| Glossary of Configuration Management Terms | |
| 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 endeavour 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 CABs 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 items 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 organizational 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 heirarchy 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 collections 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-contractors 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 suppliers 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 variations 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. |
Tuesday, August 2, 2011
Configuration Management Terms
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment