OU blog

Personal Blogs

Christopher Douce

Software Matters: Some thoughts on software engineering TM470 projects

Visible to anyone in the world
Edited by Christopher Douce, Friday, 3 Jan 2025, 17:23

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.

Permalink 2 comments (latest comment by Christopher Douce, Friday, 3 Jan 2025, 17:22)
Share post
Christopher Douce

European Innovation Academy

Visible to anyone in the world

In July I went to something called the European Innovation Academy. The idea behind the academy was to get groups of students together with the intention of creating a product or solution to a problem.  (By product, think of ‘mobile app’ or digital service of some kind).  As a part of a three week programme, students were taught about what is meant by innovation, introduced to concepts such as user centred design and different business models, before being presented with some talks about how to further develop their ideas.  At the end of the third week, participants were encouraged to write a short pitch to sell their product, solution or service, to potential investors, with a view to securing further funding.

Making skills visible

A couple of months earlier, I went to a UK Higher Education Academy event (blog) that was all about how best to go about the teaching of programming to those students who want to learn how to develop software for mobile devices.  What struck me was the point that if students want to get ahead, a really good idea is to create some kind of product that could be sold through vendor app stores (such as Google Play, for instance).  The advantage of doing this is that you advertise your skills in a very direct way and can clearly describe what you’ve done and achieved on your CV.

A substantial part of the academy was all about creating something.  As far as I understand it, there was time on the programme to allow students to not only learn about different platforms and tools, but also time to try (as best as possible) to create some prototype software that could be demonstrated to others.  Creating an artefact, as far as I could see, was considered to be a really important aspect.

Taking software further

A number of years ago, I used to have a job as a professional software developer.  It was thinking back to these times that I asked myself a fundamental question: ‘what on earth could I potentially say to the participants to help them appreciate some of the challenges inherent in creating software systems and products?’  I’ll put my hand up and say that I’ve always had one foot more firmly in the technology side of things than the business side.

I struck on an idea to not only talk about software, but also some of the more human sides of software development.  Software is, of course, a creative product, and there are things that we can do (in terms of structuring things to help people work together) to get things done. The things that we choose to do, however, are fundamentally affected by the types of product that we’re creating.  Some products or solutions require us to use different methods.

So, what did I talk about?  I had three hours to fill!  Below is a quick summary of what I considered to be the highlights.  The participants might have different views.

Challenges

First of all, I asked the groups some questions to help them consider what they considered to be the most important or significant challenges that they felt they needed to address.  When you’re going head long into a development, I thought it might be useful to find a bit of time to step back and ask the participants about the problems that they were facing, and whether they might be able to share some advice about how to solve some of their problems and how to manage some of the risks that each project group might face.

Interaction design

Since the participants were creating prototypes, I talked a bit about the process of interaction design and the ideas of different types of prototypes (i.e. horizontal prototypes and vertical prototypes).  I also spoke about the necessity to consider the user, the task and the environment, since considering all these aspects are really important when considering the final usability of a system (and usability will fundamentally influence whether or not a product or idea is accepted).

Processes

You could argue that interaction design is all about process.  I also introduced the idea of software development processes, notably, agile development which emphasises regular and constant communication between both developers and stakeholders.  I made the fundamental point that constant communication is a necessity since software is an intangible product; the only way to make software real is to talk about it.  Agile methods facilitates that talking.

Testing

In some software development cultures (and each culture is slightly different), software testing can be an integral component, but it is a subject that can be very easily overlooked.  Software testing is a pretty big subject, covering a huge variety of different techniques and approaches.  When we move from the small to the large, we fundamentally need to make sure that things work as they should be (since if things go wrong, then our customers don’t get a good customer experience).  I spoke about two important aspects to testing (and highlighted a bunch of others).  These were: different types of usability testing, and test driven development.

Abstraction

Abstraction is, perhaps, one of the most important and fundamental concepts in computing.  An abstraction could be described as an essence of a concept which doesn’t contain any superfluous detail or ideas.  When our abstractions are right, our software becomes easy to work with.  Abstractions represent a really important way to manage complexity.  We need abstractions within our code because programmers can only deal with a limited amount of stuff and connections between parts of a program at any one time.

One approach to creating software is to create our code in different layers.  Software developers constantly use code libraries as well as consume data from other information sources.   When talking about abstractions I also introduced the idea of design patterns.  These represent templates of common solutions to coding (and software design) problems that have been shown to occur time and time again.   Coming back to the point of processes and the need for constant communication, if we can put a name against our various types of abstraction (which is something that the concept of a design pattern does for us), this can make the communication between developers a whole lot easier.

Version management

When you’re working with code things can get very complicated very quickly.  There’s multiple files, different versions of libraries, you might include a whole bunch of different graphics or change database structures or web services... and then the bugs start to creep in and give both you (and your customers) a whole set of headaches.

I felt that it was important to saying something about version control and configuration management.  When we’re in the zone of high productivity (when we’re at one with the problem and our tools), creating new products and services, we can quickly lose our own history in the path of continual change.  Version management systems (or whatever you choose to call them) enable some aspects of development history to be captured and saved.  One challenge that we need to be aware of is that the use of these tools requires discipline.

Technologies

To create any software of substance, you’ve got to use some technology that already exists.  If you’re creating apps, you’re going to use some kind of integrated development environment (which consists of programming languages, debuggers, code profilers, and a whole bunch of other goodies).  Another subject that I wanted to mention was that there is a whole set of other technologies that developers could use.

One really useful concept is the software framework.  In essence, frameworks can be considered as a set of high level abstractions that allow developer to more efficiently solve common problems.  A framework can allow you to work more quickly (and hopefully more efficiently) by building on the work of other developers.  Two challenges include: figuring out which framework to choose (and whether it really would help you or not), and then understanding how a framework might work.

Another broad set of technologies that developers might utilise is web services.  Web services can now be used to store data and host applications.  Rather than having to manage their own servers and systems, an app developer might be able to use services that have been developed and deployed by other companies.  The challenge lies in figuring out what they are and making choices between different possibilities.

Community

In terms of software, the word community can be interpreted and understood in a number of different ways.  There might be a user community or a developer community, for instance.  You might want to share information about an emerging product through blogs and direct interested users to these updates through Twitter updates.  My point was that community, whatever form this might take, is fundamentally important.  Although technology is a necessity, technology won’t develop, change or improve if there isn’t a community of users or developers that are keen on using or enhancing a system.

Another notion of community lies with the area of open source software.  I understand that during earlier parts of the academy, students were introduced to different types of business models.  Some business models work through the use, application and development of open source software.  In some situations, open sourcing a development might be a part of a wider strategy.  If so, then it is fundamentally important to consider how to support and nurture a community that makes use of any software (or service) that is made available to others.

A final connection to the notion of community that came to mind was the importance of partnerships. Creating effective software and services is something that requires a lot of specialist skills and expertise. I remember one story from a HEA event that I attended some time ago.  I remember being shown an example, a collaboration between a graphics artist and a programmer, that led to the development of a really nice product; an interesting and playable mobile game.  A fundamental point was that sometimes, the best work that we do is when we work with others. 

Reflections

A personal reflection is that putting together these series of talks seemed to take up quite a lot of time, but it was pretty good fun thinking about what to include and what not to include.  I asked myself a really simple question, which was, ‘if I was there, being a delegate as a part of this programme, what would I really want to know?’  In retrospect, I fear I might have perhaps crammed in too much material, perhaps covering too many ideas or too many technologies in what was a very short space of time.  On the other hand, I think this was the point of the programme: to introduce people to new concepts and ideas, and to allow those on the programme to be fundamentally challenged.

One thing that struck me was that some of the teams gave the impression that they needed more developers; more people who were able to use the software development environment to create new products.  If you’ve never seen an integrated development environment before, the learning curve is practically vertical - it takes time to appreciate their intricacies and idiosyncratic ways.   Three weeks is an impossibly short time to come up with a new innovative idea that actually does something if working with technology isn’t something that you do all the time.

Since I attended the programme during the third week, I wanted to positively tantalise the participants.  I wanted to say to them, ‘you know, all this tech that you’re playing with, and all these cool prototypes that you’re creating using tools that you’ve never used before? Well… this is only the beginning – there’s a whole bigger world of software tech out there ready for when your ideas and inventions become real.’  I hope I managed to expose some of that bigger world of software to some of them.

Permalink Add your comment
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: 2602307