![[NASA Logo]](../Images/nasaball.gif)
| |
NASA Procedures and Guidelines |
This Document is Obsolete and Is No Longer Used.
|
|
P.1 Purpose
P.2 Applicability
P.3 Authorities
P.4 Applicable Documents
P.5 Measurement/Verification
P.6 Cancellation
1.1 Overview
1.2 Document Structure
2.1 The NASA Chief Engineer
2.2 The Agency Chief Information Officer
2.3 Mission Directorates
2.4 The Chief, Safety and Mission Assurance
2.5 Center Directors
3.1 Security Architecture
3.2 Data Architecture
3.3 Information Support System Architecture
3.4 Process Architecture
3.5 PDLM Plan
D.1 Template Scope
D.2 Template Instructions
D.3 PDLM Plan Document Format and Content
D.4 Appendices
Figure D.3-1 PDLM Plan Title Page
Table D.3-1 PDLM Plan Revision and History Page
a. This NASA Procedural Requirements (NPR) directive describes the responsibilities and requirements for space flight programs and projects to effectively manage authoritative data that defines, describes, analyzes, and characterizes a product throughout its life cycle, including, but not limited to, engineering, design, test, procurement, manufacturing, operational, and logistics data, and closeout for the product.
b. The term "Product Data and Life-cycle Management" (PDLM) is used to describe these capabilities needed to support evolving product maturity within a program. Effective PDLM requires the robust execution of data management, documentation management, and configuration management activities in accordance with NPR 7123.1, NASA Systems Engineering Processes and Requirements, to ensure that the right data is available to the right people at the right time.
c. PDLM implementation has the following goals for programs and projects:
(1) Ensure that authoritative data are captured, stored, and catalogued per identified requirements for retrieval with the necessary data ownership and usage rights.
(2) Guide programs toward data management strategies that are agile and flexible.
(3) Ensure near real-time data queries, searches, and exchanges.
(4) Ensure consistent, repeatable use of effective PDLM processes, best practices, interoperability approaches, and methodologies.
(5) Enable configuration and data management of product definition data (PDD).
(6) Facilitate development, documentation, and use of common vocabularies for important communities of interest.
(7) Provide a mechanism to determine which PDD are authoritative for specified purposes and to ensure the integrity of that data.
(8) Designate authoritative data producers and sources, including both contractor- and Government-developed engineering and programmatic product-related data.
(9) Identify state of data (e.g., in work, under review, released, or another state such as approved) and its relationship to the product design.
(10) Increase the probability of mission success by managing the risk associated with data interchange and integration across disparate systems both internally and externally.
(11) Ensure access to PDD by programs and projects for heritage purposes in accordance with NASA Policy Directive (NPD) 1440.6, NASA Records Management, and NPR 1441.1, NASA Records Retention Schedules.
a. This NPR is applicable to NASA Headquarters and NASA Centers, including Component Facilities and Technical and Service Support Centers. This language applies to the Jet Propulsion Laboratory, a Federally Funded Research and Development Center, other contractors, grant recipients, or parties to agreements only to the extent specified or referenced in the appropriate contracts, grants, or agreements.
b. This NPR applies to the following:
(1) All current NASA space flight single-project and tightly coupled programs and their projects subject to NPR 7120.5, NASA Space Flight Program and Project Management Requirements, that are already under way and have not passed program key decision point (KDP) 0 or project KDP B (defined in NPR 7120.5) as of the effective date of this NPR.
(2) All future NASA space flight single-project and tightly coupled programs and their projects subject to NPR 7120.5.
(3) Reimbursable space flight programs/projects performed for non-NASA sponsors. Any tasks or efforts performed in support of NASA space flight programs/projects or reimbursable space flight programs/projects performed for non-NASA sponsors not directly identified within the applicable program PDLM plan should comply with the appropriate Center PDLM requirements.
c. Any waivers or deviations to this NPR are approved by the NASA Chief Engineer or Agency Chief Information Officer (CIO) as primary or alternate approver as follows:
(1) Chapter 2: NASA Chief Engineer as primary and Agency CIO as alternate.
(2) Chapter 3, Sections 3.1, 3.3, 3.4, and 3.5: NASA Chief Engineer as primary and Agency CIO as alternate.
(3) Chapter 3, Section 3.2: Agency CIO as primary and NASA Chief Engineer as alternate.
d. It is recommended that this NPR be considered for use in all other NASA programs and projects to help establish coordinated agreements between program/project managers and PDLM providers as early in the program or project life cycle as possible.
e. In this document:
(1) A requirement is identified by "shall."
(2) A good practice by "should."
(3) Permission by "may" or "can."
(4) Expected outcome or action by "will."
(5) Descriptive material by "is."
a. NPD 2800.1, Managing Information Technology.
b. NPD 7120.4, NASA Engineering and Program/Project Management Policy.
a. NPD 1440.6, NASA Records Management.
b. NPR 1441.1, NASA Records Retention Schedules.
c. NPR 1600.1, NASA Security Program Procedural Requirements.
d. NPR 2810.1, Security of Information Technology.
e. NPR 7120.5, NASA Space Flight Program and Project Management Requirements.
Compliance with this document is verified by submission to responsible NASA officials of the initial preliminary program PDLM plan (for new programs, this is by KDP 0 System Definition Review), upon major updates as defined in section 1.5.4 of that plan, and by internal and external controls. Internal controls include audit, review, and assessment processes defined in NPD 1200.1, NASA Internal Control. External controls may include external audits and reporting requirements.
None.
/S/
Michael G. Ryschkewitsch
NASA Chief Engineer
1.1.1 PDLM consists of disciplined collaborative processes and systems that plan for, acquire, and control PDD and associated product-related data, (including but not limited to engineering, design, test, procurement, manufacturing, operational, and logistics information) throughout the product and data life cycles.
1.1.2 PDLM is the set of processes and associated information used to manage the entire life cycle of product data from its conception, through design, test, and manufacturing, to service and disposal. To do so requires managing the creation and changes to product definition, product configurations, affiliated engineering data (e.g., design definition and rationale, studies and analyses, models and simulations, testing and verification planning and results), data on the performance of the product components in mission environments, and product software and hardware.
1.1.3 Product Data Management (PDM) provides key capabilities that underlay Product Life-cycle Management (PLM) and is widely considered a precursor requirement to effective PDLM.
1.1.4 PDLM integrates data, processes, tools, and business systems to provide users with a product information backbone for NASA programs and projects. A life-cycle-oriented approach to PDLM is intended to reduce or eliminate redundant development activities, increase collaborative design and analysis, and reduce time to complete informed decision making throughout the program and project life cycle.
1.1.5 Information Technology (IT) Systems across NASA will be made interoperable or integrated to the extent needed to provide a secure, readily accessible environment to enable required collaborative PDLM capabilities.
1.1.6 This direction is intended to increase the probability of mission success by increasing the effectiveness and efficiency of data interchange and integration across disparate systems and increasing availability of the right data for the right people at the right time, thereby reducing risk.
1.2.1 The remainder of this document is organized as follows:
a. Chapter 2 defines roles and responsibilities for implementing PDLM.
b. Chapter 3 provides requirements (verifiable "shall" statements) for PDLM architectures and the PDLM plan.
c. Appendix A provides definitions for terms used in this document.
d. Appendix B provides a list of acronyms used in this document.
e. Appendix C provides a list of applicable references.
f. Appendix D describes the content of the PDLM plan.
Note: This chapter defines the roles and responsibilities of the key officials in the PDLM management process. The roles and responsibilities of senior NASA management, along with fundamental principles of governance, are defined in NPD 1000.0, NASA Governance and Strategic Management Handbook, and further described in NPD 1000.3, The NASA Organization.
2.1.1 The NASA Chief Engineer is responsible for modifying existing or establishing new NASA policies, procedural requirements, technical standards, and guidance associated with PDLM processes and practices and for ensuring that necessary and sufficient data are obtained for program and project needs.
2.2.1 The Agency CIO develops Agency direction on IT strategy, governance, and architecture.
2.2.2 The Agency CIO develops the Information Support System Architecture (ISSA) and Security Architecture.
2.2.3 The Agency CIO defines Agency-wide PDLM IT strategy considering high-level infrastructure, Enterprise Architecture, engineering and program management requirements, and associated policies, procedures, standards, guidelines, services, and capabilities that:
2.2.3.1 Provides oversight for the planning and deployment of IT investments to support Center, program, and project adherence to established PDLM requirements.
2.2.3.2 Ensures that the Security Architecture provides continuity of operations via timely access, reliability, transmission quality, integrity, and confidentiality of Agency data and systems while adhering to NPR 1600.1, NASA Security Program Procedural Requirements; NPR 2810.1, Security of Information Technology; and Federal IT security regulations.
2.2.3.3 Ensures that the ISSA supports the development and maintenance of capabilities for PDLM across the life cycle, including ensuring that authoritative and relevant PDD remain discoverable, reusable, and accessible within NASA in an effective and efficient manner following project disposal (as defined in NPR 1441.1, NASA Records Retention Schedules).
2.2.3.4 Documents data delivery mechanisms to facilitate the discovery, planning, and implementation of PDLM capabilities by programs and projects.
2.2.3.5 Documents lessons learned related to planning, requirements, and implementation of PDLM capabilities that cross institutional internal boundaries or relate to data exchange with external partners and contractors.
2.2.4 The Agency CIO needs to ensure, with IT providers, that the capabilities are available in advance to meet the requirements of programs and projects.
2.3.1 Mission Directorates have a critical role in the direction for PDLM: they are responsible for executing mission requirements in a manner consistent with Agency requirements, policies, and procedures, including but not limited to providing adequate program and project coordination and resources to ensure successful execution of mission requirements.
2.3.2 In coordination with the program manager, the Mission Directorate Associate Administrator is responsible for the following:
2.3.2.1 Ensuring that the program's governance framework (model) is sufficient to the task of planning and meeting the requirements herein and of developing and updating a PDLM plan when required.
2.3.2.2 Ensuring that PDLM plans (initial and updates) produced by the program manager of a single-project or tightly coupled program are in accordance with section 3.5 and the template and instructions in Appendix D of this NPR.
2.3.2.3 Ensuring that the PDLM plan reflects the PDLM requirements of the program and its projects, identifies necessary capabilities, documents specific areas of reliance on IT infrastructure and services, and articulates the timing for implementation of PDLM capabilities throughout the program and project life cycle.
2.3.2.4 Ensuring that the PDLM plan documents agreements among the program manager and the various providers of PDLM services on how the identified PDLM capabilities will be provided; concurrence to the plan is noted by signatures by the program manager, the Mission Directorate Associate Administrator, and PDLM tool providers (e.g., Center Director, Mission Directorate), at a minimum.
2.3.2.5 Ensuring that Process Architecture appropriately reflects the requirements for tightly coupled programs (i.e., supports program-wide integration and interoperability needs and identifies which processes are to be adopted across all projects in the program).
2.3.2.6 Ensuring that all contracts associated with their program and its projects contain PDLM interoperability and sustainability requirements and that essential contractor-originated data are identified and acquired with sufficient access and usage rights to support the full project life cycle.
2.4.1 The Chief, Safety and Mission Assurance establishes standards and requirements for the definition, handling, and control of safety, reliability, and mission assurance data by NASA programs and projects to facilitate goals of the PDLM standards and requirements.
2.5.1 Center Directors, or delegates, ensure that resources, capabilities, and infrastructure are available to support program execution. As such, Center Directors are responsible for ensuring that negotiations are conducted between the program/project and process/tool managers to achieve a viable and defined contribution of Center resources, that Center policies and procedures are aligned with program/project needs, and that both are documented in the program's PDLM plan.
2.5.2 Center Directors, or delegates, ensure that Center policies support the Agency's requirements for PDLM.
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.
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.
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.
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.
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.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.
A.1 Authoritative Data. Data that has been designated as valid for specific official programs/projects. The designated data is controlled by processes. (Source: NPD 7120.4, NASA Engineering and Program/Project Management Policy)
A.2 Authoritative Source. An application or repository identified as the official source for specific authoritative data. (Source: Adapted from NPD 7120.4, NASA Engineering and Program/Project Management Policy definition of Authoritative Data)
A.3 Bill of Material (BOM). A listing for a semi-finished or finished product (e.g., end item) containing component parts and materials making up a single instance of a product with a name, reference, or part number, quantity, and unit of measure for each component. A BOM is a representation of product information for a particular purpose such as engineering, manufacturing, procurement, or sustainment. An indentured, hierarchical BOM is a form of product breakdown structure because it captures product component relationships as well as identity and quantity. (Adapted from Department of Defense and industry sources)
A.4 Computer-Aided Design (CAD). Process of creating engineering designs defined by electronically produced multi-dimensional geometry using special software systems, the tools used by engineers to create geometric-based design definitions represented in a variety of formats, including two-dimensional drawings, three-dimensional solid models, envelopes, wireframes, and kinematics and time-based models.
A.5 Configuration Management. A management discipline applied over the product's life cycle to provide visibility into and to control changes to performance, function, and physical characteristics. (Source: NPR 7120.5, NASA Space Flight Program and Project Management Requirements) Also, a process that establishes and maintains consistency of a product's attributes with the requirements and product configuration information throughout the product's life cycle. (Source: NASA-STD-0005, NASA Configuration Management (CM) Standard)
A.6 Data. A representation of facts, concepts, or instructions in a manner suitable for communication, interpretation, or processing by humans or by automatic means. (Source: ISO/IEC 24765:2009, Systems and software engineering vocabulary)
A.7 Data Architecture. Provides an understanding of what information is needed to effectively execute the Enterprise's business processes and provides a framework for effectively managing the Enterprise's information environment. Data Architecture links information behavior (i.e., accessing, using, and sharing data), information management processes, and information support staff to other aspects of the Enterprise. (Source: NPR 2830.1, NASA Enterprise Architecture Procedures)
A.8 Data Life Cycle. The series of states that a data object can take from its creation to its retirement or destruction; generally, these states represent maturity levels or indicate suitability for, or restrictions on, use.
A.9 Data Management. The disciplined processes and systems that plan for, acquire, and provide stewardship for product and product-related data, throughout the product and data life cycles. (Source: NPR 7123.1, NASA Systems Engineering Processes and Requirements)
A.10 Data Model. Identifies the data, their attributes, and relationships or associations with other data. (Source: Department of Defense Directive 8320.03, Unique Identification (UID) Standards for a Net-Centric Department of Defense, March 2007)
A.11 Delivery. Applies to the hand-off, which may be physical or virtual in the case of data, at initial delivery of an item during development, for collaboration, in support of reviews, at the time of acceptance, and for subsequent modifications, maintenance, refurbishment, or any other activity that produces new data.
A.12 End Item. A product to be delivered under contract as an intact unit or to be assembled, completed, and made ready for use as a unit.
A.13 Engineering Release. An action whereby engineering documentation or an item is officially made available for the intended use. (Source: Modified from NASA-STD-0005, NASA Configuration Management (CM) Standard)
A.14 Governance Framework (Model). The framework--principles and structures--through which the Agency manages the mission, roles, and responsibilities. (Source: NPD 1000.0, NASA Governance and Strategic Management Handbook)
A.15 Metadata. Data about data, including information describing aspects of actual data items, such as name, type, format, content, and other descriptive information.
A.16 Product. A part of a system consisting of end products that perform operational functions and enabling products that perform life-cycle services related to the end product or a result of the technical efforts in the form of a work product (e.g., plan, baseline, or test result). (Source: NPR 7123.1, NASA Systems Engineering Processes and Requirements) Products include, but are not limited to, spacecraft, launch vehicles, instruments, payloads, software, launch platforms, and other elements that are necessary components to deliver a completed vehicle.
A.17 Product Breakdown Structure. A hierarchical view of the relationship of products and component products. (Source: NPR 7120.4, NASA Engineering and Program/Project Management Policy)
A.18 Product Data Management (PDM). The framework that enables organizations to manage and control engineering and technical information, specifically data surrounding the product's design, definition, and related engineering, manufacturing, and logistics processes and is a key element of PLM. From the product perspective, PDM organizes data required for design evolution, tracks versions and configurations of evolving design concepts, and manages archived data and other product-specific information. PDM tools provide access to product structures and other engineering data such as requirements, as-built, and safety and mission assurance data. From the process perspective, PDM systems offer the capability to orchestrate controlled procedural events such as design reviews, approvals, product releases, and configuration audits. (Source: NPD 7120.4, NASA Engineering and Program/Project Management Policy)
A.19 Product Definition Data (PDD). The data objects and associated elements required to completely define a product. In normal usage, PDD refers to the authoritative design engineering design definition, but it can include data associated with production, operations, maintenance, and disposal. (Source: Adapted from ISO 16792, Technical product documentation -- Digital product definition data practices)
A.20 Product Life Cycle. A series of states that generally defines the maturity level of a product and correlate with specific uses or users. Commonly, each state is represented by an agreed-to collection of information that identifies and establishes the attributes of a product at a point in time and that serves as the basis for defining change. A product's life cycle begins with a concept and ends with disposal.
A.21 Product Life-cycle Management (PLM). A strategic business approach that applies a consistent set of business solutions in support of the collaborative creation, management, dissemination, and use of product definition data/information across the extended enterprise from concept to end of life. PLM integrates people/organizations, processes, and information. In product-dominated endeavors, PLM serves as the information backbone that extends outside the enterprise. PLM implementations may be composed of multiple elements, including foundation technologies and standards (e.g., Extensible Markup Language, visualization, collaboration, and enterprise application integration), information authoring tools (e.g., mechanical computer-aided design, electrical computer-aided design, and technical publishing), core functions (e.g., data vaults, document and content management, work flow and program management), functional applications (e.g., configuration management), and business solutions built on the other elements. (Source: NPD 7120.4, NASA Engineering and Program/Project Management Policy)
A.22 Product Data and Life-cycle Management (PDLM) System. A combination of the information technology applications, users, and processes that implement the management of product data across the product life cycle.
A.23 Program. A strategic investment by a Mission Directorate or Mission Support Office that has a defined architecture and/or technical approach, requirements, funding level, and a management structure that initiates and directs one or more projects. A program defines a strategic direction that the Agency has identified as critical. (Source: NPR 7120.5, NASA Space Flight Program and Project Management Requirements)
A.24 Project. A specific investment having defined goals, objectives, requirements, life-cycle cost, a beginning, and an end. A project yields new or revised products or services that directly address NASA's strategic needs. They may be performed wholly in-house; by Government, industry, academia partnerships; or through contracts with private industry. (Source: NPD 7120.4, NASA Engineering and Program/Project Management Policy)
A.25 Software. Computer programs, procedures, rules, and associated documentation and data pertaining to the development and operation of a computer system. Software also includes but is not limited to commercial off-the-shelf (COTS) software, Government off-the-shelf (GOTS) software, modified off-the-shelf (MOTS) software, embedded software, reuse, heritage, legacy, auto-generated code, firmware, and open source software components. (Source: NPD 7120.4, NASA Engineering and Program/Project Management Policy)
| API | Application Programming Interface |
| BOM | Bill of Material |
| CAD | Computer-Aided Design |
| CIO | Chief Information Officer |
| CM | Configuration Management |
| ConOps | Concepts of Operations |
| COTS | Commercial off-the-shelf |
| D | Dimensional |
| GOTS | Government off-the-shelf |
| (I) | Interim |
| IEC | International Electrotechnical Commission |
| IEEE | Institute of Electrical and Electronics Engineers |
| ISO | International Organization for Standardization |
| ISSA | Information Support System Architecture |
| IT | Information Technology |
| KDP | Key Decision Point |
| MOTS | Modified off-the-shelf |
| NASA | National Aeronautics and Space Administration |
| NPD | NASA Policy Directive |
| NPR | NASA Procedural Requirements |
| PDD | Product Definition Data |
| PDLM | Product Data and Life-cycle Management |
| PDM | Product Data Management |
| PLM | Product Life-cycle Management |
| R&T | Research and Technology |
| SBU | Sensitive but Unclassified |
| SDR | System Definition Review |
| STD | Standard |
| UID | Unique Identification |
C.1 Department of Defense Directive 8320.03, Unique Identification (UID) Standards for a Net-Centric Department of Defense.
C.2 IEEE 1362-1998 (Incorporates IEEE 1362a-1998), IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document.
C.3 ISO 16792, Technical product documentation -- Digital product definition data practices.
C.4 ISO/IEC 24765:2009, Systems and software engineering vocabulary.
C.5 NPD 1000.0, NASA Governance and Strategic Management Handbook.
C.6 NPD 1000.3, The NASA Organization.
C.7 NPD 1001.0, 2006 NASA Strategic Plan.
C.8 NPD 1080.1, Policy for the Conduct of NASA Research and Technology (R&T).
C.9 NPD 1200.1, NASA Internal Control.
C.10 NPR 1080.1, Requirements for the Conduct of NASA Research and Technology (R&T).
C.11 NPR 1800.1, NASA Occupational Health Program Procedures.
C.12 NPR 2800.1, Managing Information Technology.
C.13 NPR 2830.1, NASA Enterprise Architecture Procedures.
C.14 NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements.
C.15 NPR 7123.1, NASA Systems Engineering Processes and Requirements.
C.16 NPR 7150.2, NASA Software Engineering Requirements.
C.17 NPR 8000.4, Agency Risk Management Procedural Requirements.
C.18 NPR 8715.3, NASA General Safety Program Requirements.
C.19 NPR 8820.2, Facility Project Requirements.
C.20 NASA-STD-0005, NASA Configuration Management (CM) Standard.
C.21 NASA-STD-(I)-0007, NASA Computer-Aided Design Interoperability.
C.22 NASA-STD-7009, Standard for Models and Simulations.
D.1.1 Consistent with the requirements for a PDLM plan in section 3.5 of the PDLM NPR, the purpose of the PDLM plan is to document agreement among the program manager and various providers of PDLM services on how the identified PDLM capabilities will be provided. For single-project or tightly coupled programs (as defined in NPR 7120.5), a single program-wide plan will be produced. Concurrence to the plan is noted by signatures by the program manager, the Mission Directorate Associate Administrator, and providers of PDLM capabilities such as Center Directors and the Mission Directorates. Project managers for tightly coupled programs are required to sign the plan.
D.1.2 All plans will reflect the requirements for specific PDLM capabilities to support the appropriate program or project-specific scope, document the choices among alternative delivery mechanisms and providers, and discuss in detail reliance on IT infrastructure and services.
D.1.3 Center Directors' concurrence with a PDLM plan documents their commitment to provide required Center resources to support the program/project as articulated in the PDLM plan.
D.1.4 A PDLM plan defines the scope of each Center's responsibilities, the implementation approach, the environment in which the program and its projects' PDLM solution(s) operates, and timing for implementation of the PDLM solution and associated processes, data, elements, attributes, and formats.
D.1.5 The template reflects the expectation that a variety of program and project documents and project data and process requirements will need to be synchronized with this plan and with the provision of IT-related capabilities, services, and infrastructure.
D.2.1 The PDLM plan template anticipates the document being treated as a formally controlled program document.
D.2.2 All sections of the PDLM plan template are required. The sections are based on requirements in this NPR citing "architectures" on ISSA, security, data, and processes. These "architectures" are combinations of technology and work practices/procedures that are linked for meaningful implementation.
D.2.3 If an extensive discussion is required, the section content may be captured in detail in a stand-alone document referenced appropriately and summarized in the section. If the material has been covered in another approved programmatic document, please indicate the source document and the appropriate sections, paragraphs, or pages.
D.2.4 If a section is not applicable due to the nature of the program or project, include the phrase "Not applicable" in that section and provide the rationale. Use section 2.2 to indicate waivers or deviations for compliance with the specific requirements of this NPR and identify the source authority documents.
D.2.5 An appendix is provided to allow for the inclusion of supporting material such as concepts of operation, user scenarios, glossaries, and the like.
Note: The template sections are shown below within an outline. Wording in italics provides suggestions or guidance about the section contents but are not requirements. A wide variety of formats such as text, diagrams, or tables may meet the intent of the section content, and authors are encouraged to use the most effective format.
D.3.1 PDLM Plan Title Page
Figure D.3-1 PDLM Plan Title Page
D.3.2 Revision and History Page
Table D.3-2 PDLM Plan Revision and History Page
D.3.3 Signature Page
Note: The signatures required for this plan will vary on the plan scope. Refer to Chapter 2, Responsibilities; Chapter 3, section 3.5, PDLM plan; and the instructions for this template to determine the required signatures.
D.3.4 Table of Contents
D.3.5 Preface
Note: The preface provides information to the reader about the context in which this document will be effective. Minor changes in preface organization are acceptable to achieve consistency with other program or project documents.
P.1 Purpose of Document
P.1.1 Purpose
P.2 Applicability and Scope
P.2.1 Applicability
P.2.2 Scope
P.3 Change Authority
P.3.1 Change Authority
P.4 Applicable and Reference Documents
P.4.1 Applicable Documents
P.4.2 Reference Documents
D.3.6 Body of the Document
1.1.1 Briefly describe the goals of the program and the organizational structure of the program, its projects, and project elements. Also, provide a context diagram identifying the program and relationships to each project and element, and identify program/project documents that will aid readers in understanding the scope, goals, and schedules of the content of this plan.
1.2.1 State the specific objectives and high-level performance goals levied on the program and its projects for PDLM.
1.3 Solution Summary
1.3.1 Summarize the content of this plan: which specific solutions will be used by which program or project elements and for what PDLM functions, clarifying use by product life cycle and user community, and identifying approximate maturity levels. If needed beyond the content in the body of this plan, refer to associated documents that describe details of the solution elements.
1.4.1 List any assumptions affecting this solution such as upgrades, software licenses, access control, network services, contract provisions/award, or other similar matters.
1.4.2 If this plan addresses a subset of all the requirements expected for PDLM support through the life of a program or project, indicate that scope.
1.5.1 Define responsible organizations and their roles. For example, depending on the scope of the program/project, this responsibility may be assigned to a responsible party within program planning and control, or there may be a separate organization such as an information systems office.
1.5.2 Identify the governing mechanisms (including processes, boards/panels) through which service capability requests and other decisions related to the requirements in this plan or their implementation will be approved.
1.5.3 Clarify the scale or scope of requests or changes that require formal approval and potentially lead to an update of this plan. Identify the program or project document describing the change control process for this plan.
1.5.4 Consistent with Chapter 3, section 3.5.2 in the NPR, address timing of the preliminary release, baseline, and updates to the program PDLM plan. This timing should recognize that the maturity of the plan is affected by both the program's phasing and by current and planned changes to the information technology used to implement PDLM (e.g., updates and capabilities committed to by PDLM tool providers). This section, in conjunction with Appendix D, section 2.3, Future Work Discussion, should be seen as delivering a cohesive picture of how PDLM is evolving as of the most recent document version.
2.1.1 Identify the specific paragraphs in Appendix D, section 4.0, that address compliance with Chapter 3, section 3.2, Data Architecture.
2.1.2 For any Chapter 3, section 3.2 Data Architecture requirements that cannot be mapped to an implementation plan detail in Appendix D, section 4.0, describe whether they do not apply or are to be achieved through future work.
2.1.3 Identify the specific paragraphs in Appendix D, section 4.0, that address compliance with Chapter 3, section 3.4, Process Architecture.
2.1.4 For any Chapter 3.4 Process Architecture requirements that cannot be mapped to an implementation plan detail in Appendix D, section 4.0, describe whether they do not apply or are to be achieved through future work.
Note: This is the section in which deviations and waivers to the NPR requirements should be noted and the source authority for that identified.
2.2.1 Justify the exclusion of a requirement from Chapter 3, section 3.2, Data Architecture.
2.2.2 Justify the exclusion of a requirement from Chapter 3, section 3.4, Process Architecture.
Note: Indicate activities or decisions that are in work or not yet under way at the time this plan is approved but which will affect the PDLM plan. A future work item here does not substitute for an update to this plan but does allow affected parties to be aware of upcoming issues.
2.3.1 Discuss the rationale and nature of the future work related to Chapter 3, section 3.2, Data Architecture.
2.3.2 Discuss the rationale and nature of the future work related to Chapter 3, section 3.4, Process Architecture.
Note: This section is expected to vary in length and complexity along with the program's length and complexity. For example, a program operating within a single Center and without complex external relationships may adopt a "local-provider" approach in which its requirements are met entirely by their local Center. Alternatively, more complex programs may pursue multiple parallel strategies as different sub-elements mature.
3.1.1 Describe the overarching strategy to be used by this program and associated projects to meet the goals of this NPR.
3.1.2 Describe how the strategy affects the adoption and deployment of PDLM concepts and practices.
3.1.3 Identify Center and Agency IT initiatives such as network updates, program-specific IT solutions, and PDLM consolidation, and discuss how the PDLM strategy aligns with these initiatives.
3.2.1 Discuss how product data and product definition will be managed for the program and projects covered under this plan.
3.2.2 Identify dependencies and barriers that must be addressed for full implementation of PDM for this program and its projects.
3.3.1 Discuss how PLM will be conducted for the program and projects covered under this plan.
3.3.2 Identify dependencies and barriers that must be addressed for full implementation of PLM for this program and its projects.
Note: Depending on the scale and scope of the program or project, the amount of detail in the following sections will vary:
4.1.1 Process Identification
4.1.1.1 Describe processes to be supported in PDLM solutions at involved Centers or sites and the projects/elements that will be using those processes. Refer to relevant documents that describe desktop instructions and associated tools for the implementation of work processes.
4.1.2 Functional Support
4.1.2.1 Define specific process support and its linkage to automated PDLM solutions for engineering change control and release management, data management, configuration management, and program/project needs for decision support, reviews, and design and systems engineering, and operations and sustaining tasks.
4.1.3 Monitoring and Performance Metrics
4.1.3.1 Discuss the management tools available to monitor process performance and issues such as time in queue, mean flow time for reviews, release rates, average number of changes in process, and number of rejected submissions.
4.1.4 Data Integrity Processes
4.1.4.1 Identify key PDD-related processes associated with ensuring integrity of data and with ensuring authoritative data are properly and efficiently managed.
4.1.5 Data Exchange Processes
4.1.5.1 Identify data exchange processes, discuss the timing and nature of their use and involved users, and the state of process implementation or maturity.
4.1.5.2 Identify associated pre- and post-processing for PDD associated with data exchanges (e.g., from design to assembly) and the parties responsible for such processing.
4.1.5.3 Identify cases where standard processes are not yet in place or where exceptions have been made and explain the reasoning for any exceptions.
4.2.1 Identify the user communities, their physical location, their program/project assignments, and their primary responsibilities.
Note: Programs and their associated projects will routinely make use of existing PDLM tool suites provided by application suppliers such as a Center. The content in this section articulates which tools will be provided by which suppliers and the extent and nature of their use for a user community or function.
4.3.1 Identify the PDLM tools and specific applications within those tools to be used and the NASA suppliers of those tools.
4.3.2 Map these tools to the user communities defined in Appendix D, section 4.2.
4.4.1 Map the processes from Appendix D, section 4.1, to the user communities defined in Appendix D, section 4.2.
4.4.2 Map the processes from Appendix D, section 4.1, to the tool in Appendix D, section 4.3.
4.4.3 If relevant processes are defined in other documents, provide the document numbers, document titles, and locations of these documents.
4.5.1 If Data Architecture is addressed in stand-alone program or project documents, identify those documents here, including the status of such documents and future plans regarding their content and applicability.
4.5.2 Depending upon the scale and scope of the program and its projects, not all aspects of Data Architecture need to be addressed independently; summarize relevant content from other program materials as it relates to the Data Architecture for product life cycle and PDD.
4.5.3 Identify Data Architecture requirements being imposed upon the PDLM solution elements to support interoperability, data exchange, metadata, and work practices.
4.6.1 Explain how the various levels of product breakdown structure(s) for the system end products, their subsystems, and the supporting or enabling products will be represented and how in-house and contractor data will be integrated into the different product breakdown structures (or bills of material) needed across the program life cycle.
4.6.2 Summarize how product breakdown structures (or bills of material) will be used in the program and its projects.
4.6.3 Discuss how the PDLM implementation approach described herein will support multiple product breakdown structures being available simultaneously across product life cycles and program/project milestones.
4.6.4 Discuss how software and hardware elements of product breakdown structure will be linked in support of program/project needs and the effect of those requirements on this solution.
4.7.1 Document intentions regarding when to use specialized data types such as 3-dimensional (D) CAD, 2-D CAD, models, simulations, or specialized design tools (e.g., to conduct simulations of product performance, control design definition for manufacturing, for acceptance check on physical hardware, for visualization and training, and for engineering analysis and modeling).
4.7.2 Describe which, and for what purposes, CAD tools will be used by program and project elements, including contractors and partners.
4.7.3 Discuss how the elements of NASA's PDLM CAD interoperability requirements will be applied over the life cycle of the program. Identify additional internal or external standards, practices, settings, and supporting tools to be used (e.g., for model checking, conformance, analysis re-use, and data exchange) and identify parties responsible for such determinations.
4.7.4 Discuss how the elements of NASA-STD-7009, Standard for Models and Simulations, will be applied to product data management. Identify additional internal or external standards, practices, or program documents that cover modeling and simulation data handling, and identify parties responsible for such determinations.
4.7.5 Identify the standards to be used for part identification. Identify responsible parties and processes for addressing conflicts and issues around CAD file naming, part identification, and reconciliation of issues emerging from use of common hardware CAD files and integration of CAD files across Centers, program elements, contractors, and partners.
4.7.6 Define policies for identifying the handling of models, simulations, CAD design documents that are proprietary, intellectual property, or designated as sensitive but unclassified (SBU).
4.7.7 Identify the program/project data or documents that the CAD producer is to provide in addition to the CAD object to assure full PDD such as parts lists, materials specifications, or acceptance testing specifications and where such material will be maintained.
4.8.1 Describe how elements of the PDLM solution will be used to avoid or reduce the occurrence of duplicate or multiple part numbers and designations for an identical physical part.
4.8.2 Describe how the program/project will work with the organizations responsible for shared part definition libraries, common model and simulation libraries, and CAD libraries (whether internal or external to the program) to ensure approved practices are followed for such matters as use, naming, and substitute/alternatives.
4.9.1 Identify existing (or describe the requirements for modifications to) engineering release and delivery-of-items processes to support program/project needs and interoperability across Centers, program elements, contractors, and partners.
4.9.2 Include the identified solutions (or requested modifications) to provide visibility of the life cycle, maturity, and change status of PDD (such as 3-D CAD models) and other engineering models across the program/project life cycle.
4.9.3 Identify the program/project-specific documents that address engineering release, change control, and configuration management and summarize their content, including contractor configuration management, as required by NASA-STD-0005, NASA Configuration Management (CM) Standard.
4.9.4 Describe which aspects of the provided PDLM solution will be used by the program and its projects to manage the data and processes around close-out or buy-off of parts.
4.10.1 Identify the program/project-specific documents that address product-related data management with particular attention to PDD and summarize their content.
4.10.2 Define reports, analyses, data sets, models, simulations, and documents (especially those leading up to a design, e.g., stress analyses, thermal, loads, dynamics) that will be generated for program management, troubleshooting, and problem resolution.
4.10.3 Define a set of authoritative requirements and data that represent the various stages of the products (e.g., as-designed, as-built, as-delivered, as-maintained) that will represent the architecture of the product at all stages.
4.10.4 Describe PDD data delivery sources, processes, usage, and access rights, including contractor-originated data across the entire project life cycle.
4.10.5 Identify the source and summarize relevant content from the program's records plans as required by NPD 1440.6, NASA Records Management, and NPR 1441.1, NASA Records Retention Schedules, and include contractor records content or identify source documents and their locations.
4.11.1 Identify party responsible for the IT security plan for the applications/systems to be used.
4.11.2 Discuss any intended revisions to support the specific program/project needs, their timing, and status.
Note: Use as needed: consider including Glossaries, Concepts of Operation, User Scenarios, Architecture Models, Data Flow Diagrams, System Descriptions/Specifications, and other materials that facilitate the understanding of the plans and solutions for product data and life-cycle management outlined in this plan.