THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

The objective of this paper is to present the Whitemarsh approach to the definition of function points within database-centric business information systems, the process of counting function points, and the use of two metrics derived from function point counts to accomplish business information system estimating.

The following individuals have been helpful in reviewing an early draft: Hank (Henry) Lavender, Russ Eggen, Chris Cordes, Michael Gould, and Rocky Phelps.

Topics Covered

The topics in this paper are:

• Function Points Defined
  
  
• What is Counted
  
  
• What Function Points Measure
  
  
• Computing Function Points
  
  
• Applying Function Point Counts

Function Points Defined

The most obvious first question is: What is a function point?

From Wikipedia: 

A function point is a unit of measurement to express the amount of business functionality an information system provides to a user.

From the Developer Daily:

Simply stated, function points are a standard unit of measure that represent the functional size of a software application. In the same way that a house is measured by the square feet it provides, the size of an application can be measured by the number of Function Points it delivers to the users of the application.

The Developer Daily then provides an example:

A good example is when I had my house built two years ago. I worked with a very straightforward home builder and he basically said “Al, you have two choices here. First, how many square feet do you want to build? Second, what quality of materials do you want to use?” He continued “Let's say that you want to build a house that is 2,000 square feet. If you want to use cheap materials we can build it for $80 per square feet. That's $160,000. If you want to go top of the line then you're looking at more like $110 per square foot, and that's $220,000. What would you like?”

Finally, from David Longstreet:

Human beings solve problems by breaking them into smaller, understandable pieces. Problems that may initially appear to be difficult are found to be simple when dissected into their components, or classes. When the objects to be classified are the contents of software systems, a set of definitions and rules, or a scheme of classification, must be used to place these objects into their appropriate categories. Function point analysis is one such technique: FPA is a method to break systems into smaller components, so they can be better understood and analyzed. It also provides a structured technique for problem solving.

• Breaks Systems into logical business components
• Ordinal Measure
• Sizes business functionality
• Easily learned and applied

Function points are a unit measure for software much like an hour is to measuring time, miles are to measuring distance or Celsius is to measuring temperature. Function points are an ordinal measure much like other measures such as kilometers, Fahrenheit, hours, so on and so forth.

Function points measure software by quantifying its functionality provided 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.

Whitemarsh was very impressed with the function point materials from Longstreet Consulting and highly recommends them for training and consulting on this topic. Their particulars are:

David Longstreet
Longstreet Consulting
2207 SW Walnut
Blue Springs, MO 64015
Web: http://www.softwaremetrics.com/
Email: David@softwaremetrics.com
Phone: +1 816-739-4058

In the approach advocated by David Longstreet, he suggests breaking down business information systems into the object types that have to be built, can be readily observed and can be easily counted. For each object class, create at least two sizes: small and large. Since all Whitemarsh database applications are business information systems, the components that are both readily observable and countable are:

• Third normal form data models
  
  
• Screens
  
  
• Browses within screens
  
  
• Menus
  
  
• Third normal form processes that were hand-coded

The Whitemarsh development environment is Clarion from SoftVelocity. Whitemarsh chose this environment back in the late 1980s because Clarion’s product development direction was toward ELIMINATING the computer programmer from most, if not all, the mundane, boring design and coding of business information system components that are the same through code generation.

By same, it is not meant, same in content, but same in form and style. Content is, of course, individualized to the functional intent of the database and business information system. Thus, while a sales system is inherently different from an HR system, or from an inventory System, or from a customer management system, or from an order entry system, or from an invoicing system, all these systems are can be seen as being built through a standard set of “content independent” information technology building blocks of:

• Third normal form data models
  
  
• Screens
  
  
• Browses within screens
  
  
• Menus
  
  
• Third normal form processes that are hand-coded

What is Counted

In the prior section, what must be counted are those things that must be built by the designer, analyst, or programmer. These include, therefore, requirements, design, and the components of the business information system itself, that is, menus, screens, and the like.

For the purposes of this paper, requirements and design activities are excluded from function point counts. That’s because these activities are completely different from the actual activities of business information system building. Mixing the two sets of activities almost always leads to disaster.

Recently, the “Agile folks” have championed having the steps of requirements, analysis, design, build, and test completely integrated and iterative. That seems to work for only those IT systems that are inherently simple, small, and intuitive. The alternative to Agile is the BDUF approach. That is: Big Design Up Front. That approach, however, also seems to commonly lead to disaster because by the time the BDUF is complete, the problem has either gone away or has substantively changed.

Whitemarsh’s business information system development approach, which was first developed in the early 1980s, and is fully described in the Whitemarsh book, Strategy for Successful Development of Business Information Systems, is a modified BUDF approach. That is, one that is mission and data centric, is combined with prototyping, and ultimately accomplished business information system construction through the use of code generation.

Because of the Whitemarsh development approach and because of the development environment (e.g., Clarion), there is a profound impact on the types and quantity of components that have to be built by the person constructing the business information system.

If, as in the case of Clarion, there are many and very sophisticated templates that can be employed, the very existence of the components and quantities of those components which exist are affected. For example, suppose a browse window that displays a collection of data records, similar to that depicted in Figure 3 has to be built. There exists, at a minimum, the following Information Technology components within that browse window:

• Menu item to invoke the process that displays the browse.
  
  
• Window frame
  
  
• Data browse that lists the columns
  
  
• Vertical and horizontal navigation arrows and implied processes
  
  
• Close button for the window
  
  
• Add, delete and modify buttons and implied data processes
  
  
• Data record sorting by column selection capability
  
  
• Help button and supporting text and display facilities
  
  
• Minimize, maximize, and close window controls

All these components exist independent of whether its construction environment is Clarion or some other Windows-based tool. The question, therefore, is not whether these components exist, but whether they have to be counted to arrive at an accurate function point count. The answer is simple. If the programmer has to construct them, then yes. Else, no.

Similarly, there would have to be component parts breakdowns for every other business information system object type. That is, for data models, menus, screens, and the like. Now, in Clarion, and in other business information system development environments to a greater or lesser degree, many of these business information system components are either greatly facilitated, or generated altogether. Thus, the statement, “the development environment dramatically affects the types of components that either or have to be counted” is a key determination prior to any function counting process. In Clarion, for example, it’s not that these components don’t exist, it’s that because they are automatically generated they do not have to be individually identified nor have to have a function point count assigned to them.

Another issue in function point counting is the state of the business information system process model and its supporting database data model prior to the counting effort. If both the data model and the process model are in third normal form, what is counted and the value assigned to what is counted are greatly reduced.

Most everybody in database understands what third normal form means with respect to data modeling. Bill Kent in 1982 has summarized it simply that a database table’s design must successfully address the following three issues to ensure that a table is in third normal form:

• Single-valued vs. multi-valued facts
  
  
• Dependency on the entire key
  
  
• Independent vs. dependent facts

Every column in the table must represent only single valued facts. Every column in the table must be dependent on the entire primary key of the table, not a partial value of the primary key. Finally, the non-key columns in the table must not rely on another non-key column in the table for a complete understanding of its value-based meaning. When data models are in third normal form, the business information systems that are built to collect, store, retrieve, and delete data are in their simplest form. That’s because there are fewer business information system components to count, which, in turn, causes the overall business information system function point count to be lower.

In a Whitemarsh conducted study in the middle 1980s, the count of business information system components for third normal form data-driven business information systems was 4.6 times lower than for a process driven, but functionally equivalent business information systems.

There is also a third normal form process that is analogous to third normal form data. These processes are characterized by having:

• Only one purpose which is reflected in its name
  
  
• No nested sub processes
  
  
• No logic branching based on data values

Traditionally, these three characteristics are also described by minimizing (e.g., low) coupling and maximizing (e.g., high) cohesion. For a greater explanation, see http://en.wikipedia.org/wiki/Coupling_(computer_science).

When both data and process are in third normal form, there are fewer components to count, and each component is simpler to construct, faster to design, easier to program, and has far fewer programming logic errors. Hence, each such component can have a lower function point count assigned to it. This paper therefore presumes that there has been an effort prior to the actual construction of the business information system to have both data and process in third normal form.

What Function Points Measure

Function points measure the size of a unit of accomplishment within a domain – in this situation, the domain is a database-centric business information system. The classes of accomplishment are those enumerated above (e.g., third normal form data model, third normal form process). The product of function point analysis is the quantity of function points. Function points do not attempt to represent the cost and/or time of accomplishing the unit of accomplishment. That’s determined when the function point count is accomplished through a chosen methodology and development environment.

Suppose, for example, the quantity of work for a business information system was equivalent to a “mile-sized” business information system. While there certainly are no mile-sized business information systems, this serves to illustrate what a function point is and is not. A common question would be: How long does it take to traverse the mile, that is, to build the business information system?

What would an answer of 20 minutes mean? Is the traveler walking fast or slow? To assess that, you’d first have know if the mile is across flat terrain, up and down steep hills, over reasonable turf or through loosely packed sand. Is it a sunny cool day, or driving rain, or 100 degrees Fahrenheit with high humidity? It would also depend on whether the person is a child or a normal size adult. If the walker is a four-year-old child, they are walking very fast, but with short steps. Or if a normal-sized person, the stride would be normal. If the adult is a “fast walker,” the 20 minute-mile would be considered slow.

These measures are not relevant to function points because they relate to the length of time require to traverse the mile. Rather, these measures related to the person, terrain, and the environment. The only valid function point measure for this example would be “feet,” that is, 5280 in a mile. That’s because the measure is independent of the mode, person, or method of accomplishment. For a child, that 5280 feet might be accomplished in 5280 paces. For a normal size adult it might be 2112 paces. The final determiner would be how fast the person (child or adult) is accomplishing each pace to accomplish the 20-minute mile. For the adult, it’s 1.76 paces per second. For the child, it’s 4.4 paces per second. In this case, the child is clearly walking faster.

Function points are not about the length of your stride, how many strides per minute, the weather, or how tall or short you are. Those are all dependent metrics associated with the duration of traversing the mile, the terrain of the mile, or a way of indicating that you walking slow or fast. Function points are independent metrics about the mile itself – that is, that there are 5280 feet in the mile.

A common complaint about function points is that it’s an accurate count only after building the business information system. True enough. Because of this problem, history-based metrics have to be built through an approach such as:

• Determine what classes of objects are to be counted.
  
  
• Determine what defines a simple and a complex object.
  
  
• Determine the quantity of functionality represented by an object class that represents a single function point.
  
  
• Standardize the business information system development methodology
  
  
• Standardize the business information system development environment.
  
  
• Keep accurate metrics about the accomplishment of the several business information system efforts.
  
  
• Classify the types of business information systems that are to be analyzed.
  
  
• Perform a function point count of representative business information systems within a class.
  
  
• Determine the key metrics: quantity of function points per database table, and cost per function point.

The first four steps are essential to “regularize” the business information system environment. Once regularized, and with several already created business information systems, a thorough function point count can occur. Once counted and with the count verified, the quantity of function points per database table can be determined.

Thereafter, the cost per function point can be determined. Armed with those two metrics, estimates of subsequent business information systems can be developed. It is critical at this point that the estimated dollars (and time derived from money) be a guideline NOT a stricture. If the estimate becomes a stricture while there is just a small “statistical sample,” the behavior of the system builders will be affected from what should be normal. Once the key metrics have been stabilized, they can be used with confidence to engineer business information system estimates and schedules.

When this type of effort is performed over a number of different business information systems within each class, the ability to employ function points to make early and accurate estimates of business information system development is possible. The following example shows how function points can be “boot-strapped” into existence within your enterprise.

In the late spring of 2000, Whitemarsh had an opportunity to develop a membership management system for an international organization. Long before this time, Whitemarsh had standardized its business information system development methodology and its business information system development environment. Whitemarsh received the contract to build the system based on best-effort rather than a cost or time estimate. By the middle of the summer of 2001, the effort was finished and the cost to the client was $350K. The client was receiving operational versions of the membership management system with incrementally increasing functionality starting in November 2000.

The effort was functionally object-oriented and except for specialized processes and was 95% code-generated from highly engineered database and functional designs.

In mid July, the IT group indicated to Whitemarsh that the governing board of the organization was concerned about the cost of the effort. Whitemarsh had known of function points, but had never applied it because of the common complaint (see above). Whitemarsh proceeded to perform a thorough function point count. The function point quantity was 6605. Based on billing records, the cost per function point came to about $50. Capers Jones research in 2000 indicated that the cost of a business information system function point was about $455. It was because of the methodology and software development environment employed by Whitemarsh that the cost was reduced by about 90%.

A key metric produced from this effort was the quantity of function points per table. It came to just over 80. That metric is very useful because in a data-driven effort, the quantity of database tables can be determined very early in the business information system development cycle. That metric, coupled with the $50 per function point provides a quick method of estimating the business information system.

The rest of this paper sets out the strategy employed to count function point for the membership management system. This strategy is illustrative of the approach that has to be taken to arrive at a correct function point count for your class of business information system, your development methodology, and your development environment for your organization.

You should carefully review the function point materials at the Longstreet website and tailor these materials to your classes of business information system, your development methodology, and your development environment so that you can develop both accurate counts and also the two key metrics.

One key feature about the Clarion development environment is that it has a DCT metadata file for the database dictionary (the DCT file) and a metadata file for the business information system itself (the APP file). The DCT metadata file contains the database data model that is equivalent to a robust SQL data definition language (DDL) file. The APP metadata file is a pre-code-generation version of the complete business information system. The DCT metadata file can be enhanced with custom coded data integrity procedures. The APP metadata file can contain linked-in custom coded processes.

Clarion takes the DCT and the APP files, along with the linked-in custom coded processes, and automatically generates the actual business information system programming language statements. This set of program code is then compiled, linked and turned into an executable. It is because of the existence of the DCT and the APP files that Clarion can always support changes to the database data model, menus, screens, browses, and hand-coded processes independently one from the other. This is a true use of object-oriented engineering principles of encapsulation, polymorphism, and of metadata-based code-generation-reuse. Clarion is the realization of the promise of object-oriented strategies.

Computing Function Points

As stated above, the class of applications developed by Whitemarsh is database-centric business information systems. These are mainly online systems with several hundred to thousands of database tables. business information systems typically have an overall menu structure on the opening frame of the application. The predominant processes center on add, delete, and modify screens. Each of these screens may, in turn, have multiple browses. Finally, there commonly exists embedded routines for data integrity checking beyond that provided by the database’s data model, and for accomplishing and other processes. These custom-coded processes, if they are in third normal form, range from 5 to 50 lines of source code.

Table 1 presents the quantity of function points per object class for particular object classes. In this example, a Table Reference means a Select, Get, Add, Delete, or Modify to a database table.

Table 1: Object Classes and Assigned Function Point Count

The figures that follow depict that items within a Clarion-generated business information system that are readily available to be counted. Counting other objects in Clarion is a complete waste of time because Clarion auto-generates them. The figures correspond to the object classes in Table 1.

Figure 1: Menu

Figure 2: Simple Browse

Figure 3: Complex Browse

Figure 4: Simple Update

Figure 5: Complex Update

Figure 6: Simple Custom Code Embed

Figure 7: Complex Custom Code Embed

Figure 8: Simple Database Table

Figure 9: Complex Database Table 

Applying Function Point Counts

The membership management system had already been built when the function points were counted. That is the reason why the counts are so precise. Once these counts were created, a key metric, function points per table was computed. At that point, other already built Clarion business information systems were evaluated to assess whether the key metric could have been used to predict their costs. Records had been kept on a daily basis as to the quantity of hours for each business information system. The predictions were all within 10%. The business functions and the counts for the membership management system were:

• Ballot – 0845
  
  
• Committee – 1701
  
  
• Invoice – 514
  
  
• ITI Processes – 2199
  
  
• Meetings – 545
  
  
• Organization – 429
  
  
• Product – 180
  
  
• Representative – 162

The function point total is 6605. The key metric, function points per table was computed by dividing the total function count by the quantity of tables. That is: 6605/ 80 = 82.5 function points per table.

The total quantity of hours charged was then determined. The duration was 14 staff months. The total quantity of staff hours, at 160 hours/month,  was 2240 hours. That meant that each function point took 2260 hours / 6605 function points = 20 minutes. The rate charged the client was $125 per hour. Consequently, each function point cost $42.

To accomplish a rough order of magnitude (ROM) estimate, each table's worth of "business information system" costs 82.5 * $42 or $3,465.

The immediate value of this statistic is that if there is an addition to the membership management system that requires and additional 14 tables, the estimate for that extension should be 14 * $3,465 =  $48,510.

It must be stated that the $42 per function point was for the actual building and testing of the membership management system. The estimate did NOT include business information system documentation or end-user documentation.

The experienced-based estimate for system and user documentation is 60 hours per main function (e.g., Ballot, Committee, and Invoice). Hence, 480 more hours. When this 480 additional hours are added to 2260, the result (2740) elevates the time to create a function point to 2760 staff hours /6605 Function Points or 25 minutes. At the rate of $125 per hour, that’s $52.23 per function point.

Conclusions

The practical application of the points made in this paper include:

• Reliable and repeatable function point counts can be determined for specific classes of business information systems.
  
  
• It is critical to standardize the business information system development methodology and business information system development environment to standardize the objects that exist and are able to be counted.
  
  
• It is bottom-line extraordinarily valuable to employ development environments such as Clarion (www.softvelocity.com) that generate the vast majority of any business information system,  reduce function point cost, and eliminate the vast majority of coding bugs.

Without development environments such as Clarion, function points cost upwards to about $450 versus about $50.

References:

The following references to Whitemarsh materials provide a more detailed exposition of practical application of the significant content of this paper. The following documents are available free from the Whitemarsh website:

The following documents are available for Whitemarsh website members. The URLs that follow provide descriptions of the pages. Members should log in and proceed to the appropriate page (e.g., Enterprise Database), find the book, paper or course and perform the download.

The following Whitemarsh books, which can be ordered from the Whitemarsh website, contain material related to this short paper.

• Strategy for Successful Development of Business Information Systems
  
  
• Data Interoperability Community of Interest Handbook
  
  
• Enterprise Architectures