Large software systems are organized collections of parts. The way a software system is put together from these parts has a critical impact on project success. Incremental development is a top-down approach to development in which a software system is developed and tested as a succession of cumulative subsets of function. A minimal system is developed in the first increment, and function is added in each successive increment until the system is complete.
Each increment implements one or more end-user functions. Each increment contains all previously developed capability plus this new capability, so the system is “grown” in cumulative increments. Incremental development enables intellectual control over system development through referential transparency. (Referential transparency essentially implies the use of pluggable components with a fixed interface.) When referential transparency holds, a system part can be implemented from its subspecification with no need for backtracking; there is no rework of previous increments. This strategy enables correctness verification of each increment in a complete system context. This referential transparency clarifies one of the advantages of having system requirements for an evolutionary system known in advance of development.
Cleanroom incremental development permits continual integration of referentially transparent user-function increments over the entire development life cycle. Because the design of each increment is based on a verified subspecification and tested interface in a prior increment, deep design and interface errors should be rare. The system evolves in well-defined increments throughout the development. Testing and certification activities begin early in the development cycle.
Incremental development as practiced in cleanroom also provides a basis for statistical process control. Each cleanroom increment is a complete cycle of the process, involving specification, development, and verification of new user function plus testing of all work completed to date. This allows for measures of performance in each iteration of the process to be compared with performance targets to determine whether or not the process is “in control” (i.e., performing as expected). If standards are not met, the team can examine performance data from the increment to identify problems, adjust project plans if necessary, and modify the software development process to prevent recurrence of the problems identified. For example, if testing of an increment reveals that the process is “out of control”