Top Banner
Systems Development I— Overview Ken Peffers UNLV March 2004
29
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Systems Development I—Overview

Ken Peffers UNLV March 2004

Page 2: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Responsibility of systems analysts and designers

• Technical quality of IS– timeliness– efficiency– accuracy

• Impact on the organization– effect on organizational

conflict– effect on decision making

Page 3: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Responsibility of systems analysts and designers

• User interface– allows user to interact with

system

• Process of design and implementation

Page 4: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Who is involved?

• Senior managers– strategic direction– funding – support/leadership

• Professionals– legal– procurement

Page 5: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Who is involved?

• Middle managers– access to people– support for analysis– Management control over the

project team

• Supervisory– Process information– Decision making detail

• Workers– task detail

Page 6: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

The management of development

• Corporate strategic planning group– Responsible for achievement of

broad corporate objectives

• IT steering committee– Reviews and approves plans for IT

projects, consistent with strategic plans

• Project team– Responsible for implementing

system

Page 7: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

The project team

• Systems analysts• Functional analysts• Application programmers• DB specialists• Communications

specialists

Page 8: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

The project team

Also...• Legal• Behavioral• Trainers• Plant and Equipment• Procurement

Page 9: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Steps in the SDLC Method

• Feasibility Study– Output: Project Proposal

• Systems Analysis– Output: Requirements

Specifications

• Systems Design– Output: Coding, database,

communications specifications, documentation, procedures

Page 10: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Steps in the SDLC Method

• Acceptance Testing– Output: testing

documentation

• Conversion– Output: working production

system

• Post implementation audit– Output: audit report

Page 11: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Waterfall Method

System R

equest

FeasibilityStudy

ProjectProposal

SystemsAnalysis

Requirem

entsD

ocument Desig

n

Coding, database,

comm

unications specifications, docum

entation, proceduresConversion

Testing W

orking System

Testing

Docum

entation PostImplementationAudit

Audit R

eport

The SDLC is also calledthe Waterfall Method

Why?

Every stage has a definite output. Why?

What is a sign off? Why is it done?

Page 12: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Feasibility study

• Problem definition– The nature of the problem– Scope– Objectives

Page 13: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Feasibility study

• Evaluation of feasibility– Technical—Can it be done?– Implementation—Can we do it?– Economic—Is it worth the cost?– Financial—Can we manage the cost?– Strategic—Is it what we should be

doing?– Operational—Is it desirable within

managerial/organizational framework?

Page 14: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Project Proposal Output from feasibility study

• Project overview• Problem definition• Findings, expected

benefits, recommendations• Costs, schedules, personnel

Page 15: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Systems Analysis Objectives

• Define Project Objectives• Identify operation and

problems of existing system• Identify requirements and

objectives of new system• identify requirements for

organizational change

Page 16: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Analysis

• Data gathering—what is done, how, data flows– documents– observation – questionnaires– interviews

Page 17: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Analysis

• Information Requirements Determination– Polling—assumes managers know– Data analysis of files, reports, etc...– Prototyping—develop requirements from

system use– Object systems analysis from conceptual

model

• Cost benefit analysis

Page 18: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Analysis-Data

• Data modeling--ER diagrams• Activity modeling—Data flow

diagrams– How data flows through the

organization• Flowcharts

– Show the flow of decisions and actions through a process.

Page 19: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Analysis—requirements

• Define inputs and outputs• Define processing—

functionally• Storyboarding

– Screen and reports– Consider every user action

and consequence

Page 20: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Requirements document

• Project overview• Problem definition• Requirements• Benefits• Description of current

system• Cost, schedules,

personnel

Page 21: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

The Skills Required By Systems Analysts

• Interpersonal skills• Communication skills• Presentation skills• Analytical and

problem solving skills• Business knowledge• Technical skills

Page 22: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Systems Design

• Devise detailed system solution

• Deliver functions required by users

• Manage implementation

Page 23: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Systems Design

• Preliminary– Conceptual design—logical– Physical design—Specifications

for hardware/software

Page 24: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Systems Design

• Detailed Design– Outputs– Inputs– Processing – Database– Procedures– Controls

• Role of users in design– Design should reflect business

objectives, not biases of professionals

Page 25: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Acceptance Testing

• program testing • system testing • user testing • auditor should check test

documentation planning / test data design / what test data / results / actions taken as a result of errors /

Page 26: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Conversion (Implementation)

• Parallel—expensive• Direct cutover—risky• Pilot study—limit use to one

area• Phased approach—in stages

by function or work unit

Page 27: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Post Implementation Audit

• Compare actual implementation time and cost to schedules and budgets

• Compare actual operating costs to estimates

• Review operations, documentation, security, controls

• Modify system as necessary

Page 28: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Dangers Of An Ad Hoc Approach

• The completed system is not what the users want

• The customers do not use the system.

• There is much conflict in the development of the system.

• Resources are wasted.

Page 29: Systems Development I—Overview Ken PeffersUNLVMarch 2004.

Dangers of an Ad Hoc Approach

• People may have to work harder than needed.

• The system does not produce the right information.

• The system is not finished on time.

• The developers get a bad reputation.