Semester Project - 2005

1. Introduction

The goals of the semester project are to give you a chance to apply the techniques of Responsibility-Driven Design

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

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

In other words, the set of artifacts you used to guide the implementation phase of your project.

3.2 Implementation Artifacts

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

8. Evaluation

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 <kena@cs.colorado.edu>. Answers to common questions will be discussed in class and/or posted to the class website.