guration items are affected by it. The effort required and the time to complete are then estimated in terms of the probable size of the product e.g. MM (man months), KDSI (thousands of delivered source instructions), TDEV (devel- 25.9.4 Status accounting opment time), as in Equations 25.1 to 25.3, for organic, semi-or- ganic and embedded projects, respectively. There is usually a delay between the approval of a change proposal and the completion of the change. A status accounting mechanism MM = 2.4 (25.1) maintains a record of how the product has evolved and how it relates, at any time, to the issued baseline documentation and the set MM = 3.0 KDSI1¹12 TDEV = 2.5 MM ¹.35 (25.2) of authorised changes. Status accounting keeps track of changes, recording which parts of the changes have been implemented. MM = 3.6 KDSI ² ² TDEV = (25.3) The kinds of data which may be kept include: Intermediate COCOMO improves on these crude estimates by 1. The formal name of each configuration item. applying multipliers based on: 2. The baseline existing for each item. 3. The dates at which baselines were set. 1. Product attributes, such as the required reliability. 4. Who is responsible for the item. Computer attributes, such as the performance constraints. 5. What change proposals affect each item. 3. Personnel attributes, such as programmer or designer capa- 6. The status of each proposed change. 7. The version number of each item. bility. 4. Project attributes, such as the degree of use of modern develop- ment practices. In addition, copies of all change requests, proposals and notes are held. Each attribute is scored and a corresponding multiplier is then applied to adjust the basic COCOMO estimates. Detailed COCOMO provides the further refinement that the 25.9.5 Configuration auditing multipliers are sensitive to life cycle phases. In each case, it is necessary for COCOMO to be calibrated to fit The purpose of auditing in configuration management is to ensure the organisation whose projects are being modelled, for no single that