software size and cost estimation cen 5016 © dr. david a. workman school of computer science...

SoftwareSize and Cost Estimation

CEN 5016© Dr. David A. Workman

School of Computer ScienceFeburary 24, 2005

Revised:February 27, 2007

Feb. 27, 2007 (c) Dr. David A. Workman 2

Software Project Estimation

• METHODS of ATTACK

– Base estimates on similar projects that have already been completed.

– Use decomposition techniques.

– Use statistically derived empirical models.

• DECOMPOSITION TECHNIQUES

Accuracy depends on the following factors:• degree of accuracy with which the planner has estimated size of the system to be

constructed;• ability of planner to translate size estimates into human effort;• degree to which the project plan reflects the abilities of the software team;• stability of product requirements and the development environment.

– Fuzzy-logic Sizing

– Function Point Sizing (#EIF, #ILF, #EI, #EO, #EQ)

– Standard Component Sizing (subsystems, modules, screens, reports, files, menus )

– Change Sizing (modifications to an existing system)

Ref: Putnam and Meyers, Measures for Excellence, Yourdon Press, 1992.


Size-Related Attributes

• Source Lines of Code (SLOC or LOC)– Logical vs. Physical

Logical = a single source statement in a given programming language

Physical = physical lines in a source file (number of EOLs)

– Developed vs. Non-developed• Developed = source statements added or modified specifically for the

software product under development.

• Non-developed = reused source statements (without change) and deleted source statements ( removed or modified from a previous version or similar product).

– New SS = #added + #modified

– Deleted SS = #modified + #removed

– Reused SS = #original - #modified - #removed


Function Points: Introduction

• Reference

Function Point Analysis, by D. Garmus and D. Herron, Addison-Wesley, 2001, ISBN = 0-201-69944-3

• Definitions

– Number of Internal Logical Files (ILF)

– Number of External Interface Files (EIF)

– Number of External Inputs (EI)

– Number of External Outputs (EO)

– Number of External Queries (EQ)

– (Raw) Function Point Count = a weighted sum of counts of the five system features enumerated above. Weights are a function of feature complexity ( low, medium , high ) and empirical data.

– Adjusted Function Point Count = Raw FP * A( F1, F2, …, F14), where F1, F2, …, F14 are project adjustment factors that must be estimated as to their “degree of influence” ( 0..5 ).


Data Functions: Internal Logical Files

Definition (Internal Logical Files)(ILF)A user-identifiable group of logically related data or control information maintained

within the boundary of the system. The primary purpose is to hold data that must be maintained by one or more elementary operations and must persist beyond a single operation.

Clarification:– ILFs are internal entity objects/classes used to encapsulate and maintain

“problem” data within the system.– ILFs are standalone classes or base classes of an inheritance hierarchy.– Elementary Operation are methods defined for ILFs.

Examples:OSSIM: Computer System, Device, User, CPU, OS, Memory, Address Unit,

Process, Program, Segment, InstructionROBOT: Waiter, Assistant, Treats, Tray, Guest, Kitchen, Reception RoomTwine: Instruction, Basic Block, Code SegmentSatellite: Command, Recorded Data, Position, Velocity, AttitudeRover: Command, Target Vehicle, Position, Velocity, Attitude, Obstacles,

PathPACS: Program, Package, File, Class, Interface, Frame, Method, Feature,

SymbolFAMS: NFA, STD, TT, Alphabet, States


Data Functions: External Interface Files

Definition (External Interface Files)(EIF)A user-identifiable group of logically related data or control information

maintained by an application outside the boundary of the system. The primary purpose is to hold data that must be referenced by one or more elementary operations within the system.

Clarification:

– An EIF is an ILF for an autonomous system modeled as an actor (on-line independent systems).

– An EIF is a persistent database table.

– An EIF is any class designed to hold data for import or export to an actor other than interactive users.


Data Functions: Complexity Level

Principle: Each ILF and EIF must be assigned a complexity level based on the number of Data Element Types (DETs) and Record Element Types (RETs) associated with it.

RET: A subclass of an ILF or EIF. - Count “1” for standalone ILF or EIF classes.- Count “1” for the base class of each ILF or EIF inheritance hierarchy.- Add “1” for each derived subclass of an ILF or EIF inheritance tree.

DET: A unique user-identifiable, non-repeated field or attribute of an ILF, EIF or RET.- Count “1” for each group of data members that has a unique purpose.- Count “1” for each pointer or handle that maintains an association or composition relationship with some other object.- Count “1” for array objects and data members used to index that object. - For subclasses (RETs), consider only those data members explicitly defined by the subclass; inherited data members are already counted.


ILFs, EIFs, RETs, DETs

Class A

XY

Class A1

UV

Class A11

R

Class A12

T

Class B

alphabeta

Class B1

delta

Class Z

ABCDE

ILF = 3Class A ( RET = 8)(DET = 12)Class B ( RET = 2)(DET = 3)Class Z (RET = 1) (DET = 5)

Class A2

X1Y1

Class A21

U2V2

Class A211

R7

Class A211

T7


Data Functions: Complexity Weights

Complexity Weight

FP Category

Low Medium High

ILF x7 x10 x15

EIF x5 x7 x10

EI x3 x4 x6

EO x4 x5 x7

EQ x3 x4 x6

Rule1: For each ILF or EIF, use the RET count as a row index into Table 1. Use the DET count to define the column index into Table 1. The entry at the intersection of the row and column gives the complexity measure for the ILF or EIF. Note: the DET count for an ILF or EIF is summed over all RETs associated with that ILF or EIF.

Rule 2: For a given ILF or EIF use the complexity level from Table 1 as a column index in Table 2. Use the appropriate (ILF | EIF) row to index the weighting factor. Sum the weights for all ILFs (and EIFs). The result is the unadjusted (raw) Function Point count.

ILF

& EIF

Data Element Types

1-19 20-50 >= 51

1 Low Low Medium

2-5 Low Medium High

>5 Medium High High

Rec

ord

Ele

men

tT

ypes

Table 1. Complexity Level

Table 2. Complexity Weight


Function Points: External Inputs

Transactional Functions– External Inputs (EI)– External Outputs (EO)– External Queries (EQ)

Definition: (EI) External Inputs

An EI is an elementary process of the system that processes data or control information that enters from outside the system boundary. The primary purpose of an EI is to maintain one or more ILFs and/or to alter the behavior of the system via its processing logic.

Clarification:– An IE is an input operation (use case) that defines or updates some subset of the

data members of one or more ILFs; EIs are control class or boundary classmethods that manage a complete use case – these methods control use case INPUT operations for capturing problem data within the system.

– An IE must bring data across the system boundary to populate one or more ILFs.– The IE must have meaning to a system actor; that is, it is a use case involving one

or more actors. – Two IE’s are unique, if they differ in the ILFs they maintain or in the set of data

members they define or update; two constructors for different subclasses (RETs) of the same ILF would be treated as distinct IEs.

System Boundary

EI EQ

EO

ILF


Complexity: External Inputs

Principle: The physical count of EI’s, together with the relative functional complexity for each determines the contribution of the external inputs to the unadjusted Function Point count (UFP). Each identified EI must be assigned a functional complexity based on the number of DETs and File Types referenced (FTRs).

– Complexity = low, medium, high– DETs = those that receive problem data that crosses the system boundary– File Types Referenced = total number of distinct ILFs or RETs read or

updated by the EI together with the total number of EIFs (DB tables) read by the EI.

Counting Rules:1. Do NOT count DETs not associated with problem data crossing the system boundary.2. Add “1” DET for multiple fields serving a single purpose (e.g lines of an “street address”)3. Add “1” DET for all prompts sent across the system boundary as part of an EI process; not

“1” for each prompt or message – “1” for all such outputs.4. Add “1” DET for all error messages sent across the system boundary as part of an EI

process.5. Add “1” DET for all mechanisms that can trigger the action of the given EI; e.g., if a mouse

click and function key are two distinct interaction mechanisms for triggering the same EI, then count only “1” (for the EI), not “2” for the different invocation methods.

6. Count only “1” FTR for each ILF, RET, or EIF that is both read and maintained (updated) by the same EI.


Transaction Function: External Output

Definition: (EO) External OutputAn EO is an elementary process of the System that generates data and control

information that exits the System boundary. The primary intent of an EO is to present information to a System actor through processing logic other than, or in addition to, the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, create derived data, maintain one or more ILFs and/or alter the behavior of the System.

Clarification– An EO is an output use case (“ the smallest unit of activity that is meaningful to

the user).– An EO must leave the System in a consistent state.– Control information is data used or generated by the System for the purpose of

influencing an elementary process (use case); e.g., control signal in real-time systems, output messages instructing the user to take some action.

– Processing logic on its own should not be used to determine unique EI, EO or EQs; re-arranging, re-formatting, and re-sorting a set of data in various ways do not by themselves constitute unique EO’s.

– unique calculations must be involved producing new information having meaning to the user.



Examples– Mathematical calculations or unique algorithms

– Conversion of units associated with values

– Selecting a data subset based on some specified criteria

– Updating ILFs, RETs or EIFs (but not using data crossing the system boundary)

– Retrieval of data or control information

– Computing or creating derived data

– Altering the behavior of the System in some way

– Preparation and presentation of information outside the System boundary

Counting Rules:1. The data or control information must exit the System boundary (eventually)

2. The processing logic (algorithm) of the EO must perform one of the following:(a) a mathematical calculation (b) compute derived data(c) update at least one ILF, RET or EIF(d) alter the behavior of the System

3. The EO must be the smallest unit of activity meaningful to the user.

4. The EO must be self-contained and must leave the System in a consistent state.


Transaction Function: External InQuiries

Definition: (EQ) External InquiriesAn EQ is an elementary process (use case) of the System that results in the retrieval

of data or control information sent outside the System boundary. The primary intent is to present information to an actor maintained in an ILF or EIF. The processing logic contains no mathematical formulas or calculations and creates no derived data (it is output or presentation only). No ILF is updated during processing, and the behavior of the application is not altered.

Clarification

– An EQ involves a request for information (calls on inspector methods), generally from an ILF or an EIF, extracting the relevant DETs, and presenting them across the System boundary to the user (or actor); e.g., file output operation, GUI display operation, or database write operation.

– The data or control information must cross the System boundary.

– The data must be retrieved from one or more ILFs, RETs and/or EIFs.

– The EQ cannot derive data, cannot perform mathematical computations, nor influence the behavior of the System (this characterizes an EO).

– An EQ cannot update (write to) an ILF, must be self-contained, and must leave the System in a consistent state.


Counting Rules: EO and EQ

Counting Rules (DETs)1. Control fields that determine what, when, and/or how data is to be retrieved or generated.2. Unique, user-recognizable, non-repeated fields that exit the System boundary.3. If a DET both enters and leaves the System boundary, count it only once for the EO or EQ.4. Count one DET for the capability to send a System response message outside the System

boundary to indicate an error, confirm that processing is complete, or verify that processing should continue.

5. Count only one DET for the capability to specify an action to be taken by an EO or EQ even if there are multiple invocation mechanisms for the action (count one for all call instances of a given EO or EQ method).

6. Do NOT count System generated report fields such as “page no.”, “run date”, “positioning info.”

7. Do NOT count literals, report titles, screen Ids, column headings and field titles.8. Do NOT count temporary ILF fields computed during an EO or EQ if they do not cross the

System boundary.9. Count one DET for a logical field that is stored physically as multiple fields but is viewed by

the user as a single piece of information.10. Count one DET for each type of label and each type of numerical equivalent appearing on a

graphical display.11. Count one DET for text information that may consist of a single word, sentence, paragraph,

or many paragraphs, but has a single meaning or purpose to the user.



Counting Rules (FTRs)1. Add “1” to the FTR count for each ILF, RET or EIF read during the EO or EQ.

2. Add “1” to the FTR count for each ILF, RET or EIF updated by an EO.

3. Add only “1” to the FTR count for an ILF, RET or EIF that is both read and updated by an EO.

NOTE: FTRs count the number of distinct classes, subclasses, or tables accessed by EI, EO and EQ operations. DETs are counts of the data members actually accessed by these operations.


Example: EI, EO, EQ

Browser IIS

TCP/IP 1*

ASP#Page

ASP#Page

WRMSDB

EQ

EI

EI

EI

EI

EO

EOEO

EIFs

ILF ILF

Client Node(s) Server Node


Complexity Level: EI, EO, EQ

EIData Element Types

1-4 5-15 >= 16

<2 Low Low Medium

2 Low Medium High

>2 Medium High High

Fil

e T

ypes

Ref

eren

ced

EOData Element Types

1-5 6-19 >= 20

<2 Low Low Medium

2-3 Low Medium High

>3 Medium High High

Fil

e T

ypes

Ref

eren

ced

EQData Element Types

1-5 6-19 >= 20

1 Low Low Medium

2-3 Low Medium High

>3 Medium High High

Fil

e T

ypes

Ref

eren

ced

Use the FTR count to index the row and the DET count to index the column of the table corresponding to a given EI, EO or EQ to determine its complexity level.


Adjustment Factors: Overview

• Complexity Adjustment Factors (Fi : 1 <= i <= 14)

F1: Data Communication: the degree to which on-line communication with other systems or interactive users is required or central to the application.

F2: Distributed Data Processing: the degree to which the application itself is composed of autonomous and distributed components or subsystems; distributed data is included in this factor.

F3: Performance: the degree to which response time and throughput performance impact development.

F4: Heavily Used Configuration: the degree to which resource restrictions influence the system design and development; includes situations where the system must share or compete for resources with other independent applications.

F5: Transaction Rate: applies primarily to transaction processing systems where transaction rate is a critical design constraint.




F6: On-line Data Entry: the degree to which data is entered interactively; includes on-line data entry and control.

F7: End User Efficiency: the degree to which consideration for human factors and ease of use for end-users impacts system design.

F8: Online Update: the degree to which on-line (interactive) update to internal logical files (ILFs) impacts system design.

F9: Complex Processing: the degree to which complexity of processing or algorithmic logic impact system design; this includes the amount of data validation and exception handling is required.

F10: Reusability: the degree to which the application and the design are required to be reusable.

F11: Installation Ease: the degree to which conversion from previous and possibly future environments influence the development of this system.




F12: Operational Ease: the degree to which operational aspects of the system influence its design; e.g. start-up, recovery, backup processing, and minimizing the need for manual intervention in these processes.

F13: Multiple Sites: the degree to which the system is to be developed for multiple locations and user organizations. Installation on multiple sites is required.

F14: Facilitate Change: the degree to which the system has been designed for easy maintenance, enhancement and flexibility.

Weight for design impact: 0..50 = no influence (not present)1 = incidental influence2 = moderate influence3 = nominal influence4 = significant influence5 = very large influence


SLOC to Function Points

? Numbers have not been validated

Estimating Software Costsby Capers Jones, McGraw-Hill, 1998.

Language LOC per FP

Assembly Language 320

C 128

COBOL 105

Fortran 105

Pascal 90

Ada95 53

Visual Basic 32

Prolog, Lisp, Forth 65?

OOPL 30?

(Java) 45-55?

(C++) 64

(SmallTalk) 22

4GL 20?

Lex, Yacc 15?

PowerBuilder 16

Spreadsheets 6?

GUI 4?


SLOC to Function PointsCocomo II Model Definition ManualBy Barry Boehm et a., 1999.


Function Points: ExampleFP

Category Low Medium High Row

UFP EI 3 x3 6 x4 0 x6 33

EO 0 x4 0 x5 1 x7 7

EQ 0 x3 3 x4 0 x6 12

ILF 3 x7 0 x10 0 x15 21

EIF 1 x5 0 x7 0 x10 5

Total Unadjustd FP = 78

NOTES:Data and Transaction counts are in red, weights in blue.Complexity weights = see slide 8Value adjustment factors (Fi) = (see slide 17 - 19)LOC to FP conversion = (see slide 20)

Factor F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14

Value 4 0 3 2 3 5 4 3 1 0 0 3 1 2

220. 2, = 30 74 = LOC 74 = FP

0.31) + (0.6578 = F0.01+0.65 UFP= FP i


Extensions to Function Point Methods

• Feature Points (Jones 1991)

"Feature Points" are a super set of Function Points. Special "Algorithms" are added to the list of features counted.

• BOEING (3D Function Points)(Whitmire 1995)

– Data Dimension

– Function Dimension

– Control Dimension


COCOMO

• Basic Formulas (LM = labor months; DT = development time in months)Organic: Small number of experienced developers who are familiar with both the

application area and the development environment. Product size varies from small to medium.

Semi-detached: Lies between Organic and Embedded in its demand on resources and development process. Assumes the development team is a mix of experienced and inexperienced personnel with little experience working together. Product size varies from medium to very large.

Embedded: Requires the most resources. Has stringent requirements on reliability, performance, schedule, external interfaces, and timing. Employs a development process with frequent reviews and rigid test requirements. Product size varies from medium to large.

0.381.05 2.5(LM) DT 2.4(KSLOC)LM

0.351.12 2.5(LM) DT 3.0(KSLOC)LM

0.321.2 2.5(LM) DT 3.6(KSLOC)LM


COCOMO

• Cost Drivers– RELY: effect of software reliability

– DATA: effect of database size

– CPLX: effect of software complexity

– TIME: effect of execution time constraints

– STOR: effect of constraints on main storage

– VIRT: effect of virtual machine volatility (environment stability)

– TURN: obsolete (choose 1.0)

– ACAP: effect of analyst's capabilities

– AEXP: effect of team's experience

– PCAP: effect of programmer's capabilities

– VEXP: effect of team experience with development/target environment

– LEXP: effect of programmer's experience with programming language

– MODP: effect of using modern development methods on team

– TOOL: effect of using advanced development tools on team

– SCED: effect of schedule constraints

Each cost driver defines a multiplicative coefficient to thevalue of LM defined by thebasic models. Call LM' the resulting adjusted labor months.

See table on next slide factorDriver Cost i CD whereLM,CDLM' thi

ii


COCOMOAttribute Weighting Factor

VeryLow

Low Nominal High Very High ExtraHigh

ProductRelated1: RELY 0.75 0.88 1.0 1.15 1.4

2: DATA 0.94 1.0 1.08 1.16

3: CPLX 0.7 0.85 1.0 1.15 1.3 1.65

ComputerRelated4: TIME 1.0 1.11 1.3 1.66

5: STOR 1.0 1.06 1.21 1.56

6: VIRT 0.87 1.0 1.15 1.3

PersonnelRelated7: ACAP 1.46 1.19 1.0 0.86 0.71

8: AEXP 1.29 1.13 1.0 0.91 0.829: PCAP 1.42 1.17 1.0 0.86 0.7010: VEXP 1.21 1.10 1.0 0.9011: LEXP 1.14 1.07 1.0 0.95ProjectRelated12: MODP 1.24 1.10 1.0 0.91 0.82

13: TOOL 1.24 1.10 1.0 0.91 0.83

14: SCED 1.23 1.08 1.0 1.04 1.10


COCOMO II Formulas

SCED.without PM is PM where, 100

SCEDPM67.3

}SCEDSITE,TOOL, LTEX, PEXP, AEXP, PCON,PCAP,ACAP,

PVOL,STOR,TIME,RUSE, DOCU,CPLX,DATA,RELY,{EM

Model reArchitectu-Postfor 17

}SCEDFCIL,PREX,PERS,PDIF,RUSE,RCPX,{EM

ModelEarly for 7

0) (Reeng1000

ESLOCor 0) (Reeng

1000

SLOC Size

}PMATTEAM,RESL,FLEX,,PREC{ W where, W01.091.0

value)calibrated(Latest 94.2

Reeng)(

estimated

)01.1(2.028.0

i

i

kk

k

B

B

Dev

n

iiestimated

T

n

B

A

SizeAEMPM


COCOMO II FormulasWith REUSE

IMCMDMAAF

AAFUNFMSUAAFAAASLOC

ESLOC

AAFUNFMSUAAFAAASLOC

ESLOC

3.03.04.0

5.0,100

5.0,100

02.00.1

ASLOC = Adjusted SLOC ( SLOC modified legacy)AA = Assessment Assimilation Increment (degree of effort needed to determine whether a full-reused module is appropriate and to integrate its description into the overall product.DM = Percentage of the original design that must be modified to accommodate the new requirements.CM = Percentage of the original code that must be modified to accommodate the new software and its environment.IM = Percentage of Integration required for modified software in comparison to normal amount required for integration and test of software of comparable size.SU = Software Understanding Increment (penalty)UNFM = Programmer Unfamiliarity Increment.


COCOMO II FormulasWith REUSE (continued)



Reeng =


Sizing Procedure A

1: As a team, apply the Brooks rule using current time expended on the project assuming we are half-way through the "design" phase.

“My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing.”

2. Apply Schach Pi-Chart

3. Compute Function Point estimations of SLOC and Effort using COCOMO-II (a) Individually compute SLOC and Effort

(b) As a team arrive at SLOC and Effort

(c) Use a weighted average of Low, High, Average of (a) & (b)

4. Compute SLOC by sizing components individually and Effort using COCOMO-II or some other productivity factor. (a) Individually compute SLOC and Effort

(b) As a team arrive at SLOC and Effort

(c) Use a weighted average of Low, High, Average of (a) & (b)

5. Compute a weighted average of 1 - 4


Sizing Procedure B

1. Apply Schach Pi-Chart to estimate:• (a) Effort to complete• (b) Calendar time to complete (using your averages team hrs/week)

2. Compute SLOC by Module breakdown analysis. (a) Count Classes to Develop/Modify – Boundary, Entity, Control

(b) Size each Class in (a) by counting methods to develop/modify

(c) Size each method (using high, medium, low) and assign SLOC count to each size category.

(d) Convert SLOC to hours, and hours to work weeks using your performance data.

3. Apply the OO Function Point Analysis to Completed Code!

Use the FP methodology on your delivered implementation to arrive at actual FP and then compute the SLOC/FP ratio for the implementation language you used.

See NotesFor more

details


Sizing Data for Java Classes

Size Categories

<= 10 11 <= 30 > 30 Totals

#All 139 37 22 198

Ave Size ALL 5 18.78 66.82

%All 70.20 18.69 11.11

#Bndry 78 27 11 116

Ave Size Bndry 5 18.33 55.91

%Bndry 67.24 23.28 9.48

#Entity 56 10 11 77

Ave Size Entity 5 20.00 77.73

%Entity 72.73 12.99 14.29

software size and cost estimation cen 5016 © dr. david a. workman school of computer science...

Documents