Configuration Management Processes: Bio-Distributed

Configuration Management (CM) is a structured engineering discipline intended to identify, manage, and monitor all hardware, software, documentation, and required items created and modified during the system lifecycle (SLC) phases. These items make up the configuration of a release baseline and are termed “Configuration Items” (CI).

Due to the monitoring, control, and auditing mechanism, CM can maintain system integrity over time. It also ensures that all work products are what they should be at a specific SLC stage, per the system configuration specifications, and are applied throughout the system lifecycle.

The following industry best practices and standards are referenced in developing the CM policy, plan, and procedures:

  • CMMI V1.3: Capability Maturity Model Integration-CM Process Area
  • IEEE 1012-20012: IEEE Standards for Software Verification &Validation
  • IEEE 828-2008: IEEE Standards for CM
  • ITIL V3: Information Technology Infrastructure Library-CM

CM starts with developing a plan that describes the CM policy, resources, tools, naming conventions, and the four CM processes. These include Configuration Identification, Configuration Control, Configuration Audits, and Configuration Status Accounting.

Configuration Identification consists of selecting, categorizing, assessing, approving, and documenting all CIs that make up an approved baseline required for a system release. Additionally, during this process, the functional and physical characteristics of each CI are also documented. Assigning and recording unique identifiers to all software, hardware, and document items is also an important task in the Configuration Identification process, as their unique identifiers help distinguish them from one another.

Configuration Control, also named configuration management, is the process of systematically evaluating recommended CI changes that are necessary to better serve end users’ needs and or correctly identified issues. These recommended changes are documented in change requests (CRs). A Change/Configuration Control Board (CCB), made up of selective project stakeholders, are responsible for reviewing all CRs. CRs are approved or rejected based on impact analyses in terms of user’s needs, technology, cost, schedule, and security. The CCB also prioritizes the implementation of approved CRs based on the assigned levels of priority and severity assigned to each CR. Configuration Control maintains allocated product baselines and regulates all changes. Effective Configuration Control warrants the CI integrity and prevents unapproved CI modifications.

Configuration Audits are intended to objectively evaluate the functional and physical characteristics of CIs that make up a system baseline to determine if they comply with the functional and physical characteristics described in their configuration baseline documentation. The Configuration Audits are performed on each system release to verify that:

  • The total number of CIs with their unique identifications listed in a release manifest (VDD or SVD) match the ones deployed to production, such as audit for completeness and correctness,
  • All CIs meet the release specifications,
  • All approved CRs are accounted for and implemented, and
  • All release documents completely and correctly describe all slated CIs and their functional and physical characteristics.

The Configuration Audits consist of two types: Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA).

The FCA is the review and assessment process to verify that all hardware and software CIs that make up a release are developed completely and correctly. This is also used to verify that the CIs meet the functional and performance requirements documented in technical release specifications. The FCA is performed at the end of the development cycle, following the completion of all tests performed on developed CIs.

The PCA is the process of validating the physical characteristics and “as-built” configuration of all deployed hardware and software CIs to determine whether they conform to a Version Description Document (VDD) or Software Version Description (SVD) specific to a release. These are two technical documents which:

  • Describe the contents of a specific hardware or software build or release;
  • Summarize the CI features and describe the identification and version of the CIs included in the build or release; and
  • Provide the build instructions, installation, and operating information specific to the target release.

The PCA is performed after a release has been successfully deployed to the production environment to assess the CI integrity. The integrity of all deployed CIs is considered preserved when the deployed CI version and identification match the ones listed in the VDD and/or SVD.

Configuration Status Accounting (CSA) is the process of recording and reporting of the information needed to manage CIs effectively. The CSA provides the means by which the CI status can be reviewed and tracked, and the history of CI modifications can be maintained.

A Configuration Status Report includes, but is not limited to, the following information:

  • The list of all CRs, with their numbers, review statuses, dates, and originators;
  • The list of approved configuration documents and their unique identification numbers;
  • The status of all CRs and dates;
  • The implementation status of approved CRs and dates;
  • Discrepancies and issues identified from the functional and physical configuration audits; and
  • As-built CI lists by part number, serial number, and date.

The table below includes a list of some of the top CM tools that currently being used within the industry.

CM Tools

The CM processes and tools discussed in this article provide direct benefits for projects. They allow projects to save coding time, as developers can work simultaneously on code changes. They reduce costs, and alleviate issues/risks by preventing code duplication, overwriting, and omission. These processes allow projects to maintain product baselines, release version information, and a history of all CI changes for audit purposes. Projects can assure that the right systems are built with correct and complete CIs, per the approved specifications. CM processes/tools prevent unauthorized modifications from being made to a system and approved changes from being made to a wrong version of a system. Finally, these processes and tools are beneficial because they allow projects to control access privileges to alleviate security breaches.