《高级软件工程》学习资料（英文版）metrics1

Software Metrics When you can measure what you are speaking about, and can express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers your knowleage is of a meagre and unsatisfactory kind: It may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the stage of science Lord Kelvin a physicist 2. In truth, a good case could be made that if your knowleage is meagre and unsatisfactory, the last thing in the world you should do is make measurements, the chance is negligible that you will measure the right things accidentally George Miller, a psychologist

Software Metrics 1. 2. ￾✂✁☎✄☎✆✞✝☎✟☎✠☛✡✌☞☎✆☛✍☛✄☎☞✏✎✌✠☎✑✒✄✔✓✕✁☎☞✗✖✘✝☎✟☎✠☛☞☎✑✒✄☛✎✘✙✚✄☎☞✏✛✌✜✢✆✤✣✥☞✏✦☎✟☎✠✚✖★✧☎☞☎✆☎✩☛✡✌☞✏✆ ✄✤✪✌✙✚✑✒✄☎✎✌✎✞✜✫✖✤✜✢✆☛✆☎✠☎✍☛✦✏✄☎✑✒✎✌✧✌✝☎✟☎✠☛✛✌✆☎✟✗✓✬✎✌✟☎✍☛✄✗✖✢✁☎✜★✆✌✣✔☞☎✦☎✟✏✠✚✖✌✜✫✖★✭☎✦☎✠✗✖☎✓✮✁☎✄☎✆ ✝✏✟☎✠☛✡✌☞☎✆☎✆☎✟✗✖✌✍☛✄☎☞☎✎✌✠☎✑✒✄☛✜✯✖✢✧✚✓✮✁☎✄✏✆✰✝✏✟☎✠☛✡✌☞☎✆☎✆☎✟✚✖✤✄✌✪✌✙✚✑✒✄☎✎✌✎✞✜✯✖✌✜✢✆☛✆✏✠☎✍☛✦☎✄☎✑✒✎✌✧ ✝✏✟☎✠☎✑✚✛✤✆☎✟✚✓✮✱✢✄☎✩✤✣✚✄☛✜✢✎✞✟☎✲☎☞☛✍☛✄☎☞✤✣✚✑✒✄✳☞✏✆☎✩☛✠☎✆☎✎✌☞✚✖★✜✢✎✤✲✫☞☎✡✏✖✢✟☎✑✯✝☛✛✌✜★✆☎✩☎✴☛✵✶✖✤✍☛☞✌✝ ✦✏✄✥✖★✁☎✄☛✦☎✄✌✣✗✜✢✆☎✆✏✜✢✆✌✣✔✟☎✲✏✛✌✆☎✟✚✓✮✱✢✄✏✩✌✣✚✄☎✧☎✦✏✠✚✖✘✝☎✟☎✠☛✁☎☞✗✷✘✄☛✎✌✡✌☞☎✑✒✡✌✄☎✱✝☛✜✢✆✞✝☎✟☎✠☎✑ ✖★✁☎✟☎✠✤✣✚✁✚✖★✎✰☞✏✩✚✷✘☞☎✆☎✡✌✄✏✩✔✖✢✟✔✖★✁☎✄☛✎☎✖✢☞✌✣✗✄✳✟✏✲☎✎✌✡✌✜★✄☎✆☎✡✌✄✏✸ Lord Kelvin, a physicist ✵✯✆✔✖✢✑✒✠✚✖★✁☎✧☎☞✞✣✚✟✏✟☎✩☛✡✌☞☎✎✌✄☛✡✌✟☎✠✏✱✢✩☛✦☎✄☛✍☛☞☎✩☎✄✔✖★✁☎☞✚✖✌✜★✲✌✝☎✟☎✠✏✑✚✛✌✆☎✟✗✓✕✱★✄☎✩✌✣✚✄☛✜★✎ ✍☛✄✏☞✌✣✚✑✒✄☛☞☎✆☎✩☛✠☎✆☎✎✌☞✗✖✢✜★✎✌✲✫☞✏✡☎✖✢✟✏✑✫✝✏✧✚✖✢✁✏✄✳✱★☞☎✎☎✖✏✖✢✁☎✜★✆✌✣✔✜✢✆✔✖★✁☎✄✔✓✮✟☎✑✒✱✢✩✞✝☎✟☎✠☛✎✌✁☎✟✏✠☎✱✢✩ ✩✏✟✳✜★✎✞✍☛☞☎✛✌✄☛✍☛✄☎☞☎✎✌✠✏✑✶✄✏✍☛✄☎✆✚✖★✎✌✭✔✖✢✁☎✄☛✡✌✁✏☞☎✆☎✡✌✄☛✜✢✎✞✆☎✄✤✣✚✱✢✜✣✚✜★✦☎✱✢✄✔✖★✁☎☞✚✖✘✝✏✟☎✠✔✓✕✜★✱✢✱ ✍☛✄✏☞☎✎✌✠☎✑✒✄✔✖✢✁✏✄✳✑✒✜✣✚✁✚✖☎✖★✁☎✜★✆✌✣✚✎✞☞☎✡✌✡✌✜★✩☎✄☎✆✗✖✢☞☎✱★✱✹✝✏✸ George Miller, a psychologist ✺

Software metrics · Product vs. process Most metrics are indirect No way to measure property directly or Final product does not yet exist For predicting, need a model of relationship of predicted variable with other measurable variables Three assumptions(Kitchenham) 1. We can accurately measure some property of software or process 2. A relationship exists between what we can measure and what we want to know 3. This relationship is understood, has been validated, and can be expressed in terms of a formula or model Few metrics have been demonstrated to be predictable or related to product or process attributes

Software Metrics Product vs. process Most metrics are indirect: No way to measure property directly or Final product does not yet exist For predicting, need a model of relationship of predicted variable with other measurable variables. Three assumptions (Kitchenham) 1. We can accurately measure some property of software or process. 2. A relationship exists between what we can measure and what we want to know. 3. This relationship is understood, has been validated, and can be expressed in terms of a formula or model. Few metrics have been demonstrated to be predictable or related to product or process attributes. ✻

Software Metrics(2 Code Static Dynamic Programmer productivity Desig Testing · Maintainabil Management Cost Duration time Staffing

Software Metrics (2) Code Static Dynamic Programmer productivity Design Testing Maintainability Management Cost Duration, time Staffing . ✼

Code metrics Estimate number of bugs left in code From static analysis of code From dynamic execution Estimate future failure times: operational reliability

Code Metrics Estimate number of bugs left in code. From static analysis of code From dynamic execution Estimate future failure times: operational reliability ✽

Static Analysis of Code Halsteads software physics or software Science n1=no of distinct operators in program n2 =no of distinct operands in program N1= total number of operator occurrences N2= total number of operand occurrences Program Length: N=N1+ N2 Program volume: V=N log,(n1+ n2) represents the volume of information(in bits)necessary to specify a program Specification abstraction level: L=(2* n2)/(n1*N2) Program Effort: E=(n1+N2*(N1+ N2)*log,(n1+ n2))/(2*n2) (interpreted as number of mental discrimination required to implement the program

Static Analysis of Code Halstead’s Software Physics or Software Science n1 = no. of distinct operators in program n2 = no. of distinct operands in program N1 = total number of operator occurrences N2 = total number of operand occurrences Program Length: N = N1 + N2 Program volume: V = N log 2 (n1 + n2) (represents the volume of information (in bits) necessary to specify a program.) Specification abstraction level: L = (2 * n2) / (n1 * N2) Program Effort: E = (n1 + N2 * (N1 + N2) * log2 (n1 + n2)) / (2 * n2) (interpreted as number of mental discrimination required to implement the program.) ✾

McCabe's Cyclomatic Complexity Hypothesis: Difficulty of understanding a program is largely determined by complexity of control flow graph Cyclomatic number V of a connected graph G is the number of linearly independent paths in the graph or number of regions in a planar graph R1 R2 R3 5R4 Claimed to be a measure of testing difficulty and reliability of modules McCabe recommends maximum v(G)of 10

McCabe’s Cyclomatic Complexity Hypothesis: Difficulty of understanding a program is largely determined by complexity of control flow graph. Cyclomatic number V of a connected graph G is the number of linearly independent paths in the graph or number of regions in a planar graph. R1 R2 R5 R4 R3 Claimed to be a measure of testing diffiiculty and reliability of modules. McCabe recommends maximum V(G) of 10. ✿

Static Analysis of Code( Problems) Doesnt change as program changes High correlation with program size No real intuitive reason for many of metrics Ignores many factors: e. g, computing environment, application area, particular algorithms implemented characteristics of users, ability of programmers Very easy to get around. Programmers may introduce more obscure complexity in order to minimize properties measured by particular complexity metric

Static Analysis of Code (Problems) Doesn’t change as program changes. High correlation with program size. No real intuitive reason for many of metrics. Ignores many factors: e.g., computing environment, application area, particular algorithms implemented, characteristics of users, ability of programmers,. Very easy to get around. Programmers may introduce more obscure complexity in order to minimize properties measured by particular complexity metric. ❀

Static Analysis of Code(Problems cont Size is best predictor of inherent faults remaining at start of program test One study has shown that besides size, 3 significant additional factors 1. Specification change activity, measured in pages of specification changes per k lines of code 2. Average programmer skill, measured in years 3. Thoroughness of design documentation, measured in pages of developed(new plus modified) design documents per k lines of code

Static Analysis of Code (Problems con’t) Size is best predictor of inherent faults remaining at start of program test. One study has shown that besides size, 3 significant additional factors: 1. Specification change activity, measured in pages of specification changes per k lines of code. 2. Average programmer skill, measured in years. 3. Thoroughness of design documentation, measured in pages of developed (new plus modified) design documents per k lines of code. ❁

Bug Counting using Dynamic Measurement Estimate number remaining from number found Failure count models Error seeding models Assumptions Seeded faults equivalent to inherent faults in difficulty of detection a direct relationship between characteristics and number of exposed and undiscovered faults Unreliability of system will be directly proportional to number of faults that remain A constant rate of fault detection

Bug Counting using Dynamic Measurement Estimate number remaining from number found. Failure count models Error seeding models Assumptions: Seeded faults equivalent to inherent faults in difficulty of detection. A direct relationship between characteristics and number of exposed and undiscovered faults. Unreliability of system will be directly proportional to number of faults that remain. A constant rate of fault detection. ❂

Bug Counting using Dynamic Measurement(2 What does an estimate of remaining errors mean? Interested in performance of program, not in how many bugs it contains Most requirements written in terms of operational reliability, not number of bugs Alternative is to estimate failure rates or future interfailure times

Bug Counting using Dynamic Measurement (2) What does an estimate of remaining errors mean? Interested in performance of program, not in how many bugs it contains. Most requirements written in terms of operational reliability, not number of bugs. Alternative is to estimate failure rates or future interfailure times. ✺❄❃