Šta žele, a šta im treba

U raznim prilikama, opisujući aktuelni korisnički softver i široke mogućnosti koje danas imamo, često smo vam skretali pažnju na to da su došla nova vremena za projektante i programere u poslovnim informacionim sistemima. Microsoft Office, koji danas smatramo najbolje struktuiranim i najmoćnijim softverskim paketom za krajnjeg korisnika na tržištu, odavno je prerastao osnovnu namenu i danas se javlja kao jedna od razvojnih platformi za poslovne namene. Microsoft Office Developer je varijanta paketa namenjena tim poslovima, što smo detaljno prikazali u „PC #71“, a onda smo govorili i o workflow aplikacijama, jednom od trendova savremenih razvojnih sistema, u nameri da ilustrujemo mogućnosti razvojne varijante novog Office-a.

Pristup koji smo primenili donosi rizik da „od silnog drveća ne vidimo šumu“ – ne bi trebalo da se povedemo za pukim opisivanjem mogućnosti neke komponente razvojnog sistema, a da pri tom ne razmišljamo o celishodnosti njene primene. Zato ćemo zastati i razmisliti o postupcima u dizajnu i razvoju korisničkih aplikacija. Polazimo od namere da primenom savremenih tehnologija ispunimo svrhu koje te tehnologije sobom nose – da unapredimo radno okruženje poslovnog čoveka, tako da svi parametri poslovanja (ili barem većina njih) budu ponuđeni kao namenski programi i kontrolisani sadržaji na personalnom računaru.

Svaki profesionalni programer može ovo da prokomentariše rečima „mi to već znamo“. Tačno, sve to već znate, ali se zapitajte kada ste poslednji put zaista razmišljali o elementarnim koracima? Verovatno je to bilo davno, pre nego što ste se prepustili inerciji rutinskog rada, kada je vaše besprekorno iskustvo neprimetno počelo da biva veća smetnja nego pomoć. Zato ćemo se pozabaviti „onim što već znamo“, počinjući od elementarnih koraka u pripremi za pisanje aplikacije i dolazeći do rešenja u Microsoft Office Developer-u.

Sve počinje od ankete

Za projektanta aplikacije bitno je da prođe kroz proces planiranja i dizajniranja, da bi pri kodiranju imao pred sobom jasan cilj programa. U toj fazi se može potrošiti nekoliko sati, dana ili meseci, svejedno... Nekompletno izvođenje ili čak preskakanje pripreme za izradu aplikacije povećava rizik da program radi nekompletno, necelishodno ili čak pogrešno.

U realnom životu, rizik nastaje zbog kompleksnosti zahteva. Često su potrebna i druga znanja osim informatičkih – nećete, recimo, napisati dobar program za fakturisanje ako taj posao ne umete da izvedete bez računara ili ako vam neko detaljno ne objasni kako izgleda operativa robnog knjigovodstva. Dodatni problem nastaje u okruženju u kome vlada loša komunikacija (zvuči poznato) i gde se rezultati traže odmah. Tu su i prepreke netehničke prirode, za čije prevazilaženje vam ne pomaže nijedna škola ili priručnik.

Prva pouka koju treba izvući i koju ćete ugraditi u temelj aplikacije jeste pravilna identifikacija korisnika. Da li će program koristiti jedna ili više osoba? Koliko od rada jednog korisnika u budućem informacionom sistemu zavisi rad drugih korisnika? Koliko je kritična tačnost podataka, a koliko brzina dostizanja rezultata? Korisnik je prvi faktor budućeg rada aplikacije i njegovim ponašanjem prema rezultatu vašeg rada sve počinje i sve se završava. Od slike koju steknete na početku zavisiće način organizacije podataka, sigurnost informacija i aplikacije, organizacija interfejsa modula programa... Već tada možete steći sliku o pravcu gradnje aplikacije, mada još nije vreme za implementaciju.

Na početku, treba ići najsporije, investirajući vreme u sprečavanje kasnije greške. Krenite sa olovkom i papirom, pišući teze i crtajući veze između dokumenata. Pri snimanju stanja nemojte se mnogo baviti nedostacima sistema: dovoljno je da ste ih uočili, a analiza sledi kasnije. Radije se posvetite traženju odgovora na dva pitanja, koja zvuče slično, ali se suštinski razlikuju: „šta korisnik želi“ i „šta korisniku treba“.

Dopustite korisniku da svojim rečima objasni šta želi, i pri tom mu postavljajte pitanja o detaljima. Ponovite ono što ste saznali, pokušavajući da vas pri tom korisnik razume. Tražite detalje od kojih će zavisiti rad programa. Na primer, korisnik govori o izveštaju. Za koga je izveštaj važan? Koliko osoba ga čita? Koliko često se izveštaj pravi i kako se čuva? Da li sadržaj izveštaja ostaje fiksan ili iz njega treba izvlačiti dalje izveštaje? Hoće li se štampati, čuvati kao fajl ili će ga neko poslati e-mail-om?

Ovo su samo neka od pitanja na osnovu kojih ćete doći do slike funkcija programa. Morate pomoći korisniku da izabere pravi vid rešenja, jer on možda ne zna za sve mogućnosti. Zato uvek sve pitajte ponovo, menjajući frazu. Demonstrirajte tipsko rešenje i razgovarajte o njegovoj celishodnosti. Ne zaboravite – proces je mukotrpan za korisnika, koji je verovatno očekivao da u času uključenja računara svi zahtevi budu ispunjeni, a svi problemi prevaziđeni.

Aplikacija na papiru

Problem nastaje kada korisnik želi tačno određeni oblik rešenja ili kada misli da je „baš ovo“ rešenje najbolje za njega. Otkrivanje takvih mesta predstavlja svrhu drugog pitanja „šta korisniku treba“. Naići ćete na korisnika koji želi tačno određeni oblik nekog rešenja, najčešće zato što mu takav način rada blizak ili zato što je negde video slično rešenje. Kao projektant, morate misliti na to kako se određena grupa funkcija ponaša u celom sistemu i stoga specifični zahtev jednog referenta ne može biti važniji od „velike slike“.

Varijante rešenja prilagodićete ograničenjima u okviru strategije. Ukoliko se pojave razlike u mišljenju, preispitajte i svoj stav jer je moguće da ne razumete potrebu korisnika. Na kraju faze anketiranja morate se posvetiti pogledu na višekorisnički rad. Razgovarajte sa više korisnika iste aplikacije i saznajte koliki je obim radnih mesta na kojima će aplikacija biti angažovana. Moraćete da mislite na mrežne resurse, način i obim angažovanja baza podataka, tip fizičkog organizovanja aplikacije (primerci programa na radnim stanicama, mrežni program, Web aplikacija...) i na posledice eksploatacije aplikacije, od fizičkog integriteta i performansi do bezbednosti i održavanja rezervnih kopija podataka. Obavezno predvidite mogućnosti ispravke bilo koje neregularnosti – od pogrešnog unosa podataka, preko zastoja radne stanice, do kvara servera. Shodno potrebnim merama zaštite, pripremite i scenario rešenja.

Posle ankete, vreme je za skice. Preporučujemo olovku i papir: možete se pobuniti zato što imate neki moćni CASE alat, ali posvetite se razmišljanju više nego prezentaciji projekta. Odaberite optimalnu tehnologiju, tip korisničkog interfejsa, organizaciju koda i organizaciju podataka. Dok dođete do cele slike o tehničkom izvođenju aplikacije, otvoriće se niz novih pitanja koja će tražiti novi krug ankete. Vredi ponoviti, otkrivanje maksimalne količine detalja pre pisanja prvog reda programa spasava vaše vreme na duge staze.

Ako je aplikacija kompleksna, obavezno napravite njenu specifikaciju. To je dokument koji sadrži pregled ciljeva aplikacije, opisuje detalje u implementaciji, daje smernice za projektovanje i eksploataciju baze podataka i podvlači trenutno nejasna i nerešena pitanja. Ovo je važan i vredan dokument koji treba prezentirati klijentu i sa kojim klijent treba da se složi. U praksi, postojanje specifikacije overene od klijenta može da znači razliku u ceni vaše aplikacije ako negde na pola puta dođe do promene zahteva. Osim toga, ako ste na čelu programerskog tima, specifikacija predstavlja centralni dokument na osnovu koga programerima dajete smernice.

Izbor tehnologije

Bez obzira na predostrožnost, previdećete neki detalj. Najčešće je to neka posebnost koju korisnici opravdano traže. Kada krenete u razvoj aplikacije, naučićete još više o poslovnom problemu koji rešavate. Tada ćete ući u krug pozitivne povratne sprege i variranjem rešenja u toku razvoja stići do optimalne aplikacije koja zadovoljava korisnike. I tek na ovom mestu možemo govoriti o specifičnostima razvojne platforme, pa se polako vratiti u kontekst softvera. Reč je o tome da sa aktuelnim alatima u razvojnim sistemima i valjanom infrastrukturom na serverima možete ostvariti mnoge prečice, realna poboljšanja u odnosu na „programiranje na o-ruk“, da ne govorimo o uštedama u razvoju i korisnikovim u eksploataciji informacionog sistema.

Ne treba „otkrivati toplu vodu“ u pripremi funkcija sistema za koje već postoji efikasno rešenje. Na primer, samo pre nekoliko godina, potreba za izradom sistema za upravljanje dokumentacijom zahtevala bi ozbiljno projektovanje i programiranje,. Danas se taj problem rešava jednostavno angažovanjem dodatka Sharepoint Team Services u intranetu. Ako govorimo o razvoju aplikacija u Office okruženju, dobro je to što se od ideje do prototipa dolazi brzo, a traženje varijacija u opštem slučaju nije skupo niti dugotrajno. Zapravo, prateća literatura novih Office Developer alata sugeriše da radna verzija Office aplikacije (tj. integrisanog rešenja u Office-u), u sprezi sa standardnim okruženjem, treba da služi kao puni radni prototip koji možete pokazati korisniku u fazi razvoja. Ovo je po efikasnosti dobar pristup, jer ne iziskuje velike pripreme za probni rad.

Napravite kroki korisničkog interfejsa aplikacije, ali nemojte gubiti mnogo vremena na izgled prozora i položaje kontrola, jer postoji velika verovatnoća da će radna površina biti revidirana u više navrata. Odložite rad na „finoj kozmetici“ (osim ako je kritično da korisnik vidi neki gotov deo aplikacije) i posvetite se „armaturi jezgra“ aplikacije. Primera radi, ako pravite „čarobnjaka“ (wizard) koji radi određeni posao, izvedite samo kontrole koje generišu osnovne rezultate i predvidite prostor za dodavanje kontrola (tj. objekata i metoda) za „fino biranje“ opcija. Što pre dostignete gotov prototip, pre ćete doći do realne slike o ponašanju aplikacije, pogotovo u onim kritičnim delovima gde se mora proveriti ponašanje korisnika u poslovnom procesu.

Sami ili uz pomoć korisnika, angažujte jezgro aplikacije u praksi, i to nad probnim podacima koji su strogo razdvojeni od „živih“ podataka. Osim provere ispravnosti i funkcionalnosti glavnih delova programa, simulirajte neke posebne situacije i tako isprobajte robustnost aplikacije. Recimo, ako je to lokalno instalirana aplikacija, izazovite prekid veze između radne stanice i mreže i ispitajte ponašanje sistema. Ako radite sa Office-om, proverite podrazumevana ponašanja programa i šablona koje ste pripremili. Ako postoji funkcija slanja e-mail-a iz aplikacije, napravite probu slanja poruke i proverite njen izgled kod primaoca.

Prepustite korisniku da neko vreme sam isproba rad aplikacije, a zbog testa kvaliteta interfejsa namerno mu saopštite što manje informacija o pojedinostima aplikacije i potom pratite njegovo ponašanje. Možda ćete tom prilikom doći do novih ideja o nekom rešenju. Tek tada počnite da razvijate ideje o detaljima radne površine, završavajući posao koji ste ranije odložili.

Pravilan izbor

Može da zvuči čudno, ali proces izbora optimalne tehnologije rada aplikacije može da se odvija paralelno sa izradom prototipa. Office okolina nudi skalabilnost na koju možete da se oslonite dok razvijate aplikaciju i na kojoj prototip može da radi. Recimo, programski alati za aplikacije nad bazama podataka su nezavisni od izvora, a veza sa bazom se uspostavlja ili menja u kratkom postupku konfigurisanja. Tako možete razviti aplikaciju koja radi sa MDB Access bazom, ne angažujući pune resurse SQL Server-a; time ćete prve korake u radu aplikacije učiniti jeftinim. Kasnije bazu možete migrirati na SQL Server, a aplikaciju brzo prilagoditi novom izvoru podataka.

Aplikacije koje razvijate uz pomoć Office Developer-a najverovatnije će pripadati jednoj od četiri grupe: sistem za upravljanje podacima, programirani šablon dokumenta, add-in (dodatak Office programu) ili Web aplikacija. Potonje tri grupe mogu (ali ne moraju) biti povezane sa nekom bazom podataka. Izbor pravog programa napravićete na osnovu pregleda snage i slabosti svakog od njih u kontekstu namene aplikacije.

Ovo svojstvo aplikacije ne bi trebalo da vas mnogo zbunjuje. Ako postoje različiti elementi aplikacije koji se prirodno rešavaju u drugom programu u odnosu na onaj koji ste prvobitno zamislili, angažovaćete drugi program direktno iz prvog. Recimo, hteli biste da faktura koju formirate u Access okruženju bude popunjena iz šablona koji ste napravili u Word-u, ili neki cenovnik održavate u radnoj svesci u Excel-u, a aplikacija u Microsoft Access-u treba da joj pristupi. Nijedna od ovih ideja neće predstavljati problem – biraćete između nekoliko načina da postignete cilj.

Bolji način orijentacije u traženju optimalnog rešenja jeste u zadovoljavanju fizičkih preduslova rada aplikacije: da li je ona višekorisnička? Koliki je broj korisnika? Kakve mere bezbednosti su neophodne? Pomenuli smo već razliku između MDB baze i baze na SQL Server-u. To ne mora biti različito samo u fazi razvoja prototipa. Ako aplikaciju upotrebljava mali broj korisnika (recimo, ispod 25), a sve mere bezbednosti se mogu lako izvesti rutinskom administracijom na serveru, aplikacija može efikasno raditi i na „maloj“ bazi. U nekim slučajevima može biti celishodno da podatke u aplikaciji skaliramo „naniže“, ka Excel listi.

Zamislite situaciju u kojoj korisnik održava relativno malu popunu podacima, ali intenzivno analizira nastale promene u obliku izvedenih i sumarnih tabela ili grafikona. U praksi su se dokazale prilike gde je rešenje u Excel-u bolje odgovaralo zahtevu korisnika nego program u Access-u, pri čemu su zadovoljeni svi kriterijumi homogene i bezbedne aplikacije. S druge strane, možda je potrebno obezbediti hijerarhiju bezbednosti unutar aplikacije, a ne na nivou baze. Standardni, „školski“ primer je program za vođenje zarada, gde i radnik i poslovođa mogu da imaju uvid u platu radnika, ali radnik ne sme da vidi platu drugih radnika. Ovakve mere bezbednosti su kritično bitan faktor aplikacije i moraju se posebno specificirati i isprobati još u toku rada prototipa. Zbog ovakvih prilika dobro je da se u fazi izrade prototipa barem na čas posvetite ispitivanju alternativnih rešenja organizacije podataka.

Na kraju početka

Pošto smo tek zagrebali po površini opsežnog područja, ovoga puta nećemo sumirati zaključke. Krenućemo u dalje ispitivanje potreba koje projektant integrisanog rešenja ima u svom poslu, pa ćemo preći i na konkretnije stvari. Možda će nas ovakav pristup odvesti u „sitan vez“, ali potpisnik ovih redova veruje da je to bolji način prikazivanja aktuelnih tehnologija u poslovnim informacionim sistemima nego da se pred vama nađe puki prikaz nekog softverskog paketa uz koji je nabrojana lista teoretskih mogućnosti. Očekujemo samo malo strpljenja dok ne zaokružimo „dosadni deo priče“, nakon čega ćemo doći i do „akcije“.

© 1995-2024 PC Press. Sva prava zadržana.