Decision Driven Risk Measurement Model to Quantify Reengineering Risk in Stakeholder Perspective of Legacy System

Er. Anand Rajavat

1Department of Computer Science & Engineering SVITS, Indore, M. P., India anandrajavat@yahoo.co.in

Dr. (Mrs.) Vrinda Tokekar Information Technology

IET (DAVV), Indore, M. P., India Vrindatokaker@yahoo.co.in

ABSTRACT- In today’s risk sensitive business environment, software has become the most valuable asset for organization. The success of any organization severely depends on the quality of their legacy systems so it is important to put more research effort in obtaining a better understanding of legacy system problems and their solutions. During the last several years, reengineering gained increasing interest. However, it incurs some risk overhead due to widespread deviations it requires in majority of cases. Effective reengineering clearly indicates the need for resolution of reengineering risk. We present a risk measurement model to measure comprehensive impact of different risk components materialize in stakeholder perspective of legacy system. The result is used to take decision about evolution of legacy system.

Keywords- Reengineering, Risk Engineering, Measurement

I. INTRODUCTION For many organizations, the competitive field has

been restructured significantly during the last decade. Many leading organizations have therefore launched large-scale efforts to deliver greater customer value by "reengineering" their legacy systems [1] [2].

In recent years software reengineering has emerged as a dominant system evolution technique which helps in effective cost control, quality improvements and time and risk reduction. The reengineering processes generally focus on the increased productivity and quality of the systems. However research shows those risk factors of reengineering process and their impact on software quality causes reengineering efforts to fail [3-6].

Proposed work measures total impact of various risk components apprehensive with stakeholder perspective of legacy system. We first measure risk impact of specific risk component for stakeholder perspective of ReeRisk framework [2]. A variety of measurement metrics is used to measure impact of individual risk component in reengineering process. Finally a pentagram model [7] is used to compute comprehensive impact of all the risk components for stakeholder perspective.

II. RELATED WORK As with any engineering discipline software

reengineering also requires effective risk measurement mechanism to make better decisions .An appropriate risk measurement process will raise success rate of reengineering strategy used to revolutionize any legacy system.

Geoffrey G. Roy in [8] provides a brief introduction to the concepts of risk management for software development projects [9] and giving an overview of a

new risk management framework called ProRisk. M. S. Camara in [10] proposes a structured methodology for risk management in the Business Process Reengineering (BPR) sub-project of ERP implementation. The aim of work is to focus on organizational changes. P.K. Suri in [11] provides a quantitative means to assess the risk associated with software development. Whereas Paul R. Garvey in [12] suggest how individual technical performance measures may be combined to measure and monitor the overall performance risk of a system.

Research shows that most of the risk measurement

models are static and only mark specific risk components. Henceforth there is a need of a consolidated reengineering risk measurement model to measure overall impact of all reengineering risk components in the evolution process of legacy system.

III. STAKEHOLDER PERSPECTIVE RISK MEASUREMENT MODEL

The purpose of stakeholder perspective risk measurement model is to design quantifiable metrics for the evaluation of legacy system. As a final point model is able to design mean opinion score board to support decision making process.

Figure 1 STAKEHOLDER PERSPECTIVE PENTAGRAM MODEL

As shown in Figure 1 stakeholder perspective measurement model is presented through using a pentagram diagram. The total impact of each risk component is measured based on the results of their metrics during measurement process [13-15] .Let us assume: the measurement results of each risk component is a value from 0 to 1. The value “1” indicates the maximum value for each risk component, and “0” indicates the minimum value. The area of the pentagram is used as the measurement of overall impact of five risk components. Clearly, the smallest value of this pentagram area is 0, and the maximum value is

978-1-4673-1989-8/12/$31.00 ©2012 IEEE

approximately 2.4. As the pentagram consists of five triangles, the area of each triangle can be computed as 0.5 * L1 * L2 * Sinα where L1, L2 represent the sides of the triangle and α represents the 72-degree angle between the two sides. The term TICSR, TIPR, TISR, TIUR, and TITR in Figure 1 are used to represent the five risk components of model respectively. Total Risk Impact (TRI) of all risk components from infrastructure perspective of legacy system can be computed as below:

Where a represents TICSR, b represents TIPR, c

represents TISR, d represents TIUR, e represents TITR. The five most important risk components of

stakeholder perspective are presented in Table 1. Table 1 Most Important Measure

IV. MEASUREMENT METRICS

In this section, we describe the measurement metrics used to measure impact of each risk component represented by each side of the pentagram model.

A. Communication strategy risk component Communication strategy risk measurement model

measures, process for exchange of information and opinion of individuals, groups, and organization on communication process. Identification of communication strategy risk consider medium and approach of communication as well as identify different

factors for communication gap between stakeholders. [16].

We identified the key measures that will affect overall impact of communication strategy risk component and a measurement metrics is developed to compute total impact of communication strategy risk component (TICSR). Impact of each measure can be calculated by using a scale value shown in table 2 which represents to what extent users of legacy system and developers of target system agree or disagree for respective measure. If we use a scale of 0 (strongly agree) to 1 (strongly disagree) then we can get the scale value for each measure by looking at the answers given by users of legacy system and developers of target system.

Table 2 Assessment Measure of CSR

Where X represents scale value given by legacy

system users & Y represents scale value given by developers of target system and I represent number of measures

B. Personal risk component Personal risk measurement model identify and

measures comfort ability of personals both users of legacy system and developers of target system with the system evolution objectives through reengineering. It involves job matching, team building, moral building, schedule and financial aspects of system evolution at personal and organizational level [17].

Table: 3 Assessment Measure of PR

Once we have identified the key measures a

measurement metrics is developed to compute total impact of persona risk component (TIPR).

Impact of each measure can be calculated by using a scale value shown in table 3 which represents to what extent users of legacy system and developers of target system agree or disagree for respective measure. If we use a scale of 0 (poor) to 3 (good) then we can get the scale value for each measure by looking at the answers given by users of legacy system and developers of target system.

Where X represents scale value given by legacy

system users & developers of target system and I represent number of measures

C. Specialization risk component Specialization risk measurement model measures

the overall technical and development expertise and experience of the software reengineering that will be involve in reengineering process. Specialization risk measurement model involves job matching, experience, skill level, schedule, and organizational change policy, administration & financial support as well as user perceptions of system evolution at personal and organizational level [18].

Table: 4 Assessment Measure of SR

Once we have identified the key measures a

measurement metrics is developed to compute total impact of specialization risk component (TISR).Impact of each measure can be calculated by using a scale value shown in table 4 which represents to what extent users of legacy system and developers of target system agree or disagree for respective measure. If we use a scale of 0 (poor) to 3 (good) then we can get the scale value for each measure by looking at the answers given by users of legacy system and developers of target system.

Where X represents scale value given by legacy

system users & developers of target system and I represent number of measures

D. User Risk component User risk measurement model identify and measure

user associated risk factors which includes user resistance to change, conflict between users, unfeasible user commitment and negative attitude towards the evolution task.

A set of criteria is used to evaluate present user involvement system. User involvement system considers a range of different elements of user involvement to evaluate existing user involvement process [19]. The criteria encompass nine dimensions of user involvement shown in table 5

Table 5 Dimensions of User Involvement

An assessment can be made for each criterion

according to the organization. Assessment measure presented in table 6 is used to compute total impact of user risk (TIUR) component.

Table 6 ASSESSMENT MEASURE of UR

E. Team risk component

Team risk measurement model measures team-oriented activities of customer and developer. Identification of team risk requires considering shared product vision, target results, and objectives of organization. Team risk identifies and measures the attributes of organizational structure and operational activities for the evolution of legacy system throughout all the phases of reengineering life-cycle, such that all individuals within the organizations, groups, departments, and agencies directly involved in reengineering are participating team members[20] [21].

For the measurement of team risk component

important measures and corresponding scale values are shown in table 7.

Table 7: Important Measures of Team Risk Component

Once we have identified the key measures and assign scale value to each measure a mean opinion score board shown in table 8 is used to check team effectiveness and total impact of team risk component.

Table 8: Mean Opinion Score Board for Team Risk

V. EXPERIMENT AND ANALYSIS The objective of this experiment is to check the

exactness of the mentioned risk measurement model for stakeholder perspective of legacy system and compare the result of two legacy software of the same scenarios i.e. library management system. The two different legacy library management systems are used to check the correctness of proposed measurement model. The total impact of five identified risk is calculated for each legacy library management system using different measurement metrics for respective risk components.

Applying pentagram model to five risk components we have the following results as shown in table 9.

Where LS1 represents legacy system 1 LS2 represents legacy system 2 TRI Total Risk Impact Table 9 Result

Based on the TRI values of two legacy library

management system the measurement results for both systems i.e. LS1 and Ls2 tests are shown in Figure 2. It is clear that the TRI of LS2 (Right) is higher than the TRI of LS1 (Left).

Figure 2 Comparative analysis

A mean opinion score represented in table 10 is used to quantify and predict the judgment based on total impact of reengineering risk from stakeholder perspective of legacy system.

Table 10 Mean opinion score

We give comparative TRI values for LS1 and LS2

with the mean opinion score. The mean opinion scores and the corresponding measurement model based impact values are shown on the table 10. It shows that reengineering is successful if the TRI value is less than or equals to 1 and the values higher than this level required massive risk engineering or tends to reengineering failure.

VI. CONCLUSION Reengineering is the opportunity to migrate

legacy system towards an evolvable system in a disciplined manner. However the success of large reengineering project depends to a great degree on proper insights of different reengineering risk from system, managerial and technical domains of legacy system. In this paper, we evaluate comprehensive impact of reengineering risk arises from stakeholder perspective of legacy system using pentagram model. Finally to check the correctness of mentioned stakeholder perspective risk measurement model we compare Total risk Impact TRI of two legacy system of the same domain. As a final point founded on the experimental result a mean opinion score board is developed to take decision about when evolution of a legacy system through reengineering is successful. REFERENCES [1] Ransom, J,” A method for assessing legacy systems for

evolution”, Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering, PP. 128 - 134, 1998.

[2] Anand Rajavat, Vrinda Tokekar, “ReeRisk –A Decisional Risk Engineering Framework for Legacy System Rejuvenation through Reengineering”, Published in Proceedings of Second International Conference on Recent Trends in Information, Telecommunication and Computing – ITC 2011 by Springer LNCS-CCIS, March 10-11, 2011 in Bengaluru, India, CNC 2011, CCIS 142, pp. 152 – 158, 2011, © Springer-Verlag Berlin Heidelberg 2011.

[3] Ransom J., Somerville I., Warren I. ,” A Method for Assessing legacy systems for evolution,” in Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering, 1998,ISBN: 0-8186-8421-6, Digital Object Identifier : 10.1109/CSMR.1998.665778

[4] Byrne, E.J. Gustafson, D.A.,” A software re-engineering process model”, in Proceeding of, Sixteenth Annual International Conference on Computer Software and Applications, Digital Object Identifier: 10.1109/CMPSAC.1992.217608 , ISBN: 0-8186-3000-0 ,1992 , PP 25-30.

[5] Alessandro Bianchi, Danilo Caivano, Vittorio Marengo, Giuseppe Visaggio, “Iterative Reengineering of Legacy Systems”,Ieee Transactions On Software Engineering, Vol. 29, No. 3, March 2003.

[6] Alessandro Bianchi, Danilo Caivano,Vittorio Marengo, Giuseppe Visaggio,” Iterative Reengineering of Legacy Functions”, 17th IEEE International Conference on Software Maintenance (ICSM'01), Florence, Italy, ISBN: 0-7695-1189-9,November 07-November 09.

[7] Anand Rajavat, Dr. (Mrs.) Vrinda Tokekar, “RrMm- a Measurement Model to Quantify the Effect of Reengineering Risk in Quality Perspective of Legacy System” Published in Springer International Conference on Advances in Information Technology and Mobile Communication – AIM 2012, PP 9-16 © Springer-Verlag Berlin Heidelberg 2012.

[8] Roy G.G, “ A Risk Management Framework for Software Engineering Practice,” Proceedings of the Conference on Software Engineering, Digital Object Identifier 10.1109/ASWEC.2004.1290458 ,PP. 60-67,2004 .

[9] R. N. Charette, Software Engineering Risk Analysis and Management, New York, McGraw-Hill, 1989.

[10] M. S. Camara, L. Kermad, A. El Mhamedi, "Risk Prediction in ERP Projects: Classification of Reengineered Business Processes," in CIMCA'06, International Conference on Computational Intelligence for Modeling Control and Automation and International Conference on Intelligent Agents Web Technologies and International Commerce, PP.213, 2006.

[11] P k Suri, Manoj Wadhwa,”Identification and assessment of Software Project’sRisk “, international Journal of computer science and network security, VOL.7No.8 August 2007.

[12] Paul R. Garvey, Chien-Ching Cho,”An Index to measure a system’sperformance Risk, Technical report, Report Number: A725324, Report Date: 2003, pages 13.

[13] Er.Anand Rajavat, Dr. (Mrs.) Vrinda Tokekar, “An Impact-based Analysis of Software Reengineering Risk in Quality Perspective of legacy System”, Published in International Journal of Computer Applications (IJCA), November 29, 2011, ISBN: 978-93-80865-35-6, Doi 10.5120/4046-5794, PP: 40-47.

[14] Er.Anand Rajavat, Dr. (Mrs.) Vrinda Tokekar, “Quantitative Evaluation Of Managerial Risk Components In Reengineering Process Of Legacy System”, Published in International Journal of Software Engineering (IJSE) International Research Publication , ISSN 0974-3162, Volume 3, Number 1 (2012), pp. 35-47

[15] Er.Anand Rajavat, Dr. (Mrs.) Vrinda Tokekar, “Identification and Measurement of Functional Risk Components in Reengineering Process of Legacy System”, Published in International Journal of Advanced Software Engineering (IJASE), ISSN 2249-3069 Volume 1, Number 1 (2011), © Research India Publications ,pp. 11-25.

[16] Abdullah Mohd Zin And Noraini Che Pa,” Measuring Communication Gap in Software Requirements Elicitation Process”, Proceedings of the 8th WSEAS Int. Conference on SOFTWARE ENGINEERING, PARALLEL and DISTRIBUTED SYSTEMS, ISSN: 1790-5117 ISBN: 978-960-474-052-9,Pp 66-71 , 2009.

[17] Personnel risk management, Toolkit, supported by European agency for safety and health at work.

[18] Shazia Mumtaz,” Factors affecting teachers' use of information and communications technology: a review of the literature”, Journal of Information Technology for Teacher Education, University of Warwick, Coventry, USA, 2006.

[19] Majid, R.A. Noor, N.L.M. Adnan, W.A.W. Mansor, S. ,” A survey on userinvolvement in software Development Life Cycle from practitioner's perspectives”, 5th International Conference on Computer Sciences and Convergence Information Technology (ICCIT), 2010, ISBN: 978-1-4244- 8567-3, Digital Object Identifier: 10.1109/ICCIT.2010.5711064, PP: 240 –243.

[20] Ronald P. Higuera, David P. Gluch, Audrey J. Doro fee ,” An Introduction to Team Risk Management”, Special Report CMU/SEI-94-SR-1, Version 1.0, May 1994.

[21] Steve Bannerman,” Direct Measurement and Forecasting of Software Team Efficiency”, Technical Report, April 17, 2007