Tarkvaraarendusprotsessid.
Lühitutvustus.

Juhan Pant

Tallinn 2004

Sisukord

Arendusprotsess

Code&Fix (kodeeri ja paranda)

Waterfall (kose mudel)

RUP (Rational Unified Process)

XP (Extreme Programming)

Arendusprotsessi töösserakendamine

Arendusprotsess

Arendusprotsess kirjeldab lähenemist tarkvara ehitamiseks, rakendamiseks ja võimalik, et ka hooldamiseks.

Arendusprotsessi peamiseks funktsiooniks on määrata kava, mille järgi toimub projektis analüüs, prototüüpimine, disain, realiseerimine, testimine ja muu sarnane.

Kodeeri-ja-paranda

Kodeeri-ja-paranda

(Code-and-fix, McConnell, Rapid Development)

Harva kasulik, tihti kasutatav. Kui projekti jaoks pole teadlikult mingit arendusprotsessi valitud, siis kasutatakse tõenäoliselt seda.

Tegevus algab üldideega süsteemist, mida soovitakse ehitada. Ametlik spetsifikatsioon võib olemas olla, aga ei pruugi. Seejärel kasutatakse suvalises kombinatsioonis disaini, kodeerimise ja testimise meetodeid, kuni süsteem on valmis

Kodeeri-ja-paranda

Eelised:

Aega ei kulu planeerimisele, dokumenteerimisele, kvaliteedikontrollile ega peaaegu üldse millelegi muule peale kodeerimise

Pole vaja mingeid projektijuhtimise alaseid oskuseid

Probleemid:

Sobilik ainult väga väikeste projektide jaoks (ajutised prototüübid, demod vms)

Raske hinnata projekti edenemist, kvaliteeti, riske

Fundamentaalsete vigade hiline avastamine

Kose mudel

Kose mudel

(Waterfall)

Selgeteks faasideks jaotatud arendusprotsess, vanim arendusprotsesside hulgas. Jaotus faasideks võib varieeruda, kuid sisaldab alati analüüsi, disaini ja ehitamist. Disainile eelneb alati täielik analüüs ja ehitamisele täielik disain.

Kose mudel

Eelised:

Annab häid tulemusi, kui nõudmised / süsteemi spetsifikatsioon on selged ja ei muutu projekti käigus ja projekt pole kuigi suuremahuline

Jaotus faasideks annab võimaluse projekti edenemist mingil määral hinnata

Sarnaneb teistes inseneritegevuse valdkondades (ehitustegevus jms) kasutatava protsessiga

Kose mudel

Probleemid:

Muutuvate nõudmiste raskendatud sisseviimine

Analüüsi ja disainifaasi lõpetatust on raske hinnata

Kipub tekitama liigmahukat dokumentatsiooni

Tagasiside töötava tarkvara baasilt saabub päris projekti lõpus

RUP, UP

Rational Unified Process®: firma Rational® (the e-development company ™) protsessitoode (process product)

Unified Process: RUP’i lihtsustatud tuumik. Protseduuriline juurdeehitus UML keeles defineeritud kirjeldustele. UML kirjeldab alusdiagrammitüüpe nagu klassidiagrammid ja jadadiagrammid. Ta ei määra meetodit või modelleerimisvaadet - selle annab arendusprotsess (nagu UP).

UP makro- / mikrostruktuur

RUP: struktuur

UML

Iteratiivne arendus

Kuna kose mudel töötab hästi väiksemate projektide puhul, siis rakendab UP “jaga ja valitse” lähenemist - projekt tükeldatakse lühikesteks, kaks nädalat kuni kaks kuud kestvateks, iteratsioonideks.

Üks iteratsioon on struktureeritud kose mudeli põhjal ja iteratsiooniga saavutatavaks eesmärgiks on realiseerida teatud hulk (tavaliselt üks-kaks) kasutusjuhtusid ja saada osaliselt töötav süsteem. UP on seega kasutusjuhtude poolt juhitav arendusprotsess.

Unified Process

Iteratiivne arendus

Värske edukate tarkvaraprojektide uuring näitab, et tarkvaraprojektide õnnestumise edufaktorite hulgas on esikohal iteratiivse arendusprotsessi rakendamine.

(MIT Sloan Management Review)

UP: faasid ja töövood

http://www.therationaledge.com/content/jan_01/f_rup_pk.html

Unified Process: faasid

Iteratsioonid ise on grupeeritud nelja järjestatud faasi:

Inception (algfaas, üks iterasioon)

Elaboration (täpsustamine)

Construction (ehitamine)

Transition (siire, üleviimine)

Kuigi rõhuasetused muutuvad eri faasides, sisaldavad kõik iteratsioonid (peale algfaasi oma) siiski analüüsi, disaini ja ehitamist.

Analüüs

Sõna analüüs kasutatakse tarkvaraarenduses väga erinevatel viisidel. Siin kasutatav definitsioon on:

Analüüs rõhutab probleemi ning vajaduste uurimist, mitte lahendust.

RUP töövoogudest vastaksid sellele definitsioonile Business Modelling (ärimodelleerimine) ja Requirements (nõudmised).

Disain

Disain rõhutab vajadusi (nõudeid) rahuldavat kontseptuaalset (loogilist) lahendust, mitte lahenduse realisatsiooni. Ehk: analüüsi õietitegemine.

UP eelised

Rakendatav suurtele ja ebaselgete ning muutuvate nõudmistega projektidele

Kõrgete riskide varane leevendamine

Varane nähtav edenemine

Varane tagasiside, kasutaja kaasahaaramine

Hallatud keerukus: meeskond pole halvatud väga pikkade ja keerukate arendussammudega

Projekti ajamahukust saab pärast esimeste iteratsioonide lõppu küllaltki täpselt hinnata

UP puudused

Vajab arenenud projektijuhtimist

Väikeste ja selgelt defineeritud ning stabiilsete nõudmistega projektide jaoks põhjendamatult keerukas

Sa ei ole UP’st aru saanud juhul kui ...

Mõtled, et inception = vajaduste analüüs, elaboration = disain, construction = realiseerimine (s.t. rakendad “kose” elutsüklit UP-le)

Mõtled, et elaboration-i eesmärgiks on täielikult ja detailselt defineerida mudelid, mis teisendatakse koodiks konstrueerimise faasis

Püüad defineerida enamikku vajadustest enne disaini või realiseerimise alustamist

Püüad defineerida enamust disainist enne realiseerimise alustamist; püüad täielikult defineerida ja lõpetada arhitektuuri enne iteratiivset programmeerimist ja testimist

Sa ei ole UP’st aru saanud juhul kui ...

Pikk aeg kulutatakse vajaduste või disaini tööle enne programmeerimise alustamist

Usud, et kasulik iteratsiooni pikkus on pigem neli kuud kui neli nädalat

Arvad, et UML diagrammide koostamine ja disain on aeg täielikult ning detailselt defineerida disain ja mudelid, ning programmeerimine on nende mehaaniline teisendamine koodiks

Arvad, et UP kasutamine tähendab teha palju võimalikke tegevusi ja luua palju dokumente, et UP on formaalne “askeldav” protsess, mis sunnib järgima paljusid samme

Sa ei ole UP’st aru saanud juhul kui ...

Üritad planeerida projekti detailselt algusest kuni lõpuni, spekulatiivselt ette näha kõiki iteratsioone ning neis toimuvat

Tahad uskuda plaane ja hinnanguid projektidele enne kui elaboration faas on lõpetatud

C. Larman, Applying UML and Patterns

Xtreme Programming

XP

XP

User Stories: erinevalt UPist kasutajalood lihtsad, lõppkasutaja nägemused, mitte liiga detailsed ja tehnilised

Release Planning: kogu tiim otsustab, palju ideaaljuhul iga kasutuslugu teostamisaega (sh. Testimine) võtab. Valitakse järgmisse release'i minevad kasutuslood. Eelistatakse sellist kasutuslugude komplekti, mis teeks juba midagi kasulikku ja mis oleks seega reaalselt testitav.

Projektil 4 param.t: skoop, kvaliteet, tööjõud, aeg. Massad tohivad maksimaalselt määrata max 3 neist, muidu tekib kiiresti jama. Kokkuleppe saavutamine nõutav.

XP: iteratsioon

Iter

XP: iteratsioon

Iteration Planning: valitakse välja järgmisse iteratsiooni (1-3 näd.) minevad kõige tähtsamad kasutajalood-progemistööd. Need valib klient. Samuti lähevad siia varemavastet bugid.

Kui progejal läheb kauem kui ta ise ennustas, lükatakse see ülesanne järgm. iter.desse. Ka ei tohi progeja lisada koodi midagi, mida pole nõutud (isegi kui see on cool ;). Klient ja massad olgu õnnelikud. Toppama ei tohi mingil juhul jääda.

Kaugemale kui käesolev iter. planeerida ei tohi. Kui on näha et asi on paigast ära, lepitakse uuel koosolekul jälle uus kava kokku.

XP: arendus

XP: arendus

XP: arendus

Iga hommiku on KÕIK tiimi osalised PÜSTIJALU ringis ja räägivad kõik hetke jamad ära. See väldib ajaraiskamist pikale lobale ja üleplaneerimisele (püstijalu tahad asjad kähku ja õieti kaelast ära saada, muidu tuleb homme hommiku kauem seista).

XP: code

XP: code

XP: koodimine

Niikunii vastutab kogu tiim süsteemi ülesehituse eest, mitte ainult selle väljamõtleja. Seetõttu tohib IGA tiimi liige XPs parandada/parendada igat koodi lõiku.

Kas nii ei puhke kaos? Ei. Enne kui kodeerid, lood Unit Testi nimelise softijupi, mille "tulele" sinu alles seejärel loodav kood peab vastu pidama. Ilma Unit Testita koodi ei aktsepteerita.

XP: kodeerimine

Pair Programming: 2 progejat ühe masina taga. Üks mõtleb ja kirjutab koodialgoritmi (taktik), teine jälgib vigade teket ja mõtleb, kuidas loodav kood muu süsteemiga integreerida (strateeg). Väidetavalt on see sama kiire kui igaüks oma masina taga, kuid kvaliteet olevat isegi kõrgem.

XP: kodeerimine

Refactor Mercilessly: progejatel on komme kasutada koodi, mis on valmis treitud väga ammu, ja olgugi et omal ajal kõva sõna, nüüdseks moraalselt aegunud, vana ja lapitud. Aegajalt tuleb iganenu siiski kas asendada või korda teha.

Koodi optimiseerimine jäta alati viimaseks, sa ei suuda iial ära arvata, mis saab pudelikaelaks. Make it work, make it right, then make it fast.

XP: kodeerimine

Move people around: vaheta aegajalt võimalusel koodijaid erinevate süsteemi osade koodimisel. Lõpuks tunnevad kõik progejad kogu süsteemi, asendamatuid koodijaid enam pole. Koodijad omakorda ei saa oma oskuste eest "karistada" sellega, et peavad tegema meeletut tööd ainult neile tuntud osade kallal, samal ajal kui teistel pole eriti midagi teha. Ka aitab selline võõra koodi kallal töötamine varem või hiljem ühiste koodimistandardite kujunemiseni.

XP: kodeerimine

Integrate Continously: Kui mingi muudatus saab valmis, siis tuleb see ka kohe "üles" panna. Nii on alati kood värske ja võimalikud jamad tulevad kohe välja. Korraga paneb koodi üles aint üks progejapaar.

Kogu tiim töötab ühes ruumis, ka kliendi esindaja, kõik on "online" ja asjadega kursis. Ületunnitööd ei tehta, sest XP on väga intensiivne tööviis.

XP: eelised

Pole vaja tugevat/ülitarka/kõikvõimast projektijuhti, kõik peavad kõigega vastavalt oma võimetele ja ülesannetele kursis olema. Sobib seega ka vähekogenud tiimile.

XP on tugev olukorras, kus klient ei tea, mida tahab. Kuna kliendi esindaja on XP tiimi liige, saab ta väga kiiresti aru, mida ja kuidas tahta. Ta peab pidevalt andma projekti ka oma panuse nii otsustamisel kui ka testimisel, mitte ainult kapriisitsema. Tegelikult lubavad XP reeglid kliendil isegi progemises osaleda.

XP: puudused

KÕIK, nii arendajad, massad kui klient, PEAVAD REEGLITEST KINNI PIDAMA. Keegi ei tohi oma positsoonist tulevat võimu/teadmisi kasutada teiste vastu, kogu töö aluseks on käigult tehtavad kokkulepped.

Ka muud XP eripärad tunduvad algul väga veidrad ja mõttetud, seega raskemalt harjutavad.

XP sobib eelkõike väikestele, 2-30 liikmelistele tiimidele.

Aga kuidas alustada...

...mis tahes arendusprotsessi juurutamisega reaalse töö tegemisel?

Tiimis peab olema konkreetset meetodit valdav kriitiline mass, mis vajadusel toetab-õpetab ka teisi. Pealesurutud arendusmeetod, mida keegi ei valda ega poolda, toob pigem jama kaela.

Arendusmeetodi valik

Lisaks meeskonnale tuleb arendusmeetodi valikul arvestada tehtava projekti iseloomu:

Demod: kontseptuaalmodelleerimine, mitte aga massiivne arendusmeetod nõuete, disaini ja testimisega

Uue tehnoloogiaga rakenduse loomine: analüüsi, disaini, realisatsiooni ja testimise faasidega iteratiivne arendusmeetod

Stabiilse rakenduse arendus või hooldus: kose meetod

Otsused proj. algul

Konkreetse arendusprotsessi standardist kinnipidamise ulatus

Dokumenteerimise ulatus

Iteratsiooni pikkus (normaalne on paar nädalat, 4 kuud on ülim piir)

Kes kellele mida (Kood? Dokid?) üle annab

Proj. ajal

1. iteratsioon tuleks igal juhul lõpuni viia, kasvõi väiksema skoobiga, siis alles selge kas asi töötab või ei. Sel ajal on tiimi igatine toetamine ülitähtis. Reeglina liialdab tiim töö hulgaga, mida arvab 1. iter.ga ära tegevat. 1. iter. keskel kindlasti koosolekul tiim ära kuulata.

Tagasisidet hankida ka peale järgmiste iter.de lõppu. Siis mõelda vajadusel arendusmeetodi customize'misele.

Peamised allikad

Torim, A. Loengusari “Objektorienteeritud disain”. TTÜ, kevad 2004

Rava, K. Loengusari “Infosüsteemi projekti juhtimine”. TTÜ, kevad 2004

Extreme Programming: A gentle introduction. http://www.extremeprogramming.org/

Tegelik elu

Ots...

Küsimusi?

Aitäh kuulamast/kannatamast ;)

Objektorienteeritud disain / modelleerimine

Ants Torim

2004-02-03T21:03:04