Introduction *

Improved Function Point Definitions *

External Inputs *

External Outputs *

External Inquiries *

Internal Logical File (ILF) *

External Interface File (EIF) *

Summary *

Understanding Internet/Intranet Applications *

Boundary *

Transactions (Transactional Function Types) *

External Input *

External Outputs *

External Inquiries *

Internal Logical Files and External Interface Files *

Summary *

GUI Applications *

Data Elements *

Rating External Outputs *

Rating External Inquires *

Menus (Dynamic Menus) *

Rating External Inputs *

Control Inputs *

Multiple Languages *

Radio Buttons *

Check Boxes *

Command Buttons *

Display of Graphical Images or Icons *

Sound Bytes *

Photographic Images *

Messages *

OO *

Objects *

Methods *

Attributes *

Classes *

Interface Services, Transactions or Message Passing *

File Structures *

EXAMPLES *

Summary *

Using Use Cases to determine the number of function points *

Use Case *

Risks Counting Function Points from Use Cases *

Examples *

Even though the primary function of all software applications is to meet business objectives, software applications come in all shapes and sizes.  The current IFPUG definitions need to be modified to be used in today’s modern world. There has not been a change to the IFPUG Counting Guidelines for almost 8 years.  During this time, the world of technology has leaped forward while Function Point Counting Rules have remained static. It is important to be able to take the current IFPUG Counting Rules and adapt (while conforming to the past standards) them to today’s fast paced and ever changing world.

The focus of the tutorial will be to apply function points to new and emerging technologies.  We will examine and dissect several OO, GUI, Internet applications, so we can apply function points to them.   Additionally, the tutorial will introduce the participant to new and improved function point definitions.  These definitions are not really new.  They have appeared in most of my articles that I have published over the past few years.   The new definitions are easier understood and simpler to  apply to new technologies than the current IFPUG definitions. The definitions conform to the current IFPUG Standards and would not impact the function point count of an application -- but they improve understanding and reduce the learning curve.

After a brief review of IFPUG Definitions, we will cover difficult topics like OO, GUI, Internet, Notification Messages, Error Messages, and Confirmation Messages so on and so forth. 

At the conclusion of the tutorial you should have the necessary skills to apply function points to the particular environments that we  cover. Additionally, you should have a clear understanding of how to apply function points to your unique environments that we have not discussed.  

It is hard to apply the IFPUG definitions to new technologies. The IFPUG definitions become much clearer with just a few simple changes. During the tutorial several examples from GUI and OO applications will be presented.  We will use the following definitions and compare and contrast them with the "old" IFPUG definitions.

The following definitions should not impact a function point count, but they do reduce the learning curve when applying function points to new and emerging technologies. 

Improved Definition: External Inputs (EI) - is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen, electronically or another application. The data can be either control information or business information. If the data is business information it is used to maintain one or more internal logical files. If the data is control information it does not have to update an internal logical file.

IFPUG 4.0 Definition: External Input (EI) processes data or control information that comes from outside the application boundary. The external input itself is an elementary process. The processed data maintains one or more ILF’s. The processed control information may or may not maintain an ILF.

Critical Reasoning:

The IFPUG definition states "…from outside the application boundary." Since the IFPUG definition reads "…the processed data maintains one or more ILF’s, then it is clear that the information must come from outside to inside the boundary. This is important for a variety of reasons. It is clear from the improved definition, calculated values that are stored are data elements for the external input, but calculated values that are not stored are not data elements for the external input. This is true because the calculated value that is not stored has not crossed the boundary (outside to inside) and it is not maintaining an ILF.

In a GUI or OO environment it is common for information to move from one window to the next. The actual movement of data is not considered an external input because it has not crossed the application boundary (outside to inside) and does not maintain an ILF.

Improved Definition: 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.

Derived Data is data that is processed beyond direct retrieval and editing of information from internal logical files or external interface files. Derived data is the result of algorithms, and/or calculations. Derived data occurs when one or more data elements are combined with a formula to generate or derive an additional data element(s).

An algorithm is defined as a mechanical procedure for performing a given calculation or solving a problem in a series of steps.

IFPUG 4.0 Definition:

An External Output (EO) is an elementary process that generates data or control information sent outside the application boundary.

Critical Reasoning:

The IFPUG 4.0 manual fails to give a definition for derived data and it does not tell where the information was prior to being sent outside the boundary. If information is sent outside the boundary it is safe to say that the information was inside the boundary. Since the information was inside the boundary it must be contained in an ILF or EIF.

Improved Definition: External Inquiry (EQ) - is an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files. This information is sent outside the application boundary. The input process does not update any Internal Logical Files and the output side does not contain derived data.

IFPUG 4.0 Definition: An External Inquiry (EQ) is an elementary process made up of an input-output combination that results in data retrieval. The output side contains no derived data. No internal logical file is maintained during processing.

Critical Reasoning

The IFPUG Definition is not clear for a variety of reasons. The IFPUG definition reads, "results in data retrieval." If this is the case then the data must be retrieved from somewhere inside the application boundary. The only place the data can reside is in an ILF or EIF. Since this is the case the definition should explicitly read "from an ILF or EIF."

The IFPUG Definition does not explicitly state the information must be sent outside the application boundary (like an EO), regardless the information must be sent outside the boundary. This is important for OO because objects communicate with each other. Only when an object actually sends something outside the boundary should it be considered an external inquiry.

Additionally, the IFPUG Manual does not make a clear distinction between an EO and an EQ. It is common in the GUI and OO environments for an EO to have an input side. The only distinguishing factor is that an EQ can not have derived data. If this is the case, then an EO must have derived data (otherwise it is an EQ).

Improved Definition: Internal Logical Files (ILF) - a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through External Inputs.

IFPUG Definition: Internal Logical File (ILF) is a user identifiable group of logically related data or control information maintained within the boundary of the application.

Critical Reasoning:

The primary difference is in the last few words of the definition. The difference is expanding on what is meant by "maintained." The only thing that maintains an internal logical file is an External Input.

Improved Definition: External Interface Files (EIF) - a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The External Interface File is an Internal Logical File for another application.

IFPUG Definition: An External Interface File (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. This means an EIF counted for an application must be an ILF in another application.

Critical Reasoning:

The differences are minor, but I believe the new definition is more concise.

It is important to lay the foundation for the tutorial. Without solid definitions we can not proceed. I maintain the very reason there is so much difficulty and confusion applying function points to new technologies is because the IFPUG definitions are very weak.

The vast majority of websites contain no or very few function points.  Most websites are nothing more than online brochures -- my website for example.  That is, no files are maintained and the contents of the webpage are not the result of a file being read. 

On the other hand, there are Internet/Intranet applications that do provide business functionality and need to be addressed.  More and more organizations are utilizing internet applications to provide core business functionality.   Applying function points to these type of applications does pose some unique problems.    The first problem is the boundary.  The second problem is identifying transactions and identifying the internal logical files and/or external interface files.

The boundary for an internet application is defined in a similar way for traditional applications.  For traditional applications the boundary is not drawn just around the user interface or a group of screens but around the entire application.  Frequently, internet applications are just extensions to current and existing applications.   There is a tendency to create a "new" application for the internet extension, but this approach is incorrect.

Transactions (external inputs, external outputs, external inquiries) follow the same basic rules as for traditional applications.  The current IFPUG Manual was written prior to the emergence of the internet; therefore, it does not contain any information for internet applications.  The IFPUG Manual has not been updated in almost 8 years and it should be considered an outdated document.

If an external input is not a control input, then it must update an internal logical file.  An example of an external input would be a "submit forms."  The submit forms may be an html that is updated with information.  For example,  I had a series of surveys on my website.  Each time questions were answered the html survey.htm was updated.  This was an example of an external input.  Information crossed the boundary from outside to inside and an internal logical file was maintained.

Some applications have online update of temporary files.  These temporary files are used to update permanent files.  Even though the external input is updating a temporary file this temporary file is logically the same as the permanent file.  That is the temporary file is a mirror image or a subset of the permanent file.

Like a external inquiry an external output can and does frequently have an input side.   The information is read from an internal logical file or an external interface file.  Our web programmer developed a series of a report so I would not have to look at a raw html file.  For example, a simple report that summarized information for each question. That is the report provided totals (calculated values).  This would be an example of external output.   The information crossed the boundary from inside to outside and contains derived data.

Like an external output the information in a external inquiry must be read from internal logical files or external interface files.  Another report created was information from the html.  That is, a listing of Name, Email, Responses.  No calculated values were on the report -- hence an external inquiry. 

Additionally, each time someone responded to the survey an email was sent to me.   The email contained respondents name, email address and responses.  The email should be considered an external inquiry.

In the above example, survey.htm, represents an internal logical file.  An internal logical file must have at least one external input.  In this case the survey submit form is the external input for the survey.htm internal logical file.

Websites developed utilizing FrontPage or other html tools may or may not contain any functionality.  The key is understand where the information resides and how the information is processed.  The far majority of websites are nothing more than just menus and text. 

Like traditional applications, GUI applications present or display information in two ways, as an External Inquiry or as an External Output. An external inquiry is an input-output combination that results in information being retrieved from one or more files. The output side contains no derived data, no conclusions are made. For example, a user may want to view the last order from a customer. The customer name would be used as the search criteria, then the last order would be displayed. The output side contains no derived data, and no conclusions are made.

On the other hand, an External Output contains derived data. Information is processed using algorithms and some sort of conclusion is presented. It is a common mistake to count everything on line as an EQ and everything sent to paper as an EO. EQ’s and EO’s can either be on line or hard copy.

Using the strict definition of a data element provided by IFPUG’s Counting Practices Manual. "A Data Element is a user recognizable, non recursive field." Unfortunately this does not provide much guidance when counting GUI applications. In fact, the IFPUG Counting Practices manual does not provide much detail on counting, Radio Buttons, Check Boxes, Pick List, Combo Boxes, so on and so forth. Regardless, a data element is information that either is stored on an Internal Logical File or that is used to invoke a transaction.

External outputs can report textual, graphical, or electronic information. You rate an external output by combining the number of file types referenced and the number of unique data element types (not recursive fields).

Graphs are counted the same way as the textual EO’s. That is, the graph is rated and scored based on the number of DET’s and the number of FTR’s. In fact, recursive information is easily seen in a graph, but can be more difficult to visualize in a text report.

There are 10 data elements in the following table

1. Days
2. Hits
3. % of Total Hits
4. User Sessions
5. Total Hits (weekday)
6. Total % (weekday)
7. Total User Sessions (weekday)
8. Total Hits (weekend)
9. Total % (weekend)
10. Total User Sessions (weekend)

The same data could be processed and presented as bar graph. But on the following bar graph there are only two data elements (user session and day of week). The bar graph is a separate external output and is unique from the above table. In short, it provides different business slightly different information than the table.

 

 

 

 

 

 

 

Rating External Inquires

EQ’s are very common in GUI applications. As stated earlier, an EQ does not contain derived or calculated data. A dynamic pick list (drop down box) is an example of an External Inquiry. It is simply a read from a file. For example, a pick list providing a listing of country names. This pick list would be counted as an EQ if the country names are contained in an internal logical file or external interface file.

A serial inquiry is one inquiry followed by another inquiry. For example, a user may be able to select a country name from a pick list (first EQ), the country name is used as input for the second EQ that provides country details.

Menus (Dynamic Menus)

The menu displayed to the right is a dynamic menu. Word displays the last several files that have been opened. We can easily conclude that this information is being read from some type of internal file. Hence, the information is dynamic. The menu would be counted as an external inquiry.

Even though the IFPUG Manual explicitly states that menus are not counted, in this case it is clear that the menu is dynamic and changes.

The real distinction is if a menu is dynamic or static. That is, are the contents of the screen or report dynamic (read from some file) or are they static.

An EI is the method in which information on an ILF is maintained (added, changed or deleted). It is common for GUI applications to have External Inputs preceded by serial inquiries. That is, a user may be able to select a customer name from a pick list (first EQ), the customer name is used as input for the second EQ which provides address, phone, zip and other contact information. From this point forward a user can add, change or delete the customer information (3 EI’s). In this case, this one screen would represent 2 EQ’s and 3 EI’s.

Control inputs change the behavior of an application or the content of a report. In the "Create Report" control screen, the user has the ability to select which reports are going to be produced. This particular screen has several data elements types. The check box, graph type, dimensions, elements, sub-items and the actions keys.

Note that the user can choice each report individually. In fact each report is as an object. The generated report is a combination of several reports (or objects). Each object has several attributes.

Consider an application that is a single language. More than likely report headings, text descriptions are all "hard coded." That is the user can not dynamically change the headings or the text. Now consider an application that has been developed with multiple languages in mind. The report headings, text descriptions are all read from files. Compare the following chart in Spanish to the English chart presented earlier. Is this chart a unique external output or the same external output?

The Spanish chart is not a unique external output. If external outputs are available in multiple languages then several things need to be considered. First there is probably some control input that allows the user to dynamically select the language. Second, there is an additional FTR referenced that contains the language text. Third, this language internal logical file is maintained by an external input. Fourth, there are more data elements in the report. If an external output is available in more than one language then it is not considered an unique external output, but the external output is more complex (more DET’s and more FTR’s).

Radio Buttons are treated as data element types. Within a group of radio buttons the user has the option of selecting only one radio button at a time, so only one data element type is counted for all the radio buttons contained in the entire frame. In the webtrends create report the "2 D and 3D" radio buttons represent only one data element.

Check boxes may represent one data element or multiple data elements. In the above example (Create Report), the check boxes only represent one data element. That is, the check boxes are recursive.

The screen listed as Data Entry Preferences has numerous check boxes. In this case, each check box is considered a data element type (DET). Each check box is independent from other check boxes and provides a different business functionality. The sort employee name and Time format are two additional data element types (DET’s) also. This particular screen has 9 data elements (8 DET’s and action key).

Command buttons may specify an add, change, delete or inquire action. According to IFPUG counting rules each command button would be counted as a DET for the action it invokes. For example, a simple application to track Distributors could have fields for Distributor Name, Address, City, State, Zip, Phone Number, and Fax Number. This would represent seven data elements ( 7 DET’s) and the add command button would represent the 8th data element. In short, the add external input represents a one external input with eight data elements, the change external input represents another external input with eight data elements (7 fields plus the change command button), and the delete external input represents the last external input with eight data elements (7 fields plus the delete command button).

In the example Data Entry Preferences the OK button is a data element type (DET). The cancel button is just navigation and the help button is for other functions. The default action key is the input side of an inquiry. That is, if the default action key is clicked, information is read from a file and populates the screen.

A display of a graphical image is simply another data element. An inventory application may contain data about parts. It may contain part name, supplier, size, weight and include a schematic image of the part. This schematic is treated as another data element.

Another example would be a map. The map may be "hot." As the mouse pointer is moved over the map different city names are displayed. If the user clicks on a particular hot point details about that city is displayed. The details about each city are contained in a internal logical file or external interface file then the details could be an external inquiry.

The following map of the United States is "hot." If you click on Kansas City, then you get the following information.

Kansas City, Missouri: Population 435,146: Location: 39.1 N, 94.5 W

Houston, Texas: Populations 2,231,130: Location: 29.8 N, 95.4 W

Chicago, Illinois: Population 2,783,726: Location: 41.8 N, 87.6 W

This would be an example of another inquiry.

Many GUI applications have a sound byte attached. This represents one data element. The number of notes played is simply recursive information. If the length of the sound byte increases, then the data element remains one. If the Star Spangled Banner is played for two seconds or four seconds, then this is still one data element. The longer it is played the more "recursive information."

A photographic image is another example of a data element. A human resource application may display employee name, start date, etc. and a photograph of the employee. The photograph is treated the same as employee name or employee start date. It is another piece of information about the employee. The photograph is stored and maintained like any other piece of information about the employee.

There are three types of messages that are generated in a GUI application: Error messages, Confirmation Messages and Notification Messages. A error message and a confirmation message indicates that a error has occurred or that a process will be or has been completed. A message that would state, "Zip code is required" would be an example of an error message. A message that would state, "Are you sure you want to delete the customer?" is an example of a confirmation message. Neither of these type of messages are treated as a unique External Output, but they are treated as data elements for the appropriate transaction.

On the other hand, a notification messages is a business type message. It is the basis of processing and a conclusion being drawn. For example, you may try to withdraw from an ATM machine more money than you have in your account and you receive the dreaded message, "You have insufficient funds to cover this transaction." This is the result of information being read from a file regarding your current balance and a conclusion being drawn. A notification message is treated as an External Output.

Notification Messages may be the result of processing and the actual processing or derived data my not be seen. If a message is created to be sent to a pager (beeper) at a given time. This is much like an alarm. That is current time is compared to set time and they are equal the message is sent. The pager message has one data element the text message.

The traditional view of software systems is as a composition. There is a collection of data that represents some information and a s set of procedures which manipulates the data. The data and procedural logic are separate components which comprise the overall software system.

In the object-oriented view of software systems there is a single entity called an object which represents both the data and the procedures. Like pieces of data, objects can be manipulated. However, like procedures, objects can describe manipulation as well.

An object is a collection of data (attributes and properties) and functional logic (methods). The data defines the state of the object and the methods define the behavior of the object. There are two kinds of methods. First, Interface methods which provide a means of communicating with the object. Second, internal methods which create object behavior but are not accessible from outside the object. The interface method provides a clear defined way of communicating with an object. The internal method need only be known to the designer of that object. Users of the object ONLY need to know about the interface methods.

Function Points measure software by quantifying its functionality delivered to the user based primarily on the logical design. Frequently the term end user or user is used without specifying what is meant. In this case, the user is a sophisticated user. Someone that would understand the system from a functional perspective --- more than likely someone that would provide requirements or does acceptance testing. Function Points make it possible to measure the size of the information systems according to what the user sees and interacts with. This definition is similar to the interface method described above.

All internal methods are done to support interface methods. Internal methods are not done as an end, but are done as a mechanism to assist the interface method in delivering information to the user.

A method is simply the action that a message carries out. Methods are the things that an object can do. Methods operate on the data contained in the object, changing it, looking at it or modifying it.

Attributes are nothing more than characteristics about an object.

How are objects defined? An object is defined via its class, which determines everything about an object. Objects are individual instances of a class. All you need to do is create a subclass of the original class. This new class inherits all the existing messages, and therefore, all the behavior of the original class. The original class is called the parent class, or superclass, of the new class. Some more jargon -- a subclass is said to be a specialization of its superclass, and the conversely a superclass a generalization of its subclasses. All of this is really independent of counting function points. The important thing is to focus on what each object actually does.

Objects communicate with another by passing messages. A message contains a name which identifies its destination, and may also contain some arguments or parameters. The message, when received, will cause the invocation of an appropriate method within the receiving object. In its simplest form, a message is the same as a function or procedure call in a traditional sense, since the net effect will be the same. The sending object is often referred to the server and the receiving the client. A message prepared and sent to the client will generally manifest itself as an External Output or a External Inquiry. A message prepared and sent from the client to the server is generally an External Input.

A message is a request for an object to carry out the sequence of actions in one or more of the methods of its calls. A method is a unit of functional logic contained within an object. According to IFPUG Standards, a transaction must have processing logic that is unique and represents the smallest unit of activity that is meaningful to the business user. Since a method is a unit of functional logic contained in an object, it is very similar to the definition of a transaction -- according to IFPUG Counting Rules.

With OO applications only persistent data is considered an Internal Logical File not transient data. Transient data is only valid inside a program or transaction and is lost when the program or transaction terminates. In traditional programming this would be similar to a temporary file. Persistent data is stored outside the program and survives program termination.

Persistent Data is stored in either Relational Database or OODBMS. Frequently, data contained in third normal form represent one internal logical file. Third normal form attempts to remove any dependencies between non-key attributes. To be considered an internal logical file (ILF) the file (or table), the data is a logical group, the data is maintained or modified through and elementary process (methods).

Transactions

1. "Peer to Peer Communication" --- A unique message sent, received and responded to is a series of functions. Lets’ assume there are two applications A & B with peer to peer communications. Application A sends a message to application B --this message sent is an External Output for application A and an external input for application B. B processes the message based on some prescribed business rules and creates a message (External Output for Application B) that is sent back to application A (an External Input for Application A). So this series of communication would represent 2 External Inputs and 2 External Outputs. In reality there may be hundreds of unique messages sent between Application A and B.

2. Two Switches Communicating through polling is an example of an external inquiries.

3. If an application has heavy user interface and is OO, there will be many more inquiries (External Inquiries) than a traditional system. A screen my have several unique objects. For example, a customer inquiry object may display a list of current customers (first External Inquiry). After selecting a customer the screen populates all the fields about a customer, address, phone, city, state, tax status, so on and so forth (second External Inquiry). If all the fields can be modified then the final screen is an External Input. So this one screen has 2 External Inquiries followed by an External Input.

To reiterate, function points can be applied to OO environments. The proposed benefit of OO applications is faster, better, and cheaper applications. If this is not the case why bother! There must be some normalization factor to compare OO to traditional development. Function Points focus on what is delivered to the user and is independent of development methodology or language. What is delivered to a user in an OO or traditional application will be the same.

Function Points measure the size of the information systems according to what the user sees and interacts with.

• Measures functionality delivered to the sophisticated user based primarily on the logical view.
• A sophisticated user is someone that participates in requirements definition, use case development, acceptance testing, so on and so forth.

A Use Case is a dialog between a user and the computer system in order to achieve specific user need. A Use Case focuses the software development effort on what the users’ need to accomplish in order to achieve their goals.

• Use cases describe how users interact with a computer systems.

Normally a screen needs to be dissected into transactions (external inputs, external inquiries and external outputs). That is, any particular screen can have an external inquiry (display of information), external outputs (derived data) and external inputs (updates to files). Use case provide the dissected parts (steps) already. A step can be a transaction, a data element or neither. Each step needs to be analyzed to determine if it is a transaction or data element.

Important to review vocabulary looking for words like, save, update, gather, calculates, so on and so forth.

A necessary transaction was not identified within a Use Case

A transaction was improperly identified within a Use Case

The number of attributes are not defined clearly within a Use Case

The number of attributes can not be tied to a entity.

Use Case – Modify Table Contents

Step 1

Step 2

The screen layout for Step 1. The existing styles is an external inquiry. This external inquiry has one data element on the input side and one data element on the output side. The result (output side of this inquiry) is a data element for the control input screen. The radio buttons (edit or create) represent a single data element.

The item on the left changes depending on the style selected. This represents another external inquiry for this screen.

The data elements are:

Page Color, Table Colors and Font Settings. These are items that change depending on the existing style selected.

[Ask Pai] [Home]