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

– Can it be done within constraints?• On time• Within budget With respect to customer needs

If not, can we afford to hire/purchase what we don’t have?

Major Steps

• Determine scope of product• Create basic design• Estimate costs• Deliver report/proposal

for decision

• Must be done quickly (a week or two at most)

Analogous to steps in development process!

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 systemwill 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/serverarchitecture

students

server

Central repository

registrars

facultycourse inventory

Repository architecture

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:

– Example: COCOMO II (COnstructive COst Model)• Very widely used for cost estimation and project

scheduling• http://sunset.usc.edu/research/COCOMOII/cocomo_main.html

FunctionComplexity of problem

Expertise of team

Estimate of effort

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 typeComplexity 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

PROD 4 7 13 25 50

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”