Process And Product Software Metrics

Published Date: 02 Nov 2017

As I do not currently work for a company I will be evaluating five process or product software metrics I think a company should use.

Software metrics are a quantitative measure that enables software developers to gain insight into the efficiency of the software process and product conducted using the process framework. A quote from Lord Kelvin sums up the reason for measurement with the quote "when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be." (Kelvin, 1883) The core reason for measuring software development using software metrics is for understanding. There a four reasons why developers would want to measure processes and products. These are; to characterize, to evaluate, to predict and to improve. The software quality factors that require measuring include; functionality, maintainability, reliability, efficiency, portability and usability. The main metrics in focus in this evaluation are; size, time, money, effort and quality. (Kan, 2002)

A measure of the size of any system, code base and how the size is changing is an important part of measuring how efficient a project is. There are a number of ways in which development companies can measure size. One way is counting the Lines of Code. This can be broken down further, Source Lines of Code, Effective Lines of Code or Non Commented Lines of Code. This is a cheap and easy way to measure a code base, but the disadvantages of this method is that it cannot be used to compare code written in different language. An alternative method called Function Point Analysis can be used as a way of standardizing measurements of work. FPA has been around since the 1970’s and claims to be language independent by measuring the functionality of the system and is also independent of programming style, thus making it an effective way to measure productivity. This method will also work for documentation as it can be measure in lines, words or pages. The disadvantages of this are that it is not easy to measure or understand making it a less desirable approach. Another major disadvantage is that calculations for Function Points need to be calculated by certified Function Point counters using different techniques depending on the method they follow. The huge disadvantages of this approach are the probable cause of why this method has not been so popular with software development companies. (University, 1999)

Time is important in the process of creating a software product as development usually follows strict deadlines. Most agile developers measure velocity to see how fast they are delivering at any point in time. The problem with this is that it is not comparison friendly as there is no standardized way of measuring how much is being delivered and how quickly it is being done. Velocity is only useful as a short-medium term prediction. Speed can be measured by the number of changes that are being made and the size of the changes in the production of software. Etsy can measure frequency and size of the changes which can tell development teams if they are making too many changes or being too quick. Time can also be broken down further into effort and schedule. Effort which is usually measured in hours, is important when measuring and recording all time included within a project including overtime. It can also be used to record the types of employee and which activities they were involved in. This will show how much effort was put into each activity, how long it took and how productive they were, this is discussed in detail further on. (University, 1999) This is all useful data when analysing data during and after a project. Schedule is measured in calendar time and records the execution and delivery of milestones, reviews and audits. It is important that everyone knows what is meant by the completion of an event, so it can be compared and interpreted correctly. The ways in which definitions are written have to be consistent to make it possible for comparisons between projects to be made. Alternatively developers and customers can work together to help measure time. This can be done by allowing a customer or even a tester to look for problems and in turn measure the length of time from when a problem is found till the time it is fixed. (Bird, 2012)

Money is an integral part of any software project, and its measurement is key to the potential success of the product at the end of the development cycle. Breaking down costs is important, as it will let managers know how exactly how much is being spent on new developments, enhancements, testing, maintenance and anything else involved in the development of a new product. The measurement of money is also connected to the time. As the saying goes "Time is Money!" as is also the case with this metric. The important part of measuring money is that for it to be effective in software development, everyone involved needs to track their costs and be able to keep it documented. This then allows managers to analyse, compare and contrast figures and times with other projects. The data returned can show trends of spending over time and which areas are the most costly. There are many budgeting and cost reporting tools available to teams to be able to efficiently document costs. The disadvantage of this is that developers are not the type of people who typically enjoy documenting figures and would rather be programming. This would cause this approach to fail. A possible solution would be, if supervisors were to get involved and track time and costs. (Bird, 2012)

Effort is another metric used, as it provides management with an insight into the contribution of their staff towards a software product. They are measured on their adherence to a schedule, their product quality and the amount of effort required for each activity they are involved in. Effort indicators are used by management to measure actual profile against the plan. These indicators include staffing levels, profile by activity or labour category. For software project s to run efficiently and quickly management need to determine how much staff is needed for the project. A composite staffing profile can be created for the project by summing up the number of staff each period. The effort metric can used for all phases of the software development cycle and it is important that management carry out this metric as it allows important data to be collected and acted upon so that a software project runs as smoothly as possible with the correct number of staff giving sufficient effort. (California) Below is a chart to show a sample of actual effort versus planned effort.

Actual

PlannedC:\Documents and Settings\Owner\Desktop\SQM_Ass3_Effort_Chart.png

One of the most important metrics is quality. Management in a software project must measure the quality of the product they are producing. No software company wants to produce poor quality products with defects, so it is in the best interests of management to ensure their software is the best it can be. There are many ways in which quality can be measured. It is commonly measured by finding defects, documenting and counting them, can provide much needed data on the quality of a product. Much like the time metric bug tracking systems are available to indentify bugs, measure the length of time it takes to fix bugs and how many can be fixed within a period of time. Defect Density is according to Software Testing fundamentals "the number of confirmed defects detected in software/component during a defined period of development/operation divided by the size of the software/component." (Fundamentals, 2011) It is mainly used for indentifying high risk components within software and it is also used when comparing two or more software products to determine the quality of the product. The formula can be seen below.

Defect Density = Number of Defects

Size

In conclusion, the above software metrics are the most important to creating a quality software product. Management of a software product should ensure that the proper reporting, documenting and analysing are carried out correctly as well as ensuring they act upon their findings. This would help to increase the profitability and shorten the development time of software product s. Despite these metrics being an important part of software development they do have disadvantages. These would include the costs at which some of the required software needed for gathering the data is expensive. When asking developers to record their effort or any other reporting data needed by management, they may not put in sufficient effort as they could see coding as more important. If management can find a solution to these problems and make sure developers agree to assist in reporting data, then these metrics will run efficiently and improve the end product.