Computer Science 121 - Project Phase 2

Alpha design and implementation

Spring 2011

Project Phase 2 Deliverables

Prototypes/Code development (40 pts)
Deliverable Date Component Points
Management Plan (25 pts) 2-15 Initial Plan 5
2-24, 3-3, 3-10, 3-24 Weekly updates 5 each
Architectural Design (40 pts) 2-15 Architectural Design Draft 10
2-22 Architectural Design Review Package 10
2-24 Design Review 10
3-8 Final Architecture 10
UI Design (30 pts) 2-22 Initial UI Design 10
2-27 User test 10
3-8 Final UI Design 10
Testing (35 pts) 3-1 (delayed to 3-8) Test Plan 10
3-3 (delayed to 3-8) Test Plan Review 10
3-8 (cancelled), 3-22, 3-29 Weekly test reports 5 each
2-22, 3-1, 3-8, 3-22 Executable and report 10 each
Alpha release (25 pts) 3-29 Executable 10
3-29 Class presentation 5
3-31 Documentation 10
Postmortem (10 pts) 4-5 Product 5
4-5 Process 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 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

(25 pts. total)

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. Though The bottom up efforts are primarility prototypes and it is your job to define these well, based on risk assessment, to ensure your alpha can be completed on time. Your weekly meeting notes should include a rationale for your choices! As in phase 1, your wiki should include:

Your management plan will be graded on clarity and completeness

2.2 Architectural Design

(40 pts. total)

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.

2.2.1 Architectural Design Draft (10 pts.)

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 and their parameters should be identified
  4. Sequence diagrams illustrating how the classes collaborate to realize the use cases
  5. Critique of the design with respect to good design principles
Each section described above is worth 2 points and will be judged for clarity, correctness, completeness, and quality.

2.2.2 Architectural Review Package (10 pts.)

The second draft of your architecture should address issues raised in your critique. It should also define the important components of the class interfaces and any input/output specifications. Finally, the underlying models and major algorithms and their parameters should be described. This design will be reviewed by another team. 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)

Your package will be evaluated for clarity and completeness (5 pts). Your design will be evaluated for quality (5 pts).

2.2.3 Architectural Review (10 pts.)

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 discussion during the review. You will be graded on your preparation and how well you can answer the questions described above.



2.2.4 Final Architecture (10 pts.)

Based on the design review and your own critique, you will finalize your architecture and critique it. It will be graded on:

2.3 UI Design

(30 pts. total)

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.

2.3.1 Initial UI Design (10 pts.)

You will develop a preliminary UI design using whatever technology use deem best (e.g. paper, electronic wireframes, etc.). You will critique the design in terms of usability principles. Your grade will be based on the

2.3.2 User test (10 pts.)

You will user test your UI design on your classmates and on your grutors. You should test the entire design but focus, in particular, on the questions raised in your critique. You need to do a run through with your teammates of the UI test; you should videotape the process and upload the video to your wiki and post a copy to the Muddy Hill Games blog. You should also upload all material used in your tests and the test prototocol to your wiki. Your grade will based on

2.3.3 Final UI Design (10 pts.)

Your final design will graded on

2.4 Testing

(35 pts. total)

You will develop a test plan, submit it to review, and revise it as necessary. You will execute it over the course of development, critique it regularly, and update it as necessary.


2.4.1 Test Plan(10 pts.)

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 test plan will be evaluated (by another team as well as the grutors) as follows:


2.4.2 Test Plan Review(10 pts.)

You will review another team's test plan. Each person on your team will be assigned an aspect of the review and come prepared ot lead a discusion on that aspect during the review. You will be evaluated on your preparation and assessment.

2.4.2 Weekly Test Reports(15 pts. total)

You will implement your test plan and report weekly on progress, problems encountered, and changes to your plan. (Note, as your code evolves, so should your plan.)


2.5 Prototypes/code advancements

(40 pts. total)

You will plan and implement one or more prototypes or code advancements 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 as well as how you plan to test/assess the results. You will conduct an assessment at the end of the week. Your weekly prototypes/code advancements will garner up to 10 points as follows:

2.6 Alpha Release

(25 pts. total)

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 also give an in-class presentation and demo.



2.6.1 Executable (10 pts.)

Your executable will be graded for quality based on the quality:



2.6.2 Presentation (5 pts.)

You will give a 10 minute presentation/demo in class that will be evaluated by your classmates. <\p>

2.6.3 Documentation(10 pts.)

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
Each of these components is worth 2 points. In addition, you'll garner up to 2 points for the quality of your in-code documentation.



2.7 Postmortem

(10 pts.)

You will, as a team, perform a postmorten on the second phase of the project and write a report. The report should first address the work products your produced through the phase and then your processes.


Product Postmortem

Which work products were most successful? Which were least successful? How did the outcomes compare to your goals? What are the major problems in the alpha release? Why are those problems present and how could they have been avoided? What will you do in the next phase to correct them?



Product Postmortem

Which processes were most successful? Most beneficial? Which were least successful/beneficial? What can you do to improve your processes? How did the outcomes compare to your goals? What are the major problems in the alpha release? Why are those problems present and how could they have been avoided? What will you do in the next phase to correct them?

3. Grading

This phase of the project is worth a total of 215 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 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.