2.3 Software Process Models and Paradigms of Software Development – A
2.3.3 Iterative and Incremental Software Process Models
available to the end user and it should form the basis for further refinements until a final system is developed.
The Quest for an Iterative Enhancement Technique
According to Larman and Basili (2003), there were numerous SPM’s advocated by the SE community and a ‘common theme’ in all these process models was the deliberate effort made to avoid a single-pass, sequential, document-driven approach. The common thread in these deliberations regarding software process improvement (SPI) initiatives was that software development process should follow an ‘iterative enhancement’ technique as suggested by McCracken and Jackson. The objective of these SPI initiatives was to minimise the “…gulf that exists between the user and the developer perspectives on a system” (Reid Turner et al., 1999, p. 3). According to Reid Turner et al. (1999), the user perspective of the system is centred in the problem or business domain while the developer’s focus is on the creation and maintenance of software artefacts that represent the developer’s interpretation of the problem domain. It does not necessarily reflect the reality as experienced by the end user when using the system in the actual problem or business domain. In order to acquire this realistic view of the system, the developer has to iteratively expose the end user to incremental views of the evolving system so that the feedback obtained can be used to underpin all phases of the development process.
Ideally, a SPM should enhance the prospect of accurately predicting user requirements (Davis et al., 1988). While this objective may not be fully achieved, it is imperative that SPM’s should be engineered to obviate the gap between the user and developer perspectives of a software system. In this respect, the iterative and incremental approach is more compatible with the philosophy of sustaining a focus on user requirements rather than focusing on the operational aspects of the software development process as is embodied by the Waterfall SPM.
entail a “…sequence of successive design and implementation steps, beginning with an initial ‘guess’ design and implementation of a skeletal sub-problem” (p.
395). After successive iterations that continuously elicit end user feedback, the system’s design model is refined and the solution to the initial skeletal sub- problem is evolved into a complete solution to the actual problem. This approach embodies a more accurate modelling of the business/problem domain thereby enhancing the maintainability3 and the robustness4 of the final software product.
Hence, any SPM based on IID methodology would have to start with the implementation of a subset of the system requirements and incrementally build functionality onto the evolving system until the final product is developed. An IID software process model, referred to as the “antithesis” of the Waterfall SPM (Booch, 1986, p. 232), had been employed in numerous software projects in the 1960’s and 1970’s (Larman & Basili, 2003). This strategy was formally presented in a seminal publication by Basili and Turner titled “Iterative Enhancement: A Practical Technique for Software Development” (see Basili & Turner, 1975). A significant deviation of the IID methodology from previous SPM’s and SDM’s is that IID does not impose the condition of having all the system requirements being declared ‘up front’. Larman and Basili make reference to a set of core requirements that are listed as tasks in a “project control list” (p. 390) that is refined while the system is being developed. The project control list acts as a project management instrument that provides an indicator of the progress made with meeting system requirements. Each task in the project control list becomes the subject of the iterative activities of analysis, design and implementation. The project control list is an inherently dynamic list that is refined on the basis of increased knowledge that the development team acquires with regards to the system requirements. This knowledge is obtained by virtue of feedback from end user interaction with the earlier, incremental versions of the system (Larman & Basili, 2003). From a SE perspective, the strategy of keeping the systems developers as well informed as
3 Software maintenance is the activity performed whenever a fault is fixed or an adjustment is made to the software product to accommodate a change.in the set of requirements (Schach, 2008, p. 11), 4 The ability of a software product to accommodate changes without any degradation in performance of
possible at all stages of development is a compulsory requirement for ensuring quality of the final system (Mills, 1980). Also, the heavy reliance on end-user involvement at all stages of development is aligned to the prototyping approach suggested by McCracken and Jackson (1982).
This iterative approach to software development represented a significant change to the sequential Waterfall-like approach and formed the basis of a new paradigm5 of software development. The focus of the development effort is on refining user requirements, not confining them to a pre-defined prescriptive list of requirements. In terms of Brooks’ quest to find the elusive ‘silver bullet’6 that will obviate some of the difficulties associated with software development, Brooks’
comments with regards to the IID methodology are summarised below:
One of the important activities performed by a software developer is the accurate extraction and refinement of the requirements for a software system. Most often, the client is not fully aware of the requirements themselves, hence there has to be extensive iteration between the client and the system developer so that an accurate idea of the system requirements is obtained;
Even with extensive consultation between the client and the systems developer, it is still difficult for the client to provide a precise specification for the software system;
One of the most promising technological developments that represents a viable ‘attack’ on the essence of software complexity is the rapid prototyping approach that is part of the iterative specification of requirements;
Software systems should be ‘grown’ or developed using an incremental, evolutionary approach. It should not be ‘built’ from an initial set of prescribed requirements. This is aligned to the strategy proposed in Mills (1980) that a software system should first be made
5 The sequential Waterfall SPM represented the older paradigm of software development.
6 See Brooks (1987) for an elaboration of the “silver bullet” analogy
to run successfully, even if it did not do anything meaningful. The system could simply demonstrate its ability to successfully activate high level ‘dummy subprograms’. Hereafter, the ‘dummy subprograms’ should be developed using a method of stepwise refinement (Wirth, 1971) until the lower level subprograms are populated with actual program code.
Brooks (1987) concludes by remarking that IID methodology has had a profound impact on the effectiveness of software development process models.
What has emerged from the preceding discussion is that the IID methodology allows the developer an opportunity to refine the system requirements on the basis of responses obtained from end users’ interaction with a working version of the actual system. The system is also ‘grown’ incrementally into the final product. The IID methodology was proposed as a mechanism to divert the sequential mentality inherent in the Waterfall SPM to a more dynamic one.
However, the individual phases of the Waterfall SPM form the core elements of the IID based SPM’s as illustrated in Figure 2.6.
Figure 2.6: IID based Software Process Model (adapted from IBM (1998))
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.