Selby, R. W., and Basili, V. R., "Analyzing Error-Prone System Structure," IEEE Transactions on Software Engineering, Vol. 17, No. 2, February 1991, pp. 141-152.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....observations that demonstrate this. For example Basili and Perricone [1] observed that smaller Fortran components are likely to have greater fault density, but did not identify an optimal component size. A similar observation was made by Davey et al. for C modules [17] and Selby and Basili [48] for routines written in a high level language similar to PL I used at the NASA GSFC. Shen et al. 49] analyzed data from three systems at IBM and found that fault density was higher for smaller components, but again did not identify a point where the fault density would start to rise again for ....

....data for a Fortran project developed at the Software Engineering Laboratory. They found that smaller modules tended to have a larger fault density than larger modules. Size was measured in terms of executable lines of code. Davey et al. 17] found a similar pattern for C modules, Selby and Basili [48] observed the same phenomenon for routines written in a high level language similar to PL I, Shen et al. 49] reported the same pattern for three systems at IBM, and Moller and Paulish for systems at Siemens [39] Other studies reported a U shaped curve between fault density and size. For ....

[Article contains additional citation context not shown here]

R. Selby and V. Basili: "Analyzing Error-Prone System Structure". In IEEE Transactions on Software Engineering, 17(2):141-152, 1991.

....that uses that data. The identification of failure modes is the most difficult part of the forward analysis. To assist in the identification, a classification of failure modes has been developed. This classification is consistent with other current classifications of defects in software (e.g. [3, 40]) See [19] for a more detailed description of failure modes. For each input and each output of the software component, each of the following four failure modes is considered: ffl Missing Data (e.g. lost message, data loss due to hardware failure) ffl Incorrect Data (e.g. inaccurate data, ....

Selby, R. W. and V. R. Basili (1991), "Analyzing Error-Prone System Structure," IEEE Transactions on Software Engineering, 17, 2, 141-152.

....observations that demonstrate this. For example Basili and Perricone [1] observed that smaller Fortran components are likely to have greater fault density, but did not identify an optimal component size. A similar observation was made by Davey et al. for C modules [14] and Selby and Basili [43] for routines written in a high level language similar to PL I used at the NASA GSFC. Shen et al. 44] analyzed data from three systems 6 at IBM and found that defect density was higher for smaller components, but again did not identify a point where the fault density would start to rise again ....

....data for a Fortran project developed at the Software Engineering Laboratory. They found that smaller modules tended to have a larger fault density than larger modules. Size was measured in terms of executable lines of code. Davey et al. 14] found a similar pattern for C modules, Selby and Basili [43] observed the same phenomenon for routines written in a high level language similar to PL I, Shen et al. 44] reported the same pattern for three systems at IBM, and Moller and Paulish for systems at Siemens [34] Other studies reported a U shaped curve between fault density and size. For ....

[Article contains additional citation context not shown here]

R. Selby and V. Basili: "Analyzing Error-Prone System Structure". In IEEE Transactions on Software Engineering, 17(2):141-152, 1991.

....to by an aggregate name [9] for example a file or a collection of files. Any variable that is shared or is visible (that is, it can be fetched and stored) by all the components of a module is considered as a global variable. Clustering techniques and architectural recovery techniques presented in [10, 11] can be used in order to obtain an initial decomposition of a large system in terms of module components. For each variable its corresponding type can be extracted from the Abstract Syntax Tree, and a candidate object class can be generated. Once an initial set of candidate classes is identified, ....

R. Selby, V. Basili, "Analyzing Error-Prone System Structure", IEEE Transactions on Software Engineering, Vol.17, No.2, February 1991, pp. 141152.

....than a design describing the algorithms or data structures used in a system. Several researchers have proposed automated or semi automated techniques to create groups of related program symbols with the implicit or explicit objective of recovering the modular decomposition of the program [BE81, CS90, HB85, MMM90, MBK91, LW90, PCB92, Sch91, SB91] . It is not very obvious how these Architecture The term module is used in this paper in the sense used by Parnas [Par76] in the context of abstract data typing and information hiding. Some researchers have proposed architecture recovery techniques that are not automatable because ....

....The papers of [HB85, LW90] present multiple ARTs, each of them with the same classification. The second column classifies the techniques on the type of computation they perform, i.e. graph theoretic, numeric, or conceptual. Notice that none of the ARTs use conceptual clustering. The ARTs of [BE81, HB85, PCB92, MBK91, Sch91, SB91] use numeric computations, those in [CS90, LW90] use graph theoretic computations. The ART of [MU90] uses both graph theoretic and numeric computations. The third column classifies each technique on whether they place a program element in one and only one module (partitioned) or whether a program ....

[Article contains additional citation context not shown here]

Richard W. Selby and Victor R. Basili. Analyzing error-prone system structure. IEEE Transactions on Software Engineering, pages 141--152, February 1991.

.... The term module is used in this paper in the sense used by Parnas [30] in the context of abstract data typing and information hiding. 1 are placed in the same subsystem [1, 6, 21, 27, 28, 31, 36] Alternatively, one may place syntactic units related to the same fault in the same subsystem [17, 37]. A subsystem may also consist of collection units files and modules where units affected by the same change request are grouped together [23] One may also classify a collection of complete programs into subsystems representing software libraries [22] Subsystems may also be comprised of both ....

....of this heuristic requires CXG , i.e. which program element is declared in which file. 4.1.5 SCT of Selby and Basili Selby and Basili s SCT uses the same CFG as the SCTs of Hutchens and Basili, Section 4.1. 1, and creates subsystems consisting of symbols from the corresponding set [37]. It uses single link HAC with the similarity matrix =a as defined with Hutchens and Basili s SCTs. 4.2 Numeric, non stratified SCTs Numeric, non stratified SCTs are techniques that use numeric computation to organize program components into subsystems. They are non stratified in that they ....

[Article contains additional citation context not shown here]

Richard W. Selby and Victor R. Basili. Analyzing error-prone system structure. IEEE Transactions on Software Engineering, pages 141--152, February 1991.

....functional testing and clustered testing, are used extensively in testing of many products. Such testing is no longer random. 2. Homogeneous distribution of faults and equal likelihood of fault exposure. By contrast, some studies have shown that the defect distribution is generally uneven [18, 19]. Selby and Basili [19] found that interfaces appear to be most error prone, regardless of the module type. They reported that 3 initialization errors are about 11 , control errors 16 , interface errors 39 , data errors 14 and computation errors 20 . 3. No new faults are introduced. In ....

....and clustered testing, are used extensively in testing of many products. Such testing is no longer random. 2. Homogeneous distribution of faults and equal likelihood of fault exposure. By contrast, some studies have shown that the defect distribution is generally uneven [18, 19] Selby and Basili [19] found that interfaces appear to be most error prone, regardless of the module type. They reported that 3 initialization errors are about 11 , control errors 16 , interface errors 39 , data errors 14 and computation errors 20 . 3. No new faults are introduced. In practice, appropriate actions ....

[Article contains additional citation context not shown here]

R. Selby, V. R. Basili, "Analyzing error-prone system structure", IEEE Transactions on Software Engineering, vol. 17, no. 2, p. 141-152.

.... that the design complexity inherent in such a system requires hidden interfaces which allow errors in non critical software to affect safety critical software [1] This is consistent with Selby and Basili s results when they analyzed 770 software errors during the updating of a library tool [23]. Of the 46 errors documented in trouble reports, 70 were categorized as wrong and 28 as missing. They found that subsystems that were highly interactive with other subsystems had proportionately more errors than less interactive subsystems. Leveson listed a set of common assumptions that ....

....safety critical hazards early in the requirements analysis. These hazards are constraints on the possible designs and factors in any contemplated tradeoffs between safety (which tends to encourage software simplicity) and increased functionality (which tends to encourage software complexity) [11, 23]. On the two spacecraft studied here, the need for high reliability led to early identification of safety critical functions. However, early identification of safety critical data items (whose incorrect values can cause risk to the system) safety critical timing dependencies, and safety critical ....

R. W. Selby and V. R. Basili, "Analyzing Error-Prone System Structure," IEEE Transactions on Software Engineering 17, 2, Febr 1991, pp. 141--152.

....Myers [10] refined the concept of coupling by presenting well defined, though informal, levels of coupling. Since his levels were neither precise nor prescriptive definitions, coupling could only be determined by hand, leaving room for subjective interpretations of the levels. Other researchers [15, 8, 6, 14] have used coupling levels or similar measures to evaluate the complexity of software design and relate this complexity to the number of software faults. Recently, Fenton and Melton [4] developed a measurement theory that provides a basis for defining software complexity and used hand derived ....

....and Henry, they derive their measures from program source, but do not derive as detailed a measurement as does coupling. Specifically, data bindings do not differentiate between data computation and control uses, and do not differentiate parameter values from global structures. Selby and Basili [14] used Hutchens and Basili s data binding measurements [6] to measure a 148,000 line system from a production environment. They collected error data during the testing phase, and applied five tools to calculate data bindings using clustering. They found that procedures with the highest coupling had ....

[Article contains additional citation context not shown here]

R. W. Selby and V. R. Basili. Analyzing error-prone system structure. IEEE Transactions on Software Engineering, 17(2):141--152, February 1991.

....techniques for determining fault position and cause. 5. 1 Fault Clustering It is known that the type of system product and the abilities of the programmers (and testers) affect the fault commonality [DR91, MP94] Also, experiments have shown that fault clustering is nonuniform [EIP 91, POC93, SB91, Dun93, BKL90, KZT94, HLL94, MP94] Moller and Paulish also 5 reasoned that over 77 of faults affect only one module, thus affirming theories on the necessity for heavy unit testing. They also confirmed that faults affecting more than one module were more costly to correct. When a defect of a ....

....new modules in the procedural environment. It is unlikely that modified classes in the OO environment would require any less rigorous testing. 5. 2 Metrics, Sufficiency and Adequacy Experiments have shown that complexity metrics are either related to the number or faults in code or are not [MK92, SB91, Gaf84, SYTP85, TK89, MP94, BP84] There is therefore some debate, which will no doubt continue for some time, with regard to the relationship between complexity and fault concentration. The results are confusing and there are obviously other factors involved other than code complexity in fault ....

R.W. Selby and V.R. Basili. Analyzing Error-Prone System Structure. IEEE Trans. on Software Engineering, SE-17(2), February 1991.

....included in our study, and we briefly indicate how each was applied to the software product. 3.1 Interclass (Coupling) Metrics We believe that, in most software products, a significant impediment to maintenance is the level of interconnection between classes. This is supported by studies such as [11] and [14] in which internal product attributes thought to be coupling related were found to correlate highly with product modifiability and, hence, maintainability. In this section, we describe the coupling metrics which were included in this study. 3.1.1 Simple Class Coupling A number of ....

R. W. Selby and V. R. Basili, "Analyzing Error-Prone System Structure," IEEE Trans. Software Eng., vol. 17, no. 2, 1991, pp. 141--152.

....program, earlier program versions can be retrieved to return to a working version or help find the change that caused the error. Like a language, a tool can make methods easier to follow or apply. A tool that discovers component relationships [Embley Woodfield 88] Rich Waters 88] Schwanke 91] Selby Basili 91] or that automates remodularizing a program can aid an engineer in using Parnas s system decomposition principles to achieve locality of change. 1.3 A Tools Solution Restructuring This thesis focuses on a tools solution to mitigate the software maintenance problem. The goal is to automate the ....

R. W. Selby and V. R. Basili. Analyzing error-prone system structure. IEEE Transactions on Software Engineering, SE-17(2):141--152, February 1991.

....and concepts. 1 Object based systems differ from object oriented systems in that inheritance is not allowed. 3 A number of studies have been published on software design measures in recent years. It has been shown that system architecture has an impact on maintainability and faultproneness [HK84, G86, R87, IS88, R90, BRBD90, S90, SB91, Z91, AE92, BTH93, BBH93, ZEWH95]. These studies have attempted to capture the design attributes affecting the ease of maintaining and debugging a software system. Most of the design measures are based on information flow between subroutines or declaration counts. We think that, even though they provide interesting insights into ....

R. Selby and V. Basili, "Analyzing Error-Prone System Structure," IEEE Trans. Software Eng., 17 (2), February, 1991.

....between modules, i.e. the more inter related they are, the more difficult these modules are to understand, change, and correct and thus the more complex the resulting software system. Some empirical evidence exists to support this theory for structured development techniques; see, e.g. TZ81] [SB91]. ISERN 96 14 2 The principle of low coupling has now been migrated to object oriented design by Coad and Yourdon [CY91a, CY91b] and recent research has again lead to a large number of new coupling measures for object oriented systems being defined. However, because coupling is a more complex ....

R.W. Selby, V.R. Basili, "Analyzing Error-prone Systems Structure", IEEE Transactions on Software Engineering, 17 (2), 141-152, 1991.

....by empirical evidence. The following quote is taken from van Vliet[21] Department of Computer Science RR 95 173 [EFoCS 9 95] Empirical studies show that interfaces exhibiting weak coupling and strong cohesion are less error prone than those that do not have those properties (see for example[18]) This paper will show, however, that there is a lack of consistent empirical evidence. In fact, the empirical work to date is even inconsistent in some respects of its definition and interpretation. In the sections which follow we briefly summarise the theoretical arguments supporting module ....

....In this section we present a survey of empirical work to date investigating module coupling. A brief summary of each experiment is presented concentrating on the methodology used, the aspects of module coupling explored and the conclusions derived. 3. 1 Analysing Error Prone System Structure [18] According to van Vliet[21] this work is an example of an empirical study demonstrating that loosely coupled modules are less error prone than tightly coupled ones. Of particular interest is the definition of coupling Selby and Basili used and the techniques they adopted to measure it. They state ....

Richard W. Selby and Victor R. Basili. Analyzing error-prone system structure. IEEE Transactions on Software Engineering, 17(2):141--152, February 1991.

.... that the design complexity inherent in such a system requires hidden interfaces which allow errors in non critical software to affect safety critical software [1] This is consistent with Selby and Basili s results when they analyzed 770 software errors during the updating of a library tool [22]. Of the 46 errors documented in trouble reports, 70 were categorized as wrong and 28 as missing. They found that subsystems that were highly interactive with other subsystems had proportionately more errors than less interactive subsystems. Leveson listed a set of common assumptions that ....

....safety critical hazards early in the requirements analysis. These hazards are constraints on the possible designs and factors in any contemplated tradeoffs between safety (which tends to encourage software simplicity) and increased functionality (which tends to encourage software complexity) [10, 22]. Many of the safety related software errors reported in Sect. III involve data objects or processes that would be targeted for special attention using hazard detection techniques such as those described in [7, 11] Early detection of these safety critical objects and increased attention to ....

R. W. Selby and V. R. Basili, "Analyzing ErrorProne System Structure," IEEE Trans Software Eng 17, 2, Febr 1991, pp. 141--152.

....to analyze the effects of failures possibly caused by software that fails to function correctly. The investigation of faults in the two tables is consistent with current classifications of defects in software [Addy 1991; Chillarege et al. 1992; Nakajo and Kume 1991; Ostrand and Weyuker 1984; Selby and Basili 1991]. The first type of table is the Data Table (Table 1) This table evaluates both the effect of receiving bad or unexpected input data on the behavior of the process being analyzed, and the effect of producing bad or unexpected output data on the behavior of the processes that use this data. For ....

Selby, R. W. and V. R. Basili (1991), "Analyzing Error-Prone System Structure," IEEE Transactions on Software Engineering, 17, 2, 141-152.

....for focusing our research on a smaller set of strategies and concepts. A number of studies have been published on software design measures in recent years. It has been shown that system architecture has an impact on maintainability and fault proneness [26] 24] 38] 30] 39] 16] 40] [41], 43] 1] 17] 2] 44] These studies have attempted to capture the design attributes affecting the ease of maintaining and debugging a software system. Most of the design measures are based on information flow between subroutines or declaration counts. We think that, even though they ....

R. Selby and V.R. Basili, "Analyzing Error-Prone System Structure, " IEEE Trans. Software Eng., vol. 17, no. 2, Feb., 1991.

....the system and its constituent parts. In this paper, we will focus on high level design metrics for software systems. A number of studies have been published on software design metrics in recent years. It has been shown that system architecture has an impact on maintainability and error proneness [HK84, G86, R87, R90, S90, SB91, Z91, AE92, BTH93, BBH93]. These studies have attempted to capture the design characteristics affecting the ease of maintaining and debugging a software system. Most of the design metrics are based on information flow between subroutines or declaration counts. We think that, even though it provides an interesting insight ....

R. Selby and V. Basili, "Analyzing Error-Prone System Structure," IEEE Trans. Software Eng., 17 (2), February, 1991.

No context found.

Selby, R. W., and Basili, V. R., "Analyzing Error-Prone System Structure," IEEE Transactions on Software Engineering, Vol. 17, No. 2, February 1991, pp. 141-152.

No context found.

SELBY, R. W., BASILI, V. R.: 'Analyzing error-prone system structure', IEEE Trans. on Softw. Eng., 1991, 17 (2) pp. 141--152

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