FREE ELECTRONIC LIBRARY - Dissertations, online materials

Pages:     | 1 |   ...   | 7 | 8 || 10 | 11 |   ...   | 32 |

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

-- [ Page 9 ] --

Within our research project, we are developing, notations, tools, and associated methods to extract, represent, and use architectural knowledge. This chapter has shed light onto the most important use cases for architectural knowledge from a practitioners’ perspective. Although specialized tool support for the architects is still generally lacking, we use these results to develop tools for the most important use cases for architectural knowledge (see Chapter 8). In addition, we continue the work in our project to further embed the view of architectural knowledge and architectural decisions in practice.

39 3 Architectural Knowledge Management Practices for Compliance in Global Software Development This chapter describes a method for assessing organizations involved in global software development to determine deficiencies in securing compliance with architectural knowledge. We report on a case study in which we applied the method in a large organization involved in global software development. The case study reveals that, while initially problems were expected with regard to the structure of the architectural rules, the real problems pertain to the process by which the architectural rules are captured, disseminated, and secured within the organization. Several recommendations are provided to improve this process.

3.1 Introduction An increasing number of organizations applies offshore software development in order to deliver solutions to its customers. This kind of global software development faces additional problems compared to collocated development, such as differences in culture and spreaded software development activities. This spread requires additional communication and coordination efforts. These efforts aim to guarantee successful integration of subsystems into a working software product that meets the requirements.

Aforementioned communication and coordination efforts can be addressed by issuing rules for the software architecture. Architectural rules are the principles and statements on the software architecture that must hold at all times, and thus must be complied with. Architectural rules are not limited to software artifacts only, but can include organizational processes that manipulate or create the artifacts as well. For example, a rule on branching might read: “a subsystem is the unit of branching, i.e., a subsystem branch is a branch of all assets in the subsystem”.

When an organization has a set of architectural rules installed, these rules act as (additional) non-functional requirements to the software architecture. Lack of compliance with architectural rules often results in architectural mismatch (Garlan et al.,

413. AKM Practices for Compliance in GSD

1995), causing problems when reusing or integrating certain software elements from different sites. Examples of these problems include an error-prone construction process or excessive code size.

For an organization to comply with architectural rules, the rules need to be enforced.

Besides enforcing the architectural rules themselves, achieving compliance requires guidelines for how to disseminate and secure the rules within the different development sites.

Differences in culture and a spread across different locations hamper compliance with architectural rules at organizations involved in GSD. This puts pressure on the guidelines targeted at disseminating and securing the rules. In order to bring the use and effectiveness of these guidelines to the surface, an assessment of the way these GSD organizations secure their architectural rules may prove valuable.

This chapter describes a method for assessing organizations involved in GSD to determine deficiencies in securing architectural compliance. We report a case study in which we applied the method in a large organization in global software development, Organization A. The case study revealed that, while initially problems were expected with regard to the structure of the architectural rules, the real problems pertained to the process by which the architectural rules are captured, disseminated, and secured within Organization A.

This chapter is structured as follows. In §3.2 we describe related work on architectural rules and methods to evaluate software architectures. Next, §3.3 introduces Organization A, where we performed the case study: a large organization involved in GSD in the consumer electronics domain. The method used and the experiences in applying the method in the organization is described in §3.4. Next, §3.5 describes the results of the assessment and the subsequent steps the organization took. Finally, §3.6 lists our conclusions.

3.2 Related Work Recent work regards software architecture as a set of architectural design decisions (Jansen and Bosch, 2005; Jansen, 2008). Capturing architectural design decisions enables more architectural knowledge to be representated explicitly in the software architecture and thus prevents vaporization of architectural knowledge. Architectural knowledge consists of the set of architectural design decisions and the resulting design (Kruchten et al., 2006). A specific subset of the architectural knowledge is formed by architectural rules. The need for architectural rules to guide and constrain the amount of ‘artistry’ in software architecture was initially identified in (Boasson, 1995).

Architectural rules are those architectural design decisions that need to be complied with throughout the organization. Architectural rules can be defined using a decision view on software architecture as described in (Smolander, 2002).

Over the past few years, methods for assessing and evaluating software architectures (Clements et al., 2001; Obbink et al., 2002) have been developed. The steps in the method we followed fit the general guidelines on how to conduct architectural reviews as described in the SARA report (Obbink et al., 2002).

42 3.3. Case Study Description

Herbsleb et al. (2001) report on a large case study in which global software development was compared to collocated development. Their contribution shows that GSD lowers the degree of informal communication and consequently the level of insight a site has into the software developed at another site. GSD lacks a certain amount of trust provided by informal communication and needs a more formal communication process.

Furthermore, according to (Ovaska et al., 2003), coordination of GSD can be organized according to standardized processes and written specifications. Our work regards software architecture as a coordination mechanism since the architecture divides a system into components that can be developed relatively autonomously. The processes and specifications that guide this development form what we regard as architectural rules.

Compliance with these rules is of paramount importance for GSD organizations. However, achieving compliance requires additional effort and guidelines. In this chapter, we report on our experience in assessing an organization involved in GSD for these efforts and guidelines.

3.3 Case Study Description We performed a case study at Organization A, a large software development organization that has multiple sites where software is being developed for a consumer electronics product. Software development within this organization is structured in projects. Each project delivers a new type of the product. As such, each project develops software to satisfy the requirements that hold for that product type.

To efficiently deliver the software for these product types, Organization A has developed a product-line architecture. The product-line architecture distinguishes several subsystems, each focusing on specific functionality, such as signal processing or the menu structure of the device. Subsystems are organized into layers. This is but a logical organization of the subsystems into manageable chunks. The relation between projects, layers, and subsystems is depicted in Fig. 3.1.

Subsystems are developed by dedicated subsystem development teams, headed by a project manager and consisting of an architect, a configuration manager, and one or more software engineers. Each subsystem development team is located at a single site.

Together, this organization into subsystems and the location of a subsystem development team at a specific site result in a certain amount of autonomy of the subsystem development teams. In order not to let this autonomy lead to problems with integration of software from multiple subsystems, an architecture team is responsible for maintaining the product-line architecture. The architecture team consists of the chief architect, representatives of the major projects that are running, and some main subsystem architects. Most members of the architecture team are located at one particular development site. To maintain the architecture, the architecture team issues architectural rules in small, text-based documents called architectural notes, or archnotes for short. Each archnote addresses a coherent set of architectural rules, e.g., all rules that have to do with naming conventions are captured in a single archnote. In total, 53 archnotes exist containing some hundreds of architectural rules.

Archnotes are mainly targeted at engineers, subsystem architects, and configura

–  –  –

Figure 3.1: Projects versus subsystems at Organization A.

Subsystems in bold deliver software for use in more than one type tion managers. These employees are included in discussions on architectural decisions.

Only decisions that concern all subsystems become rules and are included in archnotes.

A dedicated member of the architecture team documents the architectural rules.

Archnotes are placed on a central intranet website. New archnotes are communicated to the subsystem architects using a notification mechanism from a software conguration management (CM) system. The CM system provides a link to the archnote and some additional information. The subsystem architect uses the additional information to inform the employees in the subsystem development team of the new archnote.

Each subsystem development team itself is responsible for complying with the architectural rules in the archnotes.

Organization A experiences some problems in disseminating architectural rules and

securing compliance with these rules within the organization:

• Engineers believe the formulation of architectural rules is too abstract. Therefore, they do not always read them. The extent to which architectural rules are read is presumed to differ across different development sites.

• Engineers do not always understand the architectural rules.

• Architectural rules do not cover all relevant decision topics.

Based on these problems, we hypothesized that a problem for not understanding and reading the archnotes was in the way the archnotes are structured. Improving this structure would then help in understanding the architectural rules. Following that, dissemination of the archnotes would be improved. Better dissemination of the knowledge in the architectural rules would then result in better compliance with the architectural rules.

–  –  –

We performed an assessment of the way compliance is secured with architectural rules to verify the aforementioned hypothesis. We used the assessment results to identify improvement points for the structure and use of the archnotes.

3.4 Performing the Assessment This section describes the phases of the assessment method as well as the results of applying the method in the case study. We used an assessment method that helps to reveal problems that exist in securing architectural compliance.

In terms of the SARA report (Obbink et al., 2002), the objective of our assessment was to identify opportunities for improvement in architectural compliance. This objective corresponds with one of the concerns of the chief architect. The preparation of the assessment focused on getting clear the goal of the assessment (reveal problems that exist in securing architectural compliance), identifying the scope (the architectural rules), and selecting participants for the assessment (global architects and important roles in the subsystem development team, such as subsystem architect, engineer, and configuration manager). The assessment activities themselves focused not so much on the architecture itself, but rather on the guidelines and rules in place for the architecture. In observing the guidelines and rules, we specifically regarded both the structure of the architectural rules and the use of the archnitectural rules. The assessment was concluded by presentations of the assessment results (conclusions and improvement suggestions) to the line management of Organization A and several subsystem development team representatives.

We provide a general overview of the method. The next subsections describe each phase of the assessment method in more detail. In the next subsections, results from the case study are described in italics.

Fig. 3.2 provides an overview of the assessment activities:

1. Based on the objective of the assessment, our analysis starts with determining and analyzing the audience (population) of the architectural rules. This results in insight into the usage of the architectural rules at different sites.

2. Based on insight into the audience of the architectural rules, we construct a questionnaire. The questionnaire contains specific questions on the following topics:

the relevance of architectural rules, the perception of participants of the role of architectural knowledge within the organization, and the participants’ opinion of the architecture team. These questions aim to provide information on the hypotheses formulated in §3.3. Next, we send out the questionnaire to a selection of employees which includes at a minimum all major roles involved at the major development sites. We analyze the answers to the questionnaire to find e.g., conflicting statements and to find specific suggestions as to where to dig deeper.

3. Using the same selection criteria as with the questionnaire, we select a subset from the questionnaire participants to conduct interviews with. We use the interviews to foster specific suggestions for removing deficiencies in securing

–  –  –

Pages:     | 1 |   ...   | 7 | 8 || 10 | 11 |   ...   | 32 |

Similar works:

«Lei Li 1195 Bordeaux Dr, Sunnyvale, CA 94089 http://www.cs.cmu.edu/~leili Research Interests Machine learning and mining for large scale data Deep learning and application to language understanding Probabilistic programming languages, inference algorithms and complier Time series and complex dynamical system Education Carnegie Mellon University, Pittsburgh, Pennsylvania USA Ph.D., Computer Science Department, Sep. 2011 Dissertation: Fast algorithms for mining co-evolving time series. (recipient...»

«Hochwasser-Aktionsplan Lippe Grundlagen, Überflutungsgebiete, Schadenspotenzial, Defizite und Maßnahmen Band I: Bericht und Karten Marktstraße Lippstadt, Hochwasser Juli 1965 im Auftrag des Staatlichen Umweltamtes Lippstadt Lipperoder Straße 8 59555 Lippstadt in Kooperation mit: Lippeverband Wasserverband Obere Lippe Hydrotec Aachen Dezember 2002 Hochwasser-Aktionsplan Lippe Wir danken allen Beteiligten für die Hilfestellungen bei der Bearbeitung und die jederzeit freundliche und...»

«What Does Classifying More Than 10,000 Image Categories Tell Us? Jia Deng1,3, Alexander C. Berg2, Kai Li1, and Li Fei-Fei3 1 Princeton University 2 Columbia University 3 Stanford University Abstract. Image classification is a critical task for both humans and computers. One of the challenges lies in the large scale of the semantic space. In particular, humans can recognize tens of thousands of object classes and scenes. No computer vision algorithm today has been tested at this scale. This...»

«To be published in: Textual practice, 2010, 24(6), 1003-1018 which should be cited to refer to this work. Indira Ghose Jesting with Death: Hamlet in the Graveyard When Eric Morecambe appeared on stage dressed entirely in black, nursing a skull, even the slightly obtuse Ernie immediately realized what was in the offing: Shakespeare’s Hamlet. The image of Hamlet holding a skull has become iconic for the play itself. In popular memory, it is linked to the other signpost of the play, the tagline...»

«  The Official Newsletter of the Caribbean Studies Association Issue:  February 2016 MESSAGE FROM THE PRESIDENT CSA Executive Putting all our Energies into a Council, 2015­2016 Successful 2016 CSA Conference in Haiti President: Carole Boyce­Davies The Program Chairs, Local Organizing Cornell University Committee and I remain optimistic about the benefits of realizing this Vice President: year’s CSA Conference in Haiti. While Keithley Woolward...»

«AZIENDA OSPEDALIERA UNIVERSITARIA INTEGRATA VERONA GUIDA PER IL RICOVERO IN OSPEDALE Gentile Signora, Egregio Signore. EDIZIONE SETTEMBRE 2014 Gli aggiornamenti della presente guida saranno disponibili sul sito www.ospedaleuniverona.it SEDE OSPEDALIERA BORGO TRENTO SEDE OSPEDALIERA BORGO ROMA Centralino 045 8121111 Sito: www.ospedaleuniverona.it In copertina: 1 “Pescatori di sabbia o Verona” di Angelo Dall’Oca Bianca Gentile Signora Egregio Signore, è stato accolto nella nostra Azienda...»

«INSECTA MUNDIA Journal of World Insect Systematics 0457 A checklist of natural enemies of Diaphorina citri Kuwayama (Hemiptera: Liviidae) in the department of Valle del Cauca, Colombia and the world Takumasa Kondo Corporación Colombiana de Investigación Agropecuaria (CORPOICA) Centro de Investigación Palmira, Calle 23, Carrera 37, Continuo al Penal Palmira, Valle, Colombia Guillermo González F. La Reina, Santiago, Chile Catherine Tauber Department of Entomology University of California...»

«Corporate Governance Statement The Hague, March 2016 aegon.com 1. Dutch Corporate Governance Code comply or explain As a company based in the Netherlands, Aegon N.V. (also being referred to as the “Company”) adheres to the Dutch Corporate Governance Code. The complete text of the Code can be found on www.commissiecorporategovernance.nl. Aegon endorses the Code and strongly supports its principles for sound and responsible corporate governance. Aegon regards the Code as an effective means of...»

«Estimation of liquefaction using Hachinohe geotechnical information and upgrade of that system *Yutaka HASHIZUME1) Naoki OYAMA2) and Kenji KANEKO 3) 1), 2), 3) Department of Civil Engineering, Hachinohe Institute of Technology, Aomori, Japan 1) hashizume@hi-tech.ac.jp ABSTRACT In land bordering the Pacific in the Tohoku area and Kanto area of Japan, a lot of liquefaction occurred by The 2011 off the pacific of Tohoku earthquake. There are three principal factors in liquefaction damage. Those...»


«Ayal Zaks Contact IBM Haifa Research Lab Voice: +972 4-829-6499 Information Haifa University Campus Fax: +972 4-829-6116 Mount Carmel E-mail: zaks@il.ibm.com Haifa, 31905, Israel https://researcher.ibm.com/researcher/view.php?person=il-ZAKS Research Compiler Optimizations; Parallel Architectures, including Thread-Level, Data-Level and InstructionInterests Level Parallelism; Compiler Middle-End and Back-End Analysis and Transformations targeting architectures to exploit such parallelism....»

«Chapter 5 Writing Hephzibah 2: The role of Menuhin family members The relationship between Hephzibah and Yehudi Menuhin It is impossible to research and write the life story of Hephzibah Menuhin without evaluating the important and at times overshadowing influence of her brother. Hephzibah always gave Yehudi great credit for her early lessons in performance. She said he taught her to show emotion in her playing, and that his criticisms about her approach to repertoire were very useful. Just how...»

<<  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.