Estimating project size, effort and schedule

1
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

2
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)

3
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

4
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

5
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

6
Source Code Metric Example
7

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

8
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)

9
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.

10
Function Point Metric Example
11
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)

12
Language Level Relationship to Productivity
13
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?

14
Languages and Levels
15
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?

16
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
• Dont forget common tasks
• Refine approach as the project progresses
• assign and enforce responsibility for someone in
  the organization

17
Facts of Life Shortest schedules

• There is a shortest possible schedule and you
  cant 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

18
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

19
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

20
Estimate refinement

• Cant 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

21
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

22
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

23
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

24
Principled negotiation

• Separate the people from the problem
• Focus on interests not positions
• Invent options for mutual gain
• Use objective criteria
• dont negotiate the estimates but the inputs
  (assumptions)
• resources
• features
• process (features before estimate)
• rational procedure
• SW tool
• outside expert

25
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

26
The monster

• Missed schedules
• Blown budgets
• Flawed products
• The first step towards a cure is the
  understanding the disease process

27
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

28
Past breakthroughs that solved accidental
difficulties

• High level languages
• Faster machines/environments
• Unified programming environments

29
Hopes for a silver bullet 1987

• ADA
• Object oriented programming
• Artificial Intelligence
• Expert Systems
• Automatic programming Graphical programming
• Program verification
• Environments
• Workstations

30
Attacks on the Conceptual Essence (Brooks)

• Buy vs. build
• Requirements refinement and rapid prototyping
• Incremental development
• Great designers

31
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!

32
Overview of CMM

• Idea is to develop a set of stages (of maturity)
  such that each stage lays the groundwork for
  moving to the next level
• Provide guidance on how to gain control of a
  companys processes and progress through the
  stages
• Focus on a limited set of activities at each stage

33
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 projects 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

34
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?