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.
