D.N. Card and R.L. Glass: Measuring Software Design Quality. Prentice-Hall, Englewood Cliffs, 1990.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....between goals, b. argument for solving the conflict a. b. ciency, estimates of the algorithmic complexity of the algorithms employed or execution time estimates (cf. e.g. 28] 30] may give an indication which alternative to choose. Maintainability can be linked, e.g. to complexity: [4] show in a case study how complexity may be used to predict, e.g. the effort required for maintaining a software system. The complexity of a modular software design is determined by the interconnectivity of modules and the internal complexity of individual modules, i.e. the average number of ....

D.N. Card and R.L. Glass: Measuring Software Design Quality. Prentice-Hall, Englewood Cliffs, 1990.

....paradigm. It is not stating that there is an optimal program size. Also note that the optimal size theory is stated and demonstrated in terms of fault minimzation, rather than other outcome measures such as maximizing maintenance productivity. 87 09 04 00 2 or 50 160 SLOC [2] Card and Glass [12] note that military standards for module size range from 50 to 200 executable statements. Kan [34] plotted a curve of the relationship between LOC and fault density for IBM s AS 400, and concluded that there was indeed an optimal component size. This U shaped curve is depicted in Figure 1 as it is ....

....and controversial claims made by proponents of the optimal size theory [27] 28] 30] Part B of Figure 1 illustrates another element of the Goldilocks Conjecture: that beyond a certain size, fault proneness increases rapidly. This is in essence a threshold effect. For instance, Card and Glass [12] note that many programming texts suggest limiting component size to 50 or 60 SLOC. A study by O Leary [40] of the relationship between size and faults in knowledge based systems found no relationship between size and faults for small components, but a positive relationship for large components; ....

[Article contains additional citation context not shown here]

D. Card and R. Glass: Measuring Software Design Quality. Prentice-Hall, 1990.

....components further away from the optimal size. This optimal size has been stated to be, for example, 225 LOC for Ada packages [49] 83 total Ada source statements [13] 400 LOC for Columbus Assembler [34] 877 LOC for Jovial [20] or 200 400 LOC irrespective of the language [25] Card and Glass [10] note that military standards for module size range from 50 to 200 executable statements. Kan [30] plotted a curve of the relationship between LOC and fault density for IBM s AS 400, and concluded that there was indeed an optimal component size. This Ushaped curve is depicted in Figure 1 as it is ....

....To appear in the IEEE Transactions on Software Engineering. 2001. V02 27 02 00 3 Part B of Figure 1 illustrates another element of the Goldilocks Conjecture: that beyond a certain size, fault proneness increases rapidly. This is in essence a threshold effect. For instance, Card and Glass [10] note that many programming texts suggest limiting component size to 50 or 60 SLOC. A study by O Leary [35] of the relationship between size and faults in knowledge based systems found no relationship between size and faults for small components, but a positive relationship for large components; ....

[Article contains additional citation context not shown here]

D. Card and R. Glass: Measuring Software Design Quality. Prentice-Hall, 1990.

....characterized as warfare against interconnectivity [19, p. 260] Furthermore, appropriate structure also reduces the overall cognitive complexity of the design, thus making the design easier and less errorprone to implement for a programmer and consequently leading to higher software quality [20]. In conventional software engineering, modules have been proposed as a means to achieve such a reduction of interconnectivity or complexity, with the additional advantage of hiding irrelevant details to parts that need not care about them (cf. e.g. 21] In order to achieve these benefits for ....

....achieves OR AND excludes refines refines ABANDON . Measurement Measurement of performance and quality is viewed by many authors as an important step in the process of turning software development from an art into an engineering discipline. This holds for conventional software (cf. e.g. [20]) as well as for kbs (cf. e.g. 15] During kbs design and construction, methods and tools are needed for measuring the degree of performance and the quality achieved by the system [ such that [ the work done is reviewed and assessed, wrong design decisions and bad construction steps ....

[Article contains additional citation context not shown here]

D.N. Card with R.L. Glass: Measuring Software Design Quality. Prentice Hall, Englewood Cliffs, 1990.

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