International audience

The world faces escalating crises: record-breaking temperatures, widespread fires, severe flooding, increased oceanic microplastics, and unequal resource distribution. Academia introduces courses around sustainability to meet the new demand, but software engineering education lags behind. While software systems contribute to environmental issues through high energy consumption, they also hold the potential for solutions, such as more efficient and equitable resource management. Yet, sustainability remains a low priority for many businesses, including those in the digital sector. Business as usual is no longer viable. A transformational change in software engineering education is urgently needed. We must move beyond traditional curriculum models and fully integrate sustainability into every aspect of software development. By embedding sustainability as a core competency, we can equip future engineers not only to minimise harm but also to innovate solutions that drive positive, sustainable change. Only with such a shift can software engineering education meet the demands of a world in crisis and prepare students to lead the next generation of sustainable technology. This article discusses a set of challenges and proposes a customisable education roadmap for integrating sustainability into the software engineering curricula. These challenges reflect our perspective on key considerations, stemming from regular, intensive discussions in regular workshops among the authors and the community, as well as our extensive research and teaching experience in the field.

Background: This paper documents an unsuccessful attempt to develop a comprehensive artefact to mitigate software product variability in complex organisational contexts. The narrative falls into two parts: the endeavour to create the artefact; and the subsequent retrospective analysis, designed to understand the reasons for its lack of adoption in practical settings. The primary emphasis here is on the retrospective analysis, which offers the most valuable insights and lessons learned.

Marine in-situ data is collected by sensors mounted on fixed or mobile systems deployed into the ocean. This type of data is crucial both for the ocean industries and public authorities, e.g., for monitoring and forecasting the state of marine ecosystems and/or climate changes. Various public organizations have collected, managed, and openly shared in-situ marine data in the past decade. Recently, initiatives like the Ocean Decade Corporate Data Group have incentivized the sharing of marine data of public interest from private companies aiding in ocean management. However, there is no clear understanding of the impact of data quality in the engineering of systems, as well as on how to manage and exploit the collected data. In this paper, we propose main architectural decisions and a data flow-oriented component and connector view for marine in-situ data streams. Our results are based on a longitudinal empirical software engineering process, and driven by knowledge extracted from the experts in the marine domain from public and private organizations, and challenges identified in the literature. The proposed software architecture is instantiated and exemplified in a prototype implementation.

Achieving the UN Sustainable Development Goals (SDGs) demands a shift by industry, governments, society, and individuals to reach adequate levels of awareness and actions to address sustainability challenges. Software systems will play an important role in moving towards these targets. Sustainability skills are necessary to support the development of software systems and to provide sustainable IT-supported services for citizens. While there is a growing number of academic bodies including sustainability education in engineering and computer science curricula, there is not yet comprehensive research on the competencies and skills required by IT professionals to develop such systems. This study aims to identify the industrial sustainability needs for education and training from software engineers’ perspective. For this, we answer the following questions: (1) what are the interests of organisations with an IT division with respect to sustainability? (2) what do organisations want to achieve with respect to sustainability, and how? and (3) what are the sustainability-related competencies and skills that organisations need to achieve their sustainability goals? We conducted a qualitative study with interviews and focus groups with experts from twenty-eight organisations with an IT division from nine countries to understand their interests, goals, and achievements related to sustainability, and the skills and competencies needed to achieve their goals. Our findings show that organisations are interested in sustainability, both idealistically and increasingly for core business reasons. They seek to improve the sustainability of software processes and products but encounter difficulties, like the trade-off between short-term financial profitability and long-term sustainability goals or an unclear understanding of sustainability concepts from a software engineering perspective. To fill these gaps, they have promoted in-house training courses, collaborated with universities, and sent employees to external training. The acquired competencies should support translating environmental and social benefits into economic ones and make sustainability an integral part of software development.

Digital fabrication machines are controlled through code. Software that generates this code, such as slicers, often rely on abstractions that restrict practitioners from exploring the full design space. We contribute Vespidae, a programming framework for developing custom toolpaths and visualizations. Vespidae module types include Toolpaths, Actions, Solvers, and Export. These generate geometry, specify machine tasks, sort and visualize action sequences, and generate and stream machine code. We show example workflows that demonstrate Vespidae’s strengths in supporting iteration and unconventional practice. These include non-planar 3D printing, varying a print’s tactile qualities with under-extrusion, and exploring the design space of milling marks. Furthermore, we used Vespidae over the course of six months to explore multi-material 3D printing for energy storage devices on a custom machine. Finally, we discuss how Vespidae contributes to a movement in HCI arguing for human-machine collaboration.

Background: In-situ marine data has a low reusability rate, primarily due to differences in data usage objectives among stakeholders in data ecosystems. The extreme cost of collecting and maintaining in-situ marine data threatens the sustainable usage of the ocean. Aims: This paper provides an overview of current data and data quality (DQ) requirements. We also investigate limitations in the current practices that obstruct data reusability. The ultimate objective is to improve data requirements elicitation, leading to enhanced data reusability. Method: We interviewed 14 marine practitioners and researchers from 7 organizations with extensive experience in collecting, managing, and utilizing in-situ marine data. Results: We identify 9 representative use cases in the fishery, energy, and marine sciences industries, as well as their data and DQ requirements. The results give guidance to data producers to produce data meeting demands of a wider range of data consumers. At the same time, data consumers can refer to the compilation to identify existing data suiting their needs. Furthermore, we recommend a roadmap taken into account during requirements elicitation to improve 6 limitations in the current practices that obstruct data reusability.

The ocean is vital for humankind but may cause catastrophes when unhealthy. Although there have been efforts to build ocean monitoring systems, the understanding of the underwater environment is limited due to the cost and challenges of obtaining real-time marine data. One potential solution is to build stationary ocean observation systems based on wireless communication due to its affordable cost. In this study, we divide these systems into three components: 1) underwater data acquisition; 2) network communication; and 3) data management. We investigate the engineering challenges associated with each component, the causes, and how they relate. The literature has not discussed the technical issues of building stationary smart ocean monitoring systems entirely based on wireless communication yet. This article fills that research gap by conducting semi-structured interviews with 17 experts knowledgeable about underwater sensors, underwater acoustic communication, offshore network communication, and underwater data usage. The identified challenges are compared with the literature to assess whether our findings are novel or are a confirmation of what have been already found in prior publications. The Internet of Things (IoT) used in smart city platforms is quite advanced, but the Internet of Underwater Things (IoUT) employed in smart ocean monitoring systems has several unresolved issues; although IoT is viewed as a foundation for IoUT. Therefore, we compare fundamental differences between the technologies used in the smart city and the smart ocean domains, explaining why some of our identified challenges are unique in the marine context.

In automotive, stage-gate processes have previously been the norm, with architecture created mainly during an early phase and then used to guide subsequent development phases. Current iterative and Agile development methods, where the implementation evolves continuously, changes the role of architecture. We investigate how architecture evaluation can provide useful feedback during development of continuously evolving systems. Starting from the Architecture Tradeoff Analysis Method (ATAM), we performed architecture evaluation, both in a national research project led by an automotive Original Equipment Manufacturer (OEM), and at the OEM, in the context of continuous development. This allows us to include the experience of several architects from different organizations over several years. Using data produced during the evaluations we perform a post-hoc analysis to derive initial findings. We then validate and refine these findings through a series of focus groups with architects and industry experts. We propose principles of continuous evaluation and evolution of architecture, and based on these discuss a roadmap for future research. In iterative development settings, the needs are different from what typical architecture evaluation methods provide. Our principles show the importance of dedicated feedback-loops for continuous evolution of systems and their architecture.

Abstract In model-driven software engineering, models are used in all phases of the development process. These models must hold a high quality since the implementation of the systems they represent relies on them. Several existing tools reduce the burden of manually dealing with issues that affect models’ quality, such as syntax errors, model smells, and inadequate structures. However, these tools are often inflexible for customization and hard to extend. This paper presents a customizable and extensible model repair framework, PARMOREL, that enables users to deal with different issues in different types of models. The framework uses reinforcement learning to automatically find the best sequence of actions for repairing a broken model according to user preferences. As proof of concept, we repair syntactic errors in class diagrams taking into account a model distance metric and quality characteristics. In addition, we restore inter-model consistency between UML class and sequence diagrams while improving the coupling qualities of the sequence diagrams. Furthermore, we evaluate the approach on a large publicly available dataset and a set of real-world inspired models to show that PARMOREL can decide and pick the best solution to solve the issues present in the models to satisfy user preferences.

Abstract Artificial intelligence has already proven to be a powerful tool to automate and improve how we deal with software development processes. The application of artificial intelligence to model-driven engineering projects is becoming more and more popular; however, within the model repair field, the use of this technique remains mostly an open challenge. In this paper, we explore some existing approaches in the field of AI-powered model repair. From the existing approaches in this field, we identify a series of challenges which the community needs to overcome. In addition, we present a number of research opportunities by taking inspiration from other fields which have successfully used artificial intelligence, such as code repair. Moreover, we discuss the connection between the existing approaches and the opportunities with the identified challenges. Finally, we present the outcomes of our experience of applying artificial intelligence to model repair.

Abstract Digital fabrication tools such as 3D printers, computer-numerically controlled (CNC) milling machines, and laser cutters are becoming increasingly available, ranging from consumer to industrial versions. Recent studies have shown that users, ranging from researchers, to industry professionals, to hobbyists, are interested in modifying and changing the inherit workflows these tools provide. As an answer to this, these users are increasingly modifying and customizing their machines by changing the work envelope, adding different end-effectors, and creating their own fabrication workflows in software. However, customizing, modifying and creating digital fabrication machines and the workflows they provide require extensive knowledge within multiple different engineering domains and is non-trivial. In this article we present a model-driven approach that enables users to expand their digital fabrication scope by providing a high-level tool that facilitates the customization of fabrication tools. We present The Farbicatable Axis, a model that enables users to create customized linear actuators. The model takes high-level input parameters such as length and gearing-parameters, and outputs a CAD model of a linear motion axis consisting of fabricatable parts. We then present how instances of the Fabricatable Axis can be combined and used to design and implement Fabricatable Machines.

Context: The relevance of Requirements Engineering (RE) research to practitioners is vital for a long-term dissemination of research results to everyday practice. Some authors have speculated about a mismatch between research and practice in the RE discipline. However, there is not much evidence to support or refute this perception.Objective: This article presents the results of a study aimed at gathering evidence from practitioners about their perception of the relevance of RE research and at understanding the factors that influence that perception.Method: We conducted a questionnaire-based survey of industry practitioners with expertise in RE. The participants rated the perceived relevance of 435 scientific papers presented at five top RE-related conferences.Results: The 153 participants provided a total of 2,164 ratings. The practitioners rated RE research as essential or worthwhile in a majority of cases. However, the percentage of non-positive ratings is still higher than we would like. Among the factors that affect the perception of relevance are the research's links to industry, the research method used, and respondents’ roles. The reasons for positive perceptions were primarily related to the relevance of the problem and the soundness of the solution, while the causes for negative perceptions were more varied. The respondents also provided suggestions for future research, including topics researchers have studied for decades, like elicitation or requirement quality criteria.Conclusions: The study is valuable for both researchers and practitioners. Researchers can use the reasons respondents gave for positive and negative perceptions and the suggested research topics to help make their research more appealing to practitioners and thus more prone to industry adoption. Practitioners can benefit from the overall view of contemporary RE research by learning about research topics that they may not be familiar with, and compare their perception with those of their colleagues to self-assess their positioning towards more academic research.

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

In model-driven software engineering, models are used in all phases of the development process. These models may get broken due to various editions during the modeling process. There are a number of existing tools that reduce the burden of manually dealing with correctness issues in models, however, most of these tools do not prioritize customization to follow user requirements nor allow the extension of their components to adapt to different model types. In this paper, we present an extensible model repair framework which enables users to deal with different types of models and to add their own repair preferences to customize the results. The framework uses customizable learning algorithms to automatically find the best sequence of actions for repairing a broken model according to the user preferences. As an example, we customize the framework by including as a preference a model distance metric, which allows the user to choose a more or less conservative repair. Then, we evaluate how this preference extension affects the results of the repair by comparing different distance metric calculations. Our experiment proves that extending the framework makes it more precise and produces models with better quality characteristics.

Digital fabrication tools such as 3D printers, computer-numerically controlled (CNC) milling machines, and laser cutters are becoming increasingly available, ranging from consumer to industrial versions. Although these tools have enabled a completely new set of users to take part in manufacturing, they are still limited in their use and the workflows they provide. As an answer to this, users are modifying and customizing their machines by changing the work envelope and adding different end-effectors. However, customizing, modifying and creating digital fabrication machines require extensive knowledge within multiple different engineering domains, and is non-trivial. In this paper, we present The Fabricatable Axis, a high-level parametric model that aims to simplify the process of experimenting, customizing and implementing digital fabrication machines. This model encapsulates the knowledge of an experienced machine designer into a model that less experienced machine builders can use to design and customize linear and rotary motion axes which can be combined into different machines. The model receives high-level input parameters such as axis type, length and speed-parameters, and outputs a CAD model of a motion axis consisting of fabricatable parts (parts that are readily available or parts that can be fabricated using accessible tools such as a CNC milling machine). To validate our contribution, we first present a constructed scenario were we use the model to implement a specific machine. Secondly, we present an evaluation of our tool through a series of interviews with users who have been using the model to create different types of machines.

Digital fabrication is changing the way we design and manufacture the objects around us. Digital fabrication machines enable mass-customisation. However, customising the machines themselves requires a high amount of expertise, which prevents even advanced users from taking part in the creation of bespoke fabrication tools. We present Fabricatable Machines, an open-source toolkit for designing custom fabrication machines. We designed a linear motion module, The Fabricatable Axis, that provides robust automated linear motion. The Fabricatable Axis can be resized, adjusted, and fabricated from different materials. Users can build machines by combining multiple axes. We optimised the design of the axis to be manufactured using a CNC mill, with few externally sourced parts. We observed users creating machines including portable milling machines, 3D printers, and pipe inspection robots using the Fabricatable Machines Toolkit.

The automotive domain is rapidly changing in the last years. Among the different challenges OEMs (i.e. the vehicle manufacturers) are facing, vehicles are evolving into systems of systems. In fact, over the last years vehicles have evolved from disconnected and “blind” systems to systems that are (i) able to sense the surrounding environment and (ii) connected with other vehicles, the city, pedestrians, cyclists, etc. Future transportation systems can be seen as a System of Systems (SoS). In an SoS, constituent systems, i.e. the units that compose an SoS, can act as standalone systems, but their cooperation enables new emerging and promising scenarios. While this trend creates new opportunities, it also poses a risk to compromise key qualities such as safety, security, and privacy. In this paper we focus on the automotive domain and we investigate how to engineer and architect cars in order to build them as constituents of future transportation systems. Our contribution is an architectural viewpoint for System of Systems, which we demonstrate based on an automotive example. Moreover, we contribute a functional reference architecture for cars as constituents of an SoS. This reference architecture can be considered as an imprinting for the implementations that would be devised in specific projects and contexts. We also point out the necessity for a collaboration among different OEMs and with other relevant stakeholders, such as road authorities and smart cities, to properly engineer systems of systems composed of cars, trucks, roads, pedestrians, etc. This work is realized in the context of two Swedish projects coordinated by Volvo Cars and involving some universities and research centers in Sweden and many suppliers of the OEM, including Autoliv, Arccore, Combitech, Cybercom, Knowit, Prevas, ÅF-Technology, Semcom, and Qamcom.

The need to support software architecture evolution has been well recognized, even more since the rise of agile methods. However, assuring the conformance between architecture descriptions and the implementation remains challenging. Inconsistencies emanate among multiple architecture descriptions, and between architecture descriptions and code. As a consequence, architecture descriptions are not always trusted and used to the extent that their authors wish for. In this paper, we present two surveys with 93 and 72 participants to examine architectural inconsistencies, with a focus on how they evolve over time and can be mitigated using practical guidelines. We identified the importance of capturing emerging elements to keep the architecture description consistent with the implementation, and consider the current-state and future-state architecture separately. Consequences of inconsistencies typically arise at later stages, especially if an architecture description concerns multiple teams. Our guidelines suggest to limit the upfront architecture to stable decisions, while paying attention to concerns that matter across team borders. In the ideal case, companies should aim to integrate architects into the teams to capture emerging aspects with time.

Practitioners struggle with creating and evolving an architecture when developing complex and safety-critical systems in large-scale agile contexts. A key issue is the trade-off between upfront planning and flexibility to embrace change. In particular, the coordination of interfaces is an important challenge, as interfaces determine and regulate the exchange of information between components, subsystems, and systems, which are often developed by multiple teams. In a fast-changing environment, boundary objects between teams can provide the sufficient stability to align software or systems, while maintaining a sufficient degree of autonomy. However, a better understanding of interfaces as boundary objects is needed to give practical guidance. This paper presents an exploratory case study with an automotive OEM to identify characteristics of different interfaces, from non-critical interfaces that can be changed frequently and quickly, to those that are critical and require more stability and a rigorous change process. We identify what dimensions impact how interfaces are changed, what categories of interfaces exist along these dimensions, and how categories of interfaces change over time. We conclude with suggestions for practices to manage the different categories of interfaces in large-scale agile development.

Automotive manufacturers have historically adopted rigid requirements engineering processes. This allowed them to meet safety-critical requirements when producing a highly complex and differentiated product out of the integration of thousands of physical and software components. Nowadays, few software-related domains are as rapidly changing as the automotive industry. In particular, the needs of improving development speed are increasingly pushing companies in this domain toward new ways of developing software. In this paper, we investigate how the goal to increase development speed impacts how requirements are managed in the automotive domain. We start from a manager perspective, which we then complement with a more general perspective. We used a qualitative multiple-case study, organized in two steps. In the first step, we had 20 semi-structured interviews, at two automotive manufacturers. Our sampling strategy focuses on manager roles, complemented with technical specialists. In the second step, we validated our results with 12 more interviews, covering nine additional respondents and three recurring from the first step. In addition to validating our qualitative model, the second step of interviews broadens our perspective with technical experts and change managers. Our respondents indicate and rank six aspects of the current requirements engineering approach that impact development speed. These aspects include the negative impact of a requirements style dominated by safety concerns as well as decomposition of requirements over many levels of abstraction. Furthermore, the use of requirements as part of legal contracts with suppliers is seen as hindering fast collaboration. Six additional suggestions for potential improvements include domain-specific tooling, model-based requirements, test automation, and a combination of lightweight upfront requirements engineering preceding development with precise specifications post-development. Out of these 12 aspects, seven can likely be addressed as part of an ongoing agile transformation. We offer an empirical account of expectations and needs for new requirements engineering approaches in the automotive domain, necessary to coordinate hundreds of collaborating organizations developing software-intensive and potentially safety-critical systems.

Context: Historically, automotive manufacturers have adopted rigid requirements engineering processes, which allowed them to meet safety-critical requirements while integrating thousands of physical and software components into a highly complex and differentiated product. Nowadays, needs of improving development speed are pushing companies in this domain towards new ways of developing software. Objectives: We aim at obtaining a manager perspective on how the goal to increase development speed impacts how software intense automotive systems are developed and their requirements managed. Methods: We used a qualitative multiple-case study, based on 20 semi-structured interviews, at two automotive manufacturers. Our sampling strategy focuses on manager roles, complemented with technical specialists. Results: We found that both a requirements style dominated by safety concerns, and decomposition of requirements over many levels of abstraction impact development speed negatively. Furthermore, the use of requirements as part of legal contracts with suppliers hiders fast collaboration. Suggestions for potential improvements include domain-specific tooling, model-based requirements, test automation, and a combination of lightweight pre-development requirements engineering with precise specifications post-development. Conclusions: We offer an empirical account of expectations and needs for new requirements engineering approaches in the automotive domain, necessary to coordinate hundreds of collaborating organizations developing software-intensive and potentially safety-critical systems.

While several benefits of using models in software engineering have been observed in practice, the adoption of modeling remains low. Multiple challenges of using models, especially related to tools, have been reported both for industrial use and for education. However, there is a lack of systematic, empirical investigations of the challenges in modeling education and their relation to industrial challenges. Therefore, we conducted a multiple-case study with two cases, in the U.S and Sweden, focusing on students' perceptions towards tooling and UML in education. Our data collected from 369 student evaluation surveys, enriched with qualitative data, shows that the students' perception of modeling tools depends not only on the complexity of tools, but rather on multiple contextual factors, including tool characteristics, scope of course and project contents, nature of the required models, and the tools' role in generating executable artifacts. We conclude that there is a need for tailoring modeling tools for education beyond focusing on simplification and usability. Furthermore, due to the broad diversity within the modeling domain, there is a need for adapting the use of tools to the specific curriculum and course learning objectives.

The relevance of Requirements Engineering (RE) research to practitioners is a prerequisite for problem-driven research in the area and key for a long-term dissemination of research results to everyday practice. To understand better how industry practitioners perceive the practical relevance of RE research, we have initiated the RE-Pract project, an international collaboration conducting an empirical study. This project opts for a replication of previous work done in two different domains and relies on survey research. To this end, we have designed a survey to be sent to several hundred industry practitioners at various companies around the world and ask them to rate their perceived practical relevance of the research described in a sample of 418 RE papers published between 2010 and 2015 at the RE, ICSE, FSE, ESEC/FSE, ESEM and REFSQ conferences. In this paper, we summarize our research protocol and present the current status of our study and the planned future steps.

It has been stated that industrial-grade modelling tools are unsuitable for teaching modelling. We assume, however, that the experiences of the teachers and the students is strongly connected to the support available. In this paper, we present our experience with a university course on software modelling. In the first year of the course, we used a commercial modelling tool, in the second year the open-source alternative Papyrus. Our quantitative analysis shows that the industrial-grade modelling tools with all their complexity did not have a negative impact on the students' experience of modelling. We analyse why our experience differs from published accounts and conclude that the availability of a tool champion and tailored instruction material is key. From this, we derive lessons learned and give recommendations on how to successfully use industrial-strength modelling tools in the classroom.

The practice of Continuous Integration (CI) has a big impact on how software is developed today. Shortening integration and feedback cycles promises to increase software quality, feature throughput, and customer satisfaction. Thus, it is not a surprise that companies try to embrace CI in domains where it is rather difficult to implement.

Domain-specific modelling (DSM) is a modern software development technology that aims at enhancing productivity. One of the claimed advantages of DSM is increased maintainability of software. However, current empirical evidence supporting this claim is lacking. In this paper, we contribute evidence from a case study conducted at a software development company. We study how the introduction of DSM affected the maintenance of a legacy system. We collected data about the maintenance phase of a system that was initially developed using manual programming, but which was gradually replaced by DSM development. We performed statistical analyses of the relation between the use of DSM and the time needed to resolve defects, the defect density, and the phase in which defects were detected. The results show that after introducing DSM the defect density is lower, that defects are found earlier, but resolving defects takes longer. Other observed benefits are that the number of developers and the number of person-hours needed for maintaining the system decreased, and the portability to new platforms increased. Our findings are useful for organizations that consider introducing DSM and would like to know which benefits can be realized in software maintenance.

The automotive industry is currently going through an enormous change, transitioning from being pure hardware and mechanical companies to becoming more software focused. Currently, software development is embedded into a V-Model process that defines how software requirements are extracted from system requirements. In recent years, OEMs have come to recognize the importance and opportunities offered by software, which include better management and shorter time-to-market of distinguishing features. Strategies to better utilize software include in-house software development and new ways to collaborate with suppliers. However, in their effort to take advantage of these opportunities, engineers struggle with the formal process imposed on software development. In this paper, we investigate the impact of this struggle on the flow of requirements, including challenges and practices. We found that new ways of working with requirements had emerged that are partly not supported, partly hindered by the old tooling and processes for requirements engineering. Requirements flow both vertical and horizontal in the organization and across the supply-chain. Support for the new way of working should allow us to refine requirements iteratively throughout their life-cycle, handle the discussion of rationales, and to manage assumptions. We found strategies of achieving this to differ not only between OEMs, but also between different divisions inside the OEMs.

To investigate the new requirements and challenges of architecting often safety critical software in the automotive domain, we have performed two case studies on Volvo Car Group and Volvo Group Truck Technology. Our findings suggest that automotive software architects produce two different architectures (or views) of the same system. The first one is a high-level descriptive architecture, mainly documenting system design decisions and describing principles and guidelines that should govern the overall system. The second architecture is the working architecture, defining the actual blueprint for the implementation teams and being used in their daily work. The working architecture is characterized by high complexity and considerably lower readability than the high-level architecture. Unfortunately, the team responsible for the high-level architecture tends to get isolated from the rest of the development organization, with few communications except regarding the working architecture. This creates tensions within the organizations, sub-optimal design of the communication matrix and limited usage of the high-level architecture in the development teams. To adapt to the current pace of software development and rapidly growing software systems new ways of working are required, both on technical and on an organizational level.

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.

Context: Hutchinson et al. conducted an interview-based study of how model-driven engineering, MDE, is practiced in 17 companies. Their results include that successful MDE companies develop domain-specific languages; are motivated by a clear business case; and are committed at all levels of the organization. Goal: Whilst the results are useful, the study is a very broad one, with one or two interviewees per company. This paper supplements Hutchinson's study by focusing on three large companies that are applying MDE and undergoing a parallel transition to agile methods. Method: Formal data collection strategies -- 25 semi-structured interviews, observations and progress meetings -- were combined with informal interaction. The data was analysed both inductively for new insights and deductively for comparison with the results of Hutchinson et al. Results: Our findings show how MDE can include domain experts in software development and how agile development and MDE can coexist. In general our results validate the findings of Hutchinson et al. There are two areas where our results differ -- the engineers' sense of control and the appropriateness of their skills and training. Conclusions: Using a combination of data collection strategies and analysis techniques our study casts new light on earlier research as well as contributes with novel insights regarding the adoption of MDE.

Understanding software artifacts is not only time-consuming, without the proper training and experience it can be impossible. From a model-driven perspective there are two benefits from translating platform-independent models into natural language texts: First, the non-functional properties of the solution have already been omitted meaning that the translations focus on describing the functional behaviour of the system. Second, the platform-independent models are reusable across platforms and so are the translations generated from them. As a proof-of-concept a platform-independent Action language is translated into natural language texts through the framework of model transformations.

Model-based testing presents new challenges in how to perform software testing due to the fact that models offer testing on several abstraction levels. This is largely an unexplored area. We propose a pattern to construct test actors which can be used to test Platform-Independent Models. In addition, these test actors can also be automatically transformed to Platform-Specific Model level to test the implementation deployed on target. Our work is one step in the direction of permitting early testing without any waste, since the test models can be reused at a lower level of abstraction.

The E/E (Electrical/Electronic) Architecture is the key enabler for new innovative user functions in the automotive domain. The E/E Architecture needs to manage the complexity of the E/E System in a cost-efficient manner. This is a fact for all domains developing mass-produced distributed systems containing embedded software. However, many companies in these domains are missing a clear description of the development process for E/E Architectures. In addition, the relation between development of E/E Architectures and the development of E/E Systems is not clear. This paper proposes a development process for E/E Architectures in the automotive domain. Furthermore, it shows the relation between development of E/E Architectures and development of E/E Systems. The development process is based on post mortem analysis of E/E System development projects conducted at an automotive company during the period 1998-2009, and it was validated in an E/E Architecture development project conducted during the period 2010-2011. The contribution of this paper is a detailed E/E System development process describing how to create and maintain an E/E Architecture and how to refine this into a Product-specific Architecture in Product development projects. Furthermore, the paper reports on experiences from working with RA development both as a small stand-alone company with few different products, and as part of a large global company with several different products.

To estimate software code size early in the development process is important for developing cost-efficient embedded systems. We have applied the COSMIC Functional Size Measurement (FSM) method for size estimation of embedded software components in the automotive industry. Correlational studies were conducted using data from two automotive companies. The studies show strong correlation between functional size and software code size, which is important for obtaining accurate estimation results. This paper presents the characteristics and results of our work, and aims to provide a practical framework for how to use COSMIC FSM for size estimation purposes. We investigate the results from our earlier correlational studies, and conduct further studies to identify such a framework. Based on these activities, we conclude that a clear purpose of the estimation process, a well-defined domain allowing categorization of software, consistent content and quality of requirements, and historical data from implemented software are key factors for size estimation of embedded software components.

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.

Accurate estimation of Software Code Size is important for developing cost-efficient embedded systems. The Code Size affects the amount of system resources needed, like ROM and RAM memory, and processing capacity. In our previous work, we have estimated the Code Size based on CFP (COSMIC Function Points) within 15% accuracy, with the purpose of deciding how much ROM memory to fit into products with high cost pressure. Central in that work is the mapping between CFP and the information available early in the development process. We have previously defined a UML Profile capturing the information needed for CFP measurement and estimation of Code Size. The key idea was to extend UML components to contain all the necessary information. In this paper, we show how we developed a tool for automated estimation of Code Size based on our UML Profile. The tool is designed to permit Code Size estimation based on other UML diagrams than components. A case study evaluates the UML Profile and the tool in a realistic case.

Background: To estimate Software Code Size early in the development process is important both for Cost/Effort estimation and electronic hardware design reasons. The COSMIC FSM (Functional Size Measurement) method treats the intended software to be measured as a black box, and measures CFP (COSMIC Function Points) based only on data movement in and out of the software. Therefore, CFP can be measured on requirements defined early, and be used to estimate Code Size if there exists a strong correlation between CFP and Code Size. We have conducted four experiments in the automotive industry showing strong correlation between CFP and implemented Code Size in Bytes. All four experiments, of which two have not been published before, show equally strong correlation but the linear relationship is different between the experiments.

Various measures and methods have been developed to measure the sizes of different software entities produced throughout the software life cycle. Understanding the nature of the relationship between the sizes of these products has become significant due to various reasons. One major reason is the ability to predict the size of the later phase products by using the sizes of early life cycle products. For example, we need to predict the Source Lines of Code (SLOC) from Function Points (FP) since SLOC is being used as the main input for most of the estimation models when this measure is not available yet. SLOC/FP ratios have been used by the industry for such purposes even though the assumed linear relationship has not been validated yet. Similarly, FP has recently started to be used to predict the Bytes of code for estimating the amount of spare memory needed in systems. In this paper, we aim to investigate further the nature of the relationship between the software functional size and the code size by conducting a series of empirical studies.

For distributed networks which will be mass produced, such as computer systems in modern vehicles, it is crucial to find cost efficient hardware. A distributed network in a vehicle consists of several ECUs (electronic control unit). In this paper we consider the amount of memory needed for these ECUs. They should contain enough memory to survive several software generations, without inducing unnecessary cost of too much memory. Our earlier work shows that UML component diagrams can be used to collect enough information for estimating memory size using a functional size measurement method. This paper replicates our earlier experiment with more software components of a different type. We compare the results from the two experiments.

In this paper we will show how to obtain a better comprehension of the behavior of large and complex software systems using visualization and program animation. Use cases are used in the software development industry for the purpose of better understanding of software systems. The problem is that use cases for large and complex software systems are themselves large and complex. We have built a tool called Scenario Explorer to help the user handle this complexity by guiding him or her through the use cases. The user is provided with just enough information to comprehend the behavior of interest. Tools like this are crucial for developers that need to obtain a better comprehension of a whole software system, for example newcomers in a project or managers. ScenarioExplorer was built at Ericsson and applied to a subset of a large and complex software system.

Hitherto all partial evaluators have processed a complete program to produce a complete residual program. We are interested in treating programs as collections of modules which can be processed independently: 'separate partial evaluation', so to speak. In this paper we still assume that the original program is processed in its entirety, but we show how to specialise it to the static data bit-by-bit, generating a different module for each bit. When the program to be specialised is an interpreter, this corresponds to specialising it to one module of its object language at a time: each module of the object language gives rise to one module of the residual program.

We present an approach for specialising large programs, such as programs consisting of several modules, or libraries. This approach is based on the idea of using a compiler generator (cogen) for creating generating extensions. Generating extensions are specialisers specialised with respect to some input program. When run on some input data the generating extension produces a specialised version of the input program. Here we use the cogen to tailor modules for specialisation. This happens once and for all, independently of all other modules. The resulting module can then be used as a building block for generating extensions for complete programs, in much the same way as the original modules can be put together into complete programs. The result of running the final generating extension is a collection of residual modules, with a module structure derived from the original program.