Software Sizing

Introduction to Software Project Forecasting: What does the customer want to know ? How big is it? How long will it take? How many people do we need? How much will it cost? How good is it?

What to Forecast? Software size : LOC Function Points Personnel resources : PW PM PY

What to Forecast? Project schedule: Days Weeks Months Years Project costs : $$$$$$$$$$$

Top Down Estimating: based on experiential data from top and middle managers. estimates obtained from the management. aggregate works well with individual errors.

Bottom-up estimating: Personnel performing tasks estimate the work . more accurate in detail . rare in organizational budgeting.

Software Sizing! Accuracy of a software project estimate is Predicated on a number of things : The degree to which the planner has properly estimated the size of the product to be built. The ability to translate the size estimate into human effort, calendar time, and dollar. The degree to which the project plan reflects the abilities of the software team. The stability of product requirements and the enironmenment that supports the engineering effort.

Software sizing methods: “ Fuzzy Logic” sizing Standard component sizing Wideband Delphi Function points, Feature Points PROBE

Fuzzy Logic Size Estimating – 1: Gather size data on previously developed programs Subdivide these data into size categories: very large, large, medium, small, very small establish size ranges include all existing and expected products Subdivide each range into subcategories Allocate the available data to the categories. Establish subcategory size ranges. When estimating a new program, judge which category and subcategory it most closely resembles.

A Fuzzy Logic Example – 1: You have historical data on 5 programs as follows: a file utility of 1,844 LOC a file management program of 5,834 LOC a personnel record keeping program of 6,84 LOC a report generating package of 18,386 LOC an inventory management program of 25,94 LOC

A Fuzzy Logic Example - 2: You thus establish 5 size ranges, as follows: log(1844) = 3.266 log(25,943) = 4.414 the difference is 1.148 1/4th this difference is 0.287 the logs of the five ranges are thus spaced 0.287 apart the limits or these ranges are at 0.1435 above and below the midpoint of each range. midpoint of each range.

A Fuzzy Logic Example - 3: The 5 size ranges are thus: very small - 1,325 to 2,566: file utility. small - 2,566 to 4,970: no members. medium - 4,970 to 9,626: file management and personnel record program. large - 9,626 to 18,641: report generator. very large - 18,641 to 36,104: inventory management.

A Fuzzy Logic Example - 4: Your new program has the following requirements: analyze marketing performance by product line. project the likely sales in each product category. allocate these sales to marketing regions and time periods. produce a monthly report of these projections and the actual result.

A Fuzzy Logic Example - 5: In comparing the new program to the historical data you make the judgments. it is a substantially more complex application than either the file management or personal programs it not as complex as the inventory management program it appears to have significantly more function than the. You conclude that the new program is in the lower end of “very large,” or from 18 to 25 KLOC.

Fuzzy Logic – Summary: To make a fuzzy logic estimate: Divide the historical product size data into size ranges. Compare the planned product with these prior products. Based on this comparison, select the size that seems most. appropriate for the new product .

Fuzzy Logic Size Estimating – Advantages: Fuzzy logic estimating : is based on relevant historical data. is easy to use. requires no special tools or training. provides reasonably good estimates where new work is like. prior experience.

Fuzzy Logic Size Estimating – Disadvantages: The disadvantages of fuzzy logic are: it requires a lot of data. the estimators must be familiar with historically developed programs. it only provides a crude sizing. it is not useful for new program types. it is not useful for programs much larger or smaller than the historical data.

Standard Component Sizing – 1: Establish the principal product size levels components, modules, screens, etc. determine typical sizes of each level For a new product: determine the component level at which estimation is practical. estimate how many of those components will likely be in the product. determine the maximum and minimum numbers possible.

Standard Component Sizing – 2: Calculate the size as the. number of components of each type. times typical sizes of each type. total to give size. Calculate for the maximum, minimum, and likely numbers of components. Calculate size as: {maximum+4*(likely)+minimum}/6

Standard Component Sizing Example – 1: Your new program has the following requirements. analyze marketing performance by product line. project the likely sales in each product category. allocate these sales to marketing regions and time periods. produce a monthly report of these projections and the actual results.

Standard Component Sizing - Example – 2: You have the following historical data on a number of standard components. data input component: 1,108 LOC output component: 675 LOC file component: 1,585 LOC control component: 2,550 LOC computation component: 475 LOC

Standard Component Sizing - Example –3: First, estimate the minimum, likely, and maximum number of components like these in the new product. data input component: 1, 4, 7 output component: 1, 3, 5 file component: 2, 4, 8 control component: 1, 2, 3 computation component: 1, 3, 7

Standard Component Sizing - Example –4: Second, calculate the minimum, likely, and maximum maximum size of the product components. data input component: 1108, 4432, 7756 output component: 675, 2025, 3375 file component: 3170, 6340, 12680 control component: 2550, 5100, 7650 computation component: 475, 1425, 3325

Standard Component Sizing - Example – 5: Third, calculate the minimum, likely, and maximum LOC of the new product. minimum: 7,978 likely: 13,616 maximum: 34,786 The size estimate is then LOC = (7978+4*13616+34786)/6 = 16,205 LOC the standard deviation is (34786-7978)/6=4468 the estimate range is: 11,737 to 20,673 LOC

Standard Component Sizing - Advantages and Disadvantages: Advantages: based on relevant historical data. easy to use. requires no special tools or training. provides a rough estimate range. Disadvantages: must use large components early in a project. limited data on large components.

Delphi Size Estimating : Uses several estimators: each makes an independent estimate. each submits estimate to a coordinator. Coordinator: calculates average estimate. enters on form: average, other estimates. (anonymous), and previous estimate. When re-estimates stabilize: average is the estimate. range is range of original estimates.

Delphi Example – 1: 3 estimators are asked to estimate the product. Their initial estimates are. A - 13,800 LOC. B - 15,700 LOC. C - 21,000 LOC The coordinator t.hen. calculates average estimate as 16,833 LOC. returns this with their original estimates to the estimators.

Delphi Example - 2 The estimators then meet and discuss the estimates: Their second estimates are: A - 18,500 LOC. B - 19,500 LOC. C - 20,000 LOC. The coordinator then. calculates average estimate as 19,333 LOC. asks the estimators if they agree with this as the estimate.

Delphi Size Estimating - 2 Advantages: can produce very accurate results. utilizes organization’s skills. can work for any sized product. Disadvantages: relies on a few experts. is time consuming. is subject to common biases.

Wideband Delphi estimation: group effort with moderator. anonymous individual estimates submitted. estimate ranges tracked by moderator. re-estimating until estimates are within an acceptable range.

Function Points: Measure of the functionality delivered by the applications. Functionality cant be measured directly, it must be derived. indirectly using other direct measures. Function points are derived using an empirical relationship based on countable (direct) measures. of software’s information domain and assessments. of software complexity.

Computing Function Points: Analyze information domain of the application and develop counts Weight each count by assessing complexity Assess influence of global factors that affect the application Compute function points Establish count for input domain and system interfaces Assign level of complexity or weight to each count Grade significance of external factors, F i such as reuse, concurrency, OS, ... function points = (count x weight) x C where: complexity multiplier: C = (0.65 + 0.01 x N) degree of influence: N = F i

Analyzing the information domain: Determine the number of components: EI - The number of external inputs: These are elementary process in which derived data passes across the boundary from outside to inside. In an example library database system, enter an existing patron’s library card number. EO - The number of external outputs: These are elementary processes in which derived data passes across the boundary from inside to outside. In an example library database system, display a list of books checked out patron.

Analyzing the information domain: EQ - The number of external queries: These are . In an example library database system, determine what books are currently checked out patron. ILF- The number of internal log files: These are user identifiable groups of logically related data that resides entirely within the applications boundary that are maintained through external inputs In an example library database system, the file of books in the library. elementary processes with both input and output components that resolution data retrieval from one or more one or more internal logical files and external interface files.

Analyzing the information domain: ELF - The number of external log files: There are user identifiable groups of logically related data that are used for reference purposes only, and which reside entirely outside the system. In an example library database system, the file that contains transactions in the library’ .

Compute the Unadjusted Function Point Count: Rate each component as low , average , or high . For transactions ( EI , EO , and EQ ), the rating is based on the FTR and DTE. FTR - The number of files updated or referenced. DET - The number of user-recognizable fields. Based on the table, an EI that references 2 files and 10 data elements would be ranked as average .

Compute the Unadjusted Function Point Count: For files (ILF and ELF), the rating is based on the RET and DET. RET - The number of user-recognizable data elements in an ILF or ELF DET - The number of user-recognizable fields. Based on the table, an ILF that contains 10 data elements and 5 fields would be ranked as high .

Compute the Unadjusted Function Point Count Convert ratings into UFC's.

Taking Complexity into Account Degree of influence. General System Characteristics. Factors are rated on a scale of 0 (not important) to 5 (very important) Data Communications Distributed Functions Performance Heavily Used Configuration Transaction Rate Online Data Entry End User Efficiency Online Update Complex Processing Reusability Installation Ease Operational Ease Multiple Sites Facilitate Change

General System Characteristics: Data communications: How many communication facilities are there are to aid in the transfer or exchange of information with the app -lication or system? Distributed data processing: How are distributed data and proce -ssing functions handled? Performance: Was response time or throughput required by the users? Heavily used configuration: How heavily used is the current hardware platform where the application will be executed?

General System Characteristics: Transaction rate: How frequently are transactions executed daily, wee- ly, monthly, etc,? On-Line data entry: What percentage of the information is entered On- line? End-user efficiency: Was the application designed for end-user efficiency? On-Line update: How many ILF’s are updated by On-Line transaction? Complex processing: Does the application have extensive logical or mathematical processing?

General System Characteristics: Reusability: Was the application developed to meet one or many user’s needs? Installation ease: How difficult is conversion and installation? Operational ease: How effective and/or automated are start-up, back- up, and recovery procedure? Multiple sites: Was the application specifically designed, developed, and supported to be installed and recovery procedures? The application specifically designed, developed, and supported to facilitate change?

Compute the Final Function Point Count: complexity multiplier function points number of user inputs number of user outputs number of user inquiries number of internal files number of external files measurement parameter 3 4 3 7 5 count weighting factor simple avg. complex 4 5 4 10 7 6 6 5 15 10 = = = = = Unadjusted count-total X X X X X

Function Point Advantages: The advantages of function points are: they are usable in the earliest requirements phases. they are independent of programming language,product design , or development style, there exists a large body of historical data. it is a well documented method. there is an active users group.

Function Point Disadvantages: The disadvantages of function points are: you cannot directly count an existing product’s function point content. without historical data, it is difficult to improve estimating skill. function points do not reflect language, design, or style difference. function points are designed for estimating commercial data processing application.

Function Point example: Stock Control System Scenario. Refer to the MS Word file or handout provided to you.

Typical Function-Oriented Metrics: errors per FP. defects per FP. $ per FP. pages of documentation per FP. FP per person-month.

Extended Function Point Metrics: Function point was inadequate for many engineering and embedded system. A function point extension called feature points , is a superset of the function point measure that can be applied to systems and engineering software applications. Accommodate applications in which algorithmic complexity is high.

Extended Function Point Metrics: The feature point metric counts a new software characteristic – algorithms. Another function point extension – developed by Boeing. Integrate data dimension of software with functional and control dimensions. “3D function point”. “ Counted, quantified, and transformed”

Extended Function Point Metrics: To compute 3D function points, use this relationship: Index = I + O + Q + F + E + T + R (inputs, outputs,) inquiries, internal data structures, external files, transformation, tran- sition. Where each complexity weighted value is computed using: Complexity weighted value = N il W il +N ia W ia +N ih W ih Where N il , N ia , N ih represent the number of occurrences of element I for each complexity; and W il , W ia , and W ih are the corresponding weights.

Extended Function Point Metrics: Function points, feature points, and 3D point represent the same thing- “functionality” or “utility” delivered by software.

PROBE: historical data. conceptual design. subdividing design tasks. estimating subdivisions. obtaining total product size.

Achieving reliable estimates: Delay estimation as long as possible. Use historical data. Decompose tasks. Use an empirical cost model.

Cost models: predict effort as a function of software size. no model is appropriate for all cases.

The COCOMO Model: Constructive Cost Model : software cost estimation model. COCOMO II is a hierarchy of estimation models that addre- ss the following areas. Application composition model: prototyping of user interfaces, consideration of S/W and system interaction, assessment of performance, and evaluation of technology. Early design stage model: used once requirement have been stabilized and basic software architecture has been established. Post-architecture-stage model: used during the construction of the software. Stabilized and basic software architecture has been established.

The COCOMO II Model: The COCOMO II models require sizing information: object points, function points, and lines of source code.

COCOMO II: project type: organic. semi-detached. embedded. cost driver attributes. For more information : http://sunset.usc.edu/COCOMOII/Cocomo.html

COCOMO II Effort Calculation: Calculate KDSI ( thousands of delivered source instructions) Development Mode Basic Effort Equation Organic: Effort = 2.4 * (KDSI)**1.05 Semidetached: Effort = 3.0 * (KDSI)**1.12 Embedded: Effort = 3.6 * (KDSI)**1.20 Effort is measured in Staff Man-Months

COCOMO Development Time: Development Mode Basic Schedule Equation. Organic: TDEV = 2.5 * (Effort)**0.38 Semidetached: TDEV = 2.5 * (Effort)**0.35 Embedded: TDEV = 2.5 * (Effort)**0.32 Time to develop (TDEV) is the time to complete the project.

COCOMO Example : Organic mode project consisting of 3,000 lines of delivered code is estimated to require 7.6 staff-Months of effort, and 5.4 months to complete it: Effort = 2.4 * 31.05 = 7.6 Staff-Months. TDEV = 2.5 * 7.60.38 = 5.4 Months. Average staffing: 7.6 / 5.4 = 1.4 people.

PRICE: Estimates based on : Software size. Application. Complexity. Degree of reuse. Beta curves.

SLIM: Software Life Cycle Management. Estimates based on. Program size. Productivity index. Calibrateable manpower build-up index.

Other Factors Affecting Cost: learning curve. productivity. manpower cycle.

The Software Equation: A dynamic multivariable model that assumes a specific distribution of effort over the life of a software development project. The model has been derived from productivity data collected over 4000 contemporary software projects.

The Software Equation: Based on these data, an estimation model of the form: E = [LOC x B 0.333 / P ] 3 x (1/t 4 ) Where E = effort in person-months or person-years t = project duration in months or years B = special skills factor (i.e., B=0.16 when KLOC=5 to 15) P = productivity parameter (i.e., P=2000 for development of real- time embedded software).

The Software Equation: Minimum development time is defined as: t min = 8.14(LOC/ P ) 0.43 in months for t min > 6 months E = 180 B t 3 in person-months for E >= 20 person-months and t is represented in years

The Make/Buy Decision: Make/Buy decision concerns cost-effective options such as: Software may be purchased (or licensed) off-the-shelf “ full-experience” or “partial-experience” software components may be acquired Software may be custom built by an outside contractor

Creating a Decision Tree: The expected cost, computed along any branch of the decis- sicion tree, is. expected cost =  (path prob) i x (estimated path cost) i

Cost Estimation: Project scope must be explicitly define. Task and/or functional decomposition is necessary. Historical measures (metrics) are very helpful. At least two different techniques should be used. Remember that uncertainty in inherent.

Software Sizing

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Software Sizing (20)

Software Sizing