See Figure 
on page for an overview of the WaterSluice methodology.
[IMAGE ]
Figure: The WaterSluice Methodology
At the beginning of the project, in an iterative process, the analysis, design, implementation, and test phases are broken into many potential tasks, yet to be accomplished. Each potential task is assigned a priority. This priority reflects the benefit to the final goal of accomplishing the task based on what has already been accomplished. The highest priority task is accomplished next. Depending on the size of the team, multiple high priority tasks may be accomplished in parallel. The remaining lower priority tasks are held for later review.
The decomposition of the problem is important to accomplish well regardless of the methodology being used. More comments on this topic are deferred to a later section.
As of a result of accomplishing these tasks, new analysis, design, implementation, or testing tasks may be discovered. These newly discovered tasks are then added to the known remaining open tasks and again prioritization is required. The next highest priority task are then accomplished.
This process continues until the product is ready for release.
Defining the priority function is of high importance. This priority function is domain specific as well as institution specific representing tradeoffs between quantity and quality, between functionality and resource constraints, and between expectations and the reality of delivery. However, the constant priority theme of marching towards product delivery can be generalized over all priority functions.
Once a component is completed to the satisfaction of the team it is placed under change order control. For the most part, changes to the component are now frozen. If a change is absolutely necessary and the teams are willing to delay the project to implement the change, then the component is updated. Changes should be seldom, well justified, and documented.
Obviously, early in the process, analysis tasks are a natural high priority. Later on in the process, testing and quality become a higher priority. This is where the change order control process becomes important. At the beginning of the process all four categories of analysis, design, implementation, and testing are available for prioritizing and scheduling. At some point in the process, the analysis phase is subjected to change order control. Having the analysis phase frozen focuses the attention on the remaining three categories of tasks. In a similar fashion design and implementation are eventually frozen. At the final stage only changes that effect quality are allowed. This leads to a natural definition of temporal stages in the methodology, specifying priorities.
Don't confuse phases with stages. A phase is a natural grouping of similar activities. A stage is a natural temporal grouping of tasks within phases at particular times. Stages follow each other in a monotonic fashion.
The main stages are called proof of principle, prototype, alpha and beta release, and product. With the exception of the proof of principle stage, these stages should not be a new concept to software engineers.
![[IMAGE ]](sluice.gif){kind=link}