The Experts below are selected from a list of 327 Experts worldwide ranked by ideXlab platform
Thomas Ball - One of the best experts on this subject based on the ideXlab platform.
-
ICSE - Static analysis tools as early indicators of pre-release Defect Density
Proceedings of the 27th international conference on Software engineering - ICSE '05, 2005Co-Authors: Nachiappan Nagappan, Thomas BallAbstract:During software development it is helpful to obtain early estimates of the Defect Density of software components. Such estimates identify fault-prone areas of code requiring further testing. We present an empirical approach for the early prediction of pre-release Defect Density based on the Defects found using static analysis tools. The Defects identified by two different static analysis tools are used to fit and predict the actual pre-release Defect Density for Windows Server 2003. We show that there exists a strong positive correlation between the static analysis Defect Density and the pre-release Defect Density determined by testing. Further, the predicted pre-release Defect Density and the actual pre-release Defect Density are strongly correlated at a high degree of statistical significance. Discriminant analysis shows that the results of static analysis tools can be used to separate high and low quality components with an overall classification rate of 82.91%.
-
static analysis tools as early indicators of pre release Defect Density
International Conference on Software Engineering, 2005Co-Authors: Nachiappan Nagappan, Thomas BallAbstract:During software development it is helpful to obtain early estimates of the Defect Density of software components. Such estimates identify fault-prone areas of code requiring further testing. We present an empirical approach for the early prediction of pre-release Defect Density based on the Defects found using static analysis tools. The Defects identified by two different static analysis tools are used to fit and predict the actual pre-release Defect Density for Windows Server 2003. We show that there exists a strong positive correlation between the static analysis Defect Density and the pre-release Defect Density determined by testing. Further, the predicted pre-release Defect Density and the actual pre-release Defect Density are strongly correlated at a high degree of statistical significance. Discriminant analysis shows that the results of static analysis tools can be used to separate high and low quality components with an overall classification rate of 82.91%.
-
ICSE - Use of relative code churn measures to predict system Defect Density
Proceedings of the 27th international conference on Software engineering - ICSE '05, 2005Co-Authors: Nachiappan Nagappan, Thomas BallAbstract:Software systems evolve over time due to changes in requirements, optimization of code, fixes for security and reliability bugs etc. Code churn, which measures the changes made to a component over a period of time, quantifies the extent of this change. We present a technique for early prediction of system Defect Density using a set of relative code churn measures that relate the amount of churn to other variables such as component size and the temporal extent of churn. Using statistical regression models, we show that while absolute measures of code chum are poor predictors of Defect Density, our set of relative measures of code churn is highly predictive of Defect Density. A case study performed on Windows Server 2003 indicates the validity of the relative code churn measures as early indicators of system Defect Density. Furthermore, our code churn metric suite is able to discriminate between fault and not fault-prone binaries with an accuracy of 89.0 percent.
-
Use of relative code churn measures to predict system Defect Density
Proceedings of the 27th international conference on Software engineering - ICSE '05, 2005Co-Authors: Nachiappan Nagappan, Thomas BallAbstract:Software systems evolve over time due to changes in requirements, optimization of code, fixes for security and reliability bugs etc. Code churn, which measures the changes made to a component over a period of time, quantifies the extent of this change. We present a technique for early prediction of system Defect Density using a set of relative code churn measures that relate the amount of churn to other variables such as component size and the temporal extent of churn.Using statistical regression models, we show that while absolute measures of code churn are poor predictors of Defect Density, our set of relative measures of code churn is highly predictive of Defect Density. A case study performed on Windows Server 2003 indicates the validity of the relative code churn measures as early indicators of system Defect Density. Furthermore, our code churn metric suite is able to discriminate between fault and not fault-prone binaries with an accuracy of 89.0 percent.
Nachiappan Nagappan - One of the best experts on this subject based on the ideXlab platform.
-
A-MOST - Early estimation of Defect Density using an in-process Haskell metrics model
ACM SIGSOFT Software Engineering Notes, 2005Co-Authors: Mark Sherriff, Nachiappan Nagappan, Laurie Williams, Mladen A. VoukAbstract:Early estimation of Defect Density of a product is an important step towards the remediation of the problem associated with affordably guiding corrective actions in the software development process. This paper presents a suite of in-process metrics that leverages the software testing effort to create a Defect Density prediction model for use throughout the software development process. A case study conducted with Galois Connections, Inc. in a Haskell programming environment indicates that the resulting Defect Density prediction is indicative of the actual system Defect Density.
-
ICSE - Static analysis tools as early indicators of pre-release Defect Density
Proceedings of the 27th international conference on Software engineering - ICSE '05, 2005Co-Authors: Nachiappan Nagappan, Thomas BallAbstract:During software development it is helpful to obtain early estimates of the Defect Density of software components. Such estimates identify fault-prone areas of code requiring further testing. We present an empirical approach for the early prediction of pre-release Defect Density based on the Defects found using static analysis tools. The Defects identified by two different static analysis tools are used to fit and predict the actual pre-release Defect Density for Windows Server 2003. We show that there exists a strong positive correlation between the static analysis Defect Density and the pre-release Defect Density determined by testing. Further, the predicted pre-release Defect Density and the actual pre-release Defect Density are strongly correlated at a high degree of statistical significance. Discriminant analysis shows that the results of static analysis tools can be used to separate high and low quality components with an overall classification rate of 82.91%.
-
static analysis tools as early indicators of pre release Defect Density
International Conference on Software Engineering, 2005Co-Authors: Nachiappan Nagappan, Thomas BallAbstract:During software development it is helpful to obtain early estimates of the Defect Density of software components. Such estimates identify fault-prone areas of code requiring further testing. We present an empirical approach for the early prediction of pre-release Defect Density based on the Defects found using static analysis tools. The Defects identified by two different static analysis tools are used to fit and predict the actual pre-release Defect Density for Windows Server 2003. We show that there exists a strong positive correlation between the static analysis Defect Density and the pre-release Defect Density determined by testing. Further, the predicted pre-release Defect Density and the actual pre-release Defect Density are strongly correlated at a high degree of statistical significance. Discriminant analysis shows that the results of static analysis tools can be used to separate high and low quality components with an overall classification rate of 82.91%.
-
ICSE - Use of relative code churn measures to predict system Defect Density
Proceedings of the 27th international conference on Software engineering - ICSE '05, 2005Co-Authors: Nachiappan Nagappan, Thomas BallAbstract:Software systems evolve over time due to changes in requirements, optimization of code, fixes for security and reliability bugs etc. Code churn, which measures the changes made to a component over a period of time, quantifies the extent of this change. We present a technique for early prediction of system Defect Density using a set of relative code churn measures that relate the amount of churn to other variables such as component size and the temporal extent of churn. Using statistical regression models, we show that while absolute measures of code chum are poor predictors of Defect Density, our set of relative measures of code churn is highly predictive of Defect Density. A case study performed on Windows Server 2003 indicates the validity of the relative code churn measures as early indicators of system Defect Density. Furthermore, our code churn metric suite is able to discriminate between fault and not fault-prone binaries with an accuracy of 89.0 percent.
-
Use of relative code churn measures to predict system Defect Density
Proceedings of the 27th international conference on Software engineering - ICSE '05, 2005Co-Authors: Nachiappan Nagappan, Thomas BallAbstract:Software systems evolve over time due to changes in requirements, optimization of code, fixes for security and reliability bugs etc. Code churn, which measures the changes made to a component over a period of time, quantifies the extent of this change. We present a technique for early prediction of system Defect Density using a set of relative code churn measures that relate the amount of churn to other variables such as component size and the temporal extent of churn.Using statistical regression models, we show that while absolute measures of code churn are poor predictors of Defect Density, our set of relative measures of code churn is highly predictive of Defect Density. A case study performed on Windows Server 2003 indicates the validity of the relative code churn measures as early indicators of system Defect Density. Furthermore, our code churn metric suite is able to discriminate between fault and not fault-prone binaries with an accuracy of 89.0 percent.
Jason Denton - One of the best experts on this subject based on the ideXlab platform.
-
module size distribution and Defect Density
International Symposium on Software Reliability Engineering, 2000Co-Authors: Y K Malaiya, Jason DentonAbstract:Data from several projects show a significant relationship between the size of a module and its Defect Density. We address implications of this observation. Does the overall Defect Density of a software project vary with its module size distribution? Even more interesting is the question can we exploit this dependence to reduce the total number of Defects? We examine the available data sets and propose a model relating module size and Defect Density. It takes into account Defects that arise due to the interconnections among the modules as well as Defects that occur due to the complexity of individual modules. Model parameters are estimated using actual data. We then present a key observation that allows use of this model for not just estimation of the Defect Density, but also potentially optimizing a design to minimize Defects. This observation, supported by several data sets examined, is that the module sizes often follow exponential distribution. We show how the two models used together provide a way of projecting Defect Density variation. We also consider the possibility of minimizing the Defect Density by controlling module size distribution.
-
ISSRE - Module size distribution and Defect Density
Proceedings 11th International Symposium on Software Reliability Engineering. ISSRE 2000, 2000Co-Authors: Y K Malaiya, Jason DentonAbstract:Data from several projects show a significant relationship between the size of a module and its Defect Density. We address implications of this observation. Does the overall Defect Density of a software project vary with its module size distribution? Even more interesting is the question can we exploit this dependence to reduce the total number of Defects? We examine the available data sets and propose a model relating module size and Defect Density. It takes into account Defects that arise due to the interconnections among the modules as well as Defects that occur due to the complexity of individual modules. Model parameters are estimated using actual data. We then present a key observation that allows use of this model for not just estimation of the Defect Density, but also potentially optimizing a design to minimize Defects. This observation, supported by several data sets examined, is that the module sizes often follow exponential distribution. We show how the two models used together provide a way of projecting Defect Density variation. We also consider the possibility of minimizing the Defect Density by controlling module size distribution.
-
requirements volatility and Defect Density
International Symposium on Software Reliability Engineering, 1999Co-Authors: Y K Malaiya, Jason DentonAbstract:Ideally the requirements for a software system should be completely and unambiguously determined before design, coding and testing rake place. In practice, often there are changes in the requirements, causing software components to be redesigned, deleted or added. This requirements volatility causes the software to have a higher Defect Density. In this paper we analytically examine the influence of requirement changes taking place during different times by examining the consequences of software additions, removals and modifications. We take into account interface Defects which arise due to errors at the interfaces among software sections. We compare the resulting Defect Density in the presence of requirement volatility, with the Defect Density that would have resulted had requirements not changed. The results show that if the requirement changes take place close to the release date, there is a greater impact on Defect Density. In each case we compute the Defect equivalence factor representing the overall impact of requirement volatility.
-
ISSRE - Requirements volatility and Defect Density
Proceedings 10th International Symposium on Software Reliability Engineering (Cat. No.PR00443), 1999Co-Authors: Y K Malaiya, Jason DentonAbstract:Ideally the requirements for a software system should be completely and unambiguously determined before design, coding and testing rake place. In practice, often there are changes in the requirements, causing software components to be redesigned, deleted or added. This requirements volatility causes the software to have a higher Defect Density. In this paper we analytically examine the influence of requirement changes taking place during different times by examining the consequences of software additions, removals and modifications. We take into account interface Defects which arise due to errors at the interfaces among software sections. We compare the resulting Defect Density in the presence of requirement volatility, with the Defect Density that would have resulted had requirements not changed. The results show that if the requirement changes take place close to the release date, there is a greater impact on Defect Density. In each case we compute the Defect equivalence factor representing the overall impact of requirement volatility.
-
Estimating Defect Density Using Test Coverage
1999Co-Authors: Y K Malaiya, Jason DentonAbstract:Defect Density is one of the most important factors that allow one to decide if a piece of software is ready to be released. In theory, one can find all the Defects and count them, however it is impossible to find all the Defects within any reasonable amount of time. Estimating Defect Density can become difficult for high reliability software, since the remaining Defects can be extremely hard to test. Defect seeding will work only if the distribution of seeded Defects is similar to the existing Defects. One possible way is to apply the exponential SRGM and thus estimate the total number of Defects present at the beginning of testing. Here we show the problems with this approach and present a new approach based on software test coverage. Software test coverage directly measures the thoroughness of testing avoiding the problem of variations of test effectiveness. Here we present interpretations of the parameters of the coverageDefect-Density model presented by Malaiya et al. We apply this model to actual test data to project the residual Defect Density. The results show that this method results in estimates that are more stable than the existing methods. This method is easier to understand and the convergence to the estimate can be visually observed.
Y K Malaiya - One of the best experts on this subject based on the ideXlab platform.
-
module size distribution and Defect Density
International Symposium on Software Reliability Engineering, 2000Co-Authors: Y K Malaiya, Jason DentonAbstract:Data from several projects show a significant relationship between the size of a module and its Defect Density. We address implications of this observation. Does the overall Defect Density of a software project vary with its module size distribution? Even more interesting is the question can we exploit this dependence to reduce the total number of Defects? We examine the available data sets and propose a model relating module size and Defect Density. It takes into account Defects that arise due to the interconnections among the modules as well as Defects that occur due to the complexity of individual modules. Model parameters are estimated using actual data. We then present a key observation that allows use of this model for not just estimation of the Defect Density, but also potentially optimizing a design to minimize Defects. This observation, supported by several data sets examined, is that the module sizes often follow exponential distribution. We show how the two models used together provide a way of projecting Defect Density variation. We also consider the possibility of minimizing the Defect Density by controlling module size distribution.
-
ISSRE - Module size distribution and Defect Density
Proceedings 11th International Symposium on Software Reliability Engineering. ISSRE 2000, 2000Co-Authors: Y K Malaiya, Jason DentonAbstract:Data from several projects show a significant relationship between the size of a module and its Defect Density. We address implications of this observation. Does the overall Defect Density of a software project vary with its module size distribution? Even more interesting is the question can we exploit this dependence to reduce the total number of Defects? We examine the available data sets and propose a model relating module size and Defect Density. It takes into account Defects that arise due to the interconnections among the modules as well as Defects that occur due to the complexity of individual modules. Model parameters are estimated using actual data. We then present a key observation that allows use of this model for not just estimation of the Defect Density, but also potentially optimizing a design to minimize Defects. This observation, supported by several data sets examined, is that the module sizes often follow exponential distribution. We show how the two models used together provide a way of projecting Defect Density variation. We also consider the possibility of minimizing the Defect Density by controlling module size distribution.
-
requirements volatility and Defect Density
International Symposium on Software Reliability Engineering, 1999Co-Authors: Y K Malaiya, Jason DentonAbstract:Ideally the requirements for a software system should be completely and unambiguously determined before design, coding and testing rake place. In practice, often there are changes in the requirements, causing software components to be redesigned, deleted or added. This requirements volatility causes the software to have a higher Defect Density. In this paper we analytically examine the influence of requirement changes taking place during different times by examining the consequences of software additions, removals and modifications. We take into account interface Defects which arise due to errors at the interfaces among software sections. We compare the resulting Defect Density in the presence of requirement volatility, with the Defect Density that would have resulted had requirements not changed. The results show that if the requirement changes take place close to the release date, there is a greater impact on Defect Density. In each case we compute the Defect equivalence factor representing the overall impact of requirement volatility.
-
ISSRE - Requirements volatility and Defect Density
Proceedings 10th International Symposium on Software Reliability Engineering (Cat. No.PR00443), 1999Co-Authors: Y K Malaiya, Jason DentonAbstract:Ideally the requirements for a software system should be completely and unambiguously determined before design, coding and testing rake place. In practice, often there are changes in the requirements, causing software components to be redesigned, deleted or added. This requirements volatility causes the software to have a higher Defect Density. In this paper we analytically examine the influence of requirement changes taking place during different times by examining the consequences of software additions, removals and modifications. We take into account interface Defects which arise due to errors at the interfaces among software sections. We compare the resulting Defect Density in the presence of requirement volatility, with the Defect Density that would have resulted had requirements not changed. The results show that if the requirement changes take place close to the release date, there is a greater impact on Defect Density. In each case we compute the Defect equivalence factor representing the overall impact of requirement volatility.
-
Estimating Defect Density Using Test Coverage
1999Co-Authors: Y K Malaiya, Jason DentonAbstract:Defect Density is one of the most important factors that allow one to decide if a piece of software is ready to be released. In theory, one can find all the Defects and count them, however it is impossible to find all the Defects within any reasonable amount of time. Estimating Defect Density can become difficult for high reliability software, since the remaining Defects can be extremely hard to test. Defect seeding will work only if the distribution of seeded Defects is similar to the existing Defects. One possible way is to apply the exponential SRGM and thus estimate the total number of Defects present at the beginning of testing. Here we show the problems with this approach and present a new approach based on software test coverage. Software test coverage directly measures the thoroughness of testing avoiding the problem of variations of test effectiveness. Here we present interpretations of the parameters of the coverageDefect-Density model presented by Malaiya et al. We apply this model to actual test data to project the residual Defect Density. The results show that this method results in estimates that are more stable than the existing methods. This method is easier to understand and the convergence to the estimate can be visually observed.
Michel R V Chaudron - One of the best experts on this subject based on the ideXlab platform.
-
The impact of UML modeling on Defect Density and Defect resolution time in a proprietary system
Empirical Software Engineering, 2014Co-Authors: Ariadi Nugroho, Michel R V ChaudronAbstract:Background : The contribution of modeling in software development has been a subject of debates. The proponents of model-driven development argue that a big upfront modeling requires substantial investment, but it will payoff later in the implementation phase in terms of increased productivity and quality. Other software engineers perceive modeling activity as a waste of time and money without any real contribution to the final software product. Considering present advancement of model-based software development in software industry, we are challenged to investigate the real contribution of modeling in software development. Objective : We analyze the impacts of UML modeling, specifically the production of class and sequence diagrams, on the quality of the code, as measured by Defect Density, and on Defect resolution time. Method : Using data of a proprietary system, we conduct post-mortem analyses to test the difference in Defect Density between software modules that are modeled and not modeled. Similarly, we test the difference in resolution time between Defects that are related to modeled and not modeled functionality. Result : We have found that the production of UML class diagrams and sequence diagrams reduces Defect Density in the code and the time required to fix Defects. These results are obtained after controlling for the effects of co-factors such as code coupling and complexity. Conclusion : The results confirm that not only does the production of UML class diagrams and sequence diagrams possibly help improve the quality of software, but also it possibly help increase the productivity in software maintenance.
-
empirical analysis of the relation between level of detail in uml models and Defect Density
Model Driven Engineering Languages and Systems, 2008Co-Authors: Ariadi Nugroho, Bas Flaton, Michel R V ChaudronAbstract:This paper investigates the relation between the level of detail (LoD) in UML models and Defect Density of the associated implementation. We propose LoD measures that are applicable to both class- and sequence diagrams. Based on empirical data from an industrial software project we have found that classes with higher LoD, calculated using sequence diagram LoD metrics, correlates with lower Defect Density. Overall, this paper discusses a novel and practical approach to measure LoD in UML models and describes its application to a significant industrial case study.
