Software Development Processes Course: Research Paper
Script for
The Waterfall Model
Slide 1:
Each software product has a lifecycle, the sequence of phases thru which that product passes from inception to retirement from active use. Successful products may have lifecycles extending over several decades. The actual development portion of those lifecycles is usually a few years ( 1- 3) with the products spending most of their lifecycles in maintenance and support. Royce published a description of the first software lifecycle in 1970. This is the Waterfall. This presentation describes the Waterfall Model and a couple of major variants of it. Later presentations will describe the iterative, iterative-incremental, continual, and combinations of these models.
Slide 2:
As with many areas of Software Engineering, vocabulary for lifecycles is not standardized. Some software engineers refer to a lifecycle as a process model. Others use the term lifecycle. We use lifecycle to mean the phases thru which a product passes, either sequentially or iteratively. The lifecycle describes how the phases fit together. Later, we will examine major methodologies. A methodology is how the various phases are implemented. A methodology, such as Scrum, describes practices the developers should follow, and the relationships among those practices and the phases.
Slide 3:
A phase may include multiple activities. The Waterfall does not specify whether these activities are to be performed sequentally, in parallel, or in some more complex fashion.
The Waterfall uses a largely sequential movement thru the phases with limited opportunities to backtrack to an earlier phase when problems, inconsistencies, mistakes, or infeasible situations arise. However, different software engineers define different sets of phases. Sometimes multiple terms are used for the same phase, and sometimes the phases are partitioned differently.
Roger Pressman defines five phases in his version of the Waterfall. Communication includes project initiation and requirements gathering. Planning includes establishing a schedule and staffing plan as well as setting up mechanisms to track progress thru the remainder of the development portion of the lifecycle. Modeling includes analysis of the requirements and design of the product. Construction includes writing the product code, and testing that code. Finally, deployment includes delivery of the final product, support, and feedback from users.
Ian Sommerville actually has two different sets of phases in his textbook. Only one of those sets is presented here. For the other, see page 49 in his book. The details of the book are given in the Course Syllabus. Specification includes initiation, requirements engineering, an design. Development includes coding, unit testing, and integration testing. Validation includes system testing, and acceptance testing. Evolution includes delivery, support, and maintenance.
Slide 4:
In this course, we will employ a different set of phases. The proposal phase starts with a project proposal, usually by a business unit. This phase includes the decision to attempt the development. Requirements engineering then develops the product requirements and does some preliminary analysis of them. Planning develops a project schedule, and staffing plan. Design completes the analysis of the requirements and determination of the structure, data, user interface, and algorithms for the product. Construction includes coding and unit testing. Testing includes integration testing, system test, and acceptance testing. Deployment is the release of the product to potential customers and support. Finally, maintenance is the correction of errors and the evolution of the product to fit new environments.
The actual phases do not matter. The basic idea of the Waterfall is that the phases are performed largely sequentially with limited backtracking.
Slide 5:
Now let us discuss the most important aspects of the Waterfall. Although almost no published description shows it, some other activities are going on in parallel with the main development. These include monitoring the development project to ensure that the project is proceeding according to schedule. Management is tasked with responding to significant deviations from the schedule. Management responses might range from trying to encourage the developers to work more effectively through forcing extra work hours such as evenings or weekends, or negotiating with upper management to reduce requirements or lengthen the schedule, to recommending cancelation of the project.
Other parallel activities include:
• Preparation of user and operating documentation;
• Preparation of training materials;
• Bringing new developers up to speed on the project as needed
One very important characteristic of Waterfall is that most communication among developers occurs through a formal document which must be reviewed and approved before development can proceed to the next phase. The Proposal phase ends with review and approval of a Project Vision. The Requirements Engineering phase ends with review and approval of a Requirements Specification Document. The Planning Phase ends with review and approval of a Schedule document and a staffing plan. The Design phase ends with a Design Specification. Construction ends with actual code and a complete set of unit tests and their execution results.
Backtracking within a phase is very common and not disruptive. Although Backtracking between phases is possible, in most cases it is very disruptive. However, backtracking between Construction and Testing is often the exception to this.
Slide 6:
Waterfall is still used in many software development projects today. Most developers do not like it, however, because Waterfall is designed more to benefit management than the developers. Project and upper management make the decisions. Management finds the reviewed and approved documents which must be produced to move on to the next phase a much more effective way to evaluate development progress than asking the developers. Managers get to make decisions on whether or not the project should proceed at the end of each phase.
Waterfall encourages the use of specialists in such areas as database, user interface, testing, or networking. These specialists may be employed for one phase of the development. Compared to the other lifecycles, Waterfall may be more feasible for inexperienced or less-than very capable developers.
The collection of reviewed and approved documents produced at the end of each phase provides a very valuable resource for maintenance and support. Some of these documents can be excellent foundations for the work of an independent Quality Assurance group.
Waterfall emphasizes formal communication through documents. Compared to the oral communication encouraged in some other lifecycles, formal communication at least guarantees that some necessary communication among developers and between developers and other parts of the company occurs.
Finally, customers and potential users are busy with their own jobs and interests. Waterfall requires their involvement only at the very beginning of the project and once the product is deployed. Potential users do not have to take valuable time from their jobs to exercise and provide feedback upon partial products.
Slide 7:
Of course, Waterfall has several significant disadvantages. Determining if the developers actually have all the correct requirements at the end of the Requirements Engineering phase is extremely difficult, if not impossible in most situations. Deciding if a design is actually complete and feasible before it is implemented is extremely difficult. Determining if a program has been adequately tested is often impossible. As we will see later in this course, testing nonfunctional requirements adequately is much more difficult than testing functional requirements.
Some backtracking such as from Design to Requirements or Testing to Construction is expected and not too difficult. However, backtracking all the way from Testing to Requirements because some requirements turn out to be infeasible is very expensive and unlikely to be successful. Other possible backtracking can be expensive as well. In some cases, the developers might need to use specialists who are no longer available because they have moved on to other projects. Any significant backtracking requires a major adjustment of the schedule and, maybe, the project staffing.
In most companies, for a development team to remain unchanged thru a single project lasting three to five years is unlikely. For that team to remain unchanged through multiple projects is even more unlikely. Furthermore, each software development project undertaken even by the same company is very different than the other projects that company has done. The developers learn a great deal as the development proceeds. Therefore, adhering to a previously specified schedule is often impractical.
Change is inevitable for the clear majority of development projects. Not only does the development team learn important things they did not know at the start of the project, but the competitive landscape and user expectations change significantly during the years that the project takes. Some software engineers have estimated that a typical commercial development project has an average of 1% change in requirements for each month. Thus, a three-year project would see more than one third of the initial requirements change. Of course, these requirements changes would result in design and code changes as well as test case changes.
Finally, the lack of partial releases partway through the project means the developers receive no feedback until the project is complete. The risk of implementing an incomplete or inappropriate product is great.
Slide 8:
In spite of these disadvantages, there are still times when the Waterfall lifecycle is a viable choice. While it is less common than in the 1960’s and 1970’s, some governmental agencies, especially Defense Departments, still use Requests for Proposal (RFP) to request outside companies to implement needed software for them. The RFP contains a complete set of requirements, and often, a date by which the software must be produced. A company can bid to produce this software. The winning company receives a contract specifying penalties for not producing the software on time, and a mechanism for receiving additional pay, if the project runs into unexpected difficulties.
If a development project, perhaps using a different lifecycle, needs a prototype, Waterfall can be a viable approach to producing the prototype as a subproject. Prototypes often are used to evaluate and refine possible user interfaces, or to explore the feasibility of a given algorithm or data structure.
Finally, some informal projects may benefit from the use of Waterfall. The insistence on formal rather than informal communication might be helpful when more than one developer is involved. Inexperienced developers can benefit from the sequential nature of the Waterfall phases.
Note, that in all three circumstances where Waterfall might be a reasonable lifecycle, the product requirements are unlikely to change significantly.
Slide 9:
The remainder of this presentation examines a couple of popular variations on the Waterfall. The V Model emphasizes the fact that once the code is produced, there are a sequence of evaluation phases which use successively higher level documents to guide the testing of the code. Thus, unit testing is based on the source code itself. Integration testing is based on the document reviewed and approved to end the Component Design phase. System testing is based on the document that comes from Architectural design. Acceptance testing uses the Requirements Specification as its basis.
When applied, the V model generally has a planning phase before requirements engineering and a deployment phase after acceptance testing.
Slide 10:
Another Waterfall variation involves dividing the proposed software product into two or more largely independent pieces. The pieces should interact only through a limited set of narrow calls, usually implemented using application programming interfaces (API). Scheduling of the implementation of each piece can be done in either of two ways: based on the sequence in which the pieces need to be available for users; or based on the amount of risk believed to be associated with that piece.
Then the lifecycle works by doing a separate Waterfall project to implement each piece.
Slide 11:
We could have separate development teams implement each piece at the same or overlapping times. These teams could be co-located or in different places. As an alternative, we could implement one piece at a time. Sequential implementation might support recognizing needed modifications to an earlier piece and using their implementation as a new Waterfall.
Whatever of these slightly different approaches is used, each piece implementation should take three to six months.
Note that if the pieces are implemented by different teams, care must be taken to ensure the teams have the same meaning for the interfaces between pieces. In this variation of Waterfall, formal documents are used for each interface. These documents are reviewed by each team and approved.