OU blog

Personal Blogs

Christopher Douce

TM470 What should I submit?

Visible to anyone in the world

A question that I’m regularly asked is: “what do I need to submit?”

The answer is pretty simple: you only need to submit a Word single document. Some obvious follow questions are, of course: “what should my Word document contain?” and “I’ve written some software as a part of my project, should I include this? If so, how?” or “During my project, I’ve done a lot of design work, and I have a load of sketches and some prototypes – how can I submit these?”.

A principle to return to this: TM470 is all about showing off. You can ‘show off’ in a couple of different ways. One of the most important sections of your EMA is the section of your report that summarises the account of the work that you have carried out on your project. In this section, you should make sure that you highlight the best bits of work that you have done. This might include a design, a diagram, or bits of code for important functions that may have been particularly develop. If you have a lot of code, or many different screenshots or sketches, choose the best ones, and put all the others within a series of appendices. An important point to remember is: you can include any number of appendices in your EMA report.

A related question that I’m sometimes asked is: “should I include a weblink to some working software, or an app that can be downloaded?” The answer is: no; you don’t have to do this. Whilst your examiner (the reader of your EMA) may appreciate this, there isn’t an obligation to provide links to a working version of any software you have created. Your project report must, however, be sufficiently detailed to ensure they can evaluate the learning that has taken place over the duration of your project.

If your project relates to a particular setting or context, a further practical suggestion is to provide some photographs of that setting. If you are developing an app that solves a problem, you might want to include a photograph of the setting where your app is used. Give your photograph a figure number, and refer to it in the body of your text.

To summarise, you only need to submit a written report, your EMA. You don’t need to need to provide a working prototype, but you do need to provide sufficient detail to ensure that the examiner is convinced about what you have done. If you haven’t got things working at you had hoped, it is okay to say this too; this makes for an interesting report. It isn’t what you have built that is the focus, it is what you have learnt (and demonstrated) through the building of something, and how you write about it that really matters.

Permalink Add your comment
Share post
Christopher Douce

Sharing source code in a TM470 project report

Visible to anyone in the world
Edited by Christopher Douce, Saturday, 15 July 2023, 11:38

TM470 projects can take many different forms. 

Some might be design projects, some might be research projects, and some might be development projects. One of the most important points that all students should bear in mind is that there is a need to share evidence of project activity and learning that takes place.

Evidence is shared only through the project report. If your project is all about software development, you are not required to upload software to a GitHub repository, or to provide examiners with a working version of anything you may have designed. You should, however, provide evidence of software development having been carried out, and must provide evidence of critical thinking you have applied. In other words, you should write a technical story that describes how your software was created. Although every project is different, your report should share the story of requirements discovery or specification, design, development, evaluation, and testing. The number of times you carry out an evaluation cycle is, of course, completely up to you.

I am sometimes asked a question, which is: how should I share code through my EMA report?

A case study approach

You don’t need to share all your code. 

You should share your code in two ways: in the body of the report, and in an appendix.

For the body of your report, choose bits of code that best demonstrates your technical skills and help to demonstrate a technical story of what you have done, and how you have done it. You should also show how you have drawn upon modules you have previously studied.

Think about the body of your report as a showcase, where you share a series of mini case studies which demonstrate your skills, abilities, and learning. Providing snippets of code in the body of your report that highlight show the important and difficult problems that you have had to resolve during the course of your project. In the body, you can then provide a pointer to one or more appendices, where you can provide more code, which the examiner can look at.

A simple rule of thumb is: provide snippets that show your work and your learning in the body of your report, and provide bigger sections of code as a section in an appendix.

Some projects might require the development of an algorithm, so showcasing its development will be a really important part of the technical story of your project. In this example, you might want to refer to M269 Algorithms, data structures and computability, or another module.

If your project has user interfaces that is coded up in a language, such as HTML, you might want to include fragments of these, and refer to modules such as TM352 Web, mobile and cloud technologies and TM356 Interaction design and the user experience.

You should also refer to texts, such as set texts, module materials, or any other resources that you have mentioned in your literature review section.


In the body of your report, a practical approach is to share small sections of your code using tables. By using this approach, you can refer to your code using a table number, when you discuss how you created your software.

A suggestion is to present your code a font, such as Courier New, to clearly distinguish between what is code, and what is discussion. To make sure you don’t use too many pages in your project report, it is okay to make your code a bit smaller. From my tutor perspective, 8 point Courier New is a good choice. 

A fellow tutor shared a particular opinion about code presentation that has stuck with me, which was: try to avoid presenting code on a black background. The reason for this is pretty simple: if bits of your report are printed (which I don't think is likely to happen), it would use black ink or toner than is necessary. Another argument is that it might make the code harder to read on some devices.

For bigger chunks of code, you should use one or more appendices. A practical suggestion is to use one appendix for the code, dividing it up into subsections if you need to, since this way everything is in one place. You might want to use an appendix to share an entire file, or perhaps show how all your earlier code fragments look when they are combined together. You should use a font like Courier New to present your code, but you don’t need to present your code in a table, since you can refer to it with an appendix or a reference number.

Pro-tips: cross referencing and Word headings

The bigger a Word document becomes, the harder it becomes to maintain, especially if you’re starting to add in a lot of sections. To make things easier, I have the following recommendations:

  • Make use of the Word in built headings; this enables you to easily create a table of contents using a feature of Word. Also, get Word to number each section for you, since this way you don’t have to renumber everything is you need to add a new section.
  • Use the Word document navigator view to get an overview of your document.
  • Have up to 3 levels of headings, i.e. 1.2.2; too many levels will make things confusing.
  • If you add tables and figures, get Word to number them for you.
  • If you refer to a table or a figure, do so using the Word cross reference feature, since that way if you add more tables, you won’t need to mess with editing table numbers.

The final point is: if all this is a bit much, do what you need to do to get your report written. Sometimes it is best to decide to get things done. TM470 is all about OU study and running a project, rather than making a perfect Word document.

Edited 15/7/23, adding a further bit guidance about the formatting of code.

Permalink Add your comment
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 2141450