Models for assessing the maturity of software systems developers organizations. Standards ISO, SW-CMM
In November 1986, the American Software Engineering Institute (SEI), together with Miter Corporation, began developing a development process maturity survey. software, which was intended to help improve their internal processes.
The development of this review was prompted by a request from the US federal government for a method for evaluating subcontractors for software development. The real problem was the inability to manage large projects. In many companies, projects were delivered significantly late and over budget. It was necessary to find a solution to this problem.
In September 1987, SEI released short review software development processes with a description of their maturity levels, as well as a questionnaire designed to identify areas in the company in which improvements were needed. However, most companies considered this questionnaire as finished model, as a result of which, after 4 years, the questionnaire was transformed into a real model, the Capability Maturity Model for Software (CMM). The first version of the CMM (Version 1.0), released in 1991, was revised in 1992 by the participants of a working meeting, which was attended by about 200 software specialists, and members of the developer society.
As a result, the CMM standard, Version 1.1, was released, which is still actively used throughout the world.
Rice. 1. Global impact of SMM use
The reasons for this interest in SMM are clear. Despite the fact that both the software developers themselves and their management are often very aware of their persistent problems, they cannot agree on what changes the company needs in the first place. Without developing a unified improvement strategy, management cannot find mutual understanding with its employees regarding the highest priority improvement tasks. To achieve the maximum result from the efforts spent on process improvement, it is necessary to have a phased development strategy that will improve the maturity of development processes gradually, in an evolutionary way.
Continuous process improvement is based on the gradual cultivation of the company's culture, and not on the implementation of revolutionary innovations. The CMM provides a blueprint for this incremental improvement, divided into 5 levels of process maturity. These 5 levels are a scale for assessing the level of maturity of software development processes in a company and for measuring their parameters.
Rice. 2. The principle of progressive increase in the level of maturity: opportunities for the development of the organization
Here are the main characteristics of each level:
- Initial - The development process is chaotic. Few of the processes are defined and the success of the projects depends on the individual actors.
- Repeatable - Established basic project management processes: cost tracking, work schedule and functionality. Streamlined some of the processes needed to repeat previous achievements on similar projects (projects with similar applications).
- Defined - Software development and project management processes are described and implemented in single system company processes. All projects use a standard software development and support process for the organization, adapted to a specific project.
- Managed - Collects detailed quantitative data on the functioning of development processes and quality final product. The significance and dynamics of these data are analyzed.
- Optimizing - Continuous improvement of processes is based on quantitative data on processes and on the trial implementation of new ideas and technologies.
Introduction to SW-CMM
(Improving the maturity of software development processes based on the Software Engineering Institute Capability Maturity Model for Software)
The course is intended for:
For executives of software development companies, heads of departments and projects of software development and quality professionals who are interested in:
2.1 Cost, duration and results. Industry statistics
2.2 Return on investment in CMM
3.1 TQM (Total Quality Management), SPI (Software Process Improvement) and Best Business Practices as the basis of CMM
3.2 Basic concepts TQM. Application of TQM approaches in the production of software products
3.3 Benefits and risks of the CMM Process Improvement Model
3.4 Concept of process. The main components of the process approach
3.5 Process maturity levels
9.1 System of standards for the IT industry (Roadmap)
9.2 Relationship of ISO to CMM, Rational Unified Process, project management
9.3 CMM application for small organizations
9.4 What is not in the SMM
9.5 Documents and processes
10.1 Final review of the SW-CMM. Distribution in the world. Main difficulties
10.2 CMMI (Capability Maturity Model Integration) - further development CMM models
A set of slides, practical training materials, additional materials for self-study.
A complete set of documents on SW-CMM (the text of the standard, assessment methods, industry statistics, examples of documents)
Practical course on the technology of implementing the SW-CMM model in IT companies
Brief annotation:
This course is aimed at helping companies independently and competently plan and carry out work on the implementation of a process maturity improvement model, help avoid common mistakes and problems encountered during implementation.
The course is intended for:
The course is intended for managers of enterprises and departments involved in software development, project managers, quality managers and others interested in improving the quality of their developments and in certifying their process for CMM.
| 17. To CMM via ISO? |
The quality of software products is perhaps one of the most serious problems in the software industry. Quality is much more than just the absence of errors. It implies a set of different characteristics: reliability, hackability, adaptability, compatibility, maintainability, portability, efficiency, and so on. It is not surprising that there are such a variety of quality standards in the software industry.
Quality was easy to measure: either we got paid or we didn't.
Dean Leffingwell, Don Widrig.
Software requirements management
CMM/CMMI
Perhaps the most famous quality standard should be considered the Capability Maturity Model (CMM) - a model for assessing the level of maturity of development processes along with its derivatives. It was created by the SEI (Software Engineering Institute), which is funded by the US Department of Defense and is a structural unit of Carnegie Mellon University. The first official version of the standard was released in 1993, although work on it began much earlier - its main provisions were published as early as 1986.
The success of CMM was predetermined by several factors. This standard was one of the first, initially taking into account the specifics of software development. It turned out to be quite simple and transparent both for understanding and for use, and regulated “what”, and not “how” to do, and therefore was suitable for various development methodologies and did not impose any restrictions on documentation standards, tools, environment and languages used in projects. And, perhaps, the main factor that predetermined the popularity of CMM was the cooperation of SEI with the US Department of Defense, which de facto meant the use of the standard in the implementation of projects commissioned by this department.
The CMM model (Table 1) provides for five levels of maturity, each of which corresponds to certain key process areas (Key Process Areas, KPA).
| level number | Level name | Key Process Areas |
| 1 | Elementary | If the organization is at this level, then there are no key process areas for it |
| 2 | recurring | Software Configuration Management Software Quality Assurance Contractor Contract Management Project Progress Monitoring Software Project Planning Requirements Management |
| 3 | Definite | Expert assessments. Coordination of interactions between project groups. Engineering software product.Software integrated management.Personnel training program.Definition of the organizational process.Scope of the organizational process |
| 4 | Managed | Software quality management. Process management based on quantitative methods |
| 5 | Optimizable | Process change management.Technological change management.Defect prevention |
The division into levels and the definition of KPA for each of them allows the consistent implementation of the CMM, using the standard as a guide, which can ensure continuous improvement in the development process.
The CMM standard proved to be very successful, and subsequently a whole series of standards was created on its basis (Table 2). Moreover, it received a new name - SW-CMM (Capability Maturity Model for Software), which more accurately reflects its position in a fairly large family of standards.
| Name of the standard | Description |
| System Engineering CMM (SE-CMM) | Focuses on system engineering issues - product development (requirements analysis, product systems design and integration) and their production (production line planning and operation) |
| Trusted CMM (T-CMM) | Designed for servicing sensitive and closed software systems that require high quality software assurance |
| System Security Engineering CMM (SSE-CMM) | Focuses on security aspects of software engineering, ensures a secure development process, including the security of members of the creation team |
| People CMM (P-CMM) | Considers issues of personnel development in software organizations |
| Software Acquisition CMM (SA-CMM) | Covers the acquisition of software products from external organizations |
| Integrated Product Development CMM (IPD-CMM) | Serves as an environment for integrating development efforts across all life cycle stages and from every department within the company |
However, the practical application of the CMM series standards has shown that they do not provide unconditional success in software development. These standards were not well coordinated with each other - the simultaneous implementation of various modifications of the CMM could be quite a challenge and bewildered the specialists of the organizations that faced it.
Also, a significant problem of CMM is the need to "align" all processes. If an organization is attempting to certify to a certain level, then it must ensure that the appropriate level is applied to all of its processes. Even if the specifics, methodology or development features do not have certain processes to be performed, certification requires this.
Another problem is caused by the position that CMM standards have taken in the modern software industry. Since an organization with a high level in accordance with the CMM must provide higher software product performance than those certified at lower levels, the standard has become used as a selection criterion for participation in tenders for software development or outsourcing projects. The demand for certified organizations has given rise to a proposal for "quick and painless certification".
This situation has become possible due to the shortcomings of the certification process. Not the entire organization as a whole is subject to certification, but only a specific project. Nothing prevents an organization from creating a "exemplary" project, which is carried out taking into account all the requirements of high levels. CMM standard, obtain the appropriate level of certification, and declare that all products meet that level of the standard.
Solve most problems CMM is designed new standard SEI - Capability Maturity Model Integrated (CMMI) - An integrated model for assessing the level of maturity of development processes. The CMMI standard was originally created in such a way as to combine existing options CMM and eliminate any contradictions in its practical application in various areas of activity of high-tech companies.
In order to eliminate the need to "align" the processes of the organization and be more adapted to its business needs, and not vice versa, the CMMI standard has two forms of presentation - the classic, multi-level, corresponding to the CMM, and the new, continuous. The continuous form of presentation does not consider maturity levels (Maturity Levels), but Capability Levels, which are evaluated for individual process areas (Process Areas, PA). In table. 3 gives a mapping of the maturity levels of the CMM standard, as well as the maturity levels of the layered CMMI presentation and the capability levels of the continuous CMMI presentation.
SEI is moving away from CMM and is actively promoting CMMI in return, promising to tighten control over the certification process, introducing new classes to reduce costs and make it more attractive to smaller organizations; ensuring compatibility with ISO standards. However, the fact remains that in modern conditions the presence of a certificate of a certain level of CMM / CMMI is not such a significant factor as it was several years ago, and is accepted without additional questions, except perhaps in projects carried out by government order.
5 evolutionary stages in the management of organizational processes. Explanation of the Capability Maturity Model. CMM
The CM-CEI Capability Maturity Model is an organizational model that describes the 5 evolutionary stages (levels) at which processes in an organization are managed.
Originally created for software development, the point of the Capability Maturity Model is that an organization should be able to accept and support its software applications. The model also suggests concrete steps and initiatives to help the organization grow to the next level.
The 5 Stages of the Capability Maturity Model
Initial (processes are ad hoc, chaotic, or in fact few of them are defined) Repeatable (basic processes are established and there is discipline to stick to those processes) Defined (all processes are defined, documented) , unified and integrated) Managed (processes are measured by aggregating detailed data on processes and their quality) Optimizing (Optimizing) ( continuous development process through quantitative feedback and testing of new ideas and technologies)
Software development model
The CMM describes the principles and practices that underlie the concept of software process maturity. They are designed to help software development and sales firms improve the sophistication of their software processes in an evolutionary way. Starting from ad hoc, chaotic processes, moving on to mature, disciplined software processes. The focus is on identifying key process areas and exemplary practices that can constitute disciplined software processes. The concept of CMM maturity creates a context in which:
- Practices can be repeated. If you do not repeat some operation, then you should not improve it. There are rules, procedures and practices that force an organization to implement and consistently execute. Organization Best Practices production work can be quickly distributed between groups. The practices are defined to allow exchange between projects, thus providing some standardization for the organization. Deviations in the execution of these methods are minimized. Quantitative goals are set for tasks; and measurements are established, produced and maintained to form the basis for evaluation. Practices are continuously improved to improve the capability (optimization).
The capability maturity model is useful not only for software development, but also for describing the evolutionary levels of organizations in general and describing the level of management that an organization has implemented or wants to achieve.
Structure of the Feature Development Model
- Maturity levels are a layered concept that provides the consistency of discipline that is needed to achieve continuous improvement. It is important to note here that an organization develops the ability to evaluate the consequences of a new practice, technology or tool. Therefore, it is not a matter of acceptance of these innovations, but rather of how these innovative efforts affect existing practices. It supports projects, groups and organizations by giving them a basis for making informed choices. Key Process Areas - A Key process area (KPA) defines a group of related activities that, when performed together, achieve a number of important goals. Objectives - The objectives of a key process area describe the provisions that must exist for that key process area. Regulations need to be implemented in an efficient and secure manner. The extent to which goals are met indicates what kind of capability the organization has established at that level of excellence. Objectives delineate the scope, boundaries, and purpose of each key process area. General Characteristics - General characteristics include practices that implement and institutionalize key process areas. These 5 types general characteristics include: Commitment to Perform, Ability to Perform, Initiatives to be Performed, Measurement and Analysis, and Implementation Control. Key Practices - Key Practices describe the infrastructure elements and practices that contribute most effectively to the implementation and institutionalization of key process areas.
Criteria for defining a process
Criteria for defining a process are a set of process elements that need to be included in a software process description in order for people to use them in practice. In order to establish criteria, you need to ask the question - "What information on the software process is needed for documentation?"
Organizations working in the field of development, delivery, implementation and maintenance of software and system integration are increasingly feeling that their competitiveness is based on quality and low cost, manufacturability.
The leaders of such organizations are not always able to form a strategy for improving and developing the technology of their company's activities; there are clearly not enough specialists on the labor market with the necessary qualifications. At the same time, international experience in the field of improving technological processes for the development and operation of software has not been sufficiently generalized and formalized for many years. Only in the early 1990s, the American Software Engineering Institute (SEI) formed a model of technological maturity of CMM organizations (Capability Maturity Model), defining the levels of technological maturity and their distinctive features. Over the course of a decade, CMM has been tested in a number of organizations, its effectiveness and reliability have been verified by ordering organizations, software vendors, custom software development companies, and offshore programming.
Today, in the west, a development company is practically experiencing great difficulty in obtaining orders if it is not certified by the SMM. Customers demand guarantees of the contractor's manufacturability, guarantees that the contractor cannot provide a low-quality service.
The assessment of the technological maturity of companies can be used:
the customer when selecting the best performers (for example, in a tender);
· software companies to systematically assess the state of their technological processes and select areas for their improvement;
· companies that decide to undergo an attestation to assess the "dimension of the disaster", i.e. your current state;
auditors to determine the standard certification procedure and conduct the necessary assessments;
· consulting firms involved in the restructuring of companies and services providers of information technology and related services.
As the technological maturity of an organization increases, the processes for creating and maintaining software become more standardized and consistent. At the same time, the formalization of processes makes it possible to standardize the expected results of their implementation and ensure the predictability of the results of project implementation.
Process maturity (software process maturity)- this is the degree of their manageability, controllability and effectiveness. Increasing technology maturity refers to the potential for increased process resilience and indicates the degree of efficiency and consistency in the use of software development and maintenance processes throughout the organization. The real use of processes is impossible without their documentation and bringing to the attention of the organization's personnel, without constant monitoring and improvement of their implementation. The capabilities of well-designed processes are fully defined. Increasing the technological maturity of processes means that the efficiency and quality of the results of their implementation can constantly increase.
In organizations that have reached technological maturity, the processes of creating and maintaining software take the status of a standard, are fixed in organizational structures and determine production tactics and strategy. Their introduction into the status of law entails the need to build the necessary infrastructure and create the required corporate culture industries that maintain the appropriate methods, operations, and procedures for doing business, even after those who created it all leave the organization.
The CMM model develops the provisions on the organization's quality system, forming the criteria for its perfection - five levels of technological maturity, which, in principle, can be achieved by the development organization. The highest - the fourth and fifth levels - is actually a characteristic of organizations that have mastered the methods of collective development, in which the processes of creating and maintaining software are comprehensively automated and technologically supported.
Since 1990, SEI, with the support of US government agencies and software development organizations, has constantly developed and improved this model, taking into account all the latest achievements in the field of creating and maintaining software.
CMM is a methodological material that defines the rules for the formation of a management system for the creation and maintenance of software and methods for the gradual and continuous improvement of production culture. The purpose of the SMM is to provide developer organizations with necessary instructions on the choice of a strategy for improving the quality of processes by analyzing the degree of their technological maturity and the factors that most affect the quality of products. By focusing attention on a small number of the most critical operations and systematically increasing the efficiency and quality of their implementation, an organization can thus achieve a steady continuous improvement in the culture of creating and maintaining software.
The CMM is a descriptive model in the sense that it describes the essential (or key) attributes that determine what level of technological maturity an organization is at. It is a normative model in the sense that a detailed description of the methodologies establishes the level of organization required to carry out projects of varying complexity and duration under contracts with US government agencies. CMM is not a prescription, it does not prescribe how an organization should develop. The CMM describes the characteristics of the organization for each level of technological maturity, without giving any instructions on how to move from level to level. It may take an organization several years to move from the first to the second level, and very little time to move from level to level further. The process of improving the software development technology is reflected in the strategic plans of the organization, its structure, technologies used, general social culture and management system.
At each level, requirements are established, under which stabilization of the most significant indicators of processes is achieved. The achievement of each level of technological maturity is the result of the appearance of a certain number of components in the processes of software development, which in turn leads to an increase in their productivity and quality. On fig. Figure 1.7 shows five levels of CMM technological maturity.
Rice. 1.7. Five Levels of SMM Technological Maturity
The inscriptions on the arrows define the features of improving processes when moving from level to level.
Levels from the second to the fifth can be characterized through operations aimed at standardizing and (or) modernizing the processes of creating software, and through the operations that make up the processes of its creation themselves. At the same time, the first level is, as it were, the base, the foundation for comparative analysis upper levels.
At level 1 (initial), the basic processes of creating and maintaining software are random and chaotic. The success of the project depends entirely on the individual efforts of the staff. At this level, as a rule, the organization does not have a stable environment necessary for creating and maintaining software.
The success of the project in this case, as a rule, depends entirely on the degree of energy and experience of the management and professional level performers. It may happen that an energetic leader overcomes all the obstacles in the project process and achieves the release of a truly viable software product. But after such a leader leaves his post, there is no guarantee that the next such project will be successful. In the absence of the necessary level of project management, even advanced technology will not be able to save the situation.
Processes at the first level are characterized by their unpredictability due to the fact that their composition, purpose and sequence in the process of project implementation change randomly depending on the current situation. As a result, allocated funds are overspent and work schedules are disrupted. Training capable and knowledgeable professionals in organizations is the main prerequisite for success at all levels of maturity, but at the first level it is the only opportunity to achieve at least any positive results.
At level 2 (the level of repeatable processes), project management processes provide ongoing control of the project cost, schedule, and functions performed. The discipline of the project is such that it is possible to predict the success of projects to create similar software products.
At this level, project planning and management of new projects is based on the experience of successfully completed similar projects. The main feature of the second level is the presence of formalized and documented effective project management processes, which allows using the positive experience of successfully completed projects. Effective processes are those that are documented, actually used, measurable, and capable of being upgraded. It is essential that personnel be trained in their use.
Each level of CMM, starting with the second, is characterized by the presence of a number of so-called key process groups (KPA). The CMM model contains 18 such groups, the latest version of the CMMI model contains 20 groups. Level 2 CMM is characterized by the presence of the following processes in the organization (their names correspond to CMMI):
requirements management;
configuration management;
project planning;
monitoring and control of the project;
management of contracts;
measurement and analysis;
ensuring the quality of the process and product.
Processes at the second level can be characterized as streamlined due to the fact that they are planned in advance and their implementation is strictly controlled, due to which predictability of project results is achieved. With the increase and complexity of projects, attention shifts from the technical aspects of their implementation to organizational and managerial aspects. The execution of processes requires people to work more effectively and coherently, which, in turn, requires the study of documented best practices in order to improve professional excellence.
At level 3 (the level of standardized processes), software development processes are documented, standardized and represent a single technological system that is mandatory for all departments of the organization. All projects use a single technology for creating and maintaining software that has been tested, approved and elevated to the status of a standard.
At this level, the following processes are added to the level 2 processes:
requirements specification;
product integration;
verification;
certification;
standardization of organization processes;
· education;
integrated project management;
· Management of risks;
Analysis and decision making.
The main criterion for using and, if necessary, adjusting processes at this level is to help management and technical specialists in improving the efficiency of project implementation. At this level, a special group is created in the organization responsible for the composition of the operations that make up the processes - the software engineering process group (SEPG).
On the basis of a single technology for each project, its own processes can be developed, taking into account its features. Such processes in CMM are called "project-oriented software development processes" (project "s defined software process).
The description of each process includes the conditions for its execution, input data, standards and procedures for execution, verification mechanisms (for example, expert opinions), output data, and termination conditions. The description of the process also includes information about the tools required to complete it and an indication of the role responsible for its execution.
The main purpose of level 4 (the level of managed processes) is the current control over processes. Management must ensure that processes are carried out within the specified quality. There may be inevitable losses and temporary peaks in measured results that require intervention, but overall the system must be stable.
At level 4, the following processes are added:
performance and productivity management;
Quantitative project management.
At this level, a detailed assessment of the quality of both the creation processes and the software product itself is applied in practice. In this case, quantitative evaluation criteria are applied.
Within the framework of the entire organization, a single program for quantitative control of the productivity of software creation and its quality is being developed. To facilitate the analysis of processes, a single database of processes for creating and maintaining software is created for all projects carried out in the organization. Universal methods are being developed for quantifying the productivity of processes and the quality of their implementation. This allows for quantitative analysis and evaluation of software creation and maintenance processes.
The results of the processes at the fourth level become predictable, because they are measurable and vary within the given quantitative restrictions. At this level, it becomes possible to plan in advance the specified quality of the processes and final products.
The main purpose of level 5 (the level of optimized processes) is the consistent improvement and modernization of the processes of creating and maintaining software. For the purpose of the planned modernization of software development technology, the organization creates special unit, whose main responsibilities are the collection of data on the implementation of processes, their analysis, the modernization of existing and the creation of new processes, their testing on pilot projects and giving them the status of enterprise standards.
At level 5, the following processes are added:
introduction of technological and organizational innovations;
cause-and-effect analysis and problem solving. The processes of creating and maintaining software are characterized by
as consistently improved, as the organization makes continuous efforts to modernize them. This improvement extends both to the identification of additional capabilities of the processes used, and to the creation of new optimal processes and the use of new technologies.
Innovations that can bring the greatest benefit are standardized and adapted into the technological system throughout the organization. The personnel involved in the implementation of the project analyzes the defects and identifies the causes of their occurrence. Software development processes are evaluated to prevent the recurrence of situations that lead to defects, and the results of the evaluation are taken into account in subsequent projects.
Each subsequent level additionally provides a more complete visibility of the processes of creating and maintaining software.
At the first level, processes are amorphous (“black boxes”), and their visibility is very limited. From the very beginning, the composition and purpose of operations are practically not defined, which creates significant difficulties in determining the status of the project and its progress. Requirements for the execution of processes are set uncontrollably. Software development in the eyes of managers (especially those who are not programmers themselves) sometimes looks like black magic.
At the second level, the fulfillment of user requirements and the creation of software are controlled, since the basis for the project management processes is defined. The process of creating software can be viewed as a sequence of "black boxes" that can be controlled at the transition points from one "box" to another - fixed stages. Even if the manager does not know what is being done "inside the box", it is precisely established what should be the result of the process, and the control points for its start and end are determined. Therefore, management can recognize problems at black-box interaction points and respond to them in a timely manner.
At the third level, the internal structure of the "black boxes" is defined, i.e. the tasks that make up the processes. The internal structure is the way in which standard processes in an organization are applied to specific projects. The management link and the executors know their roles and responsibilities within the project to the required level of detail. Management is prepared in advance for the risks that may arise during the implementation of the project. Since standardized and documented processes become "transparent" for review, employees who are not directly involved in the project can receive accurate information about its current status in a timely manner.
At the fourth level, the execution of processes is rigidly tied to tools, which makes it possible to determine quantitative characteristics their complexity and quality of performance. Managers, having an objective base of quantitative measurements, get the opportunity to accurately plan the stages and stages of the project, predict the progress of the project, and can timely and adequately respond to emerging problems. With the reduction of possible deviations from the given terms, cost and quality in the process of project implementation, their ability to predict results is constantly increasing.
At the fifth level, in order to improve the quality of products and increase the efficiency of its creation, work is constantly and systematically carried out to create new improved methods and technologies for creating software. Attention is drawn not only to already used, but also to new, more efficient processes and technologies. Managers can quantify the impact and effectiveness of changes in software development and maintenance technology.
The fourth and fifth levels are rare in the software industry. Thus, if several hundred companies in the world reached the third level, then there were 62 firms of the fifth level (according to SEI data for 2002), and 72 of the fourth. Some are not interested in advertising their organizational technologies, while others perform certification simply under pressure from the customer.
It takes ten years or more to reach the highest levels of SMM. But even level 3 allows you to boldly enter the international arena. To use SMM, a company does not need to look for employees with some unique abilities, it is enough for it to understand the general idea. The description of the CMM model specifies in detail what needs to be done in order to develop in accordance with this model. Any middle-class manager is capable of following the regulated actions of the CMM.
The latest version of CMM 1.1 is mainly aimed at large companies involved in the implementation of large projects, but it can also be used by groups of two or three people or individual programmers to complete small projects (up to three months). In such cases, the CMM model can play a vital role, since the receipt of new orders is largely determined by the quality of the implementation of previous projects. Small groups will be quite satisfied with level 2, since for a small project a deviation from the deadline of a couple of weeks is unimportant.
Since 2002, a special integration version of CMMI has been officially distributed. This is a new development of SEI, covering all aspects of the company's activities: from development and selection of a contractor to training, implementation and maintenance. In addition, the CMMI model is extended with approaches from systems engineering. This model included developments made during the design of CMM 2.0 (it was not completed), the main changes in which were aimed at clarifying processes for companies of the fourth and fifth levels, which is most relevant for large-scale American projects.
The CMM model is quite weighty and important, but it should not be used as the only basis that determines the entire software development process. It was intended primarily for companies that develop software for the US Department of Defense. These systems are characterized by their large size and long service life, as well as the complexity of the interface with hardware and other software systems. Rather large teams of programmers are working on the creation of such systems, which must comply with the requirements and standards developed by the Ministry of Defense.
The disadvantages of SMM include the following:
1. The model focuses solely on project management, and not on the process of creating a software product. The model does not take into account such important factors, as the use of certain methods, such as prototyping, formal and structural methods, static analysis tools, etc.
2. The model lacks risk and decision analysis, which prevents problems from being detected before they affect the development process.
3. The scope of the model is not defined, although the authors acknowledge that it is universal and suitable for all organizations. However, the authors do not make a clear distinction between organizations that may or may not implement SMM in their activities. Smaller companies find this model too bureaucratic. In response to these criticisms, process improvement strategies for small organizations have been developed.
main goal In creating the SMM model, it was the intention of the US Department of Defense to assess the capabilities of software vendors. At the moment, there are no clear requirements for achieving a certain level of development of development organizations. However, it is generally accepted that an organization that has reached a high level is more likely to win a tender for the supply of software. As an alternative to CMM, a generalized classification of technological maturity improvement processes is proposed, which is suitable for most organizations and software projects. It is possible to identify several common types improvement processes.
1. informal process. Does not have a clearly defined model of improvement. It can be successfully used by a separate development team
cov. The informality of the process does not preclude formal activities such as configuration management, but the activities themselves and their relationships are not predetermined.
2. Managed process. Has a prepared model that guides the improvement process. The model defines activities, their schedule, and the relationships between them.
3. Methodically sound process. It is assumed that certain methods have been put in place (for example, object-oriented design methods are systematically applied). For this type of process, process design and analysis support tools (CASE-tools) will be useful.
4. The process of direct improvement. It has a clearly defined goal of improving the technological process, for which there is a separate line in the budget of the organization and the norms and procedures for introducing innovations are defined. Part of such a process is the quantitative analysis of the improvement process.
This classification cannot be called clear and exhaustive - some processes can simultaneously belong to several types. For example, the informality of the process is the choice of the development team. The same team can choose a certain development methodology, while having all the opportunities for direct improvement of the process. This process is classified informal, methodically sound, direct improvement.
The need for this classification is due to the fact that it provides the basis for the comprehensive improvement of software development technology and enables the organization to choose different types of improvement processes. On fig. 1.8 shows the relationship between different types software systems and processes for improving their development.
Rice. 1.8. Applicability of improvement processes
Knowing the type of product being developed will make the correspondence between software systems and improvement processes shown in Fig. 1.8 useful in choosing process improvement. For example, you need to create a program to support the transition of software from one computer platform to another. Such a program has a fairly short lifespan, so its development does not require standards and special administration process of improvement, as in the creation of long-lived systems.
Many technological processes currently have CASE support, so they can be called supported processes. Methodically justified processes supported by analysis and design tools. The effectiveness of the support tool depends on the improvement process applied. For example, in an informal process, typical support tools (prototyping tools, compilers, debugging tools, word processors, etc.) may be used. It is unlikely that more specialized support tools will be used on an ongoing basis in informal processes.
The SMM model is not unique. Almost every big company develops its own technologies for creating software, sometimes these technologies become publicly available and very popular. The wide popularity of the HMM model is associated with its state support, but the actual effectiveness of the SMM is criticized by many leading experts. One of the main shortcomings of the HMM is associated with an unnecessarily rigid requirement not to deviate from the principles of this model, even if common sense suggests otherwise. Such claims to the possession of absolute truth cannot but arouse suspicion, therefore, among small and medium-sized companies, approaches that leave much more freedom for individual and collective creativity are more popular. The SPMN methodology discussed below occupies an intermediate place between rigid, "heavy", effective for large organizations solutions such as CMM and the most flexible technologies. She appears the best option for companies that, on the one hand, want to streamline their managerial activity, and on the other hand, they plan in the future to reach international level where CMM certification is highly desirable.
By using a defined software development process, organizations have a consistent blueprint for the process that they can tailor to their specific needs. Incompatible needs for customization and standardization can be dealt with by constructing the process structure as consisting of standard modules or "basic" steps, and the rules used to describe and establish relationships between these steps. In this case, adaptation is achieved by combining them in a process model.
As a rule, quality management of software projects is based on knowledge from three sources:
Software engineering (ACM, IEEE);
Project Management (PMI);
Quality (ASQ).
The Software Engineering Institute (SEI) at Carnegie Mallon University combines all three of these sources.
Feature maturity model (CapabilityMaturityModel, SMM), serves as a "framework" for the software development process. This model is action-based and reflects the best results of individuals working to improve the software development process and performing evaluative analysis of the process. In the following, we will refer to how the quality management of software projects corresponds to the SEI CMM model. Since the CMM model is well known in the software development community, there is no particular need to define it. We will present only a brief description of it in order to demonstrate the need for using the life cycle in the development process. Below is a brief generalized description of the levels of development of the functional capabilities of the HMM model.
The CMM model is a diagram in which development stages correspond to five levels of development of functionality, on the basis of which continuous improvement of the development process is carried out. Speaking about the level of development of functionality, they usually mean a strictly defined stage of development aimed at obtaining a complete software development process. By dividing the CMM model into five levels, priority is given to the improvement activities needed to complete the development of process functionality. These five levels can be briefly described by assigning the following characteristics to them.
Source. The software development process can be described as ad hoc, tailor-made, and sometimes chaotic. Only a small number of processes can be identified, and success depends on the individual effort and decisive action taken.
Repetitive. Core project management processes are created to track costs, schedule, and functionality. Here the necessary order of execution of the process is observed, designed to repeat the achievements obtained earlier in the implementation of similar projects.
Definite. All projects use a tested, customized version of the organization's standard software development process.
Managed. Detailed indicators of the software development process and the qualitative characteristics of the product are collected. Management of the process of developing software products is carried out at a quantitative level.
Optimization level. Continuous improvement in the development process is achieved through quantitative feedback.
This connection is achieved through the implementation of the process itself, as well as on the basis of innovative ideas and technologies. Each maturity level is broken down into several key process areas that indicate what actions still need to be taken to improve the software development process. Each key process area (keyprocessarea,KPA) defines a set of interrelated actions needed to optimize this process.
Level 2 KPAs address issues that arise during the execution of a software project that are related to the establishment of basic project management controls. At this stage of the discussion, we need to know that the iterative process (level 2) allows you to optimize the structuring and management in the organization. With such a definition, a common language is formed, and transition periods are facilitated when developers are included in the process, especially if they do not have enough experience in this area.
However, having a repetitive process (level 2) does not necessarily lead to a well-designed process. In general, process improvement occurs when an organization reaches Level 3. Level 3 refers to addressing both project-related and organizational issues as the organization establishes an infrastructure that provides effective software engineering and management for all projects. Two areas of the KPA, the definition of process organization and integrated program management, belong to the subject area life cycles.
Purpose of definition organizational structure The process area of CPA at Level 3 is to develop and maintain an easy-to-use set of software development process benefits that improve process efficiency across a range of projects. The definition of a process includes the development and maintenance of an organization's standard development process, as well as the associated value propositions of the process. The purpose of defining a process organizational structure is to develop and maintain a standard software development process for a given organization.
Activities that shape the process of building an organizational structure include documenting and maintaining descriptive characteristics. software development life cycles. The goal of integrated program management in the KPA area at level 3 is to combine software engineering and management activities into a coherently defined software development process resulting from the adaptation of the standard software development process in this organization and the associated valuable process properties described in " Defining a process at the level of its structure.
The CMM refers to a group of software process models developed on a broad base maintained by the software development community. Since we are dealing with a model, there is a simplification of the actual engineering process. Representing a standard, the CMM model identifies the capabilities of an organization belonging to the category of a certain degree of maturity.
Organizations using this model as a mechanism for measuring and improving processes should use an acceptable interpretation of process knowledge areas in terms of business objectives. When used as a process assessment and measurement tool, this model becomes a roadmap for successful process improvement. Generally speaking, the CMM model can be viewed as a set of well-articulated engineering and management concepts based on proven assurance principles. In the software development process, where knowledge needs to be properly valued and protected, quality assurance principles should be given considerable attention. SMM model not is a collection of prescriptions for all occasions. It does not specify how the organization should set the process attributes. Also, its application does not guarantee immediate success. The process of implementing improvements takes time and continuous effort throughout the organization. At the same time, executive management and allocated funds are of particular importance. The CMM model is difficult to classify as universal methodologies, when "one size fits all occasions." The first step in using this model is to customize the application maturity levels to suit your organization and existing set of projects. Other capability maturity models have been developed by the SEI that are applicable to organizational personnel, software acquisition, systems engineering, integrated software product development, and the personal software process.
Since software, like any other capital, can be represented in the form of materialized knowledge, and also due to the fact that knowledge is initially unsystematized, uncertain and, by and large, incomplete, any program can be represented as a process social learning. This process is implemented in the form of a dialogue, during which the necessary knowledge materializes in the form of a finished software product. At the same time, communication is carried out between users and developers, interaction between users and the required tools (technology) is implemented. This process is iterative, with the tools used forming the environment in which communications take place. Each new round of dialogue contributes to obtaining more and more useful knowledge from the involved specialists.
One of the main applications of the HMM model is to define what a process that has reached a certain degree of maturity means. As applied to software, we can say that a mature process has the following attributes:
Defined - indicates "the method required to complete the case";
Documented - designed in such a way that it can be known and used in the future;
Learned - documentation based learning;
Practical - can be applied in practice, and not put off indefinitely;
Maintained - available, revised and improved;
Controlled - the changes are approved by the "participants of the joint case";
Verified - the process is running correctly;
Checked - exactly the process that is needed is performed;
Measured - estimated performance is applied as a basis for process control and improvement;
Ability to improve - flexibility and ability to change.
Software engineering belongs to the area of key processes for level 3, i.e. "certain". Until 1968, the term "software engineering" was not used at all. Software engineering is a practical application of scientific knowledge to the process of designing and developing computer programs. This process is also called software development or program production.
The first appearance of widespread software dates back to 1890. It was at this time that the punched cards of Herman Cholerith (1860-1929), Massachusetts Institute of Technology, Cambridge, Massachusetts, appeared at the American Census Centers.
At the same time, there was the first cost overrun due to the fault of "computers". The results of the US Census Centers were originally tabulated by mechanical aids; mechanical tabulators by Herman Hollerith. At the same time, the production of punched cards began to develop. The funds spent on tabulation of these census centers were 98% higher than similar costs incurred in the past. This is partly due to the fact that the template used in tabulating data was designed in great detail and the amount of tabulated data exceeded the minimum required amount. Although the tabulation process itself was significantly accelerated. At the same time, punched cards appeared, the reading of which was performed electrically.
Returning to the CMM model, we note that at level 2 the software development process can be represented as a set of "black boxes" with certain control points (stages). As shown in fig. 2.1, the requirements are included in the process and smoothly "flow" into a set of "black boxes".
Rice. 2.1. Level 2 Process
Calculation results are generated for each box, and milestones and milestones are applied to monitor the software product development process. This is followed by the implementation phase of policies, standards and procedures. This experience is quantified using the elementary metric system used in this project. Control is exercised through the application of formal practices involved in the project management process. Costs, schedules, and feature set are also tracked. The main subjects of the process are software requirements and work products, and their integrity is controlled by a configuration management system. Projects are characterized by close relationships with customer support. It also develops the ability to implement software processes.
At level 3, i.e. "defined", documents and consistently uses the standard process used to develop and maintain software in an organization, which is schematically depicted in Fig. 2.2.
Rice. 2.2. Level 3 process
Within the framework of projects, the standard software processes of the organization are adjusted to concretize them. The processes of management and software engineering are also integrated. The ability to perform a standard process is standard, and the development team is responsible for the activities performed in software project. The following are the KPA areas for the third level of maturity:
1) the scope of the organizational process;
2) definition of the organizational process;
3) engineering of software products;
4) integrated software management;
5) interaction between groups;
6) expert assessments;
7) curriculum.
At level 3, the software development process follows a well-defined process. Awareness of roles and responsibilities in the course of the process is required. The production process of the software product is displayed during the execution of the software process.
Level 4 (Fig. 2.3), i.e. "managed", includes two areas of KPA: quantitative process management and software quality management.
Rice. 2.3. Level 4 Process
Through the use of an extended metric system, the results of detailed assessments of the software development process and software product quality assurance are accumulated. Quantitative evaluation and control of software processes and products is carried out. The management process is based on objective criteria formulated to make decisions and evaluate performance within given boundaries.
At level 5 ("optimization"), the KPA areas focus on the stages of technology change management, process change management and defect prevention. Through continuous process improvement, quantitative Feedback in relation to the software development process. At this level, new ideas and technologies can be tested in the organization to improve the quality of the software product, which is schematically depicted in Fig. 2.4.
Rice. 2.4. Level 5 Process
Through managed changes to an existing process, an organizational approach is introduced to enable continuous process improvement. Organizing these changes is important for the following reasons:
1) the process should be culturally relevant to the organization;
2) management is obliged to contribute to an increase in the degree of culture;
3) the culture should encourage the introduction of role models and rewards.
Summing up, the CMM model is a kind of "road map" that guarantees successful process improvement. Its interpretation and application are carried out in the context of the organization's business objectives. Currently, in organizations involved in software development, the CMM model is the most common method (and this trend is typical for many countries and a great many areas of application). This model is normative, non-prescriptive, and also characterized by a large margin of stability. Its development and support is carried out by many developers united in a community of professionals.
Popular
- Belaz General Director Petr Parkhomchik about the second place in the world ranking, management style and service in the landing
- What do we know about Euroopt: assets, owners, market share, scandals, income Dear employees of the company
- What is happening now on the Belarusian-Russian border?
- Ready business plan
- The decline in retail trade in Russia continues Decline in trade in a year
- How much can I order goods on Aliexpress in Belarus per month without customs duties?
- What to do if the dish is underweighed?
- What you need to know about the rules of carriage and customs clearance?
- high paying job in china
- Confessions of a housekeeper: I saw things in villas that I never want to become rich In dirty linen they dig out of boredom