Assignments

The primary assignment in CS486 centers around the selection of a project sponsored by an "real-world" client, followed by an intensive software development effort. There are a number of deliverables that will be expected from teams over the course of this process, most of which represent actual documents that you would have to produce in an actual, real-world software development scenario.

The best way to bring together this vision of process, and how the various deliverables fit together within it, is by providing an overall timeline for the Capstone Project Development process. To help us get a grip on a long and complex process, I've split things into several documents:

• Introduction and Preamble: Deliverables and guidelines that span ALL phases of the process.
• Description of Major Phases: Gives a conceptual overview of the three major phases and what we're doing in each.
• Detailed Timeline: Cuts to the chase, with a detailed listing of deliverables and due dates.

IMPORTANT NOTES ON GUIDELINES: I have very mixed feelings about guidelines. On the one hand, a major idea behind the Capstone sequence is that you have mastered all of the project preparation skills needed in the previous courses; in the capstone course, you are merely applying them in a real-world context. Thus, theoretically, you should be able to crank out quality deliverables without guidelines --- just as you will be asked to do in the real world. In an ideal world then, I would just say "give me a functional spec" and you would go off and produce the right thing.

From a more practical perspective, however, I have found that students need some help/reminders/guidance on how to prepare the major project deliverables. Even more practically, a little structure helps to make grading --- which is necessarily already somewhat subjective in this course --- a little more uniform. Thus, I have chosen to provide you with some guidelines.

You should NOT, however, take these as an exact specification, e.g., "if I have exactly these sections in my document, I'll get an A". Each project is different; ultimately what is "needed" in a deliverable is determined by the unique features of a particular project. Some sections/discussion may not be relevant for some project; another project may require additional discussion/description that doesn't appear within the guideline. It simply depends on the project.

In the end, the quality of a deliverable is judged qualitatively, more like an essay in an English course, and not based on some step-by-step formula, like in a math course. We, as engineers, are more comfortable and accustomed to the latter. But you MUST recognize that the real world doesn't work this way -- how well a proposal or other client deliverable is received depends entirely on how well-written it is, on how well and coherently it does it's descriptive task.

So: use the guidelines I provide as they are intended, namely, as a rough framework to prime your own creative processes. Do NOT use it as some sort of precise color-by-numbers template where you blindly fill out each section. Each of your client deliverables should read smoothly, with coherent flow of ideas and compelling arguments --- arranging for this to happen will often require re-ordering or re-casting the sample sections/topics I lay out in a guideline.