Parallel Changes in Large-Scale Software Development: An Observational Case Study

1. Parallel Changes in Large-Scale Software Development: An Observational Case Study ACM Transactions on Software Engineering and Methodology, Vol. 10, No. 3, July 2001, Pages 308 – 337 Michelle ThomsonAgnieszka Jankowska Shiona Webster

2. Authors Strategy • The authors strategy for understanding the problem of parallel changes was to look at the problem from a number of different angles and viewpoints in the context of a large-scale, real-time system and a large-scale development.

3. Characteristics • An essential characteristic of large-scale software development is parallel development by a team of developers • How this development is structured and supported has a profound effect on both the quality and timeliness of the product

4. Why parallel development • Release preparation • Post-release maintenance (segregated from new development) • Tailored or customer-specific software • Segregation of work by different development teams or individuals • Segregation of work on different features • Deployment of different software variants into different environments

5. Issues Four essential problems in software development: • 1) evolution • 2) scale • 3) multiple dimensions of system organisation • 4) distribution of knowledge.

6. Evolution • Evolution compounds the problems of parallel development because not only is there parallel development within each version, but also among the releases as well

7. Scale • Scale compounds the problems by increasing the degree of parallel development and therefore increasing both the interactions and interdependencies among the developers

8. Multiple dimensions of system organisation • Multiple dimensions of system organisation compounds the problems by preventing tidy separations of development into independent work units • By System organisation, we are looking at hardware and software which make up the product and not the developers organisation

9. Distribution of Knowledge • Distribution of knowledge compounds the problem by decreasing the degree of awareness that is distributed

10. File checkin/checkout, branching and merging

11. Serial development using exclusive checkouts

12. Branching

13. Merging

14. Management of Parallel Changes • One of the standard features that enables developers to create parallel versions of the code is the branching mechanism • Every time a developer needs to create a new version of the code, they request the configuration management system (CMS) to create a new branch • The different versions of the code are then all stored in the same physical file

15. Benefit of CMS in parallel development

16. Classic vs. Modern Configuration Management Systems • In the classic configuration management system the merging process has to be done manually. There are no mechanisms to collapse branches back together • Modern configuration system provide mechanisms for automatically merging several versions back together

17. About ClearCase: A Software Configuration Management System (SCMS) originally fromRational Software (now IBM/Rational) http://www.timefold.com/snapsite/timefold/public/html/page41.html#q8http://www.ibm.com/software/rational

18. Levels of parallel development • 5ESS was maintained as a series of releases each offering new features on top of existing ones • Releases were being build in parallel with varying amount of overlapping development • Features were being developed in parallel (both with a simple release and multiple releases) * - Wikipidia.http://en.wikipedia.org/wiki/5ESS_switch

19. Two layer approach The 5ESS change management process Change management layer ECMS IMR Configuration management layer MR Deltas SCCS

20. Process of implementing an MR • Make private copy of file • Try out change • Retrieve original from SCCS – lock for editing • Makes changes [deltas] in the SCCS – release locks • Retrieve amended files again from SCCS for reading • Put code through inspection & testing • Submitted back for load integration • MR closed when changes made and approved • IMR is closed

21. IMR vs. MR activity

22. Lucent Technologies subsystem: 5ESS

23. Facts: Case study data found that: • The higher degree of parallelism the higher the number of defects! • 12.5% of all deltas are made to the same file by different developers within the same 24h period • Across the subsystems, 3% of the deltas made within 24h by different developers physically overlap each other’s changes.

24. Case study observations • The parallel development plays a vital role in large-scale software development • As study showed that the current tools (2001) available for the level or parallelism involved in large-scale development were inadequate • The number of defects was proportional to the level of parallelism

25. Team work • In parallel development team work plays a vital role to insure good integration of the system • Communication, effort and interaction need to be effectively organised and executed for parallel development effort to succeed • Team members need be aware of what other team members are doing and why

26. Workflow Organization Microsoft Solution Framework

27. It is not a question of how well each process works, the question is how well they all work together. Lloyd Dobens

28. References • Dewayne E. Perry et al. ACM Transactions on Software Engineering and Methodology, Vol. 10, No. 3, July 2001, Pages 308-337. • Brad Appleton, Stephen Berczuk, Ralph Cabrera, and Robert Orenstein. Permission is granted to copy for the PLoP '98 conference. 1998 • Tom Demarco, Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House. 1999 • Plastic SCM Platform Parallel Development. Pablo Santos Luaces. Codice Software. February 2007. www.codicesoftware.com • Context switching. http://codicesoftware.blogspot.com/2006/11/developer-contect-switching.html