chapter 9 (part b) b asic i nformation s ystems c oncepts
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 PresentationTRANSCRIPT
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