JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.

ORG

97

A Model for Object Oriented Software Quality (MOOSQUA)

Sanjay Kumar Dubey, Abhishek Jain, and Prof. (Dr.) Ajay Rana
Abstract Object oriented approach is the underlying principle in the current scenario for a quality software development. Object oriented technology present the real domain picture of the software system and helps in aggregation of discrete objects. Incorporating object oriented methodology improves the quality of the software system. Hence, quality evaluation of software system is necessary before its implementation. In order to evaluate quality of software system various models have been proposed by researchers and practitioners. This paper surveys various quality models and found that there is no dedicated model for object oriented system. Therefore, present paper proposes a Model for Object Oriented Software QUAlity (MOOSQUA). Analytical Hierarchy Process ( AHP) technique is used to evaluate the quality of proposed model in a single score. This proposed model may be beneficial in the terms of selection of better quality software system. Index TermsObject Oriented, Quality, Model, Analytical Hierarchy Process.

1 INTRODUCTION
bjectorientedsoftwaredevelopmentisanemerging wayofthinkingaboutsoftwarebasedonabstraction of objects that exist in the real world domain. The various concepts like Usability, Reusability, Testability, Understandability, Complexity, Productivity, Reliability, ExtensibilityMaintainabilityandFlexibilityetc.arecorre latedwithobjectorientedfeaturesthatenhancethequali ty of software system. This is gaining a lot of attention from the software development community as it reduces thesizeofsystemandlogicalconstructs.ObjectOriented (OO) approach promotes better designing software de velopment environment and views software system as a setofinteractiveobjects. Inspite of wide applicability of OO design in software developmentenvironment,feweffortshavebeenmadein thecontextofjudgingthequalityofOOsoftwaresystem aswellasproposalofOOqualitymodel.Softwarequality is considered as a very important aspect for developers, usersandprojectmanagers.Itisafieldofstudyandprac tice that describes the desirable attributes of software products. If a product is meeting user requirements, a feelingofsatisfactionmayemergeandthissatisfactionis nothingbutthesatisfactionforquality. This paper proposes a new Model for Object Oriented Software QUAlity (MOOSQUA) derived from ISO/IEC 9126I [17] and uses Analytical Hierarchy Process (AHP) technique to evaluate the proposed quality model. This techniqueisbeneficialasitprovidesastructuredaswell assimplesolutionfordecisionmakingproblemsandhas beenextensivelyadoptedinmulticriteriadecisionmak

ing and successfully applied to many practical decision makingproblems[40].

2 SOFTWARE QUALITY
Software quality is the extent to which an industry defined set of desirable features are incorporated into a product so as to enhance its lifetime performance [33]. Softwarequalityisdefinedasconfirmingwithexplicitly statedfunctionalandperformancerequirements,explicit lydocumenteddevelopmentstandardsandimplicitchar acteristicsthatareexpectedofallprofessionaldeveloped software [38]. Schulmeyer and McManus [12] defined software quality as all functions and characteristics of a software product that satisfy consumer needs. Software quality in business context refers to two related but dis tinct notion i.e. software functional quality and software structuralquality[37].DeutschandWills[29]categorized software quality as software procedure quality (tools, technology, equipment, personnel and organization) and softwareproductquality(organization,documentclarity, design traceability, integrity, test integrity and program reliability). Theevaluationofsoftwaresystemqualitydependsupon variousfactorslikequalitymodelandqualitycharacteris tics.Aqualitymodelisusuallydefinedasastructuredset of properties that are needed for an object of a class to meetdefinedpurposes[30].Itisalsodefinedasasetof characteristics and relationships between them which actuallyprovidethebasisforspecifyingtherequirements ofqualityandevaluatingquality[19].Thebenefitofqual ity model is given by decomposition of valuable object likeprocess,productororganizationinthelistofitschar acteristics/subcharacteristics measures. It is applicable

Sanjay Kumar Dubey is with Amity University, Noida, India, 201303. Abhishek Jain is with Amity University, Noida, India, 201303. Prof. (Dr.) Ajay Rana is with Amity University, Noida, India, 201303.

2012 Journal of Computing Press, NY, USA, ISSN 2151-9617 http://sites.google.com/site/journalofcomputing/

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

98

forpredicting,assuringandverifyingtheachievementof adefinedgoal.Quality,apartfromdescribingand meas uringthefunctionalaspectsofsoftwarealsodescribes theextrafunctionalpropertiessuchashowsystemisbuilt andhowitperforms.Therearenumberofqualitymodels proposed in software engineering literature, each one of thesequalitymodelsconsistsofseveralqualitycharacter istics(orfactors,ascalledinsome models).Thesequality characteristics could be used to reflect the quality of the softwareproduct.Thevariousqualitymodelsaredefined infollowingsubsections:

TABLE 1 RELATIONSHIP BETWEEN MCCALL QUALITY CHARACTERISTICS AND METRICS Software Quality Metric Quality Factors Auditability Accuracy Communi cation commonali ty Complete ness Conciseness Consistency Data com monality Error toler ance Execution efficiency Expandabil ity Generality Hardware independ ence Instrumen tation Modularity Operability Security Self docu mentation Simplicity Software system in dependence Traceability Training requirements. Correctness Reliability Efficiency Integrity Maintainability Flexibility Testability Portability Reusability Interoperability Usability X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

2.1 McCall Model

Thefirstandwellknownqualitymodelwasproposedby J.A.McCall[22].Theproposalofthemodelwasbasically meant to design a complete layout the products quality through its various characteristics. The model developed mainly for system developers and system development process. In this model, the quality of software has been categorizedinthreedifferentpartsnamelyProductRevi sion (Maintainability, Flexibility and Testability), Product Operation (Correctness, Reliability, Efficiency, Integrity andUsability)andProductTransition(Portability,Reusa bilityandInteroperability).RelationshipbetweenMcCall quality characteristics and metrics are shown in Table 1. Thismodelwasunabletoincludethefunctionalityaspect ofsoftwaresystem.

2.2 Bohems Model

B.W.Boehm[6]hasdevelopedaqualitymodelsimilarto theMcCallmodel.BoththemodelspresentedbyMcCall and Boehm are hierarchical quality models structured aroundhigh,intermediateandprimitivelevelcharacteris tics. These various level characteristics added to overall qualitylevel.Thesetwomodelsseemtobesimilarbutthe basicdifferenceisthatMcCallmodelfocusesonhighlev el characteristics where as Boehms quality model pre sents the characteristics of software on a larger scale as comparetoMcCallsmodel.InBoehmsmodel,thequali tycharacteristicAsIsUtilitydescribeshoweasily,relia bly and efficiently software product can be used, Main tainability describes how easily modified and retest the software product, Portability describes how the software product can be used even when environment has been changed.Thismodeldoesntprovideguidelinestomeas ureproposedfactors.

2.3 FURPS Model

FURPSmodel[32]proposedbyGradyandHewlettPack ard Co. categorized characteristics into two different re quirementssuchasFunctionalRequirements(F)whichis definedbyexpectedinput&outputandNonFunctional Requirements where U stands for Usability, R stands for Reliability, P stands for Performance and S stands for Supportability.ThismodelisfurtherextendedbyIBM Rational Software [14, 15] into FURPS+, where the + in dicates requirements as design constraints, implementa tionrequirements,interfacerequirementsandphysical

2.4 Dromeys Model

G. R. Dromey [10] quality model is based on evaluation criteria.Theaimofthismodelisevaluatingthequalityof the product when each software product has different qualitythantheother.Dromeydescribedthatamoredy namic range of evaluation techniques are required to be appliedtocoverawiderrangeofsoftwaresystems.This model is designed on the relationship between quality characteristics and subcharacteristics between software propertiesandsoftwarequalitycharacteristics.Thismod elisunabletohelpusersqualitydemandatthebegin

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

99

9126I model. This model fails to perform evaluation of qualityofsystem. 2.5 ISO/IEC-9126 Model J. Bansiya et al. [24] proposed a hierarchical Quality ISO/IEC 9126I [17] comprises six characteristics and Model for ObjectOriented Design (QMOOD) which ex twenty seven subcharacteristics of software product tendsDromeysqualitymodelmethodologyandinvolves quality.Thisqualitymodelhastwomainpartsconsisting fourlevelsasidentifyingdesignqualityattributes,identi ofInternalandExternalQualityCharacteristicsandQual fying objectoriented design properties, identifying ob ityinUseCharacteristics.TheInternalqualitycharacteris jectoriented design metrics and identifying object tics refers to the properties of the system that can be orienteddesignproperties evaluated without executing it while External quality The quality model by R. Kazman et al. [34] divided the characteristicsreferstothesystempropertiesthatmaybe qualitycharacteristicsintotwoobservablegroupsduring evaluated by observing the system during its execution. the time of performance and show during the Software The quality in use characteristics refers to the properties existence cycle. The two groups have suggested qualita ofthesystemthatareexperiencedbytheusersofthesys tivecharacteristicsinthefollowingorder: tem when the system is in operable condition and also (i)Efficiency,Security,Availability,Function. (ii) Modifiability, Portability, Reusability, Inheritability TABLE 2 ISO/IEC-9126-I MODEL andTestability. AqualitymodelbyK.Khosravietal.[26]processconsists Quality Characteristics Sub of two tasks viz. selection of a supercharacteristic and Type Characteristics selection and organization of characteristics related to Functionality Suitability super characteristic. This quality model is constructed Accuracy based on Software Reusability as supercharacteristics Interoperability andfocusesonReusability,Understandability,Flexibility, Security Modularity, Robustness, Scalability, and Usability. This Compliance quality model evaluates software quality related to soft Efficiency TimeBehaviour ware maintenance based on design patterns. Design pat Resource ternswereusedtobuildgooddesignorarchitectures. Behaviour A. Rawashdeh et al. [2] also derived a model from Portability Replaceability ISO/IEC 9126I [17]. They added compatibility sub Adaptability characteristic under the Functionality characteristic and Installability Complexity under Usability. They removed Stability and Software CoExistence Analyzability from Maintainability characteristic. This Product Maintainability Analyzability model also fails to perform the evaluation of quality of Quality Changeability system. Testability In order to evaluate software quality by means of inte Stability grating the fuzzy theory and AHP (Analytic Hierarchy Usability Understandabil Process)theguidelineswereprovidedbyC.Changetal. ity [7]andthisqualityassessmentapproachwasappliedon ISO/IEC 9126I [17] quality model. The software quality Learnability evaluations were based on the same characteristics and Operability subcharacteristicsofISO/IEC9126Imodel. Attractiveness Acomponentbasedsoftwaredevelopmentqualitymodel Reliability Maturity was proposed by A. Sharma et al. [4] which include the FaultTolerance characteristics and subcharacteristics of ISO/IEC 9126I Recoverability quality model. It also comprises of new other proposed subcharacteristicslikeReusability,Flexibility,Complexity during its maintenance. The characteristics of this model and Trackability in order to evaluate overall quality are Efficiency, Functionality, Maintainability, Portability, component. ReliabilityandUsability(Table2).But,thismodeldoesnt F.Khomhetal.[9]proposedamethodDEQUALITE(De clearly indicate about measurement of these characteris sign Enhanced Quality Evaluation) to build a quality tics. model to measure the quality of objectoriented systems withthehelpoftheirinternalattributesandtheirdesigns 2.6 Other Quality Models and measure system by analyzing the impact of design Inliterature,mostofresearchersproposedtheirsoftware patterns, antipatterns, andcode smells on different soft quality models. Mostly proposed models have been de ware quality characteristics. There are mainly four main rivedfromISO/IEC9126I[17]. steps involved in this model such as detection of design M. Berota et al. [31] proposed a quality model for COTS patterns, design defects and code smells through the componentsystem.Thecompatibilitysubcharacteristicis analysis of the impact of these design styles on quality, definedundertheFunctionalitycharacteristicsofISO/IEC empiricalstudies,buildingmodelandvalidationofthis ningofsoftwarelifecycle.

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

100

model. An AspectOriented Software Quality Model (AOSQUAMO) was proposed by A. Kumar et al. [5] which is basically extension of ISO/IEC 9126I [17] soft ware quality model. This model has also included four new subcharacteristics i.e. Modularity, Codereusability, Complexity and Reusability in addition to original char acteristicsandsubcharacteristicsofISO/IEC9126Iquali ty model. This model was unable to explain the metrics relatedtotheAO. AUMLconceptualmodelREASQ(Requirements,Aspects and Software Quality) was developed [13] to clarify the AOSD (AspectOriented Software Development) termi nologyi.e.aspect,composition,concern,qualityorprop erty requirements for the software product. Comparing REASQ model, ISO/IEC 9126I (now called ISO/IEC 25010,2007)isusedtorelatetherequirementengineering terminology(thenewstandardISO/IEC25030,2006)with the aspectorientation and software quality. This model providesaninitialviewoftheconcernsthatwillbemean ingfulforthesystem.

TABLE 3 RELATIONSHIP BETWEEN OO DESIGN CONSTRUCTS AND QUALITY CHARACTERISTICS Efficiency Encapsulation Complexity Inheritance Reusability Coupling Under standabilit Testability/ Maintain ability

Cohesion

testeffort,reworkeffort,reusability,andmaintainability. The concept of inheritance helps software developers to incorporate reusability factor in software development process. Since reusability reduces the complexity so it Intodayssoftwaredevelopmentscenario,objectoriented improvesthesoftwarequality[3]Theconceptofencapsu designandmethodsaregainingpopularityexponentially. lation enhances software quality by ensuring safety via Rosenberg et al. [28] described that objectoriented soft informationhiding[25].InspiteofsuchimportanceofOO ware development requires a different approach from conceptsthereisnoqualitymodelisavailablewhichcan moretraditionalfunctionaldecompositionanddataflow fit purely for objectoriented system. From the extensive developmentmethods.Theobjectorientedmetriccriteria survey we found that ISO/IEC 9126I model provides a aretobeusedtoevaluatethefollowingqualityattributes: base for almost all types of quality models proposed for 1) Efficiency: Are the constructs efficiently de different environment. The main characteristics of signed? ISO/IEC9126Imodelviz.functionality,usability,efficien 2) Complexity: Could the constructs be used more cy, reliability, portability and maintainability is available effectivelytodecreasethearchitecturalcomplexi in almost all proposed quality models. The differences amongallthesemodelsareonlytheselection/rejectionof ty? subcharacteristics under above mentioned characteris 3) Understandability: Psychological complexity in tics. creasedbythedesignornot? In the above context this paper proposed Model for Ob 4) Reusability: Possible reuse is supported by the jectOriented Software QUAlity (MOOSQUA) which is designornot? anextensionofISO/IEC9126I[17]model.Inthismodel 5) Testability/Maintainability: Ease of testing and we have added subcharacteristics Reusability under changesaresupportedbythestructureornot? Functionality characteristic, Cost under Efficiency, Code readability and modularity under maintainability, and R. A. Khan [35, 36] observed that SATCs attributes [28] SafetyunderUsabilitycharacteristics.Theseadditionsare representtherelationshipbetweendesignconstructsand based on the extensive survey proposed in literature by quality attributes. This relation is represented in Table 3. [4,39]. Theyconcludedthateachdesignconstructsaffectscertain qualityattributes. 3.1 Definition of Existing Sub-characteristics in L. Briand et al. [27] described that objectoriented (OO) ISO-9126 in Context of Object Orientation technologies (programming languages, tools, methods, 1) Functionality: A set of attributes that relate to and processes) are claimed to improve the quality of theexistenceofasetoffunctionsandtheirspeci software product deliverables, to support reuse and re fied properties. It means that classes and objects duce the effort of developing and maintaining the soft shouldprovidefunctionswhichmeetstatedand wareproduct.Theyalsorelatedimportantcharacteristics implied needs when the software is used under of OO software, such as encapsulation, polymorphism, specified conditions. Existing functionality of inheri ance, coupling and cohesion, to external quality classescanbeusedbyinheritance.Itwillreduce indicatorssuchasfaultproneness,developmenteffort, the expenses and provide faster implementation

3 MODEL FOR OBJECT ORIENTED SOFTWARE QUALITY (MOOSQUA)

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

101

2)

3)

4)

5)

ofsoftwaresystem.Itcontainsthefollowingsub characteristics: Suitability: Suitability describes how well the objectfitsintotheclass.Itisthecapabilityofthe softwareproducttoprovideanappropriatesetof functionsforspecifiedtasksanduserobjectives. Accuracy:Itevaluateswhethertheobjectgiving accurateresultswithcorrectprecisionlevelwhen usedunderspecificcondition. Security:Itrefershowtheclassisabletocontrol theunauthorizedaccessitsdataandfunction. Interoperability: The ability of class to interact withanotherclassinsameordifferentmodules. Compliance: This subcharacteristic describes whether an OO system is conforming to any in ternationalstandardorcertificationetc. Reliability: It is the capability of the class to maintain a specified level of performance when used under specified conditions. It includes the followingsubcharacteristics: Maturity: This subcharacteristic describes how much work has been done using a particular class. Fault tolerance: It indicates whether the object canmaintainthespecifiedlevelofperformance. Recoverability:Itisthecapabilityofobjecttore establishitslevelofperformanceandrecoverthe datadirectlyaffectedincaseofafailure. Usability: Usability only exists with regard to functionality and refers to the ease of use for a given module.ItisthecapabilityoftheOOsys tem to be understood and learned by the user, when used under specified conditions. It con tainsthefollowingsubcharacteristics: Understandability: It determines the ease of whichtheclassfunctionscanbeunderstood. Learnability:ItisthecapabilityoftheOOsystem toenabletheusertolearnitsapplication. Operability:ItistheabilityoftheOOsystemto beeasilyoperatedbyagivenuserinagivenen vironment. Attractiveness: It indicates the capability of the OOsystemtobeattractivetotheuser. Efficiency:Thischaracteristicisconcernedwith the resources used by the OO system when providingtherequiredfunctionality.Classcanbe internally optimized to improve the perfor mance. It includes the following sub characteristics: Time Behaviour: It indicates the ability to per formaspecifictaskbyaclassatthecorrecttime. ResourceBehaviour:ItisthecapabilityoftheOO systemtouseappropriateamountsandtypesof resources when the software performs its func tionunderstatedconditions. Maintainability:Itisthecapabilityoftheclassto be modified. Modifications may include correc tions,improvementsoradaptationoftheOOsys tem.Itcontainsthefollowingsubcharacteristics: Analyzability:ItreferstotheabilityofOOsys

6)

temtodiagnosefordeficienciesorcausesoffail uresinthesoftware,orforthepartstobemodi fiedtobeidentified. Changeability: It is the capability of the class to enable a specified modification to be imple mented. Stability: It refers to the class ability to handle thenonrequiredchangesduringmodification. Testability:Itreferswhethertheclassisvalidaf termodificationbyprovidingsometestcases. Portability: The capability of the OO system to be portable into new environments. It includes thefollowingsubcharacteristics: Adaptability: It refers whether the OO system canbeadaptedtonewlyenvironments. Installability: It is the capability of the OO sys temtobeinstalledinaspecifiedenvironment. Coexistence:ItisthecapabilityoftheOOsystem to coexist with other independent software in a common environment sharing common re sources. Replaceability: This sub characteristic indicates whether the OO system is replaceable with its previousversions.

3.2 Proposed Sub-characteristics Added to MOOSQUA Model

The following sections define the proposed sub characteristics added in MOOSQUA, in context of object oriented scenario. The complete model is shown in Table4. 1) CodeReadability: It refers to the degree to which a reader can quickly and easily under stand source code. In OO systems, polymor phism affects the code readability as the same messagecanbeusedtocallthedifferentobjects. Thisisimportantaseveryprogramisgoingtobe readagainandagainduringitscreation,testing, debugging and maintenance. Readability is also affected by the quality program documentation as it increase the maintenance cost for unwell documentation. Readability can be measured by the average number of questions or queries get solvedabouttheprograminaparticulartimepe riod. 2) Modularity: It is a concept of OO paradigm for decomposing a large software program into smallermodules.Itmakestheprogrameasierto understand and debug. Another benefit of modularity is that modules can be easily com bined to another system. Coupling is the extent inwhichdifferentmodulesshowinterdependen cy with each other and cohesion represents the functional strength of module. In well OO sys tems, a module should exhibits the property of lowcouplingandhighcohesion. 3) Reusability: This gives an idea of how reusable thesoftwareis.Objectorientedsoftwaresystems havebothtypesofreusability,functionalreusa

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

102

4)

5)

bilityandcodereusability.Functionalreusability onOOapproachissimilarasincaseofmodule oriented approach. Code reusability in OO ap proach is due to its inheritance property. Class inheritancepermitsaclasstoreuseitbymaking subclassfromit. Cost:Costreferstodifferenttypesofexpenses.It canbethecostoftheequipmentandthecostof system itself. Software development cost should belowerforbettersoftwaresystem. Safety:Safetyisdefinedasthecapacitytoavoid any kind of damage and risk derived when the systemisinuse.Usersafetyisveryessentialto day in terms of confidentiality. The software shouldbetotallyfreeofbugs,employingredun dancyorconductingextensivetestingforopera TABLE 4 PROPOSED MOOSQUA MODEL Characteristics Functionality Sub Characteristics Suitability Accuracy Interoperability Security Compliance Reusability TimeBehaviour Resource Behaviour

ObjectOriented Software Quality (MOOSQUA) Analytic Hierarchy Process (AHP) technique is used. It is a deci sionmakingtechniquedevelopedbySaaty[40]. ConsidertherearenelementsfromA1toAnthathaveto becomparedandtoformasquarematrixdenotetherela tiveweightofAiwithrespecttoAjbyaij.Theconstraints toformasquarematrixA=(Zij)ofordernthatZij =1/Zij, fori=j,andaii=1,alli.Therelativeimportanceoftwoele ments is rated using a scale with the values 1, 3, 5, 7, 9, where1forequallyimportant,3forsomewhat more important, 5 for much more important, 7 for very much more important, 9 for absolutely more important and 2, 4,

Quality Type Software Product Quality

6, 8 are intermediate values.

4.1 Consistency Test

Consistencyindex(C.I.)andconsistencyratio(C.R.)pro posed by Saaty to verify the consistency of the compari sonmatrix. CIandCRaredefinedasfollows: CI=maxn n1 CR=R.I. C.I. Where, RI is the average consistency index over numer ousrandomentriesofthesameorderreciprocalmatrices. IfCR 0.1, the estimate is accepted.IftheCRisexcess of0.1(CR>0.1)thejudgementsareinconsistenttobere liable.

Efficiency

Cost Replaceability Adaptability Installability CoExistence Maintainability Analyzability Changeability Testability Stability Modularity CodeReadabil ity Usability Understandabil ity Learnability Operability Attractiveness Safety Reliability Maturity FaultTolerance Recoverability Portability

4.2 Allocating the Weights of Characteristics and Sub-Characteristics

The survey conducted on 13 professionals to assign weights to characteristics and subcharacteristics of pro posed model. Survey form consists of all characteristics and sub characteristics of proposed model. Professionals

tionalsafety.

4 EVALUATION OF MOOSQUA USING ANALYTIC HIERARCHY PROCESS

InordertoevaluatethequalityofproposedModelfor wererequestedtogivetheirpreferencestoallcharacteris

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

103

TABLE 5 EIGEN VECTORS AND EIGEN VALUES OF QUALITY CHARACTERISTICS Functinality(F) Reliability(R) Usability(U) Efficiency(E) nth (6th) root of productvalues Maintainability (M) Eigenvector() A. 0.1209 0.164 0.225 0.192 0.2367 0.0628 1.000 0.7632 1.0142 1.360 1.176 1.5429 0.382 6.312 6.191 6.063 6.140 6.518 6.082 Mean=6.217 max

F R U E M P Total

1 2.25 1.833 2.083 1.333 0.352

0.444 0.545 1 1.583 1.5 1.5 0.413 0.631 1 0.709 1.25 0.324

0.48 0.666 1.41 1 1.666 0.342

0.75 0.666 0.8

2.833 2.416 3.08

Portability(P) 3.333 1

0.792 1.072 1.469 1.253 1.550 0.411 6.547

0.6 2.911 1 0.3

tics and subcharacteristics according to the rating scale giveninsurveyform. Thesurveyformconsistofseventablesinwhichfirstta ble for filling the pairwise relative weight values of six characteristicsi.e.Functionality(F),Reliability(R),Usabil ity(U),Efficiency(E),Maintainability(M),andPortability (P).Similarly,inthesurveyformintheremainingsixta bles are for filling the relative weight of the sub characteristicsofF,R,U,E,MandP. In order to determine eigenvector and eigenvalues of all thesixcharacteristics,multiplyingtogethertheentriesin each row of the matrix and then taking the nth root (in our case 6th root) of that product, which gives a very goodapproximationtothecorrectanswer.Thevaluesare giveninTable5.Thenthrootissummedandthatsumis used to normalize the eigenvector elements to add to 1.000. In the matrix of Table5, the 6th root for the first rowis0.792andthatisdividedby6.547togive0.1209as thefirstelementintheeigenvector.Theeigenvectorofthe relativeimportanceofF,R,U,E,MandPis(0.121,0.164, 0.225,0.192,0.2367,0.0628)whichisgiveninTable5. Eigen values max can be evaluated by applying max= (A./)andthesesixmaxvaluesarecalculatedas6.312, 6.191,6.063,6.140,6.518and6.082.Allthesevaluesofmax are greater than 6, as this matrix is of order of 6, which satisfiestheconditionofmaxn.Themeanofmaxvalues is6.217. NowwecanevaluateCIas CI=(maxn)/(n1)=(6.2176)/(61)=0.043 Thefinalstepistocalculatetheconsistencyratio(CR)for thesetofjudgmentsusingtheCIforthecorresponding

value from samples of matrices of purely random judg ments.WefoundthecalculatedvalueofCR<0.1inallthe samples of matrices, which indicates that the estimate is acceptable. Similarly, we have applied AHP process on pairwiserelativeweightsofsubcharacteristicsofcharac teristics F, R, U, E, M and P one by one and all these weights of subcharacteristics are listed in column of Table6. Twenty five evaluative subcharacteristics are weightedasfollows: Suitability (0.017), Accuracy (0.013), Interoperability (0.026), Compliance (0.014), Security (0.031), Reusability (0.019),Maturity(0.024),Faulttolerance(0.080),Recover ability (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), Replaceability (0.026), and Coexistance (0.009). Each subcharacteristic not has equal importance. So to restrictnottooverdesignthesystem,wetakeonlyselect ed characteristics and sub characteristics. According to the weight values of characteristics in Table 6, we select total 12 sub characteristics i.e. Interoperability, Security, ReusabilityandSuitabilityunderFunctionalitycharacter istic, Fault Tolerance under Reliability characteristic, Re source Behaviour and Cost under Efficiency characteris tic, Understandability and Learnability under Usability characteristicandTestability,ChangeabilityandModular ity under Maintainability characteristic. In this case, we needtonormalizetheweightvaluesofselectedcharacter isticsandsubcharacteristicstomakesumofallweight

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

104

TABLE 6
WEIGHT VALUES FOR SUB-CHARACTERISTICS

TABLE 7 NORMALIZED VALUES OF QUALITY SUB- CHARACTERISTICS Characteristics WeightValues Sub characteristic

WeightValues

Characteristic

Sub Characteristic

Eigenvectors

Sum

R E

Suitability Accuracy Interoperability Security Compliance Reusability Maturity FaultTolerance Recoverability TimeBehavior ResourceBehvi our Cost Understandabil ity Learnability Operability Attractiveness Safety Stability Testability Changeabiliy Analyzability Code Readabil ity Modularity Adaptability Installability Replaceability Coexistence

0.141 0.108 0.216 0.258 0.116 0.158 0.141 0.490 0.368 0.204 0.502 0.293 0.325 0.245 0.174 0.156 0.098 0.076 0.224 0.283 0.122 0.105 0.186 0.129 0.306 0.419 0.145

0.017 0.013 0.026 0.031 0.014 0.019 0.024 0.080 0.060 0.039 0.097 0.056 0.073 0.056 0.039 0.035 0.022 0.018 0.054 0.067 0.029 0.025 0.044 0.008 0.019 0.026 0.009

0.120

F R E

0.164 0.192 0.225

U M Total

Suitability Interoperability Security Reusability FaultTolerance Resource Behaviour Cost Understandability Learnability Modularity Testability Changeabiliy

0.030 0.034 0.046 0.035 0.167 0.132 0.081 0.139 0.096 0.061 0.078 0.102

0.145

0.167 0.212

0.235 0.241 1.00

0.237

0.062

Total

1.000

valuesequalto1.Thenormalizedvaluesobtainedinscale of01arementionedinTable7. To evaluate the quality of a software system as a whole, we need to measure all the selected characteristics and sub characteristics. The formula used to evaluate the whole quality of software system Quality = Fwf + Rwr + Uwu + Ewe + Mwm + Pwp 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). We have the weight values of all the characteristics mentioned in Table 5. Further, we need to evaluate the characteristics F, R, U, E, M and P. The formulas used to evaluate all the quality characteristics of software system F = wsuSu + waA + wiI + wsS + wcoCo + wreRe R = wmaMa + wftFt + wrcRc U = wunUn + wlbLb + wopOp + wattAtt + wsaSa E = wtbTb + wrbRb + wctCt M = wstSt + wteTe + wchCh + wanAn + wcrCr + wmoMo P = wadAd + winIn + wrpRp + wcoeCoe Wherewsu,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 and wcoe are weight values for Suitability, Accuracy, Interoperability, Security, Compliance, Reusability, Ma turity, Faulttolerance, Recoverability, Understandability, Learnability, Operability, Attractiveness, Safety, Time behavior, Resource behavior, Cost, Stability, Testability, Changeability,Analyzability,CodeReadability,Modular ity, Adaptability, Installability, Replaceability, and Co existence. Now, to measure the sub characteristics, we mentioned the set of metrics in Table 8.

4.3 Evaluation of Object Oriented Projects

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 MOOSQUA by using metrics shown in Table 8.

Sum

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

105

As these projects are based on C++, there is no platform independency. Therefore, there is no need to select Portability characteristic and its sub characteristics. 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,weassume 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. 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 evaluate 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-9 and Table-10.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 8 METRICS FOR EVALUATION Sub characteristics Security Interoperability Reusability Suitability Fault Tolerance Resource iour Cost Understandability Learnability Testability Changeability Modularity BehavMetric Number of access controllability provided/ total number of access controllability required. Degree of communication between system and stakeholders. Number of reusable properties/total number of properties Suitable operations/ total number of operations Operational profile of the software and number of faults in the software evaluated. How much resources required to run the software i.e. % CPU usage for the execution of method. How much expensive to buy the software User documentation, training provided and help system Number of achievable tasks/ total number of tasks Number of test cases provided for a system Number of properties can be customized/ total number of properties Combine measurement of coupling between objects (CBO) and lack of cohesion in methods (LCOM).

TABLE 9 FINAL QUALITY OF PROJECT 1 Characteristics Functionality Subcharacteristic Suitability Interoperability Security Reusability Reliability Efficiency Usability FaultTolerance ResourceBehavior Cost Understandability Learnability Modularity Testability Changeabiliy Metric(M) 5/8 =0.625 0.25 3/5 =0.6 7/10 =0.7 0.50 0.60 0 0.66 8/10 =0.8 0.75 0.5 6/10 =0.60 Weight Mi*wi (w) 0.030 0.019 0.034 0.046 0.035 0.167 0.132 0.081 0.139 0.096 0.061 0.078 0.102 0.008 0.028 0.024 0.083 0.079 0 0.092 0.077 0.046 0.039 0.061 0.083 0.079 0.169 Quality 0.079

Maintainability

0.146

Total

0.556

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

106

TABLE 10 FINAL QUALITY OF PROJECT 2 Characteristics Functionality Reliability Efficiency Usability Maintainability Total Subcharacteristic Weight Mi*wi (w) Suitability 8/9=0.89 0.030 0.027 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 FaultTolerance 0.75 0.167 0.125 ResourceBehavior 0.80 0.132 0.106 Cost 0 0.081 0 Understandability 0.66 0.139 0.092 Learnability 7/12=0.58 0.096 0.056 Modularity 0.70 0.061 0.043 Testability 0.5 0.078 0.039 Changeabiliy 7/12=0.58 0.102 0.059 Metric(M) Quality 0.105

0.125 0.106 0.148 0.141 0.625

5 CONCLUSION
This paper proposed a Model for Object Oriented Soft wareQUAlity(MOOSQUA)andevaluatedthequalityof this model by usingAnalytical Hierarchy Process (AHP) technique.ISO/IEC9126Iwasconsideredasabasemod el. New sub characteristics were added to this proposed model.Basisonexpertsviewandsurveysonlythosesub characteristics were included, which were more relevant for the software applications. Pairwise relative weight values are assigned to the characteristics and sub characteristics by using AHP technique. To obtain the quality of objectoriented software system, we used the aboveevaluationprocessontwoC++projects.Theresult was in the terms of quality as a single score for each of theprojects.Theobtainedresultscanbeusedtocompare andselectthebestsuitableobjectorientedqualitymodel as per defined quality characteristics. In future we will applythismodelonreallifeobjectorientedsoftwaresys tem to gain more perspective view about the pros and consofthismodel.

[3] [4]

A. Eliens, Principles of Object Oriented Software Development, AddisonWesley,USA,2000. A.Sharma,R.Kumar,P.S.Grover,EstimationQualityforSoft ware Components: An Empirical Approach, ACM SIGSOFT SoftwareEngineeringNotes,vol.33(6),pp.110,2008.

[5]

A.Kumar,R.Kumar,andP.S.Grover,AQuantitativeEvalua tion of AspectOriented Software Quality Model (AOSQUAMO), ACM SIGSOFT Software Engineering Notes, vol.34(5),pp.19,2009.

[6]

B.W. Boehm, J.R. Brown, H. Kasper, M. Lipow, G.J. Macleod, and M.J. Merrit, Characteristics of software Quality, vol. 2, Elsevier,NorthHolland,1978.

[7]

C.Chang,C.Wu,andH.Lin,IntegratingfuzzytheoryandHirarchy ConceptstoEvaluateSoftwareQualityControl,vol.16,no.2,pp.263 276,2008

[8]

D. G. Firesmith, Common concepts underlying safety, secu rity,andsurvivabilityengineering,CarnegieMellonSoftware Engineering Institute Technical Note CMU/SEI2003TN033, December2003.

[9]

F. Khomh, N. Haderer and G. Antoniol, SQUAD: Software Quality Understanding through the Analysis of Design, Re verseEngineering,WCRE09,16thworkingconference,2009.

ACKNOWLEDGEMENT
The authors wish to thanks to Prof. (Dr.) Arun Sharma for his guidance and support during the evaluation of projects. Authors also wish to thank Ms. Ankita Madan for her valuable suggestions during the development of model.

[10] G. R. Dromey, A model for software product quality, IEEE Trans.onsoftwareEng.,vol.21,no.2,pp.146162,1995. [11] Ghezzi, C. M. Jazayeri, and D. Mandrioli, Fundamental of Soft wareEngineering,PrenticeHall,NJ,USA,1991. [12] G.G.SchulmeyerandJ.I.McManus,Totalqualitymanagement for software quality. Southern African: International Thomson Pub.,1996. [13] I.Castillo,F.Losavio,A.Matteo,andJ.Boegh,Requirements, Aspects and Software Quality: the REASQ model, Journal of Object Technology, vol. 9, no. 4, pages 6991, 2010. http://www.jot.fm/contents/issue_2010_07/article4.html [14] I.Jacobson,G.Booch,J.Rumbaugh,TheUnified Software Devel opmentProcess,AddisonWesley,1999.

REFERENCES
[1] [2] AOSD, AspectOriented Software Development Home Page, http://www.aosd.net/wiki/index.php?title=Glossary,2008. A. Rawashdeh and B. Matalkah, A New Software Quality ModelforEvaluatingCOTScomponents,JournalofComputer Science,vol.2,no.4,pp.373381,2006.

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 2, FEBRUARY 2012, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

107

[15] P. Kruchten, The Rational Unified Process: An Introduction, AddisonWesley,2000. [16] IEEEStandardforSoftwareMaintenance,SoftwareEngineering StandardsSubcommitteeoftheIEEEComputerSociety,1993. [17] ISO/IEC91261,InstituteofElectricalandElectronicsEngineers, Part1,2,3:Qualitymodel,2001. [18] ISO 9126 Standard ISO/IEC, Information technology Software product quality Part1: Quality Model, ISO/IEC FDIS 91261: 2000(E). [19] ISO /IEC, International Standard 8402: Quality Vocabulary, 1986. [20] ISO/IEC TR 91263, Software Engineering Product Quality, 2002. [21] ISO 9126, Software Product Evaluation: Quality characteristics andguidelinesfortheiruse,ISO/IECStandardisationISO9126, 1991. [22] J.A.McCall,RichardsP.K.,andWaltersG.F.,FactorsinSoft ware Quality, vol. 1, 2, and 3, AD/A 049014/015/055,National Tech.Informationservice,Springfield,1977. [23] J. E. Gaffney, Metrics in software quality assurance, no. 81, pp.126130,ACMpress,March1981. [24] J. Bansiya, and C.G. Davis, A Hierarchical Model for Object Oriented Design Quality Assessment, IEEE Transactions on SoftwareEngineering,2002. [25] J.W. Satzinger, R.B. Jackson, S.D. Burd, System Analysis and Design in a Changing World, ed.2, Thomson Learning Can ada,2002. [26] K. Khosravi, Y. Gueheneuc, On Issues with Software Quality Models,9thECOOPworkshoponQuantitativeApproachesinOb jectOrientedSoftwareEngineering,2005. [27] L. Briand, E. Arisholm, S. Counsell, F. Houdek, P. Thevenod Fosse, Empirical Studies of ObjectOriented Artifacts, Meth ods, and. Processes: State of The Art and Future Directions, TechnicalReportISERN9912,1999. [28] L.H. Rosenberg and L. Hyatt, Software Quality Metrics for Object Oriented Environments, SATC, NASA, Technical Re portSATCTR951001,1995. [29] M.S.DeutschandR.R.Wills,Softwarequalityengineering;atotal technicalandmanagementapproach.PrenticeHall,Inc.,1998. [30] M. Fusani, Quality Models for Software Evolution Instru ments, International Seminar on Software Measuring & Testing, IEI CNR /Qualital /SSSUP S.ANNA Pisa, Italia, December 1995. [31] M. Berota, A. Vallecillo, Quality attribute for COTS Compo nent, in the proceedings of the sixth International ECOOP Work shoponQuantitiveApproachesintheObjectOrientedSoftwareEn gineering(QAOOSE),Spain,2002. [32] R.Grady,Caswell,andDeborah,Softwaremetrics:Establishing a companywide program, PrenticeHall, ISBN 0138218447, 1987. [33] R. Fitzpatrick, Software Quality: definitions and strategic is sues, School of Computing Reports, Standfordshire Univer sity,1996. [34] R. Kazman, L. Bass and P. Clements, Software Architecture in Practice,2eds.,AddisonWesley,2003.

[35] R.A. Khan and K. Mustafa, A Review of SATC Research on OO Metrics, Proceedings, National Conference on Software Engi neeringPrinciplesandPractices,SEPP04,2004. [36] R.A. Khan, K.Mustafa, and S. Yadav, Quality Assessment of Object Oriented Code in Design Phase, Proceedings, QAI 4th Annual International Software Testing Conference, Pune, India, 2004. [37] R. S. Pressman, Software Engineering a practitioners Approach, McGrawHill,Inc.,1992. [38] R.S.Pressman,SoftwareEngineeringapractitionersapproach, 5eds.,McGrawHill,2001. [39] S.K Dubey and A. Rana, Analytical Roadmap to usability Definitions and Decompositions, International Journal of Engi neeringScienceandTechnology,vol.2(9),2010. [40] Saaty, T.L, The Analytic Hierarchy Process, McGraw Hill International,1980.

Sanjay Kumar Dubey is an Assistant Professor in Amity University Uttar Pradesh, India. His research area includes Human Computer Interaction, Software Engineering, and Usability Engineering. He is pursuing his Ph.D. in Computer Science and Engineering from Amity University.

Abhishek Jain is a researcher in Computer Science & Engineering Department from Amity University, Noida. His area of interest is Software Engineering. . Ajay Rana is a Professor and Director, Amity University, Noida. He is Ph. D. (2005) in Computer Science and Engineering from U.P. Technical University, India. His research area includes Software Engineering. He has published number of research papers in reputed National & International Journals. He has received numbers of best paper/case studies medals and prizes for his work.