TENNESSEE STATE UNIVERSITY

CENTER OF EXCELLENCE IN INFORMATION

SYSTEMS ENGINEERING AND MANAGEMENT

CENTER FOR AUTOMATED SPACE SCIENCE

(CASS)

AUTOMATIC SPECTROSCOPIC TELESCOPE (AST) PROJECT

CONFIGURATION MANAGEMENT PLAN

AST-Plan-101

OCTOBER 21, 1999

Configuration Management Plan

for

Automatic Spectroscopic Telescope (AST) Project

Prepared by:

_________________________________________

Bervil D. Davis, PhD. Date
Consultant
Pace & Waite, Inc.

Concurrence:

_________________________________________

Joel A. Eaton, PhD. Date
Technical Manager
Automatic Spectroscopic Telescope Project
Tennessee State University

Approval:

_________________________________________

Michael R. Busby, PhD. Date
Director, Center for Automated Space Science
Tennessee State University

AUTOMATIC SPECTROSCOPIC TELESCOPE

PROJECT (AST)

CONFIGURATION MANAGEMENT PLAN

TABLE OF CONTENTS

1.0 SCOPE 1

2.0 APPLICABLE DOCUMENTS 1

3.0 DEFINITIONS/ACRONYMS 1

4.0 INTRODUCTION 1

5.0 QUALITY RECORDS 2

6.0 ORGANIZATION 2

7.0 CONFIGURATION IDENTIFICATION 3

8.0 CONFIGURATION CONTROL 4

9.0 CONFIGURATION CONTROL DOCUMENTATION 5

10.0 CONFIGURATION ACCOUNTING 7

11.0 END ITEM CONFIGURATION VERIFICATION 7

LIST OF APPENDICES

Appendix A Definitions / Acronyms 9

Appendix B Forms 10

CONFIGURATION MANAGEMENT PLAN

For the

AUTOMATIC SPECTROSCOPIC TELESCOPE (AST) PROJECT

1.0 SCOPE

This Configuration Management Plan for the Automatic Spectroscopic Telescope (AST) provides instructions of how configuration management (CM) will be implemented, including policies and procedures. This CM Plan provides a documented plan for compliance with NPG7120.5A, NASA Program and Project Management Processes and Requirements. NPG7120.5A defines configuration management as the identification, control, accounting, and verification of requirements and implementation documentation for formal orderly control of the program/project configuration. The configuration management system shall maintain traceability to project requirements.

2.0 APPLICABLE DOCUMENTS

NPG7120.5A NASA Program and Project Management Processes and Requirements

3.0 DEFINITIONS/ACRONYMS

Definitions and Acronyms used in this plan are provided in Appendix A.

4.0 INTRODUCTION

4.1 General - This AST Configuration Plan defines requirements, responsibilities, and procedures for the configuration management system which will be applied to the AST Project at Tennessee State University (TSU). The total AST system consists of the 2-meter telescope, telescope mount, spectrograph, detector, and the data handling system. For simplification, these items, along with the integration effort shall be referred to as the AST System.

The AST configurations will be identified by base-lining technical documentation at progressive project milestones. The hardware/software will progress from requirements to detailed design to hardware/software through this base-lining process. Any changes to baselines will be controlled and verified through the CM system described in this plan.

This plan meets the requirements of the AST Project Plan.

4.2 Objectives - CM is an element of management. It provides a disciplined method for establishment, control, accounting, and verification of the various baselines. The CM system helps ensure that technical requirements are identified and documented, accurately translated into the design and that the design is translated correctly into hardware/software.

The CM system provides the project with a formal method to meet the following objectives:

5.0 QUALITY RECORDS

The quality records consists of the CM Plan, base-lined documents and specifications, drawings and the Master files that include all project records, including configuration changes. The AST Project Office will be the custodian of these files. The authority for this configuration system is the AST Project Plan. The Configuration Control Board (CCB) will control maintenance of the AST documentation/software. Records shall be retained for at least two years after Project completion.

6.0 ORGANIZATION

6.1 CASS PI - The AST Project Management Plan states the requirement for this Configuration Management Plan. The AST CASS Principal Investigator (PI) shall ensure compliance with the policies, requirements and procedures of this plan. The PI shall:

6.2 Technical Manager - The AST Technical Manager shall authorize and ensure compliance with the policies, requirements, and procedures stated within this plan. Specific responsibilities include, but are not limited to:

7.0 CONFIGURATION IDENTIFICATION

7.1 General - The functional and performance requirements will be defined in the System Requirements Document. The physical requirements of the AST will be documented in the engineering drawings and associated lists. Specifications and/or Source Control drawings may be needed and used to define component performance, functional and physical requirements. Part, subassembly and end item identification will be accomplished via part identification.

7.2 Configuration Baselines - Configuration baselines will be established after completion of the respective Preliminary Design Review (PDR). The project reviews are described in Section 11.0 of this plan.

7.3 Design Requirements Baseline - This requirement is established after completion of the Preliminary Design Review (PDR). The baseline consists of the System Requirements Document.

7.4 Drawing Baseline and Release - The Change Proposal (CP) process will be utilized to ensure that all changes to the baseline are coordinated, documented, and available for future reference and use. All changes must originate with the designer and proceed through the Technical Manager. This baseline approach allows for early manufacturing of components under the auspices of the Technical Manager. The baseline is established to document the designs and all changes thereto as the design matures. TSU shall keep a “master” paper copy of all base-lined drawings for the AST Project.

Drawings base-lined after July 1, 1999 shall be stamped “AST Baseline” and a date placed in the signature block on the drawing. Drawing “Release” is established after satisfactory completion of the Critical Design Review (CDR) and is defined as the formal release of detailed design documentation (drawings, specifications, plans, etc.), along with completed analysis.

7.5 End Item Configuration Baseline - This baseline is established after manufacturing and acceptance of hardware/software. It consists of all documentation, which defines the as-built configuration (drawing/documentation plus all changes and deviations/waivers to the released design). TSU shall establish a “master” paper copy of these drawings that reflect, as closely as possible, the AST system as-built and mark them “final”.

8.0 CONFIGURATION CONTROL

8.1 General - Configuration control is the systematic definition, evaluation, coordination, and disposition of each proposed change, deviation, or waiver, and the implementation of each approved change into the project configuration. A formal change control system will be established for the management of the AST configuration. All changes to the configuration baselines shall be formally controlled as specified herein.

8.2 Configuration Control Board - The control of programmatic changes, engineering changes, deviations and waivers to the AST baseline will be achieved through the use of a CCB. The CCB chairperson is responsible for presiding at board meetings and for the disposition of all changes submitted, based on considerations of technical need and justification, cost/schedule impact, and design/hardware impact.

8.3 Change Packages - All change packages presented to the CCB will include a description of the proposed change, identifying which documents/drawings would be affected, including a technical justification, expected impact the change may cause to the project cost and schedule. Also, it will describe the effect on performance, cost, schedule, etc. if the change is not incorporated. The person recommending the change will prepare a change packet and deposit it in the change-packet folder for CCB disposition.

8.4 Change Evaluators - AST Project and Center for Automated Space Science (CASS) personnel with familiarity with the Project will be change evaluators. These personnel will evaluate the subject change and provide recommendations, and any known impacts, regarding disposition. The recommended disposition and impact statements will be documented on a Change Evaluation Sheet, which will be provided by the CCB Secretariat.

8.5 CCB Membership - The CCB membership will include the following:

8.6 CCB Membership Responsibilities - Each CCB member will evaluate each change submitted to the CCB, identify all impacts to the member’s area of responsibility, and will denote agreement or disagreement with the chairperson’s disposition of the change via initialing the appropriate box on the CCB Directive.

All CCB members shall agree or disagree with the change disposition. Should a member disagree with the chairperson’s disposition, he/she will provide to the chairperson and the board secretariat a written record of disagreement with rationale within 24 hours of the board meeting. After disposition of a change, it CANNOT be altered without CCB direction on a revised CCBD.

8.7 CCB Chairperson Responsibilities - The Chairperson will make the final decision on all changes pending before the CCB and will have the following actions taken:

8.8 CCB Secretariat Responsibilities - The CCB Secretariat will perform the following duties in support of the CCB.

9.0 CONFIGURATION CONTROL DOCUMENTATION

9.1 Change Documentation - Any person associated with the AST Project may initiate a change affecting already established baselines and/or released documentation. Change documentation as described below will be used to propose changes.

Engineering changes should be held to a minimum, consistent with the safety and overall effectiveness, reliability, performance, and mission accomplishment of the system. Before initiation of a change, preliminary informal interchange of engineering data between Project personnel is encouraged. This interchange will help determine the engineering feasibility or desirability of a change. Changes will be submitted to the CCB Secretariat using the following forms:

A copy of the forms identified above are provided in Appendix B. The Change Proposal Form will include all information necessary for an evaluator to make an intelligent decision regarding the change. The description of the change on the CP shall be clearly written as to leave no doubt as to what is to be changed.

9.2 Change Classification - A class I change is defined as:

A Class II change is defined as any non-interface change. The class II change may be processed outside of a formal CCB meeting at the discretion of the CCB Chairperson. As a minimum, the Class II change shall be reviewed and approved by the Technical Manager.

9.3 Change Priorities - Normally, all change requests, proposals and deviations and waivers will be assigned a change priority such as emergency, urgent, or routine based on the degree of urgency of the change. The Change priority will be suggested by the change submitter and agreed to by the Technical Manager. All Changes should be processed and implemented as soon as feasibly possible to prevent costly delays.

9.4 Change Request/Proposal Numbering - Each change proposal will be assigned a unique identification number. CP’s will be assigned identification numbers by the CCB Secretary. The CP number will consist of a three-digit prefix followed by the Project identifier plus a four-digit numeric, e.g., AST-System-XXXX.

9.5 Change Packaging - Each change request/proposal shall be assigned to a change package. Related change request/proposals will be integrated into the same change package to assure the total impact is determined prior to disposition.

A change package shall only contain data related to that change. The change package shall not contain multi-unrelated changes. Proper change packaging and integration dictates a disciplined system adhered to by all parties and elements involved from change initiation through total change implementation.

9.6 Program Control Number (PCN) - A PCN numbering system must be established such that a tracking record can be maintained for each assigned Change request.

9.7 Deviation and Waivers - A deviation is a specific written authorization, granted before manufacture, to depart from a particular baseline requirement for a limited application. A waiver is a written authorization accepting a departure, after occurrence, from a baseline requirement, normally limited to a single application or end item. Deviations and waivers shall not be used to change baseline requirements.

9.8 Drawing Change Record and Numbering System - The Drawing Change Record (DCR) is the equivalent of an Engineering Order (EO). Its purpose is to propose, process, implement, and close out engineering changes to official base-lined drawings. Changes to base-lined drawings may be accomplished using a drawing revision or a DCR/EO at the discretion of the design organization. A CCB approved drawing change results in a DCR/EO. This DCR/EO is attached to the drawing until it is incorporated into the drawing. No more than five should be attached to a drawing until they are incorporated into the drawing.

The Drawing Change Records require a numbering system for tracking purposes. The Technical Manager will establish a numbering system or use an existing one. The Secretariat will assign a DCR number to each change that is approved and affix the number to the DCR in order to prevent duplicate numbers from being simultaneously issued. This number must be assigned and affixed to the DCR prior to release for review. The CCB Secretariat shall maintain a log of DCR numbers.

10.0 CONFIGURATION ACCOUNTING

A configuration accounting system is needed to keep track of all processed changes. An existing system may be used or a new one developed. Typically, this system is called “Change Processing Tracking, and Accounting System” and is computerized for efficiency and speed.

11.0 END ITEM CONFIGURATION VERIFICATION

Verification of the hardware configuration assures that all requirements and engineering changes have been correctly translated into the hardware/software. Periodic verification is performed during design reviews when the progressive project baseline is established. Tools used to achieve this continuous verification are the release system, accounting system, manufacturing practices, inspection, audit, and surveillance practices.

11.1 Reviews and Inspections - The AST Project Office has conducted a Systems Requirements Review (SRR), and a Preliminary Design Review (PDR), and it will conduct a Configuration Inspection (CI).

11.2 Systems Requirements Review (SRR) - The SRR is the earliest technical review of the configuration concepts and requirements that will meet the mission objectives. The SRR provides an overview of requirements development, verification and compliance processes, facility requirements, and a systems overview of the various test article, ground, and operations requirements interactions. Data required at the review may include drawings/sketches, study

reports, analyses, design concept documents, preliminary interface requirements, requirements specifications, preliminary WBS, general test plans, software requirements, draft End Item (EI) Specifications and trade studies.

11.3 Preliminary Design Review (PDR) - The PDR establishes the basic design approach and reviews the compatibility of the design with the project requirements. Successful completion of the PDR establishes the design requirements baseline and authorizes the project to proceed with detailed design. The PDR provides a safety assessment, an overview of test planning, design producibility, and verification requirements. Data required for the review may include preliminary design drawings, preliminary interface control documents (ICD)s, flow diagrams, safety analysis, preliminary Hazard Analysis/Risk Assessment, test verification/validation plans, base-lined configuration management plan, interface requirements, systems description document, software document, spares philosophy, preliminary ground support equipment (GSE) requirements, updated design requirements specifications, updated fracture plan, preliminary strength and fracture mechanics, and proof of concept engineering analysis.

11.4 Critical Design Review (CDR) - The CDR establishes the detail design configuration and assures compatibility of the detail design with the design requirements specification and higher level requirements. It is held when the design and drawings are essentially complete.

The CDR provides reliability, maintainability, and safety assessment, establishes producibility, approves the drawing baseline, and authorizes release of the detail design for fabrication and procurement. Data requirements for the review include software definition, detail design/drawings, ICD’s, preliminary test results, integration plans and procedures, subsystem description documents, test site requirements, design specifications, component, subsystem and system test plans, analyses reports, safety analysis/risk assessment, and spares list.

11.5 Configuration Inspections - The Configuration Inspection (CI) review is a formal inspection of the hardware/software conducted to assure that the design and performance of the item meets the requirements specification. This review will also establish that the configuration complies with the design documentation (“as required” vs “as built”). This CI shall examine all technical data and planning intended to demonstrate that the as designed/as built/as analyzed item will meet all design, technical, configuration, performance, interface, safety, and documentation requirements. The CI will be performed by TSU prior to hardware/software testing. As with other reviews, the Configuration Inspection may be performed incrementally.

11.6 Other Review and Inspections - Other reviews and inspections may be conducted on an as needed basis. These reviews/inspections/audits will be initiated and identified at the discretion of the Technical Manager.

---------------------------------------------------------------------------------------

APPENDIX A

DEFINITIONS / ACRONYMS

---------------------------------------------------------------------------------------

APPENDIX B

FORMS

1. Change Proposal Form (omitted)

2. Change Evaluation Form (omitted)

3. Change Concurrence Form (omitted)

4. Drawing Change Record (omitted)