The SOCRAT project is important because it shows what organisations can do once they have established a software development process model, and design their system around reusable software components. Humphreys has characterised the transition from the 'defined process' to the 'managed process' by the attempt to cost the steps in the development process. This paper gives a practical demonstration of how this can be done.

The existence of these common functions implies that cost savings can be achieved through software reuse. The four dedicated control systems built so far use ORACLE software for database management and the Spacecraft Control and Operating System (SCOS) for telemetry processing. The SCOS development costs were outside the scope of SOCRAT. Differences in lower-level mission requirements limit the possibilities for software reuse. All the spacecraft have differing payloads and have distinctive payload data processing and distribution policies, for example.

All DCS projects are carried out according to ESA's Software Engineering Standards [11. These standards define a life cycle model of six phases:

• user requirements definition (UR);
• software requirements definition (SR);
• architectural design (AD);
• detailed design and production (DD);
• transfer (TR);
• operations and maintenance (OM).

The standards define the inputs, activities and outputs of each phase. All DCS projects adopt a incremental delivery life cycle approach towards software development. This means that the delivery of system functions is staggered to match the rest of the project schedule. The project plan will therefore consist of one UR, one SR and one AD phase and several DD, TR and OM phases.

Although the control systems are designed and implemented for ESOC by different contractors, the existence of a standard life cycle model facilitates comparison between different projects at the highest level. All projects will, for example, deliver a Software Requirements Document with a standard structure.

In planning a project, managers always develop a 'Work-Breakdown Structure' (WBS) that decomposes the project into separate jobs called 'Work Packages'. Early in a project work packages are all high level, like 'Write Software Requirements Document'. Later, when the architectural design is complete, the work breakdown structure follows the software component structure. The number of levels in the work breakdown structure increases.

Work packages are the cost elements of the project. Project plans contain estimates of work package costs, and project reports contain actuals. If the cost of each work package is known, the cost of the project can be calculated by summing the costs of the work packages. This microscopic approach to cost estimation is preferable to the algorithmic ones, such as COCOMO, when systems are:

• similar in functionality;
• built by similar organisations;
• costed in detail.

While the macroscopic approach used by COCOMO is useful when these conditions are not met, using COCOMO throws away information when they are. For example if job 1 contains work packages A, B, C and D and job 2 contains only A, B and C, the approach to cost estimation cannot be to calibrate a formula to describe the cost of job I and then apply it to job 2. The simpler, more accurate, approach is to subtract the cost of work package D from the cost of job 1. Of course, this relies on knowing the individual costs of A, B, C and D, and not their sum. This means that projects must practice precise cost accounting. ESOC and its contractors have been doing this for many years.

Another reason why COCOMO was not suitable for use in costing DCS developments was because it relies on estimating the number of lines of code. Ibis usually cannot be done until the architectural design is complete, and this is too late for ESOC managers. The Albrecht function point analysis method could be applied earlier. Unfortunately the Albrecht approach was devised for information systems, not real-time systems.

The approach to cost estimation for SOCRAT was to define a cost model that assumed a generic work-breakdown structure. The DCS project work package exists at the top level (zero). This work package was decomposed into the six phases defined by the ESA software engineering standards. Each phase work package was decomposed into work packages covering the activities required for each phase, such as project management, analysis, design and coding and testing.

The detailed design, coding and unit testing work package was decomposed into work packages that follow the typical DCS architecture. Work packages were defined for the eight functions listed above. Each of these was further subdivided into common work packages and project-specific work packages.

There was considerable variety in the design of dedicated control systems between projects. This was due to variation in requirements, contractors and designers. The work breakdown structures differed as a result, making direct cost comparison impossible. To this problem the following procedure was adopted. For the DD and TR phases of each project:

• list all the bottom-level work packages;
• attach the cost of each work package;
• partition the work packages into groups corresponding to the eight functions.

This step in the analysis separated the level 4 common functions from the mission-specific level 4 functions. Figure 1 shows the generic work-breakdown structure.

There are 96 work packages.

The SOCRAT data allow the cost savings possible through software reuse to be estimated. The generic work packages include 77% to 87% of the total effort required to build the four dedicated control systems studied. This means that less than a quarter of the effort will be required to construct the novel functions of a new system. A related statistic is that the effort required to build the software for common functions for the average system was twice that required to build the mission-specific functions. These measurements quantify what ESOC already knows: more kernel software should be developed for reuse between missions.

Twenty-three work packages cost models were built to explain cost variations observed at levels three and four. For work packages that implemented a system function, the approach used was to examine the design documentation for differences in functionality. Tables 2 and 3 illustrate the approach. Typically the lowest cost work package would be used to define the cost of the basic function. Additional functions would be used to explain variations in the cost of the work package in other projects. Cost data on the subfunctions was not available.

A different approach was required for the management work packages, such as those concerned with project management and configuration management. Simple models assuming a constant level of effort (e.g. one full-time project manager) for the duration of the project explained the data accurately.

The work package cost models could not fully account for the actual costs (for example the errors in Table 3 are 1, 3, 0 and 4 man months). Work is currently under way to check if these differences reflect real differences in the volume and complexity of the code. Differences in productivity due to the difference in experience of different contractors, or even project teams from the same contractor, were only observed in one instance. The unexpected rarity of this effect probably reflects the fact that personnel differences even out in large projects.

As well as being at the heart of the cost model, the generic WBS can be used to organise the work of an DCS software project. Adherence to the standards is built in from the start. Activities will not get accidentally omitted in the transformation from the standards to a project schedule.

The output of the analysis work was a Software Requirements Document for the SOCRAT and auxiliary documents describing the cost model. These were input to the design and implementation phase of the SOCRAT project.

Stages may be costed in one of the following ways:

• sum substages - the estimate is a sum of substages;
• algorithmic - the estimate is calculated using a cost model;
• fixed percentage - the estimate is calculated as a fixed percentage of the current phase or activity;
• historic default - the estimate is calculated as a percentage of a historic value for the current phase;
• prompt - the user provides the estimate, using the guidelines provided in the help text;
• default - the estimate is taken from the default provided.

The higher level stages usually just calculate the sum of estimates from their substages and perform range checking. The cost models embedded in the lower-level stages use one of the other methods. At the project level, summing all substages gives the Cost-To-Completion (CTC) of a dedicated control system. The cost of a phase can be estimated in two ways:

• by summing the substages of the phase;
• by extrapolating from the cost of completed phases using the phase% model.

The RSL rules embedded in each stage make use of libraries of 'questions' and 'functions'. Questions are used to obtain data from the user for the cost model. Several types of questions are possible, ranging from prompts to multiple-choice menus. Functions are written in RSL and codify operations common to several stages. SOCRAT's cost data is contained in a database that is accessed by a function. Stages that need the cost data for estimating and range checking call the function.

A user estimates with SOCRAT by cloning the generic work breakdown structure and working through the bottom-level work packages. Each stage employs one of several possible input mechanisms:

• select the historical mission most similar to the current one;
• select a cost model from a menu (the stage may support different ways of estimating, one of which can be selected);
• answer yes or no to a series of questions (effectively following a decision tree to choose items from the model);
• enter a numeric value for the estimate;
• enter the minimum and maximum values;
• enter an engineering-judgement sliding-scale value (e.g. in range 1 to 10);
• override an estimated value.

The initial cost of a stage is always an upper and a lower limit, rather than simply zero. As the user estimates each work package, the range of cost is narrowed down. After estimating a set of substages, the user is returned to the parent stage, whose cost is then summed. The time of an estimating session, from logon to CTC result, can last as little as twenty minutes.

The framework cost model is maintained by the SOCRAT Administrator, who can update the global database and the stage cost models. Ordinary users cannot alter the global database.