Learning log 4 - Spiral Vs Waterfall

During software development the developer apparently has to undergo a certain process named the SDLC (system development life cycle) by using one out of several software process models. This is to establish “the order of the stages involved in software development and evolution and to establish the transition criteria for progressing from one stage to the next.” (Barry W. Boehm, A spiral model of software development and enhancement p.61)

The two common models are the waterfall model and spiral model. The waterfall model provides a “linear and sequential” development method; once the developer has passed a phase, like a waterfall, “you never go back” (http://www.iuk.be/ist205/sess8.html); there is no back tracking, reversing or revising previous stages.

On the contrary, the spiral model allows for a non-linear and more flexible development method. Phases can be revisited at any stage in the process and as many times as need be. The four phases in the spiral model are:

“
1 Planning
2 Evaluation
3 Risk analysis
4 Engineering “

(http://www.buzzle.com/editorials/1-5-2005-63768.asp)


However the four phases in the waterfall model are:

“
1 Requirement spec
2 Software design
3 Implementation and
4 Testing and maintenance “

(http://www.buzzle.com/editorials/1-5-2005-63768.asp)


From simply scanning the four main phases in each model it is apparent that the spiral model is the more stable and reliable out of the two: there is evaluation and then risk analysis immediately after planning which means that if there is anything wrong or miscalculated in the initial planning then it will instantly be recognised and corrected before implementation; “important issues are discovered earlier” (http://www.answers.com/topic/spiral-model). Dissimilarly, in the waterfall model, not only is there no risk analysis, but there is only testing after implementation suggesting that if there is something wrong in the planning then it is not realised until it is too late. It is only “assume[d] that development can follow a step-by-step process” (www.horde.org/papers/oscon2001-case_study/4_waterfall.xml.html) when clearly this is not the case. The waterfall model is “risky and invites failure” as Dr. Winston W .Royce, the founder of this model, admitted himself.

The spiral model can be seen as a much more complex model; the diagrams juxtaposed are a mere demonstration:

[via appendix]

This gives reason to why the waterfall method is described as a “simple… disciplined approach” (Dr. D. Tishkovsky Software Development Tools, slide 4) however I don’t see how this model intends to “manage risks” (www.faqs.org/faqs/software-eng/part1/section-4.html) when baring in mind that phases can not be revisited and it is “impossible to capture everything in the initial requirement documentation.” (http://swiki.ucar.edu/sea-best-practices/15) Inaccuracies in one phase are “carried out in the next phase” (http://www.buzzle.com/editorials/1-5-2005-63768.asp) creating an accumulation of problems by the time implementation is applied. Surely this model is setting one up to fail.

Despite this, it is argued that it does produce “highly reliable system[s]…with large capability of growth” (Dr. D. Tishkovsky Software Development Tools, slide 4) Yet this is only possible if the developer has “complete knowledge of the problem and do[es] not experience change.” (http://swiki.ucar.edu/sea-best-practices/15) Ironically it is more often than not that “requirements will continually change.” (Previous website) Additionally, at the testing phase, if the software fails to meet the requirements then a “major redesign is required” (Dr Winston W. Royce Managing the development of large software systems p.329) yet this need is hindered as “design can’t be changed after the design phase” (http://www.ommadawn.dk/libellus/begreb.php?emneid=54) This explains why this model “does not work well” for several categories of software; it may be simplistic but this model is not realistic in the world of development.

At the opposite end of the spectrum, although it is said that the spiral method derived from the waterfall method, it was designed to “overcome the disadvantages of the waterfall model”(www.buzzle.com/editorials/1-13-2005-64082.asp) It can cope with the “inevitable changes” (http://www.answers.com/topic/spiral-model) of a development process; not only can phases be revisited as stated earlier but each phase begins with a “design goal and ends with the client…reviewing the progress” (http://www.answers.com/topic/spiral-model). This model undeniably concentrates on removing “errors and unattractive alternatives early” (Barry W. Boehm, A spiral model of software development and enhancement p.69) on. It’s “risk driven approaches avoids many” of waterfall’s difficulties. (Previous article P.69)

However, the constant client reviewing means that this model “only really works well on internal software development.” (Previous article p.70) Furthermore, its success being determined by the detailed risk assessment means that the success of using this model relies on “risk assessment expertise” (Previous article p.71), which is not always available.

Although the waterfall model “looks very good on paper” (http://www.ommadawn.dk/libellus/begreb.php?emneid=54) better than the spiral method, a product development process is not this simple. Its said that a waterfall model's success is determined by the “time spent early on” as there is no turning back. However when does one know that enough time has been spent? When is the cut-off period? In fact, it’s said that the closer a “particular plan...[is] followed” (http://www.iuk.be/ist205/sess8.html) the more successful the development, however in the case of such a strict, non iterative model I think that the closer the waterfall model is followed the more chance of failure!

What makes the spiral so robust is the fact that not only does it begin with a hypothesis that if at any time fails then "the spiral is terminated" (Barry W. Boehm, A spiral model of software development and enhancement, p.65) but also each cycle of the spiral begins with the aims identified, "alternative means of implementing...the product...[and] the constraints imposed". (Barry W. Boehm, A spiral model of software development and enhancement, p.65) Progression is constantly under scrutiny so there is little chance of mishaps being overlooked. Moreover, the early steps involve a first prototype that is made from the preliminary design; its "strengths, weaknesses, and risks" (http://searchvb.techtarget.com/sDefinition/0,,sid8_gci755347,00.html) are evaluated and a second prototype is constructed from this analysis and is tested. This prototype is also evaluated by the customer and the "preceeding steps are iterated until the customer is satisfied." (http://searchvb.techtarget.com/sDefinition/0,,sid8_gci755347,00.html)

The waterfall model may have provided the basis for a number of software development methods as it is the "first process model" (www.buzzle.com/editorials/1-5-2005-63768.asp) however the disadvantages discussed explain why this method "usually breaks down" (http://swiki.ucar.edu/sea-best-practices/15) It may allow for "departmentalization and managerial control" (http://searchvb.techtarget.com/sDefinition/0,,sid8_gci519580,00.html) along with providing neat schedules and dead lines due to it "flowing steadily downwards." (www.selectbs.com/glossary/what-is-the-waterfall-model.htm) but regardless how 'steadily' it flows; risk factors and problems are 'steadily' missed and "design changes are likely to be so disruptive." (Dr Winston W. Royce Managing the development of large software systems p.329) In fact it is argued that it “often yields projects that are horribly behind schedule” (http://www.cs.bsu.edu/homepages/metrics/cs639d/CS639WWW/chapter13/sld011.htm) not on schedule! I would choose the Spiral method over the "oldest system development method" (http://www.ommadawn.dk/libellus/begreb.php?emneid=54) in a flash.