Rice. 5.2.

These aspects are:

1. the contractual aspect, in which the customer and supplier enter into a contractual relationship and implement the procurement and delivery processes;
2. management aspect, which includes management actions of persons participating in the software life cycle (supplier, customer, developer, operator, etc.);
3. the operational aspect, which includes the actions of the operator to provide services to system users;
4. the engineering aspect, which contains the actions of the developer or support service to solve technical problems associated with the development or modification of software products;
5. aspect of support related to the implementation of supporting processes through which help desks provide necessary services to all other participants in the work. In this aspect, we can highlight the aspect of software quality management, which includes quality assurance processes, verification, certification, joint assessment and audit.

Organizational processes are carried out on corporate level or at the level of the entire organization as a whole, creating the basis for the implementation and continuous improvement of software life cycle processes.

5.6. Models and stages of software lifecycle

The software life cycle model is understood as a structure that defines the sequence of execution and relationships 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 offer a specific life cycle model and software development methods. Its provisions are general for any life cycle models, methods and software development technologies. The standard describes the structure of software life cycle processes, but does not specify how to implement or perform the actions and tasks included in these processes.

The life cycle model of any specific software determines the nature of the process of its creation, which is a set of works ordered in time, interconnected and combined into 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 a certain 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 that ends with 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-stages: detailed design, coding);
4. testing (can be broken down into stand-alone and integrated testing and integration);
5. commissioning (implementation);
6. operation and maintenance;
7. decommissioning.

Some experts introduce an additional initial stage - feasibility analysis systems. Here we mean a hardware and software system for which software is created, purchased or modified.

The stage of forming software requirements is one of the most important and determines to a significant (even decisive!) extent the success of the entire project. The beginning of this stage is the receipt of an approved and validated system architecture, including basic agreements on the distribution of functions between hardware and software. This document must also contain confirmation general idea on the functioning of the software, including basic agreements on the distribution of functions between a person and the system.

The stage of generating software requirements includes the following stages.

1. Work planning prior to work on the project. The main objectives of the stage are to determine development goals, preliminary economic assessment project, building a work schedule, creating and training a joint working group.
2. Conducting a survey of the activities of the automated organization (object), within the framework of which preliminary identification of requirements for the future system is carried out, determination of the structure of the organization, determination of the list of target functions of the organization, analysis of the distribution of functions among departments and employees, identification of functional interactions between departments, information flows within and between departments , objects external to the organization and external information influences, analysis of existing means of automating the organization’s activities.

Construction of a model of the activity of an organization (object), which involves processing survey materials and constructing two types of models:

• the “AS-IS” (“as is”) model, reflecting the current state of affairs in the organization at the time of the survey and allowing one to understand how the organization operates, as well as identify bottlenecks and formulate proposals for improving the situation;
• model "TO-BE" ("how it should be"), reflecting the idea of ​​​​new technologies for the organization.

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

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

The design stage includes the following stages.

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 functioning, interfaces and distribution of functions between users and the system, requirements for software and information components, composition of performers and development deadlines, software debugging plan and quality control.

   The basis of a system project is made up of models of the designed system, which are built on the “TO-BE” model. The result of the development of a system project must 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 is given to the question: "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, intermodular interfaces for data and control;
• specification of each software component, name, purpose, assumptions, dimensions, call sequence, input and output data, errors outputs, algorithms and logic circuits;
• formation of physical and logical data structures down to the level of individual fields;
• development of a plan for the distribution of computing resources (central processor time, memory, etc.);
• verification of completeness, consistency, feasibility and validity of requirements;
• preliminary plan for integration and debugging, plan for user manual and acceptance testing.

The completion of the detailed design stage is end-to-end

I. N. Skopin

The modeling of the software life cycle is considered as the basis for technological software development. Different approaches to life cycle modeling are presented, reflecting different ideas about the purpose of such modeling. The features of object-oriented life cycle modeling are described, including taking into account continuously incoming requirements for the project being developed.

Introduction

Life cycle concept software appeared when the programming community realized the need to move from artisanal methods of developing programs to high-tech industrial production. As usually happens in such situations, programmers tried to transfer the experience of other industrial productions into their field. In particular, the concept of life cycle was borrowed.

Software life cycle analogy with technical systems has deeper roots than it might seem at first glance. Programs are not subject to physical wear and tear, but during their operation errors (malfunctions) are discovered that require correction. Errors also arise from changes in the terms of use of the program. The latter is a fundamental property of software, otherwise it loses its meaning. Therefore it is legitimate to say about aging programs, although not about physical aging, but about moral aging.

The need to make changes to existing programs, both because of discovered errors and because of evolving requirements, essentially leads to the fact that software development continues after it is transferred to the user and throughout the entire life of the programs. The activities associated with solving the rather numerous problems of such ongoing development are called software maintenance(Fig. 1).

Rice. 1. Development, use and maintenance of software

Historically, the development of life cycle concepts is associated with the search for adequate models for it. Like any other, the life cycle model is an abstraction real process, in which details that are not significant from the point of view of the purpose of the model are omitted. The difference in the purposes for which models are used determines their diversity.

The main reasons for studying software life cycle modeling can be formulated as follows.

Firstly, this knowledge, even for a non-professional programmer, helps to understand what can be expected when ordering or purchasing software and what is unrealistic to demand from it. In particular, inconvenient aspects of working with the program, its errors and shortcomings are usually eliminated during ongoing development, and there is reason to expect that subsequent versions will be better. However, radical changes in program concepts are the task of another project, which will not necessarily be better than this system in all respects.

Secondly, life cycle models are the basis for knowledge of programming technologies and the tools that support them. A programmer always uses tools in his work, but a qualified programmer knows where, when and how to use them. This is where the concepts of life cycle modeling help: any technology is based on certain ideas about the life cycle, builds its methods and tools around the phases and stages of the life cycle.

Thirdly, general knowledge how a software project develops, provide the most reliable guidelines for its planning, allow you to use resources more economically, and achieve more high quality management. All this relates to the area professional responsibilities software project manager.

In this work, life cycle models are presented in a form that allows us to consider them, abstracting from the specifics of the development of specific software systems. Traditional models and their development adapted to the needs of object-oriented design are described.

1. Models of traditional representation
about life cycle

1.1. Generally accepted model

Probably the most common motive for referring to the concept of a life cycle is the need to systematize work in accordance with the technological process. This purpose is well suited to the so-called generally accepted model software life cycle, according to which software systems go through two stages in their development phases:

• development,
• accompaniment.

The phases are divided into a series stages(Fig. 2).

Rice. 2. Generally accepted software life cycle model

Development starts with need identification in a new application, and ends with the transfer of the development product into operation.

The first step of the development phase is problem statement and requirements definition. Defining requirements includes describing the overall context of the task, the expected functions of the system, and its limitations. At this stage, the customer, together with the developers, decide to create a system. This stage is especially important for non-traditional applications.

If the decision is positive, the stage begins system specifications according to requirements. Software developers try to understand the customer's requirements and capture them in the form of system specifications. It is important to emphasize that the purpose of these specifications is to describe external behavior the system being developed, not its internal organization, i.e. answer the question What she should do, not How it will be implemented. We are talking here about the purpose and not about the form of the specifications, since in practice, in the absence of a suitable specification language, unfortunately, it is often necessary to resort to the description “ What" through " How". Before starting to create a project according to specifications, they must be carefully checked for compliance with the original goals, completeness, compatibility (consistency) and unambiguity.

The problem with specification language is not that it is impossible (or difficult) to strictly and clearly describe what is required in the project. To a greater extent, they are associated with the need to achieve and maintain compliance with the description " What» unclear, imprecise and often contradictory requirements from people external to the project. There is no reason to believe that these people will be familiar with the "best specification language" and that they will care about the correctness of their requirements. The task of the specifications stage is to build the description of the program in the form of a logically verified system that is understandable both for the customer of this development, future users, and for the project implementers.

Development of design solutions that answer the question How the system must be implemented so that it can satisfy the specified requirements, is carried out at the stage design. Since the complexity of the system as a whole can be very large, the main task of this stage is the consistent decomposition of the system to the level obviously feasible modules or procedures.

At the next stage implementation, or coding Each of these modules is programmed in the language most suitable for a given application. From an automation point of view, this stage is traditionally the most developed.

In the model under consideration, the development phase ends with the stage testing(autonomous and integrated) and transfer systems in exploitation.

The operation and maintenance phase includes all activities to ensure the normal functioning of software systems, including fixing errors discovered during program execution, searching for their causes and correcting, improving performance characteristics systems, system adaptation to environment, as well as, if necessary, more significant work to improve the system. All this gives us the right to talk about system evolution. In this regard, the operation and maintenance phase is divided into two stages: the actual accompaniment And development. In some cases, this phase accounts for the majority of the funds spent during the software life cycle.

It is clear that the attention programmers pay to certain stages of development depends on the specific project. Often the developer does not need to go through all the steps, for example, if he is creating a small, well-understood program with a clear goal. Maintenance issues, poorly understood by developers of small programs for personal use, are at the same time very important for large systems.

This is brief description generally accepted model. In the literature there are many options that develop it in the direction of detail and the addition of intermediate phases, stages, stages and individual works(for example, on documentation and technological training projects) depending on the characteristics of software projects or the preferences of developers.

1.2. Classic iterative model

The generally accepted life cycle model is ideal because only very simple tasks progress through all stages without any iterations- return to previous steps technological process. When programming, for example, you may find that the implementation of a certain function is very cumbersome, inefficient, and conflicts with the performance required of the system. In this case, a redesign and perhaps a reworking of the specifications is required. When developing large non-traditional systems, the need for iterations arises regularly at any stage of the life cycle, both because of errors and inaccuracies made at previous steps, and because of changes in external requirements for the operating conditions of the system.

These are the motives classical iterative model life cycle (Fig. 3).

Rice. 3. Classic iterative model

Arrows pointing up indicate returns to previous steps, which qualify as a requirement to repeat the step to correct a detected error. In this regard, it may seem strange to move from the “Operation and Maintenance” stage to the “Testing and Debugging” stage. The fact is that complaints made during the operation of the system are often given in a form that requires them to be double-checked. To understand what errors are being referred to in the complaint, it is useful for developers to first reproduce the user situation at home, i.e. perform actions that are usually considered testing.

The classical iterative model makes absolute the possibility of returning to previous stages. However, this circumstance reflects an essential irresistible aspect software development, not based on object-oriented design: the desire to foresee in advance all situations of using the system and the impossibility in the vast majority of cases to achieve this. All traditional programming technologies are aimed only at minimizing returns. But this does not change the essence: when returning, you always have to repeat the construction of what was already considered ready.

The situation is different with object-oriented technologies. Refusal to complete phases and stages, instead of which it is proposed to distribute the increase in functionality and interface capabilities over iterations, allows us to weaken the requirement to rework the old when returning. Essentially, the classical scheme remains true, but only within one iteration and with one important amendment: everything useful that was done earlier is preserved. It is clear that for a software system as a whole, a new approach also requires new life cycle models that reflect its features noted earlier. This will be discussed after studying the main options for traditional life cycle models.

1.3. Cascade model

Some stricter variety classic model is the so-called cascade model, which can be considered as an illustrative example of what methods can be used to minimize returns.

Characteristics cascade model:
• completion of each stage (they are almost the same as in the classical model) by checking the results obtained in order to eliminate as many problems associated with product development as possible;
• cyclical repetition of completed stages (as in the classical model).

The motivation behind the cascade model is related to the so-called quality management software. In connection with it, the concepts of stages are clarified, some of them are structured (requirements specification and implementation).

In Fig. Figure 4 shows a diagram of the cascade model, built as a modification of the classical iterative model. Each block denoting a stage indicates the action with which the stage ends (the names of these actions are marked with a gray background). It can be seen from the figure that in this model testing is not identified as a separate stage, but is considered only a threshold that must be crossed to complete the stage, just like other similar actions.

Rice. 4. Cascade model

According to the cascade model, completion of the definition phase system requirements includes recording them in the form of special documents called reviews what is required from the system (description of functions), and the specification of program requirements is confirmation implementation of the functions recorded in the reviews in the programs planned for implementation. In addition, confirmation is assumed at the first stage, i.e. after defining the requirements. This reflects the fact that the received requirements must be agreed upon with the customer.

Design result verified, i.e. it is verified that the adopted system structure and implementation mechanisms ensure the feasibility of the specified functions.

Implementation is controlled by testing component, and after integrating the component into the system and comprehensive debugging, certification, i.e. verification and recording of actually implemented system functions, description of implementation limitations, etc.

During the operation and maintenance of the product, it is established how well the system meets user requests, i.e. carried out recertification.

Each of these checks can send system developers to repeat any of the previously completed stages, as illustrated by the arrows in Fig. 4. At the same time, the cascade model was developed in response to the requirement of the practice of developing software projects, in which, by overcoming verification barriers, minimizing returns to the completed stages is achieved. Such minimization is possible not only in terms of the number of rollbacks according to the scheme: by tightening checks, developers are trying to eliminate direct refunds through several stages. The corresponding circuit, called strict cascade model, is shown in Fig. 5.

Rice. 5. Strict cascading model

It is instructive to see how early errors are corrected in a strict waterfall model. In accordance with this scheme, developers of any stage as starting materials for its activities, i.e. development tasks, receive the results of the previous stage, which have passed the appropriate check (ideally, the performers of the stage may not be aware of the earlier stages at all). During the work of the stage, it may be found that the task is impossible for one of the following reasons:

• it is contradictory, i.e. contains inconsistent or impossible requirements;
• criteria have not been developed for choosing one of possible options solutions.

Both situations qualify as job errors, i.e. as errors of the previous stage. To correct detected errors, the work of the previous stage is resumed. As a result, errors are either eliminated or the impossibility of their immediate correction is stated. In the first case, the work of the stage that caused the return is resumed with the corrected task. The second case is qualified as an error at an earlier stage.

A strict cascade model captures two important points in the life cycle:
• precise division of work, tasks and responsibilities of stage developers and those who, by checking the work, initiate the transition to the next stage;
• small cycles between adjacent stages, as a result of which a compromise task is achieved.

The first point is a step towards understanding the actual division of labor, from which an explicit separation of technological and organizational functions performed at each stage. As a result, it becomes possible to set the task of automated support for these functions. The second point can be interpreted as the joint implementation of work at adjacent stages, i.e. their overlap. However, within the framework of the cascade model, these circumstances are reflected only indirectly. The effectiveness of explicitly including them as elements of the life cycle model is demonstrated in the next section.

1.4. Phase-function model

An extremely important motivation for the development of software life cycle models is the need for a suitable tool for integrated management project. Essentially, this statement indicates that the model should serve as a basis for organizing relationships between developers, and thus one of its purposes is to support managerial functions. This leads to the need to impose control points and functions on the model that define the organizational and time frame of the project.

Most consistently, this addition to the classical scheme is implemented in the Gunter model in the form of a “phase-function” matrix. Already from the mention of the matrix it follows that Gunter’s model has two dimensions:

• phase, reflecting the stages of the project and accompanying events;
• functional, showing what organizational functions are performed during the development of the project and what their intensity is at each stage.

Gunter's model reflects that the performance of a function at one stage can continue at the next. In Fig. Figure 6 shows the phase measurement of the model. The thick line (with a break and an arrow indicating the time direction) depicts the development process. Checkpoints and event names are indicated below this line. They are numbered. All project development in the model is tied to these milestones and events.

Rice. 6. Phase measurement of the phase-function model

In this model, the life cycle is divided into the following overlapping phases (stages):
• research- the stage begins when the need for development is recognized by the project management (checkpoint 0), and consists of justifying the required resources for the project (checkpoint 1) and formulating the requirements for the product being developed (checkpoint 2);
• feasibility analysis- begins in the research phase, when project implementers are identified (checkpoint 1), and ends with the approval of requirements (checkpoint 3). The purpose of the stage is to determine the possibility of designing a product from a technical point of view (whether there are enough resources, qualifications, etc.), whether the product will be convenient for practical use, to answer questions of economic and commercial efficiency;
• design- the stage usually begins at the feasibility analysis phase, as soon as the preliminary goals of the project are documented (checkpoint 2), and ends with the approval of design solutions in the form of a formal specification for the development (checkpoint 5);
• programming- Begins during the design phase when basic specifications for individual product components become available (milestone 4), but not before the approval of the requirements agreement (milestone 3). Combining this phase with the final design stage provides rapid verification of design solutions and some key development issues. The purpose of the stage is the implementation of component programs with subsequent assembly of the product. It ends when the developers complete documentation, debugging and assembly and hand over the product to a service that performs an independent evaluation of the results of the work (independent testing has begun - checkpoint 7);
• grade- the phase is a buffer zone between the start of testing and the practical use of the product. It begins as soon as internal (by the developers) tests of the product are carried out (checkpoint 6) and ends when the product’s readiness for operation is confirmed (checkpoint 9);
• usage- begins during the transfer of the product for distribution and continues while the product is in operation and intensively used. The stage is associated with implementation, training, configuration and support, possibly with upgrading the product. It ends when the developers cease systematic activities to maintain and support the software product (checkpoint 10).

During the life cycle phases, developers perform the following technological (organizational) functions (classes of functions):
• planning,
• development,
• service,
• release of documentation,
• tests,
• support,
• accompaniment.

The listed functions at different stages have different contents and require different intensity, but, what is especially important for the model, they are combined during the implementation of the project. This is a functional dimension of the model, the superposition of which on the phase dimension gives an image of the matrix of phase functions as a whole (see Fig. 7, in which the intensity of the functions performed is reflected by the density of shading of the matrix cells).

The composition of organizational functions and their intensity may vary from project to project depending on its characteristics, on what the project management considers to be main or secondary. For example, if the initial qualifications of the team are not very high, staff training can be added to the list of functions. Sometimes it is important to distinguish between planning and control (according to Gunter, control functions are not clearly distinguished). With object-oriented design, the role of modeling increases so much that it is advisable to transfer it from the category of design methods to an explicitly designated technological function, which will be discussed below.

The model takes into account the relationship between technological functions and life cycle phases, which is how it compares favorably with the simple (or limited?) previously considered “ideal” models. Apparently, the simplicity and limitation of “ideal” models is a consequence of identifying the identified stages with the technological operation that prevails in their implementation. At the same time, the task of reflecting iterativity is not explicitly provided for in the Gunter model. Although the mere overlap of adjacent project phases and the release of documentation corresponding to events is a way to minimize returns to completed stages, more meaningful means of describing iterations are not included in the model.

Rice. 7. Phase-function matrix of the Gunter model

If we try to develop Gunter’s model in order to take into account iterativeness, then, obviously, we will have to provide life cycle line splitting, as shown in Fig. 8. But this also entails splitting the matrix of intensities of the functions performed: it would be unreasonable to assume that the intensities are preserved during returns. In general, as development progresses towards completion, they should decrease. Thus, the intensity matrix acquires a new dimension, reflecting the iterative nature of the project development.

Iteration is inevitable when developing complex software products, and therefore its planning is advisable. However, when looking at traditional approaches to project development, you will notice that they do not try to use iterativeness as a design method and only strive to minimize returns.

Rice. 8. Taking into account iterativity in the phase-function model (phase measurement, only some returns are shown)

2. Object-oriented models
life cycle

In technological terms, the attitude towards the iterative development of a project fundamentally distinguishes the object-oriented approach from all sequential methodologies. For traditional approaches, iteration is about correcting errors, i.e. a process that is difficult to technological standards and regulations. With an object-oriented approach, iterations never cancel each other's results, but always only complement and develop them.

2.1. Principles of Object-Oriented Design

The fundamental points in which the object-oriented approach to project development should be compared with traditional sequential methodologies boil down to the following:

• Iterative development.

  From the analysis phase to the completion of implementation, the object-oriented design process, as opposed to sequential development, is structured as a series of iterations, possibly preceded by a period of sequential learning. subject area and tasks of the project as a whole (stages defining requirements And initial planning).

• Increasing functionality in accordance with scenarios.

  Increasing the functionality of the designed product is presented as the development of scenarios that correspond to descriptions (diagrams) of the interaction of objects and reflect individual aspects of functioning. These descriptions prescribe the development of the project's operational base at the programming stage: it is developed based on scenarios at the design (construction) level. The complete functionality consists of the functionality of all scenarios. Thus, this strategy is quite close to the classical method of step-by-step detailing, when using which functionality is increased by clarifying (additionally defining) modules lower level. However, unlike this method, iterative growth requires that as a result of each iteration the product receives completely finished functionality planned by the scenario being implemented. Subsequent iterations add other functionality, which is planned by a different scenario.

• Nothing is done once.

  The sequential approach assumes that analysis is completed before design, the completion of which precedes programming. The overlap of stages (see section 1.4) weakens this assumption, but does not fundamentally change the situation. In most object-oriented projects, analysis is never completed during the entire development of the project, and the design process accompanies development throughout its entire life cycle.

• Operating on the multiplying phases is similar.

  As at the beginning of design, in subsequent iterations analysis precedes design, followed by programming, testing, and other types of work.

In object-oriented design, during iterative growth, quite traditional steps are usually performed:

• Defining Requirements, or iteration planning, - it is fixed what must be done at a given iteration in the form of a description of the area for which it is planned to develop functionality at a given iteration, and what is needed for this. Typically, this stage includes the selection of scenarios that should be implemented in this iteration.
• Analysis- the conditions for fulfilling the planned requirements are examined, the completeness of the selected scenarios is checked from the point of view of the implementation of the required functionality.
• User Interface Modeling- since the iteration must provide a functionally complete implementation, it is necessary to determine the rules of interaction necessary to activate the required functions. The interface model represents the user's view of the behavior of objects in a given iteration.
• Construction- the usual decomposition of the project, carried out in an object-oriented style. Design includes building or expanding the hierarchy of a class system, describing events and determining reactions to them, etc. During construction, objects are determined that are implemented and/or further defined at a given iteration, and a set of functions (object methods) that provide a solution to the problem of a given iteration.
• Implementation(programming) - software implementation of the decisions made for a given iteration. A necessary component of the implementation here is considered to be autonomous verification of compliance of the compiled modules with their specifications (in particular, the required behavior of objects must be ensured).
• Testing- stage of comprehensive verification of the results obtained at this iteration.
• Grade iteration results - the stage includes work related to the consideration of the results obtained in the context of the project as a whole. In particular, it must be clarified which project tasks can be solved taking into account the results of the iteration, which previously posed questions have been answered, and which new questions arise in new conditions.

2.2. Modification of the phase-function model

The traditional nature of the stages of object-oriented project development within one iteration allows us to pose the task of modeling the iterative growth process as a modification of existing life cycle models. In this section, such a modification is carried out for the Gunter phase-function model.

Compared to Gunter's model, the phase dimension of the life cycle in object-oriented design remains almost unchanged: there is only one additional stage: “User Interface Modeling”, which in the old scheme can be considered as part of the analysis and/or design stages. However, this is a very significant addition that characterizes the approach as a whole. The main motivation for explicitly considering life cycle modeling in object-oriented project development is related to the following two features:

• Distribution of implemented requirements across iterations.

  The set of scenarios implemented at the next iteration and the set of previously implemented scenarios always form finished, although incomplete version of the system offered to users. For various reasons, including to eliminate ambiguities in understanding, it is necessary to present what is planned for implementation in the form of models that harmonize the view of the system from the users (as well as customers and other interested parties) with the point of view of the developers. These models emerge during the analysis phase, as reflected in their name: analysis level models.

• A special style of increasing the capabilities of the system and its development.

Representing a system as a set of classes interconnected by various relationships is the basis for project decomposition in an object-oriented approach. Each new iteration expands this set by adding new classes that enter into certain relationships with the previously constructed class system. It is almost impossible to carry out such an extension correctly without abstracting from the implementation details of the existing one, and if we take into account the future, it is almost impossible without the same abstract representation of the added classes. In other words, it requires building design level models, which specify the implementation representation of the designed system.

In the above list of stages of the iteration life cycle in the object-oriented approach, modeling of the level of analysis is clearly highlighted, which comes down to constructing a model representation of scenarios. But this is only one aspect of design modeling. As just shown, another, no less significant aspect of modeling appears during design. Finally, there is a third aspect of modeling associated with the presentation of each version of a software product to the user, whose idea of ​​the system, of course, is not related to design-level models and is only indirectly related to analysis-level models. Thus, if we follow Gunter’s style of describing the life cycle, then it would be more correct to highlight not the modeling stage (as is most often done, following an already established tradition), but technologicalmodeling function, permeating the entire project development process.

In the new life cycle scheme, a strictly regulated split appears, unique for the entire sequence of work (Fig. 9). But this route does not reflect the correction of erroneously made decisions, but a completely planned act, which records the fact that during the implementation of iterations, the capabilities of the product are increasing.

It should be noted one more modification of the Gunter scheme, reflected in the figure. Within the evaluation stage there is a special sub-stage Replenishment of the basic project environment, the meaning of which comes down to planning and implementing software reuse. Any object-oriented project develops from some pre-existing environment of classes and other components. This base environment of the project is intensively used and, in turn, is replenished with funds arising as a result of iterative growth. The usefulness of maintaining such funds for the current project and for subsequent developments is obvious. In this regard, it is advisable to carry out extra work, aimed at preserving useful things in the project depository.

For obvious reasons, in object-oriented design the content of a number of stages changes somewhat, which is reflected in the number and names of events in the figure.

Rice. 9. Phase measurement of the life cycle model in object-oriented project development

When discussing the life cycle model for object-oriented project development, it is necessary to point out activities that go beyond the scope of a standardized iterative process. This initialproject phase, which is performed at the start during research and feasibility analysis, and project completion phase(iterations), with the completion of which work on the project (iteration) ends.

The purpose of the initial phase is general planning of the project development. In addition to the traditional content included in the stages of determining the requirements for the project as a whole, they should become the basis for development in two more respects:

• needs to be determined immediate task and long-term tasks of the project. The first of these is the task of the first iteration, during which, in particular, the first work product is prepared and presented to the customer. From the point of view of project development, the solution to the immediate problem should ensure the feasibility of the subsequent iterative increase in the capabilities of the system (this will still be discussed). The fate of the project as a whole depends on the quality of these two results. Long-term objectives are planned development that allows for adjustments in the future;
• required to select results evaluation criteria iterations. These criteria may vary depending on the focus of the project, application area, and other circumstances.

The project completion (iteration) phase covers the part of the life cycle that reflects the developer activities associated with the work products of the iteration after the results are obtained. It is quite similar to the traditional operation and maintenance phase, but there are differences due to the fact that an object-oriented project usually deals with hierarchies of system versions that reflect the increase in capabilities. This phase overlaps with the evaluation phase.

As already mentioned, work related to the reuse of work products is essential for object-oriented design. Before the completion phase, reuse is usually considered for the current project (baseline enrichment phase). After the application (iteration work product) has been used for some time, it can be considered as ready, within this phase the following is carried out:

• allocation of common (i.e., not tied to the project) reused components (usually these works are associated with the event of transfer of the system for distribution - checkpoint 10).

One of the essential aspects of object-oriented design is the rejection of the traditional postulate that all requirements for a system are formulated in advance. Consequently, when modeling the life cycle in general and its completion phase in particular, it is necessary to take into account the processing of the flow of external requirements at all stages. Attention will be paid to this issue, but for now we can assume (as most often happens) that requirements received at the completion phase of the iteration are considered as relating to the next iterations, i.e. to the next versions of the system. In this case, completing an iteration means maintaining the software product and then finishing work on that version. Wishes for the development of the project during this period are taken into account as requirements for subsequent (possibly not yet started) iterations. The end of the project is considered as a refusal to maintain all versions of the system. It is worth comparing this situation with traditional approaches to design, when taking into account wishes for a system during its operation most often means one thing: organizing a new project (perhaps a special one), the purpose of which is to take into account new requirements.

A few words about the functional dimension in the phase-function matrix modified for the object-oriented approach. As shown above, it is advisable to expand the list of technological functions through modeling. Accordingly, a row of intensities for this function should be defined in the Gunter matrix. Assuming that the distribution of intensities of other functions is preserved (Fig. 7), the intensity distribution for the modified life cycle model can be set as in Fig. 10, which shows new look the entire model (in the figure, the life cycle control points are indicated by their numbers without explanation).

The presented intensity distributions cannot be absolute. It would be naive to assume the stability of the intensities of technological functions over iterations. Consequently, the entire project development cycle cannot be depicted in a matrix, two-dimensional representation of the modified Ganter model: it cannot show the change in the intensities of technological functions during the transition from one iteration to another. For this reason, it is proposed to consider the distribution of intensities of technological functions as a “statistical average” trend integrated over iterations. The practical usefulness of considering the functional dimension is not in the specific distribution of intensities of technological functions in real projects, but in the fact that it forces the project management to think about the balance of power in the development team and, in general, about the correct distribution of the project’s human resources.

Rice. 10. Phase-function model, modifications for object-oriented development of the project

2.3. Parallel execution of iterations

Any software project that deserves a manager to support development is a collaborative process. Consequently, it is appropriate to raise the question of how the simultaneity of the activities of the team’s performers should be reflected in the life cycle model. For obvious reasons, this is one of the motivations for developing models.

In a model that follows Gunter's phase-function diagram, this quality of the software product development process is reflected using a functional dimension that shows which technological functions are performed simultaneously. Within the framework of the object-oriented approach, another type of technological parallelism is clearly distinguished: the simultaneous development of several iterations by different groups of performers (the phrase “different groups” should not be taken literally - in essence, these are group roles, and a specific group of performers may well be simultaneously responsible for the development at once several iterations).

Technological parallelism means the fundamental feasibility of simultaneous development of several iterations. However, this does not mean allowing their mechanical merging, since the iterations depend on one another. For example, it is impossible to expand a class system that has not yet been built; it is impossible to use a function with unknown conditions for its correct execution. Speaking about combining work, you should always know these and other types of dependencies. The following areas should be distinguished:

• area of ​​unacceptable alignment- when the performance of one job directly depends on the results of another job;
• area of ​​possible combination - when the dependence is weakened by the fact that the expected results of previous work are well described (for example, models of the design stages have been built and tested, although programming has not yet been completed);
• the area of ​​rational combination - when the dependence of the work is actually screened in one way or another (the previous work has been completed, although perhaps not fully verified, a protocol for the interaction of work has been drawn up and checked, etc.).

The simultaneous execution of different iterations can be represented in the form of diagrams shown in Fig. 11.

In Fig. 11 a) shows a breakdown of the iteration stages. Compared to the general model (Fig. 10), a finer division of stages is presented here: planning, which for the initial iteration is part of the overall feasibility analysis stage, and testing as an overlapping part are clearly highlighted general stages programming and evaluation.

Rice. 11 b) demonstrates three simultaneously executed iterations: the second begins during the programming of the first iteration in such a way that its programming stage begins after the end of testing of the first iteration. Planning for the third iteration begins simultaneously with the programming phase of the second iteration.

Rice. 11. Parallelization of project iterations

Rice. 11 c) shows the areas of unacceptable, possible and rational combinations, as well as the area of ​​sequential execution of two iterations. Inadmissibility of combination means that there is not enough complete information to plan the next iteration, and as a result, it cannot be carried out efficiently. During the design process, there comes a time when such information appears, therefore, it becomes possible to intensify work on a new iteration. Defining an area rational combination work of two iterations reflects that it would be unwise to begin the programming phase of a new iteration when the work product of the previous iteration has not been tested (the alignment depicted in Fig. 11 b) satisfies this condition). The sequential execution area indicates the time that corresponds to the beginning of the next iteration after completion of work on the previous one (there is no overlap).

Defining these areas increases the flexibility of project time allocation. However, when planning work, it is better not to count on combining iterations, but to leave this opportunity as a reserve of the project’s temporary resource. Thus, it turns out that the iterative nature of object-oriented design has additional resistance to the risks of failure to complete the design task.

2.4. Modeling iterative growth
system capabilities

Previous models of the object-oriented software life cycle did not clearly highlight an important aspect of the approach: the gradual increase in system capabilities as the project develops. To reflect it, we can propose a representation of the life cycle in the form spirals of development, which is shown in Fig. 12.

Rice. 12. Spiral of development of an object-oriented project

In the figure, horizontal segments with marks that have the same meaning as in the previous model are iterations. They are placed in the space of time-dependent system capabilities. Lines parallel to the time axis display the levels of user capabilities implemented in iterations (Roman numerals on the right indicate iteration numbers). The transition arrows between iterations take into account the conditions for combining work, which were discussed above. This model emphasizes the fact of object-oriented development of projects that the capabilities provided by the next iteration never cancel the level achieved in previous iterations.

The gradual increase in system capabilities as the project develops is often depicted in the form of a spiral, unwinding on a plane from the center, as shown in Fig. 13. According to this simple (rough) model, project development is described as gradually covering an ever-expanding area of ​​the plane as the project moves from stage to stage and from iteration to iteration. Essentially, this model emphasizes that object-oriented development leads to a gradual expansion of the application domain for which the work products being constructed are used.

Rice. 13. Model for expanding the coverage of the application area by an object-oriented system

Object-oriented project development is often said to assume that the traditional stages of the software system development life cycle never end. The unwinding spiral model clearly illustrates the meaning of this thesis.

In this model one can see another aspect of the design of software systems - a typical development scheme for a team of developers who, starting from their first project, gradually replenish the accumulated baggage of components reused in different systems.

Unlike previous models, both spiral models do not reflect the fact that the project has an end phase. As a consequence, they assume that all modifications to any version of a software system that are required after its release will be to one of the subsequent versions. In practice, this provision is very often violated: it is necessary to maintain (and, in particular, modify) several versions of the system at once.

From the collection "Novosibirsk School of Programming. Roll Call of Times". Novosibirsk, 2004
Reprinted with permission of the editors.

Management process configuration includes administrative and technical procedures throughout the software life cycle to determine the status of software components, describe and prepare reports on the status of software components and modification requests, ensure the completeness, compatibility and correctness of software components, manage the storage and delivery of software.

According to the IEEE-90 standard, software configuration is understood as the totality of its functional and physical characteristics installed in technical documentation and implemented in software. Configuration management allows you to organize, systematically take into account and control the introduction of changes to the software at all stages of the life cycle. General principles and recommendations for software configuration management are reflected in the ISO/IEC 15288 standard "Information Technology. Software Life Cycle Process. Configuration Management for Software".

Management process configuration includes the following steps:

1. the preparatory work of planning configuration management;
2. configuration identification, which establishes rules by which software components and their versions are uniquely identified. In this case, each component uniquely corresponds to a set of documentation;
3. configuration control - an action intended for the systematic assessment of proposed software modifications and their coordinated implementation, taking into account the effectiveness of each modification and the costs of its implementation;
4. configuration status accounting, which is a registration of the state of software components. Provides preparation of reports on implemented and rejected modifications of software component versions. The set of reports provides an unambiguous reflection current state system and its components, and also ensures maintenance of the history of modifications;
5. configuration assessment, which consists in determining functional completeness software components, as well as compliance of their physical state with the current technical description;
6. release management and delivery, which covers the production of master copies of programs and documentation, their storage, and delivery to users in accordance with organizational procedures.

Provisioning process Quality assurance must ensure that the software and its life cycle processes comply with specified requirements and approved plans. Software quality is understood as a set of properties that characterizes the software’s ability to satisfy specified requirements. To obtain reliable estimates about the software being created provisioning process its quality should occur independently of the entities directly related to the development software product. This may use the results of other supporting processes such as verification, validation, participatory assessment, audit and problem resolution.

Provisioning process quality includes the following actions:

1. preparatory work (coordination with other supporting processes and planning of the software quality assurance process itself, taking into account the standards, methods, procedures and tools used);
2. ensuring product quality, which implies guaranteed full compliance of the software and its documentation with the customer’s requirements stipulated in the contract;
3. ensuring process quality, which implies guaranteed compliance of software lifecycle processes, development methods, development environment and personnel qualifications with the terms of the contract, established standards and procedures;
4. ensuring other indicators of software quality, carried out in accordance with the terms of the contract and the ISO 9001 quality standard.

The verification process consists of determining that the software resulting from some activity fully satisfies the requirements or conditions imposed by previous activities. To increase the efficiency of the entire software life cycle process, verification should be integrated as early as possible with the processes that use it (i.e., delivery, development, operation). The verification process may include analysis, evaluation and testing.

Verification can be carried out with various degrees of independence (from the performer himself to specialists from another organization independent of the supplier, developer, etc.). During the verification process, the following conditions are checked:

1. consistency of requirements for the system and the degree to which user needs are taken into account;
2. the ability of the supplier to meet specified requirements;
3. compliance of the selected life cycle processes with the terms of the contract;
4. adequacy of standards, procedures and development environment to software life cycle processes;
5. compliance of software design specifications with specified requirements;
6. correctness of description in design specifications of input and output data, sequence of events, interfaces, logic, etc.;
7. code compliance with design specifications and requirements;
8. testability and correctness of the code, its compliance with accepted coding standards;
9. correct integration of software components into the system;
10. adequacy, completeness and consistency of documentation.

The certification process is intended to determine the completeness of compliance of the specified requirements and the created software with their specific requirements. functional purpose(what the consumer requires). Certification usually refers to confirmation and assessment of the reliability of the testing of a software product. Certification must ensure full compliance of the software with specifications, requirements and documentation, as well as the possibility of safe and reliable use of the software by the user.

Certification, like verification, can be carried out with varying degrees of independence (up to an organization independent of the supplier, developer, operator or support service).

The collaborative assessment process is intended to evaluate the status of the project work and the software product created during the implementation of this work. It focuses primarily on controlling the planning and management of project resources, personnel, equipment and tools.

The assessment is applied both at the level of project management and at the level of technical implementation of the project and is carried out throughout the entire duration of the contract. This process can be carried out by two parties involved in the contract, with one party verifying the other.

The audit process is a determination of whether the project and product meet the requirements, plans, and contract terms. An audit can be performed by any two parties involved in the contract, with one party auditing the other.

An audit is an audit (verification) carried out by a competent authority (person) in order to provide an independent assessment of the degree of compliance of software or processes with established requirements.

The audit serves to establish compliance real work and reports to requirements, plans and contract. Auditors should not have direct dependence on software developers. They determine the status of work, the use of resources, compliance of documentation with specifications and standards, correctness of testing, etc.

The problem resolution process involves analyzing and resolving problems (including identified nonconformities) that are discovered during development, operations, or other processes, regardless of their origin or source.

5.4. Organizational processes of software life cycle

Management process consists of activities and tasks that can be performed by any party managing its processes. This side(manager) is responsible for managing the release of the product,

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

Software Life Cycle Models

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

Cascade model

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

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

The life cycle is traditionally divided into the following mainstages:

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

Advantages of the model:

• stability of requirements throughout the entire development life cycle;
• at each stage a complete set is formed project documentation, meeting the criteria of completeness and consistency;
• certainty and clarity of the steps of the model and ease of its application;
• the stages of work performed in a logical sequence make it possible to plan the timing of completion of all work and the corresponding resources (monetary, material and human).

Disadvantages of the model:

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

It is difficult to implement the Cascade life cycle model due to the complexity of developing a software system without returning to previous steps and changing their results to eliminate emerging problems.

Scope of application of the Cascade model

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

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

Incremental model

(step-by-step model with intermediate control)

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

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

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

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

• the customer’s inability to finance the entire expensive project at once;
• the developer lacks the necessary resources to implement complex project in a short time;
• requirements phased implementation and product adoption by end users. Implementing the entire system at once can cause rejection among its users and only “slow down” the process of transition to new technologies. Figuratively speaking, they may simply “not digest a large piece, so it must be chopped and given in parts.”

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

Advantages:

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

Disadvantages of the model:

• managers must continually measure process progress. in the case of rapid development, you should not create documents for every minimal version change;
• the structure of a system tends to deteriorate as new components are added—constant changes disrupt the structure of the system. To avoid this you need extra time and money for refactoring. Poor design makes software difficult and expensive to change later. And an interrupted software life cycle leads to even greater losses.

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

Spiral model

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

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

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

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

Advantages of the model:

• allows you to quickly show system users a workable product, thereby activating the process of clarifying and supplementing requirements;
• allows for changes in requirements during software development, which is typical for most developments, including standard ones;
• the model allows for flexible design because it embodies the benefits of the cascade model, while at the same time allowing iterations across all phases of the same model;
• allows you to get a more reliable and stable system. As software evolves, bugs and weaknesses are discovered and corrected at each iteration;
• this model allows users to actively participate in planning, risk analysis, design, and evaluation activities;
• customer risks are reduced. The customer can complete the development of an unpromising project with minimal financial losses;
• Feedback from users to developers occurs with high frequency and early in the model, which ensures the creation of the desired product of high quality.

Disadvantages of the model:

• if the project is low risk or small in size, the model may be expensive. Risk assessment after each spiral is associated with high costs;
• The model life cycle has a complicated structure, so its use by developers, managers and customers may be difficult;
• the spiral can continue indefinitely, since each customer response to the created version can generate a new cycle, which delays the end of the project;
• a large number of intermediate cycles may lead to the need to process additional documentation;
• using the model may turn out to be expensive and even unaffordable, because time. the time spent on planning, redefining goals, performing risk analyzes and prototyping may be excessive;
• It may be difficult to define goals and milestones that indicate readiness to continue the development process into the next and

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

Scope of application of the spiral model

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

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