- 3.1 An Overview of CMMI
- 3.2 CMMI Objectives
- 3.3 The Three Source Models
- 3.4 CMMI Project Organization
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 The Three Source Models
To truly appreciate the significance of the CMMI accomplishments, you need to understand a bit of the history that led up to the development of the CMMI product suite. Of primary importance are the stories of the source models. Table 3-1 summarizes the three source models for CMMI.
Table 3-1. Source Models for CMMI
|
Model Discipline |
Source Model |
|
Software |
SW-CMM, draft version 2(c) |
|
Systems Engineering |
EIA/IS 731 |
|
Integrated Product and Process Development |
IPD-CMM, version 0.98 |
3.3.1 The CMM for Software
The character of software development sometimes seems closer to mathematics and art than it does to most other engineering disciplines. Software is inherently an intangible, intellectual development medium. No laws of physics govern its behavior; it is both marvelously and dangerously malleable. For this reason, it is critical that mature disciplines and processes be applied when working with software.
Software engineering and process management have been intimately associated since the pioneering work of Ron Radice and Richard Phillips in Watts Humphrey's group at IBM in the 1980s.5 Basing their work on the tenets of the quality movement, Radice and Phillips led the way in crafting a way to capture successful software development practices and then organize those practices so as to help struggling organizations get a handle on their processes and improve them. Given the nature of software development, it was not surprising that the large majority of the practices related to management discipline and processes.
In 1986, Watts Humphrey, the SEI, and the Mitre Corporation responded to a request by the U.S. federal government to create a way of evaluating the software capability of its contractors. The group used IBM's concepts to create a software maturity framework, a questionnaire, and two appraisal methods. Over the next few years, this work was continued and refined.
In 1991, the SEI published the CMM for Software version 1.0, a model that describes the principles and practices underlying software process maturity. The CMM is organized to help software organizations improve along an evolutionary path, growing from an ad hoc, chaotic environment into mature, disciplined software processes. The CMM was used and evaluated for two years, and then revised and released as version 1.1 in 1993.7 A similar revision was planned for 1997 as version 2.0;8 this version was developed but never released as an independent model. However, the good work did not go to waste: The proposed revision was used as the source for the CMMI integration effort. In addition, two documents regarding software appraisals were used: the CMM Appraisal Framework, version 1.0,9 and the CMM-Based Appraisal for Internal Process Improvement (CBA IPI): Method Description.10
Software engineering's scope extends beyond the primary material contained in the CMM for Software to include software-related topics such as requirements elicitation, installation, operation, and maintenance. The CMMI model covers these areas in more detail through inclusion of appropriate material from the Systems Engineering Capability Model.
3.3.2 The Systems Engineering Capability Model
Systems engineering integrates all of the system-related disciplines so that systems meet business and technical needs in the most effective way, while striving to minimize local optimization and maximize return on investment. Another way of envisioning systems engineering is as the application of a set of rigorous engineering techniques to the solution of a complex technical problem.
It is difficult to fully understand the scope of systems engineering without looking at the various specialty disciplines associated with it. In Essentials of Project and Systems Engineering Management, Howard Eisner lists 30 key elements of systems engineering. These elements include such diverse areas as mission engineering, architectural design, life-cycle costing, alternatives analysis, technical data management, operations and maintenance, integrated logistics support, and reengineering.12
The systems engineering material in the CMMI has a complex history. In a modern-day "Tale of Two Capability Models," two organizations undertook to model systems engineering practices. In August 1995, the Enterprise Process Improvement Collaboration (EPIC—a group of industry, academic, and government organizations) released the Systems Engineering Capability Maturity Model (SE-CMM). EPIC enlisted the SEI and architect Roger Bate to lead the development. The team pulled its systems engineering expertise primarily from aerospace and defense industry corporations and from the Software Productivity Consortium. The result was a model based on the appraisal model architecture contained in draft versions of ISO/IEC 15504 that addressed engineering, project, process, and organization practices.13
Around the same time that the SE-CMM was under development, INCOSE created a checklist for evaluating the capabilities of systems engineering organizations based on various engineering standards. Over time, this checklist evolved into a full-blown capability model known as the Systems Engineering Capability Assessment Model (SECAM). SECAM extended the SPICE concepts of a continuous model but focused more specifically on systems engineering practices than the SE-CMM, using EIA 632, "Processes for Engineering a Model," as the fundamental reference.
Needless to say, an environment with two models developed by two reputable organizations that purported to address the same issues was ripe for a model war. Which model would emerge as the "standard" by which organizations could be evaluated? After a year of heated discussions, in 1996 EPIC and INCOSE agreed to work together under the auspices of the Government Electronic and Information Technology Association (GEIA) of the Electronic Industries Alliance (EIA), with the goal of merging the two models into a single EIA standard. The result was an interim standard EIA/IS 731, "Systems Engineering Capability Model" (SECM).14 By issuing the interim standard, the systems engineering community could apply a single, common description of systems engineering processes to the CMMI project.
Systems engineering in CMMI remains heavily influenced by EIA 731. While echoes of the controversy between SECM and SE-CMM found voice in CMMI discussions, the resulting systems engineering content reflects an even stronger evolution of the original concepts. It preserves some of the innovations of EIA 731 while providing a more consistent underlying architecture compatible with the emerging international standards.15 The standard includes both the SECM model (Part 1) and an appraisal method (Part 2).
3.3.3 The Integrated Product Development CMM
The source model for integrated product and process development was a draft of the Integrated Product Development CMM, known as IPD CMM version 0.98. This model had been developed almost to the point of its initial formal release when the CMMI project began in 1998.
From the outset, the CMMI Team wanted to include the concept of integrated product and process development (IPPD) in the CMMI product suite. This concept was fundamental to many of the large member corporations of NDIA, and it was strongly supported by the Department of Defense (DoD).16 Unfortunately, the definition of IPPD used in the CMMI requirements document was derived from the DoD's experience with integrated operation of government system acquisition programs—and acquisition was not an initial discipline for CMMI. This discrepancy led to some difficulty in addressing the IPPD tenets within the CMMI scope. Adding to the confusion was a lack of consensus in the industry (and among members of the CMMI Team) regarding the fundamental concepts and best practices of integrated product development. Because it represented a relatively new means of organizing and accomplishing engineering work, there were nearly as many definitions as there were organizations.
This problem was not unique to CMMI. Indeed, the team established by EPIC to develop the IPD CMM, which was supported by many of the same members of the SE-CMM team, struggled with IPPD concepts for more than two years before being subsumed into the CMMI effort. The final draft IPD-CMM was established as a source document for CMMI, but the draft never achieved the status of a finished product.
IPPD emphasizes the involvement of stakeholders from all technical and business functions throughout the product development life cycle—customers, suppliers, and developers of both the product and product-related processes, such as testing and evaluation, manufacturing, support, training, marketing, purchasing, financial, contracting, and disposal processes. Clearly, implementing IPPD affects more than an organization's engineering processes and practices. Because it is essentially a way of doing business, it may radically change organizational structure and modify leadership behavior.