Search

This technical report presents RefA, a reference architecture for security-compliant DevOps. RefA consists of a set of models that illustrate the artefacts and practice areas to consider when implementing secure DevOps lifecycles. In addition, RefA describes people, proceses, and technology aspects to be considered in each practice area. Practitioners can use RefA for the purposes of designing and assessing security compliance of their DevOps lifecycles, while researchers may use RefA as a reference for setting up research roadmaps. RefA models result from combining the profound analysis of the IEC 62443-4-1 standard for secure industrial products development, continuous software engineering literature review, and observations made in practice in context of a large industrial company during the past 5 years. The manuscript constitutes original, previously unpublished research.

Context Software start-ups have shown their ability to develop and launch innovative software products and services. Small, motivated teams and uncertain project scope makes start-ups good candidates for adopting Agile practices. Objective We explore how start-ups use Agile practices and what effects can be associated with the use of those practices. Method We use a case survey to analyze 84 start-up cases and 56 Agile practices. We apply statistical methods to test for statistically significant associations between the use of Agile practices, team, and product factors. Results Our results suggest that development of the backlog, use of version control, code refactoring, and development of user stories are the most frequently reported practices. We identify 22 associations between the use of Agile practices, team, and product factors. The use of Agile practices is associated with effects on source code and overall product quality. A teams’ positive or negative attitude towards best engineering practices is a significant indicator for either adoption or rejection of certain Agile practices. To explore the relationships in our findings, we set forth a number of propositions that can be investigated in future research. Conclusions We conclude that start-ups use Agile practices, however without following any specific methodology. We identify the opportunity for more fine-grained studies into the adoption and effects of individual Agile practices. Start-up practitioners could benefit from Agile practices in terms of better overall quality, tighter control over team performance, and resource utilization. © 2021 Wroclaw University of Science and Technology. All rights reserved. open access

Developing a software-intensive product or service can be a significant undertaking, associated with unique challenges in each project stage, from inception to development, delivery, maintenance, and evolution. Each step results in artefacts that are crucial for the project outcome, such as source-code and supporting deliverables, e.g., documentation. Artefacts which have inherent value for the organisation are assets, and as assets, they are subject to degradation. This degradation occurs over time, as artefacts age, and can be more immediate or slowly over a period of time, similar to the concept of technical debt. One challenge with the concept of assets is that it seems not to be well-understood and generally delimited to a few types of assets (often code-based), overlooking other equally important assets. To bridge this gap, we have performed a study to formulate a structured taxonomy of assets. We use empirical data collected through industrial workshops and a literature review to ground the taxonomy. The taxonomy serves as foundations for concepts like asset degradation and asset management. The taxonomy can help contextualise, homogenise, extend the concept of technical debt, and serves as a conceptual framework for better identification, discussion, and utilisation of assets.

When developing and maintaining software-intensive products or services, we often depend on various "assets", denoting the inherent value to selected artefacts when carrying out development and maintenance activities. When exploring various areas in Software Engineering, such as Technical Debt and our work with industry partners, we soon realised that many terms and concepts are frequently intermixed and used inconsistently. Despite the central role of assets to software engineering, management, and evolution, little thoughts are yet invested into what assets eventually are. A clear terminology of "assets" and related concepts, such as "value" or "value degradation", just to name two, are crucial for setting up effective software engineering practices. As a starting point for our own work, we had to define the terminology and concepts, and extend the reasoning around the concepts. In this position paper, we critically reflect upon the resulting notion of Assets in Software Engineering. We explore various types of assets, their main characteristics, such as providing inherent value. We discuss various types of value degradation and the possible implications of this on the planning, realisation, and evolution of software-intensive products and services over time. Published with title: Assets in Software Engineering: What are they after all? in Journal of System and Software

Context: Safety-critical systems (SCS) are mainly controlled by software. Accordingly, the development of these systems must be carefully planned since inadequate or misunderstood requirements have been recognized as the major cause of a significant proportion of accidents and safety-related catastrophes. Objective: We investigate the integration and requirements communication in the requirements engineering (RE) process among different parties when developing SCS. Method: We used a Systematic Mapping Study as the basis for our work. Results: We analyze the challenges and needs involved, application context, research type, evaluation methods, type of contribution, domain, requirements activity as well as languages and tools used to specify safety requirements. Furthermore, we also analyze stakeholders involved, communication format, and for what safety standards have the approaches been proposed. Conclusions: We believe the results of such a study will benefit both researchers and practitioners. This information contributes to setting up possible collaborative networks and as a reference when developing new research projects. © 2019 Anais do WER 2019 - Workshop em Engenharia de Requisitos. All rights reserved. Open access

Component-based software engineering (CBSE) is a common approach to develop and evolve contemporary software systems. When evolving a system based on components, make-or-buy decisions are frequent, i.e., whether to develop components internally or to acquire them fromexternal sources. In CBSE, several different sourcing options are available: 1) developing software in-house, 2) outsourcing development, 3) buying commercial-off-the-shelf software, and 4) integrating open source software components. Unfortunately, there is little available research on howorganizations select component sourcing options (CSO) in industry practice. In this work, we seek to contribute empirical evidence to CSO selection. Method: We conduct a cross-domain survey on CSO selection in industry, implemented as an online questionnaire. Based on 188 responses, we find that most organizations consider multiple CSOs during software evolution, and that the CSO decisions in industry are dominated by expert judgment. When choosing between candidate components, functional suitability acts as an initial filter, then reliability is the most important quality. We stress that future solution-oriented work on decision support has to account for the dominance of expert judgment in industry. Moreover, we identify considerable variation in CSO decision processes in industry. Finally, we encourage software development organizations to reflect on their decision processes when choosing whether to make or buy components, and we recommend using our survey for a first benchmarking., Orion

Value Stream Mapping is one of the several Lean practices, which has recently attracted interest in the software engineering community. In other contexts (such as military, health, production), Value Stream Mapping has achieved considerable improvements in processes and products. The goal is to also leverage on these benefits in the software intensive product development context. The primary contribution is that we are extending the definition of waste to fit in the software intensive product development context. As traditionally in Value Stream Mapping everything that is not considered valuable is waste, we do this practically by looking at value beyond the customer perspective, and using the Software Value Map. A detailed illustration, via application in an industrial case at Ericsson AB, demonstrates usability and usefulness of the proposed extension. The case study results consist of two parts. First, the instantiation and motivations for selecting certain strategies have been provided. Second, the outcome of the value stream map is described in detail. Overall, the conclusion is that this case study indicates that Value Stream Mapping and the integration with the Software Value Map is useful in a software intensive product development context. In a retrospective the value stream approach was perceived positively by the practitioners with respect to process and outcome.

Software Process Improvement (SPI) encompasses the analysis and modification of the processes within software development, aimed at improving key areas that contribute to the organizations’ goals. The task of evaluating whether the selected improvement path meets these goals is challenging. On the basis of the results of a systematic literature review on SPI measurement and evaluation practices, we developed a framework (SPI Measurement and Evaluation Framework (SPI-MEF)) that supports the planning and implementation of SPI evaluations. SPI-MEF guides the practitioner in scoping the evaluation, determining measures, and performing the assessment. SPI-MEF does not assume a specific approach to process improvement and can be integrated in existing measurement programs, refocusing the assessment on evaluating the improvement initiative’s outcome. Sixteen industry and academic experts evaluated the framework’s usability and capability to support practitioners, providing additional insights that were integrated in the application guidelines of the framework.

Software inspections have proved to be an effective means to find faults in different software artifacts, and the application of software inspections on requirements specifications is believed to give a high return on investment as problems are caught early. However, despite the existing evidence of positive effects requirements inspections are not a common practice in industry. The reason is believed to be the cost associated with inspections as a technology. This paper presents an evaluation of test-case driven inspections (TCD) - an emerging inspection technique that aims to cut costs associated with traditional requirements inspections. To formally test the efficiency and effectiveness of TCD inspections an experiment was conducted, in a controlled environment, where checklist based inspections was used as a point of reference. The experiment results indicate that TCD inspections perform better when it comes to effectiveness in finding major faults in a requirements specification.

Market-Driven Requirements Engineering (MDRE) handles the continuous flow of requirements in an engineering effort, and is not limited to a development instance but part of technical product management as a whole. The market-driven environment generates large amounts of requirements from multiple sources, internal and external, threatening to overload the technical management of products. MDRE involves requirements analysis, resource estimation, prioritization, and ultimately release planning. These activities allow for effectively deciding which customers get what features and quality at what point in time, making the accuracy and efficiency of MDRE a major determinant of the success of a product. This thesis presents research aimed at supporting technical product management in MDRE, based on needs identified in industry. One contribution of the thesis is the development and validation of a process assessment and improvement planning framework, making the identification of process improvement issues possible. The major characteristics of the framework can be described as resource efficiency and relative accuracy by utilizing multiple perspectives and data point triangulation. As a complement to the assessment, the improvement planning enables industry professionals to focus their efforts on one improvement package at a time, supporting step-by-step evolution with less time to return on investment. Challenges identified during process assessment using the framework resulted in the development of the Requirements Abstraction Model (RAM), which is the central contribution of the thesis. RAM employs multiple levels of abstraction for requirements elicitation, analysis, refinement and management. The model offers the possibility for early requirements triage using product strategies/roadmaps, as well as supporting a structured and repeatable way to perform continuous requirements engineering. This enables product managers to specify requirements that can be traced across abstraction levels, from abstract requirements that can be used by managers, to refined requirements specific enough to be used for estimation and input to development efforts. RAM was engineered based on industry needs, validated and refined through several empirical evaluations, utilizing both academia and industry as laboratory. This involved close collaboration with industrial partners, Danaher Motion Särö AB and ABB Robotics, where the model was introduced. Monitoring the process improvement (introduction of RAM) indicated substantial improvements, both in accuracy of the work performed using RAM, and in the quality of the requirements produced, with only moderate increase in effort. Another contribution in the thesis is a compilation of lessons learned from practical handson experience of technology and knowledge transfer from academia to industry, with focus of producing industry relevant usable and useful results. The main contribution of the thesis is improving the practice of product management by providing and evaluating frameworks for software process improvement and market-driven requirements engineering. The results of the research presented in the thesis are aimed at supporting technical product management taking the unique challenges of market-driven development into account.

Requirements Engineering (RE) is a crucial part of any product management and product development activity, and as such deficiencies in the RE process may have severe consequences. There are reports from industry that point towards inadequate requirements being one of the leading sources for project failure. Software Process Improvement (SPI) is generally seen as the main tool to address process deficiencies in general and within RE. Assessments lead to establishing plans for improvements that are subsequently implemented and evaluated, and then the SPI cycle starts again, in an optimal case being incremental and continuous. Most well known SPI frameworks, e.g. CMM, CMMI, SPICE and QIP, are based on these general principles. There are however several factors that can have a negative impact on SPI efforts in general, and in the case of SPI targeted at RE in particular. Time and cost are two fundamental factors that can effectively “raise the bar” for SPI efforts being initiated at all. This is the particular case for Small and Medium sized Enterprises (SMEs) with limited resources, and a limited ability to wait for the return on their investment. Other issues include commitment and involvement in the SPI work by the ones affected by the changes, coverage of the RE area in SPI frameworks, and the ability to focus improvements to areas where they are needed the most. The research presented in this thesis is based on actual needs identified in industry, and all of the proposed solutions have also been validated in industry to address issues of applicability and usability. In general, the goal of the research is to “lower the bar”, i.e. enabling SMEs to initiate and perform SPI activities. It is accomplished through the presentation and validation of two assessment methods that targets RE, one aimed at both fast and low-cost benchmarking of current practices, and the other designed to produce tangible improvement proposals that can be used as input to an improvement activity, i.e. producing a relatively accurate assessment but taking limited time and resources into account. Further, to offer a structured way in which SMEs can focus their SPI efforts, a framework is introduced that can be used to package improvement proposals with regards to their relative priority taking dependencies into account. This enables SMEs to choose what to do first based on their needs, as well as a way to control time to return on their investment by controlling the size of the undertaking. As a result of industry validation of the assessment method and packaging framework, several improvement proposals were identified and prioritized/packaged. As a part of a process improvement effort (based on an improvement proposal package) an RE model was developed that was appropriate for SMEs faced with a market-driven product centered development situation. The model, called Requirements Abstraction Model (RAM), addresses the structuring and specification of requirements. The main feature of the model is that it not only offers a structured way in which requirements can be specified, but it also takes a requirement’s abstraction level into account, using abstraction for the work-up instead of putting all requirements in one repository independent of abstraction level. The RAM was developed to support primarily the product management effort, recognizing that RE from this perspective is not project initiated but rather project initiating. The model assists product managers to take requirements on varying abstraction levels and refining them to the point of being good-enough to offer decision support for management, and at the same time being good-enough for project initiation. The main contribution of the thesis is to present SMEs with “tools” that help them commit to and perform SPI activities. Moreover, the thesis introduces the RAM model that was developed based on needs identified in industry, and subsequently piloted in industry to assure usability.

The lack of an adequate requirements specification is often blamed for the failure of many IT investments. Naturally, the requirements specification is the product of a requirements engineering process. Methods are required to evaluate the current requirements engineering process and identify where improvements are necessary making it possible to produce requirement specifications of high quality. Existing requirements engineering evaluation methods are often large, costly and time-consuming to use. Therefore we introduce a lightweight evaluation method, which we use to evaluate four industry projects. In this paper we outline the evaluation method, describe four industrial applications of the method and present an analysis of the findings. The results suggest that the proposed evaluation method is useful and the studied cases to a large extent have adequate requirements engineering processes although many important aspects are missing from their respective processes.

One of the challenges in requirements engineering is the ability to improve the process and establish one that is “good-enough”. The objective of this paper is to present a lightweight approach to identify process improvement issues. The approach is developed to capture both the views of different stakeholders and different sources of information. An industrial investigation from a small company is presented. In the investigation both projects and the line organization have been interviewed and documentation from them has been studied to capture key issues for improvement. The issues identified from one source are checked against other sources. The dependencies between the issues have been studied. In total nine issues for improvement of the requirements engineering work at the company were identified. It is concluded that the approach is effective in capturing issues, and that the approach helps different stakeholders to get their view represented in the process improvement work.

The area of Requirements Engineering is often underestimated in value in the area of Software Engineering. According to certain sources the failure rate of IT investments is over 60%. In addition problems introduced through the Requirements Engineering of a project accounts for something like 50% of the total debugging costs. The main reason for this is a low level of maturity pertaining to the Requirements Engineering process. This thesis introduces a model that can help organizations improve their Requirements Engineering process. A first step in process improvement is process evaluation. The REPM model has the purpose of measuring the maturity level of the Requirements Engineering process in projects, and to give a basis for what steps to take in order to improve on it. In addition to the model a method for using the model is introduced. The model and method are subsequently designed, implemented and validated. The validation takes the form of interviews and case-studies in industry featuring four companies and four projects of varying size. The project evaluations were conducted on-site in both Sweden and in Ireland. It is shown that the REPM model in combination with the method is a good way to evaluate the Requirement Engineering process of a project. It gives a picture of the current state of the Requirements Engineering process in a project and, more importantly, how the results of the evaluation can be used for process improvement. Kravhantering är ett ofta underskattat område inom programvaruteknik. Det här arbetet beskriver och testar en metod för att utvärdera mognadsgraden för kravhanteringen i mjukvaruprojekt. Det presenteras en modell att utvärdera mot, en metod för att utföra utvärderingen, och ett sätt att presentera resultaten från en utvärdering på ett sådant sätt att det lätt gå att se vad man kan göra för att förbättra kravhanteringsprocessen och få en enhetlig nivå på alla delmoment inom kravhantering.

Since its inception, software development has been recognized as a highly technical activity, where, at times, highly skilled professionals have been tempted to face technical problems on their own. In the past, software developers, may have been inclined to create solutions as if they were the only ones who needed to understand the solutions. However, nowadays, the disciplines of software development and systems development have undergone significant change. Current software development requires more crafting skills, in addition to engineering skills. The lone-cowboy programmer will soon have no place in properly organised software development projects. Current practices demand that a productive programmer be tasked to develop both working software (as claimed in the Agile Manifesto) and well crafted software. Accountability, pride in one's work, continuous learning and mentorship are characteristics of the profession that we should promote if we want to enable an attitude of craftsmanship within software development. This paper provides experiences of craftsmanship, and argues why software craftsmanship is good for the practitioner and software development organizations. To support this claim, we have analysed the development of a product that was developed by following several craftsmanship principles. We observed the product's development for seven years, and interviewed several professionals who were involved in its development.

Context. Software start-ups have shown their ability to develop and launch in- novative software products and services. Small, motivated teams and uncertain project scope makes start-ups good candidates for adopting Agile practices. Objective. We explore how start-ups use Agile practices and what effects can be associated with the use of those practices. Method. We use a case survey to analyze 84 start-up cases and 56 Agile prac- tices. We apply statistical methods to test for statistically significant associa- tions between the use of Agile practices, team, and product factors. Results. Our results suggest that backlog, version control, refactoring, and user stories are the most frequently reported practices. We identify 22 associations between the use of Agile practices, team, and product factors. The use of Agile practices is associated with effects on source code and overall product quality. A teams’ positive or negative attitude towards best engineering practices is a significant indicator for either adoption or rejection of certain Agile practices. To explore the relationships in our findings, we set forth a number of propositions that can be investigated by future research. Conclusions. We conclude that start-ups use Agile practices, however without following any specific methodology. We identify the opportunity for more fine- grained studies into the adoption and effects of individual Agile practices. Start- up practitioners could benefit from Agile practices in terms of better overall quality, tighter control over team performance and resource utilization.