|
|
home | about Q/P | contact us | |
|
|||||
| article | ||||
 |
Roger Heller, Vice President Most people agree that function points work perfectly well when measuring business systems. I often find myself, however, explaining why this robust software sizing metric works equally as well when measuring less traditional environments such as middle-ware applications. There are often heated debates on whether International Function Point Users Group (IFPUG) function points can truly represent the "size" of non-business applications. In our client work, we have found that IFPUG function points do accurately represent the size of less traditional environments. Success depends on applying the rules consistently and analyzing the results against similar applications. With this in mind, there is no reason for organizations to risk potential failure by relying on proprietary and/or unsupported software sizing techniques. Once over the acceptance hurdle, organizations can recognize many benefits that previously alluded them. While there are some function point rules and guidelines to be sensitive to, all in all the counting is very similar to traditional applications. What are middle-ware applications anyway? In classes I teach I describe middle-ware as being a software component that is in-between a user recognizable application and some other component of the technical architecture. The middle-ware application could interact with another software application and/or a hardware component. The ultimate (human) end user typically does not recognize the middle-ware application as an individual system even though they receive benefits from the functions it provides. So, who are the "users" of middle-ware applications? Function point counting of middle-ware requires a broader definition of "User." When counting traditional systems, "User" typically refers to a person, namely the end business user. When using function points to count middle-ware, we expand the definition of "User" to include other software components and /or software engineers who are defining the requirements and using the middle-ware. This expanded definition allows us to count from the middle-ware perspective. How do you identify middle-ware application boundaries? Counting middle-ware is ultimately a boundary issue. Middle-ware boundaries are based on separate and unique functions as seen by the user. Remember that we are not talking about a traditional human user but one as described above. With that in mind: data-management packages, security processing, memory managers, and data communications subsystems are middle-ware applications and each could be considered to be a separate application boundary. Do middle-ware applications have files? Note: The following discussion is based on counting guidelines as defined in the IFPUG Counting Practices Manual (CPM v4.1). Just as in counting traditional data functions, a file must contain data that is user identifiable, logically related and the data must be maintained (ILF) or referenced (ILF or EIF) through one or more elementary processes. With this definition, a distinction needs to be made between files that contain temporary data and temporary files. For example, data may be received during an elementary process that is used for validation or to build a transaction that is sent to another application or user. In this case the data structure is permanent and it contains temporary data that is required only during the execution of the elementary process. It can be counted as a data function since the data is maintained through one elementary process even though it no longer resides within the boundary. In some situations, a middle-ware application may not store any data, since it could operate purely on control inputs. What about transaction functions? External Inputs A transaction that enters the boundary of the middle-ware application to either control processing or results in storage of data required by the application is an External Input (EI). The External Input itself may only contain control information that does not have to update an ILF. Very often the External Input itself will be created by another application. For example, a telephone switch receives a message from a Customer Services application to turn-on a new feature for a customer. In this case the message to turn the feature on is an EI to the switch. External Inquiries An External Inquiry causes data to exit the boundary of an application. The results of the External Inquiry cannot contain derived data or alter the behavior of the sending application. The process is the direct retrieval of previously stored data. The output will often be used by other applications to control specific processes required by the overall architecture. For example, the application retrieves a previously stored setting and sends it to another application that uses it as input. The function of retrieving and sending the setting would be considered an EQ. External Outputs External Outputs are transactions that exit the boundary of an application and either contain derived data, cause the behavior of the system to be altered or update an ILF. The output is generated based on a specific set of system requirements. For example, given a set of parameters, an application has to derive a key that is passed to another application as input. The function of deriving and sending the key would be considered an EO. Accounting and reporting for middle-ware aren't that tricky! This is another one of those sensitive items. Since the ultimate end-user functionality is already accounted for in the traditional applications portfolio, it would be double counting to add the middle-ware function points to the same portfolio. Therefore, the results of the middle-ware applications count should not be included in the business portfolio. It is more appropriate to establish a separate applications portfolio that only contains function point counts related to middle-ware applications. This promotes specific tracking and reporting for these software products. Why would you want to count this stuff? There are many very good reasons to count middle-ware applications. Organizations use the information for a wide variety of purposes including:
About the author Roger Heller, Vice President, Q/P Management Group Inc., wrote this article. This article originally appeared in Q/P's semi-annual newsletter, "The Q's & P's of Management". © Copyright 2000-2002. Q/P Management Group, Inc. Proprietary and Confidential. All Rights Reserved. |
|||
