Estimating Software SizePart IIPart II Proxy-base EstimatingAt this early stage, the requirements may be understood but little is generally known about the product itself.. he estimating problem is thus to predict the likely !nished size of the required product.In general, all estimating methods use data on pre"iously de"eloped similar programs to establish some basis for #udging the size of the new program. he need is for some pro$y that relates product size to the functions the estimator can "isualize and describe.Pro$y can help you #udge product size.his section shows how pro$ies can be used to estimate a product%s &'(.E$ample of pro$ies are ob#ect, screens, !les, scripts, or function points.Proxies Selecting a Proxyhe criteria for a good pro$y are as follows) *elated to +e"elopment e,ort) A pro$y, to be useful, must ha"e a demonstrably close relationship to the resources required to de"elop the product. -y estimating the size of the pro$y, you can then accurately #udge the size of the #ob. .ou determine the e,ecti"eness of a pro$y by obtaining historical data on a number of products you ha"e de"eloped and comparing the pro$y "alues with the de"elopment costs. /sing the correlation method described in Appendi$ A. Automatically (ountable Pro$y (ontent) because historical pro$y data are needed for making new estimates. his requires that the data be automatically countable, which in turn suggests the pro$y must be a physical entity that can be precisely de!ned and algorithmically identi!ed.if you cannot automatically count the pro$y content of a program, there is no con"enient way to reliably obtain the statistical data you need to generate estimating factors customized for your particular de"elopment process and design style. Easily 0isualized at the Pro#ect%s -eginning) If the pro$y is harder to "isualize then the number of programmer hours required to do the de"elopment, you may as well estimate hours directly and not worry about pro$y.here will likely not be one best pro$y for all purposes. 1ith suitable historical data, you could e"en end up using se"eral di,erent pro$ies in one estimate. he multiple regression method described in Appendi$ A, section A2. Sensiti"e to Implementation 0ariations) It is essential that the languages, design styles, and application categories to be used on a pro#ect be represented in the data used to calculate the estimating factors to be used. Possible Proxies 3any potential types of pro$ies could meet the pre"iously outlined criteria. he function4point method is an ob"ious candidate because it is widely used. 3any people ha"e found function points to be helpful for resource estimating.'ther possible pro$ies are ob#ects, screens, !les, scripts, and document chapters. he data I gathered during the PSP research work on ob#ects and document chapters show that, at least for my work, these elements generally meet the pro$y criteria..ou can e"en combine multiple pro$ies with the multiple pro$y technique described in chapter 5. Objects as Proxieshe principles of ob#ect4oriented design suggest that ob#ects would be good estimating pro$ies. +uring initial program analysis and design, application entities are used as the basis for selecting system ob#ects. An application entity is something that e$ists in the aplication en"ironment. 6or e$ample, in an automobile registration system, entities might include automobiles, owners, registrations, title, or insurance policies. In an ob#ect4based design, you select program ob#ects that will model these real4world entities.'b#ect thus potentiallymeet one of the basic requirements for a pro$y. Objects as Proxies(Cont.)o determine whether ob#ects are a good size pro$y, you ne$t e$amine historical data.In both cases, the correlation and signi!cance are "ery high. -ecause total program &'( correlates to de"elopment hours and ob#ects correlate highly with total program &'(, ob#ects thus meet the requirement that they closely relate to de"elopment e,ort.'b#ects are physical entities that can be automatically counted.'b#ects will meet all the criteria for a pro$y.o use ob#ects as pro$ies, di"ide your historical ob#ect data into categories and size ranges. Objects as Proxies(Cont.)In estimating how many &'( ob#ects contain, you should similarly !rst group these ob#ects into functional categories. .ou then make estimates by #udging how many ob#ects of each category you need for the new product and the relati"e size of each ob#ect in its category. /sing Putnam%s fuzzy4logic method, you di"ide these ob#ect categories into ranges of "ery small, medium, large, and "ery large ob#ects.'b#ect size is also a matter of style. Some people prefer to group many functions in a few ob#ects7 others prefer to create many ob#ects of relati"ely few functions.-ecause of the wide "ariations in the numbers of methods or procedures per ob#ect, I ha"e also found it #udge ob#ect size on a per4method basis. The PROBE Size Estimating Methodshe PROxy-BasedEstimating8P*'-E9 method uses ob#ects as pro$ies. A :ow chart of the P*'-E size estimation procedure is shown in !gure. hese steps are also e$plained in the P*'-E script in Appendi$ ( 8able (;59 and in the size estimating template instructions 8able (ciently detailed conceptual design, then you will ha"e to re!ne each to a lower le"el. .ou continue this re!nement process until you reach a le"el of detail at which you can describe the product%s functions in terms of ob#ects that are similar to your historical ob#ect data. Determine Object Type and Sie.ou now ha"e the conceptual design, ha"e named each ob#ect, and ha"e determined its category. .ou ne$t !nd the ob#ects in the database that each of these ob#ects most closely resembles. 6or each new ob#ect, you #udge how its size compare with those in the database in its category. !ase ProgramAt the same time you are estimating the new ob#ects, you also determine the size of the base program you are enhancing and any changes to it. able shows that student ?@ identi!ed 52A &'( of base code,A of which the planned to modify. "eused ObjectIf you can !nd a"ailable ob#ects or procedures that could pro"ide the functions required by your conceptual design, you may be able to reuse them.for any ob#ects you plan to take from the reuse library, note their names and sizes in the reused line.Bew *eused 'b#ects) the P*'-E method considers two kinds of reused ob#ects. he !rst are the reused ob#ects taken from the reuse library. he second, the new reused ob#ects, are now ob#ects you plan to de"elop. .ou identify them as new reused ob#ects because you feel they are general to be put in the reuse library. Calculate #stimated Object LOCStarting at the top of the e$ample size estimating template in table, enter the "arious totals. he -ase8-9 is 52A &'(, +eleted8+9 is =, and 3odi!ed839 is A. he -ase Additions8-A9 are =. here are three Bew 'b#ects8B'9 that total ;5? &'( and