Personal Blogs

On 16 December 2024, I went to a lecture that was given by Professor Bashar Nuseibeh, Head of the OU Software Engineering and Design (SEaD) Research Group, with Alexis Lansbury, TM470 module chair.

What follows is a set of notes that I made during his presentation, which I have edited together into a blog summary which may be helpful for students who are either currently studying TM470 or may be considering studying TM470. The headings that I share are directly from Bashar’s presentation. I have taken the liberty of paraphrasing his points and sharing my own interpretations.

Opening remarks

Bashar opened with some striking remarks. I noted down the following words: “the project is the most exciting thing you can do in your degree; it changed my career” and “it allowed me to put a lot of different things together; I owned the project and what I wanted to do”. Since the project is all about developing what you already know and taking it further, the project “may help you to decide if you really enjoy computing, and what direction to take your skills”.

Bashar offered a further interesting personal reflection: “I discovered that computer systems engineering wasn’t for me; I preferred software rather than hardware”.

What follows is a perspective on software and software research. In particular, there is a summary of the different types of computing research that has been carried out in the school. The idea for sharing a research perspective is simple: if you are looking for an idea for a research project, you might get some ideas from the different types of computing research project that OU academics have been involved with. Bashar also said he would share some tips about how to carry out a project.

Part 1: Software without boundaries

Bashar opened with an important point: software permeates all our lives. Software engineers have the potential to affect the world in different ways, and we have to be responsible in terms of what tools we build, and how those tools are built.

From this starting point Bashar began to share a summary about the evolution of software engineering. Historically, software was considered to be an artefact. Linked to this, there are some key questions: who are we engineering it for, and what is our software to do? This led to the realisation that software requirements are actually pretty important.

There are other questions that we need to ask, such as ‘what kind of world do we want?’ This is an important question since software has an effect on the world. There are implications on users, communities, society and also the environment. When we build software, we also need to ask, ‘is this the kind of software that we really want?’ A related question is, of course, ‘is our software affecting our lives in a way that we care about?’ This question is particularly appropriate and relevant to social media software and products, for example. Software isn’t only about computation; it’s about the way that we live, and the world that we want.

A useful reflection that wasn’t in Bashar’s lecture is that software is, of course, a technology. Any technology can be used for good, or for ill: it can be used to avoid food waste, or it can be used to share fake news stories. Returning to Bashar’s points, if you want to build software for society, it is important to think about that society.

It is also important that software to be adaptable and changeable. In other words, software needs be malleable. In my own experience, work practices (and societal requirements) can change more quickly than software can. Within a complex world of systems that comprise of software and people (which is sometimes referred to as ‘socio-technical systems’) if things go wrong or don’t go as planned, we might not always know who is responsible.

If we consider and engage with society concerns, such as values, ethics and morality, we’re more able to anticipate more about requirements, the needs of users, and the impact of software on others – but we can’t anticipate for everything, so we need to ‘build for evaluation’, and evaluate what we build.

Part 2: TM470 Known knowns

This section was all about some of the key characteristics of Computing and IT project. I noted down the following key points. The Computing and IT project is:

• An opportunity to test, improve and demonstrate what you have learnt.
• An opportunity to personalise your learning.
• Explore what you have learnt can change the world around you for a better.
• An opportunity to challenge the materials that you have read; computing is a fast moving discipline.
• An opportunity to enjoy yourself!

What characterises a TM470 project?

An alternative title for this section could be: what makes for a good TM470 project?

• There is a clear problem that needs to be solved: it shouldn’t be too narrow, and how will you know if you have solved it.
• Computing is an applied discipline, so it should have a strong practical context.
• Your problem can be solved by applying Computing and IT.
• There will be aspects of planning, evaluation and revision; there might be elements of your project (or produce) design that could be extended.

It is easy to define a project that has a very wide scope. Practically speaking, you should always break your problem down into smaller steps. If your project is managed incrementally, you can add to it at a later point.

If your project was too ambitious, remember that you are only assessed on your project report, and in this report, there will be an opportunity to write about how our project was planned (and what changes you might have made) and share a reflective summary (about what you learnt).

Do remember to refer to some key resources: module and subject resources which you can find on the module website, and the project choice forum, which you can used to gain advice from a tutor before you start work on your project.

Types of projects

The module materials describe three main types of projects, development projects, research projects, and evaluation projects. Practically speaking, a project will contain elements from each of these categories. 

A number of active verbs can describe the work that you do within your project: investigating, developing, evaluating and comparing. 

Depending on the exact aim of your project, you could also add the social and practical context to your project to explain why there is the need for something and why you are doing what you are doing.

Identifying your project topic

Here are some useful tips when considering a project topic:

• Play to your strengths; throughout your project you should have some idea what you are good at, and what you enjoy.
• Build in a challenge to your project; identify something you can get your teeth into.
• Imagine a client; think of someone who might use it – you might even want to define some user personas and some accompanying scenarios.
• Consider your academic objectives; what are you going to extend your knowledge of (and how will you show you have done this)?
• Consider defining success criteria; how will you know when you have solved your problem?
• Be ethical and inclusive; inclusivity could be even a topic for your entire project.

Part 3: Software engineering and design group

The final part of the lecture was to give everyone a flavour of the different types of software and software engineering research that takes place within the school.

Broadly speaking, research can be split between technical domains and application domains.

Technology topics can include, and have included: adaptation and autonomy, security and privacy, machine learning, responsible software engineering. Programming languages, software architectures, empirical studies of software development.

Application topics: health and wellbeing, policing, responsible technology, aviation and aerospace, social good and sustainability.

Taking a wider perspective, the OU also has something called a Digital Humanities Research group, which has members from the Faculty of Arts and Social Sciences, and the Knowledge Media Institute.

Closing points

Bashar concluded by sharing the following concise, but helpful points:

• Own it - and enjoy it.
• Frame it - consider the context of use; consider the users, the communities and the society.
• Build it - you need to have an applied computing component.
• Reflect on it – writing about your project in terms of how you tackled it, and what you learnt will get you good marks.

Reflections

I really liked the wide thought provoking perspective that was adopted in Bashar’s lecture, which speaks to the importance of ethics.

After working with software and being a computing educator for a couple of decades, I sometimes wring my hands and become anxious about the impact that my chosen discipline has on individuals, communities and societies.

The ‘computing’ genie, this magical machine of numbers, has escaped, and we’re perpetually finding new ways of doing things with these machines. In turn, these machines inherently reflect back to us our humanity. Software engineers have a responsibility to look further than just their machines, but also to consider the impact on others. The Computing and IT Project module enables consolidation of learning, but also enables the demonstration of how different perspectives are considered.

Acknowledgements

Many thanks to Bashar, Alexis, and also to the TM470 module team. Thanks are also extended to fellow TM470 tutors and TM470 students. Every year, they always inspire me with their work, problem solving, and solutions.