1 / 25

The Capability Maturity Model

The Capability Maturity Model. Chapters 1 & 2 Gary Hellman Peter Munuhe Jingxian Zhang. Software Process Framework. Background Framework Five Maturity Levels and Behavior The Skipping of Maturity Levels Visibility in the Software Process

kathleen-weaver
Download Presentation

The 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. The Capability Maturity Model Chapters 1 & 2 Gary Hellman Peter Munuhe Jingxian Zhang

  2. Software Process Framework • Background • Framework • Five Maturity Levels and Behavior • The Skipping of Maturity Levels • Visibility in the Software Process • Prediction of Performance

  3. Software Process Framework • Why the need? • Customer satisfaction • Competitive marketplace • “Software Crises” • Technology advancement • Problem complexity increases • Overbudget & unreliable schedules

  4. Evolution of CMM • Began in 1986 ---SEI and Mitre Corp. • Developed framework & questionnaires • CMM based on – • Actual practices • Reflects the best practices • Reflects the users needs • Documented • Available publicly

  5. Immature vs. MatureOrganizations • Immature Organization • Processes are improvised • Process not enforced or followed • Reactionary • Focused on solving crises • Usually exceed budget and timetables • Quality is de-emphasized

  6. Immature vs. MatureOrganization • Mature Organization • Quality emphasized • Objective and quantitative base • Utilize historical performance • Follow a disciplined process consistently due to organization infrastructure

  7. Fundamental Concepts • Process • Software process • Software process capability • Software process performance • Software process maturity • Infrastructure • Institutionalization

  8. TQM within CMM • Purpose was to achieve lasting results in the CMM process. • The five stages of TQM were integrated into CMM. • Each stage provides a foundation for improvement.

  9. Benefits of CMM • Benefits • Forge a shared vision • Provide a framework • Builds a set of processes and practices

  10. Risks of CMM • Models are simplifications of the real world. • CMM does not address all issues. • CMM is not perfect. • CMM does not guarantee success.

  11. Behavioral characterization of the Maturity levels

  12. Initial level • Over commitment • Projects abandon planned procedures • Success depends on Manager and software team • Capability is characteristic of individual not Organization

  13. Repeatable level . • . • Project policies and procedures established • Processes management discipline implemented • Software management controls effective • Standards defined • Realistic plans

  14. Defined Level • Standard process documented • Organization wide training program implemented • Defined software process is in effect • Good insight of technical progress of project

  15. Managed level • Quantitative quality goals set • D-Base used to collect and analyze data • Meaningful variation in process performance • Trend predictability

  16. Optimizing level • Continuous process improvement is main focus • Strengths and weaknesses identified • Organized effort to remove waste • Technology and process improvements planned

  17. Skipping maturity levels WHAT HAPPENS???

  18. CMM • Stability is at risk • Key processes ignored • Failure of process • Proper foundation means improved transition

  19. Software Process Maturity Framework • Visibility into the software process • Prediction of performance

  20. SW Process is a black box • Visibility is limited • Product available to customer only when it is delivered IN OUT Visibility into the SW Process @ Level 1

  21. IN OUT Visibility into the SW Process @ Level 2 • Visibility occurs at transition points (milestones) • Customer can review the product at defined checkpoints

  22. Visibility into the SW Process @ Level 3 IN OUT • Internal structure of the boxes is visible • Customer can obtain accurate and rapid status updates

  23. Visibility into the SW Process @ Level 4 IN OUT • Managers are able to measure progress and problems • Customer can establish a quantitative understanding of process capability and risk before the project begins

  24. Visibility into the SW Process @ Level 5 Replaced/revised by IN OUT • Inefficient/defect-prone activities are identified & resolved • Managers are able to estimate/track the impact of change • A strong customer-supplier relationship is established

  25. Software Process Maturity Framework • Any Questions!!!!

More Related