Kui Arno süsteemianalüüsi jõudis, oli… Töö juba alanud do not fuck up eks? <3<3<3 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
1. Milline alljärgnevatest väidetest on õige? +mõlemad on võrdselt tähtsad Kasutusjuhtude mudeli koostamisel on teksti kirjutamine tähtsam diagrammide joonistamisest Kasutusjuhtude mudeli koostamisel on diagrammide joonistamine tähtsam kui teksti kirjutamine 2. Kas äriprotsess on samal ajal ka tarkvara kasutusjuhtum (use case)? Joonige alla õige vastus. Võib olla küll, kuid kindlate tingimuste täidetuse korral Ei, kindlasti mitte Jah, kindlasti on 3. Millist loetletud diagrammitehnikatest ei kasutata põhimõtteliselt Eriksson-Penkeri ärimodelleerimise notatsioonis? klassidiagramm + ärikasutusjuhtude diagramm olekudiagramm tegevusdiagramm 4. Milliseid kasutusjuhtude mudelis identifitseeritud tegutsejaid (actors) ei ole vaja kasutusjuhtude diagrammis näidata? Valige pakutud vastusevariantide hulgast parim (s.t. täpne) vastus: toetavad tegutsejad vaadeldava süsteemi suhtes huvisid omavad tegutsejad +kõr
Õiged vastused märgitud punasega!!! 1. Milline alljärgnevatest väidetest on õige? mõlemad on võrdselt tähtsad Kasutusjuhtude mudeli koostamisel on teksti kirjutamine tähtsam diagrammide joonistamisest Kasutusjuhtude mudeli koostamisel on diagrammide joonistamine tähtsam kui teksti kirjutamine 2. Milliseid kasutusjuhtude mudelis identifitseeritud tegutsejaid (actors) ei ole vaja kasutusjuhtude diagrammis näidata? Valige pakutud vastusevariantide hulgast parim (s.t. täpne) vastus: toetavad tegutsejad vaadeldava süsteemi suhtes huvisid omavad tegutsejad kõrvalseisvad (offstage) tegutsejad arvutisüsteemid inimtegutsejad primaarsed tegutsejad 3. Isikute haldamine on tavaline nn. CRUD (create, read, update, delete) tüüpi protsess , mis hõlmab arvutisüsteemi abil uu
Eesti Rahvusraamatukogu digitaalarhiiv DIGAR Eesti Rahvusraamatukogu digitaalarhiiv DIGAR Ain Tulvi LOGISTIKA Õpik kutsekoolidele Tallinn 2013 Eesti Rahvusraamatukogu digitaalarhiiv DIGAR Käesolev õppematerjal on valminud „Riikliku struktuurivahendite kasutamise strateegia 2007- 2013” ja sellest tuleneva rakenduskava „Inimressursi arendamine” alusel prioriteetse suuna „Elukestev õpe” meetme „Kutseõppe sisuline kaasajastamine ning kvaliteedi kindlustamine” programmi „Kutsehariduse sisuline arendamine 2008-2013” raames.
Near far wherever UML are 1. Tarkvara Nõuete analüüs Äri(...tegelt ka või see on kuradi esimene vastus??)modelleerimise (distsiblinni) tulemused annavad konteksti ning “keele” (põhimõistestiku) tarkvara nõuete püstitamiseks. Iteratiivses arendusprotsessis UP toimub tarkvara nõuete püstitamine ja analüüs põhiliselt tarkvara kasutusjuhtude kirjutmise, modelleerimise ja analüüsimise kaudu. 2. Kasutusjuhtude mudel ehk (kui te olete inglise keeles väga sitt juhuslikult) Use Case Model UP defineerib Use Case mudeli nõuete analüüsi distsiblinni sees. Use Case mudel on kõikide kasutusjuhtude hulk: süsteemi funktsionaalsuse(kasutusjuhud) ja keskkonna(tegutsejad) mudel Eesmärgid ja kasutuslood Tellijad ja lõppkasutajad omavad eesmärke (goals, UP-s needs, sest UP on needy motherfucker) ning soovivad, et süsteem aitaks neid täita. Kasutusjuhud on jutustused süsteemi kasutamisest nende eesmärkide täitmiseks. Näide: Ülikooli
Ema, anna padruneid ma hakkan UML-i uurima 1. Ärimudeli mõiste Omab erialakirjanduses kahte tähendust - mudel selle kohta, kuidas äriüksus teenib raha (loob väärtust) VÕI äriüksuse toimimise kirjeldus. Süsteemianalüüsi lähenemine - ei vastanda ärimudeli tähendusi, sest ärimudel on ka ärisüsteemi arhitektuuri kirjeldus. Ühte ja sama äriarhitektuuri saab kirjeldada erinevas vaates erinevatele huvigruppidele nt äripoole jaoks on tähtsam mudel see, kuidas raha teenida VS IT department, keda huvitab rohkem kuidas ettevõte toimib, et neile tarkvaralahendusi luua. Kõlab nagu kodusõda. EHK, parafraseerime eelmist teksti ilusamale kujule, sest äkki ei jõudnud kohale. Äriinimeste jaoks - ärimudel on kirjeldus, mis näitab kuidas ettevõte loob kasu ja tulu, kirjeldab ettevõtte turusegmenti, positsiooni turul, konkurentsivõimet, rentaablust, kliendile loodavat väärtust etc. IT inimeste jaoks - on ärimudel ettevõtte toimimise kirjeldu
Objektorienteeritud modelleerimine. Objektmudel: Klassid, Objektid ja nende seosed Esmärk: Ülevaade objektmodelleerimise põhimõistetest Klassidiagrammides kasutatavate põhikonstruktsioonide tutvustamine Sisu Objektid ja klassid Klassidiagramm Kuidas leida klasse ? Atribuudid Operatsioonid Seosed Piirangud Mudeli kvaliteet Objektorienteeritud modelleerimises on põhilisteks elementideks klassid, objektid ning nendevahelised seosed . Kui modelleerimise eesmärgiks on tarkvarasüsteemide ehitamine, minnakse objektorienteeritud mudelitelt sujuvalt üle objektorienteeritud programmeerimise mõistetele / konstruktsioonidele, kus klassid ja seosed on teisendatud tegelikuks programmikoodiks. Objektid ja klassid Objekt on element, nähtus, asi, millest me räägime ja/või millega tegutseme. Objekt eksisteerib reaalses maailmas, täpsemalt, meie ettekujutuses sellest maailmast. Modelleeritavat osa maailmast nimetatakse tavalisel
organisatsiooni toimimise muutmise juhtimine · infotehnoloogia juht (Chief Technology Officer (CTO) või IT Manager) - IT strateegia väljatöötamine · IT projektijuht - IS/IT-alaste muudatuse teostuse juhtimine Süsteemina käsitlemine Süsteemina käsitlemine (Systems Thinking) Probleemi analüüsimeetod või lähenemisviis, mis aitab inimesel näha laiemata, terviklikumat pilti sellest, kuidas asjad on omavahel seotud. Teiste sõnadega, süsteemina võtmine ehk süsteemianalüüs tegeleb süsteemist arusaamisega põhinedes tõekspidamisel, et lahendatavat probleemi võetakse süsteemi (või terviku) osana. Probleemist on võimalik paremini aru saada kui uurida selle seoseid süsteemi moodustavate teiste osade või teiste süsteemidega. Süsteemina mõtlemine üritab näidata, et: · keerulistes süsteemides üks väike sündmus võib põhjustada suuri muutusi · süsteemi ühe osa paremaks tegemine võib ebasoodsalt mõjutada süsteemi teisi osi
Kõik kommentaarid