Software Estimation using Function Point Analysis:

Difficulties and Research Challenges

Basavaraj M.J Dr. K.C Shet
Perot Systems, Bangalore, Karnataka-India Professor, Computer Department, National Institute of Technology
[email protected]; Karnataka, Surathkal,
[email protected] [email protected] ; [email protected]

ABSTRACT Tracking System should require as installation pre-requisites is

Function Point Analysis method serves better efficient way of a Windows 2000 machine with MS Office installed. A normal
predicting estimation in beginning phase of software desktop running the DTS should serve multiple projects
development life cycle(SDLC). Size and complexity of the simultaneously.
software can be derived by function point analysis method.
Difficulties of estimation using LOC(Lines of Code) can be 2.1 Functional Requirements
avoided using Function Point Analysis, since it deals directly 2.1.1 Testing Defects
with functions or requirements and independent of language or 2.1.1.1 Enter New Defect : This is the main defect
technology. This paper explains how to calculate Function entry screen, the fields that need to be captured are shown in
point analysis for the case study Defect Tracking the figure below.
System(DTS) by using function point analysis. Defect
tracking system(DTS) case study has been taken from “XYZ”
company. In the intention of maintaining confidentiality,
authors are not disclosing the company name. Authors also
discusses difficulties and challenges by using Function Point
Analysis as part of their Research Work.

1. Introduction

Function Point Analysis was developed by Allan J. Albrecht

in the mod 1970s. Function points are independent of
language, technology, tools and database. Reestimate can be
easily achieved by function point since function points are
directly linked with change of requirements. Function point
analysis can be done at the beginning stage of software
Fig1. Testing Defect Entry screen
development life cycle(SDLC), so that development
estimation effort can be predicted at each stage of requirement
2.1.1.2 View Defect ID : In this screen the user enters
phase or design phase.
the Defect ID known to him. On submitting this, if this is a
valid defect, the details of the defect are displayed.
2. Case Study – Defect Tracking System 2.1.1.3. Query : This screen presents a range of query
options. The user can filter the entire list of records for
The Defect Tracking System will be a web application various criteria.
that serves as an aid to managing the testing cycles in software
projects. It presents a simple yet effective interface to log
defects and provides for workflow management of the defect
life cycle right through the typical processes of assigning,
fixing and closing a defect.
The DTS will be low cost, and use simple and easily
accessible technology, without demanding a high learning
curve on the part of the users. The solution shall be low cost,
and implemented in quick time. The preferred platform is
Microsoft ASP and MS Access. Reporting can be done
Fig 2. Query screen
through MS Excel pivot tables, and thus all the Defect

111
T. Sobh (ed.), Innovations and Advanced Techniques in Computer and Information Sciences and Engineering, 111–116.
© 2007 Springer.
112 BASAVARAJ AND SHET

2.1.2 Review Records : 2.1.2.4 Review Status : When the user ends the review
Review Record entry : This Captures the Review Record session, he has to enter the following details:
report.
2.1.2.1 Enter Review Record Header : The fields that
should be captured are given below

Fig 6. Review status entry screen

2.1.2.5. Review Record View : User enters the ID of a

Fig 3. Enter Review record Header Screen valid review record and it will be displayed
2.1.2.6 Review Record Query : User is given query
2.1.2.2 Enter Review Defects: The user adds review criteria to select similar to defect query. The query fields are
defects one by one. The fields to be captured are: given below.

Fig 4. Enter Review Defects Screen

Fig 7. Review Record Query Screen
2.1.2.3 Review Record Report : As each record is
submitted, the screen should be refreshed so that the review 1. On a successful log in the user will see the test
record report is built as shown below. The defects will be defects entry screen by default.
automatically assigned to the author. The phase differences 2. The user should have a navigation menu so that he
and totals of the defect severity are totaled and summarized can access the different screens easily.
automatically. 3. The user should be able to submit an attachment for a
defect, e.g. screen shots, or a detailed write-up.
4. To reduce data entry load of the user, commonly used
default values should be populated in the entry fields
wherever possible, e.g. today’s date.
5. Date entry should be made easy with a calendar
popup function.
6. Defects will be of status “New” as soon as entered.
The different status changes depending on the defect
status like assigned, on hold, dropped, etc.,
7. Defect history should be maintained and tracked.
8. Flexible reports generation using MS Excel
9. There will be an administrator role for DTS. This
user can edit defect details after they are committed
Fig 5. Review Record to the system. He can also edit review records.