Assessment will be by a demonstration of the programs and by a written report, coupled with an assessment of your group work, problem solving skills and project management over the course of the project. All members of the team should be present at the demonstration. The demonstration is more important than the report, but significant credit will be lost if no report is submitted.

The team report should contain:

1. The team diary
2. A summary of who did what
3. A brief outline specification of the final program produced by the team.
4. Any further comments by the team as a whole.

This is unlikely to be more than 4 pages of A4.

The individual report should contain:

1. Your personal diary, together with a summary of the total number of hours you spent in each category.
2. The final program specifications of your contribution.
3. Your final program designs in very broad outline only, but mentioning key design decisions.
4. Any further commentary on your contribution to the project, including a brief description of test procedures.

This is unlikely to be longer than 4 pages plus diary per person, ideally less.

When writing the report, bear in mind that a common fault of documentation is to dive too quickly into fine detail, without giving an adequate overview. Take as much care in structuring your documentation as you do in structuring your programs. A detailed design description of your programs is not required, but programs should be adequately commented. You will lose credit for any programs that are not minimally commented with the name of the author, the date of completion and a description of the purpose of the program. All important routines should have similar comments together with an outline specification of all arguments required, globals accessed and results returned, and any other information which is important to a programmer using that routine. Use of Javadoc is strongly recommended, but the javadoc should not be included in the report.

The team report, together with individual reports of all members of the team, must be handed in together in a suitable wallet so that all parts are conveniently accessible and clearly labelled.

Assessment breakdown will be approximately as follows:

Nevertheless, all three aspects are essential and anyone who fails to give a demonstration, or who fails to submit a report, or who fails to contribute to the team, will be given very few marks overall.

Important

If the marks for the team are not to be split equally, owing to someone's exceptional effort, or reduced contribution, then all team members must submit a note identifying the altered proportions of marks to be allocated, signed by all team members. This has to be submitted at the same time as the final report, not later. If you have worked harder than your colleagues, you should ensure that you gain the appropriate credit. If you are too shy to negotiate it with them, you will not receive any preferential treatment. It is up to you and the team to be fair to all.

1. A written report must be submitted by not later than noon on the second Wednesday of the Summer Term
2. The programming must be completed ready for demonstration by the beginning of the second week of the Summer Term

You should make allowance for all reasonable eventualities - arguments such as ‘the computers were all in use whenever I looked last week’ or ‘I had the flu for three days and fell behind’ are most unlikely to be accepted.

You are strongly advised to assume that the deadline is the end of the Spring Term, so you have some time in hand in case of disaster! The choice, and the risk, is yours. Please don't try to blame someone or something else if your program is not working at the time of the demonstration.