5.2.2 Summary of life cycle processes

There are two important divisions of the process in this International Standard. Clause 6 provides a system context for working with a stand-alone software product or service, or software system. Clause 7 contains specific software processes for use in the implementation of a software product or service that is some element of a larger system.

To assist in the concurrent use of this International Standard, the corresponding processes in Clause 6 have the same subsection designations.

In general, the set of processes presented in this International Standard is tailored to the software tools or inputs to the results of the processes provided. Many of the processes are similar to software-specific process implementations, but they retain important differences based on goals, results, and audiences. Users of both this International Standard and this International Standard should be sure to consider the explanations and notes in each such specific process.

Agreement processes define the activities required to develop agreements between two organizations. If an acquisition process is implemented, it provides a means to conduct business with a supplier of products provided for use in a functioning system, support services for that system, or system elements developed as part of a project. If a delivery process is implemented, it provides the means to carry out a project in which the result is a product or service delivered to the acquirer.

Thus, the agreement processes given in this International Standard are software-oriented agreement processes from .

The project enablement processes manage the ability of organizations to acquire and deliver products or services through project initiation, support, and management. These processes provide the resources and infrastructure needed to support projects and ensure that organizational goals and established agreements are met. They do not claim to be a complete set of business processes that implement the management of the organization's business activities.

Project organizational support processes include:

a) model management process life cycle;

B) infrastructure management process;

c) the project portfolio management process;

d) human resources management process;

e) quality management process.

In general, the project management processes provided for in this International Standard are software-oriented processes from the corresponding set of processes in .

In this International Standard, the project is chosen as the basis for describing the processes related to planning, evaluation and control. The principles associated with these processes can be applied to any area of ​​organizational management.

There are two categories of project processes. The project management processes are used to plan, execute, evaluate, and manage the progress of a project. The project support processes ensure that specialized management objectives are met. Both categories of project processes are described below.

The project management processes are used to create and develop project plans, evaluate actual performance and progress against targets, and manage project progress through to completion. Individual project management processes may be invoked at any time in the life cycle and at any level of the project hierarchy, in accordance with project plans or the occurrence of unforeseen events. Project management processes are applied at a level of rigor and formalization depending on the risk and complexity of the project:

a) the project planning process;

b) project management and evaluation process.

Project support processes form a specific set of tasks focused on the fulfillment of specific management objectives. All of these processes are evident in the management of any initiated activity, extending from the organization as a whole down to the individual life cycle process and its objectives:

a) decision management process;

b) risk management process;

c) configuration management process;

d) information management process;

f) measurement process.

In general, the project support processes presented in this International Standard are identical to the project support processes given in , except for some differences in the form of their presentation. In some cases, Software Support Processes may have relationships with Project Support Processes.

Technical processes are used to define the requirements for the system, convert the requirements into a usable product, allow for continued copying of the product (where necessary), apply the product, provide the required services, maintain the provision of those services, and retire the product from circulation if it is not used in the provision of the service. .

Technical processes define the activities that enable the implementation of organizational and project functions to optimize the benefits and reduce the risks resulting from technical solutions and action. These activities enable products and services to have the properties such as timeliness and availability, cost effectiveness, as well as functionality, reliability, maintainability, productivity, usability, and other qualities required by acquiring and supporting organizations. It also enables products and services to meet the expectations or requirements of civil law, including health, safety, security and environmental factors.

Technical processes consist of the following processes:

a) determining the requirements of the right holders (a special case of the process for determining the requirements of the right holders, given in );

b) system requirements analysis (a special case of the requirements analysis process);

C) system architecture design (a special case of the architecture design process given in );

D) implementation process (a special case of the system element implementation process given in and further developed in Clause 7 of this International Standard as the software implementation process);

e) system integration process (a special case of the integration process given in );

f) system qualification testing process (a process that contributes to the achievement of the results of the verification process given in );

G) software installation process (a process that contributes to the achievement of the results of the transfer process in );

H) software acceptance support process (a process that contributes to the achievement of the outcomes of the handover process in );

i) software operation process (a special case of the operation process given in );

j) software maintenance process (a special case of the maintenance process given in );

k) the software retirement process (a special case of the retirement and retirement process in ).

In general, the technical processes presented in this International Standard are software-oriented by special cases or contributions to the results of the technical processes presented in . Most of them are similar to software implementation processes, but retain important differences, for example, system requirements analysis and software requirements analysis start from different starting points and have different purposes.

Software implementation processes are used to create a specific element of the system (component) made in the form of a software tool. These processes translate specified behaviors, interfaces, and implementation constraints into actions that result in a system element that satisfies the requirements arising from the system requirements.

A special process is a software implementation process that expresses a specific software feature of the implementation process given in .

The software implementation process includes several lower-level special processes:

a) software requirements analysis process;

B) software architecture design process;

c) detailed software design process;

d) software construction process;

e) software integration process;

f) software qualification testing process.

Software support processes provide a specifically focused set of activities aimed at performing a specialized software process. Any supporting process assists the software implementation process as a whole with a separate purpose, contributing to the success and quality of the software project. There are eight such processes:

a) software documentation management process;

b) software configuration management process;

c) software quality assurance process;

d) software verification process;

e) software validation process;

f) software revision process;

g) software audit process;

H) software problem solving process.

The Software Reuse Process Group consists of three processes that support an organization's ability to reuse software components across project boundaries. These processes are unique because, by their nature, they are used outside the boundaries of any particular project.

Software reuse processes are:

a) domain design process;

b) asset reuse management process;

C) software reuse management process.

The ISO/IEC 12207-95 standard defines the strategy and general order in the creation and operation of software, it covers the life cycle of software from the conceptualization of ideas to the completion of the life cycle (life cycle).

Standard features

Standard does not prescribe a specific life cycle model or software development method; It defines that the parties involved in the use of the standard are responsible =

1. for choosing a life cycle model for a software project,
2. for adapting the processes and tasks of the standard to this model,
3. for the choice and application of software development methods,
4. for performing activities and tasks appropriate for the software project;

ISO/IEC 12207-95 standard is equally focused on organizing the actions of each of the two parties: the supplier (developer) and the buyer (user); can be equally applied when both parties are from the same organization.

Standard definitions

System is the combination of one or more processes, hardware, software, equipment and people to enable certain needs or purposes to be met.

Life cycle model- a structure containing the processes, activities and tasks that are carried out during the development, operation and maintenance of a software product throughout the life of the system, from the definition of requirements to the completion of its use.

Qualification requirements- a set of criteria or conditions ( qualification requirements ) that must be satisfied in order to qualify a software product as meeting its specifications and being ready for use in the target environment.

The standard defines the general structure of the software life cycle in the form of a 3-stage model, consisting of:

1. processes,
2. · activities,
3. tasks

The standard does not define metrics, which could track the progress of work and their effectiveness. The largest elements are software life cycle processes. In total, 18 processes were identified, which are combined into 3 groups:

1. - basic processes;
2. - supporting processes;
3. - organizational processes;
4. -adaptation process.

Main life cycle processes

1) Acquisition process- its task is to determine the actions of the enterprise-buyer, which acquires automated system, software product or software service:

1. acquisition initiation;
2. preparation of a request for proposals;
3. preparation of the contract;
4. supplier analysis;
5. receiving software.

2) Transfer process(delivery) defines the activities of the supplier enterprise that supplies the buyer with a system, software product or software service.

3) Development process- its task is to determine the actions of the developer enterprise that creates the software product.
Includes the following works:

1. Deployment of the development process;
2. analysis of system requirements;
3. Designing (software and hardware) system as a whole;
4. analysis of software requirements;
5. design of software architecture;
6. detailed design;
7. coding;
8. debug testing;
9. software integration;
10. qualification testing of software;
11. system integration;
12. qualification testing of the system;
13. Deployment (installation or installation) of software.

4) Operating process determines the actions of the operator enterprise, which provides maintenance of the system during its operation in the interests of users. Includes works such as:

1. user consultation;
2. receiving feedback and etc.

5) Support process The software determines the actions of the escort personnel, which ensures:

1. installation and removal of a software product on a computer system;
2. analysis of emerging problems;
3. · alteration;
4. examination and transfer of modified software;
5. transfer of software from one platform to another;
6. Removal of the software from service.

Annotation: Logical continuation of the previous lecture. The problem is considered in detail practical application GOST R ISO/IEC 12207 in organizations and projects. In this regard, the standards GOST R ISO/IEC 15271 and GOST R ISO/IEC 16326 are being studied.

It should be obvious from the previous lecture that the implementation of GOST R ISO/IEC 12207 is a very difficult task. First of all, it is not clear what it means to "implement GOST R ISO / IEC 12207"? Can it be considered implemented if some of the organization's processes coincide with the processes of the standard, and some do not? Can a standard be considered implemented if some of the projects are carried out in accordance with it, and some are not? This list of questions can go on and on.

It is no coincidence that following GOST R ISO/IEC 12207, the GOST R ISO/IEC 15271-02 (GOST 15271, 2002) standard, which is called "Guidelines for the application of GOST R ISO/IEC 12207", was developed specially dedicated to the task of its implementation. We now turn to its consideration.

Standard GOST R ISO/IEC 15271

The meaning of the standard is revealed in its introductory section.

"1.2. Users of the standard.

This standard can be used by entities (persons, organizations) wishing to apply GOST R ISO / IEC 12207 in the implementation of contracts, regardless of the volume or complexity of the project, by a specific organization for self-control or improvement work life cycle processes software tools.

This International Standard specifies how GOST R ISO/IEC 12207 can be used in relation to different types software tools and which processes are appropriate for each case.

This standard complements GOST R ISO / IEC 12207, which is not only normative document, but also a benchmark for real project management. (For example, the latter case occurs when GOST R ISO / IEC 12207 is a model for part of the work of the improvement process). This International Standard should be understood as a whole, but specific sections may be used in individual cases."

The GOST R ISO/IEC 15271 standard consists of 8 sections and 4 Annexes. The substantive sections are called as follows (the numbering is taken from the text):

• 4. Basic concepts for the development of GOST R ISO / IEC 12207.
• 5. Implementation of GOST R ISO/IEC 12207.
• 6. Application in projects.
• 7. Application in organizations.
• 8. Applications life cycle models systems.

Section 4 is written in the style of comments and clarifications to the text of GOST R ISO/IEC 12207. The most important clarifications concern the interaction of GOST R ISO/IEC 12207 with corporate standards organization, the distinction between the concepts of "software" and "system" and the resulting distinctions between processes related to software and systems. The concept is described in detail quality management, implemented in GOST R ISO / IEC 12207. In general, the section gives the impression of a brief conceptual overview of GOST R ISO / IEC 12207, reminiscent of an educational note.

Clause 5 presents a general approach to implementation, called the implementation strategy GOST R ISO / IEC 12207. The strategy, according to the standard, is "a typical implementation method that should be followed when making changes to the activities of an organization or project." The strategy is implemented as a project, consisting of mandatory steps, described informally and without any connection with the processes of the organization. These steps are:

• a) development of an implementation plan;
• b) practical application of GOST R ISO/IEC 12207;
• c) conducting an escort pilot project(s);
• d) formalization of the implementation method;
• e) approval of the implementation method.

The development of an implementation plan includes defining the scope of GOST R ISO/IEC 12207. The scope can be, for example, a group of departments or projects of an organization. You can also define the scope as a set of key processes for the organization, which will be replaced by processes from GOST R ISO / IEC 12207. The implementation plan itself determines the composition of the projects performed during the implementation (there may be several of them). It goes without saying that when developing an implementation plan, necessary resources: financial, human, technical, etc.

In practical application, as one would expect, it is proposed to use the adaptation process described in GOST R ISO / IEC 12207 itself.

The strategy itself does not raise questions - such a sequence of steps can be quite effective in specific conditions, but it is worth noting that the formal project approach to the implementation of GOST R ISO / IEC 12207 is based on a simplified idea of ​​​​the real situation. Given that the processes of an organization (and its organizational structure) are constantly changing, I believe that it would be more methodologically correct to consider the implementation of the standard as an ongoing process, and not as a time-limited project. This process tracks changes to the organization's processes and starts individual projects, for example:

• projects for the application of GOST R ISO / IEC 12207;
• a project to train all new employees in GOST R ISO/IEC 12207 processes;
• a project for introducing changes to the implemented processes in connection with a change in the organizational structure of the organization; etc.

The approach to the implementation of GOST R ISO / IEC 12207 as a process, especially if it is supposed to start with its application in projects or individual departments of the organization, will allow concentrating responsibility for the overall result in the hands of the process owner, will make it possible to establish overall monitoring of results, etc. Obviously , the implementation should be followed by the maintenance of the implemented processes, which is also naturally organized as a process.

For more information on the application of GOST R ISO / IEC 12207 in projects, see Section 6 "Application in projects". The standard proposes to classify projects and for this it introduces a new concept - " life cycle model system" (a list of generic models is given in Appendix C). What a model is is not formally defined. life cycle model systems are divided into stages (stages) with subsequent adaptation of each of them to life cycle models a specific system" (the following is a list of stages). In total, three such models are considered: cascade, incremental, evolutionary. Their advantages and disadvantages are analyzed, and then the processes of GOST R ISO / IEC 12207 are "superimposed" on the structure of the models. As a result, these processes receive additional properties, such as multiple repetitions in the life cycle or overlapping in time with other processes.In addition, the section contains a lot of recommendations varying degrees usefulness regarding certain aspects projects. Here is a typical example.

"6.1.3. System characteristics

Subsystems and system configuration elements must be defined at the appropriate level of detail. It is necessary to define the characteristics of the system, especially those related to the software. When determining these characteristics, it is necessary to note which of them are critical in the operation of the system.

An indicative list of system-level characteristics (related to the software and subject to consideration) includes:

• intersystem and intrasystem interfaces;
• user interfaces;
• the impact of software bugs on security and system security;
• assessment of computing power and time constraints;
• availability of programs implemented by technical means;
• availability of appropriate computers.

If a system includes many subsystems or configuration items, they must be completely covered by the system-level work from the development process. All requirements for interfaces and assembly (integration) of systems must be taken into account. For a small system, such a strict sequence of steps may not be necessary."

Approximation and vagueness of the wording in the above passage are characteristic of the entire standard as a whole.

The following text serves as the central part of the very short section 7 "Application in organizations".

"7.2. Application possibilities

The reasons why GOST R ISO / IEC 12207 is implemented in organizations can be as follows:

• perfection test existing method. This is usually the case when the method has been developed by the organization itself or an existing method has been selected and modified by the organization;
• practical use this method to prevent the risk associated with entering new market sectors with more stringent requirements associated with potential risk;
• development of a new method, for example, to meet the needs new organization. This may include organizations created by merger or business cooperation. This may be necessary to support some models of the processes for providing specific work;
• implementation management new technology such as automating manual processes or changing the methods used to implement a software product. GOST R ISO/IEC 12207 establishes criteria that can be used to control the excellence of the respective method before or after a technology change;
• assessment of the internal capabilities of the party in terms of meeting the criteria of the contract, for example, as a party participating in the competitive (tender) process;
• identification of milestones from which improved programs can be developed, such as conducting an audit in accordance with GOST R ISO / IEC 12207 and using the improvement process itself.

Even with the complete absence of substantive objections, it is still impossible to consider this text as a standard. Most of all it reminds tutorial and in this capacity, it will probably be in demand, but such a text cannot be used as a guide to action when implementing GOST R ISO / IEC 12207 in an organization.

Finally, section 8 "Applied use life cycle models systems" contains rather vague definitions " life cycle models systems" and " life cycle models software tool" and tries to establish a correspondence between them. Since precise definitions absent, it is impossible to judge the results.

In general, the GOST R ISO / IEC 15271 standard gives the impression of a purely auxiliary document in relation to GOST R ISO / IEC 12207, suffering from approximation and an abundance of common places. It is unsuitable for practical managers - too much abstract reasoning and too little specificity. For students and professionals studying IT management processes, it lacks a broad view of the subject (after all, it is limited to GOST R ISO / IEC 12207) and is overloaded with unnecessary technical details. Nevertheless, familiarity with GOST R ISO / IEC 15271 is useful because it shows the direction of thought of specialists in the field of IT management, demonstrates where and how modern standards are developing. I would consider it as an interim working document, albeit in the form of a standard, but intended rather for discussion by an interested audience of IT management professionals.

Standard GOST R ISO/IEC 16326

Another attempt to formalize the process of applying GOST R ISO/IEC 12207 was made in GOST R ISO/IEC 16326 "Guidelines for the application of GOST R ISO/IEC 12207 in project management" (GOST 16326, 2002). He demonstrates an attempt to unite life cycle processes from GOST R ISO / IEC 12207 with project management processes from the popular methodological guide PMBOK 1 PMBOK- project management body of knowledge(PMBOK, 2009) and the ISO 10006 standard (the Russian version of the standard is contained in (GOST 10006, 2005)). This is shown schematically in Fig. 4.1 given in the standard.

Rice. 4.1.

The circle of users of the standard is quite precisely defined in section 1.1.

"1.1. Circle of users

This standard is intended for entities using or planning to use GOST R ISO / IEC 12207 in software projects, regardless of their scope, created products, methodology, scope or complexity. The standard is primarily intended for project administrators responsible for the compliance of management processes with GOST R ISO / IEC 12207:

• administrators responsible for the organization and continuous improvement life cycle processes software tools according to GOST R ISO/IEC 12207;
• administrators responsible for the application life cycle processes software tools according to GOST R ISO/IEC/12207 at the design level;
• organizations or persons who are subcontractors in the implementation of SCP ( Software Project Management. - AB).

Considerations for persons are given:

• involved in software projects, but not being AP ( Project Administrators. - AB);
• who are administrators of non-software projects, but related to software facilities".

The relatively short body text (clause 6 "Guidance" takes up only 9 pages out of a total of 35) is a consistent commentary on process 7.1 "Control" from GOST R ISO/IEC 12207 from the point of view of PMBOK. The style of the commentary is informal, the reasoning is mostly advisory in nature. The commentary does not go beyond ordinary common sense, and does not contain anything new. In general, this is useful reading for project managers (in the terminology of translators - "administrators") of projects, but nothing more.

Appendix A is one large table showing the relationships between the main GOST R ISO/IEC 12207 processes and the activities of the Control process called from them. All of these references are contained in the body of the GOST R ISO/IEC 12207 standard; bringing them into one table does not add any new information.

Annex B is exactly the same table linking process areas and individual processes from PMBOK to the activities of the Control process from GOST R ISO/IEC 12207.

A similar table using process groups in the sense of PMBOK instead of areas is given in Appendix C. Appendixes B and C actually summarize everything that was said in section 6 of the standard. Why it was necessary to present this in the form of tables is not clear. No additional information these tables are not carried, demonstrating only the fact of the existence of links between PMBOK and GOST R ISO / IEC 12207. However, the status of both Annexes is "reference", so they may not have had any independent value.

Another summary table is presented in Appendix D. It shows the links between three sources: GOST R ISO / IEC 12207, PMBOK and ISO 10006. I note right away that the latter was translated into Russian only in 2005; as a consequence, the terminology used in Appendix D of GOST R ISO/IEC 16326 2002 differs from later. As in the previous cases, the meaning of presenting these relationships in a compact tabular form is not clear. Moreover, the total volume Annexes A-D exceeds the volume of the main section 6 "Guidelines" more than twice.

In my opinion, GOST R ISO / IEC 16326-2002 does not differ in form and purpose from GOST R ISO / IEC 15271-2002. Both suffer from an excess of correct "in general" and based only on common sense reasoning. These considerations are obvious to anyone who has practical experience project management, and are unlikely to look reasonable to those who do not have such experience. Unlike GOST R ISO/IEC 15271-2002, GOST R ISO/IEC 16326-2002 is more formal, but the practical meaning of the proposed formalism is not clear.

From the point of view of practical application in the design of IT-related business processes, both standards are largely useless. On the other hand, they may be in demand in the implementation of complex projects, including, along with the study of IT management practices, analysis project management And quality management.

In addition to the GOST R ISO / IEC 12207 discussed above, a number of standards have come to life that detail the life cycle processes. These include, for example, GOST R ISO / IEC 15910-2002 "Process for creating software user documentation" (GOST 15910, 2002) and GOST R ISO / IEC 14764-2002 "Software maintenance" (GOST 14764, 2002). Some similar ISO standards have not yet been translated into Russian; it is likely that in the future the number of Russian-language GOST R ISO standards directly related to GOST R ISO / IEC 12207 will increase.

1) Allows to implement any life cycle model- this is possible, because The standard offers a way to define the sequence of execution of processes and tasks, in which one process can call another process or parts of it.

2) Provides maximum flexibility- many processes and tasks are designed so that they can be adapted in accordance with specific IS projects. Adaptation is reduced to the exclusion of processes, activities and tasks that are not applied in a particular project.

3) The standard fundamentally does not contain a description of specific methods of action, especially, blanks, solutions or documentation, it only describes the architecture of the software life cycle processes, but does not specify in detail how to perform or implement the tasks included in the processes.

4) The standard contains extremely few descriptions regarding database design- this is justified, because different ISs and different software systems can not only use specific types of databases, but may not use databases at all.

5) The value of the standard is that it contains sets of tasks, quality characteristics, evaluation criteria, etc., giving a comprehensive coverage of design solutions.

6) Although the standard does not mandate the use of a particular life cycle model or development method, it does specify that project parties are responsible for the following:

selection of the life cycle model for the project being developed;

adaptation of the processes and tasks of the standard to the selected model;

selection and application of software development methods;

performing activities and tasks appropriate for a given software project.

GOST 34 complex standards.

It was conceived as a comprehensive set of interconnected intersectoral documents.

Objects of standardization: automated systems of various kinds and all kinds of their components.

GOST standards provide for the stages and stages of work to create an automated system, but do not explicitly provide for end-to-end processes that take place during the implementation of the life cycle.

According to GOST, the development of an automated system is divided into the following stages and stages:

Stage 1 formation of requirements for the AU:

Stage a: inspection of the object and justification of the need to develop an automated system;

Stage b: formation of customer requirements for an automated system;

Stage c: development of a progress report and preparation of a development proposal terms of reference.

Stage 2 concept development:

a: study of the object;

b: carrying out the necessary R&D;

c: development of variants of the AU concept that meets the requirements of the customer;

d: development of a progress report.

Stage 3 development and approval of terms of reference for the creation of nuclear power plants.

Stage 4 NPP draft design development:

a: development of preliminary design solutions for the entire system as a whole and for its individual components;

b: documentation development.

Stage 5 development of a technical project:

a: development of design solutions for the entire system and for its parts;

b: development of documentation for the automated system and subsystems included in it;

c: development and execution of documentation for the supply of products for the acquisition of nuclear power plants or the development and execution of technical requirements for the development of these products.

stage 6 development of technical documentation:

a: development of working documentation for the system of its part;

b: software development or adaptation.

Stage 7putting the developed system into operation:

a: preparation of the automation object for the implementation of the AS;

b: staff training;

c: completing the AU with software and hardware;

d: installation work;

e: commissioning;

e: preliminary tests;

g: trial operation;

h: acceptance tests.

Stage 8 escorts:

a: performance of work in accordance with the warranty;

b: post-warranty service.

Russia currently uses the standard GOST R ISO/IEC 12207-2010 Software Life Cycle Processes ( ISO/IEC 12207:2008 System and software engineering — Software life cycle processes)

ISO/IEC 12207 - basic standard software life cycle processes, focused on various (any!) types of software and types of AS projects, where the software is included as a part. The standard defines the strategy and general order in the creation and operation of software, it covers the life cycle of software from the conceptualization of ideas to the completion of the life cycle.

General structure– see for yourself!

Peculiarities:

The ISO standard consists of very large generalized processes: "acquisition", "delivery", "development", etc. Roughly speaking, one such process is comparable to all CDM processes taken together. Each process is divided into a set of activities, each activity into set of tasks. A very important difference between ISO: each process, action or task is initiated and executed by another process as needed, and there are no predetermined sequences (naturally, while maintaining the logic of relationships according to the initial information of tasks, etc.).

- The "dynamic" nature of the standard is determined by the way in which the sequence of processes and tasks is determined, in which one process, if necessary, calls another or part of it. This character allows you to implement any model of life cycle.

Degree of adaptability: maximum. Many processes and tasks are designed so that they can be adapted in accordance with software projects. The tailoring process is the process of eliminating processes, activities, and tasks that are not applicable to a particular project.

The standard fundamentally does not contain specific methods of action, especially - preparations of decisions or documentation. It describes the architecture of the software lifecycle processes, but does not specify in detail how to implement or perform the services and tasks included in the processes, and is not intended to prescribe the name, format, or exact content of the resulting documentation. Decisions of this type are made using the standard.

The specificity of the use of the standard is that it contains sets of tasks, quality characteristics, evaluation criteria, etc., giving a comprehensive coverage of project situations. The standard does not prescribe a specific life cycle model or software development method, but specifies that the parties to the use of the standard are responsible for choosing a life cycle model for a software project, for adapting the processes and tasks of the standard to this model, for choosing and applying software development methods, for performing actions and tasks appropriate for the software project.

Degree of Requirement: Once an organization decides to apply ISO12207 as a condition of a trade relationship, it is its responsibility to specify the minimum set of required processes and tasks that constitute alignment with that standard.

MODEL SEI SW-CMM

Methodology CMM designed and developed in the USA as a tool to select the best manufacturers ON 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 a 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 is the de facto standard.

The basis for the creation of the CMM was the basic position that the fundamental problem of the "crisis" of the process of developing a quality ON is not the lack of new development methods and tools, but the inability of the company to organize technological processes and manage them.

To assess the readiness of an enterprise to develop a quality software SMM introduces key concept maturity of the organization (Maturity).

SMM defines 5 levels technological maturity of the company:

1. Level 1, initial - organizations that develop software, but do not have a conscious development process, do not plan and evaluate their capabilities;

2. Level 2, repeatable - in such organizations, resource costs are recorded and the progress of projects is monitored, project management rules are established based on existing experience;

3. Level 3, defined - in such organizations there is an accepted, fully documented, corresponding to the real state of affairs and accessible to the staff, the process of developing and maintaining software. This process should include both managerial and technical sub-processes, as well as training employees to work with it;

4. Level 4, managed - in these organizations, in addition to the established and described process, measurable indicators of the quality of products and the effectiveness of processes are used, which make it possible to accurately predict the amount of resources (time, money, personnel) required to develop a product with a certain quality);

5. Level 5 improving - in such organizations, in addition to the processes and methods for their assessment, there are methods for identifying weaknesses, procedures for searching and evaluating new development methods and techniques, training staff to work with them and their inclusion in general process organizations in the case of increasing production efficiency).

Each next level without fail includes all the key characteristics of the previous ones. Due to this certification companies on one of the levels implies the unconditional fulfillment of all the requirements of lower levels.