FREE ELECTRONIC LIBRARY - Dissertations, online materials

Pages:     | 1 |   ...   | 12 | 13 || 15 | 16 |   ...   | 32 |

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

-- [ Page 14 ] --

“(... ) when programming errors or compiler warnings occurred, it was difficult to get practitioners from the involved development site to react on this warning. When this succeeded, practitioners from that development site did nearly everything to just remove the warning message, hardly paying attention to the actual semantics of the implemented solution. Practitioners from the main development site actually dug into the warning message, tried to understand the root cause of this message, and removed the root cause.” Although the latter approach took much time, Organization A was much more confident that this approach, once used throughout the organization, would be more beneficial.

4. Difficulty to build a team – Organization A has a nearly exact mapping of the organizational structure to the architecture. For all subsystems defined in the architecture, a subsystem team exists. In addition, architectural rules are the responsibility of the architecture team. Some of the architectural rules of Organization A define allowed dependencies between subsystems; these dependencies closely resemble the communication processes in place. In conclusion, the architecture determines the team structure so that the definition of teams is fixed. This leads to increased formality in the communication between these teams.

5. No collective ownership – The configuration management infrastructure in place at Organization A supports distributed change management. Each subsystem team is owner of the source code of that subsystem. Consequently, the ownership of the source code is distributed. Communication across subsystem teams on source code topics is structured via change requests and problem reports, and formalized in architectural rules. The organization experiences this as highly formal and inadequate; the major issues are discussed using other channels than change requests. As a result, change requests undergo delays and do not always represent reality.

6. Difficulty to align tasks and duties – Alignment of tasks and responsibilities is mainly done via the architecture. Requirements are assigned to subsystems, which have dedicated resources. Therefore, it is clear what activities will be performed by what

674. Reassessing the Need for Practices for Architectural Compliance

subsystem teams, even by what practitioners within those teams. Because these tasks and responsibilities are defined up-front, it is necessary to conduct formal verifications to determine whether reality is in line with the rules. Nevertheless, the tasks performed by the subsystem teams are not reviewed regularly by the architecture team nor the quality assurance team.

7. No uniform process – When we observed the architectural rules at Organization A (see Chapter 3), we noticed that Organization A has a strong emphasis on architectural rules from a configuration management perspective: naming conventions, coding guidelines, and process guidelines on releasing, integrating, and deploying source code are regarded as important by the organization. These guidelines pertain to the use of a single configuration management system. In addition, we observed much emphasis on software engineering processes and communication infrastructure. What lacks are detailed guidelines on inter-team communication and collaboration and a sound mechanism to disseminate the most important architectural decisions. Especially when unplanned, social contact is hard, it is essential to establish and announce communication guidelines between teams to disseminate the essential (architectural) information, such as the major architectural decisions. This prevents subsystem teams from feeling put aside and trailing on reality, as was the case at Organization A.

Although Organization A has guidelines pertaining to the software engineering processes as described above, the organization often deviated from these guidelines. This results in e.g., ambiguity on the integration process; the guidelines describe that all subsystems were delivered to a dedicated integration team, responsible for the full integration to the final software product. Practice shows a more staged approach towards integration. Furthermore, the visibility of the architecture team is decreasing because of a lack of resources and the perception that the architecture team is trailing on projects.

Verification of compliance with the architectural rules is not implemented at Organization A. As a result of this, multiple processes co-exist in practice.

4.4.2 Organization B Organization B develops business administration systems for various customers. Software development occurs by one development team spread across two sites at different continents. Organization B does not have dedicated architects – rather, architecting is a joint effort by the complete development team. Since 2006, Organization B uses these two development sites. In total, about 100 employees work in projects at these two development sites.

Although Organization B acknowledges that the differences between its customers may result in different architectural solutions, experiences have led to a certain convergence on the architecture that can be used most often. The software architecture consists of four layers which are highly decoupled by using principles like inversion of control, see e.g., (Walls and Breidenbach, 2005), and is supported by an extensive toolset aiding the development approach of Organization B.

The development approach of Organization B uses several practices from the agile development domain (Ambler and Jeffries, 2002). Examples of these practices include

68 4.4. Organizations’ Solutions to GSD Issues

pair programming and test-driven development. Test-driven development serves as a good basis for performing integration activities (Beck, 2002). Integration is done continuously by running all tests automatically and providing a response to the team.

1. Difficulty to initiate contact – In setting up the activities at the remote development site, specific attention was paid to selecting and hiring employees with corresponding work ethics and attitude. Furthermore, the management and several key individuals of the main development site often travel to the remote site. This traveling results in getting to know the people at the other site and establishing a shared approach using exactly the same methodology and tooling for software engineering. Since starting with the remote development site, still every employee hired at the remote development site visits the main development site within two months. Finally, employees from the remote development site regularly visit the practitioners at the main development site to exchange ideas and have face-to-face discussions on project-specific matters.

2. Difficulty to exchange information – The work of Organization B is supported by a configuration management system and an integrated issue-tracking system. Furthermore, Organization B uses a wiki as a collaboration tool to capture discussions, provide documents, and relate information on configuration management and issue-tracking.

The use of the wiki started as a shared initiative and now is an established practice.

All important documents are stored on the wiki and all issues are reported uniformly.

All software engineers are involved in daily stand-up meetings with video-conferencing facilities.

3. Difference in sense of urgency – Organization B is not really bothered by this issue. Frequent traveling across development sites (including informal activities) helps to established a shared sense of urgency. In addition, all employees spend time at the main development site to get to know the customer’s context. This enables the sites to relate communication efforts back to requirements of that customer.

4. Difficulty to build a team – First of all, the sites of Organization B regard each other fully as ‘peers’. This contributes to a shared team understanding. Furthermore, having highly communicative meetings across the development sites throughout the course of the project ensures that a single, uniform team exists across development sites.

5. No collective ownership – Organization B uses a single configuration management system in which all software engineers are allowed to view and modify all parts of the source code. Programming occurs in pairs that are often changed. In addition, no distinction between software engineering tasks is made between the development sites.

Consequently, the organization has a high degree of collective ownership. In case a practitioner makes a change to a part of the source code that is relatively unknown, the practitioner contacts other software engineers on the change that is to be made. The correct effect of the change is verified by the different kinds of tests that run automatically.

6. Difficulty to align tasks and duties – Since no distinction between software engineering tasks is made at Organization B, all practitioners within a project team use a single task list for dividing the work. Given the nature of the projects and the high pressure put on them, Organization B uses a very light-weight approach for capturing architectural knowledge (including architectural design decisions) and making this

694. Reassessing the Need for Practices for Architectural Compliance

knowledge explicit. This knowledge is used to introduce new practitioners into the architecture and the architectural rules that apply.

7. No uniform process – Organization B uses SCRUM (Schwaber and Beedle, 2001) as a software development process. As mentioned at the issue of difficulty to exchange information, frequent communication between practitioners from the development sites results in common understanding of the development process. Furthermore, an organization-wide shared vision on software development gives support for following that process. Since a while, releases are made from both the main development site and the remote development site, pointing out the similarity in the processes. This is

further exemplified by a quote of a software engineer of Organization B:

“It does not matter whether I work at the remote development site or at the main development site.”

4.5 Conclusions This chapter reports on the use of architectural rules to overcome global software development issues. We have structured the challenges and solutions as identified in the literature. As a result, we have defined four challenges in GSD: time difference and geographical distance, culture, team communication and collaboration, and work distribution. We have also shown that these challenges cannot be fully regarded in isolation;

they influence each other.

We observe that the solutions that are proposed by the literature pertain to both the product (i.e., the structure of the software) and the process. Furthermore, we have exemplified how the solutions can be implemented by using architectural rules or process measures.

We used the list of GSD issues when interviewing two organizations to identify what solutions the organizations use to overcome these issues. We learned that some of these solutions can be described by using principles and statements (i.e., architectural rules) on the software architecture that must be complied with throughout the organization.

Table 4.1 summarizes the results of our analysis.

Organization A has a clear focus on software architecture throughout the organization. Mechanisms such as having an architecture team and architectural rules on different topics exist to remain in control of the architecture. The organization adheres to a waterfall approach in defining and disseminating architecture throughout the organization. With this type of approach, it is easier to check and assure that the architectural rules are complied with. In addition, it is possible to e.g., measure to what extent architectural rules help in GSD. Nevertheless, this type of approach also requires to verify backward compliance. However, this verification does not take place at Organization A. Organization B has a more agile approach towards architecture. Although the organization has several architectural rules in place, the organization uses a number of practices and measures in the development process as solutions to overcome the GSD issues.

70 Table 4.1: Overview of organizations’ solutions to GSD issues. Solutions in the form of architectural rules are marked with [R]. Process measures are marked [C]

–  –  –


4. Reassessing the Need for Practices for Architectural Compliance Architectural rules prove valuable in handling some of the the issues in GSD. Organization A mainly uses architectural rules that pertain to the product as well as some additional process measures. Sometimes, architectural rules pertaining to the product are meant to induce the necessary processes (issues 4 and 6 in Table 4.1). However, we also observe that architectural rules pertaining to the product may induce difficulties for addressing GSD issues for Organization A, such as maintaining a uniform process. Organization B does not so much focus on architectural rules but rather reverts to measures in the development process to tackle the issues related to GSD and ensure compliance with architectural rules. Organization A, on the other hand, leaves the teams a certain degree of freedom in these processes and does not verify compliance with these processes nor the architectural rules.

Our study shows that architectural rules are not a solution for all GSD issues identied: especially cultural challenges and team collaboration challenges are not addressed by using architectural rules in the organizations.

Pages:     | 1 |   ...   | 12 | 13 || 15 | 16 |   ...   | 32 |

Similar works:

«KOI VARIETIES (Taken from www.koiandponds.com) KOHAKU General Description 'Kohaku' is the term applied to a koi that has a white body with red markings. Kohaku is the first koi breed to be established by the Japanese, with breed stability being achieved in the 1890's. Appreciation Criteria Color The shiro (white) base color of the body must be unblemished, thick, snowy, and even milky. The shiro must not exhibit any yellowish tint. The hi (red) markings on the white body must be solid, deep,...»

«Headache and Facial Pain January 2001 TITLE: Headache and Facial Pain SOURCE: Grand Rounds Presentation, UTMB, Dept. of Otolaryngology DATE: January 31, 2001 RESIDENT PHYSICIAN: Robert H. Stroud, M.D. FACULTY ADVISOR: Byron J. Bailey, M.D. SERIES EDITOR: Francis B. Quinn, Jr., M.D. ARCHIVIST: Melinda Stoner Quinn, MSICS This material was prepared by resident physicians in partial fulfillment of educational requirements established for the Postgraduate Training Program of the UTMB Department of...»

«    Russell, James Edward (2011) Cultural Property and Heritage in Japan. PhD Thesis, SOAS, University  of London  http://eprints.soas.ac.uk/14043      Copyright © and Moral Rights for this thesis are retained by the author and/or other  copyright owners. A copy can be downloaded for personal non‐commercial research or  study, without prior permission or charge. This thesis cannot be reproduced or quoted ...»

«Assessment of Geriatric-Specific Changes in Brain Texture Complexity Using a Backpropagation Neural Network Classifier R. Kalpana* S. Muttan† Department of Electronics and Communication Engineering Anna University Chennai 600025, India * kalpanatirth@gmail.com † muthan_s@annauniv.edu A method to assess the aging of a human subject by modeling the devolution of the textural features in brain images using a backpropagation neural network (BPNN) is described in this paper. Normally, the brain...»

«ButeykoClinic.com Snoring.ie Chronic hyperventilationasthma, snoring & sleep apnoea Patrick McKeown, author of “Sleep with Buteyko” What is snoring? Snoring is a sound created from turbulent airflow. It is noisy breathing during sleep caused by the exchange of a large volume of air through a narrowed space, which in turn causes the tissues of the nose and throat to vibrate. Snoring comes in two flavors  Simple snoring vibration of the soft palate. (mouth snoring)  High upper airway...»

«1 Getting Started with Exodus By Lauren Stouffer and Ted Hildebrandt Copyright © 2012 Introduction to Exodus Exodus, the second book in the Torah, begins where Genesis ended—with the children of Israel living in Egypt. The original Hebrew title of the book “and these are the names,” is taken from the first two words of the book in the Hebrew. The title “Exodus” (“the way out”) is taken from the Greek Septuagint, or LXX1 explicating the content of the book as being about the way...»

«The Journal of Specialised Translation Issue 1 January 2004 Jorge Díaz Cintas University of Surrey Roehampton, London Subtitling: the long journey to academic acknowledgement ABSTRACT The present article is part of a wider translation project from Spanish carried out by Juan Abad, Judith Harling, Yuka Miyakita, Mark Seager and Christina Wiggins, students at the University of Surrey Roehampton. Audiovisual translation seems to have been absent from academic exchanges on translation until very...»

«Teresa Alicia Giamportone, Gobierno y vitivinicultura en la provincia de Mendoza (Argentina) a través del Álbum Argentino Gloriandus / Government and the wine industry in Mendoza (Argentina) through the Album Argentino Gloriandus, Revista RIVAR Vol. 1, N° 2 ISSN 0719-4994, IDEA-USACH, Santiago de Chile, mayo 2014: pp. 102-124 Gobierno y vitivinicultura en la provincia de Mendoza (Argentina) a través del Álbum Argentino Gloriandus* Government and the wine industry in Mendoza (Argentina)...»

«Champions: An Anthology of Winning Fantasy Stories Edited by Alex S. Bradshaw All stories are copyright of their respective owners and are used here with their permission No part of this work may be reproduced or transmitted in any form or by any means without written permission from the copyright holder. Table Of Contents Foreword December 2011: Exigent by Ken Lim January 2012: The Seed of Apostasy by Ian Everett February 2012: Allisande Always Comes Back by JP April 2012: A Grievance by Ian...»

«Perceptions of Draft and Existing Chlamydia Educational Materials: Final Report from Focus Groups with Females Ages 15–25 January 2010 1 Table of Contents I. Executive Summary A. Methodology B. Major Findings C. Implications for Communications II. Introduction A. Guidance from Earlier Research Activities B. Theoretical Foundation III. Methodology A. Participants B. Consent C. Products and Procedures D. Analysis IV. Limitations V. Summary of Findings A. Chlamydia Knowledge & Sources of...»

«El Dr. Solano de Luque en el tercer centenario de su nacimiento. Significación de la obra solaniana *** Por Angel FERNANDEZ DUEÑAS El 12 de noviembre de 1984 se cumplía el tercer aniversario del nacimiento del doctor don FrancisCo Solano de Luque, uno de los muchos hijos ilustres que Montilla ha dado a España y, sin embargo, fígura poco conocida o, al menos, no tan conocida como corresponde a su justa fama y a la proyección europea que alcanzó en pleno Siglo de las Luces. No es ésta la...»

«UNIONE ACCADEMICA NAZIONALE Corpus dei Manoscritti Copti Letterari LETTERATURA COPTA Serie Studi TITO ORLANDI COPTIC TEXTS RELATING TO THE VIRGIN MARY An Overview Roma CIM 2008 The layout has been prepared by the author, using troff/groff for layout and postscript fonts. God bless Unix/Linux and Gnu. © CIM Roma ISBN 88-85354-08-4 CONTENTS I. Generalia 5 a) Introduction, 5 — b) Terminology, 7 — c) Classification of works and fragments, 12 II. Bibliological and Codicological Units 13 1. The...»

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