Life cycle and stages of software development. Software Life Cycle Models

The concept of "life cycle" implies something born, developing and dying. Like a living organism, software products are created, operated and develop in time.

Life cycle software includes all the stages of its development: from the emergence of the need for it to complete the termination of its use due to moral aging or the loss of the need to solve the relevant tasks.

Multiple phases of the existence of the software product can be distinguished during its life cycle. The generally accepted names for these phases and their numbers are not yet. But there are no special disagreements on this issue. Therefore, there are several options for splitting the software life cycle to the steps. The question of whether this particular partition is better than others, is not the main one. The main thing is necessary to properly organize the development of software with their accounting.

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

Software with a small duration of operation created mainly to solve scientific and engineering tasks to obtain specific results of calculations. Such programs are usually relatively small. They are developed by one specialist or small group. The main idea of \u200b\u200bthe program is discussed by one programmer and end user. Some details are entered on paper, and the project is implemented within a few days or weeks. They are not intended for replication and transmission for subsequent use in other teams. Essentially, such programs are part of research work and cannot be considered as alienated software products.

Their life cycle consists of a long interval of systemic analysis and formalization of the problem, a significant stage of designing programs and relatively short operating time and obtaining results. Requirements for functional and constructive characteristics are generally not formalized, missing programs for programs. Their quality indicators are monitored only by developers in accordance with their informal ideas.

Software with a small duration of operation

Support and modification of such programs are not required, 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 steps of systemic analysis and design, which continue from month to 1 ... 2 years, as a result

which life cycle of the software product rarely exceeds 3 years.

Software with a large duration of operation created for regular processing of information and management. The structure of such programs is complex. Their sizes may vary in wide limits (1 ... 1000 thousand teams), but they all have the properties of the cognizability and the possibility of modifications in the process of long-term maintenance and use by various specialists. Software products of this class allow replication, they are accompanied by documentation as industrial products and are software products alienated from the developer.

Software with a large duration of operation

Large teams of specialists are engaged in their design and operation, for which the formalization of the software system, as well as formalized tests and the definition of the achieved indicators of the final product quality. Their life cycle is 10 ... 20 years. Up to 70 ... 90% of this time is to operate and maintenance. As a result of mass replication and long-term maintenance, the cumulative costs during the operation and maintenance of such software products significantly exceed the cost of system analysis and design.

All subsequent presentation focuses on the topic of developing large (complex) software management and information processing software.

Generalized model life cycle the software can look like this:

I. System analysis:

a) research;

b) analysis of feasibility:

Operational;

Economic;

Commercial.

II. Software Design:

a) Designing:

Functional decomposition system, its architecture;

External software design;

Design database;

Software architecture;

b) Programming:

Internal design of software;

External design of software modules;

Internal design of software modules;

Coding;

Debugging programs;

Program layout;

c) Debugging software.

III. Evaluation (testing) of software.

IV. Using Software:

a) operation;

b) escort.

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

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

Studies begin from the moment when the development manager is aware of 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.

Studies end then, when the requirements are formed in this form, which becomes foreseeable and, if necessary, can be modified and approved by a responsible leader.

Analysis of feasibility there is a technical part of the research and begins when the intention of the leadership will grow so much that the project manager is appointed, organizing the design and distribution of resources (labor).

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

- performance operational , will the product be convenient enough for practical use?

- economic feasibility , is the cost of the product being developed 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, to be in demand, easily installed, adapted to service, easy to learn?

These and other issues must be solved mainly when considering the above requirements.

Analysis of feasibility ends when all requirements are collected and approved.

Before you continue further work on the project, you must make sure that all the necessary information is obtained. This information must be accurate, understandable and feasible. It must be a full range of requirements of satisfying the user to the developed software product, designed as a specification.

If this requirement fails to comply, it is possible to significantly slow down the implementation of the project in the future due to the multiple re-accessing the user for the clarification of incorrectly projected parts, uncovered conditions and, as a result, the alteration of its already developed parts will be required.

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

II.. Design software. Design is the main and solving phase of the software life cycle, during which it is created and 90% acquires its final form of a software product.

This phase of life covers different kinds Project activities and can be divided into three main stages: design, programming and debugging software.

Design software usually begins in the feasibility analysis phase, as soon as they are fixed on paper some preliminary goals and requirements for it.

By the time of approval of requirements, work in the design phase will be in full swing.

On this segment of the life of the software is carried out:

The functional decomposition of the solved problem, on the basis of which the architecture of the system of this problem is determined;

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

Designing a database, if necessary;

Designing software architecture - definition of objects, modules and conjugation.

Programming begins already in the design phase, as soon as the main specifications are available on individual components of the software product, but not earlier approval of the requirements of the requirements. The overlap of the programming and design phases leads to a common development time saving, as well as to ensure the verification of the proper design solutions, and in some cases affects the solution of key issues.

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

Programming phase is completed when the developers will finish documenting, debugging and laying separate parts software to one whole.

Debugging software it is carried out after all of its components will be debugged separately and are collected in a single software product.

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

This is done in order to ensure that the ready-made software satisfies all the requirements and specifications, can be used on the user's environment, freely from any defects and contains the necessary documentation that accurately and fully describes the software product.

The assessment phase begins as soon as all components (modules) are collected together and tested, i.e. After full debugging of the finished software product. It ends after receiving confirmation that the software has passed all the tests and is ready to operate.

It continues as long as programming.

IV. Using software.If the system analysis is a signal to battle, the design is an attack and a return with the victory, the use of a software product is daily defense, vital, but usually not honorable for developers.

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

The software utilization phase begins when the product is transmitted to the distribution system.

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

At this time, staff training, implementation, configuration, support and, possibly, the extension of the software product is the so-called continuing design.

The use phase ends when the product is withdrawn from consumption and the above-mentioned actions are terminated. We note, however, that the software product can long be applied anyone else after the use phase as it is defined here. Because this someone can fruitfully use the software product even without the help of the developer.

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

Software operation it is executed, the functioning of its computer for processing information and in obtaining results that are the purpose of its creation, as well as to ensure the reliability and reliability of the data issued.

Software support it is to maintain it service, the development of functionality and increasing the operational characteristics of the program of the product, in replicating and transferring the software to various types of computing.

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

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

These refinement are usually carried out simultaneously with the operation of the current version of the software product. After checking the prepared adjustments on one of the program instances, the next version of the software product replaces the previously operated or some of them. In this case, the process of operation of the software product can be almost continuous, as the replacement of the software version is short-term. These circumstances lead to the fact that the process of operation of the software version usually goes in parallel and regardless of the accompaniment stage.

Overlapping between the phases of the life cycle of the software product

Possible and usually desirable overlap between different phases of the software product life cycle. However, there should be no overlap between non-negative processes.

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

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

For example, when a single program is designed, then often do without the design of the system architecture and

database design; The processes of source and detailed external design are often merged together, etc.

The methodology for designing information systems describes the process of creating and maintaining systems in the form life cycle (ZHC) IP, presenting it as some sequence of stages and processes performed on them. For each stage, the composition and sequence of work performed, the results obtained, the methods and means necessary for the work, the role and responsibility of participants, etc. Such a formal description of the IP LCC allows to plan and organize a collective development process and ensure the management of this process.

Life cycle IP can be represented as a number of events taking place with the system during its creation and use.

Life cycle model reflect various states Systems starting from the moment of the need for this IP and ending with the moment of its complete exit of use. Life cycle model - Structure containing processes, actions and objectives that are carried out during the development, functioning and maintenance of the software product throughout the life of the system, from determining the requirements until its completion.

Currently known and use the following life cycle models:

• Cascading model (Fig. 2.1) provides for the sequential execution of all project steps in a strictly fixed order. The transition to the next step means full completion of the work at the previous stage.
• (Fig. 2.2). IP Development is carried out with iterations with feedback cycles between the steps. Inter-stage adjustments make it possible to take into account the actual interference of the development results at various stages; The lifetime of each of the stages is stretched for the entire period of development.
• Spiral model (Fig. 2.3). Each round of the spiral is made by the next version of the product, the project requirements are specified, its quality is determined and the work of the next turn is planned. Ensure is paid to the initial stages of development - analysis and design, where the realizability of certain technical solutions is checked and justified through the creation of prototypes (macating). .

Fig. 2.1.

Fig. 2.2.

Fig. 2.3.

In practice, the greatest distribution received two main life cycle models:

• cascading model (characteristic of the 1970-1985 period);
• spiral model (characteristic of the period after 1986).

In early projects, quite simple ICs, each application was a single, functionally independent independent unit. For the development of this type of application, a cascade method was effective. Each stage completed after the full implementation and documenting of all provided.

The following positive aspects of the application of a cascade approach can be distinguished:

• at each stage, a complete set of project documentation is formed, which meets the criteria of completeness and consistency;
• the stages of work performed in the logical sequence allow you to plan the deadlines for the completion of all works and the corresponding costs.

A cascade approach has proven itself in constructing relatively simple IP, when at the very beginning of development, it is possible to quite accurately and fully formulate all requirements for the system. The main disadvantage of this approach is that the real system for creating the system is never fully stacked in such a tough scheme, the need for return to previous stages and clarification or revising previous decisions. As a result, the actual process of creating IP is appropriate phased model with intermediate control.

However, this scheme does not allow to quickly take into account the changes and refine the system requirements. Coordination of development results with users is made only at points planned after the completion of each stage of work, and general requirements It is fixed in the form of a technical task for the entire time of its creation. Thus, users often receive a system that does not satisfy their real needs.

Spiral model The LCC was proposed to overcome the problems listed. At the analysis and design stages, the realizability of technical solutions and the degree of customer satisfaction is checked by creating prototypes. Each round of spiral corresponds to creating a workable fragment or system version. This allows you to clarify the requirements, objectives and characteristics of the project, determine the quality of development, plan the work of the next spiral turn. Thus, the details of the project are deepened and consistently specifically specified and the reasonable option is selected, which satisfies the actual customer requirements And communicates before implementation.

Iterative development reflects an objectively existing spiral cycle of creating complex systems. It allows you to move to the next step, without waiting for the full completion of the work on the current and solve the main task - as soon as possible, to the users of the system workable product as soon as possible, thereby activating the process of refinement and additions.

The main problem of the spiral cycle is to determine the moment of transition to the next step. To solve it, temporary restrictions on each of the stages are introduced life cycle, and the transition is carried out in accordance with the plan, even if not all planned work is completed. Planning is based on the statistical data obtained in previous projects and personal experience developers.

The software of programs designed to solve the problem. The life cycle of the segment of time from the moment of the need to create software before the removal of it from operation. The stages of the software life cycle that can proceed both in succession and perallel and quasi-parallel:

1. Development;

2. Operation;

3. Accompanying.

At the accompaniment phase, as a rule, the following types of work are performed:

1. expansion of functionality of software;
2. modification already existing functions;
3. software modification associated with hardware modification;
4. the elimination of errors of the software that were not detected during the development in view of the impossibility of complete testing, and manifested only in the operating phase.

During the development, the following steps are distinguished clearly:

1. determination of software requirements, which provides for the collection of necessary information.
2. external design (the information contained in the technical task is subject to analysis and strict formalization; the main purpose of this stage is to provide the developer the most complete and accurate idea of \u200b\u200bwhat should ultimately turn out). It is not mandatory.
3. internal design (refer to the information obtained at the previous stages, and the data structures used in software are developed, the modular structure of the software is determined, the rules for the interaction of modules in the process of transferring control or information exchange, etc.).
4. programming (coding).
5. testing and debugging. Testing is the process of identifying the fact of errors in the program. Debugging - Testing + Diagnostics and Localization of Error + Error Remedy.
6. test software. Test - special view Testing, the purpose of which detecting inconsistencies between the obtained software and the requirements of the technical task.

Life cycle models on:

§ Cascade model

§ Spiral model - when passing one turn, the spiral result is the software version. After testing, a decision is made to develop the following version, or inverting, if this version meets the requirements of the technical task completely.

31. Technical task (GOST 19.201 - 78). Its main sections and their content.

In accordance with this standard, the following sections are included in the technical task:

2. Introduction;

3. Base for development;

4. Development assignment;

5. Requirements for the software;

6. Requirements for documentation;

7. Technical and economic indicators;

8. Stages and stages of development;

9. Procedure for control and acceptance

10. Appendix.

Introduction:

§ Name;

§ Brief description in the application of software.

The main purpose of this section is to demonstrate the relevance of this development and what place this development takes into a number of similar.

Base for development:

§ the name of the document, on the basis of which the development is maintained;

§ organization approved this document;

§ Name or conditional designation theme development.

Such a document can serve as a plan, order, contract, etc.

Development assignment:

§ Description of the functional and operational purpose of this system indicating the category of its users.

Requirements for the program or software product.

This section should include the following subsections:

1. Requirements K. functional characteristics;

2. Requirements for reliability;

3. Operating conditions;

4. Requirements for the composition and parameters of technical means;

5. Requirements for information and software compatibility;

6. Requirements for marking and packaging;

7. Requirements for transportation and storage.

8. Special requirements.

In the Requirements section of the functional characteristics, all functions must be listed and the composition, characteristics and form of the presentation of source data and results are described. In the same section, if necessary, indicate the criteria for efficiency (the maximum time response time, the maximum amount of memory used).

In the Requirements Requirements section, the level of reliability of the software should be specified in the development. In systems with conventional reliability requirements, i.e. Non-systems in which there is a risk of living people, additionally indicate the actions of the system development, aimed at increasing the reliability of the system (creating backup copies, blocking hazardous actions).

In the Operating Conditions section indicate specific requirements for the operating conditions of software (temperature, humidity). Such requirements are needed when software will work (operated) in conditions other than the development center. If the conditions do not differ, further indicate that the requirements are not presented or they omit this section at all. In this section, sometimes indicate the types of maintenance, the qualifications of the service personnel.

In the section Requirements for the composition and parameters of technical means indicate the necessary composition and main characteristics of technical means. In this section, two hardware configurations are usually indicated: minimum and nominal.

In the Requirements for Information and Software Compatibility, if necessary, you can set programming methods, development environment and the operating system used. If it is assumed that the software will be operated with other software, then in this section, you should bring the list of these software and describe the interaction interface at the level of data formats and API functions.

In the section Requirements for marking and packaging, methods of labeling and packaging software are indicated.

In the section Requirements for transportation and storage, the conditions for transportation, storage location, storage conditions and storage time in various conditions are indicated.

The Special Requirements section indicate the requirements that are not related to one of the previously described sections.

Requirements for software documentation.

This section brings a list of software and operational documentation to be developed with the software product. If necessary, it specifies special requirements for the structure and composition of documents. Minimum documentation: User Guide.

Technical and economic indicators.

Stages and stages of development.

It indicates the stages and stages of the development of the work performed indicating the timing and performers.

Procedure for control and acceptance.

It indicates the procedure for testing and general reception requirements.

Application: The list of NIR, justification, calculations, and other documents that should be used to develop.

Depending on the characteristics of the software being developed, it is allowed to specify the described sections, enter new or combine existing ones.

32. Structural design software: structural analysis method, design of a modular structure.

The structural analysis method is based on a number general principleslisted below.

1. Principle of decomposition and hierarchical orderingwhich lies in the division of a large and challenging problem into many smaller independent subtasks, easy for understanding and solving. Moreover, decomposition can be carried out for already selected subtasks. As a result of such a consistent decomposition, the specified system can be understood and built on the levels of the hierarchy, each of which adds new details.

2. The principle of abstraction It is to allocate significant aspects of the system and distraction from non-existent in order to present the problem in a convenient general form.

3. The principle of formalization It is the need for a strict methodological approach and solving the problem.

4. Principle of hiding It is a "progress" insignificant at a certain stage of information: each part "knows" only what is needed.

5. Principle of completeness It is to control the presence of unnecessary elements.

6. Principle of consistency lies in the validity and consistency of the elements.

7. The principle of logical independence It is a concentration of focus on logical design to ensure independence from physical execution.

8. The principle of data independence It is that the data models must be analyzed and designed independently of their logical processing processes, as well as their physical structure and distribution in the memory of the computing system.

9. Principle of data structuring It is that the data should be structured and hierarchically organized.

Guided by all principles in the complex, it is possible to understand the specific software at the stage of the specification, to detect blunders and flaws, which, in turn, will facilitate work at the subsequent stages of the life cycle.

For the purpose of specifying systems in structural analysis, three groups of funds illustrating are used:

* functions that the system must perform;

* relationships between data;

* time-dependent behavior of the system (aspects of real time).

For this apply:

* DFD (Data Flow Diagrams) - data stream diagrams together with data dictionaries and processes specifications;

* ERD (Entity-Relationship Diagrams) - Diagrams Essence-Communications;

* STD (State Transition Diagrams) - status transition charts.

DFD shows external sources with respect to the system and data receivers, identifies logical functions (processes) and groups of data elements connecting one function from the other (streams), and also identifies the storage (data storage devices) to which access is available. Data stream structures and determine their components are stored in the data dictionary. Each logical function can be detailed by the dfd of the lower level. When detailing is exhausted, go to the description of logic using the process specification.

The structure of each storage is described using ERD. If real-time DFD is complemented by means of a description of the system of behavior of the system, which are described using STD. These links are shown in the figure.

Interrelation of structural analysis

Designing a modular structure.The module is a separate functionally completed software unit that can be applied on its own, or be part of the program. Software is created on the basis of a modular structure consisting of separate modules.

The advantages of developing software using modules include the following:

1. Simplifies software design, since the complex and greater problem is easier to understand, breaking the CE into separate functional parts.
2. The possibility of organizing the collaboration of large developers teams, as each programmer is dealing with independent of others by a module or a group of modules.
3. The debugging programs is simplified, since limited access to the module and the unambiguousness of its external behavior eliminates the effect of errors in other modules on its operation.
4. The reliability of programs increases, since the relatively small size of the modules and, as a result, a small complexity, allow you to carry out more complete checks.

Constantine structural maps are used to design and document the modular structure (Constantine), which are the relationship model between software modules.

The structural card is a oriented graph. Structural card nodes correspond to modules and data areas, and arcs depict intermodule challenges. At the same time, cyclic and conventional challenges are simulated by special nodes tied to arcs.

Elements of structural cards.

The basic element of the structural card is the module. You can select various types of modules:

1. The module itself is used to represent the processing fragment of software and to localize it in the diagram.

2. Subsystem - a set of previously defined modules. Any number of times on any diagrams can be reused.

3. The library differs from the subsystem by the fact that is determined outside the context of the system.

4. The data area is used to specify modules containing areas of global (distributed) variables.

Types of modules on structural maps.

When building structural maps, adding modules and linking them together using threads demonstrating challenge hierarchy. There are sequential and parallel calls. With a serial call, the modules can be called in any order or simultaneously.

Conditional and iterative nodes are used to model conditional and cyclic calls.

Images of conditional and iterative calls.

Typical modular structures.Depending on the tasks solved by the developer, and from the selected design method, the modular software can have one of the following basic structures: monolithically modular; sequentially - modular; modular - hierarchical; Modular - chaotic.

a - monolithic; b - sequential; in - hierarchical; G is chaotic.

Monolithically, the modular structure includes a large software module that implements most of the functions assigned to the program. From this part there is a minor number of appeals to other software modules of significantly smaller. Such a structure bears all the disadvantages of the uncommunicable principle of programming: it is complex for understanding, checking and maintaining.

Sequentially - the modular structure includes several consecutive control of the modules in each other. This structure is simple and visual, but can only be implemented for relatively simple tasks.

Modular - hierarchical structure includes software modules located at different levels of hierarchy. Modules upper levels Manage the operation of the low level modules. Such a structure is most preferable and allows you to build enough complex programs.

Modular - chaotic structures. Such programs are complex for verification and maintenance. This structure is permissible only in real-time systems with rigid volume-time characteristics, when using programs with another structure it is impossible to achieve them.

General rules for structural construction software.On the initial stages The development of software is formed by its structure and general rules for the interaction of components, which are as follows:

• the structure of the software and rules for designing each program module must be unified;
• each module is characterized by functional finishes, autonomy and independence in the design of the modules that it is used and which it causes;
• applied standard rules Organization of communication and information management module (data) with other modules;
• Software is developed in the form of a set of small operators (up to 100) software modules associated with a hierarchical manner;
• there must be no effect after the next execution of the program for subsequent execution;
• the use of local variables and computer registers is regulated.

Life cycle standards for

• GOST 34.601-90.
• ISO / IEC 12207: 1995 ( russian analogue - GOST R ISO / IEC 12207-99)

Standard GOST 34.601-90

Iterative model

An alternative to the consistent model is the so-called model of iterative and incremental development (English. iTERATIVE AND INCREMENTAL DEVELOPMENT, IID ) who also received from T. Gilb in the 70s. name evolutionary model. Also this model is called iterative model and incremental model .

The IID model involves the splitting of the project's life cycle on the sequence of iterations, each of which resembles a "mini-project", including all processes of development in the application to create smaller fragments of functionality, compared with the project as a whole. The purpose of each iteration - Obtaining a working version of a software system that includes functionality defined by the integrated content of all previous and current iteration. The result of the final iteration contains all the required functionality of the product. Thus, with the completion of each iteration, the product receives increment - increment - to its capabilities that, therefore, develop evolutionary. Iterativeness, incremental and evolutionaryness in this case is the expression of the same meaning different words with slightly different points vision.

By expressing T. Gilba, "Evolution - a reception designed to create the visibility of stability. Chances of successful creation complex system It will be maximal if it is implemented in a series of small steps and if each step contains a clearly defined success, as well as the possibility of "rollback" to the previous successful stage in case of failure. Before putting into the case, all resources intended to create a system, the developer has the ability to receive feedback signals from the real world and correct possible errors in the project. "

IID's approach has its own negative sides, which, in essence, - back side advantages. First, a holistic understanding of the possibilities and restrictions of the project is very for a long time absent. Secondly, the iterations have to discard the part of the work done earlier. Thirdly, the conscientiousness of specialists during the performance of work is still reduced, which is psychologically explainable, because the feeling constantly brings them on them that "all the same can be removed and improved later."

Various options iterative approach is implemented in most modern methodologies Development (RUP, MSF,).

Spiral model

Each iteration corresponds to the creation of a fragment or version of software, it specifies the objectives and characteristics of the project, the quality of the results obtained is estimated and the work of the next iteration is planned.

Each iteration is estimated:

• the risk of exceeding the timing and cost of the project;
• the need to fulfill another iteration;
• the degree of completeness and accuracy of understanding the requirements for the system;
• the feasibility of termination of the project.

It is important to understand that the spiral model is not an alternative to the evolutionary model (IID model), but a specially developed option. Unfortunately, the spiral model is often either mistakenly used as a synonym for an evolutionary model in general, or (no less erroneously) referred to as a completely independent model along with IID.

A distinctive feature The spiral model is special attention paid to the risks affecting the organization of the life cycle, and control points. BoEM formulates the 10 most common (on prioritizing) risks:

1. Deficit professionals.
2. Unrealistic time and budget.
3. Implementation of inappropriate functionality.
4. Developing an incorrect user interface.
5. Perfectionism, unnecessary optimization and exhausting parts.
6. Invertible change of change.
7. Lack of information on external components that determine the environment of the system or involved in integration.
8. Disadvantages in the works performed by external (with respect to the project) resources.
9. Insufficient performance of the resulting system.
10. Relief in the qualifications of specialists from different areas.

In today's spiral model, the next general set of test points is defined:

1. Concept of Operations (COO) - System Concept (use);
2. Life Cycle Objectives (LCO) - goals and life cycle content;
3. LIFE CYCLE ARCHITECTURE (LCA) - Life Cycle Architecture; It is also possible to talk about the readiness of the conceptual architecture of the target program system;
4. INITIAL OPERATIONAL CAPABILITY (IOC) is the first version of the product being created, suitable for experienced operation;
5. Final Operational Capability (FOC) is a finished product, deployed (installed and configured) for real exploitation.

Methodology of software development

• Microsoft Solutions Framework (MSF). Includes 4 phases: analysis, design, development, stabilization involves the use of object-oriented modeling.
• Extreme programming (eng. EXTREME PROGRAMMING, XP). At the heart of the teamwork, effective communication between the customer and the Contractor during the entire project to develop IP. Development is carried out using successively refined prototypes.
• ECPD - Complex of state standards Russian Federationestablishing interrelated rules for the development, design and circulation of programs and software documentation.

Literature

• Bratischenko V.V. Design information systems. - Irkutsk: Publishing House BSUEP, 2004. - 84 p.
• Venndrov A.M. Designing software of economic information systems. - m.: Finance and statistics, 2000.
• Grekul V.I., Denischenko G.N., Korovkina N.L. Design information systems. - m .: Internet University of Information Technologies - Intuit.ru, 2005.
• Mishenine A.I. Theory of Economic Information Systems. - m.: Finance and statistics, 2000. - 240 s.

Notes

Wikimedia Foundation. 2010.

Watch what is a "life cycle of software" in other dictionaries:

The period of development and operation of software in which the steps are usually distinguished: 1 appearance and study of the idea; 2 analysis of requirements and design; 3 programming; 4 Testing and debugging; 5 Entering the program; 6 ... ... Financial vocabulary

software Life Cycle - … Technical translator directory

software Life Cycle - 3.7 Software Life Cycle; Software LifeCycle (Software LifeCycle): The sequence of the following functions of creating and using software programmable-related building or ... ...

software Life Cycle - The sequence of the following processing and use of software occurring during the time interval, which begins with the development of the overall concept of software and ends when ... ... Complex security and antiterrorist protection of buildings and structures

Software Cycle Life - Software LifeCycle Software: Time period of time: Development of software requirements, software development, encoding, testing, integration, installation, and ... ... Official terminology

life cycle - 4.16 Life cycle (Life Cycle): the development of the system, product, services, projects or other objects manufactured by the person, starting from the development stage of the concept and ending with the termination of the application. A source … Dictionary directory terms of regulatory and technical documentation

This is the process of its construction and development. The life cycle of the information system The period of time that begins from the moment the decision is made on the need to create an information system and ends at the time of its complete seizure of ... ... Wikipedia

The life cycle of the information system is the process of its construction and development. The life cycle of the information system is the period of time that begins from the moment of making a decision on the need to create an information system and ends in ... ... Wikipedia, O. V. Kazarin. The book discusses theoretical and applied aspects of the problem of software sewn from various kinds of malicious actions. Special attention is paid to models and methods of creating ...

Life cycle standards for

• GOST 34.601-90.
• ISO / IEC 12207: 1995 (Russian analogue - GOST R ISO / IEC 12207-99)

Methodology of software development

• Rational Unified Process (RUP).
• Microsoft Solutions Framework (MSF). Includes 4 phases: analysis, design, development, stabilization involves the use of object-oriented modeling.
• Extreme programming ( Extreme Programming, XP). At the heart of the teamwork, effective communication between the customer and the Contractor during the entire project to develop IP. Development is carried out using successively refined prototypes.

Standard GOST 34.601-90.

GOST 34.601-90 provides for the following stages and steps of creating an automated system:

1. Formation of requirements for speakers
   1. Survey of the object and the rationale for the creation of the AC
   2. Formation of user requirements for ac
   3. Registration of the report on the performance of work and the application for the development of the AC
2. Development of the concept of AC.
   1. Learning object
   2. Conducting the necessary research work
   3. Development of the AC concept options and select the option of the AU concept that meets user requirements
   4. Registration of the report on the work done
3. Technical task
   1. Development and approval of the technical assignment to the creation of the AC
4. Preliminary design
   1. Development of preliminary project decisions on the system and its parts
5. Technical project
   1. Development of design solutions on the system and its parts
   2. Development of documentation on the AC and its part
   3. Development and registration of documentation for the supply of components
   4. Development of design tasks in adjacent parts of the project
6. Working documentation
   1. Development of working documentation on the AC and its part
   2. Development and adaptation of programs
7. Commissioning
   1. Preparation of an automation object
   2. Preparation of personnel
   3. Complete set of products supplied by products (software and technical means, software and technical complexes, information products)
   4. Construction and installation work
   5. Commissioning works
   6. Preliminary testing
   7. Experimental exploitation
   8. Acceptance tests
8. Accompanying speakers.
   1. Working in accordance with warranty obligations
   2. Post-warranty service

Sketch, technical projects and working documentation are a consistent construction of increasingly accurate design solutions. It is allowed to exclude the stage of the "sketch project" and the individual stages of work at all stages, to combine the "Technical Project" and "Working Documentation" stages in the Project Technology, in parallel to perform various stages and works, including additional.

This standard is not fully suitable for developing currently: many processes are not reflected enough, and some provisions are outdated.

ISO / IEC 12207 standard / and its application

ISO / IEC 12207: 1995 "Information Technology - Software Life Cycle Processes" is a basic regulatory document regulating the composition of the processes of the software life cycle. It defines the structure of a life cycle containing processes, actions and tasks that must be performed during the creation of software.

Each process is divided into a set of actions, each action - to a set of tasks. Each process, action or task is initiated and performed by another process as needed, and there are no pre-defined execution sequences. Input data links are preserved.

Life cycle processes for

• Main:
  • Acquisition (actions and tasks of the customer purchasing software)
  • Supply (actions and tasks of the supplier who supplies the customer with a software product or service)
  • Development (actions and tasks performed by the developer: the creation of software, project and operational documentation, preparation of test and educational materials, etc.)
  • Operation (actions and objectives of the operator - organization operating system)
  • Escort (actions and tasks performed by the accompanying organization, that is, the maintenance service). Accompanying - Changes in software for correcting errors, improving performance or adaptation to the changed working conditions or requirements.
• Auxiliary
  • Documentation (Formalized description of information created during the LCD)
  • Configuration management (administrative and technical procedures All over the extent of the ELC to determine the state of the components of software, controlling its modifications).
  • Quality assurance (providing guarantees that IC and the processes of its LCC meet the specified requirements and approved plans)
  • Verification (determining the fact that software products that are the results of some action fully meet the requirements or conditions due to previous actions)
  • Certification (determination of the completeness of compliance of the specified requirements and the system created by their specific functional purpose)
  • Joint estimate (assessment of the status of work on the project: control of planning and management of resources, personnel, equipment, instrumental means)
  • Audit (definition of compliance with the requirements, plans and conditions of the contract)
  • Permission of problems (analysis and solving problems, regardless of their origin or source, which are found during the development, operation, maintenance or other processes)
• Organizational
  • Control (actions and tasks that can be performed by any party controlling their processes)
  • Creating infrastructure (choice and maintenance of technology, standards and tools, selection and installation of hardware and software used for the development, operation or maintenance of software)
  • Improvement (Evaluation, Measurement, Control and Improvement of the ECC Processes)
  • Education (initial training and subsequent continued staff training)

Each process includes a number of actions. For example, the acquisition process covers the following actions:

1. Initiation of the acquisition
2. Preparation of applications
3. Preparation and adjustment of the contract
4. Supervision of the Supplier
5. Acceptance and completion of work

Each action includes a number of tasks. For example, the preparation of applications should include:

1. Formation of system requirements
2. Forming a list of software products
3. Establishment of conditions and agreements
4. Description of technical restrictions (environment of the system and so on.)

Stages of the software life cycle, the relationship between processes and stages

Life cycle model for - Structure that defines the sequence of the implementation and interconnection of processes, actions and tasks throughout the life cycle. The model of the life cycle depends on the specifics, scale and complexity of the project and the specifics of the conditions in which the system is created and functions.

The standard GOST R ISO / IEC 12207-99 does not offer a specific model of life cycle. Its provisions are common for any models of the life cycle, methods and technologies for creating IP. It describes the structure of the life cycle processes without specifying how to implement or perform actions and tasks included in these processes.

Model ZHC software includes:

1. Stage;
2. The results of work at each stage;
3. Key events - completion points of work and decision-making.

Stage - Part of the process of creating software, limited to certain temporary frameworks and ending with the release of a particular product (models, software components, documentation), determined by the requirements specified for this stage.

At each stage, several processes defined in the GOST R ISO / IEC 12207-99 standard can be performed, and vice versa, the same process can be performed on different stages. The ratio between processes and stages is also determined by the software model model used.

Life Cycle Models

The structure of the life cycle is understood as a structure that determines the sequence of the implementation and interconnection of processes, actions and tasks performed throughout the life cycle. The life cycle model depends on the specifics of the information system and the specifics of the conditions in which the latter is created and operates

To date, the following basic models of the life cycle obtained the most largest distribution:

• A task model;

• cascade model (or systematic) (70-85);

• spiral model (present).

Task model

When developing a "bottom-up" system from individual tasks to the entire system (task model), a single trip to the development is inevitably lost, problems arise with the information docking of individual components. As a rule, as the number of tasks increases, the difficulty increases, it is necessary to constantly change existing programs and data structures. The speed of the system is slowed down, which slows down and the development of the organization itself. However, in some cases, such technology may be appropriate:

• Extreme urgency (it is necessary that at least somehow tasks are solved; then you have to do everything again);

• Experiment and adaptation of the Customer (not clear algorithms, solutions are fascinated by trial and error).

General conclusion: a fairly large efficient information system is impossible to create in this way.

Cascading model

Cascading model The life cycle was proposed in 1970 Winston Royce. It provides for a sequential execution of all stages of the project in a strictly fixed order. The transition to the next step means the complete completion of the work at the previous stage (Fig. 1). The requirements defined in the formation stage of the requirements are strictly documented in the form of a technical task and recorded for the development of the project. Each stage is completed by the release of a full documentation set, sufficient to ensure that the development can be continued by another developer team.

The positive aspects of the cascade approach are as follows:

• at each stage, a complete set of project documentation is formed, which meets the criteria of completeness and consistency;

• the stages of work performed in the logical sequence allow you to plan the deadlines for the completion of all work and the corresponding costs.

Stages of the project in accordance with the cascadal model:

1. Formation of requirements;
2. Design;
3. Implementation;
4. Testing;
5. Implementation;
6. Operation and maintenance.

Fig. 1. Cascade Development Scheme

The cascade approach has proven itself when building information systems for which at the very beginning of development can be quite accurate and fully formulate all the requirements in order to provide developers with freedom to realize them as much as possible from a technical point of view. This category includes complex settlement systems, real-time systems and other similar tasks. However, during the use of this approach, a number of its shortcomings were found, primarily due to the fact that the real process of creating systems was never fully fitted in such a tough scheme. In the process of creating a need to return to previous stages and clarification or revising the previous decisions. As a result, the actual software creation process took the following form (Fig. 2):

Fig. 2. The real process of developing software for a cascade scheme

The main disadvantage of a cascade approach is essential delay to obtain results. The coordination of the results with users is made only at points planned after the completion of each stage of work, the requirements for information systems are frozen in the form of a technical task for the entire time of its creation. Thus, users can make their comments only after the work on the system is fully completed. In case of inaccurate presentation of the requirements or their changes over a long period of software creation, users receive a system that does not satisfy their needs. Models (both functional and informational) automated object can be ended simultaneously with their statement. The essence of the system approach to developing the IP is to decomposition (partition) on automated functions: the system is divided into functional subsystems, which in turn are divided into subfunctions divided into tasks and so on. The partitioning process continues to specific procedures. In this case, the automated system retains a holistic representation in which all components are interconnected. Thus, this model has main advantages of development, and the main disadvantages are slow and expensive.

Spiral model

To overcome the listed problems, it was proposed spiral model The life cycle (Fig. 3), which was developed in the mid-1980s Barry Baem. It is based on the initial stages of the life cycle: analysis and design. At these stages, the realizability of technical solutions is checked by creating prototypes.

Prototype - acting component Software that implements individual functions and external interfaces. Each iteration corresponds to the creation of a fragment or version of software, it specifies the objectives and characteristics of the project, the quality of the results obtained is estimated and the work of the next iteration is planned.

Each iteration is a complete development cycle, which leads to the release of an internal or external version of the product (or subset of the final product), which is improved from iteration to iteration to become the completed system.

Each round of the spiral corresponds to the creation of a fragment or software version, it is specified by the goals and characteristics of the project, its quality is determined and the work of the next spiral turn is planned. Thus, the details of the project are deepened and consistently specifically specified and the reasonable option is selected, which is brought to implementation.

Weterative development reflects an objectively existing spiral cycle of creating a system. An incomplete completion of work at each stage allows you to move to the next step, without waiting for the full completion of work on the current. With an iterative way to develop, the missing work can be performed in the next iteration. The main task is to show users a workable product as soon as possible, thereby activating the refinement process and additions.

The main problem of the spiral cycle is to determine the moment of transition to the next step. To solve it, it is necessary to introduce temporary restrictions on each of the stages of the life cycle. The transition is carried out in accordance with the plan, even if not all planned work is completed. The plan is drawn up on the basis of statistical data obtained in previous projects, and personal experience developers.

Figure 3. Spiral model LCC

One of the possible approaches to the development of software in the framework of the spiral model of the life cycle is the resulting lately Wide distribution Methodology for quick development of RAD application (RAPID Application Development). Under this term, the process of developing software containing 3 elements is usually understood:

• a small team of programmers (from 2 to 10 people);

• short but carefully worked out production schedule (from 2 to 6 months);

• a repeated cycle, in which the developers, as an application begins to acquire the form, request and implement the requirements obtained through the interaction with the customer.

The life cycle of the RAD methodology consists of four phases:

• phase of determining requirements and analysis;

• design phase;

• phase of implementation;

• phase introduction.

Each iteration is estimated:

• the risk of exceeding the timing and cost of the project;
• the need to fulfill another iteration;
• the degree of completeness and accuracy of understanding the requirements for the system;
• the feasibility of termination of the project.

Advantages of an iterative approach:

• Iterative development will significantly simplify the introduction of changes to the project when changing the requirements of the customer.
• When using a spiral model, individual elements of the information system are integrated into a single whole gradually. In an iterative approach, integration is carried out actually continuously. Since integration begins with a smaller number of items, it arises much less problems when it is conducted (according to some estimates, when using a cascade development model, integration takes up to 40% of all costs at the end of the project).
• Iterative development provides greater flexibility in project management, allowing the possibility of making tactical changes to the product being developed.
• The iterative approach simplifies the reuse of components (implements a component approach to programming). This is due to the fact that it is much easier to identify (identify) general parts of the project, when they are already partially designed than trying to allocate them at the very beginning of the project. The project analysis after several initial iterations allows you to identify general multi-time components used, which will be improved on subsequent iterations.
• The spiral model allows you to get a more reliable and stable system. This is due to the fact that as the error system is developed and weak spots Detected and corrected on each iteration. At the same time, critical efficiency parameters can be corrected, which in the case of a cascade model is available only before the system is deployed.
• An iterative approach makes it possible to improve the development process - the analysis carried out at the end of each iteration allows us to evaluate what should be changed in the development organization, and improve it in the next iteration.