Håkan Burden

Industrial Adoption of Model-Driven Engineering: Are the Tools Really the Problem?

An oft-cited reason for lack of adoption of model-driven engineering MDE is poor tool support. However, studies have shown that adoption problems are as much to do with social and organizational factors as with tooling issues. This paper discusses the impact of tools on MDE adoption and places tooling within a broader organizational context. The paper revisits previous data on MDE adoption 19 in-depth interviews with MDE practitioners and re-analyzes the data through the specific lens of MDE tools. In addition, the paper presents new data 20 new interviews in two specific companies and analyzes it through the same lens. The key contribution of the paper is a taxonomy of tool-related considerations, based on industry data, which can be used to reflect on the tooling landscape as well as inform future research on MDE tools.

Natural language generation from class diagrams

A Platform-Independent Model (PIM) is supposed to capture the requirements specified in the Computational Independent Model (CIM). It can be hard to validate that this is the case since the stakeholders might lack the necessary training to access the information of the software models in the PIM. In contrast, a description of the PIM in natural language will enable all stakeholders to be included in the validation. We have conducted a case study to investigate the possibilities to generate natural language text from Executable and Translatable UML. In our case study we have considered a static part of the PIM; the structure of the class diagram. The transformation was done in two steps. In the first step, the class diagram was transformed into an intermediate linguistic model using Grammatical Framework. In the second step, the linguistic model is transformed into natural language text. The PIM was enhanced in such a way that the generated texts can both paraphrase the original software models as well as include the underlying motivations behind the design decisions.

A taxonomy of tool-related issues affecting the adoption of model-driven engineering

Although poor tool support is often blamed for the low uptake of model-driven engineering (MDE), recent studies have shown that adoption problems are as likely to be down to social and organizational factors as with tooling issues. This article discusses the impact of tools on MDE adoption and practice and does so while placing tooling within a broader organizational context. The article revisits previous data on MDE use in industry (19 in-depth interviews with MDE practitioners) and reanalyzes that data through the specific lens of MDE tools in an attempt to identify and categorize the issues that users had with the tools they adopted. In addition, the article presents new data: 20 new interviews in two specific companies—and analyzes it through the same lens. A key contribution of the paper is a loose taxonomy of tool-related considerations, based on empirical industry data, which can be used to reflect on the tooling landscape as well as inform future research on MDE tools.

Teaching Agile: addressing the conflict between project delivery and application of Agile methods

This paper analyses the changes we have made in teaching agile methodologies, practices, and principles in four courses in order to address a specific dilemma: students need to apply agile methods in order to learn them, but when complementing our courses with applied content, we face the problem that students perceive the learning and application of agile methods as less important than delivering a finished product at the end of the course. This causes students to not apply theoretical process knowledge and therefore to not develop necessary skills associated with working with defined processes in the industry. Concretely, we report on our experience with teaching Scrum with Lego, removing formal grading requirements on the delivered product, emphasising process application in post-mortem reports, and organisational changes to support the process during supervision. These changes are analysed in the context of student satisfaction, teacher observations, and achievements of learning outcomes. We also provide an overview of the lessons learnt to help guide the design of courses on agile methodologies.

Executable and Translatable UML -- How Difficult Can it Be?

Executable and Translatable UML enables Model-Driven Architecture by specifying Platform-Independent Models that can be automatically transformed into Platform-Specific Models through model compilation. Previous research shows that the transformations result in both efficient code and consistency between the models. However, there are neither results for the effort of introducing the technology in a new context nor on the level of expertise needed for designing the Platform-Independent Models. We wanted to know if teams of novice software developers could design Executable and Translatable UML models without prior experiences of software modelling. As part of a new university course we conducted an exploratory case study with two data collections over two years. Bachelor students were given the task to design a hotel reservation system and the necessary test cases for verifying the functionality and structure of the models within 300 hours, using Executable and Translatable UML. In total, 43 out of 50 teams succeeded in delivering verified and consistent models within the time frame. During the second data collection the students were given limited tool training. This gave a raise in the quality of the models. Due to the executable feature of the models the students were given constant feedback on their design until the models behaved as expected, with the required level of detail and structure. Our results show that using Executable and Translatable UML does not require more expertise than a bachelor program in computer science. All in all, Executable and Translatable UML could play an important role in future software development.

On the effect of using SysML requirement diagrams to comprehend requirements: results from two controlled experiments

We carried out a controlled experiment and an external replication to investigate whether the use of requirement diagrams of the System Modeling Language (SysML) helps in the comprehensibility of requirements. The original experiment was conducted at the University of Basilicata in Italy with Bachelor students, while its replication was executed at the University of Gothenburg in Sweden with Bachelor and Master students. A total of 87 participants took part in the experiment and its replication. The achieved results indicated that the comprehension of requirements is statistically significant when requirements specification documents include requirement diagrams without any impact on the time to accomplish comprehension tasks. On the basis of our results, we also present and discuss possible implications from the practitioner and researcher perspectives.

No silver brick: Opportunities and limitations of teaching Scrum with Lego workshops

© 2017 Education in Software Engineering has to both teach technical content such as databases and programming but also organisational skills such as team work and project management. While the former can be evaluated from a product perspective, the latter are usually embedded in a Software Engineering process and need to be assessed and adapted throughout their implementation. The in-action property of processes puts a strain on teachers since we cannot be present throughout the students’ work. To address this challenge we have adopted workshops to teach Scrum by building a Lego city in short sprints to focus on the methodological content. In this way we can be present throughout the process and coach the students. We have applied the exercise in six different courses, across five different educational programmes and observed more than 450 participating students. In this paper, we report on our experiences with this approach, based on quantitative data from the students and qualitative data from both students and teachers. We give recommendations for learning opportunities and best practices and discuss the limitations of these workshops in a classroom setting. We also report on how the students transferred their methodological knowledge to software development projects in an academic setting.

Industrial experiences from multi-paradigmatic modelling of signal processing

Embedded software is often composed of interacting domains. A common problem is that the implementation intertwines the different domain solutions with each other and the platform-specific details. The result is a code mass that is hard to understand, maintain and reuse. We report on an effort to overcome these problems by using a domain-specific executable modelling language for each included domain. The application was delivered for the Ericsson LTE-A uplink test bed as part of the 4G telecommunications system that was presented at the Mobile World Congress in Barcelona, February 2011. The requirements for the delivered software included efficient real-time performance for signal processing on new hardware as well as a firm non-negotiable delivery deadline. Our results show that the chosen modelling languages allowed independent implementation and validation of each domain. Neither did the integration of the separate solutions imply additional problems.

Crunch time: the reasons and effects of unpaid overtime in the games industry

The games industry is notorious for its intense work ethics with uncompensated overtime and weekends at the office, also known as crunch or crunch time. Since crunch time is so common within the industry, is it possible that the benefits of crunch time outweigh the disadvantages? By studying postmortems and conducting interviews with employees in the industry, we aim to characterise crunch time and discover its effects on the industry. We provide a classification of crunch, i.e., four types of crunch which all have distinct characteristics and affect the product, employees and schedule in various ways. One of the crunch types stands out from the others by only having positive effects on product and schedule. A characteristic that all of the types have in common is an increase in stress levels amongst the employees. We identify a set of reasons for crunch and show that crunch is less pronounced in game studios where prioritisation of features is a regular practice.

Teaching and Fostering Reflection in Software Engineering Project Courses

Reflection is an important part of agile software processes as witnessed, e.g., by the Sprint Retrospectives in Scrum or by the various learning feedback loops in XP. Engineering education also emphasizes the importance of reflective practice, e.g., in Kolb’s learning cycle and Schon’s reflection-in/on-action. Our contribution in this chapter is a toolkit for reflective practice that shows how reflection can be used by software engineering students for two purposes: to reflect on the application of a software process and to reflect on their learning process. In order to help students understand the purpose of reflection and how to approach reflection, we follow a cognitive apprenticeship approach in which the teachers reflect about the events in the course, their own goals, and how they are aligned with the teaching. Students are asked to reflect during supervisions and as part of their written assignments from the very beginning of the course. We thus combine a meta-cognitive approach where reflection is taught as a learning strategy with a common software engineering practice of continuous improvement through reflection. We evaluate the reflective model and a course design based on it through the student, teacher, and theoretical lenses based on empirical data.