Software and System Erosion Systems
Pradeep Tomar and Gurjit Kaur
SOFTWARE and SYSTEM EROSION Software erosion or software rot is the gradual degradation of software performance and responsiveness over time which ultimately results in software becoming faulty or unusable in a productive environment. Software erosion is generally categorised into two types: • Dormant erosion – This is the type of software erosion which occurs when the software is not used too frequently which eventually results in the transformation of the environment in which the software operates. The gradual variation in the rest of the software application and user needs also contribute to its erosion. • Active erosion – This is the type of software erosion which occurs when the software undergoes continuous modifications and changes to its design and architecture. Though most software do require constant upgradation but this ultimately leads to an evolution process which makes the program differ from its original design. As continuous evolution goes on the original program logic may get invalidated, presenting new bugs. Factors Responsible for Software and System Erosion There could be several factors which are responsible for software erosion at a particular time. It is rarely a case when solely one factor is held responsible. Some of the factors include the transformation of the environment in which the software operates, degradation of compatibility among different sections of the software itself, and the appearance of bugs in rarely used code. The various software erosion symptoms or factors have been presented in later chapters for clear understanding of the causes behind software erosion. Also the maintenance actions corresponding to each symptom have been presented which can be used under various erosion circumstances.
NEED FOR SOFTWARE MAINTENANCE Software maintenance is a process of modifying software product after it has been released to rectify bugs, improve performance and other attributes associated with it. It is one of the most important phases of Software Development Life Cycle (SDLC) which aims to preserve the life of the software for as long as possible with minimal problems. The need for maintenance arises once the software begins to differ from its original requirements for which it was intended to fulfil. As this happens, the software also begins to differ from its original design and architecture. It is at this point when the performance of the software degrades and its efficiency decreases, thus resulting in its erosion. The continuous use of eroded software is not recommended as it will hamper the productivity. Therefore it becomes necessary to maintain software in long run. In a software lifetime, the type of maintenance activity carried out on software may differ on its nature. Some of the maintenance types are discussed below: • Adaptive maintenance – This is the type of maintenance which is carried out when the software has to deal with changing environment in which it operates. A Set of updations needs to be carried out to maintain coordination between the environment and the software. • Corrective maintenance – This is the type of maintenance which is carried out when the software which has been released is reported with bugs and errors discovered by users and testers. • Perfective maintenance – This is the type of maintenance which is done to preserve the life of the software which makes it usable over a long period of time. It addresses the new user requirements and aims to improve the performance and reliability of the software. • Preventive maintenance – This is the type of maintenance which is done to secure the future needs of software. The objective is to address those issues which are not major concern at present but may cause serious issues in future. 2.3.1 Maintenance Models – These models play an important role as most of the time maintenance experts are unaware of specifications, architecture, requirements of a software system. Traditional models are not of much use to maintenance team. Some of the models are discussed below. • Quick-fix model - Quick-fix model is a very simple model of software maintenance. It is based on ad hoc approach which first identifies the defect and then developers fix them. Here developer is waiting for the problem to occur and then necessary action is taken to fix it. The main advantage with this model is that, it takes very less time and less cost as compared to other models. This model is useful only in case of small projects. In this model all the changes are supposed to be done at source code of the project without considering for future planning. In the software industry time is the most important factor because sometimes customers need modified software as early as possible and they can’t wait for long time. In this model generally software is developed without specification or design of the projects.
It consists of two phases:
Build code Fix
• Iterative Enhancement model - This model is basically designed for process model, where the entire requirements are supposed to be defined as early as possible and functionality of the final software is fully understood. This model is very useful for maintaining a software product because several cycles are conducted in iterative fashion. This model has been proposed originally for a development model but later on it is well suited for maintenance of software also. This model is basically a three phases, namely:
Analysis of software system
Classification of proposed modifications
Redesign and implementation of requested modifications
In the first phase i.e. Analysis of software system, first requirements is analyzed before the maintenance process is supposed to be start. Then in the second phase, proposed modification is classified based on complexity level, technical issue. At the last phase, redesign the software and implement the modification request. One thing keeps in mind that, at the end of each phase, the documentation should be updated. The objective of this model is to reduce the complexity and try to maintain good design for the software. The documentation of each software life cycle (requirements and specification, design, coding, testing etc.) is modified at highest level. This model also supports reuse of module to other module and incorporates changes in the software totally depends on the analysis of the existing system.
FUZZY LOGIC: AN APPROACH Uncertainty is inherent and unavoidable in software development processes and products. To certify the understanding of the software product is no longer a question of “Yes” and “No”, but a question of “to what degree”. Fuzzy logic is the ideal tool to model this process. Fuzzy model is build based on the prior knowledge of software components and the history record of the components from the experts. The difference lies in the fact that in fuzzy logic in spite of assigning the subjective probabilities to the parameters, each of the input and output parameters are linguistically defined. Linguistic variables are central to fuzzy logic manipulations. The linguistic term is false when the value of the assigned variable is 0 and it is true when the assigned value is 1. Relative information is conveyed by linguistic variables used in day to day speech about an object which is under consideration. In order to understand fuzzy logic it is important to discuss fuzzy sets. A fuzzy set can be defined as a collection of elements in a universe of information where the set boundary is not clearly distinguishable, in fact it is vague and ambiguous. In the fuzzy set, the elements of universe of discourse can belong to the fuzzy set with any value between 0 and 1. This value is called the degree of membership. The degree of truthfulness is high when value of element is near 1. This is called membership function which is unique to fuzzy set, as it assigns the membership degree to each element of universe of discourse.
Fuzzy Inference System The traditional idealistic mathematical approach has been improved to accommodate partial truth by the Introduction of fuzzy set theory by Professor LotfiA.Zadeh, [20], in1965. Fuzzy logic provides a convenient way to represent Linguistic variables and subjective probability. The motivation and justification for fuzzy logic is that the linguistic characterizations are less specific than the numerical ones. Most situations in the world require crisp actions. These actions are arrived by processing fuzzy information in figure. Fuzzy logic is used to provide means of inferring the fuzzy information to produce crisp actions. Fuzzy logic provides the tools for: • Fuzzification • Inference • Composition • Defuzzification
Fuzzification - Fuzzification is the process of making the crisp quality “fuzzy”. This allows addressing uncertainty in any parameter due to imprecision, ambiguity or vagueness. In artificial intelligence, the most common way to represent human knowledge is in terms of natural language i.e. linguistic variables. Depending upon the data and uncertainty, the inputs and the output parameters are fuzzified in terms of linguistic descriptors such as high, low, medium, and small to translate them into fuzzy variables. Therefore, fuzzy sets for the inputs parameters and the required single output parameter are formulated based on the expert’s knowledge and experience in the particular domain. Linguistic descriptors like High, Medium, Low, Small, Large are assigned to a range of values for the output and for the input parameters. Since these descriptors form the basis for capturing expert input on the impact of input parameters on the number of faults, it is important to calibrate them to how they are commonly interpreted by the experts providing input. Referring to a variable as High, should evoke the same understanding among the experts.
Fuzzy sets for the inputs and required single output are formulated based on the expert’s knowledge and experience in the particular domain as per the development standards of the organization.
Membership values for the input parameters are calculated from the fuzzy sets drawn by the experts. These fuzzy sets form the basis for calculating membership values as per the specification of the individual project. Inference - Having specified the expected number of faults and its influencing parameters, the logical next step is to specify how the expected numbers of faults vary as a function of the influencing parameters. Experts provide fuzzy rules in the forms of if..then statements that relate expected number of faults to various levels of influencing parameters based on their knowledge and experience. Fuzzy processor uses linguistic rules to determine what control action should occur in response to a given set of input values. Rule evolution also referred as fuzzy inference, evaluates each rule with the inputs that were created from the process of fuzzification. Composition - The AND operator is used to combine the inputs logically to generate responses for output values for the inputs given. For each membership function the active conclusions are combined into a logical sum. A firing strength for each output membership function is computed. The fuzzy outputs for all rules are finally aggregated to one fuzzy set for various levels of consequent.
Defuzzification - The logical sums are combined in the defuzzification process to produce the crisp output. To obtain a crisp decision from fuzzy output, the fuzzy set, or the set of singletons have to be defuzzified. There are several heuristic methods, one of them is e.g. to take the centre of gravity. For the discrete case with singletons usually the mean of maximum method is used where the point with maximum singleton is chosen. Centre of gravity, calculates sum of the outputs and the corresponding membership function of the output fuzzy set and the weighted sum of the membership function. Formally, crisp value is the value located under the center of gravity of the area.
REVIEW OF LITERATURE OF SOFTWARE AND SYSTEM MAINTENANCE Hall et al. [1] explored some connections between several metrics and various demands in different maintenance fields. They proposed that software maintenance activities carry a good amount of cost with them and can occupy a major piece of share in the overall budget. The quality of software plays a major role in its integration and long term functioning. They worked more towards improving the quality of the code and kept a close eye on the ongoing research in software maintenance. They explored the possibility of assessing the quality of code, the amount of change that a software has gone through after initial releases, monitoring the quality of successive releases of software, the overall risk involved in bringing some variations to the source code, identifying that portion of the code which can be further improved or reused later, providing basis to review the changes made to the code. Basili et al. [2] put forward a theory that addresses the uncertainty in the maintenance process. Their main concern was to understand and predict the expenses of maintenance release of software systems. Their main goal was to draw out maximum efficiency from the next maintenance release in terms of quality and functionality. In their paper they documented the conclusions of a case study which established that incremental approach is a better approach to understand the distribution of effort in software maintenance release. They were successful in building predictive effort model for the same. The main difficulty which they properly dealt with was to maximise the functionality and efficiency of release bounded by resource constraints. In their paper, they talk about descriptive models of maintenance which helped to explain how effort is distributed across various maintenance releases in an efficient way. Hayes et al. [3] proposed a model to roughly estimate the efforts of humans involved across various maintenance activities. They succeeded in forming a model which estimated software maintenance efforts in person hours. The model was named as Adaptive Maintenance Effort Model (AMEffMo). It was found that various metrics such as number of lines of code changed and number of operators changed had a strong impact in the calculation of maintenance effort. Their work aimed to address the problem of estimation and cost of those projects especially where changes were made frequently. They developed a method that helps in predicting maintenance effort which varies. They also performed a study to determine metrics which were closely related to maintenance effort as measured in hours. They even used their past research experience to form a possible list of metrics that could play a major role in determining maintenance effort. After this they used their analysis to rank these metrics according to priority. Then these metrics were put to use collectively to build the model required to calculate maintenance effort. Finally they were successful in predicting two models. With the help of these two models, they showed that industry environment is more demanding as compared to university environment in terms of maintenance effort applied. Effort was also predicted correctly to a good extent by regression models which also served as good source of important information for managers and maintenance experts. However, this work also did not talk about software erosion metrics and corresponding maintenance actions. Zadeh [4] talked in detail about the fuzzy sets i.e. sets with un-sharp boundaries. These sets worked better in some cases as compared to traditional sets. He tried to take mathematical approach to study these sets. He applied union, complement, intersection, convexity etc. to study them in detail. He even proved a theorem of separation for fuzzy sets which are convex without requiring them to be disjoint. In contrast, the work of Vissagio [5] focussed particularly towards erosion metrics and maintenance actions. They put forward some of the erosion symptoms which were more common to legacy systems. Each symptom was measured by a set of metrics and the outcome of measurements suggested which maintenance actions should follow. The metrics provide a good way to keep a check on software systems and ensure that its quality does not degrade to such an extent that the most costly renewal actions then have to be performed to improve it. However, this work did not focussed on uncertainty involved in maintenance environment. S .Kumar Dubey [6] proposed a method to compare the maintainability of object-oriented software system. The inputs for the method were size, complexity, coupling and inheritance and he showed how these metrics affect the maintainability of the different software. He proposed a fuzzy based model to quantify maintainability of object-oriented software system. The model took object-oriented projects and evaluated its maintainability on the basis of some metrics. The value obtained by fuzzy model was validated by using analytical hierarchy processing technique. Ning et al. [7] made an effort to eradicate the problem of uncertainty by using fuzzy logic approach but this work ignored the recommended maintenance actions. Amrendra et al. [8] presented the idea of software maintainability. They proposed a fuzzy model for estimating software maintainability. They used some object oriented metrics like Adaptability, Complexity, Understandability, Document Quality and Readability for estimating the software maintainability using Fuzzy Logic. They also assumed some membership functions like membership function which are triangular, Trapezoidal Membership Function and Gaussian Membership function. According to them fuzzy logic based approach has several advantages over other techniques like Neural Network etc. They considered factors like Adaptability, Complexity, Understandability, Documentation Quality and Readability (RD) as inputs while maintainability was considered as output. Ghosheh et al. [9] provided study for new web application metrics used for estimating size, complexity, coupling and reusability. The metrics have been applied to two different web applications of the telecommunication domain. He attempted to provide an exploratory study for those metrics which aim to handle the maintainability of web applications. These metrics were based on Web Application Extension (WAE) for UML which would measure the following design attributes: size, complexity, coupling and reusability. His work provided subjective measurement of the metrics but does not provide an objective measurement. Hamdi et al. [10] proposed a fuzzy model for the maintainability of object-oriented software system. The inputs to the proposed model were some metrics like complexity, class, coupling, inheritance and number of children on which maintainability depends. They found the relationship between object oriented metrics and software maintainability to be very complex. Therefore, there was a good amount of scope and interest which can be put into research in developing advanced techniques which can predict the software maintainability by building suitable models. However, during maintainability prediction, uncertainty and inaccuracy not only enclosed the product quality attributes but also the association which is present between external and internal quality attributes. It is hinted that the reason for the same could be the presence of two sources of information which contributed in building the model: historical data and human experts. Therefore, they attempted to bring a solution to this by using fuzzy logic which handles inaccuracy and uncertainty to build an efficient maintainability prediction model. Castillo et al. [11] took forward the work of Vissagio by handling the uncertainty in the maintenance through the use of fuzzy rule based system which gives the best set of maintenance actions for the erosion symptoms detected. They proposed a set of erosion symptoms which help to determine the cause for the degradation of software. Set of erosion metrics were also presented which help to measure or quantify those symptoms. The use of Fuzzy Inference System (FIS) eradicated the problem of uncertainty in decision making. They established fuzzy rules with the help of maintenance experts which helped to determine the maintenance action to be followed corresponding to each erosion symptom.
