Configuration Management Glossary |
  • Activity
    A set of actions designed to achieve a particular result. Activities are usually defined as part of Processes or Plans, and are documented in Procedures
  • Allocated configuration identification
    In configuration management, the current approved specifications governing the development of configuration items that are part of a higher level configuration item. Each specification defines the functional characteristics that are allocated from those of the higher level configuration item, establishes the tests required to demonstrate achievement of its allocated functional characteristics, delineates necessary interface requirements with other associated configuration items, and establishes design constraints, if any.
  • Allocated baseline
    In configuration management, the initial approved specifications governing the development of configuration items that are part of a higher level configuration item. management and configuration control.
  • Baseline
    A reviewed and approved release of artifacts that constitutes an agreed basis for further evolution or development and that can be changed only through a formal procedure, such as change
  • Baseline management
    In configuration management, the application of technical and administrative direction to designate the documents and changes to those documents that formally identify and establish baselines at specific times during the life cycle of a configuration item.
  • Build
    An operational version of a system or component that incorporates a specified subset of the capabilities that the final product will provide.
  • Configuration baseline
  1. An agreed-to description of the attributes of a product, at a point in time, which serves as a basis for defining change.
  2. An approved and released document, or a set of documents, each of a specific revision; the purpose of which is to provide a defined basis for managing change.
  3. The currently approved and released configuration documentation.
  4. A released set of files comprising a software version and associated configuration documentation
  • Change Advisory Board – CAB
    A dynamic group of people that is convened weekly and whose specific membership depends upon the change. The CAB approves Changes with medium to high priority, risk, or impact
  • Change Control
    Process by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked to completion.
  • Change Manager – CM
    Responsible for the Change Management process and authorizes all changes.
  • Change Request (CR)
    A formally submitted artifact that is used to track all stakeholder requests (including new features, enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle. All change history will be maintained with the Change Request, including all state changes along with dates and reasons for the change. This information will be available for any repeat reviews and for final closing.
  • Change Request Submit Form
    This form is displayed when a Change Request is being Submitted for the first time. Only the fields necessary for the submitter to complete are displayed on the form.
  • Change Request Combined Form
    This form is displayed when you are reviewing a Change Request that has already been submitted. It contains all the fields necessary to describe the Change Request. The following outline of the Change Request process describes the states and statuses
  • Change Request Submit
    Any stakeholder on the project can submit a Change Request (CR). The Change Request is logged into the Change Request Tracking System (e.g., Rational ClearQuest) and is placed into the CCB Review Queue, by setting the Change Request State to Submitted
  • Change Request Review
    The function of this activity is to review Submitted Change Requests. An initial review of the contents of the Change Request is done in the CCB Review meeting to determine if it is a valid request. If so, then a determination is made if the change is in or out of scope for the current release(s), based on priority, schedule, resources, level-of-effort, risk, severity and any other relevant criteria as determined by the group.
  • Change Request Update
    If more information is needed (More Info) to evaluate a Change Request, or if a Change Request is rejected at any point in the process (e.g., confirmed as a DuplicateRejected , etc.), the submitter is notified and may update the Change Request with new information. The updated Change Request is then re-submitted to the CCB Review Queue for consideration of the new data
  • Developmental base line
    It represents the evolving software configuration at selected times during the software life cycle
  • Different Base Lines
    Functional Base line — Corresponds to the reviewed system requirements Allocated Base line – Corresponds to the reviewed system requirements specifications and software interface requirement specification
  • Defect
    Any nonconformance of a characteristic with specified requirements.
  • Functional Baseline (FBL)
    The initially approved documentation describing a system’s or item’s functional, interoperability, and interface characteristics and the verification required to demonstrate the achievement of those specified characteristics.
  • Functional characteristics
    Quantitative performance parameters and design constraints, including operational and logistic parameters and their respective tolerances. Functional characteristics include all performance parameters, such as range, speed, lethality, reliability, maintainability, and safety.
  • Functional Configuration Audit (FCA)
    The formal examination of functional characteristics of a configuration item, prior to acceptance, to verify that the item has achieved the requirements specified in its functional and allocated configuration documentation.
  • Functional Configuration Documentation (FCD)
    The approved functional baseline plus approved changes.
  • Functional Configuration Identification (FCI)
    Functional configuration identification (functional baseline and approved changes) will include all specifications necessary to specify 1) all essential system functional characteristics; 2) necessary interface characteristics; 3) specific designation of the functional characteristics of key configuration items; and 4) all of the tests required to demonstrate achievement of each specified characteristic.
  • Make Changes
    The assigned team member performs the set of activities defined within the appropriate section of the process (e.g., requirements, analysis & design, implementation, produce user-support materials, design test, etc.) to make the changes requested. These activities will include all normal review and unit test activities as described within the normal development process. The Change Request will then be marked as Resolved
  • Product Baseline (PBL)
    The initially approved documentation describing all of the necessary functional and physical characteristics of the configuration item and the selected functional and physical characteristics designated for production acceptance testing and tests necessary for support of the configuration item. In addition to this documentation, the product baseline of a configuration item may consist of the actual equipment and software.
  • Physical Configuration Audit (PCA)
    The formal examination of the “as built” configuration of a configuration item against its technical documentation to establish or verify the configuration item’s product baseline.
  • Process Control
    It enforces appropriate policies and processes across diverse development environments
  • Product Configuration Documentation (PCD)
    The approved product baseline plus approved changes.
  • Product Configuration Identification (PCI)
    The product configuration identification (product baseline and approved changes) will include all specifications, engineering drawings and related data, as necessary, to provide a set of documents adequate for the procurement, production, test, evaluation, and acceptance of a configuration item without requireing further development work. This set of documents provides that technical description which describes the required physical characteristics of a configuration item; the functional characteristics designated for production acceptance testing; and required acceptance tests.
  • Release
    The designation by the contractor that a document is complete and suitable for use. Release means that the document is subject to the contractor’s configuration control procedures. The formal notification and distribution of an approved version.
  • Release Notes
    The release notes typically describe new capabilities, known problems, and platform requirements necessary for proper product operation.
  • Request for Change (RFC)
    A formal proposal for a Change to be made. An RFC includes details of the proposed Change, and may be recorded on paper or electronically
  • System
    A self-sufficient unit in its intended operational environment, which includes all equipment, related facilities, material, software, services, and personnel required for its operation and support.
  • SCM-Software Configuration Management
    SCM is a supporting software life cycle process (IEEE12207.0-96) which benefits project management, development and maintenance activities, assurance activities, and the customers and users of the end product
  • Software Building
    Software building is the activity of combining the correct versions of software configuration items, using the appropriate configuration data, into an executable program for delivery to a customer or other recipient, such as the testing activity.
  • Software Configuration Identification
    The software configuration identification activity identifies items to be controlled, establishes identification schemes for the items and their versions, and establishes the tools and techniques to be used in acquiring and managing controlled items. These activities provide the basis for the other SCM activities.
  • Software Release Management
    Software release management encompasses the identification, packaging, and delivery of the elements of a product, for example, executable program, documentation, release notes, and configuration data.
  • Software Functional Configuration Audit
    This is to ensure that the audited software item is consistent with its governing specifications. The output of the software verification and validation activities is a key input to this audit.
  • Software Physical Configuration Audit
    Software physical configuration audit (PCA) is to ensure that the design and reference documentation is consistent with the as-built software product.
  • Specification
    A document that explicitly states essential technical attributes/requirements for a product and procedures to determine that the product’s performance meets its requirements/attributes.
  • Specification Change Notice (SCN)
    A document used to propose, transmit, and record changes to a specification.
  • UCM
    Unified Change Management unifies the activities used to plan and track project progress with the artifacts being changed
  • Version
    An identified and documented body of software. Modifications to a version of software (resulting in a new version) require configuration management actions by either the contractor, the Purchaser, or both.
  • Version Control
    It Allows different projects to use the same source files at the same time It isolates work that is not ready to be shared by the rest of the project.
  • Version ID
    A branch path name which indicate a version’s exact location in its version tree
  • Version Tree
    It is a Hierarchical representation of an element in which all versions are logically organized
  • View
    A ClearCase mechanism that allows users access to versions of elements in VOBs. It enables users to work in parallel
  • VOB
    Versioned Object Base is a Read only repository of Clear Case source Files, Directories, documents, etc. It is a network wide file system resource which stores version- controlled data

    Ref :
    IEEE Software Engineering Body of Knowledge version 2004
    Rational Clearcase & Rational Unified Process