CM Process Description

Com MN PG Radio Access Networks
Procedure
Configuration Management Process Description
A1R19361 DS:02 SC:435
For internal use only
Date: 10.01.2006
Procedure Configuration Management Process Description
Copyright Siemens AG 2006
Issued by the
Siemens AG Com Mobile Networks
St. Martin-Strasse 76
D-81541 Munich
Responsible for updating: (Tiziana Vimercati, Umberto Pesce, Milan, Tel. 0224377211)
Subject to technical changes.

Technical specifications and performance features are binding only insofar as they are specifically
and expressly agreed upon in a written contract.
The file name of this document is: "CM Process Description v2 060110.doc".
It is based on the "Standard WORD Template for PEPP Working Level Process Documents.
Page 2 of 27 10.11.2005 A1R19361 DS:01 SC:435

For internal use only Copyright Siemens AG
Contents
0 Preamble ...................................................................................................4
0.1 Scope ............................................................................................................. 4
0.2 Applicability................................................................................................... 4
0.3 Document management ............................................................................... 4
0.4 History ........................................................................................................... 4
0.5 Responsibility ............................................................................................... 4
1 Position within PLP Process Structure ..................................................5
2 Process Overview ....................................................................................7
3 Process Sections Description.................................................................9
3.1 Configuration Management Strategy........................................................... 9
3.1.1 First Issue of the CM Plan (B130) ...........................................................................9
3.1.2 Final Issue of the CM Plan (B200).........................................................................10
3.1.3 Planning CM activities ...........................................................................................10
3.2 Configuration Management Control .......................................................... 11
3.2.1 Establish Baselines................................................................................................12
3.2.2 Establish Integrity...................................................................................................17
3.2.3 Track and Control Changes...................................................................................19
4 References ..............................................................................................26
ANNEXES.........................................................................................................27
A Abbreviations..........................................................................................27
A1R19361 DS:01 SC:435 10.11.2005 Page 3 of 27

Copyright Siemens AG For internal use only
0 Preamble
0.1 Scope
The aim of this document is to provide a detailed process description for configuration manage-
ment activities according to PPP: D Process for Radio Access Networks [1] in conformance with
CMMI requirements.
0.2 Applicability
The directions provided in this document apply to Com MN PG R, Com CRD RA and any other
organization involved in product development on behalf of Com MN PG R.
The document is applicable to external projects (i.e. projects delivered to customers). It can be
applied to internal projects as well, specifying in the relevant project Configuration Management
Plan how it is applied.
0.3 Document management

Document regulation is described in [2].
Computer-generated printouts are only ever provided for information purposes and are not in-
cluded in a change service! Copies provided for information purposes are not labelled as such.
0.4 History
DS 01, 10.11.2005 AFI Version, first issue
DS 02, 10.01.2006 IUS Version, after review
0.5 Responsibility
This document is under responsibility of Siemens Com CRD DT.
Page 4 of 27 10.11.2005 A1R19361 DS:01 SC:435

1 Position within PLP Process Structure
Figure 1: PLP: Product Lifecycle Process Structure
A1R19361 DS:01 SC:435 10.11.2005 Page 5 of 27

B130 B200 B500 B600 B700

D300 D400 D500
ANALYSIS
HARDWARE
DEVELOPMENT
P
r SOFTWARE
o DEVELOPMENT
Cc
oe SYSTEM
r s INTEGRATION
es SYSTEM
e TEST
s
CUSTOMER
ACCEPTANCE
PRODUCT QUALIFICATION
O&M DOCUMENTATION DEVELOPMENT
PROJECT MANAGEMENT
P
Sr QUALITY MANAGEMENT
uo
CONFIGURATION MANAGEMENT
pc
pe CHANGE MANAGEMENT
os FAULT MANAGEMENT
r s
t e TECHNOLOGY MANAGEMENT
s
CONTINUOUS PROCESS IMPROVEMENT
Figure 2: PPP:D: Process Structure
Configuration Management is a support process inside PLP/PPP:D Process Structure. [1]

This process starts before B130 and Configuration Management activities are performed until
B900.
Page 6 of 27 10.11.2005 A1R19361 DS:01 SC:435

2 Process Overview
Configuration Management is the PLP PPP:D support process of identifying the components
that comprise system configurations, controlling those components and changes to them
throughout the system lifecycle, recording configuration status and history information, and pro-
viding configuration auditing
The purpose of the Configuration Management Process is to guarantee a homogenous and
methodical style of work within the project for all items under Configuration Control. It defines the
application of administrative and technical procedures throughout the product life cycle.
The Configuration Management Process takes into account the fact that configuration item types
are heterogeneous and require different configuration management activities. All configuration
items are identified by a unique code, author, date of issue, version etc. in order to allow any
time traceability, validation and retrieval.
Examples of configuration items are:
Documents (e.g. Feature Sheets, Functional Specifications, Interface Specifications, Design
Specifications, Test Specifications, O&M Documents).
SW-items (e.g. source code modules, libraries, tools, scripts, rules, executables).
HW-items (e.g. boards, racks)
In particular HW Configuration Management monitors the HW life cycle based on a HW
Status definition, identifying different main consolidation levels of the HW which extend be-
yond the PPP:D.
The main activities belonging to CM process are:
Define, identify and manage configuration items
Control, record and report status/version of configuration items
Ensure the formal completeness, consistency and correctness of the configuration items
Archive, store, provide and distribute configuration items
Obtain derived items through the definition and application of production rules (e.g. executa-
bles)
Ensure the re-producibility of all derived items for a time period fixed according to internal
and/or external requirements

B130 B200 B700
Configuration
Management
Strategy
Configuration Management Control
Figure 3: Configuration Management Process Overview

As shown in Fig.2 the process is split in the following sub-processes:
A1R19361 DS:01 SC:435 10.11.2005 Page 7 of 27

Configuration Management Strategy: it is the sub-process during which all the Con-
figuration Management activities are established and planned. The output of the
planning activity is the CM plan which is ready as a first issue at B130 and updated at
B200.
Configuration Management Control: it is the sub-process during which the CM system is
defined and all the Configuration Management activities are performed.
Page 8 of 27 10.11.2005 A1R19361 DS:01 SC:435

3 Process Sections Description
3.1 Configuration Management Strategy
Configuration Management Strategy

B200
from PLP:
Feature List to all PPP:D processes:
Feature Request Sheets NEy Configuration Management Plans [CMR]
from Project Management:
to Quality Management:
Project Folder
Contribution to NEy Quality Plans [CMR]
from Technology Management:
Technology Evaluation Report
Figure 4: Configuration Management Strategy
The purpose of the Configuration Management Strategy is to identify the activities required for
the Configuration Management for a specific project, to identify and establish the tools to ac-
complish Configuration Management activities, to define a scheme for identification, versioning
and control of all Configuration Items within the project and to plan necessary resources.
The CM Strategy process consists in three main sections:
Issue a first version of the Configuration Management Plan at B130.
Issue the final version of the Configuration Management Plan at B200
Plan the Configuration Management activities.
The standard template for Configuration Management Plan documents is reported in [3], where
the typical table of contents is provided, including the description of each chapter and paragraph.
3.1.1 First Issue of the CM Plan (B130)
The CM Plan document is prepared and released in a first issue at B130. The contents of the
document is based on CM company policies and on information contained in the project docu-
mentation before B130 milestone.
In particular the first issue of the CM Plan covers the following topics:
Roles definition and assignment for documentation lifecycle management
Elements under Configuration control
First skeleton of HW/SW/Documentation structure
Naming conventions
Lifecycles for Configuration items/components/units
Change control rules
Status accounting and configuration auditing activities
A1R19361 DS:01 SC:435 10.11.2005 Page 9 of 27

Tooling for the above activities
3.1.2 Final Issue of the CM Plan (B200)
The final issue of the CM Plan is ready at B200. Later only corrective updates can be applied.
In the final issue, besides the topics already covered at B130, the
HW/SW/Documentation/Product structure description is completed.
3.1.3 Planning CM activities
CM activities can be split in two main categories:

Activities devoted to perform the set-up of a CM system for a specific project
Daily configuration management activities
The activities belonging to the former category consist in the definition of the CM system, in the
installation and configuration of CM and development tools and in the development of proprie-
tary tools if required.
These activities are normally performed during the early phases of the development process
lifecycle even though some support tools can be developed and released later, depending on
emerging needs.
In any case, for such activities specific plans are defined, updated and maintained. The plans
are stored and managed into the CM system.
The activities belonging to the latter category consist in the daily configuration management ac-
tivities performed and applied to a specific project. From a planning point of view these activities
are taken into account as milestones in the project development plans. Furthermore into the CM
system information relating the organization and work assignment to resources are stored and
maintained.
Page 10 of 27 10.11.2005 A1R19361 DS:01 SC:435

3.2 Configuration Management Control
Configuration Management Control

B700
Configuration Management Plan
to all PPP:D processes:
from Project Management:
Derived Configuration Items (e.g. SW loads) [CMT]
Project Folder
Configuration Items Repository [CMT]
from SW Development:
HW/SW Stocklist [CMT]
SW Load Plan
Configuration Status Reports [CMR]
from Quality Management:
Contribution to Release Notes [CMR]
NEy Quality Plan
from PLP and PPP:D:

Configuration Items
from Change Management:
Approved Change Requests
The purpose of the Configuration Management Control process is to control formally the con-
figuration item modifications, applying mechanisms for tracing them (history of changes), to
make available reports on status and history of configuration items and to audit their congruence
and completeness.
B130 B200 B500 B600 B700

D300 D400 D500
Establish Base-
Identify Configuration
Establish CM sys-
Create/Release Base-
Establish Integ-
Establish CM Rec-
Perform Configuration
Track and Control
Track Change Re-
Control Configuration
Figure 5: Configuration Control Process Overview
A1R19361 DS:01 SC:435 10.11.2005 Page 11 of 27

As shown in Fig. 5, the Configuration Management sub-process is split in the following sections:
Establish Baselines: set of practices and activities devoted to identify configuration
items, define and establish the Configuration Management System and create, release
and maintain the baselines.
Establish Integrity: this section covers the activities to ensure the integrity of data
stored into the CM system and into the released baselines. In particular accounting and
auditing are typical activities performed in this section.
Track and Control Changes: set of specific practices devoted to control and track
changes to the work products under configuration management across the entire lifecy-
cle.
3.2.1 Establish Baselines
The Establish Baselines sub-process is performed by means of a set of specific practices de-
voted to identify configuration items, define and establish the Configuration Management System
and create, release and maintain the baselines.
3.2.1.1 Identify Configuration Items
General rules for Configuration Items identification

This practice consists in identifying the configuration items, components and related work prod-
ucts that will be put under configuration management.
Configuration identification is the process of identifying and defining the components that build
up a particular configuration. A component in a configuration is referenced by a revision number
that uniquely identifies the level of changes for that component. A configuration item is an ag-
gregation of hardware/software/documentation or any of its discrete portions, which satisfies an
end-use function.
It is an entity designated for configuration management, which may consist of multiple related
work products that form a baseline. This logical grouping provides ease of identification and
controlled access. The selection of work products for configuration management to be based on
criteria established during planning and thus documented in the CM plan.
Configuration items can be broken-down into configuration components and configuration units,
depending on the complexity of the product and on the chosen number of decomposition levels.
Examples of configuration items and related configuration components and/or configuration
units are the following:
SW Configuration Item: computer programs that can be considered as a deliverable en-
tity with a stand-alone lifecycle, e. g.:
o Source code modules
o Derived objects
o Tools (e.g. compilers, linkers)
o Related documentation
HW Configuration Item: physical boards that can be considered a deliverable entity with
a stand-alone lifecycle, e.g.:
o Parts and sub-parts used to logically decompose the HW system
o Each physical component
Page 12 of 27 10.11.2005 A1R19361 DS:01 SC:435
o Related documentation
o Product Documentation
An unique unambiguous identifier has to be assigned to each configuration item and to each
configuration component/unit. A version index is also assigned to identify all the changes applied
to each component through the lifecycle.
Each time a component is modified the version index is updated, so that the revision number
serves to unambiguously define the contents of the component.
The naming conventions adopted both for identification and versioning, established during the
CM Strategy phase, are managed and controlled using appropriate tools and procedures.
In addition to the unambiguous identifier and version other information are stored and managed
for each configuration item/component/unit:
Author/Owner/Responsible
Type
Description
Information relating component evolution (i.e. creation date, update date, status, update
author)
The naming convention definition process is strictly related to the project and can follow different
criteria depending on the types of the item managed under configuration control. It is also related
to adopted company standards.
Specific topics relating configuration item identification for documentation, HW and SW items
are reported below.
Documentation Item naming convention
The definition of the naming convention is driven by the following criteria:
Keeping alignment with the system architecture
Organization of documentation items in a structure related to the foreseen item types,
considering the following categories
o Functional specifications
o Design specifications
o Planning documentation
o Testing documentation
o Feature description documentation
o Working documentation
o Review reporting documentation.
Documentation items naming convention is described into the CM Plan associated to the project
and it depends on the characteristics of the project and of the CM tool used to define and im-
plement the documentation configuration management environment.
HW Item naming convention

Keeping alignment with the system architecture
Coding of the category of the HW parts
Coding of the HW part version.
A1R19361 DS:01 SC:435 10.11.2005 Page 13 of 27

The naming convention rules apply to the following part categories:

HW modules and sub-modules
Printed circuits board
Cabling
Mechanical parts
Baby boards and boards for test
FW devices
MCC (Main Constructions Catalogue) Parts
HW item and related product documentation naming conventions are described into the CM
Plan associated to the project. The adopted naming conventions depend on the characteristics
of the project and of the CM tool used to define and implement the HW configuration manage-
ment environment.
SW/FW Item naming convention

Keeping alignment with the system design and SW design architecture
Keeping alignment with the design documentation structure.
In particular for the SW/FW area the naming convention rules apply to the following object cate-
gories:
Source code modules
Derived objects
Executables/deliverables items
Object patches
SW/FW loads and related baselines (source code frozen configurations).
SW/FW item naming convention is described into the CM Plan associated to the project and it
depends on the characteristics of the project and of the CM tool used to define and implement
the SW configuration management environment.
3.2.1.2 Establish Configuration Management System
This practice consists in establishing and maintaining a configuration management system for
controlling configuration items.
The configuration management system includes the storage media where project libraries and
CM database are archived and the procedures and the tools used for accessing the configura-
tion system.
The following requirements have to be satisfied and the following features ensured:
The CM system must be capable to store and manage all the configuration items and
tools
There must be versioning mechanisms in order to identify changes to all the configura-
tion units and to trace the status of each component version
The adopted CM tools must support and maintain CM libraries and databases
Features for the definition, creation and release of CM baselines must be available
Builds procedures must be designed and managed in order to ensure CM baselines re-
producibility
Page 14 of 27 10.11.2005 A1R19361 DS:01 SC:435
The access to the CM system must be authenticated and users operations shall be gov-
erned on the basis of assigned roles
Features supporting change documentation, status accounting and reporting and con-
figuration auditing activities must be available.
The adopted CM systems must be able to contain and manage under version control compo-
nents currently being created or revised, to contain current CM baselines and changes to them
and to archive CM baselines already released.
It must be always possible to retrieve any archived version of configuration items/components
and to generate and manage reports about their history.
Specific procedures must be set up in order to preserve the CM system and to ensure backups
and restore of configuration management data. These procedures are performed by an external
organization.
The CM System can be different depending on the project and is technically described in details
in the related CM plan.
The process for setting up a CM system is performed each time a new project and/or a new project re-
lease have to be developed. The input for the process is the project starting (at B100) and the
requirements for the CM system are establish and analyzed during the CM strategy process, when the
first issue of the CM plan is produced. The CM system set up activities are planned considering the proj-
ect master plan and are performed in order that the CM system must be ready to host foreseen
documentation, hardware and software items. In particular the CM system must be ready before B130
milestone for documentation items, before B200 milestone for HW and and before D300 for SW items.
3.2.1.3 Create/Release Baselines
General rules for CM Baselines

This activity consists in creating and releasing CM baselines for internal use and for delivery to
the customer.
The term CM baseline is used in this document to identify the snapshot/freeze of a configuration
into the configuration management system.
At defined points in the lifecycle the configuration is frozen to provide a reference point for prob-
lem fixes or further developments. These release points may be actual commercial releases to
a customer or internal releases for development control. When the release is created, the list of
components and their revision numbers are frozen to allow the release to be re-created at any
future time.
A CM baseline is a set of configuration items that has been formally reviewed and approved, that
can serve as the basis for further development and can be changed only through change control
procedures.
A CM baseline implies the assignment of an identifier to a configuration item and to its associ-
ated entities.
The create baseline process is performed in accordance with project plans, not only in connec-
tion with project milestones but considering also incremental CM baselines used to keep
evolving configurations during the product lifecycle.
Criteria established into the CM plan have to be followed in order to select and consider for the
CM baseline generations the configuration items revisions formally approved by the relevant re-
sponsible.
The purpose of the CM baseline is to freeze the selected components revisions and the product
structure to which they belong, in order to provide a snapshot of the system configuration.
In particular for SW parts the CM baseline is used to select the source code files and the related
build procedures needed for executables generations. The freeze of the system configuration
ensures the repeatability of the build process.
A1R19361 DS:01 SC:435 10.11.2005 Page 15 of 27
In order to allow for a later re-creation of a CM baseline, any support tool used to create a re-
lease is frozen as well as the configuration components.
CM procedures are defined and implemented to ensure that the CM baseline is generated con-
sidering only configuration components stored into the configuration management systems.
Utilities are available to audit the correctness, completeness and consistency of the frozen sys-
tem configuration.
A CM baseline can be delivered for internal use (i.e. for testing activities) or to the customer. The
delivery process is performed and traced using appropriate tools and is performed after a formal
approval.
CM Baselines for documentation items

CM baselines for documentation items are generated by SW CM at documentation milestone
planned date.
In particular the following CM baselines are foreseen:
B130 Definition of product
B200 Completion of Analysis phase
D300 Completion of Design phase
D400 Completion of Implementation phase
D500 Completion of HW and SW Development
B500 Completion of System Integration
B600 Completion of System Test
The CM baselines are created considering all the documentation items belonging to the project.
The last approved revisions of the documents are considered.
CM Baselines for HW items

CM baselines for HW items are generated by HW CM when HW parts list and related docu-
mentation are declared ready for Development Release by HWD.
At this stage the parts list and the documentation are frozen and can be available for limited
and/or series production.
CM Baselines for SW items

CM baselines for SW items are generated in order to freeze SW configurations to be considered
for the build process.
The build process consists in the generation of the executable items starting from source code
modules. Build procedures and tools are managed using the same rules adopted for the source
code items, so they are also recorded into the CM baseline. The goal is to ensure the reproduci-
bility anytime of the build process.
The CM baselines are created considering all the source code modules belonging to a certain
configuration. The approved revisions formally released by development teams responsible are
considered.
The output of the build process is the load environment: a CM library where all the source items,
build procedures, derived and intermediate objects and executables are stored. The library is
protected in order to ensure integrity.
SW loads can be divided into two main categories:
Planned loads
Page 16 of 27 10.11.2005 A1R19361 DS:01 SC:435

Planned loads are SW loads generated by SW CM for incorporation of new items revi-
sions created for new features and/or change requests development and for
incorporation of bug fixes (failures raised during Network Entity Integration and System
Integration Test activities). These loads are planned during the SW implementation
phase and testing phases (from D300 to B500). In order to track the various loads and
their content a Load Plan is defined, maintained and communicated to all relevant
stakeholders, in accordance with the rules and procedures defined in the Project Man-
agement Guideline [15]. In the load plan are specified, for each load, the features and
change requests to be incorporated and the fixed bugs.
Corrective loads
Corrective loads are SW loads generated by CM exclusively to introduce corrections to
a SW load previously generated. Corrective loads can be also generated after B500
milestone. In this case the code freeze baseline is generated considering the frozen
configuration associated to the SW load to be corrected and introducing the updated
items revisions containing the corrections produced by designers.
A proper naming convention is defined in order to distinguish planned loads and corrective
loads.
Details about the load generation procedure are described in specific working level docu-
ments. [9] [10]
The delivery process is executed by SW Configuration Management in order to make avail-
able a SW load for testing purposes or for the installation in the field.
The input for the process is the completion of a SW load generation.

Details about the load generation procedure are described in specific working level docu-
ments. [11]
Responsible B130 B200 D300 D400 B500 B600 B700

HW Product Structure HW CM
HW Status
StockList
Configuration Rule
SW SW CM
Documentation SW CM
The following table summarizes the CM baselines foreseen for each milestone and their con-
tents.
3.2.2 Establish Integrity
The integrity of the baselines, established by the Establish Baseline sub-process and main-
tained by the Track and Control Changes sub-processes, is performed by a process whose
activities are described in the following paragraphs.
A1R19361 DS:01 SC:435 10.11.2005 Page 17 of 27

3.2.2.1 Establish Configuration Management Records
This sub-process consists in establishing and maintaining records describing configuration

items. This is performed storing and maintaining a complete revision history for each configura-
tion component.
Furthermore the CM system provides features for the tracking and reporting the status of the
system configuration and its changes and for determining differences between CM baselines.
The information recorded into the CM system is detailed in order to always know the content of a
configuration item and retrieve the entire previous version.
The revision history is a summary of problems fixed and components changed in order to trace
the reasons for changes in HW, SW and documentation. Other information that should be re-
corded and reported includes descriptive information about each configuration component
including the time it came into being, descriptive information about each change including its
purpose, status and author, and descriptive information about each release.
To ensure this a proper configuration status accounting database is designed and implemented
as part of the CM system. The access to information stored into it is controlled via authorization
criteria.
The status accounting process is normally performed in three steps:
Identifying the reporting requirements
This activity is performed as part of the CM system definition and implementation. It is
strictly related to the product release.
Define and implement the status accounting database and the reporting procedures
This activity is strictly related to the choice of the tools for the implementation of the CM
system.
Execution of reporting activities
This activity is planned and specified into the CM Plan associated to the product Re-
lease.
3.2.2.2 Perform Configuration Audits
Configuration auditing is the process of verifying the completeness and correctness of all com-
ponents in a configuration. Completeness involves checking that all required components in a
configuration are produced; correctness involves verifying that the components agree with
specified requirements. Configuration Auditing is intended to increase the visibility of the current
status of the project, and to provide traceability between a product and its requirements through-
out the lifecycle. CM Audit activities and processes are performed to confirm that the resulting
CM baselines and documentation are accurate. Audit results are recorded as appropriate.
Three types of Configuration Audits are foreseen:
Functional Configuration Audits
The purpose is to verify that the development of a Configuration Item has been com-
pleted satisfactorily and that the Configuration Item has achieved the performance and
functional characteristics specified in the functional and allocated configuration baseline.
Functional configuration audits are held at the end of a development cycle, following the
completion of all the testing activities on the items that have been developed.
Examples of foreseen audits are:
Documentation CM baseline verification at ach milestone completion
Page 18 of 27 10.11.2005 A1R19361 DS:01 SC:435

SW load verification.
Physical Configuration Audits

It is a technical examination of a designated Configuration Item to verify that the Con-
figuration Item as built conforms to the technical documentation that describes it. The
reason for this physical configuration audit is straightforward in the hardware environ-
ment. It has been previously verified at functional configuration audit that the item
constructed as part of the development cycle met all the requirements in the specifica-
tions. Now, if the technical data package provide accurate instructions on how to build
identical items, then many, many more of the items that meet those specification can be
produced without the exhaustive testing required for the initial item.
Introductory audit for the release of the product in production (The audit is com-
pleted at the issue of the Release Note).
SW load verification
Project and Product Documentation CM baseline verification
In-Process Configuration Audits
In-process configuration audits are performed to determine whether the configuration
management processes and activities established are being correctly followed and to
ascertain what needs to be improved.
Completeness of the CM baseline contents
Assessment of the integrity of the CM baseline
Review of the structure and integrity of the items in the configuration manage-
ment system
Checking of the completeness and correctness of the items in the configuration
management system
These audits are performed at each CM baseline and appropriate reporting procedures
are available. The results are stored together with timing information into the CM system.
In compliance with the Measurements and Analysis Support Process, metrics for CM Proc-
ess have been defined and related measurements activities are planned and performed.
For more details the reader is referred to [4], [5] and [6].
3.2.3 Track and Control Changes
The Track and Control Changes sub-process is performed with a set of specific practices de-
voted to control and track changes to the work products under configuration management.
3.2.3.1 Track Change Requests
Changes to configuration items can be introduced to satisfy approved enhancement requests or

to solve problems due to failure of an item to conform to specified requirements.
A1R19361 DS:01 SC:435 10.11.2005 Page 19 of 27

In any case changes are analyzed to determine the impacts that the change will have on the
work products, related work products, schedule and costs.
In the PPP:D/PLP process structure two specific support processes: Change Management and
Fault Management, are devoted to cover these topics. Specific procedures describe the project
change requests management process and the fault handling process. These procedures also
describe the organization of the change requests and faults/defects databases.
For more details the reader is referred to [4], [5] and [6].
At the end of the Change Management/Fault Management process the approved updates are
planned to be incorporated into a planned/corrective load. The updates are applied to the con-
figuration items into the CM system and are controlled by CM procedures described below.
3.2.3.2 Control Configuration Items
General Rules to Control Configuration ltems

Control is maintained over the configuration of the work product baseline. This control includes
tracking the configuration of each of the configuration items, approving a new configuration if
necessary, and updating the baseline.
Changes to configuration items and consequently to configuration components/units can be ap-
plied for new features/change requests implementation or for problem/defect fixing. In any case
all the changes are tracked and documented, using appropriate features of the adopted CM
system.
In particular:
Changes to configuration components can be applied by users depending on users
roles and rights access
Check-in and check-out procedures are used for incorporation of changes in a manner
that correctness and integrity are maintained
The changes are always identified via versioning mechanisms
The information about the reason for changes is recorded
Changes are not official until they are released
Changes are formally reviewed and approved before the incorporation in a new up-
dated baseline.
The updates to the configuration items are introduced by designated responsible relevant to the
affected items. The CM system must be able to check this and must impose the creation of a
new item revision. It is mandatory for the author of the changes to record information about
change, (like change description, reason for change, author and date,etc), and to maintain the
change history associated to the item revision.
Depending on the configuration item type specific lifecycles are adopted to manage change
control activities. In general the standard logical lifecycles adopted for documentation, HW and
SW configuration items are reported below. Exceptions to the default life cycles shall be de-
scribed in the relevant Quality Plans and/or CM Plans of the specific development
projects/releases.
Documentation Item Change Control

Changes to documentation items can be caused by the following reasons:
Results of analysis and design activities relating features to be introduced in a new sys-
tem release. (In this case the creation of new documentation items can be foreseen.)
Defects raised during testing activities, highlighting failures affecting analysis and design
phases.
Page 20 of 27 10.11.2005 A1R19361 DS:01 SC:435
The generic lifecycle for configuration items of class documentation is characterised by the fol-
lowing logical states:
UNDER WORK: it is the state associated by the item when it is created by the author(s);
in this state the item can be modified as many times as needed;
UNDER REVIEW: this state corresponds to the completion of the item contents and the
execution of formal verification on it; an item in the UNDER REVIEW state cannot be
modified; if formal verifications are successfully passed, the item is moved to the
APPROVED state by the approver(s), otherwise the item is moved to the
SUPERSEDED state by the approver(s) and a new version of the item is created in the
UNDER WORK state in order to be modified by the author(s) to insert the necessary
modifications;
APPROVED: this state corresponds to a successful verification of the item that is
therefore fully valid and applicable in the relevant context; to insert modifications into an
APPROVED item it is necessary to create a new version of it; when an APPROVED
item is included in a official release to the customer, it is moved to the RELEASED state
by the Configuration Management Responsible;
RELEASED: this state corresponds to a official release of the item to the customer; it is
a final state in the lifecycle;
SUPERSEDED: this state corresponds to a unsuccessful verification of the item; it is a
final state in the lifecycle.
The figure below depicts states, transitions and involved roles.
Under
Work
Author
Under
Review Approver
Approver
Approved CM Technician
Superseeded
Released
Figure 6: Documentation items logical lifecycle
The logical states presented can have different names depending on the CM system adopted
and specific project rules. The specific life cycle shall be described in the relevant Quality Plans
and/or CM Plans of the specific development projects/releases.
The review process is tracked by CM and the review reports are stored and managed into the
CM system.
Hardware Configuration Item Change Control
A1R19361 DS:01 SC:435 10.11.2005 Page 21 of 27

HW Configuration items have a life cycle based on HW Status definition, identifying different
consolidation levels of the HW.
The meaning of HW status and roles responsible for transitions are reported in the following ta-
ble.
Designation Status State of product and documents Role Transition

Responsible
Sample Orders 10 purchase order of material HWD

for sample production could
be instructed. Product documenta-
tion in process.
Pre-Engineering 11 pre-Eng. could be instructed HWD
Sample Production 12 sample production could be in- HWD
structed
Ready for Development 19 documentation completed for devel- HWD
Release opment release
Development Release 21 documentation release by develop- HW-CM
ment,
- start of further release process
- material purchase order for a re-
stricted number of pieces could be
instructed
Limited Edition Release 22 production for a restricted number of HW-CM
pieces could be instructed
Orders Series Production 31 purchase ordering of material for se- HW-CM
ries production according to forecast
Series Production Re- 32 series production according to fore- HW-CM
lease cast
Production Phase out 37 successor issue is released in status HW-CM
32
Stopped for Delivery 40 product must not be delivered any HW-CM
more, but is still valid in field
Cancelled 50 product must not be delivered any HW-CM
more, and is not valid in field
Page 22 of 27 10.11.2005 A1R19361 DS:01 SC:435

10 -
Sample
Orders
11 Figure 7: Documentation items logical lifecycle

Pre-
Engineering
12 -
Sample
Production
19 - Ready
For Develop.
Software Configuration Item Change Control
Release
A1R19361 DS:01 SC:435 10.11.2005 Page 23 of 27
Copyright Siemens AG For21 -
internal use only
Development
40-
Release
Cancelled
Changes to source code items can be caused by the following reasons:

Implementation activities relating features to be introduced in a new system release. (In
this case the creation of new items can be foreseen)
Bug fixing
In any case the updates to the source code items are introduced by the owner of the item and
the updated revision must be formally promoted by a designated responsible related to the af-
fected design area, in order to be considered in an official CM SW load generation. The CM
system must be able to check this and must impose the creation of a new item revision when
changes involve revisions already frozen in a CM baseline. It is mandatory for the author of the
changes to record information about change, like change description, reason for change, author
and date, and to maintain the change history associated to the item revision.
The generic lifecycle for configuration items of class software modules is characterised by the
following logical states:
UNDER WORK: it is the state assumed by the item when it is created by the autho; in
this state the item can be modified as many times as needed; when the item is complete
and syntactically correct is moved to the CODE PRODUCED state by the developer;
CODE PRODUCED: the item in this state is complete and syntactically correct and is
ready for debug and unit test activities; in this state the item can be optionally verified
through the application of code reviews or inspections;
READY FOR CM LOAD: the item has been validated at the unit level and participate to
official load productions that are delivered for the following validation activities (entity,
system integration and system test); the transition to the CM PRODUCTION state is
controlled by the CM technician;
CM PRODUCTION: the item in this state has been successfully included in an official
load production.
The logical states presented can have different names depending on the CM system adopted
and specific project rules. The specific life cycle shall be described in the relevant Quality Plans
and/or CM Plans of the specific development projects/releases.
Configuration items of type software modules can be subdivided in further categories, i.e.:
primary configuration items, that are those produced only by human work (e.g. source
code modules),
derived configuration items that are those automatically produced by the application of
routines, programs (e.g. the executable program obtained from the source modules),
object patches, that are assembly-like source code items, produced by human work,
used to produce pieces of binary code devoted to amend already generated SW loads.
As default the above described lifecycle shall be applied to all categories with the pertinent ex-
ceptions (e.g. an executable program could have CM PRODUCTION as starting state because
both DEFINED and CODE PRODUCED are meaningless).
Furthermore details about management peculiarities of software modules depending on their
categories are described in specific working level documents.
Page 24 of 27 10.11.2005 A1R19361 DS:01 SC:435

Figure 8: Software modules logical lifecycle

Under
Work
SW Designer
Code
Produced SW Designer
Ready for CM Technician

CM Load
CM
Production
A1R19361 DS:01 SC:435 10.11.2005 Page 25 of 27

4 References
[1] IMS: PPP:D for Radio Access Networks Process Handbook, A1R12011
[2] IMS: Regulation of PEPP Process Documents, A1R11401
[3] IMS: Guideline for Configuration Management Plan document, A1R16981
[4] IMS: Electronic Change Request Procedure for SBS, A1R17041
[5] IMS: Error Handling for SBS, A1R17061
[6] A7060-D72-A211-*-35 Gestione Modifiche/Varianti and elementi HW
[7] IMS: Measurement and Analysis Process Description - A1R18911
[8] IMS: Description of CM and SW Support Quality Metrics A1R19371
[9] IMS: Load Generation Process for BSC, TRAU, LMT and OTS A7060-D73-A235-*-7635
[10] IMS: Load Generation Process for BSC, TRAU, LMT using ClearCase A1R19431
[11] IMS: SW Delivery Manual A7060-D73-A236-*-7635
[12] IMS: Object Patch Management W_SBSCM_OBJPATCHMNGT
[13] IMS: Object Patch and Load Delivery Management for SBS Project A7060-D73-A213-*-
7635
[14] IMS: Patch Information Automation A1R16781
[15] IMS: Project Management Guideline A1R17141
Page 26 of 27 10.11.2005 A1R19361 DS:01 SC:435

ANNEXES
A Abbreviations
CM Configuration Management
CMMI Capability Maturity Model Integration
HW Hardware
IUS Inspected, Updated and Stored
PLP Product Lifecycle Process
PPP:D Product Realization: Development
SW Software
TPL Technical Project Leader
A1R19361 DS:01 SC:435 10.11.2005 Page 27 of 27


CM Process Description

Uploaded by

Copyright:

Available Formats

You might also like

CM Process Description

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CM Process Description

Uploaded by

Copyright:

Available Formats

Com MN PG Radio Access Networks

Configuration Management Process Description

A1R19361 DS:02 SC:435

For internal use only

Copyright Siemens AG 2006

Subject to technical changes.

Page 2 of 27 10.11.2005 A1R19361 DS:01 SC:435

A1R19361 DS:01 SC:435 10.11.2005 Page 3 of 27

0.3 Document management

Page 4 of 27 10.11.2005 A1R19361 DS:01 SC:435

1 Position within PLP Process Structure

Figure 1: PLP: Product Lifecycle Process Structure

A1R19361 DS:01 SC:435 10.11.2005 Page 5 of 27

B130 B200 B500 B600 B700

O&M DOCUMENTATION DEVELOPMENT

Figure 2: PPP:D: Process Structure

Configuration Management is a support process inside PLP/PPP:D Process Structure. [1]

Page 6 of 27 10.11.2005 A1R19361 DS:01 SC:435

B130 B200 B700

Configuration Management Control

Figure 3: Configuration Management Process Overview

A1R19361 DS:01 SC:435 10.11.2005 Page 7 of 27

Page 8 of 27 10.11.2005 A1R19361 DS:01 SC:435

3 Process Sections Description

3.1 Configuration Management Strategy

Configuration Management Strategy

Figure 4: Configuration Management Strategy

3.1.1 First Issue of the CM Plan (B130)

A1R19361 DS:01 SC:435 10.11.2005 Page 9 of 27

Tooling for the above activities

3.1.2 Final Issue of the CM Plan (B200)

3.1.3 Planning CM activities

CM activities can be split in two main categories:

Page 10 of 27 10.11.2005 A1R19361 DS:01 SC:435

3.2 Configuration Management Control

Configuration Management Control

from PLP and PPP:D:

B130 B200 B500 B600 B700

Track and Control

Track Change Re-

Figure 5: Configuration Control Process Overview

A1R19361 DS:01 SC:435 10.11.2005 Page 11 of 27

3.2.1 Establish Baselines

3.2.1.1 Identify Configuration Items

General rules for Configuration Items identification

HW Item naming convention

A1R19361 DS:01 SC:435 10.11.2005 Page 13 of 27

The naming convention rules apply to the following part categories:

SW/FW Item naming convention

3.2.1.2 Establish Configuration Management System

3.2.1.3 Create/Release Baselines

General rules for CM Baselines

CM Baselines for documentation items

CM Baselines for HW items

CM Baselines for SW items

Page 16 of 27 10.11.2005 A1R19361 DS:01 SC:435

The input for the process is the completion of a SW load generation.

Responsible B130 B200 D300 D400 B500 B600 B700

3.2.2 Establish Integrity