Programming cost estimate: Is it reasonable?

  • Authors:
  • Robert E. Boydston

  • Affiliations:
  • -

  • Venue:
  • ICSE '84 Proceedings of the 7th international conference on Software engineering
  • Year:
  • 1984

Quantified Score

Hi-index 0.02

Visualization

Abstract

A basic concern when considering a programming cost estimate is its reasonableness. A statistical examination of over thirty completed products was conducted, using least square error methods, to develop an improved method for establishing a central value and an acceptable range of values for programming product cost estimates. Eight variables associated with the coding process, such as the number of lines of new and modified Basic Assembler Language and number of new modules, were found to be useful in developing reasonableness equations. Using regression equations developed from the variables, we developed reasonableness tests that compare the estimate prepared by the developer to the actual development effort applied to previous products. Insight also was gained about programmer productivity, the quality of code estimations, and the optimum number of lines of code per module. Estimates are usually based on the experience of the past. But whatever method is used, the main consideration is the error of estimate associated with that method. The basic question about any estimate is: how good is it? The current state of the art of the cost estimating of software projects evolved from the works of Walverton1 attempting to correlate the size of effort in person-months with the size of the product expressed in Thousand Lines of Source Code (KLOC). Large dispersion of data forced Walston and Felix2 to take into account additional variables such as programmer experience and the complexity of the application as well as over twenty variables. Putnam3 simplified staffing (life cycle curve) to a small and easily managed set of parameters that could be expressed in the form of nomograms. This paper contributes to the software cost estimation by identifying those variables of the product which were found to be governing: The importance of distinguishing higher level language Programming Language Systems (PLS) from low level Basic Assembler Language (BAL), the importance of recognizing the major increase of effort if code is modified rather than new code created. The magnitude of these differences is quantified. Finally in the analysis of the optional number of modules for a product, a balance is shown between the intramodule complexity and the intermodule complexity. Parametric data associated with program product development costs has been actively collected since mid-1976 by the Program Cost Estimating Department, now located at IBM's Santa Teresa Laboratory. This data represents the actual person-month resources used to match program development requirements. Products that were analyzed are a collection of classic IBM mainframe products: languages (such as Cobol, PL/I, APL), utilities (VSAM, OS utilities, sort, etc.), and data base products (IMS, Data Dictionary, etc.). These are “system programs” rather than applications. The range and median sizes of the products are shown in Table 1. Twenty six of the thirty products contain modified modules.