Estimation of effort (software technology)

from Wikipedia, the free encyclopedia

Cost estimation or -estimation or cost estimate is in the software engineering is a part of the planning of a software project or a work package. It estimates how many people and how much time are required for the individual work steps or program parts, which resources are needed and what it ultimately costs. Costs, deadlines and required resources are the basis for an offer or for a decision as to whether, how and when a software project or work package will be made.

Structure of costs

In the field of software development, the main costs are personnel costs ; the estimate therefore mainly refers to it.

There are also material costs (if not included in the personnel costs ) such as B.

  • required computers,
  • Computing times and network costs,
  • Licenses for operating systems and tools,
  • Test hardware,
  • Courses,
  • Traveling expenses.

These often depend on the personnel costs, because the longer a project lasts, the more people are involved, the more material costs are incurred.

Considerable commercial surcharges are necessary for the expected total costs, for example

  • Realization risk (a large part of the IT projects is canceled, is not feasible, etc.)
  • Safety surcharge for misjudgment (iceberg factor)
  • Pre-financing costs
  • Inflation, increase in personnel costs (for longer-running projects)
  • Exchange rate risks (for foreign projects)

Personnel expenses

The estimation method depends on the size of the scope of the task (i.e. estimation before estimation).

For the estimation of smaller activities, e.g. B. Work packages in an ongoing project or changes in an existing system are mostly used the assessment exam or Delphi method , because here the judgment of those involved provides the best and cheapest estimate.

For the estimation of very large projects, the comparison with other very large projects is usually used, with surcharges and discounts then the costs for the current one are roughly estimated. The large pot is then distributed by breaking down into individual subtasks. Estimates are then made for these subtasks. These can then be added up again.

The basic structure for estimating the personnel costs of a medium-sized project is:

Quantity × price × competence factors

This can be done for individual parts or phases and the costs can then be added, or for the entire project.

Dimensions (quantities)

Common dimensions for programs are Lines of Code (LOC), Function Points (FP), DSI (Delivered Source Code Instructions), and document pages.

According to Watts Humphrey (author of The Personal Software Process ), most people are not very good at directly estimating the amount of time it takes. Instead, one can predict the size of the program code with astonishing accuracy. The expected time expenditure is then determined from the sizes of the planned software modules, correction factors for various influencing variables and experience data. The COCOMO estimation method takes a particularly large number of influencing factors into account.

LOC is often criticized because the value is influenced by different code formatting (up to a factor of 3). The LOC size measure classifies long programs as more complex than short solutions. However, the length of a program does not necessarily mean a worse solution. Well-written, self-explanatory code does not have to be short, as it is usually easier to maintain than program code that has been optimized for short text due to its readability.

Furthermore, different developers require different numbers of program lines for the same functionality. In practice, there are dramatic differences in productivity among developers. So-called “super programmers” can generate 10 to 100 times more LOC per day than the average. There are projects in which hardly a line of code is written. For example, only interactive inputs can be made in an existing system (e.g. database tuning). LOC is not a suitable measure for projects in which the coding of the source code makes up only 7% of the total effort. LOC as a basis for estimates must now be viewed more as historical.

Despite all the criticism, the LOC size measure is still widely used, probably because it is intuitive and easy to measure. In retrospect, in particular, LOC (which then also includes scripts and test code) are sometimes used as a measure of the scope of software and as a measure of the developer’s performance. One should warn against this: If you take LOC as a measure of performance, you will get a lot of it, with all the negative effects on simplicity, maintainability, performance, reliability.

Instead of LOC, DSI (delivered source instructions) were often used later. That seems more sensible, but the principal problems remain. Comments that contribute significantly to quality do not count.

The function point method (according to Allen J. Albrecht, IBM) does not start from the expected code, but from the requirements and tries to estimate the number and complexity of data structures and functions / methods by classifying them as simple / normal / difficult to classify and given appropriate effort factors. These quantity factors are then corrected for difficulties. The function point method is widely used in the commercial environment. Attempts have been made to adapt them to other environments.

In cases where the main result is text documents, the expected number of pages of paper is often used as a measure and rated at 1PT / page. (E.g. studies, analyzes, specification sheets)

In other cases (e.g. specifications), the number of meetings of a committee is used and the time required, including preparation and follow-up work by all those involved, is calculated from this.

Breakdown into components

For a good estimate of the effort, it is necessary that you have a good understanding of what is required, that the scope of services is precisely defined and things that are sensible, useful or obvious, but not required, are explicitly excluded. An imperative is the availability of a requirement specification, which may have to be further specified. Based on this, a list of the components to be delivered and the additional auxiliary components to be created in the course of the project can be created. (In particular scripts, tests, diagnostic aids) The scope or effort for each component can then be estimated individually. Assuming that the respective estimation errors are statistically independent of one another, the estimation errors for the individual components partially cancel each other out.

It should be noted here, however, that systematic estimation errors, such as a general underestimation of costs through component-based estimation, are not eliminated. Furthermore, it often turns out that in the course of the project components are still required that were not even estimated. In order to counter such systematic estimation errors, estimates from old projects can be correlated with the actual project sizes and a corresponding correction factor for the systematic estimation error can be derived from this correlation (iceberg factor).

Consideration of difficulties and restrictions

Unless already taken into account in the component estimation, difficulties or restrictions must be taken into account by means of correction factors. The COCOMO method specifies 14 such factors, which were obtained from statistical analysis of many projects. Some are irrelevant today (e.g. turnaround time in closed shop operations), but most are still useful. The most important one is the quality of the developers. At Böhm it is given as a range of 4.2 between the best and the worst team and should be even higher today.

Estimation procedure

Barry W. Boehm , the father of COCOMO, also mentions some other estimation methods:

analogy

You look for similar projects and take their costs with surcharges and discounts for this and that. Advantage: reference to real costs. Disadvantage: differences in task, system environment, personnel. Suitable for an overall view where you would otherwise get lost in details and for plausibility checks.

Parkinson's procedure

“Parkinson's First Law” says “Work expands as far as it goes”: knowing the budget and the deadline will tell you how many people you can employ and what it costs. This procedure is known from practice: if you finish too early, you make embellishments and test more. If you cannot finish, but the budget is exhausted or the deadline has been reached, the status achieved is declared finished.

"Price-to-Win"

We know from various sources what the customer is willing to pay or what a competitor is offering; usually far less than a solid job would cost. The estimate is tweaked until it matches the expectation. Boehm goes on to write: "The price-to-win technique has won a large number of software contracts for a large number of companies. Almost all of them are out of business today. "(" Price-to-win technology has been able to secure a large number of orders for many software companies. Most of these companies are no longer in business today. ")

Delphi method or assessment exam

Alternatively or additionally, the effort estimate can be improved using the Delphi method . Several people are simply asked to make estimates independently of one another. The hope is again that the estimation errors in the averaging cancel each other out. In addition, with the Delphi method there is the possibility of having the estimators discuss widely differing estimates. It can, for. For example, it can be revealed that the majority of the estimators overlooked a problem aspect and therefore underestimated the effort. It can also be the case that an estimator has an implementation idea that requires significantly less effort. It is important that those involved are clear about the subject of the estimate, e.g. B. Net time required for a program change, gross time required for changes including test, documentation change and user information. The assessment exam works in a similar way, only less formalized. The experts do not estimate separately from one another, but collectively. The 3 phases of preparation, implementation and follow-up are carried out.

COCOMO

The basic idea of ​​the COCOMO method "Constructive Cost Model" is to record, evaluate and extrapolate all cost-relevant elements. The evaluation is based on empirical values obtained from an experience database in which a large number of projects have been entered. This experience database is based on DSI and a system environment from the time of punched cards. The formulas for the basic effort are therefore no longer usable today, the basic concept with suitable reference values ​​can be.

Functional sizing

Functional size measurement , or as a variant the function point method , are not themselves an effort estimation method , but serve to evaluate the scope of technical requirements for a software project. If one assumes that the functional size is an essential driver of effort for a software project, it can be deduced from this about the effort for the project. However, there is no simple or even linear relationship between the functional size and the project effort. Therefore, a model such as B. COCOMO is necessary, which describes the other effort drivers . Many commercial cost estimation models also use the functional size as an input variable.

Assessment of estimation procedures

In addition to accuracy, a number of other requirements are placed on estimation methods, some of which are contradicting each other:

  • It should be usable as early as possible. (The client wants to know at the beginning what it will cost in the end.)
  • Changes in the requirements should affect the estimate. (Additional / reduced costs)
  • The results should be easy to understand.
  • In addition to the costs, a rough schedule should also come out, which enables the transition to project planning.
  • The estimation process itself should cost as little as possible.

accuracy

A good estimate of the effort should always be accompanied by information on the accuracy of the estimate. Such information can again be derived from the statistical analysis of earlier estimates. In the software sector, simple estimation approaches are based on an accuracy of up to 10. That means, with an estimated effort of one person-year, the probable effort lies between z. B. 36 days and 10 years. Using component estimation and the Delphi method, this can often be improved to an estimation error in the order of magnitude of a factor of 2. In his trial method, Humphrey even reports in very favorable cases an estimation error of only 15% in 75% of the projects. However, this only works if a large number of similarly stored comparison projects are available and if no decisive influencing factor has changed in the new project. New staff, new technical requirements, new development tools, new runtime environments, new customers or similar risks can easily lead to an estimation error of several orders of magnitude.

There is also a paradox: the more “factors” (not summands) that are taken into account, the more plausible the result, because factors that obviously have a major influence are taken into account. However, the estimation accuracy is worsened because if z. For example, if 10 factors are estimated too optimistically or pessimistically by a factor of 1.05, that makes a factor of 1.6. Software developers have a strong tendency to be optimistic. Responsible also because of the " price-to-win ".

Cost of the estimation process

Effort arises

  • for reading and understanding the requirements mostly for several people
  • for the definition of services, restrictions, restrictions
  • for the actual estimate
  • for selling the appraisal, reworking, maintaining appraisal databases

Estimating is often an iterative process in which services are reduced or supplemented, assumptions are corrected.

According to some statements, the costs for a good estimate amount to up to 3% of the project scope, and those for a good offer up to 5% of the project scope.

This often makes the estimate itself a problem: With 10 providers and 5% effort per provider, the quotation costs make up 50% of the project scope. From the point of view of the provider, however, if a project is successfully acquired, he has to recoup the offer costs for all 9 others. It would have to be quite expensive to do that, which makes it unlikely to get the job. This suggests to make a rather rough estimate with a high mark-up in order to keep the estimation effort (and thus also the estimation costs) low.

See also

literature

  • Manfred Burghardt: Project Management: Guidelines for planning, monitoring and controlling development projects. 7th edition. Publicis Corporate Publishing, Erlangen 2006, ISBN 3-89578-274-2 , p. 156ff.
  • Siegfried Vollmann: Estimation of effort in software engineering . IWT-Verlag, 1990, ISBN 3-88322-277-1 .
  • Barry W. Boehm : Software Engineering Economics . Prentice Hall, 1981, ISBN 0-13-822122-7 .
  • IBM Germany: The Point Method function, estimation method for IS application projects . Form No. E12-1618, 1985.
  • FP Brooks: The Myth of the Man Month . Addison-Wesley 1987, translation of the original 1975 edition, ISBN 3-925118-09-8 .
  • Harry M. Sneed : Software project calculation. Hanser, 2005.
  • Steve McConnell : Software Estimation: Demystifying the Black Art . Microsoft Press, 2006, ISBN 978-0-7356-0535-0 .
  • Oliver Hummel: Cost estimates in software and system development - compact . Spectrum Academic Publishing House, 2011, ISBN 978-3827427519 .
  • Dietmar Hölscher: Estimation of effort in digital projects. Appreciating is not knowing. Verlag Altes Forsthaus, 2019, ISBN 978-1795231930 .

'