«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
3. The architect extracts previous architectural design decisions and rationale for the changing requirement.
4. The architect identiﬁes new design issues that are related to the changing requirement.
5. The architect proposes one or more alternative options to address these new design issues.
6. The architect evaluates and selects one architectural design decision from the alternative options. Criteria for the evaluation include that the selected decision should not violate existing architectural design decisions and that the selected decision should satisfy the changing requirement.
7. The architect evaluates whether the new architectural design outcome can still satisfy those non-functional requirements that are related to the changing functional requirement.
Scenario 3 – design impact evaluation An architect wants to evaluate the impact a changing requirement may have on the architecture design across versions of this requirement.
Problem – The architect needs to understand and assess how the changing requirement impacts the architecture design.
Solution – The architect ﬁnds all the components that are used to implement the changing requirement in different versions and evaluates the impact of the changing requirement on the architecture design.
1. The architect extracts all the components that realize or satisfy the changing requirement in different versions, functional or non-functional.
2. The architect ﬁnds all the interrelated requirements in the same version and the components that implement them.
3. The architect evaluates how the changes between different versions of the requirement impact on the architecture design. Furthermore, the architect can recover the decision made for addressing the changing requirement.
8.5.2 Prototype implementation: SE-Wiki The use cases described in §8.5.1 have been implemented in a semantic wiki, termed SE-Wiki. In the semantic wiki, we implemented an ontology to speciﬁcally support co-evolving architectural requirements and design (see Tang et al., 2011, Fig. 2). Furthermore, we describe how the prototype supports the use case scenarios by using the example of the development of a Portal.
Scenario 1 – software reuse Description – An architect wants to check if existing software can be reused to implement a new functional requirement which is similar to existing functional requirements that have been implemented (see §8.5.1).
Example – A new functional requirement Change User Access: The Portal should be able to change user’s access rights to resources3 is proposed by the Portal Manager.
The architect thinks that this new functional requirement is similar to an existing functional requirement, i.e., Track Usage: The Portal tool should be able to track usage of resources by all users. The architect wants to check if the existing software (i.e., design 3 Resources in the project under study refer to all the information maintained by the Portal.
118 8.5. Implementing a Semantic Wiki
outcomes/architecture) that is used to implement the requirement Track Usage can be reused to implement the new requirement Change User Access, especially with regard to the quality requirements.
Since the requirements and architecture speciﬁcations are already semantically annotated in SE-Wiki, a semantic query can be employed to query the direct and indirect tracing relationships (see Tang et al., 2011, Fig. 2) from an instance of Functional Requirement (i.e., the existing functional requirement Change User Access) to all the concerned Design Outcomes that realize this functional requirement, and all the Non-Functional Requirements that the Design Outcomes can satisfy. The snapshot of this scenario through a semantic query is shown in Fig. 8.1. The top part of this ﬁgure is the editing box for the semantic query input and the lower part shows the query results.
Figure 8.1: Scenario 1 through the semantic query interface in SE-Wiki Scenario 2 – changing requirement Description – An architect wants to update an architecture design because of a changing functional requirement (see §8.
Example – A functional requirement Change User Access: The Portal tool should be
able to change user’s access rights to resources is changed into Change User Access:
The Portal tool should only allow a System Administrator to change user’s access rights to resources. Accordingly, the design based on this requirement should be updated as well. To achieve this, the architect should make sure that this changing requirement has no conﬂict with related existing requirements, and understand the context of this requirement before updating the design. The architect then extracts all the related artifacts concerning this changing requirement by navigating to the wiki page of this requirement in SE-Wiki. The wiki page records all the artifacts (e.g., requirements, architectural design decisions, and design outcomes) related to this requirement as shown in Fig. 8.2.
Scenario 3 – design impact evaluation Description: Requirements are frequently changed from one software version to the next. An architect tries to evaluate and identify the impact of the changing requirements on architecture design, so that requirements and architecture design can be kept consistent.
Example: The requirement Change User Access is updated in the next version, i.e., Version 1: The Portal tool should be able to change user’s access rights to resources, and Version 2: The Portal tool should only allow System Administrator to change user’s access rights to resources.. The architect extracts different versions of the requirement with the same requirement ID using a semantic query (e.g., [[Category:Requirement]][[is identiﬁed by::DC 001]]), in which DC 001 is the DC element to identify the version of a requirement (see Tang et al., 2011, Fig. 2). The architect ﬁnds the components for implementing the requirements by navigating to the wiki page of the requirement in different versions. The architect then ﬁnds the other components for implementing related requirements through reasoning support (e.g., iteratively traverse all the related requirements), which is based on the reasoning rules and relationships deﬁned in the ontology. Using the information available to him, the architect can identify the changes to the architecture design in two sequential versions of the requirement. From that, the architect can evaluate the change impacts to the architecture design. Fig. 8.3 shows the comparison of the wiki pages of a requirement across two versions (the left hand side shows the latest version of the requirement Change User Access, and the right hand side shows a previous version of Change User Access, which is superseded by the latest version). The requirement changes between versions with changed decisions and design
8.6 Conclusions In this chapter we have investigated how practices for architectural knowledge management in global software development may be implemented using (semantic) wikis. To this end, we have mapped the architectural knowledge management practices for GSD onto a list of generic wiki functionalities distilled from the literature. Furthermore, we have implemented several use cases for architectural knowledge in a prototype semantic wiki implementation, SE-Wiki.
The results show that wikis offer substantial functionality for implementing architectural knowledge management practices in GSD. Three of the identiﬁed practices can be implemented completely, another three can be implemented partially, and one practice cannot be implemented using wiki functionalities. The following architectural knowledge management practices for GSD can be implemented completely using wiki functionalities: ‘have a repository for architecture artifacts and architectural decisions’, ‘share relevant architectural knowledge to all sites’, and ‘traceability of architectural knowledge’. These practices mainly support a codiﬁcation strategy towards
knowledge management. Furthermore, the following architectural knowledge management practices for GSD can at most be partially implemented using wiki functionality:
‘have a clear organizational structure with communicating responsibilities across sites’, ‘quickly collect information on an architectural topic of interest’, and ‘propose and
1218. Supporting AKM in GSD
rank alternatives when taking decisions’. These practices mainly have a personalization strategy towards knowledge management, since it urges the knowledge workers to interaction with each other. Finally, the architectural knowledge management practice for GSD ‘frequent interaction across sites’ cannot be implemented using wikis. Wikis may be used in interacting across sites, but setting up (implementing) this practice requires planning of meetings and travels, which is up to project managers.
We furthermore conclude that several distinct wiki functionalities can be used to implement the architectural knowledge management practices: ﬁrst of all, functionality to author and share architectural knowledge and functionality to track and trace wiki content. This functionality supports a codiﬁcation strategy towards knowledge management. Second, proﬁle pages and authentication support a personalization strategy towards knowledge management; this functionality does not cater for capturing architectural knowledge itself, but is used to provide information that supports interaction between knowledge workers. Hence, we conclude that a hybrid approach including a codiﬁcation and a personalization strategy towards architectural knowledge management is beneﬁcial in GSD (Babar et al., 2007; Hansen et al., 1999).
Our prototype implementation SE-Wiki supports a traceability metamodel and implements several traceability use cases using a traceability ontology. Furthermore, SEWiki supports semantic annotation and traceability, and the annotated semantic wiki pages provide an information base for constructing semantic queries. These features support the architect in reasoning with architectural knowledge, independent of location, time zone, or socio-cultural borders. Once the architectural knowledge is captured in the semantic wiki, it may help in achieving the beneﬁts of GSD.
Unfortunately, we have not been able to validate the usefulness of the prototype semantic wiki in a real-life example, e.g., via a study at one of the industrial partners in our research project. Yet, given the informal feedback we did receive and experiences reported by (de Boer and van Vliet, 2011), we believe that the prototype is viable and can be effective. Hence, our prototype provides a valuable addition to address GSD challenges by allowing practitioners to effectively use architectural knowledge.
In our earlier research, we have shown that a sound communication structure which caters for communication across sites is important when distributing work and knowledge across sites (see e.g., Chapters 3 and 4). Implementing this communication structure is part of one of the architectural knowledge management practices for GSD but in fact has implications for all other architectural knowledge management practices considered in this research.
8.7 Implications The work described in this chapter has a number of implications. First of all, when populating a wiki with architectural knowledge, adhering to a structure may prove beneﬁcial. This structure helps in aligning various stakeholders with different cultural and organizational backgrounds. Although stakeholders from different geographical regions may use different terms, a sound basis is required to allow for reasoning with architectural decisions and proposed alternatives that are stored on the wiki. Elements
122 8.7. Implications
described in the core model of architectural knowledge (de Boer et al., 2007) can be useful to implement this structure. De Boer and van Vliet (2011) also list emerging research challenges that touch upon knowledge model alignment, knowledge versioning, and knowledge updates. Second, we acknowledge that a wiki populated with architectural knowledge alone does not provide a guarantee to effective architectural knowledge management in global software development; research has shown that the role of the decision-maker is dominant (Al-Ani and Redmiles, 2009). Hence, following common pitfalls regarding the adoption, a clear adoption strategy needs to be chosen, see e.g., (Farenhorst and van Vliet, 2008; Mader, 2007). This adoption strategy should ﬁrst of all lower thresholds of capturing architectural knowledge on the wiki. Criteria for when (and when not) to store architectural knowledge will need to be devised.
123 9 The Use of Architectural Knowledge Management Practices in Agile Global Software Development In this chapter we report on a study conducted to identify what practices for architectural knowledge management in global software development are used in practice. By conducting several interviews with practitioners at three development sites of an organization involved in global software development, we build a thorough view on how the organization uses and manages architectural knowledge across the distributed development sites.
9.1 Introduction Over the past years, we observed an increase in attention to the management of knowledge in global software development organizations. For these development organizations, timely availability of accurate knowledge is important for effective and efﬁcient software processes (see e.g., (Al-Ani and Redmiles, 2009; Kotlarsky et al., 2008), and the MARK and KNOWING workshop series, held in conjunction with the IEEE Requirements Engineering Conference and IEEE International Conference on Global Software Engineering series respectively).