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.