Computer Science 121 - Project Phase 3

Spring 2011

Project Phase 3 Deliverables

Deliverable	Date	Component	Points
Management Plan (40 pts)	4-5	Initial Plan	20
	4-12, 4-19	Updates	5 points each
	4-26	Final update	10 points
Testing (50 pts)	4-5, 4-12, 4-19, 4-26, 5-13	Weekly Updates	10 pts each
Beta Release (55 pts)	4-14	25
	4-14	User Documentation	10
	4-14	User Survey	10
	4-26	Survey Analysis	10
Code Review (40 pts)	TBD	Code Review Documents	10
Code Review (40 pts)	TBD	Code Review	30
V1 Release (70 pts)	Presentation Days	Final Presentation	5
	5-13 2PM (Exam Time)	Executable	25
	5-13 2PM (Exam Time)	Code and Documentation	20
	5-13 2PM (Exam Time)	User Survey	5
	5-13 2PM (Exam Time)	Final Report	10

1. Overview

In phase 2 you developed your alpha release. In phase 3 you'll develop version 1 of your game. This phase is worth XXX points.

2. Project Components

2.1 Management Plan

An initial management plan should by submitted on 4/5/10. This plan should include

Description of the major areas of responsibility for each team member.
Definition of your beta and version 1 releases using use cases, storyboards, and/or other models you deem appropriate. You should define the "must have" and "want to have" features and capabilities.
Feature freeze and code freeze dates for your beta and version 1 release.
Risk analysis.
Initial goal breakdown for phase 3 including (at least) the required deliverables and their dependencies.
Goal stack including well-modeled goals for (at least) the next week of the project.
Plan for the next week including goals to be achieved and team members' responsibilities (via tickets).
A summary of work in the first week of phase 3.

Your goal breakdown should divide the major deliverables of phase 3 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 Tuesday 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, estimating the time you expect each goal will take to complete, and issuing tickets for those goals.

You must also provide a status report that discusses the progress made in the past week. This should identify the goals that were completed, how long it actually took compared to your estimates, and if your estimates are off, abrief discussion on how you plan to improve your estimates in the future. (Note, your work logs should clearly identify who worked on what goals for how long!) You should also discuss goals that were not completed, why, and how to avoid similar problems in the future.

Your management planning will be graded on a weekly basis with 20 points assigned to the initial plan, 5 points for each of the next two updates, and 10 points for the final plan (which covers two weeks). The grading rubric for the inital plan is:

(1 pts.) Clarity of general responsibilities for team members
(5 pts.) Quality of beta and v1 release definitions
(3 pts.) Completeness of risk analysis
(3 pts.) Quality of goal breakdown (includes all major work, elaborates high-risk, high-priority goals)
(3 pts.) Quality of goal stack (good prioritiziation and clearly elaborated goals for next week)
(3 pts.) Clarity of plans for the next week (goals, responsibilities, tickets)
(2 pts.) How well you advanced the project in the first week

The grading rubric for each iterim update is:

(1 pts.) Completeness of risk analysis and prioritization of goals
(1 pts.) Clarify of goals and appropriateness of your plan for the week
(1 pts.) Use of wiki and tickets to document progress (including individual work logs)
(1 pts.) Completeness and quality of status report
(1 pts.) How well you completed the goals from the prior week

Final update values are double the interim update.

2.2 Testing

You will execute your test plan throughout phase 3. Each week you will issue a brief report describing your progress in identifying and reporting bugs. You'll also report on changes in your test plan to reflect your changing code and/or to fix problems with the plan. You will be evaluated on

(2 pts) Test as specified by the test plan

(2 pts) Bug reports issued

(2 pts) Bugs fixed

(2 pts) Test plan evolving as needed

(2 pts) We do not encounter bugs you have not reported.

2.3 Beta release

The beta release is a version of your game that will be released for testing by students at Hillside. This is the primary mechanism through which you'll gain feedback about your game from its intended users.

2.3.1 Executable Your game will be evaluated as follows:

(5 pts.) Functionality: Does it include all important features (particularly those identified at the start of phase 3)?

(5 pts.) Usability: Is it easy for the teachers to install? Is it easy for the students to learn? Do they understand the goals and how to achieve them? Is the interface intuitive?

(5 pts.) Reliability: Are there bugs? Are problems handled gracefully?

(5 pts.) Entertainment value: Is it fun? Do students want to play it?

(5 pts.) Educational merit: Is it educational? Do they learn what they are supposed to?

2.3.2 User Documentation:

You should have some means of explaining your game to users. This could take the form of a user guide, in-game tutorial, etc. Note that you have two sets of users, the teachers and the students, and you may want different forms of documentation for each group. You should describe your documentation in a brief report on your wiki. Your user documentation will be evaluated as follows:

(5 pts) Teachers were able to install and run the game
(5 pts) Students understood the goals of your game and developed good strategies for winning.

2.3.3 User Survey

You will prepare a (Survey Monkey) survey for students to complete after they have played your game in the classroom. IMPORTANT: You should have no more than 15 questions.

You will use the results of this survey to discover problems with your game so that they can be repaired in v1. We (the faculty) will use your survey results to help us evaluate your game according to the rubric in 2.3.1 and 2.3.2. So in addition to questions you want answered, you must also include questions that ask students how easy the game is to learn, whether they understood the goals, how far they got in the game , the effectiveness of the interface, whether bugs were encountered, if they found it to be fun, and what they learned by playing. Note that questions like "What did you learn?" are far less effective than asking a question students should be able to answer because of what they learned playing the game. You'll write a brief report rationalizing your question choices.

(5 pts.) Appropriateness of questions for identifying problems
(5 pts.) Quality of rationalization

2.2.4 Survey Analysis

After receiving the survey data you'll analyze the results to identify problems with your game. Your report will be evaluated on

(5 pts.) The thoroughness of your analysis
(5 pts.) The quality of your writing

2.4 Code Review

Your team will (a) submit your code/documentation for review and (b) review the code/documentations of another team. We will use the same reviewer/reviewee relationship as for previous reviews. A rubric for the evaluation is here. The code review must be completed after your version 1 code freeze and before the final exam time (5/13 2PM). A grutor or faculty member must be present. The reviewers will produce the reviewee's grade for code/documentation described in 2.5.3 below.

2.5 Version 1 Release

2.5.1 Final Presentation You will present your game during Presentation Days the first week of May. (Exact date/time TBD.) Your presentation will be evaluated on

Meaning
Structure
Simplicity and Visual appeal
Preparedness

2.5.2 V1 Executable Like the beta, your final game will be evaluated on functionality, usability, reliability, entertainment value, and educational merit.

(5 pts.) Functionality: Does it include all necessary features?
(5 pts.) Usability: Is it easy to learn? Is the interface intuitive?
(10 pts.) Reliability: Are there bugs? Are problems handled gracefully?
(5 pts.) Entertainment value: Is it fun? Do students want to play it?
(5 pts.) Educational merit: Is it educational? Do they learn what they are supposed to?

2.5.3 Code and documentation

Your code and system documentation will be evaluated in the code review. The scores given in that evaluation will be translated into points based on teh followin

(10 pts.) Final UML diagrams
(10 pts.) Quality of code

2.5.4 User Survey

As in the beta, you'll construct a survey monkey questionnaire for the users. The user test will be conducted in June by summmer researchers working on the Muddy Hills project. IMPORTANT: You should have no more than 15 questions. They will use the results of this survey to discover problems with your game and work over the summer to improve it. As in the beta, this survey should include questions specific to your game but also general questions that reveal how easy the game is to learn, whether players understand the goals, how easy/hard it is to win, problems with the interface, bugs encountered, whether it is fun fun, and what players learn. You'll write a brief report rationalizing your question choices.

(5 pts.) Appropriateness of questions for identifying problems
(5 pts.) Quality of rationalization

2.5.5 Final Report

This 8-10 page document should summarizes your project. It will be evaluated according to this rubric.

3. Grading

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