d code and data base generation wherever possible. sentations at the same time. There may be a specification, a design 4. Automated extraction of design material, and inclusion into text, source code for the program and loadable code, each defining documentation. the final product. It is a function of configuration management to 5. Automated production of test cases. ensure that each representation is consistent with all of the others. 6. Access to editors, compilers, debuggers. Software products tend not to be stable; faults are corrected and 7. Configuration management of all objects from design elements enhancements are made. Configuration management makes it through to data structure definitions. possible to record the status of any representation of a software item, 8. Reverse engineering. to be able to say which changes have been applied to it and which have not (Bersoff, 1979). In addition, it is expected that such environments are tailorable to match the project needs in a number of ways, for example: 25.9.1 Baselines 1. Automatic production of function headers obeying project standards. A baseline is a fixed reference point in the software development. It 2. User definable annotation types to allow automatic extraction is a good point from which change can be measured. and inclusion of the text in documents. If the project management is applying a lifecycle model to the 3. Addition of menu options which when selected invoke a user development then the work will move through a series of phases, program to perform a project specific task. from one phase of the lifecycle to the next. It is conventional to draw a baseline at the end of each of the phases. The end of the phase will Each project requires a different level of tailoring which may be be marked by a completion of appropriate documentation or com- puter files. This tangible output becomes the base line for the phase. either trivial e.g. specifying a different function header layout, to substantial e.g. redefining or adding graphical symbols; or def