Last modified 6 years ago Last modified on 10/30/2013 05:08:04 PM

Obsolete ............ O B S O L E T E ........... Obsolete

Document superceded by LSE-17: Systems Engineering Management Plan

And more specifically, LSE-17 Appendix A: The DM Software Management Process. September 2013

DRAFT last revised 1 May 2009

LSST Software Configuration Management Guidelines (LSE-14)

This document is maintained under configuration control in the LSST document repository as LSE-14. It is currently edited in Trac, but the authoritative, project-approved version is always the one to be found in Docushare. The "live" Trac version (SDP/ConfigurationManagement) must always be treated as potentially unstable - it may, for instance, represent a proposed modification to the controlled document.

This document is a subordinate of LSST Software Development Plan (LSE-16) (current unstable version: Trac:SDP/LsstSoftwareDevelopmentPlan).

1. Introduction

1.1 Purpose of the document

The purpose of this document is to describe the process and procedures used by LSST personnel to ensure that all significant project artifacts, such as code, documentation, test suites, tools, products and their derivatives over time, are verifiably archived and accessible.

The policies and processes in this document will be used by anyone developing, modifying, testing and/or releasing LSST Project software products from the Telescope & Site, Camera, and Data Management subsystems. The document will also be used by each subsystem's SQA team to verify that configuration management procedures are being performed according to Project Policies and Standards.

1.2 Scope

This document describes the overall policies and procedures required for LSST Software Configuration Management.

1.3 Definitions, acronyms and abbreviations

  • CCB: LSST project-wide Configuration Control Board
  • Item: jargon used in this document to indicate a Configuration Managed composite object consisting of an identifier and the associated data being managed.
  • Module: assemblage of source, build scripts, unit tests which is logically cohesive and managed as an atomic unit.
  • Released: the act of making an object available for wider use. The scope of the release varies from other developers in the group, other groups in the project, to the entire project, or to the general population at large.
  • TCT: Technical Control Team; equivalent to the LSST CCB but limited to issues totally within the domain of the TCT's subgroup.

See also Software Development Plan: Definitions, Acronyms, and Abbreviations.

1.4 Applicable Policies, Standards and Procedures

Applicable Policies, Standards and Procedures external to this document are available at:

See also DM Applicable Policies, Standards, and Procedures.

1.5 Support Tools

Refer to the common toolset defined in the Software Development Plan.

2. Configuration Management Control

2.1 Technical Control Team

The Technical Control Team (TCT) is responsible for establishing new standards, policies, guidelines, and requirements and the oversight of any changes made to them. The TCT also determines when specifications and deliverables are of sufficient maturity and quality to be baselined (i.e. placed under configuration controlled status) or released. The TCT reviews proposed significant changes to baselined items such; the TCT generally does not review implementation details.

Within the framework established by the overall LSST configuration management plan, changes and other actions of the TCT may in some cases be able to be made within the discretion of the management of the subsystem group. Other matters, typically those with wider or more significant impact, must be handled through the full configuration management process; in that case, the TCT serves as the subsystem's gateway to entering proposed actions into the project-wide process. In particular, any changes to inter-subsystem ICDs must be referred on to the full project-wide review process, which will among other steps involve review by the LSST Change Control Board (CCB).

The TCT determines whether a change is accepted, rejected, or referred back to the requester for more information. For those changes which must be forwarded to a higher authority for their final approval, the TCT initiates the review workflow for accepted proposals.

TCT members are selected by the Subsystem's Project Manager. Should the TCT reach an impasse on the disposition of a request, the Subsystem's Project Manager will take the decision.

The TCT meets as required to process requests to create new or alter existing: standards, policies and requirements.

Refer to DM Technical Control Team for DM specific content.

2.2 Change Control Procedure

In order to initiate a Software Policy, Procedure, or Design Change, a Change Request proposal is prepared. The requester solicits comments, including a discussion on the advantages and disadvantages of the change, from the Subsystem staff prior to the TCT meeting. Finally the requester submits the proposal to the Subsystem's TCT for review.

At the next TCT meeting, the members review the Change Request proposal. The requester may be asked to lead the discussion citing the compelling reasons in favor of the change and any cautionary issues.

Refer to DM Change Control Procedure for DM specific content.

3. Module CM

Modules are assemblages of source, configuration and build scripts, and unit testers which are logically cohesive. When built, modules generally produce object libraries and/or executables. A module is the smallest unit of software managed by the build and management tools.

A collection of logically cohesive modules, called a component, may be defined to form a new superset module. Generally, unit tests for the component will also exist.

A Module Item contains (or uniquely refers to) primary source, unit tests, build configuration software and the build logs, and possibly, documentation, demonstration software, and data. If the Module Item refers to a composite module, the primary source element is replaced by the Module Item Id (see below) of each module making up the composite.

A unique version identifier will be assigned to each Subsystem Module Item once the Item has been successfully unit tested and the Module's responsible developer decides to freeze the Item's state. Only the Module's responsible developer, or delegate, is authorized to update the version identifier and to archive the corresponding Module Item's contents.

The Subsystem Module Archiving, Disaster, Build, Release, and Status Accounting procedures are defined in the respective Subsystem's baseline Configuration Management Plan.

4. Release Product CM

A Release Product is a planned deliverable from the subsystem's current baseline; it may be used during integration, system, and/or acceptance testing. The Release Product Item includes all Module Items and their build logs. Derived products of the Modules, such as libraries, executables, and automatically generated documentation, are not included since they will be regenerated should recovery of an installed Release Product derivative be necessary.

A unique version number will be assigned to the Subsystem Release Product Item by the Subsystem Test manager when the subsystem validation testing is successfully completed.

5. Test CM

The reports and logs from each level of testing: unit, integration, system and acceptance, during the Product Release baseline's build are strictly managed. Each Test Item contains: output data, build configuration, build log, and test status. Each Subgroup's specialization will provide the process of providing unique identifiers for each Test Item.

Each Test Item will be associated with a Module Item containing (or uniquely referring to) the test's input artifacts and test harness implementation. New Modules may be created to manage test input artifacts.

Refer to DM Test CM for DM specific content.

5.1 Unit Tests

Unit Tests validate that a discrete Module, or collection of discrete Modules comprising a subsystem, works according to specifications.

The source and input artifacts for the unit test are configuration managed in the relevant Module Item. If necessary for unit testing a collection of Modules, a new Module Item is specifically created to contain the Module collection's test source and input artifacts.

5.2 Integration Tests

Integration tests validate that multiple subsystems work together correctly. A Module Item is specifically created to contain the test source and input artifacts defined for the Integration test.

5.3 System Tests

System Tests validate that LSST System and Functionality Requirements are met. A Module Item is specifically created to contain the test source and input artifacts defined for the System test.

5.4 Acceptance Tests

Acceptance Tests validate that LSST Science Requirements are met. A Module Item is specifically created to contain the test source and input artifacts defined for the Acceptance test.

6. Documentation CM

LSST documentation recording plans, policies, procedures, agreements should be version controlled and permanently archived. Baseline Plans may also specify additional classes of documentation such as: documentation leading to decisions, email sent to the subgroups' mail service, etc.

Subsystem documentation automatically generated during the build process is not included under document configuration managememt since its source is embedded in a Module Item's contents.

Refer to LSSTC Change Control and Configuration Management Process for classification of documents required to be archived on the LSST Document Archive.

7. Model CM

The Enterprise Architect CASE tool manages the LSST Science and System Requirements. Additionally some subsystem groups are utilizing its design capabilities. The Enterprise Architect repository uses version control on all modifications.

The SysML and UML models should be benchmarked monthly and archived remotely from the primary version-controlled EA database.

8. Archival CM

The individual repositories managed by Subversion, Trac, and Enterprise Architect should be archived on a system supporting full backups. The retention period of these backups should be 2 years. Please note that these repositories embed permanent version control for all embedded artifacts so failsafe recovery should be performed on the most current backup.

The mail server archive(s) should also be archived onto a system supporting full backups. The backup retention period should be the duration of the LSST Facility.

The Archival CM verification should require periodic retrieval of a random artifact from each repository to verify that backup and recovery of items remains functional.

9. LSST Subsystem Configuration Management Specifics

The following sections include the subsystem specific policies and procedures for Configuration Management. The headings will reflect the layout of the overarching document.

9.1 Data Management Specifics

The following sections in the Configuration Management Guidelines are supplemented for DM by the provided information.

9.1-1.4 DM Applicable Policies, Standards and Procedures

Applicable Policies, Standards and Procedures external to this document are available at:

9.1-2.1 DM Technical Control Team

The DM System Quality Assurance and Test Lead chairs the DM TCT.

The TCT meets monthly and more often during periods prior to major reviews, system integrations or when development staff requests approval to change baseline.

9.1-2.2 DM Change Control Procedure

A record of the TCT's decision is included in the TCT meeting notes.

Refer to Policy on Changing a Baseline Requirement for the DM process for requesting the addition of, or change to, the LSST FRS.

9.1-5. DM Test CM

9.1-5.1 DM Unit Test

The unique identifier for the results of a Unit Test should incorporate the encompassing Module's svn identifier.

9.1-5.2 DM Integration Test

The unique identifier for the results of an Integration Test should incorporate the encompassing Module's svn identifier.

9.1-5.3 DM System Test

The unique identifier for the results of a System Test should incorporate the encompassing Module's svn identifier.

9.1-5.4 DM Acceptance Test

The unique identifier for the results of an Acceptance Test should incorporate the encompassing Module's svn identifier.

9.2 Telescope Specifics

9.1-3 Module CM

Basically the same definition and usage for "module" is applied in the Telescope and Site software configuration management. Some additional points refine the specific usage:

A module is a meaningful piece of code with a specific function or related collection of functions.

A module has a unique name, as short and indicative as possible, alphanumeric and case sensitive.

A module can be composed of several files organized in a directory tree with the module name as the root directory.

A module can be used to build different applications, being the base of LSSTOCS code reutilization.

Each module is under version control.

9.1-3.1 Builder Module CM

For each application, library or major software component, there is a special module called the builder. This module has the code, usually a simple collection of scripts, and the information needed to actually build and deploy the application. It must contain the list of modules and the respective versions needed for this particular release, and any configuration data. This builder module is, of course, under version control as well.

9.3 Camera Specifics


Baseline Configuration Management Plan Template

The Configuration Management Plan Template should be replicated and modified as appropriate for the Baseline. Include only information which deviates or adds to the Configuration Management Guidelines. If the new Baseline's CM characteristics are the same as the last, continue to cite that plan as the current CM Plan.

  • 1. Introduction
    • 1.1 Purpose
      • Baseline CM Plan
    • 1.2 Scope
      • Items to be managed
    • 1.3 Definitions, acronyms and abbreviations
    • 1.4 References
    • 1.5 Management
      • 1.5.1 Chain of Responsibility
      • 1.5.2 Timeline
      • 1.5.3 Applicable Policies, Standards and Procedures External to Plan
    • 1.6 Support Tools
  • 2. Configuration Management Control
  • For each CM Item type: Module, Release Product, Test, Documentation, Model, specify:
  • 3. CM Item
    • 3.1 CM Item Specification
      • 3.1.1 Contents
      • 3.1.2 Identifier
      • 3.1.3 Modification Authorization
        • Specify who may authorize a modification of a CM Item
      • 3.1.4 Conditions To Satisfy Prior to Modification
      • 3.1.5 Update Procedure
    • 3.2 CM Item Control
      • 3.2.1 Build procedures
        • Describe the procedures for building the Item.
      • 3.2.2 Release procedures
        • Describe the procedures for the release of code and documentation.
      • 3.2.3 Archiving Validation Artifacts
        • Describe the procedures for archiving test output and status.
        • List artifacts to be retained
      • 3.2.4 Disaster Recovery
        • Describe the procedure to recover the Item from either archival storage or regeneration.
      • 3.2.5 Traceability of Item Modification
        • Describe the procedures for keeping an audit trail of changes.