Continuous Improvement through Iterative Development in a Multi-Geography

Architectural Knowledge Management in Global Software Development: A Review

“…Relationships identified as I, L, and M are not encountered in Table 1 because they are not specific for GSD context and are common standards in the software architecture community. [5], [7], [15], [17], [22], [23], [26], [31] C, D An architect (or architect representative) can form part of a Distributed Team to improve coordination [7], [26], [27], [31] E Software architecture drives the organization's structure [7], [13], [14], [23], [27], […”

“…A Component is allocated to one Distributed Team [7], [23], [24], [25], [26] [7], [12], [13], [14], [17], [24], […”

“…Thus, Components are treated as independent work-packages in order to minimize the communication between sites [25]. How these work-packages are allocated can depend on the expertise of Distributed Teams at given sites [26] [7], [23], [24].…”

“…Distributed Teams need to have accessible Coordination Strategies in order to allow them to communicate in an efficient way (B). A Stakeholder that is recommended to exist at each Distributed Team is the architect (C, D), who is in charge of defining the architecture and can act as a coordinator between its local team and the distributed ones [7], [26], [27], [31] .…”

“…The development of a loosely coupled Component (subsystem, module or services) is allocated as a development task to one Distributed Team [7], [23], [26], [24], [31] (D). In this case the coordination among teams is not an issue.…”