{"title":"数学模型和软件可靠性不同的数学是否适合软件生命周期的所有阶段?","authors":"M. Krasich","doi":"10.1109/RAM.2017.7889761","DOIUrl":null,"url":null,"abstract":"Software reliability, its predictions and data analyses are mostly based on the number of faults; therefore fault mitigation and reliability growth achieved by mitigation of number of faults. The usual results are the final failure frequency of the delivered mature software. The early reliability prediction is needed at the beginning of the development phase to estimate reliability of the software and its effect of the product it is a part of. Since the discrete number of faults are expected to be observed and mitigated, the non-homogenous Poisson probability distribution comes as the preferred mathematical tool. In the case where during development process no reliability growth was achieved, the same mathematics would just yield parameters which would indicate no reliability changes or, in the worst case, reliability degradation (the growth parameter equal or greater than one). Krasich-Peterson model (patent pending) and Musa original model when used for early predictions are very similar except the first assumes power law fitting of the mitigated faults, whilst the latter model assumes constant rate of failure mitigation. Since the early reliability predictions use assumptions for function parameters derived from quality level of the software inspection, testing, and improvement process and also on the software size, complexity, its use profile, the single way of validating those assumptions and the parameters derived from them is to apply the same mathematics to the reliability estimation of software for early predictions covering its lifecycle. Regardless of what mathematical model is applied, for continuity and for meaningful conclusions and decisions regarding software reliability as well as the future use of such information on other projects, one method type of counting (discrete) distribution should be applied in the same organization throughout the software lifecycle. An additional benefit of such consistency is the ability to compare not only software development and use phases but to compare the different software development and quality and test practices.","PeriodicalId":138871,"journal":{"name":"2017 Annual Reliability and Maintainability Symposium (RAMS)","volume":"1112 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"2","resultStr":"{\"title\":\"Mathematical models and software reliability can different mathematics fit all phases of SW lifecycle?\",\"authors\":\"M. Krasich\",\"doi\":\"10.1109/RAM.2017.7889761\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Software reliability, its predictions and data analyses are mostly based on the number of faults; therefore fault mitigation and reliability growth achieved by mitigation of number of faults. The usual results are the final failure frequency of the delivered mature software. The early reliability prediction is needed at the beginning of the development phase to estimate reliability of the software and its effect of the product it is a part of. Since the discrete number of faults are expected to be observed and mitigated, the non-homogenous Poisson probability distribution comes as the preferred mathematical tool. In the case where during development process no reliability growth was achieved, the same mathematics would just yield parameters which would indicate no reliability changes or, in the worst case, reliability degradation (the growth parameter equal or greater than one). Krasich-Peterson model (patent pending) and Musa original model when used for early predictions are very similar except the first assumes power law fitting of the mitigated faults, whilst the latter model assumes constant rate of failure mitigation. Since the early reliability predictions use assumptions for function parameters derived from quality level of the software inspection, testing, and improvement process and also on the software size, complexity, its use profile, the single way of validating those assumptions and the parameters derived from them is to apply the same mathematics to the reliability estimation of software for early predictions covering its lifecycle. Regardless of what mathematical model is applied, for continuity and for meaningful conclusions and decisions regarding software reliability as well as the future use of such information on other projects, one method type of counting (discrete) distribution should be applied in the same organization throughout the software lifecycle. An additional benefit of such consistency is the ability to compare not only software development and use phases but to compare the different software development and quality and test practices.\",\"PeriodicalId\":138871,\"journal\":{\"name\":\"2017 Annual Reliability and Maintainability Symposium (RAMS)\",\"volume\":\"1112 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"1900-01-01\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"2\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"2017 Annual Reliability and Maintainability Symposium (RAMS)\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/RAM.2017.7889761\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"2017 Annual Reliability and Maintainability Symposium (RAMS)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/RAM.2017.7889761","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Mathematical models and software reliability can different mathematics fit all phases of SW lifecycle?
Software reliability, its predictions and data analyses are mostly based on the number of faults; therefore fault mitigation and reliability growth achieved by mitigation of number of faults. The usual results are the final failure frequency of the delivered mature software. The early reliability prediction is needed at the beginning of the development phase to estimate reliability of the software and its effect of the product it is a part of. Since the discrete number of faults are expected to be observed and mitigated, the non-homogenous Poisson probability distribution comes as the preferred mathematical tool. In the case where during development process no reliability growth was achieved, the same mathematics would just yield parameters which would indicate no reliability changes or, in the worst case, reliability degradation (the growth parameter equal or greater than one). Krasich-Peterson model (patent pending) and Musa original model when used for early predictions are very similar except the first assumes power law fitting of the mitigated faults, whilst the latter model assumes constant rate of failure mitigation. Since the early reliability predictions use assumptions for function parameters derived from quality level of the software inspection, testing, and improvement process and also on the software size, complexity, its use profile, the single way of validating those assumptions and the parameters derived from them is to apply the same mathematics to the reliability estimation of software for early predictions covering its lifecycle. Regardless of what mathematical model is applied, for continuity and for meaningful conclusions and decisions regarding software reliability as well as the future use of such information on other projects, one method type of counting (discrete) distribution should be applied in the same organization throughout the software lifecycle. An additional benefit of such consistency is the ability to compare not only software development and use phases but to compare the different software development and quality and test practices.