M.Tech Scholer J.P.I.E.T, Meerut, Uttar Pradesh, India. Department of computer science J.P.I.E.T, Meerut, Uttar Pradesh, India

Size: px
Start display at page:

Download "M.Tech Scholer J.P.I.E.T, Meerut, Uttar Pradesh, India. Department of computer science J.P.I.E.T, Meerut, Uttar Pradesh, India"

Transcription

1 International Journal of Scientific Researc in Computer Science, Engineering and Information Tecnology 2018 IJSRCSEIT Volume 3 Issue 6 ISSN : Analysis te Strengt of Agile Metodologies in Software Development ABSTRACT K M. Jyoti 1, Mr. Tinku Sing 2, Parul Saaravat 3 1 M.Tec Scoler J.P.I.E.T, Meerut, Uttar Prades, India 2 Department of computer science J.P.I.E.T, Meerut, Uttar Prades, India 3 Department of computer science D.N. Polytecnique, Meerut, Uttar Prades, India Tere are several software development metodologies in use today. Some companies ave teir own customized metodology for developing teir software but te majority speaks about two kinds of metodologies: eavyweigt and ligtweigt. Te strengts and weakness between te two opposing metodologies are discussed and te callenges associated wit implementing agile processes in te software industry are provided. According to our findings agile metodologies can provide good benefits for small scaled and medium scaled projects but for large scaled projects traditional metods seem dominant. Te study also focuses te different success factors of agile metods, te success rate of agile projects and comparison between traditional and agile software development. Keywords : Software Process, Software Development Metodology, Agile, Heavyweigt Metodologies. I. INTRODUCTION Software as been part of modern society for more tan 50 years. Software development started off as a messy activity often mentioned as code and fix. Te software was written witout muc of a plan, and te design of te system was determined from many sort term decisions. Tis worked well for small systems but as systems grew it became more difficult to add new features and bugs were arder to fix. Tis style of development was used for many years until an alternative was introduced: Metodology. Metodologies impose a disciplined process upon software development wit te aim of making software development more predictable and more efficient. Traditional or eavyweigt metodologies are plan driven in wic work begins wit te elicitation and documentation of a complete set of requirements, followed by arcitectural and ig level design development and inspection. Due to tese eavy aspects, tis metodology became to be known as eavyweigt. Tese metodologies and practices are based on iterative enancements, a tecnique tat was introduced in 1975 and tat as become known as agile metodologies. II. ORGANIZATION OF TITLE Te goal, terefore, is to begin filling in te gap of metodologies by conducting a detailed review of bot eavyweigt and agile metodologies. For eavyweigt metod, several metods are reviewed suc as Waterfall, Unified Process and Spiral. Furter an overall view of te caracteristics of eavyweigt metods is discussed. Next, te same procedure for agile metodologies is followed. Some agile approaces suc as Extreme Programming, Scrum, Dynamic System Development Metod, Feature Driven Development and Adaptive Software Development underlining te caracteristics of agile metods are introduced. Furtermore, a comparison of te different agile metods in order to igligt CSEIT Received : 01 July 2018 Accepted : 08 July 2018 July-August-2018 [ 3 (6) : ] 32

2 te similarities and differences between tem are carried out. Te next section criticizes te limitations of eac eavyweigt and agile metods. Following tis, te callenges associated wit implementation of agile processes in te software industry according to software practitioners and anecdotal evidence. III. PROBLEM STATEMENT Now a days in any field like business, education, sports etc. te success depend on te software being used, due to te fast development in tecnology te organizations needs its software updated and te software sould meet all te business needs. Te rapid growing completions between te organizations ave created a callenge for te software development companies (Czarnacka-Crobot, 2010). Te agile software process is te combination of te best practices and teir previous success and failure experiences wit many software development projects regarding wat works and wat not. Eac of tese two practitioners (best practice and previous success and failure experience) ad teir own different pilosopies about ow tey approaced software development. However, all of tem advocated close collaboration between software development and business teams, as opposed to silo development by software teams; face-to-face communication, as opposed to over-empasis on written documentation in projects; frequent delivery of portions of working software, as opposed to final delivery of te complete product at te end; accepting canging requirements by customers, as opposed to defining a fixed set of requirements castin-stone ; and adaptive organizational capability of teams according to canging business requirements (Misra et al., 2009). Figure 1. Software process (Pressman, 2001) Te word agile means ligt weigt; te main teme of agile metod is te simplicity and speed. Te main points of agile metods according to Fowler and Higsmit (2001) are Incremental (small software releases, wit rapid cycles) Cooperative (customer and developers working constantly togeter wit close communication) Straigtforward (te metod itself is easy to learn and to modify, well documented) Adaptive (able to make last moment canges). IV. HEAVYWEIGHT METHODOLOGIES Software development Process models are used for all most all type of software development projects and according to Sommerville (2011) a software model is te simplified form of a software process tat represents a particular perspective and provides partial information about te process.software process is a framework of activities tat are involved in all most all te software projects regardless of te size and complexity of te tasks (Pressman, 2001). Tose pases are listed below. Software specifications: Here te functionality of te software is defined and te constraints on te operations of tose functionalities are defined. 33

3 Software design and implementation: Te software wic can complete te required specification can be produced. Software validation: Te software sould satisfy te customer, means te software sould perform all te tasks for wic it is produced. Software evolution: Te software must be ready to meet te canging customer need. V. HEAVYWEIGHT METHODOLOGIES CHARACTERISTICS Te eavyweigt development metodology is based on a sequential series of steps, suc as requirements definition, solution build, testing and deployment, wereas ligtweigt metodologies propose executing te project steps in parallel. For example, te manager of a project tat is based on te eavyweigt metodology won t agree to build te IT solution until te full requirements ave been determined, and so it continues for eac project pase. Still, any project team larger tan people and working in multiple locations may be a good candidate for a eavyweigt metodology. Heavyweigt metodologies can be te better coice wen you ave multiple teams working at different locations and you need tigter control to formalize key parts of te project. VI. COMPARISON OF VARIOUS HEAVYWEIGHT METHODOLOGIES ON THE BASIS OF DIFFERENT PARAMETERS Table 1. Comparison of different Heavyweigt Metodologies MODEL/ WATE ITERA PROT MERITS RFALL TIVE OTYP V- SPI MODE WATE E SHAP RA L RFALL ED L MODE MODE MO L L DEL Success rate Low Hig Good Hig Hig Cost Low Low Hig Very ig Hig Flexibilit y Rigged Less flexibil Higl y Little flexible Flex ible ity flexibl e Risk analysis Hig No risk analysi s Low Low Low Cost Yes No No Yes Yes control Reusabili Limite Yes Weak Low Yes ty d Risk Only Low No Low Yes analysis at beginn ing risk analys is Impleme ntation time Long Less Less Less Dep end s on proj ect Interface Minim um Crucial Curial Minim um Cru cial Security Vital Limite d Weak Limite d Hig Expertise required Simplicit y User involvem ent Resource control Hig Hig Medi um Mediu m Hig Simple Simple Simpl Interm Inte e ediate rme diat e Only At te Hig At te Hig at beginn beginn beginn ing ing ing Yes Yes No Yes Yes 34

4 VII. AGILE MODELING Agile devoting te quality of being agile; readiness for motion; nimbleness, activity, dexterity in motion as mentioned in te Oxford Dictionary [13] software development metods are attempting to offer once again an answer to te eager business community asking for ligter weigt along wit faster and nimbler software development processes. Following are te Agile Manifesto principles: Individuals and interactions - In agile development, self-organization and motivation are important, as are interactions like colocation and pair programming. Working software - Demo working software is considered te best means of communication wit te customer to understand teir requirement, instead of just depending on documentation. Customer collaboration - As te requirements cannot be gatered completely in te beginning of te project due to various factors, continuous customer interaction is very important to get proper product requirements. Responding to cange Agile development is focused on quick responses to cange and continuous development. All tese metodologies acknowledged tat ig quality software and more importantly customer satisfaction could only be acieved by bringing ligtness to teir processes. Some of te most used agile metodologies are listed below. VIII. EXTREME PROGRAMMING (XP) Extreme programming (XP) as evolved from te problems caused by te long development cycles of traditional development models [14]. Te term extreme comes from taking tese commonsense principles and practices to extreme levels. A summary of XP terms and practices is sown below [14]: Planning: Te programmer estimates te effort needed for implementation of customer stories and te customer decides te scope and timing of releases based on estimates. Small/sort releases: An application is developed in a series of small, frequently updated versions. New versions are released anywere from daily to montly. Metapor: Te system is defined by a set of metapors between te customer and te programmers wic describes ow te system works. Simple Design: Te empasis is on designing te simplest possible solution tat is implemented and unnecessary complexity and extra code are removed immediately. Refactoring: It involves restructuring te system by removing duplication, improving communication, simplifying and adding flexibility but witout canging te functionality of te program Pair programming: All production code is written by two programmers on one computer. Collective ownersip: No single person owns or is responsible for individual code segments rater anyone can cange any part of te code at any time. Continuous Integration: A new piece of code is integrated wit te current system as soon as it is ready. Wen integrating, te system is built again and all tests must pass for te canges to be accepted. 40-our week: No one can work two overtime weeks in a row. A maximum of 40-our working week oterwise it is treated as a problem. On-site customer: Customer must be available at all times wit te development team. 35

5 Coding Standards: Coding rules exist and are followed by te programmers so as to bring consistence and improve communication among te development team. Adaptive Software Development (ASD) Adaptive Software Development (ASD), developed by James A. Higsmit, offers an agile and adaptive approac to ig-speed and ig-cange software projects [25]. It is not possible to plan successfully in a fast moving and unpredictable business environment. In ASD, te static plan-design life cycle is replaced by a dynamic speculate-collaborate-learn life cycle. ASD focal point is on tree non-linear and overlapping pases [23]: Speculate: To define te project mission, make clear te realization about wat is unclear. Collaborate: Higligts te importance of teamwork for developing ig cange systems Learn: Tis pase stresses te need to admit and react to mistakes, and tat requirements may well cange during development. Lean Software Development (LSD) Lean Software Development (LSD) is te application of lean principles to te craft of software development. So wat is Lean? According to te National Institute of Standards and Tecnology Manufacturing Extensions Partnersip s Lean Network, Lean is: A systematic approac to identifying and eliminating waste troug continuous improvement, flowing te product at te pull of te customer in pursuit of perfection. [26] Lean Software Development reduces defects and cycle times wile delivering a steady stream of incremental business value. [27] IX. CONCLUSION AND FUTURE WORK It s a common fact tat software plays a very important role in business and any type of business are dependent on software. If we go 30 years back ten at tat time tere was not tat muc competitions in business and te organizations were using teir old tecnology and were fulfilling teir business requirements. During te current situation due to advancement in te internet field and e- business te business of majority of te companies are expanded globally and te tose companies are using very advanced tecnology due to ig competition between te business companies and because of tat competition te organizations business requirements are canging at a very fast rate and it is not possible for te software companies to use te traditional software model for teir software development. Tose companies need suc software development metods tat are flexible to requirements and canged requirements and can deliver te software product in sort possible time and witin budget. Agile metods ave been used by software companies and te success rate of agile metods is muc more tan te traditional metods. I argue tat agile metods are very simple and easy and can complete te customer requirements easily witin time and budget because agile metods involve customer during te software develop pases. Tere is a close communication between te customer and developers, and also among te developers (team members). X. REFERENCES [1]. Cong Liu,David Umpress, Heavyweigt or Ligtweigt: A Process Selection Guide for Developing Grid Software, ACM-SE 08 Marc 28-29, 2008, Auburn, AL, USA [2]. Seetal Sarma, Daroti Sarkar, Divya Gupta, Agile Processes and Metodologies: A Conceptual Study, / International Journal on Computer Science and Engineering (IJCSE), ISSN: , Vol. 4 No. 05 May

6 [3]. Kausal Patak, Anju Saa, Review of Agile Software Development Metodologies, International Journal of Advanced Researc in Computer Science and Software Engineering, Volume 3, Issue 2, February 2013, ISSN: X [4]. B. Grady, C. Robert, J. Newkirk, Object Oriented Analysis and Design wit Applications, 2nd edition, Addison Wesley Longman, 1998 [5]. P. Kructen, "Wat is Rational Unified Process?", Te Rational Edge, ttp:// 1/f_rup_pk.tml Accessed 2/2/2005 [6]. C. Larman, Agile & Iterative Development: A Manager s Guide. Addison-Wesley, [7]. B. Boem, "A Spiral Model of Software Development and Enancement," IEEE Computer, May [8]. W. Cunningam, "Agile Manifesto." ttp:// Accessed on 10/7/2004 [9]. S. W. Ambler, "Duking it out", Software Development, July 2002 [10]. First eworksop on Agile Metods, Centre for Experimental Software Engineering Maryland, April [11]. J. Higsmit and A. Cockburn, "Agile Software Development: Te Business of Innovation", IEEE Computer, ttp:// icle1final.pdf Accessed on 10/10/