Software Estimation and Function Point Analysis Presented by Craig Myers MBA 731 November 12, 2007

Why use software estimation tools? Large software projects have traditionally had a very high frequency of schedule overruns, cost overruns, quality problems, and outright cancellations of large systems. The root problem of most projects is inadequate planning and estimation. –usage of automated estimating tools, automated project scheduling tools, and automated defect estimating tools are strongly correlated with successful outcomes.

History of Function Points Function Point Analysis was developed first by Allan J. Albrecht in the mid 1970s. –It was an attempt to overcome difficulties associated with lines of code as a measure of software size –Also an attempt to develop a mechanism to predict effort associated with software development. –Method first publicized in 1979 –Used in software estimation tool first time in International Function Point User Group (IFPUG) established in –Used to exchange information on Function Point Analysis –Several versions of the Function Point Counting Practices Manual have been published by IFPUG.

What are Function Points? Function Points are Units of Measure –Unit of measure for software much like an hour is to measuring time, inches to measuring distance and Fahrenheit to measuring temperature. –A unit of measure is important to understanding and communicating such metrics as Average Costs, Average Time and so forth. –For example understating the cost per square foot to build a house, help a buyer to compare one house to another, also helps the builder to understand the cost and predicts future costs.

Function Point Analysis Function Point (FP) Analysis is a standard method for measuring software development effort and size from the user/customer point of view. The size of the new or ongoing development project is expressed in Function Points. Function Points measure what is delivered to the customer, not how it is delivered, i.e. irrespective of which language is used for coding. –Measures software development independently of technology used for implementation

When is Function Point Analysis Done? Function Points for the system or application may be analyzed any time during the software development life cycle after high-level user requirements are completed. When a count is done early in the life cycle of a project, it is called a Function Point Estimate and approximates a project rather than measures it. Assumptions can be made in the early counts, but they should be documented. Accurate function point estimates can be made when the detailed user requirements are complete.

For what purpose is Function Point Count used? Function Point Analysis sizes the functionality delivered to the customer based on the user's Business Requirements. The resulting Function Point Count provides a basis for creating a variety of valuable software process performance and quality measures which can be used for benchmarking as well as for measuring the improvements in the software development process. The Function Point Count facilitates determining project effort and size, and hence costs, duration (in calendar months), quality (potential defects and complexities) and productivity (man-months). Counts done early in the project life cycle can be used for project estimation, such as man-months required, the duration of the project, testing time required, or the number of resources required.

Types of Function Point Counts Development Project Function Point Count –This type of count is associated with new development work. »Scope creep can be tracked and monitored by understanding the functional size at all phases of a project. Enhancement Project Function Point Count –All production applications evolve over time. »By tracking enhancement size and associated costs a historical database for your organization can be built. »Additionally, it is important to understand how a Development project has changed over time. Application Function Point Count –Application counts are done on existing production applications. –Can be used to track maintenance hours per function point. »Need to examine the ratio of maintenance hours to size of the application to get a true picture. –Can assist organizations in understanding the size of the entire corporate portfolio (or inventory).

Adjusting Function Point Counts The general characteristics of the system under consideration for FP analysis must be accounted for and their influence on the system factored to get the total number of Adjusted Function Points. This is done by examining 14 general system characteristics of the system, such as the transaction rate, performance, and installation ease. Each characteristic is evaluated by its degree of influence on the system. The total degree of influence is used in a formula to give the Adjusted Function Point Count, commonly called the Function Point Count.

Understanding Software Productivity Software Productivity = Function Points / Inputs productivity can be improved by: –increasing outputs with the same inputs –decreasing inputs but maintaining the same outputs –Increasing outputs and decreasing inputs change the ratio favorably. Software productivity is defined as hours/function points or function points/hours. –average cost to develop software or the unit cost of software –The unit cost of software is not fixed with size »the unit cost of software actually goes up with size

How does size impact productivity? As the size of software development project becomes larger the cost per function point actually rises. –Because tasks are not the same for software projects as the size increases.

Example Source: Introduction to Function Points By: Carlos Colon Riollano

Benefits of Function Point Analysis Can be used to size software applications accurately. –Sizing is an important component in determining productivity (outputs/inputs). Can be an essential ingredient to measuring and managing scope creep. Can be the basis of creating estimating models, which can be explained, revised and accurate. Can be used with other metrics and can help pinpoint opportunities for improvement. Can help improve communications with senior management. Can be counted by different people, at different times, to obtain the same measure within a reasonable margin of error. Are easily understood by the non-technical user. This helps communicate sizing information to a user or customer. Can be used to determine whether a tool, a language, an environment, is more productive when compared with others.

When not to use Function Points When sizing maintenance efforts (fixing problems) –Much of the effort associated with fixing problems (production fixes) is due to trying to resolve and understand the problem (detective work). –Another inherent problem with measuring maintenance work is that much of maintenance programming is done by one or two individuals. » Individual skill sets become a major factor when measuring this type of work. »The productivity of individual maintenance programmers can vary as much as 1,000 percent. When trying to understand performance issues –Performance tuning may or may not have anything to do with functionality. »Performance tuning is more a result of trying to understand application throughput and processing time.

Why not just use Lines of Code? The number of lines of code delivered is dependent upon the skill level of the programmer. –In fact, the higher skill level of the programmer the few lines of code they will develop to perform the same function. The actual number of lines of code is not known until the project is almost completed. Lines of code cannot be used to estimate the effort or schedule of a project. Function Points can be derived from requirements and analysis documents that are available early in a project life cycle. There is no agreed upon method to count lines of code.

Summary and Conclusions Accurately predicting the size of software has plagued the software industry for years. Function Points are becoming widely accepted as the standard metric for measuring software size. Understanding software size is the key to understanding both productivity and quality. Currently, function point counting is a time-consuming and largely manual activity unless tools are built to assist the process. –An ISO-level standard is still in the making.

References ESTtools.pdfhttp:// ESTtools.pdf Carnegie Mellon Software Engineering Institute