ACIS Science Instrument Software Management Plan

36-01208 Rev. A

Massachusetts Institute of Technology
Center for Space Research
Covers MM8075.1 - DM01
May 21, 1995

Table of Contents

1.0 Introduction

The AXAF-I CCD Imaging Spectrometer (ACIS) Science Instrument Software is being developed by the Massachusetts Institute of Technology, Center for Space Research (MIT-CSR) as part of the ACIS Digital Processor Assembly (DPA). The DPA resides on-board the Advanced X-ray Astrophysics Facility - Imaging (AXAF-I). The DPA Science Instrument Software is responsible for acquiring, and processing image data from the ACIS CCD Imaging Spectrometer and transferring the processed data to the AXAF-I Command and Telemetry Unit (CTU), which is then responsible for sending the information to the ground.

1.1 Purpose

The ACIS Science Instrument Software Management Plan establishes the software management policies for the ACIS DPA Science Instrument Software and defines the means by which these policies are implemented.

1.2 Scope

This document applies to the critical and non-critical components of the ACIS DPA Science Instrument Software. It does not provide information for the Ground Support Software (GSS), which is maintained separately as part of the Electronic Ground Support Equipment (EGSE).

This document supplies information applicable to the Software Management portion of SMA01-P. This document conforms to the content and format requirements described in MM 8075.1 - DM01.

MSFC Software Management and Development Requirements Manual MM8075.1 supersedes MA-001-006-2H.

The Software Quality Assurance requirements components of this plan, mandated by CQ5330.1, are provided in a separate document, the ACIS Software Quality Assurance Plan.

The ACIS software development schedule is not supplied within this document, but is provided as part of the ACIS Master Schedule.

2.0 References


TABLE 1. Reference Table
--------------------------------------------------------------------------------
Part Number       Title
--------------------------------------------------------------------------------
MSFC MM 8075.1    MSFC Software Management and Development Requirements Manual,
                  January 22, 1991
MIT-CSR 36-01201  ACIS Program Management Plan
MIT-CSR 36-01206  ACIS Configuration Management Plan
MIT-CSR 36-01209  ACIS Science Instrument Software Development Plan
MIT-CSR 36-01212  ACIS Software Quality Assurance Plan
-                 ACIS Master Schedule
--------------------------------------------------------------------------------

3.0 Software Development Cycle

The ACIS DPA Science Instrument Software shall be developed in the following major software phases:

The Requirements Phase starts with the top level systems requirements definition and ends with the Software Requirements Audit (SWRA). The Software Requirements are developed during this period and are placed under configuration control after the SWPDR. This allows development to proceed after the preliminary design review with stable goals and objectives.

The Design Phase starts after the Software Requirements have been defined and ends with the Software Critical Design Review (SWCDR). The Software Detailed Design is developed during this period. Prototype versions of the design may also be implemented and tested during the Design Phase. The Software Preliminary Design Review (SWPDR) is held during the early part of the Design Phase. The period prior to SWPDR is called the Preliminary Design Phase.

The Implementation Phase starts after the Software Detailed Design is available and ends with the Software Test Review (SWTR). Most of the coding, unit testing and unit integration testing occurs during this period, with version-controlled test software and with the results being accessible on a per-unit basis (i.e. via unit development folders or facilities provided by the version control system). System test development also starts during this phase, again, with the test software under version control and a maintained history of test results.

The Testing Phase starts once the baseline Science Instrument Software is available for internal testing and ends with the release of the Science Instrument Software for Systems Integration. Most of the internal integration and DPA systems testing occurs during this period. This testing will make use of written test procedures, with all procedures, tools and test data maintained under version control. A history of test results will be maintained during this phase.

The Systems Integration Phase starts when the DPA is released for Systems Integration and ends with the release of the DPA and the Configuration Inspection (CI). The activities during this phase involve supporting the Systems Integration activities, supporting the Instrument and Ground Support Equipment verification and acceptance tests, and updating the documentation.

The Support and Maintenance phase starts when organizations other than the ACIS development team (including SQA) start using the DPA. The activities during this phase involve providing support for these organizations and activities. The DPA Science Instrument Software maintenance information and software are supplied to the AXAF Science Center (ASC) during this phase.

4.0 Configuration Management Plan

4.1 ACIS Configuration Management

The ACIS Science Instrument Software and documentation shall conform to the rules and procedures described in the ACIS Configuration Management Plan. In addition to these rules and procedures, the Science Instrument Software shall use additional rules and procedures identified in Section 4.2 and Section 4.3 of this document.

4.1.1 Identification

The ACIS Configuration Management Plan identifies each controlled item using a unique part number and revision. From the software's point of view, controllable items include items such as design documents, source files, build scripts, and releasable load images.

The base MIT-CSR drawing number for the Science Instrument Software is 36-5xxxx.

The Science Instrument Software parts are organized into the following categories, with the respective base drawing numbers:

36-51xxx
Science Instrument Software Requirements Specifications

36-52xxx
Science Instrument Software Interfaces Control Documents

36-53xxx
Science Instrument Software Design Documentation and Source Code

36-54xxx
Science Instrument Software Executables and Documentation

36-55xxx
Tool Documentation, Source and Executables

36-56xxx
Trade Studies and Analyses

4.1.2 Configuration Control

As described in the ACIS Configuration Management Plan, all releases of controllable items are accomplished using an Engineering Change Order (ECO). Pre-releases are made using ECOs and incrementing numeric revision identifiers. Formal releases are made using ECOs and advancing alphabetic revision identifiers. The Systems Engineer and Project Engineer sign all ECOs and the Assistant Program Manager updates the Configuration Data Base. The Software Project Manager will ensure that Software Quality Assurance is made aware of all ECOs involving alphabetic revisions.

4.1.3 Application

All internally developed and externally procured software components included in the Science Instrument Software shall be assigned an MIT-CSR Configuration Number and shall be placed under Configuration Control.

All externally produced Interface Control Documents (ICD) shall be assigned an internal MIT-CSR Configuration Identifier and shall be placed under Configuration Control.

4.2 Electronic Identification

All internally and externally released software, including software load images, shall contain an embedded part number and a internal version identifier. The part number shall match the drawing number used by the ACIS Configuration Data Base (CDB). The internal version identifier shall be associated with the CDB version number or letter via the release's Engineering Change Order (ECO). The part number and internal version identifier shall be unique to a given release of software.

Released binary software images shall contain an integrity check code. This check code shall be included on the release's ECO. This check code is used to verify the integrity of the released image.

4.3 Electronic Configuration Control

All Science Instrument Software ECOs shall contain enough information to determine all of the software components and versions built into the release. This shall be accomplished using a symbolic electronic source control tag tied to the version of each component in the release. Refer to the ACIS Configuration Management Plan and Software Quality Assurance Plan for a description of numeric and alphabetic release definitions and procedures.

Source control tag strings use the following convention:

The absence of a tag on a particular version of a file indicates that the file is a working copy, and that it has not been reviewed nor tested. Such versions are inappropriate for internal or external release. The purpose of this tag is to encourage developers to make checkpoints of versions of their products.
This tag is equivalent to "No tag" except it provides a way individual developers can privately share and integrate their work prior to formal unit test and code review. The "#" (i.e. working-23) allows the developer to mark specific versions and to checkpoint groups of files.
This tag is reserved for versions which have undergone peer review and unit test. This tag marks a collection of units ready for integration or internal release. "#" allows several multiple peer review and unit test cycles. The transition from a "working" or "No Tag" version of a file to a "stable" version is made by the Software Development Manager or Lead Software Engineer and requires a "numeric" Engineering Change Order (ECO).
This tag is reserved for versions of items ready to be released for test with, or installation into, ACIS Flight Hardware. Items with this tag must have undergone formal internal review and sign-off. Code must have completed integration testing and be ready for systems test. "#" allows multiple releases of the software. The transition from a "stable" version to a "release" version is made by the Software Development Manager or Lead Software Engineer after consultation with SQA and requires an "alphabetic" ECO, with approvals as specified in the ACIS Configuration Management Plan.
All in-house Science Instrument Software source code, and in-house tools which directly affect the released software images, shall be maintained using an electronic source control system, such as RCS.

All off-the-shelf software used in the Science Instrument Software, or off-the-shelf tools which affect the released images, shall be maintained by vendor, version number and supplied file sizes. When appropriate, such software will also be placed under electronic source control.

5.0 Approval Authority

The Project Manager has approval authority for all software milestones, requirement reviews, design reviews, acceptance reviews, documents, ECOs and software releases.

6.0 Group Charters and Responsibilities

6.1 Digital Processing Assembly Development Team

The Digital Processing Assembly (DPA) Development Team is responsible for coordinating the interfaces between the hardware and software on the DPA. This group is lead by the systems engineer, and includes representatives from the DPA Hardware development team, and representatives from the Science Instrument Software development team.

6.2 Science Instrument Software Development Team

The Science Instrument Software Development Team is responsible for the design, implementation, and documentation of the Science Instrument Software contained in the ACIS Flight Digital Processor Assembly (DPA). This team consists of a group of software developers, headed by a Software Development Manager. The Software Development Manager is responsible for all resource management, scheduling, and external interface negotiation and coordination. The Development Manager also has input and approval authority over all major requirements, architectural, design, implementation and test issues. Individual developers are responsible for varying stages of development, from the design of major software sections, to the implementation and test of individual units.

7.0 Facilities

The ACIS Science Instrument Software development requires the following standard items:

Most of these items are already in place at MIT-CSR, although additional disk resources, and network management resources are required. The Software Development Team will identify needed development software and either purchase the software, or develop the software in-house.

Facilities planning will be performed by the Software Development Team, coordinated with the rest of the ACIS development group and MIT-CSR Systems Administration.

In addition to the standard items listed above, the following custom-built items are required:

DPA breadboard hardware is experimental hardware used to evaluate the initial hardware design. It is usually built using wire-wrap and can easily be modified. DPA brassboard hardware is treated as the engineering prototype of the final flight hardware design. Brassboard hardware uses the prototype board layout of the flight design, but uses non-flight parts. The DPA Hardware development team will provide both breadboard and brassboard hardware. The DPA Hardware development team will maintain the brassboard hardware functionality and interfaces to be consistent with the final flight hardware design. DPA breadboard hardware will be provided prior to SWCDR and brassboard hardware will be provided prior to SWTR.

Hardware which simulates the functional ACIS/RCTU interface will be provided prior to SWCDR by TRW. The Software Development Team will develop its own test software for producing commands and interpreting telemetry prior to SWCDR. The final Spacecraft RCTU and CTU simulators will be provided by the spacecraft developers (TRW) prior to the ACIS SWTR. The CCD event simulation equipment and/or software will be provided prior to SWCDR by MIT.

8.0 Software Documentation

This section lists the Science Instrument Software Data Requirements List (DRL). The ACIS Software DRL is tailored from the MSFC Software Management and Development Requirements Manual (MM 8075.1). The DRL is derived from the Preliminary Data Requirements List for a Category B project. Except for the Configuration Data Base, the listed documents will be provided by either Software Development, Software Quality Assurance (SQA), or Quality Assurance (QA) as indicated. The Configuration Data Base is maintained as described in the ACIS Configuration Management Plan (see Section 4.1.2 on page 6). Software Quality Assurance will be given the opportunity to review all documents before their release.

The major software reviews and milestones are as follows:


TABLE 2. Major Software Reviews and Milestones
-----------------------------------------------------
Name                                          Acronym
-----------------------------------------------------
Systems Requirements Review                   SRR
Software Requirements Audit                   SWRA
Software Preliminary Design Review            SWPDR
Software Critical Design Review               SWCDR
Software Test Review                          SWTR
Software Functional Configuration Inspection  SWFCI
Software Configuration Inspection             SWCI
Software Acceptance Review                    SWAR
Software Miscellaneous Periodic Reports       SWMSC
-----------------------------------------------------
The following table lists each document according to MM8075.1, its source of input and due date, and maps the document to the governing item from the Project Statement of Work:


TABLE 3. Data Requirements List
------------------------------------------------------------------------------
Contract   Document                    Responsibility      Sources                Due by
DR Item
------------------------------------------------------------------------------
SMA01-P    DM01-SW Management Plan     SW Development      Program Management     SWRA
                                                           Plan
SMA01-P    DM02-SW Development Plan    SW Development      Program Management     SWRA
                                                           Plan, SW Management
                                                           Plan
SMA01-P    DM03-SW Quality Assurance   SQA                 Program Management     SWPDR
           Plan                                            Plan
SDM02      DM06-SW Requirements        SW Development      Science Requirements   SWRA
           Specification                                   Specification
SPA04      DM07-SW Fault Tolerance     SW Development      Hardware FT and        SWPDR
           and FMEA                                        FMEA
SDM03      DM08-Preliminary SW         SW Development      SW Development Plan,   SWPDR
           Design Specification                            SW Requirements,
                                                           FT&FMEA
SDM03      DM09-Detailed SW Design     SW Development      Preliminary SW         SWCDR
           Spec (CODE-TO)                                  Design Spec, SWPDR
                                                           comments
SDM03      DM09-Detailed SW Design     SW Development      Detailed SW Design,    SWCI
           Spec (AS-BUILT)                                 SWCDR comments
SMA03      DM11-SW Status/Problem      SQA                 SQA Plan               SWCDR
           Report Plan
SMA03      DM12-SW Status/Problem      SQA                 Status/Problem         SWMSC
           Reports                                         Reports Plan, testing
SDM03      DM13-Software Maintenance   SW Development      SW Development Plan    SWCDR
           Document
SMA01-O    DM16-Software Schedules     SW Development      SW Development Plan    SWRA
           Document
SDM07      DM18-Software Test Plan     SQA                 SW Test Req.           SWPDR
SDM08      DM20-SW Verification Test   QA                  SW Requirements        SWCDR
and        Spec
SDM09
SDM08      DM22-SW/Sys Acceptance      QA                  SW Requirements        SWCDR
and        Test Spec
SDM09
SDM10      DM23-SW Verification Test   QA                  SW Verification Spec.  SWFCI
           Reports
SDM10      DM25-SW/Sys Acceptance      QA                  SW Acceptance. Spec.   SWAR
           Test Reports
SSE04      DM28-Configuration Data     Assistant Program   All controlled items   SWFCI
           File Document               Manager
SDM05      DM29-Software Operator      SW Development      SW Requirements, SW    SWCI
           Manual                                          Detailed Design, SW
                                                           Maintenance
------------------------------------------------------------------------------
The following table lists combined or omitted specifications:


TABLE 4. Combined or Omitted Specifications
-----------------------------------------------------------------------------
Document                                Status    Reason
-----------------------------------------------------------------------------
DM04-SW Standards and Procedures Spec.  Combined  Elements shall be incorporated into
                                                  DM02 - SW Development Plan
DM05-SW High Order Language Study       Combined  Elements shall be incorporated into
                                                  DM02-SW Development Plan
DM10-Programmer Development Handbook    Omitted   Inappropriate for Category B projects
DM14-SW Library Catalog                 Omitted   Inappropriate for Category B projects
DM15-Programmer Reference Manual        Combined  Elements shall be incorporated into
                                                  DM29-SW Operator Manual
DM17-SW Test Requirements Document      Combined  Elements shall be incorporated into
                                                  DM18-SW Test Plan
DM19-SW Development Test Specification  Combined  Elements shall be incorporated into
                                                  DM18-SW Test Plan
DM21-SW Validation Test Specification   Combined  Elements shall be incorporated into
                                                  DM20-SW Verification Test Spec.
DM24-SW Validation Test Reports         Combined  Elements shall be incorporated into
                                                  DM20-SW Verification Test Reports
DM26-Post-Flight SW Evaluation          Omitted   Inappropriate for single-mission SW
DM27-SW Training Plan                   Omitted   ASC responsible for Operations
-----------------------------------------------------------------------------
In addition to the data requirements listed above, the ACIS development team shall internally maintain two types of tracking information, either collected physically in a folder, or grouped electronically using version control tags and aliases. The first type of information is organized around a single unit. This information will document the current state of the unit, the test program for the unit, the latest unit test report, and any developer notes which apply to the unit (i.e. a unit development folder).

Realizing that no unit stands alone, the second type of information is organized around the system features. This information will document the level of completion of the feature, the test programs, scripts and data for the feature, the current scenario describing the use of the feature, and a current list of participating units needed to implement the feature (i.e. a feature folder).

9.0 Interface Control

All external interfaces are specified and controlled using Interface Control Documents (ICDs). All externally produced ICDs are assigned an internal MIT-CSR part number and version and are placed under Configuration Control (refer to the ACIS Configuration Management Plan for a detailed description of how ACIS hardware and software documents are controlled).

10.0 Quality Assurance Requirements

The Software Development Team, with advice from Software Quality Assurance, is responsible for establishing and implementing all quality assurance requirements. These requirements are subject to review by Software Quality Assurance, which is responsible for ensuring compliance to the developed requirements. The details of the ACIS Software Quality Assurance approach is described in the Software Quality Assurance Plan (SQAP). Software Quality Assurance will inform the Software Development Manager of the results of all software quality audits.

11.0 Status Reporting

The Software Development Team will demonstrate progress by providing monthly status reports to the Project Manager. These reports will include current development status information. These reports will contain problem status information which has changed since the previous reporting cycle. The Systems Engineer will track CPU and memory utilization, with inputs from the DPA software and hardware development teams.

12.0 Verification and Acceptance

Refer to the ACIS Software Quality Assurance Plan for the verification and acceptance process used for ACIS software development.

Appendix A - Acronyms

The following lists the acronyms and abbreviations used by this document:


TABLE 5. Acronym List
-----------------------------------------------------
Acronym  Description
-----------------------------------------------------
ACIS     AXAF-I CCD Imaging System
ASC      AXAF Science Center
AXAF     Advanced X-ray Astrophysics Facility
CCD      Charge-Coupled Device
CDB      Configuration Data Base
COTS     Commercial Off-the-shelf Software
CSR      Center for Space Research
CTU      Command and Telemetry Unit
DPA      Digital Processor Assembly
DRL      Data Requirements List
ECO      Engineering Change Order
EGSE     Electronic Ground Support Equipment
GSE      Ground Support Equipment
GSS      Ground Support Software
HW       Hardware
ICD      Interface Control Document
MIT      Massachusetts Institute of Technology
MSFC     Marshall Space Flight Center
QA       Quality Assurance
RCS      Revision Control System
SCCS     Source Code Control System
SQA      Software Quality Assurance
SRR      Systems Requirements Review
SW       Software
SWAR     Software Acceptance Review
SWCDR    Software Critical Design Review
SWCI     Software Configuration Inspection
SWFCI    Software Functional Configuration Inspection
SWMSC    Software Miscellaneous Periodic Reports
SWPDR    Software Preliminary Design Review
SWRA     Software Requirements Audit
SWTR     Software Test Review
-----------------------------------------------------