User Tools


cm3301_guide

CM3301 Software Engineering Project

This is the main page for information about the 40 credit two-semester software engineering project module CM3301.

* CM3301 Guide: The complete guide for CM3301 on a single page for printing/saving as PDF.

Project Selection

At the start of the module you will be given a list of group projects proposed by some members of staff. You will be asked to indicate your preferences for the projects based on the descriptions. You may also want to ask the members of staff proposing projects for more details or clarify anything in the description. By the middle of week 1 you will have to submit your preferences and we will then assign you to a team, based on your preferences and past performance to achieve a good balance of skills for each team. Each team will have an assigned project with one supervisor who initially will be interacting with the team as a whole and later on have individual meetings with each member to discuss their part of the project. Each team will also have a moderator assigned to them.

You will be notified via learning central announcements and e-mails on the detailed arrangements and deadlines. The overall module arrangements and projects will also be discussed with you in the lectures.

Deliverables

This is an overview of the expected deliverables and related tasks you have to execute for your project. Details on these deliverables and tasks are available on the linked pages. You also find the required deliverables with their submission deadlines on learning central.

  • Team Report: You must submit a team report covering the project initiation documentation, the requirements, software architecture and project plan in the first semester (by end of week 9 of the first semester, at most 5,000 words per team member, worth 15%).
  • Team Presentation: A team presentation on the completed project, including a demonstration of the system is due in the second semester (in week 11 of the second semester, up to 1h including audience questions and discussions, worth 10%).
  • Individual Report: An individual report on your work on the project must be submitted by the end of the second semester (by the end of week 12 of the second semester, at most 20,000 words, worth 75%).
  • Project Viva: A project viva will take place after the exams for every final year project to discuss your individual work.

Reports and presentation material will have to be submitted on learning central. For details see the instructions for the assignments there.

Guides

These guides are meant to help you produce good final year project reports. They are generic and have to be adapted to your specific module and project requirements. A good report is one that presents your project work concisely and effectively. It should contain various materials relevant to the work you have undertaken for your project; it should be organised into a logical framework; and it should be supported by written material that follows well-established academic conventions in a consistent fashion.

An important point to remember is that the report should describe your work. Large chunks of bookwork describing standard material are unnecessary. You should simply refer to such material where necessary - assume that your reader is a competent computer or information systems theorist or practitioner as suitable in the wider context of your project. The guidelines here are arranged roughly in the order that you will need them.

Your project supervisor will guide you on what it is reasonable to expect a project in your chosen topic to deliver. However, all projects are required to justify all decisions made at every stage of research and the development of appropriate deliverables, including the choice of approach.

Further information on how to prepare the various deliverables in a suitable format and related technical issues are available in these guides:

  • PDF Guide: Instructions on how to generate PDF files.

Project Coordinator

Deliverables

Team Report

You must submit a team report covering the project initiation documentation, the requirements, software architecture and project plan in the first semester worth 15% of your total mark. The final year team project is a substantial part of your degree. It can have a major effect on the degree class you are awarded and even whether or not you pass the degree. The team report is to make sure you understand what your project requires you to do and how you are going to finish your component of the overall system developed by the team and how it links with the other team members' work.

The team report is marked by your supervisor and moderator independently. Before you submit the final version you should discuss the report with your supervisor to make sure both of you agree on what your project entails. The team report should be submitted via learning central as a single PDF document by a nominated member of your team. You will get oral feedback during the supervisor team meetings and further formal written feedback by about three weeks after submission.

Finally, note that this is about the requirements and architecture for the project decided by that stage of the project. You can, and most likely should, adjust these as you progress. Note, however, that with the report you are prescribing what you intend to deliver at the various stages and how it will integrate with the other team member's work, so any change that may affect another member's work has to be discussed and agreed with the team first. In certain situations you will also have to discuss any intended changes with the supervisor to ensure they are acceptable.

Structure and Contents

Your team report should be at most 5,000 words per team member, excluding any figures, tables and appendices. You are free to choose a format and structure suitable for your specific project. However, the report must address issues relating to the project initiation documentation and contain a full set of requirements with associated testable acceptance criteria, the high-level software architecture and a work plan. In particular it should state clearly the deliverables each member of the team is working on.

There should be a description of detailed aims and objectives for the project, in sufficient detail to show what each member will be working on and also how all the individual contributions will work together in the end. These are statements of what you set out to achieve with your project. Try to be as specific as possible at this stage, but avoid getting into too many details that may change later. It's only the high-level results and components of your project that are relevant. Also ensure you are including a benefit and risk assessment with relevant quality factors, and a discussion of legal, social ethical and professional issues. It must further contain a description of the software development process the team wishes to adopt.

Frontmatter

The title of the team report document should be “Team Report” followed by the title of your project. List your team members as authors with their student numbers and list your supervisor and moderator with their roles. Please also list the module number and module title you are taking and credits due for this module. Furthermore, it must contain a separate page with the following declaration, accepted by all authors:

Declaration

By submitting this report each of its authors are accepting the terms of
the following declaration.

I hereby declare that my contribution to this document is all my own work,
that it has not previously been submitted for assessment and that I have
not knowingly allowed it to be copied by another student. I understand
that deceiving or attempting to deceive examiners by passing off the work 
of another writer, as one’s own is plagiarism. I also understand that 
plagiarising another’s work or knowingly allowing another student to
plagiarise from my work is against the University regulations and that
doing so will result in loss of marks and possible disciplinary
proceedings.

Ensure that every author has seen the final document with this declaration and is aware of its implications.

Project Initiation Documentation

Provide a brief description of your project outlining the problem you are trying to solve, its context, and overall aims. You can adapt the proposal used to select your project, but should extend it according to your findings. Following the general overview, discuss the scope of the project and specify the vision and key objectives for the project. You also have to select and justify the project management approach. Moreover, provide a risk assessment for the most significant risks and explain how these will be mitigated. This should also include managing the risks of associated legal, social ethical and professional issues. Discuss how communications will be managed within the team and with other stakeholders. You also have to select and justify the software development approach and outline the team's approach to configuration management and identify tools and techniques the team will use during implementation.

The project initiation documentation should be tailored to the specific project and its context. While in general it discusses the project goals, scope, project organisation, business case, constraints and stakeholders, this may be different for your specific project and not all or additional issues may have to be discussed.

Requirements Specification

You must provide a complete set of project requirements. Make sure you select and justify the approach to analysing the problem situation to derive the requirements. You should include associated deliverables in the appendices (e.g. transcripts of any interviews, survey results and questionnaires, process diagrams). The format/style of the requirements documentation is your team’s choice. This requirements should be presented in a format that is suitable for the selected project management / software development approach. When selecting a format, remember you are likely to do some requirements change management and version control. It needs to look professional and be understood by both developers and clients. Also provide descriptions of the most important and relevant non-functional requirements for the software with associated acceptance testing.

Software Architecture

Design a model of the high level software architecture to show the main components, interactions, services and dependencies. It is important this this is sufficiently detailed to enable every team member to work on their part of the system. It should, however, avoid prescribing too many details that may unnecessarily limit the individual project work. Ensure you consider the core concepts and principles of software design for your architecture such as decomposition, abstraction, modularity, extensibility, adaptability to change and pick a suitable architecture and hierarchical relationships between the components.

Work Plan

The team report must contain a high-level work plan for the remainder of the project with separate detailed plans for each team member stating what each member is working on when. This plan should be presented in a format that is suitable for the selected project management / software development approach. It should state clearly the deliverables each member of the team is working on. In particular ensure it includes clear milestones of what you expect to achieve by which date and also show how you intent to achieve these milestones and show the dependencies between the various tasks. Link the deliverables to your time plan, such that you actually plan to deliver them when they are due.

Your time plan should further have at least two scheduled individual review meetings with your supervisor. You should typically see your supervisor once a week for a shorter time or once every two weeks for a longer time. The details of these arrangements are for you to agree with your supervisor. Initially this will have to be between the team and the supervisor. After the team report has been submitted this should then move mainly to individual meetings between team member and supervisor, with team meetings on scheduled occasionally if needed. Independent of this, the team should agree on a regular meeting scheme, as suitable for the project and its stage. While details of meetings are decided by the team and the supervisor, you should make sure everyone knows when to meet and these meeting are suitable to execute the project effectively.

In your time plan you should mark special meetings with your supervisor where you are reviewing your progress since the last such meeting (or from the beginning) and adjust your plan for the project based on the outcome of this meeting. These review meetings are mandatory and are considered as part of the mark of the reports (see marking criteria there).

You are free to choose the work plan format that you think is best suited for your project and working style. This may be a Gantt chart, but sometimes other formats may be better. Usually a weekly scale for the work plan is a good choice. Also consider any other commitments and busy times such as the exam periods.

Marking Criteria

Your supervisor and moderator will mark your plan according to the following criteria:

  • Project initiation documentation (20%):
    • Clarity and detail of project description with aims and objectives, constraints and context
    • Suitability and justification of project management and software development approach
    • Quality of discussion of associated risks and how these will be mitigated
    • Level of understanding, consideration and broader appreciation of legal, ethical and social issues
    • Effectiveness of communication and suggested methods
  • Requirements Specification (20%):
    • Coherency and completeness of functional and non-functional systems requirements with clear justification/derivation
    • Testable acceptance criteria are associated with both the functional and non-functional requirements
    • Identification of system scope and boundaries with clear declaration of any assumptions made.
  • Software architecture (20%):
    • Quality of documentation of main components, interactions, services and dependencies
    • Level of detail sufficient to progress with individual projects without over-constraining them by unnecessary detail
    • Quality and suitability of software architecture adopting core concepts and principles of good software design relating to decomposition, abstraction, modularity, extensibility, adaptability to change, etc.
    • Level of alignment of individual team members' components to integrate into a complete system
  • Work plan (20%):
    • Quality of work plan, feasibility and specificity to the project
    • Clarity of timeline and milestones and how these are achieved
    • Suitability of deliverables and assignment of work to team members
    • Suitability of meeting schedule and approximate dates for at least two review meetings per student are given
    • Amount of work is suitable for the credits and level of the module.
  • Communication skills (20%):
    • Quality of report writing and structure
    • Clarity of expression without going into unnecessary detail
    • Frontmatter contains all required information and the declaration

All main criteria carry the weight as indicated above for the mark of the team report and will be evaluated on the following scale:

  • 70 - 100% - Excellent (rigorous, methodical, analytic, content meets all requirements of the work, very few errors or omissions)
  • 60 - 60% - Good (competent, reasoned, coherent, content very sound, few errors/omissions)
  • 50 - 59% - Fair (satisfactory, relevant, content meets many of the required elements, some errors and omissions)
  • 40 - 49% - Bare Pass (Passable, basic relevant content, weaknesses in execution errors or omissions)
  • 1 - 39% - Fail (not passable, evident weaknesses, gaps in content, evident errors or omissions)
  • 0% indicates that the team has not at all covered the topic or addressed the issue.

Supervisor and moderator will mark the report independently and your overall mark for the report is the average of the two marks.

Supervisor and moderator will provide formal feedback about your report explaining any concerns they may have and their expectations regarding the aims and objectives and deliverables. You will further get informal feedback from your supervisor in your meetings. Make sure you consider this when executing the remainder of the project.

Team Report coursework instructions: ODT PDF

Team Presentation

This documentation is preliminary and will be updated later.

A team presentation on the project, including a demonstration of system must be submitted in the second semester (in week 11 of the second semester, up to 1h including audience questions and discussions, worth 10%).

Please contact your supervisor to arrange a time for the presentation early on.

The presentation must cover the solution to the problem your team is addressing, focusing on the core challenges of the overall problem. It should address the individual core contributions of the team members as well as how these are integrated to form a complete solution of the problem. You must be able to demonstrate the system running, so make sure you test this with the whole team before the demonstration. Also do not underestimate the time it takes to integrate various solutions into one working system.

Your presentation will be evaluated by the supervisor and moderator according to these criteria:

  • Coherent and detailed presentation of the solution to the problem, focusing on major challenges of the project.
  • Discussion of how the components developed by each team member has been integrated into a complete solution and clear indication who has done what.
  • Evidence of testing and evaluation with clear statements of what the system is capable, and what not.
  • Professional presentation with clear structure and timing.
  • Engagement with the audience.
  • Handling of questions and discussions.

Supervisor and moderator will give you oral feedback after your presentation, which should be part of the 1h slot, so please allow time for feedback, questions and discussions when planning your presentation. They will also write a combined written short report on your presentation with detailed feedback to justify your mark.

Team Presentation coursework instructions: ODT PDF

Individual Report Guide

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.

Structure and Contents

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

Main Body of the Report

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"

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 "Detailed Analysis and Design"

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"

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.

The "Testing"

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.

The "Evaluation"

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 .

The "Reflection"

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.

The "Future Work and Conclusions"

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.

Supporting Material

Abstract

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).

Acknowledgements

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.

Figures

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.

References

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

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.

General Advice

Sections and Subsections

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.

Stylistic Conventions

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

Project Viva

The final part of your project is your project examination, which will take place after the exams. This viva exam will be timetabled any time in the University's Examinations period, usually in exam week 4 and 5. You must therefore remain available at the University until the end of the Examinations. You should not arrange any holidays, employment or other commitments until after this date. The timetable for the viva exams will be published as soon as possible after the submission deadline.

Note, that not attending your viva exam will result in you failing the module (unless you have extenuating circumstances in which case the viva exam will be rescheduled).

Below we explain the procedure that you need to follow for your project examination.

Your project examination is in the form of a viva, conducted by your supervisor and moderator together. The normal format of a viva is this: you demonstrate the work you have done your project to your supervisor and moderator first, and then they ask you some questions on your project. The format of project demonstration may vary. If your project has resulted in some software system or prototype, demonstration of the workings of your software in the lab will be necessary, but no formal presentation is required. If your project is of an analytic nature, then it may be demonstrated through a carefully constructed presentation, showing your analytic process and your findings. The questions that your supervisor and moderator will be asking you after your demo/presentation, will be based around your project, for example, your choice of software, justification for your choice of methodology, your design method, validity of results, etc. It may also involve some general issues in the context of your project and your degree programme. This whole process should last no longer than one hour.

As part of the viva questions, supervisors and moderators will explicitly query you on whether ethical approval was obtained for any elements that involved human participation in some way. You should be aware of the requirements and procedures following a talk in the autumn semester and a reminder email before the spring semester.

The timetable for the vivas will be made available to you, usually by e-mail. Please check your e-mails regularly, particularly nearer the time in case there are last minute changes to the schedule. Five minutes before the time of your viva, you should make yourself ready and wait outside your supervisors's office. Your supervisor and moderator will then ask you to take them to the lab to see your demo. After the demo, you may stay in the lab or go to your supervisor's office for the questions and discuss your project. If your demo is in the form of presentation or uses a laptop, then your supervisor may ask you to do it in his or her room. You can also agree with your supervisor and moderator to meet you in the lab directly, but make sure both of them know about this. Ensure that you are not late for your viva. Missing the viva means that you will fail your project module, unless you have a valid reason for missing it (see extenuating circumstances). If you have any questions regarding the viva and its arrangements for your specific project or there are any special requirements, please discuss this with your supervisor well before the viva date.

IMPORTANT: Make sure that your project is demonstrable on the day. It would be a good idea that you should try it out the night before and then perhaps “minutes” before your viva. This is particularly important for those who have used their own computers/software to develop their projects - the sofware may not work on the School's computers! It is your responsibility to make sure that your project is demonstrable. You can bring in your own equipment for the demonstration, but it is your responsibility to arrange this.

All project demonstrations will be conducted in C/2.05, the PC Lab, which will be set up with Linux, Mac and Windows computers. The lab is reserved for project demonstration only in the viva weeks. To set up your demo, please use other labs - they are all networked and operate in the same way. If you have developed your project using your own computer and you wish to demo your project using your own computer, then you may bring your computer in on the day and place it in C/2.05 for your demo. Note that you may need to register your computer on School's network, so please check with our system administrators. For any more specific requirements for the demo, e.g. specialised hardware, please discuss with your supervisor and our system administrators to find a suitable way to execute the demo.

Contact the project coordinator if you have any queries regarding your viva.

Guides

Gathering Material

This section outlines the kinds of material you need to collect before you can begin writing in earnest. Most of the necessary material will consist of your own ideas and experiences gained while carrying out the project, and your approach to solving the problem you have decided to address. For the background study or literature review you will also need references to various resources such as key books and papers, policy documents, Internet resources, related software, etc.

While working on the project you may find it helpful to keep a notebook handy and record all relevant information. Typically such information will include:

  • references such as papers, books, websites with full bibliography details;
  • lessons learned, for inclusion in the “reflective” part of your report;
  • notes from meetings or interviews with
    • your supervisor,
    • potential end-users and other stakeholders,
    • technical experts;
  • and so on.

Also, we recommend that you keep a diary of all your project-related activities. This will show the progress made during the life of the project and will provide a record of how you spent your time. In particular, when you are validating, testing and debugging your work, keep a running log of your activities and their outcomes. You will then have a record of the unforeseen difficulties you met and, hopefully, how you resolved them. Summaries of these may well be worth including in the project report (see Implementation).

In general you should supplement the material you generate yourself with relevant material from other sources. A good project report will show that you are aware of relevant work that other people have done (see Background). You should include relevant references to such work in your project report. References to work in periodicals, i.e. magazines and journals, and conference proceedings may be more useful than references to textbooks, as periodicals and conferences are usually more specialised and up to date. References to technical manuals and national and international standards should also be included, where appropriate. You may also cite web sites as sources, if suitable. However, keep in mind that web sites may often contain incomplete or wrong information and in general textbooks or papers are a better reference and show that you have done a more extensive literature review than just searching for some keywords on the Internet.

Arranging Material and Structuring the Project Report

You should consider, at the beginning of your project, what you need to do to solve the problem you have chosen to address. This will then inform choices about the structure of your reports; your written reports need to be both a “narrative” (telling the story of your project) and an “argument” (providing a logical justification of the steps you have undertaken to solve your chosen problem). Once you have started to gather material you can begin to arrange it in a form which can then be refined into a report, though the outline chapter headings shown below will serve as a good guide in the early stages of your work.

All good project reports whatever their subject, follow certain well-established conventions and have a similar overall shape. They generally consist of a main body surrounded by other information (presented in appropriate formats) that support it in various ways. Some of these are mandatory, others are optional.

Suggestions of the particular structure for the final and interim reports are given in the Interim Report and Final Report topics on this wiki. You should vary the titles of the sections if these are inappropriate for your project - your supervisor is the best person to guide you on this. Here we concentrate on the main body of the report and generic sections for both reports. The supporting information is discussed later. We recommend that you do the same when writing your report, though you should have a plan for your report which will guide you on what material your should be retaining for eventual inclusion.

We look at each of the general sections of the report structure 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"

A good introduction should tell the reader what the project is about without assuming special knowledge and without introducing any specific material that might obscure the overview. It should anticipate and combine main points described in more detail in the rest of the project report. Also, importantly, it should enthuse the reader about the project, to encourage them to read the whole report. Normally it should include such things as:

  • the aim(s) or goal(s) of the project,
  • the intended audience or “beneficiaries” of the work done,
  • the scope of the project,
  • the approach used in carrying out the project,
  • assumptions on which the work is based and
  • a broad summary of important outcomes.

The "Background"

The purpose of the Background section is to provide the typical reader with information that they cannot be expected to know, but which they will need to know in order to fully understand and appreciate the rest of the report. It should explain why the project is addressing the problem described in the report, indicate an awareness of other work relevant to this problem and show clearly that the problem has not been solved by anyone else. This section may describe such things as:

  • the wider context of the project,
  • the problem that has been identified,
  • likely stakeholders within the problem area,
  • any theory associated with 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,
  • methods and tools that your solution may be based on or use to solve the problem,
  • and so on.

The wider context of the project includes such things as its non-computing aspects. So, for example, if you are producing software or any other products, including business recommendations, for a specific organisation then you should describe aspects of that organisation’s business that are relevant to the project. If you are doing a research oriented, say on particular algorithms, you should also refer to the general problem for which these algorithms are useful (the application(s) for your techniques).

Relevant existing products, documents or artefacts that you should mention could be ones that, for example,

  • are similar to the one you are proposing,
  • support your project,
  • your project aims to extend or replace,
  • demonstrate the “deficiencies” your project intends to address.

You need only describe things that will be unfamiliar to the potential reader, or are unique to the organisation or topic your project addresses. Your project, if it involves software development, will almost certainly use all kinds of existing software such as language compilers, subroutine libraries, etc., but you can assume that the reader will be fully acquainted with, for example, general purpose programming languages such as Java, C/C++, Fortran, Pascal, Python, PHP, etc,. Also, it may involve the better known specialised packages such as MySQL, ORACLE, OpenGL, etc. You should mention the particular variety and possibly version number, e.g. Java SE 6, but you need say nothing more than that.

If your project depends on any specialist or uncommon software such as specialised subroutine packages or a more obscure or specialised programming language, you should describe them briefly and discuss whatever features are relevant to your project. Often this can be done by comparing it to some well-established piece of software, for example

The Descartes language is like a restricted version of Pascal but with
the following extra features: ...

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

Other background information could consist of the sequence of events leading up to the present situation or the results of earlier investigations. You could also discuss such things as any cost or time constraints imposed on the project.

Your background section should end with a clear statement of the research questions problem your project is trying to answer. These will reflect the aim of your project, but will be different in that they explain the problem you are attempting to solve, e.g.,

Example 1:

Aim: 
The aim of this project is to develop software for the improved planning
of the routing of delivery vehicles to customer locations, that reflects
the forecast availability of each customer to receive goods.

Research question(s):
In order to demonstrate the achievement of the stated aim, this project 
will identify route planning software currently in use and the
underpinning algorithms, define appropriate performance metrics,
determine how to express constraints on an alternative algorithm, 
develop an improved algorithm and demonstrate on what basis it is judged
an improvement, and implement the improved algorithm in a usable and
robust software package.

Example 2:

Aim:
The aim of this project is to develop a business strategy for organisation
X that will improve the survivability of X in the face of increasing
global competition.

Research question(s):
In order to develop a business strategy it will be necessary to identify
key stakeholders and determine their vision for the organisation at the
end of the strategic planning time frame, assess the likely outcome, in
terms of the organisation's survivability, of maintaining the current
strategy, and develop and assess an alternative set of activities to
achieve the stated vision.

The "Specification & Design"

The purpose of the Specification and Design sections is to give the reader a clear picture of the system you plan to create, in terms of the capability required. A specification should tell the reader what the software system is required to do. The design then gives the top-level details of how the software system meets the requirement. It will also identify constraints on the software solution, that are important in guiding decision making throughout the development process.

Describing what a software system does (specification) and how it does so (design) effectively usually means describing it from more than one viewpoint. Each viewpoint will convey some information about the system that other viewpoints omit. (You would use the same technique when describing any complicated construction such as a building, an aircraft, a novel or a painting). Possible viewpoints might be:

  • the business model the software supports,
  • the user interface,
  • the dynamic behaviour of the system,
  • how data flows through 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.

A common approach is to first define the user or business requirements, then describe the static architecture, identify modules and groups of closely connected modules, and then to apply other views to each of these groups. 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 and to aspects of it discussed in the Background section.

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.

If you are not designing a system, but testing a hypothesis for a more scientifically oriented project, specification and design sections may not be required in quite the same form. The specification instead becomes a description of the problem and what is required of a solution. The design becomes a description of your approach to solving the problem and your suggested solution(s). For instance, if you are designing an algorithm to solve a particular problem you would have a problem statement section and then a section describing one or more suggested algorithms to solve the problem. Later in the Results and Evaluation section you then describe how to design experiments to test how well the algorithm(s) solve the problem and present your experimental results with an evaluation of your suggested solutions.

The "Implementation"

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

Do not attempt to describe all the code in the system, and do not include large pieces of code in this section. Complete source code should be provided separately. 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 an algorithm, data structure, etc.

You should also mention any unforeseen problems you encountered when implementing the system 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.

The "Results and Evaluation"

In this section you should describe to what extent you achieved your goals.

You should describe how you demonstrated that the system works as intended (or not, as the case may be). Include comprehensible summaries of the results of all critical tests that were carried out. You might not have had the time to carry out any full rigorous tests - you may not even got as far as producing a testable system. However, you should try to indicate how confident you are about whatever you have produced, and also suggest what tests would be required to gain further confidence.

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. It may also contain a discussion of how you are designing your experiments to verify the hypothesis of a more scientifically oriented project. E.g., describe how you compare the performance of your algorithm to other algorithms to indicate better performance and why this is a sound approach. Then summarise the results of the tests or experiments.

You must also critically evaluate your results in the light of these tests, describing its strengths and weaknesses. Ideas for improving it can be carried over into the Future Work section. Remember: no project is perfect, and even a project that has failed to deliver what was intended can achieve a good pass mark, if it is clear that you have learned from the mistakes and difficulties.

This section also gives you an opportunity to present a critical appraisal of the project as a whole. This could include, for example, whether the methodology you have chosen and the programming language used were appropriate.

The "Future Work"

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 your unrealised ideas. It is a way of recording that 'I have thought about this', and it is also a way of stating what you would like to have done if only you had not run out of time (Remember to take into account Hofstadter’s Law: 'Everything takes longer than you think, even when you take into account Hofstadter's Law.'). A good Future Work section should provide a starting point for someone else to continue the work which you have begun.

The "Conclusions"

The Conclusions section should be a summary of the aims of project and a restatement of its main results, i.e. what has been learnt and what it has achieved. 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.

The "Reflection"

We believe in the concept of “lifelong learning”. 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. Reflection should focus on what Argyris calls “double loop learning”; this is where we identify, not relatively “simple skills”, such as the mastery of a new programming language, but the impact of what we have done on the assumptions, concepts and ideas we used to make decisions about our work. 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.

The "References"

We said that you should relate your work to that of other people. Other work explicitly cited should be listed in the Reference section and referred to in the text using some kind of key. 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.

It may be desirable to provide a Bibliography section separately from the reference section. In general, references are those documents/sources cited within the text. The bibliography lists documents which have informed the text or are otherwise relevant but have not been explicitly cited.

References should be listed in alphabetical order of author's surname(s), and should give sufficient and accurate publication details. For example,

Chikofsky, EJ, Cross, JH. 1990. Reverse Engineering and Design
Recovery: A Taxonomy. IEEE Software, 7(1):13-17.

Date, CJ. 2000. An Introduction to Database Systems, 7th Edition.
Addison-Wesley.

are acceptable references.

There are various conventions for quoting references. For example, you can quote the name of the author and the year of publication, e.g.

For more information see [Chikofsky et al, 1990]. A more detailed
description is given by Date [2000]. 

There are several other variations. For example, some authors prefer to use only the first three or four letters of the name, e.g. [Chi1990] or just to number the references sequentially, e.g. [3]. It can be helpful to the reader if, for books and other long publications, you specify the page number too, e.g. [Date 2000, p. 23].

Whatever convention you choose, be consistent.

Information Services provide a number of leaflets which describe in detail accepted ways of presenting references. For example, guidance on the Harvard Style of citing and referencing may be viewed at http://www.cardiff.ac.uk/insrv/resources/guides/inf057.pdf.

Whatever style of referencing you adopt, it is critical that you are assiduous in acknowledging the sources you have used; failure to do so may lead to suspicions of unfair practice and an investigation into whether or not your work reflects the standards expected of academic research. 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:

  • If the material you are citing from another source supports your position, you must explain why it should be trusted. For example, material from a published journal will, normally, have been peer-reviewed and can therefore be considered to have some validity, according to subject matter experts. Much of what is published on the Internet cannot be regarded in the same way, however.
  • You will often find that there are conflicting views in the published material; in such cases you must explain which view you favour and why, before relying on the material to support your position.
  • If other writers have taken a different position to the one you support, you must explain why the reader should accept your ideas rather than those proposed elsewhere.

In summary, you need to ensure that you have clearly assessed the relevance of referenced material to the development of your position, or your argument, and demonstrated that you are justified in taking this material to be authoritative.

Writing the Project Report

Once you have gathered and organised enough material you can turn it into written prose. To write effectively requires sustained concentration over long periods of time. Even with the incremental authoring possibilities that word processing offers, writing is best done in long uninterrupted sessions. Most people find it difficult and tiring.

There are rules you can follow which may make the task easier and which will certainly improve the quality of your writing, but unfortunately there are rather a lot of these and in a guide of this size we can only offer a few pieces of general advice:

  • keep your potential readership in mind;
  • identify commonality;
  • use sections and subsections to structure your work and to provide appropriate breaks for the reader;
  • do not include “padding” - include only what is necessary to “tell the story” and justify your work;
  • follow appropriate academic and professional stylistic conventions. We recommend that you read journal papers relevant to the general area of your project, as well as project reports held in the library and online; this is a normal research activity.

The project report's structure does not necessarily dictate the order in which you write it. If you want you can start by writing the Introduction, then the Background section, and so on, but this is up to you. Some people start by writing the Introduction first which gives direction to writing the other sections, but others prefer to leave writing the Introduction until last, as reports rarely turn out as planned. We recommend that you start with the middle sections, then write the Introduction (guiding the reader to what they will find in the report), then the Conclusions (bringing the report together at the end) and Reflection, and finally the Abstract (summing up the entire report). However you tackle the writing up, we recommend that you:

  • write as you go along, rather than leaving all the writing until last (writing takes longer than you think, and is best done when the ideas remain fresh in your mind);
  • leave time for someone you trust to proof-read your work, and for you to correct errors (it is not your supervisor’s responsibility to correct your written English);
  • read your work out loud to yourself. There are many advantages to this, not least the realisation that if you run out of breath your sentences are probably too long. Mainly, however, if you read “silently”, you will tend to read what you meant to write, rather than what you have in fact written, and will run the risk of missing errors.

Potential Readership

Always keep your potential readers in mind and repeatedly review what you have written, putting yourself in their place. Look at the draft, sentence by sentence, and ask yourself: 'Will this make sense to the readers given their existing knowledge and what I have told them up to now?' You can consider the potential readership as

  • your academic supervisor,
  • your project moderator/internal examiner,
  • the external examiner (usually a computing professor from another university),
  • and quite possibly future students and others interested in the topic.

So, as noted earlier, do not explain things which are common knowledge to such readers.

Also, if your project report is of sufficient quality, your supervisor may consider submitting part of it to a journal for publication as a paper, in which case it may eventually be read by a substantial number of computing and other professionals.

Identifying Commonality

You can often both clarify text and reduce its bulk if you can identify generality or commonality among the ideas you are expressing. You can then revise the text so that the common factors are described first, followed by details of how specific individual ideas differ from them.

Sections and Subsections

The main body of the project report should be divided up into sections, along the lines suggested in Arranging Material and Structuring the Project Report or otherwise, as appropriate. Each section should, if necessary, be divided up into subsections, and so on recursively. Such nesting can be used to suggest some kind of hierarchical relationship between sections. 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.

Stylistic Conventions

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;
  • generally, you should write in the “third person”. The “first person” can be used, to avoid the report becoming stilted, though it is recommended that its use be limited; for example, it may be appropriate to use “I” when stating an opinion rather than the common “It is the author’s opinion…”.

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.

Using Descriptive Devices

Here we mention some well-established descriptive devices which you can use in your project report to improve its quality.

Cross-references

Cross-references are just references to other parts of the same document. For example,

This module contains procedures for operating on variables of type WINDOW (see Section 2.2).

Section numbers will change if sections are added or deleted. Good typesetting or word processing software provides suitable mechanisms to automatically number sections and create such references such that they will always refer to the intended section. Make sure you know how your chosen software does this and select the right software to make this simple. If you use software that does not support cross-references or uses an overly complicated system, it is a good idea to wait until the report is almost complete before putting in any cross-references.

Backward references to sections earlier in the project report can make explicit connections between parts of the document that may not be connected obviously. Forward references can be used, for example, to reassure the reader that you are not going to leave them stranded after you have introduced a new idea without explaining it. For example,

This procedure uses the Volestrangler algorithm (to be described in Section 4.3).

Note that too many forward references are probably an indication that the report could be organised better.

Footnotes

Many word processors have facilities for handling footnotes. By all means use them, in particular when you want to make a comment which is not strictly relevant or which would upset the flow of ideas in the text. If the comment is closely related to the text you may consider including it in parenthesis instead.

Lists

Traditionally, collections of items are listed within the text using the adverbs ‘firstly’, ‘secondly’, etc. Often, though, it is clearer to tabulate these items, particularly if there are many of them. The simplest way of doing this is to use a “bullet” list. Various examples of bullet lists appear on this wiki. Sometimes there is a need to nest one list inside another. To distinguish the two lists, the inner one can be indented and have a different symbol. Lists with more than one degree of nesting tend to appear confusing and therefore we do not generally recommend them.

Listed items can also be keyed using numbers, letters, or other labels. Bibliography entries are an example of keyed items (see References). However, keys should only be used when necessary.

Figures

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 (If you have a graphical rather than a textual/verbal kind of mentality, a good way to write text is to express your ideas in diagrams first and then describe these textually).

Be careful though. 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. Computer Science, unlike most other professions, has few established conventions governing the use of diagrams and this means that diagrams can sometimes make ideas more obscure rather than clarifying them.

If you feel you have to invent your own notation, remember that the best ones are usually the most economical, i.e. they use only a few different kinds of symbols. Also, you must explain the precise meaning of your symbols in a key. A very common mistake is to use arrows to illustrate some kind of relationship between items without declaring what that relationship is.

Graphics editors (i.e. image processors) can be extremely useful, particularly if you have a great deal of drawing to do or if there is a lot if commonality among the drawings (because cut and paste operations can then be used with great effect). However, some artefacts are difficult to produce using standard software applications, and in such cases it is quite acceptable to present hand-drawn diagrams. To include these into your report you may use a scanner or even take a photograph (or multiple partial photographs that you merge afterwards) of the artefact and include it in your report as any other computer generated image (help from staff for this is available and you may bring the original artefact to the viva).

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.

Similar to sections and subsections the labels may change if you insert additional figures or change the structure of the report. Again good typesetting software will support automatic label generation and keeping the references to the figures consistent (see Cross-references).

For some reports it may also be useful to distinguish between figures and tables and use separate labels for them (e.g. Figure 3.1 and Table 3.1 are two separate elements, sometimes also referred to as floats). Figures are diagrams, drawings, images, etc. while tables list information in a tabular layout, e.g. program running times for specific inputs.

Literal Text

It is important when writing about software systems to distinguish in the text between the ordinary natural language you are using and the program code or other literal text. If you are using a word processor which offers both proportionally spaced and fixed width character fonts then there is a straightforward way of doing this. Program code and other literal text can be written in a fixed width font such as “Courier New” while the natural language text can be written with a proportionally spaced font such as “Times New Roman”.

Other similar kinds of text, UNIX commands for example, can be treated in the same way. Some typesetting systems also offer to include “verbatim” text, which you can use to insert small code examples, examples of the output of a program, etc. They are also typeset in a fixed width font. Using a fixed width font means that the code appears in the document much as it would do on a console. If you only have fixed width characters available on your word processor then put program code etc. into italics or bold text.

Note that using more than a few different character fonts, styles or sizes can make text look very untidy. Generally we recommend to use, e.g., a serif font for the main text (or a sans-serif font, if you prefer), a fixed-width font for literal texts as above, and optionally one sans-serif font for headings and captions (this can also be the same font used for the main text). Emphasis can be indicated by italics (or slanted text) or for stronger emphasis use bold text. If you use more fonts you should have a very good reason for this to support the content.

Supporting Material

In Arranging Material and Structuring the Project Report we say that a project report consists of a main body plus other supporting material that surround and support the body. There are well established conventions governing the purpose and format of these supporting structures which we describe here. The structures include, in order of appearance in the project report:

  • the title page,
  • the abstract,
  • the acknowledgements,
  • a table of contents,
  • a table of figures.

Then comes the main body of the report, and this is followed possibly by:

  • a glossary,
  • a list of abbreviations,
  • one or more appendices,

and finally

  • the references and bibliography.

Each of the elements listed above should begin on a new page. All pages should be numbered, with page 1 being the first page of the Introduction. The pages preceding the Introduction should be given Roman numerals (i, ii, iii, iv, etc).

The Title Page

The title page should be the first page of the report and should normally include:

  • the title of the project report,
  • the name of the author,
  • the name of the project supervisor and moderator,
  • the qualification for which the project report is a part,
  • the name of the school and institution, e.g. School of Computer Science and Informatics, Cardiff University,
  • the date of completion of the project report.

The title itself should be short, yet should aim to describe the contents of the project report as accurately as possible.

The Abstract

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).

Acknowledgements

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.

The Table of Contents and Table of Figures

The table of contents gives the reader a view of the detailed structure of the report, by giving section and subsection headings and associated pages.

If your project report contains many figures or it refers to the same figure many times you should consider listing them along with their page numbers in a table of figures.

The Glossary and Table of Abbreviations

If you use any abbreviations, obscure terms or esoteric acronyms in the project report then their meaning should be explained where they first occur. If you go on to use any of them extensively then it is helpful to list them all in a table at the end so that readers can quickly remind themselves of their meaning.

The Appendices

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 could be extensive technical details or mathematical proofs, derivations of formulae, etc. required to support a point your are making in the report. Other documents you have written, such as user manuals, technical manuals or formal specifications should go here too.

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

Our Main Recommendations

Here is a summary of our main recommendations for writing reports:

  • Record all relevant information generated by the project:
    • use a notebook,
    • keep a diary,
    • log debugging sessions.
  • Gather further material from publications or other external resources.
  • Organise the material into sections agreed with your supervisor,
    • e.g. “Background”, and so on.
  • Turn this material into written prose to form the project report's main body.
  • When writing the main body
    • keep your readership in mind;
    • identify commonality;
    • use sections and subsections;
    • follow stylistic conventions.
  • Where appropriate use
    • cross-references,
    • references,
    • figures and other descriptive devices.
  • Produce all required supporting structures according to convention, after completing the main body, and include this material in appendices to avoid disrupting the flow of your narrative.
  • For examples to follow, look at textbooks from reputable publishers, etc.
  • Discuss an outline of the project report with your supervisor before you begin to write up; this will help you to plan your project. However, we strongly recommend that you write up your work as much as possible as you carry out your project, rather than leaving the writing to last.

Typesetting Rules for Report Presentation

This is a list of general typesetting rules for the undergraduate final year project reports.

Length

Ensure you stick to the word limit assigned for the specific report, as stated in the module guidelines. The word count does not include the supporting structures, but only the contents of the main report sections, excluding front-matter, figures and tables, and appendices. There is no minimum length but it is mainly through the report that your project will be judged so the report should adequately reflect the work done in the project.

Font Size

Reports should be typeset in a 12pt font.

Line Spacing

Reports should have single line spacing. The report should be economical on paper. It should not, for example, contain excessive amounts of whitespace. Only the major sections need to begin on a new page.

Submission

Reports should be typeset with some word-processing system, e.g. LaTeX, LibreOffice or Word. The final project report should be presented as a PDF file with any other documentation in the appendices of the report. Artefacts produced for the project that are to be processed by other software such as a compiler or interpreter should be submitted as separate file(s). If files are submitted as an archive, it should be in zip format (other formats can be uploaded, but will be converted automatically into zip by PATS). Typically this will be the source code for software developed for the project. For details see the Submission Guide.

Sources of Further Guidance

The guides on this wiki are not complete. Textbooks usually demonstrate good technical writing especially if they are produced by a reputable publisher. They also provide illustrations of the use of descriptive devices, etc.

Below is a list of other books and Internet resources, specifically designed to assist in writing essays and reports.

Finally, there will be specific aspects of your project reports that only your supervisor can advise you on. It is important that you discuss an outline of the reports with your supervisor before you begin to write up.

Bibliography

Bly, R. 10 Ways To Improve Your Technical Writing, Center for Technical Communication. http://smartbiz.com/sbs/arts/bly10.htm [accessed January 2011].

Capital Community College Foundation. Guide to Grammar & Writing. http://grammar.ccc.commnet.edu/grammar/ [accessed January 2011].

Creme, P, Lea, MR. 2008. Writing at University: A Guide for Students. 3rd edition. Open Unniversity Press. Contains help for all aspects of writing while at university.

Document Foundation, The. LibreOffice Documentation. http://www.libreoffice.org/get-help/documentation/ [accessed January 2011].

Duprė, L. 1998. Bugs in Writing: Guide to Debugging your Prose. 2nd edition. Addison-Welsey. Contains tips in small, individual chapters to improve your writing; a good reference book.

Fry, R. 2004. Improve Your Writing. 5th edition. Delmar Cengage Learning. This is a guide for students producing a written project. Easy to read, full of handy hints, and guides you through the whole process from carrying out research for your report through to producing the final draft.

Landsberger, J. Study Guides and Strategies. http://www.studygs.net/ [accessed January 2011].

LaTeX Project Team. LaTeX - A document preparation system. http://www.latex-project.org/ [accessed January 2011].

Oracle. The OpenOffice.org Documentation Project. http://documentation.openoffice.org/ [accessed January 2011].

Strunk Jr, W, White, EB. 1918. The Elements of Style. WP Humphrey, Ithaca, NY. http://www.crockford.com/wrrrld/style.html [accessed January 2011]. Excellent guide to good use of English, a classic reference book, meanwhile updated and republished many times.

Word MVPs. The Word MVP Site. http://word.mvps.org/ [accessed January 2011].

PDF Generation Guide

This section describes how to prepare PDF files for your final year project. Independent of the program you are using to write the document and create the PDF file, the PDF file must fulfil the following conditions:

  • It must be compatible with Acrobat 5, PDF version 1.4.
  • All of the typefaces used in your document must be embedded in the PDF file, except for the standard PDF fonts. Embedding the standard PDF fonts is optional. The 14 standard PDF fonts are Times–Roman, Times–Bold, Times–Italic, Times–oldItalic, Helvetica, Helvetica–Bold, Helvetica–Oblique, Helvetica–BoldOblique, Courier, Courier–Bold, Courier–Oblique, Courier–BoldOblique, Symbol, ZapfDingbats.
  • The PDF file must not contain any malicious software. In general there is no need to embed any scripts at all.

We also recommend that you turn off any additional image compression during the PDF generation to preserve the original image quality. Furthermore, the PDF file should be generated for 300dpi or higher (print or prepress settings are ok). Screen resolutions, etc. may be of insufficient quality to easily read or print your documents.

The method you choose to create your PDF file is up to you, of course. However, there are several methods that most people use as described below. Following these methods will ensure your document fulfils the above conditions.

Once you created the PDF file you are highly advised to carefully proofread the resulting PDF file using acroread, available at http://get.adobe.com/reader/ (also installed on all COMSC computers). In particular check that the PDF file does not differ from the original file in any significant way.

TeX and LaTeX

If you are using TeX or LaTeX there are two basic options to create a PDF file: directly generate the PDF file with PDFTeX / PDFLaTeX or create the PDF file from a DVI file. For special TeX frontends and implementations for various platforms, commercial version, etc. you should refer to the documentation of these programs.

PDFTeX and PDFLaTeX

We recommend to use PDFTeX / PDFLaTeX directly by calling pdflatex or pdftex command to create a PDF file. Note that there are some small differences between these commands and the original latex or tex commands, which produce DVI files. To avoid any problems you should choose which version you use before you write the complete document.

TeX and LaTeX with DVI files

The standard version of TeX and LaTeX produce DVI files. To generate acceptable PDF files from these, first convert the DVI file to PostScript with the following command:

dvips -Ppdf -G0 -t a4 -o FILE.ps FILE.dvi

Then you should run the ps2pdf program to create the PDF file from the PostScript file:

ps2pdf  -dPDFSETTINGS=/prepress \
        -dCompatibilityLevel=1.4 \
        -dAutoFilterColorImages=false \
        -dAutoFilterGrayImages=false \
        -dColorImageFilter=/FlateEncode \
        -dGrayImageFilter=/FlateEncode \
        -dMonoImageFilter=/FlateEncode \
        -dDownsampleColorImages=false \
        -dDownsampleGrayImages=false \
         FILE.ps FILE.pdf

Microsoft Word

There are various ways to generate a PDF file under Microsoft Word. The following three sections describe the most common options.

Save as PDF

Newer Word programs offer under the save menu point the option to save the file as a PDF file. You may have to install a separate option in order for this to work. In general this may be best best option to generate a PDF. Make sure you turn off image compression and select at least 300dpi resolution.

PrimoPDF

PrimoPDF is a free program available at http://www.primopdf.com/. It installs a PDF printer which can be used to generate the PDF file as well. For details on how to use it see its documentation.

LibreOffice / OpenOffice

If you are using OpenOffice to write your report export the file in PDF format using the File → Export As PDF … menu. Under the options window provided you do not need to select any of the special options. But make sure you turn off JPEG compression by selecting lossless compression to avoid image quality problems and we also do not recommend reducing the image resolution.

cm3301_guide.txt · Last modified: 2018/05/15 14:09 by scmfcl