An empirical study of software design practices

David N. Card, Victor E. Church, William W. Agresti
1986 IEEE Transactions on Software Engineering  
Absmmi-Siftware rnginccrr have dwrlopcd a large hdv (if d t -vidual modules were consistent with the Dumorted hene-* . ware desiyn t h w y and LJkkire. much id which has nevrr I w n vulidated. This paper repirts the results of an empirical rtudy of wiltware desiyn practices in ime specific rnvirtmmml. l h r practices examinrd sisc, mcduk strrnyth, data cou~iny, dewendant upan. unrcfercnced variahks, and wiftwarc reuv. >lrawres charwtrristic of fits of [he design practices, ~l~h~)~~h [he term
more » ... iOdule" can refer to a more elaborate structure I I I. as used in this paper it equates to a Fortran "subroutine" consistent with the Structured Design of Stevens ef d . 13 I. The these practice% werc ealractrd frtm 887 Viwtrua m i d u b devehprd ftw five f l i h t dynamkr software priijects mimitcved hy the Siftware Engincering Lahcwatiwy. The relatitmship of these meowrev 111 ctwt and fault rate was analyzed using a cimtinyrncv tahk prirrdurr. The resulls shw that wme rectnnmended design practkes, despite their intuitive appeal, are ineffective in this envircmment. whereas others are authors selected three sanlples of Fortran niodules from the Software ~~~,~ ~~b~~~~~~ (SEL) database for study. Sl'ffH'NM Etlgi!lterhg k~horurory very effective. The SEL is a research project sponsored by the National Index 7'enns-Coupliny. fault rate, module ccnt. reu.w. ude. Siftware EngimerinR Lahiratury. strength. unreferrnced variahler. INTRODUCIION OFTWARE engineers have developed a large body of S theory, largely unsupported by quantitative evidence. that specifies the characteristics a good design must incorporate. Formal methodologies, as well as folklore. prescribe practices intended to maximize these characteristics. This paper reports the results o f an empirical study o f design practices in a Fortran-based scientific computing environment. These practices can be expressed as a set of rules. Reuse software wherever possible. Keep modules small. Include only one function i n any module. Use parameter rather than C O M M O N coupling. Allow no more than seven descendants to any Do not create or access data items unnecessarily. Some in;portant design practices (e.g., information hiding [ 1 I and data abstraction 121) had to be excluded from this study because they were difiicult to measure and/or implement in Fortran. Many factors weigh against simply upgrading the developnient language: a substantial legacy
doi:10.1109/tse.1986.6312942 fatcat:vqmcahgrdfgndgj7afkjasiqjq