Basili, Victor R. and Perricone, Barry T. Software errors and complexity: An empirical investigation. Communications of the ACM, Vol. 27, No. 1, 1984.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....[17] While external measures have the most impact on the software development cycle, they are harder to quantify than internal ones. As a result, research strives to derive good internal measures [11, 12] and to establish correlations between internal and external measures by empirical study [2, 4, 15]. However, there is no systematic way to use these studies to aid the selection process. One approach has been to develop formal axiomatic models of complexity [10, 13, 14, 18, 20, 22] In our model [18] we differentiate between complexity being an inherent property between two programs and a ....

V. R. Basili and B. T. Perricone, "Software errors and complexity: An empirical investigation," Comm. of the ACM, 27(1):42-52, Jan. 1984.

....demonstrate only part A in Figure 1. Others only support part B. The first part of the Goldilocks Conjecture argues that smaller components have higher fault proneness than larger components. There are number of empirical 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 ....

....subsection. We then consider the second part of the Goldilocks Conjecture. 2.1 The High Fault Density of Small Components and The U Shaped Curve A number of studies found a negative relationship between fault density and some measure of size for S S . For example, Basili and Perricone [1] analyzed testing and maintenance fault 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 ....

[Article contains additional citation context not shown here]

V. Basili and B. Perricone: "Software Errors and Complexity: An Empirical Investigation". In Communications of the ACM, 27(1):42-52, 1984.

....and engaging in some doubtful mathematical manipulation (i.e. setting the expected value of a sum of non linear variables equal to the sum of the expected variables) concluded that the optimal size for a module (also called a functional group) was 877 SLOC for Jovial code. Basili and Perricone [8], on the other hand, were not able to find an optimum module size for a FORTRAN system. They defined a module as a sub function, subroutine, or main program. Their data showed that the larger the module, the less error prone it was. The authors attributed this behaviour to the spreading of a large ....

Basili, V. and Perricone, B. (1984). Software Errors and Complexity: An Empirical Investigation, Computing Practices, 27 (1), 42-52.

....used to allow tagging of different versions of the code and to help large teams of developers to work on the same code base. Change data are collected as a side effect when version control systems keep track of versions. Other methods of collecting information make use of surveys or experiments [13], 14] The resulting information is valuable and detailed, but limited in scope and time, even if the data gathering is not prohibitively expensive. Further, the very act of performing the experiment can alter developers behavior and thereby bias the results. SoftChange is not susceptible to ....

....of failure in periods of time; see, for example, 20] 21] 22] 23] Since post release failure rates are typically very small, they are modeled for entire releases. In addition, source code centric measures are typically used to model the probability of failure, for example in [24] [13], 25] 26] 27] 28] Historic fault rates for code units can also predict future fault rates; see [29] as well as [8] and its references. As with effort models, the large size of releases confounds a number of factors that contribute to failure. Such factors include experience of individual ....

V. R. Basill and B. T. Perricone, "Software errors and complexity: An empirical investigation," Communications of the ACM, vol. 27, no. 1, pp. 42-52, January 1984.

....demonstrate only part A in Figure 1. Others only support part B. The first part of the Goldilocks Conjecture argues that smaller components have higher fault proneness than larger components. There are number of empirical 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 ....

....subsection. We then consider the second part of the Goldilocks Conjecture. 2.1 The High Fault Density of Small Components and The U Shaped Curve A number of studies found a negative relationship between fault density and some measure of size for S S . For example, Basili and Perricone [1] analyzed testing and maintenance fault 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 ....

[Article contains additional citation context not shown here]

V. Basili and B. Perricone: "Software Errors and Complexity: An Empirical Investigation". In Communications of the ACM, 27(1):42-52, 1984.

....counted [36] In fact, Beizer [6] comments that error classifications are potentially infinite. However a number of classifications have been developed. The objective of such classifications is to provide useful information and to allow a theory of programming errors and debugging to be developed [5, 43]. The first task in creating a classification of errors is to adopt a definition of an error on which the classification will be based. Three classifications presented here use the IEEE definition of an error [18] where an error is defined as an inappropriate action. However, the three ....

Basili, V.R. and Perricone, B.T., "Software Errors and Complexity: An Empirical Investigation", Communications of the ACM, ACM, NY, vol. 27, no. 1, pp. 42-51, January 1984.

....favorable impact cost and quality and various complexity factors unfavorable impact cost and quality Examples of change and defect models and baselines include: change baselines by various classifications, defect baselines by various classifications, defect prediction models, reliability models. [WeBa85, BaPe84, BaRo87, BaWe81, SeBa88] We can capture the number of errors, faults and failures associated with various phases, e.g. in total, by various classes (error domain, time of detection, omission commission, software aspect, failure by resolution date opened date closed) We can build histograms and cumulative graphs as ....

V. R. Basili, B. Perricone, "Software Errors and Complexity: An Empirical Investigation," ACM Communications, vol. 27, no. 1, January 1984, pp. 45-52.

....our numbers are di erent (keep in mind we take les instead of modules as our unit) the basic point of the principle seems to be supported by our results. They also found that an even smaller portion of the modules (10 ) account for almost all of the operational failures. Basili and Perricone [3] report on a manually conducted study of satellite planning software consisting of 90k LOC spread across 370 modules (functions) They found that reusing modules for a new purpose decreased initial development cost, but more e ort was required to correct errors in them. Thus there was a tradeo ....

V. Basili and B. Perricone. Software Errors and Complexity: an Empirical Investigation. Communications of the Association for Computing Machinery, 27(1):42-52, 1984.

....our numbers are di#erent (keep in mind we take files instead of modules as our unit) the basic point of the principle seems to be supported by our results. They also found that an even smaller portion of the modules (10 ) account for almost all of the operational failures. Basili and Perricone [3] report on a manually conducted study of satellite planning software consisting of 90k LOC spread across 370 modules (functions) They found that reusing modules for a new purpose decreased initial development cost, but more e#ort was required to correct errors in them. Thus there was a tradeo# ....

V. Basili and B. Perricone. Software Errors and Complexity: an Empirical Investigation. Communications of the Association for Computing Machinery, 27(1):42--52, 1984.

....our numbers are different (keep in mind we take files instead of modules as our unit) the basic point of the principle seems to be supported by our results. They also found that an even smaller portion of the modules (10 ) account for almost all of the operational failures. Basili and Perricone [3] report on a manually conducted study of satellite planning software consisting of 90k LOC spread across 370 modules (functions) They found that reusing modules for a new purpose decreased initial development cost, but more effort was required to correct errors in them. Thus there was a tradeoff ....

V. Basili and B. Perricone. Software Errors and Complexity: an Empirical Investigation. Communications of the Association for Computing Machinery, 27(1):42--52, 1984.

....over time. 4.1 Fault Distribution Patterns Real faults in a program are more likely distributed non uniformly over the program. Here, the focus is on run time rather than compile time faults. Existing evidence suggests that fault distribution depends upon functionality and structure of the code [1, 19]. Like [18] faults are classified into three major types: 1) computing and data faults associated with computation and initialization, 2) control faults associated with data flow control statements, and (3) interface faults related to interfaces (procedure or function calls and parameter ....

V.R. Basili, B.T. Perricone, "Software errors and complexity: an empirical investigation", Communication of the ACM, vol. 27, no. 1, p. 42-52, 1984.

.... 1 early lifecycle phases of requirements and design, which can have a lasting impact on the reliability, cost, and safety of a system [1] Also, requirements errors are between 10 and 100 times more costly to correct at later phases of the software lifecycle than at the requirements phase [2, 3, 4]. One approach to this problem is to document software requirements and design using a formal language; such a document is called a formal specification [5] This approach is one of the basic elements of the software engineering disciplines referred to as formal methods. A formal method is ....

V. Basili and B. Perricone, "Software errors and complexity: an empirical investigation," Communications of the ACM, vol. 21, pp. 42--52, January 1984.

.... and validate the model) Two sources of databases containing historical data, denoted here as error tracking libraries and bookkeeping libraries, have been used in the past by researchers for the development of error prediction models in software and microcode processes, see for example [4, 5, 6]. The first source, denoted here as error tracking libraries, are usually established during the integration of a system to report defects and track their resolution. The second source, which we will refer to as the bookkeeping libraries are usually created in the beginning of the development ....

V. R. Basili and B. T. Perricone. Software errors and complexity: An empirical investigation. Communications of the ACM, pages 42--52, January 1984.

....For the second formula, there is no need to compute the graph. The algorithm is to count the number of predicates. Interpretation: Maintainability should decrease has v(G) increases. McCabe suggested 10 as the ideal maximum value for a module. However, this value seems arbitrary to some authors ([BP84], Ejio91] LV89] noted that the change density was minimum for modules with v(G) between 10 and 15. Validity: This metric has been well studied in the literature. The following is a list of correlation levels found: Romb84] MIE ( 56) LNB ( 40) BK85] HIE ( 81) Canadian Space Agency ....

.... Agency 1994 34 [BSP83] LIE to MIE (depending on the analysis: by programmer, project or overall) LFC to MFC (idem) LDE to MDE (idem) KH81] HFC ( 96) LV89] MFC to HFC ( 68 random sample, 72 for selected system features) DL88] MIE ( 53 debugging time, 66 construction time) HFC ( 79 ) [BP84], surprisingly, shows that the number of faults per module was decreasing when v(G) and LOC (see description of LOC) were increasing. This is in contradiction with the interpretation just given. These results are tentatively explained by the fact that larger modules are coded with greater care, ....

V. Basili and B.T. Perricone. "Software Errors and Complexity: An Empirical Investigation", CACM, 27(1), January 1984.

....uses a new process, the defect profile of that project can be compared to the baseline, and these measurements will help members of the SEL determine whether or not the process change was effective. By 1984, The SEL had already developed a classification scheme used by projects throughout the lab [BasiliPerricone84]. The engineer identifying the error was responsible for classifying it in one of Basili and Perricone s categories: Requirements incorrect or misinterpreted . Functional specification incorrect or misinterpreted . A Design error which spans several modules Michael Fredericks Page 12 06 03 99 ....

Basili, Victor R., and Barry T. Perricone (1984). "Software Errors and Complexity: An Empirical Investigation." Communications of the ACM, 27(1) (January):42-52.

....Software modules that have been code generated will be repaired less frequently than software modules that have been coded manually. 6 2. 3 Software Complexity A number of studies have linked software complexity with software maintenance performance and software errors (Potier, et al. 1982; Basili and Perricone 1984; Banker, et al. 1991) Software complexity refers to the characteristics of software that make it difficult to understand and to modify (Curtis, et al. 1979; Basili 1980) There are multiple dimensions of software complexity (Banker, et al. 1989) in this study, we focus on one particular ....

Basili, V. R. and B. Perricone, "Software Errors and Complexity: An Empirical Investigation" Communications of the ACM, 27(1): 42-52 (1984).

....an Ada module, with respect to minimizing error density is 83 source statements. They dubbed this the Goldilocks Principle with the idea that there is an optimum module size that is not too big nor too small. The phenomenon that larger modules can have lower defect densities was confirmed in [13], 14] 15] Basili and Perricone argued that this may be explained by the fact that there are a large number of interface defects distributed evenly across modules. Moller and Paulish suggested that larger modules tend to be developed more carefully; they discovered that modules consisting of ....

....defects or defect density. Analysis of averages are one step removed from the original data and it raises a number of issues. Using averages reduces the amount of information available to test the conjecture under study and any conclusions will be correspondingly weaker. The classic study in [13] used average fault density of grouped data in a way that suggested a trend that was not supported by the raw data. The use of averages may be a practical way around the common problem where defect data is collected at a higher level, perhaps at the system or subsystem level, than is ideal; ....

# V.R. Basili and B.T. Perricone, "Software Errors and Complexity: An Empirical Investigation," Comm. ACM, vol. 27, no. 1, pp. 42-52, 1984.

....approaches have provided some extremely valuable empirical results. However, as discussed in Section 1, they cannot be used effectively for quantitative management and risk analysis, and hence do not yet address the primary objective of metrics. In the case of quality prediction (see for example, [7,24,39,46]) the emphasis has been on determining regression based models of the form f(complexity metric) defect density where defect density is defects per KLOC. In [20] we provided an extensive critique of this approach. We concluded that the existing models are incapable of predicting defects ....

Basili VR and Perricone BT, "Software Errors and Complexity: An Empirical Investigation", Communications of the ACM, Vol. 27, No.1, pp.42-52, 1984.

....Incorrect Missing commentaries or flowcharts Use Incomaptible status of macros or modules Initialize Not classifiable Set Update y Items in bold are names of main error categories. provides details of the faults in T E X classified using our scheme. 2 Past Work Several researchers [5, 12, 13, 18, 20, 22] have reported categorization of errors faults 1 found in different phases of the software life cycle. Even though each one of the classifications proposed is different from the others, they all share two common problems, namely, they are ambiguous and difficult to automate. Thus, for each ....

....This category is machine dependent and hence not useful for the categorization of faults in programs written in high level languages. 2. 2 Basili and Perricone s scheme Like the schemes proposed by other researchers, Basili and Perricone s (hereafter referred to as B P) classification scheme [5] also suffers from ambiguities. One of their categories is control errors which consists of errors that cause an incorrect path to be taken in a program module. Another category named data errors consists of errors that are the result of an incorrect use of a data structure. To point out the ....

[Article contains additional citation context not shown here]

V. R. Basili and B. T. Perricone, "Software Errors and Complexity: An Empirical Investigation, " Comm. of the ACM, Vol. 27, No. 1, pp 42-52, January 1984. 51

....during a software project. The distribution of defects by type can be used to identify product and process problems [8] 12] and can be used as a project planning and monitoring tool [35] The relationship between defect types and other variables such as whether a module was new or modified [4], and the cost of correction [32] 6] can provide insight into development activities. Defect causal analysis methods utilize defect classes for clustering defects and focusing the causal analysis meeting [10] Incorporation of defect types is considered to improve the accuracy of capturerecapture ....

V. Basili and B. Perricone: "Software Errors and Complexity: An Empirical Investigation". In Communications of the ACM, 27(1):42-52, January 1984.

....less than an hour. The largest single cause of faults was programmer error, accounting for 63 of the total. Other major causes were unclear specifications (12 ) and clerical (9 ) Also in 1984, Basiliand Perricone published a similar study on the faults in the Software Engineering Lab at NASA [Basili and Perricone, 1984]. In this study, he collected fault data from thirty three months of testing and operation of a 90,000 line Fortran system. For each fault, he collected data on the cause and the location, and assigned the fault to a fault class. 89 of the faults studied were well localized, affecting only one ....

V. Basili and B. Perricone. Software errors and complexity: An empirical investigation. Communications of the ACM, 27(1):42--52, January 1984.

....[6,7] These models estimate the number of faults that are already in the software. Our work differs from these studies in that we assume new faults are continuously being added to the system as changes are made. Our research is similar to previous empirical studies of software faults, e.g. [8,9,10,11], where the aim is to un GRAVES, KARR, MARRON, AND SIY: PREDICTING FAULT INCIDENCE USING SOFTWARE CHANGE HISTORY 101 derstand the nature and causes of faults. In these studies, explanatory variables are identified in order to account for the number of faults found. Our work extends this by ....

....B. Product measures. Product measures can be computed using syntactic data taken from a snapshot of the software. These include, for example, code size (lines of code) and degree of statement nesting. Several studies have shown that large modules have lower defect densities than small modules [8,9]. Hatton [10] reports that the decrease in defect densities is not linear but is U shaped, implying that there are mediumsized components that have lower defect densities than large components which in turn have lower defect densities than small components. Other studies have found that modules ....

[Article contains additional citation context not shown here]

V. R. Basili and B. T. Perricone, "Software errors and complexity: An empirical investigation," Communications of the ACM, vol. 27, no. 1, pp. 42--52, January 1984.

....error study, Thayer78] provides some of the same level of error analysis that our study provides, but on errors discovered during the testing and validation phases. Glass81] provides another high level, specification oriented picture of software errors discovered during the development process. Basili84] studies the relationship between software errors and complexity. Chillarege 91] provides an analysis of defects found during the test process and their impact on the growth curve. Software errors experienced in the field have different characteristics from those detected during the system test ....

V. R. Basili and B. T. Erricone., Software Errors and Complexity: An Empirical Investigation. Comm. of the ACM, 27(1), 1984.

....used to allow tagging of different versions of the code and to help large teams of developers to work on the same code base. Change data are collected as a side effect when version control systems keep track of versions. Other methods of collecting information make use of surveys or experiments [13], 14] The resulting information is MOCKUS, EICK, GRAVES, AND KARR, ON MEASUREMENT AND ANALYSIS OF SOFTWARE CHANGES 3 valuable and detailed, but limited in scope and time, even if the data gathering is not prohibitively expensive. Further, the very act of performing the experiment can alter ....

....of failure in periods of time; see, for example, 20] 21] 22] 23] Since post release failure rates are typically very small, they are modeled for entire releases. In addition, source code centric measures are typically used to model the probability of failure, for example in [24] [13], 25] 26] 27] 28] Historic fault rates for code units can also predict future fault rates; see [29] as well as [8] and its references. As with effort models, the large size of releases confounds a number of factors that contribute to failure. Such factors include experience of individual ....

V. R. Basili and B. T. Perricone, "Software errors and complexity: An empirical investigation," Communications of the ACM, vol. 27, no. 1, pp. 42--52, January 1984.

....during a software project. The distribution of defects by type can be used to identify product and process problems [8] 12] and can be used as a project planning and monitoring tool [29] The relationship between defect types and other variables such as whether a module was new or modified [4], and the cost of correction [26] 6] can provide insight into development activities. Defect causal analysis methods utilize defect classes for clustering defects and focusing the causal analysis meeting [10] 3 Incorporation of defect types is considered to improve the accuracy of ....

V. Basili and B. Perricone: "Software Errors and Complexity: An Empirical Investigation". In Communications of the ACM, 27(1):42-52, January 1984.

....be independent of programming language. Despite these advances the approaches to both defects prediction and resource prediction have remained fundamentally unchanged since the early 1980 s. Figure 1 provides a schematic view of the classical approach to defect prediction (as seen, for example in [Basili and Preicon 1984], Compton and Withrow 1990] Gaffney 1984] Lipow 1982] Shen et al. 1985] Size (whether it be solution size, as in complexity metrics or LOC based approaches, or problem size, as in function point based approaches) is the key driver. In many cases it is the only driver, although recently ....

Basili VR and Perricone BT, "Software Errors and Complexity: An Empirical Investigation", Communications of the ACM, Vol. 27, No.1, pp.42-52, 1984.

.... process for an industrial system Also, what are the important factors required from a test Research demonstrates that the efficiency and effectiveness of any testing technique is dependent on the code, how well it was written and what it does, and on the abilities of the testers [MP94, DR91, BP84] Also, the later in the software life cycle that testing is done, the higher the expense of corrective maintenance. It is therefore important to bring the testing phase further forward into the early stages of software development, and is an argument in favour of rapid prototyping or, for more ....

....that information to drive a test. Knowledge of what faults are common for a particular language, system product type (e.g. data base manager, word processor, data reduction system etc) or programmers can be used to focus testing. These ideas have been proposed by several researchers [DR91, BKL90, BP84] Also, if it is cheaper to detect and eliminate faults early in the lifecycle then designers should be encouraged to avoid common faults resulting from design patterns or method(ologie)s. It is therefore necessary to classify faults and to determine those of higher frequency for particular ....

[Article contains additional citation context not shown here]

V.R. Basili and B.T Perricone. Software Errors and Complexity: An Empirical Investigation. CACM, 27(1):42--52, January 1984.

....maintenance [8] Our conceptualization of code decay in medical terms was inspired by Parnas [9] In work related to our fault CDI, Ohlsson and Alberg [10] identify fault prone modules in switching system software. Two early fundamental papers relating software data collection and its analysis are [11], 12] II. Changes to Software Our definition of a change to software is driven by the data that are available: a change is any alteration to the software recorded in the change history data base. The specific data with which we deal are described in xII B and xV. The changes we study fall ....

V. R. Basili and B. T. Perricone, "Software errors and complexity: An empirical investigation," Communications of the ACM, vol. 27, no. 1, pp. 42--52, January 1984.

....Furthermore, type errors do not play an important role in these studies. Error type analyses have also been performed in larger scale software development settings. Type checking has not been a concern in these studies, but in some cases related information can be derived. For instance, reference [1] reports that 39 percent of all errors in a 90.000 line FORTRAN project were interface errors. We conjecture that some proportion of these could have been found by type checking. The error detection capabilities of testing methods is a question that has attracted considerable interest, see for ....

V. R. Basili and B. Perricone. Software errors and complexity: An empirical investigation. Communications of the ACM, 27(1):42--52, Jan. 1984.

....cost less and cause fewer delays, which can lead to a more effective inspection process overall. Another example where observation contradicts conventional wisdom is that small software components are proportionally less reliable than larger ones. This observation was first reported by Basili [1] and has been confirmed by a number of disparate sources; see Hatton [6] for summaries and an explanatory theory. As mentioned, the failure probabilities of multi version programs were incorrectly believed to be the product of the failure probabilities of the component versions. Another example is ....

Victor R. Basili and B.T. Perricone. Software errors and complexity: An empirical investigation. Communications of the ACM, 27(1):42--52, January 1984.

....time resolution values are 1 hour and =1 hour and the scopes are local fix (FL) global fix (FG) and no change (NC) Fault 5, for example, required more than 1 hour to fix and the changes are global. The classification of faults into kinds and types categories follow schemes discussed in [7] and [8] 7 3. USING CAPTURE RECAPTURE METHODS TO ESTIMATE THE NUMBER OF RESIDUAL FAULTS Capture recapture models for ecology are described in [9] 10] The basic model is as follows. There are some unknown number of faults N in a document being reviewed by m reviewers working independently. ....

Victor R. Basili and Barry T. Perricone, "Software Errors and Complexity: an Empirical Investigation," Communications of the ACM, vol. 27, no. 1, pp. 42-52, January 1984.

....Lines w NB, NC Semi Fault Program lines lines comments lines colons count cmdline 299 34 4 261 122 10 tokens 127 9 1 117 72 5 Table 3: Size measures and fault counts for the programs Faults were seeded into the programs. The two faceted fault classification scheme defined by Basili and Perricone [Basili and Perricone, 1984] was used to select a mix of faults (type fomission, commissiong and fault class finitialization, computation, control, interface, data, cosmeticg) The number of faults was chosen to attain a similar fault density in both programs. All faults caused unique, visible failures given suitable ....

Basili, V. R. and Perricone, B. T. (1984). Software errors and complexity: An empirical investigation. Communications of the ACM, 27(1):42--52.

....with other code metrics. Applying discriminant analysis with principal components, at a probability level of 80 percent, resulted in recognizing 79 percent of the modules with a total misclassification rate of 5 percent. Our result is closer with the investigation performed by Basili and Perricone [2], where the unexpected result was that module size and cyclomatic complexity had no relationship with the number of faults, although there was a negative relationship with the fault density. From our study, we argue that the relationship between software complexity measures and software quality ....

V. R. Basili, and B. T. Perricone, "Software errors and complexity: an empirical investigation", Communications of the ACM, vol.27, no.1, January 1984, pp.42-52.

....defects in programs written by novices, e.g. 6, 18] The results are not necessarily relevant for advanced programmers. Furthermore, type errors do not play an important role in these studies. Defect classification has also been performed in larger scale software development settings, e.g. [1, 10]. Type checking was not an explicit concern in these studies, but in some cases related information can be derived. For instance, Basili and Perricone [1] report that 39 percent of all defects in a 90.000 line FORTRAN project were interface defects. We conjecture that some fraction of these could ....

....play an important role in these studies. Defect classification has also been performed in larger scale software development settings, e.g. 1, 10] Type checking was not an explicit concern in these studies, but in some cases related information can be derived. For instance, Basili and Perricone [1] report that 39 percent of all defects in a 90.000 line FORTRAN project were interface defects. We conjecture that some fraction of these could have been found by type checking. The defect detection capabilities of testing methods [2, 8, 22] have received some attention; the corresponding ....

[Article contains additional citation context not shown here]

Victor R. Basili and B.T. Perricone. Software errors and complexity: An empirical investigation. Communications of the ACM, 27(1):42--52, January 1984.

....it as a testing method and categorise it as an ad hoc technique (the performance of which cannot be predicted) 4.4 An Agreed Fault Classification A further source of variability is in the classification and distribution of faults. Whilst significant progress has been made in this area (see [3, 1, 10] for example) there is still no agreed mechanism whereby faults can be classified and counted. This assumes that the use of seeded faults can mimic the full range of complexity and stubornesss exhibited by natural faults. 4.5 Qualitative Studies One fact that cannot be ignored is that there are ....

Victor R. Basili and Barry T. Perricone. Software errors and complexity: An empirical investigation. CACM, 27(1):42--52, January 1984.

....as project management tools. Another interesting result was that programmers were inconsistent in ranking systems according to complexity. Gibson and Senn write that objectively based metrics provide more reliable information for managers than subjectively based measures . Basili and Perricone [BP84] report about their findings in a few projects where most of the code was written in Fortran. According to their findings McCabe s [McC76] cyclomatic complexity was correlated with module size. In comparing development costs of new modules with the costs of modifying existing modules they found ....

....size would indicate error proneness. Maintenance and the complexity of systems create a vicious circle. Modifications are di#cult because of the complexity of the software, and because of the complexity more modifications are required. At least the following authors have addressed this issue: BP84,GS89,Gre84,LB85,LS80] A more interesting issue from our point of view is what can be improved in the software life cycle process by collecting and evaluating the software metrics to ensure better quality of the final product. Existing findings of software metrics studies are applied in ....

Victor R. Basili and Barry T. Perricone. Software errors and complexity: an empirical investigation. Communications of the ACM, 27(1):42--52, January 1984.

....development, program understanding, and maintenance. Researchers have recognized that the size, complexity, and interconnectedness of these systems place a severe cognitive load on software engineers which often leads to errors at high levels of system abstraction, such as requirements and design [1, 17]. It has been suggested that the attributes of hypertext make it an excellent technology for capturing and visualizing relations in a SDE [7] Providing hypertext capabilities in a SDE allows an engineer to freely associate objects without regard to the type of those objects or where they are ....

V. R. Basili and B. T. Perricone. Software Errors and Complexity: An Empirical Investigation. Communications of the ACM, 27(1):42--52, January 1984.

....of Code (or LoC) Despite being widely criticised as a measure of complexity, it continues to have widespread popularity [Azuma94] mainly due to its simplicity. Therefore, it has been suggested that LoC is used as a null hypothesis in experiments to compare quality of other software measures [Basili84a]. The search for theoretically based software measures with predictive capability was pioneered by Maurice Halstead. Halstead s Software Science [Halstead75] modelled program comprehension as a function of program operands (variables and constants) and operators (arithmetic operators and ....

....then appropriate corrective action can be taken [Daskalantonakis92] Analysis of defect detection success and latency has shown the importance of time on the impact of change. The cost of correcting software defects has been shown to rise rapidly as they progress through the software lifecycle [Basili84a]. One study quotes the cost of requirements errors not being caught until software test as much as 200 times more to correct than if they were caught during requirements engineering [Jaffe91] There are a number of reported successes of defect analysis techniques for process improvement. Indeed, ....

[Article contains additional citation context not shown here]

V. R. Basili and B. T. Perricone, "Software Errors and Complexity: An Empirical Investigation," Communications of the ACM, vol. 27, no. 1, pp. 42-52, 1984.

....implies the notion of a set of cooperating, independent tools. 11 1.5.1 The Effectiveness of Program Mutation Program mutations model simple faults, while what are regarded as complex faults occur more frequently in programs. 6 This has been empirically established by several studies [7,17,45]. However, the fact that the number of complex faults tends to dominate the number of simple faults does not negate the effectiveness of program mutation. Budd empirically showed that test data adequate to detect the presence of simple faults (mutations) is also adequate to detect the presence of ....

V. R. Basili and B. T. Perricone. Software Errors and Complexity: An Empirical Investigation. Communications of the ACM, 27(1):42--52, January 1984.

....providing added assurance that upstream processes are performed adequately. To improve review processes, resources must be used as efficiently as possible. Several recent articles argue that review processes can be improved by systematically focusing effort on high risk modules [She91] MIO87] BP84] Mye79] In practice, managers frequently concentrate resources on modules (e.g. subsystems, components, threads) that they deem to be high risk. To do this, however, they must rely on their subjective experience. In this article, we address the problem of automatically isolating high risk ....

V. R. Basili and B. T. Perricone. Software errors and complexity: An empirical investigation. Communications of the ACM, 27(1):42--52, January 1984.

....and Kanoun 1996] Khoshgoftaar et al. 1996] Ohlsson N and Alberg 1996] Shen et al. 1985] there continues to be a dearth of published empirical data relating to the quality and reliability of realistic commercial software systems. Two of the best and most important studies [Adams 1984] and [Basili and Perricone 1984] are now over 12 years old. Adams study revealed that a great proportion of latent software faults lead to very rare failures in practice, while the vast majority of observed failures are caused by a tiny proportion of the latent faults. Adams observed a remarkably similar distribution of such ....

....Pericone finding. In release n 1 it is clear that the smallest modules have the highest fault density. However, the fault density is very similar for the other groups. For release n the result is the opposite of what was reported by Basili and Perricone. The approach to grouping data as done in [Basili and Perricone 1984] is highly misleading. What Basili and Pericone failed to show was a simple plot of fault density against module size, as we have done in Figure 9 for release n 1. Even though the grouped data for this release appeared to support the Basili and Pericone findings, this graph shows only a very high ....

[Article contains additional citation context not shown here]

Basili VR and Perricone BT, `Software Errors and Complexity: An Empirical Investigation', Communications of the ACM 27(1), pp. 42-52, 1984.

.... 1981; 1987) One study found a strong positive relationship between software system errors and errors identified in requirements specifications (Davis 1989) In addition, other authors found that the requirements engineering phase is the source of the majority of detected software code errors (Basili and Perricone 1984; Endres 1975; Jones 1994; Rubey et al. 1975) During our case study, we collected data on the success of the requirements engineering process for one project in each assessed organization. Each of the respondents was requested to assess the success of the requirements engineering process for a ....

Basili, V. and Perricone, B. 1984. Software errors and complexity: An empirical investigation.

....uses a new process, the defect profile of that project can be compared to the baseline, and these measurements will help members of the SEL determine whether or not the process change was effective. By 1984, The SEL had already developed a classification scheme used by projects throughout the lab [BasiliPerricone84]. The engineer identifying the error was responsible for classifying it in one of Basili and Perricone s categories: Requirements incorrect or misinterpreted . Functional specification incorrect or misinterpreted . A Design error which spans several modules . A Design error or an implementation ....

Basili, Victor R., and Barry T. Perricone (1984). "Software Errors and Complexity: An Empirical Investigation." Communications of the ACM, 27(1) (January):42-52.

No context found.

Basili, Victor R. and Perricone, Barry T. Software errors and complexity: An empirical investigation. Communications of the ACM, Vol. 27, No. 1, 1984.

No context found.

Basili, Victor R. and Perricone, Barry T. Software errors and complexity: An empirical investigation. Communications of the ACM, Vol. 27, No. 1, 1984.

No context found.

Victor R. Basili and B.T. Perricone. Software errors and complexity: An empirical investigation. Communications of the ACM, 27(1):42--52, January 1984.

No context found.

Basili, V. and Perricone, B. (1984) `Software errors and complexity: an empirical investigation', Communications of the ACM, 27(1), 42--52.

No context found.

Victor R. Basili and B.T. Perricone. Software errors and complexity: An empirical investigation. Communications of the ACM, 27(1):42--52, January 1984.

No context found.

V.R. Basili, B.T. Perricone. Software Errors and Complexity: An Empirical Investigation. Communications of the ACM, January 1984, pp. 42-52.

No context found.

Basili, V. R., and Perricone, B. T. "Software Errors and Complexity: An Empirical Investigation," Communications of the ACM, January 1984, Vol. 27, No. 1.

First 50 documents  Next 50

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