e evolves and decays (Lehman, 1980). As a software system 25.7.3.2 System testing is maintained the number of failures reported should tend to decline, but eventually there is decay and a point is reached at which the The system test of the completed, integrated system is the supplier's removal of a fault is likely to result in the introduction of at least one final check that the system meets its requirements. Here particularly new fault. it is important that the testing is carried out by a group other than that responsible for the development. The system test team create test sets based on the understanding 25.8 Software development environments of the customer's or end user's requirements, which often are not and cannot be stated precisely, and on the user documentation Classically, a software development environment has been re- provided by the developers. The tests exercise each required facility stricted to tools supporting the creation of code, compiling, linking and examine attributes such as performance, reliability, installa- and debugging. With the advent of methods and techniques address- bility and safety. Myers (1979) lists 15 categories of system test ing the earlier stages of the software lifecycle, and the recognition cases. that time spent at the specification and design stages is more cost Software configuration management 25/17 effective than putting all of the effort into the back end of the process Software configuration management then a typical software development environment is now expected to contain tools which support the method and all tasks associated Though no single lifecycle model necessarily fits all software devel- with software development; in particular: opments, a common feature of the application of the models is that development is an ordered sequence of operations, where each 1. Analysis, and requirements traceability. operation has a tangible output acting as an input to its successor. 2. Design. This means that a software product can exist in a number of repre- Automate