**DRAFT**

**DECam Configuration**

**Management Program**

**Version 1.1**

**July 20, 2006**

**DECAM Configuration Management Program**

**Table of Contents**

1\. PURPOSE [1](#purpose)

2\. PROGRAM OVERVIEW [1](#program-overview)

3\. SCOPE AND APPLICABILITY [2](#scope-and-applicability)

**3.1 Scope** [2](#scope)

**3.2 Applicability** [2](#applicability)

4\. ACRONYMS AND DEFINITIONS [3](#acronyms-and-definitions)

**4.1 Acronyms** [3](#acronyms)

**4.2 Definitions** [3](#definitions)

5\. RESPONSIBILITIES [5](#responsibilities)

**5.1 Project Manager** [5](#project-manager)

**5.2 Level 2 Managers** [5](#level-2-managers)

**5.3 Documentation Coordinator** [6](#documentation-coordinator)

6\. CONFIGURATION MANAGEMENT PROCESS
[6](#configuration-management-process)

**6.1 Configuration Identification** [6](#configuration-identification)

6.1.1 Baseline Definition [6](#baseline-definition)

6.1.2 Configuration Items [6](#configuration-items)

6.1.3 Configuration Items Data List [7](#configuration-items-data-list)

**6.2 Change Control** [7](#change-control)

6.2.1 Initial Release [7](#initial-release)

6.2.2 Change Control Process [7](#change-control-process)

6.2.3 Document Change Notice [8](#document-change-notice)

6.2.4 Change Request Form [8](#change-request-form)

6.2.5 PMG Operations [8](#pmg-operations)

**6.3 Configuration Status Accounting**
[9](#configuration-status-accounting)

**6.4 Configuration Verification** [9](#configuration-verification)

7\. IMPLEMENTATION OF VERSIONING CONTROL
[9](#implementation-of-versioning-control)

# 

# 

# 

# 1. PURPOSE

This Configuration Management Program (CMP) describes the configuration
management (CM) responsibilities and processes that support the design
and implementation of the Dark Energy Camera (DECAM) Project. The
purpose of this CMP is to identify the organization providing the
configuration control, define what a configuration-controlled item is,
describe the change control process, and identify the plan for
configuration status accounting and verification. This CMP is designed
to ensure that:

a)  Baselines are defined and documented,

b)  Documentation is identified, released and controlled,

c)  A Change Control Board (CCB) is established and functions according
    to CMP guidelines,

d)  Changes to the baseline are evaluated and controlled,

e)  Approved configuration changes are implemented and tracked, and

f)  Configuration status accounting is accomplished.

Systems and components specific to the DECAM Project have been reviewed
in accordance with the principles provided in ANSI/EIA-649-1998,
*National Consensus Standard for Configuration Management*.
"Configuration management practices should be applied selectively, and
to a degree commensurate with the application environment." We have
tailored the degree of rigor employed based on the functions and
importance of each system or component. Table 1 provides a summary of
the principles and a brief description of how each principle was
addressed by the Project.

# 2. PROGRAM OVERVIEW

A CMP is employed by the DECAM Project to identify and control
relationships with respect to design and construction of the DECAM
instrument. The Project recognizes the importance of maintaining clear,
concise, and accurate records in order to stay on schedule, remain
within cost constraints, and provide complete information for future
operation, maintenance, and decommissioning activities. This Program has
been established to ensure that key functional organizations, both
internal and external to Fermilab, are aware of their roles and
responsibilities during the design, construction, and testing phases of
the Project. DECAM design requirements and documents have been fully
established and will be maintained in such a way that they will be
complete and accurate throughout the lifetime of the Project.

The main goal of the DECAM CM Program is to prevent unauthorized or
uncontrolled physical hardware changes to equipment, changes to
controlled documents, and changes to controlled software. The program
integrates the various CM control systems already in place and augments
where needed. It is also meant to focus on the control of active
documents and not on longer-term records management, retention, or
archiving. Records management issues will be addressed according to the
requirements listed in DOE Order 200.1, Information Management Program.

The key elements of CM are Configuration Identification, Configuration
Change Control, Configuration Status Accounting, and Configuration
Verification. Configuration Identification defines the system 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.

For convenience, the system will be broken down into Configuration Items
(CIs). The CIs will be listed in a Configuration Items Data List (CIDL),
which lists each CI and its defining documentation. The CIDL will be
created by the DECAM Project Manager (PM) and will be maintained by the
DECAM Documentation Coordinator (with oversight by the PM) as a document
in the DES document database. The CIDL is also used to track proposed
changes to CIs. The Change Control process is the vehicle by which
proposed changes are reviewed and approved. It ensures that the
technical, cost, and schedule impacts of each major change are
considered before approval is granted. Configuration Status Accounting
is a means to track configuration information and relay it 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 and through periodic configuration audits.

# 3. SCOPE AND APPLICABILITY

## **3.1 Scope**

This CMP is applicable to all work performed as part of the DECAM
Project, which includes the design, testing, integration, and assembly
of components. It provides guidance for all personnel on CM activities
in support of the Project, including all subsystem teams,
collaborations, and subcontractors. CM is applied to items selected by
the Project Manager and includes hardware and software components along
with the related design documents, specifications, drawings, procedures
and other support documents. The scope of this CMP encompasses the
lifecycle of the Project.

## **3.2 Applicability**

In general, the following classes of documents are included in the
Configuration Management Program:

• Mechanical and electrical design drawings showing the specifications
for the equipment

and subcomponents

• Technical Design Reports

• Management documents such as the Baseline Schedule, PMP, MOU's, and
SOW's.

# 4. ACRONYMS AND DEFINITIONS

## **4.1 Acronyms**

CCB -- Change Control Board

CI -- Configuration Item

CIDL -- Configuration Items Data List

CM -- Configuration Management

CMP -- Configuration Management Program

CR -- Change Request

CTIO -- Cerro Tololo Interamerican Observatory

CVS -- Concurrent Versioning System

DCN -- Document Change Notice

DECAM -- Dark Energy Camera

DES -- Dark Energy Survey

DOE -- U.S. Department of Energy

ICD -- Interface Control Document

FNAL -- Fermi National Accelerator Laboratory (Fermilab)

L2 Manager -- Person responsible for activities at Level 2 of the Work
Breakdown Structure

L3 Manager - Person responsible for activities at Level 3 of the Work
Breakdown Structure

MOU- Memorandum of Understanding

PAC -- Physics Advisory Committee

PEP -- Project Execution Plan

PM -- Project Manager

PMG -- Project Management Group

PMP -- Project Management Plan

SRTSD -- Science Requirements and Technical Specifications Document

SOW- Statement of Work

UCL -- University College London

WBS -- Work Breakdown Structure

## **4.2 Definitions**

Baseline -- The point at which a project design or requirements are
"frozen" and after which all changes must be tracked and approved.

Change Classification - All proposed changes to Project documentation
submitted to the CCB for consideration are designated as Class I, II, or
III changes. Configuration changes may affect hardware, software,
verification requirements and the documents, drawings and procedures,
which define them.

Class I Change -- A proposed change that impacts the form, fit, or
function of DECAM as described in the DECAM PMP and in the Science
Requirements and Technical Specifications Document (SRTSD). Class I
changes are out-of-scope changes that would alter the astrophysics
capabilities of the camera in a major way or introduce a new camera
system.

Class II Change -- A change that does not alter the scope of the Project
as described in the DECAM PMP and in the SRTSD. These are in-scope.

Class III Change -- A proposed change that is not classified as Class I
or II. This includes changes that affect the design of a subsystem but
do not change the ability of that subsystem to meet its functional and
design requirements. Changes to correct clerical errors or to add
clarification to documents are also classified as Class III. Class III
changes are authorized by the manager of the originating organization.

Change Control Board (CCB) -- A board composed of technical and
administrative representatives who recommend approval or disapproval of
proposed changes to a

CI's current approved configuration documentation. This is currently
considered to be the DECAM Project Management Group (PMG).

Configuration Item (CI) -- An aggregation of hardware or software that
satisfies an end use function.

Configuration Management (CM) -- The systematic control and evaluation
of all changes to documentation that has reached a baseline point.

Pending Changes -- Pending changes are those for which conceptual design
has been approved, changes that have been approved for implementation,
or approved unincorporated changes that have been implemented in the
field but for which the document revision has not been completed.

Science Requirements and Technical Specifications Document (SRTSD) --
This document lays quantitative requirements on the fundamental
quantities that must be measured and controlled to have a successful
experiment (science requirements) and defines the technical
specifications, physical characteristics, and functioning operating
parameters of the DECAM detector needed to meet the science
requirements.

# 5. RESPONSIBILITIES

The Level 1 and Level 2 Management Structure of the DECAM Project
(reproduced from the Conceptual Design Report) is shown in Figure 1.
Below we briefly describe the CM responsibilities of the Project
Manager, the Level 2 Managers, and the Documentation Coordinator.

## **5.1 Project Manager**

The Project Manager is responsible to:

• Oversee and coordinate project configuration control activities;

• Approve all changes to the project cost and schedule baselines;

• Notify the Project Management Group of any need to change a document
or system, if the change is at a level requiring such notification, as
soon as that need is identified and determined to be valid;

• Ensure that all project CIs are identified and controlled;

• Ensure any changes to controlled documents are appropriately recorded,
tracked, and incorporated into existing drawings or documents in a
timely manner;

• Ensure any additional testing or certification required as a result of
changes are explicitly called out and included in the appropriate
places;

• Maintain a database that identifies controlled documents and owners of
those documents for the Project;

• Periodically audit the CM Program to determine the effectiveness of
the Program. This may include reviewing controlled copies of documents
to ensure their accuracy and their consistency with the master copies.

## **5.2 Level 2 Managers**

Level 2 Managers are responsible to:

• Maintain CM control over their areas of responsibility, including work
by subcontractors and collaborations;

• Notify the PM of any need to change a document or system as soon as
that need is identified and determined to be valid;

• Ensure the PM is informed of as-built changes and revisions to
controlled documents,

• Assess impacts of proposed changes on cost, schedule, resources, risk,
technical performance, and scientific objectives;

• Implement approved changes to the project cost and schedule baselines;

• Ensure that people under their authority use the latest versions of
documents available.

Some of these Level 2 responsibilities may be delegated to Level 3
Managers as needed.

## **5.3 Documentation Coordinator**

The Documentation Coordinator is responsible to:

• Maintain the document database;

• Maintain the CIDL (with oversight from the PM);

• Provide assistance in maintenance of the project web page and the CCD
testing database;

• Ensure that only the latest versions of documents are disseminated and
available for use and that outdated documents are replaced. If outdated
documents are requested for any reason, they shall be labeled as
outdated or obsolete in a clear and distinctive manner.

# 6. CONFIGURATION MANAGEMENT PROCESS

The CM process consists of four ongoing stages: (1) configuration
identification, (2) change control, (3) configuration status accounting,
and (4) configuration verification. An outline of configuration
identification and change control is shown in Figure 2; a flowchart of
the configuration management process is provided in Figure 3.

## **6.1 Configuration Identification**

Configuration identification is the ongoing process of identifying and
documenting the camera's functional and physical characteristics, from
initial requirements selection through design, development, fabrication,
test, and delivery. Configuration identification provides unique
identity to detector components as well as the configuration
documentation.

### 6.1.1 Baseline Definition

The configuration identification is developed and maintained via the
peer review process and a series of formal technical and management
reviews. The peer review process includes the Physics Advisory Committee
(PAC), the DECAM Collaboration, and the Project Management Group (PMG).
Formal reviews are conducted by the Fermilab Directorate, the U.S.
Department of Energy (DOE), and outside consulting groups in the employ
of the DOE.

### 6.1.2 Configuration Items

In order to facilitate CM, the DECAM systems and components will be
broken down into manageable units, called Configuration Items (CIs). CIs
are identified through a top-down analysis that divides the total system
into logically related and subordinate aggregates of hardware and/or
software. The main criteria is to select those items whose performance
parameters and physical characteristics can be separately defined,
tested, and managed.

### 6.1.3 Configuration Items Data List

All CIs will be listed in a Configuration Items Data List (CIDL). The
CIDL is a list containing relevant information about each CI, such as
item number, title, revision history, responsible organization and
manager, release date, etc. The CIDL will also identify the documents
that define the CI. These documents are controlled through CM and may
include, but are not limited to, specifications, drawings, interface
control documents (ICDs), software description documents, databases, and
procedures. Where the design incorporates commercial off-the-shelf
(COTS) hardware or software, the vendor part number will be used in
drawings and specifications. The design data and documentation owned by
the vendor is not subject to, and therefore not included in, the DECAM
Project CMP.

## **6.2 Change Control**

Change control is the process by which the DECAM Project Office manages
and approves the release and update of configuration-controlled items.
This process aims primarily at ensuring that only currently approved
revisions of documents are in use. Tracking features support this aim
through the maintenance of information on the current status of
documents and the provision of information on pending changes. The major
features for effective control are discussed below.

### 6.2.1 Initial Release

Drawings and documents are placed under configuration control upon their
initial release. Prior to initial release, the originator should submit
the item to peer or expert review, as applicable. Initial release is
accomplished by submitting a completed and approved Document Change
Notice (DCN) to the Project Manager via the appropriate L2 or L3
Manager. The item is then entered into the CIDL. Secure master files of
the original documents are maintained in the appropriate place. If the
document is created by an off-site facility, the off-site entity may
retain control of the master file with the express authorization of the
DECAM Project Manager.

### 6.2.2 Change Control Process

Updates to released documents are accomplished through the change
control process. This process is used to classify proposed changes and
manage the approval process accordingly. All proposed changes will be
assigned a classification of Class I, Class II or Class III based on the
level of impact to the overall system. Refer to the DECAM PMP for more
detailed information about the specifics of the change control process.
The change control process is started when a need for change is
identified and the responsible person submits a Document Change Notice
(DCN) to the appropriate manager for approval. Class III changes are
managed and controlled at the subsystem level. The DCN is used to inform
the rest of the team of approved changes and to cause the CIDL to be
updated. If the proposed change requires PMG approval, then the DCN and
an accompanying Change Request (CR) are forwarded. Prior to the PMG
meeting, the PM conducts an informal screening to make sure the CR is
complete and accurate. The PM may request additional support
documentation, reports and/or analyses for the PMG presentation. The PMG
then evaluates the CR and recommends that it be approved or rejected.
Class I changes are then sent to DOE for approval as described in the
DECAM PMP. When the appropriate level of approval has been granted, the
DCN and CR forms are routed and distributed to the Project team. The
approved CR directs the Project team to implement the change. The
Project Manager will convene a formal, internal technical review panel
if dramatic technical changes become necessary during the course of the
Project. This review will address questions relating to the need for the
proposed change, the benefits versus the cost and schedule impacts, and
the availability of adequate resources to successfully complete the
change. The change control thresholds and responsibilities are shown in
Table 2, which has been reproduced from the DECAM PMP.

### 6.2.3 Document Change Notice

A Document Change Notice (DCN) form is used to notify the Project team
that an approved change has been implemented. The DCN may announce the
release of a new revision or may be attached as an amendment to the
current revision. A copy of the DCN form is available at the end of this
CMP document.

### 6.2.4 Change Request Form

The Change Request form accompanies the DCN when submitting a proposed
change. The CR provides the information about the technical performance,
cost and schedule impacts of the proposed change. A copy of the CR form
is available at the end of this CMP document.

### 6.2.5 PMG Operations

The PMG is primarily responsible for reviewing all Class I and Class II
CRs for merit based on the impact to cost, schedule and technical
performance. The PMG may also be called on to evaluate and approve or
reject Collaboration change requests and subcontractor requests for
deviation or waiver.

## **6.3 Configuration Status Accounting**

The CIDL provides the ability to track all changes to CIs. This list
will contain information providing traceability and status of all change
requests. The CIDL will maintain the change history of all CIs so that
the evolution of the system will be documented. The CIDL serves as the
vehicle for communicating the status of configuration through periodic
reports and direct real-time inquiries.

## **6.4 Configuration Verification**

The Subsystem Managers are responsible for implementing and closing the
PMG-approved changes to CIs that are under their control. The DCN serves
as notice that a document change has been implemented and verified. The
verification of hardware changes is reported by signing the bottom of
the CR form and returning it to the PM. In this manner, all changes can
be tracked to completion and easily audited. All CIs will be audited
prior to delivery for integration into the higher-level system to ensure
that the as-built configuration conforms to the configuration
documentation.

# 7. IMPLEMENTATION OF VERSIONING CONTROL 

The DECAM Project uses an instance of the DocDB document management
system[^1] linked off the Dark Energy Survey (DES) Project Site[^2] for
control of configuration management documents. Documents that Project
Management deems necessary for control are posted in this DES DocDB
under appropriate topic classifications. The DECAM Management Committee
and all Level 1 (L1) and Level 2 (L2) managers are notified when any of
these documents are updated. DECAM L2 managers are responsible for
passing the pertinent information to their personnel. The documentation
and updates on the DES Project Site are available to the project
management staff, subsystem managers and other project personnel.

The DocDB management system is not well tailored for version control of
software. For this task, DECAM employs the Concurrent Versioning System
(CVS)[^3], which is a widely used open source software version control
system and which is in standard use at FNAL.

It is acknowledged that the DECAM is a multi-institutional project, and
that many of the collaborating institutions have different methods of
document and software version control. When obtaining documents from a
collaborating institution, FNAL will determine whether that
institution's versioning control system meets the needs of the DECAM
Project. If so, the project will work with the versioned documentation
and software as provided by the collaborating institution. If not, one
of that institution's deliverables will be versioned documents or
software that will be added to FNAL's DECAM version control systems.

Similarly, since DECAM is a multi-national project, it is understood
that different conventions for units of measure will appear on the
engineering drawings that are maintained at different institutions. For
example, drawings will also be maintained at University College London
(UCL) for WBS 1.4 (Optics) and at Cerro Tololo Interamerican Observatory
(CTIO) for WBS 1.8 (CTIO Activities and Integration), as well as at
FNAL. To avoid confusion, a description of these unit conventions and of
the conversions between different unit conventions will be maintained in
the L1 Project Management documents on the DES DocDB.

![](media/image1.jpeg){width="5.988888888888889in"
height="2.9256944444444444in"}

![](media/image2.wmf)

**Figure 3**

**DECAM Configuration Management Flowchart**

**Table 1. ANSI/EIA-649-1998 Summary of Configuration Management
Principles**

  --------- --------------------------------------------- --------------------
  **No.**   **Principle**                                 **How it is
                                                          Addressed**

  **1.**    Plan CM processes for the context and         In the CMP
            environment in which they are to be performed 
            and manage in accordance with the planning:   
            assign responsibilities; train personnel;     
            measure performance; and assess               
            measurements/trends to effect process         
            improvements.                                 

  **2.**    To determine the specific CM value adding     In the CMP
            functions and levels of emphasis for a        
            particular product, identify the context and  
            environment in which CM is to be implemented  

  **3.**    A configuration management plan describes how In the CMP
            configuration management is accomplished and  
            how consistency between the product           
            definition, the product\'s configuration, and 
            the configuration management records is       
            achieved and maintained throughout the        
            applicable phases of the product\'s life      
            cycle.                                        

  **4.**    Prepare procedures to define how each         Figure 3 (Flowchart)
            configuration management process will be      
            accomplished.                                 

  **5.**    Conduct training so that all responsible      Regular meetings
            individuals understand their roles and        with L2 Managers
            responsibilities and the procedures for       
            implementing configuration management         
            processes.                                    

  **6.**    Assess the effectiveness of CM plan           PM Responsibilities
            implementation and performance of the         
            configuration management discipline with      
            defined metrics (performance indicators).     

  **7.**    Performing configuration management includes  L2 and L3 Manager
            responsibility for the configuration          responsibilities
            management performance of subordinate         
            activities (e.g., subcontractors, suppliers). 

  **8.**    Configuration identification is the basis     PMP Change Control
            from which the configuration of products are  
            defined and verified; products and documents  
            are labeled; changes are managed; and         
            accountability is maintained.                 

  **9.**    Configuration documentation defines the       Described in the
            functional, performance, and physical         *DES Science
            attributes of a product. Other product        Requirements and
            information is derived from configuration     Technical
            documentation.                                Specifications
                                                          Document* (SRTSD)

  **10.**   The product composition (i.e. relationship    To be described in
            and quantity of parts that comprise the       CD2 documentation
            product) is determinable from its             
            configuration documentation.                  

  **11.**   All products are assigned unique identifiers  Serial #'s and test
            so that one product can be distinguished from data
            other products; one configuration of a        
            product can be distinguished from another;    
            the source of a product can be determined;    
            and the correct product information can be    
            retrieved.                                    

  **12**    Individual units of a product are assigned a  Serial #'s
            unique product unit identifier when there is  
            a need to distinguish one unit of the product 
            from another unit of the product.             

  **13**    When a product is modified, it retains its    Not Applicable
            original product unit identifier even though  
            its part identifying number is altered to     
            reflect a new configuration.                  

  **14.**   A series of like units of a product is        Not Applicable
            assigned a unique product group identifier    
            when it is unnecessary or impracticable to    
            identify individual units but nonetheless     
            necessary to correlate units to a process,    
            date, event, or test.                         
  --------- --------------------------------------------- --------------------

  --------- --------------------------------------------- --------------------
  **No.**   **Principle**                                 **How it is
                                                          Addressed**

  **15.**   All documents reflecting product performance, To be described in
            functional, or physical requirements and      CD2 documentation
            other product information are uniquely        
            identified so that they can be correctly      
            associated with the applicable configuration  
            of the product                                

  **16.**   A baseline identifies an agreed-to            Described in the
            description of the attributes of a product at SRTSD
            a point in time and provides a known          
            configuration to which changes are addressed  

  **17.**   Baselines are established by agreeing to the  Described in the
            stated definition of a product\'s attributes  SRTSD

  **18.**   The configuration of any product or any       To be described in
            document, plus the approved changes to be     CD2 documentation
            incorporated is the current baseline.         

  **19.**   Maintaining product information is important  Serial #'s
            because time consuming and expensive recovery 
            may be necessary if records of operational    
            units of a product do not match the actual    
            units (as reported by maintenance activities) 
            or such records do not exist.                 

  **20.**   For product interfaces external to the        MOU's and SOW's
            enterprise, establish an interface agreement  
            and a mutually agreed to documentation of     
            common attributes                             

  **21.**   Changes to a product are accomplished using a PMP Change Control
            systematic, measurable change process.        

  **22.**   Each change is uniquely identified.           Change Request and
                                                          DCN

  **23.**   Changes represent opportunities for           Change Request and
            improvement.                                  DCN

  **24.**   Classify requested changes to aid in          PMP Change Control
            determining the appropriate levels of review  
            and approval.                                 

  **25.**   Change requests must be clearly documented.   PMP Change Control

  **26.**   Consider the technical, support, schedule,    PMP Change Control
            and cost impacts of a requested change before 
            making a judgment as to whether the change    
            should be approved for implementation and     
            incorporation in the product and its          
            documentation                                 

  **27.**   Determine all potential effects of a change   See Figure 3
            and coordinate potential impacts with the     (flowchart)
            impacted areas of responsibility              

  **28.**   Change documentation delineates which unit(s) Not Applicable
            of the product are to be changed. Change      
            effectivity includes both production break-in 
            and retrofit/recall, as applicable            

  **29.**   A changed product should not be distributed   Not Applicable
            until support and service areas are able to   
            support it.                                   

  **30.**   Decision-maker is aware of all cost factors   PMP Change Control
            in making the decision.                       

  **31.**   Change approval decisions are made by an      PMP Change Control
            appropriate authority who can commit          
            resources to implement the change             

  **32.**   Implement an approved change in accordance    PMP Change Control
            with documented direction approved by the     
            appropriate level of authority                

  **33.**   Verify implementation of a change to ensure   See Figure 2
            consistency between the product, its          (flowchart)
            documentation and its support elements        

  **34.**   If it is considered necessary to temporarily  PMP Change Control
            depart from specified baseline requirements,  
            a variance is documented and authorized by    
            the appropriate level of authority            
  --------- --------------------------------------------- --------------------

+---+---------------------------------------------+-------------------+
| * | **Principle**                               | **How it is       |
| * |                                             | Addressed**       |
| N |                                             |                   |
| o |                                             |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | An accurate, timely information base        | Figures 2 & 3     |
| * | concerning a product and its associated     |                   |
| 3 | product information is important throughout |                   |
| 5 | the product life cycle.                     |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Configuration information, appropriate to   | Outlined in CMP   |
| * | the product, is systematically recorded,    |                   |
| 3 |                                             |                   |
| 6 |                                             |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Configuration information content evolves   | Outlined in CMP   |
| * | and is captured over the product life cycle |                   |
| 3 | as tasks occur.                             |                   |
| 7 |                                             |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Data collection and information processing  | Outlined in CMP   |
| * | system requirements are determined by the   |                   |
| 3 | need for configuration information          |                   |
| 8 |                                             |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Verification that a product\'s requirement  | Quality           |
| * | attributes have been met and the product    | Management &      |
| 3 | design meeting those attributes has been    |                   |
| 9 | accurately documented is required to        | Reviews           |
| . | baseline the product configuration          |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Verification that a design achieves its     | Quality           |
| * | goals is accomplished by a systematic       | Management &      |
| 4 | comparison of requirements with the results |                   |
| 0 | of tests, analyses, or inspections          | Reviews           |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Documentation of a product\'s definition    | Quality           |
| * | must be complete and accurate enough to     | Management &      |
| 4 | permit reproduction of the product without  |                   |
| 1 | further design effort.                      | Reviews           |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Where necessary, verification is            | Outlined in CMP   |
| * | accomplished by configuration audit         |                   |
| 4 |                                             |                   |
| 2 |                                             |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Periodic reviews verify continued           | Quality           |
| * | achievement of requirements, identify and   | Management        |
| 4 | document changes in performance, and ensure |                   |
| 3 | consistency with documentation              |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Apply configuration management principles   | Document Version  |
| * | to ensure the integrity of digital          |                   |
| 4 | representations of product information and  | Control           |
| 4 | other data                                  |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Apply digital data identification rules to  | Document Version  |
| * | maintain document, document representation, |                   |
| 4 | and file version relationships              | Control           |
| 5 |                                             |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Apply business rules using data status      | Not Applicable    |
| * | levels for access, change management, and   |                   |
| 4 | archiving of digital data documents         |                   |
| 6 |                                             |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Maintain relationships between digital      | Document Version  |
| * | data, data requirements, and the related    |                   |
| 4 | product configuration to ensure accurate    | Control           |
| 7 | data access.                                |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Apply disciplined version control to manage | Document Version  |
| * | document review electronically.             |                   |
| 4 |                                             | Control           |
| 8 |                                             |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Ensure that a transmitted digital data      | Quality           |
| * | product is usable.                          | Management        |
| 4 |                                             |                   |
| 9 |                                             |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+
| * | Effective digital data access fulfills      | Not Applicable    |
| * | requirements, preserves rights, and         |                   |
| 5 | provides users with data they are entitled  |                   |
| 0 | to in the correct version.                  |                   |
| . |                                             |                   |
| * |                                             |                   |
| * |                                             |                   |
+---+---------------------------------------------+-------------------+

**Table 2.**

+--------+-------------+--------------+--------------+----------------+
| Change |             |              |              |                |
| C      |             |              |              |                |
| ontrol |             |              |              |                |
| Ap     |             |              |              |                |
| proval |             |              |              |                |
| Thre   |             |              |              |                |
| sholds |             |              |              |                |
| for    |             |              |              |                |
| DECam  |             |              |              |                |
+--------+-------------+--------------+--------------+----------------+
|        | **Level 1** | **Level 2**  | **Level 3**  | **Level 4**    |
+--------+-------------+--------------+--------------+----------------+
| *      | Acquisition | Federal      | Fermilab     | Fermilab DECam |
| *Autho | Executive / | Project      | Associate    | Project        |
| rity** |             | Director     | Director for | Manager        |
|        | SC --       |              | Research     |                |
|        | Associate   |              |              |                |
|        | Director    |              |              |                |
+--------+-------------+--------------+--------------+----------------+
| *      | Any change  | N/A          | Any change   | Any change in  |
| *Techn | in scope    |              | that affects | the scope as   |
| ical** | that        |              | the          | described in   |
|        | affects the |              | technical    | the Technical  |
|        | mission     |              | performance  | Design Report  |
|        | need        |              | or baseline, |                |
|        | r           |              | or ES&H      |                |
|        | equirements |              | requirements |                |
|        |             |              | as defined   |                |
|        |             |              | in the PMP   |                |
+--------+-------------+--------------+--------------+----------------+
| **     | Any         | Any use of   | Any use of   | Any use of     |
| Cost** | increase in | DOE          | DOE          | contingency    |
|        | the TEC or  | contingency  | contingency  |                |
|        | TPC         | that would   | that would   |                |
|        |             | take the     | take the     |                |
|        |             | contingency  | contingency  |                |
|        |             | as a         | as a         |                |
|        |             | percentage   | percentage   |                |
|        |             | of the DOE   | of the DOE   |                |
|        |             | MIE ETC      | MIE ETC      |                |
|        |             | below 25-30% | below 25-30% |                |
|        |             | (TBD)        | (TBD)        |                |
+--------+-------------+--------------+--------------+----------------+
| **Sche | Any change  | Any change   | Any change   | Any change     |
| dule** | to level 1  | to level 2   | greater than | greater than 2 |
|        | milestones  | milestones   | 3 months to  | weeks to level |
|        |             |              | level 3      | 3 milestones   |
|        |             |              | milestones   |                |
+--------+-------------+--------------+--------------+----------------+

  -------------------------- -------------------------------- ------------
  **FUNCTION**               **SIGNATURE**                    **DATE**

  L2 Manager                                                  

  Responsible Project                                         
  Engineer                                                    

  Project Manager                                             

  Directorate                                                 

  Other (specify)                                             
  -------------------------- -------------------------------- ------------

![](media/image3.wmf)

![](media/image3.wmf)

![](media/image3.wmf)

[^1]: Eric W. Vaandering and Lynn Garren, *BTeV Document Database Design
    and Interface*, BTeV-doc-140 (2001).

[^2]: https://www.darkenergysurvey.org/the-project

[^3]: http://www.nongnu.org/cvs/