märksõnade hulka? a. korduvus Küsimus 2 Millega seoses kerkib üles projekti plaanimise seostamine äriprotsesside juhtimisega? b. tootmismahtude suurenemisel Küsimus 3 Kas toote tehnoloogilisuse tagamise oskus kuulub? mõlema eelmise ja ka projektijuhi kompetentside hulka Küsimus 4 Mis ei sobi tootearendusprojekti teostusega seotud tegevuste loetellu? a. kontrolli- ja testimise tehnoloogia Küsimus 5 Milline põhimõte ei kuulu agiilse projektiteostuse juurde? b. kaasaegsetele metoodikatele orienteeritus Küsimus 6 Mis ei kuulu riskide ja kitsaskohtade dialektikasse? b. valmistustehnoloogiate mittetundmine Küsimus 7 Mis ei ole oluline tootearendusprotsessi jätkusuutlikkuse seisukohalt? b. ettevõtte kasuminäitajad Küsimus 8 Mis ei kuulu projekti seire juurde? b. töö tulemuste arutelu Küsimus 9 Milline tegevus tootearendusprotsessile esitatavates nõuetes ei sobi loetelusse? c
järgmised: * Inception (algfaas, visioon) * Elaboration (täpsustamine/viimistlemine, arhitektuur) * Construction (konstrueerimine, valmistegemine) * Transition (Siire, üleviimine, rakendamine) Millistes eelnimetatud faasides ei tohiks põhimõtteliselt tegelda enam kontseptuaalse süsteemianalüüsiga, vaid ainult disaini, realiseerimise ja rakendamisega (vastamisel lähtuge aine konspektis ja C. Larmani raamatus olevast UP tõlgendusest iteratiivse ja agiilse protsessina)? Valige (ainus) õige vastus järgnevate vastusevariantide hulgast: Täpsustamise (Elaboration), Konstrueerimise ja Siirde faasis ei tohi põhimõtteliselt enam tegeleda kontseptuaalse süsteemianalüüsiga, see peab juba varem tehtud olema. Siirde faasis ei tohi põhimõtteliselt enam tegelda kontseptuaalse süsteemianalüüsiga, see peab juba varem tehtud olema. Konstrueerimise ja Siirde faasis ei tohi põhimõtteliselt enam tegelda kontseptuaalse
järgmised: * Inception (algfaas, visioon) * Elaboration (täpsustamine/viimistlemine, arhitektuur) * Construction (konstrueerimine, valmistegemine) * Transition (Siire, üleviimine, rakendamine) Millistes eelnimetatud faasides ei tohiks põhimõtteliselt tegelda enam kontseptuaalse süsteemianalüüsiga, vaid ainult disaini, realiseerimise ja rakendamisega (vastamisel lähtuge aine konspektis ja C. Larmani raamatus olevast UP tõlgendusest iteratiivse ja agiilse protsessina)? Valige (ainus) õige vastus järgnevate vastusevariantide hulgast: Täpsustamise (Elaboration), Konstrueerimise ja Siirde faasis ei tohi põhimõtteliselt enam tegeleda kontseptuaalse süsteemianalüüsiga, see peab juba varem tehtud olema. Siirde faasis ei tohi põhimõtteliselt enam tegelda kontseptuaalse süsteemianalüüsiga, see peab juba varem tehtud olema. Konstrueerimise ja Siirde faasis ei tohi põhimõtteliselt enam tegelda kontseptuaalse
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)
erinevate kasutajate/süsteemide. Kasutuslugu piirdub pigem ühe kasutaja ja funktsiooniga. Nõuete spetsifikatsiooni dokument – dokument, kust saab järele vaadata, mida süsteem tegema peaks, mitte seda, kuidas Nõuete valideerimise tehnikad: manuaalne ülevaatamine prototüüpimine testid LOENG 3 - Raino Kolk Coding pattern – kokkulepe või traditsioon kuidas probleeme koodis lahendada Agiilse meetodi eelised: Erosioon – kui lepitakse kokku mingis tarkvara disainis, aga seda muudetakse. Näiteks kui mingid andmed peavad läbima teenuse, aga progeja hardcode’ib ja teenust ei kasutata. (eksam) Serveriteenused: klient->server Komponentidel põhinev arhitektuur, eelised: taaskasutatav asendatav laiendatav kapseldatud sõltumatus Kihiline arhitektuur: (eksam) abstraktne kapseldatud selgelt defineeritud kihid
Analüüsida süsteemi nagu praegu on, panna mõisteid kirja ja siis juba nõudeid. Nõuete analüüs on eesmärgid, võimalused ja piirangud mida me esitame oma tarkvara intensiivsele süsteemile. Eesmärk on teada saada, millist süsteemi tahame – selle võimalused, funktsioonid ta täidab, kuidas ta neid täidab. As-is süsteem -> To- be süsteem. Nõuete vahel tuleb teha kompromissi, mis ongi üks põhjustest miks nõuete analüüs on nii oluline. Nõuded on vaja kirjeldada ka agiilse arenduse käigus. Head nõuded on eelduseks edukale projektile. WHY – tuleb küsida miks klient tahab midagi teha, mida ta tahab saavutada, mida tahab parandada (eesmärgid). Eesmärk muutub nõudeks. WHAT – mida süsteem peab konkreetselt tegema (funktsionaalsed teenused). WHO – kes vastutab, kelle huvisid täidab see süsteem (vastutajate kohustused). WHY – eesmärgid. WHAT – funktsionaalsed teenused. WHO – kohustuste jagamine vastutajate vahel.
* Inception (algfaas, visioon) * Elaboration (täpsustamine/viimistlemine, arhitektuur) * Construction (konstrueerimine, valmistegemine) * Transition (Siire, üleviimine, rakendamine) Millistes eelnimetatud faasides ei tohiks põhimõtteliselt tegelda enam kontseptuaalse süsteemianalüüsiga, vaid ainult disaini, realiseerimise ja rakendamisega (vastamisel lähtuge aine konspektis ja C. Larmani raamatus olevast UP tõlgendusest iteratiivse ja agiilse protsessina)? Valige (ainus) õige vastus järgnevate vastusevariantide hulgast: Täpsustamise (Elaboration), Konstrueerimise ja Siirde faasis ei tohi põhimõtteliselt enam tegeleda kontseptuaalse süsteemianalüüsiga, see peab juba varem tehtud olema. Siirde faasis ei tohi põhimõtteliselt enam tegelda kontseptuaalse süsteemianalüüsiga, see peab juba varem tehtud olema.
tarkvaraarendusele suunatud distsipliin, mis tegeleb sellega, kuidas organiseerida tarkvaraarendust o Tarkvaraprotsess koosneb tegevustest, mis on vajalikud tarkvaratoodete arendamiseks. Nende tegevuste organiseerimisega tegelebki tarkvaratehnika. o Agiilne tarkvaratehnika on kindlate põhimõtete järgi organiseeritud iteratiivne tarkvara arendusprotsess Eksamil võib olla küsimus: mis on agiilse ja iteratiivse tarkvaraarenduse vahe? Agiilne tarkvaratehnika paneb piirid iteratsiivsele tarkvaratehnikale. Küsimus on selles, kuidas on iteratiivne tarkvaratehnika täpselt organiseeritud. o Tarkvaratooted koosnevad väljatöötatud programmidest ja nende dokumentatsioonist o Tarkvaratehnika eesmärgiks on kuluefektiivne tarkvaraarendus kogu
Vali üks või enam: a. tootearendaja kompetentside hulka b. projekteerija kompetentside hulka c. mõlema eelmise ja ka projektijuhi kompetentside hulka Mis ei sobi tootearendusprojekti teostusega seotud tegevuste loetellu? Vali üks või enam: a. kontrolli ja testimise tehnoloogia b. toote tehnoloogilisuse kontroll c. allhankevajaduste selgitamine d. rakiste vajaduse määratlemine Milline põhimõte ei kuulu agiilse projektiteostuse juurde? Vali üks või enam: a. paralleelne teostus b. kaasaegsetele metoodikatele orienteeritus c. pidev suhtlus kliendiga d. töötavad lahendused Mis ei kuulu toodete klassifitseerimisel eesmärkide hulka? Vali üks või enam: a. toote põhiomaduste ja iseärasuste äratundmine b. toote võrdlusparameetrite määratlemine c. toodete grupeerimine valmistamisel d. toodete konkurentsivõime hindamine
saavutatakse märkimisväärne sisemine kokkuhoid. ABC on universaalne meetod ja edukalt rakendatav igas eluvaldkonnas. Suurimad komistuskivid on juurutamises liiga suure detailsuse valimine või kõikehõlmava mõõtesüsteemi ehitamine (suurendab administratiivset koormust, kuid ei lisa oluliselt andmetele). Seega soovitatakse meetodit rakendada samm- sammult, liikudes suuremalt üldistuselt väiksemale Protsessipõhine lähenemine Paindliku (agiilse) tootmise / juhtimise olemus ja seos lean (timmitud) printsiipidega Paindlik tootmine / juhtimine (Agile Production / Management) * ... lähtub turust eeldab kiiret reageerimist muutustele ja kolme peamist valikut: et lisaks paindlikkusele oleks ka konkurentsieelis. Esmalt keskendumine tootele või protsessi võimekusele: tootele keskendumine: vastupidavus, keeruline tootmine ja kriitiline väärtus kliendile (mida teised ei suuda pakkuda see võib olla ettevõtte maine, toote
● Arhitektuur ei ole mitte midagi erilist ● Karda kivisse raiutud arhitektuuri ● Igal süsteemil on arhitektuur ● Arhitektuur skaleerub ● Arhitektuur evoleerub arhitektuuri muudetakse teadlikult. Vastupidiselt erosioonile, kus arhitektuuri lõhutakse. Kes vastutab arhitektuuri eest agiilse arhitektuuri puhul? Kõik on vastutavad. Ei ole üks arhitekt, kes vastutab, vaid kogu tiim vastutab. Probleem: ● vahel inimesed ei ole üksteisega nõus ● suurtes tiimides skaleeruvus Sellisel juhul valitakse arhitektuurile üks omanik/vastutaja, kes aitab alumistel tiimidel jõuda ühistele arusaamisel. Kui laat läheb väga suureks, siis keegi, kes tõuseb püsti
süsteemi struktuuri. Selle vältimiseks ja tarkvara kvaliteedi parandamiseks on vaja kulutada lisaks aega ja raha refaktoreerimisele. Halb struktuur muudab tarkvara hilisema muutmise keerulisemaks ja kulukamaks. 11 4. Agiilsed arendusmeetodid Agiilsete arendusmeetodite jaoks sobib kasutada inkrementaaset mudelit. Agiilse tarkvaraarenduse levimise algus läheb 2001 aastasse, kui senise üliplaanipärase arenduse vastased kirjutasid alla "The Agile Manifesto"-le, mille kõige olulisemates punktides rõhutakse inimesele ja inimeste vahelisele suhtlemisele: Inimesed ja suhtlemine on tähtsamad kui protsessid ja tööriistad. Töötav tarkvara on tähtsam kui dokumentatsioon. Koostöö kliendiga on tähtsam kui läbirääkimised lepingu üle.
Spiraalmudel- protsessi kulgemist kujutab spiraal. Iga keerd on tarkvara protsessi faas. XP- tarkvaraarenduse metoodika, mis on mõeldud tarkvara kvaliteedi parandamiseks ja suurem paindlikkus muutuvate nõuete tingimustes. Tee selgeks, mida pead tegema Kirjuta unit test Pane unit test tööle Kui esineb probleem, siis paranda see Scrum- iteratiivne ja kasvava populaarsusega agiilse tarkvara arendamise raamistik. Koosneb sprintidest, mis jäävad nädala kuni ühe kuu vahele. Iga sprindi päeval toimub lühikoosolek, kus arutatakse seniseid saavutusi ning eesmärke. Testipõhine arendus- luuakse testid enne realiseerimist kliendi kasutuslugude põhjal (ühikstestid, vastuvõtutestid). 15. Millal pole mõtet rääkida tarkvara elutsüklist? Siis kui tarkvara enam ei arendata. 16. Milline elutsükli mudel on parim?
produktiraamistik ja protsessiraamistik). Zachmani arhitektuuriraamistik on ainult produktiraamistik süsteemitöö tulemite kirjeldamiseks (mida valmistada?). Metoodikana rakendamiseks on Zachmani raamistikku kasulik 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:
Süsteemi illustratsioon, mis aitab aru saada süsteemi käitumisest (Software Engineering Institute http://www.sei.cmu.edu/). Süsteemi arhitektuur on struktuuride kogum, mis aitavad mõista süsteemi, hõlmates tarkvara elemente, seoseid nende vahel ja elementide ning seoste omadusi (wikipedia). Arhitektuur on vundament millele tarkvara ehitatakse. Arhitektuuri mudel defineerib vundamendi visiooni (agile modeling). 25) Mis on agiilse arhitektuuri loomise omadused? 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.
annaabi.ee 
