Semester Project - 2005
The goals of the semester project are to give you a chance to apply the techniques of Responsibility-Driven Design
- within a group setting,
- on a project of non-trivial size,
- across multiple stages of the software life cycle (including analysis, design, implementation, testing, and deployment).
In-class students should divide into teams of three to four students and identify a non-trivial domain within which they can identify a problem that can be solved via the creation of a software system. (Two person teams are acceptible if reasonable justification is provided. One person teams will be aggressively discouraged and only granted in extreme circumstances. I CAN NOT grade 54 individual projects!!!) The domain should be “rich” in concepts and relationships such that the team has ample material to perform analysis and design to produce interesting object models, use cases, and collaborations.
Once the domain and problem has been identified, the team will perform responsibility-driven design to create a software system that addresses (or solves) the problem. In other words, the system should meet the responsibilities identified for it by the team's work during analysis and design.
2. Example Domains and Programs
- Web Syndication and RSS Readers
- Web-Based Information Systems
- Productivity Tools: e.g. word processor, image editor, diagram editor
- Software-Design Tools: e.g. UML editors, integrated development environments
- Computer Games: e.g. role-playing games or real-time strategy games
Obviously, any one of these domains contains problems that might take an experienced development team, years to complete! As such, the first step after identifying a domain and a problem within that domain will be to scope the problem down such that an interesting software application can be designed and developed within 8 weeks.
3. Required Artifacts
The team will be required to produce the following artifacts when submitting the work for their final project:
3.1 Analysis and Design Artifacts
- CRC Cards (as they existed at the end of the design phase)
- A UML class diagram of those cards
- A set of use cases
- A set of sequence or collaboration diagrams that document critical collaborations.
In other words, the set of artifacts you used to guide the implementation phase of your project.
3.2 Implementation Artifacts
- A .zip or .tar.gz archive of the source code of your project. This archive should also contain build scripts, data files, or anything else needed to run your program. In addition, it should contain the set of test cases that you used to test the source code of your system.
- A class diagram documenting the classes of the final system (can be split into multiple parts, if needed).
- A diagram showing the overall architecture of the implemented system. This diagram should emphasize subsystems, layers, packages, etc. That is, it should complement, not duplicate, the information provided by the class diagram.
3.3 Supplementary Information
Each team member should send Professor Anderson an e-mail evaluating the efforts of their fellow teammates. Did each team member pull their weight? What problems were encountered and how were they resolved? These evaluations CAN impact your grade on the project.
4. Final Demonstation
Each team will meet with Dr. Anderson by Tuesday, May 3, 2005 to give Dr. Anderson a demonstration of the system they created for their project and to hand in the artifacts requested above (the code archive should be submitted via the moodle or sent to Dr. Anderson via e-mail). Send e-mail to Dr. Anderson to schedule this meeting; there should be time during the last week of class for teams to give these demonstrations, if you do not want to meet with Dr. Anderson outside of class. Note: early submissions are encouraged!
5. CAETE Variations
CAETE students can work on this project by themselves. While they must still create the artifacts above, it should be at a scale reasonable for one person.
CAETE students local to Boulder/Denver should arrange to meet with Dr. Anderson by Tuesday, May 10, 2005 to give him a demonstration of your project. CAETE students who do not live nearby should arrange to speak to Dr. Anderson by telephone by May 10, 2005 to give him a demonstration of your project. (This implies that such students should create a prototype in Java or that can be viewed on the Web so that Dr. Anderson can view the demonstration while speaking with you on the phone.)
6. Feedback during Development
Teams should keep Dr. Anderson informed of their progress (via a weekly e-mail), so he can tell you if you are doing too much or too little for the project and to answer any questions you may have.
7. Suggested Software Life Cycle
Here is one suggestion for a life cycle for this project. (CAETE students slide everything back by one week.)
|Week 1: 03/07/2005 - 03/11/2005||Team Formation and Domain/Problem Selection|
|Week 2: 03/14/2005 - 03/18/2005||Analysis|
|Week 3: 03/21/2005 - 03/25/2005||Spring Break|
|Week 4: 03/28/2005 - 04/01/2005||Design|
|Week 5: 04/04/2005 - 04/08/2005||Implementation|
|Week 6: 04/11/2005 - 04/15/2005||Implementation|
|Week 7: 04/18/2005 - 04/22/2005||Testing|
|Week 8: 04/25/2005 - 04/29/2005||Testing|
|Week 9: 05/02/2005 - 05/03/2005||Demonstration|
The project is worth 150 points for each student. (A team of 4 should be expending effort equivalent to 600 points.) The project will be evaluated for the quality of the submitted artifacts and the quality of the final demonstration. A grade will be calculated for the team as a whole. Each member will receive that grade after the evaluations of your teammates have been factored in. Thus, if a team receives a score of 140 for the project, a student rated highly by their team members may receive a score of 150, while a student rated poorly by their team members may receive a score of 130 (or lower).
9. Any questions?
Send questions to <firstname.lastname@example.org>. Answers to common questions will be discussed in class and/or posted to the class website.