Software Ageing Measurement and Classification Using Goal ...

Science and Information Conference 2013 October 7-9, 2013 | London, UK

Software Ageing Measurement and Classification Using Goal Question Metric (GQM) Approach Jamaiah H. Yahaya, Zaiha Nadiah Zainal Abidin, Noorazean Mohd Ali School of Computer Science Faculty of Information Science and Technology Universiti Kebangsaan Malaysia Selangor, Malaysia Abstract—As indicated by earlier researches, software products behave in a manner that is almost similar to the process of human ageing. Just as human beings get old, it is believed that software too can age, and even though ageing is unavoidable, it is possible to understand the reasons for its occurrence so that steps can be taken to control its impact. Being a logical product, software does not age in the physical sense. However, in certain situations, the software loses its significance and quality to its surroundings. This occurrence can be compared to the process of ageing. The software ageing function can be expressed in terms of its significance, frequency of failure, technology, costs and so on. The software can be revived and the process of ageing postponed if these factors can be ascertained and distinguished. Inspired by earlier works concerning software certification and value, we have been guided to develop a software ageing model together with its associated links such as ageing factors and the rejuvenation index. In order to realise the creation of such a model, it is necessary to carry out further research with regard to measurement and classification, and to this end the Goal Question Metrics (GQM) approach has been selected.

Aziz Deraman Department of Computer Science, Faculty of Science and Technology, Universiti Malaysia Terengganu Terengganu, Malaysia ascertained and distinguished, then the software can be rejuvenated and its ageing postponed. It has been shown in earlier researches that the significance of the software at any point during its life is determined by its quality, and this characteristic is not present in the available software models and preservation processes. A substantial amount of the ageing that is encountered is attributed to the measurement of quality on the outside [2]. We have managed to detect the causes of software ageing and these are expounded in this paper. Furthermore, we also examine here the ageing measurement produced by us using the GQM approach. In the rest of the paper we discuss the research within the context of software quality and certification, as well as matters concerning software ageing and rejuvenation. A description of the software ageing measurement using the GQM is also presented in this paper, and the conclusion is given in the final section.

It has been noted in the field of software engineering that application software displays behaviour that is similar to ageing in human beings. Just like humans, software also ages and the process is unavoidable. However, it is possible for us to understand the reasons for the occurrence of ageing and thus measures can be taken to control its impact. Past research identified two categories of software ageing: 1) the type that is due to the inability of the products to adjust to the forces at work in the surroundings, and 2) the type that occurs as a consequence of modifications. Being a logical product, software does not age in the physical sense [1]. However, in certain situations, the software is losing its significance and quality to its surroundings. Such is the process of ageing.

II. RESEARCH BACKGROUND In the field of software engineering, software ageing is a term that is used to describe the gradual deterioration of the functioning or condition of the software with the progress of time. However, time is not the only cause of software ageing, which is also strongly influenced by the quality of the software and whether that specific software can retain its quality during the whole of its lifetime. As the quality of the software tends to deteriorate with time, it is necessary to rejuvenate it in order to enhance the software and sustain its quality, while at the same time manage the factors influencing ageing. It has been indicated in previous researches that certification is one way in which software ageing can be controlled. The procedure for certifying the software can be introduced at any point in its lifecycle in order to gauge its quality so as to be able to predict the deterioration of that quality [3][4].

The ageing process in software differs from that in humans in the sense that the former can be expressed in terms of various factors such as its significance, frequency of failure, technology, costs and so on. Software rejuvenation encompasses the construction of the software and the characteristics of the software that can be adapted and revised; the changes that must necessarily take place in vibrant surroundings so as to imbue the software with adaptability and to maintain its ‗youth‘. If the software ageing factors can be

A. Software Quality and Certification There has been a rising need to gauge the quality of software by means of the self-assessment or user centric assessment method. Users require assessment parameters and measures of software quality in order to evaluate the software merchandise and items that they are utilising within their setting. The user centric assessment process is one in which the prerequisites and constraints involving the final users of a particular software item are subjected to intense scrutiny at

Keywords—software ageing; Goal Question Metrics (GQM)

I.

INTRODUCTION

160 | P a g e www.conference.thesai.org

Science and Information Conference 2013 October 7-9, 2013 | London, UK

every point of the process. Currently, the quality model needs to be uncomplicated, precise and functional so that it can be assessed by non-experts, consumers, purchasers, designers or investors. This is linked to the common meaning of quality as ―fitness for use‖ and ―conformance to requirements‖. Fitness for use is often taken to refer to features such as practicality, ease of use and maintenance, and the ability to be used repeatedly; whilst ―conformance to requirements‖ signifies that the software is worth something to the user. Very few of the quality models of the past include or focus much on these requirements[4][5]. The PQF model highlights human and behavioural (or technical) characteristics. These give a more stable assessment of human needs or for meeting the expectations of users [3]. Certification normally refers to the procedure whereby a value is attached to an item, person or organisation, and this value is validated by the issuance of a certificate, which can be produced as evidence of its authenticity. A software certification as a fact sheet presenting the proven external behaviours of the software (and possibly proven internal behaviours as well) [4]. Stanfford and Wallnau also share the same view of certification as a procedure whereby the value given to a particular asset is validated by the issuance of a certificate which can be produced as evidence of its authenticity. This is the latest software engineering theory which is fast gaining recognition in the software industry [6]. The IT Times referred to Good Software as a quality certification programme designed by the Koreans and which has been in use over the past decade [7]. At the moment, Malaysia is in the process of designing its own Malaysian Certification Programme for various professionals and academicians from a number of establishments and businesses. Such a certification programme will lend significant value to the quality of a software organisation, especially in regard to its resilience and credibility. Most of the software certification methods depend mainly on official validation, professional evaluations, and designer appraisal and software measurements to ascertain the quality of an item. Another method involves measuring quality against the ISO9126 model [4][8][9][10]. Some examples of this method are the Good Software mentioned in the IT Times, the Requirement-driven Workbench and the SCM-Prod [7][9][11]. Such models are appropriate for the normal evaluation of software with constant features such as portability, usability, dependability, maintainability, practicality and competence. The above mentioned studies are mainly aimed at validating software items from the viewpoint of designers, dealers and examiners and pay scant attention to .the viewpoint and participation of the user. Earlier studies conducted by us concerning software product certification applications have proven that our SCMProd model, which uses the product quality method for software certification, is suitable for maintaining the quality of the product during its lifetime. This model uses our PQF model as its standard of quality certification. Our software certification method pays more attention to the participation of the user in the evaluation and validation programme. Data concerning certification and quality from 2007 until 2011 were analysed and revealed that software measurements can

be used to constantly observe quality. The quality of the software can be determined at any point in its life cycle and therefore this can assist experts and designers to check the deterioration in the value and quality of the software. Once the software starts losing its value and quality in the environment it is deemed to be shifting into the ageing phase of its life cycle. Therefore, it is vital that this ageing phase be checked and prolonged by keeping the risks and conditions to a minimum. By carrying out the certification procedure on specific software items some important information can be acquired as to the quality of the software in the environment, which can then be linked to the ageing phase in the life cycle [12]. B. Software Ageing and Rejuvenation Issues Past researches, investigated the issue and vocabulary of software ageing, which concern the gradual depletion of operating system reserves, data corruption and the accrual of statistical errors. Some examples of such software ageing include the bloating and leaking of memory, restricted filelocks, storage space, etc. This study analyses the ageing of the Linux OS software [13][14][15]. Some researches concentrated on operating systems, software and hardware systems in their earlier studies [14][15][16]. A simple software rejuvenation model was designed and it comprised figures for the transition state of a system software [15][17]. A fault tolerance method utilising a range of settings to lessen the impact of ageing on a software system was suggested by Grottke et al. This study concentrated on the impact of ageing on a system software that included the internal condition of the system and trends with regard to the consumption of resources, and also researched further into the appearance of bugs connected to ageing [13][14]. Another suggested method and perspective on software ageing is to compare it to the ageing process in humans. Software seemed to age in the same way as human beings with the passage of time. As such, it can be deduced that the factors that influence human ageing will appear over time. Software may not age in the physical sense, but under certain conditions it may gradually lose its significance and value to the environment [1]. In such a case the software is said to be ageing [18][19]. There are two types of software ageing: 1) software ageing that is due to the failure on the part of the owner of the product to alter the product so as to enable it to adjust to various needs and a vibrant environment, and 2)software ageing that is the outcome of alterations that are made[19][20]. Software ageing is comparable to human ageing in terms of the following steps and causes: inactivity, ill-informed surgery and kidney failure [1]. At the same time an earlier study revealed that software failure today can be traced mainly to software error (40%), hardware error (15%), human error (40%) and others (5%). Software ageing is crucial in many applications software as it has been proven that the failure of the software is mainly caused by software error [21]. Software quality and software ageing are tightly intertwined as the former may serve to extend the age of the software. The quality of the software can be maintained within a particular setting, the ageing of the software may be

161 | P a g e www.conference.thesai.org

Science and Information Conference 2013 October 7-9, 2013 | London, UK

prolonged, while at the same time a system, procedures and markers can be put in place to sustain this. Software rejuvenation is a pre-emptive way of handling software ageing [2][3]. Therefore, it is highly important and necessary to design software ageing measurement model and a rejuvenation method. In this method, the ageing factors will be used to develop a rejuvenation guide by identifying and controlling the factors that prevent ageing. In the early days of software development, numerous methods and techniques were advanced to determine and evaluate software quality. Previous study mentioned that the precise internal measurements that were used with complicated and large programmes in the earlier years are no longer required with the technology that is available today, while the external measurements are gaining in importance and significance. The external measurements are obtained by determining the software quality features through the experiences of those who design and use the software. These individual, external features will be linked to the measurement of the internal features to enable an impartial judgment to be made of these features [2]. The connection between constant software measurements and software ageing was explored and the promising result has been reviewed in an earlier section. In addition, software can be categorised applications into two well-defined groups (littleAging and bigAging) according to constant software measurements with regard to ageing principles. This research is incomplete in that further studies must still be carried out to examine the effects of software ageing on software measurements [13][14]. III. SOFTWARE AGEING MEASUREMENT Preliminary studies reveal that some of the causes of software ageing are linked to a changing environment, operational failure, technological challenges (hardware and software), competition, commercial compatibility, etc. In order to sustain and retain the high quality of the software through the rejuvenation process several measures should be taken including maintenance (to correct, adapt, perfect and prevent), reorganisation, repositioning and redesigning. These measures should be performed throughout the life cycle of the software or until a new system is introduced to replace the software [22]. While the software is being designed, the system requirements will most probably not remain the same because the environment is constantly changing. As such, the final software that is produced will not meet its requirements. If software is to be practical it must be able to adapt to the environment at any point in its life cycle. This is one of the rules or observations of evolution dynamics that can be applied to the issue of software ageing and its related measurement. The other rules of evolution dynamics are continuous growth, increased complexity, organisational stability and feedback system. These rules will be taken into consideration in order to determine the factors that affect software ageing and will be applied in the construction of an anti-ageing model for application software [23]. In the same way, in software engineering and computer studies, especially in our study group, we intend to observe and implement the issue of ageing in application software.

Although software ageing is an innovative concept, the preliminary study carried out earlier has indicated that the issue is a significant one that needs to be investigated and examined. It might be beneficial to understand human ageing if it can be employed in the field of software ageing. Several factors have been identified as being related to software ageing [12]. An earlier study by us has revealed that some significant ageing factors that have been obtained from the industry include advancement in requirements, technological challenges, commercial compatibility and constancy, design complications, deteriorating quality and changes to the environment. Around 30 people from various backgrounds in the industry participated in this study, which was carried out in Malaysia. The results from this study will be used as a guide for the main objective of this research. A more in-depth study has been carried out to distinguish the other significant software ageing factors. A. Software Ageing Factors From an extensive study about software quality, software certification and software maintenance, we have found that there are four main factors that influent the software ageing. They are functional factor, environment factor, human factor and history factor. Functional factor is related to the usefulness of software. For example, if software can no longer function as it used to, the software is considered as ageing. The second factor is environment factor. Environment factor is the external factor involving accessories, alternative and the change of technology. For example, software is considered as ageing because of environment factor if it cannot accommodate the need for new technology in its environment. The third factor of software ageing is human factor. In human factor we found that the related sub factors are environment, staff, user, education, training and popularity. For example, a software is considered as ageing because of human factor if its users are using it less frequently because they prefer to use other alternative software that is more popular. Finally, the fourth factor of software ageing is history. The aspects that should be considered in history factor are the acquisition, time to buy, time to produce, technology and the age of software. For example, a software is considered as ageing in related to history factor if software is originally acquired because of company policy and the users are using it less frequent because of the technology that supports the software is outdated. The main ageing factors above were identified through brain storming approach. The factors are functional factors, environment factors, human factors and history factor. The next step is to validate the factors. This will be done by conducting a survey which involves respondents from various industries and sectors. During the survey and questionnaire design, we have to classify the factors using hierarchical or top-down method. In this study, we will adopt the Goal Question Metrics (GQM) approach as our classification method. In the next sub-section, we will explain in detail how GQM is applied in this study to produce a classification of software ageing factor systematically and helps in measuring metric factors involved.

162 | P a g e www.conference.thesai.org

Science and Information Conference 2013 October 7-9, 2013 | London, UK

B. Using GQM to measure software ageing factors In this study we use GQM approach to measure the factors of software ageing. GQM focuses on the data gathering process and support the interpretation process [25]. In basic GQM, there are three levels of GQM structure. The first structure of GQM is the conceptual level or known as goal which specifies the object, purpose, quality focus, viewpoint and environment of the study. The second level is operational level that contains all sets of questions that relate to the goal. The third level of GQM is measurement level (metrics). By referring to Fig. 1, we can see that goals contribute to the creation of several sets of questions. Generated questions also contributed to the metric to be used as data for the questions that have been created [24]. In our study, we adopt the basic GQM in developing a set of questions to validate the software ageing factors. For the first level known as goal, includes functional factors, environment factors, human factors and history factors. In order to know the level of validity of every factor, a set of questions are constructed in operational level. In this study, we define nine sets of objectives in operational level that contains sets of questions. Every question is then grouped into a set of metrics. In the metric level, it contains the data needed to answer the questions. To answer several questions, the same metric can be used. Fig. 2 shows the GQM model for software ageing classification and measurements. In fig. 2, the main ageing factors are at level 2 which associated with the conceptual or goal level. The factors are functional, environment, human and history. At operational or objective level which is the third level in GQM, we propose nine objectives as shown in the following:1) To determine (functionality) dynamic of the software application over time (can adapt with any changes and current technology) 2) To determine the stability of the software related to SMI (software maturity index) (volatility of maintenance activity)

3) To determine the popularity of the software as compared to other similar products 4) To determine the age and technology used for the software 5) To determine the rationale of having the software (cost/popularity/technology) 6) To determine the level of education level of users and support staff 7) To determine the level of training given related to the software 8) To determine the level of adaptation to current trend (technology/ devices/ user interfaces) 9) To quantify user’s satisfaction level in using the software The nine objectives are then mapped into the goals at conceptual level as shown in fig. 2. The objectives (O1 to O9) are then broken down into several metrics. There are 27 metrics which classify from M1 till M27. Finally, the GQM model for software ageing and measurements is used as our guideline to design and construct the questionnaire for this study. IV. CONCLUSION This paper has presented and discussed the issues in software ageing and measurements. This work was motivated from previous works in software quality and certification. The proposed model of software ageing is intended for measuring the age of the software and delay the ageing by introducing the rejuvenation index and processes. Four main ageing factors have been identified and mapped into nine objectives and twenty seven metrics. The classification is implemented using GQM approach which will lead to systematic questionnaire design. Currently we are at the stage of finalizing the questionnaire before it is readied to be distributed. The findings from the survey will become the input to our proposed ageing model, Software Ageing Measurement Model (SAMM).

Fig. 1. Basic structure of GQMSource: Gray &MacDonell (1997)

163 | P a g e www.conference.thesai.org

Science and Information Conference 2013 October 7-9, 2013 | London, UK SOFTWARE AGEING MEASUREMENT MODEL (SAMM)

Conceptual Level (GOAL)

C2 Environment (Environment/ Accessories/ Alternative/ Technology)

C1 Functional (Application Domain)

C3 Human (Environment/ Staff/ User/ Education/ Training/ Popularity)

C4 History (Acquisition/ Time to Buy/ Time to Produce/ Technology/ Age)

Operational Level (Objectives) O1

O2

O3

O4

O5

O6

O7

O8

O9

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M17 M18 M19 M20 M21 M22 M23 M24 M25 M26 M27 Quantitative Level (Metrics)

Fig. 2. Structure of GQM in software ageing factor

ACKNOWLEDGMENT This research is funded by Fundamental Research Grant Scheme, Ministry of Higher Education Malaysia. REFERENCES D.L. Parnas, ―Software aging,‖ Proceeding of ICSE '94 The 16th International Conference on Software Engineering, 1994. [2] J.H. Yahaya and A. Deraman, ―Measuring the unmeasurable characteristics of software product quality,‖ International Journal of Advancements in Computing Technology (IJACT), vol. 2(4), pp. 95106, 2010. [3] J.H. Yahaya, A. Deraman, and A.R. Hamdan, ―Continuosly ensuring quality through software product certification: A case study,‖ Proceedings of the International Conference on Information Society (iSociety 2010), London, UK, 2010. [4] J. Voas, ―Certifying software for high assurance environments,‖ IEEE Software, pp.22-25, 1999. [5] I. Tervonen, ―Support for Quality-Based Design and Inspection,‖ IEEE Software, pp. 44–54, 1996. [6] J. Stanford, and K. Wallnau, ―Is third party certification necessary?,‖ Proceeding of the 4th ICSE Workshop on Component-Based Software Engineering: Component Certification and System Prediction, 2001. [7] IT Times, ―30 Korean Software Worthy of Global Recognition in 2012,‖ [online], [Retrieved January 22, 2013], http://www.koreaittimes.com/story/15607/30-korean-software-worthyglobal-recognition-2012, 2011. [8] D. Welzel, and H. Hausen, ―Practical concurrent software evaluation for certification,‖ Journal System Software, vol. 38, pp.71-83, 1997. [9] S.W. Lee, R.A. Ghandi, and S. Wagle, ―Towards a requirements-driven workbench for supporting software certification and accreditation,‖ Proceeding of the Software Engineering for Secure Systems 2007 SESS‘07 IEEE,[online]. [Retrieved February 17, 2012), http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4273334, 2007. [10] P. Heck, M. Klabbers, and M. Eekelen, ―A Software Product Certification Model,‘ Software Quality Journal, vol.18, pp. 37-55, 2010. [1]

[11] J.H. Yahaya, A. Deraman, and A.R. Hamdan, ―Software certification model based on product quality approach,‖ Journal of Sustainability Science and Management, vol. 3(2), pp. 14-29, 2008. [12] J.H. Yahaya and A. Deraman, ―Towards a Study on Software Ageing for Application Software: The Influential Factors,‖ IJACT: International Journal of Advancements in Computing Technology, vol. 4(14), pp. 5159, 2012. [13] D. Cotroneo, R. Natella, and R. Pietrantuono, ―Is software aging related to software metrics?,‖ Proceeding of the 2nd IEEE International Workshop on Software Aging and Rejuvenation (WoSAR 2010) in conj. with International Symposium on Software Reliability Engineering (ISSRE) 2010, San Jose CA, USA, 2010. [14] D. Cotroneo, R Natella, R. Pietrantuono, and S. Russo, ―Software aging analysis of the Linux operating system,‖ Proceeding of IEEE 21st International Symposium on Software Reliability Engineering IEEE Computer Society Washington, DC, USA, 2010. [15] B. Wah, ―Software Aging and Rejuvenation,‖ Wiley Encyclopedia of Computer Science and Engineering, John Wiley & Son, Inc, 2008. [16] M. Grottke, Jr. R. Matias and K.S. Trivedi, ―The Fundamentals of Software Aging,‖ Proceedings of the 1st International Workshop on Software Aging and Rejuvenation, IEEE, 2008. [17] Y. Huang, C. Kintala, , N. Kolettis, and N.D. Fulton, ―Software rejuvenation: Analysis, module and applications,‖ [onlie].IEEE. [Retrieved February 9, 2012) http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=466961, 1995. [18] A. Deraman, ―Software certification: The way forward (keynote),‖ Proceeding of The 5th Malaysian Software Engineering Conference (MySec2011), Johor Bharu, 2009. [19] A. Deraman, ―Memburu Kualiti Perisian (Inaugural Speech)‖ UKM Publisher.ISBN 978-967-942-967-1.A, 2010. [20] C. Constantinides and V. Arnaoudova, Prolonging the aging of a software systems. [online].Encyclopedia of Information Science and Technology, Second Edition (8 Volumes). [Retrieved January 18, 2012]. http://www.igi-global.com/viewtitlesample.aspx?id=14041, 2009. [21] T. Thein, ―Proactive software rejuvenation solution for software aging,‖ [online], [Rretrieved February 9,2012]. http://eurosoutheastasiaict.org/wp-content/plugins/alcyonis-event-agenda//files/ThandarThein.pdf, 2011.

164 | P a g e www.conference.thesai.org

Science and Information Conference 2013 October 7-9, 2013 | London, UK [22] H.V. Vliet, ―Software Engineering: Principles and Practices,‖ Chichester: John Wiley & Sons, 2008. [23] Sommerville. Software Engineering, 9th edition, Pearson Education: Boston, 2011. [24] A. Gray, and S.G. MacDonell, ―GQM++ A Full Life Cycle Framework

for the Development and Implementation of Software Metric Programs,‖ Proceeding of ACOSM, pp. 22-35, 1997. [25] V.R. Basili and H.D. Rombach, ―The TAME Project: Towards Improvement-Oriented Software Environments,‖ IEEE Transactions on Software Engineering, vol. 14(6), pp. 58-773, 1988.

165 | P a g e www.conference.thesai.org