1 cs 501 spring 2002 cs 501: software engineering lecture 3 feasibility studies

26
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

Upload: buddy-merritt

Post on 04-Jan-2016

218 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

1 CS 501 Spring 2002

CS 501: Software Engineering

Lecture 3

Feasibility Studies

Page 2: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

2 CS 501 Spring 2002

Administration

News group: nntp://newsstand.cit.cornell.edu/cornell.class.cs501

Wednesday evening section this week:

Project team formation and discussions

Today:

AnnouncementsLecture on Feasibility StudiesDiscussion of Pfleeger, Chapter 2

Page 3: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

3 CS 501 Spring 2002

Administration

Project teams:

• If you have definitely chosen a project, please notify the Teaching Assistants with the names of your team members

• If you do not have a team you can meet after class

• Wednesday's recitations session will be to help the people who do not have projects form teams

• We may ask teams to add extra members

• A Teaching Assistant will be added to each team.

Page 4: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

4 CS 501 Spring 2002

Feasibility Study

Before beginning a project, a (usually) short, low-cost study to identify:

• Client

• Scope

• Potential benefits

• Resources needed:

staff, time, equipment, etc.

• Potential obstacles

Where are the risks? How can they be minimized?

Page 5: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

5 CS 501 Spring 2002

Feasibility Study

A feasibility study leads to a decision:

go aheaddo not go aheadthink 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.

Page 6: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

6 CS 501 Spring 2002

Example: Library of Congress(Poor Process)

Outline Description

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.

Page 7: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

7 CS 501 Spring 2002

Chronology (Bad)

1993-94 CNRI carried out research on architectures for digital libraries.

1995-97 CNRI developed prototype repository for Library of Congress.

1998 CNRI and Library of Congress realized that the project was going in the wrong direction.

Page 8: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

8 CS 501 Spring 2002

Bad Discoveries During Prototype

• Resistance to change within Library of Congress

• Technical weakness of Library of Congress

• Gaps in CNRI architecture

Page 9: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

9 CS 501 Spring 2002

Mistakes

• Confusion of objectives (research and implementation)

• Failure to involve all stakeholders

• Over-ambitious (no proper feasibility study)

Page 10: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

10 CS 501 Spring 2002

Repository: Research During Prototype

1. CORBA implementation of repository access protocol.

2. Integration of persistent naming through handle system.

3. Use of structural metadata to describe complex objects, elementary typology.

4. Access management framework and implementation.

5. Applet-based middleware for user interfaces.

6. Information visualization program to view the structure of large collections.

As research this was excellent, but it did not help the client build a production system.

Page 11: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

11 CS 501 Spring 2002

Example: NSDL (Long Process)

1996 Vision articulated by NSF's Division of Undergraduate Education

1997 National Research Council workshop

1998 SMETE-Lib workshop

1999 NSDL solicitation

2000 6 demonstration projects (core system)

2001 1 large core integration system funded

Page 12: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

12 CS 501 Spring 2002

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., British auto licensing center.)

Therefore, feasibility studies rely heavily on the judgment of experienced people.

Mistakes made at the beginning are the most difficult to correct.

Page 13: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

13 CS 501 Spring 2002

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

Page 14: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

14 CS 501 Spring 2002

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?

Page 15: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

15 CS 501 Spring 2002

Scope

What are the boundaries of the project?

CS 501 Examples (Fall 2000):

• Static web pages with open access on the Web [Web Profiler]

• Used by the general public [Digital Collections]

• Varying data formats [Legal Information]

• Thousands of sensors [Data mining]

• Support for Windows, Mac, Unix [SALSA]

Page 16: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

16 CS 501 Spring 2002

Potential Benefits

Why are you doing this project? Can you price 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

Page 17: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

17 CS 501 Spring 2002

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?

Page 18: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

18 CS 501 Spring 2002

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?

Page 19: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

19 CS 501 Spring 2002

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

Page 20: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

20 CS 501 Spring 2002

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.

In CS 501, I am looking for a well written, well presented document.

Page 21: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

21 CS 501 Spring 2002

Discussion of Pfleeger, Chapter 2

Format:

State a question.

Ask a member of the class to answer.

(Sorry if I pronounce your name wrongly.)

Provide opportunity for others to comment.

When answering:

Stand up.Give your name or NetID. Make sure the TA hears it.

Speak clearly so that all the class can hear.

Page 22: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

22 CS 501 Spring 2002

Question 1: Steps in the Waterfall Process

1. Give a short description of the Piccadilly television advertising project.

2. This project is likely to have some sort of database. Give an example of a requirement that is part of the decision making to use a database.

3. At what stage in the waterfall process, would the decision be made to use a relational database?

4. At what stage in the waterfall process, would the decision be made to use an Oracle database?

5. At what stage in the waterfall process would the database schema be specified?

Page 23: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

23 CS 501 Spring 2002

The Waterfall Model

Requirements Analysis

System design

Unit & Integration Testing

System Testing

Operation & Maintenance

Program design

Coding

Acceptance Testing

Page 24: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

24 CS 501 Spring 2002

Question 2: Risk

Suppose that a major requirement is changed during the development of a software system.

1. How is this accommodated in the iterative refinement model?

2. How is this accommodated in the waterfall model?

Page 25: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

25 CS 501 Spring 2002

Question 3: Acceptance Testing

1. What is the purpose of Acceptance Testing?

2. Where does Acceptance Testing occur in:

the waterfall model?

iterative refinement?

the V model of development?

3. What impact do these differences have on the project risk?

Page 26: 1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 3 Feasibility Studies

26 CS 501 Spring 2002

Question 4: Prototype and Phased Development

1. How does a prototype differ from phased development?

2. Explain the following figure:

Build release 1

Build release 2

Build release 3

Userelease 1

Userelease 2

Userelease 3

Developers

Users