CS 121 -- Fall 2012

In Phase 1 you developed your game concept and in Phase 2 you produced an Alpha release. In Phase 3 you will produce a Beta, which is a feature-complete version of your game. During this phase you will practice a variety of review and testing techniques that reduce software defects and improve software usability. You are to continue all the practices that you have been following and also to update your project documents, e.g., UML, as you make changes.

A key point of Phase 3 is feature-complete. You are to add any and all features that you determine are important to your game to fulfill the original requirements. In Phase 4, you will only make improvements...no additional features. Thus, if you think some feature is important, now is the time to add it.

2. Summary of Phase 3 deliverables
3. Description of Phase 3 deliverables
4. Submission
5. Grading

2. Summary of Phase 3 Deliverables

3.1 Management

Management updates will continue through Phase 3 as described here.

3.2 Testing

In this phase you will implement the test plan designed in Phase 2 as well as extending it for any new code you write. You are required to maintain a test log that documents the tests you performed, when you performed them, and a summary of the results. The log also documents changes to the test plan. You are also required to maintain a list of known bugs; the description of a bug should be adequate for someone else (e.g. grutors) to reproduce it. (See lecture notes on bug reports. In the case you can't reproduce a bug, include as much information as you can about the conditions under which it arose and the effect.)

Entries in the test log might look like:

 4/2/12  2AM  performed test protocol A,
found one new bug:  Missing map

 4/2/12 6AM added new unit test for
myClass.doSomething(), ran and found no new bugs

Your test log, bug reports, and know bug list will be evaluated weekly according to this rubric.

3.3 Code development and critique

Throughout this phase you will continue to develop code. You will also assess your code using a variety of techniques.

In this phase you will develop code to add new functionality, which should be specified by Use Cases. You may also refactor existing code to improve its structure. In either case, your code development goals for each week should be based on risk analysis and should be documented in your planning/assessment notes. Details on the requirements for this code is given here. Important and non-trivial details about submitting code is given here.

3.3.2 Code Standard

Earlier in the semester you might have developed coding standards for use by your team. In this phase, you will evaluate and revise (as necessary) your standards. These standards will be used in several code reviews in Phases 3 and 4. Your code standard will be evaluated by this rubric.

3.3.3 Static Code Analysis

You will research static code analysis tools appropriate for your project and choose one or more to run on your code. You will analyze the results of the tests and prioritize problems identified. After fixing the high priority problems you will re-run the tests.

You will write a brief report discussing the tools you considered, rationalizing your choices, documenting initial results (pre-test), analyzing those results, documenting new results (post-test), and, finally, discussing your analysis of the strengths and weaknesses of the tests. Your analysis will be evaluated by this rubric.

3.3.4 Code Walk Through

One team will conduct a code walkthrough for the class team based on a gameplay video sequence. (The gameplay sequence will be developed by your interaction with Mike a week prior to your presentation). The overall process should take about an hour and will be organized as follows:

1. Introduction and review of gameplay sequence
2. High level walkthrough with UML
3. Low level code walkthrough
4. Alternate routes (time-permitting)

3.4 User tests

You will conduct user tests of your game on your classmates. There is no specific rubric for these tests. Rather you are to take notes and use your survey (which should be on Survey Monkey) to evaluate your game.

3.5 Beta Release

Your beta release deliverable will include the game executable and installation/execution instructions. Important: your executable submission should follow these guidelines. You will also give an in-class presentation and demonstration.

1. UML: Use Cases realized by the Beta; Class, Sequence and other diagrams as appropriate
2. Tests: results tests (both defect and usability) as well as known bugs/issues report
3. Installation/users guide: what do I need to know to run/play your beta release

4. Submissions

Deliverables are due as indicated on the Calendar (almost always, Sunday midnight). You should link deliverables to your wiki where specified in the template.

I am not going to rehash grading here. Check out: grading.