Computer Science 121 - Project Phase 2

Alpha design and implementation

Fall 2011

Project Phase 2 Deliverables

Major Deliverables Dates Component Points
Management Plan (120 pts) 9-22, 9-27, 10-4, 10-11, 10-25 Weekly updates 20 each
Architectural Design (140 pts) 9-27 First Architectural Design Draft 30
10-4 Second Architectural Design Draft 30
10-6 Architectural Design Review Package 20
10-11 Design Review 40
10-20 Final Architecture 20
UI Design (100 pts) 10-4 Initial UI Design 40
10-4 User test 40
10-11 Final UI Design 20
Testing (100 pts) 10-11 Test Plan 40
10-20, 10-25 Test plan implementation (2 stages) 30 each
Prototypes/Code development (90 pts) 9-27, 10-4, 10-11 Executable 30 each
Alpha release (100 pts) 10-25 Executable 60
10-27 Class presentation 20
10-27 Documentation 20


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 classroom. The alpha release will be a scaled down version of your final game, but one that provides a good representation 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

For phase 2, you will be working both top-down and bottom-up to produce an alpha release. It is up to you to define your alpha but it is important that it incorporate core architecture and provide a playable experience. The top-down efforts include architecture, UI, and test plan designs and reviews. The bottom up efforts are primarily prototypes and it is your job to define these well, based on risk assessment, to ensure your alpha can be completed on time.

As you plan this phase of the project you will define your alpha (through use cases) as well as the weekly prototypes you'll develop throughout the phase. The prototypes may be defined through uses case (prototypes that will evolve to your alpha) but may also represent proofs of concept to help ameliorate project risks. Your initial goal stack will consist of the uses case and proofs of concept you identify as well as the other deliverable described throughout this document. As usual, goals should be prioritized based on risk and those near the top of the stack should be well defined; by well defined we mean that they should be broken down into tasks that take no more than 2-3 hours. Note that many of the deliverables of phase 2 may take more than a week of effort, so be sure to plan ahead.

In this phase you should issue tickets for work assignments. Each team member should also keep a work log where they document the work they do, when they do it, and how long it takes. One of the goals of the third phase of the project is to develop your skill at developing time estimates; the logs you keep in phase 2 will be important for that effort.

You should have (at least) weekly meetings and post meeting notes (as described for Phase 1). The final meeting of this phase should be used to perform a postmortem on the phase.

This deliverables table trac template should be used for phase 2.

2.2 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. The core architecture should be implemented in the alpha release.

2.2.1 First Architectural Design Draft

Your initial draft design will include:

  1. Use cases your architecture will realize (these will typically be the "must have" use cases for your alpha release)
  2. Domain diagram based on your use cases
  3. Initial class diagram identifying major responsibilities for each class; important models/algorithms/data structures and their parameters should also be identified at this stage (e.g. scoring algorithms and simulation model)
  4. Sequence diagrams illustrating how the classes collaborate to realize the use cases
  5. Your own analysis of the design with respect to good design principles
Your design will be evaluated according this rubric.

2.2.2 Second Architectural Design Draft

Your revised draft design should address issues raised in your analysis. You should also extend your design to include

  1. important components of class interface (variables, methods, and their types)
  2. input and output specification
  3. description of important underlying models and algorithms (e.g. scoring algorithms and simulation models)
In addition, you should critique your design with respect to good design principles and design patterns.

Your design will be evaluated according to this rubric.



2.2.3 Architectural Review Package

The revised draft of your architecture will be reviewed by another team using this rubric. You will prepare an architectural review package that includes the following:

  1. Table of contents
  2. Introduction
  3. Architectural requirements including use cases
  4. Design documents including class diagrams, sequence diagrams, I/O specs, description of important models/algorithms/data structures
  5. Critique (problems you know about and ideas for resolving them)
  6. Where/how to access additional information (e.g. prototypes, proposal)



2.2.4 Architectural Review

You will review another team's architectural design with the goal of answering the following questions:

Each team member will be assigned responsibility for some aspect of the architecture. That person will come to the design review with an understanding of their portion, its strengths and weaknesses, and be able to lead discussions during the review. Through these discussion, the review team will agree on an assessment of the architecture, completing the architectural review rubric.

Individual members of the review teams will be graded on her/his preparation, contributions to the discussion, and role in assessing the architecture.



2.2.5 Final Architecture

Your final architecture design should reflect concerns raised in your design review and your own critique. Your meeting notes should include a discussion of any remaining issues of concern. Your final design will be evaluated by this rubric.

2.3 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 test.

2.3.1 Initial UI Design

You will develop a preliminary UI design using whatever technology you deem best (e.g. paper, electronic wireframes, etc.) If you use paper you need to scan it so you can upload it to your trac. You will critique the design in terms of usability principles. Your design will be evaluated according to this rubric.

2.3.2 User test

You will user test your UI design on your classmates and on your grutors. (Note: You need to do a run through of the test with your teammates before the in-class session and record your results.) You should test the entire design but focus, in particular, on the questions raised in your critique. A team members should take notes during the test and the notes should be uploaded to your trac.

2.3.3 Final UI Design

Your final design should address issues raised in the user test. It will be evaluated according to this rubric.

2.4 Testing

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. (In the next phase your test plan will be reviewed by another team.)

Once your test plan is finalized you should begin implementation. Tests should be developed in parallel with new code. In addition, you should implement your plan for any completed code that will be in your alpha release. You can do this over two weeks as you see fit.

2.5 Prototypes/code advancements

You will plan and implement one or more prototypes, proofs of concept, or extensions to existing code every week. The choice of what to focus on should be based on risk analysis. You will document your goals at the start of each week an assess your results at the end. (This should be part of your meeting notes.) You should link executables along with README files (indentifying the purpose and instruction on running the executable) to your trac.

2.6 Alpha Release

Your alpha release deliverable will include the game executable and installation/execution instructions. Note, your executable should not rely on any pre-installed software. (For example, if you are building in pygame you need to compile your source into an executable.) You will also give an in-class presentation and demo.

Documenting your design, tests, and code should be an ongoing process across Phase 2. When the alpha release is complete you should provide a wiki document that provides a roadmap to the various forms of documentation including:

  1. UML: use cases realized by the alpha release; class, sequence and other diagrams that provide a snapshop of your architecture and how it works to realize your use cases
  2. Tests: results of UI tests and test plan execution as wells as known bugs/issues report
  3. Installation/users guide: what do I need to know to run/play your alpha release
  4. Coding conventions used

3. Grading

This phase of the project is worth a total of 650 points. Rubrics for each of the work products are provided here. (The current rubric covers deliverables through 10/4. This will be updated for the entire phase soon.) 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 as well as peer reviews. The resulting score will be normalized based on team size and overall scope of project. It is your job to choose an appropriate scope to your project.

4. Rules and Submissions

Your wiki should include deliverables table that includes for each deliverable (as appropriate) its due date, possible point value, percentage grade distribution to team members, grade earned (to be filled in by our grutors), late days used, link to a separate wiki page that documents your progress/process on the deliverable, and a link to your actual submission.

Each team is entitled to four late days that can be applied to any phase 2 deadline except those involving in-class scheduled events (e.g. review packages or reviews). 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.