CSSE 220 – Object-Oriented Software Development
Capstone Team Project

Overview

For this project you will design and implement a computer game of your own choosing, subject to the constraints that it must:

Regarding networking: a two-player game is fine, and the game can require the players to cooperate or compete (your choice). You may strive for a more-than-two player game if you wish, but that is not required. Be cautious about games that require large amounts of information to be exchanged in real time.

Regarding the three categories of feaures: It is very difficult for you to “scope” the project appropriately for a 3-week team project. By listing your features in three categories, you allow yourself to recover from a badly scoped project (either one that turns out to be too easy or one that turns out to be too hard). See Grading below for how this affects the grading.

Administrative Background

This is a team assignment and all that we said about that in VectorGraphics' Administrative Background section applies here as well.

Subversion Repository

Continue to use the same SVN repository for this assignment as you did for VectorGraphics, but checkout the CapstoneProject project from that repository, and all subsequent work should be placed in this project folder and committed back to your repository.

Process

Continue to use the same Rules and Practices of Extreme Programming listed in the VectorGraphics' Process section.

Deliverables

You will produce the same deliverables described in the VectorGraphics' Deliverables section.

Project Schedule and Milestones

Cycle 0 (for specification and design — not a development cycle) Cycle 1 Cycle 2 Cycle 3
May 5 - May 12 May 12 - May 15 May 15 - May 19 May 19 - May 22

 

Milestone date Time due Deliverable(s) due
Thursday, May 7 By the END of class: Screen Layout sketch, draft
CRC cards
Friday, May 8 By the END of class: Screen Layout sketch, final
  • This should be a “final” draft, in that you are ready to work from it, but you are permitted to change your Screen Layout / User Interface during the project.
  • If you do choose to make changes, make sure that all team members agree to the changes. One way to be certain of agreement is to update the Screen Layout sketch and have everyone initial the updated sketch.
UML class diagram, draft
  • When your UML class diagram is ready for my review (either after class or sometime during the weekend), email it to me. I'll give you feedback soon thereafter.
  • Your UML class diagram is a living document. It will almost certainly change some (hopefully not radically) during the project. Just commit the new version to your repository, each time you make changes.
  • At this point, your UML class diagram should contain all the classes you anticipate for the project, with all their relationships (arrows). It should also contain details (attributes and properties) that you can already see to be relevant, although many of those details will await your UML class diagram update for Cycle 1 (see below).
  • Do NOT do ANY CODING of CapstoneProject until:
    1. You have done your User Stories for Cycle 1, AND
    2. I have reviewed your UML class diagram and approved it. (I may or may not ask for changes or an entire second draft before approving it.)
    • You can do Swing Experiments, just not CapstoneProject itself.
Tuesday, May 12 By the BEGINNING of class: Cycle 0 Swing Experiments (if any)
Cycle 0 Individual Reports (one for each team member)
By the END of class: Cycle 1 User Stories
UML class diagram UPDATED to contain details (attributes, properties) relevant to Cycle 1
  • Do NOT do ANY CODING of Cycle 1 until:
    1. You have done your User Stories for Cycle 1, AND
    2. I have approved the draft of your UML class diagram, AND
    3. You have updated your UML class diagram for Cycle 1.
  • Implement by using documented stubs. Commit your work after stubbing, to demonstrate that you are doing so.
  • Do at least 1/3 of your coding using pair programming. Document this in your individual reports.
Cycle 1 Task List
  • Your Task List can (and often will) change during the cycle. Commit changes to your repository when you update the file.
By midnight: Your Team Evaluation Survey for Cycle 0
Friday, May 15 By the BEGINNING of class: Cycle 1 Swing Experiments (if any)
Cycle 1 Status Report
Cycle 1 Individual Reports (one for each team member)
By the END of class: Cycle 2 User Stories
UML class diagram UPDATED to contain details (attributes, properties) relevant to Cycle 2
  • Do NOT do ANY CODING of Cycle 2 until:
    1. You have done your User Stories for Cycle 2, AND
    2. You have updated your UML class diagram for Cycle 2.
  • Implement by using documented stubs. Commit your work after stubbing, to demonstrate that you are doing so.
  • Do at least 1/3 of your coding using pair programming. Document this in your individual reports.
Cycle 2 Task List
  • Your Task List can (and often will) change during the cycle. Commit changes to your repository when you update the file.
By midnight: Your Team Evaluation Survey for Cycle 1
Tuesday, May 19 By the BEGINNING of class: Cycle 2 Swing Experiments (if any)
Cycle 2 Status Report
Cycle 2 Individual Reports (one for each team member)
By the END of class: Cycle 3 User Stories
UML class diagram UPDATED to contain details (attributes, properties) relevant to Cycle 3
  • Do NOT do ANY CODING of Cycle 3 until:
    1. You have done your User Stories for Cycle 3, AND
    2. You have updated your UML class diagram for Cycle 3.
  • Implement by using documented stubs. Commit your work after stubbing, to demonstrate that you are doing so.
  • Do at least 1/3 of your coding using pair programming. Document this in your individual reports.
Cycle 3 Task List
  • Your Task List can (and often will) change during the cycle. Commit changes to your repository when you update the file.
By midnight: Your Team Evaluation Survey for Cycle 2
Friday, May 22 By the END of class: Cycle 3 Swing Experiments (if any)
Cycle 3 Status Report
Cycle 3 Individual Reports (one for each team member)
Final working code
By midnight (FIRM deadline for graduating seniors!): Your Team Evaluation Survey for the entire project
Extensions Plan on completing your project per the above schedule — that's best for you. But I'll grant request for short extensions (a day or two or maybe even three) with no penalty except for graduating seniors (for whom I need to turn in grades Saturday morning, May 23).

Descriptions of deliverables

Features

You establish the Required, Additional and Bonus features for your project. List these features, in their respective categories, in your Screen Layout document.

Grading

You will determine the Required, Additional and Bonus features for your project.

Here is my grading plan: First, compute the process score, which is 30 points based on:

Then compute the implementation score, which is 70 points as follows: Your overall score is the sum of your process and implementation scores.