SoftwareAssurance_HelpfulDefinitions

These definitions were taken from NASA Standard 8739.83

Term Definition
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.
Assessment

An objective evaluation of performed processes or products and services against their applicable process descriptions, standards, procedures, and requirements.

Audit An examination of a work product or set of work products performed by a group independent from the developers to assess compliance with specifications, standards, contractual agreements, or other criteria. [Based on IEEE 610.12, IEEE Standard Glossary of Software Engineering Terminology]
Configuration Item An aggregation of hardware, software, or both, that is established and baselined, with any modifications tracked and managed. [Based on IEEE 610.12, IEEE Standard Glossary of Software Engineering Terminology] Examples include requirements document, Use Case, or unit of code.
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.
Independent Verification and Validation (IV&V) Verification and validation performed by an organization that is technically, managerially, and financially independent. IV&V, as a part of software assurance, 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.
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., Preliminary Design Review, Critical Design Review), to high intensity oversight, in which the customer has day-to-day involvement in the supplier's decision-making process (e.g., software inspections).
Peer Review A review of a software work product, following defined procedures, by peers of the producers of the product for the purpose of identifying defects and improvements. [SEI-CMM Software Engineering Institute Capability Maturity Model®]
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]
Process A set of interrelated activities, which transform inputs into outputs. [ISO/IEC 12207, Software life cycle processes]
Process Assurance Activities to assure that all processes involved with the project adhere to plans and comply with the contract and/or any memorandum of agreement/understanding.
Product Assurance Activities to assure that all required plans are documented, and that the plans, software products, and related documentation adhere to plans and comply with the contract and/or any memorandum of agreement/understanding.
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.
Review A process or meeting during which a software product or related documentation is presented to project personnel, customers, managers, software assurance personnel, users or user representatives, or other interested parties for comment or approval. [IEEE 610.12, IEEE Standard Glossary of Software Engineering Terminology] Reviews include, but are not limited to, requirements review, design review, code review, test readiness review. Other types may include peer review and formal review.
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 (Commercial Off the Shelf), GOTS (Government Off the Shelf), MOTS (Modified Off the Shelf), reuse, legacy, and heritage software products and components.
Software Assurance 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 Assurance Program Metrics Metrics related to the activities defined in the Software Assurance Program. Examples include number of reviews/audits planned vs. reviews/audits performed, software assurance effort planned vs. software assurance effort actual, and corrective actions opened vs. corrective actions closed.
Software Assurance Record A record that provides objective evidence of the extent of the fulfillment of the requirements for software quality, safety, reliability, verification and validation, and, when present, IV&V. This includes documentation of the software assurance activities and analyses results.
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 Product Quality A measure of software that combines the characteristics of low defect rates and high user satisfaction.
Software Quality 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. As an attribute, software quality is (1) the degree to which a system, component, or process meets specified requirements; or (2) the degree to which a system, component, or process meets customer or user needs or expectations. [IEEE 610.12, IEEE Standard Glossary of Software Engineering Terminology]
Software Quality Assurance 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 Metrics Metrics are quantitative values that measure the quality of software or the processes used to develop the software, or some attribute of the software related to the quality (e.g., defect density).
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 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.
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]
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.”