Other opportunities and metrics can be utilized to obtain the functional size of the software. However, it is our finding that function points have the broadest-based statistical support and also appeal to a wider range of companies. Mark II and feature points can be counted at the same time, with the same level of detail and with the same precision as function points. 3D function points require a greater degree of detail to determine size, which consequently makes counting earlier more difficult. Early estimates of source lines of code (SLOC) are very inaccurate for average to large projects, and coding is such a limited aspect (perhaps 5 to 15% of the total project effort) for software development projects that using SLOC for estimation at any time tends to be erroneous. Descriptions of some additional sizing metrics follow.
Mark II Method
The Mark II method, introduced by Charles Symons, has been utilized almost exclusively in the United Kingdom. Mark II uses the same basic parameters as function points in its calculations. Mark II, however, makes use of fewer parameters and was intended to do the following:
Reduce the subjectivity in dealing with files by measuring the number of entities and their performance as they move through the data structure
Modify the function point method to compute the same numeric totals, regardless of application boundary, as a single system or as a set of related subsystems
Focus on the effort required to produce the functionality rather than on the value of the functionality delivered to the users
Add six additional complexity factors to the 14 general system characteristics
The feature point method, developed by Capers Jones, is a superset of the function point method. It includes an additional component, algorithms, adding to the set of the five function point components: external inputs, external outputs, external inquiries, external interface files, and internal logical files. With the other function point components, the algorithm component is assigned a weighted value. When using the feature point method, the values assigned to internal logical files are reduced.
3D Function Points
3D function points were publicly introduced by the Boeing Computer Services Software Metrics Team in 1991. 3D was developed in response to the call for a technology-independent size metric suitable for all domains.
The 3D method is based upon the premise that the application problem can be expressed in three dimensions: data, function, and control. Each dimension contains some of the characteristics that create complexity in a problem. Sometimes one dimension dominates, but all dimensions of the problem must be analyzed if accurate measurement is desired.
The 3D method identifies characteristics from each dimension that can be measured directly. Data-strong problems are typically associated with IS/business software environments. The data dimension characteristics are taken directly from the function point guidelines and include evaluation of external inputs, external outputs, external inquiries, internal logical files, and external interface files. Function-strong problems are associated with scientific/engineering environments. The characteristics of the functional dimension include the number and the complexity of functions that represent internal processing required to transform input data into output data, and the sets of semantic statements that govern the process. Control-strong problems are associated with real-time environments. The characteristics of the control dimension include system states and transitions.
The COnstructive COst MOdel (COCOMO), introduced by Barry Boehm, evaluates cost factors to estimate effort months. The major input required by this model is the number of source lines of code to be delivered. Since COCOMO was released to the public domain, many models and variations have appeared in the marketplace. A new release of COCOMO will also permit the use of function points as well as object points (which is determined by applying weights to screens, reports, and so on).
Cost factors are also evaluated and weighted within COCOMO for application complexity and software reliability; execution, memory, and environmental constraints; development personnel skill levels; tools and technologies; and a variety of other considerations typical of the capabilities discussed later in this article.