Systems Development Life Cycle (SDLC)

Feasibility Study

Requirements

Analysis

Requirements

Specification

Logical System

Specification

Physical Design

S

S

A

D

M

Stra tegy

Planning

Implementation

Maintenance

Feasibility

Analysis

Design

Structured Methodologies

Structured methods consist of three basic elements:

A default structure of steps and tasks which the project team should consider following.

A set of techniques to be applied in each step that provide (largely diagrammatic) structured definitions of user requirements and system components.

A set of products developed by each of the techniques.

Features:

Rigorous “top down” analysis of user requirements

Project Management

Communication and consistency

Lower LIFETIME costs

Documentation

Widely understood and adopted

Flexible and adaptable

Information Systems (database) specific

Require careful planning and customisation

Other Methodologies

Object Oriented Development

Suited to process oriented systems implemented in OO

environment

“systems that are strongly database-oriented……are not ideally

suited to object oriented development” - Bennett, McRobb & Farmer

Requires high level of expertise

Often used for customisable packages (e.g. SAP)

RAD

Iterative development

Process and user expectations must be carefully handled

Can be used in conjunction with Structured Methods

Particularly suited to small projects and user interface

development

DSDM

3-Schema Architecture

External Design Conceptual Model Physical/Internal

Design

Su

ppli

er

Pro

2

6

2

7

2

8

2

9

Pu

rc

ha

se

Or

1 2 3

S

e

t

o

f

Purc

hase

Ord

er

Item

Purc

has

e

Ord

1

9

2

0

2

1

2

2

Product

Purchase Order

Purchase Order

Line

Supplier

Supplier's Product

Proc

ess

Purc

ha-

se

Ord

er

Que

ry

Pr

oc

es

s

S

up

pli

er

1 2 3 4

Pro

ces

s

Set

of

Purc

has

e

Ord

er

Pr

oc

es

s

Purc

has

e

Ord

er 4

Pro

ces

s

Nex

t

P.O

.

Physical

Data

Storage

FCIM

PDI User and System

Interfaces

LDM

ECDs

ELHs

UPMs

etc

Systems Development Template

Investigation

External DesignConceptual Model

Internal Design

Specification

Construction

Basic SSADM Concepts

Separation of Logical and Physical

Physical or historical constraints

Implementation independence

Re-use

The Three Views of SSADM

Data

Processing

Events (Time)

CASE Tools

The claims made in their favour by suppliers are often

exaggerated, but most will provide a mix of the following

features:

Diagramming tools

Diagram validation

Automatic generation of first-cut low level diagrams

Report production

Code generation

Getting Started

Learning Outcomes:

Assemble a Project Initiation Document;

Understand the need for and application of Project Management

principles;

Assess the technical, operational and financial feasibility of a

project.

Why Projects Fail

Lack of business wide understanding of and commitment

to the project;

Lack of clearly defined objectives, deliverables and

success criteria;

Lack of ownership or sponsorship within the business;

Problems establishing the right project team;

Plans that are too optimistic and lack contingency;

Poor day-to-day management of issues and control of

project tasks;

Lack of awareness of change management and business

impact issues;

Lack of focus on project goals and milestones;

Poor understanding of risks and project dependencies.

Project Initiation

Define objectives, deliverables and scope of project;

Establish a sound financial business case for the project;

Assess costs and business benefits;

Agree plans, resources and organisation for the project;

Establish key risks and success criteria;

Formalise controls and reporting lines.

Project Management

Three components: Planning

Controls

Organisation

Planning 1. Break the project into a number of stages or phases (e.g. project

initiation, feasibility study, analysis, testing).

2. Identify the activities to be undertaken in each phase.

3. Break down the activities in the first stage into a detailed task list.

4. Estimate effort required to complete each task or activity.

5. Assign resources to each task and activity.

6. Schedule the project.

Gantt

Chart:

Project Controls

While no project is helped by unnecessary bureaucracy,

there are some formal controls that are invaluable in

ensuring that a project is effectively managed, regardless

project size:

Progress Reports

Project Issues

Change Control

Risk Log

Project Organisation

A well-defined project structure ensures that the right

people are involved in the project and that roles

responsibilities are clearly defined.

Key Roles:

Project Manager

Project Sponsor

User Representation

Project Board

Note

On student projects the role of the Project Sponsor will be undertaken by a representative of the

organisation that will be the recipient of the final deliverable(s). In addition there will be an academic

Supervisor who will act as a co-sponsor, and is responsible for both the mentoring of the Project

Manager (student) and agreeing the academic objectives of the project.

Feasibility Study

Feasibility assessment is an activity that can take many forms, varying from an informal study carried out as part of strategy planning or project initiation, to a high level systems analysis “mini project”, depending on the size or complexity of overall project.

The basic questions to be answered in any kind of feasibility study are:

Is there a computer solution to the given business problem?

Is the solution justifiable in business terms, both organisationally and financially? For example:

• Will benefits outweigh costs?

• Will the proposed solution be politically acceptable?

• Can the solution be developed in time?

• Can the level of change associated with the system be absorbed at this time?

• Are the skills in place and the people available to develop and manage the system?

• Is the risk of project failure acceptable to the organisation?

Feasibility Study (continued)

There are several points in the life cycle where a decision to drop the

project might be made. The Feasibility Study provides easily the most cost

effective point to do so.

Whether an informal approach or an SSADM Feasibility Study is

undertaken, the basic steps we go through will be the same:

1. Define the business problem to be solved;

Assemble Feasibility

Report

Select Feasibility

Option

Project Definition Statement

Feasibility Report

Action Plan Feasibility Options

Define the Problem

Strategy Planning

2. Develop high-level alternatives (or

“options”) for its solution; 3. Assess the feasibility of the options

and select options for discussion with

the Project Board; 4. Make recommendations to and

document the decision of the Project

Board;

5. Develop action plan for further analysis

and subsequent development of the

chosen option.

SSADM Feasibility Products

Problem Definition Statement

A Problem Definition Statement provides a textual summary of

requirements and their relative priority. It should include

references to formal SSADM products (which it does not replace

but merely supplements), and should include a list of the

minimum requirements.

We should attempt to be efficient and methodical by using the

PID to identify the major functional areas that the system will be

required to support, and using these as a checklist of high level

processes to be covered by the overview DFD.

Feasibility Options

Feasibility Options

At the centre of a Feasibility Option is a high level combination of

two standard SSADM products:

Business System Option (BSO). A BSO defines the functional

scope of a proposed solution. At its most basic level it consists of

textual descriptions of those requirements satisfied by the

solution. All BSOs must satisfy the minimum requirement as

identified by user representatives.

Technical Systems Option (TSO). A TSO defines a possible

technical environment for the implementation of the system. It will

include descriptions of hardware and software, technical support

arrangements, distribution of the system and development tools.

Feasibility Options (continued)

Feasibility Options (continued)

Functional support. Textual descriptions can be supplemented with process and data models showing the subset of functional requirements covered by the option.

Costs. These will be very approximate and must include: hardware; software; human resources; consultancy; training; together with maintenance and running costs (which are frequently higher than the development costs).

Benefits. Including financial benefits (e.g. increased profits or reduced costs), strategic benefits (i.e. the meeting of strategic business objectives), removal of problems (e.g. capacity constraints) etc.

Organisational Impact Analysis. Again this will be at a high level, and will describe the cultural and operational changes associated with the option.

Development approach and approximate timings.

• Is SSADM the most suitable method for developing the option? If not, what method should be used?

• How many projects are necessary? If the proposed system is large or complex, a phased approach may be best;

• Who will develop the option? Possibilities include in-house project teams, contractors, software houses, package vendors, etc.

Tips on presenting options will be given in Lecture 7 (Business System Options).

Assessing Financial Feasibility

Financial feasibility has two key elements:

Are funds are available for the solution to be developed and

maintained?

Is there a positive balance of costs and benefits over time?

Cost Benefit Analysis

Financial costs are usually easier to estimate than the financial

benefits.

For example a system may claim to improve the decision making of

a set of employees, but measuring the increased profits generated

directly by that improvement might well prove impossible.

There are a number of methods for assessing cost benefits,

including Return on Investment and Payback Periods as outlined

below. Most organisations will have internal standards for which of

the methods should be used in conducting a CBA, and what result

will be considered acceptable in assessing feasibility.

Return on Investment

Return on Investment (RoI)

RoI is the simplest, and one of the most frequently used,

measures of financial feasibility. It delivers a percentage figure

that can be compared against prevailing interest rates, in order to

assess whether the proposed investment is financially

worthwhile.

The basic formula is:

RoI = (Net Benefit / Investment) x 100

Where Net Benefit = the sum of tangible benefits – Total costs,

including annual running and development costs.

Standards vary from organisation to organisation as to what

period the costs and benefits are measured. A common

standard is to use the sums of annual costs and benefits over a

four-year period; another is to use the costs and benefits over the

expected life of the solution.

Standards also vary as to what RoI rate is acceptable, with

values such as twice bank base rate, or base rate plus 5% being

fairly typical.

Payback Period

Payback Period

Another common measure is that of Payback Period. This is a measure of when sufficient benefits will have accrued to cover both the initial investment costs and the on-going running costs of the solution.

For example a project with an investment cost of £120,000, annual running costs of £20,000, and annual benefits of £50,000 will pay back the investment in 4 years.

In assessing overall cost benefit, measures such as RoI and Payback Period will frequently be used in combination, and viewed differently by different organisations.

For example some might view a RoI of 20% with a pack back of 2 years as preferable to a RoI of 30% with a Payback Period of 4 years, depending on their strategic aims and current financial position.

For a full description of these methods the reader is referred to a text such as Robson (1997).