Table of Contents

Chapter 7 – Configuration Management and the System Life Cycle

As a transportation management system progresses through its life cycle, it will be altered in a number of ways to support such areas as improved functionality, regional integration, and so forth. In order for a CM program to effectively address change, CM must be included in each and every stage of the system life cycle, starting with the concept of operations.

Configuration Items

Before examining CMs role in each phase of a system life cycle, it is useful to review the definition of a configuration item and consider the elements that "surround" each item and enable the item to function as intended.

As described in chapter 3, transportation agencies generally consider all software components, communications cable, and hardware involved in their transportation management systems to be configuration items. Figure 7.1 illustrates the relationship of configuration items to the various elements that "enable" these items. In other words, each of the elements takes place during the system's life cycle in order to ensure that the configuration item successfully provides its intended function.

Figure 7.1 – Configuration Items and Supporting Elements
Figure 7.1 D

In order to better interpret this figure, consider the following activities/resources, which are included in each of the elements:

  • Test System – test plan, test procedures, test environment, simulators, and test jigs.
  • Product Definition – requirements, high-level design, detailed design, traceability matrix.
  • Support Systems – operator manuals, training manuals, maintenance manuals.
  • Production Systems – production process and environments.
  • Development System – build environment, procedures, patches.

Each of these elements directly supports configuration items. Consequently, the integrity of the system is reliant upon the elements, which is why the elements must be placed under configuration control. Given that each element takes place during different phases of the system life cycle, the next section will directly address these phases.

System Life Cycle

Figure 7.2 specifically illustrates configuration items and their associated elements in the context of the "Vee" diagram commonly used to describe a generic system life cycle.

Figure 7.2 – The Systems Engineering Life Cycle and Configuration Items
Figure 7.2 D

As seen in figure 7.2, the system life cycle begins at the very outset of exploring the concept of operations, and then continues throughout system use and maintenance. Best practices in configuration management are to incorporate CM in each and every stage of the system life cycle. In table 7.1 elements of the configuration management process described in chapter 3 are mapped to stages of the system lifecycle, which are illustrated in figure 7.2.

Table 7.1 – CM and the System Life Cycle
System Life Cycle Stage Config. Mgmt. Planning Config. Identification Config. Control Config. Status Accounting Config. Audits
Concept of Operations Checked empty cell empty cell empty cell empty cell
System Requirements empty cell Checked Checked empty cell empty cell
High Level Design empty cell Checked Checked Checked empty cell
CI Level Design empty cell Checked Checked Checked empty cell
Component Level Design empty cell Checked Checked Checked empty cell
Implementation empty cell Checked Checked Checked empty cell
Unit Testing empty cell empty cell Checked Checked Checked
CI Verification empty cell empty cell Checked Checked Checked
Subsystem Verification empty cell empty cell Checked Checked Checked
System Verification empty cell empty cell Checked Checked Checked
Operation and Maintenance empty cell empty cell Checked Checked Checked
* Adapted and expanded from "A Guide to Configuration Management for Intelligent Transportation Systems", Gonzalez, 4/2002

Traceability Through the Life Cycle

As systems age, personnel come and go, and technology changes. Accurately recalling details of why certain design decisions were made in the past often becomes very difficult to do. This lack of institutional memory, which is unavoidable without a solid configuration management change control system, results in a significant loss of efficiency. Thus, a key benefit of including configuration management throughout the life cycle is to ensure traceability. Although traceability may appear to be a complex systems engineering term, it simply is the concept of documenting how and why the system has arrived in its current state. An important fact to note about the system life cycle diagram of figure 7.2, is that each and every configuration item of a system is traceable to its parent high-level design, requirements, and concept of operations.

Traceability begins at the requirements stage. Uniquely identifying requirements is important so that they might be tracked and undergo the change control process as configuration items. Because requirements often are changed or deleted, having a system to control and account for these changes, as well as the proper documentation to understand the project goals, is extremely beneficial.

As projects progress, requirements eventually become specifications. These specifications similarly should be considered configuration items and linked, through documentation, to the requirements on which they are based. Dong so allows easier tracking of the development of the system. As the project proceeds, documentation should reflect the configuration items, such as hardware or software components, that are used to satisfy particular specifications. All of these items should be linked in a traceability matrix or by use of CM tools. Table 7.2 provides an example of a single record (or row) in a traceability matrix:

Table 7.2 – Traceability Matrix
Requirement Specification Software Modules
R9.1.1 S38.17 DDM031, VSM022, DSM040
* "A Guide to Configuration Management for Intelligent Transportation Systems", Gonzalez, 04/ 2002

The system will undergo testing as it is assembled. Results from tests and associated documentation should be considered configuration items as well. Dong so allows managers to easily determine whether or not system requirements have been met. A revised traceability matrix is provided in table 7.3.

Table 7.3 – Revised Traceability Matrix
Requirement(s) Specification(s) Software Module(s) Test(s)
R9.1.1 S38.17 DDM031, VSM022, DSM040 VT063
* "A Guide to Configuration Management for Intelligent Transportation Systems", Gonzalez, 04/ 2002

Baselines

A number of different baselines will be created throughout the system life cycle. For a full discussion of baselines and their relationship with specific phases of the system life cycle, please see chapter 5.

Implementation Guidance

This section provides guidance to transportation professionals for incorporating configuration management in the system life cycle.

Don't Wait

Table 7.1 may appear somewhat daunting to transportation professionals new to configuration management. While such a detailed incorporation of configuration management is desirable and certainly a best practice, the real lesson in the table is that configuration management starts when the system concept is formulated.

What If You Have Started Late?

Numerous currently operational systems that were not developed under a configuration management program exist. In such cases it is easy to resist beginning a program because it will be "too late." Such a decision is not a suggested course of action. It is never to late to institute CM as benefits can be gained at each stage of the system life cycle except when nearing system obsolescence.

Agencies are not advised, however, to attempt to re-create configuration documentation for already completed stages of the system life cycle. For example, if the system is already in operation, attempting to formally create functional baselines after the fact it is not good practice. In many cases supportive documentation is not available, and the benefit gained does not outweigh the effort. Rather, an agency should simply pick up configuration management at the current life cycle stage of the system.

How does CM get incorporated in the System Life Cycle?

Once a CM program has been established and accepted by the staff (as documented in the CM plan), the program must be used on future system upgrades and new initiatives. Requests for proposals (RFPs) must include language consistent with the CM plan. For new projects it is that contractors and developers conduct themselves in accordance with the program, which may compel them to practice CM themselves or deliver their products ready to be brought under CM. Because the CM program should place design and technical documents under document control, the RFPs should specify formats, numbering schemes, and any other data relevant to the CM program. Such specification simplifies the document control process, as the documents should be delivered ready to become configuration items.

Implementation Guidance Summary

  • Configuration management should begin at the concept of operations stage of system development.
  • Require consultants and contractors to deliver products that meet the requirements set forth in the configuration management plan.
  • Use figure 7.1 to provide guidance for necessary configuration management activities at stages of the system's life cycle.
  • Agencies that have started late should not try to "catch up." Simply begin applying configuration management as appropriate for the system's life cycle stage.
  • It is rarely too late to implement CM and reap the benefits.

Best Transportation Practices

Considering how transportation agencies have addressed CM during various phases of the system life cycle is useful. Some agencies have specific policies related to the life cycle written in their CM plans, while others simply desire to incorporate as many CM considerations as possible into the process.

Southern California Priority Corridor

The Southern California Priority Corridor CM plan specifies how CM should be incorporated in the design, acquisition, and development of the system. It requires that the CM facilitator ensure that work plans and RFPs use language consistent with the CM plan. Any contractors or subcontractors for projects are expected to follow the procedures outlined in the plan. One of the most important requirements that the plan specifies is that consultants and developers are to participate in audits of the system upon completion of projects.

Similarly, the SCPC CM plan has provisions for the Interface Control Working Group (ICWG) during system development. The leader of the ICWG is required to ensure that RFPs and work plans specify how consultants and developers are expected to perform during development. They are to work with the ICWG to develop the appropriate specifications and documents that will be treated as configuration items.

Richmond, VA Smart Traffic Center

The Richmond Smart Traffic Center uses similar policies when it comes to contracting and system improvement. One particular example of these policies is RFP 717-WB, through which the center sought to retain a system manager to perform system maintenance and administration. In the RFP, there were specific guidelines related to CM that the contractor would be expected to follow.

Because the position is system manager, the contractor is expected to manage CM activities. The system manager is tasked with reviewing and updating the CM plan to outline current policies and procedures. The RFP specified that the system manager play a crucial role on the CCB. The system manager is expected to use the current change-tracking database or propose an improved method.

Also included in the RFP were provisions regarding the specific duties of the system manager as would relate to CM and CCB meetings, including:

  • Review all change requests and determine whether they are bugs or enhancements.
  • Obtain clarification as needed from the author of the change request.
  • Recommend possible groupings of changes that could be combined into a software release package.
  • Draft a software release package that includes the following:
    • List of all change requests that will be included in the release.
    • Rough estimate of the level of effort required to implement the package.
    • List of documents affected by the changes.
    • Test plan indicating whether new test procedures will be used, or if existing software test description documents can be modified for acceptance testing.
    • Training plan, if required, for the software release package, which will specify the amount of training, whether supporting documentation will be needed, and approximately how much time will be needed to train end-users.
    *(VDOT RFP# 717-WB)

Obviously, this RFP has very specific policies regarding CM because the contractor would be an essential part of the CM program. Basically, the system manager is to follow the procedures in the plan or make improvements where possible.

Georgia NaviGAtor

The Georgia NaviGAtor CM program addresses major issues in the software development life cycle. During each step of the cycle, periodic reviews are performed and a number of documents are produced. Figure 7.3 lists the steps, reviews, and documents associated with the NaviGAtor software development cycle:

Figure 7.3 – NaviGAtor Software Development Cycle
Figure 7.3 D
* GDOT NaviGAtor Configuration Management (CM) Manual NAV01-004 – Rev. 5.0: 12/19/01(p. 5-2)

Several major reports are required throughout the software life cycle, representing each of the major phases during development. The required reports are:

  1. System Requirements Specification – This report specifies the technical requirements for a piece of software for the system. It also should list the means of verification to ensure that all of the requirements will be met. A new System Requirements Specification must be created for each software version.
  2. High Level Software Design Document – This report describes the general architectural approach to be used on the software configuration item. It is intended to be the predecessor to the detail design and allows requirements to be allocated to components of the software.
  3. Detailed Software Design Document – This document "completes the description of the software design by detailing the design, behavior and interfaces for all of the software units." All of the units designed are to be traceable back to the original requirements. Upon completion of this report, coding and testing may begin.
  4. System Test Procedures – This document should outline the test scenarios and test procedures for testing the new software, either on its own or integrated into the NaviGAtor system. All test procedures should be traceable back to the initial requirements and seek to verify that the requirements have been met. New test procedures must be established for each software version.
  5. System Test Report – This report should describe the testing and results for the particular piece of software and should assess the quality of the software. A new report should be generated for each software version.
  6. Software Change Description Document – This document is a record of the modifications and defect fixes and the associated System Change Request numbers.

These reports cover all phases of the software life cycle and ensure that the design and development process achieve the requirements specified. It is important to point out that each and every one of these reports falls under configuration control.

U.S. Department of Transportation Federal Highway Administration