0% found this document useful (0 votes)
36 views33 pages

Cost Estimation

The document outlines software cost estimation techniques, including empirical, heuristic, and analytical approaches. It discusses size metrics such as Lines of Code (LOC) and Function Point metrics, highlighting their advantages and limitations. Additionally, it introduces the COCOMO model for estimating software project costs, detailing its classification into organic, semidetached, and embedded categories, along with example calculations for effort and time based on project size.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
36 views33 pages

Cost Estimation

The document outlines software cost estimation techniques, including empirical, heuristic, and analytical approaches. It discusses size metrics such as Lines of Code (LOC) and Function Point metrics, highlighting their advantages and limitations. Additionally, it introduces the COCOMO model for estimating software project costs, detailing its classification into organic, semidetached, and embedded categories, along with example calculations for effort and time based on project size.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 33

Cost Estimation

Software Cost Estimation

• Three main approaches to


estimation:
–Empirical
–Heuristic
–Analytical

6
Software Cost Estimation Techniques

• Empirical techniques:
– an educated guess based on past experience.
• Heuristic techniques:
– assume that the characteristics to be estimated can
be expressed in terms of some mathematical
expression.
• Analytical techniques:
– derive the required results starting from certain
simple assumptions.

7
Software Size Metrics
• LOC (Lines of Code):
– Declarations ,Actual code including logic and
computations
– Blank lines : Include to improve readability
– Comments: Include to help in code understanding
as well as during maintenance.

12
for(i=0;i<10;i++) int a; // declaration
cout<<i; code comment

for(i=0;i<10;i++) // declaration comment


{ int a; code
cout<<i;
}
Function Point Metric
• Overcomes some of the shortcomings of the LOC
metric
• Proposed by Albrecht in early 80's
• It measures functionality from users point of view
• Focus on what functionality being developed

15
Function Point Metric
• Internal logical files
– The control information or logically related data that is present within system

• External Interface files


– The control data or other logical data (ie reference by system but present in another
system.

• External Input:
– Data/control information that comes from outside our system.

• External Output:
– Data/control information that goes out of system after generation.

• External Inquiries:
– Combination of input and output resulting

16
Function Point Metric (CONT.)

• Suffers from a major drawback:


– the size of a function is considered to be
independent of its complexity.
• Extend function point metric:
– Feature Point metric:
– considers an extra parameter:
• Algorithm Complexity.

17
Function Point Metric (CONT.)

• Proponents claim:
– FP is language independent.
– Size can be easily derived from problem
description
• Opponents claim:
– it is subjective --- Different people can come
up with different estimates for the same
problem.
18
• Step 1:
• Each function is ranked accordingly the complexity (low,
average, high)
• These are predefined weight for each FP in category

Functional unit Weighting factors ( j )


(i)
Low Average High

EI 3 4 6
EO 4 5 7
EQ 3 4 6
ILF 7 10 15
ELF 5 7 10

Table A
• Step 2:
– Calculate unadjusted functions points by multiplying each FP
by its corresponding weight factors
UFP )

Count of no of functional units of category


classified as complexity j

Weight from table A

Example : 5EI=LOW
6EO=HIGH
UFP= (5*3+6*7)
= 57
• Step 3: calculate final functional point
• Final FP = UFP* CAF

Complexity adjustment factor


calculated using 14 aspects of
processing complexity

• 14 questions answered on scale of 0 to 5


• 0= No influence
• 1=Incidental
• 2=Moderate
• 3=Average
• 4=Significant
• 5=Essential

CAF = [ 0.65 + ( 0.01 * )


COCOMO Model
• COCOMO (COnstructive COst MOdel) proposed by Boehm.
• Cocomo (Constructive Cost Model) is a regression model based on LOC,
i.e number of Lines of Code.
• It is a procedural cost estimate model for software projects and often
used as a process of reliably predicting the various parameters
associated with making a project such as size, effort, cost, time and
quality.
• It was proposed by Barry Boehm in 1970 and is based on the study of 63
projects, which make it one of the best-documented models.
• Divides software product developments into 3 categories:
– Organic
– Semidetached
– Embedded
26
• The key parameters which define the quality
of any software products, which are also an
outcome of the Cocomo are primarily Effort &
Schedule:
• Effort: Amount of labor that will be required to
complete a task. It is measured in person-months units.
• Schedule: Simply means the amount of time required
for the completion of the job, which is, of course,
proportional to the effort put. It is measured in the
units of time such as weeks, months.
COCOMO Product classes
• Roughly correspond to:
– application, utility and system programs
respectively.
• Data processing and scientific programs are
considered to be application programs.
• Compilers, linkers, editors, etc., are utility
programs.
• Operating systems and real-time system programs,
etc. are system programs.

28
COCOMO Model
• COCOMO (Constructive Cost MOdel) proposed by
Boehm.
• It is hierarchy of software cost estimation model
• It is classified into basic, Intermediate and detailed .
• Basic model :-
• Estimate cost in rough and quick manner
• Mostly used for small and medium size software.
• Three modes of development i.e. organic ,semidetached, embedded
• Organic:
» Relatively small groups
» working to develop well-understood applications.
• Semidetached:
» Project team consists of a mixture of experienced and inexperienced
staff.
• Embedded:
» The software is strongly coupled to complex hardware, or real-time
systems.
29
Organic Semidatached Embeded

Size 2-50KLOC 50-300KLOC 300 or higher

Team size Small Average Large

Developer Experience Average Very little


Experience
Environment Familiar Less familiar Significant (new
environment)

Innovation Little Medium Major

Deadline No Medium Very tight

Example Payroll system Utility system Air traffic monitoring


• Suppose that a project was estimated to be 400
KLOC .calculate effort and time each of modes of
development
1) Organic : a[KLOC]^b
Effort = 2.4(400) ^1.05
=1295 personmonth
Development time = 2.5(400) ^0.38
=24.36 month
2) Semideaatched :
Effort = 3 (400) ^1.12
=2462personmonth
Developmet time = 2.5(400) ^0.35
= 38.4 month
3) Embeded
Effort = 3.6 (400) ^1.2
=4772personmonth
Developmet time = 2.5(400) ^0.32
= 38.4 month
Complete COCOMO Example

• A Management Information System (MIS) for an


organization having offices at several places across
the country:
– Database part (semi-detached)
– Graphical User Interface (GUI) part (organic)
– Communication part (embedded)
• Costs of the components are estimated separately:
– summed up to give the overall cost of the system.

33

You might also like