CSE 143 Project Reports
Written Report Guidelines
Each student should complete a written report about each project individually.
The report helps you communicate technical ideas, while demonstrating
your knowledge about the design, dedevelopment, and testing of the project
software. Your report should contain the information outlined below. Please
use these guidelines to prepare it.
The report is an important component of the overall project, so you should
take the time to do a careful and thorough job. You should be complete,
but please keep your writing focused and succinct. A report of only a
couple of pages is fine if it covers all the points, and at most 5 to
8 pages of text should normally be needed. Much more than that, using
normal sized text (excluding any diagrams or figures) is usually inappropriate
- edit your report to emphasize the key points.
Technical writeups are often part of software development in the "real
world". Ideally, after reading a design report, the reader should
know:
- What the program does
- How to use it - either how to run a complete program or how to use
a piece of software as a component in another program
- How the program is designed and structured, and the major decisions
that led to that design
- Places that had bugs (or still do) or required major redesign during
the implementation (code that had or has problems is a likely source
of future concerns)
- How the code was tested and how you convinced yourself that it works
as expected
You should structure your report as follows. The report should be formatted
so it is easy to find the different information.
Introduction
State the purpose of the project and give a brief overview of the program
for someone who might be unfamiliar with it.
System Use
Describe how to use your system. Assume that the person using the system
has no familiarity with your code, but does know how to use an environment
like DrJava or Java command-line tools. Describe how to run the program
or how to create objects and interact with them (whichever is appropriate).
This part of the report should be a "user manual" that describes
the external interface of your program, without describing internal
implementation details.
System Implementation
Describe the structure of your system. What are the key components
and how are they related (diagrams can be useful here). What classes
did you design and implement? What are the important properties and
responsibilities of these classes? Try to describe the motivation behind
your class design and examples of key algorithms and methods. You may
find it helpful to include code examples or to explain key algorithms
using English or Pseudo-code, however don't just paste in tons of code.
Describe any code that you obtained from other sources (starter code,
etc.) that you used as part of your project, and describe any significant
modifications that you made.
Remember that the goal of this part of the report is to explain the
key ideas and decisions in your implementation, not to give a method-by-method
explanation of all the details.
Process
Describe how your team designed and implemented the project. What were
the interesting or challenging parts of the work? Did you need to make
any significant changes to your original design or implementation because
of lessons learned while doing it? If you added extra features to your
project beyond the basic requirements, describe what you learned from
the experience, how you learned about any concepts or algorithms involved,
and your experiences getting them to work.
Describe your experiences with pair programming. Did the pairing work
well? Where and when did you do the work? How did each of you use your
unique skills and abilities to contribute to the project? Assess the
relative contributions to the project from each member of the team.
Testing and Evaluation
Describe how you tested and evaluated your application. If your application
does not meet the project requirements or has other problems, please
note these differences. Include representative test cases and output,
if appropriate. Evaluate the quality of your code - is it readable?
Is the class design reasonable (coupling and cohesion)? What, if anything,
would you do differently if you did the project over again?
Conclusion
What were the most important parts of this project and what did you
learn from it? This could include, among other things, technical issues,
development processes, or your experience working with a partner.
Remember, you will be graded on the clarity and writing style
of your report, as well as the content. Please be complete in your descriptions,
but remember that complete does not mean verbose.
| 
UW Home 
