Software Product Metrics

1. SoftwareProduct Metrics

2. Software Quality • Definition: • Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developedsoftware • Three important points in thisdefinition • Explicit software requirements are the foundation from which quality ismeasured. Lack of conformance to requirements is lack ofquality • Specific standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will most surely result • There is a set of implicit requirements that often goes unmentioned (e.g., ease of use). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality issuspect

3. Properties of Software QualityFactors • Some factors can be directly measured (e.g. defects uncovered during testing) • Other factors can be measured only indirectly (e.g., usability or maintainability) • Software quality factors can focus on three importantaspects • Product operation: Its operationalcharacteristics • Product revision: Its ability to undergochange • Product transition: Its adaptability to newenvironments

4. ISO 9126 Software QualityFactors • Functionality • The degree to which the software satisfies statedneeds • Reliability • The amount of time that the software is available foruse • Usability • The degree to which the software is easy touse • Efficiency • The degree to which the software makes optimal use of systemresources • Maintainability • The ease with which repair and enhancement may be made to thesoftware • Portability • The ease with which the software can be transposed from one environment to another

5. Measures, Metrics, andIndicators • These three terms are often used interchangeably, but they can have subtle differences • Measure • Provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process • Measurement • The act of determining a measure • Metric • (IEEE) A quantitative measure of the degree to which a system, component, or process possesses a givenattribute • Indicator • A metric or combination of metrics that provides insight into the software process, a software project, or the productitself

6. Examples of Metrics from EverydayLife • For Example: • Working andliving • Cost of utilities for themonth • Cost of groceries for themonth • Amount of monthly rent permonth • Time spent at work each Saturday for the pastmonth • Travel • Time to drive from home to theairport • Amount of miles traveledtoday • Cost of meals and lodging for yesterday

7. Why have Software ProductMetrics? • Provide a systematic way to assess quality based on a set of clearly defined rules • Help software engineers to gain insight into the design and construction of thesoftware • Aid in the evaluation of analysis and designmodels • Provide an indication of the complexity of procedural designs and sourcecode • Facilitate the design of more effective testingtechniques

8. The attributes of effective software metrics The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration For example, a metric that measures module cohesion should increase in value as the level of cohesion increases Metrics should be based on the requirements model, the design model. They should not be dependent on the changes of programming language syntax or semantics The metric should provide you with information that can lead to a higher-quality end product

9. METRICS FOR REQUIREMENT MODEL

10. Software measurement • Size-oriented metrics

11. METRICS FOR THE REQUIREMENTS MODEL • From the data contained in the table, a set of simple size-oriented metrics can be developed for each project: • Errors per KLOC (thousand lines of code) • Defects per KLOC • $ per LOC • Page of documentation per KLOC • In addition, other metrics can be computed: • Errors per person-month • LOC per person-month • $ per page of documentation

12. METRICS FOR THE REQUIREMENTS MODEL • Function-based Metrics • It can be used as a means for measuring the functionality delivered by a system • Using historical data, The FP metric can be used to • Estimate the cost and effort required to design, code, and test the software • Predict the number of errors that will be encountered during testing • Forecast the number of components and/or the number of projected source lines in the implemented systems

13. METRICS FOR THE REQUIREMENTS MODEL • Function-based Metrics • Function points are derived using an empirical relationship based on countable measures of software’s information domain and qualitative assessment of software complexity • Information domain values are defined in the following manner: • Number of External inputs (EIs) • Each external input originates from a user or is transmitted from another application and provides distinct application-oriented data • Number of External Outputs (EOs) • Each external output is derived data within the application that provides information to the user. External output refers to reports, screens, error messages, and likes

14. METRICS FOR THE REQUIREMENTS MODEL • Function-based Metrics • Number of External Inquiries (EQs) • It is defined as an online input that results in the generation of some immediate software response in the form of an online output • Number of Internal Logical Files • Each internal logical file is a logical grouping of data that resides within the application’s boundary and is maintained via external inputs • Number of External Interface Files • It is a logical grouping of data that resides external to the application but provides data that may be of use to the application

15. METRICS FOR THE REQUIREMENTS MODEL / Function based metrics • Computing Function Points

16. Function based metrics • Once Information Domain data have been collected, a complexity value is associated with each count • Organizations that use function point methods develop criteria for determining whether a particular entry is simple, average, or complex • The determination of complexity is somewhat subjective FP = count total x [0.65 + 0.01 x ∑(Fi)] where count total is the sum of all FP entries obtained from the table The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to certain questions

17. METRICS FOR THE REQUIREMENTS MODEL • "complexity adjustment values“ Questions • Does the system require reliable backup and recovery? • Are data communications required? • Are there distributed processing functions? • Is performance critical? • Will the system run in an existing, heavily utilized operational environment? • Does the system require on-line data entry? • Does the on-line data entry require the input transaction to be built over multiple screens or operations? • Are the master files updated on-line? • Are the inputs, outputs, files, or inquiries complex? • Is the internal processing complex? • Is the code designed to be reusable? • Are conversion and installation included in the design? • Is the system designed for multiple installations in different organizations? • Is the application designed to facilitate change and ease of use by the user?

18. METRICS FOR THE REQUIREMENTS MODEL • Rate each factor on a scale of 0 to 5 0 - No influence1 - Incidental2 - Moderate3 - Average4 - Significant5 - Essential

19. Function based metrics • Computing function points for an example application. • FP = count total x [0.65 + 0.01 x ∑(Fi)] • FP = 50 x [0.65 + (0.01 x 46)] = 56

20. Size based metrics • Advantages • Simple • Drawbacks • Code dependent – does not take into consideration the size of specification • Do not consider functionality of complexity • Bad programming habits or ineffective design may cause excessive lines of code • It is language dependent

21. Function Points • Advantages • It is language independent • Not restricted to code • More accurate than LOC estimation • Drawbacks • Subjective valuing is involved • Not easy to automate or compute • More inclined towards data processing applications • Do not take quality of output in consideration

22. Example

24. METRICS FOR OTHER MODELS

25. Metrics for the Design Model • Architecturalmetrics • Provide an indication of the quality of the architecturaldesign • Component-levelmetrics • Measure the complexity of software components and other characteristics that have a bearing on quality • Interface design metrics • Focus primarily onusability • Specialized object-oriented designmetrics • Measure characteristics of classes and their communication and collaboration characteristics

26. Metrics for SourceCode • Complexity metrics • Measure the logical complexity of source code • Length metrics • Provide an indication of the size of thesoftware “These metrics can be used to assess source code complexity, maintainability, and testability, among othercharacteristics”

27. Metrics forTesting • Statement and branch coveragemetrics • Lead to the design of test cases that provide programcoverage • Defect-related metrics • Focus on defects (i.e., bugs) found, rather than on the teststhemselves • Testing effectivenessmetrics • Provide a real-time indication of the effectiveness of tests that have been conducted • In-process metrics • Process related metrics that can be determined as testing isconducted

28. Metrics for Object-OrientedDesign • Size • Population: a static count of all classes andmethods • Volume: a dynamic count of all instantiated objects at a giventime • Length: the depth of an inheritancetree • Coupling • The number of collaborations between classes or the number of methods called between objects • Cohesion • The cohesion of a class is the degree to which its set of properties is part of the problem or design domain • Primitiveness • The degree to which a method in a class is atomic (i.e., the method cannot be constructed out of a sequence of other methods provided by theclass)