An explanation of what CMMi for Development is and how the official CMMi-DEV document is structured.
An overview of CMMi for Software Development |
||||||||||||||||||||||||||||||||||||||||||
|
Article PurposeCMMi® stands for Capability Maturity Model® Integration and it is a process improvement maturity model that has been developed by the Software Engineering Institute, SEI, at Carnegie Mellon. It is important to note that CMMi defines what processes and activities need to be done and not how these processes and activities are done. The goal of CMMi is process improvement and CMMi can be thought of as a Software Process Improvement, SPI, framework. The latest version of CMMi (1.2) was released in August 2006. There are 3 areas addressed by this version of CMMi, namely: CMMi Development, CMMi Services and CMMi Acquisition. This article explains the CMMi for Development CMMi-DEV. CMMi® for Development, Version 1.2, contains 573 pages and is organized around 22 process areas that represent the core processes for software development. The 22 process areas of CMMi for Development are:-
For each process area a list of practices (or capabilities) is given. The idea being that a software development organization improves their capability by implementing the practices documented. There are a number of levels of capability which are achieved by applying more definition and control to the key development processes. The level of capability (of a given software development organization) can be assessed by an independent auditor, usually external. By way of example the practices (which are grouped by goals) for the Requirements Management (REQM) process area are:- Specific Goal 1 (SG 1) Manage Requirements. Note that the practices only define what is needed to be done and not how, for example SP 1.4 Maintain Bidirectional Traceability of Requirements, can be achieved using a Traceability Matrix but only the goal and practices are stated. SP 1.4 could also be achieved using a database of cross references or some other mechanism, the intent of CMMi is to describe what capabilities a software development process should have and not prescribe how those capabilities are achieved. This gives organizations the flexibility to implement an appropriate solution to achieve the capabilities in their unique environments. For any level of process capability, beyond the basic incomplete or initial (discussed later), all of the specific practices have to be implemented. In addition to the Specific Practices (SP), as illustrated above, there are Generic Practices (GP). It is the generic practices that determine what capability level an organization has reached, with respect to a given process. Extending the Manage Requirements process area, to include the generic practices, we would include the following (arranged by goal, or in this case generic goal (GG)):- Generic Goal 1 (GG 1) Achieve Specific Goals. Generic Goal 2 (GG 2) Institutionalize a Managed Process. Generic Goal 3 (GG 3) Institutionalize a Defined Process. Generic Goal 4 (GG 4) Institutionalize a Quantitatively Managed Process. Generic Goal 5 (GG 5) Institutionalize an Optimizing Process. A clear pattern can be seen, with reference to the Manage Requirements process area, across all the 22 process areas of CMMi. That is each process area has specific goals with practices that must be implemented. When the specific practices are implement then the first generic goal is achieved, the first generic goal in all the process areas is perform specific practices. This will get the organization to a level 2 capability. Then to gain higher capability levels the organization needs to apply the generic practices which will bring the process under increasing control, moving from capability 0, incomplete, thru to capability 5, optimizing. The following table maps the capability level with the generic practices that have been implemented.
The above capability mapping for all 22 processes is the same as the example Requirements Management process area. The specific goals and practices will be unique to the process area whilst the generic goals and practices will be similar, hence the terms specific and generic. One major complication for the reader of CMMi-DEV is that there are 2 maturity (or capability) hierarchies. This is because there are 2 separate implementation paths for CMMi. The first path is known as continuous and is described above. The second implementation path is known as staged and refers to an implementation path under which the order of which process areas are subjected to process improvement is important. The staged implementation path prescribes a set of process areas that need to be implemented for each capability level. Also the staged implementation has maturity levels in place of capability levels. The same principles, as for the continuous implementation method described above, apply to a staged implementation. In all cases the specific practices need to be implemented then the maturity level increases as the generic goals and practices are implemented. The process area definitions as well as the specific goals are the same for both staged and continuous implementation paths. For more information on the staged implementation method, as well as a detailed description of CMM-DEV, see the official CMMI-DEV V1.2 documentation. For more information on SCAMPI, Standard CMMI Appraisal Method for Process Improvement, click here. If anyone is interested in using CMMi-DEV as the basis for establishing a comprehensive software process improvement framework, without the goal of being formally audited, then a good place to start is to select the process areas that are the most problematic within your organization and then implement the specific practices for those process areas. Following that other processes should be implemented, as per the specific practices, and then the generic goals should be incrementally pursued, as per the continuous implementation methodology. |
||||||||||||||||||||||||||||||||||||||||||
No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-