Glossary


Waterfall

A-B-C- D-E-F- G-H-I- J-K-L- M-N-O- P-Q-R- S-T-U- V-W-X- Y-Z

Identification

Waterfall

Definitions/Uses

2001
Reference /Scacchi, 2001/ Process Models in Software Engineering

Definition/
Use The classic software life cycle is often represented as a simple prescriptive waterfall software phase model, where software evolution proceeds through an orderly sequence of transitions from one phase to the next in order /Royce, 1970/. Such models resemble finite state machines descriptions of software evolution. However, these models have been perhaps most useful in helping to structure, staff, and manage large software development projects in complex organizational settings, which was one of the primary purposes /Royce, 1970/. , /Boehm, 1976/. Alternatively, these classic models have been widely characterized as both poor descriptive and prescriptive models of how software development "in-the-small" or "in-the-large" can or should occur.

Rationales The author classifies Waterfall as one of the traditional software life cycle models

1981
Reference based on /Boehm, 1981/ Software Engineering Economics

Definition/
Use
There are several versions of the waterfall model. The following is a simplified wide-known version of the waterfall model:

System Initiation: Defines the concept for the software product and determines the lifecycle plan. Validation: Are we doing the right product?

Requirement Analysis and Specification: Describes the problem to be solved by the software system and specifies the functions, operational capabilities, desired performance characteristics and the resources for the software product. Validation: Are we doing the right product?

Preliminary Design: Specifies the overall software and hardware architecture and the control and data structure for the product. Verification: Are we doing the product according to the requirements?

Detailed Design: Defines the procedures for program component with its corresponding data inputs and outputs. Verification: Are we doing the product according to the preliminary design?

Coding and Implementation: Codification of the procedures defines in the last phase into operational source code and correponding unit test.

Integration and Testing: Integration of the individual tested software components into modules , verifying the functionality, resources interfaces and performance against the requirements.

Operations and Maintenance: Specifies the directions for installing the software product , provides instructional training to the users, specifies and runs diagnostic test cases to ensure the viability of the software system and adapts, and adds the requested functional enhancements.

1970
Reference /Royce, 1970/ Managing the Development of Large Software Systems: Concepts and Techniques

Definition/
Use
This paper set the roots for the "Waterfall" model. Although Royce didn't mentioned the word "waterfall" in it, his methodology became later known for it because of the layout of the boxes in his diagrams which looked like stones in a waterfall (Figure G.2)
Royce improved the nine phase stage-wise model of Benington by adding explicit feedback loops (Figure G.3) and by introducing the concept of what is now known as prototyping.
The grey boxes in Figure G.2 illustrate what Royce called "Do it twice" which foresaw the concept of prototyping: "If the computer program in question is being developed for the first time, arrange matter so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operation areas are concerned. Figure 7 (here G.3) illustrates how this might be carried out by means of a simulation. Note that it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort. The nature of this effort can vary widely depending primarily on the overall time scale and the nature of the critical problem areas to be modeled".
Actually, Royce described "feedback loops" as the ideal circumstance when there is iteration with the preceding and succeeding steps: "At any point in the design process after the requirement analysis is completed there exists a form and closeup baseline to which to return in the event of unforeseen design difficulties. What we have is an effective fallback position that tends to maximize the extend of early work that is salvageable and preserved".

In most of the publications, the waterfall model is claimed to be inefficient because of the lack of feedback loops. Surprisingly, they were explicitly considered in the original model of Royce. Moore /Moore, 1998/ justifies this situation for the reason that managers were persuaded by the name "waterfall" that, just as water never goes up, a software component should never move backward in the life cycle. They based on the premise that each step should be performed right the at first time ignoring the work of Royce.

2001
Reference	/Scacchi, 2001/ Process Models in Software Engineering
Definition/ Use	The classic software life cycle is often represented as a simple prescriptive waterfall software phase model, where software evolution proceeds through an orderly sequence of transitions from one phase to the next in order /Royce, 1970/. Such models resemble finite state machines descriptions of software evolution. However, these models have been perhaps most useful in helping to structure, staff, and manage large software development projects in complex organizational settings, which was one of the primary purposes /Royce, 1970/. , /Boehm, 1976/. Alternatively, these classic models have been widely characterized as both poor descriptive and prescriptive models of how software development "in-the-small" or "in-the-large" can or should occur.
Rationales	The author classifies Waterfall as one of the traditional software life cycle models
1981
Reference	based on /Boehm, 1981/ Software Engineering Economics
Definition/ Use	There are several versions of the waterfall model. The following is a simplified wide-known version of the waterfall model: System Initiation: Defines the concept for the software product and determines the lifecycle plan. Validation: Are we doing the right product? Requirement Analysis and Specification: Describes the problem to be solved by the software system and specifies the functions, operational capabilities, desired performance characteristics and the resources for the software product. Validation: Are we doing the right product? Preliminary Design: Specifies the overall software and hardware architecture and the control and data structure for the product. Verification: Are we doing the product according to the requirements? Detailed Design: Defines the procedures for program component with its corresponding data inputs and outputs. Verification: Are we doing the product according to the preliminary design? Coding and Implementation: Codification of the procedures defines in the last phase into operational source code and correponding unit test. Integration and Testing: Integration of the individual tested software components into modules , verifying the functionality, resources interfaces and performance against the requirements. Operations and Maintenance: Specifies the directions for installing the software product , provides instructional training to the users, specifies and runs diagnostic test cases to ensure the viability of the software system and adapts, and adds the requested functional enhancements.
1970
Reference	/Royce, 1970/ Managing the Development of Large Software Systems: Concepts and Techniques
Definition/ Use	This paper set the roots for the "Waterfall" model. Although Royce didn't mentioned the word "waterfall" in it, his methodology became later known for it because of the layout of the boxes in his diagrams which looked like stones in a waterfall (Figure G.2) Royce improved the nine phase stage-wise model of Benington by adding explicit feedback loops (Figure G.3) and by introducing the concept of what is now known as prototyping. The grey boxes in Figure G.2 illustrate what Royce called "Do it twice" which foresaw the concept of prototyping: "If the computer program in question is being developed for the first time, arrange matter so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operation areas are concerned. Figure 7 (here G.3) illustrates how this might be carried out by means of a simulation. Note that it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort. The nature of this effort can vary widely depending primarily on the overall time scale and the nature of the critical problem areas to be modeled". Actually, Royce described "feedback loops" as the ideal circumstance when there is iteration with the preceding and succeeding steps: "At any point in the design process after the requirement analysis is completed there exists a form and closeup baseline to which to return in the event of unforeseen design difficulties. What we have is an effective fallback position that tends to maximize the extend of early work that is salvageable and preserved". In most of the publications, the waterfall model is claimed to be inefficient because of the lack of feedback loops. Surprisingly, they were explicitly considered in the original model of Royce. Moore /Moore, 1998/ justifies this situation for the reason that managers were persuaded by the name "waterfall" that, just as water never goes up, a software component should never move backward in the life cycle. They based on the premise that each step should be performed right the at first time ignoring the work of Royce.

Identification

Definitions/Uses

See also