1. 1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 3 Feasibility Studies

2. 2 CS 501 Spring 2005 Administration Project teams: If you have definitely chosen a project and reached agreement with your client, send email to cs501-l@lists.cs.cornell.edu with the names of your team members If you do not have a team you can meet after class We may ask teams to add extra members A Teaching Assistant will be added to each team.

3. 3 CS 501 Spring 2005 Administration News group: n ewsstand.cit.cornell.edu/cornell.class.cs501 Course team mailing list cs501-l@lists.cs.cornell.edu (Do not subscribe) Assignment 1: due date Friday, February 18, 5:00 p.m. (corrects mistake on Web site)

4. 4 CS 501 Spring 2005 Administration Project teams: If you are having difficulty finding a team send email to cs501-l@lists.cs.cornell.edu Projects: Announcements by project groups

5. 5 CS 501 Spring 2005 Feasibility Study A feasibility study is a 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. In research, a feasibility study is often in the form of a proposal.

6. 6 CS 501 Spring 2005 Why are Feasibility Studies Difficult? Benefits are usually very hard to quantify. Approach is usually ill-defined. Estimates of resources needed and timetable are very rough. (e.g., eCornell) Organizational changes may be needed. (e.g., Copyright deposit system.) Therefore, feasibility studies rely heavily on the judgment of experienced people. Who are often over-enthusiastic. Mistakes made at the beginning are the most difficult to correct.

7. 7 CS 501 Spring 2005 The Decision Maker's Viewpoint A senior member of an organization must decide whether to begin a major software project. What information is needed? 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 there at least one technical way to carry out the project? Resources: What are the estimates of staff, time, equipment, etc? Alternatives: What are the options if the project is not begun?

8. 8 CS 501 Spring 2005 The Decision Maker's Viewpoint Where are risks? Can they be minimized? Technical 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 envisaged in the feasibility plan.) External Every system interacts with others. Are the others committed to the necessary efforts? Where are the external pressures and obstacles?

9. 9 CS 501 Spring 2005 Example 1: U.S. Government Agency (Decision before Feasibility Study) Outline Description A U.S. government agency, which manages huge numbers of documents and other records, has been very slow in moving from a paper based approach to managing digital documents.

10. 10 CS 501 Spring 2005 Example 1: Chronology A scientific computing center at University of California was commissioned to develop a prototype system to demonstrate technology. Funds were approved by Congress to "procure" a major computer system. The National Academy of Sciences was commissioned to report on the technical approach to be followed and the results of the University of California prototype (feasibility study). Note: The decision to go ahead was made and the budget approved before the feasibility study was begun.

11. 11 CS 501 Spring 2005 Example 1: National Academy Report The National Academy study finds: The computer system is technically feasible. The University of California prototype is promising but incomplete. Agency needs stronger technical staff. The study was not asked to comment on external factors, but discovered major weaknesses in the agency's management structure and organizational skills.

12. 12 CS 501 Spring 2005 National Academy Report: Technical Recommendations The study recommends a phased approach: 1.System architecture created by iterative refinement to create a Phase 1 design. 2.Followed by sequential implementation using the Phase 1 design [Note that this is the same phasing used in the vector graphics for Basic project discussed in Lecture 2.]

13. 13 CS 501 Spring 2005 Example 1: Prototype and Phased Development A prototype is not released to users, except experimentally In phased development, each phase is released into full production UC prototype Build phase 1 Build phase 2 Demonst- ration only Phase 1 production Phase 2 production Developers Users Iterative process Sequential process

14. 14 CS 501 Spring 2005 Example 1: Obvious Problems Organizational: Agency senior management clearly not ready to lead a very large project that will completely change the agency No thought given to the workflow and job changes that will affect almost every member of staff Preparation: No preliminary study made of volumes or kinds of data; nor of the very complex access policies Complexity Major changes in the requirements and design are inevitable once the system goes into production and has real users

15. 15 CS 501 Spring 2005 Example 1: Dilemma Agency does not want to return money to Congress National Academy study was paid for by agency and restricted to technical considerations The fundamental problem lies at the senior management level [A phased approach over many years might possibly work, but only after the organizational problems are addressed.] The agency has adopted a pure waterfall model and put out a Request for Proposal for the Requirements This is a disaster in the making.

16. 16 CS 501 Spring 2005 Feasibility Study: Scope Scope expresses the boundaries of the system: It will include It will exclude It depends on It replaces Confusion over scope is a common reason for clients to be dissatisfied with a system. "Is that all you planned to do?" "But I assumed that you were going to do xyz." "I can't use the system without abc."

17. 17 CS 501 Spring 2005 Example 2: Library of Congress Confusion over Scope The Library of Congress required a repository system to store and make accessible very large amounts of highly varied material over long periods of time. An outside organization (CNRI) built a repository system to store and manipulate complex digital objects Nobody built the sub-systems needed to organize, validate, and to load material into the repository. The Library of Congress expected the repository system to include this sub-system. CNRI considered it external to the repository system A good feasibility study would have seen this confusion.

18. 18 CS 501 Spring 2005 Feasibility Study: Benefits Why is this project proposed? Can you quantify the benefits? Examples Create a marketable product Improve the efficiency of an organization (e.g., save staff) Control a system that is too complex to control manually New or improved service (e.g., faster response to customers) Safety or security Get a good grade on CS 501

19. 19 CS 501 Spring 2005 Example 3: Benefits of the National Science Digital Library (NSDL) Concept Create a comprehensive digital library for all aspects of science education, where science and education are both defined very broadly. The National Science Foundation studied potential benefits for five years before going ahead. It came to the conclusion that, even though the benefits could not be quantified, the potential was sufficient to justify a major program.

20. 20 CS 501 Spring 2005 Example 3: NSDL Timetable 1996Vision articulated by NSF's Division of Undergraduate Education 1997National Research Council workshop 1998SMETE-Lib workshop 1999NSDL solicitation 20006 demonstration projects of the core system 2001Core integration system funded Note: 5 years from concept to decision to definitely go ahead.

21. 21 CS 501 Spring 2005 Feasibility Study: Technical A feasibility study needs to demonstrate that the proposed system is technically feasible. This requires: a rough outline of the requirements a possible system design (e.g., database, distributed, etc.) estimates of numbers of users, data, transactions, etc. possible choices of software to be acquired or developed These very rough numbers are fed into the provisional plan that is used to estimate the staffing, timetable, equipment needs, etc. The technical approach actually followed may be very different.

22. 22 CS 501 Spring 2005 Feasibility Study: Planning and Resources The feasibility study should include an outline plan: Estimate the staffing and equipment needs, and the preliminary timetable Identify major decision points Identify interactions with and dependences on external systems Provide a preliminary list of deliverables and delivery dates Lecture 4 is about planning techniques.

23. 23 CS 501 Spring 2005 Feasibility Study: Alternatives and Risks A feasibility study should identify alternatives and risks. Alternatives Continue with current system, enhance it, or create new one? Develop in-house, or contract out? (How will a contract be managed?) Risks What can go wrong? How will problems be identified (visibility)? Are there fall-back options?

24. 24 CS 501 Spring 2005 Techniques for Feasibility Studies Give client appreciation of system: demonstration mock-up walk through Outline budget: n people for m months at $x per month equipment, buildings, etc. Phases/milestones: deliverables at approximate date

25. 25 CS 501 Spring 2005 Feasibility Report A written document 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 are often included in supporting documents. It should be a well written, well presented document.

26. 26 CS 501 Spring 2005 CS 501: Client In CS 501, you have two clients: The client for the project The professor for the course Can you satisfy them both?

27. 27 CS 501 Spring 2005 CS 501: Resources Examples: CS 501 Staff: 5 to 7 students, with some help. How many hours per week? What skills do people have? Time: Must be completed by end of semester, including operational system, documentation, presentation Equipment and software: What special needs are there? Client: Will the client be sufficiently available and helpful?

28. 28 CS 501 Spring 2005 CS 501: Obstacles CS 501 projects Start-up time. Creating a team, scheduling meetings, acquiring software, learning new systems,... Business considerations. Licenses, trade-secrets,... Too ambitious. Nothing to show at the end of the semester... Changing circumstances. Client leaves the university,... What else?

29. 29 CS 501 Spring 2005 CS 501: How to Minimize Risk? CS 501 Projects Several target levels of functionality: required, desirable, optional phases Visible software process: intermediate deliverables Good communication within team and with Teaching Assistant Good processes lead to good software Good processes reduce risk

30. 30 CS 501 Spring 2005 CS 501: Feasibility Report Specific Requirements for the Feasibility Report Outline plan, showing principal activities and milestones (to be discussed on Thursday). Discussion of Business Considerations (see Projects page on the course Web site). Risk analysis. What can go wrong? What is your fall back plan? *