Transcript 1.2.1. IFPUG function points

Software Engineering Project
Management SE603
Unit 4: Effort Estimation
Egypt, 1.6.2014
Tempus
Introduction
Estimating efforts of a project is very important
to have an overview on the number of human
resources required to be in place and the
duration span to have the project complete.
2
Introduction
To estimate the efforts, size should be
estimated first. Size calculation is done either by
counting the code lines or based on the
functions delivered to customers. Once efforts
are estimated, many factors could be
determined and adjusted such as costs,
scheduling resources and mitigating risks. In
this unit, many size calculation methods and
one effort estimation method with all different
modes are investigated.
3
Objectives
•
•
To be familiar with the concept of Project Effort
Estimation
Going through the most familiar methods for sizing
and effort estimation for software projects
4
Unit 4: List of topics
1. Size Estimation
1.1. Technical Size Estimation
1.2. Functional Size Estimation
1.2.1. IFPUG function points
1.2.2. COSMIC Function Points
2. Effort Estimation
2.1. Algorithmic Effort Estimation Techniques
2.1.1. COCOMO Model
2.1.1.1. Basic COCOMO Model
2.1.1.2. Intermediate COCOMO Model
2.1.1.2. Detailed COCOMO Model
2.2. Non-Algorithmic Estimation Techniques
2.2.1. Expert Judgment
2.2.2. Estimation by Analogy
5
Effort Estimation
In order to estimate
project efforts, step 5
of Step Wise Planning,
introduced in Unit 2, is
investigated.
Step 0 Initiation
Step 1: Defining Scope
and Objectives
Step 2: Understanding
Client infrastructure
Step 3 Project
Characteristics
Analysis
review
Lower level
detail
Step 4 Identifying
deliverables
Step 5 Effort
Estimation
For Each
activity
Step 6 Handling risks
Figure: STEP WISE Planning Steps [1]
Step 10 Low-Level
Planning
Step 7 Resources
Allocation
Step 9 Plans
Execution
Step 8 Plans Review
Effort Estimation
Step 5 aims to enable project managers
to have their hands on the methods of
determining the size of the project and
estimating the duration of implementing
the tasks. Estimating effort is a
troublesome task facing every manager
at the inception of the software
development
Figure: STEP WISE Planning Steps [1]
1. Size Estimation
In work breakdown structure (WBS)
mentioned in unit 2, we’ve highlighted that
project is broken down into various tasks
where each task is divided into its composites.
It is about building a tree of tasks where the
root: is the project itself, Level 1: is the main
composite tasks of the root, Level 2: is the
campsite tasks of all level 1 tasks, and so on till
no further breakdown @ the leave tasks.
8
1. Size Estimation
After building this tree of tasks, the size of each
task is calculated to derive the effort needed to run
the task in terms of manpower and development
time. By summing up these calculations bottom up,
we would have the tentative final estimate for
project efforts.
There are two categories of size estimation
techniques:
1. Technical size estimation
2. Functional Point estimation
9
1.1 Technical Size Estimation
It is the estimation of software size by counting
the logical lines of code (LOC). LOC could be
physical or Logical. Physical LOC are the
number of lines counted by your programming
editor, where the physical line could include
multiple logical lines. Logical lines are the
number of commands used to execute certain
operations. Multiple logical lines could be in
one physical line [2].
10
1.1 Technical Size Estimation
Physical line Example:
Logical Line Example:
for (int i=0; i<100; i++)
count (”test");
for (int i=0; i<100;i++)
{
printf(”test");
} /* comment line */
• 1 Physical code line
• 2 Logical code lines
(for & cout)
• 4 Physical code lines
• 2 Logical code lines
(for & cout)
• 1 Comment line
11
1.2. Functional Size Estimation (1/2)
Functional Size Estimation (FSE) is a function
based estimation and also known as Function
Point Analysis (FBA) that was proposed by Alan
Albrecht while working for IBM. It is about a
measure of functions delivered to the customer.
Albrecht proposed that any system is
decomposed into the following functional units
[3,4]:
There are many ISO standards to estimate size in this domain:
1. IFPUG Function Points (IFPUG FP) (ISO/IEC 20926:2009)
2. COSMIC Function Points (COSMIC FFP) (ISO/IEC 19761:2011)
12
1.2. Functional Size Estimation (1/2)
Function Unit
Description
External Inputs
information inputs the system
External Outputs Information outputs from the
system
External Enquiries Requests to retrieve information
Internal Logical
Information stored in the system
Files (ILF)
External Interface Information stored and maintained
Files (EIF)
by another systems / applications
but used in the analyzed system.
13
1.2. Functional Size Estimation (2/2)
Functional units interactions:
User can feed the system with (External Inputs) to
have a rich database of records. This database of
records are maintained internally by the system
for any future processing activities. The user could
access the system requesting to query (External
Enquiries) certain piece of information where the
system could utilize its internal records database
(ILF) or / and any other external databases
maintained by another systems (EIF) to respond
back to the user (External outputs) [5]
14
1.2. Functional Size Estimation (2/2)
15
1.2.1. IFPUG function points (1/7)
IFPUG stands for International Function Point
Users Group (ISO/IEC 20926:2009). This group
proposed a a size measurement method that
considers the 5 function units listed before [1]:
1. Number of External Inputs
2. Number of External Outputs
3. Number of External Inquiries
4. Number of Logical Internal Files
5. Number of External Interface Files
1.2.1. IFPUG function points (1/7)
In order to estimate the size:
Step 1: Function components are weighted
(Unadjusted Function Points)
Step 2: Technical complexity factor is adjusted
Step 3: Functional Point Calculation
Step 4: LOC conversion
17
1.2.1. IFPUG function points (2/7)
Step 1: Function components are weighted
Function Units [5]
External Inputs
External Outputs
External Inquiries
Logical Internal Files
External Interface Files
Weighting Factors
Low Average High
3
4
6
4
5
7
3
4
6
7
10
15
5
7
10
Function unit are weighted according to its complexity (low,
average, and high); these weights are industry standard.
18
1.2.1. IFPUG function points (3/7)
Functional Units [5]
Count
complexity
Complexit
y totals
External Inputs (EIs)
No. …….
No. …….
No. …….
Low x 3
= ….
Average x 4 = ….
High x 6
= ….
Sum of
complexity
totals for EI
External Outputs (EOs)
No. …….
No. …….
No. …….
Low x 4
= ….
Average x 5 = ….
High x 7
= ….
Sum of
complexity
totals for
EO
External Enquiries (EQs)
No. …….
No. …….
No. …….
Low x 3
= ….
Average x 4 = ….
High x 6
= ….
Sum of
complexity
totals for
EQ
19
External Logical Files
No. …….
Low x 7
Sum of
= ….
Functional
unit totals
1.2.1. IFPUG function points (4/7)
Step 2: Technical complexity factors are
adjusted
Determining complexity is always
subjective, therefore, 14 factors that
influence the system implementation are
measured to adjust the function points.
1.2.1. IFPUG function points (4/7)
1. Reliable Backup needed?
2. Data communication needed?
3. Distributed process functions available?
4. Performance critical?
5. On line data entry required?
6. Complex inputs, outputs, files, or inquiries?
7. Master files updated on line?
8. Reusable code?
9. Complex Internal processing?
1.2.1. IFPUG function points (4/7)
9. Complex Internal processing?
10. Easy Installation?
11. Easily operated?
12. Multiple installations in different sites?
13. Easy change by the user?
14. Run in utilized operational environment?
1.2.1. IFPUG function points (4/7)
23
1.2.1. IFPUG function points (5/7)
Step 3: Functional Point Calculation
Functional Point (FP) =
Technical Complexity Factor (TCF) x Unadjusted
Function Points (UFP)
Step 4: LOC conversation
LOC = FP x Programming Language LOC
Coefficient
Programming Language [6]
C++
COBOL
DELPHI
JAVA
SQL
Coefficient
60
110
20
50
24
15
1.2.1. IFPUG function points (6/7)
Example:
What are the function points of the project with
the following specifications:
Number of inputs =10
Number of outputs =20
Number of enquiries =30
Number of internal files = 10
Number of external interface files = 3
Assuming all complexity factors with high
influence degree and convert the function
points to LOC consider the language is c++.
25
1.2.1. IFPUG function points (6/7)
Solution:
UFP =10x6 + 20x7 + 30x6 + 10x15 + 3x10 = 560
CAF = (0.65 + 0.01 Σfi) = (0.65 + 0.01 (14 x 4)) =
0.65 + 0.56 = 1.21
FP = UFP x CAF = 560 x 1.21 = 677.6
LOC = FP x C++ Coefficient = 40,656
26
1.2.1. IFPUG function points (7/7)
Example:
Compute the function point for the following project
10 external inputs with average complexity
12 external outputs with low complexity
20 internal logical files with high complexity
15 external interface files with high complexity
12 external inquiries with low complexity
Half of the complexity factors with high influence
degree and the other half with strong influence
degree.
27
1.2.1. IFPUG function points (7/7)
Solution:
UFP = 10 x 4 + 12 x 4 + 20 x 6 + 15x15 + 12 x 5 =
493
CAF = (0.65 + 0.01 (7 x 4 + 7 x 5 )) = (0.65 + 0.01
(63)) = 1.28
FP = UFP x CAF = 493 x 1.28 = 631.04
28
Example Compute the function points for the following project
External Inputs:
10 with low complexity
15 with average complexity
17 with high complexity
External Outputs:
6 with low complexity
13 with high complexity
3 with low complexity
4 with average complexity
2 high complexity
Internal logical files:
2 with average complexity
1 with high complexity
External Interface files:
9 with low complexity
In addition, system requires
1. Significant data communication
2. Performance is very critical
3. Designed code may be moderately
reusable
4. System not designed for multiple
installation in different sites.
5. Other complexity adjustment factors
are treated as average.
29
1.2.3. COSMIC Function Points (1/2)
COSMIC stands for Common Software Measurement International Consortium
(ISO/IEC 19761:2011).
COSMIC is used to size software projects that are dominated by functions that input,
store, retrieve and output data such as business applications, real-time software and
operating systems. However it is not used to size software dominated by functions
that manipulate data such as scientific and engineering software.
COSMIC measures the whole software, its components or sub-components. The
functional user requirements for a piece of software are considered as subprocesses. The sub-process is either data movement or data manipulation. Four
types of data movement in COSMIC [7]
1. Entry
2. Exit
The COSMIC Function Points = Sum of total number of data movements (Entries,
Exits, Reads and Writes)
3. Writes
4. Reads
Then COSMIC function points are converted to LOC as in the previous slide
32
1.2.3. COSMIC Function Points (2/2)
Example:
A project with the following parameters, compute the function points
100 of Entry data movements
10 of Exit data movements
200 of Write data movements
400 of Read data movements
And convert the function point into LOC consider the language is JAVA.
Solution:
FP = 100 + 10 + 200 + 400 = 710
LOC = FP x JAVA# coefficient = 710 x 50 = 35,500
33
2. Effort Estimation
Effort is measured in terms of persons-month and
development time. According to the effort data, the
manager could balance load, squeeze
implementation time or assign more resources.
For example if an effort requires 10 man-month
could be: 10 people in 1 month / 1 person in 10
months / 2 people in 5 months.
Once the size is calculated, Effort is estimated.
Effort Estimation techniques are grouped into two
categories: algorithmic and non-algorithmic
estimation techniques.
2. Effort Estimation
Project
Size
LOC
Estimation
Effort
Estimation
Efforts (person-months)
Development time (months)
Average staff size in persons
Productivity in KLOC / Person-Months
1.
2.
3.
4.
Algorithmic Estimation
techniques
COCOMO
Use-Case Points
Class Points
UML Points
Non-Algorithmic
estimation techniques
1. Expert judgment
2. Estimation by analogy
36
2.1. Algorithmic Effort Estimation
Techniques
These techniques are based on mathematical
models .Effort is measured according to many
factors such as Product Attributes, Hardware
Attributes, Personal Attributes and Project
Attributes besides the project size.
37
2.1.1. COCOMO Model
COCOMO stands for Constructive Costing Model
proposed by Berry W. Boehm in 1981 [8]. COCOMO
has three forms: basic, intermediate and detailed
running in three different modes: organic, semidetached and embedded as shown in the following
table [5, 11].
38
2.1.1. COCOMO Model
Mode
Projec Nature of Project
t size
Innovation
Project
Development
Deadline Environment
Organic
2-50
KLOC
Small size project
Small size team with high
experience on similar projects.
Ex: pay roll / inventory projects /
etc.
Little
Not tight
In house
Semi
Detache
d
50300
KLOC
Medium size project
Medium size team with Average
previous experience on similar
projects.
Ex: Utility systems as compilers,
database systems / etc.
Medium
With tight
constraints
and change
to the
system are
costly
Medium
Medium
Embedd
ed
>300
KLOC
Large project (Real time systems, Significant
Complex interfaces)
Very little previous experience.
Ex: ATMs, Air Traffic Control etc.
Tight
Complex
Hardware/
customer
39
Interfaces
required
2.1.1. BASIC COCOMO Model (1/7)
The basic COCOMO model estimates
software costs with poor accuracy as it
doesn’t account for differences of project
attributes known as cost drivers [9]. This
model estimates costs in quick and rough
way. Measuring the effort and duration is
as follows:
Effort (Person-Months) = a x KLOCb
Development Time (months) = c x Effortd
40
2.1.1. BASIC COCOMO Model (2/7)
The coefficients a,b,c & d are shown in the
following table:
Software
a
Project
Organic
2.4
Semidetached
3.0
Embedded
2.8
b
c
1.05
1.12
1.20
d
2.5
2.5
2.5
0.38
0.35
0.32
41
2.1.1. BASIC COCOMO Model (3/7)
The average staff size to complete the
project is calculated as:
Average staff size in persons
= Effort / Development Time
And the productivity level is calculated as:
Productivity in KLOC / Person-Months
= KLOC / Effort
42
2.1.1. BASIC COCOMO Model (4/7)
Example:
Compute effort and development time for a project
with size of 400 KLOC considering the three modes
organic, semidetached and embedded.
The basic COCOMO equation for effort and
development time:
Effort (Person-Months) = a x KLOCb
Development Time (months) = c x Effortd
43
2.1.1. BASIC COCOMO Model (5/7)
For Organic mode
Effort
= 2.4 (400)1.05 = 1295.31 Person-Months
Development Time = 2.5(1295.31)0.38 = 38.07 Months
For the Semidetached mode
Effort = 3.0(400)1.12 = 2462.79 Person-Months
Development time = 2.5(2462.79)0.35 = 38.45 Months
For the Embedded mode
Effort = 3.6(400)1.20 = 4772.81 Person-Months
Development time = 2.5(4772.8)0.32 = 38 Months
44
2.1.1. BASIC COCOMO Model (6/7)
Example:
Compute effort, development time, average
staff size and productivity for a project of 200
KLOC size. The development team Average
previous experience on similar projects and
the deadline is medium.
45
2.1.1. BASIC COCOMO Model (7/7)
Solution
As the project size is between 50 and 300 KLOC, the
development team of average experience for similar project
and the deadline is not tight, that implies that COCOMO
mode is semidetached.
Effort
= 3.0(200)1.12 = 1133.12 person-months
Development time = 2.5(1133.12)0.35 = 29.3 months
Average staff size = Effort / Development time = 38.67 Persons
Productivity
= KLOC / Effort = 0.1765 KLOC / Person-Months
46
2.1.1.2. Intermediate COCOMO Model (1/7)
The intermediate COCOMO is an advanced
form of the basic COCOMO that considers
the cost drivers (project attributes). These
factors are 18 factors grouped into 4
categories that influence the system size
[5,11].
47
2.1.1.2. Intermediate COCOMO Model (2/7)
Product
Attributes
• Reliability
(RELY)
• Size of
application
database
(DATA)
• Complexity
of the
product
(CPLX)
Hardware
Attributes
• Runtime
performance
constraints
(TIME)
• Memory
constraints
(STOR)
• Virtual
machine
volatility
(VIRT)
• Turnaround
time (TURN)
Personal Attributes
•
•
•
•
•
Project
Attributes
Analyst capability • Modern
(ACAP)
programmin
Programmer
g practices
capability (PCAP)
(MODP)
Application
• Use of
experience (AEXP)
software
Virtual m/c
tools (TOOL)
experience (VEXP) • Required
Programming
developmen
language
t Schedule
experience (LEXP)
(SCED)
48
(3/7)
Effort
Multiplier
values
Effort
Adjustment
Factor (EAF)
[10] = the
product of the
effort
multipliers
corresponding
to each of the
cost drivers
for your
project
Cost
Driver Very
s
low
[5,11]
Effort Multiplier Values
Low Nomin High
Very
al
High
Extra
High
Product Attributes
REL Y
0.75
0.88
DATA
-0.94
CPLX
0.70
0.85
1.00
1.00
1.00
1.15
1.08
1.15
1.40
1.16
1.30
--1.65
Computer Attributes
TIME
--STOR
---
1.00
1.00
1.11
1.06
1.30
1.21
1.66
1.56
VIRT
TURN
1.00
1.00
1.15
1.07
1.30
1.15
---
---
0.87
0.87
49
(4/7)
Effort
Multiplier
values
Effort
Adjustment
Factor (EAF)
[10] = the
product of the
effort
multipliers
corresponding
to each of the
cost drivers
for your
project
Cost
Driver Very
s
low
[5,11]
Effort Multiplier Values
Low Nomin High
Very
al
High
Personnel Attributes
ACAP
1.46
1.19
AEXP
1.29
1.13
PCAP
1.42
1.17
Extra
High
1.00
1.00
1.00
0.86
0.91
0.86
0.71
0.82
0.70
----
VEXP
1.21
1.10
LEXP
1.14
1.07
Project Attributes
1.00
1.00
0.90
0.95
---
---
MODP
TOOL
SCED
1.00
1.00
1.00
0.91
0.91
1.04
0.82
0.83
1.10
----
1.24
1.24
1.24
1.10
1.10
1.08
50
2.1.1.2. Intermediate COCOMO Model (5/7)
The intermediate COCOMO model for measuring the
effort and duration is as follows [5,11]:
EFFORT (Person-Months) = a x KLOCb x EAF
DEVELOPMENT DURATION (months) = c x EFFORTd
The coefficients a,b,c & d are shown in this table:
SW Project
a
b
c
d
Organic
3.2
1.05
2.5
0.38
Semidetached
3.0
1.12
2.5
0.35
Embedded
2.8
1.20
2.5
0.32 51
2.1.1.2. Intermediate COCOMO Model (6/7)
Example
What is the Effort Adjustment Factor for a
project with the following parameters:
Complexity is rated Very High
Language & Tools Experience is rated Low
All of the other cost drivers are rated to be
Nominal
52
2.1.1.2. Intermediate COCOMO Model (7/7)
Solution:
EAF = (effort multiplier of 1.30 for complexity) x (effort
multiplier of 1.24 for language and tools experience) x
(effort multiplier of 1.00 for all other factors) = 1.612
Adding to the previous, if we consider the project is
semidetached of 7816 LOC (7.816 KLOC) so what is the
effort, development time and average staff size?
Effort = 3.0 x (7.816)1.12 x 1.612 = 48.37 person-months
Development time = 2.5 x Effort0.35 = 2.5 x 48.37 0.35 = 9.718 months
Average staff size = Effort / Development time = 4.97 persons
53
2.1.1.3. Detailed COCOMO Model (1/11)
Example:
Which is better for project manager: hiring very high
competitive developers with very low experience on
the programming language used to develop the
project or low competitive developers with high
experience on the programming language ; for an
embedded system project of 400 KLOC size.
54
2.1.1.3. Detailed COCOMO Model (2/11)
Solution:
E = a (KLOC)b = 2.8 (400)1.20 = 3712 PM
Scenario 1: very highly capable developers
(application experience - AEXP cost driver) with very
little experience (Programming language experience
(LEXP)) in the programming being used.
EAF = 0.82 x 1.14 = 0.9348
Effort = (2.8 (400)1.20 ) x 0.9348 = 3470 personmonths
Development time = 2.5 (3470)0.32 = 33.9 months
55
2.1.1.3. Detailed COCOMO Model (3/11)
Solution:
E = a (KLOC)b = 2.8 (400)1.20 = 3712 PM
Scenario 2: low quality developers but lot of
experience with the programming language being
used.
EAF = 1.29 x 0.95 = 1.22
Effort = (2.8 (400)1.20) x 1.22 = 4528 person-month
Development time = 2.5 (4528)0.32 = 36.9 months
The effort and development time of scenario 2 are
higher than of scenario 1.
56
2.1.1.3. Detailed COCOMO Model (4/11)
This type of COCOMO is the sophisticated
version of COCOMO where it complements
the intermediate version by accounting for
the influence of individual project phases. As
the detailed COCOMO is Phase-Sensitive, the
effort and development time are changing
based on phase.
57
2.1.1.3. Detailed COCOMO Model (5/11)
For Plan / Requirements Phase
Effort: 6% to 8%
Development time : 10% to 40%
For Design Phase
Effort: 16% to 18%
Development Time : 19% to 38%
For Programming Phase
Effort :48% to 68%
Development Time : 24% to 64%
For Integration & Test
Effort: 16% to 34%
Development Time : 18% to 34%
EFFORT (Persons-Month) = a x (EFFORT of intermediate COCOMO)
DEVELOPMENT DURATION (months) = b x (Development Time of 58
intermediate COCOMO)
Mode &
Code
Size
2.1.1.3.
Plan &
System Detail Module Integrati
Requirem
Design ed
Code
& on &
Detailed
COCOMO
Model
(6/8)
ents
Desig Test
Test
n
Organic Small S≈2
0.06
0.16
0.26
0.42
0.16
KLOC
Organic medium
0.06
0.16
0.24
0.38
0.22
S≈32 KLOC
Semidetached
0.07
0.17
0.25
0.33
0.25
medium S≈32 KLOC
Semidetached
0.07
0.17
0.24
0.31
0.28
large S≈128 KLOC
Embedded large
0.08
0.18
0.25
0.26
0.31
S≈128 KLOC
Embedded extra
0.08
0.18
0.24
0.24
0.34
59
large S≈320 KLOC
a weight factors [5,11]
Mode &
Code Size
Plan &
Requirem
ents
System Detail Module Integrati
Design ed
Code & on &
Design Test
Test
2.1.1.3. Detailed COCOMO Model (6/8)
b
weight
factors
[5,11]
Organic Small S≈2
KLOC
Organic medium
S≈32 KLOC
Semidetached
medium S≈32
KLOC
Semidetached
large S≈128 KLOC
Embedded large
S≈128 KLOC
Embedded extra
large S≈320 KLOC
0.10
0.19
0.24
0.39
0.18
0.12
0.19
0.21
0.34
0.26
0.20
0.26
0.21
0.27
0.26
0.22
0.27
0.19
0.25
0.29
0.36
0.36
0.18
0.18
0.28
0.40
0.38
0.16
0.16
0.30
60
2.1.1.3. Detailed COCOMO Model (8/11)
Example:
What the effort and development timed needed
to develop a full screen editor that contains the
following components ; assuming at least three
cost driver of values different from 1.0:
1. Screen edit (4 KLOC size)
2. Command Language Interpreter (2 KLOC size)
3. File Input & Output (1 KLOC size)
4..Cursor Movement (2 KLOC size)
5. Screen Movement (3 KLOC size)
61
2.1.1.3. Detailed COCOMO Model (9/11)
Solution
The total Size of the five modules are = 12 KLOC ;
implies that is an organic software
Assuming that cost drivers are
1. Required software reliability is high
1.15
2. Product complexity is high
1.15
3. Analyst capability is high
0.86
4. Programming language experience is low 1.07
5. All other drivers are nominal
1
62
2.1.1.3. Detailed COCOMO Model (9/11)
EAF = 1.15 x 1.15 x 0.86 x 1.07 x 1
= 1.2169
Effort = 3.2 (12) 1.05 x 1.2169
= 2.91 person-months
0.38
Development time = 2.5 (52.91)
= 11.29 months
63
2.1.1.3. Detailed COCOMO Model (11/11)
Example:
Continuing the previous example: what are the efforts
and development times @ for different stages ; keeping in
mind the project is organic with small size
Solution:
….
64
COCOMO tool
http://www.functionpointmodeler.com/main.faces?target=f
ree_online_cocomo_tool.html
65
2.2. Non-Algorithmic Estimation
Techniques
• Expert judgment
• Estimation by analogy
66
2.2.1. Expert Judgment
Expert judgment is used heavily to estimate efforts in
software industry. It is based on past experience with
similar projects. Opinions of more than one expert
may need to be combined for more accurate
estimation [1].
67
2.2.1. Expert Judgment
However the disadvantage of the approach that it
requires high professional experts with long
experience and track record in the domain of the
projects. One expert is not enough, a number of
experts are involved to estimate the effort. The cost
of hiring those expert tend to be high.
68
2.2.1. Expert Judgment
A lot of companies working in the software
development domain do trust this approach as
experts work on the ground, digest very well from
previous experience some factor that are not
consider in the previous models such as culture of
workers and the conflicts that might hinder the plan;
the way of organizing the troops and finally
prioritizing the tasks.
69
2.2.2. Estimation by Analogy
If the project manager is able to define the project
attributes and search within large database of
previously similar implemented projects, he would
be able to have a good base to estimate the efforts
of his project [1].
Effort estimation for the new project is done using
the differences between the new one and the past
ones. This approach requires a database of a large
number of past projects and that incrementally
increasing by time.
71
References
1.
2.
Hughes, B. and Cotterell, M., Software Project Management, McGraw-Hill, 5th ed., 2009.
Harish Chandra, Aasiya Khatoon and Nalin Chaudhary, “Metrics for Software Project Size
Estimation”, International Journal of Advanced Research in Computer Science and Software
Engineering, 2015 ; http://www.ijarcsse.com/docs/papers/Volume_5/1_January2015/V5I10407.pdf
3. https://en.wikipedia.org/wiki/Function_point
4. http://www.softwaremetrics.com/fpafund.htm
5. Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age
International Publishers, 2007
6. Function Point Language table http://www.qsm.com/resources/function-point-languagestable
7. “How to use COSMIC Functional Size in Effort Estimation Models?"
http://medieteknik.bth.se/fou/forskinfo.nsf/all/649df6573bd994f3c125751a0051d277/$fil
e/Gencel_Cigdem_MensuraIWSMMetrikon.pdf
8. Barry Boehm. Software Engineering Economics. Englewood Cliffs, NJ:Prentice-Hall, 1981.
ISBN 0-13-822122-7
9. https://en.wikipedia.org/wiki/COCOMO
10. http://www.iasj.net/iasj?func=fulltext&aId=33976
72
11. http://www.slideshare.net/PiyushGogia/chapter-4-software-project-planning
Conclusion (1/3)
• To estimate effort, project size should be estimated first
• Size is estimated through either technical or functional
estimation methods
• LOC is a technical size estimation method that counts the
logical lines of code
• Functional Size Estimation (known as Function Point Analysis)
Techniques are:
1. IFPUG Function Points (IFPUG FP)
2. COSMIC Function Points (COSMIC FFP)
• IFPUG measures the size of an application without counting
lines of code.
• COSMIC is used to size software projects they r dominated by
73
functions that input data, store &retrieve data, &output data.
Conclusion (2/3)
• Effort is measured in man-day terms and development time.
• Effort estimation models are algorithmic and nonalgorithmic
• Algorithmic Effort Estimation techniques are COCOMO, UseCase Points, Class Points and UML Points
• Non-Algorithmic estimation techniques are Expert
judgment and Estimation by analogy
• COCOMO compute software development effort as a
function of program size
• There are 3 COMOCO models, simple, medium and detailed
that could run in different modes: organic , embedded and
74
semi-detached modes
Conclusion (3/3)
• Expert judgment is the most used effort
estimation technique in software industry
which is based on past experience with
similar projects.
• Estimation by Analogy is done using the
differences between the new project and
the past ones in the same domain with
nearly the same conditions
75
Thank you for
your attention.
Tempus