Arhitektuurse disaini dokument kirjeldab süsteemi ülesehitust, süsteemi komponente ning mooduleid, liideseid komponentide vahel ja liideseid teiste süsteemidega. Kirjeldatakse ka füüsiline arhitektuur - riistvara ja näidatakse, milline tarkvara komponent millisele riistvarale paigutatakse. Arhitektuurse disaini dokument peaks katma järgmised teemad: · sissejuhatus: dokumendi eesmärk, viited teistele dokumentidele, dokumendi struktuuri kirjeldus; · arendusvahendite valiku ja häälestuse, arenduskeskkond; · kodeerimise, sh kommenteerimise ja nimetamise standardid; · liidesed teiste süsteemidega, andmevahetusformaadid ja meetodid; · toote sisemise struktuuri, ülesehituse: süsteemi jaotuse komponentideks, komponentide kohustused ja rollid, komponentide andmevahetus; · arhitektuuriotsuste tausta, alternatiivid, valikukriteeriumid; · jõudlusnõuded
● Testimine - vahetulemuste hindamine võttes aluseks nõuded - kas vastab või ei. ● Rakendamine - vahetulemuste rakendamine tellija keskkonnas UP toetavad distsipliinid ● Muudatuste ja konfiguratsiooni haldamine - muudatusnõuete hindamine ja töössevõtmine ● Projektijuhtimine - keskendutakse tähtaegadele, ressursile, kvaliteedikontroll ● Keskkond - arendusvahendite ja protsessi keskkonna seadistamine projekti jaoks Suhteline jõupingutus - distsipliinides muutub jõupingutus ajas (nt analüüsi tehakse esimestes iteratsioonides hästi palju, hilisemates mitte eriti, vaata seda värvilist diagrammi mida ta loengus näitas koguaeg) 12. Sari lühemaid slaide Protsessi häälestamine ja arendusjuhtum. Kõik UP tegevused on mittekohustuslikud (va kood). Pm tegele väheste asjadega, aga
Arhitektuurse disaini dokument kirjeldab süsteemi ülesehitust, süsteemi komponente ning mooduleid, liideseid komponentide vahel ja liideseid teiste süsteemidega. Kirjeldatakse ka füüsiline arhitektuur - riistvara ja näidatakse, milline tarkvara komponent millisele riistvarale paigutatakse. Arhitektuurse disaini dokument peaks katma järgmised teemad: sissejuhatus: dokumendi eesmärk, viited teistele dokumentidele, dokumendi struktuuri kirjeldus; arendusvahendite valiku ja häälestuse, arenduskeskkond; kodeerimise, sh kommenteerimise ja nimetamise standardid; liidesed teiste süsteemidega, andmevahetusformaadid ja meetodid; 19 toote sisemise struktuuri, ülesehituse: süsteemi jaotuse komponentideks, komponentide kohustused ja rollid, komponentide andmevahetus; arhitektuuriotsuste tausta, alternatiivid, valikukriteeriumid; jõudlusnõuded
tehnoloogiaid. Käesolev töö on jaotatud kaheks: analüüsi ja realisatsiooni osaks. Esimeses osas analüüsitakse olemasolevaid tantsutrupi info jagamise lahendusi ning määratletakse rakenduse loomiseks vajalikud arendusvahendid kasutades neid tehnoloogiaid, mida õpetatakse Pärnu Saksa Tehnoloogiakoolis. Realisatsiooni peatükis realiseeritakse idamaise tantsutrupi Hessa veebirakendus ning kirjeldatakse arendusvahendite kasutamist ja nende eripärasid. Lõputöö lisades on toodud olemasolevate lahenduste ekraanipildid, andmebaasi tabelid, printimise väljatrüki näide. 7 1. Analüüs Käesolevas peatükis tuuakse välja töös käsitletava probleemi olemus, antakse ülevaade idamaisest tantsutrupist Hessa, sõnastatakse nõuded realiseeritavale
rakenduse jaoks: use case-ide kirjutamine ning mittefunktsionaalsete nõuete identifitseerimine.. Disain – kõik disaini aspektid: arhitektuur, objektid, kasutajaliidesed, andmebaasid, võrgud jne.. Realiseerimine (implementation) – süsteemi programmeerimine ja ehitamine, mitte rakendamine Testimine – Rakendamine (deployment) – Muudatuste ja konfiguratsiooni haldamine – Projektijuhtimine - Keskkond (environment) – arendusvahendite (tööriistad) ja protsessi keskkonna seadistamine projekti jaoks Joonis (UP põhiraamistik, vaata eestpoolt) Suhteline jõupingutus distsipliinides muutub ajas ning on eri faasides erinev. M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs, 2014 Protsessi häälestamine ja arendusjuhtum Kõik UP tegevused ja artifactid (v.a. kood?) on mittekohustuslikud. Võrdlus apteegitäie ravimite ning konkreetse haigusega.
annaabi.ee 
