1. The Large Synoptic Survey Telescope
  2. (LSST)
  3. Configuration Management Plan
    1. Change History Log
    2. Contents
  4. 1. Purpose and Scope
  5. 2. Applicable Documents
  6. 3. Acronyms and Definitions
  7. 4. Overview
  8. 5. Configuration Management Responsibilities and Processes
    1. 5.1. Responsibilities and Level of Management
    2. 5.2. Configuration Identification
    3. 5.3. Documentation Archiving and Numbering
    4. 5.4. Document Organization
  9. 6. Document Approval & Change Control Process
    1. 6.1. Initial Release
    2. 6.2. Revisions
    3. 6.3. Change Control Board Operations

SPEC-LTS-SSY-5874    LSST Configuration Management Plan



DocuShare Handle # Date Effective Status
  LPM-19 May 4, 2009 Version 1
  Chuck Claver Ruth Kneale  
System Specification      
  System Engineering
  Identification Tag
Document Title
LSST Configuration Management Plan




The Large Synoptic Survey Telescope

Back to top


Back to top

Configuration Management Plan



Change History Log
Revision Effective Date Description of Changes
May 4, 2009 Initial draft for review



1. Purpose and Scope 4
2. Applicable Documents 4
3. Acronyms and Definitions 4
4. Overview 5
5. Configuration Management Responsibilities and Processes 6
5.1. Responsibilities and Level of Management 6
5.2. Configuration Identification 7
5.2.1. Baselines 7
5.2.2. Configuration Items 8
5.3. Documentation Archiving and Numbering 8
5.3.1. Documentation Standards 8
5.3.2. Electronic Documentation Locations 8
5.4. Document Organization 9
5.4.1. General Workflow 9
5.4.2. Document Types 11
5.4.3. Document Categories 11
6. Document Approval & Change Control Process 13
6.1. Initial Release 13
6.2. Revisions 13
6.3. Change Control Board Operations 15
6.3.1. CCB Membership and Responsibilities 16



Back to top

1.  Purpose and Scope
This Configuration Management Plan (CMP) describes the responsibilities and processes necessary for configuration management and change control over the Large Synoptic Survey Telescope (LSST) Project. The CMP described here is applicable to all work performed as part of the LSST project, which includes the design and development, construction, integration, test, operations, and servicing of the Observatory and its three constituent systems: the Telescope and Site (includes the observatory control system), Camera, and Data Management systems. This CMP provides guidance for all project personnel regarding Configuration Management (CM) activities in support of the LSST project by defining the organization providing configuration management, defining what a configuration controlled item (CI) is, defining the process for change control, and define the plan for configuration status and verification. The scope of this CMP encompasses the entire lifecycle of the LSST project.
This document supersedes Document-478, “Change Control and configuration Management Process”

Back to top

2. Applicable Documents

The following documents are applicable to the development or implementation of this CMP:

1)  Document-212, “LSST Science Requirements Document, v4.3.3”

2)  LSE-17, “LSST System Engineering Management Plan”

3)  Document-478, “Change Control and Configuration Management Process”, Policies and Procedures document dated November 2005

Back to top

3. Acronyms and Definitions
Allocated Baseline: Specifies the requirements that will be used to design the systems and sub-systems of the LSST. CI’s that define this baseline include subsystem requirements documents, interface control documents, and plans defining standards and protocols to be used in the design and fabrication of subsystem components.
Baseline: An arbitrary point at which a project design or requirements are considered to be “frozen” and after which all changes must be tracked and approved.
Change Classification: All proposed changes to LSST Project documentation submitted for consideration are classified as LSST Board, Project, System, and Subsystem/Group level changes. Configuration changes may affect hardware, software, or verification requirements and the documents, drawings and procedures which define them.
Configuration Control Board (CCB): A board composed of technical and management representatives who recommend approval or disapproval of proposed changes or deviations and waivers to a CI’s current approved configuration documentation.
Configuration Item (CI): An aggregation of hardware or software that satisfies an end use function and is designated for separate CM; a document describing LSST requirements, specifications and/or characteristics.
Configuration Database: A LSST Project-controlled database that identifies all CI’s.
Configuration Management (CM): The systematic control and evaluation of all changes to documentation that has reached a baseline point.
Configuration Management Plan (CMP): A collection of formal documented procedures used to apply technical and administrative direction and monitoring processes to the Project.
CR: Change Request
DCN: Document Change Notice
Functional Baseline: The initially-approved documentation describing the LSST system’s top-level performance and functional characteristics and the verification required to demonstrate the achievement of those characteristics. This includes science requirements and system-level performance and operational requirements.
LSST: Large Synoptic Survey Telescope
LSSTC: Large Synoptic Survey Telescope Corporation
Project Controls Manager (PCM): Responsible for CCB administration and implementing approved changes to the project cost and schedule baselines.
Project Manager (PM): The individual assigned to achieve the project objectives.
Project Baseline: Defines the completed design of the LSST. CI’s that define this baseline include manufacturing drawings, procedures, and specifications that will be used to build hardware and software components. This baseline is derived from the Allocated Baseline, and is also referred to as the “Build-to” baseline, since CI’s at this maturity level are used in fabrication, assembly, integration, and testing.
Systems Engineering Manager (SE): The individual responsible for the execution, technical oversight and coordination of configuration control activities.
TBD: To Be Determined
TBR: To Be Resolved

Back to top

4. Overview

This CMP describes the CM responsibilities and processes that support the design and implementation of the LSST. The purpose of this CMP is to identify the organization providing configuration control, define what a configuration-controlled item is, describe the change control process, and identify the plan for configuration status accounting and verification.

CM is the process through which the LSST Project documents the functional and physical characteristics of the Observatory, controls changes to those characteristics, and provides information on the state of change action. The CM process involves all levels of management responsibility, and consists of four ongoing stages: Configuration Identification, Configuration Change Control, Configuration Status Accounting, and Configuration Verification.

This CMP is designed to ensure that:

· Baselines are defined and documented;
· Documentation is identified, released, and controlled;
· The Configuration Control Board is defined, established and functions to CMP guidelines;
· Identifying types and metadata structures for documentation;
· Storage procedures for documentation are defined;
· Changes to the baseline are reviewed, implemented, tracked and documented;
· Defining distribution and archiving processes.

Responsibility for controlling the configuration of the LSST Observatory involves all Levels of Management in the project. Configuration Identification is the process by which the LSST Observatory is defined through drawings and documents that specify the system components in terms of functional and physical characteristics, as well as how they will be manufactured and tested. The documents describing LSST characteristics are defined as Configuration Items (CI’s). These are listed and tracked in a Configuration Database, which is also used to assess the impact of proposed changes to CI’s. The Change Control process is the process by which proposed changes are reviewed and approved. It ensures that the technical, cost, schedule, and risk impacts of each change are considered before approval is granted. Configuration Status Accounting is the means by which configuration information is tracked and relayed to key personnel in order to support management decisions and ensure that all work is performed according to the current design. The Configuration Verification process ensures that the current hardware and software configurations match the intended design by verifying the implementation of each approved change through periodic configuration audits.

Back to top

5. Configuration Management Responsibilities and Processes

5.1. Responsibilities and Level of Management

CM is the responsibility of the LSST Project Office and must be supported by all LSST team members. The Project Manager (PM) has overall responsibility for CM and for ensuring that all project CI’s are identified and controlled. The LSST System Engineer (SE) is responsible for the execution, technical oversight and coordination of configuration control activities. The PM responsible for Configuration Control Board (CCB) administration and implementing approved changes to the project cost and schedule baselines.

Responsibility for the management of configuration items is delegated to the level of management that is consistent with the scope of the item. For the LSST project, there are five levels of change control authority that correspond to five levels of scope. These levels are discussed below, and defined explicitly in the Project management Plan. Configuration managers for each of these levels are responsible for flowing down requirements and processes defined in this document to their level of management and below, as well as implementing configuration changes from above to all areas within their scope of responsibility.
LSST Board configuration items are managed through the Project Office but require approval by the LSST Board of Directors. These are items that define the highest level of project characteristics, cost and schedule performance. Examples include the Science Requirements Document.
Project Level configuration items are managed through the Project Office and approval by the Project Manager and Director. The Change Control Board reviews and advises the Project Manager on changes to items at this level. These include the overall science requirements that are used to derive the technical and operational requirements of the LSST system, project planning and policy documents (eg. this Configuration Management Plan), and overall system operational and functional requirements.
System Level configuration items are managed and approved through the Project Office by the System Scientist and Systems Engineer.. These are items that define Observatory-level characteristics contained in the Functional Baseline or impact more than one of the LSST subsystems. Examples include Interface Control Documents between LSST subsystems, LSST subsystem Requirements Specifications, and system level functional and operational requirements.
Subsystem/Group configuration items are managed entirely by the managers for one of the 6 top level WBS items namely 1) Project Management Office, 2) Data Management, 3) Camera, 4) Telescope & Site, 5) Education and Public Outreach, and 6) Commissioning. By definition, these items have a scope that falls completely within the purview of one of the 6 top level WBS structures. Examples include Camera Subsystem Requirements Specification, Facility site drawings, and data-flow test procedures.

Beyond the Project, System, and Subsystem Managers, other key technical and managerial personnel are involved in controlling the configuration of the LSST and include the Project Systems engineer and the systems engineering representative from each LSST subsystem group.

5.2. Configuration Identification

Configuration identification is the ongoing process of identifying and documenting the LSST’s functional and performance characteristics that define the technical baseline. These characteristics include functional and performance requirements, interface requirements, standards, drawings, and verification requirements.

5.2.1. Baselines

Configuration identification is developed and maintained in a series of PMO-approved baseline configurations as follows:

The Functional baseline is the initially approved set of documents that describe the high level LSST system functional requirements and specifications. The LSST Functional Baseline will be established prior to Preliminary Design Review (PDR). The content making up the Functional Baseline is managed by the SE through the SysML Requirements Model.

The Allocated Baseline the formal definition of the LSST system, subsystems, software, and hardware while refinement of performance requirements derived from the Functional Baseline occurs. This baseline defines the requirements and specifications that will be used to design the LSST system. The allocated baseline is established upon completion of the PDR.

The Design Baseline is the formal definition of the LSST system design. This baseline contains manufacturing drawings, procedures, and specifications that will be used to build the LSST system. The Design Baseline is established upon completion of pre-production audit of the design documentation done in conjunction with the Critical Design Review (CDR).


5.2.2. Configuration Items

In order to manage the configuration of the LSST baselines, the LSST system is divided into manageable units, called Configuration Items (CI’s). CI’s are selected through a top-down system decomposition process that divides the total system into a hierarchical set of logically related documents that describe the system. These documents separately define the performance parameters and physical characteristics of LSST systems, subsystems, and components such that they are can be separately designed, fabricated, and tested. CI’s may include, but are not limited to, specifications, drawings, interface control documents (ICD’s), software description documents, and procedures.

CI’s covering system and subsystem requirements along with system ICDs are derived from the contents of the SysML Requirements Model where the point of control is the model itself.

A Configuration Database is maintained by the LSST System Engineer to track all content that define the LSST baselines.

5.3. Documentation Archiving and Numbering

All CI’s are represented by documents controlled by the LSST project. All CI’s must be identified by an LSST document number to ensure that they are tracked and maintained through the life of the project. CI’s will be managed with the centralized document management system for LSST – LSST DocuShare Archive. All changes will be controlled according to plan detailed below from within the LSST DocuShare archive.

All CI’s will be available to project personnel through read only access via the LSST DocuShare Archive

5.3.1. Documentation Standards

Creation of project documentation will follow these established application standards:

Word Processing: TeX, LaTex, Microsoft Word or Rich Text Format.
· Configuration item Document: PDF
· Spreadsheets: Microsoft Excel.
· Presentations: Microsoft PowerPoint.
· Layouts and detailed engineering drawings: PDF
· Optical drawings: PDF
· Software drawings: PDF
· Electronics drawings: ODF
· Graphics: TIFF, JPEG or PNG formats.

Portable Document Format (PDF) is acceptable for historical scanned documents where the original electronic file is unavailable.

5.3.2. Electronic Documentation Locations

Electronic files will be managed through the LSST DocuShare electronic document archiving and management system. They will be sorted based on the Work Breakdown Structure (WBS) definition. Each of the 6 top level WBS items and Change Notices will have its own DocuShare Object Type. for controlled documents
. Configuration Database

5.4. Document Organization

All documents (defined as any file in the LSST DocuShare electronic archive system regardless of type, though not including engineering CAD files) will be archived in the general LSST DocuShare system, following an established integrated organizational structure and workflow process. The organizational structure helps not only to locate the file in the DocuShare structure, but also provides metadata information for findability and additional information about the focus of the file. The integrated workflow process is that flow of information that helps process files properly, both into the appropriate DocuShare directory but also for purposes of review, approval, revision, and control.

5.4.1. General Workflow

The overall LSST Configuration Management Workflow Process is illustrated in Figure 1. The workflow is structured in two primary document classes, controlled and uncontrolled. All controlled documents are subject to review, where CI’s are a special class of controlled documents requiring the most formal level of review. The content of the document classes are:
Support Documents
These include meeting materials, calendars, publications, personnel directories, etc.
Formal Documents
These are documents that require some oversight but do not define or affect the baseline design of the system.
Configuration Items
These are documents that define or affect the design baselines of the system.
·   Images and photos of events, meeting attendees, etc.
·   Presentations
·   Reference: This category includes all published articles or references.
·   Action Items
·   Budgets
·   Schedules
·   Reports
·   Reviews: this category includes all documents to organize a review, that are generated for a review or are generated by the review
·   Technical Note
Change Request
·   Change Notice
·   Drawings
·   Error Budgets
·   Interface Control Document
·   Management
·   Plans
·   Policies
·   Procedure
·   Requirements /Specifications

Adding a document to the LSST DocuShare archive is governed by whether it is controlled or uncontrolled. are added to DocuShare, it allocates a unique specific number to each document.
Documents will be located in the organizational structure according to Work Breakdown Structure (WBS) based categories. For controlled documents the primary categories are based on the top level of the WBS. These will be the object types in the DocuShare system (as compared to a generic Document or a Collection):

Figure 1: LSST Configuration Management Workflow Process


· LPM - Project Management
· LSE – Project Systems Engineering
· LDM - Data Management
· LCA - Camera System
· LTS - Telescope & Site
· LPO – Education and Public Outreach
· LCR – Change Request

All documents (controlled or not) are require to have the following basic defined information (aka “metadata”):

· Document title
· Author
· Document Type (see 5.4.2 below)
· Document Category (see 5.4.3 below)
· Primary WBS entry
· Secondary WBS entry, if one exists

Other document meta data will be identified if needed during the duration of the project.

5.4.2. Document Types

All controlled documents will be identified as one of the following types:

·   Budget
·   Drawing
·   Interface Control Document
·   Plan
·   Policy
·   Procedure
·   Review Materials
·   Report
·   Schedule
·   Technical Note

5.4.3. Document Categories

All controlled documents will also be identified by a category based on the second and third levels of the WBS specific to each DocuShare object type defined above (see 5.4.1). These are currently defined as follows:
Project Management (LPM)
·   Management Office
·   Controls
·   Science
·   Safety & Environmental Assurance
Systems Engineering (LSE)
·   Management
·   Requirements & Traceability
·   Interface Control Document
·   Budgets and Allocations
·   Design and Performance
·   Commissioning
·   Operations
Data Management (LDM):
·   Management
·   Systems Engineering
·   Safety and Environmental Assurance
·   Applications
·   Middleware
·   Infrastructure
·   Auxiliary & Support Items
·   Integration and Testing
Camera (LCA):
·   Management
·   Systems Engineering
·   Safety and Environmental Assurance
·   Calibration
·   Utilities
·   Body and Mechanisms
·   Sensors and Rafts
·   Optical Components
·   Camera Control System
·   Cryostat
·   Electronics
·   Wavefront Sensors
·   Guide Sensors
·   Integration and Testing
Telescope and Site (LTS):
·   Management
·   Systems Engineering
·   Safety and Environmental Assurance
·   Facilities and Infrastructure
·   Dome
·   Mount
·   Primary-Tertiary Mirror
·   Secondary Mirror
·   Wavefront Sensing & Alignment
·   Calibration System
·   Software and Control
·   Observatory subsystems
·   Equipment and Support subsystems
·   Integration and Testing
Education and Public Outreach (LPO)
·   Management
·   Ongoing Activities
·   Visualization
·   Formal Education
·   Citizen Science
·   Project Astro Physics
Change Control (LCC)
·   Change Request
·   Change Notice  

Once this information is defined, along with a document title and author, a series of actions will occur:

· Support documents: the document will be filed automatically into the appropriate DocuShare folder. No formal review or approval process will be required, aside from internal reviews prior to publication or presentations.
· Formal documents: the document will be filed automatically into the appropriate DocuShare folder. Revisions are done at the author’s discretion, with appropriate internal review, but no formal review or approval process will be required.
· Configuration documents: the document will be filed automatically into the appropriate DocuShare folder. Upon completion, these documents will enter the change control loop.


Back to top

6. Document Approval & Change Control Process

Configuration documents enter a more protracted process than all other documents, as they directly impact the design baselines of the observatory. The Approval & Change Control process is the process by which configuration documents enter into change control and proposed changes to configuration documents are reviewed and approved. It ensures that the technical, cost, schedule, and risk impacts of each change are considered before approval is granted.

6.1. Initial Release

Configuration documents are placed under configuration control upon their initial release. Upon completion, the document is submitted for approval to the appropriate level (based on LSST WBS, Document Type and Category as described above) in the work flow (see Figure 1). If denied, the document is returned to the author for more work. If approved and deemed necessary, it is then submitted to the Systems Engineer. If the document is approved at that point, the Systems Engineer evaluates whether further review by the LSST Board, Project Manager (PM), Project Scientist (PS) is required or not; if not, the document passes into the Approved state. If revisions to the document are required, proceed as described in the next section. In the event that a document need review by the LSST Board the President of the LSST Corporation will act as the conduit to the LSST Board.

If further approval is required by either the PM or the PS, a similar process is followed. Either the PM or the PS can evaluate whether a document requires final approval by the LSST Board, or move it into the Approved state.

The revision process is discussed in Section 6.1.2 below.

6.2. Revisions

Updates to approved documents begins by the submission of a Change Request (CR) form. All proposed changes are assigned a classification of Class-1, Class-2, or Class-3 based on the impact on the overall system. These change classes are defined as follows:

Class-1: A proposed change that impacts any one of the following as detailed in the Project Execution Plan (PEP, see TBD):

· the ability of the project to meet a critical schedule milestone;
· the cost/schedule of a controlled item beyond limits defined in the PEP
Class-1 changes will require at a minimum the review and authorization from the PMO via the LSST Change Control Board (CCB). Most Class-1 Crs will also require the authorization by the LSST Board of Directors.

Class-2: A proposed change that impacts any one of the following:

· the ability of one of the LSST Subsystems to meet its function and design requirements;
· the interface between two or more LSST subsystems;
· the cost and/or schedule of a controlled item as defined in the PEP.
Class-2 changes are reviewed and authorized by the CCB.

Class-3: A proposed change that only impact one LSST subsystem and does not have any impact on meeting any system or LSST subsystem level functional or design requirements. These changes include correcting clerical errors and adding clarification to documents. Class-3 changes are managed and authorized by the LSST Subsystem/Group managers and systems engineers.


Setting CR class determines the approval level and establishes the approvers required for the document, and allows the CCB to distribute the CR for formal review and approval. The review, revision, and approval process is managed by the CCB until the CR has been approved by all signatories. The work flow for CRs is show graphically in Figure 2.


Figure 2: LSST Change Control Workflow Process


Once a CR is approved a Change Notice (CN) is issued and the actual document is updated in line with the changes put forth in the CN, and then is resubmitted for formal approval. This re-enters the review process at the appropriate level as determined from the original document. From that point onwards the same configuration control process outlined in above is followed.

The CR/CN is used to document the reason for the release/revision, describe impacts (if any) to the project budget and/or schedule, and to capture the approvals of all reviewers for the document. This is used in the process of evaluating the merits and impacts of a proposed change, and provides a lasting record of the change, approvals, and rationale. In particular, change requests/notices must capture four types of information regarding any change.

·   First, the CN delineates which document(s) are impacted by the change.

·   Second, the CN describes the changes. For most changes, this should include a summarized list of what the changes to the document are, including “before/after” or “was/is” lists of the changes.

·   Third, the CN discusses the reason for the change. In particular, why is the change needed and what are the benefits regarding savings in cost, schedule, or reduced risk/increased margins. This provides justification for why the change should be approved, and is used by the approvers or CCB to evaluate the benefit of the change.

·   Fourth, the CN describes the impacts of the change. This includes an estimate of the cost, schedule, and technical impact of the change on the configuration of the LSST system. If the change impacts hardware, then a complete list of serial numbers and a re-work plan needs to be included, as well.

Upon submission, a new collection is defined in the Systems Engineering Change Control section of DocuShare for this CN and all related documentation

6.3. Change Control Board Operations

If the author, Subsystem Manager, and SE determine that the proposed change requires CCB approval, then the SE will request that the Project Manager convene a CCB. The CCB is primarily responsible for reviewing all Class-1 and Class-2 CR’s based on the impact system wide costs, schedule, and technical performance. The CCB may also be called on to evaluate and approve or reject externally-initiated change requests and requests for deviation or waiver. These may originate with external review boards, subcontractors, or the Board of Directors. Also, the CCB is required to review and authorize all proposed Class-1 changes, and passes them on to the Board of Directors for final authorization as needed.

Typically, more detailed rationale for the change is required to allow for a thorough review by the CCB. Thus, the CR may need further detail, or it may refer to separate documents that provide supporting analyses of the proposed change. Note that any supporting documents should be released as part of the revision process, since they document changes to configuration controlled documents and also need to be configuration controlled themselves.

The CCB evaluates the CR, revised document(s) and any supporting material, and recommends that the CN be approved or rejected. The PM then approves or rejects the change once concurrence is obtained from the CCB members. Level 1 changes are then sent to the LSST Board of Directors for final review and approval. Once baseline configuration items are established, the CCB manages requests for changes to system-level designs and interfaces, as well as proposed draw-downs on cost, schedule and technical reserves.

The SE and PM coordinate all activities pertaining to a proposed change, to ensure that the material is complete for making a decision. Changes approved by the CCB will result in modifications to the segment and/or subsystem technical, cost and/or schedule baseline, drawing against contingency available in the total LSST project baseline. Cost and schedule changes will be implemented by the PM, with all subsequent performance measured against the new subsystem baseline. All authorized changes are reported in an accompanying CN to the original CR.

The initiator of the CR supports the CCB by assessing the change request for cost, schedule, and technical performance, scientific objectives, and risk impact. The initiator defends the CN during CCB evaluation. Subcontractors may submit out-of-scope changes for approval by the CCB. The Subsystem Manager responsible for the subcontractor reviews the change request and represents the subcontractor at the CCB.

6.3.1. CCB Membership and Responsibilities

The CCB consists of the following members:
·   LSST Corporation President (non-voting) is the conduit for all Class-1 CR going before the LSST Board of Directors.
·   Project Director
·   Project Manager serves as the CCB chair and exercises control of engineering changes and project cost and schedule. The Project manager is responsible for evaluating impacts to cost and schedule.
·   Deputy Project Manager serves as alternate CCB chair and assists in evaluating cost and schedule impacts.
·   System Scientist is responsible for evaluation of impact of the proposed change on the overall scientific performance of the system.
·   Systems Engineer is responsible for assuring the technical completeness of all change notice evaluations. Also assures the designation of the disciplines required to perform a complete evaluation of all CN’s submitted to the CCB. This responsibility includes interfacing with all team members.
·   LSST Subsystem Managers exercise control of engineering changes to his subsystem and controls the subsystem configuration. (non-voting)
·   LSST Subsystem Scientists (non-voting) assists the System Scientist evaluate the scientific impact of proposed CRs.

Back to top

Page 1