No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Software modularization in global software development
Abstract
In a Global Software Development (GSD) environment, multiple teams are located in geographically dispersed locations and project management is becoming a difficult task; and the work distribution process has become an important function in GSD. Work distribution process can influence both the benefits of global software development (e.g. cost reduction, availability of people, proximity to the customer) and its risks (e.g. communication and coordination overhead). Therefore, work should be distributed after a thorough study on the different tasks and the various locations. To do this, the categorization of work should be undertaken before it is distributed. This is known as modularization which can help overcome communication and coordination problems in the development process and makes the process more stable. In this paper, we present a survey on software modularization which includes principles of modularization and applicability of the concept to GSD.
... Since frequently cited literature on virtual development, e.g. [4,13,16], only marginally addresses product quality, we have initiated a research project with the ultimate goal to design a framework for lowering the number of residual defects in products developed by virtual teams. A virtual team is a team distributed across space, time, and organization boundaries, and linked by webs of interactive technology [17]. ...
... Both Karolak and Carmel describe why virtual development of products is much more complex than even the most 0950 [4,16]. The works of Karolak and Carmel are focused on the managerial and collaboration aspects of the organization and execution of virtual development projects. ...
... Problem and risk areas of virtual development are extensively studied by Carmel [4] and Karolak [16]. Carmel performed a case study, the Globally Dispersed Software Development (GDSD) study, to find aspects in which global development differs from traditional, entirely in-house development [4]. ...
This paper explores the effects of virtual development on product quality, from the viewpoint of ‘conformance to specifications’. Virtual Development refers to the development of products by teams distributed across space, time, and organization boundaries (hence virtual teams). Specifically, causes of defect injection and non- or late-detection are explored. Because of the practical difficulties of obtaining hard project-specific defect data, an approach was taken that relied upon accumulated expert knowledge. The accumulated expert knowledge based approach was found to be a practical alternative to an in-depth defect causal analysis on a per-project basis. Defect injection causes are concentrated in the Requirements Specification phases. Thus defect dispersion is likely to increase, as requirements specifications are input for derived requirements specifications in multiple, related sub-projects. Similarly, a concentration of causes for the non- or late-detection of defects was found in the Integration Test phases. Virtual development increases the likelihood of defects in the end product because of the increased likelihood of defect dispersion, because of new virtual development related defect causes, and because causes already existing in co-located development are more likely to occur. The findings are important for virtual development environments and (1) allow further research focusing on a framework for lowering residual defects, and (2) give insights that can be used immediately by practitioners to devise strategies for lowering residual defects.
... This is due to the fact that GSD offers several benefits to the software development organizations including access to the new markets and technologies, skilled software developers, better relationships with the development organizations (and individuals), low software development cost, and access to the large and diverse human resources [1]- [3]. Moreover, GSD provides a significant reduction in the development time; thereby, attracting the software development organizations to outsource a software product [4]. Similarly, some other key benefits of GSD are presented in Figure 1 [5]. ...
Global Software Development (GSD) is widely used by software development organizations to ensure the development of a cost-effective software product. GSD has now become a common engineering practice adopted by a significant number of multinational software development organizations, and even individuals (freelancers) are seeking numerous benefits including low development cost, highly skilled workers, and access to better development ideas. However, communication and coordination challenges remain a prominent research issue in the GSD context, while performing different project-related activities especially for Requirements Change Management (RCM). As a result, improper communication and coordination during RCM require additional time, cost, and development resources. Thus, it is of vital importance to ensure proper communication and coordination before initiating a software project. Inspired by this, current work aims at exploring and mitigating the communication and coordination challenges during RCM in the GSD context. To accomplish the targeted research objective, we performed a tertiary study to provide a landscape of the challenges that occurred during RCM in the context of GSD. Based on the performed study, we found 62 communication and 14 coordination challenges. In total, 107 mitigation strategies are explored and reported that effectively address the categorized sub-challenges of communication and coordination. Moreover, we proposed a conceptual model useful to address the communication and coordination challenges for the RCM process in GSD. Furthermore, we consulted the domain experts for the validation of the proposed conceptual model. Based on the promising results, we believe that this work supports the project managers in managing the cost and time-related issues in the GSD context. Consequently, the proposed conceptual model would help in optimally utilizing the scared software development resources.
... They further indicated that the broad vision and goal must be well defined for every practitioner of ARCM. As per Wickramaarachchi and Lai [49], the scope and the reason of the change is significant to know the demanded changes for success after required changes. So, learning environment must be established in order to accomplish the activities of the ARCM in GSD domain. ...
The economic and strategic gains motivated the majority of software firms to adopt global software development (GSD). The adoption of GSD is not straightforward. The geographical distance between the GSD teams causes the various problems for the implementation of agile software development activities, particularly, that related to requirements change management in agile (ARCM). The objective of this study is to explore the success factors of ARCM in GSD context and prioritized them based on their significance. The study comprised of two steps: (1) identify the success factors of ARCM using systematic mapping study (SMS) and validate them with industry practitioners using questionnaire survey approach; (2) prioritize the identified success factors by applying the analytical hierarchy process (AHP) approach. A total of 21 success factors that are significant for ARCM process were identified using SMS and questionnaire survey study. The results of AHP shows that allocation of resources at overseas sites, 3C’s (communication, coordination and control), geographically distributed change control board (CCB), RCM process improvement expertise and continuous top management support are the highest priority success factors of ARCM process in the context of GSD. The findings assist the practitioners to address the most priority success factors in order to successfully implement the ARCM activities in the domain of GSD.
... They underlined that the goal and vision of change should be clear for all ARCM process practitioners [35]. Wickramaarachchi and Lai [36] reported that knowing the scope and purpose of change management is important for the successful implementation of the requested changes. To perform ARCM activities in a GSD environment, an F5 (Training and monitoring) environment should be developed. ...
Requirements change management (RCM) is an important and complicated phase in the agile for the software
development process. The objective of this study was to identify and analyse the factors that can positively affect the agile RCM
(ARCM) process in the context of global software development (GSD). To this end, a questionnaire survey was carried out with
researcher and practitioner participants working in the field of GSD. From the 56 survey respondents, a total of 20 factors that
can positively influence the ARCM activities in GSD were identified. The authors also performed a client–vendor-based analysis
to investigate the significance of the considered factors for different organisation types. Additionally, they compared the data
collected from researchers and practitioners. The comparison results (r
s
(20) = 0.076) revealed that there exists a positive
correlation between the rankings in each data set. The investigated factors were mapped to ten project management book of
knowledge areas, and the mapping results revealed that human resource management is the most significant knowledge area
amongst the investigated factors. The findings of this study provide a robust framework to assist GSD firms in implementing
ARCM activities.
... They underlined that the goal and vision of change should be clear for all ARCM process practitioners [35]. Wickramaarachchi and Lai [36] reported that knowing the scope and purpose of change management is important for the successful implementation of the requested changes. To perform ARCM activities in a GSD environment, an F5 (Training and monitoring) environment should be developed. ...
Requirements change management (RCM) is an important and complicated phase in the agile for the software development process. The objective of this study was to identify and analyse the factors that can positively affect the agile RCM (ARCM) process in the context of global software development (GSD). To this end, a questionnaire survey was carried out with researcher and practitioner participants working in the field of GSD. From the 56 survey respondents, a total of 20 factors that can positively influence the ARCM activities in GSD were identified. The authors also performed a client–vendor‐based analysis to investigate the significance of the considered factors for different organisation types. Additionally, they compared the data collected from researchers and practitioners. The comparison results (rs (20) = 0.076) revealed that there exists a positive correlation between the rankings in each data set. The investigated factors were mapped to ten project management book of knowledge areas, and the mapping results revealed that human resource management is the most significant knowledge area amongst the investigated factors. The findings of this study provide a robust framework to assist GSD firms in implementing ARCM activities.
Global Software Development (GSD) is expanding quickly all around the world because of the various advantages offered to the customers, vendors, and other stakeholders involved in software project development. However, GSD is not a simple process as it faces multiple challenges that arise due to the mismanagement of the communication and coordination process. Meanwhile, Requirements Change Management (RCM) is a tedious and high resource-consuming process in GSD, which is further negatively affected by the poorly managed communication and coordination mechanisms. Multiple research studies have presented various theoretical and conceptual models to overcome the challenges during RCM in the GSD context. However, the existing methodologies lack in handling the communication and coordination challenges during the RCM process in the GSD context. In the literature, the researchers have concluded that a conceptual model can effectively reduce the communication and coordination challenges during RCM in GSD. Inspired by this, the current work aims at proposing a conceptual model to overcome and mitigate the communication and coordination challenges, while ensuring the effective requirement changes at offshore software development sites. Moreover, it would help the multiple stakeholders in understanding and managing the necessary resources before initiating the RCM process. To validate the proposed conceptual model, we have conducted a questionnaire-based survey to procure the results from the industrial experts working in the GSD domain. After analyzing the obtained results, we found that the proposed conceptual model is effective to handle the communication and coordination challenges up to 87%. In addition, almost 87% of the experts have agreed upon the correctness, identified challenges, and the mitigation practices in the proposed conceptual model necessary to improve the RCM process in the GSD context. Furthermore, it was observed that 75% of the experts also agreed upon the practical implementation of the proposed conceptual model in the software development industry to observe the heuristic performance of the proposed conceptual model.
To perform requirements management, effective communication and collaboration between stakeholders is necessary. Global Software Development (GSD), where software teams are located in different parts of the world, has become increasingly popular. However, geographical distance between stakeholders creates difficulties for stakeholders in engaging in effective communication. Taking into consideration the factors involved in GSD, previous research shows that the ways by which requirements management is being performed in collocated software development projects cannot be used effectively for GSD projects. To address this issue, in this paper we present a requirements management method for GSD. The method consists of four stages: (1) establishing and maintaining a requirements repository; (2) generating a requirements traceability matrix; (3) communicating and discussing requirements; and (4) requirements change management. To validate our method, we implemented it in a controlled laboratory environment using a case study of an online shopping system.
The following position paper outlines a software development course project for a semester long class on distributed software development. The developed application was an Android based facial recognition application which returned the name and contact information of people in a picture. Students from Iowa State University in the US, Jilin University in China, and the Federal Universidade da Bahia in Brazil participated. Challenges and solutions that were part of the development process as well as recommendations for future classes are provided.
This paper presents a formal, general model of program dependencies. Two generalizations of control and data dependence, called weak and strong syntactic dependence, are presented. Some of the practical implications of program dependencies are determined by relating weak and strong syntactic dependence to a relation called semantic dependence. Informally, one program statement is semantically dependent on another if the latter statement can affect the execution behavior of the former. It is shown that weak syntactic dependence is a necessary condition for semantic dependence, but that neither weak nor strong syntactic dependence are sufficient conditions. The implications of these results for software testing, debugging, and maintenance are then explored.
A common method of managing the complexity of both technical and organizational relationships in a large software project is to use branches within the source code management system to partition the work into teams and tasks. We claim that the files modified on a branch are changed together in a cohesive way to accomplish some task such as adding a feature, fixing a related set of bugs, or implementing a subsystem, which we collectively refer to as the goal of the branch. Further, the developers that work on a branch represent a virtual team. In this paper, we develop a theory of the relationship between goals and virtual teams on different branches. Due to expertise, ownership, and awareness concerns, we expect that if two branches have similar goals, they will also have similar virtual teams or be at risk for communication and coordination breakdowns with the accompanying negative effects. In contrast, we do not expect the converse to always be true. In the first step towards an actionable result, we have evaluated this theory empirically on two releases of the Windows operating system and found support in both.
Global software development is not a phenomenon but a reality nowadays. However, it is still poorly explored. Lack of awareness of the particular factors inherited in the nature of globally distributed software projects makes practitioners struggle and invent new approaches to survive. It uncovers the necessity to support risk management activities. This paper describes a Knowledge Base and a Risk Barometer developed to support practitioners who lack experience in global projects. Particularities of globally distributed projects and their effect on project performance are formalized in a reusable framework for managing uncertainty. The described tools provide input for risk identification and help to evaluate risks based on the experience from former projects.
Agile software development has steadily gained momentum and acceptability as a viable approach to software development. As software development continues to take advantage of the global market, agile methods are also being attempted in geographically distributed settings. In this paper, the authors discuss the usefulness of published research on agile global software development for the practitioner. It is contended that such published work is of minimal value to the practitioner and does not add anything to the guidance available before the existence of current agile methods. A survey of agile GSD related publications, from XP/Agile conferences between 2001 and 2005, is used to support this claim. The paper ends with a number of proposals which aim to improve the usefulness of future agile GSD research and experience.
This paper presents an overview of the field of distributed development of software systems and applications (DD). Based on
an analysis of the published literature, including its use in different industrial contexts, we provide a preliminary analysis
that structures existing DD knowledge, indicating opportunities but identifying threats to communication, coordination, and
control caused by temporal distance, geographical distance, and socio-cultural distance. An analysis of the case and field
study literature has been used to identify strategies considered effective for countering the identified threats. The paper
synthesizes from these a set of 10 general strategies for successful DD which, if adopted, should lead to increased company
resilience.
In the last decade, the concept of modularity has caught the attention of engineers, management researchers and corporate
strategists in a number of industries. When a product or process is “modularized,” the elements of its design are split up
and assigned to modules according to a formal architecture or plan. From an engineering perspective, a modularization generally
has three purposes:
The concept of awareness plays a pivotal role in research in Computer-Supported Cooperative Work. Recently, software engineering researchers interested in the collaborative nature of software development have explored the implications of this concept in the design of software development tools. A critical aspect of awareness is the associated coordinative work practices of displaying and monitoring actions. This aspect concerns how colleagues monitor one another's actions to understand how these actions impact their own work and how they display their actions in such a way that others can easily monitor them while doing their own work. In this paper, we focus on an additional aspect of awareness: the identification of the social actors who should be monitored and the actors to whom their actions should be displayed. We address this aspect by presenting software developers' work practices based on ethnographic data from three different software development teams. In addition, we illustrate how these work practices are influenced by different factors, including the organizational setting, the age of the project, and the software architecture. We discuss how our results are relevant for both CSCW and software engineering researchers.
The principle of information hiding has been very influential in software engineering since its inception in 1972. This principle prescribes that software modules hide implementation details from other modules in order to decrease their interdependencies. This separation also decreases the dependency among software developers implementing modules, thus simplifying some aspects of collaboration. A common instantiation of this principle is in the form of application programming interfaces (APIs). We performed a qualitative study on how practitioners use APIs in their daily work. Although particularly interested in aspects of collaboration, we report all findings about their observed use. The findings include mundane observations that are predicted by theory, ways that APIs support collaborative software development. But the findings also include some surprises, ways that APIs hinder collaboration. The surprises indicate directions for further improvement of collaborative software development practices and tools.
Software systems are modularized to make their inherent complexity manageable. While there exists a set of well-known principles that may guide software engineers to design the modules of a software system, we do not know which principles are followed in practice. In a study based on 16 open source projects, we look at different kinds of coupling concepts between source code entities, including structural dependencies, fan-out similarity, evolutionary coupling, code ownership, code clones, and semantic similarity. The congruence between these coupling concepts and the modularization of the system hints at the modularity principles used in practice. Furthermore, the results provide insights on how to support developers to modularize software systems.
Handling context is required for applications to dynam- ically and appropriately adapt to their changing environ- ment. Incorporating context into applications involves the consideration of a set of concerns related to the handling of various context types and the adaptation of the application behaviour relative to the current context. These concerns are usually heavily tangled with the base code of the ap- plications, resulting in code that is badly modularised and therefore is hard to understand, manage and modify. We propose a modularised design for the handling of dif- ferent kinds of context using aspect-oriented programming techniques. We demonstrate that a context-aware applica- tion built in this manner exhibits improved modularity, with corresponding improvements in comprehensibility, manage- ability and maintainability. The proposed aspect-oriented modularisation is eval- uated against traditional object-oriented techniques, and also against a popular context framework, using metrics indicating coupling, cohesion and complexity. The results show the positive effect of modular code on context-aware applications by quantitatively illustrating the improvements in modularisation quality factors.1
In existing global software development (GSD) literature, much focus has been on identifying the challenges that practitioners may face (such as socio-cultural and temporal distance issues), while potential benefits have not been extensively analyzed. We reverse this trend by studying these potential benefits. We question whether they are well-founded assumptions and whether they are attainable in practice. This paper presents findings from a multi-case study at three multi-national companies that have extensive experience in GSD. We identify the benefits mentioned in GSD literature, analyze them with regards to the companies' experiences and then conclude whether or not each benefit is being realized in practice. Our findings reveal that the realization of the assumed benefits cannot be simply taken for granted
The allocation of tasks can be seen as a success-critical management activity in distributed development projects. However, such task allocation is still one of the major challenges in global software development due to an insufficient understanding of the criteria that influence task allocation decisions. This article presents a qualitative study aimed at identifying and understanding such criteria that are used in practice. Based on interviews with managers from selected software development organizations, criteria currently applied in industry are identified. One important result is, for instance, that the sourcing strategy and the type of software to be developed have a significant effect on the applied criteria. The article presents the goals, design, and results of the study as well as an overview of related and future work.
Modularity, hierarchy, and interaction locality are general approaches to reducing the complexity of any large system. A widely used principle in achieving these goals in designing software systems is striving for high cohesion within a module and low coupling between modules. However, this principle has difficulties in practice. Because a hierarchical system structure often consists of several layers, it is difficult to decide at what layer an interaction should be considered as cohesion, and at what layer an interaction should be considered as coupling. In this paper, we do not differentiate cohesion and coupling, but use a general term interaction to represent the dependencies between software modules. We propose a method to verify the design modularity, hierarchy, and interaction locality of a software system. This approach is based on the component interactions gathered from certain design level artifacts, such as UML diagrams. Data clustering technique is then used to group software components according to the degree of interactions between them. To show how to use this approach, we apply it to Parna's KWIC object-oriented design example, in which sequence diagram is used to derive the degree of component interactions.
Facilitated by new standards and middleware technologies, enterprise application software is increasingly characterized by a high degree of modularity. On an organizational level, this is reflected by the goal of dominant system vendors (hubs) to form loosely-coupled hub-and-spoke networks with smaller niche players (spokes) that complement their solutions. This paper aims at explaining differences regarding the extent to which spokes strive for loosely-coupled partnerships as opposed to closely-tied relationships with a particular hub. The type of coupling is indicated by the level of hub-specific investments and the application of informal governance mechanisms. Following existing theory, the synergistic specificity between the partners' technological, commercial, and social capital is suggested to determine the aspired type of coupling. Moreover, it is argued that a tighter coupling leads to an increased threat of opportunism. However, instead of loosening the partnership, spokes tie themselves even closer to the hub.
In this paper, we seek to shed light on how communication networks in geographically distributed projects evolve in order to address the limits of the modular design strategy. We collected data from a geographically distributed software development project covering 39 months of activity. Our analysis showed that over time a group of developers emerge as the liaisons between formal teams and geographical locations. In addition to handling the communication and coordination load across teams and locations, those engineers contributed the most to the development effort.
Geographically distributed development creates new questions about how to coordinate multi-site work. In this paper, we present four methods product development organizations used to coordinate their work: functional areas of expertise, product structure, process steps, and customization. We describe the benefits and difficulties with each model. Finally, we discuss two difficulties that occur irrespective of the model used: consequences of unequal distribution of project mass, and finding expertise.
The effective assessment of emerging modularization technologies plays a pivotal role on: (i) a better understanding of their real benefits and drawbacks when compared to conventional development techniques, and (ii) their effective transfer to mainstream software development. This report is intended to summarize the results of the 1st International Workshop on Assessment of Contemporary Modularization Techniques (ACoM'07) held in Minneapolis, USA, May 22, 2007, as part of the 29th International Conference on Software Engineering (ICSE'07). The main purpose of this workshop was to share and pool the collective experience of people interested in and actively working on assessment of innovative modularization techniques. The workshop consisted of an opening presentation, several paper presentations organized into three technical sessions, and four discussion groups. During the workshop presentations and discussions, the authors and participants directly and indirectly reviewed ongoing and previous work and debated a number of important issues on contemporary modularity assessment. The ACoM'07 website, including the electronic version of this report, can be found at . We begin by presenting an overview of our goals and the workshop structure, and then focus on the workshop technical program and results.
ABSTRACT Software architecture description languages provide a means to formally describe software systems at a high level of abstraction. They capture the high-level structure and/or behavior of the system, thus providing a basis for course-grain static analyses. Dependence analysis has been used as a basis for program optimization, debugging, and testing. We are developing a dependence analysis technique, called chaining, for use with formal architectural descriptions, and implementing the technique in a tool called Aladdin. KEYWORDS Dependence Analysis, Software Architecture, Architecture Description Languages
The concept of awareness has come to play a central role in CSCW research. The coordinative practices of displaying and monitoring have received attention and have led to different venues of research, from computational tool support, such as media spaces and event propagation mechanisms, to ethnographic studies of work. However, these studies have overlooked a different aspect of awareness practices: the identification of the social actors who should be monitored and the actors to whom their actions should be displayed. The focus of this paper is on how social actors answer the following questions: to whom should I display my actions? And, whose actions should I monitor? Ethnographic data from two software development teams are used to answer these questions. In addition, we illustrate how software developers' work practices are influenced by three different factors: the organizational setting, the age of the project, and the software architecture.
Prior research has shown that customer-reported software faults are often the result of violated dependencies that are not recognized by developers implementing software. Many types of dependencies and corresponding measures have been proposed to help address this problem. The objective of this research is to compare the relative performance of several of these dependency measures as they relate to customer-reported defects. Our analysis is based on data collected from two projects from two independent companies. Combined, our data set encompasses eight years of development activity involving 154 developers. The principal contribution of this study is the examination of the relative impact that syntactic, logical, and work dependencies have on the failure proneness of a software system. While all dependencies increase the fault proneness, the logical dependencies explained most of the variance in fault proneness, while workflow dependencies had more impact than syntactic dependencies. These results suggest that practices such as rearchitecting, guided by the network structure of logical dependencies, hold promise for reducing defects.
In this paper we present an intermediate program representation, called the program dependence graph (PDG), that makes explicit both the data and control dependences for each operation in a program. Data dependences have been used to represent only the relevant data flow relationships of a program. Control dependences are introduced to analogously represent only the essential control flow relationships of a program. Control dependences are derived from the usual control flow graph. Many traditional optimizations operate more efficiently on the PDG. Since dependences in the PDG connect computationally related parts of the program, a single walk of these dependences is sufficient to perform many optimizations. The PDG allows transformations such as vectorization, that previously required special treatment of control dependence, to be performed in a manner that is uniform for both control and data dependences. Program transformations that require interaction of the two dependence types can also be easily handled with our representation. As an example, an incremental approach to modifying data dependences resulting from branch deletion or loop unrolling is introduced. The PDG supports incremental optimization, permitting transformations to be triggered by one another and applied only to affected dependences.
As software systems provide more, and more distributed, real-time services to our society, it is possible to witness their growing complexity. One way to manage this complexity is to decompose software systems into smaller parts, called modules. The predictable consequence of dividing a system into modules is that these modules need to be put back together in some coordinated way, so that the software system can provide services. A dependency between software modules is said to exist when one module relies on another to perform its operations or when changes to the latter must be reflected on the former.
Dependencies between software modules affect their development, maintenance, and reuse. More important, they affect the coordination of software development efforts. Although this relationship has been long known by researchers and practitioners, it has been largely unexplored. Most researchers focus on the technical aspects of the dependencies---identification, analysis, and maintenance---instead of focusing on their implications for understanding the collaborative work of software production. Meanwhile, empirical studies of software dependencies focus on how organizations and teams adopt strategies to manage these dependencies.
To address this issue, I have conducted two field studies to understand how software developers manage the effect of these dependencies in the coordination of their work. Using ethnographic data, I detail how management of dependencies can be understood as impact management---the work performed by software developers to minimize the impact of one's effort on that of others, and at the same time, the impact of others' efforts on one's own. The main aspect underlying impact management is used to inform the design of Ariadne, a tool that aims to facilitate this same activity.
Ariadne is evaluated in two different settings, each examined to determine how software dependencies can be used to facilitate the understanding and enactment of collaborative software development activities. This dissertation concludes by using the observations from my field studies and results from my evaluations to suggest implications for empirical software engineering research, organizational work practices, and the design of collaborative technologies.
Software design and development in Free/Open Source projects are analyzed through the lens of the theory of modularity applied to complex systems. Both the architecture of the artifacts (software) and the organization of the projects benefited from the paradign of modularity, in an original and effective manner. Our study shows that three main routines, or shortcuts, emerged and were effectively applied. First, some successful projects inherited previously existing modular architecture, rather than designing new modular systems from scratch. Second, popular modular systems, like GNU/Linux kernel, evolved from an initial integrated structure through a process of evolutionary adaptation. Third, development of modular software took advantage from the violation of one fundamental rule of modularity, that is information hiding. Implications and extensions of Free/Open Source projects' experience are discussed in the conclusions.
Distributed Software Development (DSD) is an emerging research area in software engineering. Several conducted research studies identified similar communication problems among DSD teams and tried to solve them. In this paper we present patterns that we have identified while surveying state of the art research studies. The patterns can help to organize DSD teams better in order to enhance their communication. We also highlight some potential future research challenges.
Global Software Development (GSD) has recently evolved and has been embraced by the competitive software industry today. The major attraction of GSD is due to the greater availability of human resources in distributed zones at a low cost and advances in communication technology. However, recent research reveals that expected benefits of GSD are not always realized as predicted since additional costs are often involved for the communication and coordination activities between the dispersed groups. Therefore, the main challenge of GSD today is to minimize the additional costs and maximize the benefits. A proper work distribution mechanism is particularly important to reduce the additional challenges facing GSD. In this paper, we present a method for work distribution to multiple locations. It starts with the identification of work as stages/phases in the Software Development Life Cycle (SDLC) and grouping them according to the Software Process Model (SPM) used. A final suggestion for the work distribution is based on multiple criteria such as work dependency, site dependency, site specific and work specific characteristics. The priority given to the criteria depends on the project objective.
The HIPO Hierarchy chart is being used as an aid during general systems design. The considerations and techniques presented here are useful for evaluating alternatives for thos portions of the system that will be programmed on a computer. The charting technique used here depicts more details about the interfaces than the HIPO Hierarchy chart. This facilitates consideration during general program design of each individual connection and its associated passed parameters. The resulting design can be documented with the HIPO charts. (if the designer decides to have more than one function in any module, the structure chart should show them in the same block. However, the HIPO Hierarchy chart would still show all the functions in separate blocks.) The output of the general program design is the input for the detailed module design. The HIPO input-process-output chart is useful for describing and designing each module.
Increasingly, software products development companies are attempting to make transition from traditional centralized local development to global development. This transition is taking place due to intense competition, availability of high quality and low cost software professionals in various countries, and advent of communication and information technologies to link the disperse groups. Due to a significant lack of research on the global software product (GSP) development organization, companies are commonly attempting to develop standardized software products by using an adhoc global project organization. In making transition from local development of software product to global development, developers are facing great difficulties in setting up an appropriate GSP development organization and executing GSP development. Most of the companies are not obtaining the expected benefits for their GSP development efforts and some of them are failing completely. The research was carried out by reviewing literature and conducting a multiple case study. This study introduces GSP development organization and identifies the key barriers that are encountered by the GSP development organization. The research will guide companies, who are involved in the development of GSP, to implement appropriate organizations, to avoid the challenges and to achieve the GSP development goals. This research also suggests some future research directions.
From the Publisher:The first edition of Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design quickly emerged as the leading OOA/D introduction; it has been translated into seven languages and adopted in universities and businesses worldwide. In this second edition, well-known object technology and iterative methods leader Craig Larman refines and expands this text for developers and students new to OOA/D, the UML, patterns, use cases, iterative development, and related topics. Put simply, the book shows newcomers to OOA/D how to "think in objects." It does so by presenting three iterations of a single, cohesive case study, incrementally introducing the requirements and OOA/D activities, principles, and patterns that are most critical to success. It introduces the most frequently used UML diagramming notation, while emphasizing that OOA/D is much more than knowing UML notation. All case study iterations and skills are presented in the context of an "agile" version of the Unified Process a popular, modern iterative approach to software development. Throughout, Larman presents the topics in a fashion designed for learning and comprehension. Among the topics introduced in Applying UML and Patterns are: * requirements and use cases, * domain object modeling, * core UML, * designing objects with responsibilities, * "Gang of Four" and other design patterns, * mapping designs to code (using Java as an example), * layered architectures, * architectural analysis, * package design, * iterative development, and * the Unified Process. For a more detailed list of topics, please see the accompanying table of contents. Forewordby Philippe Kruchten, the lead architect of the Rational Unified Process. "Too few people have a knack for explaining things. Fewer still have a handle on software analysis and design. Craig Larman has both."John Vlissides, author, Design Patterns and Pattern Hatching "This edition contains Larman's usual accurate and thoughtful writing. It is a very good book made even better."Alistair Cockburn, author, Writing Effective Use Cases and Surviving OO Projects
In this position paper we argue that component dependencies should be treated as a first class problem in component-based systems evolution. We discuss some issues related to dependencies and present an overview of a technique to describe and analyze dependencies in component-based systems.
The idea of congruence between the structure of techni-cal and work dependencies has been demonstrated in com-mercial software development but has not been explored in detail in free and open source software (FLOSS) develop-ment. Previous work identified 103 task episodes, selected from two FLOSS projects, and found that 83 were per-formed by single actors. We analyze the 20 tasks with mul-tiple actors and find that 14 were performed in the absense of any discursive communication between developers. The qualitative analysis of this evidence shows the paradox that, even if the developers do not seem to communicate explic-itly, the software is nonetheless built as result of a collective effort, apparently without central coordination. In answer to this puzzle, this paper turns to the concept of stygmergic coordination as possible explanation. Stigmergy explains how actors can affect the behavior of other members of the community through the traces that their activities leave in shared artifacts. Such collaboration has implications for the socio-technical congruence analysis and the design of collaborative systems.
In this paper we present a tool to facilitate the work of managers of global software development projects. This tool explores the relationship between software dependencies and coordination of work and uses social networks to suggest potential coordination problems for managers. The overall architecture of the tool is described as well as the theoretical and empirical motivations for the tool
Socio-technical congruence is an approach that measures coordination by examining the alignment between the technical dependencies and the social coordination in the project. We conduct a case study of coordination in the IBM Rational Team Concert project, which consists of 151 developers over seven geographically distributed sites, and expect that high congruence leads to a high probability of successful builds. We examine this relationship by applying two congruence measurements: an unweighted congruence measure from previous literature, and a weighted measure that overcomes limitations of the existing measure. We discover that there is a relationship between socio-technical congruence and build success probability, but only for certain build types, and observe that in some situations, higher congruence actually leads to lower build success rates. We also observe that a large proportion of zero-congruence builds are successful, and that socio-technical gaps in successful builds are larger than gaps in failed builds. Analysis of the social and technical aspects in IBM Rational Team Concert allows us to discuss the effects of congruence on build success. Our findings provide implications with respect to the limits of applicability of socio-technical congruence and suggest further improvements of socio-technical congruence to study coordination.
This paper focuses on two characteristics of collaborative design with respect to cooperative work: the importance of work
interdependencies linked to the nature of design problems; and the fundamental function of design cooperative work arrangement,
which is the confrontation and combination of perspectives. These two intrinsic characteristics of the design work stress
specific cooperative processes: coordination processes in order to manage task interdependencies, establishment of common
ground and negotiation mechanisms in order to manage the integration of multiple perspectives in design.
This study seeks to shed light on how communication patterns in geographically distributed software development (GDSD) projects evolve over time and how they relate to developers' contributions to the development effort. Data from two GDSD projects from two distinct companies were collected. The analysis showed that the definition of formal roles had an important impact on patterns of communication across development locations. In one project a group of developers emerged over time as the liaisons between geographical locations. In addition to handling the communication and coordination load across locations, those same engineers contributed the most to the development effort. On the other hand, in the second project, communication across site was formalized and the developers involved in the cross site communication and coordination activities were not as productive.
Organizations are increasingly moving to the global software development(GSD) model because of significant benefits that can accrue. However,GSD is fraught with difficulties arising from geographical, temporal and sociocultural distances. The emphasis in the literature to date has typically been onhow to overcome these significant challenges associated with GSD. While anumber of GSD benefits have been identified in the literature, there are also anumber of less obvious, what we term 'unknown, ' potential benefits that canaccrue from GSD. Here we synthesize and integrate an overall set of potentialGSD benefits and categorize them according to the organizational, team andprocess level to which they are most applicable. The 'unknown' includes organizationbenefits, such as improved resource allocation, team benefits, suchas reduced coordination cost and improved team autonomy, and process benefits,such as improved documentation and clearly defined processes.
Software modularity is not a new concept in the software engineering field; it has been a design issue since the earliest days of software development. Because the software designer cannot be expected to conceptualize a complex software application as a whole, it is usual to create a top-level design which is decomposed into a set of modules. The degree of modularization is a subjective concept that is difficult to measure; however, coupling and cohesion are two well-known concepts that are used to characterize software modularization.In this paper we illustrate how requirement scenarios can be clustered, based on attributes identified in the scenarios to quantitatively assess software modularization. Our technique uses a data mining clustering method that clusters scenarios, so that those scenarios within a cluster have a strong functional relationship with one another and weak relationships with scenarios in other clusters. Hence, cohesion within clusters is maximized while coupling between clusters is minimized. Consequently, software modularization based on these clusters should provide a good initial design.
Due to ever increasing system complexity, comprehensive methods for software architecture evaluation become more and more
important. This is further stressed in global software development (GSD), where the software architecture acts as a central
knowledge and coordination mechanism. However, existing methods for architecture evaluation do not take characteristics of
GSD into account. In this paper we discuss what aspects are specific for architecture evaluations in GSD. Our experiences
from GSD projects at Capgemini sd&m indicate, that architecture evaluations differ in how rigorously one has to assess modularization,
architecturally relevant processes, knowledge transfer and process alignment. From our project experiences, we derive nine
good practices, the compliance to which should be checked in architecture evaluations in GSD. As an example, we discuss how
far the standard architecture evaluation method used at Capgemini sd&m already considers the GSD-specific good practices,
and outline what extensions are necessary to achieve a comprehensive architecture evaluation framework for GSD.
The automated synthesis of software architecture design and associated work allocation plan is considered, given the requirements of the system and a specification of the available, possibly distributed development teams. The technique applies genetic algorithms, with mutations introducing changes both in the architectural solutions and in the work allocation schemes. The technique is implemented and evaluated using a non-trivial example system, the control system of an electronic home. The results suggest that genetic algorithms are a viable approach to solve this kind of multi-targeted optimization problem, assuming that the architectural quality and work allocation fitness can be given appropriate metrics.
Three trends accelerate the increase in complexity of large-scale software development, i.e. software product lines, global development and software ecosystems. For the case study companies we studied, these trends caused several problems, which are organized around architecture, process and organization, and the problems are related to the efficiency and effectiveness of software development as these companies used too integration-centric approaches. We present five approaches to software development, organized from integration-centric to composition-oriented and describe the areas of applicability.
The prospect of offshoring and outsourcing business processes has captured the imagination of CEOs everywhere. In the past five years, a rising number of companies in North America and Europe have experimented with this strategy, hoping to reduce costs and gain strategic advantage. But many businesses have had mixed results. According to several studies, half the organizations that have shifted processes offshore have failed to generate the expected financial benefits. What's more, many of them have faced employee resistance and consumer dissatisfaction. Clearly, companies have to rethink how they formulate their offshoring strategies. A three-part methodology can help. First, companies need to prioritize their processes, ranking each based on two criteria: the value it creates for customers and the degree to which the company can capture some of that value. Companies will want to keep their core (highest-priority) processes in-house and consider outsourcing their commodity (low-priority) processes; critical (moderate-priority) processes are up for debate and must be considered carefully. Second, businesses should analyze all the risks that accompany offshoring and look systematically at their critical and commodity processes in terms of operational risk (the risk that processes won't operate smoothly after being offshored) and structural risk (the risk that relationships with service providers may not work as expected). Finally, companies should determine possible locations for their offshore efforts, as well as the organizational forms--such as captive centers and joint ventures--that those efforts might take. They can do so by examining each process's operational and structural risks side by side. This article outlines the tools that will help companies choose the right processes to offshore. It also describes a new organizational structure called the extended organization, in which companies specify the quality of services they want and work alongside providers to get that quality.
A variety of academic work argues a relationship exists between the structure of a development organization and the design of the products that this organization produces. Specifically, products are often said to "mirror" the architectures of the organizations from which they come. This dynamic occurs because an organization's problem solving routines and normal patterns of communication tend to constrain the space of designs within which it searches for new solutions. Such a link, if confirmed empirically, would be important, given that product architecture has been shown to be an important predictor of product performance, product variety, process flexibility and industry evolution. We explore this relationship in the software industry by use of a technique called Design Structure Matrices (DSMs), which allows us to visualize the architectures of different software products and to calculate metrics to compare their levels of modularity. Our research takes advantage of a natural experiment in this industry, where products exist that fulfill the same function, but that have been developed using very different organizational modes - specifically, open source versus closed source development. We use DSMs to analyze a sample of matched-pair products - products that perform the same function but that have been developed via these contrasting modes of organization. Our results reveal significant differences in modularity, consistent with a view that larger, more distributed teams tend to develop products with more modular architectures. Furthermore, the differences between systems are substantial - the pairs we examine vary by a factor of eight, in terms of the potential for a design change to propagate to other system components. We conclude by highlighting some implications of this result for both innovating managers, as well as researchers in the field. We also assess how future work in this area might proceed, based upon these first steps in measuring "design."