The standard waterfall model for systems development is an approach that goes through the following steps:
This model is widely used on large government systems, particularly by the Department of Defense (DOD).
As part of this standard approach, the party responsible for contracting out the system development (ESDIS for the ECS Contract) can call on a number of tools to help plan and document the system. ECS followed this planning approach, which means that early in the system development, ESDIS set up a standard set of documents for the contractor to supply, as well as a contractual schedule for the major pieces. The development process provided a number of design reviews, notably
Until these reviews were completed, there would be little code developed. After the CDR, the contractor would code to the design.
The standard reference for estimating the cost of the system is the COnstructive COst MOdel (COCOMO) developed by Dr. Barry Boehm while he was at TRW [Boehm, B., 1981: Software Engineering Economics, Prentice-Hall]. This model relates the development time and workforce [man-months] to the "Source Lines of Code" (SLOC). Roughly, for an ECS type of system ECS, the workforce (and therefore cost) scales as the cube of the development time. There are simple versions of the model and much more complex ones. Generally, all of the relationships used to predict these relationships are statistical in nature: Dr. Boehm and other workers in software project cost estimation build a database of project schedules and costs and then regress those against SLOC estimates. The most recent version of Dr. Boehm's work is provided in [Boehm, B., et al., 2000: Software Cost Estimation with COCOMO II, Prentice-Hall.].
There have been a number of criticisms of the standard waterfall model, including
The standard waterfall model is associated with the failure or cancellation of a number of large systems. It can also be very expensive. As a result, the software development community has experimented with a number of alternative approaches, including
These are discussed in considerable detail in [McConnell, S., 1996: Rapid Development, Taming Wild Software Schedules, Microsoft Press]. Commercial software projects often reduce the formality of the full waterfall model. In the last few years, a paradigm known as eXtreme Programming has emerged that emphasizes reducing the cost of software changes, developing test cases before coding, developing code using pairs of programmers, and putting most of the documentation into the code [Beck, K., 2000: Extreme Programming Explained, Embrace Change, Addison-Wesley].