CSE 481D: Capstone Software Design - Spring 2008
|
|
CSE 481D: Capstone Software Design - Spring 2008 |
 About Us |
Search |
Contact Info |
Individual final reports are due just after our scheduled final exam period. Please submit them by email to zahorjan@cs.washington.edu, putting "CSE481d final report" as the subject field. (The report can be submitted any time after the final demos but before the due time.) PDF files are preferred, but anything I can reasonably read, on a Linux system, is okay.
The report is both a retrospective (what happened, and how well did it work?) and a prospective (how would you do it differently next time, and why do you think that would work better?). It assumes your discussion can be neatly divided into issues of game design, technical (code-related) decisions, and process (team coordination and other aspects of getting the product built), but I understand that it might not be possible to attribute the points you want to make neatly to just one of those.The length of your report should be appropriate for its content. I honestly have no strong pre-conceived notions about length, and it isn't a grading criterion. In case it helps, I imagine that in most cases something as short as a couple of pages or longer than ten or so probably indicates a superficial treatment of the questions, although it could indicate miraculous insight.
Please use the following outline for your report.
1. Goal Retrospective
Briefly describe the goal your team set at the beginning of the course. Be comprehensive; in particular, include a description of who you intended would be able to use your system, what they would need to do to use it, and what "system requirements" you imposed. Now briefly compare that original set of goals with what was actually built.2. Goal Prospective
Suppose you were advising a new CSE481D team charged with building your game. What changes to the game's design would you advocate that new team make (relative to your original goals)?2. Technical Decision Retrospective
Describe the major technical decisions made by your team. What (technical) surprises were there? Which decisions worked out as expected and which didn't?3. Technical Decision Prospective
If you were involved in building a similar product again, what technical decisions would you advocate, given your experience with this project? Explain what you're worried about that might still go wrong, even with those changes.4. Process Decisions Retrospective
Describe the major decisions your team made about how to operate. Which ones worked and which didn't, and why?5. Process Decisions Prospective
If you were involved in a project like this again, what process decisions would you advocate? What would you still be worried about?6. Summary
Considering your team's efforts as a whole, what do you think the most important obstacle(s) was to having gotten further? Is there something you can do in future projects to reduce the risks posed by that obstacle(s)? (Be realistic. For example, "better documentation" sounds like an inarguably good idea, but we all know there are serious problems trying to get developers to do that. If you were to suggest it, you would want to argue both why its benefits outweigh its costs and how it is that you'd get your developers to operate in a way history indicates pretty much no one likes or thinks is worth their own time.) For concreteness, imagine that you are writing advice to the teams in the next offering of CSE481D.7. Your Individual Contribution
Briefly describe your responsibilities and contributions to the project, on the game design, technical, and process sides.