Software development model (SSD9 Life-Cycle Methodologies)

Source http://hi.baidu.com/%D0%D0%D7%DF%D4%DA%BF%D5%D6%D0/blog/item/7bbb261bc20988f2af513319.html

1. Build-and-Fix Model)

There are no requirements or specification or design attempts to implement the product. Developers simply put the code together and the software is constantly modified as the customer needs it. in this model, developers get the project and immediately write programs as needed. After debugging passes, the first version of the software is generated. After the application is provided to the user, if a program error occurs or the user puts forward a new requirement, the developer re-modifies the code until the user is satisfied. This is a development method similar to workshops. It is good for writing hundreds of lines of small programs, but this method is not satisfactory for any scale of development. The main problem is:

(1) The software structure cannot be modified because of the lack of planning and design processes;
(2) Ignoring demand links brings great risks to software development;
(3) It is very difficult to maintain the software without considering the testing and program maintainability and without any documents.

2. Waterfall Model)

The waterfall model divides the software life cycle into six basic activities, including planning, demand analysis, software design, programming, software testing, and operation and maintenance, they also define a fixed order of top-down and interconnection, like waterfall flow, falling down step by step. This phase is not completed until the documents at any stage are completed and the products at this stage are recognized by the customer and the SQA team. Each stage contains a test, which is document-driven. It emphasizes the role of the document and requires careful verification at each stage. However, the linear process of this model is too idealistic. It is no longer suitable for modern software development models and almost abandoned by the industry. The main problem is:

(1) The division of each stage is completely fixed, and a large number of documents are generated between stages, greatly increasing the workload;
(2) because the development model is linear, the user can see the development results only at the end of the entire process, thus increasing the development risk;
(3) Early errors may not be detected until the test phase at the end of the development stage, resulting in serious consequences.

3. RAPId Prototype Model)

The first step is to create a quick prototype for users or customers to try out. If the customer thinks that the majority of requirements are met, the developer will draft the specification document. The second step is to develop customer-satisfied software products based on the first step. The key to rapid prototyping is to build software prototypes as quickly as possible. Once the customer's real needs are identified, the prototypes will be discarded. Therefore, the internal structure of the prototype system is not important. What is important is that the prototype must be established quickly and then the prototype must be modified quickly to reflect the customer's needs.

4. Incremental Model)

In an incremental model, software is designed, implemented, integrated, and tested as a series of incremental components, each component is composed of code fragments that provide specific functions formed by multiple interacting modules .. Incremental models do not deliver a complete product that can run at each stage, but deliver a subset of products that meet customer needs. The entire product is divided into several components, and developers deliver the product one by one. The advantage of this is that software development can better adapt to changes, and customers can constantly see the developed software, this reduces development risks. However, the incremental model also has the following defects:

(1) Since each component is gradually incorporated into the existing software architecture, adding the component must not destroy the structure of the system, which requires the software to have an open architecture.
(2) demand changes are inevitable during the development process. The flexibility of the incremental model makes it better to adapt to this change than the waterfall model and the rapid prototype model, but it is also easy to degrade to the side-to-side modeling, instead, the control of software processes loses integrity.

When using the incremental model, the first increment is usually the core product that meets basic requirements. After core products are delivered to users for use, they form the next incremental development plan, which includes modifications to core products and release of some new features. This process repeats after each incremental release until the final perfect product is produced.

5. synchronous-stable Model (Synchronize-and-Stabilize Model) is also known as the Microsoft mode.

The work is divided into three or four components, each of which is completed by the Group independently. The work is completed every day. The components are put together to test and debug the products (synchronized ). At the end of each component, the system performs stabilization, fixes existing errors, and freezes the component (that is, the specification is not modified ). This model is only successful at Microsoft.

6. Spiral Model)

It combines the waterfall model with the rapid prototype model, and emphasizes the risk analysis ignored by other models, which is especially suitable for large-scale and complex systems. You can simply think of it as a waterfall model with risk analysis before each stage, and try to reduce risks before each stage starts. If you cannot reduce major risks, the project will stop. A spiral model is driven by risks and emphasizes optional solutions and constraints to support software reuse. This helps to integrate software quality into product development as a special goal. However, the spiral model also has certain restrictions, as shown below:

(1) The spiral model emphasizes risk analysis, but it is not easy for many customers to accept and trust this analysis and make relevant responses. Therefore, this model is often suitable for large-scale internal software development.
(2) If the implementation of risk analysis will greatly affect the profit of the project, it is meaningless to carry out risk analysis. Therefore, the spiral model is only suitable for large-scale software projects.
(3) software developers should be good at finding possible risks and accurately analyzing them; otherwise, they will bring greater risks.

7. fountain model (Object-Oriented Life-Cycle Models)

Compared with the traditional structured survival model, the fountain model has more incremental and iterative properties, and each stage of the survival can overlap with each other and repeatedly, in addition, the sub-lifetime can be embedded throughout the entire life cycle of the project. Just like the water sprayed up and down, it can fall in the middle or at the bottom. There are no obvious boundaries between the stages of the model, so developers can develop the model simultaneously. It can improve the efficiency of software project development, save development time, and adapt to the object-oriented software development process. Since the fountain model overlaps in various development stages, a large number of developers are required in the development process, which is not conducive to project management. In addition, this model requires strict document management, making the review more difficult, especially when various information, requirements and materials may be added at any time.

Comparison of Models (Comparison of the Models)

Life-Cycle Model	Strengths	Weaknesses
Build-and-Fix	Fine for short programs that do not require maintenance	Totally unsatisfactory for nontrivial programs
Waterfall	Disciplined; Document-driven	Product may not meet customer needs
Rapid Prototyping	Ensures product will meet client's needs	Temptation to reuse code that shocould be reimplemented instead
Incremental	Maximized early return on investment; Promotes maintainability	Requires open architecture; May degenerate into build-and-fix
Synchronize-and-Stabilize	Future users 'needs are met; Ensures components can be integrated	Has not been widely used outside Microsoft
Spiral	Incorporates features of all the models above	Can be used only for large-scale, in-house projects; Developers must be competent in risk management
Object-Oriented	Supports iteration within phases, parallelism between phases	May degenerate into CABTAB