«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
We grouped the products into global and non-global products, depending on whether the product has been developed using GSD or not. Furthermore, we applied a further characterization of the architectural knowledge evaluation criteria from Table 5.2 using the key elements of architectural knowledge. We identiﬁed four clusters of architectural knowledge evaluation criteria: documentation, architectural knowledge (including the key elements Ass, Alt, Dec, Dep, and Rat), solution fragment (including the key elements Des, Dom, Pat, and Env), and performance (including the key element Map).
Elements labelled “n/a” in Table 5.4 indicate that the selected evaluation criterion was not inside the scope of that speciﬁc software product assessment (e.g., it was deemed
not applicable for some reason).
We make the following observations on the application and description of the architectural knowledge evaluation criteria in the software product assessments under study.
We list our observations per cluster of architectural knowledge evaluation criteria:
Documentation – Crit. 7 – Documenting application architecture and design is applied in three software products that have been developed using GSD. Furthermore, in two of these products, its application has been described as well. Yet, we observe that Crit 1. – Appropriate views and viewpoints has either not been applied in the architectural descriptions of the products to address the needs of the stakeholders involved (IEEE, 2000) (Product H), or has not been included in the assessment scope (products A, B, and D).
We observe that Product G explicitly incorporates views and viewpoints whereas Product E has used views and viewpoints without a sufﬁcient description or explanation of its application. Furthermore, the architecture description of Product G elaborates on each view in additional reference documents.
Rationale – The two evaluation criteria (Crit. 6 – Design rationale and Crit. 12 – Rationale) that fall in this category are not always applied in the software products under study; when they are applied (at products A, D, C, F, and G), its application has not been described. E.g. in the evaluation report of Product A, developed in a large
GSD project, the auditors of this assessment conclude that:
“(... ) the description of the rationale and assumptions in the architecture description is very minimal.”
795. Product Practices for AKM in GSD
Solution Fragment – Crit. 4 – Decomposition and layering and the use of Crit. 5 – Design patterns and architectural patterns in general are well-known approaches (measures) to reduce complexity in a software product. The application of these measures, however, is rather scarce, both in products developed using a single development site and using GSD. Apart from that, the only explicit occurrence of a measure in this category is with Crit. 8 – Explicit external dependencies at Product B. Further examination of the assessment of Product B showed no speciﬁc circumstances in which this measure is applied. It is applied and described in a functional design and in the installation manual of the product. In Product A, on the other hand, the criterion is not applied, causing the product to be assessed as ‘overly complex’.
Performance – Various architectural knowledge evaluation criteria have to do with a speciﬁc quality criterion, i.e., performance (termed ‘time behavior’ in (ISO/IEC, 2001)).
We observe that in most cases, these architectural knowledge evaluation criteria either have not been applied (at most products developed using GSD) or have been left outside the scope of the assessment (at most products developed using a single development site).
5.5 Discussion of the Results In this research, we showed what key elements constitute architectural knowledge. Using these key elements and a series of software product assessments, we determined which key elements of architectural knowledge are made explicit in the software product (so-called architectural knowledge evaluation criteria). We focused on differences between products that were developed using global software development and those that were developed using a single development site. As such, this research sheds light on what architectural knowledge measures are applied in GSD to improve the quality of software products.
If a similar approach was used during development of the software product instead of only when development has been completed, feedback could be given to the software development organizations in a timely fashion. This would allow for adequate measures to be taken to increase the quality of the software product during the development phase.
In contrasting software products developed using GSD with products developed on a single development site, we did not ﬁnd signiﬁcant differences between the two groups.
We do observe some overall results on the application of architectural knowledge in products developed using GSD.
Software products developed using GSD, as those developed using a single development site, typically have an architectural description. This conﬁrms an increased atten˚ tion towards documentation in GSD, as expressed in (Agerfalk and Fitzgerald, 2006), although we have not found evidence for an overly focus on documentation in these products. On the other hand, the architectural descriptions generally do not seem to be organized using views and viewpoints to address speciﬁc stakeholder concerns (Clements et al., 2003). Apparently, the beneﬁts of a view-based architectural description as described by e.g., (Sangwan et al., 2006) are not yet widely acknowledged.
80 5.5. Discussion of the Results
Beneﬁts of capturing architectural knowledge that enable architecting as a decisionmaking process (i.e., assumptions, alternatives, and rationale) are not yet widely accepted in GSD. This is in line with an earlier study we conducted (see Chapter 2, but still shows that the perceived beneﬁts need to be communicated further, especially in GSD environments.
Architectural knowledge that focuses on solution fragments is not regularly made explicit in software products or their documentation. This poses a question on how knowledge on these topics is shared in the GSD projects. These ﬁndings appear to contradict the focus on overly (solution-based) documentation generally propagated by GSD literature.
Performance is an important quality attribute which, according to the auditors, and acknowledged by (Bachmann and Bass, 2001), requires to be addressed by architectural knowledge. It is striking that in hardly any software product information on bottlenecks, scalability, load balancing, or single-points-of-failure can be found. Furthermore, we learned that this cluster of architectural knowledge seems to be not applicable in projects running on a single site; surely, performance-dependent systems are not conﬁned to being developed using GSD.
Several architectural knowledge evaluation criteria were left outside of the scope of the software product assessments we studied. Yet, the criteria used in this study are universal criteria for high-quality software products. Consequently, the understanding of the importance of these evaluation criteria and their beneﬁts still can be improved by explicitly incorporating these criteria in an evaluation framework.
5.5.1 Limitations Our study was performed on a subset of software product assessments on business administration systems performed by an IT consultancy ﬁrm in The Netherlands. We use this study to gain insight into measures taken in software products to make explicit architectural knowledge. As such, this study does not aim to give a broad overview of the status quo of software product quality, but aims at sparking a discussion on the use of product-based measures related to architectural knowledge to increase software product quality in general and, more speciﬁcally, in GSD.
81 6 Identifying Practices for Architectural Knowledge Management in Global Software Development In the previous two chapters, we have described studies that were focused on identifying how architectural knowledge management occurs in global software development.
The results showed that process practices can provide solutions to issues involved in GSD. Furthermore, we found that product practices for architectural knowledge management do not appear to contribute substantially to the quality of products developed using GSD. In this chapter, we take a different perspective. We identify whether architectural knowledge management can leverage the solutions that are available from the requirements engineering discipline to address the challenges in GSD.
6.1 Introduction In the past few years, an increasing interest in architectural knowledge management can be recognized in the software architecture community (Jansen and Bosch, 2005;
Kruchten et al., 2006; Babar et al., 2007; van der Ven et al., 2006b). Generally, architectural knowledge is regarded as important to guide the development and evolution of software systems (Kruchten et al., 2006).
With the trend of global software development, architectural knowledge management becomes even more important due to challenges that arise as a result of the geographical, temporal, and socio-cultural distance innate to GSD (Holmstr¨ m et al., o 2006). Overviews of the challenges in GSD have been widely reported in (Battin et al., ˚ 2001; Agerfalk et al., 2005; Holmstr¨ m et al., 2006; Clerc et al., 2007a,b) and include o lack of informal contact, language differences, and coordination complexity, see e.g., ˚ (Agerfalk et al., 2005).
Solutions to overcome GSD challenges generally deal with the way individuals interact with each other in a distributed setting. These solutions are provided in terms of communication and coordination strategies (Herbsleb and Grinter, 1999a; Herbsleb, 2007; Lanubile et al., 2003). In these strategies, recording decisions about the architec
836. Identifying Practices for AKM in GSD
ture plays a pivotal role (Clerc et al., 2007a; Herbsleb and Grinter, 1999a). However, we are currently lacking detailed insight into architectural knowledge management practices that can effectively be applied in a GSD setting, following observations from the literature on challenges in knowledge sharing in a GSD situation (Desouza et al., 2006;
Balaji and Ahuja, 2005).
To address this lack of insight, we build on the discipline of requirements engineering. The requirements engineering discipline is a well-discussed example of a discipline that becomes challenging in GSD, see e.g., (Hsieh, 2006; Damian, 2007). We observe a close resemblance between a set of requirements for a software system and a set of architectural decisions taken for that software system: what one person regards as requirements for a software system, another person may regard as architectural decisions (van Vliet, 2008; de Boer and van Vliet, 2009). Furthermore, we conjecture that the same challenges that the requirements engineering discipline faces with GSD hold for architectural knowledge management practices in GSD as well: as with requirements, architectural decisions too need to be communicated across different sites in order to maintain a shared vision of the software system that is designed.
We have constructed a set of architectural knowledge management practices based on a study of relevant literature on the requirements engineering discipline related to GSD. We describe these practices using a light-weight pattern language. The elements of this pattern language and its application on describing architectural knowledge management practices may help organizations in making a well-supported choice between architectural knowledge managements practices for application in GSD projects.
We provide an initial validation of the usefulness and effectiveness of these practices through semi-structured interviews on these practices within a large IT service provider.
This chapter is structured as follows. In §6.2 we list the approach we applied for this research. Next, in §6.3 we povide an overview of the resulting architectural knowledge management practices in GSD. We then provide an initial validation in §6.4 and list our conclusions in §6.5.
6.2 Research Approach In this section, we describe our approach to select relevant literature for this research in §6.2.1 and describe a light-weight pattern language for the description of the architectural knowledge management practices in §6.2.2.
6.2.1 Literature research We built a representative subset of relevant literature on the topic of requirements engineering in relation to global software development. First, we identiﬁed important software engineering conferences on this subject, such as the ICSE GSD workshops, the ICGSE ’06 and ’07 conferences, and the RE conferences. Subsequently, we collected the proceedings of these conferences. In addition, we selected special issues from relevant journals (Communications of the ACM, IEEE Software).
84 6.2. Research Approach
In our search to collect GSD requirements engineering practices that can help in overcoming GSD challenges, we scanned the abstract, introduction, and conclusion of all contributions. Contributions which explicitly reported on validated practices were studied in full detail.
After having collected the GSD requirements engineering practices, we translated these practices, if needed, to the discipline of architectural knowledge management.
When the requirements engineering practices mentioned “requirements”, we translated this into “architectural decisions”; when the practices mentioned the “requirements engineering discipline”, we translated this into the “architecting phase” or “architecture development phase”, following the similarities discussed in §6.1. In this way, we ensure that we stay fully in line with the practices as they were initially reported in the requirements engineering literature; we list the references to the requirements engineering literature throughout the description of the practices.