single measure or single combination metric will satisfy all goals or answer all measurement questions–one must choose the metric suitable for each specific question. Once the specific, measurable goals, questions and metrics have been identified, select the most appropriate metric designed for the purpose. In the same way that a toolbox contains many tools, each specifically designed to serve a particular use, a measurement toolbox should contain specific measures selected to suit your specific needs. There is no Swiss army knife of metrics–you need to select the measure that best fits your needs be it defects, function points, number of objects, lines of code, customer satisfaction, etc.–each is intended to measure a different aspect of software development.
3. Learn about the available metrics and what they mean before implementing them in an organization . For example, work effort is a function of many variables, including software size, implementation technology, development tools, skills, hardware platforms, degree of reuse, tasks to be done, and many others. As such, no single variable can accurately predict work effort; yet there is often an expectation that a single variable (for example, degree of reuse) can accurately predict effort. If one of your Goals is to increase estimating capability, it is also wise to research the available automated tools on the market and talk to actual users (not just tool vendors) about how their chosen tools works within their particular environment. Note that not all estimating tools address the same problem–some provide probabilistic estimates of work effort and cost, while others provide hourly breakdowns of predicted work effort. Which one will best suit your needs? It depends on your goals and what questions you need to answer.
4. Plan a measurement program by using metrics and measures in the manner for which they are intended, and ensure that there is a common understanding of the chosen measures . For example, functional size reflects the size of the software based on its functional user requirements, not the physical size of software. (Physical size of software is often expressed in lines of code.) Together with other variables, it can be used as a technology-independent measure of software size in order to predict effort or cost in software estimation models. However, functional size is not the right measure for predicting data access storage device needs–these depend on the technology and physical space taken up by the software and the volume of data and are better measured with other units. There is an abundance of information on the internet about various software metrics from organizations such as the Quality Assurance Institute ( www.qaiusa.com), American Society for Quality ( www.asq.org), and the International Function Point Users Group ( www.ifpug.org).
5. Remember that the accuracy of a metric is a function of the least accurate component measure it involves . People often run into measurement difficulty when they assign several decimal places of accuracy to metrics that are derived from a series of relatively inaccurate or imprecise measures. For example, the function point (FP) count of a project is calculated by summing up discrete values of its component functions, none of which is more granular than 3 FP. To then calculate defect density and report it with multiple decimal places leads to the mistaken conclusion that the metric is exact. The same situation arises when sophisticated estimating models produce effort estimates to fifteen minute accuracy based on input variables that may have been guesses (e.g., project risk on a 1-5 scale). We all know intuitively that estimates based on a myriad of input variables cannot accurately predict schedules to