V. Ilyin.

Head of Quality Service of TopSBI Company

"If you do anything

wrong - not necessary
expect the right result. "

Chinese folk wisdom

Comprehensive solution to quality assurance problems software tools involves the development and implementation of a particular quality management system (Quality Management System - QMS). In world practice, the most widespread is the system based on the requirements of international standards. ISO series 9000, because it defines precisely the most general requirements, including for software systems, and thus, in general, already predetermines the initial maturity of processes that is necessary to comply with many industry models and standards in the IT field .

But the question of whether the introduction of a quality system and successful certification guarantees the release of a quality product must be answered honestly - "no".

Emphasizing that ISO 9000 is a “great idea,” the Gartner Group recommends that ISO 9001 certification be viewed only as a starting point on the road to quality (1).

It lays down a kind of "skeleton" of the quality system, and filling this system with "muscles" (professional content based on already special, industry standards and methodologies, such as CMM) can provide a level of quality that meets the growing market requirements.

In connection with the above, both from a methodological and from a practical point of view, many experts in the field of quality management consider it expedient to build a strategy for the development of IT companies as follows:

First, develop and implement a QMS based on the ISO 9001: 2000 model. (After all, most companies that are now at the 4th and 5th levels of SW-CMM, first went through bringing their processes in line with the ISO model. As practice shows, this the best option in terms of managing the development of the QMS and reducing risks).

And only then begin to develop and implement the key processes of the SW-CMM model and further, if necessary, the CMMI model.

In order to understand how this is really correct, let's compare these models.

1. Review of applicants.

We will carry out short review the most popular standards that can be used by an IT company to optimize its business processes.

ISO 9001. The most popular, and especially in Europe, is ISO 9001 (2)

At the same time, methodically, in full accordance with the discipline of building complex systems, the ISO 9001 standard provides, on the one hand, the construction organizational system"top down": from the goals of the enterprise and its policies - to the organizational structure and the formation of business processes, and on the other - the iterative development of the organizational system through the mechanisms of measurement and improvement.

In simpler terms, "quality", according to the ISO 9000 series of standards, is a situation in which consumers receive from a manufacturer products that meet their direct requirements and latent expectations. Therefore, quality management, in accordance with ISO 9000, involves the use of the so-called. "process approach", when the most optimal chain of "transformation-processes" is modeled and implemented, ensuring that the needs of consumers are perceived by the manufacturer and embodied in any product without distortion.

This well-known series of ISO 9000 standards has been used successfully by many software organizations. A new version standards of this series was released in 2000 and already contains such concepts as the process approach, analysis and measurement, process improvement, borrowed from the CMM model and previously absent in previous versions of ISO 9000. However, it should be noted that the standards of this series are universal - they are not focused on any specific industry, they do not take into account the specifics of the IT sphere and, in this sense, of course, in terms of the degree of concretization, they are noticeably inferior to the SMM. In addition, ISO 9000 does not imply any gradations (levels) of conformity and, thus, makes it difficult to determine the "true" capabilities of an organization and, accordingly, - ways of their further development.

CMM(Capability Maturity Model) was developed by the Software Engineering Institute at Carnegie Mellon University (USA) and describes a maturity model for development processes software at enterprises (3). Within the framework of this model, for each company a certain level (one of five possible) can be compared, indicating the achieved quality of the software development process. Since these standards were developed primarily to streamline the selection process for contractors for the US Department of Defense, they focus on software project management processes, while the technical aspects of development are less covered.

There are 316 Key Practices in SW-CMM v.1.1 (Capability Maturity Model for Software). Key Practices are what should be implemented in the enterprise and what the process assessment team will pay attention to. They are united in the area - Key Practices Areas (KPA) - this is already a set of interrelated processes that, when jointly performed, lead to the achievement of a certain set of goals.

CMMI(Capability Maturity Model Integration) - further development of the CMM model. In CMMI-SE / SW Version 1.02 (CMMI for Systems Engineering / Software Engineering), perhaps the most acceptable for developers software systems, - the number of Key Practices has already reached 417.

The increase in Key Practices is related to the very purpose of developing CMMI - the model should help avoid the problems associated with using various industry CMM models.

(Since 1991, CMMs have been developed for a variety of applications, the most significant being:

Capability Maturity Model for Software (SW-CMM)
- process maturity model for system reengineering (Electronic Industries Alliance Interim Standard - EIA / IS 731)
- model of maturity of processes of integrated product development Integrated Product Development Capability Maturity Model - IPD-CMM)

Based on these models, the CMMI was built. He has absorbed the best of these models, eliminating the ambiguity in the interpretation of some concepts due to the presence of many models - therefore, the number of key practices has grown significantly).

It is clear that this turned out to be a much more "heavy" model - see. Rice. one, which, moreover, has not yet been sufficiently tested in practice (came out only in 2002). In this regard, in my opinion, when implementing the model, there are possible large risks associated with both unjustified losses in the speed of software development, and with a simultaneous unambiguous increase in labor costs for the operation (and support) of the implemented KPA - see. Fig 1. To me, as a practitioner who has already built a QMS in three different profiles of IT companies, it seems that the CMMI model is clearly out of balance between the necessary and the sufficient - the personnel of the IT company (and these, as a rule, are mostly "code artists") it will simply not "accept for execution" such a number of controlled regulations (there is a very high risk of building a "Potemkin village")!

Rice. 1 Comparison of KPA composition in CMM and CMMI models.

In addition, Assessment for CMMI will be significantly more expensive, since authorized SEI Lead Assessor " There will be very few of them so far, and these services will be much more expensive than when evaluating for compliance with the CMM model.

Moreover, many foreign experts in the field of quality management, (to whose opinion I fully agree at the moment), are rather skeptical about CMMI in the context of its usefulness for implementation in small and medium-sized organizations (these are the organizations that are just typical for Russia ). There is even an opinion that after a while SEI will have to either release an adapted SW-CMM v.2, or take some similar steps. Those. if the market does not accept the model, and such preconditions are already in place at the time of this writing, then SEI will need to adapt to market requirements.

In connection with the above, it seems appropriate to analyze the already mentioned balance of the necessary and sufficient in all these basic QMS models.

Let's draw it in the following coordinates (see. Rice. 2) :

the degree of regulation of development processes - let's designate this concept - RP,

the probability of achieving the planned results - let's designate this concept - PQ.

In Fig. 2 shows an expert assessment of the balance of the degree of regulation and the likelihood of achieving the planned results, carried out by the author based on the results of the practice of introducing the requirements of these models into the development and implementation of software systems (software).

In mathematical terms, the magnitude of the derivative is: F (Q) = dPQ \ dRQ(increase in efficiency in achieving quality dPQ with an increase in the cost of working time to support the fulfillment of requirements dRQ), decreases, respectively, in the following sequence : ISO 9000, CMM, CMMI.

Therefore, Fig. 2 clearly and simply explains:

the popularity of the ISO 9000 model,

the correctness of the methodology: first ISO, and only then, if necessary, CMM,

some skepticism about the effectiveness of the CMMI model.

Rice. 2 Analysis of the balance between the degree of regulation and the likelihood of achieving the planned results (according to the author's expert assessment)

Let us now consider one more guide that is widely used in IT companies and will be mentioned below when analyzing the issues of QMS implementation practice.

This PMBoK(Guide to the Project Management Body of Knowledge) is project project Management Institute, which has absorbed the accumulated knowledge in the field of project management. The last version of the document was published in 2000 and at the same time received the status of a standard of the American Institute for Standardization ANSI (although ANSI and IEEE standards are formally considered American, most of them are de facto international in nature). An important feature of PMBоK is that it considers project management in a general sense, without reference to specific subject areas, such as IT, and therefore cannot be applied independently - below we will consider what effect this gives when used in conjunction with ISO 9000.

Let us now consider how the requirements of the already popular ISO 9001: 2000 standard relate to the general properties of the increasingly popular CMM model {3}- cm. Rice. 3.

Rice. 3. Correspondence between the general properties of the CMM and the elements of ISO 9001: 2000

Each level of the SMM, as mentioned above, is characterized by a set areas of key processes - KPA (Key Process Areas) - cm. Fig. 3. Achieving all goals within KPA for a certain level, the CMM determines the organization's compliance with that level. If at least one target is at least one KPA for the CMM level is not achieved, then the organization cannot meet this CMM level. KPA can be broken down into three categories: managing directors , organizational and providing (cm. Rice. 4).

The CMM does not define all processes related to software development; it highlights only those that are necessary to achieve the level of the SMM, and they are included in KPA... Each KPA is broken down into 5 Common Features: Comment to perform; Ability to Perform; Activities Performed; Measurement and Analysis; Verifying Implementation

General property " Actions Performed " describes the actions that need to be performed to achieve the goals KPA, the other four general properties describe the formal factors that make the process a part of organizational culture... Complete fulfillment of all key practice of all common properties ensures the achievement of goals KPA... Key operating practices describe what a workflow (or a process element, or part of an infrastructure) should become, but do not define a way to achieve ( specific technologies or techniques), although general guidelines are given for some techniques. For different conditions the same result can be achieved in different ways. It is rather general principles work than concrete action.

The sequential implementation of common properties actually implements a cycle of improving business processes (Buisness-process Improvement - BPI-cm. Rice. 5.), i.e. continuous improvement of business processes (BP).

Rice. 5. The cycle of continuous improvement of business processes according to the CMM model and ISO 9000: 2000.

The desire to obtain a certificate of conformity in the shortest possible time compels consulting companies and quality management specialists to use the flexibility and framework of the requirements of all the listed high-level models for their own "mercenary" purposes.
As a result of this forcing of events, an organization, for example, which received a certificate according to ISO 9000: 2000, has only the minimum necessary set of processes for compliance with ISO 9001, and not all the processes that the company needs to function effectively - see. Rice. 2... In addition, the level of detail of processes may not be sufficient for a clear understanding of what is happening inside the processes and who is responsible for what tasks within the process.
V best case only a few test projects have gone through the new procedures, and after some time it becomes clear that they need to be corrected and supplemented. Often, immediately after certification of the QMS, the processes are forgotten until the next supervisory audit, while forgetting about the spent financial resources and the enthusiasm of the staff.
Indeed, when acting as an independent auditor, it is very difficult to prove that the accepted level of detail of the process is clearly not sufficient for the effective functioning of the company's QMS. But it is extremely difficult to prove the opposite during the time allocated for the audit according to ISO 9000 (this can be very successfully used when opposing the auditor). Practice shows that it is impossible to quickly build effective processes even at the 3rd level of maturity (as well as processes based on ISO 9000).
In order to achieve this, it is not enough to simply describe the processes taking into account the requirements of the chosen model. The biggest challenge is that you need to redesign the culture of production within the organization .

And it is impossible to do this by a strong-willed decision of the leadership. This is why the approach defined in the CMM is simply more viable and realistic than the ISO 9000-cm models. Rice. 5.

Let us now consider how, in practice, you can build a QMS compatible with both models.

An expert assessment of the degree of coverage of key CMM processes with the requirements of ISO 9000: 2000, in accordance with the assessment of the CMM authors themselves (4), is shown in Fig. 6.

The actual assessment was carried out by them in two coordinates:

the degree of maintainability (in%) compliance of development processes (SWP) with the maturity level within the CMM - " security ";

the degree of feasibility (in%) of such availability, which is provided by ISO 9000: 2000 - " opportunity".

As seen from Rice. 6, ISO 9000: 2000 requirements create real opportunity to achieve even the upper (CMM Level 5) SWP maturity level.

However, in the sense of already ensuring the maturity of SWP at least the third (CMM Level 3) level, the QMS according to the ISO 9000: 2000 model needs to be slightly modified - namely, to develop and implement two more organizational procedures ( Organization process definition and focus) and procedure general management (Integrated softwaremanagement ), the content of which is not difficult for any IT company.

But it is possible and necessary to go further (CMM Level 4) - for example, the author's assessment of this article (in the same coordinates - availability and capabilities) is shown in brackets, which corresponds to the QMS according to the ISO 9000: 2000 model, in which the process landscape of the QMS is supplemented with processes project management in accordance with the requirements of the other aforementioned standard PM Bok- this will help you to significantly increase the maturity of even such SWP, how:

Monitoring the progress of projects (Software project tracking and oversight);

• Planning of projects (Software project planning);

General software management (Integrated software management);

Quantitative process management.

Rice. 6. Expert assessment of the degree of coverage of key CMM processes with the requirements of ISO 9000: 2000

As seen from Fig. 6., the CMM model in terms of the principles laid down in it is very close to the QMS built according to the ISO 9001: 2000 standard and supplemented by project management processes in accordance with PM BoK..

For not doing extra work with simultaneous certification according to ISO 9000 and subsequent assessment according to CMM, I recommend that when defining your production processes, include (or maybe limit them - after all, this is for an IT company and there are production processes!) among them all necessary in the CMM KPA model. Thus, the company at the same time:

fulfills the requirements ISO 9001: 2000 on the implementation of the process approach;

documents all necessary CMM processes ( KPA);

at the same time implements a number of such important requirements ISO 9001: 2000 how:

metric-based process control (Quantitative process management);

Supplier management based on subcontract management ( Software subcontract management );

analysis of Consumer requirements based on y management requirements ( Requirements management );

human resource management based on Personnel training programs (Training program );

communication management based on Formal model building organizational processes ( Organization process definition );

launches the improvement mechanism (Plan-Do-Check -Action) all described processes (SWP) through the sequential implementation of all five Common Features-cm. Rice. 5.

Thus, if you use KPA CMM as a BP and use the requirements for project management procedures for the development of software systems PM BoK, then the QMS constructed in this way may well be estimated at CMM Level 4 - cm. Rice. 7.

Rice. 7. Scheme of achieving CMM Level 4 when using the QMS model according to ISO 9000 and the PM BoK 2000 manual.

In conclusion, for reasons of clarity (stylized by the author), I present a scheme of the functioning of the QMS of an IT company with the consistent implementation of the ISO 9000 and CMM models - see. Rice. eight.

Rice. 8. Diagram of the functioning of the QMS with the sequential implementation of the ISO 9000 and CMM models (stylized by the author)

It is important to understand here that both the CMM and ISO 9001: 2000 are in themselves just tools for continuous improvement.

Thus, certification according to the ISO 9001: 2000 standard and confirmation of the certificate should contribute to the growth of the quality of the company's processes, where the criterion for assessing the growth of the quality of processes is the company's entry to a new level. BPI, that is, their assessment is already based on the model, namely CMM {3}.

Literature

"Assessment of the quality of software", V. Lipaev, Sinteg, 2001

ISO 9001: 2000. Quality Management System. Requirements.

Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model for Software (SW-CMM), version 1.1. // CMU / SEI-93-TR-024, - Februaru, 1993.

Annotation: The range of ideas underlying, probably, the most well-known methodology for improving software development processes - CMM is studied in detail. The logic and structure of the SMM is analyzed. The connection of the HMM with the previously studied process models is shown.

A wonderful practical tool built within process approach to the description of the activity design organization , in particular, the organization developing Information Systems, demonstrates the SMM methodology. CMM stands for Capability Maturity Model, which roughly means "management system maturity model". In the literature, CMM is more commonly referred to as the organizational maturity model, and I too will follow this tradition.

The history of the emergence of the SMM is as follows. In the late 80s. last century, the US Department of Defense ordered the Institute of Software Engineering 1eng. SEI - Software Engineering Institute Carnegie Mellon University is working to establish a system of criteria for the selection of subcontractors in software development projects. The work was completed in 1991 and the result was the CMM model. It is necessary to immediately make a reservation that the model does not contain any financial, economic, political, organizational selection criteria the subcontractor, as well as the criteria for the possibility of admission to secret work (probably, such tasks were not set). We are talking only about the criteria describing the ability of a potential subcontractor in terms of developing software systems.

CMM structure

The creators of the model took the processes of the organization as a basis for assessing the ability of an organization to perform quality work, which (ability) was called maturity. Then they made several non-trivial assumptions, which were later accepted and recognized as fair by many IT specialists (and maybe most of them).

Assumption 1... There are qualitatively different levels of maturity design organization developing Information Systems(there are five such levels in the HMM model).

Assumption 2... Any development organization is interested in moving to a higher level of maturity (not only in order to increase its chances in the fight for contracts with the Ministry of Defense, but also in order to improve itself).

Assumption 3... The transition is possible only to the next level in order. It is impossible to "jump" over the level (more precisely, the risks for the organization increase dramatically).

Thus, the levels form a "ladder" along which the organization rises as own development... Each level is characterized by certain composition and properties of the organization's processes. The SMM "ladder of levels" has gained widespread acceptance and distribution. This is what it looks like.

Level 1 "Beginner"... The production process as a whole is characterized as being created each time for a specific project, and sometimes even as chaotic. Only a few processes are defined and the success of the project depends on the efforts of the individuals.

Level 2 "Repeatable"... The main project management processes have been established, allowing you to track costs, monitor the schedule of work and the functionality of the created software solution... Established process discipline to replicate previous successes in similar application development projects.

Level 3 "Defined"... The manufacturing process is documented and standardized for both management work and design. This process is integrated into the organization's standard manufacturing process. All projects use an approved customized version of the organization's standard manufacturing process.

Level 4 "Managed"... Detailed quantitative indicators of the production process and the quality of the product being created are collected. Both the production process and the products are quantified and monitored.

Level 5 "Optimizing"... Continuous process improvement is achieved through quantitative feedback with the process and implementation of advanced ideas and technologies in it.

Despite the laxity, the above definition is intuitively most often not objectionable. Moreover, experienced specialists understand why transitions are possible only to an adjacent level, as well as why it is generally worth striving for such a transition. At the same time, the HMM model does not contain any quantitative or at least formal substantiation of such an approach, which, however, does not in the least detract from its merits.

Further, as they say, is a matter of technology. The structure of the model is determined (Fig. 7.1), definitions are given, and painstaking work begins to accurately describe each process at each level. In order to appreciate the practical value of what has been done, we will go through part of this path.

Rice. 7.1.

In fig. 7.1 there are the following concepts.

Key process group... As stated in (Paulk, et al., 1995), "each group of key processes defines a block of related activities, as a result of the implementation of which a set of goals is achieved that are significant for increasing the productivity of the production process. For example, for a group of key processes." Requirements management"(see Figure 7.2) the goal is to align the requirements of a software development project between the customer and the developer."

CMM does not individual processes... Instead, there are separate activities, called core practices (see below), which are related to each other in terms of I / O and serve as the starting material for building processes. The CMM does not provide guidance on how processes are structured, that is, how key practices are linked in logical sequences. Sets of core practices are called core process groups.

Rice. 7.2.

Groups of key processes in the CMM are mapped to maturity levels (Fig. 7.2), that is, all practices at the level interact only with each other and do not interact with practices at other levels. This allows us to guarantee the full performance of all processes at a specific level and, therefore, to correlate the level with the completed stage of the organization's development.

The adjective "key" implies that there are process groups(i.e., a set of practices) that are not key from the point of view of a specific level of maturity, i.e., are not related to the achievement of the goals of this level (see below). The CMM does not cover everything process groups concerning the development and maintenance of software. It describes only those groups that are identified as key determinants of the productivity of the production process.

Goals... Objectives in the SMM are not associated with processes, but with groups of key processes. As mentioned above, goals are achieved through the implementation of key practices. In CMM, achieving a goal means that, firstly, after completing the key practices, the desired result is obtained, and, secondly, it turns out to be quite stable. The way in which the objectives of the key process group are achieved may differ from project to project, depending on the differences in subject area or environment.

If these goals are realized for all projects, then this means that the organization has reached the level of maturity of the production process, which is related this group key processes.

Chapter... Sections (there are five of them at each level and they are always the same) represent the properties of groups of key processes that must be implemented at the corresponding level. These properties describe how the processes are implemented and how legalized they are in the organization, that is, they are officially approved and consistent with corporate procedures, policies, and other processes. These are the five sections.

Obligations to fulfill

Describe the actions that the organization must take to ensure that the process is established and stable. Compliance obligations usually concern the establishment of organizational policies and support from senior management.

Prerequisites

Describe the preconditions that must be met by a project or organization for the competent implementation of the manufacturing process; usually refer to resources, organizational structures and required training.

Operations performed

The section "Performed operations" describes the substantial work that must be performed at this level. Operations performed typically include making plans and executing specific operations, performing and tracking work, and taking corrective action as needed.

Measurements and analysis

Section "Measurements and

“Each Key Process Group is expressed by Key Practices, the execution of which contributes to the achievement of the Group's objectives. Key Practices describe the infrastructure and operations that most contribute to the effective implementation and establishment of the Key Process Group.

Each Key Practice consists of a single sentence, often expanded with a more detailed description, which may include examples and clarifications. Key practices, sometimes called key practices top level, establish basic policies, procedures and operations for a group of key processes. Components detailed description often called sub-practitioners. "

Key Practices describe WHAT needs to be done, but should not be taken as dogmas stating HOW to achieve goals. The objectives of the core process group can be achieved through alternative practices. Interpretation of key practices should be reasonable, allowing the achievement of the goals of the group of key processes effective way, although perhaps formally and different from the recommended CMM.

A view of IT management activities, in which instead of processes, their components are considered - key practices, and the processes are present only virtually, as something that can be built from key practices looks somewhat exotic at first glance. Until now, the task of improving IT management has been solved by the introduction of ready-made processes from the reference process model. Now, there are many levels that contain disparate (i.e., not integrated into processes) key practices, and the recommended sequence of progress through the levels. IT governance, according to CMM, improves as you move to a higher level of maturity. What happens with such progress?

In the definitions of levels (see Fig. 7.2) such a concept as "production process" appeared. It is also present in the definition of a group of key processes, and this is not an accidental coincidence. The manufacturing process, or, as it aptly called in the CMM, Standard Manufacturing process Organizations (SPO) is one of the central concepts of the entire model.

In November 1986, the US Software Engineering Institute (SEI), in conjunction with the Miter Corporation, began developing a Maturity Survey of Software Development Processes, which was intended to help improve their internal processes.

The development of such a survey 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 big projects... In many companies, projects were completed with significant delays and exceeding the planned budget. It was necessary to find a solution to this problem.

In September 1987, SEI released a synopsis of software development processes describing their maturity levels, and a questionnaire to identify areas in the company for improvement. 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, Capability Maturity Model for Software (CMM). The first version of the CMM (Version 1.0), released in 1991, was revised in 1992 by participants in a workshop in which about 200 software specialists and members of the developer community took part.

As a result, was released CMM standard, Version 1.1, which is still actively used all over the world.

Rice. 1. The global impact of using the SMM

The reasons for this interest in the SMM are clear. Despite the fact that both software developers and their management are often very well aware of their ongoing problems, they cannot agree on what changes the company needs in the first place. Without developing a unified strategy for making improvements, management cannot find mutual understanding with its employees about the highest priority tasks for improvement. To achieve the maximum result from the efforts spent on improving processes, 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 a company's culture, not on revolutionary innovations. The CMM provides a framework for this incremental improvement, divided into 5 levels of process maturity. These 5 levels represent 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 consistent increase in the level of maturity: opportunities for the development of the organization

Here are the main characteristics of each level:

1. Initial - The development process is chaotic. Only a few of the processes have been identified and the success of projects depends on the individual performers.
2. Repeatable - The main project management processes are established: tracking costs, schedule and functionality. Streamlined some of the processes required to replicate previous achievements on similar projects (projects with similar applications).
3. Defined - Software development and project management processes are described and implemented in unified system company processes. All projects use a standard organizational process of software development and support, adapted for a specific project.
4. Managed - Collect detailed quantitative data on development process performance and quality final product... The significance and dynamics of these data are analyzed.
5. Optimizing - Continuous process improvement is based on quantitative process data and piloting 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 heads of software companies, heads of departments and software development projects and quality specialists who are interested in:

improving the transparency of existing production processes;

increasing the productivity of processes and the company as a whole;

reducing the cost of production and the volume of existing "hidden" production;

increasing the company's reputation in the professional environment;

opening new markets for products.

2.1 Cost, duration and results obtained. 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 inherent in the CMM process improvement model
3.4 The concept of a 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 ISO relationship with CMM, Rational Unified Process, Project Management
9.3 Applying CMM for Small Organizations
9.4 What is missing in the SMM
9.5 Documents and processes

10.1 Final overview of the SW-CMM model. Distribution in the world. The main difficulties
10.2 CMMI (Capability Maturity Model Integration) - further development of the CMM model

A set of slides, materials for practical exercises, additional materials for self-study.

A complete set of documents on SW-CMM (text of the standard, assessment methods, statistical materials on the industry, 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 model for improving the maturity of processes, to help avoid typical mistakes and implementation problems.

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 according to CMM.

Review of recognized quality management standards for IT (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)

17. To CMM via ISO?

5 evolutionary stages in the management of organizational processes. Explanation of the Capability Maturity Model functionality). CMM

The Capability Maturity Model CM-CEI organizational model, which describes 5 evolutionary stages (levels) at which processes in the organization are controlled.

The rationale behind the Capability Maturity Model, originally designed for software development, is that an organization must be able to accept and support its software applications. The model also suggests concrete steps and initiatives that will 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 a discipline to adhere to these processes) Defined (all processes are defined, documented , unified and integrated) Managed (processes are measured by aggregating detailed process data and their quality) Optimizing ( continuous development process using quantitative feedback and testing new ideas and technologies)

Software development model

CMM describes the principles and practices that underlie the concept of software process maturity. They are designed to help software development and marketing firms improve the sophistication of their software processes in an evolutionary way. From ad hoc, chaotic processes to mature, disciplined software processes. The focus is on identifying key process areas and best practices that disciplined software processes can constitute. The CMM maturity concept creates a context in which:

The practices can be repeated. If you do not repeat an operation, then you should not improve it. There are rules, procedures and practices that force an organization to be implemented and consistently implemented. Best practices for organizing production work can be quickly disseminated among groups. The practices are defined to allow exchange between projects, thus providing some standardization for the organization. Deviations in the performance of these methods are minimized. Quantitative goals are set for objectives; and measurements are established, produced and maintained to form the basis for the assessment. Practices are continually being improved to improve 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 the organization has implemented or wants to achieve.

Functionality Development Model structure

Maturity levels are a layered concept that provides the discipline consistency needed to achieve continuous improvement. It is important to note here that the organization develops the ability to evaluate the consequences of a new practice, technology or tool. Hence, it is not a question of acceptance of these innovations, but rather how these innovative efforts are influencing existing practices. It supports projects, groups and organizations by giving them the basis to make 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. The regulations need to be implemented in an efficient and reliable manner. The extent to which the objectives are met shows what kind of opportunity the organization has set at that level of perfection. Objectives outline the areas of activity, boundaries, and purpose of each key process area. Common characteristics - Common characteristics include practices that implement and institutionalize key process areas. These 5 types general characteristics These include: Commitment to Compliance, Ability to Compliance, Initiatives Performed, Measurement and Analysis, and Implementation Control. Key Practices - Key Practices describe the infrastructure and practice elements that most effectively contribute to the implementation and institutionalization of key process areas.

Criteria for defining the process

Criteria for defining a process are a collection of process elements that must be included in the description of a software process in order for people to use them in practice. In order to establish the criteria you need to ask the question - "What information on the program process is needed for documentation?"

Introduction

The most important part of modern complex systems are software products - an intellectual component. Software products are now used to solve management problems in almost all spheres of human activity: in the economy, social, military and other areas. Ensuring high quality of domestic software products during their mass development and delivery for various fields of application in the country and on the world market has become strategic objective.

Currently, there are two almost independent areas of standardization in software engineering and quality assurance of software products, which can be conditionally called ISO standards profiles ( The International Organization standardization) and SEI (US Software Engineering Institute) maturity models. The first ones are sufficiently fully represented in [,], and the second ones - in [,]. The main content of the article is devoted to the maturity models.

To ensure competitiveness in the world of complex software products and the possibility of their successful export, they must be developed and certified in accordance with the requirements profiles of international standards on the base ISO 9000: 2000 or maturity models - CMMI: 2003(Capability Maturity Model Integration - Integrated model for assessing the maturity of software engineering). These two directions are methodologically very close and partially intersect through mutual links.

Improvement of technical and economic indicators and quality of software products, as well as prevention of errors and defects is ensured by the use of modern software engineering technologies and systems computer-aided design... These are high-performance, resource-saving technologies for creating complexes of programs of high quality, reliability and safety, aimed at reducing the total cost of resources for the design, implementation and maintenance of software tools (PS). For this, first of all, it is necessary to apply methods and tools of analysis and design that provide concretization and the most accurate representation of goals, purposes and functions from the beginning. life cycle(Lifecycle) software systems and preventing the spread of possible system defects to subsequent stages of development. Such software engineering technologies make it possible to exclude or significantly reduce the level of system, algorithmic and software errors in software products transferred for operation. In addition, they are effective when modifying and maintaining PS, as well as when changing external environment.

To certify the quality, reliability and safety of complex, critical systems, the software products used in them are subjected to certification certified, problem-oriented test centers or laboratories. Such testing is necessary when programs are controlling complex, critical processes or processing information so important that defects or insufficient quality can cause significant damage. Certification tests must establish the compliance of software complexes with the requirements of the documentation and allow them to operate within the limits of changes in the parameters of the external environment, investigated during the checks carried out. These types of tests are characterized by the greatest rigor and depth of checks, and should be carried out by specialists independent of the developers and customers (users).

The basis of certification should be detailed and effective programs and methods for testing program complexes for compliance with standardized customer requirements, specially designed test problems and generators for their formation, as well as high qualifications and authority of testers. Application of certified quality systems to ensure the life cycle of software products based on the requirements at software development enterprises ISO 9000: 2000 or CMMI: 2003, guarantees high, sustainable quality management of processes and products of their life cycle, and also allows in many cases to facilitate the certification of the final software product. Therefore, customers of complex software projects tend to select executing contractors who have certificates confirming their application of quality assurance systems based on adapted profiles of international standards or maturity models.

Gaps in teaching software engineering methods leave a wide margin for the arbitrariness of specialists in assessing the quality of their work, as well as for the appearance of numerous defects and errors in software projects. Increasing complexity and responsibility modern challenges, solved by the programs, as well as the possible damage from the insufficient quality of their results, significantly increased the relevance of mastering the methods of a complete, standardized description of the requirements for quality characteristics and methods of measuring their real, achieved values ​​at various stages of the PS life cycle. The need for specialists to know the concepts, definitions and methods of assessing the quality characteristics of software products has sharply increased.

The rapid increase and complication of software complexes leads to the creation of large programming teams with a professional division of labor, in which it is necessary to regulate the coordinated activities of groups of specialists on a single project. Developers' contractual promises to deliver high-quality software within the agreed timeframe are often not met. This often happens due to the fact that the customer and the contractor assess the quality level according to different criteria, and they do not have any agreement on this issue, and the approach to assessing the quality of programs is not formalized enough. In addition, the ability to properly assess the resources required to achieve high quality programs is sometimes lacking. As a result, the quality of software products often remains low, unreliable and not competitive in the international market. Therefore, the most important problem in the development and application of many modern systems is the training and education of specialists in the field of software engineering, the use of international standards that contribute to the high quality of software and its reliable assessment with the main goal of making project processes managed and the results are predictable... It is necessary to be able to formalize the requirements and achieve specific values ​​of the characteristics of the quality of functioning and the use of complex complexes of programs, taking into account the resources that are available to ensure and improve this quality.

CMMI Maturity Model - 1.1, refines and improves previous models CMM(see), and also partially takes into account the basic requirements of existing international standards in the field of software management. Considerable attention in CMMI focuses on development processes and accounting for iterations when customer requirements change, tracking them to functions, components, tests and project documents. V Lately there was information about the modernization of the 2003 version by the SEI institute CMMI - 1.1 based on experience and feedback from businesses. It is planned to release in 2006 a new, significantly modernized version of the model CMMI - 1.2, after which version 1.1 should be phased out. By the end of 2007, users should switch to the version CMMI - 1.2, and in the future it will become mandatory for the formalized quality assessment (certification) of the technology of enterprises in the field of software engineering. In this case, the validity of the certificate will be limited to three years. Customers and developers of large software systems should prepare for these changes prior to the official publication of version 1.2 by SEI.

Structure and content of the CMMI Maturity Model - 1.1

Two model options CMMI - 1.1 created to provide continuous evaluating a set of processes in a specific area of ​​software development or for phased assessing and improving the maturity of the enterprise, as well as for organizing the life cycle of software complexes in general. Models CMMI provide assistance to specialists in organizing and improving their products, as well as in streamlining and maintaining the processes of developing and maintaining software systems. The concept of these models covers the management and assessment of the maturity of complex systems, software engineering, and the processes of creating integrated software products and improving their development. The components of continuous and staged models are largely similar, and can be selected and applied in a different composition and sequence of use depending on the properties and characteristics of specific projects.

Model description options are built according to a single scheme, which includes general sections:

• preface;
• Section 1 - introduction;
• Section 2 - Component Model;
• Section 3 - Terminology;
• Section 4 - the content of the levels and the main components of each version of the model (development of goals and procedures);
• Section 5 - the structure of the interaction of processes; four categories of processes of section 7, their general overview and schemes of interaction of CMMI processes are annotated:
  • process management;
  • management - project management;
  • engineering (technology);
  • support;
• Section 6 - using the model CMMI- brief recommendations for users on the use of the model and training; the compatibility and compliance of the processes of the model with the regulated processes of the previous CMM model in parts 2 and 3 of the standard is noted ISO 15504.
• Section 7 is the last, the largest in each standard, it takes about 500 pages out of the total volume of the document, which is over 700 pages. This section provides detailed recommendations for implementing each of the processes listed in it, which take into account the characteristics of a particular model.

First option The (continuous) model reflects the document: Capability Maturity Model Integration (CMMI) for Systems Engineering / Software Engineering / Integrated Prod-uct and Process Development, Version 1.1, Continuous Representation (CMMI-SE / SW / IPPD, V1.1, Continuous). Integrated Maturity Assessment Model for Systems Engineering / Software Engineering / Integrated Products and Development Processes - continuous presentation... In this model, the seventh section is made up of processes:

• process management:
  • organization of training;
  • organization of transformation (changes) of processes;
  • organizing innovations and extensions;
• project management:
  • project planning;
  • monitoring and control of project processes;
  • Management of risks;
  • quantitative project management;
• engineering (technology):
  • requirements management;
  • development of requirements;
  • technical solutions;
  • product integration;
  • verification;
  • validation (certification, approval);
• support:
  • configuration management;
  • analysis and decision-making for changes;
  • analysis of causes and resolution of problems (elimination of defects).

Five annexes provide:

A- the composition of the literature and documents used, which, however, does not mention standards ISO;

V- abbreviations;

WITH- glossary based on terminology ISO applied in only four standards ISO 9000, ISO 12207, ISO 15504: 1-9, ISO 15288;

D - descriptions of requirements and proposals for the formation of model components by maturity levels;

E - list of participants in the development CMMI- the project.

In this model, attention is focused on organizational processes, on planning, management and control of the implementation of software projects, on the development and management of requirements for software products. Below are examples of granularity in CMMI some of them.

Project planning in this as well as in the second model it includes:

• appraisal possible size(scale) of the software product;
• assessment of the complexity of the functions and characteristics of the PS project;
• determination of the model and stages of the life cycle of a complex of programs;
• feasibility study of the project - determining the cost, labor intensity and duration of the life cycle of the PS;
• development of a phased work schedule and project budget;
• analysis, identification and assessment of project risks;
• planning and documenting management of processes and products in the life cycle of a PS project;
• planning and distribution of technical and human resources by stages of the life cycle of the PS;
• planning the provision of knowledge and qualifications of a team of specialists for the implementation of the project;
• generalization and analysis of the set of plans for the PS project;
• coordination of works and resources according to the life cycle stages by the developer with the customer of the PS project;
• documenting the work plan and approving it by the project developer manager.

Requirements development processes to the software product are similar to the processes in both models and include:

• identification of the real needs of the customer and users for the functions and characteristics of the software product;
• development and coordination between the customer and the developer of the initial, basic requirements for the functions of the software product;
• determination of available resources and limitations of the project complex of programs;
• decomposition of basic initial requirements for software systems functions into a set of requirements for components and tests of a software package;
• formalization of requirements for interfaces between components, with the operational and external environment;
• development of the concept of a software product and scenarios for its use;
• development of requirements for generalized characteristics of functional suitability and the use of functions of the software product for its intended purpose.

Requirements management in both models includes:

• achievement of an unambiguous understanding of the requirements for the PS project by the customer and developers;
• receipt by the customer from the developers of obligations to fulfill all his requirements for the software product;
• management of changes in requirements to the PS project agreed between the customer and the developer;
• ensuring the traceability of the correctness of changes from the general requirements for the PS project to the requirements for components and private processes;
• identification and identification of inconsistencies between the project development processes and customer requirements.

Second option presents the document: Capability Maturity Model Integration (CMMI) for Systems Engineering / Software Engineering / Integrated Product and Process Development, Version 1.1, Staged Representation (CMMI-SE / SW / IPPD, V1.1, Staged). Integrated Maturity Assessment Model for Complex Systems Engineering / Software Engineering / Integrated Products and Development Processes - phased presentation... The model is based on maintaining the concept of five levels of maturity CMM[,]. The composition of the processes practically repeats the one given above for the first version of the model, but in a slightly different sequence and with relatively small additions.

First level is characterized by significant uncertainty in the composition and content of processes in various relatively simple projects, therefore, it is not commented on in the document. Therefore, when clarifying and detailing the content of the processes in a phased version CMMI it is recommended to limit four main levels:

• second level- formalizes basic management projects:
  • requirements management;
  • project planning;
  • project monitoring and control;
  • management of agreements with suppliers;
  • measurement and analysis of processes and products;
  • quality assurance of processes and products;
  • configuration management;
• third level- contains the standardization of the main processes:
  • development of requirements;
  • technical solutions;
  • product integration;
  • verification;
  • validation (certification);
  • the content of organizational processes;
  • definition of organizational processes;
  • organization of training;
  • integrated management of project processes and products;
  • Management of risks;
  • integration of the development team;
  • integrated supplier management;
  • analysis and resolution of problems (elimination of defects);
  • organization of the environment for integration;
• fourth level- defines quantitative management:
  • organization of the presentation of the quality of processes;
  • quantitative management of the entire project and resources;
• fifth level- optimization, continuous improvement:
  • organization, innovation, quantitative process and resource management;
  • analysis of the causes of defects, improvement of quality and management of processes and products.

The applications in the second version of the model are similar in composition to the above applications for the first model. It is recommended to apply at each higher maturity level all processes previous lower levels. In both versions of the model, each one highlighted above, the basic process is commented on with detailed recommendations for its practical implementation, which contain unified descriptions of about 20-30 pages in size:

• the overall objectives of the process to be achieved;
• introductory remarks and general description process functions;
• specific goals of the process;
• process management;
• development of process requirements;
• interaction and interfaces with other processes;
• practical goals are the required outputs of the process activities;
• planning actions in a certain process;
• analysis and validation (approval) of the results of the process implementation;
• monitoring and control of the process.

These recommendations for the volume, content and completeness of the descriptions of the basic processes are similar to a number of standards for the life cycle of the PS presented in. Streamlining and assessing the completeness of the processes used in accordance with the levels of maturity, allows you to establish the production potential of enterprises - software developers according to the predicted quality of processes and the results of their activities and readiness for certification for compliance with a certain level of model maturity CMMI - 1.1.

Special attention in models CMMI is given to the processes of management of the PS project. These requirements and model processes are closely aligned with the specified and detailed guidelines in the standards. ISO 9001: 2000 and the main components of the life cycle standards profile for complex software systems [,]. Requirements for processes in functional clauses 4-8 of the standards ISO 9001, ISO 9004, ISO 90003 a number of sections in the model that are adequate in content can be compared CMMI(in Figure 1 there is a containment overlap). The commonality of processes and requirements consists in the similarity: composition, terminology, structure, a list of recommended management processes, planning, accounting for available resources, implementation of software engineering processes, assessment and organization of specialists.

Figure 1. Commonality of processes and requirements of standards and maturity models

From the point of view of support and regulation of the full life cycle of large software projects to the disadvantages of models CMMI on the profile of existing standards ISO include the following:

To determine the above levels of maturity of the processes of ensuring the life cycle of the software system, an extensive technical report was developed and initially approved in 1998 ISO 15504, consisting of nine parts and many applications. It lays out the maturity model CMM and eight basic principles of software engineering based on the standard ISO 9000: 2000... Then in ISO this document has undergone a radical revision, reduction, simplification of structure and content, with full preservation of the goals and concept, and was approved as standard in five parts.

Standard ISO 15504: 1-5: 2003-2006 regulates the assessment and attestation of the maturity of the processes of creation, maintenance and improvement of software tools and systems performed by enterprises:

• to establish the state of their own technological processes and improve them;
• to determine the suitability of your own processes to meet specific requirements or classes of customer requirements;
• for the purpose of its suitability for the fulfillment of certain contracts with customers of PS and systems.

The standard contributes to: self-certification of the maturity of enterprises, ensuring adequate management of certified processes, determining the profile of process ratings, and is also suitable for any areas of application and sizes of PS and systems. The application of the standard is aimed at developing enterprises and specialists culture of continuous improvement of technology maturity ensuring the life cycle of the PS that meet the business goals of projects and optimize the use of available resources. The attestation of the maturity of enterprise processes provides the possibility of their comparison and selection, which are preferable for certain projects:

• for customers, buyers, users of software products and systems: the ability to determine the current and potential maturity of the supplier's life cycle processes;
• for suppliers and developers: the ability to determine the current and potential maturity of their own processes of the life cycle of software and systems, areas and priorities for process improvement;
• for maturity assessors: a basis for conducting and improving attestation processes.

Approvals in the standard are addressed in two aspects: to improve the processes of the life cycle of the PS and systems of a particular enterprise and to determine the compliance of the declared maturity of the processes of ensuring the project or enterprise with the real processes used. This is reflected in the next five parts of the standard ISO 15504: 1-5: 2003-2006.

Part 1 - Concept and vocabulary. Contains general information on the processes of attestation of the maturity of software and systems and recommendations for the use of parts of the standard. The general requirements for attestation, terminology, structure are stated, the scope of the remaining parts of the standard is determined.

Part 2 - Execution (production) of attestation. Includes detailed requirements for the attestation processes as a basis for improving and determining the level of maturity of technological processes for ensuring the life cycle of software and systems. The document defines processes for performing attestation, models of recommended attestation processes and process verification so that they are objective, meaningful and representative.

Part 3 - Manual for the production of attestation. Provides an overview of the technology for performing maturity attestation processes and interpreting the implementation of requirements. It reflects: performance of certification; measuring instruments for determining maturity processes; selection and application of certification tools; assessment of the competence of assessors; verification of the conformity of the certification to the declared requirements. Certification tools can be used by enterprises in planning, management, monitoring, control and improvement of software products and systems, in their acquisition, development, application and maintenance.

Part 4 - User guidance for improvement processes and process maturity determination on these two aspects. A number of steps are recommended, which include: applying the results of the qualification processes; setting goals for attestation of maturity; determination of the initial data for attestation; assessment of the possible reduction of the resulting risks; steps to improve processes; steps to determine the level of maturity; comparing the results of the attestation analysis with the requirements.

Part 5 - A sample model of the validation processes for compliance with the requirements presented in Part 2. The extensive document (162 pages) provides examples of the practical application of the previous parts of the standard to organize, evaluate and improve the attestation of maturity of life cycle processes for various use areas, software projects and enterprises.

In the practical implementation of projects and ensuring the life cycle of complex software systems, it is sometimes difficult for developers and suppliers to identify and isolate the advantages of models for use. CMMI... Depending on the traditions of the enterprise and the characteristics of a large PS project, it is often advisable to use a complete standards profileISO, and for evaluation by customers maturity level management, organizational and technological support of PS projects to apply specific recommendations CMMI... These recommendations can be effectively used when process quality certification at enterprises providing life cycle services, as an alternative to or along with certification according to a set of management standards ISO 9000, depending on the specifics of the project and the applicant's requirements for certification of a software product or technology to ensure its life cycle.

Organization of certification of software products

Certification consists of a number of organizational processes that make up certification system These processes are supported by regulated procedures and documents and must be carried out by qualified, certified expert inspectors. For certification of the developer enterprise and the results of its activities - software products, models CMMI or standards profiles ISO[,] a certain discipline is recommended, which should be adapted to the specific characteristics of objects and the external environment of the software system's life cycle. The processes and documents listed below are focused on large projects, and their composition can be reduced by agreement between developers, customers and certifiers in simpler cases.

Certification work begins with the accreditation of a body or testing laboratory, the formation and submission of an application and a set of documents to the Central Certification Body for making a decision on the expediency of accreditation. If the test results are positive, an accreditation certificate is issued and issued.

Regulation on the certification body or laboratory is the main document that establishes the thematic area of ​​accreditation, legal status, functions, structure, rights and obligations, methods, means and organization of tests. The passport of the certification laboratory (center) must contain information about the equipment with computer equipment necessary for testing, personnel and personnel, equipment with testing tools, provision of regulatory, technical and methodological documents, as well as other resources necessary for testing.

Quality quide contains a statement of principles, a description of the methods and procedures associated with the implementation of the main functions and tasks of the certification body or laboratory, ensuring the quality of the tests performed and confidence in the results of evaluations, tests and examinations. The quality manual usually includes sections [TWLSC $

• quality assurance policy for testing and examination;
• equipping the center with up-to-date methodological materials and software and testing tools;
• formalization of requirements for test objects;
• policy in the field of technical equipment of the center and staff development;
• archiving and control over the safety of documentation of certification results.

The applicant for evaluating the product or process subject to certification shall send an application to the certification body in the form adopted in the certification system. The certification body carries out work on the preparation and organization of product certification upon request. This work includes:

• selection of a certification scheme taking into account the specifics of the product (volume, technology, requirements of regulatory documents, etc.) and the developer's proposals;
• determination of the number and order of sampling and components to be tested, if this is not specified in the standards;
• selection and determination of an accredited testing laboratory that should conduct tests;
• preparation of a draft contract for the performance of work.

The preparatory part of the certification work ends with the release of a decision in the form adopted in the certification system. The decision, together with the draft contract for the performance of work, is sent to the applicant. When organizing certification tests, the selection and study of the current regulatory documents for products declared for certification, methods of their testing and evaluation of results are carried out.

The applicant makes the final decisions which elements of the quality system, areas and types of organizational and technical activities are subject to verification during certification in a given time interval. The applicant must create conditions and submit documents to support the verification processes. He can submit to the certification body the test reports carried out during the development and launching of products for production, documents on tests performed by third-party testing laboratories and other documents confirming the compliance of the technology or products with the established requirements. Based on the analysis of the documentary evidence provided with the application for the conformity of its products to the established requirements, the certification body may decide to reduce the scope of tests or issue a certificate.

Tests are carried out by testing laboratories accredited to carry out only those tests that are provided for in their regulatory, accreditation documents. If it is impossible to carry out tests at the testing base of an accredited laboratory, tests can be carried out by the personnel of this laboratory at the manufacturer or consumer of this product using the testing laboratory's own means or testing tools available from the supplier.

The process of certification of software products and quality systems of an enterprise includes:

• analysis and selection by the developer or customer (applicant) of a body and a certified laboratory competent in this area to perform certification tests;
• the applicant submits an application for testing to the certification body and the certifiers make a decision on the application, the choice of a certification scheme, the conclusion of a certification contract;
• identification of requirements for the quality system of the enterprise and / or for the version of the software product to be tested;
• performance of certification tests of the quality system of the enterprise or version of the software product by the certification laboratory;
• analysis of the results obtained and making a decision by the laboratory and / or the certification body on the possibility of issuing a certificate of conformity to the applicant;
• issuance by the certification body to the applicant - a certificate and license for the use of the conformity mark and for the release of certified products - versions of the software product;
• implementation of inspection control by the certification body of the certified quality system of the enterprise and / or products;
• taking corrective measures by the applicant in case of violation of the compliance of the processes of the quality system and / or products with the established requirements and in case of incorrect use of the conformity mark.

The review of the developer's management responsibility for product quality should determine whether the facility or project has a documented quality policy, goals and commitments, as well as the extent to which the policy is understood, implemented and maintained at all levels of the organization. It should be established that the enterprise has a management representative who, regardless of other duties, has the authority and responsibility for the continuous implementation of the requirements of the standards and regulatory documents of the quality system. It is necessary to check the availability of requirements, procedures, tools and trained personnel for the practical implementation of the quality system processes, as well as the relevance and regularity of documentation for all components, requirements and provisions of the quality system, which is an integrated process throughout the life cycle of the PS. Quality system checks should include a definition:

• availability and completeness of technological documentation and compliance with its requirements in practice;
• the state of technological equipment and the availability of a system for their maintenance;
• the availability and effectiveness of the control and testing system;
• condition of measuring and testing instruments;
• availability of a system for identifying and eliminating identified deficiencies in products or technology.

Based on the tests, the results obtained are evaluated and conclusions about the conformity or non-conformity of products or processes with the requirements of regulatory documents are substantiated. Test reports are submitted to the certification body, as well as to the applicant at his request. Test reports are subject to storage for the periods established in the rules of product certification systems and in the documents of the testing laboratory, but not less than three years.

After receiving and checking the completeness and quality of the documentation by the specialists of the testing laboratory, examination of the degree of real application of the quality system at the enterprise. Testing begins with a quality system audit program, which should serve as a work plan for subsequent work. The program is an internal working document of the testing laboratory and must contain a list of works, detailed in accordance with the specifics of the developer and including an analysis of the completeness and quality of the submitted source documents and the degree of their practical application in the design, development and delivery of software systems. The examination of the application of the quality system procedures is carried out by the testing laboratory at the workplaces of the enterprise that provides the life cycle of the PS. Checks are carried out on the availability of specialists-developers of the relevant documents at the workplace and on the completeness of the use of their provisions and recommendations. Project status reviews and internal audits of the quality system, processes and / or products should be performed by personnel independent of those directly responsible for the work.

Development quality control methodologies must be provided with the necessary resources to carry out the test program, planning methods and the development of private inspection procedures. The methods should contain: objects and purposes of testing; assessed quality indicators; conditions and procedure for testing; methods of processing, analysis and evaluation of test results; test technical support and reporting. The hardware and software used during the tests and the test procedure, as well as the expected test results, should be indicated. Methods for monitoring corrections, actions to correct defects should be developed, if such a request is received by the inspection management service. The test program management service should develop methods for maintaining the confidentiality of any test information, as well as data held by experts.

Test reports submitted to the applicant and the certification body. The applicant may submit to the certification body test reports, taking into account their validity periods, carried out during the development and launching of products for production, or documents on tests performed by domestic or foreign test laboratories accredited or recognized in the certification system. Based on the certification test protocols, the results obtained are evaluated and the conclusions drawn about the conformity or non-conformity of the products with the requirements of regulatory documents are substantiated.

Conclusion on the results of certification tests is developed by certifiers and contains generalized information about test results and justification of the advisability of issuing a certificate. In the event of negative results of certification tests, a decision is made to refuse to issue a certificate of conformity. After revision of the certified product or the quality system, the tests can be repeated. Results of analysis of the state of technology or product quality formalized by an act, which provides assessments for all items of the Test Program and contains conclusions, including overall assessment the state of production and products, the need for corrective measures. The act is used by the certification body, along with test reports, an application for the issuance and determination of the validity period of a certificate for a software product, the frequency of inspection control, as well as for drawing up corrective measures.

Based on the results of certification tests and examination of documentation, a decision is made to issue a certificate. In the event of negative results of certification tests, a decision is made on refusal to issue a certificate compliance. In addition, the applicant enterprise can be sent proposals to eliminate the alleged causes of negative test results, after the completion of the certified product, the tests can be repeated.

The certification body, after analyzing test reports, evaluating production, certifying the quality system, analyzing the documentation specified in the decision on the application, assesses the conformity of products to the established requirements, draws up a certificate based on the expert opinion and registers it. When changes are made to the design or operational documentation that can affect the quality of the system or software product, certified during certification, the applicant must notify the certification body to make a decision on the need for additional tests. After registration, the certificate comes into force and is sent to the applicant company. Simultaneously with the issuance of the certificate, the applicant enterprise may be issued license for the right to use the conformity mark.

For certified software products during their operation during the entire period of validity of the certificate of conformity, inspection control... Inspection control is carried out in the form of periodic and unscheduled inspections of compliance with the requirements for the quality of technology and certified products. The objects of control, depending on the certification scheme, are certified products, quality system or production stability of the developer. When determining the frequency and volume inspection check the following factors are taken into account: the degree of potential danger of the software product, the stability of production, the volume of production, the presence and application of a quality system during development, information on the results of tests of the product and its production carried out by the manufacturer, authorities state control and supervision.

Inspection control results formalized by an act, which evaluates the results of sample tests and other inspections, makes a general conclusion about the state of production of certified products and the possibility of maintaining the validity of the issued certificate. The act is kept by the certification body, and copies of it are sent to the developer and to the organizations that took part in the inspection control. Based on the results of the inspection control, the certification body may suspend or cancel the validity of the certificate and revoke the license for the right to use the conformity mark in case of non-compliance of the product with the requirements of regulatory documents controlled during certification, as well as in the following cases:

• fundamental changes in the maturity model, profile of standards, product regulations or test method;
• changes in the design (composition), completeness of products;
• changes in the organization or technology of development and production;
• non-compliance with the requirements of technology, methods of control and testing, quality system, if the listed changes can cause non-compliance of products with the requirements controlled during certification.

The decision to suspend the validity of the certificate and license for the right to use the conformity mark is not made if, by means of corrective measures agreed with the certification body that issued it, the applicant can eliminate the discovered causes of non-conformity and confirm, without retesting in an accredited laboratory, the conformity of the product or processes to regulatory documents. If this cannot be done, then the validity of the certificate is canceled, and the license for the right to use the conformity mark is canceled. Information about the suspension or cancellation of the certificate is brought to the attention of the applicant, consumers and other interested organizations by the certification body that issued it. The validity of the certificate and the right to mark products with the conformity mark can be renewed if the developer enterprise fulfills the following conditions:

• identifying the reasons for non-compliance and eliminating them;
• submission to the certification body of a report on the work done to improve and ensure product quality;
• carrying out additional tests of products according to the methods and under the control of the certification body and obtaining positive results.

Documenting the processes and results of certification of software products

Composition and content of documentation for certification of the quality system enterprises depend on the characteristics of the design, development and modification of software, as well as on the requirements for their quality and the characteristics of the technological environment. Therefore, the required set of documents for each enterprise or project should be selected and adapted in relation to these characteristics. The indicators of the quality system assessed during certification are the availability of relevant documents and the practical fulfillment of the requirements of a certain level of the maturity model CMMI or an adapted standards profile based on ISO 9000: 2000, as well as, created on their basis, job descriptions by the specialists of the developer enterprise. The applicant must prepare and submit to the testing laboratory a set of documents agreed upon between the customer and the developer and an approved set of documents to check their reliability, sufficiency of composition and quality of manufacture in accordance with regulatory documents.

An indicative set of basic documents for certification consists of three groups:

• basic regulations quality systems in accordance with the nomenclature and content of the standards profile based on ISO 9000: 2000 or maturity models CMMI, as well as the program, manual and instructions prepared by the developers on their basis, presented to the testers (experts) of the quality system or products of the audited enterprise;
• source documents characterizing a specific enterprise or project, as well as the life cycle of a software tool, prepared by the project management for certification of its quality;
• reporting documents of testers, reflecting the results of verification (certification) of the quality system of the enterprise and / or software product, submitted to the certification body, the applicant and the management of the audited enterprise.

The software product or quality system of the enterprise submitted for certification must be submitted together with the relevant documentation. The list and approximate content of the groups of these documents are focused on the general case of checking the quality systems of enterprises that ensure the life cycle of large software products. The set of documents can be reduced and adapted by agreement between the applicant, the certifier and the management of the audited enterprise in accordance with the characteristics of the software projects. Some documents can be combined into integrated reports with clear responsibility of certain specialists for their implementation.

Basic documents of the enterprise quality system and the life cycle of a software tool

1. Concept, terminology, requirements and guidance for performance improvement - quality management systems - ISO 9000: 2000 or a version of the CMMI maturity model.
2. Adapted versions or list of clauses and recommendations of standards ISO 12207, ISO 15504, their changes and application guides, highlighted during adaptation and mandatory for use in the quality system of a particular enterprise or software product project.
3. Adapted version or list of clauses and recommendations of the standard ISO 900003, allocated during adaptation and mandatory for use in the quality system of an enterprise that produces a software product.
4. Basic characteristics and quality attributes of the PS project, highlighted, adapted and specified on the basis of standards ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. An adapted version and an approved edition of the guidance on maintenance and configuration management based on the recommendations of the standards ISO 14764, ISO 10007, ISO 15846.
6. A set of job descriptions that define the responsibility, authority and procedure for interaction of all management, performing and checking the work of personnel participating in the enterprise quality system procedures for a specific PS project.

Source documents reflecting the features of the life cycle of a particular software tool

1. Description of the characteristics of software products created at the enterprise, the system and the external environment of their life cycle, necessary for the adaptation and preparation of working versions of the standards and requirements of the PS project and the enterprise quality system in accordance with the recommendations of the standards ISO 12207, ISO 15504, ISO 90003 and ISO 9126.
2. Description of the goals, requirements and obligations of the enterprise developer in the field of the quality system, quality criteria for the processes and products of development, delivery and support of the entire life cycle of the software system.
3. A set of operational documents supplied to the customer and users to ensure the life cycle and the use of a specific version of the software product based on adapted standards ISO 9294, ISO 15910, ISO 18019.
4. Documentation and automation tools for design, development, modification, control and testing used to ensure the life cycle of a software product.
5. Plans and methods for testing the application and evaluating the effectiveness of the processes of the enterprise quality system and software product.
6. Maintenance methods, identification of software product components and documentation, analysis and approval of versions of software and data complexes.
7. A methodology for configuration management, approval, storage, protection, copying of versions of a software product and accompanying documents, as well as accumulation and storage of data on quality characteristics registered in the archive of an enterprise during the life cycle of versions of a software product.

The resulting test documents - certification of the quality system of the enterprise and / or software product

1. A report on the availability, relevance and systematicity of documentation, adapted to the requirements and provisions of the enterprise quality system, which provides an integrated quality assurance process throughout the entire life cycle of a software product.
2. Results of monitoring and testing of the condition and application of the quality system carried out periodically to determine its suitability and effectiveness.
3. Report on the availability and maintenance of inspection procedures and documented reports on the results of the achieved quality of meeting the requirements of the certification agreement with the customer.
4. Results of registration of the achieved quality characteristics of the software package: identification, accumulation, storage of registered data on the characteristics and attributes of the quality of the software product and its components.
5. The results of the implementation of the development plan, documented input and output data of the development stages and protocols for verifying the implementation of the software life cycle.
6. The results of the practical implementation of the quality program and the implementation of regulated activities in the field of quality at all stages of the PS life cycle.
7. The results of certification of environmental simulators and test generators, as well as an assessment of their sufficiency for performing certification tests of a software product.
8. The results of the analysis of the implementation of plans and test methods, test reports, assessments of the compliance of test results with the requirements, as well as test results approved by representatives of the applicant, customer and supplier.
9. The act of the results of checks of the real characteristics of the life cycle of the software and the quality system of the enterprise, conclusions about their compliance with the requirements for certification of the production of a software product.
10. Certificate of the quality system of the enterprise and / or software product and ensuring its life cycle, license for the use of conformity marks.

Literature

V.V. Lipaev - Software lifecycle standards profiles. -- Jet Info, Newsletter, N 12, 2005

K. Milman, S. Milman - СММI - a step into the future. -- Open systems., N 5-6. (2005), N2. (2006), 2005, 2006

Assessment and attestation of the maturity of processes for creating and maintaining software and information systems ISO IEC TR 15504-CMMI. Per. from english -- M .: Book and business, 2001

V.V. Lipaev - Processes and standards for the life cycle of complex software. Directory.- M .: SINTEG, 2006

V.V. Lipaev - Quality assurance techniques for large-scale software.- M .: RFBR. SYNTHEG, 2003

"; antisource:" Software products are now used to solve management problems in almost all spheres of human activity: in the economy, social, military and other areas. Ensuring high quality of domestic software products during their mass development and delivery for various applications in the country and on the world market has become a strategic task. "; Condition: 1] $