170 likes | 402 Views
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?
E N D
Feasibility Studies CSCI 5801: Software Engineering
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 If not, can we afford to hire/purchase what we don’t have? With respect to customer needs
Major Steps • Determine scope of product • Create basic design • Estimate costs • Deliver report/proposalfor 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 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/serverarchitecture Repository architecture registrars Central repository course inventory server faculty students
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 Function Complexity of problem Estimate of effort Expertise of team
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
COCOMO II • Individual Productivity Rate (PROD) based on • Developer general experience/capability • Experience with software engineering tools/environments
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”