software engineering csc640 848 fall 2009 global sw engineering organization and management n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Engineering CSc640/848 Fall 2009 Global SW Engineering – organization and management PowerPoint Presentation
Download Presentation
Software Engineering CSc640/848 Fall 2009 Global SW Engineering – organization and management

Loading in 2 Seconds...

play fullscreen
1 / 27

Software Engineering CSc640/848 Fall 2009 Global SW Engineering – organization and management - PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on

09/01/09. Software Engineering CSc640/848 Fall 2009 Global SW Engineering – organization and management. Prof. Dragutin Petkovic With help of S. Mahadev, former grad student at SFSU. Class plan.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Engineering CSc640/848 Fall 2009 Global SW Engineering – organization and management' - abena


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software engineering csc640 848 fall 2009 global sw engineering organization and management

09/01/09

Software EngineeringCSc640/848Fall 2009Global SW Engineering – organization and management

Prof. Dragutin Petkovic

With help of S. Mahadev, former grad student at SFSU

S. Mahadev, D. Petkovic

class plan
Class plan
  • Address issues related to global SW engineering: development of SW with teams that are geographically distributed (whether they are from the same company or not)
  • Organizational issues
  • Communication issues
  • Teamwork issues
  • Technical issues (I.e. how to architect the system so tasks can be done as independently as possible)
  • Tools to help
  • Suggestions for global and local groups in our class
  • Reading:
    • These slides (courtesy of SFSU Grad. Student Satish Mahadev who summarized the book below, pkus D. Petkovic’s edits)
    • “Global Software teams” by E. Carmel, Prentice Hall, 1999 (hard to get. The slides are sufficient)

S. Mahadev, D. Petkovic

slide3
Global Software Teams

Def: Global Software Teams are spread over the national borders while actively participating in the development of a system/software project

Nature of Global Software Teams

Global Software Teams posses a “utopian” social organization, in which individuals communicate and collaborate with each other across boundaries by sending trusted information among themselves.

This is not easy (even local teams have problems) so expect this, plan for this and deal with this

S. Mahadev, D. Petkovic

slide4
Factorsdriving Global Software Teams

Fifteen factors at different analysis levels are driving

the new form of global software development. The fifteen

factors are merged in to four main categories namely

A) Catalyst Factor

B) Sustaining Factor

C) Size Factor

D) Vision Factor

S. Mahadev, D. Petkovic

slide5
Catalyst Factors

1) Specialized talent:

Software companies want to deploy the best software designers and developers in the world regardless of their geographic location.

2) Acquisition:

Software Companies are filing gaps and expanding product families through acquisition.

3) Reduction in development cost:

Software Companies in high-wage nations like Japan and the United States are seeking low-wage countries like China, India and Mexico for getting their work done.

4) Globalized presence:

Software executives need to position their organization as a global firm recognizing themselves as global players.

5) Reduction in time-to market:

With different time zones, the ideal dispersed project can be productive round the clock.

6) Proximity to the customer:

Software development requires a great deal of interaction with the customers so the maxim of the best corporation, the best salespeople, and the best designers is to stay close to the customers.

S. Mahadev, D. Petkovic

slide6
B) Sustaining Factors

1) Development Rigor:

Distance drives greater formalisms.

2) Internal freshness:

Diversity brings new creativity and inspiration to the software organization.

3) Distance from distractions :

Distant units are far from the numerous distraction from the headquarters.

4) Professional cadre of software globalists:

5) Experience:

In most cases the remote sites have increased upon their experience curve and are performing well in software development.

S. Mahadev, D. Petkovic

slide7
C) Size Factor

1) Scale:

At some point of time co-located centers become too large and unwieldy to manage.

2) Evolving synergies of scale:

Scale brings about opportunities for global collaborations that are unanticipated.

  • Vision Factor

1) Location Transparency :

Eliminating the perception of distance through technology.

2) Virtual Organization :

Organizing entities from different organization around a structure resembling a network that has a weak hierarchy and a weak center.

S. Mahadev, D. Petkovic

slide8
The Five Centrifugal Forces of Global Software Teams

A Centrifugal force is a physical force that propels an object outward from the

Center.

The five centrifugal forces that pull apart (I.e. create obstacles) for the global software team are

A) Dispersion

B) Coordination Breakdown

C) Loss of Communication Richness

D) Loss of Teamness

S. Mahadev, D. Petkovic

slide9
Dispersion:

Co-location and dispersion are tied to the old-age continuum of centralization and decentralization of organization.

Centralization is the concentration of decision making at a single point in the organization.

Co-location has several disadvantages leading to inbreeding, groupthink, and other group pathologies

Development Managers concentrate on centralized organization for the following reasons:

1) Control

2) Less duplication of effort and wasted effort

3) Better ability to maintain a corporate culture

S. Mahadev, D. Petkovic

slide10
B) Coordination Breakdown

Coordination is the act of integrating each task and organizational unit so that it contributes to the overall objective.

Control is the process of adhering to goals or policies or standards.

Common mechanism of Coordination and Control are:

Structured and formal mechanism:

a) Departmentalization: shaping the form of the organization.

b) Employee selection: through hiring

c) Centralization of decision making: through the hierarchy of formal authority.

d) Standardization through written policies

e) Planning

f) Control through measures such as technical reports, sales reports, financial performance.

Informal mechanisms:

a) Lateral relations through direct contact.

b) Informal communication via personal contact, conferences and job rotation.

c) Socialization through organizational culture and team culture, shared values, training and reward system.

S. Mahadev, D. Petkovic

slide11
C) The Loss of Communication Richness

Humans prefer different kinds of communication transmission or different media for different kinds of task

Given a different development cycle stages, some task require richer communication than do others.

Customer contact should be face to face during requirement gathering and later during prototyping.

Designers need richer media to collaborate with one another during analysis and design phases.

With recent study dispersed software teams found that team members always wanted richer medium no matter what the task.

S. Mahadev, D. Petkovic

slide12
D) Loss of Teamness

A good team encompasses a set of benefits that is sedative to any organization.

a) It creates creative ideas and innovations.

b) It is better at objectively evaluating ideas and finding mistakes .

c) It provides greater access to expertise and experience

d) It enhances motivation and commitment to the task.

e) It has greater access to information.

Teams are of different types

a) Multifunctional:

Includes members that traditionally were in other organizational functions and roles.

b) Self-empowered:

Members make decisions about their own work.

c) Self-managed:

Members take over management tasks such as scheduling and performance.

d) High-performing:

Outperforms other teams.

S. Mahadev, D. Petkovic

slide13
Do Cultural differences affect software

Professionals?

What do you think?

a) No, there is essentially no cultural differences amongst software

Professionals. Engineer, like software professionals, place high value

on work and on achievement and relatively low value on social

Relationship.

OR

b) Yes, there is certainly little bit of cultural difference amongst software

professional. Software professionals are not attentive to explaining

events from cultural perspective, after a few probing questions,

cultural stories emerged and eventually accumulated.

S. Mahadev, D. Petkovic

slide14
The Six Centripetal Forces for Successful

Global Software Teams

The centripetal forces move objects toward the center, I.e. help. For global software teams they are:

  • Telecommunication Infrastructure
  • Collaborative Technology
  • Development Methodology
  • Managerial Techniques
  • Product Architecture
  • Team Building

They will help only if they are done appropriately

S. Mahadev, D. Petkovic

slide15
Architecture & Task Allocation – one technical activity critical for success

Product architecture determines whether dispersed sites can work with each other harmoniously. Three task allocation strategies are identified for designing a software component.

a) Module-based allocation, assigns task-modules to each site.

b) Phase based allocation, assigns which work is passed from site to site at the end of a major phase in the development process.

c) Integrated allocation, task re tightly integrated between sites and work is passed, as often as daily, between sites.

Product architecture are a necessity for managing complex projects performed by globally dispersed teams.

Proper product architecture is based in part on the principle of modularity. Modularity is one way to solve and allocate big complex tasks. Modular design reduces complexity and allows for easier parallel development.

S. Mahadev, D. Petkovic

slide16
Task allocation strategies

Three different allocating strategies are identified for allocating development tasks between sites

  • Module-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.
  • Phase- based allocation, site B performs the first phase (design) while site a performs the next phase (build) and so on. OR: development vs. QA
  • Integrated allocation takes place when (dispersed) sites work closely together, both across modules and across the development cycle.

Both module and phase task allocation strategies were common among the global software development projects developing packaged software of various categories.

According to one study, only 25% approached the extremes of either module-based or phase-based allocation and rest of the other projects used more complex task allocation: combining module with phase, module with integrative, phase with integrative; and two projects had properties of all three approaches-phase, module, and integrative.

S. Mahadev, D. Petkovic

slide17
Building The Dispersed Team Through

Trust, Communication, And Personal

Bridges

  • Building relationships means meeting face to face, shaking hands, sharing a drink, building trust.
  • Personal, face to face relationships are formed in kick-off meetings, milestones meetings celebratory meetings, and through bridges: the traveling manager, the short foreign assignments, the cultural liaisons, the expatriate assignments.

Building trust

  • A team whose members do not trust each other will not function effectively- or even fail miserably. Trust means placing confidence in another’s character, ability, strength, and reliability.

The Kick-off and other milestone meetings

  • The kick off meeting builds trust, builds team spirit, addresses some of the cultural differences, and also accelerates communication at the outset .

S. Mahadev, D. Petkovic

slide18
Communication
  • The global team must address two communication objectives simultaneously. First, it must move from traditional reliance on informal coordination ( and communication) to increased reliance on formal mechanisms. Second, it must encourage the informal communication across distance.

Lateral communication

  • Lateral communication means communication among team members across the organization rather than up and down the hierarchy. It is the lateral communication that creates effective integration of tasks and fully and quickly addresses task problem that crops up.

Everyone gets a 360° view

  • Each developer can view what people are doing above him, below him, and laterally, on both sides of him. This is called a 360° view. The 360° view is closely related to the notion of organizational transparency, which requires a clear definition of individual tasks, and group tasks.

Team communication protocols

  • Effective communication requires some protocols or rules. Team-wide communication protocols include response protocols, predictability, reliability and consistency which are important when a colleague can never be observed with one’s own eyes. Another application for communication protocols are conference calls that bring together different cultural meeting styles.

S. Mahadev, D. Petkovic

slide19
Specialized Management Techniques

Designing the team structure

The stage model of global software teams

Stage 1: One location

Stage 2: Central Coordination

HQ

HQ

S. Mahadev, D. Petkovic

slide20

HQ

Stage 3: Globally Integrated

A Generic team structure is based on several design principles.

  • First, it represents a balance between a centralized and a decentralized structure.
  • Second, some essential centralized roles are preserved, such as architecture, planning, budget, and standard setting.
  • Third, hierarchy is not discarded entirely: some internal decision-making hierarchy needs to remain: in the roles of the project manager, team leads, and so forth.
  • Fourth, the structure facilitates the all important intra-team communication and lateral communication.

S. Mahadev, D. Petkovic

slide21
Managing Conflict
  • Collaboration is a constant process of negotiation and problem resolution.
  • The first step in conflict management is to set the groundwork for future inevitable conflict. Identify a trusted third party within or outside the team who can be called in to resolve inter-site disputes.
  • Once a conflict does arise, the first law of conflict resolution is: Separate the people from the problem.
  • Software Engineering teamwork best practices suggest three-step process for handling inter-site disputes.
    • Try to solve the dispute between the team leads without involving the other team members.
    • If the dispute remains unresolved, informally explore the respective positions separately and then bring the team leads together.
    • The third step in handling inter-site disputes is to bring in an expert third party, a neutral, or a committee to resolve the dispute.

Similar three-step process will be implemented for CSC 640/848 global teams

S. Mahadev, D. Petkovic

research of profs petkovic thompson todtenhoefer huang
Research of Profs. Petkovic, Thompson, Todtenhoefer, Huang
  • Done in CSC 640/848 since 2004 base don objective and subjective measurements (this is why you fill out time cards and surveys)
  • Global and local student team in the class achieved about the same quality
  • Global teams spent more effort
  • Key impediments:
    • Time zone differences
    • Distance (lack of personal contact)
  • Grading of the class final project is taking into account this for global groups

S. Mahadev, D. Petkovic

suggestions and guidance for csc 640 848 teams
Suggestions and guidance for CSC 640/848 teams

(Note that even local groups for most of the time work on “distributed” or “global” fashion so this is also important for them)

  • Focus immediately on establishing good rapport and communication among team members. Use face to face if you can, phone/skype and share the photos and professional bios over the WWW
  • Use modern collaborative tools that keep records of the meetings
  • Team leads: summarize meetings (no more than a page) with tasks and milestones
  • Good project docs (requirements and design, specs, APIs) are essential
  • Follow up of all participants is a must
  • Establish some common meeting times
  • Task allocation: minimize global communications
  • Conflict resolution: try to do it yourselves, then if not working involve team leads, then if not working involve instructors
  • This is hard but also a great experience. Grading will be adjusted accordingly

S. Mahadev, D. Petkovic

summary
Summary
  • Catalysts for helping global SW teams happen
    • Specialized talent:
    • Acquisition:
    • Reduction in development cost:
    • Globalized presence:
    • Reduction in time-to market:
    • Scale
  • Impediments in successful managing of global teams
    • Dispersion
    • Coordination Breakdown (project management, technical decisions)
    • Loss of Communication Richness
    • Loss of Teamness
    • Culture

S. Mahadev, D. Petkovic

summary1
Summary
  • Issues that need utmost care:
    • High level project management, organization and coordination
    • Centralized decisions and coordination for key high level issues (i.e. requirements,specs, architecture)
    • Communication: teamwork, trust, written and verbal communication, conflict resolution
    • Culture
    • Tools: for communication, project management, SW development
    • Technical management:
      • Task allocation vs. modular architecture, well defined interfaces and functions etc.
      • Source control and management
      • QA and integration testing
      • Lower-level project management including risk management

S. Mahadev, D. Petkovic

references
References:
  • Global Software teams” by E. Carmel, Prentice Hall, 1999 (book)
  • Papers:
  • Yang, M.; Jin, Y.: “An Examination of Team Effectiveness in Distributed and co-located Engineering Teams.” Int. Journal of Eng. Education, Vol. 24, No 2, pp. 400-408, 2008.
  • Richardson, I., Moore, S.; Paulish, D., Casey, V., and Zage, D.:“Globalizing Software Development in the Local Classroom.” 20th Conference on Software Engineering Education & Training, pp.: 64 – 71, 2007.
  • Petkovic, D.; Thompson, G.; Todtenhoefer, R.: "Assessment and Comparison of Local and Global SW Engineering Practices in a Classroom Setting." Proceedings of the Thirteenth Annual Conference on Innovation and Technology in Computer Science Education, Madrid, Spain, June 2008.
  • Krishna, S.; Sahay, S,; Walsham G.; “Managing Cross-Cultural Issues in Global Software Outsourcing.” Comm. Of ACM, April 2004, Vol. 47, No. 4.
  • Herbsleb, J.; “Global Software Engineering: The Future of Socio-technical Coordination”, Future of Software Engineering FOSE’07,May 2007, pp 188-198
  • Herbsleb, J.; Mockus, A.; Finholt, T.; Grinter, R.: “An Empirical Study of Global Software Development: Distance and Speed”, Proceedings of the 23rd International Conference on Software Engineering, 2001,Toronto, Canada, pp 81-90.
  • Grimheden, M.; Van der Loos, H.F.M.; Chen, H.L.; Cannon, D.M.; Leifer, D.M., “Culture Coaching: A Model for Facilitating Globally Distributed Collaboration.” Proceedings of the 36th ASEE/IEEE Frontiers in Education Conference, Oct. 2006, San Diego, CA.

S. Mahadev, D. Petkovic

references1
References
  • Gopal, A.; Mukhopadhay, T.; Krishnan, M.: “The Role of Software Processes and Communication in Offshore Software development.” Comm. Of ACM, April 2002, Vol. 45, No. 4.
  • Gotel, O.; Scharff, C.; Seng, S.: “Preparing Computer Science Students for Global Software Development.” Proceedings of the 36th ASEE/IEEE Frontiers in Education Conference, Oct. 2006, San Diego, CA.
  • Gotel, O.; Kulkarni, V.; Phal, D.; Say, M.; Scharff, C.; Sunetnanta, T.: “Evolving an Infrastructure for Student Global Software Development Projects: Lessons for Industry.” Proceedings of the 2nd Annual Conference on India Software Engineering Conference, pp. 117-126, 2009.
  • Ebert, C.; De Neve, P.: “Surviving Global Software Development.” IEEE Software, Vol 18 (2), 2001, pp 62-69.
  • Keith Edwards, H.; Sridhar, V.: “Analysis of the Effectiveness of Global Virtual Teams in Software Engineering Projects.” Proceedings of the 36th Hawaii International Conference on System Sciences, 2003.

S. Mahadev, D. Petkovic