Abstract
Architectural uncertainties arising from incomplete or unclear information pose significant challenges when making architectural decisions in Agile teams. Based on a limited number of case studies that employed a technique called ArchHypo, four patterns were identified that propose small adjustments in the development process to handle architectural uncertainties: Protective Guideline, Bring the Specialist, Plan for Preparation, and Quality Checkpoint. Although the patterns derived from these experiences can be useful in real projects, their applicability and consequences were based on limited evidence and specific scenarios. To address this issue, this paper presents an interview study with experienced software architects and engineers to gather further information on the application of these patterns. The research method employed semi-structured interviews to gather the experiences of professionals with the target practices, and thematic analysis was used to assess their recurrence, applicability, and consequences. The findings confirmed that most professionals recognized those practices in real projects and their suitability as actions in uncertainty management. Moreover, new positive and negative consequences, not previously documented in the patterns, were identified. As a result, this work contributes to the field by providing guidance to professionals on how to better evaluate the trade-offs of those patterns when applied to architecture uncertainty management.

Abstract

Abstract

Abstract
The research interest in software startups has expanded a lot in the last years as shown by the increase in the published papers, and the organization of research workshops. However, two recent systematic mapping studies recognize an inconsistency in the characterization of software startups in the literature, even though they acknowledge that innovativeness and uncertainty are the common themes the literature uses to describe these companies. In the new product development literature, even though not consolidated, innovativeness is usually related to technology and/or market discontinuities. These two different types of novelty could bring distinct consequences to software development activities in software startups. Using a case survey research approach, we analyzed 27 published papers from the period 2013-17. We identified and categorized the innovation in 18 software startups products or services from the perspective of discontinuities. We found that software engineering literature did not differentiate software startups based on the innovations they develop. Nevertheless, most studied software startups work on products with a market discontinuity and without a technological one.

Abstract

Abstract
The need of skills other than technical from software developers is becoming evident. The DevOps movement is an example of that applied to operational tasks. Startup development methodologies focus on business activities in innovative organizations. Several universities offer courses based on these methodologies to software engineering students, mainly to improve their creativity, problem solving, and business skills. This paper investigates how software engineering students learned startup development methodologies and discusses what are the challenges and benefits in their learning process. We conducted a multi-method study in three different universities. The data was collected in two phases and analyzed using thematic analysis. Our study reveals that students realized the importance of collaboration with other courses and the importance of user involvement in development. However, students tend to over-simplify concepts, trying to adapt them to what they are familiar with. The results indicate the necessity of business education for technical students and directions for improvements.