1. Parallel Changes in Large-Scale Software Development: An Observational Case Study DEWAYNE E. PERRY University of Texas at Austin HARVEY P. SIY Lucent Technologies and LAWRENCE G. VOTTA Motorola, Inc.
Greg Holifield

2. Four Essential Problems in Software Development: [Brooks 1987]
Evolution
not only have parallel development within each release,
Among releases as well.
Scale
Multiple dimensions of system organization 1[Perry 1996]
Distribution of knowledge

3. Authors’ Three Goals
provide a basic understanding of the parallel-change phenomena
begin an investigation of a subproblem: interfering changes
explore the relationship between parallel changes and the related quality data
Three Hypothesis of Relationship between Parallel Changes and Quality
Interfering changes are more likely to result in quality problems later in the development than noninterfering changes.
Files with significant degrees of parallel changes are likely candidates for code that “decays” overtime. The degree of interference increases this likelihood.
Current technology supporting the management of these problems addresses only superficial aspects of these problems.

4. Methods Toward Each Goal
basic observational data on the nature of parallel changes
Examine prima facie cases
changes to changes
changes within the same day
summarize available tools that support parallel development

5. Classical Tools Library-type Systems (check in/out) Newer Systems
SCCS [Rochkind 1975]
RCS [Tichy 1982],
Newer Systems
Rational’s ClearCase(R) [Leblang 1994]
Adele Configuration Manager [Estublier and Casallas 1994]
Traditional Systems
Various Branches one file on developer per file
“Newer” Systems
allow developers to work in parallel on the same file

6. Classical Tools Integration of Parallel Changes Semantic Conflicts
permanent versions
temporary versions
Semantic Conflicts
Logical Completeness
Permanent versions are “branches in the product develop-ment
path that have their own life cycle” [Mahler 1994].
Temporary problem figuring out how to merge the multiple versions back into a coherent single version

16. Conclusion —There are multiple levels of parallel development.
—The activities within each of these levels cut across common files.
—Over the interval of a particular release (I6), the number of files changed by multiple MRs is 60%
—though we would expect the degree of awareness of the implications of these changes to be higher than those made within one day of each other
—There is a significant correlation between files with a high degree of parallel development and the number of defects