Standard ieee 90 escort elements. Software life cycle processes. Description of the transmitted data correctness signal

In the field of IT, the most relevant standards in terms of practice are published by the following organizations:

• Institute of Electrical and Radioelectronics Engineers(IEEE, www.ieee.org) has been a leading scientific and technical organization for many years, including in the creation of documentation standards software. Most of the standards are developed by various committees made up of experienced and responsible professional engineers. Some of the IEEE standards have also become ANSI (American National Standards Institute) standards. Mostly IEEE standards formed the basis for the preparation of MU for KP. Schmidt M. Implementing the IEEE Software Engineering Standards.
• international organization for standardization (ISO) has a huge influence all over the world, especially among producers' organizations dealing with the European Union (EU). Currently, virtually all modern IT standards translated and adopted in the Russian Federation are standards prepared by ISO jointly with the International Electrotechnical Commission - IEC (IEC). You know that special attention is paid to the issues of product quality assurance at international level, therefore, according to the Decree of the Government of the Russian Federation No. 113 of 02.02.1998, compliance with the requirements of ISO 9000 (a series of standards governing quality management (quality management) in enterprises) - required condition to receive government orders.
• Institute of Software Development Technologies(Software Engineering Institute - SEI, sei.cmu.edu - more than 1000 articles) was established by the US Department of Defense at Carnegie Mellon University to raise the level of software technology for DoD contractors. The work of the SEI has also been adopted by many commercial companies that consider improving the software development process as their strategic goal. corporate mission. We will refer to one of the standards developed by the SEI called the Capability Maturity Model (CMM).
• Object Manipulation Technology Consortium(Object Management Group, www.omg.org) is non-profit organization, which includes about 700 companies as members. OMG sets the standard for distributed object-oriented computing. It should be noted that OMG uses the Unified Modeling Language (UML) as its standard for describing projects. We will study UML in detail, because. the use of this language in conjunction with Rational's unified process is the basis for developing the core of the course project.

The concept of the system life cycle

The need for standardization of software development is most aptly described in the introduction of the standard. GOST R ISO / IEC 12207-99 " Information technology. Processes life cycle software tools» : “Software is an integral part of information technology and traditional systems such as transportation, military, medical and financial. There are many and varied standards, procedures, methods, tools, and operating environments for developing and managing software. This diversity creates difficulties in software design and management, especially when combining software products and utilities. The software development strategy requires a transition from this set to a common order that allows software practitioners to "speak the same language" in developing and managing software. This International Standard provides such a general order.”

Standard GOST R ISO/IEC 12207-99 defines the basic concept of a software system - "life cycle" (GOST R ISO / IEC TO 15271-2002 "Information technology. Guidelines for the application of GOST R ISO / IEC 12207").

GOST R ISO/IEC 12207-99 introduces the concept of a life cycle model as a structure consisting of processes, and covering the life of a system from establishing requirements for it to the termination of its use. It is proposed to correct this definition and divide it into two definitions:

1. life cycle- a set of processes divided into works and tasks, and including the development, operation and maintenance software product, covering the life of the system from the establishment of requirements for it to the termination of its use.
2. life cycle model- a structure that determines the sequence of implementation of processes, works and tasks performed throughout the life cycle of a software system, as well as the relationship between them.

The life cycle processes are divided into three groups: main, auxiliary and organizational.

The group of main processes includes: acquisition, supply, development, operation and maintenance. The main life cycle processes are implemented under the control of the main parties involved in the software life cycle. The main party is understood as one of those organizations that initiate or carry out the development, operation or maintenance of software products. The main parties are the customer, supplier, developer, operator and software maintenance personnel.

Figure - The main processes of the life cycle of IS

The group of auxiliary processes includes processes that ensure the execution of the main processes:

• documentation;
• configuration management;
• quality assurance;
• verification;
• attestation;
• grade;
• audit;
• solution of problems.

The group of organizational processes includes the processes:

• project management;
• creation of project infrastructure;
• definition, evaluation and improvement of the life cycle itself;
• education.

In the text of GOST 12207-99 the works that are part of the main, auxiliary and organizational processes are characterized very generally, in fact only their directions are outlined, therefore, in order to start designing, you will need standards and additional literature that reveals the content of each separate process or, even better, a separate work.
From the group of main processes, the development process is of the greatest interest.
It should be noted that GOST 34.601-90 " Automated systems. Stages of creation" the process of creating an automated system is divided into the following stages:

• formation of requirements for the AU,
• development of the AS concept,
• technical task,
• preliminary design,
• technical project,
• working documentation,
• commissioning,
• accompaniment.

The stages are divided into stages, the content of which echoes the content of a number of tasks described in GOST 12207-99.

Development process

Development process provides for the actions and tasks performed by the developer, and covers the creation of the PS and its components in accordance with the specified requirements, including the preparation of design and operational documentation; preparation of materials necessary to check the operability and appropriate quality of software products, materials necessary for organizing staff training, etc.

Figure - The structure of the development process

Preparatory work

begins with the choice of a life cycle model of the PS, corresponding to the scale, significance and complexity of the project. The activities and tasks of the development process should be consistent with the chosen model. The developer must select, adapt to the conditions of the project and use the standards, methods and development tools agreed with the customer, as well as draw up a work plan.

Requirements analysis

The analysis of requirements for the PS involves the determination of the following characteristics for each component of the PS:

• functionality, including performance characteristics and operating environment of the component;
• external interfaces;
• reliability and safety specifications;
• ergonomic requirements;
• requirements for the data used;
• installation and acceptance requirements;
• requirements for user documentation;
• requirements for operation and maintenance.

architecture design

system at a high level is to determine the components of its equipment, software and operations performed by personnel operating the system. The architecture of the system must comply with the system requirements and accepted design standards and practices.
PS architecture design includes the following tasks (for each PS component):

• transformation of the requirements for the PS into an architecture that defines the structure of the PS and the composition of its components at a high level;
• development and documentation of program interfaces of PS and databases;
• development of a preliminary version of user documentation;
• development and documentation of preliminary requirements for tests and an integration plan for the PS.

Detailed design

PS includes the following tasks:

• description of the PS components and interfaces between them at a lower level, sufficient for their subsequent independent coding and testing;
• developing and documenting a detailed database design;
• development and documentation of requirements for tests and a plan for testing software components;

Coding and Testing

PS cover the following tasks:

• development (coding) and documentation of each component of the PS and database, as well as a set of test procedures and data for their testing;
• testing each component of the PS and the database for compliance with the requirements for them. The results of component testing should be documented;
• updating (if necessary) user documentation;
• updating the PS integration plan.

For each of the aggregated components, test suites and test procedures are developed to test each of the competencies in subsequent proficiency testing. Qualification requirement is a set of criteria or conditions that must be met in order to qualify a software product as meeting its specifications and ready for use in the field.

GOST R ISO/IEC 12119-2000 “Information technology. Software packages. Quality requirements and testing" contains guidelines that define how a product is tested for compliance with its quality requirements. Testing is a labor intensive process. According to some experts, the percentage
the distribution of time between the processes of design - development - testing is in the ratio of 40-20-40. In this regard, test automation systems are widely used. The IEEE 1209-1992 "Recommended Practice for the Evaluation and Selection of CASE Tools" standard sets out general requirements for the functions of test automation tools.

System integration

consists in assembling all its components, including PS and equipment. After integration, the system, in turn, is subjected to qualification testing for compliance with the set of requirements for it. At the same time, registration and verification of a complete set of documentation for the system are also carried out.

System installation

is carried out by the developer in accordance with the plan in the environment and on the equipment that are provided for in the contract. During the installation process, the operability of the PS and databases is checked.

System acceptance

provides for the evaluation of the results of qualification testing of the software and the system and documentation of the results of the evaluation, which are carried out by the customer with the help of the developer. The developer performs the final transfer of the software to the customer in accordance with the contract, while providing the necessary training and support. Our course is mainly aimed at a detailed review of the first four works of the software development process. A separate section will be devoted to each of these works, and now, for further presentation, it is necessary to say a few words about the models of the life cycle of PS.

Software life cycle models

Life cycle model- a structure that determines the sequence of implementation of processes, works and tasks performed throughout the life cycle of an information system, as well as the relationship between them.

To date, two main life cycle models have been most widely used:

• cascade (waterfall) model;
• spiral model.

Cascade model

Cascade model demonstrates a classic approach to development various systems in various applied areas. For development information systems This model was widely used in the 70s and the first half of the 80s. It is the cascade model that underlies the GOST 34.xxx series and the US Department of Defense standard DOD-STD-2167A. Processes GOST 12207-99 in GOST 34.601-90 “Automated systems. Stages of creation» called stages and vary slightly in composition.
The cascade model provides for a sequential organization of processes. Moreover, the transition to the next process occurs only after all work on the previous one is fully completed. Each process culminates in the release of a complete set of documentation, sufficient for the work to be continued by another development team.

The main disadvantage of the waterfall model is that errors and shortcomings at any of the stages appear, as a rule, at subsequent stages of work, which leads to the need to go back. According to consulting company The Standish Group in 1998 in the USA, more than 28% of corporate information systems (IT projects) ended in failure; almost 46% of IT projects ended with budget overruns (189% on average); and only 26% of projects fit into the allotted time and budget.

In addition, the disadvantages of the cascade model include:

• the complexity of parallelizing work;
• complexity of project management;
• high level of risk and unreliability of investments (return to previous stages can be associated not only with errors, but also with changes that have occurred in the subject area or in customer requirements during development. Moreover, returning the project for revision due to these reasons does not guarantee that the subject area will not change again by the time the next version of the project is ready.In fact, this means that there is a possibility that the development process will "loop" and the system will never reach commissioning.Project costs will constantly increase, and the deadlines for the completion product is constantly delayed).

spiral model

Unlike cascade, it involves an iterative process of developing an information system. The spiral model was proposed in the mid-1980s by Barry Boehm. Each turn of the spiral corresponds to the creation of a fragment or version of a software product, it specifies the goals and characteristics of the project, determines its quality, and plans work on the next turn of the spiral. At each iteration, the details of the project are deepened and consistently concretized, metric data is collected, which are used to optimize subsequent iterations. However, the mechanisms for ensuring the integrity of the documentation become more complicated (when a particular requirement or definition is given in the text only once), which requires the use of special tools.
Principal features of the spiral model:

• refusal to fix requirements and assign priorities to user requirements;
• development of a sequence of prototypes, starting with the requirements of the highest priority;
• risk identification and analysis at each iteration;
• evaluating results at the end of each iteration and planning for the next iteration.

Rapid Application Development

In the 90s of the XX century, based on the spiral model, a practical technology called "rapid application development" - RAD (Rapid Application Development) was founded. At the same time, the LC consisted of four stages:

• requirements analysis and planning,
• design,
• implementation,
• implementation.

Basic principles of RAD:

• development of applications by iterations;
• optional complete completion of work at each stage of the software life cycle;
• mandatory involvement of users in the development process;
• the use of configuration management tools that facilitate making changes to the project and maintaining the finished system;
• the use of prototyping to better understand and meet user needs;
• testing and development of the project, carried out simultaneously with the development;
• leading the development of a small well-managed team of professionals;
• competent management of system development, clear planning and control of work.

In early 2001, a number of leading software engineers (Martin Fowler, Kent Beck, and others) formed a group called the Agile Alliance to support and develop a new approach to design - "rapid software development" (Agile Software Development). One implementation of this approach is Extreme Programming (XP).

The principles of Extreme Programming are as follows:

1. The team consists of three to ten programmers. One or more clients must be able to continuously provide current expertise.
2. Programs are developed in three-week iterations. Each iteration produces working, tested code that can be immediately used by customers. The assembled system is shipped to end users at the end of each release period, which can take anywhere from two to five iterations.
3. The unit of collected software requirements is the “user story” (user story), recorded on the index card, and describing from the user's point of view the functionality that can be developed in one iteration. Customers and programmers plan work for the next iteration in the following way:
   • programmers estimate the time to complete each card;
   • customers prioritize, modify and revise as needed. The development of a story begins with its discussion by programmers and an expert customer.
4. The programmers work in pairs and follow the strict coding standards set by them at the beginning of the project. They create unit tests for everything they write, and ensure that these tests are run each time code is checked into mandatory version control and configuration management.
5. While programmers are at work, customers visit programmers to clarify ideas, write system acceptance tests to run during an iteration, and at the end select stories to implement in the next iteration.
6. Every day, the team holds operational meetings where programmers talk about what they are working on, what is going well and what needs help. At the end of each iteration, there is another meeting where they evaluate what went well and what needs to be worked on next time. This checklist is posted for everyone to see as they work during the next iteration.
7. One person on the team is designated as the "mentor". Together with team members, he evaluates their use of basic techniques: pair programming and testing, pair rotation, keeping design decisions simple, communication, etc. in order to continuously improve the development process.

The rapid software development approach is not universal and is applicable only to projects of a certain class. To characterize such projects, Alistair Coburn introduced two parameters - criticality and scale.
Criticality is determined by the consequences caused by defects in the software, and can have one of four levels:

• C - defects cause loss of convenience;
• D - defects cause loss of recoverable funds (material or financial);
• E - defects cause the loss of irreplaceable funds;
• L - defects pose a threat to human life.

The scale is determined by the number of developers involved in the project:

• from 1 to 6 people - small scale;
• from 6 to 20 people - medium scale;
• over 20 people - a large scale.

According to Coburn, rapid software development is applicable only in projects of small and medium scale with low criticality (C or D). This means that RAD and XP technologies are best suited for relatively small projects developed for a specific customer, and are not applicable to building complex calculation programs, operating systems or real-time control programs for complex objects, as well as systems that depend on security. of people.

Unified software development process

At present, work continues on the creation of some universal process for the development of IP. In 1999 Rational employees Ivar Jacobson, Gradi Booch and James Rambo published the book Unified Software Development Process (Unified Software Development Process), which was translated into Russian and published by the Piter publishing house in 2002. The unified process is an attempt to combine the waterfall and iterative models J C.

At the same time, the LC is divided into 4 phases:

1. Start (inception): the initial evaluation of the project.
   • a simplified use case model is created that contains the most critical use cases from the point of view of implementation;
   • a trial version of the architecture is created containing the most important subsystems;
   • risks are identified and prioritized;
   • the design phase is planned;
   • the entire project as a whole is roughly estimated;
2. refinement: most use cases are described in detail and the system architecture is developed. At the end of the design phase, the project manager performs an estimate of the resources needed to complete the project. It is necessary to answer the question: are the use cases, architecture and plan sufficiently developed so that it would be possible to give contractual obligations for the performance of work and proceed to the preparation and signing of the “Terms of Reference” ?;
3. construction- creating a product. At the end of this phase, the product includes all the use cases that the developers and customer have decided to include in the current release;
4. implementation (transition)- product release. The beta version of the product is tested by the company's testing department and at the same time a trial operation of the system by users is organized. The developers then fix the bugs they find and make some of the suggested improvements into a major release that is being prepared for wide distribution.

Each USDP phase may include one or more iterations, depending on the size of the project. During each iteration, 5 main and a number of additional worker threads can be executed.
The main workflows in USDP include:

• definition of requirements (OT);
• analysis (A);
• design (P);
• implementation (P);
• testing (T).

Additional workflows may include:

• quality assurance work (K),
• documentation (D),
• project management (U),
• configuration management (MC),
• creation and management of infrastructure (I)
• and others.

Figure - Life cycle model according to the unified software development process

The choice of a life cycle model largely depends on the type and scale of the system being developed. The iterative life cycle model is applicable to the development of most free-time ASOIs, while the waterfall model is more suitable for real-time systems. In the lectures, when working on IS design issues, we will pay special attention to the use of the Unified Modeling Language (UML), and since its creators are Grady Booch and James Rambo, we will also refer to the ideology of the Unified Development Process.

Picture - Regulations accompanying the development process

Supporting life cycle processes

Quality Assurance Process

Quality assurance process provides appropriate guarantees that the PS and its life cycle processes comply with the specified requirements and approved plans. The quality of the PS is understood as a set of properties that characterize the ability of the PS to meet the specified requirements.

Figure - The structure of the auxiliary processes of the life cycle

In the context of GOST R ISO/IEC 9126-93. "Information technology. Evaluation of software products. Quality Characteristics and Guidelines for Their Application” quality characteristic is understood as “a set of properties (attributes) of a software product by which its quality is described and evaluated”.

The standard defines six comprehensive characteristics that describe the quality of a software product with minimal overlap:

• functionality– a set of attributes related to the essence of a set of functions and their specific properties. Functions are those that fulfill stated or implied needs;
• reliability– a set of attributes relating to the ability of software to maintain its level of performance under specified conditions over a specified period of time;
• practicality– a set of attributes relating to the scope of work required for use and individual assessment of such use by a specific or intended set of users;
• efficiency– a set of attributes related to the relationship between the level of quality of software operation and the amount of resources used under specified conditions
• maintainability– a set of attributes related to the scope of work required to carry out specific changes (modifications);
• mobility– a set of attributes relating to the ability of software to be ported from one environment to another.

GOST 28195-89 “Assessment of the quality of software. General provisions» at the top, first level, it identifies 6 indicators - quality factors: reliability, correctness, ease of use, efficiency, versatility and maintainability. These factors are detailed in the aggregate by 19 quality criteria at the second level. Further detailing of the quality indicators is represented by metrics and evaluation elements, of which there are about 240. Each of them is recommended to be assessed by an expert in the range from 0 to 1. It is proposed to choose the composition of factors, criteria and metrics used depending on the purpose, functions and stages of the life cycle of the PS.

In the standard GOST 28806-90 “Quality of software. Terms and Definitions" are formalized general concepts program, software tool, software product and their quality. Definitions of 18 most commonly used terms related to program performance evaluation are given. The concepts of basic quality indicators given in GOST 28195-89 have been clarified.
The issue of quality assurance of the PS requires special attention, because according to the Decree of the Government of the Russian Federation No. 113 dated 02.02.1998, compliance with the requirements of the international standard for quality assurance and management ISO 9000 is a prerequisite for obtaining a state order.
On the present stage it is not enough to have only methods for assessing the quality of the produced and used software (output control), it is necessary to be able to plan quality, measure it at all stages of the software life cycle and adjust the software production process to improve quality.

The ISO 9000 series standards are too general. Every software company that wants to implement an effective quality management system based on the ISO 9000 series standards must take into account the specifics of its industry and develop a quality scorecard that would reflect the real impact of quality factors on a software product. To this end, many organizations have defined a process for separating systematic and full check- Quality Assurance, which begins with the launch of the project, includes inspection and testing, and is ideally carried out by some independent organization. In fact, most often, quality control is carried out by a group of colleagues of the author of the work.
The purpose of the inspection is to check parts of the design for defects:

• documentation,
• requirements
• analysis results,
• design,
• listings, etc.

The relevance of inspection shows a comparison of the cost and detection and correction of a defect during inspection and during integration according to Fagin, M., "Design and Code Inspections to Reduce Errors in Program Development, IBM Systems Journal. Some authors consider these data to be very underestimated.

Troubleshooting has become much more serious after a multibillion-dollar American satellite sent to Venus lost control due to a typo in the trajectory correction subroutine - a semicolon was put instead of a comma.
Quality assessment and improvement is carried out through the use of metrics - quantitative characteristics of some process indicators.

Inspection requires the following steps:

1. The inspection process begins with planning. Defects are classified by description, severity, and type. The choice of metrics according to which the inspection will be carried out, the choice of tools for collecting and analyzing the received data, as well as the distribution of roles between the inspectors are carried out:
   • The leader is responsible for the correct conduct of the inspection.
   • The proofreader is responsible for the activities of the team and directs it in the right direction. The proofreader takes part in the inspection.
   • The registrar is responsible for recording the description and classification of defects, as is customary in the team. The registrar also participates in the inspection.
   • A specialized inspector is a specialist in some narrow area to which the inspected fragment belongs.
2. If necessary, a review seminar can be organized to better understand the object of inspection.
3. Conducting an inspection. The inspectors check the work in full at their workplaces (for example, check whether the program code being inspected corresponds to the detailed design). The inspectors usually enter all defects into a database (for example, available through the network) along with descriptions and classification. The parts of the system to be inspected must be logically complete.
4. An inspection meeting is held during which the participants present their results.
5. The author corrects defects (refinement phase).
6. At the final meeting on completion of the work, the proofreader and the author make sure that all defects are corrected. However, this does not imply a detailed revision of the entire work by the proofreader. All corrections remain on the conscience of the author responsible for his work.
7. As with other processes, the group meets to discuss the inspection process itself and decide how it can be improved.

The company maintains a record of the time spent on inspections and the amount of work reviewed, with a view to using them in the evaluation of inspections in the future. In the conditions of a strict time limit, the so-called. a "custody" system in which each team member is guarded by a colleague.
To account for all quality control factors, it is convenient to use lists control questions. Such lists contain items that need to be checked sequentially.
For example, the Software Quality Assurance Plan (SQAP) in accordance with the IEEE 739-1989 standard defines:

• who will be responsible for quality individual, manager, group, organization, etc.;
• what documentation is required;
• what methods will be used for quality assurance - inspection, testing, etc.;
• what activities should be carried out in the course of process management - meetings, audits, reviews, etc.

Reliability and security

One of the most significant characteristics included in the concept of quality is the property of reliability.
According to the definition established in GOST 13377-75 “Reliability in engineering. Terms and definitions”, reliability is the property of an object to perform the specified functions, while maintaining the values ​​of the established performance indicators within the specified limits, corresponding to the specified modes and conditions of use, maintenance, repair, storage and transportation. Thus, reliability is an internal property of the system, incorporated during its creation and manifested in time during operation and operation.
The reliability of the functioning of the PS is most widely characterized by stability, or the ability for trouble-free operation, and the recoverability of a working state after failures or failures.
Reliability and security control of created and modified programs should accompany the entire life cycle of the software system through a specially organized effective technological system ensuring their quality. Verification and confirmation of the quality of complex and critical software should be provided by certification by certified problem-oriented certified laboratories.

Standards in the field information security are divided into two groups:

• evaluation standards designed to evaluate and classify IS and means of protection according to security requirements - the standard of the US Department of Defense "Criteria for the evaluation of trusted computer systems”, “Harmonized criteria of European countries”, international standard “Criteria for assessing the security of information technologies”, Guiding documents of the State Technical Commission of Russia;
• specifications governing various aspects implementation and use of security tools and methods published by the Internet Engineering Task Force (IETF) and its subsidiaries, the Security Working Group.

The most important appraisal standards include:

• State Technical Commission of Russia. Guidance document. Computer facilities. Firewalls. Protection against unauthorized access to information. Indicators of security from unauthorized access to information. - Moscow, 1997 - classifies firewalls in accordance with the level of data flow filtering of the reference seven-level model.
• ISO/IEC 15408:1999 Criteria for evaluating information technology security.

The second group includes the following documents:

• X.800 "Security Architecture for Interoperability open systems". The main network security services are identified: authentication, access control, confidentiality and/or data integrity. The following network security mechanisms and their combinations are provided for the implementation of services: encryption, electronic digital signature, access control, data integrity control, authentication, traffic augmentation, routing control, notarization.
• The Internet Community specification RFC 1510 "Kerberos Network Authentication Service (V5)" addresses the problem of authentication in a heterogeneous distributed environment supporting the concept of single sign-on;
• X.500 "Directory service: an overview of concepts, models and services", X.509 "Directory service: certificate frameworks public keys and attributes.

Verification, certification and audit processes

Verification, attestation and audit are integral part quality control plan SQAP IEEE 739-1989.
Verification answers the question: “Are we doing what we planned at this stage?”. Certification and audit answers the question: "Does the object under construction meet the needs of the customer?".
The IEEE 1012-1986 Software Verification and Validation Plan (SVVP) standard combines the validation and audit processes called validation and defines how they are performed.

During the verification process, the following conditions are checked:

• consistency of system requirements and the degree to which user needs are taken into account;
• the supplier's ability to meet specified requirements;
• compliance of the selected processes of the life cycle of the PS with the terms of the contract;
• the adequacy of the standards, procedures and development environment for the PS lifecycle processes;
• compliance of the design specifications of the substation with the specified requirements;
• the correctness of the description in the design specifications of the input and output data, the sequence of events, interfaces, logic, etc.;
• compliance of the code with design specifications and requirements;
• testability and correctness of the code, its compliance with accepted coding standards;
• the correctness of the integration of the PS components into the system;
• the adequacy, completeness and consistency of the documentation.

Joint review process

Joint review process is designed to assess the status of project work and focuses primarily on control planning and management of resources, personnel, equipment and tools of the project.
The evaluation is applied both during project management and during the technical implementation of the project and is carried out during the entire term of the contract. This process can be performed by any two parties involved in the contract, with one party checking the other.

Problem resolution process

Problem resolution process provides for the analysis and resolution of problems (including detected nonconformities), regardless of their origin or source, that are discovered during development, operation, maintenance or other processes. The problem resolution process is closely related to risk management. Factors that cause a project to fail manifest themselves in the form of risks. Risk management consists of identification, elimination planning, prioritization, elimination (or mitigation).

The reasons for the emergence of risks can be the following:

1. Fuzzy and/or incomplete wording of requirements;
2. Insufficient involvement of stakeholders in the project;
3. Poor planning - lack of competent project management;
4. Frequent changes in requirements caused by changes in the scope, project objectives, and other reasons;
5. Imperfection of the design technology used;
6. Lack of knowledge or skills among performers.

There are two ways to prevent risks:

1. making changes to the requirements of the project, eliminating the cause of the risk;
2. technology development, problem solving associated with the occurrence of risk.

In the process of managing a project, the manager should from time to time initiate a process of identifying risks in various parts of the project in order to compile a list of risks awaiting treatment. For each risk, three values ​​are determined: the probability of risk realization; the damage caused to the project by this risk in the event of its implementation; assessment of the cost of eliminating the risk. For all values, one scale is used, for example 1 - 10.

Documentation and configuration management process

“Documentation management of a software project requires significant organizational effort, because documentation is a complex system subject to constant changes that can be made simultaneously by many people" (E. Braude)

The documentation process provides for a formalized information description created during the life cycle of the PS. This process consists of a set of actions by which they plan, design, develop, issue, edit, distribute and maintain documents necessary for all interested parties (managers, technical specialists and system users).

GOST R ISO/IEC 9294-93. "Information technology. Software Documentation Management Guide" establishes guidelines for good governance PS documentation. The purpose of the standard is to assist in defining a strategy for documenting the OS; choice of standards for documentation; choice of documentation procedures; determining the necessary resources; drawing up documentation plans.

Documentation management involves keeping it complete and consistent (some authors include configuration management here).

Completeness of documentation characterized by the number of standards and regulatory documents that formed the basis of a set of documentation that accompanies one or another process of the life cycle of the PS.
Documentation Consistency means that the set of documents will not have internal inconsistencies. This is achieved by placing each specification in only one place - such documentation is called holistic. The integrity of the documentation is ensured through the use of hyperlinks.

Every requirement must be traceable, for this, each requirement is provided with a unique number, which is then referred to during concept development, design, and up to method listings.

• // requirement 4.3
• // author
• // version
• // arguments
• …method listing…

Parts of the project include not only the source code of the programs, but also all the documentation, including the project plan. During the life of the projects undergo changes in two directions:

• First, it is the acquisition of new parts,
• Second, getting new versions of existing parts. To correctly track these changes, a specially organized set of administrative and technical procedures is used, which are related to the configuration management process.

To keep track of project parts, you need to define their boundaries and highlight configuration items (Configuration Items - CIs). Configuration elements can be classes, less often functions, significant data sets - global tables, documentation. Accounting for the state of the configuration is carried out by registering the state of the PS components, preparing reports on all implemented and rejected modifications of the versions of the PS components. The set of reports provides an unambiguous reflection of the current state of the system and its components, as well as maintaining the history of modifications.
There are special software tools for configuration management (for example, Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion, etc.).

Typically, configuration management systems meet the following minimum requirements:

• the ability to define configuration elements;
• storage in the configuration management database of complete chronologies of versions of each object created or changed during the development of the system (these include source code, libraries, executable programs, models, documentation, tests, web pages and catalogs);
• support for geographically dispersed development teams;
• denying the right to modify to prevent more than one person working on a configuration item at the same time;
• control of changes made to all objects of the system;
• assembly of software versions from project components.

The IEEE developed the IEEE 828-1990 standard"Software Configuration Management Plan (SCMP)". The title of the standard and an example of drawing up a Configuration Management Plan is given in the book by Eric Braude.

Figure - Normative documents of auxiliary processes of the life cycle

Organizational life cycle processes

The organizational processes of the life cycle include: the process of creating an infrastructure, the process of improvement, the process of learning, the process of management.

Figure - The structure of the organizational processes of the life cycle

Infrastructure process

is the process of establishing and providing (maintaining) infrastructure, which may contain hardware and software, tools, methodologies, standards and conditions for development, operation or maintenance. At the 1st stage of creating the infrastructure, the choice of a CASE-system for design support, the choice of a programming language, a DBMS are carried out; organization of a support service - system administrators, network administrators, database administrators, secretaries, etc.
When solving the selection problem using literary sources, it is necessary to analyze the capabilities of the most common instrumental systems in order to build a classification, and then, within a certain classification group, determine the parameters by which the choice will be made.
The actual selection procedure includes the following steps:

1. The basic indicators of the selected system are identified that are significant in the design of a given ASOIU, taking into account its features, limitations, resources, etc.
2. All indicators are summarized in a table (see Table 5), in which, based on expert assessments, each indicator is assigned a weighting coefficient Vi (for example, from 1 to 10), which characterizes the significance of this indicator compared to the others. The sum of the values ​​of all weighting factors must be equal to the upper limit of the weighting factor (for example, 10).
3. Using data obtained from literary sources and / or from experts, for each i-th indicator for each j-th system, the degree of utility Ui,j is determined (from 1 - minimum, to 10 - maximum). For example, the utility of a configuration management system that is relatively expensive might be 1, while the utility of a freeware system would be 10.
4. For each j-th compared system, the value of the evaluation function is calculated by the formula: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
5. Based on the value of the evaluation function, a conclusion is made about the appropriateness of using a particular system in this project, taking into account the selected criteria and specified restrictions. The system for which the value of the evaluation function turns out to be greater is the best in terms of choosing from among the compared alternatives.

Learning process

is the process of providing initial and continuing training to staff. Order, delivery, development, operation and maintenance of software products largely depend on the qualifications of the staff. Therefore, personnel training must be planned and carried out in advance in order to prepare them for work on the order, delivery, development, operation or maintenance of a software project.

Improvement process

is the process of establishing, evaluating, measuring, controlling and improving any software life cycle process. In engineering practice, when developing IS, metrics are used - quantitative characteristics of some indicators.

The most commonly used metrics are:

• the amount of work done, measured in physical units (for example, the number of lines of code);
• time spent on work;
• the degree of defectiveness (for example, the number of defects per 1000 lines of code, the number of defects per documentation page, etc.).

Preliminary or desired metric values ​​are predicted in advance and then compared with the results obtained.
Since the metrics associated with defectiveness play a special role, we list some of them:

1. The number of defects per thousand lines of code found within 12 weeks of project delivery.
2. Schedule deviations in each phase: (Actual Duration - Planned Duration) / Planned Duration.
3. Cost Variances: (Actual Cost - Planned Cost) / Planned Cost.
4. Total design time / Total programming time (according to some estimates, it should be at least 50%).
5. The degree of occurrence and detection of defects at some stage is one of the simplest metrics.

When the results of defect detection are compared with the norms of the organization, the entire process of creating the system as a whole is evaluated, and not just a specific project. The accumulated data on defects at each stage are tabulated as shown, for example, in Table.

Stages at which defects were found (in this project / norm)	Stages containing defects
	Formation of requirements	Technical task	Preliminary design
Formation of requirements	2/5
Technical task	0,5/1,5	3/1
Preliminary design	0,1/0,3	1/3	2/2

Analysis of the stage "Formation of requirements" shows that the degree of detection of defects is less than the norm at all stages of the project. More design defects were found directly in the phase when they were produced and fewer defects were found in later phases. Typically, this is achieved through inspections.

The sequence of actions that need to be taken throughout the life cycle of the project in order to improve it, for example, can be as follows:

1. Identify and define metrics to be used by the team in each phase, including:
   • time spent on research, implementation and analysis of results;
   • size (for example, the number of lines of code);
   • the number of defects found in the module (for example, the number of lines of code) and the source of the defect detection;
   • quality rating on a scale from 1 to 10.
2. Document the received information in SQAP.
3. Collect statistics on each phase.
4. Assign developers responsible for data collection in each phase, for example, "responsible for quality".
5. Plan reviews of metric data that will be useful in the future. It is necessary to determine in advance what the values ​​of the metrics can be and what should be. The data obtained will form the basis for creating a database on the company's projects.

Organization Capability Maturity Model

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.
In the early 1990s, the American Institute of Software Engineering (Software Engineering Institute - SEI of Carnegie Mellon University (Pittsburgh, Pennsylvania, USA)) formed a model of technological maturity of CMM organizations (Capability [capability] Maturity [matsharity] Model). Currently, in the west, the development company is experiencing significant difficulties in obtaining an order if it is not certified according to CMM.
SMM is methodical material, defining the rules for the formation of a management system for the creation and maintenance of software and methods for the gradual and continuous improvement of production culture. The purpose of the SMM is to provide development 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. At each level of the CMM, requirements are set, upon fulfillment of which stabilization of the most significant indicators of processes is achieved.

Management Process

Project management is about achieving a balance between cost, capabilities, quality and timing. There are several aspects associated with the project management process: personnel management, scheduling, project cost estimation.

Personnel Management

Known empirical data to determine the optimal number of team members.

Figure - Dependence of the effectiveness of the development team on its composition

This dependence leads to the need to use hierarchical control structures.

Figure - Hierarchical management structure

Despite the fact that the number of connections of each employee is satisfactory, they do not participate in the formulation of the problem, which violates one of the main requirements of system analysis - the maximum possible number of stakeholders should take part in the discussion of the problem.
An alternative scheme for organizing a team of employees is called a “team of equals”. In this case, all team members are at the same level of the hierarchy and roles are distributed between them. Moreover, the distribution of roles can change after a certain period of time. The problem of increasing the number of connections in a large project in this case is solved by allocating the role of the person responsible for external communications.

In the concept of Extreme Programming proposed by Kent Back. emphasis is placed on the continuous relationship between developers and the customer (moreover, the customer is made one of the participants in the development), the desire for a radical simplification of the system development process and pair programming. Moreover, with pair programming, developers work only together at one computer in turn. Thus, a form of continuous inspection is realized.

Schedule preparation

There are many standards that describe the creation and maintenance of software project management plans. It is recommended to use the IEEE 1058.1-1987 Software Project Management Plan (SPMP) standard. The SPMP provides a schedule that specifies how and when the various phases of the project are to be completed. At the end of each subsequent stage of the design, the schedule needs to be supplemented and adjusted. The most common form of project schedule presentation is the Gantt chart.

Figure - Approximate view of the Gantt chart

It is recommended that the plan include buffer periods when no processes are scheduled to run. The schedule in the form of a Gantt chart, in most cases, is built using Microsoft Office Project.
The process of planning work on the implementation of the project in particular and project management in general is associated with an assessment of the cost and duration of the project. This information is provided in section 5.4. The SPMP “budget and resource allocation” and, in addition, a preliminary project cost estimate can affect the final version of the contract between the customer and the contractor, and therefore should be carried out before signing the TOR.

Estimating the costs of creating a PS

The process of estimating the complexity, as a rule, begins simultaneously with the start of the project and continues even at the stage of writing the program code.

Among the most common methods for assessing labor intensity, the following are distinguished:

• Algorithmic modeling. The method is based on the analysis of statistical data on previously completed projects, while determining the dependence of the complexity of the project on some quantitative indicator of the software product (usually the size of the program code). This indicator is estimated for this project, after which the model predicts future costs.
• Expert assessments. A survey is conducted of several experts in software development technology who know the scope of the software product being created. Each of them gives its own assessment of the complexity of the project. Then all scores are compared and discussed.
• Evaluation by analogy. This method is used if similar projects have already been implemented in the given field of application of the software being created. The method is based on comparing the planned project with previous projects with similar characteristics. It uses expert data or saved project data. Experts calculate a high, low, and most likely estimate of effort based on differences between new and previous projects.

Each assessment method has weaknesses and strengths Therefore, approaches that combine various methods are currently used.

The procedure for assessing the complexity of software development consists of the following steps:

1. estimation of the size of the developed product;
2. assessment of labor intensity in man-months or man-hours;
3. project duration estimate in calendar months;
4. project cost estimate.

The main units for measuring software size are:

• number of lines of code (LOC - Lines of Code);
• functional points (FP - Function Points).

Functional Size Estimation Methodology

Functional Size Estimation Methodology (FP – Functional Points) is to uniformly measure all the capabilities of an application and express the size of the application as a single number. This number can then be used to estimate the number of lines of code, cost, and timeline for the project.
To calculate the functional size, the rank and complexity are determined for each information characteristic of the system. The International Function Point Users Group (IFPUG - International Function Point Users Group, www.ifpug.org) has published criteria according to which information characteristics should be distinguished, which are divided into five groups:

• – a user-recognizable group of logically related data that is located within the application and served through external inputs.

• – A user-recognizable group of logically related data that is hosted and maintained by another application. An external file of this application is an internal logical file in another application.

• - an elementary process that moves data from the external environment to the application. The data may come from communication channels, from the user on an input screen, or from another application. The data can be used to update internal logical files and can contain both management and business information. Control data must not modify the internal logical file (eg data entry fields, error messages, calculated values, buttons).

• is an elementary process that moves the data calculated in the application to external environment. In addition, internal logical files may be updated in this process. The data creates reports or output files that are sent to other applications. Reports and files are generated from internal logical files and external interface files. Additionally, this process can use input data, which is formed by search criteria and parameters that are not supported by internal logical files. Input data comes from outside but is temporary and not stored in an internal logical file (eg data fields in reports, calculated values, error messages).

• – an elementary process that works with both input and output data, consisting of a request-response combination, but not related to the calculation of derived data or updating the ILF. Its result is the data returned from internal logical files and external interface files. The input part of the process does not modify the internal logical files, and the output part does not carry data calculated by the application (this is the difference between a request and an output). For example: input elements - the field used for searching, mouse click; output elements - fields displayed on the screen.

Baryshnikova Marina Yurievna
MSTU im. N.E. Bauman
Dept. PS-7

Lecture 3

Software life cycle
ensure

Software life cycle

is the period of time that starts from
the time of the decision to
the need to create software
security and ends at the moment
its complete removal from service
(IEEE Std. 610.12 - 19990 Standard Glossary of Software
engineering terminology)

The main concepts involved in the definition of the life cycle

Artifacts - human-made information
entities are documents, in a fairly general sense
participating as input and resulting in
as the results of various activities.
Role - an abstract group of stakeholders,
involved in the creation and operation of
systems that solve the same problems or have the same
and the same interests towards her
A software product is a set of computer programs
procedures and possibly associated documentation and
data
A process is a set of interrelated activities
converting some input to output

Software life cycle according to ISO/IEC 12207: 1995
"International Technology - Software Life Cycle Processes"
(GOST ISO IEC 12207-99 Information technology.
Software life cycle)
Life cycle
Organizational
processes
Control
project
Creation
infrastructure
Evaluation and improvement
life cycle
Education
Main
processes
Acquisition
Auxiliary
processes
Documentation
Supply
Control
configuration
Development
Security
quality
Exploitation
Verification
Escort
Certification
joint
grade
Audit
Permission
problems

Software acquisition process
Defines the actions of the customer who purchases the software
software-related software or services on a contractual basis
relations
During this process, the customer performs the following
actions:
awareness of their needs in the software system and
making a decision regarding the purchase, development to order
or improvements to an existing system;
preparation of application proposals containing requirements for
system, its operating conditions and technical
restrictions, as well as other conditions of the contract
Acquisition - the process of obtaining a system,
software product or software service

Delivery process
Defines the activities of the provider organization for
in relation to the customer's bids
The process includes:
consideration of the customer's application proposals and making them
their adjustments (if necessary);
preparation of a contract with the customer;
work execution planning (work may
carried out on its own or with the involvement of a subcontractor);
development organizational structure project, technical
requirements for the development environment and resources, measures to
project management, etc.
The delivery process is responsible for executing the processes
development, operation and (or) maintenance

Development process

Defines the actions to be taken by the developer in
the process of creating software and its
components in accordance with specified requirements
This process includes, among other things:
design and operational
documentation;
preparation of materials necessary for verification
performance of the software product and its
compliance with quality standards;
development of materials (methodological and educational),
necessary for the training and education of personnel and
etc.

Development process

Choosing a Life Cycle Model
System requirement analysis
System Architecture Design
Analysis of software requirements
Detailed software engineering
Software coding and testing
Software integration
Software qualification testing
System integration
System Qualification Testing
Software installation
Software acceptance

10. Analysis of system requirements

At this stage, the scope of the system is considered.
The list of requirements for the developed system should include:
set of conditions under which it is intended to operate
future system (hardware and software resources,
provided to the system; external conditions of its functioning;
composition of people and works related to it);
description of the functions performed by the system;
restrictions in the development process (directive deadlines for completion
individual stages, available resources, organizational procedures
and measures to ensure the protection of information, etc.)
System requirements are evaluated based on criteria
feasibility and verifiability during testing

11. Analysis of software requirements

Assumes the definition of the following
characteristics for each software component:
functionality, including
performance and environment characteristics
component functioning
external interfaces
reliability and safety specifications;
ergonomic requirements
requirements for the data used
installation and acceptance requirements
requirements for user documentation
requirements for operation and maintenance

12. Software architecture design

Software architecture
is a description of the subsystems and components of the software
systems and the connections between them.
As part of the architecture design for each
The software component performs the following tasks:
high-level definition of structure abstraction
software and composition of its components
development and documentation of software
software and database interfaces
development of a preliminary version of a custom
documentation
development and documentation of preliminary
test requirements and software integration plan

13. Detailed software design (software development work plan)

Includes the following tasks:
description of software components and interfaces between
them in an amount sufficient for their
subsequent self-coding and
testing
development and documentation of detailed
database project
user documentation update
development and documentation of requirements for
tests and software component test plan

14. Coding and software testing involves solving the following tasks:

development (coding) and documentation
each component of the software and database, and
set of test procedures and data for
testing
testing of each software component and base
data for compliance with the requirements
requirements
updating (if necessary) user
documentation
software integration plan update

15. System integration

is to assemble all
components, including software and
equipment, and testing
aggregated components
The integration process also
registration and verification of the complete set
system documentation

16. Software qualification testing

carried out by the developer in the presence
customer to demonstrate that the software
meets its specifications and
ready to use in conditions
exploitation
It also checks the completeness
technical and user documentation and
its adequacy to software components

17. Installation and acceptance of software

Software installation is carried out by the developer in
in accordance with the plan in that environment and on that
equipment provided for in the contract. AT
the installation process checks the functionality
Software and databases
Software acceptance provides for the evaluation of results
system qualification testing and
documentation of evaluation results, which
produced by the customer with the help of the developer.
The developer performs the final transfer of the software
to the customer in accordance with the contract, providing
with the necessary training and support

18. Operation of the software

The system is operated in
environment intended for this
according to custom
documentation
Includes setting
operating standards and
operational
testing

19. Software maintenance (according to IEEE-90 standard)

making changes to the software to correct
errors, performance improvements or
adaptation to changing working conditions
or requirements
Escort service functions:
analysis of problems and requests for software modification
software product modification
its verification and acceptance
porting software to another environment
software decommissioning

20. Auxiliary processes of software life cycle

Documentation
Configuration Management
Quality assurance
Verification
Certification
Joint evaluation
Audit
Problem resolution

21. Documentation process

Documentation - formalized description
information generated throughout
software life cycle
This is a set of actions that
plan, design, develop,
produce, edit, distribute and
accompany the documents required for all
stakeholders involved in the development
Software, as well as for system users

22. Configuration management

The software configuration is
the totality of its functional and physical
characteristics established in the technical
documentation and implemented in programs
The process allows you to organize, systematically
take into account and control changes in
Software at all stages of the life cycle
General principles and recommendations for configuration management are reflected
in ISO/IEC CD 12207 – 2:1995 “Information Technology – Software
cycle processes. Part 2. Configuration Management for Software”

23. Quality assurance process

Provides assurance that the software product and
the processes of its life cycle correspond to the given
requirements, as well as developed and approved
work plans
Quality is a set of properties that characterize
the ability of the software to meet
given requirements and needs of all interested
parties
The process is designed to ensure compliance
life cycle processes, development environment and
qualification of personnel under the terms of the contract established
standards and procedures. For this there must be
product quality, process quality and other
system quality indicators

24. Verification

It is the process of determining whether the current state of development meets,
achieved at this stage, the requirements of this stage. In the process
Verification checks the following conditions:
consistency of system requirements and the degree to which needs are taken into account
user
supplier's ability to meet specified requirements
compliance of the selected software life cycle processes with the terms of the contract
adequacy of standards, procedures and development environment for software life cycle processes
compliance of design specifications with specified requirements
the correctness of the description in the design specifications of the input and output
data, sequence of events, logic, etc.
compliance of code with design specifications and requirements
testability and correctness of the code, its compliance with accepted standards
coding
correct integration of software components into the system
adequacy, completeness and consistency of documentation
Verification is a set of actions to compare
the resulting life cycle result with the required characteristics
for this result, which is considered as a formal proof
software correctness

25. Certification

provides for the definition of completeness
compliance with the specified requirements and
created system or software
product to their specific
functional purpose
Verification and certification - two views on quality:
if verification evaluates software in terms of how it is created,
then certification considers software system from the point of view of
what it does (i.e. evaluates the ability of a software system
satisfy the functional needs of users)

26. Organizational processes of software life cycle

Control
Creation of infrastructure (infrastructure
software project includes technology and
standards, as well as a set of hardware,
software and tools for
software development, operation or maintenance)
improvement
Training (initial training and
subsequent permanent increase
staff qualifications, including the development
teaching materials)

27. Groups of ESPD standards

Group code
0
1
2
3
4
5
6
7
8
9
Group name
General provisions
Fundamental Standards
Development Documentation Rules
Rules for the execution of manufacturing documentation
Maintenance Documentation Rules
Rules for the implementation of operational documentation
Rules for handling program documentation
Reserve groups
Other standards
The designation of the ESPD standard consists of:
number 19 (assigned to the class of ESPD standards);
one digit (after the dot) indicating the code of the classification group of standards,
indicated in the table;
a two-digit number (after the dash) indicating the year the standard was registered

28. List of ESPD documents

GOST 19.001-77 ESPD. General provisions
GOST 19.101-77 ESPD. Types of programs and program documents
GOST 19.102-77 ESPD. Development stages
GOST 19.103-77 ESPD. Designation of programs and program documents
GOST 19.104-78 ESPD. Basic inscriptions
GOST 19.105-78 ESPD. General requirements to policy documents
GOST 19.106-78 ESPD. Requirements for program documents made in printed form
GOST 19.201-78 ESPD. Technical task. Requirements for content and design
GOST 19.202-78 ESPD. Specification. Requirements for content and design
GOST 19.301-79 ESPD. Procedure and test procedure
GOST 19.401-78 ESPD. Program text. Requirements for content and design
GOST 19.402-78 ESPD. Program description
GOST 19.404-79 ESPD. Explanatory note. Requirements for content and design
GOST 19.501-78 ESPD. Form. Requirements for content and design
GOST 19.502-78 ESPD. Description of the application. Requirements for content and design
GOST 19.503-79 ESPD. System programmer's guide. content requirements and
registration
GOST 19.504-79 ESPD. Programmer's Guide
GOST 19.505-79 ESPD. Operator's manual
GOST 19.506-79 ESPD. Language description
GOST 19.508-79 ESPD. Guide maintenance. content requirements and
registration
GOST 19.604-78 ESPD. Rules for making changes to program documents performed
printed
GOST 19.701-90 ESPD. Schemes of algorithms, programs, data and systems. Conventions and
execution rules
GOST 19.781-90. Provision of information processing systems

29. Benefits of using ESPD standards

ESPD standards introduce an element of streamlining into
software documentation process
(PS);
despite the presence of requirements for the kit
documentation for the PS, provided for by the standards
ESPD, they allow you to make additional types
documents;
ESPD standards allow mobile change
structure and content of established views
program documents based on the requirements
customer and user

30. Disadvantages of ESPD standards

orientation to a single, "cascade" model of life
software cycle;
lack of clear guidelines for documentation
software quality characteristics;
lack of systemic linkage with other existing
domestic systems of standards for the life cycle and
documenting products in general, for example, ESKD;
fuzzy approach to documenting PS as
commercial products;
lack of recommendations for self-documenting PS,
e.g. in the form of on-screen menus and online help tools
user ("helps");
lack of recommendations on the composition, content and design
documents for software, agreed with
recommendations of international and regional standards

31. Standard GOST 34.601-90: stages and stages of creating an automated system

1.
Formation of requirements for the AU
2.
Development of the AS concept
3.
Studying the object
Carrying out the necessary research work
Development of variants of the AU concept and selection of the variant of the AU concept,
meeting user requirements
Preparation of a report on the work done
Technical task
4.
Inspection of the object and justification for the need to create an AU
Formation of user requirements for the AU
Registration of a report on the performance of work and an application for the development of AS
Development and approval terms of reference to create AS
Preliminary design
Development of preliminary design solutions for the system and its parts

32.

Standard GOST 34.601-90: stages and steps
creation of an automated system
5.
Technical project
6.
working documentation
7.
Development of working documentation for the NPP and its parts
Development and adaptation of programs
Commissioning
8.
Development of design solutions for the system and its parts
Development of documentation for the AU and its parts
Development and execution of documentation for the supply of components
Development of design tasks in adjacent parts of the project
Preparation of the automation object
Staff training
Completion of the AU with the supplied products (software and hardware,
software and hardware complexes, information products)
Construction and installation works
Commissioning works
Carrying out preliminary tests
Conducting trial operation
Conducting acceptance tests
AC support
Performing work in accordance with warranty obligations
Post-warranty service

Goals and objectives of the design methodologyON. Main areas of designON. Stages of creationON.

Software (Software) - an intellectual product that does not depend on the environment on which it is written, including programs, rules, and related data, which, when loaded into the execution area of ​​a computer program, ensures its functioning.

Software (Software product) - a set of computer programs, procedures and, possibly, related documentation and data.

Software (Software product) - any set of computer programs, procedures and associated documentation and data resulting from the development of software products and intended for delivery to the user [ISO / IEC 12207]. Note. Products include intermediate products and products intended for users such as developers and maintainers.

Software development (Software engineering) A form of development that applies the principles of computer science, information technology, mathematics, and the applied field to achieve cost-effective solutions to practical problems through software.

Software design is the process of building applications of real size and practical value that meet specified functionality and performance requirements.

Programming - it is one of the activities included in the software development cycle.

Stages of software development

1. Understand the nature and scope of the proposed product.

2. Select a development process and create a plan.

3. Gather requirements.

4. Design and assemble the product.

5. Perform product testing.

6. Release the product and maintain it.

Under the life cycle of the program, we mean the set of stages:

Analysis of the subject area and creation of technical specifications (interaction with the customer)

Program structure design

Coding (a set of program code according to project documentation)

Testing and Debugging

Program implementation

Program support

Disposal

The concept of the life cycle (LC) of software. Definition of life cycle by international standard ISO/IEC 12207:1995. The main processes of the software life cycle.

The software life cycle is a continuous process that starts from the moment a decision is made on the need for its creation and ends at the moment of its complete withdrawal from operation.

The life cycle (LC) of software (SW) is defined as a period of time that begins from the moment a decision is made on the need to create software and ends at the time of its complete withdrawal from service.

The main regulatory document regulating the composition of software life cycle processes is the international standard ISO / IEC 12207: 1995 "Information Technology - Software Life Cycle Processes" (ISO - International Organization for Standardization - International Organization for Standardization, IEC - International Electrotechnical Commission - International Commission for It defines a lifecycle structure that contains the processes, activities, and tasks that must be performed during software development.

In this standard Software (or software product) defined as a set of computer programs, procedures, and possibly associated documentation and data.

Process is defined as a set of interrelated actions (a set of interrelated activities) that transform some initial (input data) into output (results). Each process is characterized by certain tasks and methods for their solution, initial data obtained from other processes, and results.

Each process divided into a set of actions, each action- per set tasks. Each process, action, or task is initiated and executed by another process as needed, and there are no predetermined execution sequences (of course, while maintaining the input data connections).

Main life cycle processes :

Order (acquisition);

Action - initiating acquisition

Action - preparation of bids

Action - preparation and adjustment of the contract

Action - Supervision of the activities of the supplier

In the process acceptance necessary tests are prepared and carried out. Completion of work under the contract is carried out if all conditions of acceptance are met

Supply;

Delivery initiation

Planning

Development;

The development process provides for the activities and tasks performed by the developer and includes the following activities

Preparatory work

System requirement analysis

System Architecture Design at a high level is to determine the components of its hardware, software and operations performed by personnel operating the system. The architecture of the system must comply with the system requirements and accepted design standards and practices.

Analysis of software requirements

Software architecture design

Software coding and testing

Software integration

Software qualification testing

System integration

Software installation

Software acceptance

Exploitation; covers the actions and tasks of the operator - the organization operating the system and includes the actions:

Preparatory work includes the following tasks performed by the operator:

planning activities and work performed during operation, and setting operational standards;

determination of procedures for localization and resolution of problems arising during operation.

Operational Testing is carried out for each next edition of the software product, after which it is transferred to operation.

System operation

User support

Processescorts provides for the activities and tasks performed by the maintenance service. In accordance with the IEEE-90 standard under escort means making changes to the software to fix bugs, improve performance, or adapt to changing operating conditions or requirements.

Preparatory work support service includes the following tasks:

planning of actions and works performed in the process of maintenance;

determination of procedures for localization and resolution of problems arising in the process of maintenance.

Analysis of problems and requests for software modification

Software modification

Inspection and acceptance

Decommissioning the software is carried out by the decision of the customer with the participation of the operating organization, maintenance service and users. At the same time, software products and related documentation are subject to archiving in accordance with the contract.

The concept of the life cycle (LC) of software. Definition of life cycle by international standard ISO/IEC 12207:1995. Auxiliary processes of software life cycle.

See point 2

Auxiliary life cycle processes :

Documentation; a formalized description of the information created during the life cycle of the software.

The documentation process includes the following steps:

preparatory work;

design and development;

release of documentation;

escort

Configuration Management her; to determine the status of software components in the system, manage software modifications, describe and prepare reports on the status of software components and requests for modifications, ensure the completeness, compatibility and correctness of the software, manage storage and delivery of software. According to the IEEE standard - 90 under configuration Software is understood as the totality of its functional and physical characteristics set in the technical documentation and implemented in the software.

preparatory work

configuration identification establishes rules by which software components and their versions can be uniquely identified and distinguished

configuration control designed to systematically evaluate proposed software modifications and coordinate their implementation, taking into account the effectiveness of each modification and the cost of its implementation

configuration state accounting (represents the registration of the state of the software components, the preparation of reports on all implemented and rejected modifications of the versions of the software components). + modification history

configuration evaluation (consists in assessing the functional completeness of the software components, as well as the compliance of their physical condition with the current technical description);

release management and delivery (cover the production of master copies of programs and documentation, their storage and delivery to users in accordance with the procedure adopted in the organization).

Quality assurance;

Quality Assurance Process provides appropriate assurance that the software and its life cycle processes comply with specified requirements and approved plans. Under software quality refers to a set of properties that characterize the ability of software to meet specified requirements.

The quality assurance process includes the following steps:

preparatory work

ensuring the quality of the product; guaranteeing the full compliance of software products and their documentation with the requirements of the customer, provided for in the contract;

ensuring the quality of the process of compliance of the software life cycle processes, development methods, development environment and staff qualifications with the terms of the contract established ensuring other system quality indicators

Verification; consists in determining that software products fully satisfy the requirements or conditions due to previous actions (verification in the narrow sense means formal proof of software correctness).

preparatory work;

verification;

The verification process checks the following conditions:

consistency of system requirements and the degree to which user needs are taken into account;

the ability of the supplier to meet specified requirements;

compliance of the selected software life cycle processes with the terms of the contract;

the adequacy of the standards, procedures and development environment for the software life cycle process;

compliance of software design specifications with specified requirements;

the correctness of the description in the design specifications of the input and output data, the sequence of events, interfaces, logic;

compliance of the code with design specifications and requirements;

testability and correctness of the code, its compliance with accepted coding standards;

correct integration of software components into the system;

the adequacy, completeness and consistency of the documentation.

Certification;

provides for the determination of the completeness of the compliance of the specified requirements and the created system or software product with their final functional purpose. Certification is usually understood as confirmation and assessment of the reliability of the test passed. Certification is recommended to be carried out by testing in all possible situations and using independent specialists.

Joint assessment(Joint analysis); to assess the status of work on the project and software.

Evaluation is applied both at the level of project management and at the level of technical implementation of the project and is carried out during the entire term of the contract. This process can be performed by any two parties involved in the contract, with one party checking the other.

The participatory assessment process includes the following steps:

preparatory work;

assessment (analysis) of project management;

technical assessment.

Audit;

determination of compliance with the requirements, plans and conditions of the contract. An audit can be performed by any two parties involved in the contract, with one party checking the other. An audit is an audit (inspection) carried out by a competent authority (person) in order to ensure independent evaluation the degree to which software or processes conform to specified requirements.

Permission(Solution) problems.

provides for the analysis and resolution of problems (including detected nonconformities), regardless of their origin or source, that are discovered during development, operation, maintenance or other processes. Each problem found must be identified, described, analyzed and resolved.

The concept of the life cycle (LC) of software. Definition of life cycle by international standard ISO/IEC 12207:1995. Organizational processes of software life cycle. Relationship between software life cycle processes.

See point 2

Organizational processes of life cycle :

Control;

consists of actions general works) and tasks that can be performed by any party managing its resources. This party (manager) is responsible for product release management, project management and task management of related processes such as acquisition, supply, development, operation, maintenance, etc. For example, an administrator is responsible for project management, delivery, development, operation, maintenance, etc.

The management process includes the following steps:

preparation and definition of the scope of management . The manager must make sure that the resources necessary for management (personnel, equipment and technology) are at his disposal in sufficient quantities;

planning involves performing at least the following tasks:

drawing up work schedules;

cost estimate;

allocation of required resources;

distribution of responsibility;

assessment of risks associated with specific tasks;

creation of management infrastructure.

implementation and control;

verification and evaluation;

completion.

Creation of infrastructure;

covers selection and support (technology maintenance), standards and tools, selection and installation of hardware and software used to develop, operate or maintain software. The infrastructure must be modified and maintained in accordance with changes in the requirements for the corresponding processes. Infrastructure, in turn, is one of the objects of configuration management.

improvement;

provides for the assessment, measurement, control and improvement of software life cycle processes.

Education.

covers initial training and subsequent ongoing staff development.

Relationship between software life cycle processes

The software life cycle processes defined in ISO/IEC 12207 can be used by different organizations in specific projects in a variety of ways. However, the standard offers some basic set of relationships between processes from different perspectives (Figure 1). These aspects are:

contractual aspect;

aspect of management;

aspect of operation;

engineering aspect;

support aspect.

AT contractual aspect the customer and the supplier enter into a contractual relationship and implement the procurement and delivery processes respectively. AT aspect of management the customer, supplier, developer, operator, maintainer and other parties involved in the software life cycle manage the execution of their processes. AT aspect of operation the operator operating the system provides the necessary services to the users. AT engineering aspect the developer or maintenance service solves the corresponding technical problems by developing or modifying software products. AT aspect of support services that implement auxiliary processes provide the necessary services to all other participants in the work.

The relationships between processes described in the standard are static character . More important dynamic links between processes and the parties implementing them are established in real projects.

The concept of the model and stage of the software life cycle. Characteristics of the stages of software development.

1) International standard ISO/ IEC 12207: 1995 This is how the life cycle model is defined:

The software life cycle model is understood as a structure that determines the sequence of execution and the relationship of processes, actions, tasks throughout the life cycle. The life cycle model depends on the specifics, scale and complexity of the project and the specific conditions in which the system is created and operates.

2) GOST R ISO/IEC 12207-99 This is how the life cycle model is defined:

Life cycle model - a structure consisting of processes, activities and tasks, including the development, operation and maintenance of a software product, covering the life of the system from establishing requirements for it to the termination of its use.

Under stage software creation is understood as a part of the software creation process, limited by some time frame, and ending with the release of a particular product (software models, software components, documentation), determined by the requirements specified for this stage. The stages of software creation are distinguished for reasons of rational planning and organization of work, ending with the desired results.

The composition of the software life cycle usually includes the following stations:

Formation of software requirements.

Design.

Implementation.

Testing.

Commissioning.

Operation and maintenance.

Decommissioning.

The concept of a software life cycle model. Waterfall (cascade) model of software life cycle.

See point 5

In the initially existing homogeneous IS, each application was a single whole. To develop this type of application, a cascading method was used. Its main characteristic is the division of the entire development into stages, and the transition from one stage to the next occurs only after the work on the current one is fully completed (Fig. 2). Each stage ends with the release of a complete set of documentation, sufficient for development to be continued by a team of specialists in the next stage.

Benefits of using the cascade method :

at each stage, a complete set of project documentation is formed that meets the requirements for completeness and consistency;

the stages of work performed in a logical sequence allow you to plan the timing of the completion of all work and the corresponding costs.

The cascade approach has proven itself in building IS, for which at the very beginning of development it is possible to formulate all the requirements quite accurately and completely in order to give developers the freedom to implement them technically as best as possible.

At the same time, this approach has a number of disadvantages, primarily due to the fact that the actual process of creating software never fully fits into such a rigid scheme. The software development process is usually iterative nature : the results of the next stage often cause changes in the design decisions developed in the previous stages. Thus, there is a constant need to return to previous stages and clarify or revise previously made decisions. As a result, the real process of creating software takes a different form (Fig. 2).

Significant delay in obtaining results. Coordination of the results with users is carried out only at the points planned after the completion of each stage of work, the requirements for the IS are “frozen” in the form of a technical assignment for the entire time of its creation. Thus, users can submit their comments only after the work on the system is fully completed. If the requirements are inaccurate or change over a long period of software development, users end up with a system that does not meet their needs. Models (both functional and informational) of an automated object may become obsolete simultaneously with their approval.

The concept of a software life cycle model.Rapid Application Development Model. See point 5

One of the possible approaches to the development of application software within the framework of the spiral life cycle model is the widely used method of the so-called rapid application development, or RAD (Rapid Application Development). RAD has three components:

small groups of developers (3-7 people) performing work on the design of individual software subsystems. This is due to the requirement of maximum controllability of the team;

short but carefully worked out production schedule (up to 3 months);

an iterative cycle in which developers, as the application begins to take shape, request and implement in the product the requirements received as a result of interaction with the customer.

The development team should be a group of professionals experienced in software design, programming and testing, able to communicate well with the end user and transform their suggestions into working prototypes.

There are the following stages of the RAD development process :

business modeling . Information flows between business functions are modeled.

Data Modeling . Information flow mapped to a set of data objects.

Machining simulation . Transformations of data objects are defined that provide the implementation of business functions.

Application generation . 4th generation programming languages, ready-made components, are used to construct the automation utility.

Testing and merging . The use of reusable components reduces testing time.

Each main function is developed by a separate group of developers in parallel for no more than 3 months, and then they are integrated into the whole system.

Application Disadvantages RAD :

Large projects require significant human resources to create teams.

The model is applicable only for those systems that can be decomposed into separate modules and in which performance is not a critical value.

Not applicable in conditions of high technical risks, i.e. when using new technology.

The concept of a software life cycle model. V-shaped software life cycle model.

The V-shape lifecycle model was created to help the project team plan ahead so that they can test the system. In this model, special importance is attached to the activities aimed at verification and validation of the product. It demonstrates that product testing is discussed, designed, and planned early in the development lifecycle.

A customer acceptance test plan is developed during the planning phase, and a system assembly test plan is developed during the analysis, design development, etc. phases. This test plan development process is indicated by the dotted line between the V-model boxes.

The V-shaped model was developed as a variation of the waterfall model, which means that it inherited the same sequential structure from it. Each subsequent phase begins upon completion of obtaining the resultant data of the previous phase.

Model demonstrates A complex approach to the definition of the phases of the software development process. It highlights the relationships that exist between the analytical phases and the design phases that precede coding, followed by the testing phases. Dotted lines mean that these phases should be considered in parallel.

Rice. . V-model of the life cycle

Given below short description each phase of the V-model, from project planning and requirements to acceptance testing:

project and requirements planning - system requirements are determined, as well as how the resources of the organization will be allocated in order to meet the set requirements (if necessary, the definition of functions for hardware and software is performed at this phase);

analysis of product requirements and specifications – analysis of the currently existing problem with the software, ends with a complete specification of the expected external line of behavior of the software system being created;

architecture or design at the highest level – determines how the functions of the software should be applied in the implementation of the project;

detailed project development – defines and documents the algorithms for each component that was defined during the architecture phase. These algorithms will later be converted into code;

code development – the transformation of the algorithms defined at the detailed design stage into the finished software is performed;

unit testing – each encoded module is checked for errors;

integration and testing – establishment of relationships between groups of modules previously tested element by element in order to confirm that these groups work as well as modules tested independently from each other at the stage of element testing;

system and acceptance testing – the functioning of the software system as a whole (fully integrated system) is checked after being placed in its hardware environment in accordance with the software requirements specification;

production, operation and maintenance - the software is launched into production. This phase also includes modernization and amendments;

acceptance tests (not shown in the figure) - allows the user to test the functionality of the system for compliance with the initial requirements. After final testing, the software and surrounding hardware become operational. After that, the maintenance of the system is provided.

advantages:

in the model, special importance is attached to planning aimed at verifying and certifying the product being developed at the early stages of its development. The unit testing phase validates the detailed design. The integration and testing phases implement the architectural design or top-level design. The system testing phase confirms that the requirements phase for the product and its specification has been correctly completed;

the model provides for certification and verification of all external and internal data received, and not just the software product itself;

in the V-shaped model, requirements definition is done before system design is developed, and software design is done before component development;

the model defines the products to be obtained as a result of the development process, and each received data must be tested;

thanks to the model, project managers can track the progress of the development process, since in this case it is quite possible to use the timeline, and the completion of each phase is a milestone;

the model is easy to use (relative to the project for which it is acceptable).

limitations:

it is not easy to deal with parallel events with its help;

it does not take into account iterations between phases;

the model does not provide for the introduction of the requirement of dynamic changes at different stages of the life cycle;

testing of requirements in the life cycle occurs too late, as a result of which it is impossible to make changes without affecting the project schedule;

the model does not include activities aimed at risk analysis.

To overcome these shortcomings, the V-shaped model can be modified to include iterative loops designed to resolve changes in requirements beyond the analysis phase.

Like its predecessor, the waterfall model, the V-shaped model works best when all information about the requirements is available in advance. A common modification of the V-shaped model to overcome its shortcomings involves introducing iterative loops to resolve changes in requirements beyond the analysis phase.

The use of the model is effective in the case when information about the method of implementing the solution and technology are available, and the staff has the necessary skills and experience in working with this technology.

The V-pattern is an excellent choice for systems that require high reliability, such as applications for monitoring patients in clinics, as well as embedded software for emergency airbag control devices in cars.

The concept of a software life cycle model. Boehm's spiral model of the software life cycle.

spiral model - a classic example of the application of an evolutionary design strategy. The Spiral Model (Barry Boehm, 1988) builds on the best features of the classic life cycle and layout, to which a new element, risk analysis, is added, which was not previously available.

As shown in fig. 3, the model defines four activities represented by the four quadrants of the spiral:

Planning - defining goals, options and constraints.

Risk analysis - analysis of options and risk recognition/selection.

Engineering - next level product development.

Evaluation - evaluation by the customer of the current design results.

The integrating aspect of the spiral model is evident when considering the radial dimension of the spiral. With each iteration along the spiral (moving from the center to the periphery), more and more full versions ON.

Management Process configuration includes the administrative and technical procedures throughout the software life cycle to determine the status of software components, describe and report on the status of software components and requests for modifications, ensure the completeness, compatibility and correctness of software components, manage storage and delivery of software.

According to the IEEE-90 standard, the software configuration is understood as the totality of its functional and physical characteristics established in the technical documentation and implemented in the software. Configuration Management allows you to organize, systematically take into account and control changes to the software at all stages of the life cycle. General principles and recommendations for software configuration management are reflected in the ISO / IEC 15288 standard "Information Technology. Software Life Cycle Process. Configuration Management for Software".

Management Process configuration includes the following:

1. the preparatory work of planning configuration management;
2. configuration identification, which establishes rules by which software components and their versions are uniquely identified. At the same time, a set of documentation uniquely corresponds to each component;
3. configuration control - an action designed to systematically evaluate proposed software modifications and coordinate their implementation, taking into account the effectiveness of each modification and the cost of its implementation;
4. accounting for the state of the configuration, which is the registration of the state of software components. Provides reporting on implemented and rejected modifications of software component versions. A set of reports provides an unambiguous reflection of the current state of the system and its components, and also provides a history of modifications;
5. configuration evaluation, which consists in determining functional completeness software components, as well as compliance of their physical condition with the current technical description;
6. release management and delivery, covering the production of master copies of programs and documentation, their storage and delivery to users in accordance with the procedure adopted by the organization.

Provision process quality assurance should provide assurance that the software and its life cycle processes comply with specified requirements and approved plans. Software quality is understood as a set of properties that characterizes the ability of software to meet specified requirements. To obtain reliable estimates about the software being created the process of ensuring its quality should occur independently of the subjects directly associated with the development of the software product. The results of other supporting processes, such as verification, attestation, participatory assessment, audit, and problem resolution, may be used.

Provision process quality includes the following:

1. preparatory work (coordination with other supporting processes and planning of the software quality assurance process itself, taking into account the standards, methods, procedures and tools used);
2. ensuring the quality of the product, which implies the guaranteed full compliance of the software and its documentation with the requirements of the customer provided for in the contract;
3. ensuring the quality of the process, which implies the guaranteed compliance of the software life cycle processes, development methods, development environment and personnel qualifications with the terms of the contract, established standards and procedures;
4. ensuring other software quality indicators, carried out in accordance with the terms of the contract and the ISO 9001 quality standard.

The verification process consists in determining that the software, which is the result of some activity, fully satisfies the requirements or conditions due to previous activities. To improve the efficiency of the entire software life cycle process, verification should be integrated as early as possible with the processes that use it (i.e. with delivery, development, operation). The verification process may include review, evaluation, and testing.

Verification can be carried out with various degrees of independence (from the contractor himself to specialists from another organization independent of the supplier, developer, etc.). During the verification process, the following conditions are checked:

1. consistency of requirements for the system and the degree to which user needs are taken into account;
2. the supplier's ability to meet specified requirements;
3. compliance of the selected software life cycle processes with the terms of the contract;
4. the adequacy of standards, procedures and development environment for software life cycle processes;
5. compliance of software design specifications with specified requirements;
6. the correctness of the description in the design specifications of the input and output data, the sequence of events, interfaces, logic, etc.;
7. compliance of the code with design specifications and requirements;
8. testability and correctness of the code, its compliance with accepted coding standards;
9. correct integration of software components into the system;
10. the adequacy, completeness and consistency of the documentation.

The certification process is designed to determine the completeness of compliance with the specified requirements and the created software for their specific functional purpose (what the consumer needs). Attestation is usually understood as confirmation and assessment of the reliability of the testing of a software product. Qualification should ensure that the software fully complies with the specifications, requirements, and documentation, and that the user can use the software safely and securely.

Attestation, like verification, can be carried out with varying degrees of independence (up to an organization that is independent of the supplier, developer, operator or maintenance service).

The joint evaluation process is designed to assess the status of work on the project and the software product created during the execution of these works. It focuses primarily on the planning and management of project resources, personnel, equipment, and tools.

The evaluation is applied both at the level of project management and at the level of technical implementation of the project and is carried out during the entire term of the contract. This process can be performed by two parties involved in the contract, with one party checking the other.

The audit process is a determination of the conformity of the project and product with the requirements, plans and terms of the contract. An audit can be performed by any two parties involved in the contract, with one party checking the other.

An audit is an audit (verification) carried out by a competent authority (person) in order to provide an independent assessment of the degree of compliance of software or processes with established requirements.

The audit serves to establish the conformity of the actual works and reports with the requirements, plans and contract. Auditors should not be directly dependent on software developers. They determine the state of work, the use of resources, the compliance of documentation with specifications and standards, the correctness of testing, etc.

The problem resolution process involves the analysis and resolution of problems (including detected nonconformities) that are found during development, operation or other processes, regardless of their origin or source.

5.4. Organizational processes of software life cycle

Management Process consists of activities and tasks that can be performed by any party managing their own processes. This side(manager) is responsible for managing the release of the product,

The structure of the software life cycle in accordance with the ISO/IEC 12207 standard is based on three groups of processes (Fig. 1):

the main processes of the software life cycle (acquisition, supply, development, operation, maintenance);

auxiliary processes that ensure the implementation of the main processes (documentation, configuration management, quality assurance, verification, certification, assessment, audit, problem solving);

organizational processes (project management, creation of project infrastructure, definition, evaluation and improvement of the life cycle itself, training).

Rice. 1. Software life cycle processes.

Acquisition process(acquisition process). It consists of actions

and tasks of the customer purchasing the software. This process covers the following steps:

1) acquisition initiation;

2) preparation of application proposals;

3) preparation and adjustment of the contract;

4) supervision of the activities of the supplier;

5) acceptance and completion of work.

Delivery process(supply process). It covers the activities and tasks performed by a vendor that provides a customer with a software product or service. This process includes the following steps:

1) initiation of delivery;

2) preparing a response to bids;

3) preparation of the contract;

4) planning;

5) implementation and control;

6) verification and evaluation;

7) delivery and completion of works.

Development process(development process). It provides for the actions and tasks performed by the developer and covers the creation of software and its components in accordance with the specified requirements, including the preparation of design and operational documentation, the preparation of materials necessary to test the operability and appropriate quality of software products, materials necessary for organizing training personnel, etc.

The development process includes the following steps:

1) analysis of system requirements;

2) system architecture design;

3) analysis of software requirements;

4) software architecture design;

5) detailed software design;

6) software coding and testing;

7) software integration;

8) software qualification testing;

9) system integration;

10) qualification testing of the system;

11) software installation;

12) software acceptance.

Operating process(operation process). It covers the activities and tasks of the operator - the organization operating the system. This process includes the following steps:

1) operational testing;

2) operation of the system;

3) user support.

Maintenance process(maintenance process). It provides for the activities and tasks performed by the accompanying organization (support service). This process is activated in case of changes (modifications) of the software product and related documentation caused by problems that have arisen or the need to upgrade or adapt the software. According to the IEEE-90 standard, maintenance refers to making changes to software to fix bugs, improve performance, or adapt to changing operating conditions or

requirements. Changes to existing software must not violate

its integrity. The maintenance process includes the transfer of software to another environment (migration) and ends with the decommissioning of the software.

The maintenance process covers the following steps:

1) analysis of problems and requests for software modification;

2) software modification;

3) verification and acceptance;

4) software transfer to another environment;

5) software decommissioning.

The group of auxiliary processes includes:

Documentation;

Configuration management; quality assurance;

Verification; attestation;

Joint evaluation;

Problem resolution.

Documentation process(documentation process). It provides a formalized description of the information created during the software life cycle. The documentation process includes the following steps:

1) design and development;

2) release of documentation;

3) maintenance of documentation.

Configuration management process(configuration management process). It involves the application of administrative and technical procedures throughout the software life cycle to determine the status of software components in the system, manage software modifications, describe and report on the status of software components and requests for modifications, ensure the completeness, compatibility and correctness of software components, manage storage and delivery ON. According to the IEEE-90 standard, software configuration is understood as the totality of its functional and physical characteristics.

characteristics established in the technical documentation and implemented in the software.

Configuration management allows you to organize, systematically take into account and control changes to the software at all stages of the life cycle. General principles and recommendations for software configuration management are reflected in the draft standard ISO/I EC CD 12207-2: 1995 "Information Technology - Software Life Cycle Processes. Part 2.

Configuration Management for Software". The configuration management process includes the following steps:

1) configuration identification;

2) configuration control;

3) taking into account the state of the configuration;

4) evaluation of the configuration;

5) release management and delivery.

Quality Assurance Process(quality assurance process). It provides appropriate assurance that the software and its life cycle processes comply with specified requirements and approved plans. Software quality is understood as a set of properties that characterize the ability of software to meet specified requirements. To obtain reliable estimates of the software being created, the process of ensuring its quality should occur independently of the subjects directly related to software development. The results of other supporting processes, such as verification, attestation, participatory assessment, audit, and problem resolution, may be used. The quality assurance process includes the following activities:

1) product quality assurance;

2) process quality assurance;

3) ensuring other indicators of the quality of the system.

Verification process(verification process). It consists in determining that software products, which are the results of some action, fully satisfy the requirements or conditions stipulated by previous actions (verification in the narrow sense means a formal proof of software correctness).

Attestation process(validation process). It provides for the determination of the completeness of the compliance of the specified requirements and the created system or software product with their specific functional purpose. Certification is usually understood as confirmation and assessment of the reliability of software testing.

Joint assessment process(joint review process). It is designed to assess the status of work on the project and the software created during the performance of these works (actions). It focuses primarily on the planning and management of project resources, personnel, equipment, and tools.

Audit Process(audit process). It is a determination of compliance with the requirements, plans and conditions of the contract.

Problem resolution process(problem resolution process). It provides for the analysis and resolution of problems (including detected nonconformities), regardless of their origin or source, that are discovered during development, operation, maintenance or other processes. Each problem found must be identified, described, analyzed and resolved.

The group of organizational processes of the software life cycle includes:

Control;

Creation of infrastructure;

improvement;

Release of new versions;

Education.

Management Process(management process). It consists of activities and tasks that can be performed by any party managing their own processes. This party (manager) is responsible for product release management, project management and task management of related processes such as acquisition, supply, development, operation, maintenance, etc.

Infrastructure process(infrastructure process). It covers the selection and support (maintenance) of technology, standards and tools, the selection and installation of hardware and software used to develop, operate or maintain software. The infrastructure must be modified and maintained in accordance with changes in the requirements for the corresponding processes. Infrastructure, in turn, is one of the objects of configuration management.

Improvement process(improvement process). It provides for the evaluation, measurement, control and improvement of software life cycle processes. Improvement of software life cycle processes is aimed at increasing the productivity of all specialists involved in them by improving the technology used, management methods, choice of tools and training

personnel.

Learning process(training process). It covers initial training and subsequent continuing education of staff.