Configuration Management for Transportation Management Systems:
A Primer

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 such, must either include well-developed, detailed procedures or refer to their locations in other documents. Following a general description of CM plans from EIA 649, this section provides implementation guidance and best transportation practices as examples of these recommendations.

A CM plan clearly describes how CM is accomplished and how consistency between a system's configuration and the configuration records is achieved and maintained. The CM plan is a central source of information for the CM program. Typical contents of a CM plan include items such as:

• Personnel
• Responsibilities
• Resources
• Training requirements
• Administrative meeting guidelines
• Definition of procedures
• Tools/tool use
• Organization configuration item (CI) activities
• Baselining
• Configuration control
• Configuration status accounting
• Naming conventions
• Audits and Reviews
• Subcontractor or vendor CM requirements

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.

Developing the CM Plan

Developing a CM plan is not a mysterious, magical process. Rather, it simply requires concerted effort and communication to ensure that the 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 in step 3.

The CM plan documents an agency's CM program. As the program progresses, the plan will need to change to reflect the changing 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.

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.