You must each submit an individual report at the end of the second semester worth 75% of your total mark. You will also have to submit a complete set of the deliverables that you developed for your part of the project including any models, test cases and source code. The individual report is marked by your supervisor and moderator.

We would expect the main body of the final report to be approximately 12,000 – 15,000 words and should not exceed 20,000 words. This report builds on the team report. The report should not repeat the contents of the team report, but may refer to it and expand on it. The report should include:

• an introduction to the project including a summary of your agreed individual responsibilities;

detailed design and any further analysis of the problem specifically relating to your part of the project;

• a discussion of the development of your part of the project covering implementation and how this integrates with the rest of the team;
• discussion of the testing used at a team and individual level, e.g. validation, unit testing, integration and systems testing;
• an evaluation of the product and process at a team and individual level;

an analysis of the team dynamics and a reflection on what you have personally learnt from carrying out the project;

• conclusions and future work.

A possible structure for your final report is:

• Title Page
• Abstract
• Acknowledgements
• Table of Contents

1. Introduction
2. Detailed analysis and design
3. Implementation
4. Testing
5. Evaluation
6. Reflection
7. Future Work and Conclusions

• References
• Appendices

Each of the sections of the main body of the individual report are discussed in more detail below. You can use this characteristic structure as a rough template for organising the material. However, often it may be of advantage to adjust the suggested structure to your particular project instead of sticking to the template. Consult your supervisor for advice. It is also a good idea to plan roughly how long each part should be before writing the report, to make sure that the length and overall balance are about right. You can then construct each part to produce a first draft of the main body.

The Introduction should relate the student’s individual contribution to the team report and discuss any changes, extensions or new insights. It should outline the suitability, scope, and originality of your part of the system. It should also provide a summary of your agreed individual responsibilities.

The purpose of this section is to provide information on the detailed analysis and design of YOUR PART OF THE SYSTEM that has been done since the team report. This section may describe such things as:

• the problems and challenges that has been identified,
• research and/or further analysis to fully understand the problem area
• any constraints on the approach to be adopted,
• existing solutions relevant to the problem area, and why these are unsuitable or insufficient in this particular case,
• any further methods and tools (not discussed in the team report) that your part of the solution may be based on or use to solve the problem,
• consideration of legal/ethical/professional/social issues

Long descriptions of details are to be avoided and references to suitable sources of detailed information should be given instead.

Possible viewpoints of the design might discuss:

• the business model the software supports,
• the user interface,
• the dynamic behaviour of the system,
• what data types are implemented in the system,
• what algorithms are implemented in the system,
• the static architecture of the system, i.e. how the code is partitioned into modules, etc.

Fine details, specifically details of code, should be left out. We strongly recommend that you make extensive use of diagrams, such as entity-relationship diagrams, UML diagrams, state charts, or other pictorial techniques.

As well as describing the system, it is important that you justify its design, for example, by discussing the implications of constraints on your solution and different design choices, and then giving reasons for making the choices you did. Typically these implications will relate to the aims of the project; to the relevant functional and non-functional requirements specified in the Team Report and to any innovative aspects of your design.

The design of the system will almost certainly have evolved while you were developing it. Obviously you should describe its final state but often there are good reasons for describing intermediate states, too; for example, if you want to discuss the details of the design method used or to highlight learning that you later refer to in the Reflection section. If you do this, take special care to make sure the reader does not get confused between different stages of the design.

The Implementation section is similar to the previous section in that it describes the system, but it does so at a finer level of detail, down to the code level. It can also describe any problems that may have arisen during implementation and how you dealt with them.

Do not attempt to describe all of your code in the system, and do not include large pieces of code in this section. A complete listing of your source code should be provided separately in the appendices. Instead pick out and describe just the pieces of code which, for example:

• are especially critical to the operation of the system;
• you feel might be of particular interest to the reader for some reason;
• illustrate a non-standard or innovative way of implementing functionality

You should also mention any unforeseen problems you encountered when implementing and integrating your part of the system with the work of the rest of the team and how and to what extent you overcame them. Common problems are:

• difficulties involving existing software, because of, e.g.,
• its complexity,
• lack of documentation;
• lack of suitable supporting software;
• complications with specific hardware or software platforms;
• over-ambitious project aims.

A seemingly disproportionate amount of project time can be taken up in dealing with such problems. The Implementation section gives you the opportunity to show where that time has gone.

In this section you should describe your testing strategy and to what extent your part of the system achieved your goals.

This should include a discussion of the testing approaches used at a team and individual level, e.g. validation, unit testing, integration and systems testing. This is also the place to describe the reasoning behind the tests to evaluate your results, what tests to execute, what the results show and why to execute these tests.

You should also describe how you demonstrated that your part of system met or exceeded the functional and non-functional requirements of all relevant stakeholders.

Include comprehensible summaries of the results of all critical tests that were carried out. Detailed documentation of tests can be included in the appendices.

This section provides a critical evaluation of the final product and the process used to develop the product. This should include:

• a critical evaluation of the whole product including coverage of the strengths and limitations of the solution system
• a critical evaluation of the whole process in the form of a discussion that includes the effectiveness of the tools/techniques and the choices made by the team and the student for each phase/iteration of the whole project
• an analysis of the dynamics of the team in carrying out the whole project. This should be done in a professional manner. Do not include an evaluation of named individuals in the team but discuss how behaviours, problems and actions experienced in the team promoted or hindered effective teamwork .

One of the principles applied throughout the assessment during your studies is that of the value of reflection. We believe that it is important that we reflect upon our performance in order to identify “transferable learning”, that can be carried over into future activities. For example, a “reflective practitioner” would try to identify the characteristics of the problem that has been addressed, and consider whether assumptions or decisions about the relevant approach to solving that problem had been appropriate, in order to make a better decision in relation to problems that might be encountered in the future.

It is quite likely that by the end of your project you will not have achieved all that you planned at the start; and in any case, your ideas will have grown during the course of the project beyond what you could hope to do within the available time. The Future Work section is for expressing the unrealised ideas for your part of the system.

The Conclusions section should be a summary what you have achieved regarding the suitability, scope, and originality of your part of the system and its main results. An effective set of conclusions should not introduce new material. Instead it should briefly draw out, summarise, combine and reiterate the main points that have been made in the body of the project report and present opinions based on them. The Conclusions section marks the end of the project report proper. Be honest and objective in your conclusions.

This is a summary of the report. It must be less than 300 words long. It should give enough information to allow a potential reader to decide whether or not the report will be of interest to them. It should briefly describe the main ideas of the report, including the aims and conclusions. It should be both self-contained and self-explanatory, and it should not say anything not mentioned in the rest of the report (for this reason it is usually written last).

This optional section should be used to record indebtedness for the use of facilities or help from particular sources. You should mention any organisations or people who have helped you while you have been carrying out the project.

A project report that uses figures (i.e. diagrams or other pictorial techniques such as tables) to illustrate ideas will probably be easier to digest than one that does not. We therefore recommend that you use figures wherever appropriate.

When drawing diagrams try to keep to a standard graphical notation that has been introduced during your studies, or that you have seen published widely, and use it consistently.

All figures should be labelled and captioned, for example,

Figure 3.10: Sub-System Architecture.

The label can then be used to refer to the diagram within the text, e.g.

See Figure 3.10.

All diagrams must be explicitly referred to somewhere within the text.

We said that you should relate your work to that of other people. Other work explicitly cited should be listed in the Reference section should be referenced using the Harvard Style. It is important that you give proper credit to all work that is not strictly your own, and that you do not violate copyright restrictions.

Guidance on the Harvard Style of citing and referencing may be viewed at http://www.cardiff.ac.uk/insrv/resources/guides/inf057.pdf.

Guidance on plagiarism and how to avoid it is available at http://learningcentral.cf.ac.uk/bbcswebdav/institution/INSRV/Study%20Skills/plagiarism2/new/index.html.

Note that it is seldom sufficient to simply “cut and paste” material from other sources. When you take material from someone else's work, you are doing so because it helps support your argument, or justify decisions you are making. It is therefore essential to make it clear why you have included material from other sources; in other words, you need to critically assess the work of others, whether it is supporting your position or not.

Appendices are where you present material which you want to include in the report, but which would seriously obstruct the flow of ideas if put anywhere in the main body. This should include a complete set of the deliverables that you developed for your part of the project including any models, test cases and source code

Appendices should be headed by letters in alphabetical order, i.e. Appendix A, Appendix B, etc.

The main body of the project report should be divided up into sections, along the lines suggested in Structure and Contents or otherwise, as appropriate. Each section should, if necessary, be divided up into subsections, and so on recursively. This can become obscure though if the nesting gets to more than about three levels deep.

It is important that you start each section and subsection with a summary of the rest of the material in it, i.e. inform the reader of what you are about to tell them. This has the effect of “softening up” the reader so that when they move on to the body of the section they feel confident about the direction in which you are taking them. They are reassured at regular intervals when they encounter ideas that you have told them to expect. Without the overview the overall effect is like a mystery tour of ideas, with each new idea coming as a surprise. It is sometimes difficult to appreciate the need for this when you are the author because you are already intimately familiar with the whole route that the report takes. Each major section should begin on a new page. All sections and subsections should be numbered and headed. Numbering should be like this: 3.10.7 – for subsubsection 7 in subsection 10, in section 3.

There are all kinds of stylistic conventions relating to technical writing that you should try to follow. For example:

• do not use shortened forms such as “don't” for “do not”;
• avoid colloquialisms and slang words;
• use British English and write in complete sentences;
• divide your writing up into paragraphs;

Writing where the language style or typography, e.g. font or character size, change arbitrarily looks amateurish and can be very distracting for the reader. Use typography to support the content. Other places where consistency should be maintained include:

• bullet points,
• use of hyphens,
• use of capitalisation,
• technical terms,
• abbreviations,
• use of symbols.

To some extent you can use your own judgement about what conventions to follow. Whatever you do though, you must be consistent.

Individual report coursework instructions: ODT, PDF