ining With most lifecycle models it becomes necessary to re-enter an a change to the underlying method process supported by the envi- earlier development phase. (A system design error may be dis- covered during the detailed design, for example, and SO the system ronment. design has to be reworked). If a phase is re-entered then the rework These requirements have led to a number of environments being of that phase will generate a change to its baseline. A configuration produced; in general they are in three categories: management system will record established baselines and all changes to those baselines. 1. Fixed environments supporting a given set of methods which There is a difference between work done to establish a baseline are not easily changeable. and rework done in the same phase of the lifecycle after the baseline 2. Environments which support a given set of methods but which is established. The path taken to reach the baseline need not be are written in an open and modifiable way. They are charac- recorded but each step thereafter is. terised by the fact that all interfaces (for example to the under- lying data repository) are clearly documented and available for use by non-experts, and that all menu options, formats for 25.9.2 Configuration identification function headers etc. are in files which the user may modify according to the project needs. Configuration identification establishes the composition of the soft- 3. Meta-environments which provide the facilities to create a ware item (what other items it is made from) and the documents and software development environment which matches the user's files which define it. needs exactly. Category (1) is most suited to projects where the users wish to be 25.9.2.1 Configuration items guided by the environment and it is not desirable for any changes to the method to be made. For all but the most simple software products, the product design Category (2) is for users who wish to use a particular method, but activity will include breaking the product down into