Search

Context: In despite of agile and rapid software development (ARSD) being researched and applied extensively, managing quality requirements (QRs) are still challenging. As ARSD processes produce a large amount of data, measurement has become a strategy to facilitate QR management. Objective: This study aims to survey the literature related to QR management through metrics in ARSD, focusing on: bibliometrics, QR metrics, and quality-related indicators used in quality management. Method: The study design includes the definition of research questions, selection criteria, and snowballing as search strategy. Results: We selected 61 primary studies (2001-2019). Despite a large body of knowledge and standards, there is no consensus regarding QR measurement. Terminology is varying as are the measuring models. However, seemingly different measurement models do contain similarities. Conclusion: The industrial relevance of the primary studies shows that practitioners have a need to improve quality measurement. Our collection of measures and data sources can serve as a starting point for practitioners to include quality measurement into their decision-making processes. Researchers could benefit from the identified similarities to start building a common framework for quality measurement. In addition, this could help researchers identify what quality aspects need more focus, e.g., security and usability with few metrics reported. This work has been funded by the European Union’s Horizon 2020 research and innovation program through the Q-Rapids project (grant no. 732253). This research was also partially supported by the Spanish Ministerio de Economía, Industria y Competitividad through the DOGO4ML project (grant PID2020-117191RB-I00). Silverio Martínez-Fernández worked in Fraunhofer IESE before January 2020.

The goal of secure software engineering is to create software that keeps performing as intended, even when exposed to attacks. Threat modelling is considered to be a key activity to reach this goal, but has turned out to be challenging to implement in agile teams. This paper presents results from four different studies, in which we have investigated how agile teams do threat modelling today. Study A is based on observations and document analysis from five teams in a single organisation, Study B is based on interviews with eight individuals from four different organisations, Study C is based on a questionnaire survey of 45 students at two different universities, and Study D is based on interviews with seven teams in a single organisation, supplemented with document analysis. Our results include findings, challenges and current good practice related to the use of Data Flow Diagrams, STRIDE and the Microsoft Threat Modelling Tool. We also cross-check our findings with previous relevant work, and provide recommendations for making the threat modelling activities more useful to agile teams.

Context: In the light of the swift and iterative nature of Agile Software Development (ASD) practices, establishing deeper insights into capability measurement within the context of team formation is crucial, as the capability of individuals and teams can affect team performance and productivity Although a former Systematic Literature Review (SLR) synthesized the state of the art in relation to capability measurement in ASD – with a focus on selecting individuals to agile teams, and capabilities related to team performance, productivity and success determining to what degree the SLR’s results apply to practice can provide progressive insights to both research and practice. Objective: Our study investigates how agile practitioners perceive the relevance of individual and team level measures for characterizing the capability of an agile team and its members. Here, the emphasis was also on selecting individuals to agile teams, and capabilities associated with effective teams in terms of their performance, productivity and success. Furthermore, to scrutinize variations in practitioners’ perceptions, our study further analyzes perceptions across stratified demographic groups. Method: We undertook a Web-based survey using a questionnaire built based on the capability measures identified from a previously conducted SLR. Results: Our survey responses (60) indicate that 127 individual and 28 team capability measures were considered as relevant by the majority of practitioners. We also identified seven individual and one team capability measure that have not been previously characterized by our SLR. The surveyed practitioners suggested that an agile team member’s responsibility and questioning skills significantly represent the member’s capability. Conclusion: Results from our survey align with our SLR’s findings. Measures associated with social aspects were observed to be dominant compared to technical and innovative aspects. Our results can support agile practitioners in their team composition decisions.

In the past decade, speed has become an essential trait of software development (e.g., agile, continuous integration, DevOps) and any inefficiency is considered unaffordable time waster. Such a fast pace causes challenges for architectural threat analysis. Leading techniques for threat analysis, like STRIDE, have the advantage of being systematic. However, they are not equipped to discern between important and less critical threats, while the threats are being discovered. Consequently, many threats are discarded at a later time, when their risk value is assessed. An alternative technique, called eSTRIDE, promises to remove these inefficiencies by focusing the analysis on the critical parts of the architecture. Yet, no empirical evidence exists about the actual effect of trading off systematicity, for a more focused attention on high-priority threats. This paper contributes with an empirical study comparing these two approaches in the context of two industrial case studies. We found that the two approaches yield the same number of security threats during a given time frame. However, participants using eSTRIDE found twice as many high-priority threats. The underlying analysis procedures cause similarities and differences in the execution. In addition, security expertise has an effect (albeit small) on the quality of analysis outcomes and execution.