Otsi
Vajad kellegagi rääkida?
Küsi julgelt abi LasteAbi
Logi sisse ☰

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

Informaatika - Modulatsioon
2 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?
  • Kus asuvad labori struktuurüksused?
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 protsessiraamistik).
    Zachmani arhitektuuriraamistik on ainult produktiraamistik süsteemitöö tulemite kirjeldamiseks (mida valmistada?).
    Metoodikana rakendamiseks on Zachmani raamistikku kasulik laiendada sobiva protsessiraamistikuga (kuidas tulemeid valmistada?).
    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.
    Kose mudeli järgi, kus igas arendusetapis tehakse ühte liiki tegevusi (puhas analüüs, puhas disain, jne.), tehakse kogu analüüs ära esimeses arendusetapis (väikeste süsteemide puhul) või esimeses kahes etapis (suurte süsteemide puhul).
    Suurte süsteemide puhul on esimeseks etapiks terviksüsteemi tasemeline strateegiline analüüs, mis tükeldab terviksüsteemi eraldi analüüsitavateks allsüsteemideks.
    Teine ehk detailanalüüsi etapp tegeleb konkreetsete allsüsteemide täpse analüüsiga, millest edasi minnakse disaini, milles luuakse allsüsteemide tarkvara.
    Ehitusetapis pannakse allsüsteemid ühtse tervikuna koos toimima.
    Rakendamine viib põhimõtteliselt töötava süsteemi üle tellijaettevõtte keskkonda.
    (Kontseptuaalse) Süsteemianalüüsi aine keskendub konkreetse teenuse ehk allsüsteemi detailanalüüsi etapile.
    Arendusetappidest saame mõelda kui Zachmani raamistiku kahe mõõtmega (read, veerud) ristuvast (ortogonaalsest) kolmandast mõõtmest (dimensioonist).
    Järgnevalt tutvustatav iteratiivse arendusprotsessi (RUP või UP) raamistik laiendab Zachmani raamistikku kahe uue mõõtmega: lisaks etappidele (faasidele) ka distsipliinid (töövood).
    Iteratiivne arendusprotsess RUP/UP
    Kose mudeli faasid teisenevad iteratiivses arendusprotsessis distsipliinideks (joonisel on kasutatud distsipliini asemel nimetust ’ töövoog ’).
    Distsipliin on sarnaseid arendustegevusi ühendav valdkond.
    Iteratiivses protsessiraamistikus lahutatakse faasid (etapid) ja distsipliinid omavahel ristuvateks dimensioonideks seetõttu, et iteratiivse arendamise igas faasis tehakse korraga paljude distsipliinide tegevusi.
    Klassikalises mõttes analüüsi distsipliinideks on kaks ülemist: Ärimodelleerimine ja Nõuete analüüs ( Requirements ).
    Kolmas distsipliin nimega Analüüs & Disain on tegelikult puhas disain, sest analüüsiks nimetatakse selles raamistikus tarkvara arhitektuurilahenduse loomist, mis on olemuselt disainitöö.
    (Kontseptuaalse) Süsteemianalüüsi aine katab seega Unified Processi (UP) raamistiku kahte ülemist rida, andes täpse ülesande disainerile ehk liidese ülalt kolmanda reaga (Disaini distsipliiniga).
    UP faasid on Alustamine (Inception – loob esialgse visiooni), Täpsustamine (Elaboration - loob reaalselt töötava arhitektuuri, millel realiseerib väikese hulga t’ htsamaid /riskantsemaid põhifunktsionaalsusi), Konstrueerimine (realiseerib kõik funktsionaalsused), Üleviimine (Transition – paneb tööle tellija keskkonnas).
    Analüüsiga võidakse põhimõtteliselt tegeleda kõikides faasides (etappides) ja iteratsioonides (faasid koosnevad iteratsioonidest), ehkki esimestes etappides ja iteratsioonides on analüüsitegevuste osakaal tavaliselt suurem kui tagumistes.
    Iteratsioonidest ja iteratiivsest arendusmudelist räägime täpsemalt edasi järgmises loengus, pärast Süsteemianalüüsi aine iteratiivse raamistiku kirjeldamist ja ainetöö (-projekti) käsitlemist selle raamistiku alusel.
    Aine „Süsteemianalüüs“ raamistik
    Käesolev aine katab:
  • Zachmani raamistiku 2 ülemist kihti ( skoop / sõnastik ja ärimudel);
  • „Kose mudeli“ arendusetappidest teise (analüüs ehk detailanalüüs) etapi;
  • 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 :
    Aine „raamistik“ tabelina:
    I iteratsioon (Inception)
    II iteratsioon (Elaboration1)
    III iteratsioon (Elaboration2)
    Planeerimine / Skoop / Kontekst/ Sõnastik
    Äriteenuse valik (taust);
    Äriteenuse ( mission ja) eesmärgid (mõõtmine?);
    Äriteenuse pakkuja , kasutajad (Äritegutsejad);
    (Välised) ÄriSündmused , ÄriKasutusjuhud ;
    ÄriOlemid.
    IS allsüsteemid
    Teise iteratsiooni planeerimine
    plaani/skoobi ülevaatamine/täpsustamine;
    funktsionaalsete nõuete täpsustamine
    plaani/skoobi täpsustamine;
    Ärimodelleerimine
    Eesmärkmudel
    Ärikasutusjuhtude kontekstidiagramm;
    (Sama taseme lausendid ja esialgne domeenimudel (ilma atribuutideta).)
    Äriprotsesside struktuur (eesmärkmudelit esitaval ärikasutusjuhtude diagrammil );
    Põhiprotsessi “ümberjutustus” ja/või lausendid ning esialgne domeenimudel (ilma atribuutideta);
    Põhiprotsessi töövoo tegevusdiagramm(id);
    Infovoogudega tegevusdiagrammid;
    Põhiobjektide olekudiagrammid;
    Nõuete Analüüs
    (Kasutusjuhtude mudel)
    ( Funktsionaalsed ja mittefunktsionaalsed) nõuded
    Arvutikasutuse Sündmused / Primaarsed Kasutusjuhud; Kasutusjuhtude diagramm (primaarsete kasutusjuhtudega); Prioriteetsete kasutusjuhtude lühikirjeldused;
    Keerukaima(te) kasutusjuh(tu)u(de) laiformaadis kirjeldus;
    süsteemi jadadiagramm põhistsenaariumile;
    Põhiallsüsteemi operatsioonide lepingud;
    domeemimudeli täpsustamine ( atribuudid , seoste detailid,..);
    Põhiallsüsteemi ülejäänud kasutusjuhtude lühikirjeldused;
    Täpsustatud kasutusjuhtude diagramm
    Kihid:
    • Planeerimine, Skoobi haldamine, ÄriKontekst (-Sõnastik)
    • Ärimodelleerimine
    • Nõuete analüüs, Kasutusjuhtude (tarkvara kasutus) modelleerimine

    Iteratsioonid:
    • I iteratsioon ( Visioon ): planeerimine, eesmärkmudel, funktsionaalsed nõuded, kontekstidiagrammid? Lausendid (ka klassidiagrammil)?
    • II iteratsioon: plaani/skoobi ülevaatamine/täpsustamine, ärimodelleerimine, funktsionaalsete nõuete täpsustamine, primaarsete kasutusjuhtude kirjeldamine ja diagramm, esialgne domeenimudel (kasutusjuhtude kirjeldustega kooskõlas)
    • III iteratsioon: plaani/skoobi täpsustamine, keerukaima(te) kasutusjuh(t)u(de) laiformaadis kirjeldus, süsteemi jadadiagramm põhistsenaariumi(te)le, süsteemi operatsioonid ja lepingud, domeemimudeli täpsustamine

    Praktiline töö: Vabalt valitud Äriteenuse 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. Tööd saab teha üksinda või kahekesi
    Nõuded praktilisele tööle:
    • Tööd saab teha üksinda või kahekesi
    • Hõlmab skoobi planeerimist, ärimodelleerimist ja kasutusjuhtude modelleerimist
    • On jagatud kolmeks iteratsiooniks (verstapostiks)
    • Skoobi planeerimine hõlmab äriteenuse valimist ja valiku põhjendamist (töö kontekst), äriteenuse eesmärkide loetelu (ja/või mudelit), põhiliste äritegutsejate (äriteenuse pakkuja ja kasutajad) loetelu, põhiliste ärisündmuste ja ärikasutusjuhtude loetelu, põhiliste äriolemite (äriobjektide) loetelu, infosüsteemi (funktsionaalsete) allsüsteemide ja registrite loetelu
    • Ärimodelleerimine hõlmab teksilist ja graafilist modelleerimist
    • Graafiline modelleerimine (ärimudelis) hõlmab ärikasutusjuhtude diagramme , põhiliste äriprotsesside tegevusdiagramme, põhiliste äriobjektide (olemite) olekudiagramme, kontseptuaalseid klassidiagramme (nn. Domeenimudel)
    • Tegevusdiagrammid väljendavad töövoogusid ja infovoogusid
    • Tekstiline modelleerimine (ärimudelis) hõlmab vaba teksti ja lausendeid.
    • ---------------------------------------
    • Kasutusjuhtude modelleerimine viiakse läbi ühe põhilise allsüsteemi ulatuses, kuid detailselt
    • Kasutusjuhtude mudel sisaldab kasutusjuhtude teksilist ja graafilist kirjeldamist
    • Kasutusjuhu tekstiline kirjeldus võib olla lühiformaadis, vaheformaadis või laiformaadis.
    • Laiformaadis tuleb kirjeldada peamist äriprotsessi toetava allsüsteemi kõige keerulisemad kasutusjuhud.
    • Laiformaadis kasutusjuhtude põhilise eduka stsenaariumi kohta tuleb teha süsteemi jadadiagramm, millest saadakse kätte süsteemi sündmused ja operatsioonid.
    • Süsteemi operatsioonid tuleb kirjeldada lepingu formaadis (ülesanne disainerile, liides disainiga)
    • Kasutusjuhtude graafiline kirjeldamine hõlmab kasutusjuhtude diagramme ja süsteemi jadadiagramme.
    • Esitada tuleb CASE mudel (n. Enterprise Architect-is tehtud) ja tekstidokument

    SISUKORD (Süsteemianalüüsi ainetöö/projekti jaoks)
    RESÜMEE
    SISSEJUHATUS
  • KASUTATUD METOODIKA
  • Süsteemi tutvustus (äri-, tarkvara-)
  • Metoodika (iteratiivne arendusprotsess UP)
  • Tööriista tutvustus (Enterprise Architect vms)
  • TEHTUD TÖÖ KIRJELDUS (faaside/iteratsioonide kaupa)
  • Algfaas (Visioon ehk terviku ülevaade)
  • Ärimodelleerimise tulemid
    Ärisüsteemi (-teenuse) määratlus ja lühikirjeldus, lausendid ja loetelud
    Eesmärkmudel ja ärikasutusjuhud, äriprotsesside struktuur
    Põhiprotsessi (äriteenuse osutamine) töövoog, tegevusdiagramm
    Üldine kontseptuaalne klassidiagramm
  • Tarkvara nõuete analüüsi tulemid
    Üldine tarkvara kasutusjuhtude diagramm ja lühikirjeldused
    Olulisemad funktsionaalsed ja mittefunktsionaalsed nõuded
  • Järgmise iteratsiooni ( fookuse ) planeerimine
  • Detailimisfaasi (Elaboration) esimene iteratsioon
  • Ärimodelleerimise tulemid
    Iteratsiooni fookuses oleva äriprotsessi (mudelite) täpsustamine
    Täpsustatud kontseptuaalne klassidiagramm
    Põhiobjekti olekudiagramm
  • Tarkvara nõuete analüüsi tulemid
    Iteratsiooni fookuseks oleva põhikasutusjuhu laiformaadis kirjeldus
  • Järgmise iteratsiooni (fookuse) planeerimine
  • Detailimisfaasi teine iteratsioon
  • Ärimodelleerimise tulemid
    Iteratsiooni fookuses oleva äriprotsessi (mudelite) täpsustamine
    Täpsustatud kontseptuaalne klassidiagramm
    Põhiobjekti olekudiagramm
  • Tarkvara nõuete analüüsi tulemid
    Iteratsiooni fookuseks oleva põhikasutusjuhu laiformaadis kirjeldus
    Süsteemi jadadiagramm
    Süsteemi operatsioonide lepingud
  • Järgmise iteratsiooni planeerimine ??
    KOKKUVÕTE JA ARUTELU
    KASUTATUD ALLIKMATERJALID
    LISAD
    Loeng 3. Iteratiivsest arendusprotsessist (Unified Process) täpsemalt. Süsteemianalüüsi (UML) mudeli tükeldamine ja haldamine

    Loengu eesmärk:

    • Defineerida (täpsemalt kui eelmises loengus, kus teema sai esialgselt sisse juhatatud) iteratiivne ja adaptiivne protsess (mille osana me kontseptuaalset süsteemianalüüsi käsitleme)
      • Analüüsi mudeli haldamine iteratiivses arendusprotsessis
    • Toetada harjutustunde

    Kava
    • Intervjueerimisest kui ühest analüüsi tehnikast
    • Valdkonna visiooni esitamiseks kasutatavad mudelid ja notatsioonid
    • Iteratiivsest arendusprotsessist UP (eelmise loengu jätkuna)
      • Analüüsi mudeli haldamine iteratiivses arendusprotsessis

    Intervjueerimisest kui ühest analüüsi tehnikast
    • Suuline versus kirjalik intervjueerimine
    • Intervjuu elutsükkel (Ettevalmistamine -> läbiviimine -> tulemuste analüüs)
    • Intervjuu plaan: eesmärgid, küsimused, rollijaotus
      • Seos Zachmani raamistikuga (milliseid ridu, veerge, lahtreid tahame ’sisustada’? Kuidas küsimused sõnastada?
    • Intervjuu protokoll : protokolli täpsus, mis on oluline, mis mitte?

    Valdkonna visiooni esitamiseks kasutatavad mudelid ja notatsioonid
    Vaata eraldi dokumenti harjutustundides modelleerimise toetamisest loengutes…
    Iteratiivsest adaptiivsest arendusprotsessist (Unified Process) täpsemalt

    Inimesed on tähtsamad kui ükskõik milline protsess.


    Head inimesed koos heade protsessidega mängivad igal ajal üle head inimesed ilma protsessita.

    • Grady Booch

    Hea tiimi võib halva protsessiga ära rikkuda.


    Eesmärgid

    • Defineerida (täpsemalt kui eelmises loengus, kus teema sai esialgselt sisse juhatatud) iteratiivne ja adaptiivne protsess (mille osana me kontseptuaalset süsteemianalüüsi käsitleme)
    • Defineerida UP põhimõisted
    • (Näidata ka alternatiive UP-le)

    Motivatsioon

    Edukate tarkvaraprojektide uuring näitab, et tarkvaraprojektide õnnestumise edufaktorite hulgas on esikohal iteratiivse arendusprotsessi rakendamine.
    Unified Process (UP) on populaarne tarkvara arendamise protsess objektorienteeritud süsteemide ehitamisel .
    Rational Unified Process (RUP) on UP laialt kasutatav detailne peenendus.

    UP põhiidee: iteratiivne arendamine

    … on lähenemine , kus arendamine organiseeritakse lühikeste, fikseeritud pikkusega (n. neli nädalat) miniprojektide seeriatena.
    Neid projekte nimetatakse iteratsioonideks.
    Iga iteratsiooni tulemuseks on testitud , integreeritud, ning täidetav süsteem.
    Iga iteratsioon sisaldab oma nõuete analüüsi, disaini, realiseerimise ja testimise tegevusi.
    Iteratiivne elutsükkel põhineb süsteemi laiendamisele ja peenendamisele läbi paljude iteratsioonide koos tsüklilise tagasiside ja kohandamisega tegelike nõuete rahuldamisele.
    Süsteem kasvab ajas (iteratsioonides) inkrementaalselt, mistõttu lähemist tuntakse ka iteratiivse ja inkrementaalse arendamise nime all.
    Varasemad iteratiivse protsessi ideed on tuntud nimetuste all spiraalne arendamine ja evolutsiooniline arendamine.
    Joonis

    Ühe iteratsiooni näide

    [See näide on võetud C. Larman’i raamatust ”Introduction to Object-Oriented Analysis and Design and UP”. Larmani agiilne käsitlus UP-st ei eelda koodi genereerimist UML mudelitest, vaid koodi kirjutamist programmeerija poolt. Mitmed (R)UP versioonid eeldavad mudelipõhist koodi genereerimist, mis annab disainitööle suurema osakaalu võrreldes käesoleva näitega. Selle loengu käigus tutvustame ka üht iteratiivset ”mitte-UP” ( BizAgi ) arendusprotsessi, mis on täiesti ”mudelipõhine”, s.t. töötav rakendus genereeritakse täielikult mudelitest. ]
    Vaatame ühte võimalikku kahenädalase iteratsiooni näidet projekti keskpaigast:
    Esmaspäev kulutatakse põhiliselt iteratsiooni ülesannete jaotamisele ning nõuete selgitamisele, samal ajal kui üks isik teisendab eelmise iteratsiooni koodi UML diagrammideks (reverse engineering CASE vahendi abil), ning väljastab (prindib, kuvab) antud iteratsiooni jaoks olulisemad diagrammid.
    Teisipäev veedetakse tahvlite juures, tehakse paarisdisaini: joonistatakse UML diagrammide eskiise, mis võetakse üles digitaalkaameratega, ning kirjutatakse mingit pseudokoodi ja disaini märkmeid.
    Ülejäänud kaheksa päeva kulutatakse realiseerimisele, testimisele, disaini täiustamisele, integreerimisele, ehitamisele, süsteemi testimisele ning osasüsteemi stabiliseerimisele. Muud tegevused hõlmavad demosid ja hindamisi koos tellijatega-rahastajatega, ning järgmise iteratsiooni planeerimist.
    Selles näites pole otsekohe kodeerimist ega ka pikaajalist disainifaasi, kus püütaks ajada perfektseks kõik disaini detailid enne programmeerimist. Väikest ettemõtlemist siiski tehakse: visuaalne modelleerimine, kasutades kiireid UML diagrammide eskiise, mida teevad arendajad poole kuni terve päeva jooksul paarisdisainitööna.
    Iga iteratsiooni tulemuseks on täidetav, kuid mittetäielik süsteem. Süsteem ei pruugi olla tootmisse rakendatav paljude iteratsioonide jooksul (näiteks 10 kuni 15 iteratsiooni).
    Iteratsiooni tulemuseks ei ole eksperimentaalne või äravisatav prototüüp.
    Iteratiivne arendamine ei ole prototüüpimine .
    Tulemuseks on tootmiskvaliteediga alamhulk lõppsüsteemist.
    Tavaliselt iteratsioon võtab ette uued nõuded ja laiendab süsteemi inkrementaalselt. Aeg-ajalt võib iteratsioon üle vaadata ka olemasolevat tarkvara ning täiustada seda: näiteks allsüsteemi jõudluse tõstmine ilma uusi omadusi lisamata.

    Muudatuste hõlmamine: Tagasiside ja Kohanemine

    Iteratiivne arendamine ei püüa võidelda vältimatu muudatusega tarkvara arendamisel. Ei püüta täielikult ja korrektselt spetsifitseerida, külmutada ning allkirjastada kogu nõuete hulka ning disaini enne realiseerimist.
    Nõuded on ajas muutuvad (maailm muutub, tellijate-arendajate arusaamine maailmast muutub).
    Iteratiivne arendamine annab muudatuste haldamine ja kohanemise mehhanismi: lühikesed arendussammud (iteratsioonid), iga samm tegeleb nõuete väikese alamhulgaga, varane tsükliline tagasiside, kohanemine muutuvate nõuetega.
    Iteratiivne arendamine pole kontrollimatu reaktiivne protsess, kus mittekriitiliselt reageeritakse kõigile tellija tahtmistele. Ta on kesktee nõuete külmutamise ja kontrollimatu reageerimise vahel.
    Töö toimub läbi ehitamise-tagasiside-kohandamise struktuursete tsüklite seeria. Varsemates iteratsioonides on kõrvalekalle süsteemi “õigest teest” ( otsetee lõplike nõuete ja disaini suunas) suurem kui hilisemates iteratsioonides. Aja jooksul süsteem koondub kõige sobivamate nõuete ja disaini suunas.
    Hilistes iteratsioonides on oluline muutus nõuetes harvaesinev, kuid seda võib juhtuda – hilised muudatused võivad anda organisatsioonile konkurentsieelise.

    Iteratiivse arendamise plussid

    … on:
    • Kõrgete riskide varane leevendamine
    • Varane nähtav progress
    • Varane tagasiside, kasutaja kaasahaaramine, kohandamine viib täpsustatud süsteemini, mis vastab paremini tellijate tegelikele vajadustele
    • Hallatud keerukus : meeskond pole halvatud “analüüsi paralüüsiga” või väga pikkade ja keerukate arendussammudega
    • Õppimist iteratsiooni käigus saab metoodiliselt kasutada arendusprotsessi enese täiustamiseks, iteratsioonist iteratsiooni

    Iteratsiooni pikkus ja ajaraamid

    UP soovitab iteratsiooni pikkuseks kaks kuni kuus nädalat.
    Pikad iteratsioonid rikuvad motivatsiooni iteratiivseks arendamiseks ja suurendavad projekti riski (keerukus liiga suur, tagasiside liiga hilja ). Vähem kui kahe nädalaga on raske lõpetada piisavalt tööd, millelt saaks olulist tagasisidet.
    Iteratsioonid on fikseeritud pikkusega (n. neli nädalat, meeskonnasisene kokkulepe). Tähtaja nihutamine on keelatud. Kui tähtajast kinnipidamine osutub raskeks, soovitatakse vähendada ülesandeid või nõudeid antud iteratsioonis, tõsta nad järgmisse iteratsiooni.
    Väga suured meeskonnad (mitu sada arendajat) võivad erandina lubada pikemaid iteratsioone (neli kuni kuus kuud). Ka siin saab dekomponeerida väiksemateks allsüsteemideks.


    Veel parimaid praktikaid ja mõisteid UP-s

    • Kõrge riskiga ja kõrge väärtusega probleemide käsitlemine varastes iteratsioonides
    • Pidevalt haaratakse kasutajaid hindamisse, tagasisidesse ja nõuete analüüsi
    • Ehitatakse kooskõlaline tuumarhitektuur varastes iteratsioonides
    • Pidev kvaliteedikontroll: testitakse varakult, sageli ja realistlikult (test-driven lähenemise korral kirjutatakse/realiseeritakse testid enne põhifunktsionaalsusi)
    • Rakendatakse use case-e
    • Modelleeritakse tarkvara visuaalselt (UML)
    • Hoolikalt hallatakse nõudeid-vajadusi
    • Tehakse muudatusnõudeid ja konfiguratsioonijuhtimist

    UP faasid ja planeerimisega seotud mõisted

    UP projekt organiseerib tööd ja iteratsioonid nelja põhifaasi:
  • Inception (algfaas) – ligikaudne visioon, business case (kas tasub investeerida järgmisse faasi?), skoop, esialgsed ebatäpsed hinnangud (aeg, raha,..).
  • Elaboration ( viimistlemine ) – peenendatud visioon, tuumarhitektuuri iteratiivne realiseerimine , kõrgete riskide lahendamine, enamuse nõuete ja skoobi identifitseerimine, realistlikumad hinnangud.
  • Construction – ülejäänud madalama riskiga ja kergemate elementide iteratiivne realiseerimine, rakendamiseks ettevalmistumine
  • Transition ( siire , üleviimine) – beeta testid, rakendamine
    Tegemist ei ole vana jadaarenduse (kose) mudeliga, kus esmalt defineeritakse kõik nõuded siis tehakse enamus disainist jne.
    Inception ei ole nõuete analüüsi, vaid pigem teostuvuse (feasibility) analüüsi faas, kus tehakse lühike, kuid piisav uuring jätkamise või lõpetamise otsuse toetamiseks.
    Elaboration pole nõuete ega disaini faas, vaid pigem tuumarhitektuuri iteratiivse realiseerimise faas, kus leevendatakse kõrged riskid .
    Joonis
    UP distsipliinid (vanasti töövood)
    Distsipliin on (arendus)tegevuste (ülesannete) ja nendega seotud “asjade” (artifacts) hulk ühes probleemvaldkonnas.
    Artifact on üldmõiste igasuguse tööprodukti kohta: kood, Web graafika , andmebaasiskeem, tekstidokument, diagramm, mudel,…
    UP käsitleb järgmisi distsipliine:
    • Ärimodelleerimine (business modelling) – kui arendatakse üksikut rakendust, sisaldab (rakendus)valdkonna (domeeni) objektmodelleerimist. Ulatuslikus ärianalüüsis või äriprotsesside ümberkorraldamises sisaldab äriprotsesside dünaamika modelleerimist üle terve ettevõtte.
    • Nõuded (requirements) – nõuete-vajaduste analüüs rakenduse jaoks: use case-ide kirjutamine ning mittefunktsionaalsete nõuete identifitseerimine..
    • Disain – kõik disaini aspektid: arhitektuur, objektid, kasutajaliidesed, andmebaasid , võrgud jne..
    • Realiseerimine (implementation) – süsteemi programmeerimine ja ehitamine, mitte rakendamine
    • Testimine –
    • Rakendamine (deployment) –
    • Muudatuste ja konfiguratsiooni haldamine –
    • Projektijuhtimine -
    • Keskkond (environment) – arendusvahendite ( tööriistad ) ja protsessi keskkonna seadistamine projekti jaoks

    Joonis (UP põhiraamistik, vaata eestpoolt )


    Suhteline jõupingutus distsipliinides muutub ajas ning on eri faasides erinev.

    Protsessi häälestamine ja arendusjuhtum

    Kõik UP tegevused ja artifactid (v.a. kood?) on mittekohustuslikud.
    Võrdlus apteegitäie ravimite ning konkreetse haigusega.
    Tegele väheste, kuid kasulike asjadega, sõltuvalt projekti tüübist (uus arendus, olemasoleva süsteemi integreerimine,..) ja arendusjuhtumist (konkreetsest objektist, ülesandest).
    UP artifactide valik projekti jaoks kirjutatakse lühikesse dokumenti nimega Development Case (järgnev table):

    Tabel (sarnaneb eespoololeva UP põhiraamistiku tabeliga; veerud on iga iteratsiooni kohta; lahtritesse kirjutatakse artifaktide nimetused, mida konkreetse iteratsiooni vastavas distsipliinis toodetakse; iga iteratsiooni lõppedes tabel “kirjutatakse üle” vastavalt lõppenud iteratsioonis tegelikult tehtule ja muutunud plaanidele tulevaste iteratsioonide kohta)


    Agiilne UP

    Metodoloogid klassifitseerivad protsesse järgmiselt:
    • Rasked (heavy) vs kerged ( light ) protsessid
    • Ettekirjutavad (predictive) vs. kohanevad ( adaptive ) protsessid

    Rasked protsessid on järgmiste omadustega:
    • Palju artifacte, mis luuakse bürokraatlikus atmosfääris
    • Rangus ja kontroll
    • Viimistletud pikaajaline detailplaneerimine
    • Pigem ettekirjutav kui kohanev

    Ettekirjutav protsess üritab planeerida ning ette kirjutada tegevusi ning (inim) ressursside omistamist detailselt suhteliselt pika ajaperioodi (suurem osa projektist) kohta;
    .. kasutab tavaliselt kose mudeli (mitte iteratiivset) elutsüklit: esmalt defineeritakse kõik nõuded, teiseks defineeritakse detailne disain, kolmandaks realiseeritakse.
    Kohanev (adaptiivne) protsess käsitleb muutust kui vältimatut paratamatust, millega on tarvis paindlikult kohaneda. Kasutatakse tavaliselt iteratiivset elutsüklit.
    Agiilne protsess rakendab kerget ja kohanevat protsessi, mis reageerib muutuvatele nõuetele.
    UP pole selle autorite poolt mõeldud raske ega ettekirjutavana, kuigi lai mittekohustuslike tegevuste ja artifactide hulk võib tekitada sellise mulje.
    Ta on mõeldud rakendamiseks agiilse protsessi vaimus (agiilne UP):
    • Eelista väikest hulka UP tegevusi ning artifacte (sõltuvalt projektist). Ära aja asja liiga keeruliseks;
    • Kuna UP on iteratiivne, siis nõudeid ja disaini ei lõpetata enne realiseerimist. Nõuded ja disain kasvavad adaptiivselt läbi iteratsioonide, kasutades tagasisidet;
    • Pole olemas detailset plaani kogu projekti jaoks. On kõrgtaseme plaan (faasiplaan) suurte verstapostide hindamiseks, kuid see ei täpsusta väiksemaid samme nende verstapostide jaoks. Detailplaan (iteratsiooniplaan) tehakse adaptiivselt igas iteratsioonis ning vaid ühe iteratsiooni jaoks ette.

    Klassikaline jadaarendustsükkel (kose mudel)

    … ( kontrastiks iteratiivsele arendustsüklile) omab järgnevaid põhisamme:
  • Defineeri täielik hulk nõudeid ja külmuta need;
  • Disaini süsteem nende nõuete alusel;
  • Realiseeri disaini alusel.

    Sa ei ole UP-st aru saanud juhul kui…

    • Mõtled, et inception = nõuete analüüs, elaboration = disain, construction = realiseerimine (s.t. rakendad “kose” elutsüklit UP-le)
    • Mõtled, et elaboration-i eesmärgiks on täielikult ja detailselt defineerida mudelid, mis teisendatakse koodiks konstrueerimise faasis
    • Püüad defineerida enamikku nõuetest enne disaini või realiseerimise alustamist;
    • Püüad defineerida enamust disainist enne realiseerimise alustamist; püüad täielikult defineerida ja lõpetada arhitektuuri enne iteratiivset programmeerimist ja testimist
    • Pikk aeg kulutatakse nõuete või disaini tööle enne programmeerimise alustamist
    • Usud , et kasulik iteratsiooni pikkus on pigem neli kuud kui neli nädalat
    • Arvad , et UML diagrammide koostamine ja disain on aeg täielikult ning detailselt defineerida disain ja mudelid, ning programmeerimine on nende mehaaniline teisendamine koodiks
    • [ erandiks on mudelitega juhitavatel arhitektuuridel – Model Driven Architecture (MDA) põhinevad (R)UP versioonid, kus UML-i kasutatakse programmeerimiskeelena, mitte üksnes disainikeelena nagu käesolevas näites]
    • Arvad, et UP kasutamine tähendab teha palju võimalikke tegevusi ja luua palju dokumente, et UP on formaalne “askeldav” protsess, mis sunnib järgima paljusid samme
    • Üritad planeerida projekti detailselt algusest kuni lõpuni, spekulatiivselt ette näha kõiki iteratsioone ning neis toimuvat
    • Tahad uskuda plaane ja hinnanguid projektidele enne kui elaboration faas on lõpetatud .

    Üks ”mitte-UP” iteratiivse arendusprotsessi näide:
    BizAgi ”Business/Process Driven” täielikult mudelitega juhitav arendus
    Märksõnad: protsessikeskne (mitte objektorienteeritud), mitte-UML (BPMN)
    www.bizagi.com
    Üks õppimistsükkel ehk arendusiteratsioon koosneb siin järgmistest sammudest:
  • Modelleeri Protsess
  • Modelleeri Andmed
  • Kirjelda kasutajaVormid
  • Defineeri Ärireeglid
  • Omista Ressursid (Inimesed)
  • Ühenda pärandsüsteemidega ( veebiteenused )
  • Verifitseeri protsess
  • Genereeri rakendus
  • Kasuta ja hinda rakendust
    Sarnased (objektorienteeritud, UML) mudelitega juhitavad variandid on olemas ka (R)UP-st.
    Küsimus/Ülesanne: kus asub ja milline on kontseptuaalse süsteemianalüüsi osa kahes tänases loengus käsitletud erinevas iteratiivse protsessi (UP, BizAgi) näites. Kas viimases näites on kõik Zachmani raamistiku veerud (küsimused) kaetud?
    Loeng 5 ja 6. Ärimodelleerimine, ärimudel (business model), ärisüsteemi kontseptuaalne analüüs (ärianalüüs)

    Eesmärgid


    • Rakendada kontseptuaalset süsteemianalüüsi ärisüsteemidele
    • Defineerida ärimudeli mõiste (UP vastava distsipliini põhitulem)
    • Käsitleda UP ärimodelleerimise distsipliini (ühena kahest “puhtast” analüüsidistsipliinist UP-s)
    • (1.Toetada harjutustunde: mõtestada harjutustundides seni tehtud tööd ’Konverentsisüsteemi’ teemal – vt. järgnevat joonist)

    Taust

    Ärimudeli (business model) mõistel on erialakirjanduses kaks erinevat tähendust:
  • Mudel selle kohta, kuidas äriüksus (n. ettevõte) teenib raha (või laiemalt – loob väärtust)
  • Äriüksuse (n. ettevõtte) toimimise kirjeldus
    Meie läheneme ärimudeli mõistele arhitektuuri mõiste kaudu nii, et:
    • Ärimudel on ärisüsteemi arhitektuuri kirjeldus
    • Ühte ja sama (äri)arhitektuuri kirjeldatakse erinevatele huvigruppidele erinevates vaadetes
    • Ettevõtte äripoole jaoks on ärimudel pigem mudel selle kohta, kuidas ettevõtte teenib raha
    • Ettevõtte IT poole jaoks on ärimudel pigem ettevõtte toimimise kirjeldus, mida kasutatakse sobivate IT lahenduste loomise lähtepunktina.


    Ärimodelleerimine, ärimudel (business model)

    Äriarhitektuuri kirjeldus

    Kontseptuaalne (meta)mudel

    Järgnevalt defineerime ärimudeli mõiste ärisüsteemi ja äriarhitektuuri mõistete kaudu, kasutades tarkvaramahukate süsteemide arhitektuuri üldist soovituslikku standardit, täpsemalt selle standardi põhimõisteid ning nende seoseid illustreerivat kontseptuaalset ( meta )mudelit, millest tulenevalt:
    Ärimudel = Ärisüsteemi arhitektuuri (ehk äriarhitektuuri) kirjeldus
    Joonis: Äriarhitektuuri kirjelduse kontseptuaalne mudel UML kontekstis
    Sellel joonisel äriarhitektuuri kirjeldus on ärimudel (edaspidi on neid kaht mõistet kasutatud samas tähenduses).
    Ärimudel võib omada erinevat tähendust erinevate inimeste jaoks. Äriinimeste jaoks tähendab ärimudel kirjeldust, mis näitab, kuidas ettevõte loob kasu ja tulu ning samuti kirjeldab ettevõtte turusegmenti, positsiooni turul, konkurentsivõimet, rentaablust, kliendile loodavat väärtust jne.
    Infotehnoloogia valdkonna inimesed mõistavad ärimudelit kui ettevõtte toimimise kirjeldust, mis on neile vajalik ettevõtte tähtsamatest olemitest arusaamiseks enne, kui hakatakse ehitama teda toetavat infosüsteemi.
    Ärimudeli võib defineerida kasutades UML standardis olevat mudeli definitsiooni ning asendades füüsilise süsteemi mõiste ärisüsteemi mõistega :
    Ärimudel on ärisüsteemi arhitektuuri kirjeldus kindlal eesmärgil. Ta kirjeldab äriarhitektuuri kindla(te)st vaatenurga(de)st, mis on valitud lähtudes kindla(te)st huvirühmaliigi(de)st ja nende huvidest; ja kindlal abstraktsioonitasemel. Ärimudel on täiuslik, kui ta katab kogu ärisüsteemi antud vaatenurgast ja valitud abstraktsioonitasemel.
    Näiteks, haigla laboratooriumi ärimudel näitab, mida laboratoorium teeb selleks, et saavutada püstitatud eesmärke (missiooni). [ Muuhulgas peab ärimudel näitama ka seda, kuidas laboratoorium „teenib raha“]
    See hõlmab labori organisatsioonilist struktuuri (nagu näiteks struktuurüksused, asukohad, töötajate rollid, aruandluse ja alluvuse suhted jne.), labori klientidele (arstidele) pakutavaid teenuseid ( uuringuid ), teenuste arendust ja hinnakujundust, teenuste realiseerimise protsesse, väliskeskkonda (nagu näiteks tarnijad , reguleerivad ametid), jne.
    Haigla laboratooriumi ärimudel kirjeldab neid aspekte huvitatud osapooltele.
    MIKS ON VAJA ÄRIMUDELIT?
    • Äri toimimise (sealhulgas raha teenimise) mehhanismi mõistmine. Ärimudeleid saab kasutada inimeste koolitamiseks, andes neile arusaamise nende rollidest ja tööülesannetest terves organisatsioonis
    • Äri (protsesside, struktuuri ja personali) ümberkorraldamine. Selleks, et korraldada ümber äri, on esialgu vaja mõista, kuidas äri toimib praegu. Selle arusaamise annab ärimudel. Mudel näitab muutusi, mida on vaja läbi viia selleks, et täiustada ärimudelit (’as-is’ -> ’to-be’).
    • Äriprotsessi efektiivsuse tõstmine. Siin on eesmärgiks ratsionaliseerida ja/või tõsta konkurentsivõimet kriitilistes äriprotsessides.
    • Äriprotsessi automatiseerimine. See juhtum on seotud tarkvara arendamisega. Eesmärgiks on vähendada protsessi ressursside vajadust, võimaldades temal toimuda ilma inimese sekkumiseta. Selles kontekstis võimaldavad ärimudelid saada aru keskkonnast, milles hakkab toimima tarkvara. Samuti saadakse ärimudelist tuleviku infosüsteemi tarkvara nõudeid. Ideaaljuhul saab ärimudeli suuremat osa teisendada otse infosüsteemi mudeliks.

    Millises mahus ärimodelleerimisele keskendutakse, sõltub tugevasti ärimudeli eesmärgist. Kui eesmärk on mõista ärisüsteemi piisavalt hästi selleks, et luua teda toetavat infosüsteemi tarkvara, siis ei ole vajalik modelleerida äri väga põhjalikult ja detailselt. See oleks liiga aeganõudev ja kallis tegevus. Vastupidi, kui eesmärk on äri ümberkorraldamine, siis on vajalik detailsem ja täpsem modelleerimine.

    Ärisüsteemi kontseptid

    Kõige lihtsamaks ärisüsteemi analüüsimise viisiks oleks käsitleda teda “musta kastina”. Ettevõttel oleksid mingid sisendid (nagu näiteks tarnijad, toormaterjal), mingid väljundid kliendile tarnitavate toodete või teenuste näol ning muud mõjurid nagu seadusandlus .
    Kuid tüüpilised ärisüsteemid ei eksisteeri isoleerituna teistest süsteemidest, ning paljud tähtsad elemendid asuvad väljaspool äri ja pole defineeritud ettevõtte poolt. Seetõttu on otstarbekas käsitleda ettevõtet avatud süsteemina , kus vaadeldakse täiendavalt äritegevuse läbiviimist ettevõtte sees ning nähakse, millised süsteemi osad on seejuures seotud väliskeskkonnaga . Kuigi erinevatel ärisüsteemidel on erinevad eesmärgid ja struktuur, siiski nad kasutavad sarnaseid mõisteid oma struktuuri ja tegevuste kirjeldamiseks (joonis):
    • Äriprotsess on tegevuste kogum, mis võtab ühe või mitu sisendit ning, teisendades neid, loob kliendile väärtust omava väljundi. Seejuures võib kliendiks olla väline või sisemine klient või teine protsess. [DARNTON97]
    • Äriprotsess on seotud ühe või mitme eesmärgiga. Protsessi eesmärgid on seotud organisatsiooni eesmärkidega, mis omakorda kujundavad organisatsiooni strateegiat. Kokkuvõttes püüavad kõik äriprotsessid saavutada ettevõtte strateegilisi eesmärke. Iga eesmärk võib koosneda alameesmärkidest, mille täitmist takistavad probleemid.

    Joonis Ärisüsteemi kontseptid [JAKOWSKI03]
    • Äriprotsess kasutab sisendina üht või mitut ressurssi ning, teisendades või tarbides neid, loob uue või teisendatud väljundressursi. Ressursid võivad olla toodetud teiste organisatsioonide (nagu näiteks partnerid , tarnijad) poolt.
    • Väljundressurss väljendab protsessi eesmärgi täitmist. Ühe protsessi väljund võib olla sisendiks teisele protsessile. Väljund omab väärtust sisemisele või välisele kliendile.
    • Ärireegel on väide, mis kontrollib äriprotsesside teostamist, mõjutab organisatsiooni struktuuri ja tema resursse ning piirab täitjate käitumist. Mõned ärireeglid täpsustavad eesmärke. Ärireeglid võivad viidata üksteisele.
    • Äriprotsessid on määratud mitte äritöötajatele, vaid ettevõtte struktuurüksustele. Äriprotsessi eest vastutab vähemalt üks struktuurüksus (protsessi omanik). Üldjuhul läbib äriprotsess mitut osakonda, kuid ta võib ületada ka organisatsiooni piire .
    • Sündmus, mis tekkib organisatsiooni sees või väljaspool, võib mõjutada mitut äriprotsessi. Äriprotsess võib ka ise genereerida sündmusi.
    • Äriprotsessi võib tükeldada hierarhiliselt elementaarsete äriprotsessideni. Kõige detailsemaks modelleerimise tasemeks on tegevuste tase. Tegevus on protsess, mis täidetakse ühes kohas, ja mis lisab ärile olulist väärtust [MCSHEFFREY01]. Tegevust ei saa tükeldada alamprotsessideks. Iga tegevus on planeeritud või organiseeritud töö ning on määratud ühele või mitmele täitjale, kes võib töötada mitme ressursiga.
    • Täitjaks võib olla töötaja või automaat /masin. Tegevused realiseerivad äriprotsessi. Kuna tegevused on äriprotsesside realiseerimise sammud, siis neid võib iseloomustada samal viisil, kui äriprotsesse , kuid detailsemal tasemel.

    Äriprotsessid alluvad (ka) järgmisele metamudelile: (List ja Korherr 2005)
    Joonis: Äriprotsessi kontseptuaalne metamudel
    Äriprotsess koosneb ühest või enamast alamprotsessist. Äriprotsess on kas põhiprotsess, abiprotsess või juhtimisprotsess.
    Põhiprotsessi eesmärgiks on välise kliendi vajaduse rahuldamine. Abiprotsess toetab põhiprotsessi. Abiprotsessi eesmärgiks on sisemise kliendi vajaduse rahuldamine. Juhtimisprotsessi eesmärgiks on sisemise kliendi vajaduse rahuldamine.
    Iga äriprotsessi eest vastutab konkreetne protsessi omanik. Äriprotsessi kirjeldab detailne protsessidiagramm.
    Iga Äriprotsess peab saavutama ühe või mitu protsessi eesmärki mis peavad toetama organisatsiooni põhieesmärki. Igal äriprotsessil on tulemus, mis on kas toode või teenus. Iga eesmärk on mõõdetav. Eesmärgi mõõt võib olla kvalitatiivne või kvantitatiivne . Mõõtu iseloomustavad ühik ja suurus.



    UML ja ärimodelleerimine

    Ärimodelleerimist iseloomustab fakt, et tänapäeval ei eksisteeri ühtki juhtivat või domineerivat ärimodelleerimise keelt. See on tugevas kontrastis tarkvara modelleerimisega, kus faktiliseks standardiks on UML. Tänapäeval modelleeritakse tihti tarkvara ja ärisüsteemid erinevate notatsioonidega. See põhjustab raskesti täidetavat metodoloogilist lünka nende mudelite vahel. Probleem muutub eriti keeruliseks siis, kui üritatakse luua ärimudelit toetavat tarkvara, aga puudub sujuv üleminek teisele notatsioonile. Ärimodelleerimise keelele esitakse järgmised nõuded:
    • Notatsioon peab väga lakooniliselt väljendama põhisemantikat
    • Ta peab olema kergelt loetav ka mittetehnilistele inimestele
    • Ei pea kulutama palju aega semantika ja süntaksi õppimisele.
    Kuigi UML oli esialgselt loodud kui tarkvara modelleerimise keel, siiski paljud uurimustööd on näidanud, et UML-i saab kasutada ka mittetarkvara valdkondades, seal hulgas ka ärisüsteemide modelleerimiseks.
    Üheks tähtsamaks argumendiks UML kasutamisele ärimodelleerimiseks on see, et samu mõisteid (arhetüüpe) saab kasutada nii äri- kui ka teda toetava infosüsteemi modelleerimiseks. Ühise keele kasutamine soodustab kommunikatsiooni äri ja IT inimeste vahel. Samuti toetab ta tarkvara spetsifikatsiooni kvaliteeti, kuna kaob vajadus teisendada mudelit teisesse modelleerimise keelde, vähendades sellega potentsiaalsete vigade allikaid .
    Kuna esialgselt oli UML loodud kui objekt-orienteeritud tarkvara modelleerimise keel, siis temas (UML tuumas ehk standardis) polnud otseselt ette nähtud ärimodelleerimise mõisteid. Eelkõige kritiseeriti teda äriprotsesside kirjeldamise ja detailiseerimise võimaluste puudumise tõttu. Alates UML keele versioonist 2.0 on seal olemas ärimodelleerimiseks vajalikud baasmõisted ja –tehnikad.
    UML-i tugevaks küljeks on tema laiendatavuse võimalused, mis võimaldavad defineerida omi diagrammitüüpe ja sümboleid. See annab modelleerijale võimalust adapteerida UML vastavalt oma vajadustele ilma UML metamudelit muutmata.
    Paljud teised ärimodelleerimise keeled on väga tüpiseeritud ning ei luba mudeli elementide semantika muutmist. Kuigi ilma standardit muutmata või sellest kõrvale kaldumata ei saa lisada uusi elemente, saab kõiki UML olemasolevaid elemente laiendada kasutades kolme võimalust: stereotüübid , märgendväärtused ja piirangud. UML laiendused organiseeritakse tavaliselt UML profiilidena. Eksisteerib mitmeid erinevaid UML profiile spetsiaalselt ärimodelleerimise jaoks.

    UML ärimodelleerimise tehnikad

    Tänapäeval on olemas kaks põhilist UML ärimodelleerimise tehnikat : äriprotsessikeskne ja ärikasutusjuhukeskne.
    Äriprotsessikeskne modelleerimine on laialt tunnustatud meetod äriarhitektide poolt. See kasutab traditsioonilist protsesside modelleerimise tehnikat, kasutades selleks UML tegevusdiagrammi. Näiteks, Eriksson -Penkeri notatsioon kasutab protsessikeskset ärimodellerimise tehnikat.
    Ärikasutusjuhukeskne modelleerimine on suhteliselt uus tehnika, mis on laiendanud süsteemi kasutusjuhu mõistet ning kasutab kasutusjuhtude diagrammi äriprotsesside modelleerimiseks. Siinkohal on ärikasutusjuhtu loetud praktiliselt samaväärseks äriprotsessi mõistega. Selleks, et eristada tarkvara ja ärisüsteemi modelleerimisel kasutatavaid sümboleid, on kasutatud stereotüüpe (joonis 4-3). Näiteks, seda tehnikat kasutab Rational unifitseeritud protsess (Rational Unified Process).
    Joonis Ärikasutusjuhukeskse modelleerimise notatsioon
    Kumba eelistada, sõltub ilmselt süsteemiarendusega seotud inimeste harjumustest või kasutatavast modelleerimise metoodikast.

    Sõnaline modelleerimine

    Vaatamata eelpool loetletud eelistele on UML keelel mitmeid puudusi [ARLOW03]:
    • Mudelis sisalduv informatsioon on kättesaadav vaid neile, kes teavad UML süntaksit ja semantikat.
    • Mida tehnilisem on mudel, seda raskem on sellest aru saada mittetehnilistele inimestele.
    • Mudeli kasutajale on samuti vaja teada, kuidas töötada modelleerimise vahendiga.
    • Tihtipeale on raske aru saada, kust alustada mudeli lugemist
    • Informatsioon, mis on väljendatud visuaalse modelleerimise keelega, muutub tihti märkamatuks mudelis. Isegi modelleerimise keele asjatundjale võib olla raske saada kätte mudelist ärinõudeid.
    UML kritiseeritakse ka selle eest, et ta on liiga tehniline keel. [ARLOW03] hindas UML mudelite arusaadavust (asjaosaliste võimet aru saada mudeli semantikast) ja kättesaadavust (nende võimet pääseda mudeli informatsiooni juurde). Selgus, et mittetehniliste inimeste arusaamine väheneb, kui UML diagrammide fookus nihkub ärinõuetest realiseerimise detailidele. Teiste sõnadega, nad saavad aru kasutusjuhtude diagrammidest, kasutusjuhtude spetsifikatsioonist, äriprotsesside tegevusdiagrammidest ja kontseptuaalsetest klassidiagrammidest, kuid nende arusaamine UML jadadiagrammidest, koostöödiagrammidest ja olekudiagrammidest (?!) on väike.
    Nende probleemide lahenduseks pakub välja [ARLOW03] sõnalise modelleerimise meetodi, mis ühendab visuaalse modelleerimise keele ja loomuliku keele häid omadusi. Sõnalise modelleerimise põhimõte seisneb selles, et UML mudelile lisatakse ärikonteksti dokument, mis on kirjutatud jutustuse vormis. Koos moodustavad nad sõnalise mudeli ( joonis 4-4). Siin on olemas analoogia meie ainetööga, kus nõutakse samuti UML mudelit (.mdl) ja tekstidokumenti, mis kopeerib sobivatesse kohtadesse sobivaid UML mudeli osi või viitab neile osadele.
    Joonis Sõnaline mudel [ARLOW03]
    Sõnalise modelleerimise idee pärineb sõnalisest programmeerimisest [LP], mis kombineerib dokumentatsiooni ja lähtekoodi nii, et see on inimestele kergelt loetav.
    Ärikonteksti dokument selgitab UML mudelit ärikonteksti valguses. Ta seletab mudeli loogilisi põhiprintsiipe sellisel kujul, mis on arusaadav ka äriinimestele, tõstab esile tähtsaid ärinõudeid, seab vastavusse konkreetseid mudeli detaile tähtsate ärinõuetega ja selgitab, kuidas ärinõuded ja kontekst on põhjustanud spetsiifilisi modelleerimise lahendusi.
    Sõnalise mudeli eeliseks on see, et ta on kättesaadav laiale kasutajate ringile. Isegi need, kes ei tea kasutatud visuaalset modelleerimise keelt või ei oska kasutada modelleerimise vahendeid, saavad lugeda sõnalist mudelit tänu ärikonteksti dokumendile. Sõnaline modelleerimine võimaldab dokumenteerida äriteadmust UML diagrammidesse.
    Loeng 7 ja 8. Ärimodelleerimisest täpsemalt: kahe metoodika tutvustamine ja võrdlus (meditiinilabori näitel)

    Eesmärgid


    • Õpetada meie ainetöös kasutatavat (ärikasutusjuhtude keskset) ärimodelleerimise metoodikat läbi konkreetsete näidete (MedLabor, Deklareerimine)
    • Tutvustada ka ühte teistsugust (äriprotsessikeskset Eriksson-Penkeri) metoodikat
    • Õpetada senistes loengutes käsitlemata notatsioone ja modelleerimistehnikaid
    • Toetada harjutustunde
    • Valmistuda esimeseks kontrolltööks

    Taust

    Eelmises loengus rääkisime ärimodelleerimise olemusest, eesmärkidest ja põhimõistetest.
    Eristasime äriprotsesside (tegevusdiagrammide) ning ärikasutusjuhtude (ehk funktsionaalsete ärieesmärkide) keskseid lähenemisi ärimodelleerimisele.
    Seekord vaatame täpsemalt ühte äriprotsesside (tegevusdiagrammide) keskset metoodikat ( Erikson -Penker’i metoodika) ja ühte ärikasutusjuhtude (ehk funktsionaalsete eesmärkide) keskset metoodikat (näidismetoodika meie ainetöö läbiviimiseks).

    Ärimudeli vaatenurgad

    Äriarhitektuuri kirjeldus peab olema organiseeritud üheks või mitmeks vaateks. Iga vaade keskendub ärisüsteemi kindlatele aspektidele ning on koostatud mingite graafiliste diagrammidena ja/või tekstiliste kirjeldustena. Tarkvaramahukate süsteemide arhitektuuri standardid (IEEE Std. 1471 -2000 ; ISO/IEC CD1 42010 http://www.iso.ch ) ei määra vajalike vaatenurkade hulka, jättes selle ülesande konkreetsetele arendusmetoodikatele. Käesoleva loenguosa eesmärgiks on kirjeldada/modelleerida tüüpilisi äriarhitektuuri vaatenurki – eesmärgi-, protsessi-, struktuuri- ja käitumisvaatenurka – vastavalt IEEE standartile, mis määrab, missugustest osadest peab koosnema iga (ükskõik millise) vaatenurga definitsioon. Need vaatenurgad on valitud sellepärast, et nad võimaldavad kirjeldada äri üldiseid aspekte ning sobivad hästi kokku UML võimalustega. Kuid igal konkreetsel äriarhitektuuri kirjelduse koostamisel sõltub vaatenurkade valik eelkõige huvirühmadest ja nende huvidest kirjelduse suhtes. Nii võib äriarhitektuuri kirjeldus sisaldada selliseid vaateid, nagu näiteks kultuurivaade, inimressursside vaade jne. Vaatenurkade deklaratsioonid on esitatavad järgmise malli järgi:
    1. Kirjeldus annab ülevaate konkreetst vaatenurgast.
    2. Huvirühmad ja huvid loetleb huvirühmi, kellele on suunatud see vaatenurk, ja nende huve, mida katab antud vaatenurk.
    3. Modelleerimise meetodid loetleb modelleerimise meetodeid ja diagrammi tüüpe, mis kasutatakse vaate visualiseerimiseks. Vajadusel seletab keele notatsiooni, kasutatavaid keele (n. UML) laiendusi jmt.
    Näide A: Haigla laboratooriumi ärimudel (Eriksson-Penkeri „äriprotsessikeskse“ metoodika järgi)
    [näide B esitab sama ärimudeli meie ainetöös kasutatava „ärikasutusjuhtude keskse“ arendusmetoodika järgi“]
    1 Ülevaade
    Käesolevas loenguosas esitatakse ühe haigla laboratooriumi ärimudeli näide. Laboratoorium on haigla allüksus, mistõttu toimub osa administratiivsetest protsessidest (nt. finantside haldamine, personali haldamine jne.) haigla pool ja ei kajastu selles näites. Ärimudel on koostatud vastavalt IEEE Std.1471-2000 ning ISO/IEC CD1 42010 standardile, mis määrab igasuguse arhitektuuri kirjelduse sisu (ärimudel on meil eelnevalt defineeritud kui ärisüsteemi arhitektuuri ehk äriarhitektuuri kirjeldus). Ärimudeli konkreetsete vaatenurkade valikul ja kirjeldamisel on aluseks võetud Eriksson-Penkeri („äriprotsesside/tegevusdiagrammide keskse) ärimodelleerimise metoodika ja notatioon.
    2 Huvirühmad ja huvid
    Huvirühmad, kes tunnevad huvi haigla laboratooriumi ärimudeli vastu, võib jagada kaheks grupiks:
    • Arendajad: äriarhitekt, andmete arhitekt, rakenduste arhitekt ja tehnoloogia arhitekt
    • Kasutajad: sekretär, assistent , laborant , tehnoloog ja labori juhataja.
    Järgmine tabel näitab, missugused huvid on igal huvirühmal ärimudeli suhtes, ning missugused ärimudeli vaated katavad neid huve:
    Huvirühm
    Huvi
    Vaatenurk
    Äriarhitekt,
    kasutajad
    Kas iga kasutaja eesmärgid ja probleemid on võetud arvesse?
    Eesmärgivaatenurk
    Kas igale kvantitatiivsele eemärgile on leitud sobiv mõõdik?
    Eesmärgivaatenurk
    Kas kõik vastuolud eesmärkide vahel on märgitud?
    Eesmärgivaatenurk
    Kas iga kasutaja põhikontseptid ja nendevahelised seosed on leitud?
    Eesmärgivaatenurk
    Kas on arvestatud igasse kasutajasse puutuvate ärireeglitega?
    Eesmärgivaatenurk
    Protsessivaatenurk
    Struktuurivaatenurk
    Käitumisvaatenurk
    Kas on kirja pandud kõik labori huvirühmad ja nende huvid?
    Protsessivaatenurk
    Kas igale kasutajale on leitud protsessid, kus ta osaleb või mida ta kontrollib?
    Protsessivaatenurk
    Kas on määratud kõik ressurssid, mida kasutaja vajab või pakub teistele?
    Protsessivaatenurk
    Kas on leitud kõik sündmused, millele peab kasutaja reageerima ?
    Protsessivaatenurk
    Käitumisvaatenurk
    Kas igale kasutajale on leitud ressurssid, mida ta omab või haldab?
    Struktuurivaatenurk
    Kas ressurssi struktuur on määratud õieti?
    Struktuurivaatenurk
    Kas on märgitud kõik kasutaja toimingud (reaktsioonid) ärisündmusele?
    Käitumisvaatenurk
    Kas on õieti määratud tegevused, mida kasutaja teostab ressurssidega?
    Käitumisvaatenurk
    Andmete arhitekt
    Missugused on labori eesmärgid?
    Eesmärgivaatenurk
    Missugused probleemid takistavad eesmärkide saavutamist?
    Eesmärgivaatenurk
    Missugused on labori võtmekontseptid?
    Eesmärgivaatenurk
    Kuidas labori kontseptid on omavahel seotud?
    Eesmärgivaatenurk
    Missugused protsessid on vajalikud labori toimumiseks?
    Protsessivaatenurk
    Missugused sündmused käivitavad protsesse?
    Protsessivaatenurk
    Missuguses järjekorras täidetakse protsesse?
    Protsessivaatenurk
    Mida kasutavad või loovad protsessid?
    Protsessivaatenurk
    Kes kontrollib protsesse?
    Protsessivaatenurk
    Missugused on labori kliendid, tarnijad, partnerid?
    Protsessivaatenurk
    Missuguseid ressursse omab või haldab labor ?
    Struktuurivaatenurk
    Missugune on ressursside sisemine struktuur?
    Struktuurivaatenurk
    Kuidas on ressursid omavahel seotud?
    Struktuurivaatenurk
    Missugune informatsioon on tähtis labori seisukohast ?
    Struktuurivaatenurk
    Kuidas labor on ülesehitatud?
    Struktuurivaatenurk
    Kuidas muutub ressurss aja jooksul?
    Käitumisvaatenurk
    Missugused sündmused genereerivad ressursside muutmist?
    Käitumisvaatenurk
    Missugused toimingud esinevad, kui muutub ressurssi olek?
    Käitumisvaatenurk
    Kuidas toimivad omavahel ressurssid?
    Käitumisvaatenurk
    Rakenduste arhitekt
    Missugused on labori eesmärgid?
    Eesmärgivaatenurk
    Missugused probleemid takistavad eesmärkide saavutamist?
    Eesmärgivaatenurk
    Missugused protsessid on vajalikud labori toimumiseks?
    Protsessivaatenurk
    Kas laboril on vajalik suhelda teiste infosüsteemidega?
    Protsessivaatenurk
    Missugused ressurssid on omavahel loogiliselt tihedalt seotud?
    Struktuurivaatenurk
    Missugused ärikomponendid on vajalikud protsesside täitmiseks?
    Käitumisvaatenurk
    Missuguseid teenuseid pakuvad ärikomponendid?
    Käitumisvaatenurk
    Tehnoloogia arhitekt
    Missugused on labori eesmärgid?
    Eesmärgivaatenurk
    Missugused probleemid takistavad eesmärkide saavutamist?
    Eesmärgivaatenurk
    Kuidas labor on ülesehitatud?
    Struktuurivaatenurk
    Kus asuvad labori struktuurüksused?
    Struktuurivaatenurk
    3 Vaatenurkade spetsifikatsioon
    Ärimudeli koostamiseks olid valitud eermärgi-, protsessi-, struktuuri- ja käitumisvaatenurgad, kuna nad võimaldavad kirjeldada süsteemi tähtsamaid aspekte ning katavad täielikult 2. punktis loetletud huvirühmade huve.
    A Vaated
    A.1 Eesmärgivaade
    Kuna laboratoorium on haigla struktuurüksus, siis peab labori üldeesmärk toetama haigla üldeesmärki. Visioon on väljendatud järgmise lausega:
    Teha professionaalseid laboratoorseid uuringuid, mis aitavad labori klientidele tagada kõrgekvaliteetset ravi.
    Visiooni lause tükeldati alameesmärkideks (joonis E-1) [paneme tähele, et käesolevas näites kasutatud Eriksson-Penkeri metoodikas puudub funktsionaalse eesmärgi mõiste (samuti puudub seal kasutusjuhu mõiste), mistõttu eesmärkidena käsitletakse üksnes mittefunktsionaalseid ehk kvaliteedi eesmärke; funktsionaalsed eesmärgid on väljendatud Protsessivaates äriprotsessidena]:
    Joonis E‑1 Eesmärgidiagramm
    Eesmärgidiagrammi kirjeldus
    Kulude optimeerimine – vähendada ühe proovi töötlemisega seotuid kulutusi.
    • Tööaja optimeerimine – vähendada ühe proovi töötlemise tööaega.
    • Korduvtestide arvu vähendamine sõltub tulemuste täpsusest.
    Kvaliteedi tõstmine – pidevalt parandada ja täiustada analüütilise protsessi kvaliteeti ja ohutust. See eesmärk on vastuolus kulude optimeerimise eesmärgiga.
    • Täpsed tulemused – tagada võimalikult täpsed, usaldatavad ja meditsiiniliselt õiged uuringute tulemused. Selle eesmärgi täitmist võivad takistada süstemaatiliste ja juhuslikkude vigade esinemine.
    • Kvaliteetne proov – tagada proovi kogumine vastavalt kogumismeetodile.
    Rahulolevad kliendid – tagada labori klientide rahulolu.
    • Õigeaegne aruandlus – tagada täpne ja õigeaegne aruandlus.
    • Mugav tellimine – võimalus kiirelt ja vähese vaevaga teha tellimusi.
    Seejärel püüti leida labori tähtsamaid olemeid ja nendevahelisi seoseid.
    Joonis E-2 Kontseptuaalne diagramm
    Kontseptuaalse diagrammi kirjeldus
    Kliendi tellimusel on üks tellija kliendi näol. Kliendi tellimusel võib olla märgitud mitu aruande saajat. Kliendi aruanne on seotud kliendi tellimusega. Kliendi tellimus on tellitud ühe patsiendi kohta. Patsiendil võib olla kindlustus . Proov kuulub patsiendile. Proov on määratud aine tüüpi. Ühel originaalproovil võib olla mitu klooni. Proovile on tellitud mitu uuringut . Uuring on seotud ühe kliendi tellimusega. Uuringut viib läbi üks töötaja . Uuringul on tulemus. Tulemus on väljendatud mõõtühikus. Tulemust valideerib üks töötaja. Tulemusel võib olla kaks eeltulemust. Uuring on määratud testi tüüpi. Uuring viiakse läbi ühel analüsaatoril. Analüsaator on seadme liik. Osakond koosneb mitmest töökohast. Töökoht ühendab mitut analüsaatorit. Analüsaatoril saab teha mitut erinevat testi. Profail on testi tüüp. Profail koosneb mitmest erinevast testist. Tarnija tarnib seadeid ja reagente.
    Sõnastik
    Seade on laboratooriumi töös kasutatav automatiseeritud või mehhaaniline instrument . Seadeks võib olla analüsaator, mikroskoop, vöötkoodilugeja, printer jne.
    Analüsaator on seade, mille abil viiakse läbi laboratoorsed uuringud.
    Töökoht on loogiline grupp, mis ühendab ühesuguseid teste täitvaid analüsaatoreid.
    Osakond on laboratooriumi osakond, nagu näiteks hematoloogia , biokeemia jne.
    Klient on osapool, kes tellib uuringuid ja/või saab uuringu aruannet.
    Kliendi tellimus on kliendi poolt esitatud nõue teha laboratoorseid uuringuid konkreetse patsiendi proovidega.
    Kliendi aruanne on uuringute tulemuste dokument, mida saadab labor kliendile.
    Patsient on isik, kelle proovid uuritakse ja analüüsitakse.
    Test on laboratoorse uuringu tüüp, mida pakub labor oma klientidele.
    Profail on testide kogum, mida saab klient tellida.
    Uuring on konkreetne uuring, mida on klient tellinud konkreetse patsiendi proovile.
    Proov on uuringu jaoks patsiendilt võetud näidis .
    Aine on patsiendi proovi tüüp, nagu näiteks veri , seerum jne.
    Tulemus on laboratoorse uuringu tulem.
    Tarnija on osapool, kes tarnib laborile vajalikke seadmeid ja reagente.
    Originaal on patsiendilt võetud proov, millest võetakse hiljem alikvootid.
    Alikvoot, kloon on originaalilt võetud näidis.
    A.2 Protsessivaade
    Äritegutsejate (business actors) loetelu
    Sisemised äritegijad:
    • Sekretär
    • Assistent (ehk proovi koguja)
    • Laborant
    • Tehnoloog (ehk vanem laborant)
    • Juhataja
    Välised äritegijad:
    • Tarnija
    • Haigla finantsosakond
    • Klient
    • Patsient
    • Reguleeriv amet
    • Muud laborid
    Koostati kontekstidiagramm, et näidata labori suhteid väliskeskkonnaga.
    Joonis A‑3 Kontekstidiagramm
    Kontekstidiagrammi kirjeldus
    Labor esitab tarnijale tarnetellimuse. Tarnija varustab laborit reagentide ja seadmetega. Labor saadab haigla finantsosakonnale arveldusaruande, mis näitab, missuguseid teste on tehtud (selle alusel esitab finantsosakond patsiendile või kindlustusseltsile hagi). Labor saab patsiendilt proovi uuringu läbiviimiseks. Reguleerivad ametid (nagu näiteks meditsiinilised assotsiatsioonid) annavad välja juhendeid ja standardeid, mis reguleerivad labori töökorraldust. Klient esitab laborile tellimuse analüüsi läbiviimiseks ning saab laborilt aruande analüüsi tulemustega. Labor vahetab statistilisi aruandeid teiste laboritega.
    Seejärel defineeriti visiooni ja eesmärkidega seotud protsessid. Selle näite lihtsustamiseks on jäetud vaatluse alt välja tugi- ja haldusprotsessid, nagu näiteks tarnete haldamine, labori juhtimine, kvaliteedi kontroll. Laboris määratleti kolm primaarset äriprotsessi:
  • Preanalüütiline protsess hõlmab protsesse, mis eelnevad proovi analüüsile, alates testide tellimisest kuni proovi jõudmiseni töökohale.
  • Analüütiline protsess – patsiendi proovi analüüs. Suur osa laboratoorsetest uuringutest on automatiseeritud.
  • Postanalüütiline protsess hõlmab protsesse, mis järgnevad proovi analüüsile.
    Järgmine joonis näitab primaarsete protsesside töövoogu:
    Joonis A‑4 Põhiprotsessid
    Eelnevat joonist saab „tõlkida“ standardsesse UML keelde järgnevalt:
    Joonis. A-4 „tõlgutuna“ UML tegevusdiagrammiks
    Seejärel tükeldati kõrgetasemelised äriprotsessid väiksemateks protsessideks. Preanalüütilises protsessis eristati järgnevad allprotsessid:
    • Testide tellimine – laboratoorsete uuringute tellimine.
    • Proovi kogumine – proovi kogumine patsiendilt ja selle kohaletoimetamine.
    • Distributsioon – proovi töövoo planeerimine, alikvootide valmistamine ja laialisaatmine töökohtadesse.
    Postanalüütilises protsessis eristati järgnevad protsessid:
    • Valideerimine – proovi tulemuste läbivaatamine ning õigeks või valeks kinnitamine
    • Interpreteerimine – uuringu tulemuste interpreteerimine ning aruande koostamine.
    Järgmised joonised näitavad preanalüütilise ja postanalüütilise protsesside detaile:
    Joonis A‑5 Preanalüütilise protsessi alamprotsessid
    Joonis A-6 Postanalüütilise protsessi alamprotsessid
    Ärireeglite spetsifikatsioon
  • Iga proov peab olema märgistatud unikaalse vöötkoodi lipikuga.
  • Kõik profaili testid peavad olema erinevad.
  • Kui patsient on statsionaarne, siis assistent läheb patsiendi juurde proovi kogumiseks juhul, kui patsient ei pea seda ise koguma
  • Kui patsient on ambulatoorne, siis proovi kogub arst või patsienti suunatakse laborisse proovi kogumiseks.
  • Kui uuringu tulemuse valideerimise staatus on “Vabastatud”, siis tulemust võib interpreteerida.
  • Kui uuringu tulemuse valideerimise staatus on “Korduv”, siis uuringut peab kordama .
  • Tulemusi peab säilitama 5 aastat.
    A.3 Struktuurivaade
    Struktuurivaates modelleeritakse haigla laboratooriumi ressursid, informatsioon ja organisatsioon , kasutades eesmärgi- ja protsessivaate diagramme. Kui eesmärgivaates olid modelleeritud põhilised ärikontseptid, siis selles vaates modelleeritakse detailsemalt nende struktuur. Järgmisel joonisel on näidatud , missugust informatsiooni võib sisaldada kliendi tellimus.
    Joonis A-7 Kliendi tellimuse informatsiooni modelleerimine
    Klassidiagrammi kirjeldus
    Kliendi tellimusel on prioriteet , mis näitab, missuguses järjekorras tuleb täita see tellimus. Tellimusel on mitu testi, mida on vaja teha. Tellimusel on staatus, mis näitab, missugusel täitmisetapil on tellimus. Tellimus võib sisaldada informatsiooni patsiendi formaalsete gruppide, nagu suitsetaja , rase jne., patsiendil avastatud või kahtlustatavate diagnooside ja patsiendi poolt kasutatavate medikamente kohta. See informatsioon aitab interpreteerida uuringu tulemusi.
    Järgmine diagramm näitab testi informatsiooni modelleerimise tulemust:
    Joonis A-8 Testi informatsiooni modelleerimine
    Klassidiagrammi kirjeldus
    Testil on üks analüüsimeetod. Test nõuab üht määratud aine tüüpi uuringu läbiviimiseks. Testil on üks mõõtühik , mis kasutatakse uuringu tulemuse väljendamiseks . Test võib omada mitut piirväärtust, mis näitavad, missugusesse vahemikku satub uuringu tulemus. Selle alusel määratakse tulemuse meditsiiniline staatus. Piirväärtus sõltub patsiendi soost ja vanusest .
    Joonisel A-9 on illustreeritud uuringu tulemuse modelleerimine:
    Joonis A-9 Tulemuse informatsiooni modelleerimine
    NB! Eelneval joonisel on üks tõsine viga olemite (klasside) seoste (assotsiatsioonide) osas. Leidke see viga üles!
    Klassidiagrammi kirjeldus
    Tulemus väljendatakse mõõtühikus. Tulemusel on meditsiiniline ja valideerimise staatused . Tuletatud tulemus on tulemuse liik. Tuletamine näitab, kuidas mitmest lähtetulemusest arvutada üks sihttulemus.
    Järgmine joonis näitab laboratooriumi üldist struktuuri:
    Joonis A-10 Labori üldine organisatsioon
    Klassidiagrammi kirjeldus
    Laboratoorium koosneb mitmest osakonnast. Töötaja võib olla määratud mitmesse osakonda. Osakond omab mitut töökohta. Töökoht haldab mitut analüsaatorit.
    Struktuurivaate modelleerimise käigus grupeeriti loogiliselt seotud äriressursid pakettidesse (mis meie ainetöös ning näites B nimetatakse registriteks), ning kõik paketid esitati pakettdiagrammi abil.
    Joonis A-11 Pakettdiagramm
    4.5 Käitumisvaade
    Käitumisvaates on uuritud lähemalt ressursside käitumist. Näiteks näitavad järgmised UML olekudiagrammid kliendi tellimuse staatuse ja tulemuse valideerimise staatuse olekuid :
    Joonis A-12 Kliendi tellimuse olekudiagramm
    Joonis A-13 Tulemuse olekudiagramm valideerimise staatuse järgi
    On uuritud lähemalt ka protsesside koostoimed ressurssidega. Järgmine nn. „koosteliinide“ ( assembly lines) diagramm näitab protsesside koostoimeid ressurssidega. Ressursid on joonisel näidatud pakettidena, mida antud kontekstis nimetatakse „koosteliinideks“.
    Joonis A-14 Testide tellimise protsessi koosteliinidiagramm
    Seda liiki diagramme kasutatakse Eriksson-Penkeri metoodikas kasutusjuhtude kirjutamise asemel kontrollimaks, kas ning kuidas vastavat äriprotsessi saaks automatiseerida. Meie ainetöö tegemiseks kasutatavas metoodikas ning järgnevas näites B koosteliinide diagramme ei tehta , vaid minnakse üle kasutusjuhtude analüüsile.
    Soovi korral on võimalik koosteliinide diagrammi teha ka standard-UML-is kasutusjuhtude diagrammina järgnevalt:
    Äriprotsess on eelneval joonisel kujutatud (äri)kasutusloona [NB! Eriksson-Penkeri metoodikas tegelikult ühtegi kasutulugu ei kirjutata ega joonistata. See joonis on konkreetse (koosteliinide diagrammi) tehnika üks võimalik tõlge tavalisse UML keelde].
    5 Lahknevuste analüüs
    Kontseptuaalsel diagrammil (joonis A-2) ja tulemuse informatsiooni diagrammil (joonis A-9) on näidatud, et on vaid kaks tulemuse tüüpi, ning nendeks on ressurssid “Tulemus”ja “Tuletatud tulemus”. Samuti on näidatud, et ressurssil “Tulemus” on seos iseendaga (“eeltulemus”). Kuid joonisel A-6 on näha, et interpreteerimise protsess kasutab sisendressurssi “Tulemus” ja toetavat ressurssi “Eeltulemus”. See tähendab, et tulemuse seos iseendaga on väljendatud protsessidiagrammil ressurssina. Selline lahendus on valitud selleks, et näidata täpselt, missuguseid tulemusi kasutatakse interpreteerimisel.
    Juhul kui ärimudeli alusel ei ole plaanis otseselt genereerida ega kirjutada tarkvara, on selline lahendus piisav, vastasel korral peaks modelleerima eeltulemusele vastava klassi, mis spetsialiseerib tulemust.
    Näide B: Sama meditsiinilabori ärimodelleerimine meie ainetöös kasutatava ärikasutusjuhtude keskse metoodika järgi (vt. aine keskkonnas olevat UML mudelit HaiglaLaborB.mdl).
    Ärikasutusjuhtudest (business use case) saame mõelda kolmes erinevas tähenduses (korraga, mitte üksteist välistavalt):
    • Ärisüsteemi kasutamise lugu, seanss (stsenaarium) [n. toidu ettekandmine restorani kliendile]
    • Ärikasutusjuht = Äriprotsess
    • Ärikasutusjuht = Funktsionaalne (äri)eesmärk

    Näites B on (võrreldes näitega A) eesmärkide vaade (UML pakett ) ümber nimetatud Visiooniks, protsessivaadet on nimetatud Funktsionaalseks vaateks, struktuurivaadet Registrite vaateks; käitumisvaadet näites B ei ole eraldi defineeritud, sest protsesside dünaamikat (tegevusdiagrammid) on käsitletud Funktsionaalses vaates (mis kirjeldab protsesside struktuuri ja dünaamikat) ning ressursside dünaamikat (olekudiagrammid) on käsitletud Registrite vaates (mis kirjeldab ressursside struktuuri ja dünaamikat).
    Visioon. Visioon esitatakse kolme mudeliga: eesmärkmudel, protsessimudel ning kontseptuaalne mudel.
    Eesmärkmudel hõlmab (erinevalt näitest A) nii funktsionaalseid eesmärke ((äri)kasutusjuhud) kui ka kvaliteedieesmärke ( klassid stereotüübiga või ning eesmärkide täitmist takistavaid probleeme (kvaliteedieesmärgiga seotud märkus /kommentaar või siis klass stereotüübiga ).
    Eesmärgid kuuluvad konkreetsele huvigrupile, keda tähistame tegutseja või äritegutseja sümboliga. Hagla Labori visiooni omanikuna (huvigrupina) vaatame selles näites Haigla Laborit tervikuna kui äritegutsejat, kes pakub laboriuuringute teenust Haiglale.
    Joonis B-V1. Ärikasutusjuhtude kontekstidiagramm Haigla Labori missioonilause põhjal (Visiooni osa)
    Visiooni vaate esimese diagrammina on selles näites (B) koostatud Haigla Labori missioonilause alusel ärikasutusjuhtude kontekstidiagramm. Missioonilauses on peidus üks funktsionaalne (äri)eesmärk „Laboriuuringute läbiviimine“, mis on väljendatud vastava ärikasutusjuhuna, ning üks kvaliteedieesmärk „Professionaalsed uuringud“, mis on väljendatud vastava stereotüübiga () klassina.
    Joonis B-V2. Haigla Labori kvaliteedieesmärgid
    Näite B visiooni vaate teise diagrammina on koostatud kvaliteedieesmärkide mudel UML klassidiagrammina (nii nagu näites A). Eesmärkide hierarhia on väljendatud sõltuvusseost (dependency – katkendnool) kasutades (eesmärgi täitmine sõltub alameesmärkide täitmisest). Eesmärgid võivad olla omavahel vastuolus ( assotsiatsioon stereotüübiga ). Eesmärkide täitmist võivad takistada probleemid. Eesmärkide dekompositsioon peab jõudma mõõdetavale tasemele . Mõõdikuid saab kirjeldada eesmärgiklasside atribuutidena (vaata eelneval joonisel olevat näidet).
    Joonis B-V3. Haigla Labori funktsionaalsed eesmärgid ((äri)kasutusjuhtude diagramm)
    Funktsionaalsed eesmärgid on peamiselt Funktsionaalse vaate teema. Kõige kõrgema taseme funktsionaalsed eesmärgid (mis defineerivad funktsionaalseid allsüsteeme) on samaaegselt ka visiooni keskseks osaks. Funktsionaalsete eesmärkide mudel on esitatud (äri)kasutusjuhtude diagrammil, mis annab funktsionaalsete ärieesmärkide (ja neile vastavate äriprotsesside) struktuuri ning seob funktsionaalsed eesmärgid asjassepuutuvate kvaliteedieesmärkidega.
    Ka Haigla labori missiooni (ehk kõige kõrgema taseme funktsionaalse eesmärgi ning äriprotsessi) täitmise töövoogu visandav tegevusdiagramm sobib visiooni vaatesse:
    Joonis B-V4. Laboratoorse uuringu läbiviimise protsessi tegevusdiagramm
    Sellel tegevusdagrammil on väljendatud nii töövood kui ka ressursivood (infovood, materjalivood). Kui selline tegevusdiagramm läheb liiga kirjuks, saab töövood ja ressursivood kirjeldada eraldi tegevusdiagrammidega.
    Joonis B-V5. Haigla Labori põhimõisted ja seosed (eesmärkmudelit toetav ) kontseptuaalne klassidiagramm
    Visiooni vaate neljanda diagrammina on tehtud eesmärkmudelit toetav kontseptuaalne klassidiagramm, mis väljendab eesmärkmudeliga seotud põhimõisteid (äriobjekte, -olemeid) ja nendevahelisi olulisemaid seoseid (nii nagu joonis E-2 näites A).
    Need mõistet leiavad täpsemat käsitlemist Registrite vaates.
    Funktsionaalne vaade. Funktsionaalses vaates kirjeldatakse (äri)protsesside struktuuri ja dünaamikat funktsionaalsete allsüsteemide kaupa. Funktsionaalseid allsüsteeme saab defineerida protsessikeskselt (suuremate äriprotsesside käsitlemiseks) või objektikeskselt (põhiobjekti ehk ressursi kogu elutsükli kõigi protsesside käsitlemiseks). Haigla labori funktsionaalne vaade on jaotatud kolmeks suureks allsüsteemiks protsessikeskselt, Visioonis kirjeldatud terviksüsteemi funktsionaalsete eesmärkide ja protsessi mudeli alusel on Laboriuuringute läbiviimise eesmärk ning protsess jagatud kolmeks alamprotsessiks: Preanalüütiline (eelanalüüsi), Analüütiline ning Postanalüütiline (järelanalüüsi) protsess, millest igaüks vajab käsitlemist iseseisva samanimelise funktsionaalse allsüsteemina. Igat funktsionaalset allsüsteemi võime modelleerida sarnaselt (Visioonis kirjeldatud) terviksüsteemile (kasutades samu või sarnaseid tehnikaid ja kirjeldamismustreid). Järgnevalt õpetame funktsionaalse allsüsteemi modelleerimist Postanalüütilise (Järelanalüüs) allsüsteemi näitel:
    Postanalüütiline allsüsteem
    Nii nagu Visiooni esimeseks diagrammiks oli (äri)kasutusjuhtude kontekstidiagramm terviksüsteemi (Haigla Labor) jaoks, saame sarnase kontekstidiagrammi teha ka iga funktsionaalse allsüsteemi jaoks:
    Joonis B-F1. Postanalüütilise (Järelanalüüsi) allsüsteemi ärikasutusjuhtude kontekstidiagramm
    Järelanalüüsi allsüsteemi kogu funktsionaalsus on väljendatud Postanalüütilise protsessi (Järelanalüüsi läbiviimise) funktsionaalse eesmärgi ning äriprotsessiga, mida viib läbi Tehnoloog ning mis loob väärtust Kliendile, kelleks on Haigla Arst (laboriuuringu tellija, aruande saaja). Järelanalüüsi protsessi(de) sisuks on Analüütilise protsessi tulemuste valideerimine ning interpreteerimine, mis on seotud kahe kvaliteedieesmärgiga (Visiooni vaatest): „Täpsed tulemused“ ning „Õigeaegne aruandlus“. Eelneval joonisel on jäänud need kvaliteedieesmärgid funktsionaalse eesmärgiga sidumata põhjusel , et need kvaliteedieesmärgid saab järgneval funktsionaalsete eesmärkide diagrammil siduda täpsemalt konkreetsemate funktsionaalsete eesmärkidega „Valideerimine“ ning „Interpreteerimine“:
    Joonis B-F2. Postanalüütilise (Järelanalüüsi) allsüsteemi funktsionaalsed eesmärgid ((äri)kasutusjuhtude diagramm)
    Funktsionaalsete eesmärkide mudelil on funktsionaalset allsüsteemi defineeriv suurem funktsionaalne eesmärk ning protsess (Postanalüüs) jagatud väiksemateks eesmärkideks-protsessideks (Valideerimine ja Interpreteerimine), kasutades stereotüübiga seost (mida õpime edaspidi kasutusjuhtude teema juures täpsemalt). Funktsionaalsed eesmärgid on seotud sobivate kvliteedieesmärkidega (nii täpselt kui võimalik). Ka väiksemad funktsionaalsed eesmärgid-protsessid võivad vajada (kui nad on piisavalt mahukad ja olulised) iseseisvate funktsionaalsete allsüsteemide (UML pakettide ) defineerimist (suurema allsüsteemi- paketi sees, hierarhiliselt). Interpreteerimise ja valideerimise protsesside puhul see tegelikult nii ongi (Valideerimise allsüsteem, Interpreteerimise allsüsteem).
    Iga funktsionaalne eesmärk-protsess võib olla täpsemalt kirjeldatud ühe või enama tegevusdiagrammiga:
    Joonis B-F3. Järelanalüüsi (Postanalüütiline) tegevusdiagramm
    Käesolevas tegevusdiagrammis on äriprotsessi (Järelanalüüs) töövoog ja ressursivood joonistatud ühele ja samalale diagrammile, kuid võiks olla ka kahel eraldi tegevusdiagrammil vastavalt töövoogude ja ressursivoogude jaoks.
    Registrite vaade. Registrite vaatesse näites B on ühendatud näite A Struktuurivaate ja Käitumisvaate sisu. Struktuurivaadet esindab siin konkreetset põhiobjekti ehk ressurssi esindava Registri struktuuri kirjeldav klassidiagramm, Käitumisvaadet esindab siin Registri põhiobjekti ehk ressurssi elutsüklit kirjeldav olekudiagramm.
    Joonis B-R1. Tellimuste registri kontseptuaalne klassidiagramm
    Selle klassidiagrammi mõistete ja seoste selgitused leiate näite A Struktuurivaates Tellimuse klassidiagrammi juurest. Väike erinevus diagrammi väljanägemises võrreldes näitega A seisneb selles, et kui näites A kasutati põhiobjekti sidumiseks klassifikaatorobjektiga UML sõltuvusseost (dependency, katkendnool), siis näites B kasutame tavalist mitu-üks tüüpi seost (assotsiatsiooni). Mõlemad variandid on lubatud ja head.
    Joonis B-R2. Tellimuse olekudiagramm
    Selle diagrammi sisu on sama mis tellimuse olekudiagrammil näite A käitumisvaates. Nooltel on kirjas ärisündmused, mis viivad kliendi tellimuse ühest olekust teise. Need sündmused peavad sisendite-väljundite poolest kokku sobima Funktsionaalse vaate tegevusdiagrammides olevate tegevuste kirjeldustega. Sündmused saavad edasistes loengutes täpsemalt käsitletud seoses tarkvara kasutusjuhtude mudeliga (Väljaspool UP Ärimodelleerimise distsipliini, Nõuete distsipliini põhiteemana).
    Mõlemat näidet (A ja B) oleme seni vaadanud kui kindlatest osadest-vaadetest koosnevat tulemust.
    Selle tulemuse saavutamist ehk ärimodelleerimise protsessi on vaja käsitleda ka iteratiivse arendusprotsessi UP osana-distsipliinina.
    Tegevusdiagrammi elemendid ja nende tähistus.
    Vt. UML Superstructure Specification, v2.0, lk.333, 349,
    http://www.omg.org/cgi-bin/doc?formal/05-07-04
    Modelleerimisvõimalusi on palju, dokumendis toodud näited on soovitusliku iseloomuga .
    Tegevusdiagrammid, töövood, infovood.
    Tegevusdiagramm on ujumisradade (swimlane) abil jagatud nii, et iga tegevust täidab konkreetne roll.
    Ujumisrajad võivad olla kas horisontaalsed või vertikaalsed . Ujumisraja päises tuleb ära näidata roll (Swimlane Name, antud näites näiteks Customer) ja rolli taga olevale tegutsejale vastav klass (Swimlane Class , actor on samuti klass).
    Kui tegutseja ja roll kattuvad, siis piisab kui näidata ainult tegutsejale vastavat klassi.
    Rollid luuakse tegevusdiagrammi(de) jaoks sobiva üldistusega, et saaks tegevuste täitjat näidata. Kui rolle ei ole võimalik eristada (või analüüsi täpsustase seda veel ei võimalda), siis pole vaja ujumisradu kasutada.
    Protsessi alguses on protsessi põhiobjekt protsessi algseisundis (seest täis mumm ). Protsess saab alata (lähtuda) vaid ühest põhiobjekti algseisundist. Kui ühel protsessil on näiliselt mitu algseisundit, siis tuleb üle kontrollida, kas need algseisundid on sisult dubleerivad. Teine võimalus, et tegu on erinevate (st. mitte samaste) protsessidega.
    Protsessi lõpus võib olla üks või mitu lõppseisundit (topeltringiga mumm).
    Tegevus on tähistatud ümarate nurkadega kasti abil.
    Tegevusharud
    Tegevusharusid on kahte tüüpi: alternatiivsed ja paralleelsed tegevusharud. Alternatiivsete tegevuste korral tähistatakse hargnemist ja vajadusel ka hilisemat koondumist rombiga.
    Paralleelsete tegevuste korral tähistatakse hargnemist ja vajadusel ka hilisemat koondumist sünkroniseerimisjoone abil.
    Alternatiivsed tegevusharud
    Alternatiivsed tegevusharud – tegevusliin hargneb, protsessi konkreetne instants valib iga kord vaid ühe alternatiivse tegevusharu . Tegevusliini hargnemine algab otsustusest (ehk otsustusprotsessi tähistavast tegevusest) – millist tegevusharu valida.
    Otsustamise tegevusest väljuv nool viitab hargnemise algust tähistavale rombile. Hargnemise algust tähistavast rombist peab väljuma enam kui üks nool. Rombist väljuvatele (hargnevatele) nooltele tuleb peale lisada tehtud otsus (otsustusalternatiiv, näites [Order Accepted]).
    Kui alternatiivsed tegevusharud hiljem jälle koonduvad, siis tuleb seda näidata hargnemise lõppu tähistava rombi abil. Hargnemise lõppu tähistavasse rombi peab sisenema enam kui üks nool, sellest peab väljuma vaid üks nool – romb ei saa korraga tähistada hargnemise lõppu ja uue hargnemise algust.
    Alternatiivsed tegevusharud ei pea alati koonduma – sellisel juhul on protsessil mitu alternatiivset lõppu (millele vastab mitu lõppseisundit).
    Paralleelselt toimuvad tegevusharud – järgnevad (sünkroniseerimisjoonest hargnevate harude) tegevused peavad toimuma paralleelselt. Paralleelsete tegevuste korral tähistatakse hargnemist ja vajadusel ka hilisemat koondumist sünkroniseerimisjoone abil. Sünkroniseerimisjoon on risti ujumisrajaga. Kui paralleelsed tegevusharud hiljem jälle koonduvad, siis tuleb seda näidata hargnemise lõppu tähistava sünkroniseerimisjoone abil. Hargnemist tähistavasse sünkroniseerimisjoonde peab sisenema üks nool, väljuma mitu noolt . Paralleelharusid koondava sünkroniseerimisjoone korral peab olema vastupidi. Kui paralleeltegevusharud ei koondu, siis on protsessil mitu lõppu, mis võivad lõppeda erineval ajal – igale lõpule vastab erinev lõppseisund st. protsess lõpeb liitseisundiga (see on väga erandlik olukord).
    Mitte-UML: BPMN notatsioon äriprotsesside modelleerimiseks (alternatiiviks tegevusdiagrammidele)
    http://upload.wikimedia.org/wikipedia/commons/0/06/BPMN_2.0_Sales_Operations_Planning_Map_Opsdog.jpg
    Vaadake legendi ja näidet selle lingi taga.
    BPMN on (erinevalt UML-st, mis on universaalne modelleerimiskeel ning erinevalt BPMN-st toetab ka objektorienteeritud ärimodelleerimist) keskendatud äriprotsesside modelleerimisele. Tavalisi äriprotsesse on BPMN-is mugavam modelleerida kui UML-s (ainult tegevusdiagrammi või erinevate diagrammitüüpide mingit kombinatsiooni kasutades).
    Kuid ükskõik milline BPMN protsessimudel on kindlate reeglite alusel üheselt teisendatav UML tegevusdiagrammiks ja vastupidi.
    Oluline erinevus: UML-is ei ole lubatud kirjeldada ühe ja sama tegevusdiagrammiga mitut (äri)protsessi. See sunnib meid koostama sellise funktsionaalsete eesmärkide ja protsesside struktuuri (meie teeme seda ärikasutusjuhtude ehk funktsionaalsete ärieesmärkide mudeli abil), et igat protsessi saab kirjeldada iseseisva tegevusdiagrammiga.
    BPMN-s on võimalik ühel diagrammil kirjeldada ja seostada erinevaid protsesse.
    Meie aine jaoks on BPMN kõrvalteema, mis on vajalik seose loomiseks Äriprotsesside modelleerimise (E. Õunapuu) ainega ja ka Meeskonnatöö (M.Roost) ainega, kus õpitakse ja harjutatakse seda notatsiooni.
    Sellega on esimese kontrolltöö materjal läbi võetud. Kontrolltöösse tulevad valikvastustega küsimused kogu eelneva loengumaterjali põhjal. Küsimused esindavad kolme suurt teemade gruppi:
    • Süsteemianalüüsi aine paigutus Zachmani ning iteratiivse Unified Process-i (UP/RUP) ja Kose mudeli raamistikes;
    • Iteratiivse arendusprotsessi ülevaade, iseloomustus ja võrdlus teiste arendusprotsessi tüüpidega (kose mudel, agiilmetoodikad) ning süsteemianalüüsi osa iteratiivses arenduses;
    • Ärimodelleerimine: põhimõisted, erinevad lähenemised, metoodikad, notatsioonid, näited (A ja B, nende võrdlus).

    • .DOCX Laadi alla originaalfail 102 lk · .docx · 77 allalaadimist
    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 77 laadimist Kokku alla laetud
    Kommentaarid 0 arvamust Teiste kasutajate poolt lisatud kommentaarid
    Autor 213757 Õppematerjali autor
    Kontrollitud
    PDF TXT
    Süsteemi analüüsi kontrolltöö nr.1
    Süsteemianalüüs kontrolltöö esimene kontrolltöö nr.1 süsteemianalüüs disain tarkvara modelleerimine arendusprotsess zachman

    Kasutatud allikad

    Sarnased õppematerjalid

    Süsteemianalüüs - Esimese loengutöö konspekt
    12
    docx

    Süsteemianalüüs - Esimese loengutöö konspekt

    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

    Süsteemianalüüs
    Süsteemianalüüs - 2 loengutöö konspekt
    26
    docx

    Süsteemianalüüs - 2 loengutöö konspekt

    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

    Süsteemianalüüs
    Kontseptuaalne süsteemianalüüs
    7
    pdf

    Kontseptuaalne süsteemianalüüs

    Kõikide süsteemi operatsioonide jaoks 27. Millised vaatenurgad defineerib Eriksson-Penkeri ärimodelleerimise metoodika? Valige täpne (s.t. õige ja ammendav) vastus: määrab objektide, protsesside ja struktuuri vaatenurgad määrab objektide ja protsesside vaatenurgad määrab struktuuri ja dünaamika vaatenurgad määrab eesmärkide, protsessi, struktuuri ja dünaamika vaatenurgad ei määra ühtegi vaatenurka 28. Kas detailse süsteemianalüüsi lõpptulemuseks olevas (lõpetatud) domeenimudelis võib olla ilma atribuutideta klasse? Valige õige vastus. Võib ainult siis, kui on saavutatud vastav kokkulepe disaineritega. Ei või, sest ilma atribuutideta klasside esinemise korral poleks analüüs detailne. Jah, võib küll. 29. Unifitseeritud tarkvaraarendusprotsessi UP faasid (arendustüskli etapid) on järgmised: * Inception (algfaas, visioon) * Elaboration (täpsustamine/viimistlemine, arhitektuur)

    Kontseptuaalne süsteemianalüüs
    kontseptuaalne süsteemianalüüs spikker
    12
    docx

    kontseptuaalne süsteemianalüüs spikker

    4. Millised tegutsejad (actors) on vaja kasutusjuhtude mudelis identifitseerida? Valige pakutud vastusevariantide hulgast parim (s.t. täpne ja ammendav) vastus (kõik ülejäänud/mitteparimad vastused loetakse valeks): primaarsed tegutsejad *vaadeldava süsteemi suhtes huvisid omavad tegutsejad arvutisüsteemid kõrvalseisvad (offstage) tegutsejad inimtegutsejad toetavad tegutsejad 5. Süsteemi jadadiagrammi käsitletakse (C. Larmani raamatus ning kontseptuaalse süsteemianalüüsi aine konspektis) järgmise UP-s (Unified Process) koostatava mudeli osana: domeenimudel arendusmudel eesmärkmudel ärimudel disainimudel *kasutusjuhtude (use case) mudel 6. Millised vaatenurgad defineerib Eriksson-Penkeri ärimodelleerimise metoodika? Valige täpne (s.t. õige ja ammendav) vastus: määrab objektide, protsesside ja struktuuri vaatenurgad määrab objektide ja protsesside vaatenurgad määrab struktuuri ja dünaamika vaatenurgad

    Kontseptuaalne süsteemianalüüs
    Süsteemianalüüsi kontrolltöö vastused
    12
    docx

    Süsteemianalüüsi kontrolltöö vastused

    4. Millised tegutsejad (actors) on vaja kasutusjuhtude mudelis identifitseerida? Valige pakutud vastusevariantide hulgast parim (s.t. täpne ja ammendav) vastus (kõik ülejäänud/mitteparimad vastused loetakse valeks): primaarsed tegutsejad *vaadeldava süsteemi suhtes huvisid omavad tegutsejad arvutisüsteemid kõrvalseisvad (offstage) tegutsejad inimtegutsejad toetavad tegutsejad 5. Süsteemi jadadiagrammi käsitletakse (C. Larmani raamatus ning kontseptuaalse süsteemianalüüsi aine konspektis) järgmise UP-s (Unified Process) koostatava mudeli osana: domeenimudel arendusmudel eesmärkmudel ärimudel disainimudel *kasutusjuhtude (use case) mudel 6. Millised vaatenurgad defineerib Eriksson-Penkeri ärimodelleerimise metoodika? Valige täpne (s.t. õige ja ammendav) vastus: määrab objektide, protsesside ja struktuuri vaatenurgad määrab objektide ja protsesside vaatenurgad määrab struktuuri ja dünaamika vaatenurgad

    Kontseptuaalne süsteemianalüüs
    Projekt aines-Infosüsteemide strateegiline analüüs
    64
    pdf

    Projekt aines “Infosüsteemide strateegiline analüüs”

    TALLINNA TEHNIKAÜLIKOOL Informaatikainstituut Infosüsteemide õppetool Projekt aines “Infosüsteemide strateegiline analüüs” Solaris Kino Infosüsteem Õpilased: Maksim Nikiforov 132274 Vassilina Matvejeva 132553 Juhendaja: Lea Elmik Tallinn 2013 © TTÜ Informaatikainstituut Contents 1. PROJEKTI SPETSIFIKATSIOON 2 1.1 PROJEKTI TAUST 2 1.2 PROJEKTI EESMÄRGID JA TULEMUSED 2 1.3 TÖÖJAOTUS 2 2. INFOSÜSTEEMI ÄRI- EHK TOIMIMISE VAADE 3 2.1 TERVIKSÜSTEEMI ÜLDVAADE 3 2.2 P

    Kontseptuaalne süsteemianalüüs
    Fototellimuse projekt aines kontseptuaalne süsteemianalüüs
    92
    doc

    Fototellimuse projekt aines kontseptuaalne süsteemianalüüs

    TALLINNA TEHNIKAÜLIKOOL Informaatikainstituut Infosüsteemide õppetool Projekt aines IDU5360 “Kontseptuaalne süsteemianalüüs” Fototellimus Tallinn 2013 Autorideklaratsioon Deklareerin, et käesolev ainetöö on minu töö tulemus ja seda ei ole kellegi teise poolt varem üheski aines esitatud. ............................. ………………………….. (kuupäev) (töö esitaja allkiri) 2 Sisukord 1. Iteratsioon I.............................................................................................................................6 1.1 Visioon..............................................................................................................................6 1.2

    Kontseptuaalne süsteemianalüüs
    E-deklaratsioonide haldamine
    36
    doc

    E-deklaratsioonide haldamine

    TALLINNA TEHNIKAÜLIKOOL Informaatikainstituut Infosüsteemide õppetool Projekt aines IDU5360 "Kontseptuaalne süsteemianalüüs" e-deklaratsioonide haldamine Üliõpilane: ... Õpperühm: ... Matrikli nr.: ... Juhendaja: ... Tallinn 2011 2 Autorideklaratsioon Deklareerin, et käesolev ainetöö on minu töö tulemus ja seda ei ole kellegi teise poolt varem üheski aines esitatud. ............................. ................................ (kuupäev) (töö esitaja allkiri) 3

    Informaatika


    Rohkem sarnaseid



    Meedia

    Vasakule Paremale

    Kommentaarid (0)

    Kommentaarid sellele materjalile puuduvad. Ole esimene ja kommenteeri



    Kõik kommentaarid



    Info
    K & V
    Mäng
    Eraõpetajad
    Meist
    Kuidas saada punkte?
    KKK
    Reklaam
    Uudistevoog
    Sitemap
    Kontakt
    Saada kiri
    kiri@annaabi.ee
    Telefon: +372-569-80010
    Aadress: Tiskrevälja 33, Tallinn
    OÜ LOLSOL. Registrikood: 11450433
    Kasutustingimused
    Privaatsustingimused
    Sõnastikud
    Inglise Soome Saksa Vene Hispaania Prantsuse Rootsi Itaalia Ladina Taani Esperanto
    Püsiühendus(es)
    Facebook Instagram Twitter Reddit
    Sellel veebilehel kasutatakse küpsiseid. Kasutamist jätkates nõustute küpsiste ja veebilehe üldtingimustega Nõustun