EEE/GEF 492.17
PSP
The Personal Software Process
Royal Military College of Canada
Electrical and Computer Engineering
Dr. Terry Shepard
shepard@rmc.ca
613-541-6000 ext. 6031
Professor Colin Wortley
wortley@rmc.ca
613-541-6000 ext. 6493
Logic of Time Management
• You will likely spend your time this week the
same way you did last week
• You have to track the way you spend time to
allow for planning
• You must compare your time estimates and
plans to what you actually did
• You need to determine where your previous
plans were in error and correct future planning
• To mange your time, you need to make a plan
and follow your plan
Fall 2005
EEE/GEF492
17-2
Personal Process
• each individual developer involved in a software
development project has to acquire personal expertise
on estimating product complexity/size and measuring
personal productivity
• Individuals are therefore required to practice software
development estimation
• The following slides are an introduction to a Personal
Software Process (PSP) developed by Watts Humphrey
at the Software Engineering Institute.
• Other personal processes exist.
• You should develop (or you may already have) your own
process. The important thing is to have a means by which you
can measure, evaluate, and improve your own personal process.
Fall 2005
EEE/GEF492
17-3
What is PSP?
• Estimate + Measure
• defines a software development framework that
includes defined operations, measurement and
analysis to help developers understand their
own skills in order to improve their own personal
performance
• defines 7 steps spread over 4 levels of capability
maturity
Fall 2005
EEE/GEF492
17-4
How PSP works
• Developers follow a set of scripts, forms,
templates, standards and checklists (for a total
of 77)
• Mainly these scripts require developers to track
their time spent on each engineering activity and
record defects injected throughout their
software development
• By following these, developers can evolve from a
PSP level 0 to level 3 (capability)
Fall 2005
EEE/GEF492
17-5
What it does
• PSP’s goal is to have developers improve their
capability on two aspects:
• software development skills
• improve product quality
• improve productivity
• project management skills
• improve estimates - size, time, resources
• improve planning - scheduling
• Secondary to personal skills, developers will
learn through the PSP experience and feedback:
• thorough design and code reviews are the most
efficient action to perform defect removal; and
• defect prevention is more efficient than defect
removal.
Fall 2005
EEE/GEF492
17-6
PSP Training
• It is beyond the scope of this lecture to train you
on PSP.
• Training has an aspect of applied knowledge that makes the
knowledge more or less immediately useful.
• Education is focused more on teaching the principles,
experience base, and spirit of the subject, with the application of
such knowledge left to the student.
• However the following slides provide you a
glance at some of the PSP scripts, forms,
templates and logs.
Fall 2005
EEE/GEF492
17-7
PSP
Framework
Cyclic
Personal
Process
PSP 3
Cyclic development
Personal
Quality
Management
Personal
Planning
Process
Baseline
Personal
Process
Fall 2005
PSP 2
Code reviews
Design reviews
PSP 1
Size estimating
Test report
PSP 0
Current process
Time recording
Defect recording
Defect type standard
EEE/GEF492
PSP 2.1
Design templates
PSP 1.1
Task planning
Schedule planning
PSP 0.1
Coding standard
Size measurement
Process improvement proposal
17-8
PSP0
• Establish a baseline for measuring progress and
to define a foundation on which to improve
• A convenient structure for doing small-scale tasks
• A framework for measuring these tasks
• A foundation for process improvement
• The tasks introduced include the following
•
•
•
•
•
•
•
Fall 2005
Define current process (PSP0)
Time recording (PSP0)
Defect recording (PSP0)
Defect type standard (PSP0)
Code standard (PSP0.1)
Size measurement (PSP0.1)
Process improvement proposal or PIP (PSP0.1)
EEE/GEF492
17-9
PSP1
• The PSP1 process is intended to establish an
orderly and repeatable procedure for developing
software using size, resource, and schedule
estimating
• estimation process becomes more accurate as more
data is gathered from multiple projects
• Tasks are
•
•
•
•
Fall 2005
(plus keep doing PSP0)
Size estimating (PSP1)
Test reporting (PSP1)
Task planning (PSP1.1)
Schedule planning (PSP1.1)
EEE/GEF492
17-10
PSP2
• The PSP2 process introduces design and code
reviews and quality measurement and
evaluation
• PSP2.1 process introduces design completeness
criteria and design verification
• Tasks are
(plus keep doing PSP0 + PSP1)
• Design reviews (PSP2)
• Code reviews (PSP2)
• Design templates (PSP2.1)
Fall 2005
EEE/GEF492
17-11
Time
Recording
Log
TIME RECORDING LOG
Student
Instructor
Date
Fall 2005
Date
Program #
Start
Stop
Interruption
time
Delta
Time
EEE/GEF492
Phase
Comments
17-12
Time Tracking Hints
•
•
•
•
Categorize your major activities
Record time spent in each major activity
Record time in a standard way
Keep the time data in a convenient place
• engineering notebook
• include a table of contents
• used for planning and recording time
• Track
•
•
•
•
•
Fall 2005
Date, Start Time, Stop Time
Interruption Time
Delta Time (interruption time removed)
Activity Name, Comments
Completed Task (check box), Units of Work Completed
EEE/GEF492
17-13
Time Recording Log – Instruction
TABLE C17 TIME RECORDING LOG INSTRUCTIONS
Fall 2005
Purpose
This form is for recording the time spent in each project phase.
These data are used to complete the Project Plan Summary.
General
- Record all the time you spend on the project.
- Record the time in minutes.
- Be as accurate as possible.
If you need additional space, use another copy of the form.
Header
Enter the following:
- Your name
- Today's date
- The instructor's name
- The number of the program
If you are working on a non-programming task, also enter a job description in the
Program# field.
Date
Enter the date when the entry is made.
Example
10/18/93
Start
Enter the time when you start working on a task.
Example
8:20
Stop
Enter the time when you stop working on that task.
Example
10:56
Interruption time
Record any interruption time that was not spent on the task and the reason for the
interruption.
If you have several interruptions, enter the total time.
Example
37 - Took a break
Delta time
Enter the clock time actually spent working on the task, less the interruption time.
Example
From 8:20 to 10:56, less 37 minutes, is 119 Minutes.
Phase
Enter the name or other designation of the phase or step being worked on.
Example
Planning, Coding, Test and so on.
Comments
Enter any other pertinent comments that may later remind you of any unusual
circumstances regarding this activity.
Example
Had a compiler problem and had to get help
Important
It is important to important to record all worked time. If you forget to record the starting,
stopping, or interruption time for a task, promptly enter your best estimate of the time.
EEE/GEF492
17-14
Defect Recording Log
TABLE C18 DEFECT RECORDING LOG
Student
Instructor
Date
Date
Program #
Number
Type
Inject
Remove
Fix Time
Fix Defect
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:
Date
Description:
Fall 2005
EEE/GEF492
17-15
PSP1 Process Script
• Planning
•
•
•
•
•
•
Produce or obtain a requirements statement
Estimate the software size and required development time (PSP1)
Complete the task plan (PSP1.1)
Complete the schedule plan (PSP1.1)
Enter initial project data in the project plan summary
Enter initial data in the time recording log
• Development
• Design, Implement, Compile, Test
• Collect test report data (PSP1)
• Collect time recording log data
• Postmortem
• Complete the project plan summary with actual time, defect, and
size data
• Complete the PIP
Fall 2005
EEE/GEF492
17-16
PSP2 Process Script
• Planning
•
•
•
•
•
•
•
Produce or obtain a requirements statement
Estimate software size and required development time
Estimate the required development time
Complete the task plan
Complete the schedule plan
Enter initial project data in the project plan summary
Enter initial data in the time recording log
•
•
•
•
•
Design, Implement, Compile, Test
Add design review and code reviews (PSP2)
Use design template where appropriate (PSP2.1)
Collect test report data
Collect time recording log data
• Development
• Postmortem
• Complete project plan summary with actual time, defect & size data
• Complete the PIP
Fall 2005
EEE/GEF492
17-17
PSP3 Process Script
• Planning
•
•
•
•
•
•
•
Produce or obtain a requirements statement
Estimate software size and required development time
Estimate the required development time
Complete the task plan
Complete the schedule plan
Enter initial project data in the project plan summary
Enter initial data in the time recording log
•
•
•
•
•
•
Design, Implement, Compile, Test
Add design review and code reviews
Use design template where appropriate
Use cyclic development with cycle summaries issue tracking (PSP3)
Collect test report data
Collect time recording log data
• Development
• Postmortem
• Complete project plan summary with actual time, defect & size data
• Complete the PIP
Fall 2005
EEE/GEF492
17-18
GOAL
• The quality of a software system is determined
by the quality of its worst components
• The quality of a software components is
determined by the quality of its developer’s
knowledge, discipline, and commitment
• As software professionals you should now how
to measure, track, and analyze your own
performance
• You should be able to learn from your past
failures and improve your personal practices.
Fall 2005
EEE/GEF492
17-19
An opinion on PSP
• PSP is a disciplined approach to SW development
• Valuable exercise to learn the benefits of:
• thorough design and code reviews; and
• defect prevention vs defect removal
• Some view it as being too cumbersome
• although there are tools available that can help you to go
through the process with less paperwork
• Many developers have created their own personal process
that suits their style
• Does not support iterative development
• Do the PSP training, learn from it, retain the
discipline, and define and practice your own version
Fall 2005
EEE/GEF492
17-20
CMM, TSP, PSP, and CSP
• CMM is about providing a guideline to
organisations to develop a maturity and a
capability in software development.
• Similarly PSP is about developing a capability
and maturity at the developer level.
• Between the two, CMM and PSP, there is Team
Software Process (TSP) which is about
developing a capability at the team level.
• There is also a Collaborative Software Process
(CSP) developed at U. of Utah in order to adapt
PSP to pair-programming.
PhD thesis – e.g. see http://oce.spsu.edu/cseet2002/Laurie-Williams2.pdf
Fall 2005
EEE/GEF492
17-21
Supplemental References
• Humphrey, Watt S.,
• Introduction to the personal software process,
Addison-Wesley, 1997
• A discipline for software engineering, AddisonWesley, 1995
• CMM, TSP, PSP
• visit http://www.sei.cmu.edu/
• CSP
• http://collaboration.csc.ncsu.edu/laurie/Papers/dissertation.pdf
Fall 2005
EEE/GEF492
17-22