Project Finishing Notes

1. ASSESSMENT CRITERIA

Each project will be assessed based on the following criteria:

CORE CRITERIA
* light-weight, relevant modelling, generally in accordance with a recognised process and mostly expressed in UML. (15%)
* project-related communication including, but not limited to: keeping appropriate logs, writing well-constructed formal reports, maintaining sketches of ideas in diagrammatic/written form in UML or otherwise. (15%)
* implementation based on the modelling and the content of the reports. (30%)
* appropriate mix of (a) originality, (b) innovation and (c) complexity (25%)

CRITICAL SELF-REVIEW
* what you learned (5%)
* what you achieved, and in what direction the project might be taken if more time were available (5%)
* how problems were addressed and solved (5%)

What should be included in your final report:

2. BSc (H) Final Project report sections,
for an educational system – with your supervisor, tailor these notes according to the domain of your own project.

Suggested inclusions:

See also all relevant information in

Organisation of the projects for ALL four programmes, particularly the discussion of the layout of the front cover information, and form of words that must be used for the signed declaration.

1. conceptual genesis of the project (i.e. where it came from so to speak)
2. description of the projects (words/diagrams)
3. user manual for the pupil (in case of educational project)
4. user manual for the teacher (in case of educational project)
5. pedagogical notes for the teacher/parent (in case of educational project)
6. reasons for your choice of development methodology (you do NOT need to provide, indeed should not) a tutorial on that methodology if it's based on a published one, rather than one of your own devising. However, explain any personal customisation of the methodology.)

7. how risk was managed and mitigated, particularly risks associated with (a) skills (b) technology and (c) user requirements.
8. outline of the software/hardware technologies you've used but not the details (in other words you should NOT provide a tutorial course for your reader copied from books, the WWW etc.)
9. all the code you've written, with comments, paragraphed, and with carefully chosen words for the names of methods, classes, variables and objects; you might consider laying out the code in landscape page layout to reduce risk of wrap-around causing long lines to wrap round to the extreme left margin of the page.
10. finishing/developmental documentation particularly in diagrammatic form

11. discussion on the design of the user interface/graphic design – any research done

12. discussion of the database – how it was designed/implemented, including diagrams.

13. discussion of how the application’s data is saved on to secondary storage

14. discussion of dialogue with stakeholders or, if none, how the needs of potential users of the system were researched.
15. what problems you encountered and how you tackled them
16. what tricky and or interesting things you learned
17. the blog (you can point to it via a web address) or log/minutes of meetings
18. where you would see the project going in the future whether under your own or someone else's direction
19. what additional learning you gained this year about "doing projects", how you planned to manage your time week by week shown in a table or a graph, and any deviation from that plan; in the case of an iterative project, what use cases/scenarios were planned to be delivered/actually delivered in each time box.

The documentation should be good enough that another developer should be able to continue your project! It should have the usual contents page; page numbers ABSOLUTELY ESSENTIAL etc.The finished document might not be quite as thick as a telephone directory but it won’t be a thin document either!

The title page should emphasise a 10 or so word description of the project and your name, The words final report should be in smaller letters. Name, class, student number, and project number (see project demo timetable for the project number in the left column).

And now a description issued to the Multimedia students, but which others would do well seriously to consider

Final Documentation for 4th year project

Following headings and details should be treated as a guide only

Project Report

  1. Abstract
    At this stage, this has already been completed; however it may need some adjustments.
  1. Declaration

This is a signed declaration of own work.

  1. Introduction
  2. Overview
  3. Risk Management, e.g. where there software risks, and if yes, what plans were in place to resolve these.
  4. Approach/Considerations - hardware/software, similar projects, constraints.
  5. Project Analysis and Specification

a)Project Size – e.g. individual project

b)Economic Feasibility – could project be marketed and sold; or perhaps adjusted and reused.

c)Organisational Feasibility – user options/updating options.

d)Technical Feasibility – your familiarity with the technology, etc.

  1. Requirements Analysis – s/w functions, include description, benefit, critical factor.
  2. Methodology – as before, it shouldn’t have changed. However if it has been changed, this should be discussed in detail.
  3. Specification of Data Structures – table design, dB normalisation, etc.
  4. User Interface
  5. Management of the Process – detailed schedule
  6. Project Evaluation – re-occurring problems, immediate and long term project outcomes.
  7. Testing
  8. User Manual
  9. Conclusion
  10. References
  11. Appendices

3. Concluding words:

So whose description of what should be in a project report should I follow? Well, you’ll see that there’s substantial overlap. What you MUST do, with the emphasis on MUST, is print out two copies of these notes and take them to your own supervisor, go over everything carefully, with him/her and decide what is appropriate to your own project. What you come up, however, in terms of a set of guidelines appropriate to your own project MUST substantiallyagree with the advice given above. You will be held accountable for anything you’ve unwisely chosen to omit. If your project report is something entirely different from the above, you’ll be in danger of failing. The final project report is a very important piece of work. It should be such that in conjunction with your demo, it takes account of the assessment criteria shown in brown at the top of these notes.

Three copies of your report are to be provided in hard copy form and three discs each with your report and with extra material such as source code. Please hand all these to your supervisor.

1.