Thursday, July 09, 2009

Function points and webservices

Function points are widely used to give an accurate measure of the size of an application. This application size is usually applied as an indication to measure the cost of building the application, or to estimate the cost of maintenance of the application.

The nesma counting guidelines version 2.2 generally give clear directions how several situations should be counted. However, the guidlines do not explicitly answer several questions which arise from modern technology. An internal workgroup in Nesma has been working on guidelines for over 2 years, but till now this has not resulted in a guideline on how to deal with new technology.

In this post, I will give my opinion on how a system with web services should be counted, and why. I welcome your opinions on this subject.

The first question is: Should they count at all? And if so, under which conditions?

In the first example, let us have a look at an application with a userinterface some webservices and some databases.
It is depicted in figure 1.


The main principle of Function Points, both nesma and ifpug, is that functionality should be counted, not technology.
Applied to the situation, this means that if the webservices are created because they are "standard architecture" required by the IT-department, the webservices should not be counted.

The situation changes in figure 2.


Here we are counting system A. The systems S and C and ? are other systems, outside the scope of this function point count. For our purpose, it does not matter who the owner of these systems is: another company, or another department within the same company, or even the same department.
Our knowledge of these systemes can be very limited. Sometimes we even dont know the names and owners of these systems. In fact, we may not even know which systems use the interface, or how many. This is reflected by the systems ? in the figure.

Figure 2 shows that System A has a webservice Alpha, which can be addressed from outside System A. Webservice A is an interface which enables the world to put information into System A.
System A has a webservice Beta, which is used internally. Webservice Gamma is an interface offered by System A to the outside world to retrieve information from System A.

The webservices Alpha and Gamma have been built because there are business requirements demanding that the system offers interfaces which enable other systems to feed System A and to retrieve information from system A.
That makes the webservices Alpha and Gamma something required by the user, and thus they should be considered for counting.


Let us have a look at this situation on an even more abstract level. Basically what we have is System A (the system to count) and interfaces with Systems C and S.
FPA has a standard way to deal with interfaces between systems. This has been defined in terms of "External Interface Files". This is in itself a slightly outdated technical terminology, the name "external source of data" would have been more appropriate.

Webservice Alpha receives requests from some external agent to store certain information in the system. The external agent does not need to have infomation on how and where the informaton is stored in System A, just that it needs to be stored and if the process of storing was succesfull.
How and where the information is stored, and which business rules are applied, should be described in the description of the webservice. For System A this webservice is an input function, and should be counted as such. The situation is comparable with an import function with a file from outside the application, as described in chapter 6 and chapters 4.21 and 4.22 of the nesma counting guidelines.

Nesma defines an External Interface File (EIF) as a set of permanent data which
a - is used by the system being counted,
b - is not being maintanied by the system being counted
c - is being maintained by another system than the system being counted
d - is directly accesible by the system being counted.
When we have a look at webservice Alpha, it is used by the system being counted. But it would be artificial, though not impossible, to regard it as a collection of information which is maintained by the system. Rather, it is an interface which provides input functionality into the system we are counting.

This webservice Alpha offers a functionality where information passes the system boudary. It offers a way to input information into the application, just as a batch or a screen would. Thus we should consider it as an external input function. Just to be sure, let us check the defintion of an input function, as given in chapter 7 of the nesma guidelines:
it must be a unique, by the user defined, function where information from outside the information system is brought into the system.

It will be clear that the webservice Alpha provides an interface, just like a screen, to bring information into system A. Still assuming that it was brought into existence as per user requirement as stated above, it satisfies all aspects of this definition, except perhaps the word Unique. If system A would also have a screen input, which has exactly the same functionality and data elements as this webservice Alpha, webservice Alpha would not be unique and should not be counted seperately.

For webservice Gamma, the same principles apply. Again it does not really satisfy the conditions of an external interface file, for the second condition: b - we can not say that it is maintained by another system.
Again, we do have information which transcends the system boundary. Depending on the type of information offered by the webservice, we will have either an External output or en external enquiry.


Figure 2 does not concern itself by how System C should regard webservice Gamma. This situation is depicted in figure 4.
As System C will generally not have and should not have any knowledge of what is going in webservice Gamma, webservice Gamma should be regarded as an external interface file for system C.
If System C uses the information for display on a report or screen, as depicted in the illustration, it should be regarded as a data storage being used by the report or screen (EO).
If system C uses this information to store it in its own database, this function should be regarded as an input function, and webservice Gamma should be counted an external datastorage for System C, used by this EI.

5 comments:

Anonymous said...

When I initially commented I clicked the "Notify me when new comments are added" checkbox and now each time a comment is added I get four emails with the
same comment. Is there any way you can remove me from that service?
Thanks a lot!

Here is my weblog ... Juegos Online Gratis

Anonymous said...

Heya i'm for the first time here. I came across this board and I find It really useful & it helped me out a lot. I hope to give something back and help others like you helped me.

Also visit my web page jocuri cu impuscaturi .ro

Anonymous said...

I do believe all of the ideas you have presented for your post.
They're really convincing and will definitely work. Still, the posts are very quick for beginners. Could you please prolong them a bit from next time? Thank you for the post.

Also visit my page :: jocuri online strategie

sulekha cheran said...


This is very useful to me...



Function Point

Mary P Lomas said...

Thanks for sharing your great post. I’m starting with the most obvious idea. However, it’s actually one that’s sorely lacking

on many web design blogs. Advise people on the different styles, graphics, structures and

functions a website can have. People want to be inspired and guided through the

possibilities that exist. They also want to know you really do understand the many

complexities of designing a website.