To Measure The Effectiveness of Software Metrics in Software Product Development

To Measure the effectiveness of Software Metrics in Software Product
Development
INTRODUCTION
Metrics are management tools that are used to estimate the cost and resource
requirements of a project. In order to conduct a successful software project, we must
understand the scope of work to be done, the risks incurred, the resource required,
the tasks to be accomplished, the milestones to be tracked, the cost and the
schedule to be followed. Before a project can be planned, objectives and scope
should be established, alternative solution should be identified. This information is
required to estimate costs, project tasks, and a project schedule. [David Calvert,
1996]
Metrics helps to understand the technical process that is used to develop a product.
The process is measured to improve it and the product is measured to increase the
quality. Software metrics play a huge role in assessing and improving software
reliability in complex software systems. Effective control processes require
measurements that targets specific Life Cycle (LC) in a systematic and cohesive
manner, Experts at software Reliability Research has identified some of the most
important de-facto software metrics that are best suited for different applications.
These most effective best-in-the-class metrics are used around the world. [Software
Reliability Research, 2008].
1.1 CLASSIFICATION OF SOFTWARE METRICS
Software metrics can be classified into three categories: product metrics, process
metrics, and project metrics. Product metrics describe the characteristics of the
product such as size, complexity, design features, performance, and quality level.
Process metrics can be used to improve software development and maintenance.
Examples include the effectiveness of defect removal during development, the
pattern of testing defect arrival, and the response time of the fix process. Project
metrics describe the project characteristics and execution. Examples include the
number of software developers, the staffing pattern over the life cycle of the
software, cost, schedule, and productivity. Some metrics belong to multiple
The Oxford College of Business Management 1

Development
categories. For example, the in-process quality metrics of a project are both process
metrics and project metrics.
1.2 MEASUREMENTS
Measurements can be either direct or indirect. Direct measures are overtaken from a
feature of an item (eg. length). Indirect measures associate a measure to a feature of
the object being measured (e.g. quality is based upon counting rejects)
Direct measures in a product include lines of code (LOC), execution speed, memory
size, and defects reported. Indirect measures include functionality, quality,
complexity, efficiency, reliability, and maintainability. Direct measures are generally
easier to collect direct measures of Software Engineering output and quality.
Function-oriented metrics provide indirect measures.
1.3 SOFTWARE MEASUREMENT
Software measurements are quantified as schedule, work effort, product size, project
status, and quality performance. [Karl E. Wiegers, 2006]
The software is measured to,
• Indicate the quality of the product.
• Assess the productivity of the people who produce the product.
• Assess the benefits derived from new software engineering tools an
methods.
• Form a baseline for estimation.
• Help justify requests for new tools or training.

Development
1.4 SIZE-ORIENTED METRICS
Size-oriented metrics are direct measures of software and the process by which it is
developed. These metrics can include effort (time), money spent, KLOC (1000’s
lines of code). Pages of documentation created, errors, and people on the project.
From this data some simple size-oriented metrics can be generated
Productivity= KLOC/ person-month
Quality= defects/ KLOC
Cost= cost/KLOC
Documentation=pages of documentation/LOC
Size-oriented metrics are not universally accepted. The use of LOC as a key
measure is the centre of the conflict.
1.5 FUNCTION-ORIENTD METRICS
Function-oriented metrics are indirect measures of software that focus on

functionality and utility. Albrecht, who suggested a productivity measurement
approach called Function Point Method, proposed the first function-oriented metrics.
Function points (FP’s) are derived from countable measures and assessments of
software complexity. Five characteristics are used to calculate function points. These
values are number of user inputs, number of user outputs, number of user inquiries,
(on-line inputs), number of files, number of external interfaces (machine readable
interfaces- tape, disk).

Development
1.6 USES OF METRICS
• Without measurements, there is no real way to determine if the process is

improving.
• Metrics allow an organization to identify the causes of defects that have the
greatest effect on software development.
• When metrics are applied to a product it helps in identifying:
♦Which user requirements are likely to change
♦Which modules is most error prone.
♦How much testing should be planned for each module
1.7 BENEFITS OF SOFTWARE METRICS
• Instrumenting software processes helps complete projects on schedule,

correctly predict staffing levels, and help predict the quality of software
product before it is released.
• Use of software metrics is mandated by most software engineering standards

for improving software quality and reliability.
• Use of effective software metrics program stabilizes the software development

process and ensures consistency in software quality.
• A set of well tailored metrics for specific development strategy and

methodology enhances software development process efficiency and helps in
defect detection and removal of defects earlier in the development life cycle.

Development
• Well-implemented metrics lends itself to benchmarking and controlling release
improvement of software quality and reliability. [Software Reliability Research,
2008]
1.8 NEGOTIATING SCOPE
Processes can be easily identified and flagged as mandatory, essential or optional.

This allows users to make informed decisions on which functionality is to be included
in each release of application based on their priority, given the time, cost and
resource constraints of the project. The project size can then be measured given the
different scenarios.
RESEARCH DESIGN
2.1 TITLE OF THE STUDY
“A Study to measure the effectiveness of Software Metrics in Software Product

Development for INFOSYS TECHNOLOGIES- TRIVANDRUM”
2.2 REVIEW OF LITERATURE
2.2.1 SOFTWARE COST ESTIMATION
Jenkins 1984, Phan 1988, Bergeron 1992, Heemstra and Kusters 1989, Ledrer and
Prasad [1995, 1993] have surveyed the topic of estimation accuracy. These studied
have addressed either the frequency of overruns, or the average accuracy, or both.
Bergeron and St-Arnaud 1992 found that 58% of the projects surveyed had cost

Development
overruns of more than 20%. A summary of some of the results from these surveys is
displayed in Table 3.1. A blank space in the table indicates that this information’s
were not reported in the survey.
Table 2.1 Survey on estimation accuracy
Study (First Author) Jenkins [3] Phan [8] Heemstra [2] Ledrer [14] Sauer [10]
Year of study’s first 1984 1988 1989 2003
Publication
Cost overrun 34%(median) 33% 18%(mean)
Project used more 61% 70% 63% 59%
than estimated effort
Project used less 10% 14% 15%
than estimated effort
Schedule overrun 22%(mean) 23%(mean)
Project completed 65% 80% 35%
After schedule
Project completed 4% 3%
before schedule
2.2.2 IMPROVEMENT OF SOFTWARE PROCESSES
Software processes have an important influence on the quality of the final software
product, and it has motivated companies to be more and more concerned about
software process improvement when they are promoting the improvement of the final
products. The management of software processes is a complex activity due to the
great number of different aspects to be considered and, for this reason it is useful to
establish a conceptual architecture, which includes all the aspects necessary for the

Development
management of this complexity. [Brady, Tim and Hobday, Michael, A Fast Method
for Analysing and Improving Complex Software Processes. R&D Management, Vol.
30, No. 1, January 2000]
2.2.3 SOFTWARE QUALITY ASSURANCE THROUGH HIGH-LEVEL

OBJECT-ORIENTD METRICS.
Quality software development has been based on the study of lines of implemented
code. Software is usually evaluated by means of metrics coming from programming
languages. On the other hand, regarding the great importance of the early stages of
development, metrics must be defined from higher level of abstraction.
Consequently, high-level metrics to be defined and validated in this work come from
specification languages. On the other hand, the concept of quality has subjective
aspects leading to numerous proposals for its assurance. Typically, they can be
classified in process-centric and product-centric methods. This framework is a
methodological approach to software quality assurance based on an object-oriented
conceptual modeling method including automatic code generation [Jose Romero,
SEC's XBRL Voluntary Program on Edgar: The Case for Quality Assurance (July 19,
2008)].
2.2.4 EMPIRICAL VALIDATION FOR SOFTWARE PROCESS

MODELS
Software companies are becoming more and more concerned about software
process improvement, when they are promoting the improvement of the final
products. One of the main reasons of the growing interest in software metrics has
been the perception that software metrics are necessary for software process
improvement. Measurement is essential for understanding, defining, managing, and
controlling the software development and maintenance process and it is not possible
to characterize the various aspects of development in a quantitative way without
having a deep understanding of software development activities and their
relationships. These metrics are focused on the main elements included in a model
of software processes, and may provide the quantitative base necessary to evaluate
the changes in the software processes in companies with high maturity levels. [Felix
Garcia, Francisco Ruiz, Mario Piattini, 2004, “Definition and empirical Validation of

Development
metrics for software Process Models” Alarcos Research Group, Spain pp 146-158]
2.2.5 SOFTWARE MAINTAINANCE
Software verifications and validation is a domain, which is covered by many dynamic

test, static analysis, and formal verifications techniques. A dynamic test technique
requires that certain program elements are covered, will be sensitive to errors
associated with these elements, because executing an error location is a
precondition for revealing the error. Furthermore, it is likely that the probability of
errors increases with complexity. Complexity can be characterized in terms of
several properties that can be used to suggest various testing strategies. The
complexity of the various software properties can be measured using appropriate
complexity metrics. Properties with unusual high complexity measures should be
tested very thoroughly. [Peter Liggemeyer, 2000, “A set of complexity metrics for
guiding the software test process” Corporate Research and Development, Germany,
Volume 4, pp 257-273].
2.2.6 SOFTWARE MAINTAINANCE
Software industry currently spends 50% to 75% of its development budget on

software maintenance and yet it remains the least researched topic in the industry.
Research and consultancy in this area will provide clients with the most up-to-date
techniques for reducing costs and providing estimates for the maintaining complex
real-time systems. Complexity of software modules coupled with their size and other
maintainability attributes makes effective maintenance of software products difficult
and labor extensive. [Source: Software Reliability Research, 2004].
2.2.7 SOFTWARE PROJECT ESTIMATION
Effective software project estimation is one of the most challenging and important
activities in software development. Proper project planning and control is not
possible without a sound and reliable estimate. As a whole, the software industry
doesn’t estimate projects well and doesn’t use estimates appropriately. Under-

Development
estimating a project leads to under-staffing it (resulting in staff burnout), under-
scoping the quality assurance effort (running the risk of low quality deliverables), and
setting too short a schedule (resulting in a loss of credibility as deadlines are
missed). [Kathleen Peters, Software Reliability: Measurement, Prediction,
Application, Professional Edition: Software Engineering Series, McGraw Hill, 2005,
pp 390- 408].
2.2.7.1 ESTIMATING SIZE
An accurate estimate of the size of the software to be built is the first step to an
effective estimate. Sources of information regarding the scope of the project should,
wherever possible, start with formal descriptions of the requirements- for example, a
customer’s requirements specification or request for later phases of the project’s
lifecycle, design documents can be used to provide additional detail. [Kathleen
Peters, Software Reliability: Measurement, Prediction, Application, Professional
Edition: Software Engineering Series, McGraw Hill, 2005, pp 390- 408].
2.2.7.2 ESTIMATING EFFORT
Once the size of the product is estimated, effort estimate can be derived. This
conversion from software size to total project effort can only be done if software
development lifecycle is defined and development that follow to specify, design,
develop, and test the software. A software development project involves far more
than simply coding the software in fact, coding is often the smallest part of the overall
effort. Writing and reviewing documentation, implementing prototypes, designing the
deliverables, and reviewing and testing the code take up the larger portions of
overall project effort. [Kathleen Peters, Software Reliability: Measurement,
Prediction, Application, Professional Edition: Software Engineering Series, McGraw
Hill, 2005, pp 390- 408].
2.2.7.3 ESTIMATING COST
There are many factors to consider when estimating the total cost of a project. These
include labor, hardware and software purchases or rentals, travel for meeting or

Development
testing purposes, telecommunications. Exactly how the total project cost estimate will
depend on how the organization allocates costs. Some costs may not be allocated to
individual projects and may be taken care of by adding an overhead value to labor
rates (Rs per hour). Often, a software development project manager will only
estimate the labor cost and identify any additional project costs can not considered
“overhead” by the organization. The simplest labor cost can be obtained by
multiplying the project’s effort estimate (in hours) by the general labor rate (Rs per
hour). [Kathleen Peters, Software Reliability: Measurement, Prediction, Application,
Professional Edition: Software Engineering Series, McGraw Hill, 2005, pp 390- 408]
2.3 STATEMENT OF THE PROBLEM
Problems reported from the software projects for various organizations are listed
below,
• Frequent changes in the customer’s requirements.
• More bugs reported during testing.
• Frequently attaining the milestones after the specified deadline.
• Projects overshoot the estimated cost limit.
• Certain project doesn’t meet the quality standards expected by the customer.

Development
2.4 OBJECTIVE OF THE STUDY
.objectives include: -
1. To identify the important technical requirements needed to implement

software metrics.
2. To measure the effectiveness of the software metrics in software product

development.
3. To find out the cost savings of system testing time by implementing software
metrics
4. To identify the best business practices for the software metrics

implementation.
5. To identify the key process areas in software metrics.
6. To identify the critical success factors for software metrics.
7. To analyze the various cost saving factors provided by software metrics.
2.7 RESEARCH METHODS
In this research the information’s are collected through, well-prepared

Questionnaires, face-to-face Interviews and Internet
2.8 RESEARCH DESIGN
A research design provides the framework to be used as a guide in collecting and

analyzing data. The method adopted for this research is descriptive type. Descriptive
research can be divided into 2 types
• Longitudinal.
• Crosse-sectional design.
Cross-sectional design was used in this research work. It appears to be most

Development
preferred by market researchers and their clients on account of its simplicity and
understandability. It is also quite flexible in nature, and can take care of simple
analysis as well as complex statistical methods.
2.9 SAMPLING PLAN
A sample size of 40 software companies, which are implemented software for their
technical functioning, is taken for the study. The sampling method used for the data
collection is non-probability convenience sampling.
2.9.1 Non Profitability Sampling
The major difference is that in non-probability techniques, the extent of bias in

selecting a sample is not known. This makes it difficult to say anything about the
accuracy of the sample. Non-probabilistic techniques can be used explicitly where it
is not feasible to use probability-based methods.
2.9.2 Convenience Sampling
Convenience sampling involves picking any available set of respondents convenient

for the researcher to use. For example, software development companies could be
used as a sample by a marketing researcher. They need not be representative of the
target population for the study, for the product being researched.
2.10 DATA COLLECTION
Data sources for the project are mainly primary and secondary data. Primary data’s
are collected through mailing and directly from the respondents by means of
conducting survey. The survey was conducted to know the effectiveness of software
metrics in software product development.

Development
The secondary data’s are obtained from the company website and research papers
related to software metrics, software quality and testing.
2.11 RESEARCH INSTRUMENT
The questionnaire was designed in such a way to meet the requirements of the
objectives. Various types of questions such as open ended, close ended, multiple
choice questions were used in the questionnaire,
2.12 STATISTICAL TOOLS
The statistical tool used for the data analysis is Frequency Analysis.
With additional extensive help is taken using Bar Charts, Pie Chart, and Histogram.
2.8 LIMITATIONS OF THE STUDY
• Secondary Data is used, thus the chances of errors are more.
• In depth study is not possible because of time frame.
• The study is limited within a particular branch.

Development
3.1 INDUSTRY PROFILE
India has emerged as a major exporter of software in the international economy. This
remarkable feat has been accomplished through the extraordinary growth of Indian
Software, which, in the last five year expanded at a compound annual rate of 59%
[Ashish Arora et.al, 2004]. Software industry is one of the most innovative and
fastest growing sectors of the global economy, generating revenues of more than
$150 billion every year. Software companies are becoming more and more
concerned about software process improvement, when they are promoting the
improvement of the final products.
The Indian software industry has focused primarily on providing software services in
almost all possible areas: System Software, telecommunications, e-commerce,
medical systems, automative software, Web-based development and multimedia
applications, and applications software for the insurance, banking and retail
industries.

Development
India’s software export business is mushrooming and export revenue has been
growing at an increasing rate. In terms of Indian rupees, the compound annual
growth rate (CAGR) for India’s software export revenues over the past five years
has, according to NASSCOM’s statistics, been as high as 62.3%, compare to CAGR
for its domestic market revenue during the same period. NASSCOM’s survey in 2000
indicates that more than 185 of FORTUNE 500 companies, i.e., almost two out of
every five global giants, outsourced their software requirements to India during 2004-
2005. [Chandana and Dilip Dutta, 2006].
The initial growth of the software service industry was facilitated by the enlightened
‘hands off’ policies of the government of India. The number of companies that
produce software or employ software developers is much greater than the set of
firms commonly thought of as software firms, such as Microsoft or oracle. [ Ashish
Arora et.al, 2004]. The growth of software exports from a country like India because
of lower labor cost. Table 1.1 shows the growth of software revenues in India
Table 3.1 Growths of Software Revenues in India
Growth ($ million)
Year Export revenues Domestic Revenues
1989 22 --
1990 26 --
1991 38 --
1992-93 54 --
1993-94 105.4 --
1997-98 485 350
1998-99 734 490
1999-00 1,085 670

Development
2000-01 1,750 950
2001-02 2,650 --
India’s comparative advantage in the software industry, generated from its relative
abundance of qualified software engineers, coupled with the government’s timely
national action plan for rapidly improving communications infrastructure has played a
key role in creating confidence among buyers of Indian software products and
related services. As it is evidenced by the rapid growth in their demand, Indian
software engineers have carved out a name in the world market for providing an
unbeatable combination of quality software at a low cost; software developers offer a
cost advantage of 40%-60% over their American counterpart. [Vijayan, 2004].
3.1.1 Indian Software Industry and its evolving service capability
The growth of Indian software industry has been a phenomenal success when
measured against standard indicators such as growth in sales, employment and
exports, and especially when contrasted with the performance of other industrial
sectors in India. Even measured against successful new exporters of software, such
as Israel and Ireland, the Indian software industry stands out in terms of the volume
of employment created and the indigenous nature of its growth. [Suma S.Athreye,
2008].
The largely untold story of the Indian software industry centers on the abilities of the
pioneer firms in the industry who learnt how to transform the programming skills of
their force into firm-specific capabilities, and to become rivals of firms such as
Accenture, EDS, and IBM services in the outsourced-software market. The particular
strength of Indian firms was their ability to assemble teams of talented engineers and
deliver a technical, outsourced service to extracting and different customers
anywhere in the world.

Development
In the year 1998, more than half of the SEI-CMM 4 and 5 were awarded to Indian
software firms. TCS and Infosys concentrated on the domains of finance and
insurance. Pentafour concentrated on creating digital assets in animation, Satyam
sought to concentrate on software for automated systems in transport manufacturing
an Wipro focused on telecommunications and research and development (R&D)
services. Infosys became the first Indian firm to be listed on NASDAQ, though it did
not till recently make any acquisitions [Khanna and Palepu, 2004].
3.1.2 India’s Success Story
The growth and prominence of the Indian software industry has been so
phenomenal over the last ten years that the country competes with US as the world’s
major exporter of software. This success is widely attributed to the growth of a
commercial industry. Indeed Oxford Analytical notes that the initial growth of the
software industry in India “was entirely driven by private enterprise” and minimal
regulation in key areas. [“Oxford Analytical National IT Development: Explaining
Success India”]
A strong relationship between government and the commercial IT industry in India,

particularly the software industry, has helped to develop government policy in
directions that promote the growth of the local commercial industry. For example, the
National Associations of Software and Services Companies (NASSCOM) worked
closely with the Indian government to strengthen copyright laws. Fig 1.2 shows the
growth of Indian Software Industry in 2002- 2006.
ERP (Enterprise Resource Planning) software is the segment of the software

industry that serves the information needs of entire enterprises, including very large
corporations with offices around the world. ERP software companies take
information that is used throughout a company and put it into databases. The major
ERP vendors are SAP, Peoplesoft, Baan, Oracle and J.D. Edwards.

Development
3.2 COMPANY PROFILE
Infosys Technologies Ltd. (NASDAQ: INFY) provides consulting and IT services to

clients globally - as partners to conceptualize and realize technology driven business
transformation initiatives. With over 69,000 employees worldwide, we use a low-risk
Global Model (GDM) to accelerate schedules with a high degree of time and cost
predictability.
Mission: “To achieve our objectives in an environment of vendors and society

at large.”
As one of the pioneers in strategic offshore outsourcing of software services, Infosys

has leveraged the global trend of offshore outsourcing. Even as many software
outsourcing companies were blamed for diverting global jobs to cheaper offshore
outsourcing destinations like India and China, Infosys was recently applauded by
Wired magazine for its unique offshore outsourcing strategy – it singled out Infosys
for turning the outsourcing myth around and bringing jobs back to the US. Truly, a
commitment to be objective and transaction-oriented.

Development
Infosys provides end-to-end business solutions that leverage technology. We
provide solutions for a dynamic environment where business and technology
strategies converge. Our approach focuses on new ways of business combining IT
innovation and adoption while also leveraging an organization’s current IT assets.
We work with large global corporations and new generation technology companies –
to build new products or services and to implement prudent business and technology
strategies in today’s dynamic digital environment.
Our clients have always found us to be professional and consistent at meeting their
expectations; pleased with the performance of the software solutions we develop for
them, impressed with our speed of execution and qualitative service.
Air Canada (Client since1997)
IBM Canada (Client since 1997)
Large Global Bank (Client since 2000)
ANALYSIS AND INTERPRETATION OF DATA
4.1 FEQUENCY ANALYSIS FOR IMPLEMENTATION LEVEL
Table 4.1 CMM Implementation Level
Frequency Percent Valid Cumulative

Percent Percent
Valid CMMI Level-1 2 5.0 5.0 5.0
CMMI Level-2 6 15 15.0 20.0
CMMI Level-3 13 32.5 32.5 52.5
CMMI Level-4 7 17.5 17.5 70.0
CMMI Level-5 8 20.0 20.0 90.0
CMMI 4 10.0 10.0 100
TOTAL 40 100.0 100.0

Development
Chart 4.1 Implementation Level
INTERPRETATION
The companies that have implemented CMMI level-1 are 5%, those who have
implemented CMMI Level-2 are 15%, CMMI Level-3 are 32.5%, CMMI Level-4 are
17.5%, CMMI Level-5 level are 20%, CMMI level are 10%.
INFERENCE
The market research was carried out in the software companies, which are
implemented the software metrics. From the above frequency analysis it is evident
that most of the respondents (32.5%) are having CMMI Level-3 certification.

Development
4.2 FREQUENCY ANALYSIS FOR INFRASTRUCTURE
Table 4.2 Kind of Infrastructure

Percent Percent
Valid Training 23 57.5 57.5 57.5
Auditing 15 37.5 37.5 95.0
Others 2 5.0 5.0 100
TOTAL 40 100.0 100.0
Chart 4.2 Type of Infrastructure

Development
INTERPRETATION
From the (Table 4.2, the following information’s are extracted regarding the kind of
infrastructure requirement.
TRAINING: 57.5%
AUDITING: 37.5%
OTHERS: 5.0%
The market research was carried out in the software companies, which have
implemented the Software Metrics.
INFERENCE
From the above frequency analysis it is evident that the mostly used infrastructure is
training method (57.5%).

Development
4.3 FREQUENCY ANALYSIS FOR SCHEDULE ESTIMATION

ACCURACY
Table 4.3 Schedule Estimation Accuracy

Percent Percent
Valid Yes 14 35.0 35.0 35.0
No 08 20.0 20.0 55.0
Sometimes 18 45.0 45.0 100.0
TOTAL 40 100.0 100.0
Chart 4.3 Scheduled Estimation Accuracy

Development
INTERPRETATION
From the (Table 4.3), the following information’s are extracted regarding the
schedule estimation accuracy.
Yes - 35.0%
No - 20.0%
Sometimes - 45.0%
INFERENCE
From the above frequency analysis it is found that, the schedule estimation accuracy
sometimes improved. It is measured by 45% of the total respondent.
4.4 FREQUENCY ANALYSIS FOR ANALYSING THE IMPACTS
Table 4.4 Analyzing the impact of Software metrics
Frequenc Percent Valid Percent Cumulative

y Percent
Valid Quality & 25 62.5 62.5 62.5
Timeliness
Utility and 07 17.5 17.5 80.0
Functionality
Improving 08 20.0 20.0 100.0
Software related
products and
process
TOTAL 40 100.0 100.0

Development
Chart 4.4 Analyzing the impact
INTERPRETATION
Table 4.4 indicates the impact of software metrics
Quality and Timeliness - 62.5%
Utility and Function - 17.5%
Improving Software Related Products and Process - 20.0%
INFERENCE
From the above frequency analysis it is evident that software metrics mainly helps in
improving the Quality and Timeliness. It is measured by 62.5% of the total
respondent
4.5 FREQUENCY ANALYSIS FOR COST SAVINGS

Development
Table 4.5 Cost Savings

Percent Percent
Valid System 11 27.5 27.5 27.5
Development
Cost
System 14 35.0 35.0 59.5
Testing Cost
Maintenance 10 25.0 25.0 84.5
Cost
Post 5 12.5 12.5 100
Implementatio
n
TOTAL 40 100.0 100.0
Chart 4.5 Cost Savings

Development
INTERPRETATION
System Development Test - 27.5%
System Testing Time - 35.0%
Maintenance Cost - 25.0%
Post Implementation Cost - 12.5%
INFERENCE
From the above frequency analysis it is found that System Testing Time which helps
in reducing the cost. From the table 4.5, it is indicated that 35.0% of the total
respondent prefers System Testing Time.

Development
4.6 FREQUENCY ANALYSIS FOR FUNCTION POINT ANALYSIS
Table 4.6 Function Point Analysis

Percent Percent
Valid Monthly 12 30.0 30.0 30.0
Quarterly 20 50.0 50.0 80.0
Half-Yearly 6 15.0 15.0 95.0
Others 2 5.0 5.0 100.0
TOTAL 40 100 100
Chart 4.6 Function Point Analysis
INTERPRETATION
Monthly : 30.0%
Quarterly : 50.0%
Half-Yearly : 15.0%

Development
Others : 5.0%
INFERENCE
From the above frequency analysis it is inferred that, function point analysis will be
updated on a quarterly basis. It is measured by 50.0% of the total respondent. Fig
4.6 shows the frequency analysis of function point.
4.7 FREQUENCY ANALYSIS FOR ESTIMATING PROJECT

REQUIREMENTS
Table 4.7 Estimating Project Requirements

Percent Percent
Valid Accurate 08 20.0 20.0 20.0
Approximate 29 72.5 72.5 95.0
Others 03 7.5 7.5 100.0
Total 40 100.0 100.0
Chart 4.7 Estimating Project Requirements

Development
INTERPRETATION
Accurate - 20.0%
Approximate - 72.5%
Others - 7.5%
INFERENCE
From the above frequency analysis it’s inferred that, the effectiveness of software
metrics in estimating project resource requirement is found to be approximate. It is
measured by 72.5% of the total respondents. Fig 4.7 shows the estimate of project
requirements.
4.8 FREQUENCY ANALYSIS FOR IDENTIFYING PROCESSES

Development
Table 4.8 Identifying Process

Percent Percent
Mandatory 14 35.3 35.3 35.3
Essential 25 64.7 64.7 97.5
Optional 1 2.5 2.5 100.0
Total 40 100.0 100.0
Chart 4.8 Identifying Process

Development
INTERPRETATION
From the table 4.8, the following information’s are extracted regarding the
identification of processes in software metrics,
Mandatory :35.3%
Essential :64.7%
Optional : 2.5%
INFERENCE
From the above frequency analysis it is inferred that, the effectiveness of software
metrics in identifying the processes is found to be essential. It is measured by
64.7% of the total respondent.

Development
4.9 FREQUENCY ANALYSIS FOR THE CODE AND DESIGN COMPLEXITY
Table 4.9 Code and design complexity

Percent Percent
Yes 10 25.0 25.0 25.0
No 18 45.0 45.0 70.0
Sometimes 12 30.0 30.0 100.0
Total 40 100.0 100.0
Chart 4.9 Code and design complexity

Development
INTERPRETATION
From the table 4.9, the following information’s are extracted regarding code and
design complexities are,
Yes :25.0%
No :45.0%
Sometimes :30.0%
INFERENCE
From the above frequency analysis it is found that software metrics does not helps
in bringing down code and design complexity. It is measured by 45.0% of the total
respondent.
4.10 FREQUENCY ANALYSIS FOR SYSTEM TESTING TIME
Table 4.10 System testing time

Percent Percent
1-2 weeks 06 15.0 15.0 15.0
2-3 weeks 19 47.5 47.5 62.5
3-4 weeks 12 30.0 30.0 92.5
Others 3 7.5 7.5 100.0
Total 40 100 100
Chart 4.10 System testing time

Development
INFERENCE
From the table 4.8, the following information’s are extracted regarding the system
testing time
1-2 Weeks : 15.0%
2-3 Weeks : 47.5%
3-4 Weeks :30.0%
Others : 7.5%
INTERPRETATION
From the above frequency analysis it is found that, the software metrics reduces the
system testing time by 2-3 Weeks. It is measured by 47.5% of the total respondent.
4.11 FREQUENCY ANALYSIS FOR THE TOP MANAGEENT

Development
Table 4.11 Top Management Support

Percent Percent
Highly 15 37.5 37.5 37.5

Supportive
Supportive 21 52.5 52.5 90.0
Less 4 10.0 10.0 100.0

Supportive
Total 40 100.0 100.0
Chart 4.11 Top Management Support

Development
INTERPRETATION
From the table 4.11, the following information’s are extracted regarding the Top
management support,
Highly Supportive : 37.5%
Supportive : 52.5%
Less Supportive : 10.0%
INFERENCE
From the above frequency analysis it is found that, the top management support for
implementing software metrics is supportive (52.5%).

Development
4.12 FREQUNCY ANALYSIS FOR KEY PROCESS AREAS
Table 4.12 Key Process Areas for software metrics

Percent Percent
Focus on 2 5.0 5.0 5.0

business need
Selection of 2 5.0 5.0 10.0

process, Project
training, Software
product
engineering,
Configuration
Management
Focus on 2 5.0 5.0 15.0

business need,
Selection of
process, Project
training,
Configuration
management,
Software product
engineering

Development
Selection of 3 7.5 7.5 22.5
process
Project training 2 5.0 5.0 27.5
Configuration 3 7.5 7.5 35.0

Management
Software product 2 5.0 5.0 40.0

engineering
Project training, 6 15.0 15.0 55.0

Software product
engineering
Focus on 4 10.0 10.0 60.0

business need,
Project training
Focus need, 6 15.0 15.0 80.0

Configuration
management
Focus on 8 20.0 20.0 100

business need,
Selection of
process,
Configuration
management
Total 40 100.0 100.0

Development
Chart 4.12 Key Process Areas for software metrics
INTERPRETATION
From the above frequency analysis the key process for implementing software
metrics is found to be focus on business needs, selection of appropriate

Development
measurement process and configuration management. Fig 4.12 shows the key
process areas for implementing software metrics.
4.13 FREQUENCY ANALYSIS FOR CRITICAL SUCCESS FACTORS
Table 4.13 Critical Success Factors for Software metrics

Percent Percent
Work effort 1 2.5 2.5 2.5

distribution
Work effort 3 7.5 7.5 10.0

distribution,
Product size,
test cases,
Documentation
Test cases, 2 5.0 5.0 15.0

Requirements.

Development
Work effort 3 7.5 7.5 22.5
distribution,
Product size
Work effort 4 10.0 10.0 32.5

distribution,
Test cases,
Documentation
Requirements
Product size, 7 17.5 17.5 50.0

Test cases,
Function point
Work effort 2 5.0 5.0 55.0

distribution,
Product size,
Test cases,
Function point,
Documentation
Requirements
Product size 2 5.0 5.0 60.0
Test cases 1 2.5 2.5 62.5
Function Point 1 2.5 2.5 65.0
Documentation 2 5.0 5.0 70.0
Requirements 2 5.0 5.0 75.0
Work effort 5 12.5 12.5 87.5

distribution,
Function Point
Work effort 2 5.0 5.0 92.5

distribution,
Test cases
Work effort 3 7.5 7.5 100

distribution,

Development
Documentation
Total 40 100.0 100.0
Chart 4.13 Critical Success Factors for Software metrics

Development
INFERENCE
From the above frequency analysis the critical success factors for implementing
software metrics is found to be the product size. It is measured by 17.5% of the total
respondent. Fig 4.13 shows the critical success factors for implementing software
metrics.

Development
5.1 FINDINGS
1. From the frequency analysis, it is found that most of the companies are
having CMMI level 3 certifications (Table 4.1).
2. The frequency analysis reveals that the mostly used infrastructure is training
method (Table 4.2)
3. From the frequency analysis it is found that, the schedule estimation accuracy
sometimes improved (Table 4.3).
4. The frequency analysis reveals that software metrics mainly helps in

improving the quality and timeliness (Table 4.4)
5. The frequency analysis shows the effectiveness of software metrics in

estimating project resource requirements is found to be approximate (Table
4.7).
6. The frequency analysis shows the effectiveness of software metrics in

identifying the processes is found to be essential (table 4.8).
7. The frequency analysis shows that the metrics does not help in bringing down
code and design complexity (table 4.9).

Development
5.2 CONCLUSION
Most of the Indian Software Organizations tried to implement software metrics in

CMM level 1 & 2 organizations. Due to lack of top management support, many
companies they are not able to implement the software metrics in their process.
The key process identified for implementing software metrics are focus on business
needs, selection of appropriate measurement process and configuration
management. Most of the software companies are using function-oriented metrics for
their software product development. The major infrastructure required for
implementing software metrics is training method. Software metrics mainly helps in
reducing the system testing time. It helps in reducing the system testing time by 2 to
3 weeks. It improves the schedule estimation accuracy only sometimes. Software
metrics does not helps in bringing down the code and design complexity. It helps in
improving the quality and timeliness. It is found that the effectiveness of software
metrics in estimating project requirements is found to be approximate. It indicates
that many software organizations are updating their function point analysis on a
quarterly basis. Finally, the software metrics helps in planning. Software metrics is
essential for all the organizations to improve the quality and reduce the maintenance
cost during the product development.

Development
5.3 SUGGESTIONS
• Software metrics should reduce the system testing time by 1-2 weeks.
• Top management support for implementing software metrics (52.5%) should

be more supportive.
• Project training should also be an important key process area for software
metrics.

Development
BIBLIOGRAPHY
Text Books
1. Richard I. Levin and David (2007), “Statistics for management”, Prentice-

Hall of India Private Limited
2. Rajendra Nargundkar (2006), “Marketing Research”, Tata McGraw Hill,

fourth edition.
Research Papers
1. Ashish Arora and Suma Athreye, “The software industry and its economic
development”, June 2009.
2. Bergeron, F. and J.Y. St. Arnaud, Estimation of Information Systems

Development Efforts: A Pilot Study. Information & Management, 2004, p. 239-254.
3. IEEE Standard 610.12-1990 Glossary of Software Engineering Terminology.

Development
4. Dr. Linda Rosenberg, Ted Hammer, Jack Shaw, “Software Metrics and
Reliability”, USA, 2005, p 87-95.
5. Felix Garcia, Francisco Ruiz, Mario Piattini (2004), “Definition and empirical
Validation of metrics for software Process Models” Alarcos Research Group, Spain
pp 146-158.
6. Heemstra, F.J. and R.J Kusters. Controlling Software Development Costs: A

Field Study in International Conference on Organisation and Information Systems,
2000, pp 90-104.
7. Kathleen Peters, Software Reliability: Measurement, Prediction, Application,

Professional Edition: Software Engineering Series, McGraw Hill, 2005, pp 390- 408.
8. Peter Liggemeyer, 2000, “A set of complexity metrics for guiding the software
test process” Corporate Research and Development, Germany, Volume 4, pp 257-
273.
9. Brady, Tim and Hobday, Michael, A Fast Method for Analysing and
Improving Complex Software Processes. R&D Management, Vol. 30, No. 1,
January 2000
ANNEXURE
The following annexure are to be provided as a part of the report at the end after
Bibliography.
• Questionnaire

Development
APPENDIX – 1
“MEASURING THE EFFECTIVENESS OF SOFTWARE METRICES IN

SOFTWARE PRODUCT DEVELOPMENT”

Development
Name of the Organization :
Address :
1. Have you implemented Software Metrics in your organization?
a) Yes ( ) b) No ( )
If, yes specify level of implementation of Software Metrics.
CMM Level-1 ( )
CMM Level-2 ( )
CMM Level-3 ( )
CMM Level-4 ( )
CMM Level-5 ( )
CMMI ( )
2. Please Choose the Key Process Areas for implementing Software Metrics
Focus on business needs ( )
Selection of appropriate measurement process ( )
Project training ( )
Configuration Management ( )
Software Product Engineering ( )
3. Please Choose the Critical Success Factors for Software Metrics
Work effort distribution ( )
Product size ( )
Test cases ( )

Development
Function Point ( )
Documentation ( )
Requirements ( )
4. What kind of Metrics is currently used for a specific project?
Size-oriented metrics ( )
KLOC ____________________
Effort Estimation Time _____________________
Function oriented metrics ( )
No of user inputs _____________________
No of user outputs _____________________
No of user inquiries _____________________
No of files _____________________
No of external interfaces _____________________
5. Top management support for implementation of Software Metrics?
Highly Supportive ( )
Supportive ( )
Less Supportive ( )
No Support ( )
6. What kind of infrastructure is currently used for Software Metrics?
Training ( )
Auditing ( )
Others (Specify) ( ) _________________________

Development
7. What Cost savings would Software Metrics provide?
a) System development cost ( ) b) System testing cost ( )
c) Maintenance cost ( ) d) Post implementation cost ( )
8. By how much does Software Metrics reduce the System Testing time?
a) 1-2 Weeks ( ) b) 2-3 Weeks ( )
c) 3-4 Weeks ( ) d) Others (Specify) ( )
9. Does Software Metrics improve Schedule Estimation Accuracy always?
a) Yes ( ) b) No ( )
c) Sometimes ( )
10. Does Software Metrics help in bringing down Code and Design
Complexity?
a) Yes ( ) b) No ( )
c) Sometimes ( )
11. Does Software Metrics help in analyzing the impacts on these attributes?
a) Quality & Timeliness b) Utility and Functionality
c) Improving Software-Related Products and Processes
d) Others (Please Specify)
12. How effective is Software Metrics in Estimating Project Resource
Requirements?
a) Accurate b) Approximate
c) Others (Please Specify)

Development
13. Software Metrics is effective in identifying Processes as,
a) Mandatory b) Essential
c) Optional
14. How often Software Metrics monitor the effectiveness of your software
delivery?
a) Monthly b) Quarterly
c) Half-Yearly d) Others
15. How does Software Metrics monitor the effectiveness of your software
delivery?
16. How does Software Metrics aid in Planning?

To Measure The Effectiveness of Software Metrics in Software Product Development

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

To Measure The Effectiveness of Software Metrics in Software Product Development

Загружено:

Авторское право:

Доступные форматы

To Measure the effectiveness of Software Metrics in Software Product

1.1 CLASSIFICATION OF SOFTWARE METRICS

The Oxford College of Business Management 1

1.3 SOFTWARE MEASUREMENT

The software is measured to,

• Indicate the quality of the product.

• Assess the productivity of the people who produce the product.

• Assess the benefits derived from new software engineering tools an

• Form a baseline for estimation.

• Help justify requests for new tools or training.

The Oxford College of Business Management 2

1.4 SIZE-ORIENTED METRICS

From this data some simple size-oriented metrics can be generated

Productivity= KLOC/ person-month

Quality= defects/ KLOC

1.5 FUNCTION-ORIENTD METRICS

Function-oriented metrics are indirect measures of software that focus on

The Oxford College of Business Management 3

1.6 USES OF METRICS

• Without measurements, there is no real way to determine if the process is

• When metrics are applied to a product it helps in identifying:

♦Which user requirements are likely to change

♦Which modules is most error prone.

♦How much testing should be planned for each module

1.7 BENEFITS OF SOFTWARE METRICS

• Instrumenting software processes helps complete projects on schedule,

• Use of software metrics is mandated by most software engineering standards

• Use of effective software metrics program stabilizes the software development

• A set of well tailored metrics for specific development strategy and

The Oxford College of Business Management 4

1.8 NEGOTIATING SCOPE

Processes can be easily identified and flagged as mandatory, essential or optional.

2.1 TITLE OF THE STUDY

“A Study to measure the effectiveness of Software Metrics in Software Product

2.2 REVIEW OF LITERATURE

2.2.1 SOFTWARE COST ESTIMATION

The Oxford College of Business Management 5

Table 2.1 Survey on estimation accuracy

Year of study’s first 1984 1988 1989 2003

Cost overrun 34%(median) 33% 18%(mean)

Project used more 61% 70% 63% 59%

than estimated effort

Project used less 10% 14% 15%

than estimated effort

Schedule overrun 22%(mean) 23%(mean)

Project completed 65% 80% 35%

2.2.2 IMPROVEMENT OF SOFTWARE PROCESSES

The Oxford College of Business Management 6

2.2.3 SOFTWARE QUALITY ASSURANCE THROUGH HIGH-LEVEL

2.2.4 EMPIRICAL VALIDATION FOR SOFTWARE PROCESS

The Oxford College of Business Management 7

2.2.5 SOFTWARE MAINTAINANCE

Software verifications and validation is a domain, which is covered by many dynamic

2.2.6 SOFTWARE MAINTAINANCE

Software industry currently spends 50% to 75% of its development budget on

2.2.7 SOFTWARE PROJECT ESTIMATION

The Oxford College of Business Management 8

2.2.7.1 ESTIMATING SIZE

2.2.7.2 ESTIMATING EFFORT

2.2.7.3 ESTIMATING COST

The Oxford College of Business Management 9

2.3 STATEMENT OF THE PROBLEM