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
Need aga ilmnevad alles projekti lõpus, millal on nendele reageerimine tihti võimatu, ehk liialt kallis (reegel 1:100). Üldiselt aga kasutatakse just koskmudelit väiksemate infosüsteemi arenduste puhul (koos projektimudeliga). Joonis 22 Koskmudel 45. Selgita Infosüsteemide projekteerimise spiraalmudelit (ka MSF näide), lisa joonis Spiraalmudeli puhul teostatakse mingi kokkulepitud (ka projekti jooksul tunnetatud vajadusest lähtudes) hulk iteratsioone, ehk läbitakse teadlikult etappe mitu korda. Seda tehakse, et tagada tulemuse vajadustele vastavus (muudatuste juhtimine). Joonis 23 Spiraalmudel. Allikas: Spiral Model (Boehm, 1988) Original Creator: Conrad Nutschan MSF Näide Microsofti poolt pakutav (MSF Microsoft Solutions Framework) ,,kesktee" ehk proovitud võtta parim mõlemast mudelist: MSF toob välja, et on vaja: · liikuda pidevalt visiooni suunas, · ole paindlik asjad muutuvad,
2014 Aine „Süsteemianalüüs“ raamistik Käesolev aine katab: a Zachmani raamistiku 2 ülemist kihti (skoop/sõnastik ja ärimudel); b „Kose mudeli“ arendusetappidest teise (analüüs ehk detailanalüüs) etapi; c RUP/UP iteratiivse arendamise raamistikus 2 ülemist 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)
esitatavate tingimuste osas jne. · disain visioon programmist · kodeerimine - progejad teevad ära · integreerimine ja testimine nö paikaseadmine, töölerakendamine, testimine. Joonis: 45. Selgita infosüsteemide projekteerimise spiraalmudelit, lisa joonis Teostatakse kokkulepitud hulk iteratsioone, ehk läbitakse teadlikult etappe mitu korda, et tagada tulemuse vajadustele vastavus (muudatuste juhtimine). Eesmärkide seadmine: alguses üldisemad, järjest detailsemaks muutuvad. Hea pool ei jää pikka aega tellijal oodata ta on pidevalt kaasatud, aktiivse tagasisidestaja rollis. Puudused: · kõvasti kallim, kuna tellija peab oma kaasatusega panustama palju aega (ja aeg on raha!).
Küsimus 1 Tegevuse "Projekti algatamine ja planeerimine" eesmärk on Vali üks või enam: a. Koostada ettevõte strateegiline plaan b. Identifitseerida kasutajad c. Koostada töökirjelduse dokument (Statement of Work) d. Koguda nõuded e. Koostada projekti alusplaan (Baseline Plan) Küsimus 1 Iteratiivne arenduse protsess, kui esimeste iteratsiooni valikul peamiseks argumendiks on arendaja riskide vähendamine – on risk-driven approach, Traditsiooniline arendusprotsess, kus ei ole iteratsioone ja seega pole vaja otsustada, mis on esimene, nimetakse – kosemudeliks, Iteratiivne arenduse protsess, kui esimeste iteratsiooni valikul peamiseks argumendiks on kliendi riskide vähendamine – on client-driven approach Küsimus 2 Lähenemine, mis keskendub andmete liikumisele ja teisendamisele erinevate süsteemikomponentide poolt – nimetakse protsessile orienteeritud lähenemiseks, Lähenemine, mis keskendub ideaalse andmemudeli loomisel – nimetakse andmetele
ÕIS-i puhul, võttes õppejõu siis tema peab sisestama mingi hinde õpilasele. Kasutajalood jagatakse omakorda taskideks, et asja veidi detailsemaks teha ja korrektsemaks, ehk tehnilised ülesanded. Kasutajalood täidavad kasutaja nõudeid Taskid täidavad aga süsteemi nõudeid o Kasutajajuhud (user cases) Kirjeldab süsteemi kasutaja iteratsioone süsteemiga. On kaks notatsiooni: Graafiline Tabeli kujuline Hea näide kasutajajuhtude kohta on meditsiiniline tarkvarasüsteem, kus patsient saab panna arsti juurde aega, arst saab patsiendi kohta andmeid jne. o Need on erinevad asjad! Nende erinevused on näiteks: Kasutusjuhud on keerulisemad ja tänu sellele võimalik kasutada laialdasematel aladel
· Igal tsüklil prototüübid viiakse testimismeeskonnale · Testimise käigus katsetatakse süsteemi töökiirust ning töökindlust reaalsele lähedastes olukordades. Kui analüüs ja disain on jõudnud heale tasemele (projektijuhi hinnang), hinnanguliselt viimasel kahel iteratsioonil vaadatakse süsteemi juba ühtse tervikuna. Liidestused viiakse lõpuni. Siin tulevad kindlasti väja mõningad uued nõudmised, uue analüüsi vajadus. Iteratsioone plaanis 3 4. Igale iteratsioonile ca 2, max 3 nädalat. Etapile kokku mitte üle 2.5 kuu. Nõudmiste kogumine peab iteratsioonide lõpuks olema lõppenud / lõpetatud see on arendamise lõppemise tingimuseks. Nõudmiste analüüs, infosüsteemi disain peab olema suures osas lõppenud. Lubatud on minimaalsed kõrvalekalded. 1.1.1.3 Rakendamise ja siirdamise faas · Projekti hakatakse komponentide kaupa üle viima tellija keskkonda.