Majandusinfosüsteemidpc.ut.ee/~ttamb/ikt/mis/mis2014/loeng_v24_osa2.doc · Web viewAlles seejärel saab vaadata nn füüsilisele tehnoloogiale (millega ja kus ehk mis tarkvara ja

Majandusinfosüsteemid. osa II sügis 2012

Majandusinfosüsteemid, Konspekt – osa II

Aine kodulehekülg: http://pc.ut.ee/taavi/ikt/mis/

ORGANISATSIOONI MUDELID.........................................................2

ORGANISATSIOON JA IKT.......................................................................3Ettevõtte arhitektuuritasandid..........................................................................................3Süsteemi tasand................................................................................................................6Infomudel..........................................................................................................................7Äritasandi mudelid.........................................................................................................11

KVALITEEDIMUDELID............................................................................15Kvaliteedi auhind (EFQM Excellence Award)...............................................................15Küpsusmudel (Capability Maturity Model)....................................................................16ISO 9000 jms..................................................................................................................16Balanced Score Card......................................................................................................17BPR (Business Process Reengineering).........................................................................19Teenuste disaini protsess................................................................................................21Seoseid mudelite vahel...................................................................................................22

IS PROJEKTEERIMISE METOODIKAD.........................................24

PROJEKTIJUHTIMINE..............................................................................29KOSKMUDEL.........................................................................................31SPIRAALMUDEL.....................................................................................32SCRUM..................................................................................................33MSF......................................................................................................34RUP......................................................................................................36

Etapid.............................................................................................................................37Tegevused.......................................................................................................................38Kui midagi jääks tegemata.............................................................................................42

PAKKUMISKUTSE...................................................................................43Millest juhinduda............................................................................................................43Pakkumiste hindamine....................................................................................................44Infosüsteemi omadused (nõudete spetsifikatsioon)........................................................45

MUID METOODIKAID JA NÄITEID EESTIST.............................................47IS PROJEKTEERIMISE MUDELID.............................................................51

Eesmärgivaade...............................................................................................................53Hierarhiamudel..............................................................................................................54Kasutusjuhtum................................................................................................................54Voodiagramm.................................................................................................................55Protsesside vahelised seosed..........................................................................................56Stsenaariumid.................................................................................................................56Protsessi diagramm........................................................................................................57Andmevoo diagramm......................................................................................................59Andmemudel...................................................................................................................60Infomudelid.....................................................................................................................60Mudelite näiteid..............................................................................................................61

Viidatud allikad........................................................................................67

Tartu Ülikooli Pärnu kolledž, Taavi Tamberg 1/67

http://pc.ut.ee/taavi/ikt/mis/


Organisatsiooni mudelidKui me tahame millestki olemasolevast ülevaadet saada, siis peame leidma olulised väärtused, mille alusel ja millistest perspektiividest ning tasanditest valdkonda kaardistada.

Mudelite loomine on tihti teadmise loomine, mida veel ei ole (näiteks äriplaan ettevõttele). Siin aitab tihti ka mõttekaartide loomine – sa lihtsalt kirjutad välja olemasolevat teadmist ja nähes seda kirjapandult tekivad uued seosed ja mõtted. Igasugused täpsemalt formaliseeritud mudelid (joonised) on ka sarnaste omadustega, kuid seal on väga ranged reeglid, kuidas asju üles kirjutada (joonistada). Neid käsitleme peatükis „IS projekteerimise mudelid”.

Organisatsiooni mudelite loomisest, ehk süsteemianalüüsist räägime, et paremini tagada:

organisatsiooni struktuuri ja protsesside (toimimise) mõistmine; organisatsioonis olevatest probleemidest arusaamine ja nende

parandamise võimaluste tuvastamine; veendumus, et kliendid, lõppkasutajad ja arendajad on

vaadeldavast (info)organisatsioonist ühiselt aru saanud; tuletada (info)süsteemi nõuded, mis toetaksid vaadeldavat

organisatsiooni.

Seega peame natuke uurima organisatsiooni väärtusi, mis mõjutavad organisatsiooni.



Organisatsioon ja IKT

Ettevõtte arhitektuuritasandid

Erinevad tasandid organisatsiooni (ja selle mingisuguse infosüsteemi) kirjeldamiseks:

Enterprice (Strategic Capability) Architecture (kuhu), Business Architecture (kuidas), Information Architecture (kes), Data Architecture (millega), Systems Architecture (kus), Computer Architecture (teostus).

Allikas: http://www.brint.com/papers/enterarch.htm

Arhitektuuritasandite kaardistamist vaadeldakse ka nn Zachmani raamistikus (vt. http://en.wikipedia.org/wiki/Zachman_Framework, http://it.toolbox.com/blogs/tipping-point/information-architecture-under-the-zachman-framework-part-two-conceptual-modeling-29446), kus kõige kõrgemal tasemel vaadeldaks nö konteksti ehk skoopi (kuhu me tahame jõuda), edasi liigutakse kontseptsiooni tasemele (kuidas) ning mõeldakse toimimise loogikale (info süsteemne liikumine). Alles seejärel saab vaadata nn füüsilisele tehnoloogiale (millega ja kus ehk mis tarkvara ja andmekogusid kasutada) ja esitlusviisidele (arvutiekraanil teostatu vms).

Arhitektuuritasanditest annab ülevaate ka järgnev joonis (joonisel linkides peaks avanema PDF fail, milles näha ka alumised kihid).

Joonis 1 Arhitektuuri tasandid

Zachmani raamistikku on edasi arendanud paljud – vt. http://en.wikipedia.org/wiki/Enterprise_Architecture_framework


http://en.wikipedia.org/wiki/Enterprise_Architecture_framework

http://it.toolbox.com/blogs/tipping-point/information-architecture-under-the-zachman-framework-part-two-conceptual-modeling-29446

http://it.toolbox.com/blogs/tipping-point/information-architecture-under-the-zachman-framework-part-two-conceptual-modeling-29446

http://en.wikipedia.org/wiki/Zachman_Framework

http://www.brint.com/papers/enterarch.htm


Näitena veel:Arhitek-tuuri tasand

Kirjeldus Finants-süsteem Kliendihaldus Teadmusjuhtumine ja dokumendihaldus

Äritasand - Organsiatsiooni struktuur

- Äri funktsioonid

- Äri protsessid

- Kontoplaan- Kulude

struktuur

- Klientide segmendid

- Organisatsiooni struktuur

- Töövood

Andmete ja info tasand

- Info paiknemine

- Seosed- Andmevahetus

protsessid

- Andmete allikad

- Andmete struktuur

- Dokumentide struktuur

Raken-duste tase

- Rakenduste loetelu, seosed, elutsükli seisud

- Modulaarsus, arhitektuur

- ERP & raamatu-pidamise programm

- Andmevahetuse protokollid

- BI- Sidusus

müügi rakendustega

- Kasutajaliidese disain

Tehniline tase

- Platvormi teenused

- Tehnoloogiline konfiguratsioon

- SOA- EDI standardid

- Info salvestus-tehnoloogia

Allikas: TCS Consulting Journal 2009, Vol 1

Täiendavat lugemist veel: äritasandi, rakendustarkvara, info ning tehnoloogia tasandite eesmärkidest – vt: http://msdn2.microsoft.com/en-us/library/ms978007.aspx

Ehk veelgi kitsamalt kokku võttes kolm tasandit: Strateegiline ja äri süsteemne vaade (toimivuse mudelid), infosüsteem (infomudel, kasutajaliides, äriloogika, andmekogud), platvorm (serverid, võrk jms).


http://msdn2.microsoft.com/en-us/library/ms978007.aspx


Joonis 2 Strateegiline, valdkondlik ja süsteemi tase (Allikas http://en.wikipedia.org/wiki/Enterprise_architecture)


http://en.wikipedia.org/wiki/Enterprise_architecture


Süsteemi tasand

Infosüsteemide siseselt on eelpooltoodud tasandid ka nö mudelleerivalt esindatud.

_Servers_

Rakenduse kasutajaliides

<- Äritasand

<- Infomudel

<- Tehnoloogia

Joonis 3 Arhitektuuritasandid (Allikas H.Sarv, http://www.tud.ttu.ee/material/enn/)

Rakendusprogrammide asemel vaadeldakse tänapäeval tihti IT valdkonna poolt osutatavaid infoteenuseid. Järgneval joonisel on antud üks võimalik infoteenuste tasanditeks jaotus:

Teenuse liides

Äritasand

Infomudel

Andmestruktuurid


http://www.tud.ttu.ee/material/enn/


Joonis 4 IT teenuse arhitektuuritasandid (Allikas: Aidan Lawes, ITSMF Estonia 2006 aastakonverentsi materjalid)

Või järgmine jaotus:

Joonis 5 Asutuse tervikliku infosüsteemi arhitektuuritasandid (Allikas: Bringing SOA Value Patterns to Life, An Oracle White Paper, June 2006

Selleks et lihtsustada süsteemide juurutamist, rakendatakse erinevate arhitektuuri tasandite juures oma nn mustreid ja standardeid. Üks 21. sajandil tekkinud mõisteid on siin SOA - Service Oriented Architecture. Vt: http://en.wikipedia.org/wiki/Service-oriented_architecture

Infomudel

Vaata ka konspekti 1. osa peatükki „Organsiatsioon ja info“!

Organisatsioonis oleva info kaardistamiseks kasutatakse infomudelit, mis paikneb oma loogilisel tasandil ärimudelite ja andmemudelite vahel. Info arhitektuuri kaardistamisega määratakse aga lisaks infole informatsiooni tekke allikad, tarbijad, edastuskanalid, töötlemisvajadused, säilitamine, kaitsmine ja ka hävitamine.

Informatsiooni eesmärk ja tähendus organisatsioonis määratakse äri tasandil. Seega tuleks vaadelda informatsiooni vajadust ja tekkimist äriprotsesside lõikes. Nii on loogiline, et protsessi omanik on ka ühtlasi informatsiooni omanik, mis selle protsessi käigus tekib, või mis mujalt


http://en.wikipedia.org/wiki/Service-oriented_architecture


hankides oluliste seostega rikastatakse. Nii võib protsessist (ja tegevustest) eraldatud infot käsitledagi pigem andmetena:

joonis 6 Organisatsiooni infoarhitektuur (ARIS). Allikas: Organisatsiooni käsiraamat, Eesti Juhtimiskvaliteedi Keskus (http://www.juhtimine.ee/static/files/27.Inforessursid.pdf)

Dokumendihaldus kui oluline infomudeli osa peegeldab ettevõtte asjaajamist (tõestusväärtust omavate) dokumentide abil, kattes dokumentide loomise, säilitamise, kasutamise ja arhiveerimise protsesse:

ühine arusaam, jälgitavus, tõestavus, muutuste kajastamine (ajaline perspektiiv), andmete kogu pealt saab teostada analüüse, teha järeldusi, infosüsteem on reeglite (dokumentide?) kogu.

Infovajadustest ja nende kaardistamisest on teinud hea ülevaate Priit Parmakson oma ainekursusel „Sissejuhatus infosüsteemidesse“ – vt. http://infosysteemid.blogspot.com/2012/09/loeng-1-infokaitluse-eesmargid.html.

Kokkuvõtlikult võib sealt välja tuua välja, et infovajaduste piisava selgusega (struktureeritud mudelina) esitamine on keeruline ülesanne (erinevad osapooled mõistavad mudelit erinevalt), see on ajas muutuv (ei saa ette planeerida täpselt, vaja paindlikkust) ja sõltub tihti ettevõtetes rolle täitvate isikute subjektiivsetest eelistustest (nii sisulises kui tehnoloogilises mõttes). Samuti kasutatakse samu andmeid erinevate protsesside käigus erinevalt.

Siiski on meetoditena välja toodud (Parmakson 2007): info tarbijate soovide kirja panemine ning samasisulised küsitlused;


http://infosysteemid.blogspot.com/2012/09/loeng-1-infokaitluse-eesmargid.html

http://infosysteemid.blogspot.com/2012/09/loeng-1-infokaitluse-eesmargid.html

http://www.juhtimine.ee/static/files/27.Inforessursid.pdf


dokumentide ringluse analüüs; protsesside analüüs; rollide ja stsenaariumite analüüs; olemasolevate infosüsteemide analüüs.

Konkreetsete mudelitena saab kirja panna veel (Gunjan Mansingh 2009, Building ontology-based knowledge maps to assist knowledge process outsourcing decisions,

http://www.palgrave-journals.com/kmrp/kmrp_process-views-of-km.html): teadmiste allikate kaart; teadmiste väärtuste kaart; teadmiste struktuuri mudel (andmemudeliga sarnane); teadmiste rakenduskaart (probleemipõhine, protsessimudeliga

sarnane, aga ka sisuliselt kõik juhendid, küsimus-vastus jne); teadmiste arenduskaart.

Infoauditi mõistet selgitab lahti ka Elviine Uverskaja Tallinna Ülikoolist (http://www.tlu.ee/opmat/in/Organisatsiooni%20infoaudit ja http://www.tlu.ee/opmat/in/Organisatsiooni%20alusuuring/7_organisatsiooni_infovood.html), tuues välja, et see puudutab inforessursse, informatsiooni kasutamist toetavaid teenuseid, infotehnoloogilist infrastruktuuri ja IT –vahendeid jms. Infoauditi soovitused peavad olema põhjendatud (viited aruande vastavatele osadele), seostatud organisatsiooni eesmärkidega, tuues välja riskid, mis kaasnevad juhul, kui neid soovitusi ei rakendata. Ära tuleks tuua soovituste elluviimisega kaasnevad kulud, rakendamise ajagraafik jms.

Ühe suunana räägitakse veel infovälja juhtimisest, valitsemisest (Information Governance - http://www.edrm.net/resources/guides/igrm, http://www.edrm.net/resources/guides/igrm/using-model). Selles tuuakse info loome, struktureerimise, säilitamise ja hävitamise protsessi juurde sellised aspektid nagu

ärikasumi taotlemine, privaatsus ja turvariskid, IT efektiivsus, ettevõtte riskide juhtimine, juriidilised küsimused.

Tasub teada ka veel mõistet Information Lifecycle Management (ILM - http://blog.it.ee/tag/cobit/, http://en.wikipedia.org/wiki/Information_Lifecycle_Management), mis


http://en.wikipedia.org/wiki/Information_Lifecycle_Management

http://blog.it.ee/tag/cobit/

http://www.edrm.net/resources/guides/igrm/using-model

http://www.edrm.net/resources/guides/igrm

http://www.tlu.ee/opmat/in/Organisatsiooni%20alusuuring/7_organisatsiooni_infovood.html

http://www.tlu.ee/opmat/in/Organisatsiooni%20alusuuring/7_organisatsiooni_infovood.html

http://www.tlu.ee/opmat/in/Organisatsiooni%20infoaudit

http://www.palgrave-journals.com/kmrp/kmrp_process-views-of-km.html


keskendub küll rohkem dokumentide arvutivõrkudes säilitamise tehnoloogiatele, laiendades seda vajalike ärifunktsioonidega.

21. sajandi püsiv trend on olnud nn targa äri (Business Intelligence) temaatika, mis üldiselt kätkeb endas eelkõige vastavaid arvutisüsteeme, mille eesmärk aga on otseselt seotud info targa kasutamisega organisatsioonis, ehk teadmiste juhtimisega. BI protsess - defineeri andmestik, sea infoeesmärk, vaata visualiseeritud reaportit, ehk andmete kogumine ja integratsioon, andmete analüüs, otsustamise tugi.

BI rakendusvaldkonnad (Siim Karus 2013, https://courses.cs.ut.ee/2013/bis/Main/Timetable):

- Kirjeldav analüüs:o identifitseerida probleeme,o jälgida äritegevust,o hinnata tulemuslikkust.

- Ennustav analüüs:o kasumlike klientide sõelumine,o klientide soovidele ennetav reageerimine,o klientide kaotamise ennetamine,o müügi ja tootmismahtude ennustamine,o efektiivsete turunduskampaaniate planeerimine,o valeandmete tuvastamine ja korrigeerimine.


https://courses.cs.ut.ee/2013/bis/Main/Timetable


Omaette kategooria kogu ettevõtte sotsiaalsest kapitalist ning tegutsemisvõimest määrab ka kommunikatsiooni juhtimine, seda nii sise- kui väliskeskkonnas, mida võib peaaegu et lugeda juba äritasandisse kuuluvaks valdkonnaks. Igatahes on see tugevalt seotud subjektiivsusega ja vähem konkreetsete andmeedastusviiside ehk kommunikatsioonikanalitega, ehk viimaste valik ja toimimise efektiivsus sõltub väga palju konkreetse ettevõtte taustast.

Vt. Sisekommunikatsioon - http://et.wikipedia.org/wiki/Sisekommunikatsioon.

Äritasandi mudelid

Alljärgnevalt loetletakse aga olulisemaid külgi ärimudeli osast infosüsteemi loomisel (Polis, 2002 ):

Ärimudel määrab ära kõige üldisemal tasemel nõudmised infosüsteemi arenduseks, sh milliseid süsteemi osi või tarkvaralahendusi üldse vaja on, kas tuleb arendada täiesti uusi, kasutada standardseid või modifitseerida olemasolevaid;

Paljud funktsionaalsed ja ka mittefunktsionaalsed nõuded infosüsteemile kasvavad välja äri modelleerimisest. Seejuures võidakse ära teha ka suur osa tööst nende analüüsimisel ja sobiliku lahenduse kavandamisel;


http://et.wikipedia.org/wiki/Sisekommunikatsioon


Ärimudelist saab palju kasu olla erinevate tarkvarasüsteemide integreerimisel ja nende osade korduvkasutamisel.”

Selge on, et ärimudeli tasemel pannakse paika igasuguste arenduste (sh infosüsteemide) tasuvus, ehk küsimus, millistel tingimustel see arendus ennast ära tasub.

Olgu üldisema konteksti tunnetamiseks toodud näiteks väikeettevõtte tegevuse osavaldkonnad.

SHAPE \*

MERGEFORMAT

joonis 7 Allikas: Johansson, Karjalainen 1996

Või tavapärase (tootmis)ettevõtte põhiprotsess:


HINNAKUJUNDUS

TOOTED/TEENUSED

RUUMID/KESKKOND

SEADMED/TOORAINE

OSKUSED/TEADMISED

MAJANDAMINE/ARVEPIDAMINE

TURUNDUS


joonis 8 Äri protsess (http://www.sney.com/english/services/image/c2_image01.gif)

Veel: http://www.ofm.wa.gov/roadmap/deliverables/businessprocess.htm


http://www.ofm.wa.gov/roadmap/deliverables/businessprocess.htm


Tuntud mudel on Business Model Canvas:

Joonis 9 Business Model Canvas. Allikas www.businessmodelgeneration.com

Paljud kasutavad ka ESSO mudelit, mis toob kesksele kohale teadmusjuhtimise.

Joonis 10 ESSO mudel Allikas: http://www.communitiesofinnovation.com/L/Dr_Michael_Lim_%20Business_Model_Knowledge_Creation_and_Innovation_Lecture%209.ppt

Omaette mudelite perekonna moodustavad kliendi-kesksusele, -lojaalsusele, -juhtimisele jms keskenduvad organisatsiooni, või pigem



üksiku teenuse (ja selle arendamise, disaini) mudelid nagu klienditeekonna, stsenaariumi vms mudelid.

Tootmise spetsiifilisena võiks meenutada ka näiteks tehase virtuaalset mudelit: http://virtuaaltehas.ee/.

Kvaliteedimudelid

Ettevõtluses on äärmiselt oluline äri analüüs ja kavandamine, mis keskendub äriideele ja selle toimivusele turul. Kvaliteet peab aga tegelema selle äriidee kvaliteetsele realiseerimisele.

Miks me selles aines tegeleme organisatsiooni kvaliteediga? Sest infosüsteem on alati konkreetses organisatsioonis rakendatud, ning konkreetsed vajadused saavad selgeks organisatsiooni üldisemaid vajadusi analüüsides. Üldisemad vajadused aga selguvad just tihti kvaliteedi küsimustega tegeledes.

Kvaliteedi auhind (EFQM Excellence Award)

Joonis 11 Kvaliteedi(auhinna) süsteem (allikas: T.Tammaru)

TQM (Total Quality Management) mõiste on kõige laiem (totaalne) kvaliteedi tagamine kui suund, filosoofia. EFQM eesmärk on saavutada võrdlusmoment ajas (vähemalt kolm aastat), oma eesmärkide saavutamises ja teiste sarnaste ettevõtetega. Loe edasi: http://www.eaq.ee/index.php?id=384


http://www.eaq.ee/index.php?id=384

http://virtuaaltehas.ee/


Küpsusmudel (Capability Maturity Model)

Joonis 12 CMM (Capability Maturity Model), allikas V.Leping

CMM hindab organisatsiooni võimekust (mingis valdkonnas) järgida kvaliteetsust tagavaid (formaalseid) reegleid ja mitte sõltuda üksiktegijatest.

ISO 9000 jms

Standard ISO 9000 määratleb järgneva kvaliteedimudeli: Kvaliteedijuhtimise eesmärgiks on saavutada kõigi huvipoolte rahulolu, kelleks on lisaks klientidele ka organisatsiooni kõik töötajad, omanikud, teenuse pakkuja ja ühiskond tervikuna, seejuures pidevalt parendades organisatsioonis toimuvate protsesside tõhusust ja efektiivsust. Selle eesmärgini aitab jõuda hästi toimiv ja üldisesse juhtimissüsteemi integreeritud kvaliteedisüsteem (Tammaru 1999: nr 7).

Kvaliteedijuhtimisega seonduvad sammud (ISO 9000:2000): klientide ja huvipoolte vajaduste ning ootuste määratlemine; kvaliteedipoliitika ja -eesmärkide püstitamine; eesmärkide saavutamiseks vajalike protsesside ja

kohustuste/volituste määratlemine; eesmärkide saavutamiseks vajalike ressursside määratlemine ja

hankimine; protsesside mõjususe ja tõhususe mõõtmise meetodite

väljatöötamine; nende meetodite rakendamine kõigi protsesside juures;



mittevastavuste vältimise ja nende põhjuste elimineerimise meetodite määratlemine;

protsessi loomine ja rakendamine süsteemi pidevaks parendamiseks.

Vaata tasuta koolitusmaterjale: http://www.iso9001help.co.uk/

Balanced Score Card

BSC on nagu EFQM-i mõõtmis- ja tulemikeskne kontsentraat võttes erinevad mõõdikud aluseks ja neid omavahel tasakaalustatult kokku liites saadakse kompaktne tulemuskaart ettevõtte käekäigust.

Joonis 13 Tasakaalustatud tulemuskaart (http://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/55/Default.aspx)


http://www.iso9001help.co.uk/


IKT valdkonna eesmärk oli pakkuda organisatsioonile infoteenuseid – see on infoühiskonnas nagu närvisüsteem organismi juhtimisel.

Joonis 14 Ettevõtte strateegia (BCS)

Kriitiliste edutegurite reaalajas (On-line) jälgimise võimalus on võimalik siis, kui "juhi töölauale" jõuavad analüütiliselt töödeldud andmed kogu ettevõttes toimuvast (monitooring), mitte üksikutest eraldiseisvatest süsteemidest. Millised aga on juhile õigeid otsustusaluseid andvad tegurid, peab ütlema juht ise (kvaliteedi juhtimine!)

Rohkem Strateegilised infosüsteemid

Rohkem Operatiiv-infosüsteemid

Joonis 15 Juhi töölaud



Juhtimise tasandilt antakse infot operatiivtasandile erinevate vahendite abil, alustades tööülesannetest – juhtimine ise ei ole veel tükk aega ilmselt väga hästi infosüsteemi piiridesse paigutatav, kuid suures osas saab seda siiski teha.

BPR (Business Process Reengineering)

Vaata eraldi aine loenguid: MTAT.03.231 Business Process Managament - http://courses.cs.ut.ee/2011/bpm/Main/Lectures

Äriprotsesside ümberkavandamine – eesmärk muuta töö(protsessid) efektiivsemaks või isegi asendada teistsuguste protsessidega. Seda võib võrrelda ka teatud juhtudel standardiseerimisega (mitte samastada!), kui püütakse ettevõtte protsess kohandada standardlahendustega (ka standardsete infosüsteemidega). Tihtilugu arvavad ettevõtjad põhjendamatult, et nad on nii unikaalsed.

Ümberkavandamine on metodoloogiliselt alguse saanud suurettevõtetest, kus seatakse väga selged ja mõõdetavad eesmärgid protsesside efektiivsuse tõstmiseks (positivistlik lähenemine). Mitmetel põhjustel ei ole need hästi üle toodavad VKE-dele, kelle puhul räägitakse ilmingutel põhinevast metoodikast (Phenomenological, Allikas: McAdam 2002)

Joonis 16 Miks protsesse kaardistatakse (Rosemann, http://courses.cs.ut.ee/2011/bpm/Main/Lectures kaudu).


http://courses.cs.ut.ee/2011/bpm/Main/Lectures



Joonis 17 Miks protsesse kaardistatakse 2 (Recket et al, http://courses.cs.ut.ee/2011/bpm/Main/Lectures kaudu).

Aluseks on igasugune dokumentatsioon (asutuse struktuur, tegevus-valdkonnad, töökirjeldused, auditid) aga ka analüüsid (SWOT jms), ajurünnakud ja lihtsalt küsimused (mida ma vajan?). Analüüs toobki selgust selles, miks meil muutusi vaja on? Kas midagi üldse on vaja muuta? Seejärel küsida kontekstivabu ja lahtiseid küsimusi (isegi tobedaid), küsida kõigi käest, ega midagi puudu ole (võttes joonised siis juba aluseks). Käia välja isegi halbu ideid, nii võimalik teistel (meeskonnal) neid parandada, millegi etemaga välja tulla, nõustu esialgu kõigega.

Soovitatav kava: seisundi analüüs (visioon, põhi ja tugiprotsessid), väärtusahela kindlakstegemine , ümberkavandatavate protsesside valimine, nende analüüs (mõõtmine) ja võimalik optimiseerimine, tee kindlaks, milles IKT võib aidata, uue protsessi kirjeldus (oodatav seisund mis arvestab uue IS’iga).

Analüüsi võivad teha asutuse töötajad ise, kasutades vajadusel konsultandi abi (näiteks kvaliteedisertifikaadi taotlemiseks). Tihti kaardistatakse aga ettevõte just uue infosüsteemi arendamise vajadustest Tartu Ülikooli Pärnu kolledž, Taavi Tamberg 20/67



tulenevalt. Tegeletakse ju teadmise tõlkimisega ühest „keelest” teise. Kes tõlgib? Analüüsi meeskond (konsultant), IT meeskond, kes veel?

Vt. hea üleavaate saamiseks ka: http://en.wikipedia.org/wiki/Business_process_improvement

Protsesside analüüsi ja optimiseerimise kohta Reina Uba doktoritöö - http://hdl.handle.net/10062/18709

Teenuste disaini protsess

1. Uurimine (Research) ja läbi käimine (Exploring) - kõik leiud, dokumendid, süsteemi esmane kaardistus, osapoolte ehk vastutajate kaardistamine, osapoolte hoiakute ja huvide teadasaamiseks isegi igasugused mängud, intervjuud, kliendi emotsionaalne teekonna kaart, Mystery Shopping, variantide läbi mängimine, kliendipäevikud paberil (videos), varjuna läbi liikumine (Observation, Shadowing), tehislikult loodud Persona rollis läbi käimine;

2. Süntees - kokkuleppelise mudeli loomine, arusaamine, kõigi rollide (Actor) kaardistus, kontseptsioon, mustrite leidmine, prioritiseerimine, disainiprojekti kavand, Service Blueprint, tehislike Personas’te jaks klienditeekonna terviklikum joonis koos lisadega, põhilised leiud, lahendust vajavad momendid (probleemid mitte lahendused!!!) ja võimalused (mitte piirata konkreetsete ettepanekutega!) disaini seisukohalt;

3. Loomine – jätkata võimaluste ja parenduskohtade kindlaks tegemist (aja kokkuhoiu, automatiseerimise, mugavuse kasv jne), ajurünnakud (fokuseeritud korraga ühele kliendi omadusele), jälle võimalik läbi mängida, loovuse arendamine – väärtuse otsimine (info, peiteaeg/inkubatsioon, valgustus, rakendus), radikaalne disain – muuta asjade välimust totaalselt, funktsionaalne nihestatus (kõver raamaturiiul, arvutimängu toomine lihtsasse füüsilisse vormi Wii), teenuse tüpoloogiast väljapoole mõtlemine (style sheets ehk pildimaterjal teatud fookusest a la kiirteenindus/luksus), luua teenuse prototüübid ehk läbi katsetada mudelina, persona rolli minev meeskonna liige jutustab oma lugu teistele, Story Boards (piltidega, käepärase videolahendusena pildiosadest), entusiasm – kliendi kallistamise ja wow efekti saavutamise taotlemine;

4. Peegeldamine - oma ideede esitlemine disainitava teenuse omanikule, oluline alata selge positsiooniga (Claim), selge esitlus, selge lõpp, kasu (rahaline)?!;


http://hdl.handle.net/10062/18709

http://en.wikipedia.org/wiki/Business_process_improvement


5. Rakendamine - kuidas disain mõjutab äri? töötajate roll (nende muutumine, kaasa tulemine), teenindatavate käitumine.

Joonis 18 Teenuste disaini meetodi progress

vt: http://pc.parnu.ee/~gika333/P%e4rnu%20Service%20Jam%202013/Toolkit.pdf

Seoseid mudelite vahel

joonis 19 Allikas: Juha Vaso, 2005 (http://www.innove.ee/ee/?p=457)


Uuring ja läbi-käimine

Süntees,defineeri)

Loomine,

ideed

Kontsept-siooni peegelda-mine

ideed, võimalused

aeg

BSC* täideviimine (paberist plaanid)* mõõtmine (konkreetsed majandus- likud ja isiklikud eesmärgid)* mõistmine ja sidustumine

EFQMKogu majandustegevuse arendamise ja hindamise raamistik

Mõlemad on suunatud terviklikujuhtimis- ja ohjesüsteemiarendamisele.

Juhtimis- jaohje-

süsteemiarendamine

EFQMBSC

http://www.innove.ee/ee/?p=457

http://pc.parnu.ee/~gika333/P%E4rnu%20Service%20Jam%202013/Toolkit.pdf


joonis 20 Allikas: Forrester Research, Inc.

Quality Circles; Business Performance Management ; Protsessi juhtimine vt: http://www.neti.ee/cgi-bin/otsing?query=protsessijuhtimine ; Change Management (kõik tegevused on eesmärgipärane

muutmine); Lean (kõik tegevused suunatud toote/teenuse väärtusele); Six Sigma (vigade tekkimise minimeerimine); Kommentaare: (http://www.isixsigma.com/library/content/c000613a.asp).

Lõpetuseks peab ütlema, et arendades ettevõtte juhtimist, sh kvaliteedijuhtimist, on kasulik koheselt mõelda ka infosüsteemide arendamisele, sest see on suurepärane võimalus hakata arendama just neid infosüsteeme, mida on ettevõttele kõige rohkem vaja. Nii tagatakse vähemalt eesmärk, et saavutada ettevõtte vajadustele vastav IS.

Joonis 21 IS arendamine on seotud ettevõtte arendamisega (allikas www.globalknowledge.com)


http://www.globalknowledge.com/

http://www.isixsigma.com/library/content/c000613a.asp

http://www.neti.ee/cgi-bin/otsing?query=protsessijuhtimine

http://www.google.com/search?hl=et&client=opera&rls=et&hs=Tge&q=Business+Performance+Management&btnG=Otsi&lr=


IS Projekteerimise metoodikad Infosüsteemi hankimine, ehk projekteerimine, ehk infosüsteemi elutsükkel on läbi aja muutunud järjest mahukamaks.

Joonis 22 Ajaline areng infosüsteemide elutsüklis

21. sajandi arengud on seotud kogu infotöötluse ja IS valdkonna süstematiseerimine teenustena (SLA - Service Level Agreement), mis seotakse juba laiemalt ettevõtte kvaliteedisüsteemidega (ISO 20 000 näiteks). ITIL raamistiku põhjal on teenuse elutsükli osad:

Teenuse strateegia; Teenuse disain; Teenuse juurutamine; Teenuse opereerimine; Teenus pidev uuendamine;

Joonis 23 ITIL strateegiline raamistik ja sidusus kvaliteedumudelitega. (allikas: Aidan Lawes, ITSMF Estonia 2006 aastakonverentsi materjalid)



Seega enamasti ei saa võtta piirideks IS hanke teostamist, sest ennem seda on keegi tunnetanud vajadust (probleemi) ja pannud kokku hanke tingimused. Seega on ettevõtte seisukohalt IS arendusprojekt pikem kui hange, lõppedes kas IS rutiinse kasutusena, või ka jätkuprojektidena – vananenud IS asendatakse uute versioonidega “pidevalt”.

Teenuse elutsükkel võib olla vaadatud ka etappides. Teenus on: idee tasandil; kandidaat (projekt, arendamisel); tootmises ehk kasutusel; sulgemisel.

Miks üldse on vaja infotöötlust analüüsida, arendada, vanu infosüsteeme välja vahetada? Üldiselt alustab ettevõte IS arendusprojekti:

uus lahenduste/hinna/tehnoloogia tase turul ettevõtte laienemine, muutumine; infotöötlus on reeglipäratu (puudub süsteem); toimiv infotöötlus ei vasta sisuliselt ettevõtte vajadustele; piiravad võimalused senises süsteemis erinevad süsteemid ei ühildu; vana infosüsteem on probleemne. töödeldava infomahu kasv; riist- ja tarkvara vilets töökindlus; pole tagatud õigeaegne juurdepääs vajalikule infole; arvutikasutaja madal oskustase; valed otsused süsteemi arendamisel.

Samuti meenutame, et iga teenuse puhul on võimalik valida, kas: teha ise (arendus, sh kohandamine) , tellida spetsiaalne (või partnerlussuhe), kohandada standardmoodulitest (nn pooltoodetest, tellimus), osta valmistoode, rentida valmistarkvara/lahendus (ASP, SAAS).



joonis 24 Optimaalse kuluarvestussüsteemi kujundamine (Allikas: Kaplan S.R. 2002)

Sõltuvalt sellest, kui suureks hindame riski, et vähene eelnev analüüs viib ebasobiva süsteemi hankeni (vigade maksumus), saame kasutada erinevat IS hankimise kava:

Süsteemi analüüs, nõuete analüüs, kavandamine, programmeerimine, testimine, juurutamine ---------------------------------------------- Kliendi projekt ----------------------------------------------->> ( ---------------) -------------------- Tellimus -------------------------------- (-----------) (--------------) ------------ ---- Hange --------- (-----------) (-------) --- standardtoode (ost) ---

Joonis 25 Tarkvara projekti maht olenevalt IS keerukusest.

Näiteid standardtoote ostust (paratamatus): kontoritarkvara valik

Näiteid hankest (valik olemasolevatest lahendustest): platvormi valik, suhtluskanalite valik, standardse majandustarkvara hange

Näiteid tellimusest (piiratud aeg ja raha): lihtsam veebileht, majandustarkvara tellimine

Näiteid projektist (nõutav funktsionaalsus): tootmise infosüsteemi arendusprojekt

On välja toodud hulk asjaolusid, millega peab arvestama IS arendamisel:



Kvaliteet: äri arhitektuurile vastavus (modelleerimine), äri vajadustele vastavus, ühine arusaam huvipooltel ja tootjal, kvaliteedi juhtimise printsiipide jälgimine, entusiastlik projektijuht (võib olla väljastpoolt), läbimõeldud juurutusplaan.

Hind: saada esimesel korral õige kätte (analüüs!!!), varane ärikeskkonna vajadustele vastavuse test (1:100

reegel!), iteratiivsus üldises plaanis kohe arvesse võetud, oma (kaudsedki) ja konsultandi kulud – a’ 50%, tippjuhtkonna toetus.

Aeg.

IS arendusmetoodikate jaotus: adaptiivsed, agiilsed ehk kohanduvad; ennustavad.

Vt: projektikas.doc lk 7-8.

Adaptiivsete arendusmetoodikate ühisnimetajad võetakse kokku nn. väleda arenduse manifestiga, mis on kirjas aadressil http://agilemanifesto.org/

1. Pigem indiviidid ja suhtlus kui protsessid ja tööriistad, 2. Pigem töötav tarkvara kui palju dokumentatsiooni ,3. Pigem koostöö kliendiga kui vaidlused lepingu täitmise üle ,4. Pigem vastutulek muudatustele kui kramplik kinnipidamine plaanist.

Väledate arendajate manifestile ei ole midagi ette heita peale selle, et see on idealistlik. Reaalses maailmas põrkub väle arendus mitmetele probleemidele.

1. Kui protsessile eelistatakse indiviide, siis on indiviidide vahetus samas väga valuline. On paratamatu, et inimesed vahetuvad, nendega võib midagi juhtuda. Inimeste lahkumine ei pruugi kokku langeda projekti eduka lõpu ajaga.

2. Kui dokumentatsioonile eelistatakse töötavat, ”käegakatsutavat” tarkvara, siis võib süsteemi hooldamine ja täiustamine osutuda tunduvalt kulukamaks. Reeglina antakse süsteemidele garantii, mis on küllalt pikk et tuntav hulk arendajaid jõuaks vahetuda või siirduda teisi projekte teostama.

3. Klient suhtub arenduse mahu suurenemisse ja muudatustesse seni positiivselt, kuni ta selle eest maksma ei pea. Kui aga täienduse tegemisel küsitakse iga liigutuse eest lisaraha, kaovad soojad tunded ja hakatakse ajama näpuga järge lepingus.

4. Muudatustele lõpmatu vastutulek seab ohtu projektiplaani ja järgmised projektid. Kui ressurside osalemise pikkus projektis ei ole ennustatav, muudab see pikaajalise planeerimise võimatuks.

Põhimõtteliselt, kui projekti eelarve on külluslik, sobib väle arendus puhtal kujul väga hästi, paremini kui ennustav arendus, kuna sama raha eest saadakse rohkem funktsionaalsust.


Majandusinfosüsteemid. osa II sügis 2012Fikseeritud eelarve tingimustes tuleb valida metoodika, mille alusel koostatud projekt on võimeline sellises olukorras ellu jääma.

joonis 26 Allikas: http://wiki.flashline.com/wiki/index.php/Initiative%20Overview

Arendusmetoodikaid on välja töötatud palju: Scrum (Eesti 2012 aastal ilmselt enimkasutatud agiilne tarkvara

arendusmetoodika), Extreem Programming (XP), Rapid Application Development (RAD), Prototyping, Adaptive Software Development (ASD), Crystal, Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD), ISO 12207.


http://wiki.flashline.com/wiki/index.php/Initiative%20Overview

http://wiki.flashline.com/wiki/index.php/Initiative%20Overview


Projektijuhtimine

Projekt on kindlate (mõõdetavate) eesmärkidega tegevuste hulk, allutades nende eesmärkide saavutamiseks konkreetsed (hulgaliselt) ressursid: aeg, raha, inimesed jne. Projektide kõrval kasutame tavaliselt püsitegevusi. Seega võime tavapärast tööd vaadata evolutsioonilise arenguna, aga projektitööd, kui revolutsioonilist arengut.

Projekti eesmärkide puhul alustatakse ikka tipust:

allikas: Informit.com 2003

Eesmärgid paigutatakse aga hiljem põhjuslikesse seostesse, mida võib esitada rangelt puukujulise hierarhiana, või paigutada olulisim eesmärk keskele ja alameesmärgid selle ümber. Samuti tehakse probleemidega, mis takistavad eesmärke saavutamast.

Üsna hea ülevaate projekti juhtimisega kaasnevatest valdkondadest annab järgnev loetelu (tõlkimata kujul):

Create a project plan including at least these topics: background , objective , tasks , limits , environment , schedule , risks , quality management , change management , project organisation .

allikas: Eija Kalliala, Page updated 04.08.2000



Ressursside allutamisest annab hea ülevaate Gantti diagramm:

ID Task Name Duration Cost0 e-õppe analüüs 92 days 69 600 kr1 Uuring 40 days 7 680 kr2 Eelnevate uuringute analüüs 10 days 960 kr

3 Küsitlusankeet 20 days 1 920 kr

4 Ekspertintervjuud 10 days 2 400 kr

5 Kokkuvõtte tegemine 10 days 2 400 kr

6 Protsessi analüüs 32 days 57 600 kr7 Konteksti analüüs 2 days 9 600 kr

8 Äriprotsessi analüüs 10 days 19 200 kr

9 Infotehnoloogiliste vajaduste analüüs 10 days 19 200 kr

10 Tulemuste kooskõlastamine 10 days 9 600 kr

11 Järeluuring 20 days 4 320 kr12 Küsitlusankeet 15 days 720 kr

13 Ekspertintervjuud 10 days 2 400 kr

14 Kokkuvõtte tegemine 5 days 1 200 kr

Aprote[2%]Aprote[2%]Aprote[5%]

Aprote[5%]

AproteAprote[40%]

Aprote[40%]Aprote[20%]

Aprote[1%]Aprote[5%]Aprote[5%]

M1 M2 M3 M4 M5 M6 M7 M8

Joonis 27 Gantti diagramm e-õppe alase uurimuse projektist

Iga tegevus allutab teatud ajaperioodile lisaks ka rahalisi- ja inimressursse, ning võibolla veel ühtteist (vahendid jms).

Projektijuhtimise üks olulisemaid momente on jälgida kõigi osapoolte vajadusi, alustades eelkõige põhilistest (tellija) eesmärkidest aga tegeleda ka näiteks tasuvuse analüüsiga (vaata ka http://infosysteemid.blogspot.com/2007/10/loeng-6-infokonoomika.html)


http://infosysteemid.blogspot.com/2007/10/loeng-6-infokonoomika.html


Koskmudel

Etapid:

Joonis 28 Koskmudel

Koskmudel on lihtne (lineaarne) etapiviisiline lähenemine, mis aga reaalsetes situatsioonides sisaldab mitmeid probleeme ja riske. Need aga ilmnevad alles projekti lõpus, millal on nendele reageerimine tihti võimatu, ehk liialt kallis (reegel 1:100).

Üldiselt aga kasutatakse just koskmudelit väiksemate infosüsteemi arenduste puhul (koos projektimudeliga).

Turvumiseks: http://www.riik.ee/riigikantselei/ahb/is/tolked/planeer.htm

Vaata ka Kaspar Loog, Tarkvara tehnika, loeng 1 (http://www.hot.ee/kasparloog/)

Võrdle ka teadmusjuhtimise (Knowledge Management) kavaga (Allikas: http://www.baltic-it.net): knowledge goal, knowledge identification, knowledge acquisition, knowledge development, knowledge distribution, knowledge application, knowledge storage and transfer, knowledge evaluation.


http://www.baltic-it.net/

http://www.hot.ee/kasparloog/

http://www.riik.ee/riigikantselei/ahb/is/tolked/planeer.htm


Spiraalmudel

Spiraalmudeli puhul teostatakse mingi kokkulepitud (ka projekti jooksul tunnetatud vajadusest lähtudes) hulk iteratsioone, ehk läbitakse teadlikult etappe mitu korda. Seda tehakse, et tagada tulemuse vajadustele vastavus (muudatuste juhtimine). Iteratsiooni mõiste asemel kasutatakse vahel ka versioonimise mõistet.

Joonis 29 Spiraalmudel. Allikas: Spiral Model (Boehm, 1988) Original Creator: Conrad Nutschan (http://www.e-uni.ee/e-kursused/eucip/arendus/1223_spiraalmudel.html)

Iteratiivne lähenemine on ühest küljest levinud ka üldisemas mõttes, ettevõtte sisemisel, pideva täiendamise (versioonimise) korral. Võib rakendada väikeettevõtetes kui pikaajalist arenguprotsessi ja suuremates ettevõtetes suurte (üle ühe aasta kestvate) projektide puhul.

joonis 30 Versioonid, kui iteratiivne lähenemine (allikas RUP)


http://www.e-uni.ee/e-kursused/eucip/arendus/1223_spiraalmudel.html


Scrum

Scrum iteratiivset (korduvalt samu tegevusi läbivat) metoodikat rakendav meeskond koosneb loodava toote omanikust (esindaja), arendus-meeskonnast ja nn Scrum Masterist (projektijuht). Meeskond peaks olema välistest (metoodilistest) piirajatest võimalikult vaba, mis tähendab et meeskonnas peaks ka kõik vajalikud kompetentsid olema esindatud.

Joonis 31 Scrumi protsess (Allikas: scrum.ee)

Projekti omanik tagab eesmärgi ning vajalike funktsionaalsuste sõnastamise (tegemata tööde loetelu ehk Backlog), nende prioriti-seerimise (sprindiks valimine) ja arusaadavuse arendusmeeskonnale.

Arendusmeeskond on sõltumatu oma töö korraldamisel kuidas neile antud ülesanne valmis teha. Meeskonnas on kõik liikmed (3 kuni 9) sama ametinimetusega ja võrdsed, sõltumata sellest, mida keegi meeskonnas teeb (erinevad oskused ja rollid tegevuste juures ikka), vastutatakse ühiselt! Tööd koordineeritakse suuliselt, meeskonnavaimus.

Projektijuht (Scrum Master) peab tagama metoodika korrektse rakendamise aidates projeti omanikku tehniliste küsimuste (kuidas hallata Backlogi jms), kommunikatsiooni (nii arendusmeeskonnaga suhtlemisel kui teiste huvigruppidega), sprindi jms koosolekute korraldamisel jne. Samuti aitab arendusmeeskonnal iseorganiseerumist saavutada, olla sprintides tulemuslik. Projektijuht korraldab ka rakendatavate sprindi tulemuste hindamise ning juurutamise kliendi organisatsioonis.

Vt. http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf


http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf


MSF

Microsofti poolt pakutav (MSF – Microsoft Solutions Framework) „kesktee” ehk proovitud võtta parim mõlemast mudelist:

joonis 32 MSF Process Model Phases, Milestones and Versions http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx

MSF toob välja, et on vaja: liikuda pidevalt visiooni suunas, ole paindlik – asjad muutuvad, keskendu ärilise väärtuse loomisele, info avatus kõigile – kontsentreeritus ja struktureeritus, defineerida:

tellija, kasusaajad, lahenduste pakett (dokumentatsiooni ja koolituseni välja), funktsionaalsus/aeg/ressursid – olulisim ennem, protsess/vahetähtajad(tagasiside tellijalt), kus põhivastutus

liigub ühelt meeskonnalt teisele.


http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx


joonis 33 MSF Meeskonnad

Igas meeskonnas võib olla ka ainult üks inimene, kokkuvõttes võib inimesi olla veelgi vähem. Pisemate projektide tarbeks ei saa luua erinevate teemade jaoks suuri gruppe. Kuid on teatud rolle, mida ei tohiks täita üks inimene!

joonis 34 Rollide kombineerimine väikeprojektide jaoks (allikas MSF Team Model)



RUP

Rational Unified Process on firma Rational poolt komplekteeritud tegevuste järjestus hea tulemuse saavutamiseks infosüsteemidele, mis baseerub spiraalmudelil, kuid on võtnud sisse ka koskmudeli omadusi.

RUPi saab rakendada nii väleda arendusena kui ka ennustava arendusmetoodikana. RUPi rakendust väleda arendusmetoodikana on nimetatud dX arenduseks (keera XP tagurpidi). Selle kirjeldus on http://www.objectmentor.com/publications/RUPvsXP.pdf

Joonis 35 RUP

Vaata ka Kaspar Loog, Tarkvara tehnika, loeng 2, (http://www.hot.ee/kasparloog/)

Joonis 36 Spiraalmudeli rakendamine (RUP näitel)


http://www.hot.ee/kasparloog/


Etapid

Lähteuuring

Lähteuuring (inception) võib olla teostatud osaliselt ka infosüsteemi (tarkvara) tellija enda poolt. Kui organisatsioon vaatab üle oma visiooni ja strateegiad, hetke situatsiooni ja võimalused, ning leiab vajaduse ja võimaluse uue infosüsteemi järgi, siis ta algatab projekti, mille tulemuseks peaks olema ettevõtte vajadustele (visiooni realiseerimisele suunatud, strateegiatega kooskõlas, ettevõtte väärtust tõstev jne..) vastav infosüsteem.

Lähteuuringu põhitegevused on äri analüüs (vt. RUP, Business Modeling) ja nõuete analüüs (vt. Requirements). Nende tulemustena saadakse dokument, mis üldjoontes peaks sisaldama:

o Infosüsteemi visiooni, ehk üldist arusaama infosüsteemi toimest organisatsioonis, milliseid ettevõtte vajadusi rahuldab. Üheltpoolt ülevaatlik (ettevõtte juhtkonnale ja teistele huvigruppidele lugemiseks), teisalt aga mahukas (eelkõige koos järgnevate lisadega) ja poolte poolt allkirjastatud põhidokument.

o Projekti ressursside hinnang (Business Case, finants, ROI, aeg) ja selle kõrval ka tarkvara arendusprojekti plaan (iteratsioonide arv, muudatuste juhtimise viisid jne).

o Kasutusjuhtumeid (Use Case joonised) koos spetsifikatsiooniga, kes ja mida selle loodava infosüsteemiga teha saavad (funktsionaalsed omadused);



o Kasutajaliidese prototüüpi (üldkujundus) ja süsteemi mittefunktsionaalsed omadused (arhitektuur, platvorm, selle kasutamine üldeesmärkidest lähtuvalt);

o Mõistete sõnastik, et kõik osapooled saaksid asjast ühtemoodi aru;

o Esmast riskianalüüsi (Risk List)

Kavandamine

Kavandamise etapis liigutakse täpsema detailsuse poole nii äri analüüsi, kui nõuete analüüsiga. Lisandub infosüsteemi nõuete projekteerimine loogilisel tasandil, info (faktide) sõelumine ja klassimudelite (andmemudelite) loomine. Tööd alustavad programmeerijad esimeste prototüüpide kallal, alustades üldiselt kasutaja liidesele esmase funktsionaalsuse andmisest.

Vt. http://math.ut.ee/~olegm/teach/sysmod/examples/it-osakond.html

Muud etapid Konstrueerimine (versioonimine, kuni sobiva tulemuseni); Üle viimine (installeerimine ja testimine tellija juures,

integratsioon, koolitus, kasutajatugi).

TegevusedÄri analüüs (Business modelling)

Ärikontekst IS loojatele: äri seisundi kaardistamine; põhi- ja tugiprotsesside kaardistamine ja täpsustamine;

Ärimudeli loomine: kasutusjuhtumitest alustades; kuidas realiseeritakse (automatiseerimisvõimalused jms); rollid ja vastutus.

Selle tulemuseks on ka võimalike vajaduste nimekiri loodava IS mõistes, eesmärk ning nende vajaduste (IS funktsionaalsete ja mittefunktsionaalsete omaduste) põhjendus. Aga ka see, millises keskkonnas loodav IS tööle hakkab.


http://math.ut.ee/~olegm/teach/sysmod/examples/it-osakond.html


Joonis 37 Äri modelleerimise tegijad ja tegevused

Põhilised rollid on äri loogikat tundev analüütik ja praktik ning ülevaataja.

Joonis 38 Äri analüüsi protsess (RUP)



Joonis 39 Äri analüüsi tehnikad ja tulemused

Nõuete analüüs

Luua loodava IS mudel (paralleelselt äri ja infomudeliga) Probleemide leidmine ja analüüs, tellija vajaduste analüüs

(kasutusjuhtumite loomine) ; Nõuete defineerimine ja täpsustamine iga kasutaja tegevuste

osas IS-iga suhtlemisel, edasine muudatuste viimine nõuetesse (kasutusjuhtumid on kirjeldatud ja nõuded täpsustatud);

Valdkonna sõnastik (selgitused tellija-tootja ühise arusaama loomiseks);

Infosüsteemi piirid (kasutuslugude ja protsessimudelite täpsustamine IS jaoks, tarkvara arhitektuur – süsteemi objektid, seosed ja liidesed);

IS arhitektuuri kirjeldus; platvormi valik, mis on sarnastes situatsioonides mujal

sobinud, või mis on piiranguks olemasolevas keskkonnas tellija juures,

millised on tavalised interaktsioonid komponentide vahel; Kasutajaliidese prototüübid.



Joonis 40 Nõuete analüüsi tegevused

Põhilised rollid on süsteemiteooriat tundev analüütik, nõuete disainer ja ülevaataja, tarkvara disainer (arhitekt) ning kasutajaliidese disainer.

Joonis 41 Nõuete analüüsi protsess



Muud tegevused Detailne projekteerimine (analüüs ja disain); Programmeerimine (koodi kirjutamine); Testimine; Juurutamine.

Toetavad tegevused Muudatuste juhtimine ; Projektijuhtimine; Töökeskkonna haldamine;

(CVS – Concurrent Versions System).

Kui midagi jääks tegemata

Kui midagi jääks tegemata, ehk ohud: Süsteemianalüüs jääb tegemata: puudub arusaam sihtidest, võimatu

kontrollida eesmärkide täitmist; Projektijuhtimine puudulik: puudub võimalus jälgida ja juhtida

protsessi, tegevused venivad; Riskianalüüs tegemata: eesmärgid võivad ootamatult saavutamata

jääda; Iteratiivsust pole: ei suudeta saavutatut jälgida, puudub tihe side

tellija/tootja vahel, tellija huvi väheneb; Vahetulemuste kontrolli pole: puudub arusaam saavutatust; Nõuete haldamist pole: kaob arusaam tervikust, projekt võib jääda

venima; Kasutaja ja IT tugi puudulik: süsteemi ei hakata (efektiivselt)

kasutama.



Pakkumiskutse

Millest juhinduda

Pakkumiskutset võib vaadata ka kui üht levinumat vahedokumenti infosüsteemide projekteerimisel üldse. Kui suures mahus see realiseeritud saab, määrab tihti projekti või hanke maht.

Praegu aga vaatame, mida võiks sisaldada ühe keskmise tellija põhiline alusdokument (projekt), mis on nõuete spetsifikatsiooni koostamise alus ehk tarkvara lähteülesanne:

Kontekst (mõistete sõnastik); Visioon:

miks? - kasutusjuhtumid, kelle jaoks? - kirjeldus võtme kasutajate profiilidest, äri kontekst, äri arhitektuur, tasuvus (tööaja kokkuhoid, transaktsioonikulude

vähenemine, efektiivsuse kasv, käibe kasv, adekvaatsemad juhtimisotsused vms);

Funktsionaalsus (mida? Äri reeglid): Analüüsi (kvantitatiivne ja kvalitatiivne) võimalus –

millistele küsimustele annab see süsteem vastuse? Integreeritus, Kogu ettevõtet hõlmav (?ekstranet – edasi?);

Mittefunktsionaalsed nõuded (kuidas, piirangud süsteemile); Nõuded projekti käigule:

millist metoodikat, suhtlusvormi kasutatakse, suhted projekti ajal, garantiitingimused, juurutamine ja koolitus;

Ligikaudne projekti ressursimaht (aeg, raha, inimressurss); Riski analüüs (mis juhtub, kui ...); Pakkumiste hindamise kriteeriumid.vt: http://wiki.flashline.com/wiki/index.php/PatternBookOpenSource

Kui see dokument on enda jaoks valmis, siis tuleb tootjatele esitada konkreetsed hanke tingimused. Eesti avaliku sektori asutused peavad järgima siin riigihangete seadust.


http://wiki.flashline.com/wiki/index.php/PatternBookOpenSource


Pakkumiste hindamine

Pakkumiste laekumisel on vaja neid omavahel hinnata, et leida parim pakkuja. On hea (ja riigihangete seaduse järgi kohustuslik), kui pakkujatele on ette teada, mille alusel nende pakkumisi hinnatakse.

Infosüsteemi tasuvuse analüüsist tulenevalt tuleb panna paika proportsioonid, ehk anda protsentuaalselt osatähtsused või punktide arvestuse skeem lisaväärtuste eest:

funktsionaalsed omadused, mittefunktsionaalsed omadused, hind (soetushind: kõik kaasnevad kulud riistvarale, tarkvarale,

koolitusele, oma protsesside ümberkorraldamisele jne ning püsikulu: rendimaksed, arendused/versioonid, oma töötajate kulu),

tarneaeg, integratsioon ja juurutusprotsess (paigaldamine, koolitus,

kasutajatugi, andmete sisestus või ületoomine, kohepealne testimine jms.),

pakkuja kvaliteet/tunnustatus, teenuste hindade stabiilsus, kogemused antud süsteemi valdkonnas, käive, teised kliendid, meeskond/stabiilsus,

SLA teenusleping, tugiteenus, garantii.

Mille eest maksta enam? Konsultatsioon ja projekti juhtimine, dokumentatsioon; Turvalisus (säilivus, kaitstus, autentsus); Mitme (kui suure hulga?) kasutaja tugi (administreerimine); Andmehalduse lihtsustamine/automatiseerimine; Kasvava süsteemi keerukusega võitlemine, hallatavus; Standardiseeritus, ühilduvus/ integreeritus, toote areng

(versioonid); Vajadustele vastavus, parem eesmärgipärasus, ROI; Positiivne kaasmõju ettevõtte arengusse (kvaliteedi tõusu).



Infosüsteemi omadused (nõudete spetsifikatsioon)

Nõudeid on vaja selleks, et erinevate osapoolte vahel (sh. lepingus?) fikseerida arusaam tellija vajadustest, et pakkuja teostatav tulemus kataks neid võimalikult hästi, teisest küljest aga selleks, et fikseerida uue infosüsteemi piirid ja omadused. Võrdle ka ASP SLA-ga!

Nõuded on ajas muutuvad, mistõttu on tihti oluline tegeleda nõuete (muudatuste) juhtimisega, kuna nõuded on teineteisest sõltuvad ja mõnikord võivad olla teineteise suhtes vastuolulised.

Põhimõtteliselt jaotatakse nõudeid funktsionaalseteks (mida?) ja mittefunktsionaalseteks (kuidas?) nõueteks.

Funktsionaalsus (mida? Äri reeglid) Kõik, mis seotud andmete (info) töötlemisega tulemusteks, alates infotöötluse eesmärgist kuni detailse kirjelduseni, milliste andmetega (andmetüüpidega) milliseid töötlustegevusi ette võetakse ja kes neid peab kasutada saama. Mida IS teeb info töötluse mõttes, ehk kuidas süsteem käitub

erinevate sisendite puhul (andmed ja juhtimine, y=fn(x), kus Y on väljundandmed, X sisendandmed, Fn – erinevad juhitavad funktsioonid). Sisendite ja väljundtulemuste (andmete) funktsioonid, olulisus ja hierarhilisus (detailsuse aste);

Kes kasutab, millise eelnimetatud funktsiooni pärast (võimalik struktureerimise - milliseid funktsioone pakub IS äritasandil);

Milline on kasutusõiguste süsteem; Protsessid, mida kaetakse, mida teenindatakse;

Andmete keskselt, infovajaduste (sh muutmise vajadus) kaardistus rollide ja funktsioonide kaupa;

Sisendandmete kvaliteedi kontroll/tagamine; Andmete sisestus ja väljastuse juhtumid (transaktsioonid

inimeste ja teiste süsteemidega); mis tüüpi andmetega, kas tekstiline, tabel, pilt, vormide,

arvandmete vms. NB! mitte millist erinevat sisulist informatsiooni omab;

Mittefunktsionaalsed nõuded: Kasutatavus, kasutajaliides (kuidas, kus), sh:

arhitektuur (käsurida, menüüd, graafiline, veebiliides, ...); õpitavus (standardsus); kasutajasõbralikkus (jälgitavus, haaratavus);



paindlikkus (andmetest eraldatus, kasutaja poolt kohandatav, vt. www.live.com) ;

jõulisus (kui palju saab muuta, sekkuda) jms.; kasutajale orienteeritus;

Turvalisus (vt. I osa lõpust); Usaldatavus (MTBF, taastamisvõimalused jne..); Jõudlus (andmemahud, juurdepääsumahud, kiirus, viited jne..); Arhitektuur (sisemine ja väline) ja platvorm (nimetatakse ka kui

piirangud arendusele), sobivus muude süsteemidega; Teenindatavus (testid, hooldus, ühildatavus, konfigureeritavus

jne..) ; Eranditega arvestamise võimalused (paindlikkus); Muutustega kaasaminemise vajadus (versioonimine, uuendused).

Loe veel:

- http://en.wikipedia.org/wiki/FURPS

- www.ria.ee/public/publikatsioonid/Mittefunk_nouded.doc

AberdeenGroup poolt 2006. aastal läbiviidud uuringu alusel oli IS aren-damise olulisemateks nõueteks just paljus mittefunktsionaalsed omadu-sed, mis puudutavad integreeritust teiste süsteemidega, sobitumist kesk-konda. Samas on sidusus teiste süsteemidega ka funktsionaalne omadus!

joonis 42 Allikas: AberdeenGroup uuringu tulemus – Nõuded infosüsteemidele.

Vaata ka: http://pc.parnu.ee/taavi/ikt/mis/mis2004/rup/requirements.htm http://www.tud.ttu.ee/material/enn/Juhtimisinfo/Loeng9RoiforEnterprisePortal.ppt

Püüa kirja panna tekstitöötlusprogrammi funktsionaalsed ja mittefunktsionaalsed omadused


http://www.tud.ttu.ee/material/enn/Juhtimisinfo/Loeng9RoiforEnterprisePortal.ppt

http://pc.parnu.ee/taavi/ikt/mis/mis2004/rup/requirements.htm

http://www.ria.ee/public/publikatsioonid/Mittefunk_nouded.doc

http://en.wikipedia.org/wiki/FURPS

http://www.live.com/


Muid metoodikaid ja näiteid EestistObject Modelling Technique (OMT)

Teostatakse infosüsteemis kasutatavate andmete ja nendevaheliste seoste kaardistamise alusel süsteemi loomiseks:

Kontseptsioon (kellele/milleks/mida on vaja); Analüüs (detailne ülesande püstitus); Süsteemi disain (mittefunktsionaalsed reeglid, ekraanivormid jms); Detailne disain (andmebaasi mudelini välja); Teostus; Test/Installeerimine/Hooldus.

Kontseptsioon (tavalised laused, mida, kes ja miks peab saama teha, kellele see tarkvara on mõeldud? Milliseid probleeme see tarkvara lahendab? Kus seda tarkvara kasutatakse? Millal seda tarkvara vajatakse? Ajapiirangud/tähtajad + 24x7? Mis põhimõttel see tarkvara töötab? Põhilised tegevused)

Analüüs (mida tuleb teha, mitte kuidas realiseerida):1. Ülesande definitsioon (semantiline, min. funktsionaalsus);2. Objektmudeli loomine (joonis, mis kirjeldaks loodava andmebaasi

struktuuri); Otsitakse definitsioonist välja kõik nimisõnad (Objekti

kandidaadid); Elimineeritakse sarnased, mitteasjakohased, atribuudid,

tuletatavad jms; Otsitakse välja kõik tegusõnad (Seoste kandidaadid); Elimineeritakse elimineeritud objektide seosed,

ajutised/arvutatavad jne; Määratakse atribuudid (elimineeritud objektidest pluss

lisa/taustainfost); Iteratsioonisammud, kus testitakse seoste kaudu, kas saab

korrektseid andmeid leida.

Tulemuseks saadakse andmemudel (vt. Andmemudel, lk 60).



Service-Oriented Modelling

Baseerub SOA-l (http://en.wikipedia.org/wiki/Service-oriented_architecture).

joonis 43 Michael Bell's Service-Oriented Modeling Framework: Depicted in Service-Oriented Modeling: Service Analysis, Design, and Architecture, Wiley & Sons, 2008, Chaper 1 (introduction)

Traditsioonilise olukorra muutmiseks äriloogika jaoks sobivamaks

joonis 44 Allikas: Bringing SOA Value Patterns to Life, An Oracle White Paper, June 2006


http://en.wikipedia.org/wiki/Service-oriented_architecture


ML Arvutid

Ettevõtte 2004. aasta käive 245 mln EEK. Tegevuse sisuks arvutite komplekteerimine komponentidest (12-20 tk, iga kohta 3-20 valikut, kokku kombinatsioone 400 000). Tarnevõime peab olema tagatud 2-3 päeva, kusjuures laoseis minimaalne, sest hinnad langevad 2-10% kuus, tihe konkurents madalatele arvutihindadele turul.

Majandustarkvaraks kasutati Concorde XAL’i, mille puudused tuvastati juba 2001. Otsus juurutada uus süsteem 2003 juuni.

Põhilised nõuded: All-in-One (tootmine ja müük); 24/7 töökindlus; Integreeritav enamlevinud kontoritarkvarade ja andmevahetus

protokollidega; Laiendatavus väikeste arenduskuludega; Veebipõhine iseteenindus.

Projekti käik: Juurutaja valiti 2003 septembris, tähtajaga 2004 veebruar. Uus süsteem on Axapta. 2004 nov lisati kassasüsteemi moodul ja varsti ka veebipõhine klientide iseteenindusmoodul. Transaktsioonide maht on peale juurutust kasvanud 30%, mis ei ole vajanud lisatööjõudu! Juurutaja sai umbes 300 000.- kr, millele lisandusid tarkvara litsentsi kulud.

Pakkujate hindamise tabel:Tingimus % I koht II IIIKOKKU 1 1,6 2,2Disain + Arendus 70 1 1,4 1,6Paigaldus/Juurutus 19 1 1,2 3,3Koolitus + Järgnev 11 1 1,3 2,5Analüüsi osa kogumaksumuses

0 0% 12% 15%

Parim pakkuja lihtsalt tundis hästi meie valdkonna protsesse!

KEK Trading

Ettevõtte tegevusvaldkond – pakkematerjalide kaubandus Läänemere maades, hankepartnerid üle maailma.

Probleemiks



ülevaate puudumine firmas toimuvast, sellest tulenevad valed otsused;

dubleerivad tegevused, ebaefektiivsus; telefonimäng, ehk info moondumine edastamisel; vastutuse ebaselgus.

Nõuded: ühtne majandustarkvara; sünkroniseerida toodete andmed; standardiseerida aruandlus.

Valitud majandustarkavara eelised: kiired ja selged vastused; sarnane arusaam ja klapp pakkujaga ; pakkuja kiired lahendused algusetapil; pakkuja poolse „lihtsa keele” arusaadavus.

Projekti käik: meeskonna loomine mais 2004; plaan: tulemus töötab oktoobriks; ärivajaduste uuring juunis; andmete standardiseerimine augustiks; toodete süstematiseerimine oktoobriks; koolitus 2 nädalat, tegelik töö algus novembris.

Soovitused: kõik uuest süsteemist mõjutatud töötajad kohe kaasa haarata; üldise töökorralduse muutusega arvestada; hoolikalt vajadused läbi mõelda; kokkulepitud kursilt mitte kõrvale kalduda.

Lisalugemist ja arutlemiseks IT projektide haldamine: http://www.ria.ee/26308; http://www.tehnokratt.net/stories/storyReader$31960 .


http://www.tehnokratt.net/stories/storyReader$31960

http://www.ria.ee/26308


IS projekteerimise mudelid

Kui siiani vaatlesime erinevaid metoodikaid nii IS hankimiseks kui süsteemi analüüsiks, siis selles peatükis tulevad vaatluse alla konkreetsemat tehnikad ja mudelid, mida metoodikate all rakendatakse, süsteemi selgitamiseks (nõuete analüüsiks). Mudelid võib jagada sisu kajastamise järgi kolme suuna vahel: tegijad (tegevused), andmed ja aeg (T.Saarsen Loeng_2 ja _3)

Asutuseh ie ra rh ia

Tegevused

D okum entiden im is tu

O lem id jasuh ted

Ärip rotsessid

Andm e-hu lkadeo lekud

S ündm used

A ndm evood

AEG

AND M ED

TEG EVU SED

TEG IJAD

Joonis 45 Kaardistamiste suunad (aeg, tegijad, tegevused, andmed), www.aprote.ee/loeng (esimene loeng)

Vt. nn visualiseerimise perioodilisuse tabelit http://www.visual-literacy.org/periodic_table/periodic_table.html

Tuletame meelde, et infosüsteem oli andmete ja nende töötlemisreeglite (siin tegijad-tegevused ning aeg), ning vajalike vahendite kompleks. See tähendab, et me peame reaalset süsteemi uurima just nendest aspektidest, lähtudes eelkõige ärivajadustest ja reeglitest (protsessidest).


http://www.visual-literacy.org/periodic_table/periodic_table.html

http://www.visual-literacy.org/periodic_table/periodic_table.html


Äri analüütiku oskuste ja töövahendite (mudelite) kohta annab tervikliku ülevaate ka raamat Business Analysis Body Of Knowledge: http://books.google.com/books?id=CFHw8jSEWwkC&lpg=PP1&dq=A%20guide%20to%20business%20analysis%20body%20of%20knowledge&pg=PP1#v=onepage&q&f=true

Samuti tuletame meelde, et süsteemile saab olla erinevaid vaateid eri tasandeilt:

üldvaade, eesmärkide vaade, tehnilis-arhitektuuriline vaade, tarkvaralise arhitektuuri vaade, funktsionaalne arhitektuur, andmearhitektuuri, sündmuste, tegija/kasutaja, arendus vaade ning arenduse eesmärgid, strateegia ja tegevuskava, eelarved- riskid, eesmärk muud arendamisega seotud küsimused.

Ning erinevad perspektiivid süsteemile: kliendi , protsessi, juhtimis/arendus, finants, andme/töötajate.

Mudeli optimaalseks “koormuseks” loetakse 7+/-2 objekti, et mahtuda ära kiiresti inimese lühiajalisse mällu ja kinnistuda pikaajalisse (Miller, 1956)

Mudelite joonistamiseks arvutis on tehtud väga palju erinevaid tarkvara pakette. Me võime kasutada antud aine raames kas standardtarkvara alates tekstitöötlusprogrammi oma vahenditest, või mõnda spetsiaalsemat joonistustarkvara (näiteks MagicDraw).

MS Word versioonist 2003 alates on määratud jooniste joonistamisel automaatne jooniseobjekti (konteineri, Drawing Canvas) loomine, millega tagatakse pildiobjekti terviklik haldus. Vareasemate versioonide


http://books.google.com/books?id=CFHw8jSEWwkC&lpg=PP1&dq=A%20guide%20to%20business%20analysis%20body%20of%20knowledge&pg=PP1#v=onepage&q&f=true




puhul aga tuleb kasutajal endal tagada joonise korrektne vormistus pildiobjekti näol. Loe vajadusel lisa tekstitöötluse alastest materjalidest: http://pc.parnu.ee/~ttamb/ikt/tekst/word.htm ja videoloengutest.

Nüüd vaatleme erinevaid mudeleid (diagramme) ja nende joonistel esitamise standarte. Üheks levinud IS mudelite standardiks on UML mudelid: http://en.wikipedia.org/wiki/Unified_Modeling_Language , millel baseerub suur hulk järgnevast. Unified Modelling Language (UML) annab ette terve mudelite kompleksi, mis katavad olulisemad perspektiivid süsteemi analüüsil.

Veel lugemist: http://www.smartdraw.com/tutorials/software-uml/uml.htm

Eesmärgivaade

Eesmärgivaate ülesandeks on mõtestada süsteemi ja selle arendusprotsessi ehk teisisõnu analüüsida, mille nimel ikkagi vaeva nähakse. Selle ülesandeks pole peensusteni selgitada, kuidas need eemärgid saavutatakse (Eriksson & Penker, 2000). Sarnaselt võib teha ka probleemidega, mida lahendada.


http://www.smartdraw.com/tutorials/software-uml/uml.htm

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://193.40.136.84/coursecast/Student/CourseContents.aspx?id=ec6297d2-4b72-4ce7-ae58-ff9777e85cbd

http://pc.parnu.ee/~ttamb/ikt/tekst/word.htm


Hierarhiamudel

Joonis 46 Hierarhiajoonise näide

Hierarhiad annavad ülevaate kontekstist, süsteem (organisatsiooni) osadest ja nende olulisusest. Tegijate hierarhia, tegevuste hierarhia jne.. Joonis koosneb alati ühetüübilistest elementidest ning oluline oleks välja tuua ka alluvuse tasandid visuaalse paigutusena. Piiranguna tuuakse välja seoste puukujulise struktuur. Võib lähtuda tüvest ja see dekomponeerida (leitakse tavaliselt ainult olulisimad elemendid) või alustada pisematest elementidest neid komponeerides (võib olla raske ühetüübilisi elemente koondada).

Kasutusjuhtum

Joonis 47 Kasutusjuhtumi joonise objektid ja seosed (Allikas I.Sander)

Kasutusjuhtumi diagrammi (Use Case) eesmärk on anda piiritletud ja piisav hulk juhtumeid, mida infosüsteem peab hakkama katma, näidates



ära ka juhtumite vahelised seosed. Analüüsi käigus võib juhtumite hulk muutuda ja täpsustuda, mis tingib muutusi projekteeritavas infosüsteemis või ka organisatsioonis endas.

Joonise elementideks on juhtumid (ovaal), rollid (kriipsujuku) ja seosed (erinevad nooled – lihtseos, üldistus, sisaldumine, laiendamine). Joonised võivad keskenduda kas ühe rolli tegevustele, ühe tegevusega seotud rollidele või siis olla kombinatsioon vajalikest elementidest.

Iga juhtumi kohta võib (peab saama) moodustada protsessi diagrammi, või kirjeldada vähemalt tavapärast sündmuste jada.

Vt:

Kuidas hästi kaardistada kasutusjuhtumeid - http://www.gatherspace.com/static/use_case_example.html#1

Loeng (alates 30. minutist) http://courses.cs.ut.ee/recordings/dumas/SystemsModelling2011/Lecture2

Vaata veel: http://en.wikipedia.org/wiki/Use_case_diagram

Voodiagramm

Joonis 48 Voodiagramm (allikas T.Tammaru)

Voodiagrammid annavad üldisema vaate ettevõttele, selle põhiprotsessile ehk ka väärtusahelale keskendudes. Vt. ka protsesside kaardistamise koolituskava: http://kvaliteet.tktk.ee/index.php?id=19&keel=ee


PõhiprotsessSisendsündmus (Klientide vajadused)

Väljundsündmus

Tugiprotsessid

Juhtimisprotsessid

http://kvaliteet.tktk.ee/index.php?id=19&keel=ee

http://en.wikipedia.org/wiki/Use_case_diagram

http://courses.cs.ut.ee/recordings/dumas/SystemsModelling2011/Lecture2

http://www.gatherspace.com/static/use_case_example.html#1


Protsesside vahelised seosed

Protsessidevahelisi seoseid esitatakse lisaks lihtsale voodiagrammile ka täpsemalt, tuues juurde protsesse siduvad infokogumid, ehk andmed.

joonis 49 Põhiprotsessid. Allikas: Polis, Magistritöö

Stsenaariumid

Joonis 50 Stsenaariumi näide. Allikas http://www.servicedesigntools.org/tools/13

Vaata ka klienditeekonna kaardistamise viise!Tartu Ülikooli Pärnu kolledž, Taavi Tamberg 56/67

http://www.servicedesigntools.org/tools/13


Protsessi diagramm

Protsessidiagrammid annavad selge orientatsiooni kogu juhtumile (algus ja lõpp) ning selles osalevatele tegevustele. Eesmärk on protsessist aru saada, määratleda selle efektiivsuse (efficiency) ja tõhususe (effectiveness) näitajad ning neid parendada. Igal protsessil peaks olema määratletud omanik (ressurssidega varustaja, vastutaja, muudatuste lubaja), eesmärk, efektiivsuse indikaatorid, sisendid ning väljundid.

Mudeli loomisel võib läheneda komponeerivast (kõik esile kerkinud pisitegevused omavahel sisudes ja süstematiseerides) või dekomponeerivast (terviklikku protsessi tükeldama asudes) aspektist.

joonis 51 Protsessi diagramm (Allikas http://melnais.mii.lu.lv/audris/Kalnins_Barzdins_UMLBM_Final.pdf)

Protsessi diagrammi kajastamiseks on arendatud ka standard Business Process Modeling Notation (BPMN).



Joonis 52 BPMN protsessi joonis, Allikas: http://www.bpmn.org/

Selle standardi erinevus UML protsessi joonisest on paralleelsuse tähistamine samuti tingimuslikule hargnemisele rombiga, mille keskel on suur pluss märk.

Kuigi neid jooniseid saab teha otse tekstitöötlusprogrammis (MS Word vms joonistusvahendid), siis on ka spetsiaalset vaba tarkvara olemas - näiteks: http://www.yworks.com/en/products_yed_about.html või http://www.bizagi.com/index.php?option=com_content&view=article&id=102&Itemid=109.

Majanduse (eriti tootmise) modelleerimisel kasutatakse tihti ka võrkplaneerimist (joon- ja sõlmdiagrammid).

Joonis 53 joondiagramm (allikas Sillaots)


http://www.bizagi.com/index.php?option=com_content&view=article&id=102&Itemid=109

http://www.bizagi.com/index.php?option=com_content&view=article&id=102&Itemid=109

http://www.yworks.com/en/products_yed_about.html

http://www.bpmn.org/


Joonis 54 sõlmdiagramm (allikas Sillaots)

Protsesside optimiseerimise kohta Reina Uba doktoritöö - http://hdl.handle.net/10062/18709

Andmevoo diagramm

Joonis 55 Andmevoodiagrammi näidis (I.Sander)

Andmevoodiagrammid näitavad andmete liikumist tegijate ja tegevuste vahel, kasutades vajadusel ka andmekogusid säilitatavate andmete jaoks.


http://hdl.handle.net/10062/18709


Andmemudel

Joonis 56 Objektmudeli (OM) näide (I.Sander)

Andmemudelid (ER, OM) annavad ülevaate säilitatavatest andmetest ning nende vahelistest seostest (reeglitest). Vastavad diagrammid on juba selgeks juhiseks infosüsteemi teostajatele.

Infomudelid

Lisaks andmemudelile kasutatakse ka teisi infomudeleid, mis on vajalikud eelkõige tervikliku infoarhitektuuri tasandi kaardistamiseks.



Tabel 1 Zachmani infomudeli raamistik

Allikas: Organisatsiooni käsiraamat, Eesti Juhtimiskvaliteedi Keskus (vt: http://www.juhtimine.ee/762280/organisatsiooni-kasiraamat/).

Mudelite näiteid

joonis 57 Väärtusahela üldmudel (Allikas Robert S. Kaplan, David P. Norton Tasakaalus Tulemuskaart 1996)


http://www.juhtimine.ee/762280/organisatsiooni-kasiraamat/


Kodaniku interneti portaal (KIT)

http://www.riik.ee/ekodanik/kitdoc/

Joonis 58 Kodaniku autentimise tegevusdiagramm

Joonis 59 Protsessi diagrammi näide (O.Mürk)

Joonis 60 e-poe juhtumite kaardistamine (http://askcodegeneration.com/e-commerce/)


http://askcodegeneration.com/e-commerce/

http://askcodegeneration.com/e-commerce/



Joonis 61 Teabeportaali kasutusjuhtude diagramm

+ Dokumendihaldus: http://www.riik.ee/dhp/publ/mudelid/index.html, http://www.riik.ee/dh/ylevaade/DHStrat101.html

+ Riiklikud IS’id ja nende arendamine (KIT Dokumentatsioon, U.Visse ettekanne,

Tartu e-Omavalitsus)

Teeme ise e-Ülikooli?

Projekt: Visioon, projekti tegijad, Probleemid, eesmärgid …

Visioon: Eestis? Taru Ülikoolis? Pärnu kolledžis? Mis on e-ülikool?


http://www.riik.ee/dhp/publ/mudelid/index.html


Joonis 62 Sheffield Hallam University Process Model

Infosüsteemi vaated: Eesmärgid, tegijad, tegevused, andmed, aeg…(vaatame loengu käigus?)

Eesmärgid/Protsessid:- õppematerjalide kättesaadavus, süstematiseeritus- kvaliteetse õppematerjali valmistamine (konkreetne/kokkuvõtlik,

enesetestid, …)- kaugõppe kursused (suhtluskanalid/reaalaja side grupitööks,

kontrolltööd materjalidega/aja peale- õpitulemuste privaatne kättesaadavus



Õppeprotsess

Joonis 63 Protsessidiagramm

MüüÿimeesMüüÿ

Klient - õpilane

õÿpelepingu allkirjastamine

<<extend>>

Direktor

Immatrikuleerimine

<<include>>

Rektor

Kooli külastus

<<extend>>

Tutvustaja

<<extend>>

<<include>>

Infomessid

<<extend>><<extend>>

<<extend>>

Joonis 64 Kasutusjuhtum müügist kolledžis (Use Case)

Iga tegevuse saab omakorda täpsustada eraldi joonisel. Näiteks Aine läbimise joonisel on tegevus “õppematerjali edastamine”. Siis teeme eraldi joonise “Õppematerjali edastamine”, milles võib olla omakorda tegevus “Tavapärane loeng” jne.



Elektrooniline ajakiri

Joonis 65 Andmemudel (OM)

Voodiagramm

joonis 66 Allikas: MIT kursus Integrating eSystems & Global Information Systems


http://ocw.mit.edu/OcwWeb/Sloan-School-of-Management/15-565JIntegrating-eSystems---Global-Information-SystemsSpring2002/CourseHome/index.htm



Viidatud allikadEriksson, E., Penker, M. (2000). Business Modeling with UML. Business Patterns at Work. New

York: John Wiley & Sons..................................................................................................................49Informit.com 2003...................................................................................................................................24McAdam, R Large Scale Innovation – Reengineering Methodology in SMEs, International Small

Business Journal, 2002, http://isb.sagepub.com/................................................................................14Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for

processing information. Psychological Review, 63, 81-97. cde.athabascau.ca/online_book.........48Polis E., Magistritöö 2002, Tallinna Tehnikaülikool...........................................................................7, 52

Lisaks Internetis:Sander, I. Infosüsteemide projekteerimine, loengukonspekt (http://pc.ut.ee/taavi/ikt/mis2004/isander) Saarsen, T. Süsteemide modelleerimine, loengukonspekt (http://www.aprote.ee/loeng/)Sillaots, M. Projektijuhtimine (http://www.audentes.ee/~martin/projekt/konspekt/) Rational Software Corporation, Rational Unified Process Web

(http://www.cs.ut.ee/rup/RationalUnifiedProcess/index.htm, TÜ ATI, parooli all)Riigi Infosüsteemide Osakonna projektid (www.riso.ee) Kodaniku Interneti Portaali dokumentatsioon (http://www.riik.ee/ekodanik/kitdoc/) Business Process Reengineering - http://www.brint.com/papers/bpr.htm

TÜ PK Raamatukogust:Infosüsteemi alused, T.Paas, 1991Sissejuhatus infosüsteemidesse, T.Mikli, 1999Arvuti ettevõtte asjaajamises, A.Septer (seaduste täistekstid), 2001Digitaalallkiri, tee paberivabasse maailma, V.Praust

Mujalt:Infosüsteemide projekteerimine, A.Isotamm, 1998Ettevõtte infosüsteemi loomine, T.Paas, Tartu 1993Süsteemkäsitlus, U.Mereste, 1987Management Information Systems. New Approaches to Organization & Technology (Study Edition),

New York: Prentice Hall, 1998MIT kursus "Systems Optimization", 2007 MIT kursus " Integrating eSystems & Global Information Systems", 2007



http://ocw.mit.edu/OcwWeb/Sloan-School-of-Management/15-057Systems-OptimizationSpring2003/CourseHome/index.htm

http://ocw.mit.edu/OcwWeb/Sloan-School-of-Management/15-057Systems-OptimizationSpring2003/CourseHome/index.htm

http://www.brint.com/papers/bpr.htm


http://www.riso.ee/

http://www.cs.ut.ee/rup/RationalUnifiedProcess/index.htm

http://www.audentes.ee/~martin/projekt/konspekt/

http://www.aprote.ee/loeng/

http://pc.ut.ee/taavi/ikt/mis2004/isander