The Waterfall Methodology By Winston Royce

Looking at each methodology from a different perspective, the management perspective, unveils additional benefits and setbacks. The rigidity of the Waterfall method for software development can be cumbersome when dealing with changing expectations, but it makes it easier for management to manage the project’s progression. Having clear goals makes it easy for managers to track the development process. It is more difficult to track a project where requirements are constantly evolving. Most of the projects (not involving software development) in our department are tracked through their process. As goals are achieved, completion nears 100%.

The Waterfall method is essentially a sequential approach for software development. At each stage of a project, the all tasks and goals need to be completed before moving to the next stage with the goal of reducing error. The first signs of the Waterfall method

Agile is a member of software development mode. Actually It is not a technique. I think not only it is a methodology, but also it is a process of development software. It will show and guide us to finish the development step by step according to the project required. However this kind of development mode is driven by human. The human will control the direction of the project.

As waterfall model has many advantages it is carrying a lot of disadvantages. It is hard to make changes after testing the stage. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. The software never work tile the few last steps and it is very hard to identify the errors at the beginning. It is gambling operation to make a software and successful of the software is unknown. It is not suitable for a large complex project.

Using the waterfall approach the system developers will be able to focus on one piece of the system and move on each part separately. This will give the design team more time to focus on small sections of the new coding. Moving from one stage to the next means that each step has been checked thoroughly and is completed.

Scrum Agile Methodologies is the most popular of the methodologies. It is an outline that uses fixed sprints. Once a sprints has ended, a scrum team works together with a new one which starts until the projected is finished. The team consists of:

This article by Phillip A. Laplante and Colin J. Neill of Penn State University explores the rumors of the demise of the waterfall model. The Waterfall process model progresses software products linearly from conception, through requirements, design, code, and test (Neill, 2004). The Waterfall method was developed in 1970 by Winston Royce when computer systems were monolithic, number-crunching entities with rudimentary front ends and users’ needs were filtered through the partisan minds of the computer illuminati building the systems (Neill, 2004). Most systems built in that time did not pay much attention to input from stakeholders, which is a good environment for the Waterfall method to work in – an environment where requirements seldom change after specification due to the fact that users are not involved in the development and therefore cannot provide feedback regarding incorrect assumptions or missing features (Neill, 2004).

Written off as a dying approach to software engineering I found that the Waterfall approach process was in fact alive and largely in use according to a Queue opinion article (Neill, 2004). While surveying professionals for the article in Queue, the Waterfall approach was reported to be in use by a third of the professionals that responded to the survey (Neill, 2004). I could not help but wonder if the Waterfall approach was some sort of zombie process that was back from being presumed dead, or if the method was being used for convenience purposes. Before I would be able to answer these questions for myself I would have to look into why these presumptions were made in the first place.

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

Since the method was developed for manufacturing and construction projects, it made sense in these industries that a portion of the project was fixed and unchangeable after a phase completed. Imagine the construction of a road, you prep and lay down a foundation then eventually lay down the final asphalt or concrete layer. It wouldn’t make sense to build in the ability to go back and change the foundation after the top layer was set. Obviously, software engineering is very different and therefore requires a much different approach to development. Besides slow turnaround, there were many other criticisms of the waterfall method. Some included redesign, rework, and retesting due to lack of knowledge about requirements when a project began. Also, due to the extremely long lead and delivery times, requirements changed or projects were dropped altogether leaving a company with a half-built loss on the balance sheet. An industry average put the estimated time for any software project using the Waterfall approach at 3 years. This was the environment that enabled a few forward-thinking developers to meet and design a new and better approach.

The traditional development method requires the definition and documentation of a stable set of requirements at the beginning of the project. It was inherited by other projects mainly related to construction which focused on the completion of one phase of production before moving on to the next phase, for example, laying the foundations of a building first and then proceeding with the further stages (Bowes 2014). Similarly, in Waterfall, the requirement gathering and designing work is done upfront before any coding takes place. The basic notion behind the traditional development approaches is that the projects are comparatively less complex, linear and predictable with clearly defined system boundaries which makes it simple to plan and follow without having any room for changes (Spundak 2014). Moreover, traditional development method depicts the requirements document as he key piece of documentation. The gathering of all the requirements, getting a sign off from the customer and then starting with the development of the project gives the project a limit of

Focus is kept on the recurrence of condensed work cycles and also at the functional product yielded by the outcome, but in waterfall technique only once chance is been given to the development team to keep the project aspects right. But under the agile technique each and every feature of development including the design, requirements, is thoroughly checked under its lifecycle (Mahfuj et al, 2012). There is always some time to steer in another direction if a team stops at regular interval say after every two weeks and re-evaluates the project done.

The agile software methodology uses teams that are self-organized and can develop incremental periods of work rather than working for long periods of time. Having face-to-face collaboration is preferable over written documentation. It tends to be more adhesive and produces better products in the end. Having the ability to change the direction/plan at any point during the project is possible. If change is not accommodated throughout the project, the team will not have set realistic expectations and it will be difficult to meet the anticipated deadline time period. The agile methodologies value the individual and interactions between the team over processes and other tools. When the agile software development approach is used, the team is

incremental development process makes it the opposite to the rigid requirement needs of the Waterfall method. Agile methodologies are open to change as the project starts and progresses. The contrasting requirements need of the two methodologies, is one of the main contrast points in today’s project life cycle processes. There is a constant struggle between the two processes even in today’s business landscape. I have worked at Google as a program manager - mobile and after Google, I worked at a satellite manufacturing company called Space Systems Loral. The former is a software company and latter is a hardware company. At Google, they have embraced agile methodologies for software development, as the company is very progressive in nature. They are also very open to feedback from their users, and therefore agile allows them to take in product suggestions and address users’ needs with no predetermined rigid requirements from clients or users for initial requirements. Work is done in mini project or sprints format and when there is a need to shift directions, everything already worked on is scrapped if not necessary, and then a complete reset occurs. Since the project’s initial framework is not known at the time the project starts, the final product can deviate drastically from what was initially envisioned. At Space Systems Loral, being that it is a hardware satellite manufacturing company, they inherently have to adopt the waterfall methodology for their needs.

The waterfall model consists of five phases such as requirements, Design, implementation, verification and maintenance. The method is a sequential design process where progress is seen as flowing downwards in a steadily manner, each development phase has its own distinct goals. The model is similar to water flowing down a cliff it can only flow in one way and cannot go back up it is the same with waterfall development ,after a development phase is completed it proceeds to the next development phase you cannot go back.