imat1906 systems development lecture week 6: systems analysis (1) : feasibility

IMAT1906 Systems Development

Lecture week 6: systems analysis (1) : feasibility

Today’s Agenda

IMAT 1906 Lecture Week 6 (c) De Montfort University 2010-112

Recap what is system development Understand business problem Fact-finding techniques Feasibility study

3

Recap: what is system development Inception:

Looks at a business problem Elaboration:

Analyses problem Designs solution and computer system to support

business area Construction:

Develops and tests computer system Transition:

Implements computer system Helps business area to build new system into work

practices IMAT 1906 Lecture Week 6 (c) De Montfort

University 2010-11

4

Context So far in this module we have

Looked at a scenario: the second hand bookshop Evaluated an existing system: Student 2 Student Seen ways of documenting the scenario and system

Rich picture Mind map Use case diagram and description

Now we go on to Consider a system that does not yet exist Rather than one single scenario, we will use many

little ones over the next few weeks, to illustrate different parts of development process


5

Business problem


System development starts with recognition of business problem, for example New function required for existing system New business process needs a computer system

to support it Leads to system request and business case

Outline of business problem Request made to IT director, chief analyst, IT

department manager, system developer – as relevant in the organisation

Usually a formal document of some kind Often includes business case giving reason

investment needed, costs, benefits

6

Understanding business problem


Analyst or developer starts by understanding business problem

Builds a rich picture to show what the business problem is and its context, how it fits in the organisation

We have seen how to do rich pictures How to find out what goes into the picture?

Work with the business people who know their areas

User involvement and teamwork Analysts and users need to work together as a

project team Communication and interpersonal skills

Need to find out the facts....

Where are we on agenda



8

Factfinding for overall understanding


Factfinding is done at two major stages of system development Overall understanding, for feasibility study Detailed understanding, for requirements

specification For overall understanding, need to talk to

people Main techniques are

Interviews Workshops

9

Interviews (1) - preparation


Interviews for overall understanding Talking to senior people, often managers Focus on what happens and why rather than on

how or when How to prepare for an interview

Decide what you want to find out Work out questions to find out those things Identify who to talk to (interviewees) Arrange meetings and invite interviewees List the questions and any follow-up questions Prepare for taking notes, either yourself or a scribe

10

Interviews (2) - questions


Open questions Have open-ended answers Allow person to develop ideas For example

“what do you think....” “can you tell me about....”

Often lead to follow-up questions to find out more about something they’ve said

Closed questions Have short or yes/no answers Good to confirm facts For example

“do you work in Accounts Department” “how long have you worked in this role”

11

Interviews (3) - conducting


Remind yourself of the questions Introduce yourself, put the person at ease, confirm

they understand the purpose of the interview, confirm how long it will take or any other time constraints

Ask the questions in a natural manner Allow the person time to think and respond Ask follow-up questions as they arise Summarise what you’ve heard about a topic

before moving on to a new topic Make notes as you go along, as unobtrusively as

possible Keep an eye on the time May not follow all of your interview plan but that’s

fine

12

Interviews (3a) - conducting


5 minutes before end, summarise what you’ve heard

Close the interview: Thank them for their time and thoughts Confirm any actions you have agreed

13

Interviews (4) – afterwards


Follow-up activities: write up your interview notes send a copy to the interviewee inviting them to

confirm your understanding of what they’ve said incorporate their comments in your notes

14

Workshops for overall understanding


Sometimes possible to get several senior people together at once

Preparation similar to interview preparation except More people to invite and coordinate availability Larger meeting room to arrange Need flipchart paper and pens to collect

discussion notes Still need to think about purpose of

workshop and prepare questions or topics for discussion

15

Workshops (1) - conducting


Remind yourself of the questions and topics Welcome participants, thank them for their time, confirm

how long it will take or any other time constraints State purpose of workshop for example to understand

need for new system and likely scope State what you hope to get out of it for example

understanding the business problem Ask the questions or introduce each topic for discussion Make notes of the main points and agreed conclusions

On flipcharts so all can see and refer back to during workshop Summarise what you’ve heard about a topic before

moving on to a new topic

16

Workshops (1a) - conducting


Keep an eye on the time May not follow all of your workshop plan but that’s

fine 5 minutes before end, summarise what has been

agreed Close the workshop:

Thank everyone for their time and thoughts Confirm any actions that have been agreed

17

Workshops (2) – follow-up


Similar activities to interview follow-up: Write up the notes from the flipcharts and any

other notes Send a copy to participants inviting them to

confirm your understanding of what emerged from the discussions

Incorporate their comments in your notes

18

Rich Picture


Using the information found by interviews and/or workshop

Identify main players or users Identify main processes Identify main things used or exchanged by

players Draw a rich picture Include any conflicts or potential hotspots

identified in the fact-finding Share the rich picture with people you talked

to, to confirm you’ve understood it right

Where are we on agenda



20

Feasibility study


Purpose of feasibility study is to confirm whether the system development project Is feasible, ie can be developed with reasonable chance of

success Is worth going ahead with, ie will give reasonable return on

investment or will give required business improvement Study is usually done in short timescale and is not a

full analysis of the business problem Result of a feasibility study is a feasibility report

Usually presented in hard copy and also delivered in a presentation to senior management

Allows senior management to decide business priorities and whether to go ahead with the system development or not

21

Feasibility types


Technical feasibility – are there technical reasons not to develop the system

Operational or business feasibility – are there operational business reasons not to develop the system

Economic or financial feasibility – are there financial reasons not to develop the system

22

Technical feasibility


Looks at technical resources needed to develop or purchase, install and operate the system

Compares likely performance against technical criteria

May investigate several different options for development, comparing costs and benefits

Concerned with configuration of components rather than precisely which makes or versions of hardware and software

Questions to be asked: Are the necessary hardware, software, network

components available Is the necessary technical expertise available

23

Operational or business feasibility


Looks at human, organisational and business aspects needed for system to be successful

Compares likely performance against business and organisational criteria

Unlikely to prevent development but may inform system requirements

Questions to be asked: Will users have difficulty with proposed system Will system provide expected benefits Will new system bring changes to existing job roles What new skills will be required Is the proposed system supported by senior

management and is there a firm timetable

24

Economic feasibility


Looks for a financial return that outweighs the costs of development

Compares likely financial benefits with expected costs

Likely to be used to prioritise proposed developments or to select different options for a development

Questions to be asked: What are the tangible (measurable) financial benefits What is the cost of developing the system What is the cost of not developing the system ie making

do with current process What are the intangible (hard to measure) benefits

25

Feasibility report


Report sets out how the feasibility was investigated and what the conclusions are

Presented to senior management Decision makers need to balance three types

of feasibility and not ignore any one of them Development project can be:

Technically sound but too expensive to be economically feasible

Operationally supportive but expensive to develop Financially viable – typically one option will give a

better financial return while compromising the technical or operational suitability

26

For further reference....


Fact-finding techniques: Skidmore & Eva chapter 5 Shelly & Rosenblatt pp 155-166 Cadle et al pp 26-39

Feasibility: Skidmore & Eva chapter 4 Shelly & Rosenblatt pp 63-66, 75

Note that Shelly & Rosenblatt also mention Schedule Feasibility, which other authors include in Operational or Business Feasibility

Cadle et al pp 128-131, 133-146

27

Summary


System development starts with identified business problem

Initial investigation using fact-finding techniques for overall understanding of business problem

Use findings to clarify understanding and begin feasibility study

Investigate three types of feasibility Feasibility report for management to

support decision to go ahead with system development

imat1906 systems development lecture week 6: systems analysis (1) : feasibility

Documents

business people

business areaconstruction

business problembuilds

montfort university

system request

system developer

business problem elaboration

new system