Estimating Software Costs – Computer Program Management

By Youssef Edward
December 21, 2018

Here is presented how to Acquire and evaluate technical data for projecting schedules and resource requirements, including planning versus actual data; data to define, design, implement, and evaluate systems; data on the system environment; and data at the system, subsystem, and module levels.

Such a project management system is essential if management estimates are to have any degree of accuracy.

Estimating Guidelines

The guidelines listed below can be used for estimating large software development projects. This includes any project that involves more than eight full-time professionals and whose eventual size will exceed 100,000 lines of source code.

System Design Phase

  • Requirements analysis—5 to 19 man-weeks, depending on the nature of the project
  • Total system design—one to three man-months
  • Software system design—10 percent of total man-months
  • Review of system design with user—three man-days per design document
  • Training—one month for programmers if analysts turn over design to programmers

Production [

  • Develop system test plan—one man-month per 10,000 estimated instructions
  • Program design—one man-month per 1,000 instructions
  • Program file design—one man-month per 10,000 items
  • Establish system files (used by more than one program)—two man- months per 10,000 machine instructions
  • Program coding—gross estimates: one man-month per 5,000 machine instructions Program Testing.
  • Familiarization with procedures—one week
  • Individual program testing—approximately 20 percent of the testing effort
  • Subsystems testing—from 0 to 30 percent of the total testing effort, depending on the number of subsystems
  • System testing—approximately 50 percent of testing effort; about 25 percent of total effort

Design, Coding, Debugging, and Testing Estimating

The following formulas can be used to determine the man-months required for program design through testing:

man-months = 4.495 x (The Number of Thousands of \ Source Code Instructions)

Note that the second formula is to be used for small business systems where the number of source code instructions is to be less than 10,000.

Project Administration and Data Collection. Guidelines for data collection and reporting represent a most essential support component. Accurate, timely, and uniformly understood data is needed by managers at all levels for the planning, organization, and control of a project and for the communication of project information within and outside the project structure. Guidelines are applicable to all levels of management in a software development project since the information requirements of all managers are essentially the same, differing only in the level of detail required.

Managers are cautioned that there are several problems regarding project data that require flexibility on their part. The most difficult of these problems is a lack of understanding of what the software development and management process should be. The many studies on the subject emphasize the difficulty and complexity of the process but have done little to reveal a well-defined method ology or to delineate precise relationships among project variables. Thus, we do not know precisely what data is required, when it is required, or in what form it is required to enable managers to make sound estimates. Such knowledge, however, will come not from additional studies but from the monitoring, evaluation, and refinement or modification of established procedures.

A related problem is that of defining programmer productivity, since most estimates discussed here relate to the determination and prediction of productivity. Quantity of source code produced, expressed in terms of lines of code per time period, has been the most widely accepted measure but has never become an industry standard. One problem with this definition is its lack of precision. This is not a particularly serious problem, however, since greater precision would simply be a matter of interpretation. A more serious problem is the narrowness of the definition. There is ample evidence to suggest that a good definition of productivity should have elements that address the correctness, efficiency, and complexity of programs.

Finally, data collection and reporting requirements are implemented to gether with certain development methodologies that can be lumped under the term structured programming technology. Such technology requires increased collecting, analysis, and reporting of management data and, to be truly effective, requires the support of a software development library. A library allows data items to be collected and counted in a standardized manner and a focal point (the librarian) to be established for manually collected data items and as a source of control on the collection process. Note that a library facilitates the merging of technical and management or administrative data. Such a development library, however, requires a disciplined approach to development, which is not always welcomed.


A reporting system uses as input a base of estimated and actual data on a project’s environment, system module descriptions, resource costs, processing resources, and program production. The data is gathered and stored in a computerized data base. Data is added to, deleted from, or replaced from this data base during the course of a project. Additional capabilities must exist for summarizing, sorting, and otherwise processing the data. Reports are generated and disseminated for project support and historical purposes. Thus, the functional requirements of the system can be expressed as processing functions: collecting, updating, processing, reporting, and archiving.

Two classes of data are required to plan and manage a project: planned data is developed during the planning phase of a project and is derived in part from actual data on previous projects; actual data is collected during the course of the project. Within these two classes, five types of data should be collected:

  • Project environment—general data of a static nature, defining the scope of the project.
  • Module descriptions—data that is usually automatically collected and that applies to programs, subprograms, and units of a system.
  • Service data—This type of data is limited to turnaround time for various sources of computer service.
  • Cost data—All cost data, from personnel costs to travel costs, falls into this category.
  • Production data—includes all characteristics related to the production of source code and includes quality assurance and programming data (e.g., categories of source-code updates, enhancements, changes to functional requirements, and errors).

A project manager requires information on the general project characteris tics, project and program status, quality of the products produced, use of resources, and adherence to standards and guidelines. The following report classes provide this information:

  • Statistics on programs, subprograms, and units
  • Production statistics
  • Use of computer resources
  • System design/program structure
  • Historical/summary data
  • Combinations of the preceding

Certain reports should be produced on a fixed reporting cycle. This is determined by management and usually depends on customer requirements. All reports should be available upon request. Project managers should be responsible for all data collection and reporting activities but should delegate some authority for collection and reporting to the appropriate organizational levels or functions within the project.

Management Reporting. The contents of management reports are derived from the data items previously listed and from calculations based on these items. The reports defined here are primarily technical in nature and deal with the project per se:

  • Status Reports—used by managers in determining the status of the source code during production and testing phases
  • Update Reports—used by programmers and managers in tracking unit, program, and system update activity during production and testing
  • Time Reports—used by managers in monitoring, optimizing, and allocating computer test time during the design and production phases
  • Project History—used by prospective project managers and middle management for planning and control purposes
  • System Cost Reports—used by managers at all levels, but principally by project managers, in the monitoring of development costs


It is clear that the software manager faces a lack of adequate historical data on completed software development projects, a lack of precise understanding of the variables influencing programming, and an inability to determine just how much work is to be accomplished on a given software development project. Furthermore, few standards and management controls are enforced.

There have been a few significant trends in programming during the past 15 to 20 years. The use of online systems is one of these, and it has already been discussed. Structured programming is another, more fundamental trend. What ever the merits of the various components of structured programming, the many experiments with this discipline represent the first serious attempt at under standing programming and its many aspects; more important, they imply the recognition that programming is not simply a tool to be used by subject matter specialists but is a discipline in its own right.

Structured programming technology includes [

  • Top-down structured programming
  • Program support libraries
  • Program design languages (PDLs)

Although it does not currently appear that the use of PDLs has a significant bearing on estimating techniques, given the importance of system design, their use should be significant. It is too early, however, to evaluate the extent of this impact.

The use of top-down structured programming will, on the other hand, definitely help the standards and control problem because it is a set of standards and controls. Top-down development and integration reduces or eliminates the unpredictable cost elements of redoing interfaces and modules, hence alleviating the problem of work determination. Unfortunately, we do not yet have enough experience to know the magnitude of these effects. It is equally unfortunate that structured programming does not appear to have any direct impact on our understanding of the factors affecting programming, although the data collection inherent in using a programming support library may eventually bear some fruit. Note that the development and use of a programming support library can be invaluable in collecting data on software projects, with such data to be used on future projects for estimating purposes.


The Critical Nature of Requirements

Many groups involved in the development of new programming languages have concentrated on giving the programmer a greater variety of tools with which to express programs. Recently, however, evidence shows that the most serious software errors are caused by problems in requirements engineering and design specification and that coding errors are best avoided by simplifying programs and languages, not by adding to them.. In addition to the repair cost problems, the lack of good requirements specifications causes other difficulties:

  • Top-down design is extremely difficult when there is no well-defined ‘‘top.’’
  • Testing is difficult if one is testing against ill-defined specifications.
  • It is difficult to convince users and management that they are really a part of the development effort if what is being developed is poorly specified.

Present Status and Future Technology

Software requirements are generally written in free-form English, an ambiguous form of communication. Such terms as real time, sufficient, and reliable abound, as do more precise-sounding but equally vague terms as 99 percent reliable. Determination of requirements, when done well, is usually performed using various ad-hoc techniques and common sense. When such determination is done poorly, it generally follows guidelines dictated by preconceptions.



The impact of many factors and trends on programming costs is acknowledged but poorly understood. Some of the most important questions requiring further study and understanding are:


  • What is the productivity of the average programmer, and what factors affect it? How do we know when we have identified the proper parameters? Given data on a specific project, how do we know if a resulting productivity is caused by project complexity or poor design? Is a high error rate a result of project size or poor functional specifications?
  • What impact does complexity have on a software project? Wolverton [ cites an increase in the cost of a complex project (e.g., a real-time project) ranging from 3 to 5.5 times the average, but we do not know what factors contribute how much to complexity.
  • What resource constraints (e.g., memory or execution-time limitations) affect productivity and reliability?
  • How does productivity vary with programmer ability, and what effect will the Chief Programmer Team concept have on this?

The manager of software development can do much to answer some of these questions for his organization. Adopting a structured programming methodology is a good place to start, particularly using a programming support library. Of the other factors likely to be influential, the following should receive the closest attention:

  • The use of programming support tools
  • Precise specification of functional requirements
  • Programming languages
  • Test turnaround time
  • Programming practices and standards
  • Number of lines of source code
  • Project complexity
  • Volume of documentation
  • Number of files per program
  • Access methods and data structures for files

Once gathered, this information should be augmented by similar data obtained, as available, from sources outside the organization. The manager can then adapt the programming practices in his organization to improve productivity and reliability of the software developed under his management.



Wolverton, R.W. ‘The Cost of Developing Large Scale Software.” TRW-SS-72-Ol (March 1972).

  1. Putnam, L.H. “A General Empirical Solution to the Macrn Software and Estimating Problem.” IEEE Transaction on Software Engineering. Vol SE-4, No. 4 (July 1978).

Leave a Reply

Your email address will not be published. Required fields are marked *