Identifying the Importance of Software Reuse in COCOMO81, COCOMOII

CH.V .M.K. Ha ri. et a l /Intern ational Jou rnal on C omputer S cience and Engineeri ng V ol.1( 3), 2009, 142-147 142 Identifying the Importance of Software Reuse in COCOMO81, COCOMOII. CH.V .M.K.Hari #1 Prof. Prasad Reddy P .V .G .D $2 J.N.V . R Swarup Ku mar *3 G .SriRa mGanesh *3 #1 Associate Professor , Dept of IT , Gita m University , V isak hapatnam, India, kurmahari@gmail. com . $2 Dept.of CS & SE, Andhra University, Visakhapatnam, Ind ia . prof.prasa dreddy@gmail.com *3 Dept. of IT, Gitam Uni versity, Visakhapatn am, India, swarupjnvr@ya hoo.co.in , sriramganesh_g @yahoo.co.in . Abstract- Softw are project manage ment is an interpolatio n of project planning, project monitor ing and project termination. The substratal goals of planning are to s cout for the future, to diagnose the attri butes that are es sentially done fo r the consummation of the pr oject successfull y , animate the s cheduling and allocate r esour ces for the a ttributes. Softwar e cost estima tion is a vital r ole in pr eeminent soft ware proje ct decisions such as resour ce allo cation and bid ding. This paper articul ates the conventional ov erview of software cost estimatio n modus operandi a vailable. The cost, effort esti mates of softwar e projects done by the var ious companies are congregate d, the results are segregated with the pr esent cost model s and the MRE (Mean Relative Error) i s enumerated. W e h ave administered the historical data to COCOMO 81, COCOMO II model and identified tha t the stellar predicam ent is that no cost model gives the exact estima te of a software project. This is due to the fa ct that a lot of productivity fa ctors ar e not contempl ated in estimation pr ocess. The vita l dilemma we identified is th at “softwar e reus e” is b eing eclipsed although m ost of the contemporar y software pr ojects ar e based on ob ject oriented development wher e no component i s made from scratch (Inheritance). By using the principal of software r euse the ROI (Return of Investment) is a lso bolstered for the companies. So further r esear ch exposur e is in “so ftware Reu se” and Reuse software cost estimation model. Keywords - Reuse, Size, Effort, Cost estimation, COCOMO, MRE. I. I NTRODUCTI ON The concept of soft ware cost estimation has been g rowing rapidly due to pract ically and dem and for it . T oday the pe ople expecting hi gh quality of software wit h a low cost that i s goal of softwar e engineeri ng. So ma ny popular cost estim ation models l ike COCOMO 81, COCOM OII, SLIM, FP and Delphi. These m odels created by ta king historic al data app lied to regres sion analysis. A recent revi ew of surv eys on softwar e cost estim ation found that of s oftware projec ts have cost overruns. T oday most of the soft ware com panies follow COCOMOII f or estimating the cost of products; we found some variati ons in this model [ 1 1]. The se are several re asons like “unreali stic over-o ptimum” , “complexi ty”, “and overlook ed tasks” [9 ]. The reason we id entified are the peop le are develo ping the projects by using Ob ject Orient ed T echnologies with t he principl e of “softw are Reuse”. This paper we a re present som e popular software c ost estim ation models and a pplied sam ple data to m odels and cal culated the MRE. In section2 deals with the ove rview of the cost estimation models . In section5 deals with the calcu lation by using COCOM O81, COCOMOII and compar ison graphs fo r COCOMO m odels. The contri bution of thi s paper predi cts the importance the “Software Reuse”. Cost Estim ation process is an uncer tain activity b ecause o f inaccura te infor mation and future needs are not known in advan ce. II. B ACKGROUND A rev iew of the liter ature te lls the most intere sting difference between esti mated ef fort and origi nal ef fort, estim ation models that use KDLOC (Tho usands of Deli vered Lines of Code) as the pr imary input . This input is not suf ficient for accurately estimati ng the cost of products. S everal ot her paramete rs have to be consi dered. W e examine t he COCOMO81, C OCOMOII m odels. After exami ning these models we foun d some variations in t hese models. W e identified t he lar ge scale re use offe red by product line engineer ing promises a b est produc tivity and time-to- market. A. Single vari able method Software cost estimati on is the method fo r analyzing and predicti ng the amount of ef fort required to bui ld a software system. A traditional approach to esti mate eff ort of software creation a nd developm ent is to make t he effort as the functi on of a sing le variable. The variable which we use in this model is project size [ 4]. Effort= a*size b Where ef fort is in person-months, a & b are con stants deter mined by re gression an alysis app lied on his torical data. B. COCOMO81 Mo del Boehm desc ribed C OCOMO as a c ollection o f three vari ants: basic model, i ntermedi ate model, detail ed model [12] . 1) Basic model The basic COCOMO m odel compute s effort as function o f progra m size, and it is same as single variable metho d. Effort =a*size b Where a and b are the set of values depen ding on the complexit y of software . For the o rganic type of projec ts a=2.4, b=1.05, sem i-detached type of p rojects a=3. 0, b=1.12 , Embedded t ype of project s a=3.6, b= 1.2. 2) Intermediate model An inter mediate CO COMO model e ffort is calculated using a function of prog ram size and set of cost dri vers or effor t ISSN : 0975-3397 CH.V .M.K. Ha ri. et a l /Intern ational Jou rnal on C omputer S cience and Engineeri ng V ol.1( 3), 2009, 142-147 143 multipliers. Effort = (a*size b )*EAF where a and b are t he set of values depe nding on the complexit y of software an d EAF (Eff ort Adjustment Factor) which is ca lculated using 15 cost driver s [12]. Each cost driver is rated from ordinal sc ale ranging from low t o high. For the or ganic type of proje cts a=3.2, b=1. 05, semi-de tached type of pro jects a=3.0, b=1 .12, Embe dded type of pro jects a=2.8, b=1. 2. 3) Detailed model In deta iled COCOMO the effort is calculate d as functi on of program size and a set of cos t drivers given ac cording to eac h phase of so ftware lif e cycle. The phases used in detailed COCOMO are requirem ents planning and product des ign, detailed design, code and uni t test, an d integrati on testing. Eff ort = (a *size b )*EAF*sum(Wi). The weights of life cycle m odel are descri bed in [12]. The l ife cycle acti vities like req uirement planni ng, system desi gn, detailed de sign, code a nd unit test ing, integr ation and testi ng. In all above t hree models the fa ctors a and b are depe nd on the developm ent mode. C. COCOMO II Model Boehm and his col leagues have refined and upd ated COCOMO ca lled as CO COMO II. This consists of a pplicatio n composition mode l, early desi gn model, po st architect ure model . 1) The Applic ation Composition Model It uses object po ints for sizing rath er than the size of th e code. The initial size measure is determin ed by cou nting th e number of screens, re ports and t he third generatio n components that will be u sed in app lication. Effort = NOP/PROD Where NOP (New Object Points) = (object p oints)*(100- %reuse)/100, PROD (Product ivity Rate) =NOP/Per sonMonths 2) T he Early Design Mode l It uses to evaluate al ternative soft ware system architectures where unadj usted function point is used for sizing. Effort = a*KLOC*EAF Where a is s et to 2.45, EAF is calculate d as in origina l COCOMO model using seven cost drive r s (RCPX, RUSE, PDIF , PERS, PREX, FC IL, SCED) [12]. RUSE: Reuse is consider as one fact or , but it is a major factor for effort estimation. 3) T he Post Ar chitectur e Model It is use d during th e actual dev elopment an d mainte nance of a product. The post arc hitecture m odel includes a se t of 17 cost driver s [12] and a s et of 5 factors determin ing the projec ts scaling com ponent. Effort =(a*size b )*EAF Where a=2. 55 and b is calcul ated as b=1. 01+0.01*S UM(wi), wi= sum of weighted fact ors. D. SLIM Model Larry Pu tnam of Quantit ative So ftware Man agement developed The Software Lifecycle M odel (SLIM) i n 1970's [1,2,1 1]. SLIM is based on the concept of Norden-Ra yleigh curve which r epresents m anpower as a funct ion of time. The software equation for SLIM is de fined as fol lows: S = E*(Effort) 1/3 *td 4/3 Where td is the software d elivery time, E is the en vironmen t factor that reflects the de velopme nt capabilit y , which can be derived fr om historic al data using the softwa re equation. The size S is in LOC and the E ffort is in person-ye ar . Another important relati on is Effort = D 0 *td 3 Where D 0 is a pa rameter cal led manpo wer build-u p which ranges fr om 8 (entirely new softwa re with ma ny interfaces) t o 27 (rebuilt software). Com bining the above equat ion with the software equation, we obtain the power function form : Effort = (D 0 4/7 *E -9/7 )*S 9/7 and td =(D 0 -1/7 *E -3/7 )*S 3/7 SLIM is wide ly used in pr actice for la rge projects (mor e than 70 KDLOC) and S LIM is a soft ware tool ba sed on this model for cost esti mation and m anpower sche duling. E. Function Point Analysis (FP) It is one of the m ajor techni ques used for software cost es timation. It was intro duced by Alber tch [11]. The general a pproach tha t FP A follows i s • Count the number of in puts, outpu ts, inquirie s, master files, an d interf aces required , then calcu late the Unadju sted Functi on Points (UFP ) • Calculate the adjusted function p oint (AFP) by multiply ing these counts by an adjustme nt factor; the UFP and the product co mplexity adjustmen t. • Calculat e the Source Line s of Code (SLOC ) with the help of th e AFP and the Language Factor (LF). The FP A mea sur es functi onality th at the user req uires l ike the number of input s, outputs, i nquiries, master fi les, and interfaces req uired. The s pecific user funct ionality is a measurement of the perf ormance de livered by t he applica tion as per t he reque st of th e user . For each functi on ident ified above th e function is further classi fied as s imp l e, a ver ag e or complex and a weight are given to each . The sum of the weights qua ntifies the size o f information processing an d is referred to as the Unadju sted Function points. The function types and t he weighting fact ors for the varying com plexitie s [1 1]. T o calculat e the Comple xity adj ustmen t value, several fact ors have to be consi dered, suc h as Backup and recovery , code design for reuse, etc. All the factors and t heir estimated values in this p roject ar e already a vailabl e. The adjuste d function poi nt denoted by FP is given by the f ormula: ISSN : 0975-3397 CH.V .M.K. Ha ri. et a l /Intern ational Jou rnal on C omputer S cience and Engineeri ng V ol.1( 3), 2009, 142-147 144 FP = total UFP*(0.65 + ( 0.01 *T otal compl exity adjustme nt value)) or FP =total UFP *(Complexity adjustment fac tor) T otal complexity adjust ment value is cou nted based o n responses to questions cal led comple xity weighti ng factor s [1 1,12]. Each comple xity weightin g factor is assigned a val ue (complexi ty adjustment value) that range s between 0 (n ot important) to 5 (absolut ely essential ). F . Delphi model This model also known as an exper t judgment model, this model has be en followe d by most of t he software com panies that we have obser ved in l iterature s urvey . A meeting has been conducted for the expe rts and pr edicting the requirem ents about the project and coll ect the estim ations from all experts and distri bute to all of the m for discussi on and finally a nd the cost is determ ined by the following f ormula Estimation= (leastestim ation+4*avgest imation+hi ghestim ation )/6 III. RESEARCH QUESTIONS This copious study of software c ost estimati on ruminates contempora ry cost esti mation m odels and tri es to contemplat e on th e differences t hat pr evail betw een orig inal effort and calculated ef fort. It also considers m anifold cases and tabularize s them in an el ucidatory m anner . The m ain models that we scrutini ze are the COCOM O, Function Point model and SLIM. Q1: Why does a discrepancy arise betwee n the ori ginal ef fort and calculat ed effort ? What are the factors tha t are being preclude d by the user while g auging the c ost? Q2: Whic h factor portray s a vital role in software developm ent and wo uld reduce t he diff erence bet ween actua l effort and calculat ed effort? IV. SUR VEY METHOD This research has progressed by e xcogitating on the famous cost estimatio n models in hope of unveiling the different ways of guesstim ating the cost for a soft ware project. The formulae from the vari ous books, web and journal s have been congregate d and also histori cal data from past projects has been collect ed. The param eters which have been deliber ated are based on r egression analy sis of the dif ferent models. W e have amassed dat a from 30 proj ects [1 1,23,24] done by renowned com panies and this dat a has been exercised on all the model s and MRE has been calcul ated. This exhibits a lot of differenc e between a ctual effort and calc ulated effort in various m odels. Based on our ast ute observati on there is no commodious c ost estimati on model that dispenses wi th manifold projec ts. W e have visited perso nnel working wit h acclaime d organi zations and en quired the m in order to find evidence a nd most compa nies follow e xpert jud gment for determi ning the cost of t he product. Som e have admitt ed that they use a lot of softwa re tools for deve loping the product and construct p rograms from existing libraries. V. PRELIMINAR Y RESUL TS AND FUTURE RESEARCH (PERFORMANCE OF ESTI MA TION MODELS) TA B L E I COCOMO81 Basic Mode l Fig. 1 shows C OCOMO81 Basi c model graph. O riginal ef fort is below fo r all the possi bilities o f calcula ted effort. TA B L E I I COCOMO81 Intermediate Model with nom inal values ISSN : 0975-3397 CH.V .M.K. Ha ri. et a l /Intern ational Jou rnal on C omputer S cience and Engineeri ng V ol.1( 3), 2009, 142-147 145 Fig. 2 shows COCOM O81 Interm ediate model graph with nominal v alues. T ABLE III COCOMO81 Intermediate Model with High values Fig. 3 shows COCOM O81 Interm ediate m odel graph with High values. TA B L E I V COCOMO81 Detailed Model with nominal va lues Fig. 4 sho ws COCOMO81 Detailed m odel graph with nominal va lues. TA B L E V COCOMO81 Detailed Model with High values ISSN : 0975-3397 CH.V .M.K. Ha ri. et a l /Intern ational Jou rnal on C omputer S cience and Engineeri ng V ol.1( 3), 2009, 142-147 146 Fig. 5 shows COCOM O81 Detailed m odel graph with Hig h values. TA B L E V I COCOMOII Early Design Model Fig. 6 show s graph for C OCOMOII Earl y Design mode l. T ABLE VII COCOMOII Post Architecture Model Fig. 7 Fig. 7 s hows COCOM OII Post Architecture model gr aph. Similar ly the variations a re found in S LIM, FP model. [1 1] VI. DISCUSSION AND FUTURE WORK This research wo uld emphasi ze on the salience of sof tware reuse principles i n cognit ion with softw are cost es timatio n. Also we try to articulate the multifar ious ways in wh ich software r euse aids t he cause of cost estimation. W e are speculat ing on devi sing a c ost estimati on model whi ch highlights t he prepondera nce of reuse and el se reduce the MRE. W e are also trying t o peg the di ffere nt forms of reuse to reduce c ost and MR E. VII. CONCL USION This work on Soft ware Cost Estim ation explore s contempora ry cost estimat ion models and dif ferent ways of guesstimat ing the cost. It com pares COCOMOII which h as been widely used over the pas t years. Also it ponders over the other m odels SLIM, Funct ion Point Model and Del phi which have had profound i nfluence e specially in practic e. Furtherm ore it attem pts to put fort h the gist of softwa re reuse for future use . ISSN : 0975-3397 CH.V .M.K. Ha ri. et a l /Intern ational Jou rnal on C omputer S cience and Engineeri ng V ol.1( 3), 2009, 142-147 147 REFERENCES [ 1 ] Putnam. L. H. Gener al empirica l solution to the macro software sizing a nd estimating problem. IEEE T rans. Soffw . Eng. SE 4 , 4 (July1978 , 345-361). [ 2 ] Putnam. L.. and F itzsimmons, A. Estimat ing soft ware costs. Datamation 25, lo-1 2 (Sept.-N ov . 1979) . [ 3 ] Lionel C.B riand, Khale d EI Emam , Frank Bom arius, ”COBRA: A Hybrid Method for software Cost Estimati on, Benchmarking, a nd Risk asserssment”, Internati onal Soft ware Enginee ring Resea rch Network Tec hnical Repo rt ISERN-97- 24 (Revision 2) [ 4 ] An Integrate d Approac h for Software Engineerin g. Pankaj j alote [ 5 ] Software engin eering (3 rd Edition), New a ge Internationa l publisher s, k.k Aggarwal, yoge sh singh, ISBN-(13) : 978-81-224-236 0-0. [ 6 ] Sana Ben Abd allah Ben Lamine, Lamia Labed Jilani , Henda Hajja mi Ben Ghezala , Laboratoi re Riadi Gdl, Ecole Natio nale des scien ces de l’Inf ormatique campus Universita ire la Ma nouba, La Ma noub a, 2010, Tunisi a. “A Software Cost Estimati on Model for a Pro duct Line Engi neering Ap proach: Supporti ng tool and UML Modelli ng. (SERA’ 05). [ 7 ] Tanja Gruschke , Universit y of Oslo,” Em pirical studies of Soft ware Cost Estim ation: Training of Effort Estim ation Uncertai nty Assessment Skills”, 11 th IEEE Intern ational Sof tware Metr ics Symposiu m (METRICS’05). [ 8 ] Nasser Ta dayon, Dept of Com puter and Sof tware Engineeri ng, Embry Riddle Aer onautical Uni versity, “ Neural Netw ork Approach for So ftware Cost Estimati on, (ITCC’05). [ 9 ] Magne Jorgen sen, Stein Gri mstad, Si mula Research Laborator y, Norway, “O ver-Op timism in Softwar e Developm ent Projects : “The Winner’ s Curse”, (CONIELECOMP-2005). [10] Kjeti l Molokken- Ostvold, Mem ber, IEEE, a nd Magne Jor gensen, “ A Compari son of Software Project Ove rruns-Flexi ble Versus Seq uential Developm ent Models, IEEE Transa ctions on Software Engineeri ng,VOL.3 1, No.9, Sep -2005. [11] Ro bert W. Zm ud. An Em pirical V alidation o f Software Cost Estimation Mod els. Chris F .Ke merer , May 198 7 Volume 30 Num ber 5. [12] Kim Johnson, De pt Of Com puter Scien ce, Universit y of Calga ry, Alberta, Canada, “Software C ost Estimation: Me trics and Mode ls” (pag es 1 to 17). [13] Har eton Leung, Zhang Fan, Dept of Com puting, The Hong Kong P olytechnic Uni versity, “ So ftware C ost Estimati on “. [14] Boe hm B.W (198 1). Softwar e Engineeri ng Economics. P rentice Ha ll. [15] Boehm B.W ., Abts, C. ,Clark,B., and Devnani- chulani. S.(1997). CO COMO II Model Def inition Manual. The Univer sity Of South Cali fornia. [16] Fenton, N.E. and Pf leeger, S.L. (1997). “Software Metrics : A Ri gorous an d Practic al Appro ach. Internati onal Thom son Computer Press. [17] H umphrey, W .S. (199 0), “ Mana ging The S oftware Process. Ad dison-Wes ley Publish ing Company. [18] Jone s, C. (1 996). “Ap plied So ftware M easurement ” McGraw Hil l. [19] Park, R. (1992 ). “Software Size Me asurement: A Framewor k For Counti ng Source Li nes of Code” , Software Enginee ring Techni cal Repo rt. [20] Pillai, K.an d Sukumar an Nair, V.S.(1997) “A model for Software Development Effort and Cost Estimation”, IEEE Transactions on Software Engineering 23(8) 485-497. [21] Pressm an, R.S (1997), “Software E ngineeri ng A Practitio ner’s A pproach” McGraw Hill. [22] Sha w, M.(1995 ), “Cost And Eff ort Estimati on.” CPSC451 Lec ture Notes. The Un iversity of Ca lgary. [23] Dr Anthony L Rollo, Software Measureme nt Services Ltd, “Functional Size measurem ent and COCOMO – A synergistic ap proach”. [24] Mau rizio Morisio, Ioannis Stam elos, Daniel e Romano, Co rrado Moiso, “Framework Based Software Developm ent: Learni ng as an Invest ment Factor”. c ISSN : 0975-3397