Estimating project size, effort and schedule

Software estimation is difficult

Software development is a process of gradual refinement.

• Unfortunately at the beginning only a fuzzy picture exists of what you want to build

• As with building anything options exist: – gold plated or value priced

• As the project clarifies the picture it is possible to clarify the estimate of the amount of effort necessary

• The estimate can only come into focus as the requirements for the software come into focus. – when is this?

Obviously: You can only estimate the cost and time required to build a house if you know the specific customer requirements

Software development as a process of refinement

What contributes to estimation uncertainty

• Is feature X required?– with what priority?

• What variety of feature X? Cheap or expensive (x 10)

• Will it need to be enhanced? If you later want an expensive version than this will affect the design (x 10 in design)

• Quality level of the feature (x 10 in design)

• Debugging the feature (x 10 caused by inferior design or hurried development)

Important points about estimates

• Estimates should converge over time– G & Y recommends estimates from different viewpoints

• present estimates as ranges

• communicate that as the product requirements and design come into focus so will the estimates

• schedule ranges assume that you created a schedule by first creating an effort estimate and then computing the schedule

Estimation vs. Control

Options

• Bend schedule and costs to meet features

• Meet halfway

• Bend to the discipline of a fixed time and $$ budget

Customers want and appreciate information ?

• Try your best to explain the sources of uncertainty

• Give the customer what information you can and the rationale for your estimates– never be afraid to ask for time to prepare an estimate when asked!

• Explain that further estimates will come with the refinement process

• Try to explain the necessity of tradeoffs– Internal vs. External costs

Estimation Process

• Estimate the size of the product. The number of lines of code or function points

• Estimate the effort (person-months)

• Estimate the schedule (calendar-months): shortest possible, efficient, and nominal. Depend on complexity and personnel

Provide estimates in ranges and refine the estimates to provide increasing precision as the project progresses

Source Code Metric Example

Activity AssemblerVersion

Fortran Version Difference

Requirements 2 Months 2 Months 0

Design 3 Months 3 Months 0

Coding 10 Months 3 Months -7

Integration/Test 5 Months 3 Months -2

UserDocumentation

2 Months 2 Months 0

Management/Support

3 Months 2 Months -1

Total 25 Months 15 Months -10

Total Costs $125,000 $75,000 -$50,000

Cost/Source Line $12.50 $25.00 +$12.50

Lines/PersonMonth

400 200 -200

• What other tradeoffs might be attached to such an estimate?

Size Estimation: Function Point Estimation

Size: Function points, lines of code, % difference from another project

• function points depend on – inputs - screens, forms, dialog boxes, etc.

– outputs - reports, graphs. etc

– inquiries - actual query as opposed to an input or output

– logical internal files - major logical groups of end-user data or control information

– external files - files controlled by other programs with which the program must interact

• Good simple reference: Schach, Classical and Object-Oriented Software Engineering, Fourth Edition (pps 262-270)

Revised Function Point Metric

• Measure “functionality” of software– what is that and why would we like to measure it?

• External aspects of software:

Simple Average Complex

– Inputs = 3 4 6

– Outputs = 4 5 7

– Inquiries = 3 4 6

– Data Files = 7 10 15

– Interfaces = 5 7 10

• Typically adjust for complexity based on organizations experience– technical complexity factor (multiplier)

• Use tables or empirical functions for estimating effort in person months. NEEDS TO BE TAILORED TO YOUR ORGANIZATION.

Function Point Metric Example

Activity AssemblerVersion

Fortran Version Difference

Requirements 2 Months 2 Months 0

Design 3 Months 3 Months 0

Coding 10 Months 3 Months -7

Integration/Test 5 Months 3 Months -2

UserDocumentation

2 Months 2 Months 0

Management/Support

3 Months 2 Months -1

Total 25 Months 15 Months -10

Total Costs $125,000 $75,000 -$50,000

Cost/F.P. $4,166.67 $2,500.00 -1,666.67

F.P./PersonMonth

1.2 2.0 +.08

What is Language Level?

• As language level increases, fewer statements to code one Function point are required.

• Levels provide a way to convert size from one language to another.

– 1000 statements in COBOL (level 3)

– 500 statements in NATURAL (level 6)

– 250 statements in OBJECTIVE C (level 12)

Language Level Relationship to Productivity

Language Level Productivity Average per StaffMonth (Function Points)

1 – 3 5 to 10

4 – 8 10 to 20

9 – 15 16 to 23

16 – 23 15 to 30

24 – 55 30 to 50

Above 55 40 to 100

Language Levels and Productivity

• Relationship between level of language and development productivity is not linear.– What is the tradeoff to use of higher level languages?

• do we lose anything?

– Is there a limit to the “height” of a higher level language?• what is at the “top”

• Coding amounts to 30% of the effort for large software projects.– Is this the only thing really implicated by use of higher level languages?

Languages and Levels

Language Level Average SourceStatement/F.S.

Ada 95 6.50 49Assembly (Basic) 1.00 320C 2.50 128C++ 6.00 53COBOL 3.00 107HTML 3.0 22.00 15JAVA 6.00 53LISP 5.00 64Oracle Developer/2000 14.00 23PASCAL 3.50 91PERL 15.00 21PL/I 14.00 80Qbasic 5.50 58SQL 25.00 13UNIX Shell Scripts 15.00 21Visual C++ 9.50 34

Why function points and language levels?

• Ability to size a project

• Ascertain Function Points of software conveniently

• Ability to convert the size of applications in different languages

• Measure productivity of projects in multiple languages

Again, what other tradeoffs are part and parcel of such analysis?

Tips and traps of effort and schedule estimation:

• Avoid off the cuff estimates– Courage to take some time to support integrity of the estimate

• Estimate with as much data and from as many viewpoints as possible

• Don’t forget common tasks

• Refine approach as the project progresses– assign and enforce responsibility for someone in the organization

Facts of Life : Shortest schedules

• There is a shortest possible schedule and you can’t beat it– trying to will only lead to a longer schedule than you would have had

otherwise

– remember Brooks Law

• Assumes that everything is done right– top 10% of experienced developers

– detailed knowledge of application area

– very familiar with a good environment, latest tools

– project is using fundamental software engineering principals effectively

Facts of Life : Efficient schedules

• Do most things right– top 25% of developers

– familiar with a good environment

– project is using fundamental SWE principals effectively

• Costs increase significantly when you shorten the schedule below efficient

• Compression factor = desired schedule / initial schedule Compressed schedule effort = initial effort / schedule compression factor

– it is not possible to go below .75 or .80

Facts of Life : Nominal schedules

• Average projects, these should be used most of the time– top 50% of developers

– good environment

– some experience in application area

– project is using fundamental SWE principals effectively

• Costs increase significantly when you shorten the schedule below nominal

Estimate refinement

• Can’t refine estimates in a vacuum– necessary to have refined level of software requirements

– thus you need to begin the requirements phase of the project

• Standard mistake: Make a point estimate early in the project AND be held accountable for it!

• Recalibration if there is a slip in an early phase– make up lost time

– add the time slipped

– multiply by the slip factor

• Can change product, cost, or schedule

Reality

• Problem: Being forced to work to unrealistic schedules

• Goal: Get realistic projects accepted

• Overly optimistic schedules are the rule not the exception– Winword

• Why are they so prevalent– beat competition, win a bid, look good

– Belief that high standards produce exceptional results

– feature creep

– bad estimation, inexperience

• See generally “Death March” by Yourdon

Effects of an overly optimistic schedule

Has a negative impact on

• quality of project planning (100% schedule overruns), customer relationship, credibility

• not enough time spent on requirements and design– more rework and errors

• too much time figuring on how to meet the schedule; premature attempt to converge -- at all phases of the project

• quality --- more errors

• gambling -- unproven tools

• motivation– give up

– not conducive to creativity

• turnover

Beating schedule pressure

• Realistic thinking

• Explaining impact - the software estimation story

• Negotiate effectively

• Note Gause and Weinberg on this topic– Also See, Getting to Yes by Fisher and Ury

Principled negotiation

• Separate the people from the problem

• Focus on interests not positions

• Invent options for mutual gain

• Use objective criteria– don’t negotiate the estimates but the inputs (assumptions)

• resources

• features

– process (features before estimate)• rational procedure

• SW tool

• outside expert

No Silver Bullet: Essence and Accident in Software Engineering

There is no single development, in either technology or management technique, which by itself promises even one

order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity

1987 IEEE Computer

The monster

• Missed schedules

• Blown budgets

• Flawed products

The first step towards a cure is the understanding the disease process

Essential Difficulties

The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocation of functions

• Complexity: A scaling up of a software entity is necessarily an increase in the number of different elements

• Conformity: Software must conform to arbitrary systems

• Changeability: Software can be changed and people want to extend beyond its original design

• Invisibility: Software has no inherent representation

These have both technical and managerial implications

Past breakthroughs that solved accidental difficulties

• High level languages

• Faster machines/environments

• Unified programming environments

Hopes for a silver bullet: 1987

• ADA

• Object oriented programming

• Artificial Intelligence

• Expert Systems

• Automatic programming; Graphical programming

• Program verification

• Environments

• Workstations

Attacks on the Conceptual Essence (Brooks)

• Buy vs. build

• Requirements refinement and rapid prototyping

• Incremental development

• Great designers

NSB revisited - 1995

• So what has happened in 10 years - perhaps an order of magnitude improvement in some areas but certainly not all. The crises continues.

• Buy vs. build -- a huge growth in customizable software (Excel)

• Object oriented programming– high expectations but little impact

– higher level of abstraction - design patterns?

• Reuse– very much used BUT

– large vocabularies e.g. Java libraries

Bottom line: Software development remains difficult !!!!

Note: David Harel wrote “Biting the Silver Bullet” in response to Brooks.Visual, hierarchical, functional modeling attacks essence...can execute and test!

Five levels

• Initial: ad hoc, success based on individual talent and effort

• Repeatable: Track cost, schedule, functionality -- Can repeat earlier success through mimicry

• Defined: A standard process is available that can be tailored to each project’s individual needs

• Managed: Detailed measures of the software process are tracked and product quality data is collected. The process is controlled by using the collected data.

• Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies

Determining the Maturity Level: Can you map answers to these questions to a maturity level?

• How does your company track the costs and schedule of software projects

• Is this information used in planning new projects? How? Are the results consistent from project to project?

• As a new employee how would I learn about how software projects are planned and managed?

• During the project, how do you track how the project is doing? Is that data ever used to change the project plan? How?

• What does your company do to improve the quality of the software it produces?

• Do you try new approaches? How do you judge if they are successful?