Software errors and complexity: an empirical investigation0
Communications of the ACM
A rational design process: How and why to fake it
IEEE Transactions on Software Engineering
A history of software maintenance for a complex U.S. Army Battlefield automated system
The Institute of Electrical and Electronics Engineers, Inc on Conference on software maintenance--1985
Design activity in developing modules for complex software
Papers presented at the first workshop on empirical studies of programmers on Empirical studies of programmers
Characteristics of application software maintenance
Communications of the ACM
On the criteria to be used in decomposing systems into modules
Communications of the ACM
Software Engineering Economics
Software Engineering Economics
ICSE '76 Proceedings of the 2nd international conference on Software engineering
Types, distribution, and test and correction times for programming errors
Proceedings of the international conference on Reliable software
The Detection of Fault-Prone Programs
IEEE Transactions on Software Engineering
Cost-Effective Analysis of In-Place Software Processes
IEEE Transactions on Software Engineering
Software process validation: quantitatively measuring the correspondence of a process to a model
ACM Transactions on Software Engineering and Methodology (TOSEM)
| Hi-index | 0.00 |
An analysis is presented of early design and code change data from the software cost reduction (SCR) project, a well-reported effort conducted at the US Naval Research Laboratory from 1978 to 1988. The analyses are mostly time-based studies of the change data and relationships between the data and SCR personnel activity data. Some analyses of the change data show patterns consistent with a major goal of the SCR project: the design and development of easy-to-change software. Specifically, most changes took a day or less to uncover and resolve; the majority of changes updated at most one module. Moreover, these percentages remained fairly stable. No positive relationship appeared between error-correction effort and the number of days that an error remained in the SCR design documentation. Other analyses suggest that consistency may have been temporary. For example, the analyses suggest a stepwise growth in average change effort, and an increasing percentage of changes resulted in module interface updates. Certain specific ratios between SCR change data and personnel activity data may be possible indicators of design incompleteness.