Software Cost Estimation Methods

One of the critical functions to be performed, especially at the begining of the software project, is Cost Estimation. Software Cost Estimation can be done in many ways and there had a been a lot of research on this topic. Following are most used methods for software cost estimation:

1. The Function Point Method

The Function Point Method (FPM) was developed by IBM. It is a combination of the analog method (the FP curve is based on the empirical values from similar projects) and weighting method (evaluation of the influence factors for the project). The effort estimation takes complexity, certain software characteristics, and productivity into consideration. The Function Points (FP) are applied as a measuring means for the productivity used to specify the effort.

Following are the steps taken for Cost Estimation using Function Points approach:

• Determination of the Function Points: In order to determine the Function Points, the functions are defined and classified, according to external input, external output, logical internal file, external interface file, and external inquiry (various types of transactions). After that, these transactions are classified according to the degree of their complexity (simple, average, complex). Based on the type and the degree of complexity, the transactions are weighted. The addition of these weights of all transactions results gives the unadjusted Function Points.


• Determination of the adjusted Function Points: Influence factors like interlacing with other projects, decentralized data management, transaction rate, complex processing, reusability, conversions, user friendliness are taken into consideration and evaluated with regard to the influence they are having on the project. The degree of influence is calculated from the sum of the influence factors. Multiplying the unadjusted function points with the degree of influence results in the adjusted function points. As compared to the (unadjusted) function points, these can be increased or reduced by up to 30 %.


• Determination of the Effort: Based on a productivity curve/table, the adjusted function points are converted into man-months. To realize this, an "IBM curve" is available which should be successively replaced by individual empirical values from post-calculations.

1.1 Application of Function Point Method

• Commercial Application: FPM is particularly suited for Information Systems developments; the effort estimation for data core system developments (small data volume, processing-oriented) is not sufficiently exact. This is due to the classification of the functions on the basis of the data to be processed, the processing complexity is globally evaluated as an influence factor across all functions.


• Development Project: The FPM procedure is not suited for SWMM projects. Normally, the basis for the estimation and the influence factors in an SWMM project have not been noticeably changed as compared to the ones in the development project. On the other hand, however, SWMM-based measuring quantities (like "additional input data") and influence factors (e. g. "personnel continuity") are lacking.


• Function-Oriented Engineering: Function-oriented engineering is no requirement for the FPM application. However, this type of methodical development facilitates the application of the FPM since it already covers the step to determine the transactions.

2. Estimation by Analogy

An analogy is a technique used to estimate a cost based on historical data for an analogous system or subsystem. In this technique, a currently fielded system, similar in design and operation to the proposed system, is used as a basis for the analogy. The cost of the proposed system is then estimated by adjusting the historical cost of the current system to account for differences (between the proposed and current systems). Such adjustments can be made through the use of factors (sometimes called scaling parameters) that represent differences in size, performance, technology, and/or complexity. Adjustment factors based on quantitative data are usually preferable to adjustment factors based on judgments from subject-matter experts.

The major caution of the analogy based estimation method is that it is basically a judgment process and, as a consequence, requires a considerable amount of expertise if it is to be done successfully. There are two types of analogues that may be used. One is based upon similar products/services and the other upon similar concepts.

In estimating software costs using analogy, first we have to determine how best to describe projects. Possibilities include the type of application domain, the number of inputs, the number of distinct entities referenced, the number of screens and so forth. The choice of variables must be restricted to information that is available at the point that the prediction is required. For this reason LOC is generally unsatisfactory as it must be estimated. The choice of variables is flexible, although one will wish to choose variables to characterise the project as accurately as possible. It is also important to choose at least one variable that acts as a size driver, for instance number of inputs or screens or classes. Analogies are found by measuring Euclidean distance in n-dimensional space where each dimension corresponds to a variable. Values are standardised so that each dimension contributes equal weight to the process of finding analogies.

3. Algorthmic Modelling Method of Estimation

3.1 Basic COCOMO

This is a simple on-line cost model for estimating the number of person-months required to develop software. The model also estimates the development schedule in months and produces an effort and schedule distribution by major phases. This model is based on Barry Boehm's Constructive Cost Model (COCOMO).

The model estimates cost using one of three different development modes: organic, semidetached and embedded. The different modes are discussed in detail below:

• Organic: In the organic mode, relatively small software teams develop software in a highly familiar, in-house environment. Most people connected with the project have extensive experience in working with related systems within the organization, and have a thorough understanding of how the system under development will contribute to the organizations objectives. Very few organic-mode projects have developed products with more than 50 thousand delivered source instructions (KDSI).
  
• Semidetached: The semidetached mode of software development represents an intermediate stage between the organic and embedded modes. "Intermediate" may mean either of two things:
  
  
  
  • An intermediate level of project characteristic.
  
  
  • A mixture of the organic and embedded mode characteristics.
  
  The size range of a semidetached mode product generally extends up to 300 KDSI.


• Embedded: The major distinguishing factor of an embedded-mode software project is a need to operate within tight constraints. The product must operate within (is embedded in) a strongly coupled complex of hardware, software, regulations, and operational procedures, such as an electronic funds transfer system or an air traffic control system.

3.2 COCOMO II

COCOMO II is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity. It consists of three submodels, each one offering increased fidelity the further along one is in the project planning and design process. Listed in increasing fidelity, these submodels are called the Applications Composition, Early Design, and Post-architecture models. Until recently, only the last and most detailed submodel, Post-architecture, had been implemented in a calibrated software tool. COCOMO can be studied in greater detail here and a process for calibrating Post-architecture model can be found here

4. Top-down Cost Estimation Method(TCE)

A standard top-down cost estimation process typically consists of the following steps:

• Searching a software functional classification table for the same type of software being developed, with matching functions, such as a word processor, and identifying the standard cost for that type of software


• Adjusting the standard cost by considering the developer's business strategy such as "the top priority maintaining quality."


• Re-adjusting the above adjusted standard cost by considering the development environment (such as the ability of the programmers or the availabilty of hardware and software tools).

4.1 Assumptions

• Each type of software has its own intrinsic characteristics: such as functional complexity, performance requirements and sophistication level of the user interface.


• The software development costs and worker hours are both affected by software characteristics, corporate strategy, adn the available development environment.

4.2 Implementation

Implementing and evaluating an operable TCE system must go through four phases. The four phases are bnriefly explained below:

4.2.1 Phase 1 (Construct a software taxonomy table)

In phase 1, we make a software taxonomy table that covers all software products. Of course, there are various way to classify software, some of which are detailed below:

• Operating systems: job management, data management, task management, device drivers.


• System utilities: security, file management, library management.


• Network: Internet, client/server system, dataware, groupware, network management, distributed object environment, network protocols, infrastructures.


• Language Processors: COBOL, C/C++, FORTRAN, Java, documentation languages(e.g, SGML).


• Database: tree structure, network structure, realational database, distributed databases.


• PC-related standard software: word processor, spreadsheet,


• Applictions: banking and securities system, reservation system, financial system, inventory control system, electronic commerce application, etc.

4.2.2 Phase2(Construct a standard cost table)

In phase 2, we provide the following information for each type of software:

• Standard cost


• Weightings to correspond to emphasized goals such as "performance is not a major consideration," or "critical".


• Weightings to correspond to emphasized GUI goals such as "a simple GUI is enough," or "a meticulously designed is essential."

4.2.3 Phase 3(Develop adjusting procedures)

In phase 3, we provide weightings for reflection corporate strategic characteristics, and then provide weightings that reflect the environmental characteristics.

4.2.4 Phase 4(Perform experimental evaluation of the TCE)

In phase 4, we evaluate the predictability and sensitivity of the TCE.

Depending on the type of software being developed, any of the above four methods can be applied. Cost estimation helps in ensuring that projects are optimized for costs, and helps in proper monitoring of projects based on the actual effort and the expected effort, in effect ensuring software quality, which is better known as software quality assurance.