RISK STUDY OF VARIOUS SOFTWARE DEVELOPMENT METHODOLOGIES Vishal Sharma 1, Priyanka Yadav 2, Priti Yadav 3 1,2,3 Cmputer Science Department, Drnacharya Cllege f Engineering/ ABSTRACT Maharishi Dayanand University, (India) There are different sftware methdlgies that exist in the real wrld. And there are several factrs t chse the methdlgy that will best fit the sftware prject. One f the imprtant factrs is that hw risky the prject is. And the ther factr is the degree t which each methdlgy will supprt risk management. The majr cntributr t prject success is t cntrl risk in sftware prjects. In this paper, we will study the risk and risk management in varius sftware develpment prcess mdels which are waterfall mdel, v-mdel, incremental develpment mdel, spiral mdel and agile develpment mdel s that it can help the prject manager t adpt the best methdlgy fr their prjects and can imprve the Sftware develpment prcess. Keywrds: Risk, Risk management, Sftware develpment methdlgy, Sftware develpment prcess mdel, Waterfall mdel, Spiral mdel, Incremental mdel, V-mdel, Agile mdel. I. INTRODUCTION Risk is described as "the pssibility f suffering lss that describes the impact n the prject which culd be in the frm f pr quality f sftware slutin, increased csts, failure, r delayed Cmpletin". We must identify, analyze and cntrl the risks fr successful management f a sftware prject. Accrding t Gilb s risk principle, If yu dn t actively attack the risks, they will actively attack yu. There is a basic cmpnent f risk management that are inherited in gd prject management. There are lt f differences between risk management and prject management. Prject management are designed t address general risks wherever risk management are designed t fcus n risks that are unique t each prject. Prject management plan fr details and risk management plans fr Cntingencies. Prject management plans fr success and risk management plans t manage and mitigate ptential cause f failures. There are fllwing fur reasns defined by Behm fr implementing sftware risk management: 1. Aviding sftware prject disasters, including run away budgets and schedules, defect-ridden sftware prducts, and peratinal failures. 2. Aviding rewrk that is caused by errneus, missing, r ambiguus requirements, design r cde, which typically cnsumes 40-50% f the ttal cst f sftware develpment. 3. Aviding verkill with detectin and preventin techniques in areas f minimal r n risk. 1 P a g e
4. Stimulating a win-win sftware slutin where the custmer receives the prduct they need and the vendr makes the prfits they expect. Fig. 1 Risk Management Prcess II. ANALYSIS In this sectin we will study the varius sftware develpment methdlgies and find the risk management in each f these mdels. 2.1 Waterfall Mdel It was first defined by Winstn W. Ryce in 1970 and majrly used in sftware develpment prcesses. It is sequential design prcess in which prgress is seen as steadlily flwing dwnward like waterfall which passes thrugh different phases (Requirement, Design, Implementatin, Verificatin, Maintenance). Fig 2 Stages f Waterfall Mdel By the develpment f the waterfall mdel lt f time is saved during the implementatin phase as it capture design errrs befre sftware is written, prgress is easily measured, ttal cst f prject is accurately estimated, testing becmes easier, user requirement are lucidly defined in advance. 126 P a g e
Majr Surces f Risk in the Waterfall Mdel Risk evlved in the waterfall mdel are unavidable.sme f the risk are: Cntinuus requirements change The majr risk factr threatens the waterfall prjects is the cntinuus requirements change during the develpment prcess. The waterfall mdel cannt accmmdate with these changes due t its strict structure. The waterfall mdel requires that all requirements be clearly defined in advance in the requirements stage in rder t guarantee that n change culd appear later n during the develpment prcess. N Overlapping between Stages Anther risk that is majr in waterfall mdel is that each stage must be executed cmpletely befre prceeding t the ther varius stages. This led t time inefficient and unreliability. Pr quality assurance Since waterfall mdel deals with a single phase at a particular time. The quality is nt checked at each stage and the single level testing is perfrmed at the later stages hence, the quality f the prject develped using waterfall is pr. Relatively lng stages Anther surce f risk in this mdel resides in the relatively lng stages, which makes it difficult t estimate, time, cst, and ther resurces required t cmplete each stage successfully. Additinally, in the waterfall mdel, there is n wrking prduct until late in the develpment prcess when the prduct is almst cmplete and any change is impssible. T make things wrse; imagine if the prduct failed t meet users expectatins. 2.2 Incremental Develpment Incremental develpment is a variant f the waterfall mdel which cnsists f a series f waterfall lifecycles wherein the sftware develpment prject is brken dwn int smaller segments called increments. The prpsal f the incremental develpment was t accmmdate with risks inherent frm implementing the verall sftware prject ver a single lifecycle in the pure waterfall mdel. Majr Surces f Risk in Incremental Develpment Fllwing are majr risk invlved in Incremental Mdel:- Prpagatin f bugs thrugh increments The majr risk during increment develpment mdel is the prpagatin f undiscvered bugs thrugh the increments t the later stages and it becme even mre cmplex t identify and handle the bugs at the later stages. Underestimatin f time and ther resurces required fr each increment Since it is required t estimate the time, cst and resurces fr the each increments which delays the prject develpment. Als the errred estimatins may led t the prject fall. Time and cst verrun 127 P a g e
Time and cst verrun is a critical factr t. This deadly interrupts the develpment prcess. Despite the fact that any interrupt at any pint in the incremental develpment prcess results in a wrking system, mstly this system wuld be an uncmpleted system wherein sme functinalities are nt implemented yet. 2.3 The V-Mdel The majr risk factrs threaten the waterfall mdel is the pr verificatin and validatin methds, which are restricted t a single testing phase cnducted lately in the develpment prcess. Anther variant f the waterfall mdel that came ut t deal with this risk is the V-mdel. The V-mdel is a testing-fcused sftware develpment prcess. It gives equal imprtance t bth develpment and testing. Its symmetrical shape allws the testing prcess t start early at the develpment prcess, and t be aligned with its different phases. Mrever, test planning cnducted at each stage helps at early identificatin f prject s specific risks and reducing them thrugh an imprved prcess management. prcess mdel due t the inflexibility it exhibits against the current evlutinary nature f sftware prjects. User requirements shuld be precisely defined In V mdel if user requirements are needed t be altered at later stages then it is nt that much pssible t make the changes. Hence this mdel is nt flexible.there is direct layer t layer cmmunicatin but nly errrs are detected nt crrected. 2.4 Spiral Develpment The spiral mdel was psit by Behm in 1988 as a risk-driven sftware develpment prcess mdel, where the whle develpment prcess is guided by the invlved risks. It aims at identifying and evaluating sftware prject risks, and helps in reducing these risks and cntrlling prject cst. Spiral develpment supprts risk management in sftware prjects in several ways summarized in the fllwing: The initial risk analysis aims at: Identifying mst risks threaten the prject. Classificatin f these risks under the categry f their effect t the prject. Evaluate these risks t decide upn the risks t handle thrugh each cycle. The risk analysis stage at each cycle that precedes each phase f the waterfall phases in purpse f: Reslving prgram develpment start frm the initial phase f prject. Evaluating the new risks that may arise and alter the prject quality. The iterative feature f the spiral which allws the develpment prcess t g back t the first quadrant at any pint in prgress which allws: Objectives, alternatives and cnstraints t change as mre attractive alternatives exist. New technlgy t be incrprated easily during the develpment prcess. 128 P a g e
The maximum ptimizatin f prject resurces usage. T deal with prly dne activities in the earlier phases. The review cnducted at the end f each cycle with main stakehlders as a decisin pint t avid the lack f cmmitment risks during the next cycle. Time and cst verrun risks are best managed using spiral develpment due t the risk analysis stage cnducted at each cycle. In this stage, the cst and time required fr each cycle are analyzed in advance t give a clear picture abut the critical state f the prject. This helps the prject manager and the develpers get mre cntrl ver these risks. Risks related t the increased cmplexity f the prject are als managed using spiral. This is achieved by the partitining activity cnducted at the planning phase. Decmpsing the prject int prtins t be develped in parallel spirals bviusly reduces time cntentin related risks, since mre wrk culd be achieved during the same interval. Majr Surces f Risk in the Spiral Mdel Despite its risk driven nature, spiral has its wn surces f risks which are summarized in the fllwing: High reliance n the human factr Since the risk is evaluated at each step f spirat quadrant hence there are experts f each phase t cncentrate n the spiral prcessing. This led t the mre emphasize n the human factr. Als the cst and time reliability is lw. Detailed risk management prcess Cst and schedule risks might increase using spiral due t its iterative feature, especially fr lw risk prjects wherein risk assessment is nt required t be at this level f granularity. 2.5 Agile Develpment In February 2001, 17 sftware develpers (see belw) met at the Snwbird, Utah resrt, t discuss lightweight develpment methds. They published the Manifest fr Agile Sftware Develpment t define the apprach nw knwn as agile sftware develpment. Sme f the manifest's authrs frmed the Agile Alliance, a nnprfit rganizatin that prmtes sftware develpment accrding t the manifest's values and principles. Agile sftware develpment is a grup f sftware develpment methds in which requirements and slutins evlve thrugh cllabratin between self-rganizing, crss-functinal teams. It prmtes adaptive planning, evlutinary develpment, early delivery, cntinuus imprvement and encurages rapid and flexible respnse t change. It is a cnceptual framewrk that fcuses n frequently delivering small increments f wrking sftware. The majr principal in the Agile develpment is the infrmal cmmunicatin between the stakehlders and the develpers. This cmmunicatin includes the planning, resurce allcating and ther phases f the prject. Building upn the literature, we can say that there are tw cntrasting views regarding risk management in the agile cntext. The first claims that agile is an inherent risk driven apprach and implicitly supprts risk management by nature. The prpnents believe that there is n need t enhance risk management in these 129 P a g e
prjects. In cntrast, the secnd believes that the risk management state in agile des nt differ significantly frm ther traditinal mdels and that risk management shuld be enhanced in agile t cmpensate fr the lack f risk management in the agile prjects. The advcates t the secnd view believe in that in sme situatins the inherent risk management driven nature f the agile is insufficient. Majr Surces f Risk in the Agile Develpment In spite f the assertins it makes regarding managing risks, the agile develpment lacks fr any detailed suggestins fr managing these risks. Thus, many surces f risks will be left unhandled. The fllwing are the majr surces f risk in the agile develpment: Very large sftware system The risk management in the Agile develpment is nt suitable fr the large and cmplex prjects as this wuld increase the timespan. Large develpment team This agile develpment is nt suitable fr the large team csisity large n f members as it is nt reliable t make cmmunicatin effectively between large n f peple. High reliance n human factr It relies entirely n the experience f the develpment team and their abilities t cmmunicate successfully with custmers. If the prject misses these cnditins, then the failure is an inevitable issue. Distributed develpment envirnment Since Agile Develpment requires face t face daily cmmunicatin hence it is nt suitable fr distributed envirnment. Scpe creep Under this Agile develpment the develper mstly get disatracted frm the main bjective f the prject. III. CONCLUSION This paper fcuses n the leading sftware develpment prcess mdels and explred the state f risk management in each f these mdels. We cnclude that the risk management is deep rted invlved with sme sftware develpment methdlgies. Risk Management must be enhanced in all the sftware develpment methdlgies as risk is unavidable in mst sftware develpment methdlgies. The fascinatingaspect fr future research is t discvera apprach that aims at further imprving quality f risk management in the divergent sftware develpment methdlgies. REFERENCES [1] Standish Grup, CHAOS reprt, 2009, Bstn. [2] L. Guimares and P. Vilela, Cmparing Sftware Develpment Mdels Using CDM, Prceedings f The 6th Cnference n Infrmatin Technlgy Educatin, New Jersey, 20-22 Octber 2005, pp. 339-347. 130 P a g e
[3] N. Ruparelia, Sftware Develpment Lifecycle Mdels, ACM SIGSOFT Sftware Engineering Ntes, Vl. 35, N. 3, 2010, pp. 8-13. [4] I. Smmerville, Sftware prcess mdels, ACM Cmputing Surveys, Vl. 28, N. 1, 1996, pp. 269-271. [5] B. Shahzad and S. Safvi, Effective Risk Mitigatin: A User Prspective, Internatinal Jurnal f Mathematics and Cmputers in Simulatin, Vl. 2, N. 1, 2008, pp. 70-80. [6] L. Rdrguez, M. Mra, and F. Alvarez, A descriptive Cmparative Study f the Evlutin f Prcess Mdels f Sftware Develpment Lifecycles (PM-SDLCs), Prceedings f the Mexican Internatinal Cnference n Cmputer Science, 2009, pp. 298 303. [7] J. Nyfjrd and M. Kajk-Mattssn, Outlining A Mdel Integrating Risk Management and Agile Sftware Develpment, Prceedings f the 34th Eurmicr Cnference Sftware Engineering and Advanced Applicatins, 2008, pp. 476-483. [8] R. Dash and R. Dash, Risk assessment techniques fr sftware develpment, Eurpean Jurnal f Scientific Research, Vl. 42, N. 4, 2010, pp. 629 636. [9] N. Munassar and A. Gvardhan, A Cmparisn between Five Mdels f Sftware Engineering, Internatinal Jurnal f Cmputer Science Issues (IJCSI ), Vl. 7, N. 5, 2010, pp. 94 101. [10] W. Ryce, Managing the develpment f large sftware systems, IEEE WESCON, 1970, pp. 1-9. [11] GSAM, Cndensed GSAM Handbk, chapter 2: Sftware Life Cycle, 2003. [12] G. Tate and J. Verner, Case Study f Risk Management, Incremental Develpment and Evlutinary Prttyping, Infrmatin and Sftware Technlgy, Vl. 32, N. 3, 1990, pp. 207-214. [13] B. Behm, A Spiral Mdel f Sftware Develpment and Enhancement, Cmputer, 1988, pp. 61-72. [14] B. Gtterbarn, Enhancing risk analysis using sftware develpment impact statements, Prceedings f the 26th Annual NASA Gddard Sftware Engineering Wrkshp, 2001, pp. 43-51. [15] V. Szalvay, An Intrductin t Agile Sftware Develpment, technical reprt, Danube Technlgy, 2004. [16] J. Miller and J. Grski, A Methd f Sftware Prject Risk Identificatin and Analysis, Ph.D. Thesis, Faculty f Electrnics, Telecmmunicatins and Infrmatics, Gdansk University Of Technlgy, 2005. [17] A. Schmietendrf, E. Dimitrv, and R. Dumke, Prcess Mdels fr the Sftware Develpment and Perfrmance Engineering Tasks, Prceedings f the 3rd Internatinal Wrkshp n Sftware and Perfrmance, 2002, pp. 211-218. [18] F. Nasutin and R. Weistrffer, Dcumentatin in Systems Develpment a Significant Criterin fr Prject Success, Prceedings f the 42nd Hawaii Internatinal Cnference n System Sciences, 2000, pp. 1-9. [19] S. Murthi, Preventive Risk Management fr Sftware Prjects, IT Prfessinal, Vl. 4, N. 5, 2002, pp. 9-15. 131 P a g e