The existential practice of deciding what Configuration Items there will be on a project.
This process executes in two distinct modes, depending on the phase of development:
- In the early phases, the customer and developer haggle1 over how much detail should be reported to the customer on a regular schedule. The context of the discussion is usually a notional design as communicated in a proposal, along with how the customer abstracted the system when establishing the original requirements. These might, in some contexts, be referred to as “Development Configuration Items”.
- In the later phases, the developer’s design may be noticed as having certain items worthy of independent procurement (e.g., spares) and upgrades. These may, in some contexts, be referred to as “Logistics Configuration Items”2.
The distinctions between CI’s identified in the two modes cause a great deal of confuscation: it is possible for a Logistics Configuration Item to have a C-spec without previously having had a B-spec. Many System Engineers appear unable to understand how this can be possible – they’ve been implicitly taught that there is a 1:1:1 relation of Development Requirements, Qualification Requirements and Acceptance Requirements. That notion only came into vogue when we started trying to use Relational Databases to track requirements (object-oriented databases would have worked better, but they weren’t available at the time).
But it gets worse! It is possible for a Logistics CI to be selected for an upgrade after the system is in the field. Usually, a set of new development requirements will be published in a development specification (sometimes referred to as a “re-development specification”). The new specification will want to distinguish between the original version and the upgrade, so we write “requirements” as if we had known ‘way back then how the design would turn out. It will also contain requirements for the upgrade, distinguished in the document by use of some classification scheme. Some years later, it will appear as if both CI’s had been identified early, rather than late – unless somebody thinks to check the document dates relative to the original development schedule…System Engineer, meet rat hole.
Footnotes- Because every customer wants infinite insight for zero cost, and every developer wants zero oversight for infinite pay.[↩]
- Noodle-baking alert! The immediate next-higher assembly might, or might not, be a CI in its own right at the time of late-designation. Sometimes, that next-higher assembly (and so on up the line) might be so-designated late in order to mitigate that perceived issue, which might make it look as if it always should have been, even if it did not previously need to be.[↩]