Software Metrics Software project planning consists of two

Software Metrics • Software project planning consists of two primary tasks: • analysis • estimation (effort of programmer months, development interval, staffing levels, testing, maintenance costs, etc. ). • Important: – most common cause of software development failure is poor (optimistic) planning. 1

2

3

4

5

6

7

Size Metrics LOC - “A line of code is any line of program text that is not a comment or blank line, regardless of the number of statements or fragments of statements on the line. This specifically includes all lines containing program header, declaration, and executable and non-executable statements”. Advantages of using LOC as a size metric : ü ü ü It is widely used and universally accepted. It permits comparison of size and productivity metrics between diverse development groups. It directly relates to the end product. LOC are easily measured upon project completion. It measures software from the developers point of view- what he actually does (write LOCs). Continuous improvement activities exist for estimation techniques. Disadvantages of using LOC as a size metric : ü ü ü LOC is language dependent. A line of C is not the same as a line of COBOL. It is not consistent because some lines are more difficult to code than others. Source instructions vary with coding languages, design methods and with programmer’s ability No industry standard for measuring LOC cannot be used for normalizing if platforms and languages are different. Programmers may be rewarded for writing more LOC based on a misconception of higher management by thinking that more the LOC, means more the productivity of the programmer

FP Metrics • Function Count- Alan Albrecht while working for IBM, developed Function Point Analysis technique, which appeared to be a solution to the size measurement problem. It deals with the functionality being delivered, and not with the lines of source code, source modules, files etc. FP measures functionality from the users point of view, that is, on the basis of what the user requests and receives in return from the system. Advantages of using Function Points as a size metric : Because function point analysis is independent of language used, development platform, etc. it can be used to identify the productivity benefits of. . . – One programming language over another – One development platform / methodology over another • Function points can be estimated from requirement specification or design specification, thus making it possible to estimate development efforts in early phases of develop • Function points are directly linked to the statement of requirements; any change of requirements can easily be followed by a re-estimate Disadvantages of using Function Points : • • • Function point counts are affected by project size Difficult to apply to massively distributed systems or to complex software systems Difficult to define logical files from physical files The validity of the weights– and the consistency of their application – has been challenged Different companies will calculate function points slightly different, making intercompany comparisons questionable

Function-Oriented Metrics • Mainly used in business applications • The focus is on program functionality • A measure of the information domain + a subjective assessment of complexity • Most common are: – function points and – feature points (FP). 10

Function Points • The function point metric is evaluated using the following tables: Weighting Factor Parameter Count Simple/ Low Average Complex/Hig h # of user inputs *3 4 6= # of user outputs * 4 5 7= #of user inquiries *3 4 6= # of files *7 10 15 = # of external interfaces *5 7 10 = Weight Total_weight = 11

Function Points The following relationship is used to compute function points: 12

Function Points • where Fi (i = 1 to 14) are complexity adjustment values based on the table below: 1. 2. 3. 4. 5. Reliable backup/recovery needed? Any data communications needed? Any distributed processing functions? Performance critical? Will system run in an existing heavily utilized operational environment? 6. Any on-line data entry? 7. Does on-line data entry need multiple screens/operations? 13

Function Points 8. Are master files updated on-line? 9. Are inputs, outputs, queries complex? 10. Is internal processing complex? 11. Must code be reusable? 12. Are conversion and installation included in design? 13. Is multiple installations in different organizations needed in design? 14. Is the application to facilitate change and ease of use by user? 14

Function Points • Each of the Fi criteria are given a rating of 0 to 5 as: – No Influence = 0; Incidental = 1; – Moderate = 2 Average = 3; – Significant = 4 Essential = 5 15

Function-Oriented Metrics • Once function points are calculated, they are used in a manner analogous to LOC as a measure of software productivity, quality and other attributes, e. g. : – productivity – quality – cost – documentation FP/person-month faults/FP $$/FP doc_pages/FP 16

“If you can’t measure it, you can’t manage it” Tom De. Marco, 1982 SOFTWARE QUALITY METRICS 17

What to measure • Process Measure the efficacy of processes. What works, what doesn't. • Project Assess the status of projects. Track risk. Identify problem areas. Adjust work flow. • Product Measure predefined product attributes (generally related to ISO 9126 Software Characteristics) 18

Software Quality Metrics Three kinds of Software Quality Metrics ◦ Product Metrics - describe the characteristics of product size, complexity, design features, performance, and quality level ◦ Process Metrics - used for improving software development/maintenance process effectiveness of defect removal, pattern of testing defect arrival, and response time of fixes ◦ Project Metrics - describe the project characteristics and execution number of developers, cost, schedule, productivity, etc. fairly straight forward 19

The Software Quality Metrics Framework n n Quality requirements that the software product must meet Quality factors – Management-oriented attributes of software that contribute to its quality Quality subfactors – Decompositions of a quality factor to its technical components Metrics – quantitative measures of the degree to which given attributes (factors) are present 20

Measurement, Measures, Metrics Measurement ◦ is the act of obtaining a measure Measure ◦ provides a quantitative indication of the size of some product or process attribute, E. g. , Number of errors Metric ◦ is a quantitative measure of the degree to which a system, component, or process possesses a given attribute (IEEE Software Engineering Standards 1993) : Software Quality - E. g. , Number of errors found person hours expended 21

Software Quality Metrics Desired attributes of Metrics (Ejiogu, 1991) – Simple and computable – Empirical and intuitively persuasive – Consistent and objective – Consistent in the use of units and dimensions – Independent of programming language, so directed 22 at models (analysis, design, test, etc. ) or structure

Mc. Call’s Software Quality Factors Maintainability Flexibility Testability Portability Reusability Interoperability Product Revision Product Transition Product Operation Correctness Reliability Usability Integrity Efficiency 23

Example n Quality requirement – “The product will be easy to use” n Quality factor(s) – Usability (An attribute that bears on the effort needed for use and on the assessment of such use by users) n Quality subfactors – Understandability, ease of learning, operability, communicativeness 24

25 Mc. Call’s Quality Factors • Mc. Call has 11 factors; Groups them into categories. – 1977; others have added, but this still prevail. • Three categories: – Product Operation Factors • How well it runs…. • Correctness, reliability, efficiency, integrity, and usability – Product Revision Factors • How well it can be changed, tested, and redeployed. • Maintainability; flexibility; testability – Product Transition Factors • How well it can be moved to different platforms and interface with other systems • Portability; Reusability; Interoperability • Since these underpin the notion of quality factors and others who have added, reword or add one or two, we will spend time on these factors.

26 Mc. Call's software quality factors model Software quality factors Product operation factors Product revision factors Product transition factors

27 Mc. Calls factor model tree

28 Product operation factors • • • Correctness Reliability Efficiency Integrity Usability How well does it run and ease of use.

29 Mc. Call’s Quality Factors Category: Product Operation Factors • 1. Correctness. • Please note that we are asserting that ‘correctness’ issues are arising from the requirements documentation and the specification of the outputs… • Examples include: – Specifying accuracies for correct outputs at, say, NLT <1% errors, that could be affected by inaccurate data or faulty calculations; – Specifying the completeness of the outputs provided, which can be impacted by incomplete data (often done) – Specifying the timeliness of the output (time between event and its consideration by the software system) – Specifying the standards for coding and documenting the software system – we have talked about this: standards and integration; Essential!!

30 Mc. Call’s Quality Factors Category: Product Operation Factors • 2. Reliability Requirements. (remember, this quality factor is specified in the specs!) • Reliability requirements deal with the failure to provide service. – Address failure rates either overall or to required functions. • Example specs: – A heart monitoring system must have a failure rate of less than one per million cases. – Downtime for a system will not be more than ten minutes per month (me) – MTBF and MTTR - old and engineering, but still applicable. • 3. Efficiency Requirements. Deals with the hardware resources needed to perform the functions of the software. – Here we consider MIPS, MHz (cycles per second); data storage capabilities measured in MB or TB; communication lines (usually measured in KBPS, MBPS, or GBPS). – Example spec: simply very slow communications…

31 Mc. Call’s Quality Factors Category: Product Operation Factors • 4. Integrity – deal with system security that prevent unauthorized persons access. • Huge nowadays; Cyber Security; Internet security; network security, and more. These are certainly not the same! • 5. Usability Requirements – deals with the scope of staff resources needed to train new employees and to operate the software system. – Deals with learnability, utility, usability, and more. (me) – Example spec: A staff member should be able to process n transactions / unit time. (me)

32 Product revision factors • Maintainability • Flexibility • Testability Can I fix it easily, retest, version it, and deploy it easily?

Mc. Call’s Quality Factors Category: Product Revision Software Factors 33 • These deal with requirements that affect the complete range of software maintenance activities: – corrective maintenance, – adaptive maintenance, and – perfective maintenance – KNOW THE DIFFERENCES! • 1. Maintainability Requirements – The degree of effort needed to identify reasons (find the problem) for software failure and to correct failures and to verify the success of the corrections. – Deals with the modular structure of the software, internal program documentation, programmer manual, architectural and detail design and corresponding documentation – Example specs: size of module <= 30 statements. – Refactoring. . .

Mc. Call’s Quality Factors Category: Product Revision Software Factors 34 • 2. Flexibility Requirements – deals with resources to change (adopt) software to different types of customers that use the app perhaps a little differently; – May also involve a little perfective maintenance to perhaps do a little better due to the customer’s perhaps slightly more robust environment. – Different clients exercise software differently. This is big! • 3. Testability Requirements – – Are intermediate results of computations predefined to assist testing? – Are log files created? Backup? – Does the software diagnose itself prior to and perhaps during operations?

35 Product transition factors • Portability • Reusability • Interoperability Can I move the app to different hardware? Interface easily with different hardware / software systems; can I reuse major portions of the code with little modification to develop new apps?

36 Mc. Call’s Quality Factors Category: Product Transition Software Quality Factors • 1. Portability Requirements: If the software must be ported to different environments (different hardware, operating systems, …) and still maintain an existing environment, then portability is a must. • 2. Reusability Requirements: Are we able to reuse parts of the app for new applications? – Can save immense development costs due to errors found / tested. – Certainly higher quality software and development more quickly results. – Very big deal nowadays.

37 Mc. Call’s Quality Factors Category: Product Transition Software Quality Factors • 3. Interoperability Requirements: Does the application need to interface with other existing systems –Frequently these will be known ahead of time and plans can be made to provide for this requirement during design time. • Sometimes these systems can be quite different; different platforms, different databases, and more –Also, industry or standard application structures in areas can be specified as requirements.