---

---

A

• Accident - An unplanned event or series of events that results in death, injury, occupational illness, or damage to or loss of equipment, property, or damage to the environment; a mishap.  [IEEE 1228]

• Acquirer - The entity or individual who specifies the requirements and accepts the resulting software products.  The acquirer is usually NASA or an organization within the Agency, but can also refer to the Prime contractor - sub-contractor relationship as well.

• Audit - An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria.  [IEEE 610.12]

---

B

• Baseline - A specification or product that has been reviewed formally and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

• Bug - A design flaw that will result in symptoms exhibited when an object is subjected to an appropriate test.  [Pham 2000]

---

C

• Certification - The process of formally verifying that a system, software subsystem, or computer program is capable of satisfying its specified requirements in an operational environment for a defined period of time.  This includes any requirements for safing the system upon the occurrence of failures with potential safety impacts.

• Commercial Off-The-Shelf (COTS) - Please see the definition under Off-The-Shelf Software.

• Configuration Management (CM) - A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.  [IEEE 610.12]

---

D

• Defect - A product anomaly.  [IEEE Standard 610.12-1990]

---

E

• Engineering Peer Review (EPR) - A focused, in-depth technical review that supports the evolving design and development of a product subsystem or discipline area [GPG 8700.6].  The purpose of an EPR is to add value and reduce risk through expert knowledge infusion, confirmation of approach, and specific recommendations.  An EPR provides a penetrating examination of design, analysis, integration, test and operational details, drawings, processes and data.

---

F

• Failure - Non-performance or incorrect performance of an intended function of a product.  A failure is often the manifestation of one or more faults.

• Failure Modes And Effects Analysis (FMEA) - A bottom-up systematic, inductive, methodical analysis performed to identify and document all identifiable failure modes at a prescribed level and to specify the resultant effect of the modes of failure.

• Fault - An inherent defect in a product that may or may not ever manifest, such as a bug in software code.

• Fault Tree Analysis (FTA) - An analytical technique, whereby an undesired system state is specified and the system is then analyzed in the context of its environment and operation to find all credible ways in which the undesired event can occur.

• Fault Detection, Isolation, And Recovery (FDIR) -
  • Detection:  The ability to discover faults; the process of determining that a fault has occurred.
  • Isolation:  The process of determining the location or source of a fault.
  • Recovery:  A process of overcoming a fault without permanent reconfiguration.

• Finding - Non-compliance to a requirement, procedure, standard, or specification.

• Firmware - The combination of a hardware device and computer instructions and/or computer data that reside as read-only software on the hardware device.

• Functional Configuration Audit (FCA) - An audit conducted to verify that the development of a configuration item has been completed satisfactorily, that the item has achieved the performance and functional characteristics specified in the functional or allocated configuration identification, and that its operational and support documents are complete and satisfactory.

• Functional Requirements - Functional requirements define what the system or subsystem must do to fulfill its mission, including timing and performance requirements.  All requirements that will be expressed in the system, rather than in the process to create the system, are functional requirements.

---

G

• Government Off-The-Shelf (GOTS) - Please see the definition under Off-The-Shelf Software.

---

H

• Hazard - Existing or potential condition that can result in, or contribute to, a mishap or accident.

• Hazard Control - Means of reducing the risk of exposure to a hazard.  This includes design or operational features used to reduce the likelihood of occurrence of a hazardous effect or the severity of the hazard.

• Hazard Mitigation - Any action that reduces or eliminates the risk from hazards.

---

I

• Independent Verification and Validation (IV&V) - Verification and validation performed by an organization that is technically, managerially, and financially independent.  As a part of Software Assurance, IV&V plays a role in the overall NASA software risk mitigation strategy applied throughout the life cycle to improve the safety and quality of software.

• Insight - Surveillance mode requiring the monitoring of acquirer-identified metrics and contracted milestones.  Insight is a continuum that can range from low intensity, such as reviewing quarterly reports, to high intensity, such as performing surveys and reviews.

• Integrated Independent Review (IIR) - One of a series of system-level reviews conducted at critical project/product milestones in accordance with GPG 8700.4.  IIRs build upon the results of a robust set of engineering peer reviews.  IIR examples include System Concept review (SCR), Critical Design Review (CDR), and Mission Operations Review (MOR).

---

J

• Definitions to be determined

---

K

• Definitions to be determined

---

L

• Definitions to be determined

---

M

• Memorandum Of Agreement (MOA) - A written agreement between two or more parties that defines the roles and responsibilities of each party with respect to the collaborative efforts of a particular program/project.  A MOA is sometimes called a Memorandum of Understanding (MOU).

• Mission-Critical - Item or function that must retain its operational capability to assure no mission failure (i.e., for mission success).

• Modified Off-The-Shelf (MOTS) - Please see the definition under Off-The-Shelf Software.

---

N

• Definitions to be determined

---

O

• Observation - A statement of fact (positive or negative) based on objective evidence.

• Off-The-Shelf Software - Ready-made software used "as-is" within a system.
  • COTS (Commercial Off-The-Shelf) software refers to purchased software such as operating systems, libraries, or applications.
  • MOTS (Modified Off-The-Shelf) software is typically a COTS product whose source code can be modified.
  • GOTS (Government Off-The-Shelf) software is typically developed by the technical staff of the government agency for which it is created.

• Oversight - Surveillance mode that is in line with the supplier's processes.  The acquirer retains and exercises the right to concur or non-concur with the supplier's decisions.  Non-concurrence must be resolved before the supplier can proceed.  Oversight is a continuum that can range from low intensity, such as acquirer concurrence in reviews (e.g., PDR, CDR), to high intensity oversight, in which the customer has day-to-day involvement in the supplier's decision-making process (e.g., software inspections).

---

P

• Physical Configuration Audit (PCA) - An audit conducted to verify that one or more configuration items, as built, conform to the technical documentation that defines it [based on IEEE 610.12 IEEE Standard Glossary of Software Engineering Terminology].

• Preliminary Hazard Analysis (PHA) - A gross study of the initial system concepts.  It is used to identify all of the energy sources that constitute inherent hazards. The energy sources are examined for possible accidents in every mode of system operation.  The analysis is also used to identify methods of protection against all of the accident possibilities.

• Process - A set of interrelated activities that transform inputs into outputs.  [ISO / IEC 12207, Software life cycle processes]

• Process Assessment - A systematic examination to determine whether a software process is being performed in accordance with documented plans, procedures, etc.

• Product Assessment - A systematic examination to determine whether a software product meets specified requirements and standards.

• Product Design Lead (PDL) - The manager or leader with overall responsibility for managing the design activity, managing the technical and organizational interfaces identified during design planning, and where required, forming and leading the Product Design Team (PDT).  The term refers to flight project managers, principal investigators, mission managers, instrument managers, software managers, lead engineers, etc.

• Provider - The entities or individuals that design, develop, implement, test, operate, and maintain the software products.  A provider may be a contractor, a university, a separate organization within NASA, or within the same organization as the acquirer.  The term "provider" is equivalent to "supplier" in ISO / IEC 12207, Software life cycle processes.

---

Q

• Definitions to be determined

---

R

• Reliability - The probability of a given system performing its mission adequately for a specified period of time under the expected operating conditions.  [NASA-GB-8719.13]

• Reused Software - Software created for another system that is incorporated into the system under development.

• Risk - The combination of:
  1. the probability (qualitative or quantitative) that a program or project will experience an undesired event and
  2. the consequences, impact, or severity of the undesired event were it to occur.

---

S

• Safety Critical - Any condition, event, operation, process, equipment, or system that possesses the potential of directly or indirectly causing harm to humans, destruction of the system, damage to property external to the system, or damage to the environment.

• Safety Critical Software - Software that resides in a safety-critical system that is a potential hazard cause or contributor, supports a hazard control or mitigation, controls safety-critical functions, or detects and reports 1) fault trends that indicate a potential hazard and /or 2) failures which lead to a hazardous condition.  Analysis of the system should consider software that processes hazardous commands or data, is required to put or keep the system in a safe state, provides information upon which a safety decision is made, is part of a safety subsystem, or that can adversely affect system safety by its failure or anomalous behavior.

• Software - Computer programs, procedures, rules, and associated documentation and data pertaining to the development and operation of a computer system.  Software includes programs and operational data contained in hardware (e.g., firmware, programmable logic, and programmable gate arrays).  This also includes COTS, GOTS, MOTS, reuse, legacy and heritage software products and components.

• Software Assurance (SA) - The planned and systematic set of activities that ensure that software life cycle processes and products conform to requirements, standards, and procedures [IEEE 610.12 IEEE Standard Glossary of Software Engineering Terminology].  For NASA this includes the disciplines of Software Quality (functions of Software Quality Engineering, Software Quality Assurance, Software Quality Control), Software Safety, Software Reliability, Software Verification and Validation, and IV&V.

• Software Availability - The probability that a system has not failed due to a software fault.  [Pham 2000]

• Software Error - The difference between a computed, observed or measured value or condition and the true, specified or theoretically correct value or condition.  [NASA-GB-8719.13]

• Software Fault - An incorrect step, process or data definition in a computer system.  [NASA-GB-8719.13]

• Software Hazard - A hazard caused by incorrect software control of hazardous hardware.  The software might be functioning correctly (according to its requirements) or in a failure mode.

• Software Life Cycle - The period of time that begins when a software product is conceived and ends when the software is no longer available for use.  The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase [IEEE 610.12 IEEE Standard Glossary of Software Engineering Terminology].

• Software Mean Time to Failure - The expected time when the next failure is observed due to software faults.  [Pham 2000]

• Software Quality (SQ) - The discipline of software quality is a planned and systematic set of activities to ensure quality is built into the software. It consists of software quality assurance, software quality control, and software quality engineering.

• Software Quality Assurance (SQA) - The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.

• Software Quality Control - The function of software quality that checks that the project follows its standards, processes, and procedures, and that the project produces the required internal and external (deliverable) products.

• Software Quality Engineering - The function of software quality that assures that quality is built into the software by performing analyses, trade studies, and investigations on the requirements, design, code, and verification processes and results to assure that reliability, maintainability, and other quality factors are met.

• Software Quality Personnel - Personnel responsible for providing SQ support to the Systems Assurance Manager. This includes software quality engineers, Defense Contract Management Agency (DCMA) specialists, or support provided under the Supplier Assurance Contract (SAC). Note: The Systems Assurance Manager may also perform the duties of a software quality person.

• Software Reliability - The discipline of software assurance that:
  1. defines the requirements for software controlled system fault/failure detection, isolation, and recovery;
  2. reviews the software development processes and products for software error prevention and/ or reduced functionality states; and
  3. defines the process for measuring and analyzing defects and defines/ derives the reliability and maintainability factors.

• Software Requirements Traceability Matrix (SRTM) - A tool developed and maintained by software engineering that traces software requirements back to system requirements and forward to design, code, and test.

• Software Safety - The discipline of software assurance that is a systematic approach to identifying, analyzing, tracking, mitigating and controlling software hazards and hazardous functions (data and commands) to ensure safe operation within a system.

• Software Safety Analysis - The application of system safety engineering techniques throughout the software life cycle to ensure that errors that could reduce system safety have been eliminated or controlled to an acceptable level of risk.

• Software Safety Plan (SSP) - A document that details the activities, general relative schedule of needed activities, communication paths and responsibilities for performing software safety activities as part of the systems safety program.  This does not have to be a standalone document, but could be included as part of the systems safety plan or, for small projects, an overall assurance plan.  While it may be written by either the project/program/facility or by the safety personnel within the Center SMA organization(s), both must sign off on it.

• Surveillance - The continuous monitoring and status of an entity and analysis of records to ensure that specified requirements are being met.  Note:  Surveillance can be performed in an insight, oversight, or a combined mode as determined by NASA using a risk-based decision process. [NPR 8735.2, Management of Government Safety and Mission Assurance Surveillance Functions for NASA Contractors]

• System Hazard Analysis - Identification and evaluation of existing and potential hazards and the recommended mitigation for the hazard sources found.  [NPR 8715.3] This includes the verification and validation of the safety functions and hazard controls.

• Systems Assurance Manager (SAM) - Code 300 personnel responsible for supporting the PDL in the coordination of the definition and implementation of a Project Systems Safety and Mission Assurance Program (SSMAP).

---

T

• Definitions to be determined

---

U

• Definitions to be determined

---

V

• Validation - Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use are fulfilled [ISO/IEC 12207, Software life cycle processes.]  In other words, validation ensures that "you built the right thing".

• Verification - Confirmation by examination and provision of objective evidence that specified requirements have been fulfilled [ISO/IEC 12207, Software life cycle processes].  In other words, verification ensures that "you built it right".

---

W

• Definitions to be determined

---

X

• Definitions to be determined

---

Y

• Definitions to be determined

---

Z

• Definitions to be determined