# Appendix C: Product Plan Instructions {#appendix-c-product-plan-instructions .PDHHeading1}

Product Plan---A description of the work to be performed and the
resources needed to accomplish the goals and objectives established in
the customer agreement. In QMS terminology, the Product Plan is the
*QUALITY PLANNING DOCUMENT* for producing the product. The Product plan
includes the *design planning information* and the *process management
information*.

Figure 1 is the table of contents to be followed by all Teams in
generating their Product Plan. All components shall be addressed, but
the level of detail is left to the Team based on product complexity and
customer needs/expectations.

ISO 9001 standards require certain quality control processes to be
documented. Those processes that are required and the criteria that they
must meet are described in Appendix F. Samples of these required
processes that meet these criteria are in the Library of Approved Team
Processes (see
[http://isc.gsfc.nasa.gov/ISO9k/ISO9001.htm](http://isc.gsfc.nasa.gov/Iso9k/ISO9001.htm)).
Each team in their product plan may either refer to one or more specific
approved processes, or develop and document their own processes. Any new
processes must meet the criteria specified in Appendix F and be approved
by the ISD QMS representative. The effective date of the Product
Development Handbook being used is to be placed directly under the
Product Plan "Table of Contents" label on the "Table of Contents" page
and should be labeled as "Version Date xx/xx/xx". This effectively
freezes the version of the Product Plan Table of Contents for the
duration of the Product Plan.

The following disclaimer should be placed in the footnote section of
every page:

"Printed copies of this document are for **REFERENCE PURPOSES ONLY**!
The only controlled copy of this document is located on-line at
[http://xxxxxxxx](http://xxxxxxxx/)."

Optionally for Product Plans originally signed prior to ***8/1/99***,
this disclaimer may appear directly after the signature page:

\"References to documents and data (hard copy or electronic) in the
Product Plan ***not*** directly under the Team's control shall contain
the version identification in the Product Plan.\"

The Work Order Authorization (WOA) equivalent for software development
referred to in the GSFC QMS is defined by the contents of Sections 3.1
and 4.2.1 of the ISD Product Plan, including all associated
documentation and references.

Section 1 of the Product Plan (Customer Agreement) may be under either
Project or ISD control. It follows the configuration management process
outlined in Section 1.15. A customer signature for the Section 1 of the
Product Plan is highly recommended (see Figure 2).

The remaining sections of the Product Plan are under ISD Configuration
Management and follow the configuration management process defined in
Section 4.2.1. At a minimum, these portions of the Product Plan require
a Team Lead signature and an appropriate ISD Management Team signature
for approval (see Figure 3).

The remainder of this appendix lists the product plan subsections with a
description of the contents following each subsection heading. Quality
records and controlled documents are identified in tables in the
appropriate subsections. Tables labeled as objective evidence indicate
other records that should be maintained by the Team, but are not
included on either the quality records list or the controlled documents
list.

Certain subsections may be included by reference if documented
elsewhere. These subsections are identified with an asterisk (\*). It is
recommended that subsections containing frequently changing information
be included by reference.

+-----------------------------------------------------------------------+
| Table of Contents for Product Plan                                    |
+-----------------------------------------------------------------------+
| Table of Contents---Product Development Handbook -Version Date:       |
| xx/xx/xx                                                              |
|                                                                       |
| Document Change History---Include version identifier and description  |
| of change                                                             |
|                                                                       |
| Customer Agreement Signature Page                                     |
|                                                                       |
| Product Development Signature Page                                    |
|                                                                       |
| 1.  Customer Agreement                                                |
|                                                                       |
| > 2\. Management Approach                                             |
| >                                                                     |
| > 3\. Technical Approach                                              |
|                                                                       |
| 4\. Product Assurance                                                 |
|                                                                       |
| 5\. Plan Update History                                               |
|                                                                       |
| Appendix A---Acronyms and Abbreviations                               |
|                                                                       |
| Appendix B---References                                               |
+-----------------------------------------------------------------------+
| *Figure 1. Template for Table of Contents*                            |
|                                                                       |
| **NOTE**: See following pages for detailed information on contents of |
| each section.                                                         |
+-----------------------------------------------------------------------+

Customer Agreement

for the

(project name)

(system type^1^) Development

Release Date

*Month/Year*

Prepared by:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

XXXXXXX

Team Lead

Approved by:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

XXXXXXX

Customer/Designee

Approved by:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

XXXXXXX

Information Systems Division Management Representative ^2^

The Team Lead, the Customer/Designee, and the Information Systems
Division Management Representative constitute the Configuration Control
Board for the Customer Agreement portion (Section 1) of this document.

Disclaimer

Printed copies of this document are FOR REFERENCE PURPOSES ONLY. It is
the user's responsibility to verify that the version of any printed
documentation matches the online version.

***FIGURE 2. Template for Customer Agreement***

**Notes: (1) System types---This would be ground data system, flight
software, command and data handling system, etc.**

(2) **Information Systems Division Management Representative---Title
    listed here should be the specific title of the ISD manager
    responsible for the development, for example, "Code 5xx Branch
    Head"**

Product Development

for the

(project name)

(system type^1^) Development

Release Date

*Month/Year*

Prepared by:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

XXXXXXX

Team Lead

Approved by:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

XXXXXXX

Information Systems Division Management Representative ^2^

The Team Lead and the Information Systems Division Management
Representative constitute the Configuration Control Board for this
document, with the exclusion of the Customer Agreement (section 1).

Disclaimer

Printed copies of this document are FOR REFERENCE PURPOSES ONLY. It is
the user's responsibility to verify that the version of any printed
documentation matches the online version.

***FIGURE 3. Template for Product Development***

**Notes: (1) System for types---This would be ground data system, flight
software, command and data Handling system, etc.**

> **(2) Information Systems Division Management Representative---Title
> listed here should be the specific title of the ISD manager
> responsible for the development, for example, "Code 5xx Branch Head"**

**1.0 Customer Agreement (GPG 1310.1)**

1.1 Background

A brief (maximum of one paragraph) description of what larger
effort/activity this Team is supporting and how this product fits into
the larger picture.

1.2 Team Charter

A brief one-paragraph description of what this Team is being asked to
accomplish, including any time constraints or interface boundaries
within which this Team is expected to operate.

1.3 Customer(s) Identification

The customer is usually a Flight Project or the person who pays the
bill. Otherwise, it should be the person who will define the
requirements and accept the products.

1.4 Customer Goals and Objectives

Any special things that the customer wants to accomplish (e.g., rapid
turn around, new architecture, special COTS requirements, special
experiments, etc.) through this Team's activities.

1.5 Requirements\*

This section should list or reference (preferred) any
functional/operational requirements as specified by the customer.
Include any specific standards to be met and list the interface control
documents needed. Include any policies and practices of Electrical
Engineering Division (EED) or specific Projects for devices connecting
to flight hardware. References must include revision date/number for
documents not under direct control of Team Lead. Do not include
technical interface documents or databases here. Reference them in
Section 2.4

  ------------------------ ------------------------- ---------------------
  Controlled Document      Comment                   Record Held By

  Functional Requirements  Signed and dated by       Project or Team Lead
                           Customer                  
  ------------------------ ------------------------- ---------------------

1.6 Deliverables

List products to be delivered for each phase, including software,
hardware, licenses, documentation, etc., as directed by customer.

1.7 Schedules\*

List *customer---specified* schedule requirements, including such items
as documentation, releases and reviews.

1.8 Necessary Customer Training

Specify who is to be trained how many are to be trained, location and
nature of training.

1.9 Medium/Method for Product Delivery (GPG 6400.1)

List any required delivery medium and method of delivery for all
products listed in Section 1.6

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Shipping Records                                   Team Lead
  ------------------------ ------------------------- ---------------------

1.10 Product Destination

List product delivery destination for all products listed in
Section 1.6.

1.11 Post Delivery

Describe who will do maintenance after and how it will be
requested/approved. Describe process that will be used for maintenance
activities for all products in Section 1.6

1.12 Customer-supplied elements, both technical, and resources
(schedule, medium, and interfaces)

List any technical elements supplied by the customer that will be used
in the production, testing or packaging/delivery of the product. Do not
include funding. Include delivery schedule and medium of supplied items.

1.13 Customer involvement (roles, responsibilities, authority,
accountability)

Provide details on the extent of direct customer involvement with the
Team (Attends Team meetings? Reviews results? Provides direction? Etc.)

1.14 Acceptance Criteria\*

Describe the customer's criteria for determining when the product is
completed, (i.e., when will the customer accept the product?) This is
usually demonstrated by having a satisfactorily completed test
matrix/set of test plans. Customer verbal acceptance is not sufficient.

1.15 Customer Agreement Review and Update Process

Describe the process used to evaluate and approve changes to the
customer agreement. Be sure to note that the Team will be evaluating the
changes to assure that they have the capability of providing the
requested changes. Approval authorities (those listed on the signature
page) must be listed specifically by name and title. It must be stated
that they consist of the Change Control Board (CCB) or the CCB
process/membership must be described or referenced. The original
approval authority must approve changes.

**2.0 Design Planning and Interface Management (GPG 8700.1)**

+-----------------------+------------------------+---------------------+
| Controlled Document   | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Product Plan          | Signed and dated by    | Team Lead           |
|                       | the CCB which is       |                     |
|                       | listed in              |                     |
|                       | Plan---usually Team    |                     |
|                       | Lead, Branch Head,     |                     |
|                       | Customer.              |                     |
+-----------------------+------------------------+---------------------+
| Design Planning       | May be in product      | Team Lead           |
| Materials             | plan.                  |                     |
|                       |                        |                     |
| -   Review Plan       |                        |                     |
|                       |                        |                     |
| -   Development       |                        |                     |
|     Phases            |                        |                     |
+-----------------------+------------------------+---------------------+

+-----------------------+------------------------+---------------------+
| Objective Evidence    | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Design Planning       | May be included in     | Team Lead           |
| Materials             | product plan by        |                     |
|                       | reference.             |                     |
| -   Team Work         |                        |                     |
|     Assignments       |                        |                     |
|                       |                        |                     |
| -   Team Organization |                        |                     |
|                       |                        |                     |
| -   Schedules         |                        |                     |
|                       |                        |                     |
| -   Budgets           |                        |                     |
+-----------------------+------------------------+---------------------+

2.1 General development approach

Describe in a sentence or two the general philosophy that will be used
to build the product, discussing such aspects as use of
commercial-off-the-shelf (COTS), contractor involvement, schedule
constraint, use of a particular development methodology or new
technology, etc.

2.2 Resources needed (budget, people/skills, and facilities)\*

Indicate where the *official* budget is kept. In most cases, the budget
will probably reside with the Project. Budget information should be kept
by fiscal year, and include both civil servant manpower and any
contractor support. Address any specific facilities or any facility
modifications required for use in development or testing and their
expected required dates.

2.3 Team Organization

2.3.1 Team Organization

Include an explanation or diagram illustrating the organization of the
Team personnel and its activities. Note: Any Team organization chart not
included in the product plan must be signed and dated. Include the
relationship of the Team Lead to the higher level Project organization,
if applicable.

2.3.2 Roles, Responsibilities, Authority, Accountability of Team
Members\*

Describe the method used to assign work to Team members and document the
work assignments. Assignments can be made by subsystem (e.g. Command &
Data Handling, Planning & Scheduling) or by work function (e.g. testing)

2.3.3 Decision making and conflict resolution process

Describe the method used to resolve conflicts within the Team. If group
decisions are used, identify the tiebreaker or ultimate decision
authority.

2.4 Team interfaces to other teams, organizations, or groups

Describe any interfaces to other organizations, teams, or groups
necessary in developing the product, and a *brief* description of the
purpose of each interface. This may include things such as the interface
of the ISD flight software team to the flight hardware group for working
compatibility issues, or the interface of the Ground Data System to the
Flight Operations Team for acceptance of the system.

2.5 Procurement\* (GPG 5100.1)

Describe all hardware and software purchase requirements in detail
(i.e., What are you going to buy?) Include any purchases necessary for
facility modification. If you are using contractor support, list the
contractor name and contract number. If special or usual contracting
arrangements are required, describe them. Reference the procurement
process used to make purchases. Be sure to use RITS for all items within
scope.

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Purchase Requests                                  Team Lead or Team
                                                     procurement person
  ------------------------ ------------------------- ---------------------

2.6 Team training plan\* (GPG 3410.2)

Identify any QMS Required Task Specific training need for each Team
member. When training is complete, document it by keeping a list of
name, course, and date completed. (QMS Required Task Specific training
is defined as training that must be taken to acquire new skills or
enhance current skills required to perform tasks of that position that
affect quality. Examples are Hand Soldering Certification, Electrostatic
Discharge Awareness Training, Laser Safety, Cleanroom Procedures, Range
or Launch Safety Training, Flight Operations Team Certification, or any
required Project-specific training)

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Records of Required                                Team Lead or Project
  Training Needed                                    

  Records of Required                                Team Lead or Project
  Training Completed                                 
  ------------------------ ------------------------- ---------------------

2.7 Risk mitigation

Describe any areas where there is a special risk to the delivery of the
product (if any) and describe how it will be addressed. If there is
none, state that.

2.8 Security

Describe the plans for addressing security considerations, both
physically for the facilities involved and electronically for any
computer systems being used either for development and testing or as a
part of the final product.

2.9 Detailed Schedules\*

This should be the detailed schedule used to manage the Team's
activities. It should contain the Team life cycle schedule including
facility preparations, procurements, system development by phase and
release, product delivery, and maintenance (if applicable). Make sure to
include review dates, documentation, interface control document\'s
(ICD\'s) delivery dates; test dates, software release dates,
procurements, and external deliveries to the customer. It should include
and be consistent with customer schedules defined in Section 1.7.

2.10 Technology and commercialization plan

This should describe any technology advancement, technology infusion,
and commercialization initiatives that are drivers for any aspect of
this product plan. Especially describe any initiative for which the
corresponding product plan activities would not be performed if the
technology or commercialization initiative was not considered. If there
is none, state that.

**3.0 Technical Approach**

3.1 Design Development (GPG 8700.2)

3.1.1 Product Requirements\*

Describe (or reference) the derived requirements/specifications
developed by the Team and approved by the Customer. These should include
assumptions, interfaces, and performance information. Ensure that
requirements are testable. These requirements can be the customer's
original requirements (if so, just reference Section 2.3) or can be
those derived by the Team itself.

  ------------------------ ------------------------- ---------------------
  Controlled Document      Comment                   Record Held By

  Derived Requirements     Signed and dated by       Project or Team Lead
                           Customer and Team Lead    

  Interface Control        Signed and dated by       Project or Team Lead
  Documents                Representatives of        
                           Interfacing Organizations 
  ------------------------ ------------------------- ---------------------

3.1.2 Product Design\*

Describe the design of the product that the Team is planning to produce.
Describe how changes in design are updated and traced to changes in the
requirements.

+-----------------------+------------------------+---------------------+
| Quality Record        | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Completed Design      | May include:           | Team Lead           |
| Documentation         |                        |                     |
|                       | -   High-level         |                     |
|                       |     architecture       |                     |
|                       |     description        |                     |
|                       |                        |                     |
|                       | -   Design Review      |                     |
|                       |     Materials          |                     |
|                       |                        |                     |
|                       | -   Design Documents   |                     |
+-----------------------+------------------------+---------------------+

3.1.3 Development Strategy

Describe at a HIGH LEVEL the software components you will build, the
commercial off-the-shelf/Government off-the-shelf (COTS/GOTS) or
customer supplied items you will use, the prototyping plans, and the
integration requirements.

3.1.3.1 Buy Approach\* (GPG 5100.1)

Describe any special purchasing strategies for items specified in
Section 2.5.

3.1.3.2 Build Approach\*

Include the development phases, the sequence of builds, the high level
inputs and outputs per build, vendor/customer/prototype elements to be
integrated, and the high level functional requirements satisfied in each
build.

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Completed Build Plan     Part of software work     Team Lead
                           order authorization (WOA) 
  ------------------------ ------------------------- ---------------------

3.1.3.3 Prototyping Approach\*

Describe any prototyping activities required to develop the product and
the purpose for the prototype (i.e., what specific questions are to be
answered by the prototype?)

3.1.3.4 Customer Supplied Products Approach

List and briefly describe any software that will be received from the
customer for integration into the final product, and any assumptions
concerning them.

3.1.4 Product Testing

3.1.4.1 Product inspection and test \* (GPG 5330.1)

Describe the testing approach from unit through product delivery
(including in-process and final inspection). Reference your test plans
and discuss your testing approach for unit, build, and acceptance
testing, test team (developers, independent, customer), test data
(simulator, supplied data, flight hardware, real data), and any
acceptance criteria (particularly any from the customer for final
acceptance---Section 2.11). Describe how changes in design are mapped to
changes in test plans.

+-----------------------+------------------------+---------------------+
| Controlled Document   | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Documentation of      | Include one or more:   | Team Lead           |
| Verification          |                        |                     |
| Activities            | -   Unit Test Plans    |                     |
|                       |                        |                     |
|                       | -   Code Reading       |                     |
|                       |     Checklist          |                     |
|                       |                        |                     |
|                       | -   Design Baseline    |                     |
|                       |                        |                     |
|                       | -   Integration Test   |                     |
|                       |     Plans              |                     |
|                       |                        |                     |
|                       | -   Build Test Plans   |                     |
+-----------------------+------------------------+---------------------+

+-----------------------+------------------------+---------------------+
| Quality Record        | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Documentation of      | Include one or more:   | Team Lead           |
| Verification          |                        |                     |
| Activities            | -   Unit Test Results  |                     |
|                       |                        |                     |
|                       | -   Code Reading       |                     |
|                       |     Signoffs           |                     |
|                       |                        |                     |
|                       | -   Design Walkthrough |                     |
|                       |     Documentation      |                     |
|                       |     (including issues  |                     |
|                       |     and resolutions)   |                     |
|                       |                        |                     |
|                       | -   Integration Test   |                     |
|                       |     Results            |                     |
|                       |                        |                     |
|                       | -   Build Test Results |                     |
+-----------------------+------------------------+---------------------+

+-----------------------+------------------------+---------------------+
| Controlled Document   | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Documentation of      | **Include one or       | **Team Lead**       |
| (End-to-End) System   | more:**                |                     |
| Validation Activities |                        |                     |
|                       | -   High Level         |                     |
|                       |     Description of     |                     |
|                       |     Test To Be Run     |                     |
|                       |     (Can be in Test    |                     |
|                       |     Procedures)        |                     |
|                       |                        |                     |
|                       | -   Test Validation    |                     |
|                       |     Matrices           |                     |
|                       |                        |                     |
|                       | -   Detailed           |                     |
|                       |     Description of     |                     |
|                       |     Tests with Inputs, |                     |
|                       |     Expected Outputs,  |                     |
|                       |     and Step by Step   |                     |
|                       |     Procedures for     |                     |
|                       |     Running the Tests  |                     |
|                       |                        |                     |
|                       | -   Acceptance         |                     |
|                       |     Criteria           |                     |
+-----------------------+------------------------+---------------------+

+-----------------------+------------------------+---------------------+
| Quality Record        | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Documentation of      | Include one or more:   | Team Lead           |
| (End-to-End) System   |                        |                     |
| Validation Activities | -   Validation         |                     |
|                       |     Matrices           |                     |
|                       |                        |                     |
|                       | -   Validation Test    |                     |
|                       |     Results            |                     |
+-----------------------+------------------------+---------------------+

3.1.4.2 Incoming inspection and test (GPG 4520.2)

For purchased items, including hardware, document the Receiving
Inspection Instructions to describe special receiving instructions and
tests if other than kind, count and condition. Be sure that all in-scope
products received after May 1, 1999, are identified and entered into the
RITS system.

  ------------------------ ------------------------- ----------------------
  Quality Record           Comment                   Record Held By

  Receiving Inspection     RITS entry made by Team   Team Lead or Team
  Instruction (RITS entry) Lead or Team purchase     purchase person
                           person                    

  RITS Work Order                                    Team Lead
  Authorization (WOA)                                

  Incoming Inspection      See GPG 5340.2            Center Nonconformance
  Nonconformance Report                              Reporting/Corrective
                                                     Action (NCR/CA) System
  ------------------------ ------------------------- ----------------------

3.1.4.3 Statistical Techniques\* (GPG 8070.2)

Unless the Team determines a need for statistical testing of the product
or other statistical methods, include the following paragraph in this
section of your Product Plan.

"The Team has evaluated the need for statistical testing of the products
developed under this Product Plan and has determined that statistical
techniques are not required."

Examples of statistical techniques being used are (1) techniques to
obtain reliability of hardware systems and (2) comparisons of output
results after a platform language conversion. If statistical techniques
are being used, then the procedure for their use must be documented.

3.1.5 Development Status\*

3.1.5.1 Design/Implementation Status

Describe the method(s) that will be used to track the status through
this phase of the product.

+-----------------------+------------------------+---------------------+
| Objective Evidence    | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Status Information    | May include:           | Team Lead or        |
|                       |                        | designee            |
|                       | -   Schedule Charts    |                     |
|                       |     with Status        |                     |
|                       |     Indicated          |                     |
|                       |                        |                     |
|                       | -   Module-by-Module   |                     |
|                       |     Checklist          |                     |
|                       |                        |                     |
|                       | -   Configuration      |                     |
|                       |     Management Records |                     |
|                       |                        |                     |
|                       | -   Documentation of   |                     |
|                       |     Weekly Status      |                     |
|                       |     Meetings           |                     |
+-----------------------+------------------------+---------------------+

3.1.5.2 Testing Status

Describe the method used to track testing status of the product
throughout its life cycle.

+-----------------------+------------------------+---------------------+
| Objective Evidence    | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Test Status           | May include:           | Team Lead or        |
| Information           |                        | designee            |
|                       | -   Test Status Chart  |                     |
|                       |                        |                     |
|                       | -   Weekly Test        |                     |
|                       |     Meeting Status     |                     |
|                       |                        |                     |
|                       | -   Signoffs of        |                     |
|                       |     Completed Tests in |                     |
|                       |     Test Plan or       |                     |
|                       |     Procedures         |                     |
+-----------------------+------------------------+---------------------+

3.1.6 Development Environment

Describe the development and test hardware and locations, and all Team
development standards, as appropriate.

3.1.7 Technical Review Program (GPG 8700.4)

Describe the types of reviews you plan to have and the membership of the
review boards. This should include a discussion of any code or design
walkthroughs you plan to use as verification of the design. You must
have at least a requirements review, a design review, and a product
acceptance review with the customer where requests for action (RFAs) and
responses are kept. Peer reviews as defined by GPG 8700.6 may include
team reviews where one team member reviews another team member's work
and should be included on the Team review plan. Project related reviews
and other higher level reviews may be supported as requested and they
should be listed in the Project Plan.

+-----------------------+------------------------+---------------------+
| Quality Record        | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| -   Requests for      | Include One            | Team Lead or CCB    |
|     Action (RFAs) and |                        | Chair               |
|     Responses from    |                        |                     |
|     Review Meetings   |                        |                     |
|                       |                        |                     |
| -   Review Meeting    |                        |                     |
|     Notes with Action |                        |                     |
|     Item List and     |                        |                     |
|     Resolutions       |                        |                     |
+-----------------------+------------------------+---------------------+

3.2 Process for handling, storage, packing, marking, preservation and
transportation (GPG 6400.1)

List the medium for the various products to be delivered if different
from Section 1.6 and state how they will be delivered to the customer.
Describe any plans (such as back-ups) to prevent loss or damage to the
product in all phases of development, including software, documentation
and hardware.

3.3 Servicing

Describe the process for post delivery product maintenance (i.e., How do
you plan to meet the requirements specified in Section 2.8?) Address
responsibility for the maintenance, request process, process for doing
work, and product redelivery for custom, government off-the-shelf (GOTS)
and COTS software and hardware.

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Maintenance requests                               Team Lead

  Redelivery letters                                 Team Lead
  ------------------------ ------------------------- ---------------------

**4.0 Product Assurance**

4.1 Product Quality Assurance

4.1.1 Control of Nonconforming Products and Corrective Action\* (GPG
5340.2/\
GPG 1710.1)

Describe the process for recording and correcting problems in a "minor"
Nonconformance Reporting (NCR)/Corrective Action system. Include a
description of the process used to evaluate the cause of the problem and
to assess whether any changes need to be implemented to prevent future
recurrences. The minor NCR system should include the version or release
number where the problem was found and ideally, the version number that
includes the corrections. Nonconforming products are both identified by
their associated NCRs and the associated release numbers. Any products
released to the customer will include a ***release letter*** listing the
release number, the included capabilities of the release, and a
description of any remaining nonconformance in the release. Products
with remaining nonconformance may only be released to the customer with
proper approval. (See Library of Approved Team Processes or Criteria 7
in Appendix F.) The Center nonconformance reporting/corrective action
(NCR/CA) system shall be used if no minor nonconformance system exists
or if the nonconformance meets the Center wide criteria listed in the
GPG.)

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Nonconformance records                             Team Lead or
  from minor NCR system                              Nonconformance Lead

  Nonconformance records                             Center NCR system
  from Center NCR system                             

  Corrective Action Plans  May be in NCR system      Team Lead or
                                                     Nonconformance Lead

  Product Release Letters                            Team Lead
  ------------------------ ------------------------- ---------------------

4.2 Configuration Management (GPG 1410.2)

4.2.1 Control of Team software, hardware, documentation, and data\*

Describe how your Team does configuration management for your software,
hardware and documentation and who has the change authority for each. If
you use the Project's process for any of those, reference where their
procedures can be found. Describe the signature and change authority for
the development sections of the Product plan. Describe the method used
to uniquely identify versions of the software and the elements from
which it is built. The use of a commercial configuration management tool
is strongly recommended for environments where one is available. If
on-line copies of documentation or software are considered the
controlled copy, then the approval authority must control on-line
access. A list of documents and data under configuration management by
the team is to be referenced in the Product Plan in this section. The
list is to include the document or database name, the date or version
identification of the current version, the location of the documents or
database, and the person responsible for the item. Note: Any data bases
or web sites containing controlled information directly under the Team's
control shall contain a header identifying what is being viewed, as well
as the date of the last change and person responsible for its control.
(See Library of Approved Team Processes or Criteria 2B and 2B in
Appendix F.)

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Software CM records                                Team Lead (or
                                                     Configuration
                                                     Manager)

  List of items under                                Team Lead (or
  configuration management                           Configuration
                                                     Manager)

  Copy of signature page                             Team Lead (or
  of configuration                                   Configuration
  management item                                    Manager)

  Records of CCB approval                            Team Lead (or
                                                     Configuration
                                                     Manager)
  ------------------------ ------------------------- ---------------------

4.2.2 Control of test software and hardware (GPG 8730.1)

Describe anything used to test the product, which may be both hardware
and software. Describe how this software will be validated (i.e., how do
you convince yourself that the simulator is working properly?) If the
software used for testing is not the final validation, but is only used
as part of a self-check, where neither the test software or the product
being tested is considered correct until the final results are correct,
then describe that test scenario. Describe or reference the
configuration management process used to ensure the appropriate version
of the simulator is used. See Library of Approved Team Processes or
Criteria 4 in Appendix F. Also, discuss any inspection, measuring and
test equipment (IMTE) being used and any calibration requirements.

+-----------------------+------------------------+---------------------+
| Controlled Document   | Comment                | Record Held By      |
+-----------------------+------------------------+---------------------+
| Documentation of Test | Include one or more:   | Team Lead           |
| Software Verification |                        |                     |
| Activities            | -   Test Plans         |                     |
|                       |                        |                     |
|                       | -   Acceptance         |                     |
|                       |     Criteria           |                     |
+-----------------------+------------------------+---------------------+

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Calibration records and                            Team Lead
  calibration due dates                              
  for IMTE Team is using                             

  Test software test                                 Team Lead
  results                                            

  Records of Verification                            Team Lead
  from Contractor                                    
  ------------------------ ------------------------- ---------------------

4.2.3 Quality Records\* (GPG 1440.7)

Identify the Team's Quality Records Coordinator (person who keeps the
Quality Records List) and the location of the Quality Records List.
Describe the process by which an element is added to the Quality Record
List by the Coordinator and filed with the Custodian.

  ------------------------ ------------------------- ---------------------
  Controlled Document      Comment                   Record Held By

  Quality Records List                               Team Lead
  ------------------------ ------------------------- ---------------------

4.2.4 Control of customer supplied products\* (GPG 5900.1)

Describe the method that will be used to check out or test the software
or hardware supplied to you by the customer for inclusion into the
product or for testing or packaging of the product. If a customer
provides items for use by the Team in the development/testing of the
product, describe the process used to report any problems with the
item(s) back to the customer. Describe the configuration management
process for customer supplied elements listed in Section 1.12 for
changes initiated by the Team or by the customer. Include any other
processes used to safeguard customer supplied products. (See Library of
Approved Team Processes or Criteria 3 in Appendix F.) This section
should address simulators, test data, software algorithms, software
and/or hardware received from the customer.

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Problem Reports on                                 Team Lead
  Customer-Supplied                                  
  Products                                           
  ------------------------ ------------------------- ---------------------

4.3 Process and product metric analysis\*

It is a requirement to collect the metrics described in Appendix G, at a
minimum. Additionally, product metrics, Team process metrics, and ISD
metrics may be collected. Describe how you will use these metrics for
process improvement (see Library of Approved Team Processes or
Criteria 10 in Appendix F).

  ------------------------ ------------------------- ---------------------
  Quality Record           Comment                   Record Held By

  Data and Completed Forms                           Team Lead
  Representing the                                   
  Required Metrics                                   
  ------------------------ ------------------------- ---------------------

**5.0 Product Development Journals**

5.1 Team Lessons Learned

Maintain a log of lessons learned throughout the life cycle of the team
activities. The final lessons learned report is intended to be a brief
(about one-half page) summary of the key recommendations for changes or
inclusion in future similar projects.

  ------------------------ ------------------------- ---------------------
  Objective Evidence       Comment                   Record Held By

  Lessons Learned Log or                             Team Lead
  document                                           
  ------------------------ ------------------------- ---------------------

5.2 Key Issues, Decisions, and Rationale

Maintain a log of key issues, decisions, and rationale through the life
cycle of the Team.

  ------------------------ ------------------------- ---------------------
  Objective Evidence       Comment                   Record Held By

  Log of Key Issues,                                 Team Lead
  Decisions, rationale                               
  ------------------------ ------------------------- ---------------------

\*Items may be included by reference

Appendix A: Acronyms and Abbreviations

Appendix B: References

Include a list of any references used in the Product Plan.