CHAPTER 16 Software Economics ‘Software economics was first introduced in chapter 3 (section 3.7) though not by that erm. At that time, we were discussing the feasibility of the software engineering project. After reading chapter 3, one may get the impression that software cost is equal to development cost In this chapter, you wll see that the two are often diferent; that development costs just one component of software cost; and that there are other factors, ‘You will also see that determination of software cost, software price and software value are difficult issues that continue to be the subject of research and further refinement. The chapter proceeds under the following captions: ‘+ Software Cost versus Software Price + Software Value ‘+ Assessing Software Productivity ‘+ Estimation Techniques for Engineering Cost ‘+ Summary and Concluding Remarks 16.1 Software Cost versus Software Price ‘There ae few cases where software cost isthe same as software price; in most cases, they are diferent. Let us examine both. 16.1.1 Software Cost As mentioned in chapter 3 (section 3.7.4), there are many components that go into the cost of developing a software system. These cost components are summarized in igure 16-1 an‘GUPTER 16 » SOFTWARE ECONOMICS ‘os Compan ‘Conners aspen cs! Mote Fara i sare con co oT pr EME, pectoron Be squston uae pre. Fates Ca Pes carga alten totter Azle crt Expreatng Cos ues reson aes sy saws sk peer ox toregat Opes Cot Cos ol se log oc dar pep ple and Serer cst narra Figure 16-1. Software Engineering Cost Components Software engineering is a business as well as an applied science. The business ‘approach that many organizations employ is simply to put price tag on each of these ‘components basedon experience as well as business policies: The equipment cost, facilites cost and operational cos wll continue to remain purely business issues. The standard business approach for determining the engineering costs to mulply the “organization's prescribed hourly rate by the estimated number of hours required forthe ‘project. However, as you wil see later, there have been efforts to apply more scientific ‘and objective techniques tothe evaluating engineering cost through the exploration of ‘deterministic models. 16.1.2 Software Price Determining the software costs important but it does not complete the software ‘evaluation process. We must also determine the software (selling) price. Naturally the biggest contributor to software price is software cost. Three scenarios are worth noting: ‘© your organization is a software engineering firm and/or the product sto be marketed, then determining a selling price that ‘consumers will pay for the products critica. In this ease, the price may be significantly discounted since software cost can be recovered from multiple sales. ‘+ your organization is not asoftware engineering firm and/ ‘or the product will not be marketed o the consuming public, then the software price i likely tobe high, since its cost cannot bbe recovered from sale. In this case, the minimum price isthe software cost. + your organization is a software engineering firm contracted to build aproduct exclusively for another organization, then the software prices likely to be high, since the software engineering firm must recover its costs and make a profi. Figure 16-2 summarizes some of the main factors affecting software pricing, Please note that there may be other factors that affect the pricing ofthe software (for instance ‘other quality factors). The intent heres to emphasize that pricing a software system is not ‘straightforward or tiv matter. 272(GUAPTER 16 = SOFTWARE ECONOMICS ‘urkt Opporinly: The sang pica mayb scary dsinuried fn odep beak vn nen mate The soba exgneenng em ay anna ge eels mat areas of mare sd tele mat age png coeesoors ‘ne product You wl cal he eer hay between Mires ard Nea, nN tenderer Dundes lnret Exe sotwae fr fe win Bs Wows orang ssn, Necae poesia Ata conenguus coat tate, escape wor tbe ces wn te me Toy, Nsape Eng aca, ne Meron es ‘ewido sofware ergreeng fn. Uniqueness: The mae uu epoch higher epee abe, sefuiness and Guay: The lager he anipatd use of he rout te oer pce i ho be However, is ma be ose by padng mae eases io he protic The psf fe sours so acon ofl qual (an ‘wheter hs qual sown by oan uses}. A god cae parts BM psu many cases, be consumerg blake pay more ora rau! rom IBM Pan Bey wou he sane ped fom anche aan. Tas has otic fected IM sles, because general peaking (ad respective fore rd ote cp). hen you purchase a IM pad. yu ee geting a posit igh uly. Contacting Tems: It stare einer fm mas conto bul rout prior csone, hen f {he castane reas owner fhe sourcecode, spe scan neases. ote aera eave enwrng canta he source cae and user tr purposes, te ce sia rede, Reqarements Vola: he requromen ae a cange aver he short oc macun fem, a sobre engsrng femmay ler eb pen nr wna cone and neues dave fal wale changes he requremes separa pcs tm. Francia Heath: General poking, oa engnering fms hate fancy song a mse relat ower ‘he pcs tan hose hat ae ot OF rue, re ar excepns os observa. nec yer the corso publics beet tom huge concessionary ones fom eadng star engieerg ts ich as Orc, Mest, anda ‘Sofware Enginening Cost: As cafe in fg 181, Figure 16-2. Some Factors Affecting Software Pricing 16.2 Software Value The value of a software system may be different from the price. Whether your ‘organization intends to market the software or not, its often useful to place a value on the product, forthe following reasons: ‘+ Ifthe producti being marketed, placinga value onitcan provide a competitive advantage tothe host organization (i.e. the ‘organization that owns the product) ifthe value is significantly ‘more than the price. The host organization can then use this as marketing advantage to appear generous tits prospective consumers. ‘+ Ifthe producti being kept by the host organization, then having, value thas significantly higher than its price/cost makes the ‘acquisition more justifiable, ‘+ Whatever the situation, it makes sense to place avalue on the product from an accounting point of view. 273‘GUPTER 16 » SOFTWARE ECONOMICS ‘The big question is, how do we place a value on a software product? There is no set formula or method for answering this question; therefore we resort to estimation, ‘techniques. A common sense approach isto assume that software value isa function of any or each of the following: + Software cost + Productivity brought to the organization (and how this translates tw increased protit) + Costsavings brought to the organization In the end, determining a value forthe software system is a management function thats informed by software engineering, For this reason, we will examine some of the ‘estimation techniques that ae available (section 16.4) Before doing so, we will ake a ‘loser look at evaluating software productivity. 16.3 Evaluating Software Productivity ‘There are two approaches to assessing software productivity. One is to concentrate on the effort ofthe software engineer(s). The other isto concentrate on the added value to the ‘enterprise due tothe software product. Most of the proposed models tend to concentrate ‘onthe former approach. In keeping with the theme ofthe tex, and in the interest of ‘comprehensive coverage, we will examine both approaches. ‘A.common method of assessment of software productivity is to treatit as afunction of the productivity contribution ofthe software product, and the collective engineering. effort. Two common types of metrics have been discussed in Sommerville, 2006], They are sizesrelated metrics and function-related metrics. A third approach is a value-added ‘metrics; it attempts to determine and associated value added by a software system to an ‘organization. A brief discussion of each approach follows. 16.3.1 Size-related Metrics ‘Size-related methodologies rely on the software size as the main determinant of ‘productivity evaluation. Common units of measure are the number of lines of source ‘code, the number of object code instructions, and the numberof pages of system ‘documentation. To illustrate, asize-related metric may compute a software productivity index for a project, based on the formulae in Figure 16-3. 274(GUAPTER 16 = SOFTWARE ECONOMICS Pica) = LOOHET ey 1 Pica post ndex aston cde. ts expessedn ies cat pagan nn toc, 2 Loti he neonate, 4. DT iste dencpret tne, apessedm poyanme nant pn) Apeamer non st petra on sur hou cy ene aan be) = POOH) a ‘Pou ate prc ne be on ecard page acer pe Figure 16-3. Formulae for Sice-related Metres Associated with this approach are the following caveats: ‘© Ifdifferent programming languages are used on the same project, then making a single calculation for {Code} would be Incorrect, since the level of productivity varies from ane software development environment to another. Amore prudent approach would be to calculate the PI{Code} for each language and takea Weighted average. '* Most of the documented size-related metrics concentrate on lines of code, with scant or no regard for documentation. This plays squarely into the fallacy that software engineering is equivalent, to programming. The lower half of figure 16-3 has been added to provide balance and proper perspective tothe analysis. If as proposed by this course, more effort ought to be placed on software design than on software development, and thatthe latter should be an exciting and enjoyable follow-up ofthe former, then any evaluation of software cost or productivity should reflect that perspective ‘The main problem with this modelis thatit does not address the important matter of software quality. What ifthe software product and documentation are both voluminous due to faulty design? The model does not address this concern. 16.3.2 Function-related Metrics ‘Punction-related methodologies rely on the software functionality a the main determinant of productivity evaluation. The common unit of measure for these ‘methodologies is the function-points (FP) per programmer-month (a programmer-month 275‘GUPTER 16 » SOFTWARE ECONOMICS isthe time taken by one programmer for one month assuming anormal work week of 40 hours). The number offunction points foreach program i estimated based on the following + Bxtemal inputs and outputs + User interactions + Bxtemalinguiries + Filesused Additionally, a complexity weighting factor (originally inthe range of 3 to 15) is applied to each program. Next, an unadjusted function-point count (UFC) is calculated by ‘cumulating the initial function-points count times the weight, for each component: {UFC= BO) * CW) where FC the function pout cout for «propa componcl aad Wis the compen ev for that programs cone! ‘Next, complexity factors are assigned forthe project based on other factors such as code reuse, distributed processing, ec. The UFCis then multipliedto this/these ‘other complexity factor(s) to yield an adjusted function-point count AFC). Finally, the productivity index is calculated. Figure 16-1 summarizes the essence ofthe approach, Associated with this approach ‘are the following caveats: + ‘Theapproach language independent. + Wisarguable ast how effective this approach s for event-driven systems and systems developed in the OO paradigm. For this reason, object points have been proposed to replace function points for OO systems. We will discuss object-points later (ection 16.43) + ‘Theapproach s heavily based towards software development rather than the entire software engineering lifecycle. + ‘Theapproachis highly subjective. The function-points, weights, ‘and complexity factors are all subjectively assigned by the estimator. 276(GUAPTER 16 = SOFTWARE ECONOMICS 1, Dare Fan rec angone 2 ures 3IFC)* tm 5. len orang as fr be etc, C28 4 hrosureerca" 5 Pre aroyon = cise teconpoet cout a pagan cmp an W she mph al npn UFC te rain tector cont ArCis beads nto got cat. Pisinepoacoty aor acres tncongort cars pe poyannerneth ie Fpm DT ate emepnetine, opessednpeayanne rar ‘Figure 16-4. Calculations for Function-related Metrics ‘The matter of software quality stil remains a concem, though to some extent, it has been addressed.n the software's functionality. Indeed, itcan be argued that to some extent, ‘software system's functionality is determined by the quality of the software design. 16.3.3 Assessment Based on Value Added ‘There is much work in the area of value-added assessment in the field of education as ‘wells other more traditional engineering fields. Unfortunately, the software engineering {industry is somewhat lacking in this area In value-added software assessment, we ask and attempt to obtain the answer to the question, what value has been added to the organization by introduction ofa software system ora set of software systems? In pursuing an accurate answer to this question, there are two alternatives that are available tothe software engineer: ‘+ Evaluate the additional revenue thatthe software system facilitated. ‘+ Evaluate the reduced expenditure that the software system has contributed to. ‘These alternatives are by no means mutually exclusive; in fact, in many instances they both apply. One way to conduct the analysis is to estimate the useful economic life of the software system, and compute the above-mentioned values over that period. In hindsight, this may be challenging, but by no means insurmountable. However the reality is, in most cases, itis desirable to conduct this analysis prio to the end of the economic life ofthe system. Moreover, in many cases, this analysis is required up front, as part of the feasibility study for a software engineering venture (review section 3.7). Figure 16-5 provides two formulae that may be employed in estimating the value added by a software system. The first facilitates a crude estimate, assuming that interest rates remain constant over the period of analysis (of course, ths isnot practical, which is. hy it’s described as a crude estimate). Since this approach involves taking the difference between the value added and the acquisition cost, you may call itthe diference method. The second formula computes the net present value (NPV), with due consideration to interest rates; itis considered a more realistic estimate. The simple adjustment tobe made hereis to ensure that the cash low per annum includes additional revenue due to the system as well as reduced expenditure due tothe system, 277‘GUPTER 16 » SOFTWARE ECONOMICS ‘= (EVA) CIEL) key: 1 ste stare van dolar 2. EVA be extra va aed Wich sinzeasd avenue + edvcten expend) 3. AC\s be acquson cost of he sfvare 44 ELie eesti exo Hof he stare nye, NEVE -Ae Ailton) Al (ie? ++ Al Or key: t Va bert psec ab, Rao you pul nado he present he ze ae he sar yt tar yeas 2. Abie intl nesnent 3. ie aaa cash tow (ich incase verse + econo expends). 4. 4 indore ctineest, Figure 1645, Estimating Software Value-added 16.4 Estimation Techniques for Engineering Cost In the foregoing discussion, the importance ofthe engineering costand the challenges ‘toaccurately determining itwere emphasized. In section 161, twas mentioned that the standard business approach to estimating engineering costs to multiply the estimated project duration (in hours) by the organization's prescribed hourly engineering rate. In ‘this section, we will examine the engineering cost a bit closer, and look at other models forcostestimation (Our discussion commences with the work of Barry Boehm [Boehm, 2002}, According to ‘the Bochm model for cost estimation, there are ive approaches to software cost estimation (amore precisely, the software engineering cost estimation) as summarized below: + Algorithmic Cost Modeling: The cost is determined as a function ofthe effor. © Expert Judgment: A group of experts assess the project and estimate ts cost. ‘© Analogy: The project is compared to some other completed ‘project in the same application domain, and its cost is estimated. ‘© Parkinson's Law: The project cost i based on convenience factors such as available resources, and time horizon. ‘+ Pricing Based on Consumer: The projectis assigned a cost based, ‘on the consumer's financial resources, and not necessarily onthe software requirements. Obviously, the latter four proposals ae highly subjective and error-prone; they will ‘not be explored any further. The algorithmic approach has generated much interest and. ‘subsequent proposals over the past twenty-five years, some of which have been listed for recommended readings. 278(GUAPTER 16 = SOFTWARE ECONOMICS 16.4.1 Algorithmic Cost Models Algorithmic cost models assume that project cost is a function of other project factors such as size, number of sofware engineers, and possibly others. A such, each cost model uses a mathematical formula to compute an index for the software engineering effort (E). ‘The cost is then determined based on the evaluation ofthe effort. Figure 16-6 outlines the ‘ypical cost mode. @ ey 1 Te domes ta eatin oar mnt 2. ABansC avenge cevscortns 5. Pisbepomay put nLOcr Pe Figure 16-6. Typical Cost Model By way of observation, the exponent C typically lies in the range (0.8. 1.5}. The constants A,B, and Care called adjustment parameters, and they are determined by project characteristics (such as compleaity, experience of the project team members, the development environment, etc). Pressman [Pressman, 2005] lists a number of specific cases-in-point of this cost ‘model, such as: + Bes.27(KLocy* . theWatson-Feix model + B255+073*(KLOC)™ ..theDailey-Basli model = B=3.2"(KLOC)™ the COCOMO Basic model + B=5.288*(KLOC)™” —._theDotymodelforKLOC>9 + Be-914+0355°(0P) the Albrecht & Gaffney model + B2-97+096"(EP) the Kemerer model + B=-1288+0405*(FP) .._thesmall project regression model Note In the above examples, the acronym KLOC means thousand lines of code. 279‘GUPTER 16 » SOFTWARE ECONOMICS 16.4.2 The COCOMO Model ‘Boehm frst proposed the Constructive Cost Model (COCOMO) in 1961, and since then it hhas matured to the status of international fame. The basic model was ofthe form. (EAP) where EAF denotes he eff adjutment itr (oa 1 in the asc model) Boehm used a three-mode approach, as follows (Figure 16-7 provides the formula ‘used for each model): ‘* Onganle Mode — for relatively simple projects. + Semi-detached Mode — for intermediate-level projects with ‘team members of limited experience. + Embedded Mode {or complex projects with rigid constraints, Eee" 00) | Samant E680" qLOGp? Envetiet E536" 9L0G)™ ‘Figure 16-7. COCOMO Formulae The original COCOMO model was designed based on traditional procedural ‘programming in languages such as C, Fortran, etc. Additionally, most (if not all software ‘engineering projects were pursued based on the waterfall model. The next subsection discusses Bochm's revision ofthis basic model. 16.4.3 The COCOMO II Model ‘Software engineering has changed significantly since the basic COCOMO model was first introduced. Atthe time of introduction, OOM was just an emerging idea, and most software engineering projects followed the waterfall model. In contrast today, most software engineering projects are pursued in the OO paradigm, and the waterfall model thas given way to more flexible, responsive approaches (review chapter 1). In 1997, Boehm ‘and his colleagues introduced a revised COCOMO Il model to facilitate the changes in the software engineering paradigm. ‘The COCOMO II model is more inclusive, and receptive to OO software development tools, It facilitates assessment based on the following + Number oflines ofsource code + Number of object points or function points + Number oflines of ende reused or generated + Number of application points(GUAPTER 16 = SOFTWARE ECONOMICS ‘The changes relate to application points and code reuse/generation — features of contemporary 00 software development tools. We will address both in whats called the ‘application composition model. Two other sub-models of COCOMO are the early design ‘model and the post-architecture model. ‘Application Composition Modet In the application composition model, we are interested in object points (OP) as opposed to function points (FP). The model can be explained in seven steps as summarized below: 1. ‘The number of object points ina software system is the Weighted estimate ofthe following: ‘+ Thenumber of separate screens displayed + Thenumber of reports produced + Thenumber of components that must be developed to supplement the application 2. Bach object instanceis classified into one of three complexity levels — simple, medium or difficult — accordingtothe schedule in Figure 16-8. ‘Number and Source of Data Tables Required Total<4 | Total $=7 | Totl>=8 No.of VewslSections Contained ina Screen or Report <3 ‘Single | Simple | Medium 3-7 ‘Smple | Medi | cat Medium | ifcut | Dc Figure 16-8. Object Instance Classification Guide 3. Thenumber of screens, reports, and components are weighted according to the schedule in figure 16-9. The Weights actually represent the relative effort required to Implement an instance of that complexity level ‘Object Classification ‘Simple [Medium — | Difficult Soren 1 ecm |e! Repo 2 5 6 ‘Component 0 Figure 16-9. Complexity Weights for Object Classifications 4. Determine the objet point count (OPC) by multiplying the original number of object instances by the weighting factor, and summing to obtain the total OPC. Figure 16-10a clarifies the calculation and Figure 16-10b provides an ilustration, 281‘GUPTER 16 » SOFTWARE ECONOMICS ‘OPC = Sie) (4) key: 1. Nlis number tinstances of a particular object clastlcaton screen, rept or component) ‘and Wis the weight or hat object classif\eatn, 2 OPCs he bec pon count Figure 16-10a, Calculating the OPC ‘Object Cassication | Occurrence | Complexity | Weight | OPC ‘Seren 10 | Seple i 10 ‘Swen 10 | Meu 2 20 ‘Soren 6__| Deut 3 8 ‘Component 8 | Deut 10 8 Total OPC 106 Figure 16-10b, Mustrating Calculation ofthe OPC 5. Calculate the number of object points (NOP) by adjusting the ‘OPC based on the level of code reuse in the application: [NOP = (OPC) = [400 Paee 100) 6 Determine a productivity rate (PR) forthe project, based on. the schedule of Figure 16-11. Note that the schedule that it is in the project's best interest to have a project team of very talented and experienced software engineers, and to use the best software development thats available. “Team Quay aw [tow [Norinal [igh [Very igh ‘Development Too! Gualiy Low [Low | Nominal_—| igh [Ver igh Productivity Rate 4 7 18 2 16. Note: 1 Team Quality incues he capabiitis and talent ofthe tam meres 2 Development il uaiy cles he maturly and capabiies of he stare development too employed. Figure 16-11. Productivity Rate Schedule ‘Compute the effort (E) via the formula E=(NOP)* (PR)(GUAPTER 16 = SOFTWARE ECONOMICS Figure 16-12 summarizes the steps in the application composition model. With practice on real projects, you will become more comfortable with this cost estimation technique. The important thing to remember about the models thatthe software cost is construed to bea function ofthe engineering effort, and the complexity ofthe software. |e sees, repats and compote he scare sson (Gast ech cjet tance a ple medum or dle based onthe sched of ge 16 8 Assign corgi weight each projec seen, pot or component accorng othe sea of foe 18 Cala OPC based on te oes OPC = SIN) Cate be NOP based on te oma NOP = (OPC) * 10 Rusey 10] ‘etm Pfr proj Basan Schedule of fee 16 1. Calta fer taed on frm = (NOP) PR) Figure 16-12. Summary ofthe Application Composition Model Early Design Model The early design models recommended for the early stages the software engineering projec (after the requirements specification has been prepared). A full discussion of the approach will not be conducted here, but asummary follows. ‘The formula used for calculating effortis + * (EAR) where EAF denotes the effort amen factor As clarified earlier, B and Care constants, and P denotes the primary input (estimated LOC or FP). Based on Bochm’s experiments, Ais recommended tobe 2.94, and C may vary between 1.1 and 1.24. The EAP is a multiplier that is determined based ‘on the following seven factors (called cost drivers) Inthe interes of clarity the originally proposed acronyms have been changed: ‘+ Product Reliability and Complexity (PRC) 1+ Required Reuse (RR) ‘+ Platform Difficulty (PD) ‘+ Personnel Capability (PC) ‘+ Personnel Experience (PE) + Facilites (F) + Schedule(s) EAP=(PRO)* (RR) *(PD)* (PO)*PH*O*S 283‘GUPTER 16 » SOFTWARE ECONOMICS Post-Architecture Model ‘The post architecture modelis the most detailed of the COCOMO I sub-model. is, recommend for use during actual development, and subsequent maintenance of the sofware system (chapter 18 discusses software maintenance). The formula used for calculating efforts of identical form as forthe early design ‘mode: E=B +P * (EAR where EAF denotes the effet aja factor In this case, Bis empirically recommended to be 2.55 and Cis calculated via the formula {C= 101+ GO SICW) wie CW sepeseats capability weighs caitatedtevedon characteristic of he ‘eject eam and the how expaiation ‘The criteria (also called scale factors) used wo assign capabiliy weights (CW) about the projectand the project team are as follows: + Precedence: Does the organization have prior experience working on a sinallar project? + Development Flexibility: The degree of flexibility in the software development process. + Architecture/Risk Resolution: How much rsk analysis has been done, and what stepshave been taken tolessen of eliminate these risks? + Team Cohesion: How cohesive isthe team? + Process Maturity: What i the process maturity ofthe ‘organization? How capable i itin successfully pursuing this projet? igure 16-13 provides the recommended schedule for determining the capability ‘weight for these criteria. As an be seen fom the igure, the weights range fom 0 (extra high) to 6 (very ow). ‘apni Fate Veylew [Low | Nomina | igh [Ver gh Prec aos [3a [2a [102 [oat DeseupreniPaniy [gor [405 [364 [zas 121 eck Resin — [422 [398 [253 [169 [oat Tea steson isi 355 | 297 | 1980s Press May 45 {3e 2739 [xa Tost Figure 16-13. Capability Weights Schedule(GUAPTER 16 = SOFTWARE ECONOMICS ‘The EAFis determined from a much wider range of factors than the early design ‘model. Here, there are seventeen factors (cost rivers. Figure 16-4 lists these cost drivers alongwith their assigned ratings. In the intrest of cary the original acronyms have been changed. The EAFis the product ofthese cost mukipies. ‘CpabiyFotor Very Low [Low | Nominal High | Ver High | Extra igh Prowat Requre Star Rolbiy RS] 7s [ome [oo Tass [ae Daabse Sas (8S) 08 [100 [108-18 Proc Conley (C5 ono [ome [00 — [iss Piao 16 Regard Rewsabiy t ‘Ost [100 [4m [ize [140 Doeeraon (Oo) 05s [100 nae [1.18 Pastor: vein Tine Costa TC ear Man Stage Constant USC) : = — [hoo [a6 fat — [57 Paton Vet PV) oar [to [115 [130 Personne ‘oat Capi AC) 1a0__[1 [100 [ows [oar Prone Caps Pog 131 [116 [190 [oar fare sonnel Coir (Psi) ‘ia —[190- [100 [ose Tose opens Expenere (A 122 [130 [1.00 [oss [ost Palo xpererce PE} ‘25 [132 [100 [ass ost Language ar Tol Experi (TE) tz [130 [1.00 [ost [ose Project Str Too (ST im _—_[1m@ [oo [oss [or —T- at se Devlpmest ND) 125 [130-[ 1.00 [ose [ oa [are Deven Sheds 05 29 [130-T.00 —To0-}100 1 Figure 16-14. Post-Architecture Cost Drivers Schedule ‘You have no doubt observed that this is quite a complex cost model. It must be ‘emphasized that in order tobe of any use, the model must be calibrated to suit the local situation, based on local history. Moreover, there is considerable scope for uncertainty {in estimation of values forthe various factors. The model must therefore be used asa guideline, not alaw cast in stone. 16.5 Summary and Concluding Remarks {Lotus umamaree what we have dlocuated i ha chapter: ‘+ Software cost is comprised of equipment cos, facilities cost, engineering cost and operational cost. Equipment cos, facilities, cost, and operational cos, are determined by following standard. bbusiness procedures. Engineering cost may be determined using standard business procedures also, but in software engineering, Weare also interested in fine-tuning the estimation of this cost componentby exploring more deterministic models. 285‘OUPTER 16 286 SOFTWARE ECONOMICS Software price is influenced by factors including (but not confined ‘to software cost, market opportunity, uniqueness, usefulness and ‘quality, contracting terms, requirements volatility, and financial health of the organization that owns the product. Software value is influenced by software cos, productivity brought the organization, and cost savings brought tothe organization. Software productivity may be evaluated based on the software ‘engineering effort employed in planning and constructing the product, or based on the value added to the organization, ‘Two metrics used for evaluating the engineering effort are the size-based metrics, and the function-based metrics. Two methods for evaluating value added are the difference method, and the [NPV analysis method. ‘The size-based metrics estimate productivity based on the ‘number of lines of code and pages of documentation of the software Function-based metrics estimate productivity based on the ‘number of function-points ofthe software. Value-added metrics attempt to estimate the value added to the ‘organization by the software. ‘Techniques for estimating engineering costs include algorithmic ‘cost modeling, expert judgment, analogy, Parkinson's Law, and pricing based on consumer. Algorithmic cost modeling presents ‘uch research interest in software engineering. ‘The ypical formula for evaluating engineering effort in algorithmic cost modelingis E= A+ B* Pe. ‘The COCOMO model uses three derivations ofthe basic algorithmic cost modeling formula. The model relates to ‘traditional systems developed in the FO paradigm. ‘The COCOMO II model is revision ofthe basic COCOMO ‘model, o facilitate more contemporary software systems developed in the OO paradigm. Iincludes an application ‘component model, an early design model, and a post-architecture ‘model. ‘The application composition model outlines a seven-step ‘approach for obtaining an evaluation of the engineering effort of the software system. This is summarized in Figure 16-12.(GUAPTER 16 = SOFTWARE ECONOMICS ‘The early design model uses an adjusted formula for evaluating the engineering effort. The formula is E=B * P°*(EAF), and certain precautions must be followed when usingit. ‘The post-architecture model uses the same formula E=B*P°* (EAR); however, the precautions to be followed are much more elaborate. ‘We have covered a lot of ground towards building software systems of a high quality. The deliverable that comes out of the software development phase is the actual product! Its therefore time to discuss implementation and maintenance. The next three chapters will do that. 16.6 Review Questions 2 What s the difference between software cost and software price? What are the components of software cost? What are the challenges to determining software cost? State and briefly discuss the main factors that influence software price? Howis software value determined? What are the challenges to determining software value? State three approaches to evaluating software productivity. Foreach approach, outline a methodology, and briefly highlight its limitations. dently Bochms Ave approaches to software cost estimation, Which approach provides the most interes for software engineers? Describe the basic algorithmic cost model that many software costing techniques employ. Describe the COCOMOI model Choose a software engineering project that you are familiar with, a. Using the COCOMO I! Application Composition Model, ‘determine an evaluation ofthe engineering effort of the Project. Using the COCOMO 11 Early Design Model, determine an ‘evaluation ofthe engineering effort ofthe project. 287