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.
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.
Presentation
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.
Sharing source code in a TM470 project report
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.
Presentation
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:
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.