Software life cycle: concept, standards, processes. Software life cycle. Stages and stages of the life cycle of a software development project

Life cycle software(Software) - a period of time that begins from the moment a decision is made on the need to create a software product and ends at the time of its complete withdrawal from service. This cycle is the process of building and developing software.

Life cycle stages:

2. Design

3. Implementation

4. Assembly, testing, testing

5. Implementation (release)

6. Escort

There are 2 cases of software production: 1) Software is made for a specific customer. In this case, you need to turn the applied task into a programmer one. You need to understand how the environment that needs to be automated (business process analysis) functions. As a result, a documentation-specification of the requirement appears, where exactly which tasks should be indicated. resolved and under what conditions. This work is performed by a systems analyst (business process analyst).

2) The software is developed for the market. It is necessary to carry out marketing research and find what product is not on the market. This is associated with great risk. The goal is to develop a requirements specification.

Design

Purpose - Definition overall structure(architecture) software. The result is a software specification. The system programmer does this job.

Implementation

Writing program code. Implementation includes development, testing, and documentation.

Assembly, testing, testing

Assembling everything that has been done by different programmers. Testing of the entire software package. Debugging - finding and eliminating the causes of errors. Test - refinement technical characteristics... As a result, the program is guaranteed to work.

Implementation (release)

Implementation - when they work for one customer. It includes setting up the program at the customer's place, training the customer, consulting, eliminating errors and obvious shortcomings. The software should be alienated - the user can work with the software without the participation of the author.

Release - when the software is developed for the market. It starts with the beta testing phase. Corresponding version - beta version. Alpha testing is testing by people from the same organization who were not involved in the development of the programs. Beta testing - making several copies of the software and sending it to potential customers. The goal is to double-check the software development.

If a fundamentally new software is released to the market, then several beta tests are possible. After beta testing - release of the commercial version.

Escort

Elimination of errors noticed during operation. Making minor improvements. Accumulation of proposals for the development of the next version.

Life Cycle Models

1. Waterfall ("waterfall", cascade model)

2. Prototyping

First, not the software product itself is developed, but its prototype, which contains the solution to the main problems facing the developers. After the successful completion of the prototype development, the real software product is developed according to the same principles. The prototype allows you to better understand the requirements for the developed program. Using the prototype, the customer can also formulate their requirements more precisely. The developer has the opportunity to present the preliminary results of his work to the customer using a prototype.

3. Iterative model

The task is divided into subtasks and the order of their implementation is determined, so that each subsequent subtask expands the capabilities of the software. Success essentially depends on how well tasks are divided into subtasks and how the order is chosen. Advantages: 1) the possibility of active participation of the customer in the development, he has the opportunity to clarify his requirements during the development; 2) the ability to test newly developed parts together with previously developed ones, this will reduce the cost of complex debugging; 3) during development, you can start implementation in parts.

Annotation.

Introduction.

1. Software life cycle

Introduction.

Riley Programming Process Steps

Introduction.

1.1.1. Formulation of the problem.

1.1.2. Solution design.

1.1.3. Algorithm coding.

1.1.4. Maintenance of the program.

1.1.5. Software documentation.

Conclusion to clause 1.1

1.2. Definition of life-cycle production according to Lehman.

Introduction.

1.2.1 System definition.

1.2.2. Implementation.

1.2.3. Service.

Conclusion to clause 1.2.

1.3. Phases and work of ZHCPO according to Boehm

1.3.1. Waterfall model.

1.3.2. Economic justification cascade model.

1.3.3. Improvement of the waterfall model.

1.3.4. Determination of the phases of the life cycle.

1.3.5. Basic work on the project.

Literature.

Introduction

The industrial use of computers and the growing demand for software have set the urgent tasks of a significant increase in software development productivity, the development of industrial methods for planning and designing programs, the transfer of organizational and technical, technical, economic and socio-psychological techniques, patterns and methods from the sphere of material production to the sphere of using computers. A complex approach to the processes of development, operation and maintenance of software has put forward a number of pressing problems, the solution of which will eliminate "bottlenecks" in the design of programs, reduce the time of completion of work, improve the selection and adaptation of existing programs, and perhaps determine the fate of systems with embedded computers.

In the practice of developing large software projects, there is often no uniform approach to the assessment of labor costs, timing of work and material costs, which hinders the increase in software development productivity, and ultimately - efficient management life cycle of software. Since a program of any type becomes a product (except, perhaps, educational, model programs), the approach to its production should be in many respects similar to the approach to the production of industrial products, and the issues of designing programs become extremely important. This idea is at the heart of B.W. Boehm's "Software Engineering", which we used in writing this term paper... In this book, software design refers to the process of creating a software product design.

1 Software life cycle

INTRODUCTION

Life cycle program is a continuous process that begins from the moment a decision is made on the need to create software and ends at the moment of its complete withdrawal from service.

There are several approaches to defining the phases and activities of the software life cycle (LCP), steps of the programming process, waterfall and spiral models. But they all contain common fundamental components: problem statement, solution design, implementation, maintenance.

The most well-known and complete, perhaps, is the structure of the life-cycle center according to Boehm, which includes eight phases. She will be presented in the future in more detail.

One of the possible options is the description of the upper level according to Lehmann, which includes three main phases and presents a description of the life cycle of life in the most general case.

And, for a change, - we present the steps of the programming process presented by D. Riley in the book "Using the Module-2 language". This idea, in my opinion, is very simple and familiar, and let's start with it.

1.1 Steps in the Riley Programming Process

Introduction

The programming process includes four steps (Fig. 1):

problem statement, i.e. getting an adequate idea of what task the program should perform;

designing a solution to an already posed problem (in general, such a solution is less formal than the final program);

coding the program, i.e. translating the designed solution into a program that can be executed on the machine;

maintenance of the program, i.e. an ongoing process of troubleshooting problems in the program and adding new features.

Rice. 1.Four steps of programming.

Programming starts from the moment when user, i.e. someone who needs a program to solve a problem presents the problem system analyst. The user and the systems analyst jointly define the problem statement. The latter is then transmitted algorithmist who is responsible for designing the solution. A solution (or algorithm) represents a sequence of operations, the execution of which leads to a solution to a problem. Since the algorithm is often not machine-readable, it should be translated into a machine program. This operation is performed by the encoder. The maintainer is responsible for subsequent changes in the program. programmer. A systems analyst, an algorithmist, an encoder, and an accompanying programmer are all programmers.

In the case of a large software project, the number of users, system analysts and algorithms can be significant. In addition, it may be necessary to return to the previous steps due to unforeseen circumstances. All of this adds to the argument for careful software design: the results of each step must be complete, accurate, and understandable.

1.1.1 Problem statement

One of the most important steps in programming is problem statement. It serves as a contract between the user and the programmer (s). Like a legally badly written contract, bad problem statement is useless. With a good formulation of the task, both the user and the programmer clearly and unambiguously represent the task that needs to be performed, i.e. in this case, the interests of both the user and the programmer are taken into account. The user can plan to use software that has not yet been created, based on the knowledge that it can. A good formulation of the problem serves as the basis for the formation of its solution.

Formulation of the problem (program specification); essentially means an accurate, complete, and understandable description of what happens when a particular program is executed. The user usually looks at the computer as if it were a black box: it doesn't matter to him how the computer works, but what matters is what the computer can do that interests the user. In this case, the main focus is on the interaction of a person with a machine.

Characteristics of a Good Task Statement:

Accuracy, i.e. elimination of any ambiguity. There should be no question as to what the output of the program will be for any given input.

Completeness, i.e. considering all options for a given input, including erroneous or unintended input, and determining the appropriate output.

Clarity, i.e. it should be clear to both the user and the systems analyst, since the statement of the problem is the only contract between them.

Demands for accuracy, completeness and clarity are often in conflict. Thus, many legal documents are difficult to understand because they are written in a formal language that allows you to formulate certain provisions extremely accurately, excluding any minor discrepancies. For example, some of the questions on exam tickets are sometimes so precise that the student spends more time understanding the question than answering it. Moreover, the student may not grasp the main meaning of the question at all due to the large number of details. The best formulation of the problem is the one that achieves a balance of all three requirements.

The standard form of the problem statement.

Consider the following problem statement: "Enter three numbers and output the numbers in order."

This formulation does not satisfy the above requirements: it is neither exact, nor complete, nor understandable. Indeed, should the numbers be entered one per line or all numbers on one line? Does the expression "in order" mean the ordering from highest to lowest, lowest to highest, or the same order in which they were introduced.

Obviously, such a formulation does not answer many questions. If we take into account the answers to all the questions, then the statement of the problem will become wordy and difficult to understand. Therefore, D. Riley suggests using a standard form for setting the problem, which provides maximum accuracy, completeness, clarity and includes:

task name (schematic definition);

general description(summary of the problem);

errors (unusual input options are explicitly listed to show users and programmers what the machine will take in such situations);

example ( good example can convey the essence of the problem, and also illustrate various cases).

Example. Statement of the problem in a standard form.

TITLE

Sorting three integers.

DESCRIPTION

Input and output three integers, sorted from lowest to highest.

Three integers are entered, one number per line. In this case, an integer is one or more consecutive decimal digits, which may be preceded by a plus sign "+" or a minus sign "-".

The three entered integers are displayed, with all three displayed on the same line. Separate adjacent numbers with a space. The numbers are displayed from lowest to highest, from left to right.

1) If less than three numbers are entered, the program waits for additional input.

2) Input lines other than the first three are ignored.

3) If any of the first three lines contains more than one integer, then the program exits and displays a message.

Annotation.

Introduction.

1. Software life cycle

Introduction.

Riley Programming Process Steps

Introduction.

1.1.1. Formulation of the problem.

1.1.2. Solution design.

1.1.3. Algorithm coding.

1.1.4. Maintenance of the program.

1.1.5. Software documentation.

Conclusion to clause 1.1

1.2. Definition of life-cycle production according to Lehman.

Introduction.

1.2.1 System definition.

1.2.2. Implementation.

1.2.3. Service.

Conclusion to clause 1.2.

1.3. Phases and work of ZHCPO according to Boehm

1.3.1. Waterfall model.

1.3.2. The economic rationale for the waterfall model.

1.3.3. Improvement of the waterfall model.

1.3.4. Determination of the phases of the life cycle.

1.3.5. Basic work on the project.

Literature.

Introduction

In the practice of developing large software projects, there is often no uniform approach to the estimation of labor costs, timing of work and material costs, which restrains the increase in software development productivity, and ultimately - effective management of the software life cycle. Since a program of any type becomes a product (except, perhaps, educational, model programs), the approach to its production should be in many respects similar to the approach to the production of industrial products, and the issues of designing programs become extremely important. This idea is at the heart of B.W. Boehm's "Software Engineering", which we used in writing this term paper. In this book, software design refers to the process of creating a software product design.

1 Software life cycle

INTRODUCTION

Life cycle program is an ongoing process 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 most famous and complete, perhaps, is the structure of the life-cycle center according to Boehm, which includes eight phases. She will be presented in the future in more detail.

One of the possible options is the description of the upper level according to Lehmann, which includes three main phases and presents a description of the life cycle of life in the most general case.

1.1 Steps in the Riley Programming Process

The programming process includes four steps (Fig. 1):

problem statement, i.e. getting an adequate idea of what task the program should perform;

designing a solution to an already posed problem (in general, such a solution is less formal than the final program);

coding the program, i.e. translating the designed solution into a program that can be executed on the machine;

maintenance of the program, i.e. an ongoing process of troubleshooting problems in the program and adding new features.

Rice. 1.Four steps of programming.

Programming starts from the moment when user, i.e. someone who needs a program to solve a problem presents the problem system analyst. The user and the systems analyst jointly define the problem statement. The latter is then transmitted algorithmist who is responsible for designing the solution. A solution (or algorithm) represents a sequence of operations, the execution of which leads to a solution to a problem. Since the algorithm is often not machine-readable, it should be translated into a machine program. This operation is performed by the encoder. The maintainer is responsible for subsequent changes to the program. A systems analyst, an algorithmist, an encoder, and an accompanying programmer are all programmers.

1.1.1 Problem statement

One of the most important steps in programming is problem definition. It serves as a contract between the user and the programmer (s). Like a legally badly written contract, bad problem statement is useless. With a good formulation of the task, both the user and the programmer clearly and unambiguously represent the task that needs to be performed, i.e. in this case, the interests of both the user and the programmer are taken into account. The user can plan to use software that has not yet been created, based on the knowledge that it can. A good formulation of the problem serves as the basis for the formation of its solution.

Characteristics of a Good Task Statement:

Accuracy, i.e. elimination of any ambiguity. There should be no question as to what the output of the program will be for any given input.

Completeness, i.e. considering all options for a given input, including erroneous or unintended input, and determining the appropriate output.

Clarity, i.e. it should be clear to both the user and the systems analyst, since the statement of the problem is the only contract between them.

Often the requirement for accuracy, completeness and clarity is in conflict. For example, many legal documents are difficult to understand because they are written in a formal language that allows for the most precise formulation of certain provisions, excluding any minor discrepancies. For example, some of the questions on exam tickets are sometimes so precise that the student spends more time understanding the question than answering it. Moreover, the student may not grasp the main meaning of the question at all due to the large number of details. The best formulation of the problem is the one that achieves a balance of all three requirements.

The standard form of the problem statement.

Consider the following problem statement: "Enter three numbers and output the numbers in order."

Obviously, such a formulation does not answer many questions. If we take into account the answers to all the questions, then the statement of the problem will become verbose and difficult to understand. Therefore, D. Riley suggests using a standard form for setting the problem, which provides maximum accuracy, completeness, clarity and includes:

task name (schematic definition);

general description (brief statement of the problem);

errors (unusual input options are explicitly listed to show users and programmers what the machine will take in such situations);

example (a good example can convey the essence of the problem, and also illustrate various cases).

Example. Statement of the problem in a standard form.

TITLE

Sorting three integers.

DESCRIPTION

Input and output three integers, sorted from lowest to highest.

Three integers are entered, one number per line. In this case, an integer is one or more consecutive decimal digits, which can be preceded by a plus sign "+" or a minus sign "-".

The three entered integers are displayed, with all three displayed on the same line. Separate adjacent numbers with a space. The numbers are displayed from lowest to highest, from left to right.

1) If less than three numbers are entered, the program waits for additional input.

Topic: Classic and Flexible Lifecycle Models: Definition, Description, distinctive features, sequence of stages. Methods for choosing a life cycle model in software development in various subject areas.

Information source https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297

Models and stages of software lifecycle

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

ISO / IEC 12207 does not provide a specific lifecycle model and software development methods. Its provisions are common to any life cycle models, methods and technologies of software development. The standard describes the structure of software life cycle processes, but does not specify how to implement or perform the actions and tasks included in these processes.

The life cycle model of any specific software determines the nature of the process of its creation, which is a set of work ordered in time, interconnected and united in stages (phases) of work, the implementation of which is necessary and sufficient to create software that meets the specified requirements.

The stage (phase) of software creation is understood as a part of the software creation process, limited by some time frame and ending with the release of a specific product (software models, software components, documentation, etc.), determined by the requirements specified for this stage. The stages of software development are distinguished for reasons of rational planning and organization of work, ending with the specified results. The life cycle of software usually includes the following stages:

formation of software requirements;
design (development of a system project);
implementation (can be broken down into sub-stages: detailed design, coding);
testing (can be split into standalone and complex testing and integration);
commissioning (implementation);
operation and maintenance;
decommissioning.

Some experts introduce an additional initial stage - feasibility study systems. This refers to the software and hardware system for which software is created, purchased or modified.

The stage of the formation of software requirements is one of the most important and determines to a large (even decisive!) Degree the success of the entire project. The beginning of this stage is to obtain an approved and validated system architecture with the inclusion of basic agreements on the distribution of functions between hardware and software. This document should also contain confirmation of the general understanding of the functioning of the software, including the basic agreements on the distribution of functions between the person and the system.

The stage of formation of software requirements includes the following stages.

Planning of work prior to work on the project. The main tasks of the stage are the definition of development goals, preliminary economic assessment project, construction of a work schedule, creation and training of a joint working group.
Conducting a survey of the activities of the automated organization (object), within the framework of which the preliminary identification of the requirements for the future system is carried out, the determination of the structure of the organization, the determination of the list of target functions of the organization, the analysis of the distribution of functions by departments and employees, the identification of functional interactions between departments, information flows within and between departments , external in relation to the organization of objects and external information influences, analysis existing funds automation of the organization's activities.

Building a model of the organization's (object) activity, providing for the processing of survey materials and building two types of models:

an "AS-IS" ("as is") model that reflects the current state of affairs in the organization at the time of the survey and allows you to understand how the organization works, as well as identify bottlenecks and formulate proposals for improving the situation;
model "TO-BE" ("how it should be"), reflecting the idea of new technologies of the organization.

Each of the models should include a complete functional and information model of the organization's activities, as well as (if necessary) a model that describes the dynamics of the organization's behavior. Note that the constructed models have an independent practical significance, regardless of whether the enterprise will develop and implement an information system, since they can be used to train employees and improve the business processes of the enterprise.

The result of the completion of the stage of formation of software requirements are software specifications, functional, technical and interface specifications, for which their completeness, testability and feasibility have been confirmed.

The design stage includes the following stages.

Development of a software system project. At this stage, the answer to the question "What should the future system do?" development, software debugging plan and quality control.

The system design is based on the system design models, which are based on the "TO-BE" model. The result of the development of a system project should be an approved and confirmed specification of software requirements: functional, technical and interface specifications, for which their completeness, testability and feasibility have been confirmed.
Development of a detailed (technical) project. At this stage, the actual software design is carried out, including the design of the system architecture and detailed design. Thus, the answer is given to the question: "How to build a system so that it meets the requirements?"

The result of detailed design is the development of a verified software specification, including:

formation of a hierarchy of software components, intermodular interfaces for data and control;
specification of each software component, name, purpose, assumptions, sizes, sequence of calls, input and output data, erroneous outputs, algorithms and logic circuits;
formation of physical and logical structures data to the level of individual fields;
development of a plan for the distribution of computing resources (time of central processors, memory, etc.);
verification of the completeness, consistency, feasibility and validity of requirements;
preliminary integration and debugging plan, user manual and acceptance test plan.

The completion of the detailed design stage is end-to-end project control or critical block analysis of the project.

The stage of implementation is the implementation of the following works.

Development of a verified detailed specification of each subroutine (a block of no more than 100 source commands of the high-level language).

External specifications should contain the following information:
- module name - indicates the name used to call the module (for a module with multiple inputs, there must be separate specifications for each input);
- function - defines the function or functions performed by the module;
- a list of parameters (number and order) passed to the module;
- input parameters - an exact description of all data returned by the module (the behavior of the module must be defined under any input conditions);
- external effects (printing a message, reading a request from the terminal, etc.).
Designing the logic of modules and programming (coding) modules.
Checking the correctness of the modules.
Testing modules.
Description of the database down to the level of individual parameters, symbols and bits.
Acceptance test plan.
User manual.
Preliminary plan for integration and debugging. The content of the subsequent stages basically coincides with the corresponding processes of the life cycle of software. In general, technological stages are distinguished based on considerations of reasonable and rational planning and organization of work. A possible variant of the relationship and stages of work with the life cycle of software is shown in the figure.

Rice. 1.

Types of lifecycle software models

Waterfall model (classic life cycle)

This model owes its appearance to W. Royce (1970). The model has another name - waterfall. The peculiarity of the model is that the transition to the next stage is carried out only after the work at the previous stage has been completely completed; refunds to the passed stages are not provided.

Rice. 2.

Requirements for the developed software system, determined at the stages of formation and analysis, are strictly documented in the form of technical specifications and are fixed for the entire period of project development. Each stage ends with the release of a complete set of documentation (TOR, EP, TP, RP), sufficient for the development to be continued by another development team. The criterion for the quality of development with this approach is the accuracy of the implementation of the specifications of the TK. The main attention of developers is focused on achieving the optimal values of the technical characteristics of the developed software system - performance, the amount of memory occupied, etc.

Advantages cascade model:

at each stage, a complete set of project documentation is formed that meets the criteria for completeness and consistency;
the stages of work carried out in a logical sequence allow you to plan the timing of completion of all work and the corresponding costs.

The waterfall approach has proven itself well when building a software system, for which at the very beginning of the project it is possible to fully and clearly formulate all the requirements. As long as all this is controlled by standards and various state acceptance commissions, the scheme works well.

disadvantages cascade model:

identification and elimination of errors is carried out only at the testing stage, which can be significantly extended;
real projects often require deviations from the standard sequence of steps;
the cycle is based on the exact formulation of the initial requirements for the PS, in fact, at the beginning of the project, the customer's requirements are only partially determined;
the results of the work are available to the customer only after the completion of the project.

Iterative model of life cycle of PS

With the growth of commercial projects, it became clear that it is not always possible to work out in detail the project of the future system, since many aspects of its functioning in dynamic areas of activity (business) change while the system is being created. It was necessary to change the development process to ensure that the necessary fixes were made after the completion of any development stage. This is how the iterative model of life cycle PS appeared, called the model with intermediate control or the model with cyclic repetition of phases.

Rice. 3.

In an iterative model, design and programming flaws can be rectified later by partially returning to the previous stage. The lower the error detection rate, the more expensive it is to fix it. If the cost of efforts required to detect and eliminate errors at the stage of writing code is taken as a unit, then the cost of identifying and eliminating an error at the stage of requirements development will be 5-10 times less, and the cost of identifying and eliminating an error at the maintenance stage will be 20 times less. more.

Rice. 4.

In such a situation, the stage of formulating requirements, drawing up specifications and creating a system plan becomes of great importance. Software architects are personally responsible for all subsequent design changes. The volume of documentation is in the thousands of pages, and the number of approving meetings is enormous. Many projects never leave the planning stage, falling into "analysis paralysis." One of the possible ways to avoid such situations is prototyping (prototyping).

Layout

Often the customer cannot formulate the requirements for the input, processing or output of data for the future software product. The developer may have doubts about the suitability of the product for the operating system, in the form of dialogue with the user, or the effectiveness of the algorithm. In such cases, it is advisable to use prototyping. The main purpose of prototyping is to remove uncertainty in customer requirements. Layout (prototyping) is the process of creating a model of the required product.

The model can take the following forms.

Paper mockup (hand-drawn diagram of human-machine dialogue) or PC-based mockup.
A working layout that implements some of the required functionality.
An existing program whose characteristics need to be improved.

As shown in the figure, prototyping is based on repeated iterations between the customer and the developer.

Rice. 5.

The sequence of actions for prototyping is shown in the figure. Prototyping begins with collecting and clarifying the requirements for the software system being created. The developer and the customer jointly define the goals of the software, establish which requirements are known and which have to be further defined. Then a quick design is done. It focuses on the characteristics that should be visible to the user. Rapid design leads to building a layout. The layout is evaluated by the customer and is used to clarify the software requirements. Iterations continue until the layout identifies all the customer's requirements and allows the developer to understand what needs to be done.

The virtues of prototyping are the ability to ensure that complete system requirements are defined. Disadvantages of layout:

the customer can take the layout for the product;
a developer can mistake a layout for a product.

The essence of the shortcomings should be clarified. When the customer sees a working version of the PS, he ceases to realize that in the pursuit of a working version of the PS, many quality issues are left unresolved and ease of maintenance systems. When the developer tells the customer about this, the answer may be indignation and the demand for the fastest transformation of the layout into a working product. This negatively affects the management of software development.

Rice. 6.

On the other hand, in order to get a working layout quickly, the developer often makes certain trade-offs. For example, the wrong programming language or operating system might be used. For a simple demonstration, an ineffective (simple) algorithm can be used. After a while, the developer forgets about the reasons why these tools are not suitable. As a result, a far from ideal chosen option is integrated into the system.

Before considering other lifecycle software models that have replaced cascade model, we should focus on the design strategies software systems... It is the software design strategy that largely determines the software lifecycle model.

Software design strategies

There are three strategies for designing software systems:

single pass (cascade strategy, discussed above) - a linear sequence of design steps;
incremental strategy. At the beginning of the process, all user and system requirements are determined, the rest of the design is done as a sequence of versions. The first version implements some of the planned features, the next version implements additional features, and so on, until the complete system is received;
evolutionary strategy. The system is also built in a series of versions, but not all requirements are identified at the beginning of the process. Requirements are refined as a result of version development. The characteristics of software design strategies in accordance with the requirements of the IEEE / EIA 12207 standard are shown in Table 1.

Incremental model

The incremental model is a classic example of an incremental design strategy. It combines elements of a sequential waterfall model with an iterative philosophy of prototyping (proposed by B. Boehm as an improvement cascade model). Each linear sequence here generates a supplied software increment. For example, software for processing words in the 1st increment (version) implements the functions of basic file processing, editing and documentation functions; in the 2nd increment - more complex editing and documentation options; in the 3rd increment - spelling and grammar check; in 4th increment - page layout capabilities.

The first increment results in a base product that implements the basic requirements (although many ancillary requirements remain unfulfilled). The next increment plan includes modifications to the base product to provide additional features and functionality.

An incremental process is inherently iterative, but unlike prototyping, an incremental model provides a working product at each increment.

The diagram of such a model of the life cycle of software is shown in the figure. One of the modern implementations of the incremental approach is extreme programming (focused on very small increments of functionality).

Rice. 7.

Spiral model of life cycle software

Spiral model Is a classic example of an evolutionary design strategy. The model (by B. Boehm, 1988) is based on the best properties of the classical life cycle and prototyping, to which a new element is added - risk analysis, which is absent in these paradigms. The model defines four actions, represented by the four quadrants of the spiral.

Rice. eight.

Planning - defining goals, options and constraints.
Risk analysis - analysis of options and risk recognition / selection.
Engineering is the next level of product development.
Evaluation - the customer's evaluation of the current design results.

The integrating aspect spiral model obvious when considering the radial dimension of the spiral. With each iteration, more and more complete versions of the PS are built in a spiral. In the first turn of the spiral, initial goals, options and constraints are identified, and risk is recognized and analyzed. If the risk analysis reveals the ambiguity of the requirements, the prototyping used in the design quadrant comes to the rescue of the developer and the customer.

Modeling can be used to further identify problematic and refined requirements. The customer evaluates the engineering (design) work and makes proposals for modifications (quadrant of the customer's assessment). The next phase of planning and risk analysis is based on the customer's suggestions. In each cycle in a spiral, the results of the risk analysis are formed in the form "continue, do not continue". If the risk is too great, the project can be stopped.

In most cases, the spiral continues, with each step moving developers towards a more general model of the system. Each spiral cycle requires a design (lower right quadrant) that can be accomplished by the classic lifecycle or prototyping. Note that the number of development activities (occurring in the lower right quadrant) increases as you move from the center of the spiral.

These actions are numbered and have the following content:

- initial collection of requirements and project planning;
- the same work, but based on the customer's recommendations;
- risk analysis based on initial requirements;
- risk analysis based on the customer's reaction;
- transition to an integrated system;
- initial layout of the system;
- the next level of the layout;
- designed system;
- evaluation by the customer.

Dignity spiral model:

most realistically (in the form of evolution) reflects the development of software;
allows you to explicitly take into account the risk at each stage of the development evolution;
includes a systematic approach step in an iterative development structure;
uses simulation to reduce risk and improve software product.

disadvantages spiral model:

comparative novelty (there is no sufficient statistics on the effectiveness of the model);
increased requirements for the customer;
difficulties in control and management of development time.

The spiral development process model is currently the most common. The most famous variants are RUP (Rational Unified Process) from Rational and MSF (Microsoft Solution Framework). UML (Unified Modeling Language) is used as the modeling language. The creation of the system is supposed to be carried out iteratively, moving in a spiral and, going through the same stages, to refine the characteristics of the future product at each loop. It would seem that now everything is fine: only what can be foreseen is planned, what is planned is being developed, and users begin to get acquainted with the product in advance, having the opportunity to make the necessary adjustments.

However, this requires very large funds. Indeed, if earlier it was possible to create and disband teams of specialists as needed, now they all have to constantly participate in the project: architects, programmers, testers, instructors, etc. Moreover, the efforts of different groups must be synchronized in order to timely reflect design solutions and make the necessary changes.

Rational unified process

Rational unified process(Rational Unified Process, RUP) is one of the best software development methodologies. Based on the experience of many successful software projects, RUP allows you to create complex software systems based on industrial development methods. The prerequisites for the development of RUP began in the early 1980s. at Rational Software corporation. In early 2003, Rational acquired IBM. One of the main pillars of RUP is the process of creating models using the Unified Modeling Language (UML).

RUP is one of the spiral software development methodologies. The methodology is supported and developed by Rational Software. The Unified Modeling Language (UML) is used as the modeling language in the general knowledge base. Iterative and incremental software development in RUP involves dividing a project into several projects that are executed sequentially, and each iteration of development is clearly defined by a set of goals to be achieved at the end of the iteration. Final iteration assumes that the set of goals for the iteration must exactly match the set of goals specified by the customer of the product, that is, all requirements must be met.

The process involves the evolution of models; the iteration of the development cycle is uniquely associated with a specific version of the software model. Each of the iterations contains controls software lifecycle: analysis and design (modeling), implementation, integration, testing, implementation. In this sense, RUP is an implementation spiral model, although it is often depicted in the form of a graph-table ..

This figure presents two dimensions: the horizontal axis represents time and shows the temporal aspects of the process life cycle; the vertical axis represents the disciplines that define the physical structure of the process. You can see how the accents in the project change over time. For example, in early iterations, more time is devoted to requirements; in later iterations, more time is devoted to implementation. The horizontal axis is formed from time intervals - iterations, each of which is an independent development cycle; the goal of the cycle is to bring some predefined tangible refinement to the end product that is useful from a stakeholder point of view.

Rice. nine.

The life cycle is divided into four main phases along the time axis.

Inception - the formation of a project concept, understanding of what we are creating, a vision of a product, development of a business plan (business case), preparation of a program prototype or partial solution. This is the phase of collecting information and analyzing requirements, defining the image of the project as a whole. The goal is to get support and funding. In the final iteration, the result of this stage is the terms of reference.
Design, development (Elaboration) - clarifying the plan, understanding how we create it, designing, planning the necessary actions and resources, detailing the features. The stage ends with the executable architecture, when all architectural decisions are made and the risks are taken into account. An executable architecture is a running software that demonstrates the implementation of basic architectural solutions. In the final iteration, this is - technical project.
Implementation, creation of the system (Construction) - the stage of expanding the functionality of the system, embedded in the architecture. In the final iteration, this is a working draft.
Implementation, deployment (Transition). Creation of the final version of the product. Product implementation phase, product delivery to a specific user (replication, delivery and training).

The vertical axis consists of disciplines, each of them can be described in more detail in terms of the tasks performed, the roles responsible for them, the products that are submitted to tasks as input and are released during their execution, etc.

Along this axis are the key disciplines of the RUP life cycle, which are often called processes in Russian, although this is not entirely true from the point of view of this methodology, supported by IBM (and / or third-party) tools.

Business analysis and modeling (Business modeling) provides the implementation of modeling principles in order to study the business of an organization and accumulate knowledge about it, optimize business processes and decide on their partial or complete automation.
Requirements management is about obtaining information from stakeholders and transforming it into a set of requirements that define the content of the system being developed and detail the expectations of what the system should do.
Analysis and design covers the procedures for transforming requirements into intermediate descriptions (models) that represent how those requirements should be implemented.
Implementation covers the development of code, testing at the developer level, and the integration of components, subsystems, and the entire system in accordance with established specifications.
Testing (Test) is devoted to assessing the quality of the product being created.
Deployment covers the operations that take place when products are transferred to customers and when the product is made available to end users.
Configuration management is all about synchronizing middleware and end products and managing their development throughout the project and finding hidden issues.
Project Management (Management) is dedicated to project planning, risk management, monitoring its progress and continuous assessment of key indicators.
Environment management (Environment) includes elements of the formation of an information system development environment and support for project activities.

Depending on the specifics of the project, any IBM Rational or third-party tools can be used. The RUP recommends six practices for successful project development: iterative development; requirements management; use of modular architectures; visual modeling; quality checking; tracking changes.

An integral part of the RUP is made up of artefacts, precedents, and roles. Artifacts are some of the products of a project that are generated or used in the work on the final product. Use cases are sequences of actions performed by the system to produce an observable result. In fact, any result of the work of an individual or group is an artifact, be it an analysis document, a model element, a code file, a test script, a description of an error, etc. Certain specialists are responsible for the creation of this or that type of artifacts. Thus, the RUP clearly defines the responsibilities - roles - of each member of the development team at one stage or another, that is, when and who should create this or that artifact. The entire process of developing a software system is considered in RUP as a process of creating artifacts - from the initial analysis documents to executable modules, user manuals, etc.

For computer support of RUP processes, IBM has developed a wide set of tools:

Rational Rose - CASE- visual simulator information systems, which has the ability to generate code elements. A special edition of the product - Rational Rose RealTime - allows you to get an executable module at the output;
Rational Requisite Pro - a requirements management tool that allows you to create, structure, prioritize, track, control requirements changes that occur at any stage of the development of application components;
Rational ClearQuest is a product for change management and tracking of defects in a project (bug tracking), tightly integrated with testing and requirements management tools and providing a single environment for linking all errors and documents to each other;
Rational SoDA is a product for the automatic generation of project documentation that allows you to set the corporate standard for internal documents. It is also possible to bring documentation to existing standards (ISO, CMM);
Rational Purify, Rational Quantify Rational PureCoverage - testing and debugging tools;
Rational Visual Quantify is a performance measurement tool for application and component developers who program in C / C ++, Visual Basic, and Java; helps to identify and eliminate bottlenecks in software performance;
Rational Visual PureCoverage - Automatically identifies areas of code that are not being tested.
Rational ClearCase is a software configuration management (SCM) product that allows version control of all project documents. It allows you to maintain multiple versions of projects at the same time, quickly switching between them. Rational Requisite Pro supports updates and tracks changes in the requirements for the development team;
SQA TeamTest - Tool test automation;
Rational TestManager is a test management system that brings together all test-related tools, artifacts, scripts, and data;
Rational Robot is a tool for creating, modifying and automatically running tests;
SiteLoad, SiteCheck - tools for testing web sites for performance and broken links;
Rational PerformanceStudio - Measure and predict system performance characteristics.

This set of products is constantly being improved and replenished. For example, the recent product, IBM Rational Software Architect (RSA), is part of the IBM Software Development Platform, a set of tools that support the software development lifecycle. The IBM Rational Software Architect product is intended for building models of developed software systems using the unified modeling language UML 2.0, primarily models of the architecture of the developed application. However, RSA integrates the functions of software products such as Rational Application Developer, Rational Web Developer, and Rational Software Modeler, thereby enabling architects and analysts to create different views of the information system under development using UML 2.0, and enable developers to perform development. J2EE, XML, web services, etc.

Following the principles of RUP, Rational Software Architect allows you to create the required models within the workflows of disciplines such as:

business analysis and modeling (Business modeling);
requirements management (Requirements);
analysis and design (Analysis and Design);
implementation

In addition, Rational Software Architect supports model-driven development (MDD) technology, which allows software to be modeled on different levels abstractions with traceability.

MSF (Microsoft Solution Framework)

In 1994, in an effort to maximize the impact of IT projects, Microsoft released a set of guidelines for the effective design, development, implementation and maintenance of solutions built on the basis of its technologies. This knowledge is based on the experience gained by Microsoft while working on large projects for the development and maintenance of software, the experience of Microsoft consultants and the best that the IT industry has accumulated to date. All of this is presented in the form of two interrelated and well-complementary knowledge areas: Microsoft Solutions Framework (MSF) and Microsoft Operations Framework (MOF).

It should be noted that Microsoft has developed methodologies based on general MSF methods for applied and specialized use. Moreover, Microsoft certifies experts specifically in applied knowledge in the application of MSF (for example, certification MCTS 74-131 for expertise in project management techniques). Before learning MSF techniques, you should first determine which MSF application you are referring to.

The most popular MSF applications developed by Microsoft are:

methodology for implementing solutions in the field of project management;
methodology for managing IT projects based on MSF and Agile methodologies.

The importance of MSF applications is underscored by the fact that Microsoft does not use the MSF methodology itself in its IT projects in a "pure version". Microsoft Consulting Services projects use a hybrid MSF and Agile methodology. Despite the external significant differences in the applied versions of MSF, developed by Microsoft experts, the base of MSF methods for them remains common and reflects the general methodological approaches to iterative project management.

MOF aims to provide organizations building mission-critical IT solutions based on Microsoft products and technologies with technical guidance on how to achieve their reliability, availability, ease of maintenance(supportability) and manageability (manageability). MOF addresses issues related to the organization of people and processes; technology and management in complex, distributed and heterogeneous IT environments. MOF is based on the best manufacturing practices compiled in the IT Infrastructure Library (ITIL) compiled by the Central Computer and Telecommunications Agency - UK government agency.

Building a business solution within the allotted time and budget requires a proven methodological framework. MSF offers proven methodologies for planning, designing, developing and implementing successful IT solutions. Thanks to its flexibility, scalability and lack of rigid regulations, MSF is able to meet the needs of an organization or project team of any size. The MSF methodology consists of principles, models and disciplines for managing people, processes, technology elements, and related issues that are common to most projects. MSF consists of two models and three disciplines. These are detailed in 5 whitepapers. It is better to start studying MSF with models (project team model, process model), and then move on to disciplines (project management discipline, risk management discipline, training management discipline).

The MSF process model provides a general methodology for the development and implementation of IT solutions. The peculiarity of this model is that due to its flexibility and the absence of rigidly imposed procedures, it can be applied in the development of a very wide range of IT projects. This model combines the properties of two standard production models: waterfall and spiral. The process model in MSF 3.0 has been supplemented with another innovative aspect: it covers the entire life cycle of creating a solution, from its starting point to the actual implementation. This approach helps design teams to focus on the business value of the solution, as this return becomes real only after the product is deployed and used.

The MSF process is focused on "milestones" - the key points of the project that characterize the achievement within its framework of any significant (intermediate or final) result. This result can be evaluated and analyzed, which implies answering the questions: "Has the project team come to an unambiguous understanding of the goals and scope of the project?", "Is the action plan ready enough?" Does the solution meet the needs of the customer? " etc.

The MSF Process Model accommodates constant changes in design requirements. It assumes that the development of a solution should consist of short cycles that create a progressive movement from the simplest versions of the solution to its final form.

The features of the MSF Process Model are:

a phase and milestone approach;
iterative approach;
an integrated approach to the creation and implementation of solutions.

The process model includes such main phases of the development process as:

concept development (Envisioning);
planning (Planning);
development (Developing);
stabilization;
deployment (Deploying).

In addition, there are a large number of milestones that show some progress in the project and break down large segments of work into smaller, visible areas. For each phase of the process model, MSF defines:

what (what artifacts) is the result of this phase;
what each of the role clusters is working on in this phase.

Within MSF, code, documentation, designs, plans, and other work materials are usually created in an iterative manner. MSF recommends that you begin your solution development by building, testing, and implementing basic functionality. Then more and more features are added to the solution. This strategy is referred to as a versioning strategy. While a single version release may be sufficient for small projects, it is recommended that you do not miss the opportunity to create multiple versions for one solution. With the creation of new versions, the functionality of the solution evolves.

An iterative approach to the development process requires a flexible way of maintaining documentation. Living documents must change as the project evolves along with changes in the requirements for the final product. MSF offers a number of standard document templates that are artifacts of each stage of product development and can be used to plan and control the development process.

The solution has no business value until it is implemented. It is for this reason that the MSF Process Model contains the entire lifecycle of a solution, including its implementation, right up to the point where the solution starts to pay off.

The concept of software life cycle (software life cycle) is one of the basic concepts in software engineering. Life cycle is defined as the 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.

In accordance with the ISO / IEC 12207 standard, all life cycle processes are divided into three groups (Fig. 2.1).

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

1. Formation of software requirements.

2. Design.

3. Implementation.

4. Testing.

5. Commissioning.

6. Operation and maintenance.

7. Decommissioning.

Currently, the following basic models of software lifecycle are most widely used:

a) cascading and

b) spiral (evolutionary).

The first was used for small programs that are a single whole. The principal feature waterfall approach is that the transition to the next stage is carried out only after the work on the current one is completely completed, and there are no returns to the passed stages. Its diagram is shown in Fig. 2.2.

The advantages of using the waterfall model are as follows:

At each stage, a complete set of project documentation is formed;

The stages of work carried out allow you to plan the date of their completion and the corresponding costs.

This model is used for systems for which all requirements can be accurately formulated at the beginning of development. These include, for example, systems in which, mainly, problems of a computational type are solved. Real processes are usually iterative in nature: the results of the next stage often cause changes in design solutions developed at earlier stages. Thus, the more common model is with intermediate control, which is shown in Fig. 2.3.

The main disadvantage of the cascade approach is a significant delay in obtaining results and, as a consequence, a rather high risk of creating a system that does not meet the changed needs of users.

These problems are resolved in spiral life cycle model (fig. 2.4). Its fundamental feature is that the application software is not created immediately, as in the case of the waterfall approach, but in parts using the method prototyping ... A prototype is understood as an active software component that implements individual functions and an external interface of the software being developed. Prototyping is carried out in several iterations - turns of the spiral.

The waterfall (evolutionary) model can be represented in the form of a diagram, which is shown in Figure 2.5.

One of the results of the application of the spiral life cycle model is the widely used method of the so-called rapid application development , or RAD (Rapid Application Development). According to this method, the software life cycle includes four stages:

1) analysis and planning of requirements;

2) design;

3) implementation;

4) implementation.

Analysis of the life cycle of programs allows you to clarify the content and highlight the following processes for the design of complex systems.

1) Strategy;

2) Analysis;

3) Design;

4) Implementation;

5) Testing;

6) Implementation;

7) Operation and technical support.

Strategy

Defining a strategy involves examining the system. The main task of the survey is to assess the real scope of the project, its goals and objectives, as well as to obtain definitions of entities and functions at a high level. At this stage, highly qualified business analysts are involved, who have constant access to the firm's management. In addition, close interaction with the main users of the system and business experts is expected. The main task of such interaction is to obtain as complete information about the system as possible, to unambiguously understand the customer's requirements and to transmit the information received in a formalized form to system analysts. Typically, information about the system can be obtained from a series of conversations (or seminars) with management, experts and users.

The result of the strategy definition stage is a document in which the following is clearly formulated:

What exactly is due to the customer if he agrees to finance the project;

When will he be able to receive the finished product (work schedule);

How much will it cost him (schedule of financing stages of work for large projects).

The document should reflect not only costs, but also benefits, for example, the payback period of the project, the expected economic effect (if it can be estimated).

The considered stage of the software life cycle can be represented in the model only once, especially if the model has a cyclical structure. This does not mean that in cyclic models strategic planning produced once and for all. In such models, the stages of defining strategy and analysis are, as it were, combined, and their separation exists only at the very first stage, when the management of the enterprise accepts principled decision about the start of the project. In general, the strategic stage is devoted to the development of a document at the level of enterprise management.

The analysis stage involves a detailed study of business processes (functions defined in the previous stage) and the information required for their implementation (entities, their attributes and relationships (relationships)). This stage provides the information model, and the next design stage is the data model.

All information about the system, collected at the stage of determining the strategy, is formalized and refined at the stage of analysis. Particular attention is paid to the completeness of the information received, its analysis for consistency, as well as the search for unused or duplicated information. As a rule, the customer first forms requirements not for the system as a whole, but for its individual components. And in this particular case, cyclical models of the software life cycle have the advantage, since over time it will most likely require reanalysis, since the customer's appetite often comes with eating. At the same stage, the necessary components of the test plan are determined.

Analysts collect and record information in two interrelated forms:

a) functions - information about events and processes that occur in the business;

b) entities - information about items that are relevant to the organization and about which something is known.

At the same time, diagrams of components, data flows and life cycles are built, which describe the dynamics of the system. They will be discussed later.

Design

At the design stage, a data model is formed. Designers process analysis data. The end product of the design phase is a database schema (if one exists in the project) or a data warehouse schema (ER model) and a set of system module specifications (function model).

In a small project (for example, in a course project), the same people can act as analysts, designers, and developers. The schemes and models listed above help to find, for example, not described at all, vaguely described, contradictory described system components and other shortcomings, which helps to prevent potential errors.

All specifications must be very accurate. The system test plan is also being finalized at this stage of development. In many projects, the results of the design phase are documented in a single document - the so-called technical specification. At the same time, the UML language has gained widespread use, which allows you to simultaneously obtain both analysis documents that are less detailed (their consumers are production managers) and design documents (their consumers are managers of development and test groups). This language will be discussed later. Software built using UML makes it easier to generate code - at least the class hierarchy, as well as some parts of the code of the methods (procedures and functions) themselves.

The design tasks are:

Consideration of the analysis results and verification of their completeness;

Seminars with a customer;

Identification of critical areas of the project and assessment of its limitations;

Determination of the system architecture;

Making a decision on the use of third-party products, as well as on the methods of integration and mechanisms for exchanging information with these products;

Data warehouse design: database model;

Process and code design: final selection of development tools, definition of program interfaces, mapping of system functions to its modules and definition of module specifications;

Determination of requirements for the testing process;

Determination of system security requirements.

Implementation

When implementing a project, it is especially important to coordinate the development team (s). All developers must obey strict source control guidelines. Having received a technical project, they begin to write module code. The main task of developers is to understand the specification: the designer wrote what needs to be done, and the developer determines how to do it.

During the development phase, there is close interaction between designers, developers and testing teams. In the case of intensive development, the tester is literally inseparable from the developer, effectively becoming a member of the development team.

Most often, user interfaces change during the development phase. This is due to the periodic demonstration of the modules to the customer. It can also significantly modify data queries.

The development phase is associated with the testing phase, and both processes run in parallel. The bug tracking system synchronizes the actions of testers and developers.

Errors should be classified according to priority. For each class of errors, a clear structure of actions should be defined: “what to do”, “how urgent”, “who is responsible for the result”. Each issue should be tracked by a designer / developer / tester responsible for fixing it. The same applies to situations when the planned terms of development and submission of modules for testing are violated.

In addition, repositories of ready-made project modules and libraries that are used when assembling modules should be organized. This repository is constantly being updated. One person should oversee the update process. One repository is created for modules that have passed functional testing, the second is for modules that have passed link testing. The first is drafts, the second is something from which it is already possible to assemble the distribution kit of the system and demonstrate it to the customer for control tests or for the delivery of any stages of work.

Testing

Test teams can be involved in collaboration early on in the development of a project. Usually, complex testing is separated into a separate development stage. Depending on the complexity of the project, testing and fixing errors can take a third, half of the total project time, or even more.

The more complex the project, the greater the need to automate the bug tracking system, which provides the following functions:

Storing the error message (which component of the system the error belongs to, who found it, how to reproduce it, who is responsible for fixing it, when it should be fixed);

The system of notification about the appearance of new errors, about changes in the status of errors known in the system (notifications by e-mail);

Reports on actual errors by system components;

Information about the error and its history;

Rules for accessing errors of certain categories;

Bug tracking system limited access interface for the end user.

Such systems take on many organizational problems, in particular the issues of automatic error notification.

The actual system tests are usually divided into several categories:

a) offline tests modules; they are used already at the stage of development of system components and allow you to track the errors of individual components;

b) link tests system components; these tests are also used at the development stage, they allow you to track the correct interaction and exchange of information between system components;

c) system test; it is the main criterion for the acceptance of the system; Typically, this is a group of tests that includes both standalone tests and linkage tests and models; such a test should reproduce the operation of all components and functions of the system; its main goal is the internal acceptance of the system and the assessment of its quality;

d) acceptance test; its main purpose is to hand over the system to the customer;

e) performance and load tests; this group of tests is included in the system, it is she who is the main one for assessing the reliability of the system.

Each group necessarily includes tests for modeling failures. They check the response of a component, a group of components, and the system as a whole to the following failures:

A separate component of the information system;

Groups of system components;

The main modules of the system;

Operating system;

Hard failure (power failure, hard drives).

These tests make it possible to assess the quality of the subsystem for restoring the correct state of the information system and serve as the main source of information for developing strategies to prevent the negative consequences of failures during industrial operation.

Another important aspect of the information systems testing program is the availability of test data generators. They are used to test the functionality, reliability and performance of the system. It is impossible to solve the problem of assessing the characteristics of the dependence of the performance of an information system on the growth of volumes of processed information without data generators.

Implementation

Trial operation overlaps the testing process. The system is rarely fully implemented. Typically, this is a gradual or iterative process (in the case of a cyclical life cycle).

Commissioning goes through at least three stages:

2) accumulation of information;

3) reaching the design capacity (that is, the actual transition to the operational stage).

information can cause a rather narrow range of errors: mainly, data mismatch during loading and bootloader's own errors. To identify and eliminate them, data quality control methods are used. Such errors must be corrected as soon as possible.

During the period accumulation of information v information system the largest number of errors associated with multiuser access is detected. The second category of fixes is related to the fact that the user is not satisfied with the interface. At the same time, cyclical and feedback models of stages can reduce costs. This stage is also the most serious test - the customer acceptance tests.

The system reaches its design capacity in a good version, it is fine-tuning of minor errors and rare serious errors.

Operation and technical support

At this stage, the final document for developers is the technical acceptance act. The document defines the necessary personnel and required equipment to support the system's operability, as well as the conditions for disrupting the operation of the product and the responsibilities of the parties. In addition, the terms of technical support are usually drawn up as a separate document.