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

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

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

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

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

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

Software products with a short lifespan

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

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

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

Software products with a long service life

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

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

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

I. System analysis:

a) research;

b) feasibility study:

operational;

Economic;

Commercial.

II. Software design:

a) design:

Functional decomposition of the system, its architecture;

External software design;

Database design;

Software architecture;

b) programming:

Internal software design;

External design of software modules;

Internal design of software modules;

Coding;

Debugging programs;

Program layout;

c) software debugging.

III. Evaluation (testing) of software.

IV. Software use:

a) operation;

b) support.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This phase of life covers different kinds project activity and can be divided into three main stages: design, programming and debugging of a software product.

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

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

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

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

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

Database design, if necessary;

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

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

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

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

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

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

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

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

It goes on just as long as programming.

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

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

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

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

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

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

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

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

Software maintenance consists in maintenance, development functionality and raising performance characteristics many software products, in replication and transfer of a software product to different types computing means.

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

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

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

Overlap between software product lifecycle phases

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

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

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

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

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

Topic: Classical and flexible models of LCPP: definition, description, distinctive features, the sequence of steps. Methods for choosing a model of the ZhCPP in the development of software in various subject areas.

Models and stages of software life cycle

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

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

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

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

1. formation of software requirements;
2. design (development of a system project);
3. implementation (can be broken down into sub-steps: detailed design, coding);
4. testing (can be broken down into stand-alone and complex testing and integration);
5. commissioning (implementation);
6. operation and maintenance;
7. decommissioning.

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

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

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

1. Planning work ahead of the project. The main tasks of the stage are the definition of development goals, preliminary economic evaluation project, building a schedule of work, creating and training a joint working group.
2. Conducting a survey of the activities of an automated organization (object), within the framework of which a preliminary identification of requirements for the future system is carried out, determining the structure of the organization, determining the list of target functions of the organization, analyzing the distribution of functions by departments and employees, identifying functional interactions between departments, information flows within departments and between them , external to the organization of objects and external information influences, analysis of existing means of automation of the organization's activities.

Building a model of the activity of an organization (object), which provides for the processing of survey materials and the construction of two types of models:

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

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

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

The design stage includes the following steps.

1. Development of a software system project. At this stage, the answer to the question "What should the future system do?" is given, namely: the architecture of the system, its functions, external conditions of operation, interfaces and distribution of functions between users and the system, requirements for software and information components, composition of performers and deadlines are determined. development, software debugging plan and quality control.

   The basis of the system project is the models of the designed system, which are built on the "TO-BE" model. The result of the development of a system project should be an approved and confirmed specification of software requirements: functional, technical and interface specifications, for which their completeness, verifiability and feasibility are confirmed.

2. Development of a detailed (technical) project. At this stage, the actual software design is carried out, including the design of the system architecture and detailed design. Thus, the answer to the question is given: "How to build a system so that it satisfies the requirements?"

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

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

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

Implementation stage – execution of the following works.

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

   External specifications must contain the following information:

   • module name - the name used to call the module is indicated (for a module with several inputs, there must be separate specifications for each input);
   • function - defines the function or functions performed by the module;
   • list of parameters (number and order) passed to the module;
   • input parameters - an exact description of all data returned by the module (the behavior of the module under any input conditions must be determined);
   • external effects (printing a message, reading a request from the terminal, etc.).
2. Module logic design and module programming (coding).
3. Checking the correctness of the modules.
4. Module testing.
5. Description of the database down to the level of individual parameters, symbols and bits.
6. Acceptance test plan.
7. User guide.
8. Preliminary plan for integration and debugging. The content of the subsequent stages basically coincides with the corresponding processes of the software life cycle. In general, technological stages are distinguished based on considerations of reasonable and rational planning and organization of work. A possible variant of the relationship and stages of work with the software life cycle processes is shown in the figure.

Rice. one.

Types of software life cycle models

Waterfall model (classic life cycle)

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

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

Advantages waterfall model:

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

The cascade approach has proven itself well in the construction of PS, for which at the very beginning of the project all requirements can be fully and clearly formulated. As long as all this is controlled by standards and various state acceptance commissions, the scheme works well.

Flaws waterfall model:

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

Iterative model of life cycle of PS

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

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

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

Prototyping

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

The model can take the following forms.

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

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

The sequence of actions for prototyping is shown in the figure. Prototyping begins with the collection and specification of requirements for the software system being created. The developer and the customer jointly define the goals of the software, establish which requirements are known and which are to be redefined. Then the rapid design is carried out. It focuses on features that should be visible to the user. Rapid design leads to the construction of a layout. The layout is evaluated by the customer and is used to clarify the software requirements. Iterations continue until the layout reveals all the requirements of the customer and enables the developer to understand what needs to be done.

The advantage of prototyping is the ability to ensure that complete system requirements are defined. Layout Disadvantages:

• the customer can take the layout for the product;
• the developer may mistake the layout for the product.

The shortcomings should be explained. When the customer sees a working version of the PS, he ceases to realize that in the pursuit of a working version of the PS, many quality issues and accompaniment convenience systems. When the developer tells the customer about this, the response may be indignation and a demand for the speedy transformation of the layout into a working product. This negatively affects the management of software development.

On the other hand, in order to quickly get a working layout, the developer often makes certain compromises. For example, inappropriate programming languages ​​may be used or operating system. For a simple demonstration, an inefficient (simple) algorithm may be used. After some time, the developer forgets about the reasons why these tools are not suitable. As a result, a far from ideal selected option is integrated into the system.

Before looking at other software life cycle models that have replaced waterfall model, one should dwell on the design strategies software systems. It is the software design strategy that largely determines the software life cycle model.

Software Design Strategies

There are three strategies for constructing software systems:

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

incremental model

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

The first increment results in a base product that implements the basic requirements (however, many auxiliary requirements remain unrealized). The plan for the next increment involves modifying the base product to provide additional features and functionality.

By its nature, the incremental process is iterative, but unlike breadboarding, the incremental model provides a working product at each increment.

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

Spiral software life cycle model

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

1. Planning is the definition of goals, options and constraints.
2. Risk analysis – analysis of options and risk recognition/selection.
3. Engineering is the next level of product development.
4. Evaluation - evaluation by the customer of the current design results.

Integrating aspect spiral model is obvious when considering the radial dimension of the helix. With each iteration, more and more full versions PS. In the first turn of the spiral, initial goals, options and constraints are defined, risk is recognized and analyzed. If the risk analysis reveals the uncertainty of the requirements, the prototyping used in the design quadrant comes to the aid of the developer and the customer.

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

In most cases, the spiral continues, with each step pushing developers towards a more general system model. Each loop in the spiral requires a construct (lower right quadrant), which can be implemented by a classic lifecycle or mockup. Note that the number of development activities (occurring in the lower right quadrant) increases as you move away from the center of the spiral.

These actions are numbered and have the following content:

1. – initial requirements gathering and project planning;
2. – the same work, but based on the recommendations of the customer;
3. – risk analysis based on initial requirements;
4. – risk analysis based on customer response;
5. – transition to an integrated system;
6. – initial layout of the system;
7. - the next level of the layout;
8. – designed system;
9. - Evaluation by the client.

Advantages spiral model:

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

Flaws spiral model:

• comparative novelty (there is no sufficient statistics on the effectiveness of the model);
• increased requirements for the customer;
• Difficulties in monitoring and managing development time.

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

However, this requires very large funds. Indeed, if earlier it was possible to create and dissolve groups of specialists as needed, now all of them must constantly participate in the project: architects, programmers, testers, instructors, etc. Moreover, the efforts various groups should be synchronized to reflect design decisions in a timely manner and make necessary changes.

Rational unified process

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

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

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

This figure shows two dimensions: the horizontal axis represents time and shows the temporal aspects of the process life cycle; the vertical axis represents the disciplines that define the physical structure of the process. You can see how the emphasis in the project changes over time. For example, early iterations spend more time on requirements; in later iterations, more time is devoted to implementation. The horizontal axis is formed from time periods - iterations, each of which is an independent development cycle; the purpose of the cycle is to bring some predetermined tangible refinement to the final product that is useful from the point of view of stakeholders.

Along the time axis, the life cycle is divided into four main phases.

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

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

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

1. Business analysis and modeling ( Business modeling ) provides the implementation of the principles of modeling in order to study the organization's business and accumulate knowledge about it, optimize business processes and make decisions about their partial or complete automation.
2. Requirements management is about taking information from stakeholders and transforming it into a set of requirements that define the content of the system being developed and detail the expectations of what the system should do.
3. Analysis and design (Analysis and design) covers the procedures for transforming requirements into intermediate descriptions (models) representing how these requirements should be implemented.
4. Implementation covers code development, developer-level testing, and integration of components, subsystems, and the entire system in accordance with established specifications.
5. Testing is devoted to assessing the quality of the product being created.
6. Deployment covers the operations that take place in delivering products to customers and making the product available to end users.
7. Configuration management and change management (Configuration management) is dedicated to synchronizing intermediate and final products and managing their development during the project and finding hidden problems.
8. Project Management is dedicated to project planning, risk management, project progress monitoring and continuous evaluation of key indicators.
9. Management environment (Environment) includes elements of the formation of the development environment information system and support for project activities.

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

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

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

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

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

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

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

In addition, Rational Software Architect supports model-driven development (MDD) technology, which allows you to model software at various levels of abstraction with traceability.

MSF (Microsoft Solution Framework)

In 1994, in an effort to get the most out of IT projects, Microsoft released a set of guidelines for effectively designing, developing, implementing, and maintaining solutions built on top of its technology. This knowledge is based on the experience gained by Microsoft working on large software development and maintenance projects, the experience of Microsoft consultants and the best of what has accumulated in this moment IT industry. All this is presented in the form of two interrelated and well complementary knowledge areas: Microsoft Solutions Framework (MSF) and Microsoft Operations Framework (MOF).

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

The most popular application variants of MSF developed by Microsoft are:

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

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

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

Creating a business solution within the allotted time and budget requires a proven methodological foundation. MSF provides proven methodologies for planning, designing, developing and implementing successful IT solutions. With its flexibility, scalability and lack of rigid guidelines, MSF is able to meet the needs of any size organization or project team. The MSF methodology consists of principles, models and disciplines for managing personnel, processes, technological elements and issues related to all these factors that are typical for most projects. MSF consists of two models and three disciplines. They are detailed in 5 whitepapers. It is better to start studying MSF with models (project team model, process model), and then move on to disciplines (project management discipline, risk management discipline, training management discipline).

The MSF process model represents a general methodology for the development and implementation of IT solutions. The peculiarity of this model is that, due to its flexibility and the absence of rigidly imposed procedures, it can be applied in the development of a very wide range of IT projects. This model combines the properties of two standard production models: cascade (waterfall) and spiral (spiral). The process model in MSF 3.0 has been further innovative: it covers the entire lifecycle of a solution, from its inception to implementation. This approach helps project teams focus on the business value of the solution, as that value becomes real only after implementation is complete and the product is in use.

The MSF process is focused on "milestones" - the key points of the project, characterizing the achievement within its framework of any significant (intermediate or final) result. This result can be evaluated and analyzed, which implies answers to the questions: "Did project group clear understanding of the goals and scope of the project?”, “Is the action plan sufficiently prepared?”, “Does the product meet the approved specification?”, “Does the solution meet the needs of the customer?”, etc.

The MSF process model takes into account constantly changing project requirements. It proceeds from the fact that the development of a solution should consist of short cycles that create a progressive movement from the simplest versions of the solution to its final form.

The features of the MSF process model are:

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

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

• concept development (Envisioning);
• planning (Planning);
• development (Developing);
• stabilization (Stabilizing);
• implementation (Deploying).

In addition, there is a large number of intermediate milestones that show the achievement of a certain progress in the course of the project and break down large segments of work into smaller, observable sections. For each phase of the process model, MSF defines:

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

Within MSF, code, documentation, designs, plans, and other working materials are usually created in an iterative manner. MSF recommends that you start developing a solution by building, testing, and deploying its core functionality. Then more and more features are added to the solution. This strategy is called a versioning strategy. While a single release may be sufficient for smaller projects, it is recommended that you do not miss the opportunity to create multiple versions for a single solution. With the creation of new versions, the functionality of the solution evolves.

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

A solution has no business value until it is implemented. It is for this reason that the MSF process model contains the entire life cycle of creating a solution, including its implementation, right up to the moment when the solution starts to deliver value.

Annotation.

Introduction.

1. Software life cycle

Introduction.

Riley Programming Process Steps

Introduction.

1.1.1. Formulation of the problem.

1.1.2. Solution design.

1.1.3. Algorithm coding.

1.1.4. Program support.

1.1.5. Software documentation.

Conclusion to paragraph 1.1

1.2. Definition of ZhTsPO according to Lehman.

Introduction.

1.2.1 System definition.

1.2.2. Implementation.

1.2.3. Service.

Conclusion to item 1.2.

1.3. Phases and Works of the Life Cycle Program according to Boehm

1.3.1. cascade model.

1.3.2. Economic substantiation of the cascade model.

1.3.3. Improvement of the cascade model.

1.3.4. Definition of life cycle phases.

1.3.5. Basic work on the project.

Literature.

Introduction

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

In the practice of developing large software projects, there is often no unified approach to the evaluation of labor costs, terms of work and material costs, which hinders the increase in productivity of software development, and ultimately the effective management of the software life cycle. Since a program of any kind becomes a product (except, perhaps, educational, mock-up programs), the approach to its production should be similar in many respects to the approach to the production of industrial products, and software design issues become extremely important. This idea underlies B.U. Boehm "Software Engineering Design", which we used to write this term paper. In this book, software design refers to the process of creating a design for a software product.

1 Software lifecycle

INTRODUCTION

LCPE is a continuous process that starts from the moment a decision is made on the need to create software and ends at the moment it is completely withdrawn from operation.

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

The most famous and complete, perhaps, is the structure of the life cycle according to Boehm, which includes eight phases. It will be presented in more detail later.

One of the possible options may be the description of the upper level according to Lehman, which includes three main phases and represents the description of the life cycle program in the most general case.

And, for a change, here are the steps of the programming process presented by D. Riley in the book “Using the Modula-2 Language”. This idea, in my opinion, is very simple and familiar, and we will start with it.

1.1 Riley Programming Process Steps

Introduction

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

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

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

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

program support, i.e. an ongoing process of fixing bugs in the program and adding new features.

Rice. 1.Four programming steps.

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

In the case of a large software project, the number of users, system analysts, and algorithms can be significant. In addition, it may be necessary to revert to previous steps due to unforeseen circumstances. All this serves as an additional argument in favor of careful software design: the results of each step should be complete, accurate and understandable.

1.1.1 Statement of the problem

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

Formulation of the problem (program specification); essentially means an accurate, complete, and understandable description of what happens when a particular program is executed. The user usually looks at the computer as a black box: it does not matter to him how the computer works, but it is important that the computer can do what the user is interested in. The focus is on the interaction between man and machine.

Characteristics of a Good Problem Statement:

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

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

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

Often the requirements for accuracy, completeness and clarity are in conflict. Thus, many legal documents are difficult to understand because they are written in a formal language that allows you to formulate certain provisions with the utmost precision, excluding even the most insignificant discrepancies. For example, some questions on exam papers are sometimes worded so precisely that the student spends more time understanding the question than answering it. Moreover, the student may not grasp the main meaning of the question at all due to the large number of details. The best problem statement is the one that achieves a balance of all three requirements.

The standard form of problem statement.

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

Such a statement does not satisfy the above requirements: it is neither precise, nor complete, nor understandable. Indeed, should the numbers be entered one per line, or all the numbers on one line? Does the expression "in order" mean ordering from largest to smallest, from smallest to largest, or the same order in which they were introduced.

It is obvious that such a statement does not answer many questions. If we take into account the answers to all questions, then the problem statement will become wordy and difficult to understand. Therefore, D. Riley proposes to use the standard form for setting the problem, which ensures maximum accuracy, completeness, clarity and includes:

task name (schematic definition);

general description (brief statement of the task);

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

example ( good example can convey the essence of the problem, as well as illustrate various cases).

Example. Statement of the problem in the standard form.

TITLE

Sort three integers.

DESCRIPTION

Input and output of three integers, sorted from smallest to largest.

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

The three entered integers are output, with all three displayed on the same line. Adjacent numbers are separated by a space. Numbers are displayed from smallest to largest, from left to right.

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

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

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

Software life cycle

The software life cycle is a period of time that begins from the moment a decision is made on the need to create a software product and ends at the moment of its complete withdrawal from operation. (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 the quality of software by optimal control development and use of various quality control mechanisms at each stage, from task setting to software authoring 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 (sketch) and detailed (technical) software design;

Development of software components, their integration and software debugging in general;

Testing, trial operation and replication of software;

Regular operation of the software, maintenance of operation and analysis of the results;

Maintenance of software, its modification and improvement, creation of new versions.

This model is generally accepted and corresponds to both domestic regulatory documents in the field of software development, and foreign. In terms of providing technological safety it is advisable to consider in more detail the features of the representation of the stages of the life cycle in foreign models, since it is foreign software that is the most likely carrier of software defects of the sabotage type.

Software Life Cycle Standards

GOST 34.601-90

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

Graphical representation of life cycle models allows you to visually highlight their features and some properties of processes.

Initially, a cascade model of the life cycle 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 the work at the previous stage. The requirements defined at the requirements formation stage are strictly documented in the form of terms of reference and fixed for the entire duration of the project development. Each stage culminates in the release of a complete set of documentation sufficient for development to be continued by another development team. The inaccuracy of any requirement or its incorrect interpretation as a result leads to the fact that you have to "roll back" to the early phase of the project and the required revision not only knocks the project team out of schedule, but often leads to a qualitative increase in costs and, it is possible, to the termination of the project in the form in which it was originally conceived. The main fallacy of the authors of the waterfall model is the assumption that the design goes through the whole process once, the designed architecture is good and easy to use, the design of the implementation is reasonable, and errors in the implementation are easily eliminated with testing. This model assumes that all errors will be concentrated in the implementation, and therefore their elimination occurs evenly during component and system testing. Thus, the waterfall model for large projects is not very realistic and can only be effectively used to create small systems.

The most specific is the spiral model of the life cycle. In this model, attention is focused on the iterative process of the initial stages of design. At these stages, concepts, requirements specifications, preliminary and detailed design are sequentially created. At each round, the content of the work is specified 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:

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

The need to perform another iteration;

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

The expediency 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, standardization of the most common 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 - Institute of Electrotechnical and Electronics Engineers) together with the American National Standards Institute (ANSI). The ISO/IEC and ANSI/IEEE standards are mostly advisory in nature. The third direction is stimulated by the US Department of Defense (Department of Defense-DOD). DOD standards are mandatory for firms working on behalf of the US Department of Defense.

For software design complex system, especially real-time systems, it is advisable to use a system-wide life cycle model based on the integration of all famous works under reviewed basic processes. This model is intended for use in planning, scheduling, 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 is carried out. The range of works, their complexity, duration and other characteristics at these stages depend significantly on the object and development environment. The study of such dependencies for different classes of software makes it possible to predict the composition and main characteristics of work schedules for new versions of software.

The second part of the life cycle, which reflects support for the operation and maintenance of software, is relatively weakly related to the characteristics of the object and development environment. The range of work at these stages is more stable, and their complexity and duration can vary significantly, and depend on the mass application of the software. For any model of life cycle provision High Quality software systems is possible only when using a regulated technological process at each of these stages. Such a process is supported by development automation tools, which it is advisable to choose from existing ones or create taking into account the development object and the list of works adequate to it.

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

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

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

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

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

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

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

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

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

Picture

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

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

Software development follows a specific life cycle.

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

a) obsolescence;

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

Technological approaches are mechanisms for implementing the life cycle.

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

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

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

Design

Implementation

Testing and Debugging

Implementation, operation and maintenance.

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

Processes

Design

Programming

Testing

Escort

Analysis Design Implementation Testing Implementation Operation

and debugging and maintenance

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

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

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

Implementation phase includes writing a program.

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

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

The purpose of standardizing the life cycle of complex PS:

Summarizing the experience and research results of many specialists;

Development of technological processes and development techniques, as well as a methodological basis for their automation.

Standards include:

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

Establish process control rules;

Establish requirements for the presentation of results;

Regulate the content of technological and operational documents;

Determine the organizational structure of the development team;

Provide distribution and scheduling of tasks;

Provide control over the progress of the creation of PS.

In Russia, there are standards governing the life cycle:

Software development stages - GOST 19.102-77

Stages of creating AS - GOST 34.601-90;

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

Types of test AS - GOST 34.603-92;

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

In this regard, the international standard ISO / IEC 12207-1999 - "Information technology - Software life cycle processes" should be noted.

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

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

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

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

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

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

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

2. Verification is the process of determining whether Current state software achieved on this stage, the requirements of this stage.

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

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

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

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

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

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

The development process in accordance with the standard provides for the actions and tasks performed by the developer, and covers the creation of software and its components in accordance with the specified requirements, including the preparation of design and operational documentation, as well as the preparation of materials necessary to check the operability and conformity of the quality of software products , materials needed for staff training, etc.

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

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

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

3) analysis of information system requirements - defining it

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

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

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

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

7) detailed software design - detailed

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

8) software coding -– development and documentation

each software component;

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

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

integration plan and software testing for compliance qualification requirements, which are a set of criteria or conditions that must be met in order to qualify a software product as conforming to its specifications and ready for use in given operating conditions;

11) software qualification testing – software testing in

the presence of the customer to demonstrate its compliance

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

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

13) IP qualification testing – system testing for

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

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

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

software and information system testing in general and

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

16) Management and development of documentation;

17) operation

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

software product.;

19) completion of operation.

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

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