CMMI 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 of it :)
I was quite surprised to find that on Habré there is almost no information about the CMMI model, except for a couple of mentions here and here .
In the West, large software development orders have long been entrusted only to companies that have been certified for compliance with any international standard, often the CMMI model. Although the authors of this model themselves repeatedly repeat that this is not a standard, but merely a collection of recommendations for improving the processes within the organization.
Wikipedia gives the following definition:
Actually, at first CMM just appeared, and CMMI was the result of the consistent development of the original model, which absorbed a number of others. In the mid-1980s, the US Department of Defense was faced with the problem of improving the quality of software developed for their orders. Agree, you yourself would be quieter to live, knowing that not a single American rocket will fly by accident in the direction of your home? In addition, since the money was budget, and the budget is 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 assigned 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 of key activities performed during software development and the associated risks was carried out. Were analyzed as the best practices - practices that allowed us to successfully avoid or mitigate one or another risk, and the worst practices - typical mistakes, the commission of which leads to problems in quality, disruption of terms and budget overruns. For each key activity (or goal), the model offers a number of practices that allow you to remove or substantially reduce the corresponding project risks. And all activities were grouped in the so-called. process areas. In 1987, a prototype of the future model appeared - in fact, a questionnaire that contained only 85 process questions 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 exactly what has not changed in this model for more than 20 years.
The level of maturity is the main, final assessment indicator for the CMMI model.
The processes of the first level of maturity are characterized by chaos, reactivity, unpredictability. Despite this, very often organizations that are at this stage of development produce fairly high-quality products. In this case, as a rule, the budget and development time of these products is exceeded. The quality products of these organizations are not made at the expense of stable and streamlined processes, but through 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 occurring 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, an understanding of the processes is very limited, an excessive amount of effort is spent on figuring out the status of the project and the current progress.
In principle, for small companies developing their own projects or small projects on order is acceptable. But for them, and do not need any model CMMI. This model shows itself in all its glory when developing really big projects. And so we go further up the ladder levels of maturity.
Maturity level 2 is a manageable level. At this stage, the main processes are described, they may be used repeatedly. In other words, projects executed by the organization meet the requirements. Processes are managed, planned, executed, measured and monitored. However, processes still have a certain amount of 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 fragmentary picture of it. In fact, the production process can be represented by a sequence of black boxes and the real vision of the project is present only at intermediate stages.
Maturity level 3 - a 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 whole organization. There is a more detailed description of all processes, in which connections and dependencies are better disclosed, knowledge of which allows for improved management. At this level - level 3 - the inside of our black boxes becomes visible. This internal structure reflects the way in which the organization uses a standard production process.
The level of maturity 4 is a quantitatively controlled level. At this stage, achieved all the goals of the previous levels. Subpractices have been selected that, when using statistical methods and other quantitative techniques, allow monitoring the quality of process performance. The most important difference of this stage from the previous one is the predictability of the efficiency of the processes and the possibility of its (efficiency) control. At level 4, certain processes are quantitatively controlled using appropriate means and techniques.
The level of maturity 5 is the level of continuous improvement (optimization) of processes. At this stage, we have accurate characteristics of 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 multiple process areas. Goals are achieved through the implementation of practices; just as goals, practices are divided into special and general.
And here is a list of process areas with a brief decoding of the name of each:
Using the CMMI model allows an organization to evaluate the effectiveness of processes, set priorities for their improvement, as well as implement these improvements.
The introduction of SMM / CMMI can 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 to master processes that can serve as a basis for increasing competitive ability and further development and expansion of the company .
At the core of CMM / CMMI is the notion of process. The adoption of this concept helps to avoid the tendency, which is natural for many organizations, to blame people for their failures. Dismissing employees is not a solution. Over the past decades, there have been revolutionary changes in technology, but the problems of successful project implementation remain. In this aspect, technology is also not a solution. The value of the process is that it helps to catch and use the highest achievements in future projects. It is on this premise that CMMI is based.
CMM / CMMI are models, i.e. simplified view of the world. The CMM / CMMI models contain essential elements of processes that provide different sides of the activity, and can be used as a guide for developing and improving production processes. The official publications of the model emphasize that it does not constitute 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 sum up early. It is rather an advertising, review article that does not describe the mechanics of the introduction of the model. If there is interest, 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 on Habré there is almost no information about the CMMI model, except for a couple of mentions here and here .
In the West, large software development orders have long been entrusted only to companies that have been certified for compliance with any international standard, often the CMMI model. Although the authors of this model themselves repeatedly repeat that this is not a standard, but merely a collection of recommendations for improving the processes within the 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 to realize the goals necessary for the full implementation of certain areas of activity.
Where did this model come from?
Actually, at first CMM just appeared, and CMMI was the result of the consistent development of the original model, which absorbed a number of others. In the mid-1980s, the US Department of Defense was faced with the problem of improving the quality of software developed for their orders. Agree, you yourself would be quieter to live, knowing that not a single American rocket will fly by accident in the direction of your home? In addition, since the money was budget, and the budget is 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 assigned 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 of key activities performed during software development and the associated risks was carried out. Were analyzed as the best practices - practices that allowed us to successfully avoid or mitigate one or another risk, and the worst practices - typical mistakes, the commission of which leads to problems in quality, disruption of terms and budget overruns. For each key activity (or goal), the model offers a number of practices that allow you to remove or substantially reduce the corresponding project risks. And all activities were grouped in the so-called. process areas. In 1987, a prototype of the future model appeared - in fact, a questionnaire that contained only 85 process questions 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 exactly what has not changed in this model for more than 20 years.
By the way, maturity levels ...
The level of maturity is the main, final assessment indicator for the CMMI model.
The processes of the first level of maturity are characterized by chaos, reactivity, unpredictability. Despite this, very often organizations that are at this stage of development produce fairly high-quality products. In this case, as a rule, the budget and development time of these products is exceeded. The quality products of these organizations are not made at the expense of stable and streamlined processes, but through 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 occurring 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, an understanding of the processes is very limited, an excessive amount of effort is spent on figuring out the status of the project and the current progress.
In principle, for small companies developing their own projects or small projects on order is acceptable. But for them, and do not need any model CMMI. This model shows itself in all its glory when developing really big projects. And so we go further up the ladder levels of maturity.
Maturity level 2 is a manageable level. At this stage, the main processes are described, they may be used repeatedly. In other words, projects executed by the organization meet the requirements. Processes are managed, planned, executed, measured and monitored. However, processes still have a certain amount of 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 fragmentary picture of it. In fact, the production process can be represented by a sequence of black boxes and the real vision of the project is present only at intermediate stages.
Maturity level 3 - a 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 whole organization. There is a more detailed description of all processes, in which connections and dependencies are better disclosed, knowledge of which allows for improved management. At this level - level 3 - the inside of our black boxes becomes visible. This internal structure reflects the way in which the organization uses a standard production process.
The level of maturity 4 is a quantitatively controlled level. At this stage, achieved all the goals of the previous levels. Subpractices have been selected that, when using statistical methods and other quantitative techniques, allow monitoring the quality of process performance. The most important difference of this stage from the previous one is the predictability of the efficiency of the processes and the possibility of its (efficiency) control. At level 4, certain processes are quantitatively controlled using appropriate means and techniques.
The level of maturity 5 is the level of continuous improvement (optimization) of processes. At this stage, we have accurate characteristics of 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 multiple process areas. Goals are achieved through the implementation of practices; just as goals, practices are divided into special and general.
And here is a list of process areas with a brief decoding of the name of each:
- Requirements Management
Management of requirements imposed on project products or product components in order to identify inconsistencies between requirements and project plans. - Project Planning
Development and maintenance of plans defining the development of the project. - Project Monitoring and Control
Providing an understanding of the project development stage with a view to taking corrective actions in the event of a serious departure from the plan - Supplier Contract Management (Supplier Agreement Management)
Manage the acquisition of goods and services from external suppliers with whom contracts are concluded. - Measurement and Analysis
Develop and maintain the 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 work products. - Configuration Management (Configuration Management)
Establishing and maintaining the integrity of work products as a result of the use of configuration identification, configuration control and configuration audit. - Requirements Development
Collection and analysis of customer requirements for products and components of products. - Technical Solution
Development, design and implementation of solutions for relevant requirements. Solutions, designs and implementations are expressed in products, product components and related product processes. - Product Integration
Assembling (assembling) a product from its components, checking the quality of integration, its functionality and product release. - Verification
Ensuring 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 Process (Organization Process Focus)
Establishing and maintaining an understanding of the organization's processes and process assets, identifying, planning and implementing improvements related to these areas. - Organization Process Definition Description
Establishment and maintenance of a possible to use array of organization processes. - Organizational Training (Organizational Training)
Increasing the knowledge and ability of people to fulfill their roles effectively and efficiently. - Integrated Project Management
Installation and project management and involvement of all stakeholders 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. Therefore, risk reduction processes can be planned and carried out at any stage of product or process development. - Integrated teams (developers) (Integrated Teaming)
Formation and maintenance of integrated teams for the development of work products (work products). - Integrated Supplier Management (Integrated Supplier Management)
Monitoring of new products, evaluation of sources of products that can meet the requirements for the project and the use of this information to select suppliers. - 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 (Organizational Environment for Integration)
Providing infrastructure for integrated product and process development and managing people (staff) for integration - Productive Organizational Process (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
Manage a specific process quantitatively in order to achieve the quality and performance goals set by the project. - Organizational Innovation and Deployment (Organizational Innovation and Deployment)
Selecting and implementing innovations and improvements that are measurable improves organizational processes and technologies. - Cause Analysis and Resolution (Causal Analysis and Resolution)
Identifying 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 an organization to evaluate the effectiveness of processes, set priorities for their improvement, as well as implement these improvements.
The introduction of SMM / CMMI can 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 to master processes that can serve as a basis for increasing competitive ability and further development and expansion of the company .
At the core of CMM / CMMI is the notion of process. The adoption of this concept helps to avoid the tendency, which is natural for many organizations, to blame people for their failures. Dismissing employees is not a solution. Over the past decades, there have been revolutionary changes in technology, but the problems of successful project implementation remain. In this aspect, technology is also not a solution. The value of the process is that it helps to catch and use the highest achievements in future projects. It is on this premise that CMMI is based.
CMM / CMMI are models, i.e. simplified view of the world. The CMM / CMMI models contain essential elements of processes that provide different sides of the activity, and can be used as a guide for developing and improving production processes. The official publications of the model emphasize that it does not constitute 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 sum up early. It is rather an advertising, review article that does not describe the mechanics of the introduction of the model. If there is interest, 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.
Source: https://habr.com/ru/post/79130/
All Articles