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.

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