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 )

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 =
Interfaces =
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
Don’t 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 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

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

21. See generally “Death March” by Yourdon
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
don’t 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
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 company’s 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 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

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?