73,643 research outputs found

    Effect of Introduction of Fault and Imperfect Debugging on Release Time

    Get PDF
    One of the most important decisions related to the efficient management of testing phase of software development life cycle is to determine when to stop testing and release the software in the market. Most of the testing processes are imperfect once. In this paper first we have discussed an optimal release time problem for an imperfect faultdebugging model due to Kapur et al considering effect of perfect and imperfect debugging separately on the total expected software cost. Next, we proposed a SRGM incorporating the effect of imperfect fault debugging and error generation. The proposed model is validated on a data set cited in literature and a release time problem is formulated minimizing the expected cost subject to a minimum reliability level to be achieved by the release time using the proposed model. Solution method is discussed to solve such class of problem. A numerical illustration is given for both type of release problem and finally a sensitivity analysis is performed

    Mathematical Modeling of Software Bug Complexity

    Get PDF
    During testing of software, most of the bugs lying dormant in the software gets uncovered once the test cases are executed. Different bugs may take different amounts of effort and expertise for their removal. To understand the complexity of bugs from a developer‟s perspective, researchers have developed different mathematical models. Software consists of two types of bugs, dependent and independent. Dependent bugs are those whose removal depends upon the removal of some other bugs on which it is dependent. Dependency of bugs also makes the bug complex and bugs will take more time during fixing. Different debugging time lags functions have been taken to model different complexity of bugs. The aim of this paper is to study the bugs of different complexity. The complexity of bugs has been also modeled using dependency concept. Testing effort dependent bug complexity model using fault dependency has been also discussed. We also feel that that more complex bug will take more time and less complex bug will take less time during fixing. During removal of bugs, the removal team gets more familiar with the code during the fixing. The learning effect during testing has been incorporated using logistic removal rate. The models are validated based on different comparison criteria namely MSE, R2 , Bias, Variation and Root mean squared error.Keywords/Index Terms: Non-homogeneous Poisson process, bug complexity, bugs types

    Software reliability perspectives

    Get PDF
    Software which is used in life critical functions must be known to be highly reliable before installation. This requires a strong testing program to estimate the reliability, since neither formal methods, software engineering nor fault tolerant methods can guarantee perfection. Prior to the final testing software goes through a debugging period and many models have been developed to try to estimate reliability from the debugging data. However, the existing models are poorly validated and often give poor performance. This paper emphasizes the fact that part of their failures can be attributed to the random nature of the debugging data given to these models as input, and it poses the problem of correcting this defect as an area of future research

    Design de fiabilidade bidimensional do software de múltiplos lançamentos tendo em conta o fator de redução de falhas na depuração imperfeita

    Get PDF
    Introduction: The present research was conducted at the University of Delhi, India in 2017. Methods: We develop a software reliability growth model to assess the reliability of software products released in multiple versions under limited availability of resources and time. The Fault Reduction Factor (frf) is considered to be constant in imperfect debugging environments while the rate of fault removal is given by Delayed S-Shaped model. Results: The proposed model has been validated on a real life four-release dataset by carrying out goodness of fit analysis. Laplace trend analysis was also conducted to judge the trend exhibited by data with respect to change in the system’s reliability. Conclusions: A number of comparison criteria have been calculated to evaluate the performance of the proposed model relative to only time-based multi-release Software Reliability Growth Model (srgm). Originality: In general, the number of faults removed is not the same as the number of failures experienced in given time intervals, so the inclusion of frf in the model makes it better and more realistic. A paradigm shift has been observed in software development from single release to multi release platform. Limitations: The proposed model can be used by software developers to take decisions regarding the release time for different versions, by either minimizing the development cost or maximizing the reliability and determining the warranty policies.Introducción: la presente investigación se realizó en la Universidad de Delhi, India en 2017. Métodos: desarrollamos un modelo de crecimiento de confiabilidad de software para evaluar la confiabilidad de los productos de software lanzados en múltiples versiones bajo disponibilidad limitada de recursos y tiempo. El factor de reducción de fallas (frf) se considera una constante en entornos de depuración imperfecta, mientras que la tasa de eliminación de fallas está dada por el modelo de forma retardada en S. Resultados: se valida el modelo propuesto en un conjunto de datos de cuatro lanzamientos de la vida real mediante un análisis de bondad de ajuste. También se aplicó el análisis de tendencia de Laplace para juzgar la tendencia que presentan los datos con respecto al cambio en la confiabilidad del sistema. Conclusiones: se calculó una serie de criterios de comparación para evaluar el rendimiento del modelo propuesto en relación con el modelo de crecimiento de confiabilidad del software (srgm) de múltiples lanzamientos basado únicamente en el tiempo. Originalidad: en general, el número de fallas eliminadas no es el mismo que el número de fallas experimentadas en intervalos de tiempo determinados, por lo que la inclusión de frf en el modelo lo mejora y lo hace más realista. Se ha observado un cambio de paradigma en el desarrollo de software, que pasa de un lanzamiento único a una plataforma múltiples lanzamientos. Limitaciones: los desarrolladores de software pueden emplear el modelo propuesto para tomar decisiones con respecto al tiempo de lanzar diferentes versiones, ya sea minimizando el costo de desarrollo o maximizando la confiabilidad y determinando las políticas de la garantía.Introdução: esta pesquisa foi realizada na Universidade de Deli, na Índia, em 2017. Métodos: desenvolvemos um modelo de crescimento de confiabilidade de software para avaliar a confiabilidade dos produtos de software lançados em múltiplas versões sob disponibilidade limitada de recursos e tempo. O fator de redução de falhas (frf) é considerado uma constante em contextos de depuração imperfeita, enquanto a taxa de eliminação de falhas é dada pelo modelo de forma retardada em S.Resultados: o modelo proposto é avaliado em um conjunto de dados de quatro lançamentos da vida real mediante uma análise de bondade de ajuste. Também foi utilizada a análise de tendência de Laplace para avaliar a tendência apresentada pelos dados com respeito à mudança na confiabilidade do sistema.Conclusões: uma série de critérios de comparação foi calculada para avaliar o rendimento do modelo proposto em relação com o modelo de crescimento de confiabilidade do software (srgm) de múltiplos lançamentos baseado unicamente no tempo.Originalidade: em geral, o número de falhas eliminadas não é o mesmo que o número de falhas existentes em intervalos de tempo determinados, sendo assim, a inclusão do frf no modelo o torna melhor e mais realista. Foi observada uma mudança de paradigma no desenvolvimento de software, que passa de um lançamento único a uma plataforma de múltiplos lançamentos.Limitações: o modelo proposto pode ser utilizado pelos desenvolvedores de software para tomar decisões com respeito ao tempo de lançar diferentes versões, seja para minimizar o custo de desenvolvimento ou maximizar a confiabilidade e determinar as políticas de garantia

    Statistical modelling of software reliability

    Get PDF
    During the six-month period from 1 April 1991 to 30 September 1991 the following research papers in statistical modeling of software reliability appeared: (1) A Nonparametric Software Reliability Growth Model; (2) On the Use and the Performance of Software Reliability Growth Models; (3) Research and Development Issues in Software Reliability Engineering; (4) Special Issues on Software; and (5) Software Reliability and Safety

    Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle

    Full text link
    Many practitioners and academics believe in a delayed issue effect (DIE); i.e. the longer an issue lingers in the system, the more effort it requires to resolve. This belief is often used to justify major investments in new development processes that promise to retire more issues sooner. This paper tests for the delayed issue effect in 171 software projects conducted around the world in the period from 2006--2014. To the best of our knowledge, this is the largest study yet published on this effect. We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction. This paper documents the above study and explores reasons for this mismatch between this common rule of thumb and empirical data. In summary, DIE is not some constant across all projects. Rather, DIE might be an historical relic that occurs intermittently only in certain kinds of projects. This is a significant result since it predicts that new development processes that promise to faster retire more issues will not have a guaranteed return on investment (depending on the context where applied), and that a long-held truth in software engineering should not be considered a global truism.Comment: 31 pages. Accepted with minor revisions to Journal of Empirical Software Engineering. Keywords: software economics, phase delay, cost to fi
    corecore