Computer, May 1988
by Barry W. Boehm
TRW Defence Systems Group
Document available @ http://www.computer.org/computer/co1988/r5061abs.htm
Last Updated: 17th March 2002 Sunday 17:14, Ankara
Notes that I took while reading this article:
"The major distinguishing feature of the spiral model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process."
"The primary functions of a software process model are to determine the order of the stages involved in software develeopment and evolution and to establish the transition criteria for progressing from one stage to the next.
"Many software projects...have come to grief becasue they pursued their various development and evolution phases in the wrong order."
"A primary source of difficulty with the waterfall model has been its emphasis on fully elaborated documents as completion criteria for early requirements and design phases...Document-driven standards have pushed many projects to wirte elaborate specifications of poorly understood user interfaces and decision support functions, followed by the design and development of large quantities of unusable code."
"The evolutionary development model is ... well matched to situtations in which users say " I can't tell you what I want, but I'll know when I see it." It gives users a rapid initial operatinal capability and privides a realistic operational basis for determining subsequent product improvements. Nonetheless, evolutionary development also has difficulties. It is generally difficult to distinguish it from the old code-and-fix model, whose spaghetti code and lack of planning were the initial motivation for the waterfall model. It is also based on the often-unrealistic assumption that the user's operational system will be flexible enough to accommodate unplanned evolution paths."
"Design rationale is of paramount importance in assessing the potential reusability of software components on future projects."
"The spiral model places a great deal of reliance on the ability of software developers to identify and manage sources of project risk. A good example of this is the spiral model's risk-driven specification, which carries high-risk elements down to a great deal of detail and leaves low-risk elements to be elaborated in later stages; by this time there is less risk of breakage. However, a team of inexperienced or low-balling develeopers may also produce a specification with a different pattern of variation in levels of detail: a great elaboration of detail for the well-understood, low-risk elements, and little elaboration for the little understood, high-risk elements. Unless there is an insightful review of such a specification by experienced development or acquisition personnel, this type of project will give an illusion of progress during a period in which it is actually heading for disaster."
"If the high-risk elements have been glossed over by impressive sounding references to poorly understood capabilities...there is even a greater risk that the conventional approach will give the illusion of progress in situations that are actually heading for disaster."