One of the interesting characteristics of TM354 is that it more theoretical than it is practical. Rather than using lots of software tools to work with and manipulate code and components, students are introduced to diagrammatic tools in the form of the Unified Modelling Language (UML). I don’t think this is necessarily a bad thing. It forces students to slow down, and to look at the detail, and to reflect on what it means to think about software. By deliberately pushing any practical tools aside, we avoid worrying about specific issues that relate to implementation. An implicit assumption is implementation is development, and engineering is about how we go about structuring and organising the building of software.
The practice of software engineering has moved on since 2014. Agile practices and cloud computing have now become mainstream, and there has been the recognition that artificial distinctions between ‘development’ and ‘operations’, the idea that you move software from one team to another, might not be particularly useful. The notion of technical debt has been defined, and this connects with older more established themes of software metrics. There is an increased recognition of tools: of requirement management tools, version management tools, and ticket management tools. All this mean that the notion of a theoretical module that is separate from the practical world of software engineering is harder to argue.
There are, of course, concepts which remain paramount: the importance of different types of requirements, understanding the different types of software development process, conceptions of software quality, principles of software architecture, and different approaches to software testing.
In the sections that follow, I share something of my own personal experience of software engineering education and then share some of my experiences of working as a software engineer. I then go onto share some rough thoughts about what a reimagined TM354 module might look like.
This opinion piece has been written with a couple of audiences in mind: colleagues who work on different modules, and tutors who may have a connection with the OU’s software engineering modules. The sketch that is presented isn’t a firm reflection of what TM354 might morph into (since I don’t have the power to enact that kind of radical change). It is intended to feed into future debates about the future of the module, and modules that accompany it.
A personal history
When I studied Computer Science as an undergraduate in the early to mid-1990s, I studied a software engineering module, and a complementary practical module that was all about software maintenance. I remember my software engineering module was also theoretical. We all had to sit a 3 hour exam which took place in a dusty sports hall. I remember questions about software cost estimation, software reliability and software testing. Out of these three topics, only software testing remains in TM354.
The complementary (and practical) software maintenance module was very different. We were put in a team, given a document that contained list of changes that were needed to be made, and 40k lines of FORTRAN code, and told ‘mind how you go’.
We had a lot to figure out. We needed to figure out how to drive various software tools, how to get compilers to compile, and how to work as a team. At the very end of the project, each team had to make a presentation to representatives ‘from industry’. The team bit didn’t go as as we would have liked, but all that was okay: it was all about the learning. A key point that I took away from it was that the people bit was as hard (if not harder) than figuring out how to compile ancient FORTRAN code.
Software engineering as a postdoc
My first proper job (if you can call it that) was as a Research Officer at the University of Brighton. My job was to help colleagues with their projects. I was what you could call a ‘floating technical resource’ that could be deployed as and when required.
One memorable project was all about machine translation. It soon struck me that I had to figure out a client-server software architecture. A key bit to a software puzzle was a client program that was written in Java 1.1, which I took ownership of. The code I inherited was a pathological mess. There were classes and objects everywhere. It was a rat’s nest of bafflement. I rewrote it a bit at a time. I didn’t realise it at the time, but I was refactoring my Java code (and testing as I went) before it was known as refactoring. My client software sent data to a server program using a notation that now would look very similar to the JavaScript Object Notation language.
Like the software maintenance project, there was a lot to figure out: tools, languages, code structures, software architectures, operating systems, and where code was hosted so it could be run. The end result seemed to work, and work well. I felt I had figured out OO programming.
Software engineering as a software engineer
After a year of being a research officer, I managed to get a job as a software engineer in a small company that manufactured educational equipment. They needed software to work with their hardware, which was used to demonstrate principles of process control, electronics and telecommunications. I worked on a lot projects, but I’ll just mention two of them.
The first project was a maintenance project. There was a lot of software written in a combination of Visual Basic for DOS (yes, this was an actual product) and assembly language. The challenge was to rewrite the software in a combination of Java and C++. The Java bit would display results from experiments, and the C++ bit would take voltage measurements and turn digital switches on and off. Eventually, the code would go deeper. I had to learn about device driver development kits and how to begin to write functions for microcontrollers that drove USB interfaces.
The second project was different. The idea (which came from the marketing department and the managing director) was to make a learning management system that wasn’t too different in intent to the software that generates the university’s module web pages, but at a much smaller scale. Rather than providing files and resources to tens of thousands of students, this system was to allow educators to rapidly deploy materials to workstations within a single engineering laboratory. The big question was, of course, how do we do this?
From a technical perspective we ended up doing what these days is called ‘full stack’ development. We created code for the client side using JavaScript at a time when there were not any fancy JavaScript frameworks. On the server side, we had client side ASP.NET supported by stored procedures that were run in an SQL database. There was also content to deploy that contained Java applets, metadata to figure out, XML documents to parse, a quiz engine to build and report writing facilities to master. Books about eXtreme Programming and Test Driven Development had just come out. We tried pair programming and had a go to apply JUnit. Everything we built had to be installed relatively painlessly with the click of a mouse (but, of course, everything is never that straightforward). My key learning was, of course, that software is so much more than code.
There’s a third point that is worth labouring, and that point relates to process. When I joined, the engineering efforts were just ramping up, which meant there wasn’t much legacy when it came to software engineering processes. A ‘release’ had previously involved transferring software from a development machine to a production machine using a floppy disk.
A new hire (let’s call him ‘Alan’) joined the team. Having cut his software engineering teeth having worked on an early generation of mobile phone software, Alan had a huge amount of experience and a desire to make sure that we knew what was in every release. He introduced what will now be known as a ‘ticketing’ system to document software defects, and a formal release process, which also involved the use of version management software.
Software engineering as a research fellow
The experience of working on a learning management system led me to a research project that was hosted at the OU that explored how to enhance the accessibility of virtual learning environments (VLEs) for disabled students.
Before we ever got to code, there was a lot of discussion about architecture, which came to define the project’s output. The key question that we had to solve sounded quite simple: how do we find a way to present users with content that matches their needs and preferences? To answer this question, we need to answer other questions, such as: how do we define what a user needs? Also, how do we describe digital learning materials using metadata in such a way they can be efficiently chosen by a VLE?
These simple sounding questions hide complexity. Conditions can vary on a day by day basis. The digital content needed on one day may be different to what is needed on another. Learners are, of course, the experts of their own condition, and learners (who are all different) need to have ways to express their needs and preferences. What is really important is that a VLE offers learners choice about the types of learning materials. If we were to look at this project through a software engineering lens, the most important element of the whole project was the user’s requirements.
Mid way through this project, I stepped into another role: I became a Computing staff tutor. This meant that I stepped away from the technical aspects of computing and software engineering, and into a role where I had more involved with delivering the presentation of modules and supporting tutors.
Similarities and differences
These projects differed in terms of the users, the tasks, and the environments in which the software was used. They also were different in terms of the technologies that were applied. There were different databases, operating systems and programming languages. I had to make choices from different frameworks and tools. I’ve mentioned a unit testing framework, but I also used a model-view-controller inspired PHP application framework. There were also different software development kits and libraries to work with. There were also different ways to consume and to invoke webservices.
Turning to the similarities, one of the biggest similarities doesn’t relate to what was chosen, but what was done. In every project, I had to carry out some form of critical assessment and evaluation, to make informed decisions that could be justified. This meant finding things out in terms of what things did, and then how they worked.
Software engineers need to be multi skilled. Not only do the need to know how programming languages, data structure and operating systems work, they need to be systematic researchers, be creative problem solvers, and also be effective communicators. There was a reason why, as an undergraduate, we were asked to give a presentation about our software maintenance project.
Software is invisible. Software engineers need to know how to talk about it.
A bachelor's degree is Level 6 of the FHEQ, and it is worth looking at descriptor 4.15, which states that students must gain “the ability to manage their own learning, and to make use of scholarly reviews and primary sources (for example, refereed research articles and/or original materials appropriate to the discipline)”. Students attaining level 6 should also be able to “communicate information, ideas, problems and solutions to both specialist and non-specialist audiences” and have “the qualities and transferable skills necessary for employment requiring: the exercise of initiative and personal responsibility. decision-making in complex and unpredictable contexts, the learning ability needed to undertake appropriate further training of a professional or equivalent nature”. Another point that jumps out at me is: “the holder of such a qualification will be able to evaluate evidence, arguments and assumptions, to reach sound judgements and to communicate them effectively”. It is clear from this guidance that an entire degree must help to develop student’s critical communication and critical thinking skills.
It's worth also digging into the Computing Benchmark statements to see what it says. When it comes to demonstrating computational problem-solving, to demonstrate excellence, students must “be able to demonstrate sophisticated judgement, critical thinking, research design, and well-developed problem-solving skills with a high degree of autonomy” (QAA Subject Benchmark Statement, Computing, March 2022, p.20). This means that modules must work with students to develop those critical thinking skills.
What the QAA guidance lacks is specific guidance about what a module or programme should contain. This is where something called the IEEE Software Engineering Body of Knowledge comes in (SWEBOK v4.0). There’s enough detail in here to cover a whole degree, never mind a single module. Of particular note is chapter 14, which is all about Software Engineering Professional Practice.
A vision for a new level 3 software engineering module
I hate exams. I also hate end of module assessments (especially when I have to complete one of them), but I hate them less than exams.
An EMA makes a lot more sense in a module like TM354 than a written exam, since it gives students a lot more space to demonstrate their understanding and their professional communication skills.
My proposal is to design a module that combines the teaching of software engineering ideas and concepts with a practical investigation of a software product of a student’s choice. The choice of a product being, of course, guided by a tutor. Like with TM354, I’m suggesting three TMAs, each of has some emphasis on the development of research skills. By the time students complete TM354, they should end up being better equipped to complete the computing dissertation capstone module, which currently goes by the module code TM470.
Students should ideally arrive at this module having studied a level 2 module, where they have developed an understanding of the principles of object-oriented programming and problem decomposition. They may also be aware of some diagramming languages, such as UML. Drawing on an interesting approach adopted in other modules, I would like to see independent study options, which enables students to demonstrate (and develop) their reading and investigation skills.
Here’s a suggested structure.
Block 1: Processes and Tools
This module will begin with a reminder about software the software development lifecycle (which should have been already covered on an earlier module), which are then discussed in greater depth. The term ‘tools’ is broad. Tools can be used to capture requirements and manage requirements.
Tools also support processes. A discussion about processes would lead us to a discussion about version and configuration management, and onto testing. This is linked to the topics of continuous integration and continuous deployment (CI/CD).
Independent study would include reading articles about materials that are provided within this week.
In terms of the assessment, students must demonstrate their practical understanding or use of tools, and also to draw upon a case study (which may well be written by the module team) where students relate their independent reading to the case study. Students must be able unambiguous reference both articles and software.
Block 2: Technology and Architectures
This block focuses on teaching important and essential ideas, such as software architecture and design patterns. This block should also cover software engineering abstractions that can have different meanings, such as component, containers and frameworks. Drawing on what is covered in an earlier web and cloud module, the link and relationship with cloud computing and cloud architectures should also be explored. The point here is that software engineers need to be able to recognise decisions that have been made, and to be able to begin to articulate alternative decisions. There might also be the space to highlight AI frameworks, but this is very speculative. Independent study would involve looking at articles about different aspects of architecture. A point of doing this is further help students understand what the academic study of software engineering looks like.
Regarding assessment, students must demonstrate knowledge and understanding of key concepts that are introduced in this block, ideally by sharing potential designs and research with each other.
Block 3: Research and Investigation
This final block is about further developing software research skills. Since software maintenance is a significant part of the software lifecycle, software engineers need to be able to find their way through software stacks that are unfamiliar to them. Software engineers need to be critical thinkers; they need to understand what has been done, and why something has been done.
To help students what they need to do, students might be guided through an investigation, which could then intersect with different tools, teams and stakeholders. This would lead towards the EMA, which is all about producing a report that describes a software system in terms of processes used, tools applied, technology deployed, and its overall architecture.
To help students, this block would present some materials that offer some guidance about how to structure a report. For their block assessment, students would propose a software system or product to investigate. The system might be one that they are familiar with in their workplace, an open source software application, or software component or framework that can be used or applied within other software systems. In return, tutors would offer some practical advice, and perhaps follow up with a one-to-one session if they need further advice and guidance.
End of module assessment
A theoretical EMA is to be delivered in two parts: a formal report (70% of the EMA result), followed by a short presentation (30% of the EMA result). Both components need to be passed to pass the EMA (if this is theoretically permissible by the university assessment guidelines).
The report is to contain:
A description of a software component, product, or service that is the target of an investigation.
A rationale for the choice of that component.
A summary of its architectural elements, and any software components that it uses, or how the software component is used in other products or services.
A summary of software technologies or components that are important to its implementation or realisation, such as technology standards, libraries or languages.
A description of software development methodologies that may have contributed to its creation, or a summary of methods that may currently be applied.
A summary of any tools that are important to its use and development. This may include, for example, version or configuration management tools.
A commentary about how the software is to be deployed, and what supporting software or infrastructure may be needed to facilitate its deployment.
For the presentation component, students are to prepare a ten minute PowerPoint presentation that summarises their report, with an additional ten minutes for questions. Their presentation is to contain:
A summary of their chosen software component or product and what it is used for, and who the users or stakeholder might be.
Highlight what software technologies it makes use of, or what technologies it might be a part of.
Any significant ethical or professional concerns that need to be considered.
Students will deliver their presentation to two people; a tutor, and someone who plays the role of a technical manager, who needs to make use of the report that has been created by the software engineer. For accountability and rigour, the presentations are to be recorded, but these recordings will only be used for quality control purposes.
Reflections
All ideas have to come from somewhere. The vision that is shared has been shaped by my own undergraduate studies, industrial experience, by chairing TM354, and looking at other modules, such as M813 Software Development and M814 Software Engineering. In this article I have laboured points about educational and industrial history to emphasise a disconnect between the two.
What is proposed here is a practical amalgam of both my undergraduate modules, and both the OU’s postgraduate modules, but positioned as an undergraduate module. The idea for the presentation assessment comes from M812, where students have to present their summary of a forensic investigation to a pretend ‘court’. This ensures academic rigour of the written assessment, whilst also helping to develop student’s communication skills.
One point that I have a clear opinion about is that software engineers need to be able be critical thinkers, and carry out applied research. They also need be mindful about the ethical consequences of their decisions. What is necessary (which is something that is emphasised in other modules I’ve been studying) is the need to develop research skills. By helping students to carry out their own research, students learn more about what it means to study software engineering as an academic subject, and learn more about what it means to carry out study and evaluate software products, which is a necessary and important industrial skill.
Considering a vision for TM354 Software Engineering
TM354 Software Engineering is an important module with the OU’s Computing and IT Q62 qualification. It is a module that has been around, in one form or another, for a long time. The current version of the module, which dates back to 2014 is roughly summarised in the blog post Exploring TM354 Software Engineering.
One of the interesting characteristics of TM354 is that it more theoretical than it is practical. Rather than using lots of software tools to work with and manipulate code and components, students are introduced to diagrammatic tools in the form of the Unified Modelling Language (UML). I don’t think this is necessarily a bad thing. It forces students to slow down, and to look at the detail, and to reflect on what it means to think about software. By deliberately pushing any practical tools aside, we avoid worrying about specific issues that relate to implementation. An implicit assumption is implementation is development, and engineering is about how we go about structuring and organising the building of software.
The practice of software engineering has moved on since 2014. Agile practices and cloud computing have now become mainstream, and there has been the recognition that artificial distinctions between ‘development’ and ‘operations’, the idea that you move software from one team to another, might not be particularly useful. The notion of technical debt has been defined, and this connects with older more established themes of software metrics. There is an increased recognition of tools: of requirement management tools, version management tools, and ticket management tools. All this mean that the notion of a theoretical module that is separate from the practical world of software engineering is harder to argue.
There are, of course, concepts which remain paramount: the importance of different types of requirements, understanding the different types of software development process, conceptions of software quality, principles of software architecture, and different approaches to software testing.
In the sections that follow, I share something of my own personal experience of software engineering education and then share some of my experiences of working as a software engineer. I then go onto share some rough thoughts about what a reimagined TM354 module might look like.
This opinion piece has been written with a couple of audiences in mind: colleagues who work on different modules, and tutors who may have a connection with the OU’s software engineering modules. The sketch that is presented isn’t a firm reflection of what TM354 might morph into (since I don’t have the power to enact that kind of radical change). It is intended to feed into future debates about the future of the module, and modules that accompany it.
A personal history
When I studied Computer Science as an undergraduate in the early to mid-1990s, I studied a software engineering module, and a complementary practical module that was all about software maintenance. I remember my software engineering module was also theoretical. We all had to sit a 3 hour exam which took place in a dusty sports hall. I remember questions about software cost estimation, software reliability and software testing. Out of these three topics, only software testing remains in TM354.
The complementary (and practical) software maintenance module was very different. We were put in a team, given a document that contained list of changes that were needed to be made, and 40k lines of FORTRAN code, and told ‘mind how you go’.
We had a lot to figure out. We needed to figure out how to drive various software tools, how to get compilers to compile, and how to work as a team. At the very end of the project, each team had to make a presentation to representatives ‘from industry’. The team bit didn’t go as as we would have liked, but all that was okay: it was all about the learning. A key point that I took away from it was that the people bit was as hard (if not harder) than figuring out how to compile ancient FORTRAN code.
Software engineering as a postdoc
My first proper job (if you can call it that) was as a Research Officer at the University of Brighton. My job was to help colleagues with their projects. I was what you could call a ‘floating technical resource’ that could be deployed as and when required.
One memorable project was all about machine translation. It soon struck me that I had to figure out a client-server software architecture. A key bit to a software puzzle was a client program that was written in Java 1.1, which I took ownership of. The code I inherited was a pathological mess. There were classes and objects everywhere. It was a rat’s nest of bafflement. I rewrote it a bit at a time. I didn’t realise it at the time, but I was refactoring my Java code (and testing as I went) before it was known as refactoring. My client software sent data to a server program using a notation that now would look very similar to the JavaScript Object Notation language.
Like the software maintenance project, there was a lot to figure out: tools, languages, code structures, software architectures, operating systems, and where code was hosted so it could be run. The end result seemed to work, and work well. I felt I had figured out OO programming.
Software engineering as a software engineer
After a year of being a research officer, I managed to get a job as a software engineer in a small company that manufactured educational equipment. They needed software to work with their hardware, which was used to demonstrate principles of process control, electronics and telecommunications. I worked on a lot projects, but I’ll just mention two of them.
The first project was a maintenance project. There was a lot of software written in a combination of Visual Basic for DOS (yes, this was an actual product) and assembly language. The challenge was to rewrite the software in a combination of Java and C++. The Java bit would display results from experiments, and the C++ bit would take voltage measurements and turn digital switches on and off. Eventually, the code would go deeper. I had to learn about device driver development kits and how to begin to write functions for microcontrollers that drove USB interfaces.
The second project was different. The idea (which came from the marketing department and the managing director) was to make a learning management system that wasn’t too different in intent to the software that generates the university’s module web pages, but at a much smaller scale. Rather than providing files and resources to tens of thousands of students, this system was to allow educators to rapidly deploy materials to workstations within a single engineering laboratory. The big question was, of course, how do we do this?
From a technical perspective we ended up doing what these days is called ‘full stack’ development. We created code for the client side using JavaScript at a time when there were not any fancy JavaScript frameworks. On the server side, we had client side ASP.NET supported by stored procedures that were run in an SQL database. There was also content to deploy that contained Java applets, metadata to figure out, XML documents to parse, a quiz engine to build and report writing facilities to master. Books about eXtreme Programming and Test Driven Development had just come out. We tried pair programming and had a go to apply JUnit. Everything we built had to be installed relatively painlessly with the click of a mouse (but, of course, everything is never that straightforward). My key learning was, of course, that software is so much more than code.
There’s a third point that is worth labouring, and that point relates to process. When I joined, the engineering efforts were just ramping up, which meant there wasn’t much legacy when it came to software engineering processes. A ‘release’ had previously involved transferring software from a development machine to a production machine using a floppy disk.
A new hire (let’s call him ‘Alan’) joined the team. Having cut his software engineering teeth having worked on an early generation of mobile phone software, Alan had a huge amount of experience and a desire to make sure that we knew what was in every release. He introduced what will now be known as a ‘ticketing’ system to document software defects, and a formal release process, which also involved the use of version management software.
Software engineering as a research fellow
The experience of working on a learning management system led me to a research project that was hosted at the OU that explored how to enhance the accessibility of virtual learning environments (VLEs) for disabled students.
Before we ever got to code, there was a lot of discussion about architecture, which came to define the project’s output. The key question that we had to solve sounded quite simple: how do we find a way to present users with content that matches their needs and preferences? To answer this question, we need to answer other questions, such as: how do we define what a user needs? Also, how do we describe digital learning materials using metadata in such a way they can be efficiently chosen by a VLE?
These simple sounding questions hide complexity. Conditions can vary on a day by day basis. The digital content needed on one day may be different to what is needed on another. Learners are, of course, the experts of their own condition, and learners (who are all different) need to have ways to express their needs and preferences. What is really important is that a VLE offers learners choice about the types of learning materials. If we were to look at this project through a software engineering lens, the most important element of the whole project was the user’s requirements.
Mid way through this project, I stepped into another role: I became a Computing staff tutor. This meant that I stepped away from the technical aspects of computing and software engineering, and into a role where I had more involved with delivering the presentation of modules and supporting tutors.
Similarities and differences
These projects differed in terms of the users, the tasks, and the environments in which the software was used. They also were different in terms of the technologies that were applied. There were different databases, operating systems and programming languages. I had to make choices from different frameworks and tools. I’ve mentioned a unit testing framework, but I also used a model-view-controller inspired PHP application framework. There were also different software development kits and libraries to work with. There were also different ways to consume and to invoke webservices.
Turning to the similarities, one of the biggest similarities doesn’t relate to what was chosen, but what was done. In every project, I had to carry out some form of critical assessment and evaluation, to make informed decisions that could be justified. This meant finding things out in terms of what things did, and then how they worked.
Software engineers need to be multi skilled. Not only do the need to know how programming languages, data structure and operating systems work, they need to be systematic researchers, be creative problem solvers, and also be effective communicators. There was a reason why, as an undergraduate, we were asked to give a presentation about our software maintenance project.
Software is invisible. Software engineers need to know how to talk about it.
A quick look at QAA
Before writing this piece, I wrote an article called A quick look at the QAA benchmarks (OU blog). When considering the design of a new module, it is worth reviewing the QAA guidance. One aspect that I didn’t extensively review was the Higher Education Qualifications of UK Degree-Awarding Bodies framework.
A bachelor's degree is Level 6 of the FHEQ, and it is worth looking at descriptor 4.15, which states that students must gain “the ability to manage their own learning, and to make use of scholarly reviews and primary sources (for example, refereed research articles and/or original materials appropriate to the discipline)”. Students attaining level 6 should also be able to “communicate information, ideas, problems and solutions to both specialist and non-specialist audiences” and have “the qualities and transferable skills necessary for employment requiring: the exercise of initiative and personal responsibility. decision-making in complex and unpredictable contexts, the learning ability needed to undertake appropriate further training of a professional or equivalent nature”. Another point that jumps out at me is: “the holder of such a qualification will be able to evaluate evidence, arguments and assumptions, to reach sound judgements and to communicate them effectively”. It is clear from this guidance that an entire degree must help to develop student’s critical communication and critical thinking skills.
It's worth also digging into the Computing Benchmark statements to see what it says. When it comes to demonstrating computational problem-solving, to demonstrate excellence, students must “be able to demonstrate sophisticated judgement, critical thinking, research design, and well-developed problem-solving skills with a high degree of autonomy” (QAA Subject Benchmark Statement, Computing, March 2022, p.20). This means that modules must work with students to develop those critical thinking skills.
What the QAA guidance lacks is specific guidance about what a module or programme should contain. This is where something called the IEEE Software Engineering Body of Knowledge comes in (SWEBOK v4.0). There’s enough detail in here to cover a whole degree, never mind a single module. Of particular note is chapter 14, which is all about Software Engineering Professional Practice.
As well as the SWEBOK, there is are also the Association of Computing Machinery Curricula Recommendations, which contains a sub-section that concerns Software Engineering. Of these two documents, the SWEBOK is a lot more comprehensive and more up to date than the older 2014 guidance, which is clearly in need of a refresh.
A vision for a new level 3 software engineering module
I hate exams. I also hate end of module assessments (especially when I have to complete one of them), but I hate them less than exams.
An EMA makes a lot more sense in a module like TM354 than a written exam, since it gives students a lot more space to demonstrate their understanding and their professional communication skills.
My proposal is to design a module that combines the teaching of software engineering ideas and concepts with a practical investigation of a software product of a student’s choice. The choice of a product being, of course, guided by a tutor. Like with TM354, I’m suggesting three TMAs, each of has some emphasis on the development of research skills. By the time students complete TM354, they should end up being better equipped to complete the computing dissertation capstone module, which currently goes by the module code TM470.
Students should ideally arrive at this module having studied a level 2 module, where they have developed an understanding of the principles of object-oriented programming and problem decomposition. They may also be aware of some diagramming languages, such as UML.
Drawing on an interesting approach adopted in other modules, I would like to see independent study options, which enables students to demonstrate (and develop) their reading and investigation skills.
Here’s a suggested structure.
Block 1: Processes and Tools
This module will begin with a reminder about software the software development lifecycle (which should have been already covered on an earlier module), which are then discussed in greater depth. The term ‘tools’ is broad. Tools can be used to capture requirements and manage requirements.
Tools also support processes. A discussion about processes would lead us to a discussion about version and configuration management, and onto testing. This is linked to the topics of continuous integration and continuous deployment (CI/CD).
Independent study would include reading articles about materials that are provided within this week.
In terms of the assessment, students must demonstrate their practical understanding or use of tools, and also to draw upon a case study (which may well be written by the module team) where students relate their independent reading to the case study. Students must be able unambiguous reference both articles and software.
Block 2: Technology and Architectures
This block focuses on teaching important and essential ideas, such as software architecture and design patterns. This block should also cover software engineering abstractions that can have different meanings, such as component, containers and frameworks. Drawing on what is covered in an earlier web and cloud module, the link and relationship with cloud computing and cloud architectures should also be explored. The point here is that software engineers need to be able to recognise decisions that have been made, and to be able to begin to articulate alternative decisions. There might also be the space to highlight AI frameworks, but this is very speculative.
Independent study would involve looking at articles about different aspects of architecture. A point of doing this is further help students understand what the academic study of software engineering looks like.
Regarding assessment, students must demonstrate knowledge and understanding of key concepts that are introduced in this block, ideally by sharing potential designs and research with each other.
Block 3: Research and Investigation
This final block is about further developing software research skills. Since software maintenance is a significant part of the software lifecycle, software engineers need to be able to find their way through software stacks that are unfamiliar to them. Software engineers need to be critical thinkers; they need to understand what has been done, and why something has been done.
To help students what they need to do, students might be guided through an investigation, which could then intersect with different tools, teams and stakeholders. This would lead towards the EMA, which is all about producing a report that describes a software system in terms of processes used, tools applied, technology deployed, and its overall architecture.
To help students, this block would present some materials that offer some guidance about how to structure a report. For their block assessment, students would propose a software system or product to investigate. The system might be one that they are familiar with in their workplace, an open source software application, or software component or framework that can be used or applied within other software systems. In return, tutors would offer some practical advice, and perhaps follow up with a one-to-one session if they need further advice and guidance.
End of module assessment
A theoretical EMA is to be delivered in two parts: a formal report (70% of the EMA result), followed by a short presentation (30% of the EMA result). Both components need to be passed to pass the EMA (if this is theoretically permissible by the university assessment guidelines).
The report is to contain:
For the presentation component, students are to prepare a ten minute PowerPoint presentation that summarises their report, with an additional ten minutes for questions. Their presentation is to contain:
Students will deliver their presentation to two people; a tutor, and someone who plays the role of a technical manager, who needs to make use of the report that has been created by the software engineer. For accountability and rigour, the presentations are to be recorded, but these recordings will only be used for quality control purposes.
Reflections
All ideas have to come from somewhere. The vision that is shared has been shaped by my own undergraduate studies, industrial experience, by chairing TM354, and looking at other modules, such as M813 Software Development and M814 Software Engineering. In this article I have laboured points about educational and industrial history to emphasise a disconnect between the two.
What is proposed here is a practical amalgam of both my undergraduate modules, and both the OU’s postgraduate modules, but positioned as an undergraduate module. The idea for the presentation assessment comes from M812, where students have to present their summary of a forensic investigation to a pretend ‘court’. This ensures academic rigour of the written assessment, whilst also helping to develop student’s communication skills.
One point that I have a clear opinion about is that software engineers need to be able be critical thinkers, and carry out applied research. They also need be mindful about the ethical consequences of their decisions. What is necessary (which is something that is emphasised in other modules I’ve been studying) is the need to develop research skills. By helping students to carry out their own research, students learn more about what it means to study software engineering as an academic subject, and learn more about what it means to carry out study and evaluate software products, which is a necessary and important industrial skill.