An Experience Report on Designing and Delivering of a Software Engineering Education Module to Enhance Employability Skills

1. Introduction

Software engineering education programs have evolved from computer science programs in last few years to cater employment demands. Software engineering programs continue to focus on theoretical and technical computer science topics [1]. This seems to create a gap between software engineering skills learnt in the university and the skills needed in employment [1].

Different research highlights the gaps from different perspectives. In 2000 Shaw outlined a software engineering education roadmap [2]. The roadmap focused on moving away from the content and considering how the curriculum could focus on different software engineering roles.

An investigation on graduate software developer experience in workplace reported that the students generally demonstrate good design skill, but lack other important skills related to software engineering [3]. This investigation has been carried out in one large organization.

There are many investigations highlighting the gaps. A later investigation [4] presented that student lacked software engineering skills like testing, configuration management, use of proper tools, problem solving, requirement, development process, communication etc. from software engineering point of view. Another investigation [5] concluded that graduating students do not possess skills to deliver large scale software engineering projects. This is very much aligned with the earlier investigation.

The investigation presented in [1] considers data from 12 countries across US, Canada, Europe, Asia, Africa, and Australia and presents a global view of the gap between academic skills acquired through software engineering education and skill requirement in employment. The most important gaps are identified in the areas of Software Engineering models and methods, Software Engineering process, Design and Architecture, Requirement, Quality, Configuration management and testing.

Other investigations also hint at similar types of gaps between software engineering education and requirement of employers. The presented investigations consider data across the globe. Consequently, we can summarize the gaps as a baseline of gaps between education and employment.

The seven base line gaps are a) importance of role playing in the curriculum, b) software engineering method & development process, c) requirement & problem solving, d) design & architecture, e) configuration management & testing, f) quality and g) communication.

United Kingdom is no exception in terms of gaps and the same is confirmed by [6]. It presents high unemployment of computer science graduates versus the high demand for such skills. Most of the topics covered in software engineering courses in UK universities concentrate on different aspect of programming, programming paradigms, designs, and mathematical foundation. A study on what is taught while teaching software engineering in UK universities [7] also concluded that a) software engineering is not all about programming and b) software engineering graduates fill in different roles, each of which need specific content.

The studies mentioned above, and similar studies consider industry as one bucket. From practicing experience as a software engineer for more than two decades, the author appreciates the difference between different type of industries e.g., software development organization, consulting organization, start-up organization, large organizations, Small and Medium Enterprises etc. Keeping the difference in mind, we conducted an analysis on the kind of companies our graduates are engaged with as employees or placement students. From the analysis, we prioritized the gaps that we need to address to facilitate our students’ better enablement for employment. We envisaged the ‘Contemporary Software Engineering’ module to address those gaps

The following section describes the background study to prioritise the gaps. The subsequent two sections describe the module design to address the gap and the module delivery mechanism. The discussion section reflects on the lessons learnt from first few occurrences of the module and how students are perceiving this module. The paper concludes with a conclusion section summarising the experience and outlining future enhancements.

2. Background Study

To prioritize the gaps, we analyzed the kind of organizations our students engage with as employees or placement student. Our baseline analysis is based on internally published data for 2018-19 by our university employability department.

The employment data for software engineering and computer science graduates for 2018-19 are depicted in the following chart. It is based on the number of students responding to the employability questionnaire.

Figure 1. Employment Summary.

Figure 1. Employment Summary.

The placement data for software engineering and computer science graduates for 2018-19 are depicted in the following chart

Figure 2. Placement Summary.

Figure 2. Placement Summary.

Both placement and employment data shows that most of our students engage with SME organizations, Local software development organizations and specialized software development organizations. SME organization shares the largest percentage of students. Very few students get engaged with large global organizations.

By SME organizations, we mean small and medium enterprises specializing in different business and not having any software development experience. Local software development organizations are those who develop software for different clients within the UK and based locally inside the UK. We segregated specialized software development organizations from local software development organizations based on the nature of software development. Specialized software development organizations develop software targeted to a specific industry such as education or healthcare.

As part of the background study, we tried to identify the challenges faced by SME organizations through literature review and our engagement experience with different local SME organizations to prioritize the seven base line gaps presented in the introduction.

Though we have presented local software development organizations and specialized software development organizations as separate categories, both are software development organizations on different scales. We assume their challenges are captured in investigations like large global organizations. From our experience of engaging with local SME organizations, we have found out that most of them are like start up organizations from a software development perspective. So, to understand their challenges we relied on literature review and our experience.

Melegati et al identified major challenges of software start-ups and suggested some way forwards to overcome those in their chapter [8]. They have highlighted on 'thriving in technology uncertainty' and 'time spent developing features that users are not interested in' as two major challenges. The chapter has also emphasized team related challenges like 'lot of activities in a short time' and building entrepreneurial team'. The chapter recommends getting help of methodology from Lean Startup [9] to avoid mistakes already done by other people.

‘Thriving in technology uncertainty’ can be mapped to ‘design and architecture’ from the baseline gaps as ‘design & architecture’ focuses on technical solution. ‘Time spent developing features that users are not interested in’ can be mapped to ‘requirement & problem solving’. Team related challenges can be mapped to ‘software engineering method & development process’.

Melegati, J et al [10] analyzed four start-up organizations and discussed the inhibitors and enablers. Finally, they concluded that experiment driven software development as an important approach can help software start-up succeed. Clearly experiment cannot be done unless the requirement is not clear, and as a result it can be mapped to ‘requirement & problem solving’.

Gupta V et al [11] studied software start-ups from US, UK and India and identified three major challenges a) handling software evolution, b) releasing product to the market and c) software engineering. There are other similar studies like [12] hinting at the same factors.

‘Handling software evolution’ maps to ‘design & architecture’ from our identified baseline in the introduction. ‘Releasing product to the market’ maps to ‘requirement & problem solving’. ‘Software engineering’ directly links to ‘software engineering method & development process’.

From literature review, we can summarize the challenges faced by start-up organizations as ‘design & architecture’, ‘requirement & problem solving’ and ‘software engineering methos & development process’. Now we will reflect on our engagement experience with local SME organizations to understand their challenges. We from our university engage with local SME organizations through different knowledge exchange programs Knowledge Transfer Partnership [13]. Let us present some engagement examples

As part of Knowledge Transfer Partnership, we worked with a document management organization. They had a home-grown project management software developed using legacy technologies and they wanted to build a digital platform to handle all business operations for their organization. Before this project they did not have any in-house software development team. We had to establish requirement management techniques, define software development methods and create an architecture to develop the solution satisfying the requirements.

As part of another program, we engaged with another SME organization implementing six sigma to optimize process for manufacturing clients. They were aware that they needed software to help them scaling up but were not aware of what the software should do. We helped them formulating in understanding requirement that can solve their problem using design thinking approach.

To site another example, we engaged with a mechanical engineering organization to review a proof-of-concept IoT solution that they built to monitor health parameters in a mechanical production process. The organization wanted to review the solution before building it on a large scale. We found that the solution works for the purpose, but the architecture was not robust (e.g., they were using two different cloud service providers for doing different things without any rationale). Their proof of concept was developed by one developer and there was no software engineering process to scale up the development team.

We have similar other examples. Our engagement experience identifies the challenges faced by local SME organizations as ‘design & architecture’, ‘requirement & problem solving’ and ‘software engineering methos & development process’. This is aligned with our findings from literature review about the challenges of start-up organizations.

We prioritized addressing ‘design & architecture’, ‘requirement & problem solving’ and ‘software engineering methos & development process’ to be addressed in our module. However, design has been taught in other programming modules. So, we addressed the architecture more. We did not prioritize ‘configuration management & testing’ as that is covered in other project modules. Though ‘quality’ is not part of the challenges faced by SME organizations, we prioritized that for those students who get engaged with large organizations. We decided to address ‘role playing’ and ‘communication’ as part of the module delivery as opposed to design.

The next section describes the content design of the module demonstrating how we addressed the prioritized four gaps. The module delivery section highlights how we address the other two prioritized gaps

3. Module Design

As per our prioritization we designed the content of the module ‘Contemporary Software Engineering’ keeping ‘requirement & problem solving’, ‘architecture’, ‘software engineering methos & development process’ and ‘quality’ in mind.

Initially we offered this module to final year software engineering students. We chose the final year, as then students will have an idea about programming, design and development. Additionally, some of our final year students go for one year placement before concluding final year. We envisaged that they would be able to appreciate the module and can share their placement experiences with others to make the module more effective.

As part of the module design, we referred to the modules taught in previous years to avoid potential overlap. We provided a few problems for the students to work with. The problems are chosen in such a way that students can relate to them easily as a user. For example, keeping international students in mind two of the problems given were a) Finding the right course in the right university for a student and b) Immigration helper for international students. Students were expected to choose one of the problems and identify requirements, arrive at a technical solution and design a software engineering method to develop the solution for the problem. Students would be allowed to suggest their own problem as well.

Before final year, students learn documenting a given set of requirements. They do not get much opportunity to arrive at a requirement from a problem description and arrive at a solution for the problem. So as part of this module, we introduced a widely used contemporary technique of design thinking [14] to identify requirements empathizing with users and find the right solution to the problem. Design thinking is one of the most recognized approaches that drives innovation and creates a solution that end users need [15].

We decided to leverage IBM enterprise design thinking approach [16] for practicing design thinking in the class, as this approach has been harvested from various client engagements. The requirement & problem solving is handled through the introduction of design thinking.

After requirement identification, the module introduces how to arrive at an initial solution architecture. The module introduced reference architecture [17]. The module introduced reference architecture for different technologies and domains and provided guidance on how to choose a reference architecture and leverage that to arrive at a software architecture to solve a particular problem.

We planned to introduce software engineering method, after architecture. There are different software development lifecycles, but the lifecycles are not prescriptive. They need tailoring to arrive at a software engineering method for developing a solution, based on project characteristics. The module aimed to enable students about tailoring to arrive at the method.

R Akbar [18] identified that developers and project managers do not have proper guidelines to tailor a method. He tried to suggest a guideline for tailoring an agile process considering software project characteristics as an important factor. There are similar guidelines available, but as the module needs to be lifecycle agnostic it did not consider those. The author has more than two decades of experience tailoring and arriving it software development method for different engagements. His practical experience is leveraged in designing the module content.

We highlighted a contemporary practice driven approach of software engineering, where students can learn about different practices, the tools that help realizing the practices, and how to decide about the applicability of the practices in a particular situation. The module leveraged IBM Garage method [19] as a reference for practice driven approach, as a) the method is harvested from many project experiences and gets continuously updated from applied experience and b) documentation is available in public domain. The module also introduced Lean start up methodology [20] and discussed how it can be applied to optimize software engineering methods for developing a solution. This part of the module aims to enhance students’ practical understanding of Software Engineering Methods & Development Process.

Finally, to facilitate students’ understanding of software quality, the module introduced ISO 9000 family [21]. As the module is specifically for software engineering, more stress was given on the key process areas of Software Engineering Institute Capability Maturity Model [22].

Initially the module was assessed using two parts, 70% coursework and 30% examination. Later based on delivery experience and student feedback, we changed the assessment as 100% coursework.

The next section describes the delivery modality of the module highlighting how we address ‘role playing’ and ‘communication’.

4. Discussion

We have run the module for three years and are preparing for the fourth cohort in 2024-25 academic year. The module is well received by the students from the inception of the module and gets good feedback in module review.

In addition to University’s regular module feedback, we gather specific feedback each year and enhance the module content, delivery and sequence of delivery based on that feedback. For example, the module was offered to B.Engg (Software Engineering) students in the first year, later it was offered to B.Sc (Computer Science) and B.Sc (Computer Science with AI) students also based on student reception.

In the first instance, assessment was a combination of 70% course work and 30% examination. Based on student feedback, and in alignment with the aim of the module, we removed the examination and transformed it as 100% course work. The coursework is extensive to assess all learning outcomes.

We use the following questionnaire to gather student feedback every year. Except for the last question, all others are yes/no/not applicable questions.

• Did you learn anything new?
• Did you like the module delivery mechanism?
• Did you have to do a lot of work outside the classroom for your assignment?
• Could you relate the topics with your placement experience?
• Do you think it will help you in your job?
• Do you regret taking this module?
• Additional comments (if any)

Overall, we enjoy running this module and are learning a lot. We have learnt a few lessons. Firstly, for designing a new module, it is always advisable to judge how and where students will apply the knowledge acquired in the module. Secondly, students appreciate experiencing techniques applied in the real world. Being able to use enterprise design thinking or learning about software engineering practices leveraging IBM garage method was well appreciated. Finally, students enjoy working with problems that they can relate to their day-to-day life and are not much discussed in textbooks or learning materials. The problems presented in this module create a positive environment. It is also important to have an informal classroom environment to support learning.

However, the strength of the module is one of its biggest weaknesses also. The module delivery is fully dependent on in-class engagement of students, attendance of students had a major role to achieve the learning. Due to unavoidable circumstances (e.g., self-isolation due to proximity of covid patient, job interview, horrible weather condition, etc.) we always do not get desired attendance from all students. To mitigate this, we have designed the delivery schedule in a flexible way, keeping buffer time to allow additional support sessions or catch-up if required.

Next section concludes the paper.