MONASH UNIVERSITY
SCHOOL OF COMPUTER SCIENCE AND SOFTWARE ENGINEERING
THIRD-YEAR COMPUTER SCIENCE

NOTES : CSE3301 Project Report

1. Preliminaries

This document aims at providing a general but concise statement of what is expected from third year Computer Science students when they prepare the final reports for their CSE3301 project work.

Unless instructed otherwise by the project supervisor, each student must submit a report for their CSE3301 project work. Please note that there may be some team projects and, in such cases, the supervisors may ask you to submit team reports rather than individual reports. The expected content and format of the report are outlined in the following sections. The deadline for report submission is posted elsewhere.

Before going into the guidelines for report preparation, students are urged to note that CSE3301 is a SIX point subject and, as such, a student is expected to devote about 150 hours to it.

Out of the thirteen weeks available in the semester the first week is spent in making project allocation. Thus, the students get only twelve weeks for working on the project, including the submission of the final report. Accordingly, they may use the following weekly schedule as a framework for their preparation:

  • Week 1 Preliminary reading
  • Week 2 Basic plan of attack
  • Week 5 Basic parts of some code
  • Week 7 Basic plan of report
  • Week 9 Working prototype of code
  • Week 10 Draft report
  • For different projects the scheduling might be very different, eg, more theory oriented projects would require a lot more reading and probably much less code writing. Your supervisor will advise you on how expectations differ in your particular project.

    Now let us move on to the guidelines for the preparation of the project report. This may vary to some extent from project to project. It is essential that where a student feels the guidelines are inappropriate or in need of modification, he or she should clarify exactly what is expected with their supervisor.

    2. Project Report

    The Project Report provides a complete account of your efforts towards completing the assigned project.

    The contents of the bulk of the report should be organized in a manner which allows the casual reader to quickly identify what you were aiming to achieve and how much has been achieved. At the same time, the serious reader of the report must be able to easily determine how your achievements have been realized.

    One suggested organization for your report is given below; obviously the detailed format and contents is a matter of choice depending upon the nature of the project (especially for non-programming projects) and prior agreement between the student and the supervisor.

    Unless told otherwise by the supervisor concerned, the report must be typed on A4 stationery with standard margins. It is anticipated that most reports will be between 8 and 16 pages in length.

    2.1. Identification

    (1) Your Name

    (2) Project Title

    (3) Report Date

    (4) Supervisor's Name

    (5) Access information for the supervisor/examiner to run the project software, such as, machine on which developed, usercode and password.

    2.2. General Description

    (1) A brief description (in your own words!) of the project task or tasks, including the relationship to other work (by previous students, the supervisor or your peers).

    (2) Any theoretical material or reference material relevant to understanding either the task or the solutions to be evaluated and/or employed in the project. It is important to include information on references YOU have consulted and a discussion (where appropriate) of relevant previous work by others (including references to THEIR work). References must include full bibliographic data, e.g. Nurd, Fred J. (1983): "Counting the Vertices of a Circle", Journal of Irreproducible Results, vol. 7, no 5,.pp 13-12.

    (3) A discussion of any assumptions made in developing the solution to the problem, and an evaluation of alternative solutions.

    (4) An outline of the method of attack.

    2.3. Achievements

    A summary, with particular emphasis on limitations of the solution and where the achievements are less than was anticipated (based on the statement of the problem) an explanation of why the goals were not reached.

    2.4. Project Documentation

    This section should provide a detailed description of the project solution aimed at both users and implementors (modifiers).

    2.4.1. User Interface

    Essential components of this section include:

    1. How to start using the "thing" (program or lump of hardware); configuration and/or initialization parameters, defaults, etc.
    2. Complete definition of the user input data and/or command syntax and semantics.
    3. Types and meanings of results expected for the various user input options.
    4. Permanent data files (e.g. input-output files, database files, libraries); names and uses.
    5. Temporary files (e.g. sort scratch); names and uses
    6. When the information is available provide estimates of resource consumption (e.g. data file sizes, run-times, report sizes) expressed as mean or typical values and maximum/minimum expected values.
    7. In situations where error reporting and recovery is not self-evident, include a step-by-step description of how to recover from automatically detected errors, and a synopsis of error conditions which are not (or cannot be) detected except by the end user.
    8. Where the solution provides simple and "bells and whistles" modes of operation, ensure that the user requiring only the simple facilities can readily determine how much of the user interface is relevant.

    2.4.2. Implementation

    Start with a functional description of what the solution does and a synopsis of how the solution has been structured (e.g. include a call tree or block diagram).

    Include a detailed description of all file structures, significant data structures and non-trivial algorithms.

    For each substantive module in the solution provide a description of sufficient detail to allow the reader to discover

    1. What the module does
    2. The interface between the module and the environment in which it must operate (e.g. pin assignments and signals, or parameter definitions and essential global data)
    3. The method by which the module implements its stated function
    4. The relationship between this module and other modules.

    2.4.3. Evidence of Testing

    Describe in general terms the tests which have been performed in an attempt to validate the correct operation of the project solution. The emphasis should be on summarizing the testing procedures that were employed, rather than including a box of listings and claiming this proves the program was tested.

    Where practical, include the transcript of one or more invocations of the solution which demonstrate all the supported features. Such a transcript must be self contained to the extent that another person could reproduce the results using your solution (i.e. include all system-level commands, file assignments, input data, option settings and output data.)

    2.5. Concluding Remarks

    What has been achieved? Attempt to summarize your own accomplishments, as opposed to the prior achievements of others.

    Suggested enhancements to overcome limitations, or to support additional useful facilities.

    2.6. References

    It is very rarely that a student completes a project without reference to the literature or the prior work of others. Include all books, articles and notes which you used during the course of the project.

    2.7. Appendix A

    The actual program listings or circuit diagrams which should be well commented and (where possible) cross-referenced.

    REMEMBER, REQUIREMENTS VARY DEPENDING ON THE PROJECT AND YOU MUST CONFIRM WITH YOUR SUPERVISOR WHETHER THE ABOVE SCHEME IS APPROPRIATE FOR YOUR PARTICULAR PROJECT.

    Last updated by Alan Dorin 17/12/2001.