CSCI 6838 Capstone Projects
Guidelines For Final Reports

by K. Yue, August 2004

This document describes the general requirements and format of the final report, with input from various sources, including Dr. Boetticher.

1. 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 important aspects of the project. Assume that the readers to be general computing professional who are interested in general computing technologies but do not necessary know much about the university and your project.

Note the difference between powerpoint slides and a technical report. Presentation slides need not be complete as the presenter can further elaborate during the presentation and the audiences may ask question. On the other hand, a final report needs to tell the entire story by itself. Thus, pure bullet forms with further explanation do not work 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 would be found in the appendix may include detailed computations, generated output, and source code.

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.

1.1 Submission Requirements

• Turn in one hardcopy of your final report, together with my commented earlier version. You may want to turn in one copy to the mentor too, if applicable.
• All final copies should have a vello binding. You may want to check around for better prices.
• Soft copies of the final report should be prepared in the following formats:
  • MW words document or Latex, and
  • PDF
• Filenames for the final reports should use the following format: [semester][year]_[group]_final_report.[file extension], where:
  • [semester] can be 'spring', 'summer' or 'fall'.
  • [year] is the year in four digit.
  • [group] is group1, group2, group3, etc.
  • [file extension] can be "doc", "tex" or "pdf".
• Filename examples: fall2004_group2_final_report.doc, spring200_group5_final_report.pdf, etc.
• These final reports must be accessible through your project's Website in the top level, e.g. http://dcm.uhcl.edu/capf04g5/fall2004_group5_final_report.doc. Additional links to the reports should also be provided by your team's Web site.

2. Final Report Formatting Requirements

• Title: Left-justify the title of the technical report in all capital letters on the first line of the first page.
• 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.
• Page numbering should be placed in bottom center.
• 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. Left justify section and subsection headings in bold. Section headings should be in upper case characters. Only the first character of subsection should be in upper case character.
• Make sure to label every figure and table. Use the following labeling convention: Labels for tables go above the table and labels for figures go below the figure.

2.1 References and Citations.

References should be 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.

It is very important to properly quote important work. Contribution by others should be properly quoted so not to appear that the work is done by your team. Failing to do so is a form of plagiarism.

Use the reference format of the Consortium of Computing Science in Colleges (CCSC):

http://www.sci.tamucc.edu/~ccscscc/miscforms/manuscript_guidelines.pdf

Note that you need to adhere only to the parts of "Citations" and "Reference List" of the CCSC guideline, which describes reference format.

3. Final Report Contents

Your final report should have the following contents:

3.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., Summer, 2001)
• Report date

3.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. It is limited to one page.

3.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.

3.4. Narrative

The narrative body is limited to 14 pages long. Topics that may be included in the narrative include the following components. However, other contents appropriate to the projects may also be included.

3.4.1 Introduction and Problem Specifications

This introduces the problem, its significance, context and specifications, existing current work and related problems. It may also provide an overview of the solution described by the report.

3.4.2 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 choices.
• Software development model used.
• Implementation issues: difficulties encountered and techniques to overcome them.
• Comparisons with other alternative solutions.

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

3.4.3 Evaluation of Solution

This provide evaluation of the solution prototype. Typical issues to be addressed may include:

• how well does the solution solve the original problem?
• how well is the design of the solution?
• the functionality of the solution prototype.
• the performance of the solution prototype. Is it fast enough?
• the reliability of the solution prototype. For example, is it transaction safe?

3.4.4 Conclusions, Lessons Learnt and Future Directions

Examples are:

• how successful is the project,
• what lessons are learnt,
• recommendations for future directions, such as:
  • future changes in the design of the solution,
  • adaptation of solutions to related problems, and
  • future enhancement of the solution prototype.

4. References

You should forward the reference and citation guidelines in section 2.1.

5. Appendices

Source code, screen shots and other less important details can be included in the appendices. There are no limit on the sizes of the appendices.

The mandatory first appendix must provide information about project management and team's basic data

• Team roles and role assignments: e.g. team leader, Webmaster, librarian, dba, developer, technical writer, etc. A team member may take multiple roles.
• Tasks: major tasks of the projects.
• Task assignments: who do what? Use a Gnatt chart.
• Schedule: timetable, deadlines and deliverables.
• Software metrics analysis: included planned and actual man-hour of activities; analysis of team member log books, etc.

The detailed percentage breakdown of every major task must be included. This breakdown will be used as an important input for grading.