Computer Science 121 - Project Phase 2

Alpha design and implementation

Spring 2010

Project Phase 2 Deliverables

Date Description Points
2-22 Management Plan 55
TBD Architectural Design 30
TBD Design Review 10
TBD UI Design 25
TBD Test Plan 20
3-29 Alpha Release 55
3-31Post Mortem 5


Project Description

  1. Project Overview
  2. Project Component Description
  3. Grading
  4. Rules and Submission

1. Overview

In phase 1 you developed your game concept. In phase 2 you'll develop an alpha release, which is a small, playable game that will be tested in the Hillside classrooms. The alpha release will be a scaled down version of your final game, but one that provides a good represetation of the gameplay experience. In terms of implementation, the alpha release should include a stable architecture and user interface. It is up to you to define your alpha release then carry out its planning, design, construction, and testing.

2. Project Components

2.1 Management Plan

An initial management plan should be submitted on 2/22/10. This plan should include

  1. Description of the major areas of responsibility for each team member.
  2. Definition of your alpha release using use cases, storyboards, and/or other models you deem appropriate. You should define the "must have" and "want to have" features and capabilities.
  3. Proposed due dates for the required deliverables and any other major deliverables you deem important.
  4. Risk analysis.
  5. Initial goal breakdown for phase 2 including (at least) the required deliverables and their dependencies.
  6. Goal stack including well-modeled goals for (at least) the next week of the project (ending 3/1).
  7. Plan for the next week including goals to be achieved and team members' responsibilities (via tickets).
  8. A summary of work completed in the first week of the project (ending 1/22).
Your goal breakdown should divide the major deliverables of phase 2 into smaller and smaller subcomponents until they represent well-defined tasks that can be completed by one person in a couple of hours. Your goal stack will contain the prioritized and sequenced nodes of your goal breakdown. By sequenced we mean that a goal cannot appear above any of its (AND) subgoals in the stack. You need not completely break down all goals at the beginning; just be sure that goals at the top of the stack are well-defined tasks. It is important, however, that you resolve major risks early; e.g. by exploratory work (goals) such as proofs of concepts.

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 25 points assigned to the initial plan and 10 points for each of the three weekly updates. The grading rubric for the inital plan is:

The grading rubric for each update is:

2.3 Architectural Design

A major component of the phase 2 work is development of your software architecture. You will develop a design, the design will be reviewed by another team, and then you'll revise the design based on review recommendations. Your design should include

  1. Use cases your architecture will realize (these will typically be the "must have" use cases).
  2. Class diagrams including all major classes, their interfaces, and their relationships.
  3. Sequence diagrams illustrating how the classes collaborate to realize the use cases.
  4. Descriptions of other non-trivial mathematical models, algorithms, data structures, and data input formats required to implement your architecture.
  5. Discussion of your design including its good points (in terms of good design principles) and its bad ones (problems you couldn't resolve).
Your final design will be graded as follows:

2.4 Design Review

Your team will (a) submit your architecture design for review and (b) review the design of another team. More specifically, team i will review team i + 1. The materials you submit for review will be graded for quality on a 5 point scale. The quality of review you perform will also be graded on a 5 point scale. One review will take place in class. Participants are guaranteed full credit in exchange for being guinea pigs. (Note: A grutor or I must observe the out-of-class design review so be sure to include us in scheduling discussions.)

2.5 UI Design

You will design the user interface of your game (not the just the alpha release), user test it, then revise the design based on the reviews. Team i will act as users to test the design of team i-1. Your design will include wireframes and their relationships. You will prepare and execute a user test then report on your findings. Finally you will revise your design to incorporate results of the test. (Note: A grutor or I must be present for your user test so be sure to include us in scheduling discusssions.)

Your grade will be based on

2.6 Test Plan

You will develop a test plan that includes unit, component (class or collection of classes), and integration tests. You will use test-driven development; that is you will devise tests for your code before you implement, then use the tests to evaluate the implementation. You will also use regression testing; that is a suite of tests your code must pass every time you update the repository. Your test should include the following:

  1. For each non-trivial method, devise unit tests that, in particular, test boundary and error conditions.
  2. For each component, identify the areas of high risk (where errors are likely or where they would be difficult to track) and develop component (black box and white box) tests.
  3. Identify areas of high risk cross-component functionality and devise appropriate (black box) tests.
Finally, you will document your plan and provide a rationalization for your choices.

Your grade will be based on

2.7 Alpha Release

Your alpha release deliverable will include the game executable and installation/execution instructions, source code, UML documenting the implementation, an evaluation of your testing and final bug report, and a discussion of how your implementation differs from your original design. You will be graded as follows:

2.8 Post Mortem

This project is a learning exercise, and one of the major ways we learn is by analyzing past mistakes. You will, as a team, review all aspects of this phase of the project then summarize that process into a post-mortem analysis report. It should specifically address each component of the phase. You will be graded on the basis of:

3. Grading

This phase of the project is worth a total of 200 points. For each component, the team will assign a percentage to each team member based on their contributions to the component (the percentages should, of course, add up to 100%). Grades for each team member will be based on a contribution weighted average of earned points for the components. The resulting score will be normalized based on team size and overall scope of project. It is expected that a team of size 5 will produce a project with larger scope than a team of size 4! It is your job to choose an appropriate scope to your project.

4. Rules and Submissions

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.