Configuration Management Plan

Configuration Management is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.

Configuration Management concerns itself with answering the question "Somebody did something, how can one reproduce it?" Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analyzing their differences. Traditional configuration management typically focused on controlled creation of relatively simple products.

Configuration Management Goals

The goals of Configuration Management are generally:

• Configuration identification: Identifying configurations, configuration items and baselines
• Configuration control: Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline
• Configuration status accounting: Recording and reporting all the necessary information on the status of the development process
• Configuration auditing: Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals
• Build management: Managing the process and tools used for builds
• Process management: Ensuring adherence to the organization's development process
• Environment management: Managing the software and hardware that host the system
• Teamwork: Facilitate team interactions related to the process
• Defect tracking: Making sure every defect has traceability back to the source

Configuration Items

The term configuration item or CI refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual requirements documents, software, models, plans, and people. The Configuration management system oversees the life of the CIs through a combination of process and tools by implementing and enabling the fundamental elements of identification, change management, status accounting, and audits. The objective of this system is to avoid the introduction of errors related to lack of testing as well as incompatibilities with other CIs.

The term configuration item can be applied to anything designated for the application of the elements of configuration management and treated as a single entity in the configuration management system.

• The entity must be uniquely identified so that it can be distinguished from all other configuration items.
• From the perspective of the implementer of a change, the CI is the "what" of the change. Altering a specific baseline version of a configuration item creates a new version of the same configuration item, itself a baseline. In examining the effect of a change, two of the questions that must be asked are:
• What configuration items are affected?
• How have the configuration items been affected?
• Its use within a product can be traced in a robust status accounting system.
• It is subject to acceptance verification based on established criteria.

A release (itself a versioned entity) may consist of several configuration items. The set of changes to each configuration item will appear in the release notes, and the notes may contain specific headings for each configuration item. A complex hardware configuration item may have many levels of configuration items beneath its top level; each configuration item level must meet the same fundamental elements of the configuration management system.

In addition to its purpose in the implementation and management of a change, each configuration item's listing and definition should act as a common vocabulary across all groups connected to the product. It should be defined at a level such that an individual involved with product marketing and an individual at the coalface of implementation can agree to a common definition when they use the name of the configuration item. Selection and identification of configuration items for a particular project can be seen as the first step in developing an overall architecture of the product from the top down.

Configuration items, their versions, and their changes form the basis of any configuration audit.

Test Plan

A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from Test Engineers.

Depending on the product and the responsibility of the organization to which the test plan applies, a test plan may include one or more of the following:

• Design Verification or Compliance test: to be performed during the development or approval stages of the product, typically on a small sample of units.
• Manufacturing or Production test: to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control.
• Acceptance or Commissioning test: to be performed at the time of delivery or installation of the product.
• Service and Repair test: to be performed as required over the service life of the product.
• Regression test: to be performed on an existing operational product, to verify that existing functionality didn't get broken when other aspects of the environment are changed (e.g., upgrading the platform on which an existing application runs).

A complex system may have a high level test plan to address the overall requirements and supporting test plans to address the design details of subsystems and components.

Test plan document formats can be as varied as the products and organizations to which they apply. There are three major elements that should be described in the test plan:

• Test coverage: in the test plan states what requirements will be verified during what stages of the product life. Test Coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will have one or more corresponding means of verification. Test coverage for different product life stages may overlap, but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during Design Verification test, but not repeated during Acceptance test. Test coverage also feeds back into the design process, since the product may have to be designed to allow test access.
• Test methods: in the test plan state how test coverage will be implemented. Test methods may be determined by standards, regulatory agencies, or contractual agreement, or may have to be created new. Test methods also specify test equipment to be used in the performance of the tests and establish pass/fail criteria. Test methods used to verify hardware design requirements can range from very simple steps, such as visual inspection, to elaborate test procedures that are documented separately.
• Test responsibilities: include what organizations will perform the test methods and at each stage of the product life. This allows test organizations to plan, acquire or develop test equipment and other resources necessary to implement the test methods for which they are responsible. Test responsibilities also includes, what data will be collected, and how that data will be stored and reported (often referred to as "deliverables"). One outcome of a successful test plan should be a record or report of the verification of all design specifications and requirements as agreed upon by all parties.

Supporting Tools & Environments

Before proceeding in the project’s implementation, the project manager should define the list of supporting tools that will be used in the project to guide the team and the customer preparing for the development, test and production environments. Supporting tools may include a bug tracking system, collaboration tools to share events, documents…, source control tool…