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.

1 comment:

Anonymous said...

Hi, your explanation is very interesting, but I'm afraid I am not able to assign to each web service method you mentioned in the example its correct transaction type. Could you please provide a mapping that links to each method its type of transaction? I'd appreciate. Thanks.