Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How can be the quality of a software product measured?

97 views

Published on

Overview of the topic of software measurement and metrics

Published in: Software
  • Be the first to comment

  • Be the first to like this

How can be the quality of a software product measured?

  1. 1. How can be the quality of a software measured? Gábor Guta, PhD November 2009
  2. 2. gabor.guta@axonmatics.com Why do we want to measure at all? • Estimation – Predict the necessary development time/cost from the required functionailty and quality • Decision Support – Diagnoses: objectivity – What is good enought? Is it worth to spend more time on design? Was the „quick and dirty“ solution still quick if we add the extra time of bugfixing?
  3. 3. gabor.guta@axonmatics.com What do we mean by quality? Quality Attributes Metrics correctness robustness extendability efficiency ease of use functionality timeliness security testability maintainability DIT NCSS KLOCWMC Instability Abstractness CBO FP UUCP Ce Ca Man/Month LCOM
  4. 4. gabor.guta@axonmatics.com Quality Attributes • correctness – a szoftver termék azon képessége, hogy a kijelölt feladatokat, a specifikációnak megfelelően végrehajtsa; • robustness – a szoftver termék azon képessége, hogy megfelelően reagáljon abnormális körülmények között; • extendability – a szoftver termék könnyű hozzáigazíthatósága a specifikációs változásokhoz; • functionability – a szoftver rendszer által biztosított lehetőségek mértéke; • timeliness – a szoftver rendszer azon képessége, hogy rendelkezésre álljon akkorra vagy az előtt, amikor a felhasználói szeretnék. *Bertrand Meyer [Meyer97]
  5. 5. gabor.guta@axonmatics.com Process Product/External Product/Internal Measurability of the Quality DIT (Depth of Inheritance Tree) NCSS (Non-Commenting Source Statements) WMC (Weighted Methods per Classes) CBO (Coupling Between Objects) FP (Function Point) UUCP (Unadjusted Use-Case Point) Man/Month MTTF (Mean Time to Failure) Customer Satisfaction BMI (Backlog Management Index) Fix Response Time
  6. 6. gabor.guta@axonmatics.com Measurability of the Quality Process Product/External Product/Internal correctness robustness extendability efficiency functionability timeliness security testability maintainability effort cost ease of use
  7. 7. gabor.guta@axonmatics.com Process Measurement Effort  Man/Month Cost  Budget Timeliness  Release dates  Issue completion time  Average feature development / bug fixing time Never ever use process metrics for personal performance evaluation; managment only allowed to see aggregated data Issue tracking Systems: JIRA, Red Mine, etc. Working hours tracking Agile?
  8. 8. gabor.guta@axonmatics.com Measurement of the External Product Attributes Correctness: hard to measure; usually measured indirectly • Defect density • Warning/Error message density (compilation, static analysis, etc.) • Use-case / source-code coverage EMMA, Cobertura, Clover, Google CodePro AnalytiX Checkstyle, PMD, FindBugs, JDepend, KLOCWork
  9. 9. gabor.guta@axonmatics.com Measurement of the External Product Attributes Functionality: derived from the specification • Function Points - COSMIC, IFPUG, Mark II, NESMA • Story Points • Use-Case Points
  10. 10. gabor.guta@axonmatics.com • Extendability • Maintainability • Testability Measurement of the Internal Product Attributes size complexity dependency cohesion The strural metrics do not necessariliy reflect the semantic content.
  11. 11. gabor.guta@axonmatics.com Size and Complexity • Countable attributes: – Number of Lines (KLOC, NCSS) – Number of Functions – Number of Classes • McCabe Cyclomatic Complexity = number of possible execution pathes – Weighted Methods per Classes • Block Nesting Deep
  12. 12. gabor.guta@axonmatics.com Dependency and Cohesion • Afferent Coupling = the number of classes from other modules that depend on the classes within the subject module • Efferent Coupling = the number of classes in other modules that the classes in the subject module depend on • Instability = [Efferent Coupling] / ([Afferent Coupling] + [Efferent Coupling]) • Abstractness = the number of Abstract Classes / the number of Total Classes • Distance = [Abstractness] + [Instability] – 1 • Lack of Cohesion in Methods Eszközök: JDepend, Structure101, SonarJ
  13. 13. gabor.guta@axonmatics.com Vizualization • Class diagrams • Dependency diagrams

×