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
- 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.
- Use real, publicly available data: you should share
sources for data across groups via the provided wiki.
- Support multiple levels of granularity for
viewing the data and for investigating alternatives (e.g., focused cuts
vs.
across-the-board cuts).
Criteria
- I value what the game allows users to do more than how it lets
them do it: that is, function dominates user interface.
- I value a working system for lesser function over a non-working
system with greater (potential) function.
- 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
- Each group should have 4-6 people
- You may form groups primarily on your own; I reserve
the right to make adjustments as needed
- Final groups will be in place by
the end of this Thursday’s section
- 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
- Experience shows that an inability to find
consistent and common group meeting times is a huge minus.
Software
- Each group may pick it's own implementation platform and tools.
- The following software has been requested
from CSE lab
- Other software may be possible, but please check with us first.
Milestones
- Software Requirements Specification (SRS -- Word template, pdf)
- Draft due Friday January 16, 2009 @ 5PM
- Complete version due Friday January 23, 2009 @ 5PM
- [Updates may take place afterwards as needed and appropriate]
- Software Design Specification (SDS -- Word template, pdf)
- Draft due Friday January 30, 2009 @ 5PM
- Major Revision due Friday February 13, 2009 @ 5PM
- [Updates should take place afterwards as needed and appropriate]
- 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.
- 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.
- 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.
- 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.)
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- Final Release: forthcoming