A Practical Guide to Enterprise Architecture

SEI/CMM

The Capability Maturity Model (CMM) is a model for evaluating the maturity of a process within an organization. Originally conceived in 1987 through the inspiration of Watts Humphrey from IBM, CMM has evolved through the Software Engineering Institute (SEI) at Carnegie Mellon University. This model for evaluating the maturity of processes in organizations was a response to the dramatic percentage of software development projects that spiral beyond control-of-quality assurance, initial budgets, and schedules. The capability of a model defines the domain of possible results that are possible given a specified set of processes. The maturity of a process is described as the extent to which a specific process is defined, managed, measured, controlled, and made effective. In a defined mature and capable model, the processes therein are well understood throughout the organization and are reflective of richness and consistency. CMM does not directly compare to the other methodologies in this chapter. It is rather the definition of a framework for any repeatable, measurable, and consistent business process.

Over the years, CMM has evolved into a series of variations that deal with specific facets of evaluating the maturity of processes. The SEI at Carnegie Mellon has been coordinating the release and management of the following CMM variations.

• Software Capability Maturity Model (SW-CMM): The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.

• People Capability Maturity Model (P-CMM): This is a framework that helps organizations successfully address critical people issues. Based on the best current practices in fields such as human resources, knowledge management, and organizational development, P-CMM provides the guidelines for organizations to improve their processes for managing and developing their workforces.

• Software Acquisition Capability Maturity Model (SA-CMM): This model is designed to benchmark and improve the software acquisition process for an organization.

• Integrated Product Development Capability Maturity Model (IPD-CMM): IPD is a systematic approach to product development that defines the necessary disciplines throughout the product life cycle to better satisfy customer needs.

• Systems Engineering Capability Maturity Model (SE-CMM): This model describes the essential elements of an organization's systems engineering process. Systems engineering is an interdisciplinary approach to managing the processes that involve people, technology, costing, and scheduling.

A recent development by the SEI is an attempt to create an Integrated Capability Maturity Model (CMMi) that encompasses software engineering (SW-CMM), systems engineering (SE-CMM), and integrated product and process development (IPD-CMM). The purpose of this integrated model is to create a consolidated process improvement framework suitable for software intensive systems. CMMi replaced SW-CMM in December 2003.

Because of the breadth and depth of the varieties of CMM framework definitions, this methodology overview will focus on the process definition improvements as described in SW-CMM. A CMM-certified organization benefits through improved understanding of the processes associated with software development, standardized and documented procedures, and defined metrics for measuring the performance of a process execution. CMM-SW provides direct impact to the performance of certified processes, thus reducing the delivery cycle of projects and reducing ongoing maintenance costs because of more effective quality-assurance measures.

Table 5-1 lists the five levels defined by the SW-CMM framework. Each level describes the next progressive step in a software development process's maturity.

At each level of maturity in CMM, a progression of processes must be defined. Past the first level of CMM, the processes characteristic for each level is described as a Key Process Area (KPA). A KPA describes the key processes that must exist in order for an organization to be promoted to the next level of CMM maturity. The following sections describe the criteria for each level of CMM.

Initial

Organizations identified at the initial level generally do not provide a stable environment for defining, developing, and deploying software. The nature of these types of organizations is very reactive to the conditions of a project delivery. The success of a project is usually dependent on an exceptional manager or a seasoned and effective software development team. Schedules, budgets, functionality, and product quality are unpredictable at this level of maturity, and performance depends on the capabilities of individuals and varies with their innate skills and knowledge. This level of maturity is common among organizations that have no predefined processes for handling the various phases of a software development life cycle.

Repeatable

An organization described at the repeatable level will have policies for managing a software project and documented precedence that can be leveraged for future software development projects. At this level, organizations will have basic software management controls installed. This includes defined procedures for software development activities, such as project estimation, project tracking, change management, quality assurance, and so on. The definition of the procedures is the result of previous successful projects, and the information available is complete enough to facilitate repeatable results in these process areas. Also, at this level of maturity, the organization has defined standards for coding practices, architecture considerations, and specifications information. The organization must also have the process mechanisms to enforce the defined standards and procedures. Finally, for a level-2 CMM certification, an organization must have a process for establishing strong customer supplier relationships with all its vendors.

In general, a level-2 repeatable-level organization for software development will have the following characteristics. There is a centrally available repository for process definitions and project documentation that is leverageable for new and ongoing software development projects. Next, some type of standards-enforcing group must be identified that has exposure to all projects. This group (usually referred to as a program office) is responsible for tracking the delivery of a project and verifying the compliance of projects to the existing standards. In addition, usually a vendor management group is created in the organization to centrally establish and manage customer supplier relationships with vendors, subcontractors, and service providers.

Defined

At the defined level, an organization has thoroughly documented the standard processes for developing and maintaining software. These documented processes contain information regarding software development and project management practices, and they are readily integrated across the organization. The procedures for software development are permeated throughout the group and are ubiquitously understood as the standard process for software development. Next, a Software Engineering Process Group (SEPG) is identified in the organization and is responsible for maintaining the standards and documentation material for the software development process. This group is also responsible for keeping abreast of industry standards and incorporating recent developments effectively in the organization's processes. Finally, an organization-wide training program must be instated to ensure that both staff and managers have the skills and knowledge to participate effectively in the defined software project processes. Overall, the level-3 organization owns stable and repeatable standards and procedures for both software engineering and project management. Within these standards and procedures, project cost, schedule, functionality, and software quality are controllable. The capability of the organization is consistent across all members and roles in the organization.

The key differentiating factor for the level-3 CMM organization is that the SDLC is defined in detail for the full life cycle of a project delivery. Whereas in level 2, the processes for successful projects were documented, in level-3 organizations all processes must be well defined. Well-defined processes include all the following information:

• Defined Readiness Criteria: The process requires these conditions to be met before a process can begin.

• Defined Inputs: These are the inputs required for a process to start. For example, the process of designing a software solution requires that the requirements document be used as a primary input for this phase.

• Standards and Procedures for Executing the Process: This is the actual definition of the actual work that must be completed to satisfy the process. Design process procedures can include the creation of design documentation and a formal architecture review.

• Verification Mechanism: The verification mechanism is a means to verify that the work accomplished for the process is complete. This can be in the form of a review by the program office or some type of peer review.

• Defined Outputs: Outputs are deliverables that are defined by the process.

• Defined Completion Criteria: These final completion criteria are the conditions to verify that all the specifications of a process have been satisfied.

Managed

Organizations that have reached the managed level of process maturity set quantitative quality goals for software development applications and processes. The quality and productivity of the defined processes are measurable across all the software efforts in the organization. Finally, an organization-wide database is available to collect and analyze the metrics defined for software development projects.

The software processes in a level-4 managed organization are predictable and measurable. Also, these measured processes are used to establish a foundation for quantitatively evaluating a project's delivery performance. Projects with measured performance beyond the expected boundaries are reevaluated to understand the conditions of the metric deviations.

Optimizing

At the optimizing level of maturity, the entire organization is focused on continuous process improvement. The organization has identified groups that continually identify weaknesses, and they strengthen the processes proactively with the goal of preventing defects. Measurement captured to capture the performance of processes are used to create cost-benefit analyses of new technologies and proposed changes to the existing processes.

Level-5 organizations are capable of focusing on constant process improvement because the maturity of the established processes is already dependable, repeatable, and measurable. The risks of delivering software products are reduced dramatically by this point and the organization can continue to focus on optimizing existing processes.

The Benefits and Shortcomings of CMM

CMM-certified organizations are benefited in a variety of ways as they mature to a deeper level of process maturity. First, CMM is fully comprehensive for an organization's full software development life cycle definition. It describes all the process areas that are required to successfully budget, define, design, construct, and deploy software products. Where other software methodologies focus on the definition, construction, and deployment of software, CMM incorporates the procedures necessary to build organization-wide exposure to project estimation, project tracking, and standards compliance. The CMM framework is also generally compliant with any corporate procedures for project delivery. As a framework, it is up to the organization to fill in the detailed processes. For organizations that require proprietary steps in project sign-off and quality assurance, the CMM framework only identifies key areas that must be satisfied. This framework-based approach to process definition enables this methodology to be used in conjunction with other development methodologies as long as the key process areas are satisfied in the delivery. Next, CMM is developed in perspective to manage multiple projects across an organization. Where other methodologies generally focus on the delivery of the specified project, CMM defines the organizational and procedural requirements for managing multiple simultaneous projects. Finally, with the pervading practice of utilizing offshore-development vendors, organizations can utilize this standard framework to manage processes across disparate development teams while still being able to manage and evaluate project performance at a strategic level.

Implementing a CMM framework into an organization has a number of shortfalls as well. Because of the depth and breadth of the CMM framework, it is generally expensive to implement and maintain the levels of process maturity in an organization. To satisfy all the process areas, new groups must be identified to support the definition, evaluation, and tracking required of mature capability models in an organization. Also, CMM organizations tend to be documentation intensive and bureaucratically complex as projects navigate through the various procedures that must be followed for a software delivery. All the process definition required for CMM mature organizations adds overhead to projects. Until an organization reaches level 5 optimizing many process procedures may not be applicable to a project's delivery but must be followed to adhere to the framework. This creates a scenario in which, regardless of a project's size, a sunk cost in the delivery of any project just complies with all the process requirements. For example, in a CMM level-3 organization, to develop even the simplest software project requires that every defined process and procedure be satisfied. Finally, a CMM mature organization does not necessarily dictate successful software delivery. The framework is mainly focused on controlled and repeatable processes that are adhered to in a project.