OU blog

Personal Blogs

Christopher Douce

Degree apprenticeship: DTS Themes

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 5 Mar 2024, 08:44

The Open University offers a Computing undergraduate degree apprenticeship for England and Wales. The English degree apprenticeship is known as the Digital and Technology Solutions Professional Degree Apprenticeship.

The current version of the standard, which is defined by the institute for apprenticeships is version 1.2 (Institute for apprenticeships)

Apprentices need to pass two elements: their degree bit (the academic element), and the apprenticeship (the work based learning element). Both of these elements are broken down into smaller parts. The academic bit is broken down into academic modules. The apprenticeship is defined in terms of knowledge, skills and behaviour (KSB) attributes which are, in turn, grouped together into sets of themes. To gain their apprenticeship apprentices must provide evidence of being able to satisfy all the KSBs which make up the themes. 

Passing the apprenticeship bit is a two-step process. Apprentices must demonstrate competency across these themes before entering what is called a ‘gateway’ process, which takes them to something that is called an endpoint assessment (EPA). The EPA is a professional conversation where the apprentice speaks with an assessor.

What follows is a summary of the themes for both parts of one apprenticeship pathway: the software engineering professional pathway. Some themes can only attract what could be called a pass grade, whereas others can attract a distinction grade. For concision, only the criteria that relates to the pass are highlighted here. A further note is that the themes are split into two bits: a core set of themes, and themes that relate to a specific pathway. For detailed information, do refer to the DTS standard.

A further note is that all the themes highlighted here, and can be found within the standard, are also mentioned within the apprenticeship ePortfolio tool (which is known as MKM). Where there is a heading, there will also be a space to record evidence.

Towards the end of this summary, there is some guidance about the recording of evidence. This is important; without evidence it is not possible to pass through the gateway process, or to complete the final end point assessment.

DTS apprenticeship themes

Core themes

The Organisational Context

Reviews the roles, functions and activities relevant to technology solutions within an organisation. (K7)

Core Technical Concepts

Critically evaluates the nature and scope of common vulnerabilities in digital and technology solutions (K11)

Explains core technical concepts for digital and technology solutions, including:

  • The approaches and techniques used throughout the digital and technology solution lifecycle and their applicability to an organisation’s standards and pre-existing tools. (K6)
  • Data gathering, data management, and data analysis. (K12/K14)
  • Computer networking concepts. (K16)

Applied Technical Solutions

Demonstrates the use of core technical concepts for digital and technology solutions, including:

  • Initiate, design, code, test and debug a software component for a digital and technology solution. (S4)
  • Security and resilience techniques. (S9)
  • Initiates, designs, implements and debugs a data product for a digital and technology solution. (S10)
  • Plans, designs and manages simple computer networks. (S12)
  • Applies the principles of data analysis for digital and technology solutions. (K13/S11)

Leading and Working Together

Explains how teams work effectively to produce a digital and technology solution applying relevant organisational theories using up to date awareness of trends and innovations. (K8/S7/B4/B6/B7)

Describes the concepts and principles of leadership and management as they relate to their role and how they apply them. (K9/K10/S8)

Social Infrastructure - Legal, Ethical and Sustainability

Applies relevant legal, ethical, social and professional standards to digital and technology solutions considering both technical and non-technical audiences and in line with organisational guidelines. (K19/S15/B1/B2/B5)

Explains sustainable development approaches within digital technologies as they relate to their role including diversity and inclusion. (K20/B8)

Software Engineer themes

Underlying Principles

Describes scenarios covering all stages of a development lifecycle, identifying techniques and methods are applied in each case. (K21/SEK1)

Explains the principles of a range of development techniques, for each stage of the software development cycle that produce artefacts and the contexts in which they can be applied. (K22/SEK2)

Explains the principles of a range of development methods and approaches and the contexts in which they can be applied. (K23/SEK3)

Technical Solutions

Describes. how to interpret and implement a design, compliant with functional, non-functional and security requirements. (K24/SEK4)

Describes how tools that support teamwork can be used effectively. (K28/SEK8)

Innovation and Response

Describes how they respond to changing priorities and problems arising within software engineering projects by making revised recommendations, and adapting plans as necessary, to fit the scenario being investigated. (S20/SES5)

Explains how they determine, refine, adapt and use appropriate software engineering methods, approaches and techniques to evaluate software engineering project outcomes. (S21/SES6)

Legal, Ethics and Landscape

Describes how they extend and update software development knowledge with evidence from professional and academic sources by undertaking appropriate research to inform best practice and lead improvements in the organisation. (S23/SES8)

Preparing for the End Point Assessment

Towards the end of the apprenticeships, apprentices need to complete a significant work-based project. As well as writing a 6k word report, there must be evidence collected that relates to the following themes.

Core themes

The Organisational Context

Identifies the role digital technology solutions play in gaining a competitive advantage by adapting and exploiting them (K1)

Explains the principles of strategic decision making concerning the acquisition or development of digital and technology solutions. (K2)

Project Requirements

Analyses relevant evidence to produce a proposal for a digital and technology based project in line with legal, ethical and regulatory requirements whilst ensuring the protection of personal data, safety and security (S3/B3)

Project Planning and Resources

Produces a project plan which estimates risks and opportunities and determines mitigation strategies. (K3/S2)

Evaluates appropriate techniques and approaches that are used in creating a business case (K4)

The project applies techniques to estimate cost and time resource constraints. (K15)

Researches information on innovative technologies/approaches and investigates and evaluates them in the development of a digital and technology solution. (S14)

Solution Proposal

Analyses the business problem behind the project proposal to identify the role of digital and technology solutions. (S1)

Project Delivery

Carries out the identified solution proposal utilising a range of digital tools and standard approaches. (K5/S5)

Manages the project delivery to achieve digital and technology solutions. (S6)

Project Evaluation

Justifies their methods of research and evaluation which determined the selection of digital and technology solutions identified for the project. (K18)

Presents an overview of the project to appropriate stakeholders using appropriate language and style. (K17/S13/B5)    

Software Engineer themes

Technical Solutions

Analyses the factors affecting product quality and the approaches controlling them throughout the project development process. (K25/SEK5).

Selects and applies software tools appropriate to the Software Engineering project solution. (K26/SEK6)

Outlines approaches to the interpretation and use of artefacts. (K27/SEK7)

Innovation and Response

Identifies and defines a non-routine, unspecified software engineering problem. (S16/SES1)  

Recommends a software engineering solution that is appropriate for the project brief. (S17/SES2)

Selects and applies analysis methods, approaches and techniques in software engineering projects to deliver an outcome that meets requirements. (S18/SES3)

Demonstrates how they implement software engineering projects using appropriate software engineering methods, approaches and techniques. (S19/SES4)

Evaluates their selection of approach, methodology, analysis and outcomes to identify both lessons learned and recommendations for improvements to future projects software engineering projects. (S22/SES7)

Evidence for the themes

Evidence for all these themes must be uploaded to the apprenticeship ePortfolio. There is two types of evidence: witness statements, or evidence through the academic study. For the apprenticeship element, witness statements are considered to be a stronger form of evidence than completing tutor marked assessments. 

Witness statements can be prepared by a line manager, or a delegated mentor of colleague. They present a narrative summary of what an apprentice has done or achieved and should be anything between 100 and 150 words. These statements should be uploaded to the apprentice’s ePortfolio tool by the apprentice.

Acknowledgments

The key reference for this post is, of course, the DTS standard. The text for some of these headings have been drawn from the MKM ePortfolio.

Permalink Add your comment
Share post
Christopher Douce

Understanding Moodle Themes

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 July 2010, 18:27

A section of a Moodle screen showing three icons: forums, lessons and resources

This post is about the journey that I followed trying to understand Moodle Themes.  Moodle Themes are pieces of programming magic that change the visual appearance of your Moodle installation.

If you download Moodle and play around with it, you might eventually arrive at a decision that it might be useful within your institution.  You might hold a meeting with senior management where you may say, 'I think it's a good idea if we try to use this thing call Moodle to host some of our courses'.  After answering some difficult questions about maintenance and development costs, your managers might say, 'okay, you've convinced us... let's give it a go, I'll give you a budget'

Other than figuring out which operating system and database to use and where (and how) your instance of Moodle is to be hosted, one of the first development activities you will have to do is make sure that your Moodle system is 'on brand', i.e. it's visual appearance should reflect the institution that you work for.

This is pretty much what I have to do.  I have to try and make my 'vanilla' (unmodified) version of Moodle blend in with a set of existing web pages that have been built as a part of a research project I'm working on.  Other development teams within my university have already done something similar with their production version of Moodle, but I need to tackle this problem myself.

I start with a couple of questions: what makes up a theme and how might you go about changing one or maybe even making a new one?

Resources galore

Before I can answer these questions I needed to find something to read, and it didn't take a lot of browsing to find a number of potentially useful resources.

The first page that I discovered was a link to over one hundred different themes thanks to the Database of Moodle Themes.  Perhaps I shouldn't be so surprised given the number of Moodle installations that are out there in the world.

I soon discovered the Themes documentation pages and a number of other related links, including a set of themes related FAQs and dedicated discussion forum.

The Themes documentation link (for a Themes novice) seems to be the most useful.  One of the sections says that themes can be delivered in zip files.  You download them, unzip them and place the contents in the /moodle/theme directory, and then click on some admin tools to activate it.  This sounds almost too easy!

Towards Code

Being someone who likes to view code I thought it might be useful to look at some of the magic that makes Moodle themes work.  To do this, I chose a random theme from the themes database and unzipped a folder to my desktop.  To begin to make sense of it properly, I felt that it might be a good idea to compare this random theme against one that already existed.  This made me answer, 'which theme is used by default?'

To answer this question, I logged onto my local instance of Moodle (which was running on my local machine, localhost) as an administrator.  After struggling to remember my username and password, I clicked on the Administration link, followed Appearance, Themes and then on the Theme Selector link (because I couldn't really make sense of the Theme Settings options).

I quite like the Theme Selector page.  It presents all the different themes that have been installed.  The current theme that is selected is highlighted by a black square.  The one that was selected by default (in the case of my installation - I cannot remember whether I changed it) was named standardwhite.

I delve into the Moodle code area, take a copy of standardwhite and placed it alongside the one I have randomly downloaded and started poking around.

Looking at code

I noticed similarities and differences.  The similarities are that some of the filenames are the same.  I see two PHP files, styles and config, followed by two html files, header and footer.  There seems to be a CSS file (Wikipedia) in both themes (but the downloaded theme contains a few more than the default theme).  I also notice a graphics file called gradient in the default theme (which is a jpg), and a png graphics file in the other one.  A big difference lies was that the theme I have downloaded contains a directory which seems to contain a bunch of graphic files.

Before deciding I'm terribly confused, I decide to do one more thing: open up both of the PHP files to see what they contain.

In a config script, I see assignments to a variable called $THEME.  Different attributes appear to do different kinds of magic.  Looking in the styles script, a comment tells me that 'there should be no need to modify this file'.  It seems to do something that relates to the presentation of a CSS file.  That is good enough for me!

I have a quick peek into the header and the footer html files.  It looks like these are templates (of some kind) that are filled out using the contents of some PHP variables.  Obviously the pages that the Moodle code creates have a pretty well defined structure, and presumably this structure is documented somewhere.  This is perhaps something I might need to remember later.

Return to the documentation

At this point, I roughly (think) I know what a Theme comprises: some magic scripts which define some variables (and some other stuff), some header and footer scripts which look at bit like templates, a CSS file of some kind, perhaps a graphic (which could be used by the CSS file?) and maybe a bunch of graphics that replace those that are used in Moodle by default.

If this is my current understanding, can I now find the documentation easier to understand?

I soon uncover two further pages: Make your own Theme and Creating a Custom Theme (the first link seems to be easier to understand).  A couple of clicks takes me to a documentation page called Theme config file which goes some way to explaining the variables that I have touched upon above.

The final comment in the Creating a Custom Theme page was instructive.  Other than saying that you can't change everything, if you want to make your site look like an existing site, it might be a good idea to make use of a tool called Firebug which is a plug in for your Firefox browser.

With Firebug, you can browse to a web page of your choice and uncover what CSS definitions have been used to build its visual appearance.  I've used Firebug before, and mentioning that it is a good tool is certainly a good piece of advice.  The Moodle developers have also been kind enough to prepare a CSS FAQ which is certainly worth a look.

Although I could have tried to create a new theme from scratch, I'm in a lucky position since one of my colleagues has already created a customised theme for a custom instance of Moodle.

Towards testing things out

To test things out, I copy of my customised theme into my local 'themes' directory and hit refresh on my browser.  I then select my newly installed theme and everything starts to go wrong.  The action of selecting a theme seemed to have rendered my local copy of Moodle useless since only a tiny fraction of a HTML page is created (which I see by viewing the code the browser receives).

A problem seems to have been created since the version of Moodle that I am using and the structure of the theme that I have transferred are not completely compatible with each other.  I need to go back to my default theme! But how do I do this? Where are the theme settings held?

My first guess is in the database.  I open up a front end to the MySQL database that is running on my PC, using a tool called SqlYog.  I eyeball the contents of the database to see if there's anything I can use.  I discover a 'config' table, but this doesn't tell me much.  I did, however, discover that there is a theme setting within individual courses as well as individual users.

I turn my attention towards the code by first looking at the code within the themes directory and I soon find myself fruitlessly searching through different libraries.  Finding a simple answer may necessitate spending quite a bit of time.

To get things working again, you sometimes have to cheat.  I renamed my theme to something totally different and refreshed my Moodle page.  Moodle then had no choice but to return to its default setting (which was, again, 'standardwhite').

Incrementally merging

I have two themes: one theme that I want to use but doesn't work (because it has been modified for a customised version of Moodle), and another theme that does work which I don't want to use.  When I'm faced with this situation, I try to get 'code to speak to me' by incrementally taking the one that works and making it look like the one that doesn't work.  I find I can really understand stuff when things stop working!

I begin by looking at the files and then the contents of the files.  The first thing that strikes me is that the header and footer files are quite different.  There seems to be quite a bit more happening in the customised theme when compared to the standard theme.  A step at a time I move files across and test, beginning with the favicon, then the config file, and finally the pix's.  I discover that both themes require the use of a CSS file that is contained within the standard theme directory.

The effect of moving files around seems to produce, more or less, what I was after.  The interactive 'side blocks' (particularly the show/hide buttons) are not presented as they should, but further searching reveals a magic variable, allowuserblockhiding that can be used to control this functionality.

Moodle version 2

A question to complete this post is: what is the situation regarding Moodle version 2.0?  This is a development that I have heard about for some time, but I have not heard recent any announcements regaring its expected release.  After a quick search, I reacquaint myself with something called the Moodle Roadmap.

This appears to state that there will be a beta release of V2 by the end of 2009, followed by some months of testing before a final release.  Judging by the planning document, there appears to be quite a lot more coding to do (nearly four hundred days of development time to go, so we should expect some delays).

I appreciate that giving opinion is certainly a lot easier than giving code, so I hope that Moodlers who read this section will forgive me.  I personally hope that the code for the next version is a lot cleaner.  Since the developers are forced to move to PHP version 5, I hope they will choose to adopt its object-oriented features which can help developers to form clearer (less leaky) abstractions.

In a perfect world, developers should be able to look at a screenful of code and be able to describe, more or less, what that section of code does without having to look at other code (providing, of course, they more or less have an understanding of what the product does).  From what I have seen so far in version 1.9, there is a long way to go to, but I'm certainly looking forward to learning how things have moved on in version 2.0.

Wrap-up

It's great that the developers of Moodle have designed it in such a way that it is 'themeable' (if there is such a word).  In some respects, I was surprised to discover things were not as difficult as I had expected.  Whilst, in some ways, going directly to the code and looking what is there may be a daunting challenge, it is one that I certainly recommend doing.

There's a whole lot more to the issue of Moodle themes.  I haven't touched upon the structure of Moodle pages and how they relate to elements in stylesheets, for example.  I'll leave this challenge for another day!

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: 2338255