o Esitlema mingit osa valmiskoodist kliendile iga teatud tsükli järel(paar nädalat kuni paar kuud) o Äriinimesed ja tarkvaraarendajad peavad töötama koos projektis o Tähtsustama motiveeritud individuaalseid ideid o Inkrementaalne vs iteratiivne o Arendada süsteemi korduvate tsüklite läbi - Iteratiivne o Arendada väiksemate tsüklite kaupa inkrementaalne · Extreeme Programming(XP) o On agiilne arendusmeetod o Mõeldud tõstma tarkvara kvaliteeti ja võimalusi vastuvõtmaks kliendi poolt esitatud uusi nõudmisi o Paaris programmeerimine/code review(software + person)/unit testing(moodul + funktsioon) o On-site customer o Refactoring - kood puhtamaks köögipoolt, nii et väljast ei oleks muutusi(readability, maintainability etc.) · Paaris programmeerimine o Driver + observer
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
23. Projekt on ühekordne, täpselt määratletud eesmärgiga ajutine ülesanne, mis tuleb lahendada tähtaegselt ja kvaliteetselt, kasutades selleks etteantud ressursse 24. Projekti juhtimine on üks osa ettevõtte juhtimissüsteemist. Iga projekt on üks unikaalne, terviklik lahendus, mis omab kindlaksmääratud algus- ja lõpukuupäeva ning mille tulemuseks on eelnevalt fikseeritud tehnilistele tingimustele vastav toode v. teenus. 25. Agiilne projekteerimine (projektijuhtimine) on lähenemisviis: Tulenevalt klientide vajaduste kiirest muutustest, kasvavast konkurentsist ning ressursside ratsionaalse kasutamise nõudest, peab projektijuhtimise protsess olema agiilne (väle, paindlik) so suutma reageerida pidevatele protsessi muutustele nii ajas kui ruumis. 26. Teostuspõhimõtted: · Indiviidid ja suhtlus eelistatuna protsessidele ja metoodikatele
Spetsifitseerimine- mida süsteem peab tegema ja mis on piirangud tema arendamisel? Arendamine-tarkvarasüsteemi tootmine Valideerimine- kas toodetud tarkvarasüsteem on see, mida kasutaja soovis? (üks meetod selleks on testimine) Evolutsioon- tarkvarasüsteemi muutmine vastavalt kasutajate muutuvatele nõudmistele Plaanipõhine vs agiilne tarkvaraprotsess o Plaanipõhine tarkvaraprotsess: kõik tegevused on ette planeeritud ja edu kriteeriumiks on plaani järgmine o Agiilne tarkvaraprotsess: planeerimine toimub sammude kaupa töö käigus o Kumb on parem? Mõlemad on ok, see sõltub kus seda kasutatakse. Tarkvaraprotsessi mudelite põhitüübid o Kosk Selle mudel:
Tehnoloogia kui vahendaja (broneerimissüsteemid) Tarneahelas kõige rohkem teenib esmane või teisene klient, kõige vähem viimane varustaja. Igaüks tarneahelas tahab saada oma kasumit. Palju oleneb ka sellest, kes määrab lõpphinna. Tarneahela strateegiad Lean strateegia – suunatud kuluefektiivsusele. Nõudlus on stabiilne ja ennustatav. Toodangu sortiment ei ole väga lai ning on stabiilne. Agiilne strateegia – suunatud uuendusreageerimisele, paindlik. Lühikesed tarneajad, lai toodangu sortiment. Leagile – lean ja agiilne – strateegia, mis on ettevõtte sisend ehk protsesside tarneahelate strateegia. Protsessi esimene pool on protsessipõhine strateegia; pole palju tooteid, toodetakse optimaalselt partii alusel, kuid jälgitakse varude puudust. Teine pool on agiilne, kus toimub nõudluse põhine tootmine vastavalt tellimustele. Sellise protsessi jaoks on oluline tootearendus.
Puudused: • Saab kasutada ainult siis, kui nõuded on fikseeritud; • Iga tarkvaraprotsessi etapp peab olema lõpetatud enne kui alustatakse järgmist etappi. Eelised: • Plaanipärane arendus aitab koordineerida arendustööd suurte süsteemide loomisel, kui süsteemi arendatakse erinevates kohtades. Modifitseeritud kose mudel: igast etappist saab minna ühele eelmistest etappidest ja sealt juba alla poole liikuda. Agiilne tarkvaraprotsess: planeerimine toimub sammude kaupa töö käigus. Iteratiivse mudeli kohaselt koosneb kogu protsess mitmest järjestikusest tsüklist (iteratsioonist), mis kõik sisaldavad • analüüsi, • disaini, • programmeerimist, • testimist kuid erinevates tsüklites on rõhk erinevatel sammudel. Eelised: • Klient saab anda tagasisidet kogu tarkvaraprotsessi jooksul;
Nt BPM. ○ Andmekeskne (datacentric) vaatepunkt: andmevood. Nt andmevoogude diagrammid. ○ Rollikeskne (rolecentric või agentcentric) vaatepunkt: kes mida teeb? ○ Tulemikeskne (productcentric) vaatepunkt: mis on iga tegevuse tulem? Ja kuidas see on sisendiks järgmisele tegevusele? 18. Plaanipõhine vs agiilne tarkvaraprotsess. On olemas kahte liiki tarkvaraprotsesse: ● Plaanipõhine tarkvaraprotsess: kõik tegevused on ette planeeritud ja edu kriteeriumiks on plaani järgmine ● Agiilne tarkvaraprotsess: planeerimine toimub sammude kaupa töö käigus Ei saa öelda, et kumb on õigem. Oleneb sellest, mida luuakse ja konkreetsest rakendusest.
Protsessimudelite kirjeldustes räägitakse tavaliselt tegevustest nagu andmemudeli kavandamine, kasutajaliidese disain jne, kuid nad võivad sisaldada ka dokumentatsiooni ja rollide kirjeldusi. Protsessimudelites võib kohata kahte põhimõttelist lähenemist. Tugev planeerimine. See vanem lähenemine seisneb tegevuste ja tarkvara põhjalikus planeerimises ja järgnevas kindlalt plaani järgivas arenduses. Arendustegevuse progressi mõõdetakse sama plaani abil. Agiilne ehk paindlik arendus, kus planeerimine toimub osade kaupa (inkrementaalselt) ning tänu millele on võimalik protsessi käiku muuta, tulles vastu kasutajate muutuvatele nõuetele. Paindliku protsessi kasutuselevõtt tulenes klientide vajaduste kiirest muutumisest. Protsess peab olema paindlik ja suutma reageerida toote muutmise, täiendamise ja kohandamise soovidele. Kui vahepeal toimus süsteemi üldiste arendusmudelite jaotamine rangelt ühte või teise
(Eksamiküs) spetsifitseerimine – mida süsteem peab tegema ja mis on piirangud arendamine – tarkvarasüsteemi tootmine valideerimine – kas toodetud süsteem on see, mida klient soovis? evolutsioon – tarkvarasüsteemi muutmine vastavalt kasutajate muutuvatele nõudmistele Tarkvaraprotsesside liigid: plaanipõhine – kõik tegevused on planeeritud ja edu tagab kriteeriumide järgminie agiilne – planeerimine toimub sammude kaupa töö käigus Kose (waterfall) mudel: requirements -> design -> implementation -> verification -> maintanance. Tuleneb ehitusest. Kose mudeli puudused: nõuded fikseeritud iga protsess peab olema lõpetatud enne kui teine algab protsess algab algpunktist, kus arendaja ja klient ei saa üksteisest tegelikult aru Kose mudeli eelised: parem koordineerida The Manifesto for Agile Software Development
Korda samme kõikide süsteemi osade kohta ADD KASU: Nõuete vahelised kompromissid tulevad varajases staadiumis välja, mis aitab luua luua parima arhitektuuri nõuete katmiseks. Arhitektuuri testimine Küsi endalt: Millistele eeldustele tugineb arhitektuur ? Milliseid nõudeid arhitektuur katab ? Mis on selle arhitektuuri võtme riskid ? Milliste meetmetega leevendada riske ? Mil moel on see arhitektuur edasiminek viimase kandidaadi/baas arhitektuuri suhtes ? Agiilne praktika Arhitektidel on alandlikkust tunnistada et nad ei oska vee peal käia. Arhitektid osalevad aktiivselt arendustegevuses. Nad on meeskonna konsultandid. Arhitektidel on alandlikkust tunnistada, et nad ei oska tulevikku ennustada. Küll aga on nad enesekindlad selles, et homseid probleeme saab lahendada homme. Arhitektuur tekib iteratiivselt koos arendusega. Dokumenteeri nii palju kui on vaja kommunikatsiooniks.
laiendada sobiva protsessiraamistikuga (kuidas tulemeid valmistada?). M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs, 2014 Protsessiraamistikku peetakse agiilse (valdkonna või ettevõtte) arhitektuuriraamistiku osaks. Protsessiraamistik võib olla: Klassikaline (Kose mudelil põhinev); Iteratiivne (evolutsioonilisel/spiraalsel arendustsükli mudelil põhinev); Agiilne (üldiste põhimõtete ja protsessimustrite alusel „käigu pealt“ loodav/muudetav, mitte eelnevalt valmis tehtud). Järgnevalt uurime süsteemianalüüsi kohta: 1) klassikalises Kose mudeli raamistikus; 2) iteratiivses arendusprotsessi UP raamistikus. . M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs, 2014 M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs, 2014
Iteratiivne ja inkrementaalne lähenemine Teostatakse korduvalt nö mini-Kose metoodikat. Kõiki Kose metoodika etappe viiakse läbi väikese osa peal terviksüsteemist kuni terviksüsteemi valmissaamiseni või eelnevalt pannakse paika kõik süsteemile esitatavad nõuded, mille järel teostatakse kasvatavalt ülejäänud mini-Kose metoodikat või eelnevalt teostatakse süsteemi nõuete analüüsi ja arhitektuuri disaini ning prototüüpimist, mis lõpeb töötava süsteemiga. Agiilne lähenemine · madal kriitilisus · vanad arendajad · nõuded muutuvad väga sageli · arendajate hulk väike · kaosega toimetulev kultuur IS-i arendamise juhtimine organisatsioonis (tegevused, tulemused) Infosüsteemi arendamise juhtimine organisatsioonis on tegevustik organisatsiooni infotöökorralduse muutmise reglementeeritud (paikapandud töökorraldusega) läbiviimiseks. Kasutades süsteemimudeli analoogi paikneb
annaabi.ee 
