The use of a well-established development process for software is crucial. From early informal methods that were employed until the 1970s, some structure was imposed by the well-known Waterfall method. Using this approach, the development of a software system is broken down into a number of discrete phases. Completion of a phase permits the continuance of the development in the next phase. This approach, for instance, requires that specification be completed prior to undertaking any design work.
Software developed using the Waterfall method is therefore constructed unlike any other human activity. Feedback from lessons learned during development may only be returned at certain very specific points in the development cycle. Whilst this is unrealistic, it is done to prevent chaotic changes from being made to a product's specification during its development. Too many "good ideas" for the system's development, purpose or implementation could readily muddy the initial system's objectives. It would probably be late to market and be unlikely to meet its design reliability requirements.
However, the failure to recognise the need for experimentation or the possibility that the system's specification itself may be poorly understood at the outset of development remain obstacles to well-managed development using the Waterfall approach.
Other pages in this section outline modern processes, which overcome the shortcomings in the Waterfall approach. The newer processes are based on controlled experimentation, and provide the basis for much more cost effective production of reliable software systems.