Capability Maturity Model CMM The CMM a registered
Capability Maturity Model (CMM) • • • The CMM (a registered service mark of Carnegie Mellon University, CMU) is a development model created after study of data collected from organizations that contracted with the U. S. Department of Defense, who funded the research. This model became the foundation from which Carnegie Mellon created the Software Engineering Institute (SEI). The term "maturity" relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes. When the model is applied to an existing organization's softwaredevelopment processes, it allows an effective approach toward improving them. Eventually it became clear that the model could be applied to other processes. This gave rise to a more general concept that is applicable to any other business also. The CMM was originally developed as a tool for objectively assessing the ability of government contractors‘ processes to perform a contracted software project. MMS Prepared by Prakash Vaidya 1
• • In the 1960 s, the use of computers grew more widespread, more flexible and less costly. Organizations began to adopt computerized information systems, and the demand for software development grew significantly. Many processes for software development were in their infancy, with few standard or "best practice" approaches defined. As a result, the growth was accompanied by growing pains: project failure was common, and the field of computer science was still in its early years, and the ambitions for project scale and complexity exceeded the market capability to deliver adequate products within a planned budget. In the 1980 s, several US military projects involving software subcontractors ran over-budget and were completed far later than planned, if at all. In an effort to determine why this was occurring, the United States Air Force funded a study at the SEI. Watts Humphrey began developing his process maturity concepts during 1980’s while he was working in IBM. Active development of the model by the US Department of Defense and SEI began in 1986 when Humphrey joined the SEI (at Pennsylvania) after retiring from IBM. At the request of the U. S. Air Force he began formalizing his Process Maturity Framework to aid the U. S. Department of Defense in evaluating the capability of software contractors as part of awarding contracts. MMS Prepared by Prakash Vaidya 2
• • Evolution of CMM The result of the Air Force study was a model for the military to use as an objective evaluation of software subcontractors' process capability maturity. • Humphrey based this framework on the earlier Quality Management Maturity Grid developed by Philip Crosby in his book "Quality is Free". Humphrey's approach differed because of his unique insight that organizations mature their processes in stages based on solving process problems in a specific order. Humphrey based his approach on the staged evolution of a system of software development practices within an organization, rather than measuring the maturity of each separate development process independently. The CMM has thus been used by different organizations as a general and powerful tool for understanding and then improving general business process performance. Humphrey's Capability Maturity Model (CMM) was published in 1988 and as a book in 1989, in Managing the Software Process. Organizations were originally assessed using a process maturity questionnaire and a Software Capability Evaluation method devised by Humphrey and his colleagues at the SEI. • • MMS Prepared by Prakash Vaidya 3
• • • The First Version of CMM The full representation of the CMM as a set of defined process areas and practices at each of the five maturity levels was initiated in 1991, with Version 1. 1 being completed in January 1993. The CMM was published as a book in 1995 by its primary authors, Mark C. Paulk, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis. Applications of CMM Though CMM comes from the area of software development, it can be, has been, and continues to be widely applied as a general model of the maturity of process (e. g. , IT service management processes) in IS/IT (and other) organizations. Maturity Model - Details A maturity model can be viewed as a set of structured levels that describe how well the behaviours, practices and processes of an organization can reliably and sustainably produce required outcomes. A maturity model may provide following MMS – – – a place to start, the benefit of a community’s prior experiences a common language and a shared vision a framework for prioritizing actions a way to define what improvement means for your organization. Prepared by Prakash Vaidya 4
– a benchmark for comparison and – as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In this case, the basis for comparison would be the organizations' software development processes. • • CMM Structure Maturity Levels: a 5 -level process maturity continuum - where the uppermost (5 th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement. Key Process Areas: a Key Process Area identifies a cluster of related activities that, when performed together, achieve a set of goals considered important. Goals: the goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area. MMS Prepared by Prakash Vaidya 5
• • Common Features: common features include practices that implement and institutionalize a key process area. There are five types of common features: commitment to perform, ability to perform, activities performed, measurement and analysis, and verifying implementation. Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the areas. Levels There are five levels defined along the continuum of the model and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief“. – Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process. It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes. MMS Prepared by Prakash Vaidya 6
MMS – Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted. It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress. – Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions). It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i. e. , they are the ASIS processes) and used to establish consistency of process performance across the organization. – Managed - the process is quantitatively managed in accordance with agreed-upon metrics. It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e. g. , for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level. Prepared by Prakash Vaidya 7
• • Optimizing - process management includes deliberate process optimization/improvement. It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements. At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the process (for example, to shift the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives. Within each of these maturity levels are KPA which characterise that level, and for each such area there are five factors: – – – • goals, commitment, ability, measurement, and verification. These factors are not necessarily unique to CMM. They represent the stages that organizations must go through on the way to becoming mature. MMS Prepared by Prakash Vaidya 8
• • • The model provides a theoretical continuum along which process maturity can be developed incrementally from one level to the next. Skipping levels is not allowed/feasible. Critics of CMM Critics pointed out that process maturity according to the CMM was not necessarily mandatory for successful software development. Real-life examples where the CMM was arguably irrelevant to successful software development include many shrinkwrap companies (also called commercial-off-the-shelf or "COTS" firms or software package firms). Such firms would have included Claris, Apple, Symantec, Microsoft, and Lotus. Though these companies have successfully developed their software, they have not considered or defined or managed their processes as the CMM described as level 3 or above, and so would have fitted level 1 or 2 of the model. This did not appear to have frustrated the successful development of their software. MMS Prepared by Prakash Vaidya 9
• • Software Process Framework The software process framework documentation is intended to guide those wishing to assess an organization's or project's consistency with the Key Process Areas. For each maturity level there are five checklist types: – Policy- Describes the policy contents and KPA goals recommended by the Key Process Areas. – Standard- Describes the recommended content of select work products described in the Key Process Areas. – Process- Describes the process information content recommended by the KPAs. These are refined into checklists for: • roles, entry criteria, inputs, activities, outputs, exit criteria, reviews and audits, work products managed and controlled, measurements, documented procedures, training, and tools. – Procedure- Describes the recommended content of documented procedures described in the KPAs. – Level Overview- Provides an overview of an entire maturity level. These are further refined into checklists for: • Key Process Areas purposes, goals, policies, and standards; process descriptions; procedures; training; tools; reviews and audits; work products; measurements MMS Prepared by Prakash Vaidya 10
• • Capability Immaturity Model (CIMM) It provides a contrast to the Capability Maturity Model (CMM). The ability of an organization to carry out its mission on time and within budget is claimed to improve as the CMM level increases. The CIMM asserts that organizations can and do occupy levels below CMM level 1. It describes situations that arise in dysfunctional organizations. These situations are not uncommon and occur in organizations of all kinds undertaking software development, i. e. they are more properly in practice characterizations of the management of specific projects since they can occur even in organizations with positive CMM levels. Levels – Level 0 - Negligent – The organization pays lip service, often with excessive fanfare, to implementing software engineering processes, but lacks the will to carry through the necessary effort. Whereas CMM level 1 assumes eventual success in producing software, CIMM level 0 organizations generally fail to produce any product, or do so by abandoning regular procedures in favor of crash programs. MMS Prepared by Prakash Vaidya 11
– -1 – Obstructive: – Processes, however inappropriate and ineffective, are implemented with rigor and tend to obstruct work. Adherence to process is the measure of success in a Level -1 organization. Any actual creation of viable product is incidental. – -2 - Contemptuous (disapproving) – While processes exist, they are routinely ignored by engineering staff and those charged with overseeing the processes are regarded with hostility. Measurements are fudged to make the organization look good. – -3 - Undermining – Not content with faking their own performance, undermining organizations routinely work to downplay and sabotage the efforts of rival organizations, especially those successfully implementing processes common to CMM level 2 and higher. This is worst where company policy causes departments to compete for scarce resources, which are allocated to the loudest advocates. MMS Prepared by Prakash Vaidya 12
• • Capability Maturity Model Integration(CMMI) It is a process improvement approach whose goal is to help organizations improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. Currently supported version is CMMI Version 1. 3. CMMI in software engineering and organizational development is a process improvement approach that provides organizations with the essential elements for effective process improvement. CMMI is registered in the U. S. Patent and Trademark Office by Carnegie Mellon University. According to the SEI, CMMI helps – – • integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes. CMMI currently addresses three areas of interest: – Product and service development — CMMI for Development (CMMI-DEV), – Service establishment, management, — CMMI for Services (CMMI-SVC), and – Product and service acquisition — CMMI for Acquisition (CMMI-ACQ). MMS Prepared by Prakash Vaidya 13
• • • CMMI was developed by a group of experts from industry, government, and the SEI at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization. CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest, such as the development of hardware products, the delivery of all kinds of services, and the acquisition of products and services. The word "software" does not appear in definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It is not as specific to software engineering as its predecessor, the Software CMMI is the successor of the capability maturity model (CMM) or Software CMM. The CMM was developed from 1987 until 1997. In 2002, CMMI Version 1. 1 was released, Version 1. 2 followed in August 2006, and CMMI Version 1. 3 in November 2010. Some of the major changes in CMMI V 1. 3 are the support of Agile Software Development, improvements to high maturity practices and alignment of the representation (staged and continuous). MMS Prepared by Prakash Vaidya 14
• • CMMI Representation CMMI exists in two representations: - continuous and staged. The continuous representation is designed to allow the user to focus on the specific processes that are considered important for the organization's immediate business objectives, or those to which the organization assigns a high degree of risks. The staged representation is designed to provide a standard sequence of improvements, and can serve as a basis for comparing the maturity of different projects and organizations. The staged representation also provides for an easy migration from the SW-CMM to CMMI Model Framework Depending on the CMMI areas of interest (acquisition, services, development) used, the process areas it contains will vary. Process areas are the areas that will be covered by the organization's processes. The table below lists the process areas that are present in all CMMI areas of interest in CMMI Version 1. 3. This collection of sixteen process areas is called the CMMI core process areas. MMS Prepared by Prakash Vaidya 15
MMS Abbr. Name Area Mat. Level CAR Causal Analysis and Resolution Support 5 CM Configuration Management Support 2 DAR Decision Analysis and Resolution Support 3 IPM Integrated Project Management Pr. Mgmt 3 MA Measurement and Analysis Support OPD Organizational Process Definition Pr. Mgmt 3 OPF Organizational Process Focus Pr. Mgmt 3 OPM Org. Performance Management Pr. Mgmt 5 OPP Org. Process Performance Pr. Mgmt 4 OT Organizational Training Pr. Mgmt 3 PMC Project Monitoring and Control Prj. Mgm 2 PP Project Planning Prj. Mgm 2 PPQA Proc & Prod Quality Assurance Support 2 QPM Quantitative Project Management Prj. Mgm 4 REQM Requirements Management Prj. Mgm 2 RSKM Risk Management Prj. Mgm 3 Prepared by Prakash Vaidya 2 16
• • Maturity levels in CMMI for development / acquisition There are five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. The process areas below and their maturity levels are listed for the CMMI for Development model: – – • • • Maturity Level 2 – Managed Maturity Level 3 – Defined Maturity Level 4 - Quantitatively Managed Maturity Level 5 - Optimizing Appraisal An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the type of appraisal, the organization can be awarded a maturity level rating (1 -5) or a capability level achievement profile. Many organizations find value in measuring their progress by conducting an appraisal. Appraisals are typically conducted for one or more of the following reasons: – To determine how well the organization’s processes compare to CMMI best practices, and to identify areas where improvement can be made – To inform external customers and suppliers of how well the organization’s processes compare to CMMI best practices – To meet the contractual requirements of one or more customers MMS Prepared by Prakash Vaidya 17
• • • Applications of CMMI The SEI published that 60 organizations measured increases of performance in the categories of cost, schedule, productivity, quality and customer satisfaction. The increase in performance varied between 14% (customer satisfaction) and 62% (productivity). However, the CMMI model mostly deals with what processes should be implemented, and not so much with how they can be implemented. These results do not guarantee that applying CMMI will increase performance in every organization. A small company with few resources may be less likely to benefit from CMMI; this view is supported by the process maturity profile. Of the small organizations (<25 employees), 70. 5% are assessed at level 2: Managed, while 52. 8% of the organizations with 1001– 2000 employees are rated at the highest level (5: Optimizing). MMS Prepared by Prakash Vaidya 18
- Slides: 18