Personal Software Process (PSP) Ref: Introduction to the Personal Software Process (Humphrey)

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

2. 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! SE 652- PSP Refresher

3. 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 SE 652- PSP Refresher

4. 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 SE 652- PSP Refresher

5. 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 SE 652- PSP Refresher

6. Tracking Time 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) SE 652- PSP Refresher

7. Quality & Defects 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? SE 652- PSP Refresher

8. Defect Management 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. SE 652- PSP Refresher

9. 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 SE 652- PSP Refresher

10. 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 SE 652- PSP Refresher

11. 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 SE 652- PSP Refresher

12. Sample Code Review Script (Sample Checklist: Table 14.1 in PSP) • Scan program once for each item on checklist • Note # of defects found in ‘#’ column(no defects, put an ‘x’) • For multiple objects, tally separately, same form • Scan entire program for unexpected / new defect types SE 652- PSP Refresher

13. 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 SE 652- PSP Refresher

14. LOC Counting Exercise (Pascal) SE 652- PSP Refresher

15. 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 SE 652- PSP Refresher

16. 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 /  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% SE 652- PSP Refresher