Common Software Development Models

Software Engineering involves personnel management, project management, requirement analysis, system design, Program Design, test, and maintenance, as shown in Figure 1.5. The software development model is a modeling of the software process, that is, connecting each link with a certain process, and operating the entire process in a standardized manner, such as the production line of the factory.

Figure 1.5 main steps of Software Engineering

Build-and-fix Model)
Unfortunately, many products are developed using the "make and modify" model. In this model, there is neither specification nor design. The software is constantly modified as the customer needs it, as shown in Figure 1.6.

 

Figure 1.6 edge modeling

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 the program encounters an error or the user puts forward a new requirement, the developer will modify it again.CodeUntil 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.

Waterfall Model)
Winston Royce proposed the famous "Waterfall Model" in 1970. It was the only widely used software development model until the early 1980s S.
As shown in Waterfall Model 1.7, it divides the software life cycle into six basic activities, including planning, requirement 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.

 

Figure 1.7 Waterfall Model

In the waterfall model, various activities of software development are carried out in a linear manner. The current activity accepts the work results of the previous activity and the work required for implementation. The work result of the current activity needs to be verified. If the verification is successful, the result is used as the input for the next activity to continue the next activity. Otherwise, the modification is returned.
The waterfall model 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.

We should realize that "Linearity" is the easiest way for people to master and use it skillfully. When people encounter a complicated "non-linear" problem, they always try every means to break it down or convert it into a series of simple linear problems, and then solve them one by one. A software system may be complex as a whole, and a single subroutine is always simple and can be implemented in a linear way. Otherwise, it will be too tired to work. Linearity is concise, and simplicity is beautiful. When we understand the spirit of linearity, we should not just use the appearance of a linear model, but live it. For example, the incremental model is essentially a linear model with segments, while the spiral model is a series of curved linear models. The shadows of linear models can also be found in other models.

Rapid Prototype Model)
The first step of the rapid prototyping model is to build a rapid prototype to realize the interaction between the customer or the future user and the system. the user or the customer evaluates the prototype and further refine the Needs of the software to be developed. By gradually adjusting the prototype to meet the customer's requirements, developers can determine what the customer's real needs are. The second step is to develop the customer's satisfied software products based on the first step.
Obviously, the rapid prototyping method can overcome the shortcomings of the waterfall model and reduce the development risks caused by unclear software requirements, with remarkable results.

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.

Incremental Model)
Similar to building, software is also built step by step. In an incremental model, software is designed, implemented, integrated, and tested as a series of incremental components, each component is composed of code snippets that provide specific functions by multiple interacting modules, as shown in Figure 1.8.
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 products 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.

Figure 1.8 Incremental Model

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.
For example, you can use an incremental model to develop a word processing software. You can consider that the first step is to incrementally release basic file management, editing, and document generation functions, and the second step is to release more comprehensive editing and document generation functions, the third step implements spelling and grammar check functions, and the fourth step completes Advanced page layout functions.

Spiral Model)
In 1988, Barry Boehm officially published the software system development "spiral model", which combines the waterfall model with the rapid prototype model and emphasizes the risk analysis ignored by other models, it is particularly suitable for large and complex systems.
As shown in 1.9, the spiral model carries out several iterations along the spiral line. The four quadrants in the figure represent the following activities:
(1) Develop a plan: Determine the software objectives, select the implementation scheme, and clarify the constraints of project development;
(2) Risk analysis: analyzes and evaluates the selected scheme and considers how to identify and eliminate risks;
(3) Implementation Project: implement software development and verification;
(4) customer evaluation: evaluates the development work, proposes amendments, and develops the next plan.
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.

Figure 1.9 Spiral Model

One stage is to first determine the objectives of the stage, complete the selection scheme and its constraints for these objectives, and then analyze the development strategy of the scheme from the perspective of risks, and strive to eliminate various potential risks, sometimes it is necessary to build a prototype. If some risks cannot be ruled out, the plan will be terminated immediately. Otherwise, the next sending step will be started. Finally, evaluate the results of this stage and design the next stage.

Comparison of various models
Each Software Development Organization should select a software development model suitable for the Organization and change with the specific product features being developed to reduce the disadvantages of the selected model and make full use of its advantages, the following table lists the advantages and disadvantages of several common models.

Model	Advantages	Disadvantages
Waterfall Model	Document-driven	The system may not meet the customer's needs
Quick prototyping	Focus on meeting customer needs	Poor system design, low efficiency, and difficult to maintain
Incremental Model	Early Development Feedback is timely and easy to maintain	Open Architecture is required, which may result in poor design and low efficiency.
Spiral Model	Risk-driven	Risk analysts need to be experienced and fully trained

 

http://hi.baidu.com/yaolihui/blog/item/a8e05a38fd30702696ddd82a.html