User inertia is a real innovation adoption problem that cannot be seen or grasped. How to overcome user inertia while introducing innovation has become a key factor in today's society. Based on the background of requirements engineering, the goal of this thesis is to study and understand the relationship between user inertia and innovation adoption, including whether the type of innovation has an impact on user adoption and how to use strategies to reduce this impact. Through an online survey of 60 users and a systematic literature review of a series of articles, we have concluded the following points: RI has a greater impact on user inertia, while II has almost no impact; neither RI nor II has a significant impact on user satisfaction. Not only that, but through literature review, we have also concluded a comprehensive strategy to deal with the adoption problem caused by user inertia.

The Swedish software industry is seeing explosive growth and Swedish colleges and universities play a crucial part in supplying industry professionals with relevant education. Studies show an existing gap between what software engineering (SE) education teaches students and what the software industry needs. This study looked specifically at what technologies Swedish SE education used in its syllabuses compared to what technologies were in demand by the Swedish software industry to determine if any knowledge gaps existed. Course syllabuses and job posts were collected and compared through text analysis, highlighting keywords associated with different technologies. The result showed that the Swedish SE education overall aligned with industry demands with some minor exceptions. Conclusions were that some improvements could be made to meet the demand of technologies such as C\#, TypeScript, Kubernetes, and Docker.

Software build tools like Maven and Gradle help us automate projects’ build phase but still require developers to be involved. To allow software engineers to work with multiple projects with high productivity, they need to be able to build them efficiently. In this paper, we studied automatic build tools: Maven, Gradle, and Ant, by executing the default build command on the top 300 Java Projects from Github. After gathering the projects which failed to build by using the default commands, we tried to configure the build process to get a successful result manually. The root causes of build failures were presented in 8 categories and compared to a previous paper that did similar research on the top 200 Java projects from Github. Results showed that 157 (52%) projects failed to build using default build commands, compared to the previous paper, which got 49%. The major root causes of build failures we found in this study were test failures (49%), compilation error (6%), dependency error(10%), dedicated command (7%), and file setup (24%). About 89% of the build failures could be resolved.

WebAssembly is an instruction set designed for a stack based virtual machine, with an emphasis on speed, portability and security. As the use cases for WebAssembly grow, so does the desire to target WebAssembly in compilation. In this thesis we present Rasm, a Racket to WebAssembly compiler that compiles a select subset of the top forms of the Racket programming language to WebAssembly. We also present our early findings in our work towards adding a WebAssembly backend to the Chez Scheme compiler that is the backend of Racket. We address initial concerns and roadblocks in adopting a WebAssembly backend and propose potential solutions and patterns to address these concerns. Our work is the first serious effort to compile Racket to WebAssembly, and we believe it will serve as a good aid in future efforts of compiling high-level languages to WebAssembly.

The widespread of machine learning and deep learning in commercial and industrial settings has seen a dramatic up-rise. While the traditional software engineering techniques have overlap between machine learning model development, fundamental differences exist which affect both scientific disciplines. The current state-of-the-art argues that most challenges in software engineering of deep learning applications stem from poorly defined software requirements, tightly coupled architecturesand hardware-induced development issues. However the majority of the current work on this topic stems from literature reviews and requires validation in an industrial context. The work aims to validate the findings of the academia through the development of the autoencoder model for gearbox fault detection. The model has been developed as a part of the ongoing campaign from Volvo Construction Equipment towards introducing AI-based solution in quality control and production. Findings of the work are mostly aligned with the current state-of-the-art, where poorly defined software requirements and hardware-induced issues have been experienced, but the tightly-coupled architecture did not characterize the final product. Along with the confirmation of the previous findings, the work presents a recommendation for practitioners of software engineering for deep learning models in the form of technological rule which addresses the hardware-induced issues of development through the contribution of a method for calculating the memory requirements of the model and batch during the training phase. / <p>Collaboration with Volvo Construction Equipment</p>

Background: Software Engineering is a high-demand field constantly changing with new languages, tools, and frameworks. The use of software modeling in Software Engineering is essential for solving complex problems since it helps the developer understand abstraction and develop high-level code. For an overview of the current state of software modeling, this research attempts to present an overview of software modeling curricula and how students benefit from attending these courses. Method: First, to assess the survey’s clarity and eliminate any potential for bias, we conducted a pilot study with five teachers at M¨alardalen University. We surveyed 23 participants from 23 institutions and ten countries to get their responses to Research Questions 2, 3, and 4. We have collected data for programs from 10 different countries with their top 5 universities to address Research Question 1. Results: To maintain meaning in the Software Engineering domain, we used our findings to seek the usage of knowledge gained from the academic environment in the industry when the students shift from academia to industry. Through this thesis, we present the current view of software modeling curricula and their contribution to preparing students for the industry. The following significant findings were reached: (i) software modeling aids in better understanding of abstraction concepts and the development of high-level applications; (ii) UML is one of the most popular languages; and (iii) some limitations of software modeling tools include license type, outdated tools, or poorly documented tools.

Context: Companies adopt many software reuse practices, such as software product line, reuse verbatim, and systematic reuse, to improve their internal software development and maximize the benefits. Contemporary software engineering (SE) practices, such as microservices and InnerSource, influence internal software reuse. Objective: In this thesis, we aim to improve internal software reuse in the context of contemporary SE practices. To do that, we want to 1) understand the state-of-the-art and the state-of-the-practice of software reuse costs and benefits and the challenges that companies are currently facing and 2) identify interventions to improve internal software reuse.  Methods: We conducted a systematic literature review to understand the state-of-the-art of software reuse costs and benefits. We performed two exploratory case studies to understand the state-of-the-practice of software reuse costs and benefits, challenges, and improvement areas in the context of contemporary SE practices.  We performed another follow-up improving case study to investigate the medium-sized case company's readiness of adopting InnerSource for software reuse. Results: Existing literature reported more software reuse benefits than costs. The most reported software reuse benefits are better product quality and improved productivity. Verbatim reuse and systematic reuse result in more reuse benefits. Most of the included primary studies are of moderate quality, with only four having high quality. Practitioners think that software reuse costs in developing reusable assets will be paid off when developers start to reuse them. Challenges in software reuse in the context of contemporary SE practices differ between medium-sized and large-sized companies. Both of the companies perceive that InnerSource can help improve internal software reuse. Asking practitioners about both current and desired InnerSource reuse status helps identify the needed InnerSource improvements, thus helping companies succeed in adopting InnerSource for reuse.   Conclusion: Both existing literature and our two case studies investigating software reuse in the context of contemporary SE practices showed that software reuse improves quality and productivity and has costs in developing and integrating reusable assets. However, the overall benefits outweigh the costs. Both case companies faced challenges in improving their internal reuse, where the most common challenges were about developing and maintaining reusable assets. The results showed that InnerSource helps develop and maintain reusable assets and further improves internal software reuse. / <p>Chapters 2 and 4 are papers submitted to journals and therefore removed from the fulltext file.</p>

Context: In an era where every industry is impacted by software, it is vital to keep software costs under control for organizations to be competitive. A key factor contributing to software costs is software maintenance where a significant proportion is utilized to deal with different types of technical debt. Technical debt is a metaphor used to describe the cost of taking shortcuts or sub-optimal design and implementation that compromises the software quality. Similar to financial debt, technical debt needs to be paid off in the future. Objective: To be in control of technical debt related costs, organizations need to identify technical debt types and quantify them to introduce solutions and prioritize repayment strategies. However, the invisible nature of technical debt makes its identification challenging in practice. Our aim is to find pragmatic ways to identify technical debt in practice, that can be supported by evidence. Once technical debt types that are significant have been identified, we aim to propose suggestions to mitigate them. Method: We used design science as a methodological framework to iteratively improve the technical debt identification methods. We utilized bug reports, which are artifacts produced by software engineers during the development and operation of the software system  as the data source for technical debt identification. Software defects reported through bug reports are considered as one of the key external quality attributes of a software system  which supports us in our evidence based approach. Throughout the design science iterations, we used the following research methods: case study and sample study. Results: We produced three design artifacts that support technical debt identification. The first artifact is a systematic process to identify architectural technical debt from bug reports. The second is an automated bug analysis and a visualization tool to support our research as well as to support practitioners to identify components with hot spots in relation to the number of defects. The third is a method for identifying documentation debt from bug reports. Conclusion: Based on the findings from this thesis, we demonstrated that bug reports can be utilized as a data source to identify technical debt in practice by identifying two types of technical debt; architectural technical debt and documentation debt. Compared to the identification of documentation debt, architectural technical debt identification still remains challenging due to the abstract nature of the architecture and its boundaries. Therefore, our future work will focus on evaluating the impact of reducing the sources of documentation debt on the frequency of bug reports and overall project cost.

Software quality attributes are properties that reflect the quality of a software system, and Non-functional requirements (NFRs) are the specifications that define how a software system should perform to reach a desired level of goals of the quality attributes.The evaluation of quality attributes is important to show the effectiveness of a system in meeting customers' NFRs. Continuous integration (CI) environments have emerged as powerful platforms for organizations to improve software quality through automated software verification and validation.Despite this, there is a growing need for evaluating quality attributes that is often met by in-house development of metrics and tools.This highlights the importance of quality attributes for software product quality. This thesis investigates the association between quality attributes and components of a CI environment, as well as how to utilize these components for evaluating software quality attributes.The focus is on improving the knowledge of the evaluation and providing specific recommendations for companies to enhance their CI environments for higher demands of quality evaluation.The contributions of this thesis include a better understanding of the relationship between quality attributes and CI components, and a set of practical guidelines for companies to effectively leverage CI for quality attribute evaluation. The studies in this thesis utilized mixed methodologies, including a systematic literature review, a multi-case study conducted in four software development companies, and an synthesis of the collected data.The multi-case study provided a comprehensive overview of practices for quality attribute evaluation and how CI components can generate data to support the evaluation of specific attributes.The synthesis study presents a maturity model based on the collected data from both academia and industry, and the model can aid organizations in assessing their current level of maturity in utilizing CI environments to identify potential improvements.The results in these studies show the capabilities of different components of a CI environment and how these components can be used to support the evaluation of quality attributes.While the use of CI environments for the thesis topic offers benefits, it also presents several challenges, for example, the challenge to identify effective quality metrics. In conclusion, this thesis contributes to the understanding of the use of CI environments for evaluating software quality attributes.The results suggest that CI environments can be an effective approach for quality attribute evaluation, but suitable metrics need to be considered to ensure accurate and meaningful evaluation results. Furthermore, the thesis presents areas for future research, such as the use of machine learning techniques to improve the accuracy of quality assessment using CI environments.

<p>With the general engineering practices being followed for the development of scientific software, scientists are seemingly able to simulate real world problems successfully and generate accurate numerical results. However, scientific software is rarely presented in such a way that an external reviewer would feel comfortable in certifying that the software is fit for its intended use. The documentation of the software development - Requirements, Design and Implementation, is not being given the importance it deserves. Often, the requirements are improperly and insufficiently recorded, which make the design decisions difficult. Similarly, incomplete documentation of design decisions and numerical algorithms make the implementation difficult. Lack of traceability between the requirements, design and the code leads to problems with building confidence in the results.</p> <p>To study the problems faced during certification, a case study was performed on a legacy software used by a nuclear power generating company in the 1980's for safety analysis in a nuclear reactor. Unlike many other scientific codes of that time, the nuclear power generating company included a full theory manual with their code. Although the theory manual was very helpful, the documentation and development approach still needed significant updating. During the case study, 27 issues were found with the documentation of the theory manual, 2 opportunities to update the design and 6 programming style issues were found in the original FORTRAN code. This shows room for improvement in the documentation techniques in the development of scientific software based on a physical model.</p> <p>This thesis provides a solution to the certification problem, by introducing software engineering methodologies in the documentation of the scientific software. This work proposes a new template for the Software Requirements Specification (SRS) to clearly and sufficiently state the functional and the non-functional requirements, while satisfying the desired qualities for a good SRS. Furthermore, the proposed template acts as a checklist and helps in systematically and adequately developing the requirements document. For developing the design and implementation, this thesis introduces Literate Programming (LP) as an alternative to traditional structured programming. Literate Programming documents the numerical algorithms, logic behind the development and the code together in the same document, the Literate Programmer's Manual (LPM). The LPM is developed in connection with the SRS. The explicit traceability between the theory, numerical algorithms and implementation (code), simplifies the process of verification and the associated certification.</p> / Master of Applied Science (MASc)