Project Estimation

1
Project Estimation
2
Project Estimation

• Guesstimating
• Delphi Technique
• Involves multiple, anonymous experts
• Each expert makes an estimate
• Estimates compared
• If close, can be averaged
• Else do another iteration until consensus is
  reached

3
Project Estimation Techniques

• Top-Down Estimating
• Estimate for the whole project and then break
  down
• Often estimate in terms of what a project should
  cost and how long it should take as decreed by a
  member of top management who thinks those
  parameters are appropriate.
• May be a response to the business environment
• May lead to a death march project.

4
Project Estimation Techniques

• Bottom-Up Estimating
• Most common form of project estimation
• Divide project into small modules and directly
  estimate time and effort in person-hours, weeks,
  or months for each module.
• Analogous estimating based on similarity between
  current projects and others.
• Estimates a function of activity and the
  duration is dependent on
• complexity of module
• structure of module
• resources and support assigned to module

5
Project Estimation Techniques

• Heuristics
• Rules of thumb approach to estimating
• Require a predictable percentage of the overall
  effort
• 30 planning
• 20 coding
• 25 component testing
• 25 system testing
• Estimating Software Costs -Capers

6
Empirical Estimation Models
General form
exponent
effort tuning coefficient size
usually derived
empirically
as person-months
derived
of effort required
usually LOC but
may also be
function point
either a constant or
a number derived based
on complexity of project
7
COCOMO COnstructive COst MOdel

• Developed at TRW, a US defense contractor
• Based on a cost database of more than 60
  different projects
• Exists in three stages
• Basic - Gives a 'ball-park' estimate based on
  product attributes
• Intermediate - modifies basic estimate using
  project and process attributes
• Advanced - Estimates project phases and parts
  separately

8
COCOMO MOdel

• Project Types
• Organic mode small teams, familiar environment,
  well-understood applications, no difficult
  non-functional requirements (EASY)
• Semi-detached mode Project team may have
  experience mixture, system may have more
  significant non-functional constraints,
  organization may have less familiarity with
  application (HARDER)
• Embedded Hardware/software systems, tight
  constraints, unusual for team to have deep
  application experience (HARD)

9
COCOMO MOdel

• Basic Formulas
• Organic Person-Months 2.4 x (KDSI)1.05
• Semi-detached Person-Months 3.0 x KDSI1.12
• Embedded Person Months 3. 6 x KDSI1.20
• KDSI thousands of delivered source
  instructions, i.e. LOC

10
COCOMO Examples

• Organic mode project, 32KLOC
• PM 2.4 (32) 1.05 91 person months
• TDEV 2.5 (91) 0.38 14 months
• N 91/15 6.5 people
• Embedded mode project, 128KLOC
• PM 3.6 (128)1.2 1216 person-months
• TDEV 2.5 (1216)0.32 24 months
• N 1216/24 51

11
COCOMO MOdel

• Duration Formulas
• Organic TDEV2.5(MM)0.38
• Semidetached TDEV2.5(MM)0.35
• Embeded TDEV2.5(MM)0.32

12
COCOMO MOdel

• Intermediate Formulas
• Organic
• PM 3.2 x (KDSI)1.05 EAF
• Semi-detached
• PM 3.0 x KDSI1.12 EAF
• Embedded
• PM 2.8 x KDSI1.20 EAF
• EAF Effort Adjustment Factor

13
Cost Driver Attributes

• Personnel attributes
• Analyst capability
• Virtual machine experience
• Programmer capability
• Programming language experience
• Application experience
• Product attributes
• Reliability requirement
• Database size
• Product complexity

14
Cost Driver Attributes

• Computer attributes
• Execution time constraints
• Storage constraints
• Virtual machine volatility
• Computer turnaround time
• Project attributes
• Modern programming practices
• Software tools
• Required development schedule

15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
COCOMO II

• COCOMO II recognizes different approaches to
  software development such as prototyping,
  development by component composition, use of
  4GLs, etc.
• Levels are associated with activities in the
  software process so that initial estimates may be
  made early in the process with more detailed
  estimating carried out after the system
  architecture has been defined.

21
The Early Prototyping Level

• Size estimates are based on object points and a
  simple size/productivity formula is used to
  estimate the effort required.
• This level supports software developed by
  composing existing components.

22
The Early Prototyping Level

• Formula
• PM (NOP x (1 - reuse/100))/PROD
• PM person-months
• NOP New Object Point
• reuse the percentage of reuse that is expected
• PROD productivity

23
The Early Design Level

• Size estimates are based on FP and multipliers
• This estimate refers to the code that is
  implemented manually rather than generated or
  reused.
• Formula
• Effort A x SizeB x M
• A 2.5
• B 1.01 0.01 Wi
• M PERS x RCPX x RUSE x PDIF x PREX x FCIL x
  SCED

M
24
The Early Design Level

• Automatically Translated Code
• Formula
• Effort A x SizeB x M Pmauto
• Pmauto (ASLOC x (AT/100))/ATPROD
• ASLOC Amount of software to be adapted
• AT of the code that is reengineered by
  automatic translation
• ATPROD 24000

25
Rating Scheme for The COCOMO 2 Scale Factors

26
Exponent Computation

• Precedentedness
• similar to several previous developed projects
• Development Flexibility
• need for software conformance with
  pre-established requirements,
• need for software conformance with external
  interface specification

27
Exponent Computation

• Architecture/Risk Resolution
• Risk management plan identifies all critical risk
  item
• Schedule budget compatible with risk management
  plan
• of development schedule devoted to establishing
  architecture
• of required top software architects available
  to project
• Tool support
• Number of risk items

28
Exponent Computation

• Team Cohesion
• Consistency of stakeholder objectives
• Ability, willingness of stakeholders to
  accommodate other stakeholders objectives
• Experience of stakeholders in operating as a team
• Stakeholder team building to achieve shared
  vision and commitments
• Process Maturity
• 5 levels of CMM

29
The Early Design Level -7 Multipliers

• PERS Personal Capability
• RCPX Reliability and Complexity
• RUSE Reuse Required
• PDIF Platform Difficulty
• PREX Personal Experience
• FCIL Support Facilities
• SCED Schedule

30
The Post-architecture Level

• The estimates are based on the same basic formula
  that is used in the early design estimates.
• This stage uses a more extensive set of
  multipliers.
• Formula
• Effort A x SizeB x ESLOC x M Pmauto
• ESLOC ASLOC x (AASU0.4DM0.3CM0.3IM)/100
• ESLOC Equivalent number of new instructions

31
ESLOC

• ASLOC Amount of software to be adapted
• AA The assessment and assimilation increment
• Determine whether a reused software module is
  appropriate to the application, and to integrate
  its description into the overall product
  description
• SU The software understanding increment
• Software is structured and clear, self
  descriptiveness
• DM The percentage of design modification
• CM The percentage of code modification
• IM The percentage of the original integration
  effort required for integrating the reused
  software.

32
The Post-architecture Level- 17 Multipliers

• RELY Required Software Reliability
• DATA Data Base Size
• CPLX Product Complexity
• RUSE Required Reusable
• DOCU Documentation match to life-cycle needs
• TIME Execution Time Constraint
• STOR Main Storage Constraint
• PVOL Platform Volatility
• ACAP Analyst Capability

33
The Post-architecture Level- 17 Multipliers

• PCAP Programmer Capability
• AEXP Applications Experience
• PEXP Platform Experience
• LTEX Language and Tool Experience
• PCON Personnel Continuity
• TOOL Use of Software Tools
• SITE Multisite Development
• SCED Required Development Schedule

34
Development Schedule Estimates

• Initial baseline schedule equation for all 3
  COCOMO II
• TDEV3.0x(PM)(0.330.2x(B-1.01)xSCED/100
• SCED cost driver rating

35
What Is the Best Way to Estimate IT Projects?

• Use more than one technique for estimating
• If estimates from different techniques close,
  average them
• Adjust estimate based on experience
• Negotiation may lead to unrealistic estimations