1. |
Algorithm
|
f) |
A logical sequence of discrete steps that describes a complete
solution to a given problem, computable in a finite amount of
time
|
2. |
Requirements
|
i) |
A statement of what is to be provided by a computer system or
software product
|
3. |
Abstraction
|
l) |
A model of a complex system that includes only the details
essential to the perspective of the viewer of the system
|
4. |
Module
|
k) |
A cohesive system subunit that performs a share of the work
|
5. |
Testing
|
j) |
The process of executing a program with data sets designed to
discover errors
|
6. |
Debugging
|
n) |
The process of removing known errors
|
7. |
Acceptance test
|
o) |
The process of testing the system in its real environment with
real data
|
8. |
Regression testing
|
m) |
Reexecution of program tests after modifications have been made
to ensure that the program still works correctly
|
9. |
Compiler
|
g) |
A program that translates a high-level language (such as C++,
Pascal, or FORTRAN) into machine code
|
10. |
Robustness
|
c) |
The ability of a program to recover following an error; the
ability of a program to continue to operate within its
environment
|
11. |
Deskchecking
|
b) |
Tracing an execution of a design or program on paper
|
12. |
Walk-through
|
e) |
A verification method in which a team performs a manual
simulation of the program or design
|
13. |
Inspection
|
d) |
A verification method in which one member of a team reads the
program or design line by line an the other members point
out errors.
|
14. |
Exception
|
a) |
An unusual, generally unpredictable event, detectable by
software or hardware, that requires special processing; the
event may or may not be erroneous
|
15. |
Test Plan
|
h) |
A document showing the test cases planned for a program or
module, their purposes, inputs, expected outputs, and
criteria for success.
|