CHAPTER 5shodhganga.inflibnet.ac.in/bitstream/10603/23847/6/chapter 5.pdf · model is evaluating the quality of the product when each software product has different quality than the

CHAPTER 5

QUALITY MODEL FOR OBJECT ORIENTED

SOFTWARE SYSTEM

5.1 INTRODUCTION

Object-oriented software development is an emerging way of thinking about

software based on abstraction of objects that exist in the real world domain. Better

software development environments can be created using object-oriented approach and

this is the reason that this approach is gaining a lot of attention from the software

development communities as it reduces the size of system and logical constructs.

Software quality is considered as a very important aspect for developers, users and

project managers.

The various concepts like usability, reusability, testability, understandability,

complexity, productivity, reliability, extensibility maintainability and flexibility etc. are

correlated with object-oriented features that enhance the quality of software system. The

concept of inheritance helps software developers to incorporate reusability factor in

software development process. Quality of software system improves as reusability

reduces the complexity (Eliens, 2000). The concept of encapsulation enhances software

quality by ensuring safety via information hiding (Satzinger et al., 2002).

Inspite of wide applicability of object-oriented design in software development

environment, few efforts have been made in the context of judging the quality of object-

oriented software system as well as proposal of quality model. This chapter proposes a

quality model named Model for Object Oriented Software QUAlity derived from

ISO/IEC 9126-1 (2001). AHP technique is used to evaluate the proposed quality model.

AHP technique is beneficial as it provides a structured as well as simple solution for

decision making problems (Saaty, 1980) and has been extensively adopted in multi-

criteria decision making and successfully applied to many practical decision making

problems (Saaty, 1980).

5.2 SOFTWARE QUALITY

The definition of quality as described by IEEE (1991) is ‘the degree to which a

system, component, or process meets specified requirements, customer or user needs or

expectations.’ In business context, software quality refers to two related but distinct

notion i.e. software functional quality and software structural quality (Pressman, 1992).

Software quality is the extent to which an industry-defined set of desirable features

reincorporated into a product so as to enhance its lifetime performance (Fitzpatrick,

1996). Schulmeyer and McManus (1996) defined software quality as ‘all functions and

factors of a software product that satisfy consumer needs’. Deutsch and Wills (1998)

categorized software quality as software procedure quality (tools, technology,

equipment, personnel and organization) and software product quality (organization,

document clarity, design trace-ability, integrity, test integrity and program reliability).

Software quality is also defined as ‘confirming with explicitly stated functional and

performance requirements, explicitly documented development standards and implicit

factors that are expected of all professional developed software’ (Pressman, 2001).

5.2.1 Software Quality Models

The evaluation of software system quality depends upon various factors like

quality model and quality factors. A quality model is usually defined as a structured set

of properties that are needed for an object of a class to meet defined purposes (Fusani,

1995). According to Dukic and Boegh (2003), “software quality model is defined as a

set of factors and relationships between them that provide the basis for specifying

quality requirements and evaluating quality”. As a consequence, a software quality

model is a good tool to evaluate the quality of a software product (Sacha, 2005). A more

concise definition of a quality model is presented by Donald FireSmith (2005), which

defines a quality model as a hierarchical model (i.e. a layered collection of related

abstractions and simplifications) for formalizing the quality of a system in terms of its

factors, sub-factors, criteria and measures as described below:

i. Quality factors – high level factors of a system that capture major aspects of its

quality (e.g., functionality, performance or reliability);

ii. Quality sub-factors – major components of the quality factors mentioned above

that capture a subordinate aspect of the quality of the systems (e.g., accuracy or

expansibility);

iii. Quality attributes – specific descriptions of a system that provide evidence for

or against the existence of a specific quality factor or sub-factor;

iv. Quality measures – make quality attributes measurable, objective and

unambiguous.

The benefit of quality model is given by decomposition of object like process,

product or organization in the list of its factors/sub-factors measures. Quality, apart from

describing and measuring the functional aspects of software, also describes the extra

functional properties such as how system is built and how it performs. In software

engineering literature a number of quality models have been proposed, each one of these

quality models consists of several quality factors. The quality of software system reflects

in the term of these quality factors. The various quality models are defined in following

sub-sections.

5.2.1.1 McCall Model

The first and well known quality model was proposed by McCall (1977). The

basic objective of this model is to improve and enhance the quality of product and to

design a layout for product quality through its various factors. The model developed

mainly for system developers and system development process. The basic aim of

McCall's quality model is to assess the relationship among external quality factors and

product quality criteria. McCall Model presents the relationship between quality factors

and metrics as a major contribution. This model does not consider functionality of

software product directly. In this model, the quality of software has been categorized in

three different parts namely: product revision (maintainability, flexibility and

testability), product transition (portability, reusability and interoperability) and product

operation (correctness, reliability, efficiency, integrity and usability). Product revision

property defines the ability of the software product to undergo changes, the product

transition property stands for the adaptability of the software to new environments and

the product operations property represents the software operation factors. These

categories include several quality factors (Table 5.1). Their relationship between McCall

quality factors is represented in Table 5.2.

Table 5.1: McCall Quality Factors and Metrics

Property Characteristic Definition

Product

Revision

Maintainability The efforts that required to locate and fix an error in a

program.

Flexibility The capability and effort of a system to support

required changes.

Testability The ability of a system to deal with testing of

information system to ensure that it performs its

intended function.

Product

Transition

Portability The ease of installing the software product on different

hardware and software platforms.

Reusability The ability of a system to deal with the reuse of

software in different context.

Interoperability The ability to create interfaces or the effort required to

couple the system with other systems.

Product

Operation

Correctness The extent to which a system performs according to

defined specification and fulfills the customer's

mission objectives

Reliability The Extent to which a program can be expected to

perform its intended function with required precision.

Efficiency The ability of a system to place as few demands as

possible to hardware resources, such as memory,

bandwidth used in communication and processor time.

Integrity The protection of the software against unauthorized

access.

Usability The ease to operate the software system.

Table 5.2 Relationship Between McCall Quality Factors and Metrics

Software

Quality Metrics

Quality Factors

Corr

ect

nes

s

Rel

iab

ilit

y

Eff

icie

ncy

Inte

gri

ty

Main

tain

ab

ilit

y

Fle

xib

ilit

y

Tes

tab

ilit

y

Port

ab

ilit

y

Reu

sab

ilit

y

Inte

rop

erab

ilit

y

Usa

bil

ity

Auditability X X

Accuracy X

Communication

commonality

X

Completeness X

Conciseness X X X

Consistency X X X X

Data

commonality

X

Error tolerance X

Execution

efficiency

X

Expandability X

Generality X X X X

Hardware

independence

X X

Instrumentation X X X

Modularity X X X X X X X

Operability X X

Security X

Self -

documentation

X X X X X

Simplicity X X X X

Software system

independence

X X

Traceability X

Training X

5.2.1.2 Boehm Model

Boehm (1978) has developed an improved quality model by adding some factors

to the McCall model. This model represents software quality in terms of quality factors

and metrics. The proposed model was able to evaluate the s/w product with respect to

the utility of the program. Upon analyzing the Boehm model one sees that it begins with

the software's general utility. Boehm model is very similar to McCall’s model in all

other respect including the representation of hierarchical structure of factors. This model

includes users need in similar way as the McCall’s model does. But, the important

factors that the model adds are the hardware yield factors which were not encountered in

McCall’s model earlier. Both McCall and Boehm model are hierarchical quality models

structured around high, intermediate and primitive level factors. Boehm’s model is

based on a wider range of factors and in corporate criteria. In this model, the higher level

represents software quality, next level represents quality factors and lower level

represents metrics. The biggest difference between Boehm and McCall is, that Boehm’s

Model bases on a broad range of quality factors with a primarily focus on

maintainability. McCall on the other hand focuses more on the precise measurement of

the high-level property “As-is Utility”. On the higher level factors of Boehm’s quality

hierarchy, there are three high-level factors addressing three main questions that a buyer

of software may have.

i. As-is utility: How well (easily, reliably, efficiently) can I use it as-is?

ii. Maintainability: How easy is it to understand modify and retest?

iii. Portability: Can I still use it if I change my environment?

At the intermediate level there are 7 quality factors that represent the qualities

expected from a software system:

i. Portability: The code can be operated easily and well on other environments.

ii. Reliability: The code performs its intended functions satisfactorily.

iii. Efficiency: The code executes its intention without waste of resources.

iv. Usability: The code is reliable, efficient and human-friendly-engineered.

v. Testability: The code eases setting up verification criteria and supports

evaluation

of its performance.

vi. Understandability: The code is easy to read in the sense, that inspectors can

rapidly recognize its purpose.

vii. Modifiability: The code is easy to change, when a desired change has been

determined.

At the bottom level of the model there are primitive factors metrics hierarchies.

This factors form the basis to define quality metrics. The model proposes consequently

at least one metric, which should measure a given primitive characteristic.

5.2.1.3 FURPS Model

FURPS model (1987) proposed by Grady and Hewlett Packard Co. FURPS

model decomposes characteristic in two categories of requirements namely functional

requirements. Functional requirements are defined by input and expected outputs, while

no-functional (also known as URPS where U stands for usability, R stands for

reliability, P stands for performance and S stands for supportability). This model is

further extended by IBM Rational Software into FURPS+, where the ‘+’ indicates

requirements as design constraints, implementation requirements, interface requirements

and physical requirements (Jacobson et al. 1999, Kruchten 2000). When FURPS model

is used, two steps are considered: setting priorities and defining quality attributes that

can be measured. Grady and Canswell (1987) suggested that setting priorities is

important for given the implicit trade-off. The main factors of FURPS model are:

Table 5.3: Factors of FURPS Model

Characteristic Definition/Sub-factors

Functionality which includes feature sets, capabilities and security;

Usability which includes human factors, aesthetics, consistency in the user

interface, online and context sensitive help, wizards and agents, user

documentation, and training materials;

Reliability which includes frequency and severity of failure, recoverability,

predictability, accuracy, and mean time between failure (MTBF);

Portability The ease of installing the software product on different hardware

and software platforms.

Supportability which includes testability, extensibility, adaptability, compatibility

and instability.

5.2.1.4 Dromey Model

Dromey (1995) quality model is based on evaluation criteria. The aim of this

model is evaluating the quality of the product when each software product has different

quality than the other. Dromey described that a more dynamic range of evaluation

techniques are required to be applied to cover a wider range of software systems. This

model is designed on the relationship between quality factors and sub-factors between

software properties and software quality factors. Dromey’s generic quality model deals

with three principal elements including the product properties that influence quality, a

set of high-level quality factors, and a means of linking them. For his model, Dromey

choose a list of quality factors, which is similar to the ISO/IEC 9126-1. As an extension

to ISO/IEC 9126-1, he added the factors reusability and maturity. Process maturity is a

characteristic which has not been considered in the previous models. Dromey developed

his model based on the relationship between quality factors and sub-factors. He also

showed a relationship between software product properties and software quality factors.

5.2.1.5 ISO/IEC 9126-1 Model

This model is a derivation of the McCall’s model. It defines software quality as

the totality of features and characteristic of a software product that bear on its ability to

satisfy stated or implied needs. Three different perspectives of software quality have

been explained;

i. User View: as a quality of final product;

ii. Developer View: as the quality of intermediate products generated by different

stakeholders during the development process;

iii. Manager View: as the marketing requirements.

Hence, overall quality of product may be expressed by a combination of these

different views. McCall distinguishes between two levels of quality features, which are

factors, and criteria. This inspired to develop ISO/IEC 9126-1 model (2001). The model

proposes a set of independent high-level quality factors, which are defined as a set of

attributes of a software product by which its quality is described and evaluated. Quality

factors are used as the target for validation and verification at various stages of

development and refined into sub-factors, until the attribute or measurable properties are

obtained.

ISO/IEC 9126-1 comprises six factors and twenty seven sub-factors of software

product quality. This quality model has two main parts consisting of internal and

external quality factors and quality in use factors. The internal quality factors refers to

the properties of the system that can be evaluated without executing it while external

quality factors refers to the system properties that may be evaluated by observing the

system during its execution. The quality in use factors refers to the properties of the

system that are experienced by the users of the system when the system is in operable

condition and also during its maintenance. The factors of this model (Table 5.4) are

functionality, reliability, usability, efficiency, maintainability and portability.

Table 5.4: ISO/IEC 9126-1 Model

Quality Type Factors Sub-Factors

Software Product

Quality

Functionality

Suitability

Accuracy

Interoperability

Security

Compliance

Reliability

Maturity

Fault Tolerance

Recoverability

Usability

Understandability

Learnability

Operability

Attractiveness

Efficiency Time Behaviour

Resource Behaviour

Maintainability

Analyzability

Changeability

Testability

Stability

Portability

Replace-ability

Adaptability

Install-ability

Co-Existence

5.2.1.6 SATC Model

Software Assurance Technology Center (SATC), working for NASA to improve

the software quality , is assisting software managers in establishing metrics programs

that meet their needs with minimal costs, and in interpreting the resulting metrics in the

context of the supported projects. Using the results of these metric programs and

discussions with projects as a basis, the SATC is currently defining and testing a quality

model for software. The SATC model defines a set of goals (Rosenberg and Hyatt,

1995). The goals are then related to software product and process attributes that allow

indications of the probability of success in meeting theses goals:

i. Requirements Quality

ii. Product Quality

iii. Implementation Effectively

iv. Testing Effectively

Rosenberg and Hyatt (1995) described that object-oriented software development

requires a different approach from more traditional functional decomposition and data

flow development methods. The object oriented metric criteria are to be used to evaluate

the following quality attributes:

i. Efficiency: Are the constructs efficiently designed?

ii. Complexity: Could the constructs be used more effectively to decrease the

architectural complexity?

iii. Understandability: Psychological complexity increased by the design or not?

iv. Reusability: Possible reuse is supported by the design or not?

v. Testability/Maintainability: Ease of testing and changes are supported by the

structure or not?

A set of metrics is chosen or developed that measure the selected attributes. The

SATC’s software quality model is shown in Table 5.5. The table shows all of the goals,

attributes, and metrics in the model. Each goal has attributes, and each attribute has

associated metrics. According to Briand et al. (1999), the use of object-oriented

technologies enhance the deliverable software product quality, support reusability and

involve less efforts for developing and maintaining software system.

Table 5.5 : SATC’s Quality Model

Goals Attributes Metrics

Requirement quality Ambiguity Number of weak phrases

Number of optional phrases

Completeness Number of TBDs./TBAs

Understandability Document structure

Readability Index

Volatility Count of changes/Count of

requirements

Traceability Number of software requirements

not traced to system requirements

Number of software requirements

not traced to code and tests

Product (code)

Quality

Structure/Architecture Logic complexity

GOTO usage

Size

Maintainability Correlation of complexity/size

Reusability Correlation of complexity/size

Internal Documentation Comment Percentage

External Documentation Readability Index

Implementation

Effectively

Resource Usage Staff hours spent on life cycle

Activities

Completion Rates Task completion

Planned task completions

Testing Effectively Correctness Errors and criticality

Time of finding of errors

Time of error fixes

Code Location of fault

Khan et al. (2004) designed the relationship between design constructs and

quality attributes of SATC’s attributes. This relation is represented in Figure 5.3.

Figure 5.1: Relationship Between Object Oriented Design Constructs and Quality

Factors (Khan et al. 2004)

5.2.1.7 Quality Model for Object Oriented Design

Quality Model for Object Oriented Design (QMMOD) is a quality model for

assessing high-level external quality attributes such as reusability, functionality, and

flexibility of object-oriented designs based on the internal properties of design

components (Bansiya, 1992). In this model, tangible design properties (both structural

and functional) of components and their manifestation in a product contribute to object

oriented design properties, which are high-level software properties (not directly

tangible) such as abstraction, encapsulation, coupling, and cohesion.

The model relates object-oriented design properties to set of high-level external

quality attributes using empirical and anecdotal information. The relationship, or links,

from design factors to external quality attributes are assigned values based on the

importance of their contribution to a particular quality attribute. The model can be easily

Encapsulation

Inheritance

Coupling

Cohesion

Efficiency

Complexity

Reusability

Understand

ability

Testability/

Maintain-

ability

modified to include different suites of design metrics, design properties, linking

relationships, and quality attributes.

5.3 ISO/IEC 9126-1 BASED QUALITY MODELS

The ISO/IEC 9126-1 model provides a base for almost all types of proposed

quality models for different environment. The factors of ISO/IEC 9126-1 model viz.

functionality, usability, efficiency, reliability, portability and maintainability are

available in almost all the proposed quality models. These models differ among each

other by selection/rejection of sub-factors under above mentioned factors.

Berota et al. (2002) proposed a quality model for COTS component system. The

compatibility sub-characteristic is defined under the functionality factors of ISO/IEC

9126–I model. This model fails to perform evaluation of quality of system.

The quality model by Kazman et al. (2003) divided the quality factors into two

observable groups: during the time of performance and during the Software existence

cycle. The suggested two groups are:

i. efficiency, security, availability, function.

ii. modifiability, portability, reusability, inheritability and testability.

Elli Georgiadou (2003) proposed a generic quality model. The basic idea behind

this model is to let the stakeholders develop their own model on the basis of their

requirements. The focus of this model was on product quality based on various quality

attributes and quality criteria.

A quality model by Khosravi and Gueheneuc (2005) consist two tasks

viz. selection of a super-characteristic and selection and organization of factors related to

super-characteristic. This quality model is constructed based on reusability as super-

factors and focuses on reusability, understandability, flexibility, modularity, robustness,

scalability and usability factors. This quality model evaluates software quality related to

software maintenance based on design patterns.

Rawashdeh and Matalkah (2006) also derived a model from ISO/IEC 9126-1

(2001). They added compatibility sub-characteristic under the functionality

characteristic and complexity under usability. They removed stability and analyzability

from maintainability characteristic. This model also fails to perform the evaluation of

quality of system.

In order to evaluate software quality by means of integrating the fuzzy theory

and AHP the guidelines were provided by Chang et al. (2008) and this quality

assessment approach was applied on ISO/IEC 9126-1 (2001) quality model. The

software quality evaluations were based on the same factors and sub-factors of ISO/IEC

9126-1 model.

A component based software development quality model was proposed by

Sharma et al. (2008) which include the factors and sub-factors of ISO/IEC 9126-1

quality model. It also comprises of new other proposed sub-factors like reusability,

flexibility, complexity and trackability in order to evaluate overall quality component.

Khomh et al. (2009) proposed a method DEQUALITE (Design Enhanced

Quality Evaluation) to build a quality model to measure the quality of object-oriented

systems with the help of their internal attributes and their designs and measure system

by analyzing the impact of design patterns, anti-patterns, and code smells on different

software quality factors. There are mainly four main steps involved in this model such as

detection of design patterns, design defects and code smells through the analysis of the

impact of these design styles on quality, empirical studies, building model and validation

of this model.

An Aspect-Oriented Software Quality Model (AOSQUAMO) was proposed by

Kumar et al. (2009) which is basically extension of ISO/IEC 9126-1 (2001) software

quality model. This model has also included four new sub-factors i.e. modularity, code-

reusability, complexity and reusability in addition to original factors and sub-factors of

ISO/IEC 9126-1 quality model. This model was unable to explain the metrics related to

the aspect-oriented.

A UML conceptual model REASQ (Requirements, Aspects and Software

Quality) was developed (Castillo et al., 2010) to clarify the AOSD (Aspect-Oriented

Software Development) terminology i.e. aspect, composition, concern, quality or

property requirements for the software product. Comparing REASQ model, ISO/IEC

9126-1 is used to relate the requirement engineering terminology with the aspect-

orientation and software quality. This model provides an initial view of the concerns that

will be meaningful for the system.

5.4 PROPOSED OBJECT ORIENTED QUALITY MODEL

In the context of section 5.3, we observed that there is lacking of true object-

oriented quality model. So, we proposed a Model for Object-Oriented Software QUAlity

which is an extension of ISO/IEC 9126-1 (2001) model. In this model we have added

sub-factors reusability under functionality characteristic, cost under efficiency, code

readability and modularity under maintainability, and safety under usability factors in

the ISO/IEC 9126-1 model. These additions are based on the extensive survey proposed

in literature by Dubey and Rana (2010b). The Table 5.6 represents the proposed model

for object-oriented software quality.

Table 5.6: Proposed Object Oriented Quality Model

Quality Type Factors Sub-Factors

Software Product

Quality

Functionality

Suitability

Accuracy

Interoperability

Security

Compliance

Reusability

Reliability

Maturity

Fault Tolerance

Recoverability

Usability

Understandability

Learnability

Operability

Attractiveness

Safety

Efficiency

Time Behaviour

Resource Behaviour

Cost

Maintainability

Analyzability

Changeability

Testability

Stability

Modularity

Code Readability

Portability

Replace-ability

Adaptability

Install-ability

Co-Existence

5.4.1 Definition of Existing Sub-factors

The following sub-sections provide the description about the factors that are

already exist in the ISO/IEC 9126-1 quality model.

5.4.1.1 Functionality: A set of attributes that relate to the existence of a set of functions

and their specified properties. It means that when the software is used under specified

conditions then classes and objects should provide functions which meet stated and

implied needs. Existing functionality of classes can be used by inheritance. It will reduce

the expenses and provide faster implementation of software system. It contains the

following sub-factors:

i. Suitability: Suitability describes how well the object fits into the class. It is the

capability of the software product to provide an appropriate set of functions for

specified tasks and user objectives.

ii. Accuracy: It evaluates whether the object giving accurate results with correct

precision level when used under specific condition.

iii. Security: It refers how the class is able to control the unauthorized access its data

and function.

iv. Interoperability: The ability of class to interact with another class in same or

different modules.

v. Compliance: This sub-characteristic describes whether an object-oriented system

is conforming to any international standard or certification etc.

5.4.1.2 Reliability: It is the capability of the class to maintain a specified level of

performance when used under specified conditions. The sub-factors of reliability are:

i. Maturity: This sub-characteristic describes how much work has been done using

a particular class.

ii. Fault tolerance: It indicates whether the object can maintain the specified level of

performance.

iii. Recoverability: It is the capability of object to re-establish its level of

performance and recover the data directly affected in case of a failure.

5.4.1.3 Usability: Usability only exists with regard to functionality and refers to the ease

of use for a given module. It is the capability of the object-oriented system to be

understood and learned by the user, when used under specified conditions. It contains

the following sub-factors:

i. Understandability: It determines the ease of which the class functions can be

understood.

ii. Learnability: It is the capability of the object-oriented system to enable the user

to learn its application.

iii. It is the ability of the object-oriented system to enable the user to easily operate

it.

iv. Attractiveness: It indicates the capability of the object-oriented system to be

attractive to the user.

5.4.1.4 Efficiency: This characteristic is concerned with the resources used by the

object-oriented system when providing the required functionality. Class can be

internally optimized to improve the performance. The sub-factors of efficiency are::

i. Time Behaviour: It indicates the ability to perform a specific task by a class at

the correct time.

ii. Resource Behaviour: It is the capability of the object-oriented system to use

appropriate amounts and types of resources when the software performs its

function under stated conditions.

5.4.1.5 Maintainability: It is the capability of the class to be modified. Modifications

may include corrections, improvements or adaptation of the object-oriented system. It

contains the following sub-factors:

i. Analyzability: It refers to the ability of object-oriented system to diagnose for

deficiencies or causes of failures in the software, or for the parts to be modified

to be identified.

ii. Changeability: It is the capability of the class to enable a specified modification

to be implemented.

iii. Stability: It refers to the class ability to handle the non-required changes during

modification.

iv. Testability: It refers whether the class is valid after modification by providing

some test cases.

5.4.1.6 Portability: The capability of the object-oriented system to be portable into new

environments. It includes the following sub factors:

i. Adaptability: It refers whether the object-oriented system can be adapted to

newly environments.

ii. Installability: It is the capability of the object-oriented system to be installed in a

specified environment.

iii. Co-existence: It is the capability of the object-oriented system to co-exist with

other independent software in a common environment sharing common

resources.

iv. Replaceability: This sub characteristic indicates whether the object-oriented

system is replaceable with its previous versions.

5.4.2 Definition of Proposed Sub-Factors

The following sections define the sub-factors added in the proposed model in the

context of object oriented scenario.

5.4.2.1 Code-Readability: It refers to the degree to which a reader can quickly and

easily understand source code. This concept is important because the source code is

going to read repeatedly during its creation, testing, debugging and maintenance. In

object-oriented systems, polymorphism affects the code readability as the same message

can be used to call the different objects. Readability is also affected by the quality

program documentation as it increase the maintenance cost for non-well documentation.

Readability can be measured by the average number of questions or queries get solved

about the program in a particular time period.

5.4.2.2 Modularity: It is a concept of object-oriented paradigm for decomposing a large

software program into smaller modules. It makes the program easier to understand and

debug. Modularity is beneficial in the way that modules can be easily combined to

another system. Different modules show interdependency with each other using the

coupling and the functional strength of module is represented by cohesion. In well OO

systems, the property of low coupling and high cohesion should be exhibited by the

module.

5.4.2.3 Reusability: This gives an idea of how the software can be reusable. Object-

oriented software systems have two types of reusability, functional reusability and code

reusability. Functional reusability on object-oriented approach is similar as in case of

module-oriented approach. The inheritance property represents code reusability in

object-oriented approach. Class inheritance permits a class to reuse it by making

subclass from it.

5.4.2.4 Cost: Cost refers to different types of expenses. The cost of the equipments, the

cost of system itself etc may be include in this category. Software development cost

should be lower for better software system.

5.4.2.5 Safety: Safety is defined as the capacity to avoid any kind of damage and risk

derived when the system is in use. User safety is very essential today in terms of

confidentiality. The software should be totally free of bugs, employing redundancy or

conducting extensive testing for operational safety.

5.5 EVALUATION OF PROPOSED QUALITY MODEL

In order to evaluate the quality of proposed Model for Object-Oriented Software

Quality, AHP technique is used. The detail about AHP technique is already discussed in

Chapter 3.

5.5.1 Allocating the Weights to Factors and Sub-Factors

The survey conducted on 33 professionals to assign weights to factors and sub-

factors of the proposed model. Survey form consists of all factors and sub factors of

proposed model. Professionals were requested to give their preferences to all factors and

sub-factors according to the rating scale given in survey form. The survey form consist

of seven tables in which first table for filling the pair-wise relative weight values of six

factors i.e. Functionality (F), Reliability (R), Usability (U), Efficiency (E),

Maintainability (M), and Portability (P). Similarly, in the survey form, remaining six

tables are for filling the relative weight of the sub-factors of F, R, U, E, M and P.

5.5.1.1 Weights of Factors

In order to determine eigenvector and eigen values of all the six factors,

multiplying together the entries in each row of the matrix and then taking the nth

root (in

our case 6th

root) of that product. The values are given in Table-5.7.

Table 5.7: Eigen Vectors and Eigen Values of Quality Factors

Fu

nct

inali

ty (

F)

Rel

iab

ilit

y (

R)

Usa

bil

ity (U

)

Eff

icie

ncy

(E

)

Main

tain

ab

ilit

y (

M)

Port

ab

ilit

y (

P)

nth

(6

th)

root

of

pro

du

ct v

alu

es

Eig

envec

tor

(ω)

A.ω

λm

ax

λm

ax

F 1 0.444 0.545 0.48 0.75 2.833 0.792 0.121 0.7632 6.312

R 2.25 1 0.631 0.666 0.666 2.416 1.072 0.164 1.0142 6.191

U 1.833 1.583 1 1.41 0.8 3.08 1.469 0.225 1.360 6.063

E 2.083 1.5 0.709 1 0.6 2.911 1.253 0.192 1.176 6.140

M 1.333 1.5 1.25 1.666 1 3.333 1.550 0.236 1.5429 6.518

P 0.352 0.413 0.324 0.342 0.3 1 0.411 0.062 0.382 6.082

Total 6.547 1.000

The nth

root is summed and that sum is used to normalize the eigenvector

elements to get the sum as 1.000. In the matrix of Table 5.7, the 6th

root for the first row

is 0.792 and that is divided by 6.547 to give 0.121 as the first element in the eigenvector.

The eigenvector of the relative importance of F, R, U, E, M and P is 0.1209,

0.164, 0.225, 0.192, 0.2367, 0.0628 respectively, which is given in Table-5.7.

Eigen values λmax can be evaluated by applying λmax = (A.ω / ω), where A is the

matrix filled by the values of F, R, U, E, M and P. These six λmax values are calculated as

6.312, 6.191, 6.063, 6.140, 6.518 and 6.082. All these values of λmax are greater than 6,

as this matrix is of order of 6, so it satisfies the condition of λmax ≥ n. The mean of λmax

values i.e. λmean = 6.217 ( sum of all λmax / n). So,

C. I. = (λmean - n) / ( n - 1) = (6.217-6) / (6-1) = 0.043 (5.3)

The final step is to calculate the consistency ratio (C. R.) for the set of judgments

using the C. I. for the corresponding value from samples of matrices of purely random

judgments. The value of R. I. is taken from Saaty’s standard Table.

By using equation (5.2), i.e. C. R. = C.I. / R. I. (Here, from Saaty’s standard

Table, R.I. = 1.24). So,

C.R. = 0.043 / 1.24 = 0.0346. (5.4)

We found the calculated value of C. R. < 0.1 in all the samples of matrices,

which indicates that the estimate is acceptable.

5.5.1.2 Weights of Sub-Factors

(a) Functionality

The eigenvector (ω) of Accuracy, Compliance, Suitability, Interoperability,

Reusability and Security is 0.108, 0.116, 0.141, 0.216, 0.158 and 0.258 respectively.

By applying the formula of eigenvalue λmax= (A.ω/ ω), values of λmax are

calculated as 6.33, 6.46, 6.04, 6.16, 6.2 and 6.43. As this matrix is of order of 6,

therefore the mean value should satisfy the condition of λmax ≥ n. The mean of λmax

values is 6.27. So,

C. I. = (λmean - n) / ( n - 1) = (6.27-6)/(6-1) = 0.054 (5.5)

The final step is to calculate the Consistency Ratio (C. R.) for the set of

judgments using the C. I. for the corresponding value from samples of matrices of

purely random judgments. The value of R. I. (1.24) is taken from Saaty’s standard

Table. For this matrix (by using equation 5.2):

C. R. = 0.054 / 1.24 = 0.0435. (5.6)

We found the calculated value of C. R. < 0.1, which indicates that the estimate is

acceptable. The values are given in Table 5.8.

Table 5.8: Eigen Vectors and Eigen Values of Functionality Sub-Factors

(b) Reliability

Acc

ura

cy

(A)

Com

pli

an

ce

(Co)

Su

itab

ilit

y (S

u)

Inte

rop

erab

ilit

y

(I)

Reu

sab

ilit

y

(Re)

Sec

uri

ty (

S)

C6

Eig

envec

tor

(ω)

A. ω

λm

ax

A

1 0.545 0.521 0.480 1.583 0.387 0.108 0.697 6.33

Co

1.833 1 0.666 0.545 0.480 0.444 0.116 0.711 6.46

Su 1.916 1.5 1 0.6 0.631 0.4 0.141 0.846 6.04

I 2.083 1.833 1.666 1 1.416 0.750 0.216 1.295 6.16

Re

0.631 2.083 1.583 0.705 1 0.631 0.158 0.992 6.2

S 2.583 2.25 2.5 1.333 1.583 1 0.258 1.674 6.43

Total 0.997

The eigenvector (ω) of Maturity Fault Tolerance and Recoverability is 0.141,

0.490 and 0.368 respectively.


calculated as 3.397, 2.844 and 2.875. As this matrix is of order of 3, therefore the mean

value should satisfy the condition of λmax ≥ n. The mean of λmax values is 3.0386. So,

C. I. = (λmean - n) / ( n - 1) = (3.0386-3)/(3-1) = 0.019 (5.7)





C. R. = 0.019/0.58 = 0.0327 (5.8)



Table 5.9: Eigen Vectors and Eigen Values of Reliability Sub-Factors

Matu

rity

(Ma)

Fau

lt T

ole

ran

ce

(Ft)

Rec

overa

bil

ity

(Rc)

Eig

envec

tor

(ω)

A. ω

λm

ax

Ma

1 0.4 0.387 0.141 0.479 3.397

Ft 2.5 1 1.5 0.490 1.394 2.844

Rc 2.583 0.666 1 0.368 1.058 2.875

Total 0.999

(c) Usability

The eigenvector (ω) of Understandability, Learnabiity, Operability, Safety and

Attractiveness is 0.325, 0.245, 0.174, 0.098 and 0.156 respectively.

By applying the formula of eigenvalue λmax= (A.ω / ω), values of λmax are

calculated as 5.153, 5.212, 4.908, 5.357 and 4.583. As this matrix is of order of 5,

therefore the mean value should satisfy the condition of λmax ≥ n. The mean value of λmax

is 5.042. So,

C. I. = (λmean - n) / ( n - 1) = (5.042-5)/(5-1)=0.0105 (5.9)





C. R. = 0.0105/1.12 = 0.0093. (5.10)

We found the calculated value of C. R.<0.1, which indicates that the estimate is


Table 5.10: Eigen Vectors and Eigen Values of Usability Sub-Factors

Un

der

stan

dab

ilit

y

(Un

)

Lea

rnab

iity

(L

b)

Op

erab

ilit

y (

Op

)

Safe

ty (

Sa)

Att

ract

iven

ess

(Att

)

Eig

envec

tor

(ω)

A. ω

λm

ax

Un 1 1.416 1.916 2.333 2.833 0.325 1.675 5.153

Lb 0.706 1 1.333 1.583 2.666 0.245 1.277 5.212

Op 0.521 0.75 1 1.083 1.416 0.174 0.854 4.908

Sa 0.428 0.631 0.923 1 1.75 0.098 0.525 5.357

Att 0.352 0.375 1.706 0.571 1 0.156 0.715 4.583

Total 0.998

(d) Efficiency

The eigenvector (ω) of Time Behaviour, Resource Behaviour and Cost is 0.204,

0.502 and 0.293 respectively.


calculated as 3.093, 3.017 and 2.938. As this matrix is of order of 3, therefore the mean

value should satisfy the condition of λmax ≥ n. The mean of λmax values is 3.016. So,

C. I. = (λmean - n) / ( n - 1) = (3.016-3)/(3-1)=0.008 (5.11)





C. R. = 0.008/0.58 = 0.0137 (5.12)



Table 5.11: Eigen Vectors and Eigen Values of Efficiency Sub-Factors

Tim

e B

ehavio

ur

(Tb

)

Res

ou

rce

Beh

avio

ur

(Rb

)

Cost

(C

t)

Eig

envec

tor

(ω)

A. ω

λm

ax

Tb 1 0.461 0.667 0.204 0.631 3.093

Rb 2.166 1 1.916 0.502 1.515 3.017

Ct 1.5 0.521 1 0.293 0.861 2.938

Total 0.999

(e) Maintainability

The eigenvector (ω) of Analyzability, Changeability, Stability, Testability,

Modularity and Code Readability is 0.122, 0.283, 0.076, 0.224, 0.186 and 0.105

respectively.


calculated as 6.131, 5.904, 6.302, 6.120, 6.037 and 5.847. As this matrix is of order of 6,

therefore the mean value should satisfy the condition of λmax ≥ n. The mean of λmax

values is 6.056. Now we can evaluate C. I. as:

C. I. = (λmean - n) / ( n - 1) = (6.056-6)/(6-1) = 0.0112 (5.13)




Table.For this matrix (by using equation 5.2):

C. R. = 0.0112/1.24 = 0.009 (5.14)

We found the calculated value of C. R.<0.1, which indicates that the estimate is


Table 5.12 : Eigen Vectors and Eigen Values of Maintainability Sub-Factors

An

aly

zab

ilit

y

(An

)

Ch

an

gea

bil

ity

(Ch

)

Sta

bil

ity (

St)

Tes

tab

ilit

y (

Te)

Mod

ula

rity

(M

o)

Cod

e R

ead

ab

ilit

y

(Cr)

C6

Eig

envec

tor

(ω)

A. ω

λm

ax

An 1 0.375 1.916 0.444 0.751 1.291 0.122 0.748 6.131

Ch 2.666 1 2.833 1.583 1.333 2.333 0.283 1.671 5.904

St 0.521 0.352 1 0.387 0.4 0.751 0.076 0.479 6.302

Te 2.25 0.631 2.583 1 1.458 2.166 0.224 1.371 6.120

Mo 1.333 0.75 2.5 0.685 1 2.083 0.186 1.123 6.037

Cr 0.774 0.428 1.333 0.461 0.480 1 0.105 0.614 5.847

Total 0.996

(f) Portability

The eigenvector (ω) of Adaptability, Installability, Replaceability and

Conformance is 0.129, 0.306, 0.419 and 0.145 respectively.


calculated as 3.992, 3.937, 4.031 and 4.137. As this matrix is of order of 4, therefore the

mean value should satisfy the condition of λmax ≥ n. The mean of λmax values is 4.024.

Now we can evaluate C. I. as

C. I. = (λmean - n) / ( n - 1) = (4.024-4)/(4-1) = 0.008 (5.15)




Table.For this matrix (by using equation 5.2):

C. R. = 0.008/0.90 = 0.0089. (5.16)



Table 5.13: Eigen Vectors and Eigen Values of Portability Sub-Factors

Ad

ap

tab

ilit

y

(Ad

)

Inst

all

ab

ilit

y

(In

)

Rep

lace

ab

ilit

y

(Rp

)

Con

form

an

ce

(Coe)

Eig

envec

tor

(ω)

A. ω

λm

ax

Ad 1 0.387 0.363 0.8 0.129 0.515 3.992

In 2.583 1 0.631 2.083 0.306 1.205 3.937

Rp 2.75 1.416 1 2.833 0.419 1.689 4.031

Coe 1.25 0.48 0.352 1 0.145 0.600 4.137

Total 0.999

Similarly, we have applied AHP process on pair-wise relative weights of sub-

factors of factors F, R, U, E, M and P one by one and all these weights of sub-factors are

listed in column of Table-5.14. Twenty five sub-factors are weighted as follows:

Suitability (0.017), Accuracy (0.013), Interoperability (0.026), Compliance

(0.014), Security (0.031), Reusability (0.019), Maturity (0.024), Fault-tolerance (0.080),

Recoverability (0.060), Attractiveness (0.035), Understandability (0.073), Learnability

(0.056), Operability (0.039), Safety (0.022), Time behavior (0.039), Resource behavior

(0.097), Cost (0.056), Analyzability (0.029), Changeability (0.067), Stability (0.018),

Testability (0.054), Code Readability (0.025), Modularity (0.044), Adaptability (0.008),

Install-ability (0.019), Replace-ability (0.026), and Coexistence (0.009).

Table 5.14: Weight Values for Sub-Factors

Characteristic Sub-

Characteristic

Eigen vectors Weight

Values

Sum

F

Suitability 0.141 0.017

0.120

Accuracy 0.108 0.013

Interoperability 0.216 0.026

Security 0.258 0.031

Compliance 0.116 0.014

Reusability 0.158 0.019

R

Maturity 0.141 0.024

0.164 Fault Tolerance 0.490 0.080

Recoverability 0.368 0.060

E

Time Behavior 0.204 0.039

0.192 Resource

Behviour

0.502 0.097

Cost 0.293 0.056

U

Understandability 0.325 0.073

0.225 Learnability 0.245 0.056

Operability 0.174 0.039

Attractiveness 0.156 0.035

Safety 0.098 0.022

M

Stability 0.076 0.018

0.237

Testability 0.224 0.054

Changeabiliy 0.283 0.067

Analyzability 0.122 0.029

Code Readability 0.105 0.025

Modularity 0.186 0.044

P

Adaptability 0.129 0.008

0.062 Installability 0.306 0.019

Replaceability 0.419 0.026

Co-existence 0.145 0.009

Total 1.000

Each sub-characteristic not has equal importance. So to restrict not to over

design the system, we take only selected factors and sub factors. According to the

weight values of factors in Table 5.14, we selected total 12 sub-factors i.e.

Interoperability, Security, Reusability and Suitability under Functionality characteristic,

Fault Tolerance under Reliability characteristic, Resource Behaviour and Cost under

Efficiency characteristic, Understandability and Learnability under Usability

characteristic and Testability, Changeability and Modularity under Maintainability

characteristic. In this case, we need to normalize the weight values of selected factors

and sub factors to make sum of all weight values equal to 1. The normalized values

obtained in scale of 0 – 1 are mentioned in Table 5.15.

Table 5.15: Normalized values of Quality Sub-Factors

Factors Sub-characteristic Weight

Values

Sum

F

Suitability 0.030

0.145 Interoperability 0.034

Security 0.046

Reusability 0.035

R Fault Tolerance 0.167 0.167

E Resource Behaviour 0.132 0.212

Cost 0.081

U Understandability 0.139 0.235

Learnability 0.096

M

Modularity 0.061

0.241 Testability 0.078

Changeabiliy 0.102

Total 1.000

To evaluate the quality of a software system as a whole, we need to measure all the

selected factors and sub-factors. The formula used to evaluate the whole quality of

software system is:

Quality = WF + WR + WU + WE + WM + WP (5.17)

Where WF, WR, WU, WE, WM and WP are weight values for Functionality (F), Reliability

(R), Usability (U), Efficiency (E), Maintainability (M) and Portability (P) respectively.

The weight values of all the factors are mentioned in Table 5.14. Further, we need to

evaluate the factors F, R, U, E, M and P. The formulas used to evaluate all the quality

factors of software system

WF = WSu + WA + WI + WS + WCo + WRe (5.18)

WR = WMa + WFt + WRc (5.19)

WU = WUn + WLb + WOp + WAtt + WSa (5.20)

WE = WTb + WRb + WCt (5.21)

WM = WSt + WTe + WCh + WAn + WCr + WMo (5.22)

WP = WAd + WIn + WRp + WCoe (5.23)

Where WSu, WA, WI, WS, WCo, WRe, WMa, WFt, WRc, WUn, WLb, WOp, WAtt,WSa,

WTb,WRb, WCt, WSt, WTe, WCh, WAn, WCr, WMo, WAd, WIn, WRp, WCoe are weight values

for Suitability, Accuracy, Interoperability, Security, Compliance, Reusability, Maturity,

Fault-tolerance, Recoverability, Understandability, Learnability, Operability,

Attractiveness, Safety, Time behavior, Resource behavior, Cost, Stability, Testability,

Changeability, Analyzability, Code Readability, Modularity, Adaptability, Install-

ability, Replace-ability, and Co-existence.

Now, to measure the sub-factors, we mentioned the set of metrics in Table 5.16

5.5.2 Experimental Evaluation

We have taken two Object Oriented projects developed in C++ by M.Tech students and

evaluated the quality of these projects on the basis of proposed quality model by using

metrics shown in Table 5.16.

As these projects are based on C++, there is no platform independency.

Therefore, there is no need to select portability characteristic and its sub factors. For

Fault Tolerance, we assume that if in any software system, there are very high, high,

average, less, and no failure operations within a specified time then we can measure it

by giving values 0, 0.25, 0.5, 0.75 and 1. For cost, we assume different types of

expenses, namely, human-resource costs, the equipment costs and consumables costs.

We can measure it by giving values 0, 0.25, 0.5, 0.75 and 1 for very high cost, high cost,

average cost, low cost and no cost. Understandability can be measured on the basis of

documentation, training and help provided to the user by giving values 0.33 each.

Table 5.16: Metrics for Evaluation

Sub factors Metric

Security Number of access controllability provided/ total number of access

controllability required.

Interoperability Degree of communication between system and stakeholders.

Reusability Number of reusable properties/total number of properties

Suitability Suitable operations/ total number of operations

Fault Tolerance Operational profile of the software and number of faults in the

software evaluated.

Resource

Behaviour

How much resources required to run the software i.e. % CPU usage

for the execution of method.

Cost How much expensive to buy the software

Understandability User documentation, training provided and help system

Learnability Number of achievable tasks/ total number of tasks

Testability Number of test cases provided for a system

Changeability Number of properties can be customized/ total number of

properties

Modularity Combine measurement of coupling between objects (CBO) and

lack of cohesion in methods (LCOM).

Interoperability can measure by rating it between 0 and 1 depend on the

communicative effectiveness between system and stakeholders. Testability can measure

by giving values 0, 0.5 and 1 for no test cases provided, not adequate test cases provided

and adequate test cases provided. Modularity can be evaluated as combine measurement

of coupling between objects (CBO) and Lack of Cohesion in Methods (LCOM).

Coupling measures the degree of interdependency between modules and cohesion

represents the functional strength of module. For better system, coupling should be low

and cohesion should be high. We can rate it between 0 and 1 depend on the degree of

coupling and cohesion. The resultant evaluated values of both the projects are shown in

Table 5.17 and Table-5.18.The evaluated value of software quality of project 1 is 0.556

and quality of project2 is 0.625. The result shows that the quality of project2 is better

than the project1.

Table 5.17: Final Quality of Project1

Factors Sub-

characteristic

Metric (M) Weight

(w)

Mi * wi Quality

Functionality

Suitability 5/8 = 0.625 0.030 0.019

0.079 Interoperability 0.25 0.034 0.008

Security 3/5 = 0.6 0.046 0.028

Reusability 7/10 = 0.7 0.035 0.024

Reliability Fault Tolerance 0.50 0.167 0.083 0.083

Efficiency Resource

Behavior

0.60 0.132 0.079 0.079

Cost 0 0.081 0

Usability Understandability 0.66 0.139 0.092 0.169

Learnability 8/10 = 0.8 0.096 0.077

Maintainability

Modularity 0.75 0.061 0.046

0.146 Testability 0.5 0.078 0.039

Changeabiliy 6/10 = 0.60 0.102 0.061

Total 0.556

Table 5.18: Final Quality of Project2

Factors Sub-

characteristic

Metric (M) Weight

(w)

Mi* wi Quality

Functionality

Suitability 8/9 = 0.89 0.030 0.027

0.105 Interoperability 0.50 0.034 0.017

Security 5/6 = 0.83 0.046 0.038

Reusability 8/12 = 0.67 0.035 0.023

Reliability Fault Tolerance 0.75 0.167 0.125 0.125

Efficiency Resource

Behavior

0.80 0.132 0.106 0.106

Cost 0 0.081 0

Usability Understandability 0.66 0.139 0.092 0.148

Learnability 7/12 = 0.58 0.096 0.056

Maintainability

Modularity 0.70 0.061 0.043

0.141 Testability 0.5 0.078 0.039

Changeabiliy 7/12 = 0.58 0.102 0.059

Total 0.625

So, we can say that proposed model is an improved version of ISO-9126 quality model,

which takes consideration of important characteristics like code readability, modularity,

reusability, cost and safety. The proposed model is suitable to evaluate the quality of

object-oriented system. Advantage of using proposed model is that when two projects on

the basis of the exixting model has similar quality then the proposed model has the

ability to further check the quality of those projects based on extra added characteristics

and then rank the quality of projects according to that.

Following table shows the comparison between ISO 9126 and proposed quality

model.

Table 5.19 Comparison between ISO 9126 and Proposed Quality Model

ISO 9126 Quality Model Proposed Model

1. Does not provide the guidance on

how to weigh or collate metrics

criteria in order to reflect their

importance concerning quality

factors

Consider the relative importance of sub-

factors by employing AHP. This approach the

level of model’s entities and relationship with

more accuracy. These empirical weight values

will help developers to select only those

characteristics which are as per their

requirement in that domain.

2. Fixed sub-factors in hierarchy Incorporated new sub-factors in hierarchy

levels

3. General Model Covers some important object-oriented

aspects

4. Difficult to be made operational as

it doesn’t provide guidance or

heuristics on trading off metrics

Can be made operational after refinement by

taking consideration of larger and broader

sample for better understand the underlying

dimensional structure

5.6 CONCLUSION

This paper proposed a quality model and evaluated the quality of this model by using

Analytical Hierarchy Process (AHP) technique. ISO/IEC 9126-1 was considered as a

base model. New sub factors were added to this proposed model. Pair-wise relative

weight values are assigned to the factors and sub-factors by using AHP technique. To

obtain the quality of object-oriented software system, we used the above evaluation

process on two C++ projects. The result was in the terms of quality as a single score for

each of the projects. In future we will apply this model on real life object-oriented

software system to gain more perspective view about the pros and cons of this model.

Documents

CHAPTER 5shodhganga.inflibnet.ac.in/bitstream/10603/23847/6/chapter 5.pdf · model is evaluating the quality of the product when each software product has different quality than the