A.1 Activity:
(1)
Any of the project components or research functions that are executed
to deliver a product or service or provide support or insight to mature technologies.
(2) A set of tasks that describe the technical effort to accomplish a process
and help generate expected outcomes.
A.2 Advanced Technology Development:
ATD is one of four interrelated NASA product lines.
ATD programs and projects are investments that produce entirely new capabilities or
that help overcome technical limitations of existing systems. ATD is seen
as a bridge between BAR and actual application in NASA, such as FS&GS projects
or elsewhere. ATD projects typically fall within a Technology Readiness Level (TRL)
range of 4 to 6.
A.3 Baseline:
An agreed-to set of requirements, designs, or documents that will have changes
controlled through a formal approval and monitoring process.
A.4 Basic and Applied Research:
Research whose results expand the knowledge base, provide scientific and technological
breakthroughs that are immediately applicable, or evolve into an advanced
technology development (ATD). Basic research addresses the need for knowledge,
while applied research directs this new knowledge toward a practical application.
A.5 Component Facilities:
Complexes that are geographically separated from the NASA Center or institution
to which they are assigned.
A.6 Contractor:
For the purposes of this NPR, a "contractor" is an individual, partnership, company,
corporation, association, or other service having a contract with the Agency for
the design, development, manufacture, maintenance, modification, operation,
or supply of items or services under the terms of a contract to a program or
project within the scope of this NPR. Research grantees, research contractors,
and research subcontractors are excluded from this definition.
A.7 Critical Event
(also referred to as a Key Event in this NPR): An event that requires
monitoring in the projected life cycle of a product that will generate critical
requirements that would affect system design, development, manufacture, test,
and operations (such as with an MOE, MOP, Technical Performance Measure (TPM),
or KPP).
A.8 Customer:
The organization or individual that has requested a product and will receive the
product to be delivered. The customer may be an end user of the product, the
acquiring agent for the end user, or the requestor of the work products from
a technical effort. Each product within the system hierarchy has a customer.
A.9 Decision Authority:
The Agency's responsible individual who authorizes the transition at a KDP to
the next life-cycle phase for a program/project.
A.10 Designated Governing Authority:
The management entity above the program, project, or
activity level with technical oversight responsibility.
A.11 Enabling Products:
The life-cycle support products and services (e.g., production, test, deployment,
training, maintenance, and disposal) that facilitate the progression and use
of the operational end product through its life cycle. Since the end product
and its enabling products are interdependent, they are viewed as a system.
Project responsibility thus extends to responsibility for acquiring services
from the relevant enabling products in each life-cycle phase. When a suitable
enabling product does not already exist, the project that is responsible for
the end product can also be responsible for creating and using the enabling
product.
A.12 Entry Criteria:
Minimum accomplishments each project needs to fulfill to enter into the
next life-cycle phase or level of technical maturity.
A.13 Establish (with respect to each process in Chapter 3)
The act of developing policy, work instructions or procedures to implement process activities.
A.14 Exit Criteria
Specific accomplishments that should be satisfactorily demonstrated before
a project can progress to the next product-line life-cycle phase.
A.15 Expectation:
Statements of needs, desires, capabilities and wants that are not expressed
as a requirement (not expressed as a "shall" statement) is to be referred
to as an "expectation." Once the set of expectations from applicable stakeholders
is collected, analyzed, and converted into a "shall" statement, the "expectation"
becomes a "requirement." Expectations can be stated in either qualitative
(nonmeasurable) or quantitative (measurable) terms. Requirements are always
stated in quantitative terms. Expectations can be stated in terms of functions,
behaviors, or constraints with respect to the product being engineered or
the process used to engineer the product.
A.16 Flight Systems and Ground Support
FS&GS is one of four interrelated NASA product
lines. FS&GS projects result in the most complex and visible of NASA investments.
To manage these systems, the Formulation and Implementation phases for FS&GS
projects follow the NASA project life-cycle model consisting of phases A (Concept
Development) through F (Closeout). Primary drivers for FS&GS projects
are safety and mission success.
A.17 Formulation Phase
The first part of the NASA management life cycle defined in NPR 7120.5 where
system requirements are baselined, feasible concepts are determined, a system
definition is baselined for the selected concept(s), and preparation is made
for progressing to the Implementation phase.
A.18 Implementation Phase
The part of the NASA management life cycle defined in NPR 7120.5 where the
detailed design of system products is completed and the products to be deployed
are fabricated, assembled, integrated and tested; and the products are deployed
to their customers or users for their assigned use or mission.
A.19 Institutional Projects:
Projects that build or maintain the institutional infrastructure to support
other NASA product lines.
A.20 Information Systems and Technology Projects:
All NASA projects for or including the development,
modernization, enhancement, or steady-state operations of information systems and
technologies. This includes projects for or containing computer and/or communications
systems, ancillary equipment, hardware, software applications, firmware, or
networks for the generation, processing, storage, access, manipulation, exchange
or safeguarding of information.
A.21 Iterative:
Application of a process to the same product or set of products to correct a discovered
discrepancy or other variation from requirements. (See "recursive" and "repeatable.")
A.22 Key Decision Point
The event at which the Decision Authority determines the readiness of a program/project to
progress to the next phase of the life cycle (or to the next KDP).
A.23 Key Event:
See Critical Event.
A.24 Key Performance Parameters
Those capabilities or characteristics (typically engineering-based or related
to safety or operational performance) considered most essential for successful
mission accomplishment. Failure to meet a KPP threshold can be cause for the
project, system, or advanced technology development to be reevaluated or terminated
or for the system concept or the contributions of the individual systems to
be reassessed. A project's KPPs are identified and quantified in the project
baseline. (See Technical Performance Parameter.)
A.25 Logical Decomposition
The decomposition of the defined technical requirements by functions, time,
and behaviors to determine the appropriate set of logical models and related
derived technical requirements. Models may include functional flow block diagrams,
timelines, data control flow, states and modes, behavior diagrams, operator
tasks, and functional failure modes.
A.26 Maintain
(with
respect to establishment of processes in Chapter 3): The act of planning the
process, providing resources, assigning responsibilities, training people,
managing configurations, identifying and involving stakeholders, and monitoring
process effectiveness.
A.27 Measure of Effectiveness
A measure by which a stakeholder's expectations will be judged in assessing
satisfaction with products or systems produced and delivered in accordance
with the associated technical effort. The MOE is deemed to be critical to
not only the acceptability of the product by the stakeholder but also critical
to operational/mission usage. An MOE is typically qualitative in nature or
not able to be used directly as a "design-to" requirement.
A.28 Measure of Performance:
A quantitative measure that, when met by the design solution, will help
ensure that an MOE for a product or system will be satisfied. These MOPs are
given special attention during design to ensure that the MOEs to which they
are associated are met. There are generally two or more measures of performance
for each MOE.
A.29 Other Interested
Parties:
A subset of "stakeholders," other interested parties are groups
or individuals that are not customers of a planned technical effort but may
be affected by the resulting product, the manner in which the product is realized
or used, or have a responsibility for providing life-cycle support services.
A subset of "stakeholders." (See Stakeholder.)
A.30 Peer Review:
Independent evaluation by internal or external subject matter experts who
do not have a vested interest in the work product under review. Peer reviews
can be planned, focused reviews conducted on selected work products by the
producer's peers to identify defects and issues prior to that work product
moving into a milestone review or approval cycle.
A.31 Process:
A set of activities used to convert inputs into desired outputs to generate expected
outcomes and satisfy a purpose.
A.32 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).
A.33 Product-Based WBS Model:
See WBS model.
A.34 Product Realization:
The act of making, buying, or reusing a product, or the assembly and integration of
lower level realized products into a new product, as well as the verification and
validation that the product satisfies its appropriate set of requirements and
the transition of the product to its customer.
A.35 Program
A strategic investment by a mission directorate (or mission support office)
that has defined goals, objectives, architecture, funding level, and a management
structure that supports one or more projects.
A.36 Program Commitment Agreement
The contract between the Administrator and the cognizant
Mission Directorate Associate Administrator (MDAA) or Mission Support Office
Director (MSOD) for implementation of a program.
A.37 Project
(1) 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. (2) A unit of work performed in
programs, projects, and activities.
A.38 Realized Product:
The desired output from the application of the four Product Realization
Processes. The form of this product is dependent on the phase of the product-line
life cycle and the phase exit criteria.
A.39 Recursive:
Value is added to the system by the repeated application of processes to design next
lower layer system products or to realize next upper layer end products within
the system structure. This also applies to repeating application of the same
processes to the system structure in the next life-cycle phase to mature the
system definition and satisfy phase exit criteria.
A.40 Relevant Stakeholder
See Stakeholder.
A.41 Repeatable:
A characteristic of a process that can be applied to products at any level of
the system structure or within any life-cycle phase.
A.42 Requirement
The agreed upon need, desire, want, capability, capacity, or demand for personnel,
equipment, facilities, or other resources or services by specified quantities
for specific periods of time or at a specified time expressed as a "shall"
statement. Acceptable form for a requirement statement is individually clear,
correct, feasible to obtain, unambiguous in meaning, and can be validated
at the level of the system structure at which stated. In pairs of requirement
statements or as a set, collectively, they are not redundant, are adequately
related with respect to terms used, and are not in conflict with one another.
A.43 Risk:
The combination of the probability that a program or project will experience an undesired
event (some examples include a cost overrun, schedule slippage, safety mishap,
health problem, malicious activities, environmental impact, failure to achieve
a needed scientific or technological breakthrough or mission 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.
(Reference 7120.5.)
A.44 Software
As defined in NPD 2820.1, NASA Software Policy.
A.45 Specification
A document that prescribes, in a complete, precise, verifiable manner, the
requirements, design, behavior, or characteristics of a system or system component.
A.46 Stakeholder
A group or individual who is affected by or is in some way accountable for
the outcome of an undertaking. The term "relevant stakeholder" is a subset
of the term "stakeholder" and describes people or roles that are designated
in a plan for stakeholder involvement. Since "stakeholder" may describe a
very large number of people, a lot of time and effort would be consumed by
attempting to deal with all of them. For this reason, "relevant stakeholder"
is used in most practice statements to describe the people identified to contribute
to a specific task. There are two main classes of stakeholders. See "customers"
and "other interested parties."
A.47 Success Criteria
Specific accomplishments that must be satisfactorily demonstrated to meet
the objectives of a technical review so that a technical effort can progress
further in the life cycle. Success criteria are documented in the corresponding
technical review plan.
A.48 Surveillance-Type Projects:
A project where prime or external contractors do the majority
of the development effort that requires NASA oversight.
A.49 System
(a) The combination of elements that function together to produce the capabil-ity to
meet a need. The elements include all hardware, software, equipment, facilities,
personnel, processes, and procedures needed for this purpose. (Refer to NPR 7120.5.)
(b) The end product (which performs operational functions) and enabling products (which
provide life-cycle support services to the operational end products) that
make up a system. (See WBS definition.)
A.50 Systems Approach
The application of a systematic, disciplined engineering approach that is
quantifiable, recursive, iterative, and repeatable for the development, operation,
and maintenance of systems integrated into a whole throughout the life cycle of
a project or program.
A.51 Systems Engineering Engine:
The SE model shown in Figure 3-1 provides the 17 technical processes and their
relationship with each other. The model is called an "SE engine" in that the
appropriate set of processes are applied to the products being engineered
to drive the technical effort.
A.52 Systems Engineering Management Plan
The SEMP identifies the roles and responsibility interfaces
of the technical effort and how those interfaces will be managed. The SEMP
is the vehicle that documents and communicates the technical approach, including
the application of the common technical processes; resources to be used; and
key technical tasks, activities, and events along with their metrics and success
criteria.
A.53 System Safety Engineering
The application of engineering and management principles, criteria, and techniques
to achieve acceptable mishap risk, within the constraints of operational effectiveness
and suitability, time, and cost, throughout all phases of the system life
cycle.
A.54 System Structure
A system structure is made up of a layered structure of product-based
WBS models. (See WBS definition.)
A.55 Tailoring
The documentation and approval of the adaptation of the process and approach to
complying with requirements underlying the specific program or projects. Tailoring
considerations include system size and complexity, level of system definition detail,
scenarios and missions, constraints and requirements, technology base, major
risk factors, and organizational best practices and strengths. Critical project
considerations (e.g., public safety, security, litigation exposures) may preclude
tailoring out required process activities, regardless of cost, manpower available,
or other considerations. (From Systems Engineering Fundamentals, Defense Acquisition
University, January 2001.)
A.56 Technical Performance Measures:
The set of critical or key performance parameters that are monitored
by comparing the current actual achievement of the parameters with that anticipated
at the current time and on future dates. Used to confirm progress and identify
deficiencies that might jeopardize meeting a system requirement. Assessed
parameter values that fall outside an expected range around the anticipated
values indicate a need for evaluation and corrective action. Technical performance
measures are typically selected from the defined set of Measures of Performance (MOPs).
A.57 Technical Team:
A group of multidisciplinary individuals with appropriate domain knowledge,
experience, competencies, and skills assigned to a specific technical task.
A.58 Technology Readiness Level
Provides a scale against which to measure the maturity of
a technology. TRLs range from 1, Basic Technology Research, to 9, Systems Test,
Launch and Operations. Typically, a TRL of 6 (i.e., technology demonstrated
in a relevant environment) is required for a technology to be integrated into
an SE process.
A.59 Technical Risk:
Risk associated with the achievement of a technical goal, criterion, or objective.
It applies to undesired consequences related to technical performance, human
safety, mission assets, or environment.
A.60 Transition:
The act of delivery or moving of a product from the location where the product
has been implemented or integrated, as well as verified and validated, to
a customer. This act can include packaging, handling, storing, moving, transporting,
installing, and sustainment activities.
A.61 Transition Process
In the context of this SE NPR, the Transition Process transfers a product to
a customer higher in the system structure for assembly and integration into
a higher level product or to the intended end use customer.
A.62 Validation (of a product):
Proof that the product accomplishes the intended purpose.
Validation may be determined by a combination of test, analysis, and demonstration.
A.63 Validated Requirements
A set of requirements that are well-formed (clear and un-ambiguous), complete
(agrees with customer and stakeholder needs and expectations), consistent
(conflict free), and individually verifiable and traceable to a higher-level
requirement or goal.
A.64 Verification (of a product>):
Proof of compliance with specifications. Verification
may be determined by test, analysis, demonstration, and inspection.
A.65 Waiver:
A documented agreement intentionally releasing a program or project from meeting a requirement.
(Some Centers use deviations prior to Implementation and waivers during Implementation).
A.66 WBS Model:
Model that describes a system that consists of end products and their subsystems
(perform the operational functions of the system), the supporting or enabling
products (for development; fabrication, assembly, integration, and test; operations;
sustainment; and end-of-life product disposal or recycling), and any other
work products (plans, baselines) required for the development of the system.
See the example product-based WBS for an aircraft system and one of its subsystems
(navigation subsystem) below:
Figure A-1 Product-Based WBS Model Example