Computer Science 121 - Project 1

• 40% the thoroughness of your research (did you find the related products),
• 20% the credibility of your assessments of their strengths and weaknesses,
• 20% the degree to which you identify and focus on key design elements,
• 10% the degree to which you can formulate your goals in measurable ways,
• 10% the cogency of your arguments for how/why your product will be better.

1. High Concept Statement: Working game title, team members, and a 100-200 word description of the game
2. Features: Bulleted list of important features (prioritized)
3. Competitive analysis: Similar games with comparison to proposed game and how they compare to your game
4. Overview: Player motivation, genre, target customer, hardware platform options, suitability for learning objective, major risks, unique selling points, design goals, concept art
5. Other: Info you think is important

• 25% the clarity with which your game is described (I know what it is and what it will do for me).
• 15% the extent to which I get some sense of what it will be like to play the game.
• 25% I can see how it will achieve my educational goals (which means it must do so).
• 25% I can see why it will be fun
• 10% how good an impression it makes (polished and professional).

Note your presentation must be uploaded to the wiki on the date shown in the table above. The presentation with be given at the start of meeting with the customer requirements elicitation session.

• 20% its length: 3-6 minutes
• 40% its effectiveness in establishing context (the clients understand what learning objectives are to be addressed, in what general approach).
• 20% the extent to which it does not otherwise contaminate or prejudice the clients.
• 10% how effectively it stimulates interest in the product, making them eager to provide input.
• 10% how good an impression it makes (polished and professional).

1. Briefly (in less than 60 seconds) introduce yourselves and the agenda
2. Give your concept presentation
3. Start with open-ended information gathering about the educational goals in question, how they pursue them, what problems they encounter, the gaming activities of students, their computer use, etc.
4. Then move into more specific questions, following up on interesting points raised in the open-ended questions, and posing the more directly product-focused questions that you have come up with.
5. Get their comments on information you have gained from other sources. Note: It is possible that, in the process of giving you their own requirements, the customers will actually touch on all of your own previously gathered requirents. If this is the case, when you get to that part of the agenda, specifically affirm that they have reiterated (or how they have changed) that prior input.
6. Present a summary of the key messages you have gotten from them today, and give them the opportunity to correct/amend those.
7. Thank them for their participation

• Moderator: Leads the meeting, discussions, etc.
• Scribe: Takes notes
• Others:
  The moderator and scribe will typically be too busy to actually think about and process what is being said in real time. Other team members should
  • Distill long discussions into punch-lines for the summary.
  • Keep track of points that need further clarification before we are done.
  • Check off comments that relate to previously suggested requirements, and maintain a list of requirements that still require validation.
  • Watch the agenda and the clock, and help the moderator keep to the agenda and make sure that nothing is missed (because it is very difficult to think while talking).

• 35% the extent to which you are able to adhere to the process (which will be described, in the reading, given to you in writing, and demonstrated in class).
• 50% the extent to which you are able to obtain useful information from the clients about their needs and perceptions in this area.
• 15% the extent to which you are able to validate and clarify prior assumptions and questions about requirements.

1. When and where the session took place and who attended.
2. Interesting information gained during the open-ended information gathering.
3. Clear statements of significant new requirements that were suggested, along with an assessment of how important each is and why.
4. Significant input on previously gathered requirements, affirming, refuting, or changing them.
5. Any other useful results gained from the meeting.

• 15% form (capturing who, when where, topic)
• 30% completeness (all key points captured)
• 20% understanding what the customer said (correctly, and deeply)
• 20% the analysis of this information and distillation of requirements
• 15% the clarity, organization and readability

• develop a list of basic questions that you need to know the answers to in order to validate your approach.
• develop a questionaire (for teachers and/or students) to gather basic information.
• develop a list of key assumptions that should be tested in order to gauge the likely acceptance and success of the proposed educational game.
• develop samples and/or prototypes of proposed key game elements, that intended users can watch or interact with.
• develop a process (to be carried out by the teachers in Kalamazoo) for exposing the students to your prototype and gathering their feedback.
• deliver the prototype and evaluation process to the teachers, get back the student responses, analyze them, and prepare a report on the results.

You will take the questions that can be well answered in a survey, and prepare a survey-monkey survey, which we will have taken by (your choice) teachers and/or students.

The survey will be graded on the basis of:

• 40% on having identified and posed key questions to be investigated.
• 40% on the drafting of appropriately targetted survey questions to probe those issues.
• 20% on the simplicity and professionalism of the survey.

1. the plan for what needs to be investigated, and how
2. the samples or prototype to which intended users can be exposed.
3. a process for exposing users to the prototype and gathering feedback.

In developing the User Feedback Plan you will identify a small list of key design assumptions and concepts that need to be tested, and then come up with a practical means of getting feedback from students to validate the assumptions or answer the implied questions. These questions might range from experiences with particular user interfaces, to how well they are likely to learn lessons taught in games to how they a like the artwork, interaction and premise.

This plan will be graded on the basis of:

• 25% how effectively you identified and posed key questions or assumptions to be investigated.
• 25% how viable an approach you came up with for answering/testing those key questions.
• 10% how well the approach is likely to gage how well they will enjoy the game.
• 30% how effective the approach is likely to be in getting meaningful answers to those key questions.
• 10% clarity, organization, readability.

The User Feedback Prototype is a collection of things to which intended users (students) can be exposed to gauge their response. It may take the form of video clips, artwork samples, story-lines, interaction simulators or anything else that your users can respond-to in order to give you a sense of how they would respond to the game you propose to build.

The prototype itself will be graded on the basis of:

• 50% how effectively it elicits feedback on the intended questions.
• 20% how effectively it gives the intended users a sense of what the game will be like.
• 20% was appropriate technology used to create the needed simulations.
• 10% does it create a good impression.

The User Feedback Gathering Process will be delivered to the teacher as a package, and carried out by the teacher, with a small number of students (e.g. 3-4) and should be performable (start to finish) in 20 minutes.

• instructions for the teacher on how to administer the test.
• a description of how the evaluation or play-test will be run.
• an introduction to be read to the students by the teacher.
• the prototype/samples to be evaluated.
• a questionnaire or process for gathering feedback.
• a means for returning that feedback to you.

The feedback gathering process will be graded on the basis of:

• 20% ease of administration (usability of the package by the teacher)
• 20% clarity of the student instructions (they knew what was expected of them)
• 20% organization of the activities and use of time
• 20% effectiveness and practicality of feedback gathering process
• 20% did you get meaningful feedback on the key questions

This report will be graded on the basis of:

• 10% form (capturing who, when where, topic)
• 30% completeness (all key results captured)
• 30% understanding what lessons learned were (correctly, and deeply)
• 10% the analysis of this information and distillation into requirements
• 10% completeness and insightfulness of the assessment of the plan, prototype, and process.
• 10% clarity, organization and readability

• what would the major pieces of the implementation be?
• what special technology would be required to build each?
• what skills would be required to build each?
• roughly how much work would be involved in building each?
• what problems could reasonably be anticipated in such an implementation?
• how might each of those problems be addressed?

• it must be buildable (start to finish), by about 15 students in about seven weeks.
• its construction must be achievable with available tools.
• it can require no expertise that cannot be found or developed in the students of this course.
• major risks must be identified and addressed.

Providing these assurances will involve some preliminary design, some research into available tools (e.g. game engines, digital art tools, programming languages), and some serious pondering of the likely risks. You will do the design, research, and analysis, and write up the results in a "Technological Assessment report". This report will be graded on the basis of:

• 10% plausibility of the basic design
• 20% completeness of the technological needs assessment (figuring out what pieces you need and what is involved in each)
• 20% thoroughness of the technological research (identifying resources).
• 10% completeness of the skill set requirements.
• 10% plausibility of the preliminary work estimates, and the soundness of the basis for those estimates.
• 10% thoroughness in identifying key risks, and the methodology that was used to develop the list of key risks.
• 20% soundness of suggested approaches, and the rationale for their selection.

1. this will address the pedagogical requirements
2. this will be fun to play
3. this is easily buildable with the available time and resources
4. all of the likely problems are understood and tractable.

But your case will not be made by "emphatic assertion", but by the data you are able to gather from your competitive research, requirements development, user feedback, technological research, and preliminary project plans and risk analysis. A winning proposal is a compelling concept, backed up by good research, thorough analysis and a sound plan.

The Final Proposal should include the following sections:

1. High concept statement (perhaps only 100-200 words)
2. Key Features (what it will be like and how it will address the pedagogical requirements).
3. Key requirements (necessary conditions for success).
4. Competitive analysis
5. Overview of game
6. Rational for the game design (in terms of pedagogical goals and audience)
7. Proposed project overview (architecture, tools and approaches), and rationale for these choices.
8. Risk and Feasibility analysis (including proposed scheduling and staffing, key risks and plans for their mitigation).

• 10% the clarity and persuasiveness of the "high concept statement".
• 10% the clarity and persuasiveness of the value proposition implied by the key features.
• 10% the clarity, prioritization, and provenance of the key requirements.
• 10% the clarity, depth, authoritativeness, and cogency of the competitive analysis.
• 15% the clarity of the game description and design (we understand what it will do), and the persuasiveness of the rationale for these decisions.
• 10% the reasonableness of the basic design and technology decisions, and the clarity and persuasiveness of the rationale for these decisions.
• 10% the reasonablness of the suggested project size and resource requirements, and the soundness/plausibility of the basis for those estimates.
• 10% the thoroughness of the risk analysis and the adequacy/soundness of the proposed solutions.
• 10% the overall clarity and persuasiveness of the proposal.
• 5% polish (it makes a good impression).

And one of these proposals will be selected for implementation (by the entire class) in Project 2.

Each team will prepare a task-breakdown, identify the dependency relationships between tasks, and owners for each sub-task, assign due-dates, and schedule regular reviews of both work-products and progress (to enable adequate time to deal with the problems that will happen). As your understanding of the problem evolves and you respond to unanticipated events, you will have to revise your plan. If deadlines are missed, or deliverables fail to pass review, the fact, as well as the causes and the plan to remedy them must be documented.

The living document that lays out the plan (du-jour), its progress, and its evolution over the course of the project is the Management Plan. It will be maintained in (one or more) wiki documents, and will be graded on the basis of:

• 40% good use of time and resources (work apportioned reasonably over the available time)
• 20% specificity of plan (clear responsibilities: who, what, when)
• 20% provisions for early detection of problems, and time to deal with them
• 20% degree to which it is maintained over the course of the project

Experience has shown that vague plans are easier to create up-front, but create problems down-stream (when people turn out to have been unclear about exactly what they were supposed to do, by when, and in what form they were to deliver their output). Similarly if you do not specifically map out the dependency relationships among the tasks, you may find that your schedule is unrealistic, because it does not allow sufficient time for sequential tasks.

Management is responsible for monitoring progress, recognizing these problems promptly, and adjusting the plans to respond to them. Each team will receive a management effectiveness grade based on:

• 30% how well (we can ascertain that) progress was tracked
• 10% how quickly (we can ascertain that) issues were identified
• 20% how effectively (we can ascertain that) they were responded to
• 20% the fraction of external deliverables that were on-time
• 20% the fraction of internal deliverables that were on-time

We will determine when work was done based on the dates of the final subversion check-ins.

• the concept definition, research, and brainstorming activities
• the customer requirements elicitation planning, execution, and results analysis
• the user feedback planning, execution, and results analysis
• the organization and creation of the final proposal
• the overall project as an educational exercise.

You will be graded on the basis of:

• 50% whether or not you meaningfully discuss each of the required activities.
• 25% whether or not you identify all of the important incidents.
• 25% the extent to which you are able to derive useful lessons (and good future advice) from those experiences.

Note that if you make no mistakes, you will not be able to earn any points on the post-mortem. Fortunately, no teams have ever found it necessary to deliberately make mistakes in order to have something to analyze. Organization of the submitted package

A few points will be held aside for the overall organization and clarity of your submissions. If we have no difficulty finding the things we need to grade, and finding where you met the requirements you will receive full points. If we have to struggle to find needed information, or to figure out whether or not you have met the requirements, you will not be awarded these points.

5. Rules and Submissions

When you are done, create a message that includes:

• the name of your team
• the names of your team members
• if you are using any slip days, how many from whom
• the URL for your subversion repository
• your index of work products

The index of work products is a list of file names (within your team web site) that contain the work products to be graded. We could browse around and guess which ones you meant to submit, but you would probably prefer to point us directly at the ones that are meant to be graded. It would also be useful if you gave us pointers to the working documents that contributed to the ultimate deliverables, so that we can track their evolution and history.

Each student is entitled to three slip days. A late submission that is not redeemed with slip days loses ten percent of its value for each day late it is. Note that a slip-day is only good for one deliverable. If a design is one day late, and that delays the design review by a day, then you may find that you need two slip-days. Don't make the mistake of using up your slip-days too soon, because the pressures generally get tighter later in the course.

When a team needs to use slip-days, they need to decide who's days they are using. However you decide is OK with me, but we will be tracking the slip days per student. If will be using any slip days on this deliverable, tell me in advance that you will be doing so (so that I don't nag you about whether or not I lost your submission message).

Collaboration and Citation

This is a team project, but different individuals will have primary responsibility for different processes or work products (or different parts of a single work product or process). Each team will be working on a different type of product. You are free to talk your team members (and for that matter other teams) about the processes you are following. You may review your work products with your own team members, and revise them based on their feedback ... but ...

1. If you are the primary author of a work-product, you must cite the source of text you did not write (if it is more than a sentence), or any information that did not originate within your team or from your interviews.

   You will be doing research to develop your product definition and requirements. I expect that many of the ideas for your product will come from this research. Cite all of your sources for each work product, and explain how each source contributed to your work products.

2. You may not share any of your work products (other than as required for reviews) with members of other teams.