CSE 432S/533S: Project Evaluation II and Final Project Report

This page is intended to help each project team define both its evaluation approach for the second project cycle, and the format of its Final Project Report. The final project report will serve as a comprehensive record of both the first and second project cycles.

Guidelines for Evaluation of your Second Project Cycle

Each team should evaluate their project in a way that both (1) is similar to the "happy path" demo for the second implementation stage in that it exercises the major subsystems of the project implementation, and (2) goes well beyond the "happy path" to explore (and potentially reveal design and implementation problems with) other scenarios. One of the key ways to think about your evaluation is to ask "what are the major ways our system could behave (both good an bad), and what scenarios could we define to try to drive the system into those behaviors".

For the good behaviors, your scenarios would be similar to the "happy path" scenario in demonstrating what the system can do, but would aim to demonstrate a broader range of the system's potential operation. For the potential bad behaviors, your scenarios would be designed more to test (and if the potential bad behavior actually appeared would allow you to fix) how the system responds to things like bad user inputs, different orders of actions from the user, etc.

In general, the goal in this stage is to demonstrate a system that is broader and/or more complete and/or more efficient in its functionality, and is demonstrably robust in avoiding or gracefully handling problems. Although time constraints may still mean that you won't be able to find and fix all remaining bugs in your system, it is important to try to do that to the extent possible, and document open problems as well as solved problems and their solutions.

Deliverable: Final Project Report

Using Word, LaTeX, or other editing tools as you prefer, you will produce a document that summarizes both cycles of your team's project, including your evaluation for the current development stage. The intent of the final project report is to describe your accomplishments and the thought process and project evolution behind them, throughout the entire course. In developing this report you may freely re-use materials from your team's previous deliverables, including your midterm project report, but you then should please make a thorough pass through each section of the final project report to make sure that the discussion and details in each one reflects your understanding of the project as of the end of the second evaluation stage. Your final project report should contain the following sections:

  1. a cover page with the title of the project, the nature of the document (Final Project Report), the names of the team members who contributed materially to the document, and the date the document was submitted.

  2. a project overview section that describes what your project has achieved throughout the semester (please summarize both the first and second project cycles). This should be an English narrative that summarizes what the system you described does, the scenarios that you have used to demonstrate and test its behavior, and high level observations and lessons learned during the first and second cycles of your project.

  3. a requirements and design forces section that gives a reasonably detailed description of the project requirements that have survived to the end of the second evaluation stage (including requirements that were originally given in the first project cycle, which are still valid). You should comment on when (i.e., in what cycle and stage) each of these requirements was identified your project. If any requirements were added after the initial requirements stage for either cycle I or cycle II, you should please comment on how you discovered the requirement, and your motivation for adding it. Finally, if any requirements that had been listed in your requirements stages for either cycle I or cycle II were dropped from your project, please give some justification why dropping the requirement was an appropriate decision.

    For each of the requirements that has survived to the end of the evaluation stage of the second project cycle, please describe the design forces that each requirements imposes on the design.

  4. a design evolution section that gives a narrative explanation of how you mapped the design forces from your requirements into your high level and low level design decisions, throughout both project cycles. Please comment especially on which design patterns you applied in order to resolve particular design forces from your requirements or from previously applied patterns.

  5. a technical design section consisting of (1) class structure diagrams, interaction diagrams, and/or collaboration diagrams that show the structural and behavioral relationships in your design as of the end of the second cycle's evaluation stage; (2) an English description of what those diagrams show, including which roles are played by the different classes in the design patterns you applied (as described in your previous section).

  6. a project code file listing section that contains the code files containing the declarations and definitions of the classes, functions, member functions, and member variables in your project as of the end of the second cycle's evaluation stage. The comments in the listing should reflect your design, implementation, and evaluation decisions in detail.

  7. an evaluation scenarios section that describes each of the scenarios you used to evaluate your project (including the "happy path" scenario you defined for the implementation stage of your project) in both the first and second project cycles. For each scenario, please explain what it is designed to test, the steps taken in the scenario, and the results you got when running the scenario. If any of the scenarios from the first project cycle are not applicable to your implementation as of the end of the second project cycle, please comment on which of them are no longer valid, and for each one why that is the case. Otherwise please list all other evaluation scenarios from the first project cycle as well as those added for the second project cycle, and please make sure you have tested all of those scenarios: again, if any problems were encountered while evaluating your project using any of these scenarios, please describe them as well, along with saying what you did (or would do if they're still open problems) to fix them.

  8. an instructions for building and running section, that gives step by step instructions for logging in (if needed), building and running each of the scenarios on a particular platform. If there are any libraries, etc. that need to be downloaded in order to build or run your prototype, you should also say what they are and give step by step instructions for downloading them and using them in your project. One option is to set up a demo environment in your team account on the CEC machines, and give us directions (and access) for running your evaluation there.

Participation: every member of your team should be significantly involved in the evaluation of your project and the writing of the final project report, though how you structure the interactions within the team is up to you.

Deadline: by 11:59pm on Wednesday, July 8, 2009, please e-mail your team's final project report to Prof. Gill at cdgill@cse.wustl.edu.