Project Booklet

For this course I explicitly do not give detailed instructions about the project booklet.

Use your creativity to build a high-quality project booklet that recommends your group. What, in particular, did your group do well?

You should explicitly NOT include anything in your project booklet that names someone and makes them look bad. In a graceful way you can include problem resolution strategies, problems that had to be addressed, and so forth, and should use anonymity as needed. All groups have problems, and if your group did too, then this, in itself, is not necessarily bad; successful problem resolution often highly recommends a group.

I will grade one version of the project booklet, agreed upon by the group, and submitted by the project manager. For in-class sections, EACH group member must be present, in class, with their own printed copy to receive credit.

For online versions of the course, I will accept a PDF version of the project booklet, submitted by the project manager. I strongly recommend that each group member print a copy of the project booklet so it is available for later in-person interviews. I have had numerous students send follow-up email, sometimes years later, that having this printed document ready to go on their bookshelf helped them to get a job tthey wanted.

You can, and might well, include individualized sections in your own project booklets. Managers—might the presentation of your work on problem resolution require some tact? If you have additional material in your own booklet that you wish me to review, you should show me that portion in your booklet, in class and then turn in an additional copy of just that material, with a clear note about what it is on a cover page.

Here is a partial list of what some groups have included, none of these are required:

• Project Overview
• Group structure, including responsibilities
• The code (if you decide to include code, it should be good-looking, maintainable, commented code. The one requirement I have is that if you include code you should use a small font for it.
• Formal requirements, and results of requirements tests
• The development of requirments through revisions.
• The work of the Bad Developer and the Bad Client
• Plan—printed version is often different from a presentation version
• Examples of formal replanning in the group.
• Design—with plan. Also sometimes alternate designs not used, and why
• Screen shots
• User manual (of course, not practical for some systems)
• Technical manual for developers
• Quality Designs for extensions to the system that the group never intended to implement
• Problem resolution, including possible (carefully, gracefully, worded!) examples.
• Time logs.
• Printed versions of the group, and application, web sites.
• Examples of using the system.
• Business plan
• HCI studies, recommendations, reworking of project because of recommendations.
• Innovative examples unique to your applicaiton.
• Due dilligence studies performed as background to chosing, or developing, the application idea
• Designs, and code, that did not make it into the final version of the project, but which represent additional good work.
• Data
• Fill in the blank: _________________