TSU CMM CMMI

Capability Maturity Model / Capability Maturity Model Integration

CS 3398 Software Engineering

November 12, 2003

Terry Startzel, Senior ConsultantCooper Consulting Company

Texas State University | Texas State University | San MarcosSan Marcos

Texas State University | Texas State University | San MarcosSan Marcos Greetings and Welcome!

Greetings and Welcome to this Presentation on the Capability Maturity Model

(CMM) / Capability Maturity Model Integration (CMMI)

I would like to thank Dr. Beard for the invitation to provide you with this introduction to model-based

software engineering process improvement!

Before we get going, lets introduce ourselves.

Texas State University | Texas State University | San MarcosSan Marcos Introduction

Quality Products Are The Result OfQuality Processes

Imagine for a moment that you work for a private business or a department of government and you are

the business owner of a software development project with an approved budget of $11,000,000.00.



Imagine further that to increase your opportunities for success, you plan to outsource this project to a

software consulting company. Finally, imagine that five companies have submitted bids in response to

your request for offer.



Now ask yourself, what criteria would you use to select one of those five consulting companies?

Would your selection be based solely upon the lowest cost? Or would other criteria be equally important

like the company’s track record for success?



The bottom line is that, while cost is important, you would be searching for a mature consulting company

with a history of satisfied customers and a well deserved reputation for excellence.



Now, if you were the owner of a software consulting company and you wanted to enhance your

company’s competitiveness by achieving these types of results, what is the most important thing you

could do to enhance your opportunities for success?



The answer is simple. To enhance your company’s opportunities for success project after project, a

mature, efficient and effective software engineering process is required. Quality software products are

produced by quality software engineering processes.



Assisting a company in their efforts to benchmark and appraise their software engineering processes, as

well as to provide guidance to their process improvement efforts, is the purpose of the Software

Engineering Institutes’ CMM/CMMI

Capability Maturity Model

Background and History

• In cooperation with major corporations and research centers, Congress founded the Software Engineering Institute (SEI) in 1984 www.sei.cmu.edu

• This non-profit, federally funded research and development center was located and operated by the Carnegie-Mellon University in Pittsburg, PA

• SEI was created as a research body to help improve the practice of software engineering


http://www.sei.cmu.edu/

• At its founding, its goal was to assist American software professionals maintain a competitive edge in the field of software development

• To accomplish this goal, SEI embarked on a strategy to bring an engineering discipline to the software development profession

• One of the early results this initiative was the Capability Maturity Model for Software or simply CMM

Capability Maturity ModelTexas State University | Texas State University | San MarcosSan Marcos


• The U.S. Department of Defense (DoD), which sponsors the SEI, commissioned the original CMM

• With escalating costs and schedule overruns, DoD projects were fairing no better than commercial software projects at that time

• To appreciate the rather dismal state of software development in the late 80s, let’s review the research study conducted by The Standish Group (TSG) www.standishgroup.com



http://www.standishgroup.com/

• In the 1994 CHAOS Report, TSG reported that Corporate America spent more than $275 billion each year on approximately 200,000 application software projectswww.standishgroup.com/sample_research/chaos_1994_1.php

• Of these projects, only 16.2% were completed on time and on budget, 31.1% were cancelled, and 52.7% exceeded their original cost estimates by 189%



http://www.standishgroup.com/sample_research/chaos_1994_1.php

• The CHAOS Report also identified multiple factors that contributed to these unfortunate statistics like poor requirements management

• Taken together as a whole, these factors were indicative of software process immaturity

• Given this process immaturity, it is understandable that the DoD needed a way to assess the software engineering capabilities of its consultants and suppliers and to identify best practices



• To provide the DoD with the required assessment capability, SEI with assistance from the Mitre Corporation began developing a process maturity framework in 1986

• The basic principles and concepts upon which the CMM was based was described by Watts S. Humphrey, who worked for IBM and then SEI, in his book Managing the Software Process published in 1989



• The fully developed model, CMM for Software V1.1, was published by SEI in 1993 as a technical report authored by Mark Paulk and other SEI engineers

• In 1995, The Capability Maturity Model: Guidelines for Improving the Software Process by Mark Paulk et. al. was published by Addison-Wesley

• A major update to the CMM for Software, V2.0, was in the process of being reviewed when work was cancelled with to the launch of the CMMI Project



• CMM for Software is not a proprietary software engineering process

• That is, the CMM identifies what processes should be performed by a mature software development organization not how an organization should perform these processes

• To this end, it provides a broad process assessment framework that enables an organization to objectively determine its process maturity


Process Assessment Framework

• An organization is considered fully mature once it has: Implemented measurable and controlled

processes that enable the organization to produce quality software in a predictable, reliable, and repeatable manner

Implemented the capability to continuously improve its processes in response to changes and the availability of new technologies


Process Assessment Framework

• At its most fundamental, then, CMM is concerned with continuous process improvement

• This approach can best be described as a spiral of planning, implementing, and evaluating, with the evaluation leading to new process improvements

• This approach is continuous in that this spiral continues indefinitely and, in fact, must become institutionalized within the supporting organization

Continuous Process Improvement


• In support of continuous process improvement, CMM for Software is structured as a hierarchical five-scale tier

• As such, it defines five levels of process maturity: Initial Repeatable Defined Managed Optimized


Continuous Process Improvement

1. Initial

2. Repeatable

3. Defined

4. Managed

5. Optimized

• Project-Level Focus• Basic Set of Software

Project Management Controls

• Organization-Level Focus• Institutionalized Software Management

and Engineering Processes

Quantitative Understanding of the Software Processes and Products

Continuous Process Improvement and Defect Prevention

Texas State University | Texas State University | San MarcosSan Marcos Capability Maturity Model

• Starting with maturity level 2, CMM defines goals and Key Process Areas (KPA) specific to each level

• Implementing the KPAs and, thus, satisfying the goals for a given level provides the foundation upon which an organize can build and mature its processes

• According to CMM, all process improvement initiatives should begin with a process appraisal to determine the organization’s initial maturity level


Five Levels of Process Maturity

The Initial Level

• Level 1 organizations lack a set of sound project management practices for developing software

• As such, Level 1 organizations tend to be ad hoc and reaction-driven

• Success under these circumstances depends entirely upon the skills and heroics of individuals team members


The Initial Level

• In such an environment, very little learning occurs because the factors that lead to a project success are undocumented

• As a result, the success factors are not repeatable or shareable across projects

• In 2001, SEI estimated that in the industry as a whole, between 75 to 85 percent of all software development organizations would assess at Level 1 [Persse, James (2001). Implementing the Capability Maturity Model. John Wiley & Sons, Inc.]


The Repeatable Level

• In many ways, maturing from Level 1 to Level 2 is the hardest step to take in CMM for Software

• At Level 2, a basic set of project planning and management processes are implemented

• From the perspective of software process, Level 2 organizations become “self aware” and from this awareness are able to learn and improve


The Repeatable Level

• Level 2, however, is very distinctly a project-focused tier

• That is, Level 2 KPAs have not yet become institutionalized and implementation of these processes will initially vary from project to project until they are refined and proven

• Even so, the way in which a project is planned and managed is influenced by experienced gained from similar projects and, thus, success becomes repeatable


As stated previously, the KPAs for Level 2 focus on establishing a basic set of software project planning and management processes: Requirements Management Software Project Planning Software Project Tracking and Oversight Software Quality Assurance Software Configuration Management Subcontractor Management


The Repeatable Level – Key Process Areas

In 2001, SEI estimated that in the industry as a whole, 5 to 10 percent of all software development organizations would probably assess at Level 2 [Persse]


The Repeatable Level – SEI Estimate

• Once an organization has reached Level 2, and over time, a refined and proven set of key software planning and management processes will have emerged

• Moving from Level 2 to Level 3 then is not so much focused on adopting new processes as it is with the movement from a project-level focus to an organization-level focus

• That is, these key planning and management processes have become institutionalized within the organization


The Defined Level

• As a result, and whenever a new project begins, these institutionalized processes provide direction and set expectations

• Tailoring of these processes, however, is allowed in order to take into account the unique characteristics of a given software project

• A new KPA introduced at Level 3 is a well-defined software engineering process that integrates all of the organization’s software engineering activities


The Defined Level

• Also two new groups appear within Level 3 organizations: Training Software Engineering Process Group (SEPG)

• The first provides an organization-wide training program to ensure staff have the requisite skills

• The second facilitates the definition, maintenance, and improvement of the organization's software engineering processes


The Defined Level

• The two chief qualities of the software process at this level are standardization and consistency

• Software planning, management and engineering have become stable and repeatable

• This stability is based upon an organization-wide understanding of the activities, roles, and responsibilities in this defined software engineering process


The Defined Level

The key process areas for Level 3 focus on establishing effective software planning, management and engineering processes across the organization: Organizational Process Focus Organizational Process Definition Process Training Program Integrated Software Management Software Product Engineering Intergroup Coordination


The Defined Level – Key Process Areas

The key process areas for Level 3 focus on establishing effective software planning, management and engineering processes across the organization: Peer Reviews


The Defined Level – Key Process Areas

In 2001, SEI estimated that in the industry as a whole, only 3 to 7 percent of all software development organizations would probably assess at Level 3 [Persse]


The Defined Level – SEI Estimate

• With Level 2 focused on process refinement and Level 3 focused process institutionalization, Level 4 is focused on process measurement

• That is, moving from Level 3 to Level 4 is concerned with measuring the effectiveness of the defined process with the goal of continuous process improvement

• To accomplish this, the organization establishes quantitative quality goals


The Managed Level

• These quantitative quality goals apply to the software products, as well as the planning, managerial and software engineering processes

• Level 4 is the ‘managed’ stage because nearly every aspect of the software product and process is being actively managed

• Metrics are collected, organized, and stored in a organization-wide software process database for analysis


The Managed Level

The key process areas for Level 4 focus on establishing a quantitative understanding of the software engineering process and products created by the organization: Quantitative Process Management Software Quality Management


The Managed Level – Key Process Areas

In 2001, SEI estimated that in the industry as a whole, only 2 to 3 percent of all software development organizations would probably assess at Level 4 [Persse]


The Managed Level – SEI Estimate

• The transition from Level 4 to Level 5 is a transition in which the entire organization now becomes focused on continuous process improvement

• This level is characterized by an ongoing, continuous state of operation where the major goal becomes the prevention of defects

• The organization as a whole consistently strives to improve the range of its process ability


The Optimizing Level

The key process areas for Level 5 focus on implementing continuous and measurable software process improvement: Defect Prevention Technology Change Management Process Change Management


The Optimizing Level – Key Process Areas

• In 2001, SEI estimated that in the industry as a whole, only 2 to 3 percent of all software development organizations would probably assess at Level 5 [Persse]

• The first CMM for Software Level 5 organization was the United Space Alliance (USA) equally owed by the Boeing Company and Lockheed Martin Corporation

• USA is currently performing work on the NASA Space Shuttle and International Space Station Programs and has a staff of more than 10,000 employees


The Optimizing Level – SEI Estimate

1. Initial

2. Repeatable

3. Defined

4. Managed

5. Optimized

• Project-Level Focus• Basic Set of Software

Project Management Controls

• Organization-Level Focus• Institutionalized Software Management

and Engineering Processes

Quantitative Understanding of the Software Processes and Products

Continuous Process Improvement and Defect Prevention


Capability Maturity Model Integration

• Over the past two decades, the CMM for Software has been the predominant tool for assessing and assisting an organization’s processes improvement efforts

• In fact, its success led to the creation of additional capability models to support other disciplines including: The Systems Engineering Capability Model The Integrated Product Development Capability

Maturity Model

Texas State University | Texas State University | San MarcosSan Marcos From CMM to CMMI

• While each of these models was well received, inconsistencies in approach, structure, and terminology were introduced

• For example, CMM for Software provided a “staged” approach with its pre-defined maturity levels

• In contrast, the Systems Engineering Capability Model provided a “continuous” approach that enables an organization to improve maturity within a single process area, independent of other process areas



• As a result, SEI launched the Capability Maturity Model Integration Project

• Its goal was to reduce the redundancy and complexity that resulted from the creation of separate, multiple capability models, particularly within the same organization

• To reach this goal, SEI set out to integrate the CMMs and create a product suite designed to improve efficiency and return on investment



• The three source models for CMMI include: The CMM for Software V2.0 draft C The Systems Engineering CM The Integrated Product Development CMM v0.98

• Four bodies of knowledge are supported by CMMI: Systems Engineering Software Engineering Integrated Product and Process Development Supplier Sourcing



• Systems engineering covers the development of total systems, which may or may not include software

• Software engineering covers the development of software systems

• Integrated product and process development is a systematic approach intended to achieve a timely collaboration of relevant stakeholders throughout the life of the product to satisfy customer’s needs, expectations, and requirements


CMMI Bodies of Knowledge or Disciplines

• Supplier sourcing focuses on identifying sourcing best practices (i.e., enhanced source analysis and the monitoring of supplier activities) for those projects that use suppliers to perform functions or add modifications to products needed by the project


CMMI Bodies of Knowledge or Disciplines

• In March 2002, CMMI Version 1.1 was released• For Version 1.1, four combination of disciplines are

available: CMMI-SW – covers software engineering CMMI-SE/SW – covers both systems engineering

and software engineering CMMI-SE/SW/IPPD – adds Integrated Product

and Process Development CMMI-SE/SW/IPPD/SS – adds Supplier Sourcing

Capability Maturity Model Integration Version 1.1


• Both a continuous and a staged representation of the CMMI V1.1 are available

• The continuous representation offers a flexible approach to process improvement by enabling an organization to focus on specific process areas for improvement and/or to improve process areas to different capability levels (i.e., CL1 – CL5)

• Capability levels are used to measure the improvement path from unperformed to an optimizing process area

Continuous Representation


RepresentationsContinuous and Staged

To this end, six capability levels have been defined for the continuous representation:

• Capability Level 0: Incomplete• Capability Level 1: Performed• Capability Level 2: Managed• Capability Level 3: Defined• Capability Level 4: Quantitatively Managed• Capability Level 5: Optimizing

Continuous Representation – Capability Levels



Capability Level 0: IncompleteAn incomplete process is a process that is either not performed or partially performed

Capability Level 1: PerformedA performed process is a process that satisfies the specific goals of the process area

Capability Level 2: ManagedA managed process is a Capability Level 1 process that has the basic infrastructure in place to support the process




Capability Level 3: DefinedA defined process is a Capability Level 2 process that is tailored according to guidelines and contributes to the organization’s process assets (e.g., work products, measures, etc.)

Capability Level 4: Quantitatively ManagedA quantitatively managed process is a Capability Level 3 process that is controlled using statistical and other quantitative techniques




Capability Level 5: OptimizingAn optimizing process is a Capability Level 4 process that is improved based on an understanding of the common causes of variation inherent in the process itself




Process Area 1Process Area 2 Process Area 3

Specific Goals Generic Goals

Specific Practices

Structure of the Continuous Representation

GenericPracticesCapability Levels


Chrissis, M., Konrad, M., and Shrum, S. (2003) CMMI Guidelines for Process Integration and Product Improvement. Addison-Wesley.

• In contrast to the continuous representation, the staged representation offers a systematic, structured approach to process improvement

• Like CMM for Software, it defines five distinct levels of process maturity each of which lays the foundation for the next stage

• Associated with each maturity level are a set of predefined process areas that improve the organization’s overall process performance

Staged Representation



The five maturity levels, named similarly to the five CMM for Software maturity levels, include:

• Maturity Level 1: Initial• Maturity Level 2: Managed• Maturity Level 3: Defined• Maturity Level 4: Quantitatively Managed• Maturity Level 5: Optimizing

(Note that maturity levels 2 – 5 are named exactly the same as capability levels 2 – 5)

Staged Representation – Maturity Levels



Maturity Level 1: InitialAt maturity level 1, processes are usually ad hoc and chaotic and the required supporting infrastructure is not in place

Maturity Level 2: ManagedAt maturity level 2, the organization’s projects have ensured that requirements are managed and that processes are planned, performed, measured, and controlled




Maturity Level 3: DefinedAt maturity level 3, processes are well characterized and understood by the organization, and are supported by an infrastructure that includes standards, procedures, tools, and methods; a project may tailor a process according to guidelines

Maturity Level 4: Quantitatively ManagedAt maturity level 4, the organization and projects establish quantitative objectives for quality and process performance and use them as criteria in managing processes; quality and process performance are understood in statistical terms




Maturity Level 5: OptimizingAt maturity level 5, an organization continually improves its processes based on a quantitative understanding of the common causes of variation inherent in the process itself




Maturity Levels

Process Area 1 Process Area 2 Process Area 3


AbilityTo Perform

DirectingImplementation

CommitmentTo Perform

VerifyingImplementationSpecific

Practices

Generic Practices

Structure of the Staged Representation



Comparing the Representations


LevelContinuous RepresentationCapability Levels

Staged RepresentationMaturity Levels

Level 0 Incomplete N/ALevel 1 Performed InitialLevel 2 Managed ManagedLevel 3 Defined DefinedLevel 4 Quantitatively Managed Quantitatively ManagedLevel 5 Optimizing Optimizing


• CMMI V1.1 has defined 25 process areas 22 process areas are common to all the disciplines

(i.e., CMMI-SE/SW/IPPD/SS) Two process areas are specific to Integrated

Product and Process Development One process area is specific to Supplier Sourcing

• These process areas are the fundamental organizational feature of all the CMMI models

CMMI Process Areas

Texas State University | Texas State University | San MarcosSan Marcos Understanding CMMI

• A process area is a set of related practices, which when performed collectively, satisfy a set of goals considered important in making significant process improvements in a given area

• Relationships exist between process areas and some have been classified as Fundamental and others Progressive

• Note that the 25 defined process areas are common to both the staged and continuous representations

CMMI Process Areas


CMMI’s 25 process areas can be grouped into one of the following four categories:

• Process Management• Project Management• Engineering• Support

CMMI Process Areas


Process Management process areas contain cross-project activities related to defining, planning, deploying, implementing, monitoring, controlling, appraising, measuring and improving processes

• Organizational Process Focus• Organizational Process Definition• Organizational Training• Organizational Process Performance• Organizational Innovation and Deployment

Process Management Process Areas


Process Management Process Areas


Process Area Purpose

Organizational Process Focus

To plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets

Organizational Process Definition

To establish and maintain a usable set of organizational process assets (e.g., policies, process descriptions, support tools, etc.)

Organizational Training

To develop the skills and knowledge of people so they can perform their roles effectively and efficiently

Organizational Process Performance

To establish and maintain a quantitative understanding of the performance of the organization’s set of standard processes in support of quality and process-performance objectives, and to provide the process performance data, baselines, and models to quantitatively manage the organization’s projects

Organizational Innovation and Deployment

To select and deploy incremental and innovative improvements that measurably improve the organization’s processes and technologies. The improvements support the organization’s quality and process-performance objectives as derived from the organization’s business objectives.

Project Management process areas cover the project management activities related to planning, monitoring, and controlling a project

• Project Planning• Project Monitoring and Control• Supplier Agreement Management • Integrated Project Management• Risk Management

Project Management Process Areas





Project Planning To establish and maintain plans that define project activities

Project Monitoring and Control

To provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan

Supplier Agreement Management

To manage the acquisition of products from suppliers for which there exists a formal agreement

Integrated Project Management

To establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes; [IPPD – also to establish a shared vision for the project and a team structure for integrated teams that will carry out the objectives of the project]

Risk Management

To identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate advers impacts on achieving objectives

Project Management process areas cover the project management activities related to planning, monitoring, and controlling a project



• Integrated Teaming (IPPD)

• Integrated Supplier Management (SS)• Quantitative Project Management




Integrated Teaming (IPPD) To form and sustain an integrated team for the development of work products

Integrated Supplier Management (SS)

To proactively identify sources of products that may be used to satisfy the project’s requirements and to manage selected suppliers while maintaining a cooperative project-supplier relationship

Quantitative Project Management

To quantitatively manage the project’s defined processes to achieve the project’s established quality and process-performance objectives

Engineering process areas cover the development and maintenance activities that are shared across engineering disciplines

• Requirements Definition• Requirements Management• Technical Solution• Product Integration• Verification• Validation

Engineering Process Areas


Engineering Process Areas



Requirements Definition To produce and analyze customer, product, and product-component requirements

Requirements Management

To manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products

Technical Solution

To design, develop, and implement solutions to requirements; solutions, designs, and implementation encompass products, product components, and product-related life-cycle singly or in combination as appropriate

Product Integration

To assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product

Verification To ensure that selected work products meet their specified requirements

ValidationTo demonstrate that a product or product component fulfills its intended use when placed in its intended environment

Support process areas cover the activities that support product development and maintenance

• Configuration Management• Process and Product Quality Assurance• Measurement and Analysis• Organizational Environment for Integration (IPPD)• Decision Analysis and Resolution• Causal Analysis and Resolution

Support Process Areas


Support Process Areas



Configuration Management

To establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits

Process and Product Quality Assurance

To provide staff and management with objective insights into processes and associated work products

Measurement and Analysis

To develop and sustain a measurement capability that is used to support management information needs

Organization Environment for Integration (IPPD)

To provide an Integrated Product and Process Development infrastructure and manage people for integration

Decision Analysis and Resolution

To analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria

Causal Analysis and Resolution

To identify causes of defects and other problems and take action to prevent them from occurring in the future

• Process areas are comprised of components• These components have been grouped into one of the

following three categories: Required Model Components Expected Model Components Informative Model Components

CMMI Process Area Components


• Required components describe what an organization must achieve to satisfy a process area

• The required components in CMMI are the specific and generic goals

• Goal satisfaction is used in appraisals as the basis for deciding if a process area has been achieved

• For example: Configuration Management SG1 – Baselines of identified work products are established

CMMI Process Area – Required Model Components


• Expected components describe what an organization will typically implement to achieve a specific or generic goal

• Expected components include the specific and generic practices

• Before a goal can be considered satisfied, practices as described in CMMI or alternatives must be in place

• For example: SP 1.1-1 Identify Configuration Items

CMMI Process Area – Expected Model Components


Informative components provide details that help organizations get started in thinking about how to approach the required and expected components

• Subpractices• Typical Work Products• Discipline Amplifications• Generic Practice Elaborations• Goal and Practice Titles• Goal and Practice Notes

CMMI Process Area – Informative Model Components


Informative components provide details that help organizations get started in thinking about how to approach the required and expected components

• References

CMMI Process Area – Informative Model Components


CMMI ModelComponents


Process Area

Purpose Statement

IntroductoryNotes

RelatedProcess Areas


Specific Practices

Generic Practices

Typical WorkProducts Subpractices Generic Practice

Elaborations

Required

Expected

Informative


• Each process area consists of one or more specific goals and one or more generic goals, depending upon the representation (i.e., Staged or Continuous)

• Specific goals describe the unique characteristics that must be present to satisfy a process area (e.g., Manage Requirements)

• Specific goals are supported by specific practices that describe activities that should result in the achievement of a process area’s specific goals


CMMI Process Areas – Specific and Generic Goals


Requirements Management – Specific Goal and Practices

SG 1 Manage Requirements

SP 1.1-1 Obtain an Understanding of Requirements

SP 1.2-2 Obtain Commitment to Requirements

SP 1.3-1 Management Requirements Changes

SP 1.4-2 Maintain Bidirectional Traceability of Requirements

SP 1.5-1Identify Inconsistencies between Project Work and Requirements

• Generic goals are called “generic” because the same goal statement appears in multiple process areas

• A generic goal describes the characteristic that must be present to institutionalize the processes that implement a process area

• Within CMMI, “institutionalization” is an important concept that speaks to whether the process have been ingrained within the way the organization performs work; ingrained implies consistency across projects



GG 1 Achieve Specific GoalsThe process supports and enables the achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products

GG2 Institutionalize a Managed ProcessThe process is institutionalized as a managed process

GG3 Institutionalize a Defined ProcessThe process is institutionalized as a defined process


CMMI’s Generic Goals

GG 4 Institutionalize a Quantitatively Managed ProcessThe process is institutionalized as a quantitatively managed process

GG5 Institutionalize an Optimizing ProcessThe process is institutionalized as an optimizing process


CMMI’s Generic Goals

• Generic goals are supported by generic practices that describe activities that are considered important in achieving the associated generic goal

• Generic practices are organized by the following four common features: Ability to Perform (AB) Commitment to Perform (CP) Directing Implementation (DI) Verifying Implementation (VI)



Ability to PerformGroups the generic practices related to ensuring that the process is ready for execution

Commitment to PerformGroups the generic practices related to creating policies and securing sponsorship

Direction ImplementationGroups the generic practices related to managing the performance of the practice


CMMI’s Generic Practices’ Common Features

Verifying ImplementationGroups the generic practices related to review by higher level management and objective evaluation of conformance to process descriptions, procedures, and standards


CMMI’s Generic Practices’ Common Features

• All five generic goals and practices are used in the continuous representation

• The target capability level will determine the specific goals and practices that apply to a specific process area

• In the staged representation, only generic goals 2 and 3 are used because not all process areas will be raised above a defined process




Generic Goals 1 and 2 and Associated Generic PracticesGG 1 Achieve Specific Goals

GP 1.1 Perform Base Practices

GG 2 Institutionalize a Managed Process

GP 2.1 Establish an Organizational Policy (CP)

GP 2.2 Plan the Process (AP)

GP 2.3 Provide Resources (AP)

GP 2.4 Assign Responsibility (AP)

GP 2.5 Train People (AP)

GP 2.6 Manage Configurations (DI)

GP 2.7 Identify and Involve Relevant Stakeholders (DI)

GP 2.8 Monitor and Control the Process (DI)

GP 2.9 Objectively Evaluate Adherence (VI)

GP 2.10 Review Status with Higher Level Management (VI)

• In the staged representation, the process areas are organized by the five maturity levels identified earlier

• Advancing through the maturity levels means achieving control at the project level first followed by the organizational level until the goal of continual process improvement has been realized

• In general, as an organization matures, predictability of project success increases and risk decreases


CMMI’s Staged Representation

1. Initial

2. Managed

3. Defined

4. Quantitatively Managed

5. Optimizing

• Project-Level Focus• Processes Characterized as

Reactive

• Organization-Level Focus• Processes Characterized as Proactive

Processes Measured and Controlled

Focus on Continuous Process Improvement

• Processes Unpredictable• Poorly Controlled• Ad Hoc and Chaotic



Maturity Level 2: Managed

Process Area Category

Project Monitoring and Control Project Management

Project Planning Project Management

Supplier Agreement Management Project Management

Requirements Management Engineering

Configuration Management Support

Measurement and Analysis Support

Process and Product Quality Assurance Support


Maturity Level 3: Defined


Organizational Process Definition Process Management

Organizational Process Focus Process Management

Organizational Training Process Management

Integrated Project Management Project Management

Integrated Supplier Management (SS) Project Management

Integrated Teaming (IPPD) Project Management

Risk Management Project Management


Maturity Level 3: Defined


Product Integration Engineering

Requirements Development Engineering

Technical Solution Engineering

Validation Engineering

Verification Engineering

Decision Analysis and Resolution Support

Organizational Environment for Integration Support


Maturity Level 4: Quantitatively Managed


Organizational Process Performance Process Management

Quantitative Project Management Project Management


Maturity Level 5: Optimizing


Organizational Innovation and Deployment Process Management

Causal Analysis and Resolution Support

• For additional information on CMMI V1.1, please visit the SEI’s Web Site at:http://www.sei.cmu.edu/cmmi/cmmi.html

• Portable Document Format (PDF) editions of both the staged and continuous representations are available for downloading

Texas State University | Texas State University | San MarcosSan Marcos Wrap Up

For Additional Information

http://www.sei.cmu.edu/cmmi/cmmi.html

• To hasten the transition from SW-CMM to CMMI V1.1, SEI has stopped updating the SW-CMM

• It also plans to discontinue training for SW-CMM by the end of 2003

• Because CMMI is consistent with modern software engineering best practices, the IBM Rational Software Corporation has endorsed CMMI V1.1

Texas State University | Texas State University | San MarcosSan Marcos Wrap Up

For Additional Information

• Watts S. Humphrey (1989). Managing the Software Process. Addison-Wesley Publishing Company, Inc.

• Mark Paulk, et al. (1993). Capability Maturity Model for Software, Version 1.1. A Software Engineering Institute Technical Report.

• Mark Paulk, et al. (1995). The Capability Maturity Model: Guidelines for Improving the Software Process. Addison Wesley Longman, Inc.

• James R. Persse (2001). Implementing the Capability Maturity Model. John Wiley & Sons, Inc.

Texas State University | Texas State University | San MarcosSan Marcos Resources

• CMMI Project Team (2002). Capability Maturity Model Integration (CMMI) Version 1.1. Software Engineering Institute.

• Ahren, Dennis, Clouse, Aaron, and Turner, Richard (2003). CMMI Distilled 2nd Edition: A Practical Introduction to Integrated Process Improvement. Addison-Wesley Publishing Company, Inc.

• Chrissis, Mary Beth, Konrad, Mike, and Shrum, Sandy. (2003). CMMI Guidelines for Process Integration and Product Improvement. Addison-Wesley Publishing Company, Inc.


• Reaching CMM Levels 2 and 3 with the Rational Unified Process. An IBM Rational Software Corporation White Paper.

• Rolf W. Reitzig, Carlo Rodriguez, and Gary Holt (2002). Achieving Capability Maturity Model Level 2 with the Rational Unified Process. An IBM Rational Software Corporation White Paper.

• Walker Royce (2002). CMM vs CMMI: From Conventional to Modern Software Management. An IBM Rational Software Corporation Article printed in the Rational Edge. www.therationaledge.com/


http://www.therationaledge.com/

http://www.therationaledge.com/

• Rolf W. Reitzig (2003). Using Rational Software Solutions to Achieve CMMI Level 2. An IBM Rational Software Corporation Article printed in the Rational Edge.


TSU CMM CMMI

Documents

Transcript of TSU CMM CMMI