Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
124 Cards in this Set
- Front
- Back
System
|
collection of interrelated components that function together to achieve some outcome
|
|
information system
|
a collection of interrelated components that collect, process, store, and provide as output the information needed to complete business tasks
|
|
subsystem
|
a system that is part of a larger system
|
|
supersystem
|
a larger system that contains other systems
|
|
functional decomposition
|
dividing a system into components based on subsystems that in turn are further divided in subsystems
|
|
system boundary
|
the separation between a system and its environment that inputs and outputs must cross
|
|
automation boundary
|
the separation between the automated part of a system and the manual part of a system
|
|
transaction processing systems (TPS)
|
information systems that capture and record information about the transactions that affect the organization
|
|
management information systems (MIS)
|
information systems that take information captured by transaction processing systems and produce reports that management needs for planning and control
|
|
executive information systems (EIS)
|
information systems for executives to use for monitoring the competitive environment and for strategic planning
|
|
decision support systems (DSS)
|
support systems that allow a user to explore the impact of available options or decisions
|
|
communication support systems
|
support systems that allow employees to communicate with each other and with customers and suppliers
|
|
office support systems
|
support systems that help employees create and share documents, including reports, proposals, and memos
|
|
tools
|
software products used to develop analysis and design specifications and completed system components
|
|
techniques
|
strategies for completing specific system development activities
|
|
business process reengineering
|
a technique that seeks to alter the nature of work done in a business function with the objective of radically improving performance
|
|
strategic planning
|
a process during which executives try to answer questions about the company, such as where the business is now, where they want the business to be, and what they have to do to get there
|
|
information systems strategic plan
|
the plan defining the technology and applications that the information systems function needs to support the organization's strategic plan
|
|
application architecture plan
|
a description of the integrated information systems that the organization needs to carry out its business functions
|
|
technology architecture plan
|
a description of the hardware, software, and communications networks required to implement planned information systems
|
|
enterprise resource planning (ERP)
|
a process in which an organization commits to using an integrated set of software packages for key information systems
|
|
supply chain management (SCM)
|
concerns processes that seamlessly integrate product development, product acquisition, manufacturing, and inventory management
|
|
Customer relationship management (CRM)
|
processes that support marketing, sales, and service operations involving direct and indirect customer interaction
|
|
Project
|
a planned undertaking that has a beginning and an end and that produces a desired result or product
|
|
systems development life cycle (SDLC)
|
the entire process of building, deploying, using, and updating an information system
|
|
predictive approach
|
an sdlc approach that assumes the development project can be planned and organized in advance and that the new information system can be developed according to the plan
|
|
adaptive approach
|
an sdlc approach that is more flexible, assuming that the project cannot be planned out completely in advance but must be modified as it progresses
|
|
waterfall approach
|
an sdlc approach that assumes the various phases of a project can be comleted sequentially- one phase leads into the next phase
|
|
spiral model
|
an adaptive sdlc approach that cycles over and over again through development activities until a project is complete
|
|
prototype
|
a preliminary working model showing some aspect of a larger system
|
|
iteration
|
system development process in which work activities- analysis, design, implementation- are done once, then again, and yet again on different system components; they are repeated until the system is closer to what is ultimately needed
|
|
incremental development
|
a development approach that completes parts of a system in several iterations and then puts them into operation for users
|
|
inception (up phase 1)
|
develop an approximate vision of the system, make the buiness case, define the scope, and produce rough estimates for cost and schedule
|
|
elaboration (up phase 2)
|
refine the vision, identify and describe all requirements, finalize the scope, design and implement the core architecture and functions, resolve high risks, and produce realistic estimates for cost and schedule
|
|
construction (up phase 3)
|
iteratively implement the remaining lower-risk, predictable, and easier elements and prepare for deployment
|
|
transition (up phase 4)
|
complete the beta test and deployment so users have a working system and are ready to benefit as expected
|
|
system development methodology
|
guidelines to follow for completing every activity in systems development, including specific models, tools, and techniques
|
|
model
|
representation of an important aspect of the real world
|
|
Unified Modeling Language
|
a standard set of model constructs and notations developed specifically for object-oriented development
|
|
Unified Process (UP)
|
an object-oriented system development methodology originaly developed by Grady Booch, James Rumbaugh, and Ivar Jacobson
|
|
use case
|
an activity the system carries out, usually in response to a request by a user
|
|
discipline
|
a set of functionally related activities that together contribute to one aspect of a UP development project
|
|
artifacts
|
UP work products
|
|
problem domain
|
the area of the user's business that needs an information system solution
|
|
object-oriented approach
|
a system development approach that views an information system as a collection of interacting objects that work together to accomplish tasks
|
|
object
|
a thing in the computer system that can respond to messages
|
|
object-oriented analysis
|
defining all of the types of objects that do the work in a system and showing what user interactions are required to complete tasks
|
|
Object-oriented design
|
defining all of the types of objects necessary to communicate with people and devices in the system, showing how the objects interact to complete tasks, and refining the definition of each type of object so it can be implemented with a specific language or environment
|
|
object-oriented programming
|
writing statements in a programming language to define what each type of object does, including the messages that the objects send to each other
|
|
naturalness
|
characteristic of the object-oriented approach that describes its match with the way people usually think about their world-- that is, it conforms with people's tendency to talk about their work and discuss system requirements in terms of classes of objects
|
|
reuse
|
benefit of the object-oriented approach that allows classes and objects to be invented once and used many times
|
|
user interface object
|
an object the user interacts with while using the system, such as a button, menu item, text box, or label
|
|
attributes
|
object characteristics that have values, such as the size, shape, color, location, and caption of a button or label or the name, address, and phone number of a customer
|
|
problem domain objects
|
objects that are specific to a business application-- for example, customer objects, order objects, and product objects in an order-processing system
|
|
class
|
a type or classification to which all similar objects belong
|
|
instance
|
a synonym for object
|
|
messages
|
communications between objects in which one object asks another object to invoke, or carry out, one of its methods
|
|
encapsulation
|
combining attributes and methods into one unit and hiding its internal structure of objects
|
|
information hiding
|
a characteristic of object-oriented development in which data associated with an object are not visible to the outside world
|
|
identity
|
a unique reference to an object that allows another object to find it and send it a message
|
|
persistent objects
|
objects that a system remembers and that are available for use over time
|
|
inheritance
|
a concept in which one class of objects shares some characteristics of another class
|
|
polymorphism
|
a characteristic of objects that allows them to respond differently to the same message
|
|
repository
|
a database of information about the system used by a CASE tool, including models, descriptions, and references that link the various models
|
|
business benefits
|
improvements or benefits that will acrue to the company as a result of the project and its deliverables
|
|
systems capabilities
|
high-level list of functions that the system must contain to achieve the objectives of the project and produce the defined business benefits
|
|
project charter
|
documents that define the need, objective, benefits, and scope of the new system
|
|
scope creep
|
addition of new functions to the scope of a system that cause the project to increase in size
|
|
essential use case model
|
a model that is often built during the inception phase to define the most critical functions the system must perform to respond to a business event
|
|
work breakdown structure
|
the hierarchy of phases, activities, and tasks of a project; one method to estimate and schedule the tasks of a project
|
|
Effort
|
duration*persons
|
|
critical path
|
a sequence of tasks that cannot be delayed without causing the project to be completed late
|
|
milestone
|
a precise point on the project schedule that indicates a specific completion point
|
|
risk management
|
the project management area that tries to identify potential trouble spots in the project that may jeopardize the successful conclusion of the project
|
|
payback period
|
the point at which the increased cash flow (benefits) exactly pays off the costs of development and operation; sometimes called the breakeven point
|
|
PERT/CPM chart
|
a chart for scheduling a project based on individual tasks or activities and their dependencies
|
|
Gantt chart
|
a bar chart that represents the tasks and activities of the project schedule and tracks the current date and tasks completed
|
|
functional requirement
|
a system requirement that describes an activity or process that the system must perform
|
|
nonfunctional requirement
|
a charateristic of the system other than activities it must perform or support
|
|
technical requirement
|
a system requirement that describes an operational characteristic related to an organization's environment, hardware, and software
|
|
mathematical model
|
a series of formulas that describe technical aspects of a system
|
|
descriptive model
|
narrative memos, reports, or lists that describe some aspect of a system
|
|
graphical model
|
diagrams and schematic representations of some aspect of a system
|
|
activity diagram
|
a type of workflow diagram that describes the user activities and their sequential flow
|
|
synchronization bar
|
a symbol used in an activity diagram to control the splitting or uniting of sequential paths
|
|
discovery prototype
|
a model that is created to verify a concept and then is discarded
|
|
evolving prototype
|
a working model that grows and changes and may become part of a system
|
|
mock-up
|
an example of a final product that is for viewing only, and not executable
|
|
joint application design (JAD)
|
a technique to define requirements or design a system in a single session by having all necessary people participate
|
|
group support system
|
a computer system that enables multiple people to participate with comments at the same time, each user on his or her own computer
|
|
structured walkthrough
|
a review of the findings from your investigation and of the models built based on those findings
|
|
elementary business processes (EBPs)
|
tasks that are performed by one person in one place, in response to a business event, that add measurable business value and leave the system and its data in a consistent state
|
|
event
|
an occurrence at a specific time and place that can be described and is worth remembering
|
|
event decomposition
|
a technique analysts use to identify use cases by first focusing on the events a system must respond to and then looking at how a system responds
|
|
state event
|
an event that occurs when something happens inside the system that triggers the need for processing
|
|
system controls
|
checks or safety procedures put in place to protect the integrity of the system
|
|
perfect technology assumption
|
the assumption that events should be included during early iterations only if the system would be required to respond under perfect conditions
|
|
event table
|
a catalog of sue cases that lists events in rows and key pieces of information about each event in columns
|
|
trigger
|
a signal that tells the system that an event has occurred, either the arrival of data needing processing or a point in time
|
|
source
|
an external agent that supplies data to the system
|
|
response
|
an output, produced by the system, that goes to a destination
|
|
destination
|
an external agent that receives data from the system
|
|
unary (recursive) association
|
a relationship between two things of the same type, such as one person being married to another person
|
|
ternary association
|
a relationship among three different types of things
|
|
n-ary association
|
a relationship among n (any number of) different types of things
|
|
identifier (key)
|
an attribute that uniquely identifies a thing
|
|
compound attribute
|
an attribute that contains a collection of related attributes
|
|
domain model class diagram
|
a UML class diagram that shows the things that are important in the users work: problem domain classes, their associations, and their attributes
|
|
whole-part hierarchies
|
hierarchies that structure classes according to their associated components
|
|
aggregation
|
whole-part relationship in which the parts cannot be dissociated from the object
|
|
abstract class
|
a class that cannot be instantiated (no objects can be created), existing only to allow subclasses to inherit its attributes, methods, and associations
|
|
concrete class
|
a class that can be instantiated (objects can be created)
|
|
location diagram
|
a diagram or map that identifies all of the processing locations of a system
|
|
use case-location matrix
|
a table that describes the relationship among use cases and the locations in which they are performed
|
|
use case-domain class matrix
|
a table that shows which use case requires access to each domain class
|
|
CRUD
|
acronym of create, read, update, and delete
|
|
use case diagram
|
a diagram showing the various user roles and the way those users interact with the system
|
|
system sequence diagram
|
a diagram showing the sequence of messagse between an external actor and the sytem during a use case or scenario
|
|
statechart diagram
|
a diagram showing the life of an object in states and transitions
|
|
scenario, or use case instance
|
a particular sequence of steps within a use case; a use case may have several different scenarios
|
|
precondition
|
a set of criteria that must be true prior to the initiation of a use case
|
|
postcondition
|
a set of criteria that must be true upon completion of the execution of a use case
|
|
interaction diagram
|
either a communication diagram or a sequence diagram that shows the interactions between objects
|
|
lifeline, or object lifeline
|
the vertical line under an object on a sequence diagram to show the passage of time for the object
|