Glossary of Computer Software Development Terminology

The terms are defined, as much as possible, using available standards. The source of such definitions appears immediately following the term or phrase in parenthesis, e.g. (NIST).

The source documents are listed at the bottom of this page.

SCSI. small computer systems interface.

SOPs. standard operating procedures.

SQL. structured query language.

SSI. small scale integration.

safety. (DOD) Freedom from those conditions that can cause death, injury, occupational illness, or damage to or loss of equipment or property, or damage to the environment.

safety critical. (DOD) A term applied to a condition, event, operation, process or item of whose proper recognition, control, performance or tolerance is essential to safe system operation or use; e.g., safety critical function, safety critical path, safety critical component.

safety critical computer software components. (DOD) Those computer software components and units whose errors can result in a potential hazard, or loss of predictability or control of a system.

security. See: computer system security.

sensor. A peripheral input device which senses some variable in the system environment, such as temperature, and converts it to an electrical signal which can be further converted to a digital signal for processing by the computer.

serial. (1) Pertaining to the sequential processing of the individual parts of a whole, such as the bits of a character or the characters of a word, using the same facilities for successive parts. (2) Term describing the transmission of data one bit at a time. Contrast with parallel.

server. A high speed computer in a network that is shared by multiple users. It holds the programs and data that are shared by all users.

service program. Syn: utility program.

servomechanism. (ANSI) (1) An automatic device that uses feedback to govern the physical position of an element. (2) A feedback control system in which at least one of the system signals represents a mechanical motion.

severity. See: criticality.

side effect. An unintended alteration of a program's behavior caused by a change in one part of the program, without taking into account the effect the change has on another part of the program. See: regression analysis and testing.

simulation. (1) (NBS) Use of an executable model to represent the behavior of an object. During testing the computational hardware, the external environment, and even code segments may be simulated. (2) (IEEE) A model that behaves or operates like a given system when provided a set of controlled inputs. Contrast with emulation.

simulation analysis. (IEEE) A software V&V task to simulate critical tasks of the software or system environment to analyze logical or performance characteristics that would not be practical to analyze manually.

simulator. (IEEE) A device, computer program, or system that behaves or operates like a given system when provided a set of controlled inputs. Contrast with emulator. A simulator provides inputs or responses that resemble anticipated process parameters. Its function is to present data to the system at known speeds and in a proper format.

sizing. (IEEE) The process of estimating the amount of computer storage or the number of source lines required for a software system or component. Contrast with timing.

sizing and timing analysis. (IEEE) A software V&V task to obtain program sizing and execution timing information to determine if the program will satisfy processor size and performance requirements allocated to software.

small computer systems interface. A standard method of interfacing a computer to disk drives, tape drives and other peripheral devices that require high-speed data transfer. Up to seven SCSI devices can be linked to a single SCSI port. Contrast with ST-506, EDSI, IDE.

small scale integration. A classification of ICs [chips] based on their size as expressed by the number of circuits or logic gates they contain. An SSI IC contains up to 100 transistors.

software. (ANSI) Programs, procedures, rules, and any associated documentation pertaining to the operation of a system. Contrast with hardware. See: application software, operating system, system software, utility software.

software audit. See: software review.

software characteristic. An inherent, possibly accidental, trait, quality, or property of software; e.g., functionality, performance, attributes, design constraints, number of states, lines or branches.

software configuration item. See: configuration item.

software design description. (IEEE) A representation of software created to facilitate analysis, planning, implementation, and decision making. The software design description is used as a medium for communicating software design information, and may be thought of as a blueprint or model of the system. See: structured design, design description, specification.

software developer. See: developer.

software development notebook. (NIST) A collection of material pertinent to the development of a software module. Contents typically include the requirements, design, technical reports, code listings, test plans, test results, problem reports, schedules, notes, etc. for the module. Syn: software development file.

software development plan. (NIST) The project plan for the development of a software product. Contrast with software development process, software life cycle.

software development process. (IEEE) The process by which user needs are translated into a software product. the process involves translating user needs into software requirements, transforming the software requirements into design, implementing the design in code, testing the code, and sometimes installing and checking out the software for operational activities. Note: these activities may overlap or be performed iteratively. See: incremental development, rapid prototyping, spiral model, waterfall model.

software diversity. (IEEE) A software development technique in which two or more functionally identical variants of a program are developed from the same specification by different programmers or programming teams with the intent of providing error detection, increased reliability, additional documentation or reduced probability that programming or compiler errors will influence the end results.

software documentation. (NIST) Technical data or information, including computer listings and printouts, in human readable form, that describe or specify the design or details, explain the capabilities, or provide operating instructions for using the software to obtain desired results from a software system. See: specification; specification, requirements; specification, design; software design description; test plan, test report, user's guide.

software element. (IEEE) A deliverable or in- process document produced or acquired during software development or maintenance. Specific examples include but are not limited to:

(1) Project planning documents; i.e., software development plans, and software verification and validation plans.

(2) Software requirements and design specifications.

(3) Test documentation.

(4) Customer-deliverable documentation.

(5) Program source code.

(6) Representation of software solutions implemented in firmware.

(7) Reports; i.e., review, audit, project status.

(8) Data; i.e., defect detection, test.

Contrast with software item. See: configuration item.

software element analysis. See: software review.

software engineering. (IEEE) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; i.e., the application of engineering to software. See: project plan, requirements analysis, architectural design, structured design, system safety, testing, configuration management.

software engineering environment. (IEEE) The hardware, software, and firmware used to perform a software engineering effort. Typical elements include computer equipment, compilers, assemblers, operating systems, debuggers, simulators, emulators, test tools, documentation tools, and database management systems.

software hazard analysis. (ODE, CDRH) The identification of safety-critical software, the classification and estimation of potential hazards, and identification of program path analysis to identify hazardous combinations of internal and environmental program conditions. See: risk assessment, software safety change analysis, software safety code analysis, software safety design analysis, software safety requirements analysis, software safety test analysis, system safety.

software item. (IEEE) Source code, object code, job control code, control data, or a collection of these items. Contrast with software element.

software life cycle. (NIST) Period of time beginning when a software product is conceived and ending when the product is no longer available for use. The software life cycle is typically broken into phases denoting activities such as requirements, design, programming, testing, installation, and operation and maintenance. Contrast with software development process. See: waterfall model.

software reliability. (IEEE) (1) the probability that software will not cause the failure of a system for a specified time under specified conditions. The probability is a function of the inputs to and use of the system in the software. The inputs to the system determine whether existing faults, if any, are encountered. (2) The ability of a program to perform its required functions accurately and reproducibly under stated conditions for a specified period of time.

software requirements specification. See: specification, requirements.

software review. (IEEE) An evaluation of software elements to ascertain discrepancies from planned results and to recommend improvement. This evaluation follows a formal process. Syn: software audit. See: code audit, code inspection, code review, code walkthrough, design review, specification analysis, static analysis.

software safety change analysis. (IEEE) Analysis of the safety-critical design elements affected directly or indirectly by the change to show the change does not create a new hazard, does not impact on a previously resolved hazard, does not make a currently existing hazard more severe, and does not adversely affect any safety-critical software design element. See: software hazard analysis, system safety.

software safety code analysis. (IEEE) Verification that the safety-critical portions of the design are correctly implemented in the code. See: logic analysis, data analysis, interface analysis, constraint analysis, programming style analysis, noncritical code analysis, timing and sizing analysis, software hazard analysis, system safety.

software safety design analysis. (IEEE) Verification that the safety-critical portion of the software design correctly implements the safety-critical requirements and introduces no new hazards. See: logic analysis, data analysis, interface analysis, constraint analysis, functional analysis, software element analysis, timing and sizing analysis, reliability analysis, software hazard analysis, system safety.

software safety requirements analysis. (IEEE) Analysis evaluating software and interface requirements to identify errors and deficiencies that could contribute to a hazard. See: criticality analysis, specification analysis, timing and sizing analysis, different software systems analyses, software hazard analysis, system safety.

software safety test analysis. (IEEE) Analysis demonstrating that safety requirements have been correctly implemented and that the software functions safely within its specified environment. Tests may include; unit level tests, interface tests, software configuration item testing, system level testing, stress testing, and regression testing. See: software hazard analysis, system safety.

source code. (1) (IEEE) Computer instructions and data definitions expressed in a form suitable for input to an assembler, compiler or other translator. (2) The human readable version of the list of instructions [program] that cause a computer to perform a task. Contrast with object code. See: source program, programming language.

source program. (IEEE) A computer program that must be compiled, assembled, or otherwise translated in order to be executed by a computer. Contrast with object program. See: source code.

spaghetti code. Program source code written without a coherent structure. Implies the excessive use of GOTO instructions. Contrast with structured programming.

special test data. (NBS) Test data based on input values that are likely to require special handling by the program. See: error guessing; testing, special case.

specification. (IEEE) 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. Contrast with requirement. See: specification, formal; specification, requirements; specification, functional; specification, performance; specification, interface; specification, design; coding standards; design standards.

specification analysis. (IEEE) Evaluation of each safety-critical software requirement with respect to a list of qualities such as completeness, correctness, consistency, testability, robustness, integrity, reliability, usability, flexibility, maintainability, portability, interoperability, accuracy, auditability, performance, internal instrumentation, security and training.

specification, design. (NIST) A specification that documents how a system is to be built. It typically includes system or component structure, algorithms, control logic, data structures, data set [file] use information, input/output formats, interface descriptions, etc. Contrast with design standards, requirement. See: software design description.

specification, formal. (NIST) (1) A specification written and approved in accordance with established standards. (2) A specification expressed in a requirements specification language. Contrast with requirement.

specification, functional. (NIST) A specification that documents the functional requirements for a system or system component. It describes what the system or component is to do rather than how it is to be built. Often part of a requirements specification. Contrast with requirement.

specification, interface. (NIST) A specification that documents the interface requirements for a system or system component. Often part of a requirements specification. Contrast with requirement.

specification, performance. (IEEE) A document that sets forth the performance characteristics that a system or component must possess. These characteristics typically include speed, accuracy, and memory usage. Often part of a requirements specification. Contrast with requirement.

specification, product. (IEEE) A document which describes the as built version of the software.

specification, programming. (NIST) See: specification, design.

specification, requirements. (NIST) A specification that documents the requirements of a system or system component. It typically includes functional requirements, performance requirements, interface requirements, design requirements [attributes and constraints], development [coding] standards, etc. Contrast with requirement.

specification, system. See: requirements specification.

specification, test case. See: test case.

specification tree. (IEEE) A diagram that depicts all of the specifications for a given system and shows their relationship to one another.

spiral model. (IEEE) A model of the software development process in which the constituent activities, typically requirements analysis, preliminary and detailed design, coding, integration, and testing, are performed iteratively until the software is complete. Syn: evolutionary model. Contrast with incremental development; rapid prototyping; waterfall model.

ST-506. A standard electrical interface between the hard disk and controller in IBM PC compatible computers. Contrast with EDSI, IDE, SCSI.

standard operating procedures. Written procedures [prescribing and describing the steps to be taken in normal and defined conditions] which are necessary to assure control of production and processes.

state. (IEEE) (1) A condition or mode of existence that a system, component, or simulation may be in; e.g., the pre-flight state of an aircraft navigation program or the input state of a given channel.

state diagram. (IEEE) A diagram that depicts the states that a system or component can assume, and shows the events or circumstances that cause or result from a change from one state to another. Syn: state graph. See: state-transition table.

statement coverage. See: testing, statement.

state-transition table. (Beizer) A representation of a state graph that specifies the states, the inputs, the transitions, and the outputs. See: state diagram.

static analysis. (1) (NBS) Analysis of a program that is performed without executing the program. (2) (IEEE) The process of evaluating a system or component based on its form, structure, content, documentation. Contrast with dynamic analysis. See: code audit, code inspection, code review, code walk-through, design review, symbolic execution.

static analyzer. (ANSI/IEEE) A software tool that aides in the evaluation of a computer program without executing the program. Examples include checkers, compilers, cross-reference generators, standards enforcers, and flowcharters.

stepwise refinement. A structured software design technique; data and processing steps are defined broadly at first, and then further defined with increasing detail.

storage device. A unit into which data or programs can be placed, retained and retrieved. See: memory.

string. (IEEE) (1) A sequence of characters. (2) A linear sequence of entities such as characters or physical elements.

structure chart. (IEEE) A diagram that identifies modules, activities, or other entities in a system or computer program and shows how larger or more general entities break down into smaller, more specific entries. Note: The result is not necessarily the same as that shown in a call graph. Syn: hierarchy chart, program structure chart. Contrast with call graph.

structured design. (IEEE) Any disciplined approach to software design that adheres to specified rules based on principles such as modularity, top-down design, and stepwise refinement of data, system structure, and processing steps. See: data structure centered design, input-processing-output, modular decomposition, object oriented design, rapid prototyping, stepwise refinement, structured programming, transaction analysis, transform analysis, graphical software specification/design documents, modular software, software engineering.

structured programming. (IEEE) Any software development technique that includes structured design and results in the development of structured programs. See: structured design.

structured query language. A language used to interrogate and process data in a relational database. Originally developed for IBM mainframes, there have been many implementations created for mini and micro computer database applications. SQL commands can be used to interactively work with a data base or can be embedded with a programming language to interface with a database.

stub. (NBS) Special code segments that when invoked by a code segment under test will simulate the behavior of designed and specified modules not yet constructed.

subprogram. (IEEE) A separately compilable, executable component of a computer program. Note: This term is defined differently in various programming languages. See: coroutine, main program, routine, subroutine.

subroutine. (IEEE) A routine that returns control to the program or subprogram that called it. Note: This term is defined differently in various programming languages. See: module.

subroutine trace. (IEEE) A record of all or selected subroutines or function calls performed during the execution of a computer program and, optionally, the values of parameters passed to and returned by each subroutine or function. Syn: call trace. See: execution trace, retrospective trace, symbolic trace, variable trace.

support software. (IEEE) Software that aids in the development and maintenance of other software; e.g., compilers, loaders, and other utilities.

symbolic execution. (IEEE) A static analysis technique in which program execution is simulated using symbols, such as variable names, rather than actual values for input data, and program outputs are expressed as logical or mathematical expressions involving these symbols.

symbolic trace. (IEEE) A record of the source statements and branch outcomes that are encountered when a computer program is executed using symbolic, rather than actual values for input data. See: execution trace, retrospective trace, subroutine trace, variable trace.

synchronous. Occurring at regular, timed intervals, i.e. timing dependent.

synchronous transmission. A method of electrical transfer in which a constant time interval is maintained between successive bits or characters. Equipment within the system is kept in step on the basis of this timing. Contrast with asynchronous transmission.

syntax. The structural or grammatical rules that define how symbols in a language are to be combined to form words, phrases, expressions, and other allowable constructs.

system. (1) (ANSI) People, machines, and methods organized to accomplish a set of specific functions. (2) (DOD) A composite, at any level of complexity, of personnel, procedures, materials, tools, equipment, facilities, and software. The elements of this composite entity are used together in the intended operational or support environment to perform a given task or achieve a specific purpose, support, or mission requirement.

system administrator. The person that is charged with the overall administration, and operation of a computer system. The System Administrator is normally an employee or a member of the establishment. Syn: system manager.

system analysis. (ISO) A systematic investigation of a real or planned system to determine the functions of the system and how they relate to each other and to any other system. See: requirements phase.

system design. (ISO) A process of defining the hardware and software architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. See: design phase, architectural design, functional design.

system design review. (IEEE) A review conducted to evaluate the manner in which the requirements for a system have been allocated to configuration items, the system engineering process that produced the allocation, the engineering planning for the next phase of the effort, manufacturing considerations, and the planning for production engineering. See: design review.

system documentation. (ISO) The collection of documents that describe the requirements, capabilities, limitations, design, operation, and maintenance of an information processing system. See: specification, test documentation, user's guide.

system integration. (ISO) The progressive linking and testing of system components into a complete system. See: incremental integration.

system life cycle. The course of developmental changes through which a system passes from its conception to the termination of its use; e.g., the phases and activities associated with the analysis, acquisition, design, development, test, integration, operation, maintenance, and modification of a system. See: software life cycle.

system manager. See: system administrator.

system safety. (DOD) The application of engineering and management principles, criteria, and techniques to optimize all aspects of safety within the constraints of operational effectiveness, time, and cost throughout all phases of the system life cycle. See: risk assessment, software safety change analysis, software safety code analysis, software safety design analysis, software safety requirements analysis, software safety test analysis, software engineering.

system software. (1) (ISO) Application- independent software that supports the running of application software. (2) (IEEE) Software designed to facilitate the operation and maintenance of a computer system and its associated programs; e.g., operating systems, assemblers, utilities. Contrast with application software. See: support software.

Source Documents

1. The New IEEE Standard Dictionary of Electrical and Electronics Terms, IEEE Std. 100-1992.
2. IEEE Standards Collection, Software Engineering, 1994 Edition, published by the Institute of Electrical and Electronic Engineers Inc.
3. National Bureau of Standards [NBS] Special Publication 500-75 Validation, Verification, and Testing of Computer Software, 1981.
4. Federal Information Processing Standards [FIPS] Publication 101, Guideline For Lifecycle Validation, Verification, and Testing of Computer Software, 1983.
5. Federal Information Processing Standards [FIPS] Publication 105, Guideline for Software Documentation Management, 1984.
6. American National Standard for Information Systems, Dictionary for Information Systems, American National Standards Institute, 1991.
7. FDA Technical Report, Software Development Activities, July 1987.
8. FDA Guide to Inspection of Computerized Systems in Drug Processing, 1983.
9. FDA Guideline on General Principles of Process Validation, May 1987.
10. Reviewer Guidance for Computer Controlled Medical Devices Undergoing 510(k) Review, Office of Device Evaluation, CDRH, FDA, August 1991.
11. HHS Publication FDA 90-4236, Preproduction Quality Assurance Planning.
12. MIL-STD-882C, Military Standard System Safety Program Requirements, 19JAN1993.
13. International Electrotechnical Commission, International Standard 1025, Fault Tree Analysis.
14. International Electrotechnical Commission, International Standard 812, Analysis Techniques for System Reliability - Procedure for Failure Mode and Effects Analysis [FMEA].
15. FDA recommendations, Application of the Medical Device GMP to Computerized Devices and Manufacturing Processes, May 1992.
16. Pressman, R., Software Engineering, A Practitioner's Approach, Third Edition, McGraw-Hill, Inc., 1992.
17. Myers, G., The Art of Software Testing, Wiley Interscience, 1979.
18. Beizer, B., Software Testing Techniques, Second Edition, Van Nostrand Reinhold, 1990.
19. Additional general references used in developing some definitions are:
20. Bohl, M., Information Processing, Fourth Edition, Science Research Associates, Inc., 1984.
21. Freedman, A., The Computer Glossary, Sixth Edition, American Management Association, 1993.
22. McGraw-Hill Electronics Dictionary, Fifth Edition, 1994, McGraw-Hill Inc.
23. McGraw-Hill Dictionary of Scientific & Technical Terms, Fifth Edition, 1994, McGraw-Hill Inc..
24. Webster's New Universal Unabridged Dictionary, Deluxe Second Edition, 1979.

The bulk of this information was obtained from FDA.gov.