Metrics to understand future maintenance effort required of a complicated source code

An enduring engineering problem is the creation of a source code too complicated for humans to review and understand. A consequence of a complicated source code is that it requires more effort to be implemented and maintained. Exacerbating the problem is a lack of a proper understanding of exactly what the words “complicated” and “complex” mean, as the definitions of these words are often misconstrued. Some systems are indeed inherently complex, but this does not mean they must be complicated. In our research, several opensource projects were evaluated using software metrics to map the complicatedness of a source code with the ongoing effort to sustain the project. The results of our research show that a relationship exists between a complicated source code and the maintenance effort. It is clear that adhering to proper coding practices and avoiding a complicated code can result in a much more manageable future maintenance effort.Un problema de ingeniería duradero es la creación de código fuente demasiado complicado para que los humanos lo revisen y comprendan. Una consecuencia del código fuente complicado es que requiere más esfuerzo para implementar y mantener. Lo que exacerba el problema es la falta de una comprensión adecuada de lo que significan exactamente las palabras “complicado” y “complejo”, ya que estas definiciones a menudo se interpretan mal. Algunos sistemas son realmente intrínsecamente complejos, pero esto no significa que deban ser complicados. En nuestra investigación, se evaluaron varios proyectos de código abierto utilizando métricas de software para mapear la complejidad del código fuente con el esfuerzo continuo para mantener el proyecto. Los resultados de nuestra investigación muestran que existe una relación entre el código fuente complicado y el esfuerzo de mantenimiento. Está claro que adherirse a las prácticas de codificación adecuadas y evitar el código complicado puede resultar en un esfuerzo de mantenimiento futuro mucho más manejable

Estimating worst case failure dependency with partial knowledge of the difficulty function

For systems using software diversity, well-established theories show that the expected probability of failure on demand (pfd) for two diverse program versions failing together will generally differ from what it would be if they failed independently. This is explained in terms of a “difficulty function” that varies between demands on the system. This theory gives insight, but no specific prediction unless we have some means to quantify the difficulty function. This paper presents a theory leading to a worst case measure of “average failure dependency” between diverse software, given only partial knowledge of the difficulty function. It also discusses the possibility of estimating the model parameters, with one approach based on an empirical analysis of previous systems implemented as logic networks, to support pre-development estimates of expected gain from diversity. The approach is illustrated using a realistic safety system example

A Second Replicated Quantitative Analysis of Fault Distributions in Complex Software Systems

Background. Software engineering is in search for general principles that apply across contexts, for example to help guide software quality assurance. Fenton and Ohlsson presented such observations on fault distributions, which have been replicated once. Objectives.We intend to replicate their study a second time in a new environment. Method.We conducted a close replication, collecting defect data from five consecutive releases of a large software system in the telecommunications domain, and conducted the same analysis as in the original study. Results. The replication confirms results on un-evenly distributed faults over modules, and that fault proneness distribution persist over test phases. Size measures are not useful as predictors of fault proneness, while fault densities are of the same order of magnitude across releases and contexts. Conclusions. This replication confirms that the un-even distribution of defects motivates un-even distribution of quality assurance efforts, although predictors for such distribution of efforts are not sufficiently precise

Geodynamics Branch research report, 1982

The research program of the Geodynamics Branch is summarized. The research activities cover a broad spectrum of geoscience disciplines including space geodesy, geopotential field modeling, tectonophysics, and dynamic oceanography. The NASA programs which are supported by the work described include the Geodynamics and Ocean Programs, the Crustal Dynamics Project, the proposed Ocean Topography Experiment (TOPEX) and Geopotential Research Mission. The individual papers are grouped into chapters on Crustal Movements, Global Earth Dynamics, Gravity Field Model Development, Sea Surface Topography, and Advanced Studies

Reliability improvement project decision making : water cooling system redesign

Thesis (S.M.)--Massachusetts Institute of Technology, System Design and Management Program, June 2006.Includes bibliographical references (p. 66).Deciding on which reliability & performance improvement projects to launch or to reject has historically been an extremely challenging responsibility of Teradyne management. Incorrect decisions can lead to major customer dissatisfaction, which may subsequently lead to loss of market share. Teradyne Engineering and Marketing team have been trying to develop a tool that would assist in their reliability improvement project decision making. The challenge is the dynamic aspects of the reliability improvement projects. Like most engineering projects, reliability improvement projects have variables such as internal workforce, productivity, skill sets, customer expectations and many others that are in constant motion. These variables make the assessment of reliability projects extremely difficult in a static framework. This research will incorporate these key variables into a dynamic framework to help assess individual reliability improvement projects.by Paul Devine.S.M