CHAPTER 9 (part b) B ASIC I NFORMATION S YSTEMS C ONCEPTS

Post on 04-Jan-2016

39 views 3 download

Tags:

description

CHAPTER 9 (part b) B ASIC I NFORMATION S YSTEMS C ONCEPTS. Page 366. Figure 9.10 Physical Model of a System. Tools for the As-Is Model. Must identify existing processes, external participants, other databases or applications, and inputs and outputs Tools used: - PowerPoint PPT Presentation

transcript

E. Wainright Martin Carol V. Brown Daniel W. DeHayesJeffrey A. Hoffer William C. Perkins

MANAGINGMANAGINGINFORMATIONINFORMATIONTECHNOLOGYTECHNOLOGY

FIFTH EDITION

CHAPTER 9 (part b)

BASIC INFORMATION SYSTEMS CONCEPTS

© 2005 Pearson Prentice-Hall Chapter 9 - 2 Page 366 Figure 9.10 Physical Model of a System

Boxes Major modules

Cylinders Databases

Arrows Flow of data

© 2005 Pearson Prentice-Hall Chapter 9 - 3 Page 366

Tools for the As-Is Model

Must identify existing processes, external participants, other databases or applications, and inputs and outputs

Tools used: Procedures, policies, manuals, forms, reports Other documentation Group interviews

© 2005 Pearson Prentice-Hall Chapter 9 - 4 Page 367

Context diagram – positions the system as a whole with regard to other entities and activities with which it interacts

Work process flow diagram – identifies the existing information sources, information sources that are updated, order in which steps occur, and some of the dependencies

Tools for the As-Is Model

© 2005 Pearson Prentice-Hall Chapter 9 - 5 Page 367 Figure 9.11 Context Diagram for Accounts Payable

Tools for the As-Is Model

© 2005 Pearson Prentice-Hall Chapter 9 - 6 Page 368 Figure 9.12 Work Process Flow Diagram for Accounts Payable

© 2005 Pearson Prentice-Hall Chapter 9 - 7 Page 367

Tools for the Logical To-Be Model

High-level model of a nonexistent new system

Identifies processes and data

Does not identify who does activity, where accomplished, or type of hardware or software

Describes “what” rather than “how”

Most closely associated with data flow diagrams (DFDs)

© 2005 Pearson Prentice-Hall Chapter 9 - 8 Page 369

Tools for the Logical To-Be Model

Figure 9.13(A) Top-Level DFD for Accounts Payable System

© 2005 Pearson Prentice-Hall Chapter 9 - 9 Page 369 Figure 9.13(A) Top-Level DFD for Accounts Payable System

External Entity

Data Flow

Processes

Data Store

© 2005 Pearson Prentice-Hall Chapter 9 - 10 Page 369

Tools for the Logical To-Be Model

Process of creating a DFD: Identify entities that supply or use system information Distinguish processes from data they use or produce Explicate business rules that affect transformation of data to information Identify logical relationships Pinpoint duplicate storage and movement of data

© 2005 Pearson Prentice-Hall Chapter 9 - 11 Page 370

Lower-level explosion DFD for Process 1.0

© 2005 Pearson Prentice-Hall Chapter 9 - 12 Page 370 Figure 9.13(B) Second-Level DFD for Accounts Payable System

Note process numbering scheme

© 2005 Pearson Prentice-Hall Chapter 9 - 13 Page 371-372

More logical modeling required after DFDs

Need to define system’s data elements and relationships: Data dictionary/directory (DD/D) used to define data elements Entity-relationship diagram (ERD) used to define relationships

between entities

Tools for the Logical To-Be Model

© 2005 Pearson Prentice-Hall Chapter 9 - 14 Page 371 Figure 9.14 Data Dictionary Sample Entry

© 2005 Pearson Prentice-Hall Chapter 9 - 15 Page 372 Figure 9.15 Entity-Relationship Diagram for Invoice and PO

Tools for the Logical To-Be Model

© 2005 Pearson Prentice-Hall Chapter 9 - 16 Page 372 Figure 9.16 Key Terms for Logical Data Modeling

Relational Database Terminology

© 2005 Pearson Prentice-Hall Chapter 9 - 17 Page 372-373

Tools for Documenting the Physical To-Be System

Tools for physical design represent how: processes and data stores partitioned program control handled database organized

Tools include: Program structure chart Database design System interface layouts

© 2005 Pearson Prentice-Hall Chapter 9 - 18 Page 373 Figure 9.17 Program Structure Chart

Program Structure Chart

© 2005 Pearson Prentice-Hall Chapter 9 - 19 Page 374 Figure 9.18 Relationships for Data Elements in Accounts Payable

Database Design (data relationships)

(Screen shot reprinted with permission from Microsoft Corporation)

© 2005 Pearson Prentice-Hall Chapter 9 - 20 Page 375 Figure 9.19 Input Form Layout for Vendor Invoice

System Interface Input Layout Form

(Screen shot reprinted with permission from Microsoft Corporation)

© 2005 Pearson Prentice-Hall Chapter 9 - 21 Page 375 Figure 9.20 Check Register Report Layout with Sample Data

Output Report Layout

© 2005 Pearson Prentice-Hall Chapter 9 - 22 Page 374

Object-Oriented Techniques

Object approach well suited for client/server applications, graphical interfaces, and multimedia data

Primary advantage is ability to reuse objects programmed by others

PROCESSES AND TECHNIQUES TO DELIVER INFORMATION SYSTEMS

© 2005 Pearson Prentice-Hall Chapter 9 - 23 Page 376

Object-Oriented Techniques

PROCESSES AND TECHNIQUES TO DELIVER INFORMATION SYSTEMS

Figure 9.21 The Promise of Object-Oriented Approaches

© 2005 Pearson Prentice-Hall Chapter 9 - 24 Page 376

Core Concepts

PROCESSES AND TECHNIQUES TO DELIVER INFORMATION SYSTEMS

Figure 9.22 Message Passing

Object Encapsulation Inheritance

Objects communicate with each other through messages that specify what should be done, not how it should be done

© 2005 Pearson Prentice-Hall Chapter 9 - 25 Page 376

Unified Modeling Language (UML)For O-O Modeling

PROCESSES AND TECHNIQUES TO DELIVER INFORMATION SYSTEMS

Figure 9.22 Message Passing

UML is standardization for O-O analysis and design modeling techniques and notations

UML diagrams: Use-case diagrams Extended relationship use-case diagram Sequence diagram Class diagram

Logical modeling begins with use-cases – diagrams and text forms

© 2005 Pearson Prentice-Hall Chapter 9 - 26 Page 376 Figure 9.23 Use Case Diagram

Use Case Diagram

© 2005 Pearson Prentice-Hall Chapter 9 - 27 Page 376 Figure 9.24 Become Member Use Case

Use Case – Text Form

© 2005 Pearson Prentice-Hall Chapter 9 - 28 Page 377

INFORMATION SYSTEMS CONTROLS TO MINIMIZE BUSINESS RISKS

Common system security risks: Human error Criminal acts Due to staffing changes and project management deficiencies Natural disasters

© 2005 Pearson Prentice-Hall Chapter 9 - 29

INFORMATION SYSTEMS CONTROLS TO MINIMIZE BUSINESS RISKS

Management policies

Operating procedures

Auditing function

Types of Control Mechanisms

Page 378-380

© 2005 Pearson Prentice-Hall Chapter 9 - 30 Page 380

INFORMATION SYSTEMS CONTROLS TO MINIMIZE BUSINESS RISKS

Controls built into the information system itself: To maintain data integrity Allow only authorized access Ensure proper system operation Protect against malfunctions, power outages, and disasters

Types of Control Mechanisms

© 2005 Pearson Prentice-Hall Chapter 9 - 31 Page 380

INFORMATION SYSTEMS CONTROLS TO MINIMIZE BUSINESS RISKS

IS Organization Backup power

supplies Network access

control Firewall protection

Business Organization Ensure accurate data

entry and handling Identify procedural

errors

Types of Control Mechanisms

© 2005 Pearson Prentice-Hall Chapter 9 - 32 Page 380

Types of Control Mechanisms

Figure 9.26 Pre- and Post-Installation Controls

INFORMATION SYSTEMS CONTROLS TO MINIMIZE BUSINESS RISKS