The basis of any industrialized software project is the initial cost estimate. Resources must be planned, costs estimated, and milestones set by the end of the project. Since the beginning of software development, software programming performance has been rated with metrics. Personal Days (PT), Lines of Code (LOC), Story Points (SP) or the price of the service per programming lesson (€) were used. All of these metrics allow only a limited inference of the objective programming performance or the actual scope of purchased or programmed software. Today’s productivity factors are mostly subjective and especially with purchased programming services, the providers are difficult to compare. Simple and standardized metrics are needed to estimate development performance.

There are different methods for estimating the cost of work, which are selected and combined depending on the project situation. When estimating the correct effort, it should be noted that the numerical value is always indicated with an inaccuracy (variance). Many years of estimation have shown that estimates rarely deviate downwards. The actual implementation effort for the majority of software projects is significantly higher than the initial estimated value. When a project is rough, the variance can be up to 40 percent of the estimated value. The correctness of the bottom-up estimate of a software project should move in the 20 percent corridor to the actual implementation effort.

Depending on the complexity, priority and size of a project, different methods of expert estimation are used. The simplest estimation methodology is the estimation by an exceptionally experienced senior project manager. Due to the numerous completed software projects, this expert is very easy to estimate the concrete effort for the different project participants. The larger the projects become, the more important multiple expert estimates become. Depending on the need, one of the following estimation methods is recommended: multiple survey, Delphi method or carrying out an estimation claw.

Modern software development teams tend to evaluate the technical implementation complexity of the requirements. As a result, you get the complexity rating in the form of story points, T-shirt sizes or function points. Based on historical experience, this complexity assessment can be insatiable to the actual implementation effort. In general, complex mathematical models for conversion should be dispensed with as they convey a deceptive security. Experience has shown that a simple conversion (e.g.: 1 Function Point can be implemented with 2 person-days effort) is the most cost-effective and objective method for getting from complexity to implementation effort.

Functional software size as an objective metri

In general, goods can be defined and made comparable by metrics. For example, residential sizes in square meters and motors in horsepower (recently KWh) are measured and compared. In order to enable this measurability also in information technology, the system of Function Points was developed. Function point analysis is a methodology used to assess the technical-functional scope of a software system. The Function Point process was founded in the late 1970s by Allen J. Albrecht, who worked for THE US company IBM. The valuation result, the Functional Size, is specified in the Function Points unit of measure. In software development, the Function Points are used as a basis for cost estimates. The key figures calculated with Function Points can be used by companies to compare offers or specifications of IT projects. The advantage is the determination of key figures without a connection to technical details, such as used programming languages or system conditions. The determined Function Points (FP) can thus be used transparently as a basis for cost estimation or benchmarking and support controlling in key figure analyses

The Base: Counting Practices Manual

The FPA is carried out on the basis of the Rules of the Counting Practices Manual (CPM, Release 4.3.1) of the International Function Point User Group (IFPUG). This manual is based on the standards of “ISO/ IEC 20926:2009” or “ISO/IEC 14134-1:2007” and contains numerous definitions, rules and examples.

The valuation scheme

For the determination of the functional size, the user view is a central paradigm. For evaluation, therefore, only those functions of the software that are used in the respective business processes and which bring with it a perceptible optimization effect for the user are taken into account.

The concept of the user in the FPA is conceptually equivalent to the actor. A user does not necessarily have to be a natural person, but can also be another system (e.g. a machine).

The concept of user view is therefore by no means to be taken literally. The user’s view focuses on the fact that only those functions of the software that serve to support the respective business processes are to be taken into account in the evaluation. The user’s view can be presented verbally by the user or available in various forms (requirement document, detailed specification, user manual).

Performance orientation through Function Points

By analyzing existing development services – irrelevant whether externally commissioned or provided by internal resources – a determination of the performance of the development can be measured over several releases. These analyzed historical values are used to calibrate this methodology and enable the determination of unit costs for an implemented function point. In addition to the source code, the historical values of the development and the documentation of the developed functionalities must be made available.

Reference values are available for software development performance with reference values related to function points. Depending on the technology used, the unit cost for an implemented function point amounts to an average of 1.5 to 3 person days.

The introduction of regular cost estimates and the measurement of the functional size of software can realize savings of up to 35 percent in software procurement. The savings are achieved by improved planning during software development, more transparent tracking of changes, and the more complete pre-transfer specification.

The graphic below shows the performance of a development team. The average number of person days required per Function Point is shown. For each release container, neutral unit costs can be calculated and thus the performance of the team can be measured objectively.

Automated Estimation Manager – ReqPOOL Estimation Manager

The first process step in a procurement process is the cost estimation. With the Estimation Manager, you can quickly and easily determine the scope of your project and reduce complexity to meaningful parameters. This gives you and your project participants a quick and convenient initial assessment and cost calculation of your project.

The ReqPOOL Estimation Manager is available as a cloud & on-premise web solution and as an Excel front end with a central estimation engine.
To realize the full potential of Estimation Manager, you only need to enter eight project parameters:

Project parameters for the calculation:

• Masks: Number of user interactions
• Use cases: number of functionalities
• Data Objects: Number of Business Objects
• Interfaces: Number of connected systems
• Batches: Number of timed functionalities
• Languages: Different language and culture circles
• Roles: Number of roles in the software system
• Number of users

The implementation costs are calculated using two scientifically proven and award-winning algorithms, the expert and learning algorithm. The algorithms and the scientific derivation are documented in the IEEE Xplore® Digital Library.

Insights» Effort estimation of software