Capability Maturity Model (CMM). Standards ISO, SW-CMM

Improvement Models

Improving Requirements Processes

The paradigm of quality management, as a way of organizing production, appeared a long time ago. Ideas embedded in the ISO9000 group of standards 1) , are rooted, in particular, in such "Soviet" inventions as support for rationalization proposals, mentoring, etc.

In the modern concept of a process-oriented business organization, the process of continuous quality improvement occupies one of the key positions.

With regard to the software industry, in addition to the ISO9000 series, the most successful quality standards are SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

Active introduction of quality management methods in the West began in the early 1960s. The philosophy of the CPI (Continuous Process Improvement) and TQM (Total Quality Management) approaches formed the basis of the ISO9000 series standards. The rise of the economy of post-war Japan was largely due to the ideas embodied in TQM.

Quality is a term that for some means the need to do what the consumer wants, for others - what meets his needs. Quality management, as defined in ISO 9001:2000, is based primarily on the fact that people perform better when they know what they are doing. .

Therefore, before starting any action, you should get answers to the questions: what needs to be done, who will check what has been done, how should it be done, and how to determine that the work is completed? You also need to consider how you are going to manage the process and how it can be improved.

Basic principles of ISO9000:

• Focus on customer needs;
• Active leadership role of management;
• Involvement of performers in the improvement processes;
• Implementation of the process approach;
• Systems approach to management;
• Ensuring continuous improvement;
• Fact-based decision making;
• Mutually beneficial relationships with suppliers.

The undoubted advantage of the standards of this group is due to the fact that they have been tested at many enterprises in the world. However, the recommendations of these standards are quite general in nature and do not take into account the specifics of IT enterprises. For this, specialized approaches have been developed, discussed below.

The CMM standard (the Capability Maturity Model) was developed by the Institute of Engineering software(SEI) at Carnegie Mellon University.

The purpose of the standard is to assess the level of "maturity" (maturity levels) of the organization - software developer. Five levels are distinguished: initial, repeatable, defined, managed and optimizing (for more details, see). This standard has become widely known, a significant number of Western IT companies are certified according to CMM.

In 2000, SEI released CMMI-SE/SW, an integrated model for improving both software and system design capabilities.

CMMI-SE/SW has two forms. The staged representation conforms to the SW-CMM structure with minor refinements to the level names. The five maturity levels contain the 22 workflow areas shown in Table 14.1. (CMU/SEI, 2000a). Continuous representation takes a different view: the same 22 areas are structured into 4 categories: process management, project management, design and support (CMU/SEI, 2000b).

In a continuous view, instead of maturity levels, six capability levels are defined for each process area. This view allows each organization to decide what level of capability they need in each of the 22 process areas.

As in the CMM, in this standard at level 2 there is an area called "Requirements Management", but, unlike the previous standard, at level 3 there is also a separate area of ​​\u200b\u200bRequirements Development. Placing this area at Level 3 does not imply that requirements for organizational projects that do not reach Level 2 need not be collected and documented. Requirements management is seen as a way to help create more predictable and less chaotic projects, which is the essence of CMM Level 2. By adopting a process for managing change and checking the status of requirements, an organization can place more emphasis on developing high-quality requirements.

Table 14.1.
maturity level	Name	Process areas
	Elementary	(No)
	Managed	Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management
	Definite	Requirements Development Technical Solution Product Integration Verification Validation Process Focus Organization Process Definition Organizational Learning Integrated Project Management Risk Management Issue Analysis and Resolution
	quantitatively managed	Performance organizational processes Quantitative Project Management
	Optimizing	Organizational innovations and their deployment Random analysis and resolution

Requirements Management Process Area

Key topics include how the development team should acquire an understanding of the requirements and resolve issues with customers, involve project stakeholders in working with requirements, and manage change. Unlike SW-CMM, tracing (one of the key properties of requirements) is included in the considered process area. The following qualities of tracing are discussed in the standard:

• providing a record of the sources of low-level or secondary requirements;
• tracing each requirement down to secondary requirements and arranging it by function, object, process, and worker;
• establishing horizontal links between requirements belonging to the same type.

Requirements engineering process area

Three sets of requirements development techniques are described in CMMI-SE/SW:

• techniques that define a complete set of customer requirements, which are then used to develop requirements for the product (identify the needs of stakeholders in the project; convert needs and constraints into customer requirements);
• techniques that determine the complete set of requirements for the product (install product components; place requirements for product components; determine interface requirements);
• techniques for obtaining secondary requirements, understanding requirements and their confirmation (establish operational concepts and scenarios; determine the required functionality of the system; analyze secondary requirements; evaluate the cost, time and risk of creating a product; approve requirements).

Both the CMM and the CMMI articulate the goals that a software development project or organization should strive to achieve in various areas processes. They also recommend technique helping to achieve these goals.

CMMI-SE/SW governs the relationship between requirements management, requirements development, and other process areas (Figure 14.1).

05.04.2007 Vyacheslav Pankratov

There is a lot of talk these days about software quality and information systems, studies are being conducted that demonstrate the dependence of the quality and efficiency of automated business processes. The quality of software from an abstract and intangible concept is transformed into a comprehensive metric for evaluating a software solution, a project for its implementation, the creation process and the level of use of information systems as a whole. What determines the quality of programs and how can you influence it?

Today, much is said about the quality of software and information systems, research is being conducted that demonstrates the dependence of the quality and efficiency of automated business processes. The quality of software from an abstract and intangible concept is transformed into a comprehensive metric for evaluating a software solution, a project for its implementation, the creation process and the level of use of information systems as a whole. What determines the quality of programs and how can you influence it?

Obviously, the quality of software directly depends on the quality of its production process. By managing the production process and monitoring the performance indicators of all its technological stages, it is possible to influence the quality of the product. Speaking about the characteristics of programs, we can single out quantitative metrics that are easy to understand and analyze, related to the quality of the program code (cyclomatic code complexity - the complexity of the module structure, for example, the number of independent routes in it); the number of lines of code assigned to the artifacts of the design repository, etc.; tests (covering code branches and modules with test scripts, the ratio of the number of bugs found before and after the release of the product, the dynamics of bug detection, etc.); coverage of requirements for compliance with recommendations for the application interface and operating platforms. However, when moving to the process level of quality assurance of the developed programs, certain difficulties arise in understanding the quality of this process. Indeed, how, for example, to evaluate and measure the effectiveness of one or another development method, if there are practically no development projects for two identical software systems, and even more so, there are no two development teams that are identical in experience and skills? Judged by end result it is not possible: in addition to the process conditions for software production (the methodology used, the structure of the project team, methods of communication with the customer), the conditions of the project (terms, cost and volume of resources) often vary greatly. A more detailed consideration of the software testing process - a technological component of the production process - reveals the problem of choosing test efficiency metrics.

In addition to a direct assessment of the current level of efficiency of a particular process, there is a more interesting task - increasing the level of efficiency or, as they say, maturity level processes. When the basic problems of planning and conducting testing work in integration with the software development process are solved, the task of finding optimal organizational and procedural schemes for performing work arises. Having answered the questions “who” and “when”, one has to look for answers to the questions “how, in what way”, “how to measure results”, “how to control”, “how to work more efficiently”, and also “how to manage and develop the process based on based on data and experience.

In everyday practice - when working with specific tools - IT professionals and project managers develop a strong opinion about the technological nature of all problems associated with the quality of software and the levels of maturity of the software development process that are achieved. As a result, vendor-promoted belief in the power of quality improvement software in practice becomes the breeding ground for unreasonable decisions to implement methodologies or automate development processes, starting with the implementation of specific software solutions. However modern facilities automation of development processes are such flexible and customizable platforms that they require preliminary deep study of the process component with subsequent implementation and adaptation to specific production conditions.

In 1980, the Software Engineering Institute at Carnegie Mellon University developed software development process maturity model(Capability Maturity Model for Software, CMM), which was subsequently developed into CMMI (Capability Maturity Model Integration), a de facto certificate of development maturity level recognized in the software industry. By analogy with the world of software development and existing models of the maturity of their processes, we will consider models of the maturity of the testing process.

Test maturity model

Software Testing Maturity Model is a systematic approach to the development of the testing process, which offers a system of elements of effective processes and ways to achieve specific process goals. Based on the maturity model, two main tasks of process development can be solved: to understand and fix the current testing process and to identify areas for improvement. Practice shows that process changes are possible only on the basis of a clear understanding by management of the need to make such changes - any structural and procedural changes are impossible without the political will of management. In addition to receiving management support and necessary resources, making changes to the process of testing work requires clear planning, like any other project activity.

Test consultant Terry Weatheril was one of the first to compare existing test maturity models in 2001 and identified six models:

Testability Maturity Model (TMM);

Software Testing Maturity Model (TMMSW);

Test Process Improvement (TPI);

Test Organization Maturity (TOM);

Testing Assessment Program (TAM);

Proposed Evaluation and Test SW-CMM Key Process Areas (SW-CMM KPA).

Then fundamental changes were made to some models; Thus, the TOM model (it was created and developed by Gerrard Consulting) offers an updated set of metrics that describe the testing process itself (the duration of test iterations, the ratio of test scenarios and functional requirements, etc.), which are collected and analyzed at the stage of describing the existing process.

Among the six software testing maturity models, practitioners and consultants identify two: TMMSW, developed at the Illinois Institute of Technology, and TPI, proposed by Sogeti. Both models have become widespread primarily due to their simplicity, as well as the proposed practices of internal audits that can be carried out by specialists of a company that has embarked on the path of process improvements. Consider the structure of software testing maturity models using the TMM model as an example.

The TMMSW model, chosen by Thomas Staab, one of the leading consultants in the field of software testing, is the most interesting to apply, because, along with the ease of understanding and using practices, it allows organizations to conduct assessments (assessment) on their own and gradually approach their development goals, controlling intermediate results. In our work, we also opted for this model, given the unpopularity of the practice of attracting third-party competence among domestic IT companies (companies try to save on investment projects, which in essence are consulting projects, as well as projects that bring indirect benefits, which include process changes), and we invite you to get acquainted with our experience, which demonstrates the readiness of companies to independently carry out internal changes using their own specialists. The iteration of the approach is a key point for many companies when choosing one or another maturity model, as it allows you to control the timing of the project for the implementation of process changes.

The TMMSW model was developed by a group of specialists led by Ilene Barnstein in 1996 as an extension and addition to the SW-CMM model. Its advantages include the correspondence between the maturity levels of software testing processes and the maturity levels of development processes in the SW-CMM model. Also, the TMMSW model can be used in integration with CMMI, ISO-9001 recommendations and ISO / IEC Std 12207, which allow you to get formal certification and, with constant monitoring in the form of audits and recertifications, remain at a given quality level. On the one hand, this feature of TMMSW allows the implementation of process changes in the software testing department in the form of a dedicated project on a smaller scale than the implementation of CMMI throughout the organization (which saves money and provides transparency); on the other hand, this approach eliminates the cost of adapting and pairing several models. Speaking of a kind of relationship with CMMI, I would like to emphasize that this model is quite widespread in the IT world and has earned a high degree of trust in itself, which makes it much easier for management to motivate the cost of a process change project.

The TMMSW model offers easier planning, implementation and monitoring of the improvement process. Among the shortcomings of the model, one can note the limited literature: the book Practical Software Testing: A Process-oriented Approach, published by Springer Professional Computing, is perhaps the only significant work on this topic.

The TMMSW model, like the CMM, has five levels of maturity.

Level 1 - chaotic. The software testing process is chaotic in nature, which distinguishes most start-up companies. The testing process is not defined as a dedicated activity and is not separate from the code debugging process. Testing is done after the code is generated and the system is built or assembled. The purpose of testing is to show that the application works. This level is characterized by untrained personnel, lack of resources and tools. The software is released without the formal consent of the testers. Level goals are not defined.

Level 2 - development phase. Software testing is separated from coding and is highlighted as the next phase. The main purpose of testing is to show that the application meets the requirements. There are basic approaches and testing practices. Level objectives: define development and testing tasks, create appropriate procedures, initiate the test planning process, fix and describe basic testing procedures and techniques.

Level 3 - integrated. The testing process is integrated into life cycle software development. Test objectives are based on requirements. There is an organization of testing, and testing itself is allocated in professional activity. Level objectives: to single out testing into a separate group and define a technical training program, integrate the testing process into the development life cycle, and also control the testing process itself.

Level 4 - control and measurement. Testing is a measurable and controlled process. Processes are critical inspections(review) of project artifacts (test plans and scenarios, error messages, final version status reports, etc.) refer to test activities. The product is tested for compliance with such quality metrics as reliability, usability, maintainability. Test scripts are recorded, stored in the test management system, and can be reused along with test datasets. Detected defects are not only fixed, but also analyzed according to formal criteria: criticality, “weight” of the defect, importance, lifetime, etc. Level Objectives: Implementation of critical review and audit programs at the organization/unit level on a par with a measured testing program. Quality assessment in progress software products.

Level 5 - process optimization, error prevention and quality control. Testing is a defined and controlled process. The cost of testing along with performance indicators can be determined. Testing as a process lends itself to changes that clearly positively affect it. Error prevention and quality control practices are implemented and used. Automated testing is used as the main approach in testing. Designing tests, analyzing the results obtained, processing error descriptions, as well as metrics related to testing, is carried out using the appropriate tools. The approach of reusing process practices is widespread. Level objectives: optimization of the testing process, error prevention and quality control.

All of the listed maturity levels, except for the first, include development goals, which, in turn, contain subgoals, that is, they allow you to operate not only with high-level tasks of software development process quality management, but also formulate operational tasks for all performers in the project. Control and analysis of task performance is achieved by covering the so-called ATR-matrices (Activities - Tasks - Responsibilities) - project-level artifacts that project participants can work with without prior preparation or long-term training. ATR-matrices define the activities and tasks that must be performed at each specific stage of the model implementation, and serve both as a “road map” and a kind of “checklist” for the change implementation process. The presence of design artifacts offered by the model itself is often an essential criterion for the success of a project to adapt and implement the model. Each activity in the ATR matrix is ​​assigned a control task, which is performed by managers, developers/testers, or clients/users. We especially note that the control over the change project is not assigned to a selected group of people or a specific person in the project, but is a general project function, in which project participants of all levels are interested.

Up to the fifth level of maturity of software testing processes, no special tools or integrated solutions are required, in contrast to the maturity of development processes, where tools for collecting and analyzing requirements and version control, for example, are necessary condition reaching a certain level of maturity of the development process as a whole. At the fifth level of the TMMSW model, it is possible to use certain statistical code analysis tools that allow solving one of the target tasks of this maturity level - error prevention by identifying code sections containing logical errors in the absence of resource release operators or searching for unused variables or memory arrays. However, the use of a special tool is not mandatory even at this level; for example, the approach when there are two testers per coder, one of which is a developer of more high level- busy with the tasks of critical code reviews, also allow you to solve the problem of preventing errors.

The use of specific methodologies or following any of the chosen methodologies (RUP, MSF or Scrum) also does not guarantee the achievement of product quality or project success, since the software development methodology only works for a specific type of project. Similarly, for the software testing process, no methodology without adaptation to the conditions of a particular project gives a guaranteed result. The process maturity model is precisely the practice of achieving certain levels of process quality that is interesting for application, which is a structure of goals and approaches for achieving them, allowing you to use "inside" an almost arbitrary development methodology (with proper adaptation) and a set of tools. The model explains “what and how” to do, but not “what and in what order”.

Practice

By putting into practice the recommendations of the maturity models of the testing process, the company can not only see progress in the format of the collected metrics, but also really feel the qualitative changes in the work mode itself. There are several signs of process changes that are felt both by management and team members, as well as by customers and consumers of the product being developed.

Time-controlled process of releasing versions with a given level of quality. It does not talk about the ideal quality of the manufactured product or total absence defects - we are talking about confidence in the state of the released version, on the part of both the project team and the testing team.

Regularity and predictable repeatability of all stages of the project. In the conditions of initial levels of maturity of software testing processes, testing activities follow as the final stage of work and often “suffer” due to limited time and lack of resources, which directly affects the stability of released versions and their quality. With the transition to higher levels of the testing process maturity model, testing activities are increasingly integrated into the development and release of product versions, which positively affects the allocation of the necessary resources and time to complete the work.

A change in such a qualitative indicator characterizing the process of developing and releasing software, as the number of defects found after the release of the product version in experimental or even production operation. This indicator is very significant for the managerial staff and services. technical support, which can confirm the positive dynamics of improving the quality of the software by conducting a quantitative and qualitative analysis of registered requests from customers or users. Positive points, according to our estimates, are associated with practical improvements at the stage of planning and testing control, since often missed defects are caused precisely by the lack of time for planning and monitoring the testing work carried out.

Literature

Terry Weatherill, In the Testing Maturity Model Maze. Journal of Software Testing Professionals, 2001.

Thomas Staab, Using SW-TMM to Improve the Testing Process. Wind Ridge International.

Vyacheslav Pankratov ([email protected] ) - CEO QAExpert company (Kyiv, Ukraine).

In addition to national and international standards, there are several approaches to certification of the development process. The most famous of them in Russia are, apparently, CMM and CMMI.

CMM (Capability Maturity Model) is a maturity model of software development processes, which is designed to assess the level of maturity of the development process in a particular company. According to this model, there are five levels of development process maturity. The first level corresponds to “how it goes” development, when developers go to each project as a feat. The second corresponds to more or less well-established processes, when it is possible with sufficient confidence to count on a positive outcome of the project. The third corresponds to the presence of developed and well-described processes used in the development, and the fourth corresponds to the active use of metrics in the management process to set goals and monitor their achievement. Finally, the fifth level refers to the company's ability to optimize the process as needed.

CMM and CMMI requirements

After the advent of CMM, specialized maturity models began to be developed for creating information systems, for the process of selecting suppliers, and some others. Based on them, an integrated CMMI model (Capability Maturity Model Integration) was developed. In addition, an attempt was made in CMMI to overcome the shortcomings of CMM that had manifested by that time - an exaggeration of the role of formal descriptions of processes, when the presence of certain documentation was valued much higher than just a well-established, but not described process. However, CMMI is also focused on using a highly formalized process.

Thus, the basis of the CMM and CMMI models is the formalization of the development process. They aim developers at the implementation of a process described in detail in the regulations and instructions, which, in turn, cannot but require the development of a large amount of project documentation for appropriate control and reporting.

The relationship of CMM and CMMI to iterative development is more indirect. Formally, neither of them put forward specific requirements for adhering to a waterfall or iterative approach. However, according to some experts, CMM is more compatible with the waterfall approach, while CMMI also allows for an iterative approach.

Of course, RUP is an iterative methodology. Although formally the mandatory execution of all phases or some minimum number of iterations is not indicated anywhere in RUP, the whole approach is focused on the fact that there are quite a lot of them. The limited number of iterations does not allow you to take full advantage of RUP. At the same time, RUP can also be used in almost cascading projects, which really include only a couple of iterations: one in the Build phase and the other in the Transfer phase. By the way, this is the number of iterations that is actually used in waterfall projects. After all, testing and trial operation systems involves making corrections, which may involve certain activities related to analysis, design and development, that is, in fact, they are one more pass through all phases of development.

RUP Methodology

With regard to the formality of the methodology, RUP presents the user with a very wide range of possibilities. If you do all the work and tasks, create all the artifacts, and fairly formally (with an official reviewer, with the preparation of a full review in the form of an electronic or paper document, etc.) conduct all reviews, RUP can turn out to be an extremely formal, ponderous methodology. At the same time, RUP allows you to develop only those artifacts and perform only those works and tasks that are necessary in a particular project. And selected artifacts can be executed and reviewed with an arbitrary degree of formality. It is possible to require a detailed study and careful execution of each document, the provision of an equally carefully executed and formalized review, and even, following the old practice, to approve each such review at the scientific and technical council of the enterprise. Or you can limit yourself to an email or a sketch on paper. In addition, there is always one more possibility: to form a document in your head, that is, to think about the relevant issue and make a constructive decision. And if this decision concerns only you, then limit yourself, for example, to a comment in the program code.

Thus, RUP is an iterative methodology with a very wide range of possible solutions in terms of formalizing the development process.

Let's summarize the second part of the article. RUP, unlike most other methodologies, allows you to choose the degree of formalization and iteration of the development process in a wide range, depending on the characteristics of projects and the developing organization.

And why this is so important - we will discuss in the next part.

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; in the labor market of specialists necessary qualifications clearly not enough. At the same time, in the field of improving the technological processes of software development and operation, international experience long years was insufficiently generalized and formalized. Only in the early 1990s, the American Software Engineering Institute (SEI) formed a model of technological maturity of CMM organizations (Capability Maturity Model), determining 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 has 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. his current state;

auditors to determine the standard certification procedure and conduct the necessary assessments;

consulting firms involved in the restructuring of companies and service providers information technologies 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 technological 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 law entails the need to build the necessary infrastructure and create the required corporate production culture that ensures that appropriate methods, operations and procedures for doing business are maintained 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.

SMM is methodical material, defining 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 CMM is to provide development organizations with the necessary instructions for choosing 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 on a small number of the most critical operations and systematically improving the efficiency and quality of their execution, 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 technology of creating software is reflected in strategic plans 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 standardization and (or) modernization of 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 the professional level of the performers. It may happen that an energetic manager 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. With absence required level project management, even advanced technology cannot 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, planning design work 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 ordered 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. As projects grow and become more complex, attention shifts from technical aspects their implementation on 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 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 the 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 quantification 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, a special unit is created in the organization, the main responsibilities of which are the collection of data on the implementation of processes, their analysis, the modernization of existing and the creation of new processes, their verification for 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. Internal structure represents 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 strictly tied to tools, which makes it possible to determine the quantitative characteristics of their labor intensity and quality of execution. 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 promptly 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 publicizing their organizational technologies, 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.

latest version 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 new development 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 includes developments made during the design of the CMM 2.0 version (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 CMM model, it was the intention of the US Department of Defense to assess the capabilities of software vendors. On this moment while there are no clear requirements to achieve 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. Several general types of improvement processes can be distinguished.

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 the 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. Has a clearly defined goal of improving the technological process, for which there is separate line in the budget of the organization and defines the norms and procedures for introducing innovations. 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 specific 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 of software systems and the processes of 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 sound processes are supported by analysis and design tools. The effectiveness of the support tool depends on the improvement process applied. For example, an informal process might use standard means support (prototyping tools, compilers, debugging tools, word processors, etc.). 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 technique considered below occupies an intermediate position between rigid, “heavy”, effective for large organizations solutions such as SMM 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 to enter the international level in the future, where SMM certification is highly desirable.

In 1982, the US Department of Defense formed a commission whose main task was to study the problems that arise in the development of software products in the department's organizations. As a result of the commission's activities, the Software Engineering Institute (SEI) was established in December 1984 at Carnegie Mellon University in Pittsburgh.

1987 SEI publishes: short description CMM structures; methods for evaluating software development processes; methods for evaluating the maturity of software production processes; questionnaire to identify the degree of maturity of processes (for independent, internal audit and external audit).

1991 Release of CMM v1.0.

1992 Release of CMM v1.1.

1997 Release of the next (improved) version of CMM.

The CMM methodology was developed and developed in the USA as a tool to select the best software vendors to fulfill government orders. To do this, it was supposed to create criteria for assessing the maturity of the key processes of the developer company and determine the set of actions necessary for their further improvement. As a result, the methodology turned out to be extremely useful for most companies seeking to qualitatively improve existing processes design, development, testing of software tools and reduce their management to understandable and easily implemented algorithms and technologies described in a single standard.

SMM has de facto become just such a standard. Its application allows putting software development on an industrial basis, increasing the controllability of key processes and the production culture in general, guaranteeing high-quality work and project execution on time. The basis for the creation of CMM was the basic position that the fundamental problem of the "crisis" of the quality software development process is not the lack of new development methods and tools, but the company's inability to organize and manage technological processes.

To assess the readiness of the enterprise to develop a quality software HMM introduces key concept maturity of the organization(Maturity). immature An organization is considered to be:

• there is no long-term and project planning;
• the software development process and its key components are not identified, the implementation of the process depends on the current conditions, specific managers and performers;
• methods and procedures are not standardized or documented;
• the result is not predetermined by real criteria arising from the planned indicators, the use of standard technologies and the developed metrics;
• the process of developing a solution occurs spontaneously, on the verge of art.

In this case, there is a high probability of unexpected problems, exceeding the budget or not meeting the deadlines for the project. In such a company, as a rule, managers and developers do not manage processes - they are forced to deal with the resolution of current and spontaneously arising problems. Note that on this stage development is the majority of Russian companies.

Main features mature organizations:

• the company has well-defined and documented procedures for requirements management, planning project activities, configuration management, creation and testing of software products, proven project management mechanisms;
• these procedures are constantly refined and improved;
• estimates of time, complexity and cost of work are based on accumulated experience, developed metrics and quantitative indicators, which makes them quite accurate;
• updated external and created internal standards for key processes and procedures;
• there are mandatory for all rules for the design of methodological program and user documentation;
• technologies vary slightly from project to project based on stable and proven approaches and methodologies;
• the organizational and production experience gained in previous projects, program modules, software libraries are used to the maximum;
• new technologies are being actively tested and introduced, their effectiveness is being evaluated.

SMM defines five levels technological maturity of the company, according to which customers can evaluate potential applicants for a contract, and developers can improve software development processes.

Each of the levels, except for the first, consists of several key process areas(Key Process