In Chapter 4 we presented a specific practice used in multi-site development. How- ever, other practices and general characteristics of multi-site development have al- ready been discussed in many publications.
Wongthongtham et al. [135] discussed different advantages and challenges in multi-site development. They list, among others, the need for frameworks support- ing communication and knowledge sharing [135, p. 355]. Additionally, they mention a need for technology tools that would assist in multi-site development [135, p. 357]. Both of these needs are addressed by the process and tool proposed and presented in Section 4.2.
The need for communication and more generally recognition of social and tech- nical interdependencies in development teams were discussed by Amrit and van Hillegersberg [6]. They reviewed known problems of both software architecture and processes being altered during the life-cycle of a development project despite the use of best development practices. They recognise Socio-Technical patterns that link so- cial dependencies with technical ones in a development process. They additionally propose a tool that can identify the dependency patterns based on communications between team members. Amrit’s and van Hillegersberg’s [6] work discusses possible problems in multi-site projects as well as possible solutions to the problems.
A practical solution to specific problems in multi-site software development was proposed by Lars Tax´en [123]. The solution is based on practices in the telecom- munication industry, namely one case organisation Ericsson. Tax´en proposes the Integration Centric Development (ICD) approach consisting of three sub-processes. The focus of ICD is on promoting common understanding of a system developed at the functional level as well as increment and integration planning levels [123, p. 769]. Even though ICD has been used only in one organisation, the results were col- lected based on around 140 projects [123, p. 772] and they show that the method is valid for multi-site development where communication and common understand- ing are crucial [123, p. 779]. The ICD method is an example of an industry response to problems encountered in multi-site software development.
A specific problem of system architecture knowledge sharing has been presented by Ovaska et al. [97]. They report on industry case findings where it was found that simple coordination of development activities was not enough and suggest concen- tration on interdependencies between development activities [97, p. 244]. Ovaska et
al. additionally propose architecture as means of communication about the system,
7.3. MULTI-SITE DEVELOPMENT 81 tionally, Clerc et al. [29] have specified a method for assessing organisation compli- ance with defined architectural rules at multiple sites. Also Clerc et al. point out that the main problem in multi-site development is not the architectural rules, but the gathering and distribution of knowledge about those rules in an organisation. Another approach to architecture knowledge sharing has been presented by Victor Clerc [28], who collected architectural knowledge management practices as a set of patterns. Those patterns, similarly as in other publications, put strong emphasis on communication. The communication is promoted by practices and tools.
Finally, there are a number of industry case studies that describe experiences from multi-site software development initiatives. For example, Herbsleb et al. [60] report on experiences from nine projects carried out in Siemens Corporation. The report points out practical challenges and lessons learned in project coordination, develop- ment environment, and general communication, among others. An additional report on multi-site development practices at Siemens was presented by Bass et al. [15].
As can be seen from the number of various reports in literature, multi-site devel- opment adds up to the complexity of software development. There are, however, practices that aim at mitigating the effect of distribution in development projects. Moreover, concerns related to the architecture of the system developed were re- ported frequently as well as various methods for ensuring the architecture decisions communication and later enforcement.
The reoccurring themes of issues in multi-side development could be listed as follows:
• communication and knowledge sharing [135, p. 355],
• software architecture alterations caused by social and technical interdependen-
cies [6], and
• development activities’ interdependencies [97].
The architecture conventions ensuring process and tool supporting the rules vali- dation (ARA), proposed in Chapter 4, addresses some of these issues. There exist also other tools that allow for validating software against certain architectural rules. For example, a commercial tool Lattix1 can be used as a validation tool for archi-
tecture rules. In fact, Lattix provides additional architecture refactoring features that are not in the scope of the described process. Furthermore, there is an open source tool Macker2that has capabilities for checking rules defining package or class level
references. Another tool that validates specific architectural rules was proposed by Selonen and Xu [113]. Their tool, called artDECO, uses UML profiles for architecture validation, which can be done at a lower level of granularity than packages, which are the granularity level utilised by ARA, e.g., at a class level.
Communication and knowledge sharing are encouraged in the process by for- malising the communication between the different sites of the development team that implements and designs and validates the software (i.e., the required architec- ture decomposition rules, component mappings to the Java packages, and the binary
1http://www.lattix.com
82 7. RELATED WORK
code). Additionally, the whole process aims at ensuring that the architecture is not altered by the multi-site character of the development, which is similar to concerns of social interdependencies. However, the architecture rules ensuring process does not adders any Socio-Technical patterns [6] as such. Finally, the development activi- ties’ interdependencies are addressed by the architecture rules ensurance process to a certain extent. Only the main development activities are organised in the process: the high level design, component design and implementation, and verification. The process does not address fine-grained activities.