A study on quality parameters of software and the metrics

International Journal of Computer and Technology (IJCET), ISSN 0976 – 6367(Print),
International Journal of Computer Engineering Engineering
and Technology (IJCET), ISSN 0976May - June Print) © IAEME
ISSN 0976 – 6375(Online) Volume 1, Number 1, – 6367( (2010),
ISSN 0976 – 6375(Online) Volume 1 IJCET
Number 1, May - June (2010), pp. 235-249 ©IAEME
© IAEME, http://www.iaeme.com/ijcet.html

A STUDY ON QUALITY PARAMETERS OF SOFTWARE
AND THE METRICS FOR EVALUATION
J.Emi Retna
Karunya University
Karunya nagar, Coimbatore
E-Mail: jemiretna@yahoo.co.in

Greeshma Varghese
Karunya University
E-Mail: greeshma_2010@gmail.com

Merlin Soosaiya
Karunya University
E-Mail: merlinsoosaiya@gmail.com

Sumy Joseph
Karunya University
E-Mail: almerah.joseph@gmail.com

ABSTRACT
Software Quality is one of the illusive targets to achieve in the software
development for the successful software projects. Software Quality activities are
conducted throughout the project life cycle to provide objective insight into the maturity
and quality of the software processes and associated work products. Software Quality
activities are performed during each traditional development phase. There are many
parameters or attributes which helps to ensure the quality of the software. The paper
analyses and a detailed report are presented on each quality attribute parameter.
INTRODUCTION
Gone are the days when software quality was thought of as a luxury. But now
software quality is one of the illusive targets to achieve in the software development. The
successful software projects achieve excellence in software quality. Today it is viewed as

235

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 – 6367(Print),
ISSN 0976 – 6375(Online) Volume 1, Number 1, May - June (2010), © IAEME

an essential parameter with any software delivered. Software quality has several
definitions and is viewed in several perspectives. Software built with all the requirements
specified by the client or software that has 0% defect (practically impossible) cannot be
deemed as of high quality. Quality however is not a single parameter but it is a collection
of parameters and it has a multidimensional concept. According to Crosby, quality is
defined as “a conformance to requirements”, which means the extent to which the
product conforms to the intent of design. Quality of design can be regarded as the
determination of requirements and specifications and quality of conformance is
conformance to requirements. Some of the parameters that add up to the quality of
software are as given below: Capability (Functionality), Scalability, Usability,
Performance, Reliability, Maintainability, Durability, Serviceability, Availability,
Installability, Structured ness and Efficiency.
There are two types of parameters namely functional parameters and non
functional parameters. Functional parameters deal with the functionality or functional
aspects of the application while non functional parameters deal with the non-functional
parameters (but desirable) like usability, maintainability that a developer usually doesn’t
think of at the time of development. Generally the non functional parameters are
considered only in the maintenance phase or after the software is being developed which
causes rework or additional effort requirement. Hence it is a best practice to consider
quality even in the initial phases of software development and deliver the software with
high quality and on time. Some of the quality parameters are interrelated as specified
Figure 1 Interrelationships of Software Attributes in figure 1 [1].

236


Parameters Models and Metrics Features to improve parameters
Capability 1. Function Point 1. Security of overall system
(Functionality) 2. Feature set and capabilities of the program
Usability 1. Questionnaires, Testing 1. GUI
2. Error Rate 2. Component reuse
3. ISO 9241-11
Performance 1. Execution Time 1. Reduced hit ratio
2. Time Reduction 2. Cache
3. Idle Time Reduction 3. Improved Processing Power
4. Response Time 4. Software engineering practices
5. Completion Rate 5. Design
6. Throughput 6. Understanding user requirements
7. Service Unit Reduction 7. Architecture Design
8. Meeting user’s expectations
9. Problem resolution
10. Timeliness
Reliability 1. exponential distribution models 1. Consistency
2. Weibull distribution model 2. Data Integrity
3. Thompson and Chelson's model 3. Accuracy
4. Jelinski Moranda model
5. LittleWood Model
6. MTTF (Mean Time To Failure)
7. MTTR (Mean Time To Repair)
8. POFOD (Probability of failure on demand)
9. Rate of fault occurrence
10. Reliability = MTBF/(1+MTBF)
Maintainability 1. Models like HPMAS 1. Stability
2. Polynomial assessment tool
3. Principle Components Analysis
4. Aggregate Complexity Measure
5. Factor Analysis
Durability 1. Reliability 1. Data Redundancy
(also include 2. Availability - Replication
session 3. Markov Chain Model - Erasure Coding
durability) 4. Supplier / Component Subsystem quality audits 2. Data Repair
5. PPM Defects - Failure Detection
6. % right first time - Repair
7. Initial Quality Survey
8. Customer Satisfaction
9. Warranty Claim Rates
Serviceability 1. Mean Time To Repair = Unsheduled 1. Help desk notification of exceptional events
downtime/ no. of failures 2.Network Monitoring
2. Mean nodenours to repair = Unsheduled 3.Documentation
downtime nodehours/ no.of failures 4.Event Logging
3. Mean time to boot system = sum of wall clock 5Training
time booting system/ no of boot events 6Maintenance
Availability 1. System Uptime Work product is operational and available for
Mean Time To Failure use
2.
Mean Time To Failure+Mean Time To Repair
*100%

237


Installability 1. Total installability time 1. Effort needed to install software
2. Total count of installers
3. % of installers involved only in tuning
4. Time spent for user training
5. Count of database reports written
6. “custom features” percentage
7. Customer’s negotiation strength
8. GQM
Scalability 1. Load scalability 1. Application specific factors
2. Service scalability 2. Load generation tool related
3. Data scalability 3. Hardware configuration of load client
4. Page/screen response time 4. Architecture Design
Productivity 1. Programmer productivity = 1. To reduce defect levels
LOC Produced 2. Defect prevention and removal
Person Months of Effort technologies
amount of output 3. Defect Removal Efficiency
2. Productivity =
effort input
Complexity 1. Cyclomatic Complexity (or conditional 1. Increase in RFC(Request for a class)
complexity), V (G) = E – N + 2 where E is the 2. Inheritance
number of flow graph edges and N is the 3. module strength
number of nodes. 4. Degree of data sharing
2. McClure’s Complexity Metric= C + V where C
is the number of comparisons in a module and
V is the number of control variables referenced
in the module
3. Cohesion STRENGTH =
where X is reciprocal of the number of
assignment statements in a module and Y is the
number of unique function outputs divided by
number of unique function inputs.

4. Coupling = where Zi =
Efficiency (of 1. Resource Utilization 1.Usage of CPU
algorithms) 2. Level of performance 2.I/O capacity
3. End-to-end error detection like performance
defects appear under heavy load
3.Usage of RAM
Reusability 1. Reuse percent- the de facto standard measure of 1. Software system independence.
reuse level = (Reused Software / Total 2. Machine independence.
Software) *100 3. Generality.
2. Use objective metrics on subjective data to 4. Modularity.
obtain reusability readings
Portability 1. Portability =1–(Resources needed to move 1. Design documentation
system to the target environment/Resource 2. Code
needed to create system for the resident
environment)
Testability 1. Effort needed for validating the modified 1. Related with code
software
2. Effort required to test a program
Effort/Cost 1. Boehm’s COCOMO model 1. Preparation and execution
2. Putnam’s SLIM model 2. Ease of maintenance
3. Albrecht’s Function Point model 3. Effort on duplicates and invalids
Table 1: Quality Parameters with models /metrics

238


Generally if there is a reliability problem the usability of an application is rated
poor. If the application becomes unavailable (availability factor decreases), then again the
performance is rated low. If the performance of software improves it means factors such
as availability are high. Hence all the parameters are inter-related and proportional.
Table1 proposes the quality parameters, the key models and their key metrics. The
feature that enhances the quality parameter is also listed.
1. CAPABILITY (FUNCTIONALITY)
Functionality captures the amount of function contained on a product. Often
functionality is measured rather than the physical code size. The software being
developed needs to satisfy all the functional requirements. Functional requirements
include almost all the user requirements or business requirements – the “what for the
software is being developed”. Once all the functionality is developed then the software
becomes deliverable. The software developers, testers and quality practitioners are
entrusted to verify if all the functional requirements are covered in software. If the
functionality is developed the defects will be minimal in software.
There are some sub characteristics that can be derived from the quality features of
software [3].

Figure 2 Functionality
Suitability: Attributes of software that bear on the presence and appropriateness of a set
of functions for specified tasks.
Accurateness: Attributes of software that bear on the provision of right or agreed results
or effects.
Interoperability: Attributes of software that bear on its ability to interact with specified
systems.

239


Compliance: Attributes of software that make the software adhere to application related
standards or conventions or regulations in laws and similar prescriptions.
Security: Attributes of software that bears on its ability to prevent unauthorized access,
whether accidental or deliberate, to programs or data. The most widely used metric is the
“Function Point” metric. Function Points are measures of software size, functionality, and
complexity used as a basis for software cost estimation [3].The procedure to calculate the
Function Point is as explained below:
Step 1: Determine the unadjusted function point count(UFP)
1. Count the number of external inputs.
External inputs are those items provided by the user (e.g.) file names and menu
selections)
2. count the number of external outputs
External outputs are those items provided to the user (e.g.) reports and messages
3. Count the number of external inquiries External inquiries are interactive inputs
that needs a response
4. Count the number of internal logical files
5. Count the number of external interface files
Table 2 Determination of UFP

Weighting
Item Simple Factor Complex
Average
External 3 4 6
inputs 4 5 7
External 3 4 6
output 7 10 15
External 5 7 10
inquiries
External files
Internal files
UFC= ∑((Number of items of variety i) *weight i)
i=1

VAF = 0.65 + (0.01 * TDI)

FP = UFP * VAF

240


Table 3 The general system characteristics

General System Brief Description
Characteristic

1. Data How many communication facilities are there to aid in the
communications transfer or exchange of information with the application or
system?

2. Distributed data How are distributed data and processing functions handled?
processing

3. Performance Was response time or throughput required by the user?

4. Heavily used How heavily used is the current hardware platform where
configuration the application will be executed?

5. Transaction rate How frequently are transactions executed daily, weekly,
monthly, etc.?

6. On-Line data entry What percentage of the information is entered On-Line?

7. End-user efficiency Was the application designed for end-user efficiency?

8. On-Line update How many ILF’s are updated by On-Line transaction?

9. Complex processing Does the application have extensive logical or mathematical
processing?

10. Reusability Was the application developed to meet one or many user’s
needs?

11. Installation ease How difficult is conversion and installation?

12. Operational ease How effective and/or automated are start-up, back-up, and
recovery procedures?

13. Multiple sites Was the application specifically designed, developed, and
supported to be installed at multiple sites for multiple
organizations?

14. Facilitate change Was the application specifically designed, developed, and
supported to facilitate change?

241


Step 2: Determine the value adjustment factor (VAF)
VAF is based on the Total Degree of Influence (TDI) of the 14 general system
characteristics.
TDI = Sum of Degree of Influence of 14 General System Characteristics (GSC). These
14 GSC are listed in Table 3.
II. USABILITY
Boehm defined software usability as the extent to which the product is convenient
and practical to use. The software usability is considered as a combined form of
understandability, learn ability, operability and finally the attractiveness of the product to
the final user or user group [Pressman, 1999].How usable is software? Determines its
longevity. Usability evaluation yields better results only if there is a good usability
design. The usability evaluation can be user based or expert based. The software has to be
usable. Usability depends on parameters such as ease-of-use, comfort level, simplicity
etc. Functional software without the usable factor will be least desired. If the User
Interface is designed with user friendliness in mind it adds to usability. Figure 2 depicts
the consolidated usability model by Abron. As in the figure usability factor increase only
if an application is effective, efficient, user expectations satisfied, ease to use and highly
secure.

Figure 3 Usability
Some of the methods adopted to measure usability are
a. How satisfied is the user
b. Whether the user is able to perform the task intended (task success)
c. The problems encountered when using the software (failure)
d. The time taken to complete the task
d. Task completion rates, task time, and satisfaction and error counts.

242


e. Ease of use
f. Download delay
g. More navigability
h. Interactivity
i. More responsive
j. Higher quality
To improve usability it is important to improve page reduction so that the page is
informative and the information needs of the user are satisfied. Website download delay
affects usability.
Table 4. Usability Design Factors

III. PERFORMANCE
There are lots of factors that affect the performance of software like communication
failure, poor bandwidth, hardware or component failure. The parameters for performance
evaluation are:
1. Execution time
2. Service unit reduction
3. Idle time reduction
4. No of tasks completed
A high performance application can be designed using various technologies like:

243


1. Caching
2. Multiple servers running on different machines
3. Thread management
4. Improved page design
The selection of tools, technology/platform, design, knowledge base etc plays a
vital role in the performance of an application. Appropriate models needs to be chosen at
the early stage of software development itself. For e.g., Let us consider website
performance analysis. The performance of a website is analyzed from a customer’s
perspective. When the user is only interested in checking the mails , he may log into any
websites that provide mailing services. The leading email providers have their own
design and functionality built-in. Some of the email service providers, on login directs to
the user’s mailbox (category 1)while some other email service providers, on logging in
provide a informative or a little junk page rather than directing to the user’s mailbox on
log in (category 2). So category 1 provides much better performance than category 2
since when the user’s perspective is to check mails timeliness is met by category 1 and
not category 2.The responsiveness of
websites and the performance can be measured using tools that are available like ECperf

Figure 4 Reliability

Maturity: Attributes of software that bear on the frequency of failure by faults in the
software
Fault Tolerance: Attributes of software that bear on its ability to maintain a specified
level of performance in case of software faults or of infringement of its specified
interface.

244


Recoverability: Attributes of software that bear on the capability to re-establish its level
of performance and recover the data directly affected in case of a failure and on the time
and effort needed for it.
Probability of failure on demand (POFOD) is a measure of the likelihood that the
system will fail when a service request is made. It is relevant for safety critical or non-
stop systems. Rate of fault occurrence is relevant for operating systems, transaction
processing systems etc. It considers the frequency of unexpected behavior. Mean Time
To Failure is the time between observed failures. Reliability is the capability of the
software product to maintain a specified level of performance when used under specified
conditions [9]. Reliability measures include 3 components:
1) Measuring the number of system failures for a given number of system inputs
2) Measuring the time or number of transactions between system failures
3) Measuring the time to restart after failure

IV. MATHEMATICAL CONCEPTS OF RELIABILITY

Mathematically reliability R(t) is the probability that a system will be successful
in the interval from time 0 to time t: [6]
R(t) = P(T > t), t => 0
where T is a random variable denoting the time-to-failure or failure time. Unreliability
F(t), a measure of failure, is defined as the probability that the system will fail by time t.
F(t) = P(T =< t), t => 0.
In other words, F(t) is the failure distribution function. The following relationship
applies to reliability in general. The Reliability R(t), is related to failure probability F(t)
by:
R(t) = 1 - F(t).
V. MAINTAINABILITY
The capability of the software product to be modified. Modifications may include
corrections, improvements or adaptation of the software to change in environment, and in
requirements and functional specifications" [7]. Proper documentation needs to be
maintained for maintaining software. The document needs to be complete and updated.

245


Software Maintainability assessment can be conducted at various levels of granularity. At
the component level models can be used to monitor changes to the system as they occur
and to predict fault occurring at software components. At the file level we can use models
to identify subsystem that are not well organized. Models like HPMAS [5], a hierarchical
multidimensional assessment model can be used. The important sub attributes for
Maintainability are:
Analyzability: Attributes of software that bear on the effort needed for diagnosis of
deficiencies or causes of failures, or for identification of parts to be modified.
Changeability: Attributes of software that bear on the effort needed for modification,
fault removal or for environmental change.
Stability: Attributes of software that bear on the risk of unexpected effect of
modifications.
Testability: Attributes of software that bear on the effort needed for validating the
modified software

Fig. 5 Maintainability
VI. DURABILITY
Software usability efforts improve software durability. Software durability can be
data durability or session durability. Session durability generally speaking is of short
duration. Technologies like data replication, data repair can be used to enhance
durability. Reliability and availability can be considered as metrics for data durability.
VII. SERVICEABILITY
Serviceability is the ability to offer promised services by the software or
application. With software it deals with the support offered in terms of user manual,
technical help, problem resolvement etc. As new versions of software get released, the

246


software get released, the support for the older versions vanishes. Incorporating
serviceability facilitating features typically results in more efficient product maintenance,
reduced operational cost etc. The maintainability feature can be inbuilt within the system.
Systems can be built with features that automatically shoot mails or log a service call on
experiencing a fault
VIII. AVAILABILITY
Availability is the measure of how likely the system is available for use. It
considers the repair or restart time into account. Reliability and availability goes hand-in-
hand. Software needs to be available even as the load increases. Availability of 0.997
means the software is available 997 out of 1000 time units.
IX. INSTALLABILITY
Software needs to be easily installable. The parameter that needs to be set to install
software needs to be easy. The software needs to be configurable.
X. SCALABILITY
The software needs to be highly scalable in all environments. Scalability can be
interms of load, service, data atc. A system inorder to be highly scalable needs to have
the ability to handle large transactions and load. As the load increases in production a
desirable system will be able to scale up with additional hardware resources either
vertically or horizontally. Vertical Scaling is when inorder to support an increase in load,
an individual server is given increased memory or processing power. Horizontal scaling
is when increased load is handled by adding servers to a distributed system.
XI. COMPLEXITY
Low coupling is often a sign of well-structured system and good design [5]. High
levels of coupling usually will be associated with lower productivity. Complexity can be
of two types.
a) Apparent complexity, is the degree to which a system or component has a design
or implementation that is difficult to understand and verify.
b) Inherent complexity, is the degree of complications of a system or system
component determined by such factors as the number and intricacy of

247


interfaces[4], the number and intricacy of conditional branches, the degree of
nesting, and the type of data structures
Metrics used for measuring the qualities of Software
Some software metrics include:
• Total Lines of code
• Number of characters
• Number of Comments
• Number of comment characters
• Code characters
• Halstead's estimate of program length metric
• Jensen's estimate of program length metric
• Cyclomatic complexity metric
CONCLUSION
Good engineering methods can largely improve software reliability. Before the
deployment of software products, testing, verification and validation are necessary steps.
Software testing is heavily used to trigger, locate and remove software defects. Software
testing is still in its infant stage; testing is crafted to suit specific needs in various
software development projects in an ad-hoc manner. Various analysis tools such as trend
analysis, fault-tree analysis, Orthogonal Defect classification and formal methods, etc,
can also be used to minimize the possibility of defect occurrence after release and
therefore improve software reliability. After deployment of the software product, field
data can be gathered and analyzed to study the behavior of software defects. Fault
tolerance or fault/failure forecasting techniques will be helpful techniques and guide rules
to minimize fault occurrence or impact of the fault on the system.
REFERENCES:
[1] Stephen H. Kan, Metrics and Models in Software Quality Engineering, Second
Edition.
[2] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous and Practical Approach,
Second Edition.
[3] http://davidfrico.com/fpfull.pdf

248


[4] Software Quality assurance: Principles and Practice -Nina S God bole
[5] Software Reliability Engineering-John D.Musa
[6] Roger S. Pressman. Software Engineering a practitioner's Approach. McGraw-Hill,
Inc., 1992.
[7] International Standard. ISO/IEC 9126-1. Institute of Electrical and Electronics
Engineers, Part 1, 2, 3: Quality model, 2001. http://www.iso.ch.
[8] International Standard. ISO/IEC 9126-1 (2001), Institute of Electrical and Electronics
Engineering, Part 1,2,3: Quality Model, 2001, http://www.iso.ch

249

A study on quality parameters of software and the metrics

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie A study on quality parameters of software and the metrics

Ähnlich wie A study on quality parameters of software and the metrics (20)

Mehr von iaemedu

Mehr von iaemedu (20)

A study on quality parameters of software and the metrics