The approach is predicated on the principle of completing, in detail, each stage before moving on to the next; the optimistic assumption is that the customer knows and can express the detailed requirements at the outset, that the software requirements as specified can be implemented predictably and that the requirements don't change during development.
Royce points out that the Testing stage, which occurs towards the end of the development cycle, is the first time that the developed system is experienced, as distinct from analysed. In the event that the delivered system is not what was expected or some requirements have been missed, then a major redesign is necessary. At the very least, the system design must be revised in response to weaknesses or errors exposed in testing, but if external criteria have not been satisfied then either the requirements must be changed (descoped) or the whole system must be revisited. He comments "In effect, the development process has returned to the origin and one can expect up to a 100% overrun in schedule and/or costs".
Royce accepts that the sequence of events is logically sound but that the principle of finalising each stage before the next commences is flawed. His outline alternative proposal comprises 5 steps:
- Insert a preliminary Program Design phase between Software Requirements and Analysis; whilst this must be based on incomplete information (as there is no analysis), it will be able to deal with fundamental non-functional requirements such as performance and volumes, thus setting some constraints for subsequent analysis.
- Document the Design so that subsequent phases are working towards a common, well-defined specification
- Do it Twice. Construct a pilot version of the system, the contents of which will depend on the extent and nature of critical problem areas. It is the second version which is delivered to the customer.
- Plan, Control and Monitor Testing
- Involve the Customer so that he commits himself to the direction the development is taking at the earliest stage.
In modern-day parlance, this proposed approach would be described as risk-driven and iterative.
The majority of software projects are today still based on the waterfall approach, perhaps with some fine-tuning, and are often accompanied by intimidating methods and standards whose sheer complexity implies sophistication - this can be misleading. Characteristics of such projects typically include:
- Major problems typically occur only during the Integration stage, usually too late to be accommodated within the project calendar. The effect tends to be either a descoping of the project to deliver it on time, a ‘squeeze’ on the time allowed for testing to try to hit the end date, an overrun or a combination of any or all of these.
- The tendency to build detailed project plans, right up to the end of the project, at as early a stage as possible. These soon become obsolete and are typically subject to frequent and time-consuming revision. This has a contingent effect in terms of disruption to the team’s work schedules and often morale.
- Too much optimism in the earlier stages in terms of the amount of rework that will ultimately be necessary and the lack of adequate planning for rework.
- Potential disconnect with the users between requirements gathering and delivery because of the time lapse.
and last, but certainly not least -
- the insistence by management that an accurate estimate of cost, timescales and resource requirements is submitted before the work even starts
Royce set the scene for iterative development, although it must be recognised that it was not a new concept: other scientific and engineering disciplines had been following an iterative approach for generations, if often informally. The simple rationale is that if you're doing something new, first explore the technical boundaries and constraints, by experimentation or some other means, then, when you know what is technically viable, review the design with the customer and confirm that both the technical and functional content are acceptable and justifiable. There can be few among us who cannot recall a number of major public sector projects which would have been abandoned at an early stage had the true ultimate costs and timescales been known.
Of course, much has changed since Royce wrote his article in 1970. Software development languages and tools, architectural concepts, reusable components, hardware cost and performance, sophisticated modelling techniques - and the maturing of iterative development techniques by a relatively small (and relatively successful) proportion of the development community.
The iterative process adopts the logical sequence of events of the Waterfall model but it follows the full lifecycle several times within a single project. Each iteration goes through the activities of Requirements, Analysis, Design, Coding, Integration and Testing and produces production-quality software at the end of the iteration. The content of each iteration is determined according to risk - the new, the most challenging, the most critical elements are built first, usually by a core team of the most skilled practitioners, so that the true nature of the project and its implications in terms of cost and time are constantly under review. Thus, certainty increases as the project proceeds - or, if the development is no longer viable, it can be halted at an early stage and at minimum cost.