PSP Refresher



Personal Software Process (PSP)


Introduction to the Personal Software Process (Humphrey) SE 652- PSP Refresher 1

What is the Personal Software Process?

High quality is critical to project & product success & the most important single factor is the personal commitment of each software engineer to deliver a quality product!

2 5/25/2006 SE 652- PSP Refresher

Personal Commitment to Quality

Every Engineer must be committed to quality!

– Project/Product Success – Personal Satisfaction The PSP Paradigm: – 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 5/25/2006 SE 652- PSP Refresher 3

PSP Quality Metrics

Fundamental Measures: Volume Produced Quality Time Resources Cost of Quality (COQ) Types: Failure Cost – diagnosing & fixing defects Appraisal Cost –checking product for defects Prevention Cost – analyzing data, design & modifying process Appraisal / Failure Ratio (A/FR) is an indicator of effort spent to avoid introducing defects into the product

COQ = COQ Type effort / Total Project effort A/FR = Appraisal COQ / Failure COQ

5/25/2006 SE 652- PSP Refresher 4

COQ & Defect Relationships

Defect Relationships High A/F Ratios (i.e. > 1) => fewer defects Strong Correlation between compile detected defects & overall defects High A/F Ratios => fewer test hours Review Rates & Improvement Review Rate = Defects found / code review hours To Improve: Measure Analyze defects that get through, look for ways to catch them earlier Delete steps that don’t find or miss defects 5/25/2006 SE 652- PSP Refresher 5

Tracking Time


Time Log ( LOGT )

Data Tracked: Date Start/Stop Time Interruption Time Net Delta Time

(i.e. Stop time – Start time =Interruption time)

Activity Comments Completed (yes/no) Units (e.g. # of lines of code, # of pages read / reviewed) 5/25/2006 SE 652- PSP Refresher 6

Quality & Defects

Quality Defined:

Adherence to users requirements, both explicit & implicit


Anything that detracts from program’s ability to completely & effectively meet the needs of the end users. Includes code, design & requirements.

Defect Injection:

Introduction of mistakes that cause the program to operate incorrectly.

Cost of Defects Defect identification & removal typically > ½ of total project effort Defect removal most efficiently done by person who injects them Why not bugs?

5/25/2006 SE 652- PSP Refresher 7

Defect Management


Defect Recording Log ( LOGD )

Record Defects: Improve programming

If you can’t measure it, you can’t manage it.

If you aren’t measuring, you aren’t managing.

Reduce # of defects Save Time & Money Find / fix cost increases 10x with every subsequent phase Types of Defects: See LOGD form Defect Severities: Major, Minor, etc.

5/25/2006 SE 652- PSP Refresher 8

Defect Detection

Compilers catch ~90% of syntax errors Testing efficiency varies based on: Quality into test Quality of test coverage Size & Complexity of product Field found Customer Trials Post General Availability (IBM: $250M / year to fix 13,000 customer reported defects, avg.=$20K/defect) Reviews Code (Individual & Team) Design Requirements 5/25/2006 SE 652- PSP Refresher 9

Code Reviews

Time consuming, but 3x-5x more efficient than testing If Done Well: Expect 6-10 defects / engineer hour Expect 75% - 80% defect removal efficiency Expect 30 min / 100 LOC Personal Code Review before compiling?

•Approximately same time, before or after compiling & can save compile time (typical, 12-15% development time vs. 3 %) •Once programs are compiled, reviews typically not as thorough •Compiling equally effective before or after the code review •Correlation between defects found during compile & defects found in test 5/25/2006 SE 652- PSP Refresher 10

Code Review Checklist

Prerequisite: Coding Guidelines Systematic checklists help ensure thorough reviews (See PSP Table 14.1 for example) Refine checklist based on individual performance 5/25/2006 SE 652- PSP Refresher 11

Sample Code Review Script

(Sample Checklist: Table 14.1 in PSP)

1. Scan program once for each item on checklist 2. Note # of defects found in ‘#’ column (no defects, put an ‘x’) 3. For multiple objects, tally separately, same form 4. Scan entire program for unexpected / new defect types 5/25/2006 SE 652- PSP Refresher 12

Product Size

Size one of primary tools in estimating product size & development effort Estimating is a skill, can be developed & improved with practice Better if based on historical data Improve with increased granularity Size measures good for normalizing estimates, but beware … Common size measures Programs – Lines of Code (NCSL/KLOC, Function Points) Documents – Pages Size Estimation Use historical data (whenever possible) Estimate often Compare estimates with actuals 5/25/2006 SE 652- PSP Refresher 13

Parentheses Brackets Semicolon Period Key Words Special Comma


LOC Counting Exercise (Pascal)

Code Counting Guidelines

No statement or punctuation marks within '( Š )' are counted. No statement or punctuation marks within '{ Š }' are counted Every occurrence of a ';' is counted once Every occurrence of a '.' that follows a terminating END statement is counted once. Every occurrence of the following selected key words is counted once:


Where there is no ';' at a line end, every statement preceding the following key words is counted once (if not already counted):


Every occurrence of a ',' in the USES or VAR portions of the program is counted once.

SE 652- PSP Refresher 14

Task & Schedule Planning

Schedule Development Identify & document all tasks, assign resources & communicate to each individual Obtain commitment dates for each task Identify & document interdependencies between tasks, inputs to start each task & supplier of inputs Review with entire team to identify conflicts, disagreements or misunderstandings Checkpoints Objectively identifiable points in a project (Typically want at least one checkpoint per week) Gantt Charts 5/25/2006 SE 652- PSP Refresher 15

Schedule Tracking & Earned Value

Milestone tracking by % complete (

10/90 rule


Earned Value (EV)

Assign value to each task based on estimate

Planned Value (PV) of a task = value /

EV =

PV for completed tasks of all task values


Task 1 PV = 10% Task 2 PV = 15% On completion of task 1 & task 2, EV = 25% 5/25/2006 SE 652- PSP Refresher 16