An NHPP SRGM with Change Point and Multiple Releases

Introduction

Over the years as time goes by, the technology change and evolve. These technologies provide an upgrade path for those too timid or wise to jump head-first into the latest wave of IT offerings. Realizing the great importance of current and future business needs, software developers offer latest version of their software through the addition of new functionality. To keep pace with the latest Software developments, the only way is to create great products through constant learning and improvement upon them, and thus release the software multiple times with added features and capabilities that enhance the functionality and usability of their software. Although these technologies and up-gradations of software application provides a smoother way toward a modern system, they often results to a complex and sometimes painful process that affects the entire working environment of organization. An upgrade of software is valuable if it results in increased reliability and reduced security risks. Reliability is the most important quality metric that is quantified in terms of the estimated number of faults remaining in the software system and is significantly used to measure the quality of software. Software reliability growth models (SRGMs) are used to predict the reliability and to assess software quantitatively. Many SRGMs have been developed in the last two decades that can describe the reliability growth during the testing phase of the software development (Kapur, Pham, & Jha, 2011; Xie, Hu, Wu, & Ng, 2007). These models were proposed for the software in which no further enhancement is made and are released once into market. In today’s time there is a need for a modeling framework which presents a testing and debugging process of multi release software systems. Only a few attempts have been made to model multi-release software development process. In this paper we present a discrete modeling framework for multiple releases of software by considering the realistic assumption of having the change point in the testing time. During testing phase of software development process, the fault removal rate may not remain constant throughout but may change after some testing periods. Thus change point may appear notably when there is a non-monotonic increase or decrease in software failure intensity function. It happens due to changes in various factors such as operating environment, testing strategy, testing tools or techniques, nature of faults detected, defect density etc. In the next section, we briefly discuss the work done so far in this field.