| Date | Description | Points |
|---|---|---|
| 4-5 | Management Plan | 60 |
| 4-12 | Test Plan/Progress Review | 40 |
| TBD | Feature Freeze | 0 |
| TBD | Beta Release | 30 | TBD | User Test | 20 |
| 4/28 | Code review | 20 |
| 5-14 2PM (exam time) | Version 1 | 30 |
| 5-14 2PM (exam time) | Final Documentation | 30 |
In phase 2 you developed your alpha release. In phase 3 you'll version 1 of your game. This phase is worth 230 points.
An initial management plan should be submitted on 4/5/10. This plan should include
By Monday class time each week, you should update your project plan to reflect the proposed work for the coming iteration (1 week). This includes a new risk analysis, further elaboration of your goal breakdown, updating your goal stack and identifying the goals to be achieved in the coming week, and issuing tickets for those goals. You must also provide a brief status report that explains how well you achieved your goals for the previous week. Your management planning will be graded on a weekly basis with 20 points assigned to the initial plan and 10 points for each of the four weekly updates (last update due 5/31). The grading rubric for the inital plan is:
Your team will (a) submit your test plan/progress for review and (b) review that of another team. More specifically, teams 1 and 4 will pair up as will teams 2 and 3. The materials you submit for review will be graded for quality on a 15 point scale. The quality of the review you perform will be graded on a 10 point scale (2.5 points per person). Reviews will take place in class on 4/12.
After the test plan review your team will be required to conduct regression testing (before checking in updates) and bug tracking. These activities should be documented on your wiki (including tickets for bug reports). You will be graded each week on a 5 point scale.
The beta release is a version of your final game that will be released for testing by students at Hillside. Some time prior to the beta release you need to declare a feature freeze. Between the feature freeze and the release date you will finish testing your game and complete any necessary documentation for its release. You don't get any points for this but you must schedule it!
The beta release is a version of your final game that will be released for testing by students at Hillside. It will be evaluated on the following:
Since you will not be present when Hillside students play your game, you must develop a test protocol for the teachers to follow. For example, you may want the teachers to read instructions that you prepare. You may want students to play in pairs, with one playing the game and one recording problems. You may want to have the software record some usage statistics that need to be mailed to you when the test is done. And you will probably want to construct a survey that students complete after finishing the game. The overall design of the test protocol is up to you but you must be clear about what you want to achieve in this test (and document the goals on your wiki). You should plan the test to take no more than 30 minutes. You should analyze test results and write a wiki report. Your user test will be graded on:
Your team will (a) submit your code for review and (b) review that of another team. Specifically teams 1 and 3 will pair up as will teams 2 and 4. Each team member will be assigned a specific portion of code to review. Individuals will be graded on the review they conduct on an 5 point scale.
Like the beta, your final game will be evaluated on functionality, usability, reliability, entertainment value, and educational merit.
You are required to document your product in various ways:
Your main wiki page should include a table of phase 2 milestones, the date they were completed, links to the associated deliverables, and an accounting of late days.
Each team is entitled to three late days. A late submission that is not redeemed with late days loses ten percent of its value for each day missed. Note that a late day is only good for one deliverable, subsequent delays require additional slip days. For example, if a prototype is one day late, and that delays the final report by a day, you need to use two late days in order to avoid penalties.You should apportion responsibility for each late day to team members. In the previous case, if one person was responsible for missing the prototype deadlines, both late days should be attributed to that person.