Early estimation of software size in object-oriented environments a case study in a CMM level 3 software firm

of 17

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
17 pages
0 downs
Early estimation of the size of a software product is extremely important. In this paper we analyze two software packages developed by a CMM level 3 software firm. We study if any property of analysis objects can be used to infer the size of the
    UNIVERSITYOF TRENTO   DEPARTMENT OF INFORMATION AND COMMUNICATION TECHNOLOGY 38050 Povo – Trento (Italy), Via Sommarive 14http://www.dit.unitn.it   EARLY ESTIMATION OF SOFTWARE SIZE IN OBJECT-ORIENTED ENVIRONMENTSA CASE STUDY IN A CMM LEVEL 3 SOFTWARE FIRMMarco Ronchetti, Giancarlo Succi, Witold Pedrycz, and Barbara RussoJanuary 2004Technical Report # DIT-04-007    .   Ronchetti et al. Page 1 of 14 Early estimation of software size in object-oriented environmentsa case study in a CMM level 3 software firm Marco RonchettiDipartimento di Informatica e TelecomunicazioniUniversità di Trento, Trento, ItalyGiancarlo SucciCenter for Applied Software EngineeringFree University of Bolzano-Bozen, ItalyWitold PedryczDepartment of Electrical and Computer EngineeringUniversity of Calgary, Calgary, AlbertaBarbara RussoCenter for Applied Software EngineeringFree University of Bolzano-Bozen, ItalyAbstract Early estimation of the size of a software product is extremely important. In this paper we analyzetwo software packages developed by a CMM level 3 software firm. We study if any property of analysis objects can be used to infer the size of the final code in an object-oriented environment. Inboth cases we find the number of methods well correlated with software size, in the sense that thecorrelation with the final size is high (r > 0.77) and significant at the level .05. Inferential statisticsguarantee that the results of this study are also applicable outside the scope of the two projects. 1   INTRODUCTION An accurate estimation of the time and the effort required to develop a software product is aprerequisite for effective management of the software development process. Several time and effortestimation techniques exist, such as those proposed by Boehm (1996), Putnam (1992), and Albrecht(1983).Most of these techniques either define a link between external features of the product and the size orthe time/effort to develop, or focus on finding a relation between the size of the product and thetime/effort to develop.   Ronchetti et al. Page 2 of 14 Our work tries to take advantage of a specificity of object-oriented development: the same“language” is used throughout the software lifecycle. We use objects to represent requirements,analysis documents, design documents, and code.A huge effort has been placed in the last few years on object-oriented metrics and their use topredict effort, quality, and productivity. Among the most significant works, Li and Henry havetargeted the number of changes in a component (1993), Basili, Briand, and Melo the faults presentin an objects (1996), Chidamber, Darcy, and Kemerer the productivity, the rework effort, and thedesign effort (1998). All these three works use the Chidamber and Kemerer metric suit (1994), oftenreferred to as “CK metrics.”The long-term goal of our study is to determine if any property of analysis objects is highly andsignificantly correlated with the time/effort to develop the product, so that early in the lifecyclemanagers and developers can have reliable estimates of the required effort to complete the product.This paper presents an experiment in which we have collected and analyzed data from 2 realprojects of a CMM level 3, ISO 9000 software firm to determine whether there are metrics of analysis objects that can predict the size of the final product.Our experiment has two main limitations. First, the analysis metrics used are those supplied by theOMT-based object modeling tool in use by the firm; it would have been very interesting to use allthe CK metrics, unfortunately they were not available. Second, we focus on the size of the finalproduct and not on the time or the effort to develop it; this is simply because we only have theinformation of the size.The uniqueness of our work is that we focus on analysis objects. (Li and Henry, 1993) did notclarify whether its measures came from design or from code. (Basili et al.,1996) dealt with code.(Chidamber et al., 1998) took into consideration design objects only for one of the three data-setsthey used; in the other two cases they dealt with code. Moreover, we deal with industrial data froma CMM level 3, ISO 9000 company; (Basili et al., 1996) analyzed students projects, (Li and Henry,1993) and (Chidamber et al., 1998) do not specify the maturity of the firms they dealt with.We find that a very simple measure, the number of methods of an analysis object, is well andsignificantly correlated with the size of the final product in both our data sets.This paper is organized as follows. Section 2 describes the set of metrics we have used. Section 3details the environment where we have collected the measures and the process applied to collect themeasures. Section 4 presents the results that we have obtained. Section 5 draws some conclusions. 2   BACKGROUND As mentioned, several metrics exist for Object-Oriented analysis documents. Several books includeexcellent surveys and discussions, such as (Whitmire, 1997; Henderson-Sellers, 1997; DeChampeaux, 1997).In this paper we will use the following class metrics: external complexity and internal complexity(Moreau and Dominick, 1990), depth of inheritance tree, number of methods, number of children(Chidamber and Kemerer, 1994), and number of attributes (De Champeaux, 1997).We adopted this set of metrics since it was computed automatically by the design tool in use. Thedesigners of the systems supplied the metrics to us at the end of the project without any directintervention during the projects or any change in the standard software development practices. Thedevelopers of the project were not informed in advance of the subsequent data analysis. The   Ronchetti et al. Page 3 of 14 selection of a different set of metrics would have compromised the feasibility and the internalvalidity of our experiment.The formal definitions of the adopted metrics follow. •   External Complexity of a class C -  EC(C) :  = = nii  A AC C  EC  1 )()(  Where n is the number of associations of the class,  A i is each association of the class, and  AC(A)  is:)(*#1.0*1.0 21)()(  A AttributesQ A Arity A AC  ++−=  Where Q is 1 if the association is qualified, 0 otherwise. •   Internal Complexity of a class C -  IC(C) : nn M  MC C  IC  nii *2.0 )()( 1 +=  =  Where n is the number of methods of the class,  M  i is each method, and  MC(M) is: )(*#1.01)(  M  parameters M  MC  +=   •   Depth of the Inheritance Tree of a class C –  DIT(C) : maximum length of the path from theclass to the root of the inheritance tree •   Number of Methods of a class C –  NoM(C) , Number of Children of a class C –  NoC(C) , and Number of Attributes of a class C –  NoA(C) are self-definedFor the sake of precision, NoM is used by both (Basili et al., 1996) and (Chidamber et al., 1998)under the name “Weighted Method Count”, WMC, assuming constant unitary weight for eachmethod. We prefer the simpler and more intuitive name.The scales of EC and IC are ratio. The scales of DIT, NoM, NoC, and NoA are absolute. Therefore,we can use them all as independent variables in parametric linear regressions. 3   DESCRIPTION OF THE WORKING ENVIRONMENT The data come from a European software company, certified CMM level 3 and ISO 9000. Thecompany operates in the domain of telecommunications; it employs around 300 people; it has adefined software development process based on object orientation and reuse. The softwaredevelopment process is iterative and includes in each iteration separate activities for object-orientedanalysis, Object-Oriented design, and Object-Oriented programming. The analysis and designlanguage is OMT (Rumbaugh et al., 1990). The programming language is C++.Most of the software engineers have a MSc degree either in Electrical Engineering or in ComputerScience. They have 2 to 7 years of programming experience. When they are hired, they are exposedto a significant amount of training –about 3 months full time, so that once they start working, theyhave a good understanding of the processes, languages, and tools in use.
Related Search
Similar documents
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks