What Is Capability Maturity Model_orig

The Capability Maturity Model (CMM), also known as the Software CMM (SWCMM), was first described by Watts Humphrey in his book Managing the Software Process. The CMM is a process model based on software best-practices effective in large-scale, multi-person projects. The CMM has been retired and not been updated in over 10 years. CMM has been superseded by CMMI (Capability Maturity Model Integrated).

The CMM has been used to assess the maturity levels of organization areas as diverse as software engineering, system engineering, project management, risk management, system acquisition, information technology (IT) or personnel management, against a scale of five key processes, namely: Initial, Repeatable, Defined, Managed and Optimized. CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh. It has been used extensively for avionics software and government projects around the world.

What is the Capability Maturity Model? There are many different applications of the Capability Maturity Models. Some of these models target software development, staffing, etc. In this series I will focus on the Systems Engineering Capability Maturity Model (CMM). The CMM is service marked by the Software Engineering Institute (SEI) of Carnegie Mellon University and was developed by the SEI, the Department of Defense and a host of other entities.

Why is the CMM Valuable? The CMM is valuable for several reasons.

1- It is simple and easy to understand; therefore, it speaks to the executives of

a corporation. Many corporate executives are already familiar with this model and it is probable that your company’s executives are also familiar with it. Over the years I have been able to successfully use this model to illustrate major IT issues/concepts to senior executives.CMM to be a very valuable tool for attaining project funding for key initiatives like enterprise data asset management and meta data repository development.

2- Second, as you view the model it is intuitive that a company cannot currently be ranked at a level 2 and directly jump to level 4. Instead, an organization must first develop a strategy to elevate themselves to level 3.

3- Many large companies and government institutions are actively using this model to compare themselves with other entities. In fact, many corporations have goals centered on the CMM levels. Fourth, the model gives companies a mechanism to compare themselves with other companies within their industry.

 What is CMM? • Framework that describes five (5) levels of maturity within the software process • Each maturity level within CMM is divided into Key Process Areas (KPAs) • Evolutionary improvement path from an ad hoc, immature organization to a mature, disciplined organization • CMM provides the framework. Each organization determines how to meet the criteria of the framework

 CMM Benefits • Creates a shared vision of software process improvement within an organization • Establishes a common language for the software process • Defines a set of priorities for addressing software issues • Supports measurement of the process by providing a framework for reliable, consistent assessments  CMM Focus • Capability of organizations to produce high-quality products consistently and predictably • Inherent ability of process to produce planned results • Process as a means to empower the people doing the work

The CMM model defines five levels of organizational maturity: 1. Initial level is a basis for comparison with the next levels. In an organization at the initial level, conditions are not stable for the development of quality software. The results of any project depend totally on the manager’s personal approach and the programmers’ experience, meaning the success of a particular project can be repeated only if the same managers and programmers are assigned to the next project. In addition, if managers or programmers leave the company, the quality of produced software will sharply decrease. In many cases, the development process comes down to writing code with minimal testing. 2. Repeatable level. At this level, project management technologies have been introduced in a company. That project planning and management is based on accumulated experience and there are standards for produced software (these standards are documented) and there is a special quality management group. At critical times, the process tends to roll back to the initial level. 3. Defined level. Here, standards for the processes of software development and maintenance are introduced and documented (including project management). During the introduction of standards, a transition to more effective technologies occurs. There is a special quality management department for building and maintaining these standards. A program of constant, advanced training of staff is required for achievement of this level. Starting with this level, the degree of organizational dependence on the qualities of particular developers decreases and the process does not tend to roll back to the previous level in critical situations. 4. Managed level. There are quantitative indices (for both software and process as a whole) established in the organization. Better project management is achieved due to the decrease of digression in different project indices. However, sensible

variations in process efficiency may be different from random variations (noise), especially in mastered areas. 5. Optimizing level. Improvement procedures are carried out not only for existing processes, but also for evaluation of the efficiency of newly introduced innovative technologies. The main goal of an organization on this level is permanent improvement of existing processes. This should anticipate possible errors and defects and decrease the costs of software development, by creating reusable components for example.

CMM LEVEL

DEFINITION

WHEN

TO USE

Little documentation and few if any processes and Level 1 - Chaos

procedures are in place.

Used for one of a kind projects

Success is only achieved by

of very limited scope.

the heroic actions of team members.

Enough documentation exists Level 2 - Repeatability

that the QA process is repeatable.

Level 3 Standardization

Used for any project that will be done again, whether as an upgrade or a somewhat similar variation.

QA documentation and

Critical for a QA department

processes & procedures are

that must provide QA for

standardized. Templates exist

multiple projects. Avoids

for all documentation and a

reinventing the wheel for each

QA "system" exists.

project.

The exact time & resources

Level 4 Manageability

required to provide adequate

Requires an existing data set

QA for each product is known

based on previous QA

precisely so timetables and

projects. This level can only be

quality levels are met

achieved by well documented

consistently, and without

experience.

surprises.

Level 5 - Optimization

QA processes and procedures

Actually should be used in

are understood well enough

every Stage. By Level 5, this is

to be refined and streamlined. the only thing left to work on.

Misconceptions About Maturity Levels Misconception #1: If you are at Level 1, you are pond scum. One problem with the term "process maturity" is that if you are on the low end of the scale, you are "immature" by definition. Some people object to the term "maturity" in this context because it sounds like a value judgment, rather than being an objective appraisal of process capability. The fact is that most software organizations are operating at the Initial level of the CMM today, yet some of them are successful by many commonly accepted measures (profitability, market share, customer satisfaction). However, other organizations are struggling, delivering poor quality products (or nothing) with substantial cost and schedule overruns. Being Level 1 does not mean that the members of a software organization are barely breathing (as one manager put it). 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. The CMM is concerned with organizational process capability; it does not pass judgment on the performance or capabilities of individual software practitioners. Misconception #2: Level 2 is mostly about software engineering activities, such as requirements analysis, design, coding, and testing. Actually, the Repeatable Level addresses practices that relate to planning, managing, and tracking several fundamental aspects of a software project (see Table 1). The standard software engineering tasks of analysis, design, coding, testing, and documentation are all included in a large KPA called Software Product Engineering at Level 3. For an organization to have a repeatable process, the project management controls and discipline that are provided by the Level 2 KPAs must first be established. Without a foundation of disciplined project management, even effective software engineering procedures may be abandoned during times of schedule pressure or rapidly changing requirements. Misconception #3: You have to perform all of the activities and practices defined at some maturity level in order to achieve that level. Over 120 key practices are defined for the Repeatable Level alone, counting the activities, commitments, abilities, measurements, and verification steps. You do not have to perform every one of these practices in order to achieve Level 2. However, you do need to demonstrate that you are satisfying all of the goals that are defined for the applicable Level 2 KPAs. (If an

organization does not engage in subcontracting, the Software Subcontract Management KPA is not applicable.) You may have alternative practices that accomplish the goals of a KPA, but which are not mentioned in the CMM. The key practices are only a guidelinenot a requirement-for determining whether goals are satisfied. Misconception #4: Software measurement is not required until you are approaching Level 4. People having a superficial knowledge of the CMM may be aware that the Managed Level addresses the quantitative measurement of software products and processes. These people sometimes are surprised to learn that measurement is a part of every KPA at every maturity level. The Measurement and Analysis common feature provides a hint to this effect. Most of these measurements determine the status of activities associated with application of the KPA. Consider the Requirements Management KPA. You should measure the status of each requirement, the effort spent on requirements management activities, and requirements stability (the frequency of change of the requirements). At the higher maturity levels, metrics are increasingly used to monitor progress and manage projects proactively. However, software groups at all maturity levels should begin incorporating fundamental software metrics into their routine operating practices. Misconception #5: The SEI certifies an organization at a specific maturity level. There is no such thing as being "SEI-certified," and there is no certification associated with achieving a specific CMM maturity level. Perhaps this misunderstanding arises because some people erroneously refer to CMM-based process appraisals as "audits," and certain audits do result in a certification of some sort. The SEI maintains a database of accumulated results from formal process appraisals, but it will not divulge the results for any specific organization.