OU blog

Personal Blogs

Christopher Douce

Sharing source code in a TM470 project report

Visible to anyone in the world
Edited by Christopher Douce, Saturday, 15 Jul 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.

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.

Permalink Add your comment
Share post
Christopher Douce

Considering LSEPI

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 28 Jun 2023, 09:02

In TM470 LSEPI is an abbreviation for Legal Social Ethical and Professional Issues. A good TM470 project report should clearly address these issues to show the examiner that you have thought about how these issues have impacted on your project, and what you have done to take these into account.

LSEP issues are increasingly important in computing due to the increasing impact that computing and IT has within society. When speaking with students I often a recent example: the Volkswagen emissions scandal. In this case, there are clear environmental impacts and legal implications. It is also clear that both the engineers and leaders have to make ethical decisions.

In TM470, LSEP issues are assessed through the following learning outcome: “LO10. Identify and address the legal, social, ethical and professional issues (LSEPIs) and the equality, diversity and inclusion (EDI) concerns that may arise during the development and use of computing and IT systems.” In the marking of the EMA, this learning outcome is assessed with LO2, which is all about the aims and goals of your project.  When just looking at the number of learning outcomes, and the marks available, the LSEPI section could account for 10 marks.

To gain a top score for this learning outcome a student: “has comprehensively identified the relevant LSEPIs and EDI concerns arising during development and use and modified their project work to take these into account and behaved professionally in all aspects of their project work”. EDI being an abbreviation for equality, diversity and inclusion.

Given the importance of both LSEP and EDI, a suggestion is to include it as a top level section in your report, just before the literature review section. The justification for this is that if you identify some issues that need to be explored in greater depth, you can then go onto provide evidence of your reading.

Module materials

At the time of writing, it takes a bit of digging to find two documents that relate to both LSEP and EDI issues. From the module website, click on the Resources heading, and then click on the Study materials section.

The LSEP document contains the following key headings: working with stakeholders, working with human participants, and asking the right questions. Do review the materials that are presented under these headings and review Appendix A Guidelines for conducting research with human participants. Related to these are two template documents: a sample consent form, and a participant information sheet.

Informed consent is the process through which researchers share the aims and purpose of their research with participants, and gain their approval that they are happy to participate in a study. The accompanying information sheet is designed to offer further information under a set of familiar headings.

When working with participants, I always remember two points. The first is that participants are at liberty to leave a study at any point. The second point is related: the participants are always more important than the research that is being carried out.

The equality, diversity and inclusion section addresses “why equality, diversity and inclusion are relevant to computing and IT professionals”, introduces the concept of protected characteristics, and “unconscious bias is and how it might affect your practice as a computing and IT professional” and what mitigations might be adopted (TM470 module materials).

EDI relates to people, and differences between people, irrespective of whether they are perceived or due to physical, cognitive or sensory impairments. Since Computing and IT products are, ultimately, used by people, it is necessary to consider EDI issues. If you design an app or a website, your product should be accessible to the widest possible group of users. The motivations for doing this are twofold: firstly, there is a legal obligation to ensure that products and systems are accessible under the Equality Act, and secondly, all users are potential customers. If a product isn’t accessible or perceived negatively, a consumer might choose another service that has a more accessible, usable, or appealing interface.

Looking at this issue from a slightly different perspective, if your project uses artificial intelligence or machine learning, it is necessary to question the extent to which biases might exist within either data that informs your project, and the extent to which bias might be potentially reinforced, or even magnified.

Questions to ask

As highlighted earlier, the LSEP materials contains a section that has the title: asking the right questions. 

Go through each of these questions in turn. 

When working through these questions, do think about the stakeholders who are involved with your project. A stakeholder can be thought of anyone who is affected by your project, either directly or indirectly. Ask yourself questions about what data might need to be held and collected, and what bits of legislation might play and impact if you were ever to deploy your project. The Equality Act was mentioned above. You might want to also consider data protection and computer misuse legislation.

If your project is a research report it is important to ask: what might be the impact of my report? If something is discovered by the report, what might be the impact of disclosing the results, or not disclosing the results? The point here is that it is important to go further than just the immediate project, but also to consider wider and broader impacts.

Differences between student projects and university projects

Before university staff can carry out research that involved human participants, they must submit project proposals through a formal ethics panel. The aim of this panel is to make sure that researchers have carefully considered everything, and any potential risks to all participants (and to the university) have been mitigated.

Unlike official university projects, undergraduate and postgraduate projects are not required to go through such a rigorous process. Rather than having an ethics panel and a lot of electronic paperwork to complete, students should think of their tutor or project supervisor as a mini ethics panel.

Interacting with your tutor whilst considering your LSEP and EDI issues should be thought of as a useful and necessary part of your project. Your tutor will be able to offer some thoughts about what needs to be considered. Plus, interactions with your tutor or supervisor can be documented in an appendix of your final reports.

Further resources

A lot of good resources about ethics are available, and some of these resources are mentioned in the module materials. Here are a collection of links that might be useful:

For those that find this subject really interesting, there is a whole suggested curriculum about Society, Ethics and Professionalism on the ACM website.

Going through the ethics bit of TM470 gives you a taste of what university researchers have to go through when they plan and design studies that involve human participants. More information about what goes on behind the scenes at the OU is presented through Ethics support for projects: Which studies need review, by whom and why? (OU blog)

Reflections

I find ethics a fascinating subject. In computing it comes into play more than you might initially expect since computing touches on so many different areas of human activity. Rather than being a subject that was once on the periphery of the discipline, I now see it as a topic that has moved to the centre. It is an important and necessary part of becoming a computing professional.

It is also interesting to reflect on how ethics has developed since I was a graduate student. There is now a lot more that has to be done, but this isn’t a bad thing. Additional scrutiny along the way helps researchers to carry out better research. For TM470 students, my key bit of advice is: speak with your tutor; they are your own personal ethics panel.

Permalink Add your comment
Share post
Christopher Douce

TM470 Project report structure

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 28 Jun 2023, 09:03

When studying TM470, students are required to design, plan and carry out a short project that will enable them to show off the skills and knowledge that they have gained from their earlier level 3 students. To pass this module, students have to submit a detailed project report, which can also be thought of as a dissertation.

Since student projects can take many different forms, the TM470 module materials offer general guidance that need to be interpreted by students. A suggested report structure might work well for one type of project, but not for another. Students might decide on a research project (looking into a very specific problem in a lot of detail), an evaluation project (comparing one product, tool, system or approach to another), or an implementation project (choosing to design and implement code that solves a well-defined problem).

In absence of some very specific guidance about how to structure of project report, this blog post offers a summary of some of the guidance that I have offered (and continue to offer) during some of my TM470 EMA preparation tutorials. After my tutorials, I also share a link to this blog post to the TM470 students that I am supporting.

I must offer a disclaimer: this guidance will not fit all projects. Students must decide about whether the below suggested structure it is appropriate for their own project. Also, they must also decide on whether their report demonstrates that the TM470 learning outcomes have been met.

Before summarising the suggested structure, I have three tips for students:

  1. Ensure that your report is as readable as possible (but do make sure it remains a formal report). The project marker may be unfamiliar with the subject that you are writing about. Take time to set the scene and explain concepts that may be unfamiliar to a reader.
  2. Do have a look through the OU Skills for Study resources (OU website). In particular, I’m a fan of The Good Study Guide which you can find through the OU study booklets page (OU website). The Good Study Guide offers some really helpful advice about researching and writing.
  3. Think of the project report as a ‘technical narrative’, or a ‘technical story’. It is also a story that can contain other narratives. There is a story about your planning, a story about your reading, a story about what has been done, and what has been learnt. Make your technical story as interesting as you can.

1. Introduction

In this section, present a really short introduction to the whole project. Try to summarise it in a couple of sentences. Then, provide the reader with a pointer towards what they can expect to see in the next sections. This will ‘prime’ them for what is coming up in the next section. You might also want to allude to what you have achieved, but don’t tell them everything; this is presented in the next sections.

2. Problem description

In this section, go into a bit more detail about what your project. You might want to explain a bit more about the project context or setting. Background information will help the EMA examiner to understand what your project is all about. In some ways, think of the opening sections of the report as a ‘spiral’, where you gradually lead the examiner towards the detail of what you’ve done. In some way, you’re teaching the reader about your project.

3. Preparation and planning

In the previous section, you’ve told the examiner what you’re going to do. This section is all about how you’re going to do it. Since sharing detail about your project plan is important, it is a good idea to split this section into a number of subheadings.

3.1 Project Model

A suggestion is to begin by telling the examiner about the project model you’ve chosen. Do have a look at the module materials about this, and what this means. In other words, you could use this section to summarise the project planning approach that you have chosen, and why it is appropriate. 

3.X Resources, skills, activities, risks, plan…

What might follow is a series of subsections about resources that you need, skills, potential risks to the project, and also something about this high level plans. Do say something about what you’re going to be doing, and also what tools you might have used to decide on what you’re going to be doing and when.

4. Legal, social, ethical and professional issues

Legal social ethical and professional issues (LSEPI) are important, especially in TM470. As future Computing and IT professionals, it is important to be mindful about the impact of a project or development on wider society, and any implications it might have. Also, if a project involves working with people to uncover requirements, it is important that you treat everyone in an ethical way. The module team offers a bit of guidance about this topic, but for further inspiration it might be a good idea to have a quick look through the British Computer Society Code of Conduct (BCS website).

5. Literature review

This section is all about showing the examiner what you have read or studied, and how this has influenced the project work that have done. I’ve suggested it comes at this point, after the LSEPI section, since the identification of some legal, social, ethical or professional issues might raise questions that can only be answered by further reading.

There are different ways to structure a literature review. Two ways are: by theme, or by time. In other words, by the subjects that you have read about, or the order in which you have read things. I always prefer thematic literature reviews since they enable the writer to adopt a more critical approach. This means you can more directly and easily compare and contrast different opinions from different sources.

In this section, do try to reference as widely as possible. Do take the time to reference other modules you have studied (including textbooks and module blocks), any technical text books you might be using in the next section, and also do a bit of digging into the OU library (which all students have access to).

Fellow tutors have offered the following guidance: “show you understand the importance of a source; show you recognize the limitations of your sources; show how the literature has influenced the direction of the project and informed your thinking, and show how the literature has justified decisions”.

6. Project work

This is one of the most important sections of the report. It shows the examiner what you have done. It should ideally be a series of case studies that presents a narrative (story) of what you have done, and should relate back to the plan that you have described. To structure everything, it is a good idea to separate everything out into a series of subheadings; one for each mini case study.

Drawing on comments from fellow TM470 tutors, the examiner needs to get a feel for the project as a whole, the solution you created, and whether you solved the problem. Importantly, this section should demonstrate your technical and presentation skills, and should be concise.

If you have a project where you have generated a lot of materials, such as interview scripts, survey results, source code, or diagrams, you need to make a choice about what goes in this section, and what you choose to put in an appendix. One way to answer this question is to ask yourself: is this an example of my best work? If so, put something in this section.

7. Review and reflection

By the time you get to this section, you would have prepared a plan, have done some research, and have carried out some project work. This section is all about telling the examiner what you have learnt from the experience of running your project. 

To help you to begin to answer this question, think of those “WH” questions: what, how, when, and why? Ask yourself the following questions: Did you follow your plan? Did you learn the right thing, and the right time, to solve the right problem? How did what you learn help or hinder your project? Also, how did you expand on your level 3 studies?

The more thoughtful your review and reflection section appears, and the more that you appear to have learnt by completing the project, the more evidence there will be that you have obtained some of the TM470 learning outcomes.

8. Summary

To wrap everything up neatly, I tell students to write a short summary. A suggestion is: to offer a reminder about what the project was all about, what project model was chosen, summarise what has achieved, and then to share three things that have been learnt by completing the project. In some senses, this final summary should mirror the introduction section.

9. References

Clear referencing is really important. The aim of this section is to enable the examiner to find an original source, report, textbook, or anything else that has helped you with your project. It also offers a neat summary of all the reading that you’ve done.

For TM470, you only need a references section, not a bibliography and a references section. If you use a resource in the body of your text, make sure that you refer to it in this section. Make sure that you present everything in alphabetical order, and mention dates of publication. If you’re unsure how to format any resource, book, paper, technical report, or bit of software, do refer to the CiteThemRight website.

Appendices

A project report can have any number of appendices. You can use an appendix to share supplementary materials to help the examiner to get a feel for what you’ve done during the course of your project. 

There are no hard and fast rules about how many appendices you should have since every project is different. You might use them to show excerpts of source code, diagrams, consent forms, and data that you might have collected during the course of your project. Whatever works best for you. You should, however, always reference each appendix from within the body of the report, just to make the examiner aware that this may be an important part of your report.

Although you must try to limit your project report to 10k words, there is no limit to how many additional words you can provide within the appendices (but the module team does encourage everyone to be reasonable).

Acknowledgements

You can include an acknowledgement section in your project report, along with a glossary if you feel it is appropriate to include one. 

This acknowledgement section is for this blog post, rather than for a project report. I would like to acknowledge Chris Thompson and Karl Wilcox, who have been very generous in sharing their tutorial resources with me. I would also like to acknowledge Alexis Lansbury, who is my TM470 line manager.

Permalink Add your comment
Share post
Christopher Douce

Reflecting on TM470

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 17 Sep 2019, 15:17

I’ve now been tutoring on TM470, the Open University’s Computing and IT project module, for three years.

I heard it once said that it takes around three years to get to grips with the tutoring of a module; I agree with this view.

After this amount of time, you’ve marked a good number of TMAs, EMAs and have a solid appreciation of what is on the module website. You also (hopefully) should have a thorough understanding of what is in the head of the module team, enabling you to respond to student queries with a degree of confidence.

Also, three years is enough time to get a feel for what makes up a good project report, a distinction level project report, and a project report that might not pass. Having that experience has also enabled me to question what I do as a tutor, and to help me offer the best feedback I can.

What follows is a set reflections that relate to what I think is important when tutoring on the project module. I’m sharing since it might be of interest to fellow tutors, TM470 tutors, but also the module team too (since they, of course, guide how we approach everything).

These are, of course, my own opinions, and I do expect that different tutors will (of course), have different views - and, of course, have slightly different practices.

Welcoming students

I feel that I started very well in my first presentation but didn’t do so well with this on my second presentation. This said, I think I’m happy with the approach that I have used with the most recent presentation.

I begin by sending each student an email to say hello. If I see that any of my students have any additional requirements, I add a sentence to each introductory email to ask them to let me know whether there’s anything I need to be aware of to ensure that I help them with their studies. This tends to open up a dialogue.

In my introduction, I also mention that it might be useful to have a quick chat on the phone. I try to do this with every student in my group, but not everyone wants to have a chat; and that’s okay. I feel it’s important to be supportive whilst not being pushy.

A final point is that I also tell students to subscribe to their TM470 tutor group forum. The reason for this is that I use the forum to send updates and reminders about various things, and subscribing enables them to get notifications about those notifications.

Keeping in touch

One of the things I do regularly is send all students regular emails. Not every tutor runs tutorial, but I do; I send them dates of the tutorials as soon as they have been scheduled. I also send them a note to remind them of the TMA cut off dates, and send them reminders to let me know that I would like to receive regular updates.

When I send reminders about a willingness to receive updates, I also make the point that everything that is sent to me can also be used and presented within the project report as evidence of progress. I hope this offers a further encouragement!

Tutorials

At hinted at earlier, some TM470 tutors run tutorials, whereas other don’t. There isn’t a requirement for TM470 tutors to run tutorials; some tutors only run one to one sessions with their students.

I find tutorials useful for a couple of reasons.

At the start of the module, I fix a date for two introductory sessions: one that takes place in the evening, and one that takes place in the day time. I send all these dates to students in a group email and post the same information about them on our tutor group forum.

I split my tutorials in to two parts: the first part that is recorded, and the part section that is not. Dividing the tutorials in this way enables the first section to be viewed by the students who were not able to attend either of the tutorials. The second section becomes an informal chat between the students who come along.

In the introductory tutorial, I talk about the assessment strategy and the first TMA and do some screen sharing to introduce students to the module materials.

I tend to run two EMA preparation tutorials which has a similar structure, but with more focus on what a good EMA might look like. I also do some screen sharing: I take the students to the referencing guidelines site, and might even take them to some Skills for Study sections materials that are about academic writing.

One-to-one sessions

Every student has four hours of personal one to one time. I don’t keep a very close tally of how much of that time is used; some of it could be roughly allocated to tutorials, whereas other bits of time could be allocated to one to one sessions.

I mention one-to-one sessions in different ways: in the TMA feedback, during tutorials, and in the keeping in touch emails. If students don’t want to take me up on the offer of a one to one chat, that is okay, but I do make it clear that this is an option that is available.

Rather than having telephone chat, I’ve tended to use the Adobe Connect tutor group room. One of the great advantages of this is that we can do some screen sharing. Screen sharing is really useful. I’ve used it as a way to get an understanding of how a student’s draft submission is coming along, or to guide students to resources that have been prepared by the module team. I sometimes give the student screen sharing permissions so they can take control of those sessions.

TMA Feedback

There are, of course, two main components of the TMA feedback: the summary page, and the on-script comments.

On the summary page, I tend to focus on offering three clear points of advice that student should work on to improve their performance on the next TMA. When I’m writing these points, I try to explain why these points are important, and how they connect to the aims and objectives of the project module.

When I’m working on later TMAs, I always tend to do a quick read back of the previous TMA summaries. On occasion, I’ve copied and pasted text from the previous TMA and have put it on the current TMA, saying: “I gave the following feedback; it is important because…”.

I also tend to conclude a TMA with a suggestion about having a follow up call or chat.

For the on-script comments, I encourage students to use the Word in built heading tools (if they are not using them already). I make the point that it enables the student to use the navigation tool (which helps the student to view the structure of their EMA). Also, increasingly I tend to offer some practical advice about the formatting of sections (showing how students can move between portrait and landscape page layouts). To help students get to grips with these elements of Word, I have also offered link to various YouTube videos to help them understand the points that I’m making.

Tutor group forum

Students don’t tend to you my tutor group forum much, but I tend to use it as a simple notice board.

Here’s a summary of how I use it:

  • Sharing dates of tutorials, and providing of links to recordings.
  • Giving updates about TMA marking. I make a post to the forum when I start marking, and then post again when I’m roughly half way through (to give students some idea about when to expect their results). I tend to ‘pin’ these posts at the top of the forum during the marking.
  • Sharing of additional resources and links.
  • A space for students to ask questions.

Staff tutors can (or may) dip into tutor group forums from time to time to see what is going on. A well populated tutor group will give a staff tutor the impression that all is well with the group.

Additional resources given to students

During this most recent presentation I prepared two really short resources in the form of Word documents that might help students:

  • A very short sample introduction to an imaginary project and project report. This sample presents a structure that is very similar to the guidance that is offered by the module team.
  • A sample table of contents, which includes an introductory section, a section that outlines the project, a literature review section, an account of project work section, a reflection section, a summary or concluding section and a series of imaginary appendices.

The aim of these two resources is to emphasise the point that the project report, and it’s overall degree of readability is really important.

Advice to students

I’ve sometimes offered the following tips at various points during the module. I might mention these suggestions during tutorials, or in one-to-one sessions:

  • Make sure that you use the features that are provided in Word well; they can help you to find you way though, navigate, and work with larger documents. 
  • Try to write the literature review as a narrative rather than a list of papers or resources that you consider to be useful for the project.
  • Think of the examiner as a friend who doesn’t know very much about the project (and subject) that you’re writing about. Subsequently, you might have to spell things out for them. Don’t worry about doing this, since this will all help to demonstrate your understanding of some important concepts.
  • Consider the reflection section, the bit in the EMA where you have to write about how things have gone, as a gift. It’s a gift because it’s all about you, and there are no wrong answers, and the examiner really wants to hear about you and what you’ve learnt. Also, don’t be afraid to be opinionated! Tell us what went well, what didn’t, why you thought that, and what you might have done again differently.
  • Provide copies of two different Gantt charts; one that was created at the start of the project, and the Gantt chart that was being used as the student got to the end of the project. These two Gantt charts gives a student a neat way to generate some interesting reflections, simply by considering the differences between what the plan was at the start, and what happened during the project.
  • Use the appendices as a way to share extra information about what project work you’ve done on the project.
  • Keep to the word count (10k words) but don’t worry too much if you go over by a little. If you’re going over by a lot, consider putting some bits into a series of appendices, but always make sure that you reference these in the body of your report.
  • Finally, find someone to proof read your report. It’s okay to do this, since you’re the one who is doing the writing, not whoever is doing the proof reading. Typing mistakes can and do happen. A friendly proof reader will be able to pick up on some of them.

EMA marking

EMA marking is hard work, and we don’t have too much time to do it in. When I start marking, whenever I open an EMA report, I turn tracking on, and highlight sections that I’ve read that really stand out to me as being good, important or significant. When I’ve read everything, I might go back and re-read sections before going to the learning outcomes that are presented in a grading spreadsheet. I then make notes, which are later copied and pasted into the OU’s grading tool.

My own approach is to do some marking first thing in a weekday morning (when I’m fresh), hopefully working through a couple of reports, with a view to doing more over the weekend.

If there is a moderation exercise, the highlighting annotations I’ve added really help me to remember what a project was all about, and why I assigned certain marks against a particular learning outcome.

Closing thoughts

TM470 has a slightly different tenor to the other modules I’ve tutored. Although there is a lot of learning to be done during the project, it is more about doing and writing (and then learning from that doing and writing).

Students sometimes ask whether they can see an example of a project, but this is something that the module team doesn’t provide. I can understand why students would like to see a sample (to understand more about what the module team expects), but I can also why the module team doesn’t provide one (they worry that the tutors would then receive a hundred or so projects that look remarkably like the sample projects).

One of the challenges (in my opinion) of being a TM470 tutor is to help students understand what the module team expects, but from the perspective of their own projects and their previous studies.

Permalink Add your comment
Share post
Christopher Douce

Making a TM470 log by using a blog

Visible to anyone in the world

TM470 is the Computing and IT project module. The project module allows students to draw on skills and ideas that they have studied and developed during earlier level three modules. It enables students to demonstrate skills across a more substantial piece of work.

This short blog post is basically a bunch of ideas that might be useful for fellow TM470 tutors, but also for any TM470 student (and anyone else who might be involved in a project module).

A really important part of TM470 is the end of project report which summarises everything that has been done. The report requires students to present a description of the outcomes of the project, and what has happened during the project.

The project log

TM470 project can last up to eight months. During that time, a lot can happen. To keep track of things the TM470 module team recommend that students create something that is called a project log. Here’s an excerpt from the module materials that offer a bit of guidance:

"Keeping a project log is similar to keeping a diary. It is a useful aid in helping to manage a project. In a project log, ideally you should make a log entry each time you have a work session.

Whether recorded on paper or electronically, your log is where you keep details at regular intervals of salient events or facts that have occurred in your project. The log differs from your plan in that it provides more detail of things you have done, whereas the plan is a schedule of what you are or should be doing. The log is purely historical information; it can contain facts about your project but probably more important is writing down reflections about what you are doing."

The module team suggests that a log serves three purposes:

  1. They provide a reminder of how your project developed; this will be useful when it comes to writing your TMAs and EMA.
  2. They help you when in discussions with your tutor because they provide a record of how you planned your project, how you managed your time, how you tackled the tasks and how you dealt with any problems.
  3. Using the log sheets on a regular basis will help you to keep to your schedule, and may suggest changes to your schedule. 

Students are told that they should be spending approximately ten hours per week on their project. The project log also enables students to keep track of how much time they’re spending on the project. 

Students are also encouraged to submit excerpts of their blog to their tutor, to keep them informed about how their project is progressing.

The OU VLE

The module team suggests that a log might be recorded on paper, or recorded electronically. An accompanying question is: what form might an electronic log take? One approach is to use a word processing document. You could have a day for every page. One idea is to record a ‘session number’, record a date, record how long was spent working, and also a summary of what was done during that session, and perhaps some thoughts about what the next steps might be. In some ways, this kind of log has parallels to a ‘work log’ that a researcher might keep.

Rather than using a word processing document another idea is to keep a TM470 log in the OU VLE blog.

Every OU student is given their own blog, which is hosted in the university virtual learning environment. The OU blog is useful because it provides a number of useful features:

  1. It allows students to automatically record the date and time of any entry that is made.
  2. It allows students to add ‘tags’ against particular blog entries. A tag, of course, is a useful word that can be used to help find things again. Using the OU blog you can quickly find blog entries with the same tag (in the way that the tag for this post is TM470).
  3. Students can any log entry with other TM470 students, and they can share their TM470 log entries with you. Blogs can be easily shared with a tutor, enabling them to more directly understand progress on a particular project.
  4. The blog can be accessed easily through a web browser: you don’t have to use the same word processing software every time.
  5. The blog is automatically backed up by the university, which means that you don’t have to worry. 

Another feature of the OU blog is that students can choose who sees what is posted. 

The OU blog has three settings: students can keep every blog (or log) post private; this means that a blog can be a bit like a private diary. Another setting is that blog posts are only visible to people within the university. This setting is useful for sharing blog posts to other TM470 students. The final setting is to make a blog post visible to the entire world. In terms of TM470, I personally recommend that this first two options are used.

An accompanying question is: how can students begin to use their blog? The answer is to look for their VLE profile. They will soon find a link that allows them to begin posting a blog.

Note taking advice

Whilst the TM470 module team offers some great advice for creating a log, the university also offers other advice which might be useful too, such as note taking techniques which is available on the skills for study website.

Also, the following three useful points (Making notes strategically) have been adapted from Northedge (2005) from his book The Good Study Guide, p.155:

  1. Take an active and enquiring approach to study. Ask yourself questions, such as ‘what is this about?’, ‘what do I want to remember?’ and ‘what do I want to say?’ and writing down the answers.
  2. Flexibility. Make sketched notes or detailed notes according to need. This can be particularly useful when making note to support creativity. These notes could then be ‘written up’ and used within the project log. Plus, having them in a blog form allows them to be searched.
  3. Reflection. Looking at notes and ask: ‘are they doing the job I want?’ and ‘could I be using my time more effectively?’ Or, put another way: are these the right kind of notes.

Sharing blogs with other students

The best way to share blogs with fellow students is to share links to the blogs in the module discussion forums. Once you have a link to a blog, you can then add it to something called a ‘blog feed’, to receive a notification whenever a new update has been made. Another advantage of a blog is, of course, students will see that they’re not alone; that there are others who have to contend with similar challenges.

Permalink
Share post
Christopher Douce

TM470 New tutor day

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 22 Nov 2016, 09:46

I first joined The Open University as a part time tutor back in 2006 where I tutored a module called M364 Fundamentals of Interaction Design. Knowing that this module was coming to an end I decided to apply to tutor on another module: TM470 The Computing and IT project, and I was successful!

I was invited to attend a ‘new tutor day’ which took place in the West Midlands regional centre in Birmingham (which is, sadly, closing in the new year) to learn about the ins and outs of tutoring this module. This was also an opportunity to meet my TM470 mentor, fellow TM470 tutors, and some of my colleagues who support the delivery of computing and IT modules from the Manchester and Birmingham offices. This blog post has been drawn from a set of notes I’ve made during the day, which took place on 2 July 2016.

Project choice

I’ve noted down the question: ‘what makes a good project theme?’ It’s a simple question and one that is very important: students must have a clear idea about what the problem is that they want to solve within their project. It should also have sensible limits, i.e. students shouldn’t aspire to creating the next big app for the iPhone.

Successful projects are those that draw upon practical skills that have been learnt (or studied) in previous level 3 modules. A project could also build on something that has been done before. Students should (ideally) be knowledgeable about the domain or environment in which a project relates to (so they don’t have to spend lots of time doing research into an area that isn’t familiar to them). Also, importantly, a project should be connected with something that a student is interested in doing (so they maintain their motivation).

Another bit of advice is: students should stick with using software that they know; don’t be tempted to play with new things, since it’s easy to get tied up in knots.

Sometimes students might be tempted to draw upon projects that relate to their work place. An important point is: work and TM470 have different goals; it is probably best to keep work and study separate for the simple reason that changes at work might jeopardise the project. This rule, however, doesn’t have to apply in all cases: students need to understand what is required from TM470.

Another really important point is: a project doesn’t have to have a successful outcome to submit a final project report. Students can still pass if things go horribly wrong: it is the description of the project, the learning, and the reflections that all count towards the final scores. If these are done really well, students will get a really good pass.

Another note I’ve made is all about research: ‘not really understanding what is meant by research that is academic, or what is meant by an academic literature review (and analysis)’. Some projects may be research projects, in the sense that they are an in-depth and critical study of a particular area. If students choose research projects, the need to be clear in terms of what is required of them. 

Independent learning

TM470 is different to other modules, since what really matters is being able to demonstrate independent learning; tutors will not be subject experts in all the areas in which projects are chosen from. A note I’ve made is: ‘if software breaks, it is part of your job on a project to fix it’. The role of a tutor is to push a student into this mind set.

Practicalities

I made a note that we discussed the importance of the introductory letter, and that we might connect this to the use of our module discussion forum.

A really important resource is the OU Library which allows student direct access to a wealth of prestigious journals. Another thought is to direct students to library tutorials (understanding eJournals) about how they can get started.

The project module doesn’t have any official tutorials, since it is difficult to run group events where every student is working on a different project (and will have different learning needs and problems). This said, some tutors do use OU Live to run some unofficial introductory tutors. 

Towards the end of the day, we discussed practicalities about end of module assessment marking, and assignment marking. Key questions that were asked were: ‘how do you do it?’ and ‘what processes do you use?’ The module has a very clear set of marking guidelines that are also known to the students. Ultimately, everything comes back to the question of whether students have met the learning outcomes.

Reflections from first presentation

Now that I have more of an idea how the module works and how it is structured, I think I will run an introductory OU Live tutorial at the start of the next presentation. This will allow me to learn more about the student’s ideas and understand more about their potential problems. I will also use this to emphasise the importance of time management.

In comparison to other modules that I have tutored on, I found the marking to be pretty straightforward once I knew how it worked. It took me a bit of time to find the forms, and then to internalise the marking criteria (but this is always the case when starting to work on a new module). One of the things that I really enjoyed was looking at the diversity of the projects, and how the students tackled them.

Permalink
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: 1874743