Development methodology and Task Allocation

1
The Centripetal Forces for Successful Global
Software

• Development methodology and Task Allocation

2
Development Methodology

• The map that guide the team through the software
  development cycle
• Common language bridging developers at different
  sites.
• we do that during the alpha stage
• Terms and milestones are understood
• At a given, all developers know where their place
  is in the bigger picture
• It gives everyone a consistent set of expectations

3
Development Methodology

• It groups similar activities together
• It reduces redundant activates and excessive work
• It organizes activities into steps and phases
• It enhances quality by assuring that the
  activities are comprehensive and complete
• It reduces irrational activities
• And serve as effective documentation for
  management

4
Definitions

• Methodology
• Is a systematic approach to conducting at least
  one complete phase (e.g., design) of software
  production, consisting of a set of guidelines,
  activities, techniques, and tools, based on a
  particular philosophy of systems development and
  the target system.
• Process Model
• Is a representation of the sequence of stages
  (e.g., design, build, test) through which a
  software evolves. The term methodology is often
  used synonymously with process model

5
Development Methodology

• Why Process model are not used in many software
  companies
• Small development team
• Co-located
• Heroics
• Relying on end-of-cycle all-night work weeks
• Relying on few exceptional people, with
  exceptional abilities.
• Supper programmers
• The informal team mechanism for getting job done
  fall apart for GDSD

6
Development Methodology

• Two Fundamental Development Approaches
• Waterfall or linear or sequential model
• Prototyping or iterative model

7
Development Methodology

• Waterfall model
• Moves through a number of stages in sequence
• Each stage must be fully completed before moving
  to the next one.
• Stages
• Problem definition
• Analysis
• Design
• Code (implementation)
• Testing (black box, white box, integration then
  acceptance)
• Easier to manage
• Less hand offs and each hand off tends is more
  clearly defined

8
Development Methodology

• Prototyping
• Harder to manage but more effective
• Build successive iterations (or loops)

9
Example of process Model

• IBM JavaBeans Project
• Iterative
• Problem Statement Creation. A simple 1-2 line
  definition that can be initiated by any of the
  sites.
• Problem definition development. This stage was
  considered more difficult working from a loose
  idea to high level implementation, requiring
  iterations.
• Implementation (code). Usually a small unit of
  three to five people are involved.
• Acceptance. Addresses the following questions
  Does it function correctly? Is it packaged
  correctly? Is the documentation correct and
  complete?

10
Development Methodology

• Methodology is a cook book
• Can not be overly rigid
• Need to be flexible
• Changes with time (improvement)
• Off the shelf models from many sources

11
Development Methodology

• Methodological Clash
• When two software companies (teams) conduct a
  cross-border joint venture, whose development
  methodology should be used?
• Allowed methodological differences to continue
• Imposed the headquarters standard
• Choose the methodology of one of the partners

12
Summary Development Methodology

• Impose a development framework before development
  begins
• Educate all team members on the chosen
  methodologies
• Grow the methodology
• Continue to raise the methodological capacity
  level of the development team

13
Summary Development Methodology

• When cross-border sites are consolidated into a
  team, consider one of the three methodological
  strategies
• Forcing standardization
• Blending methodological components from the
  various sites into one new methodology
• Imposing high-level guidelines only
• Define and agree to terminology every day
• Define terms early and continue to define them as
  development progresses
• Continue to standardized terms (e.g. freeze,
  fixed, etc)

14

• Architecture Task Allocation

15
Architecture Task Allocation

• Product architecture determines whether dispersed
  sites can work harmoniously with each other
  without stepping on each others toes.
• Proper product architecture is based on the
  principle of modularity
• Modularity designing software components that
  are self-contained and have few interdependencies
  with other modules.
• Modularity design reduces complexity and allows
  for easier parallel development
• Components are designed in small granules,
  keeping each components interfaces to a
  manageable number.

16
Architecture Task Allocation

• Allocation of tasks
• The key success factor for most dispersed global
  teams is the clean allocation of tasks ensuring
  that each site has a significant task that relies
  as little as possible on other sites.
• Coordination overhead is reduced by minimizing
  the interdependency between sites
• The concept of modularity allowing a software
  program to be manageable intellectually is
  fundamental to computer science.

17
Architecture Task Allocation

• How should software be decomposed?
• Information hiding
• Is a design concept that calls for properly
  structuring the softwares modules such that the
  design logic is hidden from its user the
  programmer.
• Independence of modules can be measured
• By degree of Coupling
• Degree of interaction between modules
• Minimize coupling
• By degree of Cohesion
• Degree to which a module comprises a well-defined
  functional whole.
• Maximize cohesion

18
Architecture Task Allocation
High
Low
Good
Cohesion
Coupling
Bad
High
Low
Optimal modularization
19
Architecture Task Allocation

• Task Allocation Strategies
• Modular-based
• Phase-based
• Integrated (follow-the-sun)

20
Architecture Task Allocation

• Modular-based
• In modular-based allocation, site A and site B
  are each assigned one of two modules to develop
  from the beginning of the system development
  cycle to the end.

Site A Site B
Modular-based
t0
delivery
21
Architecture Task Allocation

• Phased-based
• This strategy is based on the standard stages, or
  phases, in the systems development cycle design,
  build, test.
• That is, site A performs the first phase
  (design), while site B performs the next phase
  (build) and so on.

Site A Site B
Phase-based
22
Architecture Task Allocation

• Integrated
• The integrated strategy works when (dispersed)
  sites work closely together, both across modules
  and across development cycle.
• Known as follow-the-sum in global software teams

Site A Site B
Integrated (follow-the-sun)
23
Architecture Task Allocation

• Weakness of the strategies
• The point of weakness of each of these task
  allocation schemes are in their coupling, that
  is, the transition, or hand-over, from site to
  site.
• Module-based allocations point of weakness
  occurs at the end of the cycle when the modules
  need to be integrated together.
• This happens during the first first build or
  during integration testing
• The phase-module point of weakness is in the
  hand-over from phase to phase.
• The integrated-module has hundreds of point of
  transactions and each one of them is a point of
  weakness.

24
Architecture Task Allocation
Site A Site B
Modular-based
t0
delivery
Site A Site B
Phase-based
Site A Site B
Integrated (follow-the-sun)
25
Architecture Task Allocation

• Success Factor for each task allocation
• Module-based
• Good architecture early on
• Minimize inter-dependencies between the modules.
• Phased-based
• Devote attention to transitioning (i.e., hand
  off).
• Establish relatively stable requirements or
  specifications.
• The specifications have to be well defined,
  comprehensive and accurate.
• Integrated
• Set up small granules of work and pair up
  individuals from distant sites to work with each
  other.
• Individual coordination of transition is simpler
  than passing work from group to group.

26
Architecture Task Allocation

• Inter-site task allocation criteria
• Knowledge
• Center of competence used to describe a
  concentration of technical or more often,
  application expertise
• Most centers of excellence built through
  experience
• Some companies build center of excellence from
  the ground up.
• Predetermined by acquisitions and are modular in
  nature
• Cost
• Emerging nations
• In most cases the allocation strategy is
  phase-based coding and testing and are allocated
  to distant sites
• Structure and Abstract

27
Architecture Task Allocation

• Intra-site Task Allocation
• Task assignment to individual developers at each
  site are best made by local team leads based on
  local norms
• Individualistic culture approach
• Who is doing what
• Collective culture approach
• Work together to meet the group goal

28
Architecture Task Allocation

• Changes in allocation over time Stage Model of
  global software teams
• Allocation is not static from project to project

Stage Model for global Software Teams
Stage 1 One Location
HQ
Stage 2 Central Coordination
HQ
Stage 3 Globally Integrated
HQ
29
Architecture Task Allocation

• Changes in allocation over time
• Stage Model of global software teams

Unstructured tasks
Ownership
Functional specs
High level design
Low level design
New Programming
Redesign/maintenance
Structured tasks
Time
Enhanced responsibility of remote site over time
30
(No Transcript)
31
Stages
Performing / Strategic Focus (Not just focusing
on cost)
5 4 3 2 1
Norming / Proactive Cost Focus (Beginning to form
norms and actively focusing and proactively using
outsourcing for cost saving including offshore.
Outsourcing 20-40 of IT activities)
Storming / Strategic decision point (Organization
leaders share conflicting ideas about outsourcing
and pursue different strategies to provide IT
services)
Forming / experimenting stage (outsourcing
between 10-20 of IT activities)
Insourcing / Bystander (outsourcing between 1-5
of IT. Mostly purchasing of IT functions).
Low
High
32
Offshore Outsourcing Readiness vs. Attractiveness
Offshore Readiness
Ready but not attractive
Ready and attractive
High
Not attractive and not ready
Attractive but not ready
Low
Offshore Attractiveness
Low
High
33
Architecture Task Allocation

• Best Practices
• Architect or re-architect your product before
  dispersing its development
• Success of GDSD depends on the architectural
  design in early stages of the development process
• Architecture has to be managed
• Set up architecture support in the form of an
  inter-site committee or assign someone to the
  task
• Modularize
• Build small, independent software components that
  are easily allocated across sites
• Anticipate the points of weakness of your task
  allocation strategy
• The hands off is the point of weakness
• Do not tightly task individuals at each site.
• Leave those responsibilities to local team leads.