Feasibility Studies
CSCI 5801: Software Engineering
Feasibility Studies
Feasibility Studies
• Should we develop this system?
– Does the system contribute to objectives of the
customer?
• Are there better and cheaper alternatives they have?
– Will it work within the informational/
organizational structure of the organization?
– Is the system affordable by the customer?
•
•
•
•
Product development
Supporting hardware/software
User training
Maintenance
Feasibility Studies
• Can we develop this system?
– Do we have the resources?
• People
• Expertise/experience
• Hardware/software
resources
If not, can we afford
to hire/purchase what
we don’t have?
– Can it be done within constraints?
• On time
• Within budget
With respect to customer needs
Major Steps
•
•
•
•
Determine scope of product
Create basic design
Estimate costs
Deliver report/proposal
for decision
Analogous to
steps in
development
process!
• Must be done quickly (a week or two at most)
Project Scope
• What will system do?
– Short list of functions/use cases
– Will refine in requirements stage
• What will system not do?
– Just as important to avoid misunderstanding!
All possible requirements
What this system
will do
Example: Registration System
• This system will
– Read courses from the existing course inventory
– Allow chairs to create sections
– Allow students to view course information, and
add or drop courses over the web
– Keep track of roster for sections and allow
instructors to view their courses
– Close sections when the roster is full
– Prevent students from adding courses at
conflicting times
Example: Registration System
• This system will not
– Enforce prerequisite constraints
– Detect room/instructor conflicts
– Store grades received by students
– Handle billing for courses
Preliminary Design
• Is there some way the system can be built?
– Worry about “best” design later
• Often based on existing design patterns
Client/server
architecture
Repository architecture
registrars
Central repository
server
students
faculty
course
inventory
Cost Estimation
• Goal: accurate estimate of time/expense of
developing system
• Reality: Too many variables
– Human, technical, market…
Cost Estimation Models
• Experience:
– “How long has it taken us to do similar things before?”
– If you haven’t done this before, assume a longer time!
• Mathematical:
Complexity of problem
Expertise of team
Function
Estimate
of effort
– Example: COCOMO II (COnstructive COst Model)
• Very widely used for cost estimation and project
scheduling
• http://sunset.usc.edu/research/COCOMOII/cocomo_main.html
COCOMO II
• Project complexity = NOP (new object points)
• Based on number/complexity of
– User interface screens (single process may have many)
– Reports/database tables
– Major components/classes used to implement logic
Object type
Complexity Weight
Simple
Medium
Difficult
Screen
1
2
3
Report
2
5
8
Component
10
COCOMO II
• Individual Productivity Rate (PROD) based on
– Developer general
experience/capability
– Experience with
software engineering
tools/environments
Developer experience
Very low
Low
Nominal
High
Very high
Environment capability Very low
Low
Nominal
High
Very high
7
13
25
50
PROD
4
COCOMO II
• NOP also based on reuse (%reuse)
– Similar components we have previously built
– Components we can purchase “off shelf”
• NOP = (object points) x (100 – reuse%)/100
• Estimated effort (in terms of person/months)
=NOP/PROD
Final Report
• Describes all of the above
– Project scope, Preliminary design, Cost estimate
• May be presentation
– To management for budget approval
– To customer for approval/initial bids
• May include simple prototyping
– Sample screens for customer
– Very simple system for user focus groups
The Decision
• Based on what is best for customers and your
organization
• Not other considerations
– “It would look good on my resume if I said I have experience
developing this type of system”
– “I don’t know if it will work, but we have to be seen as having
the most up to date stuff”