Personal Blogs

On 29 February 2024 I attended an academic conduct review briefing for module teams. The aim of this blog is to share some highlights that may be useful for colleagues (and to also try to remember what was covered, since there’s always a lot going on).

During the introduction, it was highlighted that academic referrals have increased over the last 5 years. Two thirds of these typically relate to study skills and poor academic practice. In other words, this relates to what could be called inadvertent misconduct.

There are some specific challenges. Investigations take time, there is an obvious need for consistency with decision making, a need for transparency, and continually emerging threats, such as essay mills and the arrival of generative AI. To respond to this changing landscape, there is a new VLE page for staff, a new academic conduct tariff, new guidance on StudentHome, a new referral form, and new processes and study skills arrangements.

Academic integrity principles for assessment design

Assessment design is important. Good assessment design should ‘reduce the motivation and opportunities for plagarism’ and focus should be on how learning takes place, as well as what is learnt.

An important point that I noted was that module teams should look at patterns of academic conduct referrals. One way to respond to repeated issues is, of course, to consider the assessment design. To help with this, there some useful principles of assessment which I share below.

A key theme of these principles is authenticity. This is connected with need for to assessments that focus on problem solving, perhaps solving problem that might have an open ended answer.

Here are the ten principles that were shared during the session.

Principle 1: Reward academic integrity

Make sure students reflect on their skills and capabilities that demonstrate academic integrity.

Principle 2: Assess higher skills

Assess metacognitive skills where students actively create an answer, with an emphasis on construction and their own thinking. This point is, of course, linked to the principle of refletion.

Principle 3: Open-ended solutions

This principle is related to authenticity. It’s possible to see authenticity within the undergraduate computing project module.

Principle 4: Diversify assessment formats

This is linked to how students might relate assessment to their own interests and preferences. Providing a variety of different assessment formats also speaks to the importance of accessibility and diversity.

Principle 5: Authentic assessment

Making an assessment real by sharing an exciting concept can enhance motivation. Make an assessment authentic by drawing on their own experience.

Principle 6: New assignment questions

To limit the risk of academic conduct, prepare new assignment questions every year. Design the assignments in such a way that students cannot re-use a previous answer. In other words, make it difficult for students to directly benefit if the questions were to be shared.

Principle 7: Process besides product

Ask students to submit interim versions of assignments or ask them to provide a demonstration. In the computing project module, students are asked to submit a draft EMA as an assessment.

Principle 8: Making quality criteria transparent

Make rubrics transparent; share with students how assessments are made so everyone knows what the module team (and the university) is looking for. 

Principle 9: Generating and acting on feedback

Encourage students to generate their own feedback, which helps to develop critical thinking. This relates to a principle of peer assessment. This is used, to a limited extent in a software engineering module, where students comment on interim designs. 

Principle 10: Authentication methods

Are students who they say they are? There used to be a time when students had carry out written exams by attending exam centres at a specific date and time. As a part of this, students needed to show a form of ID, such as a passport or a driving licence. An alternative approach would be for a student to have a conversation with a tutor about their assignment.

TurnitIn

A recent development has been the increased availability of TurnItIn to students. Module teams and staff tutors always used to receive TurnItIn reports. These reports indicated whether a submission contained words found in other online resources. A typical TurnItIn report might highlight legitimate quotes that a student used to evidence an argument, as well as uncited text.

On many modules students can now submit an earlier version of an assignment into TurnItIn. In turn, they can review a ‘similarity report’ to gain confidence that their assignment is adhering to sound principles of good academic practice. More information about TurnItIn can be typically found within a module’s assessment handbook.

Resources

A whole host of useful resources are available to students. The blog post Study Skills Resources: what is available? offers a handy summary of some of the most useful.

Reflections

I’m not sure where these assessment principles come from. I really like them. I can bring these ten points into module team meetings. Their focus on authenticity strikes me as being really important. It is important in terms of problem solving, skill development and the application of knowledge.

Putting the assessment design principles to one side for a moment, tutors are really important. If appropriate, students can refer students for additional support sessions, and can also refer students to study advisors who work within the student support team.

Students can then be referred to additional support needs, and referral to a study advisor. In my experience tutors may sometimes get a sense when a student may have used Generative AI.

Acknowledgements

Acknowledgements are duly given to the academic conduct review team who facilitated this session. The principles shared in this blog post are their own, and I take no credit for them. I hope I’ve summarised them effectively.

On 24th in September I attended a new module briefing at the University headquarters in Milton Keynes. Rather than being the usual ‘academic’ module briefing, this was a briefing for new practice tutors (PTs). 

Practice tutors support degree apprenticeship (DA) students. DA students are funded by employers. They have one day a week, or 20% of their time allocated to degree level study. 

Practice tutors are a part of a 3 way relationship between the employer, the student and the university. Their role is to support the student, and to facilitate the students progress though the pathway by working with employer and university representatives. On the employer side, there is also someone called the APDM, who is known as the Apprenticeship Programme Delivery Manager, who work with all employers who have apprentices at the OU. 

One of the most significant differences between a practice tutor and a module tutor is that rather than getting a new set of students every year, a practice tutor supports a group of students over a number of years. 

What follows is a quick summary of some of the things that practice tutors have to do, along with some more general notes and facts about degree apprenticeships. One thing that I should note is that whilst the roles are clearly defined, some aspects to the degree apprenticeship scheme may change. What this means is that if you’re reading this a couple of years after its publication, it’s entirely possible that things might have moved on from what was described here.

The code XTXY112 relates to the activity of supporting Digital Technology Solutions (DTS) apprentices who are based in England.

Key components

A degree apprenticeship consists of a number of different components. 

Qualification: the result of studying a combination of academic modules and completing work based learning-modules (where a student has an opportunity to apply academic ideas and practice new skills in a real work environment).

English and Maths functional Skills: although there are no entrance requirements to begin a degree apprenticeship, there is an exit requirement. If a student hasn’t gained a certain level of English and Maths skills, they must achieve a certain level by the end of the programme.

Portfolio and work based projects: students need to complete an agreed work based project which something that relates to a business need, and create a valued body of work, which is represented by regular contributions to an e-portfolio system.

End point assessment (EPA): students need to get to this stage, which represents an assessment of the knowledge, skills, and behaviours learnt from the apprenticeship programme.

All this leads to: a recognised apprenticeship that was designed with input from industry, a recognised degree, and an opportunity (if applicable) to register with a professional body.

There are a number of different people involved: there are the academic/module tutors who deliver academic modules who assess progress and moderate forum discussions. There are also the practice tutors who check and evidence the e-portfolios, reviews progress, carry out assessment of work-based learning (if applicable), and help with the end point assessment preparation. There are also apprenticeship programme delivery managers who handle the registration, employer liaison and the EPA processes.

Introductions

Since a PT is going to be important in the life of the degree apprentice student and represent a key point of contact with the university, a positive introduction is really important. 

A face-to-face meeting is expected to take place between the beginning of the module and 6 weeks with the apprentice, the practice tutor, and the apprentice’s line manager. To arrange a meeting, the PT will (like other OU tutors) send a welcome message by email. Following the introductory email, different bits of information are shared, such as contact details, confirmation of work addresses, and telephone numbers.

The first meeting

The first meeting is all about getting to know the apprentice and their line manager. It’s also about information sharing. It’s an opportunity to introduce the apprentice to the various OU systems and ways of working. A suggestion is to bring along a laptop, or ask to have access to a computer, as that way you can use it to talk the apprentice through some various bits of the OU system, such as: the StudenHome website, the module website, where to find information about the module tutor, where to find the assessment resources, what the study calendar is, what a TMA is, what cut-off dates are, and how to submit an assessment. It’s also important to ask whether they have been through the OU study materials (studying at the OU).

Another key issue to explore or address is the importance of time and planning. Since the apprentices will be working full time and will have dedicated study time, it’s important to find out whether they are aware of the time commitment that is necessary to study, and that time is carefully accounted for.

Another important topic that must be spoken about is something called the Individual Learning Plan (ILP), which is a progress report that is also used to record at least three objectives. The ILP will be completed and signed off by both the practice tutor and their line manager. During the meeting, the practice tutor must make the apprentice aware of the ILP, what it is and highlight that it must be completed, and it will be returned to during future meetings.

An important question to ask is: what pathway are they taking? The English degree apprenticeship has a number of different pathways through it. This discussion will help everyone have an early understanding of what the different options are. (More will be covered about the pathways later).

Record keeping

An e-portfolio system called OneFile is used to keep records of the work that an apprentice does. It can be thought of a document store that can be used to confidentially store evidence of progress that can be reviewed by other people. It can also be used as a personal journal too; evidence of learning can be selectively made available by an apprentice to their line manager, or to the practice tutor. 

It is used to store copies of the module TMAs that a student submits, and also keeps a copy of the ILP. I understand that it can also be used to gather evidence to support the completion of the ‘apprentice’ part of the degree apprenticeship. 

Quarterly and end of year reviews

An important role of the practice tutor is to keep a gentle eye on the apprentice; to make sure that they’re on track with their studies. The practice tutor may also check with the apprentice’s TMA results, and also send a quick note to a module tutor to ask whether everything is going okay.

Before a visit or meeting, an apprentice needs to update their ILP. The practice tutor might also send a note to the module tutor to ask how things are going, and if there have been any problems. A key question that might be asked is: has anything changed with respect to any study plans?

Towards the end of the first year, there will be what is called an end of year review about how things have gone. Also, towards the end of the second year, the PT will have a discussion with the apprentice about the different pathway options that exist through the apprenticeship programme.

It will be important to review ILP, and to discuss the objectives that can be set on the plan. A suggestion is to use SMART targets; targets that are Specific Measurable Achievable Relevant and Timebound. Discussions may include points about progression, training opportunities, and whether it is necessary to gain exposure to different parts of the organisation. Essentially, it will be about what has happened, and what may happen. 

Functional skills and prerequisites

There are no prerequisites to start on a degree apprenticeship programme, but they need to have functional maths, English and ICT skills by the time they finish. If apprentices don’t have at least a GCSE grade 4 in English and Maths (if I understand this correctly) they can complete what is known as function skills test, a two hour exam, run by an organisation called BKSB (website). 

It is recommended that apprentices complete them within their first 18 months of study. Records of gaining the functional skills in these areas will be stored within the student’s e-portfolio.  An important role of the practice tutor will be to make sure that students do complete these exams as early as they can, so as to make room in their study schedule for everything else that they have to do.

Modules that DA students will study

In the first year, students will study the following three modules:

TMXY130 Introduction to computing technologies: this module has a bit of networking, cybersecurity and bits of mathematics that are specific to computing. Students will complete formative interactive computer marked assessments (iCMAs), complete tasks using Cisco packet tracer, and complete 3 tutor marked assessments. The final EMA covers all three components of the module.

TMXY112 Computing and IT 2: three different themes are interlaced; hardware, problem solving and computing in the wild. During the module, students are introduced to the Python language. All the topics are connected to the development of skills. There are 3 summative TMAs, each contributing an increasing percentage to the overall score. Students must also complete various block quizzes.

TMXY122 Work based learning: students must design a study planner, and consider their study skills, and write a reflective piece. There are 3 x TMAs and an EMA. TMA 2 is skills based, where students must identify an IT related issue, and consider a hypothetical research project. They must also develop a research proposal to collect data. TMA 3 is about reflection, and asks students to relate their role to a national occupations database. Finally, the EMA relates to a professional (or personal) development plan. 

Looking towards the second level, student will study MXY250 Object-oriented Java, TMXY254 Managing IT: the why, the what and the how (which is about service management, and has a bit about relational databases), and TTXY284 Web Technologies. 

DA pathways

There are Four pathways through the English degree apprenticeship programme (things are different for Wales and Scotland). 

Students can opt for a Data Analyst pathway, where they may study OU modules such as M269 Algorithms, Data Structures and Computability (a computer science module) and TM351 Data Management and Analysis (where students get to write programs to analyse data).

Another pathway is the software engineering route, where students may study TM352 Web, Mobile and Cloud Technologies  and TM354 Software Engineering.

The third pathway is about cybersecurity. Here students will study TM352 Web, Mobile and Cloud Technologies which has a small amount of penetration testing, and TMXY311 which is about information and security management.

The fourth pathway is all about becoming a network engineer. Here the students will study some industrial Cisco material that also enables them to gain university credit. The modules are TM257 Cisco networking (CCNA) part 1 and TM357 Cisco networking (CCNA) part 2. 

Tips for the Practice tutors

What follows is a summary of tips that I’ve picked up from the briefing:

• Emphasise that they need to do programming. This makes up an important aspect of the whole programme. They need to develop their skills in level 1, since it gets a whole lot more harder in the later levels.
• Check to make sure that they have completed their OU induction.
• Encourage the apprentices to speak to their module tutors as soon as they need to. Emphasise the point that they are there to help. Also, a practice tutor can ask a module tutor how their apprentice is getting along.
• Make sure that they’re using the 20% of the time that they have available and emphasise the importance of time management. Also highlight that it’s important to get a work, life and study balance right. 
• Record keeping is important, and this means that the individual learning plan needs to be filled in for each meeting. This needs to be signed by practice tutor, the apprentice, and the line manager.
• Suggest that the OneFile e-portfolio tool could be used as a way to gather reflections (since reflections will be important in the work based learning modules).
• The work based project is important. If they’re not in a position to do this easily, given their current role and responsibilities, find out whether there is a way that they can be temporarily seconded to an appropriate project. 
• When considering the quarterly review, ask the question: has anything changed such as the study plan?

Acknowledgements

This blog was prepared from notes made during a briefing day that was organised by Chris Thomson, Computing and Communications Staff Tutor who also kindly copy edited (and corrected) an earlier version of this blog. During the day, presentations were given by Christine Gardner, David McDade, Claire Blanchard, and Caroline Stephens. Contributions were also made by XTXY122 staff tutors, Nigel Gibson and Ann Walshe. I also acknowledge the important role of the three Apprenticeship Programme Delivery Managers who helped us to further understand the role of the practice tutor. 

On Saturday 27 September I went to a briefing for a new OU module, TM354 Software Engineering.   I have to secretly confess that I was quite looking forward to this event for a number of reasons: I haven’t studied software engineering with the OU (which meant that I was curious), I have good memories of my software engineering classes from my undergraduate days and I also used to do what was loosely called software engineering when I had a job in industry.  A big question that I had was: ‘to what extent is it different to the stuff that I studied as an undergrad?’  The answer was: ‘quite a bit was different, but then again, there was quite a bit that was the same too’.

I remember my old undergrad lecturer introducing software engineering by saying something like, ‘this module covers all the important computer stuff that isn’t in any of the other modules’.   It seemed like an incredibly simple description (and one that is also a bit controversial), but it is one that has stuck in my mind.  In my mind, software engineering is a whole lot more than just being other stuff.

This blog post summary of the event is mostly intended for the tutors who came along to the day, but I hope it might be useful for anyone else who might be interested in either studying or tutoring the module.  There’s information about the module structure, something about the software that we use, and also something about the scheduling of the tutorials.

Module structure

TM354 has three blocks, which are also printed books.  These are: Block 1 – from domain to requirements, Block 2 – from analysis to design, and Block 3 – from architecture to product.  An important aspect to the module is a set of case studies.  The module is also supported by a module website and, interestingly, a software tool called ShareSpace that enables students to share different sketches or designs.  (This is a version of a tool that has been used in other modules such as U101, the undergraduate design module, and T174, an introduction to engineering module).

Block 1 : from domain to requirements

Each block contains a bunch of units.  The first unit is entitled ‘approaches to software development’, which, I believe, draws a distinction between plan driven software development and agile software development.  I’ve also noted down the phrase ‘modelling with software engineering’.  It’s great to see agile mentioned in this block, as well as modelling.  When I worked in industry as a developer, we used bits of both.

The second unit is called requirements concepts.  This covers functional requirements, non-functional (I’m guessing this is things like ‘compatibility with existing systems’ and ‘maintainability’ – but I could be wrong, since I’ve not been through the module materials yet), testing, and what and how to document.  Another note I’ve made is: ‘perspectives on agile documentation’.

Unit three is from domain modelling to requirements.  Apparently this is all about business rules and processes, and capturing requirements with use cases.  Prototyping is also mentioned.  (These are both terms that would be familiar with students who have taken the M364 Interaction Design module).  Unit four is all about the case study (of which I have to confess that I don’t know anything about!)

Block 2: from analysis to design

Unit five is about structural modelling of domain versus the solution.  Unit six is about dynamic modelling, which includes design by contract.  Unfortunately, my notes were getting a bit weak at this point, but I seem to remember thinking, ‘ahh… I wonder if this relates to the way that I used to put assertions in my code when I was a coder’.  This introduction was piquing my interest.

Unit seven was entitled, ‘more dynamic modelling’, specifically covering states and activities, and capturing complex interactions.  Apparently the black art of ‘state machines’ are also covered in this bit.  (In my undergrad days, state machine were only covered in the completely baffling programming languages course) .  Unit eight then moves onto the second part of the case study which might contain domain modelling, analysis and design.

Block 3: from architecture to product

This block jumped out at me as being the most interesting (but this reflects my own interests).  Unit nine was about ‘architecture, patterns and reuse’.  Architecture and requirements, I’ve noted, ‘go hand in hand’.  In this section there’s something about architectural views and reuse in the small and reuse in the large.  During the briefing there was a discussion about architectural styles, frameworks and software design patterns.

When I was an undergrad, software patterns hadn’t been discovered yet.  It’s great to see them in this module, since they are a really important subject.  I used to tell people that patterns are like sets of abstractions that allow people to talk about software.  I think everyone who is a serious software developer should know something about patterns.

Unit ten seems to take a wider perspective, talking about ‘building blocks and enterprise architectures’.  Other topics include component based development, services and service oriented architectures (which is a topic that is touched upon in another module, and also potentially the forthcoming TM352 module that covers cloud computing).

Unit eleven is about quality, verification, metrics and testing.  My undergrad module contained loads of material on metrics and reliability, and testing was covered only in a fairly theoretical way, but I understand that test-driven development is covered in this module (which is a topic that is linked to agile methods).  I’ll be interested to look at the metrics bit when this bit of the module is finalised.

The final unit takes us back to the case study.  Apparently we look at architectural views and patterns.  Apparently there are also a set of further topics that are looked.  I’m guessing that students might well have to go digging for papers in the OU’s huge on-line library.

Software

I’ve mentioned ShareSpace, which is all about sharing of software models with other students (modelling is an important skill), to enable students to gain experience of group work and to see what other students are doing and creating: software development invariably happens in teams.  Another important bit of software is an open source IDE (integrated development environment) called NetBeans.  I’m not sure how NetBeans is going to be used in this module, but it is used across a number of different OU modules, so it should be familiar to some TM354 students.

Assessment

TM354 comprises of three tutor marked assignments, a formative quiz at the end of every unit (that students are strongly encouraged to complete), and an end of module exam.  The exam comprises of two parts: a part that has questions about concepts, and a second bit that contains longer questions (I can’t say any more than this, since I don’t know what the exam looks like!)

Tutorials

Each tutor is required to deliver two hours of face to face tuition, and eight hours of on-line sessions through OU Live (as far as I understand).  In the London region, we have three tutors, so what we’re doing is we’re having all the groups come to the same events and we’re having each tutor deliver a face to face session to support students through every block and every TMA. 

We’re also planning on explicitly scheduling six hours of OU Live time, leaving two hours that the tutor can use at his or her discretion throughout the module (so, if there are a group of students who struggle with concepts such as metrics, design by contract, or patterns, a couple of short ad-hoc sessions can be scheduled). 

All the OU Live sessions will be presented through a regional OU Live room.  This means that students in one tutor group can visit a session that is delivered by another London tutor.  The benefit of explicitly scheduling these sessions in advance is that all these events are presented within the student’s module calendar (so they can’t say that they didn’t know about them!)  All these plans are roughly in line with the new tuition strategy policy that is coming from the higher levels of the university.  A final thought regarding the on-line sessions is that it is recommended that tutors record them, so students can listen to the events (and potentially go through subjects that they find difficult) after an event has taken place.

A final note that I’ve made in my notebook is ‘tutorial resources sharing (thread to share)’.  This is connected to a tutor’s forum that all TM354 tutors should have access to.  I think there should be a thread somewhere that is all about the sharing of both on-line and off-line (face to face) tutorial resources.