Opentopia Directory Encyclopedia Tools

Capability Maturity Model Integration SM

Encyclopedia : C : CA : CAP : Capability Maturity Model Integration SM


Capability Maturity Model® Integration sm (CMMIsm) is a set of requirements for engineering processes (see also Process improvement). It consists of 25 key process areas with Capability or Maturity levels (see #Structure). CMMIsm is created by the Software Engineering Institute and is available in two representations: [Staged] and [Continuous], both ~700 pages long. CMMIsm should be adapted to each individual company, therefore companies are not "certified". A company is assessed (e.g. with an appraisal method like SCAMPIsm) at a certain level of CMMIsm. The results of such an assessment can be published online, if this is the wish of the involved company (see [SCAMPI Appraisal Results]). CMMIsm is the successor of CMM. Because the CMMIsm models have so many pages, the overall structure of CMMIsm and some key process areas are visualized in so called meta-models.

Figure 1: CMMI Logo
Figure 1: CMMI Logo

About the meta-models

CMMI consists of 25 key process areas which are present in both the staged and continuous representation. Of these key process areas and the overall structure of CMMI meta-models have been created. The staged representation of CMMI has been used. The more specific name of the model is CMMI-SE/SW/IPPD/SS (Version 1.1, March 1, 2002), it contains systems engineering, software engineering, Integrated Product and Process Development, and supplier sourcing ([Staged Representation, SEI CMMI Product Team, 2002]). Since only one source is used for the meta-models, all references in the meta-model sections are referring to a page number in the previously mentioned document describing the staged version. The meta models are created using the Meta-modeling technique (also see Meta-Process Modeling). Furthermore, the models are part of the [WikiProject Method engineering].

Process Areas

The CMMI contains 25 key process area's (also see Process area (CMMI)). Because one cannot easily get an overview of the structure of the processes and the relationships with the typical work products by reading the representations of CMMI, of the blue processes meta-models have been created.

  • CMMIsm Causal Analysis and Resolution
  • CMMIsm Configuration Management
  • CMMIsm Decision Analysis and Resolution
  • CMMIsm Integrated Project Management
  • CMMIsm Integrated Supplier Management
  • CMMIsm Integrated Teaming
  • CMMIsm Measurement and Analysis
  • CMMIsm Organizational Environment for Integration
  • CMMIsm Organizational Innovation and Deployment
  • CMMIsm Organizational Process Definition
  • CMMIsm Organizational Process Focus
  • CMMIsm Organizational Process Performance
  • CMMIsm Organizational Training
  • CMMIsm Product Integration
  • CMMIsm Project Monitoring and Control
  • CMMIsm Project Planning
  • CMMIsm Process and Product Quality Assurance
  • CMMIsm Quantitative Project Management
  • CMMIsm Requirements Development
  • CMMIsm Requirements Management
  • CMMIsm Risk Management
  • CMMIsm Supplier Agreement Management
  • CMMIsm Technical Solution
  • CMMIsm Validation
  • CMMIsm Verification
  • History

    The CMMI is the successor of CMM, CMM was developed from 1987 until 1997. In 2002 the latest version of CMMI was released: v1.1. The goal of the CMMI project was to improve usability of CMM for software engineering and other disciplines, by integrating all the different models into one model. It was created by members of industry, government and the SEI. The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association ([NDIA]) Systems Engineering Committee. For more details on the development of the CMMI models see [History of CMMI].

    Appraisal

    There are three different types of appraisals, type A, B and C. In Appraisal Requirements for CMMI (ARC) the requirements for CMMI appraisal methods are described ([ARC, V1.1]). The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the only appraisal method which meets all of the ARC requirements for a Class A appraisal method ([Method Definition Document]). An appraisal team and questionnaire are obligatorily when conducting a class A appraissal (in class B and C these are optional). Class A appraisals are more formal and can therefore also be used for marketing purposes. The results of the appraisal are published (if the concerning company approves) on the website of the SEI: [Published SCAMPI Appraisal Results]. SCAMPI also supports the conduct of ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability dEtermination), assessments.

    Evaluation

    The website of the SEI states that 25 organizations measured increases of performances in the categories cost, schedule, productivity, quality and customer satisfaction ([CMMI® Performance Results, 2005]). The median increase in performance varied between 14% (customer satisfaction) and 62% (productivity). However, the CMMI model mostly deals with what processes should be implemented, and not so much with how they can be implemented. SEI thus also mentions that these results do not garuantee that applying CMMI will increase performance in every organization. Furthermore, the immense size of CMMI alone makes it hard to comprehend. A small company with few resources is thus less likely to benefit from CMMI, since just reading it takes such a considerable amount of time. This view is supported by the [Process Maturity Profile] (page 10). Of the small organizations (<25 employees) 70.5% is assessed at level 2: Managed, while 52.8% of the organizations with 1001–2000 employees are rated at the highest level (5: Optimizing).

    Method Engineering

    Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and agile methods, both approaches have much in common. They believe neither way is the 'right' way to develop software, but that there are phases in a project where one of the two is better suited. They suggest one should combine the different fragments of the methods into a new hybrid method. This approach is in line with the general goals of the [WikiProject Method engineering]. Method Engineering is process in which one tries to extract and combine method fragments from existing product software and information system development methods to create new methods that are applicable to the situation. Furthermore, the combination of the project management technique Earned Value Management (EVM) with CMMI has also been described (Solomon, 2002). To conclude with a similar use of CMMI, Extreme Programming (XP), a software engineering method, has been evaluated with CMM/CMMI (Nawrocki et al., 2002). For example, the XP requirements management approach, (which relies on oral communication), was evaluated as not compliant with CMMI.

    Figure 2: CMMI –  Meta-data model
    Figure 2: CMMI – Meta-data model

    Structure

    Because one cannot easily get an overview of CMMI, or deduct the differences between the two representations by looking at the representations of CMMI, the overall structure of the CMMI is modeled in Figure 2. It should be noted that the common features only organize the generic practices of each process area. Furthermore, common features and maturity levels are only present in the staged representation and capability levels are only present in the continuous representation. There is no CMMI meta-process model because CMMI does not describe how the model should be applied. Appraisal methods describe how CMMI should be applied, (see #Appraisal). In Table 1 the concepts are described in more detail. Again, the page numbers refer to page numbers in ([Staged Representation, SEI CMMI Product Team, 2002]).

    Table 1: CMMI concept definition list
    
    Concept
    Definition (source)
    CAPABILITY LEVEL CAPABILITY LEVELS, which belong to the continuous representation, apply to an organization’s process-improvement achievement for each process area. There are six capability levels, numbered 0 through 5. Each capability level corresponds to a generic goal and a set of generic and specific practices. (page 20)
    CMMI MODEL Since the CMMI Framework can generate different models based on the needs of the organization using it, there are multiple CMMI models. Consequently, the phrase “CMMI MODEL” could be any one of many collections of information. The phrase “CMMI models” refers to one, some, or the entire collection of possible models that can be generated from the CMMI Framework. (page 29)
    COMMON FEATURE Four COMMON FEATURES organize the generic practices of each process area. Common features are model components that are not rated in any way. They are only groupings that provide a way to present the generic practices. Each common feature is designated by an abbreviation as shown (page 18):
    • Commitment to Perform (CO)
    • Ability to Perform (AB)
    • Directing Implementation (DI)
    • Verifying Implementation (VE)
    CONTINUOUS REPRESENTATION The CONTINUOUS REPRESENTATION uses capability levels to measure process improvement. (page 20)
    DISCIPLINE AMPLIFICATION Model components that provide guidance for interpreting model information for specific disciplines (e.g., IPPD, systems engineering, or software engineering) are called “DISCIPLINE AMPLIFICATIONS.” Discipline amplifications are added to other model components where necessary. These are easy to locate because they appear on the right side of the page and have a title indicating the discipline that they address (for example, “For Software Engineering”). (page 8)
    GENERIC GOAL GENERIC GOALS are called “generic” because the same goal statement appears in multiple process areas. In the staged representation, each process area has only one generic goal. Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area, thus indicating whether these processes are likely to be effective, repeatable, and lasting. Generic goals are required model components and are used in appraisals to determine whether a process area is satisfied. (page 19)
    GENERIC PRACTICE GENERIC PRACTICES provide institutionalization to ensure that the processes associated with the process area will be effective, repeatable, and lasting. Generic practices are categorized by generic goals and common features and are expected components in CMMI models. (Only the generic practice title, statement, and elaborations appear in the process areas.) (page 19)
    GENERIC PRACTICE ELABORATIONS After the specific practices, the generic practice titles and statements appear that apply to the process area. After each generic practice statement, an elaboration may appear in plain text with the heading “Elaboration.” The GENERIC PRACTICE ELABORATION provides information about how the generic practice should be interpreted for the process area. If there is no elaboration present, the application of the generic practice is obvious without an elaboration. (page 7)
    GOAL A “GOAL” is a required CMMI component that can be either a generic goal or a specific goal. When you see the word “goal” in a CMMI model, it always refers to model components (for example, generic goal, specific goal). (page 27)
    MATURITY LEVEL A MATURITY LEVEL is a defined evolutionary plateau of process improvement. Each maturity level stabilizes an important part of the organization’s processes. Maturity levels, which belong to the staged representation, apply to an organization’s overall maturity. There are five maturity levels, numbered 1 through 5. Each maturity level comprises a predefined set of process areas. (page 21)
    PROCESS AREA A PROCESS AREA is a cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area. All CMMI process areas are common to both continuous and staged representations. In the staged representation, process areas are organized by maturity levels. (page 17)
    REFERENCE REFERENCES are informative model components that direct the user to additional or more detailed information in related process areas. Typical phrases expressing these pointers are “Refer to the Organizational Training process area for more information about identifying training needs and providing the necessary training” or “Refer to the Decision Analysis and Resolution process area for more information about evaluating and selecting among alternatives.” All references are clearly marked in italics. (page 19)
    SPECIFIC GOAL SPECIFIC GOALS apply to a process area and address the unique characteristics that describe what must be implemented to satisfy the process area. Specific goals are required model components and are used in appraisals to help determine whether a process area is satisfied. (page 17)
    SPECIFIC PRACTICES A SPECIFIC PRACTICE is an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities expected to result in achievement of the specific goals of a process area. Specific practices are expected model components. (page 17)
    STAGED REPRESENTATION The STAGED REPRESENTATION uses maturity levels to measure process improvement. (page 20)
    STATEMENT A STATEMENT is designed to be used for process-improvement and appraisal purposes. (page 7)
    SUBPRACTICE SUBPRACTICES are detailed descriptions that provide guidance for interpreting specific or generic practices. Subpractices may be worded as if prescriptive, but are actually an informative component in CMMI models meant only to provide ideas that may be useful for process improvement. (page 18)
    WORK PRODUCT The term WORK PRODUCT is used throughout the CMMI Product Suite to mean any artifact produced by a process. These artifacts can include files, documents, parts of the product, services, processes, specifications, and invoices. Examples of processes to be considered as work products include a manufacturing process, a training process, and a disposal process for the product. A key distinction between a WORK PRODUCT and a product component is that a work product need not be engineered or part of the end product. (page 25)

    References

    See also

    External links

    Tools
    Below some tools are listed that aid in applying CMMI.
    • [CMMI Tracker© Tool] Tool that allows one to track their SPI progress against the CMMI and prepare automatically for the appraisal.
    • [CMM-Quest] A software tool to rate and analyze software development processes compliant to CMMI-SE/SW.
    • [MSF for CMMI Process Improvement] MSF for CMMI® Process Improvement process guidance, which is an iterative, adaptive planning, agile software development process which meets the requirements for the Software Engineering Institute’s Capability Maturity Model Integration (CMMI) level 3 and provides a transition to level 5.
    • [Multiple Supporting Tools] Supporting tools for SPI, i.g. a free Access database, that allows one to browse through the CMMI v1.1 Continuous SE/SW/IPPD/SS.
    • [QuickScan] Assessment application for the CMMI.
    Examples
    Some recent examples of published SCAMPI appraisal results are listed below. The complete list of published SCAMPI appraisal results can be viewed here: [SCAMPI Appraisal Results].

    Below an example is shown of how one should interpret the CMMI for a specific type of organization.
    Organizations
    • [NDIA] National Defense Industrial Association
    • [SEI] Software Engineering Institute

     


    From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
    All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.

    Search Titles
    0123456789
    ABCDEFGHIJ
    KLMNOPQRST
    UVWXYZ?

    E-mail this article to:

    Personal Message: