University of the Punjab Gujranwala Campus

Software Engineering
Function Point and Coco MO
Submitted to

Dr. Naveed Jhammat

By

Zain Ul Abdin Dar

November 19, 2023
Function Point and Function Point analysis:
Function Point is a unit of measurement representing the functionality provided by
a software application and Function Point Analysis helps people figure out how big
and complex a software project is, making it easier to plan and manage. It's like
measuring the size of a task without worrying about the technical details.

Function Point (FP):

 Imagine you're ordering food online. Each step in the process, like selecting
items, entering your address, and checking out, is a "function."
 Function points are like counting these steps, but not worrying about how
the website or app is built. It's just about what it lets you do.
Function Point Analysis (FPA):
 FPA is like giving a score to how complex these steps are. For example,
entering your address might be a bit more complicated than picking items.
FPA helps put a number on how much work each step requires.
Steps in Function Point Analysis:
1. Identify and Classify Functions:
 Think about what the software lets you do. Are you entering data,
getting information, or interacting with files? These are your
functions.
2. Assign Complexity Weights:
 Decide how complicated each function is. Some tasks may be simple,
while others need more effort. Give each function a complexity score.
3. Count Function Points:
 Add up the complexity scores for all your functions. This gives you
the total function points.
4. Estimate Effort:
 Now, you can use this total to estimate how much work (effort) it will
take to build or maintain the software.
Internal Logical File (ILF):
 Concept: An Internal Logical File is like a virtual cabinet where the
software keeps its own data. It's a collection of information that the software
manages and uses internally, such as a database of user profiles or a set of
records specific to the application.
External Interface File (EIF):
 Concept: An External Interface File is like a window to the outside world
for the software. It's data that the software needs, but it's not in charge of
managing it. For example, if the software needs to read or update
information in another system's database.
External Input (EI):
 Concept: An External Input is like the software reaching out to grab some
data from the user or another system. For instance, when a user enters
information into a form, and the software takes that data in.
External Output (EO):
 Concept: An External Output is like the software sharing information with
the user or another system. It could be generating a report, displaying data
on the screen, or sending information to another application.
External Inquiry (EQ):
 Concept: An External Inquiry is like the software being asked for
information without making any changes. For example, a user requests
details about a product without altering the product database.
Data Element Types (DET):
 Concept: Data Element Types are the individual pieces of information that
the software deals with. If you're managing a list of employees, each
employee's name, ID, and position would be different data elements.
Record Element Types (RET):
 Concept: Record Element Types are like folders that group related pieces of
information together. If you have a collection of data about an employee, the
employee's name, ID, and position would form a Record Element Type.
File Types Referenced (FTR):
 Concept: File Types Referenced represent the specific data collections
(ILFs or EIFs) that a process interacts with. If a process involves reading or
updating information in a user database, that database is the File Type
Referenced.
In a nutshell, ILF is where the software stores its own data, EIF is data it borrows,
EI is grabbing data from the outside, EO is sending data outside, EQ is asking for
info, DET is individual pieces of info, RET is groups of related info, and FTR is
the specific files being used. These concepts help in understanding and measuring
the size and complexity of a software system using Function Point Analysis.

Tables used in Function point Analysis:

Complexity Matrix for ILF and EIF:

DET
RET
1 to 19 20 to 50 >=51
1 low low average
2 to 5 low average high
>5 average high high

Complexity Matrix for EI:

DET
FTR
1 to 4 5 to 15 >=16
<2 low low average
2 low average high
>2 average high high
Complexity Matrix for EO and EQ:
DET
FTR
1 to 5 6 to 19 >=20
<2 low low average
2 to 3 low average high
>3 average high high

F.P Contribution of different Analysis component:

Complexity
Components
low average high
ILF 7 10 15
EIF 5 7 10
EI 3 4 6
EO 4 5 7
EQ 3 4 6

Practice Question:
1. External Input (EI): Add a Product to the Cart
 DET: 5 (Hypothetical number)
 RET: 1 (Assuming all elements are in one group)
 FTR: 1 (Internal file representing the shopping cart)
2. External Output (EO): View Shopping Cart
 DET: 4 (Hypothetical number)
 RET: 1 (Assuming all elements are in one group)
 FTR: 1 (Internal file representing the shopping cart)
 3. External Inquiry (EQ): Search for a Product
 DET: 4 (Hypothetical number)
 RET: 1 (Assuming all elements are in one group)
 FTR: 1 (Internal file representing the product catalog)
Internal Logical File (ILF): Shopping Cart
 DET: 9 (Sum of DET from EI and EO)
 RET: 2 (Assuming separate groups for cart items and product details)
External Interface File (EIF): Product Catalog
 DET: 4 (DET from EQ)
 RET: 1 (Assuming all elements are in one group)

Now first we will find complexity according to the tables given above:

EI= low
EO= low
EQ= low
ILF= low
EIF= low
Now we will allot function points based on complexity:

EI= 3
EO= 4
EQ= 3
ILF=7
EIF=5
BY adding these function points we get U.A.F (unadjusted function points):

3+4+3+7+5=22
To make them final function points we need to find TDI (Total Degree of
influence) but in this case let’s suppose it is 5
Now using TDI we will find V.A.F (value adjustment factor)
V.A.F= (TDI * 0.01) + 0.65
V.A.F= (5 * 0.01) + 0.65
V.A.F= 0.7
Now to calculate Final function points Multiply U.A.F with V.A.F
F.F.P= U.A.F * V.A.F
F.F.P= 22 * 0.7
F.F.P= 15.4
Constructive Cost Model and Regression:
The Constructive Cost Model (COCOMO) is a software cost estimation model
developed by Dr. Barry Boehm. COCOMO provides a framework for estimating
the cost and effort required for software development projects.

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 in. It is measured in the units
of time such as weeks, and months.

COCOMO classifies software projects into three categories:

1. Organic – A software project is said to be an organic type if the team size
required is adequately small, the problem is well understood and has been solved
in the past and also the team members have a nominal experience regarding the
problem.
2. Semi-detached – A software project is said to be a Semi-detached type if the
vital characteristics such as team size, experience, and knowledge of the various
programming environment lie in between that of organic and Embedded.
For example: Compilers or different Embedded Systems can be considered Semi-
Detached types.
3. Embedded – A software project requiring the highest level of complexity,
creativity, and experience requirement fall under this category. Such software
requires a larger team size than the other two models and also the developers need
to be sufficiently experienced and creative to develop such complex models.
Basic COCOMO Model:
1. Original Model:
 Basic COCOMO, or COCOMO I, is the original software cost
estimation model developed by Barry Boehm in 1981.
2. Purpose:
 It provides a simplified formula for estimating effort, duration, and
staffing based on the size of the software project in lines of code
(KLOC).
3. Effort Estimation Formula:
 The formula is Effort=a×(KLOC)b, where KLOC is the size of the
project in thousands of lines of code, and 'a' and 'b' are constants.
4. Duration Estimation Formula:
 The duration estimation formula is Time=c×(Effort)d.
5. Constants for Different System Types:
 The constants 'a', 'b', 'c', and 'd' vary based on the type of software
project (Organic, Semi-Detached, or Embedded).
Software Projects a b c d
Organic 2.4 1.05 2.5 0.38
Semi-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
6. Effort Measurement:
 Effort is measured in person-months, representing the amount of labor
required to complete the project.
7. Size Measurement:
 Size is measured in thousands of lines of code (KLOC), which is a
common metric used to quantify the size of a software project.
8. Time Measurement:
  Duration or time is measured in months, representing the time
required for the completion of the project.
9. Applicability:
 Basic COCOMO is often used during the early stages of project
planning when detailed project information is not yet available.

Intermediate COCOMO Model:

1. Purpose:
 Intermediate COCOMO is used during the early design and
development stages of a software project when the architecture is
partially defined.
 It provides more accurate estimates compared to the Basic COCOMO
model by considering additional influencing factors.
2. Factors Considered:
 Intermediate COCOMO takes into account various cost drivers and
multipliers that affect software development effort and cost.
 These factors include product attributes, hardware attributes,
personnel attributes, project attributes, and process attributes.
 Examples of attributes include database size, product complexity,
analyst capability, programmer capability, and project schedule
constraints.
3. Equations:
 The effort and duration estimation equations in Intermediate
COCOMO are more detailed than the Basic COCOMO model, taking
into account multiple cost drivers:
 Effort=a×(KLOC)b×EAF
 Time=c×(Effort)d
4. Effort Adjustment Factor (EAF):
  The Effort Adjustment Factor is a multiplier that considers the
influence of various cost drivers.
 It is calculated based on the individual ratings assigned to different
attributes.

Detailed COCOMO Model:

1. Purpose:
 Detailed COCOMO is employed for a more thorough and precise
estimation during later stages of the project when detailed information
is available.
2. Factors Considered:
 Detailed COCOMO includes an expanded set of cost drivers
compared to the Intermediate model.
 It considers factors such as personnel capability, product reliability,
complexity of the software, and the use of modern tools and
programming practices.
3. Equations:
 The effort and duration estimation equations in Detailed COCOMO
are even more sophisticated, incorporating a broader set of cost
drivers:
Effort=a×(KLOC)b×EAF×(SF)n
Time=c×(Effort)d
4. Scale Factors (SF):
 Scale factors in Detailed COCOMO represent different characteristics
of the software project.
 They include aspects such as analyst capability, software flexibility,
and team cohesion.
  Each scale factor is assigned a rating based on the project's
characteristics.

Regression and emergence of COCOMO

The emergence of COCOMO (Constructive Cost Model) was rooted in the
application of regression analysis to software project data. Regression analysis
involves examining the relationship between one dependent variable (in this case,
software project cost or effort) and one or more independent variables (project
attributes, such as size in lines of code).
Barry Boehm, the creator of COCOMO, conducted extensive research and
collected a large database of historical project data from various software
development projects. He applied regression analysis to this dataset to identify
statistical relationships between project attributes and the effort required for
software development.
The key steps in the regression process that led to the emergence of COCOMO can
be outlined as follows:
1. Data Collection:
 Gathered a comprehensive dataset from a variety of software
development projects. The dataset included information on project
size, team size, development time, and other relevant factors.
2. Identification of Variables:
 Selected variables that were believed to influence the effort required
for software development. Common variables included project size,
team size, and development time.
3. Regression Analysis:
 Applied regression analysis to the dataset to identify mathematical
relationships between the selected variables and the effort required for
software development.
 The regression analysis aimed to find coefficients and constants that
best fit the historical data, allowing for the creation of a predictive
model.
 4. Model Formulation:
 Based on the results of the regression analysis, formulated a
mathematical model that could estimate the effort required for a
software project given specific project attributes.
 The basic COCOMO model, as initially proposed, had a simple form:
Effort=a×(KLOC)b, where KLOC is the size of the project in
thousands of lines of code, and 'a' and 'b' are constants.
5. Validation and Refinement:
 Validated the model against additional project data to ensure its
accuracy and reliability.
 Continued to refine and enhance the model based on new data and
insights.
The application of regression analysis to project data allowed Boehm to create a
quantitative model that could predict the effort required for software development
based on project attributes. This marked the emergence of COCOMO as a valuable
tool for software project estimation and management. Over time, COCOMO
evolved with the introduction of Intermediate and Detailed COCOMO models,
providing more sophistication and accuracy in estimation.

Example: COCOMO I
Given Information:
 Project Type: Organic
 Size of the Project: 100 KLOC (Kilo Lines of Code)
 Constants for Organic Projects (from COCOMO I table):
 a=2.4
 b=1.05
 c=2.5
 d=0.38
Effort Estimation:
Effort=a×(KLOC)b
Effort=2.4×(100)1.05
Duration Estimation:
Time=c×(Effort)d
Time=2.5×(Effort)0.38
Example: COCOMO II
Given Information:
 Project Type: Organic
 Size of the Project: 100 KLOC
 Scale Factors (SF) Ratings:
 Precendentedness (PREC): High
 Development Flexibility (FLEX): Nominal
 Team Cohesion (TEAM): High
Effort Adjustment Factor (EAF) Calculation:
EAF=PREC×FLEX×TEAM
EAF=3.72
Effort Estimation:
Effort=a×(KLOC)b×EAF
Effort=2.4×(100)1.05×3.72
Duration Estimation:
Time=�×(Effort)�Time=c×(Effort)d
Time=2.5×(Effort)0.38Time=2.5×(Effort)0.38
Example: COCOMO III
Given Information:
 Project Type: Organic
  Size of the Project: 100 KLOC
 Rating for Additional Attributes:
 Modern Programming Practices (MODP): High
 Modern Tools (TOOL): High
Scale Factors (SF) Calculation:
SF=0.91+0.01×(MODP+TOOL)
SF=0.91+0.01×(2+2)=0.95
Effort Adjustment Factor (EAF) Calculation:
EAF=SF×PREC×FLEX×TEAM
EAF=0.95×3.72
Effort Estimation:
Effort =a×(KLOC)b×EAF×(SF)n
Effort=2.4×(100)1.05×(0.95×3.72)0.2
Duration Estimation:
Time=c×(Effort)d
Time=2.5×(Effort)0.38