Revision Modern Systems Analysis and Design. © 2008 by Prentice Hall 2 Chapter 3 Managing the...

Revision

Modern Systems Analysisand Design

Managing the Information Systems Project A Project Manager is a systems analyst with a

diverse set of skills – management, leadership, technical, conflict management, and customer relationship – who is responsible for initiating, planning, executing, and closing down a project.

Managing the Information Systems Project (Cont.)

Project management: a controlled process of initiating, planning, executing, and closing down a project.

Project Management Process Initiating the Process.Planning the Project.Executing the Project.Closing down the Project.

Standard and Evolutionary Views of SDLC

Systems Development Life Cycle (SDLC) (Cont.) Planning – an organization’s total

information system needs are identified, analyzed, prioritized, and arranged.

Analysis – system requirements are studied and structured.

Systems Development Life Cycle (SDLC) (Cont.) Design – a description of the

recommended solution is converted into logical and then physical system specifications.

Logical design – all functional features of the system chosen for development in analysis are described independently of any computer platform.

Systems Development Life Cycle (SDLC) (Cont.) Physical design – the logical

specifications of the system from logical design are transformed into the technology-specific details from which all programming and system construction can be accomplished.

Systems Development Life Cycle (SDLC) (Cont.) Implementation – the information system

is coded, tested, installed and supported in the organization.

Maintenance – an information system is systematically repaired and improved.

Traditional Waterfall SDLC

One phase begins when another completes, little backtracking and looping

Problems with Waterfall Approach

System requirements “locked in” after being determined (can't change).

Limited user involvement (only in requirements phase).

Too much focus on milestone deadlines of SDLC phases to the detriment of sound development practices.

Initiating and Planning Systems Development Projects What must be considered when making the

decision on the division between project initiation and planning (PIP) and analysis.

How much effort should be expended on the PIP process?

Who is responsible for performing the PIP process?

Why is PIP such a challenging activity?

The Process of Initiating and Planning IS Development Projects (Cont.)

Project initiation focuses on activities designed to assist in organizing a team to conduct project planning.

Establishing the Project Initiation Team. Establishing a Relationship with the

Customer.

The Process of Initiating and Planning IS Development Projects (Cont.)

Establishing the Project Initiation Plan. Establishing Management Procedures. Establishing the Project Management

Environment and Project Workbook. Developing the Project Charter.

Prototyping

Iterative development process: Requirements quickly converted to a

working system. System is continually revised. Close collaboration between users and

analysts.

Prototyping is useful for requirements determination, helping to clarify and communicate user requirements. Also, a prototype can serve as the basis for the final

system. As an example,- imagine that an analyst is developing a computerized

inventory-tracking system. This inventory-tracking system provides a sales representative with real-time access to inventory levels. The analyst asks the sales representative what kinds of inventory information he needs, including when and where he needs to access this information. Using a graphical, object-oriented development tool, such as Microsoft Visual Basic, the analyst quickly builds several sample interface displays.

Using Prototyping During Requirements Determination (Cont.) Most useful when:

User requests are not clear.Few users are involved in the system.Designs are complex and require

concrete form.History of communication problems

between analysts and users.Tools are readily available to build

prototype.

Joint Application Design (JAD)

Structured process involving users, analysts, and managers.

Several-day intensive workgroup sessions.

Purpose: to specify or review system requirements.

Merits $ Demerits JAD is better than traditional techniques

because we could have all key personnel in one place at one time, saving everyone time and resulting in high levels of system ownership as more people have more of a role in the development process.

Weaknesses include the level of commitment necessary to make the JAD work, the high degree of required planning, and the typical lack of computer support.

Nominal Group Technique (NGT)

A facilitated process that supports idea generation by groups.

ProcessMembers come together as a group, but

initially work separately.Each person writes ideas.Facilitator reads ideas out loud, and they are

written on a blackboard or flipchart.

Nominal Group Technique (NGT)

Group openly discusses the ideas for clarification.

Ideas are prioritized, combined, selected, reduced.

NGT exercise used to complement group meetings or as part of JAD effort.

How can NGT be used for requirement determinations ? The Nominal Group Technique(NGT) is a

facilitated process that supports idea generation by groups. NGT encourages individuals to identify and prioritize problems with an existing system or requirements for a new system.

Choosing Interview Questions

Each question in an interview guide can include both verbal and non-verbal information.Open-ended questions: questions that have

no prespecified answers.Closed-ended questions: questions that ask

those responding to choose from among a set of specified responses.

Interviewing Groups

Drawbacks to individual interviewsContradictions and inconsistencies between

interviewees.Follow-up discussions are time consuming.New interviews may reveal new questions that

require additional interviews with those interviewed earlier.

Chapter 6

Interviewing Groups (Cont.)

Interview several key people together Advantages

More effective use of time. Can hear agreements and disagreements at once. Opportunity for synergies.

Disadvantages More difficult to schedule than individual interviews.

Assessing Project Feasibility

Economic Technical Operational Scheduling Legal and contractual Political

Assessing Project Feasibility (Cont.) Economic feasibility: a process of

identifying the financial benefits and costs associated with a development project.Often referred to as cost-benefit analysis.Project is reviewed after each SDLC phase in

order to decide whether to continue, redirect, or kill a project.

Determining Project Costs (Cont.)

Both one-time and recurring costs can consist of items that are fixed or variable in nature.

Fixed costs are billed or incurred at a regular interval and usually at a fixed rate.

Variable costs are items that vary in relation to usage.

Determining Project Costs (Cont.) Procurement

Consulting, equipment, site preparation, capital, management time

Start-up Operating systems, communications installation,

personnel hiring, organizational disruption Project-related

Application software, software modification, personnel overhead, training, data analysis, documentation

Operating System maintenance, rental, asset depreciation,

operation and planning

The Time Value of Money Net Present Value (NPV)

Use discount rate to determine present value of cash outlays and receipts

Return on Investment (ROI)Ratio of cash receipts to cash outlays

Break-Even Analysis (BEA)Amount of time required for cumulative

cash flow to equal initial and ongoing investment

The Time Value of Money

Time value of money (TVM): the concept that money available today is worth more than the same amount tomorrow.

Discount rate: the rate of return used to compute the present value of future cash flows (the cost of capital).

Present value: the current value of a future cash flow

The Time Value of Money (Cont.)

Net Present ValuePVn = present value of Y dollars n years from

now based on a discount rate of i.NPV = sum of PVs across years.Calculates time value of money.

Assessing Technical Feasibility

Technical feasibility: a process of assessing the development organization’s ability to construct a proposed system.

Assessing Technical Feasibility

The potential consequences of not assessing and managing risks can include the following: Failure to attain expected benefits from the project, Inaccurate project cost estimates, Inaccurate project duration estimates, Failure to achieve adequate system performance

levels, and Failure to adequately integrate the new system with

existing hardware, software, or organizational procedures.

Assessing Technical Feasibility (Cont.) Risk can be managed on a project by:

Changing the project plan to avoid risky factors,

Assigning project team members to carefully manage the risky aspects,

Setting up monitoring methods to determine whether or not potential risk is, in fact, materializing.

Assessing Technical Feasibility (Cont.) The four primary factors associated with the

amount of technical risk on a given project are: Project size, Project structure, The development group’s experience with the

application and technology area, and The user group’s experience with systems

development projects and the application area (see also Kirsch, 2000).

Assessing Technical Feasibility (Cont.) Four general rules emerged as technical

risk assessments:Larger projects are riskier than smaller

projects.A system in which the requirements are easily

obtained and highly structured will be less risky than one in which requirements are messy, ill structured, ill defined, or subject to the judgment of an individual.

Assessing Technical Feasibility (Cont.) The development of a system employing

commonly used or standard technology will be less risky than one employing novel or nonstandard technology.

A project is less risky when the user group is familiar with the familiar with the systems development process and application area than if unfamiliar.

Network Diagram

Activity Time(week

Immediate Predecessors

EarlyFinish

LateFinish

CriticalPath

Collect requirements

2 -- 2 2 Yes

Analyze processes 3 1 5 5 Yes

Analyze data 3 2 8 12 No

Design processes 7 2 12 12 Yes

Design data 6 2 11 12 No

Design Screen 1 3, 4 13 17 No

Design reports 5 4, 5 17 17 Yes

Program 4 6, 7 21 25 No

Test and document 8 7 25 25 Yes

Installation 2 8, 9 27 27 Yes

common web site design errors Nonstandard use of GUI widgets, Anything that looks like advertising,

bleeding-edge technology, Scrolling test and looping animations, Nonstandard link colors, Outdated information, Slow download times, Fixed-formatted text, and displaying long

lists as long pages.

Four approaches for Implementation strategies With direct approach, the old system is turned off, and

the new one is turned on. In the parallel approach, both systems are run until

management decides the old system can be turned off. In single location, the system is tried out in a pilot

project at one location and then implemented elsewhere if the pilot is successful.

With the phased approach, the new system is brought online gradually, usually function by function.

-Parallel is usually the most expensive due to the redundant costs, and direct is usually the most risky due to the potential hazards if the new system fails. An organization decides on which approach to use depending on the scope and complexity of the change and the organization’s risk aversion.

Lucas Model of Implementation Success Lucas identified two methods for determining if an

implementation has been successful: the user’s satisfaction with the system and the extent to which the system is used.

Lucas further identified six factors that influence the extent to which a system is used; these are user’s personal stake, system characteristics, user demographics, organization support, performance, and satisfaction.

Following Figure illustrates the relationships these factors have to each other. An analyst will have more control over certain factors (system characteristics and level of support); however, the analyst will not have direct control over the demographics of the user, personal stake in the system, management support, or problem urgency.

This model points out that the analyst should balance the factors.

figure

Documenting the System-System doc. VS User doc. System documentation is the detailed

information about a system’s design specifications, its internal workings, and its functionality, whereas user documentation consists of written or other visual information about an application system, how it works, and how to use it.

Revision Modern Systems Analysis and Design. © 2008 by Prentice Hall 2 Chapter 3 Managing the...

Documents

© Prentice Hall 2002 6.1 CHAPTER 6 Managerial Support Systems

Copyright 2002 Prentice-Hall, Inc. Chapter 3 Managing the Information Systems Project 3.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer

Slide 1 © 2008 Prentice-Hall, Inc.. Systems Design and Development Slide 2 © 2008 Prentice-Hall, Inc

13.1 © 2010 by Prentice Hall 13 Chapter Building Information Systems

Stability Analysis of Nonlinear Systems Using Lyapunov ... 31.pdf · Nonlinear Control, Prentice Hall, 1991. zH. K. Khalil: Nonlinear Systems, Prentice Hall, 1996. ADVANCED CONTROL

© 2008 Prentice Hall8-1 Introduction to Project Management Chapter 8 Managing Project Quality Information Systems Project Management: A Process and Team

© Prentice Hall 2002 8.1 CHAPTER 8 Basic Information Systems Concepts

Prentice Hall, 2003 Prentice Hall, 2002 Chapter 2 Succeeding as a Systems Analyst 2.1 Modern Systems Analysis and Design

Chapter 5: Energy-Tapping Pulsed Systems - Tuks€¦ · · 2012-03-23Chapter 5: Energy-Tapping Pulsed Systems ... Frank Prentice. Electrical Engineer Frank Wyatt Prentice of the

8.1 © 2007 by Prentice Hall 8 Chapter Securing Information Systems

8.1 © 2010 by Prentice Hall 8 Chapter Securing Information Systems

Multiple Processor Systems Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall

© 2008 Prentice Hall6-1 Introduction to Project Management Chapter 6 Managing Project Scheduling Information Systems Project Management: A Process and

© 2006 Prentice Hall, Inc.16 – 1 Operations Management Just-in-Time and Lean Production Systems Just-in-Time and Lean Production Systems © 2006 Prentice

© 2008 Prentice Hall12-1 Introduction to Project Management Chapter 12 Managing Project Control and Closure Information Systems Project Management: A Process

Alter – Information Systems © 2002 Prentice Hall 1 Networks and Telecommunications

Signals and systems,2ed a.v.oppenheim,a.s.willsky,prentice hall

©2008 Pearson Prentice Hall Project Management Systems Analysis and Design, 7e Kendall & Kendall 3

15.1 © 2010 by Prentice Hall 15 Chapter Managing Global Systems

© Prentice Hall 2002 5.1 CHAPTER 5 Organizational Systems