CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

30
CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System

Transcript of CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Page 1: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

CHAPTER 4

Systems Analysis and Design of a Business Event-Driven System

Page 2: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• The objective of to help you understand the key steps in analyzing and designing information Technology (IT) applications.

• In this chapter, we explain how to use the REAL business process model to analyze and design IT application that support those responsible for defining and managing organization activities.

• The key to better information systems is not simply understanding the current business operations and information processing, but understanding the organization’s objectives and desired business process.

Page 3: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Project Initiating

And Planning

Analysis

Logical Design

Physical Design

Project Identification And Selection

Implementation

Maintenance

EXHIBIT 4-1 Systems Development Process : Method One

Page 4: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Existing system details and limitations

System Design

System support

System analysis

System Implementation

System Planning

Existing system details and limitations

Planned application development project

Business requirements statements

Production information system

Technical Designstatement

EXHIBIT 4-2System Development Process: Method Two

Page 5: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• The chapter introduce you to each of the following systems analysis and design phases, with emphasis on Phases I, II, III:I. The analysis PhaseII. The Logical Design PhaseIII. The Physical Design PhaseIV. The Implementation and Maintenance

Phase

• Your business analysis highlights the activities that an organization needs to perform effectively and efficiently in order to accomplish its objectives.

Page 6: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Order personnel

Customer

Shipping Personnel

Shipping Firm

Cashier

Receive Customer

order

Ship order

Collect Payment

Inventory

Cash Bank Is kept at

Increases

Takes in

Sends

incl

udes

Takes

Places

Goes to

Executes Carried by

Is made up of

EXHIBIT 4-3Christopher, Inc, REAL Model

Page 7: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• Processing instructions and data flows are necessary to support the operating and decision-making. Includes the major components: (1) the data and organization chooses to record and maintain and (2) the processing instructions used to record data, maintain data, and report useful information.

• The workflow to support a business process involves three types of information events: Recording, Maintaining, Reporting.

• Recording operating event data involves capturing data about each operating event. When data are captured while the operating events occurs, the recording process the execute business rules specified by management for each operating event. These rules are the guidelines standards, policies, and/or procedures intended to increase operational and information quality by reducing such as errors, irregularities and fraud.

Page 8: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• Maintaining reference data involves adding, deleting or modifying data about resources, agents and locations. The objectives is to maintain accurate, complete and timely data about the resources, agents, and locations involved in operating events for the process you are modeling.

• The reporting processes extract and covert stored data about events, resources, agents and locations into information, and format the information for presentation to information customers.

• In this step, analysts use process-modeling techniques to graphically represent the system requirements.

• Will focus on data flow diagrams of smple business event-driven systems.

Page 9: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• Context diagram-the highest level logical view of a system. When creating a context diagram, you do not show the data stores and data flows within the boundaries of the system. This diagram is consistent with the REAL model.

• As you create more detailed data flow diagrams, remember that each information process (recording, maintaining, and reporting)

Page 10: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Customers 0

Sales/Collection System

Decision Makers

Order

Bill

Payments

Desired Information

EXHIBIT 4-4Christopher, Inc, Context Diagram

Page 11: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Customers

2.0Process

shipments to

customers

Decision Makers

Order

Bill

Payments

Desired Information

1.0Process

customers orders

3.0Process

Payments from

customers

Desire

d

Info

rmat

ion Payments

Due data

Desired

Information

EXHIBIT 4-5Christopher, Inc, Level 0 Data Flow Diagram

Page 12: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

EXHIBIT 4-6Christopher, Inc, Level 1 Data Flow Diagram

1.1Approve and

record customer order data

1.2Generate

information about orders

Customer order data

Order

Shipping Request data

Approved order

Order data

Desired Information

Page 13: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• Techniques used during this step include structured English, decision Tables, decision trees and state transition diagrams or tables.

• Structured English is a code-independent way of communicating program logic. It is used to plan and document the steps of a computer instruction set (a program) without using a programming language.

Page 14: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Process

Output

Input Data

For each customer-order do the following:1. Search for Customer-Name

If foundConfirm customer info with customerEnter customer data

2. Check for availability of inventory requested If available Confirm ship to information If not available Inform customer the inventory is not available3. Provide customer with order confirmation 4. Send notification to packing agents

EXHIBIT 4-7Structured English Example

Page 15: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• Business event risk results in errors and irregularities having one or more of the following characteristics. – Information event risks include– Recording risk include– Maintaining risk – Reporting risk

• To focus on the specific data you want to capture to describe reality and generate needs outputs. Conceptual data model.

• A relationship is an association between the instances of one or more entity groups of interest to the organization

Page 16: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• We focus on the business activities that compose the information represented in the views (the business processes)

• The model from Chapter 2 includes what we call binary relationships. Binary relationships are relationships between instances of two different entity group.

• A recursive relationship is the relationship between instances of a single entity group. There is a third type relationship, the ternary relationship that we will not discuss at this time.

• Analyst use cardinalities to accomplish this task. The purpose of relationship cardinalities is to enrich our language for describing and more precisely representing business process rules.

Page 17: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Employee Manages Employee

Man

ag

ers

EXHIBIT 4-8Recursive Relationship Examples

Page 18: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• Many people overlook the power of cardinalities as a tool to understand electronic audit trails, as well as the logic that should appear in information system processing instruction. The cardinalities represent how a business desires its business activities to occur, you information system should reflect this reality.

Page 19: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Order personnel

Customer

Shipping Personnel

Shipping Firm

Cashier

Receive Customer

order

Ship order

Collect Payment

Inventory

Cash Bank Is kept at

Increases

Takes in

Sends

incl

udes

Takes

Places

Goes to

Executes Carried by

Is made up of

EXHIBIT 4-9Christopher, Inc, REAL Model with Cardinalities

Page 20: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

(1,1)

(1,*)

(0,1)

(0,*)

EXHIBIT 4-9Different Notation to Represent Relationship Cardinalities

Page 21: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• System analysts consider the various hardware, software, processing modes and so on that will be most effective and efficient in designing a system that full fills the stipulated requirements.

• The architecture guiding these concept can be implemented using a variety of technology platforms (both hardware and software).

• The logical design phase involves several major components including designing form and reports, designing interface and dialogues and designing database using logical data modeling techniques.

• A table is a two-dimensional array having columns and rows. Each column or field of a table is called and attribute, and each row of the table is called a record.

Page 22: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Reorder point

Current price

Product Specification

Beginning Quantity

Beginning Quantity date

Description

Inventory Item #

Inventory

EXHIBIT 4-11Entity Attributes in an ER Diagram

Page 23: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• The data tables will contain the recorded and maintained data that describe the essential components of an organization and its activities. These data will then be used the report information about and measurements of organizations events, resources, agents and locations.

• Deciding how many relations are needed within the logical data repository. This decision is greatly simplified by reviewing the REAL conceptual data model and applying the following rule:

• Each entity object (event, resource, agent and location) in the REAL model becomes a relation.

• When you use the relational logical design, you link relations by placing the key attribute of one entity into the relation of the related entity. To key attributes hat are placed in another relation as foreign keys or posted keys. Purpose of foreign keys is to link relations so that the resulting relational tables can be used collectively to store business data and to generate useful information.

Page 24: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• Composite attributes• When defining relation attributes

– Each relation should include only those attributes that describe the entity represented by the relation.

• Second guideline for defining event-driven logical designs is :– Avoid including derivable non-key attributes in the relations

• Derivable attributes are information items that can be calculated using other data items, so there is no need to store them as relation attributes

• In the physical design phase we create the physical files, database, and programmed instructions. The implementation and maintenance phase of a systems project involve coding, testing, installing, documenting, training users, supporting users, and maintaining the system.

Page 25: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• There are three parts to an IT application prototype:

• The data storage structure• The forms and reports used for the recording

maintaining, and reporting process• The detailed logic underlying the forms and

reports that implement the business and information process rules

• The following are typical steps in building an IT application prototype.

Page 26: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Record order

Order-Data

ORDER-INVENTORY

ORDER PERSONNEL

CUSTOMER

ORDER

INVENTORY

EXHIBIT 4-14Linking an Order Recording Process With a Data Repository

Page 27: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Update Bank data

Update Customer

data

Update Shipping

firm data

Update Inventory

data

Bank-data

Customer-data

Shipping firm-data

Inventory data

BANK

CUSTOMER

SHIPPING FIRM

INVENTORY

EXHIBIT 4-15Sample Maintenance Processes and Data Access

Page 28: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Record order

Request sales by-sales person report

SALE-MERCHANDISE

SALES PERSON

SALE

INVENTORY

Sales by-Sales person

Sales by salesperson = Report-Date + {Salesperson Name +{Merchandise-Description + Qty-Sold + $ Contribution} } + Total Sales + Total Contribution

EXHIBIT 4-16Example of Generating a Sales by Sales Person Report

Page 29: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

• These steps facilitate the development of a business event driven IT application prototype that can control the business process and perform the information processing required to support decision makers who are responsible for managing the process.

• Some guidelines for developing prototypes:– Computer should display user-friendly interface– When instructing a computer to access a data pool, the

program instructions should specify details regarding where the data area stored, the format of the data pool, and which field to access.

– Most processing code should begin only after reviewing and validating the accessibility of the computer user

– Source data automation techniques, copying data from existing data pools and having the computer automatically generate some fields, such as the data field or a sequentially numbered field, are methods to reduce human input error.

– Programmers should ensure that proper backups and electronic audit trails are maintained at all times.

Page 30: CHAPTER 4 Systems Analysis and Design of a Business Event-Driven System.

Reference

• Hollander, A. S. Eric L. Denna, J. OwenCherrington.2000. AccountingInformation Technology, And BusinessSolutions. Irwin McGraw-Kill, New York-USA.