The Capability Maturity Model ( CMM ) is a development model created in 1986 after a study of data collected from organizations that contracted with the U.S. Department of Defense , who funded the research. 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.
53-647: The model's aim is to improve existing software development processes, but it can also be applied to other processes. In 2006, the Software Engineering Institute at Carnegie Mellon University developed the Capability Maturity Model Integration , which has largely superseded the CMM and addresses some of its drawbacks. The Capability Maturity Model was originally developed as a tool for objectively assessing
106-766: A user . The process is more encompassing than programming , writing code , in that it includes conceiving the goal, evaluating feasibility, analyzing requirements , design , testing and release . The process is part of software engineering which also includes organizational management , project management , configuration management and other aspects. Software development involves many skills and job specializations including programming , testing , documentation , graphic design , user support , marketing , and fundraising . Software development involves many tools including: compiler , integrated development environment (IDE), version control , computer-aided software engineering , and word processor . The details of
159-412: A deadline. Software analysis begins with a requirements analysis to capture the business needs of the software. Challenges for the identification of needs are that current or potential users may have different and incompatible needs, may not understand their own needs, and change their needs during the process of software development. Ultimately, the result of analysis is a detailed specification for
212-522: A general and powerful tool for understanding and then improving general business process performance. Watts 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
265-549: A general model of the maturity of process (e.g., IT service management processes) in IS/IT (and other) organizations. A maturity model can be viewed as a set of structured levels that describe how well the behaviors, practices and processes of an organization can reliably and sustainably produce required outcomes. A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there
318-481: A process area. Generic goals and practices are a part of every process area. A process area is satisfied when organizational processes cover all of the generic and specific goals and practices for that process area. Generic goals and practices are a part of every process area. Each process area is defined by a set of goals and practices. These goals and practices appear only in that process area. CMMI for Development, Version 1.2 contains 22 process areas indicating
371-483: A result, the growth was accompanied by growing pains: project failure was common, 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. Individuals such as Edward Yourdon , Larry Constantine , Gerald Weinberg , Tom DeMarco , and David Parnas began to publish articles and books with research results in an attempt to professionalize
424-442: 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 CMMI has thus been used by different organizations as
477-511: Is a framework that provides the viewpoints on the system and its environment , to be used in the software development process . It is a graphical representation of the underlying semantics of a view. The purpose of viewpoints and views is to enable human engineers to comprehend very complex systems and to organize the elements of the problem around domains of expertise . In the engineering of physically intensive systems, viewpoints often correspond to capabilities and responsibilities within
530-408: Is a popular way of managing changes made to the software. Whenever a new version is checked in, the software saves a backup of all modified files. If multiple programmers are working on the software simultaneously, it manages the merging of their code changes. The software highlights cases where there is a conflict between two sets of changes and allows programmers to fix the conflict. A view model
583-497: Is also used as a model to aid in business processes generally, and has also been used extensively worldwide in government offices, commerce, and industry. In the 1980s, 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
SECTION 10
#1732775386599636-449: Is correctly incorporated with the newer software. Design involves choices about the implementation of the software, such as which programming languages and database software to use, or how the hardware and network communications will be organized. Design may be iterative with users consulted about their needs in a process of trial and error . Design often involves people expert in aspect such as database design , screen architecture, and
689-833: Is essential to success. This is more easily achieved if the team is small, used to working together, and located near each other. Communications also help identify problems at an earlier state of development and avoid duplicated effort. Many development projects avoid the risk of losing essential knowledge held by only one employee by ensuring that multiple workers are familiar with each component. Software development involves professionals from various fields, not just software programmers but also individuals specialized in testing, documentation writing, graphic design , user support, marketing , and fundraising. Although workers for proprietary software are paid, most contributors to open-source software are volunteers. Alternately, they may be paid by companies whose business model does not involve selling
742-399: Is helpful for new developers to understand the project when they begin working on it. In agile development, the documentation is often written at the same time as the code. User documentation is more frequently written by technical writers . Accurate estimation is crucial at the feasibility stage and in delivering the product on time and within budget. The process of generating estimations
795-422: Is inefficient, difficult to understand, or lacking documentation on its functionality. These standards are especially likely to break down in the presence of deadlines. As a result, testing, debugging, and revising the code becomes much more difficult. Code refactoring , for example adding more comments to the code, is a solution to improve the understandability of code. Testing is the process of ensuring that
848-597: Is made up of the process areas in Level 2 and Level 3) Maturity Level 4 - Quantitatively Managed Maturity Level 5 - Optimizing The process areas below and their maturity levels are listed for the CMMI for Acquisition model: Maturity Level 2 - Managed Maturity Level 3 - Defined Maturity Level 4 - Quantitatively Managed Maturity Level 5 - Optimizing There are two categories of goals and practices: generic and specific. Specific goals and practices are specific to
901-440: Is often delegated by the project manager . Because the effort estimation is directly related to the size of the complete application, it is strongly influenced by addition of features in the requirements—the more requirements, the higher the development cost. Aspects not related to functionality, such as the experience of the software developers and code reusability, are also essential to consider in estimation. As of 2019 , most of
954-432: Is often used to break down the customer's requirements into pieces that can be implemented by software programmers. The underlying logic of the program may be represented in data-flow diagrams , data dictionaries , pseudocode , state transition diagrams , and/or entity relationship diagrams . If the project incorporates a piece of legacy software that has not been modeled, this software may be modeled to help ensure it
1007-401: Is robust to heavy levels of input or usage), integration testing (to ensure that the software is adequately integrated with other software), and compatibility testing (measuring the software's performance across different operating systems or browsers). When tests are written before the code, this is called test-driven development . Production is the phase in which software is deployed to
1060-475: Is something in common that can be used as a basis for comparison. In the case of the CMM, for example, the basis for comparison would be the organizations' software development processes. The model involves five aspects: 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
1113-426: Is to ensure effective service system performance and ensure that resources are provided and used effectively to support service requirements. Specific Practices by Goal Purpose The purpose of Causal Analysis and Resolution (CAR) is to identify causes of selected outcomes and take action to improve process performance. Specific Practices by Goal Purpose The purpose of Configuration Management (CM)
SECTION 20
#17327753865991166-534: Is to establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams. Specific Practices by Goal Purpose The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization's processes and process assets. Specific Practices by Goal Purpose The purpose of Organizational Performance Management (OPM)
1219-512: Is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. Specific Practices by Goal Purpose The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. Specific Practices by Goal Purpose The purpose of Integrated Project Management (IPM)
1272-489: Is to establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization's set of standard processes. Specific Practices by Goal Purpose The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability used to support management information needs. Specific Practices by Goal Purpose The purpose of Organizational Process Definition (OPD)
1325-471: The programming language ). Documentation comes in two forms that are usually kept separate—that intended for software developers, and that made available to the end user to help them use the software. Most developer documentation is in the form of code comments for each file, class , and method that cover the application programming interface (API)—how the piece of software can be accessed by another—and often implementation details. This documentation
1378-646: The stages of growth model for IT organizations. Watts Humphrey began developing his process maturity concepts during the later stages of his 27-year career at IBM. Active development of the model by the US Department of Defense Software Engineering Institute (SEI) began in 1986 when Humphrey joined the Software Engineering Institute located at Carnegie Mellon University in Pittsburgh, Pennsylvania after retiring from IBM. At
1431-500: The CMM was not necessarily mandatory for successful software development. The software process framework documented 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: Software development Software development is the process of designing and implementing a software solution to satisfy
1484-416: The CMMI for Development model: Maturity Level 2 - Managed Maturity Level 3 - Defined Maturity Level 4 - Quantitatively Managed Maturity Level 5 - Optimizing The process areas below and their maturity levels are listed for the CMMI for Services model: Maturity Level 2 - Managed Maturity Level 3 - Defined (this includes the process areas that make up the previous levels; Maturity Level 3
1537-810: The Software Engineering Institute. The full representation of the Capability Maturity Model 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 published in July 1993. The CMM was published as a book in 1994 by the same authors Mark C. Paulk, Charles V. Weber, Bill Curtis , and Mary Beth Chrissis. The CMMI model's application in software development has sometimes been problematic. Applying multiple models that are not integrated within and across an organization could be costly in training, appraisals, and improvement activities. The Capability Maturity Model Integration (CMMI) project
1590-493: The ability of government contractors' processes to implement a contracted software project. The model is based on the process maturity framework first described in IEEE Software and, later, in the 1989 book Managing the Software Process by Watts Humphrey . It was later published as an article in 1993 and as a book by the same authors in 1994. Though the model comes from the field of software development , it
1643-529: The aspects of product and service development that are to be covered by organizational processes. For a summary of process areas for each model, see these quick reference documents available on the SEI website: Purpose The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement. Specific Practices by Goal Purpose The purpose of Capacity and Availability Management (CAM)
Capability Maturity Model - Misplaced Pages Continue
1696-489: The available methodologies are best suited to specific kinds of projects, based on various technical, organizational, project, and team considerations. Another focus in many programming methodologies is the idea of trying to catch issues such as security vulnerabilities and bugs as early as possible ( shift-left testing ) to reduce the cost of tracking and fixing them. In 2009, it was estimated that 32 percent of software projects were delivered on time and budget, and with
1749-423: The code executes correctly and without errors. Debugging is performed by each software developer on their own code to confirm that the code does what it is intended to. In particular, it is crucial that the software executes on all inputs, even if the result is incorrect. Code reviews by other developers are often used to scrutinize new code added to the project, and according to some estimates dramatically reduce
1802-408: The end user. During production, the developer may create technical support resources for users or a process for fixing bugs and errors that were not caught earlier. There might also be a return to earlier development phases if user needs changed or were misunderstood. Software development is performed by software developers , usually working on a team. Efficient communications between team members
1855-430: The engineering organization. Fitness functions are automated and objective tests to ensure that the new developments don't deviate from the established constraints, checks and compliance controls. Intellectual property can be an issue when developers integrate open-source code or libraries into a proprietary product, because most open-source licenses used for software require that modifications be released under
1908-477: The full functionality. An additional 44 percent were delivered, but missing at least one of these features. The remaining 24 percent were cancelled prior to release. Software development life cycle refers to the systematic process of developing applications . The sources of ideas for software products are plentiful. These ideas can come from market research including the demographics of potential new customers, existing customers, sales prospects who rejected
1961-407: The number of bugs persisting after testing is complete. Once the code has been submitted, quality assurance —a separate department of non-programmers for most large companies—test the accuracy of the entire software product. Acceptance tests derived from the original software requirements are a popular tool for this. Quality testing also often includes stress and load checking (whether the software
2014-440: The organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief". Within each of these maturity levels are Key Process Areas which characterise that level, and for each such area there are five factors: goals, commitment, ability, measurement, and verification. These are not necessarily unique to CMMI, representing — as they do — the stages that organizations must go through on
2067-403: The performance of servers and other hardware. Designers often attempt to find patterns in the software's functionality to spin off distinct modules that can be reused with object-oriented programming . An example of this is the model–view–controller , an interface between a graphical user interface and the backend . The central feature of software development is creating and understanding
2120-416: The process areas are the same in these three models. In CMMI models, the process areas are organized in alphabetical order according to their acronym. However, process areas can be grouped according to maturity levels or process area categories. 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
2173-463: The process used for a development effort varies. The process may be confined to a formal, documented standard , or it can be customized and emergent for the development effort. The process may be sequential, in which each major phase (i.e. design, implement and test) is completed before the next begins, but an iterative approach – where small aspects are separately designed, implemented and tested – can reduce risk and cost and increase quality. Each of
Capability Maturity Model - Misplaced Pages Continue
2226-424: The product that developers can work from. Software analysts often decompose the project into smaller objects, components that can be reused for increased cost-effectiveness, efficiency, and reliability. Decomposing the project may enable a multi-threaded implementation that runs significantly faster on multiprocessor computers. During the analysis and design phases of software development, structured analysis
2279-466: The product, other internal software development staff, or a creative third party. Ideas for software products are usually first evaluated by marketing personnel for economic feasibility, fit with existing channels of distribution, possible effects on existing product lines, required features , and fit with the company's marketing objectives. In the marketing evaluation phase, the cost and time assumptions become evaluated. The feasibility analysis estimates
2332-503: The project's return on investment , its development cost and timeframe. Based on this analysis, the company can make a business decision to invest in further development. After deciding to develop the software, the company is focused on delivering the product at or below the estimated cost and time, and with a high standard of quality (i.e., lack of bugs) and the desired functionality. Nevertheless, most software projects run late and sometimes compromises are made in features or quality to meet
2385-553: 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. 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 B. Crosby in his book "Quality
2438-547: The same license. As an alternative, developers may choose a proprietary alternative or write their own software module. Process area The Capability Maturity Model Integration (CMMI) defines a process area as, "a cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area." Both CMMI for Development v1.3 and CMMI for Acquisition v1.3 identify 22 process areas, whereas CMMI for Services v1.3 identifies 24 process areas. Many of
2491-427: The software that implements the desired functionality. There are various strategies for writing the code. Cohesive software has various components that are independent from each other. Coupling is the interrelation of different software components, which is viewed as undesirable because it increases the difficulty of maintenance . Often, software programmers do not follow industry best practices, resulting in code that
2544-403: The software, but something else—such as services and modifications to open source software. Computer-aided software engineering (CASE) is tools for the partial automation of software development. CASE enables designers to sketch out the logic of a program, whether one to be written, or an already existing one to help integrate it with new code or reverse engineer it (for example, to change
2597-533: The software-development processes. In the 1980s, 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 Software Engineering Institute (SEI). The first application of a staged maturity model to IT was not by CMU/SEI, but rather by Richard L. Nolan , who, in 1973 published
2650-520: The tools for estimating the amount of time and resources for software development were designed for conventional applications and are not applicable to web applications or mobile applications . An integrated development environment (IDE) supports software development with enhanced features compared to a simple text editor . IDEs often include automated compiling , syntax highlighting of errors, debugging assistance, integration with version control , and semi-automation of tests. Version control
2703-522: The way to becoming mature. 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. Between 2008 and 2019, about 12% of appraisals given were at maturity levels 4 and 5. The model was originally intended to evaluate the ability of government contractors to perform a software project. It has been used for and may be suited to that purpose, but critics pointed out that process maturity according to
SECTION 50
#17327753865992756-509: Was formed to sort out the problem of using multiple models for software development processes, thus the CMMI model has superseded the CMMI model, though the CMMI model continues to be a general theoretical process capability model used in the public domain. In 2016, the responsibility for CMMI was transferred to the Information Systems Audit and Control Association (ISACA). ISACA subsequently released CMMI v2.0 in 2021. It
2809-460: Was upgraded again to CMMI v3.0 in 2023. CMMI now places a greater emphasis on the process architecture which is typically realized as a process diagram. Copies of CMMI are available now only by subscription. The CMMI was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. Though it comes from the area of software development, it can be, has been, and continues to be widely applied as
#598401