CSE 432S/533S: Project Definition Guidelines and Examples
This page is intended to help each project team define the appropriate
topic and scope of its project for the semester, and to give
illustrative examples and suggestions to help teams establish
their projects initially and refine them thoughout the semester.
Guidelines for Project Scope and Content
Projects in this course should be well focused on a single application
or problem area, but also be sufficiently nuanced to raise interesting
and challenging issues primarily for design but also for
implementation, which your work throughout the semester will address.
In general, projects for which the context within which the problem
is to be addressed is non-trivial, will easily meet this requirement.
For example, in Michael Sorensen's project described below, what made
the scope both appropriately focused and appropriately nuanced was
that (1) its focus could be summarized in one sentence ("it managed
information about patients, medical personnel, and procedures"), but
(2) the privacy, authority, procedural, and other factors involved for
medical information management made the design very challenging and
interesting to work through.
For your projects, it's good to be able to state such a sentence, so
you can answer the "what's your project about?" question easily, say
during an elevator ride between two floors. However, you should
have to spend more than the rest of the elevator ride (say at
least another 5 minutes or so) to enumerate all the ways in which that
is a non-trivial challenge to design and implement. If both of these
things are true, then your project is probably well scoped for this
Project Lifecycle Overview
Your work on your project in this course will span two development
cycles, consisting of five stages each, during the course of the
- Requirements -- in this stage, using Word,
LaTeX, or other editing tools as you prefer, you will produce a
document that describes your plan for the current development
cycle in your project and that contains the following sections:
- an overview of the planned project
and any introductory information needed to understand what it is
- a reasonably detailed description of the core technical
problem your project will address (though some details will
necessarily need to be filled in at design time);
- the specific design forces that your high level design
and low level design will need to take into account; and
- an evaluation plan stating how you will determine
whether or not your design and its implementation has succeeded.
Your team should treat this document as a "work in progress", evolving
it appropriately throughout the development cycle, and by the
evaluation stage it should constitute most of your evaluation report,
other than the evaluation results and analysis which you will add in
that last stage of the cycle.
- High level design -- in this stage you will
expand your requirements document to become a "requirements and design
document" that includes a discussion of which design patterns you will
apply to resolve the design forces identified in your requirements
document (plus any new ones you notice and add to that document during
the high level design stage itself), and class structure diagrams,
interaction diagrams, or other representations of the object-level
structure of your design resulting from the application of those patterns.
Based on the implementation design, you should also document a high
level design for the tests you will use to evaluate your implemenetation,
including interaction diagrams or any other representation suitable to
capture that design as well.
- Low level design -- in this stage you will
move from the object-level design description toward a semi-complete
implementation structure, including cross-references between classes,
class declarations in C++, interface and class declarations in Java,
and as many implementation details as are convenient to capture during
that stage. In the low-level design stage you should also produce
outlines of the test programs you will use to evaluate your
implementation, either as pseudo-code, or even as top-level functions
in your chosen implementation language, calling do-nothing functions
and methods that you will fill in during the implementation stage.
- Implementation -- in this stage you will
complete your implementation and test code, run your tests, debug your
implementation, and collect preliminary evaluation results. In this
stage you will also assess whether the results your test code produces
are able to answer the evaluation questions you have defined for your
project in that cycle, and if not, you will add or refine your test
code to provide the necessary answers. As you complete your
implementation and test code, you should also note your implementation
decisions, challenges, and solutions briefly in your project document,
paying special attention to cases where your earlier design stages
helped or hindered your implementation.
The evaluation stage may involve some additional refinement of your
test code and possibly your implementation code, but the goal should
be to finish most or all of that activity in the implementation stage,
if possible. The majority of the effort in the evaluation stage
should focus on analysis of the test results you have
obtained, and on integrating the results and analysis into your
project document and polishing the document as a (midterm or final)
project report. Your project report should capture as many of the
important lessons learned during all five stages of the cycle, and
(especially for the first evaluation stage) should provide a good
starting point for determining the requirements for the next stage
(for example, what would you change if you could, and now that
you have another cycle within which to make changes, which ones
are the most important to make).
Illustrative Project Examples (of a slightly smaller scale)
Due in part to constraints of the course setting in which they were
conducted (in the first case as one of many projects during a course
followed by an implementation in another course and a collaboration
to write up his own pattern language about the design work he did,
and in the second case as a one-person independent study project rather
than a team project), the following two examples differ in scope from
what you will do, but not in overall intent. Both projects were well
focused and involved significant pattern-oriented design challenges.
Please examine these more for the ideas they will help you generate about
your own projects than for precise definitions of what you will do (we'll
negotiate those precise definitions next week in the requirements stage).
- Modular Music Synthesis -- As a student in CS 342
(now called CSE 332) in the spring semester of 2000, Tom Judkins
produced a design document for applying GoF patterns to a framework
for modular digital music synthesizer software, which you can find here. In that document, you can see
mostly high level design content, but also the scaffolding of his
original requirements document, within which he incorporated his high
level design decisions as he made them.
We then worked on writing up the new design ideas that emerged
from Tom's design work as a pattern language in its own right. We
were fortunate to have "shepherding" guidance in improving the pattern
language from Norm Kerth, a well known member of the design patterns
community, on the road to publishing the pattern language in a paper:
Thomas V. Judkins and Christopher D. Gill, Synthesizer,
A Pattern Language for Designing Digital Modular Synthesis
Software. Proceedings of the 6th Pattern Languages of Programs
Conference, Allerton Park, Illinois, USA, 13 -- 16 August 2000.
Finally, Tom also implemented his object-oriented design (in
assembler!) in CS 306S, Processing Systems and Structures, which is
now CSE 361S, Introduction to Systems Software. If you'd like to hear
a music sample generated by his implementation, you can
find it here.
- Medical Information Systems -- As a student in
CSE 400 (independent study) in the fall semester of 2005, Mike
Sorensen produced a design document for a medical information system,
which you can find here. In
that document, you can again see mostly high level design content, but
also requirements and most interesting and important a retrospective
of several design stages that the project went through on the way to
the one presented.
Mike also implemented his design as he went along, using an "extreme
programming" style of iterative rapid prototyping and refinement that
was closely tied to the evolution of his design. In his design
document you will find numerous references to this approach, where it
worked, and how it could have worked better. These are the kinds of
self-evaluation and lessons learned observations that are very useful
to other designers who read a project report, and which you should
strive to include in your own project reports.
Ideas for Potential Projects
To help bootstrap your thinking about the kind of project you would
like to pursue this semester, or even to give you a seedling idea that
you can run with, please consider some of the following possibilities.
In each case, I've given a short description of the project's focus,
followed by a sense of the complicating factors that will make the
design effort non-trivial, challenging, and as a result ultimately
First, let's consider variations of the kinds of projects described
above, and of the file system example given by Vlissides in the
Pattern Hatching text:
- Distributed File System or Message Board --
this project would provide a consistent but simple file (or if you
prefer, message) distribution and access system among multiple users
at different networked computers. It would be similar in intent to
Vlissides file system approach, and would re-explore many of the
complexities of single-user and multi-user security, etc., but would
do so in the context of a distributed environment (so you'd have to
deal with sockets, etc. in your design and implementation).
- Business-specific Inventory Control System --
this project would manage information specific to a given (possibly
hypothetical but well defined) business, including tracking the
property (which might consist entirely of information!) that the
business receives, processes, and distributes. It would be similar in
intent to Sorensen's Medical Information System, but would apply to a
different business domain and would need to resolve the complexities
of role, authority (and possibly privacy, etc.) pertaining to that domain.
- Digital Image Processing and Synthesis
Environment -- this project would establish a framework for
generating and modifying digital images and image streams. It would
be similar in intent to Judkins design for sound synthesis but would
apply to images instead of sounds, and accordingly would need to address
the complexities of image processing common to a variety of graphics
Other examples of reasonable projects might include more technically focused
topics such as the next two ideas, which are provided here to give a
different flavor to our suggestions, and spur additional ideas you
may have for your own project definitions, which need not be limited
to the brief list of ideas given here:
- Domain Specific Language Interpreter -- this
project would capture the ability to write and interpret statements in
a small language, such as an expression language for scientific
formulas, a query language for finding information on the web, etc.
It would be a lot more abstract than the examples above, and would be
more about the domain of computer science and programming languages,
than about the particular application domain for which a particular
language might be designed. That said, examples from the application
domain on which the particular language is focused would be essential
to testing and evaluating the language design and implementation.
- Reflective or Generic Configuration Checker --
this project is similar in intent to the domain specific language
project idea, but is even more narrowly technically focused. It would
provide the ability to describe configurations of objects and then reason
about whether the configurations are correct or incorrect (and possibly
to reason more generally about whether some configurations are "better"
than others). It would focus on issues common to type systems seen
in programming languages, or on generic programming with traits and
dispatching, which we touched on last semester in CSE 332.