5. Alternatives to Function Point Analysis
In the article, "Using Function Point Analysis Can Give You Sharp Estimates," John Rakos declares, "… theoretically [the] most accurate method is function point analysis." He discusses three estimating methods commonly used by software developers: expert guess, historical guess, and function point analysis (1993). Often a programmer or analyst will estimate by a "rule of thumb" to determine the magnitude and cost of a software development project that is based on developing similar applications. Generally this is fine, however there must be similar technologies, programmers, and programming languages. The historical guess is a little more difficult for determining what and how much to estimate from documented projects. The expert guess criteria still hold, however the unknown is the lack of experience and interpretation made by the analyst using the documentation to help them with the estimation of a new application. The third method, praised by Rakos, is the function point analysis method for estimating. The analyst can compare past projects with current ones. In addition by factoring in programmer productivity, the analyst is much more certain, without the expert and historical guess restrictions, to estimate accurately (Rakos 1993).
5.1 Lines of Code Based Estimation Methods
Not everyone is a fan favorite of function point analysis. Carnegie Mellon Software Engineering Institute (Carnegie) argues in the Web article, "Software Technology Review," that lines of code (LOC) method is still viable. However Carnegie offers the two LOC based methods, COCOMO (construction cost models) and REVIC (revised COCOMO version), to be reliable alternatives to function point analysis (Carnegie 2000).
5.2 History-Based, Pseudo-Function Point Analysis Estimation Method
Christine Comaford writes in PC Week a less technical version of function point analysis that most software engineers could use without knowing function point analysis (1993). Comaford argues for using historical metrics from projects. There are three steps in determining the estimate for a project. The first step is to determine the amount of time it takes to complete simple, intermediate, and complex tasks for a given function. Second is to rate each function, similar to the zero to five scale when determining function points, GUI screens, reports, tables, queries, etc. The third step is to create a productivity quotient based on novice, intermediate, and advanced programmer skill sets (Comaford 1993). Once these are known, apply this knowledge similarly as the function point analysis method. Using prior experiences and current abilities in evaluation of functions, the analyst can determine the time and cost of future software development projects.
These approaches are to get a handle of the time and cost it takes to develop or maintain applications. Each method represents its own strengths and may be more appropriate to estimate a particular project than another; however, function point embodies fewer restrictions than the alternatives listed above because of its focus - the customer. Function points are customer or requirements based and the customer decides what he or she is willing to purchase in the way of software solutions.