Feasibility Studies CS 360 Lecture 2

Feasibility study 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. The feasibility study may be in the form of a proposal.

Risks of the project Technical Risks: External 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?

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 360 project: Management of project teams of 5 – 7 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.

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.

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.?

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.

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.

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 benefits are not the reason for doing a project.

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 provisional plan that is used to estimate the staffing, timetable, equipment needs, etc. The technical approach actually followed may be very different.

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.

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

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

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 September 11th

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.

CS 360: 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.. What else?

CS 360: 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

CS 360: 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? If possible, have a native English speaker do the final editing.

CS 360: 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.

Software engineering Project presentations

Presentations Presentations 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.

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 360 Presentations: The presentations should be directed to the client The presentations will be 10 minutes in length Each team member should participate by speaking during the project presentations

Topics for software presentations Five projects groups is CS 360, 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 Demonstrations are always welcome during a presentation

Topics for the first CS 360 presentation Client and project team agreement on scope and goals Presentations of assumptions, decisions, etc. “The project will be a success if..” Progress to date Summary of requirements, preliminary designs, etc. “This is our understanding of your requirements..” Demonstrations, prototypes, designs, … Schedule and plan What has been done since the project group creation? What have you learned? Any change of plans? Problems? Main risks..

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. Tell the audience exactly what you are doing.

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 360 Presentations: There are four 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).

Planning for a presentation How much can you cover? Plan for a 10 minute presentation. You should include: Demonstration of the current system Design, project management tasks, goals, achievements, etc. Summary of what was proposed versus what was accomplished during the current milestone. Be honest about gaps, weaknesses, etc.

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?

First weekly team/client meeting deliverables Each team should bring to the first meeting a 5 – 6 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.