Ülevaade vÄledatest tarkvaraarenduse...
TRANSCRIPT
-
TARTU ÜLIKOOL
MATEMAATIKA-INFORMAATIKATEADUSKOND
Arvutiteaduse instituut
Tarkvarasüsteemide õppetool
Informaatika eriala
Veljo Otsason
ÜLEVAADE VÄLEDATEST TARKVARAARENDUSE METOODIKATEST
Bakalaureusetöö
Juhendaja: prof. Jüri Kiho
Konsultant: Asko Seeba
Autor: ............................................... „.......“ .................. 2003
Juhendaja: ........................................ „.......“ .................. 2003
Õppetooli juhataja: .......................... „.......“ .................. 2003
Tartu 2003
-
2
Sisukord
Sissejuhatus............................................................................................................................... 4
1 Tarkvara arendus ja metoodika ..................................................................................... 5
1.1 Tarkvaratehnika ja tarkvaraloome probleemid .......................................................... 5
1.2 Tarkvara arenduse metoodika .................................................................................... 8
1.3 Väledad metoodikad................................................................................................. 10
1.4 Väledate metoodikate praktiline kasutatavus........................................................... 12
2 Rationali unifitseeritud arendusprotsess ..................................................................... 14
2.1 Praktikad................................................................................................................... 15
2.2 Protsess..................................................................................................................... 16
2.3 Täiendav info............................................................................................................ 17
3 Ekstreemprogrammeerimine ........................................................................................ 17
3.1 Praktikad................................................................................................................... 18
3.2 Protsess..................................................................................................................... 21
3.3 Täiendav info............................................................................................................ 21
4 Erisus-juhitud arendus .................................................................................................. 22
4.1 Praktikad................................................................................................................... 23
4.2 Protsess..................................................................................................................... 24
4.3 Täiendav info............................................................................................................ 25
5 Adaptiivne tarkvaraarendus ......................................................................................... 25
5.1 Praktikad................................................................................................................... 26
5.2 Protsess..................................................................................................................... 27
5.3 Täiendav info............................................................................................................ 28
6 Dünaamiline süsteemiarendusmeetod .......................................................................... 28
6.1 Põhimõtted ............................................................................................................... 30
6.2 Protsess..................................................................................................................... 32
6.3 Täiendav info............................................................................................................ 34
7 Crystal Clear................................................................................................................... 34
7.1 Praktikad................................................................................................................... 36
7.2 Protsess..................................................................................................................... 37
-
3
7.3 Täiendav info............................................................................................................ 37
8 Muid metoodikaid ja lähenemisi................................................................................... 37
8.1 Suutvusküpsuse mudel ............................................................................................. 38
8.2 ISO 9000 .................................................................................................................. 39
8.3 Kulusäästlik arendus ................................................................................................ 40
8.4 Scrum ....................................................................................................................... 41
8.5 Pragmaatiline programmeerimine ............................................................................ 42
8.6 MSF.......................................................................................................................... 42
9 Kokkuvõte ....................................................................................................................... 44
Viited ....................................................................................................................................... 45
Abstract ................................................................................................................................... 50
-
4
Sissejuhatus Viimasel ajal on tarkvaratehnika valdkonnas välja käidud mitmeid lähenemisi tarkvara
arendamiseks ning nendes orienteerumine on muutunud suhteliselt keeruliseks. Paljud
metoodikad on teineteisega üldjoontes sarnased, kuid on ka mitmeid erinevusi. Erinevaid
käsitlusi tarkvara arendamise protsessile on palju, kuid suur osa neist pole tarkvaratööstuses
reaalset kasutust leidnud. Mitmete lähenemiste korral on teooria ja praktika teineteisest lahku
läinud ning teoorias ideaalselt töötav lähenemine on osutunud praktikas kasutuks. Viimastel
aastatel on populaarsust kogunud väle (agile) lähenemine tarkvara arendusele ning välja on
pakutud mitmeid väledaid metoodikaid.
Käesoleva töö eesmärkideks on leida valitsevast metoodilisest virr-varrist üles levinumad
väledad metoodikad, mida ka reaalselt kasutatakse; anda neist lühike ja erapooletu ülevaade
ning tuua välja viited täiendavaks uurimiseks.
Töö esimeses osas on antud üldine ülevaade probleemidest millega tarkvaratehnika tegeleb
ning erinevatest lähenemistest, mis on aegade jooksul välja käidud, et neid probleeme
lahendada. Seejärel on selgitatud väleda tarkvaraarenduse aluseid ning ära toodud mõningate
väledate metoodikate praktilist kasutatavust seiranud uuringute tulemused. Järgnevates töö
osades on antud ülevaade uuringute põhjal levinumatest väledatest metoodikatest, nagu
Rationali unifitseeritud arendusprotsess, ekstreemprogrammeerimine, erisus-juhitud arendus,
adaptiivne arendus, dünaamiline süsteemiarendusmeetod ja Crystal Clear. Enamus
metoodikaid baseeruvad mingitel parimatel praktikatel. Iga metoodika korral on ära toodud
need praktikad, kirjeldatud arendusprotsessi selle metoodika alusel ning toodud viiteid
edasiseks uurimiseks. Lisaks kuuele detailsemalt kirjeldatud metoodikale antakse põgusam
ülevaade veel mõnedest standarditest, lähenemistest ja metoodikatest, mida tarkvaraarenduses
kasutatakse, nagu suutvusküpsuse mudel, ISO kvaliteedistandard, kulusäästlik arendus,
Scrum, pragmaatiline programmeerimine ja MSF.
-
5
1 Tarkvara arendus ja metoodika Arvutustehnika leiutamine ja kiire areng on kahtlemata oluliselt muutnud tervet maailma.
Üheks oluliseks faktoriks selle juures oli arvuti ja tarkvara lahutamine teineteisest. Suhteliselt
paindumatu ja fikseeritud arvutusseade eraldati paindlikust ja kiirestimuudetavast tarkvarast
ning sellega seoses tekkis võimalus ja vajadus eraldi tarkvara loomise järele. Algselt ei olnud
arvutustehnika väga võimas ja ka sellel töötav tarkvara ei pidanud olema eriti keerukas.
Programmi kirjutamisega sai väga hästi hakkama üks inimene. Põhiline vaev kulus tollal
arvuti enda loomisele ning tarkvara loomist peeti millekski elementaarseks, umbes nagu
taskukalkulaatoriga arvutamine võrreldes kalkulaatori loomisega. Arvutustehnika arenes aga
ülikiirelt ning kasvav arvutusvõimsus vajas rakendamiseks keerukamaid programme.
Keerukat tarkvara pidi looma mitu inimest ning esialgu lihtne paistnud tarkvaraarendus sattus
vastakuti suurte probleemidega.
1.1 Tarkvaratehnika ja tarkvaraloome probleemid
Esmakordselt hakati tarkvara loomise juures esinevaid probleeme tõsisemalt analüüsima
1968. ja 1969. aastal toimunud NATO tarkvaratehnikaalastel konverentsidel [Randell], kus
tõdeti, et suurte ja keeruliste tarkvarasüsteemide loomine on problemaatiline ning võeti
esmakordselt kasutusele mõiste tarkvara kriis (software crisis). Nenditi, et paljud
tarkvaraprojektid kestsid kordi kauem kui plaanitud, kulutasid palju rohkem raha või neid ei
lõpetatudki. Loodud tarkvara oli tihti ebakvaliteetne, põhjustades rahalist kahju ja kujutades
vahel ohtu koguni inimeste eludele. Neid sündmusi võib lugeda ka tarkvaratehnika (software
engineering) kui teadusharu alguseks. Sellest ajast peale on tarkvaratehnika fookuses
küsimused, kuidas suurendada tarkvara loojate produktiivsust, tõsta tarkvara kvaliteeti ning
alandada kaasnevaid kulusid.
Samas on toimunud palju muutusi keskkonnas, milles tarkvara vajatakse. Riistvara on
teinud suure hüppe oma arengus, mistõttu osutub paljude ülesannete lahendamine
ratsionaalsemaks jõumeetodil. Teiselt poolt on riistvara areng teinud võimalikuks uute
probleemide lahendamise ja infotehnoloogia tungimise täiesti uutesse valdkondadesse, mis on
tihti kriitilisemad, pannes tarkvarale veelgi suurema vastutuse. Ärimaailm muutub ja toimib
kiiremini, vajades aina väledamat reaktsiooni ka tarkvaratööstuselt. Uute toodete
turuletoomine ja klientide nõudmistele reageerimine peab toimuma kiiremini ning tarkvara,
mis mängib aina suuremat rolli äris, peab seda võimaldama.
-
6
Tarkvaratehnika on suhteliselt uus valdkond, mis pole veel saavutanud küpsele teadusharule
omast stabiilsust. Käibel on mitmed vasturääkivad lähenemised ja tarkvaratehnika-alases
mõtlemises toimuvad kiired muutused. Kuna tegemist pole vaid formaal-matemaatilise
teadusega, vaid paljuski tuleb tegemist teha inimaspektidega, nagu juhtimine ja eestvedamine,
ei ole ka kiiret ühtse teooria paikapanekut oodata.
Hoolimata tarkvaratehnikaalasest tööst, pole tänapäeval olukord palju paremaks muutunud
ning tarkvara arendus on siiani problemaatiline. Standish Group [Standish] on alates 1994.
aastast läbi viinud igaaastast uuringut nimega Chaos report, mis analüüsib tarkvara
arendusprojektide edukust USA tarkvaratööstuse näitel. Tarkvaraprojekti tulemus liigitatakse
järgmiselt:
• Edukas – projekt lõpetati õigeaegselt, eelarvet ületamata ja koos enamuse plaanitud
funktsionaalsusega,
• Puudulik – projekt lõpetati, kuid hilines, ületati eelarvet ja/või jäeti oluline osa
funktsionaalsusest teostamata,
• Katkestatud – projekt katkestati ja tarkvara ei jõudnud kasutusse.
2000 aasta Chaos report [Chaos 2000] kohaselt jõudis eduka lõpuni vaid 28% algatatud
projektidest (Joonis 1).
edukas 28%
puudulik 49% katkestatud 23%
Joonis 1. Tarkvaraprojektide tulemuslikkus [Chaos 2000]
Olukord on mõnevõrra parem väiksemamahuliste projektidega. Alla 500 000 USD mahuga
projektidest olid edukad 38%. Eestis läbiviidavatest arendusprojektidest kuulub suurem osa
just sellesse kaalukategooriasse. Tabel 1 näitab eri suurusega projektide tulemuslikkust.
-
7
Suurus Edukas Puudulik Katkestatud alla $500K 38 % 44 % 19 % $501K - $3M 27 % 52 % 21 % $3M - $6M 16 % 55 % 29 % $6M - $10M 4 % 57 % 39 % üle $10M 0 % 66 % 34 %
Tabel 1. Projektide tulemuslikkus sõltuvalt suurusest [Chaos 2000]
Alates 1994. aastast, kui neid uuringuid läbi viima hakati on märgata mõningast olukorra
paranemist. Kui 1994. aastal oli edukaks loetud projekte kõigest 16%, siis 1998. aastal oli
nende osakaal 26% ning 2000. aastal 28% [Chaos 2000]. Samas võib vaielda uuringus
kasutatud edukriteeriumi relevantsuse üle. Edukus selle uuringu mõistes on pigem
ennustatavus – kas esialgu plaanis olnud funktsionaalsuse arendus võttis nii palju aega ja raha,
kui algselt arvatud. Nõuded aga võisid projekti käigus muutuda ning tarkvara kolmnurga
kontseptsioonist lähtuvalt polegi võimalik tarkvara loomise protsessi kõiki muutujaid
täielikult ette määrata – mingi muutuja (ajakulu, rahakulu või funktsionaalsus) peab jääma
lahtiseks. See uuring ei näita, kui paljude projektide käigus valminud tarkvara kliendi
tegelikke vajadusi rahuldas või kui tihti kulutatud ressursid ennast tegelikult ära tasusid.
Uuring toob esile ka peamised asjaolud, mida peetakse edukate projektide põhjusteks ning
mille puudumist loetakse ebaõnnestumise allikaks [Chaos 2000]:
1. Juhtkonna toetus projektile
2. Lõppkasutaja seotus arendustegevusega
3. Kogenud projektijuht
4. Selged ärieesmärgid, milleks tarkvara arendatakse
5. Vähendatud projekti ulatus
6. Standardne infrastruktuur, mida kasutatakse
7. Kindlad põhinõudmised tarkvarale
8. Formaalne arendusmetoodika
9. Usaldusväärsed hinnangud
10. Kogenud meeskond
-
8
Lisaks projektide edukusele hinnatakse Standish Groupi uuringus ka tarkvara
funktsionaalsuse kasulikkust. Uuringu tulemustest selgub, et tervelt 45% funktsionaalsusest ei
leia kunagi kasutamist ning vaid 7% kasutatakse pidevalt (Joonis 2).
alati 7%
tihti 13%
vahest 16%harva 19%
mitte kunagi 45%
Joonis 2. Tarkvara funktsionaalsuse kasutatavus [Chaos 2000]
Kasutatavuse suhtarvudest selgub, et tarkvara vastavus kasutajate reaalsetele vajadustele on
üsna madal. Nõuetele mittevastavus võib tähendada nii seda, et osa vajalikku funktsionaalsust
on puudu, kui ka seda, et mingi osa arendatud funktsionaalsust on tegelikult kasutu. Esimesel
juhul on loodud toode ebakvaliteetne. Teisel juhul on arendustegevus ebaratsionaalne, kuna
osa tööd oleks saanud tegemata jätta. Antud uuringust nähtub, et vähemalt 45% keskmisest
tarkvara funktsionaalsusest oleks saanud jätta realiseerimata, ilma tarkvara väärtust
kasutatavuse seisukohast vähendamata. Siin tuleb silmas pidada ka seda, et osa funktsioone
arendataksegi teadmisega, et neid tegelikult ei kasutata. Need võivad olla näiteks
müügiargumendiks või on neil PR-väärtus.
1.2 Tarkvara arenduse metoodika
Metoodika on süstemaatiline viis millegi tegemiseks [Hidding 1997]. Tarkvara arendamise
metoodika on viis, kuidas tarkvara luuakse. See hõlmab kõike, mida tehakse, et väljastada
regulaarselt töötavat tarkvara – millised inimesed värvatakse, kuidas nad koos töötavad ja
infot jagavad, mida ja kuidas nad loovad jne. Igal organisatsioonil on metoodika – see on viis,
kuidas nad teevad oma tööd [Cockburn 2001].
Metoodika võib olla erineva detailsusega – üksikasjadeni kirjeldatud või näiteks ainult
üldisi väärtusi ja põhimõtteid selgitav, jättes detailid konkreetse kasutaja määrata. Esimesel
-
9
juhul on oht, et metoodika sobib vaid ühe konkreetset tüüpi ülesande lahendamiseks kindlat
tüüpi organisatsioonis ja pole seetõttu piisavalt paindlik. Teises äärmuses jälle on oht, et
metoodika on liiga laialivalguv ja temast on reaalselt vähe kasu.
Metoodika võib olla ka erineva skoobiga. Skoop näitab, kui suurt ulatust kogu
arendustsüklist, rollidest ja tegevustest metoodika kirjeldab. Alistair Cockburn on pakkunud
metoodika kirjeldamiseks üldise struktuuri, milles on 13 elementi: rollid, oskused, tiimid,
tehnikad, tegevused, protsess, tehised, verstapostid, standardid, kvaliteet, tiimi väärtused,
tiimi iseloom, töövahendid [Cockburn 2001].
Tarkvara loomise protsessi esimene süstematiseeritud käsitlus oli üldine kaskaad- e.
koskmudel (generic waterfall model) [Royce 1970]. Dokument-orienteeritud ja läbipaistev
kaskaadmudel võeti pärast tema teket kasutusele paljudes valitsusagentuurides- ja asutustes
ning samuti suurte tarkvarakorporatsioonide poolt. Kaskaadmudelit kritiseeriti peamiselt
seetõttu, et see ei andnud eriti suurt võimalust tarkvara prototüüpimiseks ja taaskasutamiseks.
Järgmise lahendusena käis Boehm 1988. aastal välja spiraalmudeli [Boehm 1988].
Spiraalmudel on riskide analüüsimisel põhinev lähenemine tarkvara arendamisele, mis
sisaldab endas kaskaadmudeli ja prototüüpimise parimad omadused. Mõningad spiraalmudeli
head küljed: mudelit võib kasutada efektiivselt nii süsteemi arendamiseks kui täiendamiseks;
enamikke tarkvara elutsükli mudeleid võib käsitleda kui spiraalmudeli erijuhte; mudelisse
sisseehitatud riskianalüüs aitab vältida paljusid teiste mudelitega kaasnevaid probleeme
[Kudrjavets 2002].
Üheksakümnendate alguses sai tarkvaraarenduses populaarseks RAD (rapid application
development) lähenemine [Martin 1991]. RAD eesmärgiks on saavutada oluliselt kiirem
tarkvara valmimine, kasutades erilisi arendusvahendeid, taaskasutatavaid komponente ja
spetsiaalseid tehnikaid. RAD projektides on väga tähis roll loodava rakenduse lõppkasutajal.
Kasutajate esindajad on kaasatud arendustiimidesse, kus nad osalevad lahenduse
projekteerimisel, annavad hinnangu vahepealsetele prototüüpidele ja suunavad arendajaid
õiges suunas edasi. Kasutajad annavad seega ise oma vahetu osalusega edasi tarkvara
nõudeid, mida tavaliselt kannab edasi vaid nõuete spetsifikatsiooni dokument. Seeläbi
tagatakse nõuete täpsem järgimine ning kiirem ja adekvaatsem tagasiside. Nii hoitakse
potentsiaalselt kokku ka hulgaliselt aega ja raha, kuna nõuete vääriti mõistmine ei pruugi
mitte ainult põhjustada mõnede nõuete mittetäitmist, vaid võib samahästi kaasa tuua suure
hulga tegelikult mittenõutud funktsionaalsuse arendamise. RAD korral võetakse aluseks 80:20
-
10
printsiip, mille kohaselt 80% vajalikust funktsionaalsusest on võimalik realiseerida 20%
ajaga. Ülejäänud 20% on aga tihti vaid tehtu ilustamine, mis ei lisa tarkvara kasutamisel
tegelikku väärtust [Beynon-Davies 1998].
Üldiselt üritab iga tarkvara arenduse metoodika võidelda nendesamade probleemidega:
muuta arendus kiiremaks ja odavamaks ning tulemus kasutaja nõudmistele paremini
vastavaks ja kvaliteetsemaks. Lisaks kliendi rahulolule üritavad viimasel ajal metoodikad
rohkem suurendada ka arendajate endi rahulolu – ületunnid ja pidev stress ei toeta pikemas
perspektiivis ühtegi organisatsiooni.
1.3 Väledad metoodikad
Tarkvara looja väledus on võime kohanduda ning reageerida kiiresti ja asjakohaselt
muutustele keskkonnas ja nõuetele mida see keskkond talle esitab [Kruchten 2001].
Väle tarkvaraarendus tekkis reaktsioonina aina kiiremini muutuva ärikeskkonna
nõudmistele luua äriks vajalikke lahendusi ruttu ja paindlikult. See on eriti oluline kiiresti
arenevates valdkondades nagu näiteks internetiäri või mobiilsiderakendused, kus ajaaken uue
lahendusega turuletulekuks on väga lühike, kuna konkurents on tihe ja turusituatsioon muutub
käbedalt [Abrahamsson et al. 2002].
Väleda tarkvaraarenduse mõiste tekkis veebruaris 2001, kui USA-s said kokku erinevate
kergekaaluliste arendusmetoodikate loojad ja praktikud, et leida ühiseid seisukohti. Selle
kohtumise tulemusel loodi väle allianss [AgileAlliance] ja võeti vastu väleda
tarkvaraarenduse manifest (agile manifesto) ning tosin põhimõtet. Manifest toob ära üldised
väärtused, mida väledas tarkvaraarenduses hinnatakse. See ütleb, et eelistatakse
[AgileManifesto], [Seeba 2002]:
• isikuid ja suhtlust protsessile ja vahenditele,
• töötavat tarkvara kõikehaaravale dokumentatsioonile,
• kliendiga suhtlust lepinguläbirääkimistele,
• muutustele vastamist plaani järgimisele.
Need punktid ei tähenda, et protsessi ja vahendeid või dokumentatsiooni üldse poleks vaja,
vaid näitavad mis on väledate metoodikute arvates tähtsam. Lisaks üldistele väärtustele on
vastu võetud ka 12 põhimõtet, mida väle tarkvaraarendus järgima peaks [AgileManifesto]:
1. Kõige tähtsam on rahuldada klienti, tarnides varakult ja pidevalt väärtuslikku tarkvara
-
11
2. Tervitada muutuvaid nõudeid, isegi kui need ilmnevad projekti lõpus. Väledad
metoodikad rakendavad muutusi kliendile konkurentsieelise saavutamiseks.
3. Üle anda töötavad tarkvara tihti, paari nädala kuni paari kuu tagant, eelistades lühemat
aega.
4. Äriinimesed ja arendajad peavad töötama igapäevaselt koos kogu projekti jooksul.
5. Teostame projekte motiveeritud inimestega. Anname neile keskkonna ja toetuse, mida
nad vajavad ning usaldame neid, et nad saavad hakkama.
6. Efektiivseim viis edasi anda infot arendajatele ning arendajate endi vahel on näost-
näkku suhtlus.
7. Töötava tarkvara on peamine edu mõõdupuu.
8. Väledad protsessid edendavad jätkusuutlikku arendust. Sponsorid, arendajad, kasutajad
peavad säilitama mõõduka tempo kogu projekti jooksul.
9. Pidev tähelepanu tehnilisele täiuslikkusele ja hea disain tõstab väledust.
10. Lihtsustamine – kunst suurendada mittetehtava töö hulka – on hädavajalik.
11. Parim arhitektuur, nõuded, disain saavutatakse iseorganiseeruvates tiimides.
12. Tiim peab regulaarselt tehtule tagasi vaatama ning mõtlema, kuidas olla veel
efektiivsem ning siis oma käitumist vastavalt muutma.
Väledateks loetakse järgmisi metoodikaid: ekstreemprogrammeerimine, erisus-juhitud
arendus (feature-driven development, FDD), adaptiivne tarkvaraarendus (adaptive software
development, ASD), dünaamiline süsteemiarendusmeetod, Crystal metoodikate perekond,
kulusäästlik arendus (lean development), Scrum. Samuti loetakse väledaks avatud
lähtekoodiga arendust (open-source development) [Abrahamsson et al. 2002].
Ka RUP loojad on väledat lähenemist metoodikasse sisse toomas...
Kuigi praktikas on kõiki väledaid metoodikaid edukalt rakendatud, on mõned kriitikud
jäänud nende suhtes skeptiliseks. Väleda arenduse põhimõtteid on peetud kaose tekitajaiks
ning lihtsalt ettekäändeks, et ignoreerida igasugust planeerimist ja programmeerida kuidas
juhtub (nn. license to hack) [Rakitin 2001].
-
12
1.4 Väledate metoodikate praktiline kasutatavus
Cutter Consortium viis aastal 2001 läbi uuringu, kus uuriti eri metoodikate kasutamist
tarkvara arendavates firmades [Charette 2001]. Uuringus osales 200 IT/IS juhti üle maailma
(neist 33% Põhja-Ameerikast, 20% Euroopast). Osalejaid oli nii tarkvarafirmadest (39%) kui
ka ettevõtetest kelle põhitegevus pole tarkvara loomine (nt. finantsasutused,
telekommunikatsioonifirmad jne). Uuritavate organisatsioonide suurus (väljendatuna käibes)
oli samuti erinev – 37% firmades oli aastakäive alla 5 milj. USD, 13% firmadest olid üle
miljardidollarilise käibega. Uuringu peamine eesmärk oli võrrelda väledate ja raskete (heavy
methodologies) metoodikate kasutamise vahekorda. Rasketeks loetud metoodikatest olid
enim-kasutatud järgmised:
1. Rationali unifitseeritud protsess (RUP) – 51%
2. Suutvusküpsuse mudelil (CMM) baseeruv lähenemine – 27%
3. ISO 9000 kvaliteedistandardil baseeruv lähenemine – 26%
Väledatest lähenemistest oli levinuim iseväljatöötatud väleda metoodika kasutamine, mida
oli teinud 54% küsitletutest. Joonis 3, mis kujutab teiste väledate metoodikate populaarsust,
näitab, et kõige rohkem oli kasutatud ekstreemprogrammeerimist (XP).
38%
23% 22%19%
9% 8% 7%3%
0%5%
10%15%20%25%30%35%40%45%
osak
aal v
asta
nute
st
XP FDD
ASD
DSDM mu
u
Crys
tal C
lear
LDSc
rum
Joonis 3. Enim-kasutatud väledad metoodikad [Charette 2001]
-
13
Loomulikult ei välistanud ühe metoodika kasutamine teiste kasutamist ning tavaliselt
kasutavadki tarkvara arendajad mitmeid metoodikaid kas eri projektides või samas projektis
kombineerides.
Evans Data Corporation [Evans] on alates 1998.a. uurinud tarkvara arendust Põhja-
Ameerikas. Märtsis-aprillis 2003 toimunud uuringus [NADS 2003] küsitleti üle 600 ettevõtte
ning muuhulgas päriti ka seda, millist metoodikat nad kasutavad arenduseks. Suurim osa, ligi
40% vastanutest väitsid end kasutavat oma väljatöötatud metoodikat. 15% firmadest ei
kasutanudki mingit metoodikat. Metoodikate kasutatavust kujutab Joonis 4.
16%
9%
7%6% 5%
2%1% 0% 0%
0%
2%
4%
6%
8%
10%
12%
14%
16%
18%
osak
aal v
asta
nute
st
RAD XP mu
u
väle
prog.
RUP
JAD
Scrum
DSDM
SASD
Joonis 4. Põhja-Ameerikas kasutatud metoodikad [NADS 2003]
Austraalia firma Shine Tehnologies [Shine] on käesoleva aasta alguses viinud läbi väikese
küsitluse väledate metoodikate kasutatavusest, kus osaleti nende veebilehe kaudu 131 korral.
Hääletajatel oli valida nelja alternatiivi vahel: XP, Scrum, Crystal, FDD, muu. Neist levinuim
vastus oli ülekaalukalt XP, millele järgnesid muu, FDD, Scrum.
Eestis on autor kõige enam täheldanud omaloodud metoodikate kasutamist, mis tihti on
koskmudeli lihtsustatud või täiustatud vormid. Selle põhjuseks on ilmselt Eesti väiksus ja
sellest tulenevalt ka meie firmade ja arendusprojektide väiksus (Eesti suurimate
tarkvarafirmade aastakäive on autori hinnangul 2-4 milj. USD). Oma metoodika kõrval on
suuremate organisatsioonide hulgas populaarsust kogumas ka RUP-põhine lähenemine,
-
14
kusjuures tavaliselt kasutusele võetud vaid väike osa. RUP populaarsuse põhjuseks Eestis
võib lugeda Rational Corporationi efektiivset müügitööd. RUP on tegelikult ainus metoodika,
mille aktiivse müügiga Eestis tegeletakse.
Järgnevates peatükkides on antud ülevaade levinumatest väledatest metoodikatest, nende
üldisest filosoofiast, väärtustest, põhimõtetest, praktikatest ning arendusprotsessist.
2 Rationali unifitseeritud arendusprotsess Rationali unifitseeritud arendusprotsess (Rational Unified Process, RUP) on iteratiivne ja
inkrementaalne tarkvara arenduse metoodika. RUP üritab maandada arendusprojekti riske
võimalikult varakult.
Rationali unifitseeritud arendusprotsess on:
• Iteratiivne ja inkrementaalne
• Katab põhjalikult tervet arendusprotsessi
• Konfigureeritav eri olukordade ja organisatsioonide jaoks
• Keskendub mudelite loomisele ja haldamisele
RUP kasutab mudelite loomisel UML tarkvara modelleerimiskeelt.
Rational Corporation müüb RUP-iga töö lihtsustamiseks spetsiaalset tarkvara, näiteks
Rational Rose visuaalseks modelleerimiseks ja ClearCase konfiguratsioonihalduseks. See on
ilmselt ka üks RUP-i suure populaarsuse põhjuseks. [Abrahamsson et al. 2002]
Reaktsioonina viimasel ajal tarkvaratehnika valdkonnas toimunud muutustele on ka RUP-i
uues versioonis v2002 endisest enam rõhku pandud väikestele projektidele ning väledatele
protsessidele. Lisatud on hulk väledate metoodikate (nt. XP) parimaid praktikaid ning
juhiseid, kuidas RUP-i väledalt kasutada.
Väikeste projektide (3..10 arendajat) jaoks on loodud spetsiaalne konfiguratsioon, millest
on välja jäetud suurtele projektidele mõeldud keerulised protseduurid ja mahukad
dokumendid ning lisatud lihtsad juhised ja praktikad. Kuigi ka enne oli võimalik ja isegi
kohustuslik RUP-i enda vajadustele kohaldada ja väikeste projektide puhul valida vaid need
osad, mis kasulikud, on nüüd suur osa sellest tööst juba Rationali asjatundjate poolt eelnevalt
tehtud. See teeb RUP-i rakendamise väikeste projektide korral palju lihtsamaks. [RUPweb]
-
15
Unified Processi juured on Ivar Jacobsoni töös, mida ta tegi Ericssonis 1960ndate aastate
lõpus. Jacobson ja tema kolleegid modelleerisid väga suuri telekommunikatsioonisüsteeme.
Jacobson asutas 1987. aastal oma firma Objectory AB, kus mõne aastase töö tulemusel loodi
Objectory, mis oli nii arendusmetoodika kui ka toode. Varsti pärast seda Rational ostis
Objectory AB, Jacobson alustas tööd koos Grady Booch’i ja James Rumbaugh’ga. Nende
koostööst sündis Rational Objectory Process (ROP), RUPi esialgne versioon. [LeisIT]
2.1 Praktikad
Praktikate kirjeldused toetuvad suures mahus allikatele [Seeba 2001] ning [RUP 2002].
2.1.1 Iteratiivne tarkvara arendus
Tänapäeva keeruliste süsteemide arendamisel on võimatu kõigepealt defineerida kõik
nõudmised ning alles siis asuda programmeerima. Iteratiivne arendus võimaldab läheneda
probleemile samm-haaval, arendades süsteemi väikeste iteratsioonide kaupa. Iga iteratsioon
läbib kõik elutsükli sammud analüüsist integratsioonini ning vähendab seeläbi projekti riske
varakult. Näiteks ei jää integratsiooniriskid projekti lõppfaasi. Iteratiivsus võimaldab paremini
näidata progressi, kuna iga iteratsiooniga valmib demonstreeritav kood. Iteratsiooni tulemus
antakse proovida lõppkasutajale, kes saab nii varakult anda tagasisidet ja juhtida tähelepanu
võimalikele puudustele. Kuna arusaamatused lahendatakse varakult ning muutuvaid nõudeid
on võimalik arvestada, aitab see lahendada ühte suuremat probleemi – projekti tulemusena
valminud tarkvara mittevastavust kasutaja tegelikele nõudmistele.
2.1.2 Nõuete haldamine
Nõudmine on tingimus või suutlikkus, millele loodav süsteem peab vastama. Nõuete
haldamine on süstemaatiline tegevus tarkvarale esitatavate muutuvate nõudmiste leidmiseks,
organiseerimiseks, dokumenteerimiseks ja nendest kinnipidamise jälgimiseks. Nõuete
haldamise läbi on paremini tagatud loodava süsteemi vastavus kasutaja tegelikele vajadustele.
2.1.3 Komponendipõhise arhitektuuri kasutamine
Komponendid on mitte-triviaalsed moodulid, alamsüsteemid, mis täidavad konkreetset
ülesannet ja millel on hästidefineeritud liidesed, mis kapseldavad sisemise funktsionaalsuse.
Seetõttu on komponendid lihtsalt asendatavad ja taaskasutatavad. Komponendipõhine
arhitektuur vähendab süsteemi keerukust ning on seepärast jõulisem ja paindlikum.
-
16
2.1.4 Tarkvara visuaalne modelleerimine
Mudel on süsteemi lihtsustatud vaade. Visuaalne modelleerimine on teatud sümboolika ja
märgendite abil süsteemi arhitektuuri ja disaini kujutamine. See võimaldab keerukat süsteemi
kergemini mõista ning annab meeskonnale ühise arusaama loodavast süsteemist. RUP toetab
modelleerimiseks UML-keele (unified modeling language) kasutamist.
2.1.5 Pidev tarkvara kvaliteedi kontroll
Kvaliteetne tarkvara vastab seatud nõudmistele ning rahuldab kasutaja vajadused ja
ootused. Kui traditsiooniline tarkvaraloome protsess jätab tarkvara kvaliteedi kontrollimise e.
testimise protsessi lõppu, siis RUP soovitab kvaliteeti kontrollida kogu protsessi jooksul, et
puudusi varem kõrvaldada.
2.1.6 Tarkvara muudatuste juhtimine
Tarkvara loomisel tekib suur hulk erinevaid tehiseid ning neid muudavad tavaliselt mitmed
inimesed. Tehistest on protsessi käigus olemas erinevad versioonid, mis ei pruugi omavahel
kooskõlas olla. Muudatuste haldus võimaldab arendajate meeskonnal paralleelselt koos
töötada, tekitades igale arendajale oma isoleeritud töökeskkonna, samas võimaldades
kontrollida, jälgida ja tagasi võtta kõiki muutusi, mida tehistesse on tehtud.
2.2 Protsess
Tarkvara arenduse protsess RUP-i järgi jaguneb neljaks faasiks:
1. Algatusfaas – defineerib projekti ulatuse
2. Detailimisfaas – planeerib projekti, spetsifitseerib erisusi (feature), loob arhitektuuri
3. Konstrueerimisfaas – valmistab toote
4. Siirdefaas – kannab toote lõppkasutajateni
Igas faasis läbitakse üks kuni mitu iteratsiooni. Igas iteratsioonis on erinev rõhuasetus
erinevatel töövoogudel, nagu nõuete tuvastamine, analüüs, projekteerimine, teostus, testimine
jne (Joonis 5).
-
17
Joonis 5. RUP protsessifaasid ja põhivood [Seeba 2001b]
2.3 Täiendav info
RUP kohta saab palju infot raamatutest [Royce 1998], [Jacobson 1999] ja [Kruchten 2000]
ning RUP kodulehelt [RUP].
Asko Seeba on kirjeldanud oma magistritöös [Seeba 2001] metoodikat detailsemalt ning
toonud ühe juhtumianalüüsi selle rakendamisel reaalses Eesti tarkvarafirmas.
3 Ekstreemprogrammeerimine Ekstreemprogrammeerimine (extreme programming, XP) [Beck 1999] on kahtlemata kõige
kuulsam ja levinum väleda tarkvaraarenduse metoodika. XP on kergekaaluline ning mõeldud
väikese ja keskmise suurusega tiimidele, kes seisavad silmitsi kiirelt muutuvate nõuetega. XP
võtab muutust kui paratamatust ning üritab hoida muutuste tegemise hinna madala igas
projekti faasis. XP üheks põhiideeks on teha võimalikult vähe, kuid siiski piisavalt et
väljastada kvaliteetset tarkvara. XP loojate arvates peaks iga arendaja endalt pidevalt küsima
– kas ma saaksin midagi veel vähem teha aga ikka tasemel olla? [Beck 1999]
XP neli põhiväärtust on suhtlemine, lihtsus, tagasiside ja julgus [Beck 1999].
• Suhtlemine. Paljud probleemid projektis on põhjustatud sellest, et inimesed (klient,
arendajad, projektijuht jne) ei suhtle omavahel piisavalt. XP väärtustab
-
18
intensiivsemat suhtlemist, soodustades seda mitmete praktikatega, nagu
paarisprogrammeerimine jm.
• Lihtsus. XP soodustab seda, et alati loodaks kõige lihtsam lahendus, mis hetkel oma
eesmärgi täidaks. Kuna muutuse tegemise hind on viidud madalale, on mõistlikum
rahuldada täna ainult tänaseid vajadusi ning muuta lahendust keerulisemaks hiljem,
kui seda vaja peaks olema.
• Tagasiside. Nii arendajad kui kliendid saavad projektis piisavalt tagasisidet.
Arendajad saadava tagasisidet automaatsete testide kaudu ning klientidelt. Kliendi
poolt soovitud erisustele annavad tagasisidet arendajad. Väljastades tihti tarkvara
vaheversioone kasutajatele kasutada, saadakse väärtuslikku infot.
• Julgus. XP projektis peab arendajatel olema julgust teha suuri muutusi, teha juba
tehtut ümber, lihtsustada. Kui midagi on tehtud täiesti valesti, peab olema julgust
valesti tehtud kood ka lihtsalt ära visata ja otsast alata.
3.1 Praktikad
XP on kirjeldatud lihtsate praktikatega, mis on enamasti ammutuntud, läbiproovitud, kuid
unustatud. XP mitte ainult ei taasavastanud neid meetodeid, vaid andis neile ka uue avarama
interpretatsiooni ja sisu [Leis 2002 TTÜ].
3.1.1 Plaanimismäng
Plaanimine jaguneb kaheks. Redaktsiooni plaanimisel valib klient välja kasutajalood, mida
hakatakse arendama. Iteratsiooni planeerimisel valib klient välja eelistatumad kasutajalood,
mida selles iteratsioonis arendada võiks, mille hulgast arendajad hakkavad arendama. [XP 1]
Eesmärk on määrata järgmisel iteratsioonil realiseeritavad süsteemi omadused (features)
kliendilugude (stories) alusel. Kliendilood on kliendipoolsed süsteemi soovitud omaduste
lühikirjeldused (ühel lehel). Programmeerijad hindavad kliendilugude realiseerimiseks
vajalikku aega. Vastavalt lugude olulisusele süsteemi loomise antud etapil ja
programmeerijate ajahinnangutele määrab kliendi esindaja, missugused lood tuleb järgmisel
iteratsioonil realiseerida. Nii realiseeritakse esmalt süsteemi kõige olulisemad omadused.
[Leis 2002 TTÜ]
-
19
Tihe koostöö kliendi ja programmeerijate vahel. Programmeerijad hindavad kliendi
kasutajalugude teostamiseks kuluvat aega ja klient selle peale otsustab redaktsioonide ulatuse
ja ajastuse. [Abrahamsson et al. 2002]
3.1.2 Väikesed redaktsioonid
Iteratsiooni kestus on tavaliselt kolm nädalat, igal iteratsioonil antakse kliendile töötava
süsteemi (nudi-) versioon. Nii saab klient otsekohe loodava süsteemiga tööd alustada ja teha
uute lugude kaudu ettepanekuid märgatud puuduste kõrvaldamiseks ja süsteemi
täiendamiseks järgnevates iteratsioonides. [Leis 2002 TTÜ]
Arendus käib lühikeste 1..3 nädala pikkuste iteratsioonidega, igaühe lõpus on olemas
töötav, testitud kood, mis antakse kliendile kasutada ja testida. Lõppkasutajatele antakse
vaheversioon kasutada iga redaktsiooni lõpus, mis toimub tavaliselt 2..5 iteratsiooni tagant.
[Cockburn 2001]
3.1.3 Metafoor
Süsteem on defineeritud metafooride abil. See jagatud lugu juhib kogu arendust kirjeldades,
kuidas süsteem töötab. [Abrahamsson et al. 2002]
Kogu meeskonda ühendab metafoor ehk ühine visioon, mis kirjeldab kuidas üldiselt
programm peaks töötama. Parim metafoor on lihtne kirjeldus, näiteks „see programm töötab
nagu mesilastaru, kes käivad mett korjamas ja toovad selle tarru tagasi“ võib kirjeldada
agendipõhist infohankesüsteemi. [XP 1]
3.1.4 Lihtne disain
Üritatakse disainida lihtsaim võimalik lahendus, mis töötaks. Ebavajalik keerukus
eemaldatakse kohe. [Abrahamsson et al. 2002]
Realiseeri programmi lihtsaim variant, mis töötab, mis tänaseid vajadusi rahuldab.
Täiendada jõuab alati. Ei mingit tulevikuvajaduste ennustamist, neile orienteerumist, sellega
programmi tarbetut komplitseerimist ja programmi valmissaamisega venitamist. [Leis 2002
TTÜ]
3.1.5 Testimine
Klient kirjutab teste oma lugude verifitseerimiseks. Programmeerijad kirjutavad teste, et
avastada vigu kodeerimisel. Testid kirjutatakse enne kodeerimist. [Leis 2002 TTÜ]
-
20
3.1.6 Refaktoreerimine
Refaktoreerimine on programmi ümberstruktureerimine eemaldades kordusi, lihtsustades ja
lisades paindlikkust nii et süsteemi funktsionaalsus säilib. See on XP viis tarkvara
projekteerida ja see toimub pidevalt kogu projekti jooksul.
3.1.7 Paarisprogrammeerimine
Kogu kood kirjutatakse paaris ühe arvuti taga istudes. Üks programmeerija kirjutab, teine
vaatab pealt, leiab vigu ja mõtleb üldisemalt. Rolle vahetatakse aeg-ajalt.
3.1.8 Kollektiivne omand
Kirjutatud programmikoodi omandivorme on mitmeid. Igal failil või klassil võib olla oma
omanik, samuti igal arhitektuurilisel kihil jne. Ainult omanik võib oma koodi muuta. Kui
kellelgi teisel tekib vajadus muutuse järele selles koodiosas, palutakse omanikul muutused
sisse viia. XP eelistab programmikoodi kollektiivset omandit, s.t. iga programmeerija võib
muuta kogu koodi, kui tal parasjagu selleks vajadus tekib. See viib selleni, et kogu tiimil on
olemas ülevaade kogu koodi toimimisest ning iga programmeerijate paar saab tegutseda teiste
järel ootamata.
3.1.9 Pidev integreerimine
Tehtud muudatuste integreerimine toimub kohe peale muudatuste tegemist, mitte kord
päevas või projekti lõpus. Sellega on garanteeritud integreerimisprobleemide varajane
avastamine ja riskide kiirem maandamine. Peale iga muudatuse integreerimist käivitatakse
uuesti kõik seni loodud automaatsed testid.
3.1.10 40-tunnised nädalad
Pidevad ületunnid on märgiks muudest, tõsisematest probleemidest projektis. Üle kahe
nädala järjest pole XP projektis lubatud ületunde teha. Puhkus on oluline eeldus arendajate
töötahte tekkimiseks ja töövõime säilimiseks.
3.1.11 Klient meeskonnas
Tulevase süsteemi reaalne kasutaja peab olema pidevalt meeskonnas ja kättesaadav kõigile
arendajatele. Ta vastab küsimustele, määrab prioriteete ja aitab teste luua.
-
21
3.1.12 Kodeerimisstandard
Kogu tiim järgib ühtset koodi kirjutamise standardit. Kuna XP kasutab koodi kollektiivset
omandit, pole mõeldav, et igaüks kirjutab omas stiilis. Ühtne kodeerimisstandard muudab
koodi kõigile arusaadavaks ja jälgitavaks.
3.2 Protsess
XP arendusprotsess koosneb teineteisele järgnevatest redaktsioonidest (release). Iga
redaktsiooni lõpus viiakse tarkvara üle töökeskkonda. Esimene redaktsioon kestab
järgnevatest kauem, kuna protsess nullist kuni esimese töökõlbuliku tarkvarani võtab rohkem
aega. Kui kliendil peale mingit redaktsiooni enam uusi soove pole, lõpetatakse projekt (seda
nimetatakse projekti surmaks). Iga redaktsioon koosneb hulgast iteratsioonidest. Redaktsiooni
pikkus on tavaliselt 1..3 kuud, üks iteratsioon kestab 1..3 nädalat. Esimene, teistest pikem
redaktsioon kestab enamasti 2..6 kuud [Beck 1999].
Iga redaktsioon algab redaktsiooni planeerimisega, mille käigus klient määrab redaktsiooni
jooksul teostatavad kasutajalood. Iga iteratsioon algab iteratsiooni planeerimisega, kus
valitakse hulk lugusid välja selles iteratsioonis teostamiseks [XP 2].
Redaktsiooniplaanimine Iteratsioon
Vastuvõetavus-testid Väljastamine
Kasutajalood
Nõuded
Redaktsiooniplaan
VIimaneversioon
Kliendinõusolek
Järgmineversioon
Testistsenaariumid
Joonis 6. Ekstreemprogrammeerimise lihtsustatud arendusprotsess [XP 2]
3.3 Täiendav info
Ekstreemprogrammeerimise kohta on ilmunud üsna palju kirjandust ja materjale. Esimene
sellel teemal ilmunud raamat on [Beck 1999], mis kirjeldab metoodika ühe looja Kent Becki
esimest nägemust metoodikast, XP teket ning põhimõtteid. Raamatud [Beck et al. 2000] ja
[Jeffries et al. 2000] selgitavad vastavalt planeerimise ja juhtimisega seotud aspekte ning
metoodika praktilise rakendamisega seotud küsimusi. Erinevate aspektide tutvustamisele on
-
22
pühendatud terve hulk raamatuid, näiteks [Fowler et al. 1999] räägib refaktoreerimisest,
[Williams et al. 2002] paarisprogrammeerimisest jne.
Paarisprogrammeerimist on Tartu Ülikoolis uurinud Sven Heiberg, Uuno Puus, Priit
Salumaa ja Asko Seeba, kes korraldasid eksperimendi paarisprogrammeerimise efektiivsuse
uurimiseks [Heiberg et al. 2003]. Seda teemat on käsitlenud Priit Salumaa ka oma
bakalaureusetöös [Salumaa 2002].
Internetilehekülgedel [XP 1] ning [XP 2] on samuti palju kasulikku infot ning viiteid
edasiseks uurimiseks. Eraldi leheküljed on pühendatud refaktoreerimisele [Refactoring] ning
paarisprogrammeerimisele [PairProgramming].
4 Erisus-juhitud arendus Erisus-juhitud arendus (feature driven development, FDD) on iteratiivne ja tulemustele
orienteeritud protsess, mis võimaldab arendajatel saavutada kiireid tulemusi samas mitte
kahjustades kvaliteeti. Fookus on rohkem inimestel kui dokumentatsioonil. FDD disainiti
eelkõige väikestele tiimidele, aga see skaleerub ka suurematele. Meeskonnad koosnevad
inimestest erinevate taustadega, äriinimesed (äriekspert/analüütik, kasutajad) ja tehnilised
inimesed (domeeniekspert, arendajad) töötavad koos. Info selles peatükis pärineb valdavalt
raamatust [Palmer et al. 2002].
FDD kirjeldab vaid projekteerimise ja teostuse faase ja vajab ülejäänud osade jaoks lisaks
mõnda muud metoodikat. FDD eeldab objekt-orienteeritud lähenemist [Abrahamsson et al.
2002].
FDD mõistab erisuse (feature) all loodava süsteemi ühte funktsionaalset nõuet e. omadust.
See on mingi tegevus, mida süsteem peab tegema. Erisus on kliendile arusaadav ja tema poolt
väärtustatud s.t. klient saab aru, et selle erisuse arendamine on talle kasulik. Ühe erisuse
arendus võib võtta ülimalt kaks nädalat, kuid tavaliselt mõned tunnid kuni mõned päevad. Kui
arendus võtab kauem, tuleb erisus lahutada mitmeks erisuseks. Arendusaja piirangu ning
kliendile mõistetavuse nõuetega tagatakse, et klient näeb, et pidevalt valmib midagi vajalikku
ning töö käib. See suurendab kliendi rahulolu ning võimaldab tal kiiremini tagasisidet anda.
Erisus-juhitud arendusmetoodikat rakendasid esmakordselt Peter Coad ja Jeff De Luca koos
Stephen Palmeriga ühes suures arendusprojektis aastatel 1997-1998. Aasta hiljem kirjutasid
Peter Coad ja Jeff De Luca raamatu „Java Modeling in Color with UML“ [Coad et al. 1999],
-
23
kus oli metoodikat kirjeldav peatükk (21 lehekülge). Stephen Palmer ja John Felsing
laiendasid ja parendasid metoodikat ning kirjutasid sellest aastal 2002 raamatu „A Practical
Guide to Feature-Driven Development“ [Palmer et al. 2002].
4.1 Praktikad
Erisus-juhitud arenduse parimad praktikad on pärit raamatust [Palmer et al. 2002].
4.1.1 Valdkonna modelleerimine
Probleemi valdkonna tähtsamate objektide ning nendevaheliste suhete kujutamine
üldistatud klassidiagrammi ning järjestusdiagrammiga (sequence diagram). Selle tulemuseks
on ühise arusaamise tekkimine probleemist ja valdkonnast.
4.1.2 Erisushaaval arendamine
Arendamine käib erisuste kaupa. Kõigepealt pannakse paika soovitavad erisused, seejärel
võib klient seada neile prioriteete, misjärel hakatakse neid ükshaaval arendama, alustades
kõrgema prioriteediga erisustest.
4.1.3 Individuaalne omand
Igal klassil on omanik, kelle poole pöördutakse, kui selles klassis midagi muuta on vaja.
See tagab parema skaleeritavuse, kuna igaüks ei pea tundma kogu süsteemi.
4.1.4 Erisusmeeskonnad
Olles kokku kogunud kõik erisused, jagatakse need ära kogenumate arendajate vahel,
kelledest saavad meeskonna liidrid e. vanemprogrammeerijad (chief programmer). Seega on
ka igal erisusel oma omanik. Vanemprogrammeerijad moodustavad iga erisuse arendamiseks
ajutise meeskonna, kuhu kuuluvad kõik programmeerijad, kellele kuuluvad klassid, mis on
vastava erisuse arendamisega seotud. Meeskonna töö on disainida ning programmeerida
erisus. Üks klassiomanik võib kuuluda ka mitmesse meeskonda samaaegselt.
Vanemprogrammeerija võib ka ise olla mõne klassi omanik.
4.1.5 Ülevaatused
Aeg-ajalt korraldatakse meeskondades ülevaatusi, kus kõik liikmed vaatavad üle kogu
erisuse jaoks loodud koodi. Seeläbi välditakse vigu ning jagatakse teadmisi ja kogemusi. On
oluline, et programmeerijad ei tunneks ülevaatuse ees hirmu või häbi, et nende tööd hakatakse
-
24
arvustama, vaid võtaksid ülevaatusi kui head võimalust õppida teistelt kogenumatelt
programmeerijatelt.
4.1.6 Regulaarsed translatsioonid
Regulaarselt pannakse kokku kõik valminud kood ning transleeritakse kogu süsteem. See
aitab varakult avastada integratsiooniprobleeme. Integreeritud süsteemi peal kontrollitakse
kõiki seni loodud automaatseid teste.
4.1.7 Konfiguratsioonihaldus
FDD vajab suhteliselt lihtsat konfiguratsioonihaldust, mis suudaks hoida kõigi klasside
ajalugu ja võimaldaks leida iga erisuse käigus muudetud klasse. Soovitav on
versioonihaldussüsteemi panna peale lähtekoodi ka kõik muud dokumendid, mida projekti
käigus muudetakse.
4.1.8 Tulemuste jälgitavus ja aruanded
FDD pöörab palju tähelepanu progressi jälgitavusele. Igal hetkel on teada, kus parasjagu
ollakse ning kui palju veel minna on.
4.2 Protsess
FDD arendusprotsess on iteratiivne ning koosneb viiest faasist (Joonis 7):
1. Üldmudeli (overall model) loomine
2. Erisuste nimekirja (features list) koostamine
3. Erisuste planeerimine
4. Erisuse disainimine
5. Erisuse teostamine (kodeerimine)
Kaks viimast faasi korduvad igas iteratsioonis.
Looüldmudel
Koostaerisustenimekiri
Planeerierisused
Disainierisus
Teostaerisus
Joonis 7. FDD arendusprotsess
-
25
4.3 Täiendav info
Erisus-juhitud arendust on kirjeldatud raamatutes [Palmer et al. 2002] ja [Coad et al. 1999].
Internetist saab lähemat infot FDD kodulehelt [FDD] ning metoodika ühe looja Peter Coad
kodulehelt [Coad].
5 Adaptiivne tarkvaraarendus Adaptiivse tarkvaraarenduse (adaptive software development, ASD) filosoofia aluseks on
pidev muutumine. Tänapäeva ärimaailmas on aina olulisem kiirus ja paindlikkus, kõik
muutub kiiremini kui varem. Äris kasutatav tarkvara peab sellega kaasas käima. Tarkvara
loomise protsess peab samuti olema paindlik ja võimeline reageerima ärimaailma kiiretele
muutustele.
ASD vaatleb tarkvara loomist kui ennustamatut protsessi, kus on võimatu kõike
adekvaatselt ette planeerida. Traditsioonilise koskmudeli kohaselt algab projekt
planeerimisega, millele järgneb teostus. ASD vastupidi väidab, et projekti planeerimine on
võimatu ning parim, mida me teha saame, on spekuleerida või oletada; vaadata kuhu see meid
välja viib; õppida tehtud vigadest ning minna uuele ringile. Seda iseloomustab ka ASD
arendustsükkel (Joonis 8).
Oleta
Õpi
Osale
Joonis 8. ASD arendustsükkel
-
26
Ärimaailmas on planeerimine raskendatud. Näiteks selle pärast, et klientide nõudmised
muutuvad, tehnoloogia muutub, konkurent tuleb välja uue tootega vms. Innovatsiooninäljases
ärimaailmas on toodete eluiga lühike ning pikalt planeerimine on võimatu, kuna sel juhul
võivad toote valmimisel olla turul juba teised nõudmised või konkurentidel juba sama toode
väljas. Determineeritud või staatilised lähenemised tarkvara arendusele ei suuda Jim
Highsmithi sõnul kaasaja nõudmisi rahuldada. Keerulises keskkonnas viib plaani järgimine
küll tooteni, mida plaaniti, kuid mitte alati tooteni mida tõeliselt vaja on.
ASD hindab pidevat õppimist. Seda iseloomustab pidev muutumine, ümberhindamine,
ebakindel tulevik ning intensiivne koostöö kõigi osapoolte (arendajate, testijate ja klientide)
vahel, kuna efektiivne tagasiside on kohanduva lähenemise puhul eriti oluline. ASD
vegeteerib kaose piiril. Ta pakub piisavalt juhiseid, et mitte langeda kaosesse, kuid mitte nii
palju, et maha suruda loomingulisust [Abrahamsson et al. 2002].
ASD loodi James A. Highsmithi poolt ja avaldati raamatus [Highsmith 2000]. Mitmed
põhimõtted on pärit „RADical Software Development“ metoodikast, mis loodi Highsmithi ja
S.Bayeri poolt 1994 [Abrahamsson et al. 2002].
2001. aasta veebruaris teatati ASD ja Crystal-perekonna metoodikate ühendamisest [Leis
2002 TTÜ].
5.1 Praktikad
ASD ei määratle konkreetseid praktikaid ja paljud detailid jäetakse lahtiseks. Konkreetsuse
puudus teeb metoodika otsese kasutamise raskeks ja metoodika enda pigem filosoofiliseks
lähenemiseks. Mõned enim-mainitud praktikad on iteratiivne ning komponendipõhine
arendus ning kliendi fookus-gruppide kasutamine.
Põhilised ASD iseloomustavad printsiibid on [Abrahamsson et al. 2002]:
• Missioon-juhitud. Kõik tegevused arendustsüklis peavad vastama projekti
missioonile. Missiooni all mõistetakse projekti üldist eesmärki, visiooni ja
põhinõudeid ning see ei ole staatiline, vaid võib muutuda, kui olukord seda nõuab.
• Komponendipõhine. Tegevus pole ülesannetele ja protsessile orienteeritud, vaid
töötava tarkvara loomisele. Süsteemi ehitatakse väikeste tükkide (komponentide)
kaupa.
-
27
• Iteratiivne. Kui keskkond ja nõuded pidevalt muutuvad ja arendus on turbulentne,
siis järjestikune koskmudel ei sobi. Pole oluline teha esimesel korral kõik õigesti,
vaid teha õigesti viimasel korral.
• Ajalahterdatud. Ebaselgeid küsimusi projektis leevendatakse sellega, et seatakse
käegakatsutavad tähtajad. See sunnib raskeid ja vältimatuid otsuseid tegema projekti
alguses.
• Muutusi salliv. Muutused on tavalised ja vältimatud tarkvara arenduses. Seetõttu on
pigem oluline neile reageerida, kui üritada neid kontrollida. Seega tuleb pidevalt
arvestada, et loodavaid komponente tuleb muuta.
• Risk-juhitud. Suurema riskiga tegevused tuleb teha nii vara kui võimalik.
5.2 Protsess
ASD protsessi tsüklis on kolm üldist faasi: Oleta (speculate), Osale (collaborate), Õpi
(learn). Oletamine on planeerimise asemel ja ilmestab planeerimise võimatust muutuvas
keskkonnas. Osalemine rõhutab tiimitöö tähtsust kohanduvas protsessis. Õppimine tähtsustab
vigade tunnistamist ja nendest õppimist [Abrahamsson et al. 2002].
Tsükliplaneeri-
mine
Projektialgatamine
Paralleelnekomponentide
arendus
Kvaliteediülevaatus
Väljas-tamine
Õppimistsükkel
Oleta Osale Õpi
Joonis 9. ASD arendusprotsess ja õppimistsükkel
Arendusprotsessi kujutab täpsemalt Joonis 9. Projekti algatusfaasis defineeritakse projekti
missioon, mis kirjeldab projekti eesmärki ning põhilisi nõudmisi. Alguses fikseeritakse ka
üldine ajakava ja arendustsüklid (iteratsioonid). Tsüklite pikkus on tavaliselt 4..8 nädalat. Iga
tsükli lõpus on kvaliteediülevaatus, mis viiakse läbi koos kliendiga. Projekti lõpetab lõplik
kvaliteediaudit ja tarkvara väljastamine [Abrahamsson et al. 2002].
-
28
5.3 Täiendav info
ASD metoodikast on kirjutatud raamatus [Highsmith 2000]. Internetist võib infot ja
artikleid leida ASD looja Jim Highsmithi kodulehelt [Highsmith].
6 Dünaamiline süsteemiarendusmeetod Dünaamiline süsteemiarendusmeetod (DSDM) on väle metoodika, mis põhineb RAD
(rapid application development) [Martin 1991] lähenemisel ja kasutab inkrementaalset
prototüüpimist. DSDM on väledatest metoodikatest ilmselt üks põhjalikem, kattes suure osa
arendusprotsessist. DSDM erineb teistest väledatest metoodikatest ka selle poolest, et
metoodikat haldab kasumit mittetaotlev DSDM konsortsium [DSDM]. Metoodika kasutamise
litsents on vaid konsortsiumi liikmetel, kes peavad tasuma aastamaksu ning saavad selle eest
ka ligipääsu metoodika täiskirjeldusele. Konsortsium korraldab ka koolitusi, pakub
kasutajatuge, arendab metoodikat edasi, haldab dokumentatsiooni ning tegeleb
sertifitseerimisega [Highsmith 2001]. Kuigi esmapilgul võib raha maksmine metoodika
kasutamise eest tunduda ebaratsionaalne, on ilmselt just tänu konsortsiumi olemasolule
DSDM hästi ja stabiilselt arenenud ning laialt levinud. Konsortsium loodi 1994. aastal 17 briti
firma poolt [Stapleton et al. 2003]. Praeguseks on konsortsiumil üle 400 täisliikme üle
maailma [DSDM].
DSDM on eriti populaarne oma sünnimaal Suurbritannias, kus seda ka intensiivselt
ülikoolides tulevastele tarkvarainseneridele õpetatakse. DSDM konsortsiumi kuuluvad briti
suurimad IT-teenuste pakkujad, väidetavalt isegi 13% neist, kelle käive on üle 100 mlj. naela
[Nicholson DSDM]. Metoodika koolitusprogrammi on läbinud üle 20 000 spetsialisti
[Stapleton et al. 2003].
Suurem osa selles peatükis toodud infost pärineb autori samal teemal kirjutatud
semestritööst [Otsason 2003], DSDM versiooni 4.1 käsiraamatust [DSDM Manual], raamatust
[Stapleton et al. 2003] ning konsortsiumi kodulehelt [DSDM].
Tarkvara kolmnurga kontseptsioon ütleb, et projektil on kolm põhilist näitajat: ajakulu,
rahakulu ning loodava tarkvara funktsionaalsus. Kõiki neid kolme ei saa projekti alguses
fikseerida, midagi peab jääma lahtiseks. DSDM üks põhikontseptsioone seisneb selles, et
fikseeritakse projektile kulutatav aeg ja ressursid ning lastakse funktsionaalsusel kohanduda,
-
29
vastupidiselt traditsioonilisele lähenemisele, kus fikseeritakse funktsionaalsus (nõuded), ning
seetõttu kipub varieeruma aja- ja ressursikulu (Joonis 10).
Joonis 10. Tarkvara kolmnurga mudel DSDM metoodika järgi
DSDM rakendamine on raskendatud, kui tegemist on protsessijuhtimise, reaalajasüsteemide
või ülikriitilise tarkvaraga. Põhjuseks on see, et DSDM projektis on oluline roll iteratiivsel
arendusel ning kasutajate osalusel, mistõttu peab progress olema kasutajatele hästi jälgitav ja
arusaadav. Ülikriitilise tarkvara arendusel vajaliku põhjaliku spetsifikatsiooni loomine ning
selle põhjal tarkvara valideerimine ja verifitseerimine on samuti raskendatud iteratiivse
lähenemise korral [DSDM Manual].
DSDM tiim peab olema väike (2..6 inimest), et minimeerida juhtimis- ja
kommunikatsiooni-probleeme. Ühes projektis võib korraga töötada mitu tiimi. Seega on
võimalik DSDM rakendada ka suurtes projektides, eeldusel, et ülesanne on dekomponeeritav.
Igas tiimis peab olema vähemalt üks arendaja ja üks kasutaja esindaja.
Tavaliselt on DSDM projektis üks või kaks tiimi. Praktika näitab, et rohkem kui kuue tiimi
korral võivad tekkida koordineerimis-probleemid ning kasutusele tuleks võtta lisameetmed
projekti juhtimiseks.
Populaarne on DSDM ja XP metoodikate kombineerimine, võttes esimesest üldise
projektijuhtimise raamistiku ja teisest efektiivsed arenduspraktikad [Stapleton 2001]. Hetkel
on arendamisel DSDM versioon 4.2, millesse ongi juba sisse toodud ka mõned
ekstreemprogrammeerimise elemendid ja praktikad [DSDM].
-
30
6.1 Põhimõtted
DSDM metoodika baseerub üheksal põhimõttel, mis on paljuski sarnased RAD
põhimõtetele.
6.1.1 Kasutajate aktiivne osalus
DSDM on kasutajakeskne lähenemine. Kui kasutajad pole projektiga pidevalt lähedalt
seotud, võivad tekkida viivitused otsustamisel ning kasutajad võivad tunda, et loodud
lahendus on neile arendajate poolt peale surutud. Kasutajad pole projektivälised liikmed, kes
annavad infot ja kontrollivad tulemusi, vaid on aktiivsed osalejad arendusprotsessis. See ei
tähenda, et kõik kasutajad peaksid projektiga seotud olema – projekti algatamisel valitakse
välja igast olulisest kasutajagrupist esindajad, kes töötavad ideaaljuhul kogu projekti vältel
koos arendajatega ühes ruumis, nii et otsuseid saaks teha kiiresti. Selline lähedane osalus võib
olla mõnikord raskesti saavutatav, kuna nõuab tellijalt lisainvesteeringut kasutajate tööaja
näol.
6.1.2 Tiim on volitatud otsustama
Tiimides osalevad arendajad ja kasutajad peavad omama piisavalt volitusi, et langetada
otsuseid, kui nõudeid täpsustatakse või need muutuvad. Nad peavad saama otsustada, kas
mingil tasemel funktsionaalsus või kasutamismugavus on projektile vastuvõetav jne. Iga
pisem muutus ei tohi nõuda juhtkonnaga kooskõlastamist. See eeldab nii tellija kui arendaja
juhtkonna soovi delegeerida väiksemates asjades otsustamisõigus tiimiliikmetele.
6.1.3 Sagedased väljalasked
DSDM tiim keskendub tehiste väljastamisele, mitte etteantud tegevuste läbiviimisele.
Sagedased väljalasked aitavad tiimil paremini otsustada, millised tegevused on vajalikud ja
piisavad, et luua õige toode. Samuti annab see juhtkonnale võimaluse olla paremini kursis töö
käiguga.
6.1.4 Ärieesmärkide saavutamine on esmatähtis
Projekti eesmärk on üle anda vajaliku ärifunktsionaalsusega tarkvara õigeks ajaks. Täiendav
disainimine ja lahenduse ilustamine võib toimuda hiljem, kui selleks on vajadus.
Traditsioonilise lähenemise korral on fookus sellel, et rahuldada nõuete dokumenti ja olla
vastavuses eelmiste tehistega, kuigi nõuded on tihti ebatäpsed, eelmised tehised vigased ja
nõuded võivad olla projekti käigus muutunud. DSDM projektis on tähtsam luua õige toode
-
31
kui luua seda õigesti. Äriline kasu loodavast tootest on olulisem kui tehniline meisterlikkus
või väljanägemine. Ärieesmärkide täitmine on tarkvara esmaseks vastuvõtukriteeriumiks.
6.1.5 Iteratiivne ja inkrementaalne arendus
Loodav süsteem areneb samm-sammult, et arendajad saaksid piisavalt tagasisidet
lõppkasutajatelt. Iteratiivne arendus võimaldab lahenduse paremat kooskõla kasutajate
tegelike nõudmistega. See võimaldab ka luua osalisi lahendusi, et rahuldada esmalt kõige
pakilisemad ärinõuded. Paraku võib sellise lähenemise korral tekkida probleeme, kui tarkvara
tellija ja arendaja pole sama organisatsioon – sel juhul on vajalik piisava usalduse olemasolu
ning valmidus lähedaseks koostööks kahe poole vahel.
6.1.6 Kõik muutused on tagasivõetavad
Iteratiivse ja inkrementaalse arenduse juures võib juhtuda, et vahest valitakse vale tee. Sel
juhul peab olema võimalik valed käigud kiiresti tagasi võtta. Konfiguratsioonihaldus peab
olema kasutuses kõikide tehiste (dokumendid, tarkvara, testid jne.) jaoks. Kõiki käsiloleva
inkremendi jooksul tehtud muutusi peab olema võimalik tagasi võtta. Mõnel juhul võib siiski
olemasoleva parandamine otstarbekam olla, kui suure hulga vahepeal tehtud muudatuste
tagasivõtmine.
6.1.7 Määratakse üldised nõuded
Projekti alguses pannakse paika vaid üldine eesmärk ja projekti ulatus ning ei „külmutata“
kohe kõiki nõudeid. Arendusprotsessi käigus määratakse nõuded detailsemalt, kuid projekti
ulatus ei tohiks seejuures enam oluliselt muutuda.
6.1.8 Testimine kogu projekti jooksul
Testimist ei võeta kui eraldi tegevust ning seda ei jäeta projekti lõppu. Kuna süsteemi
arendus toimub inkrementaalselt, siis toimub inkrementaalselt ka testimine ning proovimine
arendajate ja kasutajate poolt. Pidevalt kontrollitakse, kas süsteem on arenemas nii äriliselt
kui tehniliselt õiges suunas. Algfaasides testitakse rohkem vastavust funktsionaalsetele
nõuetele, lõpus pigem kogu süsteemi töö efektiivsust.
6.1.9 Kõigi osapoolte vaheline koostöö
Nõudeid ei fikseerita lõplikult projekti alguses, vaid need täienevad ja muutuvad kogu
projekti kestel. See nõuab head koostööd osapoolte vahel, et teha kiiresti õigeid otsuseid.
-
32
Tellija ja arendaja koostöö peab olema palju lähedasem, kuna puudub kõikehaarav formaalne
spetsifikatsioon, mille alusel süsteemi ehitatakse.
6.2 Protsess
DSDM arendusprotsess on iteratiivne ja inkrementaalne. Protsessis on viis põhifaasi ning
kaks lisafaasi:
• projektieelne faas (pre-project phase),
• teostuvusuuring (feasibility study),
• talitlusuuring (business study),
• funktsionaalse mudeli faas (functional model iteration),
• projekteerimise ja teostuse faas (design and build iteration),
• juurutamise faas (implementation),
• projektijärgne faas (post-project phase).
Joonis 11. DSDM arendusprotsessi faasid, iteratsioonid ja inkrement
-
33
DSDM arendusprotsessi põhifaase kujutab Joonis 11. Tumedate nooltega on näidatud
tüüpiline protsessi kulg, heledamad nooled näitavad võimalikke teisi liikumisi ühest faasist
teise. Lisaks on märgitud inkremendi ja iteratsioonide asukohad protsessis.
Teostuvusuuringu faas läbitakse vaid projekti alguses. Üheks inkremendiks nimetatakse
tsüklit, milles läbitakse talitlusuuringu, funktsionaalse mudeli, projekteerimise ja teostuse
ning juurutamise faasid. Iteratsiooniks nimetatakse ühte tsüklit funktsionaalse mudeli,
projekteerimise ja teostuse või juurutamise faasis. Ühes faasis tehakse tavaliselt kuni kolm
iteratsiooni. Iteratsioone nimetatakse DSDM metoodikas ka ajalahtriteks (timebox).
DSDM projektile eelnev faas (pre-project phase) kindlustab, et vaid õiged projektid
algatatakse. Selles faasis kontrollitakse ressursside olemasolu ning planeeritakse tegevusi
teostuvus- ning talitlusuuringu faasides. Vajadusel võib selles faasis korraldada projekti
liikmetele DSDM metoodika lühikoolituse. Projektile järgnev faas (post-project phase)
kujutab endast valminud lahenduse opereerimist ja hooldust.
Teostuvusuuringu (feasibility study) faas läbitakse üks kord projekti alguses. Selles faasis
otsustatakse, kas DSDM rakendamine on antud projektis mõttekas. Samuti püstitatakse
põhiprobleem, mida loodav süsteem peaks lahendama, antakse esialgne hinnang
ressursikulule ja uuritakse kriitilisemaid tehnilisi aspekte, tuvastamaks projekti tehnilist
teostatavust. Faasi pikkus on maksimaalselt paar nädalat.
Talitlusuuringu (business study) faasis uuritakse lähemalt talitluse nõudeid ning tehnilisi
piiranguid. Põhirõhk on äriprotsesside revideerimisel loodava tarkvara kontekstis. Kõik
nõuded koondatakse prioriteeritud nõuete nimekirja (prioritized requirements list). Samuti
määratakse süsteemi üldarhitektuur ja tuvastatakse loodava süsteemi kasutajagrupid. Igast
grupist püütakse saada projekti osalema kasutaja, kes esindaks selle grupi nägemust ja huve.
Selles faasis tehakse ka konkreetsem plaan arendustegevuseks järgmistes faasides.
Talitlusuuring kestab maksimaalselt mõned nädalad.
Järgmine faas projektis on funktsionaalse mudeli faas (functional model iteration). Suurem
osa reaalsest arendusest tehakse selles ning järgmises faasis inkrementaalselt prototüüpe
luues, millest lõpuks areneb välja üleantav süsteem. Teostatakse põhilised funktsionaalsed ja
mõned mittefunktsionaalsed nõuded, mis said määratletud talitlusuuringu käigus. Selle faasi
lõpuks valmivad funktsionaalne mudel ning prototüübid. Loodud tarkvara testitakse kohe,
kuid mitte-funktsionaalsed testid tehakse peamiselt järgmises faasis. Nende testide
ebaõnnestumisel on võimalik liikuda tagasi siia faasi, et viga parandada.
-
34
Projekteerimise ja teostuse faasis (design and build iteration) ehitatakse valmis kvaliteetne
süsteem, mis peaks juba vastama kõigile kokku lepitud nõuetele. Selle faasi lõpuks antakse
valmis süsteem kasutajate kätte. Tähtsaim tehis selles faasis ongi testitud süsteem (tested
system). See ei tähenda, et testimine toimuks vaid selles faasis – testimine DSDM protsessis
on pidev tegevus.
Selles faasis viiakse süsteem arenduskeskkonnast töökeskkonda, koolitatakse neid
kasutajaid, kes polnud projekti kaasatud ning kirjutatakse lõplikult valmis
kasutajadokumentatsioon. Faasis on mitu järjestikust iteratsiooni, kui süsteem on vaja anda
üle suurele kasutajahulgale samm-haaval. Sellest faasist võib edasi minna neljal viisil:
a) Kõik nõuded on täidetud ja projekti võib lugeda lõpetatuks.
b) Oluline osa funktsionaalsusest on veel teostamata, kuna vajadus selle järgi selgus
alles töö käigus. Minnakse uuesti talitlusuuringu faasi.
c) Madalama prioriteediga funktsionaalsus on jäetud lisamata. Protsess läheb tagasi
funktsionaalse mudeli faasi.
d) Vähemtähtsad tehnilised probleemid jäid veel lahendamata. Suundutakse
projekteerimise ja teostuse faasi.
6.3 Täiendav info
Sügavama huvi korral on heaks allikaks raamat [Stapleton et al. 2003], kus peale metoodika
tutvustuse sisaldub ka hulk juhtumianalüüse. DSDM konsortsiumi kodulehelt [DSDM] on
võimalik alla laadida tutvumisversioon metoodika käsiraamatust [DSDM Manual] ning muid
kasulikke materjale. Detailsemalt on metoodika lahti seletatud ka autori samal teemal
kirjutatud semestritöös [Otsason 2003].
7 Crystal Clear Crystal metoodikad tähtsustavad tarkvara loomeprotsessis eriti inimesi ja nendevahelist
suhtlust. Enamuse probleemide allikana nähakse just inimfaktorit ja informatsiooni
edastamise probleeme ning seetõttu keskendutakse nendele. Tarkvara arendamine on
meeskonnamäng, mille põhieesmärgiks on luua töötav tarkvara. Kõik ülejäänud tegevused on
vajalikud vaid siis, kui nad aitavad kaasa selle eesmärgi täitmisele. Crystal metoodikad on
tolerantsed, arvestades inimeste erinevustega. Kuna ükski projekt pole teisega lõpuni sarnane,
-
35
peetakse väga oluliseks metoodika kohandamist ja arendamist vastavalt vajadusele.
Kirjeldatud metoodikad pole mõeldud lõplikena. Tiim peaks neid võtma baasmetoodikatena,
mida muutes kujundatakse välja endile sobivaim lähenemine. Kõige efektiivsem
kommunikatsiooniviis inimeste vahel on näost-näkku suhtlus, üks ebaefektiivsemaid aga
paberdokumentide vahetamine. Crystal metoodikad rõhutavad seda ning eeldavad võimalikult
lähedast suhtlust tiimiliikmete vahel. Mida efektiivsemat suhtluskanalit kasutatakse, seda
vähem peab projekti käigus looma vahepealseid tehiseid ja dokumente [Cockburn 2001].
Crystal liigitab projektid tiimi suuruse ja loodava tarkvara kriitilisuse järgi ning pakub
erinevat liiki projektidele erinevaid lähenemisi. Tiimi suurus on kõige olulisem faktor
metoodika määramisel, kuna sellest sõltub inimestevahelise suhtlemise. Väikesed
meeskonnad mahuvad ära ühte ruumi ja saavad kõige vahetumalt ja efektiivsemalt suhelda,
suuremad peavad suhtlemiseks kasutama muid viise ning see nõuab ka hoolikamat
koordineerimist. Tarkvara kriitilisuse järgi jaotatakse projektid neljaks. Kriitilisus näitab, kui
suurt ohtu võib vigane tarkvara potentsiaalselt endast kujutada e. mida võivad kasutajad
kaotada, kui tarkvara ei tööta korralikult [Cockburn 2001]:
• Mugavus (loss of comfort) – tähistatakse „C“. Tarkvara mittetöötamine võib
põhjustada halvimal juhul kasutajatele ebamugavust. Näiteks otsingumootor
ettevõtte kodulehel.
• Mõningane raha (loss of discretionary money) – tähistatakse „D“. Vigane tarkvara
võib põhjustada mõningast rahalist kaotust. Näiteks väike internetikauplus.
• Oluline raha (loss of essential money) – tähistatakse „E“. Mittetöötav süsteem võib
põhjustada olulist rahalist kadu. Näiteks börsi kauplemissüsteem.
• Elu (loss of life) – tähistatakse „L“. Näiteks tuumaelektrijaama juhtimissüsteem.
-
36
Joonis 12. Projektide klassifikatsioon Crystal metoodika järgi [Cockburn 2001]
Joonis 12 kujutab projektide klassifikatsiooni suuruse ja kriitilisuse järgi. Horisontaalteljel
on projekti suurus, vertikaalteljel kriitilisus. Kriitilisemad projektid nõuavad metoodikalt
suuremat tseremooniat ja kontrolli. Crystal elukriitilisi projekte ei käsitle. Kirjeldatud ja
praktikas kasutatud on vaid Crystal Clear [Cockburn 2001] ja Crystal Orange [Cockburn
1998].
Crystal Clear on metoodika, mis mõeldud väga väikestele (4..6 inimest) tiimidele
kasutamiseks vähekriitilistes projektides, kus on esmatähtis kiirus (time-to-market) ja
efektiivsus. Oluline on vahetu kommunikatsioon nii tiimiliikmete vahel kui kliendiga
suheldes; tihti väljastatavad redaktsioonid (2..3 kuu tagant) ning versioonihaldus. Tiim peab
töötama koos ühes ruumis, et suhtlemine oleks kõige efektiivsem. Clear on selle autori,
Alistair Cockburni sõnul minimaalne, kuid siiski töötav metoodika [Cockburn 2001].
Clear projektis on järgmised rollid, mis nõuavad eraldi inimesi: sponsor, vanemdisainer-
programmeerija, disainer-programmeerija, kasutaja. Nendest inimestest võivad mõned täita
lisaks ka projekti koordinaatori, ärieksperdi ja nõuete koguja rolle [Cockburn 2001].
7.1 Praktikad
Kõik Crystal metoodikad näevad ette inkrementaalset arendust. Ei defineerita konkreetseid
tehnikaid tarkvara arendamise enda jaoks. Selle asemel võib kasutada tehnikaid teistest
metoodikatest, nagu XP, DSDM või Scrum. Põhilised Crystal Clear praktikad on
[Abrahamsson et al. 2002]:
-
37
7.1.1 Revision and review
Igas inkremendis on mitu iteratsiooni. Iga iteratsioon koosneb järgnevatest tegevustest:
ehitamine, esitlemine ja inkremendi eesmärkide ülevaatus.
7.1.2 Monitoorimine
Tiimi progressi monitooritakse tähtpunktide (start, ülevaatus 1, ülevaatus 2, test, evitus) ja
stabiilsuse (väga muutuv, muutuv, piisavalt stabiilne et üle vaadata) järgi.
7.1.3 Metoodika häälestamine
Metoodika häälestamine on üks tähtsamaid tegevusi. Metoodikat häälestatakse kuna iga
projekt on millegi poolest eriline ja metoodika peab sellega kohanduma. Kasutatakse
projektiintervjuusid ja koosolekuid, et pidevalt protsessi ennast parendada.
7.1.4 Kasutaja vaatlused
Kaks kasutajaülevaatust on soovitatud läbi viia ühe redaktsiooni kohta.
7.1.5 Reflection workshops
Iga inkremendi eel, järel ning soovitavalt ka keskel viiakse tiimis läbi tagasivaatav
koosolek, kus hinnatakse endi tegevust ja õpitakse tehtud vigadest.
7.2 Protsess
[Abrahamsson et al. 2002],...
7.3 Täiendav info
[Cockburn 2001]
[Cockburn CC]
[Crystal]
8 Muid metoodikaid ja lähenemisi Järgnevalt on kirjeldatud muid metoodikaid ja lähenemisi nagu suutvusküpsuse mudel
(CMM), ISO kvaliteedistandard, vähemlevinud väledad lähenemised nagu kulusäästlik
-
38
arendus, Scrum ja pragmaatiline programmeerimine ning Microsofti arendusmetoodika MSF.
CMM ja ISO kvaliteedistandard pole tarkvaraarenduse metoodikad.
8.1 Suutvusküpsuse mudel
Suutvusküpsuse mudel (Capability Maturity Model, CMM) on levinud mall
tarkvaraarendusprotsessi küpsuse hindamiseks ja parendamiseks. CMM defineerib
arendusprotsessi küpsusele viis taset, mis näitavad, milliseid protsessi võtmekohti (key
process area, KPA) vaadeldav organisatsioon toetab [Seeba 2001]:
1. Algne tase (initial). KPA-sid pole.
2. Protsess on korratav (repeatable). KPA-d: nõuete haldus, projekti planeerimine,
projekti jälgimine ja ülevaadete tegemine, alltöövõttude haldus, tarkvara
kvaliteedikontroll, tarkvara konfiguratsioonihaldus).
3. Protsess on defineeritud (defined). KPA-d: organisatsiooni fookus protsessil kui
tervikul, organisatsioonipoolne protsessi defineerimine, koolitusprogrammid, terviklik
tarkvaraarenduse juhtimine, tarkvaratoote arendus, gruppidevaheline koordineerimine,
vastastikused läbivaatused.
4. Protsessi juhitakse (managed). KPA-d: protsessi hindamine ja analüüs,
kvaliteedijuhtimine, toote defektide ärahoidmine.
5. Protsessi optimeeritakse (optimized). KPA-d: tehnoloogia innovatsioon, protsessi
muudatuste haldus.
CMM spetsifikatsioon sisaldab 18 KPA-d, 52 eesmärki ning 316 praktikat. CMM tasemel
olemiseks on vajalik vastava taseme eesmärkide täitmine, kuid mitte toodud praktikate
järgmine. Praktikad on toodud lihtsalt ühe näitena, kuidas üks küps arendusprotsess välja
võiks näha. Praktikate puhul on eelkõige silmas peetud suuri tarkvaraarenduse teenust
pakkuvaid organisatsioone, väikeste firmade ja projektide puhul on toodud praktikad enamasti
liiga mahukad ja bürokraatlikud [Paulk 1999].
On teada, et enamus tarkvara arendavatest organisatsioonidest asub CMM mõistes esimesel
tasemel, kuid sellest hoolimata ei saa öelda, et nad poleks edukad, kuna paljud neist teenivad
korralikku kasumit, neil on arvestatav turuosa ning nende kliendid on nendega rahul. Seega ei
saa CMM tasemest teha veel üheseid järeldusi organisatsiooni edukuse kohta [Wiegers 1996].
-
39
CMM mudeli esimene versioon loodi 1990 Carnegie Melloni ülikooli tarkvaratehnika
instituudis. Hiljem on loodud CMM mudeleid ka teiste valdkondade jaoks, nagu
süsteemitehnika jm. Aastal 2000 loodi erinevate valdkondade mudelite integreerimiseks ühtne
mudel CMMI (CMM Integration) ning praegu spetsiifilisi mudeleid enam edasi ei arendata ja
minnakse üle CMMI standardile. Üks CMMI erinevusi seisneb selles, et ei mõõdeta enam
tervet organisatsiooni ühtse tasemega, vaid hinnatakse iga valdkonda (nt. projekti plaanimine,
riskijuhtimine jne) eraldi. Nii võib organisatsioonil olla eesmärk jõuda eri valdkondades eri
tasemetele [CMM].
Täiendavat infot suutvusküpsuse mudeli kohta on võimalik saada internetilehelt [CMM],
kus leidub ka mudeli spetsifikatsioon. CMM ja väleda lähenemise erinevustest ja seostest on
räägitud artiklis [Boehm 2002].
8.2 ISO 9000
ISO 9001:2000 kvaliteedijuhtimissüsteemi järgi on kogu organisatsiooni väljatööte
protsesside juhtimise defineerimisel kõige peamiseks dokumendiks “Kvaliteedikäsiraamat”,
mis loetleb üles kõik protsessi valdkonnad või tegevused, mille jaoks on defineeritud mingi
kord. Iga sellise valdkonna kohta käiv kord on omakorda lahti kirjutatud vastavas
kvaliteedikäsiraamatu juhendis. Olulisemad peatükid (lisaks peatükkidele, millel on pigem
dokumendi struktuurne tähendus), millest ISO 9001:2000-le vastav kvaliteedikäsiraamat
koosneb, on:
• “Juhtkonna kohustused”,
• “Ressursside juhtimine”,
• “Toote valmistamine” ning
• “Mõõtmine, analüüs ja parendamine”.
Et ka teistele potentsiaalsetele partneritele, kes oma partnereid standardile vastavuse järgi
valivad, oma taset tõendada, võib peale protsessi juhtimise korda tegemist tellida vastavalt
organisatsioonilt auditi, kes positiivse tulemuse korral väljastab ettevõttele sertifikaadi.
Negatiivse tulemuse korral ei saa järgmist auditit enne kuue kuu möödumist tellida. Kuna
tõenäosus, et esimesel katsel kogemuste puudumisel võib selline audit ebaõnnestuda, on väga
suur, on soovitatav alguses tellida eelaudit, mis on pisut kergekaalulisem ning mille tulemusel
antakse soovitusi, kuidas olukorda parandada, ja kolm kuud selleks parandamiseks aega.
Seejärel tuleb “tegelik” audit [Seeba 2001].
-
40
8.3 Kulusäästlik arendus
Kulusäästlik arendus (lean development) sai alguse 1980’ndatel Jaapani autotootjate poolt
kasutusele võetud arendusmetoodikast, mis lühendas oluliselt nende arendusprotsesse ja andis
eelise teiste tootjate ees. Nagu ka paljud teised väledad metoodikad, võtab kulusäästlik
arendus muutust (nõuetes, disainis jm) kui vältimatut ning muutmine üritatakse teha
võimalikult lihtsaks. Kulusäästliku tarkvaraarenduse põhimõtted on pigem üldised juhtnöörid
arenduseks. Erinevalt põhjalikematest metoodikatest, ei määratleta rolle, tehiseid,
konkreetseid tööprotsesse jms. Printsiibid on järgmised [Poppendieck et al. 2003]:
1. Kõige üleliigse eemaldamine. Üleliigseks loetakse kõike, mis ei ole seotud kliendi
rahuldamisega või kasumi teenimisega. Näiteks spetsifikatsioonid, dokumentatsioon ja
kood, mis on valmis tehtud, kuid mida ei kasutata; üleliigsed protsessisammud,
ületootmine, ootamine, liigne funktsionaalsus jm. Kõike tuleb teha nii vähe kui
võimalik ja täpselt nii palju kui hädavajalik. Paksud dokumentatsioonipakid, mis
riiulitel tolmu koguvad, on selge raiskamine ja sellele ressursside kulutamisest tuleb
hoiduda.
2. Õppimise kiirendamine ja võimendamine. Arendustegevus erineb tootmistegevusest
selle poolest, et eesmärkide saavutamise viis pole ette määratud ning sõltub arendajate
loomingulisusest. Efektiivsem on saada tagasisidet ja vigadest õppida, kui proovida
kõike esimesel korral täiesti õigesti teha.
3. Otsustamine nii hilja kui võimalik. Olulised otsused süsteemi arhitektuuri ja disaini
suhtes lükatakse nii kaugele kui võimalik, et muutuste tegemine oleks lihtsam. Tähtis on
edasi lükata neid valdkondi puudutavad otsused, kus võib hiljem suurema tõenäosusega
esineda muutusi.
4. Evitamine nii kiiresti kui võimalik. Kiire tagasiside kasutajatelt hoiab ära asjatut tööd
ning aitab luua kasutajate nõuetele paremini vastavat tarkvara. Tihti väljastatavad
redaktsioonid aitavad saada vajalikku tagasisidet.
5. Tiim on volitatud otsustama. Tsentraliseeritud otsustamine pidurdab arenduskiirust.
Tiim peab olema volitatud ise kiirelt väiksemaid otsuseid vastu võtma. Arendajad ise
omavad parimaid eeldusi, otsustamaks tehniliste detailide üle. Lisaks sellele, tekitab
otsustusõiguse delegeerimine tiimiliikmetes vastutustunnet ning mõjub motiveerivalt.
6. Terviklikkust silmas pidav arendamine. Terviklikkus jaguneb väliseks ja sisemiseks
terviklikkuseks. Väline näitab, kui ühtsena kasutaja süsteemi tajub, kui hästi see kattub
tema vajaduste, väärtuste, elustiiliga. Sisemine terviklikkus näitab süsteemi enda
-
41
kooskõlalisust ning seda, kui hästi erinevad osad kokku sobivad ja koos töötavad.
Sisemine terviklikkus on eelduseks välisele. Sisemise terviklikkuse tagab efektiivne
kommunikatsioon arendajate endi vahel, välise aga tõhus infovahetus arendajate ja
kasutajate vahel.
7. Asjatu optimeerimise vältimine. Optimeerida on mõtet vaid lõpptulemust, mitte kõike,
mida võimalik. Militaarselt väljendatuna, pole tähtis pole võita iga lahingut, tähtis on
võita sõda. Tihti kipuvad arendajad optimeerima oma kitsast süsteemi osa, nägemata
üldist pilti. Probleem on veel aktuaalsem allhangete korral, kui iga allhankija hakkab
oma loodavat osa asjatult optimeerima.
Täpsemalt võib kulusäästlikust arendusest lugeda raamatust [Poppendieck et al. 2003], kus
peale põhimõtete on toodud ka konkreetsed ideed, kuidas neid põhimõtteid väledas
tarkvaraarenduses rakendada. Internetilehelt [LD] võib samuti leida mitmesugust infot ning
artikleid. Kulusäästlikust tootmisest ja arendusest üldiselt (mitte ainult tarkvaraarenduse
seisukohast vaadatuna) kirjutab [Womack et al. 1991].
8.4 Scrum
Scrum on väle tarkvaraarenduse metoodika, mis keskendub arendusprotsessi juhtimisele ja
kontrollimisele. Ta on lihtne ning baseerub tervel mõistusel (common sense) ja ülilihtsatel
praktikatel. Scrum ei kirjuta ette konkreetseid tehnikaid tarkvaraarenduseks, nende valik
jäetakse metoodika rakendajale. Tihti kasutatakse Scrum protsessis
ekstreemprogrammeerimise või muid konkreetseid meetodeid, nagu paarisprogrammeerimine,
koodi ülevaatused jms.
Scrum arendusprotsess jaotatakse sprintideks, mis on 2..6 nädala pikkused iteratsioonid,
mida teostavad 5..8-liikmelised väikesed iseorganiseeruvad tiimid. Iga iteratsiooni jooksul
disainitakse, kodeeritakse, testitakse ja evitatakse tarkvara. Tarkvara nõutavad erisused
koondatakse toote nõuete nimekirja (product backlog), kus klient need olulisuse järjekorras
prioriteerib. Iga sprindi alguses koostatakse sprindi nõuete nimekiri (sprint backlog), kust
arendajad neid teostama hakkavad. Sprindi jooksul muutusi sprindi nõuete nimekirja ei
lubata. Scrum metoodikale on iseloomulikud igapäevased kiirkoosolekud, kus kõik tiimi
liikmed selgitavad mida nad eelmisel päeval tegid, millega sellel päeval kavatsevad tegeleda
ning millised on takistused või probleemid, mis neid takistavad. Selle peamine eesmärk on
projekti käekäigust pidevalt adekvaatse ülevaate saamine [Scrum].
-
42
Esialgse info metoodika kohta leiab Scrum kodulehelt [Scrum] ning lehekülgedelt [Scrum
2], [Scrum 3]. Põhjalikumalt on Scrum kirjeldatud raamatus [Schwaber et al. 2001], mis
esitab nii teooria kui praktika koos hulga näidete ja juhtumanalüüsidega.
8.5 Pragmaatiline programmeerimine
Pragmaatilise programmeerimise (pragmatic programming, PP) mõiste tuleb Andy Hunt’i
ja David Thomas’e samanimelisest raamatust [Hunt et al. 2000]. Tegemist on kogumi
praktiliste näpunäidetega tarkvara loomiseks. PP ei ole arendusprotsess ning ei määra rolle ja
tegevuskäiku. Raamatu autorid olid ka väleda liikumise algatajate seas ning raamatus antud
juhised on kooskõlas väleda arenduse põhimõtetega. Seetõttu loetakse pragmaatilist
programmeerimist vahest samuti väledaks metoodikaks [Abrahamsson et al. 2002], [PP].
8.6 MSF
MSF (Microsoft solutions framework) on 1994. aastal loodud arendusmetoodika, mis
baseerub Microsofti tootearenduse praktilisel kogemusel. Metoodikat arendatakse edasi
vastavalt tööstusharus toimuvatele muutustele ja trendidele. Hetkel viimane versioon pärineb
2002. aasta juunikuust, kus üha rohkem on märgata väledate põhimõtete mainimist.
MSF paneb suurt rõhku arendusprotsessi kiirusele ja paindlikkusele ning üritab saavutada
projektide õnnestumist läbi järgmiste põhimõtete:
• Kliendikesksed projektid, mille tulemuseks on kliendi rahulolu.
• Kasutajakeskne disain, mis tagab kasutaja vajaduste ja soovide täitmise.
• Proaktiivne riskijuhtimine, mis leevendab projekti ebaõnnestumise riske.
• Tähtpunkipõhine (milestone-based) projekti elutsükkel, mis võimaldab paremat
kontrolli projekti üle.
MSF alustaladeks on efektiivne meeskonnatöö, proaktiivne riskijuhtimine ning paindlik
protsessimudel. MSF meeskonnad on väikesed ning koosnevad omavahel võrdsetest
liikmetest. Riskijuhtimisel on MSF-is oluline roll. Lähtutakse põhimõttest, et risk on
ar