CSE403 Winter 2009: Project Description

Government budgets are complicated beasts that represent not only intricate finances but also political, social and economic policies.  People are intimately affected by these budgets, but they are often unable to think clearly about the core issues because it's hard to understand both the budgets themselves and also the consequences of potential policy and budget decisions.  High-level budget analysis "games" are available here and there on the Internet to help better understand these issues; examples include:
Very roughly, these games allow people to make coarse decisions about what programs to reduce or eliminate and which revenue streams to create or increase, showing the consequence of these decisions on the budget.  You should share other budget games across groups via the provided wiki.

High-level requirements
  1. Build a budget game for a selected government entity: it must be a Federal, state, county, city, or public university with an annual budget of at least one billion dollars.
  2. Use real, publicly available data: you should share sources for data across groups via the provided wiki.
  3. Support multiple levels of granularity for viewing the data and for investigating alternatives (e.g., focused cuts vs. across-the-board cuts).
Criteria
  1. I value what the game allows users to do more than how it lets them do it: that is, function dominates user interface.
  2. I value a working system for lesser function over a non-working system with greater (potential) function.
  3. I value a system that reflects realistic warts of the selected budget over unrealistic conceptual beauty.  (Einstein said: "Everything should be made as simple as possible, but not one bit simpler."  Although you cannot make it fully realistic, take this notion to heart.)
Groups
  1. Each group should have 4-6 people
  2. You may form groups primarily on your own; I reserve the right to make adjustments as needed
  3. Final groups will be in place by the end of this Thursday’s section
  4. By 4PM on Wednesday, you must send email to the staff (Cse403-ta@cs.washington.edu) with your group status – even if you’re a singleton
  5. Experience shows that an inability to find consistent and common group meeting times is a huge minus.
Software
  1. Each group may pick it's own implementation platform and tools.
  2. The following software has been requested from CSE lab
  3. Other software may be possible, but please check with us first.
Milestones
  1. Software Requirements Specification (SRS -- Word template, pdf)
  2. Software Design Specification (SDS -- Word template, pdf)
  3. Zero Feature Release
    A description of the implementation practices in your team, based on four elements of the Joel Test  and two additional
    elements, that were not covered in earlier deliverables. The list below shows the question for you to address in your description, and suggested artifacts
    that would clearly indicate how you have addressed the issue. Equivalent artifacts are acceptable, as long as they address the question. Note, do not just provide the
    artifact; briefly answer the question with the artifact supporting your answer.  The objective is to satisfy your customer that you're in position to build the project.
    1. Do you use source control? What are you doing for source control management?
      Artifact: A pointer to your source control repository along with a command to run to look at the revision history of several of the major files, as well as the output of such an action, showing revision levels and reasons for several major files.
    2. Do you make daily [where "daily" could be another reasonable constant] builds? What are you doing to monitor the daily health of the system?
      Artifact: Description of your process for a clean daily build. Any meaningful output your process generates. This may be the report used to notify the team of the results.
    3. Do you have a bug database? How are you managing the defects in your project?
      Artifact: A set of directions describing briefly how to find your bug-tracking system, and examine the list of current bugs. We will follow these directions and examine whether the bug tracking system exists, is usable, and is being used. (Please provide accounts and passwords.)
    4. Do you have testers? Are you considering testing from the start? How will you automate your tests?
      Artifact: Description of the tools you will use to automate your tests, along with output that early runs of this testing generator produces on your product.
    5. Do you have a skeleton framework in place, showing early progress?
      Artifact: (a) Describe what development toolset is being used. (b) Provide a way to access an initial prototype, even if it is extremely limited.
    6. Do you ensure quality software? How do you ensure the software being developed is well written?
      Artifact: A description of how your team has agreed to ensure coding quality. This may be through a style guide, a peer review before checkin, an automated review by Eclipse or equivalent, etc. Please provide details, and consider how you can document the results in the beta and final release deliverable
  4. Beta Release
    A beta release of your software. A “beta” release should show basic functionality in place, integrated, and working, for the major components of the system. It should be
    possible to perform an operation that starts at the client, reaches through to the server, and back to the client.  (I call this a "there exists" vs. a "for all".) A "release" includes several elements packaged in two distributions.
    1. Binary distribution. The elements needed for someone to install your product run it . The release should include clearly identified Release Notes in the zip file that describe (1) how to install and run the software, (2) what commands are working, and (3) a list of any known issues.
    2. Source distribution. The elements needed by someone who is going to pick up the project at this stage and do further development. A separate zip file for each
      host target is often a clean way to organize this. The source distribution should include clearly identified Release Notes in the zip file that describe how to build the product from the original sources. In grading, we will be looking for the ease at which a correct build can be made. The release notes should state any assumptions, such as a Visual Studio or Ruby on Rails installation.
You must also include updated SRS and SDS documents, with change tracking on. Focus on the content changes, not the polish. If you have made any changes to your feature list delivery schedule, please add a note discussing the tradeoffs that were involved.
  1. Final Release: forthcoming