CSE 432S/533S: Project Definition Guidelines and Examples

Guidelines for Project Scope and Content

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 course.

Project Lifecycle Overview

• 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:

  1. an overview of the planned project and any introductory information needed to understand what it is about;

  2. 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);

  3. the specific design forces that your high level design and low level design will need to take into account; and

  4. 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.

• Evaluation 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)

• 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

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 applications.

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.