Collaborative Software Engineering Especially in Disparate Geographical Environments - PowerPoint PPT Presentation

Loading...

PPT – Collaborative Software Engineering Especially in Disparate Geographical Environments PowerPoint presentation | free to download - id: 6ec4bf-YmJkY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Collaborative Software Engineering Especially in Disparate Geographical Environments

Description:

Collaborative Software Engineering Especially in Disparate Geographical Environments Philip Kelley – PowerPoint PPT presentation

Number of Views:42
Avg rating:3.0/5.0
Slides: 23
Provided by: Phili378
Learn more at: http://www.cs.unc.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Collaborative Software Engineering Especially in Disparate Geographical Environments


1
Collaborative Software Engineering Especially in
Disparate Geographical Environments
  • Philip Kelley

2
Software Engineering
  • More than 1 person ? collaborative effort
  • F.P. Brooks Mythical Man Month, No Silver Bullet
  • Can even be hard to coordinate 2 people
  • Moving to geographically isolated teams
    aggravates the problem

More collaboration
3
In Disparate Locations
  • gt 2 isolated engineering teams of gt1 people
  • Open source team size of 1 is common
  • Inter-team collaboration limited to software
    tools and the telephone
  • Time zones, workday overlap

4
In Disparate Locations
  • Herbsleb, et. al. (Bell Labs) studied a
    development project at Lucent with 2 primary
    sites.
  • A lot of things went wrong on the project
  • Components built at multiple sites did not work
    together
  • Collaboration did not just have to occur between
    the 2 primary sites
  • The teams depended on substrate components
    developed at many other sites

5
What went wrong?
  • Site teams tried to work on unrelated parts of
    the project
  • This was a good idea
  • But, assumptions were made by each of the sites
    about the semantics of the interfaces between
    components.
  • Even the unit tests at each site made these
    assumptions
  • Each team was certain their component was
    semantically correct, but the documentation was
    just inadequate

6
What went wrong?
  • Different change management systems were used at
    different sites
  • This enabled rapid progress early in the
    development cycle
  • But during the integration phase, when things
    didnt work, this caused trouble
  • Bug fixes, etc. had to be replicated in both
    tracking systems, wasting a lot of time

7
What went wrong?
  • Can these issues be addressed by collaborative
    software?
  • Easier ones identified by Herbsleb, et al
  • The high cost of initiating contact
  • Integrated development environment, i.e. same
    version control repository, same change
    management system
  • Hard ones identified
  • Cultural differences between teams
  • Trust issues between teams
  • Lack of unplanned contact with other team members
  • Time zones!

8
Ideal Software Engineering Environment
  • Obvious goal Reduce the percentage of developer
    time spent on coordination of efforts with others
  • Many tools already exist
  • Version control - Change management
  • Automated build - Workplace messaging
  • Static analysis
  • An ideal environment would have all these
    integrated together
  • Can roll your own, developing procedures to
    integrate pieces together
  • Visual Studio Team System from MS is an option

9
Ideal Software Engineering Environment
  • In addition to the standard toolbox there are
    some novel ideas for software development tools
    which we will look at
  • Two ways for tools to work
  • Manage the interaction between developers better
  • Reduce the required interaction between developers

Reduce interaction
Manage interaction better.
10
Workplace IM (and IRC)
  • Versus actually visiting someones office.
    Incredibly important with geographically
    separated teams.
  • Reduce required interaction
  • By reducing cost of contacting another
    individual. Dont have to get up (or fly to
    another country!)
  • Manage interaction better
  • Interruptee can multitask IM sessions, and delay
    response if needed to preserve his/her train of
    thought, etc.
  • Drawbacks
  • Interruptee can completely ignore IMs
  • Interrupter can get higher-quality support from
    the interruptee by walking into the interruptees
    office

11
Version Control
  • A (partially) disconnected filesystem
  • Advantages are better realized when coupled with
    the change management system

12
Version Control
  • In the case of geographically separated teams,
    the same version control system should be used
    for both sites.
  • But, each team could work out of a separate
    branch, and merge changes at regular intervals.
  • This provides insulation from breaking changes on
    the other end, but prevents divergence of the
    branches from becoming irreparable.

TRUNK
Reverse integrate (trunk-gtbranch)
Integrate (branch-gttrunk)
Team 1 Private Branch
Team 2 Private Branch
13
Change Management
  • A system for tracking requests for changes in the
    software being built
  • The same system and database should be used for
    all sites
  • Ideally, version control should be integrated
    with change management.

These screen shots are from Visual Studio Team
System. I have seen other solutions, however,
using Perforce and other change management
systems. Integration capability is a main selling
point of all these tools because the advantage is
well understood, but only in the past few years.
14
Social Issues with Change Management
  • Halverson, et al. (IBM Research) did a study of
    change management in two public projects, Mozilla
    and Eclipse
  • They found social problems with change management
    when developers were separated geographically
    from the bug reporter.
  • It is easy to ignore bugs
  • It is easy to reassign bugs to another developer
    to reduce the number of bugs on ones own plate
  • It is easy to claim an issue is not a bug
  • This is a situation where the goal is not to
    reduce the amount of required interaction, but to
    manage it more effectively. Management should be
    made aware of these sorts of social problems when
    they occur on their software development teams!

15
Halverson, et. al. (IBM Research)
The novel solution presented was better
visualization of change management data. When a
bug is deep orange, it is open and assigned. Look
how many times bug 1 has been opened and
reassigned! This is something management can
easily see when looking at a bug database.
Problem bug and problem developers can be
identified.
This applies to geographically separated
teams even more because problem bugs happen
more often when developers dont know each other.
16
Halverson, et. al. (IBM Research)
  • Bugs have priority values but also have a heat
    value that is based on age of the bug as well as
    other factors
  • Easy to spot bugs which are standouts due to high
    heat value.

17
Leveraging Integration in our Ideal Software
Development Environment
  • Enforcement of policies for the use of available
    tools
  • Ex. Cannot check in a changeset that does not fix
    a bug, if the time until release of the product
    is near
  • Ex. Cannot check in a changeset without running
    static analysis tools on the code
  • Can also use the version control system and
    change management system together as a source of
    data to be mined

18
Querying the Database
  • Cubranic, et al. U. of B.C., CSCW 2004
  • Hipikat is a tool for querying work item
    tracking, version control, and source code
    indices for a string
  • Hipikat returns nuggets of information, such as a
    previous change request, or a piece of source
    code with comments that match the string. Each
    nugget has a confidence value
  • Hipikat understands the inheritance structure of
    classes used in an object-oriented program, and
    uses this information to aid in its suggestions

19
Querying the Database
  • Cubranic et al. believed that questions could be
    answered by project history, as represented by
    this database
  • With similar effectiveness to asking a colleague
    for help
  • This strategy reduces required interaction
    between developers, and especially helps with
    geographically separated sites, where the cost of
    contacting another developer is high

20
Querying the Database
  • Two groups of people were asked to add
    functionality to Java breakpoint tooltips in the
    Eclipse debugger.
  • Group 1 Had Hipikat. Experienced programmers who
    had never worked on Eclipse.
  • Group 2 Did not have Hipikat. Experienced
    Eclipse programmers that had never worked on
    tooltips

21
Querying the Database
  • The experimental results?
  • Both groups did fairly well.
  • The non-Eclipse programmers did a little better.
    Why? Because Hipikat provided them with an
    inheritance picture that showed how a parent
    class was also involved in the correctness of the
    solution.
  • So, integration and use of past knowledge helps
  • Can reduce the number of times one has to ask for
    help, especially for new developers to a team
  • In some cases, can even go beyond what one would
    get by asking a friend, as in the example where
    Hipikat helped developers to understand the
    superclass involvement.

Breakpoint
is-a
JavaBreakpoint
22
Conclusions
  • Geographically separated software development
  • Is the future
  • Is already here
  • Many problems arise with geographically separated
    software development
  • Only some can be easily addressed by
    collaborative tools in an ideal software
    development environment
  • Two main strategies for tackling the problems
  • Reduce the amount of interaction between
    developers
  • Better manage the interaction between developers
  • In any case we are only reducing software
    development headaches by a constant factor
  • No silver bullet (Brooks)
About PowerShow.com