An Overview of Agile Software Development Methodology and Its Relevance to Software Engineering.
An Overview of Agile Software Development Methodology
and Its Relevance to Software Engineering
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
Introduction
Agile sof t ware development approaches have become more and more
popular during t he last f ew years. Agile pract ices have been developed
wit h t he int ent ion t o deliver 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 people say t hat agil e
sof t ware development is t he “ modern” repl acement of t he wat erf all model
(Larman, C. & Basili, V. R. , 2003).
The probl em wit h t radit ional plan-driven sof t ware development
met hodologies (e. g. wat erf all) are t hey are t oo mechanist ic t o be used in
det ail. As a result , indust rial sof t ware devel opers have become scept ical
about new solut ions t hat are dif f icult t o grasp and t hus remain unused
(Abrahamsson, P. , Salo, O. , Ronkainen, J. , & Warst a, J. , 2002).
There are many met hods classif ied as agile sof t ware devel opment :
• Adapt ive Sof t ware Development ,
• Agile Modell ing,
• Cryst al,
• Dynamic Syst em Development Met hodology,
• Feat ure Driven Development ,
• SCRUM and
• Ext reme Programming (XP)
(ht t p: / / www. ext remeprogramming. org).
69
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
Dif f erent aut hors emphasised dif f erent aspect s of sof t ware development .
Some f ocused on approaches t o planning and requirement s; some f ocused
on ways t o writ e sof t ware t hat could be changed more easily; and some
f ocused on t he people int eract ions t hat allow sof t ware developers t o more
easily 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 hodologies.
Overview of Agile Software Development
Ref er t o Addison-Wesley Longman dict ionary, t he t erm “ Agile ” means able
t o move quickly and easily. Thus, “ Agility” f or a sof t ware development
organizat ion, means t he abilit y t o adapt and react quick and ef f ect ively
and appropriat ely t o changes in it s environment and t o demands imposed
by t his environment (Abrahamsson, P. , Salo, O. , Ronkainen, J. , & Warst a,
J. , 2002).
In t he f all of 1999, Ext reme Programming, Embrace Change1 was publ ished
and t he t rend had f ound it s cat alyst . In early 2001, t he dif f erent
innovat ors who were creat ing dif f erent agile met hodologies held a ret reat
and scribed t he "Agile Manif est o f or Sof t ware Development . " (Lowell , L. &
Ron, J. , 2004)
This manif est o emphasises t he development on f ollowing
(ht t p: / / www. agilealliance. org):
• Individuals and interactions over processes and t ools
• Working software over comprehensive document at ion
• Customer collaboration over cont ract negot iat ion
• Responding to change over f ollowing a plan
t hings
They declared t he 12 principles of Agile Sof t ware Development as
illust rat ed in f igure 1.
70
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
Figure 1. T welve principles of Agile Soft ware Development
Mot ivat ion
Agile or light weight development met hodologies are a solut ion at t empt t o
challenge t he dif f icult y and f ailure f aced by t he t radit ional / heavyweight
/ plan-orient ed met hodologies.
Wit h t he charact erist ics of agile
development met hodol ogies (described lat er in sect ion 2. 2), developers
are t rying t o develop sof t wares quickl y wit hout compromise t he
requirement as wel l as t he qualit y of it .
In t he heavyweight environment , developers have t he challenge t o bring a
seemingly inf init e backlog of sof t ware proj ect s, while keeping side by side
of t he lat 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
delivered l at e, over budget and do not meet t he qualit y requirement .
Furt hermore, it is also dif f icult t o research t he causes of t hese f ailures.
However, t ypically, proj ect s f ail f or one or more of t he f ollowing reasons
(Lowell, L. & Ron, J. , 2004):
•
•
•
•
•
•
Requirement s t hat are not clearly communicat ed
Requirement s t hat do not solve t he business problem
Requirement s t hat change prior t o t he complet 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 will use it
Sof t ware developed such t hat it is dif f icult t o modif y
71
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
•
•
•
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 plan
Schedule and scope commit ment s are made prior t o f ully
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 ollow met hods wit h binders of document s, det ailed designs, and proj ect
plans. Many experienced programmers were having great success wit hout
all 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 people on t he proj ect , not t he t echnology or t he
met hods t hat were being used.
These become a mot ivat ion f or
developers t o leave t he heavyweight met hodologies and t o st art
developing sof t ware wit h agile met hodol ogies.
Charact erist ics
Some of t he common charact erist ics of agile development met hodol ogies
are:
Light weight
Agile met hods are easier t o use t han t radit ional (heavyweight ) met hods
because t hey include f ewer inst ruct ions when anal ysing, designing, or
implement ing t he sof t ware requirement s (Aksit , M. , Mezini, M. , & Unland,
R. , 2002, p. 412–430).
Adapt ive
Heavyweight met hodol ogies f or sof t ware est imat ion and proj ect planning
work well if t he requirement s are clearly ident if ied and t hey don't change.
However, in most proj ect s, t he requirement s do change during t heir
lif et ime, and t heref ore, developers need met hodol ogies t hat can adapt
well t o t he changing requirement s. Agile met hods permit a f ast response
t o requirement changes since changes are considered as t he rule, not t he
except ion.
It erat ive / increment al
In agile development , developers only need short proj ect cycles. An
execut able syst em is not built near t o t he end of a proj ect . Inst ead, it is
built very early and del ivered t o t he cust omer t o be validat ed.
Cooperat ive
Agile development is cooperat ive since cust omers and developers working
const ant ly t oget her wit h close communicat ion. The cust omer is assumed t o
be present at t he development sit e and is involved in t he development
process.
72
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
St raight forward
The met hod it self is easy t o learn and t o modif y, and also well
document ed. The websit e www. agilealliance. org provides a very good
int roduct ion and document at ion on agile sof t ware development .
People-orient ed
Agile development met hodologies t ruly give power t o t he developers. The
developers make all 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 ollow in a proj ect . So, it is people-orient ed rat her t han
process-orient ed.
Despit e t hose above charact erist ics, plan-orient ed and agile met hods are
act ually not st rict ly rivals. Bot h have t heir range of applicat ion or ‘ home
ground’ . They are used in proj ect s wit h dif f erent charact erist ics
(Abrahamsson, P. , Salo, O. , Ronkainen, J. , & Warst a, J. , 2002):
•
•
Plan-orient ed met hods in large proj ect s wit h st able requirement s in
a crit ical applicat ion domain
Agile met hods in dynamic environment s and in small t eams
producing rat her non crit ical appl icat ions
The f ollowing is a t abl e describing t he range of applicat ion (home ground)
of agile met hods and pl an-driven met hods:
T able 1. Home ground for agile and plan driven met hods
Homeground area
Developers
Agile met hods
Agile, knowl edgeable,
collocat ed, and collaborat ive
Dedicat ed, knowledgeable,
collocat ed, collaborat ive,
Cust omers
represent at ive, and
empowered
Largely emergent , rapid
Requirement s
change
Designed f or current
Archit ect ure
requirement s
Ref act oring
Inexpensive
Size
Smaller t eams and product s
Primarily
Rapid value
obj ect ive
Plan-driven methods
Plan-orient ed, adequat e
skills, access t o ext ernal
knowledge
Access t o knowledgeabl e,
collaborat ive,
represent at ive, and
empowered cust omers.
Knowable early, largel y
st able
Designed f or current and
f oreseeable requirement s
Expensive
Larger t eams and product s
High assurance
73
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
Figure 2 (Cockburn, A. , 2002), shows one part icular 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 planning.
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 planning.
Figure 2. Balancing Discipline and Flexibilit y wit h t he Spiral Model
and MBASE
The lines crossing on t he lef t indicat e a proj ect f or which pot ent ial
damage is relat ively l ow wit h under-planning, and relat ively high wit h
over-planning. Much commercial sof t ware, including Web services f all int o
t his cat egory. The lines crossing on t he right indicat e a proj ect f or which
pot ent ial damage is relat ively high wit h under-planning, and f or which
much more planning would have t o be done bef ore damage would accrue
f rom delays due t o planning. Saf et y-crit ical sof t ware proj ect s f all int o t his
cat egory.
The curves should make it clear t hat when t here is risk associat ed wit h
t aking a slow, deliberat e approach t o planning, t hen agile t echniques are
more appropriat e. When t here is risk associat ed wit h skipping planning or
making mist akes wit h t he plan, t hen a pl an-driven approach is more
appropriat e. The curves illust rat e clearly t he home t errit ory of each
(Cockburn, A. , 2002).
The Main Benefits of Agile Software Development
In comparison t o t radit ional sof t ware development , agile development is
less document -orient ed and more code-orient ed. This, however, is not it s
key charact erist ic but rat her a ref lect ion of t wo deeper dif f erences
bet ween t he t wo st yles (Frauke, P. , Armin, E. , & Frank M. , 2003).
74
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
In t his sect ion we t ry t o explain t he main benef it s of agile sof t ware
development which is hardly obt ained in t he t radit ional sof t ware
development .
Easier t o plan and monit or
Agile sof t ware development emphasise a close collaborat ion of t he
cust omers and developers. This pract ice makes it easier f or developers t o
plan and monit or t he proj ect . Moreover, agile met hodol ogies usually
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 feedback
Because of close coll aborat ion bet ween t he cust omers and developers,
agile met hods are very good in providing communicat ion bet ween t hem.
Wit h t heir nat ure in f requent ly delivering working sof t ware, devel opers
can get early f eedback f rom t he cust omers.
Gives early value t o t he cust omer
Again, because cust omer is involved t hroughout t he process of sof t ware
development , it may great ly improve cust omer sat isf act ion especially if
t he cust omer reall y underst ands t heir nat ure of requirement and is willing
t o get involved.
Enables t he creat ive process
Agile met hods are people-orient ed rat her t han process-orient ed. They rel y
on people’ s expert ise, compet ency and direct collaborat ion rat her t han on
rigorous, document -cent ric processes t o produce high-qualit y sof t ware.
Responsive t o changes
Wit h t radit ional met hods most of t he sof t ware process is planned in det ail
f or a longer t ime period. This works well if not much is changing and bot h
t he applicat ion domain and sof t ware t echnologies are well underst ood by
t he development t eam. In an applicat ion domain where changes of t en t ake
place, agile met hods really show it s capabilit y (Fowler, M. , 2000). Wit h an
on-sit e cust omer who always available t o provide answers t o any
clarif icat ion developers need, t he development is really responsive t o
changes.
The Main Issues Surrounding Agile Software Development
While it seems t hat t here have been many sof t ware devel opment proj ect
successes based on agil e processes, so f ar most of t hese success st ories are
only based on personal experiences (Dan T. , Robert F. , & Bernhard R. ,
2002). In t his sect ion, we t ry t o explain t he main issues and l imit at ion
surrounding t he agile approaches:
75
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
Limit ed support for development involving large t eams
In agile met hods, cont rol and communicat ion mechanisms used are
applicable t o small t o medium sized t eams. If t he sof t ware development
proj ect involves a l arge t eam, it will require less agile approaches t o
t ackle issues t hat part icular t o large management (Dan T. , Robert F. , &
Bernhard R. , 2002).
Fail t o provide an adequat e level of
document at ion.
st ruct ure and necessary
Because t he nat ure of agile sof t ware development t hat emphasise t he
development on people and codes, it t hen hardly present s an adequat e
level of st ruct ure of t he sof t ware.
Dif f erent wit h plan-driven
development , where document at ion is one of t he most import ant part of
development , agile met hods t end t o f ail in providing t he necessary
document at ion because it st ress early involvement of people and t he need
f or rapid f eedback.
Hard t o develop large and complex soft ware
In agile sof t ware development , 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 large complex syst ems it may not work properly
because t here may be import ant archit ect ural aspect s t hat are very hard
t o change. In such syst em, models / designs really play an import ant role
in which f unct ionalit y is so t ight ly coupled and int egrat ed t hat it may not
be possible t o develop t he sof t ware increment ally.
Limit ed support for reuseabilit y
Agile processes such as Ext reme Programming f ocus on building sof t ware
product s t hat solve a specif ic problem. While t here seems t o be a case f or
applying agile processes t o t he development of reusable art ef act s, it is not
clear how agile processes can be suit ably adapt ed.
Hard t o handle non-funct ional requirement s
Cust omers or users t alking about what t hey want t he syst em t o do normally
do not t hink about resources, maint ainabilit y, port abilit y, saf et y or
perf ormance. Some requirement s concerning user int erf ace or saf et y can
be elicit ed during t he development process and st ill be int egrat ed. Agile
met hods should incl ude more explicit ly handling non-f unct ional
requirement s because t hey can af f ect t he choice of dat abase,
programming language or operat ing syst em (Frauke, P. , Armin, E. , & Frank
M. , 2003).
Limit ed support for dist ribut ed development environment s
Development environment s in which t eam members and cust omers are
physicall y dist ribut ed may not be able t o accommodat e t he f ace-t o-f ace
76
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
communicat ion support ed by agile processes (Dan T. , Robert F. , &
Bernhard R. , 2002).
Agile development can affect t he st ruct ure wit hin an organizat ion
Agile sof t ware development 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,
including t hose who direct ly connect ed t o business, process, and syst ems
requirement s, while t heir managers eit her happily or unwillingly accept
t hat way (William, L, & Cockburn, A. , 2003).
Incorporating Agile Methodology to Software Engineering
Agile Met hodology has general process t hat similar t o t he classical sof t ware
engineering met hodology. It st art s wit h t he requirement analysis, t hen
f ollowed by a design process, impl ement at ion, and t est ing. However, t he
det ails 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 rapidly changing requirement s. This sect ion describes
t he way in which agile 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 agile sof t ware devel opment , t o have t he cust omer accessible 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 development process. For
example in Ext reme Programming met hod, it is assumed t hat cust omer is
an ideal user represent at ive t hat can answer all quest ion correct ly and has
aut horit y t o make right decisions.
All agile approaches emphasize t hat t alking t o t he cust omer is t he best
way t o get t he inf ormat ion needed f or development and t o avoid
misunderst anding. If anyt hing is not cl ear or vaguely def ined, cust omers or
developers should t ry t o communicat e wit h t he person responsible t o avoid
indirect t ransf er of knowledge specif ically (Frauke, P. , Armin, E. , & Frank
M. , 2003).
However, alt hough agile met hods are based on st rong cust omer
involvement during t he whole development process, t here is st ill a
problem. In most cases, agile met hods ask f or several cust omers wit h
dif f erent backgrounds, but somet imes only one cust omer is availabl e t o
work wit h t he development t eam. This means t hat not all t he quest ions
arising can be answered in enough det ail.
Design / modelling
One of agile met hods t hat incorporat e modelling very much is Agil e
Modelling (AM). However, alt hough modelling is used in AM, t he purpose is
77
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
dif f erent . In AM, models are f or example used t o communicat e
underst anding of a small part of t he syst em under development . Most of
t he models do not become part of t he f inal model of t he syst em because
t hey are most ly t hrow-away models and are drawn on a whit eboard or
paper and erased af t er f ulf illing t heir purpose (Frauke, P. , Armin, E. , &
Frank M. , 2003).
Wit h t his pract ice, agile met hod is suit able f or small t o middle size
proj ect s. For large and complex proj ect s, plan-driven met hod is more
suit able 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
implement at ion is a met hod used in Ext reme Programming. It is called
“ pai r pr ogr ammi ng” . In XP, programmers work t oget her in pairs and as a
group, wit h simple design and obsessively t est ed code, improving t he
design cont inually t o keep it sat isf y t he current needs. However, pair
programming doesn't mean all code is always writ t en by t wo programmers
working t oget her using one comput er. Some code is best implement ed
individually, and some code is best implement ed in a pair.
T est ing
In Ext reme Programming, developers 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 all
t he normal condit ions, as well as f or any unusual circumst ances (boundary
condit ions, et c. ). Then, t hey run all unit t est s and if t hey f ind some
problem wit h t he code, t hey add more unit t est s t o isolat e t he problem.
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 ools in t he market t hat can be used f or t he agile
approach. One of t he t ools is called VersionOne (www. versionone. net ).
Using such t ool, we can plan and manage our agile sof t ware development s.
VersionOne is f ocused on t he planning, management , and delivery of
rapidl y changing, unpredict able sof t ware development proj ect s.
It also
provides several t emplat e proj ect s f or Scrum, Ext reme Programming or
DSDM met hods in a web based environment .
Anot her t ool is called TP (www. t arget process. com) t hat specif ically
designed t o simplif y planning, t racking, and qualit y assurance act ivit ies.
Conclusion
In conclusion, we can say t hat t he agile met hodology is an alt ernat ive t o
plan-driven met hodology (eg: UML or Wat erf all Model) in t he development
of qualit y sof t ware. It is also very suit able f or small t o middle size
proj ect s because developers do not usually concent rat e on models as t he
78
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
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 believed can leverage t he product ivit y
of programmers.
Bibliography
Abrahamsson, P. , Sal o, O. , Ronkainen, J. , & Warst a, J. (2002). ‘ Agile
Sof t ware Development
Met hods: Review and Analysis’ , VTT
Publicat ions.
Agile Alliance Page, [ Online] , Available: ht t p: / / www. agilealliance. org [ 20
Oct ober 2004]
Aksit , M. , Mezini, M. , & Unland, R (Eds. ). (2002). ‘ Do We Need ‘ Agile’
Sof t ware Development Tools?’ , Springer-Verl ag Berlin Heidlberg, pp.
412–430.
Cockburn, A. 2002, Learning From Agil e Sof t ware Development - Part One,
[ Online] ,
Available:
ht t p: / / www. st sc. hill. af . mil/ crosst al k/ 2002/ 10/ cockburn. ht ml
[ 29
November 2004]
Dan T. , Robert F. , & Bernhard R. (2002). Limit at ions of Agile Sof t ware
Processes,
[ Online] ,
Available:
ht t p: / / www. agileall iance. org/ art icles/ art icles/ Limit at ionsof Agile. pdf
[ 27 November 2004]
Fowler, M. 2000, The New Met hodol ogy, [ Onl ine] , Avail able:
ht t p: / / www. t hought works. com/ us/ l ibrary/ newMet hodology. pdf
[ 20
November 2004]
Frauke, P. , Armin, E. , & Frank M. 2003, Requirement s Engineering and
Agile
Sof t ware
Development ,
[ Online] ,
Available:
ht t p: / / www. sern. ucalgary. ca/ ~milos/ papers/ 2003/ Paet schEberleinMau
rer. pdf [ 26 November 2004]
Larman, C. & Basili, V. R. (2003). ‘ It erat ive and Increment al Development :
A Brief Hist ory’ , IEEE Comput er, vol. 36, no. 6, pp. 47-56.
Lowell, L. & Ron, J. (2004). ‘ Ext reme Programming and Agile Sof t ware
Development Met hodologies’ , Inf ormat ion Syst ems Management , vol.
21, pp. 41-61.
Sharma, P. (2004). An Int roduct ion t o Ext reme Programming, [ Online] ,
Available: ht t p: / / www. advisor. com/ doc/ 13571 [ 28 November 2004]
79
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
William, L, & Cockburn, A. (2003) ‘ Agile Sof t ware Devel opment : It 's about
Feedback and Change’ , IEEE Comput er Societ y, vol. 3, pp. 39-44.
80
and Its Relevance to Software Engineering
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
Introduction
Agile sof t ware development approaches have become more and more
popular during t he last f ew years. Agile pract ices have been developed
wit h t he int ent ion t o deliver 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 people say t hat agil e
sof t ware development is t he “ modern” repl acement of t he wat erf all model
(Larman, C. & Basili, V. R. , 2003).
The probl em wit h t radit ional plan-driven sof t ware development
met hodologies (e. g. wat erf all) are t hey are t oo mechanist ic t o be used in
det ail. As a result , indust rial sof t ware devel opers have become scept ical
about new solut ions t hat are dif f icult t o grasp and t hus remain unused
(Abrahamsson, P. , Salo, O. , Ronkainen, J. , & Warst a, J. , 2002).
There are many met hods classif ied as agile sof t ware devel opment :
• Adapt ive Sof t ware Development ,
• Agile Modell ing,
• Cryst al,
• Dynamic Syst em Development Met hodology,
• Feat ure Driven Development ,
• SCRUM and
• Ext reme Programming (XP)
(ht t p: / / www. ext remeprogramming. org).
69
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
Dif f erent aut hors emphasised dif f erent aspect s of sof t ware development .
Some f ocused on approaches t o planning and requirement s; some f ocused
on ways t o writ e sof t ware t hat could be changed more easily; and some
f ocused on t he people int eract ions t hat allow sof t ware developers t o more
easily 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 hodologies.
Overview of Agile Software Development
Ref er t o Addison-Wesley Longman dict ionary, t he t erm “ Agile ” means able
t o move quickly and easily. Thus, “ Agility” f or a sof t ware development
organizat ion, means t he abilit y t o adapt and react quick and ef f ect ively
and appropriat ely t o changes in it s environment and t o demands imposed
by t his environment (Abrahamsson, P. , Salo, O. , Ronkainen, J. , & Warst a,
J. , 2002).
In t he f all of 1999, Ext reme Programming, Embrace Change1 was publ ished
and t he t rend had f ound it s cat alyst . In early 2001, t he dif f erent
innovat ors who were creat ing dif f erent agile met hodologies held a ret reat
and scribed t he "Agile Manif est o f or Sof t ware Development . " (Lowell , L. &
Ron, J. , 2004)
This manif est o emphasises t he development on f ollowing
(ht t p: / / www. agilealliance. org):
• Individuals and interactions over processes and t ools
• Working software over comprehensive document at ion
• Customer collaboration over cont ract negot iat ion
• Responding to change over f ollowing a plan
t hings
They declared t he 12 principles of Agile Sof t ware Development as
illust rat ed in f igure 1.
70
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
Figure 1. T welve principles of Agile Soft ware Development
Mot ivat ion
Agile or light weight development met hodologies are a solut ion at t empt t o
challenge t he dif f icult y and f ailure f aced by t he t radit ional / heavyweight
/ plan-orient ed met hodologies.
Wit h t he charact erist ics of agile
development met hodol ogies (described lat er in sect ion 2. 2), developers
are t rying t o develop sof t wares quickl y wit hout compromise t he
requirement as wel l as t he qualit y of it .
In t he heavyweight environment , developers have t he challenge t o bring a
seemingly inf init e backlog of sof t ware proj ect s, while keeping side by side
of t he lat 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
delivered l at e, over budget and do not meet t he qualit y requirement .
Furt hermore, it is also dif f icult t o research t he causes of t hese f ailures.
However, t ypically, proj ect s f ail f or one or more of t he f ollowing reasons
(Lowell, L. & Ron, J. , 2004):
•
•
•
•
•
•
Requirement s t hat are not clearly communicat ed
Requirement s t hat do not solve t he business problem
Requirement s t hat change prior t o t he complet 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 will use it
Sof t ware developed such t hat it is dif f icult t o modif y
71
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
•
•
•
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 plan
Schedule and scope commit ment s are made prior t o f ully
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 ollow met hods wit h binders of document s, det ailed designs, and proj ect
plans. Many experienced programmers were having great success wit hout
all 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 people on t he proj ect , not t he t echnology or t he
met hods t hat were being used.
These become a mot ivat ion f or
developers t o leave t he heavyweight met hodologies and t o st art
developing sof t ware wit h agile met hodol ogies.
Charact erist ics
Some of t he common charact erist ics of agile development met hodol ogies
are:
Light weight
Agile met hods are easier t o use t han t radit ional (heavyweight ) met hods
because t hey include f ewer inst ruct ions when anal ysing, designing, or
implement ing t he sof t ware requirement s (Aksit , M. , Mezini, M. , & Unland,
R. , 2002, p. 412–430).
Adapt ive
Heavyweight met hodol ogies f or sof t ware est imat ion and proj ect planning
work well if t he requirement s are clearly ident if ied and t hey don't change.
However, in most proj ect s, t he requirement s do change during t heir
lif et ime, and t heref ore, developers need met hodol ogies t hat can adapt
well t o t he changing requirement s. Agile met hods permit a f ast response
t o requirement changes since changes are considered as t he rule, not t he
except ion.
It erat ive / increment al
In agile development , developers only need short proj ect cycles. An
execut able syst em is not built near t o t he end of a proj ect . Inst ead, it is
built very early and del ivered t o t he cust omer t o be validat ed.
Cooperat ive
Agile development is cooperat ive since cust omers and developers working
const ant ly t oget her wit h close communicat ion. The cust omer is assumed t o
be present at t he development sit e and is involved in t he development
process.
72
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
St raight forward
The met hod it self is easy t o learn and t o modif y, and also well
document ed. The websit e www. agilealliance. org provides a very good
int roduct ion and document at ion on agile sof t ware development .
People-orient ed
Agile development met hodologies t ruly give power t o t he developers. The
developers make all 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 ollow in a proj ect . So, it is people-orient ed rat her t han
process-orient ed.
Despit e t hose above charact erist ics, plan-orient ed and agile met hods are
act ually not st rict ly rivals. Bot h have t heir range of applicat ion or ‘ home
ground’ . They are used in proj ect s wit h dif f erent charact erist ics
(Abrahamsson, P. , Salo, O. , Ronkainen, J. , & Warst a, J. , 2002):
•
•
Plan-orient ed met hods in large proj ect s wit h st able requirement s in
a crit ical applicat ion domain
Agile met hods in dynamic environment s and in small t eams
producing rat her non crit ical appl icat ions
The f ollowing is a t abl e describing t he range of applicat ion (home ground)
of agile met hods and pl an-driven met hods:
T able 1. Home ground for agile and plan driven met hods
Homeground area
Developers
Agile met hods
Agile, knowl edgeable,
collocat ed, and collaborat ive
Dedicat ed, knowledgeable,
collocat ed, collaborat ive,
Cust omers
represent at ive, and
empowered
Largely emergent , rapid
Requirement s
change
Designed f or current
Archit ect ure
requirement s
Ref act oring
Inexpensive
Size
Smaller t eams and product s
Primarily
Rapid value
obj ect ive
Plan-driven methods
Plan-orient ed, adequat e
skills, access t o ext ernal
knowledge
Access t o knowledgeabl e,
collaborat ive,
represent at ive, and
empowered cust omers.
Knowable early, largel y
st able
Designed f or current and
f oreseeable requirement s
Expensive
Larger t eams and product s
High assurance
73
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
Figure 2 (Cockburn, A. , 2002), shows one part icular 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 planning.
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 planning.
Figure 2. Balancing Discipline and Flexibilit y wit h t he Spiral Model
and MBASE
The lines crossing on t he lef t indicat e a proj ect f or which pot ent ial
damage is relat ively l ow wit h under-planning, and relat ively high wit h
over-planning. Much commercial sof t ware, including Web services f all int o
t his cat egory. The lines crossing on t he right indicat e a proj ect f or which
pot ent ial damage is relat ively high wit h under-planning, and f or which
much more planning would have t o be done bef ore damage would accrue
f rom delays due t o planning. Saf et y-crit ical sof t ware proj ect s f all int o t his
cat egory.
The curves should make it clear t hat when t here is risk associat ed wit h
t aking a slow, deliberat e approach t o planning, t hen agile t echniques are
more appropriat e. When t here is risk associat ed wit h skipping planning or
making mist akes wit h t he plan, t hen a pl an-driven approach is more
appropriat e. The curves illust rat e clearly t he home t errit ory of each
(Cockburn, A. , 2002).
The Main Benefits of Agile Software Development
In comparison t o t radit ional sof t ware development , agile development is
less document -orient ed and more code-orient ed. This, however, is not it s
key charact erist ic but rat her a ref lect ion of t wo deeper dif f erences
bet ween t he t wo st yles (Frauke, P. , Armin, E. , & Frank M. , 2003).
74
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
In t his sect ion we t ry t o explain t he main benef it s of agile sof t ware
development which is hardly obt ained in t he t radit ional sof t ware
development .
Easier t o plan and monit or
Agile sof t ware development emphasise a close collaborat ion of t he
cust omers and developers. This pract ice makes it easier f or developers t o
plan and monit or t he proj ect . Moreover, agile met hodol ogies usually
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 feedback
Because of close coll aborat ion bet ween t he cust omers and developers,
agile met hods are very good in providing communicat ion bet ween t hem.
Wit h t heir nat ure in f requent ly delivering working sof t ware, devel opers
can get early f eedback f rom t he cust omers.
Gives early value t o t he cust omer
Again, because cust omer is involved t hroughout t he process of sof t ware
development , it may great ly improve cust omer sat isf act ion especially if
t he cust omer reall y underst ands t heir nat ure of requirement and is willing
t o get involved.
Enables t he creat ive process
Agile met hods are people-orient ed rat her t han process-orient ed. They rel y
on people’ s expert ise, compet ency and direct collaborat ion rat her t han on
rigorous, document -cent ric processes t o produce high-qualit y sof t ware.
Responsive t o changes
Wit h t radit ional met hods most of t he sof t ware process is planned in det ail
f or a longer t ime period. This works well if not much is changing and bot h
t he applicat ion domain and sof t ware t echnologies are well underst ood by
t he development t eam. In an applicat ion domain where changes of t en t ake
place, agile met hods really show it s capabilit y (Fowler, M. , 2000). Wit h an
on-sit e cust omer who always available t o provide answers t o any
clarif icat ion developers need, t he development is really responsive t o
changes.
The Main Issues Surrounding Agile Software Development
While it seems t hat t here have been many sof t ware devel opment proj ect
successes based on agil e processes, so f ar most of t hese success st ories are
only based on personal experiences (Dan T. , Robert F. , & Bernhard R. ,
2002). In t his sect ion, we t ry t o explain t he main issues and l imit at ion
surrounding t he agile approaches:
75
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
Limit ed support for development involving large t eams
In agile met hods, cont rol and communicat ion mechanisms used are
applicable t o small t o medium sized t eams. If t he sof t ware development
proj ect involves a l arge t eam, it will require less agile approaches t o
t ackle issues t hat part icular t o large management (Dan T. , Robert F. , &
Bernhard R. , 2002).
Fail t o provide an adequat e level of
document at ion.
st ruct ure and necessary
Because t he nat ure of agile sof t ware development t hat emphasise t he
development on people and codes, it t hen hardly present s an adequat e
level of st ruct ure of t he sof t ware.
Dif f erent wit h plan-driven
development , where document at ion is one of t he most import ant part of
development , agile met hods t end t o f ail in providing t he necessary
document at ion because it st ress early involvement of people and t he need
f or rapid f eedback.
Hard t o develop large and complex soft ware
In agile sof t ware development , 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 large complex syst ems it may not work properly
because t here may be import ant archit ect ural aspect s t hat are very hard
t o change. In such syst em, models / designs really play an import ant role
in which f unct ionalit y is so t ight ly coupled and int egrat ed t hat it may not
be possible t o develop t he sof t ware increment ally.
Limit ed support for reuseabilit y
Agile processes such as Ext reme Programming f ocus on building sof t ware
product s t hat solve a specif ic problem. While t here seems t o be a case f or
applying agile processes t o t he development of reusable art ef act s, it is not
clear how agile processes can be suit ably adapt ed.
Hard t o handle non-funct ional requirement s
Cust omers or users t alking about what t hey want t he syst em t o do normally
do not t hink about resources, maint ainabilit y, port abilit y, saf et y or
perf ormance. Some requirement s concerning user int erf ace or saf et y can
be elicit ed during t he development process and st ill be int egrat ed. Agile
met hods should incl ude more explicit ly handling non-f unct ional
requirement s because t hey can af f ect t he choice of dat abase,
programming language or operat ing syst em (Frauke, P. , Armin, E. , & Frank
M. , 2003).
Limit ed support for dist ribut ed development environment s
Development environment s in which t eam members and cust omers are
physicall y dist ribut ed may not be able t o accommodat e t he f ace-t o-f ace
76
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
communicat ion support ed by agile processes (Dan T. , Robert F. , &
Bernhard R. , 2002).
Agile development can affect t he st ruct ure wit hin an organizat ion
Agile sof t ware development 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,
including t hose who direct ly connect ed t o business, process, and syst ems
requirement s, while t heir managers eit her happily or unwillingly accept
t hat way (William, L, & Cockburn, A. , 2003).
Incorporating Agile Methodology to Software Engineering
Agile Met hodology has general process t hat similar t o t he classical sof t ware
engineering met hodology. It st art s wit h t he requirement analysis, t hen
f ollowed by a design process, impl ement at ion, and t est ing. However, t he
det ails 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 rapidly changing requirement s. This sect ion describes
t he way in which agile 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 agile sof t ware devel opment , t o have t he cust omer accessible 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 development process. For
example in Ext reme Programming met hod, it is assumed t hat cust omer is
an ideal user represent at ive t hat can answer all quest ion correct ly and has
aut horit y t o make right decisions.
All agile approaches emphasize t hat t alking t o t he cust omer is t he best
way t o get t he inf ormat ion needed f or development and t o avoid
misunderst anding. If anyt hing is not cl ear or vaguely def ined, cust omers or
developers should t ry t o communicat e wit h t he person responsible t o avoid
indirect t ransf er of knowledge specif ically (Frauke, P. , Armin, E. , & Frank
M. , 2003).
However, alt hough agile met hods are based on st rong cust omer
involvement during t he whole development process, t here is st ill a
problem. In most cases, agile met hods ask f or several cust omers wit h
dif f erent backgrounds, but somet imes only one cust omer is availabl e t o
work wit h t he development t eam. This means t hat not all t he quest ions
arising can be answered in enough det ail.
Design / modelling
One of agile met hods t hat incorporat e modelling very much is Agil e
Modelling (AM). However, alt hough modelling is used in AM, t he purpose is
77
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
dif f erent . In AM, models are f or example used t o communicat e
underst anding of a small part of t he syst em under development . Most of
t he models do not become part of t he f inal model of t he syst em because
t hey are most ly t hrow-away models and are drawn on a whit eboard or
paper and erased af t er f ulf illing t heir purpose (Frauke, P. , Armin, E. , &
Frank M. , 2003).
Wit h t his pract ice, agile met hod is suit able f or small t o middle size
proj ect s. For large and complex proj ect s, plan-driven met hod is more
suit able 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
implement at ion is a met hod used in Ext reme Programming. It is called
“ pai r pr ogr ammi ng” . In XP, programmers work t oget her in pairs and as a
group, wit h simple design and obsessively t est ed code, improving t he
design cont inually t o keep it sat isf y t he current needs. However, pair
programming doesn't mean all code is always writ t en by t wo programmers
working t oget her using one comput er. Some code is best implement ed
individually, and some code is best implement ed in a pair.
T est ing
In Ext reme Programming, developers 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 all
t he normal condit ions, as well as f or any unusual circumst ances (boundary
condit ions, et c. ). Then, t hey run all unit t est s and if t hey f ind some
problem wit h t he code, t hey add more unit t est s t o isolat e t he problem.
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 ools in t he market t hat can be used f or t he agile
approach. One of t he t ools is called VersionOne (www. versionone. net ).
Using such t ool, we can plan and manage our agile sof t ware development s.
VersionOne is f ocused on t he planning, management , and delivery of
rapidl y changing, unpredict able sof t ware development proj ect s.
It also
provides several t emplat e proj ect s f or Scrum, Ext reme Programming or
DSDM met hods in a web based environment .
Anot her t ool is called TP (www. t arget process. com) t hat specif ically
designed t o simplif y planning, t racking, and qualit y assurance act ivit ies.
Conclusion
In conclusion, we can say t hat t he agile met hodology is an alt ernat ive t o
plan-driven met hodology (eg: UML or Wat erf all Model) in t he development
of qualit y sof t ware. It is also very suit able f or small t o middle size
proj ect s because developers do not usually concent rat e on models as t he
78
An overview of Agile Sof t ware Development Met hodology
and It s Relevance t o Sof t ware Engineering
(Ni ko Ibr ahi m)
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 believed can leverage t he product ivit y
of programmers.
Bibliography
Abrahamsson, P. , Sal o, O. , Ronkainen, J. , & Warst a, J. (2002). ‘ Agile
Sof t ware Development
Met hods: Review and Analysis’ , VTT
Publicat ions.
Agile Alliance Page, [ Online] , Available: ht t p: / / www. agilealliance. org [ 20
Oct ober 2004]
Aksit , M. , Mezini, M. , & Unland, R (Eds. ). (2002). ‘ Do We Need ‘ Agile’
Sof t ware Development Tools?’ , Springer-Verl ag Berlin Heidlberg, pp.
412–430.
Cockburn, A. 2002, Learning From Agil e Sof t ware Development - Part One,
[ Online] ,
Available:
ht t p: / / www. st sc. hill. af . mil/ crosst al k/ 2002/ 10/ cockburn. ht ml
[ 29
November 2004]
Dan T. , Robert F. , & Bernhard R. (2002). Limit at ions of Agile Sof t ware
Processes,
[ Online] ,
Available:
ht t p: / / www. agileall iance. org/ art icles/ art icles/ Limit at ionsof Agile. pdf
[ 27 November 2004]
Fowler, M. 2000, The New Met hodol ogy, [ Onl ine] , Avail able:
ht t p: / / www. t hought works. com/ us/ l ibrary/ newMet hodology. pdf
[ 20
November 2004]
Frauke, P. , Armin, E. , & Frank M. 2003, Requirement s Engineering and
Agile
Sof t ware
Development ,
[ Online] ,
Available:
ht t p: / / www. sern. ucalgary. ca/ ~milos/ papers/ 2003/ Paet schEberleinMau
rer. pdf [ 26 November 2004]
Larman, C. & Basili, V. R. (2003). ‘ It erat ive and Increment al Development :
A Brief Hist ory’ , IEEE Comput er, vol. 36, no. 6, pp. 47-56.
Lowell, L. & Ron, J. (2004). ‘ Ext reme Programming and Agile Sof t ware
Development Met hodologies’ , Inf ormat ion Syst ems Management , vol.
21, pp. 41-61.
Sharma, P. (2004). An Int roduct ion t o Ext reme Programming, [ Online] ,
Available: ht t p: / / www. advisor. com/ doc/ 13571 [ 28 November 2004]
79
Jurnal Sist em Inf ormasi Vol. 2 No. 1 Maret 2007 : 69-80
William, L, & Cockburn, A. (2003) ‘ Agile Sof t ware Devel opment : It 's about
Feedback and Change’ , IEEE Comput er Societ y, vol. 3, pp. 39-44.
80