2. Learning Objectives
By the end of the lecture you should be able to:
Understand the concept of Size and Cost
estimation of SW
Comprehend various methods like LoC counting
Function Point counting and Work Break down
structure
Explain various best practices around SW
Estimation
2
3. Cost Estimation
project scope must be explicitly
defined
task and/or functional
decomposition is necessary
historical measures (metrics) are
very helpful
at least two different techniques
should be used or two persons doing it
remember that uncertainty is
inherent
4. Estimation Techniques
past (similar) project experience
conventional estimation
techniques
Work breakdown and effort
estimates
size (e.g. FP) estimates
6. Creating a Task Matrix
Obtained from “process framework”
application
functions
framework activities
Effort required to
accomplish
each framework
activity for each
application function
9. Function Point - Constituents
External Inputs (EI) - is an elementary process in which
data crosses the boundary from outside to inside. This
data may come from a data input screen or an other
application. The data is used to maintain one or more
internal logical files. A good source of information to
determine EI’s are Screen Layouts, Screen Formats &
dialogs, and layouts of any input forms. Additional inputs
from other applications should be inventoried here. Inputs
from other applications must update ILF’s of application
being counted.
10. Function Point - Constituents
External Outputs (EO) - an elementary process in which
derived data passes across the boundary from inside to
outside. The data creates reports or output files sent to
other applications. These reports and files are created
from one or more Internal Logical Files A good source of
information to determine the EO’s are report layouts and
electronic file formats that are being sent outside the
application boundary.
Additionally, an EO may update an ILF.
11. Function Point - Constituents
External Inquiries (EQ) - an elementary process with
both input and output components that result in data
retrieval from one or more Internal Logical Files. The input
process does not update any Internal Logical Files, and
the output side does not contain derived data. A good
source of information to determine the External Inputs
(EI’s) are Screen Layouts, Screen Formats & dialogs, and
layouts of any input forms.
12. Function Point - Constituents
Internal Logical Files (ILF) - a user identifiable group of
logically related data that resides entirely within the
applications boundary and is maintained through External
Inputs. A good source of information to determine the
ILF’s are logical and/or preliminary physical data models,
table layouts, data base descriptions.
External Interface Files (EIF) - a user identifiable group
of logically related data that is used for reference
purposes only. The data resides entirely outside the
application and is maintained by another application. The
External Interface File is an Internal Logical File for
another application. The External Interface File is an
Internal Logical File for another application. A good
source of information to determine EIF’s are interfaces
descriptions with other systems.
13. Function Point - Counting
After the components have been classified as one of the
five major components (EI’s, EO’s, EQ’s, ILF’s or EIF’s), a
ranking of low, average or high is assigned. For
transactions (EI’s, EO’s, EQ’s) the ranking is based upon
the number of files updated or referenced (FTR’s) and the
number of data element types (DET’s). For both ILF’s and
EIF’s files the ranking is based upon record element types
(RET’s) and data element types (DET’s).
ILF and EIF
14. Taking Complexity into Account
Sl General System
Characteristic
Brief Description
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 Was response time or throughput required by the user?
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 ILF’s 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?
16. Example: FP Approach
number of user inputs
number of user outputs
number of user inquiries
number of files
number of ext.interfaces
algorithms
measurement parameter
4
5
4
7
7
3
count
x
x
x
x
x
x
count-total
=
=
=
=
=
=
weight
complexity multiplier
feature points
0.25 p-m / FP = 120 p-m
40
25
12
4
4
60
160
125
48
28
28
180
569
.84
478
17. Analyzing the Information Domain
complexity multiplier
function points
number of user inputs
number of user outputs
number of user inquiries
number of files
number of ext.interfaces
measurement parameter
3
4
3
7
5
count
weighting factor
simple avg. complex
4
5
4
10
7
6
7
6
15
10
=
=
=
=
=
count-total
X
X
X
X
X
18. Why Opt for FP Measures?
independent of programming language
uses readily countable characteristics of the
"information domain" of the problem
does not "penalize" inventive implementations that
require fewer LOC than others
makes it easier to accommodate reuse and the
trend toward object-oriented approaches
But many a times it’s too early to count DETs, RETs and FTRs
19. Estimation Guidelines
estimate using at least two techniques
get estimates from independent sources
avoid over-optimism, assume difficulties
you've arrived at an estimate
adjust for the people who'll be doing the
job—they have the highest impact
Organizational capability should be baselined
esp effort per FP or effort per KLoC
21. Make or Buy
(path probability) x (estimated path cost)
i i
For example, the expected cost to build is:
expected cost = 0.30($380K)+0.70($450K)
similarly,
expected cost = $382K
expected cost = $267K
expected cost = $410K
build
reuse
buy
contr
expected cost =
= $429 K
22. Case Study for FP counting
The Institute wants to develop an automated Examination
Tracking System. There are four semesters in MBA and
at the end of each semester, there are written
examinations. Student attendance for exam is recorded
through swiping of ID card. After the exam, papers are
sent to respective examiners for evaluation and marks
are recorded. The candidates should be able to
download their marksheet. Successful candidates can
download their semestral certificates also. The criteria
for success are to obtain 40% in each subject and 50%
on aggregate. The system is expected to generate the
following reports:
Attendance details / summary for each subject in each semester
Performance details / summary for each subject in each semester 22