Counting DETs for multiple attributes table

[Matteo Palmieri]

Hi all,

I’m a newcomer in the the Function Point Analysis. I’ve recently attended a 3-day course and now wanting to practice with real case studies from my current job. I have developed a device management system and want to apply FPA to evaluate baseline of my application.

In a device management application each DEVICE is identified by a list of ATTRIBUTES, e.g. ram size, disk size, wifi mac address and so on. The above information are displayed in the device details screen, while vendor, model, imei and operating system name are listed in the summary screen.
In the physical data model I have an entity for the DEVICE (imei, vendor, model, operating system) and an entity for APPLICATIONS installed on the device. I also have a property table to list all ATTRIBUTES of a device in form of name and value couples. The name of all possible attributes are known in advance, but the actual values and number of properties listed depend on the device capabilities.

In the attempt to identify ILF, DET and RET for this model I have the following options:

1. 1 ILF with 3 RETs (Device, Applications, Attributes) and 8 DETs (IMEI, vendor, model, app_name, app_version, app_package, attr_name, attr_value)
2. 1 ILF with 2 RETs (Device, Applications) and DETs: 3 for apps (app_name, app_version, app_package) + N for attributes (IMEI, vendor, model, ram size, disk size, wifi, mac…), being N the max number of attributes available.
3. Other options…

Which is correct?

[Frank Vogelezang]

Dear Matteo,

In the situation you describe the answer might be a little different for IFPUG and Nesma FPA. I’m giving you the suggestion for the Nesma FPA analysis.
From a logical point of view each DEVICE has a number of ATTRIBUTES that are associated with the device. This association is part of the ILF DEVICE, since this information is logically inseparable from DEVICE.

ATTRIBUTES consist of name and value couples. In NESMA these kind of files have a special status, called FPA-tables. All these types of tables together (most information systems have a number of such tables) are counted as 1 ILF. I think in IFPUG this is handled as code data and not counted.

APPLICATIONS can be installed on multiple DEVICES and a DEVICE can have multiple APPLICATIONS installed. This means that APPLICATIONS can logically be separated from DEVICES, so they are both separate ILF.

Hope this helps.

[Jacqueline Eshuis]

Hi Matteo,

I could agree with Frank on the Application being a separate ILF, but I am missing some information on that part. Question: What happens with application information when the device is deleted? If the Application information is also deleted, than Application is part of the Device ILF.

Considering the Attributes, I do not consider this to be an FPA file or a separate RET. Taking a look at the information, I can determine that attributes are part of the Device ILF. The reason why it has been put in a separate table is pure technical in my opinion (only storing the minimum number of attributes needed).

So your solution nr2 of counting 1 ILF with 2 RETs looks like the correct solution.

[Frank Vogelezang]

Hi Matteo,

Reading Jacqueline’s answer I must agree on the part that ATTRIBUTES is not a separate RET, but part of the DEVICE ILF. This is true for both Nesma and IFPUG. It is a technical solution to use a separate table.

Whether APPLICATION is a RET for DEVICE or a separate ILF depends on the answer to Jacqueline’s question. I did the assumption that APPLICATION can logically be separated from DEVICE (i.e. APPLICATION data remains in existence when a DEVICE is deleted). If that assumption is correct we have 2 ILF:
– DEVICE (including ATTRIBUTE data)
– APPLICATION
If application data is deleted when the device is deleted we have 1 ILF with 2 RET (DEVICE and APPLICATION).

It all depends on the answer to Jacqueline’s question whether your solution nr 2 is the correct one.

[Matteo Palmieri]

Hi Frank and Jacqueline, thank you for your contribution.

You are correct in speculating that the APPLICATION data function should be considered as a separate ILF. This is also reflected in how the APPLICATIONs are handled by the Device Management system. Once a DEVICE has been deleted the APPLICATIONs bound to that device remains in the system. The reason for this is that the system has to keep an inventory of all applications in order to provide to the administrator the capability to blacklist or whitelist applications.

[Author]

Posts