T3 Webinar:

Approaches for Integrating Configuration Management into Your ITS Project Development Processes

February 21, 2008

Text version of Webinar presentation:

"Approaches for Integrating Configuration Management into Your ITS Project Development Processes"

Description of image or images on a slide contained in brackets.

Back to Webinar Files

Slide 1: Configuration Management T3 Webinar

Chuck Larsen
ITS Program Coordinator
Oregon Department of Transportation

Slide 2: Outline

Configuration Management (CM) at ODOT

Our repositories
Configuration Identification (more formal)
Change Management
Accounting
Audits (less formal)

Support for CM
Benefits & Lessons Learned

Slide 3: 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.

Slide 4: CM Repositories at ODOT

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

Slide 5: Project Documents

[Screen shot of Windows-based project directory. Shows folders and subfolders. ]

Slide 6: Project Documents Include

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

Slide 7: Source Code Management

[Screen shot of Windows-based project directory. Shows folders and subfolders. ]

Slide 8: Requirements Repository (Doors)

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.

[Image of Requirements Repository. ]

Slide 9: Hardware/Software

[Image of IT System Menu. ]

Slide 10: System Repository: System Information

[Screen shot of system information in System Repository in TripCheck Traveler Information Portal. ]

Slide 11: System Repository: Contact Information

[Screen shot of contact information in System Repository in TripCheck Traveler Information Portal. ]

Slide 12: System Repository: Interfaces

[Screen shot of interfaces in System Repository in TripCheck Traveler Information Portal. ]

Slide 13: System Repository: System Components List

[Screen shot of system components list in System Repository in TripCheck Traveler Information Portal. ]

Slide 14: System Repository: System Component Information

[Screen shot of system component information in System Repository in TripCheck Traveler Information Portal. ]

Note: Production, test and development environments are tracked.

Slide 15: Hardware View: Servers by Application

[Screen shot that show names of servers running different applications. Lists servers by Production, Test, Development, and Backup environments.]

Slide 16: Hardware View: Components loaded on a server

[Screen shot that show names of installed devices loaded on a particular server. Displays System name, environment, and component name. ]

Slide 17: Change Management

The Process

Slide 18: 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.

Slide 19: 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

Slide 20: ODOT SCM

What

Source code
Project documentation

Processes

SCM requests

Controls

Program coordinator oversight
Project office oversight

Slide 21: 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.

Slide 22: 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.

Slide 23: Configuration Audits

Support at ODOT

Slide 24: Configuration Audits

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

Slide 25: 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.

Slide 26: 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

Slide 27: 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

Slide 28: 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

Slide 29: 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

Slide 30: 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

Slide 31: 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.

Slide 32: 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.

Slide 33: Contact Info

Chuck Larsen
Oregon Department Transportation
Intelligent Transportation System Program Coordinator
Phone: 503 986 3676
Email: Norman.c.Larsen@odot.state.or.us
www.tripcheck.com