Procedural
Requirements
Effective Date: August 17, 2020
Expiration Date: August 17, 2030
|
|
NASA Procedural Requirements |
NPR 7120.7A Effective Date: August 17, 2020 Expiration Date: August 17, 2030 |
| | TOC | ChangeLog | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppenidxE | ALL | |
Acceptable Risk. The risk that is understood and agreed to by the service line / project governing body, Mission Directorate and/or Mission Support Office, and other customer(s) such that no further specific mitigating action is required. (Some mitigating actions might have already occurred.)
Acquisition. Obtaining, or advancing the development of, the systems, research, services, construction, and supplies to fulfill the Agency's mission and other activities which advance the Agency's statutory objectives. (The definition of acquisition in this document is used in a broader context than the FAR definition to encompass the spectrum of various NASA acquisition authorities and approaches to achieve the Agency's mission and activities).
Action. A discrete task that is accomplished by a single individual or a small team or group. Action items typically arise from meetings and should be clearly documented.
Activity. An effort that operates the IT infrastructure capabilities, products, systems, or services. Unlike projects and initiatives, activities are ongoing and repetitive. Activities consume resources and have a sustainment cost.
Agile. An umbrella term that describes a variety of frameworks and methods that emphasize the ability to respond to change in an environment of uncertainty.
Agile Development Methodology. An umbrella term that describes a family of iterative development frameworks that align with the Agile Manifesto, which emphasizes interpersonal relationships, self-directed teams, sustainable development, customer collaboration, responsiveness to change, and incremental product development and releases. These methodologies often include similar characteristics, such as: repeatable phasing (sprints, iterations, and releases), a framework to manage changing user requirements, pair-programming practices, iterative modeling, and automated development and testing workflows.
Analysis of Alternatives (AoA). A formal analysis method that compares alternative approaches by estimating their ability to satisfy mission requirements through an effectiveness analysis and by estimating the life cycle costs (LCC) through cost analysis. The results of these two analyses are used together to produce a cost-effectiveness comparison that allows decision makers to assess the relative value or potential service line returns of the alternatives. An analysis of alternatives broadly examines multiple elements of service line / project alternatives (including recommended concept, technical performance, risk, LCC, and service line aspects).
Approval. Authorization by a required management official to proceed with a proposed course of action. Approvals are documented.
Base Services. Foundational products and services within a service line. Often equated with infrastructure capabilities and platforms that are common requirements for all Agency organizations and employs.
Baseline. An agreed-to scope, set of requirements, cost, and schedule that will have changes controlled through a formal approval and monitoring process.
Center Standardized Services. Services that are not standardized and implemented at the Enterprise level, but are standardized by a Center for the users at that Center.
Compliance Matrix. The Compliance Matrix documents how the service line or project complies with the requirements of this NPR. It provides rationale and approvals for relief from requirements and is part of formal service line and project documentation.
Concept of Operations (ConOps). Developed early in Pre-Formulation, describes the overall high-level concept of how the product, system, or service will be used to meet user expectations, usually in a time sequenced manner. It describes the product, system, or service from an operational perspective and helps facilitate an understanding of the product, system, or service goals. It stimulates the development of the requirements and architecture related to the user elements of the product, system, or service. It serves as the basis for subsequent definition documents and provides the foundation for the long-range user operational expectations.
Continuous Delivery. A specific type of activity that includes the production and release of software or data on a near continuous basis using short increments that is supported by a deployment pipeline to ensure visibility into the delivery system, rapid feedback on issues or problems, and continual automated deployment.
Contract. A mutually binding legal relationship obligating the seller to furnish the supplies or services (including construction) and the buyer to pay for them. It includes all types of commitments that obligate the Government to an expenditure of appropriated funds and that, except as otherwise authorized, are in writing. In addition to bilateral instruments, contracts include (but are not limited to) awards and notices of awards; job orders or task letters issued under basic ordering agreements; letter contracts; orders, such as purchase orders, under which the contract becomes effective by written acceptance or performance; and bilateral contract modifications. Contracts do not include grants and cooperative agreements.
Cost Baseline. The approved version of the time-phased project budget, excluding any management reserves.
Customer. Any individual, organization, or other entity to which a service line or project provides a product(s) and/or service(s).
Cybersecurity. Protection of people, property, and information assets owned by NASA that covers physical assets, personnel, IT, communications, and operations.
Decision Authority (DA). The individual authorized by the Agency to make decisions on service lines, programs, and projects under their authority.
Decision Memorandum. The document that summarizes the decisions made at life cycle reviews or in between reviews following the approved OCIO template.
Decommission. The process of removing a product, system, or service from operations.
Demand Service. Consumption-oriented service within a service line. Defined by variable service levels and price points, demand-based services enable customers to pay as-needed for the services that meet their business/mission requirements.
Deployment. The life cycle phase that culminates with the transfer of responsibility for the product, system, or service from the project team to an operations and maintenance engineering team. At the conclusion of the deployment, the product, system, or service is considered fully operational.
Development, Modernization, and Enhancement (DME). DME of an IT product, system, or service may include IT investments for steady state. DME includes design, development, testing, and deployment of changes and enhancements to existing products, systems, or services to engender new or modified functionality. DME may also include development, consolidation, integration, and/or expansion of products, systems, or services to support other Agency needs.
Disposal. The process of eliminating a project's assets.
Emergency Changes. A special case of normal changes that have a critical timeframe to implement and that are required to be made immediately to resolve a significantly impacting incident or a mission-critical issue.
Enterprise Architecture (EA). Use of a common framework and methodology to describe the integrated Target capability/service environment (including components such as people, systems, processes, information/data, and their inter-relationships) and the transition plan that integrates the IT service line architectures for the purpose of describing the integrated delivery of services.
Enterprise Architecture Project Assessment (EAPA). The process used to validate alignment and integration of the project with the service line architecture.
Enterprise Architecture Service Assessment (EASA). The process used to validate the resulting product, system, or service operates in alignment with the service line architecture.
Enterprise Services. Services that are provided to users across the entire Agency using a standard set of technologies and a single, Agency-wide service provisioning method.
Evaluation. The continual self and independent assessment of the performance of a service line or project and incorporation of the evaluation findings to ensure adequacy of planning and execution according to plans.
Formal Dissent. A substantive disagreement with a decision or action that an individual judges is not in the best interest of NASA and is of sufficient significance and importance that it warrants a timely review and decision by higher-level management.
Formulation. The identification of how the service line or project supports the Agency's strategic goals; the assessment of feasibility, technology, and concepts; risk assessment, team building, development of Concept of Operations, and acquisition strategies; establishment of high-level requirements and success criteria; the preparation of plans, budgets, and schedules essential to the success of a service line or project; and the establishment of control systems to ensure performance to those plans and alignment with current Agency strategies.
Formulation Authorization Document (FAD). The document approved by the DA to authorize the formulation of a project whose goals will fulfill part of the Agency's IT Strategic Plan and formulate a project plan.
Governing Body. The board that has responsibility for the oversight of service lines and projects, conducting reviews, and making recommendations to the Decision Authority on the service line or project readiness to transition to the next phase of their respective life cycle.
Implementation. The execution of approved plans for the development and operation of the service line / project, and the use of control systems to ensure performance to approved plans and continued alignment with the Agency's goals.
Increment. A useful portion of a product that is additive to prior increments and thoroughly verified to ensure all increments work together.
Incremental Development. The incremental build model is a method of software development where the product is designed, implemented, and tested incrementally (a little more is added each time) until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements.
Incremental Release. A useful deployment or release of a partially built product, such as a Minimally Viable Product (MVP) or Minimally Marketable Product (MMP), that still provides value to the customer and affords an opportunity for the development team to solicit customer that will inform the features or design of future release increments.
Independent Assessment (IA). The process that includes reviews, evaluations, audits, analysis oversight, and investigations. Assessments are independent to the extent the involved personnel apply their expertise impartially and without any conflict of interest or inappropriate interference or influence, particularly from the organization(s) being assessed.
Information System. A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
Information Technology (IT). Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by an executive Agency. IT also includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer; software; firmware; and similar procedures, services (including support services), and related resources, but does not include any equipment acquired by a Federal contractor incidental to a Federal contract.
Initiative. An effort intended to achieve stated objectives, such as improving performance, reducing costs, or analyzing capabilities. An initiative does not yield a new or revised product, system, or service. Initiatives consume resources and may have associated cost. An initiative has a beginning date and end date but has no required reviews.
Interface Control Document. Establishes and defines the detailed interface between two or more systems, end products, system elements, or configuration items. It is developed to control the defined interface early in the life cycle to reduce design changes due to poorly identified, managed, or controlled interfaces and is modified to reflect the system decommissioning.
Investment. Resources, usually funding, along with a decision on how to apply those resources that results in a capability, product, or service that helps NASA achieve its Mission. Generally, the benefits of an investment exceed the cost of the investment.
Iteration. A repeated cycle during which a product development team designs, develops, and tests features, leading to a releasable product. In traditional product development frameworks, an iteration may or may not be a fixed duration. However, in Agile frameworks, the term is often used synonymously with the term "sprint" to mean a short, fixed-duration timebox during which Agile teams deliver incremental customer value while working toward a product release.
IT Authority. Refers to portfolio investment insight and oversight, EA compliance, and cybersecurity compliance. The NASA CIO's IT Authority is to provide governance and processes that enable the CIO to have insight and influence on all IT investments.
IT Program Authority. Refers to the oversight, implementation, and operations of IT services that are delivered by the NASA CIO or delegate. NASA CIO program authority applies to all IT investments.
Key Decision Point. The event at which the DA determines the readiness of a service line / project to progress to the next phase of the life cycle (or to the next KDP).
Lessons Learned. The significant knowledge or understanding gained through past or current service lines and projects that is documented and collected to benefit current and future efforts.
Life Cycle Cost (LCC). The total of the direct, indirect, recurring, nonrecurring, and other related expenses both incurred and estimated to be incurred in the design, development, verification, production, deployment, operation, maintenance, support, closeout, and disposal of a service line / project.
Major IT Investment. A system or acquisition requiring special management attention because of its importance to the mission or function of the Agency, a component of the Agency, or another organization; is for financial management and obligates more than $20M annually; has significant program or policy implications; has high executive visibility; has high development, operating, or maintenance costs; is funded through other than direct appropriations; or is defined as major by the Agency's capital planning and investment control process.
Minimally Marketable Product (MMP). Defines the minimal set of features, capabilities, and service requirements that will meet the needs of the customer and that will have an acceptable cost break-even point for a service line. The cost break-even point is a point in time when the estimated unit cost to sustain the service and the estimated unit price that customers are willing to pay for the solution are equal (minus approved investment costs).
Minimally Viable Product (MVP). A production solution (i.e., the first release of a product or service) that meets the minimum capabilities needed for customers to recognize value and for a service line to learn from its use so that it can be improved in subsequent releases.
Mission Directorate. A primary implementer of a NASA mission area. Each Mission Directorate is led by an Associate Administrator who leads their respective mission area. Listed in the order they appear on the NASA organizational chart, the current Mission Directorates are as follows: Aeronautics, Exploration Systems, Science, Space Operations, Space Technology.
Mission Support Office. Headquarters organizations that establish and disseminate policy and leadership strategies within assigned areas of responsibility in support of all NASA programs and activities. Refer to NPD 1000.3 for the list of offices included in this designation. As used in this document, the term refers to any Headquarters non-Mission Directorate office that initiates a program or project.
Normal Changes. Changes that require review and approval with approval authority based on risk and impact.
Operations. The management of IT products, system, and services to provide high-quality, cost-effective capabilities.
Operations Concept (OpsCon). Developed over the life cycle, a detailed description of the operational boundaries, incident and performance/capacity monitoring systems and procedures, security controls, and related procedures for transition from development to operations for the Maintenance Phase.
Organizational Summary. The document approved by the DA to authorize the formulation of a service line whose goals will fulfill part of the Agency's IT Strategic Plan and the formulation of a service line plan.
Phase. A grouping of work that is part of a service line or project life cycle that has a defined beginning and end.
Pilot. A full-feature product, system, or service deployed into the production environment as an experimental trial to a limited user base, with all relevant IT system security controls in place, including an Authorization to Operate (ATO).
Plan of Action and Milestones (POA&M). A corrective action plan for tracking and planning the resolution of information cybersecurity weaknesses. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones.
Pre-Formulation. The study of a broad range of product, system, or service-enabling concepts that align to the service line objectives and the identification of project structures, governance tailoring, and estimated funding requirements. This phase may include a Technology Development (TD) effort.
Preliminary. In the context of this document, preliminary implies that the product has received initial review in accordance with Center best practices. The content is considered correct, though some to be determined items may remain. All approvals required by Center policies and procedures have been obtained. Major changes are expected.
Procedural Requirement. Requirements levied on a lower organizational level by a higher organizational level.
Product. An artifact that is produced to meet a need, is quantifiable, and can be either an end item in itself or a component item. In the context of IT, a product can be software, hardware, infrastructure, data, knowledge artifacts, project artifacts, systems, or systems-of-systems.
Product Management. The integration of people, data, processes, and systems to create, maintain, and evolve a product, system, or service through its life cycle.
Product Scope. The features and functions that characterize a product, system, service, or result.
Project. An IT project is a specific investment identified in a Service Line Plan having defined requirements, a LCC, a beginning, and an end. A project has a management structure and is planned, executed, and controlled according to a formal methodology and governed through a defined series of life cycle reviews. A project yields a new or revised product, system, or service that directly addresses NASA's strategic goals.
Project Plan. The document that establishes the project's baseline for implementation, signed by the responsible Service Line Deputy Director, Project Manager, and the customer, if required.
Project Team. All participants in project life cycle phases. This includes all direct reports and others that support meeting project responsibilities.
Proof of Concept (PoC). An analytical and experimental demonstration of hardware/software concepts that may or may not be incorporated into subsequent development and/or operational units. The Proof of Concept (PoC) should clearly state what it is to be proven and to what degree.
Prototype. A prototype is used to test the viability or usefulness of a product, service, system, or subsystem and demonstrates the technology in a way that the customer or beneficiary can visualize the experience of using the technology or system. It is intended to identify, demonstrate, and evaluate the key management, policy, technology, and cost implications of a desired product, system, or service. A prototype is intended for a fixed and limited duration to capture lessons or knowledge for possible implementation. It operates within a test environment and is not a full-feature product, system, or service.
Rebaseline. A change to a service line or project's approved requirements/scope, schedule, budget, or a combination of all three factors that are be controlled through a formal approval and monitoring process.
Release. One or more components of one or more products, systems, or services that are intended to be put into production at the same time.
Request for Action. A type of comment form that reviewers submit during life cycle reviews to capture their comments, concerns, and/or issues.
Requirements Specification. The document that specifies the agreed-upon user, functional, non-functional, security, system interface, regulatory, and performance requirements for the product, system, service, or software development and includes a sound process for the allocation and control of requirements throughout all levels.
Requirements Traceability Matrix (RTM). The traceability of the requirements through the RS, DS, and Test Plan and Procedures to ensure they remain traceable and verifiable through the development life cycle.
Review Item Discrepancy (RID). A type of comment form that reviewers submit during life cycle reviews to capture their comments, concerns, and/or issues.
Risk. The combination of the probability that a service line or project will experience an undesired event (some examples include a cost overrun, schedule slippage, malicious activities, or failure to achieve a needed technological breakthrough or success criteria) and the consequences, impact, or severity of the undesired event, were it to occur. Both the probability and consequences may have associated uncertainties.
Risk Assessment. An evaluation of a risk item that determines:
• what can go wrong.
• how likely is it to occur.
• what the consequences are.
• what the uncertainties are that are associated with the likelihood and consequences, and
• what the mitigation plans are.
Schedule Baseline. The approved version of the project's schedule.
Scope. The sum of the products, services, and results to be provided as a project.
Scope Baseline. The approved version of a project's goals and objectives, scope statement, work breakdown structure (WBS) and its associated WBS dictionary, requirements, and MVP and/or MMP definition.
Service. A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. The term 'service' is sometimes used as a synonym for core service, IT service, or service package.
Service Line (SL). Logical grouping of interrelated service offerings that are managed together to coordinate and execute planning, service delivery and technical solutions in alignment with OCIO strategic roadmap and customer needs.
Service Line Architecture. Use of a common framework and methodology to describe the target capability/service environment (including components such as people, systems, processes, information/data, and their inter-relationships) for a particular IT service line (as a segment of the EA) and the transition plan to move the current state to that target. Service line architecture includes enterprise and Center instances of service line capabilities.
Service Line Commitment Agreement (SCA). An agreement between the NASA CIO for Strategy and the Service Line Director to provide funding commitment for instantiation of the service line.
Service Line Plan. An agreement between the NASA CIO for Strategy and the Service Line Deputy Director that establishes the service line's baseline, management controls, goals, objectives, and risks. The Service Line Plan is updated and approved throughout the service line cycle.
Sprint. A short, fixed-duration timebox during which Agile teams deliver incremental customer value while working toward a product release. Often used synonymously with the term "iteration."
Stakeholder. An individual or organizational customer having an interest (or stake) in the outcome or deliverable of a service line or project.
Standard Changes. Low risk changes that are performed frequently. They are approved through the development, review, and approval of a specific instance of a change that can be described in general terms and applied to specific changes in daily use.
Success Criteria. Specific accomplishments that need to be satisfactorily demonstrated to meet the objectives of a life cycle review so that a service line / project can progress further in the life cycle.
System. The combination of elements that function together to produce the capability required to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose.
System Architecture. Focuses on structure in systems and system elements. System architecture addresses the architectural principles, standards concepts, properties, and characteristics of the system-of-interest. System architecture could include: platform services and logical/physical technology components; applications as groups of capabilities that provide key business functions and manage the data assets; enterprise's major types and sources of data, logical data assets, physical data assets, and data management resources.
Systems Engineering (SE). A disciplined approach for the definition, implementation, integration, and operation of a system (including products, systems, or services). The emphasis is on achieving stakeholder functional, physical, and operational performance requirements in the intended use environments over planned life within cost and schedule constraints. Systems engineering includes the engineering processes and technical management processes that consider the interface relationships across all elements of the system, other systems, or as a part of a larger system.
Systems Engineering Review. Serves as a measure of a project's progress towards identified project goals/objectives and maturity of project work products.
Tailoring. The process used to scale the prescribed requirements to accommodate the needs of a service line or project. The tailoring process results in the completion of the Compliance Matrix, found in Appendix C of this NPR.
Technology Development (TD). IT Technology Development matures a particular technology or set of related technologies and is managed within the project life cycle (Pre-Formulation), to the point where it is ready to transition to the IT project Formulation Phase.
Termination Review. A review initiated by the DA for the purpose of securing a recommendation as to whether to continue or terminate a service line or project. Failing to stay within the parameters or levels specified in controlling documents will result in consideration of a Termination Review.
Test Plan. Documentation that demonstrates the traceability of test cases/scenarios to requirements and design (verification) and describes user acceptance testing (validation).
Unique IT Services. Services that are implemented for a defined group of users at a level lower than the Enterprise or Center level (e.g., a department, mission directorate, mission program, IT program, project, or team).
Validation. The process of showing proof that the product accomplishes the intended purpose based on user/top-level requirements. May be determined by a combination of test, analysis, demonstration, and inspection.
Verification. Proof of compliance with and traceability to product, system, and/or service requirements. Verification may be determined by a combination of test, analysis, demonstration, and inspection. Answers the question, "Did I build the product right?"
Waiver. A documented authorization releasing a service line or project from meeting a requirement after the requirement is put under configuration control.
Wave. A specific sequence in a multi-sequenced deployment of a product, system, or service.
Wave Deployment. Multi-sequenced deployment of a product, system, or service to pre-defined groups of users (e.g., Center by Center, Groups of Centers, User Roles).
| TOC | ChangeLog | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppenidxE | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |
This document does not bind the public, except as authorized by law or as incorporated into a contract. 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: https://nodis3.gsfc.nasa.gov.