Term
|
Definition
| the implementation of the secondary changes (when one change in a system calls for another change in the system) |
|
|
Term
|
Definition
| occurs when a component algorithm or logic does not produce the proper output for a given input because something is wrong with the processing steps |
|
|
Term
|
Definition
| easy-to-spot faults by reading through a program or by submitting input data from each of the different classes of data that we expect the program to receive during its regular working |
|
|
Term
|
Definition
| predictions are ______ when they are consistently different from the actual reliability of the product |
|
|
Term
|
Definition
| when all components are tested in isolation, attempting to mix them together as the final system and see if it works the first time |
|
|
Term
| Boundary (capacity) faults |
|
Definition
| these faults occur when the system's performance becomes unacceptable as system activity reaches its specified limit |
|
|
Term
|
Definition
| a process that reflects ideas used in chip production to keep faults at a minimum. it is an approach that certifies the software with respect to the specifications and its goal is to produce zero-fault software |
|
|
Term
| CMM (Capability Maturity Model) |
|
Definition
| developed by the US Software Engineering Institute to assist the DoD in assessing the quality of its contractors |
|
|
Term
|
Definition
| routine that calls a particular component and passes a test case to it |
|
|
Term
|
Definition
| using components that were originally developed for other projects |
|
|
Term
|
Definition
| a metric that captures an aspect of the structural complexity of source code by measuring the number of linearly independent paths through the code |
|
|
Term
|
Definition
| a difference file, that contains editing commands that describe how the main version is to be transformed to a different version |
|
|
Term
|
Definition
| situations that we know are counter to what we really want to the system to do |
|
|
Term
|
Definition
| technique to estimate the number of faults in a program |
|
|
Term
|
Definition
| evaluation of the many risks associated with change, including estimates on resources, effort and schedule |
|
|
Term
|
Definition
| the process of verifying that the system components work together as described in the system and program design specifications |
|
|
Term
|
Definition
| a hierarchical model with six major attributes contributing to quality (International standardization organization) |
|
|
Term
|
Definition
| often averse to adopting something new, either with economic or personal justification |
|
|
Term
| law of increasing complexity |
|
Definition
| as an evolving program is continually changed, its structure deteriorates. complexity increases unless work is done to maintain or reduce it |
|
|
Term
|
Definition
| an existing computer system or application program which continues to be used because the user (typically an organization) does not want to replace or redesign it. Many people use this term to refer to "antiquated" systems |
|
|
Term
|
Definition
| any work done to change the system after it is in operation is considered to be ____________ |
|
|
Term
|
Definition
| a mapping from a set of entities and attributes in the real empirical world to a representation model or in the mathematical world |
|
|
Term
|
Definition
| measure of availability; tells us how long the system is unavailable for use |
|
|
Term
|
Definition
| measure of reliability; tells us the interfailure times |
|
|
Term
|
Definition
| measure of maintainability; the time lost as teh faults causing the failure are located and repaired |
|
|
Term
|
Definition
| predictions are _________ when successive predictions of measure fluctuate more wildly than the actual reliability |
|
|
Term
|
Definition
| the present value of benefits minus the value of the initial investment |
|
|
Term
|
Definition
| corresponds to the rate of return expected from an equivalent investment in capital markets |
|
|
Term
|
Definition
| postimplementation assessment of all aspects of the project, including products, processes, and resources, intended to identify areas of improvement for future projects |
|
|
Term
|
Definition
| creating components designed to be reused in subsequent applications |
|
|
Term
|
Definition
| test that address response to the presence of faults or to the loss of data, power, devices or services |
|
|
Term
|
Definition
| required when the system being tested is replacing an existing system. guarantees that the new system's performance is at least as good as the old |
|
|
Term
|
Definition
| to look back from the source code to the products that preceded it, recreating design and specification information from the code |
|
|
Term
|
Definition
| probability that a system is operating successfully according to specification at a given point in time |
|
|
Term
|
Definition
| probabiliyu that a system will operate without failture under given conditions for a given time interval |
|
|
Term
|
Definition
| a level or a subsystem of a build plan |
|
|
Term
|
Definition
| a special purpose program to stimulate the activity of the missing component |
|
|
Term
|
Definition
| users are often forced to block out familiar activities in order to learn new ones |
|
|
Term
|
Definition
| describes the way in which we will show our customers that the software works correctly |
|
|
Term
|
Definition
| a testing strategy that involves following each possible transaction to its end |
|
|
Term
|
Definition
| reflecting undertainty about how the system will be used |
|
|
Term
|
Definition
| reflects our lack of knowledge about the effect of fault removal |
|
|
Term
|
Definition
| the system we have built meets the requirements |
|
|
Term
|
Definition
| the system operates the way the designers intend; the designers' interpretation of the requirements specifications |
|
|
