Lecture The Personal Software Process Overview w Personal

Lecture: The Personal Software Process

Overview w Personal Software Process n assumptions n process stages n measures and quality strategy n results 2

Trademarks and Service Marks w The following are service marks of Carnegie Mellon University. n n n Capability Maturity Model Integration CMMi SM Team Software Process SM TSP SM Personal Software Process SM PSP SM SM w The following are registered trademarks of Carnegie Mellon University n Capability Maturity Model® n CMM ® 3

The PSP Paradigm w The PSP is based on process improvement principles. n Practitioners establish personal process goals. n They define the methods that they will use. n They measure their work. n They analyze the results. n Based on these analyses, they adjust their methods to better meet their personal goals. 4

The PSP Assumptions w Software engineers currently learn software development by developing toy programs. w They develop their own processes since process is not taught in introductory classes. w These toy processes do not provide a suitable foundation for large-scale software development. w To use effective methods consistently, engineers must believe that they are effective. w To believe that they are effective, they must use them. 5

The PSP Strategy w w Start with the engineer’s current process. Gradually introduce new methods. Practise these methods on module-sized programs. The engineers see for themselves how these methods help them. 6

PSP Overview -1 w The PSP is a process for individuals to use. w It applies to most structured personal tasks: n writing small programs or documents n defining requirements or processes n conducting reviews or tests w It is a software CMM level 5 process for individual engineers. 7

PSP Overview -2 w Individuals learn the PSP in 7 process steps. w Engineers write 10 module-sized programs using these PSP steps: n n They gather and analyze data on their work. Based on these analyses, they improve their working methods. w The PSP exercises provide the rapid feedback needed for effective learning. 8

The PSP is an Evolving Process Team Software Process PSP 3 Cyclic development PSP 2. 1 Code reviews Design reviews PSP 1 Design templates PSP 1. 1 Size estimating Test report Task planning Schedule planning PSP 0. 1 PSP 0 Current process Basic measures Coding standard Process improvement proposal Size measurement 9

PSP 0: Personal Measurement w Engineers gather data on the time they spend by phase and the defects they find. w Generates real, personal data and provides the base benchmark for measuring progress. w 3 phases: planning, development (design, code, compile, test), post-mortem. w PSP 0. 1 adds a coding standard, size measurement and a process improvement proposal. 10

PSP Basic Measures w Development time: measured in minutes using a time recording log designed to account for interruptions. w Defects: any change to the design or code to get the program to compile or test correctly; recorded in a defect recording log. w Size: lines of code, used primarily for estimating development time; new, modified and reused code is distinguished. 11

The Basic PSP Elements w w w Process script Project plan summary form Time recording log Defect reporting log Defect type standard 12

Process Scripts guide the engineers through the process. • purpose • inputs required • process phases • exit criteria 13

Project Plan Summary w The project plan summary form holds: n project plan data n actual project results w size w times w defect data n cumulative data on all PSP projects to date 14

Time Recording Log w. Time spent working on each PSP phase is recorded. n start time n stop time n interrupt time n phase n comments 15

Defect Recording Log w. Information on each defect found in reviews, compiling, and test. n number n type n phase injected n phase removed n find/fix time n description 16

The PSP Process Flow Requirements PSP process Planning Development Process scripts guide Design review Code review Compile Test Time and defect logs Project plan summary Postmortem Finished product Project and process data summary report 17

Why measure time usage ? -1 w Time is a non-renewable resource! w Making realistic plans requires knowing how you spend your time. w Tracking provides a more accurate record than just relying on your memory. w To manage your time, plan your time and then follow the plan (easier said than done!). 18

Why measure time usage ? -2 w Working to a plan helps guide your behaviour: n less time procrastinating n more focus on the actual task n less likely to be distracted n more likely to be efficient w Learn from your mistakes by planning better next time. 19

Why Record Defects? w w To identify the types of defects you introduce. To improve your skill as a programmer. To reduce the number of defects. Each change you make counts as one defect. 20

Defects w A defect is anything that detracts from a program’s ability to completely and effectively meet the user’s needs. w A defect is caused by a programmer’s mistake. w Even experienced programmers make a mistake about every 7 -10 lines of code they develop. w Defect prevention and removal are essential n typically account for 50% of project effort! 21

PSP 1: Personal Planning w This step introduces the PROBE method to estimate sizes and development times for new programs based on personal data. w PROBE is based on linear regression with prediction intervals to indicate size and time estimate quality. w PSP 1. 1 adds schedule and task planning. 22

The Project Planning Framework Customer need Define requirements Produce conceptual design Customer Product delivery Items PROBE Method Estimate size Size database Estimate resources Productivity database Produce schedule Resources available Develop product Size, resource schedule data Tasks Management Process analysis Tracking reports 23

Why Estimate Size? w To make better plans: n to more accurately size the job n to divide the job into separable elements w To assist in tracking progress: n can judge when job scope changes n can more accurately measure the work w Value for the PSP: n learn estimating methods n build estimating skills 24

Size Estimating Principles w Estimating is an uncertain process: n No one knows how big the product will be. n The earlier the estimate, the less is known. n Estimates can be biased by business and other pressures. w Estimating is an intuitive learning process: n n Ability improves with experience. Some people will be better at estimating than others. 25

The PROBE Estimating Method Start Conceptual design Identify and size objects Number of methods Object type Relative size Reuse categories Estimate other LOC Estimate program size Estimate resources Calculate prediction interval Size estimate Resource estimate 26

The Resource Planning Process w Start with a size estimate. w Identify available data. w Use regression when you have more than three sets of data that correlate. w Use data for estimated LOC to actual hours, where available. w Calculate the prediction interval. 27

Schedule Estimating w To make a schedule you need three things: n the estimated direct project hours n a calendar of available direct hours n the order in which the tasks will be done w Then, you need to: n n estimate the hours needed for each task spread these hours over the calendar of available hours 28

Schedule Example -1 w Jo decides to plan and track the next PSP assignment. Based on her historical data, the planned time for each phase is: Task Cum. planned value planned hrs planned value Cum. hrs Plan 1. 0 8 Design 4. 5 36 5. 5 44 Code 5. 0 40 10. 5 84 Compile 0. 5 4 11. 0 88 Test 1. 5 12 12. 5 100 TOTAL 12. 5 100 29

Schedule Example -2 w Jo knows that she will be able to spend 3. 5 hours per day on this assignment and produces the following schedule: Day No. Direct hours Cum. hours 1 3. 5 2 3. 5 7. 0 3 3. 5 10. 5 4 3. 5 14 30

Schedule Example -3 w Now Jo can determine the day on which each task should complete: Task Planned hrs Cum. hrs Complete Plan 1. 0 1 Design 4. 5 5. 5 2 Code 5. 0 10. 5 3 Compile 0. 5 11. 0 4 Test 1. 5 12. 5 4 TOTAL 12. 5 31

Schedule Example -4 w The final step is to calculate the (cumulative) planned value for each day (based on completed tasks): Day No. Direct hours Cum. hours Planned value 1 3. 5 8 2 3. 5 7. 0 44 3 3. 5 10. 5 84 4 3. 5 14 100 32

Schedule Example -5 w The schedule can be represented as a chart showed cumulative planned value per day. w As tasks get completed, we can track the earned value. w The earned value of a task is its original planned value, independent of the actual time taken to complete it. w We can also use extrapolation to predict the completion of the project. 33

Planned Value 34

Earned Value after 3 days 35

Earned Value Prediction 36

PSP 2: Personal Quality w This step introduces defect management. w Using data from the PSP exercises, engineers construct and use checklists for personal design and code reviews. w From their own data, they see how checklists help personal reviews. w PSP 2. 1 adds design specification and analysis techniques along with defect prevention, process analyses and process benchmarks. 37

The PSP Quality Strategy -1 w In the PSP, defects are the basic quality measure. w Low defect content is an essential prerequisite to a quality software process. n n Experienced software engineers typically inject around 100 defects per KLOC. Low defect products can best be assured at the PSP level. 38

The PSP Quality Strategy -2 w The PSP level is where defects are injected, and this is where the engineers should: n remove them n determine their causes n learn to prevent them w If you want to get a quality product out of test, you must put a quality product into test: n n Testing removes only a fraction of the defects. The more defects in the code entering test, the more defects there are on test exit. 39

The PSP Quality Strategy -3 w Data show that it is much more efficient to find defects in reviews than in testing: n n In unit test, typically only about 2 to 4 defects are found per hour. Code reviews typically find about 10 defects/hour. Experienced reviewers can find 70% or more of the defects in a product. Unit test rarely exceeds a 50% yield. w PSP data show that reviews find 2 to 5 times as many defects per hour compared to unit test. 40

Why Review before Compile? w The time to do a review is the same before or after compile. w Reviewing first will save compiling time. (typically 12 -15% 3 -4% of development) w Reviews done after compiling are generally not done as thoroughly. w Compiling is equally effective before or after a review. 41

Estimating Defects w Initially it seems strange to estimate how many defects we expect to inject into our programs - we are trying to develop a defect-free product! w However, it acknowledges the reality that we will make errors and inject defects - the important thing is to minimise their injection and to remove them efficiently. 42

Estimating Defects (cont. ) w As with the time estimation over phases, we start by estimating the total number of defects based on estimated program size and our past record of defect injection. w Allocate to phases using the to-date %. w Plan to remove all defects injected! 43

Estimating Defects: Example w Defect rate = 53 defects/KLOC w New program: 195 LOC (estimated) w Defect estimate = 53/1000 * 195 = 10. 3 (rounded) 44

Programming Exercises 1 A: calculate mean and standard deviation of numbers in a linked list 2 A: count LOC in a source program 3 A: enhance 2 A to count total and function LOC 4 A: calculate linear regression parameters 5 A: perform numerical integration 6 A: enhance 4 A to calculate prediction interval 7 A: calculate correlation of 2 linked lists 8 A: sort a linked list 9 A: chi-squared test for a normal distribution 10 A: calculate multiple regression parameters 45

PSP Training Data w Each assignment results in some 70 pieces of data collected by each engineer and collated by instructors to provide feedback. w This study is based on 23 PSP classes consisting of 298 engineers - over 300, 000 LOC during more than 15, 000 hours - about 22, 000 defects were discovered and removed. Each analysis is based on at least 170 cases where complete data was available. w Hayes, W. & Over, J. W. , The Personal Software Process (PSP): An Empirical Study of the Impact of PSP on Individual Engineers, (CMU/SEI-97 -TR-001), SEI, 1997. 46

Size Estimation Results Size Estimation Accuracy 0. 9 0. 8 PROBE size estimation begins 0. 7 Assignment Average 0. 6 PSP Level Average 0. 5 0. 4 0. 3 1 2 3 4 5 6 7 8 Assignment Number 9 10 1997 SEI Study 47

Effort Estimation Accuracy Effort Estimation Results 0. 7 Linear regression for effort estimation begins 0. 6 0. 5 Assignment Average PSP Level Average 0. 4 0. 3 0. 2 1 2 3 4 5 6 7 8 9 10 Assignment Number 1997 SEI Study 48

Product Quality Results -1 Total Defects/KLOC Removed Mean Defects Per KLOC 140 Design review and code review introduced 120 100 80 60 40 1 2 3 4 5 6 7 8 Assignment Number 9 10 1997 SEI Study 49

Product Quality Results -2 w. Defects/KLOC Removed in Test ± 1 Std. Dev. Mean Defects per KLOC Removed During Test 140 120 Defect analysis report written Design review and code review introduced 4 7 100 80 60 40 20 0 1 2 3 5 6 8 Assignment Number 9 10 1997 SEI Study 50

Process Quality Results 60% Mean Pre-Compile Defect Yield 50% 40% Design review and code review introduced 30% 20% 10% 0% 1 2 3 4 5 6 7 8 Assignment Number 9 10 1997 SEI Study 51

Productivity Results Mean LOC/Hour 50 40 30 20 10 0 1 2 3 4 5 6 7 8 9 10 Assignment Number 1997 SEI Study 52

Advanced Information Services w Project A: n PSP introduced after 3 of 9 components developed (500 - 2200 LOC each) n estimating error: 394% -> -10. 4% n acceptance test defects reduced by 78% n productivity improved 7% 53

Advanced Information Services (cont. ) 54

Motorola w Motorola paging products group - develop one-way numeric and alphanumeric pagers: n n n trained 40 engineers and 22 managers 18 completed maintenance and enhancement projects (25 K LOC), 575 defects total (136 in test) half in use for between 3 and 18 months with only one defect 55

Union Switch and Signal w Union Switch and Signal, Inc. - process control systems for real-time control of railroad and transit operations. w 9 managers and 25 engineers trained. w 5 projects (8, 400 LOC) all completed on schedule, a total of 57 defects found in test. w in use for between 1 and 9 months with zero defects found in use. 56

Team Software Process w Designed for teams of 2 to 20 PSP-trained software engineers. w Designed to create a process that builds effective teams and optimises team performance throughout a project. w The goal is CMM level 5 team performance. 57

Summary: The Personal Software Process w The PSP is a process designed for individual use, based on scaled-down industrial software practice. w The principal objective of the PSP is to help software engineers to do better work. w The PSP is also designed to demonstrate the value of using defined and measured processes. w Finally, the PSP is intended to help engineers and organizations meet the increasingly stringent demands for quality software systems. w Think of PSP as a level 5 process for individuals. 58

Follow-up Reading w W. Humphrey (Addison Wesley): n A Discipline for Software Engineering, 1995 n Introduction to the Personal Software Process, 1997 n Introduction to the Team Software Process, 2000 w Articles in IEEE Software, May 1996 and IEEE Computer, May 1997 w http: //www. sei. cmu. edu/tsp 59