JOURNAL OF COMPUTING, VOLUME 3, ISSUE 9, SEPTEMBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.

ORG

73

Early Usability Model for Object-Oriented System

Sanjay Kumar Dubey, Arashdeep Kaur and Dr. Ajay Rana
AbstractUsability is an important quality factor which is included in most of the quality models due to its consequences. The requirement of quality software causes the development of new techniques which can be used in developing model for predicting usability of software systems. One such technique is clustering. In this paper various metrics dataset are being used to assess the usability, namely, CM1, PC1 and JM1 taken from a public NASA data set. The metric sets include requirement time metrics and module metrics. These metrics are then combined using inner join method. This paper assess the usability of software system to be developed, at early stages of software life cycle using software fault data available from already developed similar kind of projects. Hence, examines the relationship between usability and software fault using K-Means clustering. Index TermsUsability; Software quality; clustering; Software Metrics; K-Means

1 INTRODUCTION
Usability is recognized as an important quality factor for software systems. There are various models which describe the importance of usability attribute in software system engineering. Research shows that usability is key component in the overall quality of a software product [11]. Usability also became the key issue in humancomputer interaction because not only it refers to quality of user interface but also concerned with supporting users during their interaction with computer [2]. Due to lack of usability, system may fail to fulfill the expectations of users of software system. In spite of best efforts of usability experts, systems still continue to have usability flaws that are costly and difficult to fix after the system has been implemented. To overcome this, a usability model is being presented in this paper. Usability relies on some fundamental attributes like feedback of system, number of errors, estimated time to fix those errors, number of features that system supports etc. So these metrics can be used to assess usability of a software system. Usability of a software system under construction can be estimated during early development stages by collecting data from some other similar kinds of projects. The development of early usability assessment model for software systems can be accomplished by using some advance techniques. Clustering is a technique which is helpful to develop a model based on the assessment of data. This paper examines the applications of clustering for usability estimation, and then it develops a

usability model by using requirement metric model, code metric model, and combination metric model by using clustering algorithm.

2 USABILITY
For the development of efficient software system, it is necessary to understand the usability. There are various sources and models which define the usability. Some most referenced definitions of usability is given in following Table 1. TABLE 1 USABILITY DEFINITIONS

Sanjay Kumar Dubey is with the Amity University, Sec-125, NOIDA (U.P.), India. Arashdeep kaur is with the Amity University, Sec-125, NOIDA (U.P.), India. Dr. Ajay Rana is with the Amity University, Sec-125, NOIDA (U.P.), India.

Various models are proposed in literature based on usability. The details can be found in the [17]. The usability relies on its various sub-characteristics for the development of efficient software system. Followings are some important sub-characteristics of usability. Acceptance: Whether a product is acceptable or not. It depends on context of use and characteristics of user [12]. Accessibility: The degree to which software can be used comfortably by a wide variety of people [10].

2011 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 9, SEPTEMBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

74

Attractiveness: The capability of the software product to be attractive to the user [6]. Control: It addresses the responses the product gives to the user's actions [11]. Ease of Use: It determine whether a product can be used in easiest way. It affects users performance and satisfaction [12]. Effectiveness: The degree of accuracy and completeness with which the user achieves a specified task in a certain context [10]. Efficiency: It described that system should be efficient to use [8]. Emotion: The emotional attribute of usability attract the consumer's attention, enable learning by exploring and relieve computer anxiety [15]. Fault Tolerance: Capability of the software product to maintain a specified level of performance in cases of software faults [6]. Flexibility: The ease of making changes required by changes in the operating environment [1]. Internationability: The degree to which software can be used for the global marketplace, considering variations in regions, languages, and cultures [10]. Learnability: The capability of the software product to enable the user to learn its application [6]. Likeability: User's perceptions, feelings, and opinions of the product [7]. Memorability: It refers to casual users ability to remember how to use a system after a period of time [8]. Minimal Action: The extent to which user needs to take minimal effort to achieve a specific task [3]. Minimal Memory load: The extent to which user needs to keep minimal amount of information in mind to achieve a specified task [3]. Operability: The capability of the software product to enable the user to operate and control it [6]. Productivity: It is the level of effectiveness achieved in relation to the resources consumed by the users and system. It is obtained from user interaction with the software product [1]. Safety: It concerns whether a software product limits the risk of harm to people or other resources, such as hardware or stored information [1]. Satisfaction: Freedom from discomfort and positive attitude towards the use of the software product [10]. Trustfulness: The faithfulness of a software product offers to its users [1]. Understandability: The capability of the software product to enable the user to understand whether the software is suitable, and how it can be used for particular tasks and conditions of use [6]. Usability compliance: The capability of the software component to adhere to standards, conventions, regulations relating to usability [6]. Usefulness: The items of 'system usefulness' refer to the users' perception of the ease of use, learnability, speed of performance and effectiveness in completing tasks, and subjective feeling [9] User Guidance: Whether the user interface provides context-sensitive help and meaningful feedback when errors

occur [1].

3 CLUSTERING
Clustering is a technique that divides data in to two or more clusters depending upon some criteria. As in this study data is divided in to two clusters depending upon that whether they are fault free or fault prone. Seliya et al. [13] investigated semi supervised learning approach for classifying data to improve software quality rather than supervised and unsupervised learning alone. K-means clustering is one of the best examples of semi-supervised learning [16]. K-means is a clustering algorithm depends upon iterative location that partitions dataset into K no. of clusters by standard Euclidean distance. K-means clustering algorithm starts with determining the K i.e. no. of clusters to be formed. Then randomly K no. of centroids will be chosen from the data collected. Distances of all the attributes or data objects will be calculated and all objects are divided into K no. of cluster groups following the criteria of putting the object into the group that has minimum distance with centroids and then recomputed the cluster centroids. This process is repeated until convergence criteria met.

4 METHODOLOGY
Methods for identifying usability of software modules support helps to improve resource planning and scheduling as well as facilitating cost avoidance by effective verification. Such models can be used to predict the response variable which can either be the class of a module (e.g. usable or not) or a quality factor (e.g. usability factor) for a module. However various software engineering practices limit the availability of usability data. With its effect supervised clustering is not possible to implement for analyzing the quality (usability, reusability, maintainability etc.) of software system. This limited data can be clustered by using semi supervised clustering. It is a constraint based clustering scheme that uses software engineering experts domain knowledge to iteratively create clusters as either usable or not. Software usability assessment models seek to evaluate two factors such as whether a component is usable or not. The methodology completes in the following steps:

4.1 Find the structural code and requirement attributes The first step is to find the structural code and requirement attributes of software systems i.e. software metrics. The real-time defect data sets are taken from the NASAs MDP (Metric Data Program) data repository, available online at [14]. In the MDP data, there are 13 projects, only 3 of them offer requirement metrics. The PC1 data is collected from a flight software system, containing 1107 modules and only 109 have their requirements specified. PC1 has 320 requirements available and all of them are associated with program modules. All these data sets varied in the percentage of defect modules, with the PC1

2011 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 9, SEPTEMBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

75

dataset containing the least number of defect modules. CM1 is a NASA spacecraft instrument data containing approximately 505 modules. CM1 has 266 modules that have their requirements specified. CM1 has 160 requirements and only 114 of them have associated program modules identified. JM1, is a real time ground system containing 10878 modules of which only 97 have their requirement specified. JM1 has 74 requirements available, only 17 of them are related to corresponding program modules.

4.2 Select the suitable metric values as representation of statement The suitable metrics like product requirement metrics and product module metrics out of these data sets are considered.
The product requirement metrics are as follows: Module: This metric describes the unique numeric identifier of the product. Action: This metric represents the number of actions the requirement needs to be capable of performing. Conditional: This metric is used to represent whether the requirement will be addressing more than one condition. Continuance: This metric describe phrases such as the following: that follow an imperative and precede the definition of lower level requirement specification. Imperative: This metric describe those words and phrases that command that something must be provided. Option: This metric describe words that give the developer latitude in the implementation of the specification that contains them. Risk_Level: A calculated risk level metric based on weighted averages from metrics collected for each requirement. Source: This metric represent the number of sources the requirement will interface with or receive data from. Weak_Phrase: This metric describe clauses that are apt to cause uncertainty and leave room for multiple interpretations. The product module metrics are as follows: Module: This metric describes the unique numeric identifier of the product. Loc_Blank: This metric describes the unique numeric identifier of the product. Branch_Count: This metric describes the branch count metrics i.e. the number of branches for each module. Call_Pairs: This metric describes the number of calls to ther functions in a module. LOC_Code_and_Comment: This metric describes the number of lines which contain both code & comment in a module. LOC_Comments: This metric describes the number of lines of comments in a module. Condition_Count: This metric describes the number of conditionals in a given module. Cyclomatic_complexity: This metric describes the cyclomatic complexity of a module. It is the number of linearly independent paths.

Cyclomatic_Density: This metric describes the ratio of the module's cyclomatic complexity to its length. The intent is to factor out the size component of complexity. Decision_Count: It describes the number of decision points in a given module. Decisions are caused by conditionals statements. Edge_Count: This metric describes the number of edges found in a given module. It represents the transfer of control from one module to another. Essential_Complexity: It describes the essential complexity of a module. Essential_Density: The Essential density is given by, (ev (G)-1)/ (v (G)-1) where ev (G) stands for essential complexity and v (G) stands for cyclomatic complexity. LOC_Executable: The number of lines of executable code for a module. This includes all lines of code that are not fully commented and blank. Parameter_Count: It describes the number of parameters to a given module. Global_Data_Complexity: Global Data Complexity quantifies the cyclomatic complexity of a module's structure as it relates to global/parameter data. Global_Data_Density: The Global Data density is calculated as: gdv (G) / v (G), i.e. dividing global data complexity by cyclomatic complexity. Halstead_Content: This metric describes the Halstead length content of a module. Halstead_Difficulty: The difficulty level or error proneness (D) of the program is proportional to the number of unique operators in the program. Halstead_Effort: This metric describes the halstead effort metric of a module. Effort is the number of mental discriminations required to implement the program and also the effort required to read and understand the program. Halstead_Error_EST: This metric describes the halstead error estimate metric of a module. It is an estimate for the number of errors in the implementation. Halstead_Length: This metric describes the halstead level metric of a module i.e. level at which the program can be understood. Halstead_Prog_Time: This metric describes the halstead programming time metric of a module. It is estimated amount of time to implement the algorithm. Halstead_Volume: This metric describes the halstead volume metric of a module that contains the minimum number of bits required for coding the program.. Normalized_Cyclomatic_Complexity: Normalized complexity is simply a module's cyclomatic complexity divided by the number of lines of code in the module. This division factors the size factor out of the cyclomatic measure and identifies modules with unusually dense decision logic. A module with dense decision logic will require more effort to maintain than the modules with less dense logic. Num_Operands: This metric describes the number of operands contained in a module. Num_Operators: This metric describes the number of operators contained in a module. Num_Unique_Operands: This metric describes the number of unique operands contained in a module. It is a

2011 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 9, SEPTEMBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

76

count of unique variables and constants in a module. Num_Unique_Operators: This metric describes the number of unique operators contained in a module i.e. the number of distinct operators in a module. Number_Of_Lines: This metric describes the number of lines in a module. Pure, simple count from open bracket to close bracket and includes every line in between, regardless of character content. This metric describes the number of lines in a module. Pure, simple count from open bracket to close bracket and includes every line in between, regardless of character content. Pathological_Complexity: It describes the measure of the degree to which a module contains extremely unstructured constructs. Pathological complexity measures the degree to which a module contains extremely unstructured objects. Percent_Comments: This metric describes the percentage of the code that is comments. LOC_Total: This metric describes the total number of lines for a given module. This is the sum of the executable lines and the commented lines of code. Blank lines are not counted.

In Figure1 ER diagram relates the inner join between three tables i.e. CM1_product_requirement_metrics, CM1_requirement_prodct_relation and CM1_product_module_metric. The result of the join can be defined as the outcome of first taking the Cartesian product (or cross-join) of all records in the tables then return all records which satisfy the join predicate. Join operation is performed on CM1_product_module_metric and CM1 _requirement_ product_relation using common attribute Module ID and result is stored in temporary table. Then taking all records from temporary table and joining with product_requirement_metrics using Requirement ID.

4.3 Analyze, refine metrics and normalize the metric values In the next step the metrics are analyzed, refined and normalized and then used for modeling of fault prediction in software systems. PC1 static code based dataset contains 43 static code metrics of which various metrics that do not impact binary classification are removed like module identifier, call pairs, condition count, cyclomatic density, Decision count, Decision density, Edge count, Essential density, etc and the remaining 22 have been used for training and testing data. Requirement based dataset contains 8 input metrics for all the projects included in MDP repository. 4.4 Combine Requirement and code metrics
Combining requirements and code metrics have beendone using inner join database operation. An inner join creates a new result table by combining column values of two tables based upon the join-predicate.

4.5 Find the suitable algorithm for classification of the software components into usable/not usable systems It is very important to find the suitable algorithm for classification of software components into faulty/fault-free systems and then correlate these with usability. The techniques build models using software metrics and classify the components as faulty and fault free. We have used KMeans clustering for identifying fault prone and fault free modules. 4.6 Implementing the model and finding the result The proposed approach has been implemented in MATLAB 7.0 environment. Clustering technique being used is a built-in function in its statistics toolbox. These functions are used with their default parameters. 4.7 Performance Criteria To predict the results, we have used confusion matrix in Table 2. The confusion matrix has four categories: True positives (TP) are the modules correctly classified as faulty modules. False positives (FP) refer to fault-free modules incorrectly labeled as faulty. True negatives (TN) are the fault-free modules correctly labeled as such. False negatives (FN) refer to faulty modules incorrectly classiTABLE 2 CONFUSION MATRIX

fied as fault-free modules. The following set of evaluation measures are being used to find the results: Probability of Detection (PD), also called recall or specificity, is defined as the probability of correct classification of a module that contains a fault. PD = TP / (TP + FN) (1)

Figure1. E-R Diagram relates project requirements to project modules

2011 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 9, SEPTEMBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

77

Probability of False Alarms (PF) is defined as the ratio of false positives to all non defect modules. PF = FP / (FP + TN) (2) Accuracy is defined as the closeness to the true value seen as the degree of agreement of readings Accuracy = (TP+TN) / (TP+TN+FP+FN) (3) Basically, PD should be maximum and PF should be minimum [18]. More is the value of accuracy, more accurate is the system and vice-versa. The comparison between PD and PF of projects can be viewed by using ROC curve. ROC stands for Receiver Operator Characteristics curve.ROC analysis is related in a direct and natural way to cost/benefit analysis of software projects by comparing their detected defective and non-defective modules.ROC curves can be beneficial for finding accuracy of predictions. General ROC curve has a concave shape with (0, 0) as beginning and (1, 1) as end point and is divided into different regions namely preferred curve region, cost adverse region, risk adverse region and negative curve.

The above data shows that after joining the columns in both the metrics we have better accuracy i.e. it indicates that performance is much better. Hence, these metrics can TABLE 4 RESULT OF MODEL JM1

be effective if they can be combined.

5 RESULTS
Following Table 3 and Table 4 show the results of using K-means clustering on PC1 dataset as training data and using the metrics CM1 and JM1 to calculate their true positives true negatives, false positives, false negatives, probability of detection and probability of false alarms. From the Table 3, it is clear that the value for PD, PF and accuracy are 0.10294, 0.095238 and 0.29213 respectively for requirement metrics and the value for PD, PF and accuracy are 0.49484, 0.99754 and 0.09702 for code metrics in CM1 project. From the Table 4, it is clear that the value for PD, PF and accuracy are 0.29412, 0.2 and 0.56757 respectively for requirement metrics and the value for PD, PF and accuracy are 0.59772, 0.98645 and 0.19204 for code metrics in JM1 project. If we carefully observe the join column in both the tables then we found that in Table 3, the join column has the value of PD, PF and accuracy as 0.55135, 0.08641 and 0.66165 for CM1 project and in Table 4 the join column has the value of PD, PF and accuracy as TABLE 3 RESULT OF MODEL CM1

Figure 2 represents the ROC curve. In ROC curve, points A and D lie in cost adverse region. Cost adverse region exhibits low PD and low PF which means that detection is very much low. Point B and E lies in the Risk Adverse region, the region with high PD and high PF. This region can also be preferred because detection is more important than cost to validate those false detections.

Figure2. ROC Curve of Results

Points C and F lie on the preferred curve i.e. with high PD and low PF. The region with high PD and low PF is always preferred as in this detection is always high and also cost to validate false alarms is always low. Results also show that join metric model is more accurate than other two.

6 CONCLUSION
0.86585, 0.66666 and 0.7835 for JM1 project. The above observed performance shows that the real
2011 Journal of Computing Press, NY, USA, ISSN 2151-9617

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 9, SEPTEMBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

78

world software engineering solutions can show better representation by training and test datasets after the inner join operations on their metrics. The combined model is far accurate than previously proposed models in literatures. The results show that the performance of join metric model is far better than the individual models and thus can help to improve the usability of the software system. Data available at early stage can be helpful for better usability prediction. Further research will include more algorithms to find the best suited algorithm for better judgment of usability for the given system.

Machine Learning, pp 19-26, 2002. [17] S.K. Dubey and Ajay Rana, Assessment of Usability Metrics for Object Oriented Software System, ACM SIGSOFT Software Engineering Notes, Vol. 35 No. 6, 2010. [18] Y. Jiang, B. Cukic and T. Menzies, Fault Prediction Using Early Lifecycle Data. ISSRE 2007, the 18th IEEE Symposium on Software Reliability Engineering, IEEE Computer Society, Sweden, pp. 237-246, 2007. Sanjay Kumar Dubey is Assistant Professor in Amity University Uttar Pradesh, India. His research area includes Human Computer Interaction, Software Engineering, and Usability Engineering. He has published more than 21 research papers in International journals and conferences He is pursuing his Ph.D. in Computer Science and Engineering in the field of Software Engineering. Arashdeep Kaur is Assistant Professor in Amity University Uttar Pradesh, India. Her research area includes Software Engineering and Image Processing. She has published number of research papers in International journals and conferences. Dr. Ajay Rana is Professor and Director in Amity University Uttar Pradesh, 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 59 research papers in reputed National & International Journals. He is the author of books on Software Engineering and Software Testing. He has received number of medals and prizes for his work.

REFERENCES
[1] A. Seffah, M. Donyaee, R. B. Kline and H. K. Padda, Usability measurement and metrics: A consolidated model, Software Quality Control, Vol. 14, No. 2, pp. 159178, 2006. B. Shneiderman, and C. Plaisant, Designing the User Interface: Strategies for Effective Human-Computer Interaction, Addison Wesley, Boston, MA, 2005. H. X. Lin, Yee-Yin Choong and G. Salvendy, A Proposed Index of Usability: A Method for Comparing the Relative Usability of Different Software Systems Usability Evaluation Methods, Behavior and Information Technology, Vol. 16, No. 4-5, pp. 267-278, 1997. IEEE Std. 1061, IEEE standard for a software quality metrics methodology, New York, IEEE Computer Society Press, 1992. ISO 9241-11, Ergonomic requirements for office work with visual display terminals (VDTs) Part 11: Guidance on usability, 1998.S.P. Bingulac, On the Compatibility of Adaptive Controllers, Proc. Fourth Ann. Allerton Conf. Circuits and Systems Theory, pp. 8-16, 1994. (Conference proceedings) ISO 9126-1, Software engineering- Product quality Part 1: Quality model, 2001. J. Rubin, Handbook of Usability Testing, John Wiley, New York, 1994. J. Nielsen, Usability Engineering, Academic Press, 1993. J. Lewis, IBM computer usability satisfaction questionnaires: psychometric evaluation and instructions for use, International Journal of Human Computer Interaction, Vol. 7, No. 1, pp 5778, 1995. M. Donyaee and A. Seffah, QUIM: An Integrated Model for Specifying and Measuring Quality in Use, Eighth IFIP Conference on Human Computer Interaction, Tokyo, Japan, July 9-13, 2001. M. Porteous, J. Kirakowsky and M. Corbett, SUMI user handbook, Human Factors Research Group, University College Cork. N. Bevan, J. Kirakowaski, and J. Maisal, Proceeding of 4th International Conference on HCI, Stuttgart, Sept. 1991. N. Seliya, T. M. Khoshgoftaar, Software quality with limited fault-proneness defect data: A semi supervised learning perspective, published online pp. 327-324, 2007. NASA IV & V Facility. Metric Data Program. Available from http://MDP.ivv.nasa.gov/. R.J. Logan, S. Augaitis and T. Renk, Design of simplified television remote controls: a case for behavioral and emotional usability, Proceedings of the Human Factors and Ergonomics Society 38th Annual Meeting, 355-358, 1994. S. Basu, A. Banerjee, R. Mooney, Semi -supervised Clustering by Seeding, Proceedings of 19th International conference on

[2]

[3]

[4] [5]

[6] [7] [8] [9]

[10]

[11]

[12] [13]

[14] [15]

[16]

2011 Journal of Computing Press, NY, USA, ISSN 2151-9617