Feasibility
Studies
CS 560
Lecture 2
2/2/2016
Feasibility study
• Study
•A
made before committing to a project.
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.
• The
feasibility study may be in the form of a proposal.
2
Risks of the project
• Technical
Risks:
 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 allocated in the
feasibility plan.
• External
Risks:
 Where are the external pressures and obstacles?
 Client commitments?
3
Organizational feasibility
• Creation
of a major software system makes demands on
the development team.
 Does the team have management expertise?
 Does the team have technical expertise?
 Can the team accommodate changes in personnel, project requirements,
workflow?
• Concepts
covered by the CS 560 project:
 Management of project teams of 4 – 5 people.
 Determining technical level of each team member and assigning tasks
appropriately.
 Steady progression of a software system while being open to potential
change of requirements.
 Software documentation management.
4
Why are feasibility studies difficult?
• Uncertainty
 Clients and/or development teams may be unsure of the scope of the
project.
 Benefits are usually very hard to quantify.
 Approach is usually ill-defined. Estimates of resources and timetable are
very rough.
 Organizational changes may be needed.
• Mistakes
made at the beginning of a project are the most
difficult to correct.
5
The Decision Maker’s Viewpoint
• The
feasibility study helps make recommendations.
• What
information is needed before beginning a project?
 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 the project possible?
 Resources:
 What are the estimates of staff, time, equipment, etc.?
6
Feasibility Study: Scope
• Scope
expresses the boundaries of the system:
 The project will have a list of included functions.
 The project will have a list of excluded functions.
 The project will have a list of dependencies.
• Confusion
over scope is a common reason for clients to be
dissatisfied with a system.
 “I assumed that you were going to do xyz.”
 “I can’t use the system without abc.”
 Remember, you are building the product for the client, not yourself.
7
Feasibility Study: Scope Example
• An
organization requires a “repository system” to store
and make accessible very large amounts of material over a
long period of time.
 An outside software development team was hired to build the repository
system.
 BUT…
 No one built the sub-systems needed to organize, validate, and load
material into the repository.
 The organization expected these subsystems, but the software development
team considered those systems to be separate from the repository system.
•A
good feasibility report would have foreseen this
problem.
8
Feasibility Study: Benefits
• Why
is this project proposed? Can you quantify
the benefits?
 Organization benefits:
 Create a marketable product
 Improve the efficiency of an organization
 Control complex systems
 New or improved service
 Safety or security
• Professional
a project.
benefits are not the reason for doing
9
Feasibility Study: Technical
•A
feasibility study needs to demonstrate that the proposed
system is technically feasible. This requires:
 An outline of the requirements
 A possible system design
 Database, distributed, autonomous, etc.
 Possible choices of software to be used or developed
 Estimates on number of users, data, transactions, etc.
• These
rough numbers are part of the plan that is used to
estimate the staffing, timetable, equipment needs, etc.
• The
technical approach actually followed may be very
different.
10
Feasibility Study: Planning and
Resources
• The
feasibility study must include an outline plan:
 Estimate the staffing and equipment needs, and the preliminary
timetable.
 Identify major milestones and decision points.
 Identify interactions with and dependences on external systems.
 Provide a preliminary list of deliverables and delivery dates.
• There
is a separate lecture about Project Management.
11
Feasibility Study: Alternatives and
Risks
•A
feasibility study should identify risks and
alternatives.
 Risks
 What can go wrong?
 How will progress be monitored and problems identified?
 What is the contingency plan?
 Alternatives
 Continue with current system, enhance it, or make a new one?
 Phases of delivery and possible points for revision
12
Techniques for Feasibly studies
• The
highest priority is to ensure that the client and
development team have the same understanding of the
goals of the system.
• For
the development team to understand the system:
 Interviews with the client
 Review of existing systems, including competing systems
 Background research, reading journal/conference articles, technical papers,
etc.
• For
the client to appreciate the proposed system:
 Demonstration of key features or similar systems
 Mock-up system designs and architectures
 Walk through typical transactions or interactions
13
Techniques for Feasibly studies
• Resource
budget:
 N people for H hours per week for M months
 Equipment, development space, etc.
 Contingency
• Phases/Milestones:
 Specify deliverables (designs, software, documentations, etc.) at
certain deadlines
 Feasibility report due February 18th
14
Feasibility Report
•A
feasibility report should be a well written, well
presented document.
 Written 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 can be included in supporting documents, appendix, etc.
• The
report should be very concise, and explain in detail
how the project will be approached.
15
CS 560: Feasibility Report
• Challenges:
 Team:
 How many hours per week?
 How often to meet as a group? Work individually?
 Skillset of team members?
 Time:
 Must be completed by the end of the semester.
 Including all software, documentation, and presentation resources
 Equipment and software:
 What special needs are there?
 Start-up time:
 Team creation, scheduling meetings, acquiring hardware and software, learning new
systems, etc..
 Too ambitious:
 Nothing to show at the end of the semester..
16
CS 560: How to minimize Risk?
• Techniques
for managing risk:
 Several target levels of functionality for project:
 Required
 Desirable
 Optional
 Visible software process:
 Intermediate deliverables
 Good communication:
 Within the project group
 With the client
 Well defined development processes:
 Good processes lead to good software and reduced risk
17
CS 560: Feasibility Study reports
• Appoint
one or two team members to read and edit
the entire report before it is due.
• Content:
 If different authors write different sections, are the
sections consistent?
 Scope, plan, requirements, etc. agree on what is to be done?
• Style:
 Is the text comprehensible?
 Does the report use jargon that is not clear to the client?
18
CS 560: Feasibility Studies Common Problems
• The
purpose of a feasible study is the establish if a project
is feasible, at reasonable cost, within the planned period.
• The
report should conclude with:
 Recommendations about whether to proceed
 With the final decision made by the client.
• Potential
problems with feasibility reports:
 The report is vague about scope.
 The project scope should be clearly defined. Otherwise, it is not clear if the project is
feasible.
 The report does not describe project group activities in enough
detail.
 Detail is needed about all activities to convincingly estimate effort.
 The project is too ambitious.
 The report should describe how you will monitor the progress and adjust the scope if
necessary.
19
Software Engineering
Project Presentations
Presentations
• Presentations
engineering.
are an important part of software
 Reasons:
 Marketing to potential clients
 Reporting of progress to senior management
 Reporting and demonstrations to clients
• If
you are uncomfortable making presentations,
take every opportunity to gain experience.
 It is difficult to achieve a leadership position in the
software industry if you can’t make decent presentations.
21
Planning for Presentations
• Objectives:
 What is the purpose of the presentation?
 What do you want to achieve?
 Who will be there?
 How much time will you have? How will you use the time?
 What room will you use? What equipment will be available?
• CS
560 Presentations:
 The presentations should be directed to the client
 The presentations will be 15 minutes in length
 Each team member should participate by speaking during the project
presentations
22
Topics for software presentations
• Four
project groups in CS 560, different projects for
each group
• Suggestions:
 General topics for every project:
 A description of what you have agreed to deliver to your client
 Summary of progress since last presentation/report
 Test plan and test cases
 Discussion of unexpected events and risks
 Overview of plan to complete and deliver the project
 Topics that apply to many projects:
 Results of user testing
 Technical details
23
Topics for the first CS 560 presentation
• Your
first assignment is the project proposal
Project team presentations – February 4th
10 minutes to present your project idea to the class.
You should include
 Initial approach
 Team member duties
 Feasibility requirements
 Resources needed
 Projected project time line
 Expected outcomes for your project at each milestone
24
Planning for a presentation
• Visual
aids:
 Useful, but not essential to have visual aids, such as presentation slides.
 If you use presentation slides:
 Keep them simple
 They must be legible
• Demonstrations:
 Can be very useful, but need preparation and practice to do well
 Technical:
 Load and configure all software before the presentation. Make sure it is working
correctly.
 If you need test data, create it in advance.
 If you have to type complex commands to run a presentation, do so before the
presentation.
 Script for demo:
 Prepare a script that lists the preparation, examples, and task delegations so that
team members will be more prepared during the presentation.
25
Planning for a presentation
• Have
a rehearsal, check visual aids and demonstrations.
• Check
the equipment in the presentation room.
 Do you need a network connection?
 How do you connect your computer?
• CS
560 Presentations:
 There are four milestone presentations during the semester.
 All group members must participate during each presentation.
 The current presenter should stand closest to the projector screen. Other team
members should give the presenter space to move around the front of the room.
 The project group should take notes during the presentation on format, clarity, class
interaction, client interaction, etc.
 Used to enhance future presentations.
 The first presenter should introduce everybody at each presentation, along with their
most important task(s).
26
Progressing toward the final
presentation
•
What do you want to achieve?




•
Personal team satisfaction in handing over a quality software product to the client.
Complete the course in good style with a good grade.
A clean handover of the product without loose ends.
Perhaps, a good basis for future involvement with the client, team, or project.
Who is the audience? What do they want?
 Clients:
 Is the product ready for production?
 Should we invest more effort to bring it into production?
 Should we abandon the project?
 Software Project Team:
 What has been accomplished?
 What has been learned?
 Not learned?
 Is the client satisfied?
 Are you handing over a maintainable software product?
27
Second weekly team/client meeting
deliverables
• Each
team should bring to the second meeting an 8 - 9
page draft of the feasibility report, which includes:
 Description of the project
 Technical feasibility
 Risk analysis
 Resources needed
 People hours, equipment, development space, etc.
 Outline of the team management process
 Team meeting schedule, individual tasks, etc.
 Rough draft of weekly and milestone goals
 Suggested deliverables
• Each
person in the group should have a copy of the
feasibility report draft during the meeting.
28