A Guide to

Configuration Management for Intelligent Transportation Systems

April 2002

Prepared for

Intelligent Transportation Systems

Joint Program Office

US Department of Transportation

By Mitretek Systems, Inc.

Technical Report Documentation Page

1. Report No. FHWA-OP-02-048	2. Government Accession No.			3. Recipient's Catalog No.
4. Title and Subtitle A Guide to Configuration Management for Intelligent Transportation Systems				5. Report Date April 2002
				6. Performing Organization Code
7. Author(s) Paul J. Gonzalez				8. Performing Organization Report No.
9. Performing Organization Name and Address Mitretek Systems, Inc. 600 Maryland Avenue, SW, Suite 755 Washington, DC 20024				10. Work Unit No. (TRAIS)
				11. Contract or Grant No. DTFH61-00-C-00001
12. Sponsoring Agency Name and Address Department of Transportation Intelligent Transportation Systems Joint Program Office 400 Seventh Street, SW – Room 3416 Washington, DC 20590				13. Type of Report and Period Covered
				14. Sponsoring Agency Code HOIT
15. Supplementary Notes William S. Jones – Task Manager
16. Abstract This monograph is one of a series intended to introduce the topic of systems engineering to managers and staff working on transportation systems projects, with particular emphasis on Intelligent Transportation Systems (ITS) projects. Systems engineering is a discipline that has been used for over 50 years and has its roots in the building of large, complex systems for the Department of Defense. Systems engineering is an approach to building systems that enhances the quality of the end result and the expectation is that its application to transportation systems projects will make those projects more effective in developing and implementing the systems they are intended to build. Although applying systems engineering techniques on a project doesn’t guarantee success, not following a systems engineering approach is a strong recipe for failure. This monograph covers the topic of Configuration Management. Configuration Management (CM) formalizes the process of making changes to a system under development so that the system’s builders maintain an appropriate configuration record and can always ensure that they know what the correct version of the system consists of. It is intended to establish and maintain the consistency of a system’s performance, functional, and physical attributes with its requirements, design, and operational information throughout the system’s life and is considered a “best practice” within the system engineering discipline. Managing changes to requirements is essential to minimizing cost and schedule overruns on transportation system projects. CM’s ability to control changes to requirements is a major reason for employing it on ITS projects. This monograph is intended for use in conjunction with the systems engineering courses being offered by the National Highway Institute.
17. Key Word Systems Engineering, Intelligent Transportation Systems, ITS, Transportation System Projects, Configuration Management, CM			18. Distribution Statement No Restrictions This document is available to the public.
19. Security Classif. (of this report) Unclassified		20. Security Classif. (of this page) Unclassified			21. No. of Pages 51	22. Price NA

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized

Table of Contents

Section Page

List of Figures v

Executive Summary vii

Chapter 1 - Introduction 1

Purpose of This Document 1

Intended Audience 1

Origins of Configuration Management 2

Current Configuration Management Standards 2

Chapter 2 – Configuration Management Principles 5

Configuration Management Planning 5

Deciding What Configuration Items to Control 5

Deciding When to Control Configurations 10

Deciding How to Change a Configuration 12

Deciding on Configuration Management Resources 13

Configuration Identification 13

Configuration Control 15

Proposing Changes to a Configuration Baseline 15

Reviewing and Approving Changes to Configuration Baselines 16

Configuration Status Accounting 20

Configuration Audits 22

Chapter 3 – Configuration Management and ITS Systems 23

Using Configuration Management During ITS System Development 24

Using Configuration Management During System Operation 28

Web Development and Configuration Management 30

Configuration Management Costs 31

What If You Don’t Use Configuration Management? 32

Chapter 4 – Configuration Management Tools 33

International Council on Systems Engineering (INCOSE) 35

Institute of Configuration Management (ICM) 37

References 39

List of Figures

Figures

No. Name Page

1 Hardware Levels for Configuration Management 7

2 Baselines in the System Life Cycle 11

3 Sample Engineering Change Proposal 18

4 Sample Configuration Management Organization 19

5 Change Control Process 21

6 Traceability Matrix Row Example 25

7 Expanded Traceability Matrix Row Example 26

8 Revised Traceability Matrix Row Example 27

Executive Summary

Purpose of This Document

This document is one in a series of monographs on systems engineering topics developed to help introduce this discipline to ITS project managers and their staff. While none of these documents will turn the reader into an experienced practitioner in the area of systems engineering, they are intended to give their audience a sense of how the topic covered applies to Intelligent Transportation Systems (ITS). This monograph covers the topic of Configuration Management. Although other monographs in this series discuss configuration management briefly, none goes into the topic at the same level as this one.

Intended Audience

Our intended audience includes:

· ITS project managers

· ITS project staff

· Contractors and their staff working on ITS projects

· Anyone else interested in applying configuration management, particularly on software-intensive systems

Our primary focus is on ITS project managers, but we hope to encourage others to learn more about this area. Configuration management is a key applied systems engineering practice, used to get systems built with maintainability and long-term health.

Origins of Configuration Management

Configuration management, as a systems engineering discipline, began in the 1950s, when the U.S. began developing tactical and strategic ballistic missiles. U.S. manufacturers found that they had difficulty in mass-producing missiles from their successful prototypes because they’d failed to record the contents of the successful configuration in an organized manner. ANA (Army, Navy, and Air Force) Bulletin 390 was the first configuration management guide. It formalized the process of making changes to a system under development so that the builders maintained an appropriate configuration record. Thus, once the DOD accepted a prototype for production use, the manufacturer could mass-produce the weapon. Over time, configuration management has become an accepted practice in the manufacturing and software development industries.

Current Configuration Management Standards

The two key broad configuration management standards are International Organization for Standardization (ISO) ISO 10007:1995, Quality management – Guidelines for configuration management and the American National Standard Institute (ANSI) and Electronic Industries Alliance (EIA) joint standard ANSI/EIA 649-1998, National Consensus Standard for Configuration Management. Both of these documents are equally applicable to hardware or software configuration management. The Institute of Electrical and Electronics Engineers (IEEE) also has a standard relating to configuration management, IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans, which is part of the IEEE’s software engineering standards.

The two general standards for configuration management provide guidance on how to employ configuration management on a project. The IEEE’s software engineering standard provides more specific guidance on what to do for software configuration management. A public sector project manager for an ITS project should look at the IEEE standard to see what a software development contractor should have in a software configuration management plan for a project.

Configuration Management Principles

Configuration management is defined as: “A management process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design and operational information throughout its life.”[1] Figure ES-1 illustrates how configuration management fits into the overall systems engineering process. What this figure shows is that configuration management pervades the systems engineering process, since it is a “best practice.” Table ES-1 is a checklist, taken from material[2] published by the Software Program Managers Network highlighting points that they believe are part of implementing configuration management as a “best practice.”

System Life Cycle Stage	Config Mgmt Planning	Config Identification	Config. Control	Config. Status Accounting	Config. Audits
Conception	√
Requirements Analysis		√	√	√
Design		√	√	√
Implementation		√	√	√
Integration & Testing			√	√	√
System Acceptance			√	√	√
Operation and Maintenance			√	√

Figure ES-1

Configuration Management in the System Life Cycle Stages

Configuration management involves five major areas:

• Configuration management planning – involves making decisions about what needs to be controlled within a product configuration, when you establish a controlled configuration, how you change a controlled configuration, and what amount of effort you’re going to expend to manage configurations, with the decisions formalized in a configuration management plan.

Table ES-1

Configuration Management Checklist

√ √ √ √ √ √ √ √ √ √ √ √ √ √

Is there a documented configuration management process for this project? Is the configuration management process integrated with the project plan and an integral part of the culture? What classes of information does your project control? What items are under control? How is the decision to control them made? Are all versions controlled? Are configuration control tools used for status accounting and configuration identification tracking? Are periodic reviews and audits in place to assess the effectiveness of the configuration management process? Are all pieces of information shared by two or more organizations placed under configuration management? Who on the project is responsible for change control of baselined and non‑baselined items? Do you have a configuration control board? If so, who are its members? Do you have a process for controlling non-product software that is shared? How does the developer make releases to the acquirer? How does the acquirer take delivery of items from the developer?

• Configuration identification – involves identifying the configuration items and the unique identifiers that you use to keep track of all items that need to be independently identified, stored, tested, reviewed, used, changed, delivered and/or maintained

• Configuration control – involves controlling what changes are made to the configuration baseline and when and how they are made.

• Configuration status accounting – involves keeping track of the state of all configuration items, all pending proposed changes, and all approved changes to configuration items.

• Configuration audits – involves ensuring that:

- The configuration item performs as its design and specification indicate that it should perform

- All configuration items for the system (or any of its subsystems) actually exist before the system (or subsystem) is accepted for testing or for production use

Configuration Management and ITS Systems

Configuration management’s purpose is to keep the physical implementation of a product consistent with the documentation that describes how to build it and what it is supposed to do. By keeping the product and all its associated documentation synchronized throughout the development cycle, manufacturers reach the production stage of a product life cycle ready to begin mass-producing it. Thus, it has value for mass-produced items. Why does it also have value for “products,” such as ITS systems, that aren’t mass-produced?

Some authors describe configuration management’s value in the design and implementation of ITS systems when “we start to invest significant resources in hardware and software development so further changes in requirements … start to get very costly in terms of budget and implementation time.” This recognizes the value of good requirements to quality ITS system development. Managing changes to requirements is essential to minimizing cost and schedule overruns on ITS projects. Even if there were no other use for configuration management on an ITS project, its ability to control changes to requirements would be reason enough to employ it. Smith and Smith[3] provide testimonials on configuration management from several respondents and describe configuration management’s use in a DOT’s system, as a systems engineering tool.

Configuration Management Costs

Configuration management doesn’t come free. One cost associated with it is the cost of the configuration management system itself. The configuration management systems market place changes frequently. The International Council on Systems Engineering (INCOSE) tries to keep current on all systems engineering tools available to practitioners and has a website (http://www.incose.org/tools/tooltax/cm_tools.html) that attempts to keep a current and accurate database of available products.

Another important cost is that of administering the configuration management system itself. The contractor on an ITS project may handle the project’s configuration management responsibility, but the public sector project manager must plan for this and incorporate these costs into his or her initial budget submission. When the project is over, however, the configuration management responsibility for the ongoing system becomes the government’s. Configuration management is an ongoing need as the system evolves and requires maintenance over time. The public sector agency must integrate its ongoing configuration management needs into its organizational structure and make sure that its contractual agreement allows it to get the configuration management data that the contractor maintained.

What if You Don’t Use Configuration Management?

You can avoid the costs associated with configuration management by not bothering to employ it on your ITS projects. If you do, you’ll probably pay instead in costs for:

• Figuring out which system components to change when requirements change

• Re-doing an implementation because you implemented to meet requirements that had changed and you didn’t communicate that to all parties

• Losing productivity when you replace a component with a flawed new version and can’t quickly revert to a working state

• Replacing the wrong component because you couldn’t accurately determine which component needed replacing

In addition, there’s another potential cost. If you have a system that affects safety, configuration management can help you avoid mistakes that would endanger someone. For example, consider the consequences of fielding a new or upgraded collision detection radar with a subtle “bug” that fails to alert drivers about potential collisions when certain conditions of rain, fog, or snow occur. It might not be a problem; if the specific climatic conditions don’t occur where the vehicle is being operated. In areas where (and when) they do, it could lead to loss of life.

The reason that configuration management is included as a key systems engineering practice is simple. It works! It keeps you from incurring costs you need to incur. And, good systems engineers have learned, through practical experience, that it pays for itself many times over.

The lesson to learn is simple: Don’t pay the price later! Use configuration management.

Introduction

Purpose of This Document

This document is one in a series of monographs on systems engineering topics developed to help introduce this discipline to ITS project managers and their staff. The other documents in this series are:

• Developing Quality Intelligent Transportation Systems Through Systems Engineering, which is an overview of the entire systems engineering area

• Developing Functional Requirements for ITS Projects, which focuses on how to establish good requirements to drive an ITS project to its successful conclusion

• Understanding Software Development: A Primer for ITS Public Sector Managers, which introduces software development and its issues to public sector ITS managers who may have had little or no experience with software development

While none of these documents will turn the reader into an experienced practitioner in the area of systems engineering, they are intended to give their audience a sense of how the topic covered applies to Intelligent Transportation Systems (ITS).

This monograph covers the topic of Configuration Management. Although other monographs in this series discuss configuration management briefly, none goes into the topic at the same level as this one.

Intended Audience

Our intended audience includes:

· ITS project managers

· ITS project staff

· Contractors and their staff working on ITS projects

· Anyone else interested in applying configuration management, particularly on software-intensive systems

Although our primary focus is on ITS project managers, we hope our coverage of this topic encourages others to learn more about this important area. Configuration management is a k