Wednesday, December 8, 2010

Function Point Estimation

Function Point Estimation

Estiamtion: The dictionary meaning of Estimation - an approximate calculation of quantity or degree or worth; "an estimate of what it would cost"; "a rough idea how long it would take"

The main question is in our mind is, what is the meaning of estimation in terms of Software Industries.

The estimation in the terms of Software Industries is the expectations about the time required to complete the software/ client tasks or application.

Fundamentals of Function Points:

It is a technique to measure software size based upon the user requirements. Or we can say It is a method to break systems into smaller components, so they can be better understood and analyzed.

History of Function points

It was developed first by Allan J. Albrecht in the mid 1970s. It was an attempt to overcome difficulties associated with lines of code as a measure of software size, and to assist in developing a mechanism to predict effort associated with software development. The method was first published in 1979, then later in 1983.

In 1984 Albrecht refined the method and since 1986, when the International Function Point User Group (IFPUG) was set up, several versions of the Function Point Counting Practices

Manual have been published by IFPUG.

http://www.ifpug.org/

Challenges to estimate the software:









What’s we are looking into the picture: The upper tip of tree is not a challenge; the challenge is to think other side to imagine the deeper of roots in the soil. J

Flow of FP Estimation








EI(Exteral Inputs):

It is elementary process in which data travels from outside to inside boundary. This input data may comes from an input screen or any another application. This data may be used to maintain/update one or more ILF.

For every add/ update and delete count as one EI

Note: every Input screen is not an EI. The EI who maintain/update the ILF should be counted as EI. Query Screen, login Sc, Menu report screen cannot be counted as EI.

EO(External Output):

It is an elementary process in which derived data passes across the boundary from inside to outside. Additionally, an EO may update an ILF. The data creates reports or output files sent to other applications. These reports and files are created from one or more internal logical files and external interface file.

It also means to manipulate the data and presents to the user(derived and caluculate the information).

Eg

Balance sheet Report

Customer monthly sheet

Graphic chart.

Notes: If the same EO data is produced to the two different media output then it is count as two EO.

If report is genearated by a report generator then it is one EO.

One EI should be counted for each report command like search, sort, merge etc.

EQ(External Query):

It is an unique request for retrieving the data. The input process does not update any Internal Logical Files, and the output side does not contain derived data.

Notes: It retrieves simple information while EO retrieve complex information.

E.g. Country dropdown box is EQ.

Simple reports displayed from a single table without data manipulation.

Selection of data retrieval based on input.

EIF(External Interface Files):

It’s a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The external interface file is an internal logical file for another application.

Data stored outside the application boundary is considered as EIF

ILF(Internal Logical Files):

It’s a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through external inputs.

Data stored inside the aaplication is considered as ILF

Belwo is the tip to identify ILF:

Stored internal to the application.

Maintained through a standardized process of application

User Identified

NOTE: Temps file are not counted as ILF’s.(Should not map ILF as data base file)

Benefits:

Function Points can be used to size software applications accurately. Sizing is an important component in determining productivity (outputs/inputs).

Function Points are easily understood by the non technical user. This helps communicate sizing information to a user or customer.

Function Points can be used to determine whether a tool, a language, an environment, is more productive when compared with others.

When Not to Use Function Points

While function points have many uses, Function points is not very good measure when sizing maintenance efforts (fixing problems) or when trying to understand performance issues. Much of the effort associated with fixing problems (production fixes) is due to trying to resolve and understand the problem (detective work).

Another inherent problem with measuring maintenance work is that much of maintenance programming is done by one or two individuals. Individual skill sets become a major factor when measuring this type of work.