1 / 45

Managing Software Development Risk with Capability Maturity Model

Learn how Capability Maturity Model (CMM) can help reduce risk in software development by improving processes, increasing predictability, and enhancing quality. Explore the key process areas at Level 2 and the steps to initiate Software Process Improvement (SPI) with CMM.

lani-cardenas
Download Presentation

Managing Software Development Risk with Capability Maturity Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMM OverviewA Focus on Level 2 James R. Persse LightTouch Systems, Inc.

  2. The Software Engineering Institute’sCapability Maturity Model

  3. Reduce RiskThe UnknownIs Bad

  4. What Introduces Risk? • Unrefined Expectations • Poor Planning • Poor Oversight • Floating process to build software

  5. Sources of Risk • Pressure to get the product out. • Outside agencies force constraints on IT. • Too much work and tight resources. • Staff Turnover.

  6. Can You Remove All Risk?No.But Over Time You Can Remove A Lot

  7. Remove Risk byImproving how you build software By Examining The Steps You Follow. Then Working to Make those Steps more Effective.

  8. SoftwareProcess ImprovementEmerging as a big concernin Fortune 500 IT shops

  9. 1996 StudyAverage Fortune 500 New Software Project • 189% Over Budget • 222% Over Schedule • 30% Incomplete Functionality

  10. CMM is a Tool to address this situation There are others: ISO, Demings, Baldridge, etc.

  11. The CMM Approach

  12. Equation Theory • High Risk = Low Predictability • Low Predictability = Low Chance for Quality • Maturity = Low Risk + High Predictability

  13. Risk Predictability

  14. Software Process Improvement CMM is a means to an end CMM Goal: SPI

  15. Risk Level 5 Level 4 Predictability Level 3 Level 2 Level 1

  16. Some Risk will always remain.With CMM you manage Risk proactively.

  17. Level is 2 is Step 1 • It’s the beginning of an SPI program. • You don’t have to be extensive. • You don’t have to be perfect.

  18. The Repeatable Level A Good Way to Analyze how you build software is to repeat what you do from project to project.

  19. The Path to Improvement 1 Define a process. 2 Follow the process. 3 Study the results. 4 Keep what worked. 5 Throw out what didn’t. 6 Start over again.

  20. At Level 2You begin SPI by focusing on 5 areas.Key Process AreasAreas where you develop processes you can repeat and study.

  21. The Central Idea of Level 2 Look at what you do Throw out what does not work well Keep what does work well Refine Repeat

  22. Level 2 Key Process Areas • Requirements Management • Software Project Planning • Software Project Tracking and Oversight • Software Configuration Management • Software Quality Assurance

  23. What each KPA has in Common • A Policy to show you are committed to doing certain things. • A Structure (resources – people and tools -- and funding) to carry it out. • A Plan to document what you will do. • A Process to follow for doing it. • Training to prepare your people to act according to process.

  24. Basic Level 2 Activityfor each KPA Put the right people in place Have them develop plans to predict activity Follow the plan Measure how well it worked Refine Repeat

  25. Requirements Management • Work with Documented Requirements • Have the team Review them and accept them • Track them as they change

  26. Requirements Management • Person/People appointed to analyze • Process to Analyze and Accept and Track

  27. Software Project Planning • Have Requirements and Statement of Work • Get input/estimates from team • Create a Plan • Review the plan with the team before starting

  28. Software Project Planning • Assign a Planner • Use a Template to create the plan • Have a Process to derive estimates • Have a Process to create the plan, review it and approve it.

  29. Software Project Tracking & Oversight • Use the Plan as chief tool • Regularly track actuals against planned - Status Meetings • Adjust as necessary

  30. Software Project Tracking & Oversight • Assign a Project Manager • Use a Process to track progress • Have a Process to make changes to the Plan

  31. Software Configuration Management* Identify products to CM* Configuration Manage them * Audit their integrity in the CM library

  32. Software Configuration Management* Establish a Change Control Process* Establish a Change Control Board

  33. Software Configuration Management • People to sit on the Change Control Board • A Configuration Manager for the project • A Change Control Process • A Configuration Management Library • A Process to Manage Use of the Library

  34. Software Configuration Management • A Process used to conduct Baseline Audits • A Configuration Management Plan for the project • A Template used to create the CM Plan • A Process used to create, review, and approve the Plan.

  35. Software Quality Assurance* Identify products and activities to audit* Audit them* Report on the Results

  36. Software Quality Assurance * A person appointed to serve as SQA analyst * A Template used to create an SQA Plan for the project. * A Process to follow to create, review, and approve the Plan * A Process used to conduct SQA audits * A Process used to handle noncompliance

  37. Basic Elements of CMM • People in specific roles • Plans • Process to follow the Plans • Measurements

  38. Three Keys: Simplicity Training/Understanding Consistency

  39. Simplicity:Start small; start easy Grow into the roles Expand when you’re ready

  40. Training:Educate your people at the Start Give your team a common understanding Provide on-going assistanceNot important to be perfect

  41. Consistency:Required for improvementEssential for Team Direction The Key to Software Process Improvement

  42. CMM FlexibilityNot a Series of RulesRecommendations you Implement How You See Fit

  43. CMM Relies on Your Professional Judgment • You know best how your teams work • Configure CMM to work in your way • Understand the ‘intention’ of CMM • Do not read CMM as ‘requirements’

  44. CMM is about Process --Not People • Don’t use CMM to judge performance • Only use CMM to improve process • There is a People-CMM but Cingular is adopting the SW-CMM.

  45. CMM OverviewA Focus on Level 2 James R. Persse LightTouch Systems, Inc.

More Related