Waterfall Model/Improved Waterfall Model
Although there are still many problems to be solved with the waterfall model, the waterfall model is still the most basic and effective software development life cycle model to choose from.
The waterfall model requires software development to be carried out strictly in accordance with the requirements-> analysis-> design-> coding-> testing stages, each stage of which can define clear outputs and verification criteria. The waterfall model can organize relevant reviews and validations after each stage is completed, and only after the review is passed can it move on to the next stage.
Since each stage needs to be validated, the waterfall model requires that each stage has a clear document output, and for the strict waterfall model, each stage should not overlap, but should be able to move to the next stage after the review is passed and the relevant output has been baselined.
The advantage of the waterfall model is still that it can guarantee the high quality of the entire software product and ensure that defects can be detected and solved in advance.
The waterfall model can ensure that the system is fully grasped as a whole, so that the system has good scalability and maintainability. However, for projects where the upfront requirements are not clear and it is difficult to be clear in a short period of time, it is difficult to make good use of the waterfall model. In addition, for small and medium-sized projects, requirements design and developers often invest in the project after the project starts, rather than in stages, so the use of the waterfall model will lead to too many idle project human resources, which must also be considered.
Many people tend to be constrained by schedule over the waterfall model, which is often a wrong view.
A key factor that causes this situation is often a lack of manpower during the conceptual demand phase. Therefore, under the condition that the manpower can be fully guaranteed in the conceptual requirements stage, the waterfall model and the iterative model will not be much different in the development cycle. On the contrary, many projects are not used well for iterative or agile models, in order to catch up with the schedule, the requirements are not clear in the early stage, and the coding begins without a general architectural design, and a large number of rework occurs in the later stage and severely
affects the schedule.
Architectural 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. The interface between each functional module can be clearly defined.
In this case, when the detailed design of module B is completed, it is often not necessary to wait until the detailed design of other modules is completely completed before starting to code, so after the architecture design is completed, the system can be divided into multiple modules for parallel development, and each module still follows the waterfall model idea of first design and coded testing. This is one of the most important improvement ideas for the waterfall model, and it can also be said that this is a model of incremental development
when the development of a new system has multiple completely unrelated independent requirements for functional development, you can also choose to divide the entire development process into multiple waterfalls according to independent requirements. the biggest problem with this approach is that without a completely overall design, architects cannot master plan from the scalability and reuse of the system after insight into all the requirements.
there is a method of compressing schedule in project management called rush work, so the additional improvement of the waterfall model is to pass through, the various stages of appropriate overlap to achieve the efficient use of resources. for example, through discussion, the implementation determined by the meeting can begin directing the next phase of work
No comments:
Post a Comment