kõik sis idu3350 loengukonspektid koos sisukord › biox1 › idu3350_koik_konspid_2010.pdfkõik...

Kõik SIS konspektid koos idu3350

© Karin Rava 1

Kõik SIS idu3350 loengukonspektid koos

Sisukord Infosüsteemide (IS) valdkond ..................................................................................................... 3

IS ülesanded kaasajal ................................................................................................................ 4

IT, IT ressursid ja IT teenused .................................................................................................... 4

IT kasvust tingitud organisatsiooni toimimist mõjutavaid trende ................................................. 4

IS-de hetkeseis .......................................................................................................................... 4

IS valdkonna rolle ...................................................................................................................... 5

IS/IT spetsialistide vastutused .................................................................................................... 5

IS/IT juhi vastutused .................................................................................................................. 5

Süsteemina käsitlemine (Systems Thinking) .............................................................................. 6

Süsteem..................................................................................................................................... 6

Organisatsioon ........................................................................................................................... 7

Organisatsiooni kui toimimissüsteemi üldine mudel ................................................................... 8

Organisatsiooni eesmärkide täitmine ......................................................................................... 8

Väärtusahel (Value Chain) ......................................................................................................... 9

Organisatsiooni toimimisviis (ärimudel) ...................................................................................... 9

Organisatsiooni juhtimisstruktuur ..............................................................................................10

Informatsiooni vajalikkus organisatsioonis .................................................................................10

Andmed (data) ..........................................................................................................................10

Informatsioon (information) .......................................................................................................10

Teadmine/teadmus (knowledge) ...............................................................................................11

Juhtimistasemed (-struktuur) või vastutusalad...........................................................................11

Traditsiooniline juhtimishierarhia ...............................................................................................11

Andmete ja informatsiooni liikumine organisatsioonis................................................................12

Nõuded andmetele-informatsioonile ..........................................................................................13

Infosüsteem (IS) ........................................................................................................................14

IS-i üldine mudel .......................................................................................................................15

IS-i koostisosad .........................................................................................................................15

Rakendussüsteemide liigid........................................................................................................16

Rakendussüsteemide andmekasutus ........................................................................................19


© Karin Rava 2

Andmehoidlad (repository) ........................................................................................................19

Andmehoidlatüüpide kasutus rakendussüsteemides .................................................................20

IS-i arendamine .........................................................................................................................20

John Zachman-i ettevõtte IS arhitektuuriraamistik .....................................................................24

IS arendamisel osalejate vaated ...............................................................................................26

Süsteemianalüüsi määratlus .....................................................................................................27

Süsteemianalüüsi meetodid ......................................................................................................27

Protsessi definitsioone ..............................................................................................................29

Organisatsiooni protsesside muutmine .....................................................................................30

Protsessianalüüs ja modelleerimine ..........................................................................................30

Objekti elutsükli modelleerimine ................................................................................................32

Tarkvarasüsteemi kasutuslugude modelleerimine .....................................................................32

Kasutuslugude kirjeldamine ......................................................................................................33

Toimimisobjektide (mõistete – kontseptide) modelleerimine ......................................................33

Andmete modelleerimine ..........................................................................................................34

Piirangud andmete modelleerimises .........................................................................................34

Objektitüübi omaduste (atribuutide) määramine ........................................................................36

Andmete normaliseerimisreeglid ...............................................................................................36

Objektitüübist andmetabel .........................................................................................................37

IS muutmine (arendamine) kui probleemi lahendamine .............................................................37

IS loomis- ja muutmistegevused ...............................................................................................37

Disain ........................................................................................................................................38

Ehitus (konstrueerimine) ...........................................................................................................40

Rakendamine ............................................................................................................................42

Hooldus.....................................................................................................................................44

IS arendusmetodoloogia (-metoodika) ......................................................................................44

Klassikaline lähenemine (Kose metoodika - waterfall) ...............................................................47

Iteratiivne (korduv) ja inkrementaalne (kasvatav) ......................................................................47

Rational Unified Process (RUP) ................................................................................................48

Enterprise Unified Process (EUP) .............................................................................................49

Agiilsed (kerged, lihtsad) protsessid ..........................................................................................49


© Karin Rava 3

Organisatsiooni ja IS/IT strateegiline juhtimine ..........................................................................51

Strateegia definitsioone .............................................................................................................51

Strateegiline planeerimine .........................................................................................................53

Strateegiate elluviimine .............................................................................................................58

Projektimeetod ..........................................................................................................................60

Projektijuhtimine ........................................................................................................................62

IS võimekuse tõdemus ..............................................................................................................65

Teadmine (ka teadmus) - knowledge ........................................................................................70

Teadmiste juhtimine organisatsioonis .......................................................................................71

Teadmiste juhtimissüsteem .......................................................................................................72

IT valitsemine ............................................................................................................................74

COBIT raamistik ........................................................................................................................75

ITIL mõisted ja põhimõtted ........................................................................................................77

IT ressursside turvamisega seotud mõisteid .............................................................................78

Infoturva-ala korraldamine ........................................................................................................79

Riski- (turva-)analüüs ................................................................................................................80

ISKE .........................................................................................................................................81

Infosüsteemide (IS) valdkond

tegeleb kõigega, mis on seotud inimvõimete suurendamisega infotehnoloogia abil ja see

puudutab:

probleemide lahendamist

otsuste vastuvõtmist

vajalike tegevuste sooritamist

arusaamise/mõistmise loomist

Täpsemalt tegeletakse probleemidega, mis on seotud infotehnoloogiliste (edaspidi IT) ressursside ja teenuste soetamise, kasutamise ja juhtimisega organisatsioonis - probleemidega, mis on seotud kasutatavate IT infrastruktuuride ning vastavate süsteemide arendamisega organisatsiooniliste tööprotsesside jaoks

Infosüsteemide valdkonna spetsialisti teadmised:

ärialased teadmised

IT-alased teadmised

analüütiline ja kriitiline mõtlemine

suhtlus, meeskonnatöö oskused

Kokku võetuna – IT-l põhinevat ettevõtet ja tema arendust puudutavad teadmised


© Karin Rava 4

IS ülesanded kaasajal

toetada organisatsiooni toimimisprotsesse

o tõhusus ja efektiivsus nii ajalises kui rahalises väärtuses

o tegutsemise kvaliteedi kasv

toetada otsuste tegemist

o informatsiooni kvaliteedi kasv

o teadmise loomine või õppimine

toetada konkurentsieelise saavutamist

o konkureerivate toodete-teenuste loomine

o kliendisuhete juhtimine

Infosüsteemi missioon: läbi IT kasutuse inimeste tegutsemise parendamine organisatsioonis

IT, IT ressursid ja IT teenused

IT on vahendid ja metodoloogiad andmete (informatsiooni) hankimiseks, organiseerimiseks,

salvestamiseks, töötlemiseks, esitamiseks ja edastamiseks

IT ressursid on riistvara, tarkvara, telekommunikatsiooni, andmebaasi juhtimise- jm. vahendid ja

süsteemid, mida kasutatakse arvutipõhistes infosüsteemides moodustades infrastruktuuri

IT teenus on organisatsiooni tööprotsessi toetav IT kasutus kombineerides inimesed, tegevused

ja IT ressursid

IT kasvust tingitud organisatsiooni toimimist mõjutavaid trende

IT mõju organisatsiooni väliskeskkonnale

o organisatsiooni äritsüklite kiiruse kasv

o internetipõhine majandus

o B2C; B2B

o globaalne turg – kogu maailm on muutunud turuks

IT mõju organisatsiooni sisekeskkonnale

o otsesuhtlus kliendiga

o klientidepoolne iseteenindamine

o muudatused organisatsiooni ülesehituses – ―lame‖ ülesehitus

o meeskonnapõhine töötamine

o elektrooniline, reaalajaline töötamine

IS-de hetkeseis

IT süsteemid on iga organisatsiooni ―südameks‖ ning nende töövõime mõjutab organisatsiooni

tegutsemist. Organisatsiooni ellujäämise küsimuseks on nende süsteemide täpne ja selge

töötamine. Organisatsiooni eluvõime kindlustamiseks kasvavad vajadused informatsiooni ja

selle juhtimise järele. See toob endaga kaasa nõudluse kasvu üha kvaliteetsemate IT-

süsteemide järele.


© Karin Rava 5

On vaja luua ja ―elus hoida‖ suhteliselt keerulist kombinatsiooni ostetud tarkvarasüsteemidest,

tehnilistest arhitektuuridest, platvormidest, vahenditest ja meetoditest.

Vanasti oli IT-d puudutavate otsuste tegemine organisatsioonis nö ―tehniliste juhtide‖ pädevus.

NÜÜD on suures osas ärijuhtide ja kõigi taseme töötajate vastutusalas.

Ühelt poolt on organisatsiooni inimesed oma toimimise ja infovajadustega ja nendega seotud

probleemidega. Teiselt poolt IT inimesed pakutavate lahendustega. Need 2 osapoolt on vaja

omavahel koostööd tegema panna

Eksisteerib vajadus selliste spetsialistide järele, kes oleksid võimelised määratlema

organisatsiooni vajadusi informatsiooni, selle juhtimise ning vastavate IT-süsteemide järele;

otsustama, milliseid IT-süsteeme luua/hankida ja organisatsiooni kasutusse anda ja mille jaoks

ja IT-süsteeme looma ja nende loomist juhtima. Üldiselt võttes - kes orienteeruksid

infosüsteemide valdkonnas

IS valdkonna rolle

infosüsteemi juht (Chief Information Officer)

IT juht (Chief Technology Officer või IT Manager)

infosüsteemi projektijuht

infosüsteemi rühmajuht

süsteemianalüütik

süsteemiarhitekt ja -disainer

süsteemi administraator

andmebaaside spetsialist / administraator

programmeerija

IS/IT spetsialistide vastutused

IS/IT toimimise käigushoidmine

IS/IT arhitektuuri arendamine ja vastavate strateegiate elluviimine

IS/IT süsteemide arendamine

organisatsioonipoolsete nõuete määratlemine IS/IT-le

IS/IT juhi vastutused

IS/IT-d puudutava tulevikuvisiooni loomine

IS-i valitsuse ülesehituse loomine

IT portfelli kokkupanek

organisatsiooni toimimise muutmise juhtimine


© Karin Rava 6

Süsteemina käsitlemine (Systems Thinking) Probleemi analüüsimeetod või lähenemisviis, mis tegeleb süsteemist arusaamisega põhinedes tõekspidamisel, et lahendatavat probleemi võetakse süsteemi (või terviku) osana. Probleemist on võimalik paremini aru saada kui uurida selle seoseid süsteemi moodustavate teiste osade või teiste süsteemidega

Süsteemina mõtlemine üritab näidata, et:

keerulistes süsteemides 1 väike sündmus võib põhjustada suuri muutusi

süsteemi ühe osa paremaks tegemine võib ebasoodsalt mõjutada süsteemi teisi osi

Süsteem on igasugune vastastikku sõltuvate ja (ajutiselt) seotud osade (komponentide) organiseeritud kogum. Osad ise võivad olla samuti süsteemid koosnedes omakorda osadest (=süsteemidest).

Süsteemi moodustavate osade vahel liigub energia, materjal ja informatsioon.

Süsteem paikneb seda ümbritsevas keskkonnas.

Nii energia, materjal kui informatsioon liigub keskkonnast süsteemi ja süsteemist keskkonda läbi süsteemi piiride.

Piltlikult väljendudes

Joonis 1. Süsteemi hierarhiline ülesehitus

Tõekspidamisi süsteemi kohta:

omavahel mitteseotud osad ei moodusta süsteemi

osade koostoimimine peab lõppema mingi eesmärgi saavutamise või lõpliku seisundiga

sisendid teisendatakse väljunditeks (eesmärgi saavutamise protsess)

süsteemi prognoositavaks opereerimiseks on vaja tagasisidet

Süsteemi üldine mudel


© Karin Rava 7

Joonis 2. Süsteemi üldine mudel

Organisatsioon Organiseeritud ja koordineeritud inimeste grupp koos vastavate tööviiside, rutiinide ja vastastike ootustega, kes koos töötades üritavad saavutada ühiseid eesmärke

Organisatsiooni mõte ja eesmärk on huvigruppide vajaduste rahuldamine

Huvigrupid

omanikud – raha vm mõõdetava väärtuse teenimine

kliendid

juhid – min. kuludega maks. tulemuste saavutamine

töötajad – turvaline ja rahuldust pakkuv töökeskkond

Klientide vajaduste rahuldamine väärtus(t)e loomisega:

läbi spetsiifiliste teenuste ja/või toodete loomise - tootmisettevõte, teenindusasutus

jne

läbi inimeste mõjutamise ja/või muutmise - õppeasutus, haigla, vangla jne

Organisatsioon saab tulemusi anda ainult kliendi vajadustele vastates nii nagu kliendid ise neid vajadusi määratlevad. Ainus tõestus selle kohta, kas töö on hästi tehtud on klient, kes on valmis selle eest maksma

Kliendi jaoks võib väärtusena pidada:

kvaliteeti ja selle kasvu - protsessi ja toote/teenuse kvaliteet ja selle kasv (vigade

vähenemine või veaparandusele kuluva aja vähenemine)

kulude vähenemist - kasumlikkuse kasv

kiirust - turu muutustele reageerimiskiirus või tarneaja vähendamine

innovatsiooni - eristumine toodetes/teenustes ja nende omadustes; esimesena turulejõudmine


© Karin Rava 8

suhteid - koostöö klientide, partnerite või isegi konkurentidega läbi teadmise ja kogemuste jagamise

Organisatsiooni kui toimimissüsteemi üldine mudel

Joonis 3. Organisatsiooni kui toimimissüsteemi üldine mudel

Organisatsiooni eesmärkide täitmine Teostades:

põhiprotsesse - luues etteantud tingimuste juures defineeritud tulemust - tootmine,

teenuse osutamine

tugiprotsesse - toetades sisuliste protsesside teostamist - ressursside hankimine, müük, arveldamine jne

juhtimisprotsesse - juhtides organisatsiooni ja tema toimimist ning arendamist (innovatsiooni) - strateegiline planeerimine, eelarvestamine jne

Täpsemalt põhiprotsessid

sisemine logistika - algmaterjali vastuvõtmine (ladustamine); algmaterjali kontroll

opereerimine – tootmine; pakendamine; tootekontroll; hooldamine

välislogistika - lõpptoodete arvestus; tellimuste täitmise haldamine;

kohaletoimetamine

müük ja turundus - klientide juhtimine ja tellimuste vastuvõtt; reklaamikampaaniate

korraldamine; turu-uuringute tegemine

teenindus – hooldus; koolitamine

Täpsemalt tugiprotsessid

infrastruktuuri administreerimine - infosüsteemi arendamine; juriidika;

raamatupidamine; finantsjuhtimine

inimressursside juhtimine - personaliarvestus; palgaarvestus; värbamine; koolitus; tööjõu planeerimine

toote- ja tehnoloogiaarendus - toote ja protsessi disain; turu testimine, uuringud ja arendus


© Karin Rava 9

hankimine - tarnijate juhtimine; ressursside hankimine, lepingud

Täpsemalt juhtimisprotsessid

planeerimine - otsustamine, mis peab toimuma tulevikus ja mida on vaja, et selleni jõuda

organiseerimine - plaani edukaks elluviimiseks ressursside optimaalne kasutamine

mehitamine - töö analüüs, töö jaoks sobivate inimeste värbamine ja palkamine

eestvedamine - määratlemine, mida on vaja konkreetses situatsioonis teha ja inimeste panemine seda tegema

järelvalve või jälgimine - edenemise kontrollimine plaanide suhtes ja tagasiside alusel võimalik muutmine

motiveerimine - soovitud eesmärgi täitmiseks inimeste innustamine

Väärtusahel (Value Chain) Nende protsesside ja infovoogude jada, mida organisatsioon ja selle tarnijad peavad läbi viima, et oma tooteid/teenuseid kavandada, toota/luua, turustada, kohale toimetada ja toetada omades 2 osa. Esimene osa sisaldab kõiki tegevusi, mis on seotud millegi tegemisega - kavandamine, toormaterjalide ostmine, tootmine või teenuse osutamine. Teine osa sisaldab kõiki tegevusi, mis on seotud millegi müümisega - klientide leidmine ja nendeni jõudmine; müügitehingu teostamine, toote levitamine või teenuse pakkumine

Väärtusahel piltlikult

Joonis 4. Väärtusahel

Organisatsiooni toimimisviis (ärimudel) Lugu sellest, kuidas organisatsioon tegutseb ja kuidas organisatsioon tulevikus toimib luues väärtust mitte ainult klientidele, vaid kõigile osapooltele, kellest ta sõltub (tarnijad, koostööpartnerid jne)

Kõik uued toimimisviisid on kõigi tegutsemiste aluseks oleva universaalse väärtusahela variatsioonid.

organisatsioonid on paremad (saavutavad paremaid tulemusi) - kui nad on unikaalsed. Kui nad teevad midagi, mida keegi teine ei tee ja sellisel viisil, mida keegi teine ei suuda järele teha

See omakorda tähendab valikuid: milliseid kliente ja turge teenindada; milliseid tooteid ja teenuseid pakkuda ning millist väärtust luua


© Karin Rava 10

Organisatsiooni juhtimisstruktuur Inimeste jaotumine gruppidesse ja nende omavahelise juhtimishierarhia moodustumine

formaalne - osakonnad, programmid, divisjonid, meeskonnad jne. Jaotus protsesside, funktsioonide, toodete gruppide, kliendigruppide, geograafilise või territoriaalse jaotuse järgi

mitteformaalne - sotsiaalsete kontaktidega inimgrupid (vallalised, pereinimesed, sportlased jne)

Organisatsiooni juhtimislik ülesehitus määrab ära informatsiooni liikumise ja kättesaadavuse organisatsioonis

Informatsiooni vajalikkus organisatsioonis

määratleda kasumlikkus ja jälgida eesmärkide täidetust

luua ja toimetada kätte keerulisi tooteid ja teenuseid

vältida pettust ja kuritarvitust

optimeerida ebapiisavate ressursside kasutust

juhtida efektiivselt inimesi ja nende gruppe ning kasvatada nende võimeid ja

väljavaateid

tegutseda edukalt koos tarnijate, klientide ja koostööpartneritega

Teiste sõnadega - vastavalt oma vastutusalale on informatsiooni vaja

sisendina oma töö tegemiseks

sisendite, protsesside ja väljundite planeerimiseks ja organiseerimiseks

organisatsiooni huvirühmade vajaduste ja nende täitmise juhtimiseks

Erinevad vastutusalad vajavad erinevatele nõuetele vastavat informatsiooni

Andmed (data) Töötlemata kujul faktid (nö. algandmed) sündmuste, inimeste, ressursside, tingimuste jne kohta, millel ei ole eraldivõetuna tähendust.

Andmed esitatakse numbriliselt, tekstina, pildina, helina jne

Informatsioon (information) Andmetele tähenduse andmine - kirjeldamine (informeerimisvõime andmine).

Andmete omavaheline seostamine, töötlemine, konteksti panemine

Andmed muutuvad informatsiooniks vaid siis kui need omavad tähendust vastuvõtja jaoks

fakt peab olema oluline vastuvõtjale

faktiga peab saama midagi peale hakata

Informatsioon pakub vastuvõtjale alust mõistmiseks, järelduse tegemiseks, otsustamiseks

Informatsiooni loomine on inimtegevus - ainult inimene on võimeline andmetele tähendust omistama


© Karin Rava 11

Organisatsiooni juhtimise jaoks vajalik informatsioon väljendub eelkõige arvudes - suhtarvud ja trende väljendavad arvud.

Suhtarvud võrdlevad üht sooritust mingi kindla etaloniga, n: millegi kasv

Trende väljendavad arvud on perioodiliselt saadavad suhtarvud, n: kasvutempo

Selleks, et mingist andmehulgast sisu kätte saada, tuleb see konteksti panna (siduda teiste andmetega)

See, milliseid suhtarve või trende vaadata, sõltub sellest, kes neid vaatab ja mida ta teada tahab, n: investor on huvitatud nendest näitajatest, mis kirjeldavad võimet laenu tagasi maksta; kõnekeskuse juhile pakuvad huvi need näitajad, mis aitavad vähendada klientide ooteaega

Teadmine/teadmus (knowledge) Informatsiooni omavaheline seostamine, sellele laiahaardelisema tähenduse omistamine.

Informatsiooni töötlemine selliselt, et väljendada mõistmist, kogemust, õppimist

Teadmus on vajalik selleks, et valida, milliseid andmeid informatsiooni saamiseks hankida ja milliste reeglite alusel töödelda

Teadmusel on informatsiooniga võrreldes pikem eluiga

Teadmus sisaldab reegleid tegutsemiseks, nö käitumismustrit

Juhtimistasemed (-struktuur) või vastutusalad Eristuvad üksteisest vastutuse ja volituste suurusega. Vastutust võib eristada:

andmete töötlusastme järgi, mida on vaja ülesannete täitmiseks

aja järgi, mille vältel andmed ja nende pealt saadav on veel aktuaalne (―värske‖)

Täpsemalt:

millised on andmeallikad, mis on vajalikud informatsiooni jaoks ametikohale

milline on ajavahemik, mil peetakse andmeid ja infot kõlbulikuks otsuste tegemisel

milline on tehtavate otsuste ajaline ulatus (mõju)

Traditsiooniline juhtimishierarhia

Joonis 5. Traditsiooniline juhtimishierarhia


© Karin Rava 12

Esimese astme juhid

Vastutavad organisatsiooni igapäevase tegevuse eest planeerides homse päeva tegevusi. Nende teenistuses olev info on saadav töötlemata kujul faktidelt. Need faktid laekuvad tavaliselt väljastpoolt organisatsiooni piire (n: tellimuse andmed klientidelt)

Selliselt saadud info omab väärtust ainult suhteliselt lühikest aega mõõdetuna tundides või päevades ning tehtava otsuse mõju on lühiajaline. Infovajaduste näiteid:

tellimuse sisu, täitmata tellimused

väljakutse sündmuskohale

konkreetse semestri ainele deklareerinud tudengid

Keskastme juhid

Tegelevad organisatsiooni tegutsemise jälgimise, eelarvete täitmise kontrollimise, ressursside hankimise ja poliitika loomisega, st taktikaga

Taktikalisel tasemel tehtud otsused puudutavad keskmise ulatusega (0,5 – 1 aasta) eesmärke, mis on organisatsiooni strateegiliste eesmärkide alameesmärgid (kuidas organisatsioonile püstitatud eesmärke kõige paremini ellu viia). Infovajaduste näiteid:

millised on kvartali müügitulemused võrreldes eelmise aasta sama perioodiga?

milline on tööjõu voolavuse näitaja?

ülikooli lõpetanute arv võrrelduna sisseastunute arvuga või teiste kõrgkoolidega?

Kõrgema astme (tipp-) juhtkond

Jälgib pikaajalist perspektiivi planeerides järgmisteks aastateks. Tippjuhi info jaoks vajalikud andmed omavad väärtust pikema perioodi vältel (1-st 5 aastani või rohkem)

Kõrgema astme otsustamine nõuab kõrge taseme kogemust ja teadmisi. Infovajaduse näiteid:

millises suunas peaks organisatsioon arenema (milliseid tegevusvaldkondi muutma,

juurde tooma)?

täielik üleminek e-õppele?

Andmete ja informatsiooni liikumine organisatsioonis Inimgruppides tegutsevate inimeste koostöö seisneb nii oma töö tulemuste kui andmete (mis võib samuti olla töö tulemuseks) vahetamises. Andmed liiguvad ametikohtade (rollide), täpsemalt nende täitjate vahel. Andmete liikumise vormid:

formaalne suhtlus - aruanded, raamatupidamislikud andmed jne

mitteformaalne suhtlus - vestlus, kirjavahetus, märkused, kommentaarid, arvamused jne

Formaalne suhtlus

Info edastus toimub paikapandud reeglite ja standarddokumentide vormide (blankettide) alusel. Memode, aruannete ja teiste dokumentide jaoks kasutatakse vastavaid malle (template). Andmed omavad struktureeritud (organiseeritud) kuju

Puudusena:

kehtestatud struktuur on staatiline


© Karin Rava 13

taustainfo võib kaduma minna (arvamusavaldused jne)

Mitteformaalne suhtlus

On eelkõige suusõnaline. See võib sisaldada palju ebatäpsusi ja mitteolulisust

Puudusena

võimetus hakkama saada suurte infohulkadega

suhteliselt aeglane ja ebaefektiivne

Nõuded andmetele-informatsioonile Kuigi on teada, et andmed on organisatsioonis olemas, siis 80% ajast ei ole need teada sellele inimesele, kellel neid informatsiooni jaoks vaja on

Informatsiooni kättesaamiseks peab olema määratletud, millistele nõuetele vastavat informatsiooni ning selle aluseks olevaid andmeid iga organisatsiooni liige vajab ja kuidas ta pääseb nendele andmetele ligi.

Joonis 6. Andmetele ja informatsioonile esitatavate nõuete liigid

Ajamõõde

Kirjeldab ajaperioodi, millal informatsiooni jaoks andmeid kasutatakse ja selle vastuvõtmise sagedust

andmed peavad olema protsesside jaoks aktuaalsed

andmeid peab edastatama õigeaegselt

andmed peavad olema kättesaadavad nii tihti kui vaja

andmed peavad katma korrektset ajaperioodi

Sisumõõde

Kirjeldab andmete skoopi (ulatust) ja sisu. Andmed peavad olema informatsiooni jaoks:

korrektsed

täielikud

asjakohased ja sisukad

usaldusväärsed

kontrollitavad

Vormimõõde


© Karin Rava 14

Kirjeldab, millises vormis andmeid informatsiooni jaoks vastuvõtjale esitatakse. Andmed peavad olema informeerimise eesmärgi jaoks:

esitatud selgelt ja sobival kujul

õige detailsusastmega

pakutud õiges järjekorras

andmete edastamisel peab olema kasutatud korrektset meediat

Infosüsteem (IS) Organisatsioonis on süsteem, mille eesmärkideks on:

pakkuda kvaliteetseid andmeid kvaliteetse informatsiooni jaoks organisatsiooni liikmetele ja temaga suhtlejatele, et toetada neid otsuste tegemisel

rahuldada ettevõtte iga (juhtimis-)taseme (töötaja/keskastme juht/tippjuht) infovajadusi nende kohustuste täitmisel (otsuste elluviimisel) organisatsioonis

Sellist süsteemi nimetatakse infosüsteemiks

Definitsioon 1: igasugune kombinatsioon IT-st ja seda kasutavatest inimestest, et toetada

opereerimist, juhtimist ja otsuste tegemist;

Definitsioon 2: info, isikute, tehniliste vahendite ja meetodite terviklik süsteem vajaliku, täpse ja

operatiivse info kogumiseks, korrastamiseks, analüüsimiseks ja otsustajale õigeaegseks

edastamiseks

Definitsioon 3: kogum IT ressurssidest, IT teenustest, andmetest ja inimestest, mis on

organiseeritud informatsiooni genereerimiseks, töötlemiseks ja levitamiseks, et võimaldada

organisatsiooni tegutsemist

Definitsioon 4: Organisatsiooni info- ja süsteemitöökorraldus koos vastavate reeglite ja infotehnoloogiliste vahenditega

Infotöö on töö, mille käigus toimub andmete:

omandamine – organisatsiooni välis- või sisekeskkonnast visuaalse vaatluse või laekuvate sõnumitega või mõõtmise tulemusena või muul viisil saadavate andmete kättesaamine

hoiustamine – informatsiooni loomise jaoks kasutatavate andmete meeldejätmine (pähe õppimine), kirjapanek (n: paberile) või salvestamine (elektrooniliste andmete puhul)

töötlemine – sorteerimine, grupeerimine, matemaatiliste operatsioonide rakendamine

edastamine – saatmine

Süsteemitöö on töö, mille käigus toimub infosüsteemi loomine või muutmine

Info-/süsteemitöökorraldus on koostööreeglid, kuidas info- ja süsteemitööd organisatsioonis läbi viia

kes, millal, kuidas, milliseid vahendeid kasutades millist infotöötegevust peab teostama

kes, millal, kuidas, milliste vahenditega peab infosüsteemi looma/muutma


© Karin Rava 15

IS-i üldine mudel

Joonis 7. Infosüsteemi üldine mudel

Veel 1 Infosüsteemi mudel

Joonis 8. Veel 1 IS mudel

IS-i koostisosad infotehnoloogia (IT) pakkudes organisatsioonile elektroonilist infrastruktuuri

infotöötajad ja süsteemitöötegijad kasutades IT-d täidavad oma info- ja süsteemitööülesandeid organisatsioonis

andme-(info)ressursid - infovajajate jaoks nende nõudmistele vastav info (väljund); lähteandmed selle loomiseks (sisend)


© Karin Rava 16

infosüsteemi info- ja süsteemitööprotsessid - reeglid, protseduurid, meetodid ja nende omavaheline seotus info- ja süsteemitöö jaoks

Infosüsteemis tegutseja nö arvutitöökoht

Joonis 9. IS-s tegutseja arvutitöökoht

Rakendussüsteemide liigid Formaalset suhtlust (andmevahetust) toetavad:

operatsioonilised (käitus-)süsteemid igapäevatöö tegemiseks ja juhtimiseks

administreerimis-/ juhtimissüsteemid organisatsiooni juhtimisprotsessideks

Mitteformaalset suhtlust toetavad:

teadmuse loomiseks ja organisatsioonisisese kultuuri tõstmiseks

uute teenuste ja toodete loomiseks

klienditeeninduse taseme tõstmiseks

klientide kaasamiseks toodete arendusse

tarnijate kaasamiseks tööprotsessidesse

Piltlikult väljendatuna


© Karin Rava 17

Joonis 10. Rakendussüsteemide liigid

Operatsioonilised (käitus-) süsteemid

On vajalikud organisatsiooni igapäevase tegevuse juhtimiseks

toodete tegemiseks ja jaotamiseks

teenuste planeerimiseks ja osutamiseks

Seda tüüpi süsteemide alla kuuluvad:

transaktsioonide töötlussüsteemid (Transaction Processing Systems)

protsesside juhtimissüsteemid (Process Control Systems)

kontori automatiseerimissüsteemid (Office Automation Systems) või kontori infosüsteemid (Office Information Systems)

spetsiifilised (professionaalsed) tugisüsteemid (Professional Support Systems)

Transaktsioonide (tehingute) töötlussüsteemid

Teenindavad operatiivse juhtimise taset võimaldades korduvalt ja rutiinselt salvestada ja töödelda nii organisatsioonis endas kui väljaspool seda toimuvaid sündmusi ja fakte

klientide tellimused

pakkumised hankijatele

müügifaktid

inventari liikumine

palgad

arved, maksed jne

Kontori automatiseerimissüsteemid

(kontori)töötajate töö efektiivsuse tõstmiseks


© Karin Rava 18

grupitöövahendid (e-mail, dokumentide juhtimine, kalender jne)

töövoogude juhtimissüsteemid (ülesannete täitmise juhtimine, projektijuhtimispaketid)

üldised rakendused (tekstitöötlus, tabelarvutus jne)

Juhtimist toetavad süsteemid

Võimaldavad tagasisidet organisatsioonis toimuvate protsesside, nende sisendite ja väljundite kohta

Seda tüüpi süsteemid toetavad otsuste vastuvõtmist ja teadmise loomist ja siia alla kuuluvad:

aruandlussüsteemid (Information Reporting Systems) või (Management Reporting Systems)

otsustamise toetussüsteemid (Decision Support Systems (DSS))

juhtkonna (täidesaatva võimu) rakendused (Executive Information Systems (EIS))

Tervikrakendused - ERP

Enterprise Resource Planning koosnedes järgnevatest moodulitest (alamosadest):

Manufacturing - Engineering, Bills of Material, Scheduling, Capacity, Workflow Management, Quality Control, Cost Management, Manufacturing Process, Manufacturing Projects, Manufacturing Flow

Supply Chain Management - Inventory, Order Entry, Purchasing, Product Configurator, Supply Chain Planning, Supplier Scheduling, Inspection of goods, Claim Processing, Commission Calculation

Financials - General Ledger, Cash Management, Accounts Payable, Accounts Receivable, Fixed Assets

Projects - Costing, Billing, Time and Expense, Activity Management

Human Resources - Human Resources, Payroll, Training, Time & Attendance, Benefits

Customer Relationship Management - Sales and Marketing, Commissions, Service, Customer Contact and Call Center support

Data Warehouse - and various Self-Service interfaces for Customers, Suppliers, and Employees

Mitteformaalsed suhtlusvahendid

Web 2.0. või Enterprise 2.0. tehnoloogiad:

Web teenused

Sotsiaalse võrgustiku teenused

Blogi

RSS

Wiki

Podcast

http://en.wikipedia.org/wiki/Manufacturinghttp://en.wikipedia.org/wiki/Supply_Chain_Managementhttp://en.wikipedia.org/wiki/Financialshttp://en.wikipedia.org/wiki/Projectshttp://en.wikipedia.org/wiki/Human_Resourceshttp://en.wikipedia.org/wiki/Customer_Relationship_Managementhttp://en.wikipedia.org/wiki/Data_Warehouse


© Karin Rava 19

Rakendussüsteemide andmekasutus Rakendussüsteemide töö seisneb infotöötegevuste teostamise toetamises

Rakendussüsteemid kasutavad sisendina andmeid ja töötluse tulemuseks on informatsioonina tõlgendatavad andmed

Sisendandmed saadakse kas väljastpoolt organisatsiooni (organisatsiooniga suhtlejatelt) või organisatsiooni seest (tööprotsessides osalejad ―toidavad-teenindavad‖ üksteist vajalike andmetega)

Kohti, kus hoitakse informatsiooni jaoks vajalikke andmeid, nimetatakse andmehoidlateks

Andmehoidlad (repository)

Joonis 11. Andmehoidlate tüübid

Andmehoidlatesse kogutakse ja neis hoitakse süstematiseeritult andmeid, mis on olulised organisatsiooni töö ja selle juhtimise jaoks

Struktureeritud andmed hoitakse kirjetena (record) – omavahel seotud väljade (field) kogumid, mis iseloomustavad organisatsiooni tegutsemise objekti (business object) või tegevust

Informatsiooni loomine toimub väljade pealt päringute tegemisega (n: anna kõik nimekirjas olevate tudengite andmed, kelle perekonnanime esitäht on „A―)

Struktureerimata andmed on terviktekstid, pildid jne.

Informatsiooni loomine toimub läbi märksõnade järgi otsimise (n: otsi tekstist sõna „aga―)


© Karin Rava 20

Andmehoidlatüüpide kasutus rakendussüsteemides

Joonis 12. Andmehoidlate tüüpide kasutus rakendussüsteemides

Andmebaas (database)

Infosüsteemi ―tuum‖, milles organiseeritakse infosüsteemis kasutatavad andmed. Andmebaasi näol on tegemist infovajaduste rahuldamiseks põhilise andmeallikaga

Andmebaasis on organisatsiooni seisundit esitavate struktureeritud andmete kogum, mis kajastab organisatsiooni ja tema toimimise hetkeseisu (kõige värskemaid andmeid)

Andmebaasis hoitakse erinevat tüüpi fakte esitatuna vastavalt andmebaasi tüübile kas tabelina, dokumendina või muu objektina

Andmevaramu (-ait) (data warehouse)

Eri tüüpi andmebaas, milles hoitakse vanu, ajaloolisi (mittevärskeid) andmeid ja seda kasutatakse andmete analüüsimiseks.

Andmevaramu näol on tegemist organisatsiooni erinevatest andmebaasidest koondatud (puhastatud ja töödeldud) andmete kogumiga. Puhastatud andmed tähendavad, et ei ole samade andmete kordumist, ei ole tegemist puudulike või ebatäpsete andmetega. Töödeldud andmed tähistavad juba matemaatiliste operatsioonide rakendamise tulemusi (n: toodete müükide summad kuude lõikes vms)

Andmevaramu on infoallikaks organisatsiooni taktikalisele ja strateegilisele juhtimisele

Viisi, kuidas andmeid analüüsitakse, nimetatakse andmekaevanduseks (data mining) ja see seisneb andmete omavaheliste (varjatud) seoste väljatoomises, n: mitu protsenti klientidest ostavad leiba ja õlut koos?

IS-i arendamine organisatsioonis infotehnoloogia kasutuselevõtmine

selle abil organisatsiooni juhtimisliku ülesehituse ja organisatsioonisiseste ja –väliste tegutsejate infotöökorralduse muutmine

selle jaoks infosüsteemi arhitektuuri (ülesehituse) kujundamine


© Karin Rava 21

vastavalt arhitektuurile rakendussüsteemide ja andmehoidlate loomine ja kasutuselevõtmine

eesmärgiga tõsta infosüsteemi võimet rahuldada organisatsioonis tegutsejate ja sellega suhtlejate infovajadusi

Infosüsteemi või selle osa arendamise käivitajateks võivad olla:

väljastpoolt organisatsiooni tulevad nõudmised

uued infotehnoloogilised võimalused

probleemid või nõudmised olemasolevas infosüsteemis

Arendamise üritustest õnnestuvad ca 1/3; ebaõnnestumisi 2/3, mistõttu arendamine on seotud probleemidega.

Peamiseks probleemiks on süsteemiarenduses osalevate inimeste vahel andmevahetuse puudumine, mis toob endaga kaasa rahuldamata infovajadused ja omakorda vastastikuse arusaamise puudumise tulevasest infosüsteemist ja kuidas selleni jõuda

Infosüsteemi arendamisega seotud inimesed

organisatsiooni töötajad - rakendussüsteemide lõppkasutajad, infotöötegevuste tegijad

organisatsiooni juhtpositsioonil olevad inimesed (juhid) - omavad kontrolli (või vähemalt mõju) arendamise käivitamise, suunamise või kulgemise üle

professionaalid - süsteemi tegijad - vastutavad kvaliteetse infosüsteemi kvaliteetse arendamise eest

Tõsiasjad

kõik arendamises osalejad näevad nii olemasolevat kui tulevast infosüsteemi erinevalt, nö ―oma mätta otsast‖

kõikidel arendamisel osalejatel on oma vastutus ja seega omad infovajadused otsuste tegemiseks tulevase infosüsteemi ja selleni jõudmise suhtes

D. Flynn oma raamatus ―Information Systems Requirements: Determination And Analysis‖ (1998) tõi välja süsteemiarenduse 2 aspekti – süsteemi kvaliteedi ja produktiivsuse

Süsteemi kvaliteedi tagab arusaamine

mis eesmärke süsteem peab täitma

kuidas süsteemi sobivust mõõta

Süsteemi produktiivsus on seotud süsteemi loomise/ muutmise edukuse ja ressursside kasutusega


© Karin Rava 22

Süsteemiarenduse läbikukkumise põhjusi

Tabel 1. Süsteemiarenduse läbikukkumise põhjusi

Vea tüüp Vea põhjus Kommentaar

Kvaliteedi

probleemid

Valet probleemi on lahendatud Süsteemi vastuolu ärilise (toimimise)

strateegiaga

Laiemaid mõjusid on eitatud Organisatsiooni kultuuri on ignoreeritud

Analüüsi on läbi viidud ebakorrektselt Meeskond on alakvalifitseeritud või

ebapiisavalt hõivatud (ülekoormus)

Projekti on algatatud valedel põhjustel Tehnoloogiline "tõmbamine" või

poliitiline "lükkamine"

Produktiivsuse

probleemid

Kasutajad mõtlevad ümber

Välised sündmused muudavad

keskkonda

Uus seadusandlus

Realiseerimine ei ole teostatav Ei pruugi olla teada enne kui projekt

algab

Nõrk projekti järelvalve (kontroll) Kogemusteta projektijuht

Süsteemi kvaliteedi ja loomise produktiivsuse tagamiseks valida

sobivad analüüsi-, disaini- ja realiseerimismeetodid ja -tehnikad

süsteemi muutmise olemusele vastav arendusmetoodika

õiged võtted süsteemiarenduse juhtimiseks

tehnoloogiline tugi

IS arenduses osalevate osapoolte infovajaduste rahuldamiseks ja ühise arusaamise loomiseks

erinevat liiki mudelid, mis esitavad tulevast infosüsteemi selle arendamisel osalejatele

erinevatest vaadetest olles infoallikaks arendamisotsuste tegemisel ja nende täitmisel

Mudel

uurimisobjekti (siin organisatsiooni ja infosüsteemi) kirjeldus mingist kindlast vaatenurgast

väljendab uurimisobjekti reaalsust ja visiooni

tegemist reaalsuse/visiooni lihtsustusega

ühest ja samast uurimisobjektist võib olla mitu erinevat vaadet

Piltlikult väljendudes


© Karin Rava 23

Joonis 13. Mudeli piltlik väljendus

Modelleerimise eesmärgid

paremini mõista olemasolevat ja loodavat süsteemi

kooskõlastada süsteemi muutmisega seotud osapooltega infosüsteemi puudutavaid nõudmisi

üldiselt - juhtida riske, mis on seotud oodatava, soovitud tulemusega

Arhitektuuriraamistikuga pannakse paika juhised, kuidas kirjeldada ettevõtte infosüsteemi

olemasolevat ja tulevast seisu. Lisaks sisaldab see juhiseid, kuidas praegusest olukorrast

liikuda soovitud tuleviku suunas

Valitud arhitektuuriraamistiku alusel väljendatakse organisatsiooni ja tema infosüsteemi koosseisu, mida nimetatakse organisatsiooni ja infosüsteemi arhitektuuriks

Organisatsiooni ja infosüsteemi arhitektuur on organisatsiooni ja infosüsteemi kirjeldavate

mudelite ja spetsifikatsioonide (kirjelduste) kogum, mis luuakse infosüsteemis tegutsejate –

organisatsiooni töötajate soovide ja vajaduste põhjal eesmärgiga luua arusaamist, milline on

organisatsioonis ja tema infosüsteemis olemasolev seis ja millised on probleemid ja

otsustamiseks, milline see seis peaks olema tulevikus ja kuidas selleni jõuda.

Organisatsiooni ja infosüsteemi arhitektuur võimaldab:

mõõta ja juhtida organisatsiooni tegutsemist

saavutada organisatsiooni muutmise eesmärke

siduda organisatsiooni teenuseid IT-teenustega

luua ja viia ellu arhitektuurivisiooni

Arhitektuur ja selle raamistik (Inspired materjali põhjal) piltlikult väljendatuna


© Karin Rava 24

Joonis 14. Raamistiku ja arhitektuuri mõisted

Arhitektuuriraamistike näiteid:

EABOK (Enterprise Architecture Body of Knowledge)

FEAF (Federal Enterprise Architecture)

TOGAF (The Open Group Architecture Framework)

GERAM (Generalised Enterprise Reference Architecture and Methodology)

Inspired Enterprise Architecture Frameworks

Zachman Framework

John Zachman-i ettevõtte IS arhitektuuriraamistik organisatsiooni juhtimiseks ja tema infosüsteemi arendamiseks oluliste mudelite

liigitamise ja organiseerimise loogiline struktuur

võimaldab infosüsteemi loomisel ja muutmisel osalevatel erinevatel osapooltel omavahel suhelda ja ühist arusaamist luua

ettevõte ja tema infosüsteem on jagatud 6 osaks ehk aspektiks andes 5-le infosüsteemi muutmise osapoolele nende jaoks vajaliku täpsusega informatsiooni üle kõikide aspektide moodustades vastava mudeli


© Karin Rava 25

Raamistik üldiselt

Joonis 15. Zachman-i arhitektuuriraamistik

Raamistiku sisu

Tabel 2. Zachman-i raamistiku sisu

Andmed Tegevused Asukohad Inimesed Aeg Motivatsioon

Planeerija

vaade

Toimimisobjek-

tide loetelu

Toimimis-

protsesside

loetelu

Toimimimis-

kohtade

loetelu

Struktuuriüksuste

(tegutsejate)

loetelu

Toimimis-

sündmuste

loetelu

Toimimis-

eesmärkide

loetelu

Omaniku

vaade

Kontseptuaal

mudel

Toimimis-

protsesside

mudel

Protsesside

teostuskohad

Tegutsejate

vastutused

töötulemuste

lõikes

Protsesside

stsenaariumid

Toimimisplaan

Disaineri

vaade

Loogiline

andmemudel

Rakenduste

funktsionaal-

sus

Loogiline

arhitektuur

Kasutajaliideste

arhitektuur

Protsessi osa

stsenaarium

Toimimis-

reeglite mudel

Ehitaja

vaade

Füüsiline

andmemudel

Programmi

disain

Füüsiline

arhitektuur

Kasutajaliideste

disain

Juhtimisvood,

trigerid

Toimimis-

reeglite disain


© Karin Rava 26

Alltöövõtja

vaade

Andmete

definitsioonid

Detailne

programmi

disain

Võrguarhitek-

tuur

Kasutajaõigused Trigerite

kirjeldused

Reeglite

spetsifikatsioon

Operatsioo-

niline vaade

Tegelikud

andmed

Programmi-

kood

Realiseeritud

kommuni-

katsioon

Koolitatud

töötajad

Toimimis-

tsüklid

Kehtestatud

reeglid –

realiseerunud

strateegia

IS arendamisel osalejate vaated

Joonis 16. Infosüsteemi arendamise osapoolte vaated

Täpsemalt

organisatsiooni juhtkonna vaade - muudetava osa suurus, seosed ümbrusega, toimimise eesmärgid ja strateegia – annab teiste huvirühmade vaadetele nö ―mängumaa‖

organisatsiooni liikmete vaade - organisatsiooni ja tema infosüsteemi toimimise ülesehitus

disaineri (arhitekti) vaade - kuidas infosüsteem sõltumatult lahenduse spetsiifikast organisatsiooni infovajadusi rahuldab

süsteemi ehitaja vaade - tehniline nägemus realiseeritavatest rakendussüsteemidest ja tehnoloogiatest ehk kuidas süsteem realiseeritakse; annab spetsiifilised lahendused ja tehnoloogiad ning näitab konkreetsete toodete piirangud

alltöövõtja vaade- detailne spetsifikatsioon realiseeritava süsteemi osast


© Karin Rava 27

Süsteemianalüüsi määratlus Analüüs tähendab lahtilõhkumist. Süsteemianalüüs vastab küsimustele: mis on olemasolevas süsteemis ja mida on vaja uue/muudetud süsteemi jaoks. Süsteemianalüüs on protsess, mille tulemusena määratletakse süsteem ja sellele esitatavad nõuded erinevate vaadete lõikes. Süsteemianalüüs annab lähteinfo infosüsteemi lahenduste arhitektuuri loomiseks

Süsteemianalüüsi eesmärk on süsteemi mitmevaateline määratlemine – modelleerimine:

organisatsiooni objektiivsete infovajaduste ja –soovide selgitamiseks

infosüsteemi komponentide maksumuse ja nendele kuluva aja hindamiseks

infosüsteemi disaini ettevalmistamiseks

Vaateid testitakse

formaalsete kriteeriumite järgi

organisatsiooni liikmete soovide ja nõuete järgi

Süsteemianalüüsi protsess koosneb 2-st põhisammust, kus mõlemal sammul teostatakse

tsükliliselt 2 tegevust:

faktide kogumine

saadud info dokumenteerimine - kaardistamine – modelleerimine - analüüs

Samm 1 - süsteemianalüütik koostab esialgsed mudelid "iseenda tarkusest― kasutades

dokumente

varasemaid süsteemianalüütilisi töid

tellija poolt formuleeritud põhiprobleeme, nõudeid või lausendeid süsteemi objektide, protsesside, asukohtade, tegijate määratlemiseks

Süsteemianalüüsi lähteandmed

varasemad teadmised analüüsitavast süsteemist

o varasemad süsteemianalüüsiaruanded

o projektipakkumises esitatud dokumendid ja nõuete/vajaduste loendid

o organisatsiooni varasemad mudelite- või tarkvarasüsteemid

organisatsiooni toimimist kajastav dokumentatsioon

o asutuste ja struktuuriüksuste põhimäärused või töökorralduslikud dokumendid

o ettevõtte/organisatsiooni tegevusala käsitlevad seadused ja valitsuse määrused

süsteemianalüütiku enda nö ―ajalooline mälu‖, mida ta hoiab mudelitena, koostatud aruannetena (või selle osadena) kasutades CASE vahendeid

Samm 2 on lähtemudelite parandamine.

Süsteemianalüüsi meetodid taustaanalüüs


© Karin Rava 28

küsitlused, intervjuud

toimimise vaatlemine

olemasolevate dokumentide/aruandevormide analüüs

ankeetküsitluse kasutamine

mingi situatsiooni/nägemuse pakkumine tulevastele kasutajatele ja selle analüüs koos kasutajatega

konkreetse meetodi õpetamine kasutajale ja temaga koos osaprojekti tegemine

analüüsiülesannete kasutamine täiendkoolituses

Taustaanalüüs

Organisatsiooni kohta taustamaterjali läbitöötamine

Eelised:

aitab anda esialgse arusaamise enne kohtumist organisatsiooni inimestega

võib anda formaalselt defineeritud infonõuded

Puudused:

kirjalik dokumentatsioon ei pruugi kokku minna reaalse eluga

dokumentatsioon võib olla aegunud

ametlik poliitika võib olla tegelikust toimimisest erinev

Intervjueerimine

Süsteemianalüütiku(te) ja organisatsiooni liikme(te)ga toimuv üritus

Eelised:

võimaldab täpsustavat küsitlust

annab kõige rohkem infot organisatsiooni toimimise kohta

Puudused:

nõuab kõige rohkem aega, kõige kulukam tehnika

intervjuu tulemused tuleb läbi töötada

võib tekitada intervjueeritavate ja intervjueerijate suhtes eelarvamusi

kui erinevad intervjueeritavad annavad konfliktset infot, on raske neid hiljem lahendada

Toimimise vaatlemine

Organisatsiooni töötajate igapäevatöö (tegeliku infovahetuse) jälgimine

Eelised:

annab arusaamise sellest, kuidas süsteemis toimitakse

on võimalik jälgida protsesside kõrvalekaldeid

on võimalik kätte saada protsesside tegelikud sisendid ja väljundid


© Karin Rava 29

Puudused:

enamus inimestele ei meeldi, kui neid jälgitakse ja võivad tavalisest erinevalt toimida

vaatlus nõuab kogenud vaatlejaid

võib tekkida logistilisi probleeme, kui protsesse läbitakse geograafiliselt erinevates kohtades

võib tekkida eetilisi probleeme, kui on tegemist tundliku ja/või privaatinfo töötlemisega või suhtlusega avalikkusega

Dokumentide vormide analüüs

Analüütik võib saada intervjuu käigus organisatsioonis kasutuselolevate dokumentide täidetud või täitmata blankette. Vormide järgi saab otsustada:

o millised on protsesside sisend- ja väljundandmed - tellimuse, aruande struktuur

o andmemahtusid - mitu tellimuse rida ekraanile korraga kuvada

Ankeedid - küsimustikud

Kirjalikud küsimused organisatsiooni liikmetele vastamiseks

Eelised:

infot on võimalik koguda suure hulga inimeste käest

hästi struktureeritud küsimustiku vastuseid on hõlbus töödelda

Puudused:

häid küsimustikke on raske luua

ei ole võimalik täpsustavalt küsida

vastuseid on raske saada

Protsessi definitsioone Inseneriasjanduse kontekstis - sündmuste jada, kus kasutatakse sisendeid väljundite loomiseks

Organisatsiooni tegutsemise kontekstis:

koordineeritud ja standardiseeritud tegevuste voog, mida teostatakse inimeste või masinate poolt, et saavutada tegutsemise eesmärki luues väärtust kas organisatsioonisisestele või –välistele klientidele

töötegevuste (või ressursside) spetsiifiline järjekord üle aja ja ruumi, millel on algus ja lõpp ning selgelt defineeritud sisendid ja väljundid

tegevuste hulk (töövoog - workflow), mille tulemusena antakse ―käegakatsutav‖ väärtus välisele tegutsejale (business actor)

Miks on tähelepanu all protsessid?

protsessidega toimub väärtuse loomine

halbadel majanduslikel aegadel otsivad ettevõtted võimalusi protsesside tõhustamiseks


© Karin Rava 30

headel majanduslikel aegadel otsivad ettevõtted võimalusi laienemiseks, tootmise suurendamiseks ja uutele turgudele sisenemiseks

Organisatsiooni protsesside muutmine On protsesside parendamine organisatsiooni eesmärkide (paremaks) täitmiseks. Vastavalt väärtusahela põhimõttele peavad protsessid lisama väärtust ja ei tohi sisaldada mittevajalikke tegevusi, mis tähendab ka seda, et protsessid peavad olema koordineeritud ja standardiseeritud

Hästi kujundatud toimimisprotsessi väljunditeks on:

suurenenud efektiivsus (effectiveness) – väärtus kliendile

suurenenud tõhusus (efficiency) – toimimise madalamad kulud

Organisatsiooni protsesside muutmisvõimalused

protsessi ümberkorraldamine (process re-engineering) - protsesside toimimise põhimõtete muutmine organisatsiooni strateegilisel ehk terviktasemel

protsessi ümberkujundamine (process redesign) - protsessi osade (alamprotsesside) muutmine töö määratluse muutmise või automatiseerimisega

protsessi parendamine (process improvement) - protsessi teostuse kvaliteedi tõstmine

Protsesside parendamise jaoks on vaja määratleda ja ära kaotada:

dubleerivad tegevused

väärtust mitteandvad tegevused

lüngad ja seisakud

Väärtust mitteandvad tegevused:

ettevalmistus ja seadistus

kontroll ja inspekteerimine

protsessi objekti liigutamine ühest kohast teise ilma seda füüsiliselt muutmata

tegevused, mis on tingitud viivitusest või tõrkest (n: infopuudusest)

Protsess või tegevus lisab väärtuse kui:

klient on nõus väljundi eest maksma

väljundit muudetakse füüsiliselt

tegevust teostatakse korrektselt juba esimesel katsel

Protsessianalüüs ja modelleerimine Eesmärgid

saada aru, milliseid protsesse organisatsioonis teostatakse ja kuidas

leida võimalusi protsesside automatiseerimiseks

kaaluda protsesside ümberkorraldamist


© Karin Rava 31

Tulemuseks protsessivaade

annab ülevaate protsessidest, millega organisatsioon huvigruppide poolt püstitatud eesmärke ja ootusi täidab

loob arusaamise, läbi milliste tegevuste protsesside teostus toimub

annab aluse protsesside parendamiseks

Protsessivaade näitab

ressursse, kes/mis omavahel koostööd teevad

väärtust, mida protsessi tulemusena saavutatakse

toimimise sündmusi, mis protsessi ja selles sisalduvaid tegevusi käivitavad ja lõpetavad

sisendobjekte: materjale või andmeid

väljundobjekte: protsessi tulemust – sisesele või välisele kliendile pakutavat väärtust

Protsessianalüüsi sammud

organisatsiooni eesmärkide määratlemine

organisatsiooni huvigruppide ja nende ootuste määratlemine

ootuste täitmiseks protsesside sõnastamine (―mida‖ pool) - andes analüüsitavate protsesside koguhulga, nö ―suure pildi‖ organisatsiooniga suhtlejate vaatenurgast

protsesside sammude määratlemine (―kuidas‖ pool) - organisatsiooni jaoks oluliste objektide elutsükli ja elutsükliliste etappidega seotud tegevuste määratlemine

protsesside teostuse analüüs ja muutmisvõimaluste määratlemine

Infosüsteemi muutmise kontekstis seisneb protsessianalüüs tegevuste

automatiseerimisvõimaluste määratlemises - eesmärk on analüüsida ja modelleerida vaid need

protsessid ja tegevused, millele IT-alane tugi annab kasu. Vaja luua nö vahemudel, mida võib

nimetada ―IT toega tegevuste protsessimudeliks‖. Protsessis tegevused, mille teostamist saab

automatiseerida, väljendatuna infotöötegevustena - paberil tehtavatest tegevustest saavad

tarkvarasüsteemi tegevused ehk kasutuslood

Protsesside analüüsi ja modelleerimise tulemusena saab otsustada:

millised protsessid (või nende osad) jäävad sisaldama inimtöötegevusi ja millised protsessid (või nende osad) automatiseeritakse või korraldatakse ümber

milline saab olema infosüsteemi andmekoosseis, mis rahuldab organisatsioonis tegutsejate ja sellega suhtlejate infovajadusi

Protsesside kirjeldusi saab võtta tarkvarasüsteemi kasutuslugude mudeli loomise aluseks, et

näidata, milliste tegevuste teostamisel protsessis oleks tarkvarasüsteemist kasu. Saab kätte

nõuded tulevas(t)ele tarkvarasüsteemi(de)le ning andmehoidlatele.

Infosüsteemi protsessid

Infotöötlusprotsessid - toimimisobjektidega seotud andmetega manipuleerimine


© Karin Rava 32

tellimuse täitmisprotsess

taotluse/avalduse rahuldamisprotsess

lepingu kooskõlastamisprotsess

Toimimisobjektiga teostatavate infotöötegevuste koordineeritud hulk - toimimisobjekti ja selle seisundeid väljendavate andmete haldamine muutes protsessikäiku informatsiooniliselt jälgitavaks

Objekti elutsükli modelleerimine Objekti seisundite (olekute) ja nende omavahelise järgnevuse esitamine.

Objekti elutsükkel - peamised etapid, mida objekt oma eluea jooksul läbib (üldistatult: määratlemine, soetamine, kasutus ja likvideerimine). Etapi läbimise tulemusena objekt saab mingi seisundi

Objekti seisund - objekti iseloomustavate omaduste väärtuste kogum

Seisundidiagramm esitab objekti kõiki võimalikke seisundeid süsteemis, nende muutumist põhjustavaid sündmusi ja tegevusi. Igale objekti puudutavale sündmusele vastab infotöötegevus, mille tulemusena seisundimuutus infosüsteemis andmeliselt fikseeritakse

Tarkvarasüsteemi kasutuslugude modelleerimine Esitab tarkvarasüsteemile esitatavad funktsionaalsed nõuded, mida on tarkvarasüsteemiga võimalik teha ja kes seda kasutab andes välise pildi tarkvarasüsteemi käitumisest vastusena kasutajapoolsele tegevusele. Kasutuslugude mudeli loomiseks on vaja:

defineerida tarkvarasüsteemi ulatus (skoop)

määratleda tegutsejad (süsteemi kasutajad)

määratleda kasutuslood

kirjeldada need

defineerida kasutuslugude omavahelised seosed

Tegutseja (Actor) - keegi või miski, kes/mis otseselt või kaudselt suhtleb tarkvarasüsteemiga

ning kasutab süsteemi poolt pakutavaid teenuseid, et saavutada midagi - inimene või teine

süsteem (arvuti, seadeldis)

Kasutuslugu (Use Case) - lugu, kuidas süsteemi mingil viisil kasutades tehakse midagi

kasulikku: ainus eesmärk on anda tegutsejale mingit väärtust

Kasutusloo eesmärgi täitmisele orienteeritud süsteemi ja selle kasutaja omavaheline koostöö - üksteisele järgnevate tegevuste (transaktsioonide) kogum, mida süsteem teostab, et jõuda mõõdetava tulemuseni tegutseja jaoks (tegevused võivad sisaldada suhtlemist teiste kasutajate ja süsteemidega)

Kasutusloo omadused:

käivitatakse ja teostatakse alati tegutseja abil


© Karin Rava 33

pakub tegutsejale mingit väärtust, st see on täielik

Infosüsteemi kontekstis on kasutuslugudeks infotöötegevused - pool- või täisautomaatselt

tehtavad:

andmete registreerimine või sisestamine

andmete muutmine

andmete vaatamine

andmete kustutamine

andmete arhiveerimine

Kasutatakse ka üldnimetust ―haldamine‖ - n: tellimuse haldamine sisaldab kõiki tellimuse andmetega tehtavaid tegevusi

Kasutuslugude kirjeldamine mida üritatakse sellega saavutada, mis on selle eesmärk?

kes tegutsejatest käivitavad kasutusloo?

milliseid objekte süsteemis kasutatakse või muudetakse?

millised on võimalikud stsenaariumid (sündmuste jadad), mis on seotud ―väärtusliku asjaga‖, mida süsteem teeb ühe või mitme tegutseja jaoks?

milliseid sõnumeid tegutseja ja süsteem omavahel vahetavad?

millal kasutuslugu loetakse lõpetatuks ja milline väärtus edastatakse tegutsejale?

Toimimisobjektide (mõistete – kontseptide) modelleerimine Eesmärgid:

anda arusaam ―asjadest‖, mis on organisatsiooni protsesside sisenditeks ja väljunditeks ja mida on vaja juhtida

määratleda mõisted, mida organisatsioonis kasutatakse (sõnavara)

anda alus andmehoidlate, eelkõige andmebaaside sisu - andmeobjektide määratlemiseks

Tulemused:

toimimissüsteemi mõisteid kajastav kontseptuaalmudel

mõistete kirjeldus-seletus

Objekt (entity, concept, object) - probleemvaldkonna ‖asi‖, kontsept (mõiste), mis annab arusaamise reaalsest maailmast

Toimimisobjekt (business entity, business object) - mistahes asi, mida on vaja juhtida ja/või millega töötajad protsessides opereerivad

elus (klient, töötaja)

elutu (toode, vahend)


© Karin Rava 34

dokumendipõhine (tellimus, saateleht, arve, pakkumine, töökäsk)

abstraktne (projekt, probleem, eesmärk)

Toimimisobjektide mudeli - kontseptuaalmudeli koostamine lausendite meetodil

Lausendi konstruktsioon: ―alus-öeldis-sihitis‖

valida teatav hulk organisatsiooni ja selle protsesse kirjeldavaid lausendeid

otsida ja üldistada mõisted

sidestada mõisted lausendite järgi (läbi verbide)

Andmete modelleerimine Eesmärk on fikseerida infosüsteemis kasutatavad andmed objektitüüpidena (olemitüüpidena-andmeobjektidena) ja nendevaheliste suhete tüüpidena

Objektitüüp (olemitüüp, andmeobjekt)

esitab reaalse maailma - organisatsiooni kontekstis tema toimimiseks vajalike - objektide hulka, mille/kelle kohta on vaja infosüsteemis andmeid meeles pidada

tähistab kontseptuaalmudelil esitatud sellist mõistet, mille/kelle kohta käivaid andmeid on vaja infosüsteemis hallata

Objektitüüp esitab objektide ehk eksemplaride hulka, mis peavad olema üksteisest eristatavad

Igat objektitüüpi iseloomustab 1 või mitu omadust (atribuuti) moodustades andmestruktuuri

Igal konkreetsesse objektitüüpi kuuluval eksemplaril on konkreetse omaduse jaoks konkreetne väärtus

Eksemplarid eristuvad üksteisest omadus(t)e väärtus(t)e järgi

Igat eksemplari määratletakse üheselt võtmeomaduse või –atribuudi (või omaduste kombinatsiooni) kaudu

Suhtetüüp (relatsioonitüüp) esitab seoste hulka eksemplaride vahel - suhtetüübi iga eksemplar esitab seost ühe objektitüübi 1 või mitme eksemplari ja teise objektitüübi 1 või mitme eksemplari vahel

Suhteeksemplar võib siduda sama objektitüübi 2 või enamat eksemplari

Suhtetüüp võib samuti omada omadusi olles seoseobjektitüübiks

Piirangud andmete modelleerimises Vastavalt analüüsitavas organisatsioonis kehtestatud reeglitele võivad eksemplaride, seoste ja omaduste juures eksisteerida piirangud

kardinaalsus määratledes seoste arvu objekti kohta

sõltuvus (seose tugevus) määratledes ühe objektitüübi objekti olemasolu sõltuvuse teise objektitüübi objektist

liigitus määratledes sõltuvalt objekti liigist erinevat liiki seose omamise


© Karin Rava 35

Kardinaalsuspiirangud

1:1

Tähistus

A B11

1:M

Tähistus

A B**

M:N

Tähistus

A B*** *

Sellist tähistust loetakse veaks!


© Karin Rava 36

Mida tehakse?

Tähistus

A BC1..* 1..*1..* 1..*

Objektitüübi omaduste (atribuutide) määramine määrates omadust, kas see omadus iseloomustab just seda objektitüüpi?

milliseid väärtusi see võib omada?

kas väärtuste taga ei peitu iseseisev objektitüüp?

o kui JAH, modelleeri seoseobjektitüübina (uus objektitüüp)

o kui EI, jääb omaduseks

füüsilistel objektidel on omaduseks AEG (seisundi algus, lõpp)

tegevustel on kindlasti omaduseks AEG (algus, lõpp)

kontrolli, kas omaduste väärtuste uuendamiseks on leitud sündmused ja kasutuslood

Andmete normaliseerimisreeglid määratle igale objektitüübile võtmeomadus, mille väärtus on igal sellesse objektitüüpi

kuuluval eksemplaril unikaalne

o n: tellimuse nr, dokumendi nr, arve nr jne

kui objektitüübi omadus saab samal ajahetkel omada mitut väärtust, siis vii see omadus selle objektitüübiga 1:M seoses oleva „mitu poole― objektitüübi omaduseks

o objektitüübis ―TELLIMUS‖ omadus ―toote nimetus‖ omab samaaegselt mitut väärtust (1 tellimusega võib tellida mitut nimetust toodet)

kui objektitüübi omaduse väärtus ei sõltu võtmeomaduse väärtusest, siis vii see omadus selle objektitüübiga 1:M seoses oleva „1 poole― objektitüübi omaduseks

o objektitüübis TELLIMUS omadus ―kliendi nimi‖ jääb samaks sõltumata sellest, millist väärtust omab TELLIMUS võtmeomadus ―tellimuse number‖


© Karin Rava 37

Objektitüübist andmetabel Tabel on ridadest ja veergudest koosnev andmekogum

Tabeli rida ehk kirje (record) on mōisteliselt terviklik ja omaette tähendust omav andmeüksus

Tabeli rida koosneb andmeelementide ehk tabeli veergude jadast

Tabeli veerg ehk väli (field) on omaette tähendust omav andmeüksus

Igal väljal on nimi, mida vōib vaadelda kui veeru pealkirja ning tüüp, mis määrab andmete esitusviisi. Väljade määramisel vōetakse aluseks objektitüübi omadused

IS muutmine (arendamine) kui probleemi lahendamine

IS loomis- ja muutmistegevused analüüsitegevused - määratlemine, milles seisnevad probleemid olemasolevas

infosüsteemis ja mida muudetud (parendatud) infosüsteemis peab olema võimalik teha (millistele nõuetele infosüsteem peab vastama)

disainitegevused - määratlemine, kuidas parimal viisil infosüsteemis analüüsiga paikapandud nõudeid täita

ehitustegevused - disainilahendus(t)e elluviimine

rakendamistegevused - lahenduste kättetoimetamine organisatsioonis tegutsejatele ja nende töökorralduse muutmine

Piltlikult väljendatuna


© Karin Rava 38

Joonis 17. IS-i muutmistegevused

Disain Infosüsteemis kasutatava infotehnoloogilise infrastruktuuri, rakendussüsteemide ja andmebaaside kujundamine - projekteerimine piisava detailsuseni ehitamise (realiseerimise - programmeerimise) alustamiseks

Täpsemalt - analüüsiga saadud tulemuste ja väljatoodud nõudmiste jaoks parimate tehnoloogiliste lahenduste leidmine; kasutatava tehnilise keskkonna (riistvara, tarkvara) tingimustes

Tulemuseks on tulevase infosüsteemi mudel esitatuna disaini täpsusega

Disaini põhitegevused

infosüsteemi ülesehitust puudutavate nõudmiste paikapanemine

infosüsteemi (terviksüsteemi) infrastruktuuri ja rakendussüsteemide arhitektuuri kujundamine

rakendussüsteemide komponentide (süsteemi osade) ja nende omavaheliste liideste kujundamine

kasutajaliidese (ekraanivormide) kujundamine

andmehalduse ja andmebaasi(de) projekteerimine

Disainijuhiseid

kasutajaid puudutavad

o pööra tähelepanu kohtadele, kus kasutajad süsteemi kasutavad

o arvesta kasutajate, süsteemi ja organisatsiooni vajadustega tulevikus

andmeid puudutavad

o andmesisestus peab toimuma siis ja seal, kus andmed tekivad

o andmesisestusel peab toimuma andmete nõuetele vastavuse kontroll

o kasuta automatiseeritud andmesisestust kus on see vähegi võimalik

o iga andmesisestus ja nende muutmine peab saama logitud

o samade andmete sisestus peab toimuma vaid ühekordselt

arhitektuuri puudutavad

o kasuta modulaarset disaini


© Karin Rava 39

o kujunda üksteisest sõltumatuid mooduleid, mis täidavad ühte funktsiooni

Infosüsteemi arhitektuuri kihid

organisatsiooni toimimise kiht (töötajad, töökorraldus)

rakendussüsteemide kiht (lõppkasutaja tarkvara, veebirakendused jne)

andmekiht (andmebaasid, failid jne)

riistvara kiht (arvutid, seadmed jne)

andmeside kiht (arvutivõrgud, telekommunikatsioon jne)

Nõudmised arhitektuurile

Analüüsi käigus saadud funktsionaalsetele nõudmistele (mida teha?) lisanduvad mittefunktsionaalsed nõudmised (kuidas teha?), Näiteks:

süsteem peab toetama erinevaid keeli

andmebaas peab olema relatsiooniline

süsteem peab töötama 7 päeva nädalas, 24 tundi ööpäevas

abiinfo peab olema kättesaadav reaalajas

kasutajaliides peab olema kirjutatud PHP-s

Kasutaja ja tarkvara vahelise sõnumivahetuse tüübid

Andmete paiknemine

Hajutatult, tsentraalset, ―seguna‖ nendest viisidest, Tavaliselt paiknevad hajutatult - lokaalsetes andmehoidlates. Iga töötaja või osakond kogub andmed enda juurde:

klienditellimused kogutakse müügiosakonda

kliendiarved kogutakse raamatupidamisse

Andmehulgad luuakse ja hoitakse igas andmehoidlas eraldi, mis tähendab seda, et paljud andmed on mitmekordselt, n: kliendi nimi ja aadress

Sellisel juhul on tegemist andmeliiasusega (redundancy) ja andmete muutumisel võidakse muuta ainult ühte andmehulka. See omakorda toob endaga kaasa konflikti andmete terviklikkusega (data integrity). Kuivõrd andmed ükskõik millises andmehoidlas on korrektsed ja omavahel kokkusobivad.

Andmete paiknemine hajutatult - lokaalsetes andmehoidlates


© Karin Rava 40

Joonis 18. Andmete paiknemine hajutatult

Andmete paiknemine tsentraalselt

Ühiskasutusega andmete jagamine erinevate töötajate vahel ja ühiskasutusega andmeid muudetakse ainult 1-st kohast

Joonis 19. Andmete paiknemine tsentraalselt

Ehitus (konstrueerimine) Disaini tulemusena loodud mudelite (määratluste) alusel töötavate, kasulike rakendussüsteemide ja andmebaaside loomine - disainitulemuste realiseerimine

Realiseeritud rakendussüsteemide tervikuks integreerimine - süsteemidevaheliste liideste loomine

(Integreerimis)tulemuste testimine

Ehituse tegevused

programmikoodi kirjutamine/genereerimine

andmebaasi(de) loomine (genereerimine) ja optimeerimine (denormaliseerimine, indeksid …)

ligipääsuõiguste kirjeldamine


© Karin Rava 41

erinevate komponentide (andmebaasi(de)/rakenduste) integreerimine tervikuks (vaheliideste loomine)

programmide (tarkvara) testimine

lõpp-kasutaja keskkonna ettevalmistamine ehitustulemuste rakendamiseks

Tarkvara testimine

tarkvara kvaliteedi hindamine ja selle parandamise eesmärgil defektide ja probleemide määratlemine

programmi käitumise kindlakstegemine oodatud käitumise suhtes

eeldab testimisplaani olemasolu, kus kirjas

o mida on vaja testida

o kuidas testi läbi viia

o kriteeriumid, mille järgi otsustada, kas test on läbitud edukalt või edutult

o testimise järjekord

o testimisandmed piirsituatsioonide testimiseks

Testimisliigid

black box ehk musta kasti test - kas testitav üksus teeb seda, mida see peaks tegema ja kas tehakse seda nii kiiresti kui ette nähtud?

white box ehk valge kasti test - kui hästi on testitav objekt välja töötatud?

komplekstest - kas infosüsteemi protsessid toimivad ka koos korrektselt?

regressioontest - kas infosüsteemi uute osade või muudatuste rakendamise tulemusena ei ole kahanenud süsteemi varasem funktsionaalsus?

rollitest - kas õigused tegevuste teostamiseks on tõepoolest piiratud rollis kirjeldatud õigustega?

Testimise tasemed

1. tase

o individuaalsete moodulite (klasside) või programmide test (kasutuslood)

o kogu programmide komplekti test (terve rakendus)

2. tase - alpha test või verifitseerimine

o programmide käivitamine simulatsioonikeskkonnas

o testid, mille sisenditeks on

oodatavate positiivsete asemel negatiivsed ja vastupidi

piiridest väljasolevad

vigased kombinatsioonid

3. tase - beta test või valideerimine


© Karin Rava 42

o testib programme tegelikus kasutajakeskkonnas vastuste ja täitmisaegade suhtes

o suurte andmehulkadega

Ehituse tulemused

realiseeritud ja häälestatud andmebaas(id) koos vajalike failidega (andmefailid, juhtfailid, logifailid)

realiseeritud ja testitud infrastruktuur

realiseeritud ja testitud rakendustarkvara

esialgsed abisaamise võimalused kasutajatele

plaan rakenduse läbiviimiseks ja lõpp-kasutajatepoolseks vastuvõtmiseks

Rakendamine Projekteeritud ja ehitatud andmebaasi(de) ja rakendussüsteemide viimine kasutajakeskkonda (organisatsiooni töökeskkonda) või kasutajakeskkonnas kättesaadavaks tegemine ja kasutajate poolt tulemuste hindamine

Rakendamise tegevused

töökeskkonna muutuste ettevalmistamine

tööprotseduuride kavandamine

ametijuhendite/kasutajajuhendite loomine

kasutajate koolitus

andmete siirdamise ettevalmistamine ja läbiviimine

uuele süsteemile ülemineku ettevalmistamine ja teostamine

aktsepteerimistestimise (kasutajatepoolse vastuvõtmise) ettevalmistamine ja läbiviimine

rakendusjärgse ülevaatuse teostamine

hoolduse seadistamine

Üleminekustrateegiad muudetud infosüsteemile

täielik üleminek

paralleelne toimimine

etapiline üleminek

pilootprojekt

Täielik üleminek

Kokkulepitud kuupäeval lõpetavad kasutajad vana süsteemi kasutamise ja alustavad uue süsteemi kasutamisega

Üleminek toimub tavaliselt nädalavahetusel


© Karin Rava 43

Eelised

uus süsteem toob endaga kaasa kohese äritulu ja hakkab ennast kohe ära tasuma

sunnib kasutajaid töötama uue süsteemiga ja nad ei saa enam vanale tagasi pöörduda

üleminekut on kerge planeerida

Puudused

probleemide korral ei ole tagasipöördumist vanasse seisu

üleminekuplaan peab töötama ilma raskusteta

Paralleelne toimimine

Uus süsteem töötab samaaegselt vanaga

Eelised

uue süsteemi probleemide korral on varuvariant olemas

uue ja vana süsteemi väljundeid saab omavahel võrrelda, nii saab testimist jätkata

Puudused

nii uut kui ka vana süsteemi on vaja hooldada, seeläbi suuremad kulutused

kasutajad ei pruugi olle lojaalsed uuele süsteemile, kuna on lihtsam tagasi pöörduda vana süsteemi kasutamise juurde

Etapiline üleminek

Süsteemi rakendatakse allsüsteemide kaupa

Eelised

igale üksikule rakendatavale allsüsteemile saab pöörata suuremat tähelepanu

iga allsüsteemi juures saab läbi viia põhjaliku testimise

Puudused

ühe allsüsteemi rakendamise läbikukkumine võib mõjutada teiste süsteemide rakendamist

organisatsioon ei pruugi nii kiiresti hakata tulusid teenima kui oodatud

Pilootprojekt

Süsteemi etapilise rakendamise variatsioon

Suure süsteemi väiksemas mahus töösseandmine

Saab kiirelt kogemusi ja muudatus-ettepanekuid enne terviksüsteemi rakendamist

Rakendamise tulemused

testitud ja hinnatud andmebaas(id) ja rakendustarkvara

süsteemi lõplik dokumentatsioon

lõpp-kasutajatele kasutusjuhendid


© Karin Rava 44

hoolduskeskkond

Hooldus Infosüsteemi muudatuste rakendamisjärgne tegevustik. Arendamistegevuste ja -tulemuste läbivaatamine ja järelduste tegemine, mille raames toimub:

taaskasutatavate komponentide täpsustamine

rakendussüsteemide vigade parandus

nõuete/muudatuste haldamine

kasutajate toetamine läbi kasutajatoe (helpdesk)

IS arendusmetodoloogia (-metoodika)

Kogu infosüsteemi muutmise elutsüklit kattev kogum soovituslikest sammudest, lähenemistest,

reeglitest, protsessidest, dokumentidest, kontrolliprotseduuridest, meetoditest, tehnikatest ja

vahenditest defineerides kes, millal, mida ja kuidas peab infosüsteemi muutmise juures

tegema

Struktureerib süsteemiarendusprotsessi sisaldades etappide, alametappide, protsesside,

etappide sisendite ja väljundite (oodatavate tulemuste), protseduuride, tehnikate, vahendite ja

loodava dokumentatsiooni kirjeldusi

Metodoloogia elemendid

Joonis 20. Metodoloogia elemendid


© Karin Rava 45

Metodoloogia kasutamise miinused

ennemini vähendavad kui suurendavad sisulise töö tegemise tõhusust ja seda tänu nõutavale liigsele bürokraatiale

põhinevad kindlatel jäikadel eeldustel ja üldistustel arvestamata erandeid

ei arvestata tööjõu voolavust või nende kogenematust

põhinevad liigselt tehnilisel poolel, aga mitte sotsiaalsetel aspektidel

Metodoloogia kasutamise plussid

pakub süsteemi disaini-, arendus- ja realiseerimisprotseduuride standardiseeritust

kindlustab tulemuste kvaliteeti

võimaldab juhtida muudatusi

kindlustab realiseeritud komponentide taaskasutust samas või teistes süsteemides

võimaldab arendusprotsessi ja kasutatavaid ressursse paremini juhtida

võimaldab saadud teadmisi ja kogemusi paremini hallata

Süsteemiarendusmetodoloogia valiku kriteeriumid

arendatava süsteemi olemus ja ulatus (skoop)

uue süsteemi loomise või olemasoleva süsteemi muutmise kriitilisus

eelarve

meeskonna suurus

kasutatav tehnoloogia

kasutatavad vahendid ja tehnikad

organisatsioonis eksisteeriv töökultuur

Muudetavas infosüsteemis kasutuselevõetavate tarkvarasüsteemide olemus

Steve McConnel oma raamatus "Rapid Development" eristab süsteemide olemuse 3 tüüpi

demod ja ―proof-of-concept‖ prototüüpimine - vajab kontseptuaalset modelleerimist koodi kirjutamise juhtimiseks, mitte aga detailseid nõudeid, disaini või testimist

uue tehnoloogiaga rakenduse loomine - nõuab kasvatavat lähenemist korrates arhitektuuri, detailse disaini, kodeerimise ja testimise etappe

stabiilse süsteemi (rakenduse) edasiarendus (hooldus) - nõuab klassikalist meetodit korrates hästimõistetud protsessi hästimõistetud süsteemi jaoks


© Karin Rava 46

Projekti kriitilisus + meeskonna suurus

Joonis 21. Cockburn projekti kriitilisuse ja meeskonna suuruse mudel

Boehm ja Turneri radaridiagramm

projektis osalejate oskuste/kogemuste tase

dünaamika – projektis asetleidvate muudatuste tase

kultuur – organisatsiooni temperament – kaos vs kord

meeskonna suurus

kriitilisus

Joonis 22. Boehm ja Turner-i radaridiagramm


© Karin Rava 47

Klassikaline lähenemine (Kose metoodika - waterfall)

Joonis 23. Kose metoodika üldine mudel

Kose metoodika tugevused

ideaalne toetamaks vähekogenud projektimeeskondi ja projektijuhte või kui meeskonnaliikmed vahetuvad

tänu kindlalt paikapandud arendussammude järjekorrale ning tugevale dokumentatsioonile vastavuse kontrollile võimaldab kindlustada loodava süsteemi kvaliteeti, usaldatavust ja hooldatavust

süsteemi arenduse kulgemist on võimalik lihtsalt mõõta

Kose metoodika nõrkused

annab vaid ühekordse tulemuse

lükkab riskid ajas edasi, mil on kulukas parandada eelmistes etappides tehtud vigu

välistab varast süsteemi rakendamist

mõõdab edukust tehtud tööde, mitte saavutatud tulemuste järgi

Iteratiivne (korduv) ja inkrementaalne (kasvatav)

Teostatakse korduvalt nö mini-Kose metoodikat. Kõiki Kose metoodika etappe viiakse läbi väikese osa peal terviksüsteemist kuni terviksüsteemi valmissaamiseni või eelnevalt pannakse paika kõik süsteemile esitatavad nõuded, mille järel teostatakse kasvatavalt ülejäänud mini-Kose metoodikat või eelnevalt teostatakse süsteemi nõuete analüüsi ja arhitektuuri disaini ning prototüüpimist, mis lõpeb töötava süsteemiga.


© Karin Rava 48

Joonis 24. Iteratiivse ja inkrementaalse lähenemise mudel

Rational Unified Process (RUP)

On iteratiivne protsess - iteratiivsus toetab arendatavast süsteemist arusaamise suurenemist

On arhitektuurikeskne protsess - pöörab tähelepanu süsteemi arhitektuuri loomisele juba arendustsükli alguses

On kasutuslookeskne protsess - süsteemid põhinevad põhjalikul arusaamisel, kuidas neid kasutama hakatakse

RUP (makro)etapid

alustamine (Inception) - luuakse süsteemi muutmise või loomise ulatuse jaoks toimimiskasutuslood

väljatöötamine, viimistlemine (Elaboration) - luuakse süsteemi tegemise jaoks projektiplaan ja stabiilne arhitektuur

konstrueerimine (Construction) - süsteemi iteratiivne kasvatamine

siirdamine (Transition) - süsteemi viimine lõppkasutajate töökeskkonda

Arendusprotsessi pilt


© Karin Rava 49

Joonis 25. RUP metoodika mudel

Enterprise Unified Process (EUP)

Joonis 26. EUP mudel

Agiilsed (kerged, lihtsad) protsessid

XP (Extreme Programming)

Cockburn’s Crystal Family

Open Source


© Karin Rava 50

Highsmith’s Adaptive Software Development

SCRUM

Coad’s Feature Driven Development

DSDM (Dynamic System Development Method)

Agiilne lähenemine SCRUM näitel

Joonis 27. SCRUM metoodika mudel

Agiilne lähenemine

madal kriitilisus

vanad arendajad

nõuded muutuvad väga sageli

arendajate hulk väike

kaosega toimetulev kultuur

Plaanitav

kõrge kriitilisus

noored arendajad

nõuete muutuste tase on madal

palju arendajaid

korda nõudev kultuur


© Karin Rava 51

Organisatsiooni ja IS/IT strateegiline juhtimine

Organisatsioonid peavad omama IS/IT planeerimist ja strateegiaid, et hõlbustada ressursside ja investeeringute juhtimist ning kontrolli. Nad peavad investeerima vaid nendesse IS/IT projektidesse, mis võivad näidata selgeid seoseid organisatsiooni üleüldise strateegiaga

Organisatsiooni juhid vajavad juhiseid, kuidas juhtida IT-alaseid investeeringuid ja saadavaid kasusid

Strateegia

kõik sis idu3350 loengukonspektid koos sisukord › biox1 › idu3350_koik_konspid_2010.pdfkõik...

Documents