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

NOTES CONCERNING CSE3301/CSC3010 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/CSC3010 project work.

Unless instructed otherwise by the project supervisor, each student must submit a report for their CSE3301/CSC3010 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 as follows:

Report Due by 12:00 Noon Friday 20 February, 2000

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, and
• CSC3010 is a FOUR point subject and, as such, a student is expected to devote about 100 hours to it.

Out of the thirteen weeks available in the semester, the first week is spent in making project allocation. Thus, 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 (where "week i" means the i-th week of Semester, and bearing in mind that the project starts in the second week of Semester):

week 2: preliminary reading

week 3: basic plan of attack

week 5: basic parts of some code

week 7: basic plan of report

week 8: working prototype of code

week 10: draft report

week 11: finish code

week 12: finish report

week 13: tidy up any "loose ends"; submit

For different projects the scheduling might be very different, e.g. more theory oriented projects would require a lot more reading and probably much less code writing.

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.