Measuring software productivity is similar to measuring other forms of productivity; that is, it is measured as the ratio of units of output divided by units of input. The inputs consist of the effort expended to produce a given output. For software, the tangible outputs are source code and documentation. Of course the product of software is a process, an algorithm that drives a computer to do work. Unfortunately, understanding of the functionality incorporated into a software product is still rudimentary. Only by understanding what can be measured will it be possible to understand the essence of the software process. Toward this end, this document standardizes software productivity metrics terminology to ensure an understanding of measurement data for both code and documentation production. It defines a set of units to measure the output products and input effort. The lowest level of measurement defined in this standard is called a primitive . The output primitives measured are software source statements, documentation pages, and, optionally, function points. The input primitives measure the efforts of those developing the software products. The capacity and capability of automated support tools are not directly measured by this standard, but are indirectly measured by the improvements in the productivity of the people who use them. This standard prescribes measurements to characterize the, software process, and in doing so gives insight for improving it. This standard does not establish software productivity norms, nor does it recommend productivity measurements as a method to evaluate software projects or software developers. Although the overall value of a product cannot be separated from the quality of what is produced, this standard does not measure the quality of software. The issue of measuring quality is beyond the scope of this standard, because it covers a different aspect of the software process. Nevertheless, productivity metrics should be interpreted in the context of the overall quality of the product. It is left to the user of this standard to look to other standards covering quality metrics for that information. The definition of productivity as the ratio of product to effort was selected in this standard because it is more stable than value relationships like product to monetary units or production to sales. The effects of inflation on the value of monetary units, or the caprice of the marketplace on sales, cause these measures to vary unpredictably. As a result, they do not offer a stable measure over time. However, the quantity of the product and the effort in hours expended to produce it are more consistent measures, and over time these measures will provide a better gauge of software productivity. Users may wish to translate productivity into monetary equivalents, but results shall be reported in the units specified in this standard. The metrics in this standard apply equally well to now development and to the enhancement or maintenance of an existing software product. Subsequent releases or changes to a released or delivered software product should be viewed as a new product for the purpose of applying these metrics. This standard defines a consistent way to measure the elements that go into computing software productivity. A consistent measurement process will lead to a better understanding of the software development process, and a better understanding will lead to improvement. This standard does not claim to improve productivity, only to measure it.