Importance Of Software Measurement And Metrics

Every software developing organization wants to improve their software development process in such a way that they use their minimum resources in terms of time and cost, and at the end an improved and reliable software product is expected .In order to achieve this goal , every organization needs better estimation of the cost , quality and time. To achieve this goal software matrices are used.

The word metric is used in terms of measurement, so software metric means measuring the software. As we know that software is not something physical, so it’s really hard to measure the software. In software metrics a variety of ways are used in order to measure the software. This may depend on the nature of the software. Basic and core theme of the software is to make sure about the time and cost of the software, and improve the software quality and performance and productivity. Software matrices and quantitative measurement provides a formal means of for estimating the software quality and complexity. A software metric can be helpful in almost three means,

Help us to understand and model the software engineering process as well as the product quality.

Helps in management of the software development process and projects

Helps in an improved software engineering process.

1.1 History

For the successful software development and maintenance, Measurement is a key technology. The history of software engineering and software metrics is almost from the same era. You learn more by practice or practically as compared to the only theoretical knowledge or by book reading. Similarly the extensive research and literature on the measurement and metrics has had little impact on industrial practice. Mostly metrics are used to improve the process of decision making in the software engineering from both managerial and technical point of view. Industrial metrics activity is invariably based around metrics that have been around for nearly 30 years. Not only at that time these metrics very successful and popular, but now a day there popularity is still the same. Isolation is the main problem while using these metrics. By adopting a less isolationist approach, it is possible to present improved management decision support system which is consist of these simple metrics. These are important for cause and effect relationships and uncertainty and combination of evidence.

“Software development and maintenance started to become major corporate concerns in the last half of the 20th century. Although most companies could not survive or compete successfully without software and computers, even in 2008 senior executive management remains troubled by a set of chronic problems associated with software applications: long schedules, major cost overrun, low quality and poor user satisfaction” [1].

1.2 The Problem

Poor size estimation is one of the main reasons in the software engineering for the failure of any software programs. Size is the critical factor while determining the effort, schedule, and cost. One of the complicated activities is the size estimation, results must be updated throughout the life cycle with the actual counts.

Size measures of the software include the following,

source lines-of-code,

function points,

feature points.

Function of size is complex and function of size impacts design errors and latent defects and due to this quality problem occurs, also the schedule slips, and cost overruns. So it means complexity must be measured, controlled and tracked continuously during the process. Requirements creep is another factor leading to size estimate inaccuracies which also must be base lined and diligently controlled.

Good measurement program provides quantitative clarification of critical development issues and also help in the early detection of problems and it is an investment in success for software engineering. Before they surface, Metrics give you the ability to identify and/or resolve the risk issues. Keep in mind one thing that the measurement must not be a goal in itself and it must be integrated into the total software life cycle not independent of it. Metrics must be used to be effective!

“The problem with these specialized metrics that have evolved in tandem with development methods is that many of them have such a narrow focus that they only measure one technology. For example, it is not possible to compare two projects using use case points if one of the projects handled design with use case and the second handled design with ordinary structured design” [1].

Up till 2008 there were 50 kinds of development methods that the software industry has, and it means that almost same quantity of measurement approaches, and to use and create all 50 kinds of metrics is not possible.

Software Measurements

There are three basic methods for measuring software size. Historically,

SLOC (Source Line-Of-Code): Source Line-Of-Code is the primary measure for the software size. However especially during the early development stages, it is difficult to relate software functional requirements to Source Line-Of-Code.

2.1 Source Lines-of-Code Estimates (SLOC)

Mostly Source Lines-of-Code estimates count all data declarations and executable instructions but exclude the continuation lines, blanks and comments. Source Lines-of-Code Estimates can also be used for size estimation through analogy. Source Line-of-Code estimate size by comparing both, the newly built software’s functionality to similar software functionality found in the other applications. For the better comparisons of both the functionalities, new software functionalities and the functionalities we already have, is due to SLOC for the better comparison in the process.

As the size measure, if we look in the past and present then we came to know that a big quantity of historical data and the literature available which uses Source Lines-of-Code. It is easy to count the Source lines-of-code and as the key input mostly existing software estimating models use Source Lines-of-Codes. Estimating the Source Lines-of-Code is virtually impossible. The reason is that Source Lines-of-Code’s are language-specific.

“From SLOC estimates a set of simple, size-oriented productivity and quality metrics can be developed for any given on-going program. These metrics can be further refined using productivity and quality equations such as those found in the basic COCOMO model.” [2]

C:UsersGILLDesktopSQ&PM (Labs+Assignment)AssignmentMetrics_fig1.gif

2.2 Function Point Size Estimates

By A.J. Albrecht definition, Function Points are the sums of following five different type of factors:

Inputs

Outputs

Logic (or master) files

Inquiries, and

Interfaces.

“Function points are counted by first tallying the number of each type of function listed above. These unadjusted function point totals are subsequently adjusted by applying complexity measures to each type of function point. The sum of the total complexity-adjusted function points (for all types of function points) becomes the total adjusted function point count. Based on prior experience, the final function point figure can be converted into a reasonably good estimate of required development resources.” [4]

First of all what you do is, calculate or count the required number of outputs, inputs, interfaces, logical files and inquiries. Then by established values you multiply these count. Sum of all these products is adjusted by the complexity degree. “Complexity judgments are domain specific and include factors such as data communications, distributed data processing, performance, transaction rate, on-line data entry, end-user efficiency, reusability, ease of installation, operation, change, or multiple site use.” [4]

2.3 Function Point Advantages and Disadvantages

ADVANTAGES

DISADVANTAGES

Standards are established and reviewed frequently.

Largely a manual process.

Resulting metrics are logical and straightforward.

Accurate counting requires in-depth knowledge of standards.

Counting resources are available from requirements stage and applicable for full life-cycle analysis.

Some variations exist that are not standardized (Mark II, 3D, full, feature points, object points, etc.).

Technology, platform, and language independent.

Not as much historical data available as SLOC.

Objectively defines software application from the user’s perspective.

Sometimes backfiring, derived from SLOC can be inaccurate and misleading.

2.4 Feature Point Size Estimates

Feature points, which is a derivative of function points, were developed to estimate or measure the high algorithmic complexity with the real-time software.

“Algorithms are sets of mathematical rules expressed to solve significant computational problems. For example, a square root extraction routine, or a Julian date conversion routine, are algorithms. In addition to the five standard function point parameters, feature points include an algorithm(s) parameter which is assigned the default weight of 3. The feature point method reduces the empirical weights for logical data files from a value of 10 to 7 to account for the reduced significance of logical files in real-time systems. For applications in which the number of algorithms and logical data files are the same, function and feature point counts generate the same numeric values. But, when there are more algorithms than files, feature points produce a greater total than function points. Illustrates the ratio of function point to feature point counts for selected applications”. [5]

2.5 Differences between the function point and SLOC methods.

FUNCTION POINTS

SOURCE LINES-OF-CODE

User-oriented

Specification-based

Language independent

Expandable to source lines-of-code

Variations a function of counting conventions.

Design-oriented

Analogy-based

Language dependent

Convertible to function points

Variations a function of languages.

Order Now