3. ACRONYMS AND DEFINITIONS

3.1 Acronyms and Abbreviations

3.2 Definitions

Accredit: The official acceptance of a software development tool, model, or simulation (including associated data) to use for a specific purpose.

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-subcontractor relationship as well.

Analyze: Review results in-depth, look at relationships of activities, examine methodologies in detail, follow methodologies such as Failure Mode and Effects Analysis, Fault Tree Analysis, trending, and analysis of metrics. Examine processes, plans, products, and task lists for completeness, consistency, accuracy, reasonableness, and compliance with requirements. The analysis may include identifying missing, incomplete, or inaccurate products, relationships, deliverables, activities, required actions, etc.

Approve: When the responsible originating official, or designated decision authority, of a document, report, condition, etc. has agreed, via their signature, to the content and indicates the document is ready for release, baselining, distribution, etc. Usually, there will be one “approver” and several stakeholders who would need to “concur” for official acceptance of a document, report, etc. (for example, the project manager would approve the Software Development Plan, but SMA would concur on it.)

Assess: Judge results against plans or work product requirements. Assess includes judging for practicality, timeliness, correctness, completeness, compliance, evaluation of rationale, etc., reviewing activities performed, and independently tracking corrective actions to closure.

Assure: When software assurance personnel make certain that others have performed the specified software assurance, management, and engineering activities.

Audit: (1) systematic, independent and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which audit criteria are fulfilled (2) independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria (3) independent examination of a software product, software process, or set of software processes to assess compliance with specifications, standards, contractual agreements, or other criteria (4) systematic, independent, documented process for obtaining records, statements of fact, or other relevant information and assessing them objectively, to determine the extent to which specified requirements are fulfilled. Note: An audit can be an internal audit (first-party) or an external audit (second party or a third party), and it can be a combined or integrated audit (combining two or more disciplines). Audit results are a clear indication of whether the audit criteria have been met. (IEEE Definition)

Concur: A documented agreement that a proposed course of action is acceptable.

Condition: (1) measurable qualitative or quantitative attribute that is stipulated for a requirement and that indicates a circumstance or event under which a requirement applies (2) description of a contingency to be considered in the representation of a problem, or a reference to other procedures to be considered as part of the condition (3) true or false logical predicate (4) logical predicate involving one or more behavior model elements (5) Boolean expression containing no Boolean operators.

Configuration Item: An aggregation of hardware, software, or both, that is established and baselined, with any modifications tracked and managed. Examples include requirements document, data block, Use Case, or unit of code.

Confirm: Checks to see that activities specified in the software engineering requirements are adequately done, and evidence of the activities exists as proof. Confirm includes making sure activities are done completely and correctly and have expected content in accordance with approved tailoring.

Deliverable: Report or item that has to be completed and delivered under the terms of an agreement or contract. Products may also be deliverables, e.g., software requirements specifications, detailed design documents. Develop: To produce or create a product or document and to mature or advanced the product or document content.

Ensure: When software assurance or software safety personnel perform the specified software assurance and software safety activities themselves.

Event: (1) occurrence of a particular set of circumstances (2) external or internal stimulus used for synchronization purposes (3) change detectable by the subject software (4) fact that an action has taken place (5) singular moment in time at which some perceptible phenomenological change (energy, matter, or information) occurs at the port of a unit.

Hazard: A state or a set of conditions, internal or external to a system that has the potential to cause harm.

Hazard Analysis: Identification and evaluation of existing and potential hazards and the recommended mitigation for the hazard sources found.

Hazard Control: Means of reducing the risk of exposure to a hazard.

Hazardous Operation/Work Activity: Hazardous Operation/Work Activity. Any operation or other work activity that, without the implementation of proper mitigations, has a high potential to result in loss of life, serious injury to personnel or public, or damage to property due to the material or equipment involved or the nature of the operation/activity itself.

Independent Verification and Validation (IV&V): Verification and validation performed by an organization that is technically, managerially, and financially independent of the development organization. (Source: ISO/IEC/IEEE 24765)

Inhibit: Design feature that prevents the operation of a function.

Maintain: To continue to have; to keep in existence, to stay up-to-date and correct.

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

Monitor: (1) software tool or hardware device that operates concurrently with a system or component and supervises, records, analyzes, or verifies the operation of the system or component; (2) collect project performance data with respect to a plan, produce performance measures, and report and disseminate performance information.

Participate: To be a part of the activity, audit, review, meeting, or assessment.

Perform: Software assurance does the action specified. Perform may include making comparisons of independent results with similar activities performed by engineering, performing audits, and reporting results to engineering.

Product: A result of a physical, analytical, or another process. The item delivered to the customer (e.g., hardware, software, test reports, data), as well as the processes (e.g., system engineering, design, test, logistics) that make the product possible. (Source: NASA-HDBK-8709.22)

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 management structure that initiates and directs one or more projects. A program implements a strategic direction that the Agency has identified as needed to accomplish Agency goals and objectives. (Source: NPR 7120.5)

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. (Source: NPR 7150.2)

Project Manager: The entity or individual who accepts the resulting software products. Project managers are responsible and accountable for the safe conduct and successful outcome of their program or project in conformance with governing Programmatic requirements. This is usually NASA, but can also refer to the Prime contractor-subcontractor relationship as well.

Provider: A person or entity that provides something.

Risk Posture: A characterization of risk based on conditions (e.g., criticality, complexity, environments, performance, cost, schedule) and a set of identified risks, taken as a whole which allows an understanding of the overall risk, or provides a target risk range or level, which can then be used to support decisions being made.

Safe State: A system state in which hazards are inhibited, and all hazardous actuators are in a non-hazardous state. The system can have more than one Safe State.

Safety-Critical: A term describing any condition, event, operation, process, equipment, or system that could cause or lead to severe injury, major damage, or mission failure if performed or built improperly, or allowed to remain uncorrected. (Source NPR 8715.3)

Safety-Critical Software: Software is classified as safety-critical if it meets at least one of the following criteria:

a. Causes or contributes to a system hazardous condition/event,

b. Provides control or mitigation for a system hazardous condition/event,

c. Controls safety-critical functions,

d. Mitigates damage if a hazardous condition/event occurs,

e. Detects, reports, and takes corrective action if the system reaches a potentially hazardous state.

Software: (1) computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system (2) all or a part of the programs, procedures, rules, and associated documentation of an information processing system (3) program or set of programs used to run a computer (4) all or part of the programs which process or support the processing of digital information (5) part of a product that is the computer program or the set of computer programs. The software definition applies to software developed by NASA, software developed for NASA, software maintained by or for NASA, COTS, GOTS, MOTS, OSS, reused software components, auto-generated code, embedded software, the software executed on processors embedded in programmable logic devices, legacy, heritage, applications, freeware, shareware, trial or demonstration software, and open-source software components. (Source: NPR 7150.2)

Software Assurance: The level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life-cycle, and that the software functions in an intended manner.

Software Developer: A person or thing that develops software, based on program/project requirements.

Software Life-Cycle: The period 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.

Software Peer Review: An examination of a software product to detect and identify software anomalies, including errors and deviations from standards and specifications. (Source: IEEE 1028)

Software Safety: The aspects of software engineering, system safety, software assurance and software safety that provide a systematic approach to identifying, analyzing, tracking, mitigating, and controlling hazards and hazardous functions of a system where software may contribute either to the hazard(s) or to its detection, mitigation or control, to ensure safe operation of the system.

Software Validation: Confirmation that the product, as provided (or as it will be provided), fulfills its intended use. In other words, validation ensures that “you built the right thing.” (Source: IEEE 1012)

Software Verification: Confirmation that products properly reflect the requirements specified for them. In other words, verification ensures that “you built it right.” (Source: IEEE 1012)

Supplier: a person or organization that provides something needed, such as a software product or service.

System Safety: Application of engineering and management principles, criteria, and techniques to optimize safety and reduce risks within the constraints of operational effectiveness, time, and cost.

Tailoring: The process used to refine or modify a requirement for a particular project with a justified purpose.

Track: To follow and note the course or progress of the product.