Team Java 2004/05 Report Format

For more details on the assessment criteria, see the assessment page.

The total length of the report should not exceed 30 pages in at least 10 point font and normal line spacing. Attempting to squeeze in as much text as possible is counterproductive, since it is quality, not quantity, that matters, and waffle will only lose you marks. There is no lower page limit, but writing much less than 20 pages is not recommended unless you are a master of clarity and concision. The report must be written in an acceptable style of scientific English. Some students may find it useful to consult a manual on writing, such as Strunk and White's "The Elements of Style". The harmless apostrophe does not deserve to be abused.

The project report must contain the following, with the same numbering and titles. You can add subsections, such as 3.1, or 3.2.1, as necessary.

The title page must include:

• the words "Software Workshop Team Java (06-08165) 2004/05, Dr H. Thielecke";
• the team number (such as A1), in a large font;
• the names (not the ID numbers, which must be kept confidential) of the team members.

You should write a one-page "Executive Summary". It should be written for someone who is familiar with the Team Java module, so that there is no need for background or generalities. Rather, you should explain what is special about your project, and what you claim to have achieved. (One page maximum.)

You also have to give a breakdown of the contribution of team members to the project, detailing who did what. The individual contributions should refer to page or section numbers of the report. You can include a suggested allocation of percentages of credit to each team member, but it is optional. This may be taken into account in marking, but will not necessarily determine the marks you get. All team members must sign this page, with the possible exception of members who have in effect dropped out of the project. (One page maximum.)

There has to be a table of contents with page numbers.

The main part of the report should contain these sections, with the same numbering and headings (insert sub-sections as needed):

1. Introduction
   Give a brief overview and guide the reader to the important points in the following sections.
2. Requirements
   You have been given only a very general set of requirements; hence you have to formulate more specific and detailed user requirements and explain why you chose these features. Explain your choices carefully (not just lists of bullet points). Note that not everything about requirements in general is relevant for this project (for instance, you need not write much about the hardware requirements, as they are trivial for this project).
3. Design
   This section is crucial. Describe the overall structure of your program at a suitably high level of abstraction. For instance, UML diagrams or informal box-and-arrow diagrams can be used to descibe program structure. Note that code listings or screenshots are not appropriate here. An important point is how you have divided the project into modules that different team members can work on, and how these are then integrated. For example, you could use interfaces to describe a clean boundary between modules, so that some team members use the functionality provided by the interface, while another team member implements it. Bear in mind Software Engineering principles of good design like coherence and coupling.
4. Validation and Testing
   Establish what your project can handle successfully, and what its limitations are. Use meaningful examples, not lists of trivial cases.
5. Project Management
   The week-to-week management of your project is documented in your weekly progress reports, so you do not need to repeat that information here. A number of important points that you need to address are: how you divided up the work, allocated team members to particular tasks, coordinated what team members were working on, and communicated the relevant technical information in the team. Note that a clean design makes all of these easier, so you could refer to your design section where appropriate. You can also discuss difficulties in the team interactions if there were any, and how you dealt with them.
6. Conclusions
   Evaluate what you have achieved in your project in objective terms (not just things like "we are all happy with the result."). What are the strenths and limitations of your project? If you had more time, what could you add? If you could do it all over again, what would you do differently? Are there general things about software or team management that you have learnt in this project which you could apply if you were going to work on a (perhaps completely different) team project in the future?
7. References
   Acknowledge any code you have used (if any). Give correct and complete bibliographic information for any sources cited. See the local referencing guide.

Additional supporting information can be provided as an electronic appendix in the CVS repository. Possible examples include: user manual, test data, etc.

Plagiarism

Penalties for late handing in of the report