An Effort Estimation by UML Points in the Early Stage of Software Development

Transcription

1 A Effort Estimatio by UML Poits i the Early Stage of Software Developmet SagEu Kim Departmet of Computer Sciece Texas A&M Uiversity College Statio, TX USA William Lively Departmet of Computer Sciece Texas A&M Uiversity College Statio, TX USA Dick Simmos Departmet of Computer Sciece Texas A&M Uiversity College Statio, TX USA Abstract - UML-based object-orieted metrics are fully capable of software measuremet. May researchers have produced effort estimatio models for software systems. The estimatio effort i the early stages of software developmet is oe of the most importat problems faced by software developers ad maagers. UML related iformatio ca be used as a accurate source for effort estimatio. I this paper, we propose a automatic software metrics aalysis tool ad a methodology for early stage effort estimatio for software systems. Usig this method, the developer/maager ca aalyze a software system with fuctio poit-like aalysis. UML Poits is a ew cocept, combiig Use Case Poits ad Class Poits with our ow defiitios to provide software system size iformatio. Based o UML Poits, we geerate a effort estimatio model after correlatio aalysis for determiig the relatioship betwee effort ad UML Poits. Keywords: Object-orieted metrics, correlatio aalysis, UML, software measuremet, effort estimatio. Itroductio Three approaches are used i developig highly trustworthy software systems. The first is developig ew methodologies to improve software quality. A example of this is istace object-orieted, compoet-based software developmet. New methodologies are widely used for developig software systems i both the academic ad idustrial areas. The secod approach is process improvemet. This approach has improved software quality ad reliability. The third approach is software measuremet. We eed accurate metrics for measurig software systems ad predictig the effort required for developmet. The approaches used i the first two categories affect how the software is measured. For example, object-orieted methodology geerates ew metrics relatig to objectorieted techology. Process improvemet ca be ehaced through metrics of each process. I the research of software measuremet i terms of effort estimatio, several criticisms exist: lack of a theoretical basis, lack of desirable measuremet properties, beig isufficietly geeralized, beig too implemetatio techology depedet, beig a subjective measuremet based o expert decisio ad beig too labor-itesive for collectig iformatio [][2]. It is widely recogized that Uified Modelig Laguage (UML) is a de facto stadard to describe software systems usig object-orieted cocepts through visualizatio. UML provides a well-structured architecture ad overview of a system through various diagrams represetig differet viewpoits of the target system. Though UML is ot yet a architecture descriptio laguage, by usig various UML diagrams, useful iformatio ca be extracted for measurig the complexity ad size of software systems. Capturig useful iformatio from UML diagrams provides the beefit of a laguage-idepedet measuremet i the upstream level of software developmet. This paper presets a automatic software measuremet tool based o UML diagrams, ad a effort estimatio model based o that measuremet to improve productivity. UML Poits cosist of Use Case Poits ad Class Poits from the use case diagrams ad class diagrams of UML, respectively. The mai cotributios of this paper are the developmet of a automated tool to calculate UML Poits from UML diagrams, itroducig a effort estimatio model based o UML Poits through correlatio aalysis. This approach is proofed by theoretical ad empirical validatio. We itroduce the basic cocepts of size measuremet i terms of effort estimatio. Size measuremet is oe of the most operative factors of the software developmet effort. The, we preset a proposed size measuremet, UML Poits, ad provide validatio of its usefuless ad applicability. After that, we show a effort estimatio model based o UML Poits through statistical aalysis, providig experimetal results. We coclude our paper by summarizig ad aalyzig our results. 2 Upstream vs. Dowstream Estimatio ad predictio of software system developmet cost has bee widely researched for several

2 decades. I this sectio, we review some basic cocepts of software size measuremet ad effort predictio, which are the most effective factors i developig software systems o time ad o budget. These foudatios will affect the method of software measuremet ad effort estimatio. 2. Early--as soo as possible Software metrics were used as the basic foudatio of predictio of effort. The traditioal approaches focused o source code or expert decisio-based aalysis to provide accurate iformatio for calculatio. These approaches ad their pros ad cos are show i Table [3]. [Table ] Pros ad Cos of Software Estimatio Estimatio Approaches Pros Cos Aalogy-based Work Break Structure Fuctio Poit Aalysis COCOMO/II ObjectMetrix - Accurate estimatio - Very simple to apply to similar projects - Rapid estimatio with detailed documetatio - Applicable to origial projects - Iheret local calibratio - Well documeted process - Reliable size estimatio - Ca be applicable i the early stage of project life cycle - Laguage ad platform idepedet - Large user base--active effort - Live effort estimatio - Trasparet algorithm - Local calibratio - Free implemetatio - Live commercial effort estimatio - Supportig moder developmet methodology such as OO desig; iteractive developmet - Ca be applicable i early stage of project life cycle - Icreasig ureliability - Difficulties with real eviromet ad give data - Highly depedet o expert s abilities ad decisios - Maual/high labor cost - Not applicable to latest software developmet methodology - Not ideal i the requiremets capture period - Highly depedet o size iput - Small data set to determie the parameter heuristics - Lack of public iformatio - Not as widely used as other methods - Oly commercial implemetatio Commo problems with these approaches are lack of early estimatio, over-depedece o expert decisio, ad subjective measuremet of each metric. A ew approach is required to overcome these existig difficulties. We move upstream i the software developmet process to requiremet aalysis ad desig. Curretly, UML diagrams are widely used i the software developmet idustry for requiremet aalysis ad detail desig before jumpig ito the codig processes. We surveyed 47 differet object-orieted metrics to idetify appropriate software measuremet from UML diagrams ad developed a well-structured tree for the UML-based object-orieted software measuremet to assist effort estimatio. The results of this classificatio follow: Primitive measuremets that represet a skeleto/structure of UML diagrams. These metrics help overcome a lack of desirable measuremet properties ad iformatio. Fault-proeess measuremets that predict a class s fault-proeess. Couplig measuremets, which provide locality iformatio amog objects, classes ad packages. We propose a ew metric, package-level couplig. This couplig represets locality depedecy betwee package compoets. Object-orieted software measuremets, which are related to iheritace, iformatio hidig, ad complexity of scearios. Through this classificatio, we foud it ecessary to develop a simple approach for providig useful iformatio for software effort estimatio while maitaiig accuracy. This ew approach will be to provide a early estimatio of effort as soo as possible durig the project. Based o this estimatio, the project maager ca fiish o schedule. 2.2 Classificatio of software size ad cost estimatio models To estimate software developmet cost, several approaches exist. Table 2 shows oe of the classificatio methods i literature. [Table 2] Classificatio of cost estimatio models [3] Effort & Schedulig Parametric Computatio models Complexity & Size Metrics Source Lies of Code (KSLOCs) More complex elemets (Dimesios) SLIM COCOMO Fuctio Poits Object-Orieted Approaches No-parametric models(machie Learig Approaches) Regressio Trees Regressio Trees Neural Networks Aalogies From this classificatio, we combie the parametric ad o-parametric models to effectively estimate costs at the early stage of software developmet. To do this we eed our ow defiitio of class poits, use case poits, ad UML poits. I the ext sectio, we defie each i detail. 3 UML Poits To glea useful iformatio early i the software developmet process, we focus o the followig UML diagrams: requiremet egotiatio iformatio betwee the customer ad developer i a use case diagram, ad detail

3 desig iformatio i class diagrams. The UML poits approach will provide simple calculatio, will be easy to implemet, ad will provide reasoable cost estimatio i the upper stage of software developmet. I this sectio, we provide a overview of the use case poits ad class poits approaches to provide iput for the effort estimatio model. 3. Use Case Poits Use case diagrams cotai the fuctioal behavior of the target system, determied durig the requiremet aalysis phase. The Use Case Poits (UCP) approach was itroduced by Karer[4] as a software project effort estimatio model. UCP effort estimatio is a extesio of existig estimatio methods, such as fuctio poit aalysis ad MK II fuctio poits aalysis. Figure depicts a effort estimatio mai flow based o the UCP calculatio steps. Fig.. The UCP effort estimatio steps. A detailed descriptio of each step is show i [5]. The first step is coutig the umber of actors ad assigig weightig values based o the categorizatio for uadjusted actor weights (UAW). The secod step is eumeratig the umber of use cases ad calculatig its weightig value by the umber of trasactios for uadjusted use case weights (UUCW). Step 3 is calculatig uadjusted use case poits (UUCP) by addig the previous two results. Step 4 is determiig the techical factors for system ad evirometal factors for the team by give equatios. I step 5, the adjusted use case poits (UCP) is calculated by multiplyig UUCP, techical complexity factor (TCF), ad evirometal factor (EF). The fial step, step 6, is geeratig estimated effort by multiplyig UCP ad perso-hours per UCP (PHperUCP). Table 3 shows how each factor was determied ad what value was assiged at each step [5]. [Table 3] Factors ad descriptios Factor Descriptio Weight Actors Use Cases Tech. Ev. Simple Program iterface Average Iteractive, or protocol-drive, iterface 2 Complex Graphical iterface 3 Simple 3 or fewer trasactios 5 Average 4 to 7 trasactios 0 Complex More tha 7 trasactios 5 T Distributed system 2 T2 Respose or throughput performace objectives T3 Ed-user efficiecy (olie) T4 Complex iteral processig T5 Code must be reusable T6 Easy to istall 0.5 T7 Easy to use 0.5 T8 Portable 2 T9 Easy to chage T0 Cocurret T Icludes special security features T2 Provides direct access for third parties T3 Special user traiig facilities are required F Familiar with the Ratioal.5 Uified Process F2 Applicatio experiece 0.5 F3 Object-Orieted Experiece F4 Lead aalyst capability 0.5 F5 Motivatio F6 Stable requiremets 2 F7 Part-time workers - F8 Difficult programmig laguage - This approach, however, has weak poits whe applied to geeral software projects. UCP lacks iformatio, oly coutig the umber of actors ad use cases. It also relies heavily o the estimatig expert regardig the weightig of UAW/UUCW ad the techical ad evirometal factors. The determied value of each of these factors will be highly depedet o the expert s opiio, ad will therefore icrease variace i the fial results. To overcome these problems, we propose a ew approach that will be easier to calculate, exclude the expert s decisio, ad focus more o the diagram itself. The use case diagram has much iformatio about the early developmet stage s cocept ad the target system s dyamic viewpoit. The developer uses this diagram for commuicatig with the customer to decrease the coceptual gap betwee them, havig sufficiet kowledge of the target system. We ewly defie several cocepts of use case poits as follows: Number of actors (NOA) The umber of actors used to develop the target system. NOA = oa, ()

4 Number of use cases (NOUC) The umber of use cases of the UML model. This is oe of mai artifacts affectig effort predictio. NOUC = ouc, (2) Number of roles (NOR) This shows the logical fuctioality betwee actor ad use case. The detail behavior of these roles will be implemeted at the ext software developmet stage. NOR = or, (3) Average Number of Actors per Use Case (ANA_UC) This cocept reveals a ratio value of complexity of each use case i terms of the umber of actors. ANA _ UC = NOA, (4) NOUC Average Number of Roles per Use Case (ANR_UC) This ratio value represets the complexity of use cases i terms of the umber of roles. ANR _ UC = NOR, (5) NOUC Usecase Poits (UCP) This defiitio represets the usecase poits of the target system. UCP = ( NOA + NOUC + NOR), (6) The ratio values ANA_UC ad ANR_UC are easily calculated by usig (), (2), ad (3) equatios to provide a more geeral overview of use case poits. I geeral, the use case diagram was used i commuicatio betwee developer ad customer to reduce coceptual gaps betwee them, so it has sufficiet kowledge about the target system. We, therefore, ca use the value of the use case poits as a iput for our effort estimatio model. For istace, if the value of NOA is high the it meas that the system has a great deal of iterface with its eviromet. UCP is calculated by addig up all of the use case poits as i equatio (6). 3.2 Class Poits I object-orieted developmet, the class diagram has a great deal of quatificatio iformatio based o the desig documet. It cotais the structural fuctioality of the target system ad its class hierarchy, which are the logical blocks of the developed system. The class poits approach was itroduced i 998[6]. This was based o the fuctio poits aalysis approach to represet the iteral attributes of a software system i terms of coutig. There are three major steps to measure a target system, as show i Figure 2. Each step cosists of major activities required to gather quatificatio iformatio of classes. Fig. 2. Three steps of the Class Poits. The first step is to idetify ad classify the classes ito four system types: problem domai type, huma iteractio type, data maagemet type, ad task maagemet type, each i terms of the characteristics of the target system. This classificatio will be helpful i distiguishig betwee complex systems ad will provide easier compariso amog them. After idetificatio ad classificatio of classes, the class poits will describe the complexity level of each class, as determied by the umber of exteral methods, the umber of services requested, ad the umber of attributes. Fially the class poits will be calculated by applyig a techical complexity factor of the target system. The techical complexity factor was determied by the degree of ifluece of 8 differet target software system characteristics, each o a scale of 0 to 5. The detailed procedure ad equatios of this measuremet are described i [6]. This approach, however, has weak poits whe applied to geeral software projects. CP has a lack of iformatio problem, coutig oly of the umber of exteral methods, the umber of services requested, ad the umber of attributes. There is additioal useful iformatio affectig effort estimatio of target systems such as umber of iheritace/uses/realize relatioships, umber of parameters ad umber of classes. Additioally, CP uses expert decisio o, for istace, compoet type, complexity level, TDI (Total Degree of Ifluece), ad TCF (Techical Complexity Factor). The determied value of each factor will be highly depedet o the expert s decisio, creatig variace of fial results. To solve these problems, we propose a ew cocept of class poits. This approach has similar beefits to use case poits described i the previous sectio. We focus o the diagram itself, excludig subjective factors such as expert decisio. This ew defiitio of class poits will icrease uderstadig of a system s architectural complexity. We defie it as follows: Number of Classes () The umber of classes used to desig the target system is highly relevat to effort estimatio ad describes the architectural complexity of the system. = oc, (7)

5 Number of Iheritace Relatioships (NOIR) This defiitio shows oe of the relatioship attributes betwee classes, specifyig how may iheritace relatioships were used to desig the target system. NOIR = oir, (8) Number of Use Relatioships (NOUR) This defiitio shows oe of the relatioship attributes betwee classes, specifyig how may use relatioships were used to desig the target system. NOUR = our, (9) Number of Realize Relatioships (NORR) Oe of the relatioship attributes betwee classes is how may realize relatioships were used to desig the target system. NORR = orr, (0) Number of Methods (NOM) How may methods were used to desig the target system. It will be highly relevat with effort estimatio ad also describes the architectural complexity of system. NOM = om, () Number of Parameters (NOP) This defiitio shows how may parameters were used i give methods of classes. It will be highly relevat with effort estimatio ad describes the architectural complexity of the system. NOP = op, (2) Number of Class Attributes (A) How may class attributes were used to desig the target system. A = oca, (3) Number of Associatios (NOASSOC) How may associatios were used to desig the target system. NOASS = oass, (4) Average Number of Methods per Class (ANM_CLS) The ratio value of the umber of methods per class i the target system. ANM _ CLS = NOM, (5) Average Number of Parameters per Class (ANP_CLS) The average umber of parameters per class i the target system. ANP _ CLS = NOP, (6) Average Number of Class Attributes per Class (ANCA_CLS) The average umber of class attributes per class i the desig documet. ANCA _ CLS = A, (7) Average Number of Associatios per Class (ANASSOC_CLS) The average umber of associatios per class i the target system. ANASS _ CLS = NOASS, (8) Average Number of Relatioships per Class (ANREL_CLS) The average umber of relatioships per class i the target system. ( NOIR + NOUR + NORR) ANREL _ CLS =, (9) Class Poits (CP) The class poits of the target system. ( + NOIR + NOUR + NORR + CP =, (20) NOM + A + NOASS) Equatio (7) to (2) is used to gather fudametal iformatio from class diagrams for recogizig its structural complexity. Equatios (3) to (9) are easily calculated with previous equatios to provide relative iformatio about structure complexity of class diagrams. The CP, fially, will be calculated by addig up all of the class poits values as i equatio (20). These UML-based use case poits ad class poits provide the project maager ad developer a better uderstadig of the architectural complexity of the target system. The size measuremet UML poits ca be used to estimate project effort. UML poits are calculated by addig use case poits ad class poits. 3.3 UML Poits Geerator We developed a automatic tool, the UML Poits Geerator, to geerate the UML poits. The UML Poits Geerator s coceptual flow is as follows: ) UML diagrams will be the iput of the UML Poits Geerator; ad 2) the UML Poits Geerator takes these UML diagrams ad geerates the UCP ad CP as outputs based o give user iputs. The UML Poits Geerator was developed i the Java laguage with JBuilder 4.0, so it ca ru o ay machie ruig the JVM. It has fewer tha,200 total source lies makig it a very light-weight software. The curretly developed architecture of the UML Poits Geerator is depicted i Figure 3. It cosists of three major modules: the User Iput Hadlig & Parsig Module, the Metrics Calculate Module, ad the Report Geerator Module.

6 Fig. 3. Architecture of the UML Poits Geerator. The User Iput Hadlig & Parsig Module iterprets ad parses commad-lie iput from users. There are two optios for selectig metrics (use case poits, class poits, or both) ad output formats (stadard scree or XML output). This module has two sub-modules, lexer ad parser. The lexer hadles iput files to geerate tokes, which are the processig uits of the UML Poits Geerator. These tokes are the iput of the parser. The parser creates several vectors based o each toke s kid. These vectors will be traversed to calculate each metric. The Metrics Calculate Module evaluates UML diagrams ad calculates metrics usig the use case poits ad class poits. This module has mathematical calculatio routies for each metric with their ow algorithms. The Report Geerator Module presets the metrics i stadard output or XML format. XML-formatted metrics data ca be used with other (e.g., statistical) tools, providig iteroperability betwee commercial tools. 4 Case Study There are several ways to utilize the proposed UML poits ad software effort estimatio model with UML poits: formalized validatio with theoretical validatio, experimetal validatio through ruig the pilot project, statistical aalysis of the give metrics data, ad applicatio to real projects. I the research process, these validatio processes were required to prove the software measuremet s usefuless. We chose two validatio procedure approaches, a theoretical approach to show utilizatio, ad a empirical approach to provide experimetal case studies. 4. Theoretical Approach Several approaches have proposed theoretical priciples ad frameworks for software measures to provide a formal basis ad foudatio for their validatio procedures. We followed the Briad et al. method proposed i [7]. They suggest a pragmatic approach to providig a mathematical framework to gather more practical results from huge, complex software products. They defied coveiet ad ituitive formalisms ad properties to apply to measuremet cocepts such as size, legth, complexity, cohesio, ad couplig. We follow their defiitio as a formal validatio procedure to apply to our ow proposed size measures. This approach was used to provide the theoretical foudatio for formal software measuremet validatio. They defied the represetatio of systems ad modules i relatioal systems. A system S cosists of a pair <E, R>, where E represets the set of elemets of S ad R is a biary relatio o E(R E X E) represetig the relatioships betwee S s elemets. Give a system S = <E, R>, a system m = <E m, R m > is a module of S if ad oly if E m E, R m E m X E m, ad R m R. The elemets of a module are coected to the elemets of the rest of the system by icomig ad outgoig relatioships. They also defied three basic size measuremet properties: oegativity, ull value, ad module additivity. The first says that the size of a system S is oegative. The secod says that the size of a system S is ull if E is empty. The third property says that the size of a system S is equal to the sum of the sizes of their modules [7]. Based o their defiitios ad properties, we ca provide our ow formal validatio to prove those properties i our model. The oegativity, ull value, ad module additivity properties hold for the UML poits size measure. The value of the UML poits is calculated by summatio of the oegative umbers of the UCP ad CP, so the oegativity property holds. If there are o class ad use case diagrams i the system desig, the UML poits value is ull, so the ull value property is also satisfied. If a system cosists of several modules, the values of UCP ad CP are uchaged by system developmet o matter how the use case ad class diagrams were used i the system. 4.2 Experimetal Approach To do experimetal validatio of the proposed model, we chose the liear regressio test, which is used for developig a effort estimatio model based o the 30 UML files ad the proposed size metrics. We used the SPSS tool to do this work automatically. A T-test was performed to uderstad the correlatio betwee the metrics. I the meatime, a umber of researchers were studyig object-orieted ad traditioal metrics, but they did ot aalyze the relatioship betwee the metrics themselves. This statistical aalysis helps to uderstad the cooperative relatioship of complex metrics. Basically, we assumed o tight relatioship betwee metrics, ad eeded to test the reasoableess of this hypothesis. Therefore we performed a Pearso correlatio aalysis of the SPSS tool. Table 4 shows the result of the correlatio aalysis betwee the metrics ad the total effort. The value of the Pearso correlatio ca represet three differet relatioships: a positive (close to ), o (close to 0), or a egative (close to -) relatioship betwee metrics. Through this relatioship aalysis, we ca geerate a useful assessmet of the target system. I Table 4, we foud that NORR ad NOUC have the highest positive relatioship amog the metrics. Based o this statistical

7 aalysis, there exist several tight relatioships betwee metrics ad effort model, whether egative or positive. [Table 4] Pearso Correlatio UML Poits Metrics Pearso Correlatio CP/UCP NORR vs NOUC CP/UCP NORR vs NOA CP/CP vs NOP CP/CP NOM vs NOP CP/CP NOASS vs A 0.63 CP/UCP A vs NOR Coclusios For our cotributio, UML poits was proposed to measure the size of object-orieted applicatios developed usig UML diagrams. A automatic size measuremet tool, the UML poits geerator, was developed to provide fuctio poits like measuremet from UML diagrams, especially from use case diagram ad class diagram. I this paper, we propose size measuremet for the UML desig specificatio at the early desig phase. To show the utilizatio of the size metrics, a effort estimatio model was developed with the metrics parameters based o aalysis of 30 UML files from a real project. This effort estimatio model ca be used to predict the effort of future projects. We did statistical aalysis betwee metrics to icrease uderstadig of the relatioship amog them through Pearso correlatio aalysis of the SPSS. Iteratioal Coferece o Software Egieerig (ICSE 05), pp , May [5] Shiji Kusumoto, Fumikazu Matukawa, Katsuro Ioue, Shigeo Haabusa, ad Yuusuke Maegawa, Estimatig Effort by Use Case Poits: Method, Tool ad Case Study, Proceedigs of the 0th Iteratioal Symposium o Software Metrics (METRICS 04), pp , September 4-6, [6] Gearo Costagliola ad Geoveffa Tortora, Class Poit: A Approach for the Size Estimatio of Object- Orieted Systems, IEEE Trasactios o Software Egieerig, Vol. 3, No., pp , Ja [7] Lioel Briad, Sadro Morasca, ad Victor R. Basili, Property-Based Software Egieerig Measuremet, IEEE Trasactios o Software Egieerig, Vol. 22, No., pp , Jauary 996. This work ca be expaded to develop additioal metrics extracted from other UML diagrams such as iteractio diagrams ad compoet diagrams. The curret work focuses o class ad use case diagrams. Further aalyses are ecessary to uderstad more useful relatioships betwee metrics ad complexity. 6 Refereces [] Shyam R. Chidamber ad Chris F. Kemerer, A Metrics Suite for Object Orieted Desig, IEEE Trasactios o Software Egieerig, 20(6), pp , Jue 994. [2] Nasib S. Gill ad P.S. Grover, Software Size Predictio Before Codig, ACM SIGSOFT Software Egieerig Notes, Vol. 29, No. 5, pp. -4, September [3] K. Kavoussaakis ad Terry Sloa, UKHEC Report o Software Estimatio, December 200. [4] Parastoo Mohagheghi, Bete Ada, ad Reidar Coradi, Effort Estimatio of Use Cases for Icremetal large-scale Software Developmet, Proceedigs of the