|
Term
|
Description
|
|
As Built state
|
The baseline
description of a built configuration.
|
|
As Planned state
|
The baseline
description of planned configuration e.g. as planned to be
installed.
|
|
Audit trail/history
|
Auditable
information that records for example what was done, when it was
done, by whom and why.
|
|
Backup
|
A copy of a
working environment, taken on a regular basis to provide
security against disaster or loss.
The lifetime of the backup may be quite short, depending
upon the frequency that the backup copies are taken.
|
|
Baseline
|
See
Configuration Baseline.
|
|
Build
|
The
construction of a Configuration, from its component
Configuration Items. The usually involves some processing or
conversion of the Component Configuration Items (eg. compiling
source code, text processing etc.) inputs to output
Configuration Items eg. executables.
|
|
Category
|
Classification
of a group of Configuration Items, change documents or problems.
|
|
Change
|
The addition,
modification or removal of approved, supported or baselined
business process, hardware, network, software, application,
environment, system, desktop build or associated documentation.
|
|
Change Advisory Board
|
Decisions to
create or change Products should be made by a Change Advisory
Board (CAB). All viewpoints should be represented on the CAB,
especially those of the Buyer and the End User. The CAB should endeavor
to reach decisions by consensus, with reference to
written criteria, although the final decision will rest with one
member, normally the Chairman. The decisions of the CAB should
be logged. For a large Project or Service, more than one level
of CAB may be needed, with major impact problems being passed
upwards from CAB’s managing parts of the development to a
higher level CAB.
|
|
Change Authority
|
A group that is
given the authority to approve change, e.g. by the Project
Board. Sometimes referred to as the Change Review Board or
Change Advisory Board.
|
|
Change Control
|
A formal system for ensuring that all
changes are controlled
-
obtaining approval to make the change
-
reporting planned and emergency changes to
systems/processes
-
evaluating impact
of these changes on the
systems/processes
-
post implementation review of the change
-
final summary
and approval of documentation
|
|
Change Control Board
|
See Change
Advisory Board.
|
|
Change Document
|
Change request,
change control form, change order, change record.
|
|
Change Log
|
A log of change
requests raised during the project, showing information on each
change, its evaluation what decisions have been made and its
current status, e.g. Raised, Reviewed, Approved, Implemented,
Closed
|
|
Change Management
|
Process of
managing changes to the project, infrastructure or any aspect of
services, in a controlled manner, enabling approved changes with
minimum disruption.
|
|
Change Record
|
Record
containing details of which Configuration Items are affected by
an authorized change (planned or implemented) and how.
|
|
Change Request
|
A generic form
or screen, used to record details of a request for a change to a
configuration item. Examples are Request for Change, Project
Scope Change, Software Change Control form. It is a means of
proposing a modification to the current specification of a
product, system or environment.
|
|
Change Review Board
|
See Change
Advisory Board.
|
|
Classification
|
Process of
formally grouping Configuration Items by type, e.g. software,
hardware, documentation, environment, application. Process of
formally identifying changes by type e.g. project scope change
request, change request, infrastructure change request.
|
|
Configuration
|
A Configuration
is the complete technical description required to build, test,
accept, install, operate, maintain and support a system. It
includes all documentation pertaining to the system as well as
the system itself.
|
|
Configuration Audit
|
The process of
verifying that all the required Configuration Items have been
produced, that the current version agrees with specified
requirements, that the technical documentation completely and
accurately describes the Configuration Items and that all Change
Requests have been resolved. Regular Configuration Audits should
be held. Inspection of plans, procedures, working practices,
repositories and other records would be included in such audits.
|
|
Configuration Baseline
|
Configuration
of a product or system established at a specific point in time,
which captures both the structure and details of the product. It
serves as reference for further activities and is also known as
a configuration baseline (ISO 10007). An application or software
baseline provides the ability to change or to rebuild the
specific version at a later date. A snapshot or a position which
is recorded. Although the position may be updated later, the
baseline remains unchanged and available as a reference of the
original state and as a comparison against the current position
(PRINCE 2).
|
|
Configuration Control
|
Activities
comprising the control of changes to Configuration Items after
formal establishment of its configuration documents. It includes
the evaluation, co-ordination, approval or rejection of changes.
The implementation of changes includes changes, deviations and
waivers that impact on the configuration.
|
|
Configuration Documentation
|
Documents that
define requirements, system design, build, production, and
verification for a configuration item.
|
|
Configuration Identification
|
Activities that
determine the product structure, the selection of Configuration
Items, and the documentation of the configuration item’s
physical and functional characteristics including interfaces and
subsequent changes. It includes
the allocation if identification characters or numbers to
the Configuration Items and their documents. It also includes
the unique numbering of configuration control forms associated
with changes and problems.
|
|
Configuration Item (CI)
|
Aggregation of
hardware, network, software, application, environment, services
or any of its discrete portions, that is designated for
Configuration Management and treated as single entity in the
Configuration Management process. Configuration Items may vary
widely in complexity, size and type - from an entire system
(including all hardware, software and documentation) to a
version or variant of a single module.
|
|
Configuration Management
|
Technical and
organisational activities comprising configuration
identification, configuration control, configuration status
accounting and configuration audit. This includes the processes
of identifying and defining the Configuration Items, recording
and reporting the status of Configuration Items and requests for
change, and verifying the completeness and correctness of
Configuration Items.
|
|
Configuration Management Database
|
A database
which contains all relevant details of each Configuration Item
and details of the important relationships between Configuration
Item.
|
|
Configuration Management Plan
|
Document
setting out the organisation and procedures for the
Configuration Management of a specific product, project, system,
support group or service.
|
|
Configuration Management Tool (CM Tool)
|
A software
product providing automatic support for configuration management
e.g. change, configuration or version control.
|
|
Configuration Status Accounting
|
The process of
recording and reporting information that is needed to manage a
Configuration effectively, including the approved current
Configuration identification, the status of proposed changes to
the Configuration and the implementation status of approved
changes.
|
|
Configuration Structure
|
A hierarchy of
all the Configuration Items that comprise a configuration.
|
|
Element
|
Application
programs, object files, source code files, documentation,
database structures, key parameter file information.
|
|
Environment
|
A collection
of hardware, software, network communications and procedures
that work together to provide a discrete type of computer
service. There may be one or more environments on a physical
platform e.g. test, production. An environment has unique
features and characteristics that dictate how they are
administered in similar, yet diverse manners. Examples are the
UNIX-Oracle server, NT file server.
|
|
Granularity
|
Level at which
items are to become Configuration Items, i.e. under the control
of the Configuration Management System.
|
|
Impact Analysis
|
Impact Analysis
is the term given to the process of assessing the ramifications
of pursuing a particular course of action - typically a change
to the existing system.
|
|
Incremental Change
|
Modifications
made to correct processing problems, inefficiencies. These are
normally limited in scope. See Minor Release.
|
|
Interface
|
Physical or
functional interaction at the boundary between Configuration
Items.
|
|
Library
|
A storage area
for Configuration Items. This may, for example, be a filing
cabinet for documents, a database for software or a designated
room for hardware.
|
|
Major
Release
|
Contains major new enhancements in
functionality from the previous release.
|
|
Master Copy
|
There will be
only one ‘Master’ copy of an item.
Where duplication of items can occur, appropriate
mechanisms must be in place to detect and manage variants.
|
|
Milestone
|
This is a point
in a Project when a major objective is achieved. It may be a
Release, a Baseline or a major control point.
|
|
Minor
Release
|
Contains minor modifications to the
software (e.g. fixes, patches) made to correct processing
problems, inefficiencies. These are normally limited in scope.
|
|
Process
|
A set of inter-related activities, which
transform inputs into outputs. They bring about a particular
outcome, in terms of information to be gathered, decisions to be
made, results and status that must be achieved.
|
|
Product
|
Any output from a Project. PRINCE
distinguishes between Management Products (which are produced as
a part of the Management of the Project) and Quality Products
(which show that quality has been built into the system) and
Technical Products (those Products which make up the system). A
Product may be an item of Software, Hardware or Documentation
and may itself be a collection of other Products.
|
|
Project Change Control
|
The procedure
to ensure that all project changes, @ changes and project issues
are controlled, including the submission, analysis and decision
making.
|
|
Project Issue Report
|
A document used to raise any Issues relating to the Project
in any way.
|
|
Relationships
|
Define how
objects are impacted by change documents and other Configuration
Items. The build
process captures relationships between input and output
Configuration Items.
|
|
Release
|
A particular version of a configuration
item that is made available for a specific purpose. For example,
a test release or a production release.
|
|
Software Configuration Items (SCI)
|
As
configuration item, excluding hardware and services.
|
|
Software Environment
|
Software used
to support an application such as: Operating system, database
management system, development tools, compilers, and application
software.
|
|
Software
Library
|
A controlled collection of software
Configuration Items designated to keep those with like status
and type together and segregated from unlike, to aid in
development, operation and maintenance.
|
|
Software Release
|
A set of new or
changed software Configuration Items which is promoted for use
at a more advanced stage of the Life Cycle and which comes under
the control of a higher authority (eg. Specification to Design;
Implementation to Testing; Installation to Use). Software
Release will consist of a set of Configuration Items from a
specified Configuration Baseline, collected together for use by
others in the development process or by users. For example a set
of Software modules may be collected together and released for
Testing.
|
|
Status Accounting
|
Recording and
reporting current and historical data on the status of each CI.
The status of all versions should be readily determinable, e.g.
for what purposes they are approved for use. The lifecycle
status (e.g. new; testable; tested; approved; released) for
intermediate and end products must be defined and controlled.
The configuration of each released baseline needs to be
documented, as does the configuration of the released system.
|
|
Sub-Contractor Control
|
Sub-Contractor
Control activities are concerned with the incorporation into
project Configuration Items of items developed outside of the
project environment. The Configuration Management Plan defines
the activities for incorporating the externally developed items
into Project Configuration Items. Also the Configuration
Management Plan shall define activities to co-ordinate changes
to those external items with their developers. The Configuration
Management Plan shall describe:
·
What Configuration Management requirements are to
be part of the sub-contractors agreement
·
What configuration Audits and Reviews of
sub-contractor’s items will be held
·
How external items will be tested, verified,
accepted and merged with the Project software
|
|
System
|
An integrated composite that consists of
one or more of the processes, hardware, software, facilities and
people, that provides a capability to satisfy a stated need or
objective.
|
|
Third Party Supplier
|
Enterprises or
groups, external to the project or service supplier’s
organisation, which provide services and/or products that
contribute to, or supplement, the overall product, configuration
or service.
|
|
Traceability
|
The history and
content of all versions of items ‘handed over’ from one
person or organisation to another must be traceable, as must the
results of the ‘handover’, ie. Whether the version was
accepted or used.
|
|
Variant
|
One item
version is a variant of another, if neither is a revision of the
other. Variants allow one item to meet conflicting requirements
at the same time. Temporary variants allow parallel development
and will eventually be merged. Permanent variants are not merged
but enable the CI to meet different functional requirements. An
example might be a screen with text in a different (foreign)
language.
|
|
Version
|
An identified instance of a configuration
item within a configuration structure for the purpose of
tracking and auditing change history.
A configuration Item may have a number of
versions relating to the continuing development of that
Configuration Item. In the first instance, a Configuration Item
will be created and submitted.
The configuration Item will then undergo a number of
modifications as it is tested and errors corrected, or as
changes are requested. Subsequent submissions of the
Configuration Item will be distinguished by an increasing
version number.
|
|
Version Control
|
The means by
which items are identified, the dependency information
associated with them, the means by which it is stored and how
access to it is controlled. The establishment of baselines
containing that item and its constituent parts.
|
|
Version Identifier
|
A version
number; version date; or version date and time stamp.
|
