Identify Metrics Customers


The first step of the “12 Steps to Useful Software Metrics” is to identify the customers for each metric. The customer of the metric is the person (or people) who will be making decisions or taking action based upon the metric; the person/people who needs the information supplied by the metric.

There are many different types of customers for a metrics program. This adds complexity to the program because each customer may have different information requirements. Customers may include:

   Functional Management: Interested in applying greater control to the software development process, reducing risk and maximizing return on investment.

   Project Management: Interested in being able to accurately predict and control project size, effort, resources, budgets and schedules.  Interested in controlling the projects they are in charge of and communicating facts to their management.

•    Software Engineers/Programmers: The people that actually do the software development.
Interested in making informed decisions about their work and work products. These people are responsible for collecting a significant amount of the data required for the metrics program.

   Test Managers/Testers:  The people responsible for performing the verification and validation activities.  Interested in finding as many new defects as possible in the time allocated to testing and in obtaining confidence that the software works as specified. These people are also responsible for collecting a significant amount of the required data.

   Specialists: Individuals performing specialized functions (e.g., Marketing, Software Quality Assurance, Process Engineering, Software Configuration Management, Audits and Assessments, Customer Technical Assistance).  Interested in quantitative information upon which they can base their decisions, finding and recommendations.

   Customers/Users: Interested in on-time delivery of high quality software products and in reducing the over-all cost of ownership.

If a metric does not have a customer, it should not be produced. Metrics are expensive to collect, report, and analyze so if no one is using a metric, producing it is a waste of time and money.

The customers’ information requirements should always drive the metrics program. Otherwise, we may end up with a product without a market and with a program that wastes time and money. By recognizing potential customers and involving those customers early in the metric definition effort, the chances of success are greatly increased.

What Are Software Metrics?


Software metrics are an integral part of the state-of- the-practice in software engineering.  More and more customers are specifying software and/or quality metrics reporting as part of their contractual requirements. Industry standards like ISO 9000 and industry models like the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI®) include measurement.  Companies are using metrics to better understand, 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. These are all examples of metrics when the word is used as a noun.

I 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." [Goodman-93] Figure 1, illustrates 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. This paper outlines twelve steps to selecting, designing and implementing software metrics in order to insure this understanding.

Testing ,Metrics


Testing Reliability metrics uses two approaches to evaluate the reliability.
First, it ensures that the system is fully equipped with the functions that are specified in the requirements. Because of this, the errors due to the lack of functionality decreases .
Second approach is nothing but evaluating the code , finding the errors and fixing them.

The current practices of software reliability measurement can be divided into four categories.
1) Product metrics
2) project management busy
3) process metrics
4) Fault and failure metrics
As discussed  earlier software size and complexity plays an important role in design and coding phase. One of the product metrics called function point metric is used to estimate the size and complexity of the program.
Project Management metrics increases reliability by evaluating the Management process whereas process metrics can be used to estimate , monitor and improve the reliability and quality of the software.
The final one, Fault and Failure Metrics determines, when the software is performing the whole functions that are specified by the requirement documents with out any errors. It takes the faults and failures that arises in the coding  and analyzes them to achieve this task.

Design and Code Reliability Metrics


The quality factors that exists in design and coding plan are complexity , size and modularity.
 If  there exists more complex modules, then it is difficult to understand and there is a high probability of occurring errors. So complexity of the modules should be less.
Next coming to size, it depends upon the factors such as total lines, comments, executable statements etc. According to  SATC , the most effective evaluation is the combination of size and complexity.
The reliability will decrease if modules have a combination of high complexity and large size or high complexity and small size. In the later combination also the reliability decreases because , the smaller size results in a short code which is difficult to alter.
These metrics are also applicable to object oriented code , but in this , additional metrics are required to evaluate the quality.

Software Reliability Measurement


In any  software industry , system quality plays an important role . It comprises of hardware quality and software quality. We know that hardware quality is constantly high .So  if the system quality changes , it is because of the variation in software quality only. Software quality can be measured in many ways. Reliability is an user – oriented measure of “software quality”.
Suppose assume that there are 3 programs that are executing to solve a problem.  By finding the reliability of each program we can find which program has less reliability and we can put more effort to modify that program to improve the overall reliability of the system. So always there is a need to measure the reliability. In the later sections we will discuss about  how to improve reliability and quality of the software
Related Posts Plugin for WordPress, Blogger...