A CASE STUDY OF EFFORT ESTIMATION IN AGILE SOFTWARE DEVELOPMENT USING USE CASE POINTS

Transcription

1 Sci.In.(Lahore),25(4), ,2013 ISSN ; CODEN: SINTE A CASE STUDY OF EFFORT ESTIMATION IN AGILE SOFTWARE DEVELOPMENT USING USE CASE POINTS Zhamri Che Ani (Universii Uara Malaysia, Sinok, Malaysia zhamri@uum.edu.my) Shuib Basri (Universii TeknologiPeronas, Tronoh, Malaysia shuib_basri@peronas.com.my) ABSTRACT:Research on effor esimaion in sofware developmen has been conduced for decades and has produced quaniies of models and ools. Unforunaely, reliable iniial esimaes are quie difficul o obain because of he lack of deailed informaion a an early sage of he developmen. To overcome his problem, use case poins (UCP) is seen as one of he proven mehods used by many sofware praciioners o esimae effor required o develop sofware applicaions. However, his mehod can be difficul o use in some cases, paricularly in Agile sofware developmen where he Produc Backlog does no saisfy a number of condiions in use case documenaion. Therefore, his paper looks a he poenial of successful applicaion of he UCP mehod for esimaing he effor of Agile sofware developmen projecs, including he major limiaions and offers some possible recommendaion on how o make simpler esimaion in early sage of he sofware developmen. The resuls indicae ha alhough he effor required produced by UCP mehod has lile differences compared o he acual esimae, bu he resuls sill can be acceped due o small percenage of gap. 1. INTRODUCTION Research on effor esimaion in sofware developmen has been conduced for decades and has produced quaniies of models and ools [1], [2], [3]. Unforunaely, reliable iniial esimaes are quie difficul o obain because lack of deailed informaion a an early sage of he sofware developmen where he requiremen specificaion, sofware design and he code size are no clear ye. Many sofware developmen effor esimaes are quie inaccurae unless he sofware developer has done a very similar projec before Key words: use case poins, effor esimaion, agile environmen [4]. Anoher reason why effor esimaion remains a 2. Use Case Poins challenge is ha he people involved in he projec and heir skills are probably no cerain. To overcome his problem, Use Case Poins (UCP) is seen as one of he proven mehods o esimae sofware developmen effor in early sage of sofware projec. I has been used by many sofware praciioners o esimae effor required o develop sofware applicaions [5], [6]. In fac, UCP is also capable o produce an early esimae wihin 20 percen of he acual effor, and ofen, closer o he acual effor han expers and oher esimaion mehodologies [7]. Moreover, UCP is one of he mos suiable mehods for hose who apply Unified Modeling Language (UML) and Raional Unified Process (RUP) in heir sofware developmen projecs [8]. I is where he use case modeling is used o capure he businessprocesses and requiremens of he sofware projec. Based on researchers experience, UCP can be difficul o use in some cases, paricularly in Agile sofware developmen where Produc Backlog which conaining shor descripions of all funcionaliy desired in he sofwareapplicaion, does no saisfy a number of condiions especially in use case documenaion. This problem is due oinconsisency sandard of documening use case specificaion in Agile Produc Backlog where user sories are he main concern o record he user requiremens. Furhermore, none of he sudies describe clearly how o use Agile Produc Backlog wih UCP [5]. Therefore, he aim of his research is o look a he poenial of successful applicaion of he UCP mehod for esimaing he effor of Agile sofware developmen projecs, including he major limiaions and will offers some possible recommendaion on how o make simpler esimaion in early sage of he sofware developmen. This paper is organized as follows: secion 2 provides some basic concep of UCP. Secion 3 describes a case sudy based on a real-world problem, and implemenaion of UCP is in secion 4. Resul and discussion are discussed in secion 5. Secion 6 includes conclusion and suggesion for fuure work. Use Case Poins (UCP) is a sofware sizing and esimaion mehod adoped from he classic Funcion Poin (FP) mehod in solving he specific needs of objec-oriened sysems based on use cases [9], [10]. I was developed by Gusav Karner a Objecory Sysems [11]. The accuracy of he UCP esimaions was compared o exper esimaes made by experienced sofware developers, and he resuls showed ha esimaed effor for each projec was quie close o he acual esimaes [8]. This indicaes ha he UCP can be successfully used o esimae he efforrequired for developing sofware applicaion. Unlike radiional approaches, UCP provides he abiliy o esimae a he early sages of a sofware projec [10]. In general, large projecs wih complicaed use cases will ake more effor o design and implemen han small projecs wih less complicaed use cases. In order o evaluae he applicabiliy of UCP in esimaing sofware developmen effor, five seps mus be followed [9], [11], [12]. 1) Deermine and compue he Unadjused Use Case Poins (UUCPs) 2) Deermine and compue he Technical Complexiy Facors (TCFs) 3) Deermine and compue he Environmenal Complexiy Facors (ECFs) 4) Deermine he Produciviy Facor (PF) 5) Compue he esimaed number of hours 3. A Case Sudy

2 1112 Agile sofware developmen is a group of sofware developmen mehodologies based on ieraive and incremenal developmen [13]. There are many well-known agile developmen mehods have been inroduced over he las decade. These include exreme Programming (XP), Scrum, Dynamic Sysem Developmen Mehodology (DSDM), Feaure-Driven Developmen (FDD), Adapive Sofware developmen (ASD) and Lean Sofware Developmen (LD) [14]. Mos mehods promoe developmen, eamwork, collaboraion, and process adapabiliy hroughou he life cycle of he projec. However, in his paper, Scrum was chosen as a case sudy because i is more widely adoped by sofware developers [15]. Unlike radiional approach, Scrum will no produce comprehensive documens o avoid wased effor. However, one of he imporan documens ha should be prepared by he developmen eam is Produc Backlog. This documen conains user sories, which represen pieces of funcionaliy o be esimaed [16] and rough esimae of developmen effor [17]. Based on researchers experience, i was very hard o obain real Produc Backlog produced by sofware praciioners. Many of hem refused o reveal heir works o he public due o several confidenial issues. Even hough several sudies have been done for esimaing sofware developmen effor using UCP, none of hem describe clearly how o use Agile Produc Backlog wih UCP [5]. Therefore, sofware arifac srucures of KOINS Produc Backlog which have been used o es ObjecMerix framework in Agile projec will be used as a case in his sudy [18]. For informaion, KOINS sand for Kobena Informaion Sysem and i was developed o solve curren manual sysem implemened by KoperasiBelia Naional Berhad. Based on he fac saed in [18], here are 29 use cases and five acors have been idenified in he KOINS projec. The esimaed man-hours o complee he projec was This esimaion will be used as a guideline o esimae effor required using UCP. 4. Implemening UCP in Agile Projec To esimae effor required for developing KOINS sysem, five seps as menioned in secion 2 will be used as a guideline. The firs sep is o deermine and compue he Unadjused Use Case Poins (UUCPs). This can be done by calculaing Unadjused Use Case Weigh (UUCW) and Unadjused Acor Weigh (UAW). UUCW can be obained by defining use cases as simple, average or complex, depending on he number of ransacions in he use case descripion, including secondary scenarios. In his UCP mehod, a ransacion is an even ha occurs beween an acor and he arge sysem. Alernaively, he number of ransacions can also be done by couning he use case seps. If he use case conains more han seven ransacions, i is considered complex. On he oher hand, he use case is considered simple if i conains less han four ransacions. The UUCW is calculaed by couning he number of use cases in each caegory, muliplying each oal by is specified weighing facor, and hen adding he producs. In his case, all use cases are defined as average because here is no use Special Issue Agile Symposium, Malaysia ISSN ; CODEN: SINTE 8 Sci.In.(Lahore),25(4), ,2013 case ransacion described in Produc Backlog. The deails of he UUCW calculaion are shown in Table 1. Table 1. Calculaing Unadjused Use Case Weigh (UUCW) Use Case Number of Weigh Number Produc Complexiy Transacion of Use Cases Simple 3 or fewer Average 4 o Complex more han Toal UAW can be obained by classifying he acors as simple, average, or complex. For example, a simple acor represens anoher sysem ha communicae via a pre-defined API, an average acor can be eiher human beings or anoher sysem ineracing hough well-defined proocol such as TCP/IP, and a complex acor is a person ineracing hrough GUI or a Web page. The UAW is calculaed by couning he number of acors in each caegory, muliplying each oal by is specified weighing facor, and hen adding he producs. In his case, all acors are persons who inerac wih he sysem hrough GUI. Therefore, all he acors are classified as complex. The deails of he UAW calculaion are shown in Table 2. Then, he UUCP is compued by adding he UUCW and he UAW. For he daa used in Tables 1 and 2, he UUCP = = 305. The UUCP is unadjused because i does no accoun for he echnical and environmenal complexiy facors (TCFs and ECFs). Table 2. Calculaing Unadjused AcorWeigh (UAW) Acor Type Weigh Number Produc of Acors Simple Average Complex Toal 5 15 The second sep is o deermine and compue he Technical Complexiy Facors (TCFs). For each projec, he echnical facors are evaluaed by he developmen eam and assigned a perceived complexiy value beween zero and five. The perceived complexiy facor is subjecively deermined by he developmen eam s percepion of he projec s complexiy; for example, concurren applicaions require more skill and ime han simple web-based applicaions. A perceived complexiy of zero means he echnical facor is irrelevan for his projec, hree is average, and five is srong influence. I is advisable o use hree when in doub condiion. Then, each facor s weigh is muliplied by is perceived complexiy facor o produce he calculaed facor. The calculaed facors are summed o produce he oal echnical facor (TFacor). Table 3 calculaes he hireen TCFs for his case sudy. Acually, i is a grea challenge o assign value o he TCFs. Previous sudies also had difficulies in assigning values o he TCFs because lacked of a basis for comparison [8]. To simplify he esimaion, we assigned values of hree o all he echnical facors excep T5, T8 and T12. These hree facors

3 Sci.In.(Lahore),25(4), ,2013 ISSN ; CODEN: SINTE are se o zero because KOINS is a new sofware developmen projec [18]. The main reason why value of hree is given o mos of he echnical facor is based on he T6 a focus. Easy o insall number of use cases in our case sudy. The number of use T7 Easy o use cases applied in his case sudy are 29, which is less han 50. T8 Crossplaform This means ha he sysem o be developed is no very complex and we assume ha he overall applicaion as suppor. average. We also decided o se he complexiy level as T9 Easy o average due o several unclear descripion of KOINS s change. Produc Backlog [18]. T10 Highly Based on Table 3, TCF is calculaed by using he following concurren. formula: T11 Cusom TCF = (0.01 x TFacor) = (0.01 x 33) = = 0.93 The hird sep is o deermine and compue he Environmenal ComplexiyFacors (ECFs). Larger values for he environmenal facor will have a greaer impac on he UCP equaion. A value of one means he facor has a srong negaive impac for he projec; hree is average; and five means i has a srong posiive impac. A value of zero has no impac on he projec s success. For example, eam members wih lile or no moivaion for he projec will have a srong negaive impac (one) on he projec s success while eam members wih srong objec-oriened experience will have a srong, posiive impac (five) on he projec s success. Each facor s weigh is muliplied by is perceived impac o produce is calculaed facor. The calculaed facors are summed o produce he environmenal facor. Table 4 shows he calculaion of ECF for he case sudy. KOINS s Produc Backlog did no menion he developers experience in deails [18]. Therefore, we assumed ha all developers were capable o develop KOINS applicaion and we assigned value of hree o all environmenal complexiy facors excep E7 and E8 because here was no par-ime saff menioned in heir projec plan and he programming language was also no decided ye. Table 3. Assessmen of Projec s Technical Complexiy Facors (TCF) Facors Descripion Weigh Assessmen Impac T1 Disribued sysem required. T2 Response ime is imporan. T3 End-user efficiency. T4 Complex inernal processing required. T5 Reusable code mus be T12 T13 securiy. Dependence on hirdpary code. User raining. Toal TFacor Table 4. Assessmen of Projec s Environmenal Complexiy Facors (ECF) Facor s Descripion Weigh Assessmen Impac E1 Familiariy wih he projec. E2 Applicaion experience. E3 Objecoriened programmin g experience. E4 Lead analys capabiliy. E5 Moivaion E6 Sable requiremens. E7 Par-ime saff. E8 Difficul programmin g language. Toal EFacor 19.5 Based on Table 4, ECF is calculaed by using he following formula: ECF = (-0.03 x EFacor) = (-0.03 x 19.5) = (-0.585) = Then, he adjused UCP is obained by applying he following formula: 33

4 1114 Special Issue Agile Symposium, Malaysia ISSN ; CODEN: SINTE 8 = UUCP x TCF x ECF UCP = 305 x 0.93 x = The forh sep is o deermine he Produciviy Facor (PF). Acually, here is no consisen projec daase presening UCP daa as he ISBSG (Inernaional Sofware Benchmarking Sandards Group) does for some oher mehods [19]. The reason behind his is due o he fac ha use case specificaion varies for each projec. UML does no explain in deails abou how o srucure he use case models or how o documen each use case [10]. Bu based on he previous sudies, some suggesions proposed by he expers are 20 hours/ucp [11], an average of hours/ucp [6], and range beween 15 o 30 hours/ucp [10], [9]. However, he chosen value is depending on he developmen eam s overall experience. For insance, if i is a brand-new eam, use a value of 20 for he firs projec [9], [6]. The final sep is o compue he esimaed number of hours. Below is an example of he calculaion based on 28 hours/ucp. Man-Hours = UCP x 28 = x 28 = 6, = 6,473 hours The resul is greaer han acual projec plan (5540 manhours) wih exra 933 man-hours. In order o verify he mos suiable value of PF, we conduced five experimens based on he proposed values and compared wih he acual effor. The resuls of he oal number of hours required o complee he projec based on five experimens are shown in Table 5. Table 5. Experimen of Esimaed Hours Based on Produciviy Facors Hours/UCP Esimaed Hours Acual Effor Differences Based on he above experimens, 24 hours/ucp is he bes PF for his case sudy where he esimaed value is so close o he acual effor. The resuls show ha UCP is capable o esimae a an early sage of he sofware developmen. However, he accuracy of he esimaion is highly depending on he value of he PF decided by he sofware developers in he company. 5. RESULT AND DISCUSSION The acual effor spen on he sofware developmen used in his sudy was 5540 man-hours as menioned in secion 3. Based on five experimens conduced in his sudy, 24 hours/ucp is he bes value o be used in order o obain he closes resul. The resul is greaer han acual projec plan (5540 man-hours) wih exra 8 man-hours. This is equivalen o one-day job. This means ha UCP produced almos as accurae as he esimaes produced by exper. The resuls, hough no conclusive, indicae ha he UCP has poenial o Sci.In.(Lahore),25(4), ,2013 be a reliable mehod of esimaion and i can have a srong impac on esimaing he size of sofware developmen projecs, especially when i is used along wih exper esimaes. Therefore, 24 man-hours/ucp can be used as hisorical daa o represen produciviy for similar projecs in he fuure. This shows ha he UCP mehod successfully explois he informaion from Produc Backlog. The number of acors and use-cases are enough o esimae he effor required a he early sage of sofware developmen. However, here are some hreas o his accuracy. Firs, he accuracy of he number of use case complexiy is depending on he use case ransacion described in use case documenaion because he use case models can be srucured and documened in several alernaive ways [20]. Unforunaely, here is no sandard use case documenaion applied in Agile sofwaredevelopmen. Mos of he Agile Produc Backlog did no describe he number of use case ransacion. In his case, all use cases are defined as average and he resuls produced migh be big difference if a more complex applicaion used in his case sudy. Second, he developers skills are unknown. Normally, here are differen levels of experience among he developers of he projec. However, in his case sudy, we assume ha all developers are good in compleing heir jobs. Based on he achieved resuls, we srongly believed ha UCP could be paricularly beneficial when he esimaors lack specific experience or he projec required frequen esimae. In addiion, we also srongly agree ha he pas projec daa should be documened in order o produce accurae esimaion of subsequen projecs. 6. CONCLUSION AND FUTURE WORK A case sudy was conduced wih he aim of invesigaing on how o esimae sofware developmen effor in Agile environmen using UCP. The resul shows ha UCP produced esimae ha is quie close o he acual effor spen on developing a projec. These resuls also align wih he sudy conduced in oher sofware developmen companies locaed a Norway, Sweden and Finland [8]. Thus, his indicaes ha UCP can suppor Agile environmen and fulfills objec-oriened developmen wihou major adjusmens. I is also proven ha UCP is suiable for esimaing sofware developmen effor a he early sage of he sofware developmen. We are now coninuing his work by invesigaing how UCP performs on differen ypes of projecs, in paricular regarding size and complexiy of he sofware projec implemened in Agile environmen. We also would like o compare his resul wih oher esimaion mehods, for insance COCOMO. Previous sudy claimed ha none of he companies had used COCOMO on heir Agile projecs [21].

5 Sci.In.(Lahore),25(4), ,2013 ISSN ; CODEN: SINTE REFERENCES [18] Z. Ani, N. Nordin, N. Hashim, and A. Zainol, Effor [1] B. Boehm, C. Abs, and S. Chulani, Sofware developmen cos esimaion approaches: A survey, Annals of Sofware Engineering, vol. 10, pp , esimaion in agile sofware developmen using objecmerix: A case sudy, in 2nd Inernaional Conference on Sofware Engineering and Applicaion, (Singapore), pp , [2] B. Boehm, Sofware engineering economics, Sofware Engineering, IEEE Transacions, vol. 10, pp. 4 21, [19] Ç. Gencel, L. Buglione, O. Demirors, and P. Efe, A case sudy on he evaluaion of cosmic-ffp and use case poins, in 3rd Sofware Measuremen European [3] M. Jorgensen, B. Boehm, and S. Rifkin, Sofware developmen effor esimaion: Formal models or exper judgmen?, IEEE Sofware, vol. 26, pp , Forum, (Rome, Ialy), [20] S. Sendall and A. Srohmeier, From use cases o sysem operaion specificaions, in 3rd Inernaional Conference on The Unified Modeling Language, [4] M. Jørgensen, Forecasing of sofware developmen (York, UK.), pp. 1 15, work effor: Evidence on exper judgemen and formal [21] M. Ceschi, A. Sillii, G. Succi, and S. models, Inernaional Journal of Forecasing, vol. 23, pp , DePanfilis, Projec managemen in plan-based and agile companies, Sofware, IEEE, vol. 22, pp , [5] S. Kusumoo, F. Maukawa, K. Inoue, S. Hanabusa, and Y. Maegawa, Esimaing effor by use case poins: Mehod, ool and case sudy, in 10h Inernaional Symposium on Sofware Merics, (Washingon, USA), pp , [6] G. Schneider and J. Winers, Applying Use Cases - A Pracical Guide. Boson: Addison-Wesley, 2nd ed., [7] E. Carroll, Esimaing sofware based on use case poins, in 20h annual ACM SIGPLAN conference on Objec-oriened programming, sysems, languages, and applicaions, (San Diego, CA, USA), pp , [8] B. Anda, H. Dreiem, D. Sjøberg, and M. Jørgensen, Esimaing sofware developmen effor based on use cases - experiences from indusry, The Unified Modeling Language. Modeling Languages, Conceps, and Tools, vol. 2185, pp , [9] R. Clemmons, Projec esimaion wih use case poins, The Journal of Defense Sofware Engineering, pp , [10] G. Banerjee, Use case esimaion framework, in Annual IPML Conference, pp. 1 12, Cieseer, [11] G. Karner, Resource esimaion for objecory projecs, Objecive Sysems SF AB, vol. 17, [12] M. Damodaran and A. Washingon, Esimaion using use case poins, Compuer Science Program. Texas Vicoria: Universiy of Houson. Sd, [13] R. Marin, Agile sofware developmen: principles, paerns, and pracices. New York: Prenice Hall, [14] T. Chow and D. Cao, A survey sudy of criical success facors in agile sofware projecs, Journal of Sysems and Sofware, vol. 81, pp , [15] J. Srinivasan and K. Lundqvis, Using agile mehods in sofware produc developmen: A case sudy, in 6h Inernaional Conference on Informaion Technology, (Las Vegas, USA), pp , [16] S. Keaveney and K. Conboy, Cos esimaion in agile developmen projecs, in 14h European Conference on Informaion Sysems, (Göe- borg, Sweden), [17] R. Armsrong, Sofware esimaion in an agile environmen, ech.rep., UK:TASSC, 2009.