You are on page 1of 8

1

Full Function point Analysis




Table of Contents

Full Function Point Analysis .........................................................................................................3
overview .......................................................................................................................................4

Steps to count Full Function Points ..............................................................................................5
Types Of Processes .....................................................................................................................6
Schematic Representation Method ..............................................................................................7

Bibliography...8






2





INTRODUCTION

Software is a major component of many corporate budgets. Organizations recognize the
importance of controlling software expenses and analyzing the performance of the
amounts allocated to software development and maintenance in order to benchmark
against the best in the field. To do so, measures and models using these measures are
needed.

Measures are needed for analyzing both the quality and the productivity associated with
developing and maintaining software. On the one hand, technical measures are needed to
quantify the technical performance of products or services from a developers viewpoint.
Technical measures can be used for efficiency analysis; to improve the performance of
designs, for instance.

On the other hand, functional measures are needed to quantify the performance of
products or services from a users or owners perspective; for productivity analysis, for
instance. Functional measures must be independent of technical development and
implementation decisions. They can then be used to compare the productivity of different
techniques and technologies.

Function Points Analysis (FPA) is an example of a functional measure. Where it has been
used extensively in productivity analysis and estimation. It successfully captures the
specific functional characteristics of MIS software. However, FPA has been criticized as
not being universally applicable to all types of software

A problem with the function point approach is that it assumes a limited band of
application types: typically, large file-based systems produced by agencies such as banks,
building societies and retail organizations, and is unable to cope with hybrid systems such
as the stock control system with a heavy communication component.

It is therefore held that FPA does not capture all the functional characteristics of real-time
software. When FPA is applied to such software, it does, of course, generate a value, but
this value does not constitute an adequate size measurement. Thus, until the release of
FFP version 1.0 in September 1997, there was no FPA equivalent with detailed
measurement procedures for real-time software.

3

Full Function Points (version 1.0) was proposed in 1997 with the aim of offering a
functional size measures specifically adapted to real-time software. Full Function Points
not only has the ability to capture the functional size of real-time software, but also to
capture the function




Full Function Points -an overview
FFP is an outcome of papers by researchers at Software Engineering Management
Research Laboratory and the Software Engineering Laboratory in Applied
Metrics
Full function point approach is one major effort to adapt FPA for use in real-time
systems because function points are not suitable for some types of systems, like
real-time systems
In real-time systems, the software is on-line and available continuously
The system executes almost instantly, at the boundary of the processing limits of
the central processing unit, and generates event-driven outputs almost
simultaneously with their corresponding inputs
Examples of real-time systems include satellite communications, radar systems,
missile guidance systems, etc
In real-time systems, in addition to typical MIS (management information
systems) type of processes, we also have control processes
4

There are also a large number of single occurrence control data, where there is
only one occurrence of data in the whole application .the type of data that does
not fit the ILF/EIF classification of normal FPA
In order to cater to the peculiarities of real-time software, we add new data
function types and transaction function types suited for control processes

>The approach is that processes could be
Managerial (counted by normal FPA)
Control (counted using FFP)
Steps to count FFP are broadly
Identify the processes performed by the application from the functional
perspective
For each identified process, identify whether the process is managerial or
control
Identify sub-processes depending on the type of process and apply the
corresponding factors
Obtain the total count


5





Types of processes and sub-processes in FFP
New data function types Control processes
Updated control group control data that can be updated by the
application (directly or indirectly) to control the behavior of a
device
Read-only control group control data used by application but
not updated
New transaction function types
External control Entry receive data from outside application
External control Exit send control data outside application
Internal control Read read a group of control data
Internal control Write write a group of control data


6




7



8

Bibliography
1. Agarwal, R.; Kumar, M.; Mallick, Y. S.; Bharadwaj, R. M.; Anantwar, D.: Estmating
software projects. Software Engineering Notes, 26(2001)4, pp. 60-67
2. Arifoglu, A.: A Methodology for Software Cost Estimation. Software Engineering Notes,
18(1993)2, pp. 96-105
3. Choi, J.: A Model for Estimating Software Size for Large-Scale Business Applications. In:
Dumke/Abran: Current Trends in Software Measurement, Shaker Publ., Aachen,
Germany, 2001, pp. 300-324
4. Garmus, David: Software Project Estimation Principles, Data Manager, February 1998

You might also like