1.5.1 Understanding the Software Development Process
There are a number of different approaches for developing high-quality software that satisfies both the needs and expectations of its users. Some of these approa-ches differ from each other significantly; however they all share a common feature:
1.4 Software Engineering is Not Limited to Programming 11
a quality assurance mechanism that aims to ensure the production of quality software. Figure1.1 provides an overview of the formal model of the software development process.
1.5.2 Evaluation of the Waterfall Model
The waterfall model, the oldest commonly used software life cycle, is a linear approach to software development that was first suggested by Royce in 1970. This development and maintenance paradigm, also known as the classic life cycle, lays out a set of development phases which are to be completed in order. A new phase begins only when the previous phase has been fully completed, which includes the finalization of all documentation from that phase, as well the approval of com-pletion by the software quality assurance group (Schach2008). The intent is to create an efficient development process by ensuring that all of the activities involved in a certain stage of development receive the singular attention of the software engineering team, and that as each new stage begins, all of the pre-requisite work has been completed. In short, the waterfall model seeks to ensure efficiency by enforcing adherence to a strict development sequence. Figure1.2 illustrates this sequence.
Today we know that the waterfall model represents an idealized version of the software life cycle. If all clients were able to read and fully understand technical documentation, communicate in a complete and 100 % effective manner, and if everyone involved in the software engineering project performed perfect work
Analysis
Requirement
seeking Design
Test Implementation
Stakeholders Requirements Stakeholders Requirements
Leadership Responsibility
Management of Resources
Measure, Analyze, Improve
Fig. 1.1 A formal model of the software development process
with no need for modifications or additional functionality beyond the initial product specification, then the classical model would be an easy choice. In prac-tice, however, perfection is often a difficult goal to achieve. Regardless of the energy spent trying to avoid or account for them, miscommunications, misun-derstandings, mistakes due to human error, and changes in requirements will occur; and problems will result. When this occurs, the only solution is often to correct the error through a change in the product. The failure to allow proper flexibility for this sort of change is a major weakness of the waterfall model.
The strict sequential structure of the waterfall model attempts to prohibit simultaneous work on different stages. Thus, if a problem that was created in an early development phase is not discovered until a later stage in the development process, the problem must either be ignored or the entire development process must be altered. In the latter case, the earlier development phase, which has been
‘signed off’ as complete, must now be reopened, and the life cycle must essentially be rewound to this phase. When the problem is corrected, development must continue from that early phase, in order to ensure that all of the proceeding work accommodates for the changes made. For this reason, errors discovered in later phases are extremely time consuming and expensive to fix, as they can require a full overhaul of the project (Sommerville2004).
In addition to its inflexibility, the waterfall model’s reliance on step-by-step development means that no tangible product is available for assessment by the client until late in the development process. This lack of feedback fails to ensure that the product which is being developed is compatible with the desires of the client. The discovery of such a mismatch, like the identification of any other design flaw, at such a late stage in the process can require time-consuming and costly backtracking through the entire development process (Stiller and LeBlanc2002).
The unpredictability of human error combined with the size and cost of many software engineering projects have made strict use of the waterfall model a risky endeavor. Many of the aspects that originated with this life cycle model, however, have become staples of more secure and flexible development paradigms. The development phases that Royce put forth are still used in nearly every software life
Analysis
Design
Implementation
Testing
Deployment Fig. 1.2 A model of the
waterfall life cycle
1.5 Software Life-Cycles 13
cycle, and the dedication paid to continual testing and meticulous quality assur-ance in order to catch inevitable mistakes have continued to prevent many mis-takes from becoming full blown catastrophes (Schach2008). Today, the waterfall approach is generally only taken when the requirements of a project are well defined and not likely to change.
1.5.3 Evaluation of the Spiral Model
The major downfall of the waterfall model is, in essence, its inherent level of risk.
Its use of a rigid development process means that no part of the software product can be tested until far along in the process. Due to this practice, errors and misunderstandings between the client and the developer are often missed until late in development. Fixing these errors is then much more costly to correct than it would have been at earlier stages of development. An alternative software life cycle, the spiral model, seeks to correct this problem by the use of practices designed to minimize risk. Specifically, the spiral model employs prototyping in order to test portions of the software product at various stages of development.
This feature is combined with concepts and practices from the waterfall model.
The result maintains the use of structure and well specified design phases from the classical model, but allows for greater flexibility and management of change.
Figure1.3 depicts the spiral model, as presented by its creator, Boehm (Schach2008).
In Fig.1.3, each cycle represents a phase in the development process. As can be seen, each phase consists of a series of activities, including planning, testing, designing and, most importantly to the model, risk assessment and prototyping.
The steps are generalized below.
• System requirements are defined.
• An initial (preliminary) design of the system in created.
• The initial design is translated into a prototype, which is then evaluated based not only on its strength and weaknesses, but its inherent risk.
• The evaluation of the first prototype is used in the creation of a second prototype based on an updated set of plans and requirements. This second prototype is tested and evaluated.
• Consultation with the client is used to evaluate progress. At this point, the decision is reached on whether to abort the project, or to continue on to the development of a new prototype, based on the evaluations of the previous ones.
• At this point, the project enters a loop, iterating over the preceding steps until either the client chooses to abort the project, or the client is satisfied with the most recent prototype.
• The satisfactory prototype is then used to design the final system, which is rigorously tested before final delivery to the client.
• Post-delivery maintenance is carried out for the remaining life of the product.