Baseline. A Baseline is a Configuration
Identification term formally designated and applicable at a specific point in
an items life cycle. A version of a piece of software, which has been
benchmarked, is re-creatable, and controlled in a configuration management
system from which all changes are measured against. Baselines, plus approved
changes from those baselines, constitute the current configuration
identification.
Center. A Transportation Management Center participating in the Interim C2C project.
Center to Center. The project named to define
the exchange of information among Transportation Management Centers. In this
case, the Interim C2C project.
CMP. Configuration Management Plan
Configuration. The functional and/or physical
characteristics of hardware/software as set forth in technical documentation
and achieved in a product.
Configuration control. The systematic
evaluation, coordination, approval/disapproval, tracking, and dissemination of
proposed changes and implementation of all approved changes in the
configuration of any item after formal establishment of its configuration
Baseline.
Configuration Control Board (CCB). A board
composed of technical and administrative representatives who review and
authorize changes to an approved baseline.
Configuration identification. The current
approved or conditionally approved technical documentation for a configuration
item as set forth in specifications, drawings, and associated lists, and
documents referenced therein.
Configuration item (CI). A configuration item
is an aggregation of hardware, software, or communications equipment, that
satisfies a discrete end use function and is designated for separate
configuration management.
Hardware/Communications configuration item (HCCI).
A specific CI which is an aggregation of hardware and communication items that
satisfies an end use function and is designated for separate configuration
management. This aggregation includes documentation and other artifacts
associated with the HCCI that are essential to the operation and maintenance of
the HCCI.
Interface Control Document (ICD). The
definition of interfaces for the Interim Center to Center system.
Life cycle. The phases a software product
goes through between when it is conceived and when it is no longer available
for use. The software life-cycle typically includes the following: requirements
analysis, design, development, testing (validation),
installation, operation, maintenance, and retirement.
Problem Report (PR). A report to the CCB
detailing problems or errors encountered in the Interim C2C system.
RTMC. The Bay Area’s Regional Transportation
Management Center, which is one of the Centers participating in the Interim C2C
project, and includes the TravInfo® TIC and Caltrans TMC)
System Change Request (SCR). A proposed
modification to the baseline of the Interim Center to Center (C2C) System
(SWCI(s)) that is to be managed by the Change Control process.
Software configuration item (SWCI). A specific
type of CI that relates to a software item that is identified for configuration
management. SWCI may be documentation, data, or other artifacts that are
created or procured as part of the software development lifecycle.
Status accounting. The process of documenting
and tracking the correct approved actions/status of the system, including a
historical record of the development of CIs and all approved changes.
This Configuration Management Plan (CMP) is a tool used to
establish the overall approach for the Configuration Management requirement for
the Interim C2C system. The scope of this plan extends to Software
Configuration Items (SWCIs) developed or implemented for the system’s life
cycle. The CMP will be a dynamic document, and will be updated as work on the
Interim C2C System proceeds and the necessity arises.
PB Farradyne shall maintain this plan at the behest of the
CCB for the Interim C2C system, and will use the ProjectSolve web site
initially developed for the TravInfo® project to store and provide access to
the C2C System Configuration Management documents.
The purpose of this document is to identify and describe the
overall policies and methods for the Configuration Management (CM) activities
to be used during the system life cycle of the Interim C2C system, including
SWCIs comprising data interfaces, and will be updated progressively as the work
proceeds and the necessity arises. The primary intention of this CMP is to
provide overall information on the Configuration Management policy and methods
to be adopted and implemented for the Interim C2C project including:
submitting, planning, approving, and implementing changes to participating
Centers’ C2C software, ICD, DDI, message sets, and communications system.
Configuration Management includes maintenance of inventory
lists, and includes the following:
- Lists, IDs and definitions of
Center-to-Center messages must be in a strict configuration management in
a Center-to-Center system. All Centers must agree on the common messages
they will be sharing
- Rules for device naming must be
agreed on by all centers. The rules must be flexible enough for all
centers to be able to name their own devices, but strict enough to prevent
naming conflicts.
- Rules for identifying roads and
link segments must be defined and enforced. Each road segment must have a
mechanism of identifying it.
- Rules for assigning IDs to
incidents must be defined and enforced
- Rules for assigning unique ids
to each agency must be defined and enforced, and each agency must have a
unique id.
- Rules for assigning unique ids
to workstations and operators must be defined and enforced
The Configuration Management Plan identifies the items to be
managed, the methods by which they are managed and the control processes
necessary for coordination and control. The Configuration Management Plan
focuses on directing the following actions:
- Configuration management actions in support of the ICD.
These are actions taken to make certain that any future changes to the
ICD, or development of future C2C functionality beyond the Initial Build,
follow approved configuration management guidelines. One example is to
identify changes desired by a subset of the involved agencies that could
affect overall C2C Operations, and gain approval before such changes are
made. This will ensure the developed system meets requirements and
continues to support all users.
- Configuration management actions in support of the
communications network used in C2C data exchange.
- Formally document problems associated with the functional
interface and the communications network, as reported by users, and
additional or changed requirements (e.g., suggested enhancements).
The Interim C2C project scope of work requires the
development of a Configuration Management Plan (CMP). The CMP will describe
the overall technical and administrative direction and control for the Interim
C2C system during the total system life cycle, including operational phases.
The following provides a summary of each section contained within this
Configuration Management Plan.
·
Section Introduction identifies, describes the purpose,
introduces the objectives, and summarizes the contents of the document.
·
Section Referenced Documents lists the referenced
materials to which this document refers for further information.
·
Section Configuration Management outlines and describes
the project’s Configuration Management practices, which are based on the
generally accepted industry standards in manufacturing and software
development.
·
Section Configuration Identification identifies the
Baselines and the Configuration Items (CIs) comprising the Baselines.
·
Section Configuration Control defines the policies and
methods used to establish and control the Configuration Items identified in
section 4 by the formally constituted Configuration Control Board (CCB).
·
Section Configuration Management Status Accounting describes
the plans for status accounting, which track changes and document them for
historical reference.
The application of this CMP shall be as follows:
·
Initial implementation and changes to the Interim C2C system
(comprised of software assets and communications system) will be implemented in
a controlled manner via a CCB.
·
The aim is to keep the number of configuration changes to a
minimum, and in this context it must be kept in mind that technical or
engineering feasibility are not in themselves sufficient grounds for change
authorization.
The CMP is a living document and as a result additions,
deletions, and modifications will occur as it is utilized. It will be updated
as additional configuration activities are defined as the work proceeds and the
necessity arises. Changes to this document after acceptance of the initial
version require approval of the CCB.
The following documents serve as reference materials for the
creation of the Configuration Management Plan:
·
Memorandum of Understanding for the San Francisco Bay Area
Interim Center-to-Center Program (January 4, 2005)
·
Interim Center to Center Interface Control Document (ICD) – Final
– July 7, 2004
·
Interim Center to Center Detailed Definition of Interfaces –
Final March 22, 2004
These documents can be
provided by PB Farradyne upon request until a ProjectSolve2 website
is implemented for the project to share documents among participants.
Configuration management is a systems development discipline
that promotes the proper identification of the configuration, control of
changes, and records the change implementation status of the physical and
functional characteristics of the Interim C2C system.
Configuration Management identifies what is required,
designed, and produced. It also provides for the evaluation of changes
including effects on technical and operational performance. This leads to
making the configuration visible and understood by all the parties involved
with the project.
Configuration management will be performed by participating
Centers at the Configuration Item level for SWCI(s) as explained in the Configuration Identification section. Entities developing software for use by Centers
(e.g., Centers, PB Farradyne, and IBI) will maintain baselines of released
software.
Configuration management covers three basic essential
interdependent activities:
1. Configuration
Identification – Configuration identification is for the formal step of
identifying the configuration of an item (i.e., name, location, version), and
documenting its’ functional and physical characteristics.
2. Configuration
Control – Configuration control is the exercising of established procedures
to classify, approve or disapprove, implement, and confirm changes to the
agreed upon specifications and baselines.
3. Configuration
Management Status Accounting – Configuration accounting is the formal
recording and reporting of data relating to configuration identification,
approval status of proposed changes, and implementation status of approved
changes during all phases of the project. These three activities will be
described in more detail in the following sections.
Configuration management is therefore the
means through which integrity and continuity of the system’s design, and
decisions made regarding technical performance, producibility, operability, and
supportability are recorded, communicated, and controlled.
When requested by the Interim C2C CCB or MTC, Formal
Configuration Audits will be performed to determine compliance with
baseline specifications. These audits should be performed by suitably
qualified personnel who will certify all the Interim C2C system CI(s).
Each participating Center is responsible for implementing
adequate backup and recovery activities. Backup and disaster recovery are vital
support components for any configuration management strategy. Backups apply to
development and production systems and will be performed in order to minimize
the risks associated with natural occurrences such as terrorist attacks, power
failures, fires, and earthquakes as well as human error either of which may
result in the loss of critical files, data, or functionality.
Disaster recovery is the implementation of a specified plan
that directs the computer system recovery process in the event of an
interruption of service due to a planned or unplanned event such as the natural
occurrences listed above. Disaster recovery applies to both the development
and production systems in participating Centers. Disaster recovery for the
development system will be handled through standard disaster recovery processes
in place at organizations that develop software for the C2C system (e.g.,
Centers, PB Farradyne, and IBI). For the development system, workstations and
servers should be built from a standard development system image (ghosted and
stored for recovery), source code and other development artifacts shall be
checked in and out on a periodic basis determined by the development
organization, nightly/weekly/monthly backups are performed with the daily
backups stored in a fire proof safe and the monthly backups stored off-site.
Development lab hardware is all ghosted and backed up in the same manner.
It is a firm objective that this Configuration Management
Plan shall apply through all the system life cycle phases of the Interim C2C
project which began with the requirements phase through the production and
maintenance phases and to the systems retirement phase.
Appropriate baselines are established at the start of the
development phase and are applied to each Configuration Item.
For SWCI(s) created during the development phase, all
development organizations shall implement software configuration management
procedures which will be fully compatible with and subject to this CMP. Once
becoming available for release to the system (that is, successful completion of
the Acceptance Test), the developed SWCI(s) will be subject to the change
methods and procedures outlined in this CMP.
Configuration identification consists of setting and
maintaining baselines of each individual Configuration Item (SWCI) that define
the Interim C2C system at any point in time. Depending on the system life
cycle phase, different baselines are progressively established. Details of
each baseline established throughout the system life cycle shall be maintained.
The objective of establishing a baseline is to define a
basis for further system life cycle process activity and allow reference to, control
of, and traceability among configuration items and to requirements. It serves
as the common reference that all system development activity is built on and
dictates to the development team the changes that are to be implemented.
·
Baselines shall be established for the configuration items.
Developmental baselines will be established to aid in controlling the software
development life cycle processes.
·
A Production baseline shall be established upon implementation of
the first phase of the Interim C2C system. Further changes to the Production
baseline require review and approval by the C2C CCB.
Baselines are established in a system development effort to
define a formal departure point for controlling future changes that affect
performance or design. A baseline, once defined and approved, is placed under
CM, after which any changes in the baseline should be formally documented and
approved. Each package build should have a unique release label. Product
baselines should be reviewed and approved with an approval memo and attachments
for the description of any discrepancies that are part of the release.
The following items should go in each center’s baseline
- All C2C related requirement documents
- All C2C related design documents. At a minimum these
should contain:
- All Messages that the center will publish
- All Messages that the center will subscribe to
- Field by field description of how the published messages
will be populated
- Field by field description of how received messages will
be used by the center
- Description of actions taken upon receipt of “request”
messages
- All C2C related test plans and test plan results
- All non proprietary development code required to build the
C2C components
- All C2C related data and configuration files
Refer to the ICD for details of allowable messages and rules
for creation of C2C specific data fields, such as IDs.
SWCI(s) shall consist of commercial-off-the-shelf (COTS)
products, custom software developed by Centers choosing to develop their own
software, PB Farradyne, and IBI, documentation, and other software development
tools associated with the software build environment required to build a
specific baseline. COTS software can be from subcontractors or of the “shrink
wrap” variety (not developed by a participating Center or vendor) and shall be
tracked as SWCIs. The software development tools include COTS products such as
compilers, editors, and design tools and any custom tools, data files, and
development scripts required to build a particular baseline. All the software
development tools will be tracked as SWCIs by development organizations
developing software for the Interim C2C system.
Software developed by Centers, PB Farradyne, and IBI shall
be managed and controlled through a version management tool, with each CI being
minimally uniquely identified by its path, file name, and version number. One
example of how each Configuration Item (CI) can be named has been adopted for
internal use within TravInfo®. The TravInfo® internal naming scheme
is as follows:
[Product]_[Component]_[Baseline
Type]_[Major Level]_’.’_[Minor/Revision]_
For example:
(<Project>_DD_SRAS_3_0).
Additional
information may be incorporated as necessary
where:
_ is a concatenation operator
Product = TI (Abbreviation for
<Project>)
Component =
<Component Abbreviation>
<Component
Abbreviation> – <Component Abbreviation Desc>
Baseline Type = Defined in table
below
Other types may be added as
needed. These may be coupled (i.e. TI_WD_SYS_1.0 for <Project> WatchDog for
Systems Testing).
|
Abbreviation
|
Type
|
Meaning
|
|
SRAS
|
Software Work Product
|
System Requirements Allocated to Software
|
|
SDP
|
Software Work
Product
|
Software
Development Plan/Process
|
|
SRS
|
Software Work Product
|
Software Requirements Specification
|
|
SDD
|
Software Work Product
|
Software Design Document/Description
|
|
INT
|
Software Work Product/Code
|
Integration Build
|
|
SYS
|
Software Work Product/Code
|
Systems Testing Build. Conducted for Software Systems
Testing as defined in the PBF Integrated Software Process (ISP)
|
|
PROD
|
Software Work Product/Code
|
Production Delivery. Conducted for Installation as defined
in the PBF Integrated Software Process (ISP)
|
Each Center shall have responsibility for establishing the
initial Production baseline of all HCCIs affecting the communications network.
Configuration control covers the evaluation of all Change
Requests and Problem Reports and their subsequent approval or disapproval.
This includes providing methods and procedures for the systematic proposal,
justification, evaluation, coordination, and approval or disapproval of
proposed changes to the Interim C2C system.
The following outlines the method to avoid the possibility
of a change being implemented without due consideration of its effect on the
baselines, including logistics impact, costs, schedules, performance, or
interface with any associated Center or vendor.
To enable the configuration control process to operate
correctly and effectively, it is necessary for the CCB to oversee changes
having the purpose of:
·
Providing the relevant information for best decisions on changes
to be made;
·
Determining and implementing decisions;
·
Reviewing and controlling changes in accordance with policy
established by the CCB.
In order to provide a central repository from which to
manage the change control process, a collaborative tool such as the
ProjectSolve2 website is recommended (see section Tools). The ProjectSolve2 shall be used for the following purposes:
·
Provide a platform in which participating Centers may access
developed software, interface definitions, and interface control documents;
·
CCB agendas and minutes which document decisions and policy;
·
Any policy or procedural documents;
·
Test plans, procedures, and results;
·
Submit change requests, repose approved and declined requests and
changes pending CCB approval, and implemented changes.
The configuration control process provides for an orderly
incorporation and documentation of approved changes to the formal configuration
baseline. Changes can originate as enhancements to existing functionality,
hardware problem reports, software problem reports, or notifications of
necessary hardware or software upgrades and/or patches that may impact the
Interim C2C system. Note that there are three types of change requests that
may be submitted. These are outlined within this section and example forms are
detailed in Error! Reference source not found.. One form will be used
to capture the change requests and problem reports. The three types of reports
are defined below:
- Software Change Request (SCR)
- This will document the nature and functional requirements
addressed by a proposed change to the software or Interface Control
Documents. Requests may be made by participating Centers or MTC. The
process utilized to review, deny, or approve the change is outlined by
the form structure and the basic procedure outlined below.
- Problem Report (PR)
- Problem reports will be the basic mechanism for centers
to report data or functionality problems;
- Maintenance Change Request (MCR)
- Regular and periodic upgrades to COTS products needed to
keep the system operational.
Proposed changes to the Interim C2C System are to be
submitted in writing or softcopy to the CCB for approval (see Error! Reference source not found.). Note that in the following process, the CCB may
designate a person to coordinate information prior to a CCB meeting. CCB
meetings can be scheduled or held at periodic intervals (e.g., the third
Tuesday of each month) as determined by MTC. The process for submitting a
change request follows:
- Submitter completes an Interim C2C Change Request (CR)
Form and posts it to the appropriate area of the collaboration tool.
Optimally, the collaboration tool will notify CCB members via email when
changes are submitted;
- Prior to a CCB meeting, a member of the CCB or designate
will collect together SCR/PR/MCR forms not yet addressed to determine
whether further information is needed and from who;
- The designate will coordinate with submitters to ensure
any further information is acquired prior to the CCB meeting;
- The designate will distribute information to CCB members
prior to meeting;
- A CCB meeting is scheduled;
- The CCB meets in person or via phone conference and
determines the disposition of open (i.e., reports not yet addressed)
CR(s), PR(s) and MCR(s);
- The CCB designate documents CCB major decisions in meeting
minutes and the final disposition of CR(s), PR(s) and MCR(s) ensures the
disposition and other relevant comments are reposed with the report in the
selected repository;
- A CCB designate, if necessary, notifies CR/PR submitters
of the final disposition.
Before a change to a CI is implemented in the Production
version of the Interim C2C system, the CCB will review all test results from
acceptance testing to ensure all functional requirements are met and have been
adequately tested. The review will make sure that adequate evaluation of the
affect of the change is performed in advance and a recovery strategy to restore
the system to pre-change condition is clearly identified. The test results
shall be provided to the CCB minimally one week prior to the CCB meeting.
Additionally, the CCB may request an audit to be conducted by PB Farradyne or
other designate to ensure that the new release contains all of the agreed upon
changes and documentation updates.
The primary purpose of Configuration Control Board is to
review and approve proposed changes to the Interim C2C System (e.g.,
functionality, ICD, communications network) by involving the core parties that
are interested in or impacted by proposed changes. The CCB shall consist of
representative personnel from MTC and representatives from participating
Centers. MTC will set the initial agenda and schedule for CCB meetings. Voting
members of the CCB are representatives of MTC and participating Centers. The CCB
consists of representatives from the following Centers, Regional TMC(s), or
vendor organizations:
|
Name
|
Organization
|
Project Role
|
Status
|
|
|
MTC
|
Sponsor
|
Voting
|
|
|
Silicon Valley - ITS
|
Participating Center
|
Voting
|
|
|
SFgo
|
Participating Center
|
Voting
|
|
|
Caltrans
|
Regional TMC
|
Voting
|
|
|
I-580 Smart Corridor
|
Participating Center
|
Voting
|
|
|
TravInfo®
|
Regional TMC
|
Non-voting
|
|
|
CCB designate
|
Collect, distribute information for CCB and repose minutes
and CR/PR disposition
|
Non-voting
|
|
|
PB Farradyne
|
Software vendor
|
Non-voting
|
|
|
IBI
|
Software Vendor
|
Non-voting
|
Each Configuration Control Board meeting will have an agenda
and minutes. The general agenda will include status reports from development
efforts, change requests, and problem reports received from operations (i.e.,
centers exchanging data). Minutes will be kept which identify decisions and
approvals made during each Configuration Control Board meeting as well as
requests for future agenda items.
The Configuration Control Board will coordinate the
deployment schedule for new software at all centers, and the schedule for
integrating new centers into the system.
A CCB meeting may be held after completion of acceptance
testing with software vendors and participating Centers and prior to the
release into production of the initial release of Interim C2C software. At
that meeting, CCB members would review the results of the acceptance testing to
determine whether to “Go LIVE” with the initial release of the Interim C2C
System. If the change is approved, the CCB would select a “Go LIVE” date.
Otherwise, the CCB would document the changes or clarifications required before
approval would be granted.
If any center wishes to join the Bay Area C2C, it would need
to issue a formal request to the CCB for admittance. The request must include:
- Data the Center can provide.
- Data the Center would like to receive
- The expected volume and frequency of data to be exchanged
Configuration management status accounting provides the
necessary reporting mechanism to ensure the integrity of the Interim C2C
System’s configuration at any time. With proper configuration management
status accounting, the current and previous configurations of the Interim C2C
system can be reported to the CCB and managed appropriately.
The project or CCB will need to decide upon two basic tools
for managing CM activities: 1) PB Farradyne recommends the web based
collaboration tool ProjectSolve2 which facilitates posting
documents, source and object code, data files…etc as well as host a web enabled
database tool such as the one defined in item number 2, which follows; 2) a
database system to repose SCR(s), PR(s), and MCR(s) submitted by Centers or the
MTC, preferably a web enabled tool that can be centrally located and accessed.
This later item does not need to be a high powered DBMS. There are many low
cost solutions for this type of simple database requirement. The Technical Working
Group accepted PB Farradyne's recommendation to store the SCR(s), PR(s) and
MCR(s) in a Microsoft Access Database to be stored on the ProjectSolve site.
Configuration management status accounting for source code
SWCI(s) developed by PB Farradyne, IBI, or a Center shall be stored in a
version management (VM) repository. VM tools such as CVS, PVCS, Telelogic CM
Synergy, or Visual Source Safe are examples of a VM repository. A VM tool such
as these allow for managing and controlling access to multiple versions of an
object or file such that each is identified by a unique SWCI identifier which
includes version numbers and disallows or inhibits changes to the same SWCI
version by more than one person or process. The selection of specific VM tools
by a center is outside the scope of this project. VM tools are listed here as
examples of tools that can be used by organizations that develop C2C
applications; and which groups are required to utilize a VM tool within the
development lifecycle.
Unless specifically requested by the MTC or CCB,
configuration audits are not intended to be part of this plan. If desired,
appropriate staff may be contracted to perform this function.
Through use of version management tools, software
development vendors or Centers developing their own software will be required
to produce reports of the content of any pending, current, or prior version of
the baseline. Baseline reports may be made available via the collaboration
tool at the behest of MTC or the CCB.
