An agile process for modeling logical architectures: demonstration cases from large-scale software projects

Universidade do Minho Escola de Engenharia Nuno António de Lira Fernandes Faria dos Santos December 2020 An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects Nuno António de Lira Fernandes Faria dos Santos An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects UMinho|2020 December 2020 Work done under the guidance of Doctoral Program in Information Systems and Technology Universidade do Minho Escola de Engenharia Nuno António de Lira Fernandes Faria dos Santos An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects Prof. Dr. Ricardo J. Machado Dr. Nuno C. Ferreira Doctoral Thesis Universidade do Minho Escola de Engenharia ii DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ iii Acknowledgements To my wife Mónica, with her never-ending support and understanding of what this personal project meant to me - and its impact in our lives throughout these years. To my boy Duarte, as many times I was lifting him up when we were playing, he was the one actually lifting me up. To my brothers, Zeza and Tiago, for their unconditional support throughout my life. To my father António, who taught me the values from which I guide until today. To my mother Maria Fernanda, always on my mind pushing me towards my goals. To my supervisors, Prof. Dr. Ricardo J. Machado and Dr. Nuno Ferreira, for the advices. I started my career with them, for four years even before this adventure started. Thank you both for guiding me the way but letting me figure it out on my own, never closing me the paths I suggested. To my employers, CCG\ZGDV Institute, for providing me the conditions for doing what I love. To everybody involved within the EPMQ lab: IT Engineering Process, Maturity and Quality. To my Director, Ana Lima, for always supporting my research work. Specially, to Francisco Morais, Jaime Pereira, Prof. Dr. Helena Rodrigues, Dr. Carlos Salgado, Prof. Marcelo Noguera for the insightful discussions and debates during the research work and research projects we performed together. But also, a big appreciation to Isabel Varajão, Cláudia Amaro, Rui Costa, João Peixoto, and many, many others. Dedicated… To my beloved family. To my wife, Mónica. To my son, Duarte. To my brothers, Zeza and Tiago. To my father, António. In the loving memory of my mother, Maria Fernanda. iv STATEMENT OF INTEGRITY I hereby declare having conducted this academic work with integrity. I confirm that I have not used plagiarism or any form of undue use of information or falsification of results along the process leading to its elaboration. I further declare that I have fully acknowledged the Code of Ethical Conduct of the University of Minho. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects v Abstract Developing software solutions is about providing responses to a set of business needs in form of a working software. These business needs are the starting point for the development process, which states the required business support that the software will provide, in form of functional and nonfunctional requirements. Then, every implementation decision aims satisfying those requirements. Of course, over time, the requirements change. In that sense, agile software development (ASD) approaches bring a set of practices towards embracing those changes as soon as possible. As the complexity of software increases, namely in terms of the quantity of the defined features, these approaches face some challenges, typically related in properly defining how different teams have to work together in order to deliver a unified solution. In complex solutions, the traceability between business (or stakeholder) and software (components) perspectives may not be properly assured. Using a logical architecture provides a view that organizes software components in order to meet functional requirements. In a large-scale agile (LSA) setting, the logical architecture provides a view in how different teams’ outputs fit together. Thus, this thesis presents a process for modeling logical architectures adequate for ASD settings (a.k.a., “ Agile Modeling ” – AM) with requirements elicitation and modeling techniques and, additionally, uses an architectural design method called “ Four Step Rule Set ” (4SRS) in order to trace the requirements models to the architectural components. An AM process should support evolutionary design, preventing the so-called “ Big Design Up Front ” (BDUF) with eventual efforts that are afterwards disregarded in “ You Aren’t Going to Need It ” (YAGNI) elements. The proposed process is called “ Agile Modeling Process for Logical Architectures ” (AMPLA). This research work aimed defining how AMPLA covers the model evolution and abstraction level from business to service-oriented logical architectures in LSA settings. Additionally, adopting an architectural style called “microservices”, eases the agility in developing (and deploying) the solutions, where its design principles promote continuous integration/delivery (CI/CD) and DevOps. Thus, AMPLA includes architecture modeling as well as maintenance and evolution during ASD iterations. Keywords: agile software development, agile modeling, large-scale agile, logical architectures, microservices architecture Um Processo Ágil para Modelar Arquiteturas Lógicas: Casos de Demonstração de Projetos de Software de Larga-escala vi Resumo Desenvolver soluções de software é fornecer respostas a um conjunto de necessidades de negócios na forma de um software executável. Essas necessidades de negócios são o ponto de partida para o processo de desenvolvimento, que define como o software suportará o negócio, na forma de requisitos funcionais e não funcionais. Então, qualquer decisão de implementação visa satisfazer esses requisitos. Obviamente, com o tempo, os requisitos mudam. Nesse sentido, as abordagens de desenvolvimento ágil de software (ASD) trazem um conjunto de práticas para abraçar essas mudanças o mais rápido possível. À medida que a complexidade do software aumenta, principalmente em termos da quantidade de recursos definidos, essas abordagens enfrentam alguns desafios, geralmente relacionados à definição correta de como equipas diferentes devem trabalhar em conjunto para fornecer uma solução unificada. Em soluções complexas, a rastreabilidade entre as perspetivas do negócio (ou dos stakeholders ) e software (componentes) pode não estar adequadamente garantida. Usando uma arquitetura lógica, é fornecida uma visão que organiza os componentes de software para que os requisitos funcionais sejam suportados. Num contexto ágil de larga-escala (LSA), fornece uma visão de como os diferentes resultados se encaixam. Assim, esta tese apresenta um processo para modelar arquiteturas lógicas adequadas às configurações de ASD (também conhecido como “ Agile Modeling ” - AM), composto pelas técnicas de levantamento e modelação de requisitos e, adicionalmente, usa um método arquitetural chamado “ Four Step Rule Set ” (4SRS) para rastreabilidade entre os requisitos e os componentes arquiteturais. Um processo de AM deve oferecer suporte a uma conceção evolutiva, impedindo o chamado “ Big Design Up Front ” (BDUF), com eventuais esforços que serão posteriormente desconsiderados em elementos “ You Aren’t Going to Need It ” (YAGNI). O processo proposto é chamado de “ Agile Modeling Process for Logical Architectures ” (AMPLA). Este trabalho de investigação pretendeu definir como o AMPLA cobre a evolução dos modelos e nível de abstração desde o negócio até a arquiteturas lógicas orientadas a serviços em contextos de LSA. Além disso, a adoção de um estilo arquitetural chamado “micro-serviços” facilita a agilidade no desenvolvimento (e instalação) das soluções, onde suas bases da conceção promovem a integração / entrega contínua (CI / CD) e cultura DevOps. Assim, o AMPLA inclui modelação da arquitetura, bem como manutenção e evolução durante ciclos ágeis. Palavras-chave: ágil em larga escala, arquitetura de micro-serviços, arquiteturas lógicas, desenvolvimento ágil de software, modelação ágil. vii Table of Contents PART I - INTRODUCTION Chapter 1 - Introduction ............................................................................................................ 2 1.1 Motivations ................................................................................................................ 3 1.2 Key definitions ........................................................................................................... 7 1.3 Core Concepts and Definitions ................................................................................... 7 1.4 Research question and objectives ............................................................................ 10 1.5 Research method .................................................................................................... 13 1.6 Document Structure ................................................................................................ 20 References ......................................................................................................................... 22 PART II - STATE OF THE ART Chapter 2 - Requirements and Architecture Design in LSA ....................................................... 28 2.1 Introduction ............................................................................................................. 29 2.2 Views on Debating Architectures and Agile ............................................................... 31 2.3 Using Architecture Approaches within Agile Software Development ........................... 35 2.4 Large-scale Agile Development (LSA) ....................................................................... 46 2.5 Conclusions ............................................................................................................ 65 References ......................................................................................................................... 67 Chapter 3 - Logical Architectures within Agile and “Continuous” Approaches ........................... 75 3.1. Introduction ............................................................................................................. 76 3.2. Architecture lifecycle and viewpoints ........................................................................ 79 3.3. Modeling approaches within the “continuous” paradigm .......................................... 92 3.4. Microservices architectures ................................................................................... 102 3.5. Conclusions .......................................................................................................... 116 References ....................................................................................................................... 117 PART III - CONTRIBUTIONS Chapter 4 - A Requirements Modeling Approach for Agile Settings ......................................... 132 xiv Figure 32. Classification schema............................................................................................. 85 Figure 33. Viewpoints classifications at Level 1........................................................................ 87 Figure 34. Viewpoints classifications at Level 2........................................................................ 89 Figure 35. Viewpoints classifications at Level 3........................................................................ 90 Figure 36. Viewpoints classifications at Level 4........................................................................ 91 Figure 37. "Stairway to Heaven" (Helena Holmstrom Olsson et al., 2012; Helena Holmström Olsson & Bosch, 2014) ........................................................................................................... 92 Figure 38. Continuous* framework (Fitzgerald & Stol, 2017) ................................................... 95 Figure 39. The Continuous Architecting Framework For Embedded software and Agile (CAFFEA) (Martini et al., 2015) ............................................................................................................... 99 Figure 40. Types of Technical debt (Kruchten, Nord, & Ozkaya, 2012) ................................... 101 Figure 41. A pictorical representation of a microservices architecture .................................... 102 Figure 42. Microservices main characteristics ....................................................................... 103 Figure 43. Positioning the microservices tenets (Zimmermann, 2017) ................................... 107 Figure 44. UML profile for microservices design (Rademacher, Sachweh, & Zündorf, 2018b) . 109 Figure 45. Use Case Model for identification of service candidates (Kharbuja, 2016) ............ 110 Figure 46. DDD patterns for domain-driven microservice design (Rademacher, Sorgalla, & Sachweh, 2018) ................................................................................................................... 111 Figure 47. Microservices architecture patterns ...................................................................... 114 Figure 48. Integrated modeling roadmap ............................................................................... 134 Figure 49. Overview of AMPLA .............................................................................................. 135 Figure 50. Hybrid ASD process with upfront requirements modeling ...................................... 136 Figure 51. SPEM diagram for Initialization phase ................................................................... 138 Figure 52. Example of a Sprint Backlog based in Use Cases .................................................. 138 Figure 53. The result of the V-Model to be delivered to multiple Scrum teams ........................ 140 Figure 54. Architecture modularization example .................................................................... 140 Figure 55. Relation between Use Cases, Components and User Stories ................................. 141 Figure 56. Candidate architecture design of AMPLA .............................................................. 143 Figure 57. Overview of DUARTE approach ............................................................................. 145 Figure 58. Discovery and exploration of the scenarios ............................................................ 147 Figure 59. Use Case diagram of iFloW project ....................................................................... 152 Figure 60. Example of a Sprint Backlog based in Use Cases .................................................. 153 xv Figure 61. ISOFIN Use Case Model ....................................................................................... 155 Figure 62. ISOFIN Logical Architecture .................................................................................. 156 Figure 63. ISOFIN architecture modularization ...................................................................... 157 Figure 64. User Story from 2.1.4.c ........................................................................................ 159 Figure 65 . Subset of project initial expectations .................................................................... 160 Figure 66. Scenarios elicited ................................................................................................. 161 Figure 67. UH4SP first-level Use Cases ................................................................................. 161 Figure 68. Overview of AMPLA .............................................................................................. 174 Figure 69. Integrated modeling roadmap ............................................................................... 174 Figure 70. Steps proposal for agile architecting ..................................................................... 180 Figure 71. Classification of Candidate and Refined logical architectures ................................. 181 Figure 72. Architectural views and abstraction within AAL phases .......................................... 182 Figure 73. Method for designing the candidate architecture with 4SRS .................................. 184 Figure 74. 4SRS method execution using tabular transformations .......................................... 185 Figure 75. Simple example of a candidate UML components architecture .............................. 186 Figure 76. Recursive execution of 4SRS for refining a given example module ......................... 187 Figure 77. Distributed implementation of each architecture module ....................................... 188 Figure 78. Incremental requirements and 4SRS execution throughout the Sprints .................. 189 Figure 79. Parallel tasks within Sprints in SPEM diagram ...................................................... 189 Figure 80. Traceability between models and product backlog ................................................. 190 Figure 81. AMPLA during Sprints .......................................................................................... 191 Figure 82. The performed disciplines within the Sprints ......................................................... 191 Figure 83. Parallel traceability within Sprints using the 4SRS ................................................. 192 Figure 84. Possible targets of CIA within AMPLA .................................................................... 193 Figure 85. CA-related practices within “Analysis & Design” discipline ..................................... 195 Figure 86. Inferring Domain's and sub-domain's bounded contexts from UML Use Cases ....... 196 Figure 87. Architecture modularization example .................................................................... 198 Figure 88. Recursive architectural model transformations for service design .......................... 199 Figure 89. Dependency between different teams ................................................................... 200 Figure 90. Specifying microservices using 4SRS-MSLA .......................................................... 200 Figure 91. Participant with ports, interfaces and capabilities (methods/properties)................. 203 Figure 92. Defining associations between components .......................................................... 204 xvi Figure 93. Service Architecture ............................................................................................. 205 Figure 94. Service Interface .................................................................................................. 206 Figure 95. The performed disciplines within the Sprints ......................................................... 208 Figure 96. The performed disciplines within the architectural spike Sprint .............................. 208 Figure 97. UH4SP information systems architecture .............................................................. 210 Figure 98. UH4SP logical architecture derived after 4SRS execution ...................................... 211 Figure 99. The modularization of the logical architecture ....................................................... 212 Figure 100. UH4SP sub-system ............................................................................................ 213 Figure 101. Refined use cases resulting from the model transformation................................. 214 Figure 102. Participant with ports, interfaces and capabilities (methods/properties) .............. 215 Figure 103. Service Architecture ........................................................................................... 215 Figure 104. Service Interface ................................................................................................ 216 Figure 105. UH4SP deployment diagram .............................................................................. 217 Figure 106. Use Case model of IMP_4.0 project ................................................................... 220 Figure 107. use case refinement of {UC1} Stocks .................................................................. 221 Figure 108. IMP_4.0 MSLA overview (with collapsed components) ........................................ 222 Figure 109. The IMP_4.0 Stocks microservice ...................................................................... 222 Figure 110. IMSPM Use cases diagram ................................................................................. 223 Figure 111. IMSPM Sequence diagram ................................................................................. 224 Figure 112. 4SRS method execution within ISMPM project .................................................... 224 Figure 113. IMSPM MSLA model .......................................................................................... 225 Figure 114. IMSPM Deployment diagram .............................................................................. 226 Figure 115. Spots representation of the ISMPM MSLA model ................................................ 227 Figure 116. Logical architecture-based distributed agile teams management framework ........ 245 Figure 117. Decision framework within Modularization .......................................................... 246 Figure 118. Domain's and sub-domain's bounded contexts (DDD) ......................................... 246 Figure 119. Architecture modularization example .................................................................. 248 Figure 120. The module representation................................................................................. 249 Figure 121. Requirements communication theory ................................................................. 250 Figure 122. W2ReqComm example ....................................................................................... 251 Figure 123. Inter-team management theory .......................................................................... 252 Figure 124. SPEM diagram for Initialization phase ................................................................. 254 xvii Figure 125. Approach for delivering backlog items requirements ........................................... 255 Figure 126.Relation between Use Cases, Components and User Stories ................................ 256 Figure 127. Agile requirements meda-model (Leffingwell, 2010) ............................................ 261 Figure 128. Rule for deriving Themes .................................................................................... 261 Figure 129. Rule for deriving Epics ........................................................................................ 262 Figure 130. Rule for deriving User Stories ............................................................................. 263 Figure 131. Rule for deriving user story details ...................................................................... 264 Figure 132. Rule for deriving Acceptance Criteria .................................................................. 264 Figure 133. Use Case diagram of the iFloW project ............................................................... 268 Figure 134. A Sprint Backlog based in Use Cases from the iFloW project ............................... 269 Figure 135. The result of the V-Model to be delivered to multiple Scrum teams ...................... 270 Figure 136. ISOFIN architecture modularization .................................................................... 271 Figure 137. W2ReqComm for IBS Management module ........................................................ 272 Figure 138. User Story from 2.1.4.c ...................................................................................... 274 Figure 139. Structure of UH4SP teams ................................................................................. 276 Figure 140. UH4SP logical architecture modularization ......................................................... 277 Figure 141. W2ReqComm package for "Access company data" scenario ............................... 280 Figure 142. An example scenario including inter-team management ...................................... 281 Figure 143. Evolution of AC, PV and EV ................................................................................. 285 Figure 144. EVM monitoring ................................................................................................. 286 Figure 145. Sprint #3 burndown and team velocity measurement ......................................... 286 Figure 146. Cumulative flow ................................................................................................. 287 xviii List of Tables Table 1. Characteristics of agile methodologies (Cho, 2009) ...................................................... 9 Table 2. Research challenges‘ priority at XP’s scientific workhops on LSA ................................ 47 Table 3. Applicability of the reviewed approaches .................................................................... 66 Table 4. Architecture-based activities within a SDLC (Kazman et al., 2003) .............................. 81 Table 5. Use of architecture-centric methods within a SDLC (Kazman et al., 2003) .................. 82 Table 6. A comparison of enterprise architecture frameworks (Urbaczewski & Mrdalj, 2006) .... 82 Table 7. Architecture viewpoints categories ............................................................................. 86 Table 8. Comparison and likeness of architecture viewpoints ................................................... 86 Table 9. Microservices characteristics and principles (Zimmermann, 2017) ........................... 105 Table 10. Microservices patterns and categories ................................................................... 115 Table 11. Microservices migration patterns (Armin Balalaie et al., 2016a) ............................. 116 Table 12. List of microservices bad smells (Davide Taibi & Lenarduzzi, 2018) ....................... 116 Table 13. Contributions of projects in candidate architectures ............................................... 135 Table 14. Traceability matrix of requirements within the initial expectations ........................... 150 Table 15. Traceability matrix of requirements within the identified project stakeholders and solution actors ...................................................................................................................... 150 Table 16. User Stories derived from c-type components ........................................................ 158 Table 17. Contribution of projects in continuous architecting ................................................. 177 Table 18. Comparison of agile architecting approaches and their contextualization within the architecting lifecycle ............................................................................................................. 179 Table 19. The inputs and outputs of AAL artefacts ................................................................. 182 Table 20. List of CIA practices and their targeted models ...................................................... 194 Table 21. Transition from UML (within AMPLA) to SoaML ...................................................... 202 Table 22. Deployment setting for UH4SP .............................................................................. 218 Table 23. Deployment setting for IMSPM ............................................................................... 226 Table 24. Contributions of projects in candidate architectures ............................................... 244 Table 25. User story card template ....................................................................................... 258 Table 26. Checklist DoR for a User Story ............................................................................... 265 Table 27. Mapping between iFloW roles and typical Scrum roles ............................................ 267 Table 28. User Story card for "Test IBS Before Deployment" ................................................. 273 Table 29. User Stories derived from c-type components ........................................................ 274 xix Table 30. Analysis on the product backlog............................................................................. 278 Table 31. Analysis on the Team B backlog ............................................................................ 278 Table 32. A subset of the team backlog ................................................................................. 278 Table 33. Traceability between use cases / user stories and the components from the 4SRS . 279 Table 34. Analysis on Team B Sprints ................................................................................... 279 Table 35. Coordination arenas .............................................................................................. 282 Table 36. Agile metrics ......................................................................................................... 283 Table 37. EVM controlling ..................................................................................................... 285 Table 38. Feature's contributions to project's objectives ........................................................ 288 Table 39. Cumulative value of BVD ....................................................................................... 289 Table 40. Lead Time, Processing Time, Queue Time ............................................................. 290 Table 41. Work in Progress ................................................................................................... 290 Table 42. Demonstration case's contributions towards the research objectives ...................... 312 Table 43. Demonstration case's inputs towards the research contributions ............................ 316 Table 44. Published paper's relation with demonstration case and research contribution ....... 324 Table 45 - iFloW Backlog list ................................................................................................. 334 Table 46. User Stories for c-types from ISOFIN App Management module .............................. 341 Table 47. User Stories for d-types from ISOFIN App Management module ............................. 342 Table 48. User Stories for i-types from ISOFIN App Management module ............................... 342 1 PART I INTRODUCTION Chapter 1 - Introduction 2 Chapter 1 - Introduction Chapter 1 – Introduction……………………………………………………………………..3 1.1 Motivations………………………………………………………………3 1.2 Key definitions…………………………………………………………...7 1.3 Core Concepts and Definitions…………………………………………..7 Software Architectures………………………………………………...7 Agile Software Development (ASD)………………………………….8 Large-scale Agile Development……………………………………….9 1.4 Research question and objectives……………………………………….10 1.5 Research method………………………………………………………...13 The demonstration cases……………….……....……………..……….17 1.6 Document Structure………………………………………………………..20 References………………………………………………………………………...22 This chapter introduces the topic of the presented research for a proper understanding of this research. It describes the motivations for this thesis, the research question and objectives towards answering the question, and finally the research method. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 3 Chapter 1 - Introduction “ A problem well stated is a problem half solved. ” Charles F. Kettering, inventor, engineer, businessman 1.1 Motivations Software architecture design, when performed in context of agile software development (ASD), sometimes referred as “agile architecting”, promotes the emerging and incremental design of the architectural artifact, in a sense of avoiding “big design upfront” (BDUF). Performing “agile architecting” is not always straightforward, mainly because the architecture has a required life cycle and each stage responds to different needs. There is a lack of a roadmap that guides agile architecting in an end-to-end approach (from business requirements to deployment). The role of architecture and architects have been changing due to the adoption of agile software development (ASD) approaches. Although an initial misconception because popular ASD frameworks (Scrum, XP, Kanban, DSDM) did not explicitly include architectural artifacts or roles, this role has been emerging towards a balanced design and implementation as the architecture emerges throughout the process. The architect plays a role in upfront planning, storyboarding and backlogs, Sprints and working software stages of a project (Madison, 2010). More recently, agile scaling frameworks , like Disciplined Agile Delivery (DAD) (Scott Ambler & Lines, 2012), Large-Scale Scrum (LeSS) (Larman & Vodde, 2016), Scaled Agile Framework (SAFe) (Leffingwell, 2016), Scrum@Scale (Sutherland, 2018) and Nexus (K Schwaber, 2015), have been adopted in industry. The architect’s role have been specified by actively and passively support agile teams by driving architectural initiatives, participating in architectural runways, harmonizing governance requirements, and ensuring technical alignment in solution contexts (Uludag, Kleehaus, Xu, & Matthes, 2017). The plethora of agile practices relate to management (e.g., Sprints, Scrum ceremonies), development (e.g., pair programming, TDD, BDD, DevOps) or strategy (e.g., Lean Startup), but lack a comprehensive description on how its adoption influences requirements modeling. Agile software development (ASD) is currently the worldwide-adopted approach in software engineering. The mashup of agile practices and industry coins (e.g., Scrum, XP, MVP, DevOps, large-scale agile, Squads/Tribes, Management 3.0, and many others) cover all software and application lifecycle. Although none of this Chapter 1 - Introduction 4 practices relate to requirements engineering (RE) discipline, or specifically to Agile modeling (AM) (S Ambler, 2002), performing this practices into an ASD process has direct implications on how RE practices are performed and how artifacts are built. Stakeholders are crucial participants for eliciting requirements towards a new software solution. However, agreeing a common understanding among them is a complex task in a project’s initial phase when solution requirements and design need to be refined and/or are unknown. Companies often strive to properly perform requirements engineering (RE) tasks in software solutions for complex ecosystems (mainly those related to the emergence of new paradigms like Cloud Computing and more recently Industry 4.0, Internet of Things (IoT), machine-to-machine, cyber-physical systems, etc.). The elicitation for the required functionalities regarding the adoption of these recent technologies typically ends up without consensus when technical decisions are required. This trend does not have yet mature references and standards that companies may blindly follow, so the product development results in refactoring efforts towards new architectural patterns. Stakeholders must able to communicate in what way a future solution improves their business, by defining the product roadmap. A product roadmap is an initial high level project scope and direction (IIBA, 2017). Typically, a first release on a new product encompasses a product’s subset able to address priority scenarios, previously identified in order to respond to market needs. In fact, many of these product releases are market-driven, where the release is deployed into the market so it is possible to get feedback from it, i.e. , a minimum viable product (MVP). In plan-driven approaches (e.g., Waterfall), tasks related to RE discipline are traditionally managed in a phase separated in time from design and development. In change-driven approaches, like ASD, RE discipline – also called “ Agile RE ” – activities remain the same but are executed continuously (Grau & Lauenroth, 2014), and takes an iterative discovery approach (Cao & Ramesh, 2008). Elicitation, analysis, and validation are present in all ASD processes (Paetsch, Eberlein, & Maurer, 2003). ASD widely use User Stories (Cohn, 2004) as items in the backlog for “reminders of a conversation” about a functionality. However, using only User Stories, without attached requirements specifications or models, may be insufficient to assure a common understanding, or, in case of multi-teams, to clearly define inter-systems interactions. Additionally, requirements modeling should prevent unnecessary efforts in “ You Aren’t Gonna Need It ” (YAGNI) features, hence the need for an Agile Modeling (AM) (S Ambler, 2002) approach. Applying AM should start by enabling a first iteration of requirements modeling, which is then the basis for further refinements, and later support discovery when they emerges, as the software An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 11 The 4SRS method allows deriving logical architectures aligned with the corresponding, and previously elicited and modeled, user requirements. In this PhD thesis, the 4SRS method will be adapted for adopting logical architectures in a typical software agile development. The conventional version of the 4SRS method is typically applied in large-scale projects, but demands high quantity of information (use cases, textual descriptions), which is often time consuming and, in every way, misaligned with the general paradigm adopted by ASD approaches (“ Working software over comprehensive documentation ”). Within this software development phase, some existing knowledge and concepts are considered, namely:  The architecture should emerge gradually Sprint after Sprint, as a result of successive small refactoring (Abrahamsson et al., 2010);  Performing lightweight amount of effort in up-front design, by using, for instance, a “predefined architecture” (Waterman et al., 2012), walking skeleton (Farhan, Tauseef, & Fahiem, 2009) and simple artifacts (informal box-and-line diagrams, descriptions of a system metaphor, a succinct document capturing the relevant decisions, etc.) (Erdogmus, 2009). This way, the architecture is able to handle all the known “big rocks”, i.e., requirements that are particularly hard to incorporate late in the project (Cockburn, 2006) and used as a starting point for the generation of User Stories to be incorporated in the Backlog artifact. O2: To adopt flexibility and agility mechanisms in the refinement of logical architectures throughout the iterations of ASD teams. The adoption of a logical architecture implies that it is used as a complementary approach to agile in the development life cycle (Madison, 2010). This objective relies in adding the 4SRS method with mechanisms to refine the requirements from pregame phase (addressed in O1) but also to respond to changes during the ASD iterations. This research will aim in using the 4SRS to trace every decision made during the development (“game” phase), from the stated user requirements (in O1) to the delivered software. Considering that changes in requirements are frequent (and embraced) in agile environments, the resulting artifact from the previous objective must imperatively be able to respond to those changes without losing information and not being subjected to unnecessary refactoring efforts. A research opportunity arises, where some existing knowledge and concepts will be taken in consideration, namely: Chapter 1 - Introduction 12  Assessing the impact of changes in features within the architecture (Díaz, Pérez, & Garbajosa, 2014) as well as evaluating the architecture at the end of every cycle (Kanwal, Junaid, & Fahiem, 2010);  As the requirements are being developed and refined, the architect should identify architecturally significant requirements (ASR), feature- (or functionally-) oriented requirements, and the dependencies between them to ensure the necessary elements from the architecture are present in upcoming iterations (Nord, Ozkaya, & Kruchten, 2014);  It is, thus, required to provide the logical architecture with agility (that, for Farhan et al. , relates to evaluate, discuss and correct quickly the architecture (Farhan et al., 2009)) during the small cycles of the process. The outputs from this research objective may be used in contexts where: substantial changes to the software architecture need to be explored (Farhan et al., 2009); given a change in features (adding, deleting or updating), it is possible to trace the changes to the stated requirements and assess the changes to the architecture (Díaz et al., 2014); “small rocks” (in opposition to the “big rocks” stated within the previous research objective) are handled as they appear during the project (Cockburn, 2006). O3: To develop an approach oriented for continuous architecting, aiming to specify microservices logical architectures (MSLA), identifying them and their interfaces. Use domain-driven design for requirements engineering where, included in the proposed agile modeling logical architecture, uses the 4SRS method is used for proposing MSLA in:  Projects for breaking monoliths to microservices;  Greenfield projects of microservices-based solutions. O4: To use logical architectures to manage a team assignment and orchestration process Research regarding the use of a logical architecture artefact as a supporting basis for an LSA project that includes:  a modelling approach for identification of concerns within the architecture;  a set of issues for validating subsystems size;  a format to communicate subsystems specifications to teams;  steps for delivering dependencies, priorities, of subsystems to agile distributed teams. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 13 Additionally, for this research objective to be fulfilled, the method must be able to be used in a typical ASD and in contexts of LSA projects. For scope definition of the work, LSA is characterized by having more than one team, when the number of team members is larger than the typically suggested limit (7 or 8 elements), or when large quantities of user stories (or requirements) or lines of code are required. For both contexts (but especially in LSA projects), some existing knowledge and concepts will be taken in consideration, among them: prioritizing requirements and depicting dependencies between features; coordinating and synchronizing distributed teams (Dingsøyr & Moe, 2014). 1.5 Research method Within the research objectives, it is clear that the way to fulfill them is by designing a method that is able to derive logical architectures with the desired capabilities as the ones stated previously. In order to fulfill the research objectives, this PhD thesis is structured according the Design Science Research (DSR) methodology. The decision on using DSR relies mainly in the fact that the focus is to develop an artifact, namely an agile modeling process. The artifact is developed under the execution in demonstration cases. Due to the fact that these demonstration cases occur in different organizations and environments, this thesis uses DSR instead of, for instance, Action Research (Baskerville & WoodHarper, 1998; Coughlan & Coghlan, 2002) or Design Action Research (Sein, Henfridsson, Purao, Rossi, & Lindgren, 2011). In this section, the DSR method is overviewed and the research process to be conducted in the PhD thesis is described. DSR addresses important unsolved problems in unique or innovative ways or solved problems in more effective or efficient ways. The key differentiator between routine design and design research is the clear identification of a contribution to the archival knowledge base of foundations and methodologies. The design-science paradigm seeks to extend the boundaries of human and organizational capabilities by creating new and innovative artifacts (Hevner, March, Park, & Ram, 2004), a body of knowledge about the design of artificial objects and phenomena ( i.e. , artifacts) designed to meet certain desired goals (Simon, 1996). It seeks to create innovations that define the ideas, practices, technical capabilities, and products (Denning, 1997) through which the analysis, design, implementation, management, and use of information systems can be effectively and efficiently accomplished. Chapter 1 - Introduction 14 This PhD thesis structures its phases using the proposal from Kuechler and Vaishnavi (Kuechler & Vaishnavi, 2008), as depicted in Figure 1. This proposal begins with the Awareness of a Problem, and then a solution is created, drawn abductively from existing knowledge. The rigor of DSR is derived from the effective use of prior research (existing knowledge base). Solution and respective Artifacts are evaluated through metrics that instantiate the research goals. These steps are repeated until a satisfactory solution to problem is found. Figure 1. Design Science Research Cycle (Kuechler & Vaishnavi, 2008) The performed research strategies throughout the research process will be as follows: 1) Awareness of Problem Some literature review on the topics under the PhD thesis provides the foundations that are required to define the theory development (Webster & Watson, 2002) on agile, architectures, and agile architecting. This phase intents to analyze the existing knowledge and to identify a research opportunity that is not addressed by the analyzed literature. 2) Suggestion The proposal of hypothesis is built based in the identification of the research opportunity. This hypothesis is formalized in four research objectives that together answer the research question. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 15 3) Development By performing demonstration cases, the proposed method and process are applied in R&D funded research projects conducted within CCG\ZGDV institute. These projects are conducted with ASD teams, but in different organizations and contexts. It is thus necessary to identify for which research objectives each demonstration case will have contributions. 4) Evaluation The evaluation used demonstration cases, aiming to experiment and evaluate of the method applicability (Yin, 2014). Kitchenham proposes steps for conducting a demonstration case, namely Context, Setting the Hypothesis, Planning, Validating and Analyzing the Results (Kitchenham, Pickard, & Pfleeger, 1995). For the purpose of the PhD thesis, five demonstration cases were performed within contexts of R&D funded research projects conducted within CCG\ZGDV institute, each one with specific contributes within the thesis. 5) Conclusion The demonstration case’s contribution is added to the research objective (O1, O2, O3, O4 or all). Until all four objectives are validated, the research process is conducted by new DSR cycles. Additionally, work publications relating to the main findings are prepared for submission to journals and conferences. Every doctoral work intends to develop a new theory, however its research should (or must) be based in a supporting research theory. Design theory (DT) is about having in consideration the analysis and evaluation of design within research (Larsen, Allen, Vance, & Eargle, 2015). Within the case of IS research, DT focus on the design of IT artifacts. These artifacts are broadly defined as constructs (vocabulary and symbols), models (abstractions and representations), methods (algorithms and practices), and instantiations (implemented and prototype systems) (Hevner et al., 2004). It describes the world as acted upon (processes) and the world as sensed (artifacts) (Hevner et al., 2004). From the author’s point of view, DT is the theory in which the designed artifacts are the basis. Hevner et al. defined a framework for understanding, executing, and evaluating IS research, combining behavioral-science and design-science paradigms. It is composed by three spaces - environment, knowledge base and IS research – and is structured as represented in Figure 2. Chapter 1 - Introduction 16 Figure 2. Design Theory for IS research (from (Hevner et al., 2004)) The environment defines the problem space in which reside the phenomena of interest. For IS research, it is composed of people, (business) organizations, and their existing or planned technologies. Together these define the business need or problem as perceived by the researcher (Hevner et al., 2004; Silver, Markus, & Beath, 1995; Simon, 1996). Framing research activities to address business needs assures research relevance. Given such an articulated business need, IS research is conducted in two complementary phases. Behavioral science addresses research through the development and justification of theories that explain or predict phenomena related to the identified business need. Design science addresses research through the building and evaluation of artifacts designed to meet the identified business need. The knowledge base provides the raw materials from and through which IS research is accomplished. It is composed of foundations and methodologies. Additionally, uses reference disciplines provide foundational theories, frameworks, instruments, constructs, models, methods, and instantiations used from prior IS research and results in the develop/build phase of a research study; and methodologies provide guidelines used in the justify/evaluate phase. Rigor is achieved by appropriately applying existing foundations and methodologies. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 17 Regarding the use of DT, this thesis focus in developing an IT artifact, namely an agile architecting method, i.e., a method for logical architectures that fulfills requirements for use within agile projects. Agile teams are the surrounding environment of this thesis. Teams, their process and the development artifacts have faced some critics when in large-scale contexts. These issues regard the business need for this thesis’ underdevelopment DT. As for assuring rigor, this thesis uses, for a knowledge base: (1) frameworks that propose emerging architecture design - like Abrahamsson et al., Waterman et al. or Farhan et al. (Abrahamsson et al., 2010; Farhan et al., 2009; Waterman et al., 2012); (2) as well as architectural design tasks within agile iterations – like Jeon et al., Díaz et al . or Kanwal et al. (Díaz et al., 2014; Jeon et al., 2011; Kanwal et al., 2010); (3) models related to the logical architecture artifacts; (4) constructs for the 4SRS method execution; and (5) methods - namely the Design Science Research – that enable organizing the study. All these concepts allow developing a rigorous research. Upon these concepts, the hypothesis about use of the 4SRS in an emerging, iterative and continuous approach is constructed, ultimately resulting in a research question and its research objectives. The assessment of the hypothesis will be based upon the performance of demonstration cases. After the execution of demonstration cases, that result as well in refinements of the hypothesis, later assessed in further demonstrated cases. As an output, the developed artifacts are applied in the environment where the business need arose, as well as the new theory is scientifically validated and able to be added to the knowledge base. The demonstration cases In this thesis, the research projects were used as demonstration cases, separately, within the scope of DSR cycles. Each project had a clearly defined input for the research. The ISOFIN Cloud (Interoperability in Financial Software) project ISOFIN Cloud is a Portuguese funded project in co-promotion (QREN 2010/013837, under Fundos FEDER through Programa Operacional Fatores de Competitividade – COMPETE and Fundos Nacionais through FCT – Fundação para a Ciência e Tecnologia, FCOMP-01-0124-FEDER-022674). This project is executed in a consortium comprising eight entities (private companies, public research centers and universities), namely CCG\ZGDV Institute, i2S Insurance Knowledge, University of Minho, Faculty of Chapter 1 - Introduction 18 Sciences and Technology (FCT NOVA) of Lisbon, Maisis - Information Systems, Knowledgebiz, and IZone Knowledge Systems. This project aimed to deliver a set of coordinating services in a centralized infrastructure, enacting the coordination of independent services relying on separate infrastructures. The ISOFIN platform supports the semantic and application interoperability between enrolled financial institutions (Banks, Insurance Companies and others). The cloud solution is able to be deployed in an Infrastructure-as-aService (IaaS) layer. That layer will support the execution of a set of services that will allow suppliers to specify the behavior of the services they intend on supplying, in a Platform-as-a-Service (PaaS) layer. This will allow customers, or third-parties, to use the platform’s services, in a Software-as-a-Service (SaaS) layer and billed accordingly. The project included a set of 52 deliverables. This thesis used the following project deliverables: - M/D207 – ISOFIN Logical Architecture; - M/D210 – Financial Domain Applications/Services Specifications The iFloW (Inbound Logistics Tracking System) project The iFloW project is an R&D project that is part of a consortium program, called Human-Machine Interface Excellence (HMIExcel), between University of Minho and Bosch Car Multimedia Portugal, sponsored in co-promotion nº 36265/2013 (Project HMIExcel - 2013-2015). iFloW is an R&D project that aims at developing an integrated logistics software system for inbound supply chain traceability. iFloW is a real-time tracking software system of freights in transit from the suppliers to the Bosch plant, located in Braga. The main goal of the project is to develop a tracking platform that allows to control the raw material flow from remote (Asian) and local (European) suppliers to the Bosch’s warehouse, alerts users in case of any deviation to the Estimated Time of Arrival (ETA) and anticipates deviations of the delivery time window. The iFloW project, as its name refers, relates to logistics domain, and was mainly focused in integration with third party logistics (3PL) service providers and integrating Radio Frequency Identification (RFID) technology, Global Positioning System (GPS) technologies, and an integrated webbased RFIDElectronic Product Code (EPC) compliant logistics information system. The project included a set of four deliverables. This thesis used the following project deliverables: - D4.4.2 - Specification of the model for experimental development; - D5.3.8 – development of functionalities - D6.7.9 – verification and validation of functionalities developed An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 19 The IMP_4.0 (Integrated Management Platform 4.0) project The IMP_4.0 platform (POCI-01-0247-FEDER-009147, under Portuguese National Grants Program for R&D projects P2020 – SI IDT) enables a software-house, F3M – Information Systems, SA , located in Braga, Portugal, to optimize the development process of delivering solutions to their customers with tools to support all their decision-making processes. The solution is based on public and private clouds, which are interoperable with devices in an IoT and Cyber-Physical Systems (CPS) approach. The IMP_4.0 project is about an ERP system for the textile production domain, where the focus is to support milling, weaving and clothing processes, by providing a set of reusable and integrated software modules. Additionally, the platform’s development includes establishment of generic modules and variability management for enabling its extension to textile, footwear, cutlery, metal-mechanic, glassware and other sectors. The research is conducted within an F3M’s software team. The team was composed by one Product Manager that owned the business vision, four software architects, four analysts that modeled requirements and architecture design, and two development teams responsible for implementing the resulting architecture. The architects and analysts also performed the measurements within this research. The project included a set of 36 deliverables. This thesis used the following project deliverables: - D.1.4 – Functional requirements specifications – initial version; - D.1.5 – Functional requirements specifications – final version; - D1.8 – Traceability mechanisms for production management; - D1.9 – IMP_4.0 logical architecture – initial version; - D1.10 – IMP_4.0 logical architecture – final version; - D1.11 – IMP_4.0 platform services specification. The UH4SP (Unified Hub for Smart Plants) project UH4SP is a Portuguese funded project in co-promotion (Project ID 017871, under Portuguese National Grants Program for R&D projects P2020 – SI IDT, and under COMPETE: POCI-01-0145FEDER-007043). The UH4SP project aims developing a platform for integrating data from distributed industrial unit plants, allowing the use of the production data between plants, suppliers, forwarders and clients. The consortium was composed with five different entities for software development where each had specific expected contributes, from cloud architectures to industrial software services and mobile applications. The solution is based in the Industry 4.0 paradigm, and IoT and cloud computing technologies. The entities are geographically distributed, but each entity had a single located team. Chapter 1 - Introduction 20 The project included a set of 50 deliverables. This thesis used the following project deliverables: - D.3.1 – Functional and Technical Requirements Specification; - D.3.2 – Technical and logical architecture; - D3.3 – Service Specification For Material Reception And Shipment; - D3.5 – Interoperability Between Platform And Services Requirements; - D3.7 – Solution modelling; - D4.1.1 – UH4SP Management Platform – Initial Version; - D4.1.2 – UH4SP Management Platform – Final Version; - D5.4 - Integration Services and Platform. The Internal Management System of Project Management (IMSPM) project In this case, the IMSPM is not a funded R&D project, but rather an internal project for i2S. This project is an initiative from i2S for refactoring an existing platform for their internal project management procedures, migrating it from a monolith system to a microservices architecture system. Because it is an internal project, the existing documentation for this project is private. The only available documentation is in form of an MSc thesis, whose work was associated with this PhD thesis. This MSc thesis can be found in: Amaral, José Diogo Coelho, “The evolution of monolithic architectures to microservice-based architectures” (free translation of “ A evolução das arquiteturas monolíticas para as arquiteturas baseadas em microserviços ”), ISEP - DM – Engenharia Informática 1 . If some projects were used in same DSR cycles as complimentary validation with each other, other were used to validate as alternative approaches. Finally, some cases were used for specific stages of AMPLA, for instance UH4SP was used for entire AMPLA process. Throughout the thesis, the UH4SP is described as the main demonstration case in the contributions. Whenever it is justifiable, whether complimentary or alternative, the inputs from the remaining demonstration cases are described in the respective sections. 1.6 Document Structure This document is structured in four parts: Part I – Introduction, refers to Awareness of the Problem phase of the DSR, as well as the stating the Business Need of the DT; Part II – State of the 1 Available at: http://hdl.handle.net/10400.22/11920 27 PART II STATE OF THE ART Chapter 2 – Requirements and Architecture Design in LSA 28 Chapter 2 - Requirements and Architecture Design in LSA Chapter 2 - Requirements and Architecture Design in LSA …………………………...29 2.1 Introduction……………………………………………………………. 29 2.2 Views on Debating Architectures and Agile……………………………31 2.3 Using Architecture Approaches within Agile Software Development…35 Software Architecture Methods within Initialization…………..........38 Software Architecture Methods within Development Iterations…….39 2.4 Large-scale Agile Development (LSA)………………………………46 Characteristics of LSA………………………………………………46 Agile Practices in Large-scale………………..……………………...54 Tailoring XP for large and complex projects………………………..60 Distributed Agile Teams: the Scrum of Scrums …………………...61 A Hybrid Method using RUP with Scrum…………………………..64 2.5 Conclusions……………………………………………………………..65 References…………………....……………………………………………...…...67 This chapter presents existing research regarding architecture design and large-scale agile (LSA). Firstly, this chapter introduces agile software development (ASD) and the changes in the software development that arose from this paradigm. Then, the chapter discusses how the architectural design discipline suffered some changes within this paradigm as well as how they coexist with ASD. Afterwards, it includes a section with existing approaches oriented towards using architecture design methods in specific stages of ASD processes. Additionally, LSA approaches and all its specific impacts in development practices are also presented. This chapter ends with the conclusions of the previously presented works. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 29 Chapter 2 - Requirements and Architecture Design in LSA “ Agile architecture: a paradox, an oxymoron, two totally incompatible approaches? ” Pekka Abrahamsson, Muhammad Ali Babar and Philippe Kruchten, Software Engineering researchers 2.1 Introduction Software development lifecycle (SDLC) methodologies commonly fit within the spectrum of plan-driven or change-driven (IIBA, 2015). Plan-driven approaches are used in stable contexts that allow projects to follow early planned activities. Activities are usually sequential. Known plandriven approaches are the waterfall model (Royce, 1970), the “Vee” model (or V-Model) (Ferreira, Santos, Machado, & Gasevic, 2013; Forsberg & Mooz, 1991) or the Rational Unified Process (RUP) (Kruchten, 2004). In a plan-driven approach, requirements are defined upfront almost in their totality before moving to implementation. In opposition, change-driven approaches focus on rapid delivery of business value in short iterations (IIBA, 2015). These approaches arose before ASD. In fact, ASD is seen as one of the possible change-driven approaches, and not as one project management approach. These approaches firstly appeared as prototyping in 1984 (BW Boehm, Gray, & Seewaldt, 1984), followed by Rapid Prototyping (Fischer & Schneider, 1984), Evolutionary Delivery model (Gilb, 1985) and the spiral model (B. W. Boehm, 1988). Other frameworks like Rapid Application Development (RAD) (Martin, 1991), the Dynamic System Development Method (DSDM) (Stapleton, 1997) and Adaptive Software Development (Highsmith, 2000) were the first ones to be related to a specific type of change-driven approaches, called agile software development (ASD). All were prior to Scrum and eXtreme Programming (XP) (Beck & Andres, 2004) frameworks. The turning point for the term ‘agile’ (and ASD) relates to the signing of the ‘Agile Manifesto’ (Agile Alliance, 2001). The Manifesto does not define any methodologies or practices itself, but rather outlines a philosophy in the form of a set of values and principles that frameworks such as Scrum (Ken Schwaber, 1997) and eXtreme Programming (XP) adhere. There are also others, like Kanban (Anderson, 2010), Agile Unified Process (AUP) 2005 (SW Ambler, 2005), Crystal Chapter 2 – Requirements and Architecture Design in LSA 30 Methodologies (Cockburn, 2004) and Feature-Driven Development (FDD) (Palmer & Felsing, 2001). Lean software development (Poppendieck & Poppendieck, 2003) is another framework for change-driven approaches. It has been originated by lean production within Toyota (namely in Toyota Production System - TPS), as an outgrowth of the larger Lean movement. It embodies seven principles, originally described by Mary and Tom Poppendieck (Poppendieck & Poppendieck, 2003): 1. Eliminate Waste 2. Build Quality In 3. Create Knowledge 4. Defer Commitment 5. Deliver Fast 6. Respect People 7. Optimize the Whole The agile manifesto values working software over comprehensive documentation, and emphasizes simplicity: maximizing the amount of work not done. This principle can be interpreted in many ways. Most are quite good, but some interpretations can cause problems. For example, XP advocates doing extra work to get rid of architectural features that do not support the system’s current version. This approach works fine when future requirements are largely unpredictable (Barry Boehm, 2002). Figure 3 depicts a comparison on best suited for different contexts for agile and plan-driven methods. Figure 3. Comparison of agile and plan-driven methods (Barry Boehm, 2002) An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 31 2.2 Views on Debating Architectures and Agile There has been some discussion related to the strengths and weaknesses of software architecture with regard of agility. Abrahamsson states key advantages of up-front architecting (also called “ Big Design Up Front ” – BDUF) ) (Abrahamsson, Babar, & Kruchten, 2010). Due to the mutual influence between requirements and software architecture (Avgeriou, Grundy, Hall, Lago, & Mistrík, 2011), upfront design implies having consistent and (somehow) stable requirements across the project lifespan (Grundy, 2013). A major criticism of upfront architecting is the potential efforts in capacity that may never be used (Grundy, 2013), many times referred as “ You Ain't Gonna Need It ” (YAGNI). Non-agile methodologies are accused of not involving the customer properly during all phases of the project. Companies where architectural practices are well developed often tend to see agile practices as “ amateurish, unproven, and limited to very small Web-based sociotechnical systems ” (Kruchten, 2007). On the other hand, practitioners of agile methods think that architecture-centric methods are “ too much work, equating them with high-ceremony processes emphasizing document production ” (R. L. Nord & Tomayko, 2006), or that “ architectural design has little value ”, and that the architecture should emerge gradually Sprint after Sprint, as a result of successive small refactoring (Abrahamsson et al., 2010). In opposition to these stated accusations, Falessi et al. present a study where agile developers perceive software architecture as relevant on the basis of aspects such as communication among team members, inputs to subsequent design decisions, documenting design assumptions, and evaluating design alternatives (Falessi et al., 2010). Practitioners were also questioned about when they should focus on software architecture. The answers were “always” (45%), “never” (5%) and “when the project is complex” (50%), as depicted in Figure 4. Due to the reason of complexity is a broad term, the asked respondents who selected it to choose geographic distribution (19%), number of requirements or lines of code (33%), number of stakeholders (29%), and “other” (19%) as the leading cause of complexity. Chapter 2 – Requirements and Architecture Design in LSA 32 Figure 4. Focus on software architecture by agile developers (Falessi et al., 2010) Other works also propose useful adoption of architecture design to complement ASD typical development. It is the case of the Zipper Model (Bellomo, Kruchten, Nord, & Ozkaya, 2014; R. Nord, Ozkaya, & Kruchten, 2014). Like in any project, as the requirements are being developed and refined, they are inputs for the architecture design, and allow identifying architecturally significant requirements (ASR). Alongside, more featureor functional-oriented requirements are identified, as well as relationships between them and between the ASR’s. They are further implemented in iterations based in their relationships (Figure 5). This way, the sometimesdisregarded software infrastructure is considered at the same time as the features/functionalities within the ASD iterations. Figure 5. The Zipper model (Bellomo et al., 2014; R. Nord et al., 2014) Additionally, some aspects must be considered for those interested in designing and deploying agile processes engrained with sound architectural principles and practices (Abrahamsson et al., 2010): An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 33  Understand the context. There is a vast array of software development situations, and although “out of the box” agile practices address many of these, there are outliers that needs understanding: What is the system’s size, domain, and age? What is the business model and the degree of novelty and hence of risk? How critical is the system? How many parties will be involved?  Clearly define the architecture: its scope and the architect’s role and responsibility.  Define an architecture owner, Architects are part of the development group.  Exploit architecture to better communicate and coordinate among various parties, particularly multiple distributed teams, if any. Define how to represent the architecture, based on what various parties’ need to know.  Use important, critical, and valuable functionality to identify and assess architectural issues. Understand interdependencies between technical architectural issues and visible user functionality to weave them appropriately over time (the zipper metaphor). The issues of trying to understand the apparent conflict and reconcile the two sides are in multiple dimensions (Abrahamsson et al., 2010): 1) Semantics: What do we mean in this project or organization by “architecture”? The concept of architecture often has fuzzy boundaries. In particular, not all design is architecture. Agreeing on a definition is a useful exercise, and a good starting point. 2) Scope: How much architectural activity will you actually need? Most software projects have a de facto , implicit architecture when they start; they will not need much of an architectural effort. 3) Lifecycle: When in the lifecycle should we focus on architecture? Well, early enough, as “architecture encompasses the set of significant decisions about the structure and behavior of the system” (Kruchten, 2004): these are the decisions that will be the hardest to undo, change, refactor. Which does not mean an only focus on architecture, but interleaving architecture “stories” (i.e., stories more focused in quality requirements) and functional “stories” (i.e., stories more focused in functional requirements) in early iterations. 4) Role: Who are the architects? On large, challenging, novel system, you may need a good mix of experience, of “ architectus reloadus ”– maker and keeper of big decisions, focusing on external coordination– and “ architectus oryzus ”– mentor, prototyper, troubleshooter, more codefacing and focused on internal coordination. Chapter 2 – Requirements and Architecture Design in LSA 34 5) Documentation: How much of an explicit description of the architecture is needed? While in most cases, an architectural prototype, starting with a walking skeleton, for example, will suffice, and one or a small number of solid metaphors to convey the message, there are circumstances where more explicit software architecture documentation will be needed: to communicate to a large audience, to comply with external regulations, for example. 6) Method: How are we identifying and resolving architectural issues? How to proceed to identify architecturally significant requirements, to perform incremental architectural design, to validate architectural features, etc. There are architectural methods for addressing such issues. 7) Value and cost: All agile approaches strive to deliver business value early and often. The problem seems often that while the cost of architecture is somewhat visible, its value is hard to grasp, as it remains invisible. An approach such as the Incremental Funding Method may allow casting the right compromise between architecture and functionality, without falling into the trap of BDUF. According to Brown, Nord and Okzaya, ongoing sustainable achievement of Enhancement Agility is only possible when coupled with Architectural Agility (Brown, Nord, & Ozkaya, 2010). To achieve Architectural Agility, the agile community must first expand its focus on end user stories and address the broader topic of capabilities (see Figure 6), including quality attribute requirements and a diverse range of stakeholders. Figure 6. Informed anticipation in the context of agile release planning (Brown et al., 2010) The use of dependency analysis practices can be used to facilitate a “just-in-time” approach to building out the architectural infrastructure. Real options and technical debt An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 35 heuristics can be used to optimize architectural investment decisions by analyzing uncertainty and tradeoffs between incurred cost and anticipated value. Interest is growing in separating the facts from myths about the necessity, importance, advantages, and disadvantages of having agile and architectural approaches coexist. Like many others in software development research and practice, a healthy focus on architecture isn’t antithetic to any agile process, instead of agile practitioners jump directly to refactoring and ignoring architecture (Abrahamsson et al., 2010). Architectural design can be improved in agile methods by: (1) agile architectural modelling with lowering the overhead of architectural modelling by using an incremental, customer-involved process; and (2) an initial vision of the system including initial design is created during the first iteration of the development, where architectural design is more a draft that is changed during later development (Prause & Durdik, 2012); (3) there are several iterations for designing the system, thus a more detailed design followed further on is created (Prause & Durdik, 2012); and (4) continuous iterative design where design is embedded into agile development and architectural artifacts are updated regularly (Prause & Durdik, 2012). 2.3 Using Architecture Approaches within Agile Software Development Although there is no explicit support for the concept of architecture in XP methodology, it leads to a software system that should have some specific structures, which we call it, implicit architecture. One of them is Spike Solutions, used within planning game and when preparing user stories. A Spike solution is a simple program from the potential solutions that could solve a specific problem. In the XP method, the process starts by architectural spikes that could form some kind of initial structure of system. Therefore, it could be mentioned as a kind of analysis and design activity. Spike solution however is created for solving only one problem and the rest of the system is ignored for the purposes of the spike solution for that problem. Metaphors, on the other hand, are the result of architectural spikes and are claimed to be as a resemblance of architecture in XP (Beck & Andres, 2004). Mainly, the metaphor has two purposes. It is assumed as an abstraction of a system functionality that will keep the team on the Chapter 2 – Requirements and Architecture Design in LSA 36 same page. A second reason is that the metaphor is supposed to contribute to the team’s development of software architecture. The XP development process is composed of several iterations, each of which results to a set of integrated functionalities at the end. All new functionalities will be tested for their compatibility with other functionalities already developed in the continuous integration step. Although this process may be affective to the system architecture, even indirectly, still architectural smells might be left in the system. These smells represent inefficiencies that could gradually mislead the system`s architecture toward an unmanageable and unsuitable shape unless resolved as soon as possible. One of the proposals for performing design as concepts and requirements emerge, included in the research of Abrahamsson (Abrahamsson et al., 2010) and Farhan (Farhan, Tauseef, & Fahiem, 2009) is the approach of a walking skeleton. Abrahamsson refers to it as an architectural prototype (Abrahamsson et al., 2010). Farhan refers to it as a tiny implementation of the system that performs minimum functionality. Kazman proposes the design of a candidate architecture (Kazman, 2013). He defines this design as: “ If you are building a large, complex system with relatively stable and well-understood requirements and/or distributed development, doing a large amount of architecture work up-front will likely pay off. On larger projects with unstable requirements, start by quickly designing a candidate architecture even if it leaves out many details. ” How can a team decide what is “just enough architecture documentation” for their work? Who is the audience for architecture documentation and models? What kinds of architecture documentation might be easier to keep up to date? A detailed architectural plan may be overkill, but an agile architecture model may contain descriptions of the system in several forms (Mancl, Fraser, Opdyke, Hadar, & Hadar, 2009): • architectural layers • classes and packages • interface agreements between internal system components (including internal performance contracts) • external interfaces • extension points • key end-to-end scenarios An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 43 Figure 11. Usage of architecture-centric to improve XP activities (R. L. Nord & Tomayko, 2006) Within the activities of “Planning and Stories” and “Designing”, this approach uses a customized QAW and ADD like in aCRUM (Jeon et al., 2011). Within the activities of “Analysis and Testing” (R. L. Nord & Tomayko, 2006) presented in Figure 11, the approach uses a lightweight ATAM (Farhan et al., 2009). However, Sharifloo et al. argue that this kind of integration presented by Nord et al. (R. L. Nord & Tomayko, 2006) is not applicable into a real XP team because of the fact that they are not derived from XP values and practices and are not in the way of agile principles (Sharifloo, Saffarian, & Shams, 2008). In their paper, the primary goal in is to satisfy quality attributes when developing a system using XP method. They introduced two architectural practices Continuous Architectural Refactoring (CAR) that are applied in XP concurrently with other Real Architecture Qualification (RAQ) practices and a new role called Architect is created that performs new responsibilities raised from added practices. Truly, new practices are embedded into XP in order to be conformed to XP values and culture. The purpose is to introduce practices that are going to satisfy architectural needs of a system. In order to provide XP process model with architectural practices, there is a need to think about quality attributes and their characteristics. Kanwal et al. propose a hybrid software architecture evaluation method for FDD agile process model (Kanwal, Junaid, & Fahiem, 2010). The proposed method is hybrid of QAW, ATAM and Active Review for Intermediate Designs (ARID). Due to an emphasis of these models on rapid development, there is an ever-increasing need of architecture evaluation, and a single Chapter 2 – Requirements and Architecture Design in LSA 44 architecture evaluation method capable of preserving the agility does not exist now. FDD is most suitable for the projects with large team size and low iteration time. Moreover, FDD is very effective in business modeling of the projects. FDD consists of five major phases with each phase having a set of related activities: 1. Develop an Overall Model 2. Build a Features List 3. Plan by Feature 4. Design by Feature 5. Build by Feature FDD agile methods are characterized by customer satisfaction, fast response to changes, and release in less time. This approach is hybrid of QAW, ATAM and ARID (see Figure 12). In FDD, architecture is developed in phases 1 and 2. For phase 1 of FDD, functional as well as non-functional requirements gathering activities should be executed in parallel to ensure the development of proper architecture without affecting the agility. For that, QAW is a very good choice as the major concentration of this architecture method is on determining the quality attributes which establish the non-functional requirements of the project. For phase 2 of FDD, there are two sub activities that need architecture evaluation. While building the features list, utility trees, sensitivity points and tradeoffs should also be determined to develop a proper architecture. Utility trees, sensitivity points and tradeoffs are the inherent features of ATAM. For the assessments (verifications) ARID is to be executed as it is primarily developed for review activities. Raatikainen et al. describe how software product family engineering and backlog management can be integrated in the light of two approaches called “Agilefant” and “Kumbang” (Raatikainen, Rautiainen, Myllärniemi, & Männistö, 2008). The main element of Kumbang is that it enables describing product family from feature point of view as a feature model (see Figure 13). A feature is loosely defined as an end-user visible characteristic of a system. As a means of expressing variability and creating dependencies among features, Kumbang features can be composed of other features. A feature can define any number of subfeature definitions, which state what kinds of features can exist under that feature. If a feature does not define any subfeature definitions, it An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 45 is termed as a leaf feature , otherwise as a composed feature . Further, a feature can define any number of constraints that create dependencies to other features. Figure 12. Mapping of QAW, ATAM and ARID on FDD (Kanwal et al., 2010) Consequently, the concept of feature backlog item in Agilefant corresponds with the concept of leaf feature in Kumbang feature model. Further, all leaf features of Kumbang model can have a corresponding feature backlog item in Agilefant, and vice-versa. This mapping, hence, provides integration between a software product family model and items in a backlog. Figure 13. Integrated conceptualisation of Kumbang (Raatikainen et al., 2008) Chapter 2 – Requirements and Architecture Design in LSA 46 Madison advocates the coexistence of agile and architecture as complementary approaches and principles (Madison, 2010). He emphasizes the software architect’s vital role as a linchpin for combining the two. Madison’s approach (see Figure 14), called agile architecture, advocates using agile to get to a good architecture by appropriately applying suitable combinations of architectural functions (such as communication, quality attributes, and design patterns) and architectural skills at four points (up-front planning, storyboarding, Sprint, and working software) in the development life cycle. Figure 14. A hybrid framework for agile architecture work (Madison, 2010) 2.4 Large-scale Agile Development (LSA) Characteristics of LSA The dimensions used to define a project as large-scale relate to costs, code size and number of requirements (Dingsøyr, Fægri, & Itkonen, 2014). The same work focus on the size of teams when characterizing scaling agile projects, mainly due the coordination and communication needs and practices between teams (Dingsøyr et al., 2014). There has been an increasing interest on research in this topic, which may include (Reifer, Maurer, & Erdogmus, 2003): (1) Scale agile methods to very large projects with barely sufficient up-front planning and architectural work; (2) Deploy a federation of coordinated teams (each An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 47 internally operating as an agile team) in scaling up agile ideas; (3) Use agile methods in teams larger than a typical XP team; (4) Characterize the agile continuum through different project caricatures, ranging from typical collocated XP projects to large, multiteam, multiyear ones. Additionally, LSA initiatives can be about (Uludag, Kleehaus, Caprano, & Matthes, 2018): Culture & Mindset; Communication & Coordination; Enterprise Architecture; Geographical Distribution; Knowledge Management; Methodology; Project Management; Quality Assurance; Requirements Engineering; Software Architecture; and Tooling. Main challenges relate to stakeholders and challenges, Uludag acknowledges that challenges also relate to methodology patterns, architecture principles, viewpoint patterns and anti-patterns. The challenge with more identified papers relates to “Coordinating multiple agile teams that work on the same product”, from the “Communication & Coordination” category. From the “Software Architecture” category (in which this thesis focuses on), the “Considering integration issues and dependencies with other subsystems and teams” challenge is the one present in more papers (and actually the second one in all categories), followed by “Managing technical debts”. From the “Requirements Engineering” category (in which this thesis also focuses on), the “Creating precise requirement specifications for the Development Team” challenge is the one present in more papers, followed by “Eliciting and refining requirements of end users”. Additionally, at recent events within the International Conference on Agile Software Development (“XP” conferences), there is a dedicated workshop for discussing research trends and challenges in LSA. By gathering the results from workshops during XP2013 (Dingsøyr & Moe, 2013), XP2014 (Dingsøyr & Moe, 2014), XP2016 (Moe, Olsson, & Dingsøyr, 2016), XP2017 (Moe & Dingsøyr, 2017) and XP2018 (Dingsøyr, Moe, & Olsson, 2018), Table 2 depicts the identified topics throughout the workshops, in an attempt of characterizing recognized challenges and topics within LSA. There are primarily five frameworks that address scaling agile practices: Disciplined Agile Delivery (DAD) (Scott Ambler & Lines, 2012), Large-Scale Scrum (LeSS) (Larman & Vodde, 2016), Scaled Agile Framework (SAFe) (Leffingwell, 2016), Scrum@Scale (Sutherland, 2018) and Nexus (K Schwaber, 2015). Each of these frameworks draws from variety of agile and lean practices. Sometimes the “Spotify model” (Kniberg & Ivarsson, 2012) is included within these scaling frameworks, however it is not much as a framework with practices and events for Chapter 2 – Requirements and Architecture Design in LSA 48 companies to adopt, but rather a cross-matrix structure adopted by Spotify company. These frameworks are now introduced. Table 2. Research challenges‘ priority at XP’s scientific workhops on LSA LSA workshop High Medium Low XP2018 • Agile in public/ IT government • Agile transformation • Business agility • Scaling agile • Patterns in large scale agile development • The role of architects and architecture in agile • Integrating non-software and software parts of the organization into agile (enterprise agile) • Knowledge sharing / networks • Inter-team coordination • How DevOps affects agile XP2017 •Inter-team coordination •Agile transformation •Agile transformation •Business agility •Knowledge sharing and knowledge networks XP2016 •Distributed Large-Scale •Inter-team Coordination •Knowledge Sharing •Large-scale Agile Transformations •Multidisciplinary Work •New Ways-of-Organizing XP2014 •Organisation of large development efforts •Variability factors in scaling •Inter-team coordination •Key performance indicators in large development efforts •Knowledge sharing and Improvement •Release planning and architecture •Customer collaboration •Scaling agile practices •Agile contracts •Agile transformation •UX design XP2013 •Inter-team coordination •Large project organization / portfolio management •Release planning and Architecture •Scaling agile practices •Customer collaboration •Large-scale agile transformation •Knowledge sharing and Improvement •Agile contracts An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 49 DAD is a hybrid approach that extends Scrum with proven strategies from Agile Modeling (AM), XP, Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. A full lifecycle goes from the initial idea for the product, through delivery, to operations and support and often has many iterations of the delivery lifecycle (Figure 15). Because it is not prescriptive and strives to reflect reality as best it can, DAD actually supports several versions of a delivery lifecycle: (1) An agile/basic version that extends the Scrum Construction lifecycle with proven ideas from RUP; (2) An advanced/lean lifecycle; (3) A lean continuous delivery lifecycle; and (4) An exploratory “Lean Startup” lifecycle. Figure 15. Disciplined Agile Delivery (DAD) LeSS is one-team oriented for scaled projects within Scrum practices (Larman & Vodde, 2016). LeSS includes a single Product Backlog (because it’s for a product, not a team); one Definition of Done for all teams; one Potentially Shippable Product Increment at the end of each Sprint; one Product Owner; many complete cross-functional teams (with no single-specialist teams); and all Teams in a common Sprint to deliver a common shippable product, every Sprint. The roles, events and artifacts of LeSS are represented in Figure 16. Chapter 2 – Requirements and Architecture Design in LSA 50 Figure 16. LeSS framework The Scaled Agile Framework (SAFe) was created by Dean Leffingwell. The framework articulates three levels of organization (Figure 17): Team, Program and Portfolio. Each level incorporates agile and lean practices, has its own activities and all levels are tied together. At the team level, SAFe specifies a blend of Scrum and XP practices. The code practices include Agile Architecture, Continuous Integration, Test-First, Code Refactoring, Pair Work, and Collective Code Ownership. SAFe does not expect teams to produce Potentially Shippable Increment (PSI) every Sprint, but rather over a quarterly cadence. At the program level, provides features, which the teams deconstruct and size to fit into iterations. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 51 Figure 17. SAFe levels (Portfolio, Program and Team) The three scaling frameworks provide approaches that attempt to address some of the issues that an organization faces and offer solutions to address these gaps. However, each framework provides some benefits, but they have shortcomings as well. DAD creates four distinct lifecycles, each of which an organization can adapt to fit its context. However, it also specifies an overly complicated work items pool, which an organization can address in much simpler ways. LeSS starts where Scrum leaves off when it comes to scaling agile practices in large organization. However, in the process, it makes recommendations that are problematic, like having a single Product Owner for up to ten teams SAFe organizes its practices into three levels (team, program and portfolio), which is quite useful for larger organization. At a team level, it embraces certain XP practices, which standard Scrum does not. However, the framework has myriad of issues, including being overtly process heavy (Vaidya, 2014). Scrum@Scale (Sutherland, 2018) is a framework for scaling Scrum, developed by Jeff Sutherland – “one of the fathers” of Scrum – and Scrum Inc. It is defined as “ A framework within which networks of Scrum teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value ”. In Chapter 2 – Requirements and Architecture Design in LSA 52 short, it is a framework that uses Scrum for scaling Scrum, using approaches of “Scrum of Scrums” (oriented for a team of Scrum Masters) and “MetaScrums” (oriented for a team of Product Owners) for coordinating Scrum teams. Figure 18. Scrum@Scale Developed by Ken Schwaber – the “other father” of Scrum - and Scrum.org, the Nexus Framework (K Schwaber, 2015) is a framework for large-scale product or software development largely based on Scrum. By consisting in roles, events, and artifacts, Nexus is defined itself as an exoskeleton resting on top of three to nine Scrum teams. These Scrum teams are dedicated to the development of one integrated “done” product increment, and Nexus framework supports them to deal with dependencies and interoperation. In contrast to Scrum, Nexus is a quite new framework about which only a small amount of literature was published (Uludag, Kleehaus, Xu, & Matthes, 2017). An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 59 large team can also be considered as one of the key challenges; and lack of dedicated meeting room for each site and Scrum team distribution at multiple sites also appear to be challenging factors that restrict the team communication and collaboration processes. In order to face these challenges, there are some archetypes and strategies for coordination issues. Archetypes for coordination strategies in multiteam systems are classified by their mechanistic, organic and cognitive coordination (Scheerer, Hildenbrand, & Kude, 2014). The “Perfect Plan” strategy type is characterized by high mechanistic, low organic and low cognitive coordination. While within teams, coordination may well be achieved through organic or cognitive mechanisms, the focus of multiteam coordination in this strategy lies solely on mechanistic coordination with little communication between individual actors. This type assumes that software development can be “programmed” from a coordination perspective, e.g. through complete upfront planning all dependencies as well as all contingencies can be resolved and accounted for. Since the coordination is programmed through upfront planning with little communication, one person or a very small set of people, needs to have a deep insight into the full technical details of the entire software system in order to specify all details necessary for individual work packages and correct integration. Risk Management Boehm and Turner describe a 5-step risk-based approach (see Figure 23) for benefiting of both agile and plan-driven methods (Barry Boehm & Turner, 2003). They define tasks to evaluate and determine Commercial Off-the-Shelf (COTS), reuse, and architecture choices during Systems definition and architecting. They include architectures in three distinctive agent-based system application projects within a case study. The three applications were classified as their scalability and criticality: • Small, relatively noncritical. This agent-based planning system for managing events such as conferences or conventions is based on risk patterns observed in small Web-services applications. • Intermediate. An agent-based planning system for supply-chain management across a network of producers and consumers, this application is based on risk patterns derived from the experience with scaling up XP techniques to a 50-person project in a lease-management application. Chapter 2 – Requirements and Architecture Design in LSA 60 • Very large, highly critical. This agent-based planning system for national crisis management is based on risk patterns observed in the US Defense Advanced Research Project Agency and the US Army Future Combat Systems program—an agent-oriented, network-centric system of systems being developed by more than 2,000 people. Figure 23. Five-Step risk-based approach (Barry Boehm & Turner, 2003) Tailoring XP for large and complex projects Agile XP practices are suitable for large-scale, complex software development (Cao, Mohan, Xu, & Ramesh, 2004). Having as basis a set of agile practices, namely Accept multiple valid approaches, Accommodate requirements change, Engage the customer, Build on successful experience, Develop good teamwork, Effective software development conforms to project environment constraints, and Prepare for unexpected consequences from innovation in software processes, it presents a set of 7 XP practices suited for large-scale agile projects: An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 61 • Practice 1: Designing upfront. It combines designing upfront with agile practices such as short release, pair programming, and refactoring. • Practice 2: Short Release cycles with a layered approach. The system continuously accommodates requirements changes. The delivered functionalities suit the customer need rather than focusing on documenting detailed specifications. • Practice 3: Surrogate customer engagement. This practice is a modified version of XP practice “on site customer”. • Practice 4: Flexible pair programming. Contrary to “always paired” in XP, developers are paired in analysis, design and testing. Coding is performed by solo programming. The combination of solo programming and pair programming overcomes some shortfalls of pair programming ( e.g. , developer’s resistance), while still benefiting from it where feasible. • Practice 5: Identifying and managing developers. People factor is more important in agile development than in traditional development. It emphasizes choosing the right people for the team and creating a collaborative environment to support teamwork. Developers’ knowledge and experiences on different aspects of a project are greatly valued. • Practice 6: Reuse with forward refactoring. This practice maps to the principle of building on successful experience. Refactoring is used as a technique to enhance reuse. Developers usually focus only on their current need instead of building components for later reuse. However, for a large project, development of upfront architectural design and use of design patterns are critical. Functionalities of the system are developed based on design patterns. In addition, modules that have been developed to handle specific functionalities are refactored and made generic enough so that they can be tailored to handle different functionalities. • Practice 7: Flatter hierarchies with controlled empowerment. Developers are empowered to make their own decisions. On the other side, for a large and mission-critical application, the empowerment might cause unexpected consequences such as incompatibilities among the development process and products produced by different developers. Distributed Agile Teams: the Scrum of Scrums Besides the use of Scrum in small organizations or in small projects, some techniques for adapting events, actors and artifacts arise in order to geographical distributed teams or multiple Chapter 2 – Requirements and Architecture Design in LSA 62 teams could work for the same product development (Eckstein, 2013). Distributed Scrum is classified in three distributed team models (Sutherland, Viktorov, & Blount, 2006): (1) Isolated Scrums – teams are isolated across geographies; (2) Scrum of Scrums – multiple Scrum teams working on the same product and in the same geographical space (Cristal, Wildt, & Prikladnicki, 2008); and (3) Totally Integrated Scrum – where multiple teams are geographical distributed (Paasivaara, Durasiewicz, & Lassenius, 2008b). The Scrum methodology was also tested in projects involving different organizations trying to implement the same product (Dingsøyr, Hanssen, Dybå, Anker, & Nygaard, 2006). Additionally, another scaled framework from Scrum is Large-Scale Scrum (LeSS) (Larman & Vodde, 2016). This framework is one-team oriented for scaled projects within Scrum practices. LeSS includes a single Product Backlog; one Definition of Done for all teams; one Potentially Shippable Product Increment at the end of each Sprint; one Product Owner; many complete cross-functional teams (with no single-specialist teams); and a common Sprint for all Teams, every Sprint. The roles, events and artifacts of LeSS are represented in Figure 16 in Section 2.4. Scrum uses structured meetings such as the daily Scrum meeting, the daily Scrum of Scrums meeting, the Sprint planning meeting, and the Sprint review meeting. These meetings are key components of the Scrum method and they should be adjusted to the distributed working environment (Cho, 2007). Information and knowledge-sharing issues were the most important issues in the company due to its geographically distributed working environment, where also coordination, communication, control, training, and trust and confidence issues hinder developers from being efficient (Cho, 2007). Paasivaara describes adaptation to meetings as well (Paasivaara, Durasiewicz, & Lassenius, 2008a). Each team’s parallel work within the same product development must be coordinated, but breakthroughs and progress within the distributed Scrum teams are slow and hard to achieve (Begel, Nagappan, Poile, & Layman, 2009). Scrum roles and events can be easily adapted to such dependencies between teams since the agile methodologies provide this kind of flexibility. These adaptations allow distributed teams (geographical distributed or not) to work in parallel and at the same time, and are mandatory in order to prevent an increase of the time to market, that could endanger the project execution. The product backlog should be aligned by collaborating product owners (Leffingwell, 2007). An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 63 The role of a Scrum master should be adjusted. Since the Scrum master is the key person for the success of Scrum, the Scrum master should be engaged more actively in projects as a coordinator and a controller in distributed Scrum environment. As a coordinator/controller, the Scrum master needs to ensure share of information and knowledge well between the sites and that the tasks are divided and assigned well through the Sprint planning meeting. In addition, the Scrum master needs to have the authority to motivate developers to work hard and to take ownership of the projects. These tasks can be eased by using various tools such as Wiki, VersionOne, and JIRA (Cho, 2007). The various Scrum meetings should be adjusted due to the geographical distance. For example, in daily Scrum meetings which are held every day for less than 15 minutes, team members come to talk about what tasks have been done since the last meeting, what tasks will be done before the next meeting, and what the issues and challenges are imposed on the tasks. Scrum team members come to daily Scrum meetings to communicate with other team members to find out what is going on. However, the effectiveness of communication between the sites is severely limited compare to face-to-face conversation. To mitigate the problem, the daily Scrum meeting and other Scrum meetings should be held with good communication devices. Among many different multi-media devices, a video conferencing system between the sites is recommended as the best way to communicate. Other tools including remote desktop, an email system, an instant message system, and a phone system can mitigate the communication problems too (Cho, 2007). Regarding Sprints and events, it is normal that not all of team’s Sprints are synchronized relating its start date. The Scrum Master and the Product Owner should have total availability to work with all teams equitably. Besides, if problem reports arise from a team in a Sprint Review or a Sprint Retrospective, there is still enough time to re-schedule aspects in other teams or reallocate resources at the end of the other team’s Sprints. Additionally, another issue that can be considered is that one element of each team may participate in other team’s Sprint Review, and all elements should participate instead of always the same element participating in those Sprint Reviews, so all team elements have the opportunity to know other teams’ work. Chapter 2 – Requirements and Architecture Design in LSA 64 A Hybrid Method using RUP with Scrum Scrum and RUP can be combined by embedding Scrum ceremonies (Daily Scrum meeting and Sprint meeting) and roles (Scrum Master, Team, Product Owner), and artifacts (product backlog, sprint backlog, and burndown chart) within RUP phases (Cho, 2009) (see Figure 24). In this work, the business modeling discipline is the main player in the inception phase. The analysis and the design disciplines are mostly utilized in the elaboration phase. The implementation and testing disciplines focus on the construction phase, whereas, the deployment and configuration disciplines are in the transition phase. Figure 24. Hybrid model combining RUP phases and Scrum ceremonies (Cho, 2009) The daily Scrum meeting, the daily Scrum of Scrums, the Sprint planning meeting, and the Sprint review meeting can be conducted iteratively in each RUP phase (Figure 25). The product owner can create the product log as a part of the business modeling discipline. The Scrum Master also can plays the usual role defined in the Scrum process. The tasks defined in the product backlog and the Sprint backlog can be accomplished and monitored through the daily Scrum meeting and the Sprint meeting. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 65 Figure 25. A Typical Phase of Hybrid Model (Cho, 2009) 2.5 Conclusions The reviewed literature encompass applicability of software architecture methods within any of the phases in an agile project, from sprint planning, user stories, backlogs, development, testing, etc. Additionally, the aforementioned approaches relate to a diversity of agile methodologies, from XP to Crystal, FDD or Scrum (as shown in Table 3). The aforementioned approaches showed that there is an opportunity to improve software development while maintaining a balance between agility and the architectural approach. Therefore, several approaches to integrate and embed software architecture and agile methods are proposed. These works all have in common the fact that architecture methods must perform in parallel with common agile methodologies, and the architecture itself must possess agility and flexibility enough to respond to changes rapidly. Chapter 2 – Requirements and Architecture Design in LSA 66 Table 3. Applicability of the reviewed approaches Reference Phase Architecture-driven Method Agile Framework (R. L. Nord & Tomayko, 2006) Planning and Stories, Designing, Analysis and Testing QAW, ADD, ATAM/CBAM XP (Jeon et al., 2011) Planning and stories, and Designing QAW, ADD XP, Scrum (Farhan et al., 2009) Analysis and Testing ATAM XP, Crystal (Sharifloo et al., 2008) Planning and stories, before upcoming iteration XP (Kanwal et al., 2010) All phases (Develop an Overall Model, Build a Features List, Plan by Feature, Design by Feature, Build by Feature) QAW, ATAM, ARID FDD (Madison, 2010) up-front planning, storyboarding, Sprint, and working software communication, quality attributes, and design patterns N/A (Díaz et al., 2014) Planning and stories, Sprints Change Impact Analysis Scrum These approaches do not include thorough requirements specification and a logical architecture able to be used as basis for the development like 4SRS does. Additionally, the initial backlog should include both functional and quality (non-functional) requirements (typically quality ones only emerge during development), where 4SRS supports their identification by using the Model/View/Controller (MVC) pattern. It is expected that the proposed approach uses these “strengths” of 4SRS and adapt them to agile context, but also to include concerns that the presented approaches provide (change impact analysis, architecture review and assessment, and others). This chapter essentially focused in presenting existing research regarding architecture design and large-scale agile (LSA). After a brief contextualization of how the architectural design discipline changed and coexisted with the adoption of ASD, it described existing approaches that used architecture design methods in specific stages of ASD processes and described how practices may require some change in scaled ( i.e. , LSA) settings. The presented works allowed An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 67 depicting that architecture has a specific role depending in the development stage where it is applied and, foremost, that the design is evolutionary and that the work is performed in a continuous way. The adoption of “ continuous ”-oriented approaches leads to specific concerns towards defining practices for modeling requirements and architecture. Such concerns are described in Chapter 3. References Abrahamsson, P., Babar, M. A., & Kruchten, P. (2010). Agility and architecture: Can they coexist? IEEE Software , 27 (2), 16–22. https://doi.org/10.1109/MS.2010.36 Agile Alliance. (2001). Manifesto for agile software development. Ambler, S. (2005). The agile unified process (aup). Ambysoft . Ambler, S., & Lines, M. (2012). Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise . IBM Press. Anderson, D. (2010). Kanban: successful evolutionary change for your technology business . Blue Hole Press. Avgeriou, P., Grundy, J., Hall, J. G., Lago, P., & Mistrík, I. (2011). Relating Software Requirements and Architectures . Beck, K., & Andres, C. (2004). Extreme programming explained: embrace change . AddisonWesley Professional. Begel, A., Nagappan, N., Poile, C., & Layman, L. (2009). Coordination in large-scale software teams. In Workshop on Cooperative and Human Aspects on Software Engineering (ICSE) (pp. 1–7). IEEE Computer Society. Bellomo, S., Kruchten, P., Nord, R., & Ozkaya, I. (2014). How to Agilely Architect an Agile Architecture. Cutter IT Journal . Bjarnason, E., Wnuk, K., & Regnell, B. (2011). A case study on benefits and side-effects of agile practices in large-scale requirements engineering. In 1st Workshop on Agile Requirements Engineering (p. 3). ACM. Boehm, B. (2002). Get ready for agile methods, with care. Computer , 35 (1), 64–69. Chapter 2 – Requirements and Architecture Design in LSA 68 Boehm, B., Gray, T., & Seewaldt, T. (1984). Prototyping versus specifying: a multiproject experiment. IEEE Transactions on Software Engineering , SE - 10 (3), 290–303. Boehm, B., & Turner, R. (2003). Using risk to balance agile and plan-driven methods. Computer , 36 (6), 57–66. Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer , 21 (5), 61–72. Brown, N., Nord, R., & Ozkaya, I. (2010). Enabling agility through architecture . DTIC Document. Cao, L., Mohan, K., Xu, P., & Ramesh, B. (2004). How extreme does extreme programming have to be? Adapting XP practices to large-scale projects. In 37th Annual Hawaii International Conference on System Sciences (p. 10 pp.). IEEE. Cho, J. (2007). Distributed Scrum for large-scale and mission-critical projects. In Americas Conference on Information Systems (AMCIS) (p. 235). Cho, J. (2009). A hybrid software development method for large-scale projects: rational unified process with scrum. Issues in Information Systems , 10 (2). Clements, P., Ivers, J., Little, R., Nord, R., & Stafford, J. (2003). Documenting Software Architectures in an Agile World . DTIC Document. Cockburn, A. (2004). Crystal clear: a human-powered methodology for small teams . Pearson Education. Coplien, J. O., & Bjørnvig, G. (2011). Lean architecture: for agile software development . John Wiley & Sons. Cristal, M., Wildt, D., & Prikladnicki, R. (2008). Usage of Scrum practices within a global company. In nternational Conference on Global Software Engineering (ICGSE) (pp. 222– 226). IEEE. https://doi.org/10.1109/ICGSE.2008.34 Daneva, M., Van Der Veen, E., Amrit, C., Ghaisas, S., Sikkel, K., Kumar, R., … Wieringa, R. (2013). Agile requirements prioritization in large-scale outsourced system projects: An empirical study. Journal of Systems and Software , 86 (5), 1333–1353. Díaz, J., Pérez, J., & Garbajosa, J. (2014). Agile product-line architecting in practice: A case study in smart grids. Information and Software Technology , 56 (7), 727–748. Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 75 Chapter 3 - Logical Architectures within Agile and “Continuous” Approaches Chapter 3 - Logical Architectures within Agile and “Continuous” Approaches……..76 3.1. Introduction……………………………………………………………..76 3.2. Architecture lifecycle and viewpoints…………………………………..79 Software architecture lifecycle overview……………...…………….79 Software architecture methods……………..……….……………….85 Software architecture classification levels...………………………...85 3.3. Modeling approaches within the “continuous” paradigm………………92 Continuous software engineering……………………..……………..92 Continuous Architecture..…………………...………………………97 Architectural Management, Evolution, Change, and Debt………….99 3.4. Microservices architectures……………………………………………102 Microservices modeling……………………..……………………..108 Defining service boundaries………………………………………..112 Microservices patterns……………………………………………...113 3.5. Conclusions……………………………………………………………116 References…………………………………...………………………………….117 This chapter describes how the design is evolutionary and that the work addresses specific concerns towards defining practices for modeling requirements and architecture within the “continuous” paradigm. This chapter starts by presenting the software architecture lifecycle. Afterwards, it describes the “continuous” practices, starting with continuous software engineering approaches, then continuous architecting approaches and architecture management and debt. For easing the continuous architecting and management, this chapter also describes microservices architectures and their modeling. This chapter ends with the conclusions of the previously presented works. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 76 Chapter 3 - Logical Architectures within Agile and “Continuous” Approaches “ Meaningful architecture is a living, vibrant process of deliberation, design, & decision, not just documentation. ” Grady Booch, co-author of UML 3.1. Introduction If, on one hand, the previous section focused on approaches for delivering products or services using agile practices supported by architectural methods, on the other hand this section points out that the product delivery is a continuous process. While there are frameworks for “delivering the product right” (e.g., Scrum, XP, etc.) in short cycles, ASD is about getting feedback, learning and adapting. It is also about “delivering the right product”. It is in this sense that approaches like “Lean Startup” (Ries, 2011) and “Lean Six Sigma” (George & George, 2003), by using tools like “Plan - Do - Check - Act or Adjust” (PDCA) and “Define, Measure, Analyze, Improve and Control” (DMAIC) cycles, suggest that product companies must get feedback and learn from customers after a product is deployed in the marketplace. Such feedback is conducted under controlled experiments, such as “A/B testing” (Kohavi & Longbotham, 2017). The GROWS method (Hunt, 2015) is another example of learningoriented ASD. Modern Agile 2 framework was created by a community of practitioners that aim to modernize ASD practices. It also presents revised principles of the ones from the Agile Manifesto, namely (Figure 26) (Kerievsky, 2016): “Make people awesome” (i.e., “Customer Obsession” by figuring out what’s holding them back and making essential changes to help them achieve awesome results); “Make safety a prerequisite” (i.e., learn blamelessly from failures and quickly improve); “Experiment and learn rapidly” (fail fast and quickly move on to new experiments in order to achieve continuous improvement); and “Deliver value continuously” (a safe, continuous deployment pipeline lowers stress by making releasing an automated event). 2 http://modernagile.org/ Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 77 Figure 26. Modern Agile Heart of Agile 3 was created by Alistair Cockburn, one of the authors of the Agile Manifesto, in an attempt to go back to the essence of the Agile Manifesto, based in four actions: Collaborate; Deliver; Reflect; Improve. Figure 27. Heart of agile The four actions can be further expanded using the Japanese concept “Shu-Ha-Ri” of skill progression in training and learning (Novack, 2016)., The diagram extends more specific actions to complement the four primary actions ( Learning and Income extending Deliver , Insights and Improvements extending Reflect , Collaboration and Trust extending Collaborate , and Experiment 3 http://heartofagile.com An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 78 and Change extending Improve ). In addition, it highlights the need to “return to center” where the heart of agile resides (the fourth stage “Kokoro”, meaning "heart" in Japanese). Heart of Agile and Modern Agile have some similarities, since both concepts (Ageling, 2018):  have a solid foundation in the original Agile Manifesto  are lightweight  are based on four principles  are easy to understand, with a lot behind them  are going back to the core There are differences though. While Heart of Agile is about returning to the essence of the Agile Manifesto, Modern Agile claims to be an evolved version of it. Additionally, Heart of Agile guides on doing and mastering things, while Modern Agile’s principles are primarily to reflect on the present and the future. Heart of Agile and Modern Agile both are inspirational concepts, bringing “Agile” back to a core. Both with a different perspective. And they are not mutually exclusive (Ageling, 2018). Modern Agile principles can help identifying topics to improve or enhance and Heart of Agile can guide this journey of improvement. This paradigm has required the software teams to adopt “continuous”-oriented approaches for delivering software products, i.e., “continuous software engineering” (CSE) (Bosch, 2014). This way of working originated from the adoption of continuous integration (CI) and continuous deployment (CD) practices. Performing both practices properly – CI and CD – allows companies to have a continuous delivery environment. Inside the CSE, a widely used approach towards continuous delivery is DevOps (Loukides, 2012), linking software “development” to “operations” (or maintenance) after deployment to the marketplace. Similar linkage between “development” and the “business analysis” is proposed by BizDev (Fitzgerald & Stol, 2017), and the three disciplines are linked in BizDevOps (Gruhn & Schäfer, 2015). Following the “continuous”-oriented paradigm, in order to define properly support CI and CD practices, practices such as continuous requirements engineering (CRE) (Kirikova, 2017) and continuous architecture (Erder & Pureur, 2015) arose. Together, they allow a “full-cycle” support of continuous practices. Fitzgerald and Stol called it “Continuous ∗” (i.e. Continuous Star ) Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 79 (Fitzgerald & Stol, 2017). CRE and CA are discussed in this section, since the scope of this thesis focuses on these requirements and architecture discipline, rather than CI or CD, for instance. Regarding RE, Pohl identifies two perspectives on continuity of requirements engineering (Pohl, 2010): continuous changes in the business environment, and requirements engineering activities in each phase of the systems development lifecycle. Specifically within the second one, RE is performed as a sub-function of future representation, reality representation, fulfilment Engineering, design and implementation, operations, and management (Kirikova, 2017). Of course, it mainly relates to performing RE continuously rather than only in an initial upfront effort (Grau & Lauenroth, 2014). The effort of avoiding upfront RE, from practices and principles proposed by entities like International Institute of Business Analysis (IIBA, 2017) and International Requirements Engineering Board (IREB, 2018), has been presented in chapter 2. In terms of architecture and design, the “continuous” paradigm is called Continuous architecture (CA) (Erder & Pureur, 2015). CA is an architectural approach that can encompass continuous delivery, providing it with a broader architectural perspective. The CA principle recommends delaying design decisions until they are absolutely necessary (Erder & Pureur, 2015). The developed system should be architected to enable changes, leveraging “The Power of Small”. Moreover, the systems should be architected with a special focus on the build, test, and deploy phases. Finally, the CA principle also suggests following Conway’s law (Conway, 1968), modeling the organization of the development teams after the design of the system they are working on. Migration to microservices (Newman, 2015) is one of the most common situations when companies adopt continuous architecting processes (Davide Taibi, Lenarduzzi, & Pahl, 2017). In an era where software solutions are more and more cloud-based, microservices architectures provide many benefits in CA and CI/CD (and DevOps). Thus, continuously architect microservices is within the scope of this thesis. 3.2. Architecture lifecycle and viewpoints Software architecture lifecycle overview Architecture design includes from conceptual level to more refined one (Fernandes & Machado, 2016). Such argument is in line with the design process proposed by Douglass: architectural, mechanistic, and detailed (Douglass, 1999). Architectural design defines the An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 80 strategic decisions that affect most or all the software components, such as concurrency model and the distribution of components across processor nodes. Mechanistic design elaborates individual collaborations by adding “glue” objects to bind the mechanism together and optimize its functionality. Such objects include containers, iterators, and smart pointers. Detailed design defines the internal structure and behavior of individual classes. This includes internal data structuring and algorithm details. These three levels of design are depicted in Figure 28. Figure 28. Three levels of architectural design (Douglass, 1999) During a SDLC, the architecture aims different inputs, target-users and viewpoints at each stage. Other authors, like Kazman, Nord and Klein explore the use of architecture during SDLC stages (Kazman, Nord, & Klein, 2003) - Business needs and constraints, Requirements, Architecture design, Detailed design, Implementation, Testing, Deployment, and Maintenance (Table 4). Within these stages, they described the different goals of architecture-based activity and how architecture-centric methods, namely the Architecture Tradeoff Analysis Method (ATAM), the Quality Attribute Workshop (QAW), the Cost-Benefit Analysis Method (CBAM), Active Reviews for Intermediate Designs (ARID), and the Attribute-Driven Design (ADD) method contribute to those stages (Table 5). An architecture has a particular scope. It may relate from software, hardware, organization or information, the overall system which encompasses all four, or the enterprise that hosts the Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 81 system (or will host a future system to be developed) (Eeles & Cripps, 2009). Within an organization or development project, many architectural viewpoints are defined, each more suitable for a given user but all related to each other. The “4+1” View Model (Kruchten, 1995) is one of the widely known architecture model, which presents the logical, process, physical, development and scenarios views. Other views like Siemens’ Five-view Model (Soni, Nord, & Hofmeister, 1995), Reference Model of Open Distributed Processing (RM-ODP) (ISO, 1998), NIST Enterprise Architecture Model (Fong & H., 1989), Department of Defense Architecture Framework (DoDAF) (DoD, 2009) or the Zachman Framework ™ (Zachman, 2011) present relations between these viewpoints. Urbaczewski and Mrdalj compare some of these frameworks (Table 6) in order to provide context for their suitability (Urbaczewski & Mrdalj, 2006). Table 4. Architecture-based activities within a SDLC (Kazman et al., 2003) Life-Cycle Stage Architecture-Based Activity Business needs and constraints  Create a documented set of business goals: issues/environment, opportunities, rationale, and constraints using a business presentation template. Requirements  Elicit and document six-part quality attribute scenarios using general scenarios, utility trees, and scenario brainstorming. Architecture design  Design the architecture using ADD.  Document the architecture using multiple views.  Analyze the architecture using some combination of the ATAM, ARID, or CBAM. Detailed design  Validate the usability of high-risk parts of the detailed design using an ARID view. Implementation Testing Deployment Maintenance  Update the documented set of business goals using a business presentation template.  Collect use case, growth, and exploratory scenarios using general scenarios, utility trees, and scenario brainstorming.  Design the new architectural strategies using ADD.  Augment the collected scenarios with a range of response and associated utility values (creating a utility-response curve); determine the costs, expected benefits, and ROI of all architectural strategies using the CBAM.  Make decisions among architectural strategies based on ROI, using the CBAM results. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 82 Table 5. Use of architecture-centric methods within a SDLC (Kazman et al., 2003) Life-Cycle Stage QAW ADD ATAM CBAM ARID Business needs and constraints Input Input Input Input Requirements Input; Output Input Input; Output Input; Output Architecture design Output Input; Output Input; Output Input Detailed design Input; Output Implementation Testing Deployment Maintenance Input; Output Table 6. A comparison of enterprise architecture frameworks (Urbaczewski & Mrdalj, 2006) SLDC Phase/ Framework Planning Analysis Design Implementation Maintenance Zachman Yes Yes Yes Yes No DoDAF Yes Yes Yes Describes final products No FEAF Yes Yes Yes Yes Detailed Subcontractor’s view TEAF Yes Owner’s Analysis Yes Yes No TOGAF Principles that support decision making across enterprise; provide guidance of IT resources; support architecture principles for design and implementation A software architecture, just like a software project, has a lifecycle. The Software Architecture Development Life Cycle (SADLC) (Reddy, Govindarajulu, & Naidu, 2007) has inputs from the business architecture or from software development life cycle for performing its architecture analysis and design. Then, the SADLC follows Software Architecture Analysis, Architecture design, Evaluation of design and ending in the Implementation of the Architecture (Figure 29). In the SADLC, the control moves from spiral model to the architectural issues area with design (SDLC) information and resolve all architectural issues (Figure 30). Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 83 Figure 29. The Software Architecture Development Life Cycle (SADLC) (Reddy et al., 2007) The OMG modeling infrastructure, or Four-Layer Architecture, comprises a hierarchy of model levels just in compliance with the foundations of MDD (Model-Driven Development) (Atkinson & Kuhne, 2003). Each model in the Four-Layer Architecture (except for the one at the highest level) is an instance of the one at the higher level, which range from M0 to M3. The first level ( user data ), i.e., M0, refers to the data manipulated by software. Models of user data - one level above - are called user concepts models, i.e., M1. Models of user concepts models are language concepts models, i.e., M2. These are models of models and so are called metamodels. A metamodel is a model of a modeling language. It is also a model whose elements are types in another model. It describes the structure of the different models that are part of it, the elements that are part of those models and their respective properties. The language concepts metamodels are at the highest level of the modeling infrastructure. The hierarchy of models is as follows: M3 – Language concepts metamodels: M2 – Language concepts: M1 – User concepts: M0 – User data: An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 84 Figure 30. Proposing architectural issues within the Spiral-based SADLC (Reddy et al., 2007) In comparison, the Model-driven Architecture (MDA) (OMG, 2003) proposes a hierarchical structure for model abstraction, namely:  Computation-independent model (CIM)  Platform-independent model (PIM)  Platform-specific model (PSM) Figure 31. MDA-based model abstraction (Dodani, 2006) Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 91 Technical – Phase: Implementation; 4+1: Development; Abstraction: PSM. (Others: NIST EA Model: Delivery Systems; Siemens Five-view Model: Code; SEI’s viewpoint and target audience: N/A; ISO-RM ODP: Technical; Viewpoint Catalog: Development; DoDAF 2.0: Systems; Zachman: Technology.) A deployment architecture defines the execution architecture of systems and the assignment of software artifacts to system elements (UML, 2011). With this definition in mind, the deployment architecture can be classified as: Deployment – Phase: Deployment; 4+1: Physical; Abstraction: PSM. (Others: NIST EA Model: Delivery Systems; Siemens Five-view Model: Execution; SEI’s viewpoint and target audience: Physical; ISO-RM ODP: Computation; Viewpoint Catalog: Deployment; DoDAF 2.0: Product; Zachman: Concepts.) A physical architecture show a system's physical layout, revealing which pieces of software run an what pieces of hardware (Fowler, 2004). With this definition in mind, the physical architecture can be classified as: Physical – Phase: Deployment; 4+1: Physical; Abstraction: PSM. (Others: NIST EA Model: Delivery Systems; Siemens Five-view Model: Hardware; SEI’s viewpoint and target audience: Physical; ISO-RM ODP: Technical; Viewpoint Catalog: Operational; DoDAF 2.0: Systems; Zachman: Technology.) Figure 36. Viewpoints classifications at Level 4 An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 92 3.3. Modeling approaches within the “continuous” paradigm Continuous software engineering While agile practices have succeeded in involving the customer in the development cycle, there is an urgent need to learn from customer usage of software also after delivering and deployment of the software product. Among the plethora of available practices that a company may use towards “being agile”, Olsson, Alahyari and Bosch propose a pathway for stages that a company should embrace, called “Stairway to Heaven” (Helena Holmstrom Olsson, Alahyari, & Bosch, 2012; Helena Holmström Olsson & Bosch, 2014). It is composed by five stages, as depicted in Figure 37: (i) Traditional development; (ii) Agile R&D organization; (iii) Continuous integration; (iv) Continuous deployment; and (v) R&D as an experiment system. Figure 37. "Stairway to Heaven" (Helena Holmstrom Olsson et al., 2012; Helena Holmström Olsson & Bosch, 2014) Traditional development Traditional development is typically the starting point for most companies. Traditional development is a software development approach characterized by slow development cycles, sequential phases (waterfall-style), and a rigorous planning phase in which requirements are frozen upfront (Sommerville, 2007). Projects adopting this development approach suffer from long feedback cycles and difficulties to integrate customer feedback into the product development process (Helena Holmstrom Olsson et al., 2012; Sommerville, 2007). Typically, software delivery takes place in the end of the project life cycle, and it is then that customers can provide feedback. Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 93 Agile R&D organization Adopting agile development practices is typically for overcoming the challenges from overcoming the customer’s long feedback cycles. Agile practices are characterized by small cross-functional development teams, short development Sprints resulting in working software, and continuous planning in which the customer is involved to allow for continuous customer feedback (Highsmith, 2002). In agile organizations, however, product management and system verification still work according to the traditional development approach (Helena Holmstrom Olsson et al., 2012). Continuous integration (CI) This step relates to the establishment of practices that allow for frequent integration of work, daily builds, and fast commit of changes (e.g., automated builds and automated testing). At this point, both product development organization and test and verification organization work according to agile practices with short feedback cycles and continuous integration of work. Work is integrated frequently, leading to multiple integrations per day (Humble & Farley, 2011). Continuous deployment (CD) CD implies the continuous push out of changes to the code instead of doing large builds and having planned releases of large chunks of functionality. This allows for continuous customer feedback, the ability to learn from customer usage data, and to eliminate work that does not produce value for the customer. At this point, R&D, product management, and customers are all involved in a rapid, agile development cycle in which response time is short (Helena Holmstrom Olsson et al., 2012). R&D as an experiment system The final step in the “Stairway to Heaven” model relates to the ability of the organization to respond based on instant customer feedback, where actual deployment of software functionality is seen as a way of validating functionality. Customers are exposed to partial implementation of a functionality and the organization uses their feedback for determining the value of that particular functionality (Bosch, 2012). Olsson and Bosch state the following when organizations evolve from one step to another (Helena Holmström Olsson & Bosch, 2014): An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 94 - From Traditional to Agile R&D: requires a careful introduction of agile practices into the organization, a shift to small development teams, and a focus on features rather than components - From Agile to Continuous Integration: requires an automated test suite, a main branch to which code is continually delivered, and a modularized architecture - From Continuous Integration to Continuous Deployment: requires internal and external stakeholders to be fully involved and a proactive customer with whom to explore the concept - From Continuous Deployment to R&D as an “Innovation System”: requires careful ecosystem management in order to align internal business strategies with the dynamics of a competitive business ecosystem. Finally, a characteristic for all transitions is the critical alignment of internal and external processes in order to maximize the benefits as provided by the business ecosystem of which a company is part. A research conducted by Fitzgerald and Stol showed that software engineering has evolved with the adoption of agile practices and CI, Lean Startup and Lean Thinking approaches (Fitzgerald & Stol, 2017). They also discuss the need for a holistic approach that also refers the adoption of agile approaches in other organizational functions, like Enterprise Agility (Overby, Bharadwaj, & Sambamurthy, 2005) and Beyond Budgeting (Bogsnes, 2008). Finally, the approach is complemented by integrating development and operations (DevOps) (Loukides, 2012), and integrating business strategy and development (BizDev) (Fitzgerald & Stol, 2017). Hence, they propose a holistic approach encompassing all these concepts and emphasizing in CSE, called “Continuous ∗” (i.e. Continuous Star ) (Fitzgerald & Stol, 2017). Continuous ∗ considers the entire software life cycle, with three main subphases (Figure 38): Business Strategy & Planning, Development, and Operations. Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 95 Figure 38. Continuous* framework (Fitzgerald & Stol, 2017) Each activity from Continuous * is briefly explained: - Continuous planning: endeavor involving multiple stakeholders from business and software functions, where plans are dynamic open-ended artifacts that evolve in response to changes in the business environment; - Continuous budgeting: budgeting (organization’s investments, revenue and expense outlook) becomes a continuous activity to facilitate changes during the year; - Continuous integration: a typically automatically triggered process comprising interconnected steps such as compiling code, running unit and acceptance tests, validating code coverage, checking coding standard compliance and building deployment packages; - Continuous delivery: the practice of continuously deploying good software builds automatically to some environment, but not necessarily to actual users; - Continuous deployment: the practice of ensuring that the software is continuously ready for release and deployed to actual customers; An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 96 - Continuous verification: Adoption of verification activities including formal methods and inspections throughout the development process rather than relying on a testing phase towards the end of development; - Continuous testing: a process typically involving some automation of the testing process, or prioritization of test cases, to help reduce the time between the introduction of errors and their detection; - Continuous compliance: seeks to satisfy regulatory compliance standards on a continuous basis; - Continuous security: security being treated as a key concern throughout all phases of the development lifecycle and even post deployment, supported by a smart and lightweight approach to identifying security vulnerabilities; - Continuous evolution: technical debt is incurred when an architecture is unsuitable to facilitate new requirements; - Continuous use: Recognizes that the initial adoption versus continuous use of software decisions are based on different parameters, and that customer retention can be a more effective strategy than trying to attract new customers; - Continuous trust: Trust developed over time as a result of interactions based on the belief that a vendor will act cooperatively to fulfill customer expectations without exploiting their vulnerabilities; - Continuous run-time monitoring: run-time behaviors of all kinds must be monitored to enable early detection of quality-of-service problems, such as performance degradation, and also the fulfillment of service level agreements (SLAs); - Continuous improvement: Based on lean principles of data-driven decision-making and elimination of waste, which lead to small incremental quality improvements; - Continuous innovation: a sustainable process that is responsive to evolving market conditions and based on appropriate metrics across the entire lifecycle of planning, development and run-time operations; - Continuous experimentation: software development based on experiments with stakeholders consisting of repeated Build-Measure-Learn cycles. Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 97 Continuous Architecture Continuous Architecture (CA) is a set of principles and tools targeted at addressing the gap between the Agile delivery and architecture practices (Erder & Pureur, 2015). It brings together the work of the agile developer to start building and the enterprise architect that will look at a 5year plan. CA is the response required from the adoption of Continuous Delivery by software development teams. The main objective of Continuous Delivery is to respond quickly to business needs by frequently delivering high-quality software in rapid cycles. Unlike traditional software delivery approaches that emphasize the importance of delivering various documents such as requirements, architecture, and design specifications, the overall goal of Continuous Delivery is to produce production-quality software rapidly in an incremental manner. Instead of validating various artifacts produced as part of the Software Development Life Cycle (SDLC), quality is enforced by systematically testing the software components using automated tests (Erder & Pureur, 2015). Continuous architecting has a set of specific goals (Erder & Pureur, 2015): - To create an architecture that can evolve with applications, that is testable , that can respond to feedback and in fact is driven by feedback - To make Enterprise Architecture real - To make solution architecture sustainable - To create real world, actionable, useful strategies CA is characterized by the following principles (Erder & Pureur, 2015): 1. Architect Products – not solutions for Projects 2. Focus on Quality Attributes – not on Functional Requirements 3. Delay Design Decisions Until They Are Absolutely Necessary To Keep The Architecture Manageable 4. Leverage “The Power Of Small” To Architect For Change 5. Architect for Build, Test and Deploy To Deliver Capabilities Continuously 6. Model The Organization Of Your Teams After The Design Of The System To Promote Interoperability An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 98 As part of CA, especially within large-scale agile (LSA) settings, (Martini, Pareto, & Bosch, 2014) identifies the following practices: - Risk Management; - architectural decisions and changes; - Pattern Distillation; - communication of architecture: o providing architectural knowledge (communication output), o monitor the current status of the system (communication input); - Inter-features Architecting; - Architecting for Testability; - Controlling Erosion. The CA practices require focus in the architecture role, as well as in architecting tasks within developing and maintaining software architecture. Martini and Bosch present Continuous Architecting Framework For Embedded software and Agile (CAFFEA) (Martini, Pareto, & Bosch, 2015), an organizational framework oriented for architecture governance. The frameworks presents roles, challenges and tasks within architecture teams and governance teams viewpoints (Figure 39). Roles are described as belonging to the Architects and to the Team. The existing roles for Architects are Chief Architect, Governance Architect and Team Architect. Chief architects are responsible for the whole overall portfolio architecture, which might include more products and more than one system; Governance architects are responsible for areas of the architecture, related to single products or systems or sub-systems, but not related to only one team; and Team architects are usually most experienced developer in a team who have the most knowledge about the architecture and support/lead the team on such area (Martini et al., 2014). Within the Teams, within this framework they have roles responsible for coordination and cooperation practices, which are complementary to the typical agile (and feature-oriented) teams. Roles for Teams are Runway Team, Architecture Teams, Governances Teams. Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 99 Figure 39. The Continuous Architecting Framework For Embedded software and Agile (CAFFEA) (Martini et al., 2015) Architectural Management, Evolution, Change, and Debt The architecture is not static either during the project, after either the project ended (and the software is delivered and “in production”). Architectural changes as the architecture evolves, because of enhancement and maintenance requirements, are addressed as architecture management (Babar, 2013). Changes come in different flavours, such as redefining or adding requirements, changing infrastructure and technology, or causing changes by bugs and wrong decisions. to avoid design erosion, software architects need to embrace change by systematically alternating design activities with iterative architecture assessment and refactoring (Stal, 2014). Architecture maintenance is performed by architectural methods that support evaluation of developed features during cycles (Kanwal, Junaid, & Fahiem, 2010). At this point, the major concern is to accommodate the required changes without damaging the architectural integrity. Prior design decisions are reassessed for the potential impact of the required changes and new decisions are made (Babar, 2013). Any change that will influence the system’s safety requirements after we have finished the safety analysis and safety planning for development of safety-critical software will require a change impact analysis. Using agile development we may add new requirements, change existing An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 100 requirements and make current requirements more detailed both in the product backlog and in the Sprint backlogs (Stålhane, 2014). Change impact analysis (CIA) is important for software maintenance and is closely related to traceability in two ways (Stålhane, 2014): (1) From code to requirements – which requirements are affected if we change this code? This also gives us information on which tests that need to be re-run; (2) From requirements to code – what code must be changed if this requirement is changed? Steps in a typical impact analysis process are (Wiegers, 2014):  Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.  Determine whether the change is on the project’s critical path. If a task on the critical path slips, the project’s completion date will slip. Every change consumes resources, but if you can plan a change to avoid affecting tasks that are currently on the critical path, the change will not cause the entire project to slip.  Estimate the impact of the proposed change on the project’s schedule and cost.  Evaluate the change’s priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.  Report the impact analysis results to all stakeholders so that they can use the information to help them decide whether to approve or reject the change request. A change in a system may have effects that have to be determined, which leads to use CIA techniques (Arnold, 1996). In agile architecting, CIA is used in decision-making process of adding or changing features, focusing in affected dependencies with earlier design decisions, rationale, constraints, and risks (Pérez, Díaz, Garbajosa, & Yagüe, 2014). It is crucial to perform a CIA if the change affects an architecturally significant requirement (ASR) (L. Chen, Ali Babar, & Nuseibeh, 2013). ASRs are requirements that play an important role in determining the architecture of the system (Paul Clements & Bass, 2010). This concept mostly arose from the need to differentiate the quality requirements (i.e., non-functional requirements Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 107 Figure 43. Positioning the microservices tenets (Zimmermann, 2017) They enable companies to increase the deployment frequency of new releases as one crucial part within the Continuous Delivery (CD) pipeline (Armin Balalaie, Heydarnoori, & Jamshidi, 2016a; L. Chen, 2018; O’Connor, Elger, & Clarke, 2017). They affect the way teams are structured, source code is organized and continuously built/packed, and software products are continuously deployed (Familiar, 2015). There is some discussion about similarities and differences to SOA. Microservices are not entirely new, but qualify as “SOA done right”, comprising an organic implementation approach to SOA (Zimmermann, 2017). Common characteristics include business orientation, polyglot programming in multiple paradigms and languages, and design for failure; decentralization and automation are emphasized specifically in the microservices implementation approach. An important microservices property is that services can be deployed independently of each other, which requires services to communicate with each other via remoting protocols such as HTTP and asynchronous message queues (Zimmermann, 2017). Typically there are two types of patterns to define the required microservices (Richardson, 2018): decomposition by business capability or by domains. The second one is highly adopted (Newman, 2015; Pautasso, Zimmermann, Amundsen, Lewis, & Josuttis, 2017; Steinegger, Giessler, Hippchen, & Abeck, 2017), making use of DDD (Evans, 2004) approach. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 108 Independent of whether an MSA-based system is designed greenfield, i.e. , from scratch, or brownfield, i.e. , by decomposing a monolith, microservices need to be identified (Newman, 2015). There is not a common standard on modeling the architectures (Francesco, Malavolta, & Lago, 2017). In fact, ‘modeling’ is not highly considered in microservice-related research (Cerny, Donahoo, & Trnka, 2018), although its provided benefits in terms of abstraction, model transformation, code generation, modeling viewpoints and languages (Rademacher, Sorgalla, Wizenty, Sachweh, & Zündorf, 2018). There seems to be a tendency to use languages used to describe service-based architectures (Di Francesco, 2017) (SoaML, SOMA, SOADL, CAML, CloudML and StratusML), however UML is suitable to model services and operations as well (Alshuqayran, Ali, & Evans, 2016; Rademacher, Sachweh, & Zündorf, 2018a). Modeling approaches in SOA is more mature, namely for service design and interfaces, and their applicability in MSA have many similarities (Rademacher, Sachweh, & Zundorf, 2017). Modeling in MSA may be based in integrating API and SOA styles of service design and delivery, together with a service model that contains both styles of service and articulates their relationships (Z. Xiao, Wijegunaratne, & Qiang, 2016). Models may be used in different abstraction levels (OMG, 2003). In microservices, domain models are used when adopting DDD for identifying the services, where afterwards may be used additional models – intermediate and deployment – for specifying service interfaces, deployment, etc. (Rademacher, Sorgalla, & Sachweh, 2018). Additionally, these different models may be used within different languages, like UML for domains and SoaML for interfaces (Rademacher, Sorgalla, & Sachweh, 2018). Microservices modeling DDD is always the basis for defining a microservices architecture, allowing to decompose a problem in subdomains that a microservice may tackle, and also assuring the microservice complies with the Single Responsibility Principle (SRP) (Indrasiri & Siriwardena, 2018). Rademacher, Sachweh and Zündorf present a UML Profile for identifying microservices, namely when adopting DDD (Rademacher, Sachweh, & Zündorf, 2018b). Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 109 Figure 44. UML profile for microservices design (Rademacher, Sachweh, & Zündorf, 2018b) Kharbuja uses DDD for identifying bounded contexts within requirements modeled in Use Cases, defining steps to derive a domain model for a microservice, namely (Kharbuja, 2016):  Step 1: The initial analysis of the case study produces use case model  Step 2: For each use case, task trees are generated listing the functionalities needed to accomplish the desired goal of the respective use cases.  Step 3: The initial task trees created for each use case at Step 2 are analyzed. The tasks are categorized as are either functionally independent from their corresponding use cases or common in multiple use cases.  Step 4: The use case model obtained in Step 3 is analyzed again for further refactoring.  Step 5: The use cases obtained in step 4 are used to identify the service candidates. The final use cases obtained in Step 4 have appropriate level of granularity and cohesive functionalities. An example of a UML Use Case model usage for candidate service is depicted in Figure 45. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 110 Figure 45. Use Case Model for identification of service candidates (Kharbuja, 2016) Rademacher et al. present some patterns on modeling microservices domains using DDD (Rademacher, Sorgalla, & Sachweh, 2018). Figure 46 depicts DDD modeling patterns for microservice design, using UML notation. Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 111 Figure 46. DDD patterns for domain-driven microservice design (Rademacher, Sorgalla, & Sachweh, 2018) The Extended Increment Architecture approach (Zúñiga-Prieto, Insfran, & Abrahao, 2016) lengthens the SoaML metamodel in order to handle microservices architecture design. Within this approach, a Participant may refer to: (i) a microservice to be integrated; (ii) a microservice/component already existing in the current architecture with which the microservice(s) to be integrated will interoperate; and (iii) a microservice/component to be created in order to consume microservice services or provide it with services. In addition, the Services Architecture diagram allows depicting how An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 112 parts of a microservice work together to play the owning microservice role(s). Finally, a reference to a Service Contract that describes interoperation among Participants is described, as well as the integration logic. In order to allow these languages properly address microservice specific characteristics (mainly in comparison to SOA), some model-driven development (MDD) works propose metamodels that enable microservices architectures modeling (Düllmann & Van Hoorn, 2017; Rademacher, Sorgalla, Sachweh, & Zündorf, 2018), allowing to instantiate data, service and operations of microservices. The DDD application can be enriched by defining semantics in OWL (Diepenbrock, Rademacher, & Sachweh, 2017). An agile approach for service design and service engineering relies on early understanding of user needs and service touchpoints for rapid adaptation to emerging user needs (Berre, 2012). Model-based development approaches, properly combined with agile practices, are useful for service design and engineering, relating value models, process models, user interface and interaction flow models, and service architectures and service contract models (Berre, 2012). Defining service boundaries Decomposing an existing monolith to microservices has many challenges (Di Francesco, 2017; D Taibi, Lenarduzzi, Pahl, & Janes, 2017). Typically, the decomposition starts by developing services for a given business process (Lenarduzzi & Taibi, 2018), making use of simplified microservices patterns (Davide Taibi et al., 2017; Davide Taibi, Lenarduzzi, & Pahl, 2018). These patterns are used until the architectures emerges to a complexity that requires new decisions DDD approach, on data driven as the database-is-the-service pattern (Messina, Rizzo, Storniolo, Tripiciano, & Urso, 2016), on approaches as SMART (G. Lewis, Morris, Simanta, Smith, & Wrage, 2007) or ENTICE (Kecskemeti & Marosi, 2016), etc. Some works have researched on how to extract these services from monoliths (Gysel, Kölbener, Giersche, & Zimmermann, 2016; Mazlami, Cito, & Leitner, 2017; Quiroz, Kim, Parashar, Gnanasambandam, & Sharma, 2009). Decomposing into microservices have impact on the source code, but concerns like multi-tenancy, statefulness and data consistency must be taken in consideration (Furda, Fidge, Zimmermann, Kelly, & Barros, 2018), while a new infrastructure may be developed (Armin Balalaie et al., 2016a). Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 113 These works have followed the microservices architectures as they have evolved in complexity, starting by deploying the individual services in lightweight container technologies, then introducing discovery services and reusable fault-tolerant communication libraries, service proxies, or sidecars, and ultimately serverless architectures (Jamshidi, Pahl, Mendonca, Lewis, & Tilkov, 2018), usually guided by the reference proposal in (Yale Yu, Silveira, & Sundaram, 2016). Microservices patterns Although recent, developing microservices has had such good acceptance that some patterns have been already identified. Taibi, Lenarduzzi and Pahl described architectural patterns categorized by Orchestration and Coordination, Deployment, Data (Davide Taibi et al., 2018). Issues such as data consistency, security, communication, deployment, and other patterns (Krause, 2014; Namiot & Sneps-Sneppe, 2014; Richardson, 2018; Davide Taibi et al., 2018) have also been addressed. The patterns from these works often overlap, so for simplicity reasons, further it is presented a set of widely accepted microservices patterns, proposed by Richardson (Richardson, 2018) (Figure 47). The patterns are classified in: (1) Application patterns; (2) Application Infrastructure patterns; and (3) Infrastructure patterns. Additionally, the patterns are divided, following a division structure as listed in Table 10. This pattern catalogue prescribe a set of development approaches for MSA projects. Inside each category, patterns may be exclusive, complimentary or dependent between them. It is thus possible to depict how a MSA project development process may be organized. Any migration of an application’s architecture to microservices brings challenges that make this migration a non-trivial task. Balalaie, Herdarnoori and Jamshidi proposed migration steps, after analyzing the architecture before the migration and the target architecture (A Balalaie, Heydarnoori, Jamshidi, Tamburri, & Lynn, 2015). Migrating the system towards the target architecture should be done incrementally and in several steps without affecting the end-users of the system. Furthermore, as the number of services is growing, there is a need of a mechanism for automating the delivery process. By describing an experience report of their migration process, a set of migration steps may be generalized as follows (Armin Balalaie, Heydarnoori, & Jamshidi, 2016b): An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 114  Preparing the Continuous Integration Pipeline;  Expose legacy functionalities as a REST API;  Introducing Continuous Delivery practices (e.g., separate the source code, the configuration, and the environment specification);  Introducing Edge Server (minimize the impact of internal changes on end-users);  Introducing Dynamic Service Collaboration (Service Discovery, Load Balancer and Circuit Breaker);  Introducing the Resource Manager;  Introducing additional services to complete the target architecture;  Clusterization. Figure 47. Microservices architecture patterns 5 Driven by the common “alliance” between DevOps culture and microservices architectures, these authors also include the following cross-cutting steps for these migrations (Armin Balalaie et al., 2016a):  Filling the Gap Between the Dev and Ops via Continuous Monitoring;  Changing Team Structures (small cross-functional teams for each new service constructed). 5 List of patterns from http://microservices.io/patterns/index.html, accessed in 28/08/2017 Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 115 Table 10. Microservices patterns and categories Core patterns Decomposition Security UI patterns  Monolithic architecture  Microservice architecture  Decompose by business capability  Decompose by subdomain  Access Token  Server-side page fragment composition  Client-side UI composition Cross cutting concerns Testing Observability Deployment patterns  Microservice chassis  Externalized configuration  Service Component Test  Consumer-driven contract test  Consumer-side contract test  Log aggregation  Application metrics  Audit logging  Distributed tracing  Exception tracking  Health check API  Log deployments and changes  Multiple service instances per host  Service instance per host  Service instance per VM  Service instance per Container  Serverless Deployment  Service Deployment platform Data management Communication Database architecture Maintaining data consistency Communication style Service discovery  Database per Service  Shared database  Saga  Event sourcing  Domain event  Agregate  Remote Procedure Invocation  Messaging  Domain-specific protocol  Client-side discovery  Server-side discovery  Service registry  Self registration  3rd party registration Querying Reliability External API Transactional messaging  API Composition  CQRS  Circuit Breaker  API gateway  Backend for front-end  Transactional outbox  Transaction log tailing  Polling publisher These steps were afterwards introduced as migration patterns, as depicted in Table 11. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 116 Table 11. Microservices migration patterns (Armin Balalaie et al., 2016a) Pattern name Enable the Continuous Integration Recover the Current Architecture Decompose the Monolith Decompose the Monolith Based on Data Ownership Change Code Dependency to Service Call Introduce Service Discovery Introduce Service Discovery Client Introduce Internal Load Balancer Introduce External Load Balancer Introduce Circuit Breaker Introduce Configuration Server Introduce Edge Server Containerize the Services Deploy into a Cluster and Orchestrate Containers Monitor the System and Provide Feedback Along with adopting patterns, also bad practices (architectural bad smells) are identified (Davide Taibi & Lenarduzzi, 2018). Splitting a monolith, including splitting the connected data and libraries, is the most critical issue, resulting in potential maintenance issues when the cuts are not done properly. Moreover, the conversion to a distributed system increases the system’s complexity, especially when dealing with connected services that need to be highly decoupled from any point of view, including communication and architecture (namely Hard-Coded Endpoints, Not Having an API Gateway, Inappropriate Service Intimacy, and Cyclic Dependency) (Davide Taibi & Lenarduzzi, 2018). The list of bad smells presented by Taibi and Lenarduzzi is depicted in Table 12. Table 12. List of microservices bad smells (Davide Taibi & Lenarduzzi, 2018) Microservices bad smells API Versioning Hard-Coded Endpoints Not Having an API Gateway Too Many Standards Cyclic Dependency Inappropriate Service Intimacy Shared Libraries Wrong Cuts ESB Usage Microservice Greedy Shared Persistency 3.5. Conclusions This chapter addressed the architecture design discipline, in terms of its lifecycle, the evolutionary design and the architecting as a continuous practice. The works presented in Section 3.2 propose different inputs, target-users and viewpoints of architectures at each stage of the software development life cycle (SDLC). This has also led to proposals for proper usage of specific architecture methods depending on the stage of the SDLC. Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 123 Jamshidi, P., Pahl, C., Mendonca, N. C., Lewis, J., & Tilkov, S. (2018). Microservices: The Journey So Far and Challenges Ahead. IEEE Software , 35(3), 24–35. https://doi.org/10.1109/MS.2018.2141039 Jeston, J., & Nelis, J. (2008). Business process management : practical guidelines to successful implementations . Elsevier/Butterworth-Heinemann. Kang, K. C., Kim, S., Lee, J., Kim, K., Shin, E., & Huh, M. (1998). FORM: A feature-oriented reuse method with domain-specific reference architectures. Annals of Software Engineering . Kanwal, F., Junaid, K., & Fahiem, M. A. (2010). A hybrid software architecture evaluation method for fdd-an agile process model. In International Conference on Computational Intelligence and Software Engineering (CiSE) (pp. 1–5). IEEE. https://doi.org/10.1109/CISE.2010.5676863 Kazman, R., Nord, R., & Klein, M. (2003). A life-cycle view of architecture analysis and design methods . Retrieved from http://www.dtic.mil/docs/citations/ADA421679 Kecskemeti, G., & Marosi, A. (2016). The ENTICE approach to decompose monolithic services into microservices. In International Conference on High Performance Computing & Simulation (HPCS) (pp. 591–596). IEEE. https://doi.org/10.1109/HPCSim.2016.7568389 Kerievsky, J. (2016). An Introduction to Modern Agile . Kharbuja, R. (2016). Designing a Business Platform using Microservices . Technische Universität München. Kirikova, M. (2017). Continuous Requirements Engineering. In International Conference on Computer Systems and Technologies - CompSysTech’17 . Ruse, Bulgaria: ACM. https://doi.org/https://doi.org/10.1145/3134302.3134304 Kohavi, R., & Longbotham, R. (2017). Online Controlled Experiments and A/B Tests. In Encyclopedia of machine learning and data mining (pp. 922–929). Springer US. Krause, L. (2014). Microservices: Patterns and Applications - Designing Fine-grained Services by Applying Patterns . microservicesbook.io. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 124 Kruchten, P. (1995). The 4+1 View Model of Architecture. IEEE Software , 12(6), 42–50. https://doi.org/10.1109/52.469759 Kruchten, P., Nord, R. L., & Ozkaya, I. (2012). Technical Debt: From Metaphor to Theory and Practice. IEEE Software , 29(6), 18–21. https://doi.org/10.1109/MS.2012.167 Lankhorst, M. (2009). Enterprise Architecture at Work: Modelling, Communication and Analysis. The Enterprise Engineering Series. Springer. Lenarduzzi, V., & Taibi, D. (2018). Microservices, Continuous Architecture, and Technical Debt Interest: An Empirical Study. In 44th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) . Prague, Czech republic: IEEE. Lewis, G., Morris, E., Simanta, S., Smith, D., & Wrage, L. (2007). SMART: Analyzing the Reuse Potential of Legacy Components in a Service-Oriented Architecture Environment. In AIAA Infotech@Aerospace 2007 Conference and Exhibit . Reston, Virigina: American Institute of Aeronautics and Astronautics. https://doi.org/10.2514/6.2007-2865 Lewis, J., & Fowler, M. (2014). Microservices: a definition of this new architectural term . Retrieved March 24, 2017, from https://martinfowler.com/articles/microservices.html Loukides, M. (2012). What is DevOps? Martini, A., Besker, T., & Bosch, J. (2018). Technical Debt tracking: Current state of practice: A survey and multiple case study in 15 large organizations. Science of Computer Programming , 163, 42–61. https://doi.org/10.1016/J.SCICO.2018.03.007 Martini, A., Pareto, L., & Bosch, J. (2014). Role of Architects in Agile Organizations. In J. Bosch (Ed.), Continuous Software Engineering . Springer Cham. Martini, A., Pareto, L., & Bosch, J. (2015). Towards Introducing Agile Architecting in Large Companies: The CAFFEA Framework. In Agile Processes in Software Engineering and Extreme Programming. Proceedings of the International Conference on Agile Software Development (XP2015) (pp. 218–223). Springer, Cham. https://doi.org/10.1007/978-3-319-18612-2_20 Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 125 Matinlassi, M., Niemelä, E., & Dobrica, L. (2002). Quality-driven architecture design and quality analysis method, A revolutionary initiation approach to a product line architecture . VTT Technical Research Centre of Finland. Mazlami, G., Cito, J., & Leitner, P. (2017). Extraction of Microservices from Monolithic Software Architectures. In 2017 IEEE International Conference on Web Services (ICWS) (pp. 524–531). IEEE. https://doi.org/10.1109/ICWS.2017.61 Messina, A., Rizzo, R., Storniolo, P., Tripiciano, M., & Urso, A. (2016). The Database-is-theService Pattern for Microservice Architectures. In International Conference on Information Technology in Bioand Medical Informatics (ITBAM) (pp. 223–233). Springer, Cham. https://doi.org/10.1007/978-3-319-43949-5_18 Nadareishvili, I., Mitra, R., McLarty, M., & Amundsen, M. (2016). Microservice Architecture: Aligning Principles, Practices, and Culture . O’Reilly. Namiot, D., & Sneps-Sneppe, M. (2014). On micro-services architecture. International Journal of Open Information Technologies , 2(9), 24–27. Newman, S. (2015). Building microservices - Designing fine-grained systems . O’Reilly Media, Inc. Novack, J. (2016). Shu Ha Ri: An Agile Adoption Pattern . SolutionsIQ. O’Connor, R. V., Elger, P., & Clarke, P. M. (2017). Continuous software engineering-A microservices architecture perspective. Journal of Software: Evolution and Process , 29(11), e1866. https://doi.org/10.1002/smr.1866 Olsson, H. H., Alahyari, H., & Bosch, J. (2012). Climbing the “Stairway to Heaven” -- A Multiple-Case Study Exploring Barriers in the Transition from Agile Development towards Continuous Deployment of Software. In 38th Euromicro Conference on Software Engineering and Advanced Applications (pp. 392–399). IEEE. https://doi.org/10.1109/SEAA.2012.54 Olsson, H. H., & Bosch, J. (2014). Climbing the “Stairway to Heaven”: Evolving From Agile Development to Continuous Deployment of Software. In J. Bosch (Ed.), Continuous Software An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 126 Engineering (pp. 15–27). Cham: Springer International Publishing. https://doi.org/10.1007/978-3-319-11283-1_2 OMG. (2003). MDA Guide Version 1.0.1 . Object Management Group. Overby, E., Bharadwaj, A., & Sambamurthy, V. (2005). A Framework for Enterprise Agility and the Enabling Role of Digital Options. In Business Agility and Information Technology Diffusion. IFIP International Working Conference on Business Agility and Information Technology Diffusion (TDIT 2005) (pp. 295–312). Boston: Springer. https://doi.org/10.1007/0-387-25590-7_19 Pahl, C., & Jamshidi, P. (2016). Microservices: A Systematic Mapping Study. In 6th International Conference on Cloud Computing and Services Science (CLOSER) (Vol. 1, pp. 137– 146). SCITEPRESS - Science and and Technology Publications. https://doi.org/10.5220/0005785501370146 Pautasso, C., Zimmermann, O., Amundsen, M., Lewis, J., & Josuttis, N. (2017). Microservices in Practice, Part 1: Reality Check and Service Design. IEEE Software , 34(1), 91–98. https://doi.org/10.1109/MS.2017.24 Pérez, J., Díaz, J., Garbajosa, J., & Yagüe, A. (2014). Bridging User Stories and Software Architecture: A Tailored Scrum for Agile Architecting. In A. W. . Ali Babar, Muhammad ; Brown & I. Mistrik (Eds.), Agile Software Architecture - Aligning Agile Processes and Software Architectures (pp. 215–241). Morgan Kaufmann. https://doi.org/10.1016/B978-0-12-407772-0.00008-3 Pohl, K. (2010). Requirements Engineering . Springer. Quiroz, A., Kim, H., Parashar, M., Gnanasambandam, N., & Sharma, N. (2009). Towards autonomic workload provisioning for enterprise Grids and clouds. In 2009 10th IEEE/ACM International Conference on Grid Computing (pp. 50–57). IEEE. https://doi.org/10.1109/GRID.2009.5353066 Rademacher, F., Sachweh, S., & Zundorf, A. (2017). Differences between Model-Driven Development of Service-Oriented and Microservice Architecture. In IEEE International Conference on Software Architecture Workshops (ICSAW) (pp. 38–45). IEEE. https://doi.org/10.1109/ICSAW.2017.32 Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 127 Rademacher, F., Sachweh, S., & Zündorf, A. (2018a). Analysis of Service-oriented Modeling Approaches for Viewpoint-specific Model-driven Development of Microservice Architecture . ArXiv Preprint ArXiv:1804.09946. Rademacher, F., Sachweh, S., & Zündorf, A. (2018b). Towards a UML Profile for DomainDriven Design of Microservice Architectures. In Software Engineering and Formal Methods (pp. 230–245). Springer. https://doi.org/10.1007/978-3-319-74781-1_17 Rademacher, F., Sorgalla, J., & Sachweh, S. (2018). Challenges of Domain-Driven Microservice Design: A Model-Driven Perspective. IEEE Software , 35(3), 36–43. https://doi.org/10.1109/MS.2018.2141028 Rademacher, F., Sorgalla, J., Sachweh, S., & Zündorf, A. (2018). Towards a Viewpoint-specific Metamodel for Model-driven Development of Microservice Architecture . Rademacher, F., Sorgalla, J., Wizenty, P. N., Sachweh, S., & Zündorf, A. (2018). Microservice Architecture and Model-driven Development: Yet Singles, Soon Married (?). In Second International Workshop on Microservices: Agile and DevOps Experience (MADE18) collocated with XP18 . Porto, Portugal: ACM. Reddy, A., Govindarajulu, P., & Naidu, M. (2007). A Process Model for Software Architecture. International Journal of Computer Science and Network Security , 7(4), 272–280. Richardson, C. (2018). Microservice Patterns (1st ed.) . Manning. Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses . Crown Books. Rozanski, N., & Woods, E. (2005). Software systems architecture : working with stakeholders using viewpoints and perspectives . Addison-Wesley. Sommerville, I. (2007). Software Engineering . London: Pearson/Addison Wesley. Soni, D., Nord, R. L., & Hofmeister, C. (1995). Software architecture in industrial applications. In Proceedings of the 17th international conference on Software engineering - ICSE ’95 (pp. 196–207). New York, New York, USA: ACM Press. https://doi.org/10.1145/225014.225033 An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 128 Sowa, J. F., & Zachman, J. A. (1992). Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3), 590–616. Stal, M. (2014). Refactoring Software Architectures. In Agile Software Architecture - Aligning Agile Processes and Software Architectures . Elsevier Inc. Stålhane, T. (2014). Change Impact Analysis in Agile Development . Steinegger, R. H., Giessler, P., Hippchen, B., & Abeck, S. (2017). Overview of a DomainDriven Design Approach to Build Microservice-Based Applications. In Third International Conference on Advances and Trends in Software Engineering (SOFTENG’17) . IARIA. Taibi, D., & Lenarduzzi, V. (2018). On the Definition of Microservice Bad Smells. IEEE Software , 35(3), 56–62. https://doi.org/10.1109/MS.2018.2141031 Taibi, D., Lenarduzzi, V., & Pahl, C. (2017). Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation. I EEE Cloud Computing , 4(5), 22–32. https://doi.org/10.1109/MCC.2017.4250931 Taibi, D., Lenarduzzi, V., & Pahl, C. (2018). Architectural Patterns for Microservices: A Systematic Mapping Study. In Int.Conference on Cloud Computing and Services Science, CLOSER . INSTICC. Taibi, D., Lenarduzzi, V., Pahl, C., & Janes, A. (2017). Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages. In P roceedings of the XP2017 Scientific Workshops (p. 23). ACM. Thönes, J. (2015). Microservices. IEEE Software , 32(1), 116–116. https://doi.org/10.1109/MS.2015.11 Tom, E., Aurum, A., & Vidgen, R. (2013). An exploration of technical debt. Journal of Systems and Software , 86(6), 1498–1516. https://doi.org/10.1016/J.JSS.2012.12.052 UML, O. M. G. (2011). 2.4. 1 superstructure specification. document formal/2011-08-06 . Technical report, OMG. Chapter 3 – Logical Architectures within Agile and “Continuous” Approaches 129 Urbaczewski, L., & Mrdalj, S. (2006). A comparison of enterprise architecture frameworks. Issues in Informations Systems , 7(2), 18–23. Weiss, D. M. (1999). Software Product-Line Engineering: A Family-Based Software Development Process . Addison-Wesley Professional. Wiegers, K. (2014). Best Practices for Change Impact Analysis | Jama Software. Retrieved December 4, 2018, from https://www.jamasoftware.com/blog/change-impact-analysis-2/ Wiggins, A. (2012). The Twelve-Factor App . https://12factor.net. Winter, R., & Fischer, R. (2006). Essential Layers, Artifacts, and Dependencies of Enterprise Architecture. 10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW) . Xiao, L., Cai, Y., Kazman, R., Mo, R., & Feng, Q. (2016). Identifying and quantifying architectural debt. In Proceedings of the 38th International Conference on Software Engineering - ICSE ’16 (pp. 488–498). New York, New York, USA: ACM Press. https://doi.org/10.1145/2884781.2884822 Xiao, Z., Wijegunaratne, I., & Qiang, X. (2016). Reflections on SOA and Microservices. In 2016 4th International Conference on Enterprise Systems (ES) (pp. 60–67). IEEE. https://doi.org/10.1109/ES.2016.14 Yale Yu, Silveira, H., & Sundaram, M. (2016). A microservice based reference architecture model in the context of enterprise architecture. In 2016 IEEE Advanced Information Management, Communicates, Electronic and Automation Control Conference (IMCEC) (pp. 1856–1860). IEEE. https://doi.org/10.1109/IMCEC.2016.7867539 Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal , 26(3), 276–292. Zachman, J. A. (2011). The Zachman Framework for Enterprise Architecture . Zimmermann, O. (2017). Microservices tenets. Computer Science-Research and Development . Retrieved from https://link.springer.com/article/10.1007/s00450-016-0337-0 An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 130 Zúñiga-Prieto, M., Insfran, E., & Abrahao, S. (2016). Incremental Integration of Microservices in Cloud Applications. In 25th Int. Conf. on Information Systems Development (ISD2016). Retrieved from http://aisel.aisnet.org/isd2014/proceedings2016/ISDMethodologies/8/ Zwegers, A. J. R. (1998). On systems architecting : a study in shop floor control to determine architecting concepts and principles . Technische Universiteit Eindhoven. 131 PART III CONTRIBUTIONS Chapter 4 – Agile Requirements Modeling Approach for Agile Settings 132 Chapter 4 - A Requirements Modeling Approach for Agile Settings Chapter 4 - A Requirements Modeling Approach for Agile Settings………………133 4.1. Introduction……………………………………………………………133 4.2. Upfront Modeling in ASD projects……………………………..……..136 Deriving a Use case-driven Product Backlogs……………..………136 Deriving a User story-driven Product Backlog………………...…..139 4.3. Agile logical architecting with the 4SRS method……………………..141 The Decomposing User Agile Requirements arTEfacts (DUARTE) approach…………..……………………...…...……………………144 “Just-Enough” modeling…………………………..…………….…148 4.4. Demonstration cases…………………………………………………..151 Upfront RE for use case-driven product backlogs: the iFloW case151 Upfront RE for user stories-driven product backlogs: the ISOFIN Cloud …………………………154 Emerging RE using DUARTE: the UH4SP case-………………..157 Discussion……………………………………….……………….163 4.5. Conclusions……………………………………………………………166 Further Reading………………………………………………………………....167 References………………………………………………………………………167 This chapter discusses requirements engineering (RE) in ASD processes, addressing the necessary information as stakeholders communicates their business needs or their “ minimum viable product ” (MVP). Thus, this chapter introduces both upfront and emerging approaches for RE. Regarding the latter, an approach called “ Decomposing User Agile Requirements ArTEfacts ” (DUARTE) is proposed. Both RE approaches are evaluated and discussed using three demonstration cases, two for upfront modeling and one applying DUARTE approach. This chapter ends with the conclusions. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 235 References Abrahamsson, P., Babar, M. A., & Kruchten, P. (2010). Agility and architecture: Can they coexist? IEEE Software , 27 (2), 16–22. https://doi.org/10.1109/MS.2010.36 Ali Babar, M., Brown, A. W., & Mistrík, I. (2014). Agile Software Architecture: Aligning Agile Processes and Software Architectures . Elsevier. Azevedo, S., Machado, R. J., Muthig, D., & Ribeiro, H. (2009). Refinement of Software Product Line Architectures through Recursive Modeling Techniques . (R. Meersman, P. Herrero, & T. Dillon, Eds.), On the Move to Meaningful Internet Systems: OTM 2009 Workshops . Springer Berlin / Heidelberg. https://doi.org/10.1007/978-3-642-05290-3_53 Azevedo, S., Machado, R., & Maciel, R. (2012). On the Use of Model Transformations for the Automation of the 4SRS Transition Method. In M. Bajec & J. Eder (Eds.), Advanced Information Systems Engineering Workshops (Vol. 112, pp. 249–264). Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-31069-0_22 Beck, K., & Andres, C. (2004). Extreme programming explained: embrace change . AddisonWesley Professional. Bragança, A., & Machado, R. (2007). Automating mappings between use case diagrams and feature models for software product lines. Software Product Line Conference, … . Bragança, A., & Machado, R. (2009). A model-driven approach for the derivation of architectural requirements of software product lines. Innovations in Systems and Software Engineering , 5 (1), 65–78. https://doi.org/10.1007/s11334-009-0078-3 Bragança, A., & Machado, R. J. (2005). Deriving Software Product Line’s Architectural Requirements from Use Cases: An Experimental Approach. In 2nd International Workshop on Model-Based Methodologies for Pervasive and Embedded Software (MOMPES’05) . Rennes, France. Cockburn, A. (2006). Agile software development: the cooperative game . Pearson Education. Conway, M. E. (1968). How Do Committees Invent? Datamation, 28–31. Coplien, J. O., & Bjørnvig, G. (2011). Lean architecture: for agile software development . John Wiley & Sons. Chapter 5 – Agile Logical Architecting using AMPLA 236 Cruz, E., Machado, R., & Santos, M. (2014). From business process models to use case models: A systematic approach. Advances in Enterprise Engineering … . Retrieved from http://link.springer.com/chapter/10.1007/978-3-319-06505-2_12 Díaz, J., Pérez, J., & Garbajosa, J. (2014). Agile product-line architecting in practice: A case study in smart grids. Information and Software Technology , 56 (7), 727–748. https://doi.org/10.1016/j.infsof.2014.01.014 Douglass, B. (1999). Doing hard time: developing real-time systems with UML, objects, frameworks, and patterns . Addison-Wesley Professional. Erder, M., & Pureur, P. (2015). Continuous architecture: Sustainable architecture in an agile and cloud-centric world. Erdogmus, H. (2009). Architecture meets agility. IEEE Software , 26 (5), 2–4. https://doi.org/10.1109/MS.2009.121 Evans, E. (2004). Domain-driven design : tackling complexity in the heart of software. AddisonWesley Farhan, S., Tauseef, H., & Fahiem, M. A. (2009). Adding agility to architecture tradeoff analysis method for mapping on crystal. In WRI World Congress on Software Engineering (WCSE’09) - Volume 04 (Vol. 4, pp. 121–125). IEEE. https://doi.org/10.1109/WCSE.2009.405 Fernandes, J. M., & Machado, R. J. (2016). Requirements in Engineering Projects . Cham: Springer International Publishing. https://doi.org/10.1007/978-3-319-18597-2 Fernandes, J. M., Machado, R. J., Monteiro, P., & Rodrigues, H. (2006). A Demonstration Case on the Transformation of Software Architectures for Service Specification. In B. Kleinjohann, L. Kleinjohann, R. Machado, C. Pereira, & P. S. Thiagarajan (Eds.), From Model-Driven Design to Resource Management for Distributed Embedded Systems (Vol. 225, pp. 235– 244). Springer US. https://doi.org/10.1007/978-0-387-39362-9_25 Ferreira, N., Santos, N., Machado, R., Fernandes, J. E., & Gasević, D. (2014). A V-Model Approach for Business Process Requirements Elicitation in Cloud Design. In A. Bouguettaya, Q. Z. Sheng, & F. Daniel (Eds.), Advanced Web Services (pp. 551–578). Springer New York. https://doi.org/10.1007/978-1-4614-7535-4_23 Ferreira, N., Santos, N., Machado, R. J., & Gasevic, D. (2012). Derivation of Process-Oriented An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 237 Logical Architectures: An Elicitation Approach for Cloud Design. (A. J. O. Dieste and N. Juristo, Ed.), 13th International Conference on Product-Focused Software Development and Process Improvement - PROFES 2012 . Madrid, Spain: Springer-Verlag, Berlin Heidelberg, Germany . Fitzgerald, B., & Stol, K.-J. (2017). Continuous software engineering: A roadmap and agenda. Journal of Systems and Software , 123 , 176–189. https://doi.org/10.1016/J.JSS.2015.06.063 Fowler, M. (2018). Refactoring: improving the design of existing code (2nd edition) . AddisonWesley Professional. George, M. L., & George, M. (2003). Lean six sigma for service . New York, NY: McGraw-Hill. Harvick, R. (2012). Agile Architecture for Service Oriented Component Driven Enterprises: Encouraging Rapid Application Development using Agile . DataThunder Publishing. Retrieved from http://dl.acm.org/citation.cfm?id=2331400 Indrasiri, K., & Siriwardena, P. (2018). Microservices for the enterprise: Designing, Developing, and Deploying . Apress. Jeon, S., Han, M., Lee, E., & Lee, K. (2011). Quality attribute driven agile development. In 9th International Conference on Software Engineering Research, Management and Applications (SERA) (pp. 203–210). IEEE. https://doi.org/10.1109/SERA.2011.24 Kanwal, F., Junaid, K., & Fahiem, M. A. (2010). A hybrid software architecture evaluation method for fdd-an agile process model. In International Conference on Computational Intelligence and Software Engineering (CiSE) (pp. 1–5). IEEE. https://doi.org/10.1109/CISE.2010.5676863 Kazman, R. (2013). Foreword - Bringing the Two Together: Agile Architecting or Architecting for Agile? In Agile Software Architecture: Aligning Agile Processes and Software Architectures (pp. xxix–xxx). Elsevier. Kruchten, P. (1995). The 4+1 View Model of Architecture. IEEE Software , 12 (6), 42–50. https://doi.org/10.1109/52.469759 Loukides, M. (2012). What is DevOps? Chapter 5 – Agile Logical Architecting using AMPLA 238 Machado, R. J. (2002). Heterogeneous Information Systems Integration: Organizations and Methodologies. In Springer (Ed.), 4th International Conference on Product Focused Software Process Improvement - PROFES’02 . Rovaniemi, Finland. Machado, R. J., Fernandes, J. M., Monteiro, P., & Rodrigues, H. (2005). Transformation of UML Models for Service-Oriented Software Architectures. Proceedings of the 12th IEEE International Conference and Workshops on Engineering of Computer-Based Systems . IEEE Computer Society. https://doi.org/http://dx.doi.org/10.1109/ECBS.2005.73 Machado, R. J., Fernandes, J., Monteiro, P., & Rodrigues, H. (2006). Refinement of Software Architectures by Recursive Model Transformations. (J. Münch & M. Vierimaa, Eds.), Product-Focused Software Process Improvement . Springer Berlin / Heidelberg. https://doi.org/10.1007/11767718_38 Madison, J. (2010). Agile architecture interactions. IEEE Software , 27 (2), 41–48. https://doi.org/10.1109/MS.2010.35 Mancl, D., Fraser, S., Opdyke, B., Hadar, E., & Hadar, I. (2009). Architecture in an agile world. Proceedings of the 24th ACM SIGPLAN Conference Companion on Object Oriented Programming Systems Languages and Applications . Orlando, Florida, USA: ACM. https://doi.org/10.1145/1639950.1639981 Martini, A., Pareto, L., & Bosch, J. (2014). Role of Architects in Agile Organizations. In J. Bosch (Ed.), Continuous Software Engineering . Springer Cham. Moser, R., Abrahamsson, P., Pedrycz, W., Sillitti, A., & Succi, G. (2008). A Case Study on the Impact of Refactoring on Quality and Productivity in an Agile Team. In IFIP Central and East European Conference on Software Engineering Techniques (pp. 252–266). Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-540-85279-7_20 Neiva, R., Santos, N., Martins, J. C. C., & Machado, R. J. (2015). Deriving UML logical architectures of traceability business processes based on a GS1 standard . Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) (Vol. 9158). https://doi.org/10.1007/978-3-319-21410-8_41 Newman, S. (2015). Building microservices - Designing fine-grained systems . O’Reilly Media, Inc. Nord, R. L., & Tomayko, J. E. (2006). Software architecture-centric methods and agile An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 239 development. IEEE Software , 23 (2), 47–53. https://doi.org/10.1109/MS.2006.54 OMG. (2012). Service Oriented Architecture Modeling LanguageTM (SoaML®). http://www.omg.org/spec/SoaML/. Pahl, C., & Jamshidi, P. (2016). Microservices: A Systematic Mapping Study. In 6th International Conference on Cloud Computing and Services Science (CLOSER) (Vol. 1, pp. 137–146). SCITEPRESS - Science and and Technology Publications. https://doi.org/10.5220/0005785501370146 Pérez, J., Díaz, J., Garbajosa, J., & Yagüe, A. (2014). Bridging User Stories and Software Architecture: A Tailored Scrum for Agile Architecting. In A. W. . Ali Babar, Muhammad ; Brown & I. Mistrik (Eds.), Agile Software Architecture - Aligning Agile Processes and Software Architectures (pp. 215–241). Morgan Kaufmann. https://doi.org/10.1016/B9780-12-407772-0.00008-3 Richardson, C. (2018). Microservice Patterns (1st ed.). Manning. Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses . Crown Books. Salgado, C. E., Teixeira, J., Santos, N., Machado, R. J., & Maciel, R. S. P. (2015). A SoaML Approach for Derivation of a Process-Oriented Logical Architecture from Use Cases. Exploring Services Science , 80–94. Retrieved from http://link.springer.com/chapter/10.1007/978-3-319-14980-6_7 Santos, M. Y., & Machado, R. J. (2010). On the Derivation of Class Diagrams from Use Cases and Logical Software Architectures. In 2010 Fifth International Conference on Software Engineering Advances (Vol. 0, pp. 107–113). Nice, France: IEEE. Retrieved from http://doi.ieeecomputersociety.org/10.1109/ICSEA.2010.24 Santos, N., Duarte, F. J., Machado, R. J., & Fernandes, J. M. (2013). A transformation of business process models into software-executable models using MDA . Lecture Notes in Business Information Processing (Vol. 133 LNBIP). https://doi.org/10.1007/978-3-64235702-2_10 Schwaber, K. (1997). Scrum development process. In Business Object Design and Implementation (pp. 117–134). Springer. https://doi.org/10.1007/978-1-4471-0947- Chapter 5 – Agile Logical Architecting using AMPLA 240 1_11 Sharifloo, A. A., Saffarian, A. S., & Shams, F. (2008). Embedding architectural practices into Extreme Programming. In 9th Australian Conference on Software Engineering (ASWEC) (pp. 310–319). IEEE. https://doi.org/10.1109/ASWEC.2008.4483219 Taibi, D., Lenarduzzi, V., & Pahl, C. (2017). Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation. IEEE Cloud Computing , 4 (5), 22– 32. https://doi.org/10.1109/MCC.2017.4250931 Thönes, J. (2015). Microservices. IEEE Software , 32 (1), 116–116. https://doi.org/10.1109/MS.2015.11 Waterman, M., Noble, J., & Allan, G. (2012). How much architecture? Reducing the up-front effort. In AGILE India (pp. 56–59). IEEE. https://doi.org/10.1109/AgileIndia.2012.11 Zhang, X., Hu, Y., Lu, Y., & Gu, J. (2011). University Dormitory Management System Based on Agile Development Architecture. In International Conference on Management and Service Science . IEEE. https://doi.org/10.1109/ICMSS.2011.5998992 Chapter 6 – Inter-team management within an LSA process based in logical architectures 241 Chapter 6 – Inter-team management within an LSA process based in logical architectures Chapter 6 – Inter-team management within an LSA process based in logical architectures…………………………………………………………………………...242 6.1. Introduction……………………………………………………………242 6.2. On modularization, communication and coordination………………...244 Modularization……………………………………………………..245 Communicating the requirements………………………………….249 Inter-team management…………………………………………….251 6.3. Delivering work items…………………………………………………253 Approach for using Use cases as basis for Scrum backlogs…….....253 Deriving User stories from components……………………………254 Deriving User stories and Product Backlog Items from Use Cases and Components…..260 6.4. Demonstration cases…………………………………………………..265 Team management approach based in a use case-driven backlog: the iFloW case………….266 Team management approach based in a User stories-driven backlog derivation: the ISOFIN case……………………………………………………………………………………………………………….269 Multi-team management and coordination: the UH4SP case……...275 Discussions…………………………………………………………290 6.5. Conclusions……………………………………………………………293 Further reading………………………………………………………………….295 References………………………………………………………………………295 This chapter discusses how the logical architecture model from the previous chapter is able to support teams’ management in an LSA setting. The approach proposes an architecture modularization, where the modules encompass the work scope of different teams. Afterwards, the chapter describes how the models regarding the module are basis for inter-team management and communication. The same models are the starting point for deriving product backlogs, whether based in use cases, user stories, or other items. The chapter includes three demonstration cases, one regarding the use case-driven backlog case, and two regarding the user stories-driven backlog cases, as well as a discussion of the results. This chapter ends with the conclusions. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 242 Chapter 6 – Inter-team management within an LSA process based in logical architectures “ Depending on where you’re looking, one person’s system is another’s subsystem ” Grady Booch, co-author of UML 6.1. Introduction Digital transformation of businesses has increased the rate of creation of new software ecosystems. Additionally, software solutions allow third-party integration (e.g., using Application Programming Interfaces – APIs) towards full support of the supply chain. Many times this means that software development teams are no longer developing software “alone”, rather cooperating with distributed teams belonging to other companies. While agile software development (ASD) has been adopted to optimize how a team delivers software, its use in scaled and distributed (i.e., not co-located) contexts is still object of research, with some emphasis in planning and interteam coordination (Moe & Dingsøyr, 2017). Software development processes in these contexts need to address how software delivered by a team fits in the overall solution, but also how teams must define their boundaries, interfaces, dependences and priorities. Only then, it is possible to apply ASD practices at scaled context, i.e., the concept of “ large-scale agile ” (LSA) (Dingsøyr & Moe, 2014). Managing projects that include multiple teams is a complex task in large-scale software projects. The process of delivering software using more than one development team, often distributed, faces issues of dependencies, boundaries, coordination and/or synchronization. The challenges of making decisions, setting goals, communicating, building trust and managing the team are far harder (Owen, 2016). With ASD, such task had to be rethought (Dingsøyr, Bjørnson, Moe, Rolland, & Seim, 2018). In process management, architectures are an artefact capable of supporting a set of coordination decisions. Additionally, architecture is a central artefact when scaling up agile methods, as it is explicitly present in popular “commercial” LSA frameworks, like Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), Scrum@Scale, Nexus or Enterprise Scrum. Communities such as Industrial XP include “Evolutionary Design” Chapter 6 – Inter-team management within an LSA process based in logical architectures 243 practices, and “Spotify model” have specific architecting roles. “Scientific” LSA proposals like Agile Product Line Architecting (APLA) (Díaz, Pérez, & Garbajosa, 2014), a tailored XP for largescale projects (Cao, Mohan, Xu, & Ramesh, 2004), or a hybrid RUP+Scrum (Cho, 2009) also include explicit architecture practices. Although acknowledging the importance of architecture in managing inter-team processes in an LSA context, these approaches lack of a structured approach for using such information to manage the software delivery process. Models are about presenting an abstraction of reality towards a shared understanding of the problem, but a proper analysis allows depicting their input in assigning work, derive dependencies, and manage inter-team communication and coordination. This chapter describes how a logical architectural artefact is used as basis for managing the process of setting delivery boundaries, communicating the requirements, coordinating and synchronizing multiple teams. The approach presented in further sections is an integrating part of AMPLA, after the candidate version of the logical architecture is derived (cf. Section 5.3). The research addressed in chapter is the result of using a logical architecture diagram as basis for managing work of multi-teams in ASD and LSA settings, from architecture modularization, requirements communication and inter-team coordination. This study was first applied in ISOFIN and afterwards in UH4SP project. Then, this research addressed defining work instructions for these teams by deriving backlogs. First, using a use case-driven backlog in the iFloW project. Then, deriving user stories statements (in the ISOFIN project) and afterwards deriving other agile product backlog items (in the UH4SP project). In addition, in the UH4SP project, the derived product backlog progress was monitored using a set of agile metrics. The contributions of the projects are summarized in Table 13. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 244 Table 24. Contributions of projects in candidate architectures Research contribution \ demonstration case UH4SP ISOFIN iFloW Modularization, coordination and communication from separation of concerns X Modularization, coordination and communication from DDD bounded contexts X Use case-driven backlogs X Deriving user story statements X Deriving product backlog items X ASD metrics monitoring X This chapter is structured as follows:  Section 6.2 discusses architecture modularization, inter-team communication and coordination;  Section 6.3 describes approaches for backlog definition;  Section 6.4 describes the demonstration cases and main discussions around use casedriven backlogs, LSA process based in logical architecture, and agile product backlog items derivation;  Section 6.5 presents the chapter’s conclusions;  The chapter ends with complimentary reading. 6.2. On modularization, communication and coordination As described in previous chapters, the AMPLA approach is the process for architecture design, based on successive and specific artefacts generation. AMPLA is composed by discovery of user needs, A-type sequence diagrams, use case models, a logical architecture, feedbacks and issues, and the consequent software delivery. The artefacts are generated based in the information existing in previously defined artefacts. When software delivery begins, the process is performed in typical cycles, whether in Scrum, Kanban, or other frameworks. AMPLA has four established phases: (i) Requirements Elicitation (ii) Requirements Analysis & Modelling, (iii) Architecture Design, and (iv) Delivery Cycles. Chapter 4 covered phases (i) and (ii), while Chapter 5 covered phases (iii) and (iv). This section also describes team managementdriven work that is performed within phases (iii) and (iv). Chapter 6 – Inter-team management within an LSA process based in logical architectures 251 components from the logical architecture that compose the module and their interfaces with external modules. Additionally, the W2ReqComm includes information regarding the modules usage in the real world. Such information may be described though one or more scenarios, or by including a scenario representation through an A-type sequence diagram previously modelled. The scenario should include the functionalities that the module relates to, but also include the functionality belonging to another team module, in order to provide the implementation team with much context information as possible. An example of a W2ReqComm is depicted in Figure 122. Figure 122. W2ReqComm example Inter-team management The process for managing inter-teams development from this research aims identifying coordination needs for addressing dependencies between components, as well as structuring of roles and events. The coordination and management events involve team representatives – architects, PO’s, BO’s – instead of the entire team. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 252 The identified dependencies trigger the discussions between the representatives, which base in the artefacts from Communication. Discussions take place in planned or unplanned events, using the available communication channels. It is also worth referring that dependency does not only relate to synchronizing a component’s DoD/AC to another component’s DoR. They are also used to define team interfaces, where, for instance, if one team has some doubts in implementing a component from a module boundary, practices such as CoP between the predefined representatives promote discussions in overcoming the given doubts. These associations for this phase are depicted in Figure 123. Figure 123. Inter-team management theory By modelling some processes to validate the flow between components (including components from different modules), e.g., using A-type sequence diagrams, dependencies can be depicted, namely some functionalities that must be implemented and executable in order for other functionalities to proper execute. In fact, A-type sequence diagrams are powerful tools for bordering the modules, as well as validating (not just the modules but as well the whole) architecture. 7) Manage Inter-team Coordination 5) Derive Dependencies 8) Manage Communication Outbound components Team x DoD/AC triggers Team y DoR Communication Channels Communication Periodicity Backlog Items Dependencies discussion Events Architecting CoP Team #x CA and/or BO Team #y CA and/or BO Chapter 6 – Inter-team management within an LSA process based in logical architectures 253 Coordination arenas, inspired by Dingsøyr et al. (Dingsøyr, Moe, Fægri, & Seim, 2018; Dingsøyr, Rolland, Moe, & Seim, 2017), structure how teams involve with each other, from collaborative tools, communication, chats, but also events (or ceremonies). These arenas are enablers for team cooperation, where the models are the core artefact within the discussion. 6.3. Delivering work items As the presented framework addressed mechanisms for modularization, communication and coordination of multi-teams, this section rather addresses how a team under analysis manages and controls the work items that they have to deliver. In ASD approaches, these work items are a composing part of a backlog that the team uses to define the work to be done within the overall project/product and within a given iteration (e.g., a Scrum Sprint). This section introduces defining backlogs, and its composing items, from requirements models (namely UML Use Cases, Components and Sequence Diagrams) using rules that assure the backlog items cover the gathered requirements. This research addressed three possible ways to define a backlog from the requirements models: using a backlog composed by use cases directly from those models, deriving user stories statements from use cases and architectural components, and deriving additional backlog items (themes, epics, user stories, details and acceptance criteria). Each one is further described. Approach for using Use cases as basis for Scrum backlogs As already proposed in Section 4.2, one approach for delivering work items in a backlog is by composing it directly with the Use Cases modeled during Requirements stage (i.e., Initialization phase of the hybrid approach in section 4.2). These tasks are represented in a SPEM diagram in Figure 51, depicting tasks that output work products (Use Case Prioritization and Use Case Estimation) and deliverables, namely ‘ Project Scope ’, ‘ As-Is report ’, ‘ To-Be Report ’ and the ‘ Product Backlog ’. The Business Modeling results are documented in a report designated as ‘ As-Is report ’. Requirements results are modeled in the form of UML use cases. Design results regard the proposal of the logical architecture (UML component diagram). UML use cases (output of Requirements) and UML component (output of Design) diagrams compose the ‘ Solution Requirements Specification ’ that An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 254 result in the ‘ To-Be Report ’. Use case models are used as basis to define a ‘ Product Backlog ’. This kind of backlog is demonstrated further in Section 6.5. Figure 124. SPEM diagram for Initialization phase Deriving User stories from components Using logical architectures for establishing initial requirements allows to combine requirements from backlogs (that focus only on functional features) with the quality attributes of the software (Jeon, Han, Lee, & Lee, 2011). This research proposes including some upfront design in the set-up phase (e.g., Sprint 0, for Scrum projects) of the project - by some we do not mean BDUF, rather “just-enough” (Ambler, 2007) for a candidate architecture - and to use the architecture as input for an ASD approach (back to requirements again) to build almost the totality of the Product Backlog (illustrated in Figure 125). The 4SRS method allows deriving logical architectures aligned with the corresponding, and previously elicited and modeled, user requirements. A logical architecture is a view that primarily supports the functional requirements, taken mainly from the problem domain (Kruchten, 1995). The conventional version of the 4SRS method is typically applied in large-scale projects, but demands high quantity of information (use cases, textual descriptions), which is often time consuming and, in every way, misaligned with the general paradigm adopted by ASD. Chapter 6 – Inter-team management within an LSA process based in logical architectures 255 Figure 125. Approach for delivering backlog items requirements The starting point for the User Stories derivation is the logical architecture diagram that results from the 4SRS method execution. In some cases regarding very large products, it is easy to see that these models can be extremely large and heavy to be analyzed as a whole, because these diagrams represent all the modules needed to run all desired functional requirements. Moreover, it is unlikely that, for large systems, only one Scrum team will perform all the work. In a model where there may be hundreds of modules, a Scrum team could take an amount of time not feasible with the needs of a dynamic market. Thus, deriving User Stories from the modules presented in the previous section allows that several Scrum teams can work in parallel, reducing the time required to implement and deliver the solution to the customer. The first critical decision related to the development of our approach was to understand what should be the relation between the components and the User Stories. In the 4SRS method, the components are derived through the decomposition of Use Cases in three different types (interface, data and control). In a first hypothesis, we decided to create one User Story for each components, as depicted in Figure 126. This decision intends to maintain the core principles for writing User Stories ( i.e. , the INVEST characteristics – Independent, Negotiable, Valuable, Estimable, Small and Testable). Additionally, it complies with the greater flexibility for the Product Owner to follow the team’s work. If the User Stories are always complex and require great effort to implement, there is the risk of diluting one of the main advantages recognized of agile methodologies: the ease of changing the direction of the team and the ability to see, in real time, which is state of commitment of the team to a Sprint. When implementing User Stories of great complexity, which An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 256 may occupy the entire Sprint, only one can draw conclusions about the speed and commitment of the team at the end of the Sprint, when work (supposedly) must be completed. These arguments all meet the characteristic of having small User Stories (Small) and, thus, simplifying the implementation effort estimation (estimable). Figure 126.Relation between Use Cases, Components and User Stories The information from the 4SRS method execution, mainly micro-steps 2i - "Use Case Specification", 2iii - "Component naming" and 2viii - "Component specification", together with the actors associated with each use case (where each component was derived) are key elements in the generation of User Stories, since in them are encapsulated information required to write User Stories respecting the INVEST principles. The proposed technique for deriving user stories is composed by three steps, as follows: Step 1 – Group Components. The first step is to group components and analyze their functionality and their interfaces. This step has as input the components from the logical architecture or, in case of an architecture modularization as the one presented in the previous section, from a given module. Step 2 – Analyze component specification and use case description In this step, we gather the information from micro-steps 2i - "Use Case Specification", 2iii - "Component naming" and 2viii - "Component specification" and the involved actor (by reversing to the use cases that derived the component). This step uses the traceability characteristic that the 4SRS method provides, by allowing to easily depicting the original use case. All these details of each component should be stored with the same structure to give input to create a “card” for each User Story, containing all the information needed to carry out its estimation and subsequent implementation. Thus, for each component is important to obtain the Chapter 6 – Inter-team management within an LSA process based in logical architectures 257 following information: Name; Code; Type; Description; Package; Associations ; Direct Associations; UC Associations; Original Use Case; the Actors Involved; and the UC from the functional decomposition. Alongside this information, it is also important to depict if the component is part of more than one module. Regarding the teams that have habits to keep information always visible from User Stories (placing its features in physical format, often in the form of cards), it was created a User Story template that includes all information collected and previously listed, as well as some information that the implementation team will generate in grooming, as the number of Story Points, acceptance criteria, or any other comment that the team find relevant register and save. Table 25 depicts a template including the information needed for any stakeholder (from the customer / Product Owner to implementation teams). The completion of the card is also intended to be basic and quick as all information regarding the component and the Use Case is available from the execution of the 4SRS method, while information on the User Story is mandatory and is defined by the implementation team during grooming. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 258 Table 25. User story card template User Story US # (name) Acceptance criteria  #1  #2  #3 Story Points Architecture Component # (num) (name) Type (interface/ data/ control) Package Specification Multiple (Yes/No) Module Association Direct Associations UC Associations Use Case UC # (num) (name) Description UC Ass. (num / name) Actors Other s (Comments) Step 3 – Write the User Story This is the final step and where the effecting output of the process is generated. The 4SRS method execution, followed by an analysis on the derived diagrams and documentation, allows triggering the procedure for mapping a logical architecture to output a set of User Stories that comply with the INVEST principles. One of the great advantages of applying the 4SRS method to derive the component is that it quickly allows realizing the ultimate goal of the component: data manipulation, communication or logic operations, by reading the type of component. This standardization of component types simplifies the management of User Stories because, after all, they are centered on three very specific types of tasks. The "who", the actors involved and who will perform tasks on the User Story to implement, are easily identified by analyzing their User Story Card and looking for those involved in the Use Chapter 6 – Inter-team management within an LSA process based in logical architectures 259 Case that derived the component (by executing the 4SRS method). As the logic surrounding the need to represent properties of systems in Use Case and User Story is similar (to capture specific requirements in terms of interaction between users and system), it is easy to validate that those involved in the Use Cases will be benefited by the implementation actors Story of a particular User. Regarding the "what," you can also find a direct relationship between this component and the name of component. Firstly, it is necessary to find an action, represented by a verb, to identify what you want to implement. The division between components of control, and data interface simplifies this demand, since the component interface always refer to the creation of a specific interface and is therefore an action which is fixed and constant need for the existence of a communication interface for between component and / or actors. In most cases, the name of component only indicates what kind of interface is required. Thus, in cases of interface ( i-type ) components, the actors involved just need their existence in order to use them in their workflows. By using the name of the corresponding components, and using connections want/need to have (want/need to have), the connection between the "who" (actor) and what (action) is derived. In cases of i-type components that do not have this syntax, the central part of the User Story for the "what" is simply left to the information “want/need to have an interface”, and the title of the component (the actions that will take place using that interface) used as part of the "why". For data ( d-type ) components the process is similar, since they usually refer to the need of the existence of repositories/storage locations or interfaces for communication with such storage spaces. Thus, the construction of the User Story follows the same rule used in i-type components. Compared with the previous two types, control ( c-type ) components are disparate. They support the logic behind a system, representing all actions that can be performed by manipulating the data (represented by d-type components) and using interfaces for transmission (represented by i-type components). As they can represent any action on the system, typically ctype components have associated a verb that represents the action that it performs. In this case, we are deriving information of a title for a sentence. Some kind of semantic correctness of words may be required, allowing the sentence to make sense. This approach allowed User Stories to fulfill their main purpose, which is to identify work to be done. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 260 Deriving User stories and Product Backlog Items from Use Cases and Components In this section is proposed a systematic transformation of model-based requirements (UML Use Cases and Component diagrams) into ASD-oriented requirements, according to the backlog items. Leftingwell also describes software requirements approaches for agile teams (Leffingwell, 2010). Additionally, he includes a metamodel for a common understanding on requirements information in agile product backlogs (Figure 127). The Agile Extension to the BABOK® Guide lists a variety of requirements artifacts and activities present in known agile frameworks (IIBA, 2017) such as Scrum, XP, Behavior-driven Development (BDD), Kanban, and Agile Unified Process (AUP). It was based in these works that we defined the backlog structure that should result after performing a set of derivation rules. These derivation rules aimed a backlog that followed the path of Themes, then Epics, then User stories, then finally tasks. Each User story has associated Acceptance criteria (which gives the “Definition of Done” (DoD), and may have details that describe the requirements to implement the story in software. The backlog items are the following: Deriving Themes: A theme in a Backlog item relates to a generic concept. A theme in a Backlog item relates to a generic concept, realized by a set of Epics (Leffingwell, 2010). For that reason, a theme may be derived by the identified packages. In 4SRS, a package is identified for logically grouping a set of components from the architecture. Chapter 6 – Inter-team management within an LSA process based in logical architectures 267 from UMinho had no previous knowledge of the domain (in this case, logistics), so the team decided that the project kicked-off by gathering and documenting requirements in a waterfallbased approach. After the requirements engineering was performed, and since iFloW aimed developing a software system for an industrial context, the team decided to follow the Scrum framework as the iterative approach for the implementation phase. This phase was performed by development iterative cycles in form of Scrum Sprints. Based in incremental software deliveries, both UMinho and Bosch could manage their project’s expectations. As a collaborative University-Industry R&D software project, the previously presented roles are slightly different from the roles defined by the Scrum framework (namely, Product Owner, Scrum Master and Development Team) (Schwaber & Beedle, 2001), however easily mapped, as depicted in Table 27. Table 27. Mapping between iFloW roles and typical Scrum roles Scrum Role Product Owner Scrum Master Development Team iFloW Role Bosch Product Owner  Bosch IT   UMinho R&D Coordinators  Software Developers  Use Cases that compose the backlog During the initialization phase of the hybrid method, the iFloW requirements gathering output were modeled in a set of UML Use Cases, depicted in Figure 133. Each of the use cases were functionally decomposed, which resulted in 90 lower level use cases. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 268 Figure 133. Use Case diagram of the iFloW project Afterwards, within the implementation phase, the use cases from the ‘ Product Backlog ’ were implemented iteratively and incrementally during eight four-week (Scrum) Sprints. In this phase, typical Scrum iterations were performed, where each ‘ Sprint Backlog’ is a selected subset from the ‘ Product Backlog ’. In Figure 134 is depicted a ‘ Sprint Backlog’ tracking sheet, composed by the iFloW use cases and whose progress was monitored. Chapter 6 – Inter-team management within an LSA process based in logical architectures 269 Figure 134. A Sprint Backlog based in Use Cases from the iFloW project Team management approach based in a User stories-driven backlog derivation: the ISOFIN case Team settings The ISOFIN project was composed by eight entities (private companies, public research centers and universities). During the requirements stage, the consortium defined that the entire ISOFIN solution would include a cloud platform and a set of local services. For the case of the cloud platform, one entity formed a team specifically to model requirements in order to deliver them to other three entities that would have Scrum teams to implement them. For the case of the local services, another entity modeled requirements that the remaining two would implement. This research focused in the team responsible for gathering requirements for the cloud platform. Modularization Previously in Section 4.4, the modeling process performed within the ISOFIN project has been already described. By following a V-Model approach, models were derived in succession (Figure 53). This derivation path includes the solution’s business processes, A-type sequence diagrams, use cases, logical architecture and B-type sequence diagrams. In its vertex, the 4SRS method An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 270 assures that user requirements models (in the left side) are aligned with system requirements models (in the right side). Figure 135. The result of the V-Model to be delivered to multiple Scrum teams The ISOFIN logical architecture is composed by 105 components. The overall architecture referred to software development functionalities that were to be delivered by three software teams, each belonging to a different entity. Having as basis the logical architecture and, additionally, B-type sequence diagrams and the solution’s business processes, the analysts discussed, depicted and proposed a set of application/modules to be developed. The proposed applications/modules are composed by components from the logical architecture, and the composition of each application is depicted in Figure 136 through a set of “spots” that traverse the logical architecture. The components that are “covered” by the spot represent the expected functionalities for a given application. However, it is not possible yet to depict sequences and flows for the application execution (such is provided by B-type sequence diagrams) as well as the components that interface with the application. The logical diagram was partitioned in seven “spots” covering the components (Figure 136), representing applications to be developed: Integrated Business Services (IBS) Management; ISOFIN Applications Management; Alerts Management; Subscription Management; Security Chapter 6 – Inter-team management within an LSA process based in logical architectures 271 Management; Policies Management; and Logs Management. An overview of the “spots” is presented in Annex B. Figure 136. ISOFIN architecture modularization We present in this section one of the modules to illustrate the demonstration case: the IBS Management module. By executing this module, An IBS Developer develops a new IBS by modeling the IBS, selecting the available IBSs from the pallets. Besides modeling its structure, the IBS Developer is also responsible for defining permissions, manually filling gaps in the IBS code, publishing the information in the catalog and deploying the IBS in the ISOFIN Platform. Communication The filtering and collapsing technique that was applied within the logical architecture allowed depicting the components that compose the module and their interfaces, and then depict its W2ReqComm. The W2ReqComm for the IBS Management module is presented in Figure 137. Repositories Alert Editor <<data>> {AE4.1.d} Configured Alert Information <<interface>> {AE4.1.i} Alert Configuration Interface Alert Installer <<control>> {AE4.2.1.c} Alert Code Generator <<control>> {AE4.2.2.c1} Schedule Alert <<control>> {AE4.2.2.c2} Execute Alert ISOFIN App Communication <<interface>> {AE3.5.1.i} Send Information From ISOFIN App <<interface>> {AE3.5.2.i} Receive Information in ISOFIN App <<interface>> {AE3.6.1.i} Send Configuration Commands From ISOFIN App <<interface>> {AE3.6.2.i} Receive Configuration Commands to ISOFIN App <<interface>> {AE3.6.3.i} Send Usage Commands From ISOFIN App <<interface>> {AE3.6.4.i} Receive Usage Commands to ISOFIN App ISOFIN App Installer <<interface>> {AE3.3.1.i} ISOFIN Application Publisher Interface <<control>> {AE3.3.2.c} ISOFIN App Deployer <<interface>> {AE3.3.2.i} ISOFIN App Deployment Interface <<control>> {AE3.3.3.c} Export ISOFIN App Code <<control>> {AE3.3.4.c} ISOFIN App Documentation Generator <<interface>> {AE3.3.4.i} ISOFIN App Documentation Editor <<control>> {AE3.4.2.c} Test ISOFIN Application Before Deployment Security Management <<control>> {AE1.6.c} Grant Access to ISOFIN Platform <<interface>> {AE1.6.i} ISOFIN Platform Access and Usage Management <<control>> {AE2.2.6.c1} Selected Object permissions <<control>> {AE2.4.1.c} IBS Communication Validation <<control>> {AE3.5.1.c} ISOFIN App Communication Validation Logs Management <<interface>> {AE2.4.1.i1} IBS Log Manager <<interface>> {AE3.5.1.i1} ISOFIN App Log Manager <<interface>> {AE4.3.i1} Alert Log Manager <<interface>> {AE1.3.5.i1} Subscription Log Manager Supplier Subscription Management <<control>> {AE1.3.1.c} Evaluate Supplier subscription <<interface>> {AE1.3.1.i} Supplier subscription evaluation interface <<interface>> {AE1.3.3.i} Supplier’s Subscriptions Requirements Interface <<interface>> {AE1.5.1.i} Publish SBS Subscsription in Catalog Interface Customer Subscription Management <<control>> {AE1.3.2.c} Evaluate Customer subscription <<interface>> {AE1.3.2.i} Customer subscription evaluation interface <<interface>> {AE1.3.4.i} Customer’s Subscriptions Requirements Interface <<interface>> {AE1.5.2.i} Publish Customer Subscsription in Catalog Interface IBS Communication <<interface>> {AE2.4.1.i} Send Information From IBS <<interface>> {AE2.4.2.i} Receive Information in IBS <<interface>> {AE2.5.1.i} Send Configuration Commands From IBS <<interface>> {AE2.5.2.i} Receive Configuration Commands to IBS <<interface>> {AE2.5.3.i} Send Usage Commands From IBS <<interface>> {AE2.5.4.i} Receive Usage Commands to IBS IBS Installer <<control>> {AE2.2.7.c} IBS Interface Generator <<data>> {AE2.2.7.d} IBS Interface Repository <<interface>> {AE2.3.1.i} IBS Publisher Interface <<control>> {AE2.3.2.c} IBS Deployer <<interface>> {AE2.3.2.i} IBS Deployer Interface <<control>> {AE2.3.3.c} IBS Documentation Generator <<interface>> {AE2.3.3.i} IBS Documentation Editor <<control>> {AE2.7.2.c} Test IBS Before Deployment IBS Editor <<control>> {AE2.1.2.c1} Selected Object configurations <<data>> {AE2.1.2.d} IBS Configuration Repository <<interface>> {AE2.1.2.i} Low-level IBS Configuration Interface <<data>> {AE2.1.3.d} IBS Structure Repository <<interface>> {AE2.1.3.i} Update IBS Structure Interface <<control>> {AE2.1.4.c} Compiles IBS information <<interface>> {AE2.1.4.i} Update IBS Interface <<interface>> {AE2.2.3.i} IBS Structure interface <<control>> {AE2.2.4.c} Define IBS Code Gaps <<interface>> {AE2.2.4.i} IBS Coding and Compiling Interface <<control>> {AE2.2.5.c} Compile IBS code <<data>> {AE2.2.5.d} IBS PreDeployment Storage <<interface>> {AE2.2.6.i} Permissions Interface <<control>> {AE2.7.1.c} IBS Customization Filter <<interface>> {AE2.7.1.i} IBS Customization Interface <<interface>> {AE2.6.3.i} IBS Interconnectivity interface IBS Repository <<data>> {AE2.1.1.d} IBS Repository <<interface>> {AE2.6.1.i} IBS Repository Interface SBS Repository <<data>> {AE2.6.2.d} SBS Repository <<interface>> {AE2.6.2.i} SBS Repository Interface Alert Repository <<data>> {AE4.3.d} Alert Repository <<interface>> {AE4.3.i/c} Scheduled Alert Dispatcher Subscription Repository <<control>> {AE1.3.5.c1} Subscription Duplicity Verification <<data>> {AE1.3.5.d} ISOFIN Platform Subscription Info Repository <<interface>> {AE1.3.5.i} Subscription Repository Interface <<data>> {AE1.4.d} ISOFIN Platform Subscription Assessment Repository <<interface>> {AE1.8.1.i} Manage ISOFIN Suppliers <<interface>> {AE1.8.2.i} Manage ISOFIN Customers Logs Repository <<data>> {AE2.4.1.d} IBS Logs Repository <<data>> {AE3.5.1.d} ISOFIN App Logs Repository <<data>> {AE4.3.d1} Alert Logs Repository <<interface>> {AE4.3.i2} Log Repository Interface <<data>> {AE1.3.5.d1} Subscription Logs Repository Security Repository <<data>> {AE1.2.1.d} ISOFIN Platform Policies Repository <<data>> {AE1.6.d} ISOFIN Platform Access Repository ISOFIN App Repository <<data>> {AE3.3.1.d} ISOFIN App Repository <<interface>> {AE3.3.1.i1} ISOFIN App Repository Policies Management <<interface>> {AE1.2.1.i} Configure Supplier Policies Interface <<interface>> {AE1.2.2.i} Configure Customer Policies Interface Subscription Management <<interface>> {AE1.1.1.i} Fulfillment Subscription Requirements Interface <<control>> {AE1.1.2.c1} Verifiy Subscription data duplicity <<control>> {AE1.1.2.c} Validate subscription requirement fulfillment <<interface>> {AE1.1.2.i} Manual Subscription Validation Interface <<interface>> {AE1.4.i} Subscription Request Interface <<control>> {AE1.7.c} Control Subscription Requests <<interface>> {AE1.7.i} Suscription Request Status Interface ISOFIN App Editor <<interface>> {AE3.1.i} ISOFIN Application Model Editor <<interface>> {AE3.2.1.i} IBS Information Retrieval <<control>> {AE3.2.2.c} Generate ISOFIN App Code <<interface>> {AE3.2.2.i} ISOFIN Application Coding and Compiling Interface <<interface>> {AE3.2.3.i} ISOFIN Application Model Interface <<control>> {AE3.2.4.c} Associate Visual Representation to Functionality <<interface>> {AE3.4.1.i} ISOFIN Application Customization Interface ««GENERATES»» <<interface>> {AE2.7.2.i} IBS Test Generator <<interface>> {AE2.6.2.i1} SBS Pallet Retrieval Interface <<interface>> {AE2.6.1.i1} IBS Pallet Retrieval Interface 2x 6x 6x 6x 6x 5x 6x 6x 2x 2x 2x 3x 3x ««GENERATES»» An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 272 Regarding the overlapped components in more than one module, one of the teams is nominated to be responsible for implementation of the module and assure that the teams responsible for modules with dependencies with that particular one have all required documentation and provide updates on its implementation. Figure 137. W2ReqComm for IBS Management module User Story derivation We present in Table 28 an example of the use of user story card, using the Test Before IBS Deployment component example. Information regarding the name of the User Story presupposes the execution of the next step of this method. The acceptance criteria and the story points fields are not defined at the time of the User Story derivation. They are defined later during Sprints, so these fields were not yet defined in the card in Table 28, thus defined as “not applicable” ( N/A ) at this time. IBS Management Module Alert Editor <<interface>> {AE4.1.i} Alert Configuration Interface Alert Installer Security Management <<control>> {AE2.2.6.c1} Selected Object permissions Supplier Subscription Management IBS Communication IBS Installer <<control>> {AE2.2.7.c} IBS Interface Generator <<data>> {AE2.2.7.d} IBS Interface Repository <<interface>> {AE2.3.1.i} IBS Publisher Interface <<control>> {AE2.3.2.c} IBS Deployer <<interface>> {AE2.3.2.i} IBS Deployer Interface <<control>> {AE2.3.3.c} IBS Documentation Generator <<interface>> {AE2.3.3.i} IBS Documentation Editor <<control>> {AE2.7.2.c} Test IBS Before Deployment IBS Editor <<control>> {AE2.1.2.c1} Selected Object configurations <<data>> {AE2.1.2.d} IBS Configuration Repository <<interface>> {AE2.1.2.i} Low-level IBS Configuration Interface <<data>> {AE2.1.3.d} IBS Structure Repository <<interface>> {AE2.1.3.i} Update IBS Structure Interface <<control>> {AE2.1.4.c} Compiles IBS information <<interface>> {AE2.1.4.i} Update IBS Interface <<interface>> {AE2.2.3.i} IBS Structure interface <<control>> {AE2.2.4.c} Define IBS Code Gaps <<interface>> {AE2.2.4.i} IBS Coding and Compiling Interface <<control>> {AE2.2.5.c} Compile IBS code <<data>> {AE2.2.5.d} IBS PreDeployment Storage <<interface>> {AE2.2.6.i} Permissions Interface <<control>> {AE2.7.1.c} IBS Customization Filter <<interface>> {AE2.7.1.i} IBS Customization Interface <<interface>> {AE2.6.3.i} IBS Interconnectivity interface IBS Repository <<data>> {AE2.1.1.d} IBS Repository <<interface>> {AE2.6.1.i} IBS Repository Interface SBS Repository <<data>> {AE2.6.2.d} SBS Repository <<interface>> {AE2.6.2.i} SBS Repository Interface Subscription Repository Security Repository ISOFIN App Editor ««GENERATES»» <<interface>> {AE2.7.2.i} IBS Test Generator <<interface>> {AE2.6.2.i1} SBS Pallet Retrieval Interface <<interface>> {AE2.6.1.i1} IBS Pallet Retrieval Interface 3x IBS Management Module <<data>> {AE4.1.d} Configured Alert Information <<data>> {AE1.6.d} ISOFIN Platform Access Repository <<interface>> {AE1.6.i} ISOFIN Platform Access and Usage Management <<interface>> {AE1.3.5.i} Subscription Repository Interface <<control>> {AE4.2.2.c2} Execute Alert <<control>> {AE4.2.2.c1} Schedule Alert <<control>> {AE4.2.1.c} Alert Code Generator <<interface>> {AE2.4.2.i} Receive Information in IBS <<interface>> {AE2.5.1.i} Send Configuration Commands From IBS <<interface>> {AE2.5.4.i} Receive Usage Commands to IBS <<interface>> {AE2.5.3.i} Send Usage Commands From IBS <<interface>> {AE2.4.1.i} Send Information From IBS <<interface>> {AE2.5.2.i} Receive Configuration Commands to IBS <<interface>> {AE3.2.1.i} IBS Information Retrieval <<interface>> {AE3.1.i} ISOFIN Application Model Editor <<control>> {AE3.2.4.c} Associate Visual Representation to Functionality <<interface>> {AE1.5.1.i} Publish SBS Subscsription in Catalog Interface An IBS Developer develops a new IBS by modeling the IBS, selecting the available IBSs from the pallets. Besides modeling its structure, the IBS Developer is also responsible for defining permissions, manually filling gaps in the IBS code, publishing the information in the catalog and deploying the IBS in the ISOFIN Platform. If necessary, the IBS Developer performs test and fixes coding errors. The IBS to be developed may require setting system alerts. Chapter 6 – Inter-team management within an LSA process based in logical architectures 273 Table 28. User Story card for "Test IBS Before Deployment" User Story US #1 As a Business User or a IBS Developer, I want to test IBS before deployment, in order to render IBS in pre-runtime. Acceptance criteria N/A Story Points N/A Architecture Component # 2.7.2.c Test IBS Before Deployment Type Control Package IBS Installer Specification This component allows testing of the IBS before deployment. This component will be required before the execution of {C2.3.2.c} IBS Deployer to verify that no problems occur during the execution of the IBS. All information need for the execution is provided by {C2.2.5.d} IBS Pre-Deployment Storage Multiple No Module IBS Management Association Direct Association 2.7.2.i – IBS Test Generator UC Association 2.3.2.c – IBS Deployer 2.2..5.d – Pre-Deployment Storage Use Case UC # 2.7.2 Render IBS Pre-Runtime Description Configure and defines the pre-runtime of the IBS. This use case allows testing of the IBS before deployment. UC Ass. 2.7 – Configure IBS Actors Business User IBS Developer Others The User Story must provide the "why" of a particular actor ("who") may need to perform a certain action ("what"). This information, often induced by the very title of the corresponding components, can be complemented with a description of the Use Case from which the component was derived. As User Stories relate to a lower level than uses cases, the description of the use case itself can justify the need for existence of a particular User Story. In cases where the name of components is quite similar to use case from which the component was derived, the significance of User Story can be found in the description of the use case. Using these rules, An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 274 remaining User Stories were derived that are listed in Table 16. In Figure 138 is represented a User Story sentence based in the derivation from Table 16. Table 29. User Stories derived from c-type components # Component As a(n) <actor> I want/need <description> In order to <outcome> 2.1.2.c1 Selected Object Configurations ISOFIN Customer / IBS Developer select object configurations change (IBS Structure) configurations 2.1.4.c Compiles IBS information IBS Developer compile IBS (changes and) information create a new IBS 2.2.4.c Define IBS Code Gaps IBS Developer (automatically generated code) and define IBS code gaps create IBS code 2.2.5.c Compile IBS code IBS Developer compile IBS code (and create new IBS catalog) (keep IBS catalog and store) compile(d) IBS Code 2.2.6.c1 Selected Object Permissions IBS Developer select object permissions set(/manage) permissions (and create IBS) 2.2.7.c IBS Interface Generator IBS Developer (automatically) Generate IBS Interface (store the) generate(d) IBS interface 2.3.2.c IBS Deployer IBS Developer deploy IBS execute IBS deployment 2.7.1.c IBS Customization Filter Business User filter IBS (configuration and) customization customize IBS 2.7.2.c Test IBS Before deployment Business User / IBS Developer test IBS before deployment render IBS Pre-Runtime Figure 138. User Story from 2.1.4.c Inter-team management Now that the User Story derivation is complete, there are just some issues that are dealt in the multiple teams’ management. In the case of the ISOFIN project, the teams were distributed Chapter 6 – Inter-team management within an LSA process based in logical architectures 275 but belong to the same organization and were not geographically distributed. The quantity of teams were not as many as the modules identified, but the total quantity of teams is not relevant, since they belong to the same organization. Thus, the organization chose to nominate a single Scrum Master to work closely with all teams. The Product Owner was responsible for the decisions during the implementation, like detecting potential delays and decisions on critical issues across the teams. Regarding the overlapped components in more than one module, it is then the Product Owner’s responsibility to nominate a team to be responsible for implementation of the derived User Story and assure that the teams responsible for User Stories with dependencies with that particular one have all required documentation and provide updates on its implementation. Multi-team management and coordination: the UH4SP case Team settings The UH4SP project was composed by five teams from four different entities for software development where each had specific expected contributes, from cloud architectures to industrial software services and mobile applications. The entities are geographically distributed, but each entity had a single located team. Figure 139 depicts the roles structuring between the involved teams. The business need relates to managing, communicating and coordinating software delivery. Team #A is expertized in mobile and image recognition technologies, composed by three Developers, a Quality Assurance (QA) engineer and a Scrum Master (SM) - which acts with Org #1. The Chief Architect (CA) – that also takes the role of Product Owner (PO) – is responsible for the architectural decisions of team #A’s Team Product Backlog (TPB) and part of the architecture team of the project. Teams #C and #E has the same role structure, but expertized in web and API applications. Team #B has a Scrum team expertized in web and microservices development, composed by three Developers, a QA engineer, the SM, a CA and a Business Analyst (BA) – also acting as a PO – responsible for managing team #B’s TPB. Team #D is responsible for the cloud infrastructure, composed with a CA and DevOps engineers. Additionally, all teams also include strategic roles such as Project Manager (PrjMmg), and a Business Owner (BO) that is responsible for team’s products portfolio. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 276 Teams work internally within their delivery of increments, based in Scrum teams or not. Alongside with the delivery, there are important decisions that require integration among teams, relating to architecture, dependencies, and coordination. The management and communication between these teams arise the need to define a process. Strategic decisions also require communication between PrjMng and BO, however not addressed in this research. Figure 139. Structure of UH4SP teams Architecture modularization Section 5.5 described how a candidate version of the UH4SP project logical architecture was derived in an agile-oriented way using AMPLA. The UH4SP logical architecture had as input 37 use cases and, after executing 4SRS method (Annex C), was derived with 77 architectural Scrum Team Dev QA Dev Dev SM BA / PO ProjMngCA BO Team #B Scrum Team Dev QA Dev Dev ProjMngCA / PO BO Team #A Org #1 Org #2 DevOpsDevOps ProjMngCA BO Team #D Org #3 Scrum Team Dev QA Dev Dev ProjMngCA / PO BO Team #C PODev BO Team #D Org #4 Chapter 6 – Inter-team management within an LSA process based in logical architectures 283 Quality metrics is a category where metrics are mainly measured by the team themselves. Finally, the Stakeholder metrics are more oriented for Product Managers as they are related to customers. This control was based in gathered literature around this topic, presented in Table 36, and using such works in a setting where Team #B used the models from performing AMPLA. The UH4SP project progress was monitored using the EVM system. Throughout Team #B’s Sprints, the values for Actual Cost (AC), Earned Value (EV), Planned Value (PV), Cost Variance (CV), Schedule Variance (SV), Schedule Performance Index (SPI), Cost Performance Index (CPI) were monitored. The value for Budget Cost At Completion (BAC) was obviously previously defined before project kick-off. Only AC and PV measuring was completely independent from using AMPLA before Sprints. Table 36. Agile metrics EVM metrics (Sulaiman et al., 2006) Measurement Budget Cost At Completion (BAC) Planned budget for the release Actual Cost (AC) Spent budget for the release Earned Value (EV) EV = APC × BAC Planned Value (PV) PV = PPC × BAC Cost Variance (CV) CV = EV – AC Schedule Variance (SV) SV = EV – PV Schedule Performance Index (SPI) SPI = EV / PV Cost Performance Index (CPI) CPI = EV / AC Planning/Management metrics Measurement Business Value Delivered (BVD) (Hartmann & Dymond, 2006) Business value provided by the delivered increment within the Sprint Release Burndown (Hayes, Miller, Lapham, Wrubel, & Chick, 2014) Which Product backlog items are ‘done’ and the remaining ones Sprint Burndown (Hayes et al., 2014) Which Sprint backlog items are ‘done’ and the remaining ones Velocity (Hayes et al., 2014) Story points delivered by Sprint Planned Percentage Complete (PPC) (Sulaiman et al., 2006) Nr. of Sprints performed / Nr. of Sprints planned Actual Percentage Complete (APC) Nr. of user stories ‘done’ / Nr. of user stories planned Development metrics Measurement An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 284 Lead Time (Mujtaba, Feldt, & Petersen, 2010) Time between the item inclusion in backlog and to be ‘done’ Queue Time (Mujtaba et al., 2010) Time between the item inclusion in backlog and included in Sprint backlog Processing Time (Mujtaba et al., 2010) Time between the item inclusion in Sprint backlog and to be ‘done’ Story Flow Percentage (Kupiainen, Mäntylä, & Itkonen, 2015) % of completed story under development Work in Progress (WIP) (Petersen & Wohlin, 2011) Nr. of user stories under development Quality metrics Measurement Defect Backlog (Staron, Meding, & Söderqvist, 2010) Nr. of known defects still unresolved Build Status (Janus, Schmietendorf, Dumke, & Jäger, 2012) Nr. of builds performed in a Sprint Test Coverage (Janus et al., 2012) Code Covered by testing / Completed Code Test Growth Ratio (Janus et al., 2012) growth of the Test in relation to the growth of the Source Code Deferred defects (Green, 2011) Nr. of defects identified after going ‘live’ Stakeholder metrics Measurement Customer Satisfaction Survey filled by the customer about the experience Feedback time Time between customer and team for feedbacks Since Actual Percentage Complete (APC) uses the number of user stories planned, which comes from the sum of derived user stories after performing the rules presented in section 6.4. Consequently, EV uses the APC value. Afterwards, CV, SV, SPI and CPI, which use the EV value, hence use the number of user stories derived within AMPLA. Table 37 depicts the EVM controlling performed by Team #B’s Project Manager (from the UH4SP team presented in section 6.2) throughout team’s six (Scrum) Sprints. The Project Manager was able to compare EV evolution to AC and PV (Figure 143). Additionally, values of CPI and SPI from Table 37 allowed depicting the project status at the time of a given Sprint based in time and costs. In Figure 144, CPI and SPI values for each Sprint allow depicting whether in each Sprint the project was: (i) behind in time and costs (0,5<SPI<1 and 0,5<CPI<1); (ii) bad times Chapter 6 – Inter-team management within an LSA process based in logical architectures 285 but good costs (0,5<SPI<1 and 1<CPI<1,5); (iii) good times but bad costs (1<SPI<1,5 and 0,5<CPI<1), and, finally, (iv) good times and costs (1<SPI<1,5 and 1<CPI<1,5). Table 37. EVM controlling EVM S#0 S#1 S#2 S#3 S#4 S#5 S#6 Actual Cost (AC) 130 611,5 408 876 374 236 226 Earned Value (EV) 26,11 109,67 219,33 276,78 276,78 276,78 276,78 Planned Value (PV) 67,14286 134,2857 201,4286 268,5714 335,7143 402,8571 470 Cost Variance (CV) -103,89 -501,83 -188,67 -599,22 -97,22 40,78 50,78 Schedule Variance (SV) -41,03 -24,62 17,90 8,21 -58,94 -126,08 -193,22 Schedule performance index (SPI) 0,388889 0,816667 1,088889 1,030556 0,824444 0,687037 0,588889 Cost performance index (CPI) 0,200855 0,17934 0,537582 0,315956 0,740048 1,172787 1,22468 Figure 143. Evolution of AC, PV and EV An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 286 Figure 144. EVM monitoring The progress of Sprints is monitored by the Product Owner (PO) using the Planning/Management metrics. Within these metrics, PO was able to measure Business Value Delivered (BVD), Release Burndown, Sprint Burndown, Velocity, Planned Percentage Complete (PPC), and the already mentioned Actual Percentage Complete (APC). Release Burndown, Sprint Burndown, Velocity, and PPC are measured without any input from AMPLA. Figure 145 depicts these metrics measured by Team #B’s PO. Figure 145. Sprint #3 burndown and team velocity measurement As already used for EVM, APC uses the number of user stories planned, which are the sum of user stories derived after performing AMPLA. The BVD value is a very important measure in ASD, since it focuses in the added value for the customers. As for its definition from the original publication from Hartmann and Dymond, BVD is Chapter 6 – Inter-team management within an LSA process based in logical architectures 287 measured using values of Net Present Value (NPV), Internal Rate of Return (IRR), and Return on Investment (ROI), by calculating Net cash flow per iteration (Hartmann & Dymond, 2006). In this research, the idea of measuring BVD is not by measuring the economic return of the delivered software, but rather the importance of delivered functionalities from each increment within the aimed product roadmap. AMPLA provides the mechanism to measure BVD, by providing the linking between product objectives, functional requirements and models, and the backlog items. Therefore, whenever an increment was delivered at the end of a Sprint, as backlog items are marked as ‘done’, they are traced back to the objectives. The control of the BVD throughout the Sprints is performed by the sum of the ‘done’ user stories. Such control is depicted in a Cumulative flow, like in Figure 146. As previously described in section 4.4, the UH4SP project’s objectives that were stated referred to: (1) a unified view at the corporate (group of units) level; (2) tools for third-party entities; (3) in-plant optimization; and (4) system reliability. Figure 146. Cumulative flow An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 288 The previously derived backlog items from AMPLA, where the 61 user stories (available in Annex C), were grouped within the following features: 1. Configure User profile 2. Configure User Account 3. Perform Authentication 4. Manage Stakeholders 5. Manage Trucks 6. Manage Applications 7. Collaborative tool 8. Manage Work Tokens These features were the input for aiming the project objectives. They contributed (in %) for the objectives, as depicted in Table 38. Each feature could contribute to more than one objective. Then, in addition to identifying features contributions to objectives, weights for the contribution were assigned (with an equal weight, e.g., if 3 features contributed to an objective, each one weighed 33%, if 4 features, each one weighed 25%, etc.). Thus, using these weights, the user stories marked as ‘done’ in each Sprint were used for monitoring the evolution of the objective until it is achieved. The project’s objectives, together with the gathered expectations elicited during requirements (section 4.4), are aligned with the “Objectives and Key Results” (OKR) (Doerr, 2018), where expectations describe the key results and how they are achieved. AMPLA provides the traceability mechanisms for linking the user stories and features to the expectations (and, consequently, the key results). Table 38. Feature's contributions to project's objectives view at the corporate level tools for third-party entities in-plant optimization system reliability Configure User profile 20% 16,67% 25% 33,3% Configure User Account 20% 16,67% 25% 33,3% Perform Authentication 20% 16,67% 25 33,3% Manage Stakeholders 20% - - - Manage Trucks - 16,67% - - Manage Applications - 16,67% - - Collaborative tool 20% - 25% - Manage Work Tokens - 16,67% - - Chapter 6 – Inter-team management within an LSA process based in logical architectures 289 Table 39 depicts the evolution of BVD throughout the Sprints, namely by controlling the cumulative value (in %) of the project objective to be achieved. Namely, this way the PO monitored OKR’s being met, as soon as the objective’s BVD was 100% ‘done’. Table 39. Cumulative value of BVD BVD (Cum) view at the corporate level tools for thirdparty entities in-plant optimization system reliability stories Sprint 0 0% 0% 0% 0% stories Sprint 1 0% 0% 0% 0% stories Sprint 2 57% 54% 54% 72% stories Sprint 3 77% 70% 71% 83% stories Sprint 4 93% 78% 92% 99% Regarding the Development metrics, Team #B measured Lead Time, Processing Time, Queue Time and the Work in Progress (WIP). The traceability provided by AMPLA allowed Team #B to hold the data of each feature, from its specification (before Sprint # 0 or already within the Sprints) until the respective user story is included in the Sprint Backlog and afterwards marked as ‘done’. Table 40 depicts Lead Time, Processing Time, Queue Time. Table 41 depicts the WIP control, although in this case the traceability from AMPLA does not have impact on such measurement. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 290 Table 40. Lead Time, Processing Time, Queue Time Features Specified Implemented Start Implemented Finish Lead Time Queue Time Processing Time Configure User profile 0 1 2 2 1 1 Configure User Account 0 1 2 2 1 1 Perform Authentication 0 1 2 2 1 1 Manage Stakeholders 0 1 3 3 1 2 Manage Trucks 0 1 2 2 1 1 Manage Applications 1 2 3 2 1 1 Collaborative tool 2 3 5 3 1 2 Manage Work Tokens 4 5 5 1 1 0 Table 41. Work in Progress Sprint #0 Sprint #1 Sprint #2 Sprint #3 Sprint #4 Sprint #5 WIP 5 16 21 11 4 9 Regarding stakeholder metrics, in UH4SP this measurement was performed based in customer satisfaction via a survey. Finally, regarding quality metrics, the measurement was basically based in registering bugs and number of performed tests. These two categories of metrics did not had any input from AMPLA. Discussions Use case-driven backlogs Defining a hybrid approach (waterfall-based during initialization and Scrum-based during implementation), with the inclusion of artifacts modeling and documentation, strengthened the adoption of a Scrum process in a context as the one presented within the iFloW project. However, the entire adoption was a learning process, with advantages and disadvantages, which are detailed in this section. Chapter 6 – Inter-team management within an LSA process based in logical architectures 291 This demonstration case showed the following advantages: Requirements documentation waterfall-based – the fact that the Product Backlog was composed of 90 use cases led to a shared perception of the system complexity that originated the need to perform proper efforts in documenting the requirements. Thus, consuming efforts in almost exclusively for requirements engineering typically performed in waterfall approaches, in the initialization phase, allowed the project team to gain the required knowledge to properly implement a system of such complexity. Implementation Scrum-based – within a customer perspective, Bosch was always aware of the system’s current state of development. The iterative development, in form of Scrum Sprints, was crucial to manage Bosch’s expectations, due to the periodical meetings and the incremental delivery of working software. Use of a logical architecture – to enforce a proper organization on the set of components. The relationships among components suggest dependencies that may affect the implementation of functionalities and their inclusion in the Sprint Backlog. On the other hand, it also showed the following disadvantages: Effort estimation for use cases - the fact that it was a completely new development team (thus team velocity was unknown) and the need to frequently perform research spikes in order to overcome technological issues (for instance, related to GPS, EPCIS or SAP-OER) were the main obstacles for the estimation. In Scrum, estimation is performed using techniques such as planning poker, where user stories are estimated based in comparing efforts between other user stories. Due to the inexperience of the team, estimating the required effort for implementing use cases by comparing with other was itself a learning process. Such approach resulted in Sprint backlogs where use cases had not been implemented due to error in estimating and required conclusion in further Sprints, and where the effort estimating of the remaining use cases (as well as rework, whenever was required, and the spikes that were performed within almost every Sprints) required almost constant updates on every Sprint Closure and Planning meeting. Dependence on negotiation for middleware use cases - collaborative coding among iFloW team members and service provider team members was required to implement middlewarerelated use cases. Most of the times the implementation required previous negotiation and agreements and the implementation did not progress at the desired velocity. The team’s work An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 292 reached a point where they had to pause and wait for those agreements, which resulted in the extension of use cases (and use cases with dependencies with them) through several Sprints. Architecture modularization for inter-team management Overall, in the ISOFIN project, there were clear advantages in using this approach: (1) the teams experienced difficulties in interpreted the complete architecture, thus the modularization was required; (2) since the project consortium was composed by Scrum teams, they easily understood the artifacts ( i.e. , User Stories); (3) User Stories were derived having an already designed logical architecture as input, allowing them to be properly aligned within reduced time. Connection points between modules were identified and properly covered by User Stories but there was not enough time during this research work to assess that the team’s efforts were in fact synched. Besides the identification of connection points, the authors believe that there is a vast area of progress in the topic of distributed Scrum teams. Deriving work items Although this case relates to the application of the method in Scrum teams, the authors believe that it is generic for being applied in other ASD methods, like XP or Kanban. In addition, it is perceived that such an approach is more helpful in LSA contexts, especially the sub-system partitioning and its further refinement. This approach is planned to be experimented in the future within LSA contexts. By assigning a module of the architecture to a given team, we are basically defining a subset of the backlog, i.e., a Team Backlog. Hence, it is assumed that each team is responsible for developing a set of connected features. The predefinition of a subset (or a given feature) of the backlog is also present in approaches like Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Enterprise Scrum, and Spotify model (or Squads/Tribes). In the UH4SP project, the fact that it aimed to act within a complex ecosystem was taken in consideration for applying the 4SRS method. The 4SRS is a tool for tracing components and functional requirements models, moreover in large-scale contexts. We believe that the inclusion Chapter 6 – Inter-team management within an LSA process based in logical architectures 299 https://doi.org/10.1145/3120459.3120474 Moe, N. B., Olsson, H. H., & Dingsøyr, T. (2016). Trends in Large-Scale Agile Development: : A Summary of the 4th Workshop at XP2016. In Proceedings of the Scientific Workshop Proceedings of XP2016 on - XP ’16 Workshops (pp. 1–4). New York, New York, USA: ACM Press. https://doi.org/10.1145/2962695.2962696 Mujtaba, S., Feldt, R., & Petersen, K. (2010). Waste and Lead Time Reduction in a Software Product Customization Process with Value Stream Maps. In 2010 21st Australian Software Engineering Conference (pp. 139–148). IEEE. https://doi.org/10.1109/ASWEC.2010.37 OMG. (2009). OMG Unified Modeling Language (OMG UML),Superstructure version 2.2. Object Management Group. Owen, J. (2016). Global Teams: How the best teams achieve high performance . FT Publishing International. Paasivaara, M., & Lassenius, C. (2014). Communities of practice in a large distributed agile software development organization – Case Ericsson. Information and Software Technology , 56 (12), 1556–1577. https://doi.org/10.1016/J.INFSOF.2014.06.008 Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM , 15 (12), 1053–1058. https://doi.org/10.1145/361598.361623 Petersen, K., & Wohlin, C. (2011). Measuring the flow in lean software development. Software: Practice and Experience , 41 (9), 975–996. https://doi.org/10.1002/spe.975 Power, K. (2014). Definition of ready: An experience report from teams at cisco. In Agile Processes in Software Engineering and Extreme Programming. XP 2014 . Springer Cham. https://doi.org/10.1007/978-3-319-06862-6_25 Rolland, K., Fitzgerald, B., Dingsoyr, T., & Stol, K.-J. (2016). Problematizing Agile in the Large: Alternative Assumptions for Large-Scale Agile Development. In 37th International Conference on Information Systems (ICIS) . Dublin: AIS. Schwaber, K., & Beedle, M. (2001). Agile Software Development with Scrum . Upper Saddle An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 300 River: Prentice Hall. Staron, M., Meding, W., & Söderqvist, B. (2010). A method for forecasting defect backlog in large streamline software development projects and its industrial evaluation. Information and Software Technology , 52 (10), 1069–1079. https://doi.org/10.1016/J.INFSOF.2010.05.005 Sulaiman, T., Barton, B., & Blackburn, T. (2006). AgileEVM - Earned Value Management in Scrum Projects. In AGILE 2006 (pp. 7–16). IEEE. https://doi.org/10.1109/AGILE.2006.15 301 PART IV – CONCLUSIONS Chapter 7 – Conclusions 302 Chapter 7 – Conclusions Chapter 7 – Conclusions………………………………………………………………303 7.1. Focus of the Work……………………………………………………..303 7.2. Synthesis of the research efforts…………………………………....…311 7.3. Scientific Outputs……………………………………………………...313 7.4. Future work……………………………………………………………325 References………………………………………………………………………329 This chapter concludes this thesis. It describes the overall focus of the conducted work. Additionally, it synthesizes the research efforts as well as the scientific results of this thesis. Finally, this chapter ends with a set of proposed future work. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 303 Cap 7 – Conclusions 7.1. Focus of the Work The use of models throughout the software development lifecycle (SDLC) – typically, starting from identification of business needs or opportunity, then requirements, design, implementation, testing and deployment – reflects the knowledge that stakeholders possess, at a given phase or stage, about the solution under development. As the SDLC evolves, models typically include more detail on software solution behavior rather than the business setting where the solution will deploy. In model-driven development (MDD), this situation is stated as a decrease of model abstraction. With the adoption of agile software development (ASD) approaches, by promoting iterative and incremental development and collecting feedback and learning for continuous adaptation, modeled artifacts decrease in abstraction but evolve in an incremental and continually updated way. Tracing such model evolution is needed so they are able to fulfill their purpose, which is to help teams develop software. While ASD have been increasingly adopted by organizations 9 , specifically at a team level, its usage in wider contexts – e.g., multiple and distributed teams or global development – has led to developing approaches for implementation at scale, which, as described in Chapter 2, are still object of research, with some emphasis in planning and inter-team coordination. Although acknowledging the importance of architecture in managing inter-team processes in an LSA context, these approaches lack of a structured approach for using such information to manage the software delivery process. Models are about presenting an abstraction of reality towards a shared understanding of the problem, but a proper analysis allows depicting their input in assigning work, derive dependencies, and manage inter-team communication and coordination. Modeling a system includes multiple viewpoints regarding the architecture. A well-known example is the “4+1 framework” which addresses Logical, Process, Development, Physical and (“plus”) Scenarios viewpoints. The architectural lifecycle throughout a project encompasses these viewpoints, thus all should be addressed during design. This research focuses in the logical one. 9 VersionOne, “Annual State of Agile Report”. https://www.stateofagile.com/ Chapter 7 – Conclusions 304 The logical viewpoint regards designing software components and organizing them so the software meets the business needs. Such organization allows depicting the scope of functionalities that a team needs to develop and, in case of multiple or distributed teams, allows depicting the scope of each team and respective interface needs. There is thus an opportunity for research is supporting the model evolution, namely the logical architecture one, in order to provide the mechanisms for ASD and LSA settings. Mechanisms include architecture emerging and refinement, evolution traceability, relationships with other viewpoints, continuous architecting promoted by “the power of small” (i.e., microservices) and baseline support for multiple teams management (namely in LSA contexts). Previously in Chapter 1, this PhD’s research question was presented, stating: “ How to adopt logical architectures in agile large-scale projects? ” This thesis presented the Agile Modeling Process for Logical Architectures (AMPLA), an Agile Modeling (AM) oriented process composed by UML diagrams (Sequence, Use Cases and Component). AMPLA uses agile practices in order to deliver small increments (of a requirements package) and to promote continuous customer feedback. The proposed AM process also includes a candidate architecture and further requirements refinement in parallel with a software increment delivery. The refinement ranges from component design to a microservices architecture. AMPLA supports that the model abstraction level decreases throughout the process, providing traceability for easing changes that may occur. AMPLA uses the techniques as well as its outputs in modeling AMPLA artifacts, like (1) Lean Startup, Design Thinking, Domain-driven Design, BizDev and Kent Beck’s 3X in requirements modeling; (2) Ambler’s Agile Modeling, Lean Inception for the candidate logical architecture design; (3) Sprint zero for architecture modularization; (4) Use Cases 2.0, Scrum, XP and Kanban backlog structures; (5) DevOps for the microservices architecture and its deployment. This research aimed answering the research question by addressing three research objectives. They are now revisited, as well as describing the results that resulted in their achievement. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 305 O1: To develop an approach capable of deriving logical architectures in order to establish the initial requirements that are passed on to agile development teams. In chapter 6, two possible types of approaches using a logical architecture were presented: (1) a use case-driven backlog, using UML Use Case models for defining the Product Backlog; and (2) a user story-driven backlog, using a set of UML diagrams (Use Case, Sequence and Components), described in Chapter 4, which can derive the “agile” backlog items. Related to the later, firstly it was presented a set of rules for deriving user story statements (in form of “As a…I want to…in order to…”). Then, the approach was revisited aiming deriving additional backlog items. After performing AMPLA, the resulting logical architecture was used in order to derive “agile” product backlog items, based in a widely adopted structure for backlogs (Leffingwell, 2010). Such derivation was enabled by a set of defined transformation rules, in short:  A theme may be derived by the identified packages;  an epic is directly derived from a Use Case;  a user story creation should be based by each of the scenarios from a use case;  User Stories Details are depicted by the software components responsible for executing the given functionality, identified during the 4SRS method execution. Another important aspect of the detail may be the context of use, which is depicted by scenarios, modeled in sequence diagrams ;  Acceptance Criteria is described in the use case description, namely the post condition. O2: To adopt flexibility and agility mechanisms in the refinement of logical architectures throughout the iterations of ASD teams. In Chapter 5, AMPLA was described as a supporting mechanism for proposing a candidate logical architecture, using a set of “just-enough” requirements. Then, supported by the 4SRS method, the candidate logical architecture iteratively evolves as specific subsets of the architecture are analyzed within Scrum Sprints and its components are refined. Agile architecting is about continuous design and evolution of the solution, by acknowledging the architecture’s evolution but assuring such evolution is not endangered by business decisions. Included within the AMPLA method, Chapter 5 presented how continuous architecting (CA) is supported by supporting change-impact analysis (CIA) practices for eventual changes proposals. Due to the model traceability supported by AMPLA, CIA was able to depict impacts in concerns as architecturally significant requirements (ASR), Quality characteristic, Business and customer Chapter 7 – Conclusions 306 value of the requirement, Which components are affected, Compliance with standards, Requirements emerge, and Managing architectural debt. O3: To develop an approach oriented for continuous architecting, aiming to specify microservices logical architectures (MSLA), identifying them and their interfaces. As described in O2, design in ASD continuously evolves. In previous objectives the focus was to propose an architecture from scratch and incrementally refine it. However, continuous architecture includes assuring the architecture eases a proper maintenance. By making use of the “power of small”, microservices architectures (MSA) style have been adopted in software development, on one hand, in developing cloud applications, promoted by the service’s independent deployment and maintenance and, on the other hand, using such independence and “smallness” for promoting automation in a continuous integration, continuous delivery and DevOps processes. In Chapter 5, by using an adapted version of the 4SRS, a model for microservices logical architectures (MSLA) was derived and presented using SoaML diagrams. The described approach allows deriving the microservices’ internal behavior, their data models, and the existing communications. The approach was described in opposite settings: (1) in an existing monolith decomposition setting, with upfront information about legacy systems, demonstrated in IMP_4.0 and ISMPM projects; and (2) in greenfield settings, where requirements emerged (using AMPLA), demonstrated in UH4SP project. Transiting from the logical architecture to SoaML diagrams was systematized in modeling procedures, in short:  Service Participants with boundary definition, communication needs (Requests/Services and Ports)  Service Architecture with boundary definition and communication (service requests that the service performs)  Service Capabilities with boundary definition and data model  Service Interfaces with communication specifications O4: To use logical architectures to manage assignment and orchestration process in LSA projects Software development settings composed with multi-teams, distributed or co-located, have an additional concern in the SDLC to manage and coordinate work and the software delivered by An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 307 them. This process of delivering software, at large-scale – i.e., using more than one development team, often geographically distributed - faces issues of dependencies, boundaries, coordination and/or synchronization. In ASD settings, often referred as ‘ large-scale agile development ’ (LSA), such task had to be rethought, where team collaboration heavily relies in a proper addressing of communication, trust and alignment. A logical architecture model was able to provide important insights for such concerns, by the organization of the components assigned for teams and the component’s relationships that may relate with required interfaces between teams. In Chapter 6, a framework for distributed agile teams was presented, addressing the architecture modularization, team assignment, dependencies, requirements modelling towards coordination and communication within distributed teams. Modularization phase is composed by the following principles: Identify Modules of the architecture; Assign Modules to Teams , which originates a subset of work items; Set Module Boundaries ; and Define Module Size . Derive Dependencies and Manage Communication using predefined channels and periodicity, are present in Communication and Coordination phases. Communication phase also includes Model W2ReqComm Package for a multiview requirements package. Coordination phase also includes Manage Inter-team Coordination , composed by unplanned and planned events. AMPLA is a modeling approach covering the evolution of agile architecting, from grooming to software delivery stages. Namely, AMPLA covers some modeling and design tasks, including initial inputs, candidate architecture design, incremental refinement, continuous architecting and change-impact analysis, microservice logical architecture design and deployment, and multiteams and multi-backlogs management. This thesis focused in the contribution of AMPLA to a set of research topics necessary to support covering the SLDC, which are now described. Agile modeling AM, as the name states, is about modeling in ASD settings. While other settings, like plan-driven (e.g., Waterfall) address the entire modeling in a specific stage of the SDLC, AM advocates modeling throughout the SDLC, encompassing its evolution as further details of software emerge. It relates to the opposite of “Big Design Upfront” (BDUF), aiming to prevent modeling of “You Ain’t Gonna Need It” (YAGNI) features. Chapter 7 – Conclusions 308 AMPLA contributes to AM by providing a stepwise model evolution, where different software models (Sequence Diagrams, Use Cases, and Logical Architectures) are derived in succession and properly aligned with each other in a V-Model manner. AMPLA proposes the design of a candidate version of the logical architecture during grooming stages of the ASD, afterwards providing mechanisms for the architecture refinement during iteration cycles (e.g. Scrum Sprints). Additionally, AMPLA provides the traceability between the models (Sequence Diagrams, Use Cases, Logical Architectures), as well as between the models and the Product Backlog Items (Epics, User Stories, Acceptance Criteria, etc.). Agile requirements engineering Just like AM, “agile requirements engineering” 10 differs from plan-driven by not being sticked in a specific stage of the SDLC, but rather throughout the SDLC. In ASD contexts, requirements engineering activities are still in a relatively early phase of development. However, there are change in their timings and how they are used. In ASD frameworks, like Scrum, XP, Kanban, SAFe, LeSS, Scrum@Scale, Nexus or Spotify Squad, the requirements are included in a product backlog, which then drives the development process, thus most of the RE activities are performed earlier. For the scope of this thesis, requirements engineering outputs aim gathering the information for enabling AMPLA at providing a candidate logical architecture. Towards such aim, this research proposed an approach that addressed requirements elicitation, analysis and documentation as they emerge in a stepwise and traceable way, called “Decomposing User Agile Requirements ArTEfacts” (DUARTE). DUARTE included inputs from ASD practices such as Lean Startup, Design Thinking, Domaindriven Design, BizDev and Kent Beck’s 3X. By including inputs from these practices, DUARTE aims at assuring that the gathered and modeled requirements have only the “just-enough” detail for enabling AMPLA at deriving a candidate logical architecture. AMPLA does not require that requirements engineering be based in DUARTE approach. In fact, it only requires that an output is a UML Use Case model, in order to perform the Four Step 10 Requirements engineering performed in ASD settings is sometimes referred as “agile requirements engineering”, but this term is not consensual since many authors state that “requirements engineering” techniques are the same whether in ASD or non-ASD settings. For the sake of this thesis, we use the term “agile requirements engineering” whenever techniques are performed in ASD settings. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 315 Contribution 2: Incremental model refinement until service level Microservices architectures (MSA) are an architectural style oriented towards modularization, where the idea is to split the application into smaller, interconnected services, running as a separate process that can be independently deployed, scaled and tested. Adopting microservices include specific concerns on design, development and deployment. Assuring MSA design aligned with business requirements needs to be supported by modeling methods that cover microservices principles. This thesis proposed defining a method for deriving a microservices logical architecture (MSLA) from functional requirements. The method has as input an UML logical components diagram, enabling deriving microservices specifications, afterwards modeled in SoaML diagrams. Additionally, these diagrams were basis for discussing microservices principles. This thesis included a method validation, both in greenfield settings (UH4SP project) and in breaking existing monoliths settings (IMP_4.0 and ISMPM projects). Contribution 3: Process management at large-scale Research in large-scale software development projects, or, in the case of this thesis, ‘large-scale agile development’ (LSA), relates to ASD practices for scaled settings in team’s size, number of teams, number of lines of code, among others. These practices have the concern relating to business agility, role of architects, knowledge sharing and networks, inter-team coordination, etc. Although it was acknowledged the potential role of models – like the architecture – for promoting those concerns, there was a gap in a prescriptive approach for using architectural models as input (like components and their interfaces) for supporting dependencies, communication and coordination between teams. The theory defines a logical architectural artefact as basis for managing the process of setting delivery boundaries, communicating the requirements, coordinating and synchronizing interteams work. In an LSA setting, the candidate architecture is modularized and “presented” to multi-teams. This research demonstrated how teams coordinate, communicate and synchronize during their own model evolution, enabling the architecture model to refine incrementally in multi-modules in parallel throughout the project. Chapter 7 – Conclusions 316 The inputs from these research contributions result from different demonstration cases. How demonstration case’s inputs were organized towards the research contributions is synthetized in Table 43. As depicted in the “Observations” column in Table 43, each project may contribute differently in the research contribution. For instance, iFloW and UH4SP projects provide opposite inputs on modeling in ASD (or Agile Modeling), namely upfront modeling in ASD projects and emerging modeling preventing BDUF. Also, post iterations of a contribution, which aimed at revisiting, updating and improving the research contribution, like the case of ISOFIN in helping define rules for deriving user story statements from UML models and the case of UH4SP that improved these rules in order to derive additional product backlog items, such as themes, epics, user story details and acceptance criteria. Table 43. Demonstration case's inputs towards the research contributions Demonstration case Contribution 1 Contribution 2 Contribution 3 Observations iFloW X Use of models (upfront) in ASD projects ISOFIN X X Use of models (upfront) in ASD projects, Rules for deriving user story statements and inter-team dependencies UH4SP X X X Agile (emerging) modeling using DUARTE and AMPLA, deriving agile backlog items (complimentary to ISOFIN), and uses 4SRSMSLA in greenfield projects IMP_4.0 X Uses 4SRS-MSLA in an existing monolith project (with upfront requirements rather than emerging like the UH4SP) ISMPM X Uses 4SRS-MSLA in an existing monolith project and discussed In exception for ISMPM, each of the demonstration cases relate to a funded R&D project. Which is to say that this thesis work includes scientific outputs from ISOFIN, iFloW, UH4SP and IMP_4.0 projects. In ISOFIN project, this research included developing and afterwards validating the applicability of using the 4SRS method for deriving the logical architecture and afterwards delivering it to distributed ASD teams in form of user stories and dependencies between them. Contributions such as Contribution 1: Agile Modeling Process for Logical Architectures and An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 317 Contribution 2: Process management at large-scale, are included work of the following project deliverables: - M/D207 – ISOFIN Logical Architecture; - M/D210 – Financial Domain Applications/Services Specifications Namely, M/D207 – ISOFIN Logical Architecture documented the research work towards upfront modeling for Contribution 1, and M/D210 – Financial Domain Applications/Services Specifications regarding Contribution 2 that documented the research work in modularizing the architecture, defining an approach to bound the modules scope, interfaces, and dependencies, and presenting transition rules for user story statements (“As a… I want to… In order to…”) for usage in ASD projects. In iFloW project, this research included developing and afterwards validating the applicability of using a requirements modeling in UML for use in an ASD project and backlog. Research work towards Contribution 1: Agile Modeling Process for Logical Architectures is included work of the following project deliverables: - D4.4.2 - Specification of the model for experimental development; - D5.3.8 – development of functionalities - D6.7.9 – verification and validation of functionalities developed Namely, report D4.4.2 - Specification of the model for experimental development documented the requirements process and the UML models. Reports D5.3.8 – development of functionalities, and D6.7.9 – verification and validation of functionalities developed documented the definition of the backlog and the results of the performed iterations (Scrum Sprints) which allowed perceiving how the iFloW project team used the derived backlog. In UH4SP project, this research included developing the AMPLA, DUARTE and 4SRS-MSLA approaches and afterwards validating the applicability of using emerging (agile) modeling of requirements and candidate architecture, incremental refinement of the architecture following microservices principles and continuous architecting, and the delivery of product backlog items and multi-teams LSA process management. Contributions such as Contribution 1: Agile Modeling Process for Logical Architectures, Contribution 2: Incremental model refinement until service level and Contribution 3: Process management at largescale are included work of the following project deliverables: Chapter 7 – Conclusions 318 - D.3.1 – Functional and Technical Requirements Specification; - D.3.2 – Technical and logical architecture; - D3.3 – Service Specification For Material Reception And Shipment; - D3.5 – Interoperability Between Platform And Services Requirements; - D3.7 – Solution modelling; - D4.1.1 – UH4SP Management Platform – Initial Version; - D4.1.2 – UH4SP Management Platform – Final Version; - D5.4 - Integration Services and Platform. Namely, D.3.1 – Functional and Technical Requirements Specification report documented the results from applying the DUARTE approach, and D.3.2 – Technical and logical architecture report documented the results of applying AMPLA for candidate logical architecture design, both for Contribution 1. Reports D4.1.1 – UH4SP Management Platform – Initial Version, D4.1.2 – UH4SP Management Platform – Final Version and D5.4 - Integration Services and Platform documented, firstly, the architecture modularization, communication and coordination needs, and afterwards, the performed iterations (Scrum Sprints) which allowed perceiving how one of the UH4SP project team used the derived backlog, for Contribution 3. Finally, reports D3.3 – Service Specification For Material Reception And Shipment, D3.5 – Interoperability Between Platform And Services Requirements and D3.7 – Solution modelling regarding documented the results from applying the 4SRS-MSLA and the microservices modeling in SoaML, for Contribution 2. In IMP_4.0 project, this research included developing 4SRS-MSLA and afterwards validating the applicability of the MSLA in an existing monolith setting. Research work towards Contribution 2: Incremental model refinement until service level, is included work of the following project deliverables: - D.1.4 – Functional requirements specifications – initial version; - D.1.5 – Functional requirements specifications – final version; - D1.8 – Traceability mechanisms for production management; - D1.9 – IMP_4.0 logical architecture – initial version; - D1.10 – IMP_4.0 logical architecture – final version; - D1.11 – IMP_4.0 platform services specification. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 319 Namely, reports D.1.4 – Functional requirements specifications – initial version and D.1.5 – Functional requirements specifications – final version documented the requirements engineering task for the existing monoliths setting. The D1.8 – Traceability mechanisms for production management report documented the development of the 4SRS-MSLA method. Finally, reports D1.9 – IMP_4.0 logical architecture – initial version, D1.10 – IMP_4.0 logical architecture – final version and D1.11 – IMP_4.0 platform services specification documented the resulting MSLA, in form of different SoaML diagrams. All these reports documented research work towards Contribution 2. As mentioned in Chapter 1, in the case of the IMSPM, because it is an internal project, the only available documentation is in form of a MSc thesis, that can be found in: Amaral, José Diogo Coelho, “The evolution of monolithic architectures to microservice-based architectures” (free translation of “A evolução das arquiteturas monolíticas para as arquiteturas baseadas em microserviços”), ISEP - DM – Engenharia Informática 11 . This work documented the application of 4SRS-MSLA for an internal project at i2S company, allowing depicting how the existing monolith was decomposed in an MSA, and additionally discussing deployment and infrastructure needs for that MSA, providing complimentary insights for Contribution 2: Incremental model refinement until service level. A crucial part of the research work relates to communicating the results. For that aim, several research papers were published, which are now listed. Conference papers: o Ferreira, N., Santos, N. & Machado, R.J., 2014. Modularization of Logical Software Architectures for Implementation with Multiple Teams. In Proceedings of the 14th International Conference on Computational Science and Its Applications. IEEE, pp. 1–11. DOI: 10.1109/ICCSA.2014.14 o Costa, N., Santos, N., Ferreira, N., & Machado, R. J., 2014. Delivering user stories for implementing logical software architectures by multiple scrum teams. In Computational Science and Its Applications. Springer International Publishing, pp. 747-762. DOI: 10.1007/978-3-319-09150-1_55 11 Available at: http://hdl.handle.net/10400.22/11920 Chapter 7 – Conclusions 320 o Santos, N., Barbosa, D., Maia, P., Fernandes, F., Rebelo, M., Silva, P. V., Fernandes, J. M., Machado, R. J. (2016). iFloW: an integrated logistics software system for inbound supply chain traceability. In E. Mendonça, J. P., Fensterbank, S.-A., Barthet (Ed.), “Enterprise Interoperability VII”. Springer, Cham. DOI: 10.1007/978-3-319-30957-6_15 o Santos, N., Fernandes, J. M., Carvalho, S. M., Silva, P. V., Fernandes, F., Rebelo, M., Fernandes, J. M., Machado, R. J. (2016). Using Scrum together with UML models: A collaborative University-Industry R&D software project. In Gervasi, O., Murgante, B., Misra, S., Rocha, A.M.A.C., Torre, C.M., Taniar, D., Apduhan, B.O., Stankova, E., Wang, S. (Eds.) Computational Science and Its Applications – Part III. Lecture Notes in Computer Science. Springer. DOI: 10.1007/978-3-319-42089-9_34 o Santos, N., Pereira, J., Morais, F., Barros, J., Ferreira, N., & Machado, R. J. (2018). An agile modeling oriented process for logical architecture design. In Gulden, J., Reinhartz-Berger, I., Schmidt, R., Guerreiro, S., Guédria, W., Bera, P. (Eds.) Enterprise, Business-Process and Information Systems Modeling. Lecture Notes in Computer Science. Springer, Cham. DOI: 10.1007/978-3-319-91704-7_17 o Santos, N., Pereira, J., Morais, F., Barros, J., Ferreira, N., & Machado, R. J. (2018). An experience report on using architectural models within distributed Scrum teams contexts. In XP’18 Scientific Workshops . ACM. DOI: 10.1145/3234152.3234180 o Santos, N., Pereira, J., Morais, F., Barros, J., Ferreira, N., & Machado, R. J. (2018). Incremental architectural requirements for agile modeling: a case study within a Scrum project. In XP’18 Scientific Workshops . ACM. DOI: 10.1145/3234152.3234166 o Santos, N., Pereira, J., Morais, F., Barros, J., Ferreira, N., & Machado, R. J. (2018). Deriving user stories for distributed Scrum teams from iterative refinement of architectural models. In XP’18 Scientific Workshops . ACM. DOI: 10.1145/3234152.3234165 o Santos, N., Rodrigues, H., Pereira, J., Morais, F., Abreu, R., Fernandes, N., Martins, D., Machado, R. J. (2018). UH4SP: a software platform for integrated management of connected smart plants. In: 9th IEEE International Conference on Intelligent Systems (IS). IEEE. DOI: 10.1109/IS.2018.8710468 o Santos, N., Pereira, J., Ferreira, N., & Machado, R. J. (2018). Modeling in agile software development: decomposing use cases towards logical architecture design. In ProductFocused Software Process Improvement . Lecture Notes in Computer Science. Springer. DOI: 10.1007/978-3-030-03673-7_31 An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 321 o Santos, N., Ferreira, N., & Machado, R. J. (2019): “Towards agile architecting: Proposing an architectural pathway within an Industry 4.0 project”, Information Systems: Research, Development, Applications, Education. Springer, Cham. DOI: 10.1007/978-3-030-296087_10 o Santos, N., Rodrigues, H., Ferreira, N., & Machado, R.J. (2019). “Inputs from a Model-based Approach towards the Specification of Microservices Logical Architectures: an Experience Report”. Product-Focused Software Process Improvement. Springer, Cham. o Santos, N., Salgado, C. E., Rodrigues, H., Morais, F., Melo, M,, Silva, S., Martins, R., Pereira, M., Ferreira, N., Pereira, M. & Machado, R. J. (2019). A logical architecture design method for microservices architectures. Proceedings of 13th European Conference on Software Architecture (ECSA 2019) - Vol.2. ACM. DOI: 10.1145/3344948.3344991 Book chapters o Santos, N., Rodrigues, H., Pereira, J., Morais, F., Martins, R., Ferreira, N., Abreu, R., Machado, R.J. (2018): Specifying Software Services for Fog Computing Architectures Using Recursive Model Transformations. In: Mahmood, Z. (ed.) Fog Computing: Concepts, Frameworks and Technologies. pp. 153–181. Springer, Cham. DOI: 10.1007/978-3-31994890-4 o Santos, N., Morais, F., Rodrigues, H. & Machado, R.J. (2019). Systems Development for the Industrial IoT: Challenges from Industry R&D Projects. In: Mahmood, Z. (Ed.), The Internet of Things in the Industrial Sector, 1st ed. Springer Cham. DOI: 10.1007/978-3-030-24892-5 Doctoral Consortium papers: o Santos, N., Fernandes, J. M., Carvalho, S. M., Silva, P. V., Fernandes, F., Rebelo, M., Fernandes, J. M., Machado, R. J. (2016). Industrial interoperability issues when adopting Scrum in research projects: the case of the iFloW system. In “Enterprise Interoperability”, International Conference on Interoperability for Enterprise Systems and Applications (I-ESA) Doctoral Symposium. o Santos, N., Machado, R. J., Ferreira, N. (2016). Adopting Logical Architectures within Agile Projects. In 6th Portuguese Software Engineering Doctoral Symposium (SEDES) in conjunction with the 10th International Conference on the Quality of Information and Communications Technology (QUATIC’16). DOI: 10.1109/QUATIC.2016.059 Chapter 7 – Conclusions 322 o Santos, N., Machado, R. J., Ferreira, N. (2017). Adopting Logical Architectures within Agile Projects. In Doctoral Consortium of the European Conference in Information Systems (ECIS’17 DC). Involved Master thesis: o MSc #1: Martins, Raquel “Designing Architectures for Industrial Cloud Solutions: The UH4SP Demonstration Case” (free translation of “Conceção de Arquiteturas de Soluções Cloud para a Indústria: Caso de Demonstração UH4SP”), Integrated Masters in Engineering and Management of Information Systems (MIEGSI), Department of Information Systems, University of Minho, Portugal, 2018 (http://repositorium.sdum.uminho.pt/handle/1822/59343) o MSc #2: Correia, Luis “Development of an Agile metrics Framework” (free translation of “Desenvolvimento de um framework de métricas para projetos ágeis”), Integrated Masters in Engineering and Management of Information Systems (MIEGSI), Department of Information Systems, University of Minho, Portugal, 2018 (https://repositorium.sdum.uminho.pt/handle/1822/59138) o MSc #3: Amaral, José Diogo Coelho, “The evolution of monohlithic architectures to microservice-based architectures” (free translation of “A evolução das arquiteturas monolíticas para as arquiteturas baseadas em microserviços”), ISEP - DM – Engenharia Informática, 2018. http://hdl.handle.net/10400.22/11920 Presentations at scientific conferences: o “Modularization of Logical Software Architectures for Implementation with Multiple Teams”, “Tools and Techniques in Software Development Processes” session at the 14th International Conference on Computational Science and Its Applications. Guimarães, Portugal, July 1st 2014 o “Delivering user stories for implementing logical software architectures by multiple scrum teams”, “Workshop of Agile Software Development Techniques” session at the 14th International Conference on Computational Science and Its Applications. Guimarães, Portugal, July 2nd 2014. An Agile Process for Modeling Logical Architectures: Demonstration Cases from Large-scale Software Projects 323 o “Industrial interoperability issues when adopting Scrum in research projects: the case of the iFloW system”, at the International Conference on Interoperability for Enterprise Systems and Applications (I-ESA) Doctoral Symposium, Guimarães, Portugal a March 28th 2016 o “iFloW: an integrated logistics software system for inbound supply chain traceability”, 8th International Conference on Interoperability for Enterprise Systems and Applications (I-ESA), Guimarães, Portugal, March 31st 2016. o “Adopting Logical Architectures within Agile Projects”, Doctoral Consortium of the European Conference in Information Systems (ECIS DC), Guimarães, Portugal, June 5th 2017 o “An agile modeling oriented process for logical architecture design.”, 23rd International Conference on Exploring Modeling Methods for Systems Analysis and development (EMMSAD) in conjunction with 30th International Conference on Advanced Information Systems (CAiSE) , Tallin, Estonia, June 11th 2018. o “An experience report on using architectural models within distributed Scrum teams contexts”, 6th International Workshop on Large-Scale Agile Development (LargeScaleAgile’18) in conjunction with the 19th International Conference on Agile Software Development (XP’18), Porto, Portugal, May 28th 2018. o “Incremental architectural requirements for agile modeling: a case study within a Scrum project” and “Deriving user stories for distributed Scrum teams from iterative refinement of architectural models”, at Poster Session and at “Poster Madness” session of International Conference on Agile Software Development (XP’18), Porto, Portugal, May 22nd to 24th 2018.  “A logical architecture design method for microservices architectures”. In 3rd Workshop on Formal Approaches for Advanced Computing Systems (FAACS’19) in conjunction with the 13th European Conference on Software Architecture (ECSA 2019), Paris, France, September 10th 2019.  “Towards agile architecting: Proposing an architectural pathway within an Industry 4.0 project”, at 12th EuroSymposium on Systems Analysis and Design, Gdansk, Poland, September 19th 2019.  “Inputs from a Model-based Approach towards the Specification of Microservices Logical Architectures: an Experience Report”. International Conference on Product-Focused Software Process Improvement (PROFES) 2019. Barcelona, Spain, November 27th to 29th 2019. Presentations at other events: Chapter 7 – Conclusions 324  Poster session, presenting preliminar research results, at “Doctoral Programme in Information Systems and Technology (PDTSI) Autumn Symposium 2016”, Guimarães, Portugal, November 16th 2016  Presentation of AMPLA process and the UH4SP architecture, included in the project’s results, at the event “Solutions for Smart Factories in the Era of Industry 4.0 – OpenDay by Cachapuz, Braga’s Municipality Economic Week”, Braga, Portugal, May 24th 2018  Presentation of the IMP_4.0 architecture, included in the project’s results, at the event “Industry 4.0 – Presentation of the IMP_4.0 Platform”, Braga, Portugal, November 27th 2017  Presentation of the ASD approach adopted by the iFloW project, included in the project’s results, at “HMIExcel Program Closing Conference”, Braga, Portugal, June 30th 2015 Table 44 summarizes the contribution and content of the published scientific outputs in relation with the project/demonstration case the work was validated as well as the research contribution. Table 44. Published paper's relation with demonstration case and research contribution ISOFIN iFloW UH4SP IMP_4.0 ISMPM TTSDP’14 RC2 WAGILE’14 RC2 I-ESA DS RC1 I-ESA’16 RC1 SEPA’16 RC1 SEDES’16 RC1 RC1 ECIS DC RC1 RC1 XP’18 WS RC2 EMMSAD’18 RC1/3 Fog book RC3 MSc #1 RC1/3 QuASD’18 RC1 IS’18 RC3 MSc #2 RC2 MSc #3 RC3 IIoT book RC3 RC3 FAACS’19 RC3 Eurosymposium’19 RC1 PROFES’19 RC3 331 APPENDIXES Appendix A – iFloW models ................................................................................................... 332 Appendix B - ISOFIN models ................................................................................................. 339 Appendix C - UH4SP models ................................................................................................. 344 Appendix D – IMP_4.0 models ............................................................................................. 354 Appendix E - IMSPM models ................................................................................................. 357 [Document text truncated for crawler view.]