development model

Waterfall Model/Improved Waterfall Model

　Although there are still many problems to be solved in the waterfall model, the waterfall model is still the most basic and effective alternative software development life cycle model. The waterfall model requires software development to strictly follow the requirements. ->Analysis->Design->Code->Testing stages, each stage can define clear outputs and verification criteria. Waterfall model can organize relevant reviews and verifications after each stage is completed, only when After the review is passed, the next stage can be entered.

　Since each stage needs to be verified, the waterfall model requires that each stage has a clear document output. For the strict waterfall model, each stage should not overlap, but should be After the review is passed, the relevant outputs have been baselined before entering the next stage.
　
　The advantage of the waterfall model is that it can still ensure the high quality of the entire software product and ensure that defects can be discovered and solved in advance. Adopt the waterfall model It can ensure a full grasp of the system as a whole, so that the system has good scalability and maintainability. However, it is difficult to make good use of the waterfall model for projects with unclear requirements in the early stage, but it is difficult to make it clear in a short time. In addition For small and medium-sized projects, the requirements design and developers are often fully invested in the project after the project starts, rather than in stages. Therefore, the use of the waterfall model will lead to too many idle human resources in the project, which is also necessary. Considering the problem.

　Many people tend not to choose the waterfall model due to schedule constraints, which is often a wrong point of view. A key factor leading to this situation is often the lack of manpower in the conceptual requirements stage. Therefore, the human resources can be fully obtained in the conceptual requirements stage. In the case of guarantee, there is not much difference in the development cycle between the waterfall model and the iterative model. On the contrary, many projects do not use the iterative or agile model well. In order to catch up with the schedule, the early requirements are not clear, and there is no overall Coding was started when the architecture was designed, and a lot of rework occurred later, which seriously affected the progress.
Architecture design is an important concern in software development. Therefore, it is also mentioned in RUP that software development should be based on architecture. Therefore, after the architecture design is completed, the system will be divided into related subsystems and functional modules. Each function The interfaces between modules can be clearly defined. In this case, when the detailed design of module B is completed, there is often no need to wait until the detailed design of other modules is completed before starting coding. Therefore, after the architecture design is completed, you can The system is divided into multiple modules for parallel development, and each module still follows the waterfall model idea of ​​designing and coding first. This is one of the most important improvement ideas of the waterfall model, and it can also be said that it is an incremental development model .

When the development of a new system has multiple functions with completely unrelated independent requirements, you can also choose to divide the entire development process into multiple small waterfalls according to independent requirements. The problem is that without a complete overall design, architects cannot make overall plans from the scalability, reuse, etc. of the system after understanding all the requirements.

　In project management, there is a method of compressing the schedule called rushing, so the waterfall model In addition, the improvement lies in the appropriate overlapping of the various stages of the process to achieve the effective use of resources. For example, through discussion, the implementation method determined by the meeting can start to direct the work of the next stage without necessarily waiting until the relevant deliverables are documented.

Spiral model

　First of all, the spiral model follows the waterfall model. That is, the route of requirements->architecture->design->development->testing. The greatest value of the spiral model is that the entire development process is iterative and risk-driven. This stage is transformed into multiple iterative processes to reduce the risk of the project.
Each iteration of the spiral model consists of the following six steps
　　1. Determine goals, alternatives and constraints
　　2. Identify and address project risks
　　3. Evaluate techniques Scenarios and Alternative Solutions
　　4. Develop the deliverables for this iteration and verify the correctness of the iteration outputs.
　　5. Plan the next iteration
　　6. Submit the steps and plans for the next iteration. The

　spiral model realizes that as the cost of the project increases, the risk gradually decreases. To help us strengthen the management and tracking of the project, we need to monitor the output after each iteration. Projects can be evaluated and verified, and the project can be terminated early when it is found that it cannot continue.

　The complexity of the spiral model lies in responsible, dedicated and knowledgeable management. Because for each iteration, we have to formulate clear goals, analyze relevant The key risks and deliverables in the plan that can be verified and tested are not an easy task.

　Each iteration of the spiral model contains only one or two phases of the waterfall model. For example, the second iteration focuses on requirements, the first The three iterations are the overall design and subsequent design and development plans. Therefore, this is different from the iterative model advocated by RUP. Each iteration of RUP will include activities in various stages such as requirements, design, development and testing. RUP iterative The purpose is to gradually refine rather than just complete the work of a certain stage of the waterfall model.

Incremental and iterative models

　Incremental iteration is the software development life cycle model often used in the RUP unified process. Incremental and iterative are different but often together Use. So here we need to explain the concepts of increment and iteration. Suppose that four major business functions A, B, C, and D are to be developed, and each function needs to be developed for two weeks. For the incremental method, the The four functions can be divided into two increments to complete, the first increment completes the A and B functions, and the second increment completes the C and D functions; and for iterative development, it will be divided into two iterations. Development, the first iteration completes four basic business functions A, B, C, D but does not contain complex business logic, while the second function is gradually refined to supplement the complete related business logic. After the first month has passed At the beginning of the incremental development, A and B were all developed and C and D were not moved at all; when the iterative development was adopted, the four basic functions of A, B, C, and D had been completed.
RUP emphasizes that each iteration includes requirements, design and development, testing and other processes, and each iteration is a deliverable prototype after completion. The iterations are not parallel, and the requirements are still followed during each iteration -> Design->Development waterfall process. The length of the iteration cycle has a lot to do with the cycle and size of the project. Small projects can iterate once a week, and for large projects it can be 2-4 weeks. If the project does not have a good It is difficult for the architects who are the most experienced architects to plan the content and goals of each iteration, and verify the related delivery and output. Therefore, although the iterative model can well meet the user's delivery and changes in requirements, it is indeed a very difficult task. It is difficult to really use a good model.
　
In terms of risk elimination, both incremental and iterative models can well control and solve early risks. But the iterative model has more advantages in this regard. The iterative model can be more general in terms of To systematically think about problems, a relatively complete framework or prototype can be given from the earliest stage, and each subsequent iteration is a gradual refinement of the previous iteration. The

　standard incremental model in the industry often requires that all software requirements specifications be included in the software requirements specification. After it comes out, the subsequent design and development will be incremented. At the same time, each increment can also be a small version released independently. Since the overall design of the system often has a significant impact on the architecture and scalability of a system, the recommended increments It is best to start incrementing after the architectural design is completed, which can better ensure the robustness and scalability of the system.

　Prototype method

　Prototype is generally not a life cycle model used alone, and often combines waterfall and Incremental iteration and other methods are used together. For the spiral model, it can be understood as a life cycle model of waterfall + iteration + prototype + risk. For iterative development, the output of each iteration cycle can be regarded as the next stage The prototype to be refined. For the development of the waterfall model, we can also model the interface and operation in the requirements stage, and after forming the DEMO, we will communicate and confirm the requirements with the user.

　When your users have no experience in using information systems, and your system analysts do not have too much experience in requirements analysis and mining, the process of requirements analysis and research needs to be a heuristic process. And the prototype is this A good heuristic method that can quickly mine user requirements and reach a consensus on the understanding of requirements. Otherwise, even if the requirements signed by both parties are often not what the customer really wants.

　Prototypes can be divided into disposable and non-abandoned types. Yes. If the prototype is only a DEMO drawn for communicating with users in the requirements phase, this prototype is generally recommended to be discarded. For iterative development, the output of each iteration is a system that can run independently and contain basic functions. , is the basis for subsequent refinement. Such prototypes are generally not recommended to be discarded, and later design and development should be gradually improved based on the prototype.

　Rapid and agile development

　We generally use rapid and agile development as a methodology, and rarely use rapid and agile development as a methodology. It is used as a software development life cycle model. The purpose of agile is to reduce the output of heavy and unnecessary artifacts and improve efficiency. Instead of asking us to pick stages or processes, we should not analyze and design before doing development. Therefore, for waterfall, incremental iteration or prototype, we can learn from some good practices in agile methodologies, which are good supplements to the traditional life cycle model. For agile methodologies, I won't do too much description here.
Final summary on choosing a life cycle model

　　1. Try to use the waterfall model or the improved waterfall model when the early requirements are clear.
　　2. When the user has no experience in using information systems and the skills of the demand analyst are insufficient, the prototype must be used 3.
　　When there are many uncertain factors and many things cannot be planned in advance, try to use the incremental iteration and spiral model
　　. 4. Try to use the incremental iteration model when the demand is unstable
　　. Incremental model can be used, and software products are released
　　in multiple versions
　　7. The development of a new system must start incremental or parallel after the overall design is completed.
　　8. It is not recommended to use agile or iterative life cycle models for coders with less experience.
　　9. Incremental, iterative and prototype can be Comprehensive use, but each increment or iteration must have clear delivery and export guidelines.