Lecture 09-GSD

SWENG 580: Advanced Software Engineering
Global Software Development

ENGINEERING DIVISION, PENN STATE UNIVERSITY
Background
Global Software Development (GSD)
Motivation for GSD
Challenges to GSD
GSD Process
Open Source Software (OSS)
OSS Development Process
© Penn State University

Last updated: Wednesday, April 1, 2020
Background
Economic and technological determinants of the market
are reshaping the landscape of software development
Global distributed software development is on the rise
There is also a growing interest in software products

produced through open source software development
 Open source software development is a kind of global distributed
development
 developers from around the world cooperate with each other without any
monetary compensation
2
What is global software development?

Software development in a multi-site, multi-
cultural and distributed context
 Software development is viewed as a
geographically distributed network of workflows;

typically
 Requirements and high level design is done by a
central team at a single location
 Subsystems designed by the central team are
developed by remote teams at multiple different
locations
3
Motivation for GSD

Differences in development costs
Shift based system facilitated by time-zone
differences allowing for shorter time to
market
Limited trained workforce in a single location
in technologies that are required to build
today’s complex systems
Advances in infrastructure
4
Challenges to GSD
For any project, whether collocated or distributed,
to be successful a process framework needs to
orchestrate communication, coordination and
control effectively
 Teams working on a given project need to
communicate with each other
 Activities of the teams need to be synchronized
 Activities must be controlled to enforce common goals,
policies, standards and quality levels among the teams
5
Challenges to GSD (Contd.)

When the teams working on a project are geographically
distributed communication, coordination and control
become challenging (Carmel and Agarwal, 2001)
 Distance exacerbates the problem of clearly and unambiguously

communicating information between collaborating teams
 This becomes more complex if teams are separated by several time
zones
 Distance also makes it difficult to coordinate tasks within a
distributed development environment
 Distributed development environment makes it difficult to enforce
common goals, policies, standards and quality levels among
collaborating teams
6

One way to overcome this challenge is to
minimize excessive communication by
optimizing the collaboration among the
distributed teams
 Collaboration is optimized by breaking a system
into loosely coupled subsystems or components
and having each team work on a given
subsystem or component relatively independent
of each other
7

Another key aspect of successful projects
are good teams
Team building can also be challenging in
distributed projects for reasons such as

 Members not knowing each other
 Language and culture
 Absence of project’s daily processes to be
followed by members at different sites
8

This problem can be overcome by assigning project members
who straddle multiple teams
 They act as ambassadors or liaisons between teams and
help bridge the communication gap
 They must be engaged early in the inception and

elaboration phase; this helps them to
 Acquire the knowledge of the domain
 Gain an understanding of the architecture
 With the acquired knowledge, they can share the
architectural vision, and help answer majority of the
architecture and domain related questions from the
development teams locally
9

Agilityis also a desired feature for a
project’s process
A process must be lightweight – it

should minimize overhead measuring
progress based on a working product
rather than completed documents
 A process must be dynamic – it must
adapt easily to the needs of the project
10

Achieving agility seems counterintuitive in a
distributed development environment
 Agility requires close collaboration, therefore,
collocated not remote teams would be ideal

 More not less documentation is needed to
unambiguously communicate information to
remote teams
Anapproach that balances the two opposing
needs is desired
11
GSD Process (Sangwan et al, 2004, 2006)

We can start with the standard Unified Process that
 Is iterative and incremental
 Use case driven
 Architecture centric
 Actively manages risks

Activities can be divided into phases that have significant milestones
 Inception: Vision Milestone Phase
 Elaboration: Architecture Milestone Phase
 Construction: Operational Capability Milestone Phase
 Transition: Product Release Milestone Phase
Due to the nature of communication, coordination and control, we
need to tailor requirements engineering, architecture and project
management for GSD
12
Requirements Engineering
Using a model-driven requirements engineering
approach (Berenbach, 2003, 2004)
 Business requirements are modeled using UML and
progressively refined from product features to system

requirements and subsequently partitioned into
component requirements
This makes it easier to analyze, maintain
traceability among and version control fine grained
artifacts such as stakeholder requests, system
requirements, design specifications and test cases.
13
Requirements Engineering (Contd.)

Visual modeling aids comprehension and
communication among distributed teams
Precise semantics of UML leave less room
for ambiguity
Tool support for evaluating the models gives
on demand measure of size, progress,
consistency, completeness and quality
14
Requirements Engineering (Contd.)

Semi-automated transformation from earlier to later
modeling artifacts to reduce labor and mistakes in the
design process is also possible
Inception Elaboration Construction
Business
Components
Vertical
Slices
Design
Components
15
Architecture
The system under development is functionally
decomposed during the requirements engineering and
design process
 This yields an application architecture of loosely coupled and

highly cohesive set of components that can be designed and
developed relatively independent of each other.
Frameworks that address the non-functional requirements
of the system are also created
 A collection of these frameworks defines a technical architecture
which constrains how the functional components will be realized
and how they will communicate with each other.
16
Architecture (Contd.)
The application and technical architectures
together provide a roadmap of how pieces of the
system will be created and integrated into a
finished product
 The framework components that define the technical
architecture need to be in place before the application
components can be developed
 Once the framework components are developed it
becomes possible to develop independent application
components in parallel
17
Project Management
Organization of product solution
development is optimized using small
distributed component development teams
synchronized by a central organization

Activities are classified to be carried out
completely offsite, loosely onsite or onsite
(Laplante et al, 2004)
 This classification is based on communication,
coordination and control
18
Project Management (Contd.)

 For example, consider the activities for the inception phase in the following table
Objective Activities Responsible Artifacts
Determine Establish the vision Product Manager MRS†
what must Capture scenarios Requirements Engineer; Storyboards; Glossary
be built SME †
Create initial BOM Requirements Engineer; BOM †
SME
Create feature-level screen UI designer UI Prototypes
mockups
Identify key Transform the BOM into Requirements Engineer FRS †
functionali feature-level requirements

ty Determine Feasibility Architect ADD †
Understand Organize BOM and Requirements Engineer BOM (revised); FRS
risks requirements into business (revised)
† SME: Subject Matter Expert
components
† MRS: Marketing Requirements Specification
Global analysis
† BOM: Business Object Model
Architect Global Analysis
† FRS: Feature Requirements Specification Document
† PlanDocument
ADD: Architecture Description project Project Manager Project Plan
19

Each objective defines a cohesive set of activities that require close
collaboration among the people involved
These activities should, therefore, be carried out by a collocated
team
 Distributing a related set of activities is not prudent as it creates

communication overhead and, therefore, also impacts coordination and
control
In this particular instance, since the objectives are focused on
defining the product to be built, its key functionality and associated
risks, the central team must perform their associated activities with
some involvement of members from the distributed teams (loosely
onsite)
20

Thecentral team plays a key role in the inception
and elaboration phase
 Feature level product requirements (FRS) are refined to
system requirements (SRS) and partitioned into

component requirements (CRS)
 The design model partitions business components into
loosely coupled design components which can be
developed independently by distributed teams
 Some members of the distributed component
development teams are engaged to disseminate
architecture vision and domain knowledge
21

The design is carried through in sufficient detail
that the component interfaces are fully described
and can be tested
 Acceptance tests are provided along with CRS to

distributed component development teams
A common configuration management, defect
tracking and build/test environment is established
The distributed teams carry out the component
development in parallel in the construction phase
using iterative incremental development
22

The components are grouped into vertical slices that are
incrementally developed into user visible functionality
 The development plan follows a major cycle (vertical slice development
cycle) and a minor monthly cycle (component development cycle)
Vertical Slice 1
C1 C5 C2
C4 C3
Vertical Slice 2
C6 C7
C8
Vertical Slice 3
C9
C10 C11
Month 1 2 3 4 5 6 7 8 9 10 11 12
23

Theminor and major cycles are time
boxed
 Missingfunctionality is favored over
missing deadlines
The central team integrates the
increments into an executable version of
a product that is continuously built and
tested
24
Agility in GSD
Certain agile practices can be followed throughout the
product development lifecycle
 For example, short time boxed iterations delivering some fraction
of an executable product that is continuously built and tested,

test first development, continuous refactoring, pair programming
and stand up meetings
Other aspects such as collective code ownership and
customer onsite can be challenging
Most aspects of any agile development methodology (e.g.,
XP or SCRUM), however, can be easily supported during
the construction phase
25
Agility in GSD (Contd.)

Due to the limitation of certain agile practices to
scale up to large distributed projects it becomes
important to maintain fairly comprehensive
requirements and design models

 User stories and back-of-the-napkin design will not do
Some of this burden can be alleviated by
automating generation of some documents such
as FRS, SRS and CRS from the UML model and
also the acceptance tests
26
Open Source Software (OSS)

OSS development is a kind of distributed development
 Applications are built through the part-time contributions of many
developers from around the world
 Developers cooperate under a model of rigorous peer review

 Highly parallel development effort leads to innovation and rapid
advancement
 Problems are identified, characterized and fixed quickly
 Given enough eyeballs, all bugs are shallow (Raymond, 1991)
27
OSS (Contd.)
>70,000 OSS projects in SourceForge
Many well known, high quality projects
 Linux
 Mozilla
 Apache
 GNOME
 OpenOffice
 PostgreSQL
Range from small (< 5K SLOC) to very large (>

1M SLOC) systems
28
OSS (Contd.)
Systems show punctuated evolution with periods of
intensive rewrite
OSS systems co-evolve with their developer communities
 Team critical mass of 5-15 core developers needed to sustain a

viable system.
According to Lehman’s Laws, the mean growth rate would
be expected to decrease over time, however…….
Larger OSS projects have been shown to sustain super-
linear growth (Linux subsystems)
29
OSS Development Process (Scacchi, 2004)

Requirements Analysis and Specification
 Takes the form of threaded messages and web
site discussions
CVS,System Build and Incremental Release

Review
 Concurrent version systems play an essential
role for coordination of decentralized code
30
OSS Development Process (Contd.)

Maintenance as evolutionary redevelopment,
reinvention and revitalization
 Sharing, examining, modifying and redistributing

concepts and techniques
through minor improvements and mutations across many
releases with short life cycles.
 End users often act as developers or maintainers
- continually produce mutations that allow the system to
continually adapt to what the “user-developers” want it to do.
31

Project management
 Organized in interlinked layered meritocracy
A hierarchical organizational form that centralizes
-
and concentrates certain kinds of authority, trust and
respect for experience and accomplishment within
the team
 Operates as a “dynamically organized but

loosely coupled virtual enterprise”.
32

 Over 60% of OSS developers participate in 2 – 10 projects (Madey et al, 2002)
33
References
 Berenbach, B.; “The automated extraction of requirements from

UML models,” Proceedings of the 11th Annual IEEE International
Requirements Engineering Conference (RE'03), Monterey Bay,

California, USA, September 8-12, 2003, pp 287-288.
 Berenbach, B. “Towards a Unified Model for Requirements
Engineering,” Fourth International Workshop on Adoption-Centric
Software Engineering (ACSE 2004), Edinburgh, Scotland, UK,
May 23-28, 2004, pp. 26-29.
 Carmel, E. and Agarwal, A., “Tactical Approaches for Alleviating
Distance in Global Software Development,” IEEE Software, vol.
18, no. 2, March/April 2001, pp. 22 - 29.
34
References (Contd.)
 Laplante, P., Costello, T., Singh, P., Bindiganavile, S. and

Landon, M., “The Who, What, Where, Why and When of IT

Outsourcing,” IT Professional, January/ February 2004, pp. 37
- 41.
 Sangwan, R., Neill, C., Laplante, P., Paulish, D. and Kuhn, W.,
“A Framework for Agile Development in Outsourced
Environments,” WSEAS Transactions on Computers, vol. 3,
no. 5, November 2004, pp. 1530-1537.
 Sangwan, R., Bass, M., Mullick, N., Paulish, D. Managing
Global Software Development, to be published by Auerbach,
Boca Raton, FL, 2006.
35
References (Contd.)
Open Source Software
Madey G., Freeh V., and Tynan R. “The open source software
development phenomenon: An analysis based on social network
theory,” Proceedings of the Americas Conference on Information

Systems (AMCIS2002), Dallas, TX, 2002, pp. 1806 – 1813.
Raymond, E. The Cathedral and the Bazaar: Musings on Linux and
Open Source by an Accidental Revolutionary, O’Reilly, 2001.
Scacchi, W. “Understanding Open Source Software Evolution”,
revised version to appear in N.H. Madhavji, M.M. Lehman, J.F. Ramil
and D. Perry (eds.), Software Evolution, John Wiley and Sons Inc,
New York, 2004.
36

Lecture 09-GSD

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Lecture 09-GSD

Загружено:

Авторское право:

Доступные форматы

SWENG 580: Advanced Software Engineering

Global Software Development

© Penn State University

There is also a growing interest in software products

What is global software development?

geographically distributed network of workflows;

Motivation for GSD

Challenges to GSD (Contd.)

 Distance exacerbates the problem of clearly and unambiguously

Challenges to GSD (Contd.)

Challenges to GSD (Contd.)

distributed projects for reasons such as

Challenges to GSD (Contd.)

 They must be engaged early in the inception and

Challenges to GSD (Contd.)

A process must be lightweight – it

Challenges to GSD (Contd.)

collocated not remote teams would be ideal

GSD Process (Sangwan et al, 2004, 2006)

 Actively manages risks

progressively refined from product features to system

Requirements Engineering (Contd.)

Requirements Engineering (Contd.)

Inception Elaboration Construction

 This yields an application architecture of loosely coupled and

synchronized by a central organization

Project Management (Contd.)

functionali feature-level requirements

Project Management (Contd.)

 Distributing a related set of activities is not prudent as it creates

Project Management (Contd.)

system requirements (SRS) and partitioned into

Project Management (Contd.)

 Acceptance tests are provided along with CRS to

Project Management (Contd.)

Project Management (Contd.)

of an executable product that is continuously built and tested,

Agility in GSD (Contd.)

requirements and design models

Open Source Software (OSS)

 Developers cooperate under a model of rigorous peer review

Range from small (< 5K SLOC) to very large (>

 Team critical mass of 5-15 core developers needed to sustain a

OSS Development Process (Scacchi, 2004)

CVS,System Build and Incremental Release

OSS Development Process (Contd.)

 Sharing, examining, modifying and redistributing

OSS Development Process (Contd.)

 Operates as a “dynamically organized but

OSS Development Process (Contd.)

 Berenbach, B.; “The automated extraction of requirements from

Requirements Engineering Conference (RE'03), Monterey Bay,

 Laplante, P., Costello, T., Singh, P., Bindiganavile, S. and

Landon, M., “The Who, What, Where, Why and When of IT

theory,” Proceedings of the Americas Conference on Information

Вам также может понравиться