The Personal Software Process
Overview
Service marks of Carnegie Mellon Univ






Capability Maturity Model Integration SM
CMMi SM
Team Software Process SM
TSP SM
Personal Software Process SM
PSP SM
Registered trademarks of Carnegie Mellon
University:
 Capability Maturity Model®
 CMM ®
These notes were authored by David Carrington and downloaded
from the Software Engineering Network (www.swenet.org)
2
The PSP Assumptions
• Software engineers currently learn software
development by developing toy programs.
• They develop their own processes since process
is not taught in introductory classes.
• These toy processes do not provide a suitable
foundation for large-scale software
development.
• To use effective methods consistently, engineers
must believe that they are effective.
• To believe that they are effective, they must use
them.
3
PSP0: Personal Measurement
Personal Measurement
 Engineers gather data on the time they spend by phase
and the defects they find.
 Generates real, personal data and provides the base
benchmark for measuring progress.
 3 phases: planning, dev, (design, code, compile, test),
post-mortem.
 PSP0.1 adds a coding standard, size measurement and
a process improvement proposal.
4
PSP0: Personal Measurement
Basic Measures
 Development time: measured in minutes using a
time recording log designed to account for
interruptions.
 Defects: any change to the design or code to get the
program to compile or test correctly; recorded in a
defect recording log.
 Size: lines of code, used primarily for estimating
development time; new, modified and reused code is
distinguished
Schedule: Plan your Work and Work your Plan
5
The PSP Process Flow
Requirements
PSP process
Planning
Development
Process
scripts
guide
Design
Design review
Code
Code review
Compile
Test
Time
and
defect
logs
Project
plan
summary
Postmortem
Finished product
Project and process
data summary report
6
Why measure time usage?
Time is a non-renewable resource!
 Making realistic plans requires knowing how you spend your
time.
 Tracking provides a more accurate record than just relying on
your memory.
 To manage your time, plan your time and then follow the plan
(easier said than done!).
Working to a plan helps guide your behaviour:
 less time procrastinating
 more focus on the actual task
 less likely to be distracted
 more likely to be efficient
Learn from your mistakes by planning better next time.
7
PSP Element: Time Recording Log
Time spent
working on each
PSP phase is
recorded.
Time Recording Log
Student
Instructor
JD Veloper
Humphrey
Date
Start
Stop
7/1
8:00
8:16
Interruption
Time
5
Date
Program #
Delta
Time
11
Phase
Comments
Plan
Estimated time
7/1
1A
 start time
 stop time
 interrupt time
 phase
 comments
8
Tracking Defects
A defect is anything that that detracts from a
program’s ability to completely and effectively
meet the user’s needs.
A defect is caused by a programmer’s mistake.
Even experienced programmers make a mistake
about every 7-10 lines of code they develop.
Defect prevention and removal are essential
 typically account for 50% of project effort!
Why track defects?




To identify the types of defects you introduce.
To improve your skill as a programmer.
To reduce the number of defects.
Each change you make counts as one defect.
9
PSP: Personal Quality
Defects are the basic quality measure
 Low defect rate is a prereq to quality software process
• Experienced software engineers typically inject around 100
defects per KLOC.
 Using data from past coding exercises, construct
checklists for personal design & code review
 From your data, see how checklists help personal
review
 PSP2.1 adds design specification and analysis
techniques along with defect prevention, process
analyses & process benchmarks.
10
PSP: Personal Quality
Estimating defects
 Start by estimating the total number of defects based
on estimated program size and our past record of
defect injection.
 Allocate to phases using the to-date %.
 Plan to remove all defects injected!
 It may seem strange to estimate defects when you
are trying to build something that is defect-free, but it
acknowledges reality!
11
PSP: Personal Quality
If you want to get a quality product out of test, you must put
a quality product into test:
 Testing removes only a fraction of the defects.
 The more defects in the code entering test, the more defects
there are on test exit.
Data show that it is much more efficient to find defects in
reviews than in testing:
 In unit test, typically only about 2 to 4 defects are found per hour.
 Code reviews typically find about 10 defects/hour.
 Experienced reviewers can find 70% or more of the defects in a
product.
 Unit test rarely exceeds a 50% yield.
PSP data show that reviews find 2 to 5 times as many
defects per hour compared to unit test.
12
PSP Element: Defect Recording Log
Information on each
defect found in
reviews, compiling,
and test.
 number
 type
 phase injected
 phase removed
 find/fix time
 description
Defect Types
10 Documentation
20 Syntax
30 Build, Package
40 Assignment
50 Interface
Instructor
Date
7/1
Description:
Date
Description:
Date
C18 Defect Recording Log
60 Checking
70 Data
80 Function
90 System
100 Environment
Date
Program #
JD Veloper
Humphrey
Number
Type
1
40
Missing declaration
Number
Type
Inject
code
Inject
2
20
code
Typo in function name
Remove
compile
Remove
compile
Fix Time
7/1
1A
Fix Defect
2
Fix Time
Fix Defect
1
Number
Type
Inject
Remove
Fix Time
Fix Defect
Number
Type
Inject
Remove
Fix Time
Fix Defect
Number
Type
Inject
Remove
Fix Time
Fix Defect
Description:
Date
Description:
Date
Description:
13
Size Estimation Principles
Estimating is an uncertain process:
 No one knows how big the product will be.
 Earlier the estimate, the less is known.
 Estimates can be biased by business and
other pressures.
Estimating is an intuitive learning process:
 Ability improves with experience.
 Some people will be better at estimating
than others.
Why Estimate Size?
 To make better plans:
• to more accurately size the job
• to divide the job into separable elements
 To assist in tracking progress:
• can judge when job scope changes
• can more accurately measure the work
14
Schedule Estimating
To make a schedule you need three things:
 the estimated direct project hours
 a calendar of available direct hours
 the order in which the tasks will be done
Then, you need to:
 estimate the hours needed for each task
 spread the hours over the calendar of available hours
15
Schedule Example -1
Jo decides to plan and track the next PSP
assignment. Based on her historical data,
the planned time for each phase is:
Task Planned hrs Planned value Cum. Hrs Cum. Value
Plan
1.0
8
1.0
8
Design
4.5
36
5.5
44
Code
5.0
40
10.5
84
Compile
0.5
4
11.0
88
Test
1.5
12
12.5
100
TOTAL
12.5
100
16
Schedule Example -2
Jo knows she will be able to spend 3.5 hours per day on this
assignment and produces the following schedule:
Day No.
1
2
3
4
Direct hours
3.5
3.5
3.5
3.5
Cum. hours
3.5
7.0
10.5
14
Jo can determine the day which each task should complete:
TaskPlanned hrs
Plan
1.0
Design
4.5
Code
5.0
Compile
0.5
Test
1.5
TOTAL
12.5
Cum. hrs Complete
1.0
5.5
10.5
11.0
12.5
1
2
3
4
4
17
Schedule Example -3
The final step is to calculate the (cumulative)
planned value for each day (based on
completed tasks):
Day Direct hours Cum. hours
1
3.5
3.5
2
3.5
7.0
3
3.5
10.5
4
3.5
14
Planned value
8
44
84
100
18
PSP: Project Plan Summary
The project plan
summary form holds:
 project plan data
 actual project results
• size, times, defect data
 cumulative data on all
PSP projects to date
19