Managing Information Technology 6 th Edition

Transcription

1 Managing Information Technology 6 th Edition CHAPTER 9 BASIC INFORMATION SYSTEMS CONCEPTS Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 1

2 What is a system? The Systems View It s the SYSTEM s fault! The SYSTEM is down. My SYSTEM can t be beat! Don t buck the SYSTEM. Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 2

3 The Systems View System can refer to something broader than an information system In this chapter, we adopt a systems perspective to understand the relationships among business units and organizational events Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 3

4 What is a system? Systems thinking is: The Systems View A discipline for seeing wholes A framework for seeing interrelationships rather than things An antidote to feeling of helplessness when dealing with complexity Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 4

5 What is a system? The Systems View System A set of interrelated components that must work together to achieve some common purpose Information System The collection of IT, procedures, and people responsible for the capture, movement, management, and distribution of data and information Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 5

6 The Systems View What is a system? Each piece may be well designed designed, but the pieces also need to work well together Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 6

7 THE SYSTEMS VIEW Seven key system elements 1. Boundary 2. Environment 3. Inputs 4. Outputs 5. Components 6. Interfaces 7. Storage Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 7

8 THE SYSTEMS VIEW Seven key system elements 1. Boundary Delineation of which elements are within the system and which are outside 2. Environment Everything outside the system Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 8

9 THE SYSTEMS VIEW Seven key system elements 2. Inputs Resources from theenvironmentenvironment thatare are consumed and manipulated within the system 3. Outputs 4. Resources or products provided to the environment by the activities within the system Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 9

10 THE SYSTEMS VIEW Seven key system elements 5. Components Activities or processes within the system that transform inputs into intermediate forms or that generate system outputs Components can be viewed as subsystems Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 10

11 THE SYSTEMS VIEW Seven key system elements 6. Interfaces The place where two components or the system and its environment meet or interact 7. Storage Holding areas used for the temporary and permanent storage of information, energy, materials, andso on Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 11

12 THE SYSTEMS VIEW Examples of System Components from Payroll Inputs Outputs Components Interfaces Storage Time cards, vouchers Paychecks, W 2 Forms Calculate total pay, subtract deductions Match time cards to employees, sort paychecks by department Employee benefits, Pay rates Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 12

13 THE SYSTEMS VIEW Seven key system elements Where to draw the boundary depends on: What can be controlled What scope is manageable within a given time frame The impact of a boundary change Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 13

14 THE SYSTEMS VIEW Component Decomposition Some system components can be viewed as systems with their own sets of interrelated components and are called subsystems Hierarchical decomposition is the process of breaking a system down into successive levels of subsystems Five important tgoals of hierarchical decomposition: 1. Cope with system complexity 2. Analyze or change only part of the system 3. Design and build each subsystem at different times 4. Direct the attention of a target audience 5. Allowcomponents to operate moreindependently Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 14

15 THE SYSTEMS VIEW Component Decomposition The Sales Summary System Figure 9.4 Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 15

16 THE SYSTEMS VIEW Component Decomposition The Produce Sales Summary Subsystem Figure 9.4 Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 16

17 THE SYSTEMS VIEW Interfaces Functions of an interface include: Filtering Deposing of useless data (or noise) Coding/decoding g Translating data from one format into another Error detection and correction Checking for compliance to standards and for consistency Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 17

18 THE SYSTEMS VIEW Interfaces Functions of an interface include (cont d): Buffer Allowing two subsystems to work together without being tightly synchronized Security Rejecting unauthorized requests for data and providing other protection mechanisms Summarizing Condensing large volumes of input to reduce the amount of work needed by subsequent subsystems Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 18

19 THE SYSTEMS VIEW Organizations as systems One useful framework for examining how information systems fit into organizational systems is based on the Leavitt diamondd Four fundamental components in an organization are linked People Organizational structure Information Technology Business Processes Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 19

20 THE SYSTEMS VIEW Organizations as systems Leavitt Diamond If one is component is changed, the others will likely be affected as well For example, new software may have the following effects: People have to be retrained Business processes need to be redesigned Organizational structures must be modified Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 20

21 THE SYSTEMS VIEW Systems analysis and design IT leaders understand that changes in information systems affect the entire organizational system One process used in developing new systems that takes into account the systems view is Systems Analysis and Design (SA&D) Two key principles: p Choose an appropriate scope Logical before physical Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 21

22 THE SYSTEMS VIEW Systems Analysis and Design SA&D has five key design principles Two key principles p stem from key systems characteristics: 1. Choose an appropriate scope Selecting the boundary for the IS greatly influences complexity and success of the project 2. Logical before physical You must know what an IS is to do before you can specify how a system is to operate Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 22

23 THE SYSTEMS VIEW Systems Analysis and Design SA&D has five key design principles The other three principles are problem solving steps: 3. A problem is actually a set of problems and an appropriate strategy is to keep breaking down a problem into smaller, more manageable problems 4. A single solution is not usually obvious to all stakeholders, so alternative solutions representing all parties should be generated before a final solution is selected 5. The problem and your understanding of it could change; thus a staged approach that incorporates reassessments and incremental commitment to a solution is best Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 23

24 Business Processes In the 1990s many organizations changed from a more functional approach to a more process oriented oriented approach to better compete globally Business process Chain of activities required to achieve an outcome such as order fulfillment or materials acquisition Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 24

25 Business Processes Experts urged companies to radically change the way they did business by starting with a clean slate and utilizing IT Don t automate; obliterate! Michael Hammer Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 25

26 Business Processes These changes became known as business process reengineering Business process reengineering i (BPR) Radical business redesign initiatives that attempt to achieve dramatic improvements in business processes by questioning the assumptions, or business rules, that underlie the organization s structures and procedures Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 26

27 Business Processes Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 27

28 Business Processes Systems analysis and design Examples: Accounts Payable at Ford Motor Company 75% improvement gains after assumptions were questioned and a reengineered solution was identified Mutual Benefit Life Insurance Changed a process that involved 19 people in five departments t so that t it could be accomplished by one person Policy issue times decreased from 3 weeks to 3 hours Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 28

29 Business Processes How IT Enables New Ways to Work Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 29

30 Business Processes Six Key Principles for Redesigning Business Processes Organize business processes around outcomes, not tasks Assign those who use the output to perform the process Integrate information processing into the work that produces the information Create a virtual it enterprise by treating ti geographically distributed resources as though they were centralized Lick parallel activities instead of integrating their results Have people who do the work make all the decisions, i and let controls built into the system monitor the process Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 30

31 Processes and Techniques Systems development life cycle (SDLC) Three phases of information system development: 1. Definition: end users and systems analysts conduct a multistepanalysisofthe the current business operations and the information system or systems in the area of concern 2. Construction: designing, building, and testing of a system that satisfies ifi the requirements developed din the Definition phase 3. Implementation: install the new system, which often involves converting data and procedures from an old system Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 31

32 Processes and Techniques Systems development life cycle (SDLC) Three phases of information system development: Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 32

33 Structured Techniques Structured Techniques Tools to document system needs, requirements, functional features, dependencies, and design decisions Procedural oriented Most common Include data oriented, sequential, process oriented activities Object oriented Newer approach Often used for GUIs and multimedia applications Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 33

34 Structured Techniques Procedural oriented techniques describe what you have, define what you want, and describe how you will make it so Different techniques are used to create the following threemodels: 1. As Is 2. Logical To Be 3. Physical To Be Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 34

35 Structured Techniques 1. As Is Model Must identify existing processes, external participants, other databases or applications, and inputs and outputs 2. Logical To Be High level model of a nonexistent new system Identifies processes and data Doesnotidentifywho doesactivity activity, whereaccomplished accomplished, or type of hardware or software Describes what rather than how 3. Physical To Be Requires technology expertise to map the logical requirements to available technology Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 35

36 Structured Techniques Techniques for the As Is Model Context Diagram Positions the system as a whole with regard to other entities and activities with which it interacts Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 36

37 Structured Techniques Techniques for the Logical To Be Model Data Flow Diagram (DFD) Shows the flows of information through the system These consist of four symbols representing: External Entity Data Flow Process Data Store Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 37

38 PROCESSES AND TECHNIQUES Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 38

39 Structured Techniques Techniques for the Logical To Be Model Dt Data Dictionary/Directory t Used to define data elements Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 39

40 Structured Techniques Techniques for the Logical To Be Model Entity Relationship Diagram (E R Diagram or ERD) Used dto define dfi relationships lti among entities Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 40

41 Structured Techniques Techniques for the Physical To Be Model Program Structure Chart Represent flow of program control Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 41

42 Structured Techniques Techniques for the Physical To Be Model Draft Layouts Represents user interface design Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 42

43 Structured Techniques Object Oriented (O O) Techniques Primary advantage is object reuse Can enable quick prototyping Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 43

44 Structured Techniques Core Object Oriented Concepts Encapsulation An object contains data and related operations Allows loosely coupled modules and reuse Inheritance One class of objects can inherit characteristics from others Polymorphism The ability to treat child objects the same as parent objects (i.e. call methods exactly the same) Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 44

45 Structured Techniques Unified Modeling Language (UML) A set of standardized techniques and notations for O O analysis and design There are several types of UML diagrams used to design systems We will examine three types: Use case diagram Sequence diagram Class diagram Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 45

46 UML Unified Modeling Language (UML) Use Case Diagram Represents the interaction of users with the system Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 46

47 Sequence Diagram UML Captures the messages that pass between objects Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 47

48 UML Unified Modeling Language (UML) Class Diagram Represents each object s attributes, methods, and relationships with other objects Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 48

49 Information Systems Controls All businesses face security risks and only a small percentage of those risks involve IT IT can be used to mitigate some business risk through the addition of controls There are three types of control mechanisms 1. Management policies 2. Operating procedures 3. Auditing function Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 49

50 Information Systems Controls Controls can be built into the information system itself throughout the SDLC Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 50

51 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall 51