Creating a Software Architecture for Distributed Development
-
Upload
amy-min-chen -
Category
Documents
-
view
223 -
download
0
Transcript of Creating a Software Architecture for Distributed Development
-
8/7/2019 Creating a Software Architecture for Distributed Development
1/13
1
Creating a Software Architecture for Distributed Development
Min Chen, Bharat Gorantla, Okeno Palmer, Lutz WrageMaster of Software Engineering Program
Carnegie Mellon UniversityPittsburgh, 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
-
8/7/2019 Creating a Software Architecture for Distributed Development
2/13
2
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 workon 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, toexperiment 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 welldocumented 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 inSeptember 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 ProblemsThe 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
-
8/7/2019 Creating a Software Architecture for Distributed Development
3/13
3
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 butthere 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. Thisled 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 softwarearchitecture. 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 containsdetailed interface definitions to limit the amount of communication necessary to
-
8/7/2019 Creating a Software Architecture for Distributed Development
4/13
4
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 therun-time architecture as several communicating processes. Each process shouldbe 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 JOYA system is already highly
multithreaded.
3)Trade distributability for code sharing. Each time a team uses modules that aredeveloped 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 modulesavailable 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 teammembers' 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 unitsto teams.
2)Identify & Create Artifacts. For each criterion from the previous activity, createartifacts that specifically address this criterion.
3)Propose Work Unit Assignment. Create a work unit assignment that takes all criteriainto 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.
-
8/7/2019 Creating a Software Architecture for Distributed Development
5/13
5
4.1.CriteriaID Criterion Description Artifacts
C1 Allow teams to
focus on specific
functionalities.
Each team will be responsible
for a set of 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 JOYA using
incremental
development.
There should be a functional
system by the end of each
incremental 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 todecide in which order modules
have to be implemented.
C3 Create JOYA using
bottom up
development.
Before developing each
module, other modules it
depends on should already be
developed or under
development.
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 optimizedmatrix.
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.
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.
Table 1. Work Units Assignment Criteria
-
8/7/2019 Creating a Software Architecture for Distributed Development
6/13
6
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.ArtifactsThe 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 therepresentation 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
-
8/7/2019 Creating a Software Architecture for Distributed Development
7/13
7
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 modulesdepend 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 Yassines 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
-
8/7/2019 Creating a Software Architecture for Distributed Development
8/13
8
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 Period1 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 ofthese, 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/7/2019 Creating a Software Architecture for Distributed Development
9/13
9
Technologies involved in the implementation of the moduleComplexity of the design of the moduleAmount 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 experienceand expertise.
The purpose of this view is to help balance the workload of the work units.
4.3.Results of Work Unit AssignmentsBased 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.
-
8/7/2019 Creating a Software Architecture for Distributed Development
10/13
10
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 ofthe 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 inmulti-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 thatperiod. 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.
-
8/7/2019 Creating a Software Architecture for Distributed Development
11/13
11
4)Technologies that each team has to know to implement their modules. At the bottomof 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. Thisinformation is expressed horizontally above the main grid. The intersection of team nameand 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 isshown in the main grid. The existence of empty cells read vertically in a team namecolumn 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 nodevelopment 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 thetechnologies 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 duringperiods 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 moduleand Rules module. Ideally, these two modules should be implemented by two teamsinstead 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.
-
8/7/2019 Creating a Software Architecture for Distributed Development
12/13
12
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 [email protected].
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 [email protected].
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 [email protected].
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.
-
8/7/2019 Creating a Software Architecture for Distributed Development
13/13
13
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.