NASA Procedures and Guidelines
This Document is Obsolete and Is No Longer Used. Check the NODIS Library to access the current version: http://nodis3.gsfc.nasa.gov
NPR 7120.9 Eff. Date: March 11, 2011 Cancellation Date: February 04, 2016	NASA Product Data and Life-Cycle Management (PDLM) for Flight Programs and Projects
| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppendixD | ALL |

Chapter 3. PDLM Architecture and Plan Requirements

Note: The program and project requirements for PDLM are to establish four types of architectures:

a. Security Architecture.

b. Data Architecture.

c. Information Support System Architecture.

d. Process Architecture.

3.1 Security Architecture

Note: The Security Architecture is a collection of components or layers of security that must be considered to provide information assurance. These include policy and security management, application security, data security, platform security, network and perimeter security, physical security, and user identity security. It provides the program/project with reliability, quality, integrity, availability, and confidentiality of data and systems in compliance with Federal and Agency regulations and requirements.

3.1.1 The Agency CIO shall develop a plan forward/roadmap with engineering and program management as stakeholders to enable the necessary interoperability between existing and future NASA IT systems and approved interfaces to provide a secure, readily accessible environment such that required collaborative PDLM capabilities can be established for authorized personnel.

3.1.2 The Agency CIO shall document a minimal set of security capabilities with institutional and Mission Directorate PDLM capability providers to support program and project needs while meeting relevant internal and external security standards.

3.2 Data Architecture

Note: A Data Architecture describes how data is processed, stored, and utilized in a given system or product definition. It provides criteria for data processing operations that make it possible to design data flows and also control the flow and association of data in the system. A Data Architecture should provide descriptions of data in storage and data in motion; descriptions of data stores and their interfaces; data groups and data items; and mappings of those data artifacts to data qualities, applications, and locations. The Data Architecture provides a program/project team with a framework from which to map program and project data. If programs and projects do not have the Data Architecture from the start, the program/project data becomes disorganized quickly and is nearly impossible to electronically integrate or discover as the level of data increases over time.

3.2.1 In establishing the Data Architecture, the program manager shall:

3.2.1.1 Ensure that the Data Architecture is documented, highlighting information/data flow through the system of systems, listing interoperability points.

3.2.1.2 Ensure that the Data Architecture provides identification, management, interoperability, and integration of information across business or organizational elements needed to support program PDLM goals.

3.2.1.3 Ensure that the Data Architecture provides data categorization (e.g., quality, context, access, level of data control, ownership, stewardship, and longevity) and metadata creation and management.

3.2.1.4 Ensure that the Data Architecture provides for the creation, storage, and exchange of data, especially PDD, models, and simulations, based on use of common, open industry, national, international, or NASA standards to the maximum extent practical.

3.2.1.5 Ensure that PDD and data related to defining and validating the product design and behavior from the engineering design, engineering test, manufacturing, verification, logistics, configuration and data management, and safety and mission assurance disciplines are managed to meet program requirements and relevant internal guidance (e.g., NASA-STD-7009, Standard for Models and Simulations).

3.2.1.6 Ensure that data needed by programs and projects (e.g., for milestones, reviews, mission operations, and anomalies or investigations, decisions, and outcomes) are identified and managed to provide traceability of data used in decision making.

3.2.1.7 Ensure that approaches to product identification elsewhere in program activities and practices preserve the integrity of product data and facilitate its use across the full product life cycle.

3.3 Information Support System Architecture (ISSA)

Note: The ISSA exists to allow programs/projects to capture, integrate, and manage product and process information from diverse authoring applications in a single environment. This environment enables the definition and standardization of workflow-driven processes that can be leveraged and utilized across multiple programs and projects. The ISSA is designed to integrate multiple mission-critical systems through the use of industry standards in PDLM (e.g., open application programming interfaces (APIs) and Enterprise Service Buses) to aggregate and extend knowledge sharing throughout the organization.

3.3.1 In defining and establishing an ISSA, the Agency CIO shall:

3.3.1.1 Document PDLM capabilities and make them available across the Agency, the infrastructure, security services, and architecture that supports them, their integration and interoperability functionalities, and the parties responsible for delivering them.

3.3.1.2 Ensure that PDLM capabilities meet requirements for population of and access to authoritative data (inclusive of ability to identify the purpose for which it was intended and the originator and the data management and configuration management information) from internal and external sources and the continued availability of as-designed, as-built, and as-flown PDD upon project completion and subsequent product retirement (e.g., pursuant to NPR 1441.1).

3.3.1.3 Ensure that adequate planning of Enterprise Architecture for PDLM capabilities anticipates NASA's extended life cycle, including partners and prime contractors.

3.3.1.4 Facilitate the provision of comprehensive search and integrated views (including reports) of data with a high degree of usability.

3.3.1.5 Assess the costs and benefits of providing a single point of access, single sign-on, policy-based or role-based security, support for portable devices, and other access enablers, particularly considering programs with extensive distributed work, challenging environments, or considerable external data exchange.

3.3.1.6 Periodically assess and report on performance of the ISSA in meeting and anticipating PDLM and program management needs, the adequacy of the human, technical, and organizational resources to support the ISSA, and to make recommendations for corrective action.

3.4 Process Architecture

Note: A Process Architecture is a description of the program or project business processes. A well-defined Process Architecture will set up rules and bounds in how the program and project will create, manage, and control program and project data. If set up early and properly, all program and project team members will clearly understand data control and release, and it will be well understood by all team members what data is authoritative and the process by which data is released to become authoritative. The flow of the program and project data will be well understood, and the roles and responsibilities for data handling and approval authority will be clear to all team members. The Process Architecture will ensure that every person or organization involved executes against the process. Each process to be used must be fully documented so that everyone understands their respective involvement in the process.

3.4.1 In establishing the Process Architecture, the program manager shall:

3.4.1.1 Ensure that processes include data interoperability requirements at defined life-cycle states and maturity levels, including but not limited to data relative to safety and mission assurance, such as deviations, waivers, corrective actions, and problem resolution, including detailing the close-out or buy-off of parts.

3.4.1.2 For tightly coupled programs, define a Process Architecture that supports program-wide interoperability needs and identifies which processes are to be adopted across all projects in the program.

3.5 PDLM Plan

3.5.1 The program manager shall produce and maintain a PDLM plan as follows:

3.5.1.1 For single-project and tightly coupled programs (as defined in NPR 7120.5), prepare a single PDLM plan in accordance with the requirements herein and the template in Appendix D of this NPR unless otherwise directed by the Mission Directorate; such a plan is presumed to reflect concurrence by member project managers.

3.5.1.2 For programs and projects initiated after the effective date of this NPR, prepare a preliminary, initial plan no later than completion of the System Definition Review (SDR); if no SDR is required, complete an initial plan before commencing Phase B Preliminary Design and Technology Completion.

3.5.1.3 For programs and projects underway, complete their initial plan in accordance with the applicability statements in section P.2b.

3.5.2 Because technology changes are independent of program and project phases, the program manager shall ensure that the PDLM plan is assessed at least annually in coordination with capability suppliers; during conceptual, design, development, test, and evaluation phases or, in preparation for program or project phase out, at reviews associated with or preceding major KDPs as defined in NPR 7120.5; and, during the operational phase, at flight readiness KDPs and at least annually thereafter.

3.5.3 The program manager shall ensure that contracts associated with their program and related projects acquire data that can be fully and effectively utilized by obtaining sufficient rights to use the data to support all program phases include language reflecting PDLM interoperability requirements such as those for computer-aided design (CAD) or other documents that facilitate efficient and effective data exchange with minimal rework and maximum data integrity.

DISTRIBUTION:
NODIS