Baseline (configuration management)
In configuration management, a baseline is an agreed description of the attributes of a product, at a point in time, which serves as a basis for defining change.[1] A change is a movement from this baseline state to a next state. The identification of significant changes from the baseline state is the central purpose of baseline identification.[2]
Typically, significant states are those that receive a formal approval status, either explicitly or implicitly. An approval status may be marked individually, when a prior definition for that status has been established by project leaders, or signified by association to a position above or below the established baseline. Nevertheless, this approval status is usually recognized publicly. Thus, a baseline may also mark an approved configuration item, e.g. a project plan that has been signed off for execution. In a similar manner, associating multiple configuration items with such a baseline indicates those items as being approved.
Generally, a baseline may be a single work product, or set of work products that can be used as a logical basis for comparison. A baseline may also be established as the basis for subsequent select activities when the work products meet certain criteria. Such activities may be attributed with formal approval.
Conversely, the configuration of a project often includes one or more baselines, the status of the configuration, and any metrics collected. The current configuration refers to the current status, current audit and/or current metrics. Similarly, but less frequently, a baseline may refer to all items associated with a specific project. This may include all revisions of all items, or only the latest revision of all items in the project, depending upon context.
A baseline may be a specific type of baseline, such as the body of items at a particular certifying review.[3] Some examples include:
- Functional Baseline: initial specifications established; contract, etc.
- Allocated Baseline: state of work products after requirements are approved
- Developmental Baseline: state of work products amid development
- Product Baseline: contains the releasable contents of the project
- others, based upon proprietary business practices
Capabilities of baselines
While marking approval status covers the majority of uses for a baseline, baselines may also be established to signify the progress of work through the passage of time. In this case, a baseline is a visible measure through an endured collective effort, e.g. a developmental baseline. Baselines may also mark milestones.
Baselines themselves are valued not only to use to identify the notable state of work product(s) but also provide historical views of how work product elements have proceeded together over time. When a historical baseline is retrieved, the state of the work product(s) in that subset share the same significance in their history of changes; that allows project leaders to compare the relative progress of single parts of a project to the project as whole, which allows project leaders to identify individual items that lag or lead in progress toward better functionality or performance. For this reason, baseline identification, monitoring, and retrieval are critical to the success of configuration management. Once retrieved, the baseline may be compared to a particular configuration or another baseline.
Most baselines are established at a fixed point in time[3] and serve to continue to reference that point (identification of state). However, some baselines are established to carry forward as a reference to the item itself regardless of any changes to the item. These latter baselines evolve with the progression of the work effort but continue to identify notable work products in the project.
Baselining configuration items
In the process of performing configuration management, configuration items (or work products) may be assigned a baseline so as to establish them as having a certain status. In this sense, to baseline a work product may require certain change(s) to the work product to ensure it conforms to the characteristics associated with the baseline referenced. This varies upon context, but in many cases this requires that the work product is "reset" to an initial (possibly inherently approved) state from which work may proceed.
Baseline control
In many environments, baselines are controlled such that certain subsequent activities against work products in that baseline are either prohibited or permitted. These activities are selected and controlled, and again, depending upon the configuration management system, are also monitored. Consequently, baselines are ordinarily subjected to configuration management audits. Configuration Audits may include an examination of specific actions performed against the baseline, identification of individuals involved in any action, an evaluation of change within the baseline, (re-)certification for approval, accounting, metric collection, comparison to another baseline, or all of these.
Application
Though common in software revision control systems as labels' or tags, the existence of baselines is found in several other technology-related domains. Baselines can be found in UML modeling systems and business rule management systems, among others.
In addition to the field of hardware and software engineering, baselines can be found in medicine (e.g. monitoring health progress), politics (e.g. statistics), physics and chemistry (e.g. observations and changes), finance (e.g. budgeting), and others.
References
- MIL-HDBK-61 page Page 3-4, "Configuration baseline (baseline)"
- CMMI Product Team, "Chpt 7, Maturity Level 2: Managed, Configuration Management, SP 1.3," in Capability Maturity Model Integration, Version 1.1 (CMMI-SE/SW/IPPD/SS, V1.1): Staged Representation, Carnegie Mellon Software Engineering Institute.
- IEEE Computer Society, "Chpt 7, 2.1.5. Baseline," in Guide to the Software Engineering Body of Knowledge, 2004 Version, Edited by Deborah Plummer. IEEE Computer Society Press, 2005. ISBN 0-7695-2330-7