A Report on The Capability Maturity Model
Hakan Bayraksan – hxb07u
29 November 2009 – G53QAT
Table of Contents
Introduction...2
The evolution of CMMI ...3
CMM ... 3
CMMI ... 3
The definition of CMMI... 4
Level 1 -‐ Ad hoc (Chaotic) ...5
Level 2 – Repeatable...5
Level 3 – Defined...5
Level 4 -‐ Managed ...5
Level 5 -‐ Optimized ...6
Process Areas...6
Continuous vs. Staged CMMI ...7
According to the SEI website, this year $1.000.000.000.000 will be spent on IT projects, but in recent years only %35 of IT projects are completed in accordance with their budget, time and feature constraints. Considering the fact that for approximately every project that is completed successfully, there are two projects that fail AND that the reasons for projects failing are entirely preventable; it is obvious that steps towards the improvement of the software development process must be taken. Bearing in mind that with governmental and military software contracts, money that is spent on the development of these projects is actually taxpayers money so wasting it isn’t a viable option. Carnegie Mellon University created the Capability Maturity Model in 1987 as a participant to a United States Department of Defence competition created which had the aim of software development process improvement.
The evolution of CMMI
CMM
The Capability Maturity Model was the predecessor to the Capability Model Integration, it’s a development model that was created by analysing data collected by the US Department of Defence from software development projects. This makes it different from other development improvement models since it isn’t based on theory but actual data. Since the CMM wasn’t a Software Development Life Cycle but rather a process improvement project it was obvious that it could be used in more than only software development. This is where the Capability Maturity Model evolved into the Capability Maturity Model integration.
CMMI
When the Software Engineering Institute at Carnegie Mellon University saw that CMM could be applied to a more diverse range of fields they had to define CMM in a much more vague way which removed any connotation of “Software development” from its meaning. To distinguish the difference they added “Integration” to imply that the process development technique can be integrated into many different areas.
The Definition of CMMI
Capability Maturity Model Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization.
{taken from Wikipedia}
As the definition suggests, the Capability Maturity Model can be used on different levels as well as different areas. Depending on requirements and needs an organization can decide on which level they want to apply CMMI. The most important thing about CMMI is that (like CMM), it isn’t a Software Development Lifecycle, but rather a way to improve the lifecycle (in the case of CMMI-‐DEV) already in use at a particular organization or which ever way an organization proceeds with their projects. There are six branches in the CMMI Constellation* tree.
1) Product and service development (CMMI for Development)
2) Service establishment, management, and delivery (CMMI for Services) 3) Product and service acquisition (CMMI for Acquisition)
4) Security (CMMI for Security) 5) Risk (CMMI for Risk)
6) Systems Design (CMMI for Systems design)
Constellations are then split into levels and levels into process areas, the process areas shared by all constellations are shown in the table below.
Level Focus Process Area
5 – Optimizing Continuous Process
Improvement
o Organizational Innovation &
Deployment
o Causal Analysis & Resolution 4 – Quantitatively
Managed
Quantitative Management
o Organizational Process Performance o Quantitative Project Management
3 – Defined Process
Standardization
o Requirements Development o Technical Solution
o Product Integration o Verification
o Validation
o Organizational Process Focus o Organizational Process Definition o Organizational Training
o Integrated Project Management
Management o Project Planning Project Monitoring
& Control
o Supplier Agreement Management o Measurement and Analysis
o Process & Product Quality Assurance
o Configuration Management
1 – Initial Competent People
As the table suggests Levels are the ratings an organization receives by the CMMI Appraiser and Process Areas are the “things” that the organization has to complete or implement in order to reach a particular level. The levels can be defined in the following way:
Level 1 -‐ Ad hoc (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.
Level 2 – Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.
Level 3 – Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time.
These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.
Level 4 -‐ Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
Level 5 -‐ Optimized
It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.
Taken from Wikipedia
Process Areas
Process areas are the aspects of the organization that are going to be covered by the product improvement process. The list of Process Areas shared by all three CMMI constellations is listed in the table above. Every Process Area has its own set of goals and practices that have to be completed and followed to reach the requirements for that specific level. The goals and practices that are included in all PA’s are as follows Generic Goals and Practices
• GG 1 Achieve Specific Goals
o GP 1.1 Perform Specific Practices
• GG 2 Institutionalize a Managed Process
o GP 2.1 Establish an Organizational Policy
o GP 2.2 Plan the Process
o GP 2.3 Provide Resources
o GP 2.4 Assign Responsibility
o GP 2.5 Train People
o GP 2.6 Manage Configurations
o GP 2.7 Identify and Involve Relevant Stakeholders
o GP 2.8 Monitor and Control the Process
o GP 2.9 Objectively Evaluate Adherence
o GP 2.10 Review Status with Higher Level Management
• GG 3 Institutionalize a Defined Process
o GP 3.1 Establish a Defined Process
o GP 3.2 Collect Improvement Information
• GG 4 Institutionalize a Quantitatively Managed Process
o GP 4.1 Establish Quantitative Objectives for the Process
o GP 4.2 Stabilize Sub-process Performance
• GG 5 Institutionalize an Optimizing Process
o GP 5.1 Ensure Continuous Process Improvement
o GP 5.2 Correct Root Causes of Problems
From their names it is rather straight forward what the goals and practices aim at completing, apart from these each PA has its own goals and practices. These can be found in the individual handbooks, e.g. the development version can be found at:
http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm
ways of looking at the same data. After CMMI came into play in 1997, many companies investing in it to improve their business practices found that not all of the PA’s applied to their organization or were already in place in a different form. This led to the Software Engineering Institute forming the continuous representation; in this method organizations could choose to improve in PA’s relative to their task in order to reach certain appraisal level. In the staged CMMI method, an organization would have to mature in all process areas of a certain level in order to mature to the next level. The main point that should be noted is that though it sounds like different PA’s should be completed to reach the next level in continuous CMMI it is more about achieving generic goals and therefore isn’t about companies mixing up PA’s in order to reach a continuous level in CMMI.
As the name “ Capability Maturity Model Integration” suggests there is a Capability and a Maturity level that “should” be separately achieved. In fact the difference between these are as simple as the difference between Continuous and Staged CMMI. Capability Level Appraisal are given to organizations who choose to use the Continuous approach to CMMI whereas Maturity Level Appraisals are given to organizations who choose the Maturity Level. The definitions of these two words are very important if we think about it, being capable is very different from being mature. Companies that are appraised in the staged approach show that they have matured to a certain level by completing all PA’s relative to them, where as appraisal in the continuous approach shows that a company has chosen to be as capable as possible in subjects that matter to it.
References
o The IEEE Website, Spectrum Blog, accessed on 20/11/2009
o http://spectrum.ieee.org/computing/software/why-‐software-‐fails o Wikipedia, accessed between 10-‐25/11/2009
o http://en.wikipedia.org/wiki/Process_area_%28CMMI%29
o http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration o http://en.wikipedia.org/wiki/Software_engineering
o http://en.wikipedia.org/wiki/Capability_maturity_model
o http://en.wikipedia.org/wiki/Standard_CMMI_Appraisal_Method_for_Pr ocess_Improvement
o The Entinex CMMI FAQ Website, accessed between 14/25/2009 o http://www.cmmifaq.info/
o The Software Institute Engineering Website at CMU, accessed between 10-‐
25/11/2009
o http://www.sei.cmu.edu/
