Advantages and Disadvantages of Waterfall Model and Iterative Model in R&D Modeling

The waterfall model is to specify the activities of the software life cycle as a number of phases connected in a fixed order, like a waterfall, and ultimately get the software product.

The core idea of the waterfall model is to simplify the problem according to the process, to separate the implementation of the function and design, to facilitate the division of labor, that is, the use of structured analysis and design methodology

Separate the logical implementation from the physical implementation. The software life cycle is divided into six basic activities such as planning, requirements analysis, software design, programming, software testing and operation and maintenance,

and stipulates that they are from top to bottom, the fixed order of the interconnection, as the waterfall waterfall, level by level.

The waterfall model has the following advantages

1) Provides checkpoints for the project by phase.

2) Once the current phase is complete, you only need to focus on subsequent phases.

3) Can be iterated in an iterative model each round very similar to a small waterfall model.

Incremental iteration is used in the waterfall model. Each iteration produces a runnable version while adding more functionality. Each iteration must be tested for quality and integration.

4) It provides a template that allows analysis, design, coding, and testing to be guided by the same ****.

The waterfall model has the following drawbacks

1) The division of the various phases is completely fixed, generating a large amount of documentation between phases, which greatly increases the workload.

2) Because the development model is linear, users can only see the results at the end of the process, which increases the development risk.

3) Tracking the various project phases through too many mandatory completion dates and milestones.

4) The prominent disadvantage of the waterfall model is that it does not adapt to changes in user requirements.

An iteration consists of all the development activities that result in a product release (a stable, working version of the product) and all the other peripheral elements necessary to use that release.

In a way, an iteration is a complete passage through all the workflows: planning, requirements analysis, design, coding and testing efforts, and

the release process. In essence, it is similar to a small waterfall project. Each iteration produces a release-ready product that is a subset of the final product.

Benefits

Compared to the traditional waterfall model, the iterative process has the following advantages:

1) Reduces the risk of developing on an increment. If an iteration completes with software that does not meet the customer's requirements, the loss is only the cost of the one iteration that was developed incorrectly.

2) Reduces the risk that the product will not reach the market on the established schedule. By identifying risks early in development, they can be addressed early rather than rushed later in development.

3) Accelerates the overall development effort. Because developers know exactly where to focus their efforts, they work more efficiently.

4) Since user requirements are not fully defined at the outset, they are usually refined in subsequent phases. Therefore, the iterative process model makes it easier to adapt to changes in requirements.

Disadvantages

The ability to control the pace of the product (setting weekly goals, prioritizing requirements, and handling ad-hoc requirements) requires a high level of skill, otherwise it is easy to fall into the rhythm of working overtime on release day every week.

After contacting a few Internet startups, I found that there is an obvious misunderstanding on rapid iteration: it only focuses on rapid iteration at the product feature level, and ignores rapid iteration at the system architecture level.

The result is that the back-end architecture of the system is still a mess, and even when there is no back-end architecture, a bunch of features have been stacked on the product.

This is like building on ground with a sloping foundation - the higher you build, the more dangerous it is. When you realize that your back-end system is already very sick and needs to be revamped, you realize that it is already running all sorts of features, big and small, that are piling up.

The lack of focus on iterative back-end architecture is a common problem for a number of reasons:

1) The initial product is small in terms of user size, and performance is not the main bottleneck

2) There are no good architects on the team, and optimization is not a priority.

3) Back-end architecture optimization is a slow job, it is not as fast as the product feature level iteration can be perceived, for the strong product-driven rather than strong technology-driven company, not enough attention.

4) Back-end architecture optimization is more of a detailed work, it is not like product features have obvious "output", for non-technical leaders or KPI-oriented company culture, employees to optimize the back-end of the willingness is not strong.

5) Product delivery schedule pressure is relatively large, there is no time to think about the optimization of the architecture, the energy is focused on how to achieve functionality above

The figure below is Each iteration of the product look, with the increase in iteration, the product is more and more rich in functionality, as each iteration is based on user feedback to adjust the needs of the final product is also responsible for the user's requirements