OU blog

Personal Blogs

Christopher Douce

Introducing ICEBERG

Visible to anyone in the world

On 11 July 25, in my capacity as a TM113 module team member, I attended a continuing professional development (CPD) event about something called ICEBERG.

ICEBERG is an abbreviation for Integrated, Collaborative, Engaging, Balanced, Economical, Reflective and Gradual. It is a tool used during learning and curriculum design, and is intended to embody best practice. The session was facilitated by learning designer Paul Astles, who is from the OU unit Learner and Discovery Services (LDS) (I think that is what LDS means).

What follows is a set of notes, which I am sharing with permission. It is hoped they are useful to anyone who is involved in learning design (including my colleagues from TM113 module team). My advance apologies are for anything obvious that I have missed, any mistakes I have included, and how long it has taken to pull together this set of notes. I always endeavour to thoroughly offer citations, but some sentences may have been taken verbatim from a useful presentation that Paul shared during his session.

Considering draft materials

The starting point of the session was also our starting point; our first drafts of our module materials, which are known as a ‘D0’ (or, module materials that we have started to sketch out). To help up think about our D0s, we looked at 3 ICEBERG principles: Integrated, Collaborative, and Engaging. Each principles have a set of ‘corresponding design tips’. Here are the tips that I’ve noted down, which come from Van Ameijde et al. (2018):

  • Integrated: A well-integrated curriculum constitutes a coherent whole where all the parts work together in a meaningful and cohesive way. This means that there is constructive alignment between learning outcomes, assessments, activities and support materials which all contribute effectively to helping students to pass the module.
  • Collaborative: Meaningful student collaboration and communication helps students in engaging in deep learning and making concepts and ideas their own (e.g., Garrison et al., 2001; Johnson & Johnson, 1999). It also serves as a mechanism for social support where students feel part of an active academic community of learners (see Tinto, 1975) which makes it more likely that they are retained.
  • Engaging: An engaging curriculum draws students in and keeps them interested, challenged and enthusiastic about their learning journey. Where the curriculum matches student interests and aligns with their educational and career aspirations, students are more likely to be retained. Using relevant case studies and readings and keeping these up-to-date as well as including a variety of different types of activities contribute to an engaging curriculum.

We were asked to look at a bit of material that was content heavy and were asked a question: how do we relate our draft materials to these points on the framework?

During our discussions, I made a couple of notes. Regarding Integrative, scene setting is important, since it adds concept. Collaborative can be useful, particularly a bit later on in the module when tools are introduced (collaboration is really important skill within software engineering). Also, Engaging can and should directly align with educational and career aspirations.

A key point that I took away from this part of the session was the need to emphasise ‘the people bit’. Also, since TM113 has three key themes, a question I had was ‘how do we integrate them together?’ There are also, of course, other important themes that are important to the module, such as employability, skills development, ethics and sustainability. In some respects, software engineering can be a linking theme, since it is all about people, tools, management of complexity, and communication.

The student learning journey

After a short break, the next part of the session related to the ‘student learning journey’. We again returned to the definitions of Van Ameijde et al. (2018):

  • Balanced: Balanced in this context refers to the workload that students face when studying the curriculum and the extent that this workload is well-paced and evenly distributed. Research has pointed out a negative correlation between average weekly workload and student outcomes, including satisfaction and pass rates, making it particularly important that we don’t overload students whilst keeping the workload appropriate for the level of study.
  • Economical: Economical refers to the extent to which a module or qualification is efficient in delivering the learning outcomes without providing too much additional material which. There might be a temptation to provide students with an overwhelming array of interesting facts, ideas, theories and concepts in a given subject area.
  • Reflective: For students to effectively pass a module and engage in deep learning, it is important that they are able to reflect on their learning and study progress and have the time and space to do so. This includes regular opportunities for students to test their understanding through, for instance, self-assessment questions, formative quizzes and iCMAs. It also includes opportunities for students to reflect on their learning practices and progress, and set goals. Such opportunities for reflection and feedback help keep students engaged with the curriculum and makes retention more likely.

Of these three principles, one of them is causing me a mild amount of worry: the ‘economical’ principal. There is an inherent challenge within pedagogy, which is: to learn some higher level concepts, you may need to learn a lot of lower level concepts. This learning of ‘lots of useful stuff’ can be difficult. There is also an important related question, which is: where do tell students about all these lower level concepts, if we’re being asked to do it in a cognitively economically way? Interesting facts, ideas and theories can be useful.

We didn’t get the chance to have a chat about ‘G’, which is Gradual. Also drawing on Van Ameijde et al. (2018):

  • Gradual: In an effective learning journey, students will gradually encounter increasingly complex and challenging concepts, ideas, materials, tasks and skills development. Where knowledge, skills and assessments all occur over a manageable gradient which builds on acquired knowledge, provides timely opportunities to learn and practice study skills and prepares them achieving the defined learning outcomes, it is more likely that students will not be overwhelmed and therefore more likely be retained.

The key point that I’ve taken away from this bit is the importance of practice (relevant ‘student answered questions’ which can be presented in the module materials)

Resources

During this session (and a related session) links to a number of useful resources were shared. These include:

And, of course, the article that was mentioned earlier:

Reflections

During this session, we didn’t have much time to apply the framework to our module materials, since we still had much to figure out. Not only were we still figuring out ICEBERG, we were also still figuring out the nature and form of our module materials.

One question I did have of ICEBERG was: where is the tutor in all this? I think the answer is that the tutor is implicitly embedded within all parts of the framework. Tutors, of course, make module materials come alive. In turn, they can magnify whatever learning design decisions have been made by the module team.

I get the impression that ICEBERG is a tool that specifically applies to individual modules, rather than qualifications – or, in other words, groups of modules. Can ICEBERG be applied to qualifications?  Referring to the original article by Van Ameijde et al., the definition of economical ‘refers to the extent to which a course or qualification is efficient in delivering the learning outcomes’ which suggest that it may well have a wider role. An interesting research question could be: ‘how might all the principles of ICEBERG be used to analyse the learning design of qualifications from different faculties?’ In the meantime, I’m going to concentrate on TM113.

Acknowledgements

Many thanks to Paul for his useful presentation, LDS, and all colleagues who have contributed to the development of ICEBERG. Thanks are also extended to fellow TM113 colleagues who attended the session.

Permalink Add your comment
Share post
Christopher Douce

Preparing to tutor TM113 Computing fundamentals 2

Visible to anyone in the world

One of the new level 1 computing modules on the BSc (Honours) Computer Science with Artificial Intelligence qualification goes by the catchy title TM113 Computing fundamentals 2: programming, databases, software engineering. It accompanies TM110 Computing fundamentals 1: concepts and Python programming.

As suggested by its title, this new module has three strands. What follows are a set of links and resources that may be useful to anyone who might be potentially interested in tutoring this module. If you have tutored TM112, the Python element will be familiar to you, but the software engineering and databases less familiar (although you may be familiar with databases, if have had any awareness of TM254 Managing IT: the why, the what and the how).

Programming

If you are familiar with software development but not with Python, the following OpenLearn and Cisco resources might be useful:

Databases

Within OpenLearn, there is the following:

Another useful resource that has been mentioned is:

Software engineering

Turning to the theme of software engineering, there are a couple of OpenLearn resources that have been derived from existing OU modules. 

Other resources

If you have never tutored an OU module before, the following module can be very helpful:

If you are an existing tutor, a really useful thing to do is to take advantage of the university’s fee waiver.

Reflections

The OpenLearn resources can certain be useful, and you can demonstrate awareness of the materials by gathering an informal badge (which can be added to a CV). What has really helped me to become a better tutor has been the fee waiver. This could be applied to computing modules, or modules from other faculties.

Acknowledgments

Thanks are extended to Anthony Johnson who shared some of those resources during a very early module team meeting.

Permalink 1 comment (latest comment by Darren Menachem Drapkin, Sunday, 8 June 2025, 20:35)
Share post
Christopher Douce

Some notes about agile practices in software engineering

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 1 Apr 2025, 21:06

Software engineering is done by people, but what people do to build software depends on the nature of software that is to be created. The culture of individuals, technologies and organisations also plays an important role too.

At the turn of the century, there was a new idea about how to build software; something called agile development. This led to the creation of something called the Manifesto for Agile Software Development If you’re interested in software development and want to know something about what ‘agile’ means, you need to have a look at the manifesto.

I first learnt about agile through something called eXtreme Programming (Wikipedia), and then something called Scrum (Wikipedia) (Don’t use Wikipedia in your TMAs; always use official references). In my eyes, the notable characteristic about agile (or Agile; there’s a difference between small ‘a’ agile, and large ‘A’ agile) is that it is all about people. Agile (in its different forms) helps to establish rituals which can, in turn, help software engineers to talk about that ‘invisible stuff’ which is software.

I recently asked a colleague, Advait Deshpande, who was the chair of an agile practices microcredential what the latest trends were in agile software development. He was kind enough to share links to some interesting articles and resources.

Articles about agile

 Here are some review articles that might be useful to anyone who is starting to study agile:

Edison, H., Wang, X., & Conboy, K. (2021). Comparing methods for large-scale agile software development: A systematic literature review. IEEE Transactions on Software Engineering, 48(8), 2709-2731. Available at https://ieeexplore.ieee.org/abstract/document/9387593/

Vallon, R., da Silva Estácio, B. J., Prikladnicki, R., & Grechenig, T. (2018). Systematic literature review on agile practices in global software development. Information and Software Technology, 96, 161-180. Available at https://www.sciencedirect.com/science/article/pii/S0950584917302975

Other resources

Advait also shared the following two links, which he gives me permission to share here: UK Government: Agile delivery - Agile tools and techniques.

The notion of ‘agile’ has moved beyond software, but to business. It is important to distinguish between the two. This second link emphasises what agile might mean within a business context: Agile Business Consortium: Business Agility.

Post (or peak) agile

Once, agile was the new thing on the block. Now agile has become mainstream. An accompanying question is: have we reached post (or peak) agile? Also, what comes next? One of the criticisms of agile is that it is best suited to smaller teams, which puts a limit to how it can be applied to bigger projects. There have been several attempts to address this:

Advait directed me to a talk that was hosted on YouTube that had a provocative title:

I know Dave Thomas from a book I have on my shelf at home; a book called ‘the pragmatic programmer’ – it is a good read, and is packed filled with some very practical advice. His talk about agile is worth a watch. He presents a critical view of the ‘agile industry’ in a humorous and engaging way. It is worth a watch. He talks about the origins of the agile manifesto, as well as ‘large agile’. An important point is that when thinking about how to create software, we need to think critically too.

Reflections

When I was learning about software engineering as an undergraduate, I was introduced to something called the software development lifecycle (or SDLC). There are different models; there’s a waterfall model, a spiral model, and there was something called SSADM which bored me to hears. It was only after I graduated that I later learnt about agile in all different guises.

When I started working as a software engineer, the company that I worked for didn’t have a software development process, so we had to make one. Culture and experience are themes that can influence decisions about what is done. I was lucky enough to work with someone who had had a lot of experience, for which I was really thankful for.

We set up policies and processes. We also applied techniques that had an agile flavour, bits of pair programming, and aspects of test driven development. Our processes needed to work for both the products and the people who were developing the software. We needed to be pragmatic to get things done.

Acknowledgements

Thanks are extended to Advait Deshpande. I really appreciated the chat and all the links he shared.

Permalink
Share post
Christopher Douce

Introducing the R88 qualification: Computer Science with Artificial Intelligence

Visible to anyone in the world

For my sins, I’ve found myself on four module teams; two in production (TM113, TM253) and two in presentation (TM354, and TM470). The two production modules are a part of an important new qualification the university is producing.

What follows is a set of notes I’ve made that relates to this new qualification. For the official word about the R88, my recommendation is to have a look at the R88 qualification webpage

Firstly, a bit of context: a full time degree is made up of 360 academic credits. The equivalent of one year of study at a brick university is 120 credits. The OU also reflects this, and has three levels of study. Degree classification scores are calculated from results from levels 2 and 3. Level 1 is about skills and knowledge development, but level 1 modules do need to be passed. All modules on this qualification are 30 credits. 

Here is a quick summary of what I know.

Level 1

TM110 Computing fundamentals 1: concepts and Python programming

This is the first module to study. It is likely to include some maths just to prepare everyone for the first maths module that follows. Unlike TM111, it makes use of a textual programming language from the outset. Different themes are interleaved with each other. There are two TMAs and an end of module TMA. 

TM113 Computing fundamentals 2: programming, databases, software engineering

The first presentation of this module is planned for October 2026. This obviously has three related components, and like TM110, the topics are interleaved with each other. This uses the same programming language as before, but uses a different programming environment: Visual Studio Code.  Like all these modules, there is a focus on skills development and employability.

TM129 Technologies in practice

This module has three ten point sections: a bit about robotics and AI, a section about virtual machines and the Linux operating system, and a bit about networking. In AI machines will, invariably need to talk with each other. Knowing something about networking is important.

MST124 Essential mathematics 1

This module is produced by the School of Maths and Stats. It builds on ideas that were introduced in TM110.

Level 2

TM253 Programming and software engineering

This new module is planned for October 2027. This picks up where TM113 left off. It is likely to introduce students to a programming language that is different from Java, and is likely to help students do understand more about software design and architecture. There is also likely to be a significant emphasis on object-oriented software (but other programming paradigms might also get mentioned).

TM258 Introduction to machine learning and artificial intelligence

This is a new module which introduces a range of different AI techniques. I know nothing more than this at the moment, but I’ll hazard a guess to say that ‘search’ is likely to be covered.

M269 Algorithms, data structures and computability

It could be argued that M269 is the most computer science of all these computer science modules. It covers the fundamentals, which means searching and sorting.

M249 Practical modern statistics

Stats is important within machine learning (as well as computer science). The module description says that it covers “time series, multivariate analysis, and Bayesian statistics”. 

Level 3

TM342 Investigating intelligence and ethics

As a postgrad student, I studied a module that had the title ‘natural and artificial intelligence’ that was led by the school of psychology. It was a subject that I really enjoyed. I’m looking forward to learning more about what is going to be covered in this module.

TM343 Artificial intelligence in practice

I don’t know anything about this module, other than I know it is going to be hands on, and may well cover the subject of natural language processing (in some way or another).

TM358 Machine learning and artificial intelligence

This is an existing module which is a part of the BSc (Honours) Data Science qualification. The module description says: “you’ll learn about various machine learning techniques but concentrate on deep neural learning”. In other words, neural networks.

TM470 The computing and IT project

This is what is called a capstone module. Students who take this programme are required to complete a project that is likely to have an AI flavour to it. This is also one of the modules that I tutor. I’ve written quite a few articles about TM470 in this blog.

Other qualifications

There are a number of other related qualifications which are worth knowing about:

Reflections

It’s really exciting to be working on the software engineering bit of two new modules. 

In some ways, this takes me back to my undergraduate days where I studied computer science. On the programme, there was a single AI module (which was a third year module) which I quite enjoyed. Things have, of course, moved on a huge amount; there are new techniques and new technologies. I was only taught about symbolic AI, and nothing about statistical approaches. I only came across neural networks as a postgraduate student in the mid-1990s.

It is interesting to see how mathematics is introduced in this programme. It begins slowly with material in TM110. This reflects my own experience as an undergrad. I never studied maths at A or AS level, so I went to a ‘gentle start’ class. This led onto a 'discrete mathematics' class, which could be termed ‘bits of maths that could be useful for those studying computer science’. I didn’t like it much. To this day I remember proofs, matrices (which is useful for computer graphics), and a lot of probability (lots of questions about playing cards). The equivalent of my discrete maths class is, of course, MST124. Given the importance of statistics in machine learning, there is then M249. 

It’s also important to reflect that software engineering has changed since I studied it. Computing is now everywhere, and that is a characteristic that makes it such an interesting subject. It is in your devices, in your appliances, and in the cloud. A personal objective is to work with others to create materials that not only give the materials industrial relevance, but also to share with students what it means to study software engineering as an academic subject.

Looking back to my time as an undergraduate, one of the modules that I recognise most clearly in M269, the data structures and algorithms module. Some fundamentals never change. What does change is how they are used, and how they are realised. I remember reciting Dijkstra’s algorithm in an exam, just as if it were an ode. I also remember getting a bit baffled by the big O notation, which features in M269.

One of the areas that I know I’m weak on is statistics. When I’m through studying my current module, I may well find my way back to maths.

Disclaimers

This qualification (along with all the others) is subject to change and development.

Acknowledgements

Acknowledgements are due to the School of Computing and Communications directors of teaching who have played an important role is establishing this new qualification.

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