2.3 Software Process Models and Paradigms of Software Development – A
2.3.1 The Code and Fix Model and the Software Crisis
One of the earliest software process models (late 1940s to early 1960s) is referred to as the ‘code and fix’ method (Boehm, 1988) that entailed a simple 2-step process (Figure 2.3) of writing some code and fixing errors that may be observed when the program is run. This process is repeated until the software solution produces an accurate output that conforms to the expected output from the test case values that are input into the software product. On the basis of the match between the expected output and the actual output of the system, the software product is deemed to be successful or not. Schach (2008) claimed that this model of software development also prevailed in the 1970’s and referred to the model as the “development-then-maintenance” model (p. 9).
FIX CODE
FINAL SOFTWARE PRODUCT (includes
a post-delivery maintenance phase)
Figure 2.3: Code and Fix Software Process Model (adapted from Schach (2008, p.
The focus of the effort is around the actual coding of the system and the allure of the process is that the software product begins to materialise almost immediately, thereby reducing the “invisibility” (Brooks, 1987, p. 3) of the evolving software product. The ‘code and fix’ SPM basically ‘got the job done’ and it was reported by Trauring (2002) that this unstructured process gave rise to the following criteria that were used to measure the success of a software product.
These criteria were that software:
should have a relatively low cost of initial development;
is highly maintainable;
is portable to different hardware platforms;
performs the processing expected by the customer.
These criteria epitomised much of what is expected from a software product and became a benchmark for software success that has maintained its relevance over a period of time (Kaur & Sengupta, 2013; Pressman, 2010; Van Veenendaal, 2008). However, while the code and fix process model was functional in producing software quickly, ironically it did not abide by the very same criteria that became a benchmark for software success. Lehman (1980) referred to the code and fix model as one that lacked any guiding theory and made no formal attempt to ensure accuracy or validity of the emergent software product. Boehm (1988) highlighted 3 significant weaknesses of the code and fix model. These weaknesses are listed as:
A number of fixes contributed to a code base that became difficult to manage; this observation prompted a call for a design phase prior to coding;
The emergent software product did not meet with the user’s requirements thereby necessitating the need for a requirements phase prior to design;
The lack of provision for a testing and a maintenance phase resulted in increased costs to modify the software to satisfy user requirements.
Schach (2008) commented that the code and fix SPM may work well for software tasks consisting of less than 200 lines of code. However, it did not scale well for software products that contained higher levels of complexity or delivered substantive functionality. Schach (2008) also concurred with Boehm’s criticism of the code and fix model. A common source of concern was the high cost of maintenance incurred as well as the inability to handle changing user requirements. Another area of concern was that the code and fix SPM did not ensure any form of accountability from the actual computer programmers because there were no specifications in terms of what constituted as a successful software product. The ease of code modification gave rise to a “hacker culture” (Boehm, 2006, p. 14) enabling computer programmers to adopt a strategy of hastily patching faulty code to meet project deadlines. This negative indictment on the code and fix model is sustained by Schach (2008, p. 51) who commented that the code and fix model “…is the easiest way to develop software and by far the worst way”.
Much of the criticism levelled at code and fix SPM stemmed from a lack of up-front planning and design to underpin the software development effort. In an effort to add elements of planning and design to the software process, Dijkstra introduced his method of structured design at the NATO Conference on Software Engineering Techniques in 1969 (see Dijkstra, 1970).
The structured design method entailed the following main strategies (Jensen, 1981):
Postpone details – prioritise major functions early and focus on details later;
Make decisions at each level of abstraction regarding alternate design paths;
Be flexible – the existing structure design structure should be amenable to change;
Consider the data at lower levels of abstraction;
Make an effort to reduce software complexity.
A significant consequence of these software development deliberations was that a paradigm of software development began to emerge. The emergent paradigm of software development consisted of a mix of SPM’s and SDM’s. The software process model (SPM) provided guidance on ‘what needed to be done’ while the software development methodology (SDM) provided guidance on ‘how to do it’.
From a more formal perspective, the SPM provided guidance from an ‘elevated’
level on the sequence that needs to be followed when moving from one software development phase to the next as well as the criteria that needs to be met in order to sanction progression through the various phases. At the operational level, a SDM consisted of a set of software development methods such as structured analysis and design, stepwise refinement and flowcharting that enabled the attainment of the objectives of each specific phase of the SPM. The relationship between the SPM and the set of techniques, collectively referred to as the SDM is illustrated in Figure 2.4.
The acceptance by the software practitioner community of a SDM that consisted of techniques such as the structured design method and flowcharting (to a lesser extent) paved the way for a strong focus on requirements analysis and design as precursors to the actual coding phase. In a review of the software development methods that had received much prominence in the late 1960’s and
Figure 2.4: The Relationship between the SPM and SDM’s
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.