2.3 Software Process Models and Paradigms of Software Development – A
2.3.4 The Spiral Software Process Model
Whilst the methodological aspects of the iterative and incremental approach are quite clear (as illustrated in Figure 2.6), a variety of SPM’s based on the IID methodology were proposed by the SE community. The essence of these models is that they need to have a mechanism that enables developers to test the system with end users in order to refine the system’s design models during the development process (Cusumano & Selby, 1997). A discussion of SPM’s that incorporate the IID methodology is presented in the subsequent text.
As can be seen in Figure 2.7, the Spiral SPM entails an iterative sequence of the following activities for each specific portion of the system.
Identification of objectives, alternatives and constraints for specific phases of the development cycle (upper left quadrant in Figure 2.7).
The objectives of a specific phase of development entails aspects such as the desired functionality, the expected performance of the system, the ability to accommodate change, etc. (Boehm, 1988). The alternatives allude to identification of possible alternative designs and off-the-shelf solutions. The constraints refer to operational parameters that are normally expected as part of the systems development process. This includes cost, resource and interface constraints;
An evaluation of the alternatives (identified earlier) relative to the constraints and objectives. A proof-of-concept prototype7 is
7 A proof-of-concept prototype is a scale model constructed to test the feasibility of construction Figure 2.7: The Spiral Software Process Model (Boehm, 1988)
suggested as a possible risk evaluation strategy. These activities form the upper right quadrant of the Spiral model;
The lower right quadrant of the Spiral SPM represents the development phase of the model. However, the significant aspect of the development phase is its dynamic nature. If concerns regarding the system performance or the viability of the user interface cannot be resolved, then an evolutionary8 development approached is suggested. In this case, the system is developed incrementally. The main aspects of the system are developed early, thereby providing the developers with an opportunity to evaluate the risks of system failure at an early stage of development. The system is evolved into the fully, fledged final product. If, however, all performance and user interface risks have been identified and resolved at the requirements phase, then the basic waterfall approach to software development may be followed (as indicated in the lower right quadrant). This is not the same as simply a different case of the Waterfall SPM. Boehm makes reference to a software development strategy that entails partitioning of the software product into components that are developed iteratively using the phases of the Waterfall SPM.
Spiral is a Typical IID Methodology
Based on the illustration and the subsequent narrative, the Spiral SPM is representative of a typical IID methodology. However, according to Schach (2008, p. 64) the Spiral model is not a “truly incremental model” because it consists of discrete phases of “waterfall-like” development (in reference to the different quadrants that underpin the Spiral SPM as illustrated in Figure 2.7).This assertion is certainly debatable because the strategy of prototyping ensures incremental refinement of system requirements, unlike the Waterfall approach where the requirements are declared and ‘frozen’ at the beginning of the
8 The evolutionary approach is described by Pressman (2010, p. 42) as an approach that produces an increasingly more complete version of the software with each iteration
development process. Boehm and Hansen (2000) are in agreement with the dynamism inherent in the Spiral SPM by virtue of their assertion that the Spiral model embodies a cyclic approach where the objective is to incrementally refine a system’s degree of definition whilst at the same time, reducing the degree of risk.
Ruparelia (2010) endorses the suggestion regarding the incremental nature of the Spiral SPM by claiming that the philosophy underlying the spiral approach is to start small, and think big. This is certainly aligned to the IID methodology of focusing development on small, manageable portions of the system. It is expected that each portion will be aligned to the overall system development objectives that attempt to ensure optimal functionality without incurring significant cost overheads and also ensuring the maintainability of the system. Hence, whilst there is a case to be made for the Spiral SPM to be regarded as an iterative and incremental type SPM, the “quadrant-like” structure of the Spiral model (Figure 2.7) does give credibility to Schach’s interpretation that the Spiral SPM simply entails successive iterations of the phases of the Waterfall SPM. Hence, a closer inspection of the Spiral SPM is warranted in order to resolve the doubt cast by Schach regarding the iterative and incremental nature of the Spiral SPM.
The problem of creating a SPM that attempts to minimise the weaknesses of other SPM’s is that the complexity of the newly created process model increases.
This assertion may be substantiated by using the case of risk analysis in the Spiral SPM. Risk analysis was included as a control measure in the Spiral SPM so that the incremental functionality of the evolving system was added within the parameters of cost and resource consumption feasibility. However, the stringent implementation of such control measures necessitates the introduction of a new set of processes and activities that will require concise and comprehensive documentation in order to create an effective ‘audit trail’ of the risk analysis deliberations. This added overhead to the Spiral SPM tends to render the process as a ‘high ceremony’ process.
Spiral Methodology viewed as a “High in Ceremony” Process
The expression ‘high ceremony’ was coined in the annals of SE literature to refer to SPM’s that entailed substantive focus on documentation, formal software reviews, rigid adherence to methodology and embodied a highly controlled demeanour towards the software development process. The attributes of a high ceremony process have been gleaned from the use of the expression by McBreen (2000), McCormick (2001) and Booch (2001) in reference to general software development methodology as well as Cockburn (1999), Fowler (2001) and Fowler (2006) in reference to agile software development methodology. From the preceding references, the ‘waterfall-like’ approach to software development is regarded as high ceremony while the SPM’s that are strongly influenced by an iterative and incremental approach and gives prominence to the visibility of the software rather than the documentation, is regarded as ‘low ceremony’.
A distinctive aspect of the Spiral SPM is that it has elements of the IID methodology, although the major focus is on extensive risk analysis. The risk analysis overhead renders the Spiral approach to software development as a high ceremony SPM. As such, it is ideally suited for large-scale software systems that serve a ‘mission critical’, institutionalised purpose and entails a substantive financial and resource investment. In such systems, the cost of failure warrants an approach that is underpinned by continuous risk analysis, thereby minimising the prospect of system failure and enhancing the traceability and accountability of the software development process. The Spiral SPM embodies an engineering-like approach to software development, the significance of which is highlighted in Booch’s commentary on the future of SPM’s, where he refers to the idealism of
“…managing requirements, iteratively and incrementally growing a system’s architecture, controlling change, and testing continuously” (Booch, 2001, p. 120).
A significant aspect of the preceding comment is that Booch refers to the idealism of incorporating proper software development principles into the process of software development. The implication here is that the ideal route is perceived to be more of a vision of perfection rather than being representative of what is
practically feasible. In this regard, the Spiral SPM is theoretically sound, but practically untenable.
Given the rigour and effort spent on ensuring system success, there is a lack of popularity of the Spiral SPM. While the SE community has endorsed the Spiral SPM as a viable approach to software development, it is the economic imperatives that have ‘derailed’ any prospect of a unanimous show of support for the Spiral SPM. Booch (2001) points out that economic constraints tend to be given priority over quality software thereby resulting in SPM’s that produce software systems that are less than optimal. In an article titled, “When Good Enough Software is Best”, (Yourdon, 1995) coined the expression Good Enough Software.
In this article Yourdon asserts that software development does not have to always abide by the rigour, standards and precision of engineering-like projects. He contends that a “good-enough approach” (p. 79) would faciltate a software development process that is rational and attaches significance to the domain of usage of the software system thereby modulating the exclusive focus on the rigour and precision of the development process. Meyer (2003) endorsed the concept of good enough software and suggested that a software system with ‘good enough’
quality, that is delivered on time so as to enhance the prospect of competitive business advantage is better than a software system that is deemed to be perfect, but is delivered too late to provide business value. It is within this context that high ceremony SPM’s such as the Spiral model began to lose popularity amongst software developers.
Schach (2008) pointed some other issues of concern regarding the Spiral SPM. Schach contends that the additional costs incurred by the risk analysis phases of the Spiral SPM renders the Spiral approach appropriate for large-scale software projects where the cost of the risk analysis is only a small percentage of the entire project. He also refers to the skill required by the analysis team in reliably identifying areas of risk. If this is not done accurately, then the cost of recovery from such risks could be quite substantial. Boehm (1988) has acknowledged the criticisms of the Spiral SPM by members of the SE community and has conceded that the model relies heavily on comprehensive documentation
and the involvement of highly experienced software practitioners who are skilled in risk analysis.
Conditions for the Successful Implementation of the Spiral Methodology
From the prevailing discussion, a necessary condition for the successful implementation of the Spiral model is to always have a multi-skilled team available. While software development skills are an absolute necessity, the development team also needs to have the expertise of experienced software developers readily available to make risk assessments during the life-cycle of the Spiral model. The main issue with these requirements is that the intensity of demands for software availability cannot be satisfied by software developers who always take the high ceremony approach. For most business oriented systems that serve an immediate need, a satisficing approach that entails the development of
‘good enough’ software may be perceived to be a much more viable alternative to the Spiral SPM. Naumann and Jenkins (1982) commented that SPM’s need to be adjusted to handle software requirements that are more complex and operate in less structured environments. These SPM’s need to be able to handle changing user requirements, respond to the feedback provided on the basis of users’
experiences in interacting with initial versions of the system as well as be able to handle new technology. Hence, there was a call for SPM’s to become more dynamic
The Spiral SPM had served its purpose in contributing to the evolutionary trajectory of SPM’s. However, the potential of the Spiral SPM to be accommodating of a dynamic development environment was limited. This quest for a dynamic software process model that was flexible enough to handle changing user requirements became an urgent source of enquiry by the SE community. Aligned to the issue of obtaining an accurate and adaptable representation of user requirements, the object-oriented (OO) paradigm of software development was beginning to achieve a ubiquitous presence in the field of software development.
According to Capretz (2003), the OO paradigm enhanced the prospect of obtaining a better software based representation of real world artefacts. The Unified Process (UP) is a SPM that leverages the advantages inherent in OO development to offer a truly IID methodology.