1. Topic X Personal software process (PSP)
Topic X: Lecture Notes (instructions for the lecturer)
Author of the topic: Zivana Komlenov (Novi Sad)
Author of the lecture notes: Zivana Komlenov (Novi Sad), 3rd Apr 2005
About the subject of this topic:
The Personal Software Process (PSP) provides engineers with a disciplined personal framework for doing software work.
It consists of a set of methods, forms, and scripts that show software engineers how to plan, measure, and manage their work.
PSP is a self improvement process.
It’s purpose is to drive down defects before compile time and increase s/w estimating accuracy.
Logic for the PSP:
software professionals will better understand what they do if they define, measure and track their work
provides a defined process structure and measurable criteria for evaluating and learning from experience
with this knowledge and experience, they can select those methods and practices that best suit their particular tasks and abilities
using a customized set of orderly, consistently practiced, high quality personal practices, will make them more productive members of their development teams.
Remarks: -
To do:
Slides that could be improved or replaced:
Duration of the lecture:
History of changes
(with respect to previous version(s), slide numbers are from this version):
Parts of this topic use material from the textbook
W. S. Humphrey, “A Discipline for Software Engineering”, Addison-Wesley, 1995

2. Literature Watts S. Humphrey
“A Discipline for Software Engineering: The Complete PSP Book”
Addison Wesley, 1995.
Contents
Suggested reading.
Watts S. Humphrey
A Discipline for Software Engineering: The Complete PSP Book
This book scales down to a personal level the successful methods developed by the author to help managers and organizations evaluate and improve their software capabilities--methods comprising the Personal Software ProcessSM (PSPSM). The author's aim with PSP is to help individual software practitioners develop the skills and habits they need to plan, track, and analyze large and complex projects, and to develop high-quality products.
ISBN: , Addison Wesley, Hardcover, 816 pages
Introduction to the Personal Software Process
This workbook provides a hands-on introduction to the basic discipline of software engineering, as expressed in the author's well-known Personal Software Process (PSP). By applying the forms and methods of PSP described in the book, you can learn to manage your time more effectively and to monitor the quality of your work, with enormous benefits in both regards.
ISBN: , Addison Wesley Longman, Inc., Paperback, 304 pages
Watts S. Humphrey
“Introduction to the Personal Software Process”
Addison Wesley, 1997.

3. X. Personal software process (PSP)
PSP overview
PSP0 – PSP0.0 & PSP0.1
PSP1 – PSP1.0 & PSP1.1
PSP2 – PSP2.0 & PSP2.1
PSP3
PSP usage and results
Contents
Tutorial objectives:
to describe the personal software process (PSP)
to show where and how the PSP can be used to improve individual software engineering performance
to show how the PSP can enable software organizations to improve their capability
to describe the status and plans for the PSP.

4. PSP - Personal software process
“Software improvement must begin
at the individual level.”
Watts S. Humphrey
Awareness
Best practices
Commitment
Contents
Because personnel costs constitute 70 percent of the cost of software development, the skills and work habits of engineers largely determine the results of the software development process.
Methodology
Point out the appearing basic principles which developers have to acquire in order to improve the software they produce.

5. Watts S. Humphrey
A fellow at the SEI of Carnegie Mellon University, which he joined in 1986.
Established the Process Program, led initial development of the CMM, introduced the concepts of Software Process Assessment and Software Capability Evaluation, and most recently, the PSP and TSP.
From 1959 to 1986 he was associated with IBM Corporation where he was director of programming quality and process.
Watts S. Humphrey has been awarded the prestigious 2003 National Medal of Technology for his contributions to the software engineering community.
Contents
Watts S. Humphrey founded the Software Process Program of the Software Engineering Institute (SEI) at Carnegie Mellon University. He is a Fellow of the Institute and is a research scientist on its staff.
He holds a bachelor's degree in physics from the University of Chicago, a master's degree in physics from the Illinois Institute of Technology, and a master's degree in business administration from the University of Chicago.
He was awarded an honorary Ph.D. degree in software engineering by Embry Riddle Aeronautical University in 1998.
His publications include many technical papers and nine books. His most recent books are "Winning with Software: An Executive Strategy" (2001), "Managing the Software Process" (1989), "A Discipline for Software Engineering" (1995), "Managing Technical People" (1996), "Introduction to the Personal Software Process" (1997), and "Introduction to the Team Software Process" (2000).
Remarks
In 1991 Watts S. Humphrey served on the Board of Examiners for the Malcolm Baldrige Board of Examiners National Quality Award.
In 1993, the American Institute of Aeronautics and Astronauts presented Mr. Humphrey with the Aerospace Software Engineering Award.
Mr. Humphrey holds five U.S. Patents.
In 2000, the Watts Humphrey Software Quality Institute was named in his honor in Chennai, India, and the Boeing Company presented him with an award for leadership and innovation in software process improvement.
He is one of the ten influential men and women of software, according to the managing editor of CrossTalk magazine.

6. The software problem
Poor software quality in delivered systems is expensive
expensive service and enhancement
potential for accident or loss of life.
Organizational progress with process improvement is limited because
process improvement takes time / is hard to sell.
The PSP addresses these problems by
providing convincing evidence of the benefits of process improvement
exposing the engineers to the benefits of using effective processes in their work
teaching the engineers effective process improvement methods
providing the historical data to better manage cost, schedule, and quality.
Contents
Problems of improving the quality of software processes and how PSP addresses them.

7. Objectives for process improvement
schedule (delivery date)
Contents
Good-enough software:
Target is “feature-richness”.
Customer (marketing) decides the balance between schedule, functionality and quality.
Processes are dynamic, evolutionary.
Depend on best practices, e.g., user manual, peer reviews, daily build.
Depend on guerilla programmers.
functionality
(features)
quality
(defects)

8. Models for software process improvement
Contents
Models for software process improvement.
Remarks
Conclusion:
no best model, none is complete
people are key (managers, quality managers, developers)
bottom-up vs. top-down (cost, infrastructure)
reasons:
business requirement (certification)
productivity (better, cheaper, faster).
CMM U.S. DoD ISO Industry, professional
(c) 1998 Software Productivity Consortium MFP, Inc.

9. Quality umbrella CMM/CMMI - for organizational capability
TSP - for quality products on cost and schedule
Contents
Hierarchical relationship between the SEI initiatives:
PSP - process at the individual software engineer level. Provides specific guidance on how individual engineers can continually improve their performance.
TSP - process at the software engineering team level. Provides specific guidance about how PSP-trained engineers can work as effective team members.
CMM - process at the organization level. Focuses on what organizations should do, it does not specify how to reach those goals.
Based on practices found in the Capability Maturity Model (CMM), the PSP can be used by engineers as a guide to a disciplined and structured approach to developing software.
The PSP is a prerequisite for an organization planning to introduce the TSP.
Remarks
CMM:
Developed by Software Engineering Institute (SEI), Carnegie Mellon
Funded by U.S. DoD, concerned with late and cancelled contracts (A12, $58 billion)
For large projects, contractors must be assessed at Level 3 or DoD equivalent (October 1999)
Capability Maturity Model for Software (SW-CMM) v1.1, February 1993.
PSP - for individual skill and discipline
Adapted From “Three Dimensions of Process Improvement,” Watts Humphrey, CROSSTALK, February 1998

10. What is PSP? PSP is a framework of techniques to help software
engineers improve their performance.
PSP is a self-improvement process designed to help control,
manage, and improve the way you work.
It is a structured framework of forms, guidelines, and
procedures for developing software.
(PSP as introduced in 1995 by its author, Watts S. Humphrey, SEI)
PSP
takes those large scale project methods and practices which can be used by individuals,
structures them so that they can be introduced gradually, and
provides a framework for teaching them.
Contents
The PSP is based on process improvement principles:
software engineers establish personal process goals
they define the methods to use
they measure their work
they analyze the results
based on the results, they adjust their methods to improve towards personal goals.
PSP provides engineers with a disciplined personal framework for doing software work.
Provides a set of methods, forms, and scripts that show how to plan, measure, and manage the work.
Emphasizes effort estimation & software quality.
PSP is designed for use with any programming language or design methodology.
Can be used for any aspect of software development.
Provides a rapid way to infuse each engineer with software engineering skill and experience.
Goal – produce zero defect products on schedule and within planned costs.
Key – ability to recognize and handle undue pressures.
Remarks
Software engineers develop their personal practices when they first learn to write programs. Since they are given little or no professional guidance on how to do the work, most engineers start off with exceedingly poor personal practices. As they gain experience, some engineers may change and improve their practices, but many do not. In general, the highly varied ways in which individual software engineers work are rarely based on a sound analysis of available methods and practices.
Engineers are understandably skeptical about changes to their work habits; although they may be willing to make a few minor changes, they will generally stick fairly closely to what has worked for them in the past until they are convinced a new method will be more effective. This, however, is a chicken-and-egg problem: engineers only believe new methods work after they use them and see the results, but they will not use the methods until they believe they work.

11. CMM and the PSP *PSP key practices Level 5 Level 4 Level 3 Level 2
Process change management*
Technology innovation*
Defect prevention*
Level 4
Quality management*
Process measurement and analysis*
Level 3
Peer reviews*
Intergroup coordination
Software product engineering*
Integrated software management*
Training program
Organization process definition*
Organization process focus*
Contents
The capability maturity model (CMM) was developed by the SEI with the help of leading software groups.
The CMM characterizes the most effective large-scale software practices.
Capability Maturity Matrix
Broadly agree to define how a software organization matures and improves.
Based on manufacturing process improvement and “best practices” from software engineering.
Some dramatic successes...
Developed by the Software Engineering Institute (SEI) by Watts Humphrey and Mark Paulk.
Five levels of maturity for an organization
Level 1 - Initial
Level 2 - Repeatable
Level 3 - Defined
Level 4 - Managed
Level 5 - Optimizing.
CMM Levels are cumulative – to achieve each higher level, all of the previous requirements still apply.
Level 0 means that some or all key activities are not being performed.
Level 1 means that key activities are being performed, but in a chaotic or uncontrolled manner.
Level 2 means that key activities are planned and controlled for at least a single project.
Level 3 means that key activities are planned and controlled for an entire organization (multiple projects).
Level 4 means that activities are so well predicted, they are statistically controlled.
Level 5 means that you keep reaching for new and better ways of improving your activities.
There are 18 key process areas defined by CMM, including:
Requirements Management
Software Configuration Management
Process Change Management
Defect Prevention.
Each key process area has five common features:
1) goals to be achieved
2) ability to perform
3) activities performed
4) measurement and analysis
5) verification.
The PSP address’s 12 of the SW-CMM 18 KPA’s. For this reason, PSP sometimes referred to as a “Level 5” process.
Remarks
CMM provides the framework for effective process management.
CMM assumes that the software professionals will follow disciplined personal methods.
PSP provides the framework for disciplined individual work.
PSP assumes effective process management.
Level 2
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight*
Software project planning*
Requirements management
*PSP key practices
Level 1
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

12. PSP evolution Cyclic Personal Process Personal Quality Management
Cyclic development
Cyclic Personal Process
PSP2.1
Design templates
PSP2
Code reviews
Design reviews
Personal Quality Management
PSP1.1
Task planning
Schedule planning
Personal Planning Process
PSP1
Size estimating
Test report
Contents
Since the PSP process has a number of methods that are not generally practiced by engineers, the PSP methods are introduced in a series of seven process versions.
These versions are labeled PSP0 through PSP3, and each version has a similar set of logs, forms, scripts, and standards.
PSP0.1
Coding standard
Size measurement
Process improvement
proposal (PIP)
Baseline Personal Process
PSP0
Current process
Time recording
Defect recording
Defect type standard
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

13. PSP process flow Requirements PSP Process Planning Development Process
scripts
Project
plan
summary
Finished product
Project and process
data summary report
Time
and
defect
logs
PSP Process
Development
Planning
Design
Code
Compile
Test
Design review
Code review
Postmortem
guide
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995
Contents
PSP is an iterative process, a combination of best practices at the personal level.
It is broken up into phases:
Planning
Design
Code
Compile
Test
Postmortem
Each level defines different entry/exit criteria of each phase.
Each level has 1-2 programs to develop to implement the process.

14. PSP courses The “full” PSP course:
industry course: 3 intensive weeks (60 hours per week)
academic course: 12 to 15 weeks (3 hours per week)
includes 10 programming assignments and 5 reports
course results similar in industry and academia
uses A Discipline for Software Engineering [Humphrey 1995].
The “introductory” PSP course:
does not teach the complete PSP
is often offered as part of a project management course
may start in the 1st year of a computing degree
uses Introduction to the Personal Software Process [Humphrey 1997].
Contents
PSP course
Directly exposing the engineers to the new way of working (through a rigorous training course).
Following prescribed methods (PSP process evolution, represented as levels PSP0 through PSP3).
With each exercise, gradually introducing various advanced software engineering methods.
Has been shown to substantially improve the estimating and planning ability of engineers while significantly reducing the defects in their products.

15. X. Personal software process (PSP)
PSP overview
PSP0 – PSP0.0 & PSP0.1
PSP1 – PSP1.0 & PSP1.1
PSP2 – PSP2.0 & PSP2.1
PSP3
PSP usage and results
Contents
With PSP0, engineers use their current design and development methods.
They gather data on their work:
the time spent by phase
the defects found in compile and test.
They analyze and report these data.
With PSP0, engineers learn to use a basic personal process:
they gather data on their personal work and personal processes
they learn how and why to measure the sizes of the products they produce.

16. PSP0 – the baseline personal process
Provides a convenient structure for small-scale tasks.
Has three phases: planning, development (which includes design, code, compile, and test), and postmortem.
Uses scripts and logs to measure the normal software development life cycle (design, code, compile, test).
Forms are used to ensure a consistent and complete reporting of needed information.
Basic measurements include the time for each phase, and the defects found and removed.
The net result, other than the actual software, is a Plan Summary which compares the planned effort to the actual effort, and contains defect data.
Contents
PSP0 is where the PSP starts.
Software engineers gather real, practical data for deriving benchmarks against which they measure progress.
A foundation for process improvement.

17. PSP0 - tasks Define current process (PSP0.0) Time recording (PSP0.0)
Defect recording (PSP 0.0)
Defect type standard (PSP0.0)
Code standard (PSP0.1)
Size measurement (PS0.1)
Process improvement proposal or PIP form (PSP0.1)

18. PSP0 – current process script
Planning:
produce a requirement statement
estimate the required development time
estimate the total LOC (PSP0.1)
enter initial project data in the project plan summary
enter initial project data in the time recording log.
Development:
4 steps (PSP0.1), collect time recording log data.
The last step: postmortem phase (PM)
enter the plan summary form with actual data
complete the PIP (PSP0.1).
Delivery of the finished product with forms.
Remarks
The goal-question-metric (GQM) paradigm introduced by Basili was used to define the measures used in the PSP.
The basic PSP measures are the time the engineer spends in each process phase, the defects introduced and found in each phase, and the sizes of the products developed in lines of code (LOC).
The principal measures are:
size and time estimating error
cost performance index
defects injected and removed per hour
process yield
appraisal and failure cost of quality (COQ)
the appraisal to failure ratio (A/FR).

19. PSP0.0 – time recording log
Contents
The PSP measures effort as time in minutes:
appropriate for small programs
easy to measure precisely.
You keep accurate records of time spent on each programming task.
A Time Recording Log is used for this purpose.
Interruption time is recorded and subtracted from time spent on development tasks.
Goal: time in earlier phases needs to be increased, time in later phases decreased.
Correcting compile defects is compile time.
Correcting test defects is test time.
Strictly count time per phase.
Date - enter the current date (e.g., 9/5/03).
Start - enter the time in minutes (e.g., 11:25 am) when you start a project phase.
Stop - enter the time in minutes when you stop work on a project phase, even if you are not done with that phase.
Interruption time - enter any time you lost due to interruptions in the start to stop period. (e.g., 15 minute coffee break).
Phase - note the phase on which you were working.
Comments – describe the interruption, the task you were doing, or anything else that significantly affects your work.
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

20. Defects: basic quality measure
Defects are not important to the user as long as they do not:
affect operations
cause inconvenience
cost time or money
cause loss of confidence in the program’s results.
Low defect content is essential to a quality software process. (Experienced software engineers typically inject around 100 defects per KLOC.)
Defects are injected at the ‘PSP level’ and this is where the engineers should: remove them, determine their causes and learn to prevent them.
Contents
The principal PSP quality objective is to find and fix defects before the first compile or unit test.
The PSP process includes design and code review steps in which engineers personally review their work products before they are inspected, compiled, or tested.
The principle behind the PSP review process is that people tend to make the same mistakes repeatedly. Therefore, by analyzing data on the defects they have made and constructing a checklist of the actions needed to find those mistakes, engineers can find and fix defects most efficiently.
If you want a quality product out of test, you must put a quality product into test:
testing removes only a fraction of the defects
test is only meant to find defects - correction goes to developers.
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 per 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 as unit test.
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 2.21 defects found per hour in unit testing.
By using PSP data, engineers can both save time and improve product quality. For example, from average PSP data, the time to remove 100 defects in unit testing is 45 hours while the time to find that number of defects in code reviews is only 15 hours.

21. PSP0.0 – defect recording log
Contents
A PSP defect is something that must be changed to correct an error made in a software artifact (design, code, etc.) classified according to a defect type standard.
For each defect, students record the defect type, a description of the defect, and the fix time.
All changes related to a single error are counted as one defect.
Fix time is recorded in the phase in which the defect is removed (e.g., compile or test).
A Defect Recording Log is used for this purpose.
Date - enter the date when you found and fixed the defect.
Number - enter a unique number for this defect. Start each project with 1.
Type - enter the defect type from the defect type standard.
Inject - enter the phase in which you judge the defect was injected.
Remove - enter the phase in which you found and fixed the defect.
Fix time - enter the time you took to fix the defect. You may time it exactly or use your best judgment.
Fix defect - if this defect was injected while fixing another defect, enter the number of that defect or an X if you do not know.
Description – describe each defect well enough so you can later figure out how to prevent it or how you could have found it earlier.
Strictly count defects per phase.
Type of defect is important for causal analysis.
Recording fix times is critical for later estimation.
Multiple defects are kept separate.
Remarks
While software quality involves many more aspects than defects, defect detection and prevention are a principal focus of the PSP. Finding and fixing defects typically takes a major part of development time and expense.
The principal PSP quality measure is yield. Total process yield is the percentage of defects that are found and fixed before the engineer starts to compile and test the program.
Process yield = 100 * x/(x+y)
x = all defects found before compile and test
y = net defects escaped before compile and test.
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

22. PSP0.0 – defect type standard
Type Number
Type Name
Description 10
Documentation
comments, messages 20
Syntax
spelling, punctuation, typos, instruction formats 30
Build, Package
change management, library, version control 40
Assignment
declaration, duplicate names, scope, limits 50
Interface
procedure calls and references, I/O, user formats 60
Checking
error messages, inadequate checks 70
Data
structure, content 80
Function
logic, pointers, loops, recursion, computation, function defects 90
System
configuration, timing, memory
100
Environment
design, compile, test, or other support system problems
Contents
The defect type standard provides a general set of defect categories.
While you may replace this standard with your own, it is generally wise to stick with simple type definitions until you have data to guide your changes.
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

23. PSP0.1 - product size estimation
To make better plans.
To assist in tracking development.
To normalize other measures:
development resources
defect rates.
Size data is used in estimating development time and the expected number of defects.
There are a number of criteria for good size measures:
has good correlation with effort
has a precise definition
can be counted automatically
is suitable for planning
is sensitive to language, design, and development method.
LOC measure satisfies most of those criteria.
Contents
Size estimates of the product need to be repeated during the life cycle to help ensure the product isn’t growing forever.
Software size estimates are often based on Lines of Code (LOC).
The size of code produced for a given purpose is best predicted by past experience with similar projects.
Barring that, other analytical methods can be used, such as expert estimates, function points, etc.

24. Counting program size Logical lines Physical lines The PSP
invariant to editing changes
correlate with development effort
uniquely definable
complex to count.
Physical lines
easy to count
not invariant
not uniquely definable.
The PSP
uses a physical line for each logical line
uses a defined coding standard
this standard must be faithfully followed.
Then physical line counting equals logical line counting.
Contents
The PSP uses LOC for measuring size.
There are various ways to define and interpret the meaning of a line of code.
A physical LOC count is the number of non-blank, non-comment lines of source code.
A logical LOC count is related to a program’s logical content, but it depends on the programmer’s definition of a logical line of code.
For simplicity, the PSP uses a coding standard that requires each logical LOC to use one physical line.

25. LOC type definitions LOC accounting Code metrics
LOC of actual program changes during development. LOC are added, deleted, modified, or reused.
Productivity is then the number of LOC divided by the number of hours needed to produce it.
Code metrics
(B) Base – LOC from a previous version
(D) Deleted – Deletions from the Base LOC
(M) Modified – Modifications to the Base LOC
(A) Added – New objects, functions, procedures, or any other added LOC
(R) Reused – LOC from a previous program that is used without modification
(N) New & Changed – The sum of Added and Modified LOC
(T) Total LOC – The total program LOC
Total New Reused – New or added LOC that were written to be reusable
Remarks
Checks:
N=A+M
A=(T-(B-D)-R)

26. PSP0 – project plan summary
Contents
The project plan summary form holds:
project plan data
actual project results
size
times
defect data
cumulative data on all PSP projects to date.
For PSP0 there is only one planning estimate: total minutes.
Everything else (time in phases, defects injected, defects removed) is postmortem activity.
Time - To Date - enter the total time spent in each phase to date.
Time - To Date % - enter the percent of the total To Date time that was spent in each phase.
Defects injected and removed - enter the actual numbers of defects injected and removed in each phase.
Defects - To Date - enter the total defects injected and removed in each phase to date.
Defects - To Date % - enter the percent of the total To Date defects injected and removed in each phase.
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

27. PSP0.1 – process improvement proposal (PIP)
“The process is your servant. If it does not help you, you must change it.”
Describe problems encountered on this project.
List difficulties, problems, and their impact.
Describe proposals for process improvement.
Add overall comments about the project.
Lessons learned.
Conditions you need to remember to determine why the process worked particularly well or poorly.
Contents
The process improvement proposal (PIP) is used to record process problems and proposed improvements for future reference.
The PIP holds process improvement information:
PIP number
problem description
proposed solution
notes and comments.
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

28. PSP0 process script purpose inputs required process phases
Remarks
Scripts guide the engineers through the process:
purpose
inputs required
process phases
exit criteria.

29. X. Personal software process (PSP)
PSP overview
PSP0 – PSP0.0 & PSP0.1
PSP1 – PSP1.0 & PSP1.1
PSP2 – PSP2.0 & PSP2.1
PSP3
PSP usage and results
Contents
With PSP1, engineers estimate the sizes and development times of the work they produce:
they use their historical data to improve their estimates
they project the likely statistical ranges of their estimates and learn how to reduce these ranges.

30. PSP1 – personal project management
PSP1.0 introduces size and effort estimating, and test report to PSP0.1.
PSP1.1 adds resource and schedule estimation.
Accumulated more project data, the estimation will become progressively more accurate.
Tasks:
size estimating (PSP1.0)
test report (PSP1.0)
task planning (PSP1.1)
schedule planning (PSP1.1).
Contents
PSP1 adds planning steps to PSP0.
The initial step adds size and resource estimation and a test report.
The Proxy Based Estimation (PROBE) method is introduced.
Schedule and task planning are added in PSP1.1.

31. Size estimating principles
Estimating is an uncertain process
no one knows how big the product will be
the 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 and data
some people will be better at estimating than others.
Estimating is a skill
improvement will be gradual
you may never get very good.
The objective, however, is to get consistent
you will then understand the variability of your estimates
you seek an even balance between under and over estimates.
Contents
Estimate of the size of a project:
lines of code
function points
person-months.
Based on requirements and experience or mathematical model.
To make better plans:
to better size the job
to divide the job into separable elements.
To assist in tracking progress:
can judge when job scope changes
can better measure the work.
Value for the PSP:
learn estimating methods
build estimating skills.

32. Project planning framework
Define the
requirements
Produce the
conceptual
design
Estimate the
product size
resources
schedule
Develop the
product
Size, resource,
schedule data
Analyze the
process
Resources
available
Productivity
database
Size
Items
Tasks
Customer
need
Delivered
Tracking
Reports
Management
The PROBE Method
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995
Contents
Requirements: define the work as detailed as possible, it is the basis for the plan.
Conceptual design: a first, rough guess of the product based on engineers’ current knowledge. Planning phase is too early to produce a complete product design.
Estimate product size and resources: the correlation of program size with development time is quite high for individuals, so they can estimate the time required. The PROBE method usage.

33. Size estimating proxies
The basic issue
good size measures are detailed
early estimators rarely can think in detail.
Alternatives
wait to estimate until you have the detail
make your best guess
identify a suitable proxy.
A good proxy should correlate closely to development costs.
A good proxy would be easy to visualize early in development.
It should also be a physical entity that can be counted.
Example proxies: function points, objects, product elements (components; screens, reports, scripts, files; book chapters).
Remarks
Proxy
A person authorized to act for another; an agent or substitute.
The authority to act for another.
The written authorization to act in place of another.

34. PSP1.0 - size estimating with PROBE
Conceptual
design
Start
Identify objects
Number of
methods
Object
type
Relative
size
Reuse
categories
Calculate added and
modified LOC
Estimate
program size
Calculate
prediction interval
Result?
PROBE = PROxy Based Estimating
Requirements of Proxy: correlated with effort, can be estimated during planning, can be counted in the projects.
OO languages: relative size of objects and their methods
procedural languages: functions or procedures.
Use relative size of Proxy to make initial estimate.
Use historical data to convert the relative size of Proxy into LOC.
Determine the overall size using linear regression.
Contents
PROxy Based Estimation – uses proxies or objects as the basis for estimating the likely size of the product.
Answers to the questions
Result – Estimate for size of program, total development time, and the time required for each development phase.
Remarks
Humphrey created PROBE for small, one person efforts. However, it can be modified for larger efforts and teams of engineers.
PROBE was designed around and uses “lines of code” LOC’s and KLOC’s as the basis for measuring product size and effort size. If this isn’t appropriate for your needs, it can be easily modified for:
objects, database tables
function points, screens
or other levels of granularity (slides in a presentation, pages in a book, etc.).
Strengths:
forces you to keep good historical data - then use it
quantitative and very visible estimates
works well at the individual - small effort level.
Weaknesses:
not very collaborative - losing a sense of team based estimation
doesn’t work without historical data - and of the right “type”
doesn’t scale very well to larger efforts - you lose the “team perspective”
doesn’t help with task sequencing nor exposing “peripheral” items.
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

35. Size estimating template
Guides the estimating process
Holds the estimate data
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

36. Why are resource and schedule plans needed?
The PSP1.1 process
The objectives of PSP1.1 are to introduce and practice methods for:
making resource and schedule plans
tracking performance against these plans
judging likely project completion dates.
There are two new process elements:
task planning template
schedule planning template.
Adds time estimation to size estimation.
Determines tasks.
Breaks out available project time by week.
Plans the task sequence.
Sets task schedule.
Methodology
Depending on the personal lecture style one may first ask the audience for possible answers.
Answers to the questions
Provide a business basis for doing the work
establish the price
set the schedule
permit agreement on the work.
Establish a management framework
define commitments
help groups coordinate their work
allow status tracking.
Why are resource and schedule plans needed?

37. 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.
You then need to
estimate the hours needed for each task
spread these hours over the calendar of available hours.
identify key project checkpoints
use a standard format.
Contents
To estimate the hours for each task consider:
what portion of total hours have such tasks historically taken?
will anything unusual affect this project?
to ensure tasks are not omitted, spread the task time for the entire project.

38. Example: task planning template#
Name
Hours PV CH
CPV
Date EV
CEV 1
Plan 5 6
5/1 2
Design 25 31 30 37
5/22 3
Code 15 19 45 56
5/28 4
Test 38 75 94
5/31
Post 80
100
6/2
Total
Contents
Assign each task a number and enter on form.
Estimate hours required for this task (Plan).
Sum total hours for project and calculate cumulative hours (Plan).
Compute planned value = task hours/total hours.
Calculate Cumulative Planned Value.
How many?
1/week too few
1/day too many
2-4/week OK.
When task is completed
enter date completed
enter EV taking the plan value
compute the cumulative EV.
Tracking the plan
As each task is completed, it earns the planned value
enter this earned value (EV) for that task
enter the date of task completion
add the EV to date in the cumulative EV column.
Remarks
The purpose of earned value is to
establish a value for each task
permit progress tracking against the plan
facilitate tracking even with plan changes.
The principles behind earned value are
it provides a common value for each task
this value is the percent of total project hours this task is planned to take
no value is given for partial task completion
major plan changes require new plans.
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

39. Example: schedule planning template
Week
Date DH CH
CPV
ADH
ACH
CEV 1
5/1 10 6 2
5/8 5 15 3
5/15 25 4
5/22 50 56
5/29 30 80
100
Contents
Records estimate and actual hours expended by calendar period.
Contains:
week number for each week
calendar date for each week
planned hours on that week and the total hours
actual hours.
Earned value methods can help track progress, to balance
the amount of work accomplished (the amount of value earned)
the effort used (labor hours)
the cost expended ($).
Tracking the plan
Enter the cumulative EV for each week as it is completed.
Track earned value versus planned value by week.
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995
Hours Avail = 40 *.25 = 10

40. PSP1.1 additions The PSP is augmented to include
resource estimating: already covered
schedule estimating: already covered
a new project plan summary.
The project plan summary adds
the cost performance index (CPI) as a measure of the degree to which projects are completed within planned cost
reuse data - reuse measures are % reused and % new reused.
Remarks
The cost performance index (CPI):
an index of around 1.0 is most desirable
an index of less than 1.0 indicates that projects are costing more than planned
an index of more than 1.0 indicates that projects are costing less than planned
if the index is much more than 1.0, it indicates overly conservative planning.
The reuse measures:
A high value of % reused is desirable
resources are concentrated on developing new products
resources are not spent on redeveloping existing products.
A high value of % new reused indicates that a high percentage of the new and changed LOC are planned for future reuse.

41. PSP1 – process script Planning Development Postmortem
Produce or obtain a requirements statement.
Estimate the software size and required development time (PSP1.0).
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.

42. X. Personal software process (PSP)
PSP overview
PSP0 – PSP0.0 & PSP0.1
PSP1 – PSP1.0 & PSP1.1
PSP2 – PSP2.0 & PSP2.1
PSP3
PSP usage and results
Contents
With PSP2, engineers use their historical data to improve the quality of the program modules they produce:
they measure the efficiency of their defect removal methods
they use various process quality measures, including yield, COQ (cost of quality), and A/FR (appraisal/failure ratio).

43. PSP2 – personal quality management
“The way to write a perfect program is to make yourself a perfect programmer and then just program naturally.”
Bugs are engineered in - they aren’t caught like a cold.
Goal: find and remove all defects before the first compile --- yield = 100%
New steps: design review & code review
Detailed process
During planning, estimate the number of defects that will be injected and removed in each phase.
Use historical correlation between review rates and yield to plan effective and efficient reviews.
During development, control quality by monitoring the actual defects versus planned and by comparing actual review rates to established limits.
Contents
PSP2 introduces the concept of defect prevention through defect management.
PSP2 focuses on quality from the start and how to efficiently review programs.
The use of checklists can help effectively review design and code. Checklists are continually improved as personal skills and practices evolve.

44. What are reviews?
A review is a way to personally examine your own work.
Needed to help find and eliminate defects before those mistakes get passed on to the rest of the life cycle.
It is one of a family of methods
inspections
walkthroughs
reviews.
Much more cost effective at finding defects than testing.
Remarks
After defects are found, they can often be fixed immediately.
Need to remember to verify that the fixes worked, or else additional defects may be introduced!
Reviews can be measured to determine their efficiency. What percent of the defects were found during the review? Answer is the percent yield.
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 6 to 10 defects per 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 as unit test.
After unit test, defect removal becomes much more expensive
in integration and system test it takes 10 to 40 programmer hours to find and fix each defect
inspections typically take less than an hour per defect.
The reason to eliminate defects as early as possible is because
every review, inspection, compile, and test finds only a fraction of the defects
thus, the cleaner the code entering a phase, the cleaner it will be on exit.

45. Review measures Explicit measures Derived measures
the size of the program being reviewed
the review time
the numbers of defects found
the numbers of defects not found: the escapes.
Derived measures
review yield: %found
LOC reviewed per hour
defects found per KLOC
defects found per review hour
review leverage.

46. Review yield Yield yield(for a phase or the entire process) =
a measure of process quality
the percent of defects in the product at review time that were found by the review
measures the effectiveness of a process step
design and code reviews
the overall process - prior to test
the development process - including test.
yield(for a phase or the entire process) =
100*(defects found)/(defects found + not found)
Contents
Yield cannot be calculated until all defects have been found through test and product use.
Yield can be useful early in the process if all or most defects are counted:
design and code review defects
compile defects
unit test defects.
Using process data, control parameters can help to ensure high yield reviews.
Remarks
The goal of PSP reviews is to get consistently high yield.
Review yield: the percentage of defects in the product at review time that were found by the review.
Process yield: the percentage of defects found before the first compile.
With practice, students can achieve consistently high process and review yields of around 70% to 80%.

47. Review considerations
Checklists
Define the review steps in the order suggested for performing them. By checking off each item, you are more likely to perform it properly.
Reviewing before or after compile
The PSP calls for code reviews before the first compile. If too many defects are found in compile, another review is called.
The relationship of reviews and inspections
The principal focus of inspections should be to find those requirements and design problems that you have missed.
Remarks
Establish a personal checklist that is customized to your defect experience.
The reasons for code reviews before the first compile are:
review time is about the same whether done before or after compile
code reviews will find syntax defects that the compiler misses
code reviews of compiled code tend to be much less effective
the compiler is equally effective before or after reviews.
Reviews and inspections - reviewing the code first
provides a quality product for the inspection
shows respect for the inspectors’ time
produces higher quality inspections.

48. Example: PSP2.0 - code review process
Phases include:
review
correct
check.
Each student should design their own checklist so that it supports their review process.
Contents
PSP2.0 – code reviews
Check variable and parameter initialization
Check name and spelling use
Is it consistent?
Is it within the declared scope?
Check strings
Identified by pointers and NULL terminated
Verify all files
Properly declared
Properly opened and closed …
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

49. Example: PSP2.0 - design review checklist (C++)
completeness
logic
special cases
functional use
names
standards
Contents
PSP2.0 – design reviews
Ensure the requirements, specification and high-level design are completely covered
Verify program logic
Check all special cases
Verify function use
Verify names
Review the design for conformance to all applicable design standards …
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

50. PSP2.1 - software design
Review is quite effective for eliminating most defect, but better quality designs are needed.
There are six new process elements:
PSP2.1 project plan summary
PSP2.1 design review checklist
operational scenario template
functional specification template
state specification template
logic specification template.
Examines and documents the design from different perspectives.
Contents
The objectives of PSP2.1 are to introduce:
additional measures for managing process quality
design templates that provide an orderly framework and format for recording designs.
Design is often iterative, among these steps:
identify user and system requirements
analyze and clarify requirements
propose high level design
validate design against requirements
document the design
expand high level design into low level design.
Remarks
Designs can be expressed in math-like logical languages, visual models, and/or in plain text.
Specific templates for object oriented design are included in the PSP.
The requirements must parallel design - they will often not be completely understood until you have a working product.
Each design level debugs higher level designs
the specification debugs the requirements
the high-level-design debugs the specification
the detailed design debugs the high-level design
the implementation debugs the detailed design.

51. Design dimensions Object Specification Internal External Static
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995
Object
Specification
Internal
External
Static
Attributes
Constraints
Inheritance
Class Structure
logic specification
template
functional
specification
template
Dynamic
Remarks
Four design templates are used in the PSP:
logic specification template - static, internal
state specification template - dynamic, internal
functional specification template - dynamic and static, external
operational scenario template - dynamic, external.
State Machine
Services
Messages
state specification
template
operational scenario
template

52. PSP2 – process script Development Planning Postmortem
Produce or obtain a requirements statement.
Estimate software size and required development time (PSP1.0).
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.
Add design review and code reviews (PSP2).
Use design template where appropriate (PSP2.1).
Collect test report data (PSP1.0).
Collect time recording log data.
Postmortem
Complete the project plan summary with actual time, defect, and size data.
Complete the PIP.

53. X. Personal software process (PSP)
PSP overview
PSP0 – PSP0.0 & PSP0.1
PSP1 – PSP1.0 & PSP1.1
PSP2 – PSP2.0 & PSP2.1
PSP3
PSP usage and results
Contents
PSP3 is the final PSP step.
To this point, PSP has been a linear process for building small programs.
The PSP3 process introduces methods for individuals to use when they are developing larger-scale programs.
However, it does not deal with the communication and coordination problems that are an important part of larger-scale system development.

54. PSP3 – cyclic process
Efficiently scales the PSP up to larger projects without sacrificing quality or productivity.
Cyclic development strategy: decompose large programs into parts, develop and integrate them.
PSP3 introduces:
high-level design and design review
cycle planning
development cycles based on the PSP2.1.
Incremental development.
Contents
PSP3 - scaling up the PSP
Large systems can be broken down into smaller logically separate parts, where the interaction among the parts is knowable.
This can be repeated until the smaller parts are small enough to apply the PSP.
Scaling up the PSP
scalability principles
handling software complexity
development strategies.

55. Scalability stages stage 0 - simple routines stage 1 - the program
stage 2 - the component
stage 3 - the system
stage 4 - the multi-system.
Remarks
A product development process is scalable when the methods and techniques used will work equally well for larger projects.
Scalability typically
is limited to similar application domains
does not apply to unprecedented systems
does not work for poorly managed projects
is unlikely to apply where the engineering work is undisciplined.
Scalability requires that the elements of larger projects behave like small projects.
The product design must thus divide the project into separately developed elements.

56. Scalability stage 0 Stage 0 is the basic construct level.
It concerns the construction of loops, case statements, etc.
Stage 0 is the principal focus of initial programming courses.
At stage 0, you consciously design each programming construct.
When your thinking is preoccupied with these details, it is hard to visualize larger constructs.

57. Scalability stage 1
Stage 1 concerns small programs of up to several hundred LOC.
Movement from stage 0 to stage 1 naturally occurs with language fluency.
You now think of small programs as entities without consciously designing their detailed constructs.
As you gain experience at stage 1, you build a vocabulary of small program functions which you understand and can use with confidence.

58. Scalability stage 2 Stage 2 is the component level.
Here, multiple programs combine to provide sophisticated functions.
Stage 2 components are typically several thousand LOC.
The move from stage 1 to stage 2 comes with increased experience.
You can now conceive of larger programs than you can possibly build alone.
At stage 2, system issues begin to appear: quality, performance, usability, etc.

59. Scalability stage 3
Stage 3 systems may be as large as several million LOC.
Here, system issues predominate
the components must work together
the component parts must all be high quality .
The move from stage 2 to stage 3 involves
handling program complexity
understanding system and application issues
working in a team environment.
At stage 3, the principal emphasis must be on program quality.

60. Scalability stage 4
Stage 4 multi-systems may contain many millions of LOC.
Multiple semi-independent systems must work together.
Quality is paramount.
The move from stage 3 to stage 4 introduces large scale and distributed system issues as well as problems with centralized control.
Stage 4 requires semi-autonomous development groups and self-directing teams.

61. The scope of scalability
Module C
Module B
Module A
Module F
Module E
Module D
Module I
Module H
Module G
Module L
Module K
Module J
Module O
Module N
Module M
Component X
Component Y
Product Z
Large
Project
Medium
Projects
Contents
In scaling up from the module level to the component level
you seek to maintain the quality and productivity of the module level work
the component level work is new and thus cannot be scaled up.
In scaling up to the product level
you seek to maintain the quality and productivity of the component level work
the product level work is new and thus cannot be scaled up.
Small
Projects
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

62. The cyclic PSP flow High-level Design Requirements & Planning HLD
Review
Integration
System test
Post-
mortem
Cyclic
Development
Specifications
Product
Detailed Design &
Design Review
Specify
Cycle
Test Development
and Review
Test
Compile
Implementation
and Code Review
Reassess
and Recycle
Contents
The cyclic PSP provides a framework for using a cyclic development strategy to develop modest sized programs.
It is a larger process that contains multiple PSP2.1-like cyclic elements.
The PSP requirements, planning, and postmortem steps are done once for the total program.
High-level design partitions the program into smaller elements and establishes the development strategy.
The development strategy determines the cyclic steps
element selection
the testing strategy.
The process ends with integration and system test, followed by the postmortem.
W. S. Humphrey,
“A Discipline for Software Engineering”, 1995

63. PSP3 – new elements Cycle summary Issue tracking log
size / development time / defects for each cycle
one copy to record cycle plans, another to enter actual cycle result.
Issue tracking log
Documents the issues, problems and open questions that may affect future or completed cycles.
Project plan summary
two phases are added:
high-level design
high level design review.

64. PSP3 – process script Development Planning Postmortem
Produce or obtain a requirements statement.
Estimate software size and required development time (PSP1.0).
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.
Add design review and code reviews (PSP2.0).
Use design template where appropriate (PSP2.1).
Use cyclic development with Cycle Summaries and Issue Tracking Log (PSP3).
Collect test report data (PSP1.0).
Collect time recording log data.
Postmortem
Complete the project plan summary with actual time, defect, and size data.
Complete the PIP.

65. X. Personal software process (PSP)
PSP overview
PSP0 – PSP0.0 & PSP0.1
PSP1 – PSP1.0 & PSP1.1
PSP2 – PSP2.0 & PSP2.1
PSP3
PSP usage and results

66. PSP results CMU 94 data Contents
Product
Best Practices
Processes
PSP3
Cyclic Development
Design Templates
PSP2.1
Product
Quality
Code Review
Design Review
PSP2
Product
Development
Task Planning
Schedule Planning
PSP1.1
Size Estimating
Test Report
PSP1
Schedule &
Cost
Process Quality
Coding Standard
Size Measurement
Process Improvement
PSP0.1
Contents
These data are for 12 students who took the PSP course at Carnegie Mellon University in the spring of 1994.
The data are on:
compile time
test defects
productivity.
Time Recording
Defect Tracking
Defect Type Standard
PSP0
Direct Feedback
Analysis
Synthesis
Data
CMU 94 data

67. Compile time range
14 hours to 3 hours
CMU 94 data

68. Defects found in test - range
39 Errors to 1 on average
CMU 94 data

69. Productivity range Big drop in defects Big potential increase
in productivity
CMU 94 data

70. Actual time range
CMU 94 data

71. PSP evaluation Humphrey - using PSP in SE courses:
Claims that PSP “substantially improves engineering performance in estimating accuracy and early defect removal while not significantly affecting productivity”.
Provided charts to prove that as PSP exposure continues results, quality of work improves.
Estimation accuracy increased considerable.
Number of defects introduced per 1000 lines of code (KLOC) decreased by a factor of two.
Number of defects per (KLOC) to be found late during the development decreases by a factor of three or more.
Patchy, but promising use in industry.
EASY TO LEARN!
Still immature. Requires large overhead for data gathering.
Contents
Data about PSP training show that students and engineers can improve their planning capabilities and produce higher quality products without an increase in cost.

72. The benefits of the PSP (1)
Insight into your talents and abilities
you will better understand your strengths and weaknesses
you will be better able to maximize your assets
the PSP will help you to objectively deal with your weaknesses.
Improvement ideas
by defining your process, you assert control over it
you will unconsciously observe your working self
you will see many ways to improve your process and your performance.
Improvement framework
you can better see how the process parts relate
you can better focus on priority areas for improvement.
Contents
The PSP is designed to help software professionals consistently use sound engineering practices.
It shows them how to plan and track their work, use a defined and measured process, establish measurable goals, and track performance against these goals.
The PSP shows engineers how to manage quality from the beginning of the job, how to analyze the results of each job, and how to use the results to improve the process for the next project.

73. The benefits of the PSP (2)
Personal control
you will have a planning framework
you will have the data on which to base your plans
your plans will be more reliable
you will be better able to track your status
you will be better able to manage your work.
Accomplishments and personal bests
you will recognize your personal bests
you will better understand how to repeat and to surpass them
you will see where and how you have improved
you will have your own personal improvement goals
you will have the satisfaction that comes with knowing you are doing superior work.
Remarks
When your team’s processes are defined
you can better back up and support each other
you will more precisely relate to each other
you will no longer need to protect yourself from your peers’ failures
they won’t need to protect against your failures.
Teams perform better when they can concentrate on the job and not worry about being defensive.

74. The costs of the PSP
Labor intensive - requires significant training, experience, and management support to realize benefits.
Tedious task
The time investment
process development takes about 1 to 2 hours per form and script
process updates will be needed at least every 3 months
data entry and analysis will take about an hour for each PSP-sized project.
Suggestions
try to promptly enter your process data
analyze your data every few weeks.
The emotional investment - occasional frustrations.
Lack of support tools - requires good CASE tool support to record and gather metrics with minimal effort.

75. Messages to remember 1. The PSP is designed to help you.
2. Use it to improve your performance and to help you to act professionally in difficult situations.
3. Emphasize what the PSP has done for you and urge others to find out for themselves what it will do for them.