Андрій Татчин "Software Project Estimation: Theory and Reality"

1. Software Project
Estimation
Theory and Reality
Andriy Tatchyn
General Manager at LaSoft

2. Table of content
• Introduction to estimation and estimation issues
• A theory of estimation
• Case Studies and real world examples

3. Failure Record
• Every year only United States spend nearly $250 billion on IT
applications. Each year approximately 175, 000 projects are built.
Many of those are fail.
• The Standish Group research shows a staggering 31.1% of projects
that were cancelled before they ever got completed. Further results
indicate 52.7% of projects will cost 189% of their original estimates.
• The cost of these failures and overruns are just the tip of the
proverbial iceberg. The lost opportunity costs are not measurable,
but could easily be in the trillions of dollars.
Source: The Standish Group Report 2014

4. “Bridges are normally built on-
time, on- budget, and do not fall
down. On the other hand,
software never comes in on-time
or on-budget. In addition, it
always breaks down.”
Alfred Spector,
President of Transarc Corporation

5. Results
Source: Software Estimation: Demystifying the Black Art by Steve McConnell

6. Barry W. Boehm (born 1935) is an
American software engineer,
Distinguished Professor of
Computer Science, Industrial and
Systems Engineering; the TRW
Professor of Software Engineering;
and Founding Director of the
Center for Systems and Software
Engineering at the University of
Southern California.
Source: Wikipedia

7. • http://csse.usc.edu/tools/COCOMOII.php

8. CoComo II
adjustment factors
In many cases you will not be able to use
Cocomo 2 because:
- The project size is not clear, and you have
no idea how many lines of code (LOC/SLOC)
the project will have.
- In most cases today we use several
programming languages and frameworks to
develop software. So Locs becoming less
universal.
- In most cases, it is recommended to use
your organizations' historical data and take
into account described Cocomo 2
adjustment factors.
Source: Software Estimation: Demystifying the Black Art by Steve McConnell

9. Hello my friend,
how long will it take
to deliver the
project?

10. This is how Business works and thinks:
Source: Software Estimation: Demystifying the Black Art by Steve McConnell

11. Distinguish between
estimates, targets, and
commitments.

12. Source: Software Estimation: Demystifying the Black Art by Steve McConnell

13. This is how real world looks like:
Source: Software Estimation: Demystifying the Black Art by Steve McConnell

14. There is no single
point estimation
• While project in a progress it
develops information that support
more accurate estimation. We have
better understanding of
requirements, design and tasks
become more detailed, plans
become more clear.
• Estimates are dynamic and should
be revised as more information
becomes available or when
requirements change.
Source: Software Estimation: Demystifying the Black Art by Steve McConnell

15. The Cone of Uncertainty
Source: Software Estimation: Demystifying the Black Art by Steve McConnell

16. Recognize a mismatch
between a project’s business
target and a project’s estimate
for what it is: valuable risk
information that the project
might not be successful.

17. Case Studies

18. How I estimate software projects
• Collect as much information about the project as possible. You will need at
least several meetings with a customer to understand his needs. Remember
about the Cone of Uncertainty. Try to kill everything that is not clear.
• Good if mockups and UI design are ready, if not start initial Product Design
Sprint creating User Stories, Mockups, and UI Design.
• I create a Work Breakdown Structure (WBS). During the initiation and
planning it helps organize task structure; double-check if something is
missing; and control project Scope on later project stages.
• Count first. We count Web pages, and functionality (User Stories) to
understand the project size.
• When a team is already known invite everyone into the estimation exercise
(works for small and medium projects). Team estimation is a very good team
building exercise; it is easier to make a commitment when you do the
estimation and it is proven that group estimations are more accurate.

19. • Budget expectations
• Schedule expectations
• Functional Requirements
• Non-functional requirements
Collect
• Mockups
• UI
• User Stories
• WBS
• Technology stack
• Database structure
• Application architecture
Design • Make sure that something you have
designed is something that is
expected by a customer.
Validate
• Functionality
• WBS items
• Web pages
• Proposal pages :)
Count • Implement a Law of large number.
• Involve Project Team.
• Multiply on your team index.
Estimate
Product Specification
Law of Large
Number
(15-20 items)
Team index
Count

20. Define your customer
needs, schedule and
budget early. Share your
thoughts openly.
(Raboph Case Study)

21. Wristo Project,
Historical data
implementation
Number of pages: 6
Effort: 435 hours
Effort per page: 72,5 hours
Cost calculation= Number of pages x 72,5 x Diseconomy of Scale Index x Hourly Rate

22. Example of Bottom Up estimation

23. Remember about Indians,
Chinese and the rest of the
world
(Manmeet story)

24. Thank You!
Questions and ideas are welcome!