This section has the project scope whose estimation will be done

Function Point Analysis Project Name ILF EIF EO EQ EI Total Unadjusted Function Points Total GSC Total Adjusted Function Points Programmer can complete how much FP per day(Productivity Factor) Total Man Days Use Case Point Analysis Use Case Entity Total UAW Total UUCW Total UUCP Adjusted UCP Hours Days (By Karner Way) Comparison Between Unadjusted Function Points and Unadjusted Use Case Points Total Difference between Unadjusted Values (UUCP-UAFP) Factor Difference UAFP/UUCP Number of elements in FP EI EO EQ ILF EIF Total Elements in FP Number of Use Case in UCP Number of actors Total Elements in UCP Total Difference in Elements (FP-UCP)

<<Type in Project Name Here>> 0 0 0 0 0 0 0.65 0 0.85 0 Use Case Entity Values 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Functionality

DET

RET

Value 0 0 0 0

DET's considers

RET's considerd

Functionality DET

RET

Value 0

DET's considerd RET's considered

Functionality DET

FTR

Value 0

DET's considered FTR's considerd

Functionality

DET

FTR

Value 0 0 0 0

DET's considerd

FTR's Considerd

Functionality

DET

FTR

Value 0 0 0 0 0 0 0 0 0 0 0 0 0 0

DET's considerd

FTR's Considerd

GSC Attribute Data communications

Definitions How many communication facilities are there to aid in the transfer or exchange of information with the application or system? How are distributed data and processing functions handled? Did the user require response time or throughput? How heavily used is the current hardware platform where the application will be executed? How frequently are transactions executed; daily, weekly, monthly, etc.? What percentage of the information is entered On-Line? Was the application designed for end-user efficiency? How many ILFs are updated by On-Line transaction? Does the application have extensive logical or mathematical processing? Was the application developed to meet one or many users needs? How difficult is conversion and installation? How effective and/or automated are startup, back up, and recovery procedures? Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? Was the application specifically designed, developed, and supported to facilitate change?

Value

Distributed data processing Performance Heavily used configuration Transaction rate On-Line data entry End-user efficiency On-Line update Complex processing Reusability Installation ease Operational ease

Multiple sites

Facilitate change

GSC

0.65

Guidelines from ifpug.org CPM guide EI Counting Rules Control information is received from outside the application boundary. The control information is specified by the user to ensure compliance with business function requirements. For the identified process, one of the following two rules applies: 1) Processing logic is unique from other external inputs for the application. 2) Data elements are different from other external inputs identified. FTR Counting Rules Count each ILF maintained. Count each ILF or EIF read during processing. Count only one FTR when an ILF is both maintained and read. DET Counting Rules Count each user recognizable and nonrecursive field. Each user recognizable and nonrecursive field must be maintained on an ILF. Count each field that is not entered by the user, but through an EI is maintained on an ILF Count physical implementation techniques as a single DET for the entire group of fields. EIF Counting Rules The group of data is a logical group that fulfills specific user requirements. The group of data is referenced by, and external to, the application being counted. The group of data is not maintained by the application being counted. The group of data is counted as an ILF for at least one other application. The group of data identified has not been counted as an ILF for the application. EO Counting Rules The process sends data or control information external to the application boundary. The process is the smallest unit of activity that is meaningful to the end user in the business. The elementary process is self-contained and leaves the business in a consistent state. For the identified process, one of the following two rules applies: Processing logic is unique from other EOs. Data elements are different from other EOs. EQ Counting Rules An input request enters the application boundary. Output results exit the application boundary. Data is retrieved. The process is the smallest unit of activity that is meaningful to the end user in the business. The elementary process is self-contained and leaves the business in a consistent state. The data retrieved does not contain derived data. The processing does not update an ILF. For the identified process, one of the following two rules applies: Processing logic is unique from other EQs. Data elements are different from other EQs.

Actor Name

Weight

Description so that third person can understand

Use Case Name

Number of Transactions

Weight 0 0 0

Description so that third person can understand

Technical Factor Distributed System Response time End user efficiency Complex internal processing Reusable code Installation ease Easy use Portable Easy to change Concurrent Security objectives Direct access to third parties User training facilities

Weight 2 1 1 1 1 0.5 0.5 2 1 1 1 1 1

Value

Weighted Value 0 0 0 0 0 0 0 0 0 0 0 0 0 0.6

Total TCF

Guide lines for each factor is inside comments : Please note these are guidelines provided by me depending on my experi

Description so a third person can understand Application copies files to main back up system No special requirement as its batch process which runs at night speed is of not prime importance Simple navigation for Network administrator. There is extensive logical processing in terms of browsing through folders and files and copying them across This is first time the company is making this application so no reusable code is available and second there is no scope for reusabilit Network administrator are technical guys who can do themselves As used by network administrator no special user freindliness is needed.As network administrator are them self quiet technical guys Only should work on windows 2000 server.See assumptions for details No special requirement as such for now. No requirement as such Its in house no requirement as such No requirement as such Network administrator can understand the application by themselves

se are guidelines provided by me depending on my experience and some taken from function point guidelines itself. There is no governing bod

cond there is no scope for reusability in application itself as its too small

or are them self quiet technical guys.

itself. There is no governing body who has approved it so use it at your own risk

Environmental Factor Familiarity with project Application experience Object-oriented programming experience Lead analyst capability Motivation Stable requirements Part-time Staff Difficult programming language

Weight Value 1.5 0.5 1 0.5 1 2 -1 -1 Total EF

Weighted Value 0 0 0 0 0 0 0 0 1.4

Guide lines for each factor is inside comments : Please note these are guidelines provided by me depending on my ex

Description so that third person can understand everybody know the project very well as the requirements are very clear 20 % percent application experience people are available Have 2 years of OOPs experience Have around 2 years experience lead analyst leading the project Project beign small team has less motivation Requirements do no changes No part time staff Programming language is VB.NET

e guidelines provided by me depending on my experience and some taken from function point guidelines itself. There is no gover

uidelines itself. There is no governing body who has approved it so use it at your own risk

Use Case Look Up 0 1 2 3 4 5 6 7 8 9 10 0 5 5 5 10 10 10 10 15 15 15

These are look up values used in use case do not touch this section

Guidelines to write Use Case Use Case Scenario should be non-recursive and processing logic should be different from other Use Cases. Role / Actor should be non-recursive. Minimum User goal level use case should be indentified. If two Use Cases have 60 % in common try to accommodate them using alternate scenario. Example CRUD operation Create,Read,Update and delete should come in one Use Case with alternate scenarios. If UseCase is exceeding 25 transactions split Use Case in two UseCases. Every transaction in Use Case should add buisness value from User Perspective. Sub-function level Use Case should be used to Capture algorothmic complexity.

Mapping Rules to be followed so that Use Case Point and Function Point can be compared. Every Elementary process (EI,EO,EQ,ILF and EIF) should be mapped to a Use Case,. Comparison can only be done on Unadjusted values that is on Unadjusted Function Points and Unadjusted Use Case Points Group of Function Point EP's can map in to one Use Case.Its possible than Use Case and EP will not have one to one mapping. Every ILF and it associated EI should be mapped to a Use Case Every EIF and it associated EI should be mapped to a Use Case Actors have no equivalent mapping in EP