Capability Maturity Modeling - Background
The initial CMMI product suite includes a framework for generating CMMI products, and a set of CMMI products produced by the framework. The framework includes common elements and best features of the existing models as well as rules and methods for generating CMMI products. Users may select discipline specific elements of the CMMI product suite based on their business objectives and mission needs. The CMMI product suite will consist of:
- Framework
- Capability Maturity Model Integration Models
- Training Products Assessment Products
- Glossary
Early CMM Models
Definition
A capability maturity model delineates the characteristics of a mature, capable process. It identifies the practices that are basic to implementing effective processes as well as advanced practices. It also assigns to those practices associated maturity levels ranging from unrepeatable to a mature, well-managed process. Typically a path is recommended through the various practices for achieving higher levels of maturity and, therefore, improve an organization's processes.
History of CMMs
in the mid 1980s, the Cold War was still warm, and the U.S. Department of Defense was increasingly relying on computers for all aspects of its operations. The computers were puny compared with today's, and military computers had to meet stringent environmental and reliability requirements that made them even bigger, heavier and slower than civilian machines.
Graphical operating systems and applications were starting to appear, and most military software was developed by external contractors. The DOD badly needed a way to determine whether contractors could provide software on time, within budget and to specifications.
The answer came from Carnegie Mellon University's Software Engineering Institute. Its Capability Maturity Model was a way to assess and describe the quality of an organization's software development. First released around 1990, CMM was eventually extended to other process areas. SEI began the development of a process improvement model for software engineering in 1988. In August 1991 the first version of the Capability Maturity Model for Software (SW-CMM) was published by the SEI. Subsequently, the Enterprise Process Improvement Collaboration (EPIC), an industry and government collaborative effort, developed and published the Systems Engineering Capability Maturity Model (SE-CMM), and the International Council on Systems Engineering (INCOSE) developed and published the Systems Engineering Capability Assessment Model (SECAM). Additional CMMs were also developed, including: the Software Acquisition CMM, the People CMM, and the Integrated Product Development CMM. Some business domains have also produced their own CMMs. Interest grew in combining the existing systems engineering CMMs into a single systems engineering model. The Electronic Industries Alliance (EIA) in concert with EPIC and INCOSE began an effort to consolidate the two Systems Engineering CMMs. The resulting systems engineering CMM was termed the Systems Engineering Capability Model (SECM) and was assigned the designation EIA/IS-731. Some organizations developed CMMs integrating several disciplines such as the Federal Aviation Administration's integrated Capability Maturity Model (FAA-iCMM). As the SW-CMM Version 2.0 was completing its review process, OSD directed that the CMMI project be undertaken as a collaborative industry, government and SEI effort and that the CMM Version 2.0 be cancelled as a stand-alone CMM and replaced by the software version of the CMMI product suite.
Need for Transition to CMMI
|
| History of CMMI Versions |
Problems with Early CMMs
The SW-CMM was a "roadmap" that described "evolutionary stages" consisting of key practices that guide organizations in improving their software capability. Several systems engineering maturity models supported systems engineering process improvement. The EPIC SE-CMM and the INCOSE SECAM were alternative models were amalgamated with the EIA to create EIA/IS-731. All of the systems engineering models shared similar principles. This had two principles consequences: (1), the content of SW-CMM and the system engineering models overlapped; for example, all dealt with requirements, project management, process definition, etcR, (2) the systems engineering models were based on a different representation than the SW-CMM and similar to that of ISO/IEC 15504. This representation described the entire "process area terrain" with less emphasis on exactly how an organization might mature throughout. Process areas spanned levels rather than being defined within a maturity level as in the SW-CMM. The systems engineering models employed what was termed a 'continuous representation'; that is, capability levels for each process area were described independently of the others. SW-CMM employed a staged representation; that is, process areas were grouped into collections and aligned with maturity levels. As well, improvement efforts based on more than one unique CMM would likely result in sub-optimization, confusion, and potentially unnecessary expenditure of process improvement resources.
With the various models for software engineering and systems engineering containing common processes, it was recognized that improvements made to one discipline could benefit the other. Also, assessments made for one discipline could be used for other discipline assessments thus eliminating redundant assessments.
CMM-Integrated Version 1.1
Several events in combination made it evident that the time was right to begin developing an integrated CMM framework. These occurrences included the following:
- A first step had already been taken to merge the two existing systems engineering models (the SE-CMM and the SECAM into EIA/IS-731).
- A major update (Version 2.0) to the SW-CMM was nearing completion.
- The proliferation of CMMs was escalating.
- Organizations operating in more than one discipline were becoming acutely aware of the problems of trying to improve integrated processes using separate, sometimes inconsistent CMMs.
- Sufficient experience in developing CMMs and abundant experience in using CMMs increased the likelihood that an integrated framework for a family of CMMs could be developed.
Thus, a requirement was formulated for a Capability Maturity Model-Integrated (CMMI) product suite. The suite would include a framework for generating CMMI products. The generated products would be based on CMMI models for specified disciplines and discipline combinations, training products, assessment materials, glossary terms, and tailoring requirements. The disciplines initially specified include Systems Engineering, Software Engineering, and Integrated Product and Process Development.
Value of CMMI
The CMMI includes a common set of process areas which form the core of an integrated capability model that integrates process improvement guidance for systems engineering, software engineering, and Integrated Product and Process Development (IPPD). The CMMI product suite provides an integrated approach to reducing the redundancy and complexity resulting from the use of separate, multiple capability maturity models (CMMs). The CMMI products should improve the efficiency of and the return on investment for process improvement. The resulting integrated capability models can be tailored to an organization's mission and business objectives.
CMMI comes in two basic flavors: staged and continuous. Staged CMMI is the better known, with its five levels of maturity (see diagram below). It enables comparisons between organizations and offers a proven sequence for improvement.
Continuous representation of CMMI lets an organization select specific improvements that best meet its business objectives and minimize risk, while perhaps making it easier to compare processes across projects and to transition from other quality standards. Both CMMI representations are designed to provide equivalent results.
CMMI Version 1.2
CMMI for Development (CMMI-DEV), Version 1.2 is an upgrade of CMMI-Integrated, Version 1.1. The focus of the CMMI Version 1.2 effort is on improving the quality of CMMI products and the consistency of how they are applied.
Version 1.2 includes the concept of CMMI "constellations": sets of CMMI components designed to meet the needs of specific areas of interest. A constellation can produce one or more related CMMI models and related appraisal and training materials. CMMI for Development was the first of these constellations. The three constellation in Version 1.2 comprise:
- CMMI for Development: the designated successor of three earlier sources - (1) Software CMM, (2) the IPD-CMM, (3) SECM. It is a reference model that covers the development and maintenance activities applied to both products and
services. Organizations from many industries, including aerospace, banking, computer hardware, software, defense, automobile
manufacturing, and telecommunications, use CMMI for Development.
- CMMI for Services:is the model of practice for service organizations. CMMI-SVC provides best practices that service providers can use when they:
- select services for provisioning, define and market standard services,
- Design services, including people, processes, consumables, and equipment,
- Create, change or retire systems,
- Establish service agreements, take care of service requests, and operate service systems,
- Resource and finance the delivery of services,
- Handle and prevent service incidents,
- Establish continuity planning and create and monitor disaster recovery scenarios.
- CMMI for Acquisition: a best practices modelto improve relationships with suppliers through improvements to internal processes. It can be used to increase control of projects, better manage global sourcing of products and services, and more successfully acquire solutions that meet organizational needsR.
CMMI Version 1.3
The Version 1.2 Constellation models have subsequently were reviewed by CMMI High Maturity Lead Appraisers and the CMMI Steering Group at a workshop in late September 2008. As a result, the Steering Group determined that modernizing the practices for maturity levels 4 and 5 was a priority. The Steering Committee targeted Version 1.3 to focus on:
- High maturity
- More effective GPs
- Appraisal efficiency
- Commonality across the constellations
- All changes to the CMMI Product Suite [i.e., model(s), training materials, and appraisal method] must meet the following primary criteria, which will likely be of the following nature:
- Correct identified model, training material, or appraisal method defects or provide enhancements.
- Incorporate amplifications and clarifications as needed.
- Accommodate potential additions to model coverage (e.g., safety, security, life cycle) only by specific direction of the CMMI Steering Group.
- Decrease overall model size in V1.3 if possible; increases, if any, must not be greater than absolutely necessary.
- Model and method changes should avoid adversely impacting the legacy investment of adopting companies and organizations.
- Changes to model architecture will only be incorporated with specific CMMI Steering Group authorization.
- Changes may only be initiated by Change Requests or the CMMI Steering Group.
- Editorial changes to training may be released in advance of V1.3.
- Changes must not cause retraining of the nearly 100,000 (as of December 2008) personnel already trained in CMMI. Upgrade training may be needed, especially for Instructors, Lead Appraisers, and appraisal team members.
