Information Systems

Analysis and Design

Myriam Lewkowicz

Outline

1. Information Systems: the big picture

2. Information Systems for competitive advantage
3. Organizational Information Systems
4. Entreprise-Wide Information Systems
5. Information Systems Development & Acquisition
6. Managing the Information Systems Project
7. Systems Planning
8. Determining System Requirements
9. Structuring System Requirements: Process Modeling
[Link] System Requirements: Conceptual Data Modeling
[Link] Oriented Analysis and Design
[Link] the Human Interface
[Link] Implementation and Operation

[Link]@[Link]

Chapter 1
Information Systems:
The Big Picture

Chapter 1 Objectives

Understand the term information systems (IS)

Understand IS components:
Technology, people, organizations

Understand
Understand
Understand
failure
Understand

IS career opportunities
types of information systems
IS and organizational success or
the future of IS management

[Link]@[Link]

Information Systems Defined

Combinations of hardware, software,

and telecommunications networks that
people build and use to collect, create,
and distribute useful data in
organizations

[Link]@[Link]

Key Elements of Information

Systems

[Link]@[Link]

Data

Data: raw material, unformatted

information
Information: processed data
(meaningful)
Knowledge: understanding relationships
between pieces of information
Wisdom: knowledge accumulated and
applied

[Link]@[Link]

Knowledge as a Business Resource

Knowledge Worker
A well-educated professional who creates,
modifies, or synthesizes knowledge in ones
profession

Knowledge Society
Also called digital society, new economy
Working with brains instead of hands
The importance of education
Digital divide

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

10

Integrating Skills and Knowledge

Technology
hardware, software, networking

Business
business, management, social,
communications

Systems
Integration, development methods, critical
thinking, problem solving

[Link]@[Link]

11

Hot Skills in IS Workers

Office / E-mail
Languages
Applications
RDBS Administration
Development Tools
Internetworking
Operating Systems
LAN Administration
Networking

[Link]@[Link]

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

[Link]@[Link]

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.)

[Link]@[Link]

14

The Spread of Technology in

Organizations

Benefits of centralized IS function

Coordinated planning
Consistent management
Systems compatibility and connectivity

[Link]@[Link]

15

Questions

1. Define and understand the term

information systems (IS)
2. Explain the technology, people, and
organizational components of an
information system.

[Link]@[Link]

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
[Link]@[Link]

18

Why Use Information Systems?

Automating: doing things faster

Organizational learning: doing things
better
Supporting Strategy: doing things
smarter

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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?

[Link]@[Link]

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

[Link]@[Link]

25

Decision-Making Levels of an
Organization

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

34

1.35
[Link]@[Link]

35

Information Systems that Span Organizational

Boundaries

[Link]@[Link]

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.

[Link]@[Link]

37

Information Systems that

Span Organizational Boundaries

Expert Systems (ESs)

Mimics human expertise by manipulating
knowledge
Rules (If-then)
Inferencing

[Link]@[Link]

38

Information Systems that

Span Organizational Boundaries

Office Automation Systems (OASs)

Examples:
Communicating and scheduling
Document preparation
Analyzing data
Consolidating information

[Link]@[Link]

39

Information Systems that

Span Organizational Boundaries

Collaboration Technologies
Virtual teams
Videoconferencing
Groupware
Electronic Meeting Systems (EMSs)

[Link]@[Link]

40

Information Systems that

Span Organizational Boundaries

Functional Area Information Systems

Geared toward specific areas in the
company:
Human Resources
Benefits
Marketing

[Link]@[Link]

41

[Link]@[Link]

42

Information Systems that

Span Organizational Boundaries

Global Information Systems

International IS
Transnational IS
Multinational IS
Global IS

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

46

Before an entreprise system

[Link]@[Link]

47

With an entreprise sytem

[Link]@[Link]

48

Types of Enterprise Systems

Packaged applications
Custom applications
Stand-alone applications

[Link]@[Link]

49

Types of Enterprise Systems

Enterprise Resource Planning

Integrated applications
ERP systems
Baan
Oracle
PeopleSoft
SAP

[Link]@[Link]

50

Types of Enterprise Systems

ERP Implementation
Modules
Customizations
Best practices
Business process reengineering (BPR)

[Link]@[Link]

51

Types of Enterprise Systems

Customer Relationship Management

(CRM)
Sales Force Automation (SFA)
New opportunities for competitive
advantage
Examples:
MGM
American Airlines
Marriott International

[Link]@[Link]

52

CRM system

[Link]@[Link]

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

[Link]@[Link]

54

Supply chain management

[Link]@[Link]

55

The Formula for Enterprise System

Success

Secure executive sponsorship

Get help from outside experts
Thoroughly train users
Take a multidisciplinary approach to
implementation

[Link]@[Link]

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.

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

60

The Need for Structured Systems

Development

Evolution of IS development
From art to a discipline
Standardized development methods
Software engineering

[Link]@[Link]

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

[Link]@[Link]

62

The Need for Structured Systems

Development

Information Systems Development in

Action
Breaking large complex problems into
manageable pieces
Decomposing large, complex problems

[Link]@[Link]

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

[Link]@[Link]

64

The Need for Structured Systems

Development

The Role of Users in the Systems

Development Process
Knowledgeable of needs
Effective partnership

[Link]@[Link]

65

Information Systems Analysis and

Design

Systems Analyst performs analysis and

design based upon:
Understanding of organizations objectives,
structure and processes
Knowledge of how to exploit information
technology for advantage

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

68

[Link]@[Link]

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

[Link]@[Link]

70

[Link]@[Link]

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

[Link]@[Link]

72

Characteristics of a System

Components
Interrelated Components
Boundary
Purpose
Environment
Interfaces
Constraints
Input
Output

[Link]@[Link]

73

[Link]@[Link]

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

[Link]@[Link]

75

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

80

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

83

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

88

Systems Development Life Cycle

System Development Methodology

Standard process followed in an
organization
Consists of:
Analysis
Design
Implementation
Maintenance

[Link]@[Link]

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

[Link]@[Link]

90

Systems Development Life Cycle

Phases are not necessarily sequential

Each phase has a specific outcome and
deliverable
Individual companies use customized
life cycle

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

93

[Link]@[Link]

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

[Link]@[Link]

95

[Link]@[Link]

96

Summary

Information systems analysis and

design
Process of developing and maintaining an
information system

Modern approach to systems analysis

Process-Oriented
Data-Oriented

[Link]@[Link]

97

Summary

Systems Development Life Cycle (SDLC)

Systems
Systems
Systems
Systems

Planning and Selection

Analysis
Design
Implementation

Alternatives to Systems Development Life

Cycle
Prototyping
Rapid Application Development (RAD)
Joint Application Design (JAD)

[Link]@[Link]

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?

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

102

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

105

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

110

[Link]@[Link]

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 projects tasks and resources

[Link]@[Link]

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

[Link]@[Link]

113

Closing Down the Project

1.

Termination
Types of termination
Natural
Requirements have been met

Unnatural
Project stopped

Documentation
Personnel Appraisal

2.

Conduct post-project reviews

Determine strengths and weaknesses of:
Project deliverables
Project management process
Development process

3.

Close customer contract

[Link]@[Link]

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

[Link]@[Link]

115

[Link]@[Link]

116

[Link]@[Link]

117

Summary

Skills of an effective project manager

Activities of project manager
Initiation
Planning
Execution
Closedown

Gantt Charts and Network Diagrams

Commercial PM Software

[Link]@[Link]

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.

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

122

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

127

[Link]@[Link]

128

Reviewing the Baseline Project Plan

Objectives
Assure conformity to organizational
standards
All parties agree to continue with project

[Link]@[Link]

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

[Link]@[Link]

130

[Link]@[Link]

131

[Link]@[Link]

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

[Link]@[Link]

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?

[Link]@[Link]

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
[Link]@[Link]

136

Learning Objectives

Learn about Joint Application Design

(JAD) and Prototyping
Discuss appropriate methods to elicit
system requests
Examine requirements determination
for Internet applications

[Link]@[Link]

137

Activities in Requirement Gathering

1.0
1.0
Identify
Identifythe
theright
right
Stakeholders
Stakeholders&&
Artefacts
Artefacts

0.0
0.0
Outline
Outlineinformation
information
to
tobe
besought
sought

2.0
2.0
Use
Usemost
mostappropriate
appropriate
investigation
investigationtechniques
techniques

4.0
4.0
Document
Documentthe
the
requirements
requirements

3.0
3.0
Determine
Determineduration
duration

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

141

Deliverables and Outcomes

[Link]@[Link]

142

Traditional Methods for Determining

Requirements

[Link]@[Link]

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

[Link]@[Link]

144

[Link]@[Link]

145

[Link]@[Link]

146

[Link]@[Link]

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

[Link]@[Link]

148

Traditional Methods for Determining

Requirements

Questionnaires Vs. Interviews

Interviews cost more but yield more information
Questionnaires are more cost-effective

[Link]@[Link]

149

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

152

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

155

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

159

Summary

Other means of gathering requirements

Observing workers
Analyzing business documents

Joint Application Design (JAD)

Prototyping

[Link]@[Link]

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.

[Link]@[Link]

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?

[Link]@[Link]

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

[Link]@[Link]

164

Learning Objectives

Discuss the use of data flow diagrams

as analysis tools
Discuss process modeling for Internet
Applications

[Link]@[Link]

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

[Link]@[Link]

166

Process Modeling

Modeling a systems 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

[Link]@[Link]

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

[Link]@[Link]

168

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

173

[Link]@[Link]

174

[Link]@[Link]

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
systems major processes, data flows and data stores
at a higher level

[Link]@[Link]

176

Developing DFDs: An Example

Hoosier Burgers automated food

ordering system
Context Diagram contains no data
stores

[Link]@[Link]

177

[Link]@[Link]

178

Developing DFDs: An Example

Next step is to expand the context

diagram to show the breakdown of
processes

[Link]@[Link]

179

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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 level0 diagram

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

188

Balancing DFDs

We can split a data flow into separate

data flows on a lower-level diagram

[Link]@[Link]

189

Balancing DFDs:
Four Additional Advanced Rules

[Link]@[Link]

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

[Link]@[Link]

191

Guidelines for Drawing DFDs

3.

Timing
Time is not represented well on DFDs
Best to draw DFDs as if the system has never
started and will never stop

4.

Iterative Development
Analyst should expect to redraw diagram several
times before reaching the closest approximation to
the system being modeled

5.

Primitive DFDs
Lowest logical level of decomposition
Decision has to be made when to stop
decomposition

[Link]@[Link]

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

[Link]@[Link]

193

Using DFDs in Business Process

Reengineering

Example: IBM Credit

Credit approval
process required six
days before Business
Process
Reengineering (see
Fig 5-12)

[Link]@[Link]

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

[Link]@[Link]

195

Summary

Data flow diagrams (DFD)

Symbols
Rules for creating
Decomposition
Balancing

DFDs for Analysis

DFDs for Business Process
Reengineering (BPR)

[Link]@[Link]

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?

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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 projects application
E-R diagram for system being replaced
An E-R diagram for the whole database from which
the new applications data are extracted
An E-R diagram for the whole database from which
data for the application system being replaced are
drawn

[Link]@[Link]

203

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

208

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

213

Conceptual Data Modeling and the ER Diagram

Goal
Capture as much of the meaning of the data
as possible

Result
A better design that is easier to maintain

[Link]@[Link]

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

[Link]@[Link]

215

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

218

[Link]@[Link]

219

[Link]@[Link]

220

ER diagram for Pine Valley furniture

[Link]@[Link]

222

Summary

Process of conceptual data modeling

Deliverables
Gathering information

Entity-Relationship Modeling
Entities
Attributes
Candidate keys and identifiers
Multivalued attributes

Degree of relationship
[Link]@[Link]

223

Summary

Cardinality
Associative entities
Conceptual data modeling and Internet
development

[Link]@[Link]

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-to-many?
6. Give an example of a ternary relationship (different from any
example in this chapter.)

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

231

An architecture-based vision

Functional
Functional needs
needs
Major
Major classes
classes

coding
coding

Logical
Logical View
View

Components
Components View
View

Use
Use Case
Case View
View

Process
Process View
View

Deployment
Deployment View
View
Servers
Servers and
and
network
network organization
organization

System
System performances
performances

[Link]@[Link]

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
Systems 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
[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

236

A use case and his actor

[Link]@[Link]

237

A use case diagram

[Link]@[Link]

238

[Link]@[Link]

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.

[Link]@[Link]

240

[Link]@[Link]

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.
[Link]@[Link]

242

Use case example

Online HR system

[Link]@[Link]

244

[Link]@[Link]

245

Update Benefits description

[Link]@[Link]

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

[Link]@[Link]

247

[Link]@[Link]

248

[Link]@[Link]

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.

[Link]@[Link]

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.

[Link]@[Link]

251

Collaboration diagram

[Link]@[Link]

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.

[Link]@[Link]

253

[Link]@[Link]

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

[Link]@[Link]

255

Class notations

[Link]@[Link]

256

Class stereotypes

[Link]@[Link]

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.

[Link]@[Link]

258

[Link]@[Link]

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

[Link]@[Link]

260

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

263

[Link]@[Link]

264

[Link]@[Link]

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

[Link]@[Link]

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.

[Link]@[Link]

267

[Link]@[Link]

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.

[Link]@[Link]

269

[Link]@[Link]

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.

[Link]@[Link]

271

[Link]@[Link]

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.

[Link]@[Link]

273

[Link]@[Link]

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

[Link]@[Link]

275

Objects notations

[Link]@[Link]

276

[Link]@[Link]

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

[Link]@[Link]

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.

[Link]@[Link]

279

[Link]@[Link]

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.

[Link]@[Link]

281

[Link]@[Link]

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

[Link]@[Link]

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.

[Link]@[Link]

284

[Link]@[Link]

285

Summary

Object-Oriented modeling approach

Benefits
Unified Modeling Language
Use cases
Class diagrams
State diagrams
Sequence diagrams

Use-case modeling

[Link]@[Link]

286

Summary

Object Modeling: Class Diagrams

Associations
Generalizations
Aggregation

Dynamic Modeling: State Diagrams

Dynamic Modeling: Sequence
Diagrams
Moving to Design

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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?

[Link]@[Link]

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

[Link]@[Link]

294

Deliverables and Outcomes

Design specifications are major

deliverable and contain three sections
1. Narrative
2. Screen Design
3. Testing and usability assessment

[Link]@[Link]

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 users immediate attention
Methods should be consistently selected
and used based upon level of importance of
emphasized information

[Link]@[Link]

296

[Link]@[Link]

297

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

302

[Link]@[Link]

303

[Link]@[Link]

304

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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
[Link]@[Link]

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 systems
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

[Link]@[Link]

310

[Link]@[Link]

311

[Link]@[Link]

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

[Link]@[Link]

313

Providing Help

Place yourself in users 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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

317

[Link]@[Link]

318

Designing Dialogues:
Building Prototypes and Assessing
Usability

Often optional activities

Task is simplified by using graphical design
environment

[Link]@[Link]

319

[Link]@[Link]

320

Web-based Application:
Designing Interfaces and Dialogues for Pine Valley
Furnitures Webstore

General Guidelines
Several factors have contributed to poor
design of Web interfaces
Webs 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

[Link]@[Link]

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

[Link]@[Link]

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
[Link]@[Link]

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
[Link]@[Link]

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?
[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

330

Deliverables

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

334

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

341

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

344

Acceptance Testing by Users

Beta Testing
User testing of a completed information
system using real data in the real user
environment

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

347

[Link]@[Link]

348

Planning Installation

Considerations
Data conversion
Error correction
Loading from current system

Planned system shutdown

Business cycle of organization

[Link]@[Link]

349

Documenting the System

System documentation
Detailed information about a systems
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

[Link]@[Link]

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
[Link]@[Link]

351

Training Information System Users

Potential training topics

Use of the system
General computer concepts
Information system concepts
Organizational concepts
System management
System installation

[Link]@[Link]

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

[Link]@[Link]

353

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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
Users satisfaction with system

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

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

[Link]@[Link]

364

Controlling Maintenance Requests

Determine type of request

Error
Adaptation
Enhancement

Figure 10-9 shows a flowchart for a

request procedure

[Link]@[Link]

365

[Link]@[Link]

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

[Link]@[Link]

367

Summary

Process of coding, testing and

converting an organizational
information system
Four installation strategies
Direct
Parallel
Single location
Phased installation

[Link]@[Link]

368

Summary

Documentation
System
User

User training
Providing support for end users
Systems implementation failures

[Link]@[Link]

369

Summary

Maintenance
Corrective
Adaptive
Perfective
Preventive

Cost of maintenance
Measuring effectiveness of
maintenance

[Link]@[Link]

370

Summary

Controlling maintenance requests

Configuration management
Internet development

[Link]@[Link]

371