Term
|
Definition
The official way a system works, as described in organizational documentation.
|
|
|
Term
|
Definition
The way a system actually works.
|
|
|
Term
|
Definition
The trained individual who plans and leads joint application design sessions.
|
|
|
Term
|
Definition
The person who makes detailed notes of the happenings at a joint application design session.
|
|
|
Term
Business process reengineering (BPR)
|
|
Definition
The search for, and implementation of, radical
change in business processes to achieve breakthrough
improvements in products and services.
|
|
|
Term
|
Definition
The structured, measured set of activities designed to produce a specific output for a particular customer or market.
|
|
|
Term
|
Definition
Technologies that enable the
breaking of long-held business
rules that inhibit organizations
from making radical business
changes. |
|
|
Term
|
Definition
Graphically representing the
processes that capture,
manipulate, store, and distribute
data between a system and its
environment and among
components within a system. |
|
|
Term
|
Definition
A graphic that illustrates the
movement of data between
external entities and the
processes and data stores within
a system. |
|
|
Term
|
Definition
Data at rest, which may take the
form of many different physical
representations. |
|
|
Term
|
Definition
The work or actions performed
on data so that they are
transformed, stored, or
distributed. |
|
|
Term
|
Definition
The origin and/or destination
of data; sometimes referred to
as external entities. |
|
|
Term
|
Definition
A data-flow diagram of the
scope of an organizational
system that shows the system
boundaries, external entities that
interact with the system, and the
major information flows between
the entities and the system. |
|
|
Term
|
Definition
A data-flow diagram that
represents a system’s major
processes, data flows, and data
stores at a high level of detail. |
|
|
Term
|
Definition
A DFD that is the result of n
nested decompositions of a
series of subprocesses from a
process on a level-0 diagram. |
|
|
Term
|
Definition
The conservation of inputs and
outputs to a data-flow diagram
process when that process is
decomposed to a lower level. |
|
|
Term
|
Definition
The extent to which all necessary
components of a data-flow
diagram have been included
and fully described. |
|
|
Term
|
Definition
The extent to which information
contained on one level of a set
of nested data-flow diagrams is
also included on other levels. |
|
|
Term
|
Definition
The lowest level of
decomposition for a data-flow
diagram. |
|
|
Term
|
Definition
The process of discovering
discrepancies between two or
more sets of data-flow diagrams
or discrepancies within a single
DFD. |
|
|
Term
|
Definition
A matrix representation of the
logic of a decision, which
specifies the possible conditions
for the decision and the resulting
actions. |
|
|
Term
|
Definition
That part of a decision table that
lists the conditions relevant to the
decision. |
|
|
Term
|
Definition
That part of a decision table that
lists the actions that result for
a given set of conditions. |
|
|
Term
|
Definition
That part of a decision table that
specifies which actions are to be
followed for a given set of
conditions. |
|
|
Term
|
Definition
In a decision table, a condition
whose value does not affect
which actions are taken for two
or more rules. |
|
|
Term
|
Definition
A detailed model that shows the
overall structure of organizational
data while being independent
of any database management
system or other implementation
considerations. |
|
|
Term
Entity-relationship
diagram (E-R diagram) |
|
Definition
A graphical representation of the
entities, associations, and data
for an organization or business
area; it is a model of entities,
the associations among those
entities, and the attributes of both
the entities and their
associations. |
|
|
Term
|
Definition
A person, place, object,
event, or concept in the user
environment about which
the organization wishes
to maintain data. |
|
|
Term
|
Definition
A collection of entities that share
common properties or
characteristics. |
|
|
Term
| Entity instance (instance) |
|
Definition
A single occurrence of an entity
type. |
|
|
Term
|
Definition
A named property or
characteristic of an entity that
is of interest to the organization. |
|
|
Term
|
Definition
An attribute (or combination of
attributes) that uniquely identifies
each instance of an entity type. |
|
|
Term
|
Definition
A candidate key that has
been selected as the unique,
identifying characteristic for
an entity type. |
|
|
Term
|
Definition
An attribute that may take on
more than one value for each
entity instance. |
|
|
Term
|
Definition
A set of two or more multivalued
attributes that are logically
related. |
|
|
Term
|
Definition
An association between the
instances of one or more entity
types that is of interest to the
organization. |
|
|
Term
|
Definition
The number of entity types that
participate in a relationship. |
|
|
Term
Unary relationship
(recursive relationship) |
|
Definition
A relationship between the
instances of one entity type. |
|
|
Term
|
Definition
A relationship between instances
of two entity types. |
|
|
Term
|
Definition
A simultaneous relationship
among instances of three entity
types. |
|
|
Term
|
Definition
The number of instances of
entity B that can (or must) be
associated with each instance
of entity A. |
|
|
Term
|
Definition
An entity type that associates the
instances of one or more entity
types and contains attributes that
are peculiar to the relationship
between those entity instances. |
|
|
Term
|
Definition
A particular approach to
developing an information
system. It includes statements
on the system’s functionality,
hardware and system software
platform, and method for
acquisition. |
|
|
Term
|
Definition
A testing technique in which
participants examine program
code for predictable language specific
errors. |
|
|
Term
|
Definition
A testing technique in which the
program code is sequentially
executed manually by the
reviewer. |
|
|
Term
|
Definition
Each module is tested alone in
an attempt to discover any errors
in its code. |
|
|
Term
|
Definition
The process of bringing together
for testing purposes all of the
modules that a program
comprises. Modules are typically
integrated in a top-down,
incremental fashion. |
|
|
Term
|
Definition
The bringing together for testing
purposes of all the programs that
a system comprises. Programs
are typically integrated in a top down,
incremental fashion. |
|
|
Term
|
Definition
A technique used in testing
modules, especially where
modules are written and tested in
a top-down fashion, where a few
lines of code are used to
substitute for subordinate
modules. |
|
|
Term
|
Definition
An automated testing
environment used to review code
for errors, standards violations,
and other design flaws. |
|
|
Term
|
Definition
The process whereby actual users
test a completed information
system, the end result of which is
the users’ acceptance of it once
they are satisfied with it. |
|
|
Term
|
Definition
User testing of a completed
information system using
simulated data. |
|
|
Term
|
Definition
User testing of a completed
information system using real
data in the real user environment. |
|
|
Term
|
Definition
The organizational process of
changing over from the current
information system to a new one. |
|
|
Term
|
Definition
Changing over from the old
information system to a new one
by turning off the old system
when the new one is turned on. |
|
|
Term
|
Definition
Running the old information
system and the new one at the
same time until management
decides the old system can be
turned off. |
|
|
Term
Single location
installation |
|
Definition
Trying out a new information
system at one site and using the
experience to decide if and how
the new system should be
deployed throughout the
organization. |
|
|
Term
|
Definition
Changing from the old
information system to the new
one incrementally, starting with
one or a few functional
components and then gradually
extending the installation to cover
the whole new system. |
|
|
Term
|
Definition
Detailed information about a
system’s design specifications, its
internal workings, and its
functionality. |
|
|
Term
|
Definition
System documentation that is part
of the program source code or is
generated at compile time. |
|
|
Term
|
Definition
System documentation that
includes the outcome of
structured diagramming
techniques such as data-flow
and entity-relationship diagrams. |
|
|
Term
|
Definition
Written or other visual
information about how an
application system works,
and how to use it. |
|
|
Term
|
Definition
Providing ongoing educational
and problem-solving assistance
to information system users.
Support material and jobs must
be designed along with the
associated information system. |
|
|
Term
Electronic performance
support system (EPSS) |
|
Definition
Component of a software
package or application in which
training and educational
information is embedded. An
EPSS may include a tutorial,
expert system, and hypertext
jumps to reference material. |
|
|
Term
|
Definition
Typically a Web-based tool for
logging, tracking, and assigning
system bugs and change
requests to developers. |
|
|
Term
|
Definition
A single point of contact for all
user inquiries and problems
about a particular information
system or for all users in a
particular department. |
|
|
Term
|
Definition
Changes made to a system to fix
or enhance its functionality. |
|
|
Term
|
Definition
Changes made to a system to
repair flaws in its design,
coding, or implementation. |
|
|
Term
|
Definition
Changes made to a system to
evolve its functionality to
changing business needs or
technologies. |
|
|
Term
|
Definition
Changes made to a system to
add new features or to improve
performance. |
|
|
Term
|
Definition
Changes made to a system to
avoid possible future problems. |
|
|
Term
Mean time between
failures (MTBF) |
|
Definition
A measurement of error
occurrences that can be tracked
over time to indicate the quality
of a system. |
|
|
Term
|
Definition
The process of ensuring that only
authorized changes are made to
a system. |
|
|
Term
|
Definition
Software modules that have been
tested, documented, and
approved to be included in the
most recently created version of a
system. |
|
|
Term
|
Definition
A person responsible for
controlling the checking out and
checking in of baseline modules
when a system is being
developed or maintained. |
|
|
Term
|
Definition
Guidelines that list the instructions
to construct an executable system
from the baseline source code. |
|
|
