Transcript Document 7155760

Information Systems
Analysis and Design
Myriam Lewkowicz
Outline
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Information Systems: the big picture
Information Systems for competitive advantage
Organizational Information Systems
Entreprise-Wide Information Systems
Information Systems Development & Acquisition
Managing the Information Systems Project
Systems Planning
Determining System Requirements
Structuring System Requirements: Process Modeling
Structuring System Requirements: Conceptual Data Modeling
Object Oriented Analysis and Design
Designing the Human Interface
Systems Implementation and Operation
[email protected]
2
Chapter 1
Information Systems:
The Big Picture
Chapter 1 Objectives
Understand the term information systems (IS)
Understand IS components:
Technology, people, organizations
Understand IS career opportunities
Understand types of information systems
Understand IS and organizational success or
failure
Understand the future of IS management
[email protected]
4
Information Systems Defined
Combinations of hardware, software, and
telecommunications networks that
people build and use to collect, create,
and distribute useful data in organizations
[email protected]
5
Key Elements of Information Systems
[email protected]
6
Data
Data: raw material, unformatted
information
Information: processed data (meaningful)
Knowledge: understanding relationships
between pieces of information
Wisdom: knowledge accumulated and
applied
[email protected]
7
Knowledge as a Business Resource
Knowledge Worker
A well-educated professional who creates,
modifies, or synthesizes knowledge in one’s
profession
Knowledge Society
Also called digital society, new economy
Working with brains instead of hands
The importance of education
Digital divide
[email protected]
8
Technology and Information Systems
Computer-Based Information Systems
One type of technology
Technology – any mechanical and/or electrical means
to supplement, extend, or replace human activity
Information Technology (IT) – machine technology
controlled by or using information
The goal of IS is to provide useful data to users
IS can be local or global, organizational or enterprisewide
[email protected]
9
IS Managerial Personnel
CIO
IS director
Account Executive
Info Center Manager
Development Manager
Project Manager
Maintenance Manager
Systems Manager
IS planning Manager
Operations Manager
Programming Manager
Systems Programming
Manager
Manager of Emerging
Technologies
Telecommunications
Manager
Network Manager
Database Administrator
Auditing or Computer
Security Manager
Quality Assurance
Manager
Webmaster
[email protected]
10
Integrating Skills and Knowledge
Technology
hardware, software, networking
Business
business, management, social,
communications
Systems
Integration, development methods, critical
thinking, problem solving
[email protected]
11
Hot Skills in IS Workers
Office / E-mail
Languages
Applications
RDBS Administration
Development Tools
Internetworking
Operating Systems
LAN Administration
Networking
[email protected]
12
IS Within the Firm
Traditionally a love/hate relationship
“Techies” vs. mere “users” (us vs. them)
Poor service, lousy attitudes
Now: progress toward better customer
service
Better relationships within the company
Cooperation, not rivalry
[email protected]
13
The Spread of Technology in Organizations
Technology infiltrates business units
Dual role for IS workers:
Work with IS technical group
Work with business unit (marketing, finance,
etc.)
[email protected]
14
The Spread of Technology in Organizations
Benefits of centralized IS function
Coordinated planning
Consistent management
Systems compatibility and connectivity
[email protected]
15
Questions
1. Define and understand the term
information systems (IS)
2. Explain the technology, people, and
organizational components of an
information system.
[email protected]
16
Chapter 2
Information Systems for Competitive
Advantage
Chapter 2 Objectives
Understand the IS in automation,
organizational learning, and strategic
support
Understand IS for strategic organizational
success
Understand the need for making an IS
business case
Understand technological innovations to
improve competitive advantage
[email protected]
18
Why Use Information Systems?
Automating: doing things faster
Organizational learning: doing things
better
Supporting Strategy: doing things smarter
[email protected]
19
Automating:
Doing Things Faster
Technology is used to automate a
manual process
Doing things faster, better, cheaper
Greater accuracy and consistency
Loan application example
Manual processing
Technology-supported process
Completely automated
[email protected]
20
Organizational Learning:
Doing Things Better
Going beyond automation
Involves learning to improve the day-to-day activities
within the process
Looking at patterns and trends
Organizational Learning
Using acquired knowledge and insights to improve
organizational behavior
Total Quality Management (TQM)
Monitoring an organization to improve quality of
operations, products, and services
[email protected]
21
Supporting Strategy:
Doing Things Smarter
Strategic Planning
Create a vision: setting the direction
Create a standard: performance targets
Create a strategy: reaching the goal
[email protected]
22
Question
Now, it should be fairly obvious why an IS
professional should be able to make a business
case for a given system. Why, however, is it just
as important for non-IS professionals? How are
they involved in this process? What is their role
in information systems planning?
[email protected]
23
Chapter 3
Organizational
Information Systems
Chapter Objectives
Understand characteristics of operational,
managerial, and executive information systems
Understand characteristics of transaction
processing systems, management information
systems, and executive information systems
Understand characteristics of information
systems that span organizational boundaries
[email protected]
25
Decision-Making Levels of an Organization
[email protected]
26
Decision-Making Levels of an Organization
Executive level (top)
Long-term decisions
Unstructured decisions
Managerial level (middle)
Decisions covering weeks and months
Semistructured decisions
Operational level (bottom)
Day-to-day decisions
Structured decisions
[email protected]
27
General Types of Information Systems
Transaction Processing Systems (TPSs)
Transactions
Used at Operational level of the organization
Goal: to automate repetitive information
processing activities
Increase speed
Increase accuracy
Greater efficiency
[email protected]
28
General Types of Information Systems
Data input
Manual data entry
Semiautomated data entry
Fully automated data entry
Examples:
Payroll
Sales and ordering
Inventory
Purchasing, receiving, shipping
Accounts payable and receivable
[email protected]
29
General Types of Information Systems
Management Information Systems (MISs)
Two Types:
Management of IS in organizations
Specific information systems for mid-level managers
Used at managerial level of the organization
[email protected]
30
General Types of Information Systems
Management Information Systems
Types of reports:
Scheduled report
Key-indicator report
Exception report
Drill-down report
Ad hoc report
[email protected]
31
General Types of Information Systems
Management Information Systems (MISs)
Examples:
Sales forecasting
Financial management and forecasting
Manufacturing planning and scheduling
Inventory management and planning
Advertising and product pricing
[email protected]
32
General Types of Information Systems
Executive Information Systems (EISs)
Used at executive level of the organization
Highly aggregated form
Data types
Soft data – news and nonanalytical data
Hard data – facts and numbers
[email protected]
33
General Types of Information Systems
Executive Information Systems (EISs)
Examples:
Executive-level decision making
Long-range and strategic planning
Monitoring internal and external events
Crisis management
Staffing and labor relations
[email protected]
34
1.35
[email protected]
35
Information Systems that Span Organizational
Boundaries
[email protected]
36
Information Systems that
Span Organizational Boundaries
Decision Support Systems (DSSs)
Designed to support organizational decision
making
“What-if” analysis
Example of a DSS tool: Microsoft Excel
Text and graphs
Models for each of the functional areas
Accounting, finance, personnel, etc.
[email protected]
37
Information Systems that
Span Organizational Boundaries
Expert Systems (ESs)
Mimics human expertise by manipulating
knowledge
Rules (If-then)
Inferencing
[email protected]
38
Information Systems that
Span Organizational Boundaries
Office Automation Systems (OASs)
Examples:
Communicating and scheduling
Document preparation
Analyzing data
Consolidating information
[email protected]
39
Information Systems that
Span Organizational Boundaries
Collaboration Technologies
Virtual teams
Videoconferencing
Groupware
Electronic Meeting Systems (EMSs)
[email protected]
40
Information Systems that
Span Organizational Boundaries
Functional Area Information Systems
Geared toward specific areas in the
company:
Human Resources
Benefits
Marketing
[email protected]
41
[email protected]
42
Information Systems that
Span Organizational Boundaries
Global Information Systems
International IS
Transnational IS
Multinational IS
Global IS
[email protected]
43
Chapter 4
Enterprise-Wide
Information Systems
Chapter Objectives
Understand how information technology
supports business activities
Understand enterprise systems and how
they evolved
Understand software applications that
are internally or externally focused
Understand how to implement enterprise
systems
[email protected]
45
Enterprise Systems
Enterprise systems
Also known as enterprise-wide information
systems
Information systems that allow companies to
integrate information across operations on a
company-wide basis
[email protected]
46
Before an entreprise system
[email protected]
47
With an entreprise sytem
[email protected]
48
Types of Enterprise Systems
Packaged applications
Custom applications
Stand-alone applications
[email protected]
49
Types of Enterprise Systems
Enterprise Resource Planning
Integrated applications
ERP systems
Baan
Oracle
PeopleSoft
SAP
[email protected]
50
Types of Enterprise Systems
ERP Implementation
Modules
Customizations
Best practices
Business process reengineering (BPR)
[email protected]
51
Types of Enterprise Systems
Customer Relationship Management
(CRM)
Sales Force Automation (SFA)
New opportunities for competitive advantage
Examples:
MGM
American Airlines
Marriott International
[email protected]
52
CRM system
[email protected]
53
Types of Enterprise Systems
Supply Chain Management (SCM)
Supply chain – the producers of supplies that
a company uses
Supply network
What if supply chain does not collaborate?
Two objectives of upstream information flow:
Accelerate product development
Reduce costs associated with suppliers
[email protected]
54
Supply chain management
[email protected]
55
The Formula for Enterprise System Success
Secure executive sponsorship
Get help from outside experts
Thoroughly train users
Take a multidisciplinary approach to
implementation
[email protected]
56
Questions
1.
2.
3.
List the different classes of information systems described
in this chapter. How do they differ from each other?
Of the information systems listed in the chapter, how
many do you have experience with? What systems
would you like to work with? What types of systems do
you encounter at the university you are attending?
Consider an organization that you are familiar with,
perhaps the one in which you work or one with which
you have done business. Describe the type of
information systems that organization uses and whether
or not they are useful or up-to-date. List specific
examples for updating or installing information systems
that improve productivity or efficiency.
[email protected]
57
Chapter 5
Information Systems
Development & Acquisition
Chapter Objectives
Understand the process of IS management
Understand the system development life cycle
(SDLC)
Understand alternative approaches to system
development
Understand in-house system development
Understand external acquisition, outsourcing,
and end-user development
[email protected]
59
The Need for Structured Systems
Development
Systems analysis and design – the process
of designing, building, and maintaining
information systems
Systems analyst
Blending technical and managerial expertise
[email protected]
60
The Need for Structured Systems
Development
Evolution of IS development
From “art” to a “discipline”
Standardized development methods
Software engineering
[email protected]
61
The Need for Structured Systems
Development
Options for Obtaining Information Systems
Build your own
Buy a prepackaged system
Outsource development to a 3rd party
End user development
[email protected]
62
The Need for Structured Systems
Development
Information Systems Development in
Action
Breaking large complex problems into
manageable pieces
Decomposing large, complex problems
[email protected]
63
The Need for Structured Systems
Development
System Construction Process
1. Identify a large IT problem to solve
2. Break the large problem into several smaller,
more manageable pieces
3. Translate each “piece” (small problem) into
computer programs
4. Piece together each program into an
overall comprehensive IS that solves the
problem
[email protected]
64
The Need for Structured Systems
Development
The Role of Users in the Systems
Development Process
Knowledgeable of needs
Effective partnership
[email protected]
65
Information Systems Analysis and Design
Systems Analyst performs analysis and
design based upon:
Understanding of organization’s objectives,
structure and processes
Knowledge of how to exploit information
technology for advantage
[email protected]
66
Systems Analysis and Design: Core
Concepts
Major goal: to improve organizational
systems by developing or acquiring
software and training employees in its use
Application software, or a system,
supports organizational functions or
processes
[email protected]
67
Systems Analysis and Design: Core
Concepts
System: Turns data into information and includes:
Hardware and system software
Documentation and training materials
Job roles associated with the system
Controls to prevent theft or fraud
The people who use the software to perform their jobs
[email protected]
68
[email protected]
69
Software Engineering Process
A process used to create an information system
Consists of:
Methodologies
A sequence of step-by-step approaches that help
develop the information system
Techniques
Processes that the analyst follows to ensure thorough,
complete and comprehensive analysis and design
Tools
Computer programs that aid in applying techniques
[email protected]
70
[email protected]
71
System
A system is an interrelated set of business
procedures used within one business unit
working together for a purpose
A system has nine characteristics
A system exists within an environment
A boundary separates a system from its
environment
[email protected]
72
Characteristics of a System
Components
Interrelated Components
Boundary
Purpose
Environment
Interfaces
Constraints
Input
Output
[email protected]
73
[email protected]
74
Important System Concepts
Decomposition
The process of breaking down a system into
smaller components
Allows the systems analyst to:
Break a system into small, manageable subsystems
Focus on one area at a time
Concentrate on component pertinent to one group
of users
Build different components at independent times
[email protected]
75
[email protected]
76
Important System Concepts
Modularity
Process of dividing a system into modules of a
relatively uniform size
Modules simplify system design
Coupling
Subsystems that are dependent upon each
other are coupled
Cohesion
Extent to which a subsystem performs a single
function
[email protected]
77
A Modern Approach to Systems Analysis
and Design
Systems Integration
Allows hardware and software from different
vendors to work together
Enables procedural language systems to work
with visual programming systems
Visual programming environment uses
client/server model
[email protected]
78
Data and Processes
Three key components of an information system
Data
Data Flows
Processing Logic
Data vs. Information
Data
Raw facts
Information
Derived from data
Organized in a manner that humans can
understand
[email protected]
79
Data and Processes
Data
Understanding the source and use of data is key to good
system design
Various techniques are used to describe data and the
relationship amongst data
Data Flows
Groups of data that move and flow through the system
Include description of sources and destination for each data
flow
Processing Logic
Describe steps that transform data and events that trigger
the steps
[email protected]
80
[email protected]
81
Approaches to Systems Development
Process-Oriented Approach
Focus is on flow, use and transformation of
data in an information system
Involves creating graphical representations
such as data flow diagrams and charts
Data are tracked from sources, through
intermediate steps and to final destinations
Natural structure of data is not specified
Disadvantage: data files are tied to specific
applications
[email protected]
82
Approaches to Systems Development (2)
Data-Oriented Approach
Depicts ideal organization of data,
independent of where and how data are
used
Data model describes kinds of data and
business relationships among the data
Business rules depict how organization
captures and processes the data
[email protected]
83
[email protected]
84
Databases and Application Independence
Database
Shared collection of logically related data
Organized to facilitate capture, storage and retrieval
by multiple users
Centrally managed
Designed around subjects
Customers
Suppliers
Application Independence
Separation of data and definition of data from
applications
[email protected]
85
Role of the Systems Analyst
Study problems and needs of an organization
Determine best approach to improving
organization through use of:
People
Methods
Information technology
Help system users and managers define their
requirements for new or enhanced systems
[email protected]
86
Role of the Systems Analyst
Assess options for system implementation
In-house development
Outsourced development
Outsourced development and operation
Commercial application
For in-house projects, work on a team of
analysts and developers
[email protected]
87
Skills of a Successful Systems Analyst
Analytical
Understanding of organizations
Problem-solving skills
System thinking
Ability to see organizations and information systems as systems
Technical
Understanding of potential and limitations of technology
Managerial
Ability to manage projects, resources, risk and change
Interpersonal
Effective written and oral communication skills
[email protected]
88
Systems Development Life Cycle
System Development Methodology
Standard process followed in an organization
Consists of:
Analysis
Design
Implementation
Maintenance
[email protected]
89
Systems Development Life Cycle
Series of steps used to manage the
phases of development for an
information system
Consists of four phases:
Planning and Selection
Analysis
Design
Implementation and Operation
[email protected]
90
Systems Development Life Cycle
Phases are not necessarily sequential
Each phase has a specific outcome and
deliverable
Individual companies use customized life
cycle
[email protected]
91
Phases of the Systems Development Life
Cycle
Systems Planning and Selection
Two Main Activities
Identification of need
Investigation and determination of scope
Systems Analysis
Study of current procedures and information systems
Determine requirements
Generate alternative designs
Compare alternatives
Recommend best alternative
[email protected]
92
Systems Development Life Cycle
System Design
Logical Design
Concentrates on business aspects of the system
Physical Design
Technical specifications
Implementation and Operation
Implementation
Hardware and software installation
Programming
User Training
Documentation
Operation
System changed to reflect changing conditions
System obsolescence
[email protected]
93
[email protected]
94
Alternative approaches
Prototyping
Building a scaled-down working version of the system
Advantages:
Users are involved in design
Captures requirements in concrete form
Rapid Application Development (RAD)
Utilizes prototyping to delay producing system design until
after user requirements are clear
Joint Application Design (JAD)
Users, Managers and Analysts work together for several days
System requirements are reviewed
Structured meetings
[email protected]
95
[email protected]
96
Summary
Information systems analysis and design
Process of developing and maintaining an
information system
Modern approach to systems analysis
Process-Oriented
Data-Oriented
[email protected]
97
Summary
Systems Development Life Cycle (SDLC)
Systems Planning and Selection
Systems Analysis
Systems Design
Systems Implementation
Alternatives to Systems Development Life Cycle
Prototyping
Rapid Application Development (RAD)
Joint Application Design (JAD)
[email protected]
98
Questions
1.
2.
3.
4.
5.
6.
In what way are organizations systems?
List and explain the different phases in the systems
development life cycle.
Why is it important to use systems analysis and design
methodologies when building a system? Why not just
build the system in whatever way seems to be “quick
and easy”? What value is provided by using an
“engineering” approach?
Explain the traditional application-based approach to
systems development. How is this different from the
data-based approach?
What is prototyping?
What is JAD? What is Participatory Design?
[email protected]
99
Chapter 6
Managing the Information Systems Project
Learning Objectives
Discuss skills required to be an effective
project manager
Describe skills and activities of a project
manager during project initiation,
planning, execution and closedown
Explain Gantt Charts and Network
Diagrams
Review commercial project
management software packages
[email protected]
101
Case of Pine Valley Furniture
Manufacturing Company
Product: Wood Furniture
Market: U.S.
Organized into functional areas
Manufacturing
Sales
Three independent computer systems were
converted to a database in 1990s
[email protected]
102
[email protected]
103
Managing the Information Systems Project
Focus of project management
To ensure that information system projects
meet customer expectations
Delivered in a timely manner
Meet constraints and requirements
[email protected]
104
Managing the Information Systems Project
Project Manager
Systems Analyst responsible for
Project initiation
Planning
Execution
Closing down
Requires diverse set of skills
Management
Leadership
Technical
Conflict management
Customer relations
[email protected]
105
[email protected]
106
Project Management Process
Project
Planned undertaking of related activities to reach an
objective that has a beginning and an end
Four Phases
1.
2.
3.
4.
Initiation
Planning
Execution
Closing down
[email protected]
107
Initiating the Project
1.
2.
3.
4.
5.
Establish project initiation team
Establish relationship with customer
Establish project initiation plan
Establish management procedures
Establish project management
environment and workbook
[email protected]
108
Planning the Project
1. Describe project scope, alternatives
and feasibility
Scope and Feasibility
Understand the project
What problem is addressed
What results are to be achieved
Measures of success
Completion criteria
[email protected]
109
Planning the Project
2.
Divide the project into manageable tasks
•
•
3.
4.
Estimate resources and create a resource plan
Develop a preliminary schedule
•
5.
Work breakdown structure
Gantt chart
Utilize Gantt Charts and Network Diagrams
Develop a communication plan
Outline communication processes among customers,
team members and management
Types of reports
Frequency of reports
[email protected]
110
[email protected]
111
Planning the Project
6.
Determine project standards and procedures
Specify how deliverables are tested and produced
7.
Identify and assess risk
Identify sources of risk
Estimate consequences of risk
8.
9.
Create a preliminary budget
Develop a statement of work
Describe what the project will deliver
10. Set a baseline project plan
Estimate of project’s tasks and resources
[email protected]
112
Executing the Project
1.
Execute baseline project plan
Acquire and assign resources
Train new team members
Keep project on schedule
2.
Monitor project progress
Adjust resources, budget and/or activities
3.
Manage changes to baseline project plan
Slipped completion dates
Changes in personnel
New activities
4.
5.
Maintain project workbook
Communicate project status
[email protected]
113
Closing Down the Project
1.
Termination
Types of termination
Natural
Requirements have been met
Unnatural
Project stopped
2.
3.
Documentation
Personnel Appraisal
Conduct post-project reviews
Determine strengths and weaknesses of:
Project deliverables
Project management process
Development process
Close customer contract
[email protected]
114
Representing and Scheduling Project Plans
Gantt Charts
Useful for depicting simple projects or parts
of large projects
Show start and completion dates for
individual tasks
Network Diagrams
Show order of activities
[email protected]
115
[email protected]
116
[email protected]
117
Summary
Skills of an effective project manager
Activities of project manager
Initiation
Planning
Execution
Closedown
Gantt Charts and Network Diagrams
Commercial PM Software
[email protected]
118
Questions
1. List and describe the common skills and activities of a
project manager. Which skill do you think is most
important? Why?
2. Describe the activities performed by the project manager
during project initiation.
3. Describe the activities performed by the project manager
during project planning.
4. Describe the activities performed by the project manager
during project execution.
[email protected]
119
Chapter 7
Systems Planning
Learning Objectives
Discuss the content of and need for a
Statement of Work and Baseline Project
Plan
Describe a structured walkthrough
[email protected]
121
First documents
Baseline Project Plan (BPP) : internal document
Scope
Benefits
Costs
Risks
Resources
Statement of Work (SOW) : Outlines objectives
and constraints of the project to the customer
Describes deliverables
Outlines work needed to be performed
[email protected]
122
[email protected]
123
Building the Baseline Project Plan
Objectives
Assures that customer and development group have a
complete understanding of the proposed system and
requirements
Provides sponsoring organization with a clear idea of
scope, benefits and duration of project
Four Sections
Introduction
System Description
Feasibility Assessment
Management Issues
[email protected]
124
Building the Baseline Project Plan
Introduction
Brief overview
Recommended course of action
Project scope defined
Units affected
Interaction with other systems
Range of system capabilities
[email protected]
125
Building the Baseline Project Plan
System Description
Outline of possible alternative solutions
Narrative format
Feasibility Assessment
Project costs and benefits
Technical difficulties
High-level project schedule
[email protected]
126
Building the Baseline Project Plan
Management Issues
Outlines concerns that management may
have about the project
Team composition
Communication plan
Project standards and procedures
[email protected]
127
[email protected]
128
Reviewing the Baseline Project Plan
Objectives
Assure conformity to organizational standards
All parties agree to continue with project
[email protected]
129
Reviewing the Baseline Project Plan
Walkthrough
Peer group review
Participants
Coordinator
Presenter
User
Secretary
Standards Bearer
Maintenance Oracle
Activities
Walkthrough review form
Individuals polled
Walkthrough action list
Advantages
Assures that review occurs during project
[email protected]
130
[email protected]
131
[email protected]
132
Summary
Baseline Project Plan (BPP)
Created during project initiation and planning
Contains:
Introduction
High-Level description of system
Outline of feasibility
Overview of Management Issues
Statement of Work (SOW)
Describes what project will deliver
Lists all work to be performed
[email protected]
133
Questions
1. What is contained in a Baseline Project
Plan? Are the content and format of all
baseline plans the same? Why or why
not?
2. Describe the structured walkthrough
process. What roles need to be
performed during a walkthrough?
[email protected]
134
Chapter 8
Determining System Requirements
Learning Objectives
Describe options for designing and
conducting interviews
Discuss planning an interview
Discuss using questionnaires to determine
system requirements
Explain advantages and disadvantages
of observing workers and analyzing
business documents to determine
requirements
[email protected]
136
Learning Objectives
Learn about Joint Application Design
(JAD) and Prototyping
Discuss appropriate methods to elicit
system requests
Examine requirements determination for
Internet applications
[email protected]
137
Activities in Requirement Gathering
1.0
Identify the right
Stakeholders &
Artefacts
2.0
Use most appropriate
investigation techniques
4.0
Document the
requirements
3.0
Determine duration
0.0
Outline information
to be sought
Objective: determine the functions
& information that must be provided
by the information system
138
Performing Requirements Determination
Gather information on what the system
should do from many sources
Users
Reports
Forms
Procedures
[email protected]
139
Performing Requirements Determination
Characteristics for gathering requirements
Impertinence
Question everything
Impartiality
Find the best organizational solution
Relaxation of constraints
Attention to detail
Reframing
View the organization in new ways
[email protected]
140
Deliverables and Outcomes
Types of deliverables:
Information collected from users
Existing documents and files
Computer-based information
Understanding of organizational components
Business objective
Information needs
Rules of data processing
Key events
[email protected]
141
Deliverables and Outcomes
[email protected]
142
Traditional Methods for Determining
Requirements
[email protected]
143
Traditional Methods for Determining
Requirements
Interviewing and Listening
Gather facts, opinions and speculations
Observe body language and emotions
Guidelines
Plan
Checklist
Appointment
Be neutral
Listen
Seek a diverse view
Interview Questions
Open-Ended
No prespecified answers
Close-Ended
Respondent is asked to choose from a set of specified responses
[email protected]
144
[email protected]
145
[email protected]
146
[email protected]
147
Traditional Methods for Determining
Requirements
Administering Questionnaires
More cost-effective than interviews
Choosing respondents
Should be representative of all users
Types of samples
Convenient
Random sample
Purposeful sample
Stratified sample
Design
Mostly closed-ended questions
Can be administered over the phone, in person or over
the Internet or company intranet
[email protected]
148
Traditional Methods for Determining
Requirements
Questionnaires Vs. Interviews
Interviews cost more but yield more information
Questionnaires are more cost-effective
[email protected]
149
[email protected]
150
Traditional Methods for Determining
Requirements
Directly Observing Users
Serves as a good method to supplement
interviews
Often difficult to obtain unbiased data
People often work differently when being observed
[email protected]
151
Analyzing Procedures and Other
Documents
Types of information to be discovered:
Problems with existing system
Opportunity to meet new need
Organizational direction
Names of key individuals
Values of organization
Special information processing circumstances
Rules for processing data
[email protected]
152
[email protected]
153
Modern Methods for Determining
Requirements
Joint Application Design (JAD)
Brings together key users, managers and systems
analysts
Purpose: collect system requirements simultaneously
from key people
Conducted off-site
Prototyping
Repetitive process
Rudimentary version of system is built
Replaces or augments SDLC
Goal: to develop concrete specifications for ultimate
system
[email protected]
154
Joint Application Design (JAD)
Participants
Session Leader
Users
Managers
Sponsor
Systems Analysts
Scribe
IS Staff
End Result
Documentation detailing existing system
Features of proposed system
[email protected]
155
[email protected]
156
Prototyping
Quickly converts requirements to working version
of system
Once the user sees requirements converted to
system, will ask for modifications or will generate
additional requests
Most useful when:
User requests are not clear
Few users are involved in the system
Designs are complex and require concrete form
History of communication problems between analysts
and users
Tools are readily available to build prototype
[email protected]
157
Prototyping
Drawbacks
Tendency to avoid formal documentation
Difficult to adapt to more general user
audience
Sharing data with other systems is often not
considered
Systems Development Life Cycle (SDLC)
checks are often bypassed
[email protected]
158
Summary
Interviews
Open-ended and close-ended questions
Preparation is key
Questionnaires
Must be carefully designed
Can contain close-ended as well as openended questions
[email protected]
159
Summary
Other means of gathering requirements
Observing workers
Analyzing business documents
Joint Application Design (JAD)
Prototyping
[email protected]
160
Questions (1)
1. Describe systems analysis and the major activities that occur
during this phase of the systems development life cycle.
2. What are some useful character traits for an analyst involved in
requirements determination?
3. Describe four traditional techniques for collecting information
during analysis. When might one be better than another?
4. What are the general guidelines for conducting interviews?
5. What are the general guidelines for designing questionnaires?
6. Compare collecting information by interview and by
questionnaire. Describe a hypothetical situation in which each
of these methods would be an effective way to collect
information system requirements.
[email protected]
161
Questions (2)
7. What are the general guidelines for collecting
data through observing workers?
8. What are the general guidelines for collecting
data through analyzing documents?
9. Describe how prototyping can be used during
requirements determination. How is it better or
worse than traditional methods?
[email protected]
162
Chapter 9
Structuring System Requirements:
Process Modeling
Learning Objectives
Understand the logical modeling of
processes through studying data flow
diagrams
How to draw data flow diagrams using
rules and guidelines
How to decompose data flow diagrams
into lower-level diagrams
Balancing of data flow diagrams
[email protected]
164
Learning Objectives
Discuss the use of data flow diagrams as
analysis tools
Discuss process modeling for Internet
Applications
[email protected]
165
Process Modeling
Graphically represent the processes that
capture, manipulate, store and distribute
data between a system and its
environment and among system
components
Data flow diagrams (DFD)
Graphically illustrate movement of data
between external entities and the processes
and data stores within a system
[email protected]
166
Process Modeling
Modeling a system’s process
Utilize information gathered during
requirements determination
Structure of the data is also modeled in
addition to the processes
Deliverables and Outcomes
Set of coherent, interrelated data flow
diagrams
[email protected]
167
Process Modeling
Deliverables and outcomes (continued)
Context data flow diagram (DFD)
Scope of system
DFDs of current system
Enables analysts to understand current system
DFDs of new logical system
Technology independent
Show data flows, structure and functional
requirements of new system
[email protected]
168
[email protected]
169
Data Flow Diagramming Mechanics
Data Flow
Depicts data that are in motion and moving
as a unit from one place to another in the
system
Drawn as an arrow
Select a meaningful name to represent the
data
[email protected]
170
Data Flow Diagramming Mechanics
Data Store
Depicts data at rest
May represent data in:
File folder
Computer-based file
Notebook
Drawn as a rectangle with the right hand vertical line
missing
Label includes name of the store as well as the number
[email protected]
171
Data Flow Diagramming Mechanics
Process
Depicts work or action performed on data so
that they are transformed, stored or
distributed
Drawn as a rectangle with rounded corners
Number of process as well as name are
recorded
[email protected]
172
Data Flow Diagramming Mechanics
Source/Sink
Depicts the origin and/or destination of the
data
Sometimes referred to as an external entity
Drawn as a square symbol
Name states what the external agent is
Because they are external, many
characteristics are not of interest to us
[email protected]
173
[email protected]
174
[email protected]
175
Data Flow Diagramming Definitions
Context Diagram
A data flow diagram (DFD) 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
Level-O Diagram
A data flow diagrams (DFD) that represents a system’s
major processes, data flows and data stores at a higher
level
[email protected]
176
Developing DFDs: An Example
Hoosier Burger’s automated food
ordering system
Context Diagram contains no data stores
[email protected]
177
[email protected]
178
Developing DFDs: An Example
Next step is to expand the context
diagram to show the breakdown of
processes
[email protected]
179
[email protected]
180
Data Flow Diagramming Rules
Basic rules that apply to all DFDs
Inputs to a process are always different than
outputs
Objects always have a unique name
In order to keep the diagram uncluttered, you can
repeat data stores and data flows on a diagram
[email protected]
181
Data Flow Diagramming Rules
Process
Data Store
A. No process can have
only outputs (a
miracle)
B. No process can have
only inputs (black
hole)
C. A process has a verb
phrase label
D. Data cannot be moved
from one store to
another
E. Data cannot move from
an outside source to a
data store
F. Data cannot move
directly from a data
store to a data sink
G. Data store has a noun
phrase label
[email protected]
182
Data Flow Diagramming Rules
Source/Sink
Data Flow
H. Data cannot move
I.
directly from a source
to a sink
A source/sink has a
noun phrase label
J. A data flow has only one
direction of flow
between symbols
K. A fork means that
exactly the same data
go from a common
location to two or more
processes, data stores or
sources/sinks
[email protected]
183
Data Flow Diagramming Rules
Data Flow (Continued)
L. A join means that exactly the same data come from
M.
N.
O.
P.
any two or more different processes, data stores or
sources/sinks to a common location
A data flow cannot go directly back to the same
process it leaves
A data flow to a data store means update
A data flow from a data store means retrieve or use
A data flow has a noun phrase label
[email protected]
184
Decomposition of DFDs
Functional decomposition
Act of going from one single system to many
component processes
Repetitive procedure
Lowest level is called a primitive DFD
Level-N Diagrams
A DFD that is the result of n nested decompositions of a
series of subprocesses from a process on a level-0
diagram
[email protected]
185
Balancing DFDs
When decomposing a DFD, you must conserve
inputs to and outputs from a process at the next
level of decomposition
This is called balancing
Example: Hoosier Burgers
In Figure 5-4, notice that there is one input to the
system, the customer order
Three outputs:
Customer receipt
Food order
Management reports
[email protected]
186
Balancing DFDs
Example (Continued)
Notice Figure 5-5. We have the same inputs
and outputs
No new inputs or outputs have been
introduced
We can say that the context diagram and
level-0 DFD are balanced
[email protected]
187
Balancing DFDs:
An Unbalanced Example
In context diagram, we
have one input to the
system, A and one
output, B
Level-0 diagram has
one additional data
flow, C
These DFDs are not
balanced
[email protected]
188
Balancing DFDs
We can split a data flow into separate
data flows on a lower-level diagram
[email protected]
189
Balancing DFDs:
Four Additional Advanced Rules
[email protected]
190
Guidelines for Drawing DFDs
1.
Completeness
DFD must include all components necessary for
system
Each component must be fully described in the
project dictionary or CASE repository
2.
Consistency
The extent to which information contained on one
level of a set of nested DFDs is also included on other
levels
[email protected]
191
Guidelines for Drawing DFDs
3.
Timing
4.
Iterative Development
5.
Primitive DFDs
Time is not represented well on DFDs
Best to draw DFDs as if the system has never started
and will never stop
Analyst should expect to redraw diagram several
times before reaching the closest approximation to
the system being modeled
Lowest logical level of decomposition
Decision has to be made when to stop
decomposition
[email protected]
192
Using DFDs as Analysis Tools
Gap Analysis
The process of discovering discrepancies
between two or more sets of data flow
diagrams or discrepancies within a single DFD
Inefficiencies in a system can often be
identified through DFDs
[email protected]
193
Using DFDs in Business Process
Reengineering
Example: IBM Credit
Credit approval
process required six
days before Business
Process
Reengineering (see
Fig 5-12)
[email protected]
194
Using DFDs in Business Process
Reengineering
After Business
Reprocess
Engineering, IBM was
able to process 100
times the number of
transactions in the
same amount of time
[email protected]
195
Summary
Data flow diagrams (DFD)
Symbols
Rules for creating
Decomposition
Balancing
DFDs for Analysis
DFDs for Business Process Reengineering
(BPR)
[email protected]
196
Questions
1. What is a data flow diagram? Why do systems
analysts use data flow diagrams?
2. What is decomposition? What is balancing?
How can you determine if DFDs are not
balanced?
3. Explain the convention for naming different
levels of data flow diagrams.
4. How can data flow diagrams be used as
analysis tools?
[email protected]
197
Chapter 10
Structuring System Requirements:
Conceptual Data Modeling
Learning Objectives
Define key data-modeling terms
Conceptual data model
Entity-Relationship (E-R) diagram
Entity type
Entity instance
Attribute
Candidate key
Multivalued attributes
Relationship
Degree
Cardinality
Associative entity
[email protected]
199
Learning Objectives
Ask the right kinds of questions to determine
data requirements for an IS
Learn to draw entity-relationship diagrams (ERD)
Review the role of conceptual data modeling in
overall design and analysis of an information
system
Discuss relationships and associative entities
Discuss relationship between data modeling and
process modeling
[email protected]
200
Conceptual Data Modeling
Representation of organizational data
Purpose is to show rules about the meaning and
interrelationships among data
Entity-Relationship (E-R) diagrams are commonly used to
show how data are organized
Main goal of conceptual data modeling is to create
accurate E-R diagrams
Methods such as interviewing, questionnaires and JAD are
used to collect information
Consistency must be maintained between process flow,
decision logic and data modeling descriptions
[email protected]
201
Process of Conceptual Data Modeling
First step is to develop a data model for the
system being replaced
Next, a new conceptual data model is built that
includes all the requirements of the new system
In the design stage, the conceptual data model
is translated into a physical design
Project repository links all design and data
modeling steps performed during SDLC
[email protected]
202
Deliverables and Outcomes
Primary deliverable is the entity-relationship
diagram
There may be as many as 4 E-R diagrams
produced and analyzed during conceptual
data modeling
Covers just data needed in the project’s application
E-R diagram for system being replaced
An E-R diagram for the whole database from which the
new application’s data are extracted
An E-R diagram for the whole database from which
data for the application system being replaced are
drawn
[email protected]
203
[email protected]
204
Deliverables and Outcomes
Second deliverable is a set of entries about data
objects to be stored in repository or project
dictionary
Repository links data, process and logic models of an
information system
Data elements that are included in the DFD must
appear in the data model and conversely
Each data store in a process model must relate to
business objects represented in the data model
[email protected]
205
Gathering Information for Conceptual Data
Modeling
Two perspectives
Top-down
Data model is derived from an intimate
understanding of the business
Bottom-up
Data model is derived by reviewing specifications
and business documents
[email protected]
206
Introduction to Entity-Relationship (E-R)
Modeling
Notation uses three main constructs
Data entities
Relationships
Attributes
Entity-Relationship (E-R) Diagram
A detailed, logical and graphical
representation of the entities, associations
and data elements for an organization or
business
[email protected]
207
Entity-Relationship (E-R) Modeling
Key Terms
Entity
A person, place, object, event or concept in the user
environment about which the organization wishes to
maintain data
Represented by a rectangle in E-R diagrams
Entity Type
A collection of entities that share common properties or
characteristics
Attribute
A named property or characteristic of an entity that is
of interest to an organization
[email protected]
208
[email protected]
209
Entity-Relationship (E-R) Modeling
Key Terms
Candidate keys and identifiers
Each entity type must have an attribute or set
of attributes that distinguishes one instance
from other instances of the same type
Candidate key
Attribute (or combination of attributes) that uniquely
identifies each instance of an entity type
[email protected]
210
Entity-Relationship (E-R) Modeling
Key Terms
Identifier
A candidate key that has been selected as
the unique identifying characteristic for an
entity type
Selection rules for an identifier
Choose a candidate key that will not change its
value
Choose a candidate key that will never be null
Avoid using intelligent keys
Consider substituting single value surrogate keys for
large composite keys
[email protected]
211
Entity-Relationship (E-R) Modeling
Key Terms
Multivalued Attribute
An attribute that may take on more than one
value for each entity instance
Represented on E-R Diagram in two ways:
Double-lined ellipse
Weak entity
[email protected]
212
Entity-Relationship (E-R) Modeling
Key Terms
Relationship
An association between the instances of one
or more entity types that is of interest to the
organization
Association indicates that an event has
occurred or that there is a natural link
between entity types
Relationships are always labeled with verb
phrases
[email protected]
213
Conceptual Data Modeling and the E-R
Diagram
Goal
Capture as much of the meaning of the data
as possible
Result
A better design that is easier to maintain
[email protected]
214
Degree of Relationship
Degree
Number of entity types that participate in a relationship
Three cases
Unary
A relationship between the instances of one entity type
Binary
A relationship between the instances of two entity types
Ternary
A simultaneous relationship among the instances of three
entity types
Not the same as three binary relationships
[email protected]
215
[email protected]
216
Cardinality
The number of instances of entity B that can be
associated with each instance of entity A
Minimum Cardinality
The minimum number of instances of entity B that may
be associated with each instance of entity A
Maximum Cardinality
The maximum number of instances of entity B that may
be associated with each instance of entity A
[email protected]
217
Electronic Commerce Development:
Conceptual Data Model
Conceptual data modeling for Internet
applications is no different than the
processed followed for other types of
applications
Pine Valley Furniture WebStore
Four entity types defined
Customer
Inventory
Order
Shopping cart
[email protected]
218
[email protected]
219
[email protected]
220
ER diagram for Pine Valley furniture
[email protected]
222
Summary
Process of conceptual data modeling
Deliverables
Gathering information
Entity-Relationship Modeling
Entities
Attributes
Candidate keys and identifiers
Multivalued attributes
Degree of relationship
[email protected]
223
Summary
Cardinality
Associative entities
Conceptual data modeling and Internet
development
[email protected]
224
Questions
1. List the four types of E-R diagrams produced and analyzed
during conceptual data modeling.
2. What elements of a data flow diagram should be analyzed as
part of data modeling?
3. What is the degree of a relationship? Give an example of each
of the relationship degrees illustrated in this chapter.
4. Explain why a ternary relationship is not the same as three binary
relationships.
5. Which of the following types of relationships can have attributes
associated with them: one-to-one, one-to-many, many-tomany?
6. Give an example of a ternary relationship (different from any
example in this chapter.)
[email protected]
225
Chapter 11
Object-Oriented Analysis and Design
Learning Objectives
Discuss the concepts and principles
underlying the object-oriented approach
Learn to develop requirements models
using use-case diagrams
Learn to develop requirements models
using state and sequence diagrams
Learn to use class diagrams to develop
object models of the problem domain
[email protected]
227
The Object-Oriented Modeling Approach
Benefits
1.
2.
3.
4.
5.
The ability to tackle more challenging problem
domains
Improved communication among users, analysts,
designers and programmers
Reusability of analysis, design and programming
results
Increased consistency among the models
developed during object-oriented analysis, design,
and programming
Explicit representation of commonality among system
components
[email protected]
228
The Object-Oriented Modeling Approach
Object-Oriented systems development
life cycle:
Process of progressively developing
representation of a system component
(or object) through the phases of
analysis, design and implementation
The model is abstract in the early stages
As the model evolves, it becomes more
and more detailed
[email protected]
229
The Object-Oriented Systems Development
Life Cycle
Analysis Phase
Model of the real-world application is developed
showing its important properties
Model specifies the functional behavior of the
system independent of implementation details
Design Phase
Analysis model is refined and adapted to the
environment
Implementation Phase
Design is implemented using a programming
language or database management system
[email protected]
230
The Object-Oriented Systems Development
Life Cycle
Unified Modeling Language (UML)
A notation that allows the modeler to specify,
visualize and construct the artifacts of
software systems, as well as business models
Techniques and notations
Use cases
Sequence diagrams
Activity diagrams
Class diagrams
State diagrams
[email protected]
231
An architecture-based vision
Functional needs
Major classes
coding
Logical View
Components View
Use Case View
Process View
Deployment View
Servers and
network organization
System performances
[email protected]
232
1
Statecharts Diagrams
Dynamic modelling,
focusing on an object.
Activities done in each
state correspond to
operations
Collaboration diagram
Dynamic modelling,
focusing on spatial
relationships between
objects
Class Diagrams
Static modelling
System’s structure
Objects Diagrams
Static modelling
Context
Use Cases diagrams
Functional modelling
Sequence Diagrams
Dynamic modelling of
scenarios
Activity Diagrams
Dynamic modelling,
focusing on an activity
[email protected]
233
Use-Case Modeling
Applied to analyze functional requirements of
the system
Performed during the analysis phase to help
developers understand functional requirements
of the system without regard for implementation
details
Use Case
A complete sequence of related actions initiated by
an actor
Actor
An external entity that interacts with the system
[email protected]
234
Use-Case Modeling
Use cases are always initiated by an
actor
Use cases represent complete
functionality of the system
Use cases may participate in relationships
with other use-cases
Use cases may also use other use cases
[email protected]
235
Use cases diagram
Use cases diagrams describe what a system does from the
standpoint of an external observer. The emphasis is on
what a system does rather than how.
Use cases diagrams are closely connected to scenarios. A
scenario is an example of what happens when someone
interacts with the system.
Here is a scenario for a medical clinic:
1. A patient calls the clinic to make an appointment for a yearly
checkup.
2. The receptionist finds the nearest empty time slot in the
appointment book
3. and schedules the appointment for that time slot
A use case is a summary of scenarios for a single task or
goal. An actor is who or what initiates the events involved
in that task. Actors are simply roles that people or objects
play
[email protected]
236
A use case and his actor
[email protected]
237
A use case diagram
[email protected]
238
[email protected]
239
Explanation
A system boundary rectangle separates the clinic system from the
external actors.
A use case generalization shows that one use case is simply a special kind
of another. Pay Bill is a parent use case and Bill Insurance is the child. A
child can be substituted for its parent whenever necessary.
Generalization appears as a line with a triangular arrow head toward the
parent use case.
Include relationships factor use cases into additional ones. Includes are
especially helpful when the same use case can be factored out of two
different use cases. Both Make Appointment and Request Medication
include Check Patient Record as a subtask. In the diagram, include
notation is a dotted line beginning at base use case ending with an
arrows pointing to the include use case. The dotted line is labeled
<<include>>.
An extend relationship indicates that one use case is a variation of
another. Extend notation is a dotted line, labeled <<extend>>, and with
an arrow toward the base case. The extension point, which determines
when the extended case is appropriate, is written inside the base case.
[email protected]
240
[email protected]
241
Use case diagrams are helpful in three areas
Determining features (requirements). New use
cases often generate new requirements as the
system is analyzed and the design takes shape.
Communicating with clients. Their notational
simplicity makes use case diagrams a good way
for developers to communicate with clients.
Generating test cases. The collection of
scenarios for a use case may suggest a suite of
test cases for those scenarios.
[email protected]
242
Use case example
Online HR system
[email protected]
244
[email protected]
245
Update Benefits description
[email protected]
246
Dynamic Modeling:
Sequence Diagrams
Sequence Diagram
A depiction of the interaction among objects during
certain periods of time
Activation
The time period during which an object performs an
operation
Messages
Means by which objects communicate with each other
[email protected]
247
[email protected]
248
[email protected]
249
Explanation
The Reservation window sends a makeReservation() message to
a HotelChain. The HotelChain then sends a makeReservation()
message to a Hotel. If the Hotel has available rooms, then it
makes a Reservation and a Confirmation.
Each vertical dotted line is a lifeline, representing the time that
an object exists. Each arrow is a message call. An arrow goes
from the sender to the top of the activation bar of the message
on the receiver's lifeline. The activation bar represents the
duration of execution of the message.
In our diagram, the Hotel issues a self call to determine if a room
is available. If so, then the Hotel creates a Reservation and a
Confirmation. The asterisk on the self call means iteration (to
make sure there is available room for each day of the stay in the
hotel). The expression in square brackets, [ ], is a condition.
The diagram has a clarifying note, which is text inside a dogeared rectangle. Notes can be put into any kind of UML
diagram.
[email protected]
250
Collaboration diagram
Collaboration diagrams are also interaction diagrams.
They convey the same information as sequence diagrams,
but they focus on object roles instead of the times that
messages are sent. In a sequence diagram, object roles
are the vertices and messages are the connecting links.
The object-role rectangles are labeled with either class or
object names (or both). Class names are preceded by
colons ( : ).
Each message in a collaboration diagram has a sequence
number. The top-level message is numbered 1. Messages
at the same level (sent during the same call) have the
same decimal prefix but suffixes of 1, 2, etc. according to
when they occur.
[email protected]
251
Collaboration diagram
[email protected]
252
Activity diagram
An activity diagram is essentially a fancy flowchart.
Activity diagrams and statechart diagrams are related
While a statechart diagram focuses attention on an object
undergoing a process (or on a process as an object), an
activity diagram focuses on the flow of activities involved in a
single process. The activity diagram shows the how those
activities depend on one another.
For our example, we used the following process.
"Withdraw money from a bank account through an ATM."
The three involved classes (people, etc.) of the activity are
Customer, ATM, and Bank. The process begins at the black
start circle at the top and ends at the concentric white/black
stop circles at the bottom. The activities are rounded
rectangles.
[email protected]
253
[email protected]
254
Class diagrams
A Class diagram gives an overview of a
system by showing its classes and the
relationships among them.
Class diagrams are static: they display
what interacts but not what happens
when they do interact
[email protected]
255
Class notations
[email protected]
256
Class stereotypes
[email protected]
257
Example
The following class diagram models a
customer order from a retail catalog.
The central class is the Order.
Associated with it are the Customer making
the purchase and the Payment.
A Payment is one of three kinds: Cash, Check, or
Credit.
The order contains OrderDetails (line items), each
with its associated Item.
[email protected]
258
[email protected]
259
Representing Associations
Association
A relationship between object classes
Degree may be unary, binary, ternary or higher
Depicted as a solid line between participating
classes
Association Role
The end of an association where it connects to a
class
Each role has multiplicity, which indicates how
many objects participate in a given association
relationship
[email protected]
260
[email protected]
261
Representing Generalization
Generalization
Abstraction of common features among multiple
classes, as well as their relationships, into a more
general class
Subclass
A class that has been generalized
Superclass
A class that is composed of several generalized
subclasses
[email protected]
262
Representing Generalization
Discriminator
Shows which property of an object class is being
abstracted by a generalization relationship
Inheritance
A property that a subclass inherits the features from its
superclass
Abstract Class
A class that has no direct instances, but whose
descendents may have direct instances
Concrete Class
A class that can have direct instances
[email protected]
263
[email protected]
264
[email protected]
265
Representing Aggregation
Aggregation
A part-of relationship between a component
object and an aggregate object
Example: Personal computer
Composed of CPU, Monitor, Keyboard, etc
[email protected]
266
Composition and Aggregation
Associations in which an object is part of a whole
are aggregations.
Composition is a strong association in which the
part can belong to only one whole
The part cannot exist without the whole. Composition is
denoted by a filled diamond at the whole end.
The following diagram shows that a BoxOffice
belongs to exactly one MovieTheater. Destroy
the MovieTheater and the BoxOffice goes away!
The collection of Movies is not so closely bound to the
MovieTheater.
[email protected]
267
[email protected]
268
Dependencies and constraints
A dependency is a relation between two classes
in which a change in one may force changes in
the other. Dependencies are drawn as dotted
lines.
In the class diagram below, Co_op depends on
Company. If you decide to modify Company, you may
have to change Co_op too.
A constraint is a condition that every
implementation of the design must satisfy.
Constraints are written in curly braces { }.
The constraint on our diagram indicates that a Section
can be part of a CourseSchedule only if it is not
canceled.
[email protected]
269
[email protected]
270
Packages
To simplify complex class diagrams, you can
group classes into packages.
A package is a collection of logically related
UML elements.
Packages appear as rectangles with small tabs at the
top.
The package name is on the tab or inside the
rectangle.
The dotted arrows are dependencies: One package
depends on another if changes in the other could
possibly force changes in the first.
[email protected]
271
[email protected]
272
Object diagrams
Object diagrams show instances instead
of classes. They are useful for explaining
small pieces with complicated
relationships, especially recursive
relationships.
This small class diagram shows that a
university Department can contain lots of
other Departments.
[email protected]
273
[email protected]
274
Object Modeling
Object Diagrams
Object Diagram
also called an instance diagram
Object is represented as a rectangle with two
compartments
Operation
A function or service that is provided by all the
instances of a class
Encapsulation
The technique of hiding the internal implementation
details of an object from its external view
[email protected]
275
Objects notations
[email protected]
276
[email protected]
277
Statecharts diagram
Objects have behaviors and state. The state of an object
depends on its current activity or condition. A statechart
diagram shows the possible states of the object and the
transitions that cause a change in state.
State
A condition during the life of an object during which it satisfies some
conditions, performs some actions or waits for some events
Shown as a rectangle with rounded corners
State Transition
The changes in the attribute of an object or in the links an object has
with other objects
Shown as a solid arrow
Diagrammed with a guard condition and action
Event
Something that takes place at a certain point in time
[email protected]
278
Example
Our example diagram models the login part of
an online banking system.
Logging in consists of entering a valid social security
number and personal id number, then submitting the
information for validation.
Logging in can be factored into four non-overlapping
states: Getting SSN, Getting PIN, Validating, and
Rejecting.
From each state comes a complete set of transitions
that determine the subsequent state.
[email protected]
279
[email protected]
280
Explanation
Our diagram has two self-transition, one on
Getting SSN and another on Getting PIN.
The initial state (black circle) is a dummy to start
the action. Final states are also dummy states
that terminate the action.
The action that occurs as a result of an event or
condition is expressed in the form /action.
While in its Validating state, the object does not
wait for an outside event to trigger a transition.
Instead, it performs an activity. The result of that
activity determines its subsequent state.
[email protected]
281
[email protected]
282
Moving to Design
Start with existing set of analysis model
Progressively add technical details
Design model must be more detailed than
analysis model
Component Diagram
A diagram that shows the software components or
modules and their dependencies
Deployment Diagram
A diagram that shows how the software components,
process and objects are deployed into the physical
architecture of the system
[email protected]
283
Component and deployment diagrams
A component is a code module. Component
diagrams are physical analogs of class diagram.
Deployment diagrams show the physical
configurations of software and hardware.
The following deployment diagram shows the
relationships among software and hardware
components involved in real estate transactions.
The physical hardware is made up of nodes.
Each component belongs on a node.
Components are shown as rectangles with two
tabs at the upper left.
[email protected]
284
[email protected]
285
Summary
Object-Oriented modeling approach
Benefits
Unified Modeling Language
Use cases
Class diagrams
State diagrams
Sequence diagrams
Use-case modeling
[email protected]
286
Summary
Object Modeling: Class Diagrams
Associations
Generalizations
Aggregation
Dynamic Modeling: State Diagrams
Dynamic Modeling: Sequence
Diagrams
Moving to Design
[email protected]
287
Chapter 12
Designing the Human Interface
Learning Objectives
Explain the process of designing forms and
reports and the deliverables for their creation
Discuss general guidelines for formatting text,
tables and lists
Learn how to effectively format text, tables and
lists
Explain the process of designing interfaces and
dialogues and the deliverables for their creation
[email protected]
289
Learning Objectives
Discuss the general guidelines for interface
design including:
Layout and design
Structuring data entry fields
Providing feedback
System help
Discuss the design of human-computer
dialogues and the use of dialogue diagramming
Explain interface design guidelines unique to the
design of Internet-based electronic commerce
systems
[email protected]
290
Designing Forms and Reports
System inputs and outputs are produced
at the end of the analysis phase
Precise appearance was not defined during
this phase
Forms and reports are integrally related to
DFD and E-R diagrams
[email protected]
291
Designing Forms and Reports:
Key Concepts
Form
A business document that contains some predefined
data and may include some areas where additional
data are to be filled in
An instance of a form is typically based on one
database record
Report
A business document that contains only predefined
data
A passive document for reading or viewing data
Typically contains data from many database records or
transactions
[email protected]
292
The Process of Designing Forms and Reports
User-focused activity
Follows a prototyping approach
Requirements determination
Who will use the form or report?
What is the purpose of the form or report?
When is the report needed or used?
Where does the form or report need to be delivered
and used?
How many people need to use or view the form or
report?
[email protected]
293
The Process of Designing Forms and Reports
Prototyping
Initial prototype is designed from requirements
Users review prototype design and either
accept the design or request changes
If changes are requested, the constructionevaluation-request cycle is repeated until the
design is accepted
[email protected]
294
Deliverables and Outcomes
Design specifications are major
deliverable and contain three sections
1. Narrative
2. Screen Design
3. Testing and usability assessment
[email protected]
295
General Formatting Guidelines for Forms
and Reports
Highlighting
Use sparingly to draw user to or away from
certain information
Blinking and audible tones should only be
used to highlight critical information requiring
user’s immediate attention
Methods should be consistently selected and
used based upon level of importance of
emphasized information
[email protected]
296
[email protected]
297
[email protected]
298
General Formatting Guidelines for Forms and
Reports
Displaying Text
Display text in mixed upper- and lowercase and use
conventional punctuation
Use double spacing if space permits. If not, place a
blank line between paragraphs
Left-justify text and leave a ragged right margin
Do not hyphenate words between lines
Use abbreviations and acronyms only when they are
widely understood by users and are significantly shorter
than the full text
[email protected]
299
General Formatting Guidelines for Forms
and Reports
Displaying tables and lists
Labels
All columns and rows should have meaningful labels
Labels should be separated from other information
by using highlighting
Redisplay labels when the data extend beyond a
single screen or page
[email protected]
300
General Formatting Guidelines for Forms and
Reports
Displaying tables and lists (continued)
Formatting columns, rows and text
Sort in a meaningful order
Place a blank line between every 5 rows in long columns
Similar information displayed in multiple columns should
be sorted vertically
Columns should have at least two spaces between them
Allow white space on printed reports for user to write
notes
Use a single typeface, except for emphasis
Use same family of typefaces within and across displays
and reports
Avoid overly fancy fonts
[email protected]
301
General Formatting Guidelines for Forms and
Reports
Displaying tables and lists (continued)
Formatting numeric, textual and
alphanumeric data
Right-justify numeric data and align columns by
decimal points or other delimiter
Left-justify textual data. Use short line length, usually
30 to 40 characters per line
Break long sequences of alphanumeric data into
small groups of three to four characters each
[email protected]
302
[email protected]
303
[email protected]
304
[email protected]
305
Designing Interfaces and Dialogues
Focus on how information is provided to
and captured from users
Dialogues are analogous to a
conversation between two people
A good human-computer interface
provides a unifying structure for finding,
viewing and invoking the different
components of a system
[email protected]
306
Designing Interfaces
Designing Layouts
Standard formats similar to paper-based forms
and reports should be used
Screen navigation on data entry screens
should be left-to-right, top-to-bottom as on
paper forms
[email protected]
307
Designing Layouts
Flexibility and consistency are primary
design goals
Users should be able to move freely between
fields
Data should not be permanently saved until
the user explicitly requests this
Each key and command should be assigned
to one function
[email protected]
308
Structuring Data Entry
Entry
Never require data that are already online or
that can be computed
Defaults
Always provide default values when
appropriate
Units
Make clear the type of data units requested
for entry
Replacement Use character replacement when appropriate
Captioning
Always place a caption adjacent to fields
Format
Provide formatting examples
Justify
Automatically justify data entries
Help
Provide context-sensitive help when
appropriate
[email protected]
309
Controlling Data Input
One objective of interface design is to reduce
data entry errors
Role of systems analyst is to anticipate user errors
and design features into the system’s interfaces
to avoid, detect, and correct data entry
mistakes
Table 8-9 describes types of data entry errors
Table 8-10 lists techniques used by system
designers to detect errors
[email protected]
310
[email protected]
311
[email protected]
312
Providing Feedback
1.
Status Information
Keeps users informed of what is going on in system
Displaying status information is especially important if
the operation takes longer than a second or two
2.
Prompting Cues
Best to keep as specific as possible
3.
Error and Warning Messages
Messages should be specific and free of error codes
and jargon
User should be guided toward a result rather than
scolded
Use terms familiar to user
Be consistent in format and placement of messages
[email protected]
313
Providing Help
Place yourself in user’s place when designing
help
Guidelines
Simplicity
Help messages should be short and to the point
Organization
Information in help messages should be easily absorbed
by users
Demonstrate
It is useful to explicitly show users how to perform an
operation
[email protected]
314
Providing Help
Context-Sensitive Help
Enables user to get field-specific help
Users should always be returned to where
they were when requesting help
[email protected]
315
Designing Dialogues
Dialogue
Sequence in which information is displayed to and
obtained from a user
Primary design guideline is consistency in
sequence of actions, keystrokes, and
terminology
Three-step process
1. Design dialogue sequence
2. Build a prototype
3. Assess usability
[email protected]
316
Designing the Dialogue Sequence
Define the sequence
Have a clear understanding of the user, task,
technological and environmental characteristics
Dialogue Diagram
A formal method for designing and representing
human-computer dialogues using box and line
diagrams
Consists of a box with three sections
Top: Unique display reference number used by other
displays for referencing dialogue
Middle: Contains the name or description of the display
Bottom: Contains display reference numbers that can be
accessed from the current display
[email protected]
317
[email protected]
318
Designing Dialogues:
Building Prototypes and Assessing Usability
Often optional activities
Task is simplified by using graphical design
environment
[email protected]
319
[email protected]
320
Web-based Application:
Designing Interfaces and Dialogues for Pine Valley Furniture’s
Webstore
General Guidelines
Several factors have contributed to poor
design of Web interfaces
Web’s single “click-to-act” method of loading static
hypertext documents
Limited capabilities of most Web-browsers to
support finely grained user interactivity
Limited agreed-upon standards for encoding Web
content and control mechanisms
Lack of maturity in Web scripting and programming
languages
[email protected]
321
Web-based Application:
Designing the Human Interface at Pine Valley Furniture
Design Guidelines
Navigation via cookie crumbs
A technique that uses a series of tabs on a Web
page to show users where they are and where they
have been in the site
Tabs are hyperlinks to allow users to move
backward easily within the site
Two important purposes
Allows users to navigate to a point previously visited
Shows users where they have been and how far they
have gone from point of entry into site
[email protected]
322
Web-based Application:
Design Guidelines
Lightweight Graphics
The use of small images to allow a Web page
to be displayed more quickly
Forms and Data Integrity
All forms that record information should be
clearly labeled and provide room for input
Clear examples of input should be provided
to reduce data errors
Site must clearly designate which fields are
required, which are optional and which have
a range of values
[email protected]
323
Summary
Designing Forms and Reports
General guidelines for designing forms
and reports
Formatting text, tables and lists
Design guidelines for interfaces
Layout design
Structuring data entry fields
Providing feedback
Designing help
[email protected]
324
Questions
1. To which initial questions must the
analyst gain answers in order to build an
initial prototype of a system output?
2. Describe the process of designing
interfaces and dialogues. What
deliverables are produced from this
process? Are these deliverables the
same for all types of system projects?
Why or why not?
[email protected]
325
Chapter 13
Systems Implementation and Operation
Learning Objectives
Describe the process of coding, testing and converting an
organizational information system
Discuss four installation strategies
Direct
Parallel
Single location
Phased installation
Describe the deliverables for documenting the system and
for training and supporting the users
Compare the many modes available for organizational
system training, including self-training and electronic
performance support systems
[email protected]
327
Learning Objectives
Discuss the issues of providing support to
end users
Discuss system implementation failure
Explain four types of maintenance
Describe several factors that influence
the cost of maintaining an information
system
[email protected]
328
System Implementation and Maintenance
Seven major activities
Coding
Testing
Installation
Documentation
Training
Support
Maintenance
Purpose
To convert final physical system specifications into working
and reliable software
To document work that has been done
To provide help for current and future users
[email protected]
329
The Process of Coding, Testing and
Installation
Coding
Physical design specifications are turned into working
computer code
Testing
Tests are performed using various strategies
Testing can be performed in parallel with coding
Installation
Process during which the current system is replaced by
the new system
[email protected]
330
Deliverables
Action
Deliverable
Coding
Code
Program Documentation
Test scenarios (test plan) and test data
Results of program and system testing
User guides
User training plans
Installation and conversion plan
Testing
Installation
[email protected]
331
The Process of Documenting the System, Training
Users and Supporting Users
Two audiences for documentation
The information systems personnel who will
maintain the system throughout its productive life
The people who will use the system as part of
their daily lives
[email protected]
332
Deliverables
Documentation
System documentation
User documentation
User training plan
Classes
Tutorials
User training modules
Training materials
Computer-based training aids
User support plan
Help desk
On-line help
Bulletin boards and other support mechanisms
[email protected]
333
The Process of Maintaining Information
Systems
Process of returning to the beginning of
the SDLC and repeating development
steps focusing on system change until the
change is implemented
Four major activities
1.
2.
3.
4.
Obtaining maintenance requests
Transforming requests into changes
Designing changes
Implementing changes
[email protected]
334
[email protected]
335
Deliverables
Development of a new version of the
software, new versions of all design
documents and training materials
created or modified during the
maintenance effort
[email protected]
336
Software Application Testing
A test plan is developed during the analysis
phase
During the design phase, a unit test plan and a
system test plan are developed
The actual testing is done during implementation
Test plans provide improved communication
among all parties involved in testing
Serve as checklists
[email protected]
337
Types of Testing
Inspection
A testing technique in which participants examine
program code for predictable language-specific errors
Walkthrough
A peer group review of any product created during
the systems development process; also called a
structured walkthrough
Desk Checking
A testing technique in which the program code is
sequentially executed manually by the reviewer
[email protected]
338
Types of Testing
Unit Testing
Each module is tested alone in an attempt to
discover any errors in its code, also called module
testing
Integration Testing
The process of bringing together all of the modules
that a program comprises for testing purposes.
Modules are typically integrated in a top-down,
incremental fashion
[email protected]
339
Types of Testing
System Testing
The bringing together of all the programs that a
system comprises for testing purposes. Programs
are typically integrated in a top-down, incremental
fashion
Stub Testing
A technique used in testing, 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
[email protected]
340
The Testing Process
1. The purpose of the testing is confirming that
the system satisfies requirements
2. Testing must be planned
Test Case
A specific scenario of transactions, queries or
navigation paths that represent a typical, critical
or abnormal use of the system
Test cases and results should be thoroughly
documented so they can be repeated for each
revision of an application
[email protected]
341
[email protected]
342
Acceptance Testing by Users
The process whereby actual users test a
completed information system, the end
result of which is the users’ acceptance
of it
[email protected]
343
Acceptance Testing by Users
Alpha Testing
User testing of a completed information system using
simulated data
Recovery testing
Forces the software (or environment) to fail in order to
verify that recovery is properly performed
Security testing
Verifies that protection mechanisms built into the system
will protect it from improper penetration
Stress testing
Tries to break the system
Performance testing
Determines how the system performs on the range of
possible environments in which it may be used
[email protected]
344
Acceptance Testing by Users
Beta Testing
User testing of a completed information
system using real data in the real user
environment
[email protected]
345
Installation
The organizational process of changing over
from the current information system to a new
one
Four approaches
Direct Installation
Changing over from the old information system to a
new one by turning off the old system when the new
one is turned on
Parallel Installation
Running the old information system and the new one at
the same time until management decides the old
system can be turned off
[email protected]
346
Installation
Single location installation
Trying out an information system at one site and
using the experience to decide if and how the new
system should be deployed throughout the
organization
Phased Installation
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
[email protected]
347
[email protected]
348
Planning Installation
Considerations
Data conversion
Error correction
Loading from current system
Planned system shutdown
Business cycle of organization
[email protected]
349
Documenting the System
System documentation
Detailed information about a system’s design
specifications, its internal workings and its
functionality
Internal documentation
System documentation that is part of the program
source code or is generated at compile time
External documentation
System documentation that includes the outcome
of structured diagramming techniques such as data
flow and entity relationship diagrams
[email protected]
350
Documenting the System
User Documentation
Written or other visual information about an
application system, how it works, and how to
use it
Preparing user documentation
Traditional source has been information
systems department
Application-oriented documentation is now
often supplied by vendors and users
themselves
[email protected]
351
Training Information System Users
Potential training topics
Use of the system
General computer concepts
Information system concepts
Organizational concepts
System management
System installation
[email protected]
352
Training Information System Users
Training methods
Resident expert
Computer-aided instruction
Formal courses
Software help components
Tutorials
Interactive training manuals
External sources, such as vendors
[email protected]
353
[email protected]
354
Training Information System Users
Electronic performance support system
(EPSS)
Component of a software package or
application in which training and educational
information is embedded
[email protected]
355
Supporting Information System Users
Support is extremely important to users
J.D. Power and Associates survey found user
support to be number one criterion
contributing to user satisfaction with personal
computing
Most organizations provide support by
two means
Information center
Help desk
[email protected]
356
Supporting Information System Users:
Information Center
An organizational unit whose mission is to support users in
exploiting information technology
Staff might perform the following tasks
Install new hardware or software and set up user accounts
Consult with users writing programs in fourth-generation
languages
Extract data from organizational databases onto personal
computers
Answer basic on-demand questions
Provide a demonstration site for viewing hardware and software
Work with users to submit system change requests
[email protected]
357
Supporting Information System Users:
Help Desk
A single point of contact for all user inquiries
and problems about a particular
information system or for all users in a
particular department
[email protected]
358
Why Implementation Sometimes Fails
Two conditions necessary for a successful
implementation
Management support of the system under
development
Involvement of users in the development
process
[email protected]
359
Why Implementation Sometimes Fails
Insights about implementation process
Risk
Commitment to the project
Commitment to change
Extent of project definition and planning
Realistic user expectations
Implementation success factors
Extent to which system is used
User’s satisfaction with system
[email protected]
360
Project Close Down
Evaluate team
Reassign members to other projects
Notify all affected parties that the
development project is ending and
that you are switching to operation
and maintenance mode
Conduct post-project reviews
Close out customer contract
Formal signoff
[email protected]
361
Conducting System Maintenance
Corrective maintenance
Changes made to a system to repair flaws in its design,
coding, or implementation
Adaptive maintenance
Changes made to a system to evolve its functionality to
changing business needs or technologies
Perfective maintenance
Changes made to a system to add new features or to
improve performance
Preventive maintenance
Changes made to a system to avoid possible future
problems
[email protected]
362
Conducting System Maintenance:
The Cost of Maintenance
Many organizations allocate eighty percent
of information systems budget to
maintenance
Factors that influence system maintainability
Latent defects
Number of customers for a given system
Quality of system documentation
Maintenance personnel
Tools
Well-structured programs
[email protected]
363
Conducting System Maintenance:
Measures of Effectiveness
Number of failures
Time between each failure
Type of failure
Mean time between failures (MTBF)
A measurement of error occurrences that
can be tracked over time to indicate the
quality of a system
[email protected]
364
Controlling Maintenance Requests
Determine type of request
Error
Adaptation
Enhancement
Figure 10-9 shows a flowchart for a
request procedure
[email protected]
365
[email protected]
366
Configuration Management
The process of assuring that only authorized
changes are made to the system
Baseline modules
Software modules that have been tested,
documented, and approved to be included in the
most recently created version of a system
System librarian
A person responsible for controlling the checking out
and checking in of baseline modules when a system is
being developed or maintained
Build routines
Guidelines that list the instructions to construct an
executable system from the baseline source code
[email protected]
367
Summary
Process of coding, testing and
converting an organizational
information system
Four installation strategies
Direct
Parallel
Single location
Phased installation
[email protected]
368
Summary
Documentation
System
User
User training
Providing support for end users
Systems implementation failures
[email protected]
369
Summary
Maintenance
Corrective
Adaptive
Perfective
Preventive
Cost of maintenance
Measuring effectiveness of
maintenance
[email protected]
370
Summary
Controlling maintenance requests
Configuration management
Internet development
[email protected]
371