OU blog

Personal Blogs

Christopher Douce

A sketch of M813 Software Development and M814 Software Engineering

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 26 Nov 2024, 18:20

After becoming the module chair of TM354 Software Engineering, I had a look at two related postgraduate modules, M813 Software Development and M814 Software Engineering

These two modules sit alongside a number of other modules that make up the MSc in Computing programme. My intention was to see what related topics and subjects are taught, and whether there were any notable differences about how they were taught. 

This blog aims to highlight some of the key elements of these modules. To prepare this post, I had a good look through the module materials, including the assessment materials, and spoke with each of the module chairs. My intention of looking at these modules is to identify what themes and topics might potentially feed into a future replacement of TM354, or another related module. This summary is by no means comprehensive; the points I pick up on do, of course, reflect my interests.

I hope these notes are useful to anyone who is interested in either software engineering, or postgraduate computing, or both. Towards the end of the blog, I share a quick compare and contrast between the two modules and share some links to resources for anyone who might be interested.

M813 Software Development

M813 aims to “to provide the skills and knowledge necessary to develop software in accordance with current professional practice, approaches and techniques”.

The key module learning aims are to:

  • teach you a variety of fundamental techniques for software development across the software lifecycle, and to provide practice in the use of these techniques
  • give you enough knowledge to be able to choose between different development techniques appropriate for a software development context
  • make you aware of design and technology trade-offs involved in developing enterprise software systems
  • enable you to evaluate current software development practices
  • give you an understanding of current and emerging issues in software development
  • give you the research skills needed to stay at the leading edge of software development.

The module description suggests that students “will have an opportunity to engage with an organisational problem of your choice, working towards a fit-for-purpose software solution” and students “will also have an opportunity to carry out some independent research into issues in software development, including analysing, evaluating and presenting results”.

It makes use of a set text, Head First Design Patterns, accessed through the university library. To help students with the more technical bits, it shares some resources about a graphical tool, Visual Paradigm, which enables students to create diagrams using the Unified Modelling Language (UML).

The module has 10 units of study, which are spread over four blocks. The module’s assessment strategy summarised below, followed by each of the blocks.

Assessment strategy

Like many other modules, there are two parts of assessment: tutor marked assessments (TMAs), and an examinable component, which is an end of module assessment (EMA). Interestingly, the TMAs adopt a more practical and software development skills perspective, whereas the EMA is more about carrying out research which is applied to a study context. To pass the module, students need to gain an average score of 50% in both of the components.

TMAs 1 and 3 account for 30% of the continually assessed part of the module. Due to the practical focus of TMA 2, this assessment accounts for 40% of the overall TMA score.

Block 1: Software development and early lifecycle

This block is described as helping to “learn the principles and techniques of early software lifecycle, from requirements and domain analysis to software specification. You will engage with a number of practices, including capturing and validating requirements, and UML (Unified Modelling Language) modelling with activity and class diagrams.”

The model opens with a research activity which involves finding and reading academic articles. There are three other research activities which build on this first searching activity. These activities helps students to understand what the academic study of software engineering looks like. Plus, when working as a practicing software engineer, it’s important to know how to find and evaluate information about methods, approaches, and frameworks.

This unit beings to introduce students to a tool that they will use during the module; Visual Paradigm. Throughout the module, students will learn more about different UML diagrams, such as use cases, class diagrams, and activity diagrams.

Unit 1, introducing software development, shares a couple of perspectives: a philosophical perspective and a historical perspective (history is always useful), before mentioning risk, quality and then moving onto starting to look at UML.

Unit 2, requirements and use cases, covers the characteristics of requirements and the forms that they can be presented. Unit 3, from the context to the system, starts with activity diagram (which are all about representing a context) through to class diagrams, which is all about beginning to realise a design of software using abstractions. Finally, unit 4, specifying what the system should do, touches on more formal aspects of software specification.

Block 2: Design and code

This next block explores “principles and techniques of software design, construction, testing and version control”. Other topics include design patterns, UML modelling with state diagrams and creating of software using the Java language. Out of all the blocks in the module, this is the one that has a really practical focus.

In addition to links to further video tutorials about Visual Paradigm, there’s some guidance about how to start to use Microsoft Visual Studio Code, and some initial development activities.

Unit 5, design, introduces some basic design principles, and new forms of diagram: communication diagrams and object diagrams. Unit 6, from design to code, shares a bit more detail about the principles of object-oriented programming, and goes onto introducing the topic of configuration management. Unit 7, design patterns, continues the theme of object-oriented programming by introducing a set of patterns from the Gang of Four text, which is complemented by a software development activity. 

Block 3: Software architectures and systems integration

Block 3 goes up a level to explore how to “develop software solutions based on software architectures and frameworks”. 

Unit 8, software architectures introduces the notion of architectural patterns, and how to model patterns using UML. Another useful topic introduced is state machines. An important theme that is highlighted is the idea of layer of software which, in turn, is linked to the notion of persistence (which means ‘how data can be saved’). This is complemented by unit 9, component-based architectures, which offers a specific example.  The module concludes with unit 10, service-oriented architectures.

Block 4: EMA preparation

This fourth block relates to the module’s end of module assessment (EMA), where students have to carry out some applied research into a software context in which they are familiar with. To help students to prepare, there are some useful preparatory resources.

Reflections

I really liked that this module brings in a bit of history, describing the history of object-oriented programming. I also liked that it shared some really useful descriptions about the differences between scholarship and research. There are some common elements between M813 and TM354, such as requirements and the use of UML, but I’ll say more about this in a later section.

M814 Software Engineering

M814 is “about advanced concepts and techniques used throughout the software life cycle” and replaces two earlier 15 point modules: M882 Software Project Management and M883 Requirements Engineering.

The module aims are to:

  • develop your ability in the critical evaluation of the theories, practices and systems used in a range of areas of Computing
  • provide you with a specialised area of study in order that you can experience and develop the frontiers of practice and research in focused aspects of Computing and its application
  • encourage you, through the provision of appropriate educational activities, to develop study and transferable skills applicable to your employment and continuing professional development
  • enable you to develop a deeper understanding of a specialist area of Computing and to contribute to future developments in the field.

Although this module is less ‘applied’ than M813, there are some important elements. Students make use Git and GitHub, and use a simulation and modelling tool, InsightMaker.

The module has four study blocks, containing 26 study units; a lot more than M813. These are summarised in the following sections. Students are also required to consult a set text, Mastering the requirements process by Robertson and Robertson, which is also available through the OU Library.

Assessment strategy

The module has three TMAs and an end of module exam, which is taken remotely (as opposed to an EMA). TMAs 1 and 3 have a weighting of 30% each, with TMA 2 being slightly more substantial, accounting for 40%. Students have to pass both the TMAs and the exam, gaining an average of 50% in each.

The exam covers all module learning outcomes and is split into two sections. For the second section students would have needed to be familiar with a research article.

Block 1: Software engineering context

The first two units, unit 1, software in the information society and unit 2, the organisational and business context, introduces software engineering. This is followed by an introduction to the organisational context through unit 3, organisational context, codes and standards. The title of this unit refers to professional codes, and professional and technical standards. Accompanying topics include software and the law, which includes intellectual properly, trademarking, patents, and data protection (GDPR) legislation. The final unit, unit 4, addresses ethics and values in software engineering.

Block 2: Software engineering methods and processes

Block 2 concerns software engineering methods and processes. The first two units highlights the notion of the process model, project management, and quality management, which includes the ISO 9001 standard and the Capability Maturity Model (CMMI). These are presented in unit 6, software activities and unit 7, software engineering processes. 

The module then covers unit 8, agile processes and unit 9, managing resources, which includes materials about SCRUM, Kanban, and something called the SAFe framework, which is a set of workflow patterns for implementing agile practices. There is also a case study which describes how agile is used in practice. I remember seeing some photographs that show how developers have been sharing information about project status using whiteboard and other displays. The module concludes with unit 10,  managing uncertainty and risk, and unit 11, software quality.

A part of this block makes use of simulation, introducing a ‘simulation modelling tool’ which can be used to experiment with the concept of Brooks’ law. As an aside, this reminds me of a short article https://ppig.org/papers/2002-ppig-14th-hales/ that touched on a similar topic. In the context of M814, I like how the idea of simulation has been applied in an interesting and pedagogically helpful way.

Block 3: Software deployment and evaluation

Block 3 concerns software deployment and evolution. In other words, what happens after implementation. It includes some materials about DevOps (the integration of development with the operation of software), and continual integration and delivery. There are three units: unit 12, software configuration management, which introduces Git and GitHub, unit 13, software deployment, and unit 14, software maintenance and evolution.

This block returns to simulation, specifically exploring Lehman’s 2nd law (Wikipedia), which means that software complexity increases unless something is done to reduce it. Students are also directed to a text book, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, by Humble and Farley. 

Block 4: Back to the beginning

The final block returns to the beginning by looking at requirements engineering, extensively drawing on the set text, Mastering the Requirements Process. It introduces what is meant by requirements engineering, a subtopic within software engineering. Unit titles for this block includes scoping the business problem, functional and non-functional requirements, fit criteria and rationale, ensuring quality of requirements, and reusing requirements. The block concludes with a useful section: unit 26, current trends in software engineering.

Reflections

I really liked the introductory sections to this module; they adopt a philosophical tone. I also really like how it uses case studies. What is notable is that there are a lot of materials to get through, but all the topics and units are certainly appropriate and are needed to cover the module in a good amount of depth.

Similarities and differences

There is understandably some cross over between M813 and M814; they complement each other. M813 is more of an ‘applied’ module than either M814 or TM354, but M814 does contain a few practical elements. It’s use of simulations is particularly interesting. In comparison to the undergraduate software engineering module, TM354, the two postgraduate modules do clearly require the application of higher academic skills, such as understanding what it means to carry out scholarship.

In my opinion, there appear to be more similarities between M813 and TM354 than with M814. It is worth noting that TM354 introduces topics that can be found in both postgraduate modules.

TM354 and M813 both emphasise design patterns. An important difference is that in M813, students are required to demonstrate how patterns might be applied, whereas on TM354 students have to necessarily demonstrate their understanding of design patterns that have been chosen by the module team. Both modules also explore the notions of software architectures and state machines.

There are differences between TM354 and M813 in terms of tools. TM354 steers away from the use of diagramming tools, but by way of contrast, M813 makes extensive use of Visual Paradigm. TM354 makes use of NetBeans for the design patterns task, whereas M813 introduces students to Visual Studio Code.

By way of contrast, M814 covers wider variety of concepts which are important to the building of ‘software in the large’; the importance of software maintenance and the characteristics of software quality.

UML is featured in all three modules. They all refer to software development methods and requirements engineering. Significantly, they all use the Roberston and Robertson text. The differ in terms of the depth they explore the topic.

To conclude, software development and software engineering are huge subjects. The three modules that are mentioned in this blog can only begin to scratch the surface. Every problem will have a unique set of requirements, and every problem will require different methods. There are two key elements: people and technology. Software is designed by people and used by people. Where there’s people, there’s always complexity. Adding technology in the mix adds an additional dimension of complexity.

Resources

The following links takes you to some useful OpenLearn resources:

Acknowledgements

Many thanks to Arosha Bandara who spent some time introducing me to some the key elements of M814. I also extend thanks to Yujin Yu. Both Arosha and Yujin are professors of software engineering. The current chair of M814 is Professor Andrea Zisman, who is also a professor of software engineering. Thanks are also extended to the TM354 module team: Michael Ulman, Richard Walker, Petra Wolf and Andrea Zisman.

Permalink Add your comment
Share post
Christopher Douce

Exploring TM354 Software Engineering

Visible to anyone in the world

Over the last year I’ve taken over as the incoming module chair for TM354 Software Engineering, taking over from Leonor Barroca, who has done a brilliant job ever since the module was launched back in 2014. I first learnt about TM354 through a module briefing which took place in September 2014.

What follows is a summary of the various elements that can be found within the TM354 module website. I’ve written this blog whilst wearing my ‘tutor hat’; to help students who are new to this module.

It goes without saying that two of the most important elements are, of course, the module calendar, and the assessment page which provides access to all the TMAs. One thing that I tend to do whenever I study a module is to get a printout of each of the TMAs, using the ‘view as single page’ option, just so I get an early idea about what I have coming up. You should also take some time to review the module guide and the accessibility guide.

Key resources: the blocks

TM354 is based around three printed blocks which can also be downloaded as PDFs by visiting the resources tab:

  • Block 1: Units 1-4 From domain to requirements
  • Block 2: Units 5-8 From analysis to design
  • Block 3: Units 9-12: From architecture to product

Complementing these blocks is, of course, the module glossary, which can be accessed through the resources pages.

In OU modules, the glossary is pretty important. It presents the module team’s definition of key terms. If there is an exam or an EMA question which calls for a definition, you should always draw on terms that are defined by the glossary. A practical tip is: do spend time looking at and going through the module glossary.

Software

There are three bits of software that you will need to use, and the first of these is optional:

A sketching tool: In your TMAs you will be required to draw some sketches using a graphical language called the unified modelling language (UML). UML is a really useful communication tool. It can be used to depict the static structure of software (which bits it contains), and the dynamic interaction between components (which is how they are used with each other). How you draw your diagrams is completely up to you. You can draw a sketch by hand, draw a sketch using the tools that you have in your word processor, or you can download a tool to help you. My recommendation is to use a tool that specifically helps you to draw UML diagrams. This way, the software gives you a bit of help, saving you time (although you have to spend a bit of time learning a tool). I use a tool called Visual Paradigm, which is available under a student licence, but other tools, such as UMLet might be useful. There are a lot of tools available, but if you’re pressured for time, a pencil, ruler and paper, and digital photograph will be sufficient.

ShareSpace: this is an OU tool which you will use to share some of your software designs with fellow students. Software engineering is a team sport. ShareSpace is used to simulate the sharing and collaboration between fellow software engineers. As well as posting your sketches, you will be asked to comment on the design of fellow students. When you leave comments, you will be able to see comments about your own design.

NetBeans: Netbeans is an integrated development environment; a tool for developing software. You will use Netbeans in the final block of the module to look at, and change some software code that relates to design patterns. If you’re familiar with other development environments, such as IntelliJ, or even BlueJ (from earlier studies with M250) you could use those instead.

Forums

The module has a number of forums. A practical recommendation is to subscribe to each of these, so you are sent email copies of the messages that are posted to them. 

There is a module forum, where you can ask questions about the module, and a forum for each of the TMAs. You can use these TMA forums to ask questions about the assessments if you’re unclear about what you need to do. Do bear in mind that the moderator can only offer guidance and might direct you towards relevant bits of the module materials.

There is a tutor group forum, where you can interact with your TM354 tutor. Your tutor may well share some materials through this forum, so it is important that you subscribe to it, or check it from time to time.

There is what is called a ‘online tutorial forum’. Tutorials are run in clusters. What this means is that groups of tutors work together to offer a programme of tutorials (which are sometimes known as learning events). These tutors will use this forum to share resources that relate to their tutorials. They may, for example, post copies of PowerPoint presentations that formed the basis of their tutorials, which may contain useful notes in the notes section of each slide.

Finally, there is the café forum. This is an informal area to chat with fellow students about TM354 and OU study. This area isn’t extensively monitored by the forum moderator.

One thing to note is that sometimes the names of these forum areas can and do change. The names of the forums here might not be the names of the forums that you have on your module website.

Study guides

Although most of the module materials are available through the printed blocks, there are some important elements of the module that are only available online. Within the module calendar, you will see study guide pages. To make sure you go through each of these. Sometimes, these guides are presented along side other accompanying online resources that you need to work through to answer some of the TMA questions.

Resources pages

The Resources pages (which is sometimes known as the resources tab) is a place that collates everything together: all the guides (module, accessibility and software guides), PDF versions of the blocks, online version of each of the units (which can be found within each of the blocks), and any additional resources that need to be studied:

  • Choosing closed-box test cases
  • Monoliths versus microservices
  • Introducing Jakarta EE
  • Implementing use cases

Towards the bottom of this page, there is a link to a zip file which contains some source code that is used with TMA 3, along with some NetBeans software installation instructions.

The final bit of the Resources pages that I would like to emphasise is the Download link, which can be found on the right hand side of the page. Through this link, you can access all the module resources in different formats. You can, for example, download some of the media files onto your mobile device for you to review later, or you can download ePub versions of all the study guides and units onto an e-reader.

iCMAs

TM354 also has a set of interactive marked assessments (iCMAs). These are designed to help you to learn and to remember some of the key module concepts. The iCMAs do not formally contribute to your overall assessment result.

Tutorials

Before my final section, I’ll say something about tutorials. Do try to attend as many as you can. There are tutorials that introduce you to each of the block, and help to guide you through what is required for the TMAs. There are also a series of exam revision tutorials. Do try to attend as many as you can, since different tutors will present ideas in different ways.

Reflections

There is quite a lot to TM354; there are a lot of resources, which take a lot of reading. To familiarise myself with the materials I’ve taken an incremental approach: studying a bit at a time. Although the printed blocks are central to the module, it is important to pay attention to the online materials too.

My biggest tips are:

  • Get a printout of the module guide.
  • Get a printout of each of the TMAs.
  • Make sure that you thoroughly read the module guide. You might want to get a printout of this too.
  • Do remember to regularly refer to the module glossary. These definitions are important.
  • Attend as many tutorials as you can.

Permalink Add your comment
Share post
Christopher Douce

Software engineering podcasts

Visible to anyone in the world
Edited by Christopher Douce, Thursday, 16 May 2024, 09:45

On the TM354 Software Engineering module forum, the following question was posed: ‘does anyone know of any software engineering podcasts?’  TM354 tutor, Tony Bevis gave a comprehensive reply. With permission, I am sharing selected elements from Tony’s post, listed in no particular order.

SE Radio

This SE Radio (se-radio.net) is pitched as the podcast for professional software engineers. The following sentences are drawn from the SE Radio about page: ‘The goal is to be a lasting educational resource, not a newscast. …  we talk to experts from throughout the software engineering world about the full range of topics that matter to professional developers’. It is interesting that this podcast has a formal link to a recognised publication: ‘SE Radio is managed by the volunteers and staff of IEEE Software, a leading technical magazine for software professionals published by the IEEE Computer Society. All content is licensed under the Creative Commons 2.5 license’. Episodes appear to be quite long; an hour or so.

What the Dev?

What the Dev? is a podcast from SD Times magazine. It is said to ‘cover the biggest and newest topics in software and technology’. The magazine has an accompanying weekly email newsletter which contains a summary of current technology news items and a weekly podcast. Each podcast appears to be relatively short. The ones I have listened to were approximately 20 minutes.

Agile Toolkit Podcast

Agile is an important software development approach. The Agile Toolkit podcast 

aims to share ‘conversations about agile development and delivery’ through an archive that runs from 2005 through to the current day. They appear to be pretty long, so if listening to podcasts to learn more about agile, it is important to be selective in terms of the podcasts that are listened to. 

Open Source Podcasts

Open Source technology is an important subject to software engineers. When doing a bit of internet searching, I discovered something called the Open Source Podcasts last.fm channel which aims to share ‘conversations and advice from Open Source technologists on a wide range of topics’ and summarises links to a range of different podcasts.

A quick search for the term Software Engineering on last.fm takes me to a podcast channel called Software Engineering DailyIt really does appear that there is a topic or a technology made available practically every day. These podcasts range in length between half and hour and an hour.

Hello World

Hello World is a magazine published by the Raspberry Pi Foundation. It is free for computer science educators. I am regularly send email updates about new episodes. The focus is primarily about computing education in schools. The Hello Word podcasts are a good and interesting listen, especially if you're interested in moving towards computing education.

Reflections

There are a lot of resources out there. There are so many podcasts and recordings, that I feel overwhelmed. I have yet to establish a regular podcast listening habit, and I have yet to find a convenient way (that works for me) to access these different channels.

I quite like What the Dev? since the episodes are quite short; I can be listening to a couple of these whilst getting on with other things. It is good to note that the first one mentioned on this blog is recognised by the IEEE Software magazine, and this deserves a more detailed look. The daily software engineering podcast looks to be of interest too. 

What is surprising to me is how many bits of technology that feature in these podcasts that I don’t recognise; a lot is new to me. I’m hoping that some of these podcasts will enable me to learn more about new technologies, understand their role and purpose, and how software engineers might use them.

Acknowledgements

A big thank you to Tony. I’m going to be doing a lot of listening!

Permalink Add your comment
Share post
Christopher Douce

Degree apprenticeship: DTS Themes

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

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

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

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

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

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

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

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

DTS apprenticeship themes

Core themes

The Organisational Context

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

Core Technical Concepts

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

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

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

Applied Technical Solutions

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

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

Leading and Working Together

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

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

Social Infrastructure - Legal, Ethical and Sustainability

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

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

Software Engineer themes

Underlying Principles

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

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

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

Technical Solutions

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

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

Innovation and Response

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

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

Legal, Ethics and Landscape

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

Preparing for the End Point Assessment

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

Core themes

The Organisational Context

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

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

Project Requirements

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

Project Planning and Resources

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

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

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

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

Solution Proposal

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

Project Delivery

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

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

Project Evaluation

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

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

Software Engineer themes

Technical Solutions

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

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

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

Innovation and Response

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

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

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

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

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

Evidence for the themes

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

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

Acknowledgments

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

Permalink Add your comment
Share post
Christopher Douce

Book review: Two novels about DevOps

Visible to anyone in the world

When I started to do some background reading into how TM354 Software Engineering might need to be updated, I was guided towards two curious novels. 

From October 23 I start to study A233 Telling stories: the novel and beyond, as a part of my gradual journey through a literature degree. For quite a while, I have been thinking there have been very little to connect novels and software engineering, other than obvious: the development of Word processing tools that can be used to write novels, and the Amazon cloud infrastructure used to distribute eBooks.

What follows is a very short (and not very through) review of two books that are all about DevOps: The Phoenix Project, by Gene Kim (and others), and The Unicorn Project, which is also by Kim. 

The Phoenix Project

I shall begin by sharing an honest perspective: the idea of a novel about software development did not excite me in the least. The text has a subheading that seemed to strengthen my prejudices: “a novel about IT, DevOps, and Helping Your Business win”. This is no crime drama or historical novel. The closest genre that one could attribute to The Phoenix Project is: thriller. I feel it occupies a genre all of its own, which could be labelled: IT business thriller.

The main protagonist is Bill Palmer, who has the unenviable job title of “Director of Midrange Technology Operations”. Bill works for a mysterious American company called Parts Unlimited. A lot happens in the early chapters: Bill is invited in to have a chat with a manager, who gives him a promotion. He is then asked to take a lead in getting the Phoenix Project, a new mission critical software system to work. Failure means the business would lose any potential competitive advantage, and the IT infrastructure might be outsourced, which means that people would lose their jobs.

Before Bill can get settled, he is hit by a payroll outage, which means the employees and unions are angry. He also quickly realises that the whole IT setup is in a complete state. Kim and his co-writers do a good job at attempting to convey a sense of paralysis and panic. The reason for this is expressed through the notion of ‘technical debt’, which means that existing IT infrastructure has become increasing complicated over time. Quick fixes now can, of course, lead to further problems down the line. Parts Unlimited has not been ‘paying down’ their technical debt.

An important element of the novel is the division between the Ops (operations) bit of IT, and the development division. There are other competing teams, which also play a role: there is the QA (quality assurance), and the security team. Security is important, since if an organisation doesn’t keep its auditors happy, the directors may face legal consequences.

I think I would be mean to describe the characters as one dimensional, since plot clearly takes precedence over characterisation. The main protagonist Bill is the most richly described. His organisational skills and sense of calm in the face of chaos is explained through his military background. 

Ubergeek Brent plays an important role, but I really wanted to know what made him tick. Erik Reid, an unofficial mentor to Bill plays the role of a Yoda-like mystic who provides insightful advice, who draws on his extensive knowledge of lean manufacturing. A notable character is Sarah Moulton, the Senior Vice President of Retail Operations, who takes on the unenviable role of the villain.

What struck me was the amount of technical detail that exists within the text. There are references to services, languages, and source code management. There is also the important notion of the ‘release’, which is a persistent problem, which pervades both this text, and its follow-up. Whilst I enjoyed the detail, I’m unsure about the extent to which the lay reader would grasp the main point that the book was making: to gain efficient business value from IT, it is best to combine together operations and development. Doing this enables the creation of tighter feedback loops, and reduces operational risk. Along the journey, there are these moments which raise an eyebrow. An example of this is where there is unambiguous contrition from a security manager once he sees an error in his thinking.

Bill identifies barriers and instigates change. After a “challenging” release of Phoenix, he ultimately prevails. During the updates, there is the emergence of a ‘side project’, which makes use of new fangled cloud technology to deliver value to the business. In turn, this generates income that makes shareholders happy. Political battles ensue, and Bill then gets on a fast track to a further promotion.

Apparently, The Phoenix project was popular amongst developers when it first came out, but I’ve been peripherally distant from the domain of software engineering, which means I’ve been a bit late to the party. Before providing further comment, I’ll move onto the sequel: The Unicorn Project.

The Unicorn Project

When I read The Phoenix Project, one of my criticisms was about the identity of the main protagonist. Novelists can not only use their craft to share a particular reality, but they can also have the potential to effect change. Whilst I liked Bill and the positive role that he took within the novel, given the clear and persistent gender disparities in the sector, I did feel that a female protagonist would have been more welcome. This unarticulated request was answered through The Unicorn Project in the form of Maxine Chambers, the lead protagonist in Kim’s follow up novel. 

Maxine is collateral damage from the payroll failure. Despite being hugely talented, she is side-lined; temporarily reassigned to The Phoenix Project. Her starting point was to try to get a build of all the software that was being developed, but faced persistent complexity, not just in terms of software, but in terms of finding out who to speak with to get things done.

Whilst the main project was saturated with bureaucratic burden, Maxine gradually found “her people”; smart like minded people who were also frustrated by the status quo. She also spoke with the business mystic and mentor, Erik Reid, who was very happy to share his words of wisdom. Ubergeek Brent also makes an appearance, but his backstory continued to remain opaque.

A really interesting part of the text is where Maxine ‘goes into the field’ to learn what happens in the Parts Unlimited stores. Drawing on the notion of ethnographic observations, she learns first-hand of the difficulties experienced by the store workers. Another interesting element which occurs towards the end of the novel is the movement towards embedding institutional learning, and drawing upon the creativity that exists within the workforce. In comparison to The Phoenix Project, there is more emphasis about culture, specifically, developing a no blame culture.

A key theme of The Unicorn Project is shared with The Phoenix Project: it is important to combine development and operations together, and it is helpful to perform continually integration since users can gain access to the new features more readily. A notable section highlighted the challenge of carrying out code merges during marathon meetings. If code is continually integrated, then there isn’t the need for all those uncomfortable meetings. Significantly, the Unicorn project also goes further than The Phoenix Project, since it is also about the power of teamwork, collaboration and the potential of smaller projects positively affecting and influencing others. Like Bill, the formidable Maxine is successful. 

Reflections

My initial scepticism of these novels comes from my view that novels are made from story and character, not technology. What is very clear is that although technology plays an important role, people are, by far, the most important. The novels foreground the role of teams and their organisation, the importance of sharing knowledge, and the importance of collaboration and leadership. It is clear that soft skills matter for the simple reason that software is something that is invisible; developers must be able to talk about it, and to each other. This is also why organisational culture is so important.

An important reflection is that both Bill and Maxine have difficult and very stressful jobs. They are both shown to work ridiculously long hours, often over the weekend. In the novels, IT is depicted as a difficult occupation, and one that is far from being family friendly. The families of both protagonists are featured, and they both suffer.

Although both of these novels are stories about the success of heroes battling against impossible odds, the hyperreality of the chaos within Parts Unlimited makes their success difficult to believe. Conversely, the hyperreality that is expressed through the impossible administrative burdens of the ticketing systems offers a warning to those who have to work with these systems on a daily basis.

The mystical mentor Erik is, of course, difficult to believe. He is a device use to share the pragmatic business and manufacturing theories that are central to the themes that are common to both books. I didn’t mind Erik. Like with Brent, I wanted to know more of his backstory, but with a limited work count and a lot of themes to work through, I understand why creative trade-offs were made to foreground more pressing technical topics.

Whilst I found the broader context, automotive spares, mildly interesting, I found myself becoming bored by the theme of IT being used to gain ever increasing amounts of money through the persistent and relentless pursuit of the customer. Although I accept that IT can be thought of a product of capitalism, there are more interesting ways that IT can be used and applied. Technology can be used to reflect humanity, just as humanity is reflected in technology. Whilst capital is important, there are other subjects that are more interesting. I think I would like to read an IT business thriller about cyber security, as opposed to one about a business that has found a new way to sell engine monitoring apps.

To conclude, these two novels were fun. They were also informative without being overly didactic. Although IT business thriller books is not my favourite genre, I can say that I enjoyed reading them. I’m more a fan of Victorian romances.

Epilogue

In 2004, I was working as a Software Engineer in a small company that designed and manufactured educational equipment used to teach the principles of electrical engineering and computing. 

One day in April, the manager director bounded into the office where I worked.

“We’re selling our e-learning division! This means that we won’t be able to sell our flagship learning management system anymore. We need to find a solution. We had been working on an earlier project, but that didn’t work out. So, we need you to head up the development of a new learning management system”.

That new learning management system was given an internal codename. It wasn’t very original. 

We called it Project Phoenix.

References

Kim, G. et al. (2014) The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. 1st edition. Place of publication not identified: IT Revolution Press.

Kim, G. (2019) The Unicorn Project. IT Revolution Press.

Permalink Add your comment
Share post
Christopher Douce

SEAD/LERO Research Conference ‘23

Visible to anyone in the world
Edited by Christopher Douce, Thursday, 20 July 2023, 09:56

I attended my first joint OU SEAD/LERO research conference, which took place between 4 July and 6 July 23. SEAD is an abbreviation for Software Engineering and Design Research Group a research group hosted within the OU’s School of Computing and Communications. The conference was joined by members of LERO, the Science Foundation Ireland Research Centre for Software, which based in Limerick.

What follows is a summary of the two days I attended. There was a third day that I didn’t attend, which was all about further developing some of the research ideas that were identified during the conference, and researcher professional development

The summary is intended for the delegates of the conference, and for anyone else who might be interested in what happens within the SEAD research group. All the impressions (and any accompanying mistakes in my note taking) are completely my own. What is summarised here isn’t an official summary. Think of it as a rough set of notes intended to capture some of the themes that were highlighted. It is also used to share some potential research directions and areas that intend to be further developed and explored.

Day 1: Introductions and research discussions

Bashar Nuseibeh kicked off the day by highlighting the broad focus of the conference: to consider the role of software in society. Although I missed the first minutes of his opening address due to traffic, there was a clear emphasis on considering important related themes, such as social justice.

The first session was an ice breaker session. This was welcome, since I was an incomer to the group, and there were many delegates who I had not met before. We were asked to prepare the answers for three questions: (1) Who you are, including where you are based and your role? (2) What is your main research area/interest?, and (3) Something you love about your research and something you dislike. (Not bureaucracy!)

Having a go to answer these myself, I work as a staff tutor. My research interests have moved and changed, depending on what role I’ve been doing. Most recently, it has been about the pedagogy of online teaching and learning. When I was a researcher on an EU funded project, I was looking at the accessibility of online learning environments and supporting students who have additional requirements. Historically, my research has been situated firmly in the area of software engineering; specifically, the psychology of computer programming, maintenance of object-oriented software, and software metrics (informed by research about human memory). I have, however, returned to the domain of software engineering, moving from the individual to communities of developers by starting to consider the role of storytelling in software engineering, working with colleagues Tamara Lopez and Georgia Losasso.

What I like about the research is that it is really interesting to discover how different disciplines can be applied to create new insights. What can be difficult is that different disciplines can sometimes use different languages.

Invited talk: navigating the divided city

Next up was an invited talk by Prof. John Dixon from the OU’s Social Psychology research group. John’s presentation was about “intergroup contact, conflict, desegregation, and re-segregation in historically divided societies”. John described how technology was used to explore human mobility preferences. Drawing on research carried out as a part of the Belfast Mobility Project. The project studies, broadly speaking, where people go when they navigate their way through spaces, and can be said to sit within an intersection between social science and geography. Technology was used by researchers to study activity space segregation and patterns of informal segregation, which can shed light on social processes. 

John also highlighted tensions that a researcher must navigate, such as the tension between open science (where data ca be made available to other researchers) and the extent to which it is ethical to share detailed information about the movement of people across a city.

There was a clear link between the talk and the theme: the connection between software and society. This talk also resonated with me personally: as a regular user of an activity tracker called Strava, I was already familiar with some of the ethical concerns that were shared. After becoming a user of Strava, I changed a couple of settings to ensure that my identity is disguised. Also, a year ago I noticed that the activity tracker has started to hide the start point and the end point of any activity that I was publicly sharing. A final point from the part of the day is that both technology and software can lead to the development of new methods and approaches.

Fishbowl: Discussing society and software

Talking of new methods and approaches, John’s talk (and a lunch break) was followed by an event that was known as the ‘fishbowl session’, which introduce a ‘conference method’ that I had never heard of before.

In some respect, the ‘fishbowl’ session was a discussion with rules. Delegates sat on one of ten chairs in the middle of the room, and have a conversation with each other, whilst trying to connect together either the main theme of the discussion (software and society) or some of the topics that emerge from the discussions.  We were encouraged to discuss “anything where software has a role to play”.

The fishbowl discussed consequences of technology, collective education, critical thinking (of users), power of automation, concentration of power (in corporations), the use of AI (such as large language models), trade-offs, and complex systems. On the subject of AI, one view I noted down was that perhaps the use of AI ought to be limited to low risk domains, and leave people to the critical thinking (but this presupposes that we understand all the risks). There was also a call to ensure that AI tools to explain their “reasoning”, but this also implicitly links back to points about skills and knowledge of users. This is linked to the question: how do we empower people to make decisions about the systems that they use?

Choices were also discussed. Choices by consumers, and by developers, especially in terms of what is developed, and what is good to develop. Also, when uncovering and specifying requirements, it is important to consider what the negatives might be (an observation which reminds me of the concept of ‘negative use cases’ which is highlighted in the OU’s interaction design module).

I noted down some questions that were highlighted: how do we present our discipline? Do we research how to “do software” and leave it up to industry? Should we focus on the evaluation of the impact of software on communities and society? An interesting quote was shared by Bashar, which was: “working in software research is working for society”.

A final reflection I noted was that societal problems (such as climate change) can be thought as wicked problems, where there is no right answer. Instead, there might be solutions that are not very right or wrong, or solutions that are better or worse than others.

It was difficult to distil everything down to a group of neat topics, but here are some headings that captured some of points that were discussed during the fishbowl session: resilience, care, sustainability, education, safety and security, and responsibility.

At the end of the session, all delegates were encouraged to join a group that reflected their research interests. I joined the sustainability group.

Group Work 1 - Expansion of themes from the fishbowl

After a coffee break it was time to do some work. The guidance from the agenda was to “to develop some proposals for future research (problem; research objectives; research questions; methods; impact)”. 

The sustainability group comprised of four members: three from SEAD, one from LERO.

After broadly discussing the link between sustainability and software engineering, we produced a sketch of a poster that shared the following points:

  • How can we make connections and causal links between different (sub)systems explicit.
  • How can we engineer software to be holistically ‘resource aware’?
  • What is the meta-language for sustainable software systems?
  • What are the heuristics for sustainable software systems?

On the surface of it, all these points are pretty difficult to understand. 

The first point relates to the link between software, economics, and society. Put another way, what needs to be done to make sure that software systems can make a positive contribution to the various dimensions of our lives. By way of further context, the notion of Doughnut Economics was shared and discussed.

The second point relates to the practice of developing software. Engineers don’t only need to consider how to develop software systems that use resources in an efficient way, they also need to consider how software teams use and consume resources.

The third point sounds confusing, but it isn’t. Put another way: how do we talk about, or describe, or even rate the efficiency, or sustainability of software systems. Going even further, could it be possible to define an ISO standard that describes what elements a sustainable software system could or should contain?

The final point also sounds arcane, but when unpacked, begins to make a bit of sense. In other words: are there rules that software engineers could or should apply when evaluating the energy use, or overall sustainability of software systems? There are, of course, some links from this topic to the topic of algorithms and data structures (which is explored in modules such as M269 Algorithms, data structures and computability) which considers efficiency in terms of time and memory. A simple practical rule might be, for example: “rather than continually polling for a check in status of something, use signals between software elements”. There is also a link to the notion of software patterns and architecture (with patterns being taught on TM354 Software Engineering).

Day 2: Ideate and prototype

The second day kicked off with summaries from the various groups. The responsibility team spoke about the role of individuals, values, and organisations. The care group highlighted motivation, engagement, older users and how to help people to develop their technical skills. The education had been discussing computing at schools, education for informed choices, critical thinking, and making sure that the right problem is addressed. The resilience group discussed support through communities, and the safety and security group asked whether safety related to people, or to process.

A paraphrased point from Bashar: “look to the literature to make sure that the questions that are being considered haven’t been answered before” also, reflecting on the earlier keynote, “consider radical methods or approaches, and consider the context when trying to understand socio-economic systems”.

Group Work 2 - ideate and prototype

Back in our groups, our task was to try to operationalise (or to translate) some of our earlier points into clearer research questions with a view to coming up with a research agenda.

Discussing each of the points, we returned to the meaning of the term sustainability, along with what is meant by resource utilisation by code, also drawing upon the UN sustainable development goals https://sdgs.un.org/goals .

We eventually arrived at a rough agenda, which I have taken the liberty of describing in a bit more detail. The first point begins from a high level. Each subsequent points moves down into deeper levels of analysis, and concludes with a point about how to proactively influence change:

  1. What types of software systems or products consume the most energy?
  2. After identifying a high energy consuming product or system, use a case study approach to holistically understand how energy used, also taking into account software development practices and processes.
  3. What are the current software engineering practices of developers who design, implement and build low energy computing devices, and to what extent can sharing knowledge about practice inform sustainable computing?
  4. What are the current attitudes, perceptions and motivations about the current generation of software engineers and developers, and how might these be systematically assessed?
  5. After uncovering practices and assessing attitudes, how might the university sector go about influencing organisations to enact change?

Relating to the earlier call to “draw on the literature”, a member of our team knew of some references that could be added to the reference section of our emerging research poster:

Lago, P. et al. (2015) Framing sustainability as a property of software quality. Communications of the ACM, Volume 58, Issue 10, pp.70–78. https://doi.org/10.1145/2714560

Lago, P. (2019) Architecture Design Decision Maps for Software Sustainability. 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Society (ICSE-SEIS), 25-31 May 2019, IEEE. https://doi.org/10.1109/ICSE-SEIS.2019.00015

Lago, P. et al. (2021). Designing for Sustainability: Lessons Learned from Four Industrial Projects. In: Kamilaris, A., Wohlgemuth, V., Karatzas, K., Athanasiadis, I.N. (eds) Advances and New Trends in Environmental Informatics. Progress in IS. Springer, Cham. https://doi.org/10.1007/978-3-030-61969-5_1 

Manotas, I. et al. (2018) An Empirical Study of Practitioners' Perspectives on Green Software Engineering. 2016 IEEE/ACM 38th International Conference on Software Engineering (ICSE). 14-22 May 2016. https://doi.org/10.1145/2884781.2884810

Wolfram, N. et al. (2018) Sustainability in software engineering. 2017 Sustainable Internet and ICT for Sustainability (SustainIT). 06-07 December 2017. https://doi.org/10.23919/SustainIT.2017.8379798

(A confession: I added the Manotas reference when I was writing up this blog, since it looked like a pretty interesting recommendation, especially have previously been interested in the empirical studies of programmers).

Conference visit: Bletchley Park

The second day concluded with a visit to Bletchley Park, which isn’t too far from the campus. It seemed appropriate to visit a place where socio-technical systems played such an important role. I had visited Bletchley Park a few times before (I also recommend the computing museum, which is situated on the same site), so I sloped off early to try to avoid the rush hour to London.

Day 3: Consolidate and plan next steps

This final day contained a workshop that had the title “consolidate and plan next steps” and also had a session about professional development. Unfortunately, due to my schedule, I wasn't able to attend these sessions.

Reflections

I really liked the overarching theme of the event: the connection between software and society. Whilst listening to the opening comments it struck me that there were some clear points of crossover between research carried out within the SEAD group, and the research aims of the OU Critical Information Studies research group.

It was great working with others in the sustainability group to try to develop a very rough and ready research agenda. It was also interesting to begin to discover how fellow researchers in other institutions had been thinking along similar lines and have already taken some of our ideas further. 

One of my next steps is to continue with reading and exploring with an aim of developing a more thorough understanding of the research domain.

It was interesting that I was the only staff tutor at the event. It is hard for us to do research, since our time split in three different ways: academic leadership and management (of part time associate lecturers), teaching, and whatever time remains can be dedicated to research. For the next few years, my teaching ‘bit’ of time will be put towards doing my best to support TM354 Software Engineering.

Looking forward, what I’m going to try to do is to integrate different aspects of my work together: integrate the teaching bit with the research bit, with the tutor management bit. I’m also hoping (if everything goes to plan) to tutor software engineering for the first time.

As well as integrating everything together, another action is to begin to work with SEAD colleagues to attempt to put together a PhD project that relates to sustainable computing.

Update 20 July 23: After doing a couple of internet searches to find more about DevOps, I discovered a new book entitled Building Green Software (O'Reilly), which is due to be published in July 24. I also found an interview with the lead author (YouTube), and learnt about something called the Green Software Foundation. I feel really encouraged by these discoveries.

Permalink
Share post
Christopher Douce

Generative AI and the future of the OU

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 20 June 2023, 10:24

On 15 June 2023 I attended a computing seminar about generative AI, presented by Michel Wermelinger.

In some ways the title of his seminar is quite provocative. I did feel that his presentation relates to the exploration of a very specific theme, namely, how generative AI can play a role in the future of programming education; a topic which is, of course, being explored by academics and students within the school.

What follows is a brief summary of Michel's talk. As well as sharing a number of really interesting points and accompanying resources, Michel did a lot of screensharing, where he demonstrated what I could only describe as witchcraft.

Generative AI tools

Michel showed us Copilot, which draws on code submitted through GitHub. Copilot is said to use something called OpenAI Codex. The witchcraft bit I mentioned was this: Michel provided a couple of comments in a development environment, which were parsed by the Copilot, which generated readable and understandable Python code. There was no messing about with internet searches or looking through instruction books to figure out how to do something. Copilot offered immediate and direct suggestions.

Copilot isn’t, of course, the only tool that is out there. There are now a bunch of different types of AI tools, or a taxonomy of tools, which are emerging. There are tools where you pay for access. There are tools that are connected with integrated development environments (IDEs) that are available on the cloud, and there are tools where the AI becomes a pair programmer chatbot. There are other tools, such as learning environments that offer both documentation and the automated assessment of programming assignments.

The big tech companies are getting involved. Amazon has something called CodeWhisperer. Apparently Google has something called AlphaCode, which has participated in competitive programming competitions, leading to a paper in Nature which questions whether ChatGPT and AlphaCode going to replace programmers? There’s also something called StarCoder, which has also been trained on GitHub sources.  

AI can, of course, be used in other ways. It could be used to offer help and support to students who have additional requirements. AI could be used to transcribe lectures, and help student navigate across and through learning materials. The potential of AI being a useful learning companion has been a long held dream, and one that I can certainly remember from my undergraduate days, which were in the last century.

Implications

An important reflection is that Copilot and all these other AI tools are here to stay. It wouldn’t be appropriate to try to ban them from the classroom since they are already being used, and they already have a purpose. Michel also mentioned there is already a textbook which draws on Generative AI: Learn AI-assisted Python programming

Irrespective of what these tools are and what they do, everyone still needs to know the fundamentals. Copilot does not replace the need to understand language syntax and semantics and know the principles of algorithmic thinking. Developers and engineers need to know what is meant by thorough testing, how to debug software, and to write helpful documentation. They need to know how to set breakpoints, use command prompts, and also know things about version and configuration management.

An important question to ask is: how do we assess understanding? One approach is an increasing use of technical interviews, which can be used to assess understanding of technical concepts. This won’t mean an academic viva, but instead might mean some practical discussions which both help to assess student’s knowledge, and help them to prepare for the inevitable technical interviews which take place in industry.

New AI tools may have a real impact on not only what is taught but how teaching is carried out, particularly when it comes to higher levels of study. This might mean the reformulation of assignments, perhaps developing less explicit requirements to expose learners to the challenge of working with ambiguity, which students must then intelligently resolve.

Since these tools have the potential to give programmers a performative boost, assignments may become more bigger and more substantial. Irrespective of how assignments might change there is an imperative that students must learn how to critically assess and evaluate whatever code these tools might suggest. It isn’t enough to accept what is suggested; it is important to ask the question: “does the code that I see here make sense of offer any risks, given what I’m trying to do?”

A term that is new to me is: prompt engineering. This need to communicate in a succinct and precise way to an AI to get results that are practical and useful within a particular context. To get useful results, you need to be clear about what you want. 

What is the university doing?

To respond to the emergence of these tools the university has set up something called the Generative AI task and finish group. It will be producing some interim guidance for students and will be offering some guidance to staff, which will include the necessity to be clear about ethical and transparent use about AI. It is also said to highlight capabilities and limitations.  There will also be guidance for award boards and module results panels. The point here is that Generative AI is being looked at. 

Michel suggested the need for a working group within the school; a group to look at what papers coming out, what the new tools are, and what is happening across the sector at other institutions. A thought that it might be useful to widen it out to other schools, such as the School of Physical Sciences, and any others which make use of any aspect of coding and software development.

Reflections

Michel’s presentation was a very quick overview of a set of tools that I knew very little about. It is now pretty clear that I need to know a lot more about them, since there are direct implications for the practice of teaching and learning, implications for the school, and implications for the university. There is a fundamental imperative that must be emphasised: students must be helped to understand that a critical perspective about the use of AI is a necessity.

Although I described Michel’s demonstration of Copilot as witchcraft all he did was demonstrate a new technology.

When I was a postgraduate student, a lecturer once told me that one of the most fundamental and important concepts in computing was abstraction. When developers are faced with a problem that becomes difficult, they can be said to ‘abstract up’ a level, to get themselves out of trouble, and towards another way of solving a problem. In some senses, AI tools represent a higher level of abstraction; it is another way of viewing things. This doesn’t, of course, solve the problem that code still needs to be written.

I have also heard that one of the fundamental characteristics of a good software developer or engineer is laziness. When a programmer finds a problem that requires solving time and time again, they invariably develop tools to do their work for them. In other words, why write more code than you need to, when you can develop a tool that solves the problem for you?

My view is that both abstraction and laziness are principles that are connected together.

Generative AI tools have the potential to make programmers lazy, but programmers must gain an appreciation about how and why things work. They also need to know how to make decisions about what bits of code to use, and when. 

It takes a lot of effort to become someone who is effective at being lazy.

Permalink Add your comment
Share post
Christopher Douce

Preparing to chair TM354 Software Engineering

Visible to anyone in the world

Over the years I’ve had a connection with a number of Computing modules. I started as a tutor on M364, which then became TM356. When I became a staff tutor, I joined the TM352 for a short period of time, where I made a couple of very minor contributions, and TT284, where I offered some suggestions about web development frameworks. Most recently, I’ve been helping behind the scenes on TM112.

In the coming months, I’m going to be taking over the chairing TM354 Software Engineering. This module closely aligns with some of my long standing research interests. When I was a doctoral student, I studied the maintenance of object-oriented software, during which I looked at the subject of software metrics, where I made a very tiny contribution to the area. After completing all my studies, I worked in industry for a number of years, before returning to the university sector.

In September 2014, I attended a TM354 module briefing, where I wrote a quick summary of all the main components of the module. Since the briefing, I understand that the module has gradually changed and evolved over time.

From time to time, I shall be writing blog posts as an incoming module chair.

Figuring everything out

After a handover meeting, I have the following questions and the following tasks. 

I should add that I have mostly answered some of these questions:

  • Who do I need to speak to, to get things done? I know our curriculum manager, and fellow members of the module team, but there might well be other people who I need to know about.
  • What are the key dates and times by which things need to be done? I think I’ve seen a seen a document that contains the title ‘schedule’.
  • What are the biggest issues and challenges that immediately need to be dealt with? There is a lot going on at the moment in the university; I need to know what to prioritise.
  • What bits of software do I need to know about, and where should I go to find everything out?

Here are my immediate tasks. I have started some of them, but I need to work on others:

  • Acquaint myself with the module guide, assessment guide and accessibility guide.
  • Read all the module materials carefully (there is module mailing that is likely to be coming to me over the next couple of days)
  • Go through all the software engineering textbooks the outgoing module chair has left me.
  • Review all the assessment materials; the exams, the TMAs and and iCMAs.
  • Look at how the module makes use of Open Design Studio.
  • Listen to or watch any podcasts or videos that are used within the module.
  • Identify the file store or file areas that everyone uses to carry out assessment authoring.
  • Learn how much time every module team member has allocated to the module.

Reflections

I view TM354 as a really important level 3 module.

It is also a really interesting subject, since it links many different subjects together. On one hand, software engineering is quite a technical subject. On the other, it is about people and organisations; creating software is an intrinsically human activity. Software engineering processes and tools help to guide, manage and often magnify the creative contributions that people make to the development of software.

I would like to publicly acknowledge the contribution and efforts of our outgoing module chair, Leonor Barroca, who has worked on the module since the first presentation.

Permalink Add your comment
Share post
Christopher Douce

TM354 Software Engineering: briefing

Visible to anyone in the world
Edited by Christopher Douce, Monday, 11 Sept 2023, 16:27

On Saturday 27 September I went to a briefing for a new OU module, TM354 Software Engineering.   I have to secretly confess that I was quite looking forward to this event for a number of reasons: I haven’t studied software engineering with the OU (which meant that I was curious), I have good memories of my software engineering classes from my undergraduate days and I also used to do what was loosely called software engineering when I had a job in industry.  A big question that I had was: ‘to what extent is it different to the stuff that I studied as an undergrad?’  The answer was: ‘quite a bit was different, but then again, there was quite a bit that was the same too’.

I remember my old undergrad lecturer introducing software engineering by saying something like, ‘this module covers all the important computer stuff that isn’t in any of the other modules’.   It seemed like an incredibly simple description (and one that is also a bit controversial), but it is one that has stuck in my mind.  In my mind, software engineering is a whole lot more than just being other stuff.

This blog post summary of the event is mostly intended for the tutors who came along to the day, but I hope it might be useful for anyone else who might be interested in either studying or tutoring the module.  There’s information about the module structure, something about the software that we use, and also something about the scheduling of the tutorials.

Module structure

TM354 has three blocks, which are also printed books.  These are: Block 1 – from domain to requirements, Block 2 – from analysis to design, and Block 3 – from architecture to product.  An important aspect to the module is a set of case studies.  The module is also supported by a module website and, interestingly, a software tool called ShareSpace that enables students to share different sketches or designs.  (This is a version of a tool that has been used in other modules such as U101, the undergraduate design module, and T174, an introduction to engineering module).

Block 1 : from domain to requirements

Each block contains a bunch of units.  The first unit is entitled ‘approaches to software development’, which, I believe, draws a distinction between plan driven software development and agile software development.  I’ve also noted down the phrase ‘modelling with software engineering’.  It’s great to see agile mentioned in this block, as well as modelling.  When I worked in industry as a developer, we used bits of both.

The second unit is called requirements concepts.  This covers functional requirements, non-functional (I’m guessing this is things like ‘compatibility with existing systems’ and ‘maintainability’ – but I could be wrong, since I’ve not been through the module materials yet), testing, and what and how to document.  Another note I’ve made is: ‘perspectives on agile documentation’.

Unit three is from domain modelling to requirements.  Apparently this is all about business rules and processes, and capturing requirements with use cases.  Prototyping is also mentioned.  (These are both terms that would be familiar with students who have taken the M364 Interaction Design module).  Unit four is all about the case study (of which I have to confess that I don’t know anything about!)

Block 2: from analysis to design

Unit five is about structural modelling of domain versus the solution.  Unit six is about dynamic modelling, which includes design by contract.  Unfortunately, my notes were getting a bit weak at this point, but I seem to remember thinking, ‘ahh… I wonder if this relates to the way that I used to put assertions in my code when I was a coder’.  This introduction was piquing my interest.

Unit seven was entitled, ‘more dynamic modelling’, specifically covering states and activities, and capturing complex interactions.  Apparently the black art of ‘state machines’ are also covered in this bit.  (In my undergrad days, state machine were only covered in the completely baffling programming languages course) .  Unit eight then moves onto the second part of the case study which might contain domain modelling, analysis and design.

Block 3: from architecture to product

This block jumped out at me as being the most interesting (but this reflects my own interests).  Unit nine was about ‘architecture, patterns and reuse’.  Architecture and requirements, I’ve noted, ‘go hand in hand’.  In this section there’s something about architectural views and reuse in the small and reuse in the large.  During the briefing there was a discussion about architectural styles, frameworks and software design patterns.

When I was an undergrad, software patterns hadn’t been discovered yet.  It’s great to see them in this module, since they are a really important subject.  I used to tell people that patterns are like sets of abstractions that allow people to talk about software.  I think everyone who is a serious software developer should know something about patterns.

Unit ten seems to take a wider perspective, talking about ‘building blocks and enterprise architectures’.  Other topics include component based development, services and service oriented architectures (which is a topic that is touched upon in another module, and also potentially the forthcoming TM352 module that covers cloud computing).

Unit eleven is about quality, verification, metrics and testing.  My undergrad module contained loads of material on metrics and reliability, and testing was covered only in a fairly theoretical way, but I understand that test-driven development is covered in this module (which is a topic that is linked to agile methods).  I’ll be interested to look at the metrics bit when this bit of the module is finalised.

The final unit takes us back to the case study.  Apparently we look at architectural views and patterns.  Apparently there are also a set of further topics that are looked.  I’m guessing that students might well have to go digging for papers in the OU’s huge on-line library.

Software

I’ve mentioned ShareSpace, which is all about sharing of software models with other students (modelling is an important skill), to enable students to gain experience of group work and to see what other students are doing and creating: software development invariably happens in teams.  Another important bit of software is an open source IDE (integrated development environment) called NetBeans.  I’m not sure how NetBeans is going to be used in this module, but it is used across a number of different OU modules, so it should be familiar to some TM354 students.

Assessment

TM354 comprises of three tutor marked assignments, a formative quiz at the end of every unit (that students are strongly encouraged to complete), and an end of module exam.  The exam comprises of two parts: a part that has questions about concepts, and a second bit that contains longer questions (I can’t say any more than this, since I don’t know what the exam looks like!)

Tutorials

Each tutor is required to deliver two hours of face to face tuition, and eight hours of on-line sessions through OU Live (as far as I understand).  In the London region, we have three tutors, so what we’re doing is we’re having all the groups come to the same events and we’re having each tutor deliver a face to face session to support students through every block and every TMA. 

We’re also planning on explicitly scheduling six hours of OU Live time, leaving two hours that the tutor can use at his or her discretion throughout the module (so, if there are a group of students who struggle with concepts such as metrics, design by contract, or patterns, a couple of short ad-hoc sessions can be scheduled). 

All the OU Live sessions will be presented through a regional OU Live room.  This means that students in one tutor group can visit a session that is delivered by another London tutor.  The benefit of explicitly scheduling these sessions in advance is that all these events are presented within the student’s module calendar (so they can’t say that they didn’t know about them!)  All these plans are roughly in line with the new tuition strategy policy that is coming from the higher levels of the university.  A final thought regarding the on-line sessions is that it is recommended that tutors record them, so students can listen to the events (and potentially go through subjects that they find difficult) after an event has taken place.

A final note that I’ve made in my notebook is ‘tutorial resources sharing (thread to share)’.  This is connected to a tutor’s forum that all TM354 tutors should have access to.  I think there should be a thread somewhere that is all about the sharing of both on-line and off-line (face to face) tutorial resources.

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