CMMI Basics

1. What is the CMM©?
The Capability Maturity Model© is a set of key practices that should be implemented by any entity developing or maintaining software. It can be conceived as the product of the collective experience of many of the most successful software projects, which has been documented in the form of a model. Its purpose is to provide recommendations to the software community about what should be done in order to accomplish successful projects and to continuously improve its processes. Published by the SEI, it has been largely used by the software community to assess the maturity of the software processes used by companies and agencies, to develop improvement plans, or as a reference book to implement more mature practices. The CMM© has become a "de facto" standard in the software industry.

2. Is the CMM© recognized at the international level?
The Capability Maturity Model© version 1.0 was released by the SEI in 1990. The version 1.1, more stable, was published in 1993 and had an immediate success within the international community. Vastly used by several segments of the industry and public organizations, it has inspired numerous applications and adaptations of the model. CMM is a tool largely diffused, following a disciplined evolution involving the international software community. It is not a panacea or the final solution to the problems, but the CMM© model represents, without any doubt, one of the best references available on recommended practices for software development or maintenance.

3. Why are many companies considering the CMM as a tool for technology improvement?
The SEI assessment approach is one of the most comprehensive that has been developed. Most organizations believe that a formal SEI assessment will lend credence to any recommendations that are proposed as a consequence of the assessment.

4. Are there weaknesses associated with the SEI approach?
Unfortunately, there are. It's expensive-plan on budgeting between $50K and $100K for the assessment alone. In most cases, it requires the use of an outside assessor. It uses a preconceived linear model for the software process. Far more importantly, it provides little guidance on what to do after the assessment is complete-and that's what most companies need to know.

5. At what level in the CMM would an ISO 9001 – compliant organization be?
An ISO 90001-compliant organization would not necessarily satisfy all the key process areas in level 2 of the CMM, but it would satisfy most of the level 2 and many of the level 3 goals. Further, because ISO 9001 doesn’t address all the CMM practices, a level 1 organization could receive ISO 9001 registration.

6. Can a level 2 (or 3) organization be considered compliant with ISO 9001?
A level 2 (or 3) organization would probably be considered compliant with ISO 9001 but even a level 3 organization would need to ensure that it adequately addressed the delivery and installation process, described in clause 4.15 of ISO 9001, and it should consider the use of included software products, as described in clause 6.8 of ISO 9000-3. With this caveat, obtaining certification should be relatively stratightforward for a level 2 or higher organization.

7. Should any software quality management and process improvement efforts be based on ISO 9001 or on the CMM?
As to whether software process improvement should be based on the CMM or ISO 9001, the short answer is that an organization may want to consider both, given the significant degree of overlap. A market may require ISO 9001 certification; addressing the concerns of the CMM would help organizations prepare for an ISO 9001 audit.
Conversely, level 1 organizations would certainly profit from addressing the concerns of ISO 9001. Although either document can be used alone to structure a process-improvement program, the more detailed guidance and software specificity provided by the CMM suggests that it is the better choice.
In any case, organizations should focus on improvement to build a competitive advantage, not on achieving a score – whether that is a maturity level or a certificate. The SEI advocates addressing continuous process improvement as encompassed by the CMM, but even then there is a need to address the larger business context in the spirit of Total Quality Management.

8. Should an organization choose the CMM® or ISO9001?
· Many organizations find each, in its own way, useful.
· The SEI CMM® provides unequaled guidance for software organizations hoping to develop more mature and predictable business practices.
· ISO 9001 provides a certification for process quality.
· CMM® based improvement does not have associated with it the notion of certification.
· Instead, SEI CMM® based process improvement measures "continuous process improvement" progress against a staged model (Levels 1-5).
· Within ISO9001, it is possible to certify a software process at any Level of SEI maturity.

9. Can the CMM© be used for other types of initiatives, other than conducting assessments with a method like CBA IPI?
Yes, of course! The CMM© certainly can be used as a reference for everybody looking for good ideas for improving the way the software is done or for providing examples to replace existing ones. It provides guidance to choose among different improvement paths, ideas that can be used to base the intuitions, etc. There are several assessment methods more or less formal, others than the CBA IPI, which currently are using the CMM© as a reference.

10. Does the CMM© only apply to the software domain? Does it only address both, the development and maintenance of software?
Actually, the complete name of CMM© is SW-CMM © (for "Software CMM"). In consequence, it is obviously applicable to the software domain, in what it concerns to the development, as well as to the maintenance aspects.
The specific methods (or methodologies) and technology (software or equipment) being used by a company or agency do not impose specific constraints on the utilization of the SW-CMM©, since its practices are formulated in such a generic mode, that can be easily adapted to meet the needs of particular environments. Nevertheless, even if they have been initially oriented and worded for the software domain, some of them can be extrapolated beyond their original application and applied to other domains (not necessarily in the software domain). Independently of this potential, always keep in mind that the SEI has originally oriented the practices described in the SW-CMM© model to cover the software development and maintenance aspects.

11. What is the difference between the CMM and the CMMI?
The Capability Maturity Model (CMM) exists for approximately 10 years. Just before the publication of CMM v2.0, the SEI redirected its effort toward the integration of system and software practices, since they are often linked in the context of industrial real projects. This led toward a combined and integrated model called CMMI. Fortunately, this model reused entirely draft version 2.0 which constituted one of the major inputs to CMMI.

12. What is the concrete impact of CMMI for organizations who already use the CMM or who consider the CMM use today?
The CMMI version 1.0 was published commercially on August 11, 2000. The SEI has already confirmed that they will maintain full support of the CMM version 1.1 until CMMI version 1.1 (not 1.0) is published. This is anticipated end of 2001 or early 2002. Also, it is already confirmed that the transition will be supported by the SEI. The bottomline: if the CMM 1.1 is currently satisfying the needs of a company investing into software process improvement, there is no need to stop or slower this initiative because CMMI is in the air. On the other hand, for an organization that starts in software process improvement, it might be appropriate to consider the new CMMI. Again, the bottomline is "Don’t wait!"

13. Are there any constraints to use the CMM© in environments using specific methods or tools for development or maintenance?
No. CMM© practices are formulated in a generic way. It is independent of any method (or methodology) and of any technology environment (software or hardware).

14. Is the CMM© a prerequisite to put in place a software process improvement initiative?
Certainly is not. The CMM© is not a complete remedy; it is an incomplete model and can be further improved. Nevertheless, it represents a standard whose robustness and usefulness have been verified by hundreds of companies around the world. Choosing a model with these characteristics as a reference to guide the organization’s investments in software process improvement, it is certainly a good decision to minimize the risks and to maximize the benefits

15. What is the relationship of the CMM© and ISO/IEC 15504 (previously known as SPICE)?
A working group of ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) was established to produce a standard for a model of software development and maintenance practices and an assessment method. This group had the goal to produce standards to obtain international acceptance for these two components. This was the project SPICE ("Software Process Improvement and Capability dEtermination"). The project was transferred after to a regular working group of ISO-IEC to continue the work.
This noble and ambitious objective evolved to produce not A model and A method, but a SET of requirements to be satisfied by models and methods in order to be in conformance to the ISO-IEC standard. This change of course from the initial objective (one single model and one single method), probably unavoidable, has the advantage of making easier to reach international consensus; also it stimulates the development of solutions better adapted to specific needs, while sharing a set of common rules. The SEI was an important participant of the SPICE project, most likely to influence the requirements of the standard to ensure that its model (CMM) and its method (CBA IPI), would easily conform to the future ISO standard.

16. Are there recognized courses on the CMM? Why is the "official" status of the SEI's "Intro to CMM" course important?
Nothing prevents people to offer courses on the CMM© because this model is in the public domain. The SEI has developed a 3-days course offered directly or through a network of authorized partners (e.g. Alcyonix). Obviously the SEI officially recognizes the value of its own course, provided by the SEI itself or by its authorized partners. The candidates for official accreditation as lead assessors are requested to have completed THIS COURSE. In the other hand, for the assessment team members, the SEI only requests that the lead assessors verify the good knowledge of CMM© of each team member. The lead assessor can decide to request that team members take the official course, or alternatively, to accept other courses meeting the equivalence requirements defined by the SEI.

17. How does an organization get SEI certified?
Unfortunately there is no official SEI certification. Unlike ISO, the SEI does not support the formal certification of organizations. Organizations can, however, receive formal evaluations of their organizational software maturity through CMMsm-based appraisals (CBA-IPI) or for specific project efforts via Software Capability Evaluationssm (SCEsms).

18. What are the recommendations for organizations preparing for an appraisal?
It is strongly recommended that organizations wishing to embrace the CMM, as an improvement guide, first understand the model. Typically this involves some sort of formal CMM® education.
A full-fledged SEI licensed Intro to CMM® course can be arranged for.
In concert with CMM® education, it is recommended that organizations be aware of the human and organizational factors associated with the introduction of complex change. CMM consultants are well equipped to help the organizations develop software process improvement implementation plans, or alternatively work with them on existing organizational improvement efforts.
And finally, using an appropriately scaled "Initial" assessment technique is recommended when:
· the organization begins its SPI effort and/or
· prior to conducting a full fledged CBA-IPI
This recommendation is emphasized, in large part, because a formal CBA-IPI is a lengthy and expensive assessment method, albeit thorough; one that should not be taken lightly.)
The assessment method chosen by an organization must be the least intrusive, most thorough, and cost-effective means for identifying an organization's major Software Process Improvement accomplishments and/or obstacles.

19. What is a CBA IPI?
The CBA IPI is a recent appraisal method developed by the SEI to replace the original "Software Process Assessments" (SPAs). It can be tailored to "audit" organizations for compliance to a specific maturity level of the CMM, or to "assess" organizations to determine key issues that must be addressed for process improvement. Process Inc has appraisers who have been authorized by the SEI to lead CBA IPI's.
The CBA IPI can be tailored significantly: the most important areas to consider tailoring are the purpose of the appraisal (improvement versus CMM compliance), the number of CMM levels to investigate in detail, and the amount of emphasis to place on the CMM (as opposed to non-CMM issues which always arise in an assessment). This tailoring greatly affects both the cost and the conclusions of the appraisal.

20. Is the CBA-IPI assessment a test?
Unfortunately, many organizations view CBA-IPI as tests. When viewed in this light the organization risks loosing significant assessment benefits including:
· Identifying areas that need improvement.
· Building organization support for internal improvement efforts.
· The ability to determine the organization's maturity level.
CBA-IPIs are designed, as the acronym would indicate, to provide assessments for internal process improvement (ergo the acronym IPI). Evaluations, in the SEI world, are designed to be used as maturity benchmarks for specific project efforts or software procurements.
CBA-IPIs are roughly analogous to visits to a tax or financial advisor.

21. When should an organization conduct a formal software process assessment (CBA IPI)?
An organization should consider formal software process assessments when:
· It believes that it has made significant process improvement and is seeking a detailed evaluation of the actual progress.
· Its clients/ customers require demonstrated proof of software process maturity and/or improvement.
· It seeks to identify areas requiring improvement.

22. How much time, effort and money are involved in conducting a CBA-IPI?
This is one of those questions for which it is very difficult to provide a simple answer. The simplest answer is "a lot."
CBA-IPI costs generally breakdown into the following major categories:
Interview time: this may involve anywhere from 30-60 staff members for an average of 1.5 hours each.
Meeting and presentation time: will involve the same 30-60 individuals mentioned above plus an additional number of observers up to and including the entire staff membership.
Assessment team time: involves, on an average, six of the organization’s senior individual contributors or project managers for a two week on-site assessment period (100%+ effort); three days of assessment team training (100% effort); plus an additional three days (100% effort) for CMM® training.
Lead assessor costs: to hire a SEI-authorized lead assessor team of two. In special situations it may be required to hire two lead assessors (e.g. the organization already has several in-house, or the organization is extremely small).
A rule of thumb total scope estimate for a CBA-IPI of an organization of 100-150 software professionals is 1500-2000 total hours (depending on maturity, number of projects, etc.).

23. What is the lead-time required for an assessment?
The average lead time for a "full up" CBA-IPI is three to six months. Generally the following tasks must be completed prior to the actual assessment.
· Into to CMM training for the assessment team (3 days).
· Identification of assessment team members, candidate projects, etc.
· Documentation library cross-referencing including: project, process, and CMM® related documents.
· Assessment team training (3 days).
· Resolution of any funding and staffing issues.
· Schedule coordination.

24. When is a good time to schedule an assessment?
Because of the intrusive nature of a CBA-IPI, the following guidelines are generally useful in planning the assessment.
· Allow ample lead-time to arrange schedules for participation. This includes allowing adequate time to coordinate between the organization and its Lead Assessor's, as well as that required to ensure appropriate staff availability.
· Do not schedule assessments during significant product release efforts.
· Do not schedule assessments when staff, management, or the organization's sponsor are not, or may not be, available.
· Be sure the organization requires a full assessment. Oftentimes an informal checkup provides a more expedient and more cost effective progress benchmark.

25. What happens after an assessment?
Normally once an assessment is completed, the organization will do the following:
· Complete a formal Findings and Recommendations document.
· Identify specific areas for improvement during the next timeframe (normally 12-24 months)
· Complete an Action Plan for process improvement.
· Identify pilot improvement activities.
· Measure improvement pilot progress and assess applicability and appropriateness for widespread use.
· Roll improvements out across the organization.
· Schedule informal process improvement check-ups
· Schedule another formal software process assessment (e.g. CBA –IPI)
NOTE: The SEI recommends 3 to 6 months for an action plan. This is typically not simply a list of actions and dates, but includes names, impact on current schedules, organizational changes, and costs. It is not implied that all action stops in the meantime. However, an action plan should represent true commitment to making the improvements.

Defect Prevention
The purpose of Defect Prevention is to identify the cause of defects and prevent them from recurring.
Defect Prevention involves analyzing defects that were encountered in the past and taking specific actions to prevent the occurrence of those types of defects in the future. The defects may have been identified on other projects as well as in earlier stages or tasks of the current project. Defect prevention activities are also one mechanism for spreading lessons learned between projects.

Technology Change Management
The purpose of Technology Change Management is to identify new technologies (i.e., tools, methods, and processes) and track them into the organization in an orderly manner.
Technology Change Management involves identifying, selecting, and evaluating new technologies, and incorporating effective technologies into the organization. The objective is to improve software quality, increase productivity, and decrease the cycle time for product development.

Process Change Management
The purpose of Process Change Management is to continually improve the software processes used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development.
Process Change Management involves defining process improvement goals and, with senior management sponsorship, proactively and systematically identifying, evaluating, and implementing improvements to the organization's standard software process and the projects' defined software processes on a continuous basis.

Quantitative Process Management
The purpose of Quantitative Process Management is to control the process performance of the software project quantitatively. Software process performance represents the actual results achieved from following a software process.
Quantitative Process Management involves establishing goals for the performance of the project's defined software process, which is described in the Integrated Software Management key process area, taking measurements of the process performance, analyzing these measurements, and making adjustments to maintain process performance within acceptable limits. When the process performance is stabilized within acceptable limits, the project's defined software process, the associated measurements, and the acceptable limits for the measurements are established as a baseline and used to control process performance quantitatively.

Software Quality Management
The purpose of Software Quality Management is to develop a quantitative understanding of the quality of the project's software products and achieve specific quality goals.
Software Quality Management involves defining quality goals for the software products, establishing plans to achieve these goals, and monitoring and adjusting the software plans, software work products, activities, and quality goals to satisfy the needs and desires of the customer and end user for high quality products.

Organization Process Focus
The purpose of Organization Process Focus is to establish the organizational responsibility for software process activities that improve the organization's overall software process capability.
Organization Process Focus involves developing and maintaining an understanding of the organization's and projects' software processes and coordinating the activities to assess, develop, maintain, and improve these processes.

Organization Process Definition
The purpose of Organization Process Definition is to develop and maintain a usable set of software process assets that improve process performance across the projects and provide a basis for cumulative, long-term benefits to the organization.
Organization Process Definition involves developing and maintaining the organization's standard software process, along with related process assets, such as descriptions of software life cycles, process tailoring guidelines and criteria, the organization's software process database, and a library of software process-related documentation.

Training Program
The purpose of the Training Program key process area is to develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently.
Training Program involves first identifying the training needed by the organization, projects, and individuals, then developing or procuring training to address the identified needs

Integrated Software Management
The purpose of Integrated Software Management is to integrate the software engineering and management activities into a coherent, defined software process that is tailored from the organization's standard software process and related process assets, which are described in Organization Process Definition.
Integrated Software Management involves developing the project's defined software process and managing the software project using this defined software process. The project's defined software process is tailored from the organization's standard software process to address the specific characteristics of the project.

Software Product Engineering
The purpose of Software Product Engineering is to consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently.
Software Product Engineering involves performing the engineering tasks to build and maintain the software using the project's defined software process (which is described in the Integrated Software Management key process area) and appropriate methods and tools.

Intergroup coordination
The purpose of Intergroup Coordination is to establish a means for the software engineering group to participate actively with the other engineering groups so the project is better able to satisfy the customer's needs effectively and efficiently.
Intergroup Coordination involves the software engineering group's participation with other project engineering groups to address system-level requirements, objectives, and issues. Representatives of the project's engineering groups participate in establishing the system-level requirements, objectives, and plans by working with the customer and end users, as appropriate. These requirements, objectives, and plans become the basis for all engineering activities.

Peer Reviews
The purpose of Peer Reviews is to remove defects from the software work products early and efficiently. An important corollary effect is to develop a better understanding of the software work products and of defects that might be prevented.
Peer Reviews involve a methodical examination of software work products by the producers' peers to identify defects and areas where changes are needed. The specific products that will undergo a peer review are identified in the project's defined software process and scheduled as part of the software project planning activities, as described in Integrated Software Management.

Requirements Management
The purpose of Requirements Management is to establish a common understanding between the customer and the software project of the customer's requirements that will be addressed by the software project.

Software Project Planning
The purpose of Software Project Planning is to establish reasonable plans for performing the software engineering and for managing the software project.
Software Project Planning involves developing estimates for the work to be performed, establishing the necessary commitments, and defining the plan to perform the work.

Software Project Tracking and Oversight
The purpose of Software Project Tracking and Oversight is to provide adequate visibility into actual progress so that management can take effective actions when the software project's performance deviates significantly from the software plans.
Software Project Tracking and Oversight involves tracking and reviewing the software accomplishments and results against documented estimates, commitments, and plans, and adjusting these plans based on the actual accomplishments and results.

Software Subcontract Management
The purpose of Software Subcontract Management is to select qualified software subcontractors and manage them effectively.

Software Quality Assurance
The purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by the software project and of the products being built.
Software Quality Assurance involves reviewing and auditing the software products and activities to verify that they comply with the applicable procedures and standards and providing the software project and other appropriate managers with the results of these reviews and audits.

Software Configuration Management
The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle.
Software Configuration Management involves identifying the configuration of the software (i.e., selected software work products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software life cycle.

Software engineering group
The software engineering group is the collection of individuals (both managers and technical staff) who have responsibility for software development and maintenance activities (i.e., requirements analysis, design, code, and test) for a project.
Groups performing software-related work, such as the software quality assurance group, the software configuration management group, and the software engineering process group, are not included in the software engineering group. These groups are considered to be one of the "other software-related groups."

Software-related groups
A software-related group is the collection of individuals (both managers and technical staff) representing a software engineering discipline that supports, but is not directly responsible for, software development and/or maintenance.
Examples of software engineering disciplines include software quality assurance and software configuration management.

Software engineering process group
The software engineering process group is the group of specialists who facilitate the definition, maintenance, and improvement of the software process used by the organization. In the key practices, this group is generically referred to as "the group responsible for the organization's software process activities."

System engineering group
The system engineering group is the collection of individuals (both managers and technical staff) who have responsibility for specifying the system requirements; allocating the system requirements to the hardware, software, and other components; specifying the interfaces between the hardware, software, and other components; and monitoring the design and development of these components to ensure conformance with their specifications.

System test group
The system test group is the collection of individuals (both managers and technical staff) who have responsibility for planning and performing the independent system testing of the software to determine whether the software product satisfies its requirements.

Software quality assurance group
The software quality assurance group is the collection of individuals (both managers and technical staff) who plan and implement the project's quality assurance activities to ensure the software process steps and standards are followed.

Software configuration management group
The software configuration management group is the collection of individuals (both managers and technical staff) who have responsibility for planning, coordinating, and implementing the formal configuration management activities for the software project.

Training group
The training group is the collection of individuals (both managers and staff) who are responsible for coordinating and arranging the training activities for an organization. This group typically prepares and conducts most of the training courses and coordinates use of other training vehicles.

Process Categories

Management, Organizational, Engineering
Organization's standard software process
An organization's standard software process is the operational definition of the basic process that guides the establishment of a common software process across the software projects in the organization. It describes the fundamental software process elements that each software project is expected to incorporate into its defined software process. It also describes the relationships (e.g., ordering and interfaces) between these software process elements. It guides the establishment of a common software process across the software development and maintenance projects in the organization.

Software process architecture
The software process architecture is a high-level (i.e., summary) description of the organization's standard software process. It describes the ordering, interfaces, interdependencies, and other relationships between the software process elements of the organization's standard software process. It also describes the interfaces, dependencies, and other relationships to other external processes (e.g., system engineering, hardware engineering, and contract management).

Software process element
A software process element is a constituent element of a software process description. Each process element covers a well-defined, bounded, closely related set of tasks (e.g., software estimating element, software design element, coding element, and peer review element). The descriptions of the process elements may be templates to be filled in, fragments to be completed, abstractions to be refined, or complete descriptions to be modified or used unmodified.

Software Life cycle
A software life cycle is the period of time that begins when a software product is conceived and ends when the software is no longer available for use. The software life cycle typically includes a concept stage, requirements stage, design stage, implementation stage, test stage, installation and checkout stage, operation and maintenance stage, and sometimes, retirement stage.
Because an organization may be producing software for a variety of contractual and/or commercial customers and users, one software life cycle may not be appropriate for all situations. Therefore, the organization may identify more than one software life cycle for use by the projects. These software life cycles are typically obtained from software engineering literature and may be modified for the organization. These software life cycles are available to be used, in combination with the organization's standard software process, in developing a project's defined software process.

Project's defined software process
The description of the project's defined software process is the operational definition of the software process used by the project. The project's defined software process is a well-characterized and understood software process, described in terms of software standards, procedures, tools, and methods. It is developed by tailoring the organization's standard software process to fit the specific characteristics of the project.
This tailoring includes selecting a software life cycle from those approved by the organization and modifying the organization's standard software process to fit the specific characteristics of the project.
The project's defined software process provides the basis for planning, performing, and improving the activities of the managers and technical staff performing the project's tasks and activities. It is possible for a project to have more than one defined software process (e.g., for the operational software and for the test support software) or to have one defined software process for two or more similar projects.

Stage
A stage is a partition of the software effort that is of a manageable size and that represents a meaningful and measurable set of related tasks which are performed by the project. A stage is usually considered a subdivision of a software life cycle and is often ended with a formal review prior to the onset of the following stage.

Task
The work to be performed is broken down into tasks. A task is a well-defined unit of work in the software process that provides management with a visible checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and completion criteria (postconditions).
Within the context of process definition, a task is a well-defined component of a defined process. All tasks can be considered activities, but not all activities are well enough defined to be considered tasks (although an activity may include a task). Because of this, use of "task" in the Level 2 key practices is avoided and the less rigorous term "activity" is used.

Activity
An activity is any step taken or function performed, both mental and physical, toward achieving some objective. Activities include all the work the managers and technical staff do to perform the tasks of the project and organization.

Software work product
The results of activities and tasks primarily consist of software work products. A software work product is any artifact created as part of defining, maintaining, or using a software process, including process descriptions, plans, procedures, computer programs, and associated documentation, which may or may not be intended for delivery to a customer or end user. Work products become an input to the next step in the process or provide archival information on the software project for use in future projects.
Examples of software work products include plans, estimates, data on actual effort, corrective action documentation, and requirements documents. The subset of software work products that are deliverable to the customer or end user are referred to as software products.

Software product
The software products are the complete set, or any of the individual items of the set, of computer programs, procedures, and associated documentation and data designated for delivery to a customer or end user.
All software products are also software work products. A software work product that will not be delivered to a customer or end user is not, however, a software product.

Level 1 - The Initial Level
The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort.

Level 2 - The Repeatable Level
Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

Level 3 - The Defined Level
The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.

Level 4 - The Managed Level
Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

Level 5 - The Optimizing Level
Optimizing - Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

Components

Maturity level
A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. The five maturity levels provide the top-level structure of the CMM.


Process Capability
Software process capability describes the range of expected results that can be achieved by following a software process. The software process capability of an organization provides one means of predicting the most likely outcomes to be expected from the next software project the organization undertakes.

Key Process Area
Each maturity level is composed of key process areas. Each key process area identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for establishing process capability at that maturity level. The key process areas have been defined to reside at a single maturity level. For example, one of the key process areas for Level 2 is Software Project Planning.
Each key process area contains:
a brief description of the key process area,
the goals for the key process area, and
the key practices.

Goals
The goals summarize the key practices of a key process area and can be used to determine whether an organization or project has effectively implemented the key process area. The goals signify the scope, boundaries, and intent of each key process area.
An example of a goal from the Software Project Planning key process area is "Software estimates are documented for use in planning and tracking the software project."

Common features
The key practices are divided among five Common Features sections: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation. The common features are attributes that indicate whether the implementation and institutionalization of a key process area is effective, repeatable, and lasting.
The Activities Performed common feature describes implementation activities. The other four common features describe the institutionalization factors, which make a process part of the organizational culture.

Commitment to perform
Commitment to Perform describes the actions the organization must take to ensure that the process is established and will endure. Commitment to Perform typically involves establishing organizational policies and senior management sponsorship.

Ability to Perform
Ability to Perform describes the preconditions that must exist in the project or organization to implement the software process competently. Ability to Perform typically involves resources, organizational structures, and training.

Activities Performed
Activities Performed describes the roles and procedures necessary to implement a key process area. Activities Performed typically involve establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary.

Measurement and Analysis
Measurement and Analysis describes the need to measure the process and analyze the measurements. Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effectiveness of the Activities Performed.

Verifying implementation
Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established. Verification typically encompasses reviews and audits by management and software quality assurance.

Key practices
Each key process area is described in terms of key practices that, when implemented, help to satisfy the goals of that key process area. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area.
For example, one of the practices from the Software Project Planning key process area is "The project's software development plan is developed according to a documented procedure."
The key practices, also known as top-level key practices, state the fundamental policies, procedures, and activities for the key process area. They are identified in bold and are numbered within each common feature. For example, the first key practice in the common feature of Activities Performed is identified as Activity 1.

Subpractices
Subpractices, also known as subordinate key practices, are listed beneath the top-level key practices and describe what one would expect to find implemented for the top-level key practice. The subpractices can be used to help determine whether or not the key practices are implemented satisfactorily.

Supplementary Information
Supplementary information is boxed following the key practices. The supplementary information includes examples, elaborations, and references to other key process areas.

Glossary

Acceptance criteria - The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity.

Acceptance testing - Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.

Action item - (1) A unit in a list that has been assigned to an individual or group for disposition. (2) An action proposal that has been accepted.

Action proposal - A documented suggestion for change to a process or process-related item that will prevent the future occurrence of defects identified as a result of defect prevention activities.

Application domain - A bounded set of related systems (i.e., systems that address a particular type of problem). Development and maintenance in an application domain usually requires special skills and/or resources. Examples include payroll and personnel systems, command and control systems, compilers, and expert systems.

Assessment - An appraisal by a trained team of software professionals to determine the state of an organization's current software process, to determine the high-priority software process-related issues facing an organization, and to obtain the organizational support for software process improvement.

Audit - An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria.

Baseline - A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

Baseline Configuration Management - The establishment of baselines that are formally reviewed and agreed on and serve as the basis for further development. Some software work products, e.g., the software design and the code, should have baselines established at predetermined points, and a rigorous change control process should be applied these items. These baselines provide control and stability when interacting with the customer. (See also baseline management.)

Baseline Management - In configuration management, the application of technical and administrative direction to designate the documents and changes to those documents that formally identify and establish baselines at specific times during the life cycle of a configuration item.

Benchmark - A standard against which measurements or comparisons can be made.

Bidder - An individual, partnership, corporation, or association that has submitted a proposal and is a candidate to be awarded a contract to design, develop, and/or manufacture one or more products.

Capability Maturity Model - A description of the stages through which software organizations evolve as they define, implement, measure, control, and improve their software processes. This model provides a guide for selecting process improvement strategies by facilitating the determination of current process capabilities and the identification of the issues most critical to software quality and process improvement.

Causal analysis - The analysis of defects to determine their underlying root cause.

Causal analysis meeting - A meeting, conducted after completing a specific task, to analyze defects uncovered during the performance of that task.

CMM- Acronym for capability maturity model.

Commitment - A pact that is freely assumed, visible, and expected to be kept by all parties.
Common cause (of a defect) - A cause of a defect that is inherently part of a process or system. Common causes affect every outcome of the process and everyone working in the process. (See special cause for contrast.)

Configuration - In configuration management, the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product.
Configuration control - An element of configuration management, consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification.

Configuration identification - An element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation.

Configuration item - An aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process.

Configuration Management - A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.
Configuration management library system - The tools and procedures to access the contents of the software baseline library.

Configuration unit - The lowest level entity of a configuration item or component that can be placed into, and retrieved from, a configuration management library system.

Consistency - The degree of uniformity, standardization, and freedom from contradiction among the documents or parts of system or component.

Contingency factor - An adjustment (increase) of a size, cost, or schedule plan to account for likely underestimates of these parameters due to incomplete specification, inexperience in estimating the application domain, etc.

Contract terms and conditions - The stated legal, financial, and administrative aspects of a contract.

Critical Computer Resource - The parameters of the computing resources deemed to be a source of risk to the project because the potential need for those resources may exceed the amount that is available. Examples include target computer memory and host computer disk space.

Critical path - A series of dependent tasks for a project that must be completed as planned to keep the entire project on schedule.

Customer - The individual or organization that is responsible for accepting the product and authorizing payment to the developing organization.

Defect - A flaw in a system or system component that causes the system or component to fail to perform its required function. A defect, if encountered during execution, may cause a failure of the system.

Defect Density - The number of defects identified in a product divided by the size of the product component (expressed in standard measurement terms for that product).

Defect Prevention - The activities involved in identifying defects or potential defects and preventing them from being introduced into a product.

Defect root cause - The underlying reason (e.g., process deficiency) that allowed a defect to be introduced.

Dependency item - A product, action, piece of information, etc., that must be provided by one individual or group to a second individual or group so that the second individual or group can perform a planned task.

Developmental configuration management - The application of technical and administrative direction to designate and control software and associated technical documentation that define the evolving configuration of a software work product during development. Developmental configuration management is under the direct control of the developer. Items under developmental configuration management are not baselines, although they may be baselined and placed under baseline configuration management at some point in their development.

Deviation - A noticeable or marked departure from the appropriate norm, plan, standard, procedure, or variable being reviewed.

Effective process - A process that can be characterized as practiced, documented, enforced, trained, measured, and able to improve.

End user - The individual or group who will use the system for its intended operational use when it is deployed in its environment.

End user representatives - A selected sample of end users who represent the total population of end users.

Engineering group - A collection of individuals (both managers and technical staff) representing an engineering discipline. Examples of engineering disciplines include systems engineering, hardware engineering, system test, software engineering, software configuration management, and software quality assurance.

Event-driven review/activity - A review or activity that is performed based on the occurrence of an event within the project (e.g., a formal review or the completion of a life cycle stage).

Findings - The conclusions of an assessment, evaluation, audit, or review that identify the most important issues, problems, or opportunities within the area of investigation.

First-line software manager - A manager who has direct management responsibility (including providing technical direction and administering the personnel and salary functions) for the staffing and activities of a single organizational unit (e.g., a department or project team) of software engineers and other related staff.

Formal review - A formal meeting at which a product is presented to the end user, customer, or other interested parties for comment and approval. It can also be a review of the management and technical activities and of the progress of the project.

Function - A set of related actions, undertaken by individuals or tools that are specifically assigned or fitted for their roles, to accomplish a set purpose or end.

Group - The collection of departments, managers, and individuals who have responsibility for a set of tasks or activities. A group could vary from a single individual assigned part time, to several part-time individuals assigned from different departments, to several individuals dedicated full time.

Host computer - A computer used to develop software.

Institutionalization - The building of infrastructure and corporate culture that support methods, practices, and procedures so that they are the ongoing way of doing business, even after those who originally defined them are gone.

Integrated software management - The unification and integration of the software engineering and management activities into a coherent defined software process based on the organization's standard software process and related process assets.

Maintenance - The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment.
Managed and controlled - The process of identifying and defining software work products that are not part of a baseline and, therefore, are not placed under configuration management but that must be controlled for the project to proceed in a disciplined manner. "Managed and controlled" implies that the version of the work product in use at a given time (past or present) is known (i.e., version control), and changes are incorporated in a controlled manner (i.e., change control).

Manager - A role that encompasses providing technical and administrative direction and control to individuals performing tasks or activities within the manager's area of responsibility. The traditional functions of a manager include planning, resourcing, organizing, directing, and controlling work within an area of responsibility.

Maturity questionnaire - A set of questions about the software process that sample the key practices in each key process area of the CMM. The maturity questionnaire is used as a springboard to appraise the capability of an organization or project to execute a software process reliably.

Measure - A unit of measurement (such as source lines of code or document pages of design).

Measurement - The dimension, capacity, quantity, or amount of something (e.g., 300 source lines of code or 7 document pages of design).

Method - A reasonably complete set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result.

Methodology - A collection of methods, procedures, and standards that defines an integrated synthesis of engineering approaches to the development of a product.

Milestone - A scheduled event for which some individual is accountable and that is used to measure progress.

Montechnical requirements - Agreements, conditions and/or contractual terms that affect and determine the management activities of a software project.

Operational software - The software that is intended to be used and operated in a system when it is delivered to its customer and deployed in its intended environment.

Organization - A unit within a company or other entity (e.g., government agency or branch of service) within which many projects are managed as a whole. All projects within an organization share a common top-level manager and common policies.

Organization's measurement program - The set of related elements for addressing an organization's measurement needs. It includes the definition of organization-wide measurements, methods and practices for collecting organizational measurement data, methods and practices for analyzing organizational measurement data, and measurement goals for the organization.

Organization's software process assets - A collection of entities, maintained by an organization, for use by projects in developing, tailoring, maintaining, and implementing their software processes. These software process assets typically include:
the organization's standard software process,
descriptions of the software life cycles approved for use,
the guidelines and criteria for tailoring the organization's standard software process,
the organization's software process database, and
a library of software process-related documentation.
Any entity that the organization considers useful in performing the activities of process definition and maintenance could be included as a process asset.

Organization's software process database - A database established to collect and make available data on the software processes and resulting software work products, particularly as they relate to the organization's standard software process. The database contains or references both the actual measurement data and the related information needed to understand the measurement data and assess it for reasonableness and applicability. Examples of process and work product data include estimates of software size, effort, and cost; actual data on software size, effort, and cost; productivity data; peer review coverage and efficiency; and number and severity of defects found in the software code.

Orientation - An overview or introduction to a topic for those overseeing or interfacing with the individuals responsible for performing in the topic area.

Pareto analysis - The analysis of defects by ranking causes from most significant to least significant. Pareto analysis is based on the principle, named after the 19th-century economist Vilfredo Pareto, that most effects come from relatively few causes, i.e., 80% of the effects come from 20% of the possible causes.

Peer review - A review of a software work product, following defined procedures, by peers of the producers of the product for the purpose of identifying defects and improvements.
Peer review leader - An individual specifically trained and qualified to plan, organize, and lead a peer review.

Periodic review/activity - A review or activity that occurs at specified regular time intervals.
Policy - A guiding principle, typically established by senior management, which is adopted by an organization or project to influence and determine decisions.

Prime contractor - An individual, partnership, corporation, or association that administers a subcontract to design, develop, and/or manufacture one or more products.

Procedure - A written description of a course of action to be taken to perform a given task.

Process - A sequence of steps performed for a given purpose; for example, the software development process.

Process capability - The range of expected results that can be achieved by following a process.

Process capability baseline - A documented characterization of the range of expected results that would normally be achieved by following a specific process under typical circumstances. A process capability baseline is typically established at an organizational level.
Process description-The operational definition of the major components of a process. Documentation that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a process. It may also include the procedures for determining whether these provisions have been satisfied. Process descriptions may be found at the task, project, or organizational level.

Process development-The act of defining and describing a process. It may include planning, architecture, design, implementation, and validation.

Process measurement - The set of definitions, methods, and activities used to take measurements of a process and its resulting products for the purpose of characterizing and understanding the process.

Process performance- A measure of the actual results achieved by following a process.

Process performance baseline - A documented characterization of the actual results achieved by following a process, which is used as a benchmark for comparing actual process performance against expected process performance. A process performance baseline is typically established at the project level, although the initial process performance baseline will usually be derived from the process capability baseline.

Process tailoring - The activity of creating a process description by elaborating, adapting, and/or completing the details of process elements or other incomplete specifications of a process. Specific business needs for a project will usually be addressed during process tailoring.
Profile - A comparison, usually in graphical form, of plans or projections versus actuals, typically over time.

Project - An undertaking requiring concerted effort, which is focused on developing and/or maintaining a specific product. The product may include hardware, software, and other components. Typically a project has its own funding, cost accounting, and delivery schedule.

Quality - (1) The degree to which a system, component, or process meets specified requirements. (2) The degree to which a system, component, or process meets customer or user needs or expectations.

Quantitative control - Any quantitative or statistically-based technique appropriate to analyze a software process, identify special causes of variations in the performance of the software process, and bring the performance of the software process within well-defined limits.

Required training - Training designated by an organization to be required to perform a specific role.

Risk - Possibility of suffering loss.

Risk management - An approach to problem analysis which weighs risk in a situation by using risk probabilities to give a more accurate understanding of the risks involved. Risk management includes risk identification, analysis, prioritization, and control.

Risk management plan - The collection of plans that describe the risk management activities to be performed on a project.

Role - A unit of defined responsibilities that may be assumed by one or more individuals.

SEI – Acronym for Carnegie Mellon University’s Software Engineering Institute which came up with the CMM for Software model.

SCE - Acronym for software capability evaluation.

SCM - Acronym for software configuration management.

Senior manager - A management role at a high enough level in an organization that the primary focus is the long-term vitality of the organization, rather than short-term project and contractual concerns and pressures. In general, a senior manager for engineering would have responsibility for multiple projects.

Software architecture - The organizational structure of the software or module.

software baseline audit - An examination of the structure, contents, and facilities of the software baseline library to verify that baselines conform to the documentation that describes the baselines.

Software baseline library - The contents of a repository for storing configuration items and the associated records.

Software build - An operational version of a software system or component that incorporates a specified subset of the capabilities the final software system or component will provide.
Software capability evaluation - An appraisal by a trained team of professionals to identify contractors who are qualified to perform the software work or to monitor the state of the software process used on an existing software effort.

Software configuration control board - A group responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes.

Software development plan - The collection of plans that describe the activities to be performed for the software project. It governs the management of the activities performed by the software engineering group for a software project.

Software integration - A process of putting together selected software components to provide the set or specified subset of the capabilities the final software system will provide.

Software life cycle - The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and, sometimes, retirement phase.

Software plans - The collection of plans, both formal and informal, used to express how software development and/or maintenance activities will be performed. Examples of plans that could be included: software development plan, software quality assurance plan, software configuration management plan, software test plan, risk management plan, and process improvement plan.


Software process - A set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products (e.g., project plans, design documents, code, test cases, and user manuals).

Software process assessment - An appraisal by a trained team of software professionals to determine the state of an organization's current software process, to determine the high-priority software process-related issues facing an organization, and to obtain the organizational support for software process improvement.

Software process description - The operational definition of a major software process component identified in the project's defined software process or the organization's standard software process. It documents, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a software process.

Software process element - A constituent element of a software process description. Each process element covers a well-defined, bounded, closely related set of tasks (e.g., software estimating element, software design element, coding element, and peer review element). The descriptions of the process elements may be templates to be filled in, fragments to be completed, abstractions to be refined, or complete descriptions to be modified or used unmodified.

Software process improvement plan - A plan, derived from the recommendations of a software process assessment, that identifies the specific actions that will be taken to improve the software process and outlines the plans for implementing those actions. Sometimes referred to as an action plan.

Software process improvement proposal - A documented suggestion for change to a process or process-related item that will improve software process capability and performance.
Software process maturity - The extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. Maturity implies a potential for growth in capability and indicates both the richness of an organization's software process and the consistency with which it is applied in projects throughout the organization.

Software product - The complete set, or any of the individual items of the set, of computer programs, procedures, and associated documentation and data designated for delivery to a customer or end user.

Software project - An undertaking requiring concerted effort, which is focused on analyzing, specifying, designing, developing, testing, and/or maintaining the software components and associated documentation of a system. A software project may be part of a project building a hardware/software system.

Software quality assurance - (1) A planned and systematic pattern of all actions necessary to provide adequate confidence that a software work product conforms to established technical requirements. (2) A set of activities designed to evaluate the process by which software work products are developed and/or maintained.

Software quality goal - Quantitative quality objectives defined for a software work product.

Software quality management - The process of defining quality goals for a software product, establishing plans to achieve these goals, and monitoring and adjusting the software plans, software work products, activities, and quality goals to satisfy the needs and desires of the customer and end users.

Software-related group - A collection of individuals (both managers and technical staff) representing a software engineering discipline that supports, but is not directly responsible for, software development and/or maintenance. Examples of software engineering disciplines include software quality assurance and software configuration management.

Software requirement- A condition or capability that must be met by software needed by a user to solve a problem or achieve an objective.

Software work product - Any artifact created as part of defining, maintaining, or using a software process, including process descriptions, plans, procedures, computer programs, and associated documentation, which may or may not be intended for delivery to a customer or end user.
SPA- Acronym for software process assessment.

Special cause (of a defect) - A cause of a defect that is specific to some transient circumstance and not an inherent part of a process. Special causes provide random variation (noise) in process performance.

SQA - Acronym for software quality assurance.

Standard - Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to software development.

Statement of work - A description of all the work required to complete a project, which is provided by the customer.

Subcontractor - An individual, partnership, corporation, or association that contracts with an organization (i.e., the prime contractor) to design, develop, and/or manufacture one or more products.

System - A collection of components organized to accomplish a specific function or set of functions.

System requirement - A condition or capability that must be met or possessed by a system or system component to satisfy a condition or capability needed by a user to solve a problem.
System requirements allocated to software - The subset of the system requirements that are to be implemented in the software components of the system. The allocated requirements are a primary input to the software development plan. Software requirements analysis elaborates and refines the allocated requirements and results in software requirements which are documented.

Tailor - To modify a process, standard, or procedure to better match process or product requirements

Task kick-off meeting - A meeting held at the beginning of a task of a project for the purpose of preparing the individuals involved to perform the activities of that task effectively.

Task leader - The leader of a technical team for a specific task, who has technical responsibility and provides technical direction to the staff working on the task.

Team – A collection of people, often drawn from diverse but related groups, assigned to perform a well-defined function for an organization or a project. Team members may be part-time participants of the team and have other primary responsibilities.

Testability - (1) The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met. (2) The degree to which a requirement is stated in terms that permit establishment of test criteria and performance of tests to determine whether those criteria have been met.

Technical requirements - Those requirements that describe what the software must do and its operational constraints. Examples of technical requirements include functional, performance, interface, and quality requirements.

Technology - The application of science and/or engineering in accomplishing some particular result.

Traceability - The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.

Train - To make proficient with specialized instruction and practice.

Training group - The collection of individuals (both managers and staff) who are responsible for coordinating and arranging the training activities for an organization. This group typically prepares and conducts most of the training courses and coordinates use of other training vehicles.

Training program - The set of related elements that focus on addressing an organization's training needs. It includes an organization's training plan, training materials, development of training, conduct of training, training facilities, evaluation of training, and maintenance of training records.

Training waiver - A written approval exempting an individual from training that has been designated as required for a specific role. The exemption is granted because it has been objectively determined that the individual already possesses the needed skills to perform the role.

Unit - (1) A separately testable element specified in the design of a computer software component. (2) A logically separable part of a computer program. (3) A software component that is not subdivided into other components.

Validation- The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements.

Verification- The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.

Well-defined process - A process that includes readiness criteria, inputs, standards and procedures for performing the work, verification mechanisms (such as peer reviews ), outputs, and completion criteria.

Common features are the subdivision categories of the CMM key process areas. The common features are attributes that indicate whether the implementation and institutionalization of a key process area is effective, repeatable, and lasting.

The CMM common features are the following:

Commitment to perform -The actions the organization must take to ensure that the process is established and will endure. Commitment to Perform typically involves establishing organizational policies and senior management sponsorship
Ability to perform - The preconditions that must exist in the project or organization to implement the software process competently. Ability to Perform typically involves resources, organizational structures, and training.
Activities performed - A description of the roles and procedures necessary to implement a key process area. Activities Performed typically involve establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary.
Measurement and analysis - A description of the need to measure the process and analyze the measurements. Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effectiveness of the Activities Performed.
Verifying implementation - The steps to ensure that the activities are performed in compliance with the process that has been established. Verification typically encompasses reviews and audits by management and software quality assurance.

The 18 Key Process Areas of the CMM

Level 2-Repeatable Requirements Management
Software Project Planning
Software Project Tracking and Oversight
Software Subcontract Management
Software Quality Assurance
Software Configuration Management

Level 3-Defined Organization Process focus
Organization Process Definition
Training program
Integrated Software Management
Software Product Engineering
Intergroup coordination
Peer Reviews

Level 4-Managed Quantitative Process Management
Software Quality Management

Level 5-Optimizing Defect Prevention
Technology Change Management
Process Change Management

The five maturity levels in the SEI's Capability Maturity Model are:

Initial- The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort.

Repeatable - Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

Defined-The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.

Managed - Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

Optimizing- Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

The CMM is composed of five maturity levels. With the exception of Level 1, each maturity level is composed of several key process areas. Each key process area is organized into five sections called common features. The common features specify the key practices that, when collectively addressed, accomplish the goals of the key process area. The components of the CMM include:

Maturity levels
A maturity level is a well-defined evolutionary plateau toward achieving a mature software process.The five maturity levels provide the top-level structure of the CMM.
Process capability
Software process capability describes the range of expected results that can be achieved by following a software process. The software process capability of an organization provides one means of predicting the most likely outcomes to be expected from the next software project the organization undertakes.

Key process areas
Each maturity level is composed of key process areas. Each key process area identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for establishing process capability at that maturity level. The key process areas have been defined to reside at a single maturity level. For example, one of the key process areas for Level 2 is Software Project Planning.

Goals
The goals summarize the key practices of a key process area and can be used to determine whether an organization or project has effectively implemented the key process area. The goals signify the scope, boundaries, and intent of each key process area.

An example of a goal from the Software Project Planning key process area is "Software estimates are documented for use in planning and tracking the software project."

Common features
The key practices are divided among five Common Features sections: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation. The common features are attributes that indicate whether the implementation and institutionalization of a key process area is effective, repeatable, and lasting.

The Activities Performed common feature describes implementation activities. The other four common features describe the institutionalization factors, which make a process part of the organizational culture.

Key practices
Each key process area is described in terms of key practices that, when implemented, help to satisfy the goals of that key process area. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area.

For example, one of the practices from the Software Project Planning key process area is "The project's software development plan is developed according to a documented procedure."

1986 - Work began on the maturity framework

1987 - Software Engineering Institute (Carnegie Mellon University) releases


A brief description of the software maturity framework


Software process assessment method


Software capability evaluation method


A maturity questionnaire

1991 - SEI releases v1.0 of the CMM

1992 - SEI releases v1.1 of the CMM

1997- SEI releases next version of the CMM


In November 1986, the Software Engineering Institute (SEI) with assistance from the Mitre Corporation began developing a process maturity framework that would assist organizations in improving their software process. This effort was initiated in response to a request to provide the federal government with a method for assessing the capability of their software contractors. In September 1987, the SEI released a brief description of the process maturity framework and a maturity questionnaire (CMU/SEI-87-TR-23). The SEI intended the maturity questionnaire to provide a simple tool for identifying areas where an organization's software process needed improvement. Unfortunately, the questionnaire was too often regarded as "the model" rather than as a vehicle for exploring process maturity issues.

After four years of experience with the software process maturity framework and the preliminary version of the maturity questionnaire, the SEI has evolved the software process maturity framework into a fully defined model. This model will be used in a systematic, principled way to derive a maturity questionnaire. By fully elaborating the maturity framework, a model has emerged that provides organizations with more effective guidance for establishing process improvement programs than was offered by the maturity questionnaire. Using knowledge acquired from software process assessments and extensive feedback from both industry and government, an improved version of the process maturity framework has been produced called the Capability Maturity Model for Software (CMM).

The Capability Maturity Model for Software (CMM) is a framework that describes the key elements of an effective software process. The CMM describes an evolutionary improvement path from an ad hoc, immature process to a mature, disciplined process. This framework has been developed by SEI (Software Engineering Institute). The SEI is a federally funded research and development center contract was competitively awarded to Carnegie Mellon University in December 1984.The SEI staff has extensive technical industry, and academia.The SEI mission is to provide leadership in advancing the state of the practice of software engineering to improve the quality of systems that depend on software. The SEI accomplishes this missionby promoting the evolution of software engineering from an ad hoc, labor-intensive activity to a discipline that is well managedand supported by technology.The CMM covers practices forplanning, engineering, and managing software development and maintenance. When followed, these key practices improvethe 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 .