Using Function Point Analysis
for an Object Oriented Methodology

by Koni Thompson

December 2003

Function Point Analysis (FPA) allows you to size the requirements of software independent of technology. Therefore, the newer development methods such as OO and new environments, such as Client/Server and Web Based applications can easily be sized through FPA. First, one must understand the concepts of these newer methods environments. Then, the FPA practitioner can map these concepts to the FPA model.

Object Oriented Analysis

Object Oriented Analysis and Design is a method used to analyze the business problem and solution in unique components called objects. All data necessary to describe both the business problem and the solution are depicted in ?objects?. Details and descriptions of the object are defined as attributes.

Behaviors of the objects are identified by values and changes of the data. Once an object has been thoroughly analyzed, a set of rules are defined which establish the policies of the object ? how the data can be used and changed. This is the basis for our Function Point Analysis.

OO Concepts

An object is an abstraction of something in a problem domain, which is relevant to the application. All like objects share the same characteristics An object is comprised of two parts: data (called attributes) and applications (called behavior).

Since the major part of an OO project is the definition of Objects, we will describe these components in detail to better understand how to apply FPA rules.

Objects are described by properties and can often be mapped in tabular form:

An OO software system is composed of objected sending messages to each other. Objects communicate with each other by sending messages to predefined interfaces through various means: a message is a signal between objects; an operation is a process that can be requested as a unit; a method is a procedural specification of an operation, an implementation of an operation (and are often called services).

Objects are instances of classes. An instance is a unique object created by a class. These are often represented in an Object Model or Class Diagram. The term ?object? is often used interchangeably with the term ?class?. An example of class is Aircraft. There are many types of aircraft, and all share common attributes.

This is depicted is through capturing all common attributes at the highest level of the class diagram (aircraft ? can be defined as a flying machine with wings, wheels and an engine). This implies both an ancestor/descendent concept, as well as the implicit inheritance of the common attributes to those lower classes (jet airplane inherits the attributes of wings, wheels and an engine, but is further defined by number of passenger seats, and other specifics unique to that object).

Another feature of OO Analysis and Design is the concept of polymorphism (which means many forms). This is one of the great selling points of reuse in OO. By using this technique, an object can send a message to another object without knowing the instance?s class.

For example, to send a message from the Object CD Player to the Object Audio, it is not necessary to know which model the CD player is?the behavior of a CD player is to play, start and stop.

This flexibility overall flexibility allows you to define your application (problem domain and solution) by the use of models: Object Models capture the structure of objects in a system and include identity and relationships to other objects, attributes and operations.

Dynamic Modes describe the timing and sequencing of operations in a system and capture events that make changes and changes in state. Functional Models describe the transformation of values in a system and include functions, mappings , constraints and dependencies.

From a FPA perspective, the Object Model is the most important. Included in object models are the various links and associations. For example, an truck ?is a? type of transportation vehicle. Company ?has a? employee. It is this linkage that provides further insight into the application boundary and uses of the data (objects).

Preparing to an Count OOA/OOD Application

First gather the necessary documentation: the Business Requirements and the Object Model. The following process is recommended:

1. Identify the main functions of the application (as specified in the Business Requirements)
2. Identify the main objects that support those requirements (as depicted in the Object Model)
3. Draw a boundary around objects IN the application. Often an object model includes all objects in the problem domain, and can include multiple applications (from a FPA perspective). The objects IN the application are the 1st step in identifying the ILFs from a FPA perspective.
4. Identify those objects USED by the application to satisfy the business requirements. Those objects object become EIFs from a FPA perspective.

OO Considerations for FPA

The following table matches OO components to FPA rules . This mapping should aid you in successfully counting the application independent of technology and implementation techniques . Keep in mind that we are sizing the software based on Business Requirements and are looking at the application from a logical perspective:

By carefully ?translating? OO components into logical FPA components, Function Point counting can be achieved with relative ease. Try your hand at counting the following data model documented in OOA.

OO Data Counting Exercise

• The personnel query system is an application used to request information from the personnel information database. It also permits users to change information in the personnel database.
• Administrators can query, create or delete personnel records and update all personnel information.
• Administrators can also add or delete Title, Location and Organization records.
• All users can query the personnel database.
• Use the following object model and the requirements to identify the ILFs, EI, EO and EQ. We will not assess complexity of these components, the goal of this exercise is to correctly identify the components.

Application Package Suite

This suite provides an out-of-the box solution that integrates an application vendor?s operational application and business intelligence packages into a portal environment.

The suite also provides collaboration services, and an integration bus that enables third-party product integration. This suite puts strong emphasis on prepackaged solutions.

If the application vendor also markets an application server suite, then it is likely that the application package suite will be developed and integrated with that product.

In summary, portal technology will become a key component of other software solutions. In developing a portal strategy the needs of the business should be the primary focus, but it is also important take into account other IT strategies in areas like business intelligence, content management, collaboration, and application integration.

New and evolving technologies like XML and Web Services are also likely to play key roles as portals evolve into software suites.