CSCI 6838 Capstone Projects
Guidelines For Final Reports

by K. Yue, last modified: December 2006

This document describe the general requirements and format of the final report.

I. General

Each team must submit a final report for its project at the end of the semester. The final report is a technical report that completely describes all aspects of the project. You should assume that the readers to be general computing professionals who are interested in computing technologies but do not necessarily know much about the project.

Note the difference between powerpoint slides and a technical report. Presentation slides need not be complete as the presenter can elaborate further and the audiences may ask questions. On the other hand, a final report needs to tell the entire story by itself. Thus, pure bullet forms requiring further explanation do not work well with technical reports.

The report should be typed using word-processors. Figures and tables must be numbered, labeled and clearly presented. Information that is not directly applicable to the discussion in the report should be placed in the appendices. Other items that can be placed in the appendices include UML diagrams, detailed computations, generated output, source code, etc.

Although it is obvious, make sure to check your grammar and spelling. A poorly written document implies that the software is also poorly written. Proofread all documents (and use the spelling checker) prior to submitting the final report. Like any technical writings, it is common for your final report to undergo several major and minor revisions.

II. Final Report Layout

• Turn in one copy of your final report.. You may want to turn in one copy to the mentor too, if applicable.
• All final copies should have a vello binding.
• Use 1-inch margins on all sides.
• Use "times roman" font
  • Body of text: size 12
  • Section headings: size 12
  • Main headings: size 14
• Use full margins, not left-justified margins.
• Use double spacing. This makes it easy for the instructor to write comments.
• Sections and subsections should be numbered, for example, 1, 1.1, 2.3.1, etc.
• Make sure to label every figure and table. Use the following labeling convention: Labels should be placed below the tables and figures..
• References are placed in alphabetical order by the first author's last name. When citing a reference in a document, enclose the corresponding number for the reference in square brackets. Include only references that are cited in the body. Limit your references to 15.

III. Final Report Contents

The narratives of your final report (sections 4 to 7 below) must not be more than 14 pages (Sections 4 to 7 below). Source code, screen shots and other less important details can be included in the appendices.

Your final report should have the following contents:

1. Cover Page

• Project title
• Name of the instructor
• Name of the mentor
• Names of the team members (in alphabetical order)
• Semester and year at the bottom (e.g., Spring 2007)
• Report date

2. Abstract

This is a concise executive summary of the project, describing the problem, the design, implementation and evaluation of the solution prototype and recommendations for future enhancement.

3. Table of contents

• List sections, subsections and appendices along with page numbers.
• Listing of table and figures.
• Make sure page numbers are right justified.
• The page number use Roman number in lower case.

4. Introduction and Background

This section introduces the problem, its significance, context and specifications, existing current work and related problems. It also gives an overview of the solution described by the report. This section starts at page 1 of the narrative.

5. Technical Body

These sections are the technical contents of the final report. You may use several sections to cover the technical body and arrange the order in your preferred manner. The actual contents are project dependent but your team should consider the followings:

Design and Implementation of Solutions

Topics to be covered may include:

• The architecture of the selected solution.
• Key design decisions and their rationale, which may include:
• Key UML diagrams.
• Key relation schema.
• Key data structures and classes used in the implementation.
• Main functions of the solution.
• Selected technologies and rationales behind the selection.
• Software development model used.
• Implementation issues: difficulties encountered and techniques to overcome them.
• Comparisons with other alternative solutions.

You may use screen to capture the functionality and look and feel of your prototype. If there are many screen shots, you may include them in the appendices.

Evaluation of Solution

This section provides evaluation of the solution prototype in the following respects:

• How well the solution solve the original problem?
• How well is the design of the solution?
• What is the functionality of the solution prototype?
• How does the solution prototype perform? Does it satisfy the requirements?
• How reliable is the solution prototype? For an example, is it transaction safe?

You may also describe the lessons learnt from the project and provides future directions, such as:

• future changes in the design of the solution, and
• future enhancement of the solution prototype.

6. Conclusions

This section describes whether, according to the team, the project is successful or not and a summary of the supporting reasons. It also includes a summary of the recommendations for future enhancements.

7. References

This section includes all references cited in the technical report body. You should use established reference formats. Limit your citations to 12.

8. Appendices

This section includes all appendices. You may include selected documentation's, UML diagrams, source code, user guides, manuals, etc.

There should be at least two appendices:

Appendix A . Project Management and Team Information

This appendix briefly describes the development process and the development team including:

• Team roles and role assignments: e.g. team leader, Webmaster, librarian, dba, developer, technical writer, etc. A team member may take multiple roles.
• Schedule: timetable, deadlines and deliverables.
• Software metrics analysis (optional): included planned and actual man-hour of activities; analysis of team member log books, etc.

Appendix B: Major tasks and contributions

The detailed percentage breakdown of each team member's contribution on each major task must be included in this appendix. This is a very important input for grading.