Rational Unified Process RUP on tarkvara arendusprotsess Software

Rational Unified Process RUP on tarkvara arendusprotsess (Software Engineering Process). Ehk tegevuste kirjeldused, mis kindlustavad kvaliteetse tarkvaralahenduse tootmise nii, et see vastaks lõppkasutaja vajadustele ja oleks realiseeritav määratud eelarvega ja ennustatava ajakava On konfigureeritav – sobib nii väikestele arendusmeeskondadele kui suurtele tarkvara loomise struktuuridele. Kuid mitte 1: 1 -le. RUP on raamistik koos lihtsate ja selgete kirjeldustega arendusprotsesside selle osa läbiviimiseks, mis on ühine kõigile arendusprojektidele. RUP 1

Head programmeerimise tavad (tehnikad) • Nõudmiste põhjalik analüüs – lõppeesmärk peab olema selge ja jälgitav terve arendusprotsessi käigus • Arhitektuuri-kesksed – süsteem jagatud alamosadeks, mis suhtlevad üksteisega ainult läbi kokkulepitud liideste • Komponentide kasutamine – on võimalik taaskasutus • Visuaalsete mudelite kasutamine – mõtle ja kommunkeeru UML-is • Iteratiivne arendusprotsess • Riskide juhtimine – identifitseerida, vähenda nendest tulenevaid ohtusid enne, kui need realiseeruvad RUP 2

Arendustsüklid ja faasid peamised verstapostid Lähteuuring Kavandamine Valmistamine Evitus aeg Programmi elutsükkel koosneb paljudest tsüklitest. Üks tsükkel on ühe konkreetse programmiversiooni valmistamine. RUP jagab ühe arendustsükli neljaks faasiks: • Lähteuuring (Inception) • Kavandamine (Elaboration) • Valmistamine (Construction) • Evitus (Transition) Iga faas lõppeb verstapostiga (milestone) – Konkreetne ajahetk, mil on vaja langetada strateegiliselt tähtsaid otsuseid edaspidise tegevuse kohta. RUP 3

Arendusprotsessi kaks dimensiooni Arendusprotsessi kirjeldatakse kahe dimensiooni abil: • Horisontaaltelg näitab projekti dünaamilist arengut ajas. Areng väljendub arendustsüklites, -faasides ja verstapostides • Verikaaltelg näitab protsessi struktuuri ehk organisatoorset korraldatust. Seda kirjeldavad toimingud (activities), artefaktid (artifacts), töörollid (workers), töövood (workflows) RUP 4

Lähteuuring (Inception) Tarkvara arendustsükli esimene faas, mille käigus pannakse paika arenduse lähteideed ning täpsustatakse neid tasemeni, mis võimaldab alustada kavandifaasi. Lähteuuringu tulemuseks on: • Visioon – dokument mis annab üldise vaate loodavale süsteemile esitatavatest nõuetest, põhiomadustest ja peamistest piiravatest teguritest • Esmane kasutuslugude mudel – sellel näidatud vähemalt kõik aktorid, kes on süsteemiga seotud, nende põhilisi vajadusi kirjeldavad kasutuslood (umbes 10 -20% valmis) • Projekti sõnastik • Esmane äriplaan – loodava süsteemi seosed ettevõtte üldiste äriliste eesmärkidega. Edu kriteeriumid (loodetav kasum, turuosa kasv, jne), finantsprognoos • Esmane riskide analüüs • Projektiplaani mustand – Arengufaaside ja iteratsioonide ajakava • Prototüüp(d) RUP 5

Lähteuuringu verstapost Verstapost: On selgunud arendustsükli eesmärk Tulemuse hindamise kriteeriumid: • Tööde tellija hinnang püstitatud ülesande definitsioonile ja maksumuse/ajakava prognoosidele • Kas on õigesti aru saadud tellija vajadustest. See peab olema kirjeldatud kasutuslugudes • Hinnang kulude/aja prognoosile, prioriteetidele, riskide, arendusprotsessi kirjeldusele • Kas kulutused arendustsüklis tehtud töödele vastasid planeeritud kuludele Projekt tuleb katkestada või re-organiseerida, kui hinnang tehtud tööle ei ole kirjeldatud kriteeriumite alusel positiivne RUP 6

Kavandamine (Elaboration) Eesmärk on analüüsida valdkonda (problem domain), luua/kehtestada programmi arhitektuuri põhijooned. Luua projektiplaan, ellimineerida projekti ohustavad põhiriskid Kavandamise tulemus: • Kasutuslugude mudel – kõik aktorid ja kasutuslood on määratud. Vähemalt 80% nendest on kirjeldatud • Muud nõuded - süsteemi funktsionaalsusega mitte seotud nõudmised • Süsteemiarhitektuuri kirjeldus • Töötav prototüüp, mis demonstreerib arhitektuuri • Täiendatud riskifaktorite loetelu ja äriplaan • Projekti arendusplaan • Arendusplaan – arendusportsessi kirjeldus • Kasutajajuhendi mustand RUP 7

Kavandamise faasi verstapost Verstapost: Elutsükli arhitektuur (Lifecycle Architecture) • Kas visioon loodavast süsteemist on stabiilne? • Kas arhitektuur on kandev? • Kas prototüübi demonstratsioon näitab, et kõigi kriitiliste riskifaktoritega on arvestatud • Kas süsteemi konstrueerimise plaan on piisavalt detailne ja täpne? • Kas kõik osapooled (tellijad ja täitjad) on ühisel arvamusel, et visioonis kirjeldatud eesmärgid on saavutatavad, kui esitatud plaan süsteemi loomiseks ellu viiakse? • Kas tehtud kulutused on vastavuses planeeritutega Projekt tuleb katkestada või re-organiseerida, kui hinnang tehtud tööle ei ole kirjeldatud kriteeriumite alusel positiivne RUP 8

Konstrueerimise faas (Construction) Eesmärk on konstrueerida/luua kõik komponendid ja süsteemi funktsionaalsed omadused. Kõigi funktsionaalsete omaduste põhjalik testimine. Konstrueerimise tulemus (minimaalselt): • Tarkvaraprodukt, mis toimib määratud platvormidel • Kasutajajuhendid • Programmi kirjeldus Verstapost: Reaalselt töötav produkt (Initial Operational Capability) • Kas valminud produkt on piisavalt valmis ja stabiilne, et viia see lõppkasutajateni? • Kas kõik osapooled on valmis/nõus programmi viimiseks lõppkasutajateni? • Kas tehtud kulutused (võrreldes planeertitutega) on aktsepteeritavad? Kui töö ei vasta esitatud kriteeriumitele, siis võib üleminekut järgmisesse faasi edasi lükata tsükli(te) võrra RUP 9

Evitus (Transition) Eesmärk on tarkvaraprodukti üleandmine lõppkasutajatele Evituseni jõutakse, kui loosava produkti põhiomadused on piisavalt valmis, et neid lõppkasutajateni viia. Selleni jõudmiseks võivad osutuda vajalikuks järgnevad tegevused: • “beetatestimine” – kas süsteem rahuldab kasutajate vajadusi • paralleelne kasutamine vana, asendatava süsteemiga • andmete konversioon uude süsteemi • kasutajate ja hooldajate koolitamine • toote pakendamine, tutvustamine reklaami, jaotus ja müügiosakondadele Evituse tulemus : • Kasutajad on võimelised loodud produkti iseseisvalt kasutama • Kõik osapooled nõustuvad, et lõppkasutajateni on jõudnud produkt, mis vastab visioonis kirjeldatud nõudmistele Verstapost: Produkti valmimine (Product Release) • Kas kasutajad on rahul? • Kas tegelikud kulutused vastasid planeeritutele? RUP 10

Protsessi staatiline struktuur Tööroll – “kes” , Toiming – “kuidas”, Artefakt – “mis”, Töövoog – “millal” Tööroll (Worker) – Osa, mida konkreetne inimene(d) täidab projektimeeskonnas. Defineerib inimese toimingud ja vastutusalad. Üks inimene võib esineda mitmes erinevas osas. Vastutust võib määrata nii teatud toimingute hulga täitmise eest, kui ka määratud artefaktide valmimise eest Toiming (Activity) – konkreetne tööoperatsioon, mida mingit töörolli täitev inimenesooritab. Sellel on selge eesmärk. Tavaliselt väljendatakse seda mingi artefakti loomise või täiendamisena. Toimingu töömaht võib olla mõnest tunnist paari päevani. Seda sooritab tavaliselt üks inimene ja see mõjutab ühte või mõnda artefakti. RUP 11

Protsessi staatiline struktuur Artefakt (artifact) – Informatsioonikild, mis tekib, muudetakse või on kasutusel mingi protsessi käigus. Asjad, mis tekivad või on kasutusel lõpliku produkti loomisel. Artefaktid on näiteks: mudelid (Kasutuslugude mudel, disaini mudel), mudeli elemendid (klass, kasutuslugu, alamsüsteem), dokumendid, lähtekood, töötav programmi moodulid Töövoog (Workflow) – toimingute jada, mille käigus tekib vaadeldav tulemus Seda võib kujutada järgenvus-, Koostöö- või tegevusskeemina Ei ole alati võimalik ega praktiline kujutada kõiki toimingute vahelisi seoseid. Eriti kui need käivad ühe töörolli või isiku kohta, kes täidab erinevaid rolle RUP 12

Töövood Põhilised töövood • Äri- ehk tegevusvajaduste modelleerimine • Nõuete analüüs • Analüüs ja Disain • Teostus • Testimine • Levitus Toetavad töövood • Konfiguratsiooni- ja muutuste haldamine • Projektijuhtimine • Arenduskeskonna haldamine RUP 13

Kasutuslood arendusfaasides RUP 14