LOENG 12 | Inimene ja infosüsteem

Eesmärk

Millised nähtused ja seaduspärasused on inimese–infosüsteemi suhte, samuti inimese kui infosüsteemi komponendi vaatepunkti osas olulised? Millised on need inimese infokäitluse eripärad, mida tuleks teada, mida tuleks arvesse võtta süsteemide arendamisel ja kasutamisel?

Sisukord

Inimese asend infosüsteemi suhtes >
Inimese rollid infosüsteemis >
Rollide eristamine ja ühitamine >
Infokäitluse sotsiaalne kontekst >
Inimese infotöötlusvõimed >
Individuaalsed erinevused ja nende tähtsus infokäitluse korraldamise jaoks >
Infokäitumine >
Kognitiivne stiil >
Infoülekoormus >
Infoäng >
Süsteemiarenduseks vajalike oskuste küsimus >
Süsteemi energia. Mis paneb süsteemid käima? >
Organisatsiooni ja üksikisiku energiatase kui süsteemide arenduse vältimatu eeldus >
Probleemid/harjutused Kirjandus

1. Inimese asend infosüsteemi suhtes

Inimese positsiooni infosüsteemis või selle suhtes võib käsitada kahte moodi.



Inimest võib võtta kui süsteemivälist objekti. Teine käsitus näeb inimest mitte ainult süsteemivälise „kasutajana” vaid otseselt infosüsteemi osana. Sageli määratletakse infosüsteemi kui 4-5 liiki objektide süsteemi. Inimesed (nii kasutajad kui ka arendajad) on selle vaate järgi süsteemi üks komponentide klass – riistvara, tarkvara, andmete ehk info, töömeetodite ja –korralduse kõrval.

2. Inimese rollid infosüsteemis

Küsimus, kas inimene on infosüsteemi osa, või paikneb ta süsteemist väljas, on võib-olla pigem teoreetilise kui praktilise tähtsusega. Selge on see, et inimesed täidavad infosüsteemis mitmesuguseid operatsioone. Põhimõtteliselt võib infosüsteemideks lugeda ka täiesti ilma inimkasutajateta toimivaid arvutisüsteeme, kuid need on eri- mitte üldjuhud.

Inimene osaleb infosüsteemis mitmes rollis. Nende rollide eristamine on oluline, sest inimese tegevus infosüsteemis ei piirdu ainult info passiivse kasutamisega. Inimesed ka mõjutavad ja juhivad infosüsteemi. Niisiis, inimene võib infosüsteemis tegutseda kahes peamises rollis. Ta võib olla süsteemi arendaja (väljatöötaja, hiljem hooldaja); siia võib liigitada ka süsteemi administraatori (haldaja). Või ta on süsteemi kasutaja. Olulisteks küsimusteks on seetõttu liides süsteemi ja kasutaja vahel (user interface); samuti „liides” süsteemi arendaja ja süsteemi vahel. Organisatsioonilises kontekstis ei tööta inimesed kunagi üksi, kuigi nad süsteemi kasutamise hetkel on võib-olla tõesti füüsiliselt üksinda. Nad on suuremate või väiksemate sotsiaalsete rühmade (kollektiivide) liikmed.

Vastavalt sellele võime infosüsteemis või infosüsteemi suhtes tehtavaid inimtegevusi liigitada:
- süsteemi kasutamine
- süsteemi arendamine
- süsteemi administreerimine (haldamine).

Oluline on ülalesitatud kolme tegevusliigi väljaarendatus ja tasakaalustatus. Näiteks, tüüpilises infosüsteemis on vaja reguleerida kasutajate juurdepääsu süsteemi funktsionaalsetele võimalustele (programmidele) ja süsteemis hoitavale infole. Selle tõttu peab keegi looma uuele kasutajale konto, väärkasutuse korral sulgema selle, jne. Süsteemist on vaja teha varukoopiaid; keegi peab hoolitsema süsteemi edasiarendamise korraldamise eest – infosüsteem ei saa pikemat aega töötada iseseisvalt, vaid nõuab tervet rida haldustegevusi, mida saab täita ainult inimene.

3. Rollide eristamine ja ühitamine

Organisatsioonis on süsteemide kasutamine, arendamine ja haldamine sageli organisatsiooniliselt selgelt eristatud. Teiste sõnadega, süsteemide kasutamisega, arendamisega ja halamisega tegelevad erinevad töötajad. Kuid teatud tingimustel võib üks inimene või töötajate rühm täita ka kahte isegi kõiki kolme tegevuste liiki.



Näiteks, infosüsteemide arendusega võib tegeleda IT osakonnas üks grupp, haldusega aga teine grupp. Süsteemide väljatöötamine ja haldamine (käitamine, käitlemine) on tööde olemuselt ja ajaliselt mastaabilt küllaltki erinevad. Selle tõttu on neid sageli otstarbekas eristada. Mõnel juhul, eriti piiratud inimressursside tingimustes, on vältimatu, et süsteemi väljatöötaja võtab enda kanda ka süsteemi administreerimise. Enamasti tegelevad haldusega siiski teised inimesed kui väljatöötajad.

Väiksemate süsteemide korral võib samades töötajates ühitatud süsteemi väljatöötamine ja kasutamine. See tähendab, et rakenduse töötatakse välja kasutajate endi poolt. 1980-tel levis mõiste end-user computing, mida võiks sisuliselt tõlkida kui „kasutajate-keskse süsteemiarendusena”. Süsteemiarenduse tavaline skeem, kus kasutajad tellivad IT osakonnalt rakendusi, toob reeglina kaasa IT osakonna ülekoormamise arendusnõuetega ja süsteemide valmimist on vaja pikka aega oodata. Võimsate kuid samas kasutajasõbralike arendusvahenditega võib vähemalt osa arendustööst üle kanda kasutajatele. Teiseks võimaluseks arendustööd vähemalt osaliselt kasutajatele üle kanda on teha süsteemid „laiematena”, raamistikena, mida kasutajad saavad ise häälestada ja kohandada. Süsteemi häälestamine võib siiski osutuda nii oskusmahukaks, et kasutaja ei tule sellega ise toime.

Väga oluliseks teguriks on kasutajate tehniliste ja süsteemiarenduslike oskuste tase. Mõned kasutajad suudavad ise koostada keerukaid makrosid, sisuliselt – programmeerida süsteemidele laiendusi. Teistel on raskusi ka suhteliselt lihtsate funktsioonide kasutamisega.

4. Infokäitluse sotsiaalne kontekst

Infosüsteemi õnnestumine sõltub väga palju sotsiaalsest olukorrast, milles süsteemi üritatakse kasutusele võtta. Näiteks, ühes transpordi korraldamisega tegelevas ettevõttes töötav tudeng puutus ülikooli kursuses kokku teadmuste juhtimise (knowledge management) mõistega ning tuli mõttele oma ettevõttes ise teadmuste juhtimise süsteemi luua. Ta moodustas ettevõtte serveri ühises kettapiirkonnas uue kausta (folder) ning saatis töötajatele e-kirja, milles esitas oma idee:

inimestel on kindlasti kogunenud mitmesugust infot, mis võiks olla teistele kasulik, kuid teised inimesed ei tea selle olemasolust ega oma sellele juurdepääsu. Moodustasin kausta, sellise info jaoks. Kõik pääsevad sellel ligi. Palun, kui teil on sellist infot, paigutada see sinna kausta.

Lühikese ajaga kanti kausta üle 100 faili – hinnakirju, kontaktinfot, jm. Idee oli väga edukas ja ei nõudnud teostamiseks praktiliselt mingisugust kulu. Samas on selge, et sellise süsteemiarenduse õnnestumine sõltub oluliselt organisatsioonis valitsevast sotsiaalsest ja kultuurilisest atmosfäärist.

Läänes on küllaltki levinud süsteemiarenduse meetodid, mis käsitavad infosüsteemi arendamist mitte ainult tehnoloogilise projektina, vaid vähemalt osaliselt kui mitte valdavalt muutusena sotsiaalse süsteemis . Tuntud on Hirschheimi ja Kleini poolt koostatud infosüsteemide arenduse nelja paradigma mudel. Eestis on need vaated veel vähe levinud.

5. Inimese infotöötlusvõimed

Tähtsamate nähtustena võib siin nimetada alljärgnevaid.

Inimene filtreerib infot. Ümbruskonnast tulev infovoog on alati suurem, kui inimene suudab läbi töötada. Selle tõttu jäetakse tajuprotsesside abil suur osa infost lihtsalt kõrvale. Inimese teadvusse, töötluse kõrgematele tasanditele jõuab läbi ainult väike hulk ümbruskonnast potentsiaalselt haaratavast infost. Kriisi seisundis filtreerimine tugevneb.



Inimene suudab korraga haarata ja meelde jätta ainult piiratud arvu objekte. Milleri arv – 7 ± 2.

Inimene vajab tagasisidet. Inimene tunneb end kindlamana kui ta saab tegevuse käigus infot tegevuse edukuse kohta.

Inimese rahulolu süsteemiga langeb väga kiiresti kui süsteemi reaktsiooniaeg ületab teatud läve. Inimese töö peab olema sujuv, teatava hooga. Kui töö arvutisüsteemis on seotud ooteaegadega, siis tööprotsessi sujuvus kaob.

6. Individuaalsed erinevused ja nende tähtsus infokäitluse korraldamise jaoks

Inimesed on erinevad – millist tähtsust omab see infosüsteemi arenduse ja haldamise jaoks? Seda küsimust võib käsitleda mitmel tasandil. Tarkvara kasutajaliidese tasandil on individuaalsed erinevused infotöötlusvõimetes ja –eelistustes olnud tähelepanu all juba mitmeid aastakümneid. Hästi projekteeritud kasutajaliides peab võimaldama kasutajatel häälestada kasutajaliidest vastavalt oma individuaalsetele vajadustele või valida süsteemi poolt pakutavatest liidesevariantidest enda jaoks sobivaim. Kuid küsimus on laiem. Individuaalsed erinevused infokäitluses hõlmavad ka eelistusi suhtluskanalite ja suhtlemise vormide (kommunikatsioonivormide) suhtes üldse. Näiteks, teatud kontekstis mõni inimene eelistab infot vahetada suulises vormis, mõni teine aga kirjalikult.

7. Infokäitumine

Võime rääkida inimese infokäitumisest (information behavior). See on koondmõiste, millega püütakse haarata inimkäitumist kõigi in­fo allikate ja kanalite suhtes ning kõigi infokäitlusviiside suhtes. Infokäitumine hõl­mab nii ak­tiiv­set info otsimist, passiivset info vastuvõtmist kui ka in­fo ka­su­tamist; nii näost-näkku (face-to-face) kui ka elektroonilist suht­le­mist; nii massimeedia kui ka infosüsteemide kasutamist. Alama taseme mõis­teteks on infootsimiskäitumine (information search be­hav­ior) ning in­fo­ka­su­tuskäitumine (information use be­hav­ior). Infokäitumise mõiste on pärist infoteaduse (information science) vallast (Wilson 2000).

8. Kognitiivne stiil

Kognitsioon (cognition) on inimese mõtlemine. Kognitiivseks stiiliks (cognitive style) võib nimetada püsivaid individuaalseid eri­ne­vusi ini­meste vahel mit­me­su­gus­tes mõtle­mis- ja suht­le­mis­tege­vus­tes: info töötlemises, probleemide la­hen­­da­mises, mõtlemises, õppmises, suhtlemises. Psüh­ho­loogias on eriti pal­ju uuritud inimeste eelistusi loo­gi­liste ning mitteloogiliste mõt­le­mis­stii­li­de osas. Mõt­lemis- ja suht­lusstiililised erinevused kont­sep­tua­li­see­ri­takse ta­va­liselt vastandlike stiilide paaride kaudu; tuntuim sellistest mõis­te­paa­ri­dest on pa­re­ma ja vasaku ajupoolkera erineva talitluse teooria. Pa­re­ma aju­pool­kera orientatsiooniga inimene väi­de­tavalt eelistab intuitiivset, tund­mu­sest lähtuvat infotöötlus- ja mõtlemisstiili. Vasaku ajupoolkera do­mi­nat­si­oo­ni­ga mõtleja eelistab analüütilist, de­tail­setel loogilistel mõt­tekäikudel põ­hi­nevat prob­lee­mikäsitlust. Suht­le­mi­se vallas avalduvad kog­ni­tiiv­sed stii­li­eri­ne­vused ee­lis­tustes elektroonilise ja näost-näkku suhtumise osas. Ini­me­se kognitiivse stii­li kindlakstegemiseks ka­sutatakse psüh­ho­loo­gi­li­si uu­ri­mis­instrumente; tuntumate seas on Myers-Briggs Type Indicator (MBTI) ja Cog­nitive Style Index (CSI).

Kasutajate kognitiivne stiil on ilmselt üks mit­me­test teguritest, mis mõ­ju­tab infosüsteemi tegelikku ka­su­tamist. Infosüsteemide tegemisel on ka­su­ta­ja­te kog­ni­tiiv­seid erinevusi vähe arvesse võetud; nõuaks see ju ka­su­ta­ja­lii­de­se või isegi süsteemi arhitektuuri ko­han­da­mist mitme erineva ka­su­tus­stii­li jaoks.

Infoülekoormus

(information overload) Olukord, kas infokäitluse si­tu­at­sioonis või ka tä­na­päe­va ühiskonnas laiemalt, kus ini­mene ei suuda sissetuleva või ümbritseva in­fo­mas­si­ga toime tulla.

Infoäng

(information anxiety) Richard Wurman'i poolt eden­da­tud mõiste; inimese ne­ga­tiivsete psühho­loo­gi­liste sei­sundite kompleks, mis on põhjustatud in­fo­ga toi­me­tulemise raskustest. Info paljusus, kiire ja pidev lii­ku­mine, eba­sta­biilsus, kindla toetuspunkti puu­du­mi­ne. Kaht­lused info kasulikkuses jms näh­tused.

9. Süsteemiarenduseks vajalike oskuste küsimus

Erinevused inimeste suundumustes ja võimetes on süsteemiarenduses äärmiselt olulised. Ebasobivate inimestega süsteemiarendust teha on vähe mõtet. Praktika näitab, et on inimesi, kellel on süsteemiloomine „veres”; teistele arenevad süsteemiarenduse saladused alles pikaajalise katsetuste ja eksimuste tee kaudu.

Organisatsioonilises kontekstis kasulikke oskusi liigitatakse sageli kolme klassi:
- tehnilised oskused (technical skills)
- juhtimisoskused (management skills, managerial skills).

Tihti eristatakse ka:
- suhtlemisoskusi (communication skills)
- ärilisi oskusi (business skills).

Juhtimis-, suhtlemis- ja ärioskused on üksteisega tihedalt seotud ja osaliselt kattuvad.

Joang et al (1999) on uurinud süsteemianalüütikute oskuste profiile. Nende uurimisrühm pakub 30 analüütiku uurimise alusel välja inimese orientatsioonide mudeli. Selle mudeli alusel võib süsteemianalüütikuid nende suunitluse järgi liigitada järgmiselt:
- kasutajatele orienteeritud süsteemianalüütik (user orientation). Selline süsteemianalüütik suudab luua konkreetsete inimestega hea kontakti, suudab aru saada nende tööst ja tööst tulenevatest nõuetest infosüsteemile. Näide: analüütik, kes uurib dispetšeri tööprotsessi ja avastab selles uusi, olulisi detaile, mida pealiskaudne analüüs ei näitaks.
- sotsiaal-poliitiliselt orienteeritud süsteemianalüütik (socio-political orientation). Selline süsteemianalüütik suudab hästi tajuda organisatsioonis valitsevaid suhteid, „poliitikat”, mis mõjutavad infosüsteemi väljatöötamist. Näide: IT firma „hea müügimees”, kes suudab taibata, milliste argumentidega saab konkreetsele kliendile projekti müüa.
-tehniliselt orienteeritud süsteemianalüütik (technical orientation). Selline analüütik lähtub põhiliselt tehnoloogia võimalustest ja ehitab ka oma analüüsid ja projektid vastavalt üles. Näide: inimene, kes on tundma õppinud X-tehnoloogiat ja on veendunud, et süsteem tuleb üles ehitada tingimata sellest tehnoloogiast lähtudes.

Süsteemianalüütiku orientatsiooni avaldumisvormiks on inimese suhtumine (attitude) erinevates küsimustes. Joang et al (1999) kasutab arendaja orientatsiooni väljaselgitamiseks loetelu, milles on u. 30 elementi:



Orientatsioone toetavad oskused, mida Joang et al (1999) rühmitavad suhtlemis-, äri-, poliitilisteks ja tehnilisteks oskusteks.



Arendaja orientatsiooni väljaselgitamiseks kasutavad nad u. 20 oskuse loetelu:



Yen et al (2003) uurisid potentsiaalsete tööandjate poolt infosüsteemide spetsialistidele esitatavaid nõudeid ja ootusi. Püüti ka välja selgitada, kas ülikoolides peetakse neid oskusi sama olulisteks.

Uuring näitas, et ülikoolides (õpetamisel) peetakse kõige tähtsamateks oskusteks:
- IT trendide teadmist
- paketttarkvara head valdamist
- isiklikku motivatsiooni ja iseseisva töötamise oskust
- erinevate alade sisulist tundmist ettevõttes (finantsala, turundus, tootmine jne.)
- rakenduste tundmist
- suhtlemisoskusi (suuline, kirjalik)
- kriitilise mõtlemise oskust (sh. analüüsi, hindamist ja mõtlemist).

IS KNOWLEDGE/SKILL SET
—ACADEMIA	LEVEL OF PROFICIENCY REQUIRED	LEVEL OF PROFICIENCY ACHIEVED
IS technological trends	4.47	3.53
Packaged products (spreadsheet, word processing, etc)	4.40	4.27
Personal motivation and working independently	4.33	3.13
Knowledge of specific functional areas (finance, marketing, production, etc.)	4.27	3.40
Application systems	4.20	3.53
Interpersonal communication skills (oral and written)	4.20	3.27
Critical thinking (involve analysis, evaluation and reasoning)	4.07	3.07
Creative thinking (involves synthesis and generation of new ideas)	4.07	3.00
Networking/communication software and languages	4.00	3.60
Systems analysis/design/development methodologies. (Structured programming, CASE methods or tools, etc.)	4.00	3.33
Interpersonal behavior skills (involve organizing, leading, working cooperatively, and planning collaboratively)	4.00	3.13
Programming languages	3.87	3.13
Implementation, operation, and maintenance issue (documentation, etc.)	3.73	3.33
Visions about IS/IT for competitive advantage	3.73	3.07
International communication ability (foreign languages and cultures)	3.67	2.60
Operating systems	3.53	3.13
Knowledge of speci.c organizations (your own company, your host company, etc.)	3.53	2.73
Environment (economic, legal, etc.)	3.47	2.67
Knowledge of speci.c industries (retail, automobile, textile, etc.)	3.40	2.60
Teaching and training skills	3.33	2.87
Hardware	2.87	2.53

Potentsiaalsed tööandjad pidasid seevastu kõige olulisemateks oskusteks:
- kriitilise mõtlemise oskust (sh. analüüsi, hindamist ja mõtlemist)
- loova mõtlemise oskust (sh. lahenduste süntees ja uute ideede leidmine)
- isiklikku motivatsiooni ja iseseisva töötamise oskust
- erinevate alade sisulist tundmist ettevõttes (finantsala, turundus, tootmine jne.)

Esimene infotehnoloogiline oskus on alles viiendal kohal.

IS KNOWLEDGE/SKILL SET
—PRACTITIONERS	LEVEL OF PROFICIENCY REQUIRED	LEVEL OF PROFICIENCY ACHIEVED
Critical thinking (involve analysis, evaluation and reasoning)	4.13	3.97
Creative thinking (involves synthesis and generation of new ideas)	4.05	3.91
Personal motivation and working independently	4.04	4.13
Knowledge of speci.c functional areas (.nance, marketing, production, etc.)	3.97	3.82
IS technological trends	3.97	3.78
Application systems	3.67	3.69
Visions about IS/IT for competitive advantage	3.63	3.59
Interpersonal behavior skills (involve organizing, leading, working cooperatively, and planning collaboratively)	3.62	3.59
Interpersonal communication skills (oral and written)	3.62	3.54
Operating systems	3.48	3.46
Packaged products (spreadsheet, word processing, etc.)	3.32	3.49
Programming languages	3.31	3.51
Networking/communication software and languages	3.21	2.99
Implementation, operation and maintenance issues (documentation, etc.)	3.15	3.37
Hardware	3.15	3.24
Knowledge of specific organizations (your own company, your host company, etc.)	3.14	3.21
Teaching and training skills	3.13	3.24
International communication ability (foreign languages and cultures)	3.01	3.03
Systems analysis/design/development methodologies (structured programming, CASE methods or tools, etc.)	2.95	3.15
Knowledge of specific industries (retail, automobile, textile, etc.)	2.71	2.83
Environment (economic, legal, etc.)	2.46	2.54

10. Süsteemi energia. Mis paneb süsteemid käima?

Selle küsimuse juurde võib jõuda mitmeti.
° Süsteemi tehakse, kuid süsteem ei taha käivituda.
Süsteemi tegemine.Eesmärgiks on teha süsteem. Üldjoontes teame, mida tuleb teha, millised protseduurid ja andmestruktuurid on vaja luua jne. Kuid—kas süsteem hakkab tööle? Kui hakkab, siis kui hästi? Süsteemi analüüsi ja süsteemi disainimise meetodite kasutamine ei anna garantiid. Süsteemi analüüsi ja disaini tulemiteks on tulevase süsteemi mudelid, ühes või teises vormis. Kuid hästitoimiv süsteem on vahest midagi enamat kui komponentide arhitektuurne kogum? Oleme kogenud, et tehakse süsteemi, kõiki häid reegleid järgides, kuid terviklik tulemus lihtsalt ei õnnestu.
° Süsteem „käib maha”, „jookseb energiast tühjaks”.
Süsteemi olukorra hindamine. Süsteem on juba pikemat aega kasutusel, mingist perioodist on hakanud nii-öelda "maha käima". Süsteemi osad on alles, kuid energia on asendunud loidusega. Halvemal juhul võib piltlikult öelda, et süsteem jookseb aegamööda energiast tühjaks. Asi toimis, aga nüüd mingil põhjusel ei toimi enam nii hästi.
Mis on neis kahes situatsioonis ühist? Täppisteaduslikust vaatenurgast ei ole võib-olla korrektne öelda, et hästitoimivas süsteemis on teatud kogus "sisemist energiat"—energiat, mida halvasti töötavas või lagunevas süsteemis napib.
Praktilisest seisukohast on aga selline—energeetiline—vaatenurk õigustatud. Ettevõtetes räägitakse palju motivatsioonist. Inimese nn. motivatsioon (kuid – mis motivatsioon tegelikult on?) on kindlasti üks süsteemse energia liike. Kuid kas ainus? Moodne teadus, ei oma loodusteaduslikus ega humanitaarses harus, ei oska sellele küsimusele ammendavalt vastata. Kogu inimkultuuri ajalugu huvitaval kombel näitab, et inimeste mõtted on pidevalt liikunud selles suunas, et peab olema mingi otseselt nähtamatu, kuid siiski reaalne, sisemine liikumapanev energia. Seda liikumapanevat energiat on nimetatud erinevatel viisidel: ladina keeles vis vitalis – elujõud; india muistses filosoofias – „prana”; hiinas filosoofias – „chi”; jaapani kultuuris – „ki”; havai ja polüneesia kultuurides – „mana”.

Süsteemiarenduse jaoks võime sellest teha mitu tähtsat järeldust.
° Kõigepealt peaks arvestama seda, et praktiliselt igasuguse süsteemi käigushoidmiseks on vaja energiat ; süsteem võib ise genereerida energiat; või, energia võib süsteemi tulla pidevalt mingi voo kaudu väljaspoolt. Kuid energia oluline kadu on süsteemile kindlasti kui mitte surmaotsus, siis efektiivsust vähendav.
° Süsteemi tehes tuleks mõelda, kas piisab ainult komponentide valmistamisest ja siis asja kokkupanemisest, või on vaja ka süsteem "käima joosta", "hing sisse puhuda". Tulevad meelde vanad traditsioonid laeva vettelaskmisel (kotermann) jm. Sissepühitsemise rituaal--tehnilisest vaatepunktist—omab ainult sümboolset väärtust. Aga mis see infosüsteem on, kui mitte sümbolite loomise ja töötlemise tööriist?
° Energia peaks juba süsteemi sisse projekteerima. Mitte ei tuleks püüda elustada surnult sündinud süsteemi. Ega üritada kiirkorras üles puhuda, energetiseerida, uimaselt väljakukkunud süsteemi.

Järeldused süsteemide käitamise, olukorra hindamise ja hooldamise jaoks:
° Süsteemi olukorra hindamine ei tohiks piirduda komponentide ja struktuuride seisundi uurimisega (ei tohiks sellest alustada). Alustada tuleks süs­teemi kui terviku energiataseme, energeetilise potentsiaali väljaselgitamisest.
° Süsteem, mis on energeetiliselt tühi, tuleb uuesti laadida. Kui see ei ole võimalik, siis on mõttekam süsteem koost lahti võtta ja komponente mujal kasutada.

Kuidas sellist süsteemi sisemist energiat luua, kuidas seda süsteemi sisse panna, on muidugi omaette küsimus.

11. Organisatsiooni ja üksikisiku energiatase kui süsteemide arenduse vältimatu eeldus

Juhtimisalases kirjanduses on viimasel ajal ilmunud mitu huvitavat käsitlust organisatsiooni energiataseme kohta (organizational energy) (Bruch & Ghoshal, 2003; Cross et al, 2003). Siin peetakse silmas organisatsiooni kui sotsiaalse süsteemi vaimset energiat. Tihti kasutatakse sama asja väljendamiseks terminit „motivatsioon”. Organisatsiooni energeetilisus omab süsteemiarenduse jaoks otsest tähtsust. Süsteeme saab luua ainult organisatsioonis piisava motivatsiooni (energiataseme) korral. Bruch ja Ghoshal liigitavad organisatsiooni energiataset neja klassi:

- kõrge positiivne energiatase – passionaarne organisatsioon
- kõrge negatiivne energiatase – agressiivne organisatsioon
- nõrk positiivne energiatase – rahulolev organisatsioon
- nõrk negatiivne energiatase – resigneerunud organisatsioon.

Probleemid/harjutused

Hinda oma süsteemiarendusoskusi ja -orientatsiooni Joang et al (1999) meetodi abil.

Kirjandus

Benbasat, I., Taylor, R. 1982. Behavioral Aspects of Information Processing for the Design of Management Information Systems. IEEE Trans. Syst. Man Cybernetics, 4, 439-450.

Bruch, H., Ghoshal, S. (2003) Unleashing Organizational Energy. MIT Sloan Management Review, 45, 1, 45-51.

Cross, R., Baker, W., Parker, A. (2003) What Creates Energy in Organizations? MIT Sloan Management Review, 44, 4, 51-56.

Davis, G., Olson, M. (1985) Humans as Information Processors. in: Management Information Systems: Conceptual Foundations, Structure and Development, McGraw-Hill, 235-268.

Hirschheim, R., Klein, H. (1989) Four paradigms of infor­mation systems development. Comm­unications of the ACM, 12, 1199-1216.

Kirsh, D. (2000) A Few Thoughts on Cognitive Overload. http://philpapers.org/archive/KIRAFT.pdf.

McKenney, J., Keen, P. (1974) How managers' minds work. Harvard Business Review, 52, 3, 79-90.

Taylor, W. (2004) Computer-mediated knowledge sharing and individual user dif­fe­ren­ces: an exploratory study. European Jour­n­al of Information Systems, 13, 52-64.

Wilson, T. (2000) Human Information Behavior. Informing Science, 3, 2, 49-55.

Joang, J., Klein, G., Means, T. (1999) The missing link between systems analysts' actions and skills. Information Systems Journal, 9, 21-33.

Yen, D., Chen, H-G., Koh, S. (2003) Differences in perception of IS knowledge and skills between academia and industry: findings from Taiwan. International Journal of Information Management, 23, 507-522.

IFI6068 ◦ Sissejuhatus infosüsteemidesse ◦ Sügissemester 2014

ÜLESANNE 11 | Nõuete dokumendi koostamine

Valitud arendusidee ja eelmistes iseseisvates töödes teostatud modelleerimiste ja analüüside alusel palun koostage dokument, mis fikseerib nõuded loodavale infosüsteemile sellise täpsusega, et seda dokumenti ("Nõuded loodavale süsteemile") saaks välja saata IT arendusfirmadele pakkumuste tegemiseks. (Märkus. Eesti praktikas kasutatakse nõuete dokumendi asemel tihti ka mõistet "lähteülesanne".)

Üksikasjalikumad seletused praktikumis.

Töörühm: sama, mis eelmistes iseseisvates töödes.

Esitamise tähtaeg: üks nädal alates ülesande andmisest.

PRAKTIKUM 12 | Nõuete dokumendi koostamine

Ülesanne 10 Kontseptuaalse mudeli koostamine: lahenduste läbivaatamine

Ülesanne 11 Nõuete dokumendi koostamine

PRAKTIKUM 11 | Kontseptuaalne modelleerimine

Ülesande 9 Infosüsteemi prototüüpimine | Läbivaatus

Ülesanne 10 Kontseptuaalne modelleerimine

Kontseptuaalse modelleerimise rakendusala

Kontseptuaalne modelleerimine on rakendatav igasugusele reaalsuse osale. Küsimus on ainult modelleerimise eesmärgis (milleks mudelit kasutatakse).

Kui Arno isaga koolimajja jõudis, olid tunnid juba alanud. Kooliõpetaja kutsus mõlemad oma tuppa, kõneles nendega natuke aega, käskis Arnol olla hoolas ja korralik ja seadis ta siis pinki ühe pikkade juustega poisi kõrvale istuma. Siis andis kooliõpetaja talle raamatust midagi kirjutada, ja Arnol ei olnud nüüd enam aega muule mõtelda. Ta võttis tahvli ja hakkas kirjutama. — O.Luts, Kevade

Kui Arno isaga koolimajja jõudis, olid tunnid juba alanud. Kooliõpetaja kutsus mõlemad oma tuppa, kõneles nendega natuke aega, käskis Arnol olla hoolas ja korralik ja seadis ta siis pinki ühe pikkade juustega poisi kõrvale istuma. Siis andis kooliõpetaja talle raamatust midagi kirjutada, ja Arnol ei olnud nüüd enam aega muule mõtelda. Ta võttis tahvli ja hakkas kirjutama.

OBJEKTID?             SEOSED?                 ATRIBUUDID?

--------       ------      ----------

Arno                          algama                     natuke aega

isa                              kutsuma                  hoolas

koolimaja                  kõnelema                 korralik

tund                           käskima                   pikk

kooliõpetaja              seadma                    kõrvale

tuba                           istuma

pink                           andma

juuksed                      kirjutama

poiss                          mõelda

raamat                      võtma

aeg                             hakkama

tahvel

 

IFI6068 ◦ Sissejuhatus infosüsteemidesse ◦ Sügissemester 2014

ÜLESANNE 10 | Kontseptuaalse mudeli koostamine

Lähtudes infosüsteemi ideest, koostage esialgne kontseptuaalne mudel.

Selgitused. Koostatav kontseptuaalne mudel on mõeldud väljatöötamisele mineva süsteemi peamiste infoobjektide koosseisu, struktuuri ja omavaheliste seoste väljaselgitamiseks.

Aluseks võib võtta süsteemiidee, millega töötati eelmistes ülesannetes või ka mõne muu idee. Kummalgi juhul peaks olema selge süsteemi põhimõtteskeem ja/või kasutajate peamised infovajadused.

Nõuded. Vormistus: Diagramm + tekstilised kommentaarid (need ei pea olema detailsed, vaid pigem ettevalmistuseks töö ettekandmisele).

Töörühm: sama, mis protsessi modelleerimise ülesannetes.

Esitamise tähtaeg: üks nädal alates ülesande andmisest.

Kontseptuaalse mudeli roll.

Kontseptuaalse mudeli koostamine on iteratiivne protsess. Valmistatakse esimene versioon, uuritakse ja hinnatakse selle täielikkust ja tegelikkusele vastavust, viiakse sisse parandused ja täiendused. Seda tegevust jätkatakse niikaua, kuni saavutatakse kontseptuaalse mudeli nõutav stabiilsus. Stabiilne mudel on selline, mille hoolikas läbivaatus ei too enam välja vajadust mudelit täiendada.

Kontseptuaalse mudeli koostamine paigutub infosüsteemi elutsüklis peaaegu päris algusesse. Alustatakse süsteemi idee tõstatamisest ja/või tulevaste kasutajate vajaduste fikseerimisest vägagi üldisel tasandil. Süsteemiarenduse lähtepunktiks on tavaliselt süsteemi funktsionaalsus (mida süsteem peab võimaldama automatiseerida või infotehnoloogia abil toetada).

Näiteks, külmutusseadmete hooldusteenuse infosüsteemi funktsionaalsust võime kõige esimeses lähenduses sõnastada 4-5 funktsiooni loeteluna:

Külmutusseadmete hoolduse infosüsteemi funktsioonid

FUNKTSIOON 1. Hoolduslepingute registreerimine ja haldus

FUNKTSIOON 2. Väljakutsete registreerimine

FUNKTSIOON 3. Hooldustöö plaanimine

FUNKTSIOON 4. Hooldustöö (tulemuste) registreerimine

FUNKTSIOON 5. Arvete koostamine.

Infosüsteemis hoitavate andmete koosseisu ja struktuuri küsimus on väga tähtis. Süsteemi funktsionaalsuse ja andmete koosseisu artikuleerimine peavad praktikas enamasti käima käsikäes. Selle tõttu on enamasti vaja luua juba süsteemiarenduse alguses esialgne, suhteliselt kõrge abstraktsioonitaseme kirjeldus (ülevaade) süsteemis hoidmisele tulevatest andmetest (infost). Seda vajadust täidab kontseptuaalne mudel– ülevaatlik, struktuurne kirjeldus infosüsteemi andmete kohta. Kontseptuaalne mudel koostatakse harilikult süsteemi eeluuringu etapis või hiljemalt süsteemi analüüsi alguses.

Kontseptuaalse mudeli koostamise käigus süsteemi funktsionaalsus harilikult täieneb.

Näiteks, külmutusseadmete hoolduse infosüsteemi infomudeli (ehk kontseptuaalse mudeli) koostamisel võib selguda vajadus lisada süsteemi funktsioonide loetellu täiendav funktsioon:

FUNKTSIOON 6. Hooldusmaterjalide haldus

Sageli tehakse infosüsteem valitud tegevusala täielikult katvana. See tähendab, et süsteem realiseerib või toetab mingi „reaalsuse ala” toimimist täies ulatuses. Selle tõttu lähtub kontseptuaalne modelleerimine sageli mitte süsteemi, vaid teatud viisil piiritletud „reaalsuse ala” mõistest – koostatakse mitte süsteemi, vaid reaalsuse tüki mudel.

Lihtne samm-sammuline kontseptuaalse modelleerimise meetod.

1. Koosta loetelu peamistest süsteemis hoidmisele tulevatest infoobjektidest. Heaks praktiliseks võtteks on võtta süsteemi eesmärkide kirjeldus või funktsioonide loetelu ning leida sellest nimisõnad – need näitavad sageli peamisi infoobjekte.

Näiteks, külmutusseadmete hoolduse kontseptuaalse mudeli infoobjektide kandidaatideks võivad olla:

klient

hooldusleping

külmutusseade (hooldusobjekt)

väljakutse

hooldustöö

töötaja

materjal

arve.

2. Leia infoobjektide peamised atribuudid (ehk andmeväljad, andmeelemendid, omadused). Infoobjektil võib olla 5-10-20 – kuni paarsada atribuuti, Näiteks raamatukogudes kasutatavates bibliograafilistes infosüsteemides on trükise (säilitusüksuse) kirjeldamiseks kasutada üle 200 andmevälja (atribuudi). Atribuute ei ole harilikult võimalik ühe modelleerimissammuga täielikult leida. Mudeli täiendamine jätkub tavaliselt küllaltki pika aja vältel.

3. Leia infoobjektide vahelised seosed. Oluline on seose tüüp. Praktikas on välja kujunenud tüüpide eristus: üks-ühene seos, üks-mitmele seos, mitu-mitmele seos. See tüpoloogia on oluline selle tõttu, et tüübi varajane määratlemine aitab kindlamini jõuda andmete lõpliku esituse struktuurini, kui andmete hoidmiseks kasutatakse relatsioonilist andmebaasi. Samas tuleb rõhutada, et kontseptuaalne mudel põhimõtteliselt ei sõltu andmete esituse konkreetsest viisist (relatsiooniline andmebaas, objekt-orienteeritud esitus, andmete esitus kaustade ja failide abil jm.). Kontseptuaalne mudel on kasulik abstraktne esitus nii suhteliselt traditsiooniliste, andmebaasipõhiste töötlussüsteemide kui ka disainile orienteeritud veebisüsteemide puhul.

4. Hinnata mudeli loogilisust ja tegelikkusele (reaalsele või kujutletavale) vastavust. Oluline on ka mudeli detailsusaste sobivus. Hinnata, kas mudel on piisavalt üksikasjalik (või piisavalt üldistatud).

5. Vajadusel korrata eelmisi samme.

Kontseptuaalse mudeli vormistamine.

Kontseptuaalne mudel esitatakse traditsiooniliselt diagrammina (skeemina). Nagu diagrammide juures ikka, on diagrammi mõistetavaks tegemiseks harilikult vaja lisada teksti vormis selgitusi.

Põhimõtted ja võtted. Kontseptuaalsel modelleerimisel on kasulik teada mõningaid praktilisi (heuristilisi) põhimõtteid ja võtteid.

Piiri tõmbamine süsteemi ja süsteemi ümbruse vahele. Iga vähegi ulatuslikuma reaalsuse osa põhjalik infoloogiline kirjeldamine toob välja palju infoobjekte. Oluline on osata tõmmata piir süsteemi ja „mitte-süsteemi” (süsteemist välja jäetava) vahele.

Nimede valik. Väga oluline on nimetuste (terminite) valik. Kontseptuaalne mudel peab kajastama organisatsioonis tegelikult toimuvat (reaalsust). See tähendab ka samade nimetuste (sama keele) kasutamist, mida kasutavad organisatsiooni töötajad igapäevases suhtlemises. Tegelikud terminid ja nende sisu tuleb süsteemi analüüsi käigus välja selgitada. Süsteem, mis ei kõnele kasutajatega samas keeles, omab eduks vähe väljavaateid.

Näiteks, kuidas nimetatakse külmutusseadmete hoolduse ettevõttes hooldustöö teostamist? Kas on kasutusel „väljakutse”, „ülesanne”, „töö” või mõni teine nimetus?

Süsteemiarendus tähendab ka organisatsiooni tööprotsesside täpsustamist ja arendamist. Kui kindlaid termineid ei ole praktikas välja kujunenud, siis infosüsteemi täpsuse kaalutlustel tuleb terminid kehtestada. Seda peab süsteemi arendaja tegema ainult koostöös süsteemi kasutajatega. (Süsteemi arendaja ei tohi kasutajatele ette kirjutada, milliseid termineid kasutada).

Objektide ühendamine. Kontseptuaalne mudel peab olema ökonoomne. See tähendab, et loodud esitusel peab olema võimalikult suur kirjeldusjõud. Väheinformeeritud tellijad arvavad vahel ekslikult, et suurem mudel on parem, sest „sisaldab rohkem tööd”. Tegelikult on vastupidi – eesmärgiks on just väikese, kompaktse mudeli loomine. Samas ei tohi teha järeleandmisi kirjelduse täielikkusele ja detailsusele. Suur, laialivalguv kontseptuaalne mudel on halvasti või mittepõhjalikult tehtud analüüsitöö tundemärk. Suur ja ebaefektiivne infomudel võib süsteemi realiseerimise nurjata.

Selle tõttu tuleb alati tähele panna võimalusi infoobjektide ühendamiseks.

Näiteks, külmutusseadmete hoolduse kontseptuaalses mudelis ei ole võib-olla otstarbekas luua eraldi infoobjekte „Dispetšer” ja „Remonditööline”, vaid nende asemel üldisem infoobjekt „Töötaja”, milles töötaja ametikoht või roll kirjeldatakse atribuudi (andmevälja) „Ametikoht” abil.

Näide.

Soome "kodanikukonto" projekti kontseptuaalse mudeli
esimene versioon (alustava tietomalli).
Allikas: Arkkitehtuurikuvaus.

LOENG 11 | ANDMETE (INFO) ROLL INFOSÜSTEEMIS

Eesmärk

Andmestruktuuride projekteerimise küsimus infosüsteemi tasandil on väga oluline ja mahukas. Informaatika osakonnas on pühendatud sellele eraldi kursus, IFI 6013 Andmebaaside projekteerimine. Käesolevas loengus vaatleme infosüsteemi andmete küsimusi peamiste mõistete ja põhimõtete tasandil, arvestades kuulajatega, kes ülalnimetatud kursust ei ole läbinud või ei läbi. Infosüsteemide arendusega tihedamalt kokkupuutuval inimesel on andmebaaside projekteerimise kursus praktiliselt vajalik.

Sisukord

Töötlus ja andmed
Andmebaas – infosüsteemi süda
Projekteerimine tulevikku arvestades
Andmete tsentraliseerimine
Andmebaas
Mitmekihilised süsteemid
Andmemudel
Kontseptuaalne modelleerimine
Olem, atribuut, seos
Notatsioonid
Andmebaasi projekteerimine
SQL keel
Andmebaasi projekteerimine või infoarhitektuur?
Probleemid/harjutused
Kirjandus

1. Töötlus ja andmed

Töötlus (processing) ja andmed (data) on igasuguse infotöötluse kaks peamist, teineteisega lahutamatult seotud külge. kumb on tähtsam? eraldiseisva programmi kirjutamisel on töötlus sageli olulisem kui andmestruktuurid. programmeerimisel läheb põhiline osa tööst sageli andmeid teisendavate lausete ehk töötlusalgoritmi formuleerimisele. andmestruktuurid luuakse ja täiendatakse algoritmi väljatöötamise käigus. kuid selline suhe ei kehti kõigi programmeerimisülesannete juures. mõnikord on otstarbeka andmestruktuuri leidmine küllaltki raske, näiteks siis, kui andmete maht võib kujuneda suureks ning selle tõttu on vaja lahendada andmestruktuurile kiire juurdepääsu küsimus. samuti võib andmestruktuuri projekteerimine olla raskendatud kui andmete koosseis on dünaamiline (kiirelt muutuv või suure muutuste diapasooniga).

Infosüsteemi tasandil on töötluse ja andmete proportsioon sageli vastupidine. info­süsteemis on andmestruktuurid (infostruktuurid) sageli ”tähtsamad” ja töömahukamad kui nende andmete töötlusoperatsioonid.

Miks? peamine põhjus on tänapäeva infosüsteemidesse hõivatavate andmete suur maht ja keerukus.

Näiteks, väikese kaupluse kaubanomenklatuur võib koosneda tuhandetest ühikutest, mis kuuluvad sadadesse või tuhandetesse erinevatesse tüüpidesse. võimalik on ka see, et iga kaubaartikkel on unikaalne. kõik need erinevad kaubad tuleb kaupluse müügi- või laosüsteemis adekvaatselt registreerida. kaupadega tehtavaid operatsioone on aga suhteliselt väike arv, tõenäoliselt paarikümne ringis:

uue kaubatüübi kasutuselevõtmine

kauba lattu sissevõtmine

kauba müük

kauba tagastamine

kauba mahakandmine

valesti arvelevõetud kauba andmete korrigeerimine

kaubatüübi nimekirjast kustutamine

päringute tegemine laoseisude kohta

päringute tegemine müügi kohta

päringute tegemine lattu sissevõtmise kohta

jt.

2. Andmebaas – infosüsteemi süda

Väga oluliseks nähtuseks on andmetüüpide tavaliselt suhteliselt suurem stabiilsus tööt­lusoperatsioonide tüüpidega võrreldes. Lihtsustatult öeldes – andmete struktuur on ena­­masti stabiilsem (muutub harvemini) kui andmeid töötlevad programmid.

Näiteks, ehitusfirma võib kasvada ja arendada oma tööprotsesse, lisada oma info­süs­tee­mi uusi võimalusi. Kuid ehitusmaterjalide kirjeldamine ettevõtte infosüsteemis ei tarvitse nendest muudatustest mõjutatud olla. Kaubandusettevõte võib laieneda ühest müügikohast mitme müügikohaga ettevõtteks või isegi kaupluste ketiks. Kuid kauba­artikleid kirjeldavad andmestruktuurid ettevõtte infosüsteemis ei tarvitse sellest muu­tu­da.

See põhimõte on infosüsteemi väljatöötamisel väga oluline. Infosüsteemi projek­tee­ri­mi­sel tuleb andme- (info-)struktuuridele pöörata väga tõsist tähelepanu. Hästi projek­teeritud andmestruktuurid on süsteemi õnnestumisel üheks peamiseks teguriks. Püüel­da tuleb stabiilse, tervikliku, hästi kasutatava, multifunktsionaalse andmestruktuuride kogumi (andmebaasi) poole.

Andmestruktuuri stabiilsus tähendab seda, et kirjeldatava objekti praktiliselt kõik olu­lised omadused (atribuudid) ja olulised seosed teiste objektidega on süsteemi pro­jek­tee­rimisel üles leitud, õigesti mõistetud ja andmestruktuuride kirjeldamise vahendite abil modelleeritud. Näide: Millised atribuudid on müügioperatsioonil? Müüdava kauba ni­me­tus, müügi kuupäev – kas nendest piisab? Oluliste atribuutide kooslus sõltub kaup­luse tööprotsessist, praktikast. Süsteemi analüüsi ülesanne on olulised atribuudid välja selgitada. Tihti esineb müügioperatsioonide juures erisusi. Näiteks, kaup võis olla vea­ga ja seda tuli kas kohapeal või hiljem parandada; või tehti allahindlust. Asju ”üldiselt” vaadates võib tegevus tunduda lihtne ja oluliste atribuutide hulk selge; kuid praktika on alati keerulisem.

Miks on andmestruktuuride stabiilsus oluline? Andmestruktuuri muutus juba töötavas süsteemis võib olla väga kulukas, seda nii programmide ümbertegemise kui ka andme­te konverteerimise tõttu.

Andmestruktuuri terviklikkus (katvus) tähendab seda, et kõik olulised objektid on kir­jel­datud (modelleeritud).

Andmestruktuuri kompaktsus on samuti väga oluline. Infosüsteemis hoitavatele and­me­tele tuleb leida selge, nn. normaliseeritud (minimaalsetele osastruktuuridele viidud) esitus. Näiteks, kinnisvara andmebaasis võib olla oluline paljude spetsia­li­see­ritud atri­buu­tide kasutusele võtmine, et kergendada kinnisvaraobjektide otsimist mitmete oma­duste järgi.

Andmestruktuuri multifunktsionaalsuse all peame silmas seda, et objekti kirjeldus peab võimaldama objektiga teha kõiki reaalselt võimalikke operatsioone. Näiteks, kauplus võib jamüügi kõrval hakata tegelema ka hulgimüügiga (kaupade müügiga teistele kaup­lustele). Sellest tulenevad ilmselt muudatused kaupluse infosüsteemis – lisatakse hulgimüügi funktsionaalsus. Hästi projekteeritud andmebaasi korral saame hulgi­müü­gi funktsionaalsuse lisada ilma andmestruktuure oluliselt ümber tegemata. (Jae- ja hulgimüük on ju paljuski sarnased).

3. Projekteerimine tulevikku arvestades

Hästi projekteeritud andmestruktuurides on andmete võimalikke kasutusi ka tulevikus ette nähtud . Andmestruktuure tuleb projekteerida mitte kitsalt, ainult hetkel teadaoleva funktsionaalsuse (programmidega realiseeritava töötluse) jaoks, vaid laiemalt, võttes võimaluse korral arvesse kõiki tulevikus võimalikke kasutusi. Miks? – Sest enamasti on kokkuvõttes odavam teha alguses rohkem tööd ja vältida hilisemaid muudatusi andmestruktuurides.

4. Andmete tsentraliseerimine

Üldiseks põhimõtteks on ühe andmeüksuse hoidmine ainult ühes kohas. Teiste sõna­de­ga, andmete dubleerimist tuleb üldjuhul vältida.

Ebaefektiivne – andmed on mitmes eksemplaris ja vajavad koordineerimist:



Efektiivne – andmed on ühes eksemplaris:

5. Andmebaas

Andmete tsentraliseerimise põhimõte (dubleerimise kõrvaldamine, koondamine füüsiliselt ühte kohta) leiab kõige täielikuma väljenduse andmebaasis. Andmebaasiks võib praktikas nimetada ka üldse igasugust terviklikku, süstematiseeritud andmekogumit, eelkõige aga siiski spetsiaalse tarkvara – andmebaasitarkvara (DBMS Data Base Management System) abil hoitavat ja hallatavat andmekogumit. Väga sageli on infosüsteemis andmete peamiseks paigutuskohaks üks, tsentraalne andmebaas, mille and­metele kasutajad pääsevad ligi rakendusprogrammide ja klienditarkvara (klient s.o. andmebaasi peale ehitatud tarkvararakenduse poolt teenindatav kasutaja) abil. Suuremates süsteemides võib olla kasutusel mitu andmebaasi. Tihti ka veebisüsteemides, mis kasutaja vaatepunktist võivad näida lihtsa veebilehtede kogumina, on kasutusel andmebaas. Sellisel juhul veebilehti valmiskujul ei säilitata, vaid genereeritakse andmebaasis olevate andmete põhjal, vastavalt kasutajate pöördumisele veebisüsteemi poole (dünaamilised veebilehed). Andmete koondamine andmebaasi on infokäitluse tõhustamisel üks levinumaid strateegiaid.

6. Mitmekihilised süsteemid

Andmete vahetu töötlemise operatsioonid – andmete salvestamine, otsimine, reorganiseerimine, kustutamine, varundamine (varukoopiate tegemine), juurdepääsuõiguste haldus (andmete turvalisus) – on infosüsteemis sageli niivõrd töömahukad, et nende sooritamiseks eraldatakse eraldi serverarvuti (andmebaasiserver, database server). Rakendused (infosüsteemi funktsionaalsuse põhiosa ehk nn. äriloogikat (business log­ic) realiseerivad programmid) paigutatakse siis teise, rakenduste serverisse (app­lica­tion server). Kasutajad pöörduvad tänapäeval rakenduste poole üha rohkem veebilehitsejate vahendusel. Nii kujuneb süsteemi kolmekihiline ülesehitus (arhitektuur):



Süsteemide mitmekihiline ülesehitus on tähtis keerukuse vähendamise meetod; seda kasutatakse programmeerimises ja süsteemiarenduses laialdaselt.

7. Andmemudel

Andmemudel (data model) määratleb selle, kuidas valitud objektide hulka kirjeldama hakatakse. Teisiti öeldes, andmemudeliga määratakse milliseid andmeid süsteemis hakatakse hoidma.

Andmemudelite esitamiseks on võimalik kasutada rida tähistussüsteeme (formalisme). Nende seas on nii lihtsamaid kui ka keerukamaid.

Andmebaasi minevate andmete koosseis tuleb välja selgitada enne programmide kirjutamise alustamist . Stabiilne andmebaasi andmete nomenklatuur (infosüsteemi andmemudel) on tõhusa programmeerimistöö seisukohalt äärmiselt oluline. Andmebaasi struktuuri projekteerimine on süsteemiarenduse protsessis omaette tööetapp, õigemine protsess, mis käib süsteemi funktsionaalse ulatuse projekteerimisega käsikäes. Andmebaasi projekteerimine on oskust ja kogemust nõudev töö.

Sõltuvalt süsteemist võib andmemudeli maht kujuneda küllatki suureks. Andmebaasis võib olla 50-100 või rohkemgi andmetabelit, igas tabelist kümneid andmeelemente (atribuute). See tingib vajaduse andmete modelleerimist läbi viia mitmes etapis, koostades mitu erineva taseme andmemudelit.

8. Kontseptuaalne modelleerimine

Kõige kõrgema taseme andmemudelit (see tehakse kõige esimesena) nimetatakse sageli kontseptuaalseks mudeliks (conceptual model).

Kontseptuaalse andmemudeli väljatöötamise protsessi nimetatakse vastavalt kontseptuaalseks modelleerimiseks (conceptual modeling). Lähedased, kuid mitte tingimata samamahulised terminid on andmete modelleerimine (data modeling) ja infoloogiline modelleerimine (infological modeling).

Kontseptuaalset andmemudelit iseloomustab:

° kõrge abstratsioonitase

° sõltumatus konkreetsest andme­baasisüsteemist

° tähelepanu andmete omadustel, mitte sellel, kuidas neid salvestada

° lihtsamini mõistetav kui tehniline andmebaasimudel

° kasutatav kasutajatega suhtlemisel.

Kontseptuaalne modelleerimine soovitatakse teostada sõltumata sellest, kuidas ja milliste vahenditega (ühe või teise andmebaasisüsteemiga või hoopis failidega) andmete hoidmise vajadus lahendatakse. See võimaldab keskenduda andmete olemusele. Paremini mõistetud ja artikuleeritud andmete olemus annab stabiilsema andmete struktuuri.

Kontseptuaalne modelleerimine paigutub infosüsteemiarenduse elutsüklis süsteemi eeluuringu ja süsteemi analüüsi etappide lähedusse.

Mõned eksperdid soovitavad alustada süsteemi funktsionaalsuse (tegevuste, protsesside) väljaselgitamisest põhijoontes ja selle järel asuda kontseptuaalse modelleerimise juur­de. Teised autorid rõhutavad fuktsionaalsuse ja andmete võrdset tähtsust ning soo­vitavad funktsionaalset modelleerimist ja kontseptuaalset modelleerimist läbi viia paralleelselt. See tähendab, et esialgne, abstraktne, ”suure pildi” andmemudel tehakse juba koos süsteemi esimese protsessimudeliga.

Kasutaja nõudmisi ehk vajadusi (User Requirements või Needs) sellise metoodika korral jagada kaheks:

° Nõudmised andmetele (Data Requirements)

° Funktsionaalsed nõudmised (Functional Requirements).

Kontseptuaalse modelleerimise selline rõhutamine aitab tagada, et kasutajate andmevajadused on arvesse võetud ning need va­ja­dused pole omavahel konfliktis.

Näide. Andmemudeli fragment (valmistatud Oracle modelleerimisvahendi abil). Kirjel­datud on kaks objekti (Klient, Müük), nende objektide atribuudid (kirjeldavad tunnused) ja objektivaheline loogiline seos.



Näide. Tekstina (mitte diagrammina) esitatud kontseptuaalne mudel (fragment):



° Firma koosneb osakondadest. Igal osakonnal on nimi, koodnumber ning juhataja. Osakond võib paikneda mitmes asukohas.

° Osakond juhib teatud hulka projekte. Projektil on nimi ja number. Projekti tehakse ühes asukohas.

° Töötaja kohta tuleb salvestada nimi, isikukood, aadress, palk, sugu ja sünnikuupäev. Töötaja kuulub ühte osakonda, kuid võib töötada ka teiste osakondade projektides. Registreerime töötaja poolt igas projektis töötatud tundide arvu nädalas. Töötajal on ka ülemus.

° Töötajal võib olla ülalpeetavaid. Ülalpeetava kohta registreeritakse: nimi, sugu, sünnikuupäev ning suhe töötajaga.

9. Olem, atribuut, seos

Kontseptuaalse mudeli peamisteks elementideks on olemid, atribuudid ja seoses.

Olemiks (entity) võib olla põhimõtteliselt mistahes objekt. Eristada võib:

° füüsilise iseloomuga objekte, nt. isik, auto, maja, töötaja, ...

° kontseptuaalse iseloomuga objekte, nt. ettevõte, töökoht, ülikool.

Tuleb eristada olemitüüpi (entity type) ja konkreetseid olemeid.

Atribuut (attribute) on olemit kirjeldav omadus. Konkreetse olemi atribuutidel on väär­tused (value). Atribuudi võimalike väärtuse hulka nimetatakse domeeniks (do­main of values). Atribuute liigitatakse: liht- ja liitatribuudid (simple, composite); ühe- ja mitmeväärtuselised (single-valued, multivalued); salvestatud ning tuletatud atribuu­did (stored, derived).

Null value — tarvitatakse tähendustes: - pole rakendatav (n/a); - pole teada, puudub.

Võti (key) — üks või mitu atribuuti, mille väärtus(ed) üheselt identifitseerivad konk­reetse olemi.

Seos (suhe) (relationship) on kindla tähendusega seos kahe olemitüübi vahel.

Näide. Seotud on ühelt poolt olemid Töötaja ja Töötamine, teiselt poolt Osakond ja Töötamine. Näidatud on seosed konkreetsete (üksikute) modelleeritavate objektide vahel.

10. Notatsioonid

Kontseptuaalsetes mudelites on levinud mitmed seoste tähistamise viisid:

° Peter Chen'i Entity-Relationship

° Information Engineering

° Barker'i notatsioon (kasutusel Oracle vahendites)

° IDEF1X

° UML (Unified Modeling Language)

Barker’i (Oracle) notatsioonis esitatud kontseptuaalsed mudelid (fragmendid):





Barker’i (Oracle) tähistused:





Information Engineering ’u ja Barker’i tähistuste võrdlus:

11. Andmebaasi projekteerimine

Kontseptuaalse modelleerimise järel jätkub infosüsteemi arendustöö andmete dimen­sioonis andmebaasi projekteerimisega (disainiga). Eristatakse loogilist ja füüsilist projekteerimist. Loogilise projekteerimise etapis koostatakse loogiline andmemudel, mis spetsifitseerib andmete realiseerimise valitud andmebaasisüsteemis. Füüsilise projekteerimise etapis koostatakse füüsiline andmemudel, mis määratleb tehnilised üksikasjad, mida loogiline andmemudel ei käsitle, näiteks sisemised mälustruktuurid, juurdepääsuteed, andmebaasi failide organisatsiooni.

Loogiline andmemudel peaks olema süsteemi kasutajale veel põhimõtteliselt aru­saa­dav, kuid siiski rohkem spetsifitseeriv kui kont­septuaalne andmemudel.

Näide. Andmebaasi loogiline mudel, esitatud SQL keeles.

12. SQL KEEL

SQL (Structured Query Language) on väga efektiivne, matemaatilisel süsteemil relatsioonialgebral põhinev andme­baasikeel, mis on kujunenud de facto andmebaasistandard. SQL võimaldab andmeid kirjeldada, pärida ning uuen­dada. Lisavõimalused on turbeks (autoriseerimine), kooskõlalisuse kontrolliks (integrity const­raints), transaktsioonide tööt­lu­seks. Päritolu: keel SEQUEL, IBM 1975. Süntaksinäiteid:

CREATE TABLE <table name> (<column name> <column type> [<attribute constraint>] {, <column name> <column type> [<attribute constraints>] } [<table constraint> {,<table constraint>}])

DROP TABLE <table name>

ALTER TABLE <table name> ADD <column name> <column type>

SELECT [DISTINCT] <attribute list> FROM (<table name> { <alias>} | <joined table>) {, (<table name> { <alias>} | <joined table>) } [WHERE <condition> ] [GROUP BY <grouping attributes> [HAVING <group selection condition> ] ] [ORDER BY <column name> [<order>] {, <column name> [<order>] } ]

INSERT INTO <table name> [( <column name>{, <column name>} ) ] (VALUES ( <constant value> , { <constant value>} ) {,(<constant value>{,<constant value>})} | <select statement>)

DELETE FROM <table name> [WHERE <selection condition> ]

UPDATE <table name> SET <column name>=<value expression> { , <column name>=<value expression> } [WHERE <selection condition> ]

13. Andmebaasi projekteerimine või infoarhitektuur?

Peamiselt veebisüsteemide levikuga seoses on populaarseks muutunud info­ar­hi­tek­tuu­ri mõiste. Sellest ja teistest mõistetest lähemalt järgmises loengus.

Probleemid/harjutused

1. Koosta valitud probleemala kohta kontseptuaalne mudel.

Kirjandus

° Veebis kättesaadavatest materjalidest tasub esile tuua hea praktilise käsitluse tõttu: Ambler S.W. Data Modeling 101. http://www.agiledata.org/essays/dataModeling101.html

Jaotis 2.1 How are Data Models Used in Practice?:

Kontseptuaalne andmemudel (Conceptual data model)

Loogiline andmemudel (Logical data model)

Physical data model (Physical data model)

Jaotis 2.3 Common Data Modeling Notations: Ülevaatlik tabel olulisemate andmemodelleerimis-meetodite (Information Engi­neer­ing, Barker'i/Oracle, IDEF1X, UML) notatsioonide võrdlusega. Samas ka meetodite lühiiseloomustused.

Jaotis 3. How to Model Data: Esitab andmemodelleerimise tüüptegevused:

- olemitüüpide identifitseerimine

- atribuutide identifitseerimine

- nimesüsteemide valik (naming conventions)

- seoste identifitseerimine

- võtmete leidmine/omistamine

- andmestruktuuride normaliseerimine

- denormaliseerimine (efektiivsuse kaalutlustel).

IFI6068  ◦  Sissejuhatus infosüsteemidesse  ◦  Sügissemester 2014

ÜLESANNE 9 | Infosüsteemi prototüüpimine

Koostage eelmistes ülesannetes kavandatud infosüsteemi ühte või mitut olulist aspekti väljendav ja testiv prototüüp. Prototüüp võib olla vabas vormis.

Täpsem teave praktikumis.

Töörühm: 1-3 inimest.
Esitamise tähtaeg: üks nädal alates ülesande andmisest.

PRAKTIKUM 10 | Infosüsteemi prototüüpimine

Ülesanne 8 Süsteemi arhitektuuri kavandamine | Läbivaatus

Ülesande 9 - Infosüsteemi prototüüpimine

LOENG 10 | INFOSÜSTEEMI füüsiline dimensioon

Eesmärk

Ruumi (füüsilise mõõtme) osa mitmetes infokäitlusega, sealhulgas süsteemiarendusega seotud küsimustes. Probleemid, seisukohad, lahendused. Pilk ajalukku ja võib-olla ka tulevikku.

Sisukord

Ruumi mõiste. Ruumi tüübid >  Suhe füüsilise ja virtuaalse ruumi vahel >  Ruumi omadused >  Virtuaalne ruum infosüsteemides >  Mitmemõõtmelise andmestiku esitamise probleem >  Füüsilise ja virtuaalse süsteemi liidestamine >  Huang (2001) käsitlus >  Paberdokumentatsiooni halduse küsimus >  Näide dokumendihalduse lihtsast lahendusest >  Füüsilise ruumi tähtsus süsteemiarendustöös >  Füüsiline dimensioon ettevõtte arhitektuuri mudelites >  Infotöötluse füüsilise mõõte ajaloost >  Suhtlemine arendaja ja kliendi vahel >  Füüsiline ruum ja infoühiskonna teooriad >  Kokkuvõte >  Seonduvad teemad  Probleemid/harjutused  Kirjandus

1. Ruumi mõiste. Ruumi tüübid

Ruumi mõiste on infosüsteemide arendajale oluline.

Infokäitluse seisukohalt võib rääkida kahest ruumi mõistest (ehk kahest ruumi tüübist): füüsiline ruum (physical space) ja virtuaalne ruum (virtual space). Füüsiline ruum on see loomulik keskkond, milles inimene kogu aeg on viibinud ja loodetavasti jääb ka viibima. Virtuaalne ruum on algselt olnud kujundlik väljend, kuid võtab tänapäeval üha „reaalsema” kuju.

Ruumi mõistega on lähedalt seotud keskkonna (environment) ja reaalsuse mõisted. Ulatuslikku, arenenud funtsionaalsusega tarkvarasüsteemi nimetatakse tihti keskkonnaks, näiteks: arenduskeskkond (development environment) on spetsiaalne tarkvarasüsteem süsteemiarendustöö toetamiseks. Virtuaalne reaalsus (virtual reality) on kasutusel tavapärase füüsilise keskkonda, aga ka väljamõeldud „füüsilisi” keskkondi esitavate tarkvarasüsteemi tähistamiseks.

2. Suhe füüsilise ja virtuaalse ruumi vahel

Võib näha, et suhe füüsilise ja virtuaalse keskkonna vahel võib olla keerukas. Tihti on seda suhet, täpsemalt muutusi selles suhtes, raske mõista.

Interneti buumi aatatel 2000-2001 ennustati kaubandusega füüsiliselt tegutsevate ettevõtete kiiret kadumist. Laialt levisid seisukohad, et „füüsiline”, traditsioonilistes kauplustes toimuv kaubandus on oma aja ära elanud ning asendub kiirelt e-kaubandusega. Järgnes tagasilöök. E-kaubandus on arenenud, kuid ebaühtlaselt. Eestis on „Ärielu” viimase numbri andmetele „e-kaubanduse osakaal minimaalne”. Traditsioonilise kaubanduse (brick and mortar) ja e-kaubanduse (e-business) vastandamine on asendunud realistlikuma, traditsioonilise ja e-kaubanduse optimaalse integratsiooni äristrateegiaga (kasutatakse kujundlikku väljendit clicks and mortar, s.t. nii arvutid kui ka füüsilised müügipunktid).

Sageli kohtame IT arenguid üldisel tasandil (ühiskonna mõõtkavas) käsitlevates kirjutistes väiteid, et infoühiskonnas ruumi tähtsus väheneb tugevasti, isegi kaob. Sellesuunaline tendents kindlasti on, kuid küsimust tuleks käsitleda laiemas kontekstis. Tõepoolest on tänapäeval võimalik osaleda globaalses majanduses, paiknedes füüsiliselt kusagil ääremaal. Samas metropolid, suurlinnad ei kao. Kinnisvara hinnad ei lange, vaid tõusevad.

Füüsilise ruumi tähtsus ei kao. Toimuvad keerukad protsessid, füüsiline ja virtuaalne ruum (ruumid) põimuvad üksteisega läbi. (Kõrvalmärkusena: arhitektuuri teoorias huvitutakse tänapäeval vägagi palju nendest muutustest, mida infotehnoloogiad füüsilise arhitektuurse keskkonna jaoks kaasa toovad).

3. Ruumi omadused

Kõrvutades füüsilise ja virtuaalse ruumi mõisteid, võime järeldada, et ruumi omadusteks on selle läbitavus mitmetes suundades (ruumis navigeerimine). Seetõttu saame virtuaalseks ruumiks nimetada oma tarkvarasüsteemi ainult siis, kui kasutajatel on seal küllalki palju liikumisvabadust. Ruumi mõiste on niisiis seotud ka liikumisvabaduse, laiemalt – tegutsemisvabaduse mõistega.

Ruumi tähtsaks omaduseks on mõõtmelisus. Eristatakse ühe-, kahe- ja kolmemõõtmelisi ruume. Geomeetrilises terminoloogias on ühemõõtmeline ruum – joon, kahemõõtmeline ruum – tasand. Meie tavaline ruum (see, milles viibime), on kolmemõõtmeline. Matemaatikas ja füüsikas on arendatud mitmemõõtmeliste ruumide teooriat. Näiteks kasutatakse aegruumi mõistet, milles kolmele füüsilise ruumi dimensioonile on võrdväärsena lisatud aeg.

4. Virtuaalne ruum infosüsteemides

Kas kõigis infosüsteemides tuleks püüelda virtuaalse ruumi loomise poole? Virtuaalse ruumi loomine on kindlasti raske; seda ei saa teha ilma spetsiaalse instrumentaalse tarkvarata (näiteks CAD tarkvara). Paljud rakendused vajavad oma olemuse tõttu virtuaalse ruumi loomist (arhitektuur, transport, logistika). Kuid mitte iga ülesande juures ei ole ruumilise metafoori kasutamine õigustatud. Üks veebiliideste uurija on märkinud, et veebisüsteemide algusaegadel oli populaarne maja metafoori kasutamine – kuval esitati „maja” kolme- või kahemõõtmeline mudel. Kasutaja kasutas süsteemi funktsionaalsust liikudes ühest ruumist teise. Selline ruumiline lahendus tundub esimesel pilgul huvitav, kuid pideval kasutamisel võib kergesti muutuda tüütavaks.

5. Mitmemõõtmelise andmestiku esitamise probleem

Praktilises infotöötluses on alati suureks probleemiks kõrgema mõõtmelisusega ruumi esitamine väiksema mõõtmete arvuga ruumis. See probleem tekib olemuselt mitmemõõtmeliste andmekogumite analüüsimisel. Näiteks – müügitulemuste andmete analüüsimisel. Millised atribuudid on ettevõtte müügitegevuse andmestikul? Rõivakaupluses on olulisteks atribuutideks:

artikli nr

maaletooja

tootjafirma

toote tüüp (püksid, särgid, ...)

sugu (M, N, laste, ...)

materjal

lõige

värv

suurus

pikkus

hind

müügi kuupäev

müügi kellaaeg

müügi nädalapäev

müüja nimi

Miks kõiki neid andmeid on vaja infosüsteemis registreerida? Selleks, et ettevõte saaks analüüsida müügi edukust mitmetest vaatenurkadest ja vastavalt leitud trendidele ja seaduspärasustele reguleerida kaupade sisseostu ja tootmist, müügiprotsesse – üldiselt kõiki ettevõtte töö- ja äriprotsesse. Praktikas kogutavad infomassiivid on seega sageli paljumõõtmelised (10-15 mõõdet). Kuidas sellist andmekogumit analüüsida? Excelis saame kergesti luua kahemõõtmelisi esitusi (risttabeleid). Veidi laiemaid võimalusi pakub kolmemõõtmeline diagram (3D diagram), kuid enamamõõtmelise andmekogumi esitamiseks otsesed, loomulikud moodused puuduvad. Siiski on paljumõõtmeliste andmekogumite esitamiseks ja visuaalse analüüsimise toetuseks leitud mitmeid osalahendusi. Excelis on võimas PivotTable funktsionaalsus. Eraldi klassi moodustavad andmeladude (Data Warehouse) vahendid. Teadusandmete visualiseerimine on omaette uurimise ja praktika ala (scientific visualization).

6. Füüsilise ja virtuaalse süsteemi liidestamine

Ettevõtete jaoks on oluliseks füüsilise ja virtuaalse keskonna integreerimine (seostatud, optimeeritud kasutamine).

Sama tegevust, näiteks müüki saab ju teha nii füüsiliselt (müük inimeselt inimesele kaupluses) kui ka virtuaalselt (ostja suhtleb ettevõtte e-süsteemiga). Kummalgi viisil on oma eelised. Sageli kohtame tehnokraatlikku nägemust, mille olemust võib kokku võtta järgmiselt:

iga füüsilist tegevust saab asendada e-tegevusega;

selline e-tegevusel üleminek on ka alati majanduslikult põhjendatud.

Siit tekivad loomulikult laiad võimalused e-süsteemide arendajatele. Väited ise aga ei kehti. On tegevusi, mida on otstarbekas teha füüsiliselt. Olulisteks küsimusteks ei ole mitte lausautomatiseerimine (ideaaliks on ju siis inimese üldse väljalülitamine süsteemist), vaid füüsiliste ja virtuaalsete tegevuste optimaalselt koostoimiva komplekti leidmine ja realiseerimine.

Seda põhimõtet tunti juba vanasti, kuid interneti buumi keeristes see ununes. 1970ndate süsteemiarendusmeetodites (nt. T. DeMarco Struktuurne analüüs Structured Analysis) oli arenduskäik järgmine:

1) koostati AS IS mudel (loodava süsteemiga haaratava tegevuste kompleksi üldmudel – olemasoleva töökorralduse kirjeldus)

2) koostati TO BE mudel

3) TO BE mudelis tõmmati automatiseerimise piir, s.t. märgiti tegevused, mis võeti loodavas süsteemis realiseerimisele.

Vaatamata arenenud tehnoloogilistele võimalustele tasub sellist arendusprintsiipi tänapäevalgi rakendada – valida tegevused, mille automatiseerimine (või infosüsteemiga toetamine) on nii tehnoloogiliselt, majanduslikult kui ka psühholoogiliselt (kasutaja tööhügieeni seisukohalt) mõeldav ja kasulik.

7. Huang (2001) käsitlus

Uuemal ajal on Huang (2001) andnud hea käsitluse füüsiliste tegevuste ja e-tegevuste ühitamisest. Vaatame Huangi käsitluse põhipunkte: ettevõtte müügitegevuses võib eristada järgmisi peamisi elemente (funtsionaalsusi, osategevusi):

Klientide „ligimeelitamine”

(Potentsiaalsete) klientide vajaduste väljaselgitamine

Info andmine klientidele (toodete, ostuprotsessi) kohta

Tellimuse vastuvõtmine

Makse vastuvõtmine

Kauba üleandmine ja/või kohaletoimetamine

Kliendisuhte haldamine ja arendamine (tagasiside, inimliku suhte hoidmine kliendiga jm.)

Tegevusel on füüsilised aspektid (jooned, omadused) ja virtuaalse aspektid. Näiteks, klientide ligimeelitamiseks pakub turunduspraktika palju läbiproovitud, tõhusaid meetodeid (millest kergekäeliselt loobuda ei tuleks): avatud füüsiline kauplusefrontaal käidaval äritänaval (miks kauplused koonduvad suurtesse kaubanduskeskustesse?), reklaamplakatid.



Kaupluse tegevuse füüsilised aspektid (fragment). Allikas: Huang (2001).



Kaupluse tegevuse virtuaalsed aspektid (fragment).

Küsimus, kordan, on tegevustele optimaalse realisatsiooni leidmises. Paljusid tegevusi võib tänapäeval teostada nii traditsioonilises, füüsilises viisis kui ka e-vormis (elektrooniliselt, IT abil toetatult või automatiseeritult). Näiteks rõivaste müügil võib kliendi mõõtude (mis määravad ostetava rõiva suuruse) teadasaamiseks kasutada mitmeid mooduseid:

a) klient saab e-kauplusest (veebilehelt) juhendi, kuidas end mõõta (kasutatakse näiteks jalatsite müügil; kliendile antakse juhis kuidas oma jala suurust ja laiust piisava täpsusega mõõta);

b) kaupluses kasutatakse elektroonilist mõõteseadet (keerukamatel juhtudel kehamõõtmete kindlakstegemist skaneerimise abil);

c) klient mõõdab end kodus ise ja teatav oma mõõdud;

d) müüja mõõdab kliendi isiklikult üle (kui palju kohtame sellist praktikat Eesti kauplustes?);

e) mõõtmise asemel proovitakse rõivaste sobivust kohapeal (praktiliselt kõige kindlam meetod, mida lisaks teistele tuleb praktikas reeglina ka kasutada).

Sageli minnakse lihtsamat teed – antakse kliendile ainult üks viis tegevuse tegemiseks. Tuleb mõista, et erinevad tegevuse realisatsioonid (füüsiline, elektrooniline, aga ka mitmesugustes proportsioonides kombineeritud lahendused) ei ole lihtsalt alternatiivid sama asja tegemiseks, vaid kliendi seisukohalt võib realisatsioonides olla oluline vahe.

Mõni inimene tunneb end ebamugavalt elektroonilise mõõteseade all; teisele võib olla vastumeelne mõõtmine müüja poolt – või mõõtmine üldse.

Infosüsteemi tegemine ei tohiks tegevuse sooritamise viise kitsendada vaid vastupidi – laiendada. Piiranguks siin on loomulikult majanduslikud kaalutlused – kuid sageli ka süsteemiarendaja mõtlemise piiratus.

Kui ettevõte valib füüsiliste ja e-tegevuste kooskasutamise strateegia (see on tüüpiline; vähe ettevõtteid saab hakkama ainult virtuaalsete tegevusvormidega), siis on loomulikult vaja vaadata, et füüsiline ehk nn. müüripool (brick and mortar) ja virtuaalne pool (clicks) töötavad teineteisega harmooniliselt kokku. Selleks on vaja e-tegevusi ja f-tegevusi (füüsilisi tegevusi) käsitleda mitte eraldiseisvate maailmadena, vaid ühe koosluse elementidena. Huang annab ilusa diagrammi, millelt on hästi näha ettevõtte tegevuste kogumi jagunemine füüsilisteks ja virtuaalseteks tegevusteks, samuti tegevustevahelised seosed:



Kaupluse füüsiliste ja virtuaalsete tegevuste võrk (fragment).

8. Paberdokumentatsiooni halduse küsimus

Üldine tendents on selge: paberdokumentatsiooni tähtsus ettevõtete ja organisatsioonide tegevuses väheneb. – Õige väide? Ainult osaliselt. Kontoripaberi, samuti muu infokandmiseks mõeldud paberi tarbimine maailmas ei ole vähenenud vaid kasvanud.

Mitmed uurimused, näiteks Komito(1998) on esile toonud paberi kui meediumi eripärad, mis tingivad seda, et paberi kasutamine taandub e-meediate ees ainult suhteliselt, mitte absoluutselt.

Ettevõtte kontekstis on dokumentide (nii paber- kui e-dokumentide) haldus tõsine infokäitluslik probleem, mille võib lahendada nii spetsiaalse dokumendihaldustarkvara rakendamisega kui ka teiste infosüsteemide koostises ühe moodulina või kõrvalfunktsioonina.

Tehnoloogilisest vaatepunktist (realisatsiooni lihtsus) võib ideaaliks lugeda paberivaba dokumendikäitlust. Ei tohi siiski segi ajada tehnoloogilist otstarbekust ja inimese eelistusi oma infovajaduste rahuldamisel. (Tehnoloogilise otstarbekuse seisukohalt peaksid kõik inimesed sõitma ühesuguste, ökonoomsete autodega, elama ühesugustes majades, kandma ühesuguseid rõivaid).

9. Näide dokumendihalduse lihtsast lahendusest

Näide suhteliselt lihtsast infosüsteemsest lahendusest väikese ettevõtte dokumendikäitlusele. http://www.thepapertiger.com/

Küsimused:

Milles on süsteemi põhiidee?

Kuidas on lahendatud paber- ja e-dokumentide ühtne käitlemine süsteemis?

Milles poolest see toode erinev analoogilistest isetehtud lahendustest?

10. FüüsiliSe ruumi tähtsus süsteemiarendustöös

Süsteemide endi arendamisel on ruumiline mõõde oluline nii üksiku töötaja (programmeerija, analüütiku, testija, dokumentatsioonikirjutaja, projektijuhi) kui ka arendusmeeskonna tasandil.

Süsteemiarendaja töökoha loomine ei saa piirduda standardsete kontoritöö tingimuste loomisega. Teema on lai ning vajaks eraldi käsitlust. Vt. nt. Kent Beck (2000) Extreme Programming Explained, ptk 13 Töökoha organiseerimine.

Curtis et al (2002): "Knowledge workers are extremely sensitive about their working environment".

Töörühma tasandil on üheks peamiseks motiiviks rühma suhtlemise ja koostöö toetamine füüsilise paigutuse abil.

Süsteemiarendusega (programmeerimisega) tegeleva meeskonna (firma) füüsiline töökeskkond (fragment), planeeritud ekstreemprogrammeerimise põhimõtteid järgides (Auer & Miller, 2003):





Kas selline töökeskkond on süsteemiarenduseks ideaalne? Kas sooviksite ise sellises meeskonnas töötada? Allikas: Auer & Miller, 2003.



Kas selline ruum on efektiivseks programmeerimistööks liiga väike? Kui palju võiks töö suuremas ruumis olla kiirem?



Kas ja millisteks tegevusteks saaks seda ruumi kasutada infosüsteemi arendusprojektis? Allikas: Maja/Estonian Architectural Review, 2002, 2 (33).

Avatud tööruumi (open workspace) mõiste. "Parim ekstreemprogrammeerimise tööruum on suur "laut", milles on väikesed individuaalsed töölahtrid (cubicles) paigutatud piki seinu ja keskel on lauad kiirete masinatega, üles seatud paarisprogrammeerimise jaoks."

11. Füüsiline dimensioon ettevõtte arhitektuuri mudelites

Populaarses Zachmani ettevõtte arhitektuurses raamistikus (mudelis) esitab füüsilist dimensiooni võrgu (network) veerg.



Allikas: Zachman Institute for Framework Advancement, www.zifa.com.

12. Infotöötluse füüsilise mõõte ajaloost

Infovoo liikumise analüüs infosüsteemide loomise algusaegadel (u. 1950-60 aastad) (fragment), Evans & Hague (1962). Info töötlejateks peamiselt kontoritöötajad (clerks), üksik töömahukad operatsioonid automatiseeritud mehhaaniliste või elektromehaaniliste arvutus- ja töötlusseadmetega. NCR – National Cash Register – arvutusseadmete tootja.



Kontoritöötajate jagamine rühmades infotöötlusoperatsioonide järgi (andmete kogumine, arvutuste teostamine, info edastamine, info kaustadesse paigutamine).



Tööjärje (töövoo) seonduva infoliikumise analüüsimine diagrammide abil, kasutades standardiseeritud tähistusi (fragment), Evans & Hague (1962).

13. Suhtlemine arendaja ja kliendi vahel

Väga oluliseks küsimuseks on arendaja ja kliendi vahelise suhtlemise organiseerimine, kui arendaja ja klient ei asu füüsiliselt teineteisele lähedal. Kasutatud on meetodit, kus arendusmeeskond kolib projekti ajaks kliendi ruumidesse ja arendus tehakse kohapeal. Küllaltki tihti on arendaja ja klient siiski füüsiliselt nii kaugel, et suhtlemine toimub ainult elektrooniliste kanalite kaudu.

Teine, eelmisega samalaadne probleem on arendustööde teostajate füüsiline eraldatus.

Juhtimisalases kirjanduses on näiteid projektidest (nii äri- kui ka IT projektid), mis on sattunud raskustesse just arendusmeeskonna füüsilise eraldatuse tõttu.

Füüsiline eraldatud on siiski tänapäeva projektides reaalsus. Kirjandus ja praktika pakub mitmeid meetodeid arendusprojektis virtuaalse suhtlemise korraldamiseks. Kindlasti tuleb praktikas arvestada ka seda lihtsat tõsiasja, et mõned inimesed suhtlevad e-meedia vahendusel meelsasti, mõnedele teistele on see aga vastumeelne.



Allikas: Oleg Shvaikovsky, MicroLinki tarkvaraarenduse osakonna juhtaja. think! (MicroLinki kliendileht).

14. Füüsiline ruum ja infoühiskonna teooriad

Suurbritannia parlament – kas küps informatiseerimiseks? Inimesed istuvad küllatki tihedalt (ajaloolistel pikkadel nahkpinkidel). Suuremasse ruumi ülekolimisel, inimeste paigutamisel kuvarite taha ei oleks raha ilmselt takistuseks. Kas hoitakse kinni traditsioonist, ei taibata IT võimalusi, või on põhjus milleski muus? Julgen väita, et küsimus ei ole tehnoloogilises mahajäämuses. Suurbritannia parlamendi istungeid kantakse veebis üle, neid on väga kõrgelt hinnatud. Saadikutel on oma arenenud veebilehed (-süsteemid).

15. Kokkuvõte

Füüsiline paigutus ei ole infosüsteemide ehitamisel kõrvaline ega tähtsusetu. E-süsteeme võib küll põhimõtteliselt teha täielikult virtuaalsetena; enamasti on siiski e-tegevuste kõrval süsteemi haaratud või sellega seotud nn. füüsilisi tegevusi. Sellest tekib vajadus võtta arvesse f-tegevuste spetsiifikat ning leida optimaalne jaotus kahe tegevuste liigi vahel. E- ja f-tegevused tuleb integreerida. Teatud juhtudel võivad kõige suuremad infokäitluse parendamise võimalused olla peidus füüsilises, mitte virtuaalses dimensioonis. MIT uurijad on kirjeldanud juhtumeid, kus töökohtade füüsiline ümberorganiseerimine ettevõttes (kümnete ja sadade töötajate mastaabis) on väga oluliselt tõstnud organisatsioonisisese infovahetuse efektiivsust. 

Seonduvaid teemasid

Teadmusteke  Tuntud äristrateegia ja –juhtimise autor Nonaka esitab jaapani filosoofias kasutusel olevat Ba mõistet. Ba on ruum, milles toimub inimeste sisuline kom­mu­nikatsioon ja uue teadmuse teke; Ba võib olla nii füüsiline kui ka virtuaalne.

Probleemid/harjutused

1. Projekteeri töökeskkond 3-5 liikmelisele arendusmeeskonnale (skeem + kommentaa­rid).

2. Hinda mõne tegutseva arendusrühma töökeskkonda: füüsiline paigutus, mugavus, suhtlemise võimalused.

3. Selgita välja, kui oluline on mõnes töötavas infosüsteemis füüsiline dimensioon. Kas tegevus toimub ainult virtuaalses ruumis või osaliselt ka füüsilises ruumis? Kuidas toimub füüsilise ja virtuaalse tegevuse koostoimimine?

4. Oma kavandatavad infosüsteemis: mõtle, milles avaldub füüsiline mõõde ja spetsifitseeri (esita) see diagrammi abil.

Kirjandus

Auer, K., Miller, R. (2002) Planning Extreme Programming. Playing to Win; vn. k.  Экстемальное программирование: постановка процесса с первых шагов до победного конца  (2003).

Beck, K. (2000) Extreme Programming Explained. Addison-Wesley., Ch 13 (töö­ko­ha organiseerimine); vn. k. Beck K. (2003) Экстемальное программирование.

Boland, R. (2001) The tyranny of space in organizational analysis. Inform­ation and Organization, 11, 3-23.

Curtis, R. et al (2002) Supporting Know­ledge Work With Physical Design. Knowledge Manag­ement Re­view, 5, 5.

Evans, M., Hague, L (1962) Master Plan for Information Systems, Harvard Business Review, 92-104.

Huang, J. (2001) A New Blueprint for Business Archi­tecture. Harvard Business Re­view, 4, 149-158.

Komito, L. (1998) Paper 'work and electronic files: defending professional practice. Journal of Information Technology, 13, 235-256.

Robey, D., Schwaig, K., Jin, L. (2003) Intertwining material and virtual work. Information and Orga­niz­at­ion, 13, 111-129.

Schultze, U., Boland, R. (2000) Place, space and knowledge work: a study of outsourced computer systems administrators. Acc­ount­ing, Ma­nagement & Information Technology, 10, 187-219.