December 23, 2009 at 22:02CMMI Model
Hello everybody! Finally, I'm on Habré. I will try to immediately begin to benefit if not the whole community, then at least some part of it :)
I was quite surprised to find that there is practically no information about the CMMI model on Habr, except for a couple of references here and here .
In the West, large orders for software development have long been trusted only to companies that have been certified for compliance with any international standard, often it becomes the CMMI model. Although the authors of this model themselves repeatedly repeat that this is not a standard, but just a collection of recommendations for improving processes within an organization.
Wikipedia gives the following definition:
Actually, just CMM first appeared, and CMMI was the result of the consistent development of the original model, while absorbing a number of others. In the mid-1980s, the US Department of Defense faced the problem of improving the quality of software developed for their order. Agree, you yourself would be calmer to live, knowing that not a single American rocket will accidentally fly towards your home? In addition, since the money was budgetary, and the budget was usually planned and not rubber, in addition to the quality of development, the contractor was also required to complete the order on time and within the established budget.
The problem was solved as follows: by creating a model for which all potential executors of the order of the Ministry of Defense were evaluated. The task of developing this model was entrusted to the Software Engineering Institute, created on the basis of Carnegie Mellon University, which in turn is located in the glorious city of Pittsburgh, Pennsylvania.
To create this model, an analysis was made of the key activities performed during software development and the risks associated with them. We analyzed both best practices - practices that allowed us to successfully avoid or mitigate a particular risk, and worst practices - typical mistakes, the commission of which leads to problems in quality, failure to meet deadlines and exceeding budgets. For each key activity (or goal), the model offers a number of practices that can remove or significantly reduce the corresponding project risks. And all the activities were grouped in the so-called process areas. In 1987, a prototype of the future model appeared - in fact, a questionnaire that contained a total of 85 process and 16 technological questions, the answers to which determined the evaluated company to one of five levels of maturity.
Over time, only the number and content of process areas changed. But the concept of maturity levels is just what has not changed in this model for more than 20 years.
Maturity level is the main, final indicator of assessment according to the CMMI model. Maturity
Processescharacterized by randomness, reactivity, unpredictability. Despite this, very often the organizations at this stage of development produce fairly high-quality products. In this case, as a rule, the budget and development time of these products are exceeded. The high-quality products of these organizations are not produced through sustainable and well-established processes, but thanks to the titanic efforts of individuals. If such people leave, it is very difficult to repeat successful projects. At this stage, it is very difficult to predict the performance of the processes taking place in the organization. At level 1, the production process (and with it all the processes) seems to be an amorphous entity, almost a black box, the idea of the processes is very limited, too much effort is spent on clarifying the development status of the project and the current progress of work.
In principle, for small companies developing their own projects or small projects on order - this is acceptable. But they do not need any CMMI model. This model shows itself in all its glory when developing really large projects. And so we go further up the ladder of maturity levels.
Maturity Level 2- controlled level. At this stage, the basic processes are described; they may be used repeatedly. In other words, the projects carried out by the organization meet the requirements. Processes are manageable, they are planned, executed, measured and controlled. However, processes still have some reactivity in their essence. At level 2, customer requirements and intermediate products are monitored, and basic project management practices are established. These tools allow you to manage the project, but give a fragmented view of it. In fact, the production process can be represented as a sequence of black boxes and a real vision of the project is present only at intermediate stages.
Maturity Level 3- certain level. In this case, the processes are defined. Established standards within the organization. At this stage, the processes are described not at the level of an individual project, but at the level of the entire organization. There is a more detailed description of all processes in which the relationships and dependencies are better disclosed, the knowledge of which improves management. At this level - level 3 - the inside of our black boxes becomes visible. This internal structure reflects the way in which the organization’s standard production process is applied.
Maturity Level 4- quantitatively controlled level. At this stage, all the goals of the previous levels have been achieved. Subpractices have been selected which, when using statistical methods and other quantitative techniques, allow controlling the quality of the processes. The most important difference between this stage and the previous one is the predictability of the efficiency of processes and the ability to manage it (efficiency). At level 4, certain processes are quantitatively controlled using appropriate tools and techniques.
Maturity level 5 - level of continuous improvement (optimization) of processes. At this stage, we have accurate characteristics for evaluating the effectiveness of business processes, which allows us to constantly and effectively improve business processes by developing existing methods and techniques and introducing new ones.
Process areas are what the whole model consists of. CMMI defines 22 process areas. For each of the process areas, there are a number of goals that must be achieved when implementing CMMI in this process area. Some goals are unique - they are called special. Common goals apply to several process areas. Goals are achieved through practice; just like goals, practices are divided into special and general.
And here is a list of process areas with a brief transcript of each name:
Using the CMMI model allows the organization to evaluate the effectiveness of processes, establish priority areas for their improvement, and implement these improvements.
The introduction of SMM / CMMI allows to improve the structure and quality of processes (the main problems in software development are management problems, not technical problems), to ensure a consistently high quality of development and master processes that can serve as the basis for increasing competitive ability and further development and expansion of the company .
CMM / CMMI is based on the concept of a process. The adoption of this concept helps to avoid the natural tendency for many organizations to blame people's failures. Dismissing employees is not a solution. Over the past decades, revolutionary changes in technology have occurred, but the problems of successful project implementation have remained. In this aspect, technology is also not a solution to the problem. The value of the process is that it helps to capture and use the highest achievements in future projects. It is on this premise that CMMI is based.
SMM / CMMI are models, i.e. simplified view of the world. The SMM / CMMI models contain essential elements of processes that provide different aspects of the activity, and can be used as a guide for the development and improvement of production processes. The official publications of the model emphasize that it does not represent processes or their description. Real processes in any organization depend on many factors, including the specifics of the business, the structure and size of the organization.
To summarize early. It is rather an advertising, review article that does not describe the mechanics of introducing the model. If interest arises, I will begin to describe in more detail its structure. Most likely, the articles will be a somewhat free translation of the official documentation from SEI with explanatory comments.
I was quite surprised to find that there is practically no information about the CMMI model on Habr, except for a couple of references here and here .
In the West, large orders for software development have long been trusted only to companies that have been certified for compliance with any international standard, often it becomes the CMMI model. Although the authors of this model themselves repeatedly repeat that this is not a standard, but just a collection of recommendations for improving processes within an organization.
What is CMMI?
Wikipedia gives the following definition:
Capability Maturity Model Integration (CMMI) - A comprehensive model of productivity and maturity - a set of models (methodologies) for improving processes in organizations of different sizes and activities. CMMI contains a set of recommendations in the form of practices, the implementation of which, according to the developers of the model, allows you to realize the goals necessary for the full implementation of certain areas of activity.
Where did this model come from?
Actually, just CMM first appeared, and CMMI was the result of the consistent development of the original model, while absorbing a number of others. In the mid-1980s, the US Department of Defense faced the problem of improving the quality of software developed for their order. Agree, you yourself would be calmer to live, knowing that not a single American rocket will accidentally fly towards your home? In addition, since the money was budgetary, and the budget was usually planned and not rubber, in addition to the quality of development, the contractor was also required to complete the order on time and within the established budget.
The problem was solved as follows: by creating a model for which all potential executors of the order of the Ministry of Defense were evaluated. The task of developing this model was entrusted to the Software Engineering Institute, created on the basis of Carnegie Mellon University, which in turn is located in the glorious city of Pittsburgh, Pennsylvania.
To create this model, an analysis was made of the key activities performed during software development and the risks associated with them. We analyzed both best practices - practices that allowed us to successfully avoid or mitigate a particular risk, and worst practices - typical mistakes, the commission of which leads to problems in quality, failure to meet deadlines and exceeding budgets. For each key activity (or goal), the model offers a number of practices that can remove or significantly reduce the corresponding project risks. And all the activities were grouped in the so-called process areas. In 1987, a prototype of the future model appeared - in fact, a questionnaire that contained a total of 85 process and 16 technological questions, the answers to which determined the evaluated company to one of five levels of maturity.
Over time, only the number and content of process areas changed. But the concept of maturity levels is just what has not changed in this model for more than 20 years.
By the way, maturity levels ...
Maturity level is the main, final indicator of assessment according to the CMMI model. Maturity
Processescharacterized by randomness, reactivity, unpredictability. Despite this, very often the organizations at this stage of development produce fairly high-quality products. In this case, as a rule, the budget and development time of these products are exceeded. The high-quality products of these organizations are not produced through sustainable and well-established processes, but thanks to the titanic efforts of individuals. If such people leave, it is very difficult to repeat successful projects. At this stage, it is very difficult to predict the performance of the processes taking place in the organization. At level 1, the production process (and with it all the processes) seems to be an amorphous entity, almost a black box, the idea of the processes is very limited, too much effort is spent on clarifying the development status of the project and the current progress of work.
In principle, for small companies developing their own projects or small projects on order - this is acceptable. But they do not need any CMMI model. This model shows itself in all its glory when developing really large projects. And so we go further up the ladder of maturity levels.
Maturity Level 2- controlled level. At this stage, the basic processes are described; they may be used repeatedly. In other words, the projects carried out by the organization meet the requirements. Processes are manageable, they are planned, executed, measured and controlled. However, processes still have some reactivity in their essence. At level 2, customer requirements and intermediate products are monitored, and basic project management practices are established. These tools allow you to manage the project, but give a fragmented view of it. In fact, the production process can be represented as a sequence of black boxes and a real vision of the project is present only at intermediate stages.
Maturity Level 3- certain level. In this case, the processes are defined. Established standards within the organization. At this stage, the processes are described not at the level of an individual project, but at the level of the entire organization. There is a more detailed description of all processes in which the relationships and dependencies are better disclosed, the knowledge of which improves management. At this level - level 3 - the inside of our black boxes becomes visible. This internal structure reflects the way in which the organization’s standard production process is applied.
Maturity Level 4- quantitatively controlled level. At this stage, all the goals of the previous levels have been achieved. Subpractices have been selected which, when using statistical methods and other quantitative techniques, allow controlling the quality of the processes. The most important difference between this stage and the previous one is the predictability of the efficiency of processes and the ability to manage it (efficiency). At level 4, certain processes are quantitatively controlled using appropriate tools and techniques.
Maturity level 5 - level of continuous improvement (optimization) of processes. At this stage, we have accurate characteristics for evaluating the effectiveness of business processes, which allows us to constantly and effectively improve business processes by developing existing methods and techniques and introducing new ones.
... and process areas.
Process areas are what the whole model consists of. CMMI defines 22 process areas. For each of the process areas, there are a number of goals that must be achieved when implementing CMMI in this process area. Some goals are unique - they are called special. Common goals apply to several process areas. Goals are achieved through practice; just like goals, practices are divided into special and general.
And here is a list of process areas with a brief transcript of each name:
- Requirements Management The
management of requirements for project products or product components in order to identify inconsistencies between requirements and project plans. - Project Planning (Project Planning)
Development and maintenance of plans determining the development of the project. - Monitoring and control of the project (Project Monitoring and Control)
Providing an understanding of the stage of development of the project in order to take corrective actions in case of serious deviation from the plan. - Management of contracts with suppliers (Supplier Agreement Management)
Management of the acquisition of goods and services from external suppliers with which contracts are concluded. - Measurement and Analysis
Design and maintain a measurement capability used to support information management needs. - Evaluation (guaranteeing) of the quality of goods and processes (Process and Product Quality Assurance)
Providing support and management in accordance with the objectives of the processes and related products. - Configuration Management
Installation and maintenance of the integrity of work products through the use of configuration identification, configuration control and configuration audit. - Requirements Development
Collection and analysis of customer requirements for products and product components. - Technical Solution
Development, design and implementation of solutions to relevant requirements. Decisions, design and implementations are expressed by products, product components and processes associated with these products. - Product Integration Product Integration
Assembling (mounting) a product from its components, checking the quality of integration, its functionality and product release. - Verification
Ensure that the selected work products meet the requirements. - Validation
Demonstration that a product and its components correspond to its intended use in the intended environment. - Focusing on organization processes (Organization Process Focus)
Establish and maintain an understanding of organization processes and process assets, identify, plan and implement improvements related to these areas. - Description of Organization Processes (Organization Process Definition)
Establish and maintain an array of organization processes that can be used. - Organizational Training
Improving the knowledge and abilities of people to fulfill their roles effectively and efficiently. - Project Integration Management (Integrated Project Management)
Installation and project management and involvement of all interested parties in an integrated and defined process. This area also affects the overall vision of the project by the development team. - Risk Management
Identify potential problems before they occur. In this regard, risk reduction processes can be planned and carried out at any stage of product or process development. - Integrated Teaming (Integrated Teaming)
Formation and maintenance of integrated teams for the development of work products (work products). - Integrated Supplier Management
Monitoring of new products, evaluating the sources of products that can meet project requirements and using this information to select suppliers. - Decision Analysis and Resolution Decision Analysis and Resolution
Development of solutions based on a structured approach that allows you to evaluate alternative solutions based on established criteria. - Organizational Environment for Integration
Providing infrastructure for integrated product and process development and managing people (staff) for integration - Organizational Process Performance
Establishing and maintaining a quantitative understanding of the performance of a set of standardized organization processes and providing information about the performance of processes and models for quantitative management of an organization’s projects. - Quantitative Project Management
Quantitatively manage a specific process in order to achieve the quality and performance goals set by the project. - Organizational Innovation and Deployment
The selection and implementation of innovations and improvements, which are measurable, improve organizational processes and technologies. - Causal Analysis and Resolution
Identification of the causes of defects and other problems and taking actions to prevent their occurrence in the future
And why do we need this model?
Using the CMMI model allows the organization to evaluate the effectiveness of processes, establish priority areas for their improvement, and implement these improvements.
The introduction of SMM / CMMI allows to improve the structure and quality of processes (the main problems in software development are management problems, not technical problems), to ensure a consistently high quality of development and master processes that can serve as the basis for increasing competitive ability and further development and expansion of the company .
CMM / CMMI is based on the concept of a process. The adoption of this concept helps to avoid the natural tendency for many organizations to blame people's failures. Dismissing employees is not a solution. Over the past decades, revolutionary changes in technology have occurred, but the problems of successful project implementation have remained. In this aspect, technology is also not a solution to the problem. The value of the process is that it helps to capture and use the highest achievements in future projects. It is on this premise that CMMI is based.
SMM / CMMI are models, i.e. simplified view of the world. The SMM / CMMI models contain essential elements of processes that provide different aspects of the activity, and can be used as a guide for the development and improvement of production processes. The official publications of the model emphasize that it does not represent processes or their description. Real processes in any organization depend on many factors, including the specifics of the business, the structure and size of the organization.
Total?
To summarize early. It is rather an advertising, review article that does not describe the mechanics of introducing the model. If interest arises, I will begin to describe in more detail its structure. Most likely, the articles will be a somewhat free translation of the official documentation from SEI with explanatory comments.