Software Up-gradations and Optimal Release Planning

Transcription

1 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 Software Up-gradatons and Optmal Release Plannng P K Kapur Amty Internatonal Busness School, Amty Unversty, Noda, Uttar Pradesh, Inda ABSTRACT Intense global competton n the dynamc envronment has lead to up-gradatons of software product n the market. The software developers are tryng very hard to project themselves as organzatons that provde better value to ther users. One major way to ncrease the market charsma s by offerng new functonaltes n the software perodcally. But these ntermttent add-ons n the software lead to an ncrease n the fault content. Thus, for modellng the relablty growth of software wth these up-gradatons, we must consder the falures of the upcomng release and the faults that were not debugged n the prevous release. Based on ths dea, a mathematcal modellng framework for multple releases of software products has been proposed. The model unquely dentfes the faults left n the software when t s n operatonal phase durng the testng of the new code. The model has been valdated on real data set. Now, snce the proposed structure s dependent only on tme, t can be categorzed under one dmensonal modellng outlne. But the need of the hour s to consder other factors (avalable resources; coverage, etc) smultaneously. Therefore, usng a Cobb Douglas producton functon we have extended our own modellng framework and developed a two dmensonal software relablty growth model for mult releases whch concurrently takes nto consderaton testng tme and the avalable resources. Another major concern for the software development frms s to plan the release of the upgraded verson. In a Software Development Lfe Cycle the testng phase s gven a lot of mportance. But testng cannot be done ndefntely, hence t s pertnent to fnd the optmal release tme durng testng phase. Too late an entry s lkely to lead to sgnfcant loss of opportunty and on the other hand early release of any software product mght hnder ts growth due to lack of receptveness of users towards new expertse. Therefore, tmng plays a very mportant role. In software world we term ths problem as Release Tme Problem. Many release tme problems wth optmzaton crtera lke cost mnmzaton, relablty maxmzaton and budgetary constrants etc. have been dscussed n the lterature. We have formulated an optmal release plannng problem whch mnmzes the cost of testng of the release that s to be brought nto market under the constrant of removng a desred proporton of faults from the current release. The problem s llustrated usng a numercal example, and s solved usng Genetc Algorthm. Further, we have also dscussed the release tme problem based on a new concept of Mult-Attrbute Utlty Theory that takes nto consderaton two conflctng attrbutes smultaneously. Ths framework has also been llustrated usng a numercal example. Keywords Software Relablty, Mult up-gradaton, Mult Attrbute Utlty Theory, Software Relablty Growth Model, Cobb Douglas producton functon, Optmal Release Tme.. INTRODUCTION The demand for contnuous servce n msson- and safetycrtcal software applcatons, such as Internet nfrastructure, aerospace, telecommuncaton, mltary defense and medcal applcatons s expandng.the ntense global competton n the dynamc envronment has lead to a technologcal substtuton of software product n the market. The software developers are tryng very hard to project themselves as organzatons that provde better value to ts customer. One major way to ncrease the market presence s by offerng new functonaltes n the software perodcally. Technologcal breakthroughs are happenng rapdly and these new nnovatons often take form of a new product. The concept of performance of a new technology generaton over ts lfe cycle has been explaned by usng well known s-shaped curve or sgmod curve. It has been seen that n the ntal perod of the software more efforts are put ncreasngly so that overall performance of the technology can be mproved tll attanng ts natural performance lmt. In general when software reaches a level when t attans t operatonal relablty level desred by the frm, a new verson s ntroduced and the software gets upgraded. The term upgrade refers to the replacement of a product wth a newer verson of the same product. It s most often used n computng and consumer electroncs, generally meanng a replacement of hardware, software or frmware wth a newer or better verson, n order to brng the system up to date or to mprove ts characterstcs. As the software frms are nvolved n developng complex software system wth a sharp eye on the market competton, the qualty of ther product s always under check. Performance of a software system s dependent on ts user's needs and requrements. Whle a system's performance may reman the same or even mprove, the user may come to beleve that the system s declnng n performance as technology changes. Although technologcal obsolescence s present n any ndustry, ts speed s more pronounced n the software ndustry. Therefore, t s crtcal to have a constant look on the state of a software system whch ncludes the vews of ts customers. Ths ndex allows us to ncorporate customer vews drectly nto the process, and to develop an operatonal framework for the analyss of warranty, mantenance, and upgrade polces.upgradng a software applcaton s a complex process. The new and the old component may dffer n the functonalty, nterface, and performance. Only selected components of an applcaton are changed whle the other parts of the applcaton contnue to functon. Ths process leads to an ncrease n the fault contents. The software testng team s always nterested n knowng the bugs present n the software. Therefore they contnuously keep on testng the software. Although developers produce upgrades n order to mprove a product, there are rsks nvolved, ncludng the possblty that the upgrade wll worsen the product. Upgrades of software ntroduce the rsk that the new verson (or patch) wll contan a bug, causng the program to malfuncton n some way or not

2 Falure Rate Add On Add On Add On Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 to functon at all. For example, n October 2005, a gltch n a software upgrade caused tradng on the Tokyo Stock Exchange to shut down for most of the day [22,23]. Smlar gaffes have occurred: from mportant government systems to freeware on the nternet. Upgrades can also worsen a product subjectvely. A user may prefer an older verson even f a newer verson functons perfectly as desgned. The above phenomenon s generally due to software falure. Software falures may be due to errors, ambgutes, oversghts or msnterpretaton of the specfcaton that the software s supposed to satsfy, carelessness or ncompetence n wrtng code, nadequate testng, ncorrect or unexpected usage of the software or other unforeseen problems. Abundance of software relablty models have been developed n the hstory of ths subject. Goel and Okumoto [9] proposed an SRGM, whch descrbes the fault detecton rate, as a non homogeneous Posson process (NHPP) assumng the hazard rate s proportonal to remanng fault number. The basc assumptons of ther model were as follows:-. Software systems are subject to falure durng executon caused by a fault remanng n the system. 2. Falure rate of the software s equally affected by the faults remanng n the software. 3. The number of faults detected at any tme s proportonal to the remanng number of faults n the software. 4. On a falure, repar effort starts and the fault s removed wth certanty. 5. All faults are mutually ndependent from falure detecton pont of vew. 6. The proportonalty of fault detecton/solaton/correcton s constant. 7. The fault detecton/ correcton are modeled by non homogeneous poson process. 8. The number of faults n the begnnng of the testng phase s fnte. In the last two decades several Software Relablty models have been developed n the lterature showng that the relatonshp between the testng tme and the correspondng number of faults removed. They are ether Exponental or S- shaped or a mx of the two. The software ncludes dfferent types of faults, and each fault requres dfferent strateges and dfferent amounts of testng effort to remove t. Ohba [7] refned the Goel-Okumoto model by assumng that the fault detecton/removal rate ncreases wth tme and that there are two types of faults n the software. SRGM proposed by Bttant et al. and Kapur and Garg [5,9] has smlar forms as that of Ohba but s developed under dfferent set of assumptons but all are flexble n nature. Bttant et al. [30] proposed an SRGM explotng the fault removal (exposure) rate durng the ntal and fnal tme epochs of testng. Whereas, Kapur and Garg [5,9] descrbe a fault removal phenomenon, where they assume that durng a removal process of a fault some of the addtonal faults mght be removed wthout these faults causng any falure. These models can descrbe both exponental and S-shaped growth curves and therefore are termed as flexble models. Later, Kapur et al.[9] proposed an SRGM wth three types of fault. The frst type s modeled by an Exponental model of Goel and Okumoto [9]. The second type s modeled by Delayed S- shaped model of Yamada et al. [28, 29]. The thrd type s modeled by a three-stage Erlang model proposed by Kapur et al [5,9]. The total removal phenomenon s agan modeled by the superposton of the three SRGMs. They extended ther model to cater for more types of faults by ncorporatng logstc rate durng the removal process. Fgure depcts the ncrease n falure rate due to the addton of new features n the software. Due to the feature upgrades, the complexty of software s lkely to be ncreased as the functonalty of software s enhanced [8]. Even fxng bugs may nduce more software falures by fetchng other defects nto software. But f the goal of the frm s to upgrade the software by enhancng ts relablty then t s possble to ncur a drop n software falure rate that can be done by redesgnng or re-mplementng some modules usng better engneerng approaches. Fg : Falure rate curve due to Feature Enhancements for Software Relablty 2. NOTATIONS m(t) : Number of faults detected durng the testng tme t a : Constant, representng the ntal number of faults lyng dormant n the software when the testng starts for th release; = to 4. a : Total fault content ( a a a2 a3 a4 ) f (t) : Probablty densty functon. F(t) t : Probablty dstrbuton functon. Tme for th release (= to 4). b : Fault removal per remanng faults; = to 4. : Constant parameter descrbng learnng n the Test/ Useful Lfe Obsolescence Tme fault removal rate; = to MODELING SOFTWARE RELIABILITY FOR VARIOUS RELEASES As dscussed above a plethora of mathematcal models have been dscussed n the lterature to capture the cumulatve number of faults removed n the software. Usng the hazard rate approach n dervng the mean value functon of cumulatve number of faults removed, we have: Let { N( t), t 0} be a countng process representng the cumulatve number of software falures by tme t. The N (t) process s shown to be a NHPP wth a mean value functon m (t).mean value functon represents the number of faults removed my tme t. 2

3 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 n ( mt ( )) Pr( N( t) n) exp(( m( t)),n=,2... () n! m(t) t (x)dx So, 0 dmt f t a mt dt F t Solvng the above equaton usng the ntal condton m (0) = 0 m t a F t Release The most mportant phase n the software development lfe cycle s testng. Testng starts once the code of software s wrtten. Before the release of the software n the market the software testng team tests the software rgorously to make sure that they remove maxmum number of bugs n the software.although t s not possble to remove all the bugs n the software practcally. Therefore, when one software verson s tested by the testng team, there are chances that they may detect a fnte number of bugs n the code developed. These fnte numbers of bugs are then removed perfectly and mathematcal equaton for t s gven as under:- m t a F t 0 t t (4) Release 2 Due to ferce competton and technologcal changes the software developer s forced to add new features to the software. New features added to the software leads to complexty and ncrease n the fault content of the software. Whle testng the newly formed code, there s always a possblty that the testng team may fnd some faults whch were present n prevously developed code. Testng the newly developed code helps the developer to actually mprove the software overall as t also removes some faults of prevously developed code. In ths perod, when there are two versons of the software, a (2) (3) F t the left over fault content of the frst verson nteract wth new detecton/ correcton rate. As a result of these nteractons a fracton of faults whch were not removed durng the testng of the frst verson of the product gets removed. In addton, faults are generated due to the enhancement of the features, a fracton of these faults are also removed durng the testng wth new detecton proporton.e. F t t 2. The change n the fault detecton s due to change n tme, change n the complexty due to new features, change n testng strateges etc. The two resultng equatons are as followng: m t a F t 0 t t m2 t a2 F2 t t a F t F2 t t (5) t t t2 Release 3 When the new functonaltes are added n the software for the second tme agan new lnes of code are developed. Ths new code s ntegrated wth the exstng code and a testng s started agan. It s known that bugs present n the software are nfnte. Therefore durng the testng n ths phase a lot of bugs whch have been left n prmtve stage and frst add-ons are removed. Ths helps n removng more and more bugs from the developed code. In ths perod, when there are three versons of the software, a2 F2 t2 the left over fault content of the second verson nteracts wth a changed rate of fault detecton/ correcton. As a result of these nteractons a fracton of faults whch were not removed durng the testng of the second verson of the product gets removed.. As the new verson of the software gets ntroduced, t brngs n wth t fault content to the software system. A proporton of these faults get removed when the testng team tests the new code and these faults are removed wth the detecton proporton F t t followng: 3 2 m t a F t 0 t t. The three resultng equatons are as m t a F t t a F t F t t t t t 2 m t a F t t a F t F t t t t t (6) In the above stuaton, the newly developed code for thrd release, the code developed for second release and the orgnal code of the software are tested and the cumulatve numbers of F t t. In the faults are removed wth a falure rate of 3 2 thrd stage, we can dentfy that a fnte number of faults are left over from frst and second release whch are now gettng removed wth a dfferent testng effort and under dfferent testng condtons governed by the falure dstrbuton. Release 4 The process of addng new functonaltes s an on gong process. These add-ons keep on happenng tll the product s there n the market. Ths phenomenon helps n mprovng the value of product and also helps n ncreasng the relablty of the product as more and more faults are removed when testng and ntegraton of code s done. We dscuss a case when the new features are added n the software for the thrd tme. m t a F t 0 t t m t a F t t a F t F t t t t t m t a F t t a F t F t t t t t m t a F t t a F t F t t t t t (7) The above equatons are explaned as follows: when the testng of the software began ntally, the fault content s a whch gets reduced by the proporton F t. A proporton of faults af t get removed tll tme t. At ths tme the developers start to test the new verson of the software. The new verson of the software leads to a generaton of faults n the software system due to the complexty added by new functonaltes. When testng s n process, a2 amount of faults are added n the software n the nterval [t,t 2 ]. The second equaton depcts that a proporton of these faults are removed whle testng and also a part of leftover faults of the frst verson software product are removed wth a rate whch s dfferent from the ntal testng rate. Smlarly when a new verson of a software n ntroduced n the market for the thrd 3

4 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 tme t further adds to a3 amount of faults n the software. A fracton of these faults are removed durng the testng. In addton to these faults a part of fault whch was left over durng the testng of the second verson product..e. a F t. When the software s released for the forth tme n the market a percentage of faults a4 get removed wth detecton proporton F t t 4 3. Smlarly, the fault contents whch were left over n the software system durng the tme of frst, second and thrd releases gets removed wth the F t t and a part of ther fault content gets proporton 4 3 removed durng testng n the tme nterval[t3,t4].here, we assumed that F t follows a logstc dstrbuton. Ths helps us n developng a flexble software relablty growth model, whch s s-shaped n nature. The s-shapedness of model helps us to capture the non unform nature of testng n the above developed model. F t exp bt (8) exp bt 4. Estmaton of parameters, Model valdaton and Comparson Crtera Bas MSE Varaton Fg-2 Parameter estmaton s of prme sgnfcance n software relablty predcton. In our study we have used the Statstcal Package for Socal Scences (SPSS) [5, 9]. The present study s based on the data avalable on Tandem Computers. Once the analytcal soluton for mean number of faults mt () detected/removed by tme t gven by that s mostly descrbed by the non-lnear functons s known for a gven model, the parameters n the soluton are requred to be determned. Parameter estmaton s acheved by extensvely used estmaton technques for non-lnear models method of Non-lnear Least Square (NLLS). Fgures (2,3,4,5): Release,2,3,4 respectvely. 4. Fgures and Tables TABLE : parameter estmates Re lea se a Fg-3 Fg-4 b TABLE 2: comparson crtera 2 R Release Release 2 Release 3 Release Fg-5 Fg: 2,3,4,5 respectvely showng Goodness of Ft for Four Releases 4

5 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, TWO DIMENSIONAL MODELING FRAMEWORK The headng of a secton should be n Tmes New Roman 2- The two dmensonal SRGM proposed n our work ncorporatng testng tme and resource usage s based on Non Homogeneous Posson Process (NHPP) (descrbed n the prevous secton). However, n one dmensonal analyss the object varable s dependent on one basc varable although the object takes on many dfferent roles based upon ts dependence on varous other factors. Two dmensonal models are used to capture the jont effect of testng tme and testng resources on the number of faults removed n the software. Such two dmenson models are also based on NHPP. In these models we defne a two-dmensonal stochastc process representng the cumulatve number of software falures by tme s and wth the usage of resources u by { N ( s, u ), s 0, u 0}. The mean value functon for a two-dmensonal NHPP s formulated as:-. n ( m( s, u)) Pr( N( s, u) n) exp( m( s, u)) n!, n=0,, 2 In recent years, Ish and Doh proposed a two dmensonal software relablty growth model and ther applcaton[3]. They nvestgated the dependence of test-executon tme as a testng effort on the software relablty assessment, and valdate quanttatvely the software relablty models wth two-tme scales. Inoue and Yamada also proposed two dmensonal software relablty growth models[32]. However ther modelng framework was not a drect representatve of usng mean value functons to represent of fault removal process. They dscussed software relablty assessment method by usng two dmensonal Webull-type SRGM. Moreover, ther modelng framework assumes software development as a sngle release process. Recently, Kapur et. al. proposed a two dmensonal modelng framework whch was appled n determnng optmal allocaton of testng tme and resources smultaneously to a modular software system. In ths secton we develop a two-dmensonal mult release model whch ncorporates the combned effect of testng tme and resources n each release to remove the faults lyng dormant n the software[33,34]. The model developed s based on the Cobb Douglas producton functon [34]. The functonal form of producton functons s extensvely used to characterze the relatonshp of an output to nputs. It was proposed by Knut Wcksell (85 926), and tested aganst statstcal evdence by Charles Cobb and Paul Douglas n Cobb-Douglas functon presents a smplfed outlook of the economy n whch producton output s obtaned by the amount of labor occuped and the amount of captal nvested. Whle there are many factors nfluencng economc performance, ther model demonstrated remarkable accuracy. The mathematcal form of the producton functon s specfed as: Y=AL v K v where: Y = total producton (the monetary value of all goods produced n a year) L = labor nput K = captal nput A = total factor productvty v s elastcty of labor. Ths value s constant and s determned by avalable technology. 5.. Notatons A B λ a S U Α m (s, u) Intal number of faults. Fault detecton rate per remanng smple fault. Fracton of the fault for th release Intal fault content for th release Testng tme. Resources. Resource Elastcty to Testng Tme Cumulatve number of faults removed by tme s and wth the usage of resources u. 5.2 Two Dmensonal Software Relablty Growth Model for Sngle Release The two dmensonal flexble SRGM presented n ths secton was proposed by Kapur et al [34]. It s based on the followng assumptons-. Falure /fault removal phenomenon s modeled by NHPP. 2. Software s subject to falures durng executon caused by faults remanng n the software. 3. Falure rate s equally affected by all the faults remanng n the software. 4. Fault detecton rate s non-decreasng tme and resource-dependent functon. 5. On a falure, the fault causng that falure s mmedately removed and no new faults are ntroduced. 6. To cater the combned effect of testng tme and resources we use Cobb-Douglas producton functon of the followng form: su 0 s : testng tme u : testng resources (effort) : Effect of testng tme Under the above assumptons the dfferental equaton representng the rate of change of cumulatve number of faults detected w.r.t. to the combned effect of tme and resources s gven as: ' f () m ( ) a m( ) F( ) (9) (0) Integratng above equaton wth ntal condton m( =0)=0, and usng equaton (0) we get m a. F( ) The above model can also be wrtten n the form () m s, u a. F( s, u) (2) Equaton (2) s the generalzed two-dmensonal SRGM model (SRGMs). Substtutng dfferent types of dstrbuton functons, we can obtan dfferent mean value functons correspondng to them. The cumulatve number of faults removed m( ) s dependent on. s a two-dmensonal 5

6 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 varable, wth testng tme s and testng effort u as ts dmensons. The two-dmensonal models are useful as they can show the effect of two aspects of a varable on whch the result s dependent. 5.3 Modelng Two Dmensonal Mult Release SRGM In modelng the proposed model apart from the assumptons, we assume that whle modelng the mean value functon for the next release nclude the faults of the current release and the remanng faults of just prevous release are consdered. Release In mult release model frst release s the frst step for enterng nto the market. Hence company wll have to pay attenton on t because generally frst mpresson counts for the last mpresson. Therefore to bang nto the market, the frm wll have to test the software rgorously wth an attempt to remove maxmum number of faults lyng dormant n the software. But, because of tme and resource constrants t s not practcally possble for the testng team to remove all the errors and thus the ntal release of the software s made, wth some of the fault content remanng n t. Therefore, when one software verson s tested by the testng team, there are chances that they may detect a fnte number of bugs n the code developed. These fnte numbers of bugs are then removed perfectly and mathematcal equaton for t s gven as under:- m a F ( ) 0 Release 2 (3) After frst release, n order to reman n the market company adds some new functonalty nto the software. New features added to the software leads to complexty and ncrease n the fault content of the software. At the same tme the frm can t even neglect the errors that are reported n operatonal phase of the frst release. Therefore, the mathematcal equaton representng the cumulatve number of faults removed n second release s gven by: m a F ( ) a F } F ; (4) Smlar to the arguments gven n second release along wth takng nto consderaton the fact that the next release wll contan the remanng faults of just released verson, we can have the mathematcal equatons for thrd, fourth and so on to th releases. We follow Exponental dstrbuton for removal process of the F() faults respectvely.e. t s the exponental probablty dstrbuton functon related to th release. 5.4 Data Descrpton We have used the Tandem Computer Company for four releases of software [6, 26]. The data set presents the falure data from four major releases of software product at Tandem computers. The frst release conssts of 00 faults count observed durng 20 weeks wth cumulatve resources of In the second release 20 cumulatve defects were found collected durng 9 weeks wth resource usage of Thrd release was tested for 2 weeks and 5053 cumulatve resources were used and 6 bugs were observed. Last, fourth release was testes for 9 weeks whch reported 42 errors and 305 unts resources were used. 5.5 Crtera for Model Comparson and Parameter Estmaton For estmatng the parameter values of each release s taken as tme of testng (n weeks) and u corresponds to resource usage. From estmaton result of frst release t was observed that total 9 faults were not removed durng testng n whch 7 faults smple faults and therefore they are also consttuted the part of total faults for the second release. Smlarly, the testng team was unable to remove 3 faults n the testng phase of second release, thereby formed the part of thrd release. In thrd release only 2 faults was not rectfed. The parameter values of the proposed model obtaned for the four releases are shown n table 3. Table 3 Parameter Estmates for Four Releases [=, 2, 3, 4] Parameters a b Release Release Release Release Table 4 Comparson Crtera for Four Releases Crtera R 2 Bas Varaton MSE Release Release Release Release The curve of the estmated values of the number of faults removed n dfferent releases usng the proposed modelng framework for the four releases s shown graphcally n fgures 6 to 9, respectvely. Fg 6: Goodness of Ft Curve for Release 6

7 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 Fg 7: Goodness of Ft Curve for Release 2 Fg 8: Goodness of Ft Curve for Release 3 Fg 9: Goodness of Ft Curve for Release 4 6. RELEASE PLANNING PROBLEM The headng of subsectons should be n Tmes New Roman the release of the up-graded verson. Owng to the prevalng paradox between software user s requrements and tme and resources lmtaton for the developers; an mperatve decson problem, whch arses s to determne when to stop testng of the current release and come up wth new verson of the software system for the users. Such problems are called Optmal Release Plannng Problems. Software users crave for faster delveres; cheaper software as well as qualty product whereas software developers desre to mnmze ther development cost, maxmze the proft margns and meet the compettve requrements. Moreover, t s also a matter of fact that f the new release of the software s overly delayed, the manufacturer (software developer) may undergo thrashng by means of penaltes and revenue loss, whle a premature release of new verson may cost heavly n terms of fxes (removals) to be done of that release n next release and ths mght also consequently harm manufacturer s reputaton. Thus, a tradeoff between conflctng objectves s requred. After the study of exstng lterature, t has been observed that a lot of research has been done for the release of sngle verson software systems. Okumoto and Goel [8] formulated optmum release tme polces usng the exponental SRGM. Yamada and Osak [35] studed optmal release polces based on software cost and software relablty smultaneously for exponental, modfed exponental and an S-shaped SRGM. The objectve was to mnmze the total software development cost subject to relablty less than a predefned relablty level or maxmze relablty subject to cost not exceedng a predefned budget. In 99 Kapur and Garg [] formulated release polces ncorporatng the effect of testng resource expendture for an exponental SRGM under the added assumpton that testng resource curves are descrbed by ether exponental, Raylegh or Webull curve. Huang and Lyu[36] proposed an SRGM wth generalzed testng effort functon and studed optmal release polces based on cost and relablty consderng testng effort and effcency. In 2007 Kapur et al. [37] proposed an SRGM wth two types of mperfect debuggng and determned the optmal release tme of the software. The release tme problems dscussed above were studed under the assumpton that a software comes n sngle release;.e. these researchers do not take nto consderaton the mpact of comng up wth mult releases of a software n release plannng decsons. But when dfferent versons of the software are to be released, then the frm cannot just plan the release of current verson on the bass of testng progress of new code only. It has to consder the log reports of just prevous release too. So, here we have formulated an optmal release plannng problem whch mnmzes the cost of testng of the release that s to be brought nto market under the constrant of removng a desred proporton of faults (whch cannot be ; as testng cannot be contnued ndefntely) to be removed from the release. Another attractng feature of the formulated problem s that t not only consders tme as an essental crteron for releasng the new verson but also looks smultaneously for resources that govern the pace of testng. The optmal release plannng problem s complex non lnear optmzaton problems and s solved usng genetc algorthm (GA)[38]. Furthermore, we have also dscussed the release tme problem based on a new concept of Mult-Attrbute Utlty Theory [4,3,4] that takes nto consderaton two conflctng attrbutes smultaneously [6,24,25]. Ths framework has also been llustrated usng a numercal example. 6. Release Tme Problem (Soluton Method-GA) Problem Formulaton In plannng the release decsons for software that s to be brought nto the market wth new versons; the frm has to take nto consderaton two thngs: () Testng data of the new code. () Log reports of just prevous release,.e. bugs reported by the users n the operatonal phase of the verson that had been there n the market. 7

8 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 Where n sngle release software systems, only () prevals, and f () s not taken nto consderaton for the release plannng of mult release software systems; then the noton of comng up wth varous versons gets lost. Ths s because the decson of releasng the software lays ts foundaton on the total faults that are removed from the software. In mult release software the bugs of just prevous release also get added to the total faults of the release that s under testng phase. Therefore, to formulate an optmal release plannng (ORP) for mult release software we requre mult release software relablty growth model. Usng the modellng framework as done n earler Secton, we wll dscuss the followng release plannng problem. In the present problem, we consder mnmzng the testng cost of the release that s under testng phase wth a constrant of removng a desred proporton of faults. Cost Functon Suppose the frm has to delver the n th release of the software. Then, the cost functon wll nclude cost of removng faults durng testng phase of the nth release and cost of falure and removal of faults after the delvery of the nth release and unt cost of testng durng the testng phase of nth release. All these costs lead to the followng form of the cost functons: C ( ) C m C a a F m C ; n n n n 2 n n n n n n 3 Usng values of m( ) we get cost functon as: C ( su n ) C n n3 n an exp bns u n nexp bns u n n n n n exp b s u an a C n2 n anexp bns u n nexpbns u C su ; n n n n n n exp bn s u where C n s cost ncurred on removng a fault durng testng phase of n th release. C n2 s cost ncurred on removng a fault after the delvery of the n th release of software system. C n3 s the testng cost per unt testng tme and resources. C n s the total cost of testng of nth release. Also, n The total cost s to be mnmzed. Thus, we have that cost functon s a convex functon, So, when ths cost functon wll be plotted wth respect to tme and resources frame. Hence release tme problem now can be stated as: Mnmze C ( su n subject to ) C n C n2 n3 n an exp bns u n nexp bns u n n exp b s u an a n n an exp bns u n n nexpbns u C su ; n n n n n n n exp bn s u n n n n an exp bn s u exp bn s u ( m (, )) n s u an an n n n n nexp bns u n exp bn s u (ORP Problem) where ρ s desred proporton of faults to be removed from n th release. The above problem s non lnear n nature whch s dffcult to solve through tradtonal search and optmzaton methods. Ths requres use of some new optmzaton technques based on natural evoluton and natural genetcs. Therefore to handle such dffcultes we have solved t usng Genetc Algorthm. The effcency of GA les n ts ablty of workng wth populaton of solutons and not an ndvdual pont. In addton GA breaks the lmtaton of dfferentablty. Numercal Example As an llustraton, here we choose the same data set of four releases taken n earler secton. In ths data set frst, second and thrd release have already been nto market. The problem formulated n secton 6 determnes when to stop testng the fourth release of the software such that the cost of testng s mnmzed. In order to determne the optmal release tme and optmal resource consumpton for the fourth release we make use of the estmated values of the parameters of thrd and fourth release gven n table. Wth these parameter values we solved the followng problem usng genetc algorthm method gven n secton 6. Further we assume C = 0, C 2 = 5, C 3 = 5 and t s desred that at least 0.95 proporton of faults should be removed from 4 th release. The problem s solved usng Matlab software under VC++ (6.0) compler. Mnmze 4 C ( ) C m C a a F m C subject to m4( ) 0.95 a4 a3 F3 3 where su 0 3 The parameters used n GA evaluaton for both the problems are gven n Table 5. The crossover method taken s smulated bnary crossover (SBX), and selecton crteron s tournament selecton wthout replacement. Table 5: Parameters of GA Parameter Populaton Sze Number of Crossover Mutaton Generatons Probablty Probablty Value Upon solvng the problem the optmal tme for stop testng the fourth release came out be 72 week (whch s 20 weeks after thrd release) wth an optmal resource consumpton of unts. The mnmum value of cost came out to be Release Tme Problem (Soluton Method-MAUT) 8

9 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 Optmal release tme determnaton n the testng phase s a typcal applcaton of Software relablty models. Software release tme problems have been dscussed and solved n dfferent ways. One of these s to fnd release tme so that the total cost ncurred durng remanng phases (.e. testng and operatonal) of the SDLC s mnmzed [9,9]. Some of the release tme problems are based upon relablty crteron alone. Optmzaton models that mnmze the number of remanng faults n the software or the falure ntensty also fall under ths category [,9,29]. Release tme problems have also been formulated for mnmzng cost wth relablty requrement or maxmzng relablty subject to budgetary constrant [9,]. B-crteron release polcy [9,0] smultaneously maxmzes relablty and mnmzes cost subject to relablty requrement and testng resource avalablty constrants. Mathematcal programmng methods have been used to fnd solutons to such problems. The qualty of a software system s usually managed or controlled durng the testng and mantenance phases. If the length of software testng s long, t can remove many software errors n the software system and ts relablty ncreases. However t may cause a sgnfcant fnancal loss for the software company by ncreasng the testng cost and delay n software delvery. Further, releasng software to market before measurng desred level of falure ntensty (whch s fxed by the manager) may ncrease the mantenance cost durng operatonal phase as well as create rsk to lose future market. To trade-off between two conflctng objectves, mult-attrbute utlty theory (MAUT) s appled n our decson model. measurement falure ntensty. A Mult-Attrbute Utlty Functon (MAUF) s defned as U ( x, x,..., x ) f u ( x ), u ( x ),..., u ( x ) w. u ( x ) 2 n 2 2 n n where, w n (5) where, U s a mult-attrbute utlty functon over all utlty; u ( x ) s sngle utlty functon measurng the utlty of attrbute ; x s level of th attrbute. w Represent the dfferent mportance weghts for the utltes of attrbutes By maxmzng the mult-attrbute utlty functon, the best alternatve s obtaned, under whch the attractveness of the conjont outcome of attrbutes s optmzed [3]. We now dscuss the methodology that has been utlzed n formulatng the utlty functon. Selecton of Attrbutes A vtal decson problem that frms encounter s to determne when to stop testng and release the software to user. If the release of the software s unduly delayed, the software developer may suffer n terms of revenue loss. The optmzaton problem of determnng the tme of software release can be formulated based on goals set by the frm n terms of cost and falure ntensty. Usng the concept of quantfcaton from Le et al [3]; the objectve of falure ntensty λ(t) s formulated as n max f () t (6) max where, f s the measurement of falure ntensty and s taken as to be one of the attrbutes to be consdered n MAUT. Fg 0. Steps for usng MAUT as an Evaluaton Approach MAUT has ganed a lot of mportance n recent years as t represents the scenaro of management approprately. It has strong theoretcal foundatons based on expected utlty theory [3, 3]. Another mportance s that t provdes feasblty to consder the alternatve on the contnuous scale [2, 3]. In the present study, we have dentfed two separate utlty assessments. The objectve lst utlzed for ths prelmnary analyss s mnmzaton of cost and maxmzaton of The software performance durng the feld s dependent on the relablty level acheved durng testng. In general, t s observed that longer the testng phase, the better the performance. Better system performance also ensures less number of faults requred to be fxed durng operatonal phase. On the other hand prolonged software testng unduly delays the software release. Consderng the two conflctng objectves of better performance wth longer testng and reduced costs wth early release, GO [8] proposed a cost functon for the total cost ncurred durng testng gven as: C T Cm T C2 a m T C3T (7) where, C be the cost of fxng a fault durng testng phase. C 2 be the cost of fxng a fault durng operatonal phase. C 3 s the testng cost per unt testng tme. 9

10 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 mt s the expected number of faults removed tll tme T. CT s the total cost n fault removal. A frm never wants to spend more than ts capacty, therefore the next attrbute that we consder s: CT ( ) Mn: C4 C B where, C B s the total budget allocated to the frm. Selecton of Attrbute Bounds (8) The upper and lower bounds of an attrbute are chosen by the desgner. It s possble to use mathematcal optmzaton technques to choose the lmts, however there s no rule as to the sze of the range. The range of the attrbute can change the weght of the scalng factors, when usng the mult-attrbute utlty model. SAUF represents management s satsfacton level towards the performance of each attrbute. It s usually assessed by a few partcular ponts on the utlty curve [2]. In the present study, usng the concept of Le et al [3], suppose that the sngle utlty functon for cost s to be determned, the lowest and hghest values of cost are selected frst as 0 C4 and C 4. At these boundary ponts, we have. u( C ) 0 and u( C ). Lottery The lottery s the step n the process where the desgner's preferences are determned. In ths step, the desgner needs to make a decson between two choces. The frst choce s to have the probablty p for the most preferred alternatve or - p for the least preferred alternatve. The second choce s the absolute certanty of a partcular alternatve, or the certanty value, between the most and least preferred. The goal of the lottery s to determne the probablty p where the decson maker s ndfferent between the two choces. The ndfference between the two choces s called certanty equvalence. Development of Sngle Attrbute Utlty Functon (SAUF) SAUF s obtaned by usng a set of lottery questons based on certanty equvalence. They are monotonc functons, where the fnest outcome s set at, and the worst at 0. SAUF are then developed to descrbe the desgner's compromse between the fnest and worst alternatves based on the lottery questons. and r s the rsk coeffcent whch shows degree of rsk atttude, reflectng rate at whch rsk atttude changes wth dfferent attrbute level. It may be noted that we use lottery when there s a preference or ndfference between two lotteres. If they are equal to each other, management s rsk neutral and the lnear (addtve) form u( x) y y. x should be used. Otherwse, f management 2 s not rsk neutral then the exponental form wll be selected. Furthermore, t s to note that the addtve form of multattrbute utlty functon s based on the utlty ndependence and the addtve ndependence assumptons [2,3]. The component utlty functon for attrbute ( u ) s assessed by the use of lottery [3, 2]. The three data ponts used to determne the unknown coeffcents are obtaned from the equaton u(x) = pu(x o ) + ( p)u(x * ), where x s the certanty value, x o s the best alternatve, and x * s the worst alternatve (Refer Fg 2.). Gven that the utlty s scaled between and 0, u(x f ) =, u(x w ) = 0, so u(x) = p. Therefore, to fnd p, for a gven x, the frm needs to ask from decson maker or else use the lottery theory. Credt Allotment to Weghts In ths secton we have dscussed about estmaton of weght parameter, w. The weghts are assumed to reflect the relatve mportance of movng an attrbute from worst to fnest level. Thus they are defned on rato scale. Many approaches for obtanng numercal weght have been proposed, ncludng drect trade-off methods, drect judgment of swng weght and lottery-base utlty assessment [2,3]. By these methods, Management can assgn dfferent mportance to each attrbute. In our case the number of attrbutes consdered are only two and n ths case use of the probablstc scalng (lottery weght) technque s recommended (useful when there s small number of attrbute). Consder two attrbutes C and f as software development H H cost and measurement of falure ntensty. Let ( f, c ) and L L ( f, C ) denote the fnest and worst possble consequence, (see rght hand sde n Fgure.2) respectvely. There s a H L certan jont outcome ( f, C ) that comprses of two attrbutes C and f at the best and worst level wth probablty p and (- p),respectvely [3,25]. Many functonal forms of utlty functon exst lke lnear, exponental etc. An analytcal functon s typcally used for preference descrpton, and exponental functons are usually used to descrbe ts shape. The general form s. u( x) y y2. e rx, where 2 y and y are parameters whch guarantee the utlty s normalzed between 0 and, 0

11 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 Fg : Two Choces for determnng scalng constants (Source: L et al [3]) Development of Mult Attrbute Utlty Functon (MAUF) When certan ndependence condtons are met, a mathematcal combnaton of all the SAUF, wth scalng constants, results n the MAUF, whch s the overall utlty functon wth all attrbutes consdered. Scalng constants reflect desgner's preference on the attrbutes, whch s based on scalng constant lottery questons and preference ndependence questons. The form of the MAUF functon depends upon the partcular ndependence condtons fulflled by the dfferent SAUF [2]. In the present work, the addtve form of the MAUF s gven as: Max : U( f, C ) w u( f ) w u( C ) w f w C4 where w and f 4 f C 4 wc 4 (9) are the weght parameters for attrbute f and C respectvely. u( f) and uc ( 4) are the sngle utlty functon for each attrbute. It may be noted that the U( f, C ) functon s of Max type and t has been wrtten n 4 terms of f and C 4.. From managers pont of vew, f s to be maxmzed whle C s to be mnmzed. To synchronze the two utltes together, we put ' ' sgn before cost utlty. By maxmzng ths mult-attrbute utlty functon, the optmal tme to release, * T wll be obtaned. Here, based on the sngle utlty functons and the weght parameters whch have been determned n prevous steps, the MAUF s evaluated Max u( f, C ) w u( f ) w u( C ) w f w C4 4 f C4 4, CT ( ) CB (20) The above functon s maxmzed by usng Maple package and the optmal tme to release comes out to be * T Fg 2: The mult-attrbute utlty functon aganst tme Numercal Illustraton Tandem Data [26] comprses of four successve releases. The proposed decson model has been valdated for ts thrd release. The 3 rd verson of software s released after 2 weeks. In ths paper we nvestgate about optmal tme for the release and try to fnd whether: Testng Tme for the release s suffcent. The software has been under tested. The software has been over tested. To answer these questons, the MAUT as dscussed s used. The determnaton of optmal plannng testng tme s done usng the methodology as descrbed n prevous secton. We set parameters C 5, C2 8, C3 3 and CB 2500 as parameters of cost functon. The bound are selected to the methodology dscussed earler. In partcular, the lowest budget consumpton W requrement s C4 0.5 and the hghest budget B consumpton C 4. The lowest falure ntensty W requrement s f4 0. and the hghest relablty for ths B release consdered as f By usng the concept from earler secton parameters y and y 2 are determned. Specfcally, we have the followng equatons: u( C ) 2C ; u( f ) 2 f Fg 3: The behavour of cost functon Fg 4: Behavour of falure ntensty functon Fgure 2 shows the mult attrbute utlty functon. From the curve t can be noted that the value of utlty functon starts to

12 Internatonal Journal of Computer Applcatons ( ) Internatonal Conference on Relablty, Infocom Technologes and Optmzaton, 203 declne after reachng tme around 6 (that s why we consder the optmal tme of release to be ths). Fgure 3 represents the behavour of the cost functon. Accordng to Tandem data falure, real tme to 3 th release s 2 weeks. Fgure 4 depcts the hump-shaped falure ntensty functon. After t reaches to the hghest value, t starts to declne and gves the graph the present shape. Based on optmal result, we can say that software n ths release should be kept under testng for around four more weeks. 7. CONCLUSION In software ndustry, up graded versons are made n the software at a very brsk speed. The lfe of software s very short n the envronment of perfect competton market; therefore developer has to come up wth successve releases to survve. But a matter of fact s that up-gradaton of software applcaton s a complex process. Upgrades of software ntroduce the rsk that the new verson wll nclude a bug, causng the program to fal. To capture the effect of faults generated n the software, we have developed mult-release software relablty modellng framework. The model unquely takes nto account the faults of that release whch s under the phase of testng (.e. the release whch s to be brought nto market) and the faults left n the prevous release (.e. the release whch s n operatonal phase). Further, the model s extended under the assumpton that tme and resources smultaneously are essental for modelng an accurate software relablty growth model. Wth ths development structure, a relatvely unexplored area of software relablty s nvestgated n ths work. The proposed mult release two dmensonal model s estmated on the real data set of four releases. Then the release plannng problem s dscussed n context of multple releases. The problem has been solved usng Genetc algorthm whch mnmzes the expected software cost subject to removng a mnmum desred proporton of faults from the new verson that s to be brought nto the market. The formulated release plannng problem helps n determnng both optmal release tme and optmal resource consumpton smultaneously. At last, another methodology of MAUT has been appled to the release tme problem n order to calculate whether the testng has been done approprately or some more testng tme would have requred f the software developer had the task of mnmzng cost and maxmsng falure ntensty. A numercal llustraton s also gven for the developed optmal release plannng problem. Takng nto consderaton the envronment of mperfect debuggng and exploraton of the possblty of ncludng randomness n the fault detecton rate forms the scope of future research. 8. REFERENCES [] Bardhan A K Modellng n Software Relablty and ts nterdscplnary nature,ph.d. Thess, Unversty of Delh, Department of Operatonal Research, [2] Ferrera R.J.P.., Almeda A.T., Cavalcante C A V., A mult-crtera decson model to determne nspecton ntervals of condton montorng based on delay tme analyss, Relablty Engneerng and System Safety, 94, , [3] Fshburn C P, Utlty Theory for Decson Makng, New York: Wley, 970. [4] Kanoun K, Bastos M., Morera J., A method for software relablty analyss and predcton applcaton to the TROPICO-R swtchng system. IEEE Trans. Software. Eng. 7 (4), [5] Kapur P K,, Pham H., Gupta A., Jha P C, Software Relablty Assessment wth OR Applcatons, UK: Sprnger, 20. [6] Kapur P K, Yadavall V S S, Aggarwal A G., Garmabak A H S, Development of a mult-release SRGM ncorporatng the effect of bugs reported from operatonal phase, Communcated., 202. [7] Kapur P K, Anand A., Sngh O., Modelng Successve Software Up-gradatons wth Faults of dfferent Severty. Proceedngs of the 5th Natonal Conference; INDIACom 20, Eds. Prof M.N.Hoda,Bharat Vdyapeeth s Insttute of Computer Applcatons and Management, New Delh. pp , 20. [8] Kapur P K, Tandon A., Kaur G, Mult Up- gradaton Software relablty Model 2nd nternatonal conference on relablty, safety&hazard (ICRESH), pp , 200. [9] Kapur P K, Garg R B, Kumar S, Contrbutons to hardware and software relablty Sngapore: World Scentfc Publshng Co. Ltd, 999. [0] Kapur P K, Agarwala S, Garg R B, Bcrteron release polcy for exponental software relablty growth model Recherche Operatonnelle Operatons Research, 28: 65-80, 994. [] Kapur P K, Garg R B, Optmal release polces for software systems wth testng effort Int. Journal System Scence,,22(9), , 990. [2] Keeney R L, and Raffa H, Decsons wth Multple Objectves: Preferences and Value Tradeoffs, New York, Wley, 976. [3] L, X., L Y. F., Xe M. and Ng S H, Relablty analyss and optmal verson-updatng for open source software, Informaton and Software Technology, Vol. 53, pp , 20. [4] Luo,Y. Bergander T., Software relablty growth modelng usng weghed laplace test statstc, Annual nternatonal Conference (COMPSAC 2007), 2:305 32, [5] Musa J D., Iannno A., Okumoto K, Software relablty: Measurement, Predcton, Applcatons, New York: Mc Graw Hll, 987. [6] Neumann J V,and Morgenstern O., Theory of Games and Economc Behavour (2nd ed.), Prnceton, NJ, Prnceton Unversty Press, 947. [7] Ohba, M Software relablty analyss models, IBM Journal of Research and Development,28: , 984. [8] Okumoto K. and Goel A L, Optmal release tme for computer software IEEE Transactons On Software Engneerng.; SE-9 (3): , 983. [9] Okumoto K. and Goel A.L., Tme dependent error detecton rate model for software relablty and other 2