CMM    CMMI  CFICSE 2002 – ST07 Michelle L. Crane
References <ul><li>James W. Moore, Software Engineering Standards: A User’s Road Map, IEEE Computer Society, 1998. </li></...
Outline <ul><li>Review of Motivation </li></ul><ul><li>Review of SW-CMM </li></ul><ul><ul><li>SW-CMM Maturity Levels </li>...
Outline (cont’d) <ul><li>Other Capability Maturity Models </li></ul><ul><ul><li>SA-CMM </li></ul></ul><ul><ul><li>P-CMM </...
Standards We Will Love DoD-Std 2167A ISO/IEC 12207 EIA/IEEE J-Std-016 Mil-Std 498 IEEE/EIA Std 12207 Reference:  http://ww...
But Not Just SW CMM SW CMM
SW-CMM
SW-CMM History <ul><li>November 1986, the SEI and Mitre Corporation begin developing process maturity framework </li></ul>...
Review of Motivation
Motivating Observations <ul><li>productivity and quality gains from methodologies and technologies not near what was expec...
The Immature Organization <ul><li>processes improvised </li></ul><ul><li>if process specified, it is not followed </li></u...
The Mature Organization <ul><li>organization-wide ability for managing development and maintenance </li></ul><ul><li>proce...
The Mature Organization (cont’d) <ul><li>improvements developed through controlled pilot projects or cost/benefit analysis...
Review of SW-CMM
SW-CMM (or CMM) <ul><li>Capability Maturity Model for Software </li></ul><ul><li>model for  </li></ul><ul><ul><li>judging ...
SW-CMM (cont’d) <ul><li>used as a standard for appraising the current state of an organization’s software process </li></u...
SW-CMM Maturity Levels Initial (1) Repeatable (2) Defined (3) Managed (4) Optimizing (5) Basic Management Control Process ...
The Five Levels of SW-CMM <ul><li>Level 1—Initial </li></ul><ul><ul><li>software process is ad hoc, maybe even chaotic </l...
The Five Levels of SW-CMM (cont’d) <ul><li>Level 3 – Defined </li></ul><ul><ul><li>software process for both management an...
The Five Levels of SW-CMM (cont’d) <ul><li>Level 4 – Managed </li></ul><ul><ul><li>detailed measures of the software proce...
SW-CMM Structure
Key Process Areas (KPAs) <ul><li>each maturity level (except 1) is decomposed into several key process areas that indicate...
Key Process Areas (cont’d) <ul><li>KPAs are enhanced in succeeding levels </li></ul><ul><li>to achieve a maturity level, t...
Key Process Areas (KPA) <ul><li>Level 1 has none by definition </li></ul><ul><li>Level 2 </li></ul><ul><ul><li>software pr...
Key Process Areas (cont’d) <ul><li>Level 3 </li></ul><ul><ul><li>address both project and organizational issues </li></ul>...
Key Process Areas (cont’d) <ul><li>Level 4 </li></ul><ul><ul><li>focus on establishing a quantitative understanding of bot...
Key Process Areas (cont’d) <ul><li>Level 5 </li></ul><ul><ul><li>cover the issues that both the organization and the proje...
Key Practices <ul><li>each Key Process Area is described in terms of the key practices that contribute to satisfying its g...
Common Features <ul><li>Commitment to Perform (CO)  </li></ul><ul><ul><li>groups all generic practices related to creating...
State of the Industry Goal for most organizations is to achieve Level 3.  Royce
Evaluation <ul><li>one instrument for assessing is a software capability evaluation (SCE) </li></ul><ul><ul><li>determines...
Back to the Map
SCE <ul><li>Software Capability Evaluation </li></ul><ul><ul><li>published: Version 3.0, April 1996 </li></ul></ul><ul><li...
SCE (cont’d) <ul><li>SCEs are designed to be used in </li></ul><ul><ul><li>source selection  </li></ul></ul><ul><ul><ul><l...
Back to the Map
SCDE <ul><li>Software Development Capability Evaluation </li></ul><ul><ul><li>published: 15 Jun 95 </li></ul></ul><ul><li>...
Problems with SW-CMM
Issues with the CMM <ul><li>key process areas (KPAs) focus mostly on activities and supporting artifacts associated with a...
Issues (cont’d) <ul><li>no emphasis on the architecting/design process, assessment process, or deployment process </li></u...
Issues (cont’d) <ul><li>most implementations of CMM drive organizations to produce more documents, more checkpoints, more ...
Issues (cont’d) <ul><li>hard to accurately measure an organization’s current maturity level </li></ul><ul><ul><li>CMM take...
More Short-Comings of CMM <ul><li>not a silver bullet </li></ul><ul><ul><li>a mature process is no guarantee of a quality ...
Evolution of CMM <ul><li>initial Capability Maturity Model was developed specifically to address software process maturity...
Other Capability Maturity Models
Back to the Map
SA-CMM <ul><li>Software Acquisition Capability Maturity Model </li></ul><ul><ul><li>published: Version 1.01, December 1996...
SA-CMM Maturity Levels Reference:  www.software.org/quagmire No KPAs at this level Competent people and heroics Level 1 In...
Back to the Map
P-CMM <ul><li>People Capability Maturity Model </li></ul><ul><ul><li>published: July 2001 </li></ul></ul><ul><li>describes...
P-CMM (cont’d) <ul><li>purpose is to enhance the readiness of software development and information systems organizations t...
P-CMM Maturity Levels Reference:  www.software.org/quagmire Participatory Culture Competency-Based Practices Career Develo...
P-CMM Maturity Levels (cont’d) Reference:  www.software.org/quagmire No KPAs at this level Level 1 Initial Compensation Tr...
Back to the Map
SE-CMM <ul><li>Systems Engineering Capability Maturity Model </li></ul><ul><ul><li>published: November 1995 </li></ul></ul...
SE-CMM (cont’d) <ul><li>still 5 levels (counted in each PA?) </li></ul><ul><ul><li>1 – Generic Practices </li></ul></ul><u...
Back to the Map
SSE-CMM <ul><li>Systems Security Engineering CMM </li></ul><ul><ul><li>published: 1 Apr 99 (Version 2.0) </li></ul></ul><u...
Back to the Map
IPD-CMM <ul><li>Integrated Product Development Capability Maturity Model </li></ul><ul><ul><li>published: no longer publis...
IPD-CMM <ul><li>built on a continuous model architecture like the Systems Engineering CMM </li></ul><ul><li>adds the conce...
So Many CMMs <ul><li>many organizations found these models to be useful </li></ul><ul><li>but struggled with problems caus...
Back to the Map
Integration <ul><li>CMM Integration (CMMI) project was conceived as an initiative to integrate the various CMMs into a set...
Overview of CMMI
CMMI <ul><li>Capability Maturity Model Integration </li></ul><ul><ul><li>published: draft version 1.02b, Dec 2001 </li></u...
CMMI (cont’d) <ul><li>source models </li></ul><ul><ul><li>SW-CMM version 2.0 draft </li></ul></ul><ul><ul><li>EIA/IS 731 S...
CMMI Product Suite Naming <ul><li>each CMMI model is given a name consisting of “CMMI-” followed by the abbreviation for t...
Purpose of CMMI <ul><li>to provide guidance for improving the organization’s processes and ability to manage the </li></ul...
Purpose of CMMI (cont’d) <ul><li>places proven practices into a structure that helps the organization </li></ul><ul><ul><l...
Purpose of CMMI <ul><li>CMMI is a framework that describes the essential elements of an effective system or software engin...
Core Concepts <ul><li>Software Process Capability </li></ul><ul><ul><li>the range of expected results that can be achieved...
CMMI Maturity Levels Initial (1) Managed (2) Defined (3) Quantitatively Managed (4) Optimizing (5) Disciplined process Sta...
CMMI Maturity Levels Initial (1) Managed (2) Defined (3) Quantitatively Managed (4) Optimizing (5) Disciplined process Sta...
Levels and Process Areas <ul><li>elements of CMMI are called Process Areas (not Key Process Areas or Focus Areas) </li></u...
The Five Maturity Levels of CMMI <ul><li>Level 1 – Initial </li></ul><ul><ul><li>process maturity characterized by unpredi...
The Five Maturity Levels of CMMI (cont’d) <ul><li>Level 2 – Managed </li></ul><ul><ul><li>process maturity characterized b...
The Five Maturity Levels of CMMI (cont’d) <ul><li>Level 3 – Defined </li></ul><ul><ul><li>process maturity characterized b...
The Five Maturity Levels of CMMI (cont’d) <ul><ul><ul><li>product integration </li></ul></ul></ul><ul><ul><ul><ul><li>cont...
The Five Maturity Levels of CMMI (cont’d) <ul><ul><ul><li>organizational training </li></ul></ul></ul><ul><ul><ul><ul><li>...
The Five Maturity Levels of CMMI (cont’d) <ul><li>Level 4 – Quantitatively Managed </li></ul><ul><ul><li>process maturity ...
The Five Maturity Levels of CMMI (cont’d) <ul><li>Level 5 – Optimized </li></ul><ul><ul><li>process maturity characterized...
Representations (cont’d) <ul><li>two representations </li></ul><ul><ul><li>provide alternative approaches to process impro...
Representations (cont’d) <ul><li>1. focus on the organization as a whole and provide a road map of successive stages aimed...
Representations (cont’d) <ul><li>each representation is a 600 page document </li></ul><ul><li>equivalent staging </li></ul...
Continuous <ul><li>groups process areas into </li></ul><ul><ul><li>process management </li></ul></ul><ul><ul><li>project m...
Staged <ul><li>groups process areas by maturity level </li></ul><ul><li>allows an overall assessment leading to an assessm...
Some Differences between Representations Reference:  www.sei.cmu.edu/cmmi/adoption/cmmi-faq.html   no equivalence concept ...
Summary <ul><li>Review of Motivation </li></ul><ul><li>Review of SW-CMM </li></ul><ul><ul><li>Problems with SW-CMM </li></...
?
Upcoming SlideShare
Loading in...5
×

ST07

1,352

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,352
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
50
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ST07

  1. 1. CMM  CMMI CFICSE 2002 – ST07 Michelle L. Crane
  2. 2. References <ul><li>James W. Moore, Software Engineering Standards: A User’s Road Map, IEEE Computer Society, 1998. </li></ul><ul><li>www.software.org/quagmire </li></ul><ul><li>www. sei . cmu . edu </li></ul><ul><ul><li>publications </li></ul></ul><ul><ul><li>CMM, etc. </li></ul></ul><ul><li>Walker Royce, CMM vs. CMMI: From Conventional to Modern Software Management, www. therationaledge .com </li></ul><ul><li>Winifred Menezes, To CMMI or Not to CMMI: Issues to Think About. CrossTalk. Feb 2002. </li></ul>
  3. 3. Outline <ul><li>Review of Motivation </li></ul><ul><li>Review of SW-CMM </li></ul><ul><ul><li>SW-CMM Maturity Levels </li></ul></ul><ul><ul><li>Key Process Areas (KPAs) </li></ul></ul><ul><ul><li>Evaluation </li></ul></ul><ul><ul><ul><li>SCE </li></ul></ul></ul><ul><ul><ul><li>SCDE </li></ul></ul></ul><ul><ul><li>Problems with SW-CMM </li></ul></ul>
  4. 4. Outline (cont’d) <ul><li>Other Capability Maturity Models </li></ul><ul><ul><li>SA-CMM </li></ul></ul><ul><ul><li>P-CMM </li></ul></ul><ul><ul><li>SE-CMM </li></ul></ul><ul><ul><li>SSE-CMM </li></ul></ul><ul><ul><li>IPD-CMM </li></ul></ul><ul><li>CMMI </li></ul><ul><ul><li>Purpose of CMMI </li></ul></ul><ul><ul><li>CMMI Maturity Levels </li></ul></ul><ul><ul><li>Representations </li></ul></ul>
  5. 5. Standards We Will Love DoD-Std 2167A ISO/IEC 12207 EIA/IEEE J-Std-016 Mil-Std 498 IEEE/EIA Std 12207 Reference: http://www.software.org/quagmire/ SW CMM ISO 9000 series supersedes based on uses/references
  6. 6. But Not Just SW CMM SW CMM
  7. 7. SW-CMM
  8. 8. SW-CMM History <ul><li>November 1986, the SEI and Mitre Corporation begin developing process maturity framework </li></ul><ul><li>1987, a short article and questionnaire released </li></ul><ul><ul><li>provide vehicle to identify areas in need of process improvement </li></ul></ul><ul><li>1991, the Software Capability Maturity Model (SW-CMM) version 1.0 released; 1993, SW-CMM version 1.1 released (31 drafts to this point) </li></ul><ul><li>1996, work on SW-CMM version 2.0 begins; ends in October 1997 with draft ‘C’ </li></ul>
  9. 9. Review of Motivation
  10. 10. Motivating Observations <ul><li>productivity and quality gains from methodologies and technologies not near what was expected </li></ul><ul><li>difficult to do better in a chaotic process </li></ul><ul><li>in undisciplined organizations, most projects produce poor results </li></ul><ul><li>in undisciplined organizations, some projects produce excellent results </li></ul><ul><ul><li>usually the result of heroic effort </li></ul></ul><ul><ul><li>repeating the result means repeating the heroics </li></ul></ul>
  11. 11. The Immature Organization <ul><li>processes improvised </li></ul><ul><li>if process specified, it is not followed </li></ul><ul><li>managers focuses on “fighting fires” </li></ul><ul><li>schedules and budgets routinely exceeded </li></ul><ul><li>quality and function compromised to meet schedule </li></ul><ul><li>no objective basis for judging product quality </li></ul><ul><li>quality-related activities often eliminated due to schedule pressures </li></ul>
  12. 12. The Mature Organization <ul><li>organization-wide ability for managing development and maintenance </li></ul><ul><li>process communicated to staff; staff follow process </li></ul><ul><li>processes are “fit for use” </li></ul><ul><li>processes are updated as necessary </li></ul>
  13. 13. The Mature Organization (cont’d) <ul><li>improvements developed through controlled pilot projects or cost/benefit analysis </li></ul><ul><li>managers monitor quality against an objective basis </li></ul><ul><li>schedules and budgets are realistic </li></ul><ul><li>expected results are usually achieved </li></ul>
  14. 14. Review of SW-CMM
  15. 15. SW-CMM (or CMM) <ul><li>Capability Maturity Model for Software </li></ul><ul><li>model for </li></ul><ul><ul><li>judging the maturity of the software processes of an organization </li></ul></ul><ul><ul><li>for identifying the key practices that are required to increase the maturity of these processes </li></ul></ul><ul><li>developed by the software community with stewardship by the SEI </li></ul><ul><li>has become a de facto standard for assessing and improving software processes </li></ul>Reference: www.sei.cmu.edu/cmm/cmm.html
  16. 16. SW-CMM (cont’d) <ul><li>used as a standard for appraising the current state of an organization’s software process </li></ul><ul><li>used as a guide for identifying and prioritizing the actions comprising the software process improvement effort </li></ul><ul><li>made up of 5 levels and 18 key process areas </li></ul><ul><li>a CMM-based maturity questionnaire may be used to assess the software capability of a particular organization </li></ul>
  17. 17. SW-CMM Maturity Levels Initial (1) Repeatable (2) Defined (3) Managed (4) Optimizing (5) Basic Management Control Process Definition Process Measurement Process Control
  18. 18. The Five Levels of SW-CMM <ul><li>Level 1—Initial </li></ul><ul><ul><li>software process is ad hoc, maybe even chaotic </li></ul></ul><ul><ul><li>few processes are defined; success depends on individual effort and heroics </li></ul></ul><ul><li>Level 2 – Repeatable </li></ul><ul><ul><li>basic project management practices to track cost, schedule, functionality </li></ul></ul><ul><ul><li>necessary process discipline is in place to repeat earlier successes on projects with similar applications </li></ul></ul>Reference: www.sei.cmu.edu/cmm/cmm_sum.html
  19. 19. The Five Levels of SW-CMM (cont’d) <ul><li>Level 3 – Defined </li></ul><ul><ul><li>software process for both management and engineering activities is documented, standardized, integrated into a standard software process </li></ul></ul><ul><ul><li>all projects use an approved, tailored version of the organization’s standard software process for developing and maintaining software </li></ul></ul>Reference: www.sei.cmu.edu/cmm/cmm_sum.html
  20. 20. The Five Levels of SW-CMM (cont’d) <ul><li>Level 4 – Managed </li></ul><ul><ul><li>detailed measures of the software process and product quality are collected </li></ul></ul><ul><ul><li>both the software process and products are quantitatively understood and controlled </li></ul></ul><ul><li>Level 5 – Optimized </li></ul><ul><ul><li>continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies </li></ul></ul>Reference: www.sei.cmu.edu/cmm/cmm_sum.html
  21. 21. SW-CMM Structure
  22. 22. Key Process Areas (KPAs) <ul><li>each maturity level (except 1) is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process </li></ul><ul><li>a cluster of related activities which collectively achieve a set of important goals </li></ul><ul><li>when the goals are accomplished on a continuing basis, the KPA is said to be institutionalized </li></ul>
  23. 23. Key Process Areas (cont’d) <ul><li>KPAs are enhanced in succeeding levels </li></ul><ul><li>to achieve a maturity level, the KPA for that level must be satisfied </li></ul><ul><li>there are other processes deemed to be not key to achieving a maturity level; they are not addressed by the model </li></ul>
  24. 24. Key Process Areas (KPA) <ul><li>Level 1 has none by definition </li></ul><ul><li>Level 2 </li></ul><ul><ul><li>software project concerns related to establishing basic project management controls </li></ul></ul><ul><ul><ul><li>requirements management </li></ul></ul></ul><ul><ul><ul><li>software project planning </li></ul></ul></ul><ul><ul><ul><li>software project tracking and oversight </li></ul></ul></ul><ul><ul><ul><li>software subcontract management </li></ul></ul></ul><ul><ul><ul><li>software quality assurance </li></ul></ul></ul><ul><ul><ul><li>software configuration management </li></ul></ul></ul>Reference: www.sei.cmu.edu/cmm/cmm_sum.html
  25. 25. Key Process Areas (cont’d) <ul><li>Level 3 </li></ul><ul><ul><li>address both project and organizational issues </li></ul></ul><ul><ul><ul><li>organizational process focus </li></ul></ul></ul><ul><ul><ul><li>organizational process definition </li></ul></ul></ul><ul><ul><ul><li>training program </li></ul></ul></ul><ul><ul><ul><li>integrated software management </li></ul></ul></ul><ul><ul><ul><li>software product engineering </li></ul></ul></ul><ul><ul><ul><li>intergroup coordination </li></ul></ul></ul><ul><ul><ul><li>peer reviews </li></ul></ul></ul>Reference: www.sei.cmu.edu/cmm/cmm_sum.html
  26. 26. Key Process Areas (cont’d) <ul><li>Level 4 </li></ul><ul><ul><li>focus on establishing a quantitative understanding of both the software process and the software work products being built </li></ul></ul><ul><ul><ul><li>process measurement and analysis </li></ul></ul></ul><ul><ul><ul><li>quality management </li></ul></ul></ul><ul><ul><ul><li>defect prevention </li></ul></ul></ul>Reference: www.sei.cmu.edu/cmm/cmm_sum.html
  27. 27. Key Process Areas (cont’d) <ul><li>Level 5 </li></ul><ul><ul><li>cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement </li></ul></ul><ul><ul><ul><li>technology innovation </li></ul></ul></ul><ul><ul><ul><li>process change management </li></ul></ul></ul>Reference: www.sei.cmu.edu/cmm/cmm_sum.html
  28. 28. Key Practices <ul><li>each Key Process Area is described in terms of the key practices that contribute to satisfying its goals </li></ul><ul><li>describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area </li></ul>Reference: www.sei.cmu.edu/cmm/cmm_sum.html
  29. 29. Common Features <ul><li>Commitment to Perform (CO) </li></ul><ul><ul><li>groups all generic practices related to creating policies and securing sponsorship for process improvement efforts. </li></ul></ul><ul><li>Ability to Perform (AB) </li></ul><ul><ul><li>groups all generic practices related to ensuring that the project and/or organization has the resources it needs to pursue process improvement. </li></ul></ul><ul><li>Directing Implementation (DI) </li></ul><ul><ul><li>groups the generic practices related to collecting, measuring, and analyzing data related to processes. The purpose of these activities is to provide insight into the performance of processes. </li></ul></ul><ul><li>Verifying Implementation (VE) </li></ul><ul><ul><li>groups all generic practices related to verifying that the projects and/or organization’s activities conform to requirements, processes, and procedures. </li></ul></ul>
  30. 30. State of the Industry Goal for most organizations is to achieve Level 3. Royce
  31. 31. Evaluation <ul><li>one instrument for assessing is a software capability evaluation (SCE) </li></ul><ul><ul><li>determines whether the organization “says what it does and does what it says” </li></ul></ul><ul><ul><li>by evaluating its software process (usually in the form of policy statements) and project practices </li></ul></ul><ul><ul><ul><li>process captures “say what you do” </li></ul></ul></ul><ul><ul><ul><li>project implementations demonstrate “do what you say” </li></ul></ul></ul>Reference: Royce, CMM vs. CMMI
  32. 32. Back to the Map
  33. 33. SCE <ul><li>Software Capability Evaluation </li></ul><ul><ul><li>published: Version 3.0, April 1996 </li></ul></ul><ul><li>method for evaluating the software process of an organization to gain insight into its process capability </li></ul><ul><li>version 3.0 based on SW-CMM version 1.1 </li></ul><ul><li>SCE team conducts a document review and extensive interviews </li></ul><ul><ul><li>observed strengths and weaknesses are formally documented and then used to determine risk for a particular development </li></ul></ul>Reference: www.software.org/quagmire
  34. 34. SCE (cont’d) <ul><li>SCEs are designed to be used in </li></ul><ul><ul><li>source selection </li></ul></ul><ul><ul><ul><li>help select a qualified contractor </li></ul></ul></ul><ul><ul><li>contract monitoring </li></ul></ul><ul><ul><ul><li>identify risks </li></ul></ul></ul><ul><ul><ul><li>measure performance for incentive fees </li></ul></ul></ul><ul><ul><ul><li>baselining organizational performance </li></ul></ul></ul><ul><li>SCE does NOT determine an SEI SW-CMM Level </li></ul>Reference: www.software.org/quagmire
  35. 35. Back to the Map
  36. 36. SCDE <ul><li>Software Development Capability Evaluation </li></ul><ul><ul><li>published: 15 Jun 95 </li></ul></ul><ul><li>structured methodology for assessing an organization’s ability to develop software for mission-critical computer resources </li></ul><ul><li>primary purpose is to reduce acquisition risk for software-intensive systems </li></ul><ul><ul><li>conducted as an integral part of the source selection process </li></ul></ul><ul><ul><li>addresses each offerer’s ability to develop the software required by a specific Request for Proposal </li></ul></ul>Reference: www.software.org/quagmire
  37. 37. Problems with SW-CMM
  38. 38. Issues with the CMM <ul><li>key process areas (KPAs) focus mostly on activities and supporting artifacts associated with a conventional waterfall process </li></ul><ul><ul><li>requirements specifications, documented plans, quality assurance audits and inspections, and documented processes and procedures </li></ul></ul><ul><li>very few of the KPAs address the evolving results (i.e., the software product) and associated engineering artifacts (use case models, design models, source code, or executable code) </li></ul>Reference: Royce, CMM vs. CMMI
  39. 39. Issues (cont’d) <ul><li>no emphasis on the architecting/design process, assessment process, or deployment process </li></ul><ul><ul><li>which have proven to be key discriminators for project success </li></ul></ul><ul><li>also overemphasizes peer reviews, inspections and traditional Quality Assurance “policing” methods </li></ul><ul><ul><li>although manual reviews and inspections may be capable of uncovering 60% of errors, they rarely uncover the architecturally significant flaws… </li></ul></ul>Reference: Royce, CMM vs. CMMI
  40. 40. Issues (cont’d) <ul><li>most implementations of CMM drive organizations to produce more documents, more checkpoints, more artifacts, more traceability, more reviews, and more plans </li></ul><ul><ul><li>thicker documents, more detailed information, and longer meetings are considered better </li></ul></ul>Reference: Royce, CMM vs. CMMI
  41. 41. Issues (cont’d) <ul><li>hard to accurately measure an organization’s current maturity level </li></ul><ul><ul><li>CMM takes an activity based approach to measuring maturity </li></ul></ul><ul><ul><ul><li>set of foundation project activities = Level 2 </li></ul></ul></ul><ul><ul><ul><li>set of activities as an organization = Level 3 </li></ul></ul></ul><ul><ul><li>nothing that characterizes or quantifies whether you do these activities well enough to deliver the intended results </li></ul></ul>Reference: Royce, CMM vs. CMMI
  42. 42. More Short-Comings of CMM <ul><li>not a silver bullet </li></ul><ul><ul><li>a mature process is no guarantee of a quality product </li></ul></ul><ul><li>not well suited for smaller companies/projects </li></ul><ul><ul><li>Personal Software Process (PSP) is one attempt to address this need </li></ul></ul><ul><li>crude and harsh 5-point scale </li></ul><ul><ul><li>if you fail just one of the KPAs, you fail the level </li></ul></ul>
  43. 43. Evolution of CMM <ul><li>initial Capability Maturity Model was developed specifically to address software process maturity </li></ul><ul><li>it was successfully adopted and used in many domains </li></ul><ul><li>other CMMs were developed for other disciplines and functions </li></ul><ul><li>CMMs now exist for software, people, software acquisition, systems engineering, and integrated product development </li></ul>
  44. 44. Other Capability Maturity Models
  45. 45. Back to the Map
  46. 46. SA-CMM <ul><li>Software Acquisition Capability Maturity Model </li></ul><ul><ul><li>published: Version 1.01, December 1996 </li></ul></ul><ul><li>a model for benchmarking and improving the software acquisition process </li></ul><ul><li>follows the same architecture as the Capability Maturity Model for Software (SW-CMM), but with a unique emphasis on </li></ul><ul><ul><li>acquisition issues </li></ul></ul><ul><ul><li>needs of individuals/groups planning software acquisition efforts </li></ul></ul><ul><ul><li>focused on the Buyer’s or Acquirer’s Software Acquisition Process </li></ul></ul>Reference: www.software.org/quagmire
  47. 47. SA-CMM Maturity Levels Reference: www.software.org/quagmire No KPAs at this level Competent people and heroics Level 1 Initial Transition to Support Evaluation Contract Tracking and Oversight Project Management Requirements Development and Management Solicitation Software Acquisition Planning Basic project management Level 2 Repeatable Training Program Acquisition Risk Management Contract Performance Management Project Performance Management Process Definition and Maintenance Process standardization Level 3 Defined Quantitative Acquisition Management Quantitative Process Management Quantitative management Level 4 Quantitative Acquisition Innovation Management Continuous Process Improvement Continuous process improvement Level 5 Optimizing Key Process Areas Focus Level
  48. 48. Back to the Map
  49. 49. P-CMM <ul><li>People Capability Maturity Model </li></ul><ul><ul><li>published: July 2001 </li></ul></ul><ul><li>describes the key elements of managing and developing the work force of an organization </li></ul><ul><li>describes an evolutionary path </li></ul><ul><ul><li>from an ad hoc approach to managing the workforce </li></ul></ul><ul><ul><li>to a mature, disciplined development of the knowledge, skills, and motivation of the people that fuel enhanced performance </li></ul></ul>Reference: www.software.org/quagmire
  50. 50. P-CMM (cont’d) <ul><li>purpose is to enhance the readiness of software development and information systems organizations to undertake increasingly complex applications by helping them to attract, grow, motivate, deploy, and retain the talent necessary to improve their software development capability </li></ul>Reference: www.software.org/quagmire
  51. 51. P-CMM Maturity Levels Reference: www.software.org/quagmire Participatory Culture Competency-Based Practices Career Development Competency Development Workforce Planning Knowledge and Skills Analysis Level 3 Defined Organizational Performance Alignment Organizational Competency Management Team-Based Practices Team Building Mentoring Level 4 Managed Continuous Workforce Innovation Coaching Personal Competency Development Level 5 Optimizing Key Process Areas Level
  52. 52. P-CMM Maturity Levels (cont’d) Reference: www.software.org/quagmire No KPAs at this level Level 1 Initial Compensation Training Performance Management Staffing Communication Work Environment Level 2 Repeatable Key Process Areas Level
  53. 53. Back to the Map
  54. 54. SE-CMM <ul><li>Systems Engineering Capability Maturity Model </li></ul><ul><ul><li>published: November 1995 </li></ul></ul><ul><li>describes the essential elements of an organization’s systems engineering process that must exist to ensure good systems engineering </li></ul><ul><li>18 process areas (PAs) are grouped into categories </li></ul><ul><ul><li>Engineering </li></ul></ul><ul><ul><li>Project </li></ul></ul><ul><ul><li>Organization </li></ul></ul>Reference: www.software.org/quagmire
  55. 55. SE-CMM (cont’d) <ul><li>still 5 levels (counted in each PA?) </li></ul><ul><ul><li>1 – Generic Practices </li></ul></ul><ul><ul><li>2 – Planned and Tracked </li></ul></ul><ul><ul><li>3 – Well-Defined </li></ul></ul><ul><ul><li>4 – Quantitatively Controlled </li></ul></ul><ul><ul><li>5 – Continuously Improving </li></ul></ul><ul><li>built onto the Software CMM framework </li></ul><ul><ul><li>but used the two-axis architecture of the ISO SPICE model </li></ul></ul><ul><li>replaced SECM merged systems engineering model (EIA/IS 731) </li></ul>Reference: www.software.org/quagmire
  56. 56. Back to the Map
  57. 57. SSE-CMM <ul><li>Systems Security Engineering CMM </li></ul><ul><ul><li>published: 1 Apr 99 (Version 2.0) </li></ul></ul><ul><li>describes the essential characteristics of an organization’s security engineering process that must exist to ensure good security engineering </li></ul><ul><li>objective is to advance security engineering as a defined, mature, and measurable discipline </li></ul><ul><li>… </li></ul>Reference: www.software.org/quagmire
  58. 58. Back to the Map
  59. 59. IPD-CMM <ul><li>Integrated Product Development Capability Maturity Model </li></ul><ul><ul><li>published: no longer published; halted in Nov 1997 </li></ul></ul><ul><li>developed by Enterprise Process Improvement Collaboration (EPIC) </li></ul><ul><li>to serve as a framework for improvement of </li></ul><ul><ul><li>processes for the entire product life cycle and </li></ul></ul><ul><ul><li>processes for integrating product development efforts across the enterprise </li></ul></ul>Reference: www.software.org/quagmire
  60. 60. IPD-CMM <ul><li>built on a continuous model architecture like the Systems Engineering CMM </li></ul><ul><li>adds the concept of organizational stages, similar to organizational maturity levels in the SW-CMM </li></ul><ul><li>development halted in Nov 1997 </li></ul><ul><ul><li>model had serious problems with complexity, overlap with other models, and lack of IPD content beyond team practices </li></ul></ul><ul><ul><li>EPIC decided to end the development and provide content to the CMMI effort </li></ul></ul>Reference: www.software.org/quagmire
  61. 61. So Many CMMs <ul><li>many organizations found these models to be useful </li></ul><ul><li>but struggled with problems caused by overlap, inconsistencies, and integration </li></ul><ul><li>many organizations also confronted conflicting demands between these models and ISO 9001 audits or other process improvement programs </li></ul>Reference: Royce, CMM vs. CMMI
  62. 62. Back to the Map
  63. 63. Integration <ul><li>CMM Integration (CMMI) project was conceived as an initiative to integrate the various CMMs into a set of integrated models </li></ul><ul><li>reduce redundancy and eliminate inconsistency experienced by those using multiple standalone models </li></ul>Reference: Royce, CMM vs. CMMI
  64. 64. Overview of CMMI
  65. 65. CMMI <ul><li>Capability Maturity Model Integration </li></ul><ul><ul><li>published: draft version 1.02b, Dec 2001 </li></ul></ul><ul><li>included </li></ul><ul><ul><li>systems engineering and software </li></ul></ul><ul><ul><li>IPPD (integrated product and process development) </li></ul></ul><ul><ul><li>some acquisition (draft) </li></ul></ul><ul><li>US DoD tasked the Software Engineering Institute (SEI) to integrate the capability maturity model </li></ul><ul><li>SEI is the current steward of the CMMI model </li></ul>Reference: www.software.org/quagmire
  66. 66. CMMI (cont’d) <ul><li>source models </li></ul><ul><ul><li>SW-CMM version 2.0 draft </li></ul></ul><ul><ul><li>EIA/IS 731 SECM (which replaced SE-CMM) </li></ul></ul><ul><ul><li>draft version of IPD-CMM (integrated product development) </li></ul></ul><ul><ul><li>some items from SA-CMM </li></ul></ul><ul><li>these sources will no longer be updated or supported by their issuing organizations </li></ul><ul><li>goal is to absorb more source models in the same way </li></ul>Reference: www.software.org/quagmire
  67. 67. CMMI Product Suite Naming <ul><li>each CMMI model is given a name consisting of “CMMI-” followed by the abbreviation for the discipline </li></ul><ul><ul><li>CMMI-SE/SW – systems engineering and software engineering integrated model </li></ul></ul><ul><ul><li>CMMI-SE/SW/IPPD – systems engineering, software engineering, integrated product and process development integrated model </li></ul></ul><ul><ul><li>CMMI-SE/SW/IPPD/SS - systems engineering, software engineering, integrated product and process development, supplier sourcing integrated model </li></ul></ul>Reference: www.sei.cmu.edu/cmmi/adoption/cmmi-faq.html
  68. 68. Purpose of CMMI <ul><li>to provide guidance for improving the organization’s processes and ability to manage the </li></ul><ul><ul><li>development </li></ul></ul><ul><ul><li>acquisition </li></ul></ul><ul><ul><li>maintenance </li></ul></ul><ul><li>of products and services </li></ul>Reference: www.sei.cmu.edu/cmmi/general /
  69. 69. Purpose of CMMI (cont’d) <ul><li>places proven practices into a structure that helps the organization </li></ul><ul><ul><li>assess its organizational maturity and process area capability </li></ul></ul><ul><ul><li>establish priorities for improvement </li></ul></ul><ul><ul><li>guide the implementation of these improvements </li></ul></ul>Reference: www.sei.cmu.edu/cmmi/general /
  70. 70. Purpose of CMMI <ul><li>CMMI is a framework that describes the essential elements of an effective system or software engineering process </li></ul><ul><li>in the software context, forms the basis for </li></ul><ul><ul><li>software process assessment </li></ul></ul><ul><ul><li>software process improvement </li></ul></ul><ul><ul><li>software capability evaluation </li></ul></ul><ul><li>related to ISO Software Process Improvement and Capability Evaluation (SPICE) program and ISO 15504 </li></ul>
  71. 71. Core Concepts <ul><li>Software Process Capability </li></ul><ul><ul><li>the range of expected results that can be achieved by following a software process </li></ul></ul><ul><li>Software Process Performance </li></ul><ul><ul><li>the actual results achieved by following a software process </li></ul></ul><ul><li>Software Process Maturity </li></ul><ul><ul><li>the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective </li></ul></ul>
  72. 72. CMMI Maturity Levels Initial (1) Managed (2) Defined (3) Quantitatively Managed (4) Optimizing (5) Disciplined process Standard, consistent process Predictable process Continuously improving process
  73. 73. CMMI Maturity Levels Initial (1) Managed (2) Defined (3) Quantitatively Managed (4) Optimizing (5) Disciplined process Standard, consistent process Predictable process Continuously improving process Initial (1) Repeatable (2) Defined (3) Managed (4) Optimizing (5) Basic Management Control Process Definition Process Measurement Process Control SW-CMM Not capability levels
  74. 74. Levels and Process Areas <ul><li>elements of CMMI are called Process Areas (not Key Process Areas or Focus Areas) </li></ul>Reference: www.software.org/quagmire
  75. 75. The Five Maturity Levels of CMMI <ul><li>Level 1 – Initial </li></ul><ul><ul><li>process maturity characterized by unpredictable results </li></ul></ul><ul><ul><li>ad hoc approaches, methods, notations, tools, and reactive management </li></ul></ul><ul><ul><li>translate into a process dependent predominantly on the skills of the team to succeed </li></ul></ul>Reference: Royce, CMM vs. CMMI
  76. 76. The Five Maturity Levels of CMMI (cont’d) <ul><li>Level 2 – Managed </li></ul><ul><ul><li>process maturity characterized by repeatable project performance </li></ul></ul><ul><ul><li>organization uses foundation disciplines for </li></ul></ul><ul><ul><ul><li>requirements management </li></ul></ul></ul><ul><ul><ul><li>project planning </li></ul></ul></ul><ul><ul><ul><li>project management and control </li></ul></ul></ul><ul><ul><ul><li>supplier agreement management </li></ul></ul></ul><ul><ul><ul><li>product and process quality assurance </li></ul></ul></ul><ul><ul><ul><li>configuration management </li></ul></ul></ul><ul><ul><ul><li>measurement/analysis </li></ul></ul></ul><ul><ul><li>key process focus is on project-level activities and practices </li></ul></ul>Reference: Royce, CMM vs. CMMI
  77. 77. The Five Maturity Levels of CMMI (cont’d) <ul><li>Level 3 – Defined </li></ul><ul><ul><li>process maturity characterized by improving project performance within an organization </li></ul></ul><ul><ul><li>consistent, cross-project disciplines for Level 2 key process areas are emphasized to establish organization-level activities and practices </li></ul></ul><ul><ul><li>additional process areas </li></ul></ul><ul><ul><ul><li>requirements development </li></ul></ul></ul><ul><ul><ul><ul><li>multi-stakeholder requirements evolution </li></ul></ul></ul></ul><ul><ul><ul><li>technical solution </li></ul></ul></ul><ul><ul><ul><ul><li>evolutionary design and quality engineering </li></ul></ul></ul></ul>Reference: Royce, CMM vs. CMMI
  78. 78. The Five Maturity Levels of CMMI (cont’d) <ul><ul><ul><li>product integration </li></ul></ul></ul><ul><ul><ul><ul><li>continuous integration, interface control, change management </li></ul></ul></ul></ul><ul><ul><ul><li>verification </li></ul></ul></ul><ul><ul><ul><ul><li>assessment techniques to ensure that the product is built correctly </li></ul></ul></ul></ul><ul><ul><ul><li>validation </li></ul></ul></ul><ul><ul><ul><ul><li>assessment techniques to ensure that the right product is built </li></ul></ul></ul></ul><ul><ul><ul><li>risk management </li></ul></ul></ul><ul><ul><ul><ul><li>detection, prioritization, and resolution of relevant issues and contingencies </li></ul></ul></ul></ul>Reference: Royce, CMM vs. CMMI
  79. 79. The Five Maturity Levels of CMMI (cont’d) <ul><ul><ul><li>organizational training </li></ul></ul></ul><ul><ul><ul><ul><li>establishing mechanisms for developing more proficient people </li></ul></ul></ul></ul><ul><ul><ul><li>organizational process focus </li></ul></ul></ul><ul><ul><ul><ul><li>establishing an organizational framework for project process definition </li></ul></ul></ul></ul><ul><ul><ul><li>decision analysis and resolution </li></ul></ul></ul><ul><ul><ul><ul><li>systematic alternative assessment </li></ul></ul></ul></ul><ul><ul><ul><li>organizational process definition </li></ul></ul></ul><ul><ul><ul><ul><li>treatment of process as a persistent, evolving asset of an organization </li></ul></ul></ul></ul><ul><ul><ul><li>integrated project management </li></ul></ul></ul><ul><ul><ul><ul><li>methods for unifying the various teams and stakeholders within a project </li></ul></ul></ul></ul>Reference: Royce, CMM vs. CMMI
  80. 80. The Five Maturity Levels of CMMI (cont’d) <ul><li>Level 4 – Quantitatively Managed </li></ul><ul><ul><li>process maturity characterized by improving organization performance </li></ul></ul><ul><ul><li>historical results for Level 3 projects can be exploited to make trade offs with predictable results </li></ul></ul><ul><ul><li>additional Level 4 process areas include </li></ul></ul><ul><ul><ul><li>organizational process performance </li></ul></ul></ul><ul><ul><ul><ul><li>setting norms and benchmarks for process performance </li></ul></ul></ul></ul><ul><ul><ul><li>quantitative project management </li></ul></ul></ul><ul><ul><ul><ul><li>executing projects based on statistical quality-control methods </li></ul></ul></ul></ul>Reference: Royce, CMM vs. CMMI
  81. 81. The Five Maturity Levels of CMMI (cont’d) <ul><li>Level 5 – Optimized </li></ul><ul><ul><li>process maturity characterized by rapidly reconfigurable organizational performance </li></ul></ul><ul><ul><li>as well as quantitative, continuous process improvement </li></ul></ul><ul><ul><li>additional Level 5 process areas include </li></ul></ul><ul><ul><ul><li>causal analysis and resolution </li></ul></ul></ul><ul><ul><ul><ul><li>proactive fault avoidance and best practice reinforcement </li></ul></ul></ul></ul><ul><ul><ul><li>organizational innovation and deployment </li></ul></ul></ul><ul><ul><ul><ul><li>establishing a learning organization that organically adapts and improves </li></ul></ul></ul></ul>Reference: Royce, CMM vs. CMMI
  82. 82. Representations (cont’d) <ul><li>two representations </li></ul><ul><ul><li>provide alternative approaches to process improvement for familiarity with either approach </li></ul></ul><ul><li>represent two different philosophical approaches to process improvement </li></ul>Reference: Menezes, CrossTalk; www.stsc.hill.af.mil/cmmi/more_cmmi.asp
  83. 83. Representations (cont’d) <ul><li>1. focus on the organization as a whole and provide a road map of successive stages aimed at improving the organization’s ability to understand and control its process </li></ul><ul><ul><li>staged view (comparable to SW-CMM) </li></ul></ul><ul><li>2. focus on individual processes, allowing the organization to choose which process or set of processes need to have more capability </li></ul><ul><ul><li>continuous view (comparable to systems engineering and IPD models) </li></ul></ul>Reference: Menezes, CrossTalk
  84. 84. Representations (cont’d) <ul><li>each representation is a 600 page document </li></ul><ul><li>equivalent staging </li></ul><ul><ul><li>sometimes desirable to convert an organization’s capability level achievements into a maturity level </li></ul></ul><ul><li>can translate back and forth between </li></ul><ul><ul><li>CMMI includes rules for determining which capability levels must be satisfied in each process area to achieve each maturity level </li></ul></ul>Reference: Menezes, CrossTalk; www.stsc.hill.af.mil/cmmi/more_cmmi.asp
  85. 85. Continuous <ul><li>groups process areas into </li></ul><ul><ul><li>process management </li></ul></ul><ul><ul><li>project management </li></ul></ul><ul><ul><li>engineering </li></ul></ul><ul><ul><li>support </li></ul></ul><ul><li>for each process area, assigns a rating from 0 to 5, according to an organization’s performance </li></ul>
  86. 86. Staged <ul><li>groups process areas by maturity level </li></ul><ul><li>allows an overall assessment leading to an assessment of the maturity level observed in an organization </li></ul>
  87. 87. Some Differences between Representations Reference: www.sei.cmu.edu/cmmi/adoption/cmmi-faq.html no equivalence concept to go from maturity level to a target profile additional appendix describing equivalent staging; allows translation of a target profile into a maturity level improvement is measured using maturity levels that reflect the concurrent implementation of multiple process areas improvement is measured using capability levels that reflect incremental implementation of a particular process area five maturity levels (1-5) six capability levels (0-5) process areas organized by maturity levels process areas organized by process area categories Staged Continuous
  88. 88. Summary <ul><li>Review of Motivation </li></ul><ul><li>Review of SW-CMM </li></ul><ul><ul><li>Problems with SW-CMM </li></ul></ul><ul><li>Other Capability Maturity Models </li></ul><ul><ul><li>SA-CMM, P-CMM, SE-CMM, SSE-CMM, IPD-CMM </li></ul></ul><ul><li>CMMI </li></ul><ul><ul><li>Purpose of CMMI </li></ul></ul><ul><ul><li>CMMI Maturity Levels </li></ul></ul><ul><ul><li>Representations </li></ul></ul>
  89. 89. ?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×