CS 501: Software Engineering
Lecture 3
Feasibility Studies
1
CS 501 Spring 2005
Administration
Project teams:
2
•
If you have definitely chosen a project and
reached agreement with your client, send
email to cs501-l@lists.cs.cornell.edu with the
names of your team members
•
If you do not have a team you can meet after
class
•
We may ask teams to add extra members
•
A Teaching Assistant will be added to each
team.
CS 501 Spring 2005
Administration
News group:
newsstand.cit.cornell.edu/cornell.class.cs501
Course team mailing list
cs501-l@lists.cs.cornell.edu
(Do not subscribe)
Assignment 1: due date
Friday, February 18, 5:00 p.m. (corrects mistake on Web site)
3
CS 501 Spring 2005
Administration
Project teams:
If you are having difficulty finding a team send email to
cs501-l@lists.cs.cornell.edu
Projects:
Announcements by project groups
4
CS 501 Spring 2005
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.
5
CS 501 Spring 2005
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.
(e.g., eCornell)
Organizational changes may be needed.
(e.g., Copyright deposit system.)
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.
6
CS 501 Spring 2005
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?
7
CS 501 Spring 2005
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?
8
CS 501 Spring 2005
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.
9
CS 501 Spring 2005
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.
10
CS 501 Spring 2005
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.
11
CS 501 Spring 2005
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
[Note that this is the same phasing used in the vector graphics for
Basic project discussed in Lecture 2.]
12
CS 501 Spring 2005
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
Users
13
UC
prototype
Demonstration only
Build
phase 1
Build
phase 2
Phase 1
production
Phase 2
production
Iterative
process
Sequential
process
CS 501 Spring 2005
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
14
CS 501 Spring 2005
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.
15
CS 501 Spring 2005
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."
16
CS 501 Spring 2005
Example 2: Library of Congress
Confusion over Scope
•
The Library of Congress required a repository system to
store and make accessible very large amounts of highly
varied material over long periods of time.
•
An outside organization (CNRI) built a repository system
to store and manipulate complex digital objects
•
Nobody built the sub-systems needed to organize, validate,
and to load material into the repository.
•
The Library of Congress expected the repository system to
include this sub-system. CNRI considered it external to
the repository system
A good feasibility study would have seen this confusion.
17
CS 501 Spring 2005
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
• Get a good grade on CS 501
18
CS 501 Spring 2005
Example 3: Benefits of the
National Science Digital Library (NSDL)
Concept
Create a comprehensive digital library for all aspects of
science education, where science and education are
both defined very broadly.
The National Science Foundation studied potential benefits for
five years before going ahead.
It came to the conclusion that, even though the benefits could
not be quantified, the potential was sufficient to justify a major
program.
19
CS 501 Spring 2005
Example 3:
NSDL Timetable
1996 Vision articulated by NSF's Division of Undergraduate
Education
1997 National Research Council workshop
1998 SMETE-Lib workshop
1999 NSDL solicitation
2000 6 demonstration projects of the core system
2001 Core integration system funded
Note: 5 years from concept to decision to definitely go ahead.
20
CS 501 Spring 2005
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.
21
CS 501 Spring 2005
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
Lecture 4 is about planning techniques.
22
CS 501 Spring 2005
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?
23
CS 501 Spring 2005
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
24
CS 501 Spring 2005
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.
25
CS 501 Spring 2005
CS 501: Client
In CS 501, you have two clients:
• The client for the project
• The professor for the course
Can you satisfy them both?
26
CS 501 Spring 2005
CS 501: Resources
Examples: CS 501
Staff: 5 to 7 students, with some help. How many hours per week?
What skills do people have?
Time: Must be completed by end of semester, including
operational system, documentation, presentation
Equipment and software: What special needs are there?
Client: Will the client be sufficiently available and helpful?
27
CS 501 Spring 2005
CS 501: Obstacles
CS 501 projects
Start-up time. Creating a team, scheduling meetings, acquiring
software, learning new systems, ...
Business considerations. Licenses, trade-secrets, ...
Too ambitious. Nothing to show at the end of the semester...
Changing circumstances. Client leaves the university, ...
What else?
28
CS 501 Spring 2005
CS 501: How to Minimize Risk?
CS 501 Projects
• 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
29
CS 501 Spring 2005
CS 501: Feasibility Report
Specific Requirements for the Feasibility Report
• Outline plan, showing principal activities and
milestones (to be discussed on Thursday).
• Discussion of Business Considerations (see Projects
page on the course Web site).
• Risk analysis. What can go wrong? What is your
fall back plan?
30
*
CS 501 Spring 2005