How does PSP help solve the problem?
To see how PSP can improve the quality of your application development
and reduce its cost, read this example from the SEI, Carnegie Mellon University.
"In this study we examined five personal process improvement dimensions
of the PSP: size and effort estimation accuracy, product quality, process
quality, and personal productivity. We found that the PSP improved performance
in the first four of these dimensions without any loss in the fifth area,
productivity."
-
Effort estimates improved by a factor of 1.75 (median improvement).
-
Size estimates improved by a factor of 2.5 (median improvement).
-
The tendency to underestimate size and effort was reduced. The number of
overestimates and underestimates were more evenly balanced.
-
Product quality, defects found in the product at unit test, improved 2.5
times (median improvement).
-
Process quality, the percentage of defects found before compile, increased
by 50% (median improvement).
-
Personal productivity, lines of code produced per hour, did not change
significantly. However, the improvement in product quality resulting from
the PSP is expected to improve productivity and cycle time as measured
at the project level (i.e., when integration and system test phase effort
are included in productivity and cycle time).
Statistics from "The Personal Software Process (PSP): An Empirical Study
of the Impact of PSP on Individual Engineers, Will Hayes and James
W. Over, December 1997, Software Engineering Institute, Carnegie Mellon
University"
Proof that PSP works
And now read about software quality improvement statistics, again from
SEI.
"Before learning the PSP, a group of three engineers took an average
of five times longer than they had estimated to develop three components
of a software system. After PSP training, the same engineers completed
the next six components of the same product in 10.4% less time than they
had planned. When measured in customer-found defects, the quality of the
components they finished after PSP training was five times better
than the qualifty of the earlier program components."
Defect Injection and Removal Examples
500 Lines of Code
|
Without PSP |
With PSP |
| Defects |
|
|
| Total defects |
50 |
25 |
| Found in code review |
0 |
15 |
| Defects remaining |
50 |
10 |
| Found in compile |
25 |
5 |
| Found in unit-test |
20 |
4 |
| Defects remaining |
5 |
1 |
|
|
|
| Time(hours) |
|
|
| Code review time |
0 |
2.5 |
| Compile time |
2 |
0.5 |
| Unit test time |
10 |
2 |
|
|
|
| Total Defect-Removal Time |
12 |
5 |
|
|
|
From "Introduction to the Personal Software Process, Watts S. Humphrey,
Software Engineering Institute, Addison-Wesley, 1997.
Further reading on software quality improvement:
Personal Software Process and Team Software Process (TSP)
An Empirical Study of the Impact of PSP on Individual Engineers
Applying Statistical Process Control for Software
Plan for Success
From the KPMG Peat Marwick study, project managers of these same
projects identified several critical success factors that they would
employ to avoid a runaway software project next time. From a project
management perspective they found:
-
Improved project management(86%)
-
Feasibility study (84%)
-
More user involvement (68%)
-
More external advice (56%)
"Runaway Projects - Causes and Effects", Software World, vol. 26, no. 3.