Software development models include?

Unfortunately, many products are developed using a "build-and-fix" model. In this model, there are no specifications and no design, and the software is modified over and over again as the customer needs it.

In this model, the developer gets the project and immediately writes a program based on the requirements, debugs it, and produces the first version of the software. After it is made available to the user, if there are errors in the program, or if the user makes new requests, the developer reworks the code until the user is satisfied.

This is a workshop-like development method, which is not bad for writing small programs of a few hundred lines, but this method is unsatisfactory for any scale of development, and its main problems are:

(1) Lack of planning and designing links, the structure of the software gets worse and worse with constant modifications, which leads to the impossibility of further modifications;

(2) Neglect of requirements link, bringing great risks to software development;

(3) no consideration of testing and program maintainability, and there is no documentation, the maintenance of the software is very difficult.

2. Waterfall Model

Winston Royce proposed the famous "Waterfall Model" in 1970, and until the early 1980s, it was the only widely used software development model.

The waterfall model, as shown in the figure, divides the software life cycle into six basic activities: planning, requirements analysis, software design, programming, software testing, and operation and maintenance, and stipulates a fixed order for them to follow each other from top to bottom, just like a waterfall flowing down the waterfall, step by step.

In the waterfall model, software development activities in strict accordance with the linear way, the current activity to accept the results of the previous activity, the implementation of the work required to complete the content. The result of the work of the current activity needs to be validated, and if the validation passes, the result is used as an input to the next activity to continue with the next activity, otherwise it returns to be modified.

The waterfall model emphasizes the role of documentation and requires careful validation at each stage. However, the linear process of this model is too idealized and is no longer suitable for modern software development models, and has almost been abandoned by the industry. Its main problems are:

(1) the division of each phase is completely fixed, and a large amount of documentation is generated between phases, which greatly increases the workload;

(2) because the development model is linear, the user has to wait only until the end of the whole process to see the development results, which increases the risk of development;

(3) Early errors may not be discovered until the testing phase at a later stage of development, which can have serious consequences.

We should recognize that "linear" is the easiest way for people to grasp and apply ideas. When people encounter a complex "non-linear" problem, always try to decompose or transform it into a series of simple linear problems, and then solve them one by one. The whole of a software system may be complex, but the individual subroutines are always simple and can be realized in a linear way, otherwise the work would be too tiring. Linearity is simplicity, and simplicity is beautiful. Once we understand the spirit of linearity, we should stop applying the appearance of a linear model and use it. For example, the incremental model is essentially a segmented linear model, the spiral model is a succession of curved linear model, in other models can also find the shadow of the linear model.

3. Rapid Prototype Model

The first step in Rapid Prototype Modeling is to build a rapid prototype that allows customers or future users to interact with the system, and users or customers to evaluate the prototype and further refine the requirements of the software to be developed. By gradually adjusting the prototype to meet the customer's requirements, the developer can determine what the customer's real needs are; the second step builds on the first step to develop a software product that satisfies the customer.

It is clear that the rapid prototyping approach can overcome the shortcomings of the waterfall model and reduce the development risk due to unclear software requirements with significant results. The key to rapid prototyping is to build a software prototype as quickly as possible, and the prototype that is built is discarded once the customer's true requirements have been determined. Thus, the internal structure of the prototype system is not important; what is important is that the prototype must be built quickly and subsequently modified quickly to reflect the customer's needs.

4. Incremental Model

Also known as an evolutionary model. In the same way that a building is constructed, software is built one step at a time. In the incremental model, software is designed, implemented, integrated, and tested as a series of incremental artifacts, each of which consists of pieces of code that provide specific functionality from multiple interacting modules.

The incremental model does not deliver a runnable complete product at each stage, but rather a subset of the runnable product that satisfies the customer's needs. The entire product is broken down into building blocks, and the developer delivers the product building block by building block. The advantage of this is that software development is more adaptable to change, and the customer can continually see the software being developed, thus reducing development risk. However, the incremental model also has the following drawbacks:

(1) Because each component is gradually incorporated into the existing software architecture, adding components must not destroy the constructed part of the system, which requires the software to have an open architecture.　　

(2) During the development process, changes in requirements are inevitable. The flexibility of the incremental model allows it to adapt to such changes much better than the waterfall model and rapid prototyping model, but it is also easy to degenerate into a model of making changes as you go along, so that the control of the software process loses its wholeness.

When using an incremental model, the first increment is often the core product that implements the basic requirements. After the core product is delivered to users, it is evaluated to form a development plan for the next increment, which includes modifications to the core product and the release of some new functionality. This process is repeated after each incremental release until a final, complete product is produced.

For example, use the incremental model to develop word processing software. Consider that the first increment releases basic file management, editing, and document generation functionality, the second increment releases more refined editing and document generation functionality, the third increment implements spelling and grammar checking functionality, and the fourth increment completes advanced page layout functionality.

5. Spiral Model (Spiral Model)

In 1988, Barry Boehm formally published the "Spiral Model" of software system development, which combines the waterfall model with the rapid prototyping model, emphasizes the risk analysis ignored by other models, and is particularly suitable for large and complex systems.

As shown in the figure, the spiral model proceeds through a number of iterations along a spiral, with the following activities represented in the four quadrants of the figure:

(1) Planning: defining the software goals, selecting an implementation plan, and figuring out the constraints of the project's development;

(2) Risk analysis: analyzing and evaluating the options selected, and considering how to identify and eliminate risks;

(3) Implementation engineering: implementing software development and validation;

(4) Customer assessment: evaluating the development effort, suggesting corrections, and formulating next steps.

The spiral model is risk-driven, emphasizes options and constraints to support software reuse, and helps to incorporate software quality as a special goal in product development. However, the spiral model has some limitations, as follows:

(1) The spiral model emphasizes risk analysis, but it is not easy to ask many customers to accept and believe in this analysis and to react to it, so this model tends to be adapted to internal, large-scale software development.

(2) There is no point in performing a risk analysis if performing it will significantly affect the profitability of the project; therefore, the spiral model is only appropriate for large-scale software projects.

(3) Software developers should be good at finding possible risks and analyzing them accurately, or else they will pose greater risks.

A phase begins with identifying the goals of the phase, the options for accomplishing those goals and their constraints, and then analyzing the development strategy of the program from a risk perspective, trying to eliminate various potential risks, sometimes by building prototypes. If certain risks cannot be eliminated, the program is immediately terminated, otherwise the next development step is initiated. Finally, the results of the phase are evaluated and the next phase is designed.

6. fountain model (also known as object-oriented survival model, OO model)

The fountain model is more incremental and iterative in nature compared to the traditional structured survival, where phases of survival can overlap and iterate multiple times, and sub-survival can be embedded throughout the survival of the project. Just like water sprayed up and can fall down, it can fall in the middle or at the very bottom.

7. Intelligent Modeling (Four Generation Technology (4GL))

Intelligent modeling has a set of tools (e.g., data querying, report generation, data manipulation, screen definitions, code generation, high-level graphical functions, and spreadsheets), each of which enables the developer to define certain features of the software at a high level and to automatically generate these developer-defined software into source code


Source Code.

This approach requires the support of a fourth-generation language (4GL), which differs from the third-generation languages in that its main features are an extremely user-friendly interface that allows even untrained non-professional programmers to write programs in it, and a declarative, interactive, and non-procedural programming language. 4GL also features efficient program code, intelligent default assumptions, and a complete database and application program generator. 4GL also features efficient program code, intelligent default assumptions, a complete database, and an application program generator. The popular 4GLs currently on the market (e.g., Foxpro, etc.) share these characteristics to varying degrees. However, 4GL is currently limited to the development of small to medium-sized applications for transactional information systems.

8. Hybrid model (hybrid model)

Process development model, also known as hybrid model (hybrid model), or meta-model (meta-model), the combination of several different models into a hybrid model, which allows a project to develop along the most efficient path, which is the process development model (or hybrid model). In fact, some software development organizations use several different development methods to form their own hybrid models. Comparison of Various Models Each software development organization should choose a software development model that is appropriate for the organization and should vary with the characteristics of the particular product currently being developed in order to minimize the disadvantages of the chosen model and to take full advantage of its strengths. The following table lists the advantages and disadvantages of several common models. Advantages and disadvantages of various models:

Model AdvantagesDisadvantagesWaterfall ModelDocumentation-driven system may not meet customer needsRapid prototyping modelFocus on meeting customer needsMay result in a poorly designed, inefficient, and difficult-to-maintain systemIncremental ModelDevelopmentEarly feedback is timely and easy to maintainRequires an open architecture and may be poorly designed and inefficientSpiral ModelRisk-driven Risk analysts need to have Experienced and fully trained

9. RUP Model

RUP (Rational Unified Process) model is a set of development process model proposed by Rational, which is a general business process for object-oriented software engineering. It describes a set of related software engineering processes that share the same structure, i.e., the same process architecture.RUP provides a disciplined approach to assigning tasks and responsibilities in a development organization, with the goal of ensuring that high-quality software that meets the needs of end-users is developed within a predictable schedule and budget.RUP has two axes, one of which is the time axis, which is dynamic. The other axis is the workflow axis, which is static. On the time axis, RUP is divided into four phases: initial phase, refinement phase, construction phase, and release phase. Each phase uses the concept of iteration. On the workflow axis, RUP designs six core workflows and three core support workflows. The core workflow axis includes: business modeling workflow, requirements workflow, analysis and design workflow, implementation workflow, testing workflow, and release workflow. The core support workflows are: Environment Workflow, Project Management Workflow, and Configuration and Change Management Workflow. rup brings together the best of modern software development from a variety of perspectives, and provides a flexible format that can be adapted to suit the needs of a wide range of projects and organizations. rup is a business model with a very high degree of flexibility. As a business model, it has very detailed process guidance and templates. However, it is also complex and can be costly to master. It places a high demand on project managers in particular.

It has the following characteristics:

(1) incremental iterations, each iteration follows the waterfall model to be able to control and solve the risk in the early stage;

(2) the complexity of the model, which requires project managers to have a strong management ability.

10. IPD model

IPD (Integrated Product Development) process is a set of integrated product development process put forward by IBM, is very suitable for complex large-scale development projects, especially involving the combination of hardware and software projects.

IPD from the perspective of the entire product, the process takes into account from systems engineering, research and development (hardware, software, structure, industrial design, testing, data development, etc.), manufacturing, finance to market, procurement, technical support and all processes. It is an end-to-end process.

In the IPD process total **** divided into six phases (conceptual phase, planning phase, development phase, validation phase, release phase and lifecycle phase), four decision review points (conceptual phase decision review points, planning phase decision review points, accessibility decision review points and end-of-lifecycle decision review points) as well as six technical review points.

The IPD process is a staged model with shades of the waterfall model. The model breaks down a large and complex system and reduces risk by using a comprehensive and complex process. In part, the model is about improving the quality of the overall product and gaining market share through process costs. Since the process does not define a mechanism for backtracking, it is not well suited for projects where requirements change frequently. It is also not well suited for smaller projects.