Niko Ibrahim Jur usan Si st em Inf or masi
Fakul t as Teknol ogi Inf or masi , Uni ver si t as Kr i st en Mar anat ha Jl . Pr of . Dr g. Sur i a Sumant r i No. 65 Bandung 40164
Emai l : ni ko. i br ahi m@eng. mar anat ha. edu
Abst ract
Agi l e Sof t war e Devel opment Met hodol ogy mungki n kur ang di kenal dan j ar ang di gunakan di l i ngkungan akademi k. Namun pada pr akt eknya, met odol ogi i ni sangat l ah umum di gunakan ol eh par a pr akt i si pengembang per angkat l unak. Jur nal i ni di t ul i s unt uk member i kan pandangan seki l as mengenai met odol ogi agi l e ser t a r el evansi nya di dal am set i ap t ahapan r ekayasa per angkat l unak secar a umum.
Keywords: Agi l e Met hodol ogy, Sof t war e Engi neer i ng
Int roduct ion
Agil e sof t ware devel opment approaches have become more and more popul ar during t he l ast f ew years. Agil e pract ices have been devel oped wit h t he int ent ion t o del iver sof t ware f ast er and t o ensure t hat t he sof t ware meet s changing needs of cust omers. Some peopl e say t hat agil e sof t ware devel opment is t he “ modern” repl acement of t he wat erf al l model (Larman, C. & Basil i, V. R. , 2003).
The probl em wit h t radit ional pl an-driven sof t ware devel opment met hodol ogies (e. g. wat erf al l ) are t hey are t oo mechanist ic t o be used in det ail . As a resul t , indust rial sof t ware devel opers have become scept ical about new sol ut ions t hat are dif f icul t t o grasp and t hus remain unused (Abrahamsson, P. , Sal o, O. , Ronkainen, J. , & Warst a, J. , 2002).
There are many met hods cl assif ied as agil e sof t ware devel opment :
• Adapt ive Sof t ware Devel opment ,
• Agil e Model l ing,
• Cryst al ,
• Dynamic Syst em Devel opment Met hodol ogy,
• Feat ure Driven Devel opment ,
• SCRUM and
• Ext reme Programming (XP)
Dif f erent aut hors emphasised dif f erent aspect s of sof t ware devel opment . Some f ocused on approaches t o pl anning and requirement s; some f ocused on ways t o writ e sof t ware t hat coul d be changed more easil y; and some f ocused on t he peopl e int eract ions t hat al l ow sof t ware devel opers t o more easil y adapt t o t heir cust omers' changing needs. These various ef f ort s creat ed a f ocal point f or a communit y t hat promot ed t he set of pract ices t hat succeed wit hout many of t he act ivit ies required by more def ined met hodol ogies.
Overview of Agile Software Development
Ref er t o Addison-Wesl ey Longman dict ionary, t he t erm “Agile” means abl e
t o move quickl y and easil y. Thus, “Agilit y” f or a sof t ware devel opment
organizat ion, means t he abil it y t o adapt and react quick and ef f ect ivel y and appropriat el y t o changes in it s environment and t o demands imposed by t his environment (Abrahamsson, P. , Sal o, O. , Ronkainen, J. , & Warst a, J. , 2002).
In t he f al l of 1999, Ext reme Programming, Embrace Change1 was publ ished and t he t rend had f ound it s cat al yst . In earl y 2001, t he dif f erent innovat ors who were creat ing dif f erent agil e met hodol ogies hel d a ret reat and scribed t he "Agil e Manif est o f or Sof t ware Devel opment . " (Lowel l , L. & Ron, J. , 2004)
This manif est o emphasises t he devel opment on f ol l owing t hings (ht t p: / / www. agil eal l iance. org):
• Individuals and interact ions over processes and t ool s • Working soft ware over comprehensive document at ion • Cust omer collaborat ion over cont ract negot iat ion • Responding t o change over f ol l owing a pl an
Figure 1. T welve principles of Agile Sof t ware Development Mot ivat ion
Agil e or l ight weight devel opment met hodol ogies are a sol ut ion at t empt t o chal l enge t he dif f icul t y and f ail ure f aced by t he t radit ional / heavyweight / pl an-orient ed met hodol ogies. Wit h t he charact erist ics of agil e devel opment met hodol ogies (described l at er in sect ion 2. 2), devel opers are t rying t o devel op sof t wares quickl y wit hout compromise t he requirement as wel l as t he qual it y of it .
In t he heavyweight environment , devel opers have t he chal l enge t o bring a seemingl y inf init e backl og of sof t ware proj ect s, whil e keeping side by side of t he l at est advances. Survey af t er survey cont inues t o prove t hat most sof t ware proj ect s f ail against some measure of success. Sof t ware are del ivered l at e, over budget and do not meet t he qual it y requirement . Furt hermore, it is al so dif f icul t t o research t he causes of t hese f ail ures. However, t ypical l y, proj ect s f ail f or one or more of t he f ol l owing reasons (Lowel l , L. & Ron, J. , 2004):
• Requirement s t hat are not cl earl y communicat ed
• Requirement s t hat do not sol ve t he business probl em
• Requirement s t hat change prior t o t he compl et ion of t he proj ect
• Sof t ware (code) t hat has not been t est ed
• Sof t ware t hat has not been t est ed as t he user wil l use it
[image:3.516.113.462.85.336.2]• Sof t ware t hat is used f or f unct ions f or which it was not int ended
• Proj ect s not st af f ed wit h t he resources required in t he proj ect pl an
• Schedul e and scope commit ment s are made prior t o f ul l y underst anding t he requirement s or t he t echnical risks
At t he same t ime, numerous proj ect s were very successf ul t hat did not f ol l ow met hods wit h binders of document s, det ail ed designs, and proj ect pl ans. Many experienced programmers were having great success wit hout al l t hese ext ra st eps. The det ermining f act or of proj ect success seemed more and more t o be t he peopl e on t he proj ect , not t he t echnol ogy or t he met hods t hat were being used. These become a mot ivat ion f or devel opers t o l eave t he heavyweight met hodol ogies and t o st art devel oping sof t ware wit h agil e met hodol ogies.
Charact erist ics
Some of t he common charact erist ics of agil e devel opment met hodol ogies are:
Light weight
Agil e met hods are easier t o use t han t radit ional (heavyweight ) met hods because t hey incl ude f ewer inst ruct ions when anal ysing, designing, or impl ement ing t he sof t ware requirement s (Aksit , M. , Mezini, M. , & Unl and, R. , 2002, p. 412–430).
Adapt ive
Heavyweight met hodol ogies f or sof t ware est imat ion and proj ect pl anning work wel l if t he requirement s are cl earl y ident if ied and t hey don't change. However, in most proj ect s, t he requirement s do change during t heir l if et ime, and t heref ore, devel opers need met hodol ogies t hat can adapt wel l t o t he changing requirement s. Agil e met hods permit a f ast response t o requirement changes since changes are considered as t he rul e, not t he except ion.
It erat ive / increment al
In agil e devel opment , devel opers onl y need short proj ect cycl es. An execut abl e syst em is not buil t near t o t he end of a proj ect . Inst ead, it is buil t very earl y and del ivered t o t he cust omer t o be val idat ed.
Cooperat ive
St raight f orward
The met hod it sel f is easy t o l earn and t o modif y, and al so wel l document ed. The websit e www. agil eal l iance. org provides a very good int roduct ion and document at ion on agil e sof t ware devel opment .
People-orient ed
Agil e devel opment met hodol ogies t rul y give power t o t he devel opers. The devel opers make al l t he t echnical decisions, t hey make est imat ions f or work t o be done, t hey sign up f or t asks f or it erat ion, and t hey choose how much process t o f ol l ow in a proj ect . So, it is peopl e-orient ed rat her t han process-orient ed.
Despit e t hose above charact erist ics, pl an-orient ed and agil e met hods are act ual l y not st rict l y rival s. Bot h have t heir range of appl icat ion or ‘ home ground’ . They are used in proj ect s wit h dif f erent charact erist ics (Abrahamsson, P. , Sal o, O. , Ronkainen, J. , & Warst a, J. , 2002):
• Pl an-orient ed met hods in l arge proj ect s wit h st abl e requirement s in a crit ical appl icat ion domain
• Agil e met hods in dynamic environment s and in smal l t eams producing rat her non crit ical appl icat ions
The f ol l owing is a t abl e describing t he range of appl icat ion (home ground) of agil e met hods and pl an-driven met hods:
T able 1. Home ground f or agile and plan driven met hods
Home-ground area Agile met hods Plan-driven methods
Devel opers Agil e, knowl edgeabl e,
col l ocat ed, and col l aborat ive
Pl an-orient ed, adequat e skil l s, access t o ext ernal knowl edge
Cust omers
Dedicat ed, knowl edgeabl e, col l ocat ed, col l aborat ive, represent at ive, and empowered
Access t o knowl edgeabl e, col l aborat ive,
represent at ive, and empowered cust omers.
Requirement s Largel y emergent , rapid change
Knowabl e earl y, l argel y st abl e
Archit ect ure Designed f or current requirement s
Designed f or current and f oreseeabl e requirement s Ref act oring Inexpensive Expensive
Size Smal l er t eams and product s Larger t eams and product s Primaril y
[image:5.516.76.472.437.656.2]Figure 2 (Cockburn, A. , 2002), shows one part icul ar aspect of t hese dif f erences. In t his f igure, t he t wo diminishing curves show t he pot ent ial damage t o a proj ect f rom not invest ing enough t ime and ef f ort in pl anning. The t wo rising curves show t he pot ent ial damage t o t he proj ect f rom spending t oo much t ime and ef f ort in pl anning.
Figure 2. Balancing Discipline and Flexibilit y wit h t he Spiral Model and MBASE
The l ines crossing on t he l ef t indicat e a proj ect f or which pot ent ial damage is rel at ivel y l ow wit h under-pl anning, and rel at ivel y high wit h over-pl anning. Much commercial sof t ware, incl uding Web services f al l int o t his cat egory. The l ines crossing on t he right indicat e a proj ect f or which pot ent ial damage is rel at ivel y high wit h under-pl anning, and f or which much more pl anning woul d have t o be done bef ore damage woul d accrue f rom del ays due t o pl anning. Saf et y-crit ical sof t ware proj ect s f al l int o t his cat egory.
The curves shoul d make it cl ear t hat when t here is risk associat ed wit h t aking a sl ow, del iberat e approach t o pl anning, t hen agil e t echniques are more appropriat e. When t here is risk associat ed wit h skipping pl anning or making mist akes wit h t he pl an, t hen a pl an-driven approach is more appropriat e. The curves il l ust rat e cl earl y t he home t errit ory of each (Cockburn, A. , 2002).
The Main Benefit s of Agile Soft ware Development
In t his sect ion we t ry t o expl ain t he main benef it s of agil e sof t ware devel opment which is hardl y obt ained in t he t radit ional sof t ware devel opment .
Easier t o plan and monit or
Agil e sof t ware devel opment emphasise a cl ose col l aborat ion of t he cust omers and devel opers. This pract ice makes it easier f or devel opers t o pl an and monit or t he proj ect . Moreover, agil e met hodol ogies usual l y recommend it erat ions and present a new version of t he sof t ware of one week t o t hree mont hs.
Provide early f eedback
Because of cl ose col l aborat ion bet ween t he cust omers and devel opers, agil e met hods are very good in providing communicat ion bet ween t hem. Wit h t heir nat ure in f requent l y del ivering working sof t ware, devel opers can get earl y f eedback f rom t he cust omers.
Gives early value t o t he cust omer
Again, because cust omer is invol ved t hroughout t he process of sof t ware devel opment , it may great l y improve cust omer sat isf act ion especial l y if t he cust omer real l y underst ands t heir nat ure of requirement and is wil l ing t o get invol ved.
Enables t he creat ive process
Agil e met hods are peopl e-orient ed rat her t han process-orient ed. They rel y on peopl e’ s expert ise, compet ency and direct col l aborat ion rat her t han on rigorous, document -cent ric processes t o produce high-qual it y sof t ware.
Responsive t o changes
Wit h t radit ional met hods most of t he sof t ware process is pl anned in det ail f or a l onger t ime period. This works wel l if not much is changing and bot h t he appl icat ion domain and sof t ware t echnol ogies are wel l underst ood by t he devel opment t eam. In an appl icat ion domain where changes of t en t ake pl ace, agil e met hods real l y show it s capabil it y (Fowl er, M. , 2000). Wit h an on-sit e cust omer who al ways avail abl e t o provide answers t o any cl arif icat ion devel opers need, t he devel opment is real l y responsive t o changes.
The Main Issues Surrounding Agile Software Development
Limit ed support f or development involving large t eams
In agil e met hods, cont rol and communicat ion mechanisms used are appl icabl e t o smal l t o medium sized t eams. If t he sof t ware devel opment proj ect invol ves a l arge t eam, it wil l require l ess agil e approaches t o t ackl e issues t hat part icul ar t o l arge management (Dan T. , Robert F. , & Bernhard R. , 2002).
Fail t o provide an adequat e level of st ruct ure and necessary document at ion.
Because t he nat ure of agil e sof t ware devel opment t hat emphasise t he devel opment on peopl e and codes, it t hen hardl y present s an adequat e l evel of st ruct ure of t he sof t ware. Dif f erent wit h pl an-driven devel opment , where document at ion is one of t he most import ant part of devel opment , agil e met hods t end t o f ail in providing t he necessary document at ion because it st ress earl y invol vement of peopl e and t he need f or rapid f eedback.
Hard t o develop large and complex sof t ware
In agil e sof t ware devel opment , it is assumed t hat ref act oring can be used t o remove t he need t o design f or change (Dan T. , Robert F. , & Bernhard R. , 2002). However, in l arge compl ex syst ems it may not work properl y because t here may be import ant archit ect ural aspect s t hat are very hard t o change. In such syst em, model s / designs real l y pl ay an import ant rol e in which f unct ional it y is so t ight l y coupl ed and int egrat ed t hat it may not be possibl e t o devel op t he sof t ware increment al l y.
Limit ed support f or reuseabilit y
Agil e processes such as Ext reme Programming f ocus on buil ding sof t ware product s t hat sol ve a specif ic probl em. Whil e t here seems t o be a case f or appl ying agil e processes t o t he devel opment of reusabl e art ef act s, it is not cl ear how agil e processes can be suit abl y adapt ed.
Hard t o handle non-f unct ional requirement s
Cust omers or users t al king about what t hey want t he syst em t o do normal l y do not t hink about resources, maint ainabil it y, port abil it y, saf et y or perf ormance. Some requirement s concerning user int erf ace or saf et y can be el icit ed during t he devel opment process and st il l be int egrat ed. Agil e met hods shoul d incl ude more expl icit l y handl ing non-f unct ional requirement s because t hey can af f ect t he choice of dat abase, programming l anguage or operat ing syst em (Frauke, P. , Armin, E. , & Frank M. , 2003).
Limit ed support f or dist ribut ed development environment s
communicat ion support ed by agil e processes (Dan T. , Robert F. , & Bernhard R. , 2002).
Agile development can af f ect t he st ruct ure wit hin an organizat ion
Agil e sof t ware devel opment spreads out t he decision-making aut horit y. This decision-making approach dif f ers f rom what we see in many organizat ions. In some, t he programmers make many key decisions, incl uding t hose who direct l y connect ed t o business, process, and syst ems requirement s, whil e t heir managers eit her happil y or unwil l ingl y accept t hat way (Wil l iam, L, & Cockburn, A. , 2003).
Incorporat ing Agile Met hodology t o Soft ware Engineering
Agil e Met hodol ogy has general process t hat simil ar t o t he cl assical sof t ware engineering met hodol ogy. It st art s wit h t he requirement anal ysis, t hen f ol l owed by a design process, impl ement at ion, and t est ing. However, t he det ail s t hat happen in each st ep are quit e dif f erent as it does not f ocus on t he model but t he rapidl y changing requirement s. This sect ion describes t he way in which agil e approaches are dif f erent but can be int egrat ed t o t he sof t ware engineering process in general .
Requirement Analysis
In agil e sof t ware devel opment , t o have t he cust omer accessibl e is t he key point . This is t he basis f or f ast f eedback and communicat ion which l eads t o bet t er underst anding of requirement s and devel opment process. For exampl e in Ext reme Programming met hod, it is assumed t hat cust omer is an ideal user represent at ive t hat can answer al l quest ion correct l y and has aut horit y t o make right decisions.
Al l agil e approaches emphasize t hat t al king t o t he cust omer is t he best way t o get t he inf ormat ion needed f or devel opment and t o avoid misunderst anding. If anyt hing is not cl ear or vaguel y def ined, cust omers or devel opers shoul d t ry t o communicat e wit h t he person responsibl e t o avoid indirect t ransf er of knowl edge specif ical l y (Frauke, P. , Armin, E. , & Frank M. , 2003).
However, al t hough agil e met hods are based on st rong cust omer invol vement during t he whol e devel opment process, t here is st il l a probl em. In most cases, agil e met hods ask f or several cust omers wit h dif f erent backgrounds, but somet imes onl y one cust omer is avail abl e t o work wit h t he devel opment t eam. This means t hat not al l t he quest ions arising can be answered in enough det ail .
Design / modelling
dif f erent . In AM, model s are f or exampl e used t o communicat e underst anding of a smal l part of t he syst em under devel opment . Most of t he model s do not become part of t he f inal model of t he syst em because t hey are most l y t hrow-away model s and are drawn on a whit eboard or paper and erased af t er f ul f il l ing t heir purpose (Frauke, P. , Armin, E. , & Frank M. , 2003).
Wit h t his pract ice, agil e met hod is suit abl e f or smal l t o middl e size proj ect s. For l arge and compl ex proj ect s, pl an-driven met hod is more suit abl e because it incorporat es a comprehensive model of sof t ware in t he design phase.
Implement at ion
The most int erest ing and ext reme met hod when it comes t o impl ement at ion is a met hod used in Ext reme Programming. It is cal l ed “pai r pr ogr ammi ng” . In XP, programmers work t oget her in pairs and as a
group, wit h simpl e design and obsessivel y t est ed code, improving t he design cont inual l y t o keep it sat isf y t he current needs. However, pair programming doesn't mean al l code is al ways writ t en by t wo programmers working t oget her using one comput er. Some code is best impl ement ed individual l y, and some code is best impl ement ed in a pair.
T est ing
In Ext reme Programming, devel opers writ e unit t est s f or everyt hing bef ore t hey writ e t he main code (Sharma, P. , 2004). They writ e unit t est s f or al l t he normal condit ions, as wel l as f or any unusual circumst ances (boundary condit ions, et c. ). Then, t hey run al l unit t est s and if t hey f ind some probl em wit h t he code, t hey add more unit t est s t o isol at e t he probl em. Af t er t hat t hey modif y t he code t o f ix t he bug, and rerun al l t he t est s.
Tools for Agile Met hodology
There are several t ool s in t he market t hat can be used f or t he agil e approach. One of t he t ool s is cal l ed VersionOne (www. versionone. net). Using such t ool , we can pl an and manage our agil e sof t ware devel opment s. VersionOne is f ocused on t he pl anning, management , and del ivery of rapidl y changing, unpredict abl e sof t ware devel opment proj ect s. It al so provides several t empl at e proj ect s f or Scrum, Ext reme Programming or DSDM met hods in a web based environment .
Anot her t ool is cal l ed TP (www. t arget process. com) t hat specif ical l y designed t o simpl if y pl anning, t racking, and qual it y assurance act ivit ies.
Conclusion
main component of t he f inal sof t ware. In each sof t ware engineering phases, agil e met hods have unique approach t hat f ocus on f eedback and change. Theref ore, t his met hod is bel ieved can l everage t he product ivit y of programmers.
Bibliography
Abrahamsson, P. , Sal o, O. , Ronkainen, J. , & Warst a, J. (2002). ‘ Agil e Sof t ware Devel opment Met hods: Review and Anal ysis’ , VTT Publ icat ions.
Agil e Al l iance Page, [ Onl ine] , Avail abl e: ht t p: / / www. agil eal l iance. org [ 20 Oct ober 2004]
Aksit , M. , Mezini, M. , & Unl and, R (Eds. ). (2002). ‘ Do We Need ‘ Agil e’ Sof t ware Devel opment Tool s?’ , Springer-Verl ag Berl in Heidl berg, pp. 412–430.
Cockburn, A. 2002, Learning From Agil e Sof t ware Devel opment - Part One,
[ Onl ine] , Avail abl e: ht t p: / / www. st sc. hil l . af . mil / crosst al k/ 2002/ 10/ cockburn. ht ml [ 29
November 2004]
Dan T. , Robert F. , & Bernhard R. (2002). Limit at ions of Agil e Sof t ware
Processes, [ Onl ine] , Avail abl e: ht t p: / / www. agil eal l iance. org/ art icl es/ art icl es/ Limit at ionsof Agil e. pdf
[ 27 November 2004]
Fowl er, M. 2000, The New Met hodol ogy, [ Onl ine] , Avail abl e: ht t p: / / www. t hought works. com/ us/ l ibrary/ newMet hodol ogy. pdf [ 20 November 2004]
Frauke, P. , Armin, E. , & Frank M. 2003, Requirement s Engineering and Agil e Sof t ware Devel opment , [ Onl ine] , Avail abl e: ht t p: / / www. sern. ucal gary. ca/ ~mil os/ papers/ 2003/ Paet schEberl einMau rer. pdf [ 26 November 2004]
Larman, C. & Basil i, V. R. (2003). ‘ It erat ive and Increment al Devel opment : A Brief Hist ory’ , IEEE Comput er, vol . 36, no. 6, pp. 47-56.
Lowel l , L. & Ron, J. (2004). ‘ Ext reme Programming and Agil e Sof t ware Devel opment Met hodol ogies’ , Inf ormat ion Syst ems Management , vol . 21, pp. 41-61.
