| NODIS Library | Program Formulation(7000s) | Search |

NASA Ball NASA
Procedural
Requirements
NPR 7120.8
Effective Date: February 05, 2008
Expiration Date: February 05, 2018
COMPLIANCE IS MANDATORY
Printable Format (PDF)

(NASA Only)

Subject: NASA Research and Technology Program and Project Management Requirements (w/change 3 dated 04/18/13)

Responsible Office: Office of the Chief Engineer


| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | AppendixL | ALL |

Chapter 4. Technology Development Project Requirements

4.1 Overview

4.1.1 Technology Development Project

4.1.1.1 A TD Project matures a particular technology or set of related technologies to the point where it is ready for use by a customer/beneficiary. A customer/beneficiary is usually well defined for a TD Project. Customers/beneficiaries are the intended user of the technology being developed and are involved throughout the development process. Typically, a customer/beneficiary is a space flight project or the aeronautics community.Customers/beneficiaries may also be other NASA-focused technology projects where further development occurs to meet a specific mission requirement or industrial partners that NASA supplies with technology to maintain a national aerospace capability.

4.1.1.2 New technologies often emerge from R&T where fundamental scientific principles are investigated and concepts for their application are formulated. The early stages of technology development are usually performed in the laboratory; later stages may involve field tests or flight demonstration experiments to validate the technology in relevant environments.

4.1.1.3 The TD project lead shall support reviews required by the governing PMC (section 2.3.2), CMC (section 2.3.3), Strategic Acquisition Planning (section 2.2.3), and Special Independent Assessments (sections 3.4.3 and 4.5.2.1).

4.1.1.4 General management requirements applicable to all projects including TD projects, within program, such as the Dissenting Opinions process (section 3.6) and Technical Authority process (section 3.7), are found in Chapter 3.

4.1.1.5 For TD projects, the governing PMC and the DA for each KDP shall be as defined in Table 2-2.

4.1.2 Description of TD Project Life Cycle

4.1.2.1 NASA's four-part process for managing programs and projects described in section 1.2.1 consists of: Formulation, Approval, Implementation, and Evaluation. The TD Project shall follow the life cycle in Figure 2-1, including the minimum set of reviews and gate products specified in this NPR.

4.1.2.2 During Formulation, technology needs are derived from mission concept studies, various technical approaches for meeting the technology needs are identified, technical performance goals called KPPs are established, and a TD Project Plan is developed.

4.1.2.3 Prior to Approval, a Formulation Review is conducted to ensure that the TD Project objectives are aligned with the known or potential mission needs and that the TD Project is well planned to meet the objectives.

4.1.2.4 During Implementation, the TD project matures the technology, and progress toward the KPPs is evaluated in periodic status reviews. At these reviews, reviewers may recommend to the DA that the TD Project be continued, revised, or discontinued.

4.1.2.5 Throughout the TD Project life cycle, an evaluation process is used to set priorities among competing alternatives and to assess progress relative to a baseline plan. Evaluation makes use of systems analysis, KPPs, TRLs (refer to NPR 7123.1), and other tools to evaluate the TD Project (see section 4.7.1).

4.2 Project Pre-Formulation

4.2.1 The Project DA is responsible for initiating a new TD Project (see figure 2-1) by entering into a Projects Pre-Formulation phase. The Project DA is responsible for ensuring the start of a new TD Project is in line with the Agency's vision and mission, as defined by NPD 1001.0, NASA Strategic Plan. Also, the Project DA is responsible for ensuring the start of a new TD Project is aligned with critical technology needs identified by the MD or MSO.

4.2.2 The program lead, in coordination with the MDAA or MSD, shall assign a TD project lead to manage the effort.

4.2.2.1 If a TD project lead resides at a Center, the program lead shall coordinate the assignment of the TD project pead with the Center Director.

4.2.2.2 The program lead, in coordination with the MDAA or MSD, should provide, in writing, a scope of the project to the TD project lead.

4.2.3 The program lead shall manage any project formulation activities required while in the Programs Formulation Phase. The program lead, in coordination with the MDAA or MSD, may allocate program funds to perform Pre-Formulation tasks associated with a potential project. These funds may be allocated by the program lead to specific Centers, managed internally, or used to fund external studies associated with a potential project.

4.2.4 The TD project lead shall create an R&T Project FAD, using the template provided in Appendix G. The R&T Project FAD is approved by the Project DA with concurrence by the program lead.

4.2.5 As a minimum, an R&T Project FAD shall:

a. Contain a statement of purpose for the proposed project and define its relationship to the Program's strategic goals and objectives.

b. Establish the scope of work to be accomplished.

c. Identify the TD project lead.

d. Identify the management process for the project.

e. Provide initial constraints, including resources, schedule and project participants within and external to NASA, including international partnerships.

f. Define the approach, resources, and reviews required to conduct project Formulation.

g. Identify optional KDP B if required by the DA during Formulation or identify that optional KDP B is not needed.

4.2.6 Approval of the R&T Project FAD by the Project DA is KDP A, which initiates the Project's movement from Pre-Formulation into the Formulation phase of the life cycle.

4.3 Project Formulation

4.3.1 Overview

4.3.1.1 The Formulation of a TD Project involves defining the customers/beneficiaries, identifying technology needs, evaluating alternatives, establishing KPPs, and planning project implementation.

4.3.1.2 During Formulation, the TD project lead should develop a preliminary WBS, project schedule, and the allocation of resources to perform the project (see section 4.5.1.1 for later life- cycle requirements). The project's preliminary WBS and associated WBS should be consistent with Appendix K. In coordination with OCFO, the TD project lead should identify and establish a WBS Element (level 3 or lower) specifically for capital assets, when purchase of capital assets is required. In coordination with the OCFO, the TD project lead shall complete the Alternative Future Use (AFU) Questionnaire (Form NF 1739) if any NASA-owned equipment purchased on the project has an acquisition value of $100,000 or greater per item, has an estimated useful life of 2 years or more, and has a planned use on another project.

4.3.1.3 An optional KDP (KDP B) during Formulation may be added at the discretion of the Project DA (see section 4.5.2).

4.3.2 Customer/Beneficiary Definition

4.3.2.1 The project lead shall identify the customers/beneficiaries who will benefit from the TD Project. The customers/beneficiaries may include space flight projects, another R&T program, another Government agency, the aeronautics community, or the U.S. aerospace industry.

4.3.2.2 The TD project lead shall define specific points of contacts (e.g., working groups, advisory committees, integrated product teams, technology infusion liaisons) that are capable of representing the customer/beneficiary;s requirements (e.g., technology needs, technology prioritization, key performance parameters, and technology maturity) for technology development.

4.3.3 Identification of Technology Needs

4.3.3.1 The TD project lead shall ensure that credible technology needs are derived from sources such as the customer/beneficiary;s mission concept studies or design reference missions (DRMs), technology roadmaps and associated system analysis, or technology gap analysis.

4.3.3.2 The TD project lead shall ensure the customer/beneficiary's involved in these assessments and the results should be consistent with the customer/beneficiary's technology infusion plan.

4.3.4 Systems Analysis and Technology Prioritization

4.3.4.1 The TD project lead shall ensure that appropriate analyses and studies are conducted to justify technology selections. Techniques such as Alignment Matrices, Return on Investment vs. Risk Matrices, or Technology S-curve Maps can be used to determine the best mix of technologies that will balance the project's risk posture. Formal systems analysis should be performed, when practical, to support the results. These analyses should include investment priorities for developing alternative technologies to maximize the probability of success and to enable rational allocation of resources in the event of budget fluctuation.

4.3.4.2 The TD project lead shall perform an assessment of related technology development activities (e.g., Gap Analysis, section 4.7.2.1b) in other NASA programs, other Government agencies, and the commercial sector to eliminate unnecessary duplication of effort.

4.3.4.3 Formulation Review

a. Prior to KDP C, a Formulation Review shall be conducted. The Formulation Review has both an internal and external component. The internal component is a project review to ensure the project is ready to proceed to KDP C. The external component is an independent assessment that includes the customer/beneficiary and may involve external advisory groups such as the National Research Council (NRC). The Formulation Review will assess the project's alignment with the customer/beneficiary's needs and the adequacy of the TD Project Plan to meet the specified objectives. The selecting official identified in Table 2-2 assigns the IA to be performed by one or more organizations. The selecting official for the Formulation Review team (see Table 2-2) is responsible for the development and approval of the Terms of Reference (ToR) for the Formulation Review. Conflicts during ToR development should be resolved in accordance with section 3.6. The TD project lead will revise the TD Project Plan to properly disposition any recommendations resulting from the Formulation Review.

b. For TD projects that are or are themselves or are large scale ($250M) fully integrated Technology Development system (e.g. X-33), the selecting official for the independent assessment team will obtain approval for the Formulation Review team selection (external component) and ToR development from the Chief Engineer and the Associate Administrator for PA&E. The Associate Administrator for PA&E will ensure that the IA team membership and process are independent and objective. The Chief Engineer will ensure that the IA team membership is adequate to assess the project technically and that the IA membership and process is consistent with the Technical Authority process and the governance model.

4.3.4.4 At the Formulation Review, an assessment of related technology development activities (e.g., Gap Analysis) is reviewed. This assessment should be documented in the Project Plan.

4.3.5 Key Performance Parameters

4.3.5.1 To increase the likelihood of successful technology infusion, the TD project lead shall define and document KPPs that are important to the customers/beneficiaries. KPPs consist of measurable engineering parameters that would be readily understood and used by engineers concerned with the ultimate application of the technology. For each KPP, both a goal and a threshold will be specified. The goal is a performance level that the project team is striving for, and the threshold is the minimum performance level that users agree is acceptable for the end item deliverable. Typically, the threshold KPP values are set beyond the current state-of-the art to warrant investment in the project. KPPs include information that enables an assessment of the advancement of the maturity of the technology throughout the development process. The definition of a KPP includes defining the appropriate environment and the component, subsystem, or system within which the KPP measurements are to be made.

4.3.5.2 When the TD Project contains multiple tasks and deliverables, the TD project lead shall identify KPPs for each task or deliverable.

4.3.5.3 The TD project lead shall ensure KPPs are reviewed annually by the customer/beneficiary to verify that they are still aligned with mission requirements.

4.3.5.4 The Project DA is the DA for KPPs, formally approving them by approving the TD Project Plan (Appendix H). Modification of KPPs should be through updates to the TD Project Plan.

4.3.6 TD Project Plan

4.3.6.1 During Pre-Formulation or Formulation, the Project DA may request a preliminary TD project plan from the TD project lead to document an agreement between project and program regarding the objectives and approach prior to full-project approval.

4.3.6.2 The TD Project Plan is an agreement between the Project DA, the program lead, and the TD project lead that details how the project will be managed. The TD project lead shall create a TD Project Plan, using the template provided in Appendix H. The TD Project Plan is signed by the TD project lead and approved by the Project DA with concurrence by the Program Lead. The TD Project Plan is used by the governing PMC in the review process to determine if the project is fulfilling its agreement.

4.3.6.3 As a minimum, a TD Project Plan shall:

a. State the specific project objectives, performance goals, and their relationship to the program objectives and goals.

b. Present a technical description of the project.

c. Document the project requirements/objectives, including KPPs.

d. Document an assessment (Gap Analysis) of related technology development activities in other NASA programs, other Government agencies, and the commercial sector to eliminate unnecessary duplication of effort.

e. Identify the TD project lead.

f. Define the project's management approach, resource requirements (including NASA personnel, facilities, and aircraft uses), schedule and work breakdown structure.

g. Describe the project's strategy for technology transition.

h. Summarize the risk management approach to be used for the project.

i. Define the specific reviews that will be conducted during the performance of the project.

j. Document the project's approach to implementing IT security requirements in accordance with NPR 2810.1, Security of Information Technology.

k. Identify any optional KDPs (KDP B, D, and E) required by the DA.

4.3.6.4 If warranted by changes in the stated commitments or requirements, the TD project lead shall update the TD Project Plan. Each revised TD Project Plan is reviewed and approved using the same process as the original.

4.3.6.5 The TD project lead shall ensure the TD Project Plan and R&T Program Plan are consistent. If changes are required, the approval process for the applicable document(s) will be followed.

4.3.6.6 If the TD Project resides at a Center, the TD project lead shall add the Center Director (or designee) responsible for committing workforce and facilities as a concurrence signatory to the TD Project Plan. Other concurrence signatory such as the customer(s)/beneficiary(ies) may be added, if applicable.

4.3.6.7 For TD projects proposing the construction of new or modification to existing NASA-owned facilities within normal Construction of Facilities (CoF) funding limits (see NPD 7330.1, Approval Authorities for Facility Projects), the TD project lead shall complete a preliminary business case analysis in accordance with NPD 8820.2, Design and Construction of Facilities and NPR 8820.2, Facility Project Requirements. A business case guide can be located at http://www.hq.nasa.gov/office/codej/codejx/codejx.html.

4.3.6.8 For TD projects proposing acquisition of new aircraft, the TD project lead shall plan and perform these acquisitions in accordance with NPR 7900.3, Aircraft Operations Management Manual. The term "aircraft" includes both piloted and unmanned aerial vehicles.

4.3.6.9 The TD project lead shall ensure that proposals and plans for subordinate activities/tasks include documentation of environmental compliance and permit considerations and NEPA evaluation.

4.3.6.10 If a TD project contains elements that include hardware used for flight (piloted or unpiloted), flight control software, wind tunnel testing, or systems that could result in potential harm to personnel or property, the TD project lead shall ensure a Safety and Mission Assurance (SMA) plan is developed. The plan identifies and documents project-element-specific SMA roles, responsibilities, and relationships with appropriate HQ and/or Center- SMA organizations. The plan should reflect the SMA role in areas such as: procurement, management, design and engineering, design verification and test, software design, software verification and test, manufacturing, manufacturing verification and test, operations, and preflight verification and test. In many cases, these plans are already established by Center and/or facility procedures for operations such as wind tunnel tests and flight testing and do not need to be developed by the project. The TD Project Plan should be used to document when project elements or other entities will need to develop unique SMA plans. However, this plan should still be a stand-alone document.

4.3.6.11 If a TD Project contains elements that include hardware used for flight (piloted or unpiloted), flight control software, wind tunnel testing, or systems that could result in potential harm to personnel or property, the TD project lead shall ensure a risk management plan is developed. In many cases, these plans are already established by Center and/or facility procedures for operations such as wind tunnel tests and flight testing and do not need to be developed by the project.

4.3.6.12 If a risk management plan does not already exist for a project element containing hardware used for flight (piloted or unpiloted), flight control software, wind tunnel testing, or systems that could result in potential harm to personnel or property, the TD project lead shall ensure a stand-alone risk management plan is developed that includes the content shown in NPR 8000.4, Agency Risk Management Procedural Requirements. The TD Project Plan should be used to document when risk plans need to be developed for project elements because existing plans are not sufficient or when no plan exists. However, these plans should still be stand-alone documents.

4.4 Project Approval

4.4.1 The Project DA has the authority (see Table 2-2) to move a TD Project from the Formulation phase to the Implementation phase (KDP C). This decision is in writing in the form of the Project DA approval of the TD Project Plan (see Appendix H). The Project DA is responsible for ensuring the TD Project is in line with the Agency's vision and mission, as defined by NPD 1001.0, NASA Strategic Plan.

4.4.2 KDP C occurs when the Project DA approves the revised Project Plan, and authorizes NASA HQ to allocate the funding required for project execution to the NASA Centers.

4.5 Project Implementation

4.5.1 Project Management Principles

4.5.1.1 Use of accepted project management principles will increase the likelihood that the TD Project will be successful in achieving its technical objectives within cost and schedule constraints. At a minimum, the TD project lead shall establish a WBS, in accordance with Appendix K, a project schedule with milestones for each element in the WBS, and an allocation of the projects available resources necessary to achieve each milestone (see section 4.3.1.2 for preliminary requirements). The milestones should be chosen at intervals sufficient to demonstrate steady progress toward achieving the overall KPPs for the project.

4.5.1.2 MD or MSD policy may require the use of more rigorous project management principles such as Earned Value Management (EVM).

4.5.1.3 The TD project lead shall track progress against a baseline plan. The WBS, the project schedule, and the allocation of resources to milestones constitute the baseline plan for assessing technical, schedule, and cost performance.

4.5.1.4 For all development projects or single contracts exceeding $250 million life-cycle cost, the TD project lead shall provide immediate written notice and a recovery plan to the program lead and MDAA or MSD, if the implementation costs of the project are estimated to exceed the baseline cost by 15 percent or more or if a schedule milestone is estimated to be delayed 6 months or more.

4.5.2 Independent Assessments and Optional KDPs

4.5.2.1 The NASA AA, MDAA, MSD, AA for PA&E, or program lead may authorize special independent assessments at any time in a TD Projects life cycle. A ToR should be developed for each special independent assessment. The ToR should be developed by the individual(s) who authorize the special independent assessment in coordination with the MDAA or MSOD (or designee).

4.5.2.2 The Project DA shall determine if the optional KDP (KDP B) is required during Formulation (see section 4.3.1.3). This optional KDP is added at the Project DAs discretion and identified in the Project FAD. If the KDP B is required, the Project DA should determine the gate products required prior to this optional KDP.

4.5.2.3 The Project DA shall determine if optional KDPs (KDP D and E) are required during Implementation. These optional KDPs are added at the Project DAs discretion and identified in the Project FAD. If these optional KDPs are required, the Project DA should determine the gate products required prior to these optional KDPs.

4.5.2.4 IAs occur as part of the TD Project life cycle. IAs during Implementation are performed periodically and should be documented in the Project Plan. The selecting official for the independent assessment team (see Table 2-2) is responsible for the development and approval of the ToR for the IA. For TD projects that are themselves or are a part of a large scale (>$250M) Technology Development system (e.g., X-33), the selecting official for the independent assessment team will obtain approval for the IA team selection and ToR development from the Chief Engineer and the Associate Administrator for PA&E. The Associate Administrator for PA&E will ensure that the IA team membership and process are independent and objective. The Chief Engineer will ensure that the IA team membership is adequate to assess the project technically and that the IA membership and process is consistent with the Technical Authority process and the governance model.

4.5.3 Status Reviews

4.5.3.1 The TD project lead shall conduct TD Project status reviews annually to assess both progress towards the KPPs and the maturity of the technology. In addition, status reviews may be called by the MDAA, MSOD, or program lead at any time to determine the need to modify or end the project. The status reviews are utilized by the program lead to recommend whether the TD Project should be continued for another year, re-directed, modified, or discontinued. Status reviews require customer/beneficiary involvement (i.e., status review's external component) and can help ensure mature technologies are utilized when available. IAs per section 4.5.2.4 may also be conducted in parallel to status reviews and act as the status review's external component. Status reviews may also include members from the Formulation Review panel. The program lead, in consultation with the customer/beneficiary or his/her representative(s), makes a recommendation on TD Project continuation to the MDAA or MSOD. KDP F occurs when the Project DA decides to close a TD Project or transition the technology to a different project.

4.6 Project Transition/Closure

4.6.1 Technology Transition/Closure

4.6.1.1 In the Transition/Closure phase, technologies that are successful in achieving the required level of maturity are transitioned to a customer/beneficiary for further development, are used in system designs, or are thoroughly documented for resumption of development at a later date. Transition occurs when the customer/beneficiary assumes management and financial responsibility for technology development. The transition is not tied to a specific TRL or level of maturity. If the transition customer/beneficiary is a Space Flight Systems project, further technology development or space flight integration is governed by NPR 7120.5, NASA Space Flight Program and Project Management Requirements. In this phase, the investigations may also be discontinued and a method for documenting and archiving data is implemented.

4.6.2 Closeout Review

4.6.2.1 At the conclusion of each TD Project, a closeout review of the project's accomplishments, including an independent assessment of the final TRL and other maturity measures is performed. A final report is required for the Closeout Review. The TD project lead shall document lessons learned, in accordance with NPR 7120.6, Lessons Learned Process.

4.6.3 Data Archiving and Publication

4.6.3.1 At the conclusion of the TD Project, the TD project lead shall ensure that sufficient data is archived so that future users can assess the technology maturity (e.g., TRL) and incorporate the technology into system designs. These data include the final report from the Closeout Review, engineering drawings, specifications, test reports, and any other documentation of project activities and results necessary for future researchers to understand the work performed and the results that were achieved.

4.6.3.2 All documentary information, regardless of format, made or received in the course of conducting NASA R&T Projects are Federal records and shall be maintained, safeguarded, and dispositioned in accordance with the guidelines of NPR 1441.1, NASA Records Retention Schedules.

4.6.3.3 Except when the information is classified or subject to International Traffic in Arms Regulations (ITAR) restrictions, the TD project lead should ensure publication of at least one peer-reviewed technical paper or the posting of a final report external to NASA to ensure wide dissemination of technology information.

4.7 Evaluation

4.7.1 Technology Maturity Assessment

4.7.1.1 Accurate assessment of technology maturity is critical to technology advancement and its subsequent incorporation into operational products.

4.7.1.2 The TD project lead shall ensure TRLs and/or other measures of technology maturity that are important to the customer/beneficiary are used in conjunction with KPPs to assess maturity throughout the project life cycle. When a TD Project uses a measure of maturity other than TRLs, the measurement system should map back to TRLs. TRLs are defined in NPR 7123.1.

4.7.1.3 An independent group should validate the current state of maturity. The maturity assessment should involve or be reviewed by the customer(s)/beneficiary(ies) or their representatives. The initial maturity assessment is done in the Formulation phase and updated at the project status reviews. At the conclusion of the TD Project, an independent assessment of the final TRL is performed. The program lead shall assign the independent group responsible for the Technology Maturity Assessment.

4.7.1.4 TRLs establish the baseline maturity of a technology at a given time. Moving to a higher-level of maturity (higher TRL) requires the assessment of an entire range of capabilities for design, analysis, manufacture, and test. These additional assessments may be embodied in other measures of technology maturity such as a Technology Maturity Index (TMI) or an Advancement Degree of Difficulty (AD2), which are described in the NASA Systems Engineering Handbook (SEHB).

4.7.2 Assessment Process

4.7.2.1 The following steps outline the process for assessing technology maturity and identify activities that should be accomplished on the part of the project.

a. Clearly define all terminology used in the TRL descriptions to be used throughout the life of the project.

b. Provide a formal Gap Analysis (see section 4.3.4.2) of technology needs supporting project content and identify the process for periodic project assessment, including the termination or transition of technologies out of the project and introduction of new technologies into the project.

c. Provide a formal assessment of the TRL for each new technology incorporated into the TD Project, and annually assess progress toward defined TRL goals. The assessment should occur at the system, subsystem, and component levels, as described by the TD Project's WBS.

d. The "weakest link" concept will be used in determining overall technology maturity wherein the TRL of the system is determined by the subsystem having the lowest TRL in the system, which in turn is determined by the component having the lowest TRL in the subsystem.

e. The depth of this assessment varies greatly according to the state of the project, e.g., at the concept level, only the basic building blocks are known and the major challenges identifiable. However, as the technology matures, the WBS becomes more defined and the assessment is required to go into greater detail.

f. On the basis of the assessment, prepare a list of Critical Technology Elements that are absolutely essential in meeting overall technology requirements and that have substantial risk, cost, and/or schedule associated with their development.

g. The assessment of heritage elements should consider the intended application and operational environment compared to how they were previously used.

h. Following the maturity assessment and the identification of critical technology elements, perform an Advancement Degree of Difficulty assessment of what is required to advance the technology to the desired TRL. This is done in conjunction with the WBS and is used as the basis for the technology roadmap and cost.

i. Prepare a roadmap for each TD Project that addresses the cost, schedule, and risk associated with advancing each element to the point necessary to meet requirements in a timely manner. Identify alternate paths, decision gates, off-ramps, fallback positions, and quantifiable milestones with appropriate schedules. The roadmap outlines the overall strategy for progressing toward the KPPs, and shows how interim performance milestones will be verified through test.

j. The TD Project will be assessed on an annual basis through the aggregate assessment of the individual technologies and their progress toward the stated TRL goal.

4.8 Requirements Flow Down for Project Elements

4.8.1 Portions or elements of TD projects may be accomplished at different Centers. The TD project lead shall flow down requirements for this work sufficiently to ensure requirements are met at the TD Project level.



| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | AppendixL | ALL |
 
| NODIS Library | Program Formulation(7000s) | Search |

DISTRIBUTION:
NODIS


This Document Is Uncontrolled When Printed.
Check the NASA Online Directives Information System (NODIS) Library
to Verify that this is the correct version before use: http://nodis3.gsfc.nasa.gov