Estimation – Software Projects

project planning - what to doproject control make sure it’s done rightestimation of detailed system design

Planning Process

• determine requirements from objectives

• specify work activities

• plan project organization

• develop schedule

• develop resource plan and budget

• establish control mechanisms

each project unique

Determine Requirements

Specify work activities

STATEMENT OF WORK:– product descriptions– constraints– schedule requirements– budget limits– roles & responsibilities

WORK DEFINITION

• once objectives set,

TRANSLATE INTO WORK ELEMENTS

• what needs to be done– easy to overlook some, or duplicate

• WORK BREAKDOWN STRUCTURE– divide project into major work

categories• subdivide

Work Breakdown Structure

w hat's been doneP A C K A G E

needs doingP A C K A G E

libraryTA S K

searchP A C K A G E

internetTA S K

researchC A TE G O R Y

w riteP A C K A G E

w ritingC A TE G O R Y

run offP A C K A G E

printingC A TE G O R Y

w rite paperP R O JE C T

Work Breakdown Structure• level 1 - overall project

• level 2 - category– major project sub-element

• level 3 - task– Sub-element of category

• level x - subtask

• level bottom - WORK PACKAGE– specific activity

Detailed Task List

• WBS can be focused on– PRODUCT– FUNCTION– etc.

• when work packages identified,– estimate requirements by resource– WHAT IS NEEDED– WHEN– WHAT MUST PRECEDE

Work Breakdown Structure

• needs to be checked, approved

• provides– good definition of work– how long it will take– resources required– estimated costs

• planning & control– assignments, budget, basis for control

Work Packages• chunk of required work

• relatively small cost and short duration

• include– summary of work– inputs required (predecessors)– manager responsible– product specifications– resources required (including budget, dates)– deliverables

list of work packages(activities)

system designactivity predecessor timeA2 identify req’d info A1 10 daysA31 basic software A2 3 daysA32 data access req’d A2 1 dayA33 vendor softwareA2 1 day

Work Packages

• need to identify start and finish events for each work package

• related tasks without definable end results (overhead & management; inspection; maintenance) should be included as task-oriented work packages for COST purposes

Project Organization

• identify resources required by work package

• RESPONSIBILITY MATRIX– which functions do what work packages– cost account structure

• start & finish date• budget• responsibilities

Project Management System

• lists activities on one axis

• lists people on other axis

• shows who is– primarily responsible– also involved– has approval authority– must be notified

Scheduling

• BASIS for – RESOURCE ALLOCATION– ESTIMATED COST– plan for monitoring & control

• EVENTS or MILESTONES– when activity completed (or started)– INTERFACE EVENT

• when responsibility passes

Kinds of Schedules

• project schedules– project master schedule - top

management– overview rather than detail

• task schedules– specific activities required– more detail

Resource Plans & Budgets

• Activities often compete for the same resources– hire more– reschedule

• Resource plans show critical resource schedules– bottlenecks around which schedule is

built

Charts

visual aids• Gantt Charts

– plan - activities by time (work in outline)– implement - fill in as work done– doesn’t show relationships well– very good at seeing where things are (IF

ACCURATE)

• Expense Charts - cumulatively graph $ spent

Recap

• Planning - key to accurate bidding• need to know what it will cost in order to know how to

price• need to know resources required, complex projects take

a long time• MIS projects

– activities, predecessor relations, resource use

Software Estimation

The Mythical Man-Month:

Essays on Software Engineering

Frederick P. Brooks, Jr. (U N. Carolina)Addison-Wesley: 1975

Programming Products

• Program– usable by author

• Programming System– usable by anyone

• Programming Product– tested, documented, maintained– 3 times the effort of a program

• Programming System Product

causes of project failure

• LACK OF CALENDAR TIME the most common– estimating techniques are poor– assume that effort = progress

• you can’t just throw people at a problem

– poor monitoring of progress

• SCHEDULING– tendency to assume all will go well

impact of adding people

• partitionable project– marginal contribution declines

• non-partitionable project– no benefit at all from adding people

• complex interactionsmust separately coordinate each task with all others

– first few have declining marginal contribution– after some number, adding people slows down

project

Software Project Activities

• testing is the activity most difficult to predict– planning 1/3 of project– coding 1/6 of project– component testing 1/4 of project– system testing 1/4 of project

• most projects are on schedule UNTIL TESTING• Brooks’s Law: Adding manpower

to a late project makes it later

programmer productivity

• there is wide variation in productivity between good and fair programmers

• Brute force failures– costly OS/360 TSS– slow Exec 8 SAGE– inefficient Scope 6600– nonintegrated systems Multics

impact of adding programmers

• if a 200 person project has its best 25 people as managers– fire the 175– make the 25 managers programmers

• shouldn’t have more than 10 people on a team• OS/360 had 1000 working on it, 5000 man-years• small teams infeasible; use surgical teams

surgical team

• surgeon chief programmer• copilot share thinking, evaluation• administrator boring details• editor references, documentation• secretaries (2)• program clerk technical records• toolsmith editing, debugging• tester develop test cases• language lawyerexpert on language

conceptual integrity

• better to reflect one set of design ideas than to add independent and uncoordinated features & improvements

• purpose of programming system is to make computer easy to use

• simplicity & straightforwardness come from conceptual integrity

conceptual integrity example

• OS/360– architect manager: said his 10 person team could write

specifications in 10 months (3 months late)– control program manager: his 150 people could get it done in

7 months, & if his people didn’t do this, they would have nothing to do

– architect manager: control program people would take 10 months, do a poor job

– Brooks gave to control program group– took 10 months, plus added year to debugging

estimating programming time• duration is exponential (bigger jobs take more than

proportionally longer)– analogous to sprint 100 yards, running 1 mile

effort = K x (number of instructions)1.5

• one manager noted programming taking twice as long as estimate– only getting 20 hours of work/week– machine down, divert to emergencies,

meetings, paperwork, sick

programming estimation

• the more interactions, the less productivity– interaction = coordination with others

• high level languages increase productivity– now tools should almost eliminate the

programming component, but there are other activities (the more unpredictable ones)

(prototyping)

• in most projects, the first system built is barely usable

• PLAN THE SYSTEM FOR CHANGE– modularization– subroutining– interfaces– documentation of interfaces– high-level languages

software estimation

Charles R. SymonsSoftware Sizing and Estimating: Mk II FPA

Wiley [1991]

software production cycle

• DESIGN

• DEVELOPMENT

• production not hard

• MAINTENANCE

recognized as a difficult task

software production cycle

• SYSTEM SIZE a variable in – DESIGN– DEVELOPMENT– MAINTENANCE

• components of system size– amount of information processed– technical requirements– performance drivers (objectives)

objectives

• COST minimization

• TIME minimization

• QUALITY assure that product

performs to specifications

size measures

• source lines of code+ concrete measure- what lines?- logical or physical?- housekeeping?- different across languages

• most commonly used• some economy of scale

Albrecht’s Function Point Analysis MethodAIMS

– consistent measure– meaningful to end user

• function points should be easier to understand than lines of code

– rules easy to apply– Can estimate from requirements

specification– independent of technology used

Albrecht’s system

• count – external user inputs– enquiries– outputs– master files delivered (internal & external)

• get points for every useful activityfunction points=

information processing size x technical complexity adjustment

Albrecht’s System

complexity tables– data elements referenced

• 1-4• 5-15• 16 or more

– file types referenced• 0 or 1• 2• 3 or more

table of SIMPLE, AVERAGE, COMPLEX

Albrecht complexity

1-4 data 5-15 data 16+ data

0 or 1 filetypes

SIMPLE SIMPLE AVERAGE

2 filetypes

SIMPLE AVERAGE COMPLEX

3+ filetypes

AVERAGE COMPLEX COMPLEX

Albrecht functional multipliers

SIMPLE AVERAGE COMPLEX

external input x 3 x 4 x 6external output x 4 x 5 x 7logical internal file x 7 x 10 x 15ext interface file x 5 x 7 x 10external inquiry x 3 x 4 x 6

add up, get total unadjusted function points

Albrecht Technical Complexity Adjustment14 general application characteristics

data communications on-line update distributed functionscomplex processing performance re-useabilityheavily used configuration installation ease transaction rateoperational ease on-line data entry multiple sitesend user efficiency facilitate change

not present = 0 average influence = 3

insignificant influence = 1 significant influence = 4

moderate influence = 2 strong influence = 5

TCA = 0.65+(0.01x(total degree of influence))

Symons’ complaints

• Albrecht method– alternative counting practices– weights used are questionable– large systems under-weighted

• (XEROX 1985: rapid drop in productivity with increasing system size)

– range of points too narrow

• but MUCH BETTER THAN SLOC

Mk II Function Point Analysis• modification of Albrecht• use same Technical Complexity

Adjustment• extend general application

characteristics to 19 or more• weights adjusted• Information Processing Size changed

the most

logical transactions

logical transaction = – unique input/process/output

combination triggered by unique event of interest to the user

– or need to retrieve information• create a customer• update an account• enquiry• produce monthly summary report

unadjusted function points

UFPs = WI x # input data element types

+ WE x # entity types referenced

+ WO x # output data element types

weights determined by calibrationdetermine UFPs for system by adding UFPs for all system

logical transactionsassumes work directly proportional to # of data elements;size of process proportional to # data entries;weights meaningful, obtainable

complexity adjustment

Albrecht’s method with 2 modifications:– extend general application list to 19

• interfaces to other applications• special security features• direct access requirement for third parties• special user training facilities• documentation requirements

TCA = 0.65 + C x (total degree of influence)where C is obtained by calibration

calibration

by CALIBRATION Symons means fit the company’s data

regressindustry averages:

WI 0.58

WE 1.66

WO 0.26

Mk II FPA summary

• obtain general understanding of the system• construct a model of primary entities• identify logical transactions• score degree of influence of all 19 general

application characteristics (plus client specific)• obtain total project work-hours, calibrate• calculate function points

comparison

SLOC Albrecht Mk II FPA

accepted standard no yes yesclarity potentially some subjective

objectivestructured? no no yeseasy to use? yes no noautomatable? yes no yesuse for estimating? sometimes yes yes

Estimation Example

SLOCFunction Point

Source Lines of Code

• NEED DATABASE of past experienceAVERAGES effort 33 months

cost $361 (thousand)

documentation 1194 pages

errors 201

defects 52

people 4

KLOC 20.543

Implementing LOC

• Estimate structured lines of code10,000

• averages proportional to LOC 10/20.543 = 0.487 effort 33 months 0.487 = 16cost $361 thou 0.487 = $177,000documentation 1194 pages 0.487 = 581 pp.errors201 0.487 = 98defects 52 0.487 = 25people 4 0.487 = 2 people

Function Point Calculation

1 - get count-totalnumber of features times complexity

2 - get Fi

rate 14 factors (0-5), total3 - FP = count-total [0.65 + 0.01 Fi ]

4 - multiply historical averages (623) per FP by this FP

1 - get count total

Complexity Weightingsimple average complex

product# user inputs __ 3 + __ 4 + __ 6 = ___# user outputs __ 4 + __ 5 + __ 7

= ___ # user inquiries __ 3 + __ 4 + __ 6 = ___# files __ 7 + __ 10+__ 15 = ___# external interfaces __ 5 + __ 7 + __ 10

= ___

1 - get count-total

Bank accounts record system involving36 user inputs simple complexity5 user outputs average complexity20 user inquiries simple complexity40 files accessed simple complexity3 external interfaces average complexity

1 - get count-total

Complexity Weightingsimple average complex product

36 user inputs 36 3 + __ 4 + __ 6 = 108

5 user outputs __ 4 + 5 5 + __ 7 = 25

20 user inquiries 20 3 + __ 4 + __ 6 = 6040 files 40 7 + __ 10+__ 15 = 2803 external interfaces __ 5 + 3 7 + __ 10 =

21TOTAL 494

2 - get Fi

F1 require reliable backup & recovery? Significant 4F2 data communications required? Moderate 2F3 distributed processing functions? Significant 4F4 performance critical? Average 3F5 run on existing, heavily utilized environment? Essential 5F6 require on-line data entry? Essential 5F7 on-line data entry from multiple operations? Incidental 1F8 master files updated on-line? No influence 0F9 inputs, outputs, files, or inquiries complex? Incidental 1F10 internal processing complex? Incidental 1F11 code designed to be reusable? Average 3F12 conversion and installation included in the design?

Average 3F13 system designed for multiple installations in different orgs? No

influence 0F14 application designed to facilitate change and ease of use? No

influence 0 = 32

3- Calculate FP

FP = count-total [0.65 + 0.01 Fi ]

= 494 [0.65 + 0.01 32 ] = 479.18

4- Multiply by Historical

• Estimated FP 479.18• averages proportional to avg 479.18/623 =

0.77effort 33 months 0.77 = 25.4cost $361 thou 0.77 =$278,000documentation 1194 pages 0.77 = 918 pp.errors 201 0.77 = 155defects 52 0.77 = 40people 4 0.77 = 3 people

Scheduling

• “Coding is 90% finished half of the coding time”• “Debugging is 99% complete most of the time”• MILESTONES: concrete eventsstudies of government projectsestimates carefully updated every 2 weeks before activity

starts rarely changeduring activity, overestimates dropunderestimates don’t change until into activity

Control

• When delay is first noticed,the tendency is to not report it

• STATUS INFORMATION

what is going on• ACTION INFORMATION

learning this causes something to be done

• KEY: know when which case applies

Summary

• Estimation of duration & cost key to sound project decision making

• Estimating software development very difficult– Can improve by

• Keeping records• Using productivity-enhancing methods• Use more off-the-shelf software

– Estimation methods can become accurate if systematically applied