Upload
topper
View
28
Download
0
Embed Size (px)
DESCRIPTION
The Centripetal Forces for Successful Global Software. Development methodology and Task Allocation. 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” - PowerPoint PPT Presentation
Citation preview
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
Development Methodology
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
Development Methodology
Two Fundamental Development Approaches Waterfall or linear or sequential model
Prototyping or iterative model
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
Development Methodology
Prototyping Harder to manage but more effective Build successive iterations (or loops)
Development Methodology
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
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
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
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
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.
Architecture & Task Allocation
Architecture & Task Allocation
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
Architecture & Task Allocation
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)
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.
Architecture & Task Allocation
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.
Architecture & Task Allocation
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
Architecture & Task Allocation
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.
Architecture & Task Allocation
Architecture & Task Allocation
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.
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
Architecture & Task Allocation
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
Architecture & Task Allocation
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
Architecture & Task Allocation
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
Customer Customer AccountableAccountable
-- 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
CGEY CGEY ManagedManaged
Customer Customer (PM) (PM)
oversight oversight
Customer Customer AccountableAccountable
-- DiscreteDiscrete
Level 6Level 6App App
Mgmt/SDLC Mgmt/SDLC BasedBased
CGEY CGEY ManagedManaged
CGEY CGEY Accountable Accountable
-- App App CentricCentric
Level 7Level 7App App
Mgmt/Full Mgmt/Full SDLC BasedSDLC Based
CGEY CGEY ManagedManaged
CGEY CGEY Accountable Accountable
-- 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.
Architecture & Task Allocation