|
|
| Availability | Ability of a component or service to perform its required function at a stated instant or over a stated period of time. It is usually expressed as the availability ratio, i.e. the proportion of time that the service is actually available for use by the Customers within the agreed service hours. |
| Build | The final stage in producing a usable configuration. The process involves taking one of more input Configuration Items and processing them (building them) to create one or more output Configuration Items e.g. software compile and load. |
| Category | Classification of a group of Configuration Items, Change documents or Problems. |
| Change | The addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation. |
| Change Advisory Board | A group of people who can give expert advice to Change Management on the implementation of Changes. This Board is likely to be made up of representatives from all areas within IT and representatives from business units. |
| Change authority | A group that is given the authority to approve Change, e.g. by a project board. Sometimes referred to as the Configuration Board. |
| Change control | The procedure to ensure that all Changes are controlled, including the submission, analysis, decision making, approval, implementation and post implementation of the Change. |
| Change document | Request for Change, Change control form, Change order, Change record. |
| Change history | Auditable information that records, for example, what was done, when it was done, by whom and why. |
| Change log | A log of Requests for Change raised during a project, showing information on each Change, its evaluation, what decisions have been made and its current status, e.g. raised, reviewed, approved, implemented, or closed. |
| Change Management | Process of controlling Changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved Changes with minimum disruption. |
| Change record | A record containing details of which CIs are affected by an authorised Change (planned or implemented), and how. |
| 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, validation Change request, infrastructure Change request. | |
| Process of formally identifying Incidents, Problems and Known Errors by origin, symptoms and cause. | |
| Closure | When the Customer is satisfied that an incident has been resolved. |
| Computer Aided Systems Engineering |
A software tool for programmers. It provides help in the planning, analysis, design and documentation of computer software. |
| Configuration baseline | Configuration of a product or system established at a specific point in time, which captures both the structure and details of that product or system, and enables that product or system to be rebuilt 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 (PRINCE2). | |
| Configuration control | Activities comprising the control of Changes to Configuration Items after formally establishing its configuration documents. It includes the evaluation, coordination, 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 of 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) | Component of an infrastructure - or an item, such as a Request for Change, associated with an infrastructure - that is (or is to be) under the control of Configuration Management. CIs may vary widely in complexity, size and type, from an entire system (including all hardware, software and documentation) to a single module or a minor hardware component. |
| Configuration Management | The process of identifying and defining Configuration Items in a system, recording and reporting the status of Configuration Items and Requests for Change, and verifying the completeness and correctness of Configuration Items. |
| Configuration Management tool | A software product providing automatic support for Change, Configuration or version control. |
| Configuration Management Database (CMDB) |
A database that contains all relevant details of each CI and details of the important relationships between CIs. |
| 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 structure | A hierarchy of all the CIs that comprise a configuration. |
| Customer | Recipient of a service; usually the Customer management has responsibility for the cost of the service, either directly through charging or indirectly in terms of demonstrable business need. |
| Definitive Software Library (DSL) | The library in which the definitive authorised versions of all software CIs are stored and protected. It is a physical library or storage repository where master copies of software versions are placed. This one logical storage area may in reality consist of one or more physical software libraries or filestores. They should be separate from development and test filestore areas. The DSL may also include a physical store to hold master copies of bought-in software, e.g. a fireproof safe. Only authorised software should be accepted into the DSL, strictly controlled by Change and Release Management. |
| The DSL exists not directly because of the needs of the Configuration Management process, but as a common base for the Release Management and Configuration Management processes. | |
| Delta Release | A Delta, or partial, Release is one that includes only those CIs within the Release unit that have actually changed or are new since the last full or Delta Release. For example, if the Release unit is the program, a Delta Release contains only those modules that have changed, or are new, since the last full release of the program or the last Delta Release of certain modules. See also 'Full Release'. |
| End-User | See 'User'. |
| 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. |
| Expert User | See 'Super User'. |
| Forward Schedule of Changes | A schedule that contains details of all the Changes approved for implementation and their proposed implementation dates. It should be agreed with the Customers and the business, Service Level Management, the Service Desk and Availability Management. Once agreed, the Service Desk should communicate to the User community at large any planned additional downtime arising from implementing the Changes, using the most effective methods available. |
| Full Release | All components of the Release unit that are built, tested, distributed and implemented together. See also 'Delta Release'. |
| Impact | Measure of the business criticality of an Incident. Often equal to the extent to which an Incident leads to distortion of agreed or expected service levels. |
| Incident | Any event that is not part of the standard operation of a service and that causes, or may cause, an interruption to, or a reduction in, the quality of that service. |
| Interface | Physical or functional interaction at the boundary between Configuration Items. |
| Known Error | An Incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified. If a business case exists, an RFC will be raised, but, in any event, it remains a known error unless it is permanently fixed by a Change. |
| Life-cycle | A series of states connected by allowable transitions. The life cycle represents an approval process for Configuration Items, Problem Reports and Change documents. |
| PD0005 | Alternative title for the BSI publication A Code of Practice for IT Service Management. |
| PRINCE2 | The standard UK government method for project management. |
| Priority | Sequence in which an Incident or Problem needs to be resolved, based on impact and urgency. |
| Problem | Unknown underlying cause of one or more Incidents. |
| Process | A connected series of actions, activities, Changes etc. performed by agents with the intent of satisfying a purpose or achieving a goal. |
| Process Control | The process of planning and regulating, with the objective of performing a process in an effective and efficient way. |
| Release | A collection of new and/or changed CIs which are tested and introduced into the live environment together. |
| Request for Change (RFC) | Form, or screen, used to record details of a request for a Change to any CI within an infrastructure or to procedures and items associated with the infrastructure. |
| Resolution | Action that will resolve an Incident. This may be a Work-around. |
| Role | A set of responsibilities, activities and authorisations. |
| Service Level Agreement | A written agreement between a service provider and Customer(s) that documents agreed service levels for a service. |
| Service Request | Every Incident not being a failure in the IT Infrastructure. |
| Software Configuration Item (SCI) |
As 'Configuration Item', excluding hardware and services. |
| Software Environment | Software used to support the application, such as operating system, database management system, development tools, compilers, and application software. |
| Software Library | A controlled collection of SCIs designated to keep those with like status and type together and segregated from unlike, to aid in development, operation and maintenance. |
| Super User | In some organisations it is common to use 'expert' Users (commonly known as Super, or Expert, Users) to deal with first-line support problems and queries . This is typically in specific application areas, or geographical locations, where there is not the requirement for full-time support staff. This valuable resource needs, however, to be carefully coordinated and utilised. |
| 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. |
| Urgency | Measure of the business criticality of an Incident or Problem based on the impact and on the business needs of the Customer. |
| User | The person who uses the services on a day-to-day basis. |
| Version | An identified instance of a Configuration Item within a product breakdown structure or configuration structure for the purpose of tracking and auditing change history. Also used for software Configuration Items to define a specific identification released in development for drafting, review or modification, test or production. |
| Version Identifier | A version number; version date; or version date and time stamp. |
| Work-around | Method of avoiding an Incident or Problem, either from a temporary fix or from a technique that means the Customer is not reliant on a particular aspect of a service that is known to have a problem. |
|
|
