CS3600: Software Engineering: Standards in Process Modeling CMM and PSP

1. CS3600: Software Engineering:Standards in Process ModelingCMM and PSP Vasudeva Varma vasu@iiit.net Spring 2002 International Institute of Information Technology, Hyderabad Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

2. Quick Review • Discuss Product and Process concepts • Look at various software Process models • Discuss CMM and PSP Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

3. What Makes You Better? • Why are you a better programmer than a first-year student? Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

4. Some Answers... • More training • Know how to use tools • Have seen some problems before • Know how things fit together • Familiar with language • Object, semaphore, recursion, etc • Better process! Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

5. Examples of Better Processes • Incremental coding • Code a little, test a little • Compare to writing entire program and testing • Error prevention versus debugging • Cheaper and easier to prevent than to find bugs Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

6. What Makes Organizations Better? • Why are some organizations better than others? • Deliver software on time • Deliver with high quality and few defects • Do some of the same things for a personal level scale up to organizations? • Assume two groups are doing same project, why would one be better than another? Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

7. Some Answers... • Great people • Smart management • Better tools • Good processes, standards and policies that all team members know and follow Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

8. What is the Point of Processes? • Basically, so we don’t reinvent the wheel! • Learn from mistakes • Never make the same mistake twice! • Incorporate best practices • Something works better than another • Routinization of standard tasks • Do it right once and then reuse it • Predictability Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

9. SEI-CMM • Software Engineering Institute Capability Maturity Model (SEI-CMM, or CMM) • CMM was developed by SEI at the request of the DoD in 1987 • Based on • Statistical quality control (Deming’s TQM, Juran) • Quality management (Crosby) • Feedback from industry and government projects Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

10. CMM Organization • Evolutionary path to increase software process maturity • Guide organizations in selecting improvement strategies • Small but continuous improvements • Descriptive, not prescriptive • Describes goals but not how to achieve them • Maturity characterized in five levels Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

11. CMM Components • Maturity levels • Process capabilities • Key process areas • Goals and common features • Key practices Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

12. CMM Components Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

13. CMM Maturity Levels Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

14. Level 1 - Initial • Process is ad hoc, occasionally chaotic • Few and informally defined processes • No mechanism to ensure they are used consistently • Ineffective planning • Reaction-driven management • Unpredictable • Success due to heroic efforts • ~80% of software organizations worldwide Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

15. Level 2 - Repeatable • Basic management processes, quality assurance and configuration control procedures in place • Can repeat earlier successes • Realistic project commitments based on results of previous projects • Still has frequent quality problems • Stable planning and tracking • ~15% of software organizations worldwide Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

16. Level 3 - Defined • Documented, standardized, and integrated management and engineering processes • Procedures are in place to insure they are followed • Projects tailor organization’s standard to develop own process • Software Engineering Process Group (SEPG) • Stable foundation for software engineering and management • ~5% of software organizations worldwide Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

17. Level 4 - Managed • Quality and performance is measured using metrics and can be predicted • Quality and productivity quantitative goals are established • Exceptional cases are identified and addressed • Challenge of new domains can be managed • Process is measured and operates within limits • < 1% of software organizations worldwide Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

18. Level 5 - Optimizing • Organization focuses on continuous process improvement • Goal is to address and prevent problems by analyzing their cause in the process • Process improvement is budgeted, planned, and part of the organization’s process • Identify and quickly transfer best practices • Only a handful of organizations worldwide Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

19. Why Five Levels? • Reasonably represents historical phases in actual software organizations • Reasonable measure of improvement from previous level • Suggests interim goals and measures • Prioritize improvements Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

20. Key Process Areas (KPA) • Issues to address to reach each maturity level • Related activities for achieving goals Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

21. Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

22. Key Process Areas—Repeatable(2) • Requirements management • Software project planning • Software project tracking and oversight • Software quality assurance • Software configuration management • Software subcontract management Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

23. Key Process Areas—Defined (3) • Organization process focus • Organization process definition • Training program • Integrated software management • Software product engineering • Intergroup coordination • Peer reviews Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

24. Key Process Areas—Managed (4) • Quantitative process management • Software quality management Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

25. Key Process Areas—Optimized(5) • Defect prevention • Technology change management • Process change management Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

26. CMM outcomes • Fewer project overruns • Better cost prediction (dollars, time) • Predicted performance improvements Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

27. The SEI Process Maturity Model ... • or Capability Maturity Model (CMM) • is the best available description of the goals, methods and practices needed for the industrial practice of software engineering But how do we do this in the classroom? • this is the role of thePSP i.e. the Personal Software Process Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

28. The Personal Software Process or PSP • PSP Objectives: • To introduce individuals to a process-based approach to developing software • To show individuals how to measure, estimate, schedule, and track their work • To show individuals how to improve the quality of their programs • In general PSP improves quality and productivity • The time saved in testing because of better quality reduces time across the project by 20-40% Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

29. The Personal Software Process or PSP… • a self improvement process • designed to • help you be a better software engineer • help you control, manage and improve the way you work • requires research and study of your work • needs personal motivation to pay off Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

30. The Personal Software Process • PSPhelps you to: • manage your work & assess/build your talents/skills • plan better • track your performance precisely • measure the quality of your software products - as a framework for determining: • why you make errors and how you find them • the quality of your reviews • the types of errors you make Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

31. The Personal Software Process PSP has a maturity framework like CMM - some KPAs are removed e.g.. training program Structure: PSP0: establish a measured performance baseline PSP1: make size, resource and schedule plans PSP2: learn defect and yield management PSP3: scale up PSP methods to larger projects Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

32. The Personal Software Process • Baseline Process - PSP0 • includes some basic measurements and a reporting format • the process you currently use to write software but enhanced to provide measurements • PSP0.1 - PSP0 enhanced by adding: • a coding standard • size measurement and size counting standard • process improvement proposal (PIP) Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

33. The Personal Software Process • The Personal Planning Process (PSP1) • adds planning steps to PSP0 • test report • size and resource estimation • PSP1.1 • establishes a performance rate for planning • PSP1 enhanced by adding • task planning • schedule planning Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

34. The Personal Software Process • The Personal Quality Management Process (PSP2) • adds review techniques to PSP1 to help you find defects early • design reviews • code reviews • PSP2.1 • establishes design completeness criteria • design templates Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

35. The Personal Software Process • A Cyclic Personal Process (PSP3) • for large programs e.g. 10,000 LOC • subdivide into PSP2-sized modules • enhance the base module in iterative cycles • in each iteration do a complete PSP2 including design, code, compile, test • effective scale up from base module to large program if each increment is of a high quality Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

36. The Personal Software Process • The PSP uses 3 types of measures: • Effort, Size and Defects • Effort measurement • Measured in minutes • Individuals keep records of time spent on tasks • Interruption time is recorded and subtracted • Size measurement • Size will be measured in number of lines of code and FP • Defect measurement • Students record changes to correct an error • Fix time and defect type is recorded Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

37. The Personal Software Process • PSP Logic - based on the Principles: • Measured historical data is needed for effective planning • A defined and structured process can improve working efficiency • Defined personal processes should fit the individual skills of the software engineer • Continuous process improvement is enhanced by rapid and explicit feedback Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

38. The Personal Software Process • Summary • Society is demanding more and better quality software faster and cheaper • Competent work is possible when professionals know the basic methods of their field and practice them with discipline Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH

39. Summary • The CMM sets out the principal practices for managing the processes in large-scale software development • The PSP sets out the principal practices for defining, measuring and analyzing an individual’s own processes Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITH