Student Projects

  • Overview

    If you have any ideas for a project that fits within my interests, then please feel free to come and discuss it with me. If you are trying to find a topic then there are some areas to consider on the next tab.

    Please note: At the Undergraduate level I only supervise Type 4 projects as I’m a coder, not an information systems guy!

    I look to take on students who are intelligent (which you are by definition of being a Birkbeck student) and who have an interest in the project that they are about to undertake. Students should be self-motivated and be keen to explore their topic. You should not be afraid to express your ideas and follow them. However, you need to be balanced in your approach and practice scientific practices in evaluating your own work. If you have the basics, we can work together to put together a good solid project.

    I like to see students take control of their project and run with their ideas and thoughts. This means that students exercise a degree of independence - however, I don’t expect this to translate to going off into a dark corner and never consulting me. My role is to provide some guidance and advice. There is clearly a conflict between these two expectations and so what we need to do is work together to strike a suitable balance between self-direction/independence and guidance.

    Bottom line - it is your project and the supervisor only makes suggestions...

  • Possible topics

    The project topics listed here are not the only types of project I am prepared to supervise - they are merely an interesting list of current topics.

    • You are encouraged to discuss your ideas and maybe we can shape them into an honours or masters project.
    • Some of the projects, although at Masters level, might be able to be adapted for Undergraduate level by only focussing on part of the problem.
    • I've been asked repeatedly to distinguish between Artificial Intelligence, Machine Learning, and Deep Learning, and this article helps with the differences.
  • Proposal Structure (for PG students)

    The following is a general template for a masters project proposal under my supervision, and therefore, software based.

    • Title
    • Disclaimer (stating your own work etc. - usual plagiarism requirements)
    • Abstract
    • Acknowledgements (optional)
    • Contents
    • Chapter 1 - Introduction
      • State the problem you are trying to solve
      • Why is it worth tackling?
      • What approaches are available (briefly)?
      • What approach have you chosen?
      • Any special knowledge you presume of the reader to understand the proposal.
      • Any special typography or terminology (if too many use a glossary).
      • A "road map" of the proposal document ... "In Chapter Two we describe xxxx. In Chapter Three we describe yyyy..."
    • Chapter 2 - Background
      • Any information the reader requires in terms of techniques/technology that isn't part of the programme you have studied.
    • Chapter 3 - Analysis, Requirements, and Design
      • What it says on the title
      • Should include appropriate formal design diagrams/notation as necessary
      • Any language selection, libraries, frameworks, etc., and why you have selected them.
      • If you've written some code then discuss this briefly and how this will impact the final work.
    • Chapter 4 - Experimentation & Evaluation
      • Again, what it says on the tin!
      • Briefly describe how you are going to show that your work meets the original aims and objectives; this doesn't mean just testing the code!
    • Chapter 6 - Timescale
      • Provide a GANTT chart which shows the timeline for your work. Probably a topic, rather than week-by-week, view will be most useful to the examiners.

    Now, "one size does not fit all" - this structure is meant to be a starting point; you may have more, or less, chapters. Be flexible and check with me about what you are writing.

    I prefer to see the proposal a section at a time (or even just a few pages at the start). A whole proposal sent to me to read at the end, with no chapters submitted prior to that, is a recipe for problems. It really doesn't give me any time to say, "No, change the style", or "No, I suggest you do it this way".

  • Report Structure

    The following is a general template for a project report under my supervision (and software based). This is not necessarily the structure other members of staff would recommend but it works for me!

    First of all, don't bother with the abstract, introduction, and conclusions - they are the last things you write. Next, if you have a lot of code (being supervised by me probably means "yes") then put it on GitHub (or equivalent) as a private repository and include a link to that. Don't fill up appendices with lots of code listings - think of the trees.

    So, here is the outline:

    • Title
    • Disclaimer (stating your own work etc. - usual plagarism requirements)
    • Abstract
    • Acknowledgements (optional)
    • Contents
    • Chapter 1 - Introduction
      • State the problem you are trying to solve
      • Why is it worth tackling?
      • What approaches are available (briefly)?
      • What approach have you choosen?
      • Any special knowledge you presume of the reader
      • Any special typography or terms
      • A "road map" of the report..... "In Chapter Two we describe xxxx. In Chapter Three we describe yyyy..."
    • Chapter 2 - Background
      • Any information the reader requires in terms of techniques/technology that isn't part of the programme you have studied.
        Please note: if you are submitting an MSc project report then this should not contain the material from the proposal - one cannot get credit twice for the same piece of work.
    • Chapter 3 - Analysis, Requirements, and Design
      • What it says on the title
      • Should include appropriate formal design diagrams/notation as necessary
    • Chapter 4 - Implementation
      • Describe how the implementation maps onto the design you have already discussed.
      • You should use "code snippets" to illustrate special features of your work or difficult (awkward) bits of coding. Don't make any of these snippets longer than half a page (and include line numbers if possible). If the code fragment is longer than half a page then break it up into smaller bits.
      • Describe the code, both in terms of the overall architecture and in terms of the snippets. Make sure the reader understands what you have done and why!
    • Chapter 5 - Experimentation & Evaluation
      • Again, what it says on the tin!
      • If you haven't done too much testing (for instance it is GUI based) then include a "walk-through" of the application with screenshots showing the scenarios in which the application can be used. After all, the examiners may not be near a computer to actually "run" your code.
      • You also need to clearly show how you have evaluated your work and show how it meets the original aims and objectives.
    • Chapter 6 - Conclusions
      • Restate the problem.
      • Say how successful (or not) you have been in solving/tackling the problem.
      • What would you have done differently?
      • What have you learnt?
      • Basically, "reflect" on the work you have done.
      • What additional features/extensions can be done to the work and/or what would you have done if you had more time.
    • Appendices
      • Include design diagrams, data formats, etc.
      • Basically, don't overfill the report.
      • Link to the GitHub repository (if appropriate).

    Now, "one size does not fit all" - this structure is meant to be a starting point; you may have more, or less, chapters. You may need a background chapter, you might not, etc. Be flexible and check with me about what you are writing.

    I prefer to see the report a chapter at a time (or even just a few pages at the start). A whole report sent to me to read at the end, with no chapters submitted prior to that, is a recipe for problems. It really doesn't give me any time to say, "No, change the style", or "No, I suggest you do it this way".

  • College Policy on Supervision of Dissertations for Taught Students
Open all Close all

Sample student projects

The following are not to be distributed without prior agreement

  • An Aspect Oriented Framework in F# by Nitesh Chacowry
  • The Role of Depth in Neural Network’s Multimodal Word-Learning Assumption by Akira Charoensit
  • First steps in creative computational thinking with natural language programming and Lego Mindstorms by Geoff Falk
  • A Recommendation Engine by Amy Peters
  • AmazingStoke: A Facebook game for the Not-For-Profit sector by Joanna Pinto
  • MotionJS - A JavaScript Framework for large applicationsa by Michael Sauter

Information for Personal Tutees

  • College Personal Tutors Policy
Open all Close all