Function Point Counting - Hard Lessons Learnt

Transcription

1 Function Point Counting - Hard Lessons Learnt Faustin Moses Rethinam/ Ajay Verma/ Swaminathan Subraman Productivity Center of Excellence India Development Center Accenture

2 Agenda Function Point Counting - Challenges Challenge #1: COTS - Reusable Components Challenge #2: Package Application Challenge #3: Enhancements of Packaged Applications Challenge #4: Interfacing of Applications with Legacy Systems Productivity 2

3 Function Point Counting Challenges Counting complex applications Increasing demands for quicker turnaround Productivity pressure Adherence to CPM rules in tricky situation while counting projects 3

4 Challenge #1 - COTS -Reusable Components Definition: COTS are software components which are acquired from an independent third party for providing certain functionality. It can be in form of packages, dlls or executables. Challenges: How to count application which uses COTS components? Scenario 1: Integrated with the application package and deployed Scenario 2: Resides in Services form and called on demand. 4

5 Challenge #1 - COTS -Reusable Components Scenario #1 : Integrated with the application package and deployed Functional Overview A set of Business Logics have been written as Functions/Methods in an executable formats (exe) or Linking Libraries (DLL). All these are integrated with the application. The DLL has 100 functionalities to offer. Reusable Components Inside Application Boundary Application 5

6 Challenge #1 - COTS -Reusable Components Suggested Solution: Once when the FP Counters are asked to count the APP A after the implementation The following queries that may arise: Can we include the Reusable components into Application Boundary? If Yes, Can we count the functionalities provided by the Reusable component? If Yes, Do I have to count all the DLL Functionalities or only those which are called? 6

7 Challenge #1 - COTS -Reusable Components Look at the user requirement rather than the way it is implemented Require ments User Output Serving Application Include the Reusable Components in the Application Boundary. Count only those functionalities of the DLL which are used by the Application s provided transactions. 7

8 Challenge #1 - COTS -Reusable Components Scenario #2 Functional Overview: A set of Business Logics might have been written as Functions/Methods called services (WEB SERVICES for example) and exist in a different application and serve to multiple applications at a same time. Problem Statement Defining Application Boundary on this scenario can be a challenge to include or exclude these reusable components. Services App 1 App 2 App 3 App 4 8

9 Challenge #1 - COTS -Reusable Components Resides in Services form and called on demand. Outside Application Boundary Reusable Components Application 9

10 Suggested Solution Challenge #1 - COTS -Reusable Components The Service is outside Application Boundary. And the counting methodology will be as follows, Exclude the Reusable Components (External Services) from the Application Boundary. Count the functionalities of the services which are appropriate and called from application for its service. 10

11 Challenge #2 - Package Applications Package applications offer business solution-in-a-box. Most of the functionalities offered by the package software can be enabled or configured easily without minimum effort. The package also provides the flexibility of customizing certain functionality. Don t count the whole package Packaged Applicatio n Customizing to Partial Partial Customized App to the Customer Count only the customized App 11

12 Challenge #2 - Package Applications Usage: Count only the functionalities which have been customized to the users. Most of the Packaged Applications include more number of FP, but a typical customer organization may only use Part of it. 12

13 Problem Statement Challenge #2 - Package Applications Identifying files or tables maintained in the data repositories of packaged applications In package applications, tables structures are predefined and inbuilt. The applications which are built on top of these packages do not alter the structure of the table, it only either uses the fields or leave it unused. Field 1 Field 2 Field 3 Field 4 Field 5 Field 6 Field 7 Field 8 Field 9 Field 10 Used Fields Unused Fields The project normally requires customization i.e. putting one of such fields on the screen or building the screen using one or more of the existing views. There is no coding effort needed. 13

14 Solution Area Challenge #2 - Package Applications For the Data Functions, only count the "logical" files and NOT the "physical" tables. Count only the DETs (fields/columns) that cross the application boundary that the user recognizes. For example, if the user requirement is to remove the maintenance of a field because their particular implementation does not use it, then DET no longer maintained within the application boundary should be removed from its corresponding file 14

15 Challenge #2 - Package Applications While customizing the application to user requirements, DETs removed from screens potentially result in changes to the logical files as well as the transactions (screens). Though the package applications comes with preconfigured tables, if any customization results in maintenance of an unused field, count the ILF as a changed ILF. Such fields/columns once defined to have business meaning become additional DETs crossing the application boundary and therefore contribute change to both the data and transactional functions. 15

16 Functional Overview Challenge #3 - Package Applications Enhancements of packaged applications As we all know, Packaged Applications would have different modules, however majority of the projects implemented using these application will not be using all the modules. Problem Statement: Do we need to count packaged applications at the module level or at The application/ project level? Solution Area You can count FP for Packaged Applications just as you count for others. But decide on what you are sizing (i.e.) for most of the projects you wouldn't be creating new ILF. 16

17 Challenge #3 - Package Applications Enhancements of packaged applications Function Point Counter always encounter two problems while dealing with the package Applications: 1. ILF / EIF Identifying ILF/EIF can be challenging due to the following reasons: End users are unaware of the underlying logical data structure The project document does not captures the Entity Relationship Data Model in detail Suggested Solution: If DBA is assigned to the system, it may be helpful to understand users logical view of files. If not, you may use programmers as Subject Matter Experts for the files. They may have difficulty trying to see the files through the eyes of an end user and you'll have to guide them. Imagine the data is all in First Normal Form: One Fact in One Place. 17

18 Challenge #3 - Package Applications Enhancements of packaged applications Identification of Functionality Used: Identifying Transaction can be challenging due to the following reasons: The package application provides many functionalities, Identifying the subset of transaction used in the application being counted The user requirements are not documented as clearly as it would have been in case of an In-house developed application Solution: Count only the functions they are using to satisfy their business requirements, not the whole package. To perform an accurate FP count of Packaged Applications, it is absolutely essential to work with end users as Subject Matter Experts for the transactional functions. Apart from programmers it is better to reach out to SME to understand the functionality better from business perspective Reading the user manual and discovering useful functions that are applicable to the application Counter should have a high level understanding of the Packaged applications. 18

19 Challenge #4: Interfacing of Applications with Legacy Systems What are interfaces/middleware application? Interfaces are connecting applications with some Business Logics to transfer data from one application to the other. This interfacing methodology is mostly used when Legacy Applications are interfaced to transfer data to other Applications. These applications do not store the data permanently in its database, the data is retained only for the session. Data & Transactional Functions issues: All the Interface Applications will have Staging Tables which hold data temporarily to manipulate and to produce the final output data to the other Application. Here we need to be very careful about the scope of the FP Count: Problem Statement Is it to count only Interface Application Is it to count Interface Application along with the clients 19

20 Challenge #4: Interfacing of Applications with Legacy Systems Scenario #1: Scope is to count the Interface Application. If the application receives the data, manipulates and sends the data to the other application in a sequential manner, all the transactions will be categorized as External Output as the primary intention of the transaction is to present the information outside the application boundary (Online) Otherwise (Batch) The External Applications which gets data (Outbound) will also be treated as outside of your Application Boundary hence the storing data is not being performed by the interface. All the Outbound data can be considered as External Output (EO) if the data being produced after calculation or satisfying any criteria for EO according to CPM. The Staging Tables of the Interface Applications can be treated as ILFs though the data are not being stored permanently. But we can consider the staging tables as ILFs since it stores the transactional data for the counting application. 20

21 Challenge #4: Interfacing of Applications with Legacy Systems Scenario #2: Scope is to count the Enhancement of an Application which interfaces with the Interface Application Treat the Interface Application as Outside of Application Boundary of the application being counted Count the transactions using which the data is being sent to the interfacing application as an EQ or EO Count the transactions using which the data is received from the interfacing to maintain the ILF as an EI 21

22 Challenge #4: Interfacing of Applications with Legacy Systems Case Study: Consider there is an Interface A which is interacting with two applications B & C. We will discuss the counting scope of App A, B & C. F F APP B F F Interface APP A APP C Inbound to Interface from App B & C (Through Flat File) Outbound of Interface to App B & C (Through Flat File) 22

23 Challenge #4: Interfacing of Applications with Legacy Systems When Counting APP B Consider Application A and the Interfacing Application outside the application boundary Don t count Flat file as EIF. Inbound to APP B from Flat File is EI (External Input) Outbound to Flat File from APP B is EO (or) EQ depending on the Logic. When Counting APP C Same as Counting Application B. When Counting Interface Application A Application B & C are outside Application Boundary. Staging Tables of Interfacing Application A will counted as an ILF. Inbounds will be EI (External Inputs) Outbound will be EO (or) EQ. 23

24 Thank You 24