NOAA NESDIS CENTER for SATELLITE APPLICATIONS and … › ... › STAR_DG-09.2.0_TRD_v3r0.pdf · 4.8. Section 4 – Unit Test Readiness ..... 22 4.9. Section 5

Hardcopy Uncontrolled

NOAA NESDIS

CENTER for SATELLITE APPLICATIONS and RESEARCH

DOCUMENT GUIDELINE

DG-9.2 TEST READINESS DOCUMENT

GUIDELINE Version 3.0

NOAA NESDIS STAR DOCUMENT GUIDELINE

DG-9.2 Version: 3.0

Date: October 1, 2009 TITLE: Test Readiness Document Guideline

Page 2 of 2


TITLE: DG-9.2: TEST READINESS DOCUMENT GUIDELINE VERSION 2.0 AUTHORS:

Ken Jensen (Raytheon Information Solutions)

TEST READINESS DOCUMENT GUIDELINE VERSION HISTORY SUMMARY

Version Description Revised

Sections Date

1.0 No version 1

2.0 New Document Guideline (DG-12.1) by Ken Jensen (Raytheon Information Solutions) New

Document 11/16/2007

3.0 Renamed DG-9.2 and revised by Ken Jensen (Raytheon Information Solutions) for version 3. All 10/1/2009


DG-9.2 Version: 3.0


Page 3 of 3


TABLE OF CONTENTS

Page

LIST OF ACRONYMS ....................................................................................... 4

1. INTRODUCTION ........................................................................................ 6 1.1. Objective......................................................................................... 6 1.2. The Test Readiness Document ...................................................... 6 1.3. Background .................................................................................... 7 1.4. Benefits........................................................................................... 7 1.5. Overview ......................................................................................... 8

2. REFERENCE DOCUMENTS ....................................................................... 9

3. STANDARD SECTIONS .............................................................................. 13

4. SECTION GUIDELINES ............................................................................... 15 4.1. Slide Master .................................................................................... 15 4.2. Title Slide ........................................................................................ 15 4.3. Review Outline Slide....................................................................... 16 4.4. Review Agenda Slide ...................................................................... 16 4.5. Section 1 – Introduction .................................................................. 16 4.6. Section 2 – CDR Report ................................................................. 18 4.7. Section 3 – Software Architecture .................................................. 19 4.8. Section 4 – Unit Test Readiness ........................... 22 4.9. Section 5 – Unit Test Readiness ........................... 24 4.10. Section 6 – Risks and Actions ...................................................... 24 4.11. Section 7 – Summary and Conclusions ........................................ 25

APPENDIX A – TEMPLATE FILE ..................................................................... 27


DG-9.2 Version: 3.0


Page 4 of 4


LIST OF ACRONYMS CDD Critical Design Document CDR Critical Design Review CDRR Critical Design Review Report CICS Cooperative Institute for Climate Studies CIMSS Cooperative Institute for Meteorological Satellite Studies CIOSS Cooperative Institute for Oceanographic Satellite Studies CIRA Cooperative Institute for Research in the Atmosphere CL Check List CLI Check List Item CM/DM Configuration Management/Data Management CREST Cooperative Remote Sensing and Technology Center DDD Detailed Design Document DG Document Guideline EPL Enterprise Product Lifecycle ICD Interface Control Document IPT Integrated Product Team NESDIS National Environmental Satellite, Data, and Information Service NOAA National Oceanic and Atmospheric Administration PAR Process Asset Repository PBR Project Baseline Report PG Process Guideline PPS Product Processing System PRG Peer Review Guideline QA Quality Assurance RAD Requirements Allocation Document


DG-9.2 Version: 3.0


Page 5 of 5


SG Stakeholder Guideline SOW Statement Of Work STAR Center for Satellite Applications and Research SWA Software Architecture Document TBD To Be Determined TD Training Document TG Task Guideline TRD Test Readiness Document TRR Test Readiness Review UTP Unit Test Plan VVP Verification and Validation Plan


DG-9.2 Version: 3.0


Page 6 of 6


1. INTRODUCTION

The NOAA/NESDIS Center for Satellite Applications and Research (STAR) develops a diverse spectrum of complex, often interrelated, environmental algorithms and software systems. These systems are developed through extensive research programs, and transitioned from research to operations when a sufficient level of maturity and end-user acceptance is achieved. Progress is often iterative, with subsequent deliveries providing additional robustness and functionality. Development and deployment is distributed, involving STAR, the Cooperative Institutes (CICS, CIMSS, CIOSS, CIRA, CREST) distributed throughout the US, multiple support contractors, and NESDIS Operations. NESDIS/STAR is implementing an increased level of process maturity to support the exchange of these software systems from one location or platform to another. The Test Readiness Document (TRD), a Microsoft PowerPoint file, is one component of this process.

1.1. Objective

The objective of this Document Guideline (DG) is to provide STAR standards for the TRD. The intended users of this DG are the personnel assigned by the Development Lead to the task of creating a TRD for the project.

1.2. The Test Readiness Document

The TRD is the presentation document for a project’s Test Readiness Review (TRR)1. The TRR is an important milestone of each project’s product lifecycle. It reviews the project’s readiness to conduct tests of the software units. The software units are the Layer-2 elements that are defined in the system-layer product software architecture, as described in the Software Architecture Document (SWA). The TRD should accomplish the following objectives:

» Identify relevant stakeholders and document their involvement according to the project plan.

» Provide all applicable technical data for the unit tests, including: – Software architecture and interfaces – Unit test requirements

1 Refer to the STAR EPL Process Guidelines (PG-1 and PG-1.A) for a description of the STAR EPL gates and reviews.


DG-9.2 Version: 3.0


Page 7 of 7


– Unit test plans » Identify and evaluate risks. Provide risk mitigation plans. » Document the closing of all action items since Critical Design Review (CDR).

Make recommendations for open actions and new actions. The intended target audience is the TRR reviewers. Typically, the TRD is prepared by the project’s development team under the direction of the Development Lead.

The TRD should be developed as a Microsoft PowerPoint document. Upon approval, the approved version of the TRD may be converted to an Adobe pdf file for storage in the project artifact repository.

1.3. Background

This DG defines standards and guidelines for producing a TRD. It contains all information needed for a project’s development team to produce a TRD that enables the TRR reviewers to confirm that the project is in compliance with all TRR requirements.

1.4. Benefits

A TRD developed in accordance with the standards in this DG enables the TRR reviewers to confirm that the project is in compliance with all TRR requirements. It is therefore a requirement that a TRD be developed in accordance with the guidelines in this document before obtaining TRR approval. The TRD will be reviewed at the TRR to determine whether a project proceeds to the Code Refinement and Test step of the STAR Enterprise Product Lifecycle (EPL)2.

2 A description of the STAR EPL can be found in STAR EPL process asset PG-1 (c.f. Section 2 of this document).


DG-9.2 Version: 3.0


Page 8 of 8


1.5. Overview

This DG contains the following sections: Section 1.0 - Introduction Section 2.0 - References Section 3.0 - Standard Sections Section 4.0 - Section Guidelines Appendix A - Template File


DG-9.2 Version: 3.0


Page 9 of 9


2. REFERENCE DOCUMENTS

CDD: Critical Design Document is a Microsoft PowerPoint file that contains the CDR presentation slides. It is often convenient for the TRD developers to adopt or adapt these slides for inclusion in the TRD. This document will be available to approved users in a project artifact repository. DPP: Development Project Plan is an artifact for the TRR. It should include the project plan, schedule, and resources, identify stakeholders, identify TRR entry and exit criteria, provide the TRR Check List Items (CLI), and include the project objectives, tasks, milestones, stakeholders, and schedule. This information will be useful for the TRD developers in completing Section 1 of the TRD. The TRD developers should check with the Development Lead and STAR CM/DM to determine the latest approved version of the DPP. If a DPP update is being developed concurrently with the TRD, the TRD developers should consult with the DPP developers to ensure consistency of information in the TRD and the DPP. The DPP will be available to the approved users in a project artifact repository. CDRR: Critical Design Review Report is an artifact for the TRR. It is the reviewer’s report from the CDR. This information will be useful for the TRD developers in completing Section 2 of the TRD. This document will be available to approved users in a project artifact repository. SWA: Software Architecture Document is a project artifact that contains the software architecture and data flows for the project algorithm. This information will be useful for the TRD developers in completing Section 3 of the TRD. This document will be available to approved users in a project artifact repository. SWA v2r1, the version presented at the CDR, is nominally the current version for TRR. If there have been changes to the software architecture since CDR, there may be a SWA v2r2. The TRD developers should check with the Development Lead and STAR Configuration Management/Data Management (CM/DM) to determine the latest approved version of the SWA. If a SWA update is being developed concurrently with the TRD, the TRD developers should consult with the SWA developers to ensure consistency of information in the TRD and the SWA. UTP: Unit Test Plan v1r0 is a project artifact for the TRR. It provides a complete description of the plans for each unit test. This information will be useful for the TRD developers in completing Section 4 of the TRD. If it has been completed, this document will be available to approved users in a project artifact repository. It is expected that UTP v1r0 will be developed concurrently with the TRD, as the TRD largely reflects the information in


DG-9.2 Version: 3.0


Page 10 of 10


UTP v1r0. The TRD developers should consult with the UTP developers to ensure consistency of information in the TRD and UTP v1r0. DDD: Detailed Design Document is a project artifact that describes the product design at a level of detail that is sufficient for the development programmers to write fully functional pre-operational code. This information will be useful for the TRD developers in completing Section 4 of the TRD. A separate DDD is produced for each software unit that is part of the product processing system (PPS). These documents will be available to approved users in a project artifact repository. DDD v2r0, the version presented at the CDR, is nominally the current version for TRR. If there have been changes to the detailed design since CDR, there may be a DDD v2r1. The TRD developers should check with the Development Lead and STAR CM/DM to determine the latest approved version of the DDD. If a DDD update is being developed concurrently with the TRD, the TRD developers should consult with the DDD developers to ensure consistency of information in the TRD and the DDD. RAD: Requirements Allocation Document is a project artifact that contains the basic and derived requirements for the work products and the allocation of the requirements to system components and product components. This information will be useful for the TRD developers in completing Section 4.4 of the TRD. This document will be available to approved users in a project artifact repository. RAD v1r2, the version presented at the CDR, is nominally the current version for TRR. If there have been changes to the requirements allocation since CDR, there may be a RAD v1r3. The TRD developers should check with the Development Lead and STAR CM/DM to determine the latest approved version of the RAD. If a RAD update is being developed concurrently with the TRD, the TRD developers should consult with the RAD developers to ensure consistency of information in the TRD and the RAD. PBR: Project Baseline Report v2r0 is an artifact for the TRR. It provides a listing of all items in the project’s baseline. This information will be useful for the TRD developers in providing pointers to the project artifacts and in completing Section 4.7 of the TRD. This document will be available to approved users in a project artifact repository. This version of the Project Baseline Report (PBR) will include all of the other TRR artifacts, and therefore should be the last TRR artifact to be finalized. The TRD developers should be in contact with the PBR developer to obtain the correct pointers to the project artifacts prior to the finalization of PBR v2r0. VVP: Verification and Validation Plan is a project artifact that describes the work products to be verified and validated, the requirements for each selected work product and the verification and validation methods for each selected work product. This information will


DG-9.2 Version: 3.0


Page 11 of 11


be useful for the TRD developers in completing Section 4.8 of the TRD. This document will be available to approved users in a project artifact repository. VVP v1r2, the version presented at the CDR, is nominally the current version for TRR. If there have been changes to the verification items since CDR, there may be a VVP v1r3. The TRD developers should check with the Development Lead and STAR CM/DM to determine the latest approved version of the VVP. If a VVP update is being developed concurrently with the TRD, the TRD developers should consult with the VVP developers to ensure consistency of information in the TRD and the VVP. All of the following references are STAR EPL process assets that are accessible in a STAR EPL Process Asset Repository (PAR) on the STAR web site: http://www.star.nesdis.noaa.gov/star/EPL_index.php. PG-1: STAR EPL Process Guideline provides the definitive description of the standard set of processes of the STAR EPL. PG-1.A: STAR EPL Process Guideline Appendix, an appendix to PG-1, is a Microsoft Excel file that contains the STAR EPL process matrix (Stakeholder/Process Step matrix), listings of the process assets and standard artifacts, descriptions of process gates and reviews, and descriptions of stakeholder roles and functions. PRG-9: Test Readiness Review Guidelines are the guidelines for the TRR. It is useful for the TRD developers to understand what the reviewers will expect when reviewing the TRD. DG-9.2.A: Test Readiness Document Guideline Appendix is an Appendix to DG-8.2 (this document). It contains Microsoft PowerPoint slide templates for the TRD slides described in DG-8.2. SG-13: STAR EPL Development Lead Guidelines provides a description of standard tasks for Development Leads, including development of the TRD. SG-14: STAR EPL Development Scientist Guidelines provides a description of standard tasks for Development Scientists, including development of the TRD. SG-15: STAR EPL Development Tester Guidelines provides a description of standard tasks for Development Testers, including development of the TRD.

http://www.star.nesdis.noaa.gov/star/EPL_index.php


DG-9.2 Version: 3.0


Page 12 of 12


SG-16: STAR EPL Development Programmer Guidelines provides a description of standard tasks for Development Programmers, including development of the TRD. TG-9: STAR EPL Code and Test Data Development Task Guidelines provides a description of standard tasks for process step 9, during which the TRD is developed.


DG-9.2 Version: 3.0


Page 13 of 13


3. STANDARD SECTIONS

The TRD slides are organized into sections. The standards sections are:

1.0 INTRODUCTION 1.1 Development Project Plan 1.2 Project Objectives 1.3 Project Stakeholders 1.4 Project Timeline 1.5 Project Plan Changes 1.6 Stakeholder Involvement 1.7 TRR Guidelines and Check List 1.8 TRR Report 1.9 Review Objectives

2.0 CDR REPORT 2.1 CDR Report 2.2 TRR Entry Criteria 2.3 TRR Exit Criteria

3.0 SOFTWARE ARCHITECTURE AND INTERFACES 3.1 Software Architecture Overview 3.2 Context-Layer 3.3 System-Layer

4.0 UNIT TEST READINESS 4.1 Purpose and Function 4.2 Process Flow 4.3 Test Items 4.4 Requirements Trace 4.5 Test Data Description


DG-9.2 Version: 3.0


Page 14 of 14


4.6 Test Environment 4.7 Test Configuration 4.8 Test Methods 4.9 Test Sequence 4.10 Unit Test Risks

5.0 UNIT TEST READINESS (repeat for all units) 5.1 Purpose and Function 5.2 Etc. – same subsections as Section 4.0

6.0 RISKS AND ACTIONS 6.1 CDR Risks and Actions 6.2 New Risks and Actions 6.3 Risk Summary

7.0 SUMMARY AND CONCLUSIONS 7.1 Review Objectives Status 7.2 Issues, Actions and Risks 7.3 Next Steps 7.4 Open Discussion


DG-9.2 Version: 3.0


Page 15 of 15


4. SECTION GUIDELINES

This section contains the STAR guidelines for each section of the TRD. TRD developers will benefit greatly from using the slide templates contained in the “STAR_DG-9.2.A_TRD_ v3r0.ppt” file, hereafter referred to as DG-9.2.A. DG-9.2.A is an Appendix to this document. Note that the slides in DG-9.2.A include figures, tables, and bulleted text. All figures, tables and bulleted text should be adopted as they appear in these slides, except for text between delimiters, like this: Text between delimiters consists of guidelines. The TRD developers should replace this text with appropriate text, as suggested by the guidelines.

4.1. Slide Master

It is recommended, but not required, that TRD developers use the Slide Master from DG-9.2.A as the Slide Master for the TRD. A development team may wish to tailor its Slide Master. For example, a different slide background color that has been established as a “team color” may be used. Whether or not the Slide Master is tailored, the slide master shall include the STAR logo in the upper left corner of the slide, following the Slide Master in DG-9.2.A. The STAR logo should be identical to the Picture on the cover page of this document. Another example of tailoring is to add organization logos to the upper right corner of the slide, if the development team is non-STAR (e.g. a Cooperative Institute or Contractor). The Slide Master for DG-9.2.A includes the Raytheon logo as an example. This should be replaced by the appropriate logos, or no logo if the development team consists of STAR personnel.

4.2. Title Slide

The first slide shall be a Title Slide, labeled “Title Slide”3 in DG-9.2.A. The Title Slide shall include the Project and/or Product Name4 and the Preparer’s Names and Organizations.

3 The slide templates in DG-9.2.A are labeled in text boxes located in one of the lower corners of each slide. 4 In the slide templates, unspecified (generic) fields are indicated by the convention. The TRD developers should fill these in with the appropriate information specific to the project’s TRR.


DG-9.2 Version: 3.0


Page 16 of 16


4.3. Review Outline Slide

The second slide shall be a Review Outline Slide, labeled “Review Outline Slide” in DG-9.2.A. The Review Outline Slide shall be a numbered list of each section of the presentation. The number of sections will depend upon the number of software units to be tested. “Review Outline Slide” provides an example for the case where there are two units. “Review Outline Slide – 3 Units” provides an example for the case where there are three units. The extension to cases where there are more units should be clear.

4.4. Review Agenda Slide

The third slide shall be a Review Agenda Slide, labeled ”Review Agenda Slide” in DG-9.2.A. The Review Agenda Slide shall list each section of the presentation, the scheduled time interval for the presentation of the section, and the name of the presenter(s) for that section. “Review Agenda Slide” provides an example for the case where there are four software units. It is not required that the locations of the Break and Lunch periods be exactly where they are indicated in this slide. The development team should tailor its schedule to fit the contents of each section.

4.5. Section 1 – Introduction

The TRD shall include an Introduction Section. This section shall include:

• A setup slide, labeled “Section 1 Setup Slide” in DG-11.2.A. This slide is a numbered list of all sections, with Section 1 highlighted, as shown.

• A Section Title slide, labeled “Slide 1.0” in DG-9.2.A.

• Section 1.1: Development Project Plan, labeled “Section 1.1” in DG-9.2.A, introduces

the Development Project Plan (DPP). Provide a pointer to the project’s DPP and to the DPP Document Guideline (DG-5.1).

• Section 1.2: Project Objectives, labeled “Section 1.2” in DG-9.2.A. These should be

derived from customer needs and expectations and should have been captured in the project’s Statement of Work (SOW). Match the main bullets of this slide to the main sections of the SOW. One level of sub-bullets can be used at the discretion of the development team. These would add some high-level information typically derived from the explanatory text in each section of the SOW.


DG-9.2 Version: 3.0


Page 17 of 17


• Section 1.3: Project Stakeholders, labeled “Section 1.3” in DG-9.2.A. Identify

relevant stakeholder roles and personnel. Each distinct stakeholder role should be listed as a main bullet. Stakeholder roles are identified in the “Stakeholders” sheet of STAR EPL process asset PG-1.A. Stakeholders should be named when known. There may be more than one name for a stakeholder role. Unspecified stakeholders should be identified by role with a TBD. The ensemble of roles and named personnel constitutes the Integrated Product Team (IPT). Sub-bullets can be used to add a high-level description of the tasks expected for a given stakeholder. The level of detail of these descriptions is at the discretion of the development team, but should be sufficient to give the reviewers a good sense of the IPT. The development team may prefer to present the stakeholder information as a table. See “Section 1.3 – Table Alternative” in DG-9.2.A for an example. A project organization chart is recommended. This chart should include all stakeholders that have been identified in this section. See “Section 1.3 – Option” in DG-9.2.A as an example.

• Section 1.4: Project Timeline, labeled “Section 1.4” in DG-9.2.A, should include a

listing of project milestones and a schedule of tasks leading up to the milestones. Milestones should include the project reviews (with the TRR highlighted) and associated review dates. The STAR EPL standard reviews are shown in Section 1.4 of DG-9.2.A. Refer to the DPP for the project-specific reviews. Milestones may also include key deliveries (e.g. pre-operational code). Show the project plan as an object or objects taken from a Microsoft Project file of the project plan. Use superimposed text boxes to highlight notable accomplishments leading up to TRR. Note the TRR milestone. See Section 1.4 of DG-9.2.A for an example. Use more than one slide if necessary to make the objects visually presentable. For example, the project timeline could be partitioned into the major STAR EPL phases. See “Section 1.4 – Phase Partition” of DG-9.2.A for an example.

• Section 1.5: Changes To Project Plan, labeled “Section 1.5” in DG-9.2.A. Describe

any changes to the project plan – objectives, stakeholders, tasks, schedule and milestones – that have occurred since the CDR. Use multiple slides as necessary for clarity. If there have been no changes, state this.

• Section 1.6: Stakeholder Involvement, labeled “Section 1.6” in DG-9.2.A. Document

the involvement of the stakeholders according to the project plan. Use a bullet for each type of stakeholder. Sub-bullets should describe the involvement in a way that shows the project plan is being followed. Section 1.6 of DG-9.2.A shows examples.


DG-9.2 Version: 3.0


Page 18 of 18


• Section 1.7: TRR Guidelines and Check List, labeled “Section 1.7 Alternative 1” and “Section 1.7 Alternative 2” in DG-9.2.A. This section provides the reviewers with pointers to the TRR Peer Review Guideline (PRG-9) and TRR Check List that they will need to prepare for and dispose of the review. Use Alternative 1 or Alternative 2, depending on whether the standard TRR Check List (CL-9) is to be used (Alternative 1) or a tailored Check List has been documented in the DPP (Alternative 2).

• Section 1.8: TRR Report, labeled “Section 1.8” in DG-9.2.A. This section provides

the reviewers with pointers to the TRR Report Document Guidelines (DG-9.3) that they will need to produce the TRR Report.

• Section 1.9: Review Objectives, labeled “Section 1.8” in DG-9.2.A, should provide a

clear presentation of the Review Objectives. These should include STAR EPL standard objectives for a TRR and may include project-unique objectives at the discretion of the development team. Refer to the DPP to determine this. The review objectives should correspond to the major sections of the review (c.f. Section 3 of this DG). Match the main bullets of this slide to the main sections. One level of sub-bullets can be used at the discretion of the development team. These would add some high-level descriptive information.

4.6. Section 2 – CDR Report

The TRD shall include a CDR Report Section. This section shall include:


• A Section Title slide, labeled “Slide 2.0” in DG-9.2.A. • Section 2.1: Critical Design Review Report (CDRR), labeled “Section 2.1” in DG-

9.2.A. The first bullet should be a pointer to the CDR Report, so that reviewers can obtain access to it. The remainder of the slide should be as shown in Section 2.1 of DG-9.2.A.

• Section 2.2: TRR Entry Criteria, labeled “Section 2.2” in DG-9.2.A. This section lists

the TRR entry criteria. Present as bullets. Use multiple slides as necessary for clarity. The TRR entry criteria should have been established at the CDR and documented in the CDRR.


DG-9.2 Version: 3.0


Page 19 of 19


o Section 2.2 of DG-9.2.A shows the standard STAR EPL entry criteria for the TRR. These should be used if the standard TRR entry criteria, documented in STAR EPL Check List CL-9, are used. If the entry criteria for a particular project have been tailored, revise these slides as necessary to capture the tailored entry criteria. Refer to DPP Appendix C to determine this.

o If applicable, list TRR entry criteria that are non-standard (added or revised from the standard set of entry criteria in STAR EPL Check List CL-9), explain the deviation, provide a rationale, and assess the risk, usually by reference to a risk # to be discussed in Section 6. Follow the instructions on slide 32.

o If applicable, list any standard entry criteria that have been waived for this TRR, provide a rationale, and assess the risk, usually by reference to a risk # to be discussed in Section 6. Follow the instructions in Section 2.2 of DG-9.2.A.

• Section 2.3: TRR Exit Criteria, labeled “Section 2.3” in DG-9.2.A. This section lists

the TRR exit criteria. Present as bullets. Use multiple slides as necessary for clarity. The TRR exit criteria should have been established at the CDR and documented in the CDRR.

o Section 2.3 of DG-9.2.A shows the standard STAR EPL exit criteria for the TRR. These should be used if the standard TRR exit criteria, documented in STAR EPL Check List CL-9, are used. If the exit criteria for a particular project have been tailored, revise these slides as necessary to capture the tailored exit criteria. Refer to DPP Appendix C to determine this.

o If applicable, list TRR exit criteria that are non-standard (added or revised from the standard set of exit criteria in STAR EPL Check List CL-9), explain the deviation, provide a rationale, and assess the risk, usually by reference to a risk # to be discussed in Section 6. Follow the instructions in Section 2.3 of DG-9.2.A.

o If applicable, list any standard exit criteria that have been waived for this TRR, provide a rationale, and assess the risk, usually by reference to a risk # to be discussed in Section 6. Follow the instructions in Section 2.3 of DG-9.2.A.

4.7. Section 3 – Software Architecture

The TRD shall include a Software Architecture Section. Most of the content for this section should be obtained directly from the latest version of the SWA. If a SWA revision is being


DG-9.2 Version: 3.0


Page 20 of 20


prepared for the TRR, consult with the SWA developers to ensure that this section of the TRD is consistent with the latest SWA version. This section shall include:


• A Section Title slide, labeled “Slide 3.0” in DG-9.2.A. • Section 3.1: Software Architecture, labeled “Section 3.1” in DG-9.2.A. This section

provides an overview of the software architecture. o Explain the software architecture concept and function, as shown in Section

3.1 of DG-9.2.A. o Illustrate the software architecture layers, as shown in the “Section 3.1 –

Figure 1” slide in DG-9.2.A.

• Section 3.2: Context-Layer, labeled “Section 3.2” in DG-9.2.A. o Explain the concept of the Context-Layer, defining the interfaces between the

software system and external sources and sinks, as shown in Section 3.2 of DG-9.2.A.

o Illustrate the external interfaces in a context diagram (“Section 3.2 – Figure 1” of DG-9.2.A shows an example). The context diagram slide may be obtained from CDD Section 6, unless there have been changes since CDR; in that case, obtain the updated diagram from the revised SWA.

o List all external inputs and outputs to and from the software system. This list should be documented in the SWA, which should have been reviewed and approved at CDR. If the list has been updated since CDR, note the changes since CDR. Highlight the changes or note that there have been no changes.

o List all external inputs and outputs to and from the software system in a table if that adds clarity. A table may have been shown at the CDR. If so, adopt this table and revise it as necessary to capture changes since the CDR. If a revised table is shown, highlight the changes since CDR.

o Report the status of the external interfaces in one of two ways. If there are no changes since CDR and no open actions on external interfaces, note that all external interfaces have been reviewed and approved. If there are changes since CDR, provide the rationale for these changes and a pointer to a revised SWA that demonstrates the interfaces are low risk and maintainable. If


DG-9.2 Version: 3.0


Page 21 of 21


applicable, list the open actions on external interfaces, noting that these will be addressed in a later section of the TRD.

• Section 3.3: System-Layer, labeled “Section 3.3” in DG-9.2.A.

o This section expands upon the Context-Layer data flow of Section 3.2, showing the next (first) layer of decomposition to the System-Layer. At this layer, the testable software units appear. Section 3.3 should explain this.

o Include a System-Layer data flow diagram (“Section 3.3 – Figure 1” of DG-9.2.A shows an example). This diagram should have been presented at the CDR. Adopt the figure from the CDR presentation, and revise it as needed to capture any changes since the CDR. The figure should be consistent with the latest version of the SWA.

o Show the System-Layer data flows as a table if that adds clarity (slide 54 shows an example). A table may have been shown at the CDR. If so, adopt this table and revise it as necessary to capture changes since the CDR. If a revised table is shown, highlight the changes since CDR. The table should be consistent with the latest version of the SWA.

o Report the status of the System-Layer architecture in one of two ways. If there are no changes since CDR and no open actions, note that all System-Layer components have been reviewed and approved. If there are changes since CDR, provide the rationale for these changes and a pointer to a revised SWA that documents the changes. If applicable, list the open actions on the System-Layer architecture, noting that these will be addressed in a later section of the TRD.


DG-9.2 Version: 3.0


Page 22 of 22


4.8. Section 4 – Unit Test Readiness

The TRD shall include sections that demonstrate the readiness of each software unit for its unit test. Each software unit shall have its own section, beginning with Section 4. Each section shall include:


• A Section Title slide, labeled “Slide 4.0” in DG-9.2.A. • Section 4.1: Purpose and Function, “Section 4.1” in DG-9.2.A. This section explains

the purpose of the unit and its function in the PPS. This explanation should be consistent with, and can be obtained from, the unit DDD or the UTP.

• Section 4.2: Process Flow, labeled “Section 4.2” in DG-9.2.A. This section shows the

data flows between the major sub-units (the Unit-Layer, process flow, also known as Layer-2), as documented in the SWA and UTP. “Section 4.2 – Figure 1” of DG-9.2.A shows an example. Adopt the diagram from Section 6 of the CDD, if the data flows are unchanged since CDR, or revise the diagram as necessary. The diagram should be found in the latest version of the SWA (nominally v2r2).

• Section 4.3: Test Items, labeled “Section 4.3” in DG-9.2.A. List all unit components

that have been selected for testing, as documented in Section 3.3 of the UTP. These items should be part of the system architecture as documented in the SWA and should be included in the VVP. Typically, they are sub-processes of the unit’s process flow (e.g. Layer-2 elements, Layer-3 elements, etc.). Test items should be numbered as they are numbered in Section 3.3 of UTP v1r0. Give a brief description of each test item. For pre-operational code items, note the code language and demonstrate that the appropriate coding standards have been followed. Show examples of code to support this demonstration.

• Section 4.4: Requirements Trace, labeled “Section 4.4” in DG-9.2.A. This section

traces the test items to the requirements. List the requirements allocated to each test item, consistent with the requirements allocation documented in the RAD and as documented in Section 3.4 of the UTP, following the instructions in Section 4.4 of DG-9.2.A. If there has been a change to the requirements allocation since CDR, list


DG-9.2 Version: 3.0


Page 23 of 23


each requirements allocation change, following the instruction in Section 4.4 of DG-9.2.A.

• Section 4.5: Test Data Description, labeled “Section 4.5” in DG-9.2.A.

o List all data files that will be used as input files for the unit test, as documented in Section 3.5 of the UTP. “Test data” includes sensor data (real, proxy, or simulated), ancillary data, control files, parameter files, and look up tables. It is recommended that these be listed in a table. “Section 4.5 – Table 1” of DG-9.2.A provides an example.

o Describe each input data file in sufficient detail for a reviewer to be able to confirm that its contents and format matches the description of the appropriate input file documented in Section 4 of the unit’s DDD. Follow the instructions in Section 4.5 of DG-9.2.A.

o List all “truth” data sets that will be used to assess the performance of the unit test. Follow the instructions in Section 4.5 of DG-9.2.A.

• Section 4.6: Test Environment, labeled “Section 4.6” in DG-9.2.A. Describe the

environment in which the unit tests will be performed, consistent with the VVP and UTP Section 3.6, and demonstrate that the planned test environment complies with the project’s test environment requirements, as documented in the RAD. This demonstration should be documented in UTP Section 3.6. Follow the instructions in Section 4.6 of DG-9.2.A.

• Section 4.7: Test Configuration, labeled “Section 4.7” in DG-9.2.A. Identify all

configuration items that will be used in the unit test, including code modules, test data sets, utilities, libraries, etc. Introduce the PBR and provide a pointer to the PBR. Follow the instructions in Section 4.7 of DG-9.2.A..

• Section 4.8: Test Methods, labeled “Section 4.8” in DG-9.2.A. Describe the method

or methods that will be used to test each test item, as documented in Section 3.8 of the UTP, and demonstrate that the methods selected for verification of a given item will address the requirements to be verified for that item, as documented in the VVP. Follow the instructions in Section 4.8 of DG-9.2.A.

• Section 4.9: Test Sequence, labeled Section 4.9” in DG-9.2.A. Describe the planned

sequence of test actions in sufficient detail that a reviewer can confirm that all test items are exercised, all test data is utilized, and all planned test methods are used as planned. Follow the instructions in Section 4.9 of DG-9.2.A.


DG-9.2 Version: 3.0


Page 24 of 24


• Section 4.10: Unit Test Risks, labeled “Section 4.10” in DG-9.2.A. Identify and

evaluate risks to successful implementation of the test plan for this unit, as documented in Section 3.10 of the UTP. Follow the instructions in Section 4.10 of DG-9.2.A.

4.9. Section 5 – Unit Test Readiness

Section 5 of the TRD shall present the test readiness of Unit 2. Sections 5.1 – 5.10 shall repeat the Unit 1 presentation format of Sections 4.1 – 4.10, substituting material appropriate for Unit 2, as indicated on the slide labeled “Sections 5.1 – 5.10” in DG-9.2.A.

4.10. Section 6 – Risks and Actions

The TRD shall include a Risks Section. This section shall include:


• A Section Title slide, labeled “Slide 6.0” in DG-9.2.A. • Section 6.1: CDR Risks and Actions, labeled “Section 6.1” in DG-9.2.A.

o A section introduction slide should note the number of risks that were identified at the CDR and that were identified after the CDR, as shown in Section 6.1 of DG-9.2.A.

o Report the status of the first risk identified at the CDR. Use as many slides as necessary for a clear presentation of the status of each risk.

o Report the status of each completed action that is associated with the risk, as shown in Section 6.1 of DG-9.2.A.

o Report the status of each open action that is associated with the risk, as shown in Section 6.1 of DG-9.2.A.

o Repeat for each additional risk, as shown in Section 6.1 of DG-9.2.A.

• Section 6.2: New Risks and Actions, labeled “Section 6.2” in DG-9.2.A.


DG-9.2 Version: 3.0


Page 25 of 25


o Report the status of each risk that has been identified since the CDR. Use as many slides as necessary for a clear presentation of the status of each risk.

o Report the status of each completed action that is associated with the risk, as shown in Section 6.2 of DG-9.2.A.

o Report the status of each open action that is associated with the risk, as shown in Section 6.2 of DG-9.2.A.

o Repeat for each additional risk, as shown in Section 6.2 of DG-9.2.A. • Section 6.3: Risk Summary, labeled “Section 16.3” in DG-9.2.A.

o Present a bulleted list of the risk statements for the risks that can be closed. Risks can be closed when all associated actions are closed or withdrawn. For each risk, list the associated actions that can be closed or withdrawn. Each of these should have been presented in Sections 6.1 or 6.2 as a completed or withdrawn action. Use multiple slides as necessary for clarity.

o Present a bulleted list of the risk statements for the risks that are still open. For each risk, list the actions that must be closed to reduce the risk to an acceptable level, with closure plans and estimated closure dates.

4.11. Section 7 – Summary and Conclusions

The TRD shall include a Summary and Conclusions Section. This section shall include:


• A Section Title slide, labeled “Slide 7.0” in DG-9.2.A. • Section 7.1: Review Objectives Status, labeled “Section 7.1” in DG-9.2.A. This

section explains how each review objective has been addressed. Follow the instructions in Section 7.1 of DG-9.2.A.

• Section 7.2: Issues, Actions and Risks, labeled “Section 7.2” in DG-9.2.A. List

important issues, actions and risks that require attention. Use multiple slides as necessary for clarity. Use a major bullet for each item, with sub-bullets to note conclusions for that item.


DG-9.2 Version: 3.0


Page 26 of 26


• Section 7.3: Next Steps, labeled “Section 7.3” in DG-9.2.A. List recommendations for next steps after the TRR. Follow the instructions in Section 7.3 of DG-9.2.A.

• Section 7.4: Open Discussion, labeled “Section 7.4” in DG-9.2.A. Announce that the

review is open for free discussion. Note: If you have prepared and conducted the review in accordance with standards and if the reviewers have prepared for the review in accordance with standards, there should be no need for additional discussion.


DG-9.2 Version: 3.0


Page 27 of 27


APPENDIX A – TEMPLATE FILE The slide templates that are referenced in this DG are available in the Microsoft PowerPoint file “STAR_DG-9.2.A_TRD_v3r0.ppt”. This file will be available to authorized users in the STAR EPL PAR. ______________________________________________________________________________ END OF DOCUMENT

LIST OF ACRONYMS INTRODUCTION Objective The Test Readiness Document Background Benefits Overview

REFERENCE DOCUMENTS STANDARD SECTIONS SECTION GUIDELINES Slide Master Title Slide Review Outline Slide Review Agenda Slide Section 1 – Introduction Section 2 – CDR Report Section 3 – Software Architecture Section 4 – Unit Test Readiness Section 5 – Unit Test Readiness Section 6 – Risks and Actions Section 7 – Summary and Conclusions

APPENDIX A – TEMPLATE FILE

Documents

NOAA NESDIS CENTER for SATELLITE APPLICATIONS and … › ... › STAR_DG-09.2.0_TRD_v3r0.pdf · 4.8. Section 4 – Unit Test Readiness ..... 22 4.9. Section 5