Tallinn 2013 Autorideklaratsioon Deklareerin, et käesolev ainetöö on minu töö tulemus ja seda ei ole kellegi teise poolt varem üheski aines esitatud. ............................. ………………………….. (kuupäev) (töö esitaja allkiri) 2 Sisukord 1. Iteratsioon I.............................................................................................................................6 1.1 Visioon..............................................................................................................................6 1.2 Planeerimine......................................................................................................................6 1.2.1 Äriteenuse valik (taust).....................................................
2011 2 Autorideklaratsioon Deklareerin, et käesolev ainetöö on minu töö tulemus ja seda ei ole kellegi teise poolt varem üheski aines esitatud. ............................. ................................ (kuupäev) (töö esitaja allkiri) 3 Sisukord 1. Iteratsioon I............................................................................................................................. 6 1.1 Planeerimine......................................................................................................................6 1.1.1 Äriteenuse valik (taust).............................................................................................. 6 1.1.2 Äriteenuse missioon ja eesmärgid...................................................
kohandamist. Arendamine organiseeritakse lühikesteks, fikseeritud pikkusega miniprojektideks (uusarenduse puhul soovitatakse ühe iteratsiooni pikkuseks 2-6 nädalat, pikem oleks halb motivatsiooni aspekti tõttu ja tagasisisde saamine veniks liiga pikaks, tähtaegasid ei nihutata). Pidev kvaliteedikontroll - testitakse varakult, tihti. Rakendatakse use case-e, kasutatakse UMLi Üks projekt = iteratsioon, tulemuseks on testitud, integreeritud ja täidetav süsteem (aga mittetäielik PS tulemus ei ole prototüüp, tulemus on tootmiskvaliteediga alamhulk lõppsüsteemist EHK iteratsiooni tulemus on tükike lõpp-produktist). Tavaliselt iga iteratsioon võtab ette uued nõuded ja laiendab süsteemi, samas saab ka olemasolevat tarkvara täiustada. Iga iteratsioon sisaldab oma nõuete analüüsi, disaini ja testimist. Asi on jagatud 4
Infotehnoologia teaduskond Informaatikainstituut Infosüsteemide õppetool Projekt aines “Kontseptuaalne süsteemianalüüs” Stones Health spordiklubi infosüsteem Julia Visnapu 094244IABB Vassilina Matvejeva 094076IABB Juhendaja: Lea Elmik Tallinn 2012 Sisukord Esimene Iteratsioon 1.1 Taust................................................................................................................................................................3 1.2 Lausendid .......................................................................................................................................................3 1.3 Organisatsiooni eesmärgid .........................................................................................................................
distsipliini (ärimodelleerimine, nõuded). Kui nüüd toome sisse ajatelje ja kolm esimest iteratsiooni (aine praktikatöös rohkem iteratsioone ei jõuta teha, muidu võiks neid rohkem olla), saame aine põhiliste loenguteemade ja praktikatöö ülesannete jaoks raamistiku, mida saab kujutada järgneva tabeliga: M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs, 2014 Aine „raamistik“ tabelina: I iteratsioon II iteratsioon III iteratsioon (Inception) (Elaboration1) (Elaboration2) Planeerimine / Äriteenuse valik plaani/skoobi plaani/skoobi Skoop / (taust); ülevaatamine/täpsust täpsustamine; Kontekst/ amine; Sõnastik Äriteenuse (mission ja) funktsionaalsete eesmärgid nõuete täpsustamine (mõõtmine?);
Joonis 1-4 Prototüübi loomise protsess Prototüüpimise etapid on järgmised: Nõuete kogumine - seda tehakse üldisemal tasemel ja samas ka fikseeritakse, mida on kindlasti vaja edaspidi täpsustama hakata. Kiire kavandamine - keskendub nähtavale osale (sisend, väljund, vormid jms) ja selle tulemuseks on prototüüp. Klient hindab prototüüpi ja oskab selle alusel ka oma soove täpsustada. Järgneb iteratsioon prototüübi parandamiseks, kuni see rahuldab kasutajat. Samal ajal saab arendaja uusi teadmisi kliendi soovide kohta. Prototüübi arendamisel on oluline, et see saaks loodud kiiresti, kasutades selleks abivahendeid (kiire prototüüpimise keeled ja tööriistad). Prototüüp ei pea sisaldama kogu funktsionaalsust - ta peab keskenduma sellele, millest ei ole hästi aru saadud; prototüübis ei pea olema vigade kontrolli ning prototüüp on suunatud funktsionaalsetele nõuetele
Üldised: rõhuasetud varasematel staadiumitel; omaduste varane paikapanek; pendeldada terviku ja osade vahel; pendeldada abstraktsioonide ja konkretiseeringute vahel. Strateegiad ülesande selgitamiseks: formuleerida osaülesanded ja neid samm-sammult kas järjestikku või paralleelselt töödelda; esmalt kõige tähtsam; esmalt kõige prakilisem. Strateegiad lahenduste otsinguks: tuleb lähtuda olemasolevast, tuntust; eelnevalt lõplikuni (iteratsioon); esmalt kõige otsustavam. Strateegiad lahenduse väljavalimiseks: esmalt eelvalik, seejärel lõplik valik; esmalt orienteeruv arvestus, siis täpne arvestus ja simuleerimine; esmalt eelkatsetus, siis lõppkatsetus. 20. Konstrueerimise käik VDI 2221 järgi- skeem, etapid Üldine konstrueerimise käik VDI 2221 järgi on jagatud 7-sse töölõiku, mis kuuluvad 4 faasi: I - ülesande selgitamine, II - põhimõtte väljatöötamine, III -konstruktsiooni väljatöötamine, IV -
Tingimusest R = V saab kuupvõrrandi a1B3 + a2B2 - V1, kus a1 = 0,5Nysy ja a2 = q´Nqsq + c´Ncsc - dkyk . Kuupvõrrandit saab lahendada järk-järgulise lähenemise teel. Selleks võib kasutada võrrandit kujul Bi+1 = V1 / (a1Bi + a2) , kus Bi on mingi alglahend ja Bi+1 iteratsiooniga täpsustatud lahend. Järgmisel iteratsioonisammul võetakse uus Bi võrdseks Bi+1 - ga. Iteratsioon lõpetatakse, kui Bi+1 erineb Bi -st vähe. Iteratsioon koondubsuhteliselt kiiresti ja seetõttu ei ole alglahendi valik eriti oluline iteratsiooniprotsessi pikkusele. Näiteks võiks Bi olla 1 meeter. Dreenimata tingimused. Dreenimata tingimustes on kandevõime R = B2( ( + 2)cusc + q´) ja koormus talla pinnas on V = V1 + B2dkyk . Võrdusest R = V saab avaldada otseselt vajaliku tallalaiuse
ühekohaline esindaja g. T: Kui f, cm,c1m,…,cmm ∈ F, siis kuulub klassi F ka g(n) = f (c1m(n),…,cmm(n)) iga n = cm(x1,...,xm) korral. 21 Rekursiivsete funktsioonide arvutatavus. vt punkt 18 lõpp 22 Ühekohaliste funktsioonide arvutatavus. Gödeli numbrid. Operaatorid ühekohaliste esindajate genereerimiseks: • summa: h = f + g ∀n[ h(n) = f(n)+g(n) ] • kompositsioon: h = f ◦ g ∀n [ h(n) = f(g(n)) ] • pööramine: h = f −1 ∀n[ h(n) = μz [f(z)−n] ] • iteratsioon: h = ιf ∀n[ h(n) = fn(0) ], kus n > 0 DEF: Funktsiooni h teatud formaalses keeles esitatud kirjeldusele vastavusse seatud unikaalset naturaalarvu Gh nimetatakse selle funktsiooni Gödeli numbriks. Teoreem: Kõik ühekohalised lihtrekursiivsed funktsioonid on genereeritavad elementaarfunktsioonidest s(n)=n+1 ja q(n)=n−⌊√n⌋2 („ruutjääk”), kasutades liitmise, kompositsiooni- ja iteratsioonioperaatorit.
võrrandil. Igal sõlmel on oma kauguste tabel (Distance Table). Tabelis on nii palju ridu, kui on võimalikke sihtpunkte antud sõlmest ning tulpasid sama palju, kui naabersõlmi antud sõlmel on (hoitakse kõikvõimalikke kaugusi (ruutimiskulusid) DX(Y,Z) = kaugus X-st Y-sse, kui Z on järgmine samm). Iga iteratsiooni käigus leitakse minimaalne tee ruuterist X ruuterisse Y läbi ruuteri Z (ruuterist Z saabub info ruuterusse X tee Z->Y maksumusest). Iteratsioon toimub uuesti iga kord, kui muutub ruuteriga seotud tee ruutimiskulu või naabersõlm teavitab temaga seotud kulumuutusest. Ruuter teavitab oma naabreid vaid esimesel juhul. Iteratsioon jätkub, kuni ükski võrgusõlm enam infot ei vaheta, iga võrgusõlm suhtleb ainult oma vahetute naabritega. Ruutimistabel saadakse eeltoodud minimeerimise käigus, seal hoitakse infot parima vahendajasõlme kohta ning tee maksumust läbi selle sõlme. 30. Hierarhiline marsruutimine
........................................107 4.1.5 Töötajate funktsionaalne allsüsteem........................................................ 107 4.1.6 Rendi funktsionaalne allsüsteem..............................................................107 4.2 Arendusprotsess ja projektid......................................................................... 107 4.2.1 Projektide arendamise üldine skeem (põhineb RUP-il): ...........................108 1.1.1.158Esimene iteratsioon, käsitleme süsteemi kui tervikut:: ....................108 1.1.1.1Arendamise faas (järgnevad iteratsioonid)..........................................108 1.1.1.2Ehitamise faas.....................................................................................109 1.1.1.3Rakendamise ja siirdamise faas..........................................................109
7. Keel kui matemaatiline objekt. Ehk keel kui stringihulk. Tähestik Kõigi stringide hulk * String: · Tühi string e · kui x on string ja a on sümbol, siis ax on string · ainult nende kahe tingimusega määratud ühendid kuuluvad Stringide konkatenatsioon (ex = xe = x). Keel L on alamhulgaks *. Keelte konkatenatsioon L = L1 ühend L2, kus L on alamhulgaks 1 ühend 2 L = (xy | x kuulub L1 AND y kuulub L2) Keelte iteratsioon: L* = ühend ühest n-ni Lk L0 = e Ln = Ln-1L, (n>0) Homomorfism: 1 ja 2 on tähestikud. Kujutust h: 1* 2* nimetatakse homomorfismiks, kui h(e) = e h(ax) = h(a)h(x) iga a AND x kuulub 1* korral. 8. Fraasistruktuuri grammatikad. Chomsky klassifikatsioon. Grammatika: Formaalne aparatuur keele ja tema fraasistruktuuri esitamiseks. Keel on teatud tähestiku = {a0, .., an} stringide alamhulk. L = {x | x kuulub *, P(x)} alamhulgaks kõigi stringide alamhulgale. Predikaat on semantika aluseks.
Optimiseeri äriväärtust – optimaalse kiirusega saada lõplik toote, optimaalne ärilises mõttes toode osade paigaldamine ajateljel. 5. Optimiseerida protsess – kuidas töö käib. Toode omanik (Scrumi roll) on tellija, mis tahav mingisugust asju saavutada. Product Backlog – toote on jaotatud user storiedeks, epicutekst, featuriteks – igaühel on arendamise prioriteet. Arendus on jaotatud sprinditeks. Sprint ei ole midagu muu kui iteratsioon. Iga sprindi algul on sprindi planeerimise koosolek (Spring Planning Meeting). Tiim saab kokku, arutab sprindi, planeerib selle, jaotab feature või user story taskideks. Sprint Backlog – sprint on jaotatud väikesteks ülesandeteks, mis ei ole ainult progemise ülesanded. Spring kestab 1-4 nädalat. Scrum Master (boss) jälgib protsessi ja iga 24 tundi pärast toimub igapäevane meeting (Daily Scrum
„puhtal“ Kanbanil) o EKSAMIL võib olla küsimus millegi nende võrdlemisega, kui sa suudad oma arvamust põhjendada siis see on ka õige vastus, valesid vastuseid pole sellisel juhul o Kanban paneb piirid WIP töövoo staadiumis, kui aga Scrum piirab WIP-id mis on parasjagu töös ühes iteratsioonis o Scrumi puhul teeme me nn reserdi iga kord kui iteratsioon lõppeb, kuid Kanban-i puhul on töö on pidev ja reserdi ei toimu. o Scrumi puhul on meil tiimid, mille liikmed oskavad igat asja, kuid Kanbani puhul on spetsialiseeritud tiimi liikmed o Scrumi puhul interatsiooni osad peavad mahtuma täpselt interatsiooni, kuid Kanbani puhul võivad olla pikemalt aega nõudvad user storid, või selle kogumid, puudub time boxing
sihtkohta. 32. Distance vector marsruutimisalgoritm Igal sõlmel on oma kauguste tabel (Distance Table). Tabelis on nii palju ridu, kui on võimalikke sihtpunkte antud sõlmest ning tulpasid sama palju, kui naabersõlmi antud sõlmel on (hoitakse kõikvõimalikke kaugusi (ruutimiskulusid) DX(Y,Z) = kaugus X-st Y-sse, kui Z on järgmine samm). Iga iteratsiooni käigus leitakse minimaalne tee ruuterist X ruuterisse Y läbi ruuteri Z (ruuterist Z saabub info ruuterusse X tee Z->Y maksumusest). Iteratsioon toimub uuesti iga kord, kui muutub ruuteriga seotud tee ruutimiskulu või naabersõlm teavitab temaga seotud kulumuutusest. Ruuter teavitab oma naabreid vaid esimesel juhul. Iteratsioon jätkub, kuni ükski võrgusõlm enam infot ei vaheta, iga võrgusõlm suhtleb ainult oma vahetute naabritega. Ruutimistabel saadakse eeltoodud minimeerimise käigus, seal hoitakse infot parima vahendajasõlme kohta ning tee maksumust läbi selle sõlme. 33. Hierarhiline marsruutimine
==> EHK Igal sõlmel on oma kauguste tabel (Distance Table). Tabelis on nii palju ridu, kui on võimalikke sihtpunkte antud sõlmest ning tulpasid sama palju, kui naabersõlmi antud sõlmel on (hoitakse kõikvõimalikke kaugusi (ruutimiskulusid) DX(Y,Z) = kaugus X-st Y-sse, kui Z on järgmine samm). Iga iteratsiooni käigus leitakse minimaalne tee ruuterist X ruuterisse Y läbi ruuteri Z (ruuterist Z saabub info ruuterusse X tee Z->Y maksumusest). Iteratsioon toimub uuesti iga kord, kui muutub ruuteriga seotud tee ruutimiskulu või naabersõlm teavitab temaga seotud kulumuutusest. Ruuter teavitab oma naabreid vaid esimesel juhul.Iteratsioon jätkub, kuni ükski võrgusõlm enam infot ei vaheta, iga võrgusõlm suhtleb ainult oma vahetute naabritega.Ruutimistabel saadakse eeltoodud minimeerimise käigus, seal hoitakse infot parima vahendajasõlme kohta ning tee maksumust läbi selle sõlme. 30. HIERARHILINE MARSRUUTIMINE
samm ==> EHK Igal sõlmel on oma kauguste tabel (Distance Table). Tabelis on nii palju ridu, kui on võimalikke sihtpunkte antud sõlmest ning tulpasid sama palju, kui naabersõlmi antud sõlmel on (hoitakse kõikvõimalikke kaugusi (ruutimiskulusid) DX(Y,Z) = kaugus X-st Y-sse, kui Z on järgmine samm). Iga iteratsiooni käigus leitakse minimaalne tee ruuterist X ruuterisse Y läbi ruuteri Z (ruuterist Z saabub info ruuterusse X tee Z->Y maksumusest). Iteratsioon toimub uuesti iga kord, kui muutub ruuteriga seotud tee ruutimiskulu või naabersõlm teavitab temaga seotud kulumuutusest. Ruuter teavitab oma naabreid vaid esimesel juhul.Iteratsioon jätkub, kuni ükski võrgusõlm enam infot ei vaheta, iga võrgusõlm suhtleb ainult oma vahetute naabritega.Ruutimistabel saadakse eeltoodud minimeerimise käigus, seal hoitakse infot parima vahendajasõlme kohta ning tee maksumust läbi selle sõlme. 30. HIERARHILINE MARSRUUTIMINE
○ Members should be fulltime ■ May be exceptions (e.g., database administrator) ○ Teams are selforganizing ■ Ideally, no titles but rarely a possibility ○ Membership should change only between sprints Scrumi raamistik: Sprint on iteratsioon. Iga sprindi alguses on planeerimine, kus jaotatakse user story’d taskideks. Sellest tekib backlog. Edasi tuleb taskid 14 nädalaga realiseerida. Asja jälgib boss ehk ScrumMaster. Iga 24h järel on standup igapäevased koosolekud, kus küsitakse: Mida tegid eile? Mida teed täna? Ega probleeme ei ole? Burndown näitab, kui efektiivselt taske realiseerime. Iga sprindi lõpus on Sprint Review ja Retrospective.
29. Distance vector marsruutimisalgoritm Kuldse kasukaga Pugile pühendatud küsimus Bellman-Fordi võrrand (dünaamiline programmeerimine): Aeg-ajalt saadab iga sõlm oma kaugusvektori (distance vector) hinnangu (estimate) oma naabritele. Ehk - kaugus u-z leidmiseks leia u kaugus kõigist tema naabersõlmedest, leia naabersõlmede kaugus sihtpunktist (kõige optimaalsem), liida vastavad väärtused ja leia neist kõige väiksem. Distantsvektori algoritm: Iteratiivne, kus iga kohalik (local) iteratsioon toimub, kui: ● Kohaliku lingi maksumus muutub ● Naabrilt sõnum DV uuendamiseks Distributeeritud: ● Iga sõlm teavitab naabreid ainult siis, kui nende DV muutub (naabrid siis teavitavad oma naabreid, kui vaja (ehk kui nende tabel veelkord optimeerub)). Iga sõlm ootab naabersõlmelt sõnumit, arvutab oma tabeli ning kui midagi on muutunud, teavitab naabreid. Marsruutimistabel
annaabi.ee 
