Configuration Management for Transportation Management Systems
Handbook

Chapter 5 – Configuration Management Baselines

The previous chapters have detailed the key elements of the configuration management process, including the planning element and core processes. This chapter examines the fundamental concept of a system baseline in depth. The concept of baseline is central in configuration management. In order to effectively implement a configuration management program in a transportation management system, one must fully understand baselines.

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 configuration management activities should ensure that all changes to a baseline are carefully considered and documented so that future baselines are solid.

This chapter defines and describes the concept of a system baseline, provides guidance for transportation management system applications, and gives examples of effective baselines currently used in transportation management.

EIA Standard 649 Definition

"A baseline identifies an agreed-to description of the attributes of a {system} at a point in time and provides a known configuration to which changes are addressed."

Establishing baselines and managing changes to baselines are the key functions of configuration management. Baselines are extremely important to system managers. For example, in the event of system failure, the last established baseline can be recovered in order to maintain system availability. Well-maintained and managed baselines also allow for smooth transitions when systems are integrated with external entities or when new contractors or consultants are brought on board to work with the system.

According to EIA 649, recognizing what baselines need to be established and when they should be established is fundamentally important. The first step of this process is assessing the agency's information requirements and what system elements are to be included in baselines. The analysis and deliberations required in the configuration item identification process, described in chapter 3 of this handbook, help to accomplish this goal. The next step is determining when it is necessary to institute baselines. Baselines should typically be established at key system life cycle milestones. Guidance in this area is provided later in this chapter.

EIA 649 also identifies baseline-related requirements for the CM plan. When developing the CM plan, agencies should ensure that the following items are directly addressed:

• When and how baselines will be defined.
• The process for assuring document and file integrity.
• The authority to approve baseline changes.
• If and when change authority will transfer.
• The process by which proposed changes will be implemented.

Implementation Guidance

Why establish baselines?

Careful attention to establishing formal baselines ensures long-term system availability and supports efficient future system maintenance, integration, and upgrades.

Types of Baselines

Transportation management systems do not have simply a single baseline. In fact, during the life cycle of the system, multiple baselines will be established and maintained. Figure 5.1 provides example system baselines for different points of a typical system life cycle. Figure 5.1 is nearly identical to figure 7.2, which is used to describe the system life cycle in chapter 7. The only difference is that letters have been superimposed on the "control gates" of the life cycle to indicate the appropriate baseline at these gates. The letters correspond to the baselines and descriptions that are presented in table 5.1.

Table 5.1 – Baselines in the System Life Cycle

	Baselines in the System Life Cycle
A	Concept of Operations Baseline – This baseline is established at the conclusion of the system conception stage. In most cases, this baseline 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.
B	System Baseline – This baseline may be considered to be the final functional requirements developed for the system. Often, this baseline may be the set of requirements issued as part of a system acquisition solicitation. In addition, as is the case in many acquisitions, these requirements may be changed slightly based on requirements analysis and negotiation that occurs once a contractor is brought on-board. This is an excellent example of a change to a system baseline that should be carefully controlled through the configuration management program. Note that the system baseline is very important to address the real challenge of scope creep in developing transportation management systems. 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 configuration control board) fully considering the ramifications.
C	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.
D	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.
E	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 configuration control board.
F	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.

Elements of a Baseline

As noted in table 5.1, all system baselines are not the same. 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.

Implementation Guidance Summary

• Keep formal baselines throughout the system life cycle.
• 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.

Best Transportation Practices

This section describes the experiences of three transportation agencies that use baselines in the configuration management of their transportation management systems.

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. Although the CM manager for the NaviGAtor program expressed some disappointment because it is somewhat difficult to ensure that contractors comply, auditing can help to verify and reinforce compliance to procedures. The CM manager for Georgia also stated that baselining is, by far, the agency's most expensive activity, costing over $500,000 thus far.

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 illustrated in figure 5.1, 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. The CHART II project baselines are shown in table 5.2.

Southern California Priority Corridor

The Southern California Priority Corridor lists three categories of baselines in its CM plan. They are:

• Functional Baseline – Baselines on the system-of-systems level and corridor-wide configuration items
• Allocated Baseline – Baselines on the system level and project level configuration items
• Product Baseline – Baselines that include the detailed design of developed software, hardware, or firmware
  • SCPC CM Plan (p. 5-4)

Figure 5.2 illustrates the allocation of baseline to life cycle stage.