Software life cycle. Software life cycle Stages of the software life cycle

We should start by definingSoftware life cycle(Software Life Cycle Model) is a period of time that starts from the moment a decision is made to create a software product and ends at the moment it is completely withdrawn from service. This cycle is the process of building and developing software.

Software Life Cycle Models

The life cycle can be represented in the form of models. Currently the most common are:cascading, incremental (staged model with intermediate control ) and spirallife cycle models.

Cascade model

Cascade model(eng. waterfall model) is a model of the software development process, the life cycle of which looks like a flow that sequentially passes through the phases of requirements analysis, design. implementation, testing, integration and support.

The development process is implemented using an ordered sequence of independent steps. The model provides that each subsequent step begins after the completion of the previous step. At all steps of the model, auxiliary and organizational processes and work are performed, including project management, assessment and quality management, verification and certification, configuration management, and documentation development. As a result of the completion of steps, intermediate products are formed that cannot be changed in subsequent steps.

The life cycle is traditionally divided into the following mainstages:

1. Requirements analysis,
2. Design,
3. Coding (programming),
4. Testing and debugging,
5. Operation and maintenance.

Advantages of the model:

• stability of requirements throughout the development life cycle;
• at each stage, a complete set of project documentation is formed that meets the criteria for completeness and consistency;
• the certainty and comprehensibility of the steps of the model and the simplicity of its application;
• the stages of work performed in a logical sequence allow you to plan the timing of the completion of all work and the corresponding resources (monetary, material and human).

Disadvantages of the model:

• the complexity of clearly formulating requirements and the impossibility of their dynamic change during the full life cycle;
• low flexibility in project management;
• subsequence linear structure development process, as a result of returning to previous steps to solve emerging problems leads to an increase in costs and disruption of the work schedule;
• unsuitability of the intermediate product for use;
• impossibility of flexible modeling of unique systems;
• late detection of build-related problems due to the simultaneous integration of all results at the end of development;
• insufficient user participation in the creation of the system - at the very beginning (during the development of requirements) and at the end (during acceptance tests);
• users cannot be convinced of the quality of the developed product until the end of the entire development process. They do not have the opportunity to evaluate the quality, because they cannot see the finished product of development;
• the user does not have the opportunity to gradually get used to the system. The learning process occurs at the end of the life cycle, when the software has already been put into operation;
• each phase is a prerequisite for the execution of subsequent actions, which makes such a method a risky choice for systems that have no analogues, because. it does not lend itself to flexible modeling.

It is difficult to implement the Waterfall Life Cycle Model due to the complexity of developing PS without returning to previous steps and changing their results to eliminate emerging problems.

Scope of the Cascade Model

The limitation of the scope of the cascade model is determined by its shortcomings. Its use is most effective in the following cases:

1. when developing projects with clear, unchangeablelife cycle requirements understandable by implementation and technical methodologies;
2. when developing a project focused on building a system or product of the same type as previously developed by developers;
3. when developing a project related to the creation and release of a new version of an existing product or system;
4. when developing a project related to the transfer of an existing product or system to a new platform;
5. when performing large projects involving several large development teams.

incremental model

(staged model with intermediate control)

incremental model(eng. increment- increase, increment) implies the development of software with a linear sequence of stages, but in several increments (versions), i.e. with planned product improvements for as long as the Software Development Life Cycle comes to an end.

Software development is carried out in iterations with feedback loops between stages. Inter-stage adjustments make it possible to take into account the actual mutual influence of the development results at various stages, the lifetime of each of the stages is extended over the entire development period.

At the beginning of work on the project, all the basic requirements for the system are determined, divided into more and less important ones. After that, the development of the system is carried out on an incremental basis, so that the developer can use the data obtained during the development of the software. Each increment should add certain functionality to the system. In this case, the release starts with the components with the highest priority. When the parts of the system are defined, take the first part and start detailing it using the most appropriate process for this. At the same time, it is possible to refine the requirements for other parts that have been frozen in the current set of requirements of this work. If necessary, you can return to this part later. If the part is ready, it is delivered to the client, who can use it in his work. This will allow the customer to clarify the requirements for the following components. Then they develop the next part of the system. The key steps in this process are simply implementing a subset of software requirements and refining the model over a series of successive releases until the entire software is implemented.

The life cycle of this model is typical for the development of complex and complex systems for which there is a clear vision (both on the part of the customer and the developer) of what the final result should be. Version development is carried out for various reasons:

• the lack of the customer's ability to immediately finance the entire expensive project;
• the lack of the necessary resources for the developer to implement a complex project in a short time;
• requirements for the phased implementation and development of the product by end users. The introduction of the entire system at once can cause rejection among its users and only “slow down” the process of transition to new technologies. Figuratively speaking, they can simply “not digest a large piece, so it must be crushed and given in parts.”

Advantages and limitationsof this model (strategy) are the same as those of the cascade (classical life cycle model). But unlike the classical strategy, the customer can see the results earlier. Based on the results of the development and implementation of the first version, he may slightly change the requirements for development, abandon it, or offer the development of a more advanced product with the conclusion of a new contract.

Advantages:

• costs incurred due to changing user requirements are reduced, re-analysis and documentation collection are significantly reduced compared to the waterfall model;
• it is easier to get feedback from the client about the work done - clients can voice their comments on finished parts and can see what has already been done. Because the first parts of the system are the prototype of the system as a whole.
• the customer has the ability to quickly acquire and master the software - customers can get real benefits from the system sooner than would be possible with the waterfall model.

Disadvantages of the model:

• managers must constantly measure the progress of the process. in the case of rapid development, it is not worth creating documents for every minimal version change;
• the structure of the system tends to deteriorate when new components are added - constant changes disrupt the structure of the system. To avoid this, additional time and money are required for refactoring. Poor structure makes software difficult and costly to modify later. And the interrupted Software Life Cycle leads to even greater losses.

The scheme does not allow promptly taking into account emerging changes and clarifications of software requirements. Coordination of development results with users is carried out only at the points planned after the completion of each stage of work, and General requirements to the software are fixed in the form of technical specifications for the entire time of its creation. Thus, users often receive software that does not meet their real needs.

spiral model

Spiral model:Life cycle - at each turn of the spiral, the next version of the product is created, the requirements of the project are specified, its quality is determined, and the work of the next turn is planned. Particular attention is paid to the initial stages of development - analysis and design, where the feasibility of certain technical solutions is tested and justified through the creation of prototypes.

This model is a software development process that combines both design and staged prototyping to combine the benefits of bottom-up and top-down concepts, emphasizing the initial stages of the life cycle: analysis and design.Distinctive feature This model is a special attention to the risks affecting the organization of the life cycle.

At the stages of analysis and design, the feasibility of technical solutions and the degree of satisfaction of customer needs is checked by creating prototypes. Each turn of the spiral corresponds to the creation of a workable fragment or version of the system. This allows you to clarify the requirements, goals and characteristics of the project, determine the quality of development, and plan the work of the next turn of the spiral. Thus, the details of the project are deepened and consistently concretized, and as a result, a reasonable option is selected that meets the actual requirements of the customer and is brought to implementation.

Life cycle on each turn of the spiral - different models of the software development process can be applied. The end result is a finished product. The model combines the capabilities of a prototyping model andwaterfall model. Development by iterations reflects the objectively existing spiral cycle of system creation. Incomplete completion of work at each stage allows you to move on to the next stage without waiting for the complete completion of work on the current one. The main task is to show users of the system a workable product as soon as possible, thereby activating the process of clarifying and supplementing requirements.

Advantages of the model:

• allows you to quickly show users of the system a workable product, thereby activating the process of clarifying and supplementing requirements;
• allows changes in requirements during software development, which is typical for most developments, including standard ones;
• the model provides for the possibility of flexible design, since it embodies the advantages of the cascade model, and at the same time iterations over all phases of the same model are allowed;
• allows you to get a more reliable and stable system. As software evolves, bugs and weaknesses are found and fixed at each iteration;
• this model allows users to actively participate in planning, risk analysis, development, as well as in the performance of evaluation activities;
• reduce customer risk. The customer can, with a minimum for himself financial losses complete the development of an unpromising project;
• feedback from users to developers is performed at high frequency and early in the model, which ensures that the desired product is of high quality.

Disadvantages of the model:

• if the project is low risk or small, the model can be expensive. Risk assessment after each spiral is expensive;
• The life cycle of the model has a complicated structure, so its application by developers, managers and customers can be difficult;
• the spiral can continue indefinitely, since each customer's response to the created version can generate a new cycle, which delays the completion of the project;
• a large number of intermediate cycles may lead to the need to process additional documentation;
• the use of the model can be costly and even unaffordable, because time. spending on planning, re-targeting, performing risk analysis and prototyping may be excessive;
• it may be difficult to define goals and milestones indicating readiness to continue the development process at the next and

The main problem of the spiral cycle is determining the moment of transition to the next stage. To solve it, time limits are introduced for each of the stages.life cycle and the transition proceeds according to plan, even if not all planned work is completed.Planningproduced on the basis of statistical data obtained in previous projects and personal experience developers.

Scope of the spiral model

The use of the spiral model is advisable in the following cases:

• when developing projects using new technologies;
• when developing a new series of products or systems;
• when developing projects with expected significant changes or additions to requirements;
• for the implementation of long-term projects;
• when developing projects that require demonstration of the quality and versions of a system or product over a short period of time;
• when developing projects. for which it is necessary to calculate the costs associated with the assessment and resolution of risks.

Software life cycle. Stages and stages

The IS life cycle is a series of events that occur with the system in the process of its creation and use.

Stage- a part of the software creation process, limited by a certain time frame and ending with the release of a specific product (models, software components, documentation), determined by the requirements specified for this stage.

The life cycle is traditionally modeled as a number of successive stages (or stages, phases). Currently, there is no generally accepted division of the life cycle software system into stages. Sometimes a stage is singled out as a separate item, sometimes it is included as an integral part of a larger stage. The actions performed at one stage or another may vary. There is no uniformity in the names of these stages.

Traditionally, the following main stages of the software life cycle are distinguished:

Requirements analysis,

Design,

Coding (programming),

Testing and debugging,

Operation and maintenance.

Software life cycle. Cascade model

cascade model (70-80s) ≈ assumes the transition to the next stage after the completion of work on the previous stage,

The main achievement of the waterfall model is the completeness of the stages. This enables cost and time planning. In addition, project documentation is formed, which has completeness and consistency.

The waterfall model is applicable to small software projects with well-defined and unchanging requirements. The real process can reveal failures at any stage, which leads to a rollback to one of the previous stages. The model of such software production is cascade-return

Software life cycle. Staged model with intermediate control

staged model with intermediate control (80-85) ≈ iterative software development model with feedback loops between stages. The advantage of this model is that inter-stage adjustments are less labor intensive than the waterfall model; however, the lifetime of each of the stages is stretched over the entire development period,

Main stages of problem solving

The purpose of programming is to describe data processing processes (hereinafter referred to as simply processes).

Data (data) is the presentation of facts and ideas in a formalized form suitable for transfer and processing in some process, and information (information) is the meaning that is given to data when they are presented.

Data processing is the execution of a systematic sequence of actions on data. Data are presented and stored on data carriers.

The set of data carriers used in any data processing is called the information medium (data medium).

The set of data contained at any time in the information environment is the state of the information environment.

A process can be defined as a sequence of successive states of some information environment.

To describe the process means to determine the sequence of states of the information environment. In order for the required process to be generated automatically on some computer according to a given description, this description must be formalized.

Software quality criteria

A commercial product (product, service) must meet the requirements of the consumer.

Quality is an objective characteristic of a product (product, service), showing the degree of consumer satisfaction

Quality characteristics:

› performance- the system works and implements the required functions.

› Reliability– the system works without failures and failures.

› Recoverability.

› Efficiency- the system performs its functions in the best possible way.

› Economic efficiency- the minimum cost of the final product with the maximum profit.

Quality characteristics:

› Accounting for the human factor- ease of use, speed of learning to work with software, ease of maintenance, making changes.

› Portability(mobility) - portability of code to another platform or system.

› Functional completeness– perhaps the most complete implementation of external functions.

› Calculation accuracy

Algorithm properties.

Efficiency means the possibility of obtaining a result after performing a finite number of operations.

Certainty consists in the coincidence of the results obtained, regardless of the user and the applied technical means.

mass character lies in the possibility of applying the algorithm to a whole class of tasks of the same type, differing in specific values ​​of the initial data.

discreteness - the possibility of dividing the process of calculations prescribed by the algorithm into separate stages, the possibility of highlighting sections of the program with a certain structure.

Ways to describe algorithms

There are the following ways of describing (representing) algorithms:

1. verbal description;

2. description of the algorithm using mathematical formulas;

3. graphical description of the algorithm in the form of a block diagram;

4. description of the algorithm using pseudocode;

5. a combined method of depicting an algorithm using verbal, graphic, and other methods .

6. using Petri nets.

Verbal description algorithm is a description of the structure of the algorithm in natural language. For example, for devices household appliances, as a rule, an instruction manual is attached, i.e. a verbal description of the algorithm in accordance with which this device should be used.

Graphic descriptionalgorithm in the form of a flowchart is a description of the structure of the algorithm using geometric shapes with communication lines.

The block diagram of an algorithm is a graphical representation of a method for solving a problem, which uses special characters to display operations.

The symbols that make up the block diagram of the algorithm are defined by GOST 19.701-90. This GOST corresponds international standard design of algorithms, therefore, flowcharts of algorithms, designed in accordance with GOST 19.701-90, are understood unambiguously in different countries.

Pseudocode– description of the structure of the algorithm in a natural, but partially formalized language. Pseudocode uses some formal constructions and common mathematical symbolism. There are no strict syntax rules for writing pseudocode.

Consider the simplest example. Let it be necessary to describe the algorithm for displaying the largest value of two numbers on the monitor screen.

Figure 1 - An example of the description of the algorithm in the form of a block diagram

Description of the same algorithm in pseudocode:

2. Number input: Z, X

3. If Z > X then Conclusion Z

4. Otherwise output X

Each of the above methods of depicting algorithms has both advantages and disadvantages. For example, the verbal method is verbose and lacks clarity, but it makes it possible to better describe individual operations. The graphical method is more visual, but it often becomes necessary to describe some operations in verbal form. Therefore, when developing complex algorithms, it is better to use a combined method.

Types of algorithms

linear;

branching;

cyclic.

· Linear algorithm- a set of commands (instructions) executed sequentially one after another.

· Branching Algorithm- an algorithm containing at least one condition, as a result of checking which the computer provides a transition to one of two possible steps.

· Cyclic algorithm- an algorithm that provides for repeated repetition of the same action (the same operations) on new initial data. Most of the calculation methods and enumeration of options are reduced to cyclic algorithms. Program cycle - a sequence of commands (series, loop body) that can be executed repeatedly (for new initial data) until a certain condition is met.

C. Data types.

A data type is a description of the range of values ​​that a variable of the specified type can take. Each data type is characterized by:
1. the number of bytes occupied (size)
2. the range of values ​​that a variable of this type can take.

All data types can be divided into the following types:
1. simple (scalar) and complex (vector) types;
2. basic (system) and user (defined by the user).
In C language, the basic type system is made up of four data types:
1. symbolic,
2. integer,
3. real single precision,
4. real double precision.

Structure of a C program.

1. Operators of the C++ language

Operators control the execution of a program. The operator set of the C++ language contains all the control constructs of structured programming.
A compound statement is delimited by curly braces. All other statements end with a semicolon.
Empty operator - ;
An empty statement is a statement consisting of only a semicolon. It can appear anywhere in the program where the syntax requires a statement. The execution of an empty statement does not change the state of the program.
Compound operator - (...)
The action of a compound statement is to sequentially execute the statements contained in it, except in cases where any statement explicitly transfers control to another place in the program.
Exception Handling Operator

try(<операторы> }
catch(<объявление исключения>) { <операторы> }
catch(<объявление исключения>) { <операторы> }
...
catch(<объявление исключения>) { <операторы> }

Conditional operator

if (<выражение>) <оператор 1>

switch operator

switch(<выражение>)
( case<константное выражение 1>: <операторы 1>
case<константное выражение 2>: <операторы 2>
...
case<константное выражение N>: <операторы N>
}
The switch statement is designed to select one of several alternative ways of program execution. The evaluation of a switch statement begins with the evaluation of the expression, after which control is transferred to the operator marked with a constant expression equal to the evaluated value of the expression. The switch statement is exited by the break statement. If the value of the expression is not equal to any constant expression, then control is transferred to the operator marked with the default keyword, if any.
Loop statement with precondition

while(<выражение>) <оператор>

Loop statement with postcondition

do<оператор>while<выражение>;
In C++, this operator differs from the classical implementation of a loop with a postcondition in that when the expression is true, the loop continues, rather than exiting the loop.
Step Loop Operator

for([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
The body of the for statement is executed until the conditional expression becomes false (equal to 0). The start expression and increment expression are commonly used to initialize and modify loop parameters and other values. The start expression is evaluated once before the first test of the conditional expression, and the increment expression is evaluated after each execution of the statement. Any of the three loop header expressions, and even all three, can be omitted (just remember to leave the semicolons). If the conditional expression is omitted, then it is considered true, and the loop becomes infinite.
The step-by-step loop operator in the C++ language is a flexible and convenient construction, so the loop operator with the while precondition is used very rarely in the C++ language, because in most cases it is more convenient to use the for statement.
Break operator

break;
The break statement interrupts the execution of while, do, for, and switch statements. It can only be contained in the body of these statements. Control is transferred to the program statement following the interrupted one. If a break statement is written inside nested while, do, for, switch statements, then it only terminates the statement that immediately encloses it.
continuation operator

continue;
The continuation operator transfers control to the next iteration in the while, do, for loop statements. It can only be contained in the body of these statements. In do and while statements, the next iteration begins with the evaluation of the conditional expression. In the for statement, the next iteration starts by evaluating the increment expression, and then the conditional expression is evaluated.
return statement

return[<выражение>];
The return statement terminates the execution of the function that contains it and returns control to the calling function. Control is passed to the point of the calling function

if (boolean expression)

operator;

if (boolean expression)

operator_1;

operator_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

If the value of the logical expression is true, then expression_1 is evaluated, otherwise expression_2 is evaluated.

switch (integer type expression)

case value_1:

sequence_of_operators_1;

case value_2:

sequence_of_operators_2;

case value_n:

sequence_of_operators_n;

default:

sequence_of_operators_n+1;

branch default may not be described. It is executed if none of the above expressions is satisfied.

loop operator.

Turbo C provides the following constructs for programming loops: while, do while and for . Their structure can be described as follows:

Loop with condition check at the top:

Select statement

If the actions to be performed in the program depend on the value of some variable, a select statement can be used. At the same time, in C++, only numeric variables can be used as variables in a select statement. In general, the record of a select statement looks like this:

switch(variable)
{
case value1:
actions1
break;

case value2:
actions2
break;
...

default:
default actions
}

The break keyword must be added to the end of each branch. It stops the execution of the select operation. If you do not write it, after performing actions from one selection branch, the execution of actions from the following branches will continue. However, sometimes such a selection property is useful, for example, if you need to perform the same actions for different values ​​of a variable.

switch(variable)
{
case value1:
case value2:
actions1
break;

case value3:
actions2
break;
...
}

Sample use of select:

int n, x;
...
switch(n)
{
case 0:
break; //if n is 0, then do nothing

case 1:
case 2:
case 3:
x = 3 * n; //if n is equal to 1, 2 or 3, then perform some actions
break;

case 4:
x=n; //if n is equal to 4, then perform other actions
break;

default:
x = 0; //for all other values ​​of n, perform the default actions
}

C.Cycle: loop with parameter

General notation

for (parameter initialization; end condition check; parameter correction) (

block of operations;

for - parametric loop (loop with a fixed number of repetitions). To organize such a cycle, it is necessary to carry out three operations:

§ parameter initialization- assigning an initial value to the cycle parameter;

§ end condition check- comparison of the parameter value with some boundary value;

§ parameter correction- changing the value of the parameter with each passage of the loop body.

These three operations are written in parentheses and separated by a semicolon (;). As a rule, the loop parameter is an integer variable.
Parameter initialization is done only once - when the for loop starts executing. The termination condition is checked before each possible execution of the loop body. When the expression becomes false (equal to zero), the loop ends. The parameter correction is carried out at the end of each execution of the loop body. The parameter can either increase or decrease.

Example

#include
int main() (

for(num = 1; num< 5; num++)

printf("num = %d\n",num);

Si. Loop with precondition

General notation

while(expression) (

block of operations;
}

If the expression is true (not equal to zero), then the block of operations enclosed in curly braces is executed, then the expression is checked again. The sequence of actions, consisting of checking and executing a block of operations, is repeated until the expression becomes false (equal to zero). In this case, the loop is exited and the operation after the loop statement is executed.

Example

intk=5;
int i=1;
intsum=0;
while(i<=k) {

When constructing a while loop, it is necessary to include constructs that change the value of the expression being checked so that in the end it becomes false (equal to zero). Otherwise, the loop will be executed indefinitely (infinite loop), for example

block of operations;
}

while is a loop with a precondition, so it is quite possible that the body of the loop will not be executed even once if, at the time of the first check, the condition under test is false.

Si. Loop with postcondition

Loop with do...while postcondition

General notation

block of operations;

) while(expression);

Loop with postcondition

The do...while loop is a loop with a postcondition, where the truth of the expression is checked after all the operations included in the block delimited by curly braces have been performed. The loop body is executed until the expression becomes false, that is, the loop body with the postcondition is executed even though would once.

It is better to use the do...while loop in those cases when at least one iteration must be performed, or when the initialization of the objects participating in the condition test occurs inside the loop body.

Example. Enter a number from 0 to 10

#include
#include
int main() (

system("chcp 1251");

printf("Enter a number from 0 to 10: ");

scanf("%d", &num);

) while((num< 0) || (num > 10));

printf("You entered the number %d", num);

getchar(); getchar();

Function definition

Consider the definition of a function using the example of the sum function.

In C and C++, functions do not have to be defined until the moment they are used, but they must be declared earlier. But even after all this, in the end, this function must be defined. After that, the prototype of the function and its definition are linked, and this function can be used.

If a function has been previously declared, it must be defined with the same return value and data types, otherwise a new, overloaded function will be created. Note that function parameter names do not have to be the same.

The development of CT is constantly expanding the classes of tasks to be solved related to the processing of information of a different nature.

These are basically three types of information and, accordingly, three classes of tasks for which computers are used:

1) Computational tasks associated with the processing of numerical information. These include, for example, the problem of solving a system of linear equations of high dimension. It used to be the main, dominant area of ​​​​use of computers.

2) Tasks for the processing of symbolic information associated with the creation, editing and transformation of text data. The work of, for example, a secretary-typist is associated with the solution of such problems.

3) Tasks for processing graphic information i.e. diagrams, drawings, graphs, sketches, etc. Such tasks include, for example, the task of developing drawings of new products by a designer.

4) Tasks for processing alphanumeric information - IS. At present, it has become one of the main areas of application of computers and the tasks are becoming more and more complicated.

The computer solution of problems of each class has its own specifics, but it can be divided into several stages that are typical for most problems.

Programming technologystudies technological processes and the order of their passage (stages) using knowledge, methods and means.

Technologies are conveniently characterized in two dimensions - vertical (representing processes) and horizontal (representing stages).

Picture

A process is a set of interrelated actions (technological operations) that transform some input data into output data. Processes consist of a set of actions (technological operations), and each action consists of a set of tasks and methods for solving them. The vertical dimension reflects the static aspects of the processes and operates with such concepts as work processes, actions, tasks, performance results, performers.

A stage is a part of the software development activities, limited by some time frame and ending with the release of a specific product, determined by the requirements set for this stage. Sometimes stages are combined into larger time frames called phases or milestones. So, the horizontal dimension represents time, reflects the dynamic aspects of processes and operates with such concepts as phases, stages, stages, iterations and control points.

Software development follows a specific life cycle.

Life cycle Software is a continuous and ordered set of activities carried out and managed within the framework of each project for the development and operation of software, starting from the moment an idea (concept) for the creation of some software appears and a decision is made on the need to create it, and ends at the moment of its complete withdrawal from exploitation for reasons:

a) obsolescence;

b) loss of the need to solve the corresponding tasks.

Technological approaches are mechanisms for implementing the life cycle.

The technological approach is determined by the specifics of the combination of stages and processes, focused on different classes of software and on the characteristics of the development team.

The life cycle defines the stages (phases, stages) so that the software product moves from one stage to another, from the conception of the product to the stage of its folding.

The life cycle of software development can be presented with varying degrees of detail of the stages. The simplest representation of the life cycle, includes the stages:

Design

Implementation

Testing and Debugging

Implementation, operation and maintenance.

The simplest representation of the life cycle of the program (cascade technology approach to life cycle management):

Processes

Design

Programming

Testing

Escort

Analysis Design Implementation Testing Implementation Operation

and debugging and maintenance

In fact, there is only one process running at each stage. Obviously, when developing and creating large programs, such a scheme is not correct enough (not applicable), but it can be taken as a basis.

Alysis stage focuses on system requirements. Requirements are defined and specified (described). The development and integration of functional models and data models for the system is being carried out. In addition, non-functional and other system requirements are fixed.

The design phase is divided into two main sub-phases: architectural and detailed design. In particular, the program design, user interface and data structures are refined. Design issues that affect the understandability, maintainability, and scalability of the system are raised and fixed.

Implementation phase includes writing a program.

Differences in hardware and software are especially visible at the stage exploitation. If consumer goods go through the stages of launch, growth, maturity and decline, then the life of software is more like the story of an unfinished, but constantly completed and updated building (aircraft) (Subscriber).

The software life cycle is regulated by many standards, including international ones.

The purpose of standardizing the life cycle of complex PS:

Summarizing the experience and research results of many specialists;

Working off technological processes and development techniques, as well as a methodological basis for their automation.

Standards include:

Rules for describing the initial information, methods and methods for performing operations;

Establish process control rules;

Establish requirements for the presentation of results;

Regulate the content of technological and operational documents;

Determine the organizational structure of the development team;

Provide distribution and scheduling of tasks;

Provide control over the progress of the creation of PS.

In Russia, there are standards governing the life cycle:

Software development stages - GOST 19.102-77

Stages of creating AS - GOST 34.601-90;

TK for the creation of AS - GOST 34.602-89;

Types of test AS - GOST 34.603-92;

However, the creation, maintenance and development of application software for IP in these standards are not sufficiently reflected, and some of their provisions are outdated from the point of view of building modern distributed systems of high quality application programs in control and data processing systems with different architectures.

In this regard, it should be noted the international standard ISO / IEC 12207-1999 - “ Information Technology– Software life cycle processes”.

ISO - International Organization of Standardization - international organization for standardization, IEC - International Electrotechnical Commission - International Electrotechnical Commission.

It defines the structure of the software life cycle and its processes.

Those. creating software is not such an easy task, therefore there are standards in which everything is written: what needs to be done, when and how.

The structure of the software life cycle according to the international standard ISO / IEC 12207-95 is based on three groups of processes:

1) the main processes of the software life cycle (acquisition, supply, development, operation, maintenance). We will focus on the latter.

2) auxiliary processes that ensure the implementation of the main processes ( documentation, configuration management, quality assurance, verification, validation, collaborative review (assessment), audit, problem solving).

1. Configuration managementthis is a process that supports the main processes of the software life cycle, primarily the development and maintenance processes. When developing complex software projects consisting of many components, each of which may have varieties or versions, the problem arises of taking into account their relationships and functions, creating a unified (i.e., single) structure and ensuring the development of the entire system. Configuration management allows you to organize, systematically take into account and control changes to various software components at all stages of its life cycle.

2. Verification is the process of determining whether the current state of the software as reached this stage, the requirements of this stage.

3. Certification– confirmation by examination and presentation of objective evidence that the specific requirements for specific objects are fully implemented.

4. Joint analysis (assessment) – systematic determination of the degree of compliance of the object with the established criteria.

5. Audit– verification performed by a competent authority (person) in order to provide an independent assessment of the degree of compliance of software products or processes with established requirements. Examination allows you to evaluate the compliance of development parameters with the initial requirements. Verification overlaps with testing, which is performed to determine the differences between actual and expected results and to assess whether the software characteristics meet the original requirements. In the process of project implementation, issues of identification, description and control of the configuration of individual components and the entire system as a whole occupy an important place.

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

Project management connected with the issues of planning and organizing work, creating teams of developers and monitoring the timing and quality of work performed. The technical and organizational support of the project includes the choice of methods and tools for the implementation of the project, the definition of methods for describing the intermediate states of development, the development of methods and tools for testing the created software, personnel training, etc. Project quality assurance is related to the problems of verification, verification and testing of software components.

We will consider the software life cycle from the developer's point of view.

The development process in accordance with the standard 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, as well as the preparation of materials necessary to check the operability and conformity of the quality of software products , materials needed for staff training, etc.

According to the standard, the IP software life cycle includes the following actions:

1) the emergence and study of the idea (concept);

2) preparatory stage - selection of a life cycle model, standards, methods and development tools, as well as drawing up a work plan.

3) analysis of information system requirements - defining it

functionality, user requirements, requirements for reliability and security, requirements for external interfaces, etc.

4) information system architecture design - determination of composition necessary equipment, software and operations performed by service personnel.

5) software requirements analysis- definition of functionality, including performance characteristics, operating environment of components, external interfaces, reliability and safety specifications, ergonomic requirements, requirements for data usage, installation, acceptance, user documentation, operation and maintenance.

6) software architecture design - defining the structure of the software, documenting the interfaces of its components, developing a preliminary version of user documentation, as well as test requirements and an integration plan.

7) detailed software design - detailed

description of software components and interfaces between them, updating user documentation, developing and documenting test requirements and a test plan, software components, updating the component integration plan.

8) software coding -– development and documentation

each software component;

9)software testing – development of a set of test procedures and data for their testing, testing of components, updating user documentation, updating the software integration plan;

10) software integration–assembly of software components in accordance with

integration plan and testing of software for compliance with qualification requirements, which 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 specified operating conditions;

11) software qualification testing – software testing in

the presence of the customer to demonstrate its compliance

requirements and readiness for operation; at the same time, the readiness and completeness of the technical and user documentation is also checked;

12) system integration – assembly of all components information system, including software and hardware;

13) IP qualification testing – system testing for

compliance with the requirements for it and verification of the design and completeness of the documentation;

14) software installation – installation of software on the customer's equipment and checking its performance;;

15) software acceptance – evaluation of the results of a qualified

software and information system testing in general and

documentation of the evaluation results together with the customer, certification and final transfer of the software to the customer.

16) Management and development of documentation;

17) operation

18) escort - the process of creating and implementing new versions

software product.;

19) completion of operation.

These actions can be grouped, conditionally highlighting the following main stages of software development:

statement of the task (TOR) (according to GOST 19.102-77 stage "Terms of Reference")

The concept of "life cycle" implies something that is born, develops and dies. Like a living organism, software products are created, operated, and evolve over time.

Life cycle software includes all stages of its development: from the emergence of a need for it to the complete cessation of its use due to obsolescence or the loss of the need to solve relevant problems.

There are several phases of the existence of a software product during its life cycle. There are as yet no generally accepted names for these phases and their number. But there is no particular disagreement on this issue. Therefore, there are several options for breaking down the software life cycle into stages. The question of whether a particular partition is better than others is not the main one. The main thing is to properly organize software development taking into account them.

According to the duration of the life cycle, software products can be divided into two classes: small and great life time. These classes of programs correspond to a flexible (soft) approach to their creation and use and a rigid industrial approach to the regulated design and operation of software products. In scientific organizations and universities, for example, the development of first-class programs prevails, while in design and industrial organizations- second.

Software products with a short lifespan are created mainly to solve scientific and engineering problems, to obtain specific results of calculations. Such programs are usually relatively small. They are developed by one specialist or a small group. The main idea of ​​the program is discussed by one programmer and end user. Some details are put on paper, and the project is implemented within a few days or weeks. They are not intended for replication and transfer for subsequent use in other teams. As such, such programs are part of a research project and should not be considered disposable software products.

Their life cycle consists of a long period of system analysis and formalization of the problem, a significant stage of program design and a relatively short time of operation and obtaining results. The requirements for functional and design characteristics, as a rule, are not formalized; there are no formalized program tests. Their quality indicators are controlled only by developers in accordance with their informal ideas.

Software products with a short lifespan

Maintenance and modification of such programs is not mandatory, and their life cycle is completed after receiving the results of calculations. The main costs in the life cycle of such programs fall on the stages of system analysis and design, which last from a month to 1 ... 2 years, as a result

that the life cycle of a software product rarely exceeds 3 years.

Software products with a long service life created for regular information processing and management. The structure of such programs is complex. Their sizes can vary over a wide range (1...1000 thousand commands), but they all have the properties of cognizability and the possibility of modification in the process of long-term maintenance and use by various specialists. Software products of this class can be replicated, they are accompanied by documentation as industrial products and are software products alienated from the developer.

Software products with a long service life

Their design and operation are carried out by large teams of specialists, which requires the formalization of the software system, as well as formalized testing and determination of the achieved quality indicators of the final product. Their life cycle is 10...20 years. Up to 70...90% of this time falls on operation and maintenance. Due to mass replication and long-term maintenance, the total costs during the operation and maintenance of such software products significantly exceed the costs of system analysis and design.

All subsequent presentation focuses on the development of large (complex) software tools for managing and processing information.

Generalized model life cycle The software product might look like this:

I. System analysis:

a) research;

b) feasibility study:

operational;

Economic;

Commercial.

II. Software design:

a) design:

Functional decomposition of the system, its architecture;

External software design;

Database design;

Software architecture;

b) programming:

Internal software design;

External design of software modules;

Internal design of software modules;

Coding;

Debugging programs;

Program layout;

c) software debugging.

III. Evaluation (testing) of software.

IV. Software use:

a) operation;

b) support.

I. System analysis. At the beginning of software development, a system analysis is carried out (its preliminary design), during which the need for it, its purpose and main functional characteristics are determined. The costs and possible efficiency of the application of the future software product are estimated.

At this stage, a list of requirements is compiled, that is, a clear definition of what the user expects from the finished product. Here, goals and objectives are set, for the sake of which the project itself is being developed. In the phase of system analysis, two directions can be distinguished: research and feasibility analysis.

Research begins from the moment the development manager realizes the need for software.

The work consists in planning and coordinating the actions necessary to prepare a formal handwritten list of requirements for the developed software product.

Research ends when the requirements are formed in such a way that they become visible and, if necessary, can be modified and approved by the responsible manager.

Feasibility study there is a technical part of the research and begins when the intention of the management is strong enough that a project manager is appointed to organize the design and distribution of resources (labor).

The work consists in the study of the proposed software product in order to obtain a practical assessment of the possibility of implementing the project, in particular, the following are determined:

- operational feasibility , Will the product be comfortable enough for practical use?

- economic feasibility , Is the cost of the developed product acceptable? What is this cost? Will the product be a cost effective tool in the hands of the user?

- commercial feasibility, Will the product be attractive, marketable, easy to install, serviceable, easy to learn?

These and other questions need to be addressed mainly when considering the above requirements.

The feasibility study ends when all requirements have been collected and approved.

Before proceeding further work on the project, you need to make sure that all the necessary information is obtained. This information must be accurate, understandable and enforceable. It should be a complete set of requirements that satisfy the user for the developed software product, drawn up in the form of a specification.

If this requirement is not observed, it is possible to significantly slow down the implementation of the project in the future due to repeated repeated requests to the user for clarification of incorrectly interpreted details, unspecified conditions and, as a result, it will be necessary to rework the already developed parts of it.

Often during the period of system analysis, a decision is made to stop further software development.

II. Software design. Design is the main and decisive phase of the software life cycle, during which a software product is created and 90% gets its final form.

This phase of life covers the various activities of the project and can be divided into three main stages: design, programming, and debugging of the software product.

Construction software development usually starts as early as the feasibility study phase, as soon as some preliminary goals and requirements for it are fixed on paper.

By the time the requirements are approved, work in the design phase will be in full swing.

At this segment of the life of the software, the following is carried out:

Functional decomposition of the problem being solved, on the basis of which the architecture of the system of this problem is determined;

External software design, expressed in the form of its external interaction with the user;

Database design, if necessary;

Software architecture design - definition of objects, modules and their interfacing.

Programming begins already in the construction phase, as soon as the main specifications for the individual components of the software product become available, but not before the approval of the requirements agreement. The overlap between the programming and construction phases results in savings in overall development time, as well as providing validation of design decisions, and in some cases impacts key issues.

At this stage, the work associated with the assembly of the software product is performed. It consists in a detailed internal design of a software product, in the development of the internal logic of each module of the system, which is then expressed in the text of a particular program.

The programming phase ends when the developers have finished documenting, debugging, and linking the individual parts of the software product into a whole.

Software Debugging is carried out after all its components are debugged separately and assembled into a single software product.

III. Evaluation (testing) of software. In this phase, the software product is subjected to rigorous system testing by a group of non-developers.

This is done to ensure that the finished software product meets all requirements and specifications, can be used in the user's environment, is free from any defects, and contains the necessary documentation that accurately and completely describes the software product.

The evaluation phase begins once all the components (modules) have been put together and tested, i.e. after complete debugging of the finished software product. It ends after receiving confirmation that the software product has passed all tests and is ready for operation.

It goes on just as long as programming.

IV. Use of the software. If system analysis is a call to action, design is an attack and a return with a victory, then using a software product is a daily defense, vital, but usually not honorable for developers.

Such a comparison is appropriate in view of the fact that during the use of a software product, errors that have crept in during its design are corrected.

The use phase of the software product begins when the product is transferred to the distribution system.

This is the time during which the product is in operation and used effectively.

At this time, staff training, implementation, configuration, maintenance and, possibly, expansion of the software product are carried out - the so-called ongoing design.

The use phase ends when the product is withdrawn from use and the activities mentioned above cease. Note, however, that the software product may be used by someone else for a long time after the use phase as defined here has ended. Because this someone can fruitfully use the software product even without the help of a developer.

The use of the software product is determined by its operation and maintenance.

Operation of the software product consists in its execution, its functioning on a computer for processing information and in obtaining the results that are the purpose of its creation, as well as in ensuring the reliability and reliability of the data issued.

Software maintenance consists in maintenance, development of functionality and improvement of the operational characteristics of the software product, in replication and porting of the software product to various types of computing facilities.

Maintenance plays the role of necessary feedback from the operation phase.

During the operation of the software, it is possible to detect errors in programs, and it becomes necessary to modify them and expand their functions.

These improvements, as a rule, are carried out simultaneously with the operation of the current version of the software product. After checking the prepared adjustments on one of the software instances, the next version of the software product replaces the previously used ones or some of them. At the same time, the process of operating the software product can be practically continuous, since the replacement of the software product version is short-term. These circumstances lead to the fact that the process of operating a version of a software product usually runs in parallel and independently of the maintenance phase.

Overlap between software product lifecycle phases

Overlaps between different phases of the software product life cycle are possible and usually desirable. However, there should be no overlap between non-contiguous processes.

Feedback between phases is possible. For example, during one of the external design steps, errors in the formulation of goals may be discovered, then you need to immediately return and correct them.

The considered model of the life cycle of a software product, with some changes, can also serve as a model for small projects.

For example, when a single program is being designed, it is often done without designing the architecture of the system and

database design; the processes of initial and detailed external design often merge together, etc.

Software life cycle - 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 moment of its complete withdrawal from operation.

Software Life Cycle Processes:

Basic,

Auxiliary,

Organizational.

Main:

1. Acquisition - actions and tasks of the customer purchasing the software;

2. Delivery - the activities and tasks of the supplier who supplies the customer with a software product or service;

3. Development - actions and tasks performed by the developer: software development, execution of design and operational documentation, preparation of test and teaching materials;

4. Operation - actions and tasks of the operator of the organization operating the system;

5. Maintenance - making changes to the software in order to correct errors, improve performance or adapt to changing operating conditions or requirements.

Auxiliary:

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

2. Configuration management - the application of administrative and technical procedures throughout the software life cycle to determine the state of software components, manage its modifications;

3. Quality Assurance - ensuring that the software and its life cycle processes comply with the specified requirements and approved plans;

4. Verification - determination that software products fully satisfy the requirements or conditions due to previous actions;

5. Certification - determination of the completeness of compliance of the specified requirements and the created system with their specific functional purpose;

6. Joint assessment - assessment of the state of work on the project: control of planning and management of resources, personnel, equipment, tools;

7. Audit - determination of compliance with the requirements, plans and conditions of the contract;

8. Problem resolution - analysis and resolution of problems, regardless of their origin or source, that are discovered during development, operation, maintenance or other processes.

Organizational:

1. Management - actions and tasks that can be performed by any party that manages its processes;

2. Creation of infrastructure - selection and maintenance of technology, standards and tools, selection and installation of hardware and software used to develop, operate or maintain software;

3. Improvement - assessment, measurement, control and improvement of the life cycle processes;

4. Training - initial training and subsequent continuous professional development of personnel.

In 2002, the standard for system life cycle processes (ISO/IEC 15288 System life cycle processes) was published. Experts from various fields were involved in the development of the standard: systems engineering, programming, quality management, by human resourses, security, etc. Practical experience in creating systems in government, commercial, military and academic organizations was taken into account. The standard is applicable to a wide class of systems, but its main purpose is to support the creation of computerized systems.

According to the ISO/IEC 15288 series, the following process groups should be included in the lifecycle structure:

1. Contractual processes:

Acquisition (in-house solutions or external provider solutions);

Delivery (internal solutions or external supplier solutions);

2. Enterprise processes:

Control environment enterprises;

Investment management;

IP Life Cycle Management;

Resource management;

Quality control;

3. Design processes:

Project planning;

Project evaluation;

Project control;

Management of risks;

Configuration management;

Information flow management;

Making decisions.

4. Technical processes:

Definition of requirements;

Requirements analysis;

Architecture development;

implementation;

Integration;

Verification;

Transition;

Certification;

Exploitation;

Escort;

Disposal.

5. Special processes:

Definition and establishment of interrelations proceeding from tasks and the purposes.

Establishment of Core IP Software Life Cycle Processes (ISO/IEC 15288)

Process (process executor)	Actions	Entrance	Result
Acquisition (customer)	- Initiation - Preparation of bid proposals - Contract preparation - Supplier activity control - IP acceptance	- Decision to start work on the implementation of IP - Results of a survey of customer actions - Results of an analysis of the IP market / tender - Delivery / development plan - Comprehensive test of IP	- Feasibility study for the implementation of IS - Terms of reference for IS - Contract for the supply/development - Acts of acceptance of work stages - Act of acceptance tests
Delivery (IS developer)	- Initiation - Response to bids - Contract preparation - Execution planning - IP supply	- Terms of reference for IS - Decision of management to participate in the development - Results of the tender - Terms of reference for IS - Project management plan - Developed IS and documentation	- Decision on participation in the development - Commercial proposals / bid - Contract for the supply / development - Project management plan - Implementation / adjustment - Acceptance test report
Development (IS developer)	- Preparation - IS Requirements Analysis - IS Architecture Design - Software Requirements Development - Software Architecture Design - Software Detailed Design - Software Coding and Testing - Software Integration and Software Qualification Testing - IS Integration and IS Qualified Testing	- Terms of reference for IS - Terms of reference for IS, life cycle model - IS subsystems - Requirements specifications for software components - Software architecture - Detailed software design materials - Software integration plan, tests - IS architecture, software, documentation for IS, tests	- The life cycle model used, development standards - The work plan - The composition of subsystems, hardware components - Specifications of requirements for software components - The composition of software components, interfaces with the database, the software integration plan - The database project, specifications for interfaces between software components, requirements for tests - Module texts Software, acts of autonomous testing - Assessment of compliance of the software complex with the requirements of the TOR - Assessment of compliance of software, database, technical complex and a set of documentation to the requirements of the TOR

System Development Stages (ISO/IEC 15288)

CPC: Create terms of reference for the project "Queue" on the site www.mastertz.ru

Software Lifecycle Models:

1. cascade,

2. spiral,

3. iterative.

Cascade model life cycle (“waterfall model”, English waterfall model) was proposed in 1970 by Winston Royce. It provides for the sequential implementation of all stages of the project in a strictly fixed order. The transition to the next stage means the complete completion of the work at the previous stage.

The requirements defined at the requirements formation stage are strictly documented in the form of terms of reference and fixed for the entire duration of the project development.

Each stage culminates in the release of a complete set of documentation sufficient for development to be continued by another development team.

Requirements development

Formation

spiral model(English spiral model) was developed in the mid-1980s by Barry Boehm. It is based on Edward Deming's classic PDCA (plan-do-check-act) cycle. When using this model, software is created in several iterations (spiral turns) by prototyping.

A prototype is an active software component that implements individual functions and external interfaces.

Each iteration corresponds to the creation of a fragment or version of the software, it clarifies the goals and characteristics of the project, evaluates the quality of the results obtained, and plans the work of the next iteration.

Rice. 21. Spiral model of software life cycle

At each iteration, the following are evaluated:

1. The risk of exceeding the terms and cost of the project;

2. The need to perform another iteration;

3. The degree of completeness and accuracy of understanding the requirements for the system;

4. The expediency of terminating the project.

One example of the implementation of the spiral model is RAD.

Basic principles of RAD:

1. Toolkit should be aimed at minimizing development time;

2. Creation of a prototype to clarify customer requirements;

3. Cycle of development: each new version of the product is based on the assessment of the result of the work of the previous version by the customer;

4. Minimization of version development time by transferring ready-made modules and adding functionality to the new version;

5. The development team must work closely, each member must be willing to perform multiple responsibilities;

6. Project management should minimize the duration of the development cycle.

Iterative model: the natural development of the cascade and spiral models has led to their convergence and the emergence of a modern iterative approach, which is a rational combination of these models.

Rice. 22. Iterative model of software life cycle