Süsteemianalüüs - Esimese loengutöö konspekt (0)

Kui Arno süsteemianalüüsi jõudis, oli…
Töö juba alanud do not fuck up eks? 1. Miks analüüsi üldse vaja? Mis on süsteemianalüüs?
Valdkonna paremaks mõistmiseks, ühise arusaama nimel, konkurentsis püsimine jne. Seos
modega - asju on lihtsam analüüsida kui nad on keskkonnas asuvad elemendid, mis
omavad kindlat käitumist ja struktuuri. Parem küsimus on, kas neid slaide oli üldse vaja?
Süsteemianalüüs on (mudelipõhine) struktuurne arutelu asjaosaliste vahel (tellijad,
arendajad, sponsorid etc.) süsteemist (toode, teenus, protsess) ühise arusaamise
kujundamise eesmärgil.
2. Analüüsi osad ja liigid
Valdkonna (äri)analüüs
● Organisatsiooni (kes?)
● Eesmärkide (miks?)
● Protsesside (kuidas? millal?)
● Objektide/ressursside (mis?) - analüüs
Tarkvara nõuete analüüs
● Usecase/Usestory analüüs
● Kasutajaliidese
● Andmete
● Sündmuste/operatsioonide
3. Analüüs arendustöös
Ainult üks väike osa, vastab küsimusele mida on vaja teha või muuta (disain vastab
küsimusele kuidas). Sitt analüüs = tehakse valesid asju/valesti asju.
Süsteemianalüüs on osa süsteemitööst, mis tegeleb valdkonna uurimise ja kirjeldamisega,
püstitab infrastruktuuri ja nõuded - selle alusel loob disain lahendused. Tl;dr õpid füüreriks.
4. Arendusmetoodikad - Produkti vs protsessi vaade
Süsteemitöös järgitakse metoodikat, mis annab karkassi/arhitektuuri, et kirjeldada töötulemit
ja protsesse (produktiraamistik & protsessiraamistik).
Zachman on ainult produktiraamistik - mida valmistada?
Zachmani laiendada sobiva protsessiraamistikuga (mida see isegi tähendab?) - kuidas
valmistada?
Protsessiraamistik on agiilse arhitektuuri osa.
5. Protsessiraamistik
● Klassikaline - e kose mudel (seda tegime modelleerimises) Uuri valdkonda
(ärianalüüs) - püstita nõuded tarkvarale (süsteemianalüüs) - modelleeri lahendus
(disain) - genereeri tarkvara (teostamine). Analüüs toimub esimeses kahes (? correct
me if I’m wrong) staadiumis. Siin tehakse igas arendusetapis ühte liiki tegevust e
kogu analüüs tehakse ära esimeses etapis (sobib väikeste süsteemide jaoks). Kui on
mingi eriti giga projekt, siis terviksüsteem tükeldatakse allsüsteemideks ja neid
analüüsitakse eraldi. Pärast analüüsi hakatakse disainima, allsüsteemid pannakse
ühtse tervikuna kokku. Rakendatavus - hullult aeglane, etapid on järjest ja
ajamahukad. Ei sobi uue toote disainimiseks eriti kui kiirus loeb, sobib keskkonda,
kus sul on maa ja ilm aega.
● Iteratiivne - evulutsioonilisel arendustsükli mudelil põhinev. Süsteemi
laiendatakse ja parendatakse mitme iteratsiooni käigus, võimaldab tagasisidet ja
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
faasi mis koosnevad omakorda iteratsioonidest.
Kose mudeli faasid = iteratiivse protsessi distsipliinid (sarnaseid arendustegevusi
ühendav valdkond). Faasid ja distsipliinid on ristuvad read-veerud, sest igas faasis
tehaks korraga mitme distsipliinide tegevusi.
Klassikalises mõistes analüüs on kaks ülemist rida
Kolmas rida (analüüs & disain) on puhas disain
Paindlik - nõuete valmimine ei pane neid nö lukku, kui vaja siis muudetakse.
Muudatusi
On hea teha ja kohanemine on lebo, sest iteratsioonid on lühikesed, iga samm
tegeleb ainult väikese hulga nõuetega, tagasiside pidev. PS. Pole kontrollimatu kus
reageeritakse kõigile tellija tahtmistele. Nö kuldne kesktee, et mõistuse piirides on
nõuded paindlikud.
● Agiilne - üldiste põhimõtete alusels, käigu pealt loodav
6. UP faasid/etapid
● Alustamine/Inception/Algfaas - loob esialgse visiooni, business case (kas
tasub investeerida järgmisesse faasi?), skoop, hinnangud
● Täpsustamine/Elaboration/Detailimine - loob reaalse töötava arhitektuuri,
realiseerib väikese hulga tähtsamaid põhifunktsionaalsus, enamike nõuete ja skoobi
määramine, riskide lahendamine, realistlikumad hinnangud
● Konstrueerimine - teeb kõik muud funktsionaalsused, madalama riski ja
kergemate elementide iteratiivne realiseerimine
● Üleviimine - Paneb tellija keskkonnas tööle e beeta testid
Süsteemianalüüsi seos nendega -
Analüüsiga saab pm tegeleda igas faasis ja iteratsioonis. Esimestes
etappides/iteratsioonides on analüüsi osakaal suurem.
Ma ei tea kuhu seda paigutada, aga - Süsteemianalüüs = Zachmani esimesed 2 kihti, kose
mudeli II etapp, UP arendamise 2 ülemist distsipliini (ärimodemine + nõuded)
7. Transaktsiooni muster - tellija-täitja suhe (kas neil on teema? Haha vv-d???)
-Soovi avaldus(? request) - Üks osapooltest soovib äriteenust teiselt poolelt
-Lubadus - Teine pool nö lubab osutada teenust ja tulemusena ka teeb seda
-Olek (? state) - Teine pool edastab, et jah, ta reaalselt sai hakkama endaga
-Aktsepteerimine - Soovi avaldaja nö võtab omaks et äriteenus viidi läbi
???? Ma ei oska tõlkida.
8. Iteratiivne arendus: Ehitamine - Tagasisisde - Kohanemine
Töö toimub läbi eelnevalt mainitud tsüklite seeria. Varasemates iteratsioonides on “õigest
teest” kõrvalekalle suurem, aja jooksul loksub kõik enam-vähem paika. Hilisemates
iteratsioonides ei tehta enamasti olulisi muutusi (va juhul kui see annaks nt hea
konkurentsieelise.
9. Iteratiivse arenduse plussid
● Riskide varajane lappimine
● Varane nähtav edasiminek
● Saadakse kohe tagasisidet, kasutaja kaasahaaramine, kohandamine -
tulemuseks täpsem süsteem, mis vastab tellija vajadustele
● Hallatud keerukus - meeskond ei raiska tohutult aega analüüsile/pikkadele
arendussammudele
● Iteratsioonide käigus saab arendada arendusmetoodikat ennast, et edasised
iteratsioonid oleks sujuvamad
10. Kuidas erineb kose mudelist?
Kose mudelis alguses defineeritakse kõik nõuded ja alles siis tehakse disain jne. Inception
on pigem teostuvuse analüüs kui nõuete oma, tehakse lühike aga piisav uuring, et mõista
kas on üldse mõtet edasi minna. Detailimine pole nõuete ega disaini faas vaid pigem
realiseerimise faas, kus kõrvaldatakse riske
11. UP distsipliinid ja analüüsidistsipliinid
Distsiblinn - arendustegevuste/ülesannete ja nendega seotud asjade hulk ühes valdkonnas
(Lol, dafuk does this even mean? Roost mix?)
Artifact - üldmõiste, tähistab igasugust tööprodukti: kood, graafika, dokument, diagramm etc.
● Ärimodelleerimine - Kui arendatakse üksikrakendust siis sisaldab valdkonna
klassidiagrammi.
Ulatuslikus ärianalüüsis sisaldab äriprotsesside dünaamika modelleerimist üle terve
ettevõtte.
● Nõuded - nõuete-vajaduste analüüs rakenduse jaoks, use-case’ide
kirjutamine ning mittefunktsionaalsete nõuete identifitseerimine
● Disain - kõik mis sellega kaasneb e arhitektuur, objektid, kasutajaliides,
andmebaas, võrgud
● Realiseerimine - programmeerimine, ehitamine aga mitte rakendamine
● 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
kasule orienteeritud, sõltuvalt projekti tüübist ja arendusjuhtumist (konkreetne objekt või
ülesanne).
Development Case
UP artifactide valik projekti jaoks kirjutatakse dokumenti Development Case - Sarnaneb UP
põhiraamistiku tabeliga, veerud on iga iteratsiooni kohta, lahtritesse kirj artifaktide nimetused
mida konkreetse iteratsiooni vastavas distsipliinis toodetakse. Iga iteratsiooni järel
kirjutatakse tabel üle vastavalt sellele mis tegelikult tehti ja kui plaanid muutusid.
13. Agiilne UP
Protsessid on kahes jaotuses, mis on omakorda kaheks. Rasked vs kerged protsessid ja
ettekirjutavad vs kohanevad protsessid
Rasked - palju artifacte, rangud ja kontroll, viimistletud pikk detailplaneerimine, pigem
ettekirjutav kui kohanev
Ettekirjutav protsess - üritab planeerida ning ette kirjutada tegevusi ning inimressursside
omistamist detailselt suurema osa projekti kohta. Kasutab tavaliselt kose mudeli elutsüklit
(not iteratiivne) - defineeritakse kõik nõuded, siis detailne disain ja alles seejärel
realiseeritakse.
Kohanev protsess, agiilne - käsitleb muutust kui vältimatut paratamatust, millega on tarvus
kohaneda, tavaliselt kasutatakse iteratiivset elutsüklit, reageerib muutuvatele nõuetele.
UP pole selle autorite poolt mõeldud raske ega ettekirjutavana kuigi lai mittekohustuslike
tegevuste ja artifactide hulk võib tekitada sellise mulje. Mõeldud rakendamiseks agiilse
protsessi vaimus
Põhimõtted
● Eelista väikest hulka UP tegevusi ning artifacte. Ära aja asja liiga keeruliseks
● Kuna UP on iteratiivne, siis nõuded ja disain on lahtised kuni realiseerimiseni
ehk need kasvavad ja kohanevad läbi iteratsioonide ja pole kivisse raiutud.
● Pole olemas detailset plaani kogu projekti jaoks
● On kõrgtaseme plaan suurte verstapostide hindamiseks, kuid see ei täpsusta
väiksemaid verstaposte
● Detailiplaan (iteratsiooniplaan) tehakse adaptiivselt igas iteratsioonis ning
vaid ühe iteratsiooni jaoks ette.
● VS Kose mudel - kose mudelis defineerid täieliku hulga nõudeid, külmutad
need, disainid süsteemi nõuete alusel ja külmutad selle ja seejärel realiseerid disaini
alusel
14. Sa ei ole UPst aru saanud kui… (ehk nimistu Tl;dr UP kohta)
● Inception =/= nõuete analüüs, elaboration=/= disain, construction =/=
realiseerimine ehk ära rakenda kose elutsüklit UP-le
● Elaborationi eesmärk ei ole täielikult ja detailselt defineerida mudeleid, mis
teisendatakse koodiks konstrueerimise faasis
● Enamike nõudeid ei defineerita enne disaini või realiseerimise alustamist,
neid täiendatakse iga iteratsiooni käigus
● Ei defineerita enamiku disaini enne realiseerimise alustamist
● Ei defineerita täielikult ja lõplikult arhitektuuri enne iteratiivset
programmeerimist ja testimist
● Enne progemise alustamist ei kulutata palju aega nõuete või disaini tööle
● Iteratsioonid on lühikesed, ca 3 nädala kaupa pigem
● UML diagrammide koostamise ajal ei defineerita täielikult ja detailselt disaini
ja mudeleid. Porgrammeerimine ei ole nende mehaaniline teisendamine koodiks.
● EELMISELE ERAND - Model Driven Architecture põhinevad UP versioonid,
kus UMLi kasutatakse programmeerimiskeelena, mitte ainult disainikeelena
● UP =/= palju võimalikke tegevusi ja hästi palju dokumente
● Ei ole formaalne protsess, mis sunnib järgima paljusid samme
● Ära planeeri detailselt kogu projekti algusest lõpuni, eeldades et suudad ette
näha kõiki iteratsioone ja mis neis toimub
● Sa ei saa esitada plaane ja hinnanguid projektidele enne kui detailimise faas
on lõpetatud
Väärtusmudel - see, kus on osapooled ja nooled nende vahel kes mida saab sellest
teenusest nt klient ja müüja vahetavad kaupa ja raha
Transaktsioonid - UC diagramm kus on need samad osapooled...okei ma väga ei taju seda
oot. Aaa okei. Slaidide näide - konverentsi külastaja ja korraldaja on osapooled, UC on
‘konverentsi külastamine (täisteenus), registreerumine,tellimine,maksmine ja
artikli/ettekande saatmine. Nooltel on soovib, teeb, võimaldab
Kontekstidiagramm - Slaidinäide - samad osapooled, UC konverentsi külastamise täisteenus
ja sellega ühendatud klassid, kus on kvaliteedieesmärgid mis on seotud selle UC’ga
Kvaliteedieesmärgid - Klassidiagramm kus on hunnik väärtuseid/omadussõnu
Funktsionaalsed eesmärgid - UC diagramm mille keskmes on see põhiline usecase ja on
toodud include/extend seostega mini-UC’d
Visuaalne sõnastik - Klassidiagramm millel on põhimõisted seostega.
Põhiprotsessi lihtsustatud töövoog - action diagramm, see kus on need swimline’id mis
näitavad kuidas üks transaktsioon peaks toimuma erinevate osapooltega.Tegevusdiagramm
on vist see nimi :D
THE END, sa oled väga tubli, loodan, et omandasid ka midagi