The waterfall method, documented by Royce (Royce, 1970), attempted to ensure quality through constraints, conversely Boehm’s Spiral model (Boehm, 1988) attempts to address the inflexibility of the waterfall approach offering opportunities for improvement throughout the entire process. It is Boehm’s spiral that from the basis of all today’s modern agile mythologies.
We should note that Royce himself stated that the waterfall was not suitable for all project and the potential costs involved implementing the process would be unacceptable to both developers and customer on all but large and critical projects.(Royce, 1970). Conversely Boehm establishes that early finding for software problems reduces the cost of fixing them.(Boehm and Huang, 2006) Of the problems found, the most expletive to fix are those that originate in the design , since the overall design is not complete at the start of the spiral, there is opportunity to address such issues thou ought the entire software development life cycle.
Perhaps the biggest impact on quality comes from the psychological change that the spiral method brings; spiral testing “encourages cooperation between testers and developers”(Lewis, 2004, p101) It has been my real experience that this cooperation, part necessity, part evolution is improving mutual respect between the two groups and leading to higher quality product from initial development . Never has this been more apparent with testing frameworks such as xUnit and Frame works such as Ruby on Rails and Symfony embedding unit tests and integration test into their frameworks. There is an understating that developers don’t like writing test and so in facilitating them to do so these frameworks are encouraging a new attitude of “responsible developers “who not look upon testing as proof that they did a good job. The divisive nature “inspired” the waterfall has all but disappeared.
If Quality is ultimately a measure of how usable a software program is, then the program must be “fit for the purpose” that it was intended for. There is a real risk on large project the business may have changed during the development cycle and application is no longer “fit for the purpose” . Spiral methods encourage the involvement of users and help to ensure that the end result is a good match. Early delivery of working code enables the users to meet some of their business need sooner.
By way of contrast the waterfall offer rigorous control which may be seen to be advantageous, and perhaps even require by regulatory bodies (notable in the medical industry for example) Whilst both methods have similar elements and attempt to provides similar levels for coverage to those elements, Spiral methods are still considered by some as “too lose” and consequently in appropriate. Even Boehm expresses concern especial y the need for careful requirements management (Boehm, 2002)
Spiral methods do not only provide opportunities for early delivery, but also provide opportunities for early testing and issue resolution. The involvement of users/customers further helps to ensure that the customer’s needs are met accurately. In a dynamic business environment this flexibility may well be essential to the overall success of the project.
BOEHM (1988) A spiral model of software development and enhancement. IEEE JNL Computer.[online] DIO: 10.1109/2.59 (Accessed: 18-10-2008)
BOEHM (2002) Get ready for agile methods, with care. IEEE JNL [online] DIO: 10.1109/2.976920 (Accessed: 4-5-2008)
BOEHM, B. & HUANG, L. (2006) How Much Software Quality Investment Is Enough: A Value-Based Approach. Software, IEEE, 23, 88-95.[online] DIO: 10.1109/MS.2006.127 (Accessed: 11-02-2009)
LEWIS, W. E. (2004) Software Testing and Continuous Quality Improvement, New York, Auerbach Publications.
ROYCE, W. W. (1970) Managing the development of large software systems: concepts and techniques. Proceedings of the 9th international conference on Software Engineering.[online] DIO: ISBN:0-89791-216-0 (Accessed: 13-5-2007)
