Construx Software Development Best Practices Personal Measures Personal
Construx ® Software Development Best Practices Personal Measures
Personal Measures Self Examination v How can you measure yourself? v One example of a personal process that is published, defined is PSP v PSP stands for Personal Software Process v Information available on SEI website v It’s not the only possible process! Construx “Software Development Best Practices” 2
Personal Measures: PSP Practices and Measures v Engineers plan their work before they do it v They estimate size and effort on each program v They track the time they spend on each job step to the minute v They track their own defects and build a personal review checklist based on their own defect data v They track actual time, defect and size data Construx “Software Development Best Practices” 3
Personal Measures: PSP Practices and Measures continued v They review (by themselves) each design and their code before compile v The goal is to find 100% of the inserted defects before compile v With practice they find 60 -70% Construx “Software Development Best Practices” 4
Personal Measures: PSP Disadvantages v PSP is a very structured process! v Lots of forms, lots of data gathering, to the minute v You have to be very disciplined to follow it v It takes a lot of effort to do v But you improve! Construx “Software Development Best Practices” 5
Personal Measures: PSP Results v Estimation accuracy (in lines of code) improved 2. 5 times, i. e. 50% of the engineers reduced the error in their size estimates by 2. 5 or greater v Effort estimation accuracy improved by 1. 75 x v Defects showed a median reduction in total defect density by a factor of 1. 5 u u Compile phase defects declined by 3. 7 x Test phase defects declined by 2. 5 x v Productivity (in lines of code/hour) did not change even though much more documentation and tracking was being done Construx “Software Development Best Practices” 6
Personal Measures: PSP results in industry v Slight increase in productivity; much shorter acceptance test time: 2 months to a few days v Another comparison: Project C (not PSP) D (not PSP) B (PSP) Acceptance Test 11 defects 6 defects 0 defects Use 1 defect 14 defects 0 defects Scheduled for 2 months, took 5 Scheduled for 10 months, took 19 Scheduled for 7 months, took 5 From Girish Seshagiri, “Making Quality Happen: The Manager’s Role”, Cross. Talk, June 2000 Construx “Software Development Best Practices” 7
Team Software Process v PSP folks formed into teams v Teams estimate their own work and plan the project in a week long effort v Management can’t arbitrarily change schedule v Track using Earned Value and figure out how to get back on track if won’t meet agreed deadlines v Teams do Inspections of all documents u Construx And plan how much inspection time to spend based on injection rate of defects and removal rate during inspections “Software Development Best Practices” 8
TSP Results Measure TSP Projects Average Range Typical Projects Average Range System Test defects (defects/KLOC) 0. 4 0 to 0. 9 15 Delivered defects (defects/KLOC) 0. 06 0 to 0. 2 7. 5 System Test effort (% of 4% total effort) 2% to 7% 40% System Test Schedule (% of total duration) 40% 18% 7% to 25% Duration of System Test 0. 5 (days/KLOC) 0. 2 to 0. 8 N/A From Noopur Davis and Julia Mullaney, “The Team Software Process. SM (TSPSM) In Practice: A Summary of Recent Results” Construx “Software Development Best Practices” 9
References v [Davis 03] Noopur Davis and Julia Mullaney, “The Team Software Process. SM (TSPSM) In Practice: A Summary of Recent Results”, SEI Technical Report CMU/SEI-2003 -TR 014, September 2003, available at http: //www. sei. cmu. edu/pub/documents/ 03. reports/pdf/03 tr 014. pdf Construx “Software Development Best Practices” 10
- Slides: 10