Systems Development I—Overview

Ken Peffers UNLV March 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

Responsibility of systems analysts and designers

• User interface– allows user to interact with

system

• Process of design and implementation

Who is involved?

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

• Professionals– legal– procurement

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

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

The project team

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

specialists

The project team

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

Steps in the SDLC Method

• Feasibility Study– Output: Project Proposal

• Systems Analysis– Output: Requirements

Specifications

• Systems Design– Output: Coding, database,

communications specifications, documentation, procedures

Steps in the SDLC Method

• Acceptance Testing– Output: testing

documentation

• Conversion– Output: working production

system

• Post implementation audit– Output: audit report

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?

Feasibility study

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

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?

Project Proposal Output from feasibility study

• Project overview• Problem definition• Findings, expected

benefits, recommendations• Costs, schedules, personnel

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

Analysis

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

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

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.

Analysis—requirements

• Define inputs and outputs• Define processing—

functionally• Storyboarding

– Screen and reports– Consider every user action

and consequence

Requirements document

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

system• Cost, schedules,

personnel

The Skills Required By Systems Analysts

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

problem solving skills• Business knowledge• Technical skills

Systems Design

• Devise detailed system solution

• Deliver functions required by users

• Manage implementation

Systems Design

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

for hardware/software

Systems Design

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

• Role of users in design– Design should reflect business

objectives, not biases of professionals

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 /

Conversion (Implementation)

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

area• Phased approach—in stages

by function or work unit

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

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.

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.