University of Economics in Katowice
JOINING AGILE WITH UNIFIED PROCESS IN ORDER TO IMPROVE
SOFTWARE QUALITY
Introduction
Business needs for improvement of the software development are increas- ing. Organizations expect faster results from their investments; they want their improvement projects to adapt to and follow changing business needs. The agile way of working, used more and more in software development, contains several techniques that support these business needs. So the question is: Could an im- provement of the software development be performed in an agile way and what about an adoption of this approach by more traditional practices? This article is a quick introduction to Agile practices that can help improve the quality of soft- ware creation by reducing defects, improving design, sharing the theory of the code and building less. It includes an introduction of how to choose the practices for your organizational context. It also includes an example how to adopt Agile Modeling in one of the more popular traditional approaches in order to improve software quality.
Improving software quality
The vast majority of software projects suffer from a steady degradation of design quality and it becomes more and more difficult to keep in the same level of quality. As the software ages it becomes harder and harder to maintain be- cause of the lack of skilled personnel capable to deal with it. In some cases it be- comes too expensive to maintain and therefore the software is put to rest and re- written. In others, the software is released with a steadily increasing number of defects. Both of these common situations are deeply unsatisfying, but there is another way. Many of the practices from the Agile realm inhibit the degradation
2
o h
d e i
F
•
•
• 266
of s hav
diff eme ing
Fig.
• T m o
• D e d s p t o
• T i s p t s soft ve m
So feren erge
the
1. E
Th The mou of q Des easy disc sign patc test ous The ity suc pro tim soft
twa main
oftw nt t ent e qu
Effec
here e di
us w qua sign
y to cov n in che t dr sly i eory
map ces ces me. E
twa are
ntai ware
tran app ualit
ctive
e ar imin
with lity n im
o u vere n th ed m rive
imp y bu ppe ss. B ss th
Effe are
qua ined e de nsfo proa ty o
enes
re fo nut h h y pro
mpr unde ed. I he b man n d prov
uild ed o Bui hat
ecti sys
ality d a esig orm
ach f de
ss of
our tion high obl rove
erst In t beg ny t deve
ve t ding onto ildi
is b ive stem
y an zer gn a matio to evel
f Ag
ma n of h qu
em eme tand trad inn time elop the g – o so ng best dev m r
nd ro-d and ons ent lop
gile p
ajor f de ualit ms.
ent d an ditio ning
es.
pme des pro oftw a t t do velo repr
tur defe arc ov terp ed s
prac
stra efec
ty s
– h nd ona g of Ag ent sign ogra ware
theo one
opm rese
rn th ect s chite ver prise
soft
ctice
ateg cts – soft
high flex l ap f th gile and n of ams e. T ory
fac men ents
he stat ectu
tim e ar twa
es in
gies – a twa
h q xibl ppro he p
pra d re f the s ca The y of ce to nt te s th
Pio
tren tus o ure me.
rchi are a
term
s tha low are.
qual le e oac proc acti
efac eir s an b
pro f th
o fa eam he w
otr Z
nd of t hav Acc itec are
ms o
at ca w d
De
lity eno ches cess ces ctor
sys be tr
ope he r ace ms h
wor Zad
aro thei ve b cord
ture sho
of qu
an h defe efec
de ough
s de s an s giv
ring tem reat er w real by hav rld.
ora
ound ir pr beco ding e. P own
ualit
help ect c cts a
esign h to evel nd t ve g de m.
ted way lity- tria ve a In
d. I roje ome g to Prac n on
ty
p to cou are
n m o ch lop then an eve
as of -to- al a a sh n co
It is ects e el o th ctice n Fig
o im unt
als
mak han ers n it alte lop
the man -sof and hare
onse s no s fo lasti
his, es t gur
mpro in t o th
kes nge usu t de erna pers
eorie nag ftwa erro ed u
equ ot u or m
ic a , G that re 1
ove the he m
for as uall egra ativ are
es, ging
are or w und uenc
unk mont and Gartn
t are [El
the co mos
r an new ly m ade ve; u
e no
i.e.
g th ma with ders
ce know
ths eas ner e he lss0
qu de st v
n ap w r mak s o usin ow
mo hese
app h m tan the
wn and sily
rec elpf 08, N
ality is o visib
ppli requ ke v over
ng abl
ode e mo ping more din y k
for d ye infl com ful NeA
y of ofte ble
icat uire very r tim
pra le t
els o ode g is e th ng o
kno r te ears fluen mme in i Ap0
f so en s ind
tion eme y go me actic
to c
of th els l s a han
of h w
eam s.
nce end imp 09].
oftw syno dica
n th ents
ood as ces cont
he r lead hu eno how how
ms t
ed b ds a prov
.
ware ony atio
at i s ar d de it i lik tinu
real ds t uma oug w th w t to
by an v-
e:
y- n
is re e- is ke u-
l- to an gh he to
•
g
F
t c d f b s b
m s w
• B o o c c gies
Fig.
tice cau date fect bein stan ber
mod sear with Bui ofte or n cod cod Th s sh
2. S
It e. M se o e al ts o ng i nd a of
dify rch h ot ildin en o
nev de w deba her how
Strat
can Main
of a lso once
inh and
def y th hing ther ng or a ver whic
ase e ar wn o
tegy
n b ntai a be
dim e fo here
com fect
he c g fo r m less alwa use ch m
alm re s on F
dep
e c nin ette mini ound
ntly mm s in
cod or a mem s – ays ed.
mak mos
som Figu
pend
oun ng th er u
ishe d. I y ea mun
n th e w an e mber onl . M On kes st al me i ure
denc
nted he t unde es t Imp asie nica
e sy when
erro rs o ly a More ne w s it
lwa mp 2 [R
ies
d th theo erst the prov
er t ate t yste
n a or t of th
abou e th way eas ays h porta Ref
hat t ory tand
num ving to c
the em.
a req that he t
ut 2 han y to sier
has ant fC1
ther y of ding mbe g th chan the
quir t ha
eam 20%
60%
o im to s few
dep 11].
re a f the g of er o he d nge eory
rem as b m ab
% of
% o mpro und wer pen
are e co
f th of d desi e. B y of
men been
bou f fu of a ove ders r de nden
few ode he e
defe ign Build
f the nt ch
n re ut th unct all f e th stan efec
ncie
w ad ma exis
ects als din e co
han epo he m
tion func he q nd a cts.
es b
dva akes ting s an so m
g le ode
nge orte mod nali ctio qual and betw
anta s it g de nd t mak ess e an
occ d, del
ty w onal
lity d m
wee
ages eas esig the kes co nd is
curs and and whi lity of ain en t
s of sier gn.
diff it e de s di
s, th d th d th ich bui f so
tain the
f gi r to
Ke fficu easi
ma irec
hey hey he c
is u ilt i ftw n. A
afo
iven mo eepi
ulty er t akes ctly
y kn co ode usu in s ware Add orem
n st odif ing y in
to r s it
rel now omm
ebas ally softw e is ditio
men
trate fy t
the fix rem eas late
w w mun se.
y bu war to onal ntion
egie the e th xing move sier
d to wher
nica
uilt re i
wr lly ned
es i des heor g th e er r to o th
re to ate
is u s ra rite sm d str
in p sign ry u hose rror un he n
o g we
use arel les alle rate
prac n be up t e de rs b nder num go
ll
ed ly ss er e-
c- e- to e-
y r- m-
2
I
f o s c s p t
F
t d p t m m
m g d t o q b i w 268
Imp
first of g set t com syst pab thes
Fig.
the dev ple, to th mat mos
mos gram dev this of m que bee imp whe
pro
D t pr give they mes
tem le t se p
3. S
Fo top velo , de he o ted st d Th st d mm velo
s tec mon ently n d prov en d
ovi
eve racti en e y n dow m to
to im prac
Steps
or i p of oper evel oth dev diffi
he p diffi ming oper
chn nths y A disc ve t dev
ng
elop ices envi eed wn be mp ctice
s for
imp f Fig r te lope her t
velo icul
pra ficul
g is rs w niqu s be Agile cove
tow velo
so
pers s of iron d to to f cre rov es in
r cho
prov gur sts, ers thre ope lt of ctic lt t
fre who
ue b efor e pr ered ward oper
oftw
s us f th nme
get find eated ve th n or
oosi
ving re 1 , au sho ee p er te f th ces to d eque
are by a re d ract d. F ds th
r te
war
sual e A ent h
t th ding
d. F he q rder
ing a
g qu . Fo utom ould prac
ests is s inv do f entl e us agre dec
tice Faci he g eam
re
lly s Agile hav he m
g th Figu
qua r rel
and
uali our mat d co ctic s, an set t volv from ly s sed eein idin es s
ing goa m sta
qu
star e m ve b most he h
ure ality late
imp
ity, r of ed ons es.
nd t to a ved m t seen
to ng a ng w
how wi al o arts
alit
rt IT meth
been t ou igh 3 c y of ed to
plem
the f the acc ide
Ne then adop in the n as
wo as a wh w p ith of in s ad
ty
T p hodo
n ch ut o hest cont f th o ef
menti
e m e pr cept r to ext s n fi pt c imp
bo s a rkin a te
eth prob
diff ncre dopt
Pio
in t
proje olog hose of th val tain e so ffec
ing p
most ract tanc o ad step final
corr prov ody
wa ng a eam
er i blem fficu
ease ting
otr Z
the
ects gy.
en, he p lue ns de
oftw ctive
prac
t va tice
ce t dopt p to lly rect vin of ste alon m to
it is ms t ultie ed q g do
Zad
e A
s w Th dev prac pra epe war ene
ctice
alua es ar test t pa o co aut tly).
ng th Ag of ne.
pra s w
that es i qua one
ora
Agil
with hen, velo ctice actic ende re. T ss s
es
able re i ts, a air p onsi
tom . he q gile
reso De acti worth
t ha is a ality e sta
le c
gen on oper
es t ce th enci The show
e se inde and pro ider mate
qua e pr our evel ice h a ave a ch y. A ates
con
nera nce t rs n they hat ies ere i
wn
et o epen d pa ogra r sh ed a
ality ract rces lope pai dop alw han A go
s fo
nte
al i the need y ch wil betw is a
in t
of p nde air p amm houl acce
y of tice s an
ers ir p ptin way ce ood or th
ext
dea firs d to hoos
ll fi wee also
that
prac ent:
pro min ld b epta
f so s. F nd u
sho prog ng p ys b to c d ex
he a of
st p o be se.
it in en p o a m
t fig
ctice do ogra g a be d ance
ftw For unco ould gram perm been
cor xam firs
f ho prac e aw
Ch nto t prac
mea gure
es a one
amm as a
don e te
ware ex om d co mm man n th rrec mple st ti
ow ctice ware oos the ctic asu e.
are sta min sup ne st
est
e ar xam fort onsi ming nen here t a e of
ime to c es th e of sing con ces t ure w
tho ate, ng. F
ppo tate (pro
e so mple
tabl ider g fo
tly.
e bu pro f thi e. T
cho that f the g a p ntex
that whi
ose aut For ort p e an oba
ome e pa le t r to or a
M ut h oble is h This
oose be e m prac xt o
t are ich
nea tom r ex prac nd a ably
e of air
o m o try co Most have em happ
is e th
st f mind
ctic f th e ca
put
ares mate
xam ctic auto y th
f th pro man
y ou upl
fre e no an pen sce he fit d- ce he a-
ts
st ed m-
ce o- he
he o- ny
ut le e- ot nd ns e-
nario when a team frequently works on multiple features at a time and at the end of the iteration there is a lot of work in the middle and nothing fully completed.
This is discouraging and a common response is to stop doing the practice instead of examining the reason of problems and looking for alternatives to correct them in the next iteration.
Another good approach of dealing with these practices are “small steps” be- cause many of them are completely new that may slow down development and cause frustration. It should be taken one practice at a time, performed well, and then used regularly. There is an issue of examining whether the practice is per- formed well. The estimation may be based on the value that the developers team originally hoped to achieve. If a practice is completely easy and comfortable from the first time, or has not noticeably improved the quality of work done then the team most probably did not performed it well.
Much of what developers are working on at the moment do not provide immediate sense. For example – writing the tests first, before writing working code in the automated developer tests practice is non-intuitive. It causes the issue of what is the real achievement by doing things backward? Those who have suc- cessfully adopted this practice have “suspended their disbelief” and done it any- way. After experientially learning the practice such developers then made their judgments about its utility and usually kept doing it because of the value seen.
Merging heavy methods with Agile practices
Every Project Manager can successfully integrate Agile principles and prac- tices with heavyweight approaches to improve software quality, by understand- ing and applying that Agile is not made for projects as Project Managers define projects but more likely for product management. Product management is con- cerned with the life of the product; from conception, through development and eventually to discontinuation. Projects are not concerned with the ongoing im- provement or enhancement of a product over the entire lifecycle of that product.
A project is all about the creation of something but when the something is created the project is done [InfoQ11]. Understanding that subtle difference, it is informa- tive to find out how Agile practices can be merged with heavyweight methods and whether there are some similarities or common elements between them.
One of the most known “heavy” methods of software development is the Rational Unified Process (RUP) created by the Rational Software Corporation, a division of IBM since 2003 [Eweek02]. RUP is not a single concrete prescriptive process, but rather an adaptable and iterative process framework, intended to be tai-
Piotr Zadora 270
lored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs [Wiki14].
Many of Agile Modeling principles and practices are a part of the Unified Process (UP) already, although perhaps not as explicitly as it could be. It is rela- tively straightforward for teams using Unified Process to adopt Agile practices if they choose to do so. This is because the Unified Process is very flexible and let the developers to choose elements that meet their unique needs. Below is the list of Agile practices used in modeling phase which may be adopted within Unified Process framework [AMRUP08]:
• active stakeholder participation,
• applying modeling standards,
• applying patterns gently,
• applying the right artifacts,
• collective ownership,
• creating of several models in parallel,
• depicting models simply,
• discarding temporary models,
• displaying models publicly,
• formalizing of contract models,
• iteration to another artifact,
• modeling in small increments,
• modeling with others,
• proving with code,
• reusing of existing resources,
• single source information,
• updating only when it is needed,
• using of the simplest tools.
Agile principles used in modeling define project stakeholders, users, man- agement, operations staff, and support staff which are compatible with the Uni- fied Process. The UP clearly includes project stakeholders, such as users and customers, throughout most of it disciplines. To be successful project teams should allow project stakeholders to take on modeling roles such as Business Process Designer and Requirements Specifier as appropriate, there is nothing in the RUP preventing this by the way. The more active project stakeholders are the less of a need there will be for reviews, management presentations, and other overhead activities that reduce team’s development velocity.
The application of modeling standards, in particular the diagrams of the Unified Modeling Language (UML), is a significant part of the Unified Process.
Furthermore the RUP product includes guidelines for the creation of many mod-
eling artifacts, guidelines that developers team should consider adopting and fol- lowing as appropriate, and explicitly suggests that the guidelines should be tai- lored or even bend to suit developers needs.
Unified Process teams are free to apply modeling patterns, the RUP product describes many common modeling patterns for any of the modeling disciplines.
Practice of applying patterns enhances Unified Process with its advice to ease into the application of a pattern. There is no explicit clarification of this concept within Unified Process framework.
Considering application of the right artifacts it should be stated that one of the advantages of the Unified Process is that it provides advice for when to cre- ate each type of model, even for non-UML artifacts such as data models and user interface storyboards (UI flow diagrams).
Agile concept of collective ownership can be used to enhance the efforts on Unified Process projects, assuming that the team behaviour supports the concept of open and honest communication. The UP supports collective ownership with its strong focus on configuration management issues. Developer teams should al- low anyone on the project to access and work on any artifact that they wish, in- cluding models and documents.
Unified Process clearly includes concept of creation several models in par- allel. However, this concept could be communicated better because the near- serial flow in its activity diagrams presented for each major modeling activity doesn’t communicate this concept well. There is a larger issue as well when you consider the lifecycle as a whole. Because the UP has organized its modeling ef- forts into separate disciplines, for very good reasons, it is not as apparent that not only could developer work on several business modeling artifacts in parallel but he could also work on requirements oriented artifacts, analysis-oriented artifacts, architecture artifacts, and design artifacts as well.
The practice of depicting models in straightforward way is a choice made by the modeler, albeit one that must be implicitly supported by the rest of the development team. Unified Process teams will need to adopt modeling guide- lines that allow models that are just good enough and the customers of those models (including programmers, project stakeholders, and reviewers) must also be willing to accept simple models. This issue is one of the most difficult for many organizations to adopt.
Modelers on Unified Process teams are free to discard anything that they wish. As with the simplicity practices your organization’s culture must accept the concept of developing and maintaining just enough models and documents and no more.
Piotr Zadora 272
Unified Process teams are free to follow practice of showing models pub- licly. Developer teams should follow the principle of open and honest communi- cation by making all artifacts available to everyone.
The Unified Process includes the concept of integrating with external sys- tems. These systems are typically identified on use case models and there is sug- gestion to introduce “boundary classes” as implementation of the interface to these systems. The interaction between systems could be specified with one or more use cases and the corresponding realization of them would be the formal- ized contract model. Hence, the adoption of this Agile practice can make a posi- tive contribution to strengthening the integration capabilities of enterprise appli- cation realized according to Unified Process approach.
The practice of iteration to another artifact can be easily adopted by Unified Process team. Understanding of UP’s modeling activities as quasi-serial proc- esses and the division of modeling activities into separate disciplines can hinder the iterative mindset required of Agile developers.
The practice of modeling in small increments is clearly an aspect of the Unified Process. The UP’s support for iterations implies that model established at the beginning will be incrementally developing throughout the project. This is obvious that smaller, simpler models may quickly lead to implementation and testing.
Unified Process implicitly includes the practice of modeling with others which clearly defines several roles played by one or more people. The subse- quent Agile practice of proving with code is also included in Unified Process framework. At the end of every iteration, except the Inception phase, the UP specifically states that the team should have a working prototype. Furthermore, the UP insists that developers have a working end-to-end prototype at the end of the Elaboration phase that proves given architecture.
Reusing of existing resources is an implicit part of the Unified Process. Fur- thermore, reuse management is an explicit part of the Enterprise Unified Proc- ess. Developer teams should prefer to reuse existing resources instead of build- ing them from scratch, including but not limited to existing models, existing components, open source software, and existing tools.
According to single source of information practice, there is no reason why developers cannot store information in a single place when following Unified Process. Unfortunately, many organizations choose to instantiate the RUP in a documentation-driven manner, and as a result they are proceeding with heavy load and clearly take a multi-source approach.
Considering the practice of updating only when it is needed, many devel- oper teams in reality prove to have a problem with this concept, particularly if they have a strong habit of checking relations between aspects of project arti- facts, the support for which is a strong feature of Unified Process as it is an im- portant aspect of its Configuration and Change Management discipline. Fur- thermore, Rational Unified Process includes tool mentors for working with Rational RequisitePro, a requirements tracing tool, making it appear easy to maintain a traceability matrix between artifacts.
Developer organizations with strong habit of checking relations between project artifacts will often choose to update them regularly, even if it is not nec- essary at the moment. Such attitude should be replaced with another one which allows to maintain a traceability matrix between artifacts only when there is clear benefit to do so and project stakeholders authorize the effort.
Rational Unified Process product includes tool mentors that make it easier for teams to work with tools sold by Rational Corporation. However, in reality many developer teams are using another development tools which suit their needs and Rational tools are just one of the competitors in this area.
References
[AMRUP08] Agile Modeling and the Rational Unified Process (RUP). Available http://www.agilemodeling.com/essays/agileModelingRUP.htm, 2008.
[Elss08] Elssamadisy A.: Agile Adoption Patterns: A Roadmap to Organizational Success. Addison-Wesley Professional, 2008.
[Eweek02] Taft D.K.: IBM Acquires Rational. Available: http://www.eweek.com/c/a/
Desktops-and-Notebooks/IBM-Acquires-Rational, 2002.
[InfoQ11] Flahiff J.: Integrating Agile into a Waterfall World. Available:
http://www.infoq.com/articles/agile-in-waterfall-world, 2011.
[NeAp09] Gartner Identifies New Approach for Enterprise Architecture. Available http://www.gartner.com/it/page.jsp?id=1124112, 2009.
[RefC11] Agile Adoption: Improving Software Quality. Available: http://refcardz.com, 2011.
[Wiki14] Rational Unified Process. Available: http://en.wikipedia.org/wiki/ Rational _Unified_Process, 2014.
Piotr Zadora 274
ŁĄCZENIE PRAKTYK AGILE Z PODEJŚCIEM UNIFIED PROCESS W CELU DOSKONALENIA JAKOŚCI OPROGRAMOWANIA
Streszczenie
Wytwarzanie oprogramowania wysokiej jakości stanowi jedno z największych wyzwań stojących przed deweloperami. W artykule zaprezentowano koncepcję wykorzystywania praktyk Agile, która sprzyja wytwarzaniu oprogramowania wysokiej jakości. Przedstawiono również jedną z możliwości łączenia praktyk Agile z tradycy- jnymi „ciężkimi” podejściami. Zdaniem Autora wykorzystanie zalet obu podejść, zami- ast przeciwstawiania ich sobie, powinno prowadzić do skutecznego tworzenia opro- gramowania wysokiej jakości.
