# Presentation: 140208

## Session 9

**Change and Problem Tracking**

- S1	Welcome and Introduction
- S2	Introduction to Safety Information Exchange
- S3	Operational Concepts
- S4	System Overview
- S5	SAFER Networking
- S6	Microsoft Windows NT
- S7	Standard Procedures
- S8	System Configuration
**S9****	****Change and Problem Tracking**
- S10	SAFER Versions
- S11	Using OpCon
- S12	Laboratory Exercises
- S13	Wrap-up

## Session Plan

- Configuration Management and Change Control:
- APL responsible for new requirements, tweaks, and bug fixes.
- Problem report forms
- New feature request forms

## Session Objectives

- Familiarize the student with Configuration Management and Change Control
- Step the student through a typical change request/problem report
- Introduce the student to the two forms used
- APL CVISN Change Request Form
- APL CVISN System Maintenance Log

## What is Configuration Management?

- According to the IEEE Standard Glossary of Software Engineering Terminology (Std 610.12-1990), configuration management is:
*A discipline applying technical and administrative direction and surveillance to:  identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.*

**Notes:**
Configuration Management (CM) serves as a means of establishing procedures and directives to be used in controlling the Commercial Vehicle Information Systems and Networks (CVISN) server hardware and software.  The procedures established are intended to support all system developers and to provide a framework through which CM principles may be applied.  Change Control, as defined in this document, is the process of controlling the hardware and software through all its changes.
The purpose of the Configuration Management and Change Control standard is to describe how to manage change approval and to control hardware modifications and software versions for all parties concerned.
The procedures will form the basis for:
1.	identifying the configuration management items
2.	controlling changes to configuration items
3.	establishing and maintaining status of changes and implementations
4.	allowing approval of all changes
Configuration Management is a discipline applying technical and administrative direction and surveillance to identify and document characteristics of a configuration item (CI). A Configuration Item is the hardware, software, or design that is under control.  The Configuration Management process will be administered with the aid of a Configuration Management System.  This system will be used to identify, control, audit, and review all configuration items.  Configuration Control Boards (CCBs) manage the process.  The CCB is a team of technical and program management representatives who are responsible for evaluating and recommending corrective actions for controlled configuration items.

## What happens when a user submits a change request/problem report to the help desk at Volpe

- User submits request/problem to Volpe
- Volpe submits a Trouble Reporting System to their internal system.
- Volpe decides what the next step is:
- Options:
- Resolve at Volpe
- Contact outside contractor/vendor
- Volpe sends change request to APL

## What happens when a user makes a call to the Volpe help desk?

**1. Any user calls the Volpe help desk with a possible change to the system.  (Users may include, but are not limited to, Web users, MCMIS users, CVIEW users, ASPEN users, etc.)**

***Originator/User***

***Volpe Site/Team***

***APL Site/Team***

**2. Volpe help desk**
**team member logs**
**the call using the**
**Volpe help desk s/w.**

**3a. If the call can be resolved by the Volpe Team, then they can resolve the issue.**

**3c. If the call needs to be resolved by the APL Team, then the Volpe help desk person should submit a Change Request (CR) into the APL CR system**

**3b. If the call can be resolved by contacting an outside agency/**
**vendor/**
**contractor, then the Volpe Team should contact the correct company to resolve the issue.**

**6. All Volpe help desk calls are logged and that log is sent to the APL Team on a regular basis for review.**

**4a. Feed back to the originator is given.**

**4b. Feed back to the originator is given.**

**4c. The Volpe help desk person then faxes a Change Request Form (CRF) to the APL Team.**

**5a. The call is closed.**

**5b. The call is closed.**

**7. The log of Volpe help desk calls is reviewed by the APL Team on a regular basis.**

**9. A Change Request (CR) is received by the APL Team.**

**8. If a pattern is observed in the logs, the APL Team will generate a Change Request (CR) for the recurring issue.**

**5c. Feed back to the originator is given.**

**GO TO NEXT SLIDE**

## What happens when the Volpe help desk person submits a CRF to the APL Site/Team?

**10. A Change Request (CR) is generated.**

***APL Site/Team***

**11. The APL SAFER Configuration Control Board (CCB) meets every two weeks to discuss new CRs.**

**12. The APL SAFER CCB then assigns the CR to an individual to analyze. **

**14. The APL SAFER CCB then determines whether or not to approve the change requested.**

**15a. If it is approved, then the CR is assigned to a person to make the necessary changes.**

**13. The person responsible for analyzing the change request then reports back every two weeks to the entire team.**

**15b. If it is not approved, then feedback is given to the originator of the CRF.**

## Audit TrailsTwo Forms

- 1. APL CVISN Change Request Form (CRF)
- 2. APL CVISN System Maintenance Log
- Both of these forms, and their associated descriptions, can be found in the following document:
- CVISN Prototype Server and Workstation Configuration Management Document (File size: 1,396KB, Draft, POR-98-7121 D.1, dated July 1998)
- http://www.jhuapl.edu/cvo/downdocs/index.html#Projects

## Audit TrailsAPL CVISN Change Request Form (CRF)

- Any user should complete the CRF when a hardware or software change request (also includes problem reporting) is submitted.
- The user must complete side one of the form, including the header information.
- A sample of the APL CVISN Change Request Form (CRF) is shown on the next pages.
- Note: There is a “History” section (after Part 5 of 5 in the APL CVISN Access Database)

## Audit TrailsAPL CVISN Change Request Form (CRF)(side 1 of 2)

- Audit TrailsAPL CVISN Change Request Form (CRF)(side 1 of 2)

**Notes:**
CVISN Change Request Form (CRF)

The obverse and reverse sides of a CRF are shown in Figure 2 and Figure 3, respectively.  Any user should complete the CRF when a hardware or software change request is submitted.  The user must complete side one of the form, including the header information (NOT the CRF Number field), Part 1 of 5 of the CRF (Change), and submit the CRF to the appropriate CCB.  The CCB will assign a person to analyze the request and complete Part 2 of 5 of the CRF (Analysis).  The CRF will be then forwarded to the person responsible for making necessary system modifications who will complete Part 3 of 5 of the CRF (Correction).  The CCB will notify the request originator of applied modifications after which Part 4 of 5 (Test or Review) will be completed by the person responsible for the modification.  Part 5 of 5 (Release) will be completed by both a development site tester, where the change request was initially corrected, and a field site tester, where the change request originated.

These forms are retained for the lifetime of the system and provide one of the primary sources of information on hardware and software change requests and modifications.

## Audit TrailsAPL CVISN Change Request Form (CRF)(side 2 of 2)

## Audit TrailsAPL CVISN System Maintenance Log

- Users performing hardware or software maintenance or modifications to the SAFER servers must complete a system maintenance log.
- A sample of the APL CVISN System Maintenance Log is shown on the next page.

## Audit TrailsAPL CVISN System Maintenance Log

## This Page Intentionally Blank