Topic 6: System definition and configuration management
As the title suggests, this topic has two underlying themes:
* defining the 'system' that constitutes the 'thing' we are to deliver to an agreed budget and schedule
* managing the physical configuration of that system as it evolves and is finally
There is an appreciation that a logical, top-down design methodology was needed, and that the acquisition of a system had to be managed on a total lifecycle basis. Overall system cost-effectiveness was the underlying objective. In other words, it is the optimum balance in the customer's judgement between system effectiveness and lifecycle cost. As a consequence, 'specialist' disciplines evolved—for example, reliability, maintainability, affordability—as well as others, such as safety, shock and electromagnetic interference.
Systems are the combination of people and processes, as well as hardware and software. It is the relationships between these elements—the interfaces between them—that are the primary focus, not the details of the individual elements. A system is an integrated composite of people, processes and products that provide a capability to satisfy a stated need or objective. In decomposing the system into subsystems, a guiding principle is that the interfaces should be as simple as possible.
A summary definition of systems engineering is that it is 'an interdisciplinary management process that evolves and verifies an integrated, lifecycle-balanced set of system solutions that satisfy customer needs' (DSMC, 2000: 3).
Systems engineering management integrates three major activities (DSMC, 2000: 3):
* development phasing, which controls the design process and provides baselines that coordinate the design effort
* a systems engineering process that provides a framework for solving design problems and tracking requirements that flow through the design effort
* lifecycle integration that involves customers in the design process and ensures that the system developed is viable throughout its life.
The process is:
* iterative (cycles from top to bottom more than once) and recursive (goes from bottom to middle, middle to top, or bottom to top) until the required outputs for that phase are completed
* applied sequentially, one level at a time, by integrated teams adding additional detail and definition with each level of development. In other words, it is repeated at each phase of the system lifecycle, first at the system level, then at the subsystem level, then at the component level.
The starting point is always with requirements, which need to be analysed, grouped and prioritised. Requirements always imply functions. No one wants a physical product as such; they want the functionality that a product provides. Map the functions (and thus the allocated and derived requirements) to a physical architecture (hardware and software elements). Where there are functions that can't be mapped to a physical subsystem or component, a new subsystem or component will have to be added (or modified). For each application of the process, a verification of the solution to the requirements has to be done; this is the verification loop. Keep going backwards and forwards between the physical system and the functions and requirements until you have a physical system that meets all the requirements. Develop the detailed design for the system elements, while ensuring that the technical performance measures and effectiveness measures will be satisfied.
Technical performance, cost and schedule are the three overall project elements to be tracked and controlled. Cost and schedule are tracked through specific cost and schedule control systems; technical performance has also to be tracked in a disciplined way.
TPM measures usually consist of the following:
* Planned value—the anticipated value of a parameter at a given point in the development cycle.
* Demonstrated value—the estimated or measured value
* Current estimate—the predicted final value for a parameter
* Demonstrated technical variance—the difference between the planned value and the demonstrated value of a parameter
* Predicted technical variance—the difference between the specification requirement and the current estimate of the parameter.
Managing requirements and specifications
There are three different categories of requirements: requirements that refer to the system, requirements that refer to the subsystems to be developed, and requirements that refer to the physical components to be built. Each of these requirement categories are captured in three specification types: system specifications, development specifications, and product specifications. Each of the three specification categories is managed through one of three 'baselines': the functional baseline, the allocated baseline, or the product baseline.
* Customer requirements
Customer requirements are statements of fact and assumptions about the system and the capability it is to deliver. Customer requirements focus on the functionality and performance that is to be delivered, but will also include requirements for test, support and documentation.
* Functional requirements
Functional requirements say what is to be done—what function is to be provided.
* Performance requirements
Performance requirements say how well something has to be done.
* Derived requirements
Derived requirements are implied or transformed from higher-level requirements.
* Allocated requirements
An allocated requirement is a requirement that results from the splitting of a higher-level requirement into a number of lower-level requirements.
* Design requirements
Design requirements are the product requirements; the 'build to', 'code to', or 'buy to' requirements for the system elements.
* Tracing requirements
Traceability is the ability to trace the requirements through progressively higher or lower levels of documentation in order to verify that all system requirements have been addressed in the system design.
Requirements are captured in specifications, and specifications form the basis for contracts and reviews. Consequently, just as we have layers of contracts and reviews, so we have layers of specifications. A system is a collection of interrelated components working together; these are component subsystems. The system results from the way subsystems interact with each other to provide a bundle of functionality greater than the sum of their parts.
Thus, we have three logical layers of specifications:
* system level
* subsystem level(s)
* product level(s).
Development specifications fall into three basic groups:
* Item Performance Specification. 'Item' development specifications—the specification for the complete subsystem or equipment
* Software Requirements Specification(s). Software development specifications—the specifications for the software items in the item
* Interface Requirements Specification(s). Hardware to software interface specifications—the specifications for the interfaces between the hardware items and software items in the item.
These are the 'detail' specifications that evolve from the development and apply to the building of the hardware and software items. The names assigned are: Item Detail Specification., Software Product Specification., Material Specification., Process Specification.
Although we can see from our discussion of specification types that there is logic to their origin and role, the way that the development and product specifications interweave in a system development can be confusing. A mechanism for enabling clear communication, for design and contractual purposes, on the subject of specifications is the 'specification tree'. The specification tree—which is just a diagram that shows the hierarchy of specifications that correspond to the system hierarchy—is a management tool. As such, it would be defined in the project systems engineering management plan. It is an important attachment, and is an essential part of the plan.
The tree is hierarchical and reflects the system decomposition. That is, it reflects the way the boundaries of the system and subsystems have been defined. The specification tree must map exactly the system breakdown reflected in the system part of the project work breakdown structure (WBS). The tree assists the traceability of requirements and indicates precedence if there is a conflict of requirements. The tree will determine how subcontracts are determined. The tree will reflect the physical elements against which project progress will be evaluated. The elements will have cost, schedule and TPM targets assigned to them.
The tree must reflect the WBS system breakdown because successful completion of the physical components of the system can only be assessed by acceptance against a specification. Otherwise, all that can be established is that something has been produced. If it does not perform its intended function it will be useless.
Managing system configuration
Configuration management provides documentation that describes what is supposed to be produced, is being produced, has been produced, and modifications that have been made to what was produced. Configuration management is performed on baselines, and the approval level for configuration modification can change with each baseline.
The project authority normally controls the functional baseline. Allocated and product baselines can be controlled by the project or the supplier
depending on the lifecycle management strategy. The implications of the ownership of baselines are that there is a hierarchy of authority for
control of the baselines.
A key point is that a Configuration Item is something whose function and performance are controlled to guarantee that: (a)it interfaces both physically and functionally with other items whose configurations are separately controlled, so that (b) the functions and performance of the total product are achieved.
Configuration baselines —Configuration baselines identify and define an item's functional and physical characteristics. The baselines are: (a) functional baseline—describes system level requirements (b) allocated baseline—describes design requirements for items below system level, (c) product baseline—describes product physical detail.
The focus of configuration management is threefold: (a) to identify the functional and physical characteristics of selected system components, designated as configuration items, during the system's acquisition., (b) to control changes to those characteristics., (c) to record and report the changes, as well as their implementation status.
Configuration management achieves its objectives through four functions; configuration identification., configuration control., configuration status accounting., configuration audits.
Change to the configuration baselines will be through an engineering change proposal (ECP). Generally, this panel is called the
Configuration Control Board (CCB) and is 'chaired' by the project manager.
In addition to an ECP, there are three additional types of change documents.
A Request for Deviation document; A Request for Waiver document: An Interface Revision Notice:
A very significant management activity is the identification and management of the external and internal system interfaces. As each interface often implies a different developer at each end, there are always a number of different contractors and organisations involved in ensuring compatibility of the interfaces. To do it successfully requires the establishment of interface control working groups where the relevant parties can liaise effectively.
Delivering cost-effective systems
Cost-effectiveness is the optimum balance in the customer's judgement between system effectiveness and lifecycle cost. This is sometimes called 'system value'.
The management task is to make sure that these two parameters: system effectiveness and
lifecycle cost, are properly integrated into the development process.
In particular, it is ensuring that the outputs from the
following specialist analyses are incorporated into each stage of the development process:
* reliability. The absence of failure or breakdown.
* maintainability. The measure of how easy it is to fix or repair an item when it breaks.
* availability. The overall time that a system is working.
* usability. How easy the system is to use.
* supportability. The ease with which the system can be provided with its consumables, regular spares and maintenance items.
* producibility, disposability, and affordability. The ease with which something can be manufactured, the lack of any specialist disposal requirements associated with hazardous waste, and the ease with which someone can purchase and maintain the system.