Management Information Systems, 10/e Raymond McLeod Jr. and George P. Schell

advertisement

Management

Information Systems,

10/e

Raymond McLeod Jr. and George P. Schell

1 © 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

Chapter 7

Systems Development

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

2

Learning Objectives

Recognize the systems approach as the basic framework for solving problems of all kinds.

Know how to apply the systems approach to solving systems problems.

Understand that the systems development life cycle (SDLC) is a methodology – a recommended way to develop systems.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

3

Learning Objectives (Cont’d)

Be familiar with the main SDLC approaches – the traditional waterfall cycle, prototyping, rapid application development, phased development, and business process redesign.

Know the basics of modeling processes with data flow diagrams and use cases.

Understand how systems development projects are managed in a top-down fashion.

Be familiar with the basic processes of estimating project cost.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

4

The Systems Approach

John Dewey identified three series of judgments involved in adequately resolving a controversy:

 Recognize the controversy.

 Weigh alternative claims.

 Form a judgment.

During the late 1960s/early 1970s, interest in systematic problem solving strengthened.

Systems approach — a series of problem-solving steps that ensure the problem is first understood, alternative solutions are considered, and the selected solution works.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

5

Series of Steps

Preparation effort prepares the problem solver by providing a systems orientation.

 Business areas, level of management, resource flows

Definition effort consists of identifying the problem to be solved and then understanding it.

Solution effort involves identifying alternative solutions, evaluating them, selecting the one that appears best, implementing that solution, and following up to ensure that the problem is solved.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

6

Figure 7.1 Phases and Steps of

Systems Approach

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

7

Figure 7.2 Each Business Area Is a

System

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

8

Definition Effort Terminology

Problem trigger is a signal that things are going better or worse than planned.

Symptom is a condition that is produced by the problem and is usually more obvious than the root cause of the problem.

Problem is a condition or event that is harmful or potentially or beneficial or potentially beneficial to the firm.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

9

Figure 7.3 Each Part of the System Is

Analyzed in Sequence

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

10

Select the Best Solution

Analysis–a systematic evaluation of options.

Judgment–the mental process of a single manager.

Bargaining–negotiations between several managers.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

11

Systems Development Life Cycle

Methodology is a recommended way of doing something.

Systems development life cycle (SDLC) is an application of the systems approach to the development of an information system.

Traditional SDLC stages are:

 Planning

 Analysis

 Design

 Implementation

 Use

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

12

Figure 7.4 The Circular Pattern of the

System Life Cycle

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

13

Prototyping

Prototype is a version of a potential system that provides the developers and future users with an idea of how the system in its completed form will function.

Prototyping is the process of producing a prototype.

 Best suited for small systems–reflecting the prototyping influence.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

14

Evolutionary Prototype

Evolutionary prototype is continually refined until it contains all of the functionality that users require of the new system. The steps involved are:

 Identify user needs.

 Develop prototype.

Integrated application developer

Prototyping toolkit

 Determine if the prototype is acceptable.

 Use the prototype.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

15

Figure 7.5 Development of an

Evolutionary Prototype

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

16

Requirements Prototype

Requirements prototype is developed as a way to define the functional requirements of the new system when users are unable to articulate exactly what they want. Begin with the Evolutionary

Prototype steps, then the next steps are:

 Code the new system;

 Test the new system;

 Determine if the new system is acceptable;

 Put the new system into production.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

17

Figure 7.6 Development of a

Requirements Prototype

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

18

Attraction of Prototyping

Communications between the developer and user are improved.

The developer can do a better job of determining the users’ needs.

The user plays a more active role in system development.

The developers and the user spend less time and effort developing the system.

Implementation is much easier because the user knows what to expect.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

19

Potential Pitfalls of Prototyping

The haste to deliver the prototype may produce shortcuts in problem definition, alternative evaluation, and documentation. The shortcut produces a “quick & dirty” effort.

The user may get overly excited about the prototype, leading to unrealistic expectations regarding the production system.

Evolutionary prototypes may not be very efficient.

The computer-human interface provided by certain prototyping tools may not reflect good design techniques.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

20

Rapid Application Development

Rapid Application Development (RAD) is a term coined by James Martin. It refers to a development life cycle intended to produce systems quickly without sacrificing quality.

Information engineering (IE) is the name that

Martin gives to his overall approach to system development, which treats it as a firm-wide activity.

Enterprise is used to describe the entire firm.

 Essential to RAD is management, people, methodologies, and tools.

 Best suited for large systems.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

21

Figure 7.7 Rapid Application Development Is an Integral Part of Information Engineering

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

22

Phased Development

Phased development is an approach for developing information systems that consists of six stages:

 Preliminary investigation

 Analysis

 Design

 Preliminary construction

 Final construction

 System test

 Installation.

 Best suited for systems of all sizes.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

23

Figure 7.8 The Stages of the Phased

Development Methodology

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

24

Module Phases

System is subdivided into major modules such as:

 Report writer;

 Database;

 Web interface.

Number of modules varies with the system from one to a dozen or so.

Stages are performed separately for each module.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

25

Figure 7.9 Analysis, Design, and Preliminary

Construction are Performed on Each System

Module

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

26

Business Process Redesign

Reengineering or Business process redesign

(BPR) is the process of reworking the systems.

 Systems include both those that process the firm’s data and those that perform basic functions such as drilling for oil.

BPR affects the firm’s IT operations in two ways:

 Aids in the redesign of old information systems ( systems); legacy

 Applies to the redesign of information systems to support major operations.

Usually initiated at strategic management level

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

27

Figure 7.10 Top-Down Initiation of

BPR Projects

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

28

Strategic Initiation of BPR

Reverse engineering is the process of analyzing an existing system to:

 Identify its elements and their interrelationships;

 Create documentation at a higher level of abstraction than currently exists.

Functionality is the job that it performs.

Reengineering is the complete redesign of a system with the objective of changing its functionality.

Forward engineering is given to the process of following the SDLC in the normal manner while engaging in BPR.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

29

BPR Components

BPR components can be applied separately or in combination.

Functional quality is a measure of what the system does.

Technical quality is a measure of how well it does it.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

30

Figure 7.11 BPR Component Selection Is

Based on Both Functional and Technical

Quality

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

31

Methodologies in Perspective

Traditional SDLC is an application of the systems approach to the problem of system development; contains all elements.

Prototyping is an abbreviated form focusing on the definition and satisfaction of user needs.

RAD is an alternative approach to the design and implementation phases of SDLC.

Phased development uses traditional SDLC and applies it in a modular fashion.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

32

System Development Tools

Process modeling was first done with flowcharts .

 ISO standards

 Use of 20+ symbols

Data flow diagrams (DFD) is a graphic representation of a system that uses four symbol shapes to illustrate how data flows through interconnected processes.

DFDs are excellent for modeling processes at a summary level.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

33

Data Flow Diagram Symbols

Terminator describes an environmental element, such as a person, organization, or another system.

Environmental elements exist outside the boundary of the system.

Process is something than transforms input into output.

Data flow consists of a group of logically related data elements that travel from one point or process to another; can diverge and converge .

Data storage is a repository of data.

Connector contains the number of the process that provides the data flow.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

34

Figure 7.12 A DFD of a Sales

Commission System

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

35

Leveled Data Flow Diagrams

Leveled DFDs is used to describe the hierarchy of diagrams, ranging from context to lowest-level n diagram.

Figure 0 diagram identifies the major processes of a system.

 Use additional DFDs to achieve documentation at both a more summarized and a more detailed level.

Context diagram is a diagram that documents the system at a more summarized level.

 Positions the system in an environmental context.

Figure n diagram is a diagram that provides more detail.

 n represents the # of processes on the next higher level.

 Documents a single process of a DFD in greater detail

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

36

Figure 7.13 A Context Diagram of a

Sales Commission System

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

37

Figure 7.14 A Figure 4 Diagram of a

Sales Commission System

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

38

Use Cases

Use case is a narrative description in an outline form of the dialog that occurs between a primary and secondary system.

Continuous narrative format with each action numbered sequentially.

Ping-pong format consists of two narratives and the numbering indicates how the tasks alternate between the primary and secondary systems.

Alternative events are actions that are not normally expected to occur; alphabetic letters are appended to step numbers.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

39

Figure 7.15 A Use Case

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

40

Figure 7.16 Use Case Guidelines

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

41

Project Management

Steering committee is a committee with the purpose of providing ongoing guidance, direction, and control of all systems projects.

MIS steering committee purpose is directing the use of the firm’s computing resources.

 It establishes policies.

 It provides fiscal control.

 It resolves conflict.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

42

Figure 7.17 Managers of a System

Life Cycle Arranged in a Hierarchy

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

43

Project Leadership

Project team includes all of the persons who participate in the development of an information system.

Team leader (project leader) provides direction throughout the life of the project.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

44

Project Management Mechanism

Basis for project management is the project plan.

Gantt chart is a horizontal bar chart that includes a bar for each task to be performed; bars arranged in time sequence.

Network diagram ( CPM diagram, PERT chart ) is a drawing that identifies activities and links them with arrows to show the sequence in which they are to be performed.

Narrative reports are in the form of weekly written reports by project leader, communicates project information to MIS steering committee.

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

45

Figure 7.18 A Gantt Chart

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

46

Figure 7.19 A Network Diagram

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

47

Project Cost Estimating

Cost-estimating inputs

Work breakdown structure (WBS)

Resource requirements, resource rates

Activity duration estimates

Historical information

Cost-estimating tools and techniques

Bottom-up estimating

Computerized tools

Mathematical models

Cost-estimating outputs

Supporting details

Cost-management plan

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

48

Table 7.1 Components of Cost-

Estimating Process

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

49

Table 7.2 Example of Project Cost

© 2007 by Prentice Hall Management Information Systems, 10/e

Raymond McLeod and George Schell

50

Download