1 Software life cycle

The software life cycle is the life cycle of software. Like everything else, software is born and dies. Software life cycle refers to the process of software being conceived and developed until it is no longer used and dies. Different standards have different regulations on the phase division of the software life cycle. In GB8656-88 (National Standard for Software Engineering — Specification for Computer Software Development), the software life cycle is divided into eight stages: feasibility study and planning, requirements analysis, outline design, detailed design, implementation, integration test, validation test, use and maintenance.

(1) Feasibility study and plan

Before deciding whether to develop software, a feasibility study is first required. Through the feasibility study, to determine the necessity of developing the software, and according to the results of the feasibility study to determine the software objectives, scope, risk, development costs and other content. To develop a preliminary software development plan. Through the feasibility study, if it is determined that the software is necessary for research and development, the feasibility study report and software Development plan will be produced, and the stage of demand analysis will be entered.

(2) Demand analysis

Requirement analysis is an important stage of software development. After the feasibility study, the initial goal and scope of software development is determined, and then the need for detailed analysis of software requirements, to determine what kind of software to make. Requirement analysis is an extremely important part of the software development process. If there is a significant deviation in requirement analysis, software development will inevitably deviate from the correct path and go further and further. Especially if the error of requirement analysis is found in the later stage of software development, the cost of correction is very large.

(3) Outline design

Outline design defines the technical blueprint of the entire software and is responsible for translating the results of requirements analysis into technical design solutions. In the outline design, it is necessary to determine the system architecture, the relationship between subsystems, interface specifications, database model, coding specifications and so on. The results of the outline design will serve as a working guide for programmers to understand the internal principles of the system, and carry out detailed design and coding work on its basis.

(4) Detailed design

Detailed design The final design before coding, detailed design on the basis of the outline design, refinement, such as class design. Detailed design is not a necessary stage in the development process and is often omitted in smaller, simpler systems. Similarly, in a given software development, only a few key modules may be designed in detail.

(5) Implementation

The implementation process includes coding and unit testing. Unit testing refers to testing a small program unit, such as a procedure, method, or function, that has just been written. Because the object of a unit test is a small program unit, rather than a complete program, it is often necessary to write some test programs to test. Effective unit testing can greatly improve the quality of coding and reduce the defect rate of software system.

(6) Integration test

Integration testing is also called assembly testing. A program that passes a unit test does not mean that it is free of defects. When a program unit is integrated for interaction, problems that cannot be found in a unit test often occur. Unlike unit tests, integration tests must be carefully organized, specifying integration test plans, determining how these program units will be integrated together, in what order they will be tested, and which test data will be used.

(7) Confirm the test

After the integration test is completed and the interface errors between the software have been eliminated, it is necessary to verify whether the software meets the requirements and meets the expected goals. Like integration testing, validation testing needs to be planned and organized to progressively verify that the software system is consistent with the requirements. The software that passes the confirmation test will be put into normal use and enter the maintenance period.

(8) Use and maintenance

Even after passing unit, integration, and validation tests, it is not possible to find all defects in a software system; Software system requirements also change as the business evolves. Therefore, in the process of software use, it is necessary to constantly maintain the software, correct the defects in the software, modify the software has not been able to adapt to the latest situation of the function or add new functions. The software maintenance process runs through the entire software use process. When the use and maintenance phase is over, the software system will die out naturally and the life cycle of the software system is over.

2. Software development model

In the early days of computing, it was a tool that only geniuses could master. People only know software at the level of program, so called software development is those who can master the computer write some binary sequence that only the computer can understand. However, with the development of technology and the increasing complexity of software, people have entered the era of large-scale software development. At this time, people found that the software system has become very complex, need to follow certain development methods to achieve success, so called these patterned development methods development model.

2.1 Waterfall Model

As the name implies, the waterfall model flows from one particular phase to the next, just like a waterfall, as shown in Figure 1.

2.1.1 The core idea of waterfall model

The waterfall model holds that software development is a staged, precise process. Like to build an aircraft carrier, you first need to know the parameters of the aircraft carrier (length, width, height, displacement, speed, etc.). In these parameters of the technology needs to carry on the aircraft carrier design, design includes the overall design and detailed design. Only clearly designed drawings can be delivered to construction, otherwise the parts will not fit together. After manufacturing, these parts should be assembled one by one, assembled into the engine, cabin and other parts, and check whether these parts meet the design standards, this is the integration test. Finally, the pieces were put together to create a giant aircraft carrier. This process is described in Figure 1, where the software can be accurately implemented through requirements analysis, overall design, detailed design, coding, debugging, integration testing and system testing. In Figure 1, each phase has a feedback line back to the previous phase, which means that defects found in subsequent phases of software development can be fed back to the previous phase for correction.

An important feature of the waterfall model can be seen in Figure 1: the stages of software development are clearly delineated, with clear boundaries from one stage to the next. At the end of each phase, fixed documentation or source programs flow into the next phase. At the end of the requirements analysis phase, there should be clear documentation describing the software requirements; After the overall design, there should be a document describing the overall structure of the software; After the detailed design, there should be a detailed design document that can be used for coding. After coding, the code itself is passed to the next stage as documentation. So also called waterfall model is document-oriented software development model.

When the software requirements are clear and stable, the waterfall model can be used to develop the software step by step. When the software requirements are not clear or change dramatically, the defects of the requirements in the waterfall model will not be exposed until the testing stage, resulting in the cost of late modification is too high, and it is difficult to control the risk of development.

2.1.2 Waterfall V model

The Waterfall V model is a variant of the waterfall model. With the application of waterfall model, it is found that defects are inevitable, defects will be introduced into the software at any stage, and the final test cannot guarantee that the software is completely free of defects, but only strive to find more defects before delivery. Testing becomes a very important link in software development, and the quality of testing directly affects the quality of software. As a result, a small change was made to the waterfall model, the waterfall V model with a greater emphasis on testing, as shown in Figure 2.

The whole waterfall model took a turn during coding and debugging, forming a symmetrical V. The Waterfall V model, like the standard Waterfall model, will enter the overall design phase after the requirements analysis, but in addition to the overall design, the requirements analysis also has a dotted line pointing to system testing. This means that the results of requirements analysis will be used as the criteria for system testing, i.e. the requirements analysis phase will also produce system tests consistent with the software requirements; At the same time, whether the software products meet the initial requirements will be verified in the system test phase. By analogy, master design corresponds to integration testing, and detailed design corresponds to unit testing. Waterfall V model not only maintains the waterfall model’s staged document-driven characteristics, but also emphasizes the verification of software products.

2.1.3 Shortcomings of waterfall model

Although a classic development model, there are still some insuperable flaws in the Waterfall model, even in the improved Waterfall V model.

  1. First, in the waterfall model, the requirements analysis phase is the foundation of all activities, and the design, implementation, and validation activities are derived from the results of the requirements analysis phase. Once the results of requirements analysis are not completely correct and there is a deviation, the subsequent activities can only amplify the deviation and go further and further on the wrong road. In fact, because users and developers have different positions, experience and knowledge domains, and different people express the same thing differently, it is impossible for the results of requirements analysis to accurately and completely describe the entire software system. Therefore, the late maintenance work of waterfall model is quite heavy, and most of the maintenance work is to correct the defects introduced in the requirement analysis stage. This problem is difficult to overcome with waterfall models.

  2. Second, the waterfall model is hard to adapt to change. The activities and results of each phase are precisely defined in the waterfall model, and each phase is closely dependent on the results of the previous phase. If requirements change late in the software, the whole system has to start from scratch again.

  3. Thirdly, using the waterfall model means that the software product is delivered only when all phases are completed, so it takes quite a long time to see the final result after the requirements are put forward to find out whether the software product can meet the customer’s requirements.

  4. Finally, the document-driven waterfall model produces not only software products but also a lot of documentation, most of which has no meaning for the customer, which requires a lot of labor to complete. So the waterfall model is also an overloading process.

2.2 Evolution Model

The waterfall model looks good, and as it flows through phase after phase, the software system is built. However, in the process of application software development, people find it difficult to fully understand the needs of users, design a perfect architecture, and develop a usable system at one time. This is because human cognition itself is a process, which is gradual and deepening. For complex problems, “doing it twice” is definitely better. Then, software development, which is complicated and closely related to human cognitive process, should also be a gradual process.

The evolutionary model is based on this idea. In general, an evolution model can be regarded as several iterations of the waterfall model. When a waterfall model is completed, the next iteration cycle is re-entered, and the software evolves and improves during such iterations. According to different characteristics of iteration, evolution model can be developed into spiral model, incremental model and prototype method.

2.3 Spiral model

Spiral model combines waterfall model and evolution model, which not only embodies the advantages of the two models, but also emphasizes the risk analysis that other models ignore. Each cycle of spiral model includes four stages: requirement definition, risk analysis, engineering implementation and review. Iterations are carried out by these four stages. Software development progresses one level with each iteration. The software process using spiral model is shown in Figure 3.

The basic approach of the spiral model is to introduce a very rigorous risk identification, risk analysis and risk control before each development stage of the Waterfall model. It breaks a software project into small projects, each identifying one or more major risks until all major risk factors have been identified.

The spiral model emphasizes risk analysis, enabling developers and users to understand and react to the risks that arise at each evolutionary layer. Therefore, spiral model is especially suitable for large and complex systems with high risks. For these systems, risk is a potential and non-negligible adverse factor of software development, which may damage the software development process and affect the quality of software products to varying degrees. The goal of reducing software risk is to identify and analyze the risk in time before causing harm, and decide what countermeasures to take, so as to eliminate or reduce the damage of risk.

Compared with waterfall model, spiral model supports dynamic changes of user needs, provides convenience for users to participate in all key decisions of software development, helps to improve the adaptability of target software, and provides convenience for project managers to adjust management decisions in time, thus reducing the risk of software development.

However, it cannot be said that the spiral model is absolutely superior to other models. In fact, the spiral model also has its own disadvantages:

(1) The spiral model requires rich experience and professional knowledge in risk assessment. In the project development with high risk, if the risk is not identified in time, it is bound to cause great loss. (2) Too many iterations will increase the development cost and delay the submission time.

2.4 Incremental Model

Another form of the evolutionary model is the incremental model. When the technical architecture of the system is mature and the risk is low, the system can be developed in an incremental manner. This allows integration testing and system testing to be carried out ahead of time, shortening the initial release cycle and improving the visibility of the system for users.

For incremental models, there are usually two strategies. One is the incremental release approach. That is, first do the analysis and design of the system, and then divide the system into a number of different versions, each version is a complete system, the latter version is developed on the basis of the previous version, expand the function of the previous version. In this strategy, the first version is often the core function of the system, which can meet the most basic needs of users. With incremental release, the functions of the system are gradually enriched and improved. Users can get the initial version of the system and try it out in a very short time. Problems in the trial can be quickly fed back into subsequent development, thus reducing the risk of the system. In applying the incremental model, note the following: (1) Each version is a complete version. Although the first few increments did not fully fulfill user requirements, these versions were complete and available. (2) It is important that the increments between versions be uniform. If the first release takes one month and the second takes six months, this uneven distribution reduces the significance of incremental releases and requires recalibration.

Another strategy is prototyping. Unlike incremental releases, each iteration in prototyping goes through a full life cycle. Prototyping can be used when user requirements are unclear or when there are many unknowns in the technical architecture. In the initial prototype, for the general user needs for rapid implementation, not considering the rationality of the algorithm or the stability of the system. The main purpose of this prototype is to obtain precise user requirements or to verify the usability of the architecture. Typically, this prototype will be discarded later in development and the complete system will be re-implemented.

2.5 Component assembly model

With the development of soft component technology, people begin to try to use soft component for building block development, namely component assembly model. In the construction of the assembly model, after the software functions are defined through demand analysis, the assembly structure of components is designed, the system is divided into a set of components, and the relationship between components is defined. After the system components are determined, each component will be completed independently. At this time, software components can be developed, existing components can also be reused, and of course, third-party components can be purchased or selected. The components are independent and self-contained, so the development of the architecture is also independent, and the components collaborate with each other through interfaces.

A general development process for the component assembly model is shown in Figure 4.

The component assembly model has the following advantages:

(1) The self-inclusion of components makes it easier to expand the system; (2) Well-designed components are easier to be reused and reduce the cost of software development; (3) The granularity of components is smaller than that of the whole system, so the arrangement of development tasks is more flexible. The development team can be divided into several groups to develop components independently in parallel.

The component assembly model also has obvious disadvantages: (1) The design of components requires experienced architects, and poorly designed components are difficult to realize the advantages of components, reducing the reuse degree of component assembly model. (2) When considering the reuse degree of software, it often makes concessions to other aspects, such as performance. (3) When using components to assemble application programs, programmers are required to master components proficiently, which increases the learning cost of r&d personnel. (4) The quality of the third-party component library will eventually affect the quality of the software, and the quality of the third-party component library is often difficult for the development team to control.