Economic Impact of Software Patching and Optimal Release Scheduling

Anand, Adarsh; Agarwal, Mohini; Tamura, Yoshinobu; Yamada, Shigeru

doi:10.1002/qre.1997

Cited by 25 publications

(13 citation statements)

References 33 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…where a = a. [1 − F (τ )] Using equation (1) and (3) the total number of faults debugged throughout the testing process can be modeled as follows:…”

Section: Model Buildingmentioning

confidence: 99%

“…In these circumstances, patching can help the software firms in releasing a pre-mature product which can undergo continual testing once the product is in operational phase. Patch is generally a small set of corrective code released during the operational phase of software to fix the bugs or to update them [1]. The earliest version of a patch was in the form of paper tape/punched cards.…”

Section: Introductionmentioning

confidence: 99%

“…Anand et al [6] have also studied the role of tester and user in finding both faults and vulnerabilities, and hence proposed a patch release policy for the same. Anand et al [1] proposed an economic cost analysis of software based on patching. They proposed a scheduling policy for a software product and showed the importance of patching in lowering the system outages and making the system more cost effective.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Measuring software reliability under the influence of an infected patch

Kaur

Anand

Singh

et al. 2021

YUGOSLAV J OPERATION

Self Cite

View full text Add to dashboard Cite

Patching service provides software firms an option to deal with the leftover bugs and is thereby helping them to keep a track of their product. More and more software firms are making use of this concept of prolonged testing. But this framework of releasing unprepared software in market involves a huge risk. The hastiness of vendors in releasing software patch at times can be dangerous as there are chances that firms release an infected patch. The infected patch (es) might lead to a hike in bug occurrence and error count and might make the software more vulnerable. The current work presents an understanding of such situation through mathematical modeling framework; wherein, the distinct behavior of testers (during in-house testing and field testing) and users is described. The proposed model has been validated on two software failure data sets of Tandem Computers and Brazilian Electronic Switching System, TROPICO R-1500.

show abstract

“…where a = a. [1 − F (τ )] Using equation (1) and (3) the total number of faults debugged throughout the testing process can be modeled as follows:…”

Section: Model Buildingmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Measuring software reliability under the influence of an infected patch

Kaur

Anand

Singh

et al. 2021

YUGOSLAV J OPERATION

Self Cite

View full text Add to dashboard Cite

show abstract

“…Kapur proposed a release planning model to obtain the optimal time and effort required for software development by minimizing the cost of development. Optimization problems for release time were discussed by Kumar, Kapur, Shrivastava and Sharma [51], Lyu [52], Pham [53], Anand, Agarwal, Tamura and Yamada [54], Xie [55]. Ehrlich, Prasanna, Stampfel and Wu [56] determined the cost involved in testing.…”

Section: Optimal Release Policymentioning

confidence: 99%

Testing Resource based Optimal Release Policy for Software System Incorporating Fault Reduction Factor and Change point

Arora,

Tandon,

Aggarwal

et al. 2019

IJRTE

View full text Add to dashboard Cite

In today’s competitive scenario, it is essential for software developers to perform rigorous testing. It helps them to satisfy the demand for reliable software systems. Various external and internal factors like human expertise, fault dependency, code complexity, dynamic approaches etc. affect the process of fault removal. Hence, along the time-line fault removal rate may change. The point on time-line beyond which rates are altered is termed as the change point. Also in many practical situations, the number of failures experienced may not coincide with the number of faults removed from the system. This ratio is computed by Fault Reduction Factor (FRF). Here, we have proposed testing effort based model considering effort-dependent FRF with and without change point for gauging the failure pattern of a software system. The FRF has been modelled by logistic curve. The developed models have been verified using real-life software fault datasets. Model parameters are estimated and various performance criteria are employed to check the goodness of fit. Later, we have developed a software cost model to determine the optimal Release testing effort that minimizes total expected cost of fault removal during testing phase and operational phase of software life cycle subject to a reliability constraint. A numerical study has been also taken to demonstrate the results. Cost sensitivity analysis has been carried out to identify the crucial cost component and role of each cost component on optimal testing effort and overall cost of development.

show abstract

“…Their model is further extended by Tickoo et al (2016) by proposing resource-based optimal release and patching time of software. Anand et al (2017) also developed a cost model to see the impact of patching on software release and testing stop time decision. Majumdar et al (2017) applied multiattribute utility theory on cost and reliability to determine optimal release and testing stop time of software.…”

Section: Introductionmentioning

confidence: 99%

Generalized software release and testing stop time policy

Shrivastava

Sachdeva²

2019

IJQRM

View full text Add to dashboard Cite

Purpose Almost everything around us is the output of software-driven machines or working with software. Software firms are working hard to meet the user’s requirements. But developing a fault-free software is not possible. Also due to market competition, firms do not want to delay their software release. But early release software comes with the problem of user reporting more failures during operations due to more number of faults lying in it. To overcome the above situation, software firms these days are releasing software with an adequate amount of testing instead of delaying the release to develop reliable software and releasing software patches post release to make the software more reliable. The paper aims to discuss these issues. Design/methodology/approach The authors have developed a generalized framework by assuming that testing continues beyond software release to determine the time to release and stop testing of software. As the testing team is always not skilled, hence, the rate of detection correction of faults during testing may change over time. Also, they may commit an error during software development, hence increasing the number of faults. Therefore, the authors have to consider these two factors as well in our proposed model. Further, the authors have done sensitivity analysis based on the cost-modeling parameters to check and analyze their impact on the software testing and release policy. Findings From the proposed model, the authors found that it is better to release early and continue testing in the post-release phase. By using this model, firms can get the benefits of early release, and at the same time, users get the benefit of post-release software reliability assurance. Originality/value The authors are proposing a generalized model for software scheduling.

show abstract

Economic Impact of Software Patching and Optimal Release Scheduling

Cited by 25 publications

References 33 publications

Measuring software reliability under the influence of an infected patch

Measuring software reliability under the influence of an infected patch

Testing Resource based Optimal Release Policy for Software System Incorporating Fault Reduction Factor and Change point

Generalized software release and testing stop time policy

Contact Info

Product

Resources

About