Chapter 7: Estimation

project planning - what to doproject control make sure it’s done right

estimation 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 mechanismseach project is unique

Set objectives and Requirements

– Project objectives are set early– Determine requirements– Statement of Work, which contain product

description, constraints, schedule requirements, budget limit, and roles of project participants. See figure 7.1 for example of SOW

SOWIs a formal document that captures and defines the work activities, deliverables, and

timeline a vendor must execute in performance of specified work for a client Areas that are typically addressed by a SOW are as follows:• Purpose: Why are we doing this project? • Scope of Work: This describes roughly the work to be done in detail.• Work: This describes where the work is to be performed. • Period of Performance: such as start and finish time, number of hours• Deliverables Schedule: This part lists the specific deliverables, describing what is due

and when.• Applicable Standards: This describes any industry specific standards that need to be

adhered to in fulfilling the contract.• Acceptance Criteria: This specifies how the buyer or receiver of goods will determine

if the product or service is acceptable.• Special Requirements: This specifies any special hardware or software, requirements.• Type of Contract/Payment Schedule.• Miscellaneous: There are many items that do not form part of the main negotiations

but are nonetheless very important to the project.

Identify Specific work to be Done

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

.”Running a project without a WBS is like going to a strange land without a roadmap”

• How Do you eat an elephant?

– Just One slice at a time……

Work Breakdown Structure is a deliverable oriented decomposition of a project into smaller components.

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

needs do ingP A C K A G E

lib raryT A 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

WBS example

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, summary of work to be done is the work Package.

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( for Tasks)• A Work Package is a deliverable or work component at the lowest level of its

WBS branch. • Is the basic building block of a work breakdown structure. It can be considered

as a sub-project. It is composed of one or several tasks. • Is a subset of a project that can be assigned to a specific party for execution. • It is the lowest level of the WBS where both the cost and the duration can be

reliably estimated. • chunk of required work• relatively small cost and short duration• includes

– 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

How is a Work Package Organized?

• A work package is not a separate function or data object in the Project System. You can create a work package according to your needs using a WBS element or an activity. Work packages can be on any level in the work breakdown structure and are characterized by:

• Start and finish dates• Texts describing the work to be performed• Responsible cost centers• Cost centers carrying out the project• related tasks without definable end results (overhead

& management; inspection; maintenance) should be included as task-oriented work packages for COST purposes

Plan 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

Develop the Schedule

• 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

quotes• Work expands to fill the time available for its completion - Parkinson's law

• The key is not to prioritize what's on your schedule, but to schedule your priorities.

• The only reason I'm coming out here tomorrow is the schedule says I have to..

• If you don’t plan, it doesn’t work. If you do plan, it doesn’t work either. Why plan!

• The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.

Develop 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

Control Points

• Includes – milestones, at completion of sub component or phase, to

keep each element of the organization informed of what is going on.

– checkpoint reviews, held at the conclusion of each phase to determine whether or not to proceed with the rest of the project.

– status review meetings, gather cost , quality, and schedule information.

– staff meetings, regularly held to maintain communication.

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

Tips for estimating

• Avoid the entire project estimation trap, you can not estimate the project with any degree of accuracy.

• The schedule is the one way the project will not proceed.• Use date range estimate, “ well based on the 3 minutes if

information you’ve told me about the project. It looks like we could deliver something in Q2 of next year”.

• Remember that an estimate is an approximation- a guess. The bigger the guess the more error you will have

• Many software people are optimistic.• Tasks they take longer that you think they will

Tips for estimating

• It is easier to estimate smaller chunk of work.• If you have given a project deadline, you do need to

estimate anything al all.• Timebox phases (build the system by feature) if you

have an over constrained project.• Estimating with multitasking. You don’t. you can’t.

don’t even try it. In multitasking you guarantee that your project will be late.

• Estimating using inch-pebbles (one to two days tasks that either done or not done) wherever possible.

Programming Products (scale of

project size) • Program, A program is what we all have developed. It's simple piece

of software that is useful to the programmer and/to some set of users who are directly involved in defining its requirements.

• Programming System, are programs intended to be reused as parts of larger systems. It is a code usable by anyone

• Programming Product, In theory, all commercial applications and mature bespoke (custom-made) applications are programming products. It is a code that tested, documented, maintained, ready to be marketed.

• Programming System Product, It has all the behavior of both a programming product and a programming system. It is useful to a wide range of users and can be effectively extended and/or embedded for the creation of larger systems. It involved a continual effort of development team over time. Microsoft office suite and Microsoft Project.

Scale of project size effort

causes of project failureAccording to Brooks

• First, techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.

• Second, estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

• Third, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.

• Fourth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like putting off a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.

• Fifth, Scheduling tendency to assume all will go well

impact of adding people

• partitionable project– Independent activities, adding more people will help but not at a

proportional rate.

• non-partitionable project– Activities are inter-related and need to be coordinated, no benefit

at all from adding people, this is true for most of IS project.

• complex interactions - must 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

• The concept of surgical team was proposed.• A surgical team assigned to specific system

task, and should not consist of more than 10 people.

Estimate types

• Ballpark or order of magnitude: Here the estimate is probably an order of magnitude from the final figure. Ideally, it would fall within two or three times the actual value.

• Rough estimates: Here the estimate is closer to the actual value. Ideally it will be about 50% to 100% off the actual value.

• Fair estimates: This is a very good estimate. Ideally it will be about 25% to 50% off the actual value.

• Budget estimate, Early in the planning phase, top down estimate, -10 percent to + 25percent.

• Definitive estimate, late in the planning phase (?) , bottom up estimate, -5 percent to +10 percent.

Software Estimation Methods

• Estimated cost Software estimation is very difficult.• The of one real software project was reported to vary by

almost 800% using 12 different software estimation models • duration is exponential (bigger jobs take more than

proportionally longer)– analogous to run 100 meters, running 1 kilometer.

• 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

Quotes….

• Failure is not an option.

• As always, victory finds a hundred fathers but defeat is always an orphan.

• Sweat plus sacrifice equals success.

• A life without mistakes is a mistake within itself.

• To give anything less than your best is to sacrifice the gift.

Source lines of code (SLOC)

• SLOC is a software metric used to measure the size of a software program by counting the number of lines in the text of the program's source code.

• SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or maintainability once the software is produced.

• There are two major types of SLOC measures: physical and logical.

Disadvantages of SLOC

• SLOC is particularly ineffective at comparing programs written in different languages unless adjustment factors are applied to normalize languages, also skilled developers may be able to develop the same functionality with far less code,

Line of Code Operation

Avg Effort/month

Budget/ 1000

Doc/ page

Errors Defect People

LOC 20,543

33 361 1,194 201 52 4

KLOC 1.606 15,673 58,122 9.784 2.531 0.195

Albrecht’s Function Point Analysis Method

This is a top-down method that was devised by Allan Albrecht when he worked for IBM. Albrecht was investigating programming productivity and needed some way to quantify the functional size of programs independently of the programming languages in which they had been coded. He developed the idea of function points 

Function Point Analysis has been proven as a reliable method for measuring the size of computer software

AIMS– consistent measure– meaningful to end user

• function points should be easier to understand than lines of code– rules easy to apply– Can estimate based on requirements specification– independent of technology used

Albrecht’s System

• count – External user inputs– External outputs– Logical internal file– External interface file types– External inquiry types

• 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 complexity1-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 COMPLEXexternal 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 Adjustment

14 general application characteristicsdata communications on-line update distributed functions

processing performance re-usabilityheavily used configuration installation ease transaction rate

operational ease on-line data entry multiple sitesend user efficiency facilitate change

not present = 0 average influence = 3insignificant influence = 1 significant influence = 4moderate influence = 2 strong influence = 5TCA = 0.65+(0.01x(total degree of influence))Estimate effort = Total * TCA.

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

Most Entities in the system are going to have at least 5 transactions: Create, Read, Update, Delete, and List (CRUDL)

logical transaction = – unique input/process/output combination triggered by

unique event of interest to the user– or need to retrieve information

• create a customer• read• update an account• delete• List, produce monthly summary report

unadjusted function pointsUFPs = 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 adjustmentAlbrecht’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

industry 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

Constructive Cost Model (COCOMOs)

• Is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity

• The model uses a basic formula with parameters that are derived from historical project data and current as well as future project characteristics.

• References to this model typically call it COCOMO 81. In 1995 COCOMO II was developed and finally published in 2000 in the book Software Cost Estimation with COCOMO II.

• COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern software development projects. It provides more support for modern software development processes and an updated project database. The need for the new model came as software development technology moved from mainframe and overnight batch processing to desktop development, code reusability, and the use of off-the-shelf software components.

Constructive Cost Model (COCOMOs)

• Computes software development effort based on program size.• COCOMO formulas: - small simple software project build by small team person months = 2.4 * KLOC**1.05 = E Duration (months) = 2.5 * E** 0.38 - Intermediate software project size and complexity, build by team with mixed

experience person months = 3.0 * KLOC**1.12 = E Duration (months) = 2.5 * E** 0.35 - Software project build under rigid conditions person months = 3.6 * KLOC**1.2 = E Duration (months) = 2.5 * E** 0.32

Quotes….

• Success is not the key to happiness. Happiness is the key to success. If you love what you are doing, you will be successful

• If you are going to do something, do it right or do not do it at all.

• Failing to prepare is preparing to fail.

• The sin is not falling down, but staying down.

•  I haven’t failed; I’ve found ten thousand ways that don’t work.

• Success is not the destination, it’s the journey.

• Experience is the name that everyone gives to his mistakes.

Quotes…..

• He who never fell never climbed

• Failures are divided into two classes: those who thought and never did, and those who did and never thought.

• On Negotiating Never allow a person to tell you no who doesn't have the power to say yes.

• On Teamwork If you always blame others for your mistakes, you will never improve.

Estimation Example

SLOCFunction Point

Source Lines of Code

• NEED DATABASE of past experienceAVERAGES effort 33 months

cost $361 (thousand)documentation 1194 pageserrors 201defects 52people 4KLOC 20.543

Implementing LOC

• Estimate structured lines of code 10,000• averages proportional to LOC 10/20.543 = 0.487

effort 33 months 0.487 = 16cost $361 thou 0.487 =$177,000documentation1194 pages 0.487 = 581 pp.errors 201 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

product36 user inputs 36 3 + __ 4 + __ 6 = 1085 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 = 21

TOTAL 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.77

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

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