a



Introduction to Capability Maturity Model Integrated

by Janette Toral


(visit the photo gallery for a bigger size)

The Software Engineering Institute (SEI) Capability Maturity Model® for Software (SW-CMM) describes a framework that organizations can use to determine their ability to develop and maintain software. It is a model for organizational improvement.

The SW-CMM is based on the process management work of W. Edwards Deming, Joseph M. Juran, and Phillip B. Crosby, and can be applied by organizations to improve their software process through a software process assessment. The SW-CMM is also applied to software vendors via contractor evaluation.

Certification or formal assessment is normally done in the presence of someone from Carnegie Mellon University - Software Engineering Institute who would play the Lead Assessor role. This person will form an evaluation or assessment team from selected experienced individuals from the organization who will be trained in the process model and in conducting the assessment.

As CMM sunset last December 2003, SEI earlier released the Capability Maturity Model Integrated® (CMMI) that builds on and extends the best practices of the SW-CMM and other models. Organizations now, instead of undergoing numerous training, implementation, and assessment on various models, can just look into one with CMMI.

The CMMI is a prescriptive process model as it describes what should be done during software development. This includes dealing problems when encountered and emphasizes the need to prepare for changing situations. It illustrates the tasks and documents that need to be produced and reviewed. It also requires the need for stakeholders to be involved and responsible in the process.

The CMMI is also used as a benchmark by large organizations in evaluating the competitiveness of suppliers. It serves as a guide for software process improvement initiatives by various industries that see their IT (information technology) systems as a critical component for the achievement of business goals.

High quality software processes are deemed critical especially to organizations that build systems that are meant to save lives. This can include:
  1. Software used in medical equipments to accurately predict a potential disease or even cure it.
  2. Weapon systems meant to defend one country.
  3. Software used to operate space shuttles or satellites. (It is hard imagining them to reboot their systems or having a software error in outer space)
There are more critical applications or use of software today that will be too long to detail here. My point of stating this is not to exaggerate but to highlight the importance of quality software processes. Thinking that having software errors is ok as they can be fixed is not appropriate for these applications. Having such thinking speaks so much on how we regard or view the importance of quality in our software development work.

The CMMI model has two representations:

1. Continuous - looks into a set of process areas relating to a single process area or practice. This representation provides flexibility for focusing on specific process areas that are important to one's organization.

In this representation, the process areas are spread in 4 categories or process groups. They are:

a. Project management composed of the following process areas:
  • Project planning
  • Project monitoring and control
  • Supplier agreement management
  • Integrated project management
  • Integrated supplier management
  • Integrated teaming
  • Risk management
  • Quantitative project management
b. Support with the following process areas:
  • Configuration management
  • Process and product quality assurance
  • Measurement and analysis
  • Causal analysis and resolution
  • Decision analysis and resolution
  • Organizational environment for integration
c. Engineering with the following process areas:
  • Requirements management
  • Requirements development
  • Technical solution
  • Product integration
  • Verification
  • Validation
d. Process management with the following process areas:
  • Organizational process focus
  • Organization process definition
  • Organizational training
  • Organizational process performance
  • Organizational innovation and deployment
2. Staged - this representation looks into an established set of process areas across an organization. It also provides a guide for sequenced implementation. The process areas are spread into five maturity levels where each is a layer for continuous process improvement.

a. Level 1.
There are no CMMI stated process areas in this level. This is where most software development organizations are today.

Although there are informal and flexible processes performed in this level, it is likely to have less predictability, more rework, more defects, and more schedule slippage than those in a higher maturity. Usually, the organization's software development success is attributed to its people and so are its failures due to lack of established processes.

b. Level 2.
Despite an organization having established software engineering procedures, without a well-followed project management processes, these procedures can be bend if project management dictates it.

This level addresses practices that contribute to the creation of a disciplined project management culture in the organization. It includes:
  • Requirements management
  • Project planning
  • Project monitoring and control
  • Supplier agreement management
  • Configuration management
  • Process and product quality assurance
  • Measurement and analysis
c. Level 3.
This level covers software engineering and contribute to the standardization of processes. It includes process areas such as:
  • Requirements development
  • Technical solution
  • Product integration
  • Verification
  • Validation
  • Organizational process focus
  • Organizational process definition
  • Organizational training
  • Integrated project management
  • Integrated supplier management
  • Risk management
  • Decision analysis and resolution
  • Organizational environment for integration
  • Integrated teaming
d. Level 4.
This is where processes are measured and controlled. The establishment of process areas in Level 2 and 3 paves the way for this to take place. Process areas included are:
  • Organizational process performance
  • Quantitative project management
e. Level 5.
The organization's software process improvement becomes part of its daily life as ways to innovate processes for the better becomes part of its culture. Its process areas are:
  • Organizational innovation and deployment
  • Causal analysis and resolution
For an organization to be considered having a CMMI Level 3 maturity, all process areas in levels 2 and 3 are being practiced in an organization. If an organization misses one process area, without proper justification, can result to non-consideration for an organization to be at such a level during the time of assessment. Compliance is checked based if the company adheres to to generic goal and practices of each level and specific practices of each process area.

Please download the CMMI-SE/SW guide or we popularly refer to as the CMMI bible for more information at http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr012.pdf.