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 per Use Case (productivity factor for Use Case) Hours according 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)

Research Training Project 28 0 5 16 34 83 0.65 53.95 0.85 63.47058824 Use Case Entity Values 9 65 74 62.16 8 497.28 62.16 -9 1.121621622 10 1 5 4 0 20 6 3 9 11

Functionality Category Course Enquiry Marks

DET 1 5 8 2

RET 1 2 2 2

Value 7 7 7 7

DET's considers Category description Course Name , Course Description , date when course will start , end date of course, trainer name Name,First Name,Last Name,Date of birth,Address,Education details(Free text),Course Enquiry done Course, Student marks

RET's considerd Category Course , Course initiation Enquiry Name, Course enquiry Course, Students

Functionality DET

RET

Value 0

DET's considerd RET's considered

Functionality Print Certificate

DET 4

FTR 4

Value 5

DET's considered Student Name, Course Name , Marks , faculty name

FTR's considerd Marks, Students, Course, Faculty

Functionality DET Display category for update Display course details for update Display enquiry for update Display Category Dropdown Display Course dropdown

FTR 1 5 8 1 1 1 2 2 1 1

Value 3 3 4 3 3

DET's considerd

FTR's Considerd

Functionality Add Category Update Category Delete category Add course Update Course Delete Course Add Enquiry Update Enquiry Delete Enquiry Update Marks

DET 1 1 1 5 5 1 8 8 1 2

FTR 1 1 1 2 2 1 2 2 1 2

Value 3 3 3 4 4 3 4 4 3 3 0 0 0 0

DET's considerd Category description Category description Category description Course Name , Course Description , date when course will start , end date of course, trainer name Course Name , Course Description , date when course will start , end date of course, trainer name Course Name (This is a delete so will only need Course Name as input) Name,First Name,Last Name,Date of birth,Address,Education details(Free text),Course Enquiry done Name,First Name,Last Name,Date of birth,Address,Education details(Free text),Course Enquiry done Enquiry code Course , Student marks

FTR's Considerd Category Category Category Course , Course initiation Course , Course initiation Course Enquiry Name, Course enquiry Enquiry Name, Course enquiry Enquiry Course , Students for that course

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 Counsellor Faculty Admin

Weight 3 3 3

Description so that third person can understand

Use Case Name

Number of Transactions

Weight

Add/Update/Delete Category

15

Add/Update/Delete Course Master

10

Add/Update/Delete Enquiry Sheet

12

15

Add/Update/Delete Course initiation

10

Update Marks

Print Certificate

10

Description so that third person can understand Main Scenario :1) User click on Add master menu to add new categories. Master menu is seen only if the user is admin. 2) User fills in the category description. 3) If the category description is more than 50 length error message " Category description can not exceed more than 50 " is displayed. 4) After user has filled in information for category user clicks on "Add Category" and the category is added to database with message displayed "Category Added sucess fully". Alternate scenario Update Category :1) User click on Update master menu to Update existing categories. User is displayed with Categories in existing system. 2) User selects one of the categories.The details are displayed and is ready to update or delete. 3) Step 2 to step 4of main scenario is executed. Alternate scenario Delete Category :1) from step2 of alternate scenario update category , User has option to delete the information also.If he clicks on delete Category message box is popped up "Are you sure you want to delete this category". 2) If the user clicks on "Yes" the Category is delete from the Database.If the category is used in any other transaction "Category can not be deleted already in use" message is shown or else the category is not deleted from database.

Main Scenario :1) User click on Add Course menu to add new Course.Master menu for courses is seen only if the user is admin. 2) User fills in the Course Name , Course duration and date when the course will start. If the course name description is exceeds more than 50 length then error message "Course Name can not exceed more than 50 length is displayed". 3) Course duration is pure numeric and Course date should equal to more than todays date. Alternate scenario Update Course :1) User click on Update Course menu to Update existing Course definition.User is displayed with existing Courses.User selects one of the Courese.The Course details are displayed and is ready to update or delete. 2) Step 2 to step 3 of main scenario are executed. Alternate scenario Delete Course :1) From step2 of alternate scenario Update course , User has option to delete the Course information also.If he clicks on delete Course message box is popped up "Are you sure you want to delete this Course". 2) If the user clicks on "Yes" the Course is deleted from the Database.If the Course is used in any other transaction "Course can not be deleted already in use" message is shown. and if user selects "NO" for deleting the Course the Course is not deleted from the database.

Main scenario :1) User clicks on Add enquiry sheet. Enquiry sheet is only seen to if you are a counsellor or admin.Courses are displayed in dropdown. 2) User fills in Name,First Name, Last Name. 3) User fills in DOB,Address details. 4) User fills in education details. 5) User selects the course enquired from the dropdown and adds the course. 6) if the enquiry is for more course step 5 is repeated. 7) User then updates to database.If the user has not filled in Name and one course atleast programe displays "Name and Enquiry is compulsory can not proceed" or else the program updates the values to database. Alternate scenario 1:1) Counsellor Selects the enquiry by putting the enquiry number. 2) if the enquiry number is not present then program displays no enquiry number present or else relevant information is displayed to the user. 3) Counsellor then can repeat step 2 to step7. Alternate scenario 2 :1) Step 1 to 2 of alternate scenario is executed 2) Counsellor then has option to delete the enquiry.The enquiry will not be deleted if the enquiry is turned in to course. Main scenario 1) Counsellor selects enquiry by putting enquiry number. All details of enquiry is seen to the counsellor. 2) Counsellor then fills in course name, trainer name., start date and end date. 3) After filling the above information counsellor updates the Course against the enquiry. Alternate scenario update course : 1) Counsellor can pull the enquiry by either putting enquiry number or course number. 2) Step 2 to 3 is the followed of the main scenario Alternate scenario Delete 1) Step 1 of the alternate scenario update course is executed.User then has option to delete the course details attached with the enquiry. 2) Course is not deleted if certificate is issued for the course. Main scenario : 1) Faculty inputs course number , user is prompted with name of student and textbox to input marks for every student in that course. 2) Faculty inputs marks for the students and clicks update. Main scenario :1) Faculty enters course number , all students and there relevant marks information is displayed. 2) Faculty then selects the students whose certificate has to be printed. 3) Faculty then selects the printer on which he wants to print the information. 4) Program then takes the print structure and prints the certificate.

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 steps are repeating accommodate with executed clause. 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