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