U ovu se fazu ide kada je plan razvoja informacionog sistema usvojen.

Analiza sistema

Analiza sistema (sistemska analiza) je raščlanjivanje sistema na njegove komponente da bi se proučilo kako te komponente rade i međusobno komuniciraju. Nakon analize sistema sledi sinteza sistema i razvoj aplikacija. Sinteza sistema je ponovno objedinjavanje komponenti u celoviti, poželjno poboljšani, sistem.

Analiza sistema je: (1) razmatranje i planiranje sistema i projekta, (2) proučavanje i analiza postojećeg poslovnog i informacionog sistema, te (3) definisanje poslovnih zahteva i prioriteta novog ili poboljšanog postojećeg sistema .
Aktivnosti analize se mogu sistematizovati u tri nivoa, gde svaki nivo traži odgovor na odgovarajuća pitanja:

  1. Detaljna analiza postojećeg sistema, te utvrđivanje potreba i zahteva: Kako radi postojeći sistem?, Na koji način korisnici koriste sistem da bi obavili svoj posao?, Koji su problemi pri korišćenju aplikacija?
  2. Detaljna specifikacija zahteva za informacioni sistem: Koji su podaci potrebni?, Ko ih treba?, Kada?, Od koga?, Ko ih stvara?, Koji su izlazni podaci?, Kakav im je oblik?, Koji su izvori izlaznih podataka?, Na koji način se podaci prikupljaju i objedinjuju?
  3. Daljnja razrada granica projekta.

Pozadinska analiza treba da pomogne razumevanju strukture organizacije, ko u njoj radi, ko je kome potčinjen, kako sarađuju različiti sektori, itd. Za potrebe pozadinske analize može se izraditi shema organizacione strukture iz koje će biti vidljivo koja osoba ili grupa ljudi obavlja koji dio posla (modeliranje funkcija). Za ostale elemente, takođe, se rade odgovarajući modeli (modeliranje procesa, modeliranje podataka)


Dodatni materijal za čitanje (opciono):


Za one koji žele da znaju malo više, u nastavku su objašnjeni vrste zahteva, na koji način se određuje prioritet između različitih zahteva koje bi informacioni sistem trebalo da zadovolji, koje su ključne aktivnosti i učesnici u analizi, kao i načini prikupljanja informacija. Obratite pažnju na to koji su najčešći problemi pri prikupljanju informacija.


Definisanje zahteva koje sistem mora posedovati


Zahtevi ne sadrže detalje dizajna, detalje implementacije ili informacije vezane uz planiranje projekta. Pažnja se usmerava na ono ŠTA se želi izgraditi, a ne ulazi se u detalje kako i kada to napraviti.

Za 40 do 60% grešaka u projektu uzrok leži u greškama napravljenim u fazi postavljanja zahteva. Tipična posledica su "prazna očekivanja", razlika između onog što očekuje naručilac i onoga šta je izvršilac mislio da treba napraviti. Naknadne prepravke mogu predstavljati do 40% troškova razvoja. Nepotpuno definisani  zahtevi čine nemogućim planiranje projekta i praćenje promena.


 Vrste zahteva

Zahtevi mogu biti:

  • poslovni zahtevi (zašto),
  • korisnički zahtevi (zahtevi krajnjih korisnika),
  • funkcionalni zahtevi (šta) ili
  • nefunkcionalni zahtevi (kako ili kako dobro).

Poslovni zahtevi definišu ciljeve organizacije, odnosno daju opis problema koje treba rešiti (npr. poslovna potreba "Poboljšanje usluge postojećim klijentima i pridobijanje novih") ili su sadržani u dokumentima u kojima se opisuje vizija i opseg projekta (npr. poslovni zahtev "Omogućiti Internet prodaju").

Korisnički zahtevi (zahtevi krajnjih korisnika) opisuju zadatke koje korisnik mora da može da obavi služeći se aplikacijama ili koji su sadržani u opisima slučajeva korištenja, tj. opisima scenarija rada.

Funkcionalni zahtevi (šta) definišu očekivano ponašanje i operacije koje sistem može izvoditi, odnosno softversku funkcionalnost koju treba ugraditi u proizvod da bi omogućio korisnicima obavljanje njihovih zadataka. U ovu grupu zahteva spadaju posebno zanimljive mogućnosti programa, odnosno skup logički povezanih funkcionalnih zahteva koje korisniku omogućavaju ispunjavanje poslovnih zahteva.

Nefunkcionalni zahtevi (kako ili kako dobro) su standardi, pravila i ugovori koje proizvod mora zadovoljiti, opisi vanjskih interfejsa, zahtevi za performansama, ograničenja za dizajn i implementaciju, te osobine kvaliteta koje preciziraju opis proizvoda navodeći karakteristike proizvoda u različitim dimenzijama, a bitne su ili korisniku ili projektantu.
Potrebno je još naglasiti da je potrebno odrediti prioritetete pojedinih zahteva.


Određivanje zahteva

Poslovni zahtevi: Sve što opisuje finansijski, trgovački ili drugi poslovni prodor koji korisnici, ili organizacija koja razvija sistem, mogu dobiti je, najvjerovatnije, poslovni zahtev.

Slučajevi korišćenja ili scenariji: Opšte izjave o korisničkim ciljevima ili poslovnim zadacima, koje korisnici moraju obavljati, najvjerovatnije su slučajevi korišćenja, dok specifični opisi zadataka predstavljaju korisničke scenarije.

Poslovna pravila: Kada korisnik izjavi da neku aktivnost mogu obavljati samo pojedine osobe ili uloge, pod određenim uslovima, on možda opisuje poslovno pravilo. Poslovna pravila nisu funkcionalni zahtevi.

Funkcionalni zahtevi: Izjava koja počinje sa „Korisnik mora moći da obavi neku funkciju”, ili „Sistem treba moći da demonstrira određeno ponašanje” je najverovatnije funkcionalni zahtev. Funkcionalni zahtevi opisuju vidljivo ponašanje sistema i definišu šta će sistem raditi. Treba svima biti jasno zašto sistem „mora” biti u stanju da obavlja određene funkcije. Predloženi funkcionalni zahtevi ponekad predstavljaju zastarele ili neefikasne poslovne procese koji ne trebaju biti uključeni u novi sistem.

Atributi kvaliteta: Izjave koje opisuju kako dobro sistem obavlja funkciju su atributi kvaliteta, tj. jedna vrsta nefunkcionalnih zahteva. Zahteve koji opisuju poželjne karakteristike sistema: brzinu, jednostavnost, intuitivnost, robustnost, pouzdanost, sigurnost i efikasnost treba razmotriti sa korisnicima, da bi se precizno utvrdilo šta oni misle pod tim dvosmislenim i subjektivnim terminima.

Zahtevi spoljnih interfejsa: Ova klasa zahteva opisuje veze između sistema i spoljnjeg sveta. Ovo treba da uključuje i interfejse i mehanizme komunikacije za korisnike, hardver i druge softverske sisteme.

Ograničenja su uslovi koji ograničavanju izbor rešenja raspoloživih dizajneru ili programeru. Spadaju u nefunkcionalne zahteve i trebaju biti dokumentovani. Neopravdana ograničenja treba pokušati odbaciti jer onemogućavaju postizanje najboljeg rešenja. Takođe, mogu umanjiti primenu komercijalnog softvera i komponenti u rešenju. Neka ograničenja mogu pomoći u zadovoljavaju atributa kvaliteta. Primer je poboljšanje prenosivosti programa korištenjem samo standardnih naredbi nekog programskog jezika.

Definicija podataka je bilo koji opis formata, dozvoljenih vrednosti, pretpostavljenih vrednosti ili kompozicija složenih struktura podataka. Sve definicije treba čuvati u nekoj vrsti Rečnika podataka, kao glavni orijentir za učesnike na projektu.

Ideje o rešenju: Ako korisnik opisuje specifičan način interakcije sa sistemom, kojom bi mogao obaviti neku akciju, npr. „Korisnik odabira podatak koji želi iz padajuće liste”, on predlaže rešenje, a ne zahtev. Predloženo rešenje može odvući pažnju od pravih zahteva. Kod postavljanja zahteva treba se usmeriti na ono što je potrebno obaviti, a ne na način realizacije. Treba istražiti zašto korisnik predlaže određenu ugradnju, jer to može pomoći u razumevanju stvarne potrebe i korisnikovih očekivanja o načinu kako sistem treba da radi.

Postavljanje prioriteta zahteva

Nužno svojstvo sistema nameće pitanje: Da li vlasnik sistema nešto stvarno mora imati? Postoji tendencija da se previše zahteva proglasi nužnim! Po definiciji, ako sistem ne uključuje nužne zahteve, taj sistem ne može ispuniti svoju svrhu. Treba testirati svaki zahtev koji se smatra nužnim i probati ga rangirati. Ako se zahtev može rangirati onda nije obavezan. Potpuno obavezni zahtevi se ne mogu rangirati, jer su nužni za prvu verziju sistema.

Poželjno svojstvo sistema su funkcije koje korisnik želi na kraju da ima. Ranije verzije sistema mogu pružiti (ne potpunu) funkcionalnost bez tih zahteva. Poželjni zahtevi mogu i trebaju biti rangirani.

Neobvezna svojstva sistema su proizvoljni zahtevi, svojstva i mogućnosti bez kojih se može, iako bi bilo lepo da se imaju. To nisu pravi zahtevi. Ovi zahtevi, takođe, mogu biti rangirani.


Dokumentovanje analize zahteva

Kratke definicije zahteva glase: (1) izjava o stanju, ograničenjima i potrebama sistema, (2) narativni dokument namenjen korisniku, ili ga piše korisnik, a sačinjavaju ga poslovni i korisnički zahtevi, kao i njihovi prioriteti, uočeni problemi, ključne pretpostavke i preporuke za njihovo rešavanje.

Specifikacija zahteva, često nazvana i funkcionalnom specifikacijom, je strukturirani dokument sa detaljnim opisom očekivanog ponašanja sistema. Namenjen je ugovaračima i izvršiocima razvoja. Predstavlja celoviti i nezavisan pogled na sistem. Sačinjavaju ga funkcionalni i nefunkcionalni zahtevi te njihovi prioriteti, model organizacione strukture (strukturirani dijagrami), opis toka dokumenata (dijagrami toka), model procesa (dijagrami toka podataka), kao i konceptualni model podataka (dijagrami entiteti - veze).


Uzroci lošeg planiranja zahteva

Nedovoljna uključenost korisnika: Bez korisnika se ne može tačno znati šta korisnici žele. Takvi proizvodi su neprihvatljivi.

Čudni korisnički zahtevi: Neopravdana promena mišljenja tokom izvedbe uzrokuje prekoračenje predviđenog roka za realizaciju, kao i degradaciju kvaliteta proizvoda.

Nejasni (dvosmisleni) zahtevi: Situacija u kojoj onaj ko je dobio zahtev može da ga tumači na više načina. To uzrokuje prepravljanje i gubljenje vremena.

Preterano ukrašavanje: Želja izvođača da dodaju novu funkcionalnost "koja treba da se svidi korisnicima" i zahtev korisnika za dodacima koji dobro izgledaju ali ne pridonose funkcionalnosti. Izrada takvih dodataka je nepotrebna i predstavlja gubljenje vremena.

Minimalističke specifikacije: Tendencija postavljanja minimalnih zahteva ili skiciranja koncepata, uz želju da ih izvođači nadopune tokom izvedbe, izaziva frustracije izvođača i neispunjena očekivanja korisnika.

Zanemarivanje potreba: Zanemarivanje potreba određenih (grupa) korisnika izaziva stvaranje „opozicije“ projektu.

Svojstva dobro postavljenih zahteva

Svojstva dobro postavljenih korisničkih zahtjeva su definisana IEEE standardom [1998]. Ta svojstva su: potpunost, tačnost, ostvarivost (izvodljivost), nužnost, poredak po prioritetima, nedvosmislenost i mogućnost provere.

Dobra specifikacija zahteva korisnika mora da sadrži sledeća svojstva: potpunost, konzistentnost, mogućnost izmene i mogućnost praćenja. Cilj je napisati dovoljno dobre zahteve, na osnovu kojih se može pristupiti dizajnu i ugradnji pojedinih komponenata sistema, uz prihvatljiv stepen rizika.


Ključne aktivnosti i učesnici


Korisnik (korisnik usluga, klijent, osoba ili grupa za koju se gradi informacioni sistem) - podrazumeva korisnika sistema i vlasnika sistema. Korisnik sistema (krajnji korisnik) - neposredno koristi informacioni sistem pri obavljanju svakodnevnih poslova ili koristi informaciju dobijenu iz njega. Vlasnik sistema (naručilac, stvarni vlasnik ili predstavnik uprave) - naručuje i plaća razvoj i održavanje sistema, postavlja prioritete i određuje politiku njegovog korištenja;

Projektant (dizajner sistema) - tehnički stručnjak koji oblikuje sistem tako da zadovolji zahteve korisnika, prevodi poslovne zahteve i ograničenja u tehničko rešenje, oblikuje datoteke, baze podataka, ulaze, izlaze, forme na ekranu, mrežu i programe, integriše rešenje, a može biti i graditelj sistema;

Graditelj sistema (programer, projektant, stručnjak koji izgrađuje sistem) - proverava njegovu ispravnost te ga isporučuje u primenu, konstruiše komponente sistema na osnovu specifikacija koje rade dizajneri sistema.

Sistem analitičari - razumeju i poslovanje i računarsku obradu podataka. Njihov zadatak je da provode sistemsku analizu i dizajn. Povezuju one koji trebaju računar i one koji poznaju informacione tehnologije (IT). Formalna definicija [Whitten et. al, 2000] sistem analitičara glasi:

Sistem analitičar pomaže proučavanju problema i potreba poslovanja radi određivanja kako poslovni sistem i informaciona tehnologija mogu najbolje rešiti problem i postići unapređenje poslovanja. Plodovi ove aktivnosti su poboljšani poslovni procesi, poboljšani informacioni sistemi te nove ili poboljšane aplikacije, a često sve zajedno.

Sistem analitičar je istraživač, arhitekta i kontrolor, rešavalac poslovnih problema, zagovornik promena, psiholog, trgovac, političar. Većina sistem analitičara koristi specifičnost pristupa, koja se naziva životni ciklus razvoja sistema, odnosno sistematičan i metodičan pristup rešavanju problema sistema.


Definisanje zahteva za informacionim sistemom


Ključne aktivnosti

Ključne aktivnosti, koje se mogu izdvojiti u definisanju zahteva za informacionim sistemom, su prikupljanje informacija, prikupljanje podataka i ustanovljavanje činjenica.


Prikupljanje informacija

Jedna od aktivnosti kod definisanja zahteva za informacionim sistemom su intervjui sa ključnim korisnicima i radne sednice. Ako naručilac zapošljava informatičare svakako ih treba uključiti u analizu. Suočavanje korisnika i informatičara ubrzava rešavanje protivrečnih iskaza. Kao zamena za intervjue koriste se upitnici i ankete, koji su pogodni i za prikupljanje informacija o resursima. Analiza dokumentacije je u stvari prikupljanje celokupne dokumentacije značajne za poslovanje, radi boljeg utvrđivanja pravila, poslovne politike, ciljeva poslovanja i strukture informacija.

Potrebno je oceniti kakve su postojeće aplikacije i/ili računarom podržani podaci, radi analize podataka, ali i zbog njihove konverzije u novi sistem. Posmatranje, odnosno neposredni uvid u poslovne procese posmatranjem radnih sredina (način izrade i razmene dokumenata, procesi osnovne delatnosti), je značajan vid definisanja zahteva za IS. Postupak analize mora biti prilagođen korisniku.


Postupak intervjuisanja

Intervju mora biti neusiljen i elastičan razgovor sa ispitanikom u obliku niza pitanja i odgovora. Ispitanik se pojavljuje u ulozi pasivnog sagovornika. Sagovornici su rukovodioci, krajnji korisnici i ostali učesnici iz poslovnog sistema. Standardno uključuje dva sagovornika, ali može i više, i to korisnika i ispitivača. Individualni intervju je kada učestvuje jedan korisnik, ili učesnici koji rade isti posao, dok je intervjuisanje grupe kada se razgovara sa više korisnika iz različitih područja.

Informacije se prikupljaju nizom pojedinačnih razgovora. (Prve) razgovore treba voditi prema unapred dogovorenom planu i rasporedu, što treba da obezbedi koordinator intervjua.

Postupak intervjua je spor i neefikasan, jer se organizacija razgovora mora obaviti za svaki pojedini razgovor. Nakon završetka analize i sinteze dobijenih informacija, neke razgovore (ponekad i čitavu seriju) treba ponoviti da bi se upotpunile dobijene informacije ili uskladili protivrečni iskazi. Ukupan broj razgovora ne može se unapred tačno odrediti i treba ga prilagoditi stvarnoj situaciji.


Tehnika intervjuisanja

Priprema za razgovor treba da sadrži utvrđivanje informacija koje treba saznati, proučavanje postojeće dokumentacije i prethodnih nalaza, određivanje dokumentacije koju treba prikupiti i priprema pitanja koja će biti postavljena tokom razgovora.
Priprema pitanja podrazumeva izradu standardnih pitanja, i izradu sveobuhvatnog potsetnika i izdvajanje prikladnih pitanja.

Mogući plan i obavljanje razgovora može da se odvija na sledeći način:
  1. Trajanje prvog razgovora je 2 sata (okvirno 1,5 do 2,5 sata);
  2. Početak razgovora, koji sadrži predstavljanje učesnika i upoznavanje sa svrhom razgovora (prikupljanje informacija o … );
  3. Vođenje razgovora, odnosno postavljanje pitanja i zapisivanje odgovora, prikupljanje dokumentacije, ...
  4. Završetak razgovora je približno 5 do10 minuta pre isteka planiranog vremena. Prekida se redosled postavljanja pitanja, proverava se da li postoji nešto što je sagovornik htio reći a nije bilo pitano, proverava se da li treba proširiti krug sagovornika, dogovara se nastavak razgovora (dopunski razgovor) kada voditelj razgovora nije postavio sva planirana pitanja ili smatra da je razgovor nametnuo nova pitanja;
  5. Zahvala na razgovoru.

Preispitivanje i pojašnjenje sadržaja se sastoji od provera zapisanih navoda radi upotpunjavanja beleški: telefonom, elektronskom poštom ili novim sastankom.
Dokumentovanje razgovora sačinjavaju:

  • Samostalno pisanje zapisnika (“Ko ne razume, ne može zapisivati.”). Kada u razgovoru sudeluje više analitičara, određuje se voditelj razgovora koji je ujedno i zapisničar, a ostali ulažu primedbe;
  • Zapisnik treba da sadrži: naziv projekta, vreme i mesto održavanja razgovora, spisak učesnika, sadržaj razgovora (tekst zapisnika), popis prikupljene dokumentacije i ime zapisničara;
  • Zapisnik mora sadržavati ono što je rečeno i slediti tok razgovora;
  • Zapisnik ne sme nametati zaključke, jer su oni rezultat analize.

Autorizacija (overa) zapisnika se vrši tako da se zapisnik dostavlja na uvid sagovorniku, koji potvrđuje verodostojnost zapisnika. Po potrebi sagovornik može nadopuniti delove za koje smatra da nisu evidentirani ili pojasniti delove za koje misli da su pogrešno protumačeni.


Preporuke za vođenje intervjua

Tokom vođenja intervjua treba pitati o svemu što se smatra važnim. Ništa nije samo po sebi razumljivo i svima jasno. Ne pretpostavljati da se unapred zna o čemu se radi. Repertoar i vrste pitanja može biti sledeći:

  1. Pitanja zatvorenog tipa: Koliko ... obrađujete (u nekom razdoblju)?, Na koji način obrađujete ... ?;
  2. Pitanja otvorenog tipa: Što mislite o ... ?, Koji su najveći problemi ... ?;
  3. “Probna” pitanja: Zašto?, Možete li navesti primer za takvu situaciju?, Molim detaljnije objašnjenje za ....

Analizom odgovora se razdvajaju činjenice od mišljenja, utvrđuje se da li pojedine činjenice odgovaraju drugima, analiziraju činjenice koje se ne poklapaju i vrši provera odgovora različitih sagovornika na isto pitanje.
Preporučuje se sledeće ponašanje:

  • iskrenost i nepristranost (cilj je naći za korisnika najprikladnije rešenje, a ne naturati određeno programsko rešenje ili računarsku platformu),
  • pažnja i jezgrovitost tj. “brzo misli, jasno govori”,
  •  izbegavanje sugestivnih pitanja,
  •  nenametanje zaključaka i ležernost (plus praćenje reakcija sagovornika).
Grupno intervjuisanje je potrebno izbegavati i po potrebi nadoknaditi radnim sednicama. Ovu vrstu intervjuisanja kao izuzetak treba provesti kada se želi utvrditi zajednički interes ili protivrečnost.


Upitnici i ankete

Upitnik je, u suštini, pismeni intervju. Sadrži pitanja koja se postavljaju tokom razgovora (okvirno 20 pitanja). Može se dostaviti korisniku pre ili nakon intervjua. Nedostaci upitnika su sledeći: ispitanik može prilagoditi (kontrolisati) svoje odgovore, teško je proceniti iskrenost (spontanost) odgovora, a može i obeshrabriti ispitanika.

Anketa može da obuhvatiti više ispitanika. Pitanja su zatvorenog tipa, a odgovori i obrada odgovora mogu se standardizovati. Pogodna je za popis resursa.

Na osnovu navedenog, može se zaključiti da je intervjuisanje najelastičnije! Pomoću intervjua se može više naučiti o stavovima, osećajima i motivaciji osoblja. Tokom intervjua analitičar i ispitanik se nalaze jedan nasuprot drugom, pa analitičar može posmatrati način na koji ispitanik odgovara i po potrebi proširiti ili usmeriti pitanja.


Proučavanje dokumenata

Prikupljaju se svi dokumenti do kojih se može doći. U prvom redu treba prikupiti dokumente koji su nastali kao rezultat analize procesa, tipične dokumente (pravilnici, zakoni, obrasci, izvještaji) i dokumente nastale analizom podataka. Poželjno je da dokumenti budu reprezentativni, tj. popunjeni na tipičan način (tako se može ustanoviti koje informacije se unose i na koji način). Reprezentativni dokumenti najčešće ne ukazuju na izuzetke, to jest podatke koji se ređe beleže, ali ipak trebaju. Stalno beleženje nekih podataka ne mora značiti da su ti podaci stvarno potrebni. Treba prikupiti više uzoraka iste vrste dokumenta!

Vrednost informacija o analiziranoj organizaciji prikupljena (samo) preko dokumenata je niska. Praksa može odudarati od pravilnika i administrativnih obrazaca. Treba shvatiti zašto i kada dokumenti nastaju, kako se popunjavaju, koliko su potrebni, te šta treba promeniti da bi se popravili (sadržaj, lakoća popunjavanja i čitanja). Nužno je modele (podataka), razmatrane analizom, proveriti kod korisnika.


Evidencija i analiza postojećih aplikacija

Budući da su nedostaci opreme, podrške i podataka najčešći razlozi za izgradnju novog informacionog sistema, potrebno ih je evidentirati i analizirati. Vrši se procena aplikacija i (baza) podataka u primeni, i to: korišteni programski jezici i alati, uključujući programe za kancelarijsko poslovanje (npr. Excel), podržane funkcije i način opsluživanja programa, međusobna povezanost različitih aplikacija i podataka, postojeće platforme (računari, operativni sistem, mreža, SUBP), kao i sastav i stepen informatičke obučenosti korisnika.

Analiziraju se nedostaci sistemske opreme i programske podrške. U prvom redu se analizira nepovezanost aplikacija (tzv. informatička ostrva), loša programska rešenja (funkcionalnost, ergonomija), nepouzdanost, integritet, zaštita i sigurnost podataka. Takođe se analizira nepostojanje programske dokumentacije, tehnološka zastarelost (programski jezici i alati, nemogućnost rada u višekorisničkom okruženju, grafički interfejs).


Posmatranje poslovnog sistema

Definisanje zahteva za informacionim sistemom se može dopuniti uvidom u poslovne procese, odnosno posmatranjem radnih sredina. Posmatra se lokacija i kretanje ljudi, tok izvršavanja poslova, fizički ulazi i izlazi sistema, preuzimanje, izrada i razmena dokumenata, procesi osnovne delatnosti, npr. proizvodnje. Prednost ovakvog pristupa je u tome što je analitičar u stanju da realno sagleda poslovni proces. Ovaj pristup je efikasan, ako se dobro provede, i obezbeđuje pouzdanost prikupljenih informacija. Nedostaci posmatranja poslovnog sistema su neefikasnost, ako se dobro ne provede, znatan utrošak vremena, ometanje i nelagodnost posmatranih osoba, mogućnost manipulacije posmatrača, npr. prikrivanjem uobičajenog kršenja radnih procedura.

Podaci dobijeni iz malog broja kratkotrajnih posmatranja mogu biti nepouzdani i netačni. Posmatranje na licu mesta je najteža metoda za utvrđivanje činjenica.

(Analiza sa ciljem automatizacije poslovnih procesa omogućava razumevanje  postojećeg sistema, ekstenzivno prikupljanje informacija i zahteva, kao i oblikovanje procesa i podataka. Osim toga, omogućava uočavanje mogućih poboljšanja (ako nije učinjeno ranije), analizu problema, odnosno identifikovanje problema, ustanovljavanje željenih poboljšanja, kao i analizu i traženje uzroka problema i prioritete njihovog rešavanja.)

Radni sastanci

Radni sastanci (sednice) se organizuju da analitičari i korisnici zajednički provode analizu i oblikovanje. Cilj sednice je (zajedničko) pronalaženje najboljeg rešenja. Za to je potreban poseban prostor i izolacija, moderator, dnevni red i zapisnici.

Genijalnost grupe se koristi za prikupljanje ideja i definisanje informacionih potreba. Izvodi se tako da se od svakog ispitanika iz grupe traži da definiše svoj pogled na idealno rešenje. Svaki učesnik iznosi sve što mu pada na pamet u vezi sa problemom koji se rešava. Od predloženih rešenja odabira se najbolje prema realnoj izvodljivosti. Postupak je koristan tamo gde postoje korisnici koji dobro poznaju sistem, ali teško prihvataju nove ideje.

Prednosti radnih sednica su njihova pogodnost za projekte kojima se rešavaju problemi važni za celi poslovni sistem ili veći dio poslovanja. Njihovim organizovanjem se izbegavaju specifični (egzotični) i nejasni zahtevi, preciznije se ustanovljava doseg projekta i bolje uočava protivrečnost zahteva. Nedostaci radnih sednica su pasivnost učesnika, “usitnjavanje” razgovora i često udaljavanje od tema. Sednice treba da traju više dana (5 do 10) u nekoliko sedmica. Ovom zahtevu u praksi je vrlo teško udovoljiti zbog obaveza učesnika. Otpor sednici je srazmeran nivou položaja konkretnog učesnika. Otpor je naročito naglašen kada poslovni sistem zapošljava informatičare, jer se podrazumeva da je informatizacija isključivo njihov posao.


Razvoj prototipa

Razvoj prototipa se koristi kada korisnik ne može tačno da definiše svoje informacione potrebe pre nego što se izgradi informacioni sistem. Razlog tome može biti nedostatak postojećeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak teška vizuelizacija budućeg sistema. Da bi se olakšala vizuelizacija budućeg sistema izgrađuje se sistem koji zadovoljava neke osnovne, inicijalne potrebe. U radu sa takvim sistemom korisnik otkriva svoje informacione potrebe, te se sistem modifikuje kako bi se zadovoljile te potrebe. Postupak korištenje sistema i modifikovanje istog iterativno se ponavlja, a informacione potrebe korisnika otkrivaju korištenjem sistema.


Najčešći problemi pri prikupljanju informacija

Ponašanja korisnika često može da uzrokuje niz problema pri definisanju zahteva za informacioni sistem. Informatičkim žargonom su opisana ponašanja koja se mogu očekivati od korisnika.

  1. Taktika “kuhinjskog sudopera”: korisnik navodi (preko)brojne potrebe, gomilu nepotrebnih izveštaja, formi na ekranu, sortiranja, izračunavanja i sl. Ovakav pristup obično je uzrokovan pomanjkanjem iskustva korisnika, koji ne zna šta bi mu stvarno moglo zatrebati ili nije u stanju izdvojiti ono šta je bitno;
  2. Taktika “dimne zavese”: korisnik traži više mogućnosti, a zapravo mu je potrebna samo jedna ili dve. Dodatni zahtevi služe za postizanje bolje nagodbe sa analitičarom. Ova taktika obično oslikava korisnika sa dobrim poznavanjem onoga šta želi, a zahteve treba reducirati na one realne i izvodljive;
  3. Taktika "Treba mi isto, ali u boljem obliku": korisniku koji koristi ovu taktiku nedostaje volja ili znanje, a ponekad oboje. Šanse za uspešno definisanje problema su male, jer samo korisnik može izraziti svoje potrebe i probleme.


Korisnik je sklon da prešuti izuzetke, koji su bitni (nužni!) za uspešnu realizaciju, a obično izuzeci zahtevaju i najviše napora tokom ugradnje: "To je naša jedina procedura … (osim kada … )". Ne izjednačavati “tako se uvek radi” sa “tako treba raditi”!


Last modified: Thursday, 10 October 2019, 8:44 AM