A perennial problem for our department is scheduling classes in available rooms, because there are lots of constraints to satisfy:
You have some flexibility in deciding exactly what functionality to provide; that's part of the design problem. In a real-world situation, you would have a ``customer'' whose needs you are trying to meet, and part of the design problem might be to turn a vague initial problem description into something more specific. For this class, I will play the role of customer, so part of the analysis phase of the project might be asking me questions to help you clarify requirements. Class time will be available for this purpose, or you may ask me in office hours or via e-mail (being sure to coordinate with other members of your group.)
Customers typically also impose constraints (how much a solution can cost, what hardware/software platforms it must run on, etc.). For this project, the following constraints apply.
A project such as this one can be broken down into three phases:
The following table lists ``deliverables'' on which you will be graded. Items with a ``Y'' in the column labeled ``Group?'' are to be turned in by group leaders (and should represent the combined efforts of the members of the group); other items are to be turned in by individual students (and should represent individual efforts). Notice that the points add up to the 75 points specified in the syllabus for the project.
| What | Group? | Due | Points |
|---|---|---|---|
| Preliminary requirements analysis | Y | February 22 | 5 |
| Midterm report | Y | March 22 | 10 |
| Midterm group evaluation | N | March 22 | 5 |
| Presentation | Y | April 19 | 15 |
| Final report | Y | April 26 | 20 |
| Prototype code | Y | April 26 | 15 |
| Final group evaluation | N | April 26 | 5 |
Your first deliverable is a short report presenting the results of your requirements analysis -- a list of use cases, a UML use-case diagram, and a short text description of each use case.
Your next deliverable is another short report, incorporating the previous report (possibly with improvements or corrections) and adding a sketch of your implementation design, in the form of a description of classes you will write and a UML class diagram showing their relationship.
Each student will also evaluate the performance/contribution of members of his/her group. I will use this information in determining grades. Forms will be provided.
Each group will present its analysis of the problem, its proposed solution, and a prototype implementation. The presentation should include UML diagrams of your requirements analysis (use case diagram(s)) and your design (class diagram(s)) and a brief demonstration of your prototype implementation. Each group will have 20 minutes, plus 5 minutes for questions.
Your final report should be an expanded version of your midterm report, incorporating any changes you have made (particularly to the implementation design) and also describing your prototype implementation.
You are not required to come up with a complete implementation of your design; this course is meant to be about design more than implementation. However, before starting a complete implementation it can be extremely helpful to develop a prototype that shows your ``customer'' what you have in mind, to be sure that what you plan to implement really meets his/her needs. Thus, you will develop a prototype implementation you can demonstrate. Prototype implementations generally focus more on the parts of the system that ``show'' -- that is, the user interface. For this project, ideally you would build as much as you can of the part of the program that actually figures out the schedule, subject to time constraints.
See ``Midterm group evaluation.''