Plaanid puhkusele minna? Võta endale majutus AirBnb kaudu ja saad 37€ kontoraha Tee konto Sulge
Facebook Like


Süsteemianalüüsi kontrolltöö 1 (0)

1 HALB
Punktid

Esitatud küsimused

  • Mis? d d Kes ?
  • Kuidas? Kus ?
  • Millal? Miks ?
  • MIKS ON VAJA ÄRIMUDELIT ?
  • Kus ta osaleb või mida ta kontrollib ?
  • Mida ta omab või haldab ?
  • Missugused on labori eesmärgid ?
  • Missugused on labori võtmekontseptid ?
  • Mida kasutavad või loovad protsessid ?
  • Kes kontrollib protsesse ?
  • Kuidas on ressursid omavahel seotud ?
  • Kuidas labor on ülesehitatud ?
  • Kuidas muutub ressurss aja jooksul ?
  • Kuidas toimivad omavahel ressurssid ?
  • Missugused on labori eesmärgid ?
  • Missugused on labori eesmärgid ?
  • Kuidas labor on ülesehitatud ?
  • Kus asuvad labori struktuurüksused ?
 
Säutsu twitteris
M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs , 2014
IDU 5360 SÜSTEEMIANALÜÜS
Loeng 1. Sissejuhatus (kontseptuaalsesse) süsteemianalüüsi.
  • Aine fookus
  • Aine taust
  • Eesmärgid ja õpiväljundid
  • Aine korraldus
Aine fookus
KONTSEPTUAALNE SÜSTEEMIANALÜÜS
Fookus: Kontseptuaalse süsteemanalüüsi meetodite rakendamine valdkonna ning tarkvara nõuete detailseks analüüsiks iteratiivses arendusprotsessis
Aine taust
Analüüsi ained:
  • Sissejuhatus infosüsteemidesse (IDU 3350) või Modelleerimine (IDU 3355); ->
  • -> Süsteemianalüüs (IDU 5360) ->
  • -> Infosüsteemi strateegiline analüüs (idu0021) ehk Ettevõtte äriarhitektuur ( idu1321 )
    Aine on eelduseks (OIS)
    IDU5661 - Infosüsteemide projekteerimine ,
    IDU0050 - Objektorienteeritud disain ,
    IDX5010 - Struktuuranalüüs ja ekspertsüsteemide tehnoloogia
    ANALÜÜS JA MODELLEERIMINE
    Analüüs on eesmärgipärase inimtegevuse (n. igapäevase probleemide lahendamise) loomulik osa.
    Konkurentsis püsimiseks peame (mina ise, minu esindatav üksus, organisatsioon , riik, …) oma “asja” (toodet, teenust, põhitegevust) tegema teistest paremini.
    Selleks peame me alustuseks “asjadest” hästi (“asjaosalistega ühte moodi ja konkurentidest paremini) “aru saama”.
    Aru saamiseks peame neid “asju” uurima , analüüsima .
    Uuritavat “asja” on kasulik käsitleda (modelleerida) süsteemina (mis asub keskkonnas, koosneb omavahel seotud elementidest, omab struktuuri ja käitumist).
    Süsteemi analüüs (kui tegevus) on (mudelipõhine) struktuurne arutelu asjaosaliste (süsteemiga seotud erinevad osapooled- huvigrupid ) vahel süsteemist (tootest, teenusest, protsessist,..) ühise arusaamise kujundamise eesmärgil.
    Struktuurseks aruteluks vajame me mudeleid .

    Modelleerimisest üldiselt

    Keerukaid nähtusi ja süsteeme (n. ettevõte ja tema infosüsteem) saame käsitleda (mõista, luua, muuta, juhtida,) mudelite kaudu.

    Mudel on ’reaalse’ maailma osa (huvipiirkonna, valdkonna, objektsüsteemi) eesmärgipärane lihtsustatud esitus

    (n. mänguauto, mat. valem või võrrandisüsteem , geograafiline kaart, filmi stsenaarium , tarkvara kood/prototüüp, mõttemall,..).

    • Modelleerimine on ’reaalse’ maailma ( mudeliga vahendatud) käsitlemise viis.
    • Mudel kui ’reaalse’ maailma ( fokusseeritud ) käsitlemise vahend (keskendub olulisele, peidab ebaolulisi detaile, vähendab keerukust, sageli abstraheerib).
    • Mudel esitab reaalse maailma (= objektsüsteemi, semantikavaldkonna) vaate (interpretatsiooni).
      • Väljendab (kellegi) teadmist selle maailma (mudeli kontekst) kohta
    • Ühest ja samast reaalsusest eksisteerib N erinevat võimalikku vaadet/interpretatsiooni/mudelit.

    • [Sama mudelit saab põhimõtteliselt rakendada erinevatele reaalsustele/kontekstidele (sama mudeli erinevad interpretatsioonid)]

    Näide 1: MAAILM = ”Õppetöö Valdkond Ülikoolis”, ’prillikandjateks’ selle valdkonna põhitegelased – Tudengid , Õppejõud, Ametnikud,...
    MIS ON MUDEL ? (modelleerimisega seotud põhimõistetest, täpsemalt)
    MUDEL ja KONTEKST
    MUDEL – INTERPRETATSIOON – VALDKOND
    Mudel on lausete (väidete) hulk uuritava Valdkonna (=semantikavaldkond ehk kontekst mudeli jaoks) kohta kindlas modelleerimisKeeles.
    Mudeli lausetele annab tähenduse Interpretatsioon mis ’projitseerib’ selle mudeli elemendid semantilise Valdkonna elementidele (vastavuse loomine).
    Mudelit võidakse (analüüsitöös) kasutada Valdkonna kirjeldamiseks (analüüs saab aru). Sel juhul loetakse mudelit kindla Interpretatsiooni all korrektseks juhul, kui kõik selles mudelis leiduvad laused ( väited ) on tõesed antud Valdkonna jaoks (mudel kirjeldab valdkonda).
    Mudelit võidakse (disainitöös) kasutada ka Valdkonna (või mõne temas sisalduva süsteemi) spetsifikatsioonina (disain loob lahenduse). Sel juhul loetakse konkreetset Valdkonda valiidseks (valid) vastava spetsifikatsiooni suhtes siis, kui ükski mudelis leiduv lause (väide) pole väär selle Valdkonna jaoks (spetsifikatsiooni saab realiseerida selle valdkonna baasil).
    Lihtne näide omandisuhete Valdkonnast, mille Mudel (kirjeldus) on antud kahe Lausega ( väitega ): iga Isik omab nime; mõned Isikud omavad Maju.
    Sama Mudel omab ka teistsugust Interpretatsiooni, Java keeles kirjutatud tarkvaraprogrammide Valdkonna jaoks. Seda Mudelit võime käsitleda vastava tarkvaraprogrammi (disaini)spetsifikatsioonina, mis eksisteerib enne programmi kirjutama hakkamist ja on vajalik valiidse Java programmi konstrueerimiseks.
    MODELLEERIMiNE SÜSTEEMITÖÖ kontekstis hõlmab:
    • Valdkonna (äri) modelleerimist
    • Nõuete modelleerimist
    • Tarkvara modelleerimist

    SÜSTEEMITÖÖ (system work , system engineering – süsteemide väljatöötamine ja tööshoidmine) põhitegevused (distsipliinid):
    • Modelleerimine ( ideest kuni teostuseni, Valdkond->Nõuded-> Tarkvara)
    • Juhtimine (n. projekti- , programmi-, portfelli- vm muudatuse )
    • Kvaliteeditöö
    • Koolitamine /õppimine
    • ..
    ANALÜÜS versus DISAIN versus TEOSTAMNE (vt. MDA mudelite liigid)
    • Analüüs saab aru (‘musta kasti’ mudel; MIDA süsteem teeb/teab)
    • Disain annab lahenduse (‘valge kasti’ mudel; KUIDAS teeb/teab)

    \ MUDEL
    SÜSTEEM \
    Musta kasti“ mudel ehk Analüüs (MIDA ?)
    Valge kasti“ mudel ehk
    Disain (KUIDAS ?)
    ÄriSüsteem ehk
    Puhas Valdkond
    ÄriAnalüüs
    Nõuded ÄriSüsteemile
    ÄriDisain
    ÄriSüsteemi lahenduse loomine
    TarkvaraSüsteem (- Rakendus )
    Tarkvara Analüüs -> Nõuded tarkvarale
    Tarkvara Disain (N: objektorienteeritud lahenduse loomine)
    „Füüsiline“ süsteem ehk
    Tehnoloogia
    Nõuded riistvarale ja alustarkvarale
    Deployment diagramm
    KomponentDiagramm?
    ÕPPEAINE KIRJELDUS
    õppeaine register
    A - põhiregister
    õppeaine kood
    IDU5360
    õppeaine nimetus eesti k
    [Kontseptuaalne] Süsteemianalüüs
    õppeaine nimetus inglise k
    [Conceptual] System Analysis
    õppeaine nimetus vene k
    [Kontseptualnyi] sistemnyi analiz
    õppeaine maht AP
    3.5
    õppeaine maht EAP
    5.00
    deklareeritav
    jah
    kontrollivorm
    eksam
    õpetamise semester
    kevad
    õppetöö keel: eesti keel
    jah
    inglise keel
    ei
    vene keel
    ei
    õppeaine eesmärgid:
    1.Anda arusaamine süsteemianalüüsi kohast infosüsteemide (jt. tarkvaramahukate süsteemide) arendamisel.
    2.Õpetada süsteemset mõtlemist ja täpset väljendumist
    3.Omandada süsteemianalüüsi kaasaegsed meetodid, tehnikad ja vahendid
    4.Õpetada süsteemianalüüsi kui tellijakeskset vaadet infosüsteemile ja selle arendamisele
    5. Õpetada nõuete ning kasutajaliideste analüüsi ja haldamist (kontseptuaalse) süsteemianalüüsi tähtsa osana
    6. Suhestada nõuete ning kasutajaliideste analüüs valdkonnamodelleerimisega, samuti erinevate disainiteemadega
    7.Viia läbi ainetöö /aineprojekt
    8.Näidata liidesed seotud distsipliinidega
    õppeaine õpiväljundid:
    1.Saab aru süsteemianalüüsi olemusest ning rollist infosüsteemi arendusprotsessis
    2. Saab aru analüüsi ning disaini erinevusest ning ühtsusest.
    3. Oskab süsteemselt (struktuurselt) mõelda ning arutleda.
    4.Teab ning oskab kasutada ja siduda traditsioonilise (struktuurse), objektorienteeritud ning agent -orienteeritud süsteemianalüüsi tuntumaid meetodeid , tehnikaid ning vahendeid.
    5.On võimeline rakendama kontseptuaalset süsteemianalüüsi ümbritseva elu erinevatele nähtustele ja probleemidele nende mõistmiseks, kirjeldamiseks ja selgitamiseks.
    6.Oskab kasutada UMLi põhilisi diagrammitehnikaid (UP - Unified Process -i) ärimodelleerimise ja (kasutusjuhtude ning/või kasutuslugude keskse) nõuete analüüsi kontekstis
    7.Oskab kirjeldada, analüüsida, hallata ning selgitada infosüsteemi/arenduse osapoolte nõudeid ja eesmärke, mõisteid, kasutuslugusid ja kasutajaliideseid.
    8.Oskab ühendada tekstilist ning graafilist (sealhulgas UML) modelleerimist, ning päringute (vaadete) koostamist (valdkonnamudeli alusel nõuete modelleerimiseks).
    9.Oskab püstitada ülesannet disainerile ( disainer -programmeerijale).
    10.Tunneb iteratiivse arendusprotsessi UP põhiloogikat ning oskab näha süsteemianalüüsi distsipliine (ärimodelleerimine ja kasutusjuhtude keskne nõuete analüüs) selle terviku osadena.
    11. Oskab hallata (iteratiivse arendamise käigus tekkivaid) mudelite versioone ja muudatusi.
    12. Oskab retsenseerida kaastudengite töid (antud aine raames)
    õppeaine sisu lühikirjeldus :
    Valdkonna analüüs. Mõisteline (kontseptuaalne) modelleerimine ja mõisteraamistikud (ontoloogiad). Analüüs ja Arhitektuur : kihid , vaated, elutsükkel . Valdkond vs infrastruktuur . Ärimudeli kiht kui „puhas valdkond“ ning kontseptuaalne (computing independent) vaade infosüsteemile. Süsteemianalüüsi koht klassikalises ja iteratiivses arendustsüklis. Analüüs vs. Disain. Strateegiline analüüs vs. detailanalüüs. Klassikaline (struktuurne) vs. objektorienteeritud analüüs, agent-orienteeritud analüüs, nende ühtsus ja erinevus. Ärimodelleerimine vs nõuete (ning kasutajaliideste) analüüs. Objektide, protsesside, sündmuste, organisatsiooni (tegutsejate/agentide), eesmärkide ja suhtluste analüüs ning modelleerimine. Tekstiline vs. graafiline modelleerimine analüüsitöös. UML: klassidiagrammid , kasutusjuhtude diagrammid , tegevusdiagrammid, olekudiagrammid, jadadiagrammid analüüsimudelite kontekstis. Süsteemi nõuded ja kasutusjuhud, kasutuslood ning kasutajaliidesed . Üleminek ärimudelilt kasutusjuhtude mudelile. Kasutusjuhtude kirjeldamise formaadid . Domeenimudel (staatilise valdkonnamudeli tähenduses). Nõuded ja kasutajaliidesed kui vaated (päringud) domeenimudelisse. Süsteemi sündmused ja operatsioonid . Süsteemi jadadiagrammid. Süsteemi operatsioonide lepingud . Analüüsimudeli tükeldamine, haldamine , dokumenteerimine , versioonide ja muudatuste haldus. Analüüsimustrid. Süsteemianalüüsi protsess (iteratiivse arenduspotsessi raamistikus). Üleminek analüüsilt disainile.
    Hindamisviisid :
    1.Iseseisva töö kaitsmine (40% eksamihindest, praktilise töö esitamine on eksami eelduseks).
    2.Teise tudengi töö hindamine ( 10% eksamihindest).
    3.Kontrolltööd kõigi suuremate teemade läbimise järel (eksami eeldus, 50% eksamihindest).
    Õppekirjandus:
    C.Larman, An Introduction to Object-Oriented Analysis and Design and the Unified Process: Applying UML and Patterns , 2001 (või hilisem).
    L.Sterling and K.Taveter, Agent Oriented Modeling, The MIT Press, 2009.
    J. Heuman, An Introduction to Business Modeling in UML [Online] http://www.ibm.com/developerworks/rational/library/360.html
    M. Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, 2005.
    eeldusaine 1
    IDU3530 - Sissejuhatus infosüsteemidesse
    eeldusaine 2
    IDU3355 - Modelleerimine
    statsionaarõpe:     nädalatunnid
    4.0
         loenguid
    2.0
          praktikume
    0.0
         harjutusi
    2.0
    reegel eesti keeles (2000 tähemärki)
    Deklareerimine ainult õppejõu loal.
    iseseisev töö:
    Vabalt valitud Äriteenuse (vm valdkonna) infosüsteemi detailanalüüs, keskendatud põhilisele äriprotsessile (äriteenuse osutamine) ja seda toetavale IS (funktsionaalsele) allsüsteemile. Nõutud vaadete kirjeldamine, modelleerimine, kooskõlastamine , vormistamine. Nõuete ning kasutajaliideste kirjeldamine ja analüüs. (Ühte tööd võivad teha 1 – 2 tudengit. Kahekesi tehes olgu töö laius poole suurem).
    Loeng 2.1 Aine põhimõisted ja raamistikud (1). Valdkonnapõhine süsteemianalüüs: Zachmani raamistik kui Süsteemianalüüsi aine mõtlemisraamistiku raamistiku esimene nurgakivi
    Eesmärk: kujundada mõtlemisraamistik (mõisteraamistik, ontoloogia ) Süsteemianalüüsi ainele
    • Zachmani raamistik (tuletame meelde Modelleerimise ainest)
    • Valdkonnapõhine süsteemianalüüs
    • Harjutustundide toetamine , eesmärkmudelid, UML kasutusjuhtude diagrammi tõlgendus eesmärkmudelina
    Zachmani tugiraamistik
    Süsteemi analüüs (kui tegevus) on struktuurne arutelu asjaosaliste (süsteemiga seotud erinevad osapooled-huvigrupid) vahel süsteemist (valdkonnast, tootest, teenusest, protsessist,..) ühise arusaamise kujundamise eesmärgil.
    Struktuurseks aruteluks vajame me mõtlemisraamistikku (analüüsi raamistikku).
    Võime alustuseks tugineda klassikalisele Zachmani tugiraamistikule (ettevõtte vm ärivaldkonna ja tema infosüsteemi arhitektuuri kirjeldamiseks). http://www.zachman.com/
    [vt. ka Modelleerimise aine konspektist lk. 30?]
    Zachman Framework (ZF) on kahemõõtmeline tabel, mille
    Veerud vastavad põhiküsimustele:
    Mis? Objektid, andmed
    Kuidas? Funktsioonid, protsessid, tegevused
    Kus? Asukohad, võrk
    Kes? Inimesed, rollid, vastutused
    Millal? Aeg, sündmused, stsenaariumid, elutsüklid
    Miks? Eesmärgid, strateegiad, nõuded - Motivatsioon
    Read vastavad süsteemitöö (arendus + ülalhoid ) põhilistele osapooltele-huvigruppidele:
    Juhtkond , tippjuhid, planeerijad: ärisõnastik , ärimõisted, loetelud;
    Ärimõistete (n. protsesside, toodete, süsteemide) omanikud : ettevõtte/valdkonna/äri mudel, ärimõistete definitsioonid ;
    Arhitekt -disainer: süsteemi mudel, loogiline mudel, ärimõistete esitus süsteemis;
    Ehitaja- tehnoloog : tehnoloogia mudel, füüsiline mudel;
    Tehnik (n. programmeerija ): tööriista (tarkvara) mudel, detailne spetsifikatsioon , kood;
    Ülalhoidja: toimiv ettevõte/valdkond/äri/tarkvara.
    Vaated
    Kihid
    Objektid
    Mis?
    Protsessid
    Kuidas?
    Asukohad
    Kus?
    Inimesed
    Kes?
    Sündmused
    Millal?
    Eesmärgid
    Miks?
    Juhtkonna
    liige
    Objektide
    nimekiri
    Protsesside
    nimekiri
    Asukohtade
    nimekiri
    Osapoolte
    nimekiri
    Sündmuste nimekiri
    Eesmärkide
    nimekiri
    Ärimõiste omanik
    Äri objektmudel
    Äriprotsessi
    mudel
    Äri asukoha-mudel
    Äri rolli
    mudel
    Äri sündmu-sed ja stsenaariumid
    Äri eesmärk-
    mudel
    Arhitekt-
    Disainer
    Süsteemi
    objektmudel
    Süsteemi protsessi-mudel
    Süsteemi
    asukohamu-
    del
    Süsteemi
    rolli mudel
    Süsteemi sündmused,
    stsenaariumid
    Süsteemi
    Eesmärkmu-
    del
    Ehitaja-
    Tehnoloog
    Tehnoloogia
    objektmudel
    Tehnoloogia
    protsessi-mudel
    Tehnoloogia
    asukohamu-
    del
    Tehnoloogia
    rolli mudel
    Tehnoloogia
    sündmused, stsenaariumid
    Tehnoloogia
    eesmärk-
    mudel
    Tehnik-
    Program-meerija
    Tööriista
    objektmudel
    Tööriista
    protsessi-mudel
    Tööriista
    asukoha-
    mudel
    Tööriista
    Rolli
    mudel
    Tööriista
    sündmused,
    stsenaariumid
    Tööriista
    eesmärk-
    mudel
    Ülalhoidja-
    Administ-raator
    Toimiv
    objektmudel
    (instants)
    Toimiv
    protsessi-mudel
    Toimiv
    asukoha-
    mudel
    Toimiv
    rolli mudel
    Tegelikud
    sündmused,
    stsenaariumid
    Operatsioo-
    nilised
    eesmärgid
    Zachmani raamistik rakendub igale ärivaldkonnale (s.h. konkreetne ettevõte A, ettevõtete ühendus, ettevõtte osa) sõltumata selle suurusest .
    Eristame „puhast“ valdkonda (ülemised kaks rida) ja (IT) infrastruktuuri (alates kolmandast reast ) ja vastavaid mudeleid, mis MDA (Model Driven Architecture ) mudelite klassifikatsiooni järgi on:
    • CIM - Computing Independent Model (Zachmani ülalt teine rida)
    • PIM - Platform Independent Model (Z kolmas rida)
    • PSM – Platform Specific Model (Z neljas rida)
    • Kood (Z viies rida).

    Valdkonnapõhine süsteemianalüüs (meie põhiteema!) katab Zachmani raamistiku ülemist kahte („arvutamisest sõltumatut“) rida.
    Valdkonnatehnikad (domain engineering) katavad Zachmani raamistiku ülemist kolme rida.
    Kogu Zachmani raamistik (valdkond koos infrastruktuuriga) kirjeldab valdkonna infosüsteemi üldist ülesehitust ehk arhitektuuri.
    Loeng 2.2 Kontseptuaalne süsteemianalüüs iteratiivse arendusprotsessi osana.

    Loengu eesmärk:

    • Anda ülevaade iteratiivsest arendusprotsessist Unified Process (UP):

      • Näidata seosed UP ja Zachmani raamistiku vahel.

    • Käsitleda kontseptuaalsest süsteemianalüüsi iteratiivse arendusprotsessi osana:

      • Siduda ainetöö (-projekti) tegemine iteratiivse arendusprotsessi raamistikuga.

    • Toetada harjutustunde:
      • Anda ülevaade visiooni kirjeldamisel kasutatavatest mudelitest ja notatsioonidest (lisaks eelmises loengus tutvustatud eesmärkmudelitele):
        • kontseptuaalne klassidiagramm kui visuaalne ärisõnastik;
        • kontekstidiagrammide erinevad võimalikud esitused ja notatsioonid
        • äriprotsessi kirjeldamine (UML tegevusdiagramm vs mitte-UML: BPMN)


    Kava
    • Süsteemianalüüs iteratiivse arendusprotsessi osana
      • Arendusmetoodikad: produkti versus protsessi vaade
      • Klassikaline arendustsükkel ( kose mudel), süsteemianalüüsi koht selles
      • Iteratiivse arendusprotsessi UP põhiraamistik
      • Kontseptuaalse süsteemianalüüsi koht selles raamistikus
      • Kontseptuaalse süsteemianalüüsi aine (valdkonna, metoodika) arhitektuur (Zachmani pluss UP raamistiku eeskujul)
      • Ainetöö (projekti) ülesande käsitlemine selles raamistikus

    • Valdkonna visiooni esitamiseks kasutatavad mudelid ja notatsioonid
      • Aine deklareerimise (teenuse) näide: eesmärkmudel
      • Kontseptuaalne klassidiagramm (visuaalne ärisõnastik)
      • Kontekstidiagrammid
      • Äriprotsessi töövoo kirjeldamine (UML, BPMN)


    Süsteemianalüüs erinevates arendusmetoodikates
    Eelmises loengus rääkisime valdkonnapõhisest süsteemianalüüsist, mis toetub Zachmani arhitektuuriraamistikule ning katab selle kaks ülemist rida, millised kirjeldavad nn. „puhast valdkonda“ (äri/tegevus) infrastruktuurist (IT) sõltumatult.
    Zachmani ülalt teine rida esitab puhta valdkonna mudeli, mille alusel süsteemianalüüs püstitab nõuded valdkonna infrastruktuurile (tarkvarasüsteemile).
    Nõuded tarkvarasüsteemile asuvad Zachmani raamistikus ülalt kolmandas reas Motivatsiooni (MIKS?) veerus /lahtris [Tarkvara „musta kasti“ mudel].
    Süsteemianalüüs on süsteemitöö (=distsiplineeritud arenduslik töö) osa ( distsipliin ),
    mis tegeleb valdkonna (praktika) uurimise ja kirjeldamisega (valdkonna mudeli või/ning teooria ehitamine) ning infrastruktuuri (n. tarkvara) nõuete püstitamisega,
    mille alusel disain loob sobiva infrastruktuuri lahenduse (Zachmani raamistiku ülalt kolmas rida vastab infrastruktuuri loogilisele ja neljas rida füüsilisele lahendusele, viies rida on realisatsioon ja kuues rida rakendus).
    Arendusmetoodikad: produkti versus protsessi vaade
    Süsteemitöös järgitakse kindlat metoodikat.
    Metoodika annab tavaliselt raamistiku nii töötulemite kui ka tööprotsesside süsteemseks kirjeldamiseks (vastavalt, produktiraamistik ja
  • 80% sisust ei kuvatud. Kogu dokumendi sisu näed kui laed faili alla
    Vasakule Paremale
    Süsteemianalüüsi kontrolltöö 1 #1 Süsteemianalüüsi kontrolltöö 1 #2 Süsteemianalüüsi kontrolltöö 1 #3 Süsteemianalüüsi kontrolltöö 1 #4 Süsteemianalüüsi kontrolltöö 1 #5 Süsteemianalüüsi kontrolltöö 1 #6 Süsteemianalüüsi kontrolltöö 1 #7 Süsteemianalüüsi kontrolltöö 1 #8 Süsteemianalüüsi kontrolltöö 1 #9 Süsteemianalüüsi kontrolltöö 1 #10 Süsteemianalüüsi kontrolltöö 1 #11 Süsteemianalüüsi kontrolltöö 1 #12 Süsteemianalüüsi kontrolltöö 1 #13 Süsteemianalüüsi kontrolltöö 1 #14 Süsteemianalüüsi kontrolltöö 1 #15 Süsteemianalüüsi kontrolltöö 1 #16 Süsteemianalüüsi kontrolltöö 1 #17 Süsteemianalüüsi kontrolltöö 1 #18 Süsteemianalüüsi kontrolltöö 1 #19 Süsteemianalüüsi kontrolltöö 1 #20 Süsteemianalüüsi kontrolltöö 1 #21 Süsteemianalüüsi kontrolltöö 1 #22 Süsteemianalüüsi kontrolltöö 1 #23 Süsteemianalüüsi kontrolltöö 1 #24 Süsteemianalüüsi kontrolltöö 1 #25 Süsteemianalüüsi kontrolltöö 1 #26 Süsteemianalüüsi kontrolltöö 1 #27 Süsteemianalüüsi kontrolltöö 1 #28 Süsteemianalüüsi kontrolltöö 1 #29 Süsteemianalüüsi kontrolltöö 1 #30 Süsteemianalüüsi kontrolltöö 1 #31 Süsteemianalüüsi kontrolltöö 1 #32 Süsteemianalüüsi kontrolltöö 1 #33 Süsteemianalüüsi kontrolltöö 1 #34 Süsteemianalüüsi kontrolltöö 1 #35 Süsteemianalüüsi kontrolltöö 1 #36 Süsteemianalüüsi kontrolltöö 1 #37 Süsteemianalüüsi kontrolltöö 1 #38 Süsteemianalüüsi kontrolltöö 1 #39 Süsteemianalüüsi kontrolltöö 1 #40 Süsteemianalüüsi kontrolltöö 1 #41 Süsteemianalüüsi kontrolltöö 1 #42 Süsteemianalüüsi kontrolltöö 1 #43 Süsteemianalüüsi kontrolltöö 1 #44 Süsteemianalüüsi kontrolltöö 1 #45 Süsteemianalüüsi kontrolltöö 1 #46 Süsteemianalüüsi kontrolltöö 1 #47 Süsteemianalüüsi kontrolltöö 1 #48 Süsteemianalüüsi kontrolltöö 1 #49 Süsteemianalüüsi kontrolltöö 1 #50 Süsteemianalüüsi kontrolltöö 1 #51 Süsteemianalüüsi kontrolltöö 1 #52 Süsteemianalüüsi kontrolltöö 1 #53 Süsteemianalüüsi kontrolltöö 1 #54 Süsteemianalüüsi kontrolltöö 1 #55 Süsteemianalüüsi kontrolltöö 1 #56 Süsteemianalüüsi kontrolltöö 1 #57 Süsteemianalüüsi kontrolltöö 1 #58 Süsteemianalüüsi kontrolltöö 1 #59 Süsteemianalüüsi kontrolltöö 1 #60 Süsteemianalüüsi kontrolltöö 1 #61 Süsteemianalüüsi kontrolltöö 1 #62 Süsteemianalüüsi kontrolltöö 1 #63 Süsteemianalüüsi kontrolltöö 1 #64 Süsteemianalüüsi kontrolltöö 1 #65 Süsteemianalüüsi kontrolltöö 1 #66 Süsteemianalüüsi kontrolltöö 1 #67 Süsteemianalüüsi kontrolltöö 1 #68 Süsteemianalüüsi kontrolltöö 1 #69 Süsteemianalüüsi kontrolltöö 1 #70 Süsteemianalüüsi kontrolltöö 1 #71 Süsteemianalüüsi kontrolltöö 1 #72 Süsteemianalüüsi kontrolltöö 1 #73 Süsteemianalüüsi kontrolltöö 1 #74 Süsteemianalüüsi kontrolltöö 1 #75 Süsteemianalüüsi kontrolltöö 1 #76 Süsteemianalüüsi kontrolltöö 1 #77 Süsteemianalüüsi kontrolltöö 1 #78 Süsteemianalüüsi kontrolltöö 1 #79 Süsteemianalüüsi kontrolltöö 1 #80 Süsteemianalüüsi kontrolltöö 1 #81 Süsteemianalüüsi kontrolltöö 1 #82 Süsteemianalüüsi kontrolltöö 1 #83 Süsteemianalüüsi kontrolltöö 1 #84 Süsteemianalüüsi kontrolltöö 1 #85 Süsteemianalüüsi kontrolltöö 1 #86 Süsteemianalüüsi kontrolltöö 1 #87 Süsteemianalüüsi kontrolltöö 1 #88 Süsteemianalüüsi kontrolltöö 1 #89 Süsteemianalüüsi kontrolltöö 1 #90 Süsteemianalüüsi kontrolltöö 1 #91 Süsteemianalüüsi kontrolltöö 1 #92 Süsteemianalüüsi kontrolltöö 1 #93 Süsteemianalüüsi kontrolltöö 1 #94 Süsteemianalüüsi kontrolltöö 1 #95 Süsteemianalüüsi kontrolltöö 1 #96 Süsteemianalüüsi kontrolltöö 1 #97 Süsteemianalüüsi kontrolltöö 1 #98 Süsteemianalüüsi kontrolltöö 1 #99 Süsteemianalüüsi kontrolltöö 1 #100 Süsteemianalüüsi kontrolltöö 1 #101 Süsteemianalüüsi kontrolltöö 1 #102
    Punktid 50 punkti Autor soovib selle materjali allalaadimise eest saada 50 punkti.
    Leheküljed ~ 102 lehte Lehekülgede arv dokumendis
    Aeg2014-12-14 Kuupäev, millal dokument üles laeti
    Allalaadimisi 68 laadimist Kokku alla laetud
    Kommentaarid 0 arvamust Teiste kasutajate poolt lisatud kommentaarid
    Autor 213757 Õppematerjali autor

    Lisainfo

    Mõisted

    idu5661, idu0050, idx5010, idu3530, osapooltele, arhitekt, arhitekt, tehnik, program, administ, süsteemianalüüs, zachmani arhitektuuriraamistik, metoodikana rakendamiseks, distsipliin, analüüsiks, up faasid, enterprise architect, neid projekte, hilistes iteratsioonides, iteratsioonid, 3 construction, distsipliin, artifact, rasked protsessid, elaboration faas, ärisüsteemidel, äriprotsess, ärireegel, äriprotsessid, uurimustööd, uml, äriprotsessikeskne modelleerimine, ärikasutusjuhukeskne modelleerimine, mudeli kasutajale, eriksson, 1471, laboratoorium, visioon, kulude optimeerimine, tööaja optimeerimine, kvaliteedi tõstmine, kvaliteetne proov, rahulolevad kliendid, õigeaegne aruandlus, mugav tellimine, joonis e, kliendi tellimusel, kliendi aruanne, kliendi tellimus, proov, proovile, uuringul, analüsaator, kliendi tellimus, kliendi aruanne, patsient, profail, proov, originaal, lihtsustamiseks, testide tellimine, distributsioon, valideerimine, interpreteerimine, joonis a, joonis a, kliendi tellimusel, tellimusel, tellimusel, joonis a, testil, testil, joonis a, joonis a, käitumisvaates, joonis a, joonis a, ressursid, joonis a, soovi korral, äriprotsess, joonis b, joonis b, eesmärkide hierarhia, joonis b, funktsionaalsed eesmärgid, joonis b, sellel tegevusdagrammil, joonis b, joonis b, joonis b, joonis b, käesolevas tegevusdiagrammis, põhiobjekti, joonis b, joonis b, ärimodelleerimise protsessi, modelleerimisvõimalusi, tegevusdiagramm, protsessi alguses, tegevusharusid, alternatiivsed tegevusharud, sünkroniseerimisjoon, bpmn, bpmn, ärikasutusjuhtude, bpmn

    Meedia

    Kommentaarid (0)

    Kommentaarid sellele materjalile puuduvad. Ole esimene ja kommenteeri


    Sarnased materjalid

    12
    docx
    Süsteemianalüüs - Esimese loengutöö konspekt
    12
    docx
    Süsteemianalüüsi kontrolltöö vastused
    6
    docx
    Süsteemianalüüsi 3-kontrolltöö
    1072
    pdf
    Logistika õpik
    22
    docx
    Süsteemianalüüs - Kolmanda loengutöö konspekt
    26
    docx
    Süsteemianalüüs - 2 loengutöö konspekt
    42
    doc
    Klassidiagrammid
    52
    docx
    Sissejuhatus infosüsteemidesse kontrolltöö teooria





    Faili allalaadimiseks, pead sisse logima

    Kasutajanimi / Email
    Parool

    Unustasid parooli?

    UUTELE LIITUJATELE KONTO MOBIILIGA AKTIVEERIMISEL +50 PUNKTI !
    Pole kasutajat?

    Tee tasuta konto

    Sellel veebilehel kasutatakse küpsiseid. Kasutamist jätkates nõustute küpsiste ja veebilehe üldtingimustega Nõustun