Experiences adopting an integrated gsd infrastructure

Abstract:

In this paper the author states how using only a particular tool and/or process is not much useful, Instead an augmenting set of tools and processes can be used and effect GSD in a positive manner.Tools in GSD toward integrated solutions that attempt to cover the full range of needs of distributed projects. The proper usage of tools will help in: Decoupling of work, give importance of unplanned and informal communication, ensure project management must be more flexible and more rigid. The various risk factors were studied by surrogating the project to student simulation teams. This paper describes the tools and processes developed, and insights gained from applying them to the GSP

Discussion:

The global Software Project (GSP) was split into two distinct years with a particular set of student teams being involved for one year. For the second year the infrastructure and processes were refined to address the issues experienced and lessons learned during the first year. Findings have been separated into themes that ended up being central in this project in one way or another. Set of finding were done to understand the issues of GSD concerned to centralized management, information and awareness, iterative development process, and balancing of formal and informal specialization.

A set of issues related to the findings were noticed during the the first year of software development, they were:

• Unclear process communication
• Inconsistent communication from the supplier manager
• Centralized Management and infrastructure problem
• Frequent re-planning required
• Interdependence of tasks not well understood
• Work assignment not easily understood
• Integration test were not easy to execute
• Issue with formal specification language like the UML diagram (issues like: different interpretations, machine friendly, etc..)

To tackle with those issues, a set of possible solutions were proposed int he second year of the GSP, they were:

• Maintain consistent communication with remote team by suing tools like MediaWiki
• The project should be transparent to all the people working on the project rather than specific to a individual person his module
• Keep a mandatory central version control than that of distributed version control system
• Put more upfront effort to better understand the needs and requirements of the project by using UI mockups, understanding the dependencies between different views
• Improved tools support by using Wiki updates, traceability matrix. It was observed no explanations were required after the first iteration
• Enable proper awareness to ensuring consistent understanding
• Maintain consistent communication
• Make every person of a team participate in the project
• Apart from UML specification, provide text based specification to the project.  

The paper was trying to summarize:

1. Try to introduce more informal communication techniques
2. Project management should be more flexible and rigid Eliminate the source of problem
3. Put more efforts in the early stages to avoid many problem like re-plan, re engineering, etc..
4. Make people more aware of the work and kind of work
5. Understand the technical and requirement bridge