![[NASA Logo]](../Images/nasaball.gif) |
NASA Procedures and Guidelines |
||||
This Document is Obsolete and Is No Longer Used.
|
|||||
|
|
|||||
|
|
||||
| | TOC | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppendixD | ALL | | |||||
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.
| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | AppendixA | AppendixB | AppendixC | AppendixD | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |