For University Use Only Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

For University Use Only Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

Chapter 19 Technical Metrics for Software

McCall’s Triangle of Quality b l y P o r t a b i l y F l e x i b t y R e u s a b i l t y T e s t a b i l y I n t e r o p a b i l y P R O D U C T E V I S N P R O D U C T A N S I P R O D U C T E A I N C o r e c t n s U s a b i l t y E f i c e n y R e l i a b t y I n t e g r i y

A Comment McCall’s quality factors were proposed in the early 1970s. They are as valid today as they were in that time. It’s likely that software built to conform to these factors will exhibit high quality well into the 21st century, even if there are dramatic changes in technology.

Formulation Principles The objectives of measurement should be established before data collection begins; Each technical metric should be defined in an unambiguous manner; Metrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design should draw upon basic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemed desirable); Metrics should be tailored to best accommodate specific products and processes [BAS84]

Collection and Analysis Principles Whenever possible, data collection and analysis should be automated; Valid statistical techniques should be applied to establish relationship between internal product attributes and external quality characteristics Interpretative guidelines and recommendations should be established for each metric

Attributes simple and computable. It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time empirically and intuitively persuasive. The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration consistent and objective. The metric should always yield results that are unambiguous. consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of unit. programming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself. an effective mechanism for quality feedback. That is, the metric should provide a software engineer with information that can lead to a higher quality end product

Analysis Metrics Function-based metrics: use the function point as a normalizing factor or as a measure of the “size” of the specification Bang metric: used to develop an indication of software “size” by measuring characteristics of the data, functional and behavioral models Specification metrics: used as an indication of quality by measuring number of requirements by type

Architectural Design Metrics Structural complexity = g(fan-out) Data complexity = f(input & output variables, fan-out) System complexity = h(structural & data complexity) HK metric: architectural complexity as a function of fan-in and fan-out Morphology metrics: a function of the number of modules and the number of interfaces between modules

Component-Level Design Metrics Cohesion metrics: a function of data objects and the locus of their definition Coupling metrics: a function of input and output parameters, global variables, and modules called Complexity metrics: hundreds have been proposed (e.g., cyclomatic complexity)

Interface Design Metrics Layout appropriateness: a function of layout entities, the geographic position and the “cost” of making transitions among entities

Code Metrics Halstead’s Software Science: a comprehensive collection of metrics all predicated on the number (count and occurrence) of operators and operands within a component or program

Chapter 8 Software Quality Assurance

Why SQA Activities Pay Off? cost to find and fix a defect 100 60.00-100.00 log scale 10.00 10 3.00 1.50 1.00 1 0.75 Design test field Req. system code use test

Quality Concepts general objective: reduce the “variation between samples” ... but how does this apply to software? quality control: a series of inspections, reviews, tests quality assurance: analysis, auditing and reporting activities cost of quality appraisal costs failure costs external failure costs

Software Quality Assurance SQA Process Definition & Standards Formal Technical Reviews Analysis & Reporting Test Planning & Review Measurement

Reviews & Inspections ... there is no particular reason why your friend and colleague cannot also be your sternest critic. Jerry Weinberg

What Are Reviews? a meeting conducted by technical people for technical people a technical assessment of a work product created during the software engineering process a software quality assurance mechanism a training ground

What Reviews Are Not! They are not: a project budget summary a scheduling assessment an overall progress report a mechanism for reprisal or political intrigue!!

The Players review leader producer reviewer recorder standards bearer (SQA) producer maintenance oracle reviewer recorder user rep

Conducting the Review 1. be prepared—evaluate product before the review 2. review the product, not the producer 3. keep your tone mild, ask questions instead of making accusations 4. stick to the review agenda 5. raise issues, don't resolve them 6. avoid discussions of style—stick to technical correctness 7. schedule reviews as project tasks 8. record and report all review results

Review Options Matrix * IPR WT IN RRR trained leader agenda established reviewers prepare in advance producer presents product “reader” presents product recorder takes notes checklists used to find errors errors categorized as found issues list created team must sign-off on result IPR—informal peer review WT—Walkthrough IN—Inspection RRR—round robin review no maybe yes no yes no yes no maybe *

Metrics Derived from Reviews inspection time per page of documentation inspection time per KLOC or FP inspection effort per KLOC or FP errors uncovered per reviewer hour errors uncovered per preparation hour errors uncovered per SE task (e.g., design) number of minor errors (e.g., typos) number of major errors (e.g., nonconformance to req.) number of errors found during preparation

Statistical SQA measurement • collect information on all defects • find the causes of the • move to provide fixes for the process Product & Process measurement ... an understanding of how to improve quality ...