To frame our discussion, consider:
What we have measuring development activity?
What metrics can be applied at different stages of the development process?
To what degree have these metrics been validated?
How might these metrics influence the development activity?
Easy to learn the metric and determine its value with reasonable effort.
The metric should provide empirical support for intuitive relationships between the attributes of an artifact.
The metric should always yield the same value when applied to an artifact. Furthermore, when two independent observers apply the metric they should arrive at the same result.
| Organic | b=2.4, c=1.05 |
| A relatively small team develops software in a known environment. Those involved generally have significant experience with projects of this type. These tend to be small projects. | |
| Embedded | b=3.0, c=1.12 |
| These projects involve the development where the intended environment poses significant constraints. The product is "embedded" in an environment which is inflexible. | |
| Semidetached | b=3.6, c=1.20 |
| This is an intermediate. The team may show a mixture of experience and inexperienced people. The project may be larger than that in the organic type. |
| Cost Drivers | Rating | |||||
| very low | low | nominal | high | very high | extra high | |
| Product Attributes | ||||||
| Reliability | .75 | .88 | 1.00 | 1.15 | 1.40 | |
| Data base | .94 | 1.00 | 1.08 | 1.16 | ||
| Product Complexity | .70 | .85 | 1.00 | 1.15 | 1.30 | 1.65 |
| Computer Attributes | ||||||
| Execution Time | 1.00 | 1.11 | 1.30 | 1.66 | ||
| Main Storage | 1.00 | 1.06 | 1.21 | 1.56 | ||
| Virtual Machine Volatility | .87 | 1.00 | 1.15 | 1.30 | ||
| Computer Turnaround Time | .87 | 1.00 | 1.07 | 1.15 | ||
| Personnel Attributes | ||||||
| Analyst Capabilities | 1.46 | 1.19 | 1.00 | .86 | .71 | |
| Applications Experience | 1.29 | 1.13 | 1.00 | .91 | .82 | |
| Programmer Capability | 1.42 | 1.17 | 1.00 | .86 | .70 | |
| Virtual Machine Experience | 1.21 | 1.10 | 1.00 | .90 | ||
| Prog. Lang. Experience | 1.14 | 1.07 | 1.00 | .95 | ||
| Project Attributes | ||||||
| Use of modern prog. Tech. | 1.24 | 1.10 | 1.00 | .91 | .82 | |
| Use of Software Tools | 1.24 | 1.10 | 1.00 | .91 | .83 | |
| Development Schedule | 1.23 | 1.08 | 1.00 | 1.04 | 1.10 | |
Type | Description | Complexity Level | ||
| Simple | Average | Complex | ||
| Input (I) | User input that leads to changes in data structures. | 3 | 4 | 6 |
| Output (O) | User output that leads to changes in data structures. | 4 | 5 | 7 |
| Inquiry (E) | User inputs that control program execution. | 3 | 4 | 6 |
| Logical Internal (L) | Internal data generated and maintained by the system. | 7 | 10 | 15 |
| Interfaces (F) | Data that is output to another program. | 5 | 7 | 10 |
| Weighting Factor | |||||||
|---|---|---|---|---|---|---|---|
| Parameter | Count | Simple | Average | Complex | |||
| User Inputs | 3 | * | 3 | 4 | 6 | = | 9 |
| User Outputs | 2 | * | 4 | 5 | 7 | = | 8 |
| User Inquiries | 2 | * | 3 | 4 | 6 | = | 6 |
| Files | 1 | * | 7 | 10 | 15 | = | 7 |
| External Interfaces | 4 | * | 5 | 7 | 10 | = | 20 |
| UFP | 50 | ||||||
| Language | Source Statements |
|---|---|
| Assembler | 320 |
| C | 150 |
| COBOL | 106 |
| FORTRAN | 106 |
| Pascal | 91 |
| RPG | 80 |
| Prolog | 64 |
| LISP | 64 |
| SmallTalk | 21 |
| Query Languages | 16 |
1. Content Coupling: Two modules are content coupled if one module refers to or changes the internals of another module.
2. Common Coupling: Two modules are common coupled if they share the same global data areas.
3. Control Coupling: Two modules are control coupled if data from one is used to direct the order of instruction execution in the other.
4. Stamp Coupling: Two modules are stamp coupled if they communicate via a composite data item.
5. Data Coupling: Two modules are data coupled if they communicate via a variable or array that is passed directly as a parameter between the two modules. The data is used in problem related processing, not for program control purposes.
1. Functional: Each element in a module is a necessary and essential part of one and only one function.
2. Sequential: The elements of a module are related by performing different parts of a sequence of operations where the output of one operation is the input to the next.
3. Communicational: The elements of a module all operate on the same data.
4. Procedural: The elements of a module are all part of a procedure.
5. Temporal: The elements of a module are related by time but need not occur in a certain order or operate on the same data.
6. Logical: The elements of a module are all oriented toward performing a certain class of operations.
7. Coincidental: The elements of a module are essentially unrelated by any common function, procedure, data, or anything.
Lines of code (LOC or KLOC) is typically correlated with effort. Boehm, Walston-Felix, and Halstead all indicate Effort as a function of lines of code.
| Support | Objection |
| Easy to determine once an operational definition is agreed upon. | Some programmers write more verbose programs than others. |
| Easy to automate. | Difficult to compare programs written in different languages. |
| Easy to enforce. | Some lines are more complex than others. |
| Assembler | Ada | |
| Source Code Size | 70 KDSI | 25 KDSI |
| Development Costs | $1,043,000 | $590,000 |
| Effort (person-months) | 209 | 119 |
| KDSI per person-month | 0.335 | 0.211 |
| Cost per source statement | $14.90 | $23.60 |
SEI staff gave conference participants the following program and ask for the line count.
#define LOWER 0 /* lower limit of table */
#define UPPER 300 /* upper limit of table */
#define STEP 20 /* step size */
main()
{
int fahr;
for (fahr=LOWER; fahrUPPER;fahr=fahr+STEP)
printf("%4d %6.1f\n", fahr, (5.0/9.0)*(fahr-32));
}
| # of Source Lines | Number of Votes |
| 1 | 1 |
| 2 | 8 |
| 3 | 4 |
| 4 | 9 |
| 5 | 9 |
| 6 | 23 |
| 7 | 10 |
| 8 | 3 |
| 9 | 1 |
| Statement Type | Includes | Excludes |
|---|---|---|
| Executable | x | |
| Declarations | x | |
| Compiler Directives | x | |
| Comments on their own lines | x | |
| Assertions (Pre/Postconditions) | x | |
| Program, procedure and function banners |
x | |
| Blank Lines | x | |
| Blank Comments | x |
| Statement Type | Includes | Excludes |
|---|---|---|
| Comments on their own lines | x | |
| Assertions (Pre/Postconditions) | x | |
| Comments with source lines | x | |
| Program, procedure and function banners |
x | |
| Blank Lines | x | |
| Blank Comments | x |
Nodes represent one or more procedural statements.
Each conditional maps to a distinct node.
Edges (arcs) indicate potential flow from one node to another.
An edge must terminate at a node.
A predicate node is a node with two or more edges emanating from it.
V(G)=e-n+p where e is number of edges, n is the number of nodes, and p is the number of components.
| Procedure sort (var x:array of integer; n: integer; | |
| var i, j, save: integer; | |
| begin | |
| 1. | for i:=2 to n do (node 1) |
| 2. | for j:=1 to i do (node 2) |
| 3. | if x[i]<x[j] then (node 3) |
| 4. | begin (node 4 - includes lines 4-7) |
| 5. | save:=x[i]; |
| 6. | x[i]:=x[j]; |
| 7. | x[j]:=save |
| 8. | end (node 5) |
| 9. | end;(node 6) |
Go To Lecture Overview]
Go To [Course Outline] [CIS Department Page]
Fenton, N. & S. Pfleeger (1997) Software Metrics: A Rigorous and Practical Approach. London: International Thomson Computer Press.
Glass, R. I. (July/August 1997) Telling Good Numbers from Bad Ones. IEEE Software, p. 15-16,19.
Kan, S. H. (1995) Metrics and Models in Software Quality Engineering. Addison-Wesley.
Kitchenham, B. (1996) Software Metrics: Measurement for Software Process Improvement. Oxford: NCC Blackwell.
Pressman, R. S. (1997) Software Engineering: A Practitioner's Approach. New York: McGraw-Hill.
Rombach, H. D. (March 1990) Design Measurement: Some Lessons Learned. IEEE Software, p. 17-25.
Weyuker, E. (1988) Evaluating Software Complexity Metrics. IEEE Trans. on Software Engineering, 14(9), pp. 1357-1365.