WWW.DISSERTATION.XLIBX.INFO
FREE ELECTRONIC LIBRARY - Dissertations, online materials
 
<< HOME
CONTACTS



Pages:     | 1 |   ...   | 21 | 22 || 24 | 25 |   ...   | 32 |

«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»

-- [ Page 23 ] --

3. The architect extracts previous architectural design decisions and rationale for the changing requirement.

4. The architect identifies 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 finds 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.

Scenario description

1. The architect extracts all the components that realize or satisfy the changing requirement in different versions, functional or non-functional.

2. The architect finds 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 specifically 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 specifications 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 figure 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.

5.1).

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 conflict 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 identified 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 finds the components for implementing the requirements by navigating to the wiki page of the requirement in different versions. The architect then finds 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 defined 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 identified 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 codification 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: first of all, functionality to author and share architectural knowledge and functionality to track and trace wiki content. This functionality supports a codification strategy towards knowledge management. Second, profile 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 codification and a personalization strategy towards architectural knowledge management is beneficial 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 benefits 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 beneficial. 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 first 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 efficient 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).



Pages:     | 1 |   ...   | 21 | 22 || 24 | 25 |   ...   | 32 |


Similar works:

«3 He a lt h 0 0 Fire 0 2 0 Re a c t iv it y P e rs o n a l P ro t e c t io n Material Safety Data Sheet Ammonia-Ammonium Chloride Buffer TS MSDS Section 1: Chemical Product and Company Identification Product Name: Ammonia-Ammonium Chloride Buffer TS Contact Information: Sciencelab.com, Inc. Catalog Codes: SLA2323 14025 Smith Rd. CAS#: Mixture. Houston, Texas 77396 US Sales: 1-800-901-7247 RTECS: Not applicable. International Sales: 1-281-441-4400 TSCA: TSCA 8(b) inventory: Ammonium hydroxide;...»

«Bringing Calm to Chaos A critical incident review of the San Bernardino public safety response to the December 2, 2015, terrorist shooting incident at the Inland Regional Center Rick Braziel, Frank Straub, George Watson, and Rod Hoops Bringing Calm to Chaos A critical incident review of the San Bernardino public safety response to the December 2, 2015, terrorist shooting incident at the Inland Regional Center Rick Braziel, Frank Straub, George Watson, and Rod Hoops This project was supported by...»

«Novel anti-infective secondary metabolites and biosynthetic gene clusters from actinomycetes associated with marine sponges Neue anti-infektive Sekundärmetabolite und biosynthetische Gencluster aus mit marinen Schwämmen assoziierten Actinomyceten Dissertation towards a Doctoral Degree at the Graduate School of Life Sciences Julius-Maximilians-University Würzburg Section: Infection and Immunity submitted by Sheila Marie Pimentel Elardo from Cebu City, Philippines Würzburg, November 2008...»

«The ‘STage’ North Rhine Westphalia (Lippstadt circled) & Germany The part which was East Germany is overlaid in grey Tales from the barracks to the bar (with some soldiering in between) 1973 to 1978 Smudge’s Gemütliches Lippstadt Ian Smith Tales from the barracks to the bar – with some soldiering in between BATTERY ORDERS MAJOR D I SASTER ROYAL ARTILLERY COMMANDING 56 (OLPHERTS) HEAVY BATTERY ROYAL ARTILLERY LIPPSTADT TUESDAY 6 SEPTEMBER 1973 SERIAL No 107 ROUTINE FOR WED 7 SEPTEMBER...»

«“Godtalk: Theist Language and Unitarian Universalist Children” 20 August 2006 Unity Church–Unitarian Worship Leader: Kerri Meyer Worship Associate: Sonia Hazard READING: “You’re It” Hafiz, 14th century; translated by Daniel Ladinsky God Disguised As a myriad things and Playing a game Of tag Has kissed you and said, “You’re it I mean, you’re Really IT!” Now It does not matter What you believe or feel For something wonderful, Major-league Wonderful Is someday going To Happen....»

«TRANSCRIPT CLOSED PROCEEDINGS ENVIRONMENT, NATURAL RESOURCES AND REGIONAL DEVELOPMENT COMMITTEE Inquiry into the CFA training college at Fiskville Melbourne — 15 June 2015 Members Ms Bronwyn Halfpenny — Chair Mr Bill Tilley Mr Tim McCurdy — Deputy Chair Ms Vicki Ward Mr Simon Ramsay Mr Daniel Young Mr Tim Richardson Staff Executive officer: Dr Greg Gardiner Research officer: Dr Kelly Butler Witnesses Mr Norman Carboon, and Mr Bruce Carboon Necessary corrections to be notified to executive...»

«A83 Trunk Road Route Study Part A A83 Rest and Be Thankful Final Report February 2013 Document Control Sheet BPP 04 F8 Version 14 July 2012 Project: A83 Trunk Road Route Study Project No: B1557610 Client: Transport Scotland Document Title: Part A – A83 Rest and Be Thankful Ref. No: Originated by Checked by Reviewed by Approved by NAME NAME NAME NAME ORIGINAL (Draft) Charles Macklin Graeme Herd Stuart Turnbull Helen Bradley DATE INITIALS INITIALS INITIALS INITIALS 07/12/2012 Published Draft...»

«Real Time Arabic Translation System For Signboard Images Based on Printed Character Recognition ‫وف ا‬ ‫ا‬ ‫د‬ ‫تا‬ ‫را‬ ‫ا‬ ‫ا‬ ‫ما‬ By Shoroq Almamon Alsharari 400920235 Supervisor Dr. Rafeeq Abdul Rahman A. Al-Hashemi A Thesis Submitted in Partial Fulfillment of the Requirements for the Master Degree in Computer Science Faculty of Information Technology Middle East University ‫‪II‬‬ ‫3102, ‪January‬‬ ‫‪AUTHORIZATION FORM‬‬...»

«UNIVERSITEIT GENT FACULTEIT POLITIEKE EN SOCIALE WETENSCHAPPEN Homestay programme as potential tool for sustainable tourism development? Case study of Kiangan, Philippines Beleidsrapport Aantal woorden: 22 871 EMMA ACHTEN MASTERPROEF MANAMA CONFLICT AND DEVELOPMENT PROMOTOR: PROF. Bernard Mazijn ACADEMIEJAAR 2013 – 2014 Acknowledgements Conducting research in a complete strange country and culture is not without concerns. Without the warm help and support of various individuals, I wouldn’t...»

«KELLEY DRYE & W ARREN LLP A LI MIT E D LIA BI LIT Y P ART NER SHI P 400 AT L ANT I C ST REET NEW YORK, NY FACSIMILE WASHINGTON, DC (203) 327-2669 ST AMFORD, CONNECT I CUT 069013229 CHICAGO, IL www.kelleydrye.com PARSIPPANY, NJ (203) 324-1400 BRUSSELS, BELGIUM M. RIDGW AY BARKER DIRECT L INE: (203) 351-8032 EMA IL: mbarke r@kel leydr ye.com AFFILIATE OFFICES MUMBAI, INDIA October 14, 2010 Securities Act of 1933 Rule 144 Rule 414 Form S-3 Form S-4 Form S-8 Securities Exchange Act of 1934 Section...»

«6.045J/18.400J: Automata, Computability and Complexity Prof. Nancy Lynch, Nati Srebro 6.045 Final Exam Solutions May 18, 2004 Susan Hohenberger Name: • Please write your name on each page.• This exam is open book, open notes.• There are two sheets of scratch paper at the end of this exam.• Questions vary substantially in difficulty. Use your time accordingly. • If you can not produce a full proof, clearly state partial results for partial credit. • Good luck! Problem Points Grade 1...»

«Guide to Documents Relating to American Indians in Montana Identified and Collected by the Natives of Montana Archival Project (NOMAP) From Repositories in the National Archives and Records Administration, Smithsonian Institution & Library of Congress 2008-10 Helen Cryer (Saddle Lake Cree, ’08) Miranda McCarvel (’08-10) Carole Meyers (Oneida/Seneca/Blackfeet) (’10) Wilena Old Person (Blackfeet/Yakama, ’08-09) Glen Still Smoking Jr. (Blackfeet, ’08) Eli Suzukovich III (Cree, ’08)...»





 
<<  HOME   |    CONTACTS
2016 www.dissertation.xlibx.info - Dissertations, online materials

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.