Cost and Effort Estimation

UFP

Unadjusted function points. Calculate by assigning appropriate number of function points to each component of product (input, output, inquiries, master files, interfaces)

the lower level the language....

the more productive the programmer. Same functionality takes more code to implement in a lower level language than in high level language

cost

time + money (effort + resources)

size

time used for team communication increases nonlinearly with project size

technology

tools suppo/softwarrt, hardwaree availability

Parkinson's law

1. "work expands so as to fill time available for its completion" 2. cost of project is determined by all resources available rather than by objective assessment 3. advantages: no overspending possible 4. disadvantages: system usually unfinished at scheduled completion date

COCOMO2

1. COCOMO81 dev'd assuming waterfall process would be used and all software developed from scratch 2. COCOMO2 supports spiral model of development 3. incorporates range of submodels that produce increasingly detailed software estimates 4. use set of 17 multipliers to reflect personnel capability, product and project characteristics

COCOMO Model

1. COnstructive COst Model (Barry Boehm, 1981) 2. empirical model based on project experience 3. well-documented 'independent' model not tied to a specific vendor 4. COCOMO2 takes into account different approaches to software dev, reuse, etc. published in 2000 5. initial version in 81. COCOMO81. instantiated several times up to COCOMO2

metrics based on measurable quantities that can be determined early in software life cycle

1. FFP (files, flows, processes) 2. function points

Factors for cost/effort estimation

1. Opportunity 2. uncertainty 3. contract 4. volatitlity 5. stability

COCOMO2 models

1. application composition model: used when software composed from existing parts 2. early design model: used when reqs available but design not yet started 3. reuse model: used to compute effort of integrating reusable components 4. post-architecture model: used once system architecture has been designed and more info about system is available

size-related measures

1. based on some output from software process

3 stages of COCOMO81

1. basic: estimate based on product attributes 2. intermediate: modifies basic estimate using project and process attributes 3. advanced: estimates project phases and parts separate Assume waterfall model is used in SW dev, and using standard imperative program languages (C, FORTRAN)

3 steps for function points

1. classify each component of product (input, output, inq, Maf, interfaces) as simple, average, or complex. Assign appropriate numer of function points. Sum gives UFP 2. compute techincal complexity factor (TCF) and calculate Total Degree of Influence (TDI) 3. number of function points given by FP = UFP x TCF

function points

1. combination of program characteristics a. external I/O b. user interaction c. external interfaces d. files used by system 2. each factor assessed and weighted from 3 (simple input) to 15(complex files) 3. based on number of inputs, outputs, inquiries, master files, interfaces

estimation by analogy

1. comparison to similar project in same application domain 2. advantages: accurate if data available 3. disadvantages: impossible if no comparable project has been done

how to calculate TDI

1. compute TCF by assigning 0(not present) to 5(strong influence throughout) to each factor such as transaction rates, portability, ease of installation, reusability, etc, then add all numbers

Algorithmic Cost Modeling

1. cost estimated as mathematical function of product, project, and process attributes (e.g. project size, # of engineers) whose values are estimated by project manage. Size: LOC or FP 2. Size (LOC) is most used product attribute for cost estimation

Pricing to win

1. cost estimated to be whatever customer has to spend 2. estimated effort depends on customer's budget, not software functionality 3. advantages: likely to win contract 4. disadvantages: costs don't accurately reflect work required; customer satisfaction low

Objectives of cost estimation

1. establish budget for project 2. control project costs 3. monitor progress against budget by comparing planned w/estimated costs 4. create cost database for future estimation

Summary of estimation

1. estimation is a key management activity 2. many factors affect productivity; LOC still used due to simplicity 3. estimation should be based on several methods, not single measures 4. pricing to win often only viable approach to winning a contract 5. COCOMO is a wellknown algorithmic method used by mature organizations

Effort estimation factors

1. experience 2. process 3. size 4. technology 5. environment

Estimation techniques

1. expert judgment 2. estimation by analogy 3. parkinson's law 4. pricing to win 5. topdown estimation 6. bottom up estimation 7. algorithmic cost modeling

expert judgment

1. experts in software dev and application domain use their experience to predict costs 2. each estimate compared and discussed until agreement is reached 3. advantages: relatively inexpensive; can be accurate if experts have direct exp w/similar systems 4. disadvantages: need experts

Indirect resource costs

1. hardware and software 2. traveling and training 3. infrastructure: a. building/heating/lighting/shared facilities b. computing, networking, communications c. benefits

Fundamental estimation questions

1. how much effort is required to complete an activity 2. how much calendar time is needed to complete an activity 3. what is total cost of an activity 4. project estimation and scheduling are interleaved management activities

2 kinds of languages

1. imperative: based on Fennoi machine. 3 characteristics: variable, assignment, loops 2. functional: based on functions, returning values. Ex: LISP.

top-down estimation

1. may be any of the previous approaches 2. start at system level and assess the overall system functionality and how this is delivered through subsystems 3. usable w/o knowledge of architecture 4. advantages: takes into account costs such as integration, configuration management, and documentation 5. disadvantages: can underestimate the cost of solving difficult low-level technical problems

changing technologies

1. most estimation techniques rely on experience-based judgements by project managers 2. changing tech may mean that previous estimating experience deosnt carry to new systems

Considerations for defining lines of code

1. multiple statement lines? 2. do commentedl lines count? 3. executable lines? 4. daata definitions? 5. comments? 6. JCL (Java control language) statements? alternate metric: Thousand Delivered Source Instructions (KDSI). The more verbose the programmer, the higher the productivity?

difficulties in cost estimation

1. reqs not clearly specified 2. pressure to provide effort estimate without really understanding what is being asked 3. no easy measures: volume "a few/many" "good enough" "too many bugs"

Estimation accuracy

1. size of system can only be known when it is finished 2. factors influencing final size: a. use of COTS b. programming language c. distribution system 3. as dev progresses, size estimate more accurate

measures of productivity

1. size-related measures 2. function related measures 3. function opints are the best known of this type

Productivity Comparisons

1. source code is only a small part of the total software effort 2. different languages lead to different lengths of code 3. Meaningless language comparisons: APL vs assembler Java vs COBOL Tcl/TK vs C++ 4. LOC not defined for nonprocedural languages (like LISP) 5. LOC still most used measure

Resources include:

1. staff: salary + overhead 2. expertise: staff, contractors, consultants 3. indirect: cross-organizational taxes

examples of changing tech that may cause previous estimating experience to not carry over

1. use of CASE tools and program generators 2. use of web services 3. use of COTS 4. development using scripting languages

price to win

1. when detailed information is lacking, may be only appropriate strategy 2. project cost agreed on basis of an outline proposal and the development is constrained by that cost 3. a detailed specification may be negotiated or an evolutionary approach used for system dev 4. buyer and seller agree on what is acceptable functionality 5. fixed factor in many projects is not the requirements, but the cost: reqs can be changed so cost is not exceeded

important notes about quality and productivity

1.all metrics based on volume/unit time are flawed b/c dont take quality into account 2. productivity may generally be increased at cost of quality 3. if reqs constantly changing then an approach based on counting LOC not meaningful as program itself is not static

initial estimations based on....

1.inadequate info in a user requirements definition. 2.Software may run on unfamiliar computers or use new tech. 3. ppl in project may be unknown

human factors

Sackman (1968) measured differences of up 28 to 1 between pairs of prgorammers Critical staff may resign during project

TCF

Technical complexity factor.

bottom-up estimation

any of previous approaches may be bottom-up. 1. start at component level and estimate effort required for each component. Add these efforts to reach a final estimate 2. usable when architecture of system is known and components identified 3. advantages: accurate if system has been designed in detail 4. disadvantages: may underestimate costs of system-level activities like integration

function-related measures

based on an estimate of the functionality of delivered software

Sackman's research

compared pairs of prgorammers w/respect to: 1. product size - 6:1 2. product execution time - 8:1 3. development time - 9:1 4. coding time - 18 : 1 5. debugging time - 28 : 1

internal cost

cost to developers

FFP

files, flows, processes

stability

fiscal health problems may cause lower bids to win contract

process

hindrance or help

biggest difficulty in cost/effort estimation

human factor

uncertainty

increase price as contingency planning

environment

infrastructure, offices, cubicles

experience

knowledge of application and implementation domains

opportunity

low price quoted to enter new segment and gain market share

volatility

lower price due to changing requirements; price increased once contract is awarded

Estimation

predicting effort required for SE activity: designing, coding, writing, etc

external cost

price that client pays

contract

retain product ownership for future use