Baseline (configuration management)

Last updated

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]

Contents

Typically, significant states are those that receive a formal approval status, either explicitly or implicitly. An approval status may be attributed to individual items, when a prior definition for that status has been established by project leaders, or signified by mere association to a particular established baseline. Nevertheless, this approval status is usually recognized publicly. A baseline may be established for the singular purpose of marking an approved configuration item, e.g. a project plan that has been signed off for execution. Associating multiple configuration items to such a baseline indicates those items as also being approved. Baselines may also be used to mark milestones. A baseline may refer to a single work product, or a set of work products that can be used as a logical basis for comparison.

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, dynamic 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. Retrieving such a dynamic baseline obtains the current revision of only these notable items in the project.

While marking approval status covers the majority of uses for a baseline, multiple fixed baselines may also be established to monitor the progress of work through the passage of time. In this case, each baseline is a visible measure through an endured team effort, e.g. a series of developmental baselines. This progression is revealed when the baselines are compared with each other. A baseline may also be established as the basis for subsequent exclusive activities when the baselined products have met certain criteria. For example, certain activities reserved for items with a prior formal approval, such as formal change control procedures.

Baselines themselves are valued not only to identify the notable state of work product(s) but also provide historical views of how work product elements have progressed together over time. When a fixed baseline is retrieved, the state of the work product(s) in that subset share the same significance in their history of changes; this allows project leaders to compare the relative progress of single parts of a project to the project as a 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, and ultimately, project quality.

Conversely, the configuration of a project includes all of its baselines, the status of the configuration, all audits, and all metrics collected. The current configuration refers to the current status, current audit, and current metrics. Similarly, but less common, a baseline may refer to all items in a project. This may include the latest revision of all items or only specific revisions of all items in the project, depending on the nature of the baseline, dynamic or fixed respectively. Once retrieved, the baseline may be compared to a particular configuration or another baseline. In configuration management, the configuration of a project is not the same as a baseline in the project but the two could coincide.

Fixed baselines often coincide with or signify project milestones, such as the set of items at a particular certifying review. [3] Some examples include:

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.

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.

See also

Related Research Articles

Earned Value Management (EVM), earned value project management, or earned value performance management (EVPM) is a project management technique for measuring project performance and progress in an objective manner.

Project management is the process of leading the work of a team to achieve all project goals within the given constraints. This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, and budget. The secondary challenge is to optimize the allocation of necessary inputs and apply them to meet pre-defined objectives.

<span class="mw-page-title-main">Configuration management</span> Process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

In software engineering, version control is a class of systems responsible for managing changes to computer programs, documents, large web sites, or other collections of information. Version control is a component of software configuration management.

In software engineering, software configuration management is the task of tracking and controlling changes in the software, part of the larger cross-disciplinary field of configuration management. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine the "what, when, why and who" of the change. If a configuration is working well, SCM can determine how to replicate it across many hosts.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Information technology service management (ITSM) is the activities that are performed by an organization to design, build, deliver, operate and control information technology (IT) services offered to customers.

Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization. CMMI defines the following maturity levels for processes: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. Version 2.0 was published in 2018. CMMI is registered in the U.S. Patent and Trademark Office by CMU.

<span class="mw-page-title-main">StarTeam</span>

StarTeam is a version control system used in software development, especially when a project involves multiple teams in different locations. StarTeam is an SCM and SDLC software application, created by Starbase Corporation, which was acquired by Borland in January 2003 which was acquired by Micro Focus in July 2009. The application is client-server, backed by a relational database that retains all changes made to a project during its evolution as well as the project requirements, task assignments, threaded discussions and bug tracking. Microsoft SQL Server and Oracle database are supported database servers.

CA Harvest Software Change Manager is a software tool for the configuration management of source code and other software development assets.

Quality management ensures that an organization, product or service consistently functions well. It has four main components: quality planning, quality assurance, quality control and quality improvement. Quality management is focused not only on product and service quality, but also on the means to achieve it. Quality management, therefore, uses quality assurance and control of processes as well as products to achieve more consistent quality. Quality control is also part of quality management. What a customer wants and is willing to pay for it, determines quality. It is a written or unwritten commitment to a known or unknown consumer in the market. Quality can be defined as how well the product performs its intended function.

Software quality assurance (SQA) is a means and practice of monitoring all software engineering processes, methods, and work products to ensure compliance against defined standards. It may include ensuring conformance to standards or models, such as ISO/IEC 9126, SPICE or CMMI.

The term configuration item (CI) refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual hardware or software components. The configuration-management system oversees the life of the CIs through a combination of processes and tools by implementing and enabling the fundamental elements of identification, change management, status accounting, and audits. This system aims to avoid the introduction of errors related to lack of testing as well as of incompatibilities with other CIs.

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety-critical software used in certain airborne systems. It was jointly developed by the safety-critical working group RTCA SC-167 of the Radio Technical Commission for Aeronautics (RTCA) and WG-12 of the European Organisation for Civil Aviation Equipment (EUROCAE). RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B. Although technically a guideline, it was a de facto standard for developing avionics software systems until it was replaced in 2012 by DO-178C.

The Capability Maturity Model Integration (CMMI) defines a process area as, "a cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area." Both CMMI for Development v1.3 and CMMI for Acquisition v1.3 identify 22 process areas, whereas CMMI for Services v1.3 identifies 24 process areas. Many of the process areas are the same in these three models.

Software project management is the process of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

International standards in the ISO/IEC 19770 family of standards for IT asset management address both the processes and technology for managing software assets and related IT assets. Broadly speaking, the standard family belongs to the set of Software Asset Management standards and is integrated with other Management System Standards.

Lean IT is the extension of lean manufacturing and lean services principles to the development and management of information technology (IT) products and services. Its central concern, applied in the context of IT, is the elimination of waste, where waste is work that adds no value to a product or service.

ISO 10007 "Quality management — Guidelines for configuration management" is the ISO standard that gives guidance on the use of configuration management within an organization. "It is applicable to the support of products from concept to disposal." The standard was originally published in 1995, and was updated in 2003 and 2017. Its guidance is specifically recommended for meeting "the product identification and traceability requirements" introduced in ISO 9001:2015 and AS9100 Rev D.

<span class="mw-page-title-main">In-Step BLUE</span>

in-STEP BLUE is a project management software program developed and sold by microTOOL GmbH, based in Berlin, Germany. It is designed to assist project managers in developing plans, assigning resources to tasks, tracking progress, managing budgets, requirements, changes and risks as well as analyzing workloads. The tool automatically stores all project results in a central repository shared by all users. Individual project management methods can be supported as well as the agile method Scrum, official methods like the British PRINCE2, the German V-Model XT, the Swiss HERMES method and methods for the automotive industry according to ISO/IEC 15504, also known as SPICE.

References

  1. ↑ MIL-HDBK-61 page Page 3-4, "Configuration baseline (baseline)"
  2. ↑ 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.
  3. 1 2 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
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.