1. Software Engineering Prof. Dr. Bertrand Meyer March–June 2007 Chair of Software Engineering Lecture 2: The Personal Software Process

2. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 2 2 PSP: the background CMMI: Capability Maturity Model Integration (originally: CMM) Late 1980s, Software Engineering Institute (An institute at Carnegie-Mellon University, funded by the US Department of Defense) Goal: assess the maturity of the software process of an organization, especially its reproducibility Five levels of maturity (Initial, Managed, Defined, Quantitatively managed, Optimizing)

3. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 3 3 TSP, PSP Team Software Process Personal Software Process Outgrowth of CMMI work Directs work of teams and individuals for higher quality PSP is part of TSP

4. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 4 4 About this presentation This lecture describes the PSP as seen by its authors It does not necessarily imply endorsement of every idea The symbol indicates points that seem arguable

5. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 5 5 Management support The initial TSP objective is to convince management to let the team be self-directed, meaning that it:  Sets its own goals  Establishes its own roles  Decides on its development strategy  Defines its processes  Develops its plans  Measures, manages, and controls its work

6. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 6 6 Management support Management will support you as long as you:  Strive to meet their needs  Provide regular reports on your work  Convince them that your plans are sound  Do quality work  Respond to changing needs  Come to them for help when you have problems

7. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 7 7 Management support Self-directed teams are a bargain Management will agree to your managing your own work as long as they believe that you are doing a superior job. To convince them of this, you must:  Maintain and publish precise, accurate plans  Measure and track your work  Regularly show that you are doing superior work The PSP help you do this

8. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 8 8 PSP principles The quality of a software system is determined by the quality of its worst components. The quality of a software component is governed by the individual who developed it. The quality of a software component is governed by the quality of the process used to develop it. The key to quality is the individual developer’s skill, commitment, and personal process discipline.

9. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 9 9 More PSP principles Every software professional is responsible for his or her personal process. Measure, track, and analyze your work. Learn from your performance variations. Incorporate lessons learned into your personal practices.

10. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 10 10 What does a PSP provide? A stable, mature PSP allows you to  Estimate and plan your work  Meet your commitments  Resist unreasonable commitment pressures You will also  Understand your current performance  Improve your expertise as a professional

11. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 11 11 PSP outcomes  A proven basis for developing and using an industrial- strength personal process  A discipline that shows you how to improve your personal process  Data to continually improve the productivity, quality, and predictability of your work

12. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 12 12 PSP fundamentals The PSP is a personal process for developing software or for doing any other defined activity. The PSP includes  Defined steps  Forms  Standards It provides a measurement and analysis framework for characterizing and managing your personal work. It is also a defined procedure that helps you to improve your personal performance.

13. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 13 13 The PSP process flow Requirements Finished product Project summary Project and process data summary report Planning Design Code Compile Test PM Scripts guide Logs Requirements Finished product Project summary Project and process data summary report Planning Design Code Compile Test Postmortem Scripts guide Logs

14. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 14 14 Using PSP The PSP process is designed for individual use. It is based on scaled-down industrial software practice. It helps you meet the increasing demands for quality and timely software.

15. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 15 15 The Personal Software Process The PSP is introduced in six upward-compatible steps  You write one or more module-sized programs at each step  You gather and analyze data on your work  You use the results to improve your personal performance

16. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 16 16 The steps

17. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 17 17 Goals at each level PSP0:Establish a measured performance baseline PSP1:Make size, resource, and schedule plans PSP2:Practice defect and yield management

18. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 18 18 Scope of the PSP The PSP is not the process for writing software The PSP is a process for learning about process It’s the process equivalent of a code sample

19. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 19 19 PSP process flow Requirements Finished product Project summary Project and process data summary report Planning Design Code Compile Test PM Scripts guide Logs Requirements Finished product Project summary Project and process data summary report Planning Design Code Compile Test Postmortem Scripts guide Logs

20. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 20 20 The steps PSP1 Size estimating Test report PSP2 Code reviews Design reviews TSP Team development PSP2.1 Design templates PSP1.1 Task planning Schedule planning PSP0 Current process Time recording Defect recording Defect type standard PSP0.1 Coding standard Size measurement Process improvement proposal (PIP)

21. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 21 21 PSP0 Objective:  Demonstrate use of defined process for small programs  Incorporate basic measurements in process  Minimize changes to your personal practices PSP1 Size estimating Test report PSP2 Code reviews Design reviews PSP2.1 Design templates PSP1.1 Task planning Schedule planning PSP0.1 Coding standard Size measurement Process improvement proposal (PIP) PSP0 Current process Time recording Defect recording Defect type standard

22. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 22 22 PSP0 setup PSP0 is a simple, defined, personal process:  Make a plan  Use your current design and development methods to produce a small program  Gather time and defect data on your work  Prepare a summary report

23. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 23 23 The six phases of PSP0 Produce plan for developing program from requirements Produce design specification for the program. Turn design into executable code (In Eiffel, 2 & 3 are one step) Plan Design Code Compile Test Postmortem 1 2 3 5 4 6 Translate into executable code Verify that code satisfies requirements Summarize & analyze project data

24. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 24 24 Phase order PSP looks like waterfall but is not Phase order is determined by dependencies:  Can’t test code before it’s compiled  Can’t compile before it’s written  Can’t use design if produced after code is written  No reason to make a plan after you’re done Conclusion… start here with a plan. Plan Design Code Compile Test

25. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 25 25 Process flow When programs are small or well understood, you can execute the phases in order:  Produce a plan  Design all modules  Code all modules  Compile the coded program  Summarize project data during the postmortem Plan Design Code Compile Test Postmortem Requirements Program and Project data

26. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 26 26 Cyclic process flow Large programs or those that are not well understood may require an iterative approach. In this example the design is completed in one step. Two modules are identified during the design, modules A and B. Then each module is separately coded, compiled, and tested. This example uses the PSP0 phases and two cycles of code-compile-test. Plan Design Code Compile Test Postmortem Requirements Code Compile Test Module A Module B Program and Project data

27. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 27 27 Cyclic process flow There can be more than two cycles Each cycle is focused on producing part of the program, e.g. module A, B, C (see cluster model) Part size is key factor for determining cycles:  Line of code: too small  Program: may be too large One or more classes, features, procedures, or functions are probably the right size Determine what works for you Plan Design Code Compile Test Postmortem Requirements Module B Design Code Compile Test Module AModule C Design Code Compile Test Program and Project data

28. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 28 28 PSP0.1 Objective: help you to  Measure size of programs that you produce  Perform size accounting for these programs  Make accurate and precise size measurements PSP1 Size estimating Test report PSP2 Code reviews Design reviews PSP2.1 Design templates PSP1.1 Task planning Schedule planning PSP0.1 Coding standard Size measurement Process improvement proposal (PIP) PSP0 Current process Time recording Defect recording Defect type standard

29. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 29 29 Process measurement To be useful, measurements should be  Gathered for a specific purpose  Explicitly defined  Properly managed  Properly used We measure to  Understand and manage change  Predict or plan  Compare one product, process, or organization with another  Determine adherence to standards  Provide a basis for control

30. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 30 30 Measurement objectives Measurements only produce numbers To be useful, they must  Relate to business objectives  Be properly interpreted  Lead to appropriate action If the business purposes for the measurements are not understood  The wrong data may be gathered  Data may not be properly used

31. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 31 31 PSP measurements Basic PSP data:  Program size  Time spent by phase  Defects found and injected by phase On every item, gather both actual and estimated data Measures derived from these data:  Support planning  Characterize process quality

32. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 32 32 PSP1 Objective: establish orderly & repeatable procedure for size estimation PSP1 Size estimating Test report PSP2 Code reviews Design reviews PSP2.1 Design templates PSP1.1 Task planning Schedule planning PSP0 Current process Time recording Defect recording Defect type standard PSP0.1 Coding standard Size measurement Process improvement proposal (PIP) New process elements:  PROBE size estimating method & template  Test report template

33. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 33 33 Estimating with PROBE Stands for PROxy Based Estimating Uses proxies to estimate program size and development time A good proxy helps make accurate estimates

34. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 34 34 The PROBE estimating method Conceptual design Start Identify and size the proxies Number of items Part Type Relative size Reuse categories Estimate other element sizes Estimate program size Calculate prediction interval Size estimate and range Estimate resources Calculate prediction interval Resource estimate and range

35. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 35 Conceptual design Conceptual design relates the requirements to the parts needed to produce the program Parts categories:  Reused: Can be used as-is  Base: Exists, requires modifications  Added: needs to be developed

36. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 36 Sizing parts Reused part: Use actual size Added part: define proxy  Identify part type, e.g. parsing, GUI, network…  Estimate number of items, e.g. routines  Estimate relative size, i.e. very small, small, medium, large, or very large  Find size of an item of this part type and relative size in the relative size table  Estimated size = item size  number of items Base part: start from actual size; estimate additions, deletions, modifications

37. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 37 37 PSP1.1 Objective: introduce & practice methods for  Making resource & schedule plans  Tracking your performance against them  Judging likely project completion dates PSP1 Size estimating Test report PSP2 Code reviews Design reviews PSP2.1 Design templates PSP1.1 Task planning Schedule planning PSP0 Current process Time recording Defect recording Defect type standard PSP0.1 Coding standard Size measurement Process improvement proposal (PIP) Two new process elements:  Task planning template  Schedule planning template Typically used for projects that take several days or weeks

38. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 38 38 PSP2 Objective: introduce  Design & code reviews  Methods for evaluating and improving quality of reviews PSP1 Size estimating Test report PSP2 Code reviews Design reviews PSP2.1 Design templates PSP1.1 Task planning Schedule planning PSP0 Current process Time recording Defect recording Defect type standard PSP0.1 Coding standard Size measurement Process improvement proposal (PIP) Two key capabilities added at this level:  Design and code reviews  Quality planning Two new process elements, separate:  Design review checklist  Code review checklist

39. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 39 39 Quality planning PSP2 introduces quality planning. This involves estimating:  Total number of defects that will be injected  Number of defects injected & removed in each process phase  Amount of time for design and code reviews & adjusting these parameters to ensure high-quality result

40. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 40 40 Arguments for reviews over tests In testing, you must  Detect unusual behavior  Figure out what the test program was doing  Find where the problem is in the program  Figure out which defect could cause such behavior This can take a lot of time With reviews you  Follow your own logic  Know where you are when you find a defect  Know what the program should do, but did not  Know why this is a defect  Are in a better position to devise a correct fix

41. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 41 41 PSP review process principles Defined review process: guidelines, checklists, standards. Goal is to find every defect before first compile/test To meet it, you must:  Review before compiling or testing  Use coding standards  Use design completeness criteria  Measure and improve your review process  Use a customized personal checklist

42. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 42 42 Code review checklist Reviews are most effective with personal checklist customized to your own defect experience:  Use your own data to select the checklist items  Gather and analyze data on the reviews  Adjust the checklist with experience Do the reviews on a printed listing, not on the screen (???) The checklist defines the review steps and the suggested order for performing them  Review for one checklist item at a time  Check off each item as you complete it

43. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 43 43 Design review principles In addition to reviewing code, you should also review your designs Requires that you  Produce designs that can be reviewed  Follow an explicit review strategy  Review design in stages  Verify that logic correctly implements requirements

44. Software Engineering, lecture 1: Personal Software Process for Engineers: Introduction to PSP 44 44 PSP2.1 PSP1 Size estimating Test report PSP2 Code reviews Design reviews PSP2.1 Design templates PSP1.1 Task planning Schedule planning PSP0 Current process Time recording Defect recording Defect type standard PSP0.1 Coding standard Size measurement Process improvement proposal (PIP) Objective: introduce  Additional measures for managing process quality  Design templates that provide an orderly framework and format for recording designs New process elements:  Design review script  Design review checklist  Operational specification template  Functional specification template  State specification template  Logic specification template