Introduction

The most important part of modern complex systems are software products - the intellectual component. Software products are now used to solve management problems in almost all areas of human activity: in the economy, social, military and other areas. Security High Quality domestic software products with them mass development and supply for various applications in the country and in the world market has become a strategic objective.

Currently, there are two almost independent areas of standardization in software engineering and software product quality assurance, which can be conditionally called ISO (International Standards Organization) standards profiles and SEI (US Software Engineering Institute) maturity models. The first ones are quite 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 software engineering maturity assessment model). These two directions are methodologically very close and partially intersect through mutual references.

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

To certify the quality, reliability and safety of the use of complex, critical systems, the software products used in them are subjected to certification certified, problem-oriented test centers or laboratories. Such tests should be carried out when programs manage complex, critical processes or process information so important that defects in them or insufficient quality can cause significant damage. Certification tests should 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 studied during the tests. These types of tests are characterized by the greatest severity and depth of checks and should be carried out by specialists independent of developers and customers (users).

The basis for certification should be detailed and effective programs and methods for testing software packages for compliance with standardized customer requirements, specially designed test problems and generators for their formation, as well as high qualification and authority of testers. Application at enterprises-developers of software products, certified quality systems for ensuring the life cycle of PS based on requirements 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, clients of complex software projects tend to choose implementing contractors who have certificates certifying their application of quality assurance systems based on adapted international standards profiles or maturity models.

Gaps in teaching software engineering methods leave a wide field 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. The growing complexity and responsibility of modern tasks solved by programs, as well as the possible damage from the insufficient quality of their results, has significantly increased the relevance of mastering methods for a complete, standardized description of the requirements for quality characteristics and methods for measuring their real, achieved values ​​at various stages of the software life cycle. The need for specialists to know the concepts, definitions and methods for evaluating the characteristics of the quality 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' promises in contracts to deliver high-quality software within agreed timeframes are often not kept. Often this happens due to the fact that the customer and the contractor evaluate the quality level according to different criteria, and they do not have agreement on this issue, and the approach to assessing the quality of programs is not formalized enough. In addition, sometimes there is a lack of ability to properly assess the resources needed to achieve high quality programs. As a result, the quality of software products often remains low, unreliable and uncompetitive on 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 the software and its reliable evaluation with the main goal - to make project processes manageable, 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 application of complex software packages, 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. Significant attention in CMMI is given to development processes and accounting for iterations when changing customer requirements, their traceability to functions, components, tests and project documents. Recently, information has appeared about the modernization of the SEI version of the 2003 version. CMMI-1.1 based on accumulated experience and feedback from enterprises. It is supposed to release in 2006 a new, significantly upgraded version of the model CMMI-1.2, after which version 1.1 should be phased out. Until the end of 2007, users should switch to the version CMMI-1.2, and in the future it will become mandatory for a formalized assessment of the quality (certification) of enterprise technology in the field of software engineering. The validity period of the certificate will be limited to three years. Customers and developers of large software systems should prepare for these changes before 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 designed to provide continuous evaluating a set of processes in a specific area of ​​software development or for phased evaluating and improving the maturity of the enterprise, as well as for organizing the life cycle of program complexes in general. Models CMMI provide assistance to specialists in organizing and improving their products, as well as in streamlining and servicing the processes of developing and maintaining PS. The concept of these models covers the management and evaluation of the maturity of complex systems, software engineering, as well as the processes of creating integrated software products and improving their development. The components of the continuous and phased 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:

• foreword;
• 1 section - 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; the four categories of processes in section 7 are annotated, their general overview and the interaction schemes of CMMI processes:
  • process management;
  • management - project management;
  • engineering (technology);
  • support;
• Section 6 - Using the Model CMMI- brief recommendations for users on the application of the model and training; the compatibility and compliance of the model processes with the regulated processes of the previous CMM model in parts 2 and 3 of the standard are noted ISO 15504.
• Section 7 is the last, largest in each standard, it takes up about 500 pages of the total document, which is over 700 pages. This section provides detailed recommendations for the implementation of each of the processes listed in it, which take into account the characteristics of a particular model.

First option(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 System Engineering/Software Engineering/Integrated Products and Development Process Maturity Assessment Model - continuous view. In this model, the seventh section consists of processes:

• process management:
  • organization of training;
  • organization of transformation (changes) of processes;
  • organizing innovations and expansions;
• project management:
  • project planning;
  • monitoring and control of project processes;
  • Management of risks;
  • quantitative project management;
• engineering (technology):
  • requirements management;
  • requirements development;
  • technical solutions;
  • product integration;
  • verification;
  • validation (attestation, approval);
• support:
  • configuration management;
  • analysis and decision-making on changes;
  • root cause analysis and problem resolution (defect elimination).

The five appendices provide:

BUT- the composition of the used literary sources and documents, which, however, does not mention standards ISO;

AT- abbreviations;

FROM- glossary based terminology ISO used 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 development participants CMMI- project.

In this model, attention is focused on organizational processes, on planning, managing and controlling the processes for implementing software projects, on developing and managing requirements for software products. The following are examples of details in CMMI some of them.

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

• assessment of the possible size (scale) of the software product;
• assessment of the complexity of the functions and characteristics of the PS project;
• definition of the model and stages of the life cycle of the software package;
• feasibility study of the project - determination of the cost, labor intensity and duration of the life cycle of the substation;
• development of a phased work schedule and project budget;
• analysis, identification and assessment of project risks;
• planning and managing documentation of processes and products in the life cycle of the 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 for the stages of the life cycle by the developer with the customer of the PS project;
• documenting the work plan and its approval by the project developer manager.

Requirements Development Processes to a 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 software suite project;
• decomposition of the basic initial requirements for the functions of the PS into a set of requirements for the components and tests of the software package;
• formalization of requirements for interfaces between components, with the operating and external environment;
• development of the concept of a software product and scenarios for its use;
• development of requirements for the generalized characteristics of functional suitability and the use of the functions of the software product for its intended purpose.

Requirements Management both models include:

• achieving an unambiguous understanding of the requirements for the PS project by the customer and developers;
• obtaining by the customer from the developers of obligations to fulfill all its requirements for the software product;
• management of changes in the requirements for the PS project agreed between the customer and the developer;
• ensuring the correctness of changes from the general requirements for the PS project to the requirements for components and particular processes;
• identifying and identifying discrepancies between 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 System Engineering/Software Engineering/Integrated Products and Development Process Maturity Assessment Model - phased introduction. 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 processes in a phased version CMMI recommended to be limited four main levels:

• second level- formalizes basic project management:
  • requirements management;
  • project planning;
  • project monitoring and control;
  • management of agreements with suppliers;
  • measurement and analysis of processes and products;
  • ensuring the quality of processes and products;
  • configuration management;
• third level- contains the standardization of the main processes:
  • requirements development;
  • 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 representation of the quality of processes;
  • quantitative management of the entire project and resources;
• fifth level- optimization, continuous improvement:
  • organization, innovation, quantitative management of processes and provision of resources;
  • analysis of the causes of defects, improvement of quality and management of processes and products.

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

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

These recommendations in terms of the scope, content and completeness of descriptions of basic processes are similar to a number of standards for the PS Life Cycle Profile presented in. Ordering and evaluating the completeness of the processes used in accordance with the levels of maturity, allows you to establish the production potential of enterprises - developers of software products in terms of the predicted quality of processes and the results of their activities and readiness for certification for compliance with a certain level of maturity of the model CMMI - 1.1.

Emphasis on models CMMI is given to the management processes of the PS project. These requirements and processes of the models practically correspond to the regulated and detailed recommendations in the standards. ISO 9001:2000 and the main components of the profile of complex PS life cycle standards [ , ]. Requirements for processes in functional sections 4-8 of the standards ISO 9001, ISO 9004, ISO 90003 a number of sections adequate in content can be compared in the model CMMI(in Fig. 1, the content overlap zone). The commonality of processes and requirements consists in the similarity: composition, terminology, structure, list of recommended management processes, planning, accounting for available resources, implementation of software engineering processes, evaluation and organization of specialists.

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

From the point of view of supporting and regulating the full life cycle of large software projects, the shortcomings of models CMMI regarding the profile of existing standards ISO can include the following:

An extensive technical report was developed and initially approved in 1998 to determine the levels of maturity of the processes for ensuring the life cycle of the PS presented above. ISO 15504, consisting of nine parts and many applications. It outlines the maturity model CMM and eight basic principles software engineering based on the standard ISO 9000:2000. Then in ISO this document has undergone a radical revision, reduction, simplification of the structure and content, while fully maintaining the goals and concept, and approved as standard in five parts.

Standard ISO 15504:1-5:2003-2006 regulates the assessment and certification of the maturity of the processes of creating, maintaining and improving software tools and systems performed by enterprises:

• to establish the state of their own technological processes and their improvement;
• to determine the suitability of own processes to meet specific requirements or classes of customer requirements;
• with a view to its suitability for performance certain treaties with customers of PS and systems.

The standard contributes to: self-assessment of the maturity of enterprises, ensuring adequate management of attested processes, determining the profile of process ratings, and also fits any scope and size of OS and systems. The application of the standard is aimed at developing enterprises and specialists culture of continuous improvement technology maturity ensuring the life cycle of the PS that meets the business goals of the projects and optimizing the use of available resources. Enterprise process maturity assessment provides an opportunity to compare and select them, 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 vendors and developers: the ability to determine the current and potential maturity of their own software and systems life cycle processes, areas and priorities for process improvement;
• for matriculation assessors: a framework for conducting and improving assessment processes.

Approval in the standard is dealt with in two aspects: to improve the life cycle processes of the PS and systems of a particular enterprise and to determine whether the declared maturity of the project or enterprise support processes corresponds to the actual processes used. This is reflected in the following five parts of the standard. ISO 15504:1-5:2003-2006.

Part 1 - Concept and vocabulary. Contains general information about the processes for certification of the maturity of software and systems and recommendations for the use of parts of the standard. Outlined General requirements for certification, terminology, structure, the scope of the remaining parts of the standard is determined.

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

Part 3 - Guidance for the production of certification. Provides an overview of the technology for performing maturity assessment processes and interpreting requirements implementation. It reflects: performance of certification; measuring tools for determining maturity processes; selection and application of certification tools; assessing the competence of certifiers; verification of conformity of attestation to the declared requirements. Validation tools can be used by enterprises in planning, managing, monitoring, controlling and improving software products and systems, in their acquisition, development, application and maintenance.

Part 4 - User guidance for process improvement and process maturity in these two aspects. A number of steps are recommended which include: applying the results of the validation processes; setting goals for maturity assessment; determination of initial data for certification; 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 qualification analysis with the requirements.

Part 5 - Sample model of attestation processes for compliance with the requirements presented in Part 2. An extensive document (162 pages) provides practical examples of the previous parts of the standard for organizing, evaluating, and improving life cycle process maturity assessments for various application areas, software projects, and enterprises.

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

Organization of certification of software products

Certification consists of a series 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 experts - inspectors. For certification of the enterprise-developer 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 the objects and the environment of the life cycle of the PS. The processes and documents listed below are designed for large projects and may be reduced by agreement between developers, customers, and certifiers in simpler cases.

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

Regulations on the certification body or laboratory is the main document that establishes the subject 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 computer science necessary for testing, on 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 the 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 and confidence in the results of assessments, tests and examinations. The quality manual usually includes sections [ TWLSC$

• policy in the field of quality assurance of testing and examinations;
• equipping the center with relevant 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 safety control of documentation of certification results.

For evaluation of products or processes subject to certification, the applicant sends 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 application. This work includes:

• selection of a certification scheme taking into account the specifics of products (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 identification of an accredited testing laboratory to carry out the tests;
• preparation of a draft contract for the performance of work.

The preparatory part of the work on certification 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, selection and study of the current regulatory documents for products declared for certification, methods of testing and evaluating the 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 ensure the verification processes. He can submit to the certification body test reports carried out during the development and production of products, documents on tests performed by third-party testing laboratories and other documents indicating the compliance of the technology or products with the established requirements. Based on the analysis of the documented evidence of the conformity of its products with the established requirements, presented with the application, the certification body may decide to reduce the scope of tests or to issue a certificate.

Tests are carried out by testing laboratories accredited to conduct only those tests that are provided for in their regulatory, accreditation documents. If it is not possible to conduct tests at the testing facility 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 facilities or the test facilities available from the supplier.

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

• analysis and selection by the developer or customer (applicant) of a body competent in this field and a certified laboratory to perform certification tests;
• submission by the applicant of an application for testing to the certification body and the adoption by the certifiers of a decision on the application, the choice of a certification scheme, the conclusion of a certification agreement;
• identification of requirements for the enterprise's quality system and / or for the version of the software product to be tested;
• performance of certification tests of the company's quality system or version of the software product by the certification laboratory;
• analysis of the results obtained and decision-making by the laboratory and/or certification body on the possibility of issuing a certificate of conformity to the applicant;
• issue by the certification body to the applicant - a certificate and a license to use the mark of conformity and to issue 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;
• carrying out by the applicant of corrective measures in case of violation of the conformity of the processes of the quality system and / or products with the established requirements and in case of incorrect application of the mark of conformity.

When checking the responsibility of the developer's management for product quality, it should be determined that the enterprise or project has a documented policy, goals and obligations in the field of quality, as well as the degree to which this policy is understood, implemented and maintained in working order 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. The availability of requirements, procedures, tools and trained personnel for the practical implementation of the quality system processes should be checked, as well as the relevance and systematic documentation of 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 existence and effectiveness of the control and testing system;
• state 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 compliance or non-compliance 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, the specialists of the testing laboratory should carry out examination of the degree of actual application of the quality system at the enterprise. Testing begins with the development of a quality system test program, which should serve as a working plan for subsequent work. The program is an internal working document of the testing laboratory and should contain a list of works, detailed in accordance with the specifics of the developer enterprise 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 the software. 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 presence of specialists-developers of relevant documents at the workplace and on the completeness of the use of their provisions and recommendations. Reviews of the status of the project and internal audits of the quality system, processes and/or products should be carried out by personnel independent of those directly responsible for the implementation of these works.

Methods for checking the quality of development should be provided necessary resources for the implementation of the test program, planning methods and the development of private test procedures. Methods should contain: objects and goals of testing; assessed quality indicators; conditions and procedure for testing; methods of processing, analysis and evaluation of test results; technical support testing and reporting. The hardware and software used during the tests and the test procedure, as well as the expected results of the checks, should be indicated. Methods should be developed to control corrections, actions to correct defects, if such a request is received by the audit management service. The test program management service should establish procedures for maintaining the confidentiality of any test information, as well as data held by assessors.

Test reports submitted to the applicant and to the certification body. The applicant may submit to the certification body test reports, taking into account the terms of their validity, carried out during the development and production of products, or documents on tests performed by domestic or foreign testing laboratories accredited or recognized in the certification system. On the basis of certification test protocols, the results obtained are evaluated and the conclusions drawn about the compliance or non-compliance of 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 the test results and the rationale for issuing a certificate. In case of obtaining negative results of certification tests, a decision is made to refuse to issue a certificate of conformity. After completion of the certified product or quality system, the tests can be repeated. The results of the analysis of the state of technology or product quality are drawn up by an act, which gives estimates for all positions of the Test Program and contains conclusions, including a general assessment of 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 issuing and determining the validity period of a certificate for a software product, the frequency of inspection control, and also 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 case of obtaining negative results of certification tests, a decision is made to refusal to issue a certificate compliance. In addition, proposals can be sent to the applicant enterprise to eliminate the alleged causes of negative test results, after the completion of the certified products, the tests can be repeated.

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

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 compliance with the requirements for the quality of technology and certified products. The objects of control, depending on the certification scheme, are certified products, the quality system or the stability of the production of the developer. When determining the frequency and extent of the inspection, the following factors are taken into account: the degree of potential danger of the software product, the stability of production, the volume of release, the availability 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, state control and supervision bodies.

Results of inspection control are drawn up by an act, which evaluates the results of sample tests and other checks, 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 stored in the certification body, and its copies are sent to the developer and to the organizations that took part in the inspection control. Based on the results of inspection control, the certification body may suspend or cancel the validity of the certificate and revoke the license for the right to use the mark of conformity in case of non-compliance of products with the requirements of regulatory documents controlled during certification, as well as in the following cases:

• fundamental changes in the maturity model, standards profile, 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 may 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 mark of conformity is not taken if, through corrective measures agreed with the certification body that issued it, the applicant can eliminate the detected causes of non-compliance and confirm, without re-testing in an accredited laboratory, the conformity of the product or processes to normative documents. If this cannot be done, then the validity of the certificate is canceled and the license for the right to use the mark of conformity is cancelled. Information about the suspension or cancellation of the certificate is brought by the certification body that issued it to the applicant, consumers and other interested organizations. The validity of the certificate and the right to label products with the mark of conformity can be renewed if the developer enterprise fulfills the following conditions:

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

Documentation of processes and results of certification of software products

Composition and content of documentation for quality system certification 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 necessary set of documents for each enterprise or project should be selected and adapted in relation to these characteristics. The indicators of the quality system evaluated during certification are the availability of relevant documents and the practical fulfillment of the requirements of a certain level of the maturity model. SMMI or an adapted standards profile based on ISO 9000:2000, as well as created on their basis, job descriptions specialists of the enterprise-developer. The applicant must prepare and submit to the testing laboratory a set of documents agreed between the customer and the developer and approved to verify their reliability, sufficiency of composition and workmanship 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 profile of standards based on ISO 9000:2000 or maturity models SMMI, 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 particular enterprise or project, as well as the life cycle of a software tool, prepared by the project management for certification of its quality;
• testers' reporting documents reflecting the results of the audit (certification) of the enterprise's quality system and / or software product, submitted to the certification body, the applicant and the management of the audited enterprise.

The software product or enterprise quality system 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 may be reduced and adapted as agreed between the applicant, the certifier and the management of the audited enterprise in accordance with the characteristics of software projects. Some documents can be combined into integrated reports with a clear responsibility of certain specialists for their implementation.

Basic documents of the enterprise quality system and software life cycle

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 sections and recommendations of the standards ISO 12207, ISO 15504, their changes and application guidelines, selected during adaptation and mandatory for use in the quality system of a particular enterprise or software product project.
3. Adapted version or list of sections and recommendations of the standard ISO 900003, selected during adaptation and mandatory for use in the quality system of an enterprise producing a software product.
4. Basic characteristics and quality attributes of the PS project, identified, adapted and specified on the basis of standards ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Adapted version and approved edition of the maintenance and configuration management manual 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 the managerial, performing and checking the work of the personnel involved in the procedures of the enterprise quality system 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.
3. A set of operational documents supplied to the customer and users to ensure the life cycle and 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 quality system of the enterprise and the software product.
6. Methods of maintenance, identification of software product components and documentation, analysis and approval of versions of software and data complexes.
7. The methodology for configuration management, approval, storage, protection, copying of software product versions and accompanying documents, as well as the accumulation and storage of data on quality characteristics registered in the enterprise archive during the life cycle of software product versions.

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

1. A report on the availability, relevance and systematic execution 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 the software product.
2. The results of monitoring and testing 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 methods for conducting inspections and documented reports on the results of the achieved quality of fulfilling the requirements of the certification agreement with the customer.
4. The 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 checking the implementation of the life cycle of the PS.
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 life cycle of the PS.
7. The results of certification of environment 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 verification of the real characteristics of the life cycle of the software system 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 Life Cycle Standards Profiles. -- Jet Info, Newsletter, N 12 , 2005

K. Milman, S. Milman -- SMMI is a step into the future. -- open systems., N 5-6. (2005), N2. (2006) , 2005, 2006

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

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

V.V. Lipaev -- Methods for ensuring the quality of large-scale software.-- M.: RFBR. SINTEG, 2003

"; antisource: "Software products are now used to solve management problems in almost all areas of human activity: in the economy, social, military and other areas. Ensuring the 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]$

The quality of software products is perhaps one of the most serious problems in the software industry. Quality is much more than just the absence of errors. It implies a set of different characteristics: reliability, hackability, adaptability, compatibility, maintainability, portability, efficiency, and so on. It is not surprising that there are such a variety of quality standards in the software industry.

Quality was easy to measure: either we got paid or we didn't.
Dean Leffingwell, Don Widrig.
Software requirements management

CMM/CMMI

Perhaps the most famous quality standard should be considered the Capability Maturity Model (CMM) - a model for assessing the level of maturity of development processes along with its derivatives. It was created by the SEI (Software Engineering Institute), which is funded by the US Department of Defense and is a structural unit of Carnegie Mellon University. First official version standard was published in 1993, although work on it began much earlier - its main provisions were published as early as 1986.

The success of CMM was predetermined by several factors. This standard was one of the first, initially taking into account the specifics of software development. It turned out to be quite simple and transparent both for understanding and for use, and regulated “what”, and not “how” to do, and therefore was suitable for various development methodologies and did not impose any restrictions on documentation standards, tools, environment and languages ​​used in projects. And, perhaps, the main factor that predetermined the popularity of CMM was the cooperation of SEI with the US Department of Defense, which de facto meant the use of the standard in the implementation of projects commissioned by this department.

The CMM model (Table 1) provides for five levels of maturity, each of which corresponds to certain key process areas (Key Process Areas, KPA).

Table 1. CMM Model Layers

level number	Level name	Key Process Areas
1	Elementary	If the organization is at this level, then there are no key process areas for it
2	recurring	Software configuration management. Software product quality assurance. Contractor contract management. Project progress monitoring. Software project planning. Requirements management.
3	Definite	Expert evaluations.Coordination of interactions between project teams.Software product engineering.Comprehensive software management.Personnel training program.Definition of the organizational process.Scope of the organizational process
4	Managed	Software quality management. Process management based on quantitative methods
5	Optimizable	Process change management.Technological change management.Defect prevention

The division into levels and the definition of KPA for each of them allows the consistent implementation of the CMM, using the standard as a guide, which can ensure continuous improvement in the development process.

The CMM standard proved to be very successful, and subsequently a whole series of standards was created on its basis (Table 2). Moreover, it received a new name - SW-CMM (Capability Maturity Model for Software), which more accurately reflects its position in a fairly large family of standards.

Table 2. Development of CMM standards

Name of the standard	Description
System Engineering CMM (SE-CMM)	Focuses on system engineering issues - product development (requirements analysis, product systems design and integration) and their production (production line planning and operation)
Trusted CMM (T-CMM)	Designed to serve sensitive and closed software systems that require high quality software assurance
System Security Engineering CMM (SSE-CMM)	Focuses on security aspects of software engineering, ensures a secure development process, including the security of members of the creation team
People CMM (P-CMM)	Considers issues of personnel development in software organizations
Software Acquisition CMM (SA-CMM)	Covers the acquisition of software products from external organizations
Integrated Product Development CMM (IPD-CMM)	Serves as an environment for integrating development efforts across all life cycle stages and from every department within the company

However, the practical application of the CMM series standards has shown that they do not provide unconditional success in software development. These standards were not well coordinated with each other - the simultaneous implementation of various modifications of the CMM could be quite a challenge and bewildered the specialists of the organizations that faced it.

Also, a significant problem of CMM is the need to "align" all processes. If an organization is attempting to certify to a certain level, then it must ensure that the appropriate level is applied to all of its processes. Even if the specifics, methodology or development features do not have certain processes to be performed, certification requires this.

Another problem is caused by the position that CMM standards have taken in the modern software industry. Since an organization with a high level in accordance with the CMM must provide higher software product performance than those certified at lower levels, the standard has come to be used as a selection criterion for participation in tenders for software development or outsourcing projects. The demand for certified organizations has given rise to a proposal for "quick and painless certification".

This situation has become possible due to the shortcomings of the certification process. Not the entire organization as a whole is subject to certification, but only a specific project. There is nothing to prevent an organization from creating a "demonstrative" project that meets all the requirements of the high levels of the CMM standard, obtain the appropriate level of certification, and declare that all products meet such and such a level of the standard.

Solve most problems CMM is designed new standard SEI - Capability Maturity Model Integrated (CMMI) - An integrated model for assessing the level of maturity of development processes. The CMMI standard was originally created in such a way as to combine existing CMM options and eliminate any contradictions in its practical application in various areas of activity of high-tech companies.

In order to eliminate the need to "align" the processes of the organization and be more adapted to its business needs, and not vice versa, the CMMI standard has two forms of presentation - the classic, multi-level, corresponding to the CMM, and the new, continuous. The continuous form of presentation does not consider maturity levels (Maturity Levels), but Capability Levels, which are evaluated for individual process areas (Process Areas, PA). In table. 3 gives a mapping of the maturity levels of the CMM standard, as well as the maturity levels of the layered CMMI presentation and the capability levels of the continuous CMMI presentation.

SEI is moving away from CMM and is actively promoting CMMI in return, promising to tighten control over the certification process, introducing new classes to reduce costs and make it more attractive to smaller organizations; ensuring compatibility with ISO standards. However, the fact remains: in modern conditions, the presence of a certificate of a certain level of CMM / CMMI is not such a significant factor as it was several years ago, and is accepted without additional questions, except perhaps in projects carried out by government order.

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 HMM is analyzed. The connection between the HMM and the previously studied process models is shown.

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

The history of the emergence of SMM is as follows. At the end of the 80s. last century, the US Department of Defense ordered the Institute of Software Engineering 1Eng. SEI - Software Engineering Institute Carnegie Mellon University is working on a system of criteria for selecting subcontractors in software development projects. The work was completed in 1991, and the result was CMM model. We must immediately make a reservation that the model does not contain any financial, economic, political, organizational selection criteria subcontractor, as well as the criteria for the possibility of admission to secret work (probably, such tasks were not set). We are only talking about criteria that describe 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 some non-trivial assumptions, which were subsequently accepted and recognized as fair by many IT professionals (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 of the Department 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 sharply at the same time).

Thus, the levels form a "ladder" along which the organization rises as own development. Each level is characterized by a certain composition and properties of the organization's processes. The SMM "Level Ladder" has been widely accepted and disseminated. Here's what she looks like.

Level 1 "Beginner". The production process as a whole is characterized as being created every 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 individuals.

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

Level 3 "Definite". The production process is documented and standardized for both managerial work as well as for design. This process is integrated into the organization's standard manufacturing process. All projects use an approved customized version of the organization's standard operating process.

Level 4 "Managed". Detailed quantitative indicators of the production process and the quality of the product being created are collected. Both the manufacturing process and the products are evaluated and controlled from a quantitative point of view.

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

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

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

Rice. 7.1.

On fig. 7.1 contains 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 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 reconcile the requirements of the software development project between the customer and the developer."

There are no individual processes in the CMM. Instead, there are individual works, called key practices (see below), connected by inputs and outputs with each other and serving as the source material for building processes. The CMM does not provide guidance on how processes should be structured, i.e. linking key practices into logical sequences. Sets of key practices are called key process groups.

Rice. 7.2.

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

The adjective "key" implies that there are process groups(i.e., sets of practices) that are not key in terms of a specific level of maturity, i.e., not related to the achievement of the goals of this level (see below). The HMM model does not describe everything process groups relating to 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. Goals in CMM are not associated with processes, but with groups of key processes. As mentioned above, the goals are achieved through the implementation of key practices. In CMM, achieving the goal means that, firstly, after the implementation of key practices, the desired result is obtained, and, secondly, it is obtained quite consistently. The way in which the objectives of the Key Process Group are achieved may differ from project to project due to 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 correlated with this group of 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 to what extent they are legalized in the organization, i.e. officially approved and coordinated with corporate procedures, policies, and other processes. Here are the five sections.

Performance obligations

Describe the actions the organization must take to ensure that the process is established and stable. Performance obligations typically relate to the establishment of organizational policies and support from top management.

Prerequisites

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

Operations in progress

The Operations in Progress section describes the substantive work that must be performed at this level. Operations performed typically include creating plans and implementing specific operations, executing and tracking work, and taking corrective action as needed.

Measurements and analysis

Section "Measurements and

“Each group of key processes is expressed by key practices, the implementation of which contributes to the achievement of the goals of the group. Key practices describe the infrastructure and operations that contribute most to the effective implementation and establishment of a group of key processes.

Each key practice consists of a single sentence, often followed by a more detailed description that may include examples and clarifications. Key Practices, sometimes referred to as top-level key practices, establish the basic policies, procedures, and operations for a group of key processes. Detailed description components are often referred to as sub-practices."

Key practices describe WHAT needs to be done, but they should not be taken as dogma about HOW goals should be achieved. The objectives of the key process group can be achieved through alternative practices. The interpretation of key practices should be reasonable, allowing the objectives of the key process group to be achieved in an efficient manner, although perhaps formally and differently from the recommended CMM.

A look at IT management activities, in which, instead of processes, their components are considered - key practices, and 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 was solved by the introduction of ready-made processes from the reference process model. Now there is a set of levels containing disparate (i.e., not integrated into processes) key practices, and a recommended sequence for moving through the levels. IT management, according to CMM, improves as it moves to a higher level of maturity. What happens with this promotion?

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

Organizations working in the field of development, delivery, implementation and maintenance of software and system integration are increasingly feeling that their competitiveness is based on quality and low cost, manufacturability.

The leaders of such organizations are not always able to form a strategy for improving and developing the technology of their company's activities; there are clearly not enough specialists on the labor market with the necessary qualifications. At the same time, international experience in the field of improving technological processes for the development and operation of software has not been sufficiently generalized and formalized for many years. Only in the early 1990s, the American Software Engineering Institute (SEI) formed a model of technological maturity of CMM organizations (Capability Maturity Model), determining the levels of technological maturity and their distinctive features. Over the course of a decade, CMM has been tested in a number of organizations, its effectiveness and reliability has been verified by ordering organizations, software vendors, custom software development companies, and offshore programming.

Today, in the west, a development company is practically experiencing great difficulty in obtaining orders if it is not certified by the SMM. Customers demand guarantees of the contractor's manufacturability, guarantees that the contractor cannot provide a low-quality service.

The assessment of the technological maturity of companies can be used:

the customer when selecting the best performers (for example, in a tender);

· software companies to systematically assess the state of their technological processes and select areas for their improvement;

· companies that decide to undergo an attestation to assess the "dimension of the disaster", i.e. your current state;

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

· consulting firms involved in the restructuring of companies and services providers of information technology and related services.

As the technological maturity of an organization increases, the processes for creating and maintaining software become more standardized and consistent. At the same time, the formalization of processes makes it possible to standardize the expected results of their implementation and ensure the predictability of the results of project implementation.

Process maturity (software process maturity)- this is the degree of their manageability, controllability and effectiveness. Increasing technological maturity refers to the potential for increased process resilience and indicates the degree of efficiency and consistency in the use of software development and maintenance processes throughout the organization. The real use of processes is impossible without their documentation and bringing to the attention of the organization's personnel, without constant monitoring and improvement of their implementation. The capabilities of well-designed processes are fully defined. Increasing the technological maturity of processes means that the efficiency and quality of the results of their implementation can constantly increase.

In organizations that have reached technological maturity, the processes of creating and maintaining software take the status of a standard, are fixed in organizational structures and determine production tactics and strategy. Their introduction into the status of law entails the need to build the necessary infrastructure and create the required corporate culture industries that maintain the appropriate methods, operations, and procedures for doing business, even after those who created it all leave the organization.

The CMM model develops the provisions on the organization's quality system, forming the criteria for its perfection - five levels of technological maturity, which, in principle, can be achieved by the development organization. The highest - the fourth and fifth levels - is actually a characteristic of organizations that have mastered the methods of collective development, in which the processes of creating and maintaining software are comprehensively automated and technologically supported.

Since 1990, SEI, with the support of US government agencies and software development organizations, has constantly developed and improved this model, taking into account all the latest achievements in the field of creating and maintaining software.

SMM is a methodological material that defines the rules for the formation of a management system for the creation and maintenance of software and methods for the gradual and continuous improvement of production culture. The purpose of the SMM is to provide developer organizations with necessary instructions on the choice of a strategy for improving the quality of processes by analyzing the degree of their technological maturity and the factors that most affect the quality of products. By focusing on a small number of the most critical operations and systematically improving the efficiency and quality of their execution, an organization can thus achieve a steady continuous improvement in the culture of creating and maintaining software.

The CMM is a descriptive model in the sense that it describes the essential (or key) attributes that determine what level of technological maturity an organization is at. It is a normative model in the sense that a detailed description of the methodologies establishes the level of organization required to carry out projects of varying complexity and duration under contracts with US government agencies. CMM is not a prescription, it does not prescribe how an organization should develop. The CMM describes the characteristics of the organization for each level of technological maturity, without giving any instructions on how to move from level to level. It may take an organization several years to move from the first to the second level, and very little time to move from level to level further. The process of improving the software development technology is reflected in the strategic plans of the organization, its structure, technologies used, general social culture and management system.

At each level, requirements are established, under which stabilization of the most significant indicators of processes is achieved. The achievement of each level of technological maturity is the result of the appearance of a certain number of components in the processes of software development, which in turn leads to an increase in their productivity and quality. On fig. Figure 1.7 shows five levels of CMM technological maturity.

Rice. 1.7. Five Levels of SMM Technological Maturity

The inscriptions on the arrows define the features of improving processes when moving from level to level.

Levels from the second to the fifth can be characterized through operations aimed at standardization and (or) modernization of the processes of creating software, and through the operations that make up the processes of its creation themselves. At the same time, the first level is, as it were, a base, a foundation for a comparative analysis of the upper levels.

At level 1 (initial), the basic processes of creating and maintaining software are random and chaotic. The success of the project depends entirely on the individual efforts of the staff. At this level, as a rule, the organization does not have a stable environment necessary for creating and maintaining software.

The success of the project in this case, as a rule, depends entirely on the degree of energy and experience of the management and professional level performers. It may happen that an energetic leader overcomes all the obstacles in the project process and achieves the release of a truly viable software product. But after such a leader leaves his post, there is no guarantee that the next such project will be successful. In the absence of the necessary level of project management, even advanced technology will not be able to save the situation.

Processes at the first level are characterized by their unpredictability due to the fact that their composition, purpose and sequence in the process of project implementation change randomly depending on the current situation. As a result, allocated funds are overspent and work schedules are disrupted. The training of capable and knowledgeable people in organizations is a basic prerequisite for success at all levels of maturity, but at the first level it is the only way to achieve any positive results.

At level 2 (the level of repeatable processes), project management processes provide ongoing control of the project cost, schedule, and functions performed. The discipline of the project is such that it is possible to predict the success of projects to create similar software products.

At this level, planning design work and management of new projects is based on the experience of successfully completed similar projects. The main feature of the second level is the presence of formalized and documented effective project management processes, which allows using the positive experience of successfully completed projects. Effective processes are those that are documented, actually used, measurable, and capable of being upgraded. It is essential that personnel be trained in their use.

Each level of CMM, starting with the second, is characterized by the presence of a number of so-called key process groups (KPA). The HMM model contains 18 such groups, latest version CMMI models - 20 groups. Level 2 CMM is characterized by the presence of the following processes in the organization (their names correspond to CMMI):

requirements management;

configuration management;

project planning;

monitoring and control of the project;

management of contracts;

measurement and analysis;

ensuring the quality of the process and product.

Processes at the second level can be characterized as ordered due to the fact that they are planned in advance and their implementation is strictly controlled, due to which predictability of project results is achieved. With the increase and complexity of projects, attention shifts from the technical aspects of their implementation to organizational and managerial aspects. The execution of processes requires people to work more effectively and coherently, which, in turn, requires the study of documented best practices in order to improve professional excellence.

At level 3 (the level of standardized processes), software development processes are documented, standardized and represent a single technological system that is mandatory for all departments of the organization. All projects use a single technology for creating and maintaining software that has been tested, approved and elevated to the status of a standard.

At this level, the following processes are added to the level 2 processes:

requirements specification;

product integration;

verification;

certification;

standardization of organization processes;

· education;

integrated project management;

· Management of risks;

Analysis and decision making.

The main criterion for using and, if necessary, adjusting processes at this level is to help management and technical specialists in improving the efficiency of project implementation. At this level, a special group is created in the organization responsible for the composition of the operations that make up the processes - the software engineering process group (SEPG).

On the basis of a single technology for each project, its own processes can be developed, taking into account its features. Such processes in CMM are called "project-oriented software development processes" (project "s defined software process).

The description of each process includes its execution conditions, input data, execution standards and procedures, verification mechanisms (for example, peer reviews), output data, and termination conditions. The description of the process also includes information about the tools required to complete it and an indication of the role responsible for its execution.

The main purpose of level 4 (the level of managed processes) is the current control over processes. Management must ensure that processes are carried out within the specified quality. There may be inevitable losses and temporary peaks in measured results that require intervention, but overall the system must be stable.

At level 4, the following processes are added:

performance and productivity management;

Quantitative project management.

At this level, a detailed assessment of the quality of both the creation processes and the software product itself is applied in practice. In this case, quantitative evaluation criteria are applied.

Within the framework of the entire organization, a single program for quantitative control of the productivity of software creation and its quality is being developed. To facilitate the analysis of processes, a single database of processes for creating and maintaining software is created for all projects carried out in the organization. Universal methods are being developed quantification the productivity of processes and the quality of their implementation. This allows to carry out quantitative analysis and evaluation of software creation and maintenance processes.

The results of the processes at the fourth level become predictable, because they are measurable and vary within the given quantitative restrictions. At this level, it becomes possible to plan in advance the specified quality of the processes and final products.

The main purpose of level 5 (the level of optimized processes) is the consistent improvement and modernization of the processes of creating and maintaining software. For the purpose of the planned modernization of software development technology, a special unit is created in the organization, the main responsibilities of which are the collection of data on the implementation of processes, their analysis, the modernization of existing and the creation of new processes, their verification for pilot projects and giving them the status of enterprise standards.

At level 5, the following processes are added:

introduction of technological and organizational innovations;

cause-and-effect analysis and problem solving. The processes of creating and maintaining software are characterized by

as consistently improved, as the organization makes continuous efforts to modernize them. This improvement extends both to the identification of additional capabilities of the processes used, and to the creation of new optimal processes and the use of new technologies.

Innovations that can bring the greatest benefit are standardized and adapted into the technological system throughout the organization. The personnel involved in the implementation of the project analyzes the defects and identifies the causes of their occurrence. Software development processes are evaluated to prevent the recurrence of situations that lead to defects, and the results of the evaluation are taken into account in subsequent projects.

Each subsequent level additionally provides a more complete visibility of the processes of creating and maintaining software.

At the first level, processes are amorphous (“black boxes”), and their visibility is very limited. From the very beginning, the composition and purpose of operations are practically not defined, which creates significant difficulties in determining the status of the project and its progress. Requirements for the execution of processes are set uncontrollably. Software development in the eyes of managers (especially those who are not programmers themselves) sometimes looks like black magic.

At the second level, the fulfillment of user requirements and the creation of software are controlled, since the basis for the project management processes is defined. The process of creating software can be viewed as a sequence of "black boxes" that can be controlled at the transition points from one "box" to another - fixed stages. Even if the manager does not know what is being done “inside the box”, it is precisely established what should be the result of the process, and the control points for its start and end are determined. Therefore, management can recognize problems at black-box interaction points and respond to them in a timely manner.

At the third level, the internal structure of the "black boxes" is defined, i.e. the tasks that make up the processes. The internal structure is the way in which standard processes in an organization are applied to specific projects. The management link and the executors know their roles and responsibilities within the project to the required level of detail. Management is prepared in advance for the risks that may arise during the implementation of the project. Since standardized and documented processes become "transparent" for review, employees who are not directly involved in the project can receive accurate information about its current status in a timely manner.

At the fourth level, the execution of processes is strictly tied to tools, which makes it possible to determine the quantitative characteristics of their labor intensity and quality of execution. Managers, having an objective base of quantitative measurements, get the opportunity to accurately plan the stages and stages of the project, predict the progress of the project, and can promptly and adequately respond to emerging problems. With the reduction of possible deviations from the given terms, cost and quality in the process of project implementation, their ability to predict results is constantly increasing.

At the fifth level, in order to improve the quality of products and increase the efficiency of its creation, work is constantly and systematically carried out to create new improved methods and technologies for creating software. Attention is drawn not only to already used, but also to new, more efficient processes and technologies. Managers can quantify the impact and effectiveness of changes in software development and maintenance technology.

The fourth and fifth levels are rare in the software industry. Thus, if several hundred companies in the world reached the third level, then there were 62 firms of the fifth level (according to SEI data for 2002), and 72 of the fourth. Some are not interested in advertising their organizational technologies, while others perform certification simply under pressure from the customer.

It takes ten years or more to reach the highest levels of SMM. But even level 3 allows you to boldly enter the international arena. To use SMM, a company does not need to look for employees with some unique abilities, it is enough for it to understand the general idea. The description of the CMM model specifies in detail what needs to be done in order to develop in accordance with this model. Any middle-class manager is capable of following the regulated actions of the CMM.

The latest version of SMM 1.1 is mainly focused on large companies, involved in the implementation of large projects, but it can also be used by groups of two or three people or individual programmers to complete small projects (up to three months). In such cases, the HMM model can play a vital role. important role, since the receipt of new orders is largely determined by the quality of the implementation of previous projects. Small groups will be quite satisfied with level 2, since for a small project a deviation from the deadline of a couple of weeks is unimportant.

Since 2002, a special integration version of CMMI has been officially distributed. it new development SEI, covering all aspects of the company's activities: from development and selection of a contractor to training, implementation and maintenance. In addition, the CMMI model is extended with approaches from systems engineering. This model includes developments made during the design of the CMM 2.0 version (it was not completed), the main changes in which were aimed at clarifying processes for companies of the fourth and fifth levels, which is most relevant for large-scale American projects.

The CMM model is quite weighty and important, but it should not be used as the only basis that determines the entire software development process. It was intended primarily for companies that develop software for the US Department of Defense. These systems are characterized by their large size and long service life, as well as the complexity of the interface with hardware and other software systems. Rather large teams of programmers are working on the creation of such systems, which must comply with the requirements and standards developed by the Ministry of Defense.

The disadvantages of SMM include the following:

1. The model focuses solely on project management, and not on the process of creating a software product. The model does not take into account such important factors as the use of certain methods, such as prototyping, formal and structural methods, static analysis tools, etc.

2. The model lacks risk and decision analysis, which prevents problems from being detected before they affect the development process.

3. The scope of the model is not defined, although the authors acknowledge that it is universal and suitable for all organizations. However, the authors do not make a clear distinction between organizations that may or may not implement SMM in their activities. Small companies find this model too bureaucratic. In response to these criticisms, process improvement strategies for small organizations have been developed.

main goal In creating the CMM model, it was the intention of the US Department of Defense to assess the capabilities of software vendors. On the this moment while there are no clear requirements to achieve a certain level of development of development organizations. However, it is generally accepted that an organization that has reached a high level is more likely to win a tender for the supply of software. As an alternative to CMM, a generalized classification of technological maturity improvement processes is proposed, which is suitable for most organizations and software projects. Several general types of improvement processes can be distinguished.

1. informal process. Does not have a clearly defined model of improvement. It can be successfully used by a separate development team

cov. The informality of the process does not preclude formal activities such as configuration management, but the activities themselves and their relationships are not predetermined.

2. Managed process. Has a prepared model that guides the improvement process. The model defines the activities, their schedule, and the relationships between them.

3. Methodically sound process. It is assumed that certain methods have been put in place (for example, object-oriented design methods are systematically applied). For this type of process, process design and analysis support tools (CASE-tools) will be useful.

4. The process of direct improvement. It has a clearly defined goal of improving the technological process, for which there is a separate line in the budget of the organization and the norms and procedures for introducing innovations are defined. Part of such a process is the quantitative analysis of the improvement process.

This classification cannot be called clear and exhaustive - some processes can simultaneously belong to several types. For example, the informality of the process is the choice of the development team. The same team can choose a specific development methodology, while having all the opportunities for direct improvement of the process. This process is classified informal, methodically sound, direct improvement.

The need for this classification is due to the fact that it provides the basis for the comprehensive improvement of software development technology and enables the organization to choose different types of improvement processes. On fig. 1.8 shows the relationship between different types software systems and processes for improving their development.

Rice. 1.8. Applicability of improvement processes

Knowing the type of product being developed will make the correspondence between software systems and improvement processes shown in Fig. 1.8 useful in choosing process improvement. For example, you need to create a program to support the transition of software from one computer platform to another. Such a program has a fairly short lifespan, so its development does not require standards and special management of the improvement process, as when creating long-lived systems.

Many workflows now have CASE support, so they can be called supported processes. Methodically sound processes are supported by analysis and design tools. The effectiveness of the support tool depends on the improvement process applied. For example, in an informal process, typical support tools (prototyping tools, compilers, debugging tools, word processors, etc.) can be used. It is unlikely that more specialized support tools will be used on an ongoing basis in informal processes.

The SMM model is not unique. Almost every large company develops its own software development technologies, sometimes these technologies become public and very popular. The wide popularity of the HMM model is associated with its state support, but the actual effectiveness of the SMM is criticized by many leading experts. One of the main shortcomings of the HMM is associated with an unnecessarily rigid requirement not to deviate from the principles of this model, even if common sense suggests the opposite. Such claims to the possession of absolute truth cannot but arouse suspicion, therefore, among small and medium-sized companies, approaches that leave much more freedom for individual and collective creativity are more popular. The SPMN technique considered below occupies an intermediate position between rigid, “heavy”, effective for large organizations solutions such as SMM and the most flexible technologies. She appears the best option for companies that, on the one hand, want to streamline their managerial activity, and on the other hand, they plan in the future to reach international level where CMM certification is highly desirable.

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

The development of this review was prompted by a request from the US federal government for a method for evaluating subcontractors for software development. The real problem was the inability to manage large projects. In many companies, projects were delivered significantly late and over budget. It was necessary to find a solution to this problem.

In September 1987, SEI released short review software development processes with a description of their maturity levels, as well as a questionnaire designed to identify areas in the company in which improvements were needed. However, most companies considered this questionnaire as a ready-made model, as a result of which, after 4 years, the questionnaire was converted into a real model, the Capability Maturity Model for Software (CMM). The first version of the CMM (Version 1.0), released in 1991, was revised in 1992 by the participants of the working meeting, which was attended by about 200 software specialists, and members of the developer society.

1. Elementary. The most primitive status of the organization. The organization is capable of developing software. The organization does not have an explicitly conscious process, and the quality of the product is entirely determined by the individual abilities of the developers. One takes the initiative and the team follows his instructions. The success of one project does not guarantee the success of another. At the end of the project, data on labor costs, schedule and quality are not recorded.
2. repeatable. To some extent, the process is monitored. Records are made of labor costs and plans. The functionality of each project is described in writing. In mid-1999, only 20% of organizations were Level 2 or higher.
3. Installed. Have a defined, documented and established process work independent of individuals. That is, agreed professional standards are introduced, and the developers comply with them. Such organizations are able to fairly reliably predict the costs of projects similar to those completed earlier.
4. Managed. They can accurately predict the timing and cost of work. There is a database of accumulated measurements. But there are no changes with the emergence of new technologies and paradigms.
5. Optimized. There is an ongoing procedure for finding and mastering new and improved methods and tools.

Development

The use of the model in practice revealed the ambiguity in approaches to achieving higher levels of organization of software development processes. Therefore, by 2002, recommendations are being developed to improve the development process, which are called CMMI (Capability Maturity Model Integration). Currently the latest version of CMMi is 1.3 (published in November 2010) .

see also

Links

MIT Student Forum > Main Section > Tests > Control Systems Simulation

View full version: Simulation of control systems

I solved all the modules, passed everything with 4, and the final one with 2, now in three days I will try to pass again, there was not a single identical question. I tried to correct the final test, but check, I can’t vouch for the correctness. I expose everything that I have, maybe someone will pass it better than me. If someone has a second, third attempt, put up, if you don’t mind, discipline, really very difficult.:eek:

Final test 100 out of 100

Is the result different every time?

More questions that are not listed here and caught me. I didn’t look for answers, because without it I passed 4. Who wants to be confused, upload the answers here for the rest 🙂

Module 1:
What should not be considered as a hallmark of a business process?

Value Addition

Choose one answer:
A product of a process that embodies previously set goals

Choose one answer:

In the final (passed on 4.

What is the Capability Maturity Model? (CMM)

These questions + those already on the forum):
1. Choose the correct statement.
Choose one answer:
The business process of divisions consists of various value chains (UNSURE)
An end-to-end business process consists of business processes of various organizations
Cross-functional business process, as a rule, consists of business processes of departments

2. What is not an element of the universal business process flow chart?
Choose one or more answers:
Process resources
Risks
Business process management activities
Environmental factors
Activity to convert inputs to outputs

3. Material resources as a basic element of processes are:
Choose one answer:
Active subjects of activity united in systems interacting with each other and other resources
Control actions directed by the subjects of activity on the objects of activity, which determine the goals and results of the processes
Passive facilities and activities used to carry out processes (NOT SURE)

28.03.2014, 10:07

Module 1:
What should not be considered a hallmark of a business process? Choose one or more answers:
Converting inputs to outputs
Delivery of the product to an external consumer
Value Addition
Formation of surplus and/or use value

Results as basic elements of processes are:
Choose one answer:
Active subjects of activity united in systems interacting with each other and other resources
A product of a process that embodies previously set goals Passive facilities and activities used to carry out the processes
The set of material, energy and information objects necessary to complete the process

What is feedback within a business process?
Choose one answer:
Purposeful and conscious influence on the process, designed to ensure the desired result
Analysis and comparison of the results of the process with previously set goals
Impact on the system of objects and factors of the environment, which are sources of various kinds of deviations in the functioning of the system
I answered so! but it still came out 4

In the final - These questions + those that already exist:
1 Select the shortcomings of the design-target structures from the list.

2 Select examples of command usage from the list.
Quality mugs
Committees
Work Teams

3 Select from the list the conditions for applying organic organizational structures.
Workers are motivated by complex needs
Goals are blurry and dynamically changing
Power is questioned and tested, requires confirmation from subordinates

4 Select from the list the benefits of project-based organizational structures.
direct subordination of employees to the project manager and thus the unambiguity of the direction of the efforts of these employees is achieved

5 Supporting processes:
Provide effective implementation main processes

Final grade 5
Question 1
Choose from the list of command usage examples.

Quality mugs
Committees
Work Teams

Question 2
What are intermediaries used for within the functional structure?

To integrate the activities of various structural divisions

Question 3
Name the types of relationships in the SADT model:
Control
exit-mechanism
Feedback at the entrance

Question 4
Which of the following business processes is the shortest?
Division business process

Question 5
What methods, methodologies and tools can be used to create business process information models?

Gein-Sarson methodology
Chen and Barker's modeling language

Question 6
Which business process representation corresponds to the lowest level (of those listed)?

Business Process Operations

Question 7
Business process length:

It is subjective

Question 8
Material resources as a basic element of processes are:

Passive means and objects of activity used to carry out processes

Question 9
Select from the list the benefits of project-based organizational structures.

The direct subordination of employees to the project manager is implemented and thus the unambiguity of the direction of the efforts of these employees is achieved

Question 10
Select from the list the benefits of matrix organizational structures.

There is an opportunity to flexibly “customize” the organizational structure within a wide range: from a weak to a strong matrix

Question 11
What does the second loop of business system management include?

Operation control subsystem
development management subsystem

Question 12
The general process model of a business system includes the following elements:

Exit
process
Entrance
Disturbance

Question 13
Which IDEF standard allows you to model activities, flows, and the state of objects?

Question 14
What are the powers of the Project Manager in a strong matrix structure?

Medium to High

Question 15
What can be attributed to the main elements of investment and financial processes?

Investors
Lenders

Question 16
Select from the list the shortcomings of the design-target structures.

Reduced manufacturability in functional areas

Control Systems Modeling.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

What is the order of dominance in SADT diagrams?
Answer: The most dominant functions are located in the upper left corner.

help 3training who has it pliz

Added after 1 minute
I ask for 3 training from anyone who has Modeling of control systems

vBulletin® v3.8.7, Copyright 2000-2018, vBulletin Solutions, Inc.

Translation that you can say:

Methodology for the development of IS. CMM/CMMI maturity model.

In 1991, the Institute of Software Engineering of the University

Carnegie Mellon (Software Engineering Institute, SEI) created the CMM maturity model (Capability Maturity Model) for developing software products. Over time, a whole family of models has been released:

SW-CMM - for software products, SE-CMM - for systems engineering, Acquisition CMM - for procurement, People CMM - for human resource management, ICMM - for product integration.

A variety of models turned out to be quite difficult to understand and implement. Since they were created different groups specialists, the content of these models was not always consistent with each other, as well as with

requirements of international standards. Therefore, in 2002, SEI published a new CMMI model (Capability Maturity Model Integration), combining previously released models and taking into account the requirements

international standards. CMMI is a set of models (methodologies) for improving processes in organizations of various sizes and activities. The CMMI distinguishes the following groups of improvement areas: process management, project management, engineering areas, service

areas. In this case, all areas are specified in the form of requirements that determine not how they are implemented, but interface requirements. From this there are two consequences.

Consequence 1. CMMI allows various implementations and is not a software development methodology like MSF, Scrum, RUP, etc. The latter can be used in its implementation. For example, there is a special process template in VSTS for CMMI called MSF for CMMI.

Corollary 2. CMMI is used to certify companies for the maturity of their processes. Initially, in the late 80s and early 90s, CMM (then not yet CMMI) was created precisely as a means of certification

federal subcontractors. And only later, having become widespread in the world, it began to be used and then focused on improving processes. Let's note one more important characteristic of CMMI. It is intended not only for the development of software systems. Many large companies do not release software, but target products, where software is included as an integral part.

For example, aviation, aerospace industries. That is, software development

occurs along with engineering work of other types. And it often happens that more than two different types of engineering are involved in one project. The task of CMMI is to provide such projects and companies with a single platform for organizing the development process.

Unlike the classical CMM model, which was strictly hierarchical and allowed only sequential improvement of processes by levels, the CMMI model has two dimensions - sequential, such

same as in the CMM, and continuous, allowing the improvement of processes in the organization to some extent in an arbitrary manner. Here we will focus on the sequential model. It has 5 levels

process maturity (Fig. 1).

First level(maturity level 1) is the level at which, by definition, any company is. At this level, software development is more or less chaotic.

Managed Level(maturity level 2) - policies and procedures for organizing processes approved at the company level already appear here. But the full extent of the processes exist only within the framework of individual projects.

A certain level(maturity level 3) - here a standard process appears at the level of the entire company as a whole.

What is Capability Maturity Model (CMM)? What are CMM Levels?

This is a large and constantly growing set of process assets: document templates,

life cycle models, software tools, practices, etc. Any specific process is obtained by cutting from this standard.

Quantitative Level(maturity level 4) implies the emergence of a system of measurements in the company, which occur on the basis of a standard process and allow quantitative management of development.

Optimizing level(maturity level 5) implies continuous improvement of development processes, both incremental, incremental, and revolutionary. At the same time, these changes are not forced, but proactive problems and difficulties. The process is being improved by itself and constantly, appropriate mechanisms have been implemented.

Many people know the abbreviation CMMI, many people know that this is a model, i.e. a set of recommendations on how to improve processes related to, for example, software development. But few people know that there are several CMMI models. The most famous of them is CMMI for Development (CMMI-DEV), which is really connected in many respects with the activities of development companies (that is, those companies and organizations that develop and supply a certain software product or other complex software and hardware solution).

But what about those who deliver not a product, but services (for example, product support with an insignificant share of development in total labor costs or no labor costs at all)? For them, there is also a set of recommendations - the CMMI for Services model (CMMI-SVC). For IT departments, for example, this model (more precisely, its recommendations) can help to understand what needs to be done so that, for example, the same ITIL recommendations become a normal process, and not some kind of “sacred practice”.

Capability Maturity Model (CMM)

It is curious that the recommendations of this model are quite universal and do not "close" only on Information Technology. The pilot introduction of the practices of this model took place ... in one of the hospitals in the United States (after all, medical care is also a service).

However, any of the models listed is better to learn. And if there are several hundred people trained in the CMMI-DEV model for the entire CIS (about 250-300 people), then there are only 6 people trained in the CMMI-SVC model in the CIS. We are talking about the trained, not the instructors. This was exactly the main problem until December 2011: for CMMI-DEV, there was only one Russian-speaking instructor certified by the SEI (CMMI model developer) in the whole world, and for other models there were none at all! Now such an instructor has also appeared according to the CMMI-SVC model (hence the first 6 trained). This instructor is the author of this publication, who is available to answer any questions about the models mentioned and about formal training. Ask!

This material is a private record of a member of the Club.CNews community.
The editors of CNews are not responsible for its content.