Configuration Management for Transportation Management Systems
Handbook

Appendix C – Summary of CM Plans

Summary of Texas DOT Strategy

Section 1 - Scope

This plan is designed for the Traffic Operations Division (TRF) of the Texas DOT, specifically for software configuration management applications. Major issues discussed include: configuration management organization, the methods by which issues are entered and processed, identification of documents, change request formats, and the baselining system.

Section 2 – Software Configuration Management

The section begins by describing the composition of a configuration control board and its typical duties. According to this plan, the CCB should be managed by an ITS branch manager, while other positions on the board may vary. CCB responsibilities include:

• Oversee the CM process.
• Develop and maintain CM procedures.
• Conduct oversight of the implementation of CM products.
• Monitor quality of CM products.
• Provide monthly status updates to the ITS branch manager, including:
  • Issues being tracked by issue tracking tool.
  • Configuration status reports on products under CM
  • A report of personnel hours used in previous month.
  • A report of anticipated personnel hours for coming month.

Section 2 lists the other internal and external organizations with which the TRF CCB should be involved. External organizations include:

• TDOT districts.
• Hardware vendors.
• Software consultants.
• Product validation team (may be internal)

This section specifies that other organizations that develop and maintain software applications for TRF are expected to follow the TRF CM procedures. Specific procedures that they are expected to follow are outlined in the scope of work documents for specific projects. Alternative CM procedures may be proposed and approved by the TRF CCB.

Section 3 – Software Configuration Management Activities

Section 3 describes how artifacts are identified and tracked, the process for implementing changes, and the process for performing configuration status accounting and auditing. The primary subsections are:

• Configuration identification.
• Product baselines.
• Configuration management plan.
• Backup and recovery plan.
• Change control.
• Configuration status reporting.

The configuration identification section discusses how documents and source code are identified and tracked. It specifies the specific information that should be attached to documents, including:

• A product ID.
• A document acronym.
• A version number.

The product team develops the proper IDs and acronyms, and the CCB manager ensures that the product identifier in the CM repository is unique. Section 3 lists the requirements for establishment of the version numbering system (Version V.r). A document’s major version number, V, is incremented when significant new functionality is added. The minor version number, r, is incremented when bugs are addressed and smaller changes are made.

Typical software documentation should include:

• Software requirements specification.
• Software design document.
• Version description document.
• Software user's manual.
• Acceptance test plan.

The plan describes the two different repositories: developmental and production CM repositories. The developmental CM repository is the storage location for documentation and source code while the product is being developed. The production CM repository is where this information is stored once the product is ready for delivery. Once a system is placed in the production CM repository, it may only be modified after an Engineering Change Request (ECR) has been filed and approved by the CCB.

Information required on all ECRs is subsequently discussed. Twenty-two specific items are listed.

Baselines are the next items discussed in section 3. Once baselines are inputted into the developmental CM repository, the following information is to be recorded:

• How and when the baseline was created.
• Purpose of the baseline.
• A list of ECRs implemented for this baseline.
• Files that were changed.

The establishment of a configuration management plan is discussed next. The CCB uses the plan to provide guidance and outline the policies and procedures that users are expected to implement. The CM plan is submitted to the CCB for review, and the board either approves it or returns it with feedback. The CM repositories are set up only after the CM plan has been established.

Next, the backup and recovery strategy is discussed. A separate backup and recovery plan is needed for both developmental CM and production CM. During development and modification, the developmental CM must be backed up daily. The plan provides a list of media that can be used to backup this information, such as CD-ROMs and tape. The restoration process should be tested bimonthly on a computer that was not involved in the development process.

The production CM also should be backed up daily. Because production CM requires fewer changes than developmental CM, it is only necessary to record the changes and not the entire documents. The entire production CM repository should be backed up either monthly or quarterly, and the restoration process should be attempted on a computer that does not contain the production CM. The CCB is responsible for ensuring that adequate backup procedures take place.

The next major topic in Section 3 is change control. For TRF purposes, change control is initiated by identifying issues and entering them into an issue-tracking tool. The ITT is a Web-based system that automatically generates emails to the CCB manager when a new issue has been inputted into the system. The CCB addresses emergency issues as quickly as possible. Periodically, the CCB manager converts the issues to ECRs, at which point the CCB has the following options:

• Approve the ECR
• Deny the ECR
• Request clarification for the ECR
• Request internal research be performed on the ECR

The CCB meets monthly, either in person or via teleconference, to discuss ECRs. For ECRs that have been denied or that have had more information about them requested, emails are automatically generated to the submitter, informing him or her of the status. Typically, technical staff is assigned to work on the ECRs requiring internal research. Similarly, approved ECRs are updated in the ITT and assigned to a staff member to begin work.

Section 3 also discusses the process for local source code change control. A staff member checks out the necessary files from the production CM repository and performs only the tasks specified by the ECR. Once the tasks have been completed, the staff member will perform tests and subsequently pass the modified files to the Product Validation Team. Through this process, the staff member is to create documentation for the modifications to be submitted to the Product Validation Team.

The next topic describes in section 3 is remote source code change control. Because many districts are involved in this system, local district staff sometimes will want to modify source code that TRF maintains. The same process is used as is used for other modifications, whereby the local staff submits ECRs to the CCB. If approved, the source code is placed in a staging area for alteration by local staff. The code is baselined, however, so that the new version is district specific and leaves the original source code unmodified. If the source code for the whole system is eventually changed, meaning that the baseline has been altered, local district staff is notified of any branched code to be affected.

Configuration status reporting is the last topic addressed in section 3. Configuration status reporting involves the tracking and reporting of the product artifacts under CM. On a monthly basis, reports are generated, which list:

• The version of the artifact.
• A revision history of the artifact.
• The current status of the artifact.

This information is gathered by performing CM audits. During the audit process the product artifacts are checked to ensure that the changes implemented were approved by the CCB and that the relevant standards were adhered to. The strategy lists the information expected to be included in the audit. The following is the process that is to be followed for audits:

• CCB assigns a staff member to execute the audit.
• Staff member creates the report.
• Staff member reviews the report and notes discrepancies.
• Staff member reviews the structure and facilities of the CM library system.
• Staff member verifies the completeness and correctness of the baseline library contents.
• Staff member finalizes the CM audit report.
• Staff member presents the report to the CCB.

Also included in this section is a discussion of the product release process audit, which is designed to ensure that the current product release is the one that is being distributed to customers. It then lists specific information to be included in these audits. This is the conclusion of the TxDOT TRF Configuration Management Strategy.

Summary of Georgia NaviGAtor CM Plan

This document summarizes the configuration management plan developed for the Georgia NaviGAtor system. The plan is divided into six areas:

• General CM information.
• Configuration management control procedures.
• Configuration control board.
• Software management procedures.
• Hardware management procedures.
• Design configuration management procedures.

Section 1 – General Overview

The configuration management plan is one of three control tools GDOT uses to manage the NaviGAtor system (the other two are the maintenance plan and the Technical Integration Working Group). GDOT uses the configuration management plan to manage the expansion of its NaviGAtor system, which includes adding fiber optic cable, communications hubs, field devices, and changes in hardware. The primary objective of the configuration management plan is change control throughout all stages of this expansion.

This section introduces the four major processes of the NaviGAtor configuration management system: identification, control, status accounting, and audit and review. The identification process includes identifying all system components, such as documents, drawings, software, and hardware, by name, identification number, and version. The control process maintains a stable configuration while changes are being implemented to the system and does so via the configuration control board (CCB). Status accounting involves the recording and reporting of change requests in order to maintain information on the potential impacts of a change. Finally, the audit and review process ensures that correct procedures are being followed and that the configuration management program is being used to maximum benefit.

Section 2 – General CM Information

This section describes the required resources for effective configuration management. First, a table (reproduced in table C-1) details key positions in the configuration management system and lists their responsibilities. The document states that the two major functions of the CM team are to serve as CCB members and to perform administrative duties, such as overseeing design reviews, monitoring schedules and budgets, and recommending new processes and procedures.

The next section describes baselines and their requirements, including items that are under baseline control such as documents, drawings, software, and hardware. Finally, the CCB is explained; the major action of the CCB is to review and either approve or reject change requests. Change requests are submitted using a System Change Request form and no change is permitted without CCB approval.

Section 3 – CM Control Procedures

Section 3 describes six specific procedures of the CM plan beginning with documentation/drawing management. As consistency and traceability are needed for effective configuration management, this area covers production and control procedures such as numbering conventions, formatting, and revision control. The next control procedure is data archive and release control, which manages documents, drawings, forms, and software data so that earlier versions of such items are available even after related change requests have been approved and implemented. Training is the third control procedure and is considered "the most important part of the overall CM plan." Training is to be conducted by the CM advisor or manager, and classes are to include "real life problems and situations as they relate to the attendees’ jobs and CM principles." The fourth procedure, status reporting, is the recording and reporting process for CM item information and includes change request reports, change request analysis reports, and audit reports. The fifth procedure is auditing, which establishes a plan for continual monitoring of CM processes and procedures. Specifically, the auditing process develops the required audits, their content, and timing, including audits of GDOT sections and even the CM manual itself. Finally, a COTS software control procedure controls the review, purchase, storage, and control of all COTS software used in the NaviGAtor system.

Section 4 – Configuration Control Board (CCB)

As stated by the CM manual, "it is the function of the CCB to review and approve or reject all requested changes for hardware, software, documentation and drawings that are under CM control." The CCB is not to be a "preliminary investigation tool for problems," but rather a decision-making entity evaluating recommended resolution to problems. Therefore it is essential that the mechanism for requesting a change, the System Change Request form, be thorough and complete, because, as the CM manual states, "the SCR process is only as good as the information provided." The SCR is completed by the originator, a change assessment and resolution leader (assigned by the CM manager), and the CM manager. The SCR includes information such as:

• Name of originator, CAR leader, and CM manager.
• Type of change.
• Reason for change.
• Affects.
• Priority.
• Description of condition.
• Recommended solution.
• Approval.
• Updated data assignments.
• Tracking numbers.
• SCR history.

The CCB is to meet regularly to decide upon SCRs using the process illustrated in figure C-1.

Section 5 – Software Management Procedures

This section specifies the CM processes to be used during the software development cycle. First, the required reports are described, including the system requirements specifications, high-level software design document, detailed software design document, system test procedures, system test report, and software change description document. Next, the methods of configuration identification are explained so that all baseline items are assigned consistent and unique names and numbers. Finally, the manual details the tools for software change control, which include the SCR (standard for any change within the NaviGAtor system) and ClearCase, a software management tool.

Section 6 – Hardware Management Procedures

This section of the CM manual is still a work in progress, but it may be safe to assume that it will include procedures for configuration identification, required reports, change control, status accounting and auditing.

Section 7 – Design CM Procedures

The majority of the Design CM Procedures section describes SCR submittal and timing, including a timeline of SCR activity compared to design activity. A summary of this timeline is provided in table C-2.

Table C.2 – SCR Submittal Timeline

Design Activity	Days	SCR Activity	SCR Notes
Preliminary Design Review	1	Submit 1st SCR to CM manager if assessment is required (submit approximately 1 month later if assessment is not required)	Possible changes to existing drawings fiber allocation, special provisions and software.
	50	1st SCR submitted to CCB
Start of Final Design Phase	60	1st SCR data updated
Final Field Plan Review	150	Submit 2nd SCR to CM manager	Possible additional changes to drawings and special provisions resulting from final design phase.
	160	2nd SCR to CCB
Contract Submittal	170	2nd SCR data updated
	180	Submit 3rd SCR to CM manager	Possible additional changes to drawings and special provisions resulting from contract review.
	190	3rd SCR to CCB
Advertisement	200	3rd SCR data updated
	210	Submit 4th SCR to CM manager	Possible update to drawings and special provisions from contract advertisement.
	220	4th SCR to CCB
Contract Letting	230	4th SCR data updated
End of Construction		Submit 5th SCR to CM manager	Possible update to drawings to incorporate "as-built" changes.
		5th SCR to CCB
		5th SCR data updated