CIS 700 Programming & Problem Solving - Summer 2013

Project Reports

Your project reports are worth 60% of your final course grade, so it's important that you take time to make them clear, precise, and thorough. The reports should be structured in pretty much the same way you'd organize a research paper:

In general, the more you write, the better. Remember, this course focuses not only on creating and implementing solutions, but also on analyzing and communicating them.

It is very likely that we will share your reports with your classmates and with students in subsequent offerings of this course, so please try to be professional!

1. Introduction
Your report should start with a brief introduction in which you describe the problem you are trying to solve. Just a paragraph or two will be fine. You can assume that the reader is familiar with the topic.

Also include a sentence or two about each of the approaches you tried to solving this problem. Just a bit of foreshadowing for the rest of the document.


2. Initial Insights and Observations
When you first started working on this project, what were you trying to do? What were the first things you thought about how to go about solving this?

Once you started implementing it, what were the problems that you noticed with your initial approach? What, if anything, needed to be changed?

It's important that your report demonstrates that you made progress over the course of this project. So use this section to describe your initial ideas, and then use the next two sections to show that your solution got better over time.


3. Approach
Now describe the intuition behind your solution. Do not explain the implementation details (you'll do that in the next section) of how you wrote your code, but start with a high-level overview of what you were trying to accomplish. Imagine you are explaining your solution to your parents (assuming your parents aren't Computer Scientists!): just give a general idea of what you were trying to do, and why you thought it would make sense to do that. This section should be specific enough so that another programmer could understand and then go implement your idea, but not so specific that it gets into how you implemented it.

You may, of course, have multiple solutions to different variations of the problem. Describe each of those separately, especially if there was a particular aspect of the problem you were trying to solve (e.g., a specific corner-case or a specific configuration).

This would be a good place to include screen-shots showing your solution at work, especially if there is some step-by-step process that is difficult to explain in words. And it's always good to use specific examples. The more specific, the better.

Also, if you have introduced any terms/concepts over the course of this project, please define them here. Don't assume that the reader will know what you mean.


4. Implementation
Next, explain how you actually implemented the solutions described in the previous section. Make it clear what parts you solved in your heads (and thus hard-coded into the solution) and what parts you allowed the software to figure out for itself.

The most important information in this section regards the different algorithms that you used. It must be very clear how they work and how you implemented them. You can include pseudo-code if you'd like, or the actual Java code from your implementation (we won't look at your code unless it's in this document, but please don't just dump all of it into this report).

Additionally, if you needed to use any data structures or create your own classes, describe those, too.

If your implementation included any hard-coded constants or parameters, explain the effects that those had on your solution.

It can often be hard to differentiate what should be in the "Approach" section and what should be in the "Implementation" section. Keep in mind that there can be different implementations of the same approach.


5. Results
Discuss the results of your submissions to the end-of-project tournament. There are two things to focus on here: are your results "good"? are your results "better" than other groups'? Those are not necessarily related!

In describing whether your results are "good", refer back to the Approach section and relate your initial thoughts and intutitions to the actual experimental outcome. That is, did you set out what you hoped to accomplish? If so, how do you know? If not, what went wrong?

In describing whether your results are "better" than other groups', feel free to put a positive spin on things. For instance, was there a particular configuration or aspect of the problem that you were significantly better at? Be careful about meaningless self-congratulating platitudes, though: "we were consistently in the top five" doesn't really sound good if there are only five groups!

If you performed additional experiments outside what we agreed upon for the tournament, and those experiments reflect positively on your implementation, include those results, too.

Note that unless your performance is particularly awful or particularly fantastic, the results of the tournament will not affect your grade. What's important is that you understand why your solution performs the way it does, and that you're able to analyze and communicate that.


6. Contributions
In this section, describe the contributions that your group made to the class as a whole. Were there any specific insights that you had that helped other groups? Did you identify any algorithms or solutions that no one else thought of? What was different/unique (in a good way) about what you did for this project?


7. Future Directions and Limitations
If there are any known problems with your solution (either in the approach, algorithm, or implementation), please describe them here. You will not be penalized for these unless they are particularly egregious, e.g. things that could easily be fixed. Rather, this is a way of warning future students who work on this project about potential pitfalls.

In this section, you may also indicate any possible solutions that you thought of but did not have time to implement, or any other ideas you had but did not pursue.


8. Acknowledgments
Give credit to people whose ideas you used in solving this problem. This may include other students in the class, members of the instruction staff, or people outside the class with whom you spoke about this project. It is important that you recognize other people's contributions and do not take credit for ideas that are not your own.

If you are unsure of who originated an idea that you used, please consult the class discussion notes in the project blog, or ask the TA for help.

Also, if you used any third-party resource -- e.g. a textbook, website, etc. -- for anything other than Java implementation-related issues, please cite those here.


9. Conclusion
Your conclusion is an opportunity for you to give us feedback on the project itself. Please answer the following:

Updated: May 30 2013, 4:14pm