The Community for Technology Leaders
RSS Icon
Subscribe
Issue No.04 - July/August (2003 vol.20)
pp: c3, 53, 56, 93
Published by the IEEE Computer Society
Software Configuration Management Domain

baseline:
1. A description of a system and its components (configuration items) at a particular period of time, and any approved updates to the baseline. 2. A work product that has been placed under formal configuration management. See also work product.

baseline document:
A system/software document that defines a work product that has been placed under configuration management. Examples are system specifications, requirements specifications, and design specifications .

build:
An operational version of a software product incorporating a specified subset of the capabilities that the final product will include. Sometimes synonymous with version.configuration: 1. The arrangement of a system or network as defined by the nature, number, and chief characteristics of its functional units; might refer to a hardware configuration or a software configuration. 2. The requirements, design, and implementation that define a particular version of a system or system component. 3. The functional and/or physical characteristics of hardware/software as set forth in technical documentation and achieved in a product. [Military Std. 480B-1988]

configuration control:
An element of configuration management consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification. [IEEE Std. 610.12-1990] Sometimes erroneously used for configuration management.

configuration control board (CCB):
The authority responsible for evaluating, approving, and/or disapproving proposed engineering changes to hardware/software configurations. This board should also insure the implementation of the approved changes. [IEEE Std. 610.12-1990] See also configuration management, engineering change proposal.

configuration item (CI):
An aggregation of hardware, software, or both that is designated for configuration management and treated as a single entity in the configuration management process. [IEEE Std. 610.12-1990]

configuration management (CM):
A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE Std. 610.12-1990]

configuration management system:
The discipline of identifying the components of a continually evolving system for the purpose of controlling changes to those components and maintaining integrity and traceability throughout the life cycle.

control point (project control point):
An agreed-on point in time or times when specified project agreements or controls are applied to the software configuration items being developed. Examples are an approved baseline or release of a specified document or code. [IEEE Std. 828-1998]

document control:
The application of configuration management to the control of documents.

engineering change:
An alteration in the configuration of a hardware/software configuration item or items, delivered, to be delivered, or under development, after formal establishment of their configuration identification. See also engineering change proposal.

engineering change proposal (ECP):
A proposed engineering change and the documentation by which the change is described and suggested. [IEEE Std. 610.12-1990]

functional baseline:
The initial configuration established at the end of the requirements definition phase.

hardware configuration item (HCI):
A hardware entity that has been established as a configuration item. An HCI exists where functional allocations have been made that clearly distinguish equipment functions from software functions and where the hardware has been established as a configuration item. Contrast with software configuration item.

interface control:
The process of (a) identifying all functional and physical characteristics relevant to the interfacing of two or more configuration items provided by one or more organizations, and (b) ensuring that proposed changes to these characteristics are evaluated and approved prior to implementation.

product baseline:
The "final" hardware/software configuration identification established at the end of a development phase.

program librarian:
1. An individual who administers the project library. 2. The person responsible for establishing, controlling, and maintaining a software development library. 3. An individual who acts as an administrator, secretary, and librarian for many teams and who maintains and controls all elements of the software configuration—for example, documentation, source listings, and data catalogs—and indexes reusable software models. The librarian also assists the team in research, evaluation, and document preparation.

program support librarian (PSL):
See program librarian.

release:
The formal notification and distribution of an approved version of a hardware/software system. [IEEE Std. 828-1998]

software change control:
The process by which a software change is proposed, evaluated, approved or rejected, scheduled, and tracked. [ANSI/IEEE Std. 610.12 1990] See also software configuration control, configuration management. software component (SC): A functionally or logically distinct part of a software configuration item, distinguished for the purpose of convenience in designing and specifying a complex SCI as an assembly of subordinate elements.

software configuration:
1. The arrangement of a computer system or component as defined by the number, nature, and interconnections of its constituent parts. 2. The functional and physical characteristics of a software system as set forth in technical documentation or achieved in a product. [ANSI/IEEE Std. 610.12 1990]

software configuration auditing:
The process of verifying that all required hardware/software 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. [ANSI/IEEE Std. 610.12 1990] See also software configuration management. software configuration control: The evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification. [IEEE Std. 610.12-1990] See also software configuration management.

software configuration identification:
1. An element of configuration management consisting of selecting the configuration items for a software system and recording their functional and physical characteristics in technical documentation. 2. The current approved technical documentation for a software configuration item as set forth in specifications, drawings, associated lists, and documents referenced therein. [IEEE Std. 610.12-1990] See also software configuration management.

software configuration item (SCI):
A software entity that has been established as a configuration item. The SCI exists where functional allocations have been made that clearly distinguish equipment functions from software functions //AUTHOR: okay?// and where the software has been established as a configurable item. Contrast with hardware configuration item.

software configuration management (SCM):
A discipline applying technical and administrative direction and surveillance to (a) identify and document the functional and physical characteristics of a software configuration item, (b) control changes to those characteristics, (c) record and report change processing and implementation status, and (d) verify compliance with specified requirements. //AUTHOR: added letters okay?// See also software configuration auditing, software configuration control, software configuration identification, software configuration status accounting, software release management.software configuration management plan: A document setting forth the configuration items of a system and the plan for configuration management of each of them, including schedules, procedures, personnel, and equipment to be used. [IEEE Std. 828-1998]

software configuration status accounting:
The process of recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes. [ANSI/IEEE Std. 610.12 1990] See also software configuration management.

software item:
An aggregation of software, such as a computer program or database, that satisfies an end use function and is designated for specification, qualification testing, interfacing, configuration management, or other purposes. Software items are selected based on trade-offs among software function, size, host or target computers, developer, support strategy, reuse plans, criticality, interface considerations, the need to be separately documented and controlled, and other factors. A software item is made up of one or more software units.

software librarian:
See program librarian. software release management: Management of the activities surrounding the release of one or more versions of software to one or more customers, including identifying, packaging, and delivering //AUTHOR: okay?// the elements of a product. See also software configuration management, version.

software version control:
A process for controlling the different versions of a software system. See also configuration management.

version:
1. An initial release or rerelease of a computer software configuration item, associated with a complete compilation or recompilation of the computer software configuration item. 2. An initial release or complete rerelease of a document, as opposed to a revision resulting from issuing change pages to a previous release. [CSDP Glossary] 3. An operational software product that differs from similar products in terms of capability, environmental requirements, and configuration. Sometimes synonymous with build.

work product:
Any document, documentation, or other tangible item that results from working on a project function, activity, or task. Examples of work products include the project plan, functional requirements, design documents, source code, test plans, meeting minutes, schedules, budgets, and problem reports. A subset of the work products will form the set of project deliverables. [IEEE Std. 1058-1998]

15 ms
(Ver 2.0)

Marketing Automation Platform Marketing Automation Tool