Author |
Message |
27/04/2015 22:00:43
|
mpalmier
Joined: 27/04/2015 21:59:39
Messages: 2
Offline
|
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 according to your view?
|
|
|
28/04/2015 19:41:17
|
jberzin
Joined: 03/02/2012 14:37:43
Messages: 2
Offline
|
Dear Mpalmier,
FPA some times can not be very much exactly and open to interpretation.
First of all in FPA and data modeling attributes should be grouped according to their characteristics and significance following user view, them in my interpretation for your scenario would be:
PHYSICAL MODEL
DEVICE MODEL
Device ID (Key)
Description Device
Vendor
Model
DEVICE ID
Device Id (Key)
Owner Id (Name Or Code)
Owner Celular Number
Imei
Device ID (Foreign Key)
DEVICE ATTRIBUTE ID (Foreign Key)
DEVICE ATTRIBUTES
Device Attribute Id (Key)
Description Device
Decimal Value
Char Value
Device Id (Foreign Key)
App Attribute Id (Foreign Key)
APP ATTRIBUTES
App Attribute Id (Key)
App_Name
App_Version
App_Package
ILF of your application
DEVICE MODEL 1 4
DEVICE ID 1 4
DEVICE ATTRIBUTES 1 4
APP ATTRIBUTES 1 4
Of course, this scenario is subject to evolution as more information is provided.
I expect have helped and especially simplified their baseline count.
Regards
Jberzin
|
|
|
30/04/2015 03:05:55
|
Steve Neuendorf
Joined: 02/02/2012 19:04:57
Messages: 2
Offline
|
Hello mpalmier,
Welcome to a great community. I am assuming your class was on IFPUG Function Points. The Challenge is always to ignore the physical view and implementation knowledge of your application and use the logical user view. Hopefully you have access to the IFPUG Counting Practices Manual (CPM) and you can always access the networks of knowledgeable and experienced FP counters and users through this group and several others, including the message board hosted at ifpug.org.
The key concept for answering your question is that of (in)dependence, as explained in the CPM. From your explanation, you have 3 distinct entities: Device, Attributes and Applications. The primary subject of your application is device management, So I would start with Device as being the logical group of data from an user view. A device can have any set of attributes and any number (or no) applications. From an end user view, a device with no attributes would not be meaningful, as nor would any attribute(s) not associated with a device. The way I think, the cardinality is many to many (no zeros) so the two entities are dependent. Device is an ILF and Attributes is a mandatory RET. The cardinality is also true for applications; however, a device with no applications is meaningful, since it can have applications installed and it may be useful (meaningful) with none of the applications of record installed. Also, an application not installed on any device may be meaningful, since it can be installed on any device (think of an application acquired and recorded for an anticipated shipment of devices), so Application is independent and an ILF also.
Let me as an aside recommend a cult classic movie: "Harry In Your Pocket." "Harry doesn't hold" and "Steve doesn't do DETs" (at least not on the boards or outside of "Metrics Views". HTH Steve
|
Steve |
|
|
01/05/2015 23:27:04
|
mpalmier
Joined: 27/04/2015 21:59:39
Messages: 2
Offline
|
Thank you both for replying to my question.
As you may have guessed I have some difficuties in identifying whether an entity should be counted as ILF by itself or as RET of another ILF.
Based on Steve suggestion I have reviewed CPM definition for entity independence and now it is clear to me that DEVICE and ATTRIBUTES have a link and ATTRIBUTES cannot be independent of DEVICE. This is also proved by the fact that once a DEVICE has been removed from the device management system also the ATTRIBUTES are deleted. But now a different question... why not counting ATTRIBUTES as DETs of my DEVICE entity?
Let's move now to APPLICATIONS. An application "comes to life" because it has been detected on a managed DEVICE. The relationship I see between DEVICE and APPLICATIONS is the same between an AUDIO CD and AUDIO TRACKS (Counting RETs). AUDIO CD should be counted as an ILF and AUDIO TRACKS as a RET. The only difference I would agree is that an AUDIO CD without TRACKS makes no sense, while a DEVICE without APPLICATIONS make sense anyway. Is this the reason why I sould count APPLICATIONS as ILF?
So, to recap:
DEVICE is ILF with 2 RETs (DEVICE, ATTRIBUTES)
APPLICATIONS is ILF with 1 RET (APPLICATIONS)
Regards,
Matteo
|
|
|
|
|
|