What are CMM and CMMI? What is the difference between the two?

In this article we take up two very important topics CMM and CMMI! Though these two concepts sound too much similar with only a difference of “I” there is a whole lot of difference between the two. 

The CMM stands for “capability maturity model whereas the CMMI stands for capability maturity model integration. 

What is CMM?

- CMM was born as a registered service mark of the CMU (Carnegie Mellon University). 

- CMM is quite a popular model these days that was created post the study of some data that was collected from many different organizations which had made a contract with the USDD (U.S. department of defense), the organization that had funded the whole research. 

- This model is regarded as the birth point for the engineering giant SEI or software engineering institute.

- An effective approach for improving the quality of the software system or application that is under development can be planned by applying this model to that concerned software system or application. 

- Previously, it was thought that the CMM model can only be applied to the software systems and applications.

- But eventually it was proved it cane be very effectively applied to the other processes as well. Gradually a concept of this model was developed which could also be applied to the business.

What is CMMi?

- CMMI is the abbreviation for capability maturity model integration.

- It is rather like a simple approach for improving the processes whose basic aim lies in helping the organizations in improving their overall performance.

- Unlike CMM, CMMI can effectively drive the improvement process across a whole organization, project or even across a division of the organization. 

- Current version 1.3 of CMMI is supportable by most of the organizations. 

- With the aid of CMMI, following things can be done:

1. Traditionally separate organizational functions can be properly integrated.
2. Process improvement priorities as well as goals can be set.
3. Guidance for quality processes can be provide and
4. A point of reference for the appraisal of the current processes can be provided etc.

To say three major aspects are addressed in CMMI as mentioned below:

1. Product and service development
2. Service establishment, management and delivery and
3. Product and service acquisition.

Differences between CMM and CMMi

Now let us clearly state what all the differences among these two! 

- Firstly the CMM was developed for software systems and applications whereas the CMMI was developed as a means for the integration of the past and future models and build some initially integrated models. 

- Gradually, CMM models gained success and found their use in the following concepts also:

1. Systems engineering
2. Software acquisition
3. Integrated public development
4. Software quality assurance and so on.

- Though all the above mentioned CMMs proved to be quite useful they presented some of the drawbacks also as mentioned below:

1. They were overlapping.
2. They were contradicting
3. They lack an understandable interface
4. They lack standardization and
5. They all displayed different levels of detail etc.

All these drawbacks led to a quite expensive and utter confusing improvement programs that conflicted with one another. 

- CMMI is nothing but an upgraded version of the CMM which has got much wider applications than CMM. 

- CMM model can be considered to be a reference model constituting of matured practices in a discipline that is specified but difficult to integrate as and when needed. On the other hand, the CMMI can be considered to be a more matured set of practices as well as guidelines. 

- It was resultant of the combination of the best components of individual disciplines of CMM. 

Differentiate between Capability Maturity Model (CMM) and Scrum?

In the year of 2002, when both the CMM (capability maturity model) and agile software development models were on the list of the highest demanded software development methodologies, the CMM model and agile processes were considered to be to pretty much same.

But, later in the same year two of the software engineers Jain and Turner argued that these two software development models or processes have much difference between them if investigated in detail.

This article discusses about the differences between the cmm model and agile methods. There is no fixed or appropriate way to develop a software system or application but at different stages a different methodology is to be adopted. 

Coming to the scrum, it is a pre defined development life cycle based entirely up on the agile principles. The CMM on the other hand comprises of many practices that can be adopted by a team so as to improve its overall performance. The CMM model pays more attention to the areas that require change and project management. 

Another aspect of the CMM is focussed up on the following three aspects:

1.      Engineering skills

2.      Organizational learning

3.      Advanced project management

Differences between Capability Maturity Model and Scrum

Difference #1:

- In CMM, it is required that an understanding is developed with the requirement

providers  based upon the definition of the requirements.

- In Scrum, there are reviews of the requirements listed in the product back log with

development team and product owner.

Difference #2:

- In CMM, commitment to the requirements is demanded from all those involved in    

the project. 

- In Scrum practice, the commitment is needed in the sprint planning and release 

planning.

Difference #3:

- In CMM, practice any changes to be made are directly carried out on the

requirements.

- In Scrum practice, the changes are recorded in the product back log and are worked 

up on in the later sprints.

Difference #4:

- In CMM, it involves the identification of the inconsistencies among the work 

products and the requirements.

- In Scrum practice, the inconsistencies are identified during the sprint planning and

release planning sessions.

Difference #5:

- CMM develops a top level work breakdown structure for the proper estimation of the  

project scope. 

- In scrum, the standard tasks combined with the specific project tasks define the 

scope of the project.

Difference #6:

- In CMM, the attributes of the work products and tasks are maintained kept for the 

maintenance of the estimates.

- In scrum, this task is done with the help of story points.

Difference #7:

- In CMM, the whole project budget and schedule is prepared in CMM.

- In scrum, a project is broken down in to several sprints and for every sprint there is a 

separate schedule and back log.

Difference #8:

- The main estimates that are carried out in CMM are of the resources required to 

perform the development tasks. 

- On the other side, the scrum maintains the estimates of the sprint back log, release 

plan and assignments.

Difference #9:

- In CMM a plan of involvement is prepared for all the stakeholders separately during 

the planning process.

- In Scrum, there are predefined core and ancillary roles that saves a lot of time.

Difference #10:

- In CMM, at the end of the day the project plan is re-conciliated to check out the 

available resources.

- In scrum, there is sprint planning meetings and daily scrum meetings to do this task.

Difference #11:

- The project development in CMM is tracked by monitoring the actual values of the 

project parameters against the already prepared project plan. 

- On the other hand the scrum is aided by the sprint burn down charts for the same 

purpose. 

What are different characteristics of Capability Maturity Model (CMM)?

Capability maturity model or CMM as it is often abbreviated. It is a development model developed after a prolonged study of the data collected from various organizations from all over the world.

Characteristics of Capability Maturity Model
1.The development of this model was funded by the USDD (United States department of defence).

2.The capability maturity model became the foundation for the development of software engineering institute or SEI as it is popularly known as.

3.The term “maturity” emphasises process optimization and level of formality.

4.Processes are optimized from ad-hoc practices to steps that have been formally defined.

5.Nowadays this model is being used effectively for management of result metrics.

6.Capability maturity model has proved to be great help in active optimization of the processes.

7.This model allows improvement in the development processes of an organization.

8.It is an effective and good approach towards improvement of any organization’s development processes.

9.This model is securely based upon the frame work of process maturity which was developed in 1989.

10.Initially it was used for objective assessment of the processes carried out by the contractors of the government to keep a track on the project.

11.CMM is not only used in the field of software engineering but, it is also applied to organizational processes of a business.

12.It is used in other fields like:
- Software development
- System engineering
- Software maintenance
- Project management
- System acquisition
- Risk management
- Information technology
- Human capital management and
- Services

Where is Capability Maturity Model used?

Capability maturity model is being extensively used in various organizations like in commerce, government offices, software development organizations and industry.

What was the need for Capability Maturity Model?
- In the 20th century the use of computers was wide spread.

- Computerized processes were thought to be less costly, effective and flexible way to carry out tasks.

- As more and more organizations started adopting computerized processing systems, the demand for software development eventually rose.

- As a result CMM was developed, of course with lots of failures.

- The computers were a new technology at that time and so there was a lot of pressure on developers to deliver quality products within a stipulated period of time.

- The US military was in havoc that because all their projects were running out of budget and time.

- So in order to know the reason behind all this, they funded the study at SEI. Active study started at SEI.

- It was watts Humphrey who actually came up with the actual idea of CMM.

- He based his approach on the evolution of software development practices.

- He concentrated on all the processes as one instead of concentrating on just one software development process.

- Since then the CMM has become popular among various organizations and is used as a powerful tool for improving overall performance of the business.

Though CMM proved to be a very effective tool for business but many times it caused problems in software development.

- CMM didn’t allow use of multiple software development practices. It was superseded by CMMI.

- These days still the capability maturity model is being used as the model with the capability of handling general processes when it comes to public domain.

Some Important Facts About CMM
1.CMM is still maintaining its position as a model of maturity of process.

2.CMM provides a place to start the development.

3.It uses a common language and the development is based upon a shared vision.

4.It effectively develops a frame work for actions according to their priority.

5.For an organization it defines the ways for improvement.

6.It is used an aid for better and effective understanding.

CMM has 5 aspects:
- Maturity level
- Key process area
- Goal
- Features
- Practices.

Differences between Capability Maturity Model(CMM) and Capability Maturity Model Integration(CMMI)

Capability Maturity Model (CMM)

The Capability Maturity Model for Software (CMM) is a framework that describes the key elements of an effective software process. There are CMMs for non software processes as well, such as Business Process Management (BPM).
- The CMM describes an evolutionary improvement path from an ad hoc, immature process to a mature, disciplined process.
- The CMM covers practices for planning, engineering, and managing software development and maintenance.
- When followed, these key practices improve the ability of organizations to meet goals for cost, schedule, functionality, and product quality.
- The CMM establishes a yardstick against which it is possible to judge, in a repeatable way, the maturity of an organization's software process and compare it to the state of the practice of the industry.
- The CMM can also be used by an organization to plan improvements to its software process.
- It also reflects the needs of individuals performing software process, improvement, software process assessments, or software capability evaluations; is documented; and is publicly available.

Capability Maturity Model Integration (CMMI)
- CMMI is a process improvement approach that provides organizations with the essential elements of effective processes.
- It can be used to guide process improvement across a project, a division, or an entire organization.
- CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.

Misconceptions of the Capability Maturity Model (CMM)

CMM is the most widely used Software Process Improvement model. It was developed by Carnegie Mellon University’s Software Engineering Institute (SEI). A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level provides a layer in the foundation for continuous process improvement.
In CMMI models with a staged representation, there are five maturity levels designated by the numbers 1 through 5.
- Initial
- Managed/Repeatable
- Defined
- Quantitatively Managed
- Optimizing

Misconceptions About Maturity Levels
- If you are at Level 1, you are pond scum.
Being Level 1 does not mean that the members of a software organization are barely breathing. It does mean that the organization's projects are likely to have less predictability, more rework, more defects, and more schedule slippage than those in a higher maturity organization.
- Level 2 is mostly about software engineering activities, such as requirements analysis, design, coding, and testing.
- You have to perform all of the activities and practices defined at some maturity level in order to achieve that level.
- Software measurement is not required until you are approaching Level 4.
- The SEI certifies an organization at a specific maturity level.
- The CMM requires that you use specific software development practices, tools, and methodologies.
- The CMM mandates a waterfall life cycle model.
- The Software Quality Assurance KPA is mostly about testing.
- The CMM requires that you perform software inspections to achieve Level 3.
- Having a "tailorable" process really means that you can do whatever you want.
- Requirements management is the same thing as requirements engineering.
- You cannot work on improving KPAs more than one maturity level higher than your current level.
- The CMM mandates bureaucracy and wasteful paperwork.
- The CMM is a quick fix for short-term problems.
- CMMI is proprietary for the US military use.
- CMMI is the next release of CMM.
- Everyone uses the Staged Representation.
- You cannot use CMMI if you already use some other improvement model.
- CMMI is not suitable for small organizations.
- CMMI is used only to get an appraisal rating.
- CMMI is not suitable for companies using Agile methods.
- CMMI implementation takes long and is expensive and does not pay off.
- CMMI is a process model.

Verification (VER) Process Area in Capability Maturity Model (CMMi)

An Engineering Process Area at Maturity Level 3. The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.
Verification includes verification of the product and intermediate work products against all selected requirements, including customer, product, and product component requirements. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.

Verification is inherently an incremental process because it occurs throughout the development of the product and work products, beginning with verification of the requirements, progressing through the verification of the evolving work products, and culminating in the verification of the completed product.

Specific Practices by Goal

SG 1 Prepare for Verification
Up-front preparation is necessary to ensure that verification provisions are embedded in product and product component requirements, designs, developmental plans, and schedules. Verification includes selection, inspection, testing, analysis, and demonstration of work products. Methods of verification include, but are not limited to, inspections, peer reviews, audits, walkthroughs, analyses, simulations, testing, and demonstrations.
- SP 1.1 Select Work Products for Verification.
The work products to be verified may include those associated with maintenance, training, and support services. The work product requirements for verification are included with the verification methods.
- SP 1.2 Establish the Verification Environment.
An environment must be established to enable verification to take place. The verification environment can be acquired, developed, reused, modified, or a combination of these, depending on the needs of the project. The type of environment required will depend on the work products selected for verification and the verification methods used.
- SP 1.3 Establish Verification Procedures and Criteria.
The verification procedures and criteria should be developed concurrently and iteratively with the product and product component designs. Verification criteria are defined to ensure that the work products meet their requirements.

SG 2 Perform Peer Reviews
Peer reviews involve a methodical examination of work products by the producers peers to identify defects for removal and to recommend other changes that are needed. The peer review is an important and effective verification method implemented via inspections, structured walkthroughs, or a number of other collegial review methods.
- SP 2.1 Prepare for Peer Reviews.
Preparation activities for peer reviews typically include identifying the staff who will be invited to participate in the peer review of each work product; identifying the key reviewers who must participate in the peer review; preparing and updating any materials that will be used during the peer reviews, such as checklists and review criteria, and scheduling peer reviews.
- SP 2.2 Conduct Peer Reviews.
One of the purposes of conducting a peer review is to find and remove defects early. Peer reviews are performed incrementally as work products are being developed. These reviews are structured and are not management reviews. Peer reviews may be performed on key work products of specification, design, test, and implementation activities and specific planning work products.
- SP 2.3 Analyze Peer Review Data.
Analyze data about preparation, conduct, and results of the peer reviews.

SG 3 Verify Selected Work Products
The verification methods, procedures, and criteria are used to verify the selected work products and any associated maintenance, training, and support services using the appropriate verification environment.
- SP 3.1 Perform Verification.
Verifying products and work products incrementally promotes early detection of problems and can result in the early removal of defects. The results of verification save considerable cost of fault isolation and rework associated with troubleshooting problems.
- SP 3.2 Analyze Verification Results.
Analyze the results of all verification activities. Actual results must be compared to established verification criteria to determine acceptability. The results of the analysis are recorded as evidence that verification was conducted.

Validation (VAL) Process Area in Capability Maturity Model (CMMi)

An Engineering process area at Maturity Level 3. The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment. Validation activities can be applied to all aspects of the product in any of its intended environments, such as operation, training, manufacturing, maintenance, and support services. The methods employed to accomplish validation can be applied to work products as well as to the product and product components.
The validation environment should represent the intended environment for the product and product components as well as represent the intended environment suitable for validation activities with work products.
Validation demonstrates that the product, as provided, will fulfill its intended use; whereas, verification addresses whether the work product properly reflects the specified requirements. Whenever possible, validation should be accomplished using the product or product component operating in its intended environment. The entire environment can be used or only part of it.

Specific Practices by Goal

SG 1 Prepare for Validation
Preparation activities include selecting products and product components for validation and establishing and maintaining the validation environment, procedures, and criteria. The items selected for validation may include only the product or it may include appropriate levels of the product components that are used to build the product.
- SP 1.1 Select Products for Validation.
Products and product components are selected for validation on the basis of their relationship to user needs. For each product component, the scope of the validation (e.g., operational behavior, maintenance, training, and user interface) should be determined.
- SP 1.2 Establish the Validation Environment.
The requirements for the validation environment are driven by the product or product components selected, by the type of the work products (e.g., design, prototype, and final version), and by the methods of validation. These may yield requirements for the purchase or development of equipment, software, or other resources. These requirements are provided to the requirements development processes for development. The validation environment may include the reuse of existing resources.
- SP 1.3 Establish Validation Procedures and Criteria.
Validation procedures and criteria are defined to ensure that the product or product component will fulfill its intended use when placed in its intended environment. Acceptance test cases and procedures may meet the need for validation procedures.
The validation procedures and criteria include test and evaluation of maintenance, training, and support services.

SG 2 Validate Product or Product Components
The product or product components are validated to ensure that they are suitable for use in their intended operating environment. The validation methods, procedures, and criteria are used to validate the selected products and product components and any associated maintenance, training, and support services using the appropriate validation environment. Validation activities are performed throughout the product lifecycle.
- SP 2.1 Perform Validation.
Perform validation on the selected products and product components. To be acceptable to users, a product or product component must perform as expected in its intended operational environment. Validation activities are performed and the resulting data are collected according to the established methods, procedures, and criteria.
- SP 2.2 Analyze Validation Results.
The data resulting from validation tests, inspections, demonstrations, or evaluations are analyzed against the defined validation criteria. Analysis reports indicate whether the needs were met; in the case of deficiencies, these reports document the degree of success or failure and categorize probable cause of failure. The collected test, inspection, or review results are compared with established evaluation criteria to determine whether to proceed or to address requirements or design issues in the requirements development or technical solution processes.

Technical Solution (TS) Process Area in Capability Maturity Models (CMM)

The purpose of Technical Solution (TS) is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combination as appropriate. It is an Engineering process area at Maturity Level 3.
The process area focuses on the following:
- Evaluating and selecting solutions (sometimes referred to as “design approaches,” “design concepts,” or “preliminary designs”) that potentially satisfy an appropriate set of allocated requirements.
- Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component).
-Implementing the designs as a product or product component.

Technical Solution specific practices apply not only to the product and product components but also to product-related lifecycle processes. Processes associated with the Technical Solution process area receive the product and product component requirements from the requirements management processes.

Specific Practices by Goal

SG 1 Select Product-Component Solutions
Product or product component solutions are selected from alternative solutions. Alternative solutions and their relative merits are considered in advance of selecting a solution. Key requirements, design issues, and constraints are established for use in alternative solution analysis. Architectural features that provide a foundation for product improvement and evolution are considered.
- SP 1.1 Develop Alternative Solutions and Selection Criteria.
The activity of selecting alternative solutions and issues to be subject to decision analyses and trade studies is accomplished by the involvement of relevant stakeholders. These stakeholders represent both business and technical functions and the concurrent development of the product and the product-related lifecycle processes (e.g., manufacturing, support, training, verification, and disposal).
- SP 1.2 Select Product Component Solutions.
Selecting product components that best satisfy the criteria establishes the requirement allocations to product components. Lower level requirements are generated from the selected alternative and used to develop the product component design. Interface requirements among product components are described, primarily functionally. Physical interface descriptions are included in the documentation for interfaces to items and activities external to the product.

SG 2 Develop the Design
Product or product component designs must provide the appropriate content not only for implementation, but also for other phases of the product lifecycle such as modification, procurement, maintenance, sustainment, and installation. The design documentation provides a reference to support mutual understanding of the design by relevant stakeholders and supports future changes to the design both during development and in subsequent phases of the product lifecycle.
- SP 2.1 Design the Product or Product Component.
Product design consists of two broad phases that may overlap in execution: preliminary and detailed design.
- SP 2.2 Establish a Technical Data Package.
A technical data package provides the developer with a comprehensive description of the product or product component as it is developed. Such a package also provides procurement flexibility in a variety of circumstances such as performance-based contracting or build to print.
- SP 2.3 Design Interfaces Using Criteria.
Design product component interfaces using established criteria. The criteria for interfaces frequently reflect critical parameters that must be defined, or at least investigated, to ascertain their applicability. These parameters are often peculiar to a given type of product (e.g., software, mechanical, electrical, and service) and are often associated with safety, security, durability, and mission-critical characteristics.
- SP 2.4 Perform Make, Buy, or Reuse Analysis.
The determination of what products or product components will be acquired is frequently referred to as a “make-or-buy analysis.” It is based on an analysis of the needs of the project. This make-or-buy analysis begins early in the project during the first iteration of design; continues during the design process; and is completed with the decision to develop, acquire, or reuse the product.

SG 3 Implement the Product Design
Product components are implemented from the designs established by the specific practices in the Develop the Design specific goal. The implementation usually includes unit testing of the product components before sending them to product integration and development of end-user documentation.
- SP 3.1 Implement the Design.
Once the design has been completed, it is implemented as a product component. The characteristics of that implementation depend on the type of product component. Design implementation at the top level of the product hierarchy involves the specification of each of the product components at the next level of the product hierarchy. This activity includes the allocation, refinement, and verification of each product component. It also involves the coordination between the various product component development efforts.
- SP 3.2 Develop Product Support Documentation.
Develop and maintain the end-use documentation. This specific practice develops and maintains the documentation that will be used to install, operate, and maintain the product.

Supplier Agreement Management (SAM) Process Area in CMMi

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers. It is a Project Management process area at Maturity Level 2.
The Supplier Agreement Management process area involves the following:
- Determining the type of acquisition that will be used for the products to be acquired.
- Selecting suppliers.
- Establishing and maintaining agreements with suppliers.
- Executing the supplier agreement.
- Monitoring selected supplier processes.
- Evaluating selected supplier work products.
- Accepting delivery of acquired products.
- Transitioning acquired products to the project.

Suppliers may take many forms depending on business needs, including in-house vendors (i.e., vendors that are in the same organization but are external to the project), fabrication capabilities and laboratories, and commercial vendors. A formal agreement is established to manage the relationship between the organization and the supplier. A formal agreement is any legal agreement between the organization (representing the project) and the supplier.

Specific Practices by Goal

SG 1 Establish Supplier Agreements
Agreements with the suppliers are established and maintained.
- SP 1.1 Determine Acquisition Type.
Determine the type of acquisition for each product or product component to be acquired. There are many different types of acquisition that can be used to acquire products and product components that will be used by the project.
- SP 1.2 Select Suppliers.
Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria. Criteria should be established to address factors that are important to the project.Examples of factors include geographical location of the supplier, supplier’s performance records on similar work, engineering capabilities, staff and facilities available to perform the work and prior experience in similar applications.
- SP 1.3 Establish Supplier Agreements.
When integrated teams are formed, team membership should be negotiated with suppliers and incorporated into the agreement. The agreement should identify any integrated decision making, reporting requirements (business and technical), and trade studies requiring supplier involvement.

SG 2 Satisfy Supplier Agreements
Agreements with the suppliers are satisfied by both the project and the supplier.
- SP 2.1 Execute the Supplier Agreement.
Perform activities with the supplier as specified in the supplier agreement. Typical work products are supplier progress reports and performance measures, supplier review materials and reports, action items tracked to closure and documentation of product and document deliveries.
- SP 2.2 Monitor Selected Supplier Processes.
Select, monitor, and analyze processes used by the supplier. The selection must consider the impact of the supplier's processes on the project. On larger projects with significant subcontracts for development of critical components, monitoring of key processes is expected. For most vendor agreements where a product is not being developed or for smaller, less critical components, the selection process may determine that monitoring is not appropriate. Between these extremes, the overall risk should be considered in selecting processes to be monitored.
- SP 2.3 Evaluate Selected Supplier Work Products.
The scope of this specific practice is limited to suppliers providing the project with custom-made products, particularly those that present some risk to the program due to complexity or criticality. The intent of this specific practice is to evaluate selected work products produced by the supplier to help detect issues as early as possible that may affect the supplier's ability to satisfy the requirements of the agreement.
- SP 2.4 Accept the Acquired Product.
Ensure that the supplier agreement is satisfied before accepting the acquired product. Acceptance reviews and tests and configuration audits should be completed before accepting the product as defined in the supplier agreement.
- SP 2.5 Transition Products.
Transition the acquired products from the supplier to the project. Before the acquired product is transferred to the project for integration, appropriate planning and evaluation should occur to ensure a smooth transition.

Risk Management (RSKM) Process Area in CMMi

It is a Project Management process area at Maturity Level 3. The purpose of Risk Management (RSKM) is 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 adverse impacts on achieving objectives.
Risk management is a continuous, forward-looking process that is an important part of management. Risk management should address issues that could endanger achievement of critical objectives. A continuous risk management approach is applied to effectively anticipate and mitigate the risks that may have a critical impact on the project.
Effective risk management includes early and aggressive risk identification through the collaboration and involvement of relevant stakeholders, as described in the stakeholder involvement plan addressed in the Project Planning process area. Risk management must consider both internal and external sources for cost, schedule, and performance risk as well as other risks.

Specific Practices by Goal

SG 1 Prepare for Risk Management
Preparation is conducted by establishing and maintaining a strategy for identifying, analyzing, and mitigating risks. This is typically documented in a risk management plan. The risk management strategy addresses the specific actions and management approach used to apply and control the risk management program.
- SP 1.1 Determine Risk Sources and Categories.
Identification of risk sources provides a basis for systematically examining changing situations over time to uncover circumstances that impact the ability of the project to meet its objectives. Risk sources are both internal and external to the project.
- SP 1.2 Define Risk Parameters.
Parameters for evaluating, categorizing, and prioritizing risks include risk likelihood (i.e., probability of risk occurrence), risk consequence (i.e., impact and severity of risk occurrence), thresholds to trigger management activities.
- SP 1.3 Establish a Risk Management Strategy.
A comprehensive risk management strategy addresses items such as the following:
. The scope of the risk management effort.
. Methods and tools to be used for risk identification, risk analysis, risk mitigation, risk monitoring, and communication.
. Project-specific sources of risks.
. How these risks are to be organized, categorized, compared, and consolidated.
. Parameters, including likelihood, consequence, and thresholds, for taking action on identified risks.
. Risk mitigation techniques to be used, such as prototyping, piloting, simulation, alternative designs, or evolutionary development.
. Definition of risk measures to monitor the status of the risks.
. Time intervals for risk monitoring or reassessment.

SG 2 Identify and Analyze Risks
The degree of risk impacts the resources assigned to handle an identified risk and the determination of when appropriate management attention is required.
- SP 2.1 Identify Risks.
The identification of potential issues, hazards, threats, and vulnerabilities that could negatively affect work efforts or plans is the basis for sound and successful risk management.
- SP 2.2 Evaluate, Categorize, and Prioritize Risks.
The evaluation of risks is needed to assign relative importance to each identified risk, and is used in determining when appropriate management attention is required.

SG 3 Mitigate Risks
The steps in handling risks include developing risk-handling options, monitoring risks, and performing risk-handling activities when defined thresholds are exceeded.
- SP 3.1 Develop Risk Mitigation Plans.
A critical component of a risk mitigation plan is to develop alternative courses of action, workarounds, and fallback positions, with a recommended course of action for each critical risk. The risk mitigation plan for a given risk includes techniques and methods used to avoid, reduce, and control the probability of occurrence of the risk, the extent of damage incurred should the risk occur (sometimes called a “contingency plan”), or both.
- SP 3.2 Implement Risk Mitigation Plans.
To effectively control and manage risks during the work effort, follow a proactive program to regularly monitor risks and the status and results of risk-handling actions. The risk management strategy defines the intervals at which the risk status should be revisited.

Requirements Management (REQM) Process Area in CMMi

The purpose of Requirements Management (REQM) is 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. It is an Engineering process area at Maturity Level 2.
Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product component requirements that will also be managed by the requirements management processes.
Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product component requirements that will also be managed by the requirements management processes.

REQM vs.RD

- REQM is about managing the set of requirements and keeping it consistent with the project’s plans whereas RD is about developing the requirements in a systematic way.
- REQM is a Maturity Level 2 process area whereas RD is a Maturity Level 3 process area.

Specific Practices by Goal

SG 1 Manage Requirements
The project maintains a current and approved set of requirements over the life of the project by managing all changes to the requirements, maintaining the relationships among the requirements, the project plans, and the work products, identifying inconsistencies among the requirements, the project plans, and the work products and taking corrective action.
- SP 1.1 Obtain an Understanding of Requirements.
The intent of this SP is to establish a criteria for the project to identify appropriate requirements providers, criteria for the evaluationand acceptance of requirements, and ensure through an analysis or reviewprocess that the established criteria are met.
- SP 1.2 Obtain Commitment to Requirements.
Once the understanding of the requirement is established through the SP1.1, this SP deals with agreements and commitmentsamong those who have to carry out the activities necessary to implement the requirements.
- SP 1.3 Manage Requirements Changes.
Once commitments to the requirements are established and plans have been made. The project will transform from planning mode to execution mode. During the project execution phase, changes to requirements may occur for a variety of reasons. As needs change and as work proceeds, additional requirements are derived and changes may have to be made to the existing requirements.
- SP 1.4 Maintain Bidirectional Traceability of Requirements.
he intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.
- SP 1.5 Identify Inconsistencies between Project Work and Requirements.
This SP focuses on maintaining consistency between requirements and project plans. I.e. the project plan should be revised, if changes to the requirements are identified to be impacting the schedule.

Requirements Development (RD) Process Area in CMMi

he purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements. An Engineering process area at Maturity Level 3.
This process area describes three types of requirements: customer requirements, product requirements, and product component requirements. Taken together, these requirements address the needs of relevant stakeholders, including those pertinent to various product lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, and maintainability).
This process area addresses all customer requirements rather than only product-level requirements because the customer may also provide specific design requirements.
Customer requirements are further refined into product and product component requirements. In addition to customer requirements, product and product component requirements are derived from the selected design solutions.

Specific Goals and Practices

SG 1 Develop Customer Requirements
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. The needs of stakeholders are the basis for determining customer requirements. The stakeholder needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements.
- SP 1.1 Elicit Needs.
Eliciting goes beyond collecting requirements by proactively identifying additional requirements not explicitly provided by customers. Additional requirements should address the various product lifecycle activities and their impact on the product.
- SP 1.2 Develop the Customer Requirements.
Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements. The various inputs from the relevant stakeholders must be consolidated, missing information must be obtained, and conflicts must be resolved in documenting the recognized set of customer requirements. The customer requirements may include needs, expectations, and constraints with regard to verification and validation.

SG 2 Develop Product Requirements
Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements called “product and product component requirements.” Product and product component requirements address the needs associated with each product lifecycle phase.
- SP 2.1 Establish Product and Product-Component Requirements.
The customer requirements may be expressed in the customer’s terms and may be nontechnical descriptions. The product requirements are the expression of these requirements in technical terms that can be used for design decisions.
- SP 2.2 Allocate Product-Component Requirements.
Allocate the requirements for each product component. The requirements for product components of the defined solution include allocation of product performance; design constraints; and fit, form, and function to meet requirements and facilitate production.
- SP 2.3 Identify Interface Requirements.
Interfaces between functions (or between objects) are identified. Functional interfaces may drive the development of alternative solutions described in the Technical Solution process area.

SG 3 Analyze and Validate Requirements
The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in both the Develop Customer Requirements specific goal and the Develop Product Requirements specific goal. The specific practices associated with this specific goal cover analyzing and validating the requirements with respect to the user’s intended environment.
- SP 3.1 Establish Operational Concepts and Scenarios.
A scenario is typically a sequence of events that might occur in the use of the product, which is used to make explicit some of the needs of the stakeholders. In contrast, an operational concept for a product usually depends on both the design solution and the scenario.
- SP 3.2 Establish a Definition of Required Functionality.
The definition of functionality, also referred to as “functional analysis,” is the description of what the product is intended to do. The definition of functionality can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used.
- SP 3.3 Analyze Requirements.
Analyze requirements to ensure that they are necessary and sufficient.
- SP 3.4 Analyze Requirements to Achieve Balance.
Analyze requirements to balance stakeholder needs and constraints. Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk.
- SP 3.5 Validate Requirements.
Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation.

Quantitative Project Management (QPM) Process Area in CMMi

The purpose of Quantitative Project Management (QPM) is to quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives. A Project Management process area at Maturity Level 4.
The Quantitative Project Management process area involves the following:
- Establishing and maintaining the project’s quality and process-performance objectives.
- Identifying suitable subprocesses that compose the project’s defined process based on historical stability and capability data found in process-performance baselines or models.
- Selecting the subprocesses of the project’s defined process to be statistically managed.
- Monitoring the project to determine whether the project’s objectives for quality and process performance are being satisfied, and identifying appropriate corrective action.
- Selecting the measures and analytic techniques to be used in statistically managing the selected subprocesses.
- Establishing and maintaining an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques.
- Monitoring the performance of the selected subprocesses to determine whether they are capable of satisfying their quality and process-performance objectives, and identifying corrective action.
- Recording statistical and quality management data in the organization’s measurement repository.

Specific Goals and Practices

SG 1 Quantitatively Manage the Project

The project is quantitatively managed using quality and process-performance objectives.
- SP 1.1 Establish the Project's Objectives.
When establishing the project’s quality and process-performance objectives, it is often useful to think ahead about which processes from the organization’s set of standard processes will be included in the project’s defined process, and what the historical data indicates regarding their process performance.
- SP 1.2 Compose the Defined Processes.
Select the subprocesses that compose the project’s defined process based on historical stability and capability data. Subprocesses are identified from the process elements in the organization’s set of standard processes and the process artifacts in the organization’s process asset library.
- SP 1.3 Select the Subprocesses that will be statistically managed.
Selecting the subprocesses to be statistically managed is often a concurrent and iterative process of identifying applicable project and organization quality and process-performance objectives, selecting the subprocesses, and identifying the process and product attributes to measure and control.
- SP 1.4 Manage Project Performance.
A prerequisite for such a comparison is that the selected subprocesses of the project’s defined process are being statistically managed and their process capability is understood. The specific practices of specific goal 2 provide detail on statistically managing the selected subprocesses.

SG 2 Statistically Manage Subprocess Performance
The performance of selected subprocesses within the project's defined process is statistically managed. This specific goal describes an activity critical to achieving the Quantitatively Manage the Project specific goal of this process area.
- SP 2.1 Select Measures and Analytic Techniques.
Select the measures and analytic techniques to be used in statistically managing the selected subprocesses.
- SP 2.2 Apply Statistical Methods to Understand Variation.
Establish and maintain an understanding of the variation of the selected subprocesses using the selected measures and analytic techniques. Understanding variation is achieved, in part, by collecting and analyzing process and product measures so that special causes of variation can be identified and addressed to achieve predictable performance.
- SP 2.3 Monitor Performance of the Selected Subprocesses.
Monitor the performance of the selected subprocesses to determine their capability to satisfy their quality and process-performance objectives, and identify corrective action as necessary.
- SP 2.4 Record Statistical Management Data.
Record statistical and quality management data in the organization’s measurement repository.