Complete
The Personal Software Process (PSP)1
is a set of advanced process and quality techniques to help software
engineers improve their performance in their organizations through a
step-by-step, disciplined approach to measuring and analyzing their
work. Software engineers that use the PSP can substantially improve
their ability to estimate and plan their work and significantly
improve the quality, i.e., reduce the defects, in the code they
develop. PSP is a result of research by Watts Humphrey into applying
process principles to the work of individual software engineers and
small software teams [Humphrey
95]. The objective was to transfer the quality concepts of
the Capability Maturity Model (CMM)2
for Software [Paulk
95] to the individual and team processes. The PSP provides
the foundational skills necessary for individuals to participate on
teams using the Team Software
Process (TSP)3.
The foundations of PSP are the advanced process and quality
methods that have been used in manufacturing to improve all forms of
production. These concepts include the following:
- definition of the processes
- use of the defined processes
- measurement of the effects of the processes on product
- analysis of the effects on the product
- continuous refinement of the processes based on analysis
Some of the engineering methods
used in PSP are data gathering, size and resource
estimating,
defect management, yield management,
and cost of quality and productivity analysis. The basic data
gathered in PSP are
- the time the engineer spends in each process phase
- the defects introduced and found in each phase
- the size of the developed product
All PSP process quality measures
are derived from this basic set of data. Size and resource estimating
is done using a proxy-based estimating method, PROBE [Humphrey
96b], that uses the engineer's personal data and statistical
techniques to calculate a new item's most likely size and development
time, and the likely range of these estimates. A key PSP tenet is
that defect management is an engineer's personal responsibility. By
analyzing the data gathered on the defects they injected, engineers
refine their personal process to minimize injecting defects, and
devise tailored checklists and use personal reviews to remove as many
defects as possible. Yield, the principal PSP quality measure, is
used to measure the effectiveness of review phases. Yield is defined
as the percentage of the defects in the product at the start of the
review that were found during the review phase. The basic
cost-of-quality measure in PSP is the appraisal-to-failure-ratio
(A/FR), which is the ratio of the cost of the review and evaluation
phases to the cost of the diagnosing and repair phases. PSP-trained
engineers learn to relate productivity and quality, i.e., that
defect-free (or nearly so) products require much less time in
diagnosing and repair phases, so their projects will likely be more
productive.
The PSP (and the courses based on it) concentrates on applying PSP
to the design, code, and Unit Test phases, i.e. module-level
development phases of software development [Humphrey
95]. As such, an instance of PSP for module-level development
is created. In PSP for module-level development, the individual
process phases are planning, design, design review, code, code
review, compile, test, and postmortem. Size is measured in lines of
code and size/resource estimating is done using functions or objects
as the proxies for the PROBE method. Engineers build individually
tailored checklists for design review and code review based on the
history of the defects they inject most frequently. Yield is the
percentage of defects found before the first compile, engineers are
taught to strive for a 100% yield and can routinely achieve yields in
the range of 70%. A/FR is the ratio of the time spent in design
review and code review phases to the time spent in compile and test
phases, and engineers are encouraged to plan for an A/FR of 2 or
higher, which has been shown to correlate well with high yield.
The PSP substantially improves engineering performance on
estimating accuracy, defect injection, and defect removal. Class data
from 104 engineers that have taken the PSP course shows reductions of
58% in the average number of defects injected (and found in
development) per 1,000 lines of code (KLOC), and reductions of 72% in
the average number of defects per KLOC found in test. Estimating and
planning accuracy also improved with an average 26% reduction in size
estimating error and an average 46% reduction in time estimating
error. Average productivity of the group went up slightly
[Humphrey
96a].
The PSP is applicable to new development and enhancement work on
whole systems or major subunits. The PSP has been demonstrated and
used in organizations at all levels of the CMM. Because PSP
emphasizes early defect removal, i.e., spending time in the design
through code review phases to prevent and remove as many defects as
possible before the first compile, PSP introduction will likely be
difficult in organizations that are concerned primarily with schedule
and not with product quality.
PSP is an individual development process; however, it can be used
by small teams if all members are PSP-trained and team conventions
are established for code counting and defect types. PSP does not
require sophisticated tools or software development environments;
however, simple spreadsheet-based tools can significantly help
individual engineers reduce the effort needed to track and analyze
their personal data. For teams to apply these principles, the TSP
should be applied.
The principles of PSP can be applied to other areas such as
developing documentation, handling maintenance, conducting testing,
and doing requirements analysis. Humphrey describes how the PSP can
be adapted to these and other areas [Humphrey
95].
PSP is a relatively new technology. It is already being taught in
a number of universities, but industrial introduction has just begun
and only limited results are available. Early industrial results are
similar to the PSP course results, showing reduced defects and
improved quality. Work on industrial transition methods, support
tools, and operational practices is ongoing.
PSP training (class room instruction, programming exercises, and
personal data analysis reports) requires approximately 10 days of
instruction on the part of each engineer. Through the use of 10
programming exercises and 5 reports, engineers are led through a
progressive sequence of software processes, taking them from their
current process to the full-up PSP for module-level development
process. By doing the exercises, engineers learn to use the methods
and by analyzing their own data, engineers see how the methods work
for them.
Based on demonstrated benefits from course data, it is projected
that the costs of training will be recovered by an organization
within one year through reduced defects, reduced testing time,
improved cycle time, and improved product quality.
Attempts by engineers to learn PSP methods by reading the book and
then trying to apply the techniques on real projects have generally
not worked. Until they have practiced PSP methods and have become
convinced of their effectiveness, engineers are not likely to apply
them on the job.
PSP introduction requires strong management commitment because of
the significant effort required to learn PSP. It is also recommended
that you follow TSP into strategy. Management must provide engineers
the time to learn PSP and track their training progress to ensure the
training is completed.
The TSP is a follow-up
approach to Humphrey's work on PSP. The TSP was designed to provide
both a strategy and a set of operational procedures for using
disciplined software process methods at the individual and team
levels. The TSP has been used with software-only teams and with mixed
teams composed of hardware, software, systems, and test
professionals. The TSP can be used on teams that typically range in
size from 2 to about 150 individuals. The TSP has been used for both
new development and enhancement, and on applications ranging from
commercial software to embedded real-time systems. It is also
applicable in maintenance and support environments. The TSP is being
developed for a wider range of project applications, including large
multi-teams, geographically distributed teams, and functional teams
[McAndrews
00].
This technology is classified under the following categories.
Select a category for a list of related topics.
|
[Humphrey 95]
|
Humphrey, Watts. A Discipline for
Software Engineering. Reading, MA: Addison-Wesley
Publishing Company, 1995.
|
|
[Humphrey 96a]
|
Humphrey, Watts. "Using a Defined and
Measured Personal Software Process." IEEE Software
13, 3 (May 1996): 77-88.
|
|
[Humphrey 96b]
|
Humphrey, Watts. "The PSP and Personal
Project Estimating." American Programmer 9, 6 (June
1996): 2-15.
|
|
[Humphrey 00]
|
Humphrey, Watts. The Team Software
ProcessSM (TSPSM)
(CMU/SEI-2000-TR-023).
Pittsburgh, Pa.: Software Engineering Institute, Carnegie
Mellon University, 2000.
|
|
[McAndrews 00]
|
McAndrews, Donald R. The Team Software
ProcessSM (TSPSM): An Overview and Preliminary
Results of Using Disciplined Practices (CMU/SEI-2000-TR-015).
Pittsburgh, Pa.: Software Engineering Institute, Carnegie
Mellon University, 2000.
|
|
[Paulk 95]
|
Paulk, Mark C. The Capability
Maturity Model: Guidelines for Improving the Software
Process. Reading, MA: Addison-Wesley Publishing
Company, 1995.
|
Dan Burton, SEI
Archie Andrews, SEI
Watts Humphrey, SEI
Mark Paulk, SEI
10 Jan 97 (original)
1 June 01 (updated)
1 Personal Software Process and PSP are
service marks of Carnegie Mellon University.
2 Capability Maturity Model and CMM are
service marks of Carnegie Mellon University.
3 Team Software Process and TSP are
service marks of Carnegie Mellon University.
