|This paper is an attempt to understand the processes by which software ages. We de ne code to be aged or decayed if its structure makes it unnecessarily di cult to understand or change, and we measure the extent o f d ecay by counting the number of faults in code in a period of time. Using change management data from a very large, long-lived software system, we explore the extent to which measurements from the change history are successful in predicting the distribution over modules of these incidences of faults. In general, process measures based on the change history are more useful in predicting fault rates than product metrics of the code: for instance, the number of times code has been changed is a better indication of how many faults it will contain than is its length. We also compare the fault rates of code of various ages, nding that if a module is on the average a year older than an otherwise similar module, the older module will have roughly a third fewer faults. Our most successful model measures the fault potential of a module as the sum of contributions from all of the times the module has been changed, with large, recent changes receiving the most weight. Keywords| F ault potential, code decay, change management data, metrics, statistical analysis, generalized linear models.

AbstractÐA central feature of the evolution of large software systems is that changeÐwhich is necessary to add new functionality, accommodate new hardware, and repair faultsÐbecomes increasingly difficult over time. In this paper, we approach this phenomenon, which we term code decay, scientifically and statistically. We define code decay and propose a number of measurements (code decay indices) on software and on the organizations that produce it, that serve as symptoms, risk factors, and predictors of decay. Using an unusually rich data set (the fifteen-plus year change history of the millions of lines of software for a telephone switching system), we find mixed, but on the whole persuasive, statistical evidence of code decay, which is corroborated by developers of the code. Suggestive indications that perfective maintenance can retard code decay are also discussed.

Cracks in concrete generally interconnect flow paths and increase concrete permeability. The increase in concrete permeability due to the progression of cracks allows more water or aggressive chemical ions to penetrate into the concrete, facilitating deterioration. The present work studies the relationship between crack characteristics and concrete permeability. In this study, feedback controlled splitting tests are introduced to generate crack widthcontrolled concrete specimens. Sequential crack patterns with different crack widths are viewed under a microscope. The permeability of cracked concrete is evaluated by water permeability tests. The preliminary results indicate that crack openings generally accelerate water flow rate in concrete. When a specimen is loaded to have a crack opening displacement smaller than 50 microns prior to unloading, the crack opening has little effect on concrete permeability. When the crack opening displacement increases from 50 microns to about 200 microns, concrete permeability increases rapidly. After the crack opening displacement reaches 200 microns, the rate of water permeability increases steadily. The present research may provide insight into developing design criteria for a durable concrete and in predicting service life of a concrete structure.

Using the theory of random point processes, a method is presented whereby functional relationships between neurons can be detected and modeled. The method is based on a point process characterization involving stochastic intensities and an additive rate function model. Estimates are based on the maximum likelihood (ML) principle and asymptotic properties are examined in the absence of a stationarity assumption. An iterative algorithm that computes the ML estimates is presented. It is based on the expectation/maximization (EM) procedure of Dempster et al. (1977) and makes ML identification accessible to models requiring many parameters. Examples illustrating the use of the method are also presented. These examples are derived from simulations of simple neural systems that cannot be identified using correlation techniques. It is shown that the ML method correctly identifies each of these systems.

No abstract