9.2. Main areas

There are four areas that will be assessed in the project report. These areas contribute 70% of your overall module mark.

  • Problem Analysis - 15%

  • Technical Work - 35%

  • Critical Evaluation and Insight - 10%

  • Dissertation Presentation Quality - 10%

These areas are discussed in the following sub-sections.

Problem Analysis

This area will assess the project as described in the background, objectives and overview of the development process or research method(s).

  • Preparation: This will assess how well you researched the background to the project topic, how well you understood what you read and how well you presented this preparation with appropriate citations and references. This might include, but is not limited to, discussion of papers read, technologies investigated and any similar tools that you have evaluated.

    Some of the material you wrote for your Project Outline may be reused here, but it would need to be more detailed because you are expected to have done more since the first two weeks of term.

  • Analysis: This will assess your understanding of the problems for your project, how well you assessed alternative approaches and your justification for the approach you selected.

    There should be a clear statement of the objectives of the work or the research question, which you will evaluate at the end of the project.

    For plan-driven software development projects, it would be appropriate to include a full requirements specification as an appendix of your final report and refer to the key issues in this section. For an agile approach, the requirements should be expressed in a format appropriate to the choice of agile approach, e.g. a set of user stories.

  • Process/Method: This will assess the process you have followed to manage and organize your work. Engineering projects should talk about a development methodology. A research-based project would talk about an approach that looks at the design of a hypothesis and how that will be tested and evaluated. A research-based project would also need to discuss a relevant software development methodology for the software produced to support the research.

This section should state what the general approach is and justify that choice. The detail showing how the approach was used should be evident from the Technical Work section (see below). What you write should be consistent with how your supervisor sees you working each week throughout the project.

Technical work

This area will assess the technical achievement, based on the following aspects:

  • One of:
    1. Design for engineering-based projects. The student should explain the design for the system. There should be an indication of how the design has evolved and the decisions taken. The discussion of the design will relate to the choice of process or method.

    For example, if the project follows a plan-driven approach such as the Waterfall model, then the student should have produced a design specification. The full specification could be included as an appendix or a separate document in the technical submission. Then, parts of this are discussed in the main body of the report.

    1. Experiment method(s) design for research-oriented projects. The student should explain the overall hypothesis being tested and justify the approach selected in the context of the research area. Within this context, the student should also describe the experiment design that has been selected and how measurements and comparisons of results are to be made.

    There will also be explanation of the design of the software that is going to enable the experiments. As with an engineering-based project, there should be an indication of how the design has evolved and the decisions taken. The discussion of the design will relate to the choice of process or method.

  • Implementation of the design or experiment methods. Discuss any difficulties encountered (such as fundamental limitations of the language or problems integrating software, or issues with the approach adopted) and how you overcame them. Describe any other significant problems you encountered and how you overcame them or whether the problems remain.

  • Quality of the technical output, including code, tests and test data. Other issues could be considered where appropriate for the project. For example, hardware aspects may be relevant.

  • Where appropriate, consideration of security aspects in the design, implementation and testing of the product.

  • User evaluation may be relevant to some projects. This would form part of the testing strategy. Whether or not this is relevant should be discussed with the project supervisor. If it is used, it should be a compliment rather than a substitute for testing.

  • Projects, which have an identifiable client, should discuss the interactions with the client during the development.

The choice of development process might influence how this information is ordered and presented in the report. For example:

  • A plan-driven engineering project would be expected to have produced up-front documents for design and testing. The full versions of such documents would go into the appendices or in the technical submission, with appropriate discussion of key issues included in the body of the report.

  • An agile approach would typically have iterations, so the description of experiments, design, implementation and testing might evolve over several iterations. Detailed information that demonstrates the iterations, e.g. CRC cards for the design and story cards for iterations, may be better in appendices. The body of the report would have an appropriate discussion of key issues included in the body of the report.

Critical evaluation and insight

This area assesses the quality and detail of your analysis of the strengths and weaknesses of the work that you have produced. Your analysis should also evaluate your approach to the project.

You should summarize what you have achieved in comparison with the original project aims and assess critically the work that you have carried out. How could you have improved it? Would you approach it differently if you were to start the project over again? If you continued with the work, how would you extend the project?

Report presentation quality

This area will assess the quality of the report, including the structure and presentation of the material, including appropriate ordering of the contents, ease of reading and ease of finding specific sections. This can include issues such as the correctness and appropriateness of the language and the quality of diagrams, tables, images, screenshots, etc. Formatting and detail of the references is also assessed.