Terms Manual Database
Web Resources
View this section on the websiteSee edit history of this section
Post feedback on this section
Unknown macro: {page-info}
Term | Definition |
Audit | A planned, independent and documented assessment to verify compliance to agreed-upon requirements. |
Abstraction | Abstraction captures and represents only those details about an object that are relevant to the current perspective. |
Accredit | The official acceptance of a software development tool, model, or simulation, (including associated data) to use for a specific purpose. (Source: NPR 7150.2- Appendix A) |
Accuracy | The difference between a parameter or variable (or a set of parameters or variables) within a model, simulation, or experiment and the true value or the assumed true value (Definition from source document: NASA-STD-7009, Standard for Models and Simulations.) (Source: NPR 7150.2 - Appendix A) |
Acquirer |
|
Analysis | The post-processing or interpretation of the individual values, arrays, files of data, or execution information. (Source: NPR7150.2 - Appendix A) Also: It is a careful study of something to learn about its parts, what they do, and how they are related to each other. (Source: NPR 7150.2 - Appendix A) Analysis is also a search tag used in this Software Engineering Handbook to designate a subject relationship with Analysis. |
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 |
|
BiCE | Best-in-Class Example. BiCE is also a search tag used in this Software Engineering Handbook to designate a subject relationship with Best-in-Class Example. |
Bidirectional Traceability | Association among two or more logical entities that are discernible in either direction (to and from an entity). (ISO/IEC/IEEE 24765) |
Term | Definition |
Code coverage | The percentage of the software that has been executed (covered) by the test suite. |
Cohesion | A measure of how strongly related each piece of functionality expressed by the source code of a software module is |
Commercial Off-the-Shelf Software | The software product is available for purchase and use without the need to conduct development activities. COTS solutions, as opposed to custom-developed solutions, are typically readily available and ready for use as purchased. |
Computer | A functional unit that can perform substantial computations, including numerous arithmetic operations and logic operations. |
Computer Software Configuration Item | An aggregation of software that is designated for configuration management and treated as a single entity in the configuration management process. |
Computer System | A system containing one or more computers and associated software. (Source: ISO/IEC/IEEE 24765) |
Concur | A documented agreement that a proposed course of action is acceptable. |
Condition |
|
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. |
Contracted Software | Software created for a project by a contractor or subcontractor. |
COTR | Contracting Officer Technical Representative. Works with CO to plan acquisition approach, prepare statement of work, evaluates proposals, determines the technical adequacy of proposed approach, monitor technical implementation. See Topic 7.3 - Acquisition Guidance. |
CSC | Computer Software Component. A functionally or logically distinct part of a computer software configuration item, typically an aggregate of two or more software units (ISO/IEC/IEEE 24765:2010 Systems and software engineering). CSC is a search tag used in this Software Engineering Handbook indicating Class C - Safety-Critical. |
CSCI | Computer Software Configuration Items. An aggregation of software that is designated for configuration management and treated as a single entity in the configuration management process (ISO/IEC/IEEE 24765:2010 Systems and software engineering). |
CSMA | Center OSMA. CSMA is also a search tag used in this Software Engineering Handbook to designate a subject relationship with Center OSMA. |
Cybersecurity | The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability. |
Data | Information for computer processing (e.g., numbers, text, images, and sounds in a form that is suitable for storage in or processing by a computer). |
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. |
Deviation | A documented authorization releasing a program or project from meeting a requirement before the requirement is put under configuration control at the level the requirement will be implemented. (Source: NPR 7150.2 - Appendix A) |
Term | Definition |
Earned Value | The sum of budgeted cost for task and products that have actually been produced (completed or in progress) at a given time in the schedule. (Systems Engr. Handbook) |
Embedded Computer System | A computer system that is part of a larger system and performs some of the requirements of that system. (Source: ISO/IEC/IEEE 24765) |
Embedded Software | Software that is part of a larger system and performs some of the requirements of that system. (Source: ISO/IEC/IEEE 24765) |
Ensure | To secure or guarantee, to make sure or certain. |
Establish and Maintain | Formulation, documentation, use/deployment, and current maintenance of the object (usually a document, requirement, process, or policy) by the responsible project, organization, or individual. |
Event |
|
Freeware | Software that is proprietary and that is available for use at no monetary cost. In other words, freeware may be used without payment but may usually not be modified, re-distributed, or reverse-engineered without the author's permission. |
Function points | The functional user requirements of the software are identified and each one is categorized into one of five types: outputs, inquiries, inputs, internal files, and external interfaces. Once the function is identified and categorized into a type, it is then assessed for complexity and assigned a number of function points. |
Term | Definition |
Glueware | Software created to connect the off-the-shelf software/reused software with the rest of the system. It may take the form of software that modifies interfaces or add missing functionality, "firewalls" that isolate the off-the-shelf software, or software that check inputs and outputs to the off-the-shelf software and may modify to prevent failures. |
GNU | GNU is a recursive acronym for 'GNU's Not Unix' It is a Unix-like computer operating system developed by the GNU Project, composed wholly of free software, is based on the GNU Hurd kernel and is intended to be a complete Unix-compatible software system. |
Government Off-the-Shelf Software | Government Off-the-Shelf Software refers to Government-created software, usually from another project. The software was not created by the current developers (see software reuse). Usually, the source code is included and documentation, including test and analysis results, is available; e.g., the Government is responsible for the Government off-the-shelf (GOTS) software to be incorporated into another system. |
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. |
Heritage | Software products (architecture, code, requirements) written specifically for one project and then, without prior planning during its initial development, found to be useful on other projects. See software reuse. (Source: NPR 7150.2 - Appendix A) |
Term | Definition |
Independent Verification and Validation | Independent Verification and Validation. Verification and validation performed by an organization that is technically, managerially, and financially independent of the development organization. (Source: ISO/IEC/IEEE 24765) The NASA requirements for Independent Verification and Validation are defined in the NASA-STD-8739.8. |
Information Technology | Any equipment or interconnected system(s) or subsystem(s) of equipment that is used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the Agency (reference FAR 2.101). (Source: NPR 2800.1) |
Inhibit | Design feature that prevents the operation of a function. |
Insight | An element of Government surveillance that monitors contractor compliance using Government-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. (Source: NPR 7123.1) |
Iterative | The “application of a process to the same product or set of products to correct a discovered discrepancy or other variation from requirements,” |
Term | Definition |
KDP | Key Decision Point. (NPR 7150.2) Each phase of the NASA Program or Project life cycle is typically marked by a Key Decision Point (KDP), which usually is associated with a prescribed major design review. A KDP is an event wherein the decision authority determines the readiness of a program/project to progress to the next phase of the life cycle. See also gate. (NPR 7150.2) |
Legacy | Software products (architecture, code, requirements) written specifically for one project and then, without prior planning during its initial development, found to be useful on other projects. See software reuse. (Source: NPR 7150.2 - Appendix A) |
Life cycle | (noun) The totality of a program or project extending from formulation through implementation encompassing the elements of design, development, verification, production, operation, maintenance, support and disposal. (NPR 8705.2, Appendix A) life-cycle (hyphenated) is an adjective describing an object (noun) as related to a software life cycle. |
Term | Definition |
Maintain | To continue to have |
Major Engineering/Research Facility | Used in this document to show research, development, test, or simulation facilities representing a significant NASA investment (facilities with a Current Replace Value equal to or greater than 50 million dollars) which contains software that supports programs and projects managed under NPR 7120.5, NPR 7120.7, or NPR 7120.8 and that have a Mission Dependency Index value equal to or greater than 70. |
Mathematical Model | The mathematical equations, boundary values, initial conditions, and modeling data needed to describe the conceptual model (ASME V&V 10). (Definition from source document: NASA-STD-7009, Standard for Models and Simulations.) (Source: NPR 7150.2 - Appendix A) |
Mission Critical | Item or function that should retain its operational capability to assure no mission failure (i.e., for mission success - meeting all mission objectives and requirements for performance and safety). (Source: NPR 8715.3) |
Mobile Application | A mobile application is an application built using native code for the device or a software Web application that is distributed through the device specific marketplace. Web applications presented via a mobile browser are not considered mobile applications. |
Model | A description or representation of a system, entity, phenomena, or process. (Source: NASA-STD-7009) Only for this document, the term "model" refers to models implemented in software. |
Modified Off-the-Shelf Software | When COTS or legacy and heritage software is reused, or heritage software is changed, the product is considered "modified." The changes can include all or part of the software products and may involve additions, deletions, and specific alterations. An argument can be made that any alterations to the code and design of an off-the-shelf software component constitute "modification," but the common usage allows for some percentage (less than 5 percent of the code changes) of change before the off-the-shelf software is declared to be modified off-the-shelf (MOTS) software. Modified Off-the-Shelf Software may include the changes to the application shell or glueware to add or protect against certain features and not to the off-the-shelf software system code directly. When less than 30 percent of the existing code changes, the product can be considered "modified." If more than 30 percent of the code changes or if the new code is added, the software should be considered a new software development. |
Monitor | 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. |
Monte Carlo Method | Monte Carlo methods use random numbers to obtain numerical solutions when analytical methods are too difficult to use. When using Monte Carlo methods with cost models, they are used to simulate the estimated cost distribution. |
Term | Definition |
Off-the-Shelf Software | Software not developed in-house or by a contractor for the specific project now underway. The software is developed for a purpose different from the current project. Used in practice as an umbrella for COTS, GOTS, MOTS, OSS, freeware, shareware, trial software, demonstration software, legacy software, heritage software, and reuse software. |
Open-Source Software | Software where its human-readable source code is made broadly available without cost under an OSS license, which provides conditions for use, reuse, modification/improvement, and redistribution; and often where the software development, management, and planning is done publicly, or easily observable by an individual or organization not previously connected with its open source project. |
Operational Software | Software that has been accepted and deployed, delivered to its customer, or is deployed in its intended environment. (Source: NPR 7150.2 - Appendix A) |
Oversight | Oversight is a surveillance process that implies a more active supervision of a contractor's processes and decision making. Oversight is often used in problem areas. (From the NASA Program and Project Management Handbook (NPR 7120.5 Handbook, February, 2010). |
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. |
Primary Mission Objectives | Outcomes expected to be accomplished, which are closely associated with the reason the mission was proposed, funded, developed, and operated (e.g., objectives related to top-level requirements or their flow down). |
Procedure | Procedure is a search tag used in this Software Engineering Handbook to designate a subject relationship with Procedures. |
Process | Process is a search tag used in this Software Engineering Handbook to designate a subject relationship with Processes. |
Process Asset Library | A collection of process asset holdings that may be used by an organization or project. (Source: CMMI® for Systems Engineering/Software Engineering/Integrated Product and Process Development Supplier Sourcing.) |
Process Asset Library (PAL) | A collection of process asset holdings that can be used by an organization or project. (Definition from source document: CMMI^®^ for- Systems Engineering/Software Engineering/Integrated Product and Process Development Supplier Sourcing.) |
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 technical approach, requirements, funding level, and a management structure that initiates and directs one or more projects. A program defines a strategic direction that the Agency has identified as critical. |
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. They may be performed wholly in-house; by Government, industry, academia partnerships; or through contracts with private industry. |
Provider | A person or entity that provides something. |
Term | Definition |
Records | Records is a search tag used in this Software Engineering Handbook to designate a subject relationship with Records. |
recursive | The repeated application of processes to design next lower layer system products or to realize next upper layer end products within the system structure. |
Relevant Stakeholder | A stakeholder that is identified for involvement in specified activities and is included in a plan. See also Stakeholder. |
Risk Management | An organized, systematic decision-making process that efficiently identifies, analyzes, plans, tracks, controls, communicates, and documents risk to increase the likelihood of achieving program/project goals. (Source: NPR 8715.3) |
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. |
Term | Definition |
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 Compliance Data Package | The safety compliance data package (SCDP) shall document the identification, causes, controls, and verification methods for each hazard. (1999 NASA Dryden document). |
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:
|
Scripts | A sequence of automated computer commands embedded in a program that tells the program to execute a specific procedure (e.g., files with monitoring, logic, or commands used by software to automate a process or procedure). |
Sensitivity Analysis | The study of how the variation in the output of a model can be apportioned to different sources of variation in the model input and parameters. (Definition from source document: NASA-STD-7009, Standard for Models and Simulations.) (Source: NPR 7150.2 - Appendix A) |
Shareware | Software that is available free of charge and often distributed informally for evaluation, after which a fee may be requested for continued use. |
Simulation | The imitation of the behavioral characteristics of a system, entity, phenomenon, or process. (Source: NASA-STD-7009) Only for the purpose of this document, the term "simulation" refers to only those simulations that are implemented in software. |
Software | In this directive, “software” is defined as
|
Software Architecture | The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the properties of those components, and the relationships between them. The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects. |
Software Assurance | The planned and systematic set of activities that ensure that software life cycle processes and products conform to requirements, standards, and procedures. For NASA, this includes the disciplines of Software Quality (functions of Software Quality Engineering, Software Quality Assurance, and Software Quality Control), Software Safety, Software Reliability, Mission Software Cybersecurity Assurance, Software Verification and Validation, and IV&V. |
Software Engineering | Software Engineering. The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, i.e., the application of engineering to software. (Source: ISO/IEC/IEEE 24765) |
Software Item | Source code, object code, control code, control data, or a collection of these items. |
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 Maintenance |
|
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 Peer Review and Inspection | Software Peer Review and Inspection. A visual examination of a software product to detect and identify software anomalies, including errors and deviations from standards and specifications. (Source: IEEE 1028). Refer to NASA-STD-8739.9 for guidelines for software peer reviews or inspections. |
Software Reuse | A software product developed for one use but having other uses or one developed specifically to be usable on multiple projects or in multiple roles on one project. Examples include, but are not limited to, COTS products, acquirer-furnished software products, software products in reuse libraries, and pre-existing developer software products |
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 Suppliers | An organization or individual that enters into an agreement with the acquirer for the supply of a software product or service or individual or organization that enters into a contract with the acquirer for the supply of a software system, software product, or software service under the terms of the contract or an organization or part of an organization or individual that enters into an agreement with the application management organization for the supply of a software product or software service. Software Suppliers includes NASA in-house software development. |
Software Technical Authority | Prior to contract release, verify that the SOW includes the complete flow down of the agency and Center software requirements [recommended practice]. See also Topic 7.3 - Acquisition Guidance. |
Software Unit |
|
Software Validation | 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 | 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) |
Stakeholder | A group or individual affected or in some way accountable for the outcome of an undertaking. |
Static Analysis | The process of evaluating a system or component based on its form, structure, content, or documentation. (Source: ISO/IEC/IEEE 24765) |
Studies | Studies is a search tag used in this Software Engineering Handbook to designate a subject relationship with Studies. |
Subsystem | Subsystem. A secondary or subordinate system within a larger system. (Source: ISO/IEC/IEEE 24765) |
Supplier | a person or organization that provides something needed, such as a software product or service. |
System | The combination of elements that function together to produce the capability required to meet a need. The elements include hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose. (Source: NPR 7123.1) |
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 adjust a prescribed requirement to accommodate the needs of a specific task or activity (e.g., program or project). Tailoring may result in changes, subtractions, or additions to a typical implementation of the requirement. |
Track | To follow and note the course or progress of the product. |
Transition Criteria | An event or set of conditions which, when satisfied, allows a process to begin (enter) or end (exit). |
Term | Definition |
Uncertainty |
|
Unit Test |
|
Validation |
|
Term | Definition |
Waiver | A documented authorization intentionally releasing a program or project from meeting a requirement after the requirement is put under configuration control at the level the requirement will be implemented. (Source: NPR 7150.2 - Appendix A) |
wiki | A wiki is a website whose users can add, modify, or delete its content via a web browser using a simplified markup language or a rich-text editor. The SWEHB wiki only allows suggestions for additions, modifications, or deletions. Actual changes will be reviewed and, if approved, made by the SWEHB development team. |