Personal Blogs

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 7 April, I attended the module briefing for a new module: TM111 Introduction to Computing and Information Technology 1. I arrived a little late but got there just in time to catch Richard Walker’s talk about the importance of accessibility, missing Elaine Thomas’s introduction.

Accessibility 

From the notes I picked up after the event, Richard’s talk mentioned quite a few things. TM111 has an accessibility statement, and the module provides a range of alternative formats. There are some issues that tutors need to be aware of. One challenge that some students might have is when they come to use a package called Audacity (Audacity Team website) which is an audio recording and manipulation tool. In some cases, students might need help to use the software, and students who may have speaking difficulties can use computer generated speech.

The programming environment, OU Build, can present some challenges for students who have visual impairments. Students with low vision will need sighted assistance to drive the software. Hearing impaired students might find some of the activities a challenge, but the module team have provided alternative versions.

Block 1: The digital world

Elaine Thomas who is the TM111 module chair introduced the first block. I haven’t got too many notes from this part of the day, so I’ll summarise some of the slides. An important slide has the title: what will students be doing in block 1? The answer is: reading the module guide, reading block 1 materials, finding this way around the module website, using Open Studio, using Audacity and using Google sites. 

Block 2: Creating Solutions

This bit of TM112 was introduced by Sarah Mattingly and Richard Walker. The vision behind this block is to help students to figure out if they enjoy programming. A part of this is to help them to understand that it is a creative process, and also understand key programming concepts and problem solving strategies (which can also be transferrable between different domains and subjects). I made the note that an important aim of block 2 was to help students to appreciate algorithms. A personal view is that programming is fun! However, like anything worthwhile, it takes time and practice to master. 

The key bits from the briefing PowerPoint included an introduction to OU Build (which is a bit like Scratch), an introduction to parts 2-5 (which are all about problem solving), and part 6 which is all about algorithms.

Block 2 is also interesting since it contains a number of forum activities. Tutors were provided a set of guidance notes. A key sentence reads: ‘your role is to encourage and support engagement with this activity … please suggest to students that they comment and ask questions of other students as well as post their own ideas’.

A final note is that the block doesn’t include a comparison with other languages, introduces unnecessary terms, or place significant emphasis on more nuanced (but important) issues such as efficiency or ‘good’ style. 

Marking exercise

Christine Gardner introduced us all to a very interesting marking exercise. We were given a TM111 TMA question, given a short excerpt from the tutor notes, and an excerpt from a student’s submission. Our job was to look at everything and figure out what score we would give the student’s answer, what comments we would write on the student’s script, and what we would write on the student’s PT3 summary (with respect to that particular question).

It interesting that different tutors gave slightly different marks for slightly different reasons, but there wasn’t anything to worry about; these were all within the bounds of acceptability. What really mattered, of course, was the learning that had taken place.

I made a note of a couple of suggestions that might help with the marking: it was important to acknowledge what our student had done well. It was also useful to point our student to the relevant module sections which explain the concepts that were being assessed in the TMA question. With respect to TM111, I think someone referred to something called the ‘laminated’ sheet.

Block 3: Connecting people, places and things

The final block was introduced by Karen Kear. This block introduces students to a wider set of issues that relate to computing and information technology. There are six parts: network technologies, the internet, wireless communications, the internet of things, online communications and the networked society.

From a personal perspective, the last two sections looked to be especially interesting: the part about online communications and the section about the networked society. The network society part features some really interesting topics: the connection between the government, the state and society, identity and biometrics, and networked health. The final section in block 3 has the title: placeless power and powerless places. This section includes interviews that explore the connection between technology use and individual power. I also made a note of something called ‘social presence theory’, which also is connected to power relationships and technology.

Acknowledgements

I have to confess that I have very little to do with TM111. I did help to support the delivery of the first presentation, by interviewing and supporting tutors, but I have now handed over that responsibility to a colleague (I am now more involved in TM112, this module that immediately follows TM111). I would like to mention the names of all the authors of the module materials: Elaine Thomas (chair), Chris Bissell, David Chapman, Ingi Helgason, Alan Jones, Karen Kear, Soraya Kouadrai, Sarah Mattingly, Nicky Moss, Mike Richards, Rita Tingle and Richard Walker. I’m sure I’ve missed some names! (Not to mention all the production and editorial staff).

And finally…

As a slight aside, when I was doing a bit of research for this blog, I found another blog, which was called: a sackofcrazy (a nice title!) The blog has the subtitle: adventures in Open University Computing and IT. If you’ve accidentally found my blog and you’re an OU student, I do recommend that you have a look at Mark’s blog. A few days later, another blog was mentioned in a newsletter. This has the title: Open University, and insider’s perspective.

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.