1. F28SD2 Software Design Information Systems Lifecycle
Introduction to Feasibility Studies
Monica Farrow
EM G30
Material available on Vision

2. Timetable Thu Mar 5 G44 Tue Mar 10 NS136
Thu Mar 12 – No lecture – work independently
Tue Mar 17 – guest visitor starting at 11:15 (?)
Lyle Barbour from SOPRA group
Maybe lasting up to 1hr 30 mins
Location to be arranged
Thu Mar 19 G44
Tue Mar 24 NS136 back with CS
01/13/09
F28SD Software Design

3. Process models There are various types of software lifecycle models
Waterfall, spiral, agile...
01/13/09

4. Waterfall process model
Requirements capture
System and
software design
Implementation and unit testing
Integration and system testing
You’ll find slightly different
versions elsewhere.
Operation and maintenance
01/13/09
F28SD Software Design

5. Boehm’s spiral model
01/13/09
F28SD Software Design 5

6. SCRUM – an agile process
Other diagrams show 2-4 weeks
Rather than 30 days
01/13/09

7. Information Systems lifecycle
Software lifecycle models
concentrate on design and implementation of a software system
models lack an overall picture of the organisation and its business processes
A traditional structured design method extended in this manner is shown next
(Based on Avison and Shah)
The similarities are clear
So are the new features
01/13/09
F28SD Software Design

8. Information Systems lifecycle After Avison and Shah p71 IS planning
Problems with
existing system
New business
opportunities
Information Systems lifecycle After Avison and Shah p71 IS
planning
Managerial
directive
Feasibility
study
Feasibility
study report
Systems
investigation
User
requirements
Project
plans
Resource
requirements
Staff
assignment
Methods
and tools
Systems
analysis
Current
system
data flow
System
requirements
Systems
design
New system
data flow
System
specification
Training and
test plans
Implementation
Programs
Procedures
Documentation
New system
in operation
Review
and
maintenance
Evaluation
report
New problem
statement?
01/13/09
F28SD Software Design

9. What’s similar? Stages rather like waterfall
Repeats with review like spiral
Progress in terms of artefacts
01/13/09
F28SD Software Design

10. What’s added? Feasibility study Review during maintenance
System is an open one
Operation feeds back to design
01/13/09
F28SD Software Design

11. Review during maintenance
Learning from experience
Effectiveness of the solution
Correctness of function
Efficiency
Suitability for the business process
Effectiveness of the process
Kept to time?
Kept to budget?
Lessons learned for future developments
01/13/09
F28SD Software Design 11

12. System is an open one
Take account of influences from the organisation which change over time
Managerial directives
often arbitrary
but often dominate decision making
New opportunities
business process change requires system change
Longer term information systems planning
system change to maintain business process
01/13/09
F28SD Software Design 12

13. Operation feeds back to design
Operation reveals errors - “maintenance” in SE
Operation reveals bottlenecks for the business
Operation reveals new opportunities for business
Operation reveals difficulties for users
Summary : from the original ‘build a system then hand it over’ approach, we must be now more aware of the user and their environment.
01/13/09
F28SD Software Design 13

14. The negative option is a valid option!
Feasibility study
Propose and evaluate alternatives
Establish priorities
Gather information
Perform cost-benefit analysis
Form options for computerisation
Present conclusions
The negative option is a valid option!
01/13/09
F28SD Software Design 14

15. Objectives of feasibility study
A feasibility study should provide management with enough information to decide:
whether the project can be done
whether the final product will benefit its intended users
what are the alternatives among which a solution will be chosen (during subsequent phases)
is there a preferred alternative
After a feasibility study, management makes a go/no go decision
The feasibility study is a management-oriented activity
01/13/09

16. Inputs and outputs Organisation Feasibility study Users Management
report
Existing
Practice
Boundary
Constraints
Objectives
Responsibilities
New
Opportunities
Problems
New
Requirements
Feasibility study
Systems
analyst
Suppliers
Costs
01/13/09

17. Terms of reference Project objectives System boundary Responsibility
Constraints
Reporting mechanism
01/13/09

18. Terms of reference Project objectives System boundary
Unambiguous statement of what the client expects
Must be agreed before further work is done
System boundary
The scope of the feasibility study
What should be considered
What should not be considered
01/13/09

19. Terms of reference continued
Responsibility
Who will supervise the project?
Who can authorise changes during the study?
Is the scope fixed?
Constraints
Budget
Time scales
Resources
Etc
Reporting
How will the report be expected?
To whom will the report be presented?
Who else can see the report?
01/13/09

20. Tasks in conducting the study
Study current situation
Analyse requirements
Consider alternatives
Analyse economic/financial situation
01/13/09

21. Current situation Study current situation
The present organizational system, including users, policies, functions, objectives,...
Problems with the present system (inconsistencies, inadequacies in functionality, performance,...,
Gain thorough understanding
Establish reality of problems
Look for opportunities
Establish cause and effect
01/13/09

22. PIECES framework
The PIECES framework can help in identifying problems to be solved, and their urgency:
Performance -- Does current mode of operation provide adequate throughput and response time?
Information -- Does current mode provide end users and managers with timely, pertinent, accurate and usefully formatted information?
Economy -- Does current mode of operation provide cost-effective information services to the business? Could there be a reduction in costs and/or an increase in benefits?
01/13/09

23. PIECES framework
Control -- Does current mode of operation offer effective controls to protect against fraud and to guarantee accuracy and security of data and information?
Efficiency -- Does current mode of operation make maximum use of available resources, including people, time, flow of forms,...?
Services -- Does current mode of operation provide reliable service? Is it flexible and expandable?
01/13/09

24. Analyse requirements Analyse requirements (What not how)
Objectives and other requirements for the new system
what needs to change?
What would the stakeholders like to achieve?
Constraints, including non-functional requirements on the system (preliminary pass)
What is the client’s intention?
What capabilities are needed?
Data input and stored
Information output
01/13/09

25. Tasks in conducting the study continued
Consider alternative solutions
Possible alternatives (the current system is always one of those)
Different business processes for solving the problems
Different levels/types of computerization for the solutions
Advantages and disadvantages of the alternatives
Economic/financial analysis
Costs of alternatives
Opportunity costs of inaction
Benefits of changes
Impact on business as a whole
01/13/09

26. Four tests for feasibility
There are four categories of feasibility tests
Operational feasibility
How well will solution work in organisation? How do people feel about it?
Technical feasibility
Practical? Expertise?
Schedule feasibility
Reasonable timetable?
Economic feasibility
Cost-effective?
01/13/09

27. Operational Feasibility: Acceptability
How do end-users and managers feel about the problem (solution)?
It's not only important to evaluate whether a system can work but also evaluate whether a system will work.
A workable solution might fail because of end-user or management resistance.
Does management support the project?
How do the end-users feel about their role in the new system?
What end-users or managers may resist or not use the system? People tend to resist change. Can this problem be overcome? If so, how?
How will the working environment of the end-users change?
01/13/09

28. Operational Feasibility: Acceptability
Can or will end-users and management adapt to the change?
Internal issues, such as manpower problems, labour objections, manager resistance, organizational conflicts and policies;
also external issues, including social acceptability, legal aspects and government regulations.
The PIECES framework can also be used for each alternative solution
Performance, Information, Economy, Control, Efficiency, Services
01/13/09

29. Technical feasibility
Is the proposed technology or solution practical?
Do we currently possess the necessary technology?
Do we possess the necessary technical expertise, and
Is the schedule reasonable for the team?
Is relevant technology mature enough to be easily applied to our problem?
Is it compatible with our other systems?
01/13/09

30. Technical feasibility
Some firms like to use state-of-the-art technology, but most firms prefer to use mature and proven technology.
A mature technology has a larger customer base for obtaining advice concerning problems and improvements.
Assuming that required technology is practical, is it available ‘in-house’?
If so, does it have the capacity to handle the solution.
If not, can it be acquired?
Is it available within given resource constraints (i.e., budget, schedule,...)?
01/13/09

31. Schedule feasibility
Do we have the skills required to properly apply that technology;
True, all information systems professionals can learn new technologies;
However, that learning curve will impact the technical feasibility of the project;
Specifically, it will impact the schedule.
Given our technical expertise, are the project deadlines reasonable?
Some projects are initiated with specific deadlines;
You need to determine whether the deadlines are mandatory or desirable. What are the consequences of delay?
If the deadlines are desirable rather than mandatory, the analyst can propose alternative schedules.
Missed schedules are bad, but inadequate systems are worse!
01/13/09

32. Economic feasibility
The bottom line in many projects is economic feasibility.
During the early phases of the project, economic feasibility analysis amounts to little more than judging whether the possible benefits of solving the problem are worthwhile.
As soon as specific requirements and solutions have been identified, the analyst can weigh the costs and benefits of each alternative.
This is called a cost-benefit analysis.
01/13/09

33. Cost/benefit analysis
The purpose of a cost/benefit analysis is to answer questions such as:
Is the project justified (because benefits outweigh costs)?
Can the project be done, within given cost constraints?
What is the minimal cost to attain a certain system?
What is the preferred alternative, among candidate solutions?
01/13/09

34. Cost/benefit analysis
Examples of things to consider:
Hardware/software selection
How to convince management to develop the new system
Selection among alternative financing arrangements (rent/lease/purchase)
Difficulties
Discovering and assessing benefits and costs. They can both be intangible, hidden and/or hard to estimate,
It's also hard to rank multi-criteria alternatives
01/13/09

35. Types of benefit Examples of particular benefits: cost reductions,
error reductions,
increased throughput,
increased flexibility of operation,
Improved operation,
better (e.g., more accurate) and more timely information
01/13/09

36. Types of benefit
Benefits may be classified into one of the following categories:
Monetary -- when $-values can be calculated
Tangible (Quantified) -- when benefits can be quantified, but $-values can't be calculated
Intangible -- when neither of the above applies
How to identify benefits?
By organizational level (operational,lower/middle/higher management)
or by department (production,purchasing, sales,...)
01/13/09

37. Types of cost Project-related costs Development and purchasing costs:
who builds the system(internally or contracted out)?
software used (buy or build)?
hardware (what to buy, buy/lease)?
facilities (site, communications, power,...)
Installation and conversion cost
installing the system,
training of personnel,
file conversion,....
01/13/09

38. Types of cost Operational costs (on-going) Maintenance
hardware (maintenance, lease, materials,...),
software (maintenance fees and contracts), facilities
Personnel: operation, maintenance
01/13/09

39. Types of cost
For a small business that wants to introduce a PC-based information system, these cost categories translate to the following:
Project costs
purchasing (hardware, software, office furniture),
customizing software, training,
system installation
and file conversion
On-going costs:
operating the system (data entry, backups, helping users, vendors etc.),
maintenance (software) and user support,
hardware and software maintenance,
supplies
01/13/09

40. Costing example?
01/13/09

41. Next More on costs next time
Most of these notes come from Ch9 of Systems Analysis and Design Methods b Whitten, Bentley and Dittman
You can read this chapter in full electronically, on Vision
01/13/09