Configuration Management for Transportation Management Systems:
A Primer

CM Baseline

The concept of a baseline is not new or complex. In general, a baseline is a well-defined, well-documented reference that serves as the foundation for other activities. For configuration management a baseline is a stable, well-documented, and thoroughly tested version of the transportation management system at some point in its life cycle. For this reason, all CM activities should ensure that all changes to a baseline are carefully considered and documented so that future baselines are solid.

Transportation management systems do not have simply a single baseline. If fact, during the life cycle of the system, multiple 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.

Baseline Elements

Some baselines purely involve documentation, while others include software, hardware, and so forth. Typical baseline elements are:

• Documentation – This is an element of each and every baseline. 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 Release 1/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.