The life cycle of software. Life cycle of software systems Define the concept of life cycle of software

Topic: Classic and flexible life cycle models: definition, description, distinctive features, sequence of stages. Methods for choosing a life cycle model in software development in various subject areas.

Models and stages of software lifecycle

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

ISO / IEC 12207 does not provide a specific lifecycle 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 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 work ordered in time, interconnected and united in stages (phases) of work, 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 a 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 development are distinguished for reasons of rational planning and organization of work, ending with the specified results. The life cycle of software 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 split into standalone 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 the formation of software requirements is one of the most important and determines to a large (even decisive!) Degree the success of the entire project. The beginning of this stage is to obtain an approved and validated system architecture with the inclusion of basic agreements on the distribution of functions between hardware and software. This document should also contain confirmation of the general understanding of the functioning of the software, including the basic 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 of work prior to work on a project. The main tasks of the stage are the definition of development goals, preliminary economic assessment project, construction of a work schedule, creation and training of 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 the 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 and between departments , external in relation to the organization of objects and external information influences, analysis existing funds automation of the organization's activities.

Building a model of the organization's (object) activity, providing for the processing of survey materials and building 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;
• model "TO-BE" ("how it should be"), reflecting the idea of ​​new technologies of the organization.

Each of the models must include full functional and information model activities of the organization, as well as (if necessary) a model that describes the dynamics of the behavior of the organization. Note that the constructed models have independent practical significance, 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, testability and feasibility have been 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?" development, software debugging plan and quality control.

   The system project is based on the models of the designed system, which are based 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, testability and feasibility have been 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 meets 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, sizes, sequence of calls, input and output data, erroneous 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 (time of central processors, memory, etc.);
• verification of the completeness, consistency, feasibility and validity of requirements;
• preliminary integration and debugging plan, user manual and acceptance test plan.

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

The stage of implementation is the implementation of the following works.

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

   External specifications should contain the following information:

   • module name - indicates the name used to call the module (for a module with multiple inputs, there must be separate specifications for each input);
   • function - defines the function or functions performed by the module;
   • a 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 must be defined under any input conditions);
   • external effects (printing a message, reading a request from the terminal, etc.).
2. Designing the logic of modules and programming (coding) modules.
3. Checking the correctness of the modules.
4. Testing modules.
5. Description of the database down to the level of individual parameters, symbols and bits.
6. Acceptance test plan.
7. User manual.
8. Preliminary plan for integration and debugging. The content of the subsequent stages basically coincides with the corresponding processes of the life cycle of software. 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 life cycle of software processes is shown in the figure.

Rice. 1.

Types of software lifecycle models

Waterfall model (classic life cycle)

This model owes its appearance to W. Royce (1970). The model also has another name - 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 has been completely completed; refunds to the passed stages are not provided.

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

Advantages cascade model:

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

The waterfall approach has proven itself well when building a software system, for which at the very beginning of the project all the 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.

disadvantages cascade model:

• identification and elimination of errors is carried out only at the testing stage, which can be significantly extended;
• real projects often require deviations from the standard sequence of steps;
• the cycle is based on the exact formulation of the initial requirements for the PS, in fact, at the beginning of the project, the customer's requirements are only partially determined;
• 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 in detail the project of the 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 fixes were made after the completion of any development stage. This is how the iterative model of life cycle PS appeared, called the model with intermediate control or the model with cyclic repetition of phases.

In an iterative model, design and programming flaws can be rectified 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 code is taken as a unit, then the cost of identifying and eliminating an error at the stage of requirements development will be 5-10 times less, and the cost of identifying and eliminating an error at the stage of maintenance will be 20 times less. more.

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

Layout

Often the customer cannot formulate the requirements for the input, processing or output of data for the future software product. The developer may have doubts about the suitability of the product for the operating system, in the form of 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 customer's requirements. Layout (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 between the customer and the developer.

The sequence of actions for prototyping is shown in the figure. Prototyping begins with collecting and clarifying the 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 have to be further defined. Then a quick design is done. It focuses on the characteristics that should be visible to the user. Rapid design leads to building a layout. The layout is evaluated by the customer and is used to clarify the software requirements. Iterations continue until the layout identifies all the customer's requirements and gives the developer an opportunity to understand what needs to be done.

The virtues of prototyping are the ability to ensure that complete system requirements are defined. Disadvantages of layout:

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

The essence of the shortcomings should be clarified. 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 have been left unresolved. ease of maintenance systems. When the developer tells the customer about this, the answer may be indignation and the demand for the fastest transformation of the layout into a working product. This negatively affects the management of software development.

On the other hand, in order to get a working layout quickly, the developer often makes certain trade-offs. For example, not the most suitable programming languages ​​may be used, or operating system... For a simple demonstration, an ineffective (simple) algorithm can be used. After a while, the developer forgets about the reasons why these tools are not suitable. As a result, a far from ideal chosen option is integrated into the system.

Before considering other lifecycle software models that have replaced cascade model, we should focus on the design strategies software systems... It is the software design strategy that largely determines the software lifecycle model.

Software design strategies

There are three strategies for designing 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 design is done as a sequence of versions. The first version implements some of the planned features, the next version implements additional features and so on, until a complete system is obtained;
• evolutionary strategy. The system is also built in a sequence of versions, but not all requirements are defined at the beginning of the process. Requirements are refined as a result of versioning. The 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 philosophy of prototyping (proposed by B. Boehm as an improvement cascade model). Each linear sequence here generates a supplied software increment. For example, the software for processing words in the 1st increment (version) implements the functions of basic file processing, editing and documentation functions; in the 2nd increment - more complex editing and documentation options; in the 3rd increment - spelling and grammar check; in 4th increment - page layout capabilities.

The first increment results in a base product that implements the basic requirements (although many ancillary requirements remain unfulfilled). The next increment plan includes modifications to the base product to provide additional features and functionality.

An incremental process is inherently iterative, but unlike prototyping, an incremental model provides a working product at each increment.

The diagram of such a model of the life cycle of software 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 model of life cycle software

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

1. Planning - defining 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 - the customer's evaluation of the current design results.

The integrating aspect spiral model obvious when considering the radial dimension of the spiral. With each iteration, more and more full versions PS. In the first turn of the spiral, initial goals, options and constraints are identified, and risk is recognized and analyzed. If the risk analysis reveals the ambiguity of the requirements, the prototyping used in the design quadrant comes to the rescue 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 (quadrant of the customer's assessment). The next phase of planning and risk analysis is based on the customer's suggestions. In each cycle in a spiral, the results of the risk analysis are formed in the form "continue, do not continue". If the risk is too great, the project can be stopped.

In most cases, the spiral continues, with each step moving developers towards a more general model of the system. Each spiral cycle requires a design (lower right quadrant) that can be accomplished by the classic lifecycle or prototyping. Note that the number of development activities (occurring in the lower right quadrant) increases as you move from the center of the spiral.

These actions are numbered and have the following content:

1. - initial collection of requirements and project planning;
2. - the same work, but based on the customer's recommendations;
3. - risk analysis based on initial requirements;
4. - risk analysis based on the customer's reaction;
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 customer.

Dignity spiral model:

1. most realistically (in the form of evolution) reflects the development software;
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 software product.

disadvantages spiral model:

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

The spiral development process model is currently the most common. The most famous variants are RUP (Rational Unified Process) from Rational and MSF (Microsoft Solution Framework). UML (Unified Modeling Language) is used as the modeling language. The creation of the system is supposed to be carried out iteratively, moving in a spiral and, going through the same stages, to refine the characteristics of the future product at each loop. It would seem that now everything is fine: only what can be foreseen is planned, what is planned is being 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 disband teams of specialists as needed, now they all have to constantly participate in the project: architects, programmers, testers, instructors, etc. Moreover, the efforts of different groups must be synchronized in order to timely reflect design solutions and make the 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 began in the early 1980s. at Rational Software corporation. In early 2003, Rational acquired IBM. One of the main pillars of RUP is the process of creating models using the Unified Modeling Language (UML).

RUP is one of the spiral software development methodologies. The methodology is supported and developed by Rational Software. The Unified Modeling Language (UML) is used as the modeling language in the general knowledge base. Iterative and incremental software development in RUP involves dividing a project into several projects that are executed sequentially, and each iteration of development is clearly defined by a set of goals to be achieved at the end of the iteration. Final iteration assumes that the set of goals for 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; the iteration of the development cycle is uniquely associated with a specific 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 quite often it is depicted as a graph-table ..

This figure presents 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 accents in the project change over time. For example, in early iterations, more time is devoted to requirements; in later iterations, more time is devoted to implementation. The horizontal axis is formed from time intervals - iterations, each of which is an independent development cycle; the goal of the cycle is to bring some predefined tangible refinement to the end 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. Inception - the formation of a project concept, understanding of what we are creating, a vision of a product (vision), development of a business plan (business case), preparation of a program prototype or 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) - clarifying the plan, understanding how we create it, designing, planning the necessary actions and resources, detailing the features. The stage ends with the executable architecture, when all architectural decisions are made and the risks are taken into account. An executable architecture is a running software that demonstrates the implementation of basic architectural solutions. In the final iteration, this is a technical project.
3. Implementation, creation of the system (Construction) - 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, product delivery to a specific user (replication, delivery and training).

The vertical axis consists of disciplines, each of them can be described in more detail in terms of the tasks performed, the roles responsible for them, the products that are submitted to tasks as input and are 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 business of an organization and accumulate knowledge about it, optimize business processes and decide on their partial or complete automation.
2. Requirements management is about obtaining 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 covers the procedures for transforming requirements into intermediate descriptions (models) that represent how those requirements should be implemented.
4. Implementation covers the development of code, testing at the developer level, and the integration of components, subsystems, and the entire system in accordance with established specifications.
5. Testing (Test) is devoted to assessing the quality of the product being created.
6. Deployment covers the operations that take place when products are transferred to customers and when the product is made available to end users.
7. Configuration management is all about synchronizing middleware and end products and managing their development throughout the project and finding hidden issues.
8. Project Management (Management) is dedicated to project planning, risk management, monitoring its progress and continuous assessment of key indicators.
9. Environment management (Environment) includes elements of the formation of the development environment information system and support of project activities.

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

An integral part of the RUP is made up of artefacts, precedents, and roles. Artifacts are some of the products of a project that are generated or used in the work 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 group is an artifact, be it an analysis document, a model element, a code file, a test script, a description of an error, etc. Certain specialists are responsible for the creation of this or that type of artifacts. Thus, the 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 the initial analysis documents to executable modules, user manuals, etc.

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

• Rational Rose - CASE- visual simulator 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 - a requirements management tool that allows you to create, structure, prioritize, track, control requirements changes that occur at any stage of the development of application components;
• Rational ClearQuest is a product for change management and tracking of defects in a project (bug tracking), tightly integrated with testing and requirements management tools and providing a single environment for linking all errors and documents to each other;
• Rational SoDA is a product for the automatic generation of project documentation that allows you to set a corporate standard for internal documents. It is also possible to bring documentation to existing standards (ISO, CMM);
• Rational Purify, Rational Quantify Rational PureCoverage - testing and debugging tools;
• Rational Visual Quantify is a performance measurement tool for application and component developers who program in C / C ++, Visual Basic, and Java; helps to identify and eliminate bottlenecks in software performance;
• Rational Visual PureCoverage - Automatically identifies areas of code that are not being tested.
• Rational ClearCase is a software configuration management (SCM) product that allows version control of all project documents. It allows you 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 is 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 system performance characteristics.

This set of products is constantly being improved and replenished. 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 development lifecycle. The IBM Rational Software Architect product is intended for building models of developed software systems using the unified modeling language UML 2.0, primarily models of the architecture of the developed application. However, RSA integrates the functions of software products such as Rational Application Developer, Rational Web Developer, and Rational Software Modeler, thereby enabling architects and analysts to create different views of the information system under development using UML 2.0 and developers J2EE, XML, web services, etc.

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

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

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

MSF (Microsoft Solution Framework)

In 1994, in an effort to maximize the impact of IT projects, Microsoft released a set of guidelines for the effective design, development, implementation and maintenance of solutions based on its technologies. This knowledge is based on the experience gained by Microsoft while working on large projects for the development and maintenance of software, the experience of Microsoft consultants and the best that the IT industry has accumulated to date. All of 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 general MSF methods for applied and specialized use. Moreover, Microsoft certifies experts specifically in applied knowledge in the application of MSF (for example, certification MCTS 74-131 for expertise in project management techniques). Before learning MSF techniques, you should first determine which MSF application you are referring to.

The most popular MSF applications developed by Microsoft are:

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

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

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

Building a business solution within the allotted time and budget requires a proven methodological framework. MSF offers proven methodologies for planning, designing, developing and implementing successful IT solutions. Thanks to its flexibility, scalability and lack of rigid guidelines, MSF is able to meet the needs of an organization or project team of any size. The MSF methodology consists of principles, models and disciplines for managing people, processes, technology elements, and related issues that are common to most projects. MSF consists of two models and three disciplines. These 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 provides 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: waterfall and spiral. The process model in MSF 3.0 has been supplemented with another innovative aspect: it covers the entire life cycle of creating a solution, from its starting point to the actual implementation. This approach helps project teams focus on the business value of the solution, as this return becomes real only after the product is deployed and used.

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: "Has the project team come to an unambiguous understanding of the goals and scope of the project?", "Is the action plan ready enough?" Does the solution meet the needs of the customer? " etc.

The MSF Process Model accommodates constant changes in design requirements. It assumes 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;
• deployment (Deploying).

In addition, there are a large number of milestones that show some progress in the project and break down large segments of work into smaller, visible areas. 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 work materials are usually created in an iterative manner. MSF recommends that you begin your solution development by building, testing, and implementing basic functionality. Then more and more features are added to the solution. This strategy is referred to as a versioning strategy. While a single version release may be sufficient for small projects, it is recommended that you do not miss the opportunity to create multiple versions for one solution. With the creation of new versions, the functionality of the solution evolves.

An iterative approach to the development process requires a flexible way of maintaining documentation. Living documents must change as the project evolves along with changes in the requirements for the final product. 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.

The solution has no business value until it is implemented. It is for this reason that the MSF Process Model contains the entire lifecycle of a solution, including its implementation, right up to the point where the solution starts to pay off.

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

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

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

According to the duration of the life cycle, software products can be divided into two classes: small and long life span. 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. V scientific organizations and universities, for example, are dominated by the development of programs of the first class, and in design and industrial organizations - the second.

Software products with short lifespan are created mainly for solving scientific and engineering problems, for obtaining 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 the end user. Some details are put on paper and the project is completed within days or weeks. They are not intended to be replicated and passed on for later use by other teams. As such, such programs are part of research and development work and cannot be regarded as alienable software products.

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

Software products with short lifespan

Maintenance and modification of such programs is not necessary, and their life cycle ends 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

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

Software products with a long service life are 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 represent software products alienated from the developer.

Software products with a long service life

Large teams of specialists are engaged in their design and operation, which requires 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 is spent 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 control and information processing.

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

I. System analysis:

a) research;

b) feasibility analysis:

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;

Programming;

c) software debugging.

III. Evaluation (testing) of software.

IV. Using the software:

a) operation;

b) accompaniment.

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

At this stage, a list of requirements is drawn up, that is, a clear definition of what the user expects from the finished product. Here, the setting of goals and objectives is carried out, for the sake of which the project itself is being developed. The systems analysis phase can be divided into two directions: research and feasibility studies.

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

The job consists of planning and coordinating the activities necessary to prepare a formal handwritten list of requirements for the software product being developed.

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 leadership is strengthened so much that a project manager is appointed to organize the design and allocation of resources (labor).

The work consists in researching the proposed software product in order to obtain practical assessment the possibilities of project implementation, in particular, are determined by:

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

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

- commercial feasibility, Will the product be attractive, in demand, easy to install, adaptable to service, easy to learn?

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

The feasibility study ends when all requirements are collected and approved.

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

Failure to comply with this requirement can significantly slow down the implementation of the project in the future due to repeated repeated appeals to the user for clarification of incorrectly interpreted details, unspecified conditions and, as a result, it will require reworking its already developed parts.

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% takes its final form.

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

Construction software usually starts in the feasibility study phase, once some preliminary goals and requirements are fixed on paper.

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

In this segment of the life of the software, they carry out:

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

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

Database design, if necessary;

Software architecture design - defining objects, modules and their interfacing.

Programming begins already in the design phase, as soon as the basic specifications for individual components of the software product become available, but not before the approval of the requirements agreement. Overlapping programming and design phases leads to savings in overall development time, as well as to ensure that design decisions are validated, and in some cases affects the solution of key issues.

At this stage, the work associated with assembling 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 specific program.

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

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

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

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

The evaluation phase begins as soon as all components (modules) are assembled and tested, i.e. after full debugging of the finished software product. It ends after receiving confirmation that the software product has passed all tests and is ready for use.

It takes as long as programming.

IV. Use of software. If systems analysis is the signal for battle, design is attack and return with 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 in the process of its design are corrected.

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

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

At this time, personnel 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 taken out of use and the above activities are discontinued. Note, however, that the software product can be used for a long time by someone else and after the use phase as defined here has ended. Because this someone can fruitfully use the software product at home, even without the developer's help.

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

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

Software maintenance consists in maintenance, development of functional capabilities and improvement of operational characteristics of a software product, in replication and transfer of a software product to various types of computing facilities.

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

During the operation of the software, it is possible to detect errors in programs, and there is a need for their modification and expansion of functions.

These modifications are usually carried out simultaneously with the operation of the current version of the software product. After checking the prepared corrections on one of the copies of the programs, the next version of the software product replaces the previously used ones or some of them. In this case, the process of operating a software product can be almost continuous, since the replacement of a version of a software product is short-term. These circumstances lead to the fact that the process of operating a version of a software product usually proceeds in parallel and independently of the maintenance stage.

Overlap between phases of software product lifecycle

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 found, then you need to immediately return and correct them.

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

For example, when a single program is being designed, the system architecture is often dispensed with and

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

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. Maintenance of the program.

1.1.5. Software documentation.

Conclusion to clause 1.1

1.2. Definition of ZHCPO according to Lehman.

Introduction.

1.2.1 System definition.

1.2.2. Implementation.

1.2.3. Service.

Conclusion to clause 1.2.

1.3. Phases and work of ZHCPO according to Boehm

1.3.1. Waterfall model.

1.3.2. Economic justification cascade model.

1.3.3. Improvement of the waterfall model.

1.3.4. Determination of the phases of the life cycle.

1.3.5. Basic work on the project.

Literature.

Introduction

Industrial application computers and the growing demand for software have set urgent tasks to significantly increase 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 using computers. A complex approach to the processes of development, operation and maintenance of software has put forward a number of pressing problems, the solution of which will eliminate "bottlenecks" in the design of programs, reduce the time of completion of work, 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 uniform approach to the estimation of labor costs, timing of work and material costs, which hinders the increase in software development productivity, and ultimately - effective management of the software life cycle. Since a program of any type becomes a product (except, perhaps, educational, model programs), the approach to its production should be in many respects similar to the approach to the production of industrial products, and the issues of designing programs become extremely important. This idea is at the heart of B.W. Boehm's "Software Engineering", which we used in writing this term paper... In this book, software design refers to the process of creating a software product design.

1 Software life cycle

INTRODUCTION

Life cycle program is a continuous process that begins from the moment a decision is made on the need to create software and ends at the moment of its complete withdrawal from service.

There are several approaches to defining the phases and activities of the software life cycle (LCP), steps of the programming process, 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 center according to Boehm, which includes eight phases. She will be presented in the future in more detail.

One of the possible options is the description of the upper level according to Lehmann, which includes three main phases and presents a description of the life cycle of life in the most general case.

And, for a change, - we present the steps of the programming process presented by D. Riley in the book "Using the Module-2 language". This idea, in my opinion, is very simple and familiar, and we will start with it.

1.1 Steps in the Riley Programming Process

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);

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

maintenance of the program, i.e. an ongoing process of troubleshooting problems in the program and adding new features.

Rice. 1.Four steps of programming.

Programming starts from the moment when user, i.e. someone who needs a program to solve a problem presents the problem system analyst. The user and the systems analyst jointly define the problem statement. The latter is then transmitted algorithmist who is responsible for designing the solution. A solution (or algorithm) represents a sequence of operations, the execution of which leads to a solution to a problem. Since the algorithm is often not machine-readable, 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. A systems analyst, an algorithmist, an encoder, and an accompanying programmer 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 return to the previous steps due to unforeseen circumstances. All of this adds to the argument for careful software design: the results of each step must be complete, accurate, and understandable.

1.1.1 Problem statement

One of the most important steps in programming is problem statement. It serves as a contract between the user and the programmer (s). Like a legally badly written contract, bad problem statement is useless. With a good formulation of the task, both the user and the programmer clearly and unambiguously represent the task that needs 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 software that has not yet been created, based on the knowledge that it can. A good formulation 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 if it were a black box: it doesn't matter to him how the computer works, but what matters is what the computer can do that interests the user. In this case, the main focus is on the interaction of a person with a machine.

Characteristics of a Good Task Statement:

Accuracy, i.e. elimination 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 unintended input, and determining the appropriate output.

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

Often the requirement for accuracy, completeness and clarity is in conflict. For example, many legal documents are difficult to understand because they are written in a formal language that allows for the most precise formulation of certain provisions, excluding any minor discrepancies. For example, some of the questions on exam tickets are sometimes so precise 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 formulation of the problem is the one that achieves a balance of all three requirements.

The standard form of the problem statement.

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

This formulation does not satisfy the above requirements: it is neither exact, nor complete, nor understandable. Indeed, should the numbers be entered one per line or all numbers on one line? Does the expression "in order" mean the ordering from highest to lowest, lowest to highest, or the same order in which they were introduced.

Obviously, such a formulation does not answer many questions. If we take into account the answers to all the questions, then the statement of the problem will become wordy and difficult to understand. Therefore, D. Riley suggests using a standard form for setting the problem, which provides maximum accuracy, completeness, clarity and includes:

task name (schematic definition);

general description (summary tasks);

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

example (a good example can convey the essence of the problem, and also illustrate various cases).

Example. Statement of the problem in a standard form.

TITLE

Sorting three integers.

DESCRIPTION

Input and output three integers, sorted from lowest to highest.

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 displayed, with all three displayed on the same line. Separate adjacent numbers with a space. The numbers are displayed from lowest to highest, from left to right.

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

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 retirement. (IEEE Std 610.12 standard)

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 through optimal development management and the use of a variety of quality control mechanisms at every stage, from the formulation of the problem to the author's support of the software. 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 as a whole;

Testing, trial operation and software replication;

Regular software maintenance, maintenance support and analysis of results;

Software maintenance, 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. From the point of view of ensuring technological safety, it is advisable to consider in more detail the features of the presentation of life cycle stages in foreign models, since it is foreign software that is the most likely carrier of software defects of a sabotage type.

Software lifecycle standards

GOST 34.601-90

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

The graphical presentation of life cycle models allows you to visually highlight their features and some properties of processes.

Initially, a cascading life cycle model was created, in which major stages began one after another using the results of previous work. It provides for the sequential execution 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. Requirements identified at the stage of requirements formation are strictly documented in the form terms of reference and are recorded for the entire duration of the project development. Each stage ends with 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 it is necessary to "roll back" to the early phase of the project and the required rework not only knocks the project team off the schedule, but often leads to a qualitative increase in costs and, possibly, to the termination of the project in the form in which it was originally conceived. The main misconception of the authors of the waterfall model is the assumption that the project goes through the entire process once, the designed architecture is good and easy to use, the implementation design is reasonable, and implementation errors are easily eliminated as testing progresses. This model assumes that all errors will be concentrated in the implementation, and therefore they are eliminated evenly during component and system testing. Thus, the waterfall model for large projects is not very realistic and can be effectively used only for creating small systems.

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

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

Feasibility of terminating the project.

Standardization of software lifecycle is carried out in three directions. The first direction is organized and promoted by the International Organization for Standardization (ISO - International Standard Organization) and the International Electro-technical Commission (IEC - International Electro-technical Commission). At this level, the most general technological processes relevant to international cooperation... The second direction is being actively developed in the USA by the Institute of Electrotechnical and Electronics Engineers (IEEE) together with the American National Standards Institute (ANSI). The ISO / IEC and ANSI / IEEE standards are mostly advisory in nature. The third area is stimulated by the US Department of Defense (Department of Defense-DOD). DOD standards are binding on firms commissioned by the US Department of Defense.

To design software for a complex system, especially a real-time system, it is advisable to use a system-wide model of life cycle, based on the combination of all known works within the framework of the considered 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 model of life cycle into two parts, significantly differing in the features of the processes, technical and economic characteristics and factors influencing them.

In the first part of the life cycle, a system analysis, design, development, testing and software testing is carried out. The range of works, their labor intensity, duration and other characteristics at these stages significantly depend on the object and the 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 software versions.

The second part of the life cycle, reflecting support for the operation and maintenance of software, is relatively weakly related to the characteristics of the object and the development environment. The range of work at these stages is more stable, and their labor intensity and duration can vary significantly, and depend on the mass use of software. For any model of life cycle, ensuring the high quality of 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 are advisable to choose from the available ones or to create, taking into account the development object and an adequate list of works.

The development of VT 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 problems, for the solution of which computers are used:

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

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

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 the designer.

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

The solution on a computer to 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.

It is convenient to characterize technologies in two dimensions - vertical (representing processes) and horizontal (representing stages).

Drawing

Process is a set of interrelated actions ( technological operations) converting some input to output. 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 processes and operates with such concepts as work processes, actions, tasks, performance results, performers.

A stage is a part of 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 grouped 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 controlled within the framework of each project for the development and operation of software, starting from the moment the idea (concept) of creating some software and making a decision about the need to create it and ending at the moment of its complete withdrawal from operation for reasons:

a) obsolescence;

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

Technological approaches are life cycle implementation mechanisms.

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 with the inception of the product concept 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 life cycle view includes stages:

Design

Implementation

Testing and debugging

Implementation, operation and maintenance.

The simplest representation of the life cycle of a program (a cascade technological approach to maintaining the life cycle):

Processes

Design

Programming

Testing

Escort

Analysis Design Implementation Testing Implementation Operation

and debugging and maintenance

In fact, a single process is performed here at each stage. Obviously, when developing and creating large programs, such a scheme is not correct enough (inapplicable), but it can be taken as a basis.

Aalysis stage concentrates on system requirements. Requirements are defined and specified (described). The development and integration of functional and data models for the system is underway. In addition, non-functional and other system requirements are recorded.

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 being refined. Design issues are raised and recorded that affect the comprehensibility, maintainability, and scalability of the system.

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 introduction to the market, growth, maturity and decline, then the life of software is more like the story of an unfinished, but constantly being completed and renovated building (aircraft) (Subscriber).

Lifecycle software is regulated by many standards, including international ones.

The goal of standardizing the life cycle of complex software systems:

Generalization of the experience and research results of many specialists;

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

Standards include:

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

Establish rules for the control of technological processes;

Establish requirements for the presentation of results;

Regulate the content of technological and operational documents;

Determine the organizational structure of the development team;

Provide assignment and scheduling of tasks;

Provide control over the progress of the creation of the PS.

In Russia, there are standards that regulate the life cycle:

Software development stages - GOST 19.102-77

Stages of NPP development - GOST 34.601 –90;

Terms of Reference for the creation of an AU - GOST 34.602-89;

Speaker test types - GOST 34.603-92;

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

In this regard, the international standard ISO / IEC 12207-1999 should be noted - “ Information Technology- Software Life Cycle Processes ”.

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

It defines the structure of the software lifecycle and its processes.

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

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

1) the main processes of software lifecycle (purchase, delivery, development, operation, maintenance). We will focus on the latter.

2) auxiliary processes that ensure the implementation of the main processes ( documenting, configuration management, quality assurance, verification, validation, joint 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 projects of complex software, consisting of many components, each of which may have varieties or versions, the problem arises of taking into account their connections and functions, creating a unified (i.e., a single) structure and ensuring the development of the entire system. Configuration management allows you to organize, systematically take into account and control changes to various software components at all stages of its life cycle.

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

3. Certification- confirmation by examination and presentation of objective evidence that 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) to ensure independent evaluation the degree of compliance of software products or processes with established requirements. Examination allows you to assess the compliance of development parameters with the original requirements. Verification overlaps with testing, which is conducted to determine the difference between actual and expected results and to assess whether the characteristics of the software meet the original requirements. In the process of project implementation important place occupy the issues of identification, description and control of the configuration of individual components and the entire system as a whole.

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

Project management associated with the planning and organization of work, the creation of development teams and control over 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, training of personnel, etc. Project quality assurance is concerned with the issues of verification, validation and testing of software components.

We will consider software lifecycle 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 work on 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 performance and quality of software products , materials required for staff training, etc.

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

1) the emergence and research of an 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, reliability and security requirements, external interface requirements, etc.

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

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

6) software architecture design - defining the software structure, 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 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, component testing, updating user documentation, updating the software integration plan;

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

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

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 – testing the system for

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

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

15) software acceptance – evaluation of the results of qualified

testing software and information system as a whole and

documenting the results of the assessment together with the customer, certification and final transfer of the software to the customer.

16) Management and development of documentation;

17) exploitation

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

software product.;

19) completion of operation.

These actions can be grouped by conventionally highlighting the following main stages of software development:

· Statement of the problem (TZ) (according to GOST 19.102-77 stage "Terms of reference")