The Present Value of Software Maintenance 1, 2

Size: px

Start display at page:

Download "The Present Value of Software Maintenance 1, 2"

Sydney Brice Bryant
5 years ago
Views:

1 The Preset Value of Software Maiteace, Robert L. Vieeau Abstract: Decidig to egage i a software project typically results i icurrig costs ad geeratig reveues over a log time period. Itroducig ew techology ito the software process ca likewise be cosidered a ivestmet decisio. This paper presets capital budgetig techiques employed amog fiacial aalysts ad upper-level maagemet to evaluate such ivestmet decisios. Examples are give to illustrate fiacial aalysis techiques based o actual data reported i the software egieerig literature. Uder proper time discoutig, the commoly reported effect of moder programmig practices to shift costs to earlier i the lifecycle decreases the et preset value of a project uless resultig gais i quality ad productivity more tha compesate. The pricipal theses of this paper are that software maagers should use these techiques i performig cost aalyses ad that software process measuremet programs eed to be desiged with the goal of supportig such aalyses..0 Itroductio A variety of tools ad techiques have bee itroduced over the last two decades for improvig software developmet ad maiteace. Examples iclude Structured Aalysis, Structured Programmig, Computer Aided Software Egieerig (CASE), Object Orieted desig, formal methods, structured ispectios, ad ew testig methods. This paper provides maagers of software orgaizatios with techiques for choosig amog these possibilities. It also provides a outlie of valid argumets to sell upper maagemet o the cost-effectiveess of ivestig i process improvemet. The aalysis techiques recommeded here result i fidigs i a laguage uderstood by upper maagemet. Applyig the techiques described i this paper requires more measuremet of the software process tha is typical. This paper describes a fiacial aalysis framework for esurig software measuremet will be directed toward maagemet cocers. Early results from a Software Egieerig Istitute (SEI) survey of process maturity showed that of several doze orgaizatios, over 85% were at a Level, the Iitial level, where process measuremets are rarely collected [Humphrey 88]. The overwhelmig majority of software orgaizatios simply do ot collect the data that maagemet eeds to make optimal decisios o ew software techology. Software projects require expeditures ad geerate reveues over a legthy spa of time. A software project ca be cosidered the result of a ivestmet decisio i which expeses are dispersed i the belief that greater beefits will be obtaied i the future. Similarly, the choice of the specific techiques employed o a software project are the results of ivestmet decisios that should reflect a attempt to optimize certai fiacial criteria. Fially, attempts to improve the process of a software orgaizatio should likewise be cosidered ivestmet decisios i which the payoff is likely to be obtaied across several projects. A established set of techiques are employed by maagers of well-ru corporatios, especially at the higher levels, to assist i choosig amog alterate

2 ivestmet projects. These techiques are described i may textbooks o fiacial aalysis ad maagemet accoutig (e.g. [Copelad 78]). They are eve described i the most well-kow book o software egieerig ecoomics [Boehm 8]. Sectio presets a itroductio to these capital budgetig techiques. Sectio 3 illustrates these techiques with some very simple models fleshed i with some parameters draw from the software metrics literature. Sectio 4 cocludes with some observatios o the implicatios of fiacial aalysis for software maagemet, particularly with respect to measuremet ad process improvemet programs..0 Preset Value Aalysis Optimal techiques for maximizig the value of a corporatio's assets are based upo the recogitio that a dollar received sometime i the future is ot of the same value as a dollar received today. The time value of moey expresses this differece i value as a iterest rate. The relevat iterest rate for a firm to employ i time discoutig ca be thought of as objectively give by the cost of capital 3. The iterest rate expressig the time value of moey or the cost of capital ca be used to discout all moetary quatities to a sigle poit of time. The preset value of x dollars to be spet or received years i the future is give by Equatio : x PV = () ( + r) where r is the iterest rate expressig the cost of capital. Preset values should be used i comparig moetary quatities across time, ot raw amouts ucorrected for time discoutig. A decisio betwee two or more ivestmet decisios should reflect the decisiomaker's objectives. Geerally, firms should choose amog ivestmet projects o the basis of et preset value. Firms should choose projects as log as their et preset value is positive 4. The et preset value of a ivestmet project which icurs costs C (i) ad geerates reveues R (i) at the ed of year i, i = 0,,,, is give by: = R( i) C( i) NPV () i i= 0 ( + r) Give a choice of mutually exclusive ivestmet projects, firms iterested i maximizig the value of their assets for their stockholders should choose the project with the highest et preset value. Fiacial aalysis techiques should guide upper-level maagemet, but they caot reduce decisio makig to mere calculatio. Ay importat decisios based o et preset value calculatios should be accompaied by a sesitivity aalysis, which ivestigates how results vary with chages i the parameters. For example, the et preset value model's sesitivity to iterest rate variatios icreases wheever cash flows occur i icreasigly distat periods [Copelad 78].

3 3.0 Examples The effects of proper fiacial aalysis o software maagemet ca be illustrated by some examples that cast a differet light o some well-kow software egieerig wisdom. 3. Lifecycle Cost Models The outputs of a software cost model, such as the Costructive Cost Model (COCOMO), typically cosist of the developmet cost ad schedule. They are usually broke dow by phases. I additio, the maager of a software project should have some idea of the et reveues to be gaied i operatios oce the system is fielded. Table provides a list of such parameters. Phase Requiremets ( ) Prelimiary Desig ( ) Detailed Desig ( 3 ) Codig & Uit Test ( ) Itegratio & Test ( ) 5 Table : Lifecycle Cost Data Total Reveues Moths i (Cost) Phase c c c 3 Operatios & Maiteace R 6 Reveues (Cost) per Moth c ( ) ( c ) ( c 3 3 ) ( c 4 4 ) ( c ) c 4 4 c R 6 Software cost models are ofte used to examie the cost impacts of various developmet methods. Differet methods will shift costs across time, as well as chage the total cost. Thus, the impact of ew developmet methods should take time discoutig ito accout. This example shows how to calculate the Net Preset Value of the software lifecycle show i Table. Let 00 r % represet the mothly iterest rate, ad 00 r be the aual iterest rate. Equatio 3 relates the mothly ad aual iterest rates: ( ) ( + r ) = + r (3) Let m j be the total umber of moths from the begiig of the project to the ed of phase j : m 0 = 0 (4) m j = m j + j, j =,,3, K,6 (5) The the et preset value of the software lifecycle is give by Equatio 6:

4 R c j m6 5 m j 6 j NPV = (6) i i i= m + ( + r ) j = i= m + ( + r ) 5 j Equatio 6 ca be reduced to Equatio 7: [( + ) 6 ] 5 R r [( + ) ] = c j r j NPV (7) m 6 ( + ) 6 m r r j = j r ( + r ) j Cost models should provide this quatity as a commo practice. Cost aalysts should examie what assumptios eed to be made about iterest rates, et operatig reveues, ad the legth of time a system is fielded to esure the et preset value is positive. Figure provides a simple example of such a aalysis. It is based o a system with 3 thousad source lies of code ad a developmet schedule as predicted by the Basic COCOMO model. This is a medium size project. The developmet schedule, icludig Requiremets, is 6 moths, ad 96 perso-moths are cosumed by developmet. Figure shows the mothly reveues required before et preset value is positive. If mothly reveues durig operatios are expected to fall below the values graphed, the firm will ot recover its cost of capital ad should ot udertake this project. New desig methods are ofte claimed to decrease maiteace costs, thereby icreasig operatig reveues, at the expese of more up-frot developmet costs. The above et preset value model provides a framework for ivestigatig the value of such chages. Sice later costs have a much smaller impact o et preset value, shiftig uchaged total costs forward decreases et preset value. The itroductio of a ew method must decrease total costs eough to more tha compesate for this effect.

5 3. The Importace of Maiteace I 97, Barry Boehm predicted that by 985, more tha 80% of the cost of software would be spet i maiteace [Boehm 73]. The covetioal wisdom is that this predictio has bee fulfilled [Berry 9]. This seems to imply that as much as possible should be doe durig developmet to esure maiteace costs are as low as possible, certaily much more tha is state-of-the practice. However, sice maiteace costs occur later i the lifecycle, they are discouted more heavily tha developmet costs. So the 80% figure overstates the importace of maiteace. How much overstated is illustrated by a fairly crude model. Cosider a software project with two phases, Developmet ad Operatios ad Maiteace (O&M). Assume: The Developmet phase requires years with a cost of c dollars at the ed of each year. The O&M phase requires years with a cost of c dollars spet at the ed of each year. 00 p % of the total lifecycle cost is spet i O&M. The cost of capital is expressed by a iterest rate of 00 r %. I this simple model, the total cost (without time discoutig) is give by: TC c + c = (8) The assumptio that the O&M cost is 00 p % of the total cost allows oe to derive a relatioship betwee the yearly costs durig the two phases: c p c ( p) = (9) Preset values ca be foud as follows: [ c c ( + r) ] PV Developmet = = i i= ( + r) r( + r) [( + r) ] PVO& M + c p c = i ( ) i ( ) p + = + + r r( + r) PV TC PVDevelopmet + PVO & M (0) = () = () The ratio of the preset value of the cost of O&M ad the preset value of the total lifecycle cost is the: PV PV O& M TC ( p) = + p ( + r) ( + r) ( + r) (3)

6 The importace of maiteace costs, whe properly discouted, varies with the details of the project ad the ecoomic climate as reflected i the cost of capital. Table, which is based o the assumptio that maiteace cosumes 80% of total (udiscouted) costs, illustrates that maiteace ca be much less of a problem tha a aalysis without time-discoutig might lead oe to expect. A more sophisticated aalysis would take ito accout variatios i cost over both the developmet ad maiteace phases ad would allow for costs to be paid more frequetly tha aually. Still the arithmetic of preset value aalysis implies maiteace costs are of lesser importace tha is commoly thought. Years i Developmet Table : Preset Value of Maiteace Years i Iterest Rate Maiteace r Ratio of Preset Values PV O & M PVTC 5 0% 80% 5 0% 74% 5 0% 69% 5 30% 63% 0 0% 70% 0 0% 60% 0 30% 5% 5 0% 66% 5 0% 53% 5 30% 43% 5 5 0% 7% 5 5 0% 6% % 5% 5 0 0% 67% 5 0 0% 53% % 4% 5 5 0% 6% 5 5 0% 46% % 33% 3.3 A Empirical Example Data from the Software Egieerig Laboratory (SEL) ca be used to illustrate the effects of preset value calculatios. The SEL was created i 976 by the Natioal Aeroautics ad Space Admiistratio/Goddard Space Flight Ceter (NASA/GSFC) to support research i evaluatio ad measuremet of the software developmet process. The SEL is joitly operated by NASA/GSFC, Computer Scieces Corporatio (CSC), ad the Uiversity of Marylad [SEL 89]. NASA/GSFC develops ad maitais software for satellite systems. Util the recet itroductio of cotrolled experimetatio with Ada, these systems were developed i Fortra with some Assembly. The SEL has a very comprehesive data collectio program o NASA/GSFC software projects, ad the SEL database is distributed through the Data & Aalysis Ceter for Software (DACS).

7 Software systems for NASA/GSFC are typically produced o a cotractual basis. The cotractor is usually paid as costs are icurred with paymets exceedig costs by a specified amout. Although the cotractor should calculate the total worth of the project o a et preset value basis, the cotractor eed ot be cocered with the effects o et preset value of time differeces betwee reveues ad costs. O the other had, the govermet should accout for the time differeces betwee the costs icurred durig the developmet phase ad beefits obtaied while a system is fielded. Sice beefits are difficult to quatify, the data preseted here oly examies the distributio of life cycle costs. Costs are assumed to be proportioal to perso hours. The SEL has collected software developmet data from its iceptio. Maiteace data has bee collected sice the mid eighties, but oly three projects with developmet ad maiteace data have reached retiremet. The selectio of these three projects, idetified as Projects 68, 80, ad 8, may ot be represetative of NASA/GSFC projects i that they may have a atypically short operatios period. Table 3 summarizes the size of these projects. Maagemet ad techical effort data was collected weekly o these projects usig the SEL's Persoel Resources Form (PRF) durig developmet ad the Weekly Maiteace Effort Form (WMEF). Total maagemet ad techical effort was recorded o the Project Completio Statistics Form (PCSF) at the ed of the developmet phase, but the weekly data oly totals approximately two thirds of the PCSF values. So this data should be used with cautio for other purposes tha a mere illustratio. Project Table 3: NASA/SEL Project Iformatio Subsystems Compoets Pages of SLOC Documetatio SLOC for New Compoets ,974 5,704 33, ,45,500 36,393 5, ,690 78,68 4,084 Project 68 is a simulator with a emphasis o codig for efficiecy due to strict timig costraits. Figure shows the effort expeded durig its lifetime. The solid lie represets udiscouted labor hours, while the dashed lie represets a time discoutig based o a aual iterest rate of 30%. Typically the cost of capital is less, so the curves show represet upper ad lower bouds. Notice that curves become further apart for periods more distat from project iitiatio. Udiscouted maiteace costs overstate their importace i a ratioal accoutig framework. Projects 80 ad 8, show i Figures 3 ad 4, are both Attitude Groud Support Systems (AGSS) whose developmet schedules were cosiderably perturbed by the Challeger explosio. The Challeger accidet resulted i a delay i the lauch date for Project 80 ad a stretch-out of the schedule. Project 8 was actually halted for a short period ear the begiig of its developmet. Software chages accomodated a redesig of the spacecraft. Fluctuatios i effort over the lifecycle are oticable i both udiscouted ad discouted costs, but the magitude of these fluctuatios is oticably smaller whe time discoutig is performed properly.

9 3.4 Test ad Evaluatio Methods Suppose oe is tryig to decide betwee the use of two differet methods for detectig ad correctig faults o a software project. Oe method is a static aalysis method applicable early i the lifecycle, for example, a desig or code walkthrough based o the "stepwise abstractio" readig methodology described i [Liger 79]. The other method is fuctioal testig applicable durig some high-level testig phase, for example CSCI Testig or System Testig. The achievemet of a desired reliability goal at delivery, expressed as a failure rate, is a reasoable goal to adopt. This goal should be met for the miimum cost durig developmet, where cost is measured by the preset value of activities adopted for detectig ad correctig faults. A very simple model ca be used to illustrate some of the cosideratios that arise with preset value calculatios. Assume that the failure rate is directly proportioal to the umber of faults i a program. Hece, the desired failure rate is achieved oly if the umber of faults i the software system is below some specified value. Assume that the developmet process iserts a give umber of bugs, ad that this umber is idepedet of the activities ivolved i detectig ad correctig faults. I other words, whether a fault is removed at requiremets or permitted to remai util some later testig phase will ot ifluece how may additioal bugs are iserted. These assumptios are admittedly urealistic. They permit further expositio of this example ad demostrate a maagemet eed for more accurate empirical modelig of the software process. Table 4 presets the relevat parameters for the two methods.

10 Table 4: Parameters Describig Two Testig Methods Parameter Method I Method II Time applicable t t Cost per bug detected a a Cost of removig bug at b b time whe method is applicable Assume t < t ad the iterest rate is 00 r %. The preset values of the two methods, per detected ad removed bug, are: a + b PV I = t ( + r) (4) a + b PV II = t ( + r) (5) The differece i these two preset values is: a + = b PV II PVI ( a + ) b t ( + ) t r ( + r) t (6) The preset value of the cost of the first method is less tha the secod method, ad thus preferred, if ad oly if a + b + (7) ( + r) ( a b ) < t t Note the ifluece of the cost of capital, expressed as a iterest rate. Eve if the cost of both correctig ad detectig bugs is lower for the earlier method, the later method may still be cheaper i a preset value sese. Thus, the later method will be preferred if the iterest rate is high eough or the time betwee the two methods is log eough. Some empirical data suggests time discoutig will rarely overcome the greater cost effectiveess of test ad evaluatio methods that shift costs towards the begiig of the lifecycle. Suppose the two methods are code readig, performed durig the codig phase, ad fuctioal test, performed durig a later testig phase. Empirical data shows that i the NASA Software Egieerig Laboratory (NASA/SEL) eviromet, the average cost of detectig a bug by code readig is 0.3 hours. The average cost of detectig a bug by fuctioal test is hours [Basili 87]. Correctig a bug ca be reasoably assumed to be twice as expesive i test, as compared to the codig phase [Boehm 8]. Figure 5 is based o Equatio 3-5 ad these parameter values. I drawig this figure, eight hours is assumed to be required to correct a fault durig codig, but the frotier betwee the two methods is ot very sesitive to the value of this parameter.

11 Figure 5 shows that code readig is cheaper tha fuctioal test i preset value terms for all reasoable iterest rates ad schedules. The reductio of the cost of detectig ad correctig a bug durig codig more tha compesates for the effects of time discoutig. This coclusio ca probably be geeralized. The maager eedig to choose betwee alterate methods for fault detectio ad correctio may geerally fid the effects of deferrig bug correctios so costly that the earlier method is more ofte tha ot to be preferred. More empirical data is eeded to substatiate this coclusio. I particular, the savigs i preset value may deped o the type of bug ad how the cost of a method varies with the umber of bugs removed. This aalysis also throws a iterestig light o the purpose of testig. Cost effective uses of testig should ot be directed towards detectig ad correctig faults. Rather, the purpose of testig is evaluatio ad certificatio, icludig process evaluatio ad reliability certificatio. These coclusios coform to curret treds i testig ad Verificatio ad Validatio ([Duham 89], [Gelperi 88], [Mills 87]). 4.0 Coclusios This paper has preseted a fiacial aalysis framework for software lifecycle cost aalysis. With software becomig a ever more importat compoet i the budgets of may orgaizatios, models more sophisticated ad realistic tha those preseted i Sectio 3 eed to be developed to support optimal maagemet decisio-makig. Ufortuately, the empirical database eeded to develop better models does ot yet exist. For the most part, the software metric literature does ot reflect a awareess of the type of issues time discoutig ca raise.

12 This situatio eeds to chage. Users of software cost models should perform et preset value aalyses, ad the models should icorporate the eeded parameters. Researchers presetig experimetal results o the costs ad beefits of specific techiques should idicate how chages i the time distributio of costs ca affect the magitude of (udiscouted) beefits. The preset values of cost ad beefits will deped o specific details of idividual projects. Nevertheless, the simple aalyses preseted above suggest the reluctace of maagemet to address maiteace problems ad adopt ew techology may be more ratioal tha is commoly thought. Fiacial aalysis i a ucertai eviromet caot provide the fial word o techology, but it is time that software measuremet ad software developmet reflect a awareess of the eeds, methods, ad laguage of high-level maagemet. Refereces [Basili 87] V. R. Basili ad R. W. Selby, "Comparig the Effectiveess of Software Testig Strategies," IEEE Trasactios o Software Egieerig, Volume SE-3, Number, December 987. [Berry 9] Daiel M. Berry, Academic Legitimacy of the Software Egieerig Disciplie, Software Egieerig Istitute, CMU/SEI-9-TR-34, November 99. [Boehm 73] B. W. Boehm, "Software ad Its Impact: A Quatitative Assessmet," Datamatio, Volume 9, Number 5, May 973. [Boehm 8] Barry W. Boehm, Software Egieerig Ecoomics, Pretice-Hall, Ic. 98. [Copelad 78] Roald M. Copelad ad Paul E. Dascher, Maagerial Accoutig, Secod editio, Joh Wiley ad Sos, 978. [Duham 89] Jaet R. Duham, "V&V i the Next Decade," IEEE Software, Volume 6, Number 3, May 989. [Gelperi 88] David Gelperi ad Bill Hetzel, "The Growth of Software Testig," Commuicatios of the ACM, Volume 3, Number 6, Jue 988. [Harcourt 7] Geoff Harcourt, Some Cambridge Cotroversies i the Theory of Capital, Cambridge Uiversity Press, 97. [Humphrey 88] Watts S. Humphrey, "Characterizig Software Process: A Maturity Framework," IEEE Software, Volume 5, Number, pp , March 988. [Liger 79] R. C. Liger, H. D. Mills, ad B. I. Witt, Structured Programmig: Theory ad Practice, Addiso-Wesley 979. [Mills 87] Harla D. Mills, Michael Dyer, ad Richard C. Liger, "Clearoom Software Egieerig," IEEE Software, Volume 4, Number 6, September 987. [SEL 89] Database Orgaizatio ad User's Guide Revisio, Software Egieerig Laboratory, SEL-89-0, 989.

13 Ackowledgemets: R. Vieeau is with Kama Scieces Corporatio. This work was supported by the Data & Aalysis Ceter for Software, Cotract No. F C-058. The author would like to ackowledge helpful commets from the referees o a earlier draft. Origially published i the Joural of Parametrics, V. 5, N. (April 995): The fiacial aalysis techiques preseted here are well-accepted, but their foudatio i ecoomic theory is very much a matter of dispute. Cotroversy ceters o whether ay rigorous meaig ca be ascribed to the cocept of capital as fiace ad whether the ultimate determiats of the rate of iterest lie i idividual subjective prefereces or the objectively observable capability of productio to geerate a physically specified surplus of commodities [Harcourt 7]. 4 I a ucertai world, firms might also require that the time eeded to fully recover the costs of a ivestmet, the payback period, be below some specified maximum value. Other criteria for ivestmet decisios are discussed further i the fiacial aalysis literature.

CAPITAL PROJECT SCREENING AND SELECTION

CAPITAL PROJECT SCREENING AND SELECTION CAPITAL PROJECT SCREEIG AD SELECTIO Before studyig the three measures of ivestmet attractiveess, we will review a simple method that is commoly used to scree capital ivestmets. Oe of the primary cocers