Development methodology and Task Allocation The Centripetal Forces for Successful Global Software.

Development methodology and Task Allocation

The Centripetal Forces for Successful Global Software

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

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


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”

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


Two Fundamental Development Approaches Waterfall or linear or sequential model

Prototyping or iterative model


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


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


Example of process Model

IBM JavaBeans Project Iterative1. Problem Statement Creation. A simple 1-2 line

definition that can be initiated by any of the sites.2. Problem definition development. This stage was

considered more difficult – working from a loose idea to high level implementation, requiring iterations.

3. Implementation (code). Usually a small unit of three to five people are involved.

4. Acceptance. Addresses the following questions: Does it function correctly? Is it packaged correctly? Is the documentation correct and complete?

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


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


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

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)

Summary: Development Methodology

Architecture & Task Allocation


Product architecture determines whether dispersed sites can work harmoniously with each other without stepping on each other’s 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 component’s interfaces to a manageable number.

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.



How should software be decomposed? Information hiding

Is a design concept that calls for properly structuring the software’s 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


Coupli n

g

Cohes i

on

High Low

Low High

Bad

Good

Optimal modularization

Task Allocation Strategies

Modular-based

Phase-based

Integrated (follow-the-sun)


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

t=0 delivery

Modular-based

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 BPhase-based

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 BIntegrated (follow-the-sun)

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 allocation’s 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.



Site A

Site BIntegrated (follow-the-sun)

Site A

Site BPhase-based

Site A

Site B

t=0 delivery

Modular-based

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.


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



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


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

HQStage 1One Location

Stage 2Central Coordination HQ

Stage 3Globally Integrated HQ

Stage Model for global Software Teams

Changes in allocation over time Stage Model of global software teams


Unstructured tasks

Structured tasks

TimeEnhanced responsibility of remote site over time

Redesign/maintenance

New Programming

Low level design

High level design

Functional specs

Ownership

Application Maturity ModelApplication Maturity Model

Level 1Level 1No No

ProjectsProjects

Level 2Level 2Staff Staff

AugmentationAugmentation

Customer Customer ManagedManaged

Customer Customer AccountableAccountable

-- Simple Simple ProjectsProjects

Level 3Level 3Staff Staff

AugmentationAugmentation

Customer Customer ManagedManaged


-- Non DiscreteNon Discrete

Level 5Level 5Project/SDLC Project/SDLC

BasedBased

CGEY CGEY ManagedManaged

Customer Customer (SME) (SME)

involvedinvolved

CGEY CGEY Accountable Accountable

-- DiscreteDiscrete

Level 4Level 4Project Project BasedBased


Customer Customer (PM) (PM)

oversight oversight


-- DiscreteDiscrete

Level 6Level 6App App

Mgmt/SDLC Mgmt/SDLC BasedBased



-- App App CentricCentric

Level 7Level 7App App

Mgmt/Full Mgmt/Full SDLC BasedSDLC Based



-- App App CentricCentric

Performing / Strategic Focus (Not just focusing

on cost)

High

Insourcing / Bystander (outsourcing between 1-5% of IT. Mostly purchasing of IT functions).

Forming / experimenting stage (outsourcing between 10-20% of IT activities)

Storming / Strategic decision point (Organization leaders share conflicting ideas about outsourcing and pursue different strategies to provide IT services)

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)

5

4

3

2

1

Stages

Low

Offshore Outsourcing Readiness vs. Attractiveness

High

Low

Offshore Readiness

Low HighOffshore Attractiveness

Ready but not attractive

Ready and attractive

Not attractive and not ready

Attractive but not ready

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.


Development methodology and Task Allocation The Centripetal Forces for Successful Global Software.

Documents

Transcript of Development methodology and Task Allocation The Centripetal Forces for Successful Global Software.