skip to page content
Skip all navigation and jump to content Jump to site navigation Jump to section navigation
Jump to current event information
NASA Logo - Goddard Space Flight Center GSFC SW Process Improvement
  + GSFC SW IMPROVEMENT   + PROCESS ASSETS LIBRARY   + TRAINING   + TOOLS   + MEASURES   + LESSONS LEARNED
 

Definitions

List only Terms Containing:

Term/Acronym
Definition
Acceptance Testing (1) Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. (2) Formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component.
Source:
 IEEE Std 1012-2005, IEEE Standard for Software Verification and Validation.
Acquirer An organization that takes possession or ownership of a system, product or service from a supplier. NOTE: The acquirer could be one of the following: buyer, customer, owner, user, purchaser.
Note:
 When GSFC is contracting for software development, then GSFC is the acquirer.
Source:
 Adapted from IEEE/EIA 12207.0-1996
Acquisition The process of obtaining through contract; any discrete action or proposed action by the acquisition entity that would commit to invest (appropriated funds) for obtaining products and services.
Source:
 Capability Maturity Model Integration [CMMI], Version 1.1
Activity A defined body of work to be performed
Note:
 Examples are preparing a software design, or reviewing that design.
Source:
 IEEE Std 1074-1997
Baseline (1) A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. (2) A document or a set of such documents formally designated and fixed at a specific time during the life cycle of a configuration item (3) Any agreement or result designated and fixed at a given time, from which changes require justification and approval.
Source:
 IEEE Std 610.12-1990
Bidirectional Traceability An association among two or more logical entities that is discernable in either direction (i.e., to and from an entity).
Note:
 See also "requirements traceability" and "traceability." When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Requirements traceability can also cover the relationships to other entities such as intermediate and final work products, changes in design documentation, test plans, and work tasks.
Source:
 CMMI v1.2
Build (n) A version of a system or component that incorporates a specified subset of the capabilities that the final product will provide
Note:
 See also: development build, formal build, release.
Source:
 580-PG-8730.3.1
Checklist Any list in which items can be compared, scheduled, verified or identified.
Source:
 American Heritage Dictionary
Checklist A list of expected items (e.g., review materials, design inspection materials, document contents) against which the actual materials developed or delivered can be compared and/or verified. A checklist may also be used to ensure performance of the tasks within a process/sub-process or steps within a procedure.
Source:
 Web Team
Class A: Human Rated Software Systems Applies to all space flight software subsystems (ground and flight) developed and/or operated by or for NASA to support human activity in space and that interact with NASA human space flight systems. Space flight system design and associated risks to humans are evaluated over the program's life cycle, including design, development, fabrication, processing, maintenance, launch, recovery, and final disposal. Examples of Class A software for human rated space flight include but are not limited to: guidance; navigation and control; life support systems; crew escape; automated rendezvous and docking; failure detection, isolation and recovery; and mission operations.
Source:
 NPR 7150.2, "NASA Software Engineering Requirements", Appendix B
Class B: Non-Human Space Rated Software Systems Flight and ground software that must perform reliably in order to accomplish primary mission objectives. Examples of Class B software for non-human (robotic) spaceflight include, but are not limited to, propulsion systems; power systems; guidance navigation and control; fault protection; thermal systems; command and control ground systems; planetary surface operations; hazard prevention; primary instruments; or other subsystems that could cause the loss of science return from multiple instruments.
Source:
 NPR 7150.2, "NASA Software Engineering Requirements", Appendix B
Class C: Mission Support Software Flight or ground software that is necessary for the science return from a single (non-critical) instrument or is used to analyze or process mission data or other software for which a defect could adversely impact attainment of some secondary mission objectives or cause operational problems for which potential work-arounds exist. Examples of Class C software include, but are not limited to, software that supports prelaunch integration and test, mission data processing and analysis, analysis software used in trend analysis and calibration of flight engineering parameters, primary/major science data collection and distribution systems, major Center facilities, data acquisition and control systems, aeronautic applications, or software employed by network operations and control (which is redundant with systems used at tracking complexes). Class C software must be developed carefully, but validation and verification effort is generally less intensive than for Class B.
Source:
 NPR 7150.2, "NASA Software Engineering Requirements", Appendix B
Class D: Analysis and Distribution Software Non-space flight software. Software developed to perform science data collection, storage, and distribution; or perform engineering and hardware data analysis. A defect in Class D software may cause rework but has no direct impact on mission objectives or system safety. Examples of Class D software include, but are not limited to, software tools; analysis tools, and science data collection and distribution systems.
Source:
 NPR 7150.2, "NASA Software Engineering Requirements", Appendix B
Class E: Development Support Software Non-space flight software. Software developed to explore a design concept; or support software or hardware development functions such as requirements management, design, test and integration, configuration management, documentation, or perform science analysis. A defect in Class E software may cause rework but has no direct impact on mission objectives or system safety. Examples of Class E software include, but are not limited to, earth science modeling, information only websites (non- business/information technology); science data analysis; and low technical readiness level research software.
Source:
 NPR 7150.2, "NASA Software Engineering Requirements", Appendix B
Class F: General Purpose Computing Software (Multi-Center or Multi- Program/Project) General purpose computing software used in support of the Agency, multiple Centers, or multiple programs/projects, as described for the General Purpose Infrastructure To-Be Component of the NASA Enterprise Architecture, Volume 5 (To-Be Architecture), and for the following portfolios: voice, wide area network, local area network, video, data centers, application services, messaging and collaboration, and public web. A defect in Class F software is likely to affect the productivity of multiple users across several geographic locations, and may possibly affect mission objectives or system safety. Mission objectives can be cost, schedule, or technical objectives for any work that the Agency performs. Examples of Class F software include, but are not limited to, software in support of the NASA-wide area network; the NASA Web portal; and applications supporting the Agency's Integrated Financial Management Program, such as the time and attendance system, Travel Manager, Business Warehouse, and E-Payroll.
Source:
 NPR 7150.2, "NASA Software Engineering Requirements", Appendix B
Class G: General Purpose Computing Software (Single Center or Project) General purpose computing software used in support of a single Center or project, as described for locally deployed portions of the General Purpose Infrastructure To-Be Component of the NASA Enterprise Architecture, Volume 5 (To-Be Architecture) and for the following portfolios: voice, local area network, video, data centers, application services, messaging and collaboration, and public web. A defect in Class G software is likely to affect the productivity of multiple users in a single geographic location or workgroup, but is unlikely to affect mission objectives or system safety. Examples of Class G software include, but are not limited to, software for Center custom applications such as Headquarters' Corrective Action Tracking System and Headquarters' ODIN New User Request System.
Source:
 NPR 7150.2, "NASA Software Engineering Requirements", Appendix B
Class H: General Purpose Desktop Software General purpose desktop software as described for the General Purpose Infrastructure To-Be Component (Desktop Hardware & Software Portfolio) of the NASA Enterprise Architecture, Volume 5 (NASA To-Be Architecture). This class includes software for Wintel, Mac, and Unix desktops as well as laptops. A defect in Class H software may affect the productivity of a single user or small group of users but generally will not affect mission objectives or system safety. However, a defect in desktop IT-security related software, e.g., anti-virus software, may lead to loss of functionality and productivity across multiple users and systems. Examples of Class H software include, but are not limited to, desktop applications such as Microsoft Word, Excel, and Power Point, and Adobe Acrobat.
Source:
 NPR 7150.2, "NASA Software Engineering Requirements", Appendix B
Component One of the parts that make up a system. A component may be hardware or software and may be subdivided into other components.
Note:
 The terms "module," "component," and "unit" are often used interchangeably or defined to be sub-elements of one another in different ways depending upon the context. The relationship of these terms is not yet standardized
Source:
 IEEE Std 610.12-1990
Computer Software Configuration Item
  / CSCI 		An aggregation of software that is designated for configuration management and treated as a single entity in the configuration management process. See also: configuration item.
Source:
 IEEE Std 610.12-1990
Configuration (1) The arrangement of a computer system or component as defined by the number, nature, and interconnections of its constituent parts. (2) In configuration management, the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product. See also: configuration item, version.
Source:
 IEEE 610.12-1990
Configuration Audit See: functional configuration audit; physical configuration audit.
Source:
 IEEE Std 610.12-1990
Configuration Control An element of configuration management, consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal [identification of their configuration]. Syn.: change control.
Source:
 Adapted from IEEE Std 610.12-1990
Configuration Identification (1) An element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation. Contrast with: configuration control; configuration status accounting. (2) The current approved technical documentation for a configuration item as set forth in specifications, drawings, associated lists, and documents referenced therein.
Source:
 IEEE Std 610.12-1990
Configuration Item An aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process.
Source:
 IEEE Std 610.12-1990
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
Source:
 IEEE Std 610.12-1990
Configuration Status Accounting An element of configuration management, consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes. Contrast with: configuration control; configuration identification.
Source:
 IEEE Std 610.12-1990
Contract In project management, a legally binding document agreed upon by the customer and the hardware or software developer or supplier; includes the technical, organizational, cost, and/or scheduling requirements of a project.
Source:
 IEEE Std 1362-1998
Cross-Cutting Activities Activities that may be performed throughout the life of the project and apply to multiple phases of a development or maintenance project.
Source:
 Adapted from 580-PG-8730.3.1
Customer Any individual, group, or organization that receives and/or pays for a product or service, or arranges to have the product or service provided
Source:
 580-PG-8730.3.1
Derived requirement A requirement deduced or inferred from the collection and organization of requirements into a particular system configuration and solution.
Source:
 IEEE Std 1233-1998
Design The process of defining the architecture, components, interfaces, and other characteristics of a system or component
Source:
 IEEE Std 610.12-1990
Dynamic Analysis The process of evaluating a system or component based on its behavior during execution. Contrast with: static analysis.
Source:
 IEEE Std 610.12-1990
Earned Value Decomposition of a job into its component work packages, scheduling and assigning resources to each such work package (i.e., the work package "value"), periodically determining work accomplished (earned) and resources used, and comparing the work accomplished and resources used to the job plan to measure schedule and resource variance.
Source:
 ISD Process Team
Form A data collection document consisting primarily of multiple fields, into which the user is expected to enter appropriate information.
Source:
 Web Team
Functional Configuration Audit
  / FCA 		An audit conducted to verify that the test records for a developed configuration item demonstrate that it satisfies its requirements. In the NASA/GSFC environment, this generally involves review of the Requirements-to-Test Matrix (RTM) for the configuration item. See also: configuration management; physical configuration audit.
Source:
 ISD Process Team
Functional requirement A requirement that specifies a function that a system or system component must be able to perform.
Source:
 IEEE Std 610.12-1990
Guideline A document that contains technical information in support of a process, sub-process, procedure, or policy. Guidelines provide suggested approaches to good practice, but generally refrain from stating mandatory requirements. Such requirements are generally contained in the associated processes, subprocesses, procedures, or policies.
Source:
 Adapted from: James W. Moore, Software Engineering Standards: A User's Road Map. IEEE Computer Society Press, 1998. p. 29
Implementation The process of translating a design into hardware components, software components, or both.
Source:
 IEEE Std 610.12-1990
Independent Verification and Validation
  / IV&V 		A process whereby the products and processes of the software development life-cycle phases are reviewed, verified, and validated by an organization that is neither the developer nor the purchaser of the software, which is defined by three parameters: technical independence, managerial independence and financial independence. Technical independence engages personnel who are not involved in the development activities. IV&V prioritizes its own efforts. Managerial independence requires responsibility for the IV&V effort to be vested in an organization separate from the organization responsible for development. IV&V maintains an independent reporting route to the Program Management. Financial independence involves funding for the IV&V efforts allocated by the Program and controlled at a high level such that IV&V effectiveness is not compromised.
Source:
 NASA IV&V Facility, IV&V Project Manager's Handbook, revised draft
Indicator A measure or combination of measures that provides insight into a software issue or concept. PSM frequently uses indicators that are comparisons, such as planned versus actual measures. Indicators are generally presented as graphs or tables.
Source:
 Practical Software Measurement [PSM], Version 4.0b, Part 9, www.psmsc.com
Inspection A static analysis technique that relies on visual examination of development products to detect errors, violations of development standards, and other problems. Types include code inspection, design inspection.
Source:
 IEEE Std 610.12-1990
Inspection A means of verifying intellectual products by manually examining the developing product, a piece at a time, by small groups of peers to ensure that it is correct and conforms to product specifications and requirements.
Source:
 Ebenau, Robert G., and Strauss, Susan H., Software Inspection Process, McGraw-Hill, 1994, p. 3.
Interface Control Document
  / ICD 		(Also called Interface Requirement Document.) Documentation that specifies requirements for interfaces between systems or components. These requirements include constraints on formats and timing.
Note:
 ICDs also clarify the responsibilities of the various groups within an organization.
Source:
 IEEE Std 1012-1998
Life Cycle Model A partitioning of the life of a product into phases that guide the project from identifying customer needs through product retirement.
Note:
 Six typical life cycle models are: waterfall development, incremental development, evolutionary development, Spiral model, package-based development, and legacy system maintenance. For additional information on these five life cycle models, see "Software Management Guidebook," NASA-GB-001-96 (November 1996), sec. 5.1, "Selecting an Appropriate Life-Cycle Model."
Source:
 Capability Maturity Model Integration [CMMI], Version 1.1
Life Cycle Model A framework containing the processes, activities, and tasks involved in the development, operation, and maintenance of a software product, spanning the life of the system from the definition of its requirements to the termination of its use.
Source:
 IEEE/EIA 12207.0-1996
Measure A method of counting or otherwise quantifying characteristics of a process or product. Measures assign numerical values to attributes according to defined criteria.
Note:
 The Goal/Question/Metric (GQM) method (see: http://sel.gsfc.nasa.gov/website/exp-factory/gqm.htm) is a systematic approach to defining measures to be captured on a software project.
Source:
 Practical Software Measurement [PSM], Version 4.0b, Part 9, www.psmsc.com
Measurement The process of assigning quantitative values to measures and indicators, according to some defined criteria. This process can be based on estimation or direct measurement. Estimation defines planned or expected measures. Direct measurement results in actual measures.
Source:
 PSM, Version 4.0b, Part 9, www.psmsc.com
Metric A measurement taken over a period of time that communicates vital information about a process or activity. A metric should drive appropriate action.
Source:
 NPG 7120.5B
Metric A quantitative measure of the degree to which a system, component, or process possesses a given attribute.
Source:
 IEE Std 610.12-1990
Mission Software All software directly associated with the operational support of flight projects, including network communications, planning and scheduling, flight system (spacecraft and instrument), flight dynamics, ground mission & science command and control, and science data capture software. Software such as science analysis and research software is not considered mission software.
Note:
 Science data capture software includes archiving and distribution functions.
Source:
 ISD Management Team
Nonconformance Non-fulfillment of a specified requirement. This includes on-orbit anomalies. NOTE: At GSFC, this includes process nonconformances found during ISO audits.
Note:
 At GSFC, this includes process nonconformances found during ISO audits.
Source:
 GPG 5340.2
Nonconforming Product Any product with one or more characteristics that depart from the requirements in the contract, specification, drawing, or other approved product description.
Source:
 Adapted from a Raytheon glossary maintained at:
http://dmserver.hitc.com/EMD_PAL/Indices/Other/definitions.htm]
Organizational Support Processes that are used throughout the life cycle in support of project management, product development, and/or acquisition. Organizational support consists of cross-cutting project activities such as configuration management and software assurance, and organization-level activities such as training and process improvement.
Source:
 Adapted from CMMI
Peer Review The in-process technical examination of work products by the supplier's peers for the purpose of finding and eliminating defects before exiting the current process step. Peer reviews are performed following defined procedures covering the preparation for the review, conducting the review itself, documenting results, reporting the results, and certifying the completion criteria.
Note:
 This term is commonly used within NASA to refer to reviews attended by management. The above definition replaces that usage with the standard industry definition. As the term is used here, a peer review is only for peers; managers do not normally attend.
Source:
 Adapted from NPR 7150.2, section 4.3
Physical Configuration Audit
  / PCA 		An audit conducted to verify that the technical documentation for a developed configuration item completely and accurately describes the as-built configuration item. In the NASA/GSFC environment, this generally involves verification of the contents of the configuration item against the corresponding software delivery documentation. See also: functional configuration audit.
Source:
 ISD Process Team
Policy A guiding principle established by senior management that defines the organization's expectations and makes the expectations visible to affected personnel.
Source:
 ISD Process Team
Procedure An ordered series of steps that are followed to perform a task.
Source:
 Web Team
Procedure (1) A course of action to be taken to perform a given task. (2) A [documented, step-by-step] description of a course of action as in (1); for example, a documented test procedure.
Source:
 IEEE 610.12-1990
Process A set of interrelated activities, which transform inputs into outputs.
Source:
 IEEE/EIA 12207.0-1996
Process A sequence of tasks performed for a given purpose; for example, the software development process.
Source:
 Adapted from IEEE Std 610.12-1990
Product The output of a task, whether deliverable or internal. Products may include hardware, software, documentation, services, mission data, science, and technology output.
Source:
 ISD Process Team
Product Development The translation of user needs into a product, which may include software, hardware, and/or services. The process involves translating user needs into requirements; transforming the requirements into a design; implementing the design; integrating product components; verifying and validating the product, and sometimes, installing and checking out the product for operational use. Note: These acivities may overlap or be performed iteratively.
Source:
 Adapted from IEEE Std 610.12-1990
Product Development Lead
  / PDL 		The manager or leader with overall responsibility for managing the software development activities, including managing the technical and organizational interfaces, and forming and leading the product development team (PDT). For a maintenance project the lead is known as the Product Maintenance Lead (PML).
Source:
 580-PG-8730.3.1
Product Development Team
  / PDT 		The team with overall responsibility for the software development activities. This team is equivalent to the Quality Management System (QMS) Product Design Team. For a maintenance project the team is called a Product Maintenance Team (PMT).
Source:
 580-PG-8730.3.1
Program A major activity within an Enterprise having defined goals, objectives, requirements, and funding levels, and consisting of one or more projects.
Source:
 NPG 7120.5B
Project An activity, designated by a program, characterized as having defined goals, objectives, requirements, a Life-Cycle Cost (LCC), a beginning, and an end.
Source:
 NPG 7120.5B
Project Manager Leader of a Project.
Source:
 ISD Process Team
Project Plan A document describing the implementation of a Project within a Program, prepared and maintained by the Project. The Project Plan is the project's customer agreement and the initial quality plan, approved by the Project Manager, Program Manager, and Center Director. Tailoring decisions are documented in the Project Plan.
Source:
 GPG 7120.2
Provider See: supplier.
Source:
Quality (1) The degree to which a system, component, or process meets specified requirements. (2) A set of activities designed to evaluate the process by which products are developed or manufactured.
Source:
 IEEE Std 610.12-1990
Quality Assurance
  / QA 		(1) A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. (2) A set of activities designed to evaluate the process by which products are developed or manufactured.
Source:
 IEEE Std 610.12-1990
Release (n) A build that is delivered for acceptance testing and subsequently released for operational use.
Source:
 SEL-81-305, "Recommended Approach to Software Development," Revision 3, June 1992
Relevant Stakeholder A stakeholder that is identified for involvement in specified activities.
Source:
 Adapted from Capability Maturity Model Integration [CMMI], Version 1.1
Requirement Any function, constraint, or other property that must be provided, met, or satisfiedÂ…
Source:
 Abbott, R.J. An Integrated Approach to Software Development. New York: John Wiley, 1986.
Requirements Document An organized hierarchy of requirements that provides a validation and/or verification basis for a system or system element.
Source:
 Adapted from GPG 7120.5
Requirements Traceability A discernable association between requirements and related requirements, implementations, and verifications.
Note:
 See also "bidirectional traceability" and "traceability."
Source:
 CMMI v1.2
Risk The combination of 1) the probability (qualitative or quantitative) that a program or project will experience an undesired event such as cost overrun, schedule slippage, safety mishap, or failure to achieve a needed technological breakthrough; and 2) the consequences, impact, or severity of the undesired event were it to occur.
Source:
 NPR 7120.5B, Appendix B; also NASA CRM Glossary
Risk Assessment (1) The process of estimating the probability and impact for each risk identified to ensure that they are understood and can be prioritized. (2) The review of identified risks to see if they are acceptable according to proposed actions.
Source:
 NASA CRM Glossary
Risk Exposure The impact of a risk multiplied by its probability of occurring.
Source:
 NASA CRM Glossary
Risk Management
  / RM 		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 7120.5B, Appendix B; NPR 8735.2, Appendix A; NASA CRM Glossary
Risk Mitigation A strategy that decreases risk by lowering the probability of a risk event's occurrence or reducing the effect of the risk should it occur.
Source:
 NASA CRM Glossary
Risk Mitigation Plan An action plan for risks that are to be mitigated. It documents the strategies, actions, goals, schedule dates, tracking requirements, and all other supporting information needed to carry out the mitigation strategy.
Source:
 NASA CRM Glossary
Senior Management The individual who issues organizational policies, whose primary focus is the long-term vitality of the organization, and who assigns responsibility and resources to organizational elements.
Source:
 ISD Process Team
Software Assurance
  / SA 		For NASA, this [Software Assurance] includes the disciplines of Software Quality (SQ), Software Safety, Software Reliability, Software Verification and Validation (V&V), and Independent Verification and Validation (IV&V)
Source:
 NASA-STD-8739.8 Draft
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.
Source:
 IEEE 610.12
Software Engineering (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).
Source:
 IEEE Std 610.12-1990
Software Library A controlled collection of software and related documentation designed to aid in software development, use, or maintenance.
Source:
 IEEE Std 610.12-1990
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.
Note:
 Note: These phases may overlap or be performed iteratively. Contrast with: software development cycle.
Source:
 IEEE Std 610.12-1990
Software Life Cycle The [sequence of phases] 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.
Note:
 These phases may overlap or be performed iteratively.
Source:
 Adapted from IEEE Std 610.12-1990
Software Maintenance The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment.
Source:
 IEEE Std 610.12-1990
Software Quality Assurance
  / SQA 		The planned and systematic set of activities that provides objective insight into the maturity and quality of the processes and products. As a discipline, it ensures conformance of software life cycle processes and products to documented requirements, standards, and procedures.
Note:
 SQA differs from IV&V. SQA focuses on all software, with emphasis on compliance to standards and procedures. Software Quality (SQ) personnel review, monitor, and audit all software processes and products for completeness and accuracy. IV&V focuses on only a subset of the software, specifically mission-critical software, with emphasis on completeness and correctness of the product. IV&V personnel review, analyze, and provide more in-depth evaluations of life cycle products that have the highest level of risk. While both SQA and IV&V are independent from the project, SQ personnel provide daily insight/oversight, while IV&V works selected tasks -- primarily off-site
Source:
 ISD Process Team
Software Quality Personnel Personnel from the Assurance Management Office, Code 303, responsible for providing Software Quality (SQ)/SQA support to projects and software development efforts. This includes Software Quality Engineers, delegated Defense Contract Management Agency (DCMA) specialists, or support provided under the Supplier Assurance Contract (SAC), as necessary.
Source:
 ISD Process Team
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.
Source:
 NASA-STD-8739.8 Draft
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.
Source:
 NASA-STD-8739.8 Draft
Specification A detailed, implementation-specific requirements document that provides a verification and validation basis for a system or system element.
Source:
 Adapted from GPG 7120.5
Specification A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system or component, and, often, the procedures for determining whether these provisions have been satisfied...
Source:
 IEEE Std 610.2-1990
Stakeholder A group or individual that is affected by or is in some way accountable for the outcome of an undertaking. Stakeholders may include project members, suppliers, customers, end users, and others.
Source:
 Capability Maturity Model Integration [CMMI], Version 1.1
Static Analysis The process of evaluating a system or component based on its form, structure, content, or documentation.
Note:
 Contrast with: dynamic analysis. See also: inspection, walkthrough.
Source:
 IEEE Std 610.12-1990
Sub-process A process that is invoked by a higher-level process.
Source:
 Web Team
Supplier (1) An entity delivering products or performing services being acquired. (2) An individual, partnership, company, corporation, association, or other service having an agreement (contract) with an acquirer for the design, development, manufacture, maintenance, modification, or supply of items under the terms of an agreement (contract).
Source:
 Capability Maturity Model Integration [CMMI], Version 1.1
Sustaining Engineering Implementation of modifications to the current operational version of the hardware, software, and firmware for the purpose of fixing or improving the existing system. The sustaining engineering function includes the analyses and identification of ways to accommodate new technologies and new concepts, manage system upgrades and evolution, control and maintain project databases, and perform the activities necessary to ensure safety, security, reliability, maintainability, and availability. The sustaining engineering effort also includes the development, test, installation, configuration, and tuning of the operational software, COTS packages, operating systems, compilers, tools, utilities, networks, and databases.
Source:
 Adapted from a Raytheon glossary maintained at:
http://dmserver.hitc.com/EMD_PAL/Indices/Other/definitions.htm
System A collection of components organized to accomplish a specific function or set of functions.
Source:
 IEEE Std 610.12-1990
System An integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective.
Source:
 IEEE/EIA 12207.0-1996
Template A pattern used to create a document. It contains page layouts, section headers, etc. Sometimes a template also contains explanations of the expected contents of each section or field; this is called an annotated template.
Source:
 ISD Process Team
Traceability A discernable association among two or more logical entities such as requirements, system elements, verifications, or tasks.
Note:
 See also "bidirectional traceability" and "requirements traceability."
Source:
 CMMI v1.2
Validation Validation confirms that the product, as provided, will fulfill its intended use.
Source:
 CMMI
Validation A process for determining whether the requirements and the final, as-built system or software product fulfills its specific intended use.
Source:
 IEEE/EIA 12207.0-1996, p. 6.5, p. 36
Verification Verification confirms that work products properly reflect the requirements specified for them.
Source:
 CMMI
Verification A process for determining whether the software products of an activity fulfill the requirements or conditions imposed on them in the previous activities.
Source:
 IEEE/EIA 12207.0-1996, sec. 6.4, p. 33
Walkthrough An aid to understanding, in which a designer or programmer gives a brief, tutorial overview of the product, then walks the reviewers through the materials step by step. The reviewers are encouraged to analyze and question the material under discussion.
Source:
 Adapted from SEL-81-305, "Recommended Approach to Software Development," Revision 3, p. 29, June 1992
Walkthrough A static analysis technique in which a designer or programmer leads members of the development team and other interested parties through a segment of documentation and code, and the participants ask questions and make comments about possible errors, violations of development standards, and other problems.
Note:
 A walkthrough is less structured than an inspection.
Source:
 IEEE Std 610.12-1990

Questions/Feedback  Feedback Icon

+ Privacy Policy and Important Notices		 NASA logo

Curator: Terry L. McRoberts
NASA Official: Sara H. Godfrey
NASA Home Page Goddard Space Flight Center Home Page