Measuring Function Point from
Requirements/Design Specification- A Case Study of Joint Work between
Osaka University and Hitachi Co.
Katsuro Inoue
Graduate School of Engineering Science, Osaka University
Graduate School of Information Science, Nara Institute ofScience and TechnologyJapan

Map of Japan

NaraOsaka Univ./ NAIST

Osaka-u

NAISTOsaka University
70 years history
10 schools
900 million $ budget
2500 faculty members
13,000 undergraduate students
7,000 graduate students
3 computer related departments

Foil 4

Osaka Univ. SE Lab
3 faculty members– Inoue, K.
– Kusumoto, S.
– Matsushita, M.

Slicing, AnalysisMetrics, Measurement
Process, Environment

3 Ph.D. candidates, 13 master students,
5 undergraduate students
50,000$ budget annual

Foil 5

Research Focus of Osaka SE Lab.
Program Analysis and Slicing-Pascal base slicing system, Java alias analysis
system, Combining dynamic and static analysis

Software Metrics and Measurement-Function point analysis, Object oriented programmeasurement, Clone detection

Software process and development environment-Process modeling, Quality assurance framework,
Versioning file system
Foil 6

NAIST
9 years history
3 schools
90million $ budget
200 faculty members
1000 graduate students
2 computer science departments

Foil 7

NAIST SE Lab.
4 faculty members– Inoue, K. (adjunct)– Matsumoto, K. Usability, Software quality– Shima, K.
Reliability model– Monden, A
Bug analysis, Softwarewatermarking

6 Ph.D. students, 8 master students
60,000 $ budget annual

Foil 8

Research Focus of NAIST SE Lab.
Usability of Computer Systems– Analysis of human activities (eye, brain wave …),
Tracking system on Unix and Windows

Bug Analysis for Large Legacy System– Bug prediction based on complexity measures

Reliability Modeling– Multi version software, Reliability growth model

Foil 9Research Focus of Osaka SE Lab.
Program Analysis and Slicing-

Pascal base slicing system, Java alias analysis
system, Combining dynamic and static analysis

Software Metrics and Measurement-Function point analysis, Object oriented programmeasurement, Clone detection

Software process and development
environments-

Process modeling, Quality assurance framework,
Versioning file system

Foil 10

Background(1/2)
Function point analysis(FPA) :Measures functionality of application software
Issues:• FPA involves analyzer’s judgment ->instability of analysis results• High deployment cost to overall organization

Foil 11

Background (2/2)
Hitachi: Business System Development Division• Introducing FPA to various softwaredevelopment projects• An object-oriented requirement analysis
system REQUARIO has been used during therequirements analysis phase.

• Use REQUARIO document for FPA• Automated analysis

Foil 12

Function Point Analysis
FPA: Specification or design documents– Data functions• Internal and external data requirements– Transactional Functions• Represent the functionality provided to theuser for the processing of data by anapplication

USER

Input
OutputInquiryInternaldata

External
dataApplication Software
Foil 13

Data Functions•

Internal Logical File(ILF) is…
– user identifiable group of data.
– maintained within the application boundary.

•External Interface File(EIF) is…
– user identifiable group of data.
– not maintained by the application being counted.

•Each ILF or EIF has a functional complexity
based on the number of data element types(DETs) and record element types (RETs).
– DET is a unique user recognizable, nonrecursive fieldon the ILF or EIF.
– RET is a user recognizable subgroup of data elements
within an ILF or EIF.

Foil 14

Transactional Functions• External input(EI):– Processes data or control information that comes from outside
the application's boundary.

• External output(EO):– An elementary process that generates data or control
information sent outside the application's boundary.

• External inquiry(EQ):– An external inquiry is an elementary 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 file types referenced (FTRs)
and data element types (DETs).
– FTR is• An internal logical file read or maintained by a function type
• An external interface file read by a function type.
Foil 15

REQUARIO• REQUARIO is a CASE tool for visually
analyzing requirements developed inHitachi.
• Features :– Use-cases(objects + events) are visuallyrepresented.
– Users can easily develop and review the usecases.
– Use-cases are automatically translated into
the object, UML use-case and sequence
diagrams.
Foil 16

Example of REQUARIO Use-Case

Foil 17

Collaboration Goals• Hitachi:– Obtain a function point measurement toolfor REQUARIO– Industrial strength tool

• Osaka University:– Understand industrial problems– Publish papers with background ofindustrial needs

Foil 18

Overview of collaboration• Duration:– 2 years (June, 1997〜May, 1999)• Fund from Hitachi to University– 20,000 $ / annual• Staff:– Hitachi: 2 engineers (part time).
– Osaka University: 4 persons(2 students, Inoue,Kusumoto)• Meeting:– Meeting (every two months)– Day-by-day communication (via e-mail/phone/fax)
Foil 19

Progress(1997.6-1997.12)
Osaka University•Learning

Hitachi Ltd.
•Explanation– Software development– REQUARIO– Function Point•Proposal of detailed FP
measurement rules•Application of the rules tosmall example•Revision of the rules•Design of measurement
tool
Foil 20

Progress(1998.1-1999.5)
Osaka University
Development of prototypesystem.

Hitachi Ltd.

•Exhibition at ICSE’98 expoin Kyoto.
•Case study•Extension of prototypesystem.

•Exhibition at ICSE99
poster&research demo inLos Angeles
Foil 21

Measurement Tool
Developed with Visual C++ on Windows95/98
Program size : about 14000 lines
Function point counting: IFPUG counting
manual version 4.0.
Counting Tool
Requirement
Specification
byREQUARIO•Function points•Data functions•Transactional
functions

Foil 22

Counting Rules
Internal Logical File

ExternalInput

Foil 23

Example of screen

Foil 24

Example of screen

Foil 25

Case study
Applied the tool:(1) Purchase processing system(2) Order processing system(3) Stock control system
We have compared the FP values:- Function point analysis specialist of Hitachi- Our tool

Foil 26

Comparison
P : Purchase processing system
O : Order processing system
S : Stock control system

Data function
Transactional
function
Total

Function point
analysis specialistPOS

Our toolPOS

１４２９２４１４２９２４１８６３３６1544

27

３２９２６０297351

No significant difference between two analysis
results (specialist counts not described transactionfunctions)
Foil 27

Results of collaboration
・Research papers
・International conference
・Domestic conference
・Journal paper・Master thesis
・Bachelor thesis

23112

・Exhibited tool at ICSE’98 & ICSE’99
・Hitachi applied for several patents andmight integrate the FP tool into
REQUARIO.
Foil 28

Lessons learned
・Students were very motivated.
・find research theme easily.
・get the information of the actual softwaredevelopment at the company.

・It was useful to train students.
・required some results basedschedule・learning several manners

ontight・Papers based on actual data andexperience interest industry people
Foil 29

Derived Research Project
Function point measurement for UML
design specification
Collaboration with
Hitachi System Engineering, Ltd.
(subsidiary company of Hitachi)
Applied a government research fund
120,000 $ budget

Foil 30

Collaboration Issues• Start with small problems
Do not set ambitious goals atbeginning•Not consulting, equal research partner
Share ideas and labors•Do not expect short term successLong term relation, Good human relation•Find publishable theme from university side
Money is a secondary issue
Foil 31

Foil 32