Expt no.

06

AIM: COCOMO model and Function point for given system

Airline Reservation
COST ESTIMATION OF THE PROJECT
I have used the COCOMO model for estimating the cost of the system .It is regarded as a
semidetached system. Since this project is somewhat small, COCOMO estimate might be
inaccurate. COCOMO is designed for use on system larger than 2 KDL.This model
estimates the total effort in term of person-month of technical project staff. It does not
include the cost of the secretarial staff that might be needed. The basic steps in this model
are:
(1) Obtain an initial estimate of the development effort from the estimate of
thousands of delivered lines of source code (KDL).
(2) Determine a set of multiplying factor from different attribute of the project.
(3) Adjust the effort estimate by multiplying the initial estimate with the entire
multiplying factor.

COCOMO MODEL :
The Constructive Cost Model known as the COCOMO Model, has been designed in
1981 by Barry Boehm, to give an estimate of number of man months it will take to develop a
software product. The model also estimates the development schedule for the project in
months and gives us a schedule distribution for all the major phases of a project.
The COCOMO models are developed for three classes of software projects. They are as
follows:
Organic Projects - These are relatively small and simple software projects inwhich small
teams with good application experience work towards a set of less than rigid requirements.
Semi Detached Projects These are intermediate size software projects in which teams
with mixed experience levels must meet a mix of rigid and less than rigid requirements.
Embedded Projects These are software projects that must be developed within a set of
tight hardware, software and operational constraints.

The Airline Reservation System project has an average complexity and fair flexibility. Thus,
this project is classified as an organic project under the COCOMO model.

The equations as they are modified for the organic projects are as follows:
Effort = 3.2 * EAF * (Size) ^ 1.05
Time = 2.5 * (Effort) ^ 0.38 where
Effort = number of staff months (PM)
EAF = effort adjustment factor
Size = number of lines of code for completed product. It is measures in KLOC (thousands
of lines of code)
Time = total number of months CIS 895 Airline Reservation System Project Plan

The adjustment factors for the Airline Reservation System are as follows :
RELY as nominal with a value of 1.00
DATA as nominal with a value of 1.00
CPLX as low with a value of 0.75
TIME as nominal with a value of 1.00
STOR as low with a value of 1.00
VIRT as nominal with a value of 1.03
TURN as low with a value of 0.88
ACAP as high with a value of 0.9
AEXP as nominal with a value of 0.9
PCAP as nominal with a value of 0.9
VEXP as nominal with a value of 1.00
LEXP as nominal with a value of 1.00
TOOL as high with a value of 0.9
SCED as nominal with a value of 1.00
With the help of above stated values, the EAF for the Airline Reservation System project is
calculated as EAF = 0.45. Also by estimating the size of the project we have the value 3.0.

Since we already have the formulae for Effort and Time, we can calculate the values as
follows:
Effort = 3.2 * 0.45 * 3.0 ^ 1.05 = 4.56 staff months
Time = 2.5 * 4.56 ^ 0.38 = 4.44 months (development time)

Function Point:
A function point is a unit of measurement to express the amount of business functionality an
information system provides to a user. Function points are the units of measure used by the
IFPUG Functional Size Measurement Method. The IFPUG FSM Method is an ISO
recognised software metric to size an information system based on the functionality that is
perceived by the user of the information system, independent of the technology used to
implement the information system. The IFPUG FSM Method (ISO/IEC 20926 SOFTWARE
ENGINEERING - FUNCTION POINT COUNTING PRACTICES MANUAL) is one of five
currently recognised ISO standards for Functionally sizing software.
Function Points are units of measure for functional size as defined within the IFPUG
Functional Size Measurement (FSM) Method and it is the major global functional sizing
methodology.
FP is a standard method for quantifying the software deliverable based upon the user view,
where:

User is any person or thing that communicates or interacts with the software at any
time

User View is the Functional User Requirements as seen by the user

Functional user requirements describe what the software shall do, in terms of tasks
and services.

It is also important to keep in mind that function points look at the logical view, not the
physical. So things like coding algorithms, database structure, screenshots of transactions are
not counted.
Things that are counted within the Function Points methodology:

Input files and input transactions (batch interfaces)

Screens (adds, changes, deletes)

Control Information

Internal Logical Files (tables, files with data, control files)

External tables and referenced files from other applications

Output files and transactions (batch interfaces)

Other outputs - reports, files, dvd's, views, notices, warnings

Benefits :

The use of function points in favor of lines of code seek to address several additional issues:

The risk of "inflation" of the created lines of code, and thus reducing the value of the
measurement system, if developers are incentivized to be more productive. FP advocates
refer to this as measuring the size of the solution instead of the size of the problem.

Lines of Code (LOC) measures reward low level languages because more lines of
code are needed to deliver a similar amount of functionality to a higher level language.
[5]
C. Jones offers a method of correcting this in his work.[6]

LOC measures are not useful during early project phases where estimating the number
of lines of code that will be delivered is challenging. However, Function Points can be
derived from requirements and therefore are useful in methods such as estimation by
proxy.