Chapter - 04 Software Process and Project Metrics

Chapter 4 Software Process and Project Metrics
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001
Measurement & Metrics

... collecting metrics is too hard ... it's too time-consuming ... it's too timepolitical ... it won't prove anything ...
Anything that you need to quantify can be measured in some way that is superior to not measuring it at all .. Tom Gilb
Why do we Measure?
To characterize To evaluate To predict To improve
Metrics Guidelines
Use common sense and organizational sensitivity when interpreting metrics data. Provide regular feedback to the individuals and teams who have worked to collect measures and metrics. Dont use metrics to appraise individuals. Work with practitioners and teams to set clear goals and metrics that will be used to achieve them. Never use metrics to threaten individuals or teams. Metrics data that indicate a problem area should not be considered negative. These data are merely an indicator for process improvement. Dont obsess on a single metric to the exclusion of other important metrics.
Product Metrics
focus on the quality of deliverables measures of analysis model complexity of the design
internal algorithmic complexity architectural complexity data flow complexity
code measures (e.g., Halstead) measures of process effectiveness

e.g., defect removal efficiency
Process Metrics - strategic

majority focus on quality achieved as a consequence of a repeatable or managed process statistical SQA data
error categorization & analysis
defect removal efficiency

propagation from phase to phase
reuse data
Project Metrics tactical

Effort/time per SE task Errors uncovered per review hour Scheduled vs. actual milestone dates Changes (number) and their characteristics Distribution of effort on SE tasks
Normalization for Metrics

Normalized data are used to evaluate the process and the product (but never individual people) size-oriented normalization function-oriented normalization approach the line of code approach the function point
Typical Size-Oriented Metrics Sizeerrors per KLOC (thousand lines of code) defects per KLOC $ per LOC page of documentation per KLOC errors / person-month personLOC per person-month person$ / page of documentation
Typical Function-Oriented Metrics Functionerrors per FP (thousand lines of code) defects per FP $ per FP pages of documentation per FP FP per person-month person-
10
Computing Function Points

Analyze information domain of the application and develop counts
Establish count for input domain and system interfaces
Weight each count by assessing complexity
Assign level of complexity or to each count
weight
Assess influence of global factors that affect the application
Grade significance of external factors, F such as reuse, concurrency, OS, ... function points = (count x weight) x C
where: complexity multiplier: C = (0.65 + 0.01 x N) degree of influence: N = F i These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001
Compute function points
11
Analyzing the Information Domain

measurement parameter number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces count-total complexity multiplier function points count weighting factor simple avg. complex X X X X X 3 4 3 7 5 4 5 4 10 7 6 7 6 15 10 = = = = =
12
Taking Complexity into Account

Factors are rated on a scale of 0 (not important) to 5 (very important): data communications distributed functions heavily used configuration transaction rate on-line data entry end user efficiency on-line update complex processing installation ease operational ease multiple sites facilitate change
13
14
Why Opt for FP Measures?

independent of programming language uses readily countable characteristics of the "information domain" of the problem does not "penalize" inventive implementations that require fewer LOC than others makes it easier to accommodate reuse and the trend toward object-oriented approaches
15
Measuring Quality
Correctness the degree to which a program operates according to specification Maintainability Maintainabilitythe degree to which a program is amenable to change Integrity Integritythe degree to which a program is impervious to outside attack Usability Usabilitythe degree to which a program is easy to use
16
Defect Removal Efficiency
DRE = (errors) / (errors + defects)

where errors = problems found before release defects = problems found after release
17
Managing Variation
The mR Control Chart
Er, Errors found/ rev iew hour
6 5 4 3 2 1 0 1 3 5 7 9 11 13 15 17 19 Projects
18

Chapter - 04 Software Process and Project Metrics

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Chapter - 04 Software Process and Project Metrics

Caricato da

Copyright:

Formati disponibili

Chapter 4 Software Process and Project Metrics

Measurement & Metrics

code measures (e.g., Halstead) measures of process effectiveness

Process Metrics - strategic

defect removal efficiency

Project Metrics tactical

Normalization for Metrics

Computing Function Points

Establish count for input domain and system interfaces

Weight each count by assessing complexity

Assign level of complexity or to each count

Assess influence of global factors that affect the application

Compute function points

Analyzing the Information Domain

Taking Complexity into Account

Why Opt for FP Measures?

Defect Removal Efficiency

DRE = (errors) / (errors + defects)

Potrebbero piacerti anche