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