Creating a Software Architecture for Distributed Development

Min Chen, Bharat Gorantla, Okeno Palmer, Lutz Wrage Master of Software Engineering Program Carnegie Mellon University Pittsburgh, PA 15213 {minc1, bgorantl, orp, lw}@andrew.cmu.edu Abstract
Many companies have been using the distributed development model in their quest for lower costs and availability of skilled resources to create software products. However, distributed development projects face major problems due to inter-dependencies among work items and challenges of coordination because effective communication is difficult to achieve in distributed environments. Software architecture helps with the coordination of distributed teams when designed appropriately taking in consideration the communication problems that are exacerbated by the distributed environment. Software architecture by itself does not assure the success of a distributed development project, but the architecture artifacts do provide information about the expected communication patterns among the distributed teams and, hence, a better insight on how to manage the project. Keywords: Software Architectures, Programming teams

1. Introduction
Major sources of problems in distributed software development are inter-dependencies among work items and challenges of coordination. Effective communication is difficult to achieve for distributed teams because of distance, language, culture, time difference, and work environment. Previous research suggests that the use of architecture, process, and tools helps 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." "[Software architecture] allows groups of people – often separated by organizational, geographical, and even temporal boundaries – to work cooperatively and productively together to solve a much larger problem than any of them would be capable of individually." [2]. Architectures have a strong influence on the communication patterns of development teams. Therefore, they can be used to study distribution, in the sense of suggesting which software components should be developed by which organizational units. Software architecture and structure of the organizational units that will implement it must match to successfully produce a system. However, literature about architectures suitable for distributed teams is scarce. There are many methodologies to reason about quality attributes also known as non-functional requirements [3], such as performance and modifiability, but little is said about the suitability of an architecture for distributed development. 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

1

architecture team responsible for re-designing a software architecture suitable for distributed development.

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 "JOYA". The goals of the JOYA 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 JOYA 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. First Iteration Problems The main problems we encountered while trying to implement the original JOYA architecture were in the 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.1.2. Requirements Elicitation Issues: The original JOYA 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

2

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

3. Creating the New Architecture
When analyzing the problems that caused the first iteration of the JOYA project to fail, we identified several tactics we used to increase the distributability of our software architecture. By distributability we mean the suitability of the architecture for development by distributed teams. 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

3

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 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 selfcontained 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 JOYA 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. Dividing 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: 1) Identify Criteria. Create a prioritized list of criteria to guide in assigning work units to teams. 2) Identify & Create Artifacts. For each criterion from the previous activity, create artifacts that specifically address this criterion. 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

4.1. Criteria ID Criterion Description Each team will be responsible for a set of functionality to reduce the need for communication with other teams. Artifacts 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. 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 in which order 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 JOYA architecture. A timeline view was derived from the optimized matrix. It is necessary to know the technologies that are required to implement each of the modules of the JOYA system. Hence, the architecture team created a technology view that maps each module to the technologies that are required in its implementation.

C1 Allow teams to focus on specific functionalities.

C2 Create JOYA using incremental development.

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

C3 Create JOYA using bottom up development.

Before developing each module, other modules it depends on should already be developed or under development.

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

Table 1. Work Units Assignment Criteria

5

4.1.1. Other Artifacts: To balance the teams' workload and resources, the architecture team estimated the development effort required for each module. Information about the teams, such as size, expertise and availability are also necessary, but they were not available when assigning work units. This is shown in a development effort view. 4.1.2. Assumptions: Since the profile of the development teams was unknown, the architecture team made the assumption that no team would have significant experience in any of the required technologies. 4.2. Artifacts The artifacts presented in this section are those we created to address the criteria of the previous section. 4.2.1. Dependency View A Design Structure Matrix (DSM) was used to create the dependency view based on the modules of the JOYA 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 [5].

Table 2. Dependency View 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

6

manual DSM partition algorithm. Marks in the matrix explain if there are dependencies among the modules and, if so, which kind of dependency. A ”1“ in bold represents a “uses” dependency, and a “1” in regular font represents a regular dependency. A uses dependency is stronger than other dependencies: if module A uses 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 the two modules 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 is derived from the dependency view. It is based solely on the uses dependencies to determine in which period a module can be developed. Regular 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 uses dependencies.

Table 3. Timeline View

7

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. 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 across several periods.

4.2.3. Technology View The Technology View 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.

Table 4. Technology View For the JOYA system we identified five technologies the development teams will use in its implementation. As we assume that the teams do not have extensive 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 shows the relative effort required to implement each module in terms of:

8

Technologies involved in the implementation of the module Complexity of the design of the module Amount of functionality contained in the module

Table 5. Development Effort View 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 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.

4.3. Results of Work Unit Assignments Based on information from the dependency view, 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 below 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.

9

Table 6: Work Unit Assignment View

The work unit assignment view takes the form of a grid with information embedded in each axis of the grid. The primary information from this view is the assignment of modules to teams. This is expressed in the main grid which is the white colored area of the grid. All supplementary information is then embedded around this main grid. This information can then be read both vertically and horizontally to the express information previously identified. 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 JOYA's functionality will grow across periods.

10

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, the CMU team can 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 1-3 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.

11

5. Conclusion
Software architecture by itself can not 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 component 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 deducted 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 JOYA 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) element dependencies.

6. Author biographies
Min Chen is one of the founders and principal consultant at Alcenit Consulting Services. Her research interests involve process improvement and distributed development. Previously, she worked as a software consultant for the Latin America region. She was a Fulbright scholar when she pursued the Master of Software Engineering degree at CMU. She can be contacted at mchen@alcenit.com. Bharat Gorantla is a Software Engineer at Bentley Systems. His research interests software architecture, security for software systems, and global software development. Previously, he developed financial software systems. He holds a Masters in Software Engineering from CMU. He had co-authored an IT textbook for Secondary Schools published by Marshall Cavendish International in 2004. He can be reached at bgorantl@cs.cmu.edu. Okeno Palmer is a Software Systems Architect at Verizon. He is a graduate the Master of Software Engineering program at CMU. He is also a contributor to the codeproject.com community. He can be contacted at keno@coretechnologies.com. Lutz Wrage is a senior member of the technical staff at the Software Engineering Institute (SEI) of CMU. He is currently working in the areas of integration of software-intensive systems and real-time architecture description languages. Previously, he worked as a consultant for enterprise resource planning systems integration and customization. He has over ten years of experience in software engineering.

12

7. Acknowledgements
We would like to thank Prof. Jim Herbsleb, Tony Lattanze, Cliff Huff, and Felix Bachmann for their support in this project.

8. References
[1] J. Herbsleb and R. Grinter, “Splitting The Organization and Integrating the Code: Conway's Law Revisited”, International Conference on Software Engineering, 1999. [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-di-management.it, No.9, 2004.

13

Sign up to vote on this title
UsefulNot useful