2.3 Software Process Models and Paradigms of Software Development – A
2.3.2 The Waterfall Software Process Model
early 1970’s, Boehm (1988) commented that there was a need for a software process model that guided the software development process through the sequence of stages from analysis to design to coding. The quest for such a well-defined process model was aligned to the SE imperative to adopt an approach for software development that was prescriptive, well defined and resembled a manufacturing process that was similar to the traditional branches of engineering (Mahoney, 2004). This quest for a well-defined, prescriptive and highly controlled SPM was pivotal in promoting the viability of the Waterfall SPM.
contention was the lack of iteration between non-adjacent steps in the model.
Royce (1970) did concede that this was a potential weakness of the model and tried to embed more layers of iteration into the model. He proposed execution of the 7 step sequence twice where the first iteration was regarded as a preliminary/prototyped version with the intention of getting to understand the requirements a lot better thereby enhancing the prospect of developing an accurate design model which in turn would arguably ensure that the system would meet its operational expectations. While this iterative intervention boded well for imparting an element of dynamism into the model, it is negated by the model’s reliance on substantive documentation requirements that underpinned each stage of development. It is reported in Victor (2003, p. 55) that the allure of the simplicity of the “…single pass, document-driven waterfall model of requirements, design, implementation held sway during the first attempts to create the ideal development process.” Hence, the simplicity of the Waterfall model was its biggest advantage and provided the SE community with a solution to the quest to find an orderly, accountable and quantifiable SPM. With the passage of time, there was a growing criticism of the Waterfall model’s capacity to handle software requirements that were becoming increasingly complex. These criticisms, summarised in Parnas and Clements (1985), Sommerville (1996) as well as Ranjeeth et al. (2013), include the following:
a system’s users seldom know exactly what they want and cannot articulate all they know;
even if the system’s users could state all requirements, there are many details that they can only discover once they are well into implementation;
Even if the system’s users knew all these details, as humans we can master only so much complexity;
even if the system’s users could master all this complexity, external forces lead to changes in requirements some of which may invalidate earlier decisions.
The criticism of the Waterfall model is also alluded to by Nerur et al. (2005) who make the observation that the model has a propensity to foster an adversarial relationship between the people involved in the development of the software system, prompting a suggestion that development of software using this approach was not intrinsically rewarding.
These factors coerced the SE community to look at other process models. At an international conference on Systems Analysis and Design held in September 1980 at Georgia State University, McCracken and Jackson (1982) criticised the concept of the systems development life cycle (SDLC). This criticism was based on the commonly held perception that the SDLC was synonymous with the Waterfall approach to systems development. Based on this assumption, the SDLC approach necessitated the early ‘freezing’ of requirements and a lack of end user involvement in the latter stages of systems development. According to McCracken and Jackson, this strategy (of using a SDLC approach) perpetuates the failure of the SE community to obviate the communication gap between the end user and the systems analyst. McCracken and Jackson proposed 2 alternate approaches to software systems development, both of which do not fit the SDLC mould of development. These approaches are briefly described below:
Systems development is heavily dependent on end user involvement and presence during all phases of the development process. The development team engages with end users to produce a prototype of the system. Based on feedback from user interaction with the prototype, the development team continually refines the prototype until it eventually evolves into a final product;
A process of systems development that involves repetition of the following activities: implement, design, specify, re-design and re- implement.
A significant aspect of the software development approach advocated by McCracken and Jackson (1982) was that at the inception of the software development process, a working version of the software system should be made
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.