Life cycle is a model for creating and using a software system. It reflects the various states of a software system, starting from the moment the need for this software system arises and the decision to create it is made, and ending with the complete withdrawal of the software system from operation.

The international standard ISOIES 12207 defines a life cycle framework containing the processes, activities and tasks that must be performed during the creation of software. According to this standard, the life cycle software is based on three groups of processes:

the main life cycle processes, that is, acquisition, delivery, development, operation and maintenance;

auxiliary processes that ensure the implementation of the main processes, that is, documentation, verification, certification, quality assessment and others;

organizational processes, that is project management, creation of project infrastructure and training.

Development includes all work to create software in accordance with specified requirements. This includes the preparation of design and operational documentation, preparation of materials necessary to test the functionality and quality of software products.

Main stages of the development process:

analysis of customer requirements;

design;

implementation (programming).

The operation process includes work on putting software into operation, including configuring workstations, training personnel, localizing operational problems and eliminating the causes of their occurrence, modifying software within the established regulations and preparing proposals for system modernization.

Each process is characterized by certain tasks and methods for solving them, as well as initial data and results.

The software life cycle is, as a rule, iterative in nature, that is, stages are implemented, starting from the earliest ones, which are repeated cyclically in accordance with changing requirements of external conditions and the introduction of restrictions.

Software life cycle models

There are several life cycle models that determine the order of execution of development stages and the criteria for transition from stage to stage. To date, two life cycle models have become most widespread: cascade And spiral.

In previously existing homogeneous information systems ah, each application was a single whole. To develop such applications, a waterfall life cycle model was used, also called classical or waterfall.

When using the waterfall model, development was viewed as a sequence of stages, with the transition to the next lower stage occurring only after all work at the current stage was completely completed. It is understood that in the waterfall model, development begins at system level and occurs through analysis, design, coding, testing and maintenance.

Figure 1 – Main stages of developing a cascade model

1. System analysis specifies the role of each element in a computer system and the interaction of elements with each other. Since software is considered as part of a larger system, the analysis begins with determining the requirements for all system elements. The need for system analysis clearly manifests itself when the interface of the software with other elements is formed, i.e. with hardware or databases. At the same stage, the solution to project planning problems begins. During project planning, the volume of project work and its risk, the required labor costs are determined, work tasks and a work schedule are formed.

Requirements analysis refers to a single software element. At this stage, the functions of each element, its characteristics and interface are clarified and detailed. At the same stage, the solution to the project planning problem is completed.

2. Design consists of creating:

software architectures;

modular software structure;

algorithmic structure of the software;

data structures;

input/output interface (input/output data forms).

When solving design problems, the main attention is paid to the quality of the future software product.

3. Coding or development consists of translating design results into program code.

4. Testing is the execution of a program to identify defects in the functions, logic and form of implementation of a software product.

5. Maintenance is making changes to the operating software in order to:

bug fixes;

adaptation to changes in the environment external to the software;

improvement of software in accordance with customer requirements.

Advantages of using the cascade model:

gives a plan and time schedule for all stages of the project, thus streamlining the progress of development;

at each stage, a complete set of design documentation is generated, checked for completeness and consistency;

the stages of work performed in a logical sequence make it possible to plan the timing of completion of all work and the corresponding costs.

The cascade model has proven itself well in the construction of information systems, for which at the very beginning of development it is possible to quite accurately formulate all the requirements in the system, for example, complex calculation systems, various real-time systems, etc.

Disadvantages of the cascade model:

real projects often require deviations from the standard sequence of steps;

the cascade model is based on the precise formulation of the initial software requirements, but in reality, in a number of cases, at the beginning of the project, the customer’s requirements are only partially determined;

the results of the project are available to the customer only after completion of all work.

Due to the need in the software creation process to constantly return to previous stages and refine or revise previously decisions taken the actual software development process based on the waterfall model can be represented by the following diagram (Fig. 2).

Figure 2 – Software development process based on the waterfall model

Software development is impossible without understanding the so-called software life cycle. The average user may not need to know this, but it is advisable to master the basic standards (later it will be said why this is necessary).

What is life cycle in a formal sense?

The life cycle of any application is usually understood as the time of its existence, starting from the development stage and until the moment of complete abandonment of use in the chosen field of application, up to the complete withdrawal of the application from use.

In simple terms, information systems in the form of programs, databases or even “operating systems” are in demand only if the data and the opportunities they provide are up-to-date.

It is believed that the life cycle definition does not apply in any way to test applications, such as beta versions, which are the most unstable in operation. The software life cycle itself depends on many factors, among which one of the main roles is played by the environment in which the program will be used. However, it is also possible to highlight General terms, used in defining the concept of life cycle.

Initial requirements

• formulation of the problem;
• analysis of mutual requirements of future software for the system;
• design;
• programming;
• coding and compilation;
• testing;
• debugging;
• implementation and maintenance of the software product.

Software development consists of all the above-mentioned stages and cannot do without at least one of them. But special standards have been established for control of such processes.

Software Life Cycle Process Standards

Among the systems that predetermine the conditions and requirements for such processes, today we can name only three main ones:

• GOST 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

For the second international standard there is a Russian analogue. This is GOST R ISO/IEC 12207-2010, which is responsible for system and software engineering. But the software life cycle described in both rules is essentially identical. This is explained quite simply.

Types of software and updates

By the way, for most currently known multimedia programs, they are a means of saving basic configuration parameters. The use of software of this type is, of course, quite limited, but understanding the general principles of working with the same media players will not hurt. And that's why.

In fact, they include the software life cycle only at the level of updating the version of the player itself or installing codecs and decoders. And audio and video transcoders are integral attributes of any audio or video system.

Example based on FL Studio

Initially, the virtual studio-sequencer FL Studio was called Fruity Loops. The life cycle of the software in its initial modification has expired, but the application has been somewhat transformed and acquired its current form.

If we talk about the stages of the life cycle, first, at the stage of setting the problem, several mandatory conditions were set:

• creating a drum module similar to rhythm machines like Yamaha RX, but using one-shot samples or sequences in WAV format, recorded live in studios;
• integration into Windows operating systems;
• the ability to export a project in WAV, MP3 and OGG formats;
• Compatibility of projects with the additional application Fruity Tracks.

At the development stage, C programming language tools were used. But the platform looked quite primitive and did not give the end user required quality sound.

In this regard, at the testing and debugging stage, the developers had to follow the path of the German Steinberg corporation and apply support for Full Duplex mode in the requirements for the main sound driver. The sound quality has become higher and allows you to change the tempo, pitch and apply additional FX effects in real time.

The end of the life cycle of this software is considered to be the release of the first official version of FL Studio, which, unlike its ancestors, already had the interface of a full-fledged sequencer with the ability to edit parameters on a virtual 64-channel mixing console with unlimited addition of audio tracks and MIDI tracks.

It didn't stop there. At the project management stage, support was introduced for connecting plug-ins of the VST format (first the second, and then the third version), which was once developed by Steinberg. Roughly speaking, any virtual synthesizer that supports VST-host could connect to the program.

It is not surprising that soon any composer could use analogues of “hardware” models, for example, complete sets of sounds of the once popular Korg M1. Further more. The use of modules like Addictive Drums or the universal Kontakt plugin made it possible to reproduce the live sounds of real instruments recorded with all shades of articulation in professional studios.

At the same time, the developers tried to achieve maximum quality by creating support for ASIO4ALL drivers, which turned out to be head and shoulders above the Full Duplex mode. Accordingly, the bitrate also increased. Today, the quality of the exported audio file can be 320 kbps at a sampling rate of 192 kHz. And this is professional sound.

As for the initial version, its life cycle could be called completely complete, but such a statement is relative, since the application only changed its name and acquired new capabilities.

Development prospects

What the stages of the software life cycle are is already clear. But the development of such technologies is worth mentioning separately.

Needless to say, any software developer is not interested in creating a fleeting product that is unlikely to survive in the market for several years. In the long term, everyone is looking at its long-term use. This can be achieved in different ways. But, as a rule, almost all of them come down to the release of updates or new versions of programs.

Even in the case of Windows OS, such trends can be seen with the naked eye. It is unlikely that today there will be at least one user using systems like modifications 3.1, 95, 98 or Millennium. Their life cycle ended after the release of XP. But server versions based on NT technologies are still relevant. Even Windows 2000 today is not only very relevant, but in some installation or security parameters it even surpasses the latest developments. The same applies to the NT 4.0 system, as well as a specialized modification of Windows Server 2012.

But in relation to these systems, support is still declared at the highest level. But the once sensational Vista is clearly experiencing the decline of its cycle. Not only did it turn out to be unfinished, but there were so many errors in it and gaps in its security system that one can only guess how such an untenable solution could be released onto the software market.

But if we say that the development of software of any type (control or application) does not stand still, we can only say that today it concerns not only computer systems, but also mobile devices, in which the technologies used are often ahead of the computer sector. The emergence of processor chips based on eight cores is not the best best example? But not every laptop can boast of having such hardware.

Some additional questions

As for understanding the life cycle of software, it is quite arbitrary to say that it ended at a certain point in time, because software products still have support from the developers who created them. Rather, the ending refers to legacy applications that do not meet the requirements modern systems and cannot work in their environment.

But even taking into account technical progress many of them may soon become insolvent. Then you will have to make a decision either to release updates or to completely revise the entire concept originally incorporated into the software product. Hence the new cycle, which involves changing the initial conditions, development environment, testing and possible long-term use in a certain area.

But in computer technologies Today, preference is given to the development of automated control systems (ACS), which are used in production. Even operating systems, in comparison with specialized programs, lose.

Visual Basic-based environments remain much more popular than Windows systems. And we are not talking about application software for UNIX systems at all. What can we say if almost all communication networks of the same United States work exclusively for them. By the way, systems like Linux and Android were also originally created on this platform. Therefore, most likely, UNIX has much more prospects than other products combined.

Instead of a total

It remains to add that in this case only general principles and stages of the software life cycle are given. In fact, even the initially set tasks can vary very significantly. Accordingly, differences can be observed at other stages.

But the basic technologies for developing software products and their subsequent support should be clear. For the rest, one should take into account the specifics of the software being created, the environments in which it is supposed to work, and the capabilities of the programs provided to the end user or production, and much more.

In addition, sometimes life cycles can depend on the relevance of development tools. If, for example, a programming language becomes obsolete, no one will write programs based on it, much less implement them into automated systems production management. Here it is not even programmers who come to the fore, but marketers who must respond in a timely manner to changes in the computer market. And there are not so many such specialists in the world. Highly qualified personnel who can keep their finger on the pulse of the market are becoming the most in demand. And they are often the so-called “gray cardinals” on whom the success or failure of a certain software product in the IT field depends.

They may not always understand the essence of programming, but they are clearly able to determine models of the software life cycle and the length of time for their use, based on global trends in this area. Effective management often produces more tangible results. Yes, at least PR technologies, advertising, etc. The user may not need some application, but if it is actively advertised, the user will install it. This is already, so to speak, a subconscious level (the same effect of the 25th frame, when information is put into the user’s consciousness independently of him).

Of course, such technologies are prohibited in the world, but many of us do not even realize that they can still be used and influence the subconscious in a certain way. Just look at the cost of “zombification” by news channels or Internet sites, not to mention the use of more powerful means, such as exposure to infrasound (this was used in one opera production), as a result of which a person may experience fear or inappropriate emotions.

Returning to the software, it is worth adding that some programs use a sound signal when starting up to attract the user's attention. And, as research shows, such applications are more viable than other programs. Naturally, the software life cycle also increases, no matter what function was initially assigned to it. And, unfortunately, many developers use this, which raises doubts about the legality of such methods.

But it’s not for us to judge this. It is possible that tools will be developed in the near future to identify such threats. So far this is only a theory, but, according to some analysts and experts, up to practical application There's very little left. If they are already creating copies of the neural networks of the human brain, then what can we say?

Software life cycle

One of the basic concepts of IS design methodology is the concept of software life cycle (SOLC).

J C– this is a model of various states of a software product, starting from the moment the need for this software product arises and ending with the moment it goes out of use for all users.

The life cycle of databases is not yet regulated by standards - existing standards relate only to the life cycle of software.

PS life cycle standards can be used as directive, guidance or advisory documents.

The life cycle, technology for developing and ensuring the quality of software are most fully reflected in ISO standards (International Standards Organization). The ISO 12207:1995 standard - “Software life cycle processes” - most fully reflects the architecture, work, organization and management of the software life cycle.

PS life cycle models actually used in companies Lately change relative to those given in the standards in connection with the introduction and development of object-oriented analysis and methods for rapid software development, CASE systems and fourth-generation languages. The new models reduce the work on the direct creation of software components and detail the work on system analysis and design of software systems and databases.

In general, when creating PS projects and ensuring their life cycle, it is advisable to use a sample from the entire set of presented standards (both international and national), and fill existing gaps in standardization with de facto standards and departmental regulatory documents.

Profile- is a combination of several basic standards and other regulatory documents, designed to implement a given function or group of functions.

Based on the same set of basic standards, different profiles can be formed for different projects.

When certifying information systems, certification for compliance with the profile is distinguished as a special type of test. And here it should be taken into account that in international IP standardization a strict interpretation of the concept of a profile is adopted - it is believed that only international and national approved standards can be the basis of a profile (that is, the use of de facto standards and regulatory documents of companies is not allowed).

Based on the specific profile, it is planned to write documentation. Moreover, for each stage of the life cycle, its own documentation is written, which in turn is divided into types, depending on for which specialists it is created.

Software life cycle is a continuous process that begins from the moment a decision is made about the need for its creation and ends at the moment of its complete withdrawal from service.

The main regulatory document regulating the life cycle of software is international standard ISO /IEC 12207 (ISO - International Organization of Standardization, IEC - International Electrotechnical Commission). It defines the life cycle structure containing the processes, activities and tasks that must be performed during software creation.

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

· main processes Software life cycle (purchase, supply, development, operation, support);

· auxiliary processes ensuring the implementation of basic processes (documentation, configuration management, quality assurance, verification, certification, assessment, audit, problem solving);

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

Development includes all work on creating software and its components in accordance with specified requirements, including the preparation of design and operational documentation, preparation of materials necessary to test the functionality and appropriate quality of software products, materials necessary for organizing personnel training, etc.

Software development includes, usually:

· analysis;

· design;

· implementation (programming).

The development phase begins with a feasibility study of the project and then translates it from user requirements into a form that can be implemented on computers.

This phase typically accounts for 50% of the design cost and 32% of labor costs.

Exploitation begins when the product is handed over to the user, in use and in use.

Includes:

Work on putting software components into operation, including configuring the database and user workstations;

Providing operational documentation;

Conducting personnel training, etc., and direct operation, including localizing problems and eliminating the causes of their occurrence,

Modification of software within the established regulations, preparation of proposals for improvement, development and modernization of the system.

Maintenance phase also called the ongoing development phase.

Consists of identifying and eliminating errors in programs and changing their functionality.

Practitioners have recognized that this part of the life cycle (LC) should be taken into account from the moment development begins in order to improve the design in accordance with the needs of the user.

Maintenance process, will continue in parallel with the operation of the PI.

Labor cost structure for different kinds Maintenance activities are such that about 78% of the time is spent on changing the functionality of the software, and 17% on identifying errors.

Configuration management is one of the auxiliary processes that support the main processes of the software life cycle, primarily the processes of software development and maintenance. When creating complex IS projects consisting of many components, each of which may have varieties or versions, the problem arises of taking into account their connections and functions, creating a unified structure and ensuring the development of the entire system. Configuration management allows you to organize, systematically take into account and control changes to software at all stages of the life cycle. General principles and recommendations for configuration accounting, planning and software configuration management are reflected in the draft standard ISO 12207-2.

Project quality assurance associated with problems of software verification, verification and testing. Verification is the process of determining whether the current state of development achieved at at this stage, the requirements of this stage. Examination allows you to assess the compliance of development parameters with the initial requirements. The check partially coincides with testing, which is associated with identifying differences between actual and expected results and assessing the conformity of software characteristics original requirements. In the process of project implementation, an important place is occupied by the issues of identification, description and control of the configuration of individual components and the entire system as a whole.

Project management associated with issues of planning and organizing work, creating development teams and monitoring the timing and quality of work performed. Technical and organizational support for the project includes the selection of methods and tools for project implementation, determination of methods for describing intermediate development states, development of methods and tools for software testing, personnel training, etc.

Each process is characterized by:

specific tasks and methods for solving them,

the initial data obtained at the previous stage,

results.

The results of the analysis, in particular, are functional models, information models and their corresponding diagrams. Life cycle software carries iterative nature: The results of the next stage often cause changes in design solutions developed at earlier stages.

Software life cycle models

The ISO/IEC 12207 standard does not provide a specific life cycle model and software development methods. (The life cycle model depends on the specifics of the information system and the specific conditions in which the latter is created and operates). Its regulations are common to any life cycle models, methodologies and development technologies. The ISO/IEC 12207 standard describes the structure of software life cycle processes, but does not specify in detail how to implement or perform actions And tasks included in these processes.

To date, the following two main life cycle models have become most widespread:

· cascade model (70-85);

· spiral model (86-90).

In the original homogeneous IS, each application was a single whole. To develop this type of application we used cascade method. Its main characteristic is the division of the entire development into stages, and the transition from one stage to the next occurs only after the work on the current one is completely completed (Fig. 1). Each stage culminates in the release of a complete set of documentation sufficient to allow development to be continued by another development team.

Positive sides The applications of the cascade approach are as follows:

· at each stage a complete set is formed project documentation, meeting the criteria of completeness and consistency;

· stages of work carried out in a logical sequence allow us to plan the completion time of all work and the corresponding costs.

Rice. 1. Waterfall software development scheme

The cascade approach has proven itself well in the construction of information systems, for which, at the very beginning of development, all requirements can be quite accurately and completely formulated in order to give developers the freedom to implement them as best as possible from a technical point of view. Complex calculation systems, real-time systems, and other similar tasks fall into this category. However, in the process of using this approach, a number of its shortcomings were discovered, primarily caused by the fact that the real software creation process never completely fit into such a rigid scheme:

· Identifying reasons why a project needs to be changed at later stages: checking the functionality and feasibility of an application project in the early stages is usually not performed.

· Inadequate risk management: risks associated with the project are identified in the later stages of the project.

· No procedure for reviewing requirements: In this model, requirements must be formulated and recorded in the early stages of development. As a rule, project goals and objectives are not fully understood at the beginning of the project, and therefore they have to be revised at later stages, which leads to a significant increase in development costs and delays in product release. If the changed requirements are not taken into account in the project, the customer will not consider the application to meet the objectives.

Rice. 2 Real software development process using a waterfall scheme

So, the main disadvantage of the cascade approach is the significant delay in obtaining results. Coordination of results with users is carried out only at points planned after the completion of each stage of work; the requirements for the IS are “frozen” in the form terms of reference for the entire time of its creation. Thus, users can make their comments only after work on the system is completely completed. If requirements are inaccurately stated or they change over a long period of software development, users end up with a system that does not meet their needs. Models (both functional and informational) of the automated object may become outdated simultaneously with their approval.

Thus, in the process of creating software, there was a constant need to return to previous stages and clarify or revise previously made decisions. As a result, the actual software creation process took next view(Fig. 2):

To overcome these problems, it was proposed spiral life cycle model(Fig. 3), focusing on the initial stages of life cycle: analysis and design. At these stages, the feasibility of technical solutions is tested by creating prototypes. Each turn of the spiral corresponds to the creation of a fragment or version of software. It clarifies the goals and characteristics of the project, determines its quality, and plans the work of the next turn of the spiral. Thus, the details of the project are deepened and consistently specified, and as a result, a reasonable option is selected, which is brought to implementation.

Development by iterations reflects the objectively existing spiral cycle of creating a system. Incomplete completion of work at each stage allows you to move on to the next stage without waiting for the complete completion of the current stage. With an iterative development method, the missing work can be completed in the next iteration. The main task is to show system users a workable product as quickly as possible, thereby activating the process of clarifying and supplementing requirements.

The main problem of the spiral cycle is determining the moment of transition to the next stage. To solve it, it is necessary to introduce time restrictions for each stage of the life cycle. The transition proceeds as planned, even if not all planned work is completed. The plan is drawn up based on statistical data obtained in previous projects and personal experience developers.

The spiral life cycle model places emphasis on the initial stages of the life cycle: analysis and design. At these stages, the feasibility of technical solutions is tested by creating prototypes. Each turn of the spiral corresponds to the creation of a fragment or version of the software, where the goals and characteristics of the project are specified, its quality is determined, and the work of the next turn of the spiral is planned. In this way, the details of the project are deepened and consistently specified, and as a result, a reasonable option is selected, which is brought to implementation.

Rice. 3. Spiral life cycle model

When creating software it can be used "A Model of Reuse and Reverse Engineering."

In it, the main weight of design decisions falls on design. The purpose of this model is the reuse (reuse) in current projects of well-tested “old” design solutions recorded in libraries of already completed projects. During the analysis and preliminary design process, work plans are outlined that include tasks for testing alternative design solutions. Then work begins to create the planned prototypes using a cascade scheme. As a result, one of the alternative solutions is selected, developed in parallel iterations for the remainder of the product development cycle. It is possible to select a mixed option based on combining the results of several turns.

If the implemented version fails, a rollback of the project (Reengineering) is possible.

Program life cycle.

The software life cycle is a period of time that begins from the moment a decision is made about the need to create a software product and ends when it is completely removed 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 programming one. You need to understand how the environment that needs to be automated functions (business process analysis). As a result, a documentation specification of the requirement appears, which indicates which specific tasks should be performed. resolved and under what conditions. This work is performed by a systems analyst (business process analyst).

2) Software is developed for the market. It is necessary to carry out marketing research and find which product is not on the market. This comes with a lot of risk. The goal is to develop a requirements specification.

Design

Purpose - Definition general structure(architecture) software. The result is a software specification. This work is performed by a system programmer.

Implementation

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

Assembly, testing, testing

A compilation of everything made by different programmers. Testing of the entire software package. Debugging – finding and eliminating the causes of errors. Test - clarification technical characteristics. As a result, the program is guaranteed to work.

Implementation (release)

Implementation – when they work for one customer. Includes setting up a program at the customer’s site, training the customer, consultations, eliminating errors and obvious deficiencies. The software must be alienated - the user can work with the software without the participation of the author.

Release – when software is developed for the market. Begins with the beta testing stage. Resp. 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 – production of several copies of software and sending potential customers. The goal is to check the software development again.

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

Escort

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

Life cycle models

1. Waterfall (“waterfall”, cascade model)

2. Prototyping

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

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 depends significantly on how well the 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 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 begin implementation in parts.

Software life cycle

The software life cycle is a period of time that begins from the moment a decision is made about the need to create a software product and ends at the moment it is completely removed from service. (IEEE Std 610.12)

The need to determine the stages of the software life cycle (LC) is due to the desire of developers to improve software quality by optimal control development and use of various quality control mechanisms at every stage, from problem formulation to author’s software support. The most general representation of the software life cycle is a model in the form of basic stages - processes, which include:

System analysis and justification of software requirements;

Preliminary (draft) and detailed (technical) software design;

Development of software components, their integration and debugging of software as a whole;

Testing, trial operation and replication of software;

Regular operation of the software, support for operation and analysis of results;

Software maintenance, its modification and improvement, creation of new versions.

This model is generally accepted and complies with both domestic regulations in the field of software development and foreign ones. From the point of view of ensuring technological safety, it is advisable to consider in more detail the features of the representation of life cycle stages in foreign models, since it is foreign software that is the most likely carrier of sabotage-type software defects.

Software life cycle standards

GOST 34.601-90

ISO/IEC 12207:1995 (Russian equivalent - GOST R ISO/IEC 12207-99)

Graphic representation of life cycle models allows one to clearly highlight their features and some properties of processes.

Initially, a cascade life cycle model was created, in which major stages began one after another using the results of previous work. 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 work at the previous stage. The requirements determined at the stage of requirements formation are strictly documented in the form of technical specifications and are recorded for the entire development of the project. Each stage culminates in the release of a complete set of documentation sufficient to allow development to be continued by another development team. The inaccuracy of any requirement or its incorrect interpretation results in the fact that it is necessary to “roll back” to the early phase of the project and the required rework not only throws the project team off schedule, but often leads to a qualitative increase in costs and, possibly, to the termination of the project in the form in which it was originally intended. The main misconceptions of the authors of the waterfall model are the assumptions that the project goes through the entire process once, the designed architecture is good and easy to use, the implementation design is reasonable, and errors in the implementation are easily eliminated through testing. This model assumes that all errors will be concentrated in the implementation, and therefore their elimination occurs evenly during testing of components and the system. Thus, the waterfall model is not very realistic for large projects and can only be effectively used to create small systems.

The most specific is the spiral life cycle model. This model focuses on the iterative process of the initial design stages. At these stages, concepts, requirements specifications, preliminary and detailed designs are sequentially created. At each turn, the content of the work is clarified and the appearance of the software being created is concentrated, the quality of the results obtained is assessed, and the work of the next iteration is planned. At each iteration the following are evaluated:

Risk of exceeding project deadlines and costs;

The need to perform another iteration;

The degree of completeness and accuracy of understanding of system requirements;

The feasibility of terminating the project.

Standardization of software life cycle is carried out in three directions. The first direction is organized and stimulated by the International Organization for Standardization (ISO - International Standard Organization) and the International Electrotechnical Commission (IEC - International Electro-technical Commission). At this level, the standardization of the most general technological processes that are important for international cooperation is carried out. The second direction is being actively developed in the USA by the Institute of Electrical and Electronics Engineers (IEEE) together with the American National Standards Institute (ANSI). ISO/IEC and ANSI/IEEE standards are primarily advisory in nature. The third direction is stimulated by the US Department of Defense (DOD). DOD standards are mandatory for companies working for the US Department of Defense.

To design software for a complex system, especially a real-time system, it is advisable to use a system-wide life cycle model based on combining all famous works within the framework of the considered basic processes. This model is intended for use in planning, scheduling, and managing various software projects.

It is advisable to divide the set of stages of this life cycle model into two parts, which differ significantly in the features of the processes, technical and economic characteristics and factors influencing them.

In the first part of the life cycle, system analysis, design, development, testing and testing of software are carried out. The range of work, its complexity, duration and other characteristics at these stages significantly depend on the object and development environment. The study of such dependencies for various classes of software allows us to predict the composition and main characteristics of work schedules for new software versions.

The second part of the life cycle, reflecting support for software operation and maintenance, is relatively weakly related to the characteristics of the object and development environment. The range of work at these stages is more stable, but their labor intensity and duration can vary significantly and depend on the widespread use of the software. For any life cycle model, provision High Quality software systems is possible only when using regulated technological process at each of these stages. This process is supported by development automation tools, which it is advisable to select from those available or create them taking into account the development object and the list of works adequate to it.