Software Management

Software Size Estimate

Software Size Estimating is an important activity in software engineering that is used to estimate the size of an application or component in order to be able to implement other program management activities such as cost estimation or schedule progress.  The software engineer is responsible for generating independent estimates of the software size throughout the lifecycle. These estimates are sometimes expressed as Software Lines of Code (SLOC), Function Points (FP), or Equivalent Software Lines of Code (ESLOC). An effective software estimate provides the information needed to design a workable Software Development Plan (SDP). This estimate is also input to the Cost Analysis Requirements Description (CARD) process.  Visit Software Estimation Process Consideration and Estimating Reuse Feasibility for more information. [1]

There are several categories of software that make up the estimate. Each of these categories has different time, effort, skills, and environments associated with them. The main categories making up the software size estimate are:[1]

  • New – Software to be developed by the program
  • Reused code – Software is previously written. If it is from an earlier build of the same program, it is called “legacy.” Reused code needs to be analyzed to determine if it was originally designed for reuse or not. Software designed for reuse is usually better documented, has cleaner interfaces, and is easier to integrate than software that is not.
  • Machine generated code – Code automatically created by a software tool. Modern software tools often have the capability to auto-generate enormous amounts of code with a few clicks of a mouse. This code is generally not efficient and may require re-engineering and “clean up” along with integration and testing effort.
  • Commercial Off The Shelf (COTS) – Software previously produced, usually by a different developer, which is generally available to the public. Glue code – Software that needs to be developed in order to make COTS products integrate with the new and existing software.
  • Wrap code – Software that needs to be developed in order to make COTS products work in the target environment.
  • Deleted – Software that will be deleted from existing code. Deleted code must be counted in order to account for the effort expended identifying, deleting, recompiling, and retesting the software.
  • Redesign and rework –This is a percentage estimate of the existing software (reuse and COTS) that will need to be re-developed to ensure it will work in the current program.
  • Regression testing and retesting – This is a percentage estimate of the existing software (reuse and COTS) that will need to be retested to ensure it still functions as intended.

There are various ways available to the software engineer to develop a size estimate. It is recommended that multiple techniques be used and the results combined to produce the final size estimate. Methods that can be used of estimating size are:

  • Comparable to existing programs: Compare the proposed functionality and other similarities to existing programs. If the proposed program has 20% more functionality than one program and 15% less than another, a fairly accurate estimate can be achieved using the actual sizes from the existing programs.
  • Historical data: Within a program, historical data of previous developments (estimates and actual) may exist. Since many of the parameters are usually the same (developer team, environment, platform, etc.) this is a good method to compare previous software builds and the proposed code. The more data that is used will increase the accuracy.
  • Contractor estimate: It is generally true the contractor has written software similar previously. They often maintain a database of past efforts (estimates and actual) and can produce a very accurate estimate. Since the contractor and the Government have different objectives, their estimate should never be relied on solely.
  • Expert Judgment (Delphi technique): Engineers that have domain experience and knowledge can often accurately estimate the software size. Without extensive experience however, expert judgment is seldom more accurate than guessing.
  • Level of effort or schedule: This method does not really estimate the size to be developed, but rather defines the most that could be developed given unchangeable level of effort or schedule constraints.  The software engineer uses productivity rates, integration time and software defect data from recently delivered programs to define the maximum size that could be developed.

AcqTips:

  • Analyze similar, past projects to generate the historical data needed to estimate the size of new software projects. Relying on memory is not effective and leads to poor estimates.
  • Include data gathered from software and test team members. Early project team involvement, not only serves to improve the accuracy of the estimate, but also prepares the team for the eventual project start date.
  • Keep in mind that experience is the key to effective software size estimation. The larger the project, the more experience required to make a good estimate.
  • Use multiple estimation techniques. During the initial estimation stage, the comparative results of different estimation techniques provides the best estimate.
  • Revise the initial size estimate as new information becomes available. During the design phase as the major software pieces come into focus, each module can be estimated separately, the sum of which reflects a revised, more accurate estimate.

AcqLinks and References:

Updated: 9/7/2017

Leave a Reply