In phase I you developed your game concept and in phase II you produced an alpha release. In phase III you'll produce a beta, which is a feature-complete version of your game. During this phase you'll practice a variety of review and testing techniques that reduce software defects and improve software usability.
| Major Deliverables | Component | Points |
|---|---|---|
| Management | Management updates | 5 each week |
| Testing | Test log | 5 each week |
| Code | Code development | 10 each week |
| Code standard | 5 | |
| Static code analysis | 10 | |
| Code walk through | 10 | |
| User tests | User test 1 | 10 |
| User test 2 | 10 | |
| Beta release | Executable | 15 |
| Class presentation | 5 | |
| Documentation | 5 |
Management updates will continue through phase III as describedhere.
In this phase you'll implement the test plan designed in Phase II 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 know 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 bugswhere test protocol A and new unit test for myClass are links to descriptions of tests in your test plan and Missing map is a link to the description of the bug (called "missing map") in your know bug list.
Your test log, bug reports, and know bug list will be evaluated weekly according to this rubric.
Throughout this phase you will continue to develop code. You will also assess your code using a variety of techniques.
3.3.1 Weekly code developmentIn this phase you'll 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.
Earlier in the semester you developed coding standards for use by your team. In this phase, you'll evaluate and revise (as necessary) your standards. These standards will be used in several code reviews in phase III and IV. Your code standard will be evaluated by this rubric.
You will research static code analysis tools appropriate for your project and choose one or more to run on your code. You'll analyze the results of the tests and prioritize problems identified. After fixing the high priority problems you'll re-run the tests.
You'll 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.
You will conduct a code walkthrough for another team based on a gameplay video sequence. (The gameplay sequence will be developed during a class lab by the reviewing team.) The overall process should take about a half an hour and will be organized as follows:
You'll conduct user tests of your game on your classmates. Your results will be evaluated according to this rubric.
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 demo.
Documenting your design, tests, and code should be an ongoing process across phase III. When the beta release is complete you should provide a wiki document that provides a roadmap to the various forms of documentation including:Deliverables are due at the start of class time on Tuesday unless otherwise specified. You should link deliverables to your wiki where specified in the template. You should also specify the percentage contribution of each team member to the deliverable.
Each team is entitled to two late days that can be applied to any phase 1 deadline except those involving in-class scheduled events (e.g. Customer Elicitation) or work products that are subject to customer/user review (e.g. game treatment). If there is any question about whether a deliverable can be turned in late, be sure to ask ahead of time. A late submission that is not redeemed with late days loses ten percent of its value for each day missed.Your team will be assigned a letter grade for each work product; these grades will be normalized based on the point value of each work project in order to compute a team grade for Phase 1. In addition, individual grades will be determined for each phase based on the team grade, the contribution percentages for the deliverables, your work logs, and peer evaluations. Note that in the case of unevenly sized teams, a team of size 5 is expected to produce a project with larger scope than a team of size 4! It is your job to choose an appropriate scope to your project.