CSCI 311 Semester Project

(Spring Semester, 02)

Introduction:

The semester project for CSCI 311 is a Requirements / Analysis / Design project, which does not involve coding. The purpose of the project is to help the student become familiar with requirements gathering using use cases, and object-oriented analysis and design.

Although coding is not involved with this project, you may choose a project which involves coding in another class, or as part of your Master’s project. If you cannot decide on a project, the instructor has one project which you can do which will involve some Java coding, and which will take about as much effort as any average project in the class.

Scope of the Project

The project comprises 40% of your grade in this class. I expect the project to be neither too small or too large. If the project has somewhere in the neighborhood of 10 – 20 use cases, and 10 – 20 classes, it is probably in the right range. If you have chosen an overly ambitious project, you might decide to do just a subsection (subsystem) of the overall project, which might then fall into the correct range for use cases and classes.

Teams

I expect the students to work in teams for this project. Teams should ideally contain 3 people, although teams of 2 or 4 people are allowed. If you absolutely must work alone, please come and talk to me about the situation.

There are two reasons for teams. First, analysis and design documents rarely come out good when only one person works on them. I expect you to bounce ideas off of each other, and to find flaws in each other’s logic. This will lead to designs which are far more “waterproof” than when one person works on a design alone.

The second reason, quite honestly, is to reduce the grading workload on me. We have quite a few people in this class, and I am responsible for over 120 students overall this semester.

Two or more teams may do the same project, but they better not collaborate with each other too closely. Nearly identical projects may result in a zero on the project, which will probably result in an F for the class. (You could theoretically still get a D). Two identical projects from different teams means a lot of people are in a lot of trouble.

Deliverables

There will be four deliverables for the project:

1. Proposal, written on the Proposal / Requirements Template, which will be e-mailed to you.

2. Requirements, including a use case model, again written on the Proposal / Requirements Template, and using the use case templates. These will be e-mailed to you.

3. Analysis Model

· Candidate Class Catalog

· Class Diagrams

· Data Dictionary

4. Design Model

· Expanded Class Diagrams

· Sequence Diagrams or Collaboration Diagrams

· State Diagrams for controller classes or use cases

Deliverable Dates

1. Proposal: Wednesday, Feb 20^th, 02

2. Requirements: Monday, April 29^th, 02

3. Analysis Model: Wednesday, May 22^st, 02 (Finals Day)

4. Design Model: Wednesday, May 22^nd, 02 (Finals Day)

Other Important Dates (Tests):

Test 1: To be determined

Spring Break: March 25^th -- April 1^st

Test 2: To be determined

Final: Wednesday, May 22^nd, 02 (2:00 – 3:50 PM)

Reviews:

Each team will have another team review their work. The reviewing team cannot be doing the same project as the reviewed team. The reviewing team will have part of their project grade based on the other team’s grade! So they better take the reviews seriously.

THIS IS NO JOKE. The last 311 class I taught did not take this seriously, and several people were nicked badly in their grades by letting friends’ projects slip through with poor or no reviews. REVIEW the other team’s project as if your grade depends on it, because it DOES!

It is the responsibility of the reviewed team to make their work so clear that another group of people, with little or no idea of what they are doing, can understand their work. It is the responsibility of the reviewing team to grill the reviewed team on any vague, ambiguous, and/or incorrect concepts, ideas, and modeling constructs.

Grading

The following grading policy will be in effect for the project. Percentages are in terms of the overall course percentage:

Deliverable	Grade on Work	Difficulty Weighting	Grade on Reviewed Work
Proposal	6%	Usually 1.0	2%
Requirements	8%	Usually 1.0	4%
Analysis Model	7%	Usually 1.0	3%
Design Model	8%	Usually 1.0	2%

Late Policy

As this class does not have off-site participation (i.e., not a satellite class) the late policy will be somewhat more stringent than for the satellite classes. Basically, you will lose 10% off your grade for each week a deliverable is late. Please note that no deliverable can be handed in if the previous deliverable has not been handed in.