Software Engineering II: Feasibility Studies

Software Engineering II
Feasibility Studies
1
Feasibility Study
A feasibility study is a study made before committing to a

project.
A feasibility study leads to a decision:
go ahead
do not go ahead
think again
In production projects, the feasibility study often leads to a
budget request.
In research, a feasibility study is often in the form of a
proposal.
2
Why are Feasibility Studies Difficult?
Benefits are usually very hard to quantify.

Approach is usually ill-defined. Estimates of resources needed
and timetable are very rough.
Organizational changes may be needed.
Therefore, feasibility studies rely heavily on the judgment of
experienced people. Who are often over-enthusiastic.
Mistakes made at the beginning are the most difficult to correct.
3
The Decision Maker's Viewpoint
A senior member of an organization must decide whether to

begin a major software project. What information is needed?
Client: Who is this project for?
Scope: What are the boundaries of the project?
Benefits: What are the benefits? Can they be quantified?
Technical: Is there at least one technical way to carry out the
project?
Resources: What are the estimates of staff, time, equipment, etc?
Alternatives: What are the options if the project is not begun?
4
The Decision Maker's Viewpoint
Where are risks? Can they be minimized?
Technical
• There must be an outline plan with a rough timetable and
staff allocation.
• The plan must have a very large margin for contingencies.
(Projects typically require twice the staff and/or time
envisaged in the feasibility plan.)
External
• Every system interacts with others. Are the others
committed to the necessary efforts?
• Where are the external pressures and obstacles?
5
Example 1: U.S. Government Agency
(Decision before Feasibility Study)
Outline Description
A U.S. government agency, which manages huge
numbers of documents and other records, has been
very slow in moving from a paper based approach to
managing digital documents.
6
Example 1: Chronology
• A scientific computing center at University of

California was commissioned to develop a prototype
system to demonstrate technology.
• Funds were approved by Congress to "procure" a
major computer system.
• The National Academy of Sciences was
commissioned to report on the technical approach to
be followed and the results of the University of
California prototype (feasibility study).
Note: The decision to go ahead was made and the budget
approved before the feasibility study was begun.
7
Example 1: National Academy Report
The National Academy study finds:

• The computer system is technically feasible.
• The University of California prototype is promising but
incomplete.
• Agency needs stronger technical staff.
The study was not asked to comment on external factors,
but discovered major weaknesses in the agency's
management structure and organizational skills.
8
National Academy Report:
Technical Recommendations
The study recommends a phased approach:

1. System architecture created by iterative refinement to create a
Phase 1 design.
2. Followed by sequential implementation using the Phase 1
design
9
Example 1: Prototype and Phased
Development
• A prototype is not released to users, except experimentally
• In phased development, each phase is released into full
production
Developers UC Build Build

prototype phase 1 phase 2
Users Demonst- Phase 1 Phase 2

ration only production production
Iterative Sequential
process process
10
Example 1:
Obvious Problems
Organizational:
• Agency senior management clearly not ready to lead a very
large project that will completely change the agency
• No thought given to the workflow and job changes that will
affect almost every member of staff
Preparation:
• No preliminary study made of volumes or kinds of data; nor
of the very complex access policies
Complexity
• Major changes in the requirements and design are inevitable
once the system goes into production and has real users
11
Example 1: Dilemma
• Agency does not want to return money to Congress

• National Academy study was paid for by agency and restricted
to technical considerations
• The fundamental problem lies at the senior management level
[A phased approach over many years might possibly work, but
only after the organizational problems are addressed.]
• The agency has adopted a pure waterfall model and put out a
Request for Proposal for the Requirements
This is a disaster in the making.
12
Feasibility Study: Scope
Scope expresses the boundaries of the system:

• It will include <list of included functions>
• It will exclude <list of excluded functions>
• It depends on <list of dependencies>
• It replaces <list of functions to be replaced>
Confusion over scope is a common reason for clients to be
dissatisfied with a system.
"Is that all you planned to do?" "But I assumed that you were going
to do xyz." "I can't use the system without abc."
13
Feasibility Study: Benefits
Why is this project proposed? Can you quantify the benefits?

Examples
• Create a marketable product
• Improve the efficiency of an organization (e.g., save staff)
• Control a system that is too complex to control manually
• New or improved service (e.g., faster response to customers)
• Safety or security
14
Feasibility Study: Technical
A feasibility study needs to demonstrate that the proposed system

is technically feasible. This requires:
• a rough outline of the requirements
• a possible system design (e.g., database, distributed, etc.)
• estimates of numbers of users, data, transactions, etc.
• possible choices of software to be acquired or developed
These very rough numbers are fed into the provisional plan that is
used to estimate the staffing, timetable, equipment needs, etc.
The technical approach actually followed may be very different.
15
Feasibility Study:
Planning and Resources
The feasibility study should include an outline plan:
• Estimate the staffing and equipment needs, and the preliminary
timetable
• Identify major decision points
• Identify interactions with and dependences on external systems
• Provide a preliminary list of deliverables and delivery dates
16
Feasibility Study:
Alternatives and Risks
A feasibility study should identify alternatives and risks.
Alternatives
• Continue with current system, enhance it, or create new one?
• Develop in-house, or contract out? (How will a contract be
managed?)
Risks
• What can go wrong?
• How will problems be identified (visibility)?
• Are there fall-back options?
17
Techniques for Feasibility Studies
Give client appreciation of system:

demonstration
mock-up
walk through
Outline budget:
n people for m months at $x per month
equipment, buildings, etc.
Phases/milestones:
deliverables at approximate date
18
Feasibility Report
A written document
• For a general audience: client, financial management,
technical management, etc.
• Short enough that everybody reads it.
• Long enough that no important topics are skipped.
• Details are often included in supporting documents.
It should be a well written, well presented document.
19
How to Minimize Risk?
• Several target levels of functionality:

required, desirable, optional phases
• Visible software process: intermediate deliverables
• Good communication within team and with
Teaching Assistant
Good processes lead to good software

Good processes reduce risk
20
Feasibility Report
Specific Requirements for the Feasibility Report

• Outline plan, showing principal activities and
milestones.
• Discussion of Business Considerations
• Risk analysis.
• What can go wrong?
• What is your fall back plan?
21

Software Engineering II: Feasibility Studies

Uploaded by

Copyright:

Available Formats

Software Engineering II: Feasibility Studies

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering II: Feasibility Studies

Uploaded by

Copyright:

Available Formats

Software Engineering II

A feasibility study is a study made before committing to a

Benefits are usually very hard to quantify.

A senior member of an organization must decide whether to

• A scientific computing center at University of

The National Academy study finds:

The study recommends a phased approach:

Developers UC Build Build

Users Demonst- Phase 1 Phase 2

• Agency does not want to return money to Congress

Scope expresses the boundaries of the system:

Why is this project proposed? Can you quantify the benefits?

A feasibility study needs to demonstrate that the proposed system

Give client appreciation of system:

It should be a well written, well presented document.

• Several target levels of functionality:

Good processes lead to good software

Specific Requirements for the Feasibility Report

You might also like