Personal Blogs

One way to think about the term ‘criticality’ is to understand that it can mean ‘to demonstrate that you’re thinking things through’. In your project module report, there are many different ways you can show your critical thinking. Here are some of the ways that came to mind:

Problem context. What is the problem? Why is the problem important? Who benefits from the problem being solved? How will you investigate the problem domain? Who are the stakeholders? What questions will you ask them? How will you capture their responses?

Literature review. Why are the resources, reports or articles you have found considered useful? Is the resource from a trustworthy source? Which modules you have studied are relevant to your project? How, and where will you be using the articles that you have found in the body of your report? Have you found any articles that present conflicting or opposing views? How will you structure your literature review? What subheadings will you use?

Resources. Why is a particular resource, or set of resources useful? When you get to the end of the project, were some resources more useful than others?

Skills. Towards the start of your project report, it is important to share a list of skills you expect you will need to draw on. Preparing this list will help you to identify what skills (and knowledge) you need to develop. When you get to the end of your project, what skills have been the most useful, and which skills have you developed the most.

Planning. When preparing your project plan, it is not good enough to say ‘agile’ or ‘waterfall’. You need to say why you have chosen a particular approach, and what advantages your chosen approach gives you. Sometimes an agile approach is selected since there is the misunderstanding that it avoids planning. You need to demonstrate planning irrespective of whatever project model you choose. When you get to the end of

Methodology. In the context of your project, the term methodology can be used to refer to what you will be doing to answer questions, and to solve your problem. Why are you doing what you are doing? If you use a survey, are the answers to the questions you ask actively going to help you to achieve what you wish to achieve? If you interview people to gather requirements, have you asked the right questions?

Requirements. Where did requirements come from? What did you do to collect them, and how did you go about collecting them? Can you provide evidence from data that is collected that suggest a particular requirement. Who have you spoken with to gather your requirements, and why have you chosen those people? What documents have you looked at (and, again, why have you chosen them and why are they important). An important question to ask is: are your requirements traceable? What are the most appropriate form of diagrams you could use to represent your requirements, or the problem context? Why have you chosen that approach? Has the literature you have identified been helpful? If so, are you able to provide a quotation and page reference?

Design. What approaches did you use, and why did you use them? Which tools are you using? Are these tools mentioned in your literature review? What is your architecture? Can you able to justify your design decisions in a way that the examiner can follow? What approaches have you used to describe your design? Have you used sketches, prototypes, or diagrams? Why have you chosen that particular approach? What evaluation have you done to your design? What articles or source have you used that have informed your design? Can you evidence this by quoting from them, and providing a reference that includes a page number?

Technology choices. What are the advantages of different tools and technologies? Is one set of technology choices likely to be better than another? If so, why is that the case? Also, what evidence do you have to show this is the case? Is the examiner able to see what you have done, and why you have done what you have done?

Testing. What testing approaches have you used, and why have you used them? What evidence is there of the testing you have done? To what degree do you feel that you have confidently uncovered any bugs or problems that exist within your product.

Evaluation. Testing and evaluation are linked, but they can be used to answer slightly different questions. Testing can answer the question of: does it work as I expect it to work? Evaluation can ask the question: does it solve the problem I set out to solve? If an evaluation is carried out, does you chosen approach help you to answer that question? Have you asked the right evaluation questions, and have you dealt with all the ethical questions that must be attended to? What about resources? Have you provided some? Do they work? Are they helpful for you, or for your participant?

Diversity, accessibility, legal, social, ethical and professional issues. In the project report, this group of concerns can, of course, be grouped under the label LSEPI. A really useful question to ask is: to what extent does the project, or product, potentially impact the society or community in which it is used?

Reflection. When reflecting on your project and what you have learnt, consider a set of ‘wh’ (and ‘h’) questions. For example: What have you learnt? What did you do? Why did you do what you did? Was your project model choice appropriate? Where there any surprises during your project? How would you have planned it differently? Where there any differences between your plan and what actually happened? What would you do differently? Also, are you able to support your points from comments that you have left in your project log?

Reflections

When I’m not a computing tutor, or working on module teams, I'm also an OU student. A few months ago, I was attending a tutorial where a tutor said something about essay writing that was really simple, which really resonated me. My tutor said ‘whoever is marking your EMA wants to see your thinking’. This principle applies as much to your Computing EMA as it does to an English literature essay.

There is another phrase that I have picked up from my studies that is useful; there is a creative writing adage, which goes ‘show, don’t tell’. Show the reader what is happening, rather than tell the readers what has been done. The same principle also applies to good Computing EMAs. Show the examiner what you have done (show them your code, and show them the problems you have solved), rather than just telling the examiner that you have done something. Examiners always look for evidence. Show what you have built, and show your thinking. I think the mathematicians have their own expression, which is (of course), ‘show your working’.

My final point is: reference everything. By showing your reading, you also show your understanding.

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:

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