10.1. BASICS OF COST ESTIMATION Avcurate software cost estimation is important for the successful completios « software project. However, the need and importance of software cost estima is underestimated duc to the following reasons: 1s of the software dev clopment process is not considered while estima @Atis difficult to estimate software costs and intractable accurately, as software is intane™ (bere are many parameters (also availabilt However Lihabiis. snchare coment aetoh8) SH ws complex ofwate sie 1 ewisered gy ane of the cost estumal in pararesFigure 10.2 Project X > Resources oOwa Project Objectives & Requirements |< od v Plan Activity (WBS) y Estimate Size!) y wha "Estimate Cost and Efer] cf v v _~ Estimate Schedule v Risk As ee . Rak assenal Ins eee | Software Cost Estimation Figure 10.3 Software Cost Estimation ‘ ed Processienyiig Project Objectives and Requirements {iis ph are nev the objectives and requirements for the Project are identified, which sary to estimate cost accurately and accomplish usér requirements. The project objective defines the end product, intermediate steps involved in deliverin, the end product, end date of the project, and individuals involved in the project. 4 This phase also defines the constraints/limitations that affect the project in meeting es. Constraints may arise due to the following factors: * Aaa date and completion date of the project. #/Availability and use of appropriate resources. * Policies and Procedures that require explanations regarding their implementation. : Project cost can be accurately estimated once all the requirements are known. coe tl requirements are not known, then the cost estimate is based only he ton ‘quirements. For example, if software is developed according to "ues l development model, thea the cost estimation is based on the “Mens that have been defined for that incr :Planning Activities - erent set of acti c oftware development project involves different s tof act ic fi e according to the quire! el : jeveloping software accord cer ents, Thess dev - font in_fields of software maintenance, software proj ere iftware quality assurance, and software configuration management The, cot fice arch areamedin the work breakdown structure according to] acuyiti ng akdown structure accor hei importan Work breakdown structure (WBS) is the process of dividisyg Le Project ints tasks dnd ordering them according to the specified sequence. WBS eee Only the tasks that are performed and not the process by which these a S are to be completed. This is because WBS is based on requirements and not the manner jp se tasks are carried out which thi _E&timating Product Size ‘Once the WBS is established, product size is calculated b i he size ofits components Estimating product size is an important step in cost estimation as most of the cost estimation models ustatty consider size as the major input factor, Also, project m ers consider product size as a major technical pert mance indicator or productivity indicator, which allows them to track a Project during “Software _development.) _Bationatin, ig Effort Once the size of the project is known, cost is ¢: lated by estimatin; effort, which is expressed in terms of person-month (PM). ood s (like COCOMO, COCOMO II. expert judgment, top-down, bottom-up, estimation by analogy.) Parkinson’s principal, and price to win) are used to estimate effort. Note that for cost estimation more than one model is used, so that cost estimated by one model can be verified by another model. \_ Estimating Schedule (Schedule determines the start date and end date of the project. Schedule estimate _is developed either manually or with the ited tools, To develop 2 1S Sinate minally.g numberof stops ae followed a sted belo ik kdown structure is ¢ & A schedule for development is developed independently, The schedule for cach set of the estimated time r derived for ZX. * of independent 4.y lek Assessment : isks are involved in every phase of software development; therefore, risks \anatina sofiware project should be defined and analyzed, and the impact of y the costs should also be determined. Ignoring risks cant tead to ccts, such as increased costs in the later stages of software Geelopment{ In the cost estimation process, four risk areas are considered, which are listed in Table 10.2. the project ¢ Inspect and Approve ive of thi To ensure that the ate correct.Heese Coe extimation, "1 , _Tracking Estimates (Tracking estimate over a period of time is essential, as it helps in compar mates, resolving any discrep a Current Estimate to previous es nies Wilh fy i th, eee a ee ee ee eee a eles with Brg, estimates, comparing planned cost estimates and actua estimates This h 5 ats he} Keeping track of the changes in a software project over a period o Ps z= ——__=— 7 = cl also-allows the developme SIE : time Tray i of a historical database of estimates, w Ich ca me i 5 n used to adjust various cost models or to compare past estimates to future stim, ate, Voy Process Measuring and Improving (Metrics should be collected (in each step) .to improve t the cost estimation proces, For this. two types of process metrics are used namely, process effective Metrics ce a SS Mefries Are Used Ne POCESS CECCHIVE metrig S he benefit of collecting these“metrics 1s to. Specify 2 s between the accuracy of the estimates and the cog > reciprocal relation that ex of developing the estimat ¢@ Process effective metrics: Keeps track of the effects of cost estimating process. The objective is to identify elements of the estimation process, which enhance the estimation process.(These metrics also identify those clemeny Which are of little or no U8éT0 the planning and tracking processes of a roject, The elements that do not enhance the accuracy of estimates should be isolated and eliminated. Process cost metrics: Qrovides information about implementation and performance cost incurred in the estimation process. The objective is to quantifi and tdentify-different increase the cost effectiven 7 ocesy ; INES ics, ae less of the pre ties that cost-effecti ely cnhanee ae and tracking process remain intact, vely enhance the project planning while activiti : ee on the project are eliminated. activities that have negligible affect10.4.1 Constructive Cost Model (Inthe early 1980s, Barry Boehm developed a model called COCOMO (COnsinuc, 1) to estim | effort required to develop a software projee TOCOMO model “omc used as itis based on the gt dy of Iready develop soliware proj While estimating total ffort for a software project, cosy development, management, and other su ort tasks are incl ided. However, co, sland other staff are excluded. In this model, size is measured in tem I red lines of code (KDLOC). accurately, the COCOMO model divides projec aie * 6 In order to estimate eff into three categorie @ Organic Projects: hese projects are small in size (not more than 50 KDLOC) ~~ and thus easy to develop. In organic projects, small teams ith prior experience work together to accomplish user, requirements which are less demanding Most people involved in these projects have a thorough understanding of how the software under development contributes to achieving the or; ion ; eer ieee re object Examples of organic projects include’ simple business syste. inventory management system, payroll management system. and library management system. a Emb jects: @ : a # a peered pc eca gel Get lea complex in nature (size is mot ) and organizations have less experience in developing such type of proj Mee prolees. Develo ers also have to meet stringent user requirempem!s projects are developed under tight constraints (hardware software, and people). Exampl i ee nie ogee systems include software syste™ g/Semi-detached Projects: The: requirements are less strii jects are less complex as us! siren xe se nn ent com ared to embedded projects. The size 4 ae an 300 KDLOC. Examples of semi-detached clude operating system, compiler design, and database design; 49.10: Values of Constants for Different Projects (Basis Model) table 10.1"" only the sizeof project is considered while calculating effort. the following equation (known as effort equation): o (5) s the effort in person-months and size is measured in terms of KDLOC. The values of constants “A’ and “B* de id on vare jodel., values of constants (“A’ and ‘B’) for three different types of projects are listed in Table 10.10. _ For ample, if the project is an organie project having a size of 30 KDLOC, then effor is calculated using equation (5): <-> ven effort is calculated using equation (5); E=24 » (30)'% E=85 PM Tee Intermediate Model In the interme; : diate model, Parameters like software Teliabili Sina SE also considered along > and software stimate with the size, whil i fon {An Wel effon in this model, a number Of steps = Ine reir. To ee £15 parameters derived tthe are rated against ‘THultiplyige Stent factor (EAN “plying factors with each other. Adjust the mate of development effort by calcula Y — ee OY multipy in step 1 with EAF.ry ject Organic project semi-detached project Embedded project = i a mentioned steps properly, let us consider aney, Tounderstand the papencate whose size is 45 KDLOC is cong implicit ns, an is con For a cl the values of constants (A a 3 be listed in 7 itt aera total effort in this model, a number of steps are ‘ole 10.11. ; which are listed below. - ipofefiont opation 8 it i is calculated with the help of ql n (5). % } A eltionship between size and the effort required to doa mee project. This relationship is given by the following equation, E.=Ax (size)® i “ae Whee risthe estimate of initial effort in person-months and size is m s in terms of KDOC. The value of constants ‘A’ and ‘B’ depend on the type software project (organic, embedded, and semi-detached). In this model, Valge | of constants for different types of projects are listed in Table 10.1, Using the equation (6) and the value of constant for organic project, ini effort can be calculated as follows: Te ’ 2 x (45) = 174 PM ———— 2 a 2, Fifteen parameters are identified. These parameters are called epst driver attributes, which are rated as very Jow, low, nominal, high, véry high extremely high. For example, in Table 10.12, reliability of a project canbe rated according to this rating scale. In the same table, the corresponding | multiplying factors for reliability are 0.75, 0.88, 1.00, 1.15 and 1.40. i Next, the multiplying factors of all cast drivers considered for the project multiplied with -each-other to-obtain EAF. For instance, using cost drives | listed in Table 10.13, EAF is caoulated as: a ENF 0.8895 (1.15 « 0.85 «0.91 x 1.00 3. Once EAF is calculated, the effort estim: ct f lates for a software project is ot by multiplying EAF with initial esti r byn ui ving Mnitial estimate (E), To calculate ei fort use the 4 Total effort =. EAF x E, wen example, the total éffort wil} be 155 PM. ance Model (ithe advance mo, ofpen he 44; Multiplying Factors for ACAP in Difterent Pha Je 10.14: [RP | ‘or example, a software project (of organic project type) with a size. KDLOC and rating of ACAP cost driver as nominal is considered (that is 1.0 calculate effort for code and unit test phase in this example, only ACAP ¢ drivers are considered. Initial effort can be calculated by using equation (6 B,=3.2 x (45)! = 174 PM Using the value of E,, final estimate of effort can be calculated by using following equation: EEE aed E=Ex1 —— That is, E=174 x | = 174 PM