A. Mockus, S. Eick, T. Graves, and A. Karr. On measurement and analysis of software changes, 1999. Home/Search Document Details and Download
Summary Related Articles Check |
This paper is cited in the following contexts:
A System for Graph-Based Visualization of the.. - Collberg.. (2003) (5 citations) (Correct)
....Software Real world software changes over time and software becomes better or worse because of the changes made to it. There are many tools available for analyzing such changes. These usually extract historical information stored by change management systems such as CVS and SCCS. SoftChange [20] is such tool that extracts complexity, size, purpose and author of changes made to a program and summarizes this information in textual web based reports. The authors note that to study software changes it was essential to handle large and complex data sets. The volume, complexity, and lack of ....
A. Mockus, S. Eick, T. Graves, and A. Karr. On measurement and analysis of software changes, 1999.
An Integrated Approach for Studying Architectural Evolution - Tu, Godfrey (2002) (5 citations) (Correct)
....history of a realworld software system, the GCC compiler suite, is used to demonstrate the effectiveness of our approach. 2 Challenges to Software Evolution Research Many studies on software evolution emphasize the statistical changes of the software system by analyzing its evolution metrics [15, 16, 8, 6, 20, 1, 9, 17, 4, 22]. Apart from some visualization tools [11, 13, 7] little work has been done to help understanding the nature of the evolution of software architecture. Performing a long ranging and detailed evolutionary case study of a software system presents several difficult technical problems. Some previous ....
A. Mockus, S. G. Eick, T. Graves, and A. F. Karr. On measurement and analysis of software changes. Technical report, Bell Labs, Lucent Technologies, 1999.
Identifying Productivity Drivers by Modeling Work Units.. - Todd Graves Audris (1999) Self-citation (Mockus Graves) (Correct)
....the observed monthly effort. Omitting some months will break up changes whose lifetimes span those months, making it impossible to define the total effort for such a change. 3. CHANGE DATA AND THEIR ANALYSIS Change history is a promising new tool for measuring and analyzing software evolution (Mockus et al., 1999). Change histories are automatically recorded by source code control and change management systems (see 3.1) Every change to every part of the source code is recorded by the change control system, providing a repository of software modifications which is large, detailed, and uniform over time. ....
....has tens of millions of lines of source code, and has been changed several hundred thousand times. The source code is mostly written in the C programming language, augmented by the Specification and Description Language (SDL) Tools used to process and analyze software change data are described in Mockus et al., 1999. The change management (CM) data include information on each change made to the code, its size and content, submission time, and developer. Also available are financial support system (FSS) data, which record amounts of effort spent each month by each developer. Because developers tend to work ....
[Article contains additional citation context not shown here]
A. Mockus, S. G. Eick, T. Graves, and A. F. Karr, "On measurement and analysis of software changes," tech. rep., Bell Labs, Lucent Technologies, 1999.
Does Code Decay? Assessing the Evidence from Change.. - Eick, Graves, Karr.. (1998) (1 citation) Self-citation (Mockus Eick Graves Karr) (Correct)
....More than 10,000 software developers have participated. We begin, in xII, with a brief discussion of the software change process and the change management data with which we work. The handling, exploration and visualization of these data are important issues in their own right, and are treated in [1]. In xIII, we propose a conceptual model for code decay: a unit of code (in most cases, a module) is decayed if it is harder to change than it should be, measured in terms of effort, interval and quality. Associated with the model is a compelling medical metaphor of software as patient, which ....
....these requirements, and at which levels of aggregation of changes, is shown in Table I. In this table, D indicates items directly in the database, while A denotes items obtained by aggregation over constituent software sub units. Elements denoted by D have problematic aspects discussed in [1]. 2 This preserves the capability to build earlier versions of the software. 102 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. XX, NO. Y, MONTH 1999 Time Date delta IMR Feature MR Description File, Module Developer #lines add. del. Fig. 1. Changes to the code (bold boxes) and associated data ....
A. Mockus, S. G. Eick, T. L. Graves, and A. F. Karr, "On measurement and analysis of software changes," Tech. Rep., National Institute of Statistical Sciences, 1999.
Goal-Oriented Software Assessment - Weiss, Bennett, Payseur, Tendick.. (2001) (Correct)
No context found.
Mockus, A., Eick, S.G., Graves,T. L., and Karr, A. F., "On Measurement and Analysis of Software Changes," Tech. Rep., National Institute of Statistical Sciences, 1999.
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