The Classification and Analysis of Risks in Reengineering System

Transcription

1 Internatinal Jurnal f Cmputer Applicatins ( ) Vlume 39 N.18, February 2012 The Classificatin and Analysis f Risks in Reengineering Jshphin Jasaline Anitha.X M.Karthika K. Alagarsamy Assistant Prfessr Assistant Prfessr Assciate prfessr MCA Department MCA Department Cmputer Centre N.M.S.S.Vellaichamy Nadar Cllege N.M.S.S.Vellaichamy Nadar Cllege Madurai Kamaraj University Madurai, Tamil Nadu, India. Madurai, Tamil Nadu, India. Madurai, Tamil nadu, India. ABSTRACT Sftware engineering has becme an imprtant field f cmputer science and an active research field. Due t new trend and technlgy mst f the sftware is in need f change. Any sftware that has crssed a decade are incapable f satisfying custmer need with current technlgy is named legacy system. T vercme this hazard and t be cst benefited, in facing the new trends the sftware has t be reengineered in a benefiting way. The legacy system, therwise called existing system has t be reengineered. In Mst f the reengineering system, the legacy transfrmatin is the prcess f mdernizing an peratinal system t retain and extend the value f investment in that system. It invlves bth infrastructure and applicatin mdernizatin. The primary benefit f legacy transfrmatin is t enhance the business prcess and imprve functinality f business bjective. Legacy transfrmatin prjects are frequently challenged, because a set f risks will threaten the prject success f legacy transfrmatin. This paper presents a set f risks and their classificatin. Frm the analysis f risks, sme mitigatin that helps t make the reengineering prjects mre beneficial is suggested. Keywrds Reengineering, Legacy system, Reverse Engineering, Frward Engineering, mitigatin. 1. INTRODUCTION Sftware reengineering is rerganizing and mdifying existing sftware systems t make them mre maintainable. That is restructuring r rewriting a part r all f a legacy system withut changing its functinality [1]. Reengineering invlves adding effrt t make them easier t maintain, the system may be restructured and redcumented. The purpse f reengineering is t mdernize the existing system ver a newer ne. Aging and unreliable system cmpnents, when system becmes utages frequently. Changes t business prcesses becme t cmplex, difficult, and/r cstly t implement. Slutins are less expensive than legacy maintenance. The advantages f reengineering are reduced risk at reduced cst. The reengineering prcess may als face varius types f risks as sftware engineering. The risk identificatin is an art. The risk identificatin is mre imprtant fr effective risk assessment, risk analysis, and management. In the prpsed wrk, the ptential risks are analyzed and categrized. A mnitring methd is explained fr the categrized risks. It will help a reengineering system twards an ease f maintenance and cst benefit with reduced risk at reduced cst. 2. REENGINEERING- AN OVERVIEW The examinatin and alteratin f a system t recnstitute it in a new system is knwn as reengineering [9]. It is als a prcess f mdificatin f a sftware system that takes place after it has been reverse engineered, generally t add new functinality, r t crrect errrs. The reengineering prcess typically encmpasses a cmbinatin f ther prcesses such as reverse engineering, re-dcumentatin, restructuring, translatin, and frward engineering. The main bjective f reengineering is shwn in Figure.1,which helps t understand the existing sftware system, and t enhance, redesign, re-implement the riginal r ld functinality with the current trend f technlgy, and with added subsystem t get mre prfit with latest technlgy. Existing Fig.1 Reengineering prcess The current system in use is called as legacy system. When the legacy system becmes ld and weak in its design, structure, and cding, new mdules can be added t strengthen the legacy system. This prcess makes the system thrnier and it wn t be cst benefited. Whenever a new system is evlved, the system develpment life cycle cnsists f the fllwing stages: Alteratin r mdernizatin Feasibility study Requirement and analysis Design Cding Testing Implementatin and But, all these stages are nt needed in reengineering. When we engineer the legacy system definitely it might take time, mney, and peple t buildup. The invested legacy system cannt be simply wasted r thrashed. The legacy system has t be redefined fr reengineering. Then the system will be mre ecnmical with the current trend and new technlgies and will be at par. The cre bjective f the redefined reengineering system is, fitting the mdules with imprved technlgy, functinality and explicit interfaces. The dcumentatin will als match with the current trend and technlgy. Requirement definitin f reengineering prjects first requires the assessment f the 57

2 Internatinal Jurnal f Cmputer Applicatins ( ) Vlume 39 N.18, February 2012 current legacy applicatin and prtfli and infrastructure. This assessment shuld identify at minimum: Cre applicatins that supprt the business and applicatin that verlap r are redundant Obslete r unused applicatin with current business rules and prcesses Technical value and peratinal efficiency f applicatin Infrastructure cmpnents and cnstraints Ptential imprvements in efficiency and reductin f redundancy in bth system and current business prcesses. Latest trend and sftware technlgy that match the current business prcess. A thrugh understanding f all these items is essential t specify requirements that definitely meet the business need within technical cnstraints. 2.1 Reengineering life cycle: When hardware r sftware supprt becmes bslete and when tls t supprt re-structuring are available, a system can be taken up fr reengineering. The advantages f reengineering are reduced risk at reduced cst. The reengineering life cycle has tw parts. i. Reverse Engineering ii. Frward engineering i.reverse Engineering: Reverse Engineering is the prcess f analyzing a sftware system in rder t identify its cmpnents and their interrelatinships and Create representatins f the system in anther frm r at a higher level f abstractin. [1,4] Alteratin (Reverse Eng) (r) (Frward Eng) Abstractin Mdernizatin Refinement Existing Fig.2 Reverse Engineering Reverse engineering is a key t the rest f the prcess f reengineering, because it enables us t take an existing sftware system that is being reengineered (e.g., in terms f its surce cde) and t recver an abstract representatin that can be used fr subsequent reengineering r even reimplementatin. ii. Frward Engineering: The Frward Engineering is the Prcess that applies sftware engineering principles, cncepts, and methds t re-create an existing applicatin. Simply it is the prcess f legacy system t new system. Figure.3 shws the functins f frward engineering [8]. The frward engineering evlves in redcumentatin, restructuring, and remdularizatin. 2.2 Benefits f Reengineering Fr many reasns, especially ecnmical, any system r prject needs redevelpment. In the case f reengineering, reuse f legacy cmpnents will help t make a new system. Sme f the benefits are as fllws: Imprves the quality and cnsistency f business plans. Imprves the financial reprting. Makes fair f bnus plans pssible. Filters the macrecnmic factrs Extends the planning prcess relevance. Lwers Csts Lwers Risks Better use f existing staff Reveals business rules Incremental develpment Reduces peratinal csts Imprves system perfrmance, accessibility, system dcumentatin Preserves legacy investments Minimize impacts t business peratins Add r enhance sftware functinality As a system evlves in reengineering, the purpse and success secret f the system are rediscvered. Reengineering can be dne by different stages, such as budget and available resurces. The functinal rganizatin has a wrking system in all time, and the users are able t gradually becme accustmed t the reengineered system as it is carries in the incremental way. Always reengineering is an incremental imprvement f systems, rather than a drastic change in the system. This will imprve the system as per user s need. Mrever the existing staff members can be train in the reengineered system withut lsing them. Which will help t evlve the skills f the existing staff member s as well as system. With the reengineering system the benefits can be classified as Prtability Ease f maintenance Migratin Reliability Legacy transfrmatin prjects have many f the same risks as ther types f system develpment prjects. The impacts f thse risks are mre severe than the traditinal prjects, because legacy transfrmatin prjects invlve changes in functinal peratins that may be integral with the current trend and technlgy t business peratins. Specificatin Design and implementatin Fig. 3 Frward Engineering 58

3 Internatinal Jurnal f Cmputer Applicatins ( ) Vlume 39 N.18, February RISK: Risk is a likely shrtfall between the desired level f perfrmance and the actual perfrmance at a future time. [16]. 3.1Risk Assessment: A systematic apprach t bserve the wrking methds, expectatin f truble and find ut a suitable mnitring methd t prevent lss in the business and hstility in the wrk place is knwn as assessment. The assessment shuld include the cntrls required t eliminate, reduce r minimize the risks. 3.2 Cntrlling Risks: Any system must be cnscius abut the risks which may ccur at any time and at any place. T cntrl the risks the fllwing principles f measurement shuld apply in any system. The risks can be avided r eliminated The affected part f the system has t be analyzed. The preventive methd t cntrl the risks Technical methd can implement t cntrl risk Infrmatin, instructin and training, and prviding persnal prtective equipment shuld always be cnsidered as a last resrt after the abve cntrls have been cnsidered. Emplyers shuld, wherever pssible, give pririty t thse cntrls that best prtect everyne expsed t the risk. 3.3 Risk Mitigatin When the risks are identified in a system, the eliminatin prcess will take place. Over the perid the practice f finding risks and alleviatin is easy. risk assessment, risk analysis and risk management. This paper shws the categrizatin and identificatin f risks and an evlutin f mitigatin methds fr reengineering prjects. While mnitring the prject in a cntinuus manner, the identificatin f risks can be dne at the initial stages. Once the risk is identified the mitigatin prcess is easy with the expert team and we can avid the prblem in functinal peratins. The maintenance part als becmes very easy. This will make the prject a prfitable ne. The main advantage f reengineering is reduced risk at reduced cst. This can be easily prved. The risk mitigatin is shwn in Fig.4 cnsists f the fllwing stages. Classificatin, Identificatin, Assessment, Mitigatin, Mnitring. Whatever the risks may arise we categrize them int the limited divisins. With cntinuus mnitring f risk we can identify the risk when it ccurs. The assessment can als be dne and check whether the risk is knwn r unknwn risk. If the risk is knwn and expected, mitigate it with expert team therwise, the unknwn risk shuld be categrize and g back t risk mnitring system. The prcess can be dne in the fllwing manner, Categrize Risk Mnitring Identificatin 3.4 Risk Analysis Risk analysis has becme a standard requirement fr legacy prcess transfrmatin prjects in many rganizatins. The basic thing is t identify, analyze, classify, and categrize the risks invlved. When the risks are systematically listed ut and categrized, the mitigatin prcess becme easier and ecnmically sund in prfit. Any reengineering system faces sme risks when the prcess transfrmatin takes places. Such risks are as fllws. Yes Assessment Expected N Missin and Gal Prgram management Decisin derivers Organizatin management Custmer/User Prject parameters Prduct cntent Deplyment Develpment Envirnment Prject Management Prject team Technlgy 4. THE RISKS IN RE-ENGINEERING SOFTWARE Althugh re-engineering is ften used as a means t reduce the risk, reduce csts and maintain the peratin f deriving the sftware, but re-engineering cannt avid risk. The risk f early identificatin prgrams t supprt and prject management in the preparatin f estimates, risk assessment f sftware re-engineering and prvide a practical framewrk fr the expectatins. Identifying risks is essential fr effective Fig 4. Risk mnitring methdlgy The purpse f the study is t suggest a methd t mnitr the reengineering sftware, t identify the risks when it ccurs and categrize them and mitigate with apprpriate slutin. This will lead the reengineering sftware t reduce risk and make it mst cst benefited. The risks can be categrized in t the fllwing five types as depicted in Figure.4. Existing Mitigatin Alteratin r mdernizatin Risks categrizatin Time delay Cst User perfrmance maintenance satisfactin 59

4 Internatinal Jurnal f Cmputer Applicatins ( ) Vlume 39 N.18, February 2012 Fig.5 Classificatins f Risks Time delay: Time is the prime risk factr fr any prject. Time is needed t anticipate and prevent prblems. Time is the great equalizer, since every day that is made available t the prject is an additinal day t deal with the cnsequences f risk. By managing risk, time can be used t an advantage, rather than being wasted. The risks related t time factr are Lack f knwledge abut legacy systems. Lack f understanding the cncepts f legacy system. The vital rle played by rganizatinal hierarchy in making decisin. Plitical reasns. Delivering the prject n time. Budget cst verflw. Migratin f team peple Cst benefit: Any prject is reengineered fr business needs t face the market with new trend and technlgies and t make it mre cst benefited. Risks invlved in cst benefit are as fllws: Less benefit/prfit High maintenance cst Expensive backup High cst t finance reprt Pr quality and incnsistency f business plans Lss f legacy investments Perfrmance: Perfrmance Risk is the degree f uncertainty in the develpment and deplyment prcess that may keep the system frm meeting its technical specificatins r that may result in the system being unsuitable fr its intended use. The reengineering prjects depend n the perfrmance f new system. The new system perfrmance shuld definitely be better than the legacy system. The Perfrmance risks are: Nn prtability Result mismatching Unsupprted legacy system Reliability mismatch Incmpatible Result Imprper selectin f reengineering apprach Inapprpriate Data restructuring User/Custmer Satisfactin: In a cmpetitive marketplace where businesses cmpete fr custmers, custmer satisfactin is seen as a key differentiatr and increasingly has becme a key element f any business strategy. Table: 1 Risk Verses Develpment life cycle Therefre, it is essential fr any business t effectively manage custmer satisfactin. T d this, firms need reliable and representative measures f satisfactin. The reengineering system s custmer /user satisfactin risks are listed belw. Budget verflw Unexpected result Less User friendliness Unsupprted t referential mdel : is really an evlutinary develpment and maintenance decisins are aided by understanding what happens t any sftware systems ver time. The key sftware maintenance issues are bth managerial and technical. Key management issues are: alignment with custmer pririties, staffing, which rganizatin des maintenance, estimating csts. Key technical issues are: limited understanding, impact analysis, testing, and maintainability measurement. The maintenance activities are categrized int fur classes: Adaptive dealing with changes and adapting t the sftware envirnment Perfective accmmdating with new r changed user requirements which cncern functinal enhancements t the sftware Crrective dealing with errrs fund and fixing it Preventive cncerns activities aiming n increasing sftware maintainability and prevent prblems in the future. The maintenance risk factrs are Backup Recvery f legacy systems Imprper Data restructuring Imprper Redcumentatin Alternative system slutin The risks which may ccur in reengineering are tabulated accrding t peple, prject, prcess, prduct in the sftware develpment life cycle. Identified Risks 4 P s Develpment life cycle Peple Prject Prcess prduct User satisfactin Cmmunicatin Technlgy Degrade Alternative system Cst High salary Budget verflw Pr quality Lss Perfrmance Hazard Deplyment Maze Backup Time delay Incmpetent Missin and Gal On time submissin Delivery time Migratin Enhancement Incmpatible Reliability 60

5 Internatinal Jurnal f Cmputer Applicatins ( ) Vlume 39 N.18, February 2012 Thus we can categrize the risks that we expect and meet in legacy and in a new system. If the methds discussed either t be fllwed, the mnitring f risk is very easy. When we identify the risks we can mitigate them with the experts withut affecting the functins f the new system. In such a way, we can make the reengineering system mre cst benefited. 5. CONCLUSION Whenever reengineering takes places a variety f risks might ccur. This paper prpses varius risks which are classified and a mnitring methd is taken fr discussin. It will help t identify the risks and t categrize the risks t mitigate them prperly. The main utcme is, the rganizatin must feel easy t make the prject with reengineering at a lw budget, with current trend and technlgy, the custmer satisfactin. It will lead the prject mre cst benefited with gd perfrmance and with an ease f maintenance. Further, risks invlved in prcess transfrmatin can be identified, analyzed and mitigatin methds can be evlved. An evlutinary methd will be dne in a cmprehensive manner in my future wrk related with prcess transfrmatin, risk analysis and methds f mitigatin in reengineering can becme effective and efficient. 6. REFERENCES: [1] Arnld.R., Sftware reengineering IEEE, Cmputer sciety press, [2] Capers jnes, Early sizing and early risk analysis f sftware prjects, [3] Chia-chu chang Sftware stability in sftware reengineering. Infrmatin Reuse and Integratin, [4] Chikfsky.E.J; Crss.J.H., Reverse Engineering and Design Recvery : A Taxnmy, IEEE Sftware, Vl.23, 1990,pp [5] Gerard canfra, Aniell cimitile, Sftware maintenance, Jurnal f Sftware 13(1): 1-2 (2001) [6] Harry.M.Sneed, Ecnmics f Sftware reengineering, Jurnal f Sftware Maintanence, Vl.3, 1991,p.163. [7] Harry M.Sneed. Risks invlved in reengineering prjects.,prceedings f WCRE, IEEE Cmputer Sciety Press, Atlanta, 1999, pp [8] Ian Smmerville.,2000. Sftware engineering., [9] Dr.Linda and Rsenberge, Sftware reengineering. [10].Mghaddas, Y., & Rashidi, H. (2009). A nvel apprach fr replacing legacy systems. Jurnal f Applied Sciences, 9(22), [11] Dr.Rger.S.pressman, Sftware engineering, fifth editin. [12] M. Slvin, and S. Malik. Reengineering t reduce system maintenance: A case study, Sftware Engineering, pp.14-24,2011. [13] Dr. ying zu, Sftware reengineering evlutin. [14] Jakub Miler, Janusz Górski. Identifying Sftware Prject Risks with the Prcess Mdel, ICSSEA2004. [15] Jhn bergey, Dennis smith, Sctt titley, Nelsn Weiderman, Steven wnds. Why reengineering prjects fail. [16] Planning mentr 61