Function Point FAQs

Web Based Applications

ISSUE

How is FPA applied to sizing web-based applications?

FUNCTIONAL OVERVIEW

Most organisations have a number of web based applications for which functional size is required to be determined. In the absence of definitive industry guidelines, the following guidelines, derived from the IFPUG paper and other industry sources are our recommendations.

Characteristics of Web Based Applications

  • A web based application is defined as a collection of logically related interactive functions that fulfil a specific business requirement as defined by a knowledgeable user of the internet. In the case of a web application, the 'business user' of the application is the web provider, and it is this view that determines what is "user requested functionality." The end-user of the web site does not directly influence either the business functionality provided, or the design requirements.
  • One web site can provide access to multiple web applications. It is important to establish applications boundaries clearly at the outset of counting.
  • The architecture of web applications comprises multiple components. The purpose for counting determines which components are to be included within the scope of a particular count. For most organisations, only functionality actually built by their developers is included. Examples of web components include:
    • Business application functionality
    • Security (e.g. access control structures, data encryption, firewalls)
    • Browsers (e.g. Internet Explorer)
    • E-Mail component
    • Forums.

Web components are being added and changed regularly.

  • The types of business functions that are provided by web based applications vary considerably. Web based applications can be characterised as either:
    • Collections of static HTML pages
    • On-line applications -
      • Simple form fill and information provision applications
      • Fully functioning business applications

In categorising web applications, the main criterion used is to determine whether the web site business functions, contain logic and algorithmic processes, or simply re-deliver stored data.

GENERAL DISCUSSION AND RESOLUTION

The recommended guidelines for counting web based applications are based upon the following basic rules:

  1. Only functions customised or custom built by the organisation's developers will be included within the scope of the function point count.
  2. Functions from the different web architecture components are counted separately.
  3. Results for the different web architecture components are recorded in the one count if developed by the same team, but functions must be assigned to separate branches and clearly identified.

The following counting guidelines present a generic solution to the FPA issues related to web based applications.

Collections of static HTML pages

These are simple web sites which comprise a collection of 'information' pages, containing both textual and graphic elements, connected with hyperlinks. The text may be structured to present data content as lists. The text may represent advertising. In essence, this type of web site provides on-line access to 'brochures'. Hyperlinks may also provide access to other web sites. System engineering skills are not required to develop such sites; rather, the skills required are related to technical writing, graphic design and advertising.

The majority of HTML pages are constructed manually using a text editor, or simple authoring tools. There is no ability to update the HTML pages; they are reconstructed each time a change is required. They may support some simple user interaction functionality, for example, commenting, viewing site user appraisals, etc.

These sites may include some custom developed Javascript code to provide a menu infrastructure or animation. However, this is not considered to be logic; rather, the code provides the user interface.

IFPUG FPA is not an appropriate technique for sizing these types of applications. The queries supported by these sites are similar to system Help enquiries. From a logical perspective, each 'query' upon a page is the same type of EQ. The Page ID is input and the page text is displayed. As for Screen Help, only one EQ should be counted per application. This applies regardless of whether the page retrieved is just text, provides a list of items and/or includes graphic elements.

Effort involved in developing these types of applications relates directly to the number of pages created, the volume of text per page, the number of hyperlinks established, the complexity of the graphical elements and the menu structures provided. All of these components are not addressed by traditional FPA.

Where such applications include simple user interactions, these functions can be sized using FPA. However, the value of this size measure, which only assesses a small proportion of the application 'functionality', must be questioned.

On-line Applications

These are web-based applications that act as a front-end or extension to an existing host application. The internet is used as the medium for providing broad user access to the functions and data of host applications. Typically, the web browser and server provide an access mechanism to initiate a connection between the client application and server. The functionality provided by these applications is generally already available in similar applications provided on different platforms. These applications can be further categorised into:

Simple Form Fill and Information Provision Applications

These are applications whose primary objective is to record and provide access to data maintained either in a host system database or in a database specifically developed for the web based application. The data in the database is accessed and the server generates dynamic HTML pages for display on the user's web-browser. There is a direct link between the application presentation layer and the DBMS with no "logic" layer involved.

The data presented may be textual, in the form of lists or graphical, i.e. the data may be retrieved and presented to the user as stored, or it may be processed prior to presentation.

Various tools are available which assist in the development of these types of applications. These tools are used to 'generate', rather than 'build', these applications, much as application generators would generate COBOL code based upon structured design specifications. The availability of application generating tools allows end users to develop their own applications.

IFPUG FPA is an appropriate technique for sizing these types of applications. However, the project attributes (i.e. use of application generator tools) must be taken into consideration when comparing development productivity rates. The main issue that needs to be addressed is the placement of the application boundary, i.e. is the database inside or outside the boundary of the web application? Once this is resolved, the following functions are counted for the business applications software layer.

Files: Logical Files

Where they exist, the following may be counted as logical files for the Business Applications Layer

  • Files maintained via the system "forms"
  • Files referenced to retrieve the business data that satisfies available queries
  • Control files which store the hypertext links.

Files that have been developed specifically for the web application, and that are maintained by the "forms" functions, are counted as ILF's. Files referenced from a host application are counted as EIF's. Where the purpose of the "forms" function is to store data on host application files, these host files are counted as ILF's to the web application. Typically, the data will initially be stored in a temporary file in the web application. These temporary files are not counted.

Transactions: External Inputs

Where they exist, the following may be counted as EIs for the Business Applications Layer:
  • Maintenance functions on data files which reside within the web application boundary
    (These functions may be provided by a conventional application interface)
  • Maintenance functions for data files which reside on the host application

Where the host application contributes to the external input function ie by providing the necessary functionality for accessing and updating its data files, this should be counted as per the scenarios described in Section 3.3.6, Duplicate Counting of Front-end and Core System Functions, and Section 3.3.8, System Interfacing Summary.

Transactions: External Outputs/External Enquiries

Where they exist, the following may be counted as EOs and EQs for the Business Applications Layer.
  • Reporting/enquiry functions on the above files. Apply IFPUG guidelines to determine function type.

Where the host application contributes to the enquiry function, i.e. by providing the necessary functionality for accessing its data files, this should be counted as per the scenarios described in Section 3.3.6, Duplicate Counting of Front-end and Core System Functions, and Section 3.3.8, System Interfacing Summary.

Fully Functioning Business Applications

These applications provide all the normal business functions of an on-line application built on any other platform. For example, funds transfer, bill payment functions that ultimately maintain data on host applications, and account balance enquiry functions, which reference host data files. The functions involve logic and algorithms; they are not simple 'store and retrieve' functions.

The web provides the interface to these functions via custom developed 'applets' written in Java, C++, Visual Basic, etc. Systems engineering skills are required to develop these types of functions due to their algorithmic complexity.

Again, the main issue that needs to be addressed is the placement of the application boundary, i.e. is the database inside or outside the boundary of the web? Typically, for these types of applications, the supporting databases will reside within separate host applications. Once the boundary issue is resolved, the following functions are counted for the business applications software layer.

Files: Logical Files

Where they exist, the following may be counted as logical files for the Business Applications Layer

  • Host system files and web files maintained by application business functions
    ( not temporary web files)
  • Host system files and web files referenced to retrieve the business data that satisfies available queries

Files maintained are ILF's. Files referenced are typed as EIF if they are sourced from a host application. Files that have been developed specifically for the web application are considered to lie within the application boundary and are therefore ILF's.

Transactions: External Inputs

Where they exist, the following may be counted as EIs for the Business Applications Layer.
  • Maintenance functions on host system files. For example, funds transfer functions.
  • Maintenance functions on data files which reside within the web application boundary
    (These functions may be provided by a conventional application interface)

Where the host application  contributes to the external input function ie by providing the necessary functionality for accessing and updating its data files, this should be counted as per the scenarios described in Section 3.3.6, Duplicate Counting of Front-end and Core System Functions, and Section 3.3.8, System Interfacing Summary.

Transactions: External Outputs/External Enquiries

Where they exist, the following may be counted as EO's and EQ's for the Business Applications Layer.
  • Reporting/enquiry functions on the above files. Apply IFPUG guidelines to determine function type.

Where the host application contributes to the enquiry function ie by providing the necessary functionality for accessing its data files, this should be counted as per the scenarios described in Section 3.3.6, Duplicate Counting of Front-end and Core System Functions, and Section 3.3.8, System Interfacing Summary.

Hybrid Applications

The above categories tend to simplify the situations that can be encountered. Hybrid applications exist which combine all of the above elements. It can be difficult to determine from the presentation layer whether the functionality accessed represents another application, and the type of the application.

Heavy reliance needs to be placed upon the application expert to advise the FP Analyst on the complexities involved. Use the above guidelines in your discussions with the application expert.

Hybrid applications need to be clearly identified by the FP Analyst, and the functionality that does not deliver project functions points should be described in the count report, for example, "application provides x static HTML pages which were not sized using FPA".

Functionality provided by other web architecture components includes:

  • E-Mail functionality
  • Bulletin boards
  • Security functions
  • Browser functions
  • Advertising
  • Links to other web applications/sites.

The main issue that needs to be addressed in counting these components, is to determine whether this functionality has been custom built by the organisation's development project teams or has been provided by web tools and utilities. Only custom built functionality is counted. For example, the ability to download files from other sites is normally handled by standard browser functionality. This is not usually custom built software.

The E-mail, Security functions that address application access control, and bulletin boards are counted using standard IFPUG guidelines.

Advertising provided on web sites can take the form of:

  • image links on static HTML pages - which are not counted (See Static HTML Pages above)
  • links to the ad agency for pictures to display, 'click throughs' to be recorded and reports tabulated, in this case, the work is done by the agency. It is counted as EQ functions by the initiating web site. (See Section 3.3.6, Duplicate Counting of Front -end and Core System Functions, the Agency system is treated as a Core System for counting purposes)
  • custom built advertising - treated like any other custom built functions
  • Links to other Web applications/sites - This functionality is treated in the same way as it would be for non web based applications.
If the user is simply given access to the other application, this is considered to be menu navigation and function points are not awarded. If, however, as part of the transfer, user details, or other data is transferred to the new application, this would be counted as a Control External Output.

Further References:

  • Issue, Front-end Systems - Counting Guidelines
  • Issue, System Interfacing Summary
  • Issue, Security