History of the Waterfall ModelThe history of the Waterfall model is somewhat disrupted. It is often said or believed that the model was first put forth by Winston Royce in 1970 in one of his articles; whereas he did not even used the word “waterfall.” In fact Royce later presented this model to depict a failure or a flaw in a non-working model. So later on, this term was mostly used in writing about something that is often wrongly done in the process of software development – like a common malpractice.Royce was more of the opinion that a successful model should have the allowance of repetition or to go back and forth between phases which the waterfall model does not do. He examined the first draft of this model and documented that a recurrent method should be developed in this model. He felt the need of progressing only after a feedback from the previous stage has been received. This is known as the Iterative model.As opposed to the Waterfall model, the Iterative model is more practical and has room for maneuver. Followers of the Iterative method perceive the Waterfall model as inappropriate.
doesn’t analyze risk or have a good way to manage errors found later in the process.
Basic Description of the Waterfall Model Analysis: Research is being conducted which includes brainstorming about the software, what is going to be and what purpose is it going to fulfill. Design: After the first phase successfully completed and well thought out plan for the software development has been laid then the next step involves formulating the basic design of the software. Technical Design/ Detail Design: After the basic design gets approved, then a more elaborated technical design can be planned. Here the functions of each of the part are decided and the engineering units are placed for ex. Modules, programs etc.Implementation and Coding: In this phase the source code of the programs is written. Testing: At this phase, the whole design and its construction is put under a test to check its functionality. If there are any errors then they will surface at this point of the process. Integration: The company puts it in use after the system has been successfully tested. Acceptance Test: Probably done under users control and supervision, and in their environment. Management and Maintenance: It is needed to ensure that the system will continue to perform as desired.
- Therefore if there is a fault in this software it will be detected during one of the initial phases and will be sealed off for correction.- When new workers enter the project, it is easier for them to carry on the work from where it had been left. The newer methods don’t document their developmental process which makes it difficult for a newer member of the team to understand what step is going to follow next. The Waterfall Model is a straight forward method and lets one know easily what stage is in progress.
Many software projects are dependent upon external factors; out of which the client for which the software is being designed is the biggest factor. It happens a lot of times, that the client changes the requirement of the project, thereby influencing an alteration in the normal plan of construction and hence the functionality as well. The Waterfall Model doesn’t work well in a situation like this as it assumes no alteration to occur once the process has started according to plan. The other negative aspect of this model is that a huge amount of time is also wasted. For example if we study any software development process, we know that Phase II cannot be executed until Phase I has been successfully completed; so while the designers are still designing the software, time of the builders is completely wasted.Another disadvantage of this method is that the testing period comes quite late in the developmental process; whereas in various other developmental programs the designs would be tested a lot sooner to find the flaw at a time when a lot of time and money has not been wasted.Elaborate documentation during the Waterfall method has its advantages, but it is not without the disadvantages as well. It takes a lot of effort and time, which is why it is not suitable for smaller projects.
Spiral Model – risk driven rather than document drivenThe "risk" inherent in an activity is a measure of the uncertainty of the outcome of that activity High-risk activities cause schedule and cost overruns Risk is related to the amount and quality of available information. The less information, the higher the risk
Addresses Risk at every stage & let the stakeholders determine the outcome
Envisioning phase-Determine objectives, alternatives and constraintsObjectives: functionality, performance, hardware/software interface, critical success factors, etc. Alternatives: build, reuse, buy, sub-contract, etc. Constraints: cost, schedule, interface, etc.Planning phase-Evaluate alternatives, identify and resolve risks Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight schedules, poor process, etc. Resolve risks (evaluate if money could be lost by continuing system developmentDeveloping Phase- Develop next-level productCreate a design, Review design, Develop code, Inspect code, Test productStabilizing Phase- steadyDevelop project plan Develop configuration management plan Develop a test plan Develop an installation planDeploying Phase - install
Waterfall and spiral model
Reported by: Honey Mae Llanto
It is a model which wasdeveloped for softwaredevelopment; that is to createsoftware. This was first put forthby Winston Royce in 1970 in one ofhis articles.
Analysis Design Technical Design/ Detailed Design Implementation and Coding Testing Integration Acceptance Test Management and Maintenance
The project requires the fulfillment of onephase, before proceeding to the next. Provides structure to inexperienced staff Works well when quality is more importantthan cost or schedule
Many software projects are dependent uponexternal factors. A huge amount of time is also wasted. Little opportunity for customer to previewthe system. All requirements must be known upfront
Requirements are very well known Product definition is stable Technology is understood New version of an existing product
This model is preferred for large, expensiveand complicated projects. It combines thefeatures of Prototyping and Waterfallmodels.
Early and frequent feedback from users Users see the system early because of rapidprototyping tools Provides early indication of risks. Users can be closely tied to all lifecyclesteps
Time spent for evaluating risks too large The model is complex Risk assessment expertise is required May be hard to define objective, verifiablemilestones that indicate readiness toproceed through the next iteration
When creation of a prototype isappropriate Requirements are complex Significant changes are expected Users are unsure of their needs