The staged representation offers a systematic, structured way to approach model-based process improvement one stage at a time. Achieving each stage ensures that an adequate process infrastructure has been laid as a foundation for the next stage.
Process areas are organized by maturity levels that take some of the guess work out of process improvement. The staged representation prescribes an order for implementing process areas according to maturity levels, which define the improvement path for an organization from the initial level to the optimizing level. Achieving each maturity level ensures that an adequate improvement foundation has been laid for the next maturity level and allows for lasting, incremental improvement.If you do not know where to start and which processes to choose to improve, the staged representation is a good choice for you. It gives you a specific set of processes to improve at each stage that has been determined through more than a decade of research and experience with process improvement.
.
Continuous Representation
The continuous representation offers maximum flexibility when using a CMMI model for process improvement. An organization may choose to improve the performance of a single process-related trouble spot, or it can work on several areas that are closely aligned to the organization’s business objectives. The continuous representation also allows an organization to improve different processes at different rates. There are some limitations on an organization’s choices because of the dependencies among some process areas.If you know the processes that need to be improved in your organization and you understand the dependencies among the process areas described in CMMI, the continuous representation is a good choice for your organization.
Choosing a Representation
If you are new to process improvement and are not familiar with either the staged or the continuous representation, you cannot go wrong if you choose one representation or the other. There are many valid reasons to select either representation.
If you have been using a CMM and you are familiar with a particular representation, we suggest that you continue to use that representation because it will make the transition to CMMI easier. Once you have become completely comfortable with CMMI, you might then decide to use the other representation.
Because each representation has advantages over the other, some organizations use both representations to address particular needs at various times in their improvement programs. In the following sections, we provide the advantages and disadvantages of each representation to help you decide which representation is best for your organization.
If you have been using a CMM and you are familiar with a particular representation, we suggest that you continue to use that representation because it will make the transition to CMMI easier. Once you have become completely comfortable with CMMI, you might then decide to use the other representation.
Because each representation has advantages over the other, some organizations use both representations to address particular needs at various times in their improvement programs. In the following sections, we provide the advantages and disadvantages of each representation to help you decide which representation is best for your organization.
Resolving Different Approaches of CMMs
The definition of a CMM allows the community to develop models supporting different approaches to process improvement. As long as a model contains the essential elements of effective processes for one or more disciplines and describes an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness, it is considered a CMM. CMMI enables you to approach process improvement and appraisals using two different representations: continuous and staged.
The continuous representation enables an organization to select a process area (or group of process areas) and improve processes related to it. This representation uses capability levels to characterize improvement relative to an individual process area.The staged representation uses predefined sets of process areas to define an improvement path for an organization. This improvement path is characterized by maturity levels. Each maturity level provides a set of process areas that characterize different organizational behaviors.
The continuous representation enables an organization to select a process area (or group of process areas) and improve processes related to it. This representation uses capability levels to characterize improvement relative to an individual process area.The staged representation uses predefined sets of process areas to define an improvement path for an organization. This improvement path is characterized by maturity levels. Each maturity level provides a set of process areas that characterize different organizational behaviors.
The Group of IPPD Additions
In CMMI, “additions” are used to include material that may be of interest to particular users. For the CMMI for Development constellation, additional material was included to address IPPD.
The IPPD group of additions covers an IPPD approach that includes practices that help organizations achieve the timely collaboration of relevant stakeholders throughout the life of the product to satisfy customers’ needs, expectations, and requirements [DoD 1996]. When using processes that support an IPPD approach, you should integrate these processes with other processes in the organization. To support those using IPPD-related processes, the CMMI for Development constellation allows organizations to optionally select the IPPD group of additions.
When you select CMMI for Development +IPPD, you are selecting the CMMI for Development model plus all the IPPD additions. When you select CMMI for Development, you are selecting the model without the IPPD additions. In the text in Part One of this document, we may use “CMMI for Development” to refer to either of these models, for the sake of brevity.
The IPPD group of additions covers an IPPD approach that includes practices that help organizations achieve the timely collaboration of relevant stakeholders throughout the life of the product to satisfy customers’ needs, expectations, and requirements [DoD 1996]. When using processes that support an IPPD approach, you should integrate these processes with other processes in the organization. To support those using IPPD-related processes, the CMMI for Development constellation allows organizations to optionally select the IPPD group of additions.
When you select CMMI for Development +IPPD, you are selecting the CMMI for Development model plus all the IPPD additions. When you select CMMI for Development, you are selecting the model without the IPPD additions. In the text in Part One of this document, we may use “CMMI for Development” to refer to either of these models, for the sake of brevity.
The Scope of CMMI for Development
CMMI for Development 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.Models in the CMMI for Development constellation contain practices that cover project management, process management, systems engineering, hardware engineering, software engineering, and other supporting processes used in development and maintenance. The CMMI for Development +IPPD model also covers the use of integrated teams for development and maintenance activities.
CMMI for Development
The CMMI for Development constellation consists of two models: CMMI for Development +IPPD and CMMI for Development (without IPPD). Both models share much of their material and are identical in these shared areas. However, CMMI for Development +IPPD contains additional goals and practices that cover IPPD.
Currently, only one model is published since the CMMI for Development +IPPD model contains the full complement of practices available in this constellation, and you can derive the other model from this material. If you are not using IPPD, ignore the information that is marked “IPPD Addition,” and you will be using the CMMI for Development model. If the need arises or the development constellation is expanded, the architecture will allow other models to be generated and published.
CMMI for Development is the designated successor of the three source models. The SEI has retired the Software CMM and the IPD-CMM. EIA has retired the SECM. All three of these models are succeeded by CMMI for Development.
The best practices in the CMMI models have gone through an extensive review process. CMMI version 0.2 was publicly reviewed and used in pilot activities.
The CMMI Product Team evaluated more than 3,000 change requests to create CMMI version 1.0. Shortly thereafter, version 1.02 was released, which incorporated several minor improvements.
Version 1.1 incorporated improvements guided by feedback from early use, with more than 1,500 change requests submitted as part of the public review, and hundreds of comments as part of the change control process.CMMI version 1.2 was developed using input from nearly 2,000 change requests submitted by CMMI users. More than 750 of those requests were directed at CMMI model content. As you can see, not only is CMMI widely adopted, but it is improved based on the feedback received from the community.
Currently, only one model is published since the CMMI for Development +IPPD model contains the full complement of practices available in this constellation, and you can derive the other model from this material. If you are not using IPPD, ignore the information that is marked “IPPD Addition,” and you will be using the CMMI for Development model. If the need arises or the development constellation is expanded, the architecture will allow other models to be generated and published.
CMMI for Development is the designated successor of the three source models. The SEI has retired the Software CMM and the IPD-CMM. EIA has retired the SECM. All three of these models are succeeded by CMMI for Development.
The best practices in the CMMI models have gone through an extensive review process. CMMI version 0.2 was publicly reviewed and used in pilot activities.
The CMMI Product Team evaluated more than 3,000 change requests to create CMMI version 1.0. Shortly thereafter, version 1.02 was released, which incorporated several minor improvements.
Version 1.1 incorporated improvements guided by feedback from early use, with more than 1,500 change requests submitted as part of the public review, and hundreds of comments as part of the change control process.CMMI version 1.2 was developed using input from nearly 2,000 change requests submitted by CMMI users. More than 750 of those requests were directed at CMMI model content. As you can see, not only is CMMI widely adopted, but it is improved based on the feedback received from the community.
Evolution of CMMI
Since 1991, CMMs have been developed for myriad disciplines. Some of the most notable include models for systems engineering, software engineering, software acquisition, workforce management and development, and integrated product and process development (IPPD).
Although these models have proven useful to many organizations in different industries, the use of multiple models has been problematic. Many organizations would like their improvement efforts to span different groups in their organizations. However, the differences among the discipline-specific models used by each group, including their architecture, content, and approach, have limited these organizations’ capabilities to broaden their improvements successfully. Further, applying multiple models that are not integrated within and across an organization is costly in terms of training, appraisals, and improvement activities.
The CMM IntegrationSM project was formed to sort out the problem of using multiple CMMs. The CMMI Product Team’s initial mission was to combine three source models:
1. The Capability Maturity Model for Software (SW-CMM) v2.0 draft C [SEI 1997b]
2. The Systems Engineering Capability Model (SECM) [EIA 1998]
3. The Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 [SEI 1997a]
The combination of these models into a single improvement framework was intended for use by organizations in their pursuit of enterprise-wide process improvement.
These three source models were selected because of their widespread adoption in the software and systems engineering communities and because of their different approaches to improving processes in an organization.
Using information from these popular and well-regarded models as source material, the CMMI Product Team created a cohesive set of integrated models that can be adopted by those currently using the source models, as well as by those new to the CMM concept. Hence, CMMI is a result of the evolution of the SW-CMM, the SECM, and the IPD-CMM.
Developing a set of integrated models involved more than simply combining existing model materials. Using processes that promote consensus, the CMMI Product Team built a framework that accommodates multiple disciplines and is flexible enough to support the different approaches of the source models [Ahern 2003].
The Systems Engineering Capability Model is also known as Electronic Industries Alliance 731 (EIA 731).
Since the release of CMMI v1.1, we have seen that this improvement framework can be applied to other areas of interest [SEI 2002a, SEI 2002b]. To apply to multiple areas of interest, the framework groups best practices into what we call “constellations.” A constellation is a collection of CMMI components that are used to build models, training materials, and appraisal documents.
Recently, the CMMI model architecture was improved to support multiple constellations and the sharing of best practices among constellations and their member models. Work has begun on two new constellations: one for services (CMMI for Services) and the other for acquisition (CMMI for Acquisition). Although CMMI for Development incorporates the development of services, including the combination of components, consumables, and people intended to meet service requirements, it differs from the planned CMMI for Services (CMMI-SVC), which focuses on the delivery of services. The CMMI models that have been available in the community prior to 2006 are now considered part of the CMMI for Development constellation.
Although these models have proven useful to many organizations in different industries, the use of multiple models has been problematic. Many organizations would like their improvement efforts to span different groups in their organizations. However, the differences among the discipline-specific models used by each group, including their architecture, content, and approach, have limited these organizations’ capabilities to broaden their improvements successfully. Further, applying multiple models that are not integrated within and across an organization is costly in terms of training, appraisals, and improvement activities.
The CMM IntegrationSM project was formed to sort out the problem of using multiple CMMs. The CMMI Product Team’s initial mission was to combine three source models:
1. The Capability Maturity Model for Software (SW-CMM) v2.0 draft C [SEI 1997b]
2. The Systems Engineering Capability Model (SECM) [EIA 1998]
3. The Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 [SEI 1997a]
The combination of these models into a single improvement framework was intended for use by organizations in their pursuit of enterprise-wide process improvement.
These three source models were selected because of their widespread adoption in the software and systems engineering communities and because of their different approaches to improving processes in an organization.
Using information from these popular and well-regarded models as source material, the CMMI Product Team created a cohesive set of integrated models that can be adopted by those currently using the source models, as well as by those new to the CMM concept. Hence, CMMI is a result of the evolution of the SW-CMM, the SECM, and the IPD-CMM.
Developing a set of integrated models involved more than simply combining existing model materials. Using processes that promote consensus, the CMMI Product Team built a framework that accommodates multiple disciplines and is flexible enough to support the different approaches of the source models [Ahern 2003].
The Systems Engineering Capability Model is also known as Electronic Industries Alliance 731 (EIA 731).
Since the release of CMMI v1.1, we have seen that this improvement framework can be applied to other areas of interest [SEI 2002a, SEI 2002b]. To apply to multiple areas of interest, the framework groups best practices into what we call “constellations.” A constellation is a collection of CMMI components that are used to build models, training materials, and appraisal documents.
Recently, the CMMI model architecture was improved to support multiple constellations and the sharing of best practices among constellations and their member models. Work has begun on two new constellations: one for services (CMMI for Services) and the other for acquisition (CMMI for Acquisition). Although CMMI for Development incorporates the development of services, including the combination of components, consumables, and people intended to meet service requirements, it differs from the planned CMMI for Services (CMMI-SVC), which focuses on the delivery of services. The CMMI models that have been available in the community prior to 2006 are now considered part of the CMMI for Development constellation.
Subscribe to:
Posts (Atom)