Software metrics are an integral part of the modernization in software engineering. More and more customers are specifying software and/or quality metrics reporting as part of their contractual requirements. Many Industry standards like ISO 9000 and industry models like the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI®) include measurement. So organizations are defining & using these metrics to better track, control and predict software projects, processes and products.
The term software metrics means different things to different people. When we buy a book or pick up an article on software metrics, the topic can vary from project cost and effort prediction and modeling, to defect tracking and root cause analysis, to a specific test coverage metric, to computer performance modeling. As software engineers prefer the activity based view taken by Goodman. He defines software metrics as, "The continuous application of measurement-based techniques to the software development process and its products to supply meaningful and timely management information, together with the use of those techniques to improve that process and its products." an expansion of this definition to include software-related services such as installation and responding to customer issues. Software metrics can provide the information needed by engineers for technical decisions as well as information required by management.
If a metric is to provide useful information, everyone involved in selecting, designing, implementing, collecting, and utilizing it must understand its definition and purpose. Let's ponder on steps to selecting, designing, and implementing software metrics in order to insure this understanding.
Some Basic Measurement Theory The use of measurement is common. We use measurements in everyday life to do such things as weigh ourselves in the morning or when we check the time of day or the distance we have traveled in our car. These repetitive measurements are used extensively in most areas of production and manufacturing to estimate costs, calibrate equipment, assess quality, and monitor inventories. Science and engineering disciplines depend on the rigor that measurements provide.
According to Fenton, "measurement is 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". In this statement an entity is a person, place, thing, event or time period. An attribute is a feature or property of the entity. To measure, we must first determine the entity. For example, we could select a car as our entity. Once we select an entity, we must select the attribute of that entity that we want to describe. For example, the car’s speed or the pressure in its tires would be two attributes of a car. Finally, we must have a defined and accepted mapping system. It is meaningless to say that the car’s speed is 65 or its tire pressure is 75 unless we know that we are talking about miles per hour and pounds per square inch, respectively.
We will use the basic process model of input - process - output to discuss software entities. Software entities of the input type include all of the resources used for software research, development, and production. Examples of input entities include resources (people), materials, tools, and methods. Software entities of the process type include software-related activities and events and are usually associated with a time factor. Examples of process entities include defined activities such as developing a software system from requirements through delivery to the customer, the inspection of a piece of code, or the first 6 months of operations after delivery. Process entities also include time periods, which do not necessarily correspond to specific activities. An example would be the period between 1/1/10 and 2/1/11. Software entities of the output type are the products of the software process. These include all the artifacts, deliverable, and documents that are produced. Examples of software output entities include requirements documentation, design specifications, code (source, object & executable), test documentation (plans, scripts, specifications, cases, reports), project plans, status reports, budgets, problem reports, and software metrics.
Each of these software entities has many properties or features that we might want to measure. We might want to examine a computer's price, performance, or usability. We could look at the time or effort that it took to execute a process, the number of incidents that occurred during the process, its cost, controllability, stability, or effectiveness. We might want to measure the complexity, size, modularity, testability, usability, reliability, or maintainability of a piece of source code.
One of the challenges of software metrics is that few standardized mapping systems exist. Even for seemingly simple metrics like the number of lines of code / Kilo line of code (KLOC) no standard counting method followed across the organizations.
Do we count physical or logical lines of code?
Do we count comments or data definition statements?
Do we expand macros before counting and do we count the lines in those macros more than once?
Another example is engineering hours for a project – besides the effort of software engineers, do we include the effort of testers, managers, secretaries, and other support personnel?
This are improving like a few metrics, which do have standardized counting criteria include McCabe’s Cyclomatic Complexity and the Function Point Counting Standard from the International Function Point User Group (IFPUG).
However, the selection, definition, and consistent use of a mapping system within the organization for each selected metric are critical to a successful metrics program.
For a thumb rule all IT companies follow three types basic matrices line cost matrix, Schedule matrix & quality matrices. We will ponder on these & types of matrices in next discussions. Share your thoughts at ravindrapande@gmail.com.
No comments:
Post a Comment