TARTU ÜLIKOOL Matemaatika-informaatikateaduskond Arvutiteaduse instituut Referaat XP vs. RUP Autor: Martin Mäe Juhendaja: Erik Jõgi Tartu, Sügis 2005
SISUKORD SISSEJUHATUS...3 XP...4 RUP...6 KOKKUVÕTE...8 KASUTATUD KIRJANDUS...9 2
SISSEJUHATUS Tarkvaraarendus (ingl. k. Software Engineering) on arenenud alates 1940test aastatest, mil sellele alale algus pandi ja pidev areng toimub ka tänapäeval. Erinevad aplikatsioonid on pidevalt arenenud ja nendega käsikäes on arenenud ka meetodid nende tegemiseks. Endiselt on tarkvaraarenduse eesmärk arendada tehnoloogiaid ja otsida võimalusi arendamaks tootlikust ja toodete kvaliteeti. Termin software engineering võeti kasutusele 1950te aastate lõpus. Programmeerijad teadsid varem arendamisest erinevatel aladel ja tekkis tõsine arutelu, mida tähendab sõna arendamine tarkvara jaoks. Ametlikult tähistas tarkvaraarendaja elukutse algust NATO teaduskonverents aastal 1969. Aastatel 1965 kuni 1985 (mõnede arvates kuni tänapäevani) valitses tarkvaramaailmas nn. tarkvarakriis (ingl. k software crisis). Seda eelkõige sellepärast, et paljud projektid läksid lõhki nii ajalises kui ka rahalises mõttes. Kui algul valitses kriis vaid produktiivses pooles(pidev aja ja rahapuudus) siis hiljem hakkas kannatama ka kvaliteet. Sellest ajavahest on mitmeid näiteid nii meeletust rahakulutamisest mitte millelegi kui ka olulistest kvaliteedipuudusest, mille tulemusena kannatati olulist materiaalset kahju. Alates 1985st aastast on hakanud asi aina paremaks muutuma. Arenenud on erinevad metoodikad, protsessid ja ka arendajad on muutunud professionaalsemaks. Struktureeritud programmeerimine, objekt-orienteeritud programmeerimine, erinevad töövahendid, dokumentatsioon kõike seda on peetud hõbekuuliks, et päästa tarkvaraarendus kriisist. Arenenud on ka erinevad metoodikad, mille järgi tarkvara arendada: RUP, XP, Scrum, FDD, jpt. Väle (ingl. k. agile) tarkvaraarendus, mille alla kuuluvad ka antud referaadis käsitletavad RUP ja XP, on võtnud eesmärgiks toota tarkvara jagades kogu protsessi tsükliteks, mille käigus valmivad töötavad osad kogutarkvarast. Väledas arenduses peetakse oluliseks pidevat reaalajas suhtlemist eelistades näost-näkku suhtlust. Meekonnad võiks paikneda samas ruumis. Põhimõtteliselt toimub väle arendus samade eesmärkidega, nagu tavaline arenduski, võttes eesmärgiks toota kvaliteetset ja töötava tarkvara. Väleda arenduse põhimõtted on kokku võetud dokumendis nimega The Agile Manifesto, mis võeti vastu 90ndate aastate alguses vastukaaluks raskekaalulistele protsessidele. Tuntuimad nimed selle dokumendi taga on kindlasti Kent Beck, Dave Thomas ja Martin Fowler. Dokumendi endaga on võimalik tutvuda aadressil: http://agilemanifesto.org/ 3
XP XP (extreme Programming) ehk eesti keeles ekstreemprogrammeerimine on üks tuntumaid väleda tarkvaraarenduse metoodikaid. Tegemist on kergekaalulise tarkvaraarendusprotsessiga, mis eelkõige mõeldud väikestele meeskondadele ja projektidele. Tema eeliseks on see, et kuna tegemist on kergekaalulise protsessiga, siis erinevaid muudatusi on küllaltki lihtne kiiresti ja efektiivselt sisse viia. XP neli põhilist muutujat on hind, aeg, kvaliteet ja ulatus. Rahaga on ikka nii, et liiga palju pole hea ja ka liiga vähe on paha. Valida tuleb just selline paras summa, mis motiveeriks ja samas ei tekitaks sellist miljonäri tunnet. Peaaegu sama lugu nagu rahaga, on ka ajaga. Kui aega on rohkem võib suureneda ulatus ja kvaliteet. Mida vähem on aega, seda rohkem kannatab kvaliteet. Kvaliteediga on nii, et sa võid kiiresti teha ebakvaliteetset kaupa, kuid samas kulutades natuke rohkem aega kui ette on antud ja sellega tõsta kvaliteeti, siis minu arvates oleks viimane õigem teguviis. Väiksem ulatus võimaldab kiiremini ja kvaliteetsemalt tarkvara toota. XP neli põhiväärtust on: suhtlemine, lihtsus, tagasiside ja julgus. Suhtlemine on oluline igas elu valdkonnas. Pidev suhtlemine erinevate osapoolte (tellija ja tootja) vahel tagab kvaliteetse toodangu. Sellepärast soovitataksegi kaasata arendusmeeskonda ka klienti esindav liige, kes pidevalt jälgiks arendusprotsessi ja saaks jooksvalt märkida erinevaid vigu, mis tulevikus võiksid segada tootel korrektselt funktsioneerimast. Selline liige meeskonnas tagab ka selle, et toodet arendatakse pidevalt kliendi poolt soovitud suunas. teiseks on suhtlemine oluline ka partnerite vahel(paarisprogrammeerimine), et oleks pidevalt selge, mida tehakse ja miks seda just nii tehakse. Lihtsus peaks seisnema selles, et lahendama peab vaid tegelikke probleeme. Teisalt tähendab see ka seda, et ülesannete lahendamiseks peaks kasutama kõige lihtsamat võimalust. ei ole nutikas ajada asja liiga keeruliseks, sest kunagi ehk hakkab see lihtsalt üle jõu käima. Tagasiside on oluline nii meeskonna sees kui ka kliendiga suheldes. Mida adekvaatsem ja detailsem on tagasiside, seda parem on lõpptoodang. Ole julge, kui on vaja midagi muuta. lihtsam on pärast rääkida, et selline muudatus sai sisse viidud, kui et selleks luba paluda. Eriti kehtib see siis, kui muudatus on pigem äärmuslik ja töötav tulemus pole 100% garanteeritud. XP korral lastakse tarkvara välja pidevalt. Kuni 4 nädalased iteratsioonid tagavad selle, et klient saaks lõpptulemusena täpselt sellise tarkvara, nagu ta alguses tellis. Vahetapid on kasulikud, sest seal on kliendil võimalik tagasisidet anda, et midagi ümber muuta või paremaks teha. Nüüd natuke pikemalt eelpool juba mainitud asjadest. Kui ma esimest korda kuulsin paarisprogrammeerimisest, siis ei tundunud see mulle üldse hea vahendina. Kui aga sellega 4
põhjalikumalt tutvust tegin, siis polnud asi üldse nii hull. Põhimõte on see, et 2 programmeerijat istuvad ühe arvuti taga. Üks neist kirjutab koodi ja teine analüüsib seda pidevalt, et kas midagi saaks paremini teha. Kui esimesel peaks tekkima mõttepaus või ideed otsa saama, siis võtab teine klaviatuuri üle ja hakkab ise koodi kirjutama. Tundub esmapilgul kahtlane, kuid töötab suhteliselt hästi. Testimise puhul on asjad ikka nii, et kui testi tulemus pole 100% siis tuleb tööd teha niikaua, kui test läbitakse täies ulatuses. See kehtib nii iga paari poolt arendatava koodi kohta, kui ka kogu koodi kohta, kuhu just valminud kood on sisse integreeritud. XP puhul on kasulik testimisse kaasata ka klient, kes annaks tagasisidet, et kas programm teeb seda, mida vaja. Üks omapärane asi XP puhul on kollektiivne koodi omamine. See tähendab seda, et koodi kirjutab kogu meeskond ja koodi eest vastutab kogu meeskond. Kellelgi pole suuremat õigust mingi koodiosa üle kui teistel. Selle asja positiivne külg on see, et nii saab iga meeskonna liige ülevaate kogu projektist. Samas, kui keegi peaks kirjutama mingi vigase koodi ja selle integreerima üldisesse projekti, võib kellegi teise kirjutatud kood lakata töötamast. XP pole raske, see on tegelikult väga lihtne. Raske on seda juurutada või üle võtta. Kui otsustatakse, et mingi poolelioleva projekti teostamist jätkatakse kasutades XPd, siis peaks see üleminek olema järkjärguline. Liiga kiire ümberlülitumine võib viia kriisini, millest tulenevalt võib kogu arendatav tarkvara üldse mitte valmis saada. Kuna tegemist on küllaltki uue tehnoloogiaga, siis pole veel võimalik päris kindlalt öelda, millistel juhtudel XPd ei peaks kasutama. Kindlasti ei sobi XP suurtele meeskondadele, sest sellistes meeskondades, pole võimalik kiiresti ümber orienteeruda, kuna kliendi poolt tuli mingi muudatus. Siinkohal tuleb välja ka üks põhilisi nüansse, mis XP raskeks muudab. Millal kasutada XPd? Sellele küsimusele pole ühest vastust. Projekti alguses tuleb lihtsalt hinnata projekti enda suurust, meeskonna suurust ja siis otsustada, kas kasutada XPd või mitte. 5
RUP RUP ehk Rational Unified Process on iteratiivne tarkvaraarenduse protsess, mis loodi Rational Software Corporationi poolt. Erinevate uuringute andmetel kuulub see enimkasutatud väledate metoodikate hulka maailmas. RUPi eesmärk on tagada kvaliteetse tarkvara tootmine. RUP kirjeldab, kuidas arendada tarkvara, kasutades tõestatud tehnikaid. Üldjoontes on RUP mõeldud suurtele tarkvaraarendusmeeskondadele, kes töötavad suurte tarkvaraprojektidega. RUP kasutab ka spetsiaalseid arendusvahendeid (nt Rational Rose) ja modelleerimiseks UMLi (Unified Modeling Language). Kuigi RUP on mõeldud siiski suurematele ja mahukamatele projektidele, on ta siiski üle võetav ka väiksematele projektidele, kuid seda mitte kogu ulatuses, vaid kasutades mingeid kindlaid osi RUPist. Nüüd aga natuke pikemalt ja lähemalt neljast RUPi protsessifaasist. Igas neis neljas faasis on põhiline rõhuasetus erinevatel asjadel. Kui mõnest neist neljast faasist (ingl. k. milestone) jääb läbimata, siis projekt katkestatakse, või alustatakse antud faasi uuesti, et see edukalt läbida ja projektiga edasi minna. ALGATUSFAAS (The Inception Phase) Selles faasis defineeritakse projekti ulatus ja antakse hinnang, kas projekti on mõtet läbi viima hakata või kas see on üldse võimalik. Peamiselt on sisuline osa ärivaldkonda kuuluv, kus määratakse kindlaks äriline kontekst ja edukuse faktorid, nagu näiteks oodatav kasum ja turusuunitlus. Paika pannakse üldine äriplaan, ennustatav riskivõimalus ja projekti kirjeldus. Kui see etapp ebaõnnestub, peaks hoolega mõtlema, et kas projektiga jätkata või mitte. Kui otsustate jätkata, siis tuleks kindlasti likvideerida kohad, kus tekkisid tõrked. DETAILIMISFAAS (The Elaboration Phase) Siin astuvad tõsisemasse tegevusse ka arendajad. Selles faasis hakkab projekt juba oma kuju võtma ja paika pannakse ka algne arhitektuur. Ühe tähtsama tegevusena võib välja tuua erisuste (ingl. k. features) spetsifitseerimise. Valmis peaks olema ka enamus kasutuslugusid. Tähtsamateks alampunktideks on veel arhitektuuri kirjeldamine arendusprotsessi jaoks ja arenduse plaan kogu projekti jaoks. Kui selles faasis tekib mingi tõrge, või seda faasi ei suudeta edukalt läbida, tuleks taas kaaluda, et kas projektiga on mõtet jätkata. Kui soovitakse siiski jätkata, tuleks midagi kuskil taas üle vaadata ja ümber teha. Kui selles faasis jäävad vead sisse, siis hiljem neid kõrvaldada või parandada on juba väga raske KONSTRUEERIMISFAAS (The Construction Phase) Selles faasis läheb peaaegu kogu tähelepanu komponentide ja muude erisuste arendamisele. Siin 6
toimub põhiline koodi kirjutamine. Antud faasi lõpus peaks välja tulema ka esimene töötav programm, mida lõppkasutajad saaksid katsetada. Testimise käigus tehakse kindlaks, kas programm teeb seda, mis sai esimeses faasis paika pandud. SIIRDEFAAS (The Transition Phase) Selles faasis toimub tarkvara täielik üleandmine arendajatelt lõppkasutajatele. Vajadusel koolitatakse välja lõppkasutajad ja lastakse neil veel viimast korda katsetada, et tarkvara vastaks nende ootustele ja nõuetele. Kontrollitakse ka toote kvaliteeti ja kui midagi ei vasta tellija nõuetele, on võimalik teha veel mingeid muutusi, kuid seda ainult väga väikeses osas. 7
KOKKUVÕTE Nii XP kui ka RUPi näol on tegemist küllaltki erinevate väledate protsessidega. XP on eelkõige mõeldud väikestele meeskondadele, RUP pigem suurematele meeskondadele, kuid viimane on kohandatav ka väiksematele arendusmeeskondadele. Kahjuks vastupidi on asi natuke keerulisem ja ilmselt on XPd suurele meeskonnale natuke raske rakendada, kuid teatavaid muudatusi tehes, on see kindlasti võimalik. Kuna arendusprotsessis kasutatakse ka küllaltki erinevaid vahendeid, siis polegi nii kerge öelda, kumb neist parem on. Ilmselt on nad mõlemad väga efektiivsed, kui neid õigesti rakendada. Samas, kui jälgida punktuaalse täpsusega mõlema arendusprotsessi ideaalmudelit, võib öelda, et RUP on efektiivne suurema meeskonna ja tarkvara jaoks, kus paigas kindlad ja stabiilsed(ei muutu kuigi palju) nõuded. XP aga sobib projektile, mida teostab väike meeskond ja mille nõuded tarkvara valmimise käigus muutuvad. 8
KASUTATUD KIRJANDUS Kent Beck Extreme Programming Enplained: embrace change http://en.wikipedia.org/wiki/history_of_software_engineering http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/srinivasan/01-29- 1999.html http://www.adtmag.com/article.asp?id=8982 http://en.wikipedia.org/wiki/rational_unified_process http://www.webopedia.com/term/r/rup.html 9