Transcript Function Point Measurement for Requirements

Function Point Measurement from
Java Programs
Shinji Kusumoto+, Masahiro Imagawa+, Katsuro Inoue
Shuuma Morimoto$, Kouji Matsusita$, Michio Tsuda$
+Osaka University
$Hitachi System & Service, Ltd.
+
Background(1/3)
Function point analysis(FPA) was proposed to
help measure the functionality of the
application software.
effort
(person-months)
300
0
2000
FP
Foil 2
Background(2/3)
Issues:
• Since FP counting involves judgement on the
part of the counter, some difference for the
same product would be caused.
• In order to introduce FPA to an organization,
it is necessary to count FP from the software
developed in the past as experience data.
Foil 3
Background (3/3)
• Automatic FP measurement from objectoriented software.
– FP measurement tool from UML diagrams*
• Demand to measure function point from
source code.
– Functional differences between
requirements/design specification and
source code.
– Existence of source code without
specifications.
* T. Uemura, S. Kusumoto and K. Inoue: ``Function point analysis for design specifications
based on the Unified Modeling Language'', Journal of Software Maintenance and Evolution,
Vol. 13, No. 4, pp.223-243 (2001).
Foil 4
Objective of the reserach
• We examine the possibility to measure function
point from source code automatically.
– Propose measurement rules to count data
and transactional functions from object
oriented program based on IFPUG method.
– Develop the function point measurement tool
based on the rules.
– Apply the tool to practical Java programs in
Hitachi Systems & Services
Foil 5
Function Point Analysis
FPA is a technique that functions are classified into
the following element, and then measures the
functionality.
– Data function
• Internal and external data requirements
– Transactional function
• Represent the functionality provided to the
user for the processing of data by an
application
USER
Input
Output
Inquiry
Internal
data
External
data
Application Software
Foil 6
Definition of Data Function types
• Internal Logical File(ILF) :
– user identifiable group of data.
– maintained within the system.
• External Interface File(EIF) :
– user identifiable group of data.
– not maintained by the system.
• Each ILF or EIF has a functional complexity
based on the number of data of it.
Foil 7
Definition of Transactional Function types
• External input(EI):
– processes data that come from outside the
software.
• External output(EO):
– generates data sent outside the software.
• External inquiry(EQ):
– is a process made up of an input-output
combination that results in data retrieval.
• Each EI, EO or EQ also has a functional
complexity based on the number of data
processed.
Foil 8
Key Idea (1/2)
• It is difficult to judge the types of functions only
from the static information of source codes.
• We use the dynamic information collected from
the program execution based on a set of
testcases which should correspond to all
functions of the target program.
– Testcases for acceptance test
Foil 9
Key Idea (2/2)
classA
message
classB
classC
classD
• It shows an interaction, which is a set of
messages exchanged among the classes, like
a sequence diagram. We call this kind of
sequence as method calling sequence.
• We measure FP by analyzing the messages
and the information of the classes in the
sequence constructed by each testcase.
Foil 10
Counting Data Function Types(1/2)
•
From our previous experience most classes on
the object-oriented requirements/design
specification directly corresponded to data
functions.
•
We assume that the function point analyst
select the classes that would be the data
functions from the program.
Foil 11
Counting Data Function Types(2/2)
•
Classify DF into two types:
– ILF: During the program execution, the
classes some of which methods are called
with some arguments are regarded as ILF.
– EIF: Other classes that are not regarded as
ILF, are regarded as EIF.
classX
classY(DF)
Y.method (arguments)
Foil 12
Counting Transactional Function Types(1)
•
•
Regarding the classes as data functions, the
method that updates or refers to the data in
the class can be used to extract the
transactional function.
Basic element in the method calling sequence
– Sub-method calling sequence where a
method, that is defined in a data function
class, is called by other class.
classA
classB(DF)
B.method
classA(DF)
classB(DF)
B.method
Foil 13
Counting Transactional Function Types(2)
• Step1:
– Calculate the method calling sequences for
all testcases.
– Set application boundary (classes whose
methods are inevitably called when the user
input some data. ex. GUI classes or Java
Servlet classes )
classA
(Boundary
class)
classB
classC
classD (DF)
D.method
Foil 14
Counting Transactional Function Types(3)
Step2:
– Extract the method calling sequences where
the basic element is appeared.
classA
classB
classC
classD (DF)
D.method
Foil 15
Counting Transactional Function Types(4)
Step3:
Identify the type of transactional functions:
(1)External Input (EI) is the sequences that include
the following pattern.
classA
(Boundary
class)
classB
classC (DF)
C.method(X)
Foil 16
Counting Transactional Function Types(5)
(2) External Output (EO) is the sequences that
include the following pattern.
classA
classB
(Boundary
classC (DF)
(halfway
class)
class)
C.method(0)
(3) External Inquiry (EQ) is the sequences not
satisfying the above pattern.
Foil 17
FP measurement tool (1/2)
Java
Programs
Syntax
Analysis Unit
Test
Case
Execution
Unit (JVMPI)
Syntax
Information
File
Execution
Log File
Data Function
Class
Boundary
Class
FP calculation
Unit
FP
results
Foil 18
Screen of FP measurement tool
Foil 19
Case study(1): Target application
Target application is a typical Web application that has
been developed based on the object oriented approach.
Database server
Application server
Java Program
Web server
Brow
serﾞ
Java
Java Servlet
Servlet
Components
for
DB access
Ｊ
Ｄ
Ｂ
Ｃ
Ｏｒａｃｌｅ８ｉ
HTML
HTML
HTML
ＣＳＶ
HTML
HTML
We compare the FP values by our tool with ones by
a Function Point specialist of Hitachi System &
Services, Ltd.
Foil 20
Case study (2) Result
Data
function
Transactional
function
FP total
Tool
Specialist
ILF
11
4
EIF
1
7
EI
9
6
EO
13
14
EQ
0
0
174
170
Foil 21
Case study (3) Analysis of DF
• By selecting the classes, that conceal the access to
database, as data functions, the number of data
functions are quite similar.
• The classification result of data function types are
different between the tool and the specialist.
– The result is due to the fact that most methods in
the data function class have arguments.
• It is necessary to revise the classification rule. For
example, if the argument of the method in a class
indicates the meaningful data, the class is regarded
as ILF.
Foil 22
Case study (4) Analysis of TF
• Both the number of transactional functions by
the tool and the specialist are quite similar.
– Each of the transactional functions counted
by the specialist was also counted by the
tool.
• The tool counted two transactional functions
excessively.
Foil 23
Example
classX
(Boundary class)
classB
classC(DF) classD
classY
(Boundary class)
classB
classC(DF) classD
(1)
(2)
Foil 24
Conclusions
•
We have examined the possibility to measure
function point from source code automatically.
– Proposed measurement rules.
– Developed the FP measurement tool.
– Applied the tool to practical Java programs.
•
It is necessary to
– apply the proposed tool to other programs
which include EQ.
– revise the rule of the classification of each
function .
Foil 25