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
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
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
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.
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
The failure to produce reliable software to handle baggage at the new Denver airport is costing the city $1.1 million per day
An interview assignment in a Software Project Management course revealed that none of 15 inquired project managers had any formal and/or defined (i.e. parametric, algorithmic etc.) approach for estimating effort required in software development.
This thesis elucidates the Constructive Cost Model (COCOMO) II that addresses some commonly reoccurring reasons for inaccurate estimations. An investigation conducted on 115 different organizations revealed that many companies have moderately or very unsatisfactory estimates due to the undermentioned causes extracted from Pfleeger (2001:99). Most of them are issues dealt with by the model under investigation in this case study.
Source lines of code (SLOC), also known as lines of code (LOC), is a software metric used to measure the size of acomputer 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 maintainabilityonce the software is produced.