5/25/2006
Ref: Introduction to the Personal Software Process (Humphrey)
SE 652- PSP Refresher 1
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
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
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
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
Form: 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 Defined:
Adherence to users requirements, both explicit & implicit
Defect:
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
Form: 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
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
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
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 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
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
5/25/2006
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:
BEGIN, CASE, DO, ELSE, END, IF, RECORD, REPEAT, THEN
Where there is no ';' at a line end, every statement preceding the following key words is counted once (if not already counted):
ELSE, END, UNTIL
Every occurrence of a ',' in the USES or VAR portions of the program is counted once.
SE 652- PSP Refresher 14
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
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 /
of all task values
EV =
PV for completed tasks
E.G.
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