Systems Development Life Cycle (SDLC)

Feasibility Study

Requirements

Analysis

Requirements

Specification

Logical System

Specification

Physical Design

S S

A D M

Strategy 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

Supplier Pro

26 27 28 29

Purchase Or

1 2 3

Set of

Purchase Order Item

Purchase Ord

19 20 21 22

Product

Purchase Order

Purchase Order

Line

Supplier

Supplier's Product

Process Purcha-

se Order Query

Process

Supplier

1 2 3 4

Process Set of

Purchase Order

Process

Purchase Order

4

Process

Next

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

Planning1. 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.

Task Name Effort Duration

Investigation 25 hrs 17 days

Prepare Stage Plan 6 hrs 3 days

Schedule Interviews and Workshops 4 hrs 7 days

Interviews and W orkshops 15 hrs 10 days

Interview M Portillo 1 hr 1 hr

Delivery Scheduling Workshop 6 hrs 1 day

Document DS Workshop 4 hrs 2 days

Resolve DS Workshop Anomolies 4 hrs 6 days

22 25 28 31 03 06 09 12 15 18 21 24 27 30 02 05July 2001 August 2001 September 2001

GanttChart:

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

NoteOn 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).