Thursday, July 30, 2009

FPA and services: how to count them

Since the publication of the previous post I received a number of noticeable comments.

My co-worker Adri Gerritsen remarked that the indicated method does not only apply to web services, but to all types of services. So where in the previous post web services are mentioned, please read them as (web)services.

When cooperating with another fellow worker, John Mieremet, they applied this method.
In the system they were counting, there was only one service, with one interface. The web service fulfilled the requirement that it was used by an outside system, and required by the user.

The problem was the functionality. The interface supported calls upon which the service returned information. The information returned, would vary heavily upon the call being made. These functions were not present elsewhere in the information system.
The (web)service being counted was about a specialized part of the Dutch social security system, an esoteric topic which does not lend itself very well to serve as an example here. Therefore I have translated the example to a student-lecturer-course system, something much easier to understand.
In our example, the request can be:

  • Request GetStudent: Input StudentID, Returns StudentName, StudentAddress, StudentAge.

  • Request ListStudents: Returns a list of StudentIDs, StudentBirth

  • Request GetCourse: Input CourseID, Returns CourseName, Prerequisite-courselist.

  • Request ListCourseDates: Input CourseID, Date-range. Returns: List of dates on which course will be given, number of courses in this date range, total students enrolled

  • Request SignUp Input CourseId, StudentID, Date. Returns:

They counted these as 5 user transactions, of 2 different types (2 external outputs (EO), 2 external inquiries (EQ)), 1 External Input Function.

To me this looks like a correct approach. What counts is functionality. The IFPUG counting guidelines say:
External Outputs (EO) - an elementary process in which derived data passes across the boundary from inside to outside. The data creates reports or output
files sent to other applications. These reports and files are created from one or more internal logical files and external interface file.
(David Longstreet)
Nesma is a lot stricter than Nesma when regarding functions as identical. For example, ifpug regards different output media for a report as 2 functions, Nesma as just 1. Nesma does not look at layout, ifpug does. But even according to Nesma guidelines these functions are different: they are of different transaction type, they contain a different number of data element types and different data "record types".
(nesma counting guidelines, ch 9, "unique set of data input type elements", and "unique set of data element types reported"

Another step that they have taken, is how to weigh these functions. As the Nesma guidelines for counting inquiries and external outputs state to count both input and output elements, they weighed the ListCourseDates at 1 record type, 2 5 data elements. The counted just the Course as an ILF (Internal logical file), not regarding CourseDates as an independent ILF. They counted CourseID, date range as 2 elements, and the output as 3 elements.

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.

Tuesday, July 07, 2009

Translation

Translation is a problem as old as the tower of Babylon. Yesterday I was looking for the translation of the dutch word "verband", as applied to wounds.
Now this word has many meanings, depending upon context. The oldest well known translator on the web, babelfish, took just 1 meaning, and translated it as "link".

This morning my google page advertised microsofts new translator, bing. Sadly, it also came up with just 1 translation, albeit a different one: "link". This also is a correct translation.

There is however a not superwuick, but rather efficient way to translate the word. I went to the dutch wikipedia, and looked up the word "verband". Wikipedia presented me with a page in which the various meanings were sorted out. The one i wanted was among them, and i selected that. In the left column was the list of articles in other languages on the same subject, and i picked english. This led me to "dressing", which upon seeing i identified as a corrcet trnaslation of what I had in mind.

Now the wiki guys are also working on a dictionary, called wiktionary, but this is far from complete compared with wikipedia. I much prefer the wikipedia route.

Friday, July 03, 2009

outlook life hack

Outlook is alas the obligatory email client in the office. For years i have complained about the lack of grouping emails. One of gmails main advantages is that it groups emails in threads, enabling me to digest an entire discussion of in one go.

I have been told that MS Office 2010 will have this ability too. But hanging the transfer of msdn licenses from getronics to capgemini, i am stuck with office and thus outlook 2003.

But today there i fund a small hack, which does not solve all, but at least goes a small step. Outlook has a field called "Conversation". This field is identical to "Subject", but stripped of "Re" and "Fw".
In outlook, right click on the fields bar with all your emails, select "fields chooser" and pick "Conversation". Set it in front of "Subject", and sort on that field.

Some useful links:
http://lifehacker.com/
http://www.lifehack.org/
http://en.wikipedia.org/wiki/Life_hacking
http://office.microsoft.com/en-us/outlook/HA010970221033.aspx