Collaborative Software Engineering Especially in Disparate Geographical Environments | COMP 790, Study notes of Computer Science

Download Collaborative Software Engineering Especially in Disparate Geographical Environments | COMP 790 and more Study notes Computer Science in PDF only on Docsity! Collaborative Software Engineering Especially in Disparate Geographical Environments Philip Kelley 31 October 2006 Since the publication of The Mythical Man-Month by Brooks [1], academia and industry have been aware of the problem of how to enable efficient communication among members of a software development team. It is well acknowledged that in excess of 50 percent of each developer’s time may be taken up by the costs of collaboration during software development. This collaboration is a necessary part of the development process; without it the team could not move the product under development forward to completion in a successful fashion. Collaborative software tools have been developed to combat the communication problems which arise during software development. Some are more applicable to large (30+ people) development teams, but in general, the development and use of structured software development tools have been well received in industry and in the open source / free software community. Because of the time-saving effect of these tools and the impact they have upon collaboration, many, such as the version control system and the change management system, are now ubiquitous. The problems faced by a group of developers working to create software are hard enough when they are all co-located and can collaborate effectively face-to-face. The difficulty of collaborating effectively with coworkers increases when individual developers or groups of developers are isolated geographically. Herbsleb et al [2] studied a development project at Lucent Communications with two primary development sites and found that the introduction of geographic separation resulted in new problems for their software development process. The introduction of geographic separation caused the management in charge of the project to attempt to split the work logically based on the structure of the software development environment may make effective use of novel tools not yet widely in use in industry. The integration of these tools is of no small consequence. Increases in efficiency can be gained by integrating version control with change management, for example, so that sets of changes committed to version control are tagged with the change management items which they resolve. Policies may be put in effect for the checkin of changes to version control that require that all flaws pointed out by a static analysis tool be either corrected, or documented as to why they were not corrected. Effective use of policies and integration can have an immediate impact on the efficiency of a software development team. Workplace IM Workplace IM can play an important role in reducing the cost of starting a dialogue with another team member, by removing the requirement that a co-located developer visit that other team member’s office personally. In the case of geographically separated developers, the role of workplace IM is even more important, as it can complement the only other option, the telephone, which is often avoided in development teams such as those working on open source / free software. The interaction between developers using workplace IM is also better managed than when a developer has to interrupt another in their office. With an IM, the interruptee can multitask IM sessions, and delay their response if needed to preserve their train of thought. There are drawbacks, however: the interruptee can also completely ignore IM requests if he or she so chooses. The interrupter can also almost always get higher quality support from the interruptee by making an office visit, as the interruptee is then required, culturally, to answer the question. However, as a front-line tool in an ideal software development environment, workplace IM makes a significant contribution to streamlining collaboration. Version Control The use of the version control system in software development efforts is now taken for granted. Teams with more limited requirements can use freely available software, but those with more significant version control needs often have to purchase software from a vendor at great cost. In a geographically separated environment, it may make sense for teams to work on separate branches from a main trunk, at least until each piece of the system stabilizes somewhat. In this fashion, each team is insulated from breaking changes that the other team makes, increasing efficiency. This choice was made by the developers working on the Lucent project. However, these developers did not merge their changes back to the trunk at regular intervals and ensure that trunk builds maintained some minimum level of correct operation. In order to prevent divergence of the n (in this case two) private branches, integration and reverse integration at regular intervals is required, although it can be painful for both teams. Team 1 Private Branch Team 2 Private Branch TRUNK Reverse integrate (trunk->branch)Integrate (branch->trunk) Change Management A second important tool for collaborative software development is the change management system. In conjunction with the version control system, the change management system serves as a sort of log for all activity done on the project, as well as a mechanism for assignment of tasks to individual developers, testers, and management. With geographically isolated teams, it is important that all teams be using the same change management system, even if there is very little crossover between bugs from one team to the other. This was shown by Herbsleb, et al in their study of the Lucent project. Ideally, bugs entered into a change management system would follow one of a small set of idealized paths through the system, going from a reported bug to a closed bug that has been verified as fixed in a later build of the product, or from a reported bug to a closed bug that has been verified as not being a bug at all. Often bugs do not follow these paths. This can be due to complexity, resulting in discussion on how to solve the problem. This is productive. However, often bugs do not make it through the system as a result of social issues. Halverson, et al [3] at IBM Research studied change management on two public projects, Mozilla and Eclipse. In doing so they found social problems with change management, especially when developers were geographically separated from the bug reporter. They found it was easy for developers to ignore bugs, to assign bugs to another developer (perhaps one they did not know) in order to reduce their own bug count, and to claim that a particular issue was not a bug. This often resulted in multiple bugs for the developer hovers over a breakpoint in the Eclipse debugger. One group of developers was experienced with software development, but had never worked on Eclipse before. This group was given access to Hipikat. The second group had worked on Eclipse, but not on this particular component of the system. They were not given Hipikat. The developers of Hipikat found that while both groups of developers did fairly well in implementing the requested modification to the behavior of tooltips, the group that was given Hipikat to use performed slightly better. Cubranic, et al attributed this difference to an inheritance relationship between two classes, Breakpoint and JavaBreakpoint, which was made clear by the Hipikat software, but may have been overlooked by developers to whom the relationship was not easily discovered. The relationship between the two classes had an impact on the semantics of the solution. Conclusions Geographically separated software development is rapidly becoming commonplace in industry, as it has become in the open source community during the past ten years. While the number of teams working together remains small, significant problems do still arise when teams are geographically isolated. Figure 3. The Hipikat tool performing a search. Only some of these problems can be tackled by the use of collaborative software in an ideal software development environment. By reducing the amount of communication that must occur between software developers, and allowing the communication that is required to be managed more effectively, developers can work faster and with fewer obstacles in their path toward the final product. Unfortunately, the use of collaborative software and an ideal software development environment can only affect the time to complete a project by some small, constant factor. No order of magnitude gains have been realized or are likely to be realized in the future, according to Brooks [5]. References 1. Brooks, F.P., The Mythical Man-Month. Datamation, 1974. 2. Herbsleb, J. D. and Grinter, R. E. 1999. Splitting the organization and integrating the code: Conway's law revisited. In Proceedings of the 21st international Conference on Software Engineering (Los Angeles, California, United States, May 16 - 22, 1999). International Conference on Software Engineering. IEEE Computer Society Press, Los Alamitos, CA, 85-95. 3. Cubranic, D., Murphy, G. C., Singer, J., and Booth, K. S. 2004. Learning from project history: a case study for software development. In Proceedings of the 2004 ACM Conference on Computer Supported Cooperative Work (Chicago, Illinois, USA, November 06 - 10, 2004). CSCW '04. ACM Press, New York, NY, 82-91. 4. Halverson, C. A., Ellis, J.B., Danis, C., and Kellogg, W. A. 2006. Designing Task Visualizations to Support the Coordination of Work in Software Development. In Proceedings of the 2006 ACM Conference on Computer Supported Cooperative Work (Banff, Alberta, Canada, November 04 – 08, 2006). CSCW ’06. ACM Press, New York NY. 5. Brooks, F. P., "No Silver Bullet: Essence and Accidents of Software Engineering," Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.