0% found this document useful (0 votes)
56 views47 pages

Effort Estimation VIA Software Metrics

This document discusses effort estimation using function point analysis. It provides information on calculating function points, including counting the number of user inputs, outputs, inquiries, files and interfaces. It also discusses weighting factors, complexity adjustments, and examples to demonstrate calculating function points for a project.

Uploaded by

Mansab Raja Khan
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)
56 views47 pages

Effort Estimation VIA Software Metrics

This document discusses effort estimation using function point analysis. It provides information on calculating function points, including counting the number of user inputs, outputs, inquiries, files and interfaces. It also discusses weighting factors, complexity adjustments, and examples to demonstrate calculating function points for a project.

Uploaded by

Mansab Raja Khan
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/ 47

Effort Estimation VIA software

Metrics
Function Point
• Collection of executable statements that
perform a certain task, together with
declarations of the formal parameters and
local variables manipulated by those
statements.
Function Points
FP cont…
FP cont…
Calculation Using FP
FP ranking
FP cont…
Calculation
Factors
Factors cont…
Function Point Calculation

5 3

Function Counts = FC   x i w j
i  1 j 1

  14 
Function Points = FP  FC .65  .01  ck 
  k  1 

where
xi = function i
wj = weight j
ck = complexity factor k
Over all
Weighting Factor
weighting factor
measurement parameter count simple avg. complex
number of user inputs X 3 4 6 =
number of user outputs X 4 5 7 =
number of user inquiries X 3 4 6 =
number of files X 7 10 15 =
number of ext.interfaces X 5 7 10 =
count-total
complexity multiplier
function points
Example
Cont…
Attempt

• Compute the function point value for a project with the following
information domain characteristics:
– Number of user inputs: 32
– Number of user outputs: 60
– Number of user enquiries: 24
– Number of files: 8
– Number of external interfaces: 2
– Assume that weights are average and external complexity adjustment
values are not important.
Example: SafeHome Functionality
Enter Password

User Sensor Inquiry SafeHome


SafeHome Messages
User
System
System Sensor Status User
User
Panic Button

Monitor
Monitor
Password, Alarm Alert and
and
Sensors, etc. Response
Response
System
System
System
System
Config
ConfigData
Data
Example: SafeHome FP Calc
weighting factor
measurement parameter count simple avg. complex
number of user inputs 1 X 3 4 6 = 3
number of Ext. outputs 2 X 4 5 7 = 8
number of user inquiries 2 X 3 4 6 = 6
number of files 1 X 7 10 15 = 7

number of ext.interfaces 1 X 5 7 10 = 5
count-total 29
complexity multiplier
function points
Attempt Yourself
• The Pilot will be able to submit the Co-ordinates to Air traffic
Control system ATCS which generates the message to him
regarding the current coordinates of CZ-6007. Pilot will provide
the height to ATCS to retrieve the external temperature. ATCS
may also be used to inquire the Zone and landing system
sensors. The Zone is retrieved via Zone Interface and Response
interface system generates the results for landing sensors. Pilot
may transfer the control from manual to auto that will allow the
ATCS of CZ-6007 to access flying details from SYSTEM AUTO
DATA.

• Question: Calculate FP. Assume average values and the impact


of 14 general characteristics may be considered essential i.e. 5
More Appropriate way to compute FP
• Acronyms and Abbreviation
• Through out the tutorial i have been using lot of acronyms. Knowing them before
hand will make your comfortable while reading.

• FP : Function Point
• ILF : Internal Logical File.
• EIF : External Interface file
• EI : External Inputs
• EO : External Outputs
• EQ : External Enquiries
• RET : Record Element Type
• DET : Data Element Type
• FTR : File Type Reference
• GSC : General System Characteristic
• VAF : Value Added Factor
Sections of Function Point

Data section: Data
section is further divided into:

1.Internal logical file (ILF):

This contains logically related data that resides inside application boundary. The
application has to maintain data . Example like customer table which will be
maintained through a Customer data entry screen. Note the inside application
data is updated and not any external data. But if you are updating external
application table, those tables will not be categorized as ILF.

2.External Interface files (EIF):

This contains components which will lie external of application boundary and
used for only for reference purpose. Note : Do not include functionality like
updating the external application in this section.
Transaction Section
• Transaction section uses data section, that is,

• External Inputs (EI): EI is basically from which we can maintain the ILF.
Accountants definitely should have interface through which they can
maintain (Add, Update, Delete) ILF. The basic judgment factor to come out
with EI is from user screens. Like, a customer maintenance screen which
gives us an idea that we have 1 EI and 1 ILF.

• External Outputs (EO): Here data passes from inside application to outside.
Example your application generates XML or CSV ( Comma separated values)
Files. These files are then used by some external application to update the
external application tables. So in this scenario the data is passed from your
application to a external application. So these types of function will fall in
this category.

• External Inquiries (EQ): These functions will be mainly reports. They have
input criteria. Any type of reports and search screens are right components
for EQ. Note like EI and EQ they do not update any ILF or EIF. They only fetch
data for display. So for identifying EQ is any reports or search screens which
do not update data in any tables(ILF or EIF).Example Balance sheet in
accounting reports.
Sub sections
• These are subsections which can either be a subset of either transaction section or
data section.

• Record Element Type (RET): A subgroup of data element inside a logical file. In our
customer ILF, we can have multiple addresses or multiple phone numbers. So for the
customer, we can have 2 RETs, Addresses and Phone numbers.

• Data Element Type (DET): DET is a non-repetitive field in a ILF. Please note, I have said
that field should not repeat in counting again. Every customer ILF can have Customer
Code. So the customer code becomes a DET. Every invoice can have customer code
saying whom this invoice belongs to. But once the customer code has been counted,
do not count customer code twice as two different DETs. But in practical scenarios,
when doing function point of huge projects, there is possibility that you can count DET
twice, make a second iteration just for removing the duplicate DETs.

• File Type Reference (FTR): An FTR is a file referenced by transaction. An FTR must also
be an internal logical file or external interface file.
General System Characteristic Section (GSC):

• This section is the most important section. All the above 3 sections are counting sections. They relate only to
application. But there are other things also to be considered while making a software, like are you going to
make it an N-Tier application, what's the performance level the user is expecting etc. These are external
factors which affect the software a lot and also the cost of it. When you submit a function point to a client, he
normally will skip everything and come to GSC first. GSC gives us something called as VAF (Value Added
Factor). There are 14 points considered to come out with VAF (Value Added factor).

1. Data communications: How many communication facilities are there to aid in the transfer or exchange of
information with the application or system?
2. Distributed data processing: How are distributed data and processing functions handled?
3. Performance: Did the user require response time or throughput?
4. Heavily used configuration: How heavily used is the current hardware platform where the application will be
executed?
5. Transaction rate: How frequently are transactions executed; daily, weekly, monthly, etc.?
6. On-Line data entry: What percentage of the information is entered On-Line?
7. End-user efficiency: Was the application designed for end-user efficiency?
8. On-Line update: How many ILFs are updated by On-Line transaction?
9. Complex processing: Does the application have extensive logical or mathematical processing?
10.Reusability: Was the application developed to meet one or many user’s needs?
11.Installation ease: How difficult is conversion and installation?
12.Operational ease: How effective and/or automated are start-up, back up, and recovery procedures?
13.Multiple sites: Was the application specifically designed, developed, and supported to be installed at
multiple sites for multiple organizations?
14.Facilitate change: Was the application specifically designed, developed, and supported to facilitate change?
Function Count Reference Table
EI Rating Table

Data Elements
FTR 1 to 4 5-15 >15
Less than 2 3 3 4
2 3 4 6
>2 4 6 6

EO Rating Table
Data Elements
FTR 1 to 5 6-19 >19
<2 4 4 5
2 or 3 4 5 7
>3 5 7 7
Cont…
EQ Rating Table
Data Elements
FTR 1 to 5 6-19 >19
<2 3 3 4
2 or 3 3 4 6
>3 4 6 6
ILF Rating Table
Data Elements
RET 1 to 19 20-50 51 or more
1 RET 7 7 10
2 to 5 7 10 15
>6 10 15 15

EIF Rating Table


Data Elements
RET 1 to 19 20-50 51 or more
1 RET 5 5 7
2 to 5 5 7 10
>6 7 10 10
Example

1.There are 2 ILFs in the above screen: The customer ILF.


2.The Customer Address ILF. (or could be one, if RET are increased from 1 to 2)
•There could be one External Interface File for verifying card through payment
Count FP for ILFs & EIFs
• Number of DET and number of RET may be
counted and look for the table values.
• i.e. DET = ?
• RET= ?
• Function Point count= ?
Last Step to COUNT FP
• Add individual function points of five categories.
• Calculate GSC as GSC Value(0-5)
Data communications 1
Distributed data
1
processing
Performance 4
Heavily used
FP = 0.87 * 24 = 20.88 = rounded to 21 FP. 0
configuration
Transaction rate 1
On-Line data entry 0
End-user efficiency 4
On-Line update 0
Complex processing 0
Reusability 3
Installation ease 4
Operational ease 4
Multiple sites 0
VAF = 0.65 + ((sum of all GSC factor)/100). = 0.65
Facilitate change
+ (22/100) = 0.87.
0
Total 22
• On the basis of studies, the conversion
between LOC and function points is
possible.
Halstead Equations
• Give more weight to lines that are more complex. metrics of the software should reflect the
implementation or expression of algorithms in different languages, but be independent of their execution
on a specific platform. These metrics are therefore computed statically from the code.
• In order to estimate the code length, volume, complexity and effort, software science suggests the use of
operators and operands.
Halstead’s Example
if (k < 2)
{
if (k > 3)
x = x*k;
}

• Distinct operators: if ( ) { } > < = * ;


• Distinct operands: k 2 3 x
• n1 = 8
• n2 = 4
• N1 = 10
• N2 = 7
Attempt yourself
Macabe Complexity
• The cyclomatic complexity of a section of source code
 is the number of linearly independent paths within it.
For instance, if the source code contained no 
control flow statements (conditionals or decision
points), the complexity would be 1, since there would
be only a single path through the code. If the code
had one single-condition IF statement, there would
be two paths through the code: one where the IF
statement evaluates to TRUE and another one where
it evaluates to FALSE, so the complexity would be 2
McCabe’s Complexity Measures
 It simply measures the amount of decision logic in the program
module. Cyclomatic complexity gives all possible paths through
the module. Cyclomatic complexity is often referred to as
McCabe's complexity.
 It is important to testers because it provides an indication of the
amount of testing (including reviews) necessary to practically
avoid defects
 McCabe's complexity used to define minimum number of test
cases required for a module 
 McCabe’s metrics are based on a control flow representation of
the program.
 A program graph is used to depict control flow.
 Nodes represent processing tasks (one or more code statements)
 Edges represent control flow between nodes
Cyclomatic Complexity
Set of independent paths through the graph
(basis set)

V(G) = E – N + 2
◦ E is the number of flow graph edges
◦ N is the number of nodes

V(G) = P + 1
◦ P is the number of predicate nodes
Meaning
 V(G) is the number of (enclosed) regions/areas of the planar graph.
 The V(g) or cyclomatic number is a measure of the complexity of a function
which is correlated with difficulty in testing. The standard value is
between 1 and 10.
 A value of 1 means the code has no branching.

 Number of regions increases with the number of decision paths and loops

 A quantitative measure of testing difficulty and an indication of ultimate


reliability

 Experimental data shows value of V(G) should be no more then 10 - testing is


very difficulty above this value
More Notations
Notations
Example

while (i<n-1)
while (j<n) do
if A[i]<A[j] then
swap(A[i], A[j]);
end do;
i=i+1;
end do;
Flow Graph
1

7 4 5

6
Computing V(G)
V(G) = 9 – 7 + 2 = 4
V(G) = 3 + 1 = 4
Basis Set
◦ 1, 7
◦ 1, 2, 6, 1, 7
◦ 1, 2, 3, 4, 5, 2, 6, 1, 7
◦ 1, 2, 3, 5, 2, 6, 1, 7
Try This

• If A=100;
Then if B<C;
Then A=C;
Else A=B;
End if
• End if
• Print A
Another Example

You might also like