Chapter 3 – Configuration Management Processes

Introduction

This chapter provides detailed information on how to "do" configuration management. It covers the major components of the formal CM process including:

  • CM planning.
  • Configuration identification.
  • Change control.
  • Configuration status accounting.
  • Configuration audits.

In each section, EIA 649 is used to explain the particular CM process. This is followed by implementation guidance designed to help transportation professionals apply EIA 649 principles to TMSs. Finally, examples of effective current CM transportation practices are described.

Configuration Management Planning

One of the most important processes involved in the CM program is CM planning. Because the plan serves as the foundation for all other CM activities, it is essential that the plan receive significant thought and effort.

The CM plan typically addresses all items concerning the CM program, including:

  • Personnel.
  • Administrative bodies.
  • Activities.
  • Items under CM.
  • Policies.
  • CM tool descriptions.

Because of the critical importance of CM planning, an entire chapter (chapter 4) in this handbook has been devoted to the topic.

Configuration Identification

Configuration identification refers to the activities and processes dedicated to creating and maintaining full documentation describing configuration items. A CI 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.

EIA Standard 649 Definition

"Configuration identification is the basis from which the configuration of [items] are defined and verified; [items] and documents are labeled; changes are managed; and accountability is maintained."

As stated in EIA 649, the purpose of configuration identification is to document each item in such a way that its operation, functionality, capabilities, and configuration are fully described. Also, specific to hardware, it is important to document location, maintenance, and warranty information.

After determining what information about each item needs to be documented, the next step of configuration identification is to determine the overall structure of the documentation system. EIA 649 recommends that the CM manager begin documentation at high levels of functionality, which is usually a system of items, then document each item in that system, and continue until the lowest levels of functionality are documented. A simple example of this is to consider a variable message sign system. The system has a high level of functionality. After its information is documented, then the signs, software, and other hardware that are integral to the system should be documented as well.

Another step of configuration identification is configuration item identification, which defines how the items should be named. Obviously, the naming system should be consistent, and it should allow users of the system simple access to the documentation about each item. Some DOTs have come up with a system for naming that is independent of many standards. Georgia DOT, for example, has a system in which all items have the same prefix, followed by a number that identifies the item as a document, software, hardware, and so forth, which is then followed by a unique number from 1-999. The system's simple nomenclature serves the state's needs according to the CM manager.

Implementation Guidance

There are many important points to consider when developing a system for configuration identification. Successfully implementing such a system is essential to serve as a foundation to support system maintenance and change control. System managers may want to develop their own identification systems based on the needs of their personnel and the complexities of the involved systems. One of the professionals who was interviewed during the development of this report stated that there is no such thing as too much information for a configuration item. All of the information may be useful at some point during the system's life cycle, but limited memory or limited time available for data entry may place restrictions on this approach. It therefore becomes necessary for the CM manager to determine what information is critical for an agency's daily operation.

Level of Configuration Identification – Software

Software configuration management can best be considered in two broad categories: custom and commercial-off-the-shelf (COTS). Custom software refers to applications developed specifically for a TMS. In this case, generally the TMS receives both source code and executable code corresponding to the application. Source code is the English "readable" code statements, written by programmers and stored in individual files. This is the original composition of software before compilation into object code, also known as executable code, which drives or runs a particular application in a computer system. The executable code is the complete program, which is intended to run on an agency's computer. COTS software, on the other hand, is generally only provided to an agency in executable form. In this case, the software is used by many organizations, and the TMS simply maintains a license allowing their use.

For both custom and COTS software, the information items to include in configuration identification are similar. These items include:

  • Item's unique identifier.
  • Storage location.
  • Required hardware and operating system.
  • Associated directories and libraries.
  • Version number.
  • Updates.

The level of detail, however, is different between COTS and custom software. For COTS software transportation agencies usually record the above information for an entire functional application, because the agency generally cannot change one portion of the application. Changes are restricted generally to updates and new versions of the COTS software. For custom software an agency establish and document configuration items down to the level of software modules because custom software allows the user to modify a single module within the application.

Level of Configuration Identification – Hardware

When establishing and maintaining configuration identification for hardware elements of a TMS, it is important to consider at what level the hardware items will be controlled. Suggested levels for hardware documentation are listed and described in figure 3.1. A DOT's identification requirements may vary depending on such things as its ability to maintain items, expected growth, and functionality. As stated in A Guide to Configuration Management for Intelligent Transportation Systems, the parts, subassembly, assembly, and unit levels of configuration control are the only ones appropriate to managing an ITS system. If an agency plans on recording the model number of an item, it would be controlling at the assembly level. At this level when the item fails, it is replaced. At the subassembly and parts levels, the item is tested to see what part of it failed, and then that part or parts is fixed. At the unit level an entire functional group is treated as the same item. Although this would require a lot less information to be stored, replacing an entire traffic signal cabinet when one item fails is clearly unreasonable. The majority of states surveyed control their configuration at the assembly level, since most of their system components are purchased from third parties. It is therefore suggested that agencies use the assembly level to achieve hardware configuration identification.

Figure 3.1 – Levels of Hardware Configuration Identification
* "A Guide to Configuration Management for Intelligent Transportation Systems", Mitretek – 04/2000 (p. 5)

Tool Use

The complexities of keeping detailed records for all of the CIs raise the issue of tool use for configuration identification. Many transportation agencies utilize software tools that are designed specifically for CM to manage their CIs. For identification purposes, these programs usually include large databases in which the information about the configuration items may be stored and modified. Other organizations, with less complex CM programs, use relatively simple spreadsheets to keep track of their CIs. As system complexity increases and the number of CIs increases, the need for a robust CM tool emerges.

Baselining

A baseline consists of all documentation on items that are under change control, the items themselves, and all approved changes that are being made to the system. The importance of establishing baselines cannot be emphasized enough when discussing configuration identification. Because of the frequent changes that occur to a TMS, it is important that hardware, software, and documentation are regularly baselined, using a standardized procedure to identify all of the changes that have taken place.

According to agencies that provided information for this report, baselining saves tremendous amounts of time because it tends to minimize redundancy and the need to retrace steps. Baselining is essential in software development environments. Many agencies have systems that allow software developers to "check out" versions of the object code for enhancements. Instead of being checked back in with the same identification, it receives new identification and is considered the new baseline for this piece of software. A CM manager or committee should approve the new version before it receives its unique identifier and becomes the new baseline.

Consistency

In order to ensure effective configuration identification, consistency should be a primary concern. Specific persons or committees should be responsible for determining CIs and the information that is to be recorded. Proceeding in this manner means that standardized formats are used for identification and the end users has a consistent format with which to work. Having a person or persons in charge of configuration identification activities who consistently collects accurate information helps to provide the traceability of the decision-making process to the actual configuration. This allows the organization to know the rationale behind decisions so that one person or group does not make changes that conflict with another.

Implementation Guidance Summary

  • A CM manager should determine the agency's level of configuration identification (part, subassembly, assembly, unit, group, set, subsystem, system) based on the complexity of its 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.

Best Transportation Practices

This section presents a number of examples of configuration identification practices employed by transportation agencies.

Configuration Item Determination

CI determination is the first step of CM after the development of the plan. It is how a transportation agency determines what is going to be included in its change control and what is going to be left out of its baselining procedures. The first step that CM managers use in CI determination is the statement of purpose of the CM program from the DOT or agency that created the system.

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.

Richmond, VA Smart Traffic Center

The Richmond Smart Traffic Center (STC) CM plan takes a more comprehensive approach than does the Maryland CHART II plan. Instead of giving a guideline and then a general outline of the items that should be included under change control, the Richmond STC plan includes an appendix that "identifies the baseline software, firmware, documentation, and hardware that will be the responsibility of the CCB". Included as an appendix, this section lists all the CIs by name. Although the CCB has the authority to add new CIs to the list, it appears to be exhaustive and attempts to list all the items to be placed under baseline control. The following list is from an appendix included in the Richmond plan, which details all documentation under change control:

Documents Subject to Configuration Management Controls

  • System Requirements Specification, v1.7
  • Acceptance Test Plan, v1.0
  • Software Development Plan, v1.0
  • System Test Plan, v1.0
  • Database Design Document, Final-2
  • Build Document, Final-1
  • Computer Operator's Manual, Draft-3
  • Software Design Description of the CCTV, Final-1
  • Software Design Description of the Dialup Communications Component , Final-1
  • Software Design Description of the Event Logger Component, Final-1
  • Software Design Description of the Graphical User Interface Component, Final-1
  • Software Design Description of the HAR, Final-1
  • Software Design Description of the Incident Detection, Final-1
  • Software Design Description of the Incident Management, Final-1
  • Software Design Description of the Scheduler Component, Final-1
  • Software Design Description of the Security Service Component, Final-1
  • Software Design Description of the Serial Communications Component, Final-1
  • Software Design Description of the Socket Communications Component, Final-1
  • Software Design Description of the Transportation Sensor Station, Final-1
  • Software Design Description of the VMS Component, Final-1
  • Software Design Description of the VOIS Sender Component, Final-1
  • Software Design Description of the Web Mapper Component, Final-1
  • Software Design Description of the Work Zone Component, Final-1
  • System Test Description for CCTV, Draft 5
  • System Test Description for Condition Monitoring, Draft 5
  • System Test Description for Equipment Management, Draft 2
  • System Test Description for HAR, Draft 4
  • System Test Description for Incident Detection, Draft 4
  • System Test Description for Incident Management, Draft 4
  • System Test Description for Other, Draft 2
  • System Test Description for ITS Scheduler, Draft 4
  • System Test Description for VMS, Draft 5
  • System Test Description for Work Zone, Draft 4
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: users 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.
Georgia NaviGAtor

Georgia is unique in the area of CI determination because its CM program baselines field hardware, software, cabling, and documentation. The plan divides this group into three main categories: documents, drawings, and software and then further breaks those categories down to more specific subcategories, which are roughly at the same level as the Maryland and California systems. According to the CM manager, everything GDOT has in the way of ITS and IT equipment is being placed under baseline control. The manager for the NaviGAtor system is in charge of change control for all ITS equipment, and the IT equipment change control is handled by a separate GDOT agency. The NaviGAtor CM identifies all items that are currently deployed in field, as well as items that are part of inventory. The only equipment that interacts with the NaviGAtor system that is not considered a CI is equipment that is not owned by GDOT, but by outside agencies such as city and county municipalities.

Configuration Item Information

After determining what equipment falls under change control, it is important to determine the information needed to fully describe each category of items. When interviewed, some DOT personnel stated that an agency could never have too much information. Although this philosophy has its advantages, personnel and funding limitations certainly dictate a need to prioritize CI information. Thus, it is necessary for the CM manager to determine what information is critical for an agency's daily operation.

Richmond, VA Smart Traffic Center

The configuration manager of the Richmond STC stated that he maintains at least five important pieces of information on each configuration item:

  • All vendor documentation.
  • Directions on how to maintain and service equipment.
  • Design documents.
  • Hardware layout.
  • Purchase and installation date.

It should be noted that the Richmond STC does not maintain configuration item information on field devices—only on software and the related hardware (computers and communications gear).

Georgia NaviGAtor

The Georgia NaviGAtor program maintains information on all items related to its TMS, which includes hardware in the field and software. For field hardware the CM Manager maintains the following item information:

  • Location.
  • Identification number.
  • Description.
  • Make and model.

For software, each build requires three documents to be maintained:

  • User manual.
  • Description.
  • Commenting.

The NaviGAtor program uses two software tools to manage its information. One is designed to manage the field devices; the other to manage changes in the software. According to the CM manager, each tool greatly simplifies the time necessary to store and update the information. The tools are discussed in further detail later in the report.

Configuration Identification Scheme

Georgia Navigator

The Georgia NaviGAtor configuration identification scheme is broken down into five major categories, which are determined by the CM manager. The categories and numbering conventions are:

  1. Documentation: NAV01-001 – NAV01-999
  2. Hardware drawings: NAV02-001 – NAV02-999
  3. Forms: NAV03-001 – NAV03-999
  4. Software: NAV04-001 – NAV04-999
  5. Cable drawings: NAV05-0001 – NAV05-9999
Maryland CHART II System

The Maryland CHART II System similarly breaks down its configuration identification scheme into five categories. These categories are:

  1. Developed applications.
  2. Legacy applications.
  3. COTS products.
  4. Hardware.
  5. Documentation.

Table 3.1 below demonstrates the naming scheme used by the CHART II System.

Table 3.1 – CHART II Naming Scheme
Category Identification Scheme Example
Developed applications [program name] [release#][build#].[version] CHART2 R1B1.02
Legacy applications [program name] [release#(if applicable)] EORS2
COTS products:
  • Operating systems
  • Tools
  • Applications
[product name][release# (if applicable)]  
  • Windows NT 4.0
  • ClearCase 3.2
  • TTS
Hardware:
  • Network devices
  • Servers
  • Workstations
 
  • [agency]-[site]-[type][#]
  • [site][department (optional)][#]
  • [modal letter ID][tag number]
 
  • SHA-HANSOC-SWT1
  • HANSOC1
  • HO25455
Documentation [task #]-[document type]-[#][revision level(if applicable)] M361-DS-001R0
* Maryland CHART II Project Configuration Management Plan – 10/2000 (p. 3-2)
Southern California Priority Corridor

The Southern California Priority Corridor specifies the following naming scheme for configuration items:

XXXYYZZN.N

where:

XXX is the project unique identifier

YY is the CI identifier – a document and/or component identifier

ZZ is the hardware/software module identifier

N.N is the version number

Table 3.2 demonstrates some of the project unique IDs and configuration item unique Ids.

Table 3.2 – Priority Corridor Unique IDs
Project Unique ID Project CI Unique ID CI
SHO Showcase (Project Documents) CO Concept of Operations
K.3 Kernel (CSCI/HWCI) Version 0.3 UR User Requirements
K1. Kernel (CSCI/HWCI) Version 1.0 SR System Requirements
TIP TravelTIP IS Infrastructure Summary
IMJ IMAJINE UI User Interface
MVA Mission Valley ATMIS IR Interface Requirements
ICD InterCAD WD Working Document (Paper)
MSF Modeshift AP Architecture Paper
LVA LA/Ventura ATIS HL High Level Design
FOA Fontana / Ontario ATMIS SD Software Design
SDT San Diego Region Transit Management System DD Detailed Design
OCM Orange County Model Deployment Initiative (TANN) IC Interface Control Document
SDS San Diego Regional Traffic Signal Integration Project AT Acceptance Test Plan/Procedure Together
* Southern California Priority Corridor CM Plan – 12/5/2000 (p. 5-6)

Change Control

Change control is the procedure used for managing changes to the configuration of a system by evaluating a change's impact, tracing its progress, and ensuring its proper documentation. EIA 649 describes the principles behind effective change control procedures within the context of a larger CM program. Recommendations are made to help transportation professionals effectively implement change control procedures and several agencies' procedures for change control are discussed in the "Best Transportation Practices" section.

EIA Standard 649 Definition

"Configuration change management [change control] is a process for managing product configuration changes and variances."

Change control is the process that involves (1) identifying the need for a change, (2) analyzing the impact of a proposed change on system documentation, (3) evaluating and coordinating a proposed change, and (4) incorporating an approved change into the existing system with its appropriate documentation. Changes can include virtually any modification to the system, hardware or software, depending on which parts of the system the CM activities cover. Typically, agencies that utilize CM have a specific group that is responsible for administering the change control activities including reception of change requests, evaluation of requests, determination of course of action, and assignment of responsibilities.

The purpose of change control is to ensure availability of an existing system by carefully managing change. Each change is uniquely identified to minimize redundancy and confusion. Once a change has gone through the entire change control process, the item that was changed becomes part of the new system baseline. For example, if a DOT were to see a need to modify a piece of software, the change control process would be initiated, the relevant body would decide if the change should be accepted, and the new changed version of the software would emerge as the baseline. In this process, the change request would receive a unique identifier. After modification the software also would be given a unique identifier.

Personnel that deal with the system on a daily basis initiate the vast majority of change requests. Personnel may request a change for a number of reasons, which include:

  • To fix a flaw in the system (bug fixing).
  • To replace an outdated item with a newer version.
  • To improve the functionality of an item.

Although it is somewhat rare, changes also may be indirectly initiated by comments from end users or a new law that requires a change in the system.

Under change management, modifications to an item are made in a systematic, measurable fashion. Typically, changes are requested by relevant personnel to the approving body, whether it is a CCB or a CM administrator. Classifications of the type of request help the approving body rank which changes should be addressed and when. Proper classification also can improve understanding of a change's impact, and therefore which CCB members should attend particular sessions. Once the authority has approved a change, they specify the parameters in which change is to take place.

Implementation Guidance

Many important points should be considered when developing change control procedures and administration. Change control, if performed efficiently, saves time and money for the agency. This implementation guidance section is divided into three subsections:

  1. Change Control Administration and Responsibilities.
  2. Change Control Processes.
  3. Tool Use for Change Control.

All of these areas of focus are very important to developing change control as part of a CM program.

Change Control Administration and Responsibilities

Change control administration should be one of the first tasks in developing change control. DOTs should create and use a configuration control board to make administrative decisions regarding changes to the system. Many important factors should be considered in the establishment and operation of a CCB. As with the establishment of the CM administration, it is important that as many relevant departments or sections of an agency are represented as possible to ensure that all needs are addressed. Broad representation also helps to ensure that a change proposed by one group will not adversely affect another.

In order for the CCB to operate as smoothly as possible, the tasks of each of the members must clearly be defined, and a chairperson must run CCB proceedings. In cases of disputes or extended discussions giving the chairperson the authority to make unilateral final decisions may expedite the change process. One of the most significant factors that helps a CCB run smoothly is preparing all of the members well in advance by providing a meeting agenda, which includes all of the proposed changes up for discussion. Doing so gives members adequate time to determine how the respective changes will affect their interests and to prepare notes for discussion and debate of the changes. It also minimizes the time needed to review the changes during the actual meeting.

The most important task of any CCB is reviewing and determining the fate of proposed changes. For this reason, classifying the changes into different categories based on their effect on the overall system is beneficial. Some changes may be minor enough that they do not require review by the entire CCB, but rather a subsection or even an individual member.

Change Control Processes

The specifics of change control processes among DOTs vary greatly, but the same general concepts apply. It is important that groups seeking to implement effective change control use a formal procedure to ensure consistency and acceptance.

A standardized CM form is used to request a change whether it is intended to add functionality or is needed due to a flaw, a legal mandate, or regulation. Often, the form must be submitted electronically, using one of the tools discussed in the following sections. Standard information on these forms usually includes, but is not limited to:

  • Requestor.
  • Requestor's department/section.
  • Type of change.
  • Reason for change.
  • Priority.
  • Anticipated effects on system.

Once a change has been requested by correctly filing the proper form, a portion of the CCB or one of the outside CM experts should review it in preparation for CCB meetings.

Whoever is responsible for compiling and reviewing all of the change requests should author a report to be reviewed by the CCB prior to the meetings. This provides time for CCB members to look over some of the requested changes, begin to think about their impacts, and how to implement the changes. During the meetings, each change request is discussed individually, unless grouped with a similar change request by the reviewing body. Recently, GDOT has established a change assessment and resolution (CAR) leader to present the recommended solution to the CCB. This action was taken because in some cases the solution is too complicated or out of the area of knowledge of the person requesting the change.

The CCB makes decisions about approval or rejection of change requests and assigns the job, as well as issues a due date. This information should be entered into the change control tool for tracking purposes. After the change has been initiated or completed, the CCB (or, depending on the organization, the CM manager or other staff) conducts configuration status accounting and configuration audits to ensure that the change has been executed and in a way consistent with the request.

Tool Use for Change Control

The use of tools is crucial to any DOT that is attempting to implement change control. With increasing system complexity or number of system changes, tracking and managing the change control process may become difficult if left to paper-based systems. The time personnel save in terms of change status tracking and baselining justifies the costs associated with acquisition. Change management systems account for all requested changes, their initiators, the priority of the change request, and the status of the change, and can be used to introduce new baselines. Management personnel should be provided with a tool that will guide their change control activities and track the progress of personnel on their projects.

Implementation Guidance Summary

  • CCBs should be established to make decisions regarding 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.

Best Transportation Practices

This section presents a number of examples of change control and the associated procedures. The discussion is broken down into three major categories: change control administration and responsibilities, example change control processes, and tool use for change control.

Change Control Administration and Responsibilities

Georgia NaviGAtor

The Georgia NaviGAtor CM plan specifies a CCB, which is made up of DOT personnel and consultants responsible for change control decisions. The CCB must review and approve or reject all requested changes to configuration items. The CCB is not tasked with investigations or feasibility analyses. The CM manager reviews proposed changes. If a resolution is not proposed, the CM manager appoints a change assessment and resolution leader. The CCB is made up of the following personnel:

  • CM manager – chairman.
  • Program manager.
  • IT software manager.
  • Operations manager.
  • Design manager.
  • IT hardware manager.
  • Systems integrator.
  • Field hardware manager.
Figure 3.2 – NaviGAtor CCB Organization
Figure 3.2 D
* GDOT NaviGAtor Configuration Management (CM) Manual NAV01-004 – 12/19/01(p. 4-2)

CCB meetings take place regularly, normally every two weeks. Typically, the numbers of incoming System Change Request forms (SCR) helps to determine the schedule. Additional meetings may be held in cases of emergency or large numbers of outstanding SCRs. The CM manager is responsible for determining meeting times and frequency. The CM manager administers all CCB meetings. Standard meeting procedure involves the presentation of a recommended solution for each SCR either by the person that submitted it or by the CAR leader for SCRs requiring assessment. Based on the recommendation of any one CCB member, a vote is taken. If the vote is unanimous, the recommendation is approved. If not, further discussion is required until unanimous consent is reached.

Maryland CHART II System

The Maryland CHART II System relies on two major administrative bodies to regulate its change control activities: the CCB and the Level B Problem Review Board (PRB). The difference between Level A and Level B changes is represented in table 3.3.

Table 3.3 – CHART II Change Levels
Level Controlled CIs Change Reviewers Approval Authority
A
  • CHART II requirements
  • CHART II design documents
  • Acceptance documents
  • Transition plan
  • Operational system components
  • Interface control documents
  • Other items as specified by MDSHA project manager
  • Affected software managers
  • Task manager
CHART II CCB (see Section 2.3)
B
  • Development baseline items
  • Other items as specified by MDSHA project manager
  • Affected software managers
CHART II PRB (see Section 2.4)
* Maryland CHART II Project Configuration Management Plan - 10/2000 (p. 4-1)

The CCB is responsible for establishing and enforcing the procedures regulating the change control process and its place in the CM plan. The project manager, who is considered the chairperson of the board, leads the CCB. The other members of the CCB include regional managers, a representative from the University of Maryland, a representative from the Federal Highway Administration (FHWA), a contractor task manager, a contractor development manager, and an independent validation and verification representative.

The Level B PRB meets whenever necessary to address Level B changes, which are tracked and documented by the Configuration Management Office (CMO). This board is chaired by the task manager and includes the CHART II CM office, a quality assurance representative, a system test manager, a development manager and a database designer. Members of the PRB are expected to attend meetings based on their relevance to proposed changes.

Richmond, VA Smart Traffic Center

Richmond utilizes a CCB to review and accept or reject all change requests regarding Richmond software. Its board consists of three Virginia Department of Transportation (VDOT) employees and one person from each of the two contractors that helped to develop the system. Because it is a VDOT facility, a VDOT employee chairs the CCB.

In addition to the CCB, the Richmond STC also has an issue mediation board (IMB). The purpose of this board is to resolve issues that cannot be solved by the CCB. It consists of project level management personnel and maintains the authority to determine the status of change requests should the CCB be unable to do so. This board consists of one person from VDOT (the chairman) and one from each of the contractors that worked on the system.

Various activities take place before CCB or IMB meetings. Prior to CCB meetings, the representatives of the contractors gather and process all of the Trouble Report Forms, identifying changes that could be grouped into larger software package modifications. Then they specify what changes will be implemented as a result of the larger software package change, estimate time and resources to accomplish changes, list documents affected by the changes, and submit a report specifying all of this information in time for it to be reviewed before the meetings.

The CCB is to meet regularly on a schedule determined by the chair. Presently, meetings are held on a monthly basis, and there is constant communication via email. During the meetings the CCB reviews the report generated by the contractors and may determine to accept or reject the classifications of the proposed changes. The CCB acts on system operations/maintenance issues. It does not accept or deny new large-scale projects because its CM procedures are regional, and new projects are considered on a statewide basis. The CCB also determines which software release package to issue next. Any issues that are left unresolved are passed on to the IMB, which uses roughly the same structure.

Southern California Priority Corridor

The Southern California Priority Corridor CCB is comprised of two major subcommittees: the CM Subcommittee (CMS) and the CM Technical Team (CMTT). One of the stated goals of the CCB is to ensure that CM issues are addressed during the integration of regional systems. But for other considerations, CM activities are to be handled by the individual localities.

Figure 3.3 – Configuration Control Board Organization
Figure 3.3 D
* Southern California Priority Corridor Configuration Management Plan, 12/ 2000 (p. 3-1)

The CMS has several tasks listed in the plan that it is expected to carry out. The most important task is to keep all member organizations up to date with the most current procedures regarding the CM program and activities. The CMS configuration is pictured in figure 3.4.

Figure 3.4 – SCPC CM Subcommittee Organization
Figure 3.4 D
* Southern California Priority Corridor Configuration Management Plan, 12/ 2000 (p. 3-3)

The CM facilitator is involved with both the CM Subcommittee and the CM Technical Team and has several major duties. The facilitator is responsible for preparing both committees for their respective meetings by ensuring that all relevant materials are provided, maintaining the CM plan and standards, and facilitating and calling all CM meetings. The facilitator also must report on the status accounting and configuration audit activities.

The CMS chairperson manages the overall SCPC CM program. The chairperson must ensure the proper development of corridor-wide configuration items, oversee the development of CM policies, and verify that CM activities adhere to guidelines set forth by the SCPC Steering Committee. The chairperson also must ensure that all relevant personnel and committees have the resources and training necessary to carry out their CM duties.

The SCPC project director identifies issues that need to be addressed by the respective committees, ensures that these issues are addressed, and provides staff support for CM activities. The project director also acts as a liaison to make sure that all relevant stakeholders are involved in the CM process.

The CM quality assurance manager reports directly to the SCPC Steering Committee and must monitor and provide reports regarding all aspects of the CM process. The quality assurance manager is to report on the quality of these processes at the regular CMS and steering committee meetings. The quality assurance manager also is responsible for overseeing all configuration audit activities.

The regional representatives oversee change within their regions, send change requests to the CMS, and appeal CMS decisions, in an effort to support the corridor-wide CM activities.

Example Change Control Processes

Georgia NaviGAtor

The Georgia NaviGAtor system utilizes change control processes that apply to hardware, software, documents, and other configuration items. Georgia uses System Change Request forms to initiate such changes. Change requestors take the following steps during the life cycle of a change request:

  1. A proposed change is analyzed to see whether it will alter the system configuration. If it will not, a maintenance ticket is issued. If it will, step 2 is taken.
  2. The SCR is electronically filled out in its entirety; one for each requested change.
  3. The SCR is checked to ensure that all of the required fields have been completed, and a log number is issued. If the SCR is categorized as an emergency, then it is brought to the attention of the program manager. The appropriate CAR leader then develops a recommended solution for presentation to an emergency CCB. When the SCR includes a viable solution, it can be placed on the agenda of the next CCB meeting. When a recommended solution is yet to be identified, the SCR is passed to an appropriately qualified CAR leader along with a due date set by the CM manager. The SCR is added to the status report and to the CCB agenda when it is ready for presentation to the board.
  4. The CAR leader performs tasks such as completing necessary analysis of condition and forms, providing supporting documentation, and justifying the recommendations to the CCB. When a software range is required, the CAR leader may request that the SCR be pre-approved to permit further work to take place as part of a software build task order. The recommended solution generated by the code writer is vetted by the CAR leader and presented to the CCB as the recommended solution. Pre-approved software changes may lie on the table for some time before they are investigated and a solution developed.
  5. The CM manager reviews the SCR to see whether it is a valid and complete request.
  6. The document control section must document and track the release of software, documentation, and drawings.
  7. Areas that are described in the SCR must verify that baselines have been updated upon the release of the document control information.
  8. All changed items are reviewed and approved by someone assigned by the CCB.
  9. The SCR will be closed and the CCB and SCR originator will be notified of the status.
* GDOT Navigator CM Manual – 12/19/2001 (4-9 – 4-10)

Detailed information is required to submit an SCR including:

  • Originator.
  • Section – the name of the section in which the originator works.
  • Date.
  • Subject.
  • Type of change.
  • Reason for change.
  • Affects.
  • Priority.
* GDOT Navigator CM Manual – 12/19/2001 (4-4 – 4-7)

There are 24 such fields required to complete the SCR. Typically one change is requested per form. Figure 3.5 details the SCR process for Georgia NaviGAtor.

Figure 3.5 – Georgia NaviGAtor SCR Flow
Figure 3.5 D
* NaviGAtor CM Manual – 12/19/2001 (p. 4-8)
Southern California Priority Corridor

The Southern California Priority Corridor also uses a detailed system for change control. Their procedures apply to baselines, specifications, and manuals. Eleven steps are involved in the change control process:

  1. An initiator prepares a change proposal.
  2. The relevant project's engineering manager is responsible for developing the change request, which is forwarded to the CM facilitator. A package to help resolve the change is created by the team leaders. A presentation is made to the CMTT about the requested change and its impact.
  3. The CMTT reviews the presentation and makes decisions about the requested change.
  4. The requestor updates the Engineering Change Proposal (ECP) based on the comments made by the CMTT during the presentation.
  5. A presentation is made to the CMS, similar to that given to the CMTT. The questions during this presentation are more administrative in nature, focusing on items such as scheduling and costs.
  6. The requestor may make a presentation to the SCPC Steering Committee, during which questions similar those of the CMS presentation are asked.
  7. Approvals may be necessary at higher levels, based on the nature of the project.
  8. If approved, the requested change is implemented.
  9. Full verification and regression testing is performed for the change.
  10. The baseline is updated and promoted to reflect the change that has taken place to the system.
  11. CM status accounting is performed to document the results of the change control process.
Maryland CHART II System

The Maryland CHART II change control process involves formal methods to propose, assess, determine the fate of, and implement changes. The process also is designed to evaluate and track the changes from initiation to completion. As a change is proposed to the respective board, it is given a priority rating based on the chart presented in figure 3.6.

Figure 3.6 – CHART II Change Priorities
Priority Criticality Characteristics
1
Very High
Major deficiency, error, or issue that merits immediate attention until resolved

Any one of the following is true:

  • Critical system functionality is inhibited
  • Testing cannot proceed in the affected functional area(s)
  • Continuation of the situation jeopardizes the project schedule
2
High
Major deficiency, error, or issue that requires immediate attention as soon as all Very High items are resolved

Any one of the following is true:

  • Major system functionality is inhibited, but system is not inoperable
  • Testing can proceed in affected functional area(s) but with restrictions
  • Continuation of the situation may jeopardize the project schedule

3
Medium

Deficiency, error, or issue that requires resolution but not immediate attention

All of the following are true:

  • System functionality is somewhat affected, but an acceptable workaround has been identified
  • Testing can proceed in affected functional area(s) with few or no restrictions
  • The situation has little or no impact on operational use
  • Continuation of the situation does not impact the project schedule
4
Low
Minor deficiency, error, or issue that should be resolved but may be postponed

All of the following are true:

  • System functionality is not affected
  • Testing is not impacted
  • The situation (though an irritation or distraction) does not impact operational use
  • Continuation of the situation does not impact the project schedule

* Maryland CHART II Project Configuration Management Plan – 10/2000 (p. 4-1)

The CHART II change control process allows for any project staff member to propose a change to the system. The project manager reviews all incoming changes to determine if the CCB or the Level B PRB should address them. The CMO enters all proposed changes into the appropriate software tool in preparation for this review. Level A changes initially are reviewed by a small external CCB or personnel relevant to the change, which then make recommendations to the full CCB that will determine the fate of the proposed change. The change control process is represented in figure 3.7.

Figure 3.7 – CHART II Change Control Process
Figure 3.7 D

* Maryland CHART II Project Configuration Management Plan – 10/2000 (p. 4-3)

As part of the change control process, the CMO undertakes several actions based upon the determination of what will happen with the proposed change by the respective body. Such actions are listed in table 3.4.

Table 3.4 – CHART II CMO Actions
Approval Determination CMO Action Taken
Approved Updates the corresponding record in the applicable tool
Notifies the originator of approval
Forwards the approved package to the individual assigned to implementation
Continues to track implementation progress
Rejected Updates the corresponding record in the applicable tool
Notifies the originator that the item has been rejected and provides the reason(s) for rejection
Deferred Updates the corresponding record in the applicable tool
Notifies the originator that the item has been deferred and will be reevaluated on a specified date
May request that the originator provide further information or conduct further testing

* Maryland CHART II Project Configuration Management Plan – 10/2000 (p. 4 -4)

Richmond, VA Smart Traffic Center

The software CM plan for the Richmond STC specifies a number of specific change control processes. Under its procedures once a system user identifies a problem, the user is to fill out a trouble report form, which is pictured as figure 3.8. Trouble Report Forms also may be used simply to recommend enhancements. This form requires certain information about the nature of the change request, such as reasons and subsystems that the change may involve. The trouble report form is forwarded to the consultants who helped develop the system. The consultants review the form and determine the seriousness of the possible changes. Eventually, the CCB makes a determination of the status of the change request and classifies it as an enhancement, a bug, or a change. The Richmond STC plan includes a detailed flowchart, dictating which steps should be taken at this stage.

Figure 3.8 – Richmond Trouble Report Form
Figure 3.8 D

* Richmond CM Plan – 12/1/2001 (Appendix A)

Tools Use for Change Control

Georgia NaviGAtor

Georgia uses a software package tool called a change management system to help manage its change control procedures. The tool accounts for all requested changes, their priority, and their originator, and tracks the change request as it goes through the change control process. The CM manager can use this tool to help assign software change responsibility, track the status of the change, and then reintroduce it as a new baseline. The primary mission of the change management system is to control and integrate software changes. Information taken directly from the SCR form is entered into this tool in order to authorize the release of software.

Richmond, VA Smart Traffic Center

The Richmond STC uses the Client Portal Help Desk, an online issue database, for its change control applications. This online interface collects all of the change requests that are to be processed in the coming period. The change requests are entered and tracked using a feature called the Change Desk. The status of changes that have been approved is visible to the users, and the tool also can assign new changes to personnel. Because it is a Web-based tool, any project member may access it to determine the status of changes and change requests.

Configuration Status Accounting

Configuration status accounting is the element of the CM process that involves recording all relevant information about configuration items and the CM program as the system undergoes changes. One of the primary objectives of CSA is to update an item's documentation to reflect the most recent changes and the current configuration of that item. CSA is closely linked with change control and helps to ensure that each change has been properly documented. The primary output of the CSA process is current, accurate information, which will facilitate future changes to a particular item or to the system. In this section, a description of configuration status accounting based on EIA 649 is presented, implementation guidance is provided, and examples of best transportation practices are described.

EIA Standard 649 Definition

"Configuration Status Accounting (CSA) correlates, stores, maintains and provides readily available views of the organized collection of information. CSA provides access to accurate, timely information about an {item} and its documentation throughout the {item's} life cycle."

CSA is a method for organizing the information about an item and the changes it goes through and helps ensure that the documentation and other materials regarding an item have been updated. According to EIA 649, CSA deals with the storage and maintenance of:

  • Information about the configuration documentation.
  • Information about the item's documentation.
  • Information about the item's operational and maintenance documentation.
  • Information about the CM process.

Some of the primary objectives of CSA include allowing access to information about change control decisions, supporting system inquiries such as design problems, and providing total information about a configuration items. CSA allows the TMS to backtrack information to discover the source of problems or issues that may arise operationally.

Throughout an item's life cycle, all pertinent information about it should be recorded and catalogued using a system that supports data organization and allows easy retrieval of data. Specific information to be recorded is chosen typically by personnel responsible for CM management. EIA 649 cites six phases of an item's life cycle that serve as subdivisions for information gathering on that item. The information from all prior phases should be used in the current phase. The six phases are:

  1. The Conception Phase – Information about item functional requirements is recorded using the CSA procedures.
  2. The Definition Phase – As the item is developed, information such as design documentation and engineering drawings is catalogued. Essentially, any document used to design, develop, test, build, or verify an item is recorded. If the design is changed significantly during development, documentation recorded during CSA will account for these changes. This phase typically requires the largest amount of information.
  3. The Build Phase – CSA information that is recorded during this phase includes differences between the implemented item and the design. Also, the serial numbers of components and dates associated with various milestones of the build are recorded.
  4. The Distribution Phase – Information during this phase involves the installation configuration and dates associated with installations and warranties.
  5. The Operation Phase – During operations changes that are made to an item because of upgrades or maintenance are recorded and catalogued. All of the information dealing with change control of an item is maintained in this manner.
  6. The Disposal Phase – During this phase any information about the disposal of an item, such as salvage options or disposal contracts, is recorded.

CSA usually involves the recording of information in a database, sometimes referred to as the CSA information management system. The information should be gathered from multiple sources—from engineers to management.

Implementation Guidance

CSA is extremely important to a CM program because it helps verify that that the procedures specified for configuration identification and change control are implemented as intended and performed effectively. Decision makers must have the most accurate information possible on the state of the TMS. For this reason it is important to have:

  1. Effective CSA activities.
  2. Detailed CSA reports.

The CSA activities and the reports they generate go hand in hand, but are discussed separately.

CSA Activities

CSA activities are very similar across DOTs. The primary objective of most CSA activities is to record and track changes to configuration items. As an item is introduced into a system, it should become part of the CSA process. Any proposed, ongoing, or completed change to that item should be recorded with detailed information in such a way that the information is easily retrievable. Using as much detail as possible, the CSA activities should highlight any differences between the proposed change and the implemented change so that decision makers can understand the deviation.

The use of software tools for execution of CSA activities is recommended. Tools allow personnel involved with the system to enter data about items or changes to items into a central database that is viewable by all with access. Having an on-line tool or a database application allows management to review changes on a system-wide level without reading through pages of documents.

CSA Reports

CSA reports are the results of CSA activities and are the final product that management often uses to assess their systems. Various DOTs use different levels of detail and require different types of information for their reports. The format of CSA reports often is affected by the systems used for configuration identification or change control. While information may vary from report to report, some information about configuration items is essential to effective CSA, including:

  • Identification information.
  • Change history.
  • Current status.
  • Proposed changes.

These basic pieces of data help to facilitate the CSA process. But decision makers also typically add fields for additional information that would find useful.

Implementation Guidance Summary

  • All changes should be recorded with detailed information, which can be used to determine whether the change was implemented according to design.
  • 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.

Best Transportation Practices

This section presents a number of examples of configuration status accounting processes and the documentation they require. DOTs utilize various levels of CSA based on their needs.

CSA Activities

Southern California Priority Corridor

The Southern California Priority Corridor plan specifies a robust system for configuration status accounting. The plan keeps standardized records of the most current versions of documents, configuration items and their related parts, and current configuration item identification numbers. When an item is first placed under CM, the process is initiated and information is updated throughout the life cycle of the item. The stated goal of the CSA system is to:

  1. Monitor and track documentation.
  2. Report administrative activities.
  3. Track action items.
  4. Record audit results.
  5. Maintain listings of items.
  6. Track verification results.

These activities are intended to help decision makers understand the status of their systems to help them make informed decisions.

Richmond, VA Smart Traffic Center

The Richmond Smart Traffic Center CM plan specifies that the CSA activities be carried out using a Web-based database tool to record change documentation. Management personnel can query the list of requested changes to see how many are outstanding, the priority of the change, and the anticipated schedule. As changes are carried out, the contractors that work with VDOT are expected to update the Web-based tool to reflect the new status. As a change is completed, its status will change from "approved" to "completed", after which the change information will be available to VDOT management.

Maryland CHART II System

The Maryland CHART II System uses a CM plan that calls for specific procedures for CSA. The stated goals of their CSA activities are to record and monitor changes to configuration items. Each proposed change is identified and tracked, and its status is reported throughout the life cycle. One important purpose of its CSA system is to analyze the impact of changes on project activities or on the overall system. Using the reports generated by CSA, decision makers can evaluate the quality of system testing, system documentation, and personnel training.

CSA Reports

Southern California Priority Corridor

The Southern California Priority Corridor plan specifies a number of reports that are associated with CSA activities. The Specification Change Notice (SCN) tracks revisions to an item's specifications and records basic information that is used to track an item from the current release to the SCN. Detailed information also is recorded of drawings of system components. Some data that is included for this documentation includes drawing number, drawing title, and revision number. Similar reports are kept about the following:

  • Software version level and history.
  • CI component listing.
  • Change documentation tracking.
  • System problem/change report status accounting.
  • CI deliveries.
  • Review of action items.

For each of these divisions of CSA, similar information is recorded and maintained to provide decision makers with the information necessary to resolve issues.

Georgia NaviGAtor

The Georgia NaviGAtor plan specifies a system for CSA that is focused on CM activities. The three major reports that are to be generated by the CM manager and provided to the CCB are:

  1. SCR status reports
  2. SCR analysis reports
  3. Audit reports

The SCR status reports provide a log of all SCR activities, reflecting such information as priority, subject, status, and dates. The SCR status reports should be updated and made available to all CCB members on a regular basis. The SCR analysis reports provide information on all of the SCRs over a reporting period and is typically issued very three months. This report should include information such as numbers of SCRs and number of open/closed SCRs. Audit reports are generated by the CM manager within five days of an audit, providing such information as areas audited, criteria, and results. (NaviGAtor p. 3-13)

Maryland CHART II System

Table 3.5 lists the reports generated and entered into the CM software tool for the Maryland CHART II System.

Table 3.5 – CHART II CSA Reports
Report Title Content Description
CI List List of all CHART II CIs with version identifiers and cross-references to associated change records
Baseline Documentation List of currently approved versions of controlled CHART II project documentation by number and title, with cross-references to associated change records
CM Audits List of held and planned FCAs and PCAs by date, with status and cross-references to associated CIs, change records, and baseline documentation
Change Records List of all CHART II change records by number, date, and title, with status and cross-references to DOORS change records, affected CIs, and baseline documentation
D/Ws (Deviations/Waivers) List of all CHART II D/Ws by number, date, and title, with status and cross-references to associated CIs and baseline documentation
Software Lines of Code Counts Tool-generated lines of code for all baseline units divided into data set instructions (DSI), comments, and blanks
System Problem Report Summaries Table of all pending and/or closed CHART II system problems, at levels A and B, and their status, posted to the CHART II web site

* Maryland CHART II Project Configuration Management Plan – 10/2000 (p. 5-1)

Configuration Audits

The term "audit" traditionally is thought of in the context of financial statements. Configuration auditing is based on the same fundamental concept. It is a process that confirms that the documentation for each CI is consistent with the item and ensures adherence to the procedures specified in the CM plan and program. EIA 649 lists in detail the goals of configuration audits and the resources that should be used. Recommendations are made to effectively employ configuration audit procedures, and best transportation practices are listed as examples of these recommendations.

EIA Standard 649 Definition

"Configuration audits establish that the performance and functional requirements defined in the configuration documentation have been achieved by the design and that the design has been accurately documented in the configuration documentation."

Configuration audits are used to confirm that designs or documentation achieve its goals by systematically comparing the requirements with results of tests, analyses, or inspections. They are thorough examinations of CIs, comparing the associated documentation and change records that provide a history of the item to ensure that the documentation reflects the current state of the CIs. One of the primary objectives of conducting configuration audits is to verify that the documentation for items is consistent with the items themselves. Audits are carried out in order to assure that the change control procedures that are in place are effective and are being used and that the documentation reflects actual changes. Audits typically are carried out by the organization or by an independent contractor.

EIA 649 states that a body relevant to specific systems should determine procedures for auditing and verification of those systems. For example, when conducting an audit on a database system, the auditor or auditing body should be involved with the database system or have significant knowledge of it. Measures of effectiveness of configuration audit standards likewise are determined. They must be consistent within a CM program. For this reason audit plans must be developed prior to audit and agreed upon by the relevant bodies. According to the standard, the following information should be recorded during audits:

  1. Any questions the auditor has about an item or CM procedures.
  2. Discrepancies or anomalies between documentation and actual configuration.
  3. Recommended courses of action.

EIA 649 also lists a number of resources that are useful or necessary for conducting configuration audits, including:

  • Audit plan – The audit plan should be established before the audit begins with an agenda, personnel, procedures, and a listing of what specific configuration items are intended for audit. Such a plan also verifies whether personnel are following appropriate procedures. If procedures that personnel are required to follow are part of the audit, they should be identified.
  • Audit personnel – Audit personnel should be specified based on expertise in the area intended for audit.
  • Relevant documentation – The relevant documentation for audits should include design documents, identification information, and change history.
  • Tools such as software applications or matrices that track items – Tools should be used to help verify that the design is consistent with the existing documentation.
  • Access to configuration items.

The end results of the configuration audit process should verify that the identification, change control, and status accounting procedures have been used as intended. If not, the audits help determine areas where the procedures or CM program need reinforcement for compliance, modification, or improvement. The audit process helps provide a thorough review of all of the configuration items and ensures that the most up-to-date documentation of the CI status is available. This procedure also identifies some of the items that will need to be fixed or modified to reflect design requirements.

Implementation Guidance

The goals of configuration audit procedures are clear: to ensure that documentation is consistent with the system configuration, to examine current baselines, and to ensure that the changes made to a system were properly requested, approved, and carried out. An effective configuration audit procedure should verify that the other components of CM (configuration identification, change control, and configuration status accounting) are working properly or identify problems in any of these procedures.

Configuration Audit Activities

Effective configuration audit activities should take place on a regular basis with the possibility of additional audits added as necessary. The CCB should determine which parties are responsible for auditing which parts of the system, as well as the frequency of audits. Usually, agencies have the CM manager or an outside consultant that helped develop the system conduct configuration audits. Having either or both of these personnel audit the system is beneficial because both have an intimate knowledge of the CM plan and know the requirements of the system. The purpose of such audits should be to verify that configuration documentation is consistent with item configuration and that changes to items were requested, approved, and baselined in a manner consistent with the CM plan. Audits also should be conducted to ensure that various departments or offices within an agency are adhering to the procedures defined in the CM manual.

Based on the findings of the audits, the auditor(s) should be responsible for filling out all relevant forms or reports or updating any other audit documentation. Usually, these forms are an audit report and any change request forms that are needed to conform to system requirements as detailed in the CM plan. This information should be presented to the CCB for review and determination of further action. For any changes deemed necessary during the audit, the auditor should fill out documents to initiate the change and deliver it to the CCB for action.

Configuration Audit Resources

A limited number of resources are required to execute effective configuration audits. The CM plan should define specific roles and responsibilities for personnel involved with the auditing process. Ideally, a procedure for conducting the audits also is defined, perhaps as a separate document. Audit checklists can greatly facilitate the process and help ensure that audits are conducted consistently each time. The audit findings often necessitate changes, which require either the standard change forms or forms specifically tailored to changes consequent to configuration audits.

Implementation Guidance Summary

  • The appropriate personnel as chosen by the CCB should conduct configuration audits on a regular basis in order to ensure that the 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.

Best Transportation Practices

This section presents a number of examples of configuration audit procedures used in transportation CM programs. The discussion is broken down into two major categories: configuration audit activities and configuration audit resources.

Configuration Audit Activities

Georgia NaviGAtor

The Georgia NaviGAtor plan calls for two major types of audits within the CM Program: GDOT section audits and CM manual audits. The CM manager and the CM advisor regularly audit sections (departments or subdepartments) within the GDOT organizational structure to ensure that groups within the department are adhering to the CM program and plan. These audits are conducted at least on a quarterly basis for each section. The section manager receives notice well in advance of the audit as well as an agenda from the CM manager. Activities involved with the GDOT section audits include:

  • Ensuring that all documentation, software, etc. has been updated per approved SCRs.
  • Reviewing current existing baselines.
  • Comparing internal processes to standard operating procedures.
  • Establishing new procedures for CM manual and standard operating procedures.
  • Creating SCRs for any changes to CM manual.

The NaviGAtor CM plan also calls for audits of the CM manual. The CCB regularly examines the content to ensure that it is applicable to the current situation and system configuration. Based on any discrepancies identified by the audits, the CCB recommends new procedures or changes to existing procedures to the CM manager, who subsequently creates SCRs for any changes to the CM manual.

Southern California Priority Corridor

The Southern California Priority Corridor CM Plan calls for both informal and formal audits of the system. Typically, the CM quality manager is responsible for ensuring that the audits take place and for determining what members of the CM team are to conduct them. The overall project office is responsible for audits of corridor-wide CM items.

Under the informal audits, the baselines and the CM library are regularly examined to ensure that documentation and item status coincide. These audits are conducted both internally and by sources external to that particular part of the system. Another primary goal of the informal audits is to verify that contractors and vendors are adhering to the CM program. Informal audits are agreed to in advance, and the relevant parties know the agenda prior to the audit. Informal audit results are reported directly to the CMS chairperson. Occasionally, audits may be conducted of contractors working on the project. In such instances results are documented and provided to the CMS and the contractor management staff.

SCPC formal audits are more structured and defined. The quality manager conducts both functional and physical configuration audits of the system. The goals of these activities are to confirm that the documentation for CIs is consistent with their current configuration and to establish new baselines for items if needed. These audits are required to approve new baselines or prior to the installation of new hardware.

The CM quality manager determines a schedule to review and audit CM activities for quality assurance purposes. The following reports describe three major items:

  1. Compliance with CM standards and procedures.
  2. Performance of periodic informal CM audits.
  3. Performance of periodic software baseline audits.

* Southern California Priority Corridor Configuration Management Plan, 12/ 2000 (p. 9-2)

Maryland CHART II System

The Maryland CHART II Project Master Plan outlines procedures for both functional configuration audits (FCAs) and physical configuration audits (PCAs). FCAs are conducted for delivery of every item prior to customer acceptance to determine whether test results indicated that the system meets its functional requirements and to verify that the documentation for CIs is updated and accurate for the current configuration. FCAs use a set procedure, which is defined in the FCA Procedure documentation, and they are conducted simultaneously with the PCAs. The purpose of the PCAs is to confirm that a CI is consistent with its documentation and that only requested and approved changes were executed on the item.

Configuration Audit Resources

Configuration audits require the fewest amount of resources of any of the CM activities for most agencies using CM. Most agencies have documentation, which outlines some of the procedures that are to be used in the audits, and forms, which are to be completed prior to and upon completion of configuration audits.

Georgia NaviGAtor

The NaviGAtor CM manual requires the submission of formal reports to the CCB after completion of an audit. The report serves as the basis for the initiation of change request forms, which help the system conform to the requirements of the CM manual. If the requested change ultimately leads to a modification of the CM manual, then a change request must be filed and reviewed by the CCB in order for that change to take place.

Southern California Priority Corridor

The Southern California Priority Corridor CM plan specifies a list of materials to be involved in the configuration audit process, such as:

  • An audit plan.
  • An agenda for particular audits.
  • Applicable CIs.
  • Documented audit results.
  • Audit tools such as software.
  • Copies of reports and data sheets.

The findings of these audits are distributed to audited participants and other parties in formal reports.

Maryland CHART II System

The Maryland CHART II CM Plan requires a number of documents for its configuration audit processes. For FCAs the plan requires an FCA procedure document and FCA checklist, which assigns responsibilities for audit activities. Likewise, PCAs require procedure documents and checklists, which have similar goals.