# Presentation: 542901

## Configuration ManagementT3 Webinar Feb 21, 2008

**Chuck Larsen**
- ITS Program Coordinator
- Oregon Department of Transportation

## Outline

- CM at ODOT
- Our repositories
- Configuration Identification  (more formal)
- Change Management
- Accounting
- Audits				      (less formal)
- Support for CM
- Benefits & Lessons learned

## Configuration Management at ODOT

- CM is very integrated into what we do
- It is hard to discuss it as a sole context
- It is a key process set in our system development, project management, and maintenance methodology

## CM Repositories at ODOT

- Project document
- Project Statements, Designs, Test Plans, Specs, etc...
- Source code
- Requirements Repository
- Application deployment and versioning
- Hardware deployment
- Field equipment

## Project Documents

- Project documentation is stored in directories, the directory structure is controlled by the project office.  It is organized by system by project.  They are also organized by projects in development vs. in production.

## Project Documents Include

- Project Management
- Development Methodology
- Architecture
- Development strategy
- Requirements reports
- Design
- Specs
- Test plans

## Source Code Management

- Source code is stored in directories, the directory structure is controlled by the project office.  It is organized by system and by version.  Old versions are stored in history. Current development code vs. what is in production.

## Requirements Repository (Doors)

| 158 | 6 | 194 | The TOCS’s shall support an automatic interface to the Remedy application.  Automatic notification may be based upon thresholds | 2 | 700 |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 156 | 5 | 239 | The TOCS system shall be capable of generating alarms from all ODOT field devices within an ODOT designated zone. | 2 | 700 |  |  |  |
| 76 | 4 | 249 | The TOCS will use Traffic Monitoring Stations to determine traffic conditions | 2 | 700 |  |  |  |
| 309 | 6 | 320 | The scheduler shall support at least # TBD simultaneous active, scheduled events at any given time. | 2 | 700 |  |  |  |
| 310 | 6 | 321 | The scheduler shall be able to integrate other subsystems, such that additional devices and actions may be scheduled (i.e., set camera views for time of day, schedule ramp metering, etc.). | 2 | 700 |  |  |  |
| 406 | 3 | 379 | The TOCS shall provide an integrated VSL (Variable Speed Limit) program using all of ODOT’s roadway field devices. | 2 | 700 |  |  |  |

- ODOT maintains a master requirements list of all systems. The list gets updated through the system development and maintenance process.
- This is not true for all legacy systems.

## Hardware/Software 

**IT System Menu**

| IT System Name  | Acronym  | Program Area  |
| --- | --- | --- |
| Top of Form
Advanced Traffic Management  | ATM  | ITS (Intelligent Transportation Systems)  |
| Automatic Vehicle Location  | AVL  | ITS (Intelligent Transportation Systems)  |
| AVTEC Radio System  | AVT  | ITS (Intelligent Transportation Systems)  |
| Cable TV  | CTV  | ITS (Intelligent Transportation Systems)  |
| Camera Services  | ITS-CSS  | ITS (Intelligent Transportation Systems)  |
| Closed Circuit TV Region 1  | CCT1  | ITS (Intelligent Transportation Systems)  |
| Closed Circuit TV Region 2-5  | CCT2-5  | ITS (Intelligent Transportation Systems)  |
| Computer Aided Dispatch  | CAD  | ITS (Intelligent Transportation Systems) 
Bottom of Form |

- And the list goes on ...

## System RepositorySystem information

## System RepositoryContact information

_**System Repository**_Contact information

## System RepositoryInterfaces

_**System Repository**_Interfaces

## System RepositorySystem components List

_**System Repository**_System components List

## System RepositorySystem component information

_**System Repository**_System component information
- Note: Production, test and development environments or tracked.

## Hardware ViewServers by Application

## Hardware ViewComponents Loaded on a Server

## Change Management

- The Process

## Configuration Establishment/Identification

- Theoretical “CM” process describes this as following:
- To establish the CM infrastructure in order to ensure integrity and consistency in the various versions of the configuration items delivered.
- To formalize a CM plan.
- In practice ODOT:
- Establishes what elements go to which repository though policy and procedure.
- Does not commonly create CM plans on a project level.
- Creation of the elements are established in the development and maintenance processes.
- Each component type has naming conventions.  Not all elements have formal naming conventions.

## Accounting & Change Management

- The Theoretical “CM” process describes this as:
- Implementing changes
- Tracking the changes to the system
- In practice ODOT uses:
- SCM requests to track and control source code and project documentation
- Change requests to document implementation changes to the production/test environment

## ODOT SCM 

- What
- Source code
- Project documentation
- Processes
- SCM requests
- Controls
- Program coordinator oversight
- Project office oversight

## ODOT Change Management

- What
- All changes to the IT environment must go through ODOT’s change management process.
- Processes
- Change Request
- Repository Updates
- Logs
- Controls
- All changes are managed and coordinated by ODOT’s ITS maintenance coordinator.  Verifies all standards and practices are met.

## Configuration Audits

- The Theoretical “CM” process describes this as:
- To ensure that developers have followed the CM process with respect to all external obligations.
- To verify that the software items match the configuration item descriptions in the specification documentation, and that the package being reviewed is complete.
- In practice ODOT uses:
- High level testing of each requirement as part of the project.
- Auditing by the project office that the required documentation is complete.
- Review by the Program Coordinator of results.

## Configuration Management

- Support at ODOT

## CM is required by policy at ODOT
Policy IS-002, established in 1999 in response to Y2K
ADM 04-05 System engineering

Primarily an IT policy

- Policy IS-002, established in 1999 in response to Y2K
- ADM 04-05 System engineering
- Primarily an IT policy

## ODOT Policy IS-002 Established 1999IT Configuration Management 

_**PURPOSE:**_
-      To ensure that the integrity of ODOT’s software and hardware assets, and their related components, is protected and effectively managed throughout the product’s life cycle.
_**BACKGROUND:**_
-      In 1991, the Legislature passed Senate Bill 1210. This legislation states*, "Information is a strategic asset of the state which must be managed as a valuable state resource*."  ODOT has an enormous investment in hardware, and created and purchased information software to support the organization’s business processes.  The integrity of these components is vital to the organization.

## CM Policy Goals

_**GOALS:**_
- CM activities are planned for each project
- Configuration components are identified, maintained in a controlled repository, and made available as needed
- Changes to established configuration components are controlled
- Affected groups and individuals are aware of baseline content, the status of configuration data, proposed changes, and how to access this information

## Policy Guidelines

- Establish and maintain CM processes and procedures to ensure software and hardware assets, and their related components, are protected and effectively managed throughout their life cycle
- Assign responsibility for CM for each project or product
- Ensure CM is implemented and utilized throughout the product’s life cycle
- Ensure configuration component baselines and CM activities are audited on a periodic basis

## Key Factor:

**Strong partnership between ITS and IS.**
- IS leadership realized ITS was coming and planned accordingly.
- IS staffs positions specifically for ITS
- Development
- Field Maintenance
- Project Management
- System Methodology

## Benefits of CM

- You control the system.  Not the other way around.
- You can make changes affordably.
- Reduced costs for future projects
- Reduced costs for maintenance

## Benefits of CM

- How else can you...
- Keep track of
- Dozens of applications
- Over 50 servers
- Several 100 field devices
- While
- Working on 3-6 major software development projects
- Process dozens of maintenance requests
- Dealing with standard IT infrastructure maintenance
- Adding several new devices every month
- Maintaining and updating the field equipment

## Lessons learned

- Partnership with IS is important
- Keep it as simple as you can
- Certain things must be very formal
- Change management into production.
- The people who use the data must be responsible for maintaining the data.

## You know your CM is working if

- You know what applications are installed where?
- You know what components and versions make up your applications.
- When a system has problems maintenance staff don’t waste time looking for documentation.
- When you start an enhancement project to an existing system you have the document you need.
- Existing requirements
- Existing test plans
- Etc...
- Staff doesn’t struggle with implementation of systems.
- Field Staff know the what equipment is installed in what cabinets, so they can take the appropriate spare parts.

## Contact Info

**Chuck Larsen**
- Oregon Department Transportation
- Intelligent Transportation System Program Coordinator
- Phone: 503 986 3676
- Email: _[Norman.c.Larsen@odot.state.or.us](mailto:Norman.c.Larsen@odot.state.or.us)_
- www.tripcheck.com