Life cycle of software systems. Software life cycle

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

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

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

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

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

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

Software products with a short lifespan

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

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

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

Software products with a long service life

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

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

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

I. System analysis:

a) research;

b) feasibility study:

operational;

Economic;

Commercial.

II. Software design:

a) design:

Functional decomposition of the system, its architecture;

External software design;

Database design;

Software architecture;

b) programming:

Internal software design;

External design of software modules;

Internal design of software modules;

Coding;

Debugging programs;

Program layout;

c) software debugging.

III. Evaluation (testing) of software.

IV. Software use:

a) operation;

b) support.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Database design, if necessary;

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

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

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

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

Software Debugging is carried out after all its components are debugged separately and assembled into a single software 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 the user's environment, is free from any defects, and contains the necessary documentation that accurately and completely describes the software product.

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

It goes on just as long as programming.

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

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

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

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

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

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

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

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

Software maintenance consists in maintenance, development of functionality and improvement of the operational characteristics of the software product, in replication and porting of the software product to various types of computing facilities.

Accompaniment plays a vital role feedback from the operational phase.

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

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

Overlap between software product lifecycle phases

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

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

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

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

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

Software Life Cycle Standards

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

Software Development Methodologies

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

Standard GOST 34.601-90

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

1. Formation of requirements for the AU
   1. Inspection of the object and justification for the need to create an AU
   2. Formation of user requirements for the AU
   3. Registration of a report on the performance of work and an application for the development of AS
2. Development of the AS concept
   1. Studying the object
   2. Carrying out the necessary research work
   3. Development of variants of the AU concept and selection of the variant of the AU concept that meets the requirements of users
   4. Preparation of a report on the work done
3. Technical task
   1. Development and approval terms of reference to create AS
4. Preliminary design
   1. Development of preliminary design solutions for the system and its parts
5. Technical project
   1. Development of design solutions for the system and its parts
   2. Development of documentation for the AU and its parts
   3. Development and execution of documentation for the supply of components
   4. Development of design tasks in adjacent parts of the project
6. working documentation
   1. Development of working documentation for the NPP and its parts
   2. Development and adaptation of programs
7. Commissioning
   1. Preparation of the automation object
   2. Staff training
   3. Complete set of speakers with supplied products (software and technical means, software and hardware systems, information products)
   4. Construction and installation works
   5. Commissioning works
   6. Carrying out preliminary tests
   7. Conducting trial operation
   8. Conducting acceptance tests
8. AC support.
   1. Performing work in accordance with warranty obligations
   2. Post-warranty service

Draft, technical designs and working documentation is a consistent construction of more and more accurate design solutions. It is allowed to exclude the stage "Draft design" and individual stages of work at all stages, to combine the stages "Technical design" and "Detailed documentation" into the "Detailed design", to perform various stages and works in parallel, to include additional ones.

This standard is not quite suitable for development at the present time: many processes are not sufficiently reflected, and some provisions are outdated.

ISO/IEC 12207/ and its application

ISO/IEC 12207:1995 "Information Technology - Software Life Cycle Processes" is the main normative document, regulating the composition of the software life cycle processes. It defines the life cycle framework containing the processes, activities, and tasks that must be completed during software development.

Each process is divided into a set of actions, each action into a set of tasks. Each process, action, or task is initiated and executed by another process as needed, and there are no predefined execution sequences. Connections by input data are preserved.

Software life cycle processes

• Main:
  • Acquisition (actions and tasks of the customer purchasing the software)
  • Delivery (activities and tasks of the supplier who supplies the customer with a software product or service)
  • Development (actions and tasks performed by the developer: creating software, drawing up design and operational documentation, preparing test and teaching materials etc.)
  • Operation (actions and tasks of the operator - the organization operating the system)
  • Maintenance (actions and tasks performed by the accompanying organization, that is, the maintenance service). Maintenance - making changes to the software in order to correct errors, improve performance or adapt to changing operating conditions or requirements.
• Auxiliary
  • Documentation (formalized description of information created during the software life cycle)
  • Configuration management (application of administrative and technical procedures throughout the software life cycle to determine the state of software components, manage its modifications).
  • Quality assurance (ensuring that the IS and the processes of its life cycle comply with the specified requirements and approved plans)
  • Verification (determining that software products, which are the results of some action, fully satisfy the requirements or conditions due to previous actions)
  • Certification (determination of the completeness of compliance of the specified requirements and the created system with their specific functional purpose)
  • Joint assessment (assessment of the state of work on the project: control of planning and management of resources, personnel, equipment, tools)
  • Audit (determination of compliance with the requirements, plans and terms of the contract)
  • Problem resolution (analysis and resolution of problems, regardless of their origin or source, that are discovered during development, operation, maintenance or other processes)
• Organizational
  • Management (activities and tasks that can be performed by any party managing their processes)
  • Creation of infrastructure (selection and maintenance of technology, standards and tools, selection and installation of hardware and software used to develop, operate or maintain software)
  • Improvement (assessment, measurement, control and improvement of life cycle processes)
  • Training (initial training and subsequent ongoing staff development)

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

1. Acquisition Initiation
2. Preparation of bids
3. Preparation and adjustment of the contract
4. Supplier oversight
5. Acceptance and completion of works

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

1. Formation of requirements for the system
2. Formation of a list of software products
3. Setting conditions and agreements
4. Description of technical limitations (system operation environment, etc.)

Software life cycle stages, relationship between processes and stages

Software life cycle model- a structure that determines the sequence of execution and the relationship of processes, actions and tasks throughout the 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 GOST R ISO/IEC 12207-99 standard does not offer a specific life cycle model. Its provisions are common to any life cycle models, methods and technologies for creating IP. It describes the structure of life cycle processes without specifying how to implement or perform the activities and tasks included in these processes.

The software lifecycle model includes:

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

Stage- a part of the software creation process, limited by a certain time frame and ending with the release of a specific product (models, software components, documentation), determined by the requirements specified for this stage.

At each stage, several processes defined in ISO/IEC 12207-99 can be performed, and vice versa, the same process can be performed at different stages. The relationship between processes and stages is also determined by the software life cycle model used.

Software life cycle models

The life cycle model is understood as a structure that determines the sequence of execution and the relationship of processes, activities and tasks performed throughout the life cycle. The life cycle model is specific information system and the specifics of the conditions in which the latter is created and operates

To date, the most widely used are the following main life cycle models:

• Task model;

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

• spiral model (present).

Task model

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

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

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

The general conclusion is that it is impossible to create a sufficiently large effective information system in this way.

Cascade model

Cascade model life cycle was proposed in 1970 by Winston Royce. It provides for the sequential implementation of all stages of the project in a strictly fixed order. Go to next stage means the complete completion of work at the previous stage (Fig. 1). The requirements defined at the requirements formation stage are strictly documented in the form of terms of reference and fixed for the entire duration of the project development. Each stage culminates in the release of a complete set of documentation sufficient for development to be continued by another development team.

The positive aspects of applying the cascade approach are as follows:

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

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

Project stages according to the waterfall model:

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

Rice. 1. Cascading development scheme

The waterfall approach has proven itself in building information systems for which, at the very beginning of development, all requirements can be formulated quite accurately and completely in order to give developers the freedom to implement them as best as possible from a technical point of view. Complex computational systems, real-time systems and other similar tasks fall into this category. However, in the process of using this approach, a number of its shortcomings were discovered, primarily due to the fact that the real process of creating systems never completely fit into such a rigid scheme. In the process of creation, there was a constant need to return to previous stages and clarify or revise previously made decisions. As a result, the real process of creating software took the following form (Fig. 2):

Rice. 2. The real process of software development according to the cascade scheme

The main disadvantage of the cascade approach is a significant delay in obtaining results. Coordination of the results with users is carried out only at the points planned after the completion of each stage of work, the requirements for information systems are "frozen" in the form of a technical task for the entire time of its creation. Thus, users can submit their comments only after the work on the system is fully completed. If requirements are not accurately stated or changed over a long period of software development, users end up with a system that does not meet their needs. Models (both functional and informational) of an automated object may become obsolete simultaneously with their approval. Essence systems approach to the development of IS is its decomposition (partitioning) into automated functions: the system is divided into functional subsystems, which in turn are divided into subfunctions, subdivided into tasks, and so on. The partitioning process continues up to specific procedures. At the same time, the automated system retains a holistic view in which all components are interconnected. Thus, this model has the main advantage of systematic development, and the main disadvantages are slow and expensive.

spiral model

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

Prototype- an active software component that implements individual functions and external interfaces. Each iteration corresponds to the creation of a fragment or version of the software, at which the goals and characteristics of the project are specified, the quality of the results obtained is assessed, and the work of the next iteration is planned.

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

Each turn of the spiral corresponds to the creation of a piece or version of the software, on which the goals and characteristics of the project are specified, its quality is determined, and the work of the next turn of the spiral is planned. Thus, the details of the project are deepened and consistently concretized, and as a result, a reasonable option is selected, which is brought to implementation.

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

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

Fig 3. Spiral model of the life cycle of IS

One of the possible approaches to software development within the framework of the spiral life cycle model is the recently widely used methodology of rapid application development RAD (Rapid Application Development). This term is usually understood as a software development process containing 3 elements:

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

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

• an iterative cycle in which developers, as the application begins to take shape, request and implement in the product the requirements received through interaction with the customer.

The software life cycle according to the RAD methodology consists of four phases:

• requirements definition and analysis phase;

• design phase;

• implementation phase;

• implementation phase.

At each iteration, the following are evaluated:

• the risk of exceeding the terms and cost of the project;
• the need to perform another iteration;
• the degree of completeness and accuracy of understanding the requirements for the system;
• expediency of terminating the project.

Advantages of the iterative approach:

• Iterative development greatly simplifies the introduction of changes to the project when changing customer requirements.
• When using the spiral model, the individual elements of the information system are gradually integrated into a single whole. In the iterative approach, integration is virtually continuous. Since the integration starts with fewer elements, there are much fewer problems during its implementation (according to some estimates, when using the waterfall development model, integration takes up to 40% of all costs at the end of the project).
• Iterative development provides greater flexibility in project management by allowing tactical changes to be made to the product under development.
• The iterative approach simplifies the reuse of components (implements a component approach to programming). This is due to the fact that it is much easier to identify (identify) the common parts of the project when they are already partially developed than to try to highlight them at the very beginning of the project. Reviewing the design after several initial iterations reveals common reusable components that will be improved in subsequent iterations.
• The spiral model allows you to get a more reliable and stable system. This is because as the system evolves, bugs and weaknesses are found and fixed at each iteration. At the same time, critical performance parameters can be adjusted, which in the case of the waterfall model is available only before the implementation of the system.
• An iterative approach provides an opportunity to improve the development process - the analysis carried out at the end of each iteration allows you to evaluate what needs to be changed in the development organization and improve it in the next iteration.

We should start by definingSoftware life cycle(Software Life Cycle Model) is a period of time that starts from the moment a decision is made to create a software product and ends at the moment it is completely withdrawn 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:cascading, incremental (staged model with intermediate control ) and spirallife cycle models.

Cascade model

Cascade model(eng. 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, design. implementation, testing, integration and support.

The development process is implemented using an ordered sequence of independent steps. The model provides that each subsequent step begins after the completion of the previous step. At all steps of the model, auxiliary and organizational processes and activities including project management, assessment and quality management, verification and validation, configuration management, 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 development life cycle;
• at each stage, a complete set of project documentation is formed that meets the criteria for completeness and consistency;
• the certainty and comprehensibility of the steps of the model and the simplicity of its application;
• the stages of work performed in a logical sequence allow you to plan the timing of the completion of all work and the corresponding resources (monetary, material and human).

Disadvantages of the model:

• the complexity of clearly formulating requirements and the impossibility of their dynamic change during the full life cycle;
• low flexibility in project management;
• subsequence linear structure development process, as a result of returning to previous steps to solve emerging problems leads to an increase in costs and disruption of the work schedule;
• unsuitability of the intermediate product for use;
• impossibility of flexible modeling of unique systems;
• late detection of build-related 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 the development of requirements) and at the end (during acceptance tests);
• users cannot be convinced of the quality of the developed product until the end of the entire development process. They do not have the opportunity to evaluate the quality, because they cannot see the finished product of 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 the execution of subsequent actions, which makes such a 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 Waterfall Life Cycle Model due to the complexity of developing PS without returning to previous steps and changing their results to eliminate emerging problems.

Scope of the Cascade Model

The limitation of the scope 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 by implementation and technical methodologies;
2. when developing a project focused on building a system or product of the same type as previously developed by developers;
3. when developing a project related to the creation and release new version an existing product or system;
4. when developing a project related to the transfer of an existing product or system to a new platform;
5. when performing large projects involving several large development teams.

incremental model

(staged model with intermediate control)

incremental model(eng. 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 as long as the Software Development Life Cycle comes to an end.

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

At the beginning of work on the project, all the basic requirements for the system are determined, divided into more and less important ones. After that, the development of the system is carried out on an incremental basis, so that the developer can use the data obtained during the development of the software. Each increment should add certain functionality to the system. In this case, the release starts with the components with the highest priority. When the parts of the system are defined, take the first part and start detailing it using the most appropriate process for this. At the same time, it is possible to refine the requirements for other parts that have been frozen in the current set of requirements of 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 the simple implementation of a subset of software requirements and the refinement of the model over a series of successive releases until the software is fully implemented.

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

• the lack of the customer's ability to immediately finance the entire expensive project;
• the lack of the necessary resources for the developer to implement a complex project in a short time;
• requirements for the phased implementation and development of the product by end users. The introduction of 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 can simply “not digest a large piece, so it must be crushed and given in parts.”

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

Advantages:

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

Disadvantages of the model:

• managers must constantly measure the progress of the process. in the case of rapid development, it is not worth creating documents for every minimal version change;
• the structure of the system tends to deteriorate when new components are added - constant changes disrupt the structure of the system. To avoid this, it is required additional time and money for refactoring. Poor structure makes software difficult and costly to modify later. And the interrupted Software Life Cycle leads to even greater losses.

The scheme does not allow promptly taking into account emerging changes and clarifications of software requirements. Coordination of development results with users is carried out only at the points planned after the completion of each stage of work, and the general requirements for software are fixed in the form of a technical task 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 specified, its quality is determined, and the work of the next turn is planned. Special attention is given to the initial stages of development - analysis and design, where the feasibility of certain technical solutions is checked and justified through the creation of prototypes.

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 initial stages 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 stages of analysis and design, the feasibility of technical solutions and the degree of satisfaction of customer needs is checked 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. Thus, the details of the project are deepened and consistently concretized, and as a result, a reasonable option is selected that meets the actual requirements of the customer and is brought to implementation.

Life cycle on each turn of the spiral - different models of the software development process can be applied. The end result 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 system creation. Incomplete completion of work at each stage allows you to move on to the next stage without waiting for the complete completion of work on the current one. The main task is to show users of the system a workable product as soon as possible, thereby activating the process of clarifying and supplementing requirements.

Advantages of the model:

• allows you to quickly show users of the system a workable product, thereby activating the process of clarifying and supplementing requirements;
• allows changes in requirements during software development, which is typical for most developments, including standard ones;
• the model provides for the possibility of flexible design, since it embodies the advantages of the cascade model, and at the same time iterations over all phases of the same model are allowed;
• allows you to get a more reliable and stable system. As software evolves, bugs and weaknesses are found and fixed at each iteration;
• this model allows users to actively participate in planning, risk analysis, development, as well as in the performance of evaluation activities;
• reduce customer risk. The customer can complete the development of an unpromising project with minimal financial losses;
• feedback from users to developers is performed at high frequency and early in the model, which ensures that the desired product is of high quality.

Disadvantages of the model:

• if the project is low risk or small, the model can be expensive. Risk assessment after each spiral is expensive;
• The life cycle of the model has a complicated structure, so its application by developers, managers and customers can be difficult;
• the spiral can continue indefinitely, since each customer's response to the created version can generate a new cycle, which delays the completion of the project;
• a large number of intermediate cycles may lead to the need to process additional documentation;
• the use of the model can be costly and even unaffordable, because time. spending on planning, re-targeting, performing risk analysis and prototyping may be excessive;
• it may be difficult to define goals and milestones indicating readiness to continue the development process at the next and

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

Scope of the spiral model

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

• when developing projects using new technologies;
• when developing a new series of products or systems;
• when developing projects with expected significant changes or additions to requirements;
• for the implementation of long-term projects;
• when developing projects that require demonstration of 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 the assessment and resolution of risks.

Annotation.

Introduction.

1. Software life cycle

Introduction.

Riley Programming Process Steps

Introduction.

1.1.1. Formulation of the problem.

1.1.2. Solution design.

1.1.3. Algorithm coding.

1.1.4. Program support.

1.1.5. Software documentation.

Conclusion to paragraph 1.1

1.2. Definition of ZhTsPO according to Lehman.

Introduction.

1.2.1 System definition.

1.2.2. Implementation.

1.2.3. Service.

Conclusion to item 1.2.

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

1.3.1. cascade model.

1.3.2. Economic substantiation of the cascade model.

1.3.3. Improvement of the cascade model.

1.3.4. Definition of life cycle phases.

1.3.5. Basic work on the project.

Literature.

Introduction

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

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

1 Software life cycle

INTRODUCTION

ZHPO is continuous process, which begins from the moment a decision is made on the need to create software and ends at the moment of its complete withdrawal from operation.

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

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

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

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

1.1 Riley Programming Process Steps

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

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

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

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

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

Rice. 1.Four programming steps.

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

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

1.1.1 Statement of the problem

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

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

Characteristics of a Good Problem Statement:

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

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

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

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

The standard form of problem statement.

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

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

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

task name (schematic definition);

general description(brief statement of the task);

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

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

Example. Statement of the problem in the standard form.

TITLE

Sort three integers.

DESCRIPTION

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

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

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

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

Software life cycle. Stages and stages

The IS life cycle is a series of events that occur with the system in the process of its creation and use.

Stage- a part of the software creation process, limited by a certain time frame and ending with the release of a specific product (models, software components, documentation), determined by the requirements specified for this stage.

The life cycle is traditionally modeled as a number of successive stages (or stages, phases). Currently, there is no generally accepted division of the life cycle of a software system into stages. Sometimes a stage is singled out as a separate item, sometimes it is included as an integral part of a larger stage. The actions performed at one stage or another may vary. There is no uniformity in the names of these stages.

Traditionally, the following main stages of the software life cycle are distinguished:

Requirements analysis,

Design,

Coding (programming),

Testing and debugging,

Operation and maintenance.

Software life cycle. Cascade model

cascade model (70-80s) ≈ assumes the transition to the next stage after the completion of work on the previous stage,

The main achievement of the waterfall model is the completeness of the stages. This enables cost and time planning. In addition, project documentation is formed, which has completeness and consistency.

The waterfall model is applicable to small software projects with well-defined and unchanging requirements. The real process can reveal failures at any stage, which leads to a rollback to one of the previous stages. The model of such software production is cascade-return

Software life cycle. Staged model with intermediate control

staged model with intermediate control (80-85) ≈ iterative software development model with feedback loops between stages. The advantage of this model is that inter-stage adjustments are less labor intensive than the waterfall model; however, the lifetime of each of the stages is stretched over the entire development period,

Main stages of problem solving

The purpose of programming is to describe data processing processes (hereinafter referred to as simply processes).

Data (data) is the presentation of facts and ideas in a formalized form suitable for transfer and processing in some process, and information (information) is the meaning that is given to data when they are presented.

Data processing is the execution of a systematic sequence of actions on data. Data are presented and stored on data carriers.

The set of data carriers used in any data processing is called the information medium (data medium).

The set of data contained at any time in the information environment - state information environment.

A process can be defined as a sequence of successive states of some information environment.

To describe the process means to determine the sequence of states of the information environment. In order for the required process to be generated automatically on some computer according to a given description, this description must be formalized.

Software quality criteria

A commercial product (product, service) must meet the requirements of the consumer.

Quality is an objective characteristic of a product (product, service), showing the degree of consumer satisfaction

Quality characteristics:

› performance- the system works and implements the required functions.

› Reliability– the system works without failures and failures.

› Recoverability.

› Efficiency- the system performs its functions in the best possible way.

› Economic efficiency - the minimum cost of the final product with the maximum profit.

Quality characteristics:

› Accounting for the human factor- ease of use, speed of learning to work with software, ease of maintenance, making changes.

› Portability(mobility) - portability of code to another platform or system.

› Functional completeness– perhaps the most complete implementation of external functions.

› Calculation accuracy

Algorithm properties.

Efficiency means the possibility of obtaining a result after performing a finite number of operations.

Certainty consists in the coincidence of the results obtained, regardless of the user and the applied technical means.

mass character lies in the possibility of applying the algorithm to a whole class of tasks of the same type, differing in specific values ​​of the initial data.

discreteness - the possibility of dividing the process of calculations prescribed by the algorithm into separate stages, the possibility of highlighting sections of the program with a certain structure.

Ways to describe algorithms

There are the following ways of describing (representing) algorithms:

1. verbal description;

2. description of the algorithm using mathematical formulas;

3. graphical description of the algorithm in the form of a block diagram;

4. description of the algorithm using pseudocode;

5. combined method images of the algorithm using verbal, graphic and other methods .

6. using Petri nets.

Verbal description algorithm is a description of the structure of the algorithm in natural language. For example, for devices household appliances, as a rule, an instruction manual is attached, i.e. a verbal description of the algorithm in accordance with which this device should be used.

Graphic descriptionalgorithm in the form of a flowchart is a description of the structure of the algorithm using geometric shapes with communication lines.

The block diagram of an algorithm is a graphical representation of a method for solving a problem, which uses special characters to display operations.

The symbols that make up the block diagram of the algorithm are defined by GOST 19.701-90. This GOST complies with the international standard for the design of algorithms, therefore, flowcharts of algorithms, designed in accordance with GOST 19.701-90, in different countries are clearly understood.

Pseudocode– description of the structure of the algorithm in a natural, but partially formalized language. Pseudocode uses some formal constructions and common mathematical symbolism. There are no strict syntax rules for writing pseudocode.

Let's consider the simplest example. Let it be necessary to describe the algorithm for displaying on the monitor screen the greatest value from two numbers.

Figure 1 - An example of the description of the algorithm in the form of a block diagram

Description of the same algorithm in pseudocode:

2. Number input: Z, X

3. If Z > X then Conclusion Z

4. Otherwise output X

Each of the above methods of depicting algorithms has both advantages and disadvantages. For example, the verbal method is verbose and lacks clarity, but it makes it possible to better describe individual operations. The graphical method is more visual, but it often becomes necessary to describe some operations in verbal form. Therefore, when developing complex algorithms, it is better to use a combined method.

Types of algorithms

linear;

branching;

cyclic.

· Linear algorithm- a set of commands (instructions) executed sequentially one after another.

· Branching Algorithm- an algorithm containing at least one condition, as a result of checking which the computer provides a transition to one of two possible steps.

· Cyclic algorithm- an algorithm that provides for repeated repetition of the same action (the same operations) on new initial data. Most of the calculation methods and enumeration of options are reduced to cyclic algorithms. Program cycle - a sequence of commands (series, loop body) that can be executed repeatedly (for new initial data) until a certain condition is satisfied.

C. Data types.

A data type is a description of the range of values ​​that a variable of the specified type can take. Each data type is characterized by:
1. the number of bytes occupied (size)
2. the range of values ​​that a variable of this type can take.

All data types can be divided into the following types:
1. simple (scalar) and complex (vector) types;
2. basic (system) and user (defined by the user).
In C language, the basic type system is made up of four data types:
1. symbolic,
2. integer,
3. real single precision,
4. real double precision.

Structure of a C program.

1. Operators of the C++ language

Operators control the execution of a program. The operator set of the C++ language contains all the control constructs of structured programming.
A compound statement is delimited by curly braces. All other statements end with a semicolon.
Empty operator - ;
An empty statement is a statement consisting of only a semicolon. It can appear anywhere in the program where the syntax requires a statement. The execution of an empty statement does not change the state of the program.
Compound operator - (...)
The action of a compound statement is to sequentially execute the statements contained in it, except in those cases when any statement explicitly transfers control to another place in the program.
Exception Handling Operator

try(<операторы> }
catch(<объявление исключения>) { <операторы> }
catch(<объявление исключения>) { <операторы> }
...
catch(<объявление исключения>) { <операторы> }

Conditional operator

if (<выражение>) <оператор 1>

switch operator

switch(<выражение>)
( case<константное выражение 1>: <операторы 1>
case<константное выражение 2>: <операторы 2>
...
case<константное выражение N>: <операторы N>
}
The switch statement is designed to select one of several alternative ways of program execution. The evaluation of a switch statement begins with the evaluation of the expression, after which control is transferred to the operator marked with a constant expression equal to the evaluated value of the expression. The switch statement is exited by the break statement. If the value of the expression is not equal to any constant expression, then control is transferred to the operator marked with the default keyword, if any.
Loop statement with precondition

while(<выражение>) <оператор>

Loop statement with postcondition

do<оператор>while<выражение>;
In C++, this operator differs from the classical implementation of a loop with a postcondition in that when the expression is true, the loop continues, rather than exiting the loop.
Step Loop Operator

for([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
The body of the for statement is executed until the conditional expression becomes false (equal to 0). The start expression and increment expression are commonly used to initialize and modify loop parameters and other values. The start expression is evaluated once before the first test of the conditional expression, and the increment expression is evaluated after each execution of the statement. Any of the three loop header expressions, and even all three, can be omitted (just remember to leave the semicolons). If the conditional expression is omitted, then it is considered true, and the loop becomes infinite.
The step-by-step loop operator in the C++ language is a flexible and convenient construction, so the loop operator with the while precondition is used very rarely in the C++ language, because in most cases it is more convenient to use the for statement.
Break operator

break;
The break statement interrupts the execution of while, do, for, and switch statements. It can only be contained in the body of these statements. Control is transferred to the program statement following the interrupted one. If a break statement is written inside nested while, do, for, switch statements, then it only terminates the statement that immediately encloses it.
continuation operator

continue;
The continuation operator transfers control to the next iteration in the while, do, for loop statements. It can only be contained in the body of these statements. In do and while statements, the next iteration begins with the evaluation of the conditional expression. In the for statement, the next iteration starts by evaluating the increment expression, and then the conditional expression is evaluated.
return statement

return[<выражение>];
The return statement terminates the execution of the function that contains it and returns control to the calling function. Control is passed to the point of the calling function

if (boolean expression)

operator;

if (boolean expression)

operator_1;

operator_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

If the value of the logical expression is true, then expression_1 is evaluated, otherwise expression_2 is evaluated.

switch (integer type expression)

case value_1:

sequence_of_operators_1;

case value_2:

sequence_of_operators_2;

case value_n:

sequence_of_operators_n;

default:

sequence_of_operators_n+1;

branch default may not be described. It is executed if none of the above expressions is satisfied.

loop operator.

Turbo C provides the following constructs for programming loops: while, do while and for . Their structure can be described as follows:

Loop with condition check at the top:

Select statement

If the actions to be performed in the program depend on the value of some variable, a select statement can be used. At the same time, in C++, only numeric variables can be used as variables in a select statement. AT general view The select statement entry looks like this:

switch(variable)
{
case value1:
actions1
break;

case value2:
actions2
break;
...

default:
default actions
}

Keyword break must be added to the end of each branch. It stops the execution of the select operation. If you do not write it, after performing actions from one selection branch, the execution of actions from the following branches will continue. However, sometimes such a selection property is useful, for example, if you need to perform the same actions for different values ​​of a variable.

switch(variable)
{
case value1:
case value2:
actions1
break;

case value3:
actions2
break;
...
}

Sample use of select:

int n, x;
...
switch(n)
{
case 0:
break; //if n is 0, then do nothing

case 1:
case 2:
case 3:
x = 3 * n; //if n is equal to 1, 2 or 3, then perform some actions
break;

case 4:
x=n; //if n is equal to 4, then perform other actions
break;

default:
x = 0; //for all other values ​​of n, perform the default actions
}

C.Cycle: loop with parameter

General form records

for (parameter initialization; end condition check; parameter correction) (

block of operations;

for - parametric loop (loop with a fixed number of repetitions). To organize such a cycle, it is necessary to carry out three operations:

§ parameter initialization- assigning an initial value to the cycle parameter;

§ end condition check- comparison of the parameter value with some boundary value;

§ parameter correction- changing the value of the parameter with each passage of the loop body.

These three operations are written in parentheses and separated by a semicolon (;). As a rule, the loop parameter is an integer variable.
Parameter initialization is done only once - when the for loop starts executing. The termination condition is checked before each possible execution of the loop body. When the expression becomes false ( zero), the cycle ends. The parameter correction is carried out at the end of each execution of the loop body. The parameter can either increase or decrease.

Example

#include
int main() (

for(num = 1; num< 5; num++)

printf("num = %d\n",num);

Si. Loop with precondition

General notation

while(expression) (

block of operations;
}

If the expression is true (not equal to zero), then the block of operations enclosed in curly braces is executed, then the expression is checked again. The sequence of actions, consisting of checking and executing a block of operations, is repeated until the expression becomes false (equal to zero). In this case, the loop is exited and the operation after the loop statement is executed.

Example

intk=5;
int i=1;
intsum=0;
while(i<=k) {

When constructing a while loop, it is necessary to include constructs that change the value of the expression being checked so that in the end it becomes false (equal to zero). Otherwise, the loop will be executed indefinitely (infinite loop), for example

block of operations;
}

while is a loop with a precondition, so it is quite possible that the body of the loop will not be executed even once if, at the time of the first check, the condition under test is false.

Si. Loop with postcondition

Loop with do...while postcondition

General notation

block of operations;

) while(expression);

Loop with postcondition

The do...while loop is a loop with a postcondition, where the truth of the expression is checked after all the operations included in the block delimited by curly braces have been performed. The loop body is executed until the expression becomes false, that is, the loop body with the postcondition is executed even though would once.

It is better to use the do...while loop in those cases when at least one iteration must be performed, or when the initialization of the objects participating in the condition test occurs inside the loop body.

Example. Enter a number from 0 to 10

#include
#include
int main() (

system("chcp 1251");

printf("Enter a number from 0 to 10: ");

scanf("%d", &num);

) while((num< 0) || (num > 10));

printf("You entered the number %d", num);

getchar(); getchar();

Function definition

Consider the definition of a function using the example of the sum function.

In C and C++, functions do not have to be defined until the moment they are used, but they must be declared beforehand. But even after all this, in the end, this function must be defined. After that, the prototype of the function and its definition are linked, and this function can be used.

If a function has been previously declared, it must be defined with the same return value and data types, otherwise a new, overloaded function will be created. Note that function parameter names do not have to be the same.