Software Development Process and Waterfall Model
The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design,Construction, Testing and Maintenance. The waterfall development model originates in the manufacturing and constructionindustries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software developmentmethodologies existed at the time, this hardware-oriented model was simply adapted for software development.
The first formal description of the waterfall model is often cited as a 1970 article byWinston W. Royce, though Royce did not use the term “waterfall” in this article. Royce presented this model as an example of a flawed, non-working model (Royce 1970). This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice.  Waterfall Model Application Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors.
Software Development Process and Waterfall Model Essay Example
Some situations where the use of Waterfall model is most appropriate are: Requirements are very well documented, clear and fixed. Product definition is stable. Technology is understood and is not dynamic. There are no ambiguous requirements. Ample resources with required expertise are available to support the product. The project is short. Pros Cons Simple and easy to understand and use Easy to manage due to the rigidity of the model . each phase has specific deliverables and a review process. Phases are processed and completed one at a time. Works well for smaller projects where requirements are very well understood.
Clearly defined stages. Well understood milestones. Easy to arrange tasks. Process and results are well documented. No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Not a good model for complex and object-oriented projects. Poor model for long and ongoing projects. Not suitable for the projects where requirements are at a moderate to high risk of changing. So risk and uncertainty is high with this process model. It is difficult to measure progress within stages. Cannot accommodate changing requirements.