I

I
m
m
p
p
l
l
e
e
m
m
e
e
n
n
t
t
a
a
c
c
i
i
j
j
a
a

i
i
n
n
f
f
o
o
r
r
m
m
a
a
c
c
i
i
o
o
n
n
o
o
g
g

s
s
i
i
s
s
t
t
e
e
m
m
a
a




ada je dizajn zavren, dolazi vreme za fiziku implementaciju novog informacionog
sistema. Cilj i glavni zadatak je prevesti projektantska reenja ulaza, izlaza, prenosa,
baze podataka i njihove interakcije u programski kod; proizvesti softverski proizvod za novi
informacioni sistem. Druga, ne manje vana, pitanja su testiranje i implementacija
tehnologije, testiranje programa i sistema u celini, edukacija i konverzija sistema. Mnoge
organizacije se odluuju na kupovinu gotovih aplikativnih softverskih reenja, umesto da ih
same konstruiu i izgrauju. U tom sluaju, sadraj ove glave bio bi usredsreen na problem
evaulacije i kastimizacije kupljenog softvera. Meutim, u ovom tekstu emo se skoncentrisati
na procese i probleme sopstvenog razvoja softvera.


Implementacija informacionog sistema se paljivo planira (Slika 21-1) [35,s.836]. Celokupan
plan se odnosi na etiri celine: (1) Programiranje; (2) Instalacija i testiranje tehnologije; (3)
Trening i edukacija personala i (4) Konverzija i uvoenje sistema.
K
K







546
Informacioni sistemi u menadmentu











Slika 21-1

L
e
g
e
n
d
a
A
k
t
i
v
n
o

v
r
e
m
e

t
r
a
j
a
n
j
a
D
o
g
a

a
j
i
P
r
i
h
v
a
t
a
n
j
e
I
m
p
l
e
m
e
n
t
a
c
i
j
a
K
o
r
e
k
c
i
j
a

s
i
s
t
e
m
a
T
e
s
t

p
r
o
g
r
a
m
a
P
i
s
a
n
j
e

p
r
o
g
r
a
m
a
4
7
9
1
0
1
1
1
2
1
2
6
3
8
5
I z b o r i n a b a v k a
t e h n o l o g i j e
I
n
s
t
a
l
a
c
i
j
a
t
e
h
n
o
l
o
g
i
j
e
T
e
s
t
i
r
a
n
j
e
t
e
h
n
o
l
o
g
i
j
e
T
e
s
tira
n
je
u
la
z
a
i iz
la
z
a



















Implementacija informacionog sistema
547









1 1 P Pr ro og gr ra am mi ir ra an nj je e

oftverski proizvodi su veoma kompleksni, moniji nego ikada ranije i prema pouzdanim
statistikim podacima oko 80% trokova razvoja informacionog sistema otpada na izradu
programa. Organizacija i menadment od programerskih timova zahtevaju vie nego ikada
ranije. Dobra organizacija programerskih timova i efikasan menadment su preduslovi
produktivnog rada programera i kvaliteta softverskih proizvoda.


1 1. .1 1 P Pr ro og gr ra am me er rs sk ke e o or rg ga an ni iz za ac ci io on ne e s st tr ru uk kt tu ur re e

Kompleksnost programerskih napora i potreba za efektivnom i efikasnom organizacijom se
razmatra u svim sluajevima, ak i za najmanje poslovne informacione sisteme. Sloenost je
prouzrokovana iz vie razloga. Na jednom proizvodu radi uvek vie programera, vremensko
ogranienje je esto prisutno, programski moduli su relativno nezavisni. ak i kada je
razreen nain povezivanja, i uspeno ili neuspeno reenje jednog modula moe imati
signifikantan uticaj na druge, programski standardi moraju biti uspostavljeni i primenjivani,
da bi se osigurale efikasne budue promene, kontakti sa korisnicima moraju biti koordinirani,
testiranje programa treba da se planira i paljivo obavi. U literaturi [35] se susreu tri vrste
organizacionih struktura za planiranje, izvrenje i kontrolu programerskih zadataka: (a)
tradicionalna programerska struktura, (b) adaptivni programerski timovi i (c) ef
programerskog tima.

1.1.1 Tradicionalna programerska organizaciona struktura

U tradicionalnom nainu organizovanja programerskog rada, programeri su lanovi
programerskih grupa ili odeljenja i dodeljuje im se posao koji je raspoloiv. U situacijama
kada organizacija raspolae dovoljnim brojem aplikativnih programera za odravanje,
programeri se organizuju za pojedine divizionalne ili funkcionalne oblasti. Ovakav nain
organizacije moe biti vrlo uspean. Neretko se primenjuje model, projekat bazirane
strukture tima. Uspostavljaju se projekti i za svaki projekat formira tim od profesionalnih
informatiara i eksperata korisnika. Ovo je matrini oblik organizacije i ova vrsta
programerskih timova radi veoma dobro u razvoju sistema sa visokim stepenom
nadreenosti. Ovaj nain programerske organizacione strukture, podrazumeva da veliina
programerskih timova bude relativno mala, izmeu dva i osam lanova. Vei timovi su uvek
optereeni komunikacijom, i imaju potekoa zbog mrvljenja programskih zadataka u
module jer prekomerna modularizacija rezultira slabom kohezijom i kompleksnim
povezivanjem. Smatra se da je sa manjim timovima modularizacija laka i standardi
strukturnog programiranja mogu biti nametnuti i kontrolisani.
S
S







548
Informacioni sistemi u menadmentu










1.1.2 Adaptivni programerski timovi

Adaptivni programerski timovi su neformalni i ine ih 5-10 programera. Svaki tim, po
pravilu, ima poasnog lidera koji moe da se u toku funkcionisanja tima pojavi i preuzme
liderske pozicije, ili se voenje moe rotirati i deliti izmeu lidera i drugiha lanova tima.
Zadaci u timu se diskutuju od strane tima u celini i alociraju za svakog lana, shodno
njegovim sposobnostima i iskustvu; kompleksni zadaci starijim i iskusnijim lanovima, a
manje sloeni mlaim lanovima. lanovi tima su odgovorni za ispitivanje i evaulaciju rada
drugih. Ovaj odnos je nedokazan u negovanju oseanja zajednike odgovornosti za kvalitet
programa, poto programeri sve posmatraju kao svojstvo grupe, a ne personalne svojine.
Slobodan tok informacija i porast demokratije timske "pameti" rezultiraju u veoj
produktivnosti. Treba imati na umu da se ovakvi timovi mogu formirati i od nekompetentih
lanova, to e uvek dovoditi do nezadovoljavajuih rezultata. U tim sluajevima timovi e u
svom radu posrtati, troie novac i eventualno izneveriti oekivanja. ak, adaptivni tim sa
prosenim iskusnim i kompetentnim lanovima moe imati ogranieni nivo efikasnosti u
proizvodnji softvera, poto kultura tima prisiljava na jednolino ponaanje i kanjava svako
odstupanje od normi.

1.1.3 ef programerskog tima

Ovaj pristup postavljanja organizacione strukture programiranja polazi od injenice da ef
programerskog tima upravlja svim tehnikim aspektima nekog projekta, u koje spadaju: (a)
priprema dizajna programa, (b) kontrola kodiranja, (c) nadziranje testiranja programa, (d)
integracija modula i (e) dokumentovanje programa. ef programerskog tima dobija kljunu
podrku od vodeeg asistenta, koji komunicira sa svim lanovima tima i ispoljava se kao
"vrsta savest" ideje efa programerskog tima. lanovi tima su osobe razliitih funkcija,
zaduenja i znanja [35]:

a) programeri za podrku programeri koji kodiraju module nieg nivoa;
b) bibliotekar osoba koja odrava biblioteku programske produkcije, kompajlira i testira,
stara se da objektni i izvorni kod bude uvek auran;
c) administrator osoba koja vodi sve administrativne poslove tima;
d) editor osoba koja je odgovorna za ureivanje i kritiku analizu dokumentacije,
pretraivanje referenci, nadgledanje svih faza sainjavanja i distribucije dokumentacije;
e) graditelj sredstava osoba koja pie specijalne programe za interfejs sa operativnim
sistemom;
f) evaulator priprema test podatke za pojedine programe i testira sistem (osobe nezavisne
od programerskog tima);
g) specijalista za programski jezik neko ko izvanredno poznaje jezik, konsultant je efu
programerskog tima, pie programe koji zahtevaju visok nivo znanja i iskustva u
konkretnom programskom jeziku;






Implementacija informacionog sistema
549









h) sekretar - ovek koji prati sve tehnike probleme ekspertskog tima, izvrava sve
sekretarske dunosti koje zahteva programerski tim.

Za uspeno funkcionisanje ovog organizacionog modaliteta signifikantna je procedura
"prolaska kroz strukturne programe". To je osnovni metod revizije koji se regularno
upotrebljava u ispitivanju programiranja i determinisanja pripadnosti utvrenim
specifikacijama i standardima. Cilj ove procedure je pronalaenje propusta, greaka, loe
logike i inae pogrenih programskih konstrukcija. Od ove procedure ima vie koristi. Jednu
smo ve istakli - proizvodnja programskog koda poeljnog kvaliteta. Druga korist je da
program postaje vie itak, poto programeri znaju da e njihovi programi biti ispitivani i
ocenjivani od drugih, od nekog ko moe biti iz drugog tima ili grupe korisnika.

Poto je priroda strukturnog programiranja hijerarhijska, revizorski tim se koncentrie na vie
nivoe dizajna u vreme ranog ispitivanja. Sekvencijalne iteracije obezbeuju poveanu masu
detalja za ispitivanje. Obino, nekoliko lanova tima je iz druge oblasti, to poveava
objektivnost ispitivanja.

Seansa se zavrava na terminalnom sastanku; moderator kontrolie sastanak, programeri
objanjavaju svoj posao, ocenjivai komentariu, zapisniar dokumentuje sve greke, kolizije,
nekonzistentnosti koje nisu otkrivene za vreme "prolaza kroz program". Proishod ovakvog
tretmana je lista greaka uz obezbeenje generalne preporuke. Tim je odgovoran za
identifikaciju problema, a programer koji je pisao program za otklanjanje greaka.

Smatra se da je ovo danas, najbolja organizaciona struktura programerskog rada. Veliki broj
autoriteta smatra da je modalitet organizacije programerskog rada "ef programerskog tima"
priblino dva puta produktivniji od drugih timova. Ovi timovi su pogodni da zadovolje
vrste rokove i vie je decentralizovan i motivisan tim. esto se ef programerskog tima
uporeuje sa timom hirurga u kojem ultimativna odgovornost ostaje na efu hirurga, koji je
podran sposobnim specijalistikim tabom, koji ine pozadinski hirurzi, anesteziolozi,
glavna sestra, sestre i drugo tehniko osoblje.


1 1. .2 2 I Iz zr ra ad da a p pr ro og gr ra am ma a

Izrada programa je proces koji izvravaju programeri (lanovi programerskog tima), koji piu
programske instrukcije koje e izvravati raunar. Programski kod se bazira na
specifikacijama koje su pripremili analitiari sistema tokom faze dizajna. Ove specifikacije su
najee u jednom od oblika ili njihovoj kombinaciji: strukturni engleski ili pseudo kod,
Nassishneiderman dijagram, Warnier-Orr dijagram, strukturni dijagram, Hipo, tabele
odluivanja i slino.






550
Informacioni sistemi u menadmentu










U nastojanju da budu u svom poslu produktivni i da proizvode kvalitetne programe,
programeri koriste mnoge tehnike, kao to su: metodologija sistemskog razvoja, prototajping,
jezici etvrte generacije, sistemi za upravljanje bazama podataka, upitni jezici, razliiti
dijagrami za modelovanje, case alati, strukturno i objektno programiranje i razliita
programska sredstva.

1.2.1 Pristup strukturnog programiranja

Strukturno programiranje nalae programeru da sledi, posebnu i pedantnu disciplinu,
uglavnom, okarakterisanu zabranom korienja goto naredbe u interprogramskom
povezivanju unutar programske procedure. Tehnika modularnog programiranja ima veoma
vanu ulogu u izgradnji strukture programa. Strukturni programi su organizovani
hijerarhijski; sa jednim modulom na vrhu (glavni modul) i vie modula na pojedinim
hijerarhijskim nivoima (Slika 21-2).

Slika 21-2

100
Nabavka
110
Obrada narudbi
120
Auriranje slogova
dobavljaa
130
Upiti
140
Izvetaji
121
Dodavanje podataka
122
Auriranje podataka
123
Brisanje podataka














Hijerarhijsko razlaganje programskih zadataka se vri Top-down pristupom. Razbijaju se
kompleksni programerski problemi na manje zadatke, module. Moduli mogu biti, radi izrade
programskog koda, dodeljeni pojedincima ili manjim programerskim grupama. Izvrenje
zapoinje modulom na vrhu hijerarhijske strukture; potom se izvrenje i kontrola prenose na
module niih hijerarhijskih nivoa. Hijerarhijski dijagram (Slika 21-2) postaje organizaciono
efikasno sredstvo za koordinaciju programerskog rada i dokumentovanje projekta. Dobre
karakteristike i koristi ovog metoda su:

Sloeni programski zadaci se razlau na manje kohezivne celine (module);
Moduli su meusobno povezani i njihova realizacija sledi logiki tok "levo na desno" (na
primer, ne moemo aurirati i/ili brisati podatke ako oni nisu prethodno uneti);






Implementacija informacionog sistema
551









Hijerarhijski skup zavisnih modula se koristi za razvoj plana realizacije projekta i plana
testiranja;
Moduli su organizovani u grupe modula. Na primer, auriranje slogova dobavljaa (grupa
modula) se ne moe u potpunosti testirati sve dok se ne zavre moduli kao to su:
dodavanje, auriranje i brisanje. Ovo je vano zbog ciljeva testiranja i odreivanja
odgovornosti za izvrenje programskih zadataka;
Produktivnost izrade programa se unapreuje dodeljivanjem sloenih i teih modula
sposobnijim programerima;
Efikasnost izvrenja moe biti uveana fokusiranjem napora na module koji se ee
koriste;
Programi se lake odravaju, poto promene mogu biti izdvojene i locirane u module koji
ne zahtevaju iri zahvat promena.

Logika strukturnog i modularnog programiranja se konsekventno moe primeniti od nivoa
kompleksnih i velikih programskih zadataka, do nivoa najmanje, mikroprogramske strukture.
Pristup je baziran na matematikim dokazima teorije struktura, koja pokazuje da neki
programski zadatak moe biti strukturisan kao poseban i podesan modul sa jednim ulazom i
jednim izlazom, koristei kao logiku strukturu sledee programske funkcije: (a) sekvencu,
(b) selekciju, (c) iteraciju.

Strukturna metodologija je sistematian, pristup odozgo na dole (top-down) uspeno deli
programske zadatke na manje delove. Konani delovi (grumenii) su male celine koje se
mogu prevesti brzo u specifini kod nekog programskog jezika.

1.2.2 Programska sredstva

Programeri u izradi programa koriste razliita sredstva u cilju vee produktivnosti, tanosti i
pouzdanosti programa. Neke od njih emo ukratko opisati: biblioteka subrutina, store
procedure, biblioteka klasa, editori tekstova i mree radnih stanica.

Najpoznatije programsko sredstvo je biblioteka subrutina. Ova biblioteka direktno
obezbeuje imena, opise i pristupne procedure za subrutine koje u programu imaju odreene
funkcije i koje su ranije napisane i testirane. Ove rutine mogu biti takozvani "industrijski
standardi", kao to su, na primer, matematike, statistike, finansijske i druge funkcije i oni
mogu biti primenjivani u pojedinim aplikacijama unutar kompanije, kao to je, na primer,
izraunavanje poreza. Kada su potrebne u nekom programu, one se pozivaju svojim imenom
(CALL OBR-POREZ) iz biblioteke subrutina. Osim subrutina moe se koristiti i programsko
sredstvo zvano copy routines. Njime se omoguava da se iz biblioteke odreene sekcije koda
kopiraju i prenesu u novi program.

Store procedura je objekt baze podataka koji se tumai, optimalizuje i sprema za izvrenje
odgovarajuim softverom u samoj bazi podataka. Primarni cilj store procedure je
obezbeivanje alternativnih sredstva za izvrenje SQL naredbi i njenim smetanjem na






552
Informacioni sistemi u menadmentu










centralno mesto u bazi podataka. Normalna je procedura SQL da se konkretna naredba
poziva i izvrava drugim sredstvima, kao npr. 4GL, iz drugih eksternih spremita, a ne iz
baze podataka. Sredstvo kao to je store procedura je uaurena struktura sa drugim
funkcijama i smetena u tabele baze podataka. Ove memorisane procedure mogu biti
izvravane eksternim pozivom iz 4GL ili nekih drugih proizvoda. Ova tehnologija se naziva
SPL (Stored Procedure Language). Izvravanje store procedure je mnogo efikasnije poto ne
zahteva neke posebne resurse i komunikacije radi njihovog izvrenja.

Biblioteka klasa - Objektno orijentisani alati i biblioteke ine programiranje mnogo lakim,
kreativnijim i to je najvanije mnogo produktivnijim. Svaka biblioteka sadri mnotvo klasa.
Programiranje u OO jezicima moemo podeliti na klijent programere i programere klasa i
biblioteka klasa. Veina objektno orijentisanih jezika, pored sintakse i kompajlera, u sebi
sadre i kompletno razvojno okruenje ukljuujui poveu biblioteku sa dobro definisanim i
lako iskoristivim objektima. Primarni zadatak klijent programera moe biti, da se najbolje
iskoriste postojee klase za reavanje problema. Veoma je vano da korisnik biblioteka,
takozvani klijent programer, moe da se osloni na postojee biblioteke u OO jeziku kako ne
bi morao da ispravlja kod pri izlasku novih verzija i biblioteka. Takoe, i kreator klasa mora
da ima slobodu menjanja raznih klasa u biblioteci radi unapreivanja ranijih zamisli i reenja.

Editori teksta omoguavaju programerima da vre razliite promene, brisanje, dodavanje i
to veoma lako i brzo. Editor automatski izlistava sintaksne greke za vreme editovanja
procesa.

Mrea radnih stanica omoguava programerima da rade na radnim stanicama on-line i u
realnom vremenu. Radne stanice su povezane sa file serverima, serverima za tampu i drugim
raunarskim resursima, koji znaajno poveavaju produktivnost rada programera, stvaraju
efikasno i pouzdano radno okruenje i omoguavaju brzo povezivanje i komunikaciju u
programerskim timovima.

1.2.3 Programski standardi

Jedan od osnovnih ciljeva u razvoju IS jeste, lako budue odravanje i menjanje programa.
Najefikasnije sredstvo da se osigura budue razmatranje i menjanje programa je postavljanje i
striktno pridravanje programskih standarda. Izmeu mnogih, u ovom tekstu dat je osvrt na
etiri kljuna standarda: kodiranje, interna programska dokumentacija, eksterna
programska dokumentacija i programska biblioteka.

Kodiranje se oslanja na standarde koji podravaju osnovne strukture programa i preporuuje
se pet takvih standarda:

Program treba da je modularan i da modul nema vie od 15 linija koda. Moduli se lako
odravaju, promena koda jednog modula nema znaajnih implikacija na ostatak programa,
programer za odravanje lake prati programsku logiku.






Implementacija informacionog sistema
553









U dizajnu programa neophodno je koristiti top-down prilaz, tako da svaki modul
poseduje vrstu logiku, povezanost i reene submodule za povezivanje.
Svaki modul treba da ima samo jedan ulaz i jedan izlaz, da bi se uveale mogunosti
programera za odravanje - lakog i breg razumevanja modula.
Treba uvek slediti sekvencijalni programski tok, tako da se program izvrava u istim
sekvencama kako se pojavljuje u listingu programa. Ako bi inili suprotno, posledice bi
bile komplikovano razumevanje programske logike od strane programera za odravanje.
Treba se pridravati pravila: jedna instrukcija po redu, poveava stepen razumevanja
programskog koda u modulu.

Pridravanje ovih standarda u kodiranju, znaajno poveava efikasnost procesa,
produktivnost rada programera i smanjuje trokove odravanja programa.

Interna programska dokumentacija sadri, pre svega, objanjenja funkcija programa. Ne
treba zaboraviti da e napisani program biti u operativnoj primeni due vreme i da e
najverovatnije, posle izvesnog vremena, biti odravan od osobe koja ga nije pisala.
Svrsishodno je koristiti nazive sa punim znaenjem, identifikovati i objasniti subrutine,
kopirane rutine, storeprocedure, klase i tome slino. Koristiti komentare radi boljeg
razumevanja programske logike. Postaviti prazne linije izmeu delova programa,
programskih celina, kako bi se poveala itljivost programa.

Eksterna programska dokumentacija ukljuuje tehnike kao to su hijerarhijski dijagram
programa, U-P-I dijagram, strukturni detaljni dijagram toka programa, Nassi-Shneiderman
dijagram i druge grafike tehnike. Programer trai modul koji treba menjati idui kroz
programski kod. Klju za traenje je eksterna programska dokumentacija, a ona je esto
oskudna i neaurna. Dobar dizajn podrazumeva dobru i dokumentovanu implementaciju.
Loa i nedokumentovana implementacija je ekvivalentna siromanom sistemu.

Programska biblioteka se projektuje i izgrauje za smetanje, zatitu, uvanje i
dokumentovanje svih aplikativnih programa i jezika za kontrolu poslova. Obino se u
velikim sistemima koriste posebni diskovi za smetaj desetina i desetina programa, a tim
programima rukuju bibliotekarski paketi. Biblioteka omoguava direktno listanje naziva svih
programa, uvid u programski status: proizvodi se, testira, aktivan, neaktivan i potpun pregled
promene programa. Samo autorizovane osobe mogu pristupiti biblioteci, menjati status
programa, menjati ga ili brisati iz biblioteke.


1 1. .3 3 T Te es st ti ir ra an nj je e p pr ro og gr ra am ma a

Bilo da je program razvijen u kui ili nabavljen na tritu softvera, neophodno je proveriti
(testirati) da li program radi ono to se od njega zahteva. Testiranje programa je zavrni






554
Informacioni sistemi u menadmentu










zadatak da utvrdimo, budemo sigurni i dokumentujemo da program zadovoljava zahteve
korisnika. Rezultati procesa testiranja ne mogu apsolutno tvrditi da je program korektan.
Testiranje pokazuje prisustvo greaka koje se ne mogu tolerisati i koje se moraju otkloniti.
Mogue je, dakle, da se neke greke ne otkriju iako je izvreno testiranje bilo rigorozno,
sveobuhvatno i iroko. S obzirom da nema garancije za potpuno odsustvo greaka u
programu, postavlja se pitanje: koliko dugo vriti testiranje i koje metode testiranja
primenjivati. Odgovor na ovo pitanje ne moe biti egzaktan i moglo bi se rei da zavisi od
vrste i znaaja konkretnog aplikativnog programa. Ako je re o programu koji kontrolie let
svemirskog broda, onda oko 90% ukupnog vremena razvoja sistema otpada na testiranje i
testiranje je sveobuhvatno i veoma, veoma rigidno. Ako je, na primer, re o programu koji
formira neki interni poslovni izvetaj, testiranje moe trajati marginalni procenat ukupnog
vremena razvoja sistema. U svakom sluaju, testiranje treba da se vri i plan testiranja mora
biti primeren funkciji, sloenosti i znaaju programa koji se testira.

1.3.1 Ciljevi i korist testiranja programa

Strukturni prilaz razvoju raunarskih programa zahteva strukturni prilaz razvoju test
podataka. Cilj konstrukcije odgovarajuih test podataka je kompleksan proces i primarni cilj
je ograniiti broj testova, jer svako dodatno testiranje programa zahteva vreme i troenje
novca. Sa minimalnim brojem testova cilj je obezbediti kvalitetan program. Od razvoja test
podataka u strukturnom programu koristi mogu biti:

a) standardizacija testiranja svih programa nekog projekta i obezbeivanje konzistentnog
proizvoda,
b) ocenjivanje svih moguih uslova koji mogu prouzrokovati greke u sistemu,
c) strukturni razvoj moe biti heuristiki, test podaci mogu biti unapreivani, moe se uiti iz
greaka sistema i za svaku greku kreiraju se novi test podaci.

1.3.2 Vrste greaka i nivoi testiranja

Greke u programu su veoma nezgodni "neprijatelji". Znati ko su i kakva je priroda tih
neprijatelja je od znaajne koristi. Tada moemo uspeno otkrivati i boriti se, razoriti ih, pre
nego one razore na sistem. Tri najvanije kategorije programskih greaka ili stenica (bugs),
su: (a) sintaksike greke, (b) semantike greke i (c) algoritamske greke.

Sintaksike greke su posledica neodgovarajue primene gramatikih pravila koje namee
konstrukcija nekog programskog jezika. Semantike greke rezultiraju iz pogrene logike.
One su tee za otkrivanje nego sintaksne, prouzrokuju greke u izvrenju programa,
generisae, primera radi, atraktivne, ali netane izvetaje. Algoritamske greke ne
prouzrokuju netane proraune, ali formiraju nevalidne rezultate. Na primer, moe se desiti
da kompanija, koja distribuira elektrinu energiju i upotrebljava formule za proraun utroaka






Implementacija informacionog sistema
555









energije i izradu rauna, bude usled nastanka algoritamske greke u tim proraunima
znaajno oteena. Raun je, sa algoritmike take gledita "korektan", ali usled pogreno
upotrebljenog numeratora u formuli, za kompaniju tetan, jer su zaduenja potroaa bila
ispod realnog nivoa. Ove se greke, takoe, vrlo teko otkrivaju.

Strukturno programiranje zahteva modularne konstrukcije i proces testiranja treba da sledi
istu logiku. U tom kontekstu postoji pet nivoa testiranja: (a) testiranje funkcija, (b) testiranje
modula, (c) testiranje integracije, (d) testiranje celovitog programa i (e) testiranje
prihvatljivosti programa.

Testiranje funkcija i procedura koje sainjavaju programski modul se vri sa svrhom da se
obezbedi njihovo korektno operisanje. Testiranje modula je testiranje celine koja je
sastavljena od ve testiranih delova (funkcije i procedure), da bi se ocenilo da li su
performanse celine zadovoljavajue. Testiranje integracije je testiranje korektnosti i
ispravnosti interakcije izmeu integrisanih modula u celinu vieg nivoa. Testiranje je
fokusirano na interfejs modula, poto se pretpostavlja da su sami moduli korektni.
Testiranje celovitog programa se esto naziva testiranje sistema, testira se uspenost
kombinacija svih subsistema u celoviti programski paket. Panja je usmerena na otkrivanje
greaka u dizajnu i sagledavanju kako adekvatno i korektno programski paket zadovoljava
korisnike zahteve. Testiranje prihvatljivosti je usredsreeno na ustanovljavanje injenica
da li dobro i uspeno program radi sa realnim podacima u operativnom okruenju. Ovu vrstu
testiranja obavljaju korisnici. Ako program zadovolji ovaj test, on je prihvatljiv za korisnike i
moe se uvrstiti u informacioni sistem.

1.3.3 Pristupi testiranju

Nekoliko pristupa testiranju programa se moe efikasno koristiti: (a) big-beng, (b)
inkrementalni, (c) top-down i (d) bottom up [35]. Svaki od ovih pristupa ilustrovaemo
primerom na slici 21 3.

Slika 21-3

A
B C D
E F G



















556
Informacioni sistemi u menadmentu










Big-Beng pristup kombinuje sve module i funkcije u testiranju celog programa. Mnogi
eksperti ne preporuuju ovaj pristup. Smatra se da je veoma teko sainiti sloaj za testiranje
koji e sprovesti proveru svih aspekata programa. Ako se greke otkriju, teko je prepoznati
vrstu i alocirati mesto greke. Ako bi program na slici bio napisan razliito od njegove
modularne strukture u stilu "kobasica" sa n goto instrukcija, onda je jedino ovaj pristup
mogu u testiranju takvih programa. Program se zbog mnogo interparagrafskih goto
instrukcija ne moe razbiti u manje kontrolisane module i testirati nekim drugim efikasnim
pristupom.

Inkrementalno testiranje polazi od pojedinanog modula koji se podvrgava odgovarajuem
test sluaju. Ako jedanput testiran modul obezbeuje zadovoljavajue rezultate, drugi modul
se uvodi i primenjuje se vie test sluajeva. Proces se nastavlja sve dok se svi moduli,
postupno ne integriu u kompletan program. Pretpostavlja se da pojavu greaka, nakon
uvoenja novog modula, prouzrokuje novi, tek uvedeni modul. Na ovaj nain se lokalizuje
izvor greaka, otkrivaju i lake ispravljaju greke.

Slika 21-4

A
C B D
A
C B D
F E G
A
C B D
F E G
stubs stubs stubs
stubs stubs stubs














Top-down testiranje zahteva prethodno razvijanje dodatnog softvera koji e omoguiti ovaj
pristup. Ovaj softver obezbeuje stub i drajver module. Za testiranje modula koji poziva i
prenosi (predaje) podatke, stub moduli moraju biti napisani, da bi se modelovao ovaj odnos
(veza). Za testiranje modula koji se pozivaju viim modulom i primaju podatke od njega,
mora biti napisan driver modul. Ovaj pristup ima obrnuti redosled u odnosu na razmatrani
pristup u nivoima testiranja. Tada smo rekli da je redosled sledei: funkcija moduli






Implementacija informacionog sistema
557









integracija program prihvatljivost. Top-down prilaz poinje integracijom, pomera se
potom redosledno na nie nivoe sve do kraja hijerarhijske strukture (Slika 21-4).

Modul vlasnika A se testira prvo. To zahteva korespodentni stubs do modula B, C i D. Tada
se moduli B, C i D testiraju korienjem modula A i stubs za module E, F i G. Konano,
moduli E, F i G se obuhvataju zajedno sa ostalim modulima i testira se integralni paket.
Podesan test prozvanog, traenog modula zahteva stub da proveri ulazne parametre i vraa
vrednosti raspoloivih odgovora za autput parametre.

Buttom-up testiranje polazi od najnieg nivoa modula koji se testira prvi, zahtevajui driver
module. Nakon toga se testiraju moduli koji povezuju najnie module. Testiranje se nastavlja
postupno sve do modula vlasnika. Ovaj pristup je prikazan na slici 21-5. Prvo se testiraju
moduli E, F, G i D. Zahtevani driveri su B-driver za module E i F, C-driver za modul G i A-
driver za modul D. Tada se moduli E, F, G, C i B integriu i testiraju A-driverom. Potom se
svi moduli integriu i testiraju.

Slika 21-5

A
C B D
F E G
Driver
D
Driver
A
C B D
F E G
C B
F E G
driver driver














1.3.4 Kontrola testiranja

Upravljanje tehnikama testiranja je teko i zahteva striktnu kontrolu. Proces testiranja nikada
nije izolovan. Dobar softver se testira strukturno, standardizovano, sveobuhvatno i efikasno.
Testiranje mora imati kontrolne funkcije, biti odgovorno i uvek realizovano od nezavisnih
programerskih timova. Kontrola testiranja ukljuuje nekoliko inilaca: sekvencijalnost (o
emu je bilo rei), dokumentovanost, odgovornost, plan testiranja. Svi podaci, poruke i






558
Informacioni sistemi u menadmentu










informacije o procesu testiranja programa moraju biti dokumentovani. Dokumentacija sadri
sledee informacije:

testirane softverske module,
broj uslova (ulaza) koji su korieni u test pokuajima,
testirane specifine uslove,
raunarsko vreme utroeno na testiranje,
broj i vrsta otkrivenih greaka.

Odgovornost za testiranje programa najee dele programer koji je pisao program,
programer koji e odravati program i eventualno korisnik. Sekvencijalno testiranje,
kompozicija test podataka i dokumentovanje test rezultata su delovi test plana. Plan se razvija
u skladu sa hijerarhijskim dijagramom koji se koristi kao sredstvo za organizaciju
programerskih napora. Plan se sainjava u fazi dizajna, a koristi u fazi implementacije
sistema. On je deo ukupnog plana razvoja IS i koristi se kao jedno od sredstava kontrole u
sistemskom pristupu razvoja IS.


2 2 I In ns st ta al la ac ci ij ja a i i t te es st ti ir ra an nj je e t te eh hn no ol lo og gi ij je e
informacionom strategijskom planiranju posveena je odreena panja informatikoj
tehnologiji: (a) projektovanje modela savremene informatike arhitekture, (b) analiza i
izbor raunarske opreme i (c) analiza i izbor sistemskog softvera (operativni sistemi, sistemi
za upravljanje bazama podataka, CASE alati, jezici i sredstva za razvoj aplikativnog softvera).

U ovoj sekciji ukratko emo diskutovati o problemima instalacije i testiranja tehnologije.

Instalacija sistema na veliki broj mesta u organizaciji koja ima sloenu organizacionu
topoloku strukturu, nije ni malo lak zadatak. Potrebno je izgraditi globalnu i verovatno vie
lokalnih raunarskih mrea, instalisati ENTERPRISE SERVER, vie APLICATION SERVER-a,
rasporediti i uvezati desetine i desetine radnih stanica (terminala, PS i druge raunarske
opreme).

Pre nego to se tehnologija instalira, neophodno je izvriti odreena testiranja. Sredstva koja
se koriste za potrebe testiranja su: Burn-in test i Site Preporation, Job accanting system
(sistemi za evidentiranje poslova), kontrola hardvera i softvera, korisnost performansi,
ergonomija.


2 2. .1 1 B Bu ur rn n- -i in n t te es st t

Kada je tehnologija ve odabrana, pre nego to je dobavlja isporui, poeljno je da
dobavlja simulira kontinuiran rad nekoliko nedelja. Burn-in test proverava elektronske
sisteme, prekidae, konektore, razliite komponente.
U
U







Implementacija informacionog sistema
559









Poto se ovaj test obavi, priprema smetaja tehnologije treba da je skoro kompletirana.
Izabrano mesto treba da zadovolji standardno okruenje, da osigura validno prihvatanje,
kada tehnologija stigne od dobavljaa.

Adekvatna mesta moraju biti obezbeena za svaki deo opreme i nametaja. Odgovarajui
kablovi, snabdevai, ventilatori, klima ureaji i druga oprema treba da se instaliu da bi se
obezbedilo odgovarajue i isto okruenje. Odgovarajui stolovi, kabineti, mesta za odlaganje
memorisanih medija, unapred moraju biti raspoloivi. Klima radnog mesta, sa stanovita
organizacije, buke, akustike mora imati zadovoljavajua reenja. Nametaj, radne povrine,
radno mesto, treba da su dizajnirani i reeni na odgovarajui nain. Odgovarajua priprema
radnih mesta omoguava brzo i lako instalisanje isporuene tehnologije.


2 2. .2 2 S Si is st te em m e ev vi id de en nt ti ir ra an nj ja a p po os sl lo ov va a

Ovaj sistem, kojim raspolau, vie-manje, svi vei i srednji raunari, moe biti veoma koristan
i efikasan za planiranje kapaciteta i testiranje efikasnosti. On moe da obezbedi veliku
koliinu test informacija o radnom okruenju raunarskog sistema. On obezbeuje
informacije ko, koliko dugo i kako pristupa bazi podataka, koliko su se efikasno realizovali
procesi i tome slino. Daje, takoe, podatke o korienju kapaciteta sistema u pojedinim
poslovima i obraunava trokove. Isporuioci opreme obezbeuju odgovarajui softverski
paket za ovu namenu.


2 2. .3 3 M Mo on ni it to or r h ha ar rd dv ve er ra a

Hardver monitor sadri senzore koji su povezani sa raunarskim elementima i sklopovima.
Meri aktivnosti CPU, ekiranje CPU, pretraivanje diskova, vri transfer podataka sa diska,
zauzee diska, aktivnosti trake, vremena i korienje operativne memorije. Senzori su
povezani sa malim raunarima koji zapisuju signale. Sa dovoljno statistike, odgovarajuim
vrednovanjem, budet svih raunarskih ureaja moe biti reduciran i unapreen putem
primene CPU, dropovanjem kanala ili rekonfiguracijom traka i diskova. Cilj je podesiti snage
raunara prema zahtevima informacionog sistema.


2 2. .4 4 M Mo on ni it to or r s so of ft tv ve er ra a

Da bi se procenile ukupne performanse sistema, softver monitor moe biti korien u
konjukciji sa hardver monitorom i sistemom evidentiranja poslova. Ovo je program koji je
smeten u raunaru da bi raunarski softver bio testiran. Softverske komponente koje se






560
Informacioni sistemi u menadmentu










mere su operativni sistem, softver podrke i aplikativni programi. Vrednovanjem operativnog
sistema identifikuju se neuspene sekcije koda. Postojanje takvih sekcija moe primorati
menadment da trai od dobavljaa da ga unapredi ili se drugi raspoloivi komercijalni
softver uzima kao mogua zamena.

Softver podrke spada u sivu zonu, izmeu korisnikog programa i operativnog sistema.
Mada se obrauje u sistemu slino korisnikim programima, on se pie od strane isporuioca
i pojavljuje kod regularnog korisnika kao deo operativnog sistema. Kompajleri,
komunikacioni i usluni programi su primeri ovog softvera. Cilj je zahtevati od isporuioca
da unapredi programe ukoliko ne zadovoljavaju ili da se ispitaju mogunosti alternativnog
softvera.

Softver za upravljanje bazama podataka je takoe predmet testiranja; da li je baza dovoljno
performantna u pogledu zadovoljenja zahteva korisnika, dovoljno velika, kako obavlja
procese unosa, auriranja, upita i autputa. U okruenju intenzivnih upita, testiranje SQL
povezanih naredbi je kritino. Sva ova povezivanja treba testirati sa podacima velikog obima,
i koji odraavaju realne transakcione procese. Znaajno je testirati pojave u bazi, nastale
prekidima nekih procesa. Kvalitet optimizatora je pojedinano najvanija komponenta
DBMS. Treba testiranjem ustanoviti njegovu sposobnost da obrauje efikasno spajanja,
testirati nivo senzitivnosti na uslove spajanja i povezivanja. Optimizatori visokog nivoa
koriste statistiku koja je memorisana u sistemskom katalogu da bi ustanovili najbolji nain
korienja indeksa. On moe vriti unapreenje performansi u procesu indeksiranja. DBMS
mora obezbediti integralnost podataka, testiranje multikorisnikog auriranja, upita sa END i
OR uslovima, testiranje transakcija tipa logging i obnove (recovery) i veeg broja korisnikih
programa koji se realizuju konkurentno. Visok nivo konzistentnosti i konkurentnosti
podataka su poeljni.

Aplikacije i korisniki programi se ocenjuju da bi se determinisalo korienje resursa i
efikasnost koda. Za svaki program se ocenjuju potrebni resursi, kao to su operativna
memorija, disk, traka, ocenjivanje u/i aktivnosti i slino.


2 2. .5 5 E Er rg go on no om me et tr ri ij ja a

Osoblje koje e koristiti tehnologiju, odnosno informacioni sistem, treba da ima komfor i
radna mesta ergonomski dizajnirana i izvedena. Najbolji nain da se testira radno okruenje,
jeste pustiti korisnika i operativni personal da radi sa sistemom, a potom ih posmatrati na
delu i periodino ih intervjuisati. Raditi nekoliko asova u loe dizajniranoj radnoj stanici i u
okruenju printera koji stvaraju buku, prouzrokovae napetost oiju, glavobolju, bolove u
leima i ramenima i nervne tenzije. Ako je ovo, primera radi, rezultat ergonomskog testa,






Implementacija informacionog sistema
561









redizajn treba odmah izvriti da bi se ublaili i olakali, ako ne eliminisali ovi i drugi loi
efekti.


3 3 O Ob bu u a av va an nj je e o os so ob bl lj ja a

Izvesne potekoe u implementaciji i korienju IS u obavljanju radnih zadataka nastaju
usled izostanka praenja (follow-up), procenjivanja i potpomaganja uspenijeg ponaanja na
radnom mestu. Ali, to praenje i potporu na radnom mestu bi trebalo posmatrati kao
sastavni deo obuavanja, a ne kao neto posebno i izdvojeno, i pri tom bi obuavanje trebalo
posmatrati celovito. Obuavanje podrazumeva poeljne funkcionalne promene u
vetinama, znanjima, stavovima ili socijalnom ponaanju. Pored toga, podrazumeva promene
u radnom ponaanju, to kao posledicu ima i promene radnog ponaanja i lake postizanje
ciljeva organizacije.


3 3. .1 1 P Pl la an ni ir ra an nj je e, , s sp pr ro ov vo o e en nj je e i i o oc ce en nj ji iv va an nj je e o ob bu u a av va an nj ja a

Proces obuavanja ukljuuje: (1) planiranje i oblikovanje obuavanja, (2) sprovoenje
programa obuavanja, (3) praenje i ocenjivanje efektivnosti i efikasnosti obuavanja radi
preduzimanja korektivnih akcija. Celovit proces obuavanja se moe grubo prikazati
shemom na slici 21-6.

Planiranje i oblikovanje obuavanja podrazumeva:

a) odreivanje ciljne grupe koju bi trebalo obuavati,
b) odreivanje sadraja koji bi lanovi grupe trebalo da ue i naue i
c) odreivanje naina na koji bi to trebalo da naue.

Odreivanje sadraja koji bi trebalo uiti i nauiti spada u odreivanje potreba za
obuavanjem koje se sprovodi:

1) Analizom radnih zadataka (metodi analize posla, metod kritinih incidenata i dr.) i
poeljnih oblika radnog ponaanja, da bi se zakljuilo koja su znanja i vetine potrebni za
uspeno obavljanje posla sa informacionim sistemom koji se uvodi;
2) Analizom osoblja i aktuelnog radnog ponaanja (testovima performanse, posmatranjem,
kontrolom kvaliteta, procenjivanjem. Informacije o potrebama za obuavanjem se
zakljuuju na osnovu razlike izmeu eljenog nivoa kompetentnosti osoblja i postojeeg
nivoa kompetentnosti toga osoblja.

Analizu potreba za obuavanjem mogue je obaviti dvojako:






562
Informacioni sistemi u menadmentu










a) ispitivanjem malog uzorka lanova ciljne grupe ili
b) ispitivanjem svih lanova ciljne grupe - to je pouzdanije, ali zahteva vie vremena i truda.

Slika 21-6

Identifikovanje POTREBA za
obuavanjem
Odreivanje
CILJEVA obuavanja
Definisanje KRITERIJUMA za
ocenjivanje uspenosti
obuavanja
Zakljuivanje potrebnog
SADRAJA (programa)
obuavanja
Oblikovanje potrebnih METODA i
MATERIJALA za obuavanje
IMPLEMENTACIJA
PROGRAMA OBUAVANJA
OCENJIVANJE
KOMPETENTNOSTI obuavanih
osoba i FOLLOW-UP















Osim toga potrebno je odreivanje ciljeva obuavanja, kriterijuma za ocenjivanje
uspenosti obuavanja i definisanje potrebnog sadraja obuavanje na osnovu razlike
izmeu potrebnih znanja i vetina za uspeno obavljanje posla i raspoloivih znanja i vetina
osoblja - lanova ciljne grupe.






Implementacija informacionog sistema
563









Odreivanje naina na koji bi trebalo nauiti ono to je potrebno, podrazumeva poznavanje
principa uenja, metoda obuavanja i na osnovu utvrenih individualnih razlika osoba koje
e biti obuavane, potrebno je oblikovati metode i materijale za obuavanje. Potrebno je
odrediti da li je za dati sadraj obuavanja prikladnije koncentrisano ili rasporeeno uenje.
Slinu odluku je potrebno doneti i kada je re o uenju celine ili uenju delova. Ta odluka
se donosi na osnovu teine zadatka koji treba nauiti. Organizacija zadatka se tie stepena
meusobne povezanosti podzadataka, a kompleksnost se tie teine pojednanih
podzadataka. Ako je organizovanost zadatka visoka a kompleksnost raste, onda je bolje
uenje celine, ali ako je organizovanost zadatka slaba, a kompleksnost raste, onda je bolje
uenje delova. Takoe je potrebno odabrati odgovarajui metod ili kombinaciju metoda
obuavanja. To mogu biti: predavanja, audiovizuelne tehnike, simulacije, metod sluaja,
instruisanje pomou raunara, konferencije, management games, sensitivity training i dr.
Izbor metoda je odreen ne samo sadrajem obuavanja nego i postavljenim ciljevima
obuavanja.


3 3. .2 2 S St ti ic ca an nj je e p po ot tr re eb bn ne e k ko om mp pe et te en nt tn no os st ti i o ob bu u a av va an nj je em m

Za ovaj zadatak je neophodno odrediti poetnu ponaajnu osnovu za svakog pojedinca, u
odnosu na koju e biti utvrivano napredovanje. Zatim sledi postavljanje ciljeva obuavanja
koji bi trebalo da budu jasno saopteni obuavanim osobama na poetku i na strategijskim
takama tokom obuavanja. Ciljevi bi trebalo da budu dovoljno teki (plodonosniji su teki i
specifini nego laki i opti). Tokom obuavanja konani cilj treba da bude upotpunjen
periodinim podciljevima. Obuavana osoba mora znati koje se specifino ponaanje oekuje
od nje, a potkrepljenje treba da bude povezano s tim ponaanjem. Potkrepljenje mora da
bude trenutno i kontinuirano. Potrebno je imati na umu da se efektivnost potkrepljenja
razlikuje od osobe do osobe. Neophodno je da obuavana osoba dobija znaajne povratne
informacije, da zna rezultate koje postie, jer oni usmeravaju i motiviu; bolje su opisne nego
ocenjivake povratne informacije, specifine nego opte, pravovremene nego odloene. Na
efektivnost povratnih informacija utiu: uestalost i vremenski raspored povratnih
informacija, pozitivna ili negativna priroda povratne informacije, specifinost, znaajnost
povratne informacije za cilj obuavanja, kredibilitet nastavnika i dr.

Praenje (follow-up) i ocenjivanje efektivnosti i efikasnosti obuavanja radi pruanja strune
potpore na radnom mestu i preduzimanja korektivnih akcija u obuavanju se podrazumeva.
Da bi se ocenile efektivnost i efikasnost, odnosno korisnost primenjenog programa
obuavanja, potrebno je meriti i procenjivati ishode obuavanja i dati odgovore na, bar
sledea pitanja:

a) da li se javila trajna promena radnog ponaanja,
b) da li je ta promena pozitivno povezana sa postizanjem postavljenih ciljeva organizacije,






564
Informacioni sistemi u menadmentu










c) da li zapaene promene doista potiu usled obuavanja i
d) da li se sline promene mogu oekivati kod novih polaznika kursa.

Ocenjivanje efektivnosti i efikasnosti obuavanja je u prvom redu odreeno postavljenim
ciljevima obuavanja i unapred odreenim kriterijumima uspenosti obuavanja. Ocenjivanje
efektivnosti obuavanja je lieno smisla ako se ne odnosi na postavljene ciljeve obuavanja.
Rezultati ocenjivanja bi trebalo da ukau da li se i u kojoj meri obuavanjem postiu
postavljeni ciljevi. Ocenjivanje uspenosti obuavanja se moe obaviti:

a) ispitivanjem mnenja (pomou upitnika, ek lista i sl.),
b) ispitivanjem rezultata uenja (npr. testovima postignua, "achievement test"),
c) ocenjivanjem radnog ponaanja (skalama procenjivanja, ek listama i dr.) i
d) ocenjivanje rezultata radnog ponaanja (kvalitet proizvoda, usluge i sl.).

Testovi postignua (testovi kojima se meri efekat specijalnog obuavanja) su vrlo podesni za
svrhe ocenjivanja uspenosti obuavanja, ali njihova izrada zahteva znatna ulaganja vremena i
rada. Grubo opisani zadaci u pravljenju testa postignua izgledaju ovako:

(1) Odreivanje funkcije testa (cilja kojem test slui);

(2) Odreivanje sadraja testa (1. Kategorije koje se tiu predmetnog sadraja i 2. Kategorije
procesa ili manipulisanje predmetnom materijom, npr.: a) zna osnovne izraze i pojmove, b)
ima "skladite" osnovnih injenica; c) razume smisao, svrhu, razloge i uslove primene
odreene procedure; d) razume principe i generalizacije; e) uspeno primenjuje principe i
generalizacije u novim uslovima; f) ume da pronae i protumai nove informacije; g) ume
ispravno da primeni odreenu tehniku, proceduru i da interpretira dobijene rezultate, h)
kritiki procenjuje vrednost dobijenih rezultata i raspoloivog materijala i sl.);

(3) Odreivanje osnovnog skupa (subjekata) kojem je test namenjen;

(4) Odreivanje tipa testa i stavki testa (papir-olovka, uzorak posla - "replika posla",
otvorene stavke, "objektivni testovi: stavke istinite ili lane, stavke viestrukog izbora",
stavke dopunjavanja);

(5) Odreivanje rasporeda ukupnog materijala (ukupnog broja stavki) testa postignua po
razliitim oblastima sadraja testa;

Kategorije
procesa
Kategorije predmetnog sadraja
1 2 3 4 5 6 7 Ukupno
A
B
C
D
E
F
G
Ukupno








100%






Implementacija informacionog sistema
565









(6) Odreivanje vremena za testiranje;

(7) Odreivanje tehnikih reenja (redosleda, lista za odgovore, uputstava, naina
ocenjivanja).

Praenje i ocenjivanje uspenosti primenjivanja obuavanjem nauenih znanja i vetina u
procesu rada na radnom mestu, obavlja se radi pruanja potrebne strune potpore osobi na
radnom mestu i radi preduzimanja potrebnih korektivnih akcija, da bi se postigli postavljeni
ciljevi obuavanja i efikasna primena novog informacionog sistema. Tu je re o (u nekom
smislu) nastavku obuavanja, ali se ono odvija s pojedincem na njegovom radnom mestu, pri
emu se tom pojedincu prua struna potpora (samo ako se uvidi da je neophodna) u
primenjivanju tokom obuavanja steenih (usavrenih) vetina i znanja prilikom reavanja
specifinih problema u procesu rada, sve dok reavanje tih problema ne bude prihvatljive
tanosti, efektivnosti i efikasnosti. Duina potrebnog vremena zavisi od prirode i obima
onoga to je ueno, od individualnih svojstava obuavane osobe (i osobe koja instruie), od
situacionih okolnosti i inilaca itd.


3 3. .3 3. . N Na a i in ni i o ob bu u a av va an nj ja a

Ciljevi obuavanja mogu se postizati na razliite naine. Neki od tih naina su ovi: (a)
seminar i grupne instrukcije, (b) proceduralni trening, (c) tutorijalni trening, (d) simulacija, (e)
trening "na poslu" i (f) informacioni centar.

Seminar i grupne instrukcije je nain obuavanja koji omoguava instruktorima da u isto
vreme i na istom mestu prue znanje veem broju ljudi. Veoma je efikasan u velikim
organizacijama, kada vei broj ljudi radi iste poslove i kada se vri prezentacija celovitog
informacionog sistema.

Proceduralni trening obezbeuje pojedinca pisanim materijalima koji objanjavaju kako se
neke aktivnosti obavljaju. Obino korisnici sistema imaju priliku da postavljaju pitanja i
dobijaju odgovore, da zauzmu stavove o problemima koje namee neka procedura, kako u
grupi tako i individualno.

Tutorijalni trening je individualni trening. Veoma efikasan i skup. U kombinaciji sa drugim
nainima, ovaj nain moe uspeno ukloniti bilo koju prazninu u znanju koja spreava
zadovoljavajue razumevanje sistema i njegovu primenu. U sistemu u kojem su pojedini
zadaci veoma kompleksni ili posebno vitalni i vani za uspeno funkcionisanje, tutorijalni
trening moe biti neophodan i nuan za postizanje eljenih rezultata.

Vana trening tehnika za operativni personal jeste simulacija radnog okruenja. Ovo
okruenje mora biti relativno lako kreirano. Sa reproduciranim podacima, procedurama i
zahtevanom opremom omoguava individuama da izvravaju pretpostavljene aktivnosti sve






566
Informacioni sistemi u menadmentu










dok se prihvatljivi nivo performansi ne postigne. Iako se simulacija ini skupim metodom,
manje greke i mnogo vei uinci se pojavljuju kao dobar razlog njene este primene.

Trening "na poslu" je metod uenja rada na novom informacionom sistemu, koji se
najee koristi za trening operativnog osoblja. Obino ovo osoblje izvrava jednostavne
zadatke i nije teko dati specifine instrukcije o tome ta i kako se neto radi. Kada se
savladaju neki prvi poetni zadaci, ide se na uenje zadataka koji se dodaju, sve do konanog
cilja. Kriva uenja u ovom pristupu moe biti veoma uzlazna, ali ta pojava i verovanje da je
neko savladao nain rada i da moe produktivno da radi, moe biti vrlo varljiva. Ako su
pojedine operacije kompleksne i teke za savladavanje, rezultati uenja mogu biti skromniji,
postati frustrirajui i zahtevati novi trening.

Informacioni centar je efektivan nain treninga i voenja korisnika, istrajavanja i
obezbeivanja odgovarajue podrke. Stavovi osoblja informacionog centra treba da budu
"ta moemo da uinimo da ti pomognemo?". Oni mogu napraviti veoma brzo uvodni kurs
ili demonstraciju aplikacije, obezbediti individualni trening, pomoi korisnicima da primene
posebne softverske pakete za specifine poslovne probleme, karakteristine case sluajeve
koji pokrivaju probleme IS i aplikacija, do okruenja workshop treninga i seminara. Cilj
informacionog centra je ohrabrivanje korisnika da proiruju i poveaju korist i usluge IS, i da
na adekvatan nain pokau kako korisnici mogu reavati sopstvene probleme.


3 3. .4 4 K Ko og ga a t tr re eb ba a o os sp po os so ob bl lj ja av va at ti i? ?

Dve kategorije personala organizacije moraju prihvatiti trening i edukaciju: korisnici i
operativno osoblje. U kategoriju korisnika spadaju menaderi, specijalisti i osoblje u
razliitim funkcionalnim oblastima, kao to su planeri, komercijalisti, raunovoe, planeri i
organizatori u proizvodnji i drugi. Ovo osoblje mora, pre svega, da bude dobro upoznato ta
informacioni sistem zahteva i ta obezbeuje. Edukacioni proces za mnoge lanove ovih
grupa stvarno poinje jo u fazi strategijskog informacionog planiranja, jer oni uestvuju u
koncipiranju informacionog sistema, a nastavlja se u fazi analize, kada su identifikovane
njihove informacione potrebe. Osnovna svrha edukacije u fazi implementacije sistema jeste
razjanjenje i instruisanje kako njihove informacione zahteve sistem moe da zadovolji.

Operativno osoblje je trening kategorija koja ukljuuje sve individue koje uestvuju na
pripremi i obradi podataka i odravanju logikih i fizikih komponenti sistema. U ovu grupu
spada i ono osoblje koje je odgovorno za direktnu kontrolu sistema. Mi nazivamo ovaj oblik
edukacionog procesa "trening". Trening operativnog osoblja ima dve dimenzije koje moraju
biti razmatrane. Prvo, operativno osoblje mora biti podvrgnuto treningu sve dok novi sistem
ne pone da efektivno i efikasno radi. Drugo, trening mora biti proces koji se kontinuirano
obavlja; sistem se menja, modifikuje, unapreuje, osoblje se menja, razmeta, novo se
angauje.






Implementacija informacionog sistema
567









4 4 K Ko on nv ve er rz zi ij ja a i i u uv vo o e en nj je e i in nf fo or rm ma ac ci io on no og g s si is st te em ma a

roces konverzije, zamene informacionog sistema znai staviti sistem "na promaju",
pustiti ga u ivot. Proces preobraenja starog informacionog sistema u novi je sloen,
teak, osetljiv, intenzivan kolizijama, latentnim i otvorenim otporima, te ga je stoga
neophodno paljivo planirati i realizovati jednim ili kombinacijom vie pristupa. U literaturi
se, najee, raspravlja, a u praksi primenjuju, sledea etiri pristupa: (a) direktni, (b) paralelni,
(c) modularni i (d) fazni. Slika 21-7 ilustrativno i a priori prikazuje logiku i ukazuje na sutinu
ovih pristupa.

Slika 21-7

Stari sistem Stari sistem Novi sistem
Stari sistem Novi sistem Novi sistem
Modularna konverzija Fazna konverzija
Stari
sistem
Novi
sistem
Direktna konverzija
Stari sistem Novi sistem
Paralelna konverzija
Stari sistem
Novi sistem















4 4. .1 1 D Di ir re ek kt tn na a k ko on nv ve er rz zi ij ja a

Direktna konverzija je, u stvari, zamena starog sistema novim, na tano odreen termin.
Ovaj oblik konverzije, uvoenja i prihvatanja IS je najjednostavnije sprovesti, zahteva mali
vremenski utroak i ima najnie trokove. Loa strana ovog naina uvoenja novog sistema
je visok rizik od moguih greaka. Najee se preduzima ovakav pristup ako je novi sistem
imao rigidno testiranje, veoma temeljito obuavanje osoblja, apsolutno je razliit od
prethodnog i nije previe sloen, odnosno, stari sistem je izgubio poeljne performanse i
vrednosti.


4 4. .2 2 P Pa ar ra al le el ln na a k ko on nv ve er rz zi ij ja a

Paralelna konverzija podrazumeva funkcionisanje starog sistema i njegovu upotrebu sve dok
se u potpunosti novi sistem ne konsolduje i proveri. Ovaj pristup garantuje potpunu
sigurnost i zatitu, jer se tokom nekog perioda, oba sistema simultano koriste. Ovo je
P
P







568
Informacioni sistemi u menadmentu










potpuno divergentan pristup u odnosu na direktnu konverziju. Korisnici prate uinke, vre
komparaciju i utvruju razlike izmeu sistema. Prednost ovog pristupa konverzije se uoava
u obezbeivanju visokog nivoa zatite organizacije od greaka koje moe proizvesti novi
sistem. Jasno je da su nedostaci ovog pristupa, pre svega, u poveanim trokovima
implementacije, zahtevnijim resursima i potrebama u personalu koji odravaju oba sistema.
Pored svega, u praksi je ovaj prilaz, za mnoge organizacije prihvatljiv i esto se koristi.


4 4. .3 3 M Mo od du ul la ar rn na a k ko on nv ve er rz zi ij ja a

Modularna konverzija je pristup sukcesivne zamene starog sistema novim. Naime, stari
sistem ne moe biti zamenjen trenutno i u celini, nego se zamena vri tako to se jedan
podsistem, odnosno, modul starog sistema zamenjuje odgovarajuim novim IS i ceo proces
traje relativno dui vremenski period. U funkciji su neko vreme delovi i jednog i drugog
informacionog sistema. esto se ovaj pristup naziva i "pilot pristup". Na primer, moemo
neki informacioni podsistem ili modul starog sistema zameniti u nekom departmentu ili
regionu sa podsistemom ili modulom novog sistema, pa tek nakon njegove eksperimentalne
primene njegovo uvoenje iriti u drugim delovima organizacije. Prednosti ovog pristupa se
ogledaju, pre svega, u lokalizaciji rizika od moguih greaka, problemi identifikovani u
sistemu mogu biti otklonjeni pre nego se u potpunosti implementira, operativni personal
moe biti edukovan u "ivom" okruenju i pre nego to sistem bude u potpunosti
implementiran. Nedostatak ovog pristupa je u ekstremno dugom trajanju procesa konverzije.


4 4. .4 4 F Fa az zn na a k ko on nv ve er rz zi ij ja a

Pristup fazne konverzije je slian modularnom pristupu, ali postoje i znaajne razlike. Na
primer, moemo uvesti postupke i reenja aktivnosti kolektiranja podataka i uspostaviti
mehanizam interfejsa sa starim sistemom. Ovakav interfejs omoguava da stari sistem
funkcionie sa novim inputom podataka. Kasnije se aktivnosti memorisanja, pristupa i
pretraivanja podacima novog IS u potpunosti implementiraju. Vremenom se novi segmenti
dodaju i sukcesivno se razvija interfejs sa starim sistemom. Prednost ovog pristupa je u
injenici da se organizacione promene mogu minimizirati i resursi obrade podataka mogu biti
razvijani i proirivani tokom vremenskog perioda. Nedostaci su u poveanim trokovima
ulaganja i due vreme razvijanje interfejsa sa starim sistemom, esta demoralizovanja
atmosfere u organizaciji i formiranje stava "nikad neemo kompletirati sistem".