TSE2251 SAD Revision Note

TSE2251
Systems Analysis & Design

Final Examination Revision Note
Table of Contents
Description Page
Lecture 01 The Systems Development Environment 1
Tutorial 01 15
Lecture 02 The Origins of Software 22
Lecture 03 Managing the Information Systems Project 29
Tutorial 03 46
Lecture 04 Identifying, Selecting, Initiating and Planning System 51
Development Projects
Tutorial 04 66
Lecture 05 Analysis: Determining System Requirements 71
Tutorial 05 81
Lecture 06a Structuring System Process Requirements 87
Lecture 06b Logic Requirements 98
Tutorial 06 103
Lecture 07 Structuring System Data Requirements 107
Tutorial 07 117
Lecture 08 Designing Databases 119
Tutorial 08 133
Lecture 09 Designing Forms and Reports 137
Tutorial 09 148
Lecture 10 Designing Interfaces and Dialogues 150
Tutorial 10 163
Lecture 11 System Implementation & Maintenance 166
TSE2251 Systems Analysis & Design Kirby510s Website Blog
Lecture 01: The Systems Development Environment

Learning Objectives
Define information systems analysis and design.
Describe the information Systems Development Life Cycle (SDLC).
Explain Rapid Application Development (RAD), prototyping, Computer Aided Software
Engineering (CASE), and Service-Oriented Architecture (SOA).
Describe agile methodologies and eXtreme programming.
Explain Object Oriented Analysis and Design and the Rational Unified Process (RUP).
1. Introduction
Information Systems Analysis and Design
Complex organizational process
Used to develop and maintain computer-based information systems
Used by a team of business and systems professionals
FIGURE 1-1 An organizational approach to systems analysis and design is driven by

methodologies, techniques, and tools
2. A Modern Approach to Systems Analysis and Design

1950s: focus on efficient automation of existing processes
1960s: advent of 3GL (third-generation programming language: C, C++, C#, Java,
Delphi), faster and more reliable computers
1970s: system development becomes more like an engineering discipline
1980s: major breakthrough with 4GL, CASE tools, object oriented methods
1990s: focus on system integration, GUI applications, client/server platforms, Internet
The new century: Web application development, wireless PDAs, component-based
applications
Application Software
Computer software designed to support organizational functions or processes
Systems Analyst
Organizational role most responsible for analysis and design of information systems

3. Types of Information Systems and Systems Development

Transaction Processing Systems (TPS)
Automate handling of data about business activities (transactions)
Process orientation
Examples: POS, ordering & inventory system
Management Information Systems (MIS)
Converts raw data from TPS into meaningful form
Data orientation
Examples: Monthly sales report, profit statistics
Decision Support Systems (DSS)
Designed to help decision makers
Provides interactive environment for decision making
Involves data warehouses, executive information systems (EIS)
Database, model base, user dialogue
Examples: Analysis on the customers demand, estimate inventory volume, set
marketing plan
4. Summary of Information Systems Types

Information Information Systems Systems Development Methods
Systems Characteristics
Type
Transaction High-volume, data capture focus; Process orientation; concern with
Processing goal is efficiency of data movement capturing, validating, and storing
System and processing and interfacing data and with moving data between
different TPSs each required step
Managemen Draws on diverse yet predictable Data orientation; concern with
t data resources to aggregate and understanding relationships among
Information summarize data; may involve data so data can be accessed and
System forecasting future data from summarized in a variety of ways;
historical trends and business builds a model of data that supports
knowledge a variety of uses
Decision Provides guidance in identifying Data and decision logic orientations;
Support problems, finding and evaluating design of user dialogue; group
System alternative solutions, and selecting communication may also be key, and
or comparing alternatives; access to unpredictable data may
potentially involves groups of be necessary; nature of systems
decision makers; often involves requires iterative development and
semi-structured problems and the almost constant updating
need to access data at different
levels of detail
2 The Systems Development Environment Lecture 01

5. Developing Information Systems

System Development Methodology is a standard process followed in an organization to
conduct all the steps necessary to analyze, design, implement, and maintain information
systems.
6. Systems Development Life Cycle (SDLC)

Traditional methodology used to develop, maintain, and replace information systems.
Phases in SDLC:
Planning
Analysis
Design
Implementation
Maintenance
7. Standard and Evolutionary Views of SDLC
FIGURE 1-2 The systems development FIGURE 1-3 Evolutionary model

life cycle
8. Systems Development Life Cycle (SDLC)

Planning an organizations total information system needs are identified, analyzed,
prioritized, and arranged

Analysis system requirements are studied and structured
Design a description of the recommended solution is converted into logical and then
physical system specifications
Logical design all functional features of the system chosen for development in
analysis are described independently of any computer platform
Physical design the logical specifications of the system from logical design are
transformed into the technology-specific details from which all programming and
system construction can be accomplished

Implementation the information system is coded, tested, installed and supported in the
organization
Maintenance an information system is systematically repaired and improved

TABLE 1-1 Products of SDLC Phases

Phases Products, Outputs, or Deliverables
Planning Priorities for systems and projects; an architecture for data,
networks, and selection hardware, and Information Systems
management are the result of associated systems
Detailed steps, or work plan, for project
Specification of system scope and planning and high-level system
requirements or features
Assignment of team members and other resources
System justification or business case
Analysis Description of current system and where problems or opportunities
are with a general recommendation on how to fix, enhance, or
replace current system
Explanation of alternative systems and justification for chosen
alternative
Design Functional, detailed specifications of all system elements (data,
processes, inputs, and outputs)
Technical, detailed specifications of all system elements
(programs, files, network, system software, etc.)
Acquisition plan for new technology
Implementation Code, documentation, training procedures, and support capabilities
Maintenance New versions or releases of software with associated updates to
documentation, training, and support
9. Traditional Waterfall SDLC

One phase begins when another completes, with little backtracking and looping.

FIGURE 1-9 A traditional waterfall SDLC
10. Problems with Waterfall Approach

System requirements locked in after being determined (can't change)
Limited user involvement (only in requirements phase)
Too much focus on milestone deadlines of SDLC phases to the detriment of sound
development practices
11. The Heart of the Systems Development Process
Current practice combines analysis, design, and implementation into a single iterative and
parallel process of activities.
12. Different Approaches to Improving Waterfall SDLC

Prototyping
CASE Tools
Joint Application Design (JAD)
Rapid Application Development (RAD)
Service-Oriented Architecture (SOA)
Agile Methodologies
eXtreme Programming
13. Prototyping
Iterative development process:
Requirements quickly converted to a working system.
System is continually revised.
Close collaboration between users and analysts.
FIGURE 1-11 The phototyping methodology
14. Computer-Aided Software Engineering (CASE) Tools

Diagramming tools enable graphical representation.
Computer displays and report generators help prototype how systems look and feel.
Analysis tools automatically check for consistency in diagrams, forms, and reports.
A central repository provides integrated storage of diagrams, reports, and project
management specifications.

Documentation generators standardize technical and user documentation.

Code generators enable automatic generation of programs and database code directly
from design documents, diagrams, forms, and reports.
FIGURE 1-12 A class diagram from IBMs Rational Rose (Source: IBM)
TABLE 1-2 Examples of CASE Usage within the SDLC

SDLC Phase Key Activities CASE Tool Usage
Project Display and structure Diagramming and matrix tools to create
identification high-level organizational and structure information
and selection information
Project Develop project scope Repository and documentation generators
initiation and and feasibility to develop project plans
planning
Analysis Determine and structure Diagramming to create process, logic, and
system requirements data models
Logical and Create new system Form and report generators to prototype
physical design designs designs; analysis and documentation
generators to define specifications
Implementatio Translate designs into an Code generators and analysis, form and
n information system report generators to develop system;
documentation generators to develop
system and user documentation
Maintenance Evolve information All tools are used (repeat life cycle)
system
15. Joint Application Design (JAD)

Structured process involving users, analysts, and managers.
Several-day intensive workgroup sessions.

Purpose: to specify or review system requirements.
FIGURE 6-6 Illustration of the typical room layout for a JAD
JAD Participants:
Session Leader: facilitates group process
Users: active, speaking participants
Managers: active, speaking participants
Sponsor: high-level champion, limited participation
Systems Analysts: should mostly listen
Scribe: record session activities
Information Systems Staff: should mostly listen
End Result
Documentation detailing existing system
Features of proposed system
Upper CASE tools are used
Enables analysts to enter system models directly into CASE during the JAD session
Screen designs and prototyping can be done during JAD and shown to users
16. Rapid Application Development (RAD)

Methodology to radically decrease design and implementation time
Involves: extensive user involvement, prototyping, JAD sessions, integrated CASE tools,
and code generators

FIGURE 1-11 RAD life cycle
17. Service-Oriented Architecture (SOA)

An approach to systems development based on building complete systems through
assembling software components, each of which model generic business functions
FIGURE 1-12 Illustration of a service, a credit check, used by applications and other
services
18. Agile Methodologies

Motivated by recognition of software development as fluid, unpredictable, and dynamic
Three key principles

Adaptive rather than predictive

Emphasize people rather than roles
Self-adaptive processes
TABLE 1-3 The Agile Manifesto

The Manifesto for Agile Software Development
Seventeen anarchists agree:
We are uncovering better ways of developing software by doing it and helping others do
it. Through this work we have come to value:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while we value the items on the right, we value the items on the left more. We
follow the following principles:
Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
Business people and developers work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Working software is the primary measure of progress.
Continuous attention to technical excellence and good design enhances agility.

Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely.
Simplicity the art of maximizing the amount of work not done is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
Kent Back, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,
Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave
Thomas (www.agileAlliance.org)
The Agile Methodologies group argues that software development methodologies adapted
from engineering generally do not fit with real-world software development.
19. When to use Agile Methodologies

If your project involves:
Unpredictable or dynamic requirements
Responsible and motivated developers
Customers who understand the process and will get involved
TABLE 1-4 Five Critical Factors That Distinguish Agile and Traditional Approaches to
Systems Development
Factor Agile Methods Traditional Methods
Size Well matched to small products and Methods evolved to handle large
teams. Reliance on tacit knowledge products and teams. Hard to tailor
limits scalability. down to small projects.
Criticality Untested on safety-critical products. Methods evolved to handle highly
Potential difficulties with simple critical products. Hard to tailor down
design and lack of documentation. to products that are not critical.
Dynamis Simple design and continuous Detailed plans and Big Design Up
m refactoring are excellent for highly Front excellent for highly stable
dynamic environments but a source environment but a source of expensive
of potentially expensive rework for rework for highly dynamic

highly stable environments. environments.

Personnel Requires continuous presence of a Needs a critical mass of scarce experts
critical mass of scarce experts. during project definition but can work
Risky to use no-agile people. with fewer later in the project, unless
the environment is highly dynamic.
Culture Thrives in a culture where people Thrives in a culture where people feel
feel comfortable and empowered by comfortable and empowered by
having many degrees of freedom having their roles defined by clear
(thriving on chaos). practices and procedures (thriving on
order)
20. eXtreme Programming

Short, incremental development cycles
Automated tests
Two-person programming teams
Coding and testing operate together
Advantages:
Communication between developers
High level of productivity
High-quality code
21. Object-Oriented Analysis and Design (OOAD)

Based on objects rather than data or processes
Object: a structure encapsulating attributes and behaviors of a real-world entity
Object class: a logical grouping of objects sharing the same attributes and behaviors
Inheritance: hierarchical arrangement of classes enable subclasses to inherit properties
of superclasses
22. Rational Unified Process (RUP)

An object-oriented systems development methodology
RUP establishes four phase of development: inception, elaboration, construction, and
transition.
Each phase is organized into a number of separate iterations.

FIGURE 1-13 Phases of OOAD-based development
23. Our Approach to Systems Development

The SDLC is an organizing and guiding principle in this book.
We may construct artificial boundaries or artificially separate activities and processes for
learning purposes.
Our intent is to help you understand all the pieces and how to assemble them.
Summary
In this chapter you learned how to:
Define information systems analysis and design.
Describe the different types of information systems.
Describe the SDLC.
Explain RAD, prototyping, CASE, and SOA.
Describe agile methodologies and eXtreme programming.
Explain Object Oriented Analysis and Design and the Rational Unified Process (RUP).

Tutorial 01
1. Match each of the key terms above with the definition that best fits it:
Analysis Application Application Data

independence software
Rapid Application Data-oriented Application Implementation
Development approach Service Provider
(RAD) (ASP)
Information Design Logical design Joint
System analysis
and design
Maintenance Reuse Outsourcing Object-oriented
Analysis and
Design (OOAD)
Process-oriented Processing logic Prototyping Stakeholder
approach
System System System analyst Physical design
Development Life development
Cycle (SDLC) methodology
Database Information Joint Application Rational Unified
Design (JAD) Process (RUP)
Enterprise Managed Service Request for
Resource Provider (MSP) Proposal (RFP)
Planning (ERP)
System
a. Systems development methodologies and techniques based on objects rather than data or
processes.
Object-oriented Analysis and Design (OOAD)
b. The third phase of the SDLC in which the description of the recommended solution is
converted into logical and then physical system specifications.
Design
c. The complex organization process whereby computer-based information systems are

developed and maintained.
Information System analysis and design
d. Computer software designed to support organizational functions and processes.
Application software
16 Tutorial 01
e. The organizational role most responsible for the analysis and design of information
systems.
System analyst
f. The use of previously written software resources, especially objects and components, in
new application.
Reuse
g. A structured process in which users, managers and analysts work together for several
days in a series of intensive meetings to specify or review system requirements.
h. An iterative process of systems development in which requirements are converted to a

working system that is continually revised through close work between an analyst and
users.
Prototyping
i. The part of the design phase of the SDLC in which all functional features of the system
chosen for development in analysis are described independent of any computer platform.
Logical design
j. The part of the design phase of the SDLC in which the logical specifications of the
system from logical design are transformed into technology-specific details from which
all programming and system constructions can be accomplished.
Physical design
k. The practice of turning over responsibility of some to all of an organizations information

systems applications and operations to an outside firm.
Outsourcing
l. The second phase of the SDLC in which the current system is studied and alternative
replacement systems are proposed.
Analysis
m. The fourth phase of the SDLC in which the information system is coded, tested, installed
and supported in the organization.
Tutorial 01 17
Implementation
n. The final phase of the SDLC in which an information system is systematically repaired
and improved; or changes made to s system to fix or enhance its functionality.
Maintenance
o. A standard process followed in an organization to conduct all the steps necessary to

analyze, design, implement, and maintain information systems.
System development methodology
p. Organizations that host and run computer applications for other companies, typically on a
per-use or license basic.
Application Service Provider (ASP)
q. The traditional methodology used to develop, maintain, and replace information systems.
System Development Life Cycle (SDLC)
r. Systems development methodology created to radically decrease the time needed to

design and implement information systems. This methodology relies on extensive user
involvement, Joint Application Design sessions, prototyping, integrated CASE tools and
code generators.
Rapid Application Development (RAD)
s. A person who has an interest in an existing or new information system. Someone who is
involved in the development of a system, in the use of a system, or someone who has
authority over the parts of the organization affected by the system.
Stakeholder
t. An object-oriented systems development methodology. This methodology establishes

four phases of development, each of which is organized into a number of separate
iterations, inception, elaboration, construction and transition.
Rational Unified Process (RUP)
u. An organization that remotely provides customized computer applications and network-

based services for other companies for a monthly or per-use fee.
18 Tutorial 01
Managed Service Provider (MSP)
v. A document provided to vendors to ask them to propose hardware and system software
that will meet the requirements of your new system.
Request for Proposal (RFP)
w. A system that integrates individual traditional business functions into a series of modules
so that a single transaction occurs seamlessly within a single information system rather
than several separate systems.
Enterprise Resource Planning (ERP) System
2. In the section on choosing off-the-shelf software, eight criteria are proposed for evaluating
alternative packages. Suppose the choice was between alternative custom software
developers rather than pre-written packages. What criteria would be appropriate to select and
compare among competing bidders for custom development of an application? Define each
of these criteria.
3. 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?
Tutorial 01 19
4. Fill in the blank in the following diagrams:
Planning
Maintenance Analysis
Implementati Design
on
20 Tutorial 01
Design
Implementati
on
Analysis
Maintenance
Planning
Develop
Prototype
Convert to
Operational
System
Implement and Revise and

Use Prototype Enhance
Prototype
5. Based on the diagram below, what is the expected product for each phase in the SDLC?
Tutorial 01 21
Feasibility Study
System Requirements
System Specifications
Working System
Enhancement
Case Study (Optional)

Students are encouraged to discuss the case study below on their own.
Situation: You are the IT manager at Low-Voltage Components, a medium-sized firm that makes
and sells specialized electrical cables to companies that manufacture electronic test
equipment. Low-Voltages largest customer, TX Industries, recently installed a
computerized purchasing system and wants Low-Voltage to connect to the new
system to receive purchase orders and production schedule forecasts. Low-Voltage
currently has the following information systems: finance, accounts receivable, and
accounts payable.
1. Should Low-Voltage develop an order entry system to connect with TX Industries

purchasing system? Why or why not?
2. What factors will affect the complexity of Low-Voltages new order entry system?
Modification
Cost
Time Constraint
System Boundaries (Security)
22 Tutorial 01
3. What term describes the proposed computer-to-computer relationship between Low-Voltage

and TX Industries?
Electronic Data Interchange (EDI)
4. Is Low-Voltages proposed new system an operational system? Why or why not?
Yes, because it is dealing to the day-to-day operational data.
Tutorial 01 23
Lecture 02: The Origins of Software

Learning Objectives
Explain outsourcing.
Describe six different sources of software.
Discuss how to evaluate off-the-shelf software.
Explain reuse and its role in software development.
1. Introduction
There are various sources of software for organizations.
There are criteria to evaluate software from different sources.
2. Systems Acquisition: Outsourcing

Outsourcing: Turning over responsibility of some or all of an organization's information
systems applications and operations to an outside firm
Outsourcing Examples
A company that runs payroll applications for clients
A company that runs your applications at your site
Reasons to outsource
Cost-effective
Take advantage of economies of scale
Free up internal resources
Reduce time to market
Increase process efficiencies
System development is a non-core activity for the organization
3. Sources of Software
Information technology services firm
Packaged software producers
Enterprise-wide solutions
Application service providers (ASPs)
Open source software
In-house developers
24 The Origins of Software Lecture 02

FIGURE 2-1 Sources of Application Software
4. Information Technology (IT) Services Firms

Help companies develop custom information systems for internal use.
Develop, host, and run applications for customers.
Provide other services.
5. Packaged Software Producers

Serve many market segments.
Provide software ranging from broad-based packages (i.e. general ledger) to niche
packages (i.e. day care management).
Software runs on all size computers, from microcomputers to large mainframes.
Prepackaged software is off-the-shelf, turnkey software (i.e. not customizable).
Off-the-shelf software at best meets 70 percent of organizations needs.

TABLE 2-1 The 2007 Top Global Software Companies

Ran Company 2007 Software / Software Business Sector
k Services Revenue
($US million)
1 IBM $74,126 Middleware / Application Server /
Web Server
2 Microsoft $44,846 Operating Systems
3 EDS $22,134 Outsourcing Services
4 Accenture $19,696 Systems Integration Services / IT
Consulting
5 HP $18,971 Systems Integration Services / IT
Consulting
6 Oracle $17,996 Database
7 SAP $14,980 Enterprise Application / Data
Integration
8 Computer Sciences $14,857 Systems Integration Services / IT
Corporation (CSC) Consulting
9 Capgemini $12,818 Systems Integration Services / IT
Consulting
10 Lockhead Martin $10,213 Vertical Industry Applications
Corportion
Note: All figures in U.S. dollars.
6. Prepackaged Software
FIGURE 2-2 Microsoft Project

7. Enterprise Solutions Software

Enterprise Resource Planning (ERP) systems integrate individual traditional business
functions into modules enabling a single seamless transaction to cut across functional
boundaries.
SAP AG is the leading vendor of ERP systems.
FIGURE 2-3 SAPs Business ByDesign, a product designed for medium sized
companies.
8. Cloud Computing
The provision of computing resources, including applications, over the Internet, so customers
do not have to invest in the computing infrastructure needed to run and maintain the
resources
9. Open Source Software

Freely available including source code
Developed by a community of interested people
Performs the same functions as commercial software
Examples: Linux, mySQL, Firefox
10. In-House Development

If sufficient system development expertise with the chosen platform exists in-house, then
some or all of the system can be developed by the organizations own staff.
Hybrid solutions involving some purchased and some in-house components are common.

11. Sources of Software Components
TABLE 2-2 Comparison of Six Different Sources of Software Components

Producers When to Go to This Type of Internal Staffing Requirements
Organization for Software
IT service firms When task requires custom Internal staff may be needed,
support and system cant be built depending on application
internally or system needs to be
sourced
Packages When supported task is generic Some Information Systems and
software user staff to define requirements
producers and evaluate packages
Enterprise-wide For complete systems that cross Some internal staff necessary but
solutions functional boundaries mostly need consultants
vendors
Cloud For instant access to an Few; frees up staff for other IT
computing application; when supported task work
is generic
Open source When supported task is generic Some Information Systems and
software but cost is an issue user staff to define requirements
and evaluate packages
In-house When resources and staff are Internal staff necessary through
developers available and system must be staff size may vary
built from scratch
12. Selecting Off-the-Shelf Software

(i) Cost: comparing the cost of developing the same system in-house with the cost of
purchasing or licensing the software package
(ii) Functionality: the tasks that the software can perform and the mandatory, essential,
and desired system features
(iii) Vendor support: whether or how much support the vendor can provide and at
what cost
(iv)Viability of vendor: can the software adapt to changes in systems software and
hardware
(v) Flexibility: how easy it is to customize the software
(vi)Documentation: is the users manual and technical documentation understandable and
up-to-date
(vii) Response time: how long it takes the software package to respond to the users
requests in an interactive session
(viii) Ease of installation: a measure of the difficulty of loading the software and
making it operational

13. Validating Purchased Software Information

Use a variety of information sources:
Collect information from vendor
Software documentation
Technical marketing literature
14. Request For Proposal (RFP)

Request for proposal (RFP) is a document provided to vendors to ask them to propose
hardware and system software that will meet the requirements of a new system.
Sometimes called a Request For Quote (RFQ)
Use a variety of information sources
Based on vendor bids, analyst selects best candidates.
15. Information Sources For RFP

Vendors proposal
Running software through a series of tests
Feedback from other users of the vendors product
Independent software testing services
Articles in trade publications
16. Reuse
The use of previously written software resources, especially objects and components, in
new applications
Commonly applied to two different development technologies:
Object-oriented development
Component-based development
Object-oriented development
Object class encapsulates data and behavior of common organizational entities (e.g.
employees)
Component-based development
Components can be as small as objects or as large as pieces of software that handle
single business functions.
Object-oriented development reuse is the use of object classes in more than one
application (e.g. Employee).
Component-based development reuse is the assembly of an application from many
different components at many different levels of complexity and size (e.g. Currency
conversion).

17. Costs and Benefits of Reuse
FIGURE 2-5 Investments necessary to achieve reusable components
18. Approaches to Reuse

Ad-hoc: individuals are free to find or develop reusable assets on their own.
Facilitated: developers are encouraged to practice reuse.
Managed: the development, sharing, and adoption of reusable assets is mandated.
Designed: assets mandated for reuse as they are being designed for specific applications.
TABLE 2-3 Approaches to Reuse

Approach Reuse level Cost Policies & Procedures
Ad-hoc None to low Low None
Facilitate Low Low Developers are encouraged to reuse but are not
d required to do so.
Managed Moderate Moderate Development, sharing and adoption of reusable
assets are mandated; Organizational policies are
established for documentation, packaging, and
certification.
Designed High High Reuse is mandated; Policies are put in place so
that reuse effectiveness can be measured; Code
must be designed for reuse during initial
development, regardless of the application it is
originally designed for; There may be a corporate
office for reuse.
Summary
Explain outsourcing.

Describe six different sources of software.

Discuss how to evaluate off-the-shelf software.
Explain reuse and its role in software development.

Lecture 03: Managing the Information Systems

Project
Learning Objectives
Explain the process of managing an information systems project.
Describe the skills required to be an effective project manager.
List and describe the skills and activities of a project manager during project initiation,
project planning, project execution, and project closedown.
Explain what is meant by critical path scheduling and describe the process of creating Gantt
charts and network diagrams.
Explain how commercial project management software packages can be used to assist in
representing and managing project schedules.
1. Importance of Project Management

Project management may be the most important aspect of systems development.
Effective PM helps to ensure
The meeting of customer expectations.
The satisfying of budget and time constraints.
PM skills are difficult and important to learn.
2. Pine Valley Furniture (PVF)

Manufactures high-quality wood furniture
Distributes to retail stores within the U.S.
Started in the early 1980s and expanded by 1984 doubling sales volume
By 1990, Pine Valley Furniture had become a complex company, employing over 50
persons
Company organized into functional areas:
Manufacturing
Sales
Orders
Accounting
Purchasing
Established manual information systems
PVF installed a network server to automate invoicing, accounts receivable, and inventory
control applications.
In the late 1990s, PVF upgraded the network server and implemented a centralized
database management system.
PVF decided to develop its application software in-house.
PVF hired staff and bought computer software and hardware.
The new information system will take into account market conditions, the Internet, and
WWW.
The Project Manager plays the key role in developing the new information system.
32 Managing the Information Systems Project Lecture 03

3. Pine Valley Application Project
FIGURE 3-1 Three computer applications at Pine Valley Furniture: Order filling,
invoicing, and payroll
4. Deciding on Systems Projects

System Service Request (SSR)
A standard form for requesting or proposing systems development work within an
organization
Feasibility study
A study that determines whether a requested system makes economic and operational
sense for an organization
FIGURE 3-2 System Service Request for purchasing a fulfillment system with name
and contact information of the person requesting the system, a statement

of the problem, and the name and contact information of the liaison and
sponsor.
5. Managing the Information Systems Project

Project
A planned undertaking of related activities to reach an objective that has a beginning
and an end
Project management
A controlled process of initiating, planning, executing, and closing down a project
Project manager
Systems analyst with management and leadership skills responsible for leading
project initiation, planning, execution, and closedown
Deliverable
The end product of an SDLC phase
6. Project Management Activities
FIGURE 3-4 A project manager juggles numerous activities

7. Phases of Project Management Process

Phase 1: Initiation
Phase 2: Planning
Phase 3: Execution
Phase 4: Closedown
FIGURE 3-5 Project Initiation

8. PM Phase 1: Project Initiation

Assess size, scope and complexity, and establish procedures.
Establish 6 activities:
(i) Initiation team
(ii) Relationship with customer
(iii) Project initiation plan: activities required to organize team
(iv)Management procedures: team communication & reporting
(v) Project management environment: tools to manage project
+ Project workbook: online or hard-copy repository for all project correspondence,
inputs, outputs, deliverables, procedures, and standards that are used
FIGURE 3-6 The project workbook for the Purchase Fulfillment System project
contains nine key documents in both hard-copy and electronic form.
(vi)A project charter

Project charter a short (1 page), high-level document prepared for customer.
It formally announces the establishment of the project (communication tools)
It briefly describes its objectives, key assumptions, and stakeholders.
Ensures both parties gain a common understanding of the project.

FIGURE 3-7 The project charter prepared for customer that describes the deliverables
and outlines of the project.
9. PM Phase 2: Project Planning

Define clear, discrete activities and the work needed to complete each activity
10 Tasks:
(i) Define project scope, alternatives, feasibility
(ii) Divide project into tasks
(iii) Estimate resource requirements
(iv)Develop preliminary schedule
(v) Develop communication plan
(vi)Determine standards and procedures
(vii) Identify and assess risk
(viii) Create preliminary budget
(ix)Develop a statement of work
(x) Set baseline project plan

10. Planning Detail
FIGURE 3-8 Level of project planning detail should be high in the short term, with less
detail as time goes on.
11. Planning the Project (Task 1)

Describe project scope, alternatives, and feasibility:
What problems or opportunities does the project address?
What are the quantifiable results to be achieved?
What needs to be done?
How will success be measured?
How will we know when we are finished?

The characteristics of a task:
Can be done by one person or a well-defined group
Has a single and identifiable deliverable
Has a known method or technique
Has well-accepted predecessor and successor steps
Is measurable so that percent completed can be determined

14. Some Components of Project Planning

Statement of Work (SOW)
Contract between the IS staff and the customer regarding deliverables and time
estimates for a system development project
The Baseline Project Plan (BPP)
Contains estimates of scope, benefits, schedules, costs, risks, and resource
requirements
Preliminary Budget
Cost-benefit analysis outlining planned expenses and revenues

Develop a communication plan:
Who are the stakeholders for this project?
What information does each stakeholder need?
When, and at what interval, does this information need to be produced?
What sources will be used to gather and generate this information?
Who will collect, store, and verify the accuracy of this information?
Who will organize and package this information into a document?
Who will be the contact person for each stakeholder should any questions arise?
What format will be used to package this information?
What communication medium will be most effective for delivering this information to
the stakeholder?
16. Some Components of Project Planning

Work Breakdown Structure (WBS)
Division of project into manageable and logically ordered tasks and subtasks
Scheduling Diagrams
Gantt chart: horizontal bars represent task durations
Network diagram: boxes and links represent task dependencies

17. Scheduling Diagrams Gantt Chart
FIGURE 3-10 Gantt chart showing project tasks, duration times for those tasks, and
predecessors
Special-purpose project management software is available for this.
18. Scheduling Diagrams Network Diagram
FIGURE 3-13 A network diagram illustrating tasks with rectangles (or ovals) and the
relationships and sequences of those activities with arrows
Special-purpose project management software is available for this.

19. Preliminary Budget
FIGURE 3-15 A financial cost and benefit analysis for a systems development project
Spreadsheet software is good for this.
20. PM Phase 3: Project Execution

Plans created in prior phases are put into action.
Actions
Execute baseline project plan (BPP)
Monitor progress against baseline plan
Manage changes in baseline plan
Maintain project workbook
Communicate project status
21. Executing the Project

Monitor project progress against the Baseline Project Plan (BPP)
Manage changes to the BPP:
A slipped completion date for an activity
A bungled activity that must be redone
The identification of a new activity that becomes evident later in the project
An unforeseen change in personnel due to sickness, resignation, or termination

22. Monitoring Progress with a Gantt Chart
FIGURE 3-17 Gantt chart with tasks 3 and 7 completed
Red bars indicate critical path; lines through bars indicate percent complete.
23. Communication Methods

High Formality
Project workbook
Newsletters
Status reports
Specification documents
Meeting minutes
Medium Formality
Meetings
Seminars and workshops
Memos
Low Formality
Bulletin boards
Brown bag lunches
Hallway discussions
24. PM Phase 4: Project Closedown

Bring the project to an end
Actions
Close down the project.
Conduct post-project reviews.
Close the customer contract.

25. Representing and Scheduling Project Plans Techniques

Gantt Charts
Network Diagrams
PERT Calculations
Critical Path Scheduling
Project Management Software
26. Gantt Charts vs. Network Diagrams

Key differences between Gantt Charts and Network Diagrams:
Gantt charts
Show task durations.
Show time overlap.
Show slack time in duration.
Network diagrams
Show task dependencies.
Do not show time overlap, but show parallelism.
Show slack time in boxes.
27. Estimating Task Duration

PERT: Program Evaluation Review Technique
Technique that uses optimistic (o), pessimistic (p), and realistic (r) time estimates to
determine expected task duration
Formula for Estimated Time (ET):
ET = (o + 4r + p)/6
28. Example PERT Analysis
FIGURE 3-22 Estimated time calculations for the SPTS project

29. Critical Path Scheduling

A scheduling technique whose order and duration of a sequence of task activities directly
affect the completion
Critical path: the shortest time in which a project can be completed
Slack time: the time an activity can be delayed without delaying the project
30. Critical Path Example (dependencies between tasks)
PRECEDING ACTIVITIES indicate the activities that must be completed before the
specified activity can begin.
FIGURE 3-23 Sequence of Activities within the SPTS project
Network diagram shows dependencies
FIGURE 3-25 A network diagram that illustrates the activities (circles) and the sequence
(arrows) of those activities
31. Determining the Critical Path

Calculate the earliest possible completion time for each activity by summing the activity
times in the longest path to the activity. This gives total expected project time.

Calculate the latest possible completion time for each activity by subtracting the activity
times in the path following the activity from the total expected time. This gives slack time
for activities.
Critical path contains no activities with slack time.
32. Critical Path Calculation
FIGURE 3-26 A network diagram for the SPTS project showing estimated times for each
activity and the earliest and latest expected completion time for each
activity
Early and late time calculations are determined and critical path established. (Note: Activity
#5 can begin late without affecting project completion time).
FIGURE 3-27 Activity slack time calculations for the SPTS project; all activities except
number 5 are on the critical path
Note: the slack time in Activity #5.
33. Using Project Management Software

Many powerful software tools exist for assisting with project management.
Example: Microsoft Project can help with
Entering project start date.

Establishing tasks and task dependencies.

Viewing project information as Gantt or Network diagrams.
34. Project Start Date
FIGURE 3-28 Establishing a project starting date in Microsoft Project for Windows
35. Entering Tasks
FIGURE 3-29 Entering tasks and assigning task relationships in Microsoft project for
Windows

36. Viewing Network Diagram
FIGURE 3-30 Viewing project information as a network diagram in Microsoft Project for
Windows
Hexagon shape indicates a milestone.

Red boxes and arrows indicate critical path (no slack).
37. Viewing Gantt Chart

FIGURE 3-31 Gantt chart showing progress of activities (right frame) versus planned
activities (left frame)
Black line at top indicates a summary activity (composed of subtasks).

Diamond shape indicates a milestone.
Summary
Explain the process of managing an information systems project.
Describe the skills required to be an effective project manager.
List and describe the skills and activities of a project manager during project initiation,
project planning, project execution, and project closedown.
Explain what is meant by critical path scheduling and describe the process of creating
Gantt charts and network diagrams.
Explain how commercial project management software packages can be used to assist in
representing and managing project schedules.

Tutorial 03
1. Calculate the expected time for the following activities:
Activity Optimistic Time Most Likely Time Pessimistic Time Expected Time
A 3 5 7 5.0
B 5 7 10 7.2
C 7 9 14 9.5
D 2 6 7 5.5
E 1 3 5 3.0
F 5 7 10 7.2
G 8 7 14 8.3
H 1 2 5 2.3
I 4 7 9 6.8
J 5 8 11 8.0
o +4 r+ p
ET=
6
Optimistic Time+ 4 Most Likely Time+ Pessmistic Time
Expected Time=
6
2. A project has been defined to contain the following list of activities along with their required
times for completion
Activity Time (weeks) Immediate Predecessors

1- collect requirements 2 -
2- analyze processes 3 1
3- analyze data 3 2
4- design processes 7 2
5- design data 6 2
6- design screens 1 3, 4
7- design reports 5 4, 5
8- program 4 6, 7
9- test and document 8 7
10- install 2 8,9
a. Draw the network diagram for the activities.
Notation TE TL
Act E calculate from 1st activity to last calculate from last activity to 1
ivit T activity activity
y choose the largest choose the smallest
+
Tutorial 03 49
1 2 5-3=2 2 3 20-3=17 3 3 21-1=20 6 1

2 2 2+3=5 5 5 5+3=8 8 2 8+1=9 13 2
0 1
12-7=5 21-1=20
5+7=12 12+1=13
4 7
5+6=11 12-6=6 12 1 13+4=17 21-4=21
2
5 6 8 4
11 1 12+5=17 17-5=12 21 2
2 5
17-5=12 25-4=21
11+7=16 17+4=21
7 5
17 1
7 21+2=23 27-2=25
17+8=25 25-8=17
9 8 27-2=25 10 2
25 2 25+2=2 27 2
5 7 7
b. Calculate the earliest expected completion time.
27
c. Show the critical path.
1 2 4 7 9 10
d. What would happen if Activity 6 were revised to take six weeks instead of one week?
Activity 6 will not give impact to the completion of the project.
3. List the five key activities done by a project manager during a project execution?
Execute baseline project plan (BPP)

Monitor progress against baseline plan
Manage changes in baseline plan
Maintain project workbook
Communicate project status
50 Tutorial 03
4. Explain the major differences between a network diagram and a Gantt chart.
Gantt Chart Network Diagram / PERT Chart

show task duration (calendar / date) show duration in the box
show time overlap do not show time overlap, but show
dependencies / relationship among
activities
5. Assume that you have a project with SEVEN activities labeled A-G. Derive the earliest
completion time (TE), latest completion time (TL) and the slack for each of the following
tasks (start at time = 0). Which tasks are on the critical path? Draw a network diagram for the
tasks shown. Highlight the critical path in the network diagram.
Activit Preceding Duration TE TL Slack Critical

y Event(s) (DT) Path?
A - 5 5 5 0
B A 3 8 12 4
C A 4 9 9 0
D C 6 15 15 0
E B, C 4 13 16 3
F D 1 16 16 0
G D, E, F 5 21 21 0
Notation
ET Slack
Activity
TE TL
5 0 3 4 4 3
5+3=8 B 8+4=12 E
A
12-3=9 8 12 16-4=12 13 16
5 5
5+4=9 9+4=13 13+5=18
9-4=5 16-4=12 21-5=16
4 0 6 0 5 0
C 9+6=15 15+5=20
15-6=9 D G
9 9 21-5=16
15 15 21 21
16-1=15 15+1=16
16+5=21
21-5=16
Tutorial 03 51
1 0
Critical Path: A C D F G
F
16 16
6. What are the differences between problem identification and problem solving?
Problem identification is a way to find the gap or measurement between the current problem
and expectation.
Problem solving is the solution or alternative solution to reduce the gap or measurement.
7. Describe the activities performed by the project manager during project planning.
Define project scope, alternatives, feasibility

Divide project into tasks
Estimate resource requirements
Develop preliminary schedule
Develop communication plan
Determine standards and procedures
Identify and assess risk
Create preliminary budget
Develop a statement of work
Set baseline project plan
8. Match the key terms to the following definition that best fits it.
Project Manager Gantt Chart

Project Network Diagram
Deliverable Project Execution
Feasibility Study Project Closedown
Project Management Project Charter
Project Initiation Critical Path Scheduling
Project Workbook Critical Path
Project Planning Slack Time
WBS (Work Breakdown Structure) PERT (Program Evaluation Review Technique)
a) A controlled process of initiating, planning, executing and closing down a project.
Project Management
b) The shortest time in which a project can be completed.
Critical Path
c) A systems analyst with a diverse set of skills: management, leadership, technical, conflict
management and customer relationship who is responsible for initiating, planning,
executing and closing down a project.
52 Tutorial 03
Project Manager
d) An end product of an SDLC phase.
Deliverable
e) The amount of time that an activity can be delayed without delaying the entire project.
Slack Time
f) The process of dividing the project into manageable tasks and logically ordering them to
ensure a smooth evolution between tasks.
WBS (Work Breakdown Structure)
g) A technique that uses optimistic, pessimistic and realistic time estimates to calculate the
expected completion time for a particular task.
PERT (Program Evaluation Review Technique)
h) An online or hard-copy repository for all project correspondence, inputs, outputs,

deliverables, procedures and standards.
Project Workbook
i) A short document prepared for customer during project initiation that describes what the
project will deliver and outlines, generally at a high level, all work required to complete
the project.
Project Charter
j) A study that determines if the proposed information system makes sense for the
organization from an economic and operational standpoint.
Feasibility Study
Tutorial 03 53
Lecture 04: Identifying, Selecting, Initiating and

Planning System Development Projects
Learning Objectives
Describe the steps involved when identifying and selecting projects and initiating and
planning projects.
Explain the need for and the contents of a Project Scope Statement and Baseline Project Plan.
List and describe various methods for assessing project feasibility.
Describe the activities and participant roles within a structured walkthrough
Describe the differences between tangible and intangible benefits and costs and the
differences between one-time and recurring costs.
Perform cost-benefit analysis and describe what is meant by the time value of money, present
value, discount rate, net present value, return on investment, and break-even analysis.
1. Identifying and Selecting Systems Development Projects
FIGURE 4-1 Systems development life cycle with project identification and selection
highlighted
2. The Process of Identifying and Selecting IS Development Projects

(i) Identifying potential development projects
Identification from a stakeholder group
Each stakeholder group brings their own perspective and motivation to the IS
decision
Top-down source are projects identified by top management or by a diverse steering
committee.
Bottom-up source are project initiatives stemming from managers, business units, or the
development group.
The process varies substantially across organizations.
54 Identifying, Selecting, Initiating and Planning System Development Projects

Lecture 04
(ii) Classifying and ranking potential IS projects.

Using value chain analysis or other evaluation criteria.
Value chain analysis: the process of analyzing an organizations activities for making
products and/or services to determine where value is added and costs are incurred
FIGURE 4-2 Organizations can be thought of as a value chain, transforming raw

materials into products for customers.
Selecting IS development projects.

Based on various factors.
Consider both short- and long-term projects.
Select those most likely to achieve business objectives.
Is a very important and ongoing activity.
3. Factors for Project Selection

Perceived needs of the organization.
Existing systems and ongoing projects.
Resource availability.
Evaluation criteria.
Current business condition.
Perspectives of the decision makers.
4. The Process of Identifying and Selecting IS Development Projects
FIGURE 4-3 Project selection decisions must consider numerous factors and can have
numerous outcomes.
Lecture 04Identifying, Selecting, Initiating and Planning System Development

Projects 55
5. Deliverables and Outcomes

Primary deliverable from the first part of the planning phase is a schedule of specific IS
development projects (from top-down and bottom-up sources).
Outcome of the next part of the planning phase project initiation and planning is the
assurance that careful consideration was given to project selection and each project can
help the organization reach its goals.
Incremental commitment:
A selected project does not necessary result in working system.
A strategy in systems analysis and design in which the project is reviewed after each
phase, and continuation of the project is re-justified in each of these reviews.
6. Corporate Strategic Planning

Corporate strategy involves:
Mission statement
Objective statements
Description of competitive strategy
Mission statement: A statement that makes it clear what business a company is in

Lecture 04
Objective statement: a series of statements that express an organizations qualitative and

quantitative goals for reaching a desired future position
Competitive strategy: the method by which an organization attempts to achieve its

mission and objectives
Main types:
Low-cost producer
Product differentiation
Product focus or niche
TABLE 4-3 Generic Competitive Strategies

Strategy Description
Low-Cost This strategy reflects competing in an industry on the basis of
Producer product or service cost to the consumer. For example, in the
automobile industry, the South Korean-produced Hyundai is a
product line that competes on the basis of low cost.
Product This competitive strategy reflects capitalizing on a key product
Differentiation criterion requested by the market (for example, high quality, style,
performance, roominess). In the automobile industry, many
manufacturers are trying to differentiate their products on the basis
of quality (for example, At Ford, quality is job one.).
Product Focus or This strategy is similar to both the low-cost and differentiation

Projects 57
Niche strategies but with a much narrower market focus. For example, a
niche market in the automobile industry is the convertible sports car
market. Within this market, some manufacturers may employ a low-
cost strategy while others may employ a differentiation strategy
based on performance or style.
7. Information Systems Planning
FIGURE 4-10 Parallel activities of corporate strategic planning and information systems
planning
Top-down planning attempts to gain a broad understanding of information system needs

of the entire organization and offers:
Broader perspective.
Improved integration.
Improved management support.
Better understanding.
Bottom-up planning identifies IS development projects based on solving specific
operational business problems or taking advantage of specific opportunities.
Can be faster and less costly, so may be beneficial in certain circumstances.

Lecture 04
8. The Process of Initiating and Planning IS Development Projects
FIGURE 5-1 Systems development life cycle with project initiation and planning
highlighted
Project initiation focuses on activities designed to assist in organizing a team to conduct

project planning.
Establishing the Project Initiation Team.
Establishing a Relationship with the Customer.
Establishing the Project Initiation Plan.
Establishing Management Procedures.
Establishing the Project Management Environment and Project Workbook.
Developing the Project Charter.
9. Project Initiation: Deliverables & Outcomes

Projects 59
Establish and Developing:

Project Initiation Team
Relationship with Customer
Project Initiation Plan
Management Procedures
Project Management Environment and Project Workbook
Project Charter
10. The Process of Initiating and Planning IS Development Projects

The key activity of project planning is the process of defining clear, discrete activities
and the work needed to complete each activity within a single project.
The objective of the project planning process is the development of a Baseline Project
Plan (BPP) and the Project Scope Statement (PSS).
11. Elements of Project Planning

(i) Describe project scope, alternatives, feasibility.
(ii) Divide project into tasks.
(iii) Estimate resource requirements and create resource plan.
(iv)Develop preliminary schedule.
(v) Develop communication plan.
(vi)Determine standards and procedures.
(vii) Identify and assess risk.
(viii) Create preliminary budget.
(ix)Develop a statement of work.
(x) Set baseline project plan.

Business Case
Justification for an information system
Presented in terms of the tangible and intangible economic benefits and costs
The technical and organizational feasibility of the proposed system
Baseline Project Plan (BPP)
A major outcome and deliverable from the PIP phase
Contains the best estimate of a projects scope, benefits, costs, risks, and resource
requirements
Project Scope Statement (PSS)
A document prepared for the customer
Describes what the project will deliver
Outlines at a high level all work required to complete the project
13. Business Case: Assessing Project Feasibility

(i) Economic feasibility
seeks to identify the financial benefits and costs associated with the project

Lecture 04
(ii) Technical feasibility

seeks to determine if the organization is capable of developing the new system.
(iii) Operational feasibility
examines the degree of likelihood that the candidate system will be able to solve the
business problem or take advantage of opportunities.
(iv)Schedule feasibility
examines the likelihood that all potential time frame and completion date schedules
can be met.
(v) Legal and Contractual feasibility
tries to assess the potential legal ramifications due to the construction of the new
system
(vi)Political feasibility
determining stakeholders views of the candidate system is the intent of political
feasibility
14. Economic Feasibility

A process of identifying the financial benefits and costs associated with a development
project.
Often referred to as cost-benefit analysis.
Project is reviewed after each SDLC phase in order to decide whether to continue,
redirect, or kill a project.
15. Determining Project Benefits

Tangible benefits refer to items that can be measured in RM and with certainty.
Examples include:
Hardware costs,
Labor costs
Operational costs
reduced personnel expenses
lower transaction costs
higher profit margin
Most tangible benefits will fit within the following categories:
Cost reduction and avoidance
Error reduction
Increased flexibility
Increased speed of activity
Improvement of management planning and control
Opening new markets and increasing sales opportunities
Figure shows an example of the tangible benefits for Customer tracking System. Benefits that
can be measured in dollars and with certainty

Projects 61
Intangible benefits are benefits derived from the creation of an information system that
cannot be easily measured in RM or with certainty.
May have direct organizational benefits, such as the improvement of employee
morale.
May have broader societal implications, such as the reduction of waste creation or
resource consumption.
Example:
Loss of customer goodwill,
Employee morale, or
Operational inefficiency.
Example of Intangible Benefits that cannot easily be measured in dollars or with certainty
TABLE 5-3 Intangible Benefits from the Development of an Information System

Competitive necessity Faster decision making
More timely information Information processing efficiency
Improved organizational planning Improved asset utilization
Increased organizational flexibility Improved resource control
Promotion of organizational learning Increased accuracy in clerical operations
and understanding Improved work process that can improve
Availability of new, better, or more employee morale
information Positive impacts on society
Ability to investigate more alternatives

Lecture 04
One-time cost: a cost associated with project start-up and development or system start-
up.
These costs encompass activities such as:
Systems development,
New hardware and software purchases,
User training,
Site preparation, and
Data or system conversion.
FIGURE 5-5 One-time costs for Customer Tracking System (Pine Valley Furniture)
Recurring cost: a cost resulting from the ongoing evolution and use of a system.
Examples of these costs include:
Application software maintenance,
Incremental data storage expenses,
Incremental communications,
New software and hardware leases, and

Projects 63
Supplies and other expenses (i.e. paper, forms, data center personnel).
FIGURE 5-6 Recurring costs for Customer Tracking System (Pine Valley Furniture)
Both one-time and recurring costs can consist of items that are fixed or variable in nature.
Fixed costs are billed or incurred at a regular interval and usually at a fixed rate.
Variable costs are items that vary in relation to usage.
16. Three Financial Measurements for Economic Feasibility

Net Present Value (NPV)
Use discount rate to determine present value of cash outlays and receipts
Return on Investment (ROI)
Ratio of cash receipts to cash outlays
Break-Even Analysis (BEA)
Amount of time required for cumulative cash flow to equal initial and ongoing
investment
17. Definitions of Terms

Present value: current value of a future cash flow.
Discount rate: rate of return used to calculate the present value of future cash flows.
Time value of money (TVM): comparing present cash outlays to future expected returns
or the concept that money available today is worth more than the same amount tomorrow.
18. The Time Value of Money

Net Present Value
PVn = present value of Y dollars n years from now based on a discount rate of i.
NPV = sum of PVs across years.
Calculates time value of money(TVM)

Lecture 04
Summary spreadsheet reflecting PV calculation for all benefits and costs
19. Break Even Analysis

Break-even Analysis: a type of cost-benefit analysis to identify at what point (if ever)
benefits equal costs.

Projects 65
FIGURE 5-8 Break-even analysis for Customer Tracking System (Pine Valley
Furniture)
20. Technical Feasibility

Project size
Team size, organizational departments, project duration, programming effort
Project structure
New vs. renovated system, resulting organizational changes, management
commitment, user perceptions
Development group
Familiarity with platform, software, development method, application area,
development of similar systems
User group
Familiarity with IS development process, application area, use of similar systems
21. Other Feasibilities

Operational
Does the proposed system solve problems or take advantage of opportunities?
Schedule
Can the project time frame and completion dates meet organizational deadlines?
Legal and Contractual
What are legal and contractual ramifications of the proposed system development
project?
Political
How do key stakeholders view the proposed system?
22. Building the Baseline Project Plan

Baseline Project Plan (BPP) is a document intended primarily to guide the development
team.
Sections:
Introduction
System description
Feasibility assessment
Management issues

Lecture 04
FIGURE 5-10 Outline of a Baseline Project Plan
Project Scope Statement is part of the BPP introduction.

Sections:
Problem statement
Project objectives
Project description
Business benefits
Deliverables
Expected duration

Projects 67
FIGURE 5-11 Statement of project scope (Pine Valley Furniture)
23. Factors in Determining Project Scope

Organizational units affected by new system
Current systems that will interact with or change because of new system
People who are affected by new system
Range of potential system capabilities
24. Diagram Depiction of Project Scope
FIGURE 5-12 Context-level data flow diagram showing project scope for Purchasing
Fulfillment System (Pine Valley Furniture)

Lecture 04
25. Building the Baseline Project Plan

System description section outlines possible alternative solutions.
Feasibility assessment section outlines issues related to project costs and benefits,
technical difficulties, and other such concerns.
Management issues section outlines a number of managerial concerns related to the
project.
26. Reviewing the Baseline Project Plan

Structured Walkthroughs: a peer-group review of any product created during the
system development process
Roles: coordinator, presenter, user, secretary, standard-bearer, maintenance oracle
Can be applied to BPP, system specifications, logical and physical designs, program code,
test procedures, manuals and documentation
Figures show sample of Walkthrough Review Form and Walkthrough Action List
Summary
After this chapter, you should learn all the learning objectives listed at the beginning of the
class.

Projects 69
Tutorial 04
1. Assuming monetary benefits of an information system at $85,000 per year, one-time costs of
$75,000, recurring costs of $35,000 per year, a discount rate of 12 percent, and a five-year
time horizon, calculate the Net Present Value of these costs and benefits of an information
system. Also calculate the overall Return on Investment of the project and then present a
Break-Even Analysis. At what point does break-even occur?
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Total

Net Economic 85000 85000 85000 85000 85000
Benefit
Discount Rate 0.12 0.89 0.80 0.71 0.64 0.59
PV of Benefits 75650 68000 60350 54400 50150
NPV of all 75650 14365 20400 25840 30855 30855

Benefits 0 0 0 0 0
One-Time 75000
Costs
Recurring 35000 35000 35000 35000 35000

Costs
Discount Rate 0.12 0.89 0.80 0.71 0.64 0.59
PV of 31150 28000 24850 22400 20650
Recurring
Costs
NPV of all 106150 13415 15900 18140 20205 20205

Costs 0 0 0 0 0
Overall NPV 10650

0
Overall ROI 0.53
Break-even 1.7
Analysis years
Yearly NPV (75000 44500 40000 35500 32000 29500
Cash Flow )
Overall NPV (75000 (30500 9500 45000 77000 10650
Cash Flow ) ) 0
The Break down Point happened on 1.7 years.
70 Tutorial 04
1
Discount Rate Value=
( 1+i )n
i = Discount Rate, n = Year
1 1
Discount Rate Value ( Year 1 )= = =0.89
( 1+ 0.12 ) ( 1.12 )1
1
1 1
Discount Rate Value ( Year 2 )= = =0.80
( 1+0.12 ) ( 1.12 )2
2
PV of Benefits = Net Economic Benefit Discount Rate
NPV of Benefits = Cumulative PV of Benefits
PV of Recurring Costs = Recurring Costs Discount Rate
NPV of all Costs = One-Time Costs + Cumulative PV of Benefits
Overall NPV = NPV of All Benefits NPV of all Costs
Overall NPV
Overall ROI =
NPV ofAll Costs
Yearly NPV Cash Flow = PV of Benefits PV of Costs
Yearly NPV Cash FlowOverall NPV Cash Flow

Break even Point=
Yearly NPV Cash Flow
400009500
(Year 2)= =0.7625=0.7/0.8
40000
2. Describe the three commonly used methods for performing economic cost-benefit analysis.
(i) Break-even duration

(ii) Return of Investment (ROI) ratio
(iii) Net Present Value (NPV) discount value / reflection rate
3. Describe the concept of the time value of money. How does the discount rate affect the value
of $1 today versus one year from today?
Tutorial 04 71
The concept of the time value of money is comparison of the current value with the future
rate. $ 1 is not going to be the same value next year because of the discount rate.
4. In a project, the initial investment for the project is RM45000. The present values for Year 1,
2, 3, 4 and 5 are RM25455, RM9917, RM7513, RM6830 and RM6209 respectively. How
much is the Net Present Value (NPV)?
Cost = RM 45000
Benefits = RM 25455 + RM 9917 + RM 7513 + RM 6830 + RM 6209 = RM 55924
NPV = Benefits Cost
= RM 55924 RM 45000
= RM 10924
(Economic Feasibility, Discount Rate, Intangible benefit, One-time cost, Tangible benefit,
Intangible Cost, Baseline Project Plan, Schedule Feasibility, Operational Feasibility,
Recurring Cost, Statement of Work, Intangible Benefit, Tangible Cost, Technical Feasibility)
5. Match each of the key terms above with the definitions that best fits it.
a. Analyzing an organizations activities to determine where value is added to products
and/or services and the costs incurred for doing so.
Value Chain Analysis
b. A strategy in systems analysis and design in which the project is reviewed after each
phase and continuation of the project is rejustified in each of these reviews.
Incremental Commitment
c. An ongoing process that defines the mission, objectives, and strategies of an organization.
Corporate Strategy Planning
d. A statement that makes it clear what business a company is in.
Mission Statement
e. A series of statements that express an organizations qualitative and quantitative goals for
reaching a desired future position.
Objective Statement
f. The method by which an organization and defining the systems, databases, and
technologies that will best satisfy those needs.
72 Tutorial 04
Competitive Strategy
g. An orderly means of assessing the information needs of an organization and defining the
systems, databases, and technologies that will best satisfy those needs.
Information Systems Planning
h. A generic information systems planning methodology that attempts to gain a broad

understanding of the information system needs of the entire organization.
Top-Down Planning
i. A generic information systems planning methodology that identifies and defines IS

development projects based upon solving operational business problems or taking
advantage of some business opportunities.
Bottom-Up Planning
j. Document prepared for the customer during project initiation and planning that describes
what the project will deliver and outlines generally at a high level all work required to
complete the project.
Project Scope Statement
k. A process of identifying the financial benefits and costs associated with a development
project.
Economic Feasibility
l. The process of assessing the degree to which a proposed system solves business problems
or takes advantage of business opportunities.
Operational Feasibility
m. A cost resulting from the ongoing evolution and use of a system.
Recurring Cost
n. The rate of return used to compute the present value of future cash flows.
Discount Rate
o. A benefit derived from the creation of an information system that cannot be easily
measured in dollars or with certainty.
Tutorial 04 73
Intangible Benefits
p. The process of assessing the degree to which the potential time frame and completion
dates for all major activities within a project meet organizational deadlines and
constraints for affecting change.
Schedule Feasibility
q. A cost associated with an information system that can be easily measured in dollars and
certainty.
Tangible Cost
r. A process of assessing the development organizations ability to construct a proposed

system.
Technical Feasibility
s. A cost associated with project start-up and development or system start-up.
One-Time Cost
t. A benefit derived from the creation on an information system that can be measured in
dollars and with certainty.
Tangible Benefits
u. The process of assessing potential legal and contractual ramifications due to the
construction of a system.
Legal and Contractual Feasibility
v. A cost associated with an information system that cannot be easily measured in terms of
dollars or with certainty.
Intangible Cost
w. The plan is the major outcome and deliverable from the project initiation and planning
phase and contains the best estimate of the projects scope, benefits, costs, risks, and
resource requirements.
Baseline Project Plan (BPP)
74 Tutorial 04
Lecture 05: Analysis: Determining System

Requirements
Learning Objectives
Describe options for designing and conducting interviews and develop a plan for conducting
an interview to determine system requirements.
Explain the advantages and pitfalls of observing workers and analyzing business documents
to determine system requirements.
Explain how computing can provide support for requirements determination.
Participate in and help plan a Joint Application Design session.
Use prototyping during requirements determination.
Describe contemporary approaches to requirements determination.
Understand how requirements determination techniques apply to the development of
electronic commerce applications.
1. Performing Requirements Determination
FIGURE 6-1 Systems development life cycle with analysis phase highlighted
2. The Process of Determining Requirements

Good Systems Analyst Characteristics:
Impertinence question everything
Impartiality consider all issues to find the best organizational solution
Relaxing constraints assume anything is possible
Attention to details every fact must fit
Reframing challenge yourself to new ways


Deliverables for Requirements Determination:
From interviews and observations interview transcripts, observation notes,
meeting minutes
From existing written documents mission and strategy statements, business forms,
procedure manuals, job descriptions, training manuals, system documentation,
flowcharts
From computerized sources Joint Application Design session results, CASE
repositories, reports from existing systems, displays and reports from system
prototype
4. Traditional Methods for Determining Requirements

Interviewing individuals
Interviewing groups
Observing workers
Studying business documents
5. Interviewing and Listening

One of the primary ways analysts gather information about an information systems
project
Interview Guide is a document for developing, planning and conducting an interview.
6. Guidelines for Effective Interviewing

Plan the interview.
Prepare interviewee: appointment, priming questions.
Prepare agenda, checklist, questions.
Listen carefully and take notes (tape record if permitted).
Review notes within 48 hours.
Be neutral.
Seek diverse views.
7. Interviewing and Listening
76 Analysis: Determining System Requirements Lecture 05

FIGURE 6-2 Typical interview guide
8. Choosing Interview Questions

Each question in an interview guide can include both verbal and non-verbal information.
Open-ended questions: questions that have no prespecified answers
Closed-ended questions: questions that ask those responding to choose from among
a set of specified responses
9. Interviewing Groups
Drawbacks to individual interviews:
Contradictions and inconsistencies between interviewees
Follow-up discussions are time consuming
New interviews may reveal new questions that require additional interviews with
those interviewed earlier
Interviewing several key people together
Advantages
More effective use of time
Can hear agreements and disagreements at once
Opportunity for synergies
Disadvantages
More difficult to schedule than individual interviews
10. Nominal Group Technique (NGT)

A facilitated process that supports idea generation by groups
Process
Members come together as a group, but initially work separately.
Each person writes ideas.
Facilitator reads ideas out loud, and they are written on a blackboard or flipchart.
Group openly discusses the ideas for clarification.
Ideas are prioritized, combined, selected, reduced.
NGT exercise used to complement group meetings or as part of JAD effort.
11. Directly Observing Users

Direct Observation
Watching users do their jobs
Obtaining more firsthand and objective measures of employee interaction with
information systems
Can cause people to change their normal operating behavior
Time-consuming and limited time to observe
12. Analyzing Procedures and Other Documents

Document Analysis
Review of existing business documents
Can give a historical and formal view of system requirements
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
Reasons for current system design
Rules for processing data
Useful document: Written work procedure
For an individual or work group
Describes how a particular job or task is performed
Includes data and information used and created in the process
FIGURE 6-3 Example of a procedure

Potential Problems with Procedure Documents:

May involve duplication of effort.
May have missing procedures.
May be out of date.
May contradict information obtained through interviews.
Formal Systems: the official way a system works as described in organizational
documentation (i.e. work procedure)
Informal Systems: the way a system actually works (i.e. interviews, observations)
Useful document: Business form
Used for all types of business functions
Explicitly indicate what data flow in and out of a system and data necessary for the
system to function
Gives crucial information about the nature of the organization
FIGURE 6-4 An example of a business formAn invoice form for QuickBooks, from
jnk.btobsource.com.
Useful document: Report

Primary output of current system
Enables you to work backwards from the report to the data needed to generate it
Useful document: Description of current information system
TABLE 6-4 Comparison of Observation and Document Analysis

Characteristic Observation Document Analysis
Information High (many channels) Low (passive) and old
Richness

Time Required Can be extensive Low to moderate

Expenses Can be high Low to moderate
Chance for Good: probing and clarification Limited: probing possible only if
Follow-up and questions can be asked during or original author is available
Probing after observation
Confidentiality Observer is known to Depends on nature of document;
interviewer; observer may does not change simply by being
change behavior when observed read
Involvement of Interviewers may or may not be None, no clear commitment
Subject involved and committed
depending on whether they
know if they are being observed
Potential Limited numbers and limited Potentially biased by which
Audience time (snapshot) of each documents were kept or because
document was not created for this
purpose
13. Contemporary Methods for Determining System Requirements

Brings together key users, managers, and systems analysts
Purpose: collect system requirements simultaneously from key people
Conducted off-site
Group Support Systems
Facilitate sharing of ideas and voicing of opinions about system requirements
CASE tools
Used to analyze existing systems
Help discover requirements to meet changing business conditions
System prototypes
Iterative development process
Rudimentary working version of system is built
Refine understanding of system requirements in concrete terms
14. Joint Application Design (JAD)

Intensive group-oriented requirements determination technique
Team members meet in isolation for an extended period of time
Highly focused
Resource intensive
Started by IBM in 1970s

FIGURE 6-6 Illustration of the typical room layout for a JAD
JAD Participants:
Session Leader: facilitates group process
Users: active, speaking participants
Managers: active, speaking participants
Sponsor: high-level champion, limited participation
Systems Analysts: should mostly listen
Scribe: record session activities
IS Staff: should mostly listen
End Result
Documentation detailing existing system
Features of proposed system
Upper CASE tools are used
Enables analysts to enter system models directly into CASE during the JAD session
Screen designs and prototyping can be done during JAD and shown to users
15. Using Prototyping During Requirements Determination

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.
There is a history of communication problems between analysts and users.
Tools are readily available to build prototype.
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
16. Radical Methods for Determining System Requirements

Business Process Reengineering (BPR): search for and implementation of radical
change in business processes to achieve breakthrough improvements in products and
services
Goals
Reorganize complete flow of data in major sections of an organization.
Eliminate unnecessary steps.
Combine steps.
Become more responsive to future change.
17. Identifying Processes to Reengineer

Identification of processes to reengineer
Key business processes
Structured, measured set of activities designed to produce specific output for a
particular customer or market
Focused on customers and outcome
Same techniques are used as for requirements determination
18. Disruptive Technologies

Information technologies must be applied to radically improve business processes.
Disruptive technologies are technologies that enable the breaking of long-held business
rules that inhibit organizations from making radical business changes.
TABLE 6-6 Long-Held Organizational Rules That Are Being Eliminated Through
Disruptive Technologies
Rule Disruptive Technology
Information can appear in only one place Distributed databases allow the sharing of
at a time. information.
Businesses must choose between Advanced telecommunications networks can
centralization and decentralization. support dynamic organizational structures.
Managers must make all decisions. Decision-support tools can aid nonmanagers.
Field personnel need offices where they Wireless data communication and portable
can receive, store, retrieve, and transmit computers provide a virtual office for
information. workers.
The best contact with a potential buyer is Interactive communication technologies allow
personal contact. complex messaging capabilities.

You have to find out where things are. Automatic identification and tracking
technology knows where things are.
Plans get revised periodically. High-performance computing can provide
real-time updating.
19. Requirements Determination using Agile Methodologies

Continual user involvement
Replace traditional SDLC waterfall with iterative analyze design code test cycle
Agile usage-centered design
Focuses on user goals, roles, and tasks
The Planning Game
Based on eXtreme programming
Exploration, steering, commitment
20. Continual User Involvement
FIGURE 6-11 The iterative analysisdesigncodetest cycle
21. Agile Usage-Centered Design Steps

Gather group of programmers, analysts, users, testers, facilitator.

Document complaints of current system.

Determine important user roles.
Determine, prioritize, and describe tasks for each user role.
Group similar tasks into interaction contexts.
Associate each interaction context with a user interface for the system, and prototype the
interaction context.
Step through and modify the prototype.
22. The Planning Game from eXtreme Programming
FIGURE 6-12 eXtreme Programmings Planning Game
23. Electronic Commerce Applications: Determining System Requirements

Determining system requirements for Pine Valley furnitures Webstore
System layout and navigation characteristics
Webstore and site management system capabilities
Customer and inventory information
System prototype evolution
Summary
Describe interviewing options and develop interview plan.
Explain advantages and pitfalls of worker observation and document analysis.
Explain how computing can support requirements determination.
Participate in and help plan Joint Application Design sessions.
Use prototyping during requirements determination.
Describe contemporary approaches to requirements determination.

Understand how requirements determination techniques apply to the development of

electronic commerce applications.
24. Components to understand during determining system requirements:

(a) Business objective that drive what and how work is done
(b) Information people need to do their jobs
(c) Data (definition, volume, size) handled within the organization to support the jobs
(d) When, how and by whom or what the data are moved, transformed and stored
(e) Sequences and other dependencies among difference data-handling activities
(f) Rules governing how data are handled and processed
(g) Policies and guidelines the nature of the business and the market and environment in
which it operates
(h) Key events affecting data values and when these events occur.

Tutorial 05
1. Describe four traditional techniques for collecting information during analysis. When might
one be better than another?
Traditional Methods
a. Interview
- Observation (gesture)
- Open-ended questionnaire (ask another related question)
- Active
- Person-contact
- First-hand information
- Bias to individual
b. Questionnaire
- Analysis (statistical view of point)
- Wider participant
- General point of view
- Fast, cheap
- Closed-ended
c. Observation during work days
- Direct contact
- Passive
- Seldom ask questions
- 1-2 weeks (slow)
- Incomplete requirements
- Complete picture of the activities
d. Document Analysis
- History
- SOP
- Redundancies (blank form, filled-up form)
2. What is JAD? How is it better than traditional information gathering techniques? What are its
weaknesses?
JAD
- Joint Application Design
- Intensive group-oriented requirements determination technique
- A series of intensive meeting for requirements determination
- Save time
- Generate more idea
- More interaction
- High quality result
86 Tutorial 05
Weakness
- High commitment needed
- Expensive
- Need proper planning
3. How has computing been used to support requirements determination?
CASE tools (used to design interface and prototype)
4. How can NGT be used for requirements determination?
Idea generation and prioritize
5. How can CASE tools be used to support requirements determination? Which types of CASE
tools are appropriate for use during requirements determination?
6. Describe how prototyping can be used during requirements determination. How is it better or
worse than traditional methods?
When definition and requirement not complete when the system is complicate
communication problem with clients only involved a few stakeholder
Pros:
- Prototype certain part
Cons:
- Interaction problem
- SDLC not around
- No proper documentation because of refinement of prototype
7. When conducting a business process reengineering study, what should you look for when
trying to identify business processes to change? Why?
Reengineering
- Change / restructure whole process
- When the direction of company change
- Find key process in order to identify problem encountered
- Speed, quality and customer satisfaction need to be consider
8. What are disruptive technologies and how they enable organizations to radically change their
business processes?
9. Why is continual user involvement a useful way to discover system requirements? Under
what conditions it might be used? Under what conditions might it not be used?
Tutorial 05 87
10. Describe Agile Usage-Centered Design. Describe the Planning Game. Compare and contrast
these two requirements determination techniques.
(Formal System, Scribe, Open-ended Question, Informal System, JAD Session Leader,
Closed-ended Question, Disruptive Technologies, Nominal Group Technique, Key Business
Process, Business Processing Reengineering)
11. Match each of the key terms above with the definition that best fits it.
a. Questions in interviews and on questionnaires that ask those responding to choose from
among a set of specified responses.
Closed-ended Question
b. Technologies that enable the breaking of long-held business rules that inhibit
organizations from making radical business changes.
Disruptive Technologies
c. A facilitated process that supports idea generating by groups. At the beginning of the
process, group members work alone to generate ideas, which are then pooled under the
guidance of a trained facilitator.
Nominal Group Technique (NGT)
d. The structured, measured set of activities designed to produce a specific output for a
particular customer or market.
Key Business Process
e. The official way system works as described in organizational documentation.
Formal Systems
f. The search for, and implementation of, radical change in business processes to achieve
breakthrough improvements in products and services.
Business Process Reengineering (BPR)
g. The way a system actually works.
Informal Systems
h. The person who makes detailed notes of the happenings at a Joint Application Design
session.
Scribe
88 Tutorial 05
i. Questions in interviews and on questionnaires that have no prespecified answers.
Open-ended Question
j. The trained individual who plans and leads Joint Application Design sessions.
JAD Session Leader
Case Study
Situation: The school, Elmwood College is considering a new system that will speed up the
registration process. As a systems analyst, you are asked to develop a plan for
fact-finding.
1. List all the possible techniques that you might use.
Analysis
- Interview
- Questionnaire
- Observation
- Document Analysis
2. Describe an advantage for each technique.
3. Suppose the development budget is tight. How might that affect the fact-finding process?
Budget
- Sources (planning)
- Programmes
- Time framer (shorter)
- Involve less people

- Interview will not be conducted (a few interview will consumed a lot of cost)
4. What are the five important questions to use during fact-finding?
Covers 4W1H
Tutorial 05 89
Baxter Community College Part 1

Baster Community College is a two-year school in New Jersey. Twice a year, the records office
at Baxter mails requests for donations to the alumni. The staff uses a word processing merge file
to create personalized letters, but the date on past contributions and other alumni information is
stored manually. The registrar, Mary Louise, recently submitted a systems request asking the
colleges IT department to develop a computerized alumni information system. Baxter
Community College does not have a formal systems review committee, and each department
head has an individual budget for routine information services.
Todd Wagner, a systems analyst, was assigned to perform a preliminary investigation. After
reading his report. Mary asked him to proceed with the systems analysis phase, saying that a
formal presentation was unnecessary. Todd was scheduled an interview tomorrow with her, and
he asked you to help him prepare for the meeting.
1. Make a list of the topics that you think Todd should cover during the interview.
2. Prepare a list of specific questions that Todd should ask. Include open-ended, closed-ended,
and range-of-response questions.
[Open-ended] What are the problems with the current operating procedure?
[Open-ended] What are the expectation of the new system?
[Closed-ended] What are the duration of the purposed system?
[Closed-ended] How often they contact the alumni? (which month)
[Closed-ended] How often they update alumni information?
[Range-of-response] Do you happy with the current system?
Baxter Community College Part 2

Todd Wagner completed the systems analysis work and prepared a recommendation for a new
alumni system with online update and query features. He discussed his ideas with Penny Binns,
the IT department head, and several coworkers. They all felt that Todd had excellent ideas. Todd
then prepared and sent the final report for the systems analysis phase.
Before completing this part of the case, you should review the presentations section in the
Systems Analysts Toolkit.
This time, Mary Louise, the registrar, wanted a formal presentation. She requested that the
college president and all the administrative vice presidents receive invitations to attend. The
registrar wanted to ensure that she would have support for the new alumni System.
Unfortunately, Todds car would not start the morning of the presentation. Therefore, he arrived
12 minutes late for the presentation and was out of breath and disorganized. He immediately
apologized and began to set out his notes. He then noticed that an easel was not in the room to
hold his flip charts. Consequently, he moved a table closer to the front wall, placed the flip chart
on the table, popped it against the wall, and began his presentation.
90 Tutorial 05
The flip chart was not very steady in that position, however, so Todd stood next to it to hold it. In
order to flip to the next chart, Todd had to juggle the entire flip chart. He was so busy with the
charts that he did not notice that people in the back of the room strained to see them. The
registrar finally interrupted to point out that not everyone was able to see the charts. Todd rushed
out of the room to find an easel. When he finally returned with an easel, he found that several of
the attendees had left. He did finish the presentation but with little of his original enthusiasm.
1. List every mistake that Todd made.
Mistakes made by Todd

- He was late for presentation
- Needed requirements are not ready / in-place
- No interaction with audience
- He went out to find the easel
- Emotionally affected
2. For each mistake listed, describe what Todd should have done differently.
- Call up office, and tell what he will be late

- A day before presentation, he has to make sure everything needed is in-place
- Get an assistant to help to flip chart
- Ask for help / inform
3. What might Mary Louise have done to help Todd?
- Call Todd and ask the reason why he being late

- Apologize on behalf of Todd
- Engage the audience
- Make the audience busy
- Alert Todd about the presentation
- Find the easel
4. What do you think Todd should do next to try to salvage the project?
- Ask the boss to apologize on behalf of Todd

- Ask the boss to send the presentation slides to audience
Tutorial 05 91
Lecture 06a: Structuring System Process

Requirements
1. Process Modeling
FIGURE 7-1 Systems development life cycle with the analysis phase highlighted

Context data flow diagram (DFD)
Scope of system
DFD = A picture of movement of data between external entities (person, place),
processes and data stores within a system.
DFDs of new logical system
Technology independent
Show data flows, structure, and functional requirements of new system
Thorough description of each DFD component
3. Data Flow Diagramming Mechanics

Represent both physical and logical information systems
Only four symbols are used
Useful for depicting purely logical information flows
DFDs that detail physical systems differ from system flowcharts which depict details of
physical computing equipment
92 Structuring System Process Requirements Lecture 06a

4. Definitions and Symbols
FIGURE 7-2 Comparison of DeMarco and Yourdon and Gane and Sarson DFD symbol
sets
Process: work or actions performed on data (inside the system)

Data store: data at rest (inside the system)
Source/sink: external entity that is origin or destination of data (outside the system)
Data flow: arrows depicting movement of data
5. Developing DFDs
Context diagram is an overview of an organizational system that shows:
the system boundaries.
external entities that interact with the system.
major information flows between the entities and the system.
Note: only one process symbol, and no data stores shown
6. Context Diagram
FIGURE 7-4 Context diagram of Hoosier Burgers food-ordering system
7. Developing DFDs
Level-0 diagram is a data flow diagram that represents a systems major processes, data
flows, and data stores at a high level of detail.

Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive
(lower-level) DFDs.
8. Level-0 Diagram
FIGURE 7-5 Level-0 DFD of Hoosier Burgers food-ordering system

9. Data Flow Diagramming Rules

There are two DFD guidelines that apply:
The inputs to a process are different from the outputs of that process.
Processes purpose is to transform inputs into outputs.
Objects on a DFD have unique names.
Every process has a unique name.
FIGURE 7-6 Incorrect and correct ways to draw data flow diagrams

TABLE 7-2 Rules Governing Data Flow Diagramming

Process:
A. No process can have only outputs. It is making data from nothing (a miracle). If an
object has only outputs, then it must be a source.
B. No process can have only inputs (a black hole). If an object has only inputs, then it
must be a sink.
C. A process has a verb phrase label.
Data Store:
D. Data cannot move directly from one data store to another data store. Data must be
moved by a process.
E. Data cannot move directly from an outside source to a data store. Data must be moved
by a process that receives data from the source and places the data into the data store.
F. Data cannot move directly to an outside sink from a data store. Data must be moved by
a process.
G. A data store has a noun phrase label.
Source/Sink:
H. Data cannot move directly from a source to a sink. It must be moved by a process if the
data are of any concern to our system. Otherwise, the data flow is not shown on the
DFD.
I. A source/sink has a noun phrase label.
Data Flow:
J. A data flow has only one direction of flow between symbols. It may flow in both
directions between a process and a data store to show a read before an update. The
latter is usually indicated, however, by two separate arrows because these happen at
different times.
K. A fork in a data flow means that exactly the same data goes from a common location to
two or more different processes, data stores, or sources/sinks (this usually indicates
different copies of the same data going to different locations).
L. A join in a data flow means that exactly the same data come from any of two or more
different processes, data stores, or sources/sinks to a common location.
M. A data flow cannot go directly back to the same process it leaves. There must be at least
one other process that handles the data flow, produces some other data flow, and returns
the original data flow to the beginning process.
N. A data flow to a data store means update (delete or change).
O. A data flow from a data store means retrieve or use.
P. A data flow has a noun phrase label. More than one data flow noun phrase can appear
on a single arrow as long as all of the flows on the same arrow move together as one
package.

10. Decomposition of DFDs

Functional decomposition is an iterative process of breaking a system description down
into finer and finer detail.
Creates a set of charts in which one process on a given chart is explained in greater
detail on another chart.
Continues until no subprocess can logically be broken down any further.
Primitive DFD is the lowest level of a DFD.
Level-1 diagram results from decomposition of Level-0 diagram.
Level-n diagram is a DFD diagram that is the result of n nested decompositions from a
process on a level-0 diagram.
11. Level-1 DFD
FIGURE 7-8 Level-1 diagram showing the decomposition of Process 4.0 from the level-
0 diagram for Hoosier Burgers food-ordering system
12. Level-n DFD
FIGURE 7-9 Level-2 diagram showing the decomposition of Process 4.3 from the level-
1 diagram for Process 4.0 for Hoosier Burgers food-ordering system

13. Balancing DFDs

Conservation Principle: conserve inputs and outputs to a process at the next level of
decomposition
Balancing: conservation of inputs and outputs to a data flow diagram process when that
process is decomposed to a lower level
Balanced means:
Number of inputs to lower level DFD equals number of inputs to associated process
of higher-level DFD
Number of outputs to lower level DFD equals number of outputs to associated
process of higher-level DFD
FIGURE 7-10 An unbalanced set of data flow diagrams
Data flow splitting is when a composite data flow at a higher level is split and different
parts go to different processes in the lower level DFD.
The DFD remains balanced because the same data is involved, but split into two parts.

FIGURE 7-11 Example of data flow splitting
TABLE 7-3 Advanced Rules Governing Data Flow Diagramming

Q. A composite data flow on one level can be split into component data flows at the next
level, but no new data can be added and all data in the composite must be accounted for
in one or more subflows.
R. The inputs to a process must be sufficient to produce the outputs (including data places
in data stores) from the process. Thus, all outputs can be produced, and all data in
inputs move somewhere: to another process or to a data store outside the process or
onto a more detailed DFD showing a decomposition of that process.
S. At the lowest level of DFDs, new data flows may be added to represent data that are
transmitted under exceptional conditions; these data flows typically represent error
messages (e.g., Customer not known; do you want to create a new customer?) or
confirmation notices (e.g., Do you want to delete this record?).
T. To avoid having data flows lines cross each other, you may repeat data stores or
sources/sinks on a DFD. Use an additional symbol, like a double line on the middle
vertical line of a data store symbol or a diagonal line in a corner of a sink/source
square, to indicate a repeated symbol.
14. Four Different Types of DFDs

Current Physical
Process labels identify technology (people or systems) used to process the data.
Data flows and data stores identify actual name of the physical media.
Current Logical
Physical aspects of system are removed as much as possible.
Current system is reduced to data and processes that transform them.
New Logical
Includes additional functions.

Obsolete functions are removed.

Inefficient data flows are reorganized.
New Physical
Represents the physical implementation of the new system.
15. Guidelines for Drawing DFDs

Completeness
DFD must include all components necessary for system.
Each component must be fully described in the project dictionary or CASE
repository.
Consistency
The extent to which information contained on one level of a set of nested DFDs is
also included on other levels
Timing
Time is not represented well on DFDs.
Best to draw DFDs as if the system has never started and will never stop.
Iterative Development
Analyst should expect to redraw diagram several times before reaching the closest
approximation to the system being modeled.
Primitive DFDs
Lowest logical level of decomposition
Decision has to be made when to stop decomposition
Rules for stopping decomposition
When each process has been reduced to a single decision, calculation or database
operation
When each data store represents data about a single entity
When the system user does not care to see any more detail
When every data flow does not need to be split further to show that data are handled
in various ways
When you believe that you have shown each business form or transaction, online
display and report as a single data flow
When you believe that there is a separate process for each choice on all lowest-level
menu options
16. Using DFDs as Analysis Tools

Gap Analysis is 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.

FIGURE 7-16 IBM Credit Corporations primary work process before BPR
FIGURE 7-17 IBM Credit Corporations primary work process after BPR
17. Electronic Commerce Application: Process Modeling using Data Flow Diagrams
Process modeling for Pine Valley Furnitures Webstore
Completed JAD session.
Began translating the Webstore system structure into data flow diagrams.
Identified six high-level processes.
TABLE 7-4 System Structure of the WebStore and Corresponding Level-0 Processes
WebStore System Processes
Main Page Information Display (minor / no processes)
Product Line (Catalog) 1.0 Browse Catalog
Desks 2.0 Select Item for Purchase
Chairs
Tables
File Cabinets
Shopping Cart 3.0 Display Shopping Cart
Checkout 4.0 Check Out Process Order
Account Profile 5.0 Add/Modify Account Profile
Order Status/History 6.0 Order Status Request

Customer Comments Information Display (minor / no processes)

Company Information
Feedback
Contact Information
FIGURE 7-22 Level-0 data flow diagram for the WebStore
Summary
Understand logical process modeling via data flow diagrams (DFDs).
Draw data flow diagrams of well structured process models.
Decompose data flow diagrams into lower-level diagrams.
Balance high-level and low-level data flow diagrams.
Use data flow diagrams for analyzing information systems.
Use decision tables to represent the logic of choice in conditional statements.

Lecture 06b: Logic Requirements

Learning Objectives
Use Structured English as a tool for representing steps in logical processes in data flow
diagrams.
Select among Structured English and decision tables for representing processing logic.
Understand how logic modeling techniques apply to the development of electronic commerce
applications.
1. Logic Modeling
Data flow diagrams do not show the logic inside the processes.
Logic modeling involves representing internal structure and functionality of processes
depicted on a DFD.
Logic modeling can also be used to show when processes on a DFD occur.
2. Modeling a Systems Logic
FIGURE 8-1 Systems development life cycle with the analysis phase highlighted

Structured English representation of process logic.
Decision Tables representation.
Sequence diagram.
Activity diagram.
4. Modeling Logic with Structured English

Structured English: modified form of English language used to specify the logic of
information system processes.
No single standard.
Typically relies on action verbs and noun phrases and contains no adjectives or No
specific standards.

FIGURE 8-2 Current logical DFD for Hoosier Burger's inventory control system
FIGURE 8-3 Structured English representations of the four processes depicted in

FIGURE 8-2
5. Modeling Logic with Decision Tables

Decision table: a matrix representation of the logic of a decision which specifies the
possible conditions for the decision and the resulting actions.
Best used for complicated decision logic.
104 Logic Requirements Lecture 06b

FIGURE 8-4 Complete decision table for payroll system example
Condition stubs: that part of a decision table that lists the conditions relevant to the
decision.
Action stubs: that part of a decision table that lists the actions that result for a given set
of conditions.
Rules: that part of a decision table that specifies which actions are to be followed for a
given set of condition.
Indifferent condition: in a decision table, a condition whose value does not affect which
actions are taken for two or more rules.
Procedure for Creating Decision Tables
Name the condition and the values that each condition can assume.
Name all possible actions that can occur.
List all possible rules.
Define the actions for each rule.
Simplify the table.
FIGURE 8-5 Reduced decision table for payroll system example
6. Deciding Among Structured English and Decision Tables

Criteria Structured English Decision Tables
Determining Conditions and Actions Second Best Third Best
Transforming Conditions and Actions into Best Third Best
Sequence
Checking Consistency and Completeness Third Best Best

7. Electronic Commerce Application: Logic Modeling

Pine Valley Furniture development methodology dictated that the logic within each
unique processes be represented.
Structured English was chosen for modeling the logic.
FIGURE 8-8 Level-0 DFD for the WebStore system
TABLE 8-5 Structured English Representations of Processes 4.0, 5.0, and 6.0 from
FIGURE 8-8
Process 4.0: Check Out Process Orders
READ Customer-ID
READ Check-Out
FIND Customer-Information from Customer-Tracking System
DO
READ Item-Profile
ADD Item-Profile to Order
UNTIL Shopping-Card is Empty
ADD Order to Purchasing-Fulfillment-System
READ Order-Number from Purchasing-Fulfillment-System
READ Return-Code from Purchasing-Fulfillment-System
DISPLAY Invoice
Process 5.0: Add/Modify Account Profile
READ Customer-Information
ADD Customer-Information to Customer-Tracking-System
DISPLAY Customer-Information
Process 6.0: Order Status Request
106 Logic Requirements Lecture 06b

READ Order-Number
FIND Order-Status-Information from Purchasing-Fulfillment-System
DISPLAY Order-Status-Information
Summary
Use Structured English as a tool for representing steps in logical processes in data flow
diagrams.
Select among Structured English and decision tables for representing processing logic.
Understand how logic modeling techniques apply to the development of electronic
commerce applications.

Tutorial 06
1. Answer TRUE or FALSE.
a. Logic modeling graphically represents the processes that capture, manipulate, store, and
distribute data between a system and its environment and among components within a
system.
FALSE (Process modeling) DFD Process modeling

Decision Tree Table Logic modeling
Structured English Logic modeling
ERD Data modeling
b. A primitive level data flow diagram is the first deliverable produced during requirements
structuring.
FALSE (last level of data flow diagram)
c. A data flow represents data in motion, moving from one place in the system to another.
TRUE
d. On a data flow diagram, a paycheck is represented as a data store.
FALSE (process)
e. Assume we have placed a data store between Process 5.1 and Process 5.5; we would say
that these processes are decoupled.
TRUE Decoupled separate relationship is weak

Coupled subsequent process
2. Does DFD provide an accurate representation of time/ timing in a particular system? Justify
your answer.
Context Diagram
One process
Data flow
Entities
No data store
Level 4 symbols
No, because in DFD didnt state the start time and end time.
108 Tutorial 06
3. Draw out the different symbols used in a Data Flow Diagram. Label them appropriately.
Process, Data Flow, Entities, Data Store
4. Using the example of a retail clothing store in a mall, list relevant data flows, data stores,
processes, and sources/sinks. Observe several sales transactions. Draw a context diagram and
a level-O diagram that represent the selling system at the, store. Explain why you chose
certain elements as processes versus sources/sinks.
5. What is balancing? State how you can determine if a DFD diagram is not balanced. What is
the importance of balancing a DFD?
Balancing is the concept where the number of Input / Output between 2 subsequent levels
have to be the same.
To make the DFD clearer, easy to understand and consistent.
6. What is process modeling? Identify three types of process models.
7. Identify the five basic procedures to follow when constructing a decision table.
(a) Condition
(b) Action
(c) Rules (can be derived based on condition)
(d) Decide on which action to be taken based on the rules
(e) Simplification of Decision Table
8. An individual wishes to withdraw cash from an ATM machine. Prepare a decision table to
represent this situation. Please note any assumptions that you make.
Simplify
Condition Rules Condition Rules
PIN Number Y Y Y N N N PIN Number Y Y Y N
Withdraw Amount < > = < > = Withdraw Amount < > =
Action Action
Take Card * * * * * * Take Card * * * *
Take Cash * Take Cash *
Print Receipt * Print Receipt *
Update Balance * Update Balance *
End Transaction * * * * * End Transaction * * *
Tutorial 06 109
FIGURE 7-20 Class Registration System for Problem
Context Diagram D1
Level-0 Diagram D2 change to D1
FIGURE 7-21 DFD for Problem
DF1 Should have process between 2 entities

DF5 Should have process between the entity and data store
P2 Should have output
DF2 Redundancies
110 Tutorial 06
FIGURE 7-22 DFD for Problem
DF6 The data flow from DS2 to P2 in Level 0 but the data flow from DS2 to P1.2 in Level 1
DF3 There are data flow from P1 to DS1 in Level 0 but there are no data flow from P1 to DS1
in Level 1
P1.4.2 Should have input
Tutorial 06 111
Lecture 07: Structuring System Data Requirements

Learning Objectives
Concisely define each of the following key data modeling terms: entity type, attribute,
multivalued attribute, relationship, degree, cardinality, business rule, associative entity,
trigger, supertype, subtype.
Draw an entity-relationship (E-R) diagram to represent common business situations.
Explain the role of conceptual data modeling in the overall analysis and design of an
information system.
Distinguish between unary, binary, and ternary relationships and give an example of each.
Define four basic types of business rules in a conceptual data model.
Relate data modeling to process and logic modeling as different views of describing an
information system.
1. Conceptual Data Modeling

Conceptual data modeling: a detailed model that captures the overall structure of data in
an organization
Independent of any database management system (DBMS) or other implementation
considerations
FIGURE 8-1 Systems development life cycle with analysis phase highlighted
2. The Conceptual Data Modeling Process

Develop a data model for the current system.
Develop a new conceptual data model that includes all 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.
112 Structuring System Data Requirements Lecture 07

3. Conceptual Data Modeling
FIGURE 8-2 Relationship between data modeling and the systems development life
cycle
4. Deliverables and Outcome

Primary deliverable is an entity-relationship (E-R) diagram or class diagram.
As many as 4 E-R or class diagrams are produced and analyzed:
E-R diagram that covers data needed in the projects application
E-R diagram for the application being replaced
E-R diagram for the whole database from which the new applications data are
extracted
E-R diagram for the whole database from which data for the application system being
replaced is drawn
FIGURE 8-3 Sample conceptual data model

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 included in the DFD must appear in the data model and vice versa
Each data store in a process model must relate to business objects represented in the
data model
5. Gathering Information for Conceptual Data Modeling

Two perspectives on data modeling:
Top-down approach for a data model is derived from an intimate understanding of the
business.
Bottom-up approach for a data model is derived by reviewing specifications and
business documents.
Requirements Determination Questions for Data Modeling:
What are subjects/objects of the business?
Data entities and descriptions
What unique characteristics distinguish between subjects/objects of the same type?
Primary keys
What characteristics describe each subject/object?
Attributes and secondary keys
How do you use the data?
Security controls and user access privileges
Over what period of time are you interested in the data?
Cardinality and time dimensions
6. Introduction to Entity-Relationship (E-R) Modeling

The E-R model is expressed in terms of:
Data entities in the business environment.
Relationships or associations among those entities.
Attributes or properties of both the entities and their relationships.
Entity: a person, place, object, event or concept in the user environment about which
data is to be maintained
Entity type: collection of entities that share common properties or characteristics
Entity instance: single occurrence of an entity type

FIGURE 8-5 Basic E-R notation
7. Naming and Defining Entity Types

An entity type name should be:
A singular noun.
Descriptive and specific to the organization.
Concise.
Event entity type should be named for the result of the event, not the activity or process
of the event.
An entity type definition should:
Include a statement of what the unique characteristic(s) is (are) for each instance.
Make clear what entity instances are included and not included in the entity type.
Often include a description of when an instance of the entity type is created or
deleted.
For some entity types the definition must specify:
When an instance might change into an instance of another entity type?
What history is to be kept about entity instances?
8. Attributes
Attribute: a named property or characteristic of an entity that is of interest to the
organization
Naming an attribute: i.e. Vehicle_ID
Place its name inside the rectangle for the associated entity in the E-R diagram.

9. Naming and Defining Attributes

An attribute name is a noun and should be unique.
To make an attribute name unique and for clarity, each attribute name should follow a
standard format.
Similar attributes of different entity types should use similar but distinguishing names.
An attribute definition:
States what the attribute is and possibly why it is important.
Should make it clear what is included and what is not included.
Contain any aliases or alternative names.
States the source of values for the attribute.
An attribute definition should indicate:
If a value for the attribute is required or optional.
If a value for the attribute may change.
Any relationships that attribute has with other attributes.
10. Other Attribute Types

Multivalued attribute: an attribute that may take on more than one value for each entity
instance
Repeating group: a set of two or more multivalued attributes that are logically related
FIGURE 8-8 Multivalued attributes and repeating groups
Required attribute: an attribute that must have a value for every entity instance
Optional attribute: an attribute that may not have a value for every entity instance
Composite attribute: an attribute that has meaningful component parts
Derived attribute: an attribute whose value can be computed from related attribute
values

FIGURE 8-11 Examples of relationships of different degrees
11. Relationships
Relationship: an association between the instances of one or more entity types that is of
interest to the organization
Degree: the number of entity types that participate in a relationship
12. Conceptual Data Modeling and the E-R Model

Unary relationship: a relationship between the instances of one entity type
Also called a recursive relationship
Binary relationship: a relationship between instances of two entity types
Most common type of relationship encountered in data modeling
Ternary relationship: a simultaneous relationship among instances of three entity types
13. Cardinalities in Relationships

Cardinality: the number of instances of entity B that can (or must) 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
Mandatory vs. Optional Cardinalities
Specifies whether an instance must exist or can be absent in the relationship.
FIGURE 8-14 Examples of cardinality constraints
14. Naming and Defining Relationships

A relationship name is a verb phrase; avoid vague names.
A relationship definition:
Explains what action is to be taken and possibly why it is important.
Gives examples to clarify the action.
A relationship definition should:
Explain any optional participation.
Explain the reason for any explicit maximum cardinality other than many.
Explain any restrictions on participation in the relationship.
Explain the extent of history that is kept in the relationship.
Explain whether an entity instance involved in a relationship instance can transfer
participation to another relationship instance.
15. Associative Entities

Associative Entity: an entity type that associates the instances of one or more entity
types and contains attributes that are peculiar to the relationship between those entity
instances
Sometimes called a gerund
The data modeler chooses to model the relationship as an entity type.

FIGURE 8-15 An associative entity
16. Summary of Conceptual Data Modeling with E-R Diagrams

The purpose of E-R diagramming is to capture the richest possible understanding of the
meaning of the data necessary for an information system or organization.
17. Representing Supertypes and Subtypes

Subtype: a subgrouping of the entities in an entity type
Is meaningful to the organization
Shares common attributes or relationships distinct from other subgroupings
Supertype: a generic entity type that has a relationship with one or more subtypes
Business Rules for Supertype / Subtype Relationships:
Total specialization specifies that each entity instance of the supertype must be a
member of some subtype in the relationship.
Partial specialization specifies that an entity instance of the supertype does not have
to belong to any subtype, and may or may not be an instance of one of the subtypes.
Disjoint rule specifies that if an entity instance of the supertype is a member of one
subtype, it cannot simultaneously be a member of any other subtype.
Overlap rule specifies that an entity instance can simultaneously be a member of two
(or more) subtypes.

FIGURE 8-19 Example of supertype/subtype hierarchy
18. Business Rules

Business rules: specifications that preserve the integrity of the logical data model
Captured during requirements determination
Stored in CASE repository as they are documented
Four basic types of business rules are:
Entity integrity: unique, non-null identifiers
Referential integrity constraints: rules governing relationships between entity types
Domains: constraints on valid values for attributes
Triggering operations: other business rules that protect the validity of attribute values
19. Domains
Domain: the set of all data types and values that an attribute can assume
Several advantages
Verify that the values for an attribute are valid
Ensure that various data manipulation operations are logical
Help conserve effort in describing attribute characteristics

20. Triggering Operations

Trigger: an assertion or rule that governs the validity of data manipulation operations
such as insert, update and delete
Includes the following components:
User rule: statement of the business rule to be enforced by the trigger
Event: data manipulation operation that initiates the operation
Entity Name: name of entity being accessed or modified
Condition: condition that causes the operation to be triggered
Action: action taken when the operation is triggered
21. Role of Packaged Conceptual Data Models Database Patterns

Packaged data models provide generic models that can be customized for a particular
organizations business rules.
Universal data models are templates for
one or more core subjects areas such as:
Customers, products, accounts, documents
and/or core business functions such as:
Purchasing, accounting, receiving, etc.
Industry-specific data models that are designed to be used by organizations within
specific industries.
These models are based on the premise that data model patterns for organizations are
similar within a particular industry.
22. Benefits of Database Patterns and Packaged Data Models

Dramatically reduced implementation times and costs
Provides a starting point for asking requirements questions.
Higher-quality models
Represents best practice data modeling techniques and data model components
whose quality often exceeds that which can be achieved by internal development
teams, given typical organizational pressures.
Summary
Concisely define each of the following key data modeling terms: entity type, attribute,
multivalued attribute, relationship, degree, cardinality, business rule, associative entity,
trigger, supertype, subtype.
Draw an entity-relationship (E-R) diagram to represent common business situations.
Explain the role of conceptual data modeling in the overall analysis and design of an
information system.
Distinguish between unary, binary, and ternary relationships and give an example of each.
Define four basic types of business rules in a conceptual data model.
Relate data modeling to process and logic modeling as different views of describing an
information system.

Tutorial 07
1. Match each of the key terms below with the definition that best fits it:
Triggering operation (trigger), Entity-relationship data model (E-R model), Associative

entity, Partial specialization rule, Disjoint rule, Candidate key, Identifier, Multivalued
attribute, Entity-relationship diagram (E-R diagram), Conceptual data model.
a. A detailed model that captures the overall structure of organizational data while being
independent of any database management system or other implementation considerations.
Conceptual Data Model
b. A detailed, logical representation of the entities, associations, and data elements for an
organization or business area.
Entity-Relationship Data Model (E-R Model)
c. A graphical representation of an E-R model.
Entity-Relationship Diagram (E-R Diagram)
d. An attribute (or combination of attributes) that uniquely identifies each instance of an

entity type.
Candidate Key
e. A candidate key that has been selected as the unique, identifying characteristic for an
entity type.
Identifier
f. An attribute that may take on more than one value for each entity instance.
Multivalued Attribute
g. An entity type that associates the instances of one or more entity types and contains
attributes that are peculiar to the relationship between those entity Instances.
Associative Entity
122 Tutorial 07
h. Specifies that each entity instance of the super-type must be a member of some subtype in
the relationship. Specifies that an entity instance of the super-type is allowed not to
belong to any subtype.
Partial Specialization Rule
i. Specifies that if an entity instance of the super-type is a member of one subtype, it cannot
simultaneously be a member of any other subtype.
Total Specialization Rule / Disjoint Rule
j. An assertion or rule that governs the validity of data manipulation operations such as
insert, update, and delete.
Triggering Operation (Trigger)
2. Define the following key data modeling terms: entity, attribute, relationship, degree,
cardinality, and associative entity.
3. Contrast data modeling to process modeling and logic modeling.
Process Modeling
Process that captured, distributed and data stored within the system and its environment
Data Modeling
Data and relationship within data in the system
Logic Modeling
Internal representation of a process
4. Contrast the following terms:

a. subtype; super-type
b. total specialization rule; partial specialization rule
c. disjoint rule; overlap rule
5. Discuss unary, binary, and ternary relationships. Provide an example of each.
Tutorial 07 123
Lecture 08: Designing Databases

Learning Objectives
Concisely define each of the following key database design terms: relation, primary key,
normalization, functional dependency, foreign key, referential integrity, field, data type, null
value, denormalization, file organization, index, and secondary key.
Explain the role of designing databases in the analysis and design of an information system.
Transform an entity-relationship (E-R) diagram into an equivalent set of well-structured
(normalized) relations.
Merge normalized relations from separate user views into a consolidated set of well-
structured relations.
Choose storage formats for fields in database tables.
Translate well-structured relations into efficient database tables.
Explain when to use different types of file organizations to store computer files.
Describe the purpose of indexes and the important considerations in selecting attributes to be
indexed.
1. Introduction
FIGURE 9-1 Systems development life cycle with design phase highlighted
124 Designing Databases Lecture 08

2. Database Design
File and database design occurs in two steps.
a. Develop a logical database model, which describes data using notation that
corresponds to a data organization used by a database management system.
Relational database model
b. Prescribe the technical specifications for computer files and databases in which to
store the data.
Physical database design provides specifications
Logical and physical database design in parallel with other system design steps
FIGURE 9-2 Relationship between data modeling and the systems development life
cycle
3. The Process of Database Design

Four key steps in logical database modeling and design:
a. Develop a logical data model for each known user interface for the application using
normalization principles.
b. Combine normalized data requirements from all user interfaces into one consolidated
logical database model (view integration).
c. Translate the conceptual E-R data model for the application into normalized data
requirements.
d. Compare the consolidated logical database design with the translated E-R model and
produce one final logical database model for the application.

4. Physical Database Design

Key physical database design decisions include:
Choosing a storage format for each attribute from the logical database model.
Grouping attributes from the logical database model into physical records.
Arranging related records in secondary memory (hard disks and magnetic tapes) so
that records can be stored, retrieved and updated rapidly.
Selecting media and structures for storing data to make access more efficient.

Logical database design
Must account for every data element on a system input or output.
Normalized relations are the primary deliverable.
Physical database design
Converts relations into database tables.
Programmers and database analysts code the definitions of the database.
Written in Structured Query Language (SQL).
FIGURE 9-3 (d) Conceptual data model and transformed relations

6. Relational Database Model

Relational database model: data represented as a set of related tables or relations
Relation: a named, two-dimensional table of data; each relation consists of a set of
named columns and an arbitrary number of unnamed rows
Relations have several properties that distinguish them from nonrelational tables:
Entries in cells are simple.
Entries in columns are from the same set of values.
Each row is unique.
The sequence of columns can be interchanged without changing the meaning or use
of the relation.
The rows may be interchanged or stored in any sequence.
7. Well-Structured Relation and Primary Keys

Well-Structured Relation (or table)
A relation that contains a minimum amount of redundancy
Allows users to insert, modify, and delete the rows without errors or inconsistencies
Primary Key
An attribute whose value is unique across all occurrences of a relation
All relations have a primary key.
This is how rows are ensured to be unique.
A primary key may involve a single attribute or be composed of multiple attributes.
8. Normalization and Rules of Normalization

Normalization: the process of converting complex data structures into simple, stable data
structures
The result of normalization is that every nonprimary key attribute depends upon the
whole primary key.
First Normal From (1NF)
Unique rows, no multivalued attributes
All relations are in 1NF
Second Normal Form (2NF)
Each nonprimary key attribute is identified by the whole key (called full functional
dependency)
Third Normal Form (3NF)
Nonprimary key attributes do not depend on each other (i.e. no transitive
dependencies)

9. Functional Dependencies and Primary Keys

Functional Dependency: a particular relationship between two attributes
For a given relation, attribute B is functionally dependent on attribute A if, for every
valid value of A, that value of A uniquely determines the value of B.
The functional dependence of B on A is represented by AB.
Functional dependency is not a mathematical dependency.
Instances (or sample data) in a relation do not prove the existence of a functional
dependency.
Knowledge of problem domain is most reliable method for identifying functional
dependency.
10. Second Normal Form (2NF)

A relation is in second normal form (2NF) if any of the following conditions apply:
The primary key consists of only one attribute.
No nonprimary key attributes exist in the relation.
Every nonprimary key attribute is functionally dependent on the full set of primary
key attributes.
To convert a relation into 2NF, you decompose the relation into new relations using the
attributes, called determinants, that determine other attributes.
The determinants are the primary key of the new relation.
11. Third Normal Form (3NF)

A relation is in third normal form (3NF) if it is in second normal form (2NF) and there
are no functional (transitive) dependencies between two (or more) nonprimary key
attributes.
(a) Relation with transitive dependency
(b) Relation in 3NF

FIGURE 9-9 Removing transitive dependencies
Foreign Key: an attribute that appears as a nonprimary key attribute in one relation and
as a primary key attribute (or part of a primary key) in another relation
Referential Integrity: an integrity constraint specifying that the value (or existence) of
an attribute in one relation depends on the value (or existence) of the same attribute in
another relation
12. Transforming E-R Diagrams into Relations

It is useful to transform the conceptual data model into a set of normalized relations.
Steps
Represent entities.
Represent relationships.
Normalize the relations.
Merge the relations.
13. Representing Entities

Each regular entity is transformed into a relation.
The identifier of the entity type becomes the primary key of the corresponding relation.
The primary key must satisfy the following two conditions.
The value of the key must uniquely identify every row in the relation.
The key should be nonredundant.
The entity type label is translated into a relation name.
14. Binary 1:N and 1:1 Relationships

The procedure for representing relationships depends on both the degree of the
relationship unary, binary, ternary and the cardinalities of the relationship.
Binary 1:N Relationship is represented by adding the primary key attribute (or
attributes) of the entity on the one side of the relationship as a foreign key in the relation
that is on the many side of the relationship.
Binary or Unary 1:1 Relationship is represented by any of the following choices:
Add the primary key of A as a foreign key of B.
Add the primary key of B as a foreign key of A.
Both of the above.

(a) E-R diagram
(b) Relations
FIGURE 9-11 Representing a 1:N relationship
15. Binary and Higher-Degree M:N Relationships

Create another relation and include primary keys of all relations as primary key of new
relation
(a) E-R diagram
(b) Relations

FIGURE 9-12 Representing an M:N relationship
16. Unary Relationships

Unary 1:N Relationship
Is modeled as a relation
Primary key of that relation is the same as for the entity type
Foreign key is added to the relation that references the primary key values
Recursive foreign key: a foreign key in a relation that references the primary key values
of that same relation
Unary M:N Relationship
Is modeled as one relation
Create a separate relation the represent the M:N relationship
Primary key of new relation is a composite key of two attributes that both take their
values from the same primary key
Any attribute associated with the relationship is included as a nonkey attribute in this
new relation
(a) EMPLOYEE with Manages relationship (1:N)
(b) Bill-of-materials structure (M:N)

FIGURE 9-13 Two unary relationships
17. Merging Relations

Purpose is to remove redundant relations
The last step in logical database design
Prior to physical file and database design
18. View Integration Problems

Must understand the meaning of the data and be prepared to resolve any problems that
arise in the process
Synonyms: two different names used for the same attribute
When merging, get agreement from users on a single, standard name
Homonyms: a single attribute name that is used for two or more different attributes.
Resolved by creating a new name
Dependencies between nonkeys dependencies may be created as a result of view
integration
To resolve, the new relation must be normalized
Class / Subclass relationships may be hidden in user views or relations
Resolved by creating a new name

FIGURE 9-16 Class diagram corresponding to normalized relations of Hoosier Burgers

inventory control system
19. Relations for Hoosier Burger
20. Physical File and Database Design

The following information is required:
Normalized relations, including volume estimates
Definitions of each attribute
Descriptions of where and when data are used, entered, retrieved, deleted, and
updated (including frequencies)
Expectations or requirements for response time and data integrity
Descriptions of the technologies used for implementing the files and database
21. Designing Fields

Field: the smallest unit of named application data recognized by system software
Attributes from relations will be represented as fields
Data Type: a coding scheme recognized by system software for representing
organizational data
22. Choosing Data Types

Selecting a data type balances four objectives:
Minimize storage space.
Represent all possible values of the field.
Improve data integrity of the field.
Support all data manipulations desired on the field.
TABLE 9-2 Commonly Used Data Types in Oracle 10i

Data Type Description
VARCHAR2 Variable-length character data with a maximum length of 4,000 characters;
you must enter a maximum field length (e.g., VARCHAR2(30) for a field
with a maximum length of 30 characters). A value less than 30 characters
will consume only the required space.
CHAR Fixed-length character data with a maximum length of 255 characters;

default length is 1 character (e.g., CHAR(5) for a field with a fixed length
of 5 characters, capable of holding a value from 0 to 5 characters long).
LONG Capable of storing up to two gigabytes of one variable-length character
data field (e.g., to hold a medical instruction or a customer comment).
NUMBER Positive and negative numbers in the range 10-130 to 10126; can specify the
precision (total number of digits to the left and right of the decimal point)
and the scale (the number of digits to the left and right of the decimal
point) (e.g., NUMBER(5) specifies an integer field with a maximum of 5
digits and NUMBER(5, 2) specifies a field with no more than five digits
and exactly two digits to the right of the decimal point).
DATE Any date from January 1, 4712 B.C. to December 31, 4712 A.D.; date
stores the century, year, month, day, hour, minute and second.
BLOB Binary large object, capable of storing up to four gigabytes of binary data
(e.g., a photograph or sound clip).
23. Calculated Fields

Calculated (or computed or derived) field: a field that can be derived from other
database fields
It is common for an attribute to be mathematically related to other data.
The calculate value is either stored or computed when it is requested.
24. Controlling Data Integrity

Default Value: a value a field will assume unless an explicit value is entered for that field
Range Control: limits range of values that can be entered into field
Both numeric and alphanumeric data
Referential Integrity: an integrity constraint specifying that the value (or existence) of
an attribute in one relation depends on the value (or existence) of the same attribute in
another relation
Null Value: a special field value, distinct from zero, blank, or any other value, that
indicates that the value for the field is missing or otherwise unknown
25. Designing Physical Tables

Relational database is a set of related tables.
Physical Table: a named set of rows and columns that specifies the fields in each row of
the table
Denormalization: the process of splitting or combining normalized relations into
physical tables based on affinity of use of rows and fields
Denormalization optimizes certain data processing activities at the expense of others.
Three types of table partitioning:
Range partitioning: partitions are defined by nonoverlapping ranges of values for a
specified attribute

Hash partitioning: a table row is assigned to a partition by an algorithm and then

maps the specified attribute value to a partition
Composite partitioning: combines range and hash partitioning by first segregating
data by ranges on the designated attribute, and then within each of these partitions
Various forms of denormalization, which involves combining data from several
normalized tables, can be done.
No hard-and-fast rules for deciding
Three common situations where denormalization may be used:
Two entities with a one-to-one relationship
A many-to-many relationship (associative entity) with nonkey attributes
Reference data
26. File Organizations

File organization: a technique for physically arranging the records of a file
Physical file: a named set of table rows stored in a contiguous section of secondary
memory
TABLE 9-3 Comparative Features of Sequential, Indexed and Hashed File

Organizations
File Organization
Factor Sequential Indexed Hashed
Storage space No wasted No wasted space for data, Extra space may be
space but extra space for index needed to allow for
addition and deletion
of records
Sequential retrieval Very fast Moderately fast Impractical
on primary key
Random retrieval Impractical Moderately fast Very fast
on primary key
Multiple key Possible, but Very fast with multiple Not possible
retrieval requires indexes
scanning
whole file
Deleting rows Can create If space can be Very easy
wasted space dynamically allocated,
or require this is easy, but requires

reorganizing maintenance of indexes

Adding rows Requires If space can be Very easy, except
rewriting file dynamically allocated, multiple keys with
this is easy, but requires same address require
maintenance of indexes extra work
Updating rows Usually Easy, but requires Very easy
requires maintenance of indexes
rewriting file
Sequential file organization: a file organization in which rows in a file are stored in
sequence according to a primary key value
Hashed file organization: a file organization in which the address for each row is
determined using an algorithm
Pointer: a field of data that can be used to locate a related field or row of data
27. Arranging Table Rows

Objectives for choosing file organization
Fast data retrieval
High throughput for processing transactions
Efficient use of storage space
Protection from failures or data loss
Minimizing need for reorganization
Accommodating growth
Security from unauthorized use
28. Indexed File Organization

Indexed file organization: a file organization in which rows are stored either
sequentially or nonsequentially, and an index is created that allows software to locate
individual rows
Index: a table used to determine the location of rows in a file that satisfy some condition
Secondary keys: one or a combination of fields for which more than one row may have
the same combination of values
Main disadvantages:
Extra space required to store the indexes
Extra time necessary to access and maintain indexes
Main advantage:
Allows for both random and sequential processing

Guidelines for choosing indexes

Specify a unique index for the primary key of each table.
Specify an index for foreign keys.
Specify an index for nonkey fields that are referenced in qualification, sorting and
grouping commands for the purpose of retrieving data.
29. Designing Controls for Files

Two of the goals of physical table design are protection from failure or data loss and
security from unauthorized use.
These goals are achieved primarily by implementing controls on each file.
Two other important types of controls address file backup and security.
Techniques for file restoration include:
Periodically making a backup copy of a file.
Storing a copy of each change to a file in a transaction log or audit trail.
Storing a copy of each row before or after it is changed.
Means of building data security into a file include:
Coding, or encrypting, the data in the file.
Requiring data file users to identify themselves by entering user names and
passwords.
Prohibiting users from directly manipulating any data in the file by forcing users to
work with a copy (real or virtual).
Summary
Concisely define each of the following key database design terms: relation, primary key,
normalization, functional dependency, foreign key, referential integrity, field, data type,
null value, denormalization, file organization, index, and secondary key.
Explain the role of designing databases in the analysis and design of an information
system.
Transform an entity-relationship (E-R) diagram into an equivalent set of well-structured
(normalized) relations.
Merge normalized relations from separate user views into a consolidated set of well-
structured relations.
Choose storage formats for fields in database tables.
Translate well-structured relations into efficient database tables.
Explain when to use different types of file organizations to store computer files.
Describe the purpose of indexes and the important considerations in selecting attributes to
be indexed.

Tutorial 08
1. Match each of the key terms below with the definition that best fits it:
Well-structured relations or table, Second normal form (2NF), Referential integrity,

Relation, Denormalization, Secondary key, Normalization, Third normal form (3NF),
Primary key, Data type.
a. A named, two-dimensional table of data.
Relation
b. The process of converting complex data structures into simple, stable data structures.
Normalization
c. A Relation that contains a minimum amount of redundancy and allows users to insert,
modify, and delete the rows without errors or inconsistencies.
Well-structured Relations or Table
d. A relation for which every non-primary key attribute is functionally dependent on the
whole primary key.
Second Normal Form (2NF)
e. A relation that is in second normal form and that has no functional (transitive)
dependencies between two (or more) non-primary key attributes.
Third Normal Form (3NF)
f. An integrity constraint specifying that the value (or existence) of an attribute in one
relation depends on the value (or existence) of the same attribute in another relation.
Referential Integrity
g. A coding scheme recognized by system software for representing organizational data.
Data Type
h. The process of splitting or combining normalized relations into physical tables based on
affinity of use of rows and fields.
Denormalization
138 Tutorial 08
i. One or a combination of fields for which more than one row may have the same
combination of values.
Secondary Key
j. An attribute whose value is unique across all occurrences of a relation.
Primary Key
2. Answer TRUE or FALSE

a. Generally speaking, a physical table corresponds to a relation.
FALSE
b. Denormalization reduces the chance of errors introduced by normalizing relations.
FALSE (speed up the process power)
c. When using the sequential file organization, the addition of rows requires rewriting the
file.
TRUE
d. Data security can be built into a file through encryption, passwords, or prohibiting users
from directly manipulating a file.
TRUE
e. Designing the database for an Internet-based electronic commerce application differs

significantly from the process followed when designing the database for other types of
applications.
TRUE
Tutorial 08 139
3. Transform the E-R diagram of Figure 10.21 into a set of 3NF relations.
Vendor (Vendor_ID, Address)

Price_Quote (Quote_Quantity, Price, Vendor_ID, Item_Number)
PART (Item_Number, Description)
PART_RECEIPT (Order_Number, Date, Order_Quantity, Quote_Quantity, Vendor_ID,
Item_Number)
4. What are the goals of designing physical tables?
Efficiently use of storage (normalization reduce the redundancy)

Retrieval method (file organization sequential / index / hash / )
5. Contrast between normalization and Denormalization.
Normalization process of splitting / converting complex data structures into a simple and
stable relations
Denormalization combine two / more relations
Data in one relation always being referenced / combined when another
relation is being called
140 Tutorial 08
6. Discuss the factors that should be considered in selecting a file organisation.
Fast data retrieval

High throughput for processing transactions
Efficient use of storage space
Protection from failures or data loss
Minimizing need for reorganization
Accommodating growth
Security from unauthorized use
7. How is a binary one-to-one relationship represented?
8. What are the four key physical database design decisions you will make?
Data Types (attributes) Input

Data Structures (relations / records) Input
File Organization Output
Media (hardware / server / cloud) Storage
Tutorial 08 141
Lecture 09: Designing Forms and Reports

Learning Objectives
Explain the process of designing forms and reports and the deliverables for their creation.
Apply the general guidelines for formatting forms and reports.
Use color and know when color improves the usability of information.
Format text, tables, and lists effectively.
Explain how to assess usability and describe how variations in users, tasks, technology, and
environmental characteristics influence the usability of forms and reports.
Discuss guidelines for the design of forms and reports for Internet-based electronic
commerce systems.
1. Designing Forms and Reports
FIGURE 10-1 Systems development life cycle with logical design phase highlighted
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
It is a passive document used solely for reading or viewing data.
A report typically contains data from many unrelated records or transactions.
Common Types of Reports:
Scheduled: produced at predefined time intervals for routine information needs
Key-indicator: provides summary of critical information on regular basis
Exception: highlights data outside of normal operating ranges
Drill-down: provides details behind summary of key-indicator or exception reports
Ad-hoc: responds to unplanned requests for non-routine information needs
142 Designing Forms and Reports Lecture 09

2. The Process of Designing Forms and Reports

Is user-focused activity.
Follows a prototyping approach.
First steps are to gain an understanding of the intended user and task objectives by
collecting initial requirements during requirements determination.
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?
Prototyping
Initial prototype is designed from requirements.
Users review prototype design and either accept the design or request changes.
If changes are requested, the construction-evaluation-refinement cycle is repeated
until the design is accepted.
A coding sheet is an old tool for designing forms and reports, usually associated with
text-based forms and reports for mainframe applications.
Visual Basic and other development tools provide computer aided GUI form and report
generation.
FIGURE 10-2 The layout of a data input form using a coding sheet

FIGURE 10-3 A data input screen designed in Microsofts Visual Basic .NET

Design specifications are the major deliverables and inputs to the system implementation
phase.
Design specifications have three sections:
Narrative overview: characterizes users, tasks, system, and environmental factors
Sample design: image of the form (from coding sheet or form building development
tool)
Testing and usability assessment: measuring test/usability results (consistency,
sufficiency, accuracy, etc.)
4. Formatting Forms and Reports

Meaningful titles use clear, specific, version information, and current date
Meaningful information include only necessary information, with no need to modify
Balanced layout use adequate spacing, margins, and clear labels
Easy navigation system show how to move forward and backward, and where you are
currently

(a) Poorly designed form
(b) Improved design for form
FIGURE 10-5 Contrasting customer information forms (Pine Valley Furniture)

5. Highlighting Information
Notify users of errors in data entry or processing.
Provide warnings regarding possible problems.
Draw attention to keywords, commands, high-priority messages, unusual data values.
Highlighting can include use of
upper case all capital letters
bold blinking
italics reverse video
underlining audible tones
boxing intensity differences
size and color differences offsetting nonstandard information
FIGURE 10-6 Customer account status display using various highlighting techniques
(Pine Valley Furniture)
6. Color vs. No Color

Benefits of Using Color
Soothes or strikes the eye.
Accents an uninteresting display.
Facilitates subtle discriminations in complex displays.
Emphasizes the logical organization of information.
Draws attention to warnings.
Evokes more emotional reactions.
Problems from Using Color
Color pairings may wash out or cause problems for some users.
Resolution may degrade with different displays.
Color fidelity may degrade on different displays.
Printing or conversion to other media may not easily translate.

7. Displaying Text
Case: mixed upper and lower case, use conventional punctuation
Spacing: double spacing if possible, otherwise blank lines between paragraphs
Justification: left justify text, ragged right margins
Hyphenation: no hyphenated words between lines
Abbreviations: only when widely understood and significantly shorter than full text
(a) Poorly designed help screen with many violations of the general guidelines for displaying
text
(b) An improved design for a help screen

FIGURE 10-7 Contrasting the display of textual help information
8. Designing 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.
Formatting columns, rows and text:
Sort in a meaningful order.
Place a blank line between every five 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.
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.
(a) Poorly designed form
FIGURE 10-8 Contrasting the display of tables and lists (Pine Valley Furniture)

(a) Line graph
(b) Bar graph
FIGURE 10-10 Graphs for comparison
9. Assessing Usability
Objective for designing forms, reports and all human-computer interactions is usability.
There are three characteristics:
Speed Can you complete a task efficiently?
Accuracy Does the output provide what you expect?
Satisfaction Do you like using the output?
Usability: an overall evaluation of how a system performs in supporting a particular user
for a particular task.
10. Usability Success Factors

Consistency of terminology, formatting, titles, navigation, response time
Efficiency minimize required user actions.
Ease self-explanatory outputs and labels.
Format appropriate display of data and symbols.
Flexibility maximize user options for data input according to preference.
Characteristics for consideration:
User: experience, skills, motivation, education, personality
Task: time pressure, cost of errors, work durations
System: platform

Environment: social and physical issues
11. Measures of Usability

Time to learn
Speed of performance
Rate of errors
Retention over time
Subjective satisfaction
Layout of information should be consistent, both within and across applications, whether
information is delivered on screen display or on a hard-copy report.
Summary
Explain the process of designing forms and reports and the deliverables for their creation.
Apply the general guidelines for formatting forms and reports.
Use color and know when color improves the usability of information.
Format text, tables, and lists effectively.
Explain how to assess usability and describe how variations in users, tasks, technology,
and environmental characteristics influence the usability of forms and reports.
Discuss guidelines for the design of forms and reports for Internet-based electronic
commerce systems.
Identify the mistakes

Correction
Comment on Windows Apps.
Comment on Web apps.

Problem
1) In general, forms are used to present or collect information on a single item.
TRUE
2) The contents of a form or report correspond to the data elements contained in an associated
data flow located on a data flow diagram.
TRUE
3) The data on all forms and reports must consist of data elements in data stores and on the E-R
data model for the application or must be computed from these data elements.
TRUE
4) Invoices and mailing labels are examples of forms.
FALSE
5) On the Internet, form interaction is the standard method of gathering and displaying
information when consumers order products, request product information, or query account
status.
TRUE

Tutorial 09
1. What is usability? Based on guidelines for usability of forms and reports, investigate the
usability of the design for reports that you are going to design for a web site.
Usability overall evaluation of how the system performs towards a specific user / task
Based on a set of criteria

a) Consistency
b) Efficiency
c) Ease
d) Format
e) Flexibility
2. Identify nine common errors that occur when designing the layout of Web pages.
a) Poor layout design

Text is not being aligned
b) Not user friendly interface
Long text
Placement of buttons / icons not consistent
Calculation errors
Colours
Hyperlinks / links not consistent
Too many advertisements
Downloading is slow
Outdated information
3. Differentiate between a form and a report.
Form Enter raw data

Data collection
View your data
Report Processed analyzed data

Provide information / summary
Passive
View
Table
Graph
4. Identify four problems of using color.
Tutorial 09 153
5. As a Website designer, how can you avoid errors caused by links that do not provide enough
information?
Links that do not provide enough info

Hyperlinks Name is not clear
Find a suitable name to describe the link
Change the colour black and white
- Clicked on the hyperlink
- Not clicked on the hyperlink
Images / icons
Hyperlink
- Different tab in the same browser
- Different browser
How to make better?

Search button
6. As a Website designer, how can you avoid errors caused by hidden links?
Hidden link
Phishing website false advertisement
White text on the white background
Dont put hidden link

Put the hidden link into the box
Change the colour default colour
Try not to include link in the long text / put in blocks of text
7. Identify ten validation tests and techniques used to enhance the validity of data input.
8. When should you use tables? When should you use graphs?
Tables Represent detail data / individual data
Graphs Summarized data

Pattern / trend against the time
Comparison
154 Tutorial 09
Lecture 10: Designing Interfaces and Dialogues

Learning Objectives
Explain the process of designing interfaces and dialogues and the deliverables for their
creation.
Contrast and apply several methods for interacting with a system.
List and describe various input devices and discuss usability issues for each in relation to
performing different tasks.
Describe and apply the general guidelines for designing interfaces and specific guidelines for
layout design, structuring data entry fields, providing feedback, and system help.
Design human-computer dialogues and understand how dialogue diagramming can be used
to design dialogues.
Design graphical user interfaces.
Discuss guidelines for the design of interfaces and dialogues for Internet-based electronic
commerce systems.
Describe internet and distributed system.
1. Designing Interfaces and Dialogues

User-focused activity
Prototyping methodology of iteratively:
Collecting information
Constructing a prototype
Assessing usability
Making refinements
Must answer the who, what, where, and how questions
FIGURE 11-1 Systems development life cycle (SDLC)


Creation of a design specification
A typical interface/dialogue design specification is similar to form design, but
includes multiple forms and dialogue sequence specifications.
The specification includes:
Narrative overview
Sample design
Testing and usability assessment
Dialogue sequence
Dialogue sequence is the ways a user can move from one display to another.
3. Interaction Methods and Devices

Interface: a method by which users interact with an information system
All human-computer interfaces must:
have an interaction style, and
use some hardware device(s) for supporting this interaction.
4. Methods of Interacting
Command line
Includes keyboard shortcuts and function keys
Menu
Form
Object-based
Natural language
5. Command Language Interaction

Command language interaction: a human-computer interaction method whereby users
enter explicit statements into a system to invoke operations
Example from MS DOS:
COPY C:PAPER.DOC A:PAPER.DOC
Command copies a file from C: drive to A: drive
156 Designing Interfaces and Dialogues Lecture 10

6. Menu Interaction
Menu interaction: a human-computer interaction method in which a list of system
options is provided and a specific command is invoked by user selection of a menu
option
Pop-up menu: a menu-positioning method that places a menu near the current cursor
position
Drop-down menu is a menu-positioning method that places the access point of the menu
near the top line of the display.
When accessed, menus open by dropping down onto the display.
Visual editing tools help designers construct menus.
Guidelines for Menu Design
Wording meaningful titles, clear command verbs, mixed upper/lower case
Organization consistent organizing principle
Length all choices fit within screen length
Selection consistent, clear and easy selection methods
Highlighting only for selected options or unavailable options
FIGURE 11-8 Menu building with Microsoft Visual Basic .NET

7. Form Interaction
Form interaction: a highly intuitive human-computer interaction method whereby data
fields are formatted in a manner similar to paper-based forms
Allows users to fill in the blanks when working with a system.
FIGURE 11-9 Example of form interaction from the Google Advanced Search Engine

8. Object-Based Interaction
Object-based interaction: a human-computer interaction method in which symbols are
used to represent commands or functions
Icons: graphical pictures that represent specific functions within a system
Use little screen space and are easily understood by users
FIGURE 11-10 Object-based (icon) interface from Microsoft Visual Basic .NET
9. Natural Language Interaction

Natural language interaction: a human-computer interaction method whereby inputs to
and outputs from a computer-based application are in a conventional spoken language
such as English
Based on research in artificial intelligence.
Current implementations are tedious and difficult to work with, not as viable as other
interaction methods.

10. Usability Problems with Hardware Devices

Visual Blocking
touch screen, light pen
User Fatigue
touch screen, light pen
Movement Scaling
keyboard, mouse, joystick, trackball, graphics tablet, voice
Durability
trackball, touch screen
Adequate Feedback
keyboard, mouse, joystick, trackball, graphics tablet, voice
Speed
keyboard
Pointing Accuracy
joystick, touch screen, light pen, voice
TABLE 11-4 Summary of General Conclusions from Experimental Comparisons of

Input Devices in Relation to Specific Task Activities
Task Most Accurate Shortest Positioning Most Preferred
Target trackball, graphics touch screen, light pen, touch screen, light pen
Selection tablet, mouse, mouse, graphics tablet,
joystick trackball
Text Selection mouse mouse
Data Entry light pen light pen
Cursor light pen
Positioning
Text light pen, cursor keys light pen light pen
Correction
Menu touch screen keyboard, touch screen
Selection
Key:
Target Selection = moving the cursor to select a figure or item
Text Selection = moving the cursor to select a block of text
Data Entry = entering information of any type into a system
Cursor Positioning = moving the cursor to a specific position
Text Correction = moving the cursor to a location to make a text correction
Menu Selection = activating a menu item
= no clear conclusion from the research

11. Designing Interfaces

Forms have several general areas in common :
Header information
Sequence and time-related information
Instruction or formatting information
Body or data details
Totals or data summary
Authorization or signatures
Comments
Use standard formats similar to paper-based forms and reports.
Use left-to-right, top-to-bottom navigation.
Flexibility and consistency:
Free movement between fields
No permanent data storage until the user requests
Each key and command assigned to one function
12. 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
Replacemen Use character replacement when appropriate
t
Captioning Always place a caption adjacent to fields
Format Provide formatting examples
Justify Automatically justify data entries
Help Provides context-sensitive help when appropriate
13. Controlling Data Input

Objective: Reduce data entry errors
Common sources data entry errors in a field:
Appending: adding additional characters
Truncating: losing characters
Transcripting: entering invalid data
Transposing: reversing sequence of characters
14. Providing Feedback

Three types of system feedback:

Status information: keep user informed of whats going on, helpful when user has to
wait for response
Prompting cues: tell user when input is needed, and how to provide the input
Error or warning messages: inform user that something is wrong, either with data
entry or system operation
15. Providing Help

Place yourself in users place when designing help.
Guidelines for designing usable help:
Simplicity Help messages should be short and to the point.
Organize Information in help messages should be easily absorbed by users.
Show It is useful to explicitly show users how to perform an operation.
16. Designing Dialogues

Dialogues: the sequence of interaction between a user and a system
Dialogue design involves:
Designing a dialogue sequence.
Building a prototype.
Assessing usability.
17. Designing the Dialogue Sequence

Typical dialogue between user and Customer Information System:
Request to view individual customer information.
Specify the customer of interest.
Select the year-to-date transaction summary display.
Review the customer information.
Leave system.
Dialogue diagramming: a formal method for designing and representing human-
computer dialogues using box and line diagrams
Three sections of the box are used as:
Top contains a unique display reference number used by other displays for
referencing it.
Middle contains the name or description of the display.
Bottom contains display reference numbers that can be accessed from the current
display.

FIGURE 11-17 Sections of a dialogue diagramming box
Dialogue diagrams depict the sequence, conditional branching, and repetition of

dialogues.
FIGURE 11-18 Dialogue diagram illustrating sequence, selection, and iteration
18. Example of Dialogue Sequence

19. Building Prototypes and Assessing Usability

Optional activities
Building prototypes displays using a graphical development environment
Microsofts Visual Studio .NET
Borlands Enterprise Studio
Easy-to-use input and output (form, report, or window) design utilities
20. Graphical Interface Design Issues

Become an expert user of the GUI environment.
Understand how other applications have been designed.
Understand standards.
Gain an understanding of the available resources and how they can be used.
Become familiar with standards for menus and forms.

FIGURE 11-20 Highlighting graphical user interface design standards
21. Designing Distributed and Internet Systems

FIGURE 12-1 Systems development life cycle (SDLC)
FIGURE 12-3 File server model
FIGURE 12-8 Thin clients used to access the Internet

FIGURE 12-9 Thin clients typically have a limited screen size
FIGURE 12-11 Combining XML data with XSL style sheet to format content
FIGURE 12-18 Generic two-tier data warehouse architecture

FIGURE 12-19 Three-tier warehouse architecture
Summary
Explain the process of designing interfaces and dialogues and the deliverables for their
creation.
Contrast and apply several methods for interacting with a system.
List and describe various input devices and discuss usability issues for each in relation to
performing different tasks.
Describe and apply the general guidelines for designing interfaces and specific guidelines
for layout design, structuring data entry fields, providing feedback, and system help.
Design human-computer dialogues and understand how dialogue diagramming can be
used to design dialogues.
Design graphical user interfaces.
Discuss guidelines for the design of interfaces and dialogues for Internet-based electronic
commerce systems.
Describe internet and distributed system.

Tutorial 10
1. Answer TRUE or FALSE
a. Interface design focuses on how information is provided to and captured from users.
TRUE
b. Command language interaction refers to a human-computer interaction method where a

list of system options is provided and a specific command is invoked by user selection of
a menu option.
FALSE (Menu)
c. One guideline for menu design is making sure that command verbs clearly and
specifically describe operations.
TRUE
d. The selection of devices users will use for interaction is made during implementation.
FALSE (design stage)
e. When using a mouse, usability problems may occur in the areas of movement scaling and
adequate feedback.
TRUE
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?
Process
(a) Get / know user requirements
Aim of each interface / dialogue
What are the data to be captured
Flow
Target user
(b) Start designing
Could start interface
A series of interface dialogue
(c) User feedback
Deliverable prototype
Is it the same for all types of system projects? No
Tutorial 10 169
3. Briefly identify and define the five most widely used interaction methods.
(a) Natural Language

(b) Menu
(c) Object Symbol
(d) Form
(e) Command Predefined list / verbs to invoke an operation
4. Identify four sources of data errors.
5. Identify the eight guideline categories for the design of human-computer dialogues.
(a) Consistent
(b) Clear information (user knows exactly what to do)
Feedback
Where are you right now? (page)
Easy navigation
(c) Presentation layout (bold, highlighting)
6. Identify nine common errors that might occur when designing the interface and dialogues of
Web sites.
170 Tutorial 10
7. Prepare a dialogue diagram for an ATM machine.

0
input pin
number
system
1
main menu
0, system
1.1 1.2 1.3 1.4

balance inquiry cash withdrawal change pin exit
1 1 number 0
1
1.2.1
enter withdrawal 1.3.1
amount input old
1, 1.2 password
1, 1.3
1.3.1.1
input new
password
1.3, 1.3.1
Tutorial 10 171
172 Tutorial 10
Lecture 11: System Implementation & Maintenance

Learning Objectives
Describe the process of coding, testing, and converting an organizational information system
and outline the deliverables and outcomes of the process.
Prepare a test plan for an information system.
Apply four installation strategies: direct, parallel, single-location, and phased installation.
List the deliverables for documenting the system and for training and supporting users.
Compare the many modes available for organizational information system training, including
self-training and electronic performance support systems.
Discuss the issues of providing support for end-users.
Explain why system implementation sometimes fails.
Describe the threats to system security and remedies that can be applied.
Show how traditional implementation issues apply to electronic commerce applications.
1. System Implementation
Six major activities:
Coding
Testing
Installation
Documentation
Training
Support
FIGURE 13-1 Systems development life cycle with the implementation phase
highlighted

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
2. 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 performed in parallel with coding.
Installation
The current system is replaced by new system.
TABLE 13-1 Deliverables for Coding, Testing, and Installation

1. Coding
a. Code
b. Program documentation
2. Testing
a. Test scenarios (test plan) and test data
b. Results of program and system testing
3. Installation
a. User guides
b. User training plan
c. Installation and conversion plan
i. Software and hardware installation schedule
ii. Data conversion plan
iii. Site and facility remodeling plan
174 System Implementation & Maintenance Lecture 11

3. The Process of Documenting the System, Training Users, and Supporting Users
Two audiences for final documentation:
Information systems personnel who will maintain the system throughout its
productive life
People who will use the system as part of their daily lives
User Training
Application-specific
General for operating system and off-the-shelf software
TABLE 13-2 Deliverables for Documenting the System, Training and Supporting Users
1. Documentation
a. System documentation
b. User documentation
2. User Training Plan
a. Classes
b. Tutorials
3. User Training Modules
a. Training materials
b. Computer-based training aids
4. User Support Plan
a. Help desk
b. Online help
c. Bulletin boards and other support mechanisms

4. Software Application Testing

A master test plan is developed during the analysis phase.
During the design phase, unit, system and integration test plans are developed.
The actual testing is done during implementation.
Test plans provide improved communication among all parties involved in testing.
TABLE 13-3 Table of Contents of a Master Test Plan

1. Introduction
a. Description of system to be tested
b. Objectives of the test plan
c. Method of testing
d. Supporting documents
2. Overall Plan
a. Milestones, schedule, and locations
b. Test materials
i. Test plans
ii. Test cases
iii. Test scenarios
iv. Test log
c. Criteria for passing tests
3. Testing Requirements
a. Hardware
b. Software
c. Personnel
4. Procedure Control
a. Test initiation
b. Test execution
c. Test failure
d. Access/change control
e. Document control
5. Test-Specific or Component-Specific Test Plans
a. Objectives
b. Software description
c. Method
d. Milestones, schedule, progression and locations
e. Requirements
f. Criteria for passing tests
g. Resulting test materials
h. Execution control
i. Attachments

5. Seven Different Types of Tests

Static or dynamic techniques
Static testing means that the code being tested is not executed.
Dynamic testing involves execution of the code.
Test is automated or manual
Automated means computer conducts the test.
Manual means that people complete the test.
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, including code
Desk checking: a testing technique in which the program code is sequentially executed
manually by the reviewer
Unit testing: each module is tested alone in an attempt to discover any errors in its code
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.
System testing: the bringing together of all of 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 modules, especially where modules are written
and tested in a top-down fashion, where a few lines of code are used to substitute for
subordinate modules
6. The Testing Process

The purpose of testing is to confirm that the system satisfies the requirements.
Testing must be planned.
Test case is a specific scenario of transactions, queries or navigation paths.
Test cases represent either:
Typical system use
Critical system use, or
Abnormal system use.
Test cases and results should be thoroughly documented so they can be repeated for each
revision of an application.

FIGURE 13-4 Test case results form
7. Automated Testing
Improves testing quality
Reduce testing time up to 80%
Functions:
Create recorded data entry and user action scripts
Compare test results between test cases
Simulate high-volume for stress-testing
8. Combining Coding and Testing

Coding and testing often go together.
Big companies have dedicated test staff.
With eXtreme programming (XP) a common technique is refactoring.
Refactoring = making a program simpler after adding a new feature.
9. Acceptance Testing by Users

Acceptance testing: the process whereby actual users test a completed information
system, the end result of which is the users acceptance of it
Alpha testing: user testing of a completed information system using simulated data
Beta testing: user testing of a completed information system using real data in the real
user environment
Types of Alpha Test:
Recovery testing forces 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
10. Installation
Installation: the organizational process of changing over from the current information
system to a new one
Four installation strategies:
Direct Installation
Parallel Installation
Single-location installation
Phased Installation
11. Direct Installation

Direct installation: changing over from the old system to a new one by turning off the
old system when the new system is turned on
12. Parallel Installation

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
13. Single-Location 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
Also known as location or pilot installation

14. Phased Installation

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
15. Planning Installation

Considerations
Data conversion
Error correction
Loading from current system
Planned system shutdown
Business cycle of organization
16. Documenting the System

System documentation: detailed information about a systems design specifications, its
internal workings, and its functionality
User documentation: written or other visual information about an application system,
how it works, and how to use it
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 E-R diagrams

TABLE 13-5 SDLC and Generic Documentation Corresponding to Each Phase

Generic Life-Cycle Phase Generic Document
Requirements Specification System Requirements Specification
Resource Requirements Specification
Project Control Structuring Management Plan
Engineering Change Proposal
System Development
Architectural design Architecture Design Document
Prototype design Prototype Design Document
Detailed design and implementation Detailed Design Document
Test specification Test Specifications
Test implementation Test Reports
System Delivery Users Guide
Release Description
System Administrators Guide
Reference Guide
Acceptance Sign-Off
17. Preparing User Documentation

Traditional source has been information systems department.
Application-oriented documentation is now often supplied by vendors and users
themselves.
FIGURE 13-6 Example of online user documentation

TABLE 13-6 Outline of a Generic Users Guide

Preface
1. Introduction
1.1 Configurations
1.2 Function flow
2. User interface
2.1 Display screens
2.2 Command types
3. Getting started
3.1 Login
3.2 Logout
3.3 Save
3.4 Error recovery
3.n [Basic procedure name]
n. [Task name]
Appendix A Error Messages
([Appendix])
Glossary
Terms
Acronyms
Index
18. Training and Supporting Users

Support: providing ongoing educational and problem-solving assistance to information
system users
For in-house developed systems, support materials and jobs will have to be prepared or
designed as part of the implementation process.
Computing infrastructure: all of the resources and practices required to help people and
adequately use computer systems to do their primary work
19. Training Information Systems Users

Potential training topics
Use of the system
General computer concepts
Information system concepts
Organizational concepts
System management
System installation
20. Types of Training Methods

Resident expert
Traditional instructor-led classroom training
E-learning, distance learning
Blended learning (instructor plus e-learning)
External sources (e.g. vendors)
21. Training Information Systems Users

Electronic performance support system (EPSS): component of a software package or
an application in which training and educational information is embedded
An EPSS can take several forms, including a tutorial, an expert system shell, and
hypertext jumps to reference materials.
22. Supporting Information Systems Users

Support is extremely important to users.
Providing support can be expensive and time-consuming.
23. Automating Support

One approach is through automation.
Internet-based online support forums
On-demand fax
Voice response systems
Knowledge bases
24. Providing Support Through a Help Desk

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
Requires
Technical skills: extensive knowledge about how to use the system and typical
problems that can be encountered
People skills: good listening and communication, dealing with complaints and
frustrations
25. Support Issues for the Analyst to Consider

User questions and problems
Recovery and backup
Disaster recovery
PC maintenance
Writing newsletters
Setting up user groups
26. Organizational Issues in Systems Implementation

Biggest measure of success: Will it be used?
Major factors influencing implementation success:
Management support

User involvement
Commitment to project
Commitment to change
Extent of project definition and planning
27. Factors Influencing System Use

Personal stake of users
System characteristics
User demographics
Organizational support
Performance
Satisfaction
28. Security Issues

Increasingly important issue for organizations and their management
Malicious software (malware): includes Trojan horses, worms, viruses, and other kinds
External sources of threats include laptop theft, system penetration, and denial of service.
29. Security Technologies

Antivirus software
Firewalls
Anti-spyware software
Intrusion detection systems
Biometrics
30. Electronic Commerce Application: System Implementation for Pine Valley Furnitures
WebStore
Developing test cases for the WebStore include testing categories as follows:
Simple functionality
Multiple functionality
Function chains
Elective functions
Emergency/crisis
31. Developing Test Cases for WebStore

Test case forms had the following sections:
Test Case ID
Category/Objective of Test
Description
System Version
Completion Date

Participants
Machine Characteristics (processor, operating system, memory, browser, etc.)
Test Result
Comments
32. Bug Tracking and System Evolution

Bug-tracking form has the following categories:
Bug Number (simple incremental number)
Test Case ID that Generate the Bug
Is the Bug Replicable?
Effects
Description
Resolution
Resolution Date
Comments
As batches of bugs are fixed, the version number of the software is incremented (i.e. 1.0,
2.0, 3.0, etc.).
33. Alpha and Beta Testing the WebStore

Alpha Testing:
PVF employees who actively participated received a t-shirt and $100 to shop.
Development team conducted extensive recovery, security, stress, and performance
testing.
Beta Testing:
PVF recruited several of their established customers to help in beta testing.
34. WebStore Installation

WebStore was ready to go online and development team recommended to top
management that it was time to flip the switch.
35. 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

36. Maintaining Information Systems
FIGURE 14-1 Systems development life cycle
37. 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
Maintenance is the longest phase in the SDLC.
Four major activities:
Obtaining maintenance requests
Transforming requests into changes
Designing changes
Implementing changes
38. Types of System Maintenance

Maintenance: changes made to a system to fix or enhance its functionality
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

39. Measuring Maintenance Effectiveness

Must measure the following factors:
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
FIGURE 14-7 How the mean time between failures should change over time
40. Website Maintenance

Special considerations:
24 X 7 X 365
Nature of continuous availability makes maintenance challenging.
Pages under maintenance can be locked.
Consider using date and time stamps to indicate when changes are made
instead.
Check for broken links
HTML Validation
Pages should be processed by a code validation routine before publication.
Reregistration

When content significantly changes, site may need to be reregistered with search
engines.
Future Editions
Consistency is important to users.
Post indications of future changes to the site.
Batch changes.
Summary
Describe the process of coding, testing, and converting an organizational information
system and outline the deliverables and outcomes of the process.
Prepare a test plan for an information system.
Apply four installation strategies: direct, parallel, single-location, and phased installation.
List the deliverables for documenting the system and for training and supporting users.
Compare the many modes available for organizational information system training,
including self-training and electronic performance support systems.
Discuss the issues of providing support for end-users.
Explain why system implementation sometimes fails.
Describe the threats to system security and remedies that can be applied.
Show how traditional implementation issues apply to electronic commerce applications.

TSE2251 SAD Revision Note

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TSE2251 SAD Revision Note

Enviado por

Direitos autorais:

Formatos disponíveis

TSE2251

Systems Analysis & Design

Lecture 01: The Systems Development Environment

FIGURE 1-1 An organizational approach to systems analysis and design is driven by

2. A Modern Approach to Systems Analysis and Design

Lecture 01 The Systems Development Environment 1

3. Types of Information Systems and Systems Development

4. Summary of Information Systems Types

2 The Systems Development Environment Lecture 01

5. Developing Information Systems

6. Systems Development Life Cycle (SDLC)

7. Standard and Evolutionary Views of SDLC

FIGURE 1-2 The systems development FIGURE 1-3 Evolutionary model

8. Systems Development Life Cycle (SDLC)

Lecture 01 The Systems Development Environment 3

Analysis system requirements are studied and structured

4 The Systems Development Environment Lecture 01

Maintenance an information system is systematically repaired and improved

Lecture 01 The Systems Development Environment 5

TABLE 1-1 Products of SDLC Phases

9. Traditional Waterfall SDLC

6 The Systems Development Environment Lecture 01

FIGURE 1-9 A traditional waterfall SDLC

10. Problems with Waterfall Approach

11. The Heart of the Systems Development Process

12. Different Approaches to Improving Waterfall SDLC

Lecture 01 The Systems Development Environment 7

FIGURE 1-11 The phototyping methodology

14. Computer-Aided Software Engineering (CASE) Tools

8 The Systems Development Environment Lecture 01

Documentation generators standardize technical and user documentation.

TABLE 1-2 Examples of CASE Usage within the SDLC

15. Joint Application Design (JAD)

Lecture 01 The Systems Development Environment 9

Purpose: to specify or review system requirements.

FIGURE 6-6 Illustration of the typical room layout for a JAD

16. Rapid Application Development (RAD)

10 The Systems Development Environment Lecture 01

FIGURE 1-11 RAD life cycle

17. Service-Oriented Architecture (SOA)

18. Agile Methodologies

Lecture 01 The Systems Development Environment 11

Adaptive rather than predictive

TABLE 1-3 The Agile Manifesto

Seventeen anarchists agree:

12 The Systems Development Environment Lecture 01

Agile processes promote sustainable development. The sponsors, developers, and

19. When to use Agile Methodologies

Lecture 01 The Systems Development Environment 13

highly stable environments. environments.

20. eXtreme Programming

21. Object-Oriented Analysis and Design (OOAD)

22. Rational Unified Process (RUP)

14 The Systems Development Environment Lecture 01

FIGURE 1-13 Phases of OOAD-based development

23. Our Approach to Systems Development

Lecture 01 The Systems Development Environment 15

Analysis Application Application Data

Object-oriented Analysis and Design (OOAD)

c. The complex organization process whereby computer-based information systems are

Information System analysis and design

d. Computer software designed to support organizational functions and processes.

Joint Application Design (JAD)