We should start by definingLife cycle software (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 work are performed, including project management, assessment and quality management, verification and certification, configuration management, and documentation development. As a result of the completion of steps, intermediate products are formed that cannot be changed in subsequent steps.

The life cycle is traditionally divided into the following mainstages:

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

Advantages of the model:

• stability of requirements throughout the development life cycle;
• at each stage, a complete set is formed project documentation, which 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 the 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 simply implementing a subset of software requirements and refining the model over a series of successive releases until the entire software is 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 should be final result. Version development is carried out for various reasons:

• the lack of the customer's ability to immediately finance the entire expensive project;
• developer's lack necessary resources 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 on 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, additional time and money are required for refactoring. Poor structure makes software difficult and costly to modify later. And an 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 General requirements to the software are fixed in the form of technical specifications for the entire time of its creation. Thus, users often receive software that does not meet their real needs.

spiral model

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

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

At the 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- as soon as possible to show users of the system a workable product, 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 done at high frequency and early in the model to ensure the right product is built 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.Planningproduced on the basis of statistical data obtained in previous projects and personal experience 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.

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

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

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

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

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

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

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

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

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

Picture

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

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

Software development follows a specific life cycle.

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

a) obsolescence;

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

Technological approaches are mechanisms for implementing the life cycle.

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

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

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

Design

Implementation

Testing and Debugging

Implementation, operation and maintenance.

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

Processes

Design

Programming

Testing

Escort

Analysis Design Implementation Testing Implementation Operation

and debugging and maintenance

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

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

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

Implementation phase includes writing a program.

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

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

The purpose of standardizing the life cycle of complex PS:

Summarizing the experience and research results of many specialists;

Working off technological processes and development techniques, as well as a methodological basis for their automation.

Standards include:

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

Establish process control rules;

Establish requirements for the presentation of results;

Regulate the content of technological and operational documents;

Determine organizational structure development team;

Provide distribution and scheduling of tasks;

Provide control over the progress of the creation of PS.

In Russia, there are standards governing the life cycle:

Software development stages - GOST 19.102-77

Stages of creating AS - GOST 34.601-90;

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

Types of test AS - GOST 34.603-92;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3) analysis of requirements for information system - defining it

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

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

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

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

7) detailed software design - detailed

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

8) software coding -– development and documentation

each software component;

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

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

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

11) software qualification testing – software testing in

the presence of the customer to demonstrate its compliance

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

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

13) IP qualification testing – system testing for

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

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

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

software and information system testing in general and

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

16) Management and development of documentation;

17) operation

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

software product.;

19) completion of operation.

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

task statement (TOR) (according to GOST 19.102-77 stage " Technical task»)

The concept of software life cycle (LC) is one of the basic concepts in software engineering. Life cycle is defined as a period of time that starts from the moment a decision is made on the need to create software and ends at the time of its complete withdrawal from operation.

According to ISO standard/IEC 12207, all life cycle processes are divided into three groups (Fig. 2.1).

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

1. Formation of software requirements.

2. Design.

3. Implementation.

4. Testing.

5. Commissioning.

6. Operation and maintenance.

7. Decommissioning.

Currently, the following main models of software life cycle are most widely used:

a) cascading and

b) spiral (evolutionary).

The first was used for programs of small volume, which are a single whole. The principal feature waterfall approach is that the transition to the next stage is carried out only after the work on the current one is fully completed, and no return to the passed stages is provided. Its scheme is shown in Fig. 2.2.

The advantages of using the waterfall model are as follows:

At each stage, a complete set of project documentation is formed;

The stages of work performed allow you to plan the time of their completion and the corresponding costs.

Such a model is used for systems for which all requirements can be precisely formulated already at the beginning of development. These include, for example, systems in which problems of a computational type are mainly solved. Real processes are usually iterative in nature: the results of the next stage often cause changes in design decisions developed at earlier stages. Thus, the intermediate control model shown in Fig. 1 is more common. 2.3.

The main disadvantage of the cascade approach is a significant delay in obtaining results and, as a result, a rather high risk of creating a system that does not meet the changing needs of users.

These problems are fixed in spiral life cycle model (Fig. 2.4). Its fundamental feature is that application software is not created immediately, as in the case of the cascade approach, but in parts using the method prototyping . A prototype is an active software component that implements individual functions and the external interface of the software being developed. The creation of prototypes is carried out in several iterations - turns of the spiral.

The cascade (evolutionary) model can be represented as a diagram, which is shown in Figure 2.5.

One of the results of the application of the spiral model of the life cycle is the method of the so-called rapid application development , or RAD (Rapid Application Development). The software life cycle in accordance with this method includes four stages:

1) analysis and planning of requirements;

2) design;

3) implementation;

4) implementation.

Analysis of the life cycle of programs allows you to clarify the content and identify the following processes for designing complex systems.

1) Strategy;

2) Analysis;

3) Design;

4) Implementation;

5) Testing;

6) Introduction;

7) Operation and technical support.

Strategy

Defining a strategy involves examining the system. The main task of the survey is to assess the real scope of the project, its goals and objectives, as well as to obtain definitions of entities and functions at a high level. At this stage, highly qualified business analysts are involved, who have constant access to the firm's management. In addition, close interaction with the main users of the system and business experts is expected. The main task of such interaction is to obtain the most complete information about the system, unambiguously understand the requirements of the customer and transfer the information received in a formalized form to system analysts. Typically, information about the system can be obtained from a series of conversations (or workshops) with management, experts, and users.

The outcome of the strategy definition phase is a document that clearly states the following:

What exactly is due to the customer if he agrees to finance the project;

When he can get the finished product (work schedule);

How much will it cost him (schedule of financing stages of work for large projects).

The document should reflect not only the costs, but also the benefits, for example, the payback period of the project, the expected economic effect (if it can be estimated).

The considered stage of the software life cycle can be represented in the model only once, especially if the model has a cyclic structure. This does not mean that in cyclic models strategic planning produced once and for all. In such models, the stages of determining the strategy and analysis seem to be combined, and their separation exists only at the very first round, when the company's management makes a fundamental decision to start the project. Generally strategic stage is devoted to the development of a document at the level of enterprise management.

The analysis stage involves a detailed study of business processes (functions defined in the previous stage) and the information necessary for their implementation (entities, their attributes and relationships (relationships)). This phase provides the information model, and the next design phase, the data model.

All information about the system collected at the strategy definition stage is formalized and refined at the analysis stage. Particular attention is paid to the completeness of the information received, its analysis for consistency, as well as the search for unused or duplicate information. As a rule, the customer first forms the requirements not for the system as a whole, but for its individual components. And in this particular case, cyclic software life cycle models have an advantage, since re-analysis is likely to be required over time, since the customer often gets hungry with food. At the same stage, the necessary components of the test plan are determined.

Analysts collect and record information in two interrelated forms:

a) functions - information about the events and processes that occur in the business;

b) entities - information about things that are important to the organization and about which something is known.

In doing so, diagrams of components, data flows and life cycles are built that describe the dynamics of the system. They will be discussed later.

Design

At the design stage, a data model is formed. Designers process the analysis data. The end product of the design phase is a database schema (if one exists in the project) or a data warehouse schema (ER model) and a set of system module specifications (function model).

In a small project (for example, in a coursework), the same people can act as analysts, designers, and developers. The schemes and models listed above help to find, for example, not described at all, indistinctly described, inconsistently described system components and other shortcomings, which helps to prevent potential errors.

All specifications must be very accurate. The system test plan is also finalized at this stage of development. In many projects, the results of the design phase are documented in a single document - the so-called technical specification. At the same time, the UML language has been widely used, which allows you to simultaneously obtain both analysis documents that are less detailed (their consumers are production managers) and design documents (their consumers are managers of development and testing groups). This language will be discussed later. Software built using the UML makes it easier to generate code - at least the class hierarchy, as well as some parts of the code of the methods themselves (procedures and functions).

Design tasks are:

Consideration of the results of the analysis and verification of their completeness;

Seminars with the customer;

Identification of critical areas of the project and assessment of its limitations;

Determining the architecture of the system;

Deciding on the use of third-party products, as well as on the ways of integration and mechanisms for exchanging information with these products;

Data warehouse design: database model;

Process and code design: final choice development tools, defining program interfaces, mapping system functions to its modules, and defining module specifications;

Determining the requirements for the testing process;

Determination of system security requirements.

Implementation

When implementing a project, it is especially important to coordinate the group(s) of developers. All developers must comply with strict source control rules. They, having received technical project, start writing module code. The main task of developers is to understand the specification: the designer writes what needs to be done, and the developer determines how to do it.

At the development stage, there is close interaction between designers, developers and groups of testers. In the case of intensive development, the tester is literally inseparable from the developer, in fact, becoming a member of the development team.

Most often, user interfaces change during the development phase. This is due to the periodic demonstration of modules to the customer. It can also significantly change data queries.

The development phase is coupled with the testing phase, and both processes run in parallel. The bug tracking system synchronizes the actions of testers and developers.

Bugs should be classified according to priorities. For each class of errors, a clear structure of actions should be defined: “what to do”, “how urgent”, “who is responsible for the result”. Each issue should be tracked by the designer/developer/tester responsible for fixing it. The same applies to situations where the planned terms for the development and transfer of modules for testing are violated.

In addition, repositories of ready-made project modules and libraries that are used when assembling modules should be organized. This repository is constantly updated. One person should supervise the update process. One repository is created for modules that have passed functional testing, the second - for modules that have passed link testing. The first is drafts, the second is something from which it is already possible to assemble the distribution kit of the system and demonstrate it to the customer for control tests or for the delivery of any stages of work.

Testing

Test teams may be involved in collaboration early in the development of a project. Usually complex testing is separated into a separate stage of development. Depending on the complexity of the project, testing and fixing bugs can take a third, half of the total time of work on the project, and even more.

The more complex the project, the greater will be the need to automate the bug tracking system, which provides the following functions:

Storing the error message (what system component the error belongs to, who found it, how to reproduce it, who is responsible for fixing it, when it should be fixed);

Notification system about the appearance of new errors, about changes in the status of errors known in the system (notifications by e-mail);

Reports on current errors on system components;

Information about the error and its history;

Rules for accessing errors of certain categories;

Interface of limited access to the bug tracking system for the end user.

Such systems take on many organizational problems, in particular the issues of automatic error notification.

Actually, system tests are usually divided into several categories:

a) offline tests modules; they are already used at the development stage of the system components and allow you to track the errors of individual components;

b) link tests system components; these tests are also used at the development stage, they allow you to track the correct interaction and exchange of information between the system components;

c) system test; it is the main criterion for the acceptance of the system; as a rule, this is a group of tests, including both stand-alone tests and link and model tests; such a test should reproduce the operation of all components and functions of the system; its main purpose is the internal acceptance of the system and the assessment of its quality;

d) acceptance test; its main purpose is to hand over the system to the customer;

e) performance and load tests; this group of tests is included in the system one, it is the main one for assessing the reliability of the system.

Each group necessarily includes failure simulation tests. They test the response of a component, a group of components, and the system as a whole to the following failures:

A separate component of the information system;

Groups of system components;

The main modules of the system;

operating system;

Hard failure (power failure, hard drives).

These tests make it possible to evaluate the quality of the subsystem for restoring the correct state of the information system and serve as the main source of information for developing strategies to prevent the negative consequences of failures during industrial operation.

Another important aspect information systems testing program is the presence of test data generators. They are used to test the functionality, reliability and performance of the system. The task of assessing the characteristics of the dependence of the performance of an information system on the growth of the volume of processed information cannot be solved without data generators.

Implementation

Trial operation overrides the testing process. The system is rarely entered completely. As a rule, this is a gradual or iterative process (in the case of a cyclic life cycle).

Commissioning goes through at least three stages:

2) accumulation of information;

3) reaching the design capacity (that is, the actual transition to the operation stage).

During the period accumulation of information in the information system is revealed the largest number errors related to multi-user access. The second category of fixes is related to the fact that the user is not satisfied with the interface. At the same time, cyclic models and models with feedback steps to reduce costs. The stage under consideration is also the most serious test - the customer acceptance test.

System reaching design capacity in a good version, this is fine-tuning minor errors and rare serious errors.

Operation and technical support

At this stage, the last document for developers is the technical acceptance certificate. Document defines necessary staff and the required equipment to keep the system operational, as well as the terms of violation of the product and the liability of the parties. In addition, technical support conditions are usually issued in the form of a separate document.

In this PS standard (or software) is defined as a set of computer programs, procedures, and possibly associated documentation and data. A process is defined as a set of interrelated actions that transform some input data into output data (G. Myers calls this data translation). Each process is characterized by certain tasks and methods for their solution. In turn, each process is divided into a set of actions, and each action is divided into a set of tasks. Each process, action, or task is initiated and executed by another process as needed, and there are no predetermined execution sequences (of course, while maintaining the input data connections).

It should be noted that in the Soviet Union, and then in Russia, the creation of software (software) initially, in the 70s of the last century, was regulated by the GOST ESPD standards (Unified System for Program Documentation - GOST 19.XXX series), which were focused on the class relatively simple programs of small volume created by individual programmers. At present, these standards are outdated conceptually and in form, their validity has expired and their use is inappropriate.

Creation processes automated systems(AS), which also includes software, are regulated by GOST 34.601-90 " Information technology. Set of standards for automated systems. Stages of creation", GOST 34.602-89 "Information technology. Set of standards for automated systems. Technical task for the creation of an automated system" and GOST 34.603-92 "Information technology. Types of tests of automated systems". However, many provisions of these standards are outdated, while others are not reflected enough to be used for serious projects for the creation of PS. Therefore, it is advisable to use modern international standards in domestic developments.

In accordance with the ISO / IEC 12207 standard, all software life cycle processes are divided into three groups (Fig. 5.1).

Rice. 5.1.

Five main processes are defined in the groups: acquisition, supply, development, operation and maintenance. Eight sub-processes ensure the execution of the main processes, namely documentation, configuration management, quality assurance, verification, validation, joint assessment, audit, problem resolution. The four organizational processes provide governance, infrastructure building, improvement and learning.

5.2. The main processes of the life cycle of the PS

The acquisition process consists of the activities and tasks of the customer purchasing the software. This process covers the following steps:

1. acquisition initiation;
2. preparation of application proposals;
3. preparation and adjustment of the contract;
4. supervision of the activities of the supplier;
5. acceptance and completion of work.

Acquisition initiation includes the following tasks:

1. determination by the customer of his needs in the acquisition, development or improvement of the system, software products or services;
2. making a decision regarding the acquisition, development or improvement of existing software;
3. checking the availability of the necessary documentation, warranties, certificates, licenses and support in case of purchasing a software product;
4. preparation and approval of the acquisition plan, including system requirements, type of contract, responsibilities of the parties, etc.

Bids must contain:

1. system requirements;
2. list of software products;
3. terms of acquisition and agreement;
4. technical limitations (for example, on the operating environment of the system).

Bids are sent to a selected supplier or multiple suppliers in the event of a tender. A supplier is an organization that enters into a contract with a customer for the supply of a system, software or software service on the terms specified in the contract.

Preparation and adjustment of the contract includes the following tasks:

1. determination by the customer of the procedure for selecting a supplier, including criteria for evaluating the proposals of possible suppliers;
2. selection of a specific supplier based on the analysis of proposals;
3. preparation and conclusion supplier contracts;
4. making changes (if necessary) to the contract in the process of its implementation.

The supplier's activities are supervised in accordance with the actions stipulated in the joint assessment and audit processes. During the acceptance process, the necessary tests are prepared and performed. Completion of work under the contract is carried out in case of satisfaction of all conditions of acceptance.

The delivery process covers the activities and tasks performed by a vendor that supplies a customer with a software product or service. This process includes the following steps:

1. delivery initiation;
2. preparing a response to bids;
3. preparation of the contract;
4. contract work planning;
5. performance and control of contractual works and their evaluation;
6. delivery and completion of works.

The initiation of the supply consists in the consideration by the supplier of the bid proposals and the decision whether to agree with the requirements and conditions set out or to offer their own (agreed). Planning includes the following tasks:

1. making a decision by the supplier regarding the performance of work on its own or with the involvement of a subcontractor;
2. development by the supplier of a project management plan containing the organizational structure of the project, delimitation of responsibilities, technical requirements to the development environment and resources, management of subcontractors, etc.

The development process provides for the activities and tasks performed by the developer, and covers the work of creating software and its components in accordance with specified requirements. This includes the preparation of design and operational documentation, the preparation of materials necessary for performance testing, and quality of software products, materials necessary for organizing staff training, etc.

The development process includes the following steps:

1. preparatory work;
2. analysis of the requirements for the system;
3. system architecture design;
4. analysis of requirements for software;
5. software architecture design;
6. detailed software design;
7. software coding and testing;
8. software integration;
9. software qualification testing;
10. system integration;
11. qualification testing of the system;
12. software installation;
13. software acceptance.

The preparatory work begins with the selection of a software life cycle model appropriate to the scale, significance, and complexity of the project. The activities and tasks of the development process should be consistent with the chosen model. The developer must select, adapt to the conditions of the project and use the standards, methods and methods agreed with the customer. development tools, as well as draw up a work plan.

Analysis of the requirements for the system involves determining its functionality, custom requirements, requirements for reliability, security, requirements for external interfaces, performance, etc. System requirements are evaluated based on feasibility criteria and verifiability during testing.

The design of the system architecture consists in determining the components of its equipment (hardware), software and operations performed by the personnel operating the system. The architecture of the system must comply with the system requirements and accepted design standards and practices.

Software requirements analysis involves determining the following characteristics for each software component:

1. functionality, including performance characteristics and operating environment of the component;
2. external interfaces;
3. reliability and safety specifications;
4. ergonomic requirements;
5. requirements for the data used;
6. installation and acceptance requirements;
7. requirements for user documentation;
8. requirements for operation and maintenance.

The software requirements are evaluated based on the criteria of compliance with the requirements for the system as a whole, feasibility and verifiability during testing.

Software architecture design includes the following tasks for each software component:

1. transformation of software requirements into an architecture that defines the structure of the software and the composition of its components at a high level;
2. development and documentation of program interfaces for software and databases (DB);
3. development of a preliminary version of user documentation;
4. development and documentation of prerequisites for tests and software integration plan.

Detailed software design includes the following tasks:

1. description of software components and interfaces between them at a lower level, sufficient for subsequent coding and testing;
2. developing and documenting a detailed database design;
3. updating (if necessary) user documentation;
4. development and documentation of test requirements and a plan for testing software components;

Software coding and testing includes the following tasks:

1. coding and documenting each component of the software and database, as well as preparing a set of test procedures and data for testing them;
2. testing each component of the software and database for compliance with the requirements for them, followed by documentation of the test results;
3. updating documentation (if necessary);
4. updating the software integration plan.

Software integration provides for the assembly of the developed software components in accordance with the integration and testing plan for the aggregated components. For each of the aggregated components, test suites and test procedures are developed to test each of the competencies in subsequent proficiency testing. Qualification requirement is a set of criteria or conditions that must be met in order to qualify software as conforming to its specifications and ready for use in the field.

Qualification testing of software is carried out by the developer in the presence of the customer (

The operation process covers the activities and tasks of the organization of the operator operating the system. The operation process includes the following steps.

1. Preparatory work, which includes carrying out the following tasks by the operator:

   1. planning activities and work performed during operation, and setting operational standards;
   2. determination of procedures for localization and resolution of problems arising during operation.
2. Operational testing carried out for each next edition of the software product, after which this edition is transferred to operation.
3. The actual operation of the system, which is performed in the environment intended for this in accordance with the user documentation.
4. analysis of problems and requests for software modification (analysis of messages about a problem that has arisen or a request for modification, assessment of the scale, cost of modification, resulting effect, assessment of the feasibility of modification);
5. software modification (making changes to software product components and documentation in accordance with the rules of the development process);
6. verification and acceptance (in terms of the integrity of the system being modified);
7. transfer of software to another environment (conversion of programs and data, parallel operation of software in the old and new environment for a certain period of time);
8. decommissioning of the software by the decision of the customer with the participation of the operating organization, maintenance service and users. Wherein software products and documentation are subject to archiving in accordance with the contract.

Annotation.

Introduction.

1. Software life cycle

Introduction.

Riley Programming Process Steps

Introduction.

1.1.1. Formulation of the problem.

1.1.2. Solution design.

1.1.3. Algorithm coding.

1.1.4. Program support.

1.1.5. Software documentation.

Conclusion to paragraph 1.1

1.2. Definition of ZhTsPO according to Lehman.

Introduction.

1.2.1 System definition.

1.2.2. Implementation.

1.2.3. Service.

Conclusion to item 1.2.

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

1.3.1. cascade model.

1.3.2. Economic substantiation of the cascade model.

1.3.3. Improvement of the cascade model.

1.3.4. Definition of life cycle phases.

1.3.5. Basic work on the project.

Literature.

Introduction

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

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

1 Software lifecycle

INTRODUCTION

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

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

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

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

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

1.1 Riley Programming Process Steps

Introduction

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

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

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

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

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

Rice. 1.Four programming steps.

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

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

1.1.1 Statement of the problem

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

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

Characteristics of a Good Problem Statement:

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

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

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

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

The standard form of problem statement.

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

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

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

task name (schematic definition);

general description (brief statement of the task);

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

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

Example. Statement of the problem in the standard form.

TITLE

Sort three integers.

DESCRIPTION

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

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

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

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

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

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