FPA counting of web-services

[Ilie Boarescu]

I’m writing to you in regards to the method we should use when counting FPA in projects that use web-services. Maybe you can help me with some insight.
I will describe two hypothetical scenarios in order to explain the situation.

1. Standard scenario – no web services

Requirements:
The user must be able to create, view and edit Product information. In this situation we would count:

Transaction	Type	Complexity	Function points
Product	ILF	Low	7
Create Product	EI	Average	4
View product	EQ	Average	4
Edit product	EI	Average	4
Total			19

2. Our scenario – web services must be used

Requirements:
The user must be able to create, view and edit Product information.
The data about the product is stored in another application. The application to be developed must send and retrieve data via web-services.

In this situation, we can consider that the second application that stores the Product information is a second user.
We count a transaction for every set of data that crosses the boundary of the application.

Transaction	Type	Complexity	Function points
Create Product	EI	Average	4
Request: Create product	EQ	Average	4
Reply: Create product	EI	Average	4
View product details	EQ	Average	4
Request: Product details	EQ	Average	4
Reply: Product details	EI	Average	4
Update product details	EI	Average	4
Request: Update product details	EQ	Average	4
Reply: Update product details	EI	Average	4
Total			36

Is this approach correct? What kind of experience do you have with this kind of situations?

[Martin Jacobs]

Hello Ilie,

I treat a situation like this as noted below.

• Point of departure: Nesma FPA.

Standard scenario
Here we have one system and one system boundary to consider. Count this as stated.

Web services
Here we have two systems and two system boundaries to consider (we do not consider possible ESB as independent system in between for this example).

Systems:
• Frontend (FE) for the end user
• Backend (BE) for the data storage

The FE sends messages to BE and receives messages from the BE. The web services handle the messages and are part of the FE. The FE can be considered as a user of the BE (the FE has the lead).
System to be counted is the FE, assumption is that the BE exists and doesn’t change.

Based on this we can state that:
• The FE has no ILFs, they are in the BE.
• The web services do not have their own boundary.
• BE: nothing to count.
• To count: only the FE including the web services.

So in the FE we are looking for transactional functions. A transactional function is a unique, elementary function from user point of view. Take into consideration that the messages to and from the BE are not elementary. They are part of the user transactions.

So we count:
• Create Product EI Average 4
• View product EQ Average 4
• Edit product EI Average 4
Total 12
In your 2. Our scenario, you also don’t count for the second application, as you consider it as a user. So you consider the messages from that user as unique, elementary functions. According to Nesma definitions (e.g. 7.1) they are not elementary however, so they should not be counted.

If the BE does change, then messages and/or ILFs should be counted, for this BE, still not for the FE.

Hope this helps!

Regards,
Martin Jacobs
QSM Europe

[EdwinvanGorp]

Hello Ilie,

This is not an easy question to answer.

First of all: With FPA you measure the size of the functionality that an application provides to a user (Nesma guidelines; v2.1; section 3.1.2).

Now, let’s add a third scenario.
Requirements:
The user must be able to create, view and edit product information.
The data about the product is stored in another application, directly by the application that needs to be measured.

In scenario 1, you have an application with the size of 19 FP.
In scenario 3, the application does exactly the same from the end users point of view (the user that must be able to create, view and edit product information). So, in both scenario’s this user is offered the exact same functionality. This means that the size of the functionality (from the end users point of view) in both scenarios should be the same (in this case: 19 FP).

Now my question is: what is, logically, the difference between your scenario 2 and my scenario 3?
The webservices mentioned are part of the first application and are able to store and edit the data directly in the logical file, so there is no difference at all. And that means that the functional size of the first application is still 19 FP, whether it uses webservices or not (websevices are a technical implementation of the required functionality).
Or, to put it differently, the requirements that the end user has do not change when you decide to use webservices to meet these requirements.

[Alexander Vermeulen]

So Martin and Edwin,What to count for developing of the webservices in the backend BE?

Let’s say that the BE allready has the product tables in place, but don’t have the webservices for providing the functionality to support Front End?
For this the BE will get 3 webservices:
* CreateProduct
* GetProduct
* UpdateProduct

What to count for that functionality?

[SueHannan]

Hi, please tell me in Scenario 3, is the application being sized own the product file? Then in that case I can see the sizing to be the same. However, if the product file is owned by an application outside the system being counted it would be considered an EIF and therefore change the size.

I clearly see though how scenario 1 and 2 in the first conversation would result in the same 19 FP’s assuming the product file is owned by the application being sized.

Now, let’s ask this question, what if the web service is referencing a file outside the boundary like in the case of google maps, then would we keep everything the same except instead of an ILF it would be an EIF?

[Frank Vogelezang]

In scenario 3, as proposed by Edwin, the webservices are part of the application to be counted. I have no issue with the count.

Alexander’s reply refers to something that I see quite often, that is that the back-end system is offering webservices to handle requests on the data. When these services must be built in the back-end system they will be counted similar to scenario 3.

The functional size of a front-end system will not change, whether the webservices are available or not. The functionality that must be provided to the user is the same. The productivity will be very different when the functionality can be provided by calling existing webservices rather than building the full mechanism to handle the data in the back-end system.

With regards to Sue’s first remark: When the application is able to change or create the data in the back-end system, the product-file is by definition an ILF, regardless of the fact that the architects say that product data belongs to the back-end system.

[Author]

Posts