Now that you've got your project team together, no doubt you're eager to get started delivering the solution your client is so eagerly awaiting. Before you begin, however, you need to determine which process to adapt for building the finished product.
There are a few to choose from, but the two fundamental processes are known as the Waterfall Process and the Spiral Process. Both these processes have the same basic stages and elements in common. The difference lies in the order and manner in which they are approached.
In the Waterfall Process, the entire project is treated as a single solution to be delivered. The approximate process that is followed is shown in Figure 20-1.
The key principle of the Waterfall Process is that none of the phases may begin until its predecessor has been completed in full. In other words, the specification for the entire project must be completed and approved in full before the design and architecture phase for the project is completed. Only then can the build process of the project be completed and approved. Finally, the test phase of the project may take place.
This traditional process is fine in principle but has some latent problems in practice. For example, if an error is made during a particular phase that is not detected until later, that phase and all phases thereafter need to be repeated, which is immensely time consuming and expensive. An error at specification stage not picked up by the client until delivery will require respecification, redesign, rebuild, and retesting.
Another potential problem arises because the solution is built in one fell swoop, making it very difficult to offer the client anything partly finished to play with early on in the development process. If the client wants to provide early demos, or just needs reassurance as to progress, these can be very difficult to accomplish until very late in the project life cycle.
The Spiral Process has the same core components as those of the Waterfall Process specification, design and architecture, build and test. However, rather than approach the entire solution as a single entity to which these four steps are applied, the system is divided into individual components, and the process is then applied to each component.
A component may either be a discrete piece of functionality or a partial evolution or layer of a piece of functionality. For each component, the four phases are applied: the specification of that component, followed by the design and architecture of that component, followed by the build of that component, followed by the testing of that component, in isolation.
The process is called the Spiral Process because you follow the path of a spiral ever progressing down the path, but passing the same four compass points (each of the four phases) again and again (Figure 20-2).
The big advantage of this process is that should an error be spotted at any stage during the four phases, the steps backward that have to be taken are much smaller because you are dealing with only one discrete component rather than with the entire application. In addition, the client is able to play with the first components of your application much sooner, which can have huge political benefits.
It's worth pointing out that the testing phase deviates from the Spiral Process slightly, in that the tests applied with each new component should ideally include all the previous tests from previous components, too, to ensure that no new piece of functionality is causing a previously tested and signed-off piece of functionality to fail.
This chapter does not advocate either process over the other. In the next chapter, you'll see one of the processes again in the context of our Sales Force Automation application, but for now we will leave the door wide open. Which method you choose depends very much on the project at hand.
Although the Spiral Process certainly has huge advantages from a change request and exception handling perspective, the additional paperwork and administrative involvement has a cost to it, too, which must be weighed equally.
Your own experience will let you get a feel for both processes; much of the time the decision comes down to personal preference as much as anything else. Whichever way you go, there are common steps and a best practice for each one, which we examine next.