Reexamining the Waterfall Model 1 Reexamining the Waterfall Model

Reexamining the Waterfall ModelUniversity of Maryland University CollegeGeorgia Nelson – MSWE 635 – June 16, 20071. IntroductionIn the early 1970s, Dr. Winston Royce introduced a solution to the oncoming software crisis in the form of a software development life cycle model called the "Waterfall Model" (Dorfman & Thayer, 2000, p. 404). It proposed a stepwise series of finite development stages starting with requirements and ending with deployment. At the time, the introduction of such a model was revolutionary to the way engineers approached software development given the fact that previously engineers merely approached software development in a very ad hoc manner. The Waterfall Model brought engineering concepts to software.Guimarães and Vilela (2005) believed the Waterfall Model to be one of the "most important models ever published," so why is it that engineers tend to avoid its use in today's software development environment (p. 340)? The traditional approach taken by the Waterfall Model pushes a project through a very rigid, top-down approach. This can oftentimes cause problems in the later stages where problems with requirements or design may inadvertently pop up. Problems such as these can increase costs and cause schedule slips to occur.It is not always necessary to turn toward iterative, rapid application development approaches such as Barry Boehm's "Spiral Model" to resolve the pitfalls of the Waterfall Model (as cited in Dorfman & Thayer, 2000, p. 415). Although the Waterfall Model is linear and provides little room for development flexibility, it can be quite useful in environments where project organization is top-down, processes and methodologies are strictly adhered to, and requirements are well defined from the beginning.2. Top-Down Project OrganizationA project that is organized in a top-down manner is formal, rigid, and exact in its operation. The chain of command is clearly communicated, tasks are well defined, and the project's goals are unambiguous in such a development environment (Constantine, 1993, p. 38). While top-down project organization may leave little room for employees to flex their creative muscles or devise new methodologies during development, it is the perfect environment, in which the Waterfall Model may succeed.The strict nature of the top-down approach can be helpful in constraining the urge for bottom-level employees and middle management to attempt to "initiate strategies on their own," which can confuse anddisrupt the project's development flow (Yourdon, 2002, p. 156). When individuals at the topmost level are making decisions, there tends to be less noise and deviation from the project's plan. This ensures that tasks are well defined before pushing to the next stage of development without spending extra time listening to the input of bottom-level employees. Their input can increase the likelihood of requirements additions or changes that can delay a project's development. Taking the top-down organizational approach can make it easier for management to lay down finite end-points and deliverables at each stage of the Waterfall Model.3. Solid Development ProcessesRock solid processes can help a company achieve a great deal of control over their development practices. Documentation plays a big role in the maturity of the methodologies utilized by a company. Since the Waterfall Model is organized in a series of linearly progressive stages, it encourages engineers to document a great deal before proceeding to the next stage (Guimarães & Vilela, 2005, p. 340). The set of documents delivered at the end of each Waterfall Model stage firmly defines the findings of the previous stage, and all parties must review and approve them before the project can progress.The Capability Maturity Model (CMM) describes the maturation level of a company's ability to develop and maintain software (Dorfman & Thayer, 2000, p. 427). What really sets one maturation level apart from another are the processes that make software development progress smoothly. A company with a high CMM level has a documented process that can be repeated, improved, and standardized (Dorfman & Thayer, 2000, p. 429). Under the Waterfall Model, this is an extremely important characteristic to possess. With it, engineers can feel confident in their decisions that cement each stage at a comfortable level that can both push forward and abate any risks that may be thrown at the project later on.4. Early Requirements DefinitionPerhaps one of the largest circumstances under which the Waterfall Model may succeed is the early definition of requirements. As the first stage, it is crucial that requirements analysis exit with a set of well-defined and documented requirements in order to avoid the costly mistake of misinterpretation. Faulk stated that the costs of repairing requirements failures on a software development project are "relative" and "rise quickly" with each stage of development (as cited in Dorfman & Thayer, 2000, p. 85). In other words, discovering a missing requirement during implementation will cost ten times as much to fix as it would if it were found during requirements analysis (Dorfman & Thayer, 2000, p. 85). This is due, in part, becausenot only will the code need to change, but so will the design, product specifications, and all other documentation leading up to the implementation stage.Oftentimes, gathering requirements can be like pulling teeth out of a shark. Customers rarely understand the full scope of what they want from the product, and engineers have a difficult time relating to their needs (Dorfman & Thayer, 2000, p. 87). Requirements analysis strives to lessen the pain of defining product requirements through a series of elicitation sessions. If these sessions are successful, then engineers can document the requirements and have them approved to a point that allows the development team to proceed to future stages without worrying about misinterpretations, ambiguities, or missing requirements.5. ConclusionExperts, like Barry Boehm, believed that to combat the software crisis, engineers needed to take a "risk-driven" approach rather than a "document-driven" approach like the Waterfall Model (as cited in Dorfman & Thayer, 2000, p. 415). This is not always the case. Although the Waterfall Model has been traditionally viewed as being a strict and rigid methodology leaving little room for flexing creative muscles, it serves a purpose in a structured environment. These environments are oftentimes militaristic or top-down. They promote finalizing the decision-making process rather than doting on the input of bottom-level employees that can delay or weigh down a project's ability to progress smoothly. Oftentimes, the top-down approach can be avoided simply by having a mature development process where documentation is stressed upon as being an important factor for progression. The successful elicitation of requirements is also a key factor that would support a linearly progressive methodology.ReferencesConstantine, L.L. (October 1993). Work organization: Paradigms for project management and organization.Communications of the ACM, 36(10), 35-43. Retrieved May 23, 2007, from ACM Digital Library database.Dorfman, M., & Thayer, R.H. (2000). Software engineering. Indianapolis: Wiley Publishing, Inc.Guimarães, L.R., & Vilela, P.R.S. (2005). Comparing software development models using CDM. SIGITE '05, October 20-22, (pp. 339-347). Newark, New Jersey, USA: ACM Press.Yourdon, E. (2002). Byte wars. Upper Saddle River, New Jersey: Prentice Hall.。