Planning Distributed Development through Software Architecture

Min Chen, Bharat Gorantla, Okeno Palmer, Lutz Wrage Master of Software Engineering Program Carnegie Mellon University Pittsburgh, PA 15213, USA {minc1, bgorantl, orp, lw}@andrew.cmu.edu

Abstract
Coordination among distributed teams is the major challenge in global software development projects because effective communication is difficult to achieve. Software architecture, when designed appropriately, helps to increase coordination while minimizing the need for communication among teams. Software architecture for globally developed systems must take into consideration the communication problems that are exacerbated by distance, different languages and cultures, time difference, and work environment. Furthermore, techniques to assign architecture elements to distributed teams must consider module dependencies, technologies, development effort, and end-to-end functionality for each development iteration. This facilitates project administration by providing the necessary insight and flexibility when managing global development projects.

1. Introduction
Global software development projects face coordination problems because of ineffective communication and inter-dependencies among teams. Effective communication is difficult to achieve in a distributed environment because of distance, different languages and cultures, time difference, and work environment. Previous research suggests that the use of well-designed architectures, processes, and tools help to coordinate the work of distributed teams while minimizing the need of communication across these teams [1]. Software architecture is defined as "the structure or structures of the system, which consist of elements, their externally visible properties, and the relationships among them." It allows groups of people separated by organizational, geographical, and even temporal boundaries to work cooperatively and productively [2].

Moreover, it has a strong influence on the communication patterns of the development teams because it determines the module dependencies of the system that will be developed by these teams. Consequently, a well-designed architecture can be used to study distribution, in the sense of suggesting which software modules should be developed by which teams. Software architecture is driven by functional requirements, quality attributes, and constraints. Quality attributes are often addressed as non-functional requirements such as performance, security, and interoperability of the system. Distributability, on the other hand, is an attribute of the architecture that makes the system suitable for development by distributed teams. Architecture documentation is comprised of a collection of views. The static, runtime, and physical are the three main perspectives of a system that can be represented with views. Module views contain classes, functions, and interfaces to represent properties of the system from the static perspective. Component-andconnector (C&C) views encompass processes and sequence diagrams to represent the properties from the runtime perspective. Allocation views of computers, devices, and networks are used to represent properties of the system from the physical perspective. Every view focuses on quality attributes of the architecture. For example, module views can be used to reason about interoperability and portability; C&C views to address performance and security; and allocation views to address disk capacity and memory properties. However, distributability is not addressed by any of the views alone. Module views are useful when analyzing inter-dependencies among modules to decide which architecture elements can be assigned to which teams. C&C views are important when studying whether the structures of the system are independently testable. Allocation views provide the assignment of modules to teams.

This paper describes our experiences and lessons learned when working as a development team in a global development project at Carnegie Mellon University (CMU), and as the architecture team responsible for redesigning a software architecture suitable for distributed development and proposing the assignation of architecture elements to distributed teams.

areas of communication, requirements elicitation, work assignments, and distributed implementation. 2.1.1. Communication Issues. The project was organized following a hub-and-spoke model. The client had a central team, the hub, and the student teams were arranged around the center. Student teams could directly communicate with the central team, but all communication between student teams had to be facilitated by the central team. The goal of this organizational structure was to limit the number of communication channels and thus control the communication overhead in the distributed environment. However, the software architecture was not well suited for this model because it required close collaboration of student teams, for example, to define component interfaces that needed to be shared among teams.

2. Project Overview
The project on which we base this paper was a Studio project in the Master of Software Engineering program at CMU. Our Studio team consisted of 4 graduate students. This team was one of seven teams distributed across the world who were chosen by the client to work on a global development research project named "JOY". The goals of the JOY project were to: • Learn from experimentation of processes in a globally distributed context. That is, to experiment with processes and to observe the influence of requirements, architecture, and process documentation on development in a globally distributed environment. • Determine how having a stable set of requirements, a sound architecture and a well documented lightweight process can influence development in a distributed context. The focus of the project was on observing the teams and distilling lessons learned for distributed development. It was not to create a product for use in a production environment. The JOY project was planned for a duration of three years; the first iteration started in September 2004 and was planned to end in August 2005. The client had prepared an initial, high-level software architecture of the system, and each team would develop one or more components of this architecture. The CMU team was mainly responsible for developing a basic component called system object model. However, due to coordination problems that arose, the CMU team was later given the responsibility of recreating the architecture for the same system to make it suitable for distributed development and proposing an initial work unit assignment for the new distributed development teams based on the revised architecture.

2.1.2. Requirements Elicitation Issues. The original JOY software architecture was based on a set of architectural drivers that included high-level functional requirements and a number of constraints. For example, the system had to be Web-based, and it had to update the user interface asynchronously whenever certain measured values changed. However, we found that many of these requirements were not understood in enough detail to create a viable architecture. In addition, quality attribute requirements had not been documented at all. As a result, in the original architecture, the responsibilities of components and their interfaces were not defined in as much detail as the teams needed to develop their assigned components. Particularly the lack of documented quality attribute requirements made it difficult to refine the component design consistently across development teams. We had planned to use the attribute-driven design method, but this method requires this kind of information to be documented in the architecture [3]. 2.1.3. Work Assignments. Each student team was assigned a number of components to develop. One criterion for assignment was a preference given by the teams; other criteria were not explained to the teams. However, in the course of the project it became obvious that the central team had not considered component inter-dependencies to the degree necessary for success. Incremental deliveries were organized by use cases which led to situations where parts of a use case were to be implemented in components developed by different teams but with the same delivery date.

2.1. First Iteration Problems
The main problems we encountered while trying to implement the original JOY architecture were in the

2.1.4. Distributed Implementation Issues. The lack of detail in the original software architecture made it necessary for the student teams to add missing interface definitions to their assigned components. Adding or modifying a component interface is a change in the architecture that must be communicated to all development teams that use this interface but there was no process in place to manage this kind of change. The original strategy called for the central team to integrate components developed by the student teams. It did not work well because there were dependencies among components which were not immediately obvious in the architecture, and the schedule did not take them into account. 2.1.5. First Iteration Results. In May 2005 it became clear that the original approach would not result in the creation of a system that could demonstrate even simple end-to-end functionality. The code produced by the student teams constituted an incomplete set of components that did not fit well together. The central team realized that they had significantly underestimated the effort to manage such a distributed development project. This led to many of the problems because the teams were assigned responsibilities that should have been executed by the central team. The most prominent mistake in this regard was that it was left to the student teams to define component interfaces without exercising control over the content of the interfaces and over interface changes. The next section describes our approach for designing an architecture suitable for distributed development. We then focus on criteria and artifacts that help in assigning work to distributed teams.

that communication among teams may still be necessary to evolve interface specifications, but given our architecture this will require significantly less communication than to negotiate completely new interfaces. 2) Make components independently testable. We accomplished this designing the run-time architecture as several communicating processes. Each process should be assigned to one team for development such that they all work on largely self-contained pieces. This tactic may increase the complexity of the overall architecture. Integration testing will be more complex compared to a monolithic system, but only to a limited degree because the JOY system is already highly multithreaded. 3) Trade distributability for code sharing. Each time a team uses modules that are developed by other teams a strong dependency is introduced. The required coordination among the teams may offset any savings the shared modules can achieve. Our architecture contains two very similar small modules that will be developed by independent teams. 4) Create more modules than there are distributed teams. More modules available for assignment to teams make planning more flexible. Work assignments can be adapted to the teams' technical expertise and to schedule constraints. The trade-off is that the architecture becomes more complex with each added module because module responsibilities and interfaces need to be specified.

4. Creating and Assigning Work Units
The main effort of the architecture redesign was focused on dividing work among teams. At the time we created the architecture, the central team only knew that there would likely be six student teams to implement the system. However, we had no information about the team members' profiles, background, and availability. Hence, we compiled information for use by the project management to assign work units to the distributed teams. This information will also inform the milestones in the project schedule. To accomplish this we executed the following activities:

3. Creating the New Architecture
When analyzing the problems that caused the first iteration of the JOY project to fail, we identified several tactics we used to increase the distributability of our software architecture. Some of these tactics increase the architecture's level of detail, while others are related to the kind of artifacts included in the architecture documentation. 1) Address communication with interfaces. Our revised architecture contains detailed interface definitions to limit the amount of communication necessary to coordinate distributed development efforts. In addition we provide sequence diagrams that show how components and interfaces are used to achieve the system's overall functions. We realize that

1) Identify Criteria. Create a prioritized list of criteria to guide in assigning work units to teams. 2) Identify and Create Artifacts. For each criterion from the previous activity, create artifacts that specifically address this criterion. An artifact is a representation

representation tool that helps communicating and analyzing a concept. 3) Propose Work Unit Assignment. Create a work unit assignment that takes all criteria into account. As we did not have enough information about the teams' level of expertise, our work assignment will serve as a starting point that the central team will adapt.

4.2 Artifacts
The artifacts presented in this section are those we created to address the criteria of the previous section. All the modules listed below are part of the detailed architecture. High-level modules are composed from one or more of the modules listed below. 4.2.1. Dependency View. A Design Structure Matrix (DSM) was used to create the dependency view based on the modules of the JOY system. The DSM is a tool that displays the relationships between elements of a system in a compact, visual, and analytically advantageous format [4]. The DSM method is an information exchange model that allows the representation of complex module relationships in order to determine a sensible sequence for the modules being modeled. The DSM in Table 2 is a module-based binary matrix which rows and columns are headed with the complete list of modules of the system. This is the final DSM as the result of using a manual DSM partition algorithm to determine the optimum module development sequence. Marks in the matrix explain if there are dependencies

4.1 Criteria
Table 1 shows the criteria decreasing priority order. These criteria are based on the customer’s preferences. In addition, to balance the development teams' workload and resources, the architecture team estimated the development effort required for each module. In an ideal situation the architect would have information about the teams, such as size, expertise and availability to accurately estimate the effort. In the JOY project the profiles of the development teams were unknown, so the architecture team made the assumption that no team would have significant experience in any of the required technologies. The result of these considerations is shown in the development effort view.

ID C1

Criterion Allow teams to focus on specific functionalities

Table 1. Work Units Assignment Criteria Description Artifacts Each team will be responsible for a functionality to reduce the need for communication with other teams. The modules, as designed by the CMU team, are created with high cohesion and low coupling in mind. Hence, the resulting modules are packages of functionalities. The module view of the architecture helps to reason about this criterion.

C2

Create JOY using incremental development

There should be a functional system by the end of each release.

To have a functional system in each release, the development teams have to implement elements of the architecture that will fulfill functional requirements. Prioritized use cases are one artifact used to decide the order in which the modules have to be implemented. An artifact that shows the module dependencies along with the possible timelines will be the best for this criterion. The CMU team used a Design Structure Matrix (DSM) to create a module dependency view of the JOY architecture. A timeline view was derived from the optimized matrix. It is necessary to know technologies that are required to implement each of the modules of the JOY system. Hence, the architecture team created the technology view that maps each module to the technologies that are required in its implementation.

C3

Create JOY Before developing each using bottom up module, other modules it development. depends on should already be developed or under development. Allow teams to focus on few technologies. Save time by assigning work units to teams according to their expertise. Assign modules to teams to minimize the number of teams that need to learn a technology.

C4

Table 2. Design Structure Matrix
Number of modules this depends on Module PS CP CFG VC DA CD COV AM PD AP ARE HED AD LRE RED LO ID 1 3 14 4 5 6 15 9 11 16 12 7 10 13 8 2 1 3 14 4 5 6 15 9 11 16 12 7 10 13 8 2 0 0 0 1 1 1 1 5 3 3 4 2 2 4 3 4 0 0

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 10 1 1 1 1 1 1 1 1 1 1 2 1 3 2 2 1 1 1 1 1 1 1 1

1

Number of dependants Legend

6

2

1

1 in bold = strong dependencies 1 regular = weak dependencies

there are dependencies among the modules and, if so, which kind of dependency. A ”1“ in bold represents strong dependency, and a “1” in regular font represents a weak dependency. If module A has a strong dependency on module B, A needs a correct implementation of module B to run correctly. Each row represents all the modules required for the implementation of the module corresponding to that row. Similarly, reading down a specific column shows which modules depend on, or use, the module corresponding to that column. For example, the PS module depends on no other modules, but 6 modules depend on it. The order of the modules in the DSM shows a possible sequence of development. The first three modules (PS, CP, CFG) can be developed in parallel as they do not depend on each other and not on modules outside this group. Following this group, there are 11 modules (VC through LRE) which depend on the modules in the first group as well as on other modules within this group. Some of these modules can be developed in parallel; others have to be developed in sequence. Finally, the last two modules (RED, LO) do not have any dependants, and they can be developed in parallel as they do not depend on each other.

For more information about DSM and partition algorithms, refer to Yassine’s paper [5]. 4.2.2. Timeline View. The timeline view (Table 3) is derived from the dependency view. It is based solely on the strong dependencies to determine in which period a module can be developed. Weak dependencies were not taken into consideration because development teams can create stubs to simulate functions of the required module if it is not ready. Stubs cannot be used to replace modules in strong dependencies. This view partitions the project into four time periods. These do not necessarily have the same duration. The earliest possible section indicates the period in which a module can be developed right after all its required modules are ready. The latest possible section indicates the last period in which a module can be developed without delaying the development of its dependants, if any. Some modules have to be developed in the same period for both options. The names of these modules are shown in bold. For example, the VC module has to be developed in Period 1 regardless if the option is earliest or latest possible.

Option Earliest Possible Latest Possible

Table 3. Timeline View Period 1 Period 2 Period 3 PS VC DA CE HED CP COV AM PD RED CFG AP LO AM VC DA CFG CE CP

Period 4 AD ARE LRE AP LO PD LRE ARE COV AD PS HED RED

The timeline view does not take into consideration system functionality and size of the modules. That is, developing the modules in the suggested order does not guarantee an incremental development. In addition, the view does not show if development of a module can span several periods. 4.2.3. Technology View. The Technology View shown in Table 4 provides information about the technologies that each module will require for its implementation. The purpose of this view is to identify how many technologies a development team will have to learn for its work units. For the JOY system we identified five technologies the development teams will use in its implementation. As we assume that the teams do not have experience in any of these, the number of technologies a team uses should be limited to no more than three.

4.2.4. Development Effort View. The Development Effort View (Table 5) shows the relative effort required to implement each module. The effort estimation must take into account: • Technologies involved in the implementation of the module • Complexity of the design of the module • Amount of functionality contained in the module • Expertise and experience of developers The relative effort is measured as high, medium, and low. That is, a module assigned high effort requires more effort than a module assigned medium, but two modules with high effort may or may not take the same amount of time. We estimate that modules within a category will require similar amounts of time for development. We could not provide a more precise effort because we did

Module PD AD HED RED LO PS CP VC CP COV ARE LRE AP CFG DA AM

ASP.NET × × × × ×

Table 4. Technology View Technology AJAX .NET Remoting C# Programming × × × × × × × × × × × × × × × × × × × × × × × × × × × × × × × ×

NHibernate

×

effort because we did not have the necessary information about the teams’ level of experience and expertise. The purpose of this view is to help balance the workload of the work units. Table 5. Development Effort View Module Effort PS High LO Low CP Medium VC Low DA High CE High HED Medium RED Medium AM Medium AD Medium PD High ARE Low LRE Low CFG Medium COV Low AP Medium

timeline view, technology view, and the development effort view, a more informed way of assigning work in a distributed environment can be done. The work assignment view shown in Table 6 merges information from all four views and provides a work assignment distribution that factors in module dependencies, sequence of implementation of the modules, technological expertise required, and estimated development effort. The work unit assignment view takes the form of a grid. Information from the grid is read as follows: 1) Modules assigned to specific teams. This information is contained in the white area of the grid. Teams are specified across the top of the grid in columns. Modules assigned to each team are then specified in a cell in a grid column below the team name. 2) Period of time in which a module must be implemented. Periods are expressed in multi-colored rows of the main grid. Modules are placed in cells that intersect the team name and the period in which the module must be implemented. Periods do not necessarily have the same length. The duration depends on the estimation of the development teams based on their low-level design. 3) Expected functionality at the end of a period based on modules implemented in that period. This information is expressed to the right on the main grid which expectations for each period included in the same color and row as the targeted period. Reading this information vertically from top to bottom shows how JOY's functionality will grow across periods.

4.3. Results of Work Unit Assignments
Based on information from the dependency view,

Table 6. Work Unit Assignment View
FSS Adapter, Adapter Manager Rules, Presentation Rules, Presentation High-level Module Presentation Team 6 Publish Subscribe

Team 1 1. PS (H) Period 1

Team 2 3. CP (M) 14. CFG (M) 15. COV (L) 9. AM (M)

Team 3 4. VC (L)

Data

Team 4

Team 5

Expected Functionality (End of Period) Basic communication from FSS to JOY and viceversa without persistence Full communication from FSS to JOY including persistence

5. DA (H)

Period 2 16. AP (M) 10. AD (M) 12. ARE (L) Period 4 Technology required by each team X X X X X X X X X 6. CE (H) 8. RED (M) 13. LRE (L) 11. PD (H) 7. HED (M) 2. LO (L)

Period 3

User Interface

Rule Engines

C# .Net Remoting ASP.Net AJAX NHibernate

X X

X X X

X X X X

Back-end

Front-end

across periods. 4) Technologies that each team has to know to implement their modules. At the bottom of the main grid, the technologies that each team needs to know to implement their assigned modules are specified. Teams need to know several technologies for their set of assigned modules and each technology is specified in a single row below the main grid. A marked cell that intersects the team name with a technology specifies which technology that team needs to know to implement their set of modules. 5) System's high-level modules that each team will be involved in implementing. This information is expressed horizontally above the main grid. The intersection of team name and high-level module name shows which teams are involved in the implementation of the details of a high-level module(s). 6) Length of time in terms of periods that teams will need to be involved in the project. This information is expressed in the form of empty cells in the main grid. An empty cell means that a team is not needed during that period of development. Reading this information vertically indicates how long a team is needed for the duration of the project across the periods. Reading this information horizontally gives no information as the size of modules is not specified. 7) Time available for teams to learn technologies they need to know. This information is shown in the main grid. The existence of empty cells read vertically in a team name column indicates that a team has no modules assigned to them in a period. Given that the technologies a team needs is known, then a team can use this time to learn a technology before they start work on their modules. Several important observations can be made from the work assignment view and interpreting the information embedded in this view. These observations are as follows: • During the first 2 periods, the system's implemented functionality will include no development of the user interface. Modules that constitute the back-end functionality will all be implemented. • The front-end will be developed in the last 2 periods of development. • All teams need to learn C# and .NET Remoting. Based on these observations, we could make the following suggestions:

• As soon as teams are identified for the project, provide them with information about the technologies they need to know. This will help in the productivity and speed of development of the project as teams will become familiar with their development tools before the start of the project. • Documentation of the back-end functionality can be focused on intensively during periods 3-4 by teams 13 as they will have “free time” based on the current work distribution. • Teams 4-6 will have to coordinate more because they work on the Presentation module and Rules module. Ideally, these two modules should be implemented by two teams instead of three; hence, more coordination is required and expected. The central team should facilitate the communication channel among these teams and provide the guidelines for user interface design in order to achieve the same look and feel throughout the system.

5. Conclusion
Software architecture by itself cannot assure the success of a distributed development project. An integrated project that incorporates a project plan, a development process, a product integration process, a configuration management environment, and a software architecture that all support distributed development must be in place for the success of a distributed development effort. A project plan for a distributed development project needs to be structured based on the module dependencies. This is a direct consequence of dependencies present in the software architecture. A plan that is based on the software architecture will be more able to accommodate planning across teams and consider integration and communication that needs to occur between teams. The scheduling and organization of teams and resources in the project plan can be deduced from the time line and development effort views defined earlier in this article. A distributed development environment directly affects the elements and relationships defined in a software architecture. During the design of the JOY architecture, the main elements affected by the distributability requirement were the relationships between elements of the architecture because they are closely related to communication between the teams that implement the elements. In creating a software architecture, the architect must consider work assignment as one of the important allocation views of the software architecture. Work

assignment will be based on (1) skill set of development teams, (2) development team availability, (3) feature list requirements, (4) incremental delivery schedule, and (5) module dependencies.

[2] P. Clemens et al., Documenting Software Architecture, Addison Wesley, United States, February 2004. [3] L. Bass et al., Software Architecture in Practice, Addison Wesley, United States, October 2004. [4] T.R. Browning, “Applying the Design Structure Matrix to System Decomposition and Integration Problems: A Review and New Directions”, IEEE Transactions on Engineering Management, Vol. 48, No. 3, August 2001, pp. 292-306. [5] A. Yassine, “An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method”, Quaderni di Management (Italian Management Review), www.quaderni-dimanagement.it, No.9, 2004.

6. Acknowledgements
We would like to thank Prof. Jim Herbsleb, Tony Lattanze, Cliff Huff, and Felix Bachmann for supporting us in this project with their knowledge, experience, and guidance.

7. References
[1] J. Herbsleb and R. Grinter, “Splitting The Organization and Integrating the Code: Conway's Law Revisited”, International Conference on Software Engineering, 1999.

Sign up to vote on this title
UsefulNot useful