D.E. Perry, H.P. Siy, and L.G. Votta, Parallel Changes in Large-Scale Software Development: An Observational Case Study. ACM Transactions on Software Engineering and Methodology, 2001. 10(3): p. 308-337.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....system is to coordinate access to a common set of artifacts by multiple developers who are all working on the same project. While ideally project management assigns the developers tasks that are mutually exclusive, the reality is that changes made by one developer regularly affect another s work [21,22,31]. The various approaches that different configuration management systems take to address this situation can be distinguished into two classes: pessimistic and optimistic. In the pessimistic approach, a developer must lock artifacts before making any modifications. Such a lock prevents other ....

....isolation by automatically coordinating the activities of individual developers. In reality, however, the ideal case cannot be enforced. More often than not the illusion of workspace isolation vanishes when complex direct or indirect conflicts arise that the automated procedures cannot handle [21,22,31]. Table 1. Different coordination mechanisms. Coordination mechanism Direct conflicts Indirect conflicts Pessimistic Locking before changes are made Avoided, at the expense of project delays Not addressed Optimistic Automated merging after changes are made Resolved, ....

[Article contains additional citation context not shown here]

D.E. Perry, H.P. Siy, and L.G. Votta, Parallel Changes in Large-Scale Software Development: An Observational Case Study. ACM Transactions on Software Engineering and Methodology, 2001. 10(3): p. 308-337.

.... SoftChange were instrumental in studying the interdependencies of software development and the organizational structure in legacy organizations [7] Change properties can also be used to quantify increases in fault incidence due to past changes [8] or the increased complexity of parallel changes [9]. SoftChange includes methodology for reliably inferring the purpose of changes [10] and an iterative algorithm described in [11] 12] for identifying factors that affect the effort required for individual changes. The presence of SoftChange has made it quite straightforward to perform analyses ....

D.E. Perry, H. P. Siy, and L. G. Votta, "Parallel changes in large scale software development: An observational case study," in Proceedings of the 1998.

....such that the number of conflicts resulting from parallel change is reduced. By providing capabilities that either avoid parallel development altogether (e.g. locking) or assist in resolving conflicts (e.g. merging) these systems certainly have succeeded in reducing the number of conflicts [3]. Nonetheless, merge conflicts do occur and often must be manually resolved, a time consuming and sometimes difficult task. Furthermore, the issue of indirect conflicts remains unaddressed by CM systems [4] At best, they provide a historical trace of changes. While useful in identifying what ....

Perry, D.E., H.P. Siy, and L.G. Votta. Parallel Changes in Large Scale Software Development: An Observational Case Study. in Proceedings of the 1998.

....in EDS Italia: one involving several different geographical sites and the other a single site belonging to the same company. Data are analyzed to show the impact of distributed projects over scheduling of the activities, their subdivision and the degree of synchronization achieved, as described in [PV98]. Furthermore, communication among team members is analyzed analogously to [PSV94] as also we look for evidence of higher cost overheads in distributed processes due to practical limitations of this communication. The paper is organized as follows: section 2 presents the projects and the metrics ....

D.E. Perry, L.G. Votta, Parallel Changes in Large Scale Software Development: An Observational Case Study , Proc. Intl. Conf. on Software Engineering, 1998, pp. 251-260.

.... SoftChange were instrumental in studying the interdependencies of software development and the organizational structure in legacy organizations [7] Change properties can also be used to quantify increases in fault incidence due to past changes [8] or the increased complexity of parallel changes [9]. SoftChange includes methodology for reliably inferring the purpose of changes [10] and an iterative algorithm described in [11] 12] for identifying factors that affect the effort required for individual changes. The presence of SoftChange has made it quite straightforward to perform analyses ....

D. E. Perry, H. P. Siy, and L. G. Votta, "Parallel changes in large scale software development: An observational case study," in Proceedings of the 1998 International Conference on Software Engineering, Kyoto, Japan, April 1998. MOCKUS, EICK, GRAVES, AND KARR, : ON MEASUREMENT AND ANALYSIS OF SOFTWARE CHANGES 19

....or solve a problem are sent to the development organization as Initial Modification Requests (IMRs) implementation of a feature typically requires hundreds of IMRs. The supervisor responsible for the IMR distributes the work to the developers. Developers implementing parallel changes (as in [15]) must wait for unavailable files. Each IMR generates a number of Modification Requests (MRs) which contain information representing the work to be done to each module. Thus, an IMR is a problem, while an associated MR is all or part of the solution to the problem. To perform the changes, a ....

....produce frustration and sloppy work. 7. Programmer variability, for example, programmers who cannot understand or change delicate, complex code written by their more skilled colleagues. 8. Inadequate change processes, such as lack of a version control system or inability to handle parallel changes [15]. This cause is particularly pertinent to today s world of Web distribution of open source software. Bad project management may amplify the effects of any of these causes. C. Symptoms of Code Decay In our conceptual model, symptoms are measurable manifestations of decay, in the same way that ....

D. E. Perry, H. P. Siy, and L. G. Votta, "Parallel changes in large scale software development: An observational case study," in Proceedings of the 1998 International Conference on Software Engineering, Kyoto, Japan, April 1998. EICK, GRAVES, KARR, MARRON, AND MOCKUS: DOES CODE DECAY? 111

....in connecting local and long distance calls involving voice, data, and video communications. The software to run the switch is more than 10 million lines of code, divided into 50 subsystems, and involves more than 3,000 developers. The degree of parallel work going on is at an unprecedented level [4]. Moreover, the globalization of the telecommunications market has led to a diverse international customer set who have different requirements due to different telecommunication policies, maturity of telecommunications infrastructure, unwillingness to replace expensive legacy hardware, etc. With ....

....unit testing. 5. Submit the MR for load integration and feature and regression test. There are several observations. At any given time, there may be multiple private copies of a file being edited by different developers. In fact, some files may be involved in more than 10 active MRs at one time [4], each with its own private copy of the file. Unless the developers are aware of each others work, the changes being made by other developers are not visible until these developers submit their MRs for integration. It is hoped that any conflicts are caught during load integration and feature and ....

Dewayne Perry, Harvey Siy, and Lawrence Votta. Parallel changes in large scale software development: An observational case study. In Proceedings of the 1998 International Conference on Software Engineering, Kyoto, Japan, April 1998.

....is further compounded by such considerations as 13 specialization, optioning and portability. I note in passing that the occurrence of multiple dimensions of organization is a general problem, not one endemic to switching systems. In a study about parallel changes in a subsystem of 5ESS [22], Perry, Siy and Votta found that 83 of the features implemented in that subsystem required changes to more than one file. Indeed, 25 of the features required changes to 2 to 5 files, 25 of the features required changes to 6 to 20 files, and 33 of the files required changes to more than 20 ....

Dewayne E. Perry, Harvey P. Siy and Lawrence G. Votta. "Parallel Changes in Large Scale Software Development: An Observational Case Study", submitted for publication.

No context found.

D.E. Perry, H.P. Siy, and L.G. Votta, Parallel Changes in Large-Scale Software Development: An Observational Case Study. ACM Transactions on Software Engineering and Methodology, 2001. 10(3): p. 308-337.

No context found.

Perry, D.E., H.P. Siy, and L.G. Votta, Parallel Changes in Large-Scale Software Development: An Observational Case Study. ACM Transactions on Software Engineering and Methodology, 2001. 10(3): p. 308-337.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC