Computer Science 121 - Project 2 Organization

"Make It So"

Fall 2009

Critical Dates

Project Description

  1. Introduction
  2. Suggested Organization
  3. Overview of Graded Deliverables
  4. Grading
  5. Project Details
  6. Rules and Submission

1. Introduction

In this project you will, as a class, plan, organize, architect, design, implement, test, deliver, and support-through-preliminary-evaluation one of the educational games that was proposed in project 1. Each of you will be part of a team that will be guiding a major aspect of the planning and design. In addition, all of you will do some of the work associated with the development of the game software and content. Everyone will be required to design, review, implement and test at least one software module.

This process will involve:

Unlike project 1, where you were in small teams, and given clear definitions and delivery dates for everything you had to do, you will have a much greater role in defining and scheduling your deliverables for this project.

2. Suggested Organization

There will be dozens of gradable deliverables (which we will enumerate for you) and myriad of tasks to be accomplished (which you will have to define for yourselves). This is not a problem where it makes sense to organize yourselves around "deliverables". Rather, we will ask you to organize yourselves around areas of responsibility:

  1. project management

    This group will define and maintain the overall schedule, negotiating and integrating new tasks into that schedule as they are defined by the other teams, ensuring that these plans are adequately reviewed.

    This team will ensure that all tasks are staffed, and track (and report on) progress versus plan. When problems are discovered, this team is responsible for ensuring that they are properly diagnosed and responded to, and that all plans and resource allocations are adjusted accordingly.

    This team will review the risk assessments and management plans from the other teams, and ensure that adequate risk management is being performed.

    Planning activities will mostly happen durring the first few weeks, but it should be expected that problems will multiply as the work progresses. It wouldn't surprise me if this group was uniformly busy throughout the project.

    I would suggest a group of (about) three very organized and methodical people, at least one of whom should have good people skills for this team.

  2. game design

    This group will have a wide range of responsibilities, and will probably break into sub-teams to address some of them:

    • game rules and behavior
    • story arc development
    • specifying artwork and sounds
    • maintaining the game specification du-jour
    • communication with and feedback from the customers
    • publicizing customer feedback

    Each of these teams will produce plans and specifications that will be reviewed, revised, and will ultimately turn into work items.

    Note that this team is not responsible for writing the software that implements the rules and story, creating the artwork or building the prototypes that will be evaluated. These are tasks they will specify, and that will be assigned to individuals (from this or other teams).

    This will probably be the largest team (because of the range of responsibilities) and calls for a people with a mixture of creative and planning skills.

  3. architecture and specifications

    This team is responsible for defining the overall system architure, specifying all of the major s/w components and the interfaces between them, and defining all of the programming tasks required to implement the game.

    This team is responsible for identifying all technical risks, and planning prototyping or other solutions to manage those risks.

    This team is responsible for identifying all required technlogy, and planning its acquisition, evaluation, and integration into the project. It may also be necessary to understand complex new frameworks (e.g. what it means to be a plug-in for some existing system). This team is responsible for acquiring the required expertise and developing the specifications to be used by whoever has to develop the required new components.

    This team is responsible for maintaining constant communication with all s/w developers to ensure that problems that require interface or design changes are promptly recognized and responded to, that the specifications are properly updated, and that all associated s/w changes are enumerated and scheduled.

    Note that this team is not responsible for writing the software that they specify. They merely define tasks, which will then be assigned to individuals (from this or other teams).

    The initial architecture and specification development will be the lions' share of their work, but I am sure there will be problems to deal with until the very end. None-the-less, it is probably safe to assert that this is a largely front-loaded activity.

    I would suggest a group of 3-5 skilled and experienced developers, who are very organized and take planning and writing. This may sound like the software glory job ... but the "devil is in the details" and this job is really about managing a huge number of details.

  4. tools, integration, system test, and quality assurance

    The tools responsibility encompasses finding, obtaining, and figuring out how to use new technologies. Getting a tool working often requires very different skills (and perhaps more time) than using that tool to solve problems. It seems certain that there will be a great deal of infrastructure that we need to import and bring up in order to get this working.

    The architects worry about how each component will interact with the others, and the component developers worry about how to implement their specifications. Neither of these people is really worrying about the order in which the pieces can be mated, and how we can ascertain that the various combinations seem to be working before we send them out to customers. Developing such plans requires an architectural overview of the whole system, and as well as a practical understanding of how each component is likely to behave, and the types of problems to which the whole system is likely to be exposed.

    Everyone will participate in test plan reviews, and opine on the adequacy of proposed unit testing activities. Figuring out the difference between the sums of the unit-test plans, and the confidence we want to have about the overall product similarly requires an understanding of the overall architecture, all of the invidual pieces, and what it means to say that "the product works".

    The system test and quality assurance function involves:

    • defining the minimum requirements for a shippable prototype or product
    • participating in all unit test plan reviews, with an eye towards customer satisfaction.
    • determining what system testing, beyond the unit testing would be required to meet those requirements
    • figuring out how to automate that testing, and defining tasks to obtain or implement the required technology.
    • reporting on the status of testing activities (testing done vs planned, how we are doing on those tests, areas of concern).

    Note that this team is not responsible for implementing the specified testing tools. They will merely define these as tasks to be perfromed (by people from this or other teams).

    This team is a good place for 3-4 organized generalists who like learning about new things, and enjoy tackling new problems. It may also be a good place for people who are good at finding reasons why something won't work.

Each of you will be asked to choose one of these areas, and join the associated team. These teams will define the plans for the work that must be done in their respective areas. From these plans will emerge (perhaps) hundreds of discrete tasks. Individuals will then take responsibility for, and complete, particular tasks.

3. Graded Deliverables.

Component Description Type Due Date Points

In addition to the Team grade, individuals will be graded on their contribution to the team's efforts:

Criterion Points
Work Share 40
Work Quality 40
Contribution to Team Score 40
On-Time Performance 40

4. Grading

5. Project Details

6. Rules and Submissions

When you are done, create a message that includes:

And submit all of these things to me in an e-mail with the subject "cs 121 - Project 1".

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.