Configuration

Management for
Transportation
Management Systems:
A Primer

September 2003
 Notice
This document is disseminated under the sponsorship
of the Department of Transportation in the interest of
information exchange. The United States Government
assumes no liability for its contents or use thereof. This
report does not constitute a standard, specification, or
regulation.

The United States Government does not endorse

products or manufacturers. Trade and manufacturers’
names appear in this report only because they are
considered essential to the object of the document.
 Contents

INTRODUCTION.................................................................................................................. 1
Purpose of CM ............................................................................................................. 1
Benefits of CM.............................................................................................................. 2
CM OVERVIEW ................................................................................................................... 3
CM Process .................................................................................................................. 3
Configuration Identification .......................................................................................... 4
Change Management/Change Control........................................................................ 4
Configuration Status Accounting ................................................................................. 5
Configuration Audits..................................................................................................... 5
CM Implementation ...................................................................................................... 6
CM Administration........................................................................................................ 6
CM PLAN.............................................................................................................................. 7
Developing the CM Plan .............................................................................................. 8
Successful Practices .................................................................................................... 9
CM BASELINE ................................................................................................................... 10
Baselines in the System Life Cycle............................................................................ 10
Baseline Elements ..................................................................................................... 11
Successful Practices .................................................................................................. 11
CURRENT PRACTICES .................................................................................................... 12
TMS Characteristics................................................................................................... 12
Benefits/Costs of CM ................................................................................................. 13
CM Benefit Testimonials ............................................................................................ 13
CM TOOLS AND TRAINING ............................................................................................. 14
Issue Tracking Tools .................................................................................................. 14
Document Management Tools................................................................................... 14
Process-Based CM Tools .......................................................................................... 14
CM and Version Control Tools................................................................................... 15
Merging Tools............................................................................................................. 15
Building Software ....................................................................................................... 15
Programming Environments with Versioning ............................................................ 15
Infrastructure Relationship Management Tools......................................................... 16
Awareness Level Training.......................................................................................... 16
Targeted Training....................................................................................................... 16
IMPLEMENTATION GUIDANCE ....................................................................................... 17
Configuration Identification ........................................................................................ 17
Change Control .......................................................................................................... 17
Configuration Status Accounting ............................................................................... 18
Configuration Audits................................................................................................... 18
CM Planning............................................................................................................... 18
CM Baselines ............................................................................................................. 19
Establishing a CM Program ...................................................................................... 19
CM Administration...................................................................................................... 19
CM Manager............................................................................................................... 19
Personnel ................................................................................................................... 20
Budgeting Considerations.......................................................................................... 20
System Life Cycle ...................................................................................................... 20
CM Tools .................................................................................................................... 20
CM Training................................................................................................................ 21
ADDITIONAL RESOURCES AND TRAINING .................................................................. 22
SUMMARY GUIDANCE PRINCIPALS .............................................................................. 23

i
 Introduction

Configuration Management (CM) describes a series of processes and

procedures developed in the information technology community to
establish and maintain system integrity. It is an integral part of the
systems engineering process. While some of the terms used in CM may “Configuration
be unfamiliar to transportation professionals, the core concepts and Management, applied
practices of CM are not technically complex. Rather, they represent sound over the life cycle of a
practices in developing and maintaining any system. As you will see in this system, provides
document, CM makes sense for use in transportation management visibility and control of
systems (TMSs). its performance,
functional and physical
The purpose of this primer is to identify for a non-technical audience the attributes. …
key aspects, identify issues for their agencies to consider, identify the
benefits or value, profile successful practices, describe why and identify - EIA Standard 649
opportunities how agencies may benefit from and why they should
consider or using various configuration management procedures,
techniques, tools, or requirements into their policies, programs, and day-
to-day activities.
There are two fundamental purposes of CM – to establish system integrity Purpose
and to maintain system integrity. To an individual who designs, develops,
operates, or maintains complex TMSs, the definition of integrity is well of CM
understood:
► A system with integrity is one in which all components are well
defined and documented.
► A system with integrity is one in which a working baseline is
always available to implement and provide transportation
management services.
► A system with integrity is one that can be readily integrated with
other regional intelligent transportation systems (ITS).
► A system with integrity is one with a high degree of traceability –
allowing one to easily identify how system functions are provided
technically.
The importance of CM in establishing and maintaining a functionally
sound TMS cannot be overstated. However, CM can consume significant
amounts of resources including staff time and money. For this reason,
developing a CM program that fits the needs of a particular system is vital
to its success. In other words, CM programs are not one-size-fits-all
entities. Some may think that CM is too large an undertaking to be worth
it for his or her system or that the agency cannot possibly implement such
a program. Although CM, and its complexity, can and should grow as a
system grows, it does not need to include each and every item described
in this document.

1
 Configuration Management Primer

As TMSs are becoming more sophisticated through the addition of new

Benefits subsystems, integration with other systems, and overall physical
expansion, the need to control the rapid pace of change has become
of CM apparent. One problem that has been discovered as these systems
change is that groups within an agency often work independently of each
other, conducting changes without consulting one another and
documenting the changes improperly. If the entire system is to undergo a
major change or upgrade, this can present a significant problem.
Contractors or agency personnel often will have to devote significant effort
to retracing the steps taken for minor changes to the system to
understand the current status. Doing so obviously requires major outlays
of time and money.
A CM Program Will Ensure: A proper CM program will ensure that documentation (requirements,
design, test, and acceptance documentation) for items is accurate and
Documentation is accurate
consistent with the actual physical design of the item. In many cases,
and consistent with the
without CM, the documentation exists but is not consistent with the item
actual physical design of
itself. For this reason, contractors and agency staff will frequently be
the item.
forced to develop documentation reflecting the actual status of the item
An accurate, up-to-date before they can proceed with a change. This “reverse-engineering”
baseline of the system process is wasteful in terms of human and other resources and can be
exists, if needed for minimized or eliminated using CM.
disaster recovery.
Some of the other benefits of CM, which hopefully will never be needed,
Administration of change are its provisions for disaster recovery. Because a CM program should
decisions are handled with ensure that an accurate, up-to-date baseline of the system exists, the re-
a system-wide perspective engineering process should be far less costly. Without CM and the
in mind. associated baselining process, entire subsystems would require redesign
Requirements are tracked at a much higher cost, and the recovery process would be greatly
throughout the life cycle lengthened, if even feasible.
creating an accurate record CM also provides for administration of change decisions with a system-
of the status of the system. wide perspective in mind. The configuration control board (CCB) has
personnel with various areas of focus and from various departments within
an agency. All proposed changes to the system are considered by the
CCB in terms of the system, not just particular subsystems. Using tracking
tools, unapproved changes can be detected and fixed more easily.
In cases of subsystem or system development, CM allows TMS
management to track requirements throughout the life cycle through
acceptance and operations and maintenance. As changes are inevitably
made to the requirements and design, they must be approved and
documented, creating an accurate record of the status of the system. The
CM process may be (and ideally should be) applied throughout the system
life cycle. Over time, CM will reduce operating and maintenance costs,
while improving system performance and reliability.

2
 CM Overview

CM is the practice of handling changes systematically so that a system

maintains its integrity over time. CM involves the policies, procedures,
techniques, and tools to: manage, evaluate proposed changes, track the
status of changes, and to maintain an inventory of system and support
documents as the system changes. CM programs and plans provide the
technical and administrative direction to the development and
implementation the procedures, functions, services, tools, processes, and
resources that are required for successful development and support of a
traffic management center (TMC).
In cases of subsystem or system development, CM allows TMS
management to track requirements throughout the life cycle through
acceptance and operations and maintenance. As changes are inevitably
made to the requirements and design, they must be approved and
documented, creating an accurate record of the status of the system. The
CM process may be (and ideally should be) applied throughout the system
life cycle.
The general CM process is described graphically in figure 1. While not
shown in figure 1, a CM plan is integral to the process. The CM plan is the CM
document that will guide the CM program of a particular group. Plans Process
typically are established at the outset of the CM program and undergo
changes as the system evolves and as areas where the plan can be
improved are identified. Contractors, in conjunction with the particular
agency that will be using the CM program, often develop the plans. The
benefit of the CM plan is that it provides a central location for all CM
program information.

Configuration
Management

Configuration
Configuration Change
Status
Identification Management
Accounting
Define the product and Control changes to a Product Provide status and
its configuration and its configuration information about a product
documentation documentation and its configuration
Identification documentation

Configuration
Audits
Verify consistency of
configuration documentation
against the product

Figure 1 Configuration Management Process 3

Configuration Management Primer

Configuration identification refers to the activities and processes dedicated

Configuration to creating and maintaining full documentation describing configuration
Identification items. The goal of configuration identification is to provide a unique
identifier for each item to help track the changes to that item and to be
able to understand its place in the system. Often, identification involves
recording the identifier, maintenance history, relevant documents and
other information that will simplify the change process in the future.
Configuration identification may be defined as anything that has a function
in the TMS. Therefore, system components classified in the broad
categories of software, cabling, and hardware are considered as
configuration items, in addition to system requirement and design
documentation.
Configuration identification includes processes such as item naming,
drawing and document management, information management and
baselining. Configuration identification is the first and possibly most time-
consuming process in CM, and if done correctly, will result in significant
long-term benefits. The items selected for configuration identification
depend upon the scope of the effort. For example, configuration
identification may be constrained to software items or may be larger and
include system level components ranging from software, hardware,
firmware, documentation, and perhaps the CM plan. The plan serves as
the primary resource for any questions pertaining to the CM program. The
benefits of configuration identification are to provide a means of unique
identification of system components to support traceability and change
management processes. Proper identification minimizes confusion over
various versions of configuration items and facilitates the change control
process by allowing items to be more easily tracked as they undergo
change.

Change management, or change control, is the process of assessing the

Change impact of a possible change to a system, determining the fate of the
Management/ proposed change, executing the approved changes, and ensuring that the
change is carried through to the proper documentation. Usually, a change
Change Control is proposed by someone who is working with the particular part of the
system that will be changed. Change requests are submitted to the
relevant administrative body for review. This body is normally referred to
as a change control board (CCB). The CCB will review the proposed
change, determine its effect on the overall system and decide whether or
not to proceed with it. An important part of change control is ensuring that
the change itself is documented and that the relevant configuration item’s
(CI) documentation now reflects that change.

4
 CM Overview

The primary benefit of an effective change control procedure is that

proposed changes are evaluated in terms of their impact on the entire
system. Change control allows the changes to be reviewed by personnel
with a variety of interests and areas of specialty. This minimizes the
negative impacts of changes on other components of the system. Change
control also ensures that the changes are properly implemented and
within schedule and cost constraints.

Configuration status accounting (CSA) is the process of ensuring that all Configuration
of the relevant information about an item – documentation and change
history – is up to date and as detailed as necessary. A primary goal of Status
CSA is to repose CI information necessary to support existing and future Accounting
change control efforts. A typical CSA system involves establishing and
maintaining documentation for the entire life cycle of an object. Status
Accounting is ideally carried out in conjunction with change control.
The primary benefit of CSA is that it provides a methodology for updating
all relevant documentation to ensure that the most current configuration is
reflected in the configuration identification database. CSA accounts for
the current status of all proposed and approved changes. The goal of
CSA is to provide decision makers with the most up-to-date information
possible. Having the most recent information about a CI or changes
implemented for a CI helps to reduce research efforts in future change
control activities whether implementing a new change or rolling back a
change that had a negative or unexpected impact.

Configuration verification and audit is the process of analyzing Configuration

configuration items and their respective documentation to ensure that the
documentation reflects the current situation. Essentially, while change Audits
control ensures that change is being carried out in adherence with the CM
plan, configuration audits ensure that the change was appropriately
carried out. The most important goal of this process is to prevent lost time
on future changes due to inaccurate documentation. If discrepancies are
located between the documentation and the item, the personnel carrying
out the audit will prescribe a course of action for remedying the problem.
The most important benefits of configuration audits are that they verify that
changes were carried out as approved by the relevant administrative body
and that documentation about an item reflects the current configuration.
By ensuring that changes are properly executed and all documentation is
updated, configuration audits will facilitate future changes to the system.

5
Configuration Management Primer

As with any new initiative, a CM program must have a champion to

CM spearhead its initiation. Sometimes, the champion faces a difficult battle,
Implementation particularly due to cultural resistance within the agency. CM often is
viewed as an expensive bureaucratic process with benefits that are hard
to quantify. For this reason, the champion must educate decision makers
and system staff on what CM is, and isn’t, as well as describe the benefits
of CM in a tangible manner. The champion must also secure funds or
staff time to use in creating a CM plan for the program.
Once initial buy-in has been established, the next step is to create a CM
plan. Depending on the complexity of the system, the plan may be
developed in-house or by a consultant. Regardless of the developer, the
agency must be actively involved in the entire plan development process.
Once the plan is developed, the blueprint is in place to drive the program.
The champion must make it clear to decision makers that the creation of
the plan is but the fist step in the program. Committing to CM means a
long-term staff, budget and procedural commitment.

CM The success of CM is solely dependent on how well an agency organizes

itself to institute the required policies and processes. Depending on the
Administration size of the system and complexity of the CM program, the CM
administration may be comprised of a large or small group of individuals.
Regardless of the administration’s size, the roles of each individual within
the CM administration must be well understood. The CM plan should
specify the responsibilities of each person involved in the CM decision-
making process. In order for the CM program to be as effective as
possible, it is ideal to include personnel from across the spectrum of
departments, such as planning, management, technical/design,
operations and maintenance, and financial. Doing so ensures that no
areas are overlooked during the application of the CM program and
reduces the chances of the CM activities of one group overlapping or
conflicting with those of another.
Additionally, effective CM administration starts at the top. The TMS
facility/system manager must play an active role in the CM program. In
most cases this individual serves on the CCB and, in some cases, serves
as the CM manager. In all cases, the TMS facility/system manager must
fully support the program and become involved on critical change
decisions.

6
 CM Plan

The CM plan is the defining guidebook for a CM program. It defines all of

the procedures, organizational responsibilities, and tools to be used within
the CM process. The plan is the backbone of a CM program, and as Key Benefits of Creating a
such, must either include well-developed, detailed procedures or refer to CM Plan Include:
their locations in other documents. Following a general description of CM Assurance that the
plans from EIA 649, this section provides implementation guidance and appropriate CM processes
best transportation practices as examples of these recommendations. are applied
A CM plan clearly describes how CM is accomplished and how Detailed descriptions of
consistency between a system’s configuration and the configuration responsibilities for CM
records is achieved and maintained. The CM plan is a central source of activities
information for the CM program. Typical contents of a CM plan include
items such as: Accurate knowledge
concerning required
Personnel Baselining resources
Responsibilities Configuration control
A foundation for continued
Resources Configuration status
improvement
Training requirements accounting
Administrative meeting Naming conventions - EIA Standard 649
guidelines Audits and Reviews
Definition of procedures Subcontractor or vendor CM
Tools/tool use requirements
Organization configuration
item (CI) activities
Development of an effective CM plan for a transportation agency is not a
turnkey job that can be completely handed over to a consultant. Although
most agencies surveyed for this publication have used a consultant to
support CM plan development, they agree that it is essential to have
agency staff actively involved with, or leading the development of, the plan
because agency staff has the best understanding of the system
functionality and change control needs.
Given the active role required of a transportation agency in plan
development, the next step is to become educated. Staff must
understand the principles and concepts of CM, and there are numerous
training opportunities available. For example, the National Highway
Institute (NHI) has a course entitled Configuration Management for
Transportation Management Systems (NHI Course No. 137042), which is
designed for individuals engaged with or responsible for the planning,
design, implementation, management, operation or maintenance of
transportation management systems. In addition, the Configuration
Management for Transportation Management Systems Handbook (FHWA
Publication No. FHWA-OP-04-013) may be used for educational
purposes.

7
 Configuration Management Primer

Developing Developing a CM plan is not a mysterious, magical process. Rather, it

simply requires concerted effort and communication to ensure that the
the CM Plan plan meets the needs of the TMS in question. This subsection
summarizes the steps recommended in the “CM Plans: The Beginning of
Your CM Solution” by Bounds and Dart.
Start with a standard. A number of good standards to guide CM plan
development are available. The Bounds and Dart document includes a
comparison of some of the more popular plans. In particular, the IEEE
Standard for Software Configuration Management Plans (IEEE Std 828-
1990) is recommended.
Create a template. Create a template/outline for the plan, which will guide
deliberations in next steps.
Develop CM procedures. Develop the various procedures that the
organization will follow in the CM program using the template as a guide.
Doing so is by far the most difficult step in the process. It also will require
involvement of individuals with expertise in the TMS as well as CM.
Essentially, the team must study various procedures to find ones that will
work for the agency.
Document. Document the procedures and other plan material developed
Experienced CM in step 3.
professionals note that
it is best to start out The CM plan documents an agency’s CM program. As the program
small and address the progresses, the plan will need to change to reflect the changing
essentials. environment. In addition, as a transportation agency gains experience in
CM, this experience will dictate changes to the plan. A one CM official
stated, “The old adage ‘We don’t know what we don’t know’ applies to
CM. Most agencies have little or no experience and will find that their
original plan will require multiple changes and modifications once put into
effect. Experience will determine what works and what does not work for
a given agency or situation.” Clearly, the CM plan subsequently will
change throughout the system’s life cycle. For this reason the CM plan is
subject to change control and should be treated as any other component
of the TMS.
A common mistake of individuals just getting involved in CM is to attempt
to develop an overly complex, comprehensive CM plan, which addresses
every possible situation in a system changing through time. Experienced
CM professionals note that it is best to start out small and address the
essentials. The following page presents two examples of successful
practices employed by transportation agencies in determining which items
to include.

8
 CM Plan

Successful Practice - Maryland CHART II System

The Maryland Coordinated Highways Action Response Team (CHART) II plan states, “the goal in
selecting CIs is to provide meaningful management visibility and tracking.” The plan also details the
need for determining the overall structure of the system in order to determine the correct level of
configuration identification. The plan states, “defining configuration identification at too low a level
results in over-control of system development and overly complex and costly CM. On the other hand,
identifying CIs at too high a level reduces management visibility into the project and can make progress
difficult to control, manage, and verify.”
After giving a general description of how to determine a CI, the plan goes on to detail the five major
categories of CIs. Since the CM system only covers the software used in the CHART system, all items
are categories of software, documentation, or related hardware (workstations, servers, etc.), but not
hardware that is deployed in the field.

Successful Practice - Southern California Priority Corridor

The Southern California Priority Corridor (SCPC) CM initiative also has a policy regarding configuration
identification. The plan states that CIs are “aggregations of deliverable documents, software products,
and hardware.” The plan also includes selection criteria that state that potential CIs should be
evaluated on the basis of their impact on other projects, number of potential deployments, and impact
on system consistency. Similar to the Maryland CHART II plan, a list of general categories that should
be included in CM is included, although individual items are not named. The following is an excerpt of
the CM plan, which lists the types of items that are to be maintained under configuration control:
► Developed software, firmware, and hardware.
► Supporting COTS software, firmware, and hardware.
► Project documents such as: Concepts of Operations, User and System Requirements, High Level
and Detailed Designs, etc.
► Development systems such as: development environments, tools, COTS software, build notes and
procedures, and all other information needed to fully develop the configuration item.
► Test systems such as: test environments, test plans, test software, procedures, simulators, tools,
test equipment, COTS software, and notes used to verify the configuration item against
requirements.
► Production systems such as: documentation, jigs, fixtures, “as built” drawings, bills of materials, and
all other information needed to reproduce the configuration item.
► Supporting documentation such as: User’s manuals, operational guides, training materials used to
train users on the operation of the configuration item.
► Process artifact data such as: traceability matrix, requirements attributes technical review notes,
etc.

9
 CM Baseline

The concept of a baseline is not new or complex. In general, a

The concept of baseline
baseline is a well-defined, well-documented reference that serves as
is central in configuration
the foundation for other activities. For configuration management a
management. In order to
baseline is a stable, well-documented, and thoroughly tested version
effectively implement a
of the system at some point in its life cycle. For this reason, all CM
configuration activities should ensure that changes to a baseline are carefully
management program in
considered and documented so that future baselines are solid.
a transportation
management system, one Transportation management systems do not have simply a single
must fully understand baseline. If fact, during the life cycle of the system, multiple baselines
baselines. will be established and maintained. Example system baselines for
different points of a typical system life cycle are provided below.

Baselines in the System Life Cycle

► Concept of Operations Baseline – This baseline is established at the conclusion of the system
conception stage. In most cases, it may be considered the formal concept of operations document
developed for the system. Note that the intention of this baseline is to clearly establish the basic
requirements that the system will fulfill.
► System Baseline – This baseline may be considered to be the final functional requirements
developed for the system. This is an excellent example of a change to a system baseline that
should be carefully controlled through the configuration management program. By establishing and
maintaining formal system baselines, project team members will not be able to add/delete
requirements without the full team (and usually the CCB) fully considering the ramifications.
► Subsystem Baseline - This intermediate baseline between the functional baseline and the
development baseline falls after the requirements are completed and preliminary design work has
established a mapping of high-level functions to system components.
► Development Baseline – This baseline may be considered to be the detailed design document
completed before system development begins. Once system development begins, there will be
significant pressure to change system design due to a myriad of reasons (desired new functionality,
changes in technology, impediments to development, etc.). It is essential to carefully control these
changes to design to maintain the integrity of the system.
► Product Baseline – This baseline essentially documents the “as-built” design that reflects the
completed system. The product baseline is the result of the series of changes that have been
made to the original developmental baseline during the system development process. Ideally, if the
developmental baseline is under configuration control, the product baseline will simply be the
evolution of the developmental baseline through the various system acceptance and verification
tests, as governed by the CCB.
► Operational Baseline – Given the constant pressure for change, transportation management
systems are truly “living” systems. In other words, the product baseline will change with time to
adapt to the necessary changes. During system operations, it is essential to maintain the
operational baseline to reflect changes that have been approved through the configuration
management process and implemented.

10
 CM Baseline

Some baselines purely involve documentation, while others include

software, hardware, and so forth. Typical baseline elements are: Baseline
► Documentation – This is an element of each and every baseline. Elements
In some cases, such as the functional baseline, documentation is
the entire baseline. In other cases, documentation supplements
other elements.
► Configuration items – Particularly in the case of software,
configuration items themselves should make up portions of the
product and operational baseline. For example, the source code
for the product baseline should be kept in conjunction with the
documentation.
► Change documentation – All documentation resulting from the
configuration management change control process should be
maintained as part of the appropriate baselines, which allows for
traceability in the change management process.
Below are two descriptions of agencies that use baselines in the
configuration management of their TMSs.

Successful Practice - Georgia NaviGAtor

The Georgia NaviGAtor CM manual states, “The baseline configuration is established at a point in time
when GDOT initiates formal control over documentation, drawings, and/or software.” Of the agencies
that were surveyed for this report, GDOT is the only agency whose plan details the time when a
baseline is to be established. After a set of plans has been given to the DOT for a certain project and
reviewed to see that all requirements have been met, the agency can baseline that set of plans. From
that point on, any changes made during construction should be subject to the change control process.

Successful Practice - Maryland CHART II System

The CHART II CM plan lists five major baselines that are to be included as part of the system life cycle.
Under this system, which treats baselines at a project level rather than at an individual item level, the
baselines consist of all relevant configuration items (documents, software, and other items). Similar to
the multiple, concurrent baselines outlined earlier, the CHART II plan stipulates that at any point the
project may be supporting multiple baselines. As an example, the plan says that Release 1/Build 2 may
be operational while Release1/Build 3 may be in development and Release 2/Build 1 may be in design.
As is standard with baselining procedures, CHART II baselines are modified using the change control
process.

11
Current Practices

A survey was conducted in the spring of 2000 to gauge the use of CM

TMS by transportation agencies in the United States.1 The results indicate
a need to educate the TMS community about CM in order to realize a
Characteristics significant commitment to this valuable resource-saving activity. The
survey also revealed that many of the complex TMSs in this country
are not using a formal change control process. This lack of formal
change control processes calls into question the very integrity of many
of these systems.
The first question of the survey
5 asked about the core functions
provided by the TMS. Respondents
2
Freeway were to check all that applied, and if
Management System a particular agency performed more
Traffic Signal System than one function, then the sample
20
size would increase accordingly.
Automatic Toll Counting each function
Collection System independently increased the sample
15 Tunnel Control size from 38 to 42. Figure 2
System
illustrates the percentage share of
the functional classes of systems.

Figure 2. Use of CM According to TMS Function

A key finding of the survey was that
80 a relatively low percentage of TMSs
80
70
75
use CM. What was particularly
70
75 notable is that only 27 percent of
60 67
Percent that use CM

60 67
Percent that use CM

50
signal control systems and 62
50 percent of freeway management
40
40 43 systems reported using CM.
30 43
30
20
20
10
Another clear trend in the survey
10 responses is that the likelihood of a
0
0 S m a ll (1 -9 9 la n e -m ile s)
S m a ll (1 -9 9 la n e -m ile s)
M e d iu m (1 0 0 -4 9 9 la n e -
M e d iu m (1 s0 )0 -4 9 9 la n e -
m ile
L a rg e (5 0 0 + la n e -m ile s )
L a rg e (5 0 0 + la n e -m ile s )
TMS using CM is dependent on the
m ile s )
S iz e o f F re e w a y M a n a g e m e n t S ys te m size of the system. Larger systems
S iz e o f F re e w a y M a n a g e m e n t S ys te m
are more likely to utilize CM, as
Figure 3. CM Use by System Size
illustrated in figure 3.

1
This survey was originally conducted for an NCHRP Synthesis project. The full
results of this project are published in NCHRP Synthesis 294 (2001).

12
 Current Practices

Most of the agencies responding to the survey reported that the Benefits/Costs
benefits gained from CM were well worth the costs required. Table 1
presents the average survey rating for a series of CM benefits. The
of CM
ratings were on a scale of 0 to 10, with zero representing no benefit
and 10 representing the highest level of benefit. Note that according
to the survey responses, the largest benefits of CM are seen in the
ability to maintain systems and in improved system reliability.

Table 1. Average Benefits Ratings for CM (Scale: 0 – 10)

System System Ability to Ability to Ability to Ability to

Reliability Maintainability Upgrade Expand Share Integrate
System System Information with Other
with Other Systems
Systems
7.8 8.3 7.5 7.4 5.8 5.7

Finally, when asked to rate if the overall benefits of CM were well

worth the costs, on a scale of 0 to 10 (with 10 being complete
agreement, and 0 being complete disagreement), 77 percent of the
agencies gave a rating of 7 or higher. Again, this strongly indicates
that of the relatively small percentage of agencies using CM, the
experience has been positive.

CM Benefit Testimonials
“With almost 20 years experience in the design, implementation, modification and expansion of our
system, the benefits of quickly being able to recover from problems by returning to an earlier working
state are enormous. Our system has been very dynamic, and there is always some area where we are
working on an improvement or upgrade, while still actively managing traffic.”
“As in any large, complex system, CM can provide a constant understanding of the current state of the
system…. The key factor in CM is having a central repository of information for reference as personnel
changes occur over the life of the system. It also is a great aid in maintaining the system when items
are replaced for repair. Technicians should have ready access to configuration data when installing or
re-installing standard system components.”
“A formal, documented configuration control process can save operational costs over the life of the
contract and mitigate the impact of personnel and equipment changes.”
- Comments obtained from Spring 2000 survey of transportation agencies

13
CM Tools and Training

Many of the currently available tools and training programs are

designed specifically for software development. Some, such as issue
tracking tools and document management tools, have relevance in a
wider range of CM applications, including TMS. When considering
the selection of a tool, an agency should consider its level of
“ownership” of the various TMS components. Lower levels of
ownership, as is the case for an agency that has purchased a license
for a commercial-off-the-shelf signal control package, often require
minimal tools for CM assistance. High levels of ownership, such as
when an agency has supported the development and maintenance of
a completely custom application, require full support from CM tools.
Furthermore, keep in mind that CM tools are merely tools, which often
require significant training of agency staff in order to realize their
benefits. Commonly used CM support tools are described below;
specific tools available on the market are not described because of
the rapidly changing industry.

Issue Tracking Issue tracking tools (ITTs) are among the most commonly used tools
for CM program support. These tools support decision makers in
Tools tracking changes as they progress from approval to completion. One
of the most important characteristics of these tools is that they provide
administrators the ability to assign changes to various personnel and
then track the changes.

Document Document management tools can be very supportive of CM

programs. With projects often having hundreds of documents in both
Management paper and electronic form, archiving these documents and making
Tools them easy to locate and access once archived is extremely important.
Software tools that accomplish this task have the potential to shorten
project length, save money, and prevent confusion for those involved
in the project.

Process-Based Process-based configuration management tools are intended to

facilitate the software development and modification processes.
CM Tools These tools act as a central location for all information regarding such
effort and seek to minimize confusion among participants about the
tasks that they are expected to achieve. Popular applications in this
field will document and log software modifications or additions to the
system to facilitate backtracking and increase knowledge of the total
process.

14
 CM Tools and Training

An important consideration in a CM program is that there will be more

than one version of many software applications—representing CM and Version
different baselines for these system elements at various stages of the Control Tools
system life cycle. Version control tools assist the user in resolving the
differences in the software applications relevant to their system.
Version control tools often prevent or manage concurrent access to
the same code files to facilitate concurrent development. Much like
merge tools discussed next, version control tools compare two
versions and then automatically present to the user a report detailing
the major differences, such as changes, additions, removals, moves,
and renames.

Merging tools are intended for software CM only. Merging tools are Merging Tools
software applications intended to facilitate the merging of multiple
sources of code into one final set of code. Merging tools are relevant
for use in TMS change control of custom-developed application
software. They aid the change control process by greatly reducing
physical examination of source code and allowing programmers to
more quickly establish new baselines.

As its name implies, building software is intended to aid in the process

of building software applications from a variety of components, and Building
thus is intended for software CM only. Building tools resolve or Software
highlight missing references, build projects in the correct hierarchical
order, maintain dependencies between multiple projects, and inform
each involved participant when a project has been added to or
removed from the application on which they are working.

Programming environment tools also is a software-specific CM tool.

Such tools can be very useful during software modifications across Programming
software platforms. They provide a consistent feel and functionality Environments
across heterogeneous systems and across diverse languages. The
major operations that can be carried out using a tool such as this are: with Versioning
design, coding, testing, debugging, and maintenance. Programming
environment tools can be invaluable to the change control process
and can eliminate redundancy, a major source of inefficiency.
Programming environments with versioning are among the most
common tools currently used by transportation agencies to manage
custom TMS software.

15
Configuration Management Primer

Infrastructure Infrastructure relationship management (IRM) tools constitute a

relatively new category of CM support resources. They are designed
Relationship to handle just about every facet of an information technology
Management infrastructure and are suited well for use on ITSs. These tools
minimize the effects of organizational change on a system by
Tools providing full documentation of items and their relationships to each
other, providing up-to-date baselines for disaster recovery, and
keeping accurate records of the changes to items and of the current
system configuration.

Awareness Level All management, design, development, and maintenance personnel

must receive awareness-level training to familiarize themselves with
Training the basics of CM before they are expected to become involved with
implementing the program. Note that management levels above
TMC management also should be included in the awareness training
given upper management’s role in resource allocation and project
determination and programming. Short, half- or full-day awareness-
level courses are recommended. In most cases, either internal
agency personnel with significant CM experience or CM consultants
would serve as good instructors for the course.

Targeted Personnel essential to the CM program, such as those serving on the

CCB or otherwise directly involved with recommending or making
Training changes require extensive, targeted training. Personnel requiring
targeted training are advised to take a weeklong seminar on CM,
which provides in-depth exposure to the processes and intricacies of
CM. The courses presently available for this level of training are
heavily software-oriented, but are the best choice until more general,
detailed CM courses become available.

While CM tools and are currently used within many TMSs, some
agencies are reluctant to invest in these products. Some of the
reasons that were cited for the hesitance to accept tools include cost,
fear of increased staff workload, need for lengthy training, and the fact
that many of the organizations would need to use only a small portion
of a tool’s capabilities.

16
 Implementation Guidance

The following implementation guidance summaries distill all the

information and recommendations provided earlier into a small
number of essential guiding principles of a CM program. They
combine information found in technical literature and standards with
interviews of transportation professionals experienced with
configuration management. The summaries are designed to help
transportation officials apply these principals to TMSs.

► A CM manager should determine the agency’s level of Configuration

configuration identification (part, subassembly, assembly, unit,
group, set, subsystem, system) based on the complexity of its Identification
system and the anticipated frequency of change.
► A tool, which can be anything from an extensive database to a
spreadsheet, is the best way to keep track of configuration item
information.
► For software, a tool that allows code to be checked in and out is
essential to maintaining system integrity.
► Having a centralized authority, which determines configuration
items and the necessary information to collect on each leads to a
more standardized and accountable system.

► CCBs should be established to make decisions regarding Change Control

changes to the system.
► The CCB should have personnel from various departments and
areas of expertise so that proposed changes may be reviewed
from many perspectives.
► Agencies should use a formal change control procedure to ensure
consistency and acceptance.
► After a change report is submitted, a CCB member or designated
staff member should acquire and distribute the necessary
information regarding the effects of the proposed change before
the CCB meets.
► Tools should be used to help personnel keep track of changes in
an efficient manner.

17
Configuration Management Primer

Configuration ► All changes should be recorded with detailed information, which

can be used to determine whether the change was implemented
Status according to design.
Accounting ► A robust software tool should be used in carrying out all CSA
activities. CSA should highlight any differences between a
proposed change and the change as implemented.
► CSA reports should be used to assess the current status of a
system.

Configuration ► The appropriate personnel as chosen by the CCB should conduct

configuration audits on a regular basis in order to ensure that the
Audits adopted CM policies are being used.
► The auditor is responsible for documenting the findings and
initiating the necessary changes.
► Audits should be conducted in a standardized environment, which
describes the auditor’s responsibilities and supporting paperwork.

CM Planning ► A CM program requires a CM plan.

► The development of a CM plan must include the active
involvement of TMS agency staff.
► Use the following document to guide plan development: CM
Plans: The Beginning of your CM Solution (Bounds and Dart,
2001).
► Use a standard to guide development. Recommended: the IEEE
Standard for Software Configuration Management Plans (IEEE
Std 828-1990).
► Put the majority of the effort into crafting CM procedures that work
for the agency and TMS.
► Start small – be sure to include essential elements and do not
seek to address every possible system change scenario.
► Put the CM plan under CM control.

18
 Implementation Guidance

► Keep formal baselines throughout the system life cycle. CM Baselines

► The establishment and maintenance of baselines begins at the
concept of operations stage.
► Require contractors and consultants to deliver baselines as
appropriate for the life cycle stage of the system.
► Above all else, concentrate on maintaining complete, up-to-date
documentation in baselines.

► A CM champion is needed.
► Ideally, incorporate CM during the requirements and development
Establishing a
phases. CM Program
► CM program begins with educating decision makers and staff on the
realities of CM and the benefits of a CM program.
► Be sure all involved understand that CM is an ongoing program, not a
short-term project.

► The TMS system/facility manager must play an active role in CM CM

administration. Administration
► The roles of all personnel must be clearly defined and the
relationships among them must be understood.
► The CM plan should clearly state specific tasks and requirements of
all personnel involved in CM administration.
► The personnel involved in the administration of a CM program must
have a variety of focus areas including: management, planning,
financial, and technical.

► A CM manager, employed by the transportation agency, must be CM Manager

formally established to lead the CM program.
► The CM manager will be the chair of the CCB.
► The CM manager should be an individual with an appreciation for
technical considerations and who has a sound understanding of
personnel, operations, and budgeting issues within the TMS.

19
Configuration Management Primer

Personnel ► Consider basic Knowledge, Skills and Abilities (KSAs) needed when
selecting any staff member to be involved in CM program.
► CM manager must have strong TMS experience. CM experience is
preferable, but in-depth training can be used as a substitute.
► CM facilitator must have experience with CM programs.
► Consider requiring the CM facilitator to be CMII Certified.

Budgeting ► Expect CM planning to require between 1 – 12 person months of

effort.
Considerations ► Annual costs of a CM program are generally 5 – 8 percent of initial
system cost.
► Ongoing CM costs include staff time, consultant support, tool
purchase/maintenance fees, and training.

System Life ► Configuration management should begin at the concept of operations

stage of system development.
Cycle ► Require consultants and contractors to deliver products that meet the
requirements set forth in the configuration management plan
► Agencies that have started late should not try to “catch up.” Simply
begin applying configuration management as appropriate for the
system’s life cycle stage.
► It is rarely too late to implement CM and reap the benefits.

CM Tools ► An agency should carefully consider its level of system “ownership.”

Systems that require minimal CM activities do not warrant the
purchase of high-end tools.
► Agencies should survey currently available tools. The INCOSE Web
site provides a convenient place to begin this effort: (www.incose.org)
► Key issues to consider when choosing a CM tool include:
ƒ how many seats (licensed users) will need to be supported.
ƒ the need for a high skill level to effectively use tools. (PLANET
estimates that it takes 6-12 months to become proficient with their
software.)
ƒ including the use of the tool and the purchase of the tool in
operations and maintenance contracts.

20
 Implementation Guidance

► An agency should expect to spend 10 to15 percent of original

software cost on annual tool maintenance fees.
► The case study of GDOT presented in the next section provides
excellent guidance on the process an agency should follow in
choosing a tool for a particular CM program.

► Provide awareness-level training for all staff involved in CM. CM Training

► Provide targeted training for key staff with essential CM
responsibilities.
► The CM manager should lead the training program.
► Training must continue as the CM program continues.

21
Additional Resources and Training

The handbook entitled Configuration Management for Transportation

Management Systems is intended to provide guidance for transportation
professionals that are responsible for developing and maintaining complex
Intelligent Transportation Systems (ITS) and TMS. The handbook
expands on the information presented here, by detailing the various
aspects and components of CM.
The documents listed below and additional training materials are available
on the TMC Pooled-Fund Study website at
http://tmcpfs.ops.fhwa.dot.gov/.
► CM for TMS Handbook, FHWA-0P-04-013, EDL# 13885
► CM for TMS Brochure, FHWA-OP-04-016, EDL# 13888
► CM for TMS Fact Sheet, FHWA-OP-04-017, EDL# 13889
► CM for TMS, NHI Training Course No. 137042, FHWA-NHI-03-119

22
 Configuration Management for Transportation Management Systems
Summary Guiding Principals

1. Identify the context and environment in which CM is to be implemented and develop an

appropriate CM plan accordingly.
2. Define procedures describing how each CM process will be accomplished.
3. Conduct training so that all responsible individuals understand their roles and
responsibilities and the procedures for implementing configuration management
process.
4. All items are assigned unique identifiers so that one item can be distinguished from
other items.
5. Configuration documentation defines the functional, performance, and physical
attributes of a system.
6. A baseline identifies an agreed-to-description of the attributes of an item at a point in
time and provides a known configuration to which changes are addressed.
7. Each change is uniquely identified.
8. Consider the technical, support, schedule, and cost impacts of a requested change
before making a judgment as the whether or not it should be approved for
implementation and incorporation in the item and its documentation.
9. Implement a change in accordance with documented direction approved by the
appropriate level of authority
 "Configuration Management, applied over the life cycle of a
system, provides visibility and control of its performance,
functional and physical attributes. Configuration Management
verifies that a system performs as intended, and is identified
and documented in sufficient detail to support its projected life
life
cycle."

EIA Standard 649

Configuration Management for

Transportation Management Systems

Federal Highway Administration

U.S. Department of Transportation
400 7th Street, S.W. (HOP)
Washington, DC 20590
Toll-
Toll-Free ì Help Lineî 866-
866-367-
367-7487
www.ops.fhwa.dot.gov

Publication No.: FHWA-

FHWA-OP-
OP- 04-
04-014
EDL Document No.: 13886

NHI Training Course No. 137042

Configuration Management for Transportation Management Systems
Publication No.: FHWA-
FHWA-NHI-
NHI- 03-
03-119