The Capability Maturity Model Integrated
By Hodari Na Basura
Running head: THE CAPABILITY MATURITY MODEL INTEGRATION
The Capability Maturity Model Integrated Capella University
Graduate School of Technology
TS 5130
System Development Theory and Practice
Abstract
This paper discuses the history of the SW-CMM and CMMI of the Software Engineering Institute at Carnegie-Mellon University. This document contains a description of the process areas, bodies of knowledge, and purpose of the generic goals and practices. It also describes the relationship of the process area to the capability level of the Continuous Representation and maturity levels of the Staged Representations. In addition, there is a brief description of the chapters and appendices of the on-line manuals. The conclusion states some of the observations of Ahern (2001) and West (2004) as well as some personal observation about the CMM/CMMI modules.
Table of Contents
Abstract 2
Introduction 4
CMMI 8
Software Development Life Cycle 9
Overall Description CMMI 11
Process Areas 13
Staged Representation 16
Continuous Representation 22
Assessment 28
Conclusion 31
Summary 31
Future of CMMI 32
Figures 39
Tables 39
The Capability Maturity Model Integrated
Introduction
The maturity model concepts grew out of the works of Walter Shewhart in the 1930s with the Principals of Statistical Control. Later, W. Edward Deming and Joseph Juran expanded on Shewhart’s principles. Deming gained fame as the economist that helped reconstruct the Japanese economy after World War II. In brief, his economic and management theories taught the Japanese that teamwork far outweighs the accomplishments of individuals. Additionally, Deming’s theories demonstrated to the Japanese in a modern business environment nothing is static, management systems are always in flux to meet their economic needs and goals (Barnett, 1994).
In the 1980s, several organizations within IBM led by Watts Humphrey, Ron Radice extended the management concepts of Deming and applied the principles to software development. The research work eventually led to the development of the Process Maturity Model (PMM). The PMM provided software engineers with the basic methodologies and best practices to ensure the production of high quality software and employee feedback (Chrissis, Konrad, & Shrum, 2003).
In 1984, the United States government, the nation’s largest software developer, decided to create a federally funded research institute at Carnegie-Mellon University called the Software Engineering Institute (SEI) to assist the Department of Defense with the assessment of software development contractor’s ability to meet contractual obligations. The SEI researchers, inspired by the careers and theories of Deming and the researchers at IBM, created the Capability Maturity Model as the government’s new assessment tool. In all, the SEI developed a series of six capability maturity models. Five are discussed hear briefly, the sixth; the Capability Maturity Model Integrated or Integration is the subject of this term paper. The five other models are listed below:
1. SW-CMM - the Software Capability Maturity Model is used for measuring software development organizations ability to meet contractual obligations.
2. P-CMM - the People CMM is used to assess an organization’s management personnel
3. SA-CMM – the Software Acquisition CMM follows the same framework as the SW-CMM, with emphasis on acquisition issues and the needs of individuals and groups who are planning and managing software acquisition efforts.
4. IPD-CMM - The Integrated Product Development CMM was a model created to use for judging the integrated product development processes of software contractors.
5. SE-CMM - The Systems Engineering CMM was a model designed to use for judging the essential elements of the systems engineering processes of an organization (Hamilton & Harris, 2001).
The CMM model categorizes organizations that develop software into five maturity levels as shown below in figure-1.
Figure 1 Software Engineering Institute's Levels of maturity
Each of the CMM maturity levels focuses on differing activities. The first maturity level, the Initial Level, describes a software development process that is ad hoc. There are no discernable standardized practices in place. The input processes are ill defined and uncontrolled. Output is described as chaotic. Organizations working at this level should focus on imposing structure to their developmental process.
At the next maturity level, the Repeatable Level, organizations focus on defining software inputs and outputs, its functional requirements, and its non-functional requirements. This level, according to Pfleeger (2001), is where basic project management cost, budget, schedule, and functionality come into play.
Refining attributes of the repeatable level leads an organization to the third maturity level, the Define Level. At the defined level, management and engineering activities are documented, standardized, and integrated throughout the organization’s software developmental process. The defined level provides insight to into a systematic approach to software development. At this maturity level, key organizational software development practice areas have focus. The organization’s product attributes, staffing, criteria and faults are measured against customer expectations and requirements. This maturity level differs from the repeatable level in that activities are defined and their outputs are known. As a result, organizations are capable of comparing and measuring fault density with previous projects. Such capabilities provide more controls over future development projects. After mastering the practices at the defined level, the software development organization moves up the CMM ladder to the next level, the Managed Level (Pfleeger, 2001).
At the Managed Level, software development companies exhibit a consistent organizational framework for developing its workforce. The organization manages the maturity level and its practices with a sustained systematic monitoring of activities. Organizations functioning at this maturity level have statistical baselines to measure and predict project performances. The management baselines quantify understanding of the development process and the causes for variation. The baseline tools provide insight into project outcomes much earlier in the development process. By managing statistically, management consents to greater empowerment of project teams and increased predictability of project results (LeVasseur, 2005).
The final level in the CMM is the Optimizing level. At this level, the entire organization focuses on the continual optimizing of competency-based processes and workforce practices to pinpoint areas for improvement. At this level, organizations establish an infrastructure for supporting continuous change management as a fundamental and integral component of their development processes (Pfleeger, 2001) (Curtis et al., 2002) (LeVasseur, 2005)
CMMI
According to the Software Engineering Institute (SEI) (2005), “Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind. … Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems. Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates.”
Software Development Life Cycle
In Software Engineering: Theory and Practice by Pfleeger (2001), software engineering is described as a methodical approach, that first provides an analysis of a problem, then breaks the large problem into smaller problems. After synthesis, the pieces are joined together once again to reform the larger structure.
The software life cycle is similar to Pfleeger’s analysis of software engineering in that it begins with a problem or the ideal of the customer. Each facet of the customer’s needs and desires are translated into software requirements, which in turn are analyzed and decomposed into smaller manageable components. Then each smaller component is built according to the customer's needs. Next, each individual component is tested, integrated, and systematized. Finally, after synthesis, each decomposed component is rejoined once again into the customer’s ideal. An example of the Software development life cycle is shown below in table-1, with an explanation of the stages.
Table 1 Software Life Cycle
Stages Descriptions
Requirements Analysis The requirements are a description of customer desires and what the system is capable of doing.
System Design System design consists of two components: Conceptual design and technical design. Conceptual for the customer and technical for the engineers
Program Design Program design describes the program architecture: classes, objects, relationships, and component
Code Writing The coding of the program takes place at this level
Unit Testing Unit testing verifies that each component of the software functions properly
Integration Testing This is the process of verifying the system components are properly defined and work together as described in the design requirements and program design.
System Testing System testing ensures the system meets the customer’s demands.
System Delivery This phase of the cycle discusses user training, system documentation, and installation of the system
Maintenance This is the point in the software life cycle where maintenance and configuration management are key.
(Pfleeger, 2001)
The table describes nine steps in the software development life cycle. It begins with requirements analysis that describes the customer’s needs. After translating customer wants in software requirements, the system designers take control of the project. The system designers complete two designs one for the customer and one for the development team members. A stop at the program designer is the next step in the software development life cycle. At this point, the program designers translate the system designers’ drawings into programmable components. Next, the programmers write the code that transforms the programmable components into a usable application. After the program is written, quality assurance takes over the next three steps in the software life cycle. QA performs unit tests, integration tests, and system’s tests to ensure the program functions as the customer wants. The final step is the system maintenance.
Organizations describe their software life cycle in terms that fit into their talent, workforce practices, and management standards. Other names synonymous with the software development life cycle are Waterfall Model, Waterfall Model with Prototyping, V Model, Prototyping Model, Transformational Model, Operational Specification Model, Phased development Model, Incremental Development Model, Iterative Development Model, and the Spiral Model. There are hundreds of other names and systems for the software development life cycle but that is beyond the scope of the paper (Pfleeger, 2001).
Overall Description CMMI
The Software Engineering Institute (SEI) developed Capability Maturity Model Integrated (CMMI) as a software engineering evaluation tool to evaluate the systematic approaches software development companies apply to the software development life cycle (Hamilton & Harris, 2001). CMMI replaces the Capability Maturity Model described in the introduction. SEI developed the CMMI to fix the shortcomings of the Capability Maturity Model. Since then CMMI has become the de facto standard for determining maturity and capability levels of software development and systems development organizations.
Supposedly, CMMI eliminates the bottlenecks and administrative barriers of its predecessor CMM. CMMI consists of methods considered the best practices for a product’s life cycle, from conception to maintenance. SEI achieved this standard by combining three popular and widely used software development models the Capability Maturity Model for Software (SW-CMM), the Systems Engineering Capability Model (SECM), and the Integrated Product Development Capability Maturity Model (IPD-CMM) into one suite or framework (Chrissis, Konrad, & Shrum, 2003).
The CMMI framework offers management a choice of two representations: Staged Representation Model or Continuous Representations Model.
The fundamental question facing users of the CMMI is which representation to employ? The choice is not that difficult. According to the SEI (Ahern et al., 2001), whichever representation is chosen, it is the correct choice. The first model, the Staged Representation is similar to the old CMM with predefined boundaries and prescribed sequences of improvements. The second choice, the continuous representation is similar to the structure of the System Engineering Capability Model (SECM). The choice of representations depends on the organization’s needs for improvement to their managerial and engineering processes. An organization may choose to focus on organizational maturity or process area capabilities (Ahern, Clouse, & Turner, 2001).
Each representation has its advantages. For instance, if you choose the continuous representation for your organization, expect that the model will do the following: a) Allows an organizations to select the order of improvement that best meets the organization’s business objectives and mitigates the organization’s areas of risk b) Enables comparisons across and among organizations on a process area by process area basis or by comparing results through the use of equivalent staging
c) Provide an easy migration from Electronic Industries Alliance Interim Standard (EIA/IS) 731 to CMMI
d) Affords an easy comparison of process improvement to International Organization for Standardization and International Electro-technical Commission (ISO/IEC) 15504, because the organization of process areas is similar to ISO/IEC 15504
By choosing the staged representation, an organization expects the model will do the following:
a) Provide a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels, each serving as a foundation for the next
b) Permit comparisons across and among organizations by the use of maturity levels Provide an easy migration from the SW-CMM to CMMI
c) Provide a single rating that summarizes appraisal results and allows comparisons among organizations (Guibert, 2004).
Process Areas
CMMI defines a process area as a cluster of related practices that, when performed collectively; satisfy a set of goals considered important to making significant improvement. To understand their interactions and interrelationships with one another regardless of their defined level, understand that CMMI interprets the PAs across following four categories or bodies of knowledge: Process Management, Project Management, Engineering, and Support.
The process management process areas contains cross-project activities related to defining, planning, resources, deploying, implementing, monitoring, controlling, appraising, measuring, and improving processes. The process management process areas are as follows:
• Organizational Process Focus
• Organizational Process Definition
• Organizational Training
• Organizational Process Performance
• Organizational Innovation and Deployment
The project management process areas addresses project management activities related to planning, monitoring, and controlling the project. Project management process areas encompass activities related to establishing and maintaining the project plan, establishing and maintaining project commitments, monitoring progress against the plan, taking corrective action. Planning begins with requirements that define the product and project “What to Build.” The process areas include the following:
• Project Planning
• Project Monitoring and Control
• Supplier Agreement Management
• Integrated Project Management for IPPD
• Risk Management
• Integrated Teaming
• Integrated Supplier Management
• Quantitative Project Management
The engineering process areas consist of development and maintenance activities shared across engineering disciplines (for the purpose of this paper systems engineering and software engineering). The six process areas in the engineering process area category have inherent interrelationships. The categories of the engineering process area are as follows:
• Requirements Development
• Requirements Management
• Technical Solution
• Product Integration
• Verification
• Validation
The support process areas focus on activities that support product development and maintenance. In general, the support process areas concentrate on processes that target the project, and may address processes that apply more generally to the organization. For example, the process and quality assurance category can be used with all process areas to provide an objective evaluation of work products described in all organizational departments. The categories of the support process area are as follows:
• Process and Product Quality Assurance
• Configuration Management
• Measurement and Analysis
• Organizational Environment for Integration
• Decision Analysis and Resolution
• Causal Analysis and Resolution (International Software Benchmarking Standards Group, 2004).
Staged Representation
The staged representation online manual of the CMMI model table of contents lists a total of seven chapters and five appendices briefly described below:
• Chapter 1 - The introductory chapter provides an overview of the CMMI models, suggestions on where to look for other information not included in the CMMI models, and the typographical conventions used throughout the CMMI models.
•
• Chapter 2 - The Model Components chapter describes the model components, maturity levels, goals, and practices.
•
• Chapter 3 - The Model Terminology chapter describes the approach using terminology in CMMI models and terms defined in the glossary.
•
• Chapter 4 - Entitled, Common Features, Generic Goals and Generic Practices, describes the common features and generic practices, which ensure that the implementation of processes is effective, repeatable, and lasting. • Chapter 5 - Framework Interactions provides insight into the meaning of basic and advanced processes for the areas of project management, process Management, support, and engineering. • Chapter 6 – This chapter, entitled the Using CMMI Models explains the methods in which an organization may use the CMMI models. • Chapter 7 - The last chapter, Process Areas, contains descriptions of the required, expected, and informative components of the selected models including goals, practices, subpractices, and typical work products.
The Appendices are as follows:
• Appendix A - represents usable resources to locate the documented sources, such as reports, process-improvement models, industry standards, and books, used to create the content of the CMMI models. • Appendix B - defines acronyms used in the CMMI models. • Appendix C: The Glossary appendix defines terms used in the CMMI models not adequately defined in the text or by the Webster’s American English dictionary. • Appendix D - The Required and Expected Model Elements appendix contains the required and expected components of each of the process areas. It offers no informative material other than the process area purpose, titles, and component titles. • Appendix E - contains a list of CMMI Steering Group members, Product Team, Configuration Control Board members, and Stakeholder/Reviewer Team
The Staged Representation like its predecessor, the CMM, provides an organization with a predetermine path of success via adherence to a maturity level’s schedule of ordered groupings, prescribed processes for organizational relationships and practices. Each maturity level has a set of standards that indicate where an organization should focus its efforts to improve its software development processes. Each process describes practices that contribute to satisfying a maturity level’s goal. The practices describe infrastructure and activities that contribute to an effective implementation of the maturity level requirements (Ahern et al., 2001).
The staged representation model lists five maturity level plateaus:
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing.
Within the Staged Representation each maturity level model are a list specific goals and specific practices followed by a list generic goals and generic practices. The CMMI describes a generic goal as the degree of institutionalization an organization needs to achieve to satisfy a process area. In the staged representation each maturity levels area has only one generic goal. Achievement of a generic goal in a maturity levels signifies improved control in planning and implementing the processes associated with that maturity level. Generic goals are required maturity level components and are used during appraisals to determine whether a process area has been satisfied (Guibert, 2004).
The specific goals apply to process areas and attend to the unique characteristics that describe required implementations to satisfy the maturity levels. Specific goals are used during appraisal to determine if a specific practice satisfies the process area of a maturity level.
The staged representation focuses on the best practices an organization can employ to improve its software engineering practices in the process areas of a given maturity level. Before an organization begins using the CMMI model for improving processes, it must map its software development life cycle to the CMMI process areas. Mapping enables it to document and control process improvement by creating tracking data to measure the organization’s level of conformance to the CMMI model. It is understood that not every CMMI process area maps to one of the organization’s software development life cycle. Figure-2, describes the CMMI components for the staged representation (Guibert, 2004).
Figure 2 - CMMI Staged Representation Maturity Level Components
Each maturity level, except for the first, builds upon the previous maturity levels goals and practices. Maturity levels are composed of key elements called Process Areas (PA). CMMI defines a PA as a set of practices, generic and specific, that when by the software developer achieves a given purpose of the PA. The goals of a PA may include tools, methods, materials, and/or people.
The first level of the Staged Representation is the Initial Level. Organizations falling into this category are characterized by unpredictable ad-hoc processes areas with dubious and uncertain results.
Organizations with some structured processes may reside on plateau two or the Managed Level. At the Managed Level, organizational improvement channels through project management. Organizing project management makes certain the software development organization is documenting it projects, that customer requirements are recorded and events are planned, performed, measured, and controlled. The process areas for the Managed Level are as follows:
1. Requirements Management
2. Project Planning
3. Project Monitoring and Control
4. Supplier Agreement Management
5. Measurement and Analysis Process and Product
6. Quality Assurance
7. Configuration Management
When a software development company rises to the Defined level, it focuses on organizational standardization. The defined level PA sets the standardize processes for the level. These standards are used to establish consistency across the organization. The process areas at level three include the following:
1. Requirement Development
2. Technical Solutions
3. Product Integration
4. Verification
5. Validation
6. Organizational Process Focus
7. Organizational Process Definition
8. Organizational Training
9. Integrated Project management
10. Integrated Supplier Management
11. Risk Management
12. Decision Analysis and Resolution
13. Organizational Environment for Integration
14. Integrated Teaming
The Quantitatively Managed Maturity Level is the fourth level of the Staged Representation. At this level, the company uses a statistical baseline to manage. This level list just two important PA:
1. Organizational Process Performance
2. Quantitative Project Management
The final level of the Staged Representation is the Optimizing level of the CMMI; it assesses the following two areas:
1. Organizational Innovation and Deployment
2. Casual Analysis and Resolution.
Continuous Representation
The online CMMI manual for Continuous Representation contains seven chapters and six appendices. A brief description of the chapters and appendices follows:
• Chapter 1 - The introductory chapter provides an overview of the CMMI models, suggestions on where to look for other information not included in the CMMI models, and the typographical conventions used throughout the CMMI models.
• Chapter 2 - The Model Components chapter describes the model components, maturity levels, goals, and practices. • Chapter 3 - The Model Terminology chapter describes the approach using terminology in CMMI models and terms defined in the glossary. • Chapter 4 - Entitled, Common Features, Generic Goals and Generic Practices, describes the common features and generic practices, which ensure that the implementation of processes is effective, repeatable, and lasting. • Chapter 5 - Framework Interactions provides insight into the meaning of basic and advanced processes for the areas project management, process Management, support, and engineering. • Chapter 6 – This chapter, entitled the Using CMMI Models explains the methods in which an organization may use the CMMI models. • Chapter 7 - The last chapter, Process Areas, contains descriptions of the required, expected, and informative components of the selected models including goals, practices, subpractices, and typical work products.
The Continuous Representation appendices are as follows:
• Appendix A - represents usable resources to locate the documented sources, such as reports, process-improvement models, industry standards, and books, which were used to create the content of the CMMI models. • Appendix B - defines acronyms used in the CMMI models.
• Appendix C - The Glossary appendix defines terms used in the CMMI models not adequately defined in the text or by the Webster’s American English dictionary. • Appendix D – The Required and Expected Model Elements appendix contains the required and expected components of each of the process areas. It offers no informative material other than the process area purpose, titles, and component titles. • Appendix E - contains a list of CMMI Steering Group members, Product Team, Configuration Control Board members, and Stakeholder/Reviewer Team (Carnegie-Mellon, 2002).
The process area for the Continuous Representation differs from the process area of the Staged Representation. In the Staged Representation, figure-2, a process area differentiates generic and specific goals. In the staged models, a specific goal leads to a specific practice; and a generic goal leads to common features (commitment to perform, ability to perform, directing implementation, and verifying implementation) that create generic goals. The process area composition in the continuous model, in contrast, shown in figure-3, illustrates capability levels create a link between generic and specific goals.
There are six Continuous Representation capability levels, numbered from 0 to 5, compared to five maturity levels for Staged Representation. Each capability level, except the first, has a corresponding generic goal and a set of generic and specific practices. The six CMMI Continuous Representation capability levels are listed as follows:
Level 0 – Incomplete
Level 1 - Performed
Level 2 - Managed
Level 3 - Defined
Level 4 - Quantitatively Managed
Level 5 - Optimizing.
In another comparison of the two representations, the Continuous Representation capability levels have more specific practices than the Staged Representation. For instance, the Continuous Representation has two types of specific practices, base and advanced, per capability level, whilst the Staged Representation has only one specific practice per maturity level.
In the continuous models, generic practices exist for capability levels 1-5. While in the staged models, the generic practices appear for only maturity levels 2 and 3. There are no generic practices for maturity levels 1, 4, and 5. Figure-3 shown below illustrates the process areas of the continuous models.
Figure 3 Continuous Representation Process Areas
As stated earlier, the continuous representation’s models provide less structured guidance and do not have distinct levels associated with an organization’s maturity. An example of a continuous model is the EIA/IS731. (EIA/IS731 introduces the concepts of advanced practices known as Focus Areas (FA). The FA represents the merger of technical practices within a process area SE-CMM with process areas of the Systems Engineering Capability Assessment Model (SECAM). The purpose of the merger is associated with higher capability levels augmented by generic practices and industry wide acceptance of the practices).
The first capability level, capability level 0, the Incomplete Level, the requirements of the process areas is either incomplete or non-existent. At this level, neither goals nor practices exist.
The second level in the Continuous Representation is the Performed Level. In the performed level, the processes support and enable achievement of specific goals of the process area by transforming identifiable work inputs into identifiable work outputs. The generic goals of the level focus upon achieving the specific goals and practices. There are two generic practices for the Incomplete Level:
1. Achieve specific goals
2. Perform base practices.
Capability level two is the Managed Level. The Managed Level focuses on institutionalization as a managed process. There are ten generic practices at the managed capability level. At this level, an organization has a policy stating which process to use and follows a documented plan and process description. The ten generic practices of capability level two are listed (Ahern et al., 2001):
1. Establish an Organizational Policy.
2. Plan the Process.
3. Provide Resources.
4. Assign Responsibility 5. Train the people performing or supporting the process as needed.
6. Manage Configurations.
7. Identify and Involve Relevant Stakeholders. 8. Monitor and control the process against the plan for performing the process and take appropriate corrective action. 9. Objectively evaluating the process, its work products, and its services for adherence to the process descriptions, standards, and procedures, and addressing noncompliance. 10. Review the activities, status, and results of the process with higher-level management and resolve issues (Carnegie-Mellon, 2002).
The Defined Level is Capability level 3. The generic practices for this level focus on institutionalization as a defined process. In other words, for each process area, each organizational project has a managed process as defined in capability level two. There are only two generic practices for the Defined Level:
1. Establish a defined process
2. Collect improvement information.
Capability level 4 is the Quantitatively Managed Level. Its generic goals focus on institutionalization as a quantitatively managed process (Ahern et al., 2001). According to SEI (Carnegie-Mellon, 2002), a quantitatively managed process is a defined (capability level 3) process that is controlled by statistical and quantitative techniques. The quantitative objectives for quality and process performances are the criteria for managing the process. The quantitative objectives are based on the capability of the organizational: standard processes, business objectives, and the customer needs, end-users needs, organizational needs, and process implementers subject to available resources. The two generic goals for the quantitatively managed level follow:
1. Establish quantitative objectives for the process
2. Stabilize sub-process performance (Carnegie-Mellon, 2002).
Capability level five is the Optimizing Level. Organizations functioning at this level have generic goals focus on institutionalization as an optimizing process. This level requires management to adapt constantly the quantitatively managed process established with capability level four based on their measurements (Ahern et al.). The generic practices of capability five are as follows:
1. Ensure Continuous Process Improvement
2. Correct Root Causes of Problems (Carnegie-Mellon, 2002).
Assessment
The assessment of the continuous representation differs from that of the staged representation. Whereas the staged representation assessments evaluates an organization as a whole by determining how many process areas have been achieved, the continuous representation assessment rates each process area by its own capability. An assessments of an organization’s capability levels measures several different process areas with differing levels of proficiency. The results of the organizational assessment is reported as a capability profile as shown in figure-4.
Figure-4 Capability Level Profiles
The capability profile includes the level number ratings, as shown in figure-4 above for individual process areas or for a set of process areas. In the above example, the profile examines capability level three. The results show the organization is strong in the dimensions of Monitor and Control and Management Configuration. It, also, shows the organization needs to stress improvement in the dimensions of Integrate Discipline and Management Risk.
The CMMI provides two methods for assessment. The method System Engineers used was the SECM of the EIA/IS 731-1 or EIA/IS 731-2. The other method used by Software Engineers is the SW-CMM-Based Appraisal for Internal Process Improvement.
One part of the CMMI product that deals with assessments is the Assessment Requirements for CMMI version 1.0 (ARC). It is composed of 40 requirements that provide a mixture of offset requirements and design constraints. The Assessment Requirements for CMMI has seven categories as listed below: 1. Responsibilities – this category lists the responsibilities of the assessment sponsor and the assessment team lead. 2. Assessment Method – List the documentation that should be included in the assessment. 3. Planning and Preparation - This section identifies a minimum standard of assessment preparation activities. 4. Assessment Data Collection – This section of the ARC lists the three required methods of data collection: administering instruments, interviews, and documentation review. 5. Data consolidation and Validation – In this section, the constraints on the way an assessment method provides for the consolidation and validation of data. 6. Rating – The ratings section lists specific constraints for achieving a capability level or maturity level rating. 7. Reporting Results – This section requires documentation of the findings for the assessment sponsor.
Another part of the CMMI assessment is the Standard CMMI Assessment Method for process Improvement (SCAMPI). The CMMI development team developed SCAMPI to address all requirements of the ARC. SCAMPI is divided into three levels: (1) initial planning and preparations, (2) on-site assessment, and (3) reporting results.
Each level is refined into sub-tasks. For example, level one describes identifying the scope of the assessment, developing plans, preparing the team, briefing the participants, administering the appraisal questionnaire and examination, and conducting the final review.
Level two of SCAMPI focuses on holding meeting for the on-site visit, conducting interviews, consolidating information, preparing and presenting draft findings, consolidating the findings, and determining ratings and preparation of the final findings.
Finally, level three of the SCAMPI address the presentation of the final findings to the sponsor and collections of all information needed by the CMMI Steward (SEI) (Ahern, Clouse, & Turner, 2001).
Conclusion
Summary
In conclusion, as stated earlier, the SEI at Carnegie-Mellon University created the CMM to assist the Federal government’s assessment of software developers. What SEI created was a framework of generally accepted practices of successful software developers; these attributes when compared to current practices of software vendors vying for governments contracts made the government’s assessment of competing vendors’ capabilities easier.
The original appraisal system, the CMM, however, created too many awkward administrative bottlenecks that isolated managerial processes and engineering processes from the organizational overall business objective. In an effort to eliminate the shortcomings of CMM, the SEI, in 1993, created the CMMI.
Unlike its predecessor, the CMM, which used just the SW-CMM for evaluation of an organization’s worthiness, the CMMI combines three widely used software development models the Capability Maturity Model for Software (SW-CMM), the Systems Engineering Capability Model (SECM), and the Integrated Product Development Capability Maturity Model (IPD-CMM) as sources for the new framework. The source models are then expressed across four subject knowledge areas Process Management, Project Management, Engineering, and Support.
CMMI also differs from CMM in another way; it offers two models to choose from Staged Representation and Continuous Representation. The Staged Representation, like CMM has definite boundaries. The Continuous Representation does not have definitive boundaries. Instead, the Continuous Representation creates profiles that describe the process area dimensions for each capability.
Future of CMMI
In this strained economic time in the United States, one unexpected outcropping of the CMM was it became the measuring stick for outsourcing. International companies with lower standards of living and lower wage requirements present themselves to corporate boards as thrifty alternatives to the wages of American developers. Even so, some unwanted drawbacks invite themselves into the process. CMM comparisons of are not as simple, because CMM measures what a company has, not how well the company organizes around its capability. For example, a company may reach the second maturity level simply because it has a requirements management department. It matters not that the management requirements department in question is one of the worst in the region or nation. CMM does not distinguish quality (Tomayko & Hazzan, 2004).
According to (Voas, 2000) another drawback of the staged representation was the lack of statistical validation. Many of the implementations of CMM restated CMM requirements instead of the measurement and analyzing techniques require making valid assessments of the capability levels.
Still others view adapting either SW-CMM or CMMI as excellent guidelines for planning and managing projects. However too many people involved in a process improvement work fail to see the relevance of guidelines to their work. Even if an organization focuses exclusively on software-intensive systems, CMMI does not or cannot address many of the realities of project planning and management. CMMI was never intended to be a convenient substitute for thinking.
Many researchers use the terms systems thinking as analyzed in the book The Fifth Discipline by Senge (1994) to elaborate, resolve, and overcome deep organization problems commonly plaguing CMM and CMMI-based process improvement initiatives. According to Senge, through West (2004), continually working inside a process improvement environment causes management to loose site of the main objective of the CMMI. There are two system’s archetypes that provide insight to commonly recurring systemic problems in organizations working in process improvement environments: fixes that backfire and shifting the burden.
With archetype fixes that backfire systems, obvious solutions are applied to problems. When the perceived or obvious solution is applied hastily and without thorough analysis of problem, the results are often unintended consequences, which further aggravate of the problem. For example, several organizations resorted to corporate downsizing to improve profits. A subsequent study in 1991 study of 850 companies that had cut staff drastically, only 41 percent had achieved the hoped for savings. Such hastily applied solutions often created grass-roots resistance to achieving maturity level amongst remaining employees.
For shifting of the Burden archetype, the problem symptoms bring about a quick intervention. The solution is obvious but the fundamental source of the problem continues. The situation continues until a standardized process is in place to remedy the situation. Problems like this evolve in organizations that do not have a CMMI maturity level (West, 2004).
Consternation has developed over the lack of certification of XP companies. According to sources (Reifer, 2004), companies rated maturity levels two or three are not receiving comparable ratings when switching to XP development processes.
Finally, (Ahern et al., 2001) believe CMMI will evolve into a single representation. They suggest initiating either does not generate any distinct advantages. They offer two scenarios Partial Staging and a Unified CMMI Model. Both models represent a belief that the more than 1500 pages of the Staged and Continuous models can be streamlined or downsized. The first method suggests defining a common language where some processes are staged and others are continuous. The second scenario advocates simplifying the models by defining process areas that can be applied to any area, be it project management or engineering.
Personally, the CMMI is like a nation with a new constitution. It is well to have a written document to rely upon, but quite often, the responsible parties will rely more on personal experience than a formal document. The same is true with software companies. For as long as there have been document about the Software Development Life Cycle and the CMM/CMMI have been around, companies still rely on the proven process rather than adapt the codified ISO 9000 or the CMMI. They despite what the document state rely on the best programmer when the program has processing errors, the best telephony engineer when there are connectivity errors. Experience has taught, even though Teletech adapted the ISO 9000; it was still business as usual in the operation center at the USPS call center.
References
Ahern, D. M., Clouse, A., & Turner, R. (2001). CMMI Distilled: A Practical Introduction to Integrated Process Improvement. Boston, MA: Addison-Wesley.
Barnett, R. (1994). Quality in Business. Business Date, 2(2), 1-5.
Carnegie-Mellon (2002 August). Capability Maturity Model Integration Version 1.1 Software Engineering (CMMI-SW, V1.1) Continuous Representation (ESC-TR-2002-028). Retrieved February 8, 2005 from http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr028.pdf
Chrissis, M. B., Konrad, M., & Shrum, S. (2003, July 11). Introduction to CMMI. Retrieved January 23, 2005, from Addison-Wesley Web Site: http://www.awprofesional.com/articles/printerfriedly.asp?=98146
Curtis, B., Hefley, W. E., & Miller, S. A. (2002, February 15). Overview of the. Retrieved January 23, 2005, from Addison-Wesley Web Site: http://www.awprofessional.com/articles/printerfriendly.asp?p=25349
Fowler, M. (2003, April). The New Methodologies. Retrieved January 30, 2005, from MartinFowler.Com Web Site: http://www.martinfowler.com/articles/newMethodology.html
Guibert, C. (2004, October 15). CMMI STAGED. Retrieved February 27, 2005, from Web Idea Tree Web Site: http://chrguibert.free.fr/cmmi/text/176411b-1106.php
Hamilton, M., & Harris, K. (2001, November 9). The Software Life Cycle. Retrieved January 25, 2005, from Prentice Hall Web Site: http://www.phptr.com/articles/printerfriendly.asp?p=24016
International Software Benchmarking Standards Group. (2004, November 17). CMMI and the ISBSG. Retrieved February 28, 2005, from International Software Benchmarking Standards Group Web Site: http://www.isbsg.org/isbsg.nsf/weben/CMMI LeVasseur, C. (2005). Describing the Capability Maturity Model. Retrieved January 25, 2005, from Gartner Group Web Site: http://www4.gartner.com/4_decision_tools/measurement/measure_it_articles/2003_0424/desr...
Pfleeger, S. L. (2001). Software Engineering: Theory and Practices (2nd Ed.). Upper Saddle River, NJ: Prentice Hall.
Radding, A. (2002, February 4). Extremely Agile Programming. Computer World, 36, 42.
Reifer, D. J. (2004, March 15). XP and the CMM. Retrieved March 13, 2005, from Computer. Org: IEEE Software Web Site: http://www.computer.org/software/homepage/2003/s3man.htm
Senge, P. (1994). The Fifth Discipline Fieldbook: Strategies and Tools for Building a Learning Organization. New York: Currency-Doubleday.
The Software Engineering Institute. (2005, January 5). What Is Software Engineering? Retrieved January 29, 2005, from Carnegie Mellon University Web Site: http://www.sei.cmu.edu/about/overview/whatis.html
Tomayko, J. E., & Hazzan, O. (2004). Human Aspects of Software Engineering. Hingham, MA: Charles River Media.
Voas, J. (2000). Sorting out Six Sigma and the CMM. IEEE Software 0740 - 7459, 17(3), 11-13.
West, M. (2004). Real Process Improvement Using the CMMI. Portland, OR: CRC Press. Retrieved March 2, 2005, from IEEE Computer Org. Web Site: http://ieee-cs.books24x7.com/viewer.asp?bookid=8769&chunkid=0214377957 Figures
Figure 1 Software Engineering Institute's Levels of maturity 6
Figure 2 - CMMI Staged Representation Maturity Level Components 19
Figure 3 Continuous Representation Process Areas 24
Figure-4 Capability Level Profiles 28
Tables Table 1 Software Life Cycle 10
If you need to type anything after the reference list then start it on this page
|
