Characteristic of Quality Function

Point Analysis
• Function Point Analysis should be performed by trained
and experienced personnel. If Function Point Analysis is
conducted by untrained personnel, it is reasonable to
assume the analysis will done incorrectly.
• Current application documentation should be utilized to
complete a function point count. For example, screen
formats, report layouts, listing of interfaces with other
systems and between systems, logical and/or preliminary
physical data models will all assist in Function Points
Analysis.
• The task of counting function points should be included as
part of the overall project plan. That is, counting function
points should be scheduled and planned. The first function
point count should be developed to provide sizing used for
estimating.
 Counting Function Points
• The five functional units are ranked according to
their complexity i.e. low, average, high
• Organizations that use FP methods develop
criteria for determining whether a particular entry
is Low, Average or High
• After classifying each of the five function types,
the unadjusted function point (UFP) are
calculated using predefined weights for each
function type.
 Function Units with weighting Factors

Functional Units Weighting Factors

Low Average High

External Input 3 4 6
External Output 4 5 7
External Enquiries 3 4 6
Internal Logical Files 7 10 15
External Interface Files 5 7 10
 UFP counting table
Functional Units Count Functional Unit Totals
Complexity
EI Low * 3 =sum of all count
Average* 4 complexity
High *6
EO
Ext Inquiry
ILF
EIF
 Function Point Analysis
• The procedure for the calculation of UFP in
mathematical form is
5 3

UFP=Σ Σ Zij wij

i=1 j=1

Wij – It is the entry of the ith row and jth column of the table
Zij – It is the count of the number of functional units of type I
that have been classified as having the complexity
corresponding to column j.
Organizations use function point methods develop a
criterion for determining whether a particular entry is low,
average or high.
• The final number of function point is
arrived at by multiplying the UFP by an
adjustment factor.
• The adjustment factor allows the UFP
count to be modified by at most +/- 35%.
– FP=UFP * CAF
– UFP – Unadjusted Function point
– CAF Complexity adjustment factor and is
equal to [.65 + .01 * ΣFi .
• Calculation of CAF
• Rate each of the following factors on the
scale of 0 to 5
– No Influence – 0
– Incidental – 1
– Moderate - 2
– Average - 3
– Significant - 4
– Essential - 5
• Number of Factor
– Does the system require reliable backup and
recovery?
– Is data communication required?
– Are there distributed processing functions?
– Is performance critical?
– Will the system run in an existing heavily
utilized operational environment?
– Does the system require on line data entry?
• Does the online data entry require the input
transaction to be built over multiple screen or
operations?
• Are the master files updated on line?
• Is the input, output, files or inquiries complex
• Is the internal processing complex?
• Is the code designed to be reusable?
• Are conversion and installation included in the
design?
• Is the system designed for multiple installation in
different organizations?
• Is the application designed to facilitate change
and ease of use by the user?
 Uses of function points
• The collection of function point data has two
primary motivation
– The desire by managers to monitor level of
productivity, number of function points achieved per
work hour expended. (The function point accurately
describe the size of the final software project)
– The estimation of software development cost. There
are only a few studies that address this issue, though
it is arguably the most important potential use of
function point data
• Functions points may compute the following
important metrics :
– Productivity = Function Point/ persons –
months
– Quality = Defects / FP
– Cost = Rupees / FP
– Documentation = Pages of documentation per FP
These Metrics are controversial and are not universally
acceptable.
These are standards issued by the International
Function Point User Group and the United Kingdom
Function Point User Group.
• Consider a project with the following
functional units :
– Number of user inputs = 50
– Number of user output = 40
– Number of user Enquiries = 35
– Number of user files = 06
– Number external interfaces = 04
Assume all complexity adjustment factors and
weighting factors are average.
Compute the function points for the project.
• UFP = Σ Σ Zij wij
• UFP = 50 * 4 + 40 * 5 + 35 * 4 + 6 * 10 + 4
*7
• CAF = ( 0.65 + 0.01 Σ Fi)
(0.65 + 0.01 ( 14 * 3) = 0.65 + 0.42
=1.07
FP = UFP * CAF
628 * 1.07 =672
 Constructive Cost Model
(COCOMO)
• Developed by B.W. Boehm in 1981
• COCOMO is one of the most widely used
software estimation models in the world
• Is a hierarchy of software cost estimation model,
which include basic intermediate and detailed sub
models.
• COCOMO predicts the effort and schedule for a
software product development based on inputs
relating to the size of the software and a number
of cost drivers that affect productivity
 COCOMO Models

• COCOMO has three different models that

reflect the complexity:
– the Basic Model
– the Intermediate Model
– and the Detailed Model
 Basic Model
• Aims at estimating, in a quick and rough
fashion, most of the small to medium sized
project.
• Three modes of software development are
considered in this model
– Organic
– Semi Detached
– embedded
 Organic Mode
• Relatively small, simple software projects
• Small teams with good application
experience work to a set of less than rigid
requirements
• Similar to the previously developed projects
• relatively small and requires little innovation
• Size of software development in this mode
ranges from small (a few KLOC) to medium (a
few tens of KLOC)
 Semidetached Mode

• Intermediate (in size and complexity)

software projects in which teams with mixed
experience levels must meet a mix of rigid
and less than rigid requirements.
Contd…

• Embedded Mode
• Software projects that must be developed
within a set of tight hardware, software, and
operational constraints.
 Comparison of three COCOMO
modes
Mode Project Size Nature of Innovation Deadline of Developme
Project the Project nt
Environme
nt
Organic Typically 2- Small size Little Not Tight Familiar &
50 KLOC project, In House
experienced
developers in
the familiar
environment.

For Example
Pay roll,
inventory,
project etc.
 Comparison of three COCOMO
modes
Mode Project Size Nature of Innovation Deadline of Developme
Project the Project nt
Environme
nt
Semi Typically 50- Medium Size Medium Medium Medium
Detach 300 KLOC Project, Medium
ed Size Team,
Average
previous
experience on
similar Projects.
Eg. – Utility
System like
compilers,
database
systems,
editors etc.
 Comparison of three COCOMO
modes
Mode Project Size Nature of Innovation Deadline of Developme
Project the Project nt
Environme
nt
Embed Typically Large Project, Significant Tight Complex
ded Over 300 Real Time Hardware/
KLOC systems, Customer
Complex Interfaces
interfaces, very required
little previous
experience

Eg : ATMs, Air
Traffic Control
etc.
• The basic COCOMO equation take the
form
– E=ab (KLOC) bb
– D=Cb (E) db
• Where E is effort applied in Person Month
and D is the development time in months.
Project Ab bb cb db
Organic 2.4 1.05 2.5 0.38

Semidet 3.0 1.12 2.5 0.35

ached
Embedd 3.6 1.20 2.5 0.32
ed
• When effort and development time are
known, average staff size
– Average staff size (SS) = E/D Person
• When project size is known, the
productivity level be calculated as
– Productivity (p) = ( KLOC )/ E KLOC/ PM
• Suppose that a project was estimated to
be 400 KLOC. Calculate the effort and
development time for each of the three
modes i.e organic, semidetached and
embedded
• Organic Mode
– E= 2.4*(400)1.05 =1295.31
– D = 2.5 * ( 1295.31)0.38 = 38.07PM
• A Project size of 200 KLOC is to be
developed. Software development team
has average experience on similar type of
projects. The project schedule is not very
tight. Calculate the effort development
time, average staff size and productivity of
the project.
 Intermediate Model
• The basic model allowed for a quick and
rough estimate, but it resulted in lack of
accuracy.
• Boehm introduced an additional set of 15
predictors called cost drivers in the
intermediate model to take account of the
software development environment.
 Intermediate Model
• Cost Drivers are grouped into four categories :
– Product attributes
• Required Software reliability (RELY)
• Database Size (DATA)
• Product complexity (CPLX)
– Computer attributes
• Execution time constraint (TIME)
• Main storage constraint (STOR)
• Virtual machine volatility (VIRT)
• Computer turnaround time (TURN)
• Personnel Attributes
– Analyst capability (ACAP)
– Application Experience ( AEXP)
– Programmed Capability (PCAP)
– Virtual machine Experience (VEXP)
– Programming Language Experience (LEXP)
• Project Attributes
– Modern programming practices (MODP)
– Use of software tools (TOOL)
– Required development schedule (SCED)
• Each cost driver is rated for a given project
environment.
• The rating uses a scale very low, low,
nominal, high, very high, extra high which
describes to what extent the cost drivers
applies to the project being estimated.
 Multiplier values for effort
calculations
Cost Rating
Drivers
Product Very Low Nomi High Very Extra
Attributes Low nal High High
RELY 0.75 0.88 1.00 1.15 1.40
DATA 0.94 1.00 1.08 1.16
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
 Multiplier values for effort
calculations
Cost Rating
Drivers
Computer Very Low Nomi High Very Extra
Attributes Low nal High High
TIME 1.00 1.11 1.30 1.66
STOR 1.00 1.06 1.21 1.56
VIRT 0.87 1.00 1.15 1.30
TURN 0.87 1.00 1.07 1.15
 Multiplier values for effort
calculations
Cost Rating
Drivers
Personnel Very Low Nomi High Very Extra
Attributes Low nal High High
ACAP 1.46 1.19 1.00 0.86 0.71
AEXP 1.29 1.13 1.00 0.91 0.82
PCAP 1.42 1.17 1.00 0.86 0.70
VEXP 1.21 1.10 1.00 0.90
LEXP 1.14 1.07 1.00 0.95
 Multiplier values for effort
calculations

Cost Rating
Drivers
Project Very Low Nomi High Very Extra
Attributes Low nal High High
MODP 1.24 1.10 1.00 0.91 0.82
TOOL 1.24 1.10 1.00 0.91 0.83
SCED 1.23 1.08 1.00 1.04 1.10
• The multiplying factor for all 15 cost
drivers are multiplied to get the effort
adjustment factor (EAF).
• Typical values for EAF range from 0.9 to
1.4.
• The intermediate COCOMO equation take
the form
– E = ai (KLOC) bi * EAF
– D = ci (E) di
Project Ab bb cb db
Organic 3.2 1.05 2.5 0.38

Semidet 3.0 1.12 2.5 0.35

ached
Embedd 2.8 1.20 2.5 0.32
ed
 Detailed COCOMO Model
• Offers a means for processing all the
project characteristics to construct a
software estimate.
• Introduces two more capabilities
– Phase Sensitive effort multipliers
– Three Level product hierarchy
Phase Sensitive Effort Multiplier
• Some phases (design, programming,
integration/test) are more affect than
others by factors defined by the cost
drivers.
• The detailed model provides a set of
phase sensitive effort multiplier for each
cost driver.
• This helps in determining the manpower
allocation for each phase of the project.
 Three Level Product Hierarchy
• Three product levels are defined. These
are module, subsystem and system levels.
• The rating of the cost drivers are done at
appropriate level, i.e. the level at which it
is most susceptible to variation.
 Development Phases
• Plan/requirements –
– Requirement is analyzed, the product plan is setup
and a full product specification is generated
– This phase consumes from 6-8% of the effort and 10-
40% of the development time.
• Product design –
– concerned with the determination of the product
architecture and the specification of the subsystem.
– This phase requires from 16-18% nominal effort and
can last from 19-38% of the development time.
• Programming –
– The third phase of the COCOMO development cycle
is divided into the sub phases : detailed design and
code/unit test.
– This phase requires from 48-68% of the effort and
lasts from 24-64% of the development time.
• Integration/Test –
– This phase occurs before the delivery.
– This phase requires from 16-34% of the nominal effort
and can last from 18-34% of the development time.
• Software might be partly developed from
software already existing, a full development is
not always required.
• In such cases, the part of design code, code and
integration to be modified are estimated.
• Then adjustment fact A is calculated
– A= .4 * DD + .3 * C + .3 *I
• The size equivalent is obtained by
– S(equivalent) = (S* A)/100
 COCOMO II
• Revised version of the original COCOMO and is
developed at University of southern California
under the leadership of Dr. Barry Boehm.
• The model is tuned into life cycle practices of 21
century.
• It also provides a quantitative analytic
framework, and set of tools and techniques for
evaluating the effects of software technology
improvements on software life cycle costs and
schedules.
 Categories of application/Projects
Identified by COCOMO - II
• End User Programming
• Infrastructure sector
• Intermediate Sector –
– Application generators and composition aids – create largely
prepackaged capabilities for user programming. Product line will
have many reusable components.
– Application composition sector –deals with applications which
are too diversified to be handled by prepackaged solution, but
which are sufficiently simple to be rapidly comosable from
interoperable components.
– System Integration – deals with large scale, highly embedded or
unprecedented systems.
 Stages of COCOMO II
Stage Model Applicable Applications
No Name for the type
of projects
Stage I Application Application In addition to
application
compositio Composition composition type of
n projects. This model
is also used for
estimation prototyping (Stage of
model application
generators,
infrastructure &
system integration.
 Stages of COCOMO II
Stage Model Applicable Applications
No Name for the type
of projects
Stage II Early Application Used in early design
stage of a project,
Design generators, when less is known
estimation infrastructure about the project
model & system
integration
 Stages of COCOMO II
Stage Model Applicable Applications
No Name for the type
of projects
Stage III Post Application Used after the
composition of the
architecture generators, detailed architecture
estimation infrastructure of the project
model & system
integration
Application Composition Estimation
Model
• Model is designed for quickly developed
applications using interoperable compnents.
• Can also be used for prototyping phase.
• In this model size is first estimated using object
points. The object points are easy to identify and
count.
• The object in object points defines screens,
reports and 3 GL modules as objects.
• This may or may not have any relationship to
other definition of objects.
• The steps required for the estimation of effort in
Person-Months
– Assess object count
– Classify complexity level of each object.
– Assign complexity weight to each object.
– Determine object points
– Compute new object points
– Calculate productivity rate
– Compute the estimated effort in person months
• Asses Object counts- Estimate the number
of screen, reports and 3GL components
that will comprise this application.
• Classification of complexity levels –
– we have to classify each object instance into
simple, medium and difficult complexity level
depending on values of its characteristics.
– The screens are classified on the basis of
number of views and sources and reports are
on the basis of number of sections and
sources.
 Classification of complexity level
For screens
Number of views
contained

Total >4 (< Total <8 ( 2-3 Total >8+ (>3

2server < 3 client) server 3-5 server >5
client) client)
medium
<3 Simple Simple medium

3-7 Simple Medium Difficult

>8 Medium Difficult Difficult

 Complexity weight to each object
Object type

Simple Medium Difficult

Screen 1 2 3
Report 2 5 6
3GL 10
Component
• Determine object points – add all weight
object instances to get one number and
this number is known as object point
count.
• Compute new object points
– NOP = ((Object points) * (100-% reuse) )/ 100