12 Steps to Useful Software Metrics – Data to Information to Knowledge
In my last blog, Measurement Defined, I talked about Norman Fenton’s definition of measurement as “the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to describe them according to clearly defined rules." Once we perform the measurement process, we have one or more numbers or symbols, these are data items. Data items are simply “facts” that have been collected in some storable, transferable, or expressible format.
However, if the data is going to be useful, it must be transformed into information products that can be interpreted by people into knowledge so that it can be used to make better, fact-based decisions.
According to the Guide to Data Management Body of Knowledge, “information is data in context.” The raw material of information is data. By adding the context, collected data starts to have meaning. For example, a data item stored as the number 14 does not by itself provide us with any usable information. But if we know its context—for example, if it has a definition such as “the number of newly detected defects”; a timeframe such as “last week”; and relevance such as “while system testing software product ABC”; that data item is converted to information. Information can then be stored as additional data.
Information in and of itself is not useful until human intelligence is applied to convert it to knowledge through the identification of patterns and trends, relationships, assumptions, and relevance. Going back to our example, if the information regarding the 14 newly detected defects found last week during the system testing of software product ABC is simply put in a report that no one reads or uses, then the information is never converted to knowledge. However, if the project manager determines that this is a higher defect arrival rate (trend) than was found during the previous three weeks (relationship) and determines that corrective action is needed (assumption) resulting in the shifting of an additional software engineer onto problem correction (relevance), that information becomes knowledge. Of course the project manager can also decide that everything is under control and that no action is necessary. If this is the case, the information has still been converted to knowledge.
The moral of this blog is that the goal should never be “To put metrics (or measurements) in place”. That goal can result in your organization becoming DRIP (Data Rich – Information Poor). The goal should be to provide people with the knowledge they need to make better, fact-based decisions.
Metrics are simply the tools to ensure that standards exist for measuring in a consistent, repeatable manner in order to create reliable and valid data. For example, establishing “what” we are measuring through well-defined and understood entities and attributes, and “how” we are measuring through standardizing the mapping system and the conditions under which we measure. Metrics also define how to turn collected data into information and how to interpret that information to create knowledge.