+ All Categories
Home > Documents > Systems development fall 2006

Systems development fall 2006

Date post: 22-Nov-2014
Category:
Upload: eeetq
View: 314 times
Download: 0 times
Share this document with a friend
Description:
 
67
Systems Development MIS 503 Management Information Systems MBA Program
Transcript
Page 1: Systems development   fall 2006

Systems Development

MIS 503Management Information Systems

MBA Program

Page 2: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 385

Systems development life cycle (SDLC) – a highly structured approach for development of new customized software applications

Page 3: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 393

The SDLC Project Team

• Usually temporary• Includes personnel from IS and business units• Has a project manager

– Traditionally from IS– Can be from business unit– May be one from each– Responsible for success of project – delivering quality

system on time and within budget

Page 4: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 394

The SDLC Project Team

• Includes systems analysts – Have critical roles– Work closely with business managers and end

users– Have problem-solving skills, knowledge of IT

capabilities, strong business understanding

• Has a business sponsor and a champion

Page 5: Systems development   fall 2006

Managing Change

• The ability to manage change is critical to the success of systems development. – The new or modified systems created

during systems development will inevitably cause change.

– Managing change requires the ability to recognize existing or potential problems.

Page 6: Systems development   fall 2006

There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new information system. For the initiator has the enmity of all who would profit from the preservation of the old system and merely luke warm defenders in those who would gain from the new one.

Significant Quote

Page 7: Systems development   fall 2006

Establishing Objectives for Systems Development

• Systems development objectives should be supportive of, and aligned with, organizational goals.

• There are four kinds of objectives that should be considered:– Performance objectives.

– Cost objectives.

– Control objectives.

– Complexity objectives.

Page 8: Systems development   fall 2006

Systems Development Methodologies

• A key factor in completing a successful systems development project is to adopt a methodology.

• A methodology is a way of doing things.

Page 9: Systems development   fall 2006

• A systems development methodology is an assortment of rules and standards that govern the approach taken to all tasks associated with systems development.

• In structured systems development the systems development tasks are broken down into small, easily managed parts.

Systems Development Methodologies

Page 10: Systems development   fall 2006

• Top-down design means the entire system can be viewed as a layered set of descriptions, each of which could be decomposed, or “peeled back,” to reveal more detailed specifications for smaller parts of the system.

Systems Development Methodologies

Page 11: Systems development   fall 2006

Structured Walkthrough

• A structured walkthrough is a planned and pre-announced review of the progress of a particular project deliverable--a specific project outcome, a structure chart, or a human procedure.

• The walkthrough helps team members review and evaluate the program of components of a structured project.

Page 12: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 386

The SDLC Steps

Figure 10.1 The Systems Development Life Cycle

Key characteristic is extensive formal reviews

required at end of each major step

Page 13: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 386

The SDLC Steps

Figure 10.2 Cost Breakdown for $1 Million SDLC Project

Hallmark of SDLC approach: extensive up-front time spent

determining requirements to avoid expensive changes later

Page 14: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 386

The SDLC Steps

SDLC:– Most often requires a lot of

documentation– Outputs from one step inputs to next– Often referred to as the “waterfall” model

Page 15: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 387-388

Definition Phase – Feasibility Analysis• Types of feasibility – economic, operational, and

technical• Deliverable – 10-20 page document:

– Executive overview and recommendations– Description of what system would do and how it would

operate– Analysis of costs and benefits– Development plan

Page 16: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 388

Definition Phase – Requirements Definition

• Focuses on logical design: processes, data flows, and data interrelationships – not specific physical implementation

• Deliverable – system requirements document: – Detailed descriptions of inputs and outputs, processes used

to convert input data to outputs– Formal diagrams and output layouts– Revised cost/benefit analysis – Revised plan for remainder of project

Page 17: Systems development   fall 2006

Brook’s Law:

Adding manpower to a late software project makes it later!

(Frederick P Brooks Jr.)

Significant Quote

Hofstadter's Law: It always takes longer than you think, even when you take Hofstadter's Law into account.

(Douglas Hofstadter)

Page 18: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 389

Construction Phase

• System Design

• System Building

• System Testing

Figure 10.3 Characteristics of High Quality Systems

Documentation is a major mechanism of

communication during development process

Page 19: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 390

Implementation Phase

• Installation

• Operations

• Maintenance

Page 20: Systems development   fall 2006

Page 391

Implementation Phase – Installation

Figure 10.4 Implementation Strategies

Parallel Strategy

Parallel Strategy

Parallel Strategy

Parallel Strategy

Page 21: Systems development   fall 2006

Page 392

Implementation Phase – Maintenance

Figure 10.5 Percent of Development Resources Devoted to Maintenance

Page 22: Systems development   fall 2006

Page 392

Implementation Phase – Maintenance

Figure 10.6 The Widening Gap BetweenOrganization’s Needs and System’s Performance

Page 23: Systems development   fall 2006

Bove’s Theorem:

The remaining work to finish in order to reach your goal increases as the deadline approaches.

Significant Quote

Walking on water and developing software from a specification are easy if both are frozen.

(Edward V Berard)

Page 24: Systems development   fall 2006

SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY

Page 395

SDLC Advantages and Disadvantages

Figure 10.8 Advantages and Disadvantages of Traditional SDLC Approach

Page 25: Systems development   fall 2006

Deadline Dan’s Demon:

Every task takes twice as long as you think it will take. If you double the time you think it will take, it will actually take four times as long.

Meskimens Law

There is never time to do it right, but there is always time to do it over

Significant Quote

Page 26: Systems development   fall 2006

Causes of Maintenance

• Some major causes of program maintenance are:– New requests from stakeholders,

users, and managers.– Bugs or errors in the program.– Technical and hardware problems.– Corporate mergers and acquisitions.– Governmental regulations.

Page 27: Systems development   fall 2006

Significant Quote

Nixons Law

The man who can smile when things go wrong has thought of someone to blame.

Flon's axiom

There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs.

(Lawrence Flon)

Page 28: Systems development   fall 2006

Trends in Systems Development

Page 29: Systems development   fall 2006

Operational and Rapid Prototyping

• An operational prototype is a prototype that works.

• A partially operational prototype has some components that are operational.

• A rapid prototype allows system stakeholders and users to see a mockup of the subsystem much faster, which enables earlier changes.

Page 30: Systems development   fall 2006

Page 396

• Prototyping approach:– Takes advantage of availability of fourth generation

procedural languages and relational database management systems

– Enables creation of system (or part of system) more quickly, then revise after users have tried it

– Is a type of evolutionary development process

PROTOTYPING METHODOLOGY

Page 31: Systems development   fall 2006

Page 396

• Prototyping examples:

– Input and output screens developed for users to test as part of requirements definition

– “First-of-a-series” – a completely operational prototype used as a pilot

– “Selected features” – only some essential features included in prototype, more added later

– Prototyping used as a complete alternative to traditional SDLC methodology

PROTOTYPING METHODOLOGY

Page 32: Systems development   fall 2006

Page 396

• Prototyping used as a complete alternative to traditional SDLC methodology:

– Good when requirements hard to define

– Good when system needed quickly

– Impractical for large, complex applications

PROTOTYPING METHODOLOGY

Page 33: Systems development   fall 2006

Page 397

The Prototyping Steps

Figure 10.9 The Prototyping Life Cycle

Page 34: Systems development   fall 2006

Page 398-399

• Advantages:

– Only basic requirements needed at front end

– Used to develop systems that radically change how work is done, so users can evaluate

– Allows firms to explore use of new technology

– Working system available for testing more quickly

– Less strong top-down commitment needed at front end

– Costs and benefits can be derived after experience with initial prototype

– Initial user acceptance likely higher

Prototyping Advantages and Disadvantages

PROTOTYPING METHODOLOGY

Page 35: Systems development   fall 2006

Page 399

• Disadvantages:

– End prototype often lacks security and control features

– May not undergo as rigorous testing

– Final documentation may be less complete

– More difficult to manage user expectations

Prototyping Advantages and Disadvantages

PROTOTYPING METHODOLOGY

Page 36: Systems development   fall 2006

PROTOTYPING METHODOLOGY

Page 399

Prototyping within an SDLC Process

Figure 10.10 SDLC with Prototyping to Define Requirements

Page 37: Systems development   fall 2006

PROTOTYPING METHODOLOGY

Page 399

Prototyping within an SDLC Process

Figure 10.11 Prototyping/Piloting Replaces SDLC Definition Phase

Page 38: Systems development   fall 2006

NEWER APPROACHES

Page 400

Rapid Application Development (RAD)

Figure 10.12 Four-Step RAD Cycle

• Hybrid methodology – aspects of SDLC and prototyping

• Goal is to produce a system in less than a year

Page 39: Systems development   fall 2006

NEWER APPROACHES

Page 400-401

Rapid Application Development (RAD)

Joint application design (JAD) – a technique in which a team of users and IS specialists engage in an intense and structured process in order to minimize the total time required for gathering information from multiple participants

Page 40: Systems development   fall 2006

NEWER APPROACHES

Page 400-401

Rapid Application Development (RAD)

Joint application design (JAD) – a technique in which a team of users and IS specialists engage in an intense and structured process in order to minimize the total time required for gathering information from multiple participants

Computer-aided software engineering (CASE) – any software tool used to automate one or more steps of a software development methodology

Page 41: Systems development   fall 2006

NEWER APPROACHES

Page 401

Rapid Application Development (RAD)

Figure 10.13 Types of CASE Tools

(Adapted from Valacich, George, and Hoffer, 2001)

Page 42: Systems development   fall 2006

NEWER APPROACHES

Page 402

Rapid Application Development (RAD)

Figure 10.14 RAD Advantages and Disadvantages

Page 43: Systems development   fall 2006

NEWER APPROACHES

Page 402

Agile Software Development Discipline

• Alternative methodology for smaller projects• Based on four key values:

– Simplicity– Communication– Feedback – Courage

• One type: Extreme Programming (XP)– Programmers write code in pairs– Use simple design and frequent testing

Page 44: Systems development   fall 2006

THE MAKE-OR-BUY DECISION

Page 406

• Decision should be made jointly by business managers and IS professionals

• Advantages of purchasing:– Cost savings

– Faster speed of implementation

• Disadvantages of purchasing:– Seldom exactly fits a company’s needs

– Often forces trade-offs

Page 45: Systems development   fall 2006

PURCHASING METHODOLOGY

Page 407

The Purchasing Steps

Figure 11.1 The Purchasing Process

Page 46: Systems development   fall 2006

Page 407

Initiating the Purchasing Process

Figure 11.2 Comparison of Costs and Building vs. Purchasing a System

PURCHASING METHODOLOGY

Page 47: Systems development   fall 2006

Page 408

Establish Criteria for Selection

Figure 11.3 Key Criteria for Software Package Selection

PURCHASING METHODOLOGY

Page 48: Systems development   fall 2006

Page 409

Develop and Distribute the RFP

Request for proposal (RFP) – a formal document sent to potential vendors inviting them to submit a proposal describing their software package and how it would meet the company’s needs

PURCHASING METHODOLOGY

Page 49: Systems development   fall 2006

Page 410-411

• Evaluation steps:– Review vendors’ responses from RFPs– Request demonstrations of leading packages– Request references from users of software packages in other companies– Assess how well package capabilities satisfy company’s needs– Understand extent of any additional development efforts or costs to tailor

software– Make decision

Evaluate Vendor Responses to RFP and Choose Package

PURCHASING METHODOLOGY

Page 50: Systems development   fall 2006

Page 411

Evaluate Vendor Responses to RFP and Choose Package

Figure 11.6 Matching Company Needs with Capabilities of the Package

PURCHASING METHODOLOGY

Page 51: Systems development   fall 2006

Page 413

• If no software package modifications required:– Skip system design and building steps– Move directly to system testing– Develop any necessary process changes

• If software package is modified:– Consider contracting with vendor or a third party for changes versus

modifying in-house– Determine if changes are required to other existing company systems

Construction Phase

PURCHASING METHODOLOGY

Page 52: Systems development   fall 2006

Page 414-415

– Business managers and users– IS professionals– Project manager – usually a business manager– Software vendor personnel– Sometimes includes a third-party implementation partner– Purchasing specialists– Attorneys

Project Team for Purchasing Packages

PURCHASING METHODOLOGY

Page 53: Systems development   fall 2006

Page 416

Purchasing Advantages and Disadvantages

Figure 11.7 Advantages and Disadvantages of Purchasing Packaged Software

PURCHASING METHODOLOGY

Page 54: Systems development   fall 2006

Page 418

NEW PURCHASING OPTION: APPLICATION SERVICE PROVIDERS (ASPs)

• New trend beginning 2000s• Purchasing option: purchaser elects to use a “hosted” application rather than to

purchase the software application and host it on its own equipment• ASP is an ongoing service provider• Company pays third party (ASP) for delivering the software functionality over the

Internet to company employees and sometimes business partners

Page 55: Systems development   fall 2006

Page 418-419

NEW PURCHASING OPTION: APPLICATION SERVICE PROVIDERS (ASPs)

• Some advantages:– Cost savings and faster speed of implementation– Usually involves monthly fees rather than large infrastructure investment

• Disadvantages:– Dependence on an external vendor for both software and ongoing operations– Good assessment of required service levels even more critical

Page 56: Systems development   fall 2006

Potential Problems for Systems Development

• Solving the wrong problem.

• Poor problem definition and analysis.

• Poor communication.

• A project that is too ambitious.

• A lack of top management support.

• A lack of management and user involvement.

Page 57: Systems development   fall 2006

• Failure to use a standard systems development approach.

• Inadequate or improper systems design.

• Poor testing and implementation.

• A lack of concern for maintenance.

Potential Problems for Systems Development

Page 58: Systems development   fall 2006

Success Factors in Systems Development

• Clearly defined organizational goals.• A sharp focus on, and clear understanding of, the most

important business problems or opportunities.• Clearly defined systems development objectives.• Support of top-level managers. Involvement of users at all

stages.• Use of a proven systems development method.• Creating or aligning incremental systems benefits with

normal user work activities so as to provide incentives for effective system interaction.

• Managing change.• A simple and straightforward design.• Good training programs for all involved.

Page 59: Systems development   fall 2006

Global Sourcing

• The process of deciding where in the world a firm’s activities will be performed and who will perform the activities.– Fundamentally any activities that does

not require direct customer contact, extensive local knowledge, or complex interactions can be sourced anywhere

Page 60: Systems development   fall 2006

Global Resourcing

Page 61: Systems development   fall 2006

Outshoring and Outsourcing

Page 62: Systems development   fall 2006

Definition of Outsourcing

• IS outsourcing is the commissioning of part or all of the IS activities an organization needs, and/or transferring the associated human and other IS resources, to one or more external IS suppliers

• IS Offshoring is the commissioning of part or all of the IS activities an organization needs to one or more other countries

• IS Insourcing is the sourcing of a business function within the firm (e.g., Kingland Systems)

Page 63: Systems development   fall 2006

IS Outsourcing

• Four Types of Outsourcing Relationships: Support Reliance Alignment Alliance

Page 64: Systems development   fall 2006

Outsourcing Grid

Reliance Alliance

Support Alignment

Strategic Impact of IS ApplicationsExt

ent o

f S

ubst

itut

ion

by V

endo

rs

High

High

Low

Low

Page 65: Systems development   fall 2006

Outsourcing Decision Variables

• Relationships

• Division Among Suppliers and Contracts

• Management Structure

• Operational Structure

• Internal Organization of Outsourcing Coordination

Page 66: Systems development   fall 2006

Horizontal and Vertical Integration

• Diversification - increasing the number of products and services

• Differentiation - aka ‘disintegration’ - decreasing the number of subsequent phases in the production chain

• Specialization - reducing the number of products and services

• Integration - performing a larger number of phases in the production chain

Page 67: Systems development   fall 2006

Backward Vertical Disintegration

• Car manufacturer purchasing pre-assembled engines instead of purchasing and assembling the component parts themselves

• Decreasing the number of phases a firm performs by commissioning another entity within the production chain to perform those functions


Recommended