configuration management procedures

Toxicology Data Management System

  ----------------------------------- -----------------------------------
  **Document Number:**                GD-1017-3.0

  **Version:**                        3.1

  **Issued:**                         Feb. 13, 2001

  **Reviewed & Approved by:**         Mike Rowley, Project Officer

                                      

  **Date:**                           Feb. 13, 2001
  ----------------------------------- -----------------------------------

Configuration Management Procedures

# Revision History

+------------+-------------------+-------------+----------------------+
| **Date**   | **Document        | **Revision  | **Reason for         |
|            | Number**          | Level**     | Revision**           |
+------------+-------------------+-------------+----------------------+
| February   | GD-1017-3.0       | 3.1         | Update due to        |
| 2001       |                   |             | configuration        |
|            |                   |             | management changes   |
+------------+-------------------+-------------+----------------------+
| March 1998 | GD-1017-2.0       | 2.0         | Documentation        |
|            |                   |             | Changes              |
|            |                   |             |                      |
|            |                   |             | Placed in MS Word    |
|            |                   |             | TDMS Manual format   |
+------------+-------------------+-------------+----------------------+
| Sept. 1995 | GD-1017-1.1       | 1.1         | Change Document Type |
+------------+-------------------+-------------+----------------------+
| Dec. 1994  | LP-1017-1.1       | 1.1         | Added new procedures |
+------------+-------------------+-------------+----------------------+
| Mar. 1988  | LP-1017-1.0       | 1.0         | New                  |
+------------+-------------------+-------------+----------------------+

National Toxicology Program Support

Configuration Management Procedures

> Prepared for: National Institute of Environmental Health Sciences
>
> Research Triangle Park, NC 27709

Table of Contents

Revision History

Chapter 1

Introduction

Scope

Policy

Chapter 2

Procedures

Malfunctions of Existing Software

Need for System Enhancement

SCR Processing

Software Development and Maintenance Procedures

Software Design and Programming

Software Testing and Validation

Distribution of New Software or Documentation

Coordination of SCRs with Code Changes

Goals

Milestones

Promotion Steps

Responsibilities & Access

Notification via E-Mail

Code Management Software Used

Guidelines for Development Documentation

Development Matrix

Modification of Production Libraries Procedures

Matching of Source and Executable Codes

Maintaining Production Libraries

Documentation Development During the Life Cycle

Appendix A A

TDMS Configuration Management Process A

Appendix b B

TDMS Software Change Request Form B

Appendix c C

TDMS Development Analysis Report (DAR) Form C

TDMS Development Enhancement Report (DER) Form C

TDMS Development Test Plan (DTP) Form C

TDMS QA Test Plan (QATP) Form C

TDMS QA Test Procedures (QATPR) Form C

Introduction

The purpose of this document is to define and establish the policies and
procedures that are followed in a controlled environment when
modifications to the TDMS software are required.

# Scope

The policies and procedures set forth in this document are applicable to
the entire range of TDMS software:

-   Adabas/Natural software

-   VMS software

-   Laboratory Micro-Computer Systems (LDAS)

All parties and activities involved in the operation, maintenance, and
further development of TDMS must comply with the policies and procedures
explained in this manual. TDMS configuration management procedures
include activities performed by officials at the National Institute of
Environmental Health Sciences (NIEHS) and Analytical Sciences Inc.
(ASI). Software configuration management and control begin with the
identification of deviations from the currently accepted functional
performance baseline or when enhancements to the system are directed.
Software configuration management continues through the development and
QA testing process and ends with the satisfactory implementation of the
desired modifications and accompanying documentation. This document
addresses all aspects of this cycle.

# Policy

The NTP TDMS Project Officer is ultimately responsible for maintaining
the integrity of TDMS. The Project Officer is responsible for seeing
that the system performs in accordance with the current functional
specifications baseline (or, in the absence of such a baseline, the
state of the existing system that over time has been accepted as
normal). This responsibility is presently executed through the Computer
Support Services-National Toxicology Program (CSS-NTP) contract with
ASI. It is the prime contractor for TDMS software support. The ASI
Project Manager is responsible for the development and implementation of
policies and procedures that are approved by the Project Officer. The
ASI Project Manager is also responsible for seeing that only NIEHS
authorized and approved changes are made to TDMS. The NIEHS approval
process begins with the review, acceptance, and prioritization of
Software Change Requests (SCRs). The SCR identifies problems or
enhancements to the currently accepted functional performance baseline.
The process continues through the review of design specifications and
culminates with the Quality Assurance (QA) review and testing.

Any change that alters the functional performance of the system (i.e.,
those changes that result in deviations from the currently accepted
functional baseline) will only be made to TDMS software with NIEHS
approval. The ASI Project Manager is delegated the authority to correct
software deficiencies and to implement technical changes to TDMS by the
NTP Project Officer. These technical changes do not alter the functional
performance of TDMS and are made in compliance with procedure. An
example of a technical change would be making a change to a piece of
production software to enhance its efficiency without changing its
output. The change would be a transparent change to the user. Written
notice is provided immediately following the implementation of all
technical changes.

Procedures

Changes to TDMS Software originate from the two types of circumstances:
malfunctions of existing software and the need for system enhancements.

# Malfunctions of Existing Software

The first method of initiating desired changes to TDMS software occurs
when users, monitors, liaisons, testers, or developers report problems
concerning the operational functioning of the system. Possible system
problems:

-   Output report error

-   The abnormal termination of a program

-   Failure of a program to generate a report

-   No report was generated

When malfunctions occur, the ASI User Support and QA Manager, and
Software Development Manager are notified and given a description of the
problem. Each reported problem is numbered and described on the Software
Change Request (SCR), (See Appendix B).

# Need for System Enhancement

The second method of initiating changes to TDMS software occurs when
users, monitors, or developers identify a need to enhance a particular
process or add a function to the currently accepted baseline. Persons
desiring additions and enhancements should submit the request to ASI's
User Support, QA, or Software staff so they may generate a SCR. This SCR
is discussed with the Government Project Officer before the contract
staff takes any action. Software changes generated in this fashion are
generally classified as \"new development.\"

## SCR Processing

Software issues may be reported by the any of the following:

-   Testing laboratories

-   NTP user community

-   ASI User Support

-   QA or Development staff

The ASI staff records the issue on an SCR and designates a
classification category such as: Bug Fix, Enhancement, Suggestion,
Maintenance, Database Change or Documentation. The SCR is entered and
tracked in a tracking system, implemented using Intersolv's PVCS Tracker
software on an NIEHS Windows NT server. After preliminary analysis, the
software problems are given to the Software Development Group for
action. The change is prioritized, and the effort required to fix the
problem is estimated.

Usually, software issues are identified during the analysis, coding, and
testing phases of software development. These problems are recorded by
QA staff in an SCR and are given to software developers for analysis. If
the problem is related to current work, it is repaired as part of the
current change. If it is not related to the current work, the change is
added to a list of open SCRs for scheduling and resolution.

Enhancements from the user community are generally requested through the
User Support Group. ASI technical staff may also suggest enhancements.
Enhancement requests are also recorded on SCR forms and given to the
Software Development Group for analysis, prioritization, scheduling, and
resolution.

SCRs are automatically assigned unique control numbers when they are
entered into the tracking system. Each SCR is entered into the project
that corresponds to the application, such as:

  --------------------------------- -------------------------------------
  TDMS                              POST-PWG QUERY

  LDAS I                            AMFS

  LDAS II                           DOCUMENTATION
  --------------------------------- -------------------------------------

Each SCR contains information categories such as:

  --------------------------------- -------------------------------------
  Submitter                         Solution

  Assign To                         Origin of SCR

  Subsystem                         Open/Closed Status

  Resolution                        
  --------------------------------- -------------------------------------

The tracking system can then report on any or all of this information.
This allows ASI to track the progress of all SCRs. Automatic
notification via e-mail informs concerned parties when particular
actions on SCRs are performed, i.e. submitted, closed, or changed. The
SCRs can be entered either through a PVCS Tracker client installed on
designated Personal Computers at ASI or by individuals through a web
browser.

The Government Project Officer has access to PVCS via the WEB interface.
He may review or monitor SCRs at his convenience.

# Software Development and Maintenance Procedures

The ASI Software Development group is responsible for any software
changes and/or enhancements made, at either the microcomputer or
mainframe level, to maintain current TDMS function. During the software
development/maintenance cycle, various subcontractors may provide
assistance. Appropriate ASI personnel are kept abreast of progress and
problems; and, the NIEHS staff are provided with regular status reports,
and notification when any unexpected changes impact time/resource
estimates and milestones.

## Software Design and Programming

The ASI Software Development Manager reviews the NIEHS prioritization
plan. The ASI Project Manager and the ASI Software Development Manager
discuss the priorities and their impact on current task work. They also
discuss the overall software development and maintenance plans. Concerns
arising from this discussion are transmitted to the Government Project
Officer. Once priorities are established, milestones and deliverables
for all tasks are re-evaluated to determine if any need revising. A
milestone/deliverables schedule is developed and this information is
passed on to the Project Manager and to NIEHS on a regular basis. If
significant changes to milestones are required, the appropriate parties
are notified immediately. The prioritization of tasks may occasionally
require an iterative dialogue to assure that all parties concerned are
aware of the implications of adding the new work.

After prioritization and scheduling are complete, the Software
Development Manager assign a ASI programmer/analyst to review the
project and develop designs for any large scale maintenance assignments
or new development work. Small maintenance tasks may require only minor
changes to existing design documentation. If no change to the formal
design document is required, the problem analysis will serve as
sufficient design documentation for the software change.

For new development or major enhancements, it is the responsibility of
the Software Development Manager to oversee the development of detailed
external design specifications. (A document that defines information
aggregates, information flow, and logical processing steps describing
the algorithms and data structure.) Also, the Software Development
Manager is responsibile for re-assessing the resources needed to
complete the project on schedule. The external design specifications are
given to a programmer/analyst, a consultant, and/or a subcontractor to
develop a detailed internal design and to program changes after approval
by NIEHS. All programming is completed in development libraries.

The Software Development Manager approves and monitors all internal
design and programming work, paying particular attention to resource
requirements, milestones, software and documentation standards, and the
integrity and security of production software and data. The Software
Development Manager keeps the ASI Project Manager and NIEHS officials
informed periodically of the status of the work, and immediately
informed if important changes in status occur. A detailed
milestone/deliverable schedule is periodically updated and distributed.

Consultants and subcontractors are required to report status at regular
intervals and to monitor progress in relation to the established
milestone/deliverables schedule. All of these external software tasks
are monitored and directed by the Software Development Manager as well.

## Software Testing and Validation

ASI programmer/analysts, consultants, and/or subcontractors will create
a detailed Development Test Plan (DTP), (See Appendix C), to conduct
both unit and system tests. All software modules that are developed to
address system problems or provide system enhancements, except modules
specifically exempted by an Exception Report, will reside in development
libraries.

Developers prepare and execute module test plans for each software
change. The module test plan specifies how to verify that all software
problems are fixed, and all changed code works as designed. The module
test plan is inspected and approved by the Software Development Manager
and the Use Support and Quality Assurance Manager.

The QA Test Plan (QATP) is prepared by the Quality Assurance group. The
QATP tests that the software functions as specified and that the
software change has not introduced new problems. System test plans
should provide a detailed means of testing the software under conditions
close to production conditions. Read-only testing using the production
data bases is permitted; but, only fully certified software is permitted
to update production data. Update testing is performed with test data
bases only.

The system test plan requires approval of the User Support and Quality
Assurance Manager. After approval of the test plan, testing is carried
out by the assigned personnel. Problems found during testing are
reported in PVCS Tracker. Tracker submits the problem to the appropriate
parties for resolution. Problem resolutions are re-tested, and testing
is resumed. This process continues until the performance of the software
is error-free. When complete, the tester prepares a test report,
detailing the results of the testing. The tester attaches the user and
maintenance documentation to the test report. The User Support and
Quality Assurance Manager reviews the test plan, test report, and
accompanying user and maintenance documentation. Approved software and
documentation are considered validated and ready to release to
production.

## Distribution of New Software or Documentation

If implementation of the software requires an update or new
software/user documentation, the Technical Writer updates the
documentation and distributes it in accordance with the procedures
established for documentation distribution of TDMS micro computer
software and documentation. Notification by letter is sufficient if the
software change does not require updating user documentation. The
Project Officer will determine which users are notified of the software
change.

# Coordination of SCRs with Code Changes

## Goals

The logging of 'bugs' or enhancements through PVCS via the SCR tracks
problems or enhancements through the system. The SCR needs to be linked
to actual code changes. Tracking both the SCR and codes changes together
allows:

-   Code is associated with an SCR from initial code checkout, through
    promotion and up to installation into production.

-   There is control over who can create SCRs, change code, promote code
    and build/install the code in various environments. These
    constraints provide control of work load distribution and make
    deviations from the continuity of the milestone/deliverables
    schedule visible.

-   The status of the SCR updates automatically once the associated code
    is checked-out/in, promoted or canceled from further promotions.

-   Principle parties are automatically notified of the SCR and code
    status via e-mail when code promotions/cancellations occur.

## Milestones

The basic milestones for this coordination are:

-   **Why** - The SCR that is linked to code via the tracking system
    should explain why code needs to be changed.

-   **Who -** The code tracking system should show who has entered the
    SCR and who will create, change or promote the code associated with
    the SCR.

-   **What** - The tracking system should show what particular code
    file(s) changed for the SCR.

-   **Where** - The tracking system should show where in the promotion
    stage the code resides. This includes, Development, Pending_QA, QA,
    Pending_Beta, Beta and Production. The SCR will reflect the current
    promotion status of the associated code.

-   **When** - The tracking system should show when the date/time of all
    actions performed the code.

## Promotion Steps

The source code to repair or enhance, according to an SCR, follows a
series of promotion steps. The initial step begins with a developer
checking-out source code from the library and associating the file(s)
with any SCRs. On changing the file(s), the code is checked-in and
promoted. While the file(s) is checked-out, the code/SCR is in the
DEVELOPMENT promotion phase. After the file(s) is checked-in, the code
is promoted to PENDING_QA. Someone then moves the code into QA and
testing begins. Once the code passes testing, the code is promoted to
PENDING_PROD. The process concludes with the code being moved into PROD.
In some cases, two steps\--PENDING_BETA and BETA\--may be inserted
between QA and PENDING PRODUCTION. This occurs when the code requires
additional testing for large scale changes or if user training is
required in a separate environment. At each promotion step, the status
of the associated SCR will change to reflect the new location of the
code.

## Responsibilities & Access

Each step of code promotion or code change is the responsibility of a
single individual or a team of individuals on staff. In the latter case,
the responsibilities of the staff are illustrated in the graph on the
following page.

  ------------------ ------------------ ------------------ ----------------
                     **DEVELOPMENT**    **QA**             **PRODUCTION**

  ***Staff***                                              

                                                           

  ***DEVELOPER***                                          

                                                           

                                                           

  ***QA***                                                 

                                                           

  ***SW Development                                        
  Manager***                                               
  ------------------ ------------------ ------------------ ----------------

The graph above shows that the Developer has control over the
Development environment for the following tasks:

1.  Check out code from the library to the developer's area.

2.  Check in code to the library from the developer's area.

3.  Move code to Pending_QA. The responsibility shifts to the QA staff,
    once they are notified that code has moved to Pending_QA.

4.  Move the code to the QA environment and test the changes.

5.  Once the test is complete, QA staff would move the code to
    Pending_Prod.

6.  Finally, the Software Development Manager who has control over the
    production environment would move the code from Pending_Prod to
    Prod.

## Notification via E-Mail

While the code is moved from one stage to the next- (PENDING_QA, QA, or
PENDING_PROD), e-mail is sent to various parties:

1.  When the Developer moves the code to PENDING_QA, an e-mail
    reflecting the status of the associated SCR is sent to the SCR
    submitter (Liaison, QA or Developer) and to the QA tester assigned
    to test the code.

2.  When the code is moved into QA, an e-mail is sent to the SCR
    submitter and the Developer who worked on the code.

3.  When QA moves the code to PENDING_PROD, an e-mail is sent to the SCR
    Submitter, Developer and the Librarian.

4.  Finally, when the Software Development Manager moves the code to
    PROD, e-mail is sent to the SCR Submitter, QA tester and the
    Developer. This keeps all interested parties informed of SCR
    progress and the associated code.

# Code Management Software Used

Two areas of code currently require different software packages to
control them:

  ------------------------- ---------------------------------------------
  **Alpha/VMS computer:**   Uses the VMS code management software CMS

  **Windows PC based:**     Uses Intersolv's PVCS Version Manager
  ------------------------- ---------------------------------------------

Each area uses the promotion process mentioned earlier in the
*Responsibilities and Access* section of this chapter.

As mentioned earlier, each area may have control of moving code into the
QA and PROD environments. This process may be centralized to one
individual or spread among a team, particularly for steps four and six
listed in the *Responsibilities and Access* section of this chapter.
Centralized control is a necessity when a build or install is required
in each environment. For the Alpha/VMS case, the DBA must build and
install code for the TDMS application into the respective environment's
database before the code is executable. On the Windows PC code, a
central repository manager is needed for Visual C++ code to be compiled
and linked to the LDAS II application.

# Guidelines for Development Documentation

To determine when requirement documents and design documents are
necessary, development efforts are categorized as follows:

  ---------------------------- ------------------------------------------
  Level III                    Least effort

  Level II                     Medium effort

  Level I                      Full Force effort
  ---------------------------- ------------------------------------------

Several characteristics determine the level of development a task
requires. Determine which characteristic(s) you are most able to
quantify in the table below:

  ---------------------- ------------------------------------------------
  **Characteristic**     **Description**

  Development Level      Level of development effort and functional
                         documentation required.

  Human Resources        Number of man hours required to develop project.

  Users                  Number of users communicating requirements

  Phase Implementation   Number of development phases expected for
                         delivery.

  User Training          Number of hours required to train user(s).

  Size                   Significance of changes to software: databases,
                         modules, files, screens, reports and tables.

  Complexity             Impact of integration, interaction and security
                         changes on other systems, databases and
                         networks.

  Technology Usage and   Familiarity and usage of new software, hardware
  Experience             and network technology supplied.

  Document(s) Required   Documents required to explain system
                         requirements and design. Note that for Level III
                         development, either a Development analysis
                         Report (DAR) or Development Enhancement Report
                         (DER) is created. The difference would be for
                         'bugs' a DAR is created and for enhancements a
                         DER is created.
  ---------------------- ------------------------------------------------

Then, find the column for the characteristic(s) in the matrix on the
next page. Find your value first, followed by the document requirements.

# Development Matrix

  ------------- ------------- ----------- ------------------ ------------ ------------ ----------- ---------------- --------------------
                **Human       **Users**   **Phase            **User       **Size**                 **Complexity**   **Technology Usage &
                Resources**               Implementation**   Training**                                             Experience**

  Development                                                             Components   Databases                    Document(s) Required
  Level                                                                                                             

  III           \<160 hours   1           1                  \<16 hours   \<5          1db         Stand-alone, no  ONE: (DER/DAR)
                                                                                                   external access; Development
                                                                                                   no security;     Enhancement
                                                                                                   single tier      Report/Development
                                                                                                                    Analysis Report

  II            160-320 hours 2-3         2                  16-32 hours  5-20         2db         File sharing to  ONE: Combined
                                                                                                   another          requirements and
                                                                                                   platform; common design document
                                                                                                   file access      
                                                                                                   security; 2-tier 

  I             \>320 hours   \>3         \>2                \>32 hours   \>20         \>2db       File access via  TWO: Requirements
                                                                                                   client/server;   document and design
                                                                                                   security granted document
                                                                                                   via specific     
                                                                                                   user account;    
                                                                                                   3-tier           
  ------------- ------------- ----------- ------------------ ------------ ------------ ----------- ---------------- --------------------

# Modification of Production Libraries Procedures

Programs are developed using NATURAL, COBOL, PL1, and SAS.

## Matching of Source and Executable Codes

It is the responsibility of the Technical Support staff to make sure
that executable code of all software moved to production matches the QA
tested version of the source code. Before moving to production, version
numbers and file descriptions are checked to insure a match between
source and executable code. Source and executable codes of all software,
including modifications to current production software or newly
developed software, are always moved simultaneously to the production
environment. Corresponding SCRs logged in the automated system are given
a completion date and status when software is finally moved to
production.

## Maintaining Production Libraries

The Software Development Manager is responsible for the code libraries
and for modifications and changes made to the libraries. The accumulated
code libraries form a historical file, in chronological order, of all
modifications. This provides a status of all modifications and the mean
for baseline performance of the TDMS system. The Software Development
Manager is responsible for the movement of all production software from
the development libraries to production environment.

## Documentation Development During the Life Cycle

Documents are prepared by the Technical writer throughout the
development cycle. The scope of the development determines the types of
documentation that may be generated during the development and QA
phases.

+----------------------+-----------------------------------------------+
| **Type of Document** | **Description**                               |
+----------------------+-----------------------------------------------+
| -   Submit Change    | User/Technical Support Staff completes this   |
|     Request:         | form for a Bug Fix, Enhancement, Suggestion,  |
|                      | Maintenance, Database Change, or              |
|                      | Documentation request.                        |
+----------------------+-----------------------------------------------+
| -   Design           | A list of functions for software development. |
|     Requirements     |                                               |
+----------------------+-----------------------------------------------+
| -   Project          | A time line of the development schedule and   |
|     Management Plan  | the assignment of work hours to definable     |
|                      | work units.                                   |
+----------------------+-----------------------------------------------+
| -   System           | The assignment of functional requirements to  |
|     Functional       | program units.                                |
|     Design           |                                               |
+----------------------+-----------------------------------------------+
| -   Program Design   | A description of the relationships for an     |
|     Documents        | operation of code within a program unit.      |
+----------------------+-----------------------------------------------+
| -   Development Test | A description of how the code was tested by   |
|     Report (DTR)     | the developer and the test results.           |
+----------------------+-----------------------------------------------+
| -   QA Test Plan     | A description of the test requirements and a  |
|     (QATP)           | methodology for testing plus a list of the    |
|                      | test cases to be developed and the results of |
|                      | each test.                                    |
+----------------------+-----------------------------------------------+
| -   QA Test          | A step by step description of an individual   |
|     Procedures       | test case.                                    |
|     (QATPR)          |                                               |
+----------------------+-----------------------------------------------+
| -   Maintenance      | A description of how each unit (module) of    |
|     Manual           | code is to be maintained.                     |
+----------------------+-----------------------------------------------+
| -   Operator Manuals | A description of how the program is to be     |
|                      | loaded into a computer and operated.          |
+----------------------+-----------------------------------------------+
| -   Training Plan    | A plan and schedule for implementation of a   |
|                      | system at labs throughout the US.             |
+----------------------+-----------------------------------------------+
| -   User Manuals     | A step by step description of how use a       |
|                      | system.                                       |
+----------------------+-----------------------------------------------+

Before accepting and moving the new software to production, the Software
Development Manager will have the responsibility of insuring compliance
with all the requirements set forth in this document.

# TDMS Configuration Management Process

![](media/image1.png){width="5.254166666666666in"
height="6.790277777777778in"}

# TDMS Software Change Request Form

![](media/image2.png){width="7.152777777777778in" height="4.2375in"}

# TDMS Development Analysis Report (DAR) Form

[ASI Development Analysis Report *xx*]{.smallcaps}

+-----------------------+----------------------------------------------+
| Section I: General    |                                              |
| Information           |                                              |
+-----------------------+----------------------------------------------+
| [date]{.smallcaps}    | *date of DAR*                                |
+-----------------------+----------------------------------------------+
| [SCR control          | *SCR number*                                 |
| number]{.smallcaps}   |                                              |
+-----------------------+----------------------------------------------+
| [SCR                  | *SCR title*                                  |
| title]{.smallcaps}    |                                              |
+-----------------------+----------------------------------------------+
| [an                   | *name of developer*                          |
| alyst(s)]{.smallcaps} |                                              |
|                       | *     *                                      |
+-----------------------+----------------------------------------------+

  ---------------------- ------------ -------------------- ----------- ----------------------------------------
                         Section II:                                   
                         Review                                        
                         Signatures                                    
                         and Dates                                     

                                                                       

  [technical                                               signature   
  review]{.smallcaps}                                      date        

  [software systems                                        signature   
  manager]{.smallcaps}                                     date        

  [quality assurance                                       signature   
  manager]{.smallcaps}                                     date        
  ---------------------- ------------ -------------------- ----------- ----------------------------------------

### 1.0 Describe the Problem

*Provide a technical description of the problem cause, based on your
analysis.*

### 2.0 Reproduce the Problem

*Describe the steps and data required to reproduce the problem. If the
SCR full describes how to reproduce the problem, enter the SCRs
description here.*

### 3.0 Scope of Problem

*List the number of users, reports, queries, subsystems and databases
changed and tested, as applicable.*

### 4.0 Solution

*Describe you solution.*

### 5.0 Impact on Documents

*List the requirements, design, and user documents that will reflect
software changes.*

# TDMS Development Enhancement Report (DER) Form

[ASI Development Enhancement Report *xx*]{.smallcaps}

+-----------------------+----------------------------------------------+
| Section I: General    |                                              |
| Information           |                                              |
+-----------------------+----------------------------------------------+
| [date]{.smallcaps}    | *date of DER*                                |
+-----------------------+----------------------------------------------+
| [SCR control          | *SCR number*                                 |
| number]{.smallcaps}   |                                              |
+-----------------------+----------------------------------------------+
| [SCR                  | *SCR title*                                  |
| title]{.smallcaps}    |                                              |
+-----------------------+----------------------------------------------+
| [an                   | *name of developer*                          |
| alyst(s)]{.smallcaps} |                                              |
|                       | *     *                                      |
+-----------------------+----------------------------------------------+

  -------------------------- --------------------------------------------
  Section II: Review         
  Signatures and Dates       

                             

  [technical qa              signature date
  review]{.smallcaps}        

  [software systems          signature date
  manager]{.smallcaps}       

  [quality assurance         signature date
  manager]{.smallcaps}       
  -------------------------- --------------------------------------------

### 1.0 General Information

*Briefly summarize the software to be developed, the environment in
which the software will be implemented, and any applicable references.*

### 2.0 Overview

*You do not have to write anything after this section. This is an
opening header.*

### 2.1 Background

*Present the purpose and scope of the software and any background
information that would orient the reader.*

### 2.2 Objectives

*State the major performance objectives of the software, including
examples. Identify anticipated operational changes that will affect the
software and its use.*

### 2.3 Existing Methods and Procedures

*Describe the current methods and procedures that satisfy the existing
objectives. Include organizational and personnel responsibilities;
available and required equipment; volume and frequency of inputs and
outputs and; deficiencies and limitations.*

### 2.4 Proposed Methods and Procedures

*Describe the proposed software and its capabilities. Identify
techniques and procedures from other software that will be used or that
will become part of the proposed software. Identify the requirements
that will be satisfied by the proposed software.*

### 2.5 Summary of Improvements

*Itemize improvements to be obtained from the proposed software; such as
new capabilities; upgraded existing capabilities; elimination of
existing deficiencies; improved timelines; elimination of reduction of
existing capabilities that are no longer needed.*

### 2.6 Summary of Impacts

*Summarize the anticipated impacts of the proposed software on
equipment; software; organization; operation; and user support.*

### 2.8 Alternative Proposals

*If alternative software has been proposed to satisfy the requirements,
describe each alternative. Compare and contrast the alternatives.
Explain the selection reasoning.*

#   {#section .unnumbered}

# TDMS Development Test Plan (DTP) Form

[ASI Development Test Plan 59]{.smallcaps}

+----+-----------------+----------------------------------------------+
|    | Section I:      |                                              |
|    | General         |                                              |
|    | Information     |                                              |
+----+-----------------+----------------------------------------------+
| [d |                 | *date of DTP*                                |
| at |                 |                                              |
| e] |                 |                                              |
| {. |                 |                                              |
| sm |                 |                                              |
| al |                 |                                              |
| lc |                 |                                              |
| ap |                 |                                              |
| s} |                 |                                              |
+----+-----------------+----------------------------------------------+
| [S |                 | *SCR number*                                 |
| CR |                 |                                              |
| c  |                 |                                              |
| on |                 |                                              |
| tr |                 |                                              |
| ol |                 |                                              |
| n  |                 |                                              |
| um |                 |                                              |
| be |                 |                                              |
| r] |                 |                                              |
| {. |                 |                                              |
| sm |                 |                                              |
| al |                 |                                              |
| lc |                 |                                              |
| ap |                 |                                              |
| s} |                 |                                              |
+----+-----------------+----------------------------------------------+
| [S |                 | *SCR title*                                  |
| CR |                 |                                              |
| ti |                 |                                              |
| tl |                 |                                              |
| e] |                 |                                              |
| {. |                 |                                              |
| sm |                 |                                              |
| al |                 |                                              |
| lc |                 |                                              |
| ap |                 |                                              |
| s} |                 |                                              |
+----+-----------------+----------------------------------------------+
| [a |                 | *name of developer*                          |
| na |                 |                                              |
| ly |                 | *     *                                      |
| st |                 |                                              |
| (s |                 |                                              |
| )] |                 |                                              |
| {. |                 |                                              |
| sm |                 |                                              |
| al |                 |                                              |
| lc |                 |                                              |
| ap |                 |                                              |
| s} |                 |                                              |
+----+-----------------+----------------------------------------------+
| [  |                 | *     Module name*                           |
| ta |                 |                                              |
| sk |                 |                                              |
| n  |                 |                                              |
| am |                 |                                              |
| e] |                 |                                              |
| {. |                 |                                              |
| sm |                 |                                              |
| al |                 |                                              |
| lc |                 |                                              |
| ap |                 |                                              |
| s} |                 |                                              |
+----+-----------------+----------------------------------------------+
| [  |                 | *     component name*                        |
| co |                 |                                              |
| mp |                 |                                              |
| on |                 |                                              |
| en |                 |                                              |
| t] |                 |                                              |
| {. |                 |                                              |
| sm |                 |                                              |
| al |                 |                                              |
| lc |                 |                                              |
| ap |                 |                                              |
| s} |                 |                                              |
+----+-----------------+----------------------------------------------+

  -------------------------- --------------------------------------------
  Section II: Approval of    
  Test Plan                  

                             

  [technical qa              signature date
  review]{.smallcaps}        

  [software systems          signature date
  manager]{.smallcaps}       

  [quality assurance         signature date
  manager]{.smallcaps}       
  -------------------------- --------------------------------------------

  -------------------------- --------------------------------------------
  Section III: Approval to   
  Release Module to Next     
  Level of Test              

                             

  [software systems          signature date
  manager]{.smallcaps}       

  [quality assurance         signature date
  manager]{.smallcaps}       
  -------------------------- --------------------------------------------

###  1.0 System Changes

*Identify and list the modules, files, directories, and (or) programs
that caused the problem. Then list the modules, files, subsystems,
directories and (or) programs affected by the solution.*

### 2.0 Testing Summary

*Summarize your testing strategy. Include the test objectives and steps
taken in preparation for testing, if applicable.*

### 3.0 Testing Environment

*This is a section opening. You do not have to enter anything after this
statement.*

### 3.1 Hardware Required

*List the hardware require to run and test the system.*

### 3.2 Software Required

*List the software require to run and test the system.*

### 4.0 Test Checklist

*Briefly describe the systems of software that must run when testing the
exact area affected by the changed. List a short check list of steps
(such as, entering min./max. values, initial values, keystrokes,
reviewing logs, etc. ).*

Executed by Date

*You do not have to write anything after this section. The person who
executes this plan should sign and date this line.*

### 5.0 Comments

*Add any additional notes, comments, or observations that may help with
future testing. Also add other comments about test execution or test
data.*

# TDMS QA Test Plan (QATP) Form

ASI Quality Assurance Test Plan For (Insert Project Name)

# General Information

  ---------------- ------------------------------------------------------
  **S****CR        Insert SCR number
  Number:**        

  **Title:**       Insert the Title of the Test Plan

  **Test Plan      Insert Author\'s Name and Title
  Author:**        

  **Location:**    Insert Test Plan location
  ---------------- ------------------------------------------------------

# Revision History

  ------------ ------------------ ----------------------------------------
  **Version    **Date and Time**  **Description**
  No.**                           

  Insert       Insert Date and    Give a brief description of the changes
  Version      Time               made.
  Number                          
  ------------ ------------------ ----------------------------------------

# Review & Approval

  ---------------------------------------------------------------------------------------------- ----------------------------------------------
  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  Software Development Manager                                                                   Date

  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  User Support Manager                                                                           Date

  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  Quality Assurance Manager                                                                      Date

  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  Database Administrator                                                                         Date

  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  Program Manager                                                                                Date
  ---------------------------------------------------------------------------------------------- ----------------------------------------------

# Purpose

State the purpose of the test plan.

# Overview

State what the systems being tested should support and/or accomplish.

# Testing Approach

Define the test environment. State the method used and the type of
testing accomplished. Name any documents or materials needed to create
test procedures.

# Testing Plan

Create a test schedule based on QA estimated effort. Include estimates
of support and critical need dates from other organizations. Discuss any
training the testers may need.

# Defect Reporting

Define the system that will be used to report software/hardware errors
and how it will be used.

# Input State

Define the state teh softwrae should be in for QA to begin testing. This
should include the need for other modules, data and special test
software.

# Output State

Define the criteria to be met for QA\'s release to the next stage. This
could be the number or priority of remaining errors, or other actions to
be completed before moving to beta or release.

# Testing Summary

  ---------- ---------- ---------- ---------------- ---------- ---------- ---------- ----------------
  **Date**   **Number   **Number   **Number of      **Number   **Number   **Number   **Number of
             of Tests** of SCRs**  Showstoppers**   of High**  of         of Low**   Enhancements**
                                                               Medium**              

                                                                                          

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

#   {#section-1 .unnumbered}

# TDMS QA Test Procedures (QATPR) Form

ASI Quality Assurance Test Procedure For (Insert Project Name)

# General Information

  --------------------- -------------------------------------------------
  **Test Plan Name:**   Insert the Test Plan name

  **Title:**            Insert the Title of the Test Procedures

  **Test Procedures     Insert Author\'s Name and Title
  Author:**             

  **Location:**         Insert test plan location
  --------------------- -------------------------------------------------

# Revision History

  ---------- ---------------- -------------------------------------------
  Version    Date & Time      Description
  No.                         

  Insert     Insert date &    Give a brief description of the changes
  Version    time             made.
  Number                      
  ---------- ---------------- -------------------------------------------

# Review & Approval

  ---------------------------------------------------------------------------------------------- ----------------------------------------------
  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  Software Development Manager                                                                   Date

  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  User Support Manager                                                                           Date

  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  Quality Assurance Manager                                                                      Date

  \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  Database Administrator                                                                         Date
  ---------------------------------------------------------------------------------------------- ----------------------------------------------

# Test Case Description

  ------------------ ----------------------------------------------------
  **Test Case        Provide an overall description of what the test
  Description**      document will accomplish.

  **Reference        Name of Reference Manual from which test cases are
  Manual:**          derived.

  **Scope of         List a brief synopsis of what each test case is to
  Testing:**         accomplish.
  ------------------ ----------------------------------------------------

+-------+--------------------------------------------------------------+
| **    |                                                              |
| [Test |                                                              |
| Case  |                                                              |
| (I    |                                                              |
| nsert |                                                              |
| Test  |                                                              |
| Case  |                                                              |
| nu    |                                                              |
| mber) |                                                              |
| ]{.un |                                                              |
| derli |                                                              |
| ne}** |                                                              |
+-------+--------------------------------------------------------------+
|       |                                                              |
+-------+--------------------------------------------------------------+
| I     |                                                              |
| nsert |                                                              |
| a     |                                                              |
| det   |                                                              |
| ailed |                                                              |
| d     |                                                              |
| escri |                                                              |
| ption |                                                              |
| of    |                                                              |
| the   |                                                              |
| test  |                                                              |
| case. |                                                              |
+-------+--------------------------------------------------------------+
|       |                                                              |
+-------+--------------------------------------------------------------+
| Des   |                                                              |
| cribe |                                                              |
| the   |                                                              |
| steps |                                                              |
| for   |                                                              |
| the   |                                                              |
| test  |                                                              |
| case  |                                                              |
| in    |                                                              |
| the   |                                                              |
| table |                                                              |
| b     |                                                              |
| elow. |                                                              |
| An    |                                                              |
| *X*   |                                                              |
| next  |                                                              |
| to    |                                                              |
| each  |                                                              |
| step  |                                                              |
| indi  |                                                              |
| cates |                                                              |
| the   |                                                              |
| step  |                                                              |
| is    |                                                              |
| comp  |                                                              |
| lete. |                                                              |
+-------+--------------------------------------------------------------+
|       |                                                              |
+-------+--------------------------------------------------------------+
| **St  | **Description**                                              |
| eps** |                                                              |
+-------+--------------------------------------------------------------+
| 1.    |                                                              |
+-------+--------------------------------------------------------------+
| 2.    |                                                              |
+-------+--------------------------------------------------------------+
| 3.    |                                                              |
+-------+--------------------------------------------------------------+
| 4.    |                                                              |
+-------+--------------------------------------------------------------+
| 5.    |                                                              |
+-------+--------------------------------------------------------------+
| 6.    |                                                              |
+-------+--------------------------------------------------------------+
| 7.    |                                                              |
+-------+--------------------------------------------------------------+
| 8.    |                                                              |
+-------+--------------------------------------------------------------+
| 9.    |                                                              |
+-------+--------------------------------------------------------------+
| 10.   |                                                              |
+-------+--------------------------------------------------------------+

END OF DOCUMENT