Abstract With the advent of regulations protecting users such as the General Data Protection Regulation, security and privacy concerns are playing a new role in small settings such as in very small entities. Their relevance is increasing, and privacy is being considered a Troy horse in software developments. In fact, privacy is a part of software architectural decisions, and they must be considered as a technical debt. The contributions of this paper are the following: a privacy debt definition with a principal and an interest, privacy‐related activities to be considered within the ISO/IEC 29110 basic profile, and the use of the net present value within this context. All these contributions help us to integrate privacy debt and VSE's software developments.

Industries from very diverse domains are realising that security should not be treated in a reactive way (e.g., once the cyberattack has happened). This way, security-related requirements and risks need to be continuously managed, and the need of integrating technical measures should be continuously assessed. In some cases, some decisions led, intentionally or unintentionally, to debt related to security aspects. This security debt is thus incurred when limited approaches or solutions are applied to reach the expected security levels of the system in operation. Identifying and making explicit security debt items is a challenge for companies. In this work, we analyse the literature on security debt to provide initial insights on the topic. Concretely, we discuss its definition, identify its most salient characteristics, present approaches for integrating its management in the product life-cycle, and to present categories and examples of security debt items.

Abstract This study argues the difference between security and privacy and outlines the concept of Privacy Debt as a new Technical Debt. Privacy is gaining momentum in any software system due to mandatory compliance with respect to laws and regulations. There are several types of technical debts within the umbrella of software engineering, and most of them arise during different phases of software development. Several research studies have been focussed on highlighting different types of technical debts. However, authors introduce Privacy Debt as a particular technical debt focussed on privacy management and linked to a perturbative method. Privacy must be considered not only as technical debt requirements but also at design and deployment phases, among others. In addition, this method is illustrated with a use case.

Abstract Nowadays, security and safety aspects are two of the major concerns for any software system development, especially while developing safety critical systems. This is especially relevant for very small entities because they have a limited amount of resources for dealing with all these aspects at the same time. In addition, these systems are highly regulated domains, and they involve a huge set of standards focused on safety and security‐related issues. Therefore, these small entities are not only facing hurdles related to technical aspects but also from the so‐called technical debt when overarching a critical development. This paper extends the assurance cases approach by integrating security aspects within the life cycle, and it proposes a framework for managing the associated security technical debt for very small entities. A tool chain is outlined, and the approach is illustrated with an industrial use case.

Healthcare systems have been improved in order to provide support to cross‐border situations where one citizen from one country travels to another country and requires the use of their health records. Several initiatives have been carried out to tackle this problem. This is the case for the OpenNCP which is supported by the European Commission by providing a common network and an infrastructure to connect different national healthcare systems which most of the times are cloud‐based systems. The OpenNCP plays a key role in communicating health records among European Union's member states, and therefore it manages sensitive information. Therefore, this study provides a security analysis of this platform and a prototype is developed for identifying secure patterns in source code.

Abstract Software Process Improvement (SPI) initiatives have been applied in a wide set of organisations including very small entities (VSE). In fact, this kind of organisations is facing several hurdles when overarching a SPI initiative. In this context, the ISO/IEC 29110 has been used as a lightweight reference model for steering VSEs in their SPI initiatives. The inherent uncertainty behind the SPI curtains blocks the organisations in their investments. Due to these reasons, we need to identify relationships and similarities in order to predict whether a SPI will succeed or not. We propose the use of Self‐Organising Maps for identifying patterns from these SPI studies. The aim of this paper is to identify correlations among SPI studies and to discover patterns from them.

Abstract ISO/IEC 29110 is intended to help very small entities in improving their software processes. However, this standard is not the only initiative devoted to help organizations in these matters. For instance, ITMark is an established method with an important background in terms of number and diversity of assessments. The aim of this paper is to present a method to assess ISO/IEC 29110 by means of the evaluation performed under the ITMark certification schema built upon an experience factory. To do so, in this paper, authors present, firstly, a mapping for ITMark to ISO/IEC 29110 and, secondly, a study to test the applicability of the assessments made by ITMark in the ISO/IEC 29110 environment taking into account the previous mapping. The main conclusion from this industrial experience is that ITMark can be used as a method for assessing very small entities. Copyright © 2016 John Wiley & Sons, Ltd.

ABSTRACT Software process improvement (SPI) initiatives are facing complex environments where stakeholders need to integrate different reference models in their organizations. There are several approaches to multimodel environments defining some steps or activities that should be carried out for implementing it efficiently inside organizations. This paper presents a report on the use of a multimodel framework integrating three quality reference models in 47 SPI initiatives. Basically, this report is based on statistical data extracted from industrial assessments. Copyright © 2014 John Wiley & Sons, Ltd.