Search

Background: Effort estimations are critical tasks greatly influencing the accomplishment of software projects. Despite their recognized relevance, little is yet known what indicators for inaccurate estimations exist, and which are the reasons of inaccurate estimations. Aims: In this manuscript, we aim at contributing to this existing gap. To this end, we implemented a tool that combines data analytics and developers’ feedback, and we employed that tool in a study. In that study, we explored the most common reasons of inaccurate user story estimations and the possible indicators of inaccurate estimations. Method: We relied on a mixed method approach used to study reasons and indicators for the identification and prediction of inaccurate estimations in practical agile software development contexts. Results: Our results add to the existing body of knowledge in multiple ways. We elaborate causes for inaccurate estimations going beyond the borders of existing literature; for instance, we show that lack of developers’ experience is the most common reason of inaccurate estimations. Further, our results suggest, for example, that the higher the complexity, the higher the uncertainty in the estimation. Conclusions: Overall, our results strengthen our confidence in the usefulness of using data analytics with human-in-the-loop mechanisms to improve effort estimations.

Context: Agile maturity models (AMMs) suggest that agile practices are introduced in a certain order. However, whether the order of agile practice introduction as suggested in the AMMs is relevant in industry has not been evaluated in an empirical study. Objectives: In this study, we want to investigate: (1) order of agile practice introduction mentioned in AMMs, (2) order of introducing agile practices in industry, and (3) similarities and differences between (1) and (2). Methods: We conducted a literature survey to identify strategies proposed by the AMMs. We then compared the AMMs’ suggestions to the strategies used by practitioners, which we elicited from a survey and a series of interviews from an earlier study. Results: The literature survey revealed 12 AMMs which provide explicit mappings of agile practices to maturity levels. These mappings showed little agreement on when practices should be introduced. Comparison of the AMMs’ suggestions and the empirical study revealed that the guidance suggested by AMMs are not aligned with industry practice. Conclusion: Currently, AMMs do not provide sufficient information to guide agile adoption in industry. Our results suggest that there might be no universal strategy for agile adoption that works better than others.

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.

Practically all organizations are developing data warehousing, business intelligence, and analytics (DW/BIA) projects for achieving customer value. A DW/BIA development project may be characterized by both agile and plan-driven aspects. The reported study investigated two research questions: (1) Which factor, agile values or plan-driven aspects, contributes more toward the success of DW/BIA? (2) What are the significant antecedents of agile values and plan-driven aspects? 124 respondents engaged in DW/BIA development filled a 30-item questionnaire on seven constructs. The partial least squares structural equation modeling (PLS-SEM) method was used to determine the strength of the relationships among the following factors: technological capability, shared understanding, top management commitment, and complexity as antecedents; agile values and plan-driven aspects as mediating; and project success as the dependent construct. Based on a prediction-oriented segmentation (PLS-POS) analysis, the findings indicate that there are two groups, agile-plan balanced and agile-heavy, which represent different approaches to DW/BIA development. Top management commitment and shared understanding emerge as strong antecedents to agile values and plan-driven aspects. Overall, the factor agile values contributes more toward the success of DW/BIA development.

Context: An effective development model can help improve competitive advantage and shorten release cycles, which is vital in the fast paced environment of mobile app development.Objective: The aim with this paper is to provide an extensive review of existing mobile app development models.Method: The review is done by following a systematic literature review process. Also presented is an assessment of the usefulness and relevance to industry of the models based on a rigor and relevance framework.Results: 20 primary studies were identified, each with distinct models. Agile methods or state-based principles are commonly adopted across the models. Relatively little effort focuses on deployment, maintenance, project evaluation activities.Conclusion: The review reveals that the contexts in which the identified models are intended to be used vary. This benefits practitioners as they are able to select a model that suits their contexts. However, the usefulness in industry of most of the models, based on the contexts in which the models were evaluated, is questionable. There is a need for evaluating mobile app models in contexts that resemble realistic contexts. The review also calls for further research addressing special constraints of mobile apps, e.g., testing apps on multiple-platforms, user involvement in release planning and continuous deployment.

Teaching agile practices has found its place in software engineering curricula in many universities across the globe. As a result, educators and students have embraced different ways to apply agile practices during their courses through lectures, games, projects, workshops and more for effective theoretical and practical learning. Practicing agile in university contexts comes with challenges for students and to counter these challenges, they perform some adaptations to standard agile practices making them effective and easier to use in university contexts. This study describes the constraints the students faced while applying agile practices in a university course taught at the University of Auckland, including difficulty in setting up common time for all team members to work together, limited availability of customer due to busy schedule and the modifications the students introduced to adapt agile practices to suit the university context, such as daily stand-ups with reduced frequency, combining sprint meetings, and rotating scrum master from team. In addition, it summarizes the effectiveness of these modifications based on reflection of the students. Recommendations for educators and students are also provided. Our findings and recommendations will help educators and students better coordinate and apply agile practices on industry-based projects in university contexts.

Architectural threat analysis has become an important cornerstone for organizations concerned with developing secure software. Due to the large number of existing techniques it is becoming more challenging for practitioners to select an appropriate threat analysis technique. Therefore, we conducted a systematic literature review (SLR) of the existing techniques for threat analysis. In our study we compare 26 methodologies for what concerns their applicability, characteristics of the required input for analysis, characteristics of analysis procedure, characteristics of analysis outcomes and ease of adoption. We also provide insight into the obstacles for adopting the existing approaches and discuss the current state of their adoption in software engineering trends (e.g. Agile, DevOps, etc.). As a summary of our findings we have observed that: the analysis procedure is not precisely defined, there is a lack of quality assurance of analysis outcomes and tool support and validation are limited.

Context:Requirements Engineering (RE) is one of the key processes in software development. Since Agile software development advocates continuous improvement, the question arises which Agile RE practices are the most essential and shall be adopted/improved at first? Objective:Investigate and rank the Agile RE practices based on how practitioners perceive their importance for a software project. Method:We conducted a survey asking 136 Agile software development practitioners how they perceive the importance of the 31 Agile RE practices that we had identified in a literature study. We used a ranking method based on the PROMETHEE family methods to create the ranking of relative importance of the practices. Results:The opinions of respondents from a wide range of countries around the globe allowed us to determine the perceived importance of the Agile RE practices and create a seven-tier ranking of the practices. Moreover, the analysis concerning demographic data let us identify some relationships between the experience of the respondents and their view on the importance of the Agile RE practices. Conclusions:Our findings suggest the most critical Agile RE practices are those supporting iterative development with emergent requirements and short feedback loop. Moreover, in many cases, the perceived importance of practices seems to depend on the context of the project (e.g., methodology, domain). We also learned that the popularity of the practices is highly correlated with their perceived importance.

Agile Software Development (ASD) has several limitations concerning its requirements engineering activities. Improving the quality of Software Requirements Specifications (SRSs) in ASD may help to gain a competitive advantage in the software industry. Based on the findings of a Systematic Mapping study, six industrial case studies in different contexts were conducted to investigate and characterize the requirements specification activity in ASD. Data collected from documents, observations, and interviews with software engineers were triangulated, analyzed, and synthesized using Grounded Theory and Meta-Ethnography. The analysis and cross-synthesis of the six case studies resulted in a model describing the phenomenon. This model defines the simplicity and objectivity as essential quality factors of SRSs in ASD. The main factors that affect the SRSs quality in ASD projects are related to their customer-driven nature that leads to prolix SRSs, hindering its understanding from the developer perspective. The emerged model is supported by explanations and provides a deeper understanding of the requirements specification activity in ASD. This creates opportunities for further studies and improvements in SRSs for ASD in industry.

SCRUM picture was replaced.Requirements modification statement was revised.References format was corrected. ContextRequirements engineering in agile software development is a relatively recent software engineering topic and it is not completely explored and understood. The understanding of how this process works on agile world needs a deeper analysis. ObjectiveThe goal of this paper is to map the subject area of requirements engineering in agile context to identify the main topics that have been researched and to identify gaps to develop future researches. It is also intended to identify the obstacles that practitioners face when using agile requirements engineering. MethodA systematic mapping study was conducted and as a result 2171 papers were initially identified and further narrowed to 104 by applying exclusion criteria and analysis. ConclusionAfter completing the classification and the analysis of the selected studies it was possible to identify 15 areas (13 based on SWEBOK) where researches were developed. Five of such areas points to the need of future researches, among them are requirements elicitation, change management, measuring requirements, software requirements tools and comparative studies between traditional and agile requirements. In this research, some obstacles that practitioners face dealing with requirements engineering in agile context were also identified. They are related to environment, people and resources.

The software development industry adopts agile methods in different ways by considering contextual requirements. To fulfill organizational needs, adoption strategies consider agile methods tailoring. However, tailoring according to the context of the organization remains a problem to be solved. Literature on criteria for adopting software development methods exists, but not specifically for agile methods. Given this scenario, the following research question arises: what is the impact of software method tailoring criteria on the adoption of agile practices? To answer this question, we conducted a survey among agile practitioners in Brazil to gather data about importance of the tailoring criteria and agile practices adopted. A model for agile practices adoption based on the tailoring criteria is proposed using the results of the survey with a majority of novice agile practitioners. The proposed model was validated using PLS-SEM (partial least squares structural equation modeling) and the survey data. Results show that adoption of agile practices was influenced by criteria such as external environment, previous knowledge and internal environment. Results also indicate that organizations tend to use hybrid/custom software methods and select agile practices according to their needs.

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.

User Acceptance Testing (UAT) involves validating software in a real setting by the intended audience. The aim is not so much to check the defined requirements but to ensure that the software satisfies the customer’s needs. Agile methodologies put stringent demands on UAT, if only for the frequency at which it needs to be conducted due to the iterative development of small product releases. In this setting, traditional in-person meetings might not scale up well. Complementary ways are needed to reduce the costs of developer-customer collaboration during UAT. This work introduces a wiki-based approach where customers and developers asynchronously collaborate: developers set the UAT scaffolding that will later shepherd customers when testing. To facilitate understanding, mind maps are used to represent UAT sessions. To facilitate engagement, a popular mind map editor, FreeMind, is turned into an editor for FitNesse, the wiki engine in which these ideas are borne out. The approach is evaluated through a case study involving three real customers. First evaluations are promising. Though at different levels of completeness, the three customers were able to complete a UAT. Customers valued asynchronicity, mind map structuredness, and the transparent generation of documentation out of the UAT session.

This study aims to identify how traditional organizational roles are transformed towards Agile roles. A grounded theory study with 5 software teams in a large software development company in Spain was conducted. We interviewed 21 people, participated in Agile Coaching sessions and observed daily activities in the company during a six-month period. The transition of organizational roles during the Agile transformation process is influenced by many circumstances such as: higher management commitment and support, knowledge about Agile, project team size and culture. The theory demonstrates how enterprise factors influence the transition of organizational roles and how practitioners cope with the challenges during the Agile transformation process. Based on our results, we proposed recommendations and guidelines for organizational roles transition during the Agile method adoption.

Corrigendum: DOI:10.1016/j.jss.2019.02.022 Software development in highly dynamic environments imposes high risks to development organizations. One such risk is that the developed software may be of only little or no value to customers, wasting the invested development efforts. Continuous experimentation, as an experiment-driven development approach, may reduce such development risks by iteratively testing product and service assumptions that are critical to the success of the software. Although several experiment-driven development approaches are available, there is little guidance available on how to introduce continuous experimentation into an organization. This article presents a multiple-case study that aims at better understanding the process of introducing continuous experimentation into an organization with an already established development process. The results from the study show that companies are open to adopting such an approach and learning throughout the introduction process. Several benefits were obtained, such as reduced development efforts, deeper customer insights, and better support for development decisions. Challenges included complex stakeholder structures, difficulties in defining success criteria, and building experimentation skills. Our findings indicate that organizational factors may limit the benefits of experimentation. Moreover, introducing continuous experimentation requires fundamental changes in how companies operate, and a systematic introduction process can increase the chances of a successful start.

This paper refines a model of Sustained Agile Usage to present a comprehensive understanding of the key factors that are pertinent to the sustained usage of agile methodologies. It describes our qualitative study which involves: (i) a focus group with twenty-nine software industry agile practitioners, and (ii) semi-structured interviews with twenty agile practitioners from five different organizational backgrounds. Data from both methods is used to develop the refined model of Sustained Agile Usage. The refined Sustained Agile Usage Model includes the following three categories: Agile Team Factors, Technological Factors, and Organizational Factors. These revisions are discussed in this research. Finally, we see implications for research: the study offers a useful complement to the few studies that have examined the long-term acceptance of agile methods. The refined model can be used as a reference model to guide future studies to understand sustained usage in different agile domains (e.g. Kanban). Additionally, implications for practice include valuable insights that can help agile teams and others (e.g. top management) to better understand and benchmark how agile methods can be effectively sustained in organizations.

As the application of the principles of agile and lean software development, software multiple release becomes very common in the modern society. Short iteration and short release cycle have driven the significant changes of the development process of multi-release software product, compared with single release software product. Thus, it is time to conduct a new study investigating the impact level of environmental factors on affecting software reliability in the development of multi-release software to provide a sound and concise guidance to software practitioners and researchers. Statistical learning methods, like principle component analysis, stepwise backward elimination, lasso regression, multiple linear regression, and Tukey method, are applied in this study. Comparisons regarding significant environmental factors during the whole development process, principle components, significant environmental factors in each development phase and significance level of each development phase between the development of single release software and multi-release software are also discussed.

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.

Context: Software development processes are considered as knowledge intensive and therefore Knowledge Management (KM) can be applied to efficiently manage the knowledge generated. Agile practices can benefit software organizations in terms of KM. Some studies have already presented evidence about this relationship. However, the intersection of these two areas still requires further clarification. Objective: This study synthesizes research on KM and Agile Software Development (ASD) using the meta-ethnography method considering Scrum and XP frameworks. Method: In order to achieve the proposed goal, first, a diagnostic was conducted in different project domains with agile and traditional software development in order to identify the performance of KM activities. Second, the phases of the meta-ethnography analysis method were applied in a set of studies selected from a tertiary review on KM and ASD, as well as classic guides and area references. Finally, the relationships that were identified among the areas investigated were analyzed from interviews with agile development methodology experts. Results: The most common activity investigated between KM and ASD is knowledge sharing. However, in the practical view of software development companies, the attention is on how to use the generated knowledge. Conclusion: The clarification of how KM is present in each agile value, practices, and artifacts allows a reflection on how much knowledge was created, shared, and applied during ASD. Besides, such results presented in this study enable organizations to know each other better and to explore more each KM activity, thus contributing to delivering more value to the customer.

Every company wishes to improve its system quality and security, all the more so in these times of digital transformation, since having a good quality and security management system is essential to any company’s commercial survival. Such needs are even more pressing for small and medium-sized enterprises (SMEs), given their limited time and resources. To address these needs, a Spanish company, Proceso Social, has developed an innovative method called “SevenWeeks” to allow SMEs to create or improve their quality and security management systems in just seven weeks, with a view to obtaining one or both of the ISO 9001 and ISO/IEC 27001 certifications. We have evaluated the effectiveness and usefulness of SevenWeeks by carrying out a multi-case study of 26 Spanish companies, based on independent sources of evidence. This allowed us to corroborate that SevenWeeks was indeed effective for and perceived as useful by all the companies, as it enabled them to create their own quality and security management systems in only seven weeks and to obtain the necessary ISO certification. The interviewees found SevenWeeks to be an agile and intuitive method, easy to implement, which reduces costs and effort. We also include some recommendations to improve and further develop the method.

To meet changing requirements and rising product complexity, a growing number of traditional logistics companies and logistics startups are increasing their agility through the use of progressively agile methods. The objective of the Delphi Study is to assess how traditional logistics companies and logistics startups use agile methods in their IT departments, what benefits they realise and what challenges they face introducing and using agile methods. A modified Delphi Study was conducted over three complementary rounds as an iterative expert judgment process. After the analysis of the results, insights were gained on the following points covering traditional logistics companies and logistics startups: (a) used agile methods and practices, (b) perceived benefits that these methods offer and (c) challenges of applying these methods. The results of the Delphi Study show that traditional logistics companies as well as logistics startups chose similar agile methods and practices. Both company types aim to realise mainly the same benefits but face different challenges regarding the introduction of agile methods. The Delphi Study’s originality lies in its contribution to the largely unexplored area of agility in the field of logistics.

Component-based development (CBD) relies on the use of pre-fabricated business components to develop new application systems, rather than developing them from scratch. It provides an attractive alternative to more established development methods such as object-oriented analysis and design (OOAD). Given the growing demands for using agile methods for software development, we examine if systems analysts are more effective at modeling business systems by reusing business components than by reusing objects. We also examine whether the influence of component or object reuse on modeling performance is moderated by prior experience in systems analysis and design. We evaluate the representational constructs of the two based on a set of decomposition characteristics, and postulate hypotheses comparing the two based on theories in cognitive psychology and human factors. We find that models generated by reusing business components are of higher accuracy than those developed by reusing objects. An interesting finding of our study is that IT professionals who are less experienced in systems analysis and design perform on par with experienced professionals, when modeling business systems by reusing components. We argue that the decomposition characteristics of components—with respect to granularity, quality, and focus—enable less experienced analysts to perform on par with more experienced analysts.

An approach to software architecting in agile projects in education.Experiences and lessons learned from two applications of the approach.Research directions for improving education on architecting in agile projects. Software architecting activities are not discussed in most agile software development methods. That is why, the combination of software architecting and agile methods has been in the focus of numerous publications. However, there is little literature on how to approach software architecting in agile projects in education. In this paper, we present our approach to the introduction of software architecting activities in an agile project course. The approach is based on literature sources and is tailored to fit our educational goals and context. The approach has been applied in two consecutive executions of the course. We observe improved understanding on the value of architecting activities and appreciation among students on the combination of architecting activities and agile development. We applied the approach predominantly in cases with an architecturally savvy Product Owner. Further research is required to understand how the approach performs in scenarios with architecturally unsavvy Product Owners and if it needs to be adapted for these scenarios. We also conclude that more research is needed on the challenges that architects face in agile projects in order to better prepare students for practice.

Metrics of the continuity of continuous integration proposed and discussed.Organizational size found to correlate with CI continuity.Evidence of correlation between continuity and organization composition discovered.Findings discussed in the context of architectural styles and manufacturability. The practice of continuous integration has firmly established itself in the mainstream of the software engineering industry, yet many questions surrounding it remain unanswered. Prominent among these is the issue of scalability: continuous integration has been reported to be possible to scale, but with difficulties. Understanding of the underlying mechanisms causing these difficulties is shallow, however: what is it about size that is problematic, which kind of size, and what aspect of continuous integration does it impede? Based on quantitative data from six industry cases encompassing close to 2000 engineers, complemented by interviews with engineers from five companies, this paper investigates the correlation between the continuity of continuous integration and size. It is found that not only is there indeed a correlation between the size and composition of a development organization and its tendency to integrate continuously; there is evidence that the size of the organization influences ways of working, which in turn correlate with the degree of continuity, raising the question of software manufacturability. It is further observed that developer behavior in ostensibly continuously integrating cases does not necessarily match expectations, and that frequent integration of the product itself does not automatically imply that each individual developer commits frequently.

Examines how Value is interpreted in 14 agile software development organizations.Data is collected from 13 project managers and 10 product owners.Sixteen categories of Value Aspects are identified and prioritized.The most important Value Aspect is Delivery process w.r.t. time.The most used activity to achieve Value is activities related to agile practices. The Agile manifesto focuses on the delivery of valuable software. In Lean, the principles emphasise value, where every activity that does not add value is seen as waste. Despite the strong focus on value, and that the primary critical success factor for software intensive product development lies in the value domain, no empirical study has investigated specifically what value is. This paper presents an empirical study that investigates how value is interpreted and prioritised, and how value is assured and measured. Data was collected through semi-structured interviews with 23 participants from 14 agile software development organisations. The contribution of this study is fourfold. First, it examines how value is perceived amongst agile software development organisations. Second, it compares the perceptions and priorities of the perceived values by domains and roles. Third, it includes an examination of what practices are used to achieve value in industry, and what hinders the achievement of value. Fourth, it characterises what measurements are used to assure, and evaluate value-creation activities.

Context:Development of software-intensive products and services increasingly occurs by continuously deploying product or service increments, such as new features and enhancements, to customers. Product and service developers must continuously find out what customers want by direct customer feedback and usage behaviour observation. Objective: This paper examines the preconditions for setting up an experimentation system for continuous customer experiments. It describes the RIGHT Model for Continuous Experimentation (Rapid Iterative value creation Gained through High-frequency Testing), illustrating the building blocks required for such a system. Method: An initial model for continuous experimentation is analytically derived from prior work. The model is matched against empirical case study findings from two startup companies and further developed. Results: Building blocks for a continuous experimentation system and infrastructure are presented. Conclusions: A suitable experimentation system requires at least the ability to release minimum viable products or features with suitable instrumentation, design and manage experiment plans, link experiment results with a product roadmap, and manage a flexible business strategy. The main challenges are proper, rapid design of experiments, advanced instrumentation of software to collect, analyse, and store relevant data, and the integration of experiment results in both the product development cycle and the software development process.

Agile development processes, such as Scrum, focus on communication, developer collaboration and delivery of working software early and continuously. User-centered systems design (UCSD) is a process emphasizing usability and the user experience throughout the system life cycle. It highlights the UCSD activities: understanding the context of use, iterative prototyping to explore the design space and active collaboration with users throughout the software development. Agile processes are by many assumed to address similar issues as UCSD, hence, by applying Agile processes the systems would become usable for the end-users and their user experience should improve. This paper discusses and interprets findings on UCSD activities in Agile projects in practice, that are analyzed according to the fundamental principles from the Agile manifesto. We show that Agile development has much to gain from integrating UCSD, and give guidance on how to integrate UCSD in Agile processes. User experience (UX) professionals need a more explicit role in the Agile projects and more authority. We recommend that they receive a “license to kill” design suggestions that are not perceived as useful by the users.

Context: Software has become ubiquitous in every corner of modern societies. During the last five decades, software engineering has also changed significantly to advance the development of various types and scales of software products. In this context, Software Engineering Education plays an important role in keeping students updated with software technologies, processes, and practices that are popular in industries. Objective: We investigate from literature the extent Software Engineering Education addresses major Software Engineering Trends in the academic setting. Method: We conducted a systematic mapping study about teaching major Software Engineering Trends in project courses. We classified 126 papers based on their investigated Software Engineering Trends, specifically Software Engineering processes and practices, teaching approaches, and the evolution of Software Engineering Trends over time. Results: We reveal that Agile Software Development is the major trend. The other Trends, i.e., Software Implementation, Usability and Value, Global Software Engineering, and Lean Software Startup, are relatively small in the academic setting, but continuously growing in the last five years. System of Systems is the least investigated among all Trends. Conclusions: The study points out the possible gaps between Software Industry and Education, which implies actionable insights for researchers, educators, and practitioners.

Context: Agile methods have become mainstream even in large-scale systems engineering companies that need to accommodate different development cycles of hardware and software. For such companies, requirements engineering is an essential activity that involves upfront and detailed analysis which can be at odds with agile development methods. Objective: This paper presents a multiple case study with seven large-scale systems companies, reporting their challenges, together with best practices from industry. We also analyze literature about two popular large-scale agile frameworks, SAFe® and LeSS, to derive potential solutions for the challenges. Methods: Our results are based on 20 qualitative interviews, five focus groups, and eight cross-company workshops which we used to both collect and validate our results. Results: We found 24 challenges which we grouped in six themes, then mapped to solutions from SAFe®, LeSS, and our companies, when available. Conclusion: In this way, we contribute a comprehensive overview of RE challenges in relation to large-scale agile system development, evaluate the degree to which they have been addressed, and outline research gaps. We expect these results to be useful for practitioners who are responsible for designing processes, methods, or tools for large scale agile development as well as guidance for researchers.

As the software industry transitions to a subscription-based software-as-a-service (SaaS) model, software development companies are transforming to hybrid development organizations with increased adoption of Agile and Continuous Integration/ Continuous Delivery (CI/CD) development practices for newer products while continuing to use Waterfall methods for older products. This transformation is a huge undertaking impacting all aspects of the software development life cycle (SDLC), including the quality management system. This paper presents a case study of a large-scale transformation of a legacy quality management system to a modern system developed and implemented at Cisco Systems. The framework for this transformation is defined by six distinct areas: metrics, process, measurement, reporting, quality analytics, and culture & leadership. Our implementation leveraged recent advances in Machine Learning (ML), Artificial Intelligence (AI), connected data, integrated operations, and big data technologies to solve the challenges created by a hybrid software development organization. We believe this case study will help researchers and industry leaders understand the benefits and potential challenges of such sizeable transformations.

Given the relevance of coordination in the field of global software engineering, this work was carried out to further understand coordination mechanisms. Specifically, we investigated meetings and the collaboration tool Slack. We conducted a longitudinal case study using a mixed-methods approach with surveys, observations, interviews, and chat logs. Our quantitative results show that employees in global projects spend 7 hours 45 minutes per week on average in scheduled meetings and 8 hours 54 minutes in unscheduled meetings. Furthermore, distributed teams were significantly larger than co-located teams, and people working in distributed teams spent somewhat more time in meetings per day. We found that low availability of key people, absence of organizational support for unscheduled meetings and unbalanced activity from team members in meetings and on Slack were barriers for effective coordination across sites. The positive aspects of using collaboration tools in distributed teams were increased team awareness and informal communication and reduced the need for e-mail. Our study emphasizes the importance of reflecting on how global software engineering teams use meetings and collaboration tools to coordinate. We provide practical advice for conducting better meetings and give suggestions for more efficient use of collaboration tools in global projects., Comment: 33 pages

The integration of user experience (UX) work with agile software development has been addressed in extensive research of challenges and process models. However, in-depth research of context-specific improvements of this integration with actual UX professionals and agile developers in their actual practice is limited. This study examines how the integration of UX work with agile development can be improved in the context of a small Danish Software-as-a-Service (SaaS) company. We used the problem- and solution-oriented action research method over 12 months in the company. During this period, we initially carried out extensive participant observations, recorded 32 semi-structured interviews, and finally conducted two improvement iterations with evaluations of their effect on agility. We identified user stories as an essential indicator of UX integration. Verbose user stories imply problems in collaboration and trust, while concise user stories and deliberation improve integration of UX work with agile development. The conclusion is that integrating UX work with agile development in practice is complex, contextualized, and difficult even for only a small part of it. We propose that concise user stories and deliberation can be useful and well-defined focuses for integrating UX work with agile software development without sacrificing their agility.

The declaration of the Agile Manifesto in 2001 was hailed as a paradigmatic shift in the development of software systems. Initially, agile development was typically deployed in projects with a single team with fewer than ten members. Recently, a new kind of agile development has emerged for larger projects that may be referred to as large-scale agile methodology (LSAM). The taxonomy of LSAM is more enhanced and subsumes the Agile Manifesto. Based on the software development literature, the study investigates five important antecedents of methodology acceptance: perceived usefulness, compatibility, subjective norm, mandatoriness, and external support. As a result of the initial PLS analysis, the study introduces the notion of Job-Work Fit as a second-order construct composed of perceived usefulness and compatibility. Based on a survey of 123 respondents, the study finds that the construct job-work fit significantly explains the LSAM acceptance for large projects. Job-work fit also mediates the relationships between subjective norm and external support with LSAM acceptance. This research suggests that as the stakes become higher because of project size and agility, job-work fit emerges as the central determinant of LSAM acceptance.

We performed a tertiary study in Agile and Lean methods.TDD is the most studies Agile practice.Each Agile and Lean practice has trade-offs. The growing interest in Agile and Lean software development is reflected in the increasing number of secondary studies on the benefits and limitations of Agile and Lean processes and practices. The aim of this tertiary study is to consolidate empirical evidence regarding Agile and Lean practices and their respective impacts on project constraints as defined in the Project Management Body of Knowledge (PMBOK): scope, quality, schedule, budget, resources, communication, and risk. In this tertiary study, 13 secondary studies were included for detailed analysis. Given the heterogeneity of the data, we were unable to perform a rigorous synthesis. Instead, we mapped the identified Agile and Lean practices, and their impacts on the project constraints described in PMBOK. From 13 secondary studies, we identified 13 Agile and Lean practices. Test-Driven Development (TDD) is studied in ten secondary studies, meanwhile other practices are studied in only one or two secondary studies. This tertiary study provides a consolidated view of the impacts of Agile and Lean practices. The result of this tertiary study indicates that TDD has a positive impact on external quality. However, due to insufficient data or contradictory results, we were unable to make inferences on other Agile and Lean practices. Implications for research and practice are further discussed in the paper.

Examines three cases on applying agile practices into embedded system development.Visibility of work and system-wide understanding increased.Improved communication diminished the need for internal documentation.Slow hardware development and specialization of team members challenged agile methods.If not possible to present working product, visualize the progress in other ways. Agile methods are widely utilized in software development but their usage in embedded system development is often limited to software. A case study of three industrial cases was carried out to understand how to tailor agile methods effectively including also hardware development.Agile practices, mostly derived from Scrum, were tailored to fit the needs of each team and the method development was closely followed. Surveys conducted in the beginning and in the end of the cases were compared and complemented with interviews to understand the new working methods and their effects.Case evidence shows that interdependencies between work of each developer were taken into account better, visibility over the whole product increased and need for internal documentation diminished due to improved communication, but dividing hardware tasks into iterations was experienced difficult. With some tailoring, agile practices are beneficial also in the embedded system development.To successfully adopt agile methods into embedded system development, the team must consist of all the project members, the natural cycle lengths of different disciplines and different knowledge between the developers must be accepted and built upon, and the progress of the product must be presented or visualized in the end of each iteration.

A systematic literature review on engineering software for ubiquitous systems.We identified 132 approaches addressing issues on different phases of the software engineering cycle for ubiquitous systems.Implementation, evolution/maintenance, and feedback phases have been the most studied.The testing phase needs to receive more attention, especially in what respect to simulations. Context: Software engineering for ubiquitous systems has experienced an important and rapid growth, however the vast research corpus makes it difficult to obtain valuable information from it.Objective: To identify, evaluate, and synthesize research about the most relevant approaches addressing the different phases of the software development life cycle for ubiquitous systems.Method: We conducted a systematic literature review of papers presenting and evaluating approaches for the different phases of the software development life cycle for ubiquitous systems. Approaches were classified according to the phase of the development cycle they addressed, identifying their main concerns and limitations.Results: We identified 128 papers reporting 132 approaches addressing issues related to different phases of the software development cycle for ubiquitous systems. Most approaches have been aimed at addressing the implementation, evolution/maintenance, and feedback phases, while others phases such as testing need more attention from researchers.Conclusion: We recommend to follow existing guidelines when conducting case studies to make the studies more reproducible and closer to real life cases. While some phases of the development cycle have been extensively explored, there is still room for research in other phases, toward a more agile and integrated cycle, from requirements to testing and feedback.

Conceptual model of office space arrangement for Scrum teams is proposed.The model has been implemented and tested in an IT organisation.Conceptual model can be adopted in any organisation using Scrum.Work present IT projects office requirements, especially managed by Scrum. IT project management according to the Agile principles will be less effective if the space where the teams work is not arranged properly. In this paper, a model of office space arrangement for the needs of teams using the Agile methodology is proposed. The main aim of the model is to support Scrum Teams in carrying out project tasks in a more efficient and effective way. The conceptual model is based on requirements that should be fulfilled by offices destined to have Agile (Scrum) working teams and can be adopted in any organization. The model has been implemented and validated.

Self-organizing teams are closely involved in project management activities.High team involvement in project management leads to new challenges.We present the multiple levels of agile project management challenges.Relationships between challenges at different levels were also identified.Teams and managers need to address these challenges in order to be effective. Agile software development advocates self-organizing teams that display high levels of autonomy. Self-organizing agile teams are meant to share project management activities such as estimation, planning, and requirements elicitation with managers and customers. While prior literature has explored some individual management-related issues, little is known about how the high involvement of self-organizing agile teams influences everyday project management activities. Through a Grounded Theory study involving 21 agile practitioners across six software companies implementing scrum and XP, we identified a set of eight project management challenges as experienced by and as a result of self-organizing agile teams at multiple levels. These include delayed/changing requirements and eliciting senior management sponsorship at the project level; achieving cross-functionality and effective estimations at the team level; asserting autonomy and self-assignment at the individual level, and lack of acceptance criteria and dependencies at the task level. A mapping between the emergent challenges and standard project management activities is also presented. The article also shares practical implications and guidelines for agile teams, their managers, and customers for overcoming some of these challenges.

We provide a quantitative metrics model to evaluate the impact of an agile and lean transformation.We propose eight rigorously described metrics within that model.We establish and apply the model in a large international telecommunication organization with 350 employees in two sites.Our findings show significant improvement in six of the eight metrics whereas one metric showed deteriorated results. Context: Agile software development continues to grow in popularity and is being adopted by more and more organizations. However, there is a need for empirical evidence on the impact, benefits and drawbacks of an agile transformation in an organization since the cost for such a transformation in terms of money, disrupted working routines and quality of development can become considerable. Currently, such evidence exists in the form of success stores and case studies, mostly of qualitative nature.Objective: Provide a metrics model to quantitatively measure the impact of an agile transformation in a software development organization.Method: The metrics model was elicited with the use of the Goal Question Metric approach.Results: A quantitative metrics model containing eight rigorously described metrics is presented and followed by its application to evaluate an agile and lean transformation in a large international telecommunication organization with 350 employees in two sites.Conclusions: The metrics model was sensitive to the changes that occurred in the organization and revealed significant improvements in six of the eight metrics and a deterioration in one of the metrics.

We develop a series of intervention actions to mitigate collaboration issues in chains of Scrum teams.We implement the intervention actions in a Scrum chain at a financial service provider.The interventions result in a feature delivery time reduction from 29 to 10 days.We package the intervention actions in a governance framework for chains of Scrum teams. Many enterprises that adopt Agile/Scrum suffer from collaboration issues between Scrum teams that depend on one another to deliver end-to-end functionality. These dependencies delay delivery and as a result deteriorate the business value delivered in such value chains. The objective of our study is to support enterprises that suffer from such dependencies with a governance framework that helps them mitigate collaboration issues between sets of codependent Scrum teams. We first identify a set of intervention actions that aim to mitigate the collaboration issues between codependent Scrum teams. Second, we validate the effectiveness of these intervention actions in a large confirmatory industrial case study. This study was held in a large multi-national financial institute that worked with a large number of codependent Scrum teams. Third, we triangulate the findings in three focus groups. We finally package the intervention actions in a governance framework. The intervention actions led to a delivery time reduction from 29 days to 10 days. The participants in the focus groups confirmed the causality between the intervention actions and the observed delivery improvement. The empirical results show that the intervention actions, packaged in the governance framework, enable codependent sets of Scrum teams to deliver faster.

Considerable attention has been paid to teaching Scrum in software engineering education as an academic response to the software industry's demands. In order to reinforce and strengthen the understanding of Scrum concepts, professors should personalize the learning process, catering for students' individual learning characteristics. To address this issue, learning styles become effective to understand students' different ways of learning. In this context, the meshing hypothesis claims that when both teaching and learning styles are aligned, the students' learning experience is enhanced. However, the literature fails to evidence support for the meshing hypothesis in the context of software engineering education. We aim to corroborate the meshing hypothesis by using teaching strategies matching the Felder-Silverman Learning Style Model in a Scrum course. Based on previous findings, we focused on the processing dimension of the model. To validate our approach, two experiments were conducted in an undergraduate software engineering course in the academic years 2013 and 2014. We provided students with a Scrum class by applying teaching strategies suiting students' learning style. Test results corroborate that students' outcomes improved when receiving the strategy that match their learning styles. Our data highlight opportunities for improving software engineering education by considering the students' learning preferences. Fil: Scott, Mario Ezequiel. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentina Fil: Rodríguez, Guillermo Horacio. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentina Fil: Soria, Alvaro. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentina Fil: Campo, Marcelo Ricardo. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Conicet - Tandil. Instituto Superior de Ingeniería del Software. Universidad Nacional del Centro de la Provincia de Buenos Aires. Instituto Superior de Ingeniería del Software; Argentina

In this paper we address the topic of software development team members satisfaction with their development process. We present an in-depth analysis of the results of a nationwide survey about software development in Switzerland. We wanted to find out if satisfaction relates to the applied development method, and to the use of various practices, and impacts on business, team and software issues. We found that higher satisfaction is reported more by those using Agile development than with plan-driven processes. We explored the different perspectives of developers and those with a management role and found a high consistency of satisfaction between Agile developers and Agile management, and differences with those using working plan-driven methods. We found that certain practices and impacts have high correlations to satisfaction, and that collaborative processes are closely related to satisfaction. We then explored the relationship between satisfaction and various other perspectives. Our results in this analysis are principally descriptive, but we think they can be a relevant contribution to understand the challenges for everyone involved in Agile development.

Government and academia share concerns for efficiently and effectively servicing societal demands, which includes the development of e-government software. Government-academia partnerships can be a valuable approach for improving productivity in achieving these goals. However, governmental and academic institutions tend to have very different agendas and organizational and managerial structures, which can hinder the success of such collaborative projects. In order to identify effective approaches to overcome collaboration barriers, we systematically studied the case of the Brazilian Public Software portal project, a 30-month government-academia collaboration that, using Free/Libre/Open Source Software practices and agile methods for project management, developed an unprecedented platform in the context of the Brazilian government. We gathered information from experience reports and data collection from repositories and interviews to derive a collection of practices that contributed to the success of the collaboration. In this paper, we describe how the data analysis led to the identification of a set of three high-level decisions supported by the adoption of nine best practices that improved the project performance and enabled professional training of the whole team.

Requirements prioritization is an important issue that determines the way requirements are selected and processed in software projects. There already exist specific methods to classify and prioritize requirements, most of them based on quantitative measures. However, most of existing approaches do not consider collisions, which are an important concern in large-scale requirements sets and, more specifically, in agile development processes where requirements have to be uniquely selected for each software increment. In this paper, we propose QMPSR (Qualitative Method for Prioritizing Software Requirements), an approach that features the prioritization of requirements by considering qualitative elements that are related to the project's priorities. Our approach highlights a prioritization method that has proven to reduce collisions in software requirements rankings. Furthermore, QMPSR improves accuracy in classification when facing large-scale requirements sets, featuring no scalability problems as the number of requirements increases. We formally introduce QMPSR and then define prioritization effort and collision metrics to carry out comprehensive experiments involving different sets of requirements, comparing our approach with well-known existing prioritization methods. The experiments have provided satisfactory results, overcoming existing approaches and ensuring scalability, This work was partially supported by the Spanish Government [grant number RTI2018-095255-B-I00 ] and the Madrid Research Council [grant number P2018/TCS-4314]

Agile approaches tend to focus solely on scoping and simplicity rather than on problem solving and discovery. This hampers the development of innovative solutions. Additionally, little has been said about how to capture and represent the real user needs. To fill this gap, some authors argue in favor of the application of “Creative thinking” for requirements elicitation within agile software development. This synergy between creativeness and agility has arisen as a new means of bringing innovation and flexibility to increasingly demanding software. The aim of the present study is therefore to employ a systematic review to investigate the state-of-the-art of those approaches that leverage creativity in requirements elicitation within Agile Software Development, as well as the benefits, limitations and strength of evidence of these approaches. The review was carried out by following the guidelines proposed by Dr. Kitchenham. The search strategy identified 1451 studies, 17 of which were eventually classified as primary studies. The selected studies contained 13 different and unique proposals. These approaches provide evidence that enhanced creativity in requirements elicitation can be successfully implemented in real software projects. We specifically observed that projects related to user interface development, such as those for mobile or web applications, are good candidates for the use of these approaches. We have also found that agile methodologies such as Scrum, Extreme Programming or methodologies based on rapid modelling are preferred when introducing creativity into requirements elicitation. Despite this being a new research field, there is a mixture of techniques, tools and processes that have already been and are currently being successfully tested in industry. Finally, we have found that, although creativity is an important ingredient with which to bring about innovation, it is not always sufficient to generate new requirements because this needs to be followed by user engagement and a specific context in which proper conditions, such as flexibility, time or resources, have to be met.

Present six strategies to overcome Continuous Delivery (CD) adoption challenges.Identify and elaborate eight further challenges for research.They are based on four years CD adoption experience at a multi-billion-euro company. Continuous Delivery (CD) is a relatively new software development approach. Companies that have adopted CD have reported significant benefits. Motivated by these benefits, many companies would like to adopt CD. However, adopting CD can be very challenging for a number of reasons, such as obtaining buy-in from a wide range of stakeholders whose goals may seemingly be different fromor even conflict withour own; gaining sustained support in a dynamic complex enterprise environment; maintaining an application development team's momentum when their application's migration to CD requires an additional strenuous effort over a long period of time; and so on. To help overcome the adoption challenges, I present six strategies: (1) selling CD as a painkiller; (2) establishing a dedicated team with multi-disciplinary members; (3) continuous delivery of continuous delivery; (4) starting with the easy but important applications; (5) visual CD pipeline skeleton; (6) expert drop. These strategies were derived from four years of experience in implementing CD at a multi-billion-euro company. Additionally, our experience led to the identification of eight further challenges for research. The information contributes toward building a body of knowledge for CD adoption.

Refactoring is recognized as an essential practice in the context of evolutionary and agile software development. Recognizing the importance of the practice, modern IDEs provide some support for low-level refactorings. A notable exception in the list of supported refactorings is the "Extract Class" refactoring, which is conceived to simplify large, complex, unwieldy and less cohesive classes.In this work, we describe a method and a tool, implemented as an Eclipse plugin, designed to fulfill exactly this need. Our method involves three steps: (a) recognition of Extract Class opportunities, (b) ranking of the identified opportunities in terms of the improvement each one is anticipated to bring about to the system design, and (c) fully automated application of the refactoring chosen by the developer. The first step relies on an agglomerative clustering algorithm, which identifies cohesive sets of class members within the system classes. The second step relies on the Entity Placement metric as a measure of design quality. Through a set of experiments we have shown that the tool is able to identify and extract new classes that developers recognize as "coherent concepts" and improve the design quality of the underlying system.

Systematic review on large-scale agile transformations analyzing 52 papers.We identify 35 reported challenges in 9 categories, and 29 success factors in 11 categories.Few academic studies (6), mostly experience reports (46) identified.Challenges e.g. difficulty of implementing, integrating other functions, and change resistance.Success factors e.g. choosing and tailoring, management support, and mindset. Agile methods have become an appealing alternative for companies striving to improve their performance, but the methods were originally designed for small and individual teams. This creates unique challenges when introducing agile at scale, when development teams must synchronize their activities, and there might be a need to interface with other organizational units. In this paper we present a systematic literature review on how agile methods and lean software development has been adopted at scale, focusing on reported challenges and success factors in the transformation. We conducted a systematic literature review of industrial large-scale agile transformations. Our keyword search found 1875 papers. We included 52 publications describing 42 industrial cases presenting the process of taking large-scale agile development into use. Almost 90% of the included papers were experience reports, indicating a lack of sound academic research on the topic. We identified 35 reported challenges grouped into nine categories, and 29 success factors, grouped into eleven categories. The most salient success factor categories were management support, choosing and customizing the agile model, training and coaching, and mindset and alignment.