948 PERSONAL SOFTWARE PROCESS (PSP)

evolution. In his empirical work, he uses primarily the PERSONAL SOFTWARE PROCESS (PSP)
results to prune his theoretical work, but also creates
empirical methods when needed to support that work.
INTRODUCTION
Dewayne Perry's research interests are centered on the
creation and application of methods, techniques, pro-
cesses, tools and technologies, organizational structures, The Personal Software Process (PSP)^'^ (Personal Soft-
and software engineering principles for building and evol- ware Process and PSP are service marks of Carnegie Mel-
ving large-scale software systems. His research has been lon University.) provides engineers a disciplined personal
strongly influenced first by his experience as a practicing framework for doing software work. The PSP process con-
software engineer and second by his continuing empirical sists of a set of methods, forms, and scripts that show soft-
studies with, for example, software development organiza- ware engineers how to plan, measure, and manage their
tions within Lucent Technologies. work. It is introduced with a textbook and a course that
are designed for both industrial and academic use. The
Several general themes run through all his research. PSP is designed for use with any programming language
The first is that of software evolution. While his experience or design methodology, and it can be used for most aspects
as a software engineer spanned both initial and evolution- of software work, including writing requirements, running
ary development, his research has focused on the latter tests, defining processes, and repairing defects. When
since it is the more general problem and any principles engineers use the PSP, the recommended process goal is
and solutions found there will be applicable to initial devel- to produce zero-defect products on schedule and within
opment as well. The second strand is that of using empiri- planned costs. When used with the Team Software Process
cal studies (as exemplified in the Perry-Porter-Votta (TSP)^", (Team Software Process and TSP are service
tutorial A Primer on Empirical Studies) as the basis for marks of Carnegie Mellon University.) the PSP has heen
motivation, justification, and evaluation. These empirical effective in helping engineers achieve these objectives
studies range from looking at current practices as a base (see TEAM SOFTWARE PROCESS).
for software engineering research, scientific experiments
to determine underlying causal factors, to generating This article describes in detail what the PSP is and how
and testing software engineering theories and principles. it works. Starting with a brief discussion of the relation-
ship of the PSP to general quality principles, the article
His research interests (in the context software system
describes how the PSP was developed, its principles, and
evolution) are in empirical studies, formal models of the
its methods. Next is a summary of the PSP courses, the
software processes, process and product support environ-
strategy used for teaching the PSP, selected data on PSP
ments, software architecture, and the practical use of for-
experience, PSP adoption in university curricula, and the
mal specifications and techniques. He is particularly
status of PSP introduction into industry. The article con-
interested in the role architecture plays in the coordina-
cludes with comments on likely future trends involving
tion of multisite software development as well as its role
the PSP.
in capitalizing on company software assets in the context
of product lines.
The challenges at UT for Dewayne Perry are building a SOFTWARE QUALITY
great software engineering program at both graduate and
undergraduate levels, creating a software engineering Until shortly after World War II, the quality strategy in
research center, and focusing on the empirical aspects of most industrial organizations was based almost entirely
software engineering to create a mature and rigorous on testing. Groups typically established special quality
empirical software engineering discipline. Obviously, the departments to find and fix problems after products had
design of the software engineering curriculum, the crea- been produced. It was not until the 1970s and 80s that
tion of the necessary software engineering courses, and W. Edwards Deming and J. M. Juran convinced U.S.
the hiring of first rate software engineering research industry to focus on improving the way people performed
faculty are all critical to successfully meeting these chal- their jobs (Deming, 1982; Juran and Gryna, 1988). In the
lenges. succeeding years, this focus on working processes has been
Dewayne Perry's work in the use of "light semantics" responsible for major improvements in the quality of auto-
has been one of his seminal contributions to software engi- mobiles, electronics, or almost any other kind of product.
neering: his paper "Software Interconnection Models" was The traditional test-and-fix strategy is now recognized as
the best paper for ICSE9 (9th International Conference on expensive, time-consuming, and ineffective for engineer-
Software Engineering), Monterey 1987; his paper "The ing and manufacturing work.
Inscape Environment" from ICSEll, Pittsburgh 1989, Even though most industrial organizations have now
was considered to be the most influential paper from that adopted modern quality principles, the software commu-
conference at ICSE21, Los Angeles 1999. nity has continued to rely on testing as the principal qual-
He is a co-editor-in-chief of Wiley's Software Process: ity management method. For software, the first major step
Improvement & Practice; a former associate editor of in the direction pioneered by Deming and Juran was taken
IEEE Transactions on Software Engineering; a member by Michael Fagan in 1976, when he introduced software
of ACM SIGSOFT and IEEE Computer Society; and has inspections (Fagan, 1976, 1986). By using inspections,
served as organizing, program, and other chairs as well organizations have substantially improved software qual-
program committee member on various software engineer- ity. Another significant step in software quality improve-
ing conferences. ment was taken with the initial introduction of the
 PERSONAL SOFTWARE PROCESS (PSP) 949

Capability Maturity Model (CMM) for software in 1987 from these initial courses, Humphrey revised the PSP text-
(Humphrey, 1989; Paulk et al., 1995). The CMM's pritici- book manuscript and published the final version in late
pal focus was on the management system and the support 1994 (Humphrey, 1995). At about the same time, Jim
and assistance provided to the development engineers. Over and Neil Reizer of the SEI and Robert Powels of the
The CMM has had a suhstantial positive effect on the AIS corporation developed the first course to train instruc-
performance of software organizations (Herhsleb et al., tors to teach the PSP in industry. Watts Humphrey and
1997). [For further information on the CMM, see CAPABI the SEI have continued working on PSP development
LITY MATURITY MODEL ( C M M ) . ] and introduction hy applying the same principles to the
A further significant step in software quality improve- work of engineering teams. This work is called the Team
ment was taken with the Personal Software Process (PSP) Software Process (see the TEAM SOFTWARE PROCESS).
(Humphrey, 1995). The PSP extends the improvement pro-
cess to the people who actually do the work - the practicing
PRINCIPLES OE THE PSP
engineers. The PSP concentrates on the work practices of
the individual engineers. The principle behind the PSP is
that to produce quality software systems, every engineer The PSP design is based on the following planning and
who works on the system must do quality work (see also quality principles.
CAPABILITY MATURITY MODEL and TEAM SOFTWARE PROCESS).
Every engineer is different; to be most effective, engi-
The PSP is designed to help software professionals con- neers must plan their work and they must base their
sistently use sound engineering practices. It shows them plans on their own personal data.
how to plan and track their work, use a defined and mea-
sured process, establish measurable goals, and track per- To consistently improve their performance, engineers
formance against these goals. The PSP shows engineers must personally use well-defined and measured pro-
how to manage quality from the beginning of the job, how cesses.
to analyze the results of each job, and how to use the results To produce quality products, engineers must feel per-
to improve the process for the next project. sonally responsible for the quality of their products.
Superior products are not produced by mistake; engi-
neers must strive to do quality work.
H O W THE PSP WAS DEVELOPED It costs less to find and fix defects earlier in a process
than later.
After he led the initial development of the CMM for soft- It is more efficient to prevent defects than to find and fix
ware, Watts Humphrey decided to apply CMM principles them.
to writing small programs. Many people had been asking The right way is always the fastest and cheapest way to
how to apply the CMM to small organizations or to the
do a job.
work of small software teams. While the CMM principles
applied to such groups, more guidance was needed on pre-
To do a software engineering Job in the right way, engi-
cisely what to do. Humphrey decided to personally use
neers must plan their work before committing to or start-
CMM principles to develop module-sized programs both
ing on a job, and they must use a defined process to plan
to see if the approach would work and to figure out how
the work. To understand their personal performance,
to convince software engineers to adopt such practices.
they must measure the time that they spend on each job
In developing module-sized programs, Humphrey per- step, the defects that they inject and remove, and the sizes
sonally used all of the software CMM practices up through of the products that they produce. To consistently produce
level 5. Shortly after he started this project in April 1989, quality products, engineers must plan, measure, and track
the Software Engineering Institute (SEI) made Humphrey product quality, and they must focus on quality from the
an SEI fellow, enabling him to spend full time on the PSP beginning of a job. Finally, they must analyze the results
research. Over the next three years, he developed a total of of each job and use these findings to improve their personal
62 programs and defined about 15 PSP process versions. processes.
He used the Pascal, Object Pascal, and C + + program-
ming languages to develop about 25,000 lines of code.
From this experience, he concluded that the Deming and PSP PROCESS STRUCTURE
Juran process management principles were just as applic-
able to the work of individual software engineers as they The structure of the PSP process is shown conceptually in
were to other fields of technology. Figure 1. Starting with a requirements statement, the first
Humphrey next wrote a textbook manuscript that he step in the PSP process is planning. There is a planning
provided to several associates who planned to teach PSP script that guides this work and a plan summary for
courses. In September 1993, Howie Dow taught the first recording the planning data. While the engineers are fol-
PSP course to four graduate students at the University lowing the script to do the work, they record their time
of Massachusetts (Lowell). Humphrey also taught the and defect data on the time and defect logs. At the end of
PSP course during the winter semester of 1993/94 at Car- the job, during the postmortem phase (PM), they summar-
negie Mellon University, as did Nazim Madhavji at McGill ize the time and defect data from the logs, measure the
University and Soheil Khajanoori at Embry Riddle Aero- program size, and enter these data in tbe plan summary
nautical University. On the basis of experiences and data form. When done, they deliver the finished product along
950 PERSONAL SOFTWARE PROCESS (PSP)

I Requirements guess at what the product would look like if the engineers
had to build it based on what they currently know. Later,
Ptanning Man during the design phase, the engineers examine design
Design alternatives and produce a complete product design.
Design review
Scripts Guide Logs RMult»\
Code Estimate Product Size and Resources. The correlation of
program size with development time is only moderately
good for engineering teams and organizations. However,
Compile Plan for individual engineers, the correlation is generally quite
'Tims summary
Test
y DetectB high. Therefore, the PSP starts with engineers estimating
the sizes of the products they will personally develop.
Postmortem
1 Then, on the basis of their personal size and productivity
1 1
Project and process data
data, the engineers estimate the time required to do the
work. In the PSP, these size and resource estimates are
Ftnlshed product made with the PROBE method.
summary report
Figure 1. PSP process flow.
Size Estimating with PROBE
PROBE stands for PROxy Based J^Jstimating and it uses
with the completed plan summary form. A copy of the proxies or objects as the basis for estimating the likely
PSPl plan summary is shown in Tahle 1. size of a product (Humphrey, 1995). With PROBE, engi-
Since the PSP process has a number of methods that are neers first determine the objects required to build the pro-
seldom practiced by engineers, the PSP methods are intro- duct described by the conceptual design. Then they
duced in a series of seven process versions. These versions determine the likely type and number of methods for
are laheled PSPO through PSP3, and each version has a each object. They refer to historical data on the sizes of
similar set of logs, forms, scripts, and standards, as shown similar objects they have previously developed and use lin-
in Figure 2. The process scripts define the steps for each ear regression to determine the likely overall size of the
part of the process, the logs and forms provide templates finished product. The example object size data in Table 3
for recording and storing data, and the standards guide show the five size ranges the PSP uses for objects. Since
the engineers as they do the work. object size is a function of programming style, the PROBE
An example PSP script is shown in Table 2. A PSP method shows engineers how to use the data on the pro-
script is what Deming (1982) called an operational process. grams they have personally developed to generate size
In other words, a process that is designed to be used. It is ranges for their personal use. Once they have estimated
constructed in a simple-to-use format with short and pre- the sizes of the objects, they used linear regression to esti-
cise instructions. While scripts descrihe what to do, they mate the total amount of code they plan to develop. To use
are more like checklists than tutorials. They do not include linear regression, the engineers must have historical data
the instructional materials that would he needed by on estimated versus actual program size for at least three
untrained users. The purpose of the script is to guide engi- prior programs.
neers in consistently using a process that they understand.
The next several sections of this article describe the var-
ious methods that the PSP uses for planning, estimating, Resource Estimating with PROBE
data gathering, quahty management, and design. The PROBE method also uses linear regression to estimate
development resources. Again, this estimate is based on
PSP PLANNING
estimated size versus actual effort data from at least three
prior projects. The data must demonstrate a reasonable
The PSP planning process is shown in Figure 3. The correlation between program size and development time.
following paragraphs describe the tasks in this figure. The PSP requires that the r'^ for the correlation he at
least 0.5.
Requirements. Engineers start planning by defining the Once they have estimated the total time for the job,
work that needs to he done in as much detail as possible. If engineers use their historical data to estimate the time
all they have is a one-sentence requirements statement, needed for each phase of the job. This is where the column
that statement must be the basis for the plan. Of course, ToDate'/i in the project plan summary in Table 1 is used.
the accuracy of the estimate and plan is heavily influenced ToDate'A keeps a running tally of the percentage of total
by how much the engineers know about ihe work to be development time that an engineer has spent in each
done. development phase. Using these percentages as a guide,
engineers allocate their estimated total development
Conceptual Design. To make an estimate and a plan, time to the planning, design, design review, code, code
engineers first define how the product is to be designed review, compile, unit test, and postmortem phases. When
and huilt. However, since the planning phase is too early done, they have an estimate for the size of the program, the
to produce a complete product design, engineers produce total development lime, and the time required for each
what is called a conceptual design. This is a first, rough development phase.
 PERSONAL SOFTWARE PROCESS {PSP) 951

Table 1. PSPl Project Plan Summary

Student Date
Program Program #
Instructor Language
Summary Plan Actual To date
LOC/Hour
Program size (LOC): Plan Actual To date
Base(B)
(Mi'iiHurt'dl (Measured)
Deleted (D)
(Estimated) (Counted)
Modified (M)
([Link] (Counted 1
Added (A)
iN Ml (T-B + D-Rl
Reused (R)
(EHtimatedl (CoLjnted)
Total new and changed (N)
(Estimated) lA + M)
Total LOC (T)
(N t B M D t H) I Measured)
Total new reused

Total object LOC (E)

Time in phase (min.) Plan Actual To date To date %
Planning
Design
Code
Compiie
Test
Postmortem
Total
Defects injected Actual To date To date %
Planning
Design
Code
Compile
Test
Total Development
Defects removed Actual To date To date %
Planning
Design
Code
Compile
Test
Total Development
After Development

Produce the Schedule. Once engineers know the time While this work is not normally considered part of the
required for each process step, they estimate the time planning process, the engineers must use the data from
they will spend on the job each day or week. With that this process to make future plans.
information, they spread the task time over the available
scheduled hours to produce the planned time for complet- Analyze the Process. After completing a job, the engi-
ing each task. For larger projects, the PSP also introduces neers do a postmortem analysis of the work. In the post-
the earned-value method for scheduling and tracking the mortem, they update the project plan summary with
work (Boehm, 1981; Humphrey, 1995). actual data, calculate any required quality or other perfor-
mance data, and review how well they performed against
Develop the Product. In the step called "develop the pro- the plan. As a final planning step, the engineers update
duct," the engineers do the actual programming work. their historical size and productivity databases. At this
952 PERSONAL SOFTWARE PROCESS (PSP)

PSPO PROBE estimating PSP DATA GATHERING

PSPO. I
PSPl Plan summaries
PSPl. I
In the PSP, engineers use data to monitor their work and
PSP2 Review checklists to help them make hetter plans. To do this, they gather
PSP2.1 data on the time that they spend in each process phase,
Design templates
the sizes of the products they produce, and the quality of
PIP these products. These topics are discussed in the following
sections.
PSP
Time Measures
forms
In the PSP, engineers use the time recording log to mea-
sure the time spent in each process phase. In this log, they
note the time they started working on a task, the time
when they stopped the task, and any interruption time. For
Defects example, an interruption would be a phone call, a brief
Time break, or someone interrupting to ask a question. By track-
ing time precisely, engineers track the effort actually spent
on the project tasks. Since interruption time is essentially
PSP random, ignoring these times would add a large random
logs error into the time data and reduce estimating accuracy.

Size Measures
Figure 2. PSP process elements. Since the time it takes to develop a product is largely deter-
mined hy the size of that product, when using the PSP,
time, they also examine any PIPs (process improvement engineers first estimate the sizes of the products they plan
proposals) and make process adjustments. They also to develop. Then, when they are done, they measure the
review the defects found in compiling and testing, and sizes of the products they produced. This provides the engi-
update their personal review checklists to help them find neers with the size data they need to make accurate size
and fix similar defects in the future. estimates. However, for these data to be useful, the size

Table 2. PSPl Process Script

Phase
Number Purpose To Guide You in Developing Module-Level Programs
Entry criteria Problem description
PSPl Project Plan Summary form
Size Estimating Template
Historical estimate and actual size data
Time and Delect Recording Logs
Defect Type Standard
Stop watch (optional)
Planning Produce or obtain a requirements statement.
Use the PROBE method to estimate the total new and changed LOC required.
Complete the Size Estimate Template.
Estimate the required development time.
Enter the plan data in the Project Plan Summary form.
Complete the Time Recording Log.
Development Design the program.
Implement the design.
Compile the program and fix and log all defects found.
Test the program and fix and log all defects found.
Complete the Time Recording Log.
Postmortem Complete the Project Plan Summary form with actual time, defect, and size data.
Exit criteria A thoroughly tested program
Completed Project Plan Summary form with estimated and actual data
Completed Size Estimating Template
Completed Test Report Template
Completed PIP forms
Completed Defect and Time Recording Logs
 PERSONAL SOFTWARE PROCESS (PSP) 953

Define the
requirements
The PROBE Method

Produce the
conceptual
design

Estimate the Historical

product size size
Customer database

Historicai
Estimate the productivity
resources database

iVIanagement
Produce the
scheduie

Size,
Develop the resource Analyze the
product schedule process
data

Figure 3. Project planning process.

measure must correlate with the development time for the in defining their own. Since the PSP requires that engi-
product. While lines of code (LOC) is the principal PSP size neers measure the sizes of the programs they produce,
measure, any size measure can be used that provides a and since manually counting program size is both time
reasonahle correlation between development time and pro- consuming and inaccurate, the PSP also guides engineers
duct size. It should also permit automated measurement of in writing two automated LOC counters for use with the
actual product size. PSP course.

Lines of Code (LOC). The PSP uses the term "logical Size Categories. To track how the size of a program is
LOC" to refer to a logical construct of the programming changed during development, it is important to consider
language heing used. Since there are many ways to define various categories of product LOC. These categories are
logical LOC, engineers must precisely define how they as follows:
intend to measure LOC (Park, 1995). When engineers
work on a team or in a larger software organization, they Base. When an existing product is enhanced, base LOC
should use the team's or organization's LOC standard. If is the size of the original product version before any
there is no such standard, the PSP guides the engineers modifications are made.

Table 3. C++ Object Size Data"

C++ Object Sizes in LOC per Method

Category Very Small Small Medium Large Very Large

Calculation 2.34 5.13 11.25 24.66 54.04
Data 2.60 4.79 8.84 16.31 30.09
I/O 9.01 12.06 16.15 21.62 28.93
Logic 7.55 10.98 15.98 23.25 33.83
Set-up 3.88 5.04 6.56 8.53 11.09
Text 3.75 8.00 17.07 36.41 77.66
"Reprinted from A Discipline for Software Engineering, p. 117, by Watts S. Humphrey, Addison Wesley Publishing Co., 1995, Permission Required.
954 PERSONAL SOFTWARE PROCESS (PSP)

Added. The added code is that code written for a new inject, the phases in which they injected them, the phases
program or added to an existing base program. in which they found and fixed them, and how long it took to
Modified. The modified LOC is that base code in an fix them. With the PSP, engineers record data on every
existing program that is changed. defect found in every phase, including reviews, inspec-
tions, compiling, and testing. These data are recorded in
Deleted. The deleted LOC is that base code in an exist-
the defect recording log.
ing program that is deleted.
The term defect in this context refers to something that
New and Changed. When engineers develop software,
is wrong with a program. It could be a misspelling, a punc-
it takes them much more time to add or modify a
tuation mistake, or an incorrect program statement.
LOC than it does to delete or reuse one. Thus, in
Defects can be in programs, in designs, or even in the re-
the PSP, engineers use only the added or modified
quirements, specifications, or other documentation.
code to make size and resource estimates. This
Defects can be found in any process phase and they can
code is called the "new and changed LOC."
be redundant or extra statements, incorrect statements,
Reused. In the PSP, the reused LOC is the code that is or omitted program sections. A defect, in fact, is anything
taken from a reuse library and used, without modifi- that detracts from tbe program's ability to completely and
cation, in a new program or program version. Reuse effectively meet the user's needs. Thus a defect is an objec-
does not count the unmodified base code retained tive thing. It is something that engineers can identify,
from a prior program version and it does not count describe, and count.
any code that is reused with modifications. With size, time, and defect data, there are many ways to
New Reuse. The new reuse measure counts the LOC measure, evaluate, and manage the quality of a program.
that an engineer develops and contributes to the The PSP provides a set of quality measures that helps
reuse library. engineers examine the quality of their programs from sev-
Total. The total LOC is the total size of a program, eral perspectives. Although no single measure can ade-
regardless of the source of the code. quately indicate the overall quality of a program, the
aggregate picture provided by the full set of PSP measures
Size Accounting. When modifying programs, it is often is a generally reliable quality indicator. The principal PSP
necessary to track the changes made to the original quality measures are
program. These data are used to determine the volume of
product developed, the engineer's productivity, and pro- Defect density
duct quality. To provide these data, the PSP uses the
Review rate
size accounting method to track all the additions, deletions,
and changes made to a program {Humphrey, 1995). Development time ratios
To use size accounting, engineers need data on the Defect ratios
amount of code in each size category. For example, if a pro- Yield
duct of 100,000 LOC were used to develop a new version, Defects per hour
and there were 12,000 LOC of deleted code, 23,000 LOC of Defect removal leverage
added code, 5,000 LOC of modified code, and 3,000 LOC of
reused code, then the new and changed (N & C) LOC would Appraisal/failure ratio (AFR)
be
Each of these measures is described in the following para-
N&C LOC = added + modified
graphs.
28,000 = 23,000 + 5,000
When measuring the total size of a product, the calcula- Defect Density. Defect density refers to the defects per
tions are as follows: new and changed KLOC found in a program. Thus, if a
150-LOC program had 18 defects, the defect density would
Total LOC = base - deleted ^ added + reused be 1000*18/150 - 120 defects/KLOC.
Defect density is measured for the entire development
Neither the modified nor the "new reuse" LOC are
process and for specific process phases. Since testing only
included in the total. This is hecause a modified LOC can
removes a fraction of the defects in a product, when there
be represented by a deleted and an added LOC, and the
are more defects that enter a test phase, there will be more
"new reuse" LOC are already accounted for in the added
remaining after the test phase is completed. Therefore, the
LOC. Using this formula, the total LOC for the above
numher of defects found in a test phase is a good indication
example would be
of the number that remain in the product after that test
phase is completed.
Total = lOOjOOO - 12,000 + 23,000 + 3,000 = 114,000 LOC
Figure 4 shows IBM data on a major product that
demonstrate this relationship (Kaplan et al., 1994). These
This is 114 KLOC, where KLOC stands for 1,000 LOC.
data imply that when engineers find relatively fewer
defects in unit test, assuming that they have performed
Quality Measures a competent test, their programs are of relatively higher
The principal quality focus of the PSP is on defects. To quality. In the PSP, a program witb 5 or fewer defects/
manage defects, engineers need data on the defects they KLOC in unit test is considered to be of good quality. For
 PERSONAL SOFTWARE PROCESS (PSP) 955

140 Table 4. PSP Defect Injection and Removal Data

Phase Injected/Hour Removed/Hour
Design 1.76 0.10
Design review 0.11 2.96
Coding 4.20 0.51
Code review 0.11 6.62
Compile 0.60 15.84
Unit test 0.38 2.21
Note: These data are from PSP courses wbere the exercises produced 2,386
programs with 308,023 LOC, 15,534 development hours, and 22,644
defects.

fore, based on the PSP data in Table 4, engineers sbould

0 100 200 300 400
spend ahout 65% as much time in code reviews as tbey
Development Defects by Component do in coding. Tbe PSP uses 50% as an approximate guide-
Figure 4. Development vs. usage defects, IBM release 1 (r^ = line for the code review time to coding time ratio.
0.9267).
Defect Ratios. Tbe PSP defect ratios compare the defects
found in one phase to those found in another. The principal
engineers who have not heen PSP trained, typical unit test defect ratios are defects found in code review divided by
defect levels range from 20 to 40 or more defects/KLOC. defects found in compile, and defects found in design
review divided by defects found in unit test. A reasonable
Review Rate. In the PSP design and code reviews, engi- rule of thumh is tbat engineers should find at least twice as
neers personally review their programs. The PSP data many defects when reviewing the code as tbey find in com-
show that when engineers review designs or code faster piling it. Tbe number of defects found wbile compiling is an
than about 150 to 200 new and changed LOC per hour, objective measure of code quality. Wben engineers find
they miss many defects. With the PSP, engineers gather more tban twice as many defects in the code review as in
data on their reviews and determine how fast they should compiling, it generally means that tbey have done a com-
personally review programs to find all or most of the petent code review or that they did not record all the com-
defects. pile defects. The PSP data also suggest that the design
review to unit test defect ratio he two or greater. If engi-
Development Time Ratios. Development time ratios neers find twice as many defects during design review as
refer to the ratio of the time spent by an engineer in any in unit test, they have probably done acceptable design
two development phases. In the PSP, the three develop- reviews.
ment time ratios used in process evaluation are design Tbe PSP uses these two measures in comhination witb
time to coding time, design review time to design time, time ratios and defect density measures to indicate
and code review time to coding time. whether a program is ready for integration and system
The design time to coding time measure is most useful testing. The code review to compile defect ratio indicates
in determining the quality of an engineer's design work. code quality and the design review to unit test defect ratio
When engineers spend less time in designing than in cod- indicates design quality. If either measure is poor, tbe PSP
ing, they are producing most of the design while coding. quality criteria suggest tbat the program is likely to bave
This means that the design is not documented, the design problems in test or later use.
cannot be reviewed or inspected, and design quality is
probably poor. Tbe PSP guideline is tbat engineers sbould Yield. In the PSP, yield is measured in two ways. Phase
spend at least as much time producing a detailed design as yield measures the percentage of tbe total defects that are
tbey do in producing the code from that design. found and removed in a phase. For example, if a program
The suggested ratio for design review time to design entered unit test with 20 defects and unit testing found 9,
time is based on the PSP data shown in Tahle 4. In the the unit test phase yield would he 45^. Similarly, if a pro-
PSP courses, engineers injected an average of 1.76 defects gram entered code review with 50 defects and tbe review
per hour in detailed design and found an average of 2.96 found 28, the code review pbase yield would he 56%. Pro-
defects per hour in design reviews. Thus, to find all tbe cess yield refers to tbe percentage of the defects removed
defects that tbey injected during the design phase, engi- before tbe first compile and unit test. Since the PSP objec-
neers sbould spend 59% as mucb time in tbe design review tive is to produce high quality programs, tbe suggested
as tbey did in tbe design. The PSP guideline is tbat engi- guideline for process yield is 70% better.
neers sbould spend at least balf as much time reviewing a The yield measure cannot he precisely calculated until
design as they did producing it. the end of a program's useful life. By then, presumably, all
The code review time to coding time ratio is also a useful the defects would bave heen found and reported. When
measure of process quality. During coding, engineers programs are of high quality, however, reasonably good
injectedanaverageof 4.20 defects per hour and tbey found early yield estimates can usually be made. For example,
an average of 6.52 defects per hour in code reviews. There- if a program bad tbe defect data shown in Table 5, tbe
9S6 PERSONAL SOFTWARE PROCESS (PSP)

Table 5. Example Defects R e m o v e d Table 7. Yield Calculations

Phase Defects Removed Phase Defects Defects Defects at Phase
Design review Injected Removed Phase Entry Yield
11
Code review 28 Detailed design 26 0 0
Compile 12 Design review 0 11 26 42.3%
Unit test 7 Code 39 0 15
Total 58 Code review 0 28 54 51.9%
Compile 0 12 26 46.2%
Unit test 0 7 U 50.0%
After unit test 0 7 7
PSP guideline for estimating the yield is to assume that Total 65 65
the number of defects remaining in the program is equal
to the number found in the last testing phase. Thus, in
Table 5, it is likely that seven defects remain after unit test is 3.06/1.71 = 1.79. This means that the engineer will
testing. he 1.79 times more effective at finding defects in design
To calculate yield, engineers use the data on the phases reviews as in unit testing. The DRL measure helps engi-
in which the defects were injected. They also need to neers design the most effective defect removal plan.
assume that the defects remaining after unit test were
injected in the same phases as those found during unit A/FR. The appraisal/failure ratio (A/FR) measures the
test. The data in Table 6 include one such defect in coding quality of the engineering process, using cost-of-quality
and six in detailed design. parameters (Juran and Gryna, 1988). The "A" stands for
As shown in Table 7, the total defects injected, includ- the appraisal quality cost, or the percentage of develop-
ing those estimated to remain, is 65. At design review ment time spent in quality appraisal activities. In PSP,
entry, the defects present were 26, so the yield of the the appraisal cost is the time spent in design and code
design review was 100*11/26 = 42.3%. At code review reviews, including the time spent repairing tbe defects
entry, the defects present were the total of 65 less those found in those reviews.
removed in design review, or 65 - 11 = 54, so the code The "F" in A/FR stands for the failure quality cost,
review yield was 100 * 28/54 = 51.9'/(. Similarly, the com- which is the time spent in failure recovery and repair.
pile yield was 100 * 12/(65 - 11 - 28) = 46.2%. Process The failure cost is the time spent in compile and unit
yield is the hest overall measure of process quality. It is test, including the time spent finding, fixing, recompiling,
the percentage of defects injected before compile that are and retesting the defects found in compiling and testing.
removed before compile. For the data in Table 7, the pro- The A/FR measure provides a useful way to assess qual-
cess yield is 100 * 39/65 = 60.0%. ity, both for individual programs and to compare the qual-
ity of the development processes used for several programs.
Defects per Hour. With the PSP data, engineers can cal- It also indicates the degree to which the engineer attemp-
culate the numbers of defects they inject and remove per ted to find and fix defects early in the development process.
hour. They can then use this measure to guide their perso- In the PSP course, engineers are told to plan for A/FR
nal planning. For example, if an engineer injected four values of 2.0 or higher. This ensures that they plan ade-
defects per hour in coding and fixed eight defects per quate time for design and code reviews.
hour in code reviews, he or she would need to spend about
30 minutes in code reviews for every hour spent in coding.
It would take this long to find and fix the defects that were PSP QUALITY MANAGEMENT
most likely injected. The defects per hour rates can be cal-
culated from the data in the project plan summary form. Software quality is becoming increasingly important and
defective software is a growing problem (Leveson, 1995).
Any defect in a small part of a large program could poten-
Defect Removal Leverage (DRL). Defect removal lever-
tially cause serious problems. As systems become faster,
age measures the relative effectiveness of two defect
increasingly complex, and more automatic, catastrophic
removal phases. For instance, from the previous examples,
failures are increasingly likely and potentially more dama-
the defect removal leverage for design reviews over unit
ging (Perrow, 1984). The problem is that the quality of
large programs depends on the quality of the smaller parts
Table 6. Example Defects Injected and Removed of which they are built. Thus, to produce high quality large
Phase
programs, every software engineer who develops one or
Defects Injected Defects Removed
more of the system's parts must do high quality work.
Detailed design 26 0 This means that all engineers must manage the quality
Design review 0 XI of their personal work. To help them do this, the PSP
Code 39 0 guides engineers in tracking and managing every defect.
Code review 0 28
Compile 0 12
Unit test 0 7 Defects and Quality
After unit test 0 7
Quality software products must meet the users' functional
Total 65 65
needs and perform reliably and consistently. While
 PERSONAL SOFTWARE PROCESS (PSP) 957

software functionality is most important to the program's Defect Prevention

users, the functionality is not usable unless the software
The most effective way to manage defects is to prevent
runs. To get the software to run, however, engineers must
their initial introduction. In the PSP, there are three dif-
remove almost all of its defects. Thus, while there are
ferent but mutually supportive ways to prevent defects.
many aspects to software quality, the engineer's first qual-
The first is to have engineers record data on each defect
ity concern must necessarily be on finding and fixing
they find and fix. Then tbey review these data to determine
defects. PSP data show that even experienced program-
what caused the defects and to make process changes to
mers inject a defect in every seven to ten lines of code
eliminate these causes. By measuring their defects, engi-
(Hayes and Over, 1997). Although engineers typically
neers are more aware of their mistakes, tbey are more sen-
find and fix most of these defects when compiling and
sitive to their consequences, and they have the data
unit testing programs, traditional software methods leave
needed to avoid making the same mistakes in the future.
many defects in tbe finished product.
Tbe rapid initial decline in total defects during the first
Simple coding mistakes can produce very destructive or few PSP course programs indicates tbe effectiveness of
hard-to-find defects. Conversely, many sophisticated tbis prevention metbod.
design defects are often easy to find. The mistake and its
The second prevention approach is to use an effective
consequences are largely independent. Even trivial imple-
design method and notation to produce complete designs.
mentation errors can cause serious system problems. This
To completely record a design, engineers must thoroughly
is particularly important since the source of most software
understand it. This not only produces better designs, it
defects is simple programmer oversights and mistakes.
results in fewer design mistakes.
Although design issues are always important, newly
developed programs typically have few design defects com- The third defect prevention method is a direct conse-
pared to the large number of simple mistakes. To improve quence of tbe second: with a more tborougb design, coding
program quality, PSP training shows engineers how to time is reduced, thus reducing defect injection. PSP data
track and manage all the defects they find in their for 298 experienced engineers show the potential quality
programs. impact of a good design. These data show that during
design, engineersinject an average of 1.76 defects per hour
whileduringcodingthey inject 4.20 defects per hour. Since
The Engineer's Responsibility it takes less time to code a completely documented design,
The first PSP quality principle is that engineers are by producing a thorougb design, engineers will corres-
personally responsible for the quality of the programs pondingly reduce tbeir coding time. So, by producing
they produce. Because the software engineer who writes thorough designs, engineers actually inject fewer coding
a program is most familiar with it, that engineer can defects (Humphrey, 1998).
most efficiently and effectively find, fix, and prevent its
defects. The PSP provides a series of practices and mea-
PSP DESIGN
sures to help engineers assess the quality of the programs
tbey produce and to guide them in finding and fixing all
program defects as quickly as possible. In addition to qual- Although the PSP can he used with any design method, it
ity measurement and tracking, tbe PSP quality manage- requires that the design be complete. Tbe PSP considers a
ment metbods are early defect removal and defect design to be complete wben it defines all four of tbe dimen-
prevention. sions shown in the object specification structure shown in
Table 8 (De Champeaux et al, 1993). Tbe way tbat these
four templates correspond to tbe ohject specification struc-
Early Defect Removal ture is shown in Table 9. Tbe PSP has four design tem-
The principal PSP quality objective is to find and fix plates that address these dimensions:
defects before the first compile or unit test. The PSP pro-
cess includes design and code review steps in which engi- The operational scenario template defines bow users
neers personally review their work products before they interact with the system.
are inspected, compiled, or tested. The principle behind The function npecification template specifies tbe call-
the PSP review process is that people tend to make the return behavior of the program's objects and classes
same mistakes repeatedly. Therefore, by analyzing data as well as tbe inberitance class structure.
on tbe defects they have made and constructing a checklist
Tbe state specification template defines the program's
of the actions needed to find those mistakes, engineers can
find and fix defects most efficiently. state machine behavior.
PSP-trained engineers find an average of 6.52 defects
per hour in personal code reviews and 2.96 defects per
hour in personal design reviews. This compares with Table 8. Object Specification Structure
2.21 defects found per hour in unit testing (Humphrey,
Ohject Specification Internal External
1998). By using PSP data, engineers can both save time
and improve product quality. For example, from average Static Attributes Inheritance
PSP data, the time to remove 100 defects in unit testing constraints class structure
is 45 hours, while the time to find that number of defects Dynamic State machine Services
in code reviews is only 15 hours. messages
958 PERSONAL SOFTWARE PROCESS (PSP)

Table 9. PSP Template Structure

Object
Specification PSP3
Templates Internal External Cyclic development
Static Logic Function specification
specification template (inheritance
template class structure)
Dynamic State machine Functional specification
template template (user interaction) PSP2.1
operational scenario PSP2
template •Code reviews Design tempiates
'Design reviews

The logic specification template specifies the program's PSP1.1

internal logic, normally in a pseudocode language. PSP1 -Task planning
•Size estimating Scheduie planning
For a complete description of these templates and how to •Test report
use them, consult the references (Humphrey, 1995).

PSP DISCiPLiNE PSP0.1

-Coding standard
A principal problem in any engineering field is getting PSPO -Process improvement
engineers to consistently use the methods they have •Current process
proposai
•Basic measures
heen taught. In the PSP, these methods are: following a •Size measurement
defined process, planning the work, gathering data, and
using these data to analyze and improve the process. While Figure 5. PSP/TSP course structure.
this sounds simple in concept, it is not easy in practice.
This is why a principal focus of PSP introduction is on pro-
viding a working environment that supports PSP prac-
tices. This is the main reason why the SEI developed the
Team Software Process: to provide the disciplined environ- practices with their first programming assignments.
ment that engineers need to consistently use the PSP Then they are more likely to develop sound personal prac-
methods in practice (see TEAM SOFTWARE PROCESS). tices, and it is easier to teach them rigorous engineering
practices when they later take the full PSP course.
When introducing the PSP in industry, engineers com-
INTRODUCING THE PSP plete the full PSP course and write all 10 of the A series of
programming exercises in the PSP texthook (Humphrey,
PSP introduction in universities starts with a PSP course 1995). This course takes about 120-150 engineering hours,
in which students write 10 programs and complete 5 data and is generally spread over 10 to 14 work days. After engi-
analysis reports (Humphrey, 1995). The university course neers are PSP trained, experience has shown that they
typically takes a full semester, during which the students must be properly managed and supported to consistently
follow the PSP process shown in Figure 5 to complete 10 use the PSP in their work (Ferguson et al, 1997). To
exercise programs. Students start with the PSPO process, help working engineers, teams, and managers consistently
where they use their current programming practices, use the PSP methods, the SEI has developed the Team
record the time they spend in each process phase, and Software Process (TSP) (see TEAM SOFTWARE PROCESS).
log all the defects they find. The PSP process is enhanced
through seven process versions, with students writing one
or two programs with each PSP version. For each program, PSP RESULTS
they use the process methods just introduced, as well as all
the methods introduced with the previous process ver- Hayes and Over (1997) have shown that the PSP course
sions. By the end of the course, the students have written substantially improves engineering performance in esti-
10 programs and have learned to use all of the PSP process mating accuracy and early defect removal while not sig-
methods. This course is designed for graduate and nificantly affecting productivity. Typical results for
advanced undergraduate students. estimating accuracy are shown in Figure 6. When engi-
There is also a PSP course for beginning university stu- neers take the PSP course, they write 10 programs and
dents (Humphrey, 1997). Although this introductory gather data on their work. In Figure 6 and the following
course teaches the same basic PSP principles as the charts, performance on program 1 is shown at the left,
advanced course, it is not as rigorous and students typi- and the results achieved with program 10 are on the
cally do not learn how to practice the full set of PSP meth- right. Since the students are using their prior program-
ods. However, they do start using sound engineering ming practices with program 1 and the full set of PSP
 PERSONAL SOFTWARE PROCESS (PSP) 959

Effort Estimation Accuracy Trend

0.7

0.6
A.
3^—•—w—\ \
0.5"
Mean Time Misestimation
PSP Level Average
0.4

^T— y^
Jlr—•—V*
OJ

0.2 0 1 2 3 4 5 6 7 8 9 10

Program Number
Figure 6. Effort estimation accuracy.

methods with program 10, the presumption is that the Although the PSP is relatively new, early industry
improvements result from the PSP methods. In writing results are becoming available (Ferguson et al., 1997;
these 10 exercise programs, defect levels also improved Seshagiri, 2001). For further information on the use of
as shown in Figure 7. The productivity results are shown the PSP in industry, see TEAM SOKTWARE PROCESS.
in Figure 8. All these data are averages for 298 students in No controlled studies have yet compared the results
SEI industrial courses on the PSP. obtained when students wrote identical programs, with

Defects Per KLOC Removed in Compile and Test

110 -

100 - * * * ^ . , :

90 - \
—-^^^^^^^^^^^^
80 - Mean Compile -^' Test
70 - PSP Level Mean Comp
60 - .Z*\^ + Test
50 - \
40 - \
:::z^
30 -

20 -

10 -

0 -
4 5 6 7 8 9 10

Program Number
Figure 7. Defect-level improvement.
960 PERSONAL SOFTWARE PROCESS (PSP)

lines of (New and Changed) Code

Produced Per Hour of Total Development Time
iO -

28 -

26 -
•I
h/ ^
* 1 t t 1
\ Mean LOC/Hour
PSP Level Average
24 -

s --:fl
22 -
A/'

3 4 5 6 7 8 9 10
Program Number
Figure 8. Productivity results.

an experimental group using the PSP methods and a con- market need. Without these, organizations cannot
trol group not using the PSP. However, when taught by he successful, regardless of their other charac-
qualified instructors, student results consistently show teristics.
significant improvement. Industrial data also show that 2. To produce superior products, management must
engineering performance after PSP training is substan- obtain superior performance from tbeir engineers.
tially better than before (Ferguson et al., 1997; Seshagiri, This requires that they hire capable people and pro-
2001). It thus appears likely tbat PSP training was respon- vide them with suitable leadership, processes, and
sible for much of the improvement found in tbe PSP support.
courses.
3. The engineers must he ahle to work together effec-
tively in a team environment and know how to con-
THE PSP A N D PROCESS IMPROVEMENT sistently produce quality products.
4. The engineering teams must be properly trained and
Tbe PSP is one of a series of tbree complementary process- capahle of doing disciplined engineering work.
improvement approaches:
Without any one of these conditions, organizations are not
Tbe Capability Maturity Model (CMM), which addres- likely to do superior work. In tbis list, tbe CMM is designed
ses software management issues (Humphrey, 1989; to provide the second capability; tbe TSP, tbe third, and
Paulk et al., 1995) (see also CAPABILITY MATURITY tbe PSP, the fourth. Unless engineers have the capabilities
MODEL) provided hy PSP training, they cannot properly support
The PSP, which is described in this article tbeir teams or consistently and reliably produce quality
The Team Software Process (TSP), which guides PSP- products. Unless teams are properly formed and led, they
cannot manage and track their work or meet schedules.
trained engineers, teams, and managers in develop-
Finally, without proper management and executive lea-
ing software-intensive products (see also TfciAM SOFT-
dership, organizations cannot succeed, regardless of their
WARE PROCESS)
other capabilities.
Although these methods are all related, they address dif-
ferent aspects of organizational capability: PSP STATUS A N D EUTURE TRENDS

1. To produce superior products, the organization's In the future, software engineering groups will he increas-
management must have a sound business strategy ingly required to deliver quality products, on time, and for
and plan as well as a set of products tbat meet a their planned costs. Guaranteed reliability and service
 PERT 961

levels, warranted security, and contract performance P. Ferguson, W. S. Humphrey, S. Khajenoori, S. Macke,
penalties will be normal and engineering staffs that can- and A. Matvya, "Introducing the Personal Software Process:
not meet such commitments will not survive. Three Industry Case Studies," IEEE Computer 30(5), 24-31
Although superior technical work will continue to be (19971.
required, the performance of each individual engineer W. Hayes and J. W. Over, The Personal Software Process: An
will he recognized as important. Quality systems require Empirical Study of the Impact of PSP on Individual Engineers,
quality parts, and unless every engineer strives to produce CMU/SEI-97-TR-OOl, Software Engineering Institute, Carne-
gie Mellon University, Pittsburgh, PA, 1997.
quality work, the team cannot do so. Quality management
will be an integral part of software engineering training. J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, and M. Paulk,
Engineers will bave to learn how to measure the quality "Software Quality and tbe Capability Maturity Model," Com-
munications of the ACM 40(6), 30-40 (1997).
of their work and bow to use these measures to produce
essentially defect-free work. W. S. Humphrey, Managing the Software Process, Addison-
Wesley, Reading, MA, 1989.
The PSP is designed to provide the disciplined practices
W. S. Humphrey, A Discipline for Software Engineering, Addison-
software professionals will need in the future. Wbile some
Wesley, Reading, MA, 1995.
industrial organizations are introducing these metbods,
broader introduction of disciplined methods must start in W. S. Humphrey, Introduction to the Personal Software Process,
Addison-Wesley, Reading, MA, 1997.
universities. Academic introduction of the PSP is currently
supported with courses at botb introductory and advanced W. S. Humphrey, "Tbe Software Quality Index," Software Quality
Professional 1(1), 8-18 (1998).
levels (Humphrey, 1995, 1997). Several universities in tbe
United States, Europe, and Australia now offer tbe PSP, J. M. Juran and F. M. Gryna, Juran s Quality Control Handbook,
and several institutions in Asia are considering its intro- 4tb ed., McGraw-Hill, New York, 1988.
duction. Tbe SEI, in conjunction witb various universities, C. Kaplan, R. Clark, and V. Tang, Secrets of Software Quality, 40
also supports a one-week summer workshop for faculty Innovations from IBM, McGraw-Hill, New York, 1994.
who teacb or wish to teach tbe PSP. N. G. Leveaon, Safeware, System Safety and Computers, Addiaon-
Wesley, Reading, MA, 1995.
Industrial PSP introduction is also supported by tbe
R. E. Park, Software Size Measurement: A Framework for Count-
SEI witb a PSP course for engineers and instructors. ing Source Statements, Technical Report, CMU/SEI-92-TR-20,
Tbis course is offered several times a year in a condensed Software Engineering Institute Carnegie Mellon University,
format tailored to industrial needs. Tbe SEI also qualifies Pittsburgh, PA, 1992.
PSP instructors to assist organizations in introducing the M. C. Paulk, C. V. Weber, B. Curtis, and M. B. Chrissie, The Cap-
PSP and it maintains a registry of qualified PSP instruc- ability Maturity Model: Guidelines for Improving the Software
tors (Software Engineering Institute). Process, Addison-Wesley, Reading, MA, 1995.
While tbe PSP is relatively new, the early results are C. Perrow, Normal Accidents, Living with High-Risk Technolo-
promising. Botb industrial use and academic adoption gies, Basic Books, New York, 1984.
are increasing. Assuming that these trends continue, the G. Seshagiri, "Making Quality Happen: Tbe Managers' Role, AIS
future sbould see a closer integration of tbe PSP, TSP, Case Study," Crosstalk 13(6), 11-13, (2000).
and CMM methods and a closer coupling of the PSP aca- Software Engineering Institute, [Link] Itsp
demic courses witb the broader computer science and soft-
ware engineering curricula.
WATTS S. HUMPHREY
Software Engineering Institute,
Carnegie Mellon University
ACKNOWLEDGMENT

Contributing reviewers for this article were Nooper Davis, PERT

Frank Gmeindl, Marsha Pomeroy Huff, Allan Koch, Don
McAndrews, Jim McHale, Julia MuUaney, Jim Over, and PERT, or project evaluation and review technique, is a
Bill Peterson. scheduling technique based on a network of evenets or
activities, and nodes whicb signal the completion of the
activity. Each event is classified by a minimum, average,
BIBLIOGRAPHY and maximum time to complete. The connected network,
tbe interconnection of all nodes, shows tbe relationship
B. W. Boehm, Software Engineering Economics, Prentice-Hall of all activities in the development. The path through the
Englewood Cliffs, NJ, 1981. network with tbe longest expected time to complete is
D. De Champeaux, D. Lea, and P. Faure, Object-Oriented System called tbe "critical patb." By identifying this critical
Development, Addison-Wesley, Reading, MA, 1993. path, management and engineering focus can he applied
W. E. Deming, Out of the Crinis, MIT Center for Advanced Engi- to assure that tbe scbedule is met by dealing with risks
neering Study, Cambridge, MA, 1982. and issues that are identified through use of the technique.
M. Fagan, "Design and Code Inspections to Reduce Errors in Pro- Tbe technique is bighly amenable to automation. As actual
gram Development," IBM Systems Journal 1513), 182-211, event completion times are recorded tbe computer can
(1976). recalculate the critical path through tbe network and
M. Fagan, "Advances in Software Inspections," IEEE Transac- furnish schedule reports. Tbis technique is also referred
tions on Software Engineering SE-12(7), 744-751, (1986). to as PERT-CPM for PERT-Critical Path Metbod.