Abstract The domain of cyber‐physical systems (CPS) has recently seen strong growth, for example, due to the rise of the Internet of Things (IoT) in industrial domains, commonly referred to as “Industry 4.0.” However, CPS challenges like the strong hardware focus can impact modern software development practices, especially in the context of modernizing legacy systems. While microservices and DevOps have been widely studied for enterprise applications, there is insufficient coverage for the CPS domain. Our goal is therefore to analyze the peculiarities of such systems regarding challenges and practices for using and migrating towards microservices and DevOps. We conducted a rapid review based on 146 scientific papers, and subsequently validated our findings in an interview‐based case study with nine CPS professionals in different business units at Siemens AG. The combined results picture the specifics of microservices and DevOps in the CPS domain. While several differences were revealed that may require adapted methods, many challenges and practices are shared with typical enterprise applications. Our study supports CPS researchers and practitioners with a summary of challenges, practices to address them, and research opportunities.

Technical debt (TD) in a software system is a metaphor that tries to illustrate the remediation effort of the already introduced quality deficit and the impact thereof to the business value of the system. To address TD, various management activities are proposed, each addressing a particular purpose. Whereas the activities of debt identification and measurement are broadly considered in literature, the activities of debt prioritization and communication lack appropriate approaches with an economic perspective. This work proposes a TD prioritization approach. Therefore, it narrows down the focus of TD to design debt and relies on the quantification of design best practices. Further, the non-conformance of these practices is assessed by applying a benchmarking technique. As a result, the gained information is transferred into a portfolio-matrix to support the prioritization and communication of design remediation actions. The applicability and suitability of the approach are demonstrated by using the source code of the open source project GeoGebra.

The design debt metaphor tries to illustrate quality deficits in the design of a software and the impact thereof to the business value of the system. To pay off the debt, the literature offers various approaches for identifying and prioritizing these design flaws, but without proper support in aligning strategic improvement actions to the identified issues. This work addresses this challenge and examines the suitability of our proposed portfolio-based design assessment approach. Therefore, this investigation is conducted based on three case studies where the product source code was analyzed and assessed using our portfolio-based approach. As a result, the approach has proven to be able to recommend concrete and valuable design improvement actions that can be adapted to project constraints.

To measure object-oriented design quality, metric-based approaches have been established. These have then been enhanced by identifying design smells in code. While these approaches are useful for identifying hot spots that should be refactored, they are still too vague to sufficiently guide software developers to implement improvements. This is why our previous work focuses on measuring the compliance of source code with object-oriented design best practices. These design best practices were systematically derived from the literature and can be mapped to design principles, which can help reveal fundamental object-oriented design issues in a software product. Despite the successful applications of this approach in industrial and open source projects, there is little accepted knowledge about the importance of various design best practices. Consequently, this paper shows the result of an online survey aimed at identifying the importance of 49 design best practices on design quality. In total, 214 people participated in the survey, resulting in an average of 138 opinions for each practice. Based on these opinions, five very important, 21 important, 12 moderately important and 11 unimportant design best practices could be derived. This information about importance helps managing design improvements in a focused way.

Current software development trends have shortened release cycles and forced developers to implement short-term solutions that cannot cope with increasing product complexity. This phenomenon of introducing hasty design choices or applying bad design practices becomes something known as technical debt, in particular design debt. To pay off this debt, the literature offers approaches for identifying these design flaws; however, few methods for properly prioritizing investment efforts are available. In this paper, we propose an approach that supports the decision-making process regarding design improvements. It identifies violations of design best practices that are then arranged within a two-dimensional portfolio matrix. This matrix combines the importance of practices of design quality with actual achievement relative to a benchmark suite. To show the application of the approach in a quality-improvement process, we performed a feasibility study on three open-source projects and a benchmark suite containing 50 projects. This study clearly shows that the importance of the design best practices greatly impacts the improvement decisions and must be aligned with the strategic quality goals of the product.

Existing software quality models typically focus on common quality characteristics such as the ISO 25010 software quality characteristics. However, most of them provide insufficient operationalization for quality assessments of source code. Moreover, they usually focus on software in general or on information systems and do not sufficiently cover the particularities of embedded systems. We have developed a quality model that covers quality requirements for source code that are specific for embedded systems software. It provides comprehensive operationalization (with 336 measures) for C and C++ systems, which allows for largely automated quality assessments. The empirical evaluations performed acknowledge moderate completeness of the requirements and the associated measures. Therefore, we still see room for improvements to allow covering even more aspects of embedded systems software quality. Nevertheless, the empirical validation (based on three industrial products) shows good concordance between the results gained by the automatic model-based assessment and independent expert judgment on code quality.

There is empirical evidence that the code quality of software has an important impact on the external, i.e., user perceptible, software quality. Currently a large number of source code metrics exist that seem to ease the evaluation of code quality. Nevertheless, studies show that the theoretical foundations are weak and promising approaches for the automatic assessment of code quality are to be considered with great caution. We therefore came to the conclusion that the metric values and other findings provided by various static code analysis tools can only be used in the context of an expert-centred assessment of internal software quality. In order to be able to carry out code quality assessments in a timely and efficient manner it is inevitable to have additional tool support. For that purpose we developed the eclipsed based tool software product quality reporter (SPQR) that supports expert-centred evaluation of source code - from the formulation of project-specific quality models up to the generation of preliminary code quality reports. The application of SPQR already proved its usefulness in various code assessment projects around the world.