U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
California Division
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
OBJECTIVE: Configuration management ensures that project documentation accurately describes and controls the functional and physical characteristics of the end product being developed [establishing system integrity]. Configuration management is also used to maintain consistency of system changes to its documentation. This occurs throughout the system life cycle [maintaining system integrity]. |
DESCRIPTION: Configuration management [CM], in conjunction with other systems engineering activities, is used to establish system integrity [integrity is defined as all system functionality, physical characteristics, and design match its documentation] and then maintain this integrity throughout its life. The following are the activities for configuration management:
Interface management is a key configuration management practice that has a focus on interfaces. Since interfaces give the system leverage and access to stakeholders there should be special attention paid to them. Usually a specialized group [or individual] called the interface control working group is established just to manage interfaces. |
CONTEXT OF PROCESS:
CONFIGURATION MANAGEMENT |
Inputs: Project Products that have been approved to be managed under the CM process throughout the life of the system. Change Request[s] for products under change management control. |
Control: SEMP/Project Plan will contain the CM plan[s] for the system's owner and development team. |
Enablers: Stakeholder involvement in the change management board and in changes that affect them. Technical reviews are used to evaluate changes prior to submission to the CM board. Control Gates are used to establish baseline products that allow the project to move forward to the next phase of work. |
Outputs: CM Plan contains the process needed to carry out CM for the project. Change Decisions on change requests. Verified changes after the implementation and synchronization to the documentation. Supporting change data that identifies the change and rationale for the change. |
Process Activities: Plan configuration management activities There are three application areas that need planning. The agency's CM plan for the life of the system, the implementation team's CM plan for development, and the CM Plan for COTS product vendors. The agency's CM plan should identify the requirements for the development team's CM plan and vendor's CM plan and the needed outputs to support the life of the system. Identify configuration items This step identifies items that will be managed under the CM process. These are called “Configuration Items [CI]”. These items exist at all levels of decomposition and occur in each phase of development. For example, baseline requirements and design documents developed during the definition and decomposition of the system are configuration items. When products are identified, e.g. sub-system at the detailed design level, and when the end products of software and hardware are complete functional units, these are product level configuration items. Finally, when the system is deployed, the operational baseline is a configuration item. Manage change This is the process to manage changes to the configuration items. This involves a change management board and documentation that identifies the change, rationale, cost, risk, and priority. Perform status accounting This step collects change data and is used for status and analysis purposes. Perform configuration audits There are two types of audits, [functional and physical]. Functional audits match the product to the functional and performance requirements [acceptance verification]; and physical audits match version numbers and physical identifiers with the documentation. Manage interfaces This step manages the interfaces of the system. This activity controls both external and internal interfaces. Interfaces that are shared with other agencies should have an Interface Control Document [ICD] that contains an memorandum of understand [MOU] that agrees to the specification for the interface. |
Where does the Configuration Management take place in the project timeline? |
Is there a policy or standard includes Configuration Management?
FHWA Final Rule does not specifically mention general Configuration Management practices to be followed. EIA 649 National Consensus Standard for Configuration Management and the Mil-Hbk-61 provide a great deal of application information.
Which activities are critical for the system's owner to do?
How do I fit these activities to my project? [Tailoring]
The CM process is scalable to the level of custom development that is being done. For systems that are all COTS products, the primary CM activity is a review of the vendors' CM processes to ensure the vendor will provide appropriate updates to the product and notices when the product changes or is discontinued. This continued support most likely will require an on-call service contract and a warranty period. On the other end, where the development is a large multi-regional system with multiple stakeholders, and a mix of custom hardware/software and COTS products owned by the system's owner and stakeholders, the CM process will be more involved.
What should I track in this process step to reduce project risks and get what is expected? [Metrics]
On the technical side:
On the project management side:
Checklist: Are all the bases covered?
 |
Is there a CM plan for the project? |
|
Was the plan reviewed and supported by all the stakeholders? |
|
Is the organization for CM in place for the project? |
|
Is there sufficient funding to sustain the CM activities throughout the life of the system? |
|
Does the development team have a CM process and was it reviewed by the system's owner and stakeholder? |
|
Is the product documentation completeto the extent that the system's owner can use another qualified development team to upgrade and maintain the system independent of the initial development team? [extremely important] |
|
Does the COTS vendor have a CM process for their products? |
|
Does the vendor provide a notice of design changes? |
|
Does the vendor provide a notice of obsolescence? |
|
Does the vendor provide on-going maintenance support? |
Are there any other recommendations that can help?
Configuration management for systems development is a management process for the project products. Configuration management works together with a good systems engineering process. The systems engineering process provides the orderly establishment of the project products and documentation and Configuration Management is used to maintain consistency between the system changes to its documentation.
Use configuration management as an evaluation tool and discriminator for vendors of COTS products and development teams . COTS products for Intelligent Transportation Systems should have a long life through upgrades. A vendor that has a good internal CM process can show how their products are maintained and upgraded. The vendor would not only maintain and upgrade their products on a regular basis, but issue notices of design changes, and notices of obsolescence when products reach their end of life. This type of service would most likely be part of an on-call service contract.
Configuration management should not be assumed as part of the project. It must be planned. The cost of Configuration Management on large projects is estimated at around 5% to 10% of the life cycle costs. This data was from an informal poll of systems engineers from the aerospace and defense contractors. This cost covers starting a CM activity from the ground up [10%] or using an existing in place CM process and extending it to include a new project [5%]. Once a CM process is in place, it should be used for future projects as well.
Internal interfaces may need Interface Control Documents [ICD] if the interface is shared with a partner agency's system or sub-system.
A closer look at three different environments for configuration management
System's owner has the ultimate responsibility for the system over its life. Various development teams and vendors may be involved in providing or developing products for the system and in providing upgrades, maintenance, and evolution of the system over its life. The system's owner should have a CM process that covers the life the system. The vendors and development teams working on the system should provide the products and documentation that will be compatible with the system's owner's CM plan.
Development Team[s] should have their own configuration management processes and tools when developing hardware and software for the system. This CM process addresses the low level procedures needed when software and hardware is developed. The system's owner should define the expected output from the development team's process but should not dictate how the development team performs CM. However, inspection of the team's CM process should show that it conforms to industry standards [see references for a list].
COTS Vendors should have internal CM processes that are documented and followed, and be willing to share their documented processes with the purchaser of their equipment. At a minimum, the vendor should maintain a configuration of the version of the product sold. This configuration should at a minimum identify the following:
These additional services may be available free over a warranty period. For extended periods of support they most likely will be at an additional cost.
 |
 |
