Seminarski rad iz predmeta Projektovanje informacionih sistema Tema: Analiza sistema

Sadraj:

1.Uvod
Pojam Analiza sistema, kao jedne od faza u razvoju informacionog sistema, moemo definisati kao dekompoziciju (rastavljanje) poslovnog sistema na jednostavnije djelove (komponente), s ciljem da saznamo kako ti djelovi funkcioniu pojedinano i da utvrdimo kako su meusobno povezani, odnosno u kakvoj su interakciji.

Svrha analize sistema (sistemske analize) je u ponovnom objedinjavanju rastavljenih komponenti sistema i poboljanju interakcije (meudjelovanja) izmeu njih. Krae reeno, cilj analize sistema je izgradnja novog poboljanog sistema, u naem sluaju informacionog sistema. Svrha, cilj i dubina analize sistema mogu se predstaviti sledeim aktivnostima: Automatizacijom poslovnih procesa (Business Process Reengineering) BPA, odnosno poveanjem efikasnosti korisnika analizom problema i uklanjanjem uzroka; Poboljanjem poslovnih procesa ( Busines Process Improvement ) BPI, tj. poveanjem efikasnosti I djelotvornosti, analizom trajanja i kotanja poslovnih procesa, te predlaganjem poboljanja (udruivanje procesa, paralelizam izvedbe); Reinenjeringom poslovnih procesa ( Business Process Reengineering ) BPR ili preoblikovanjem poslovnih procesa (Business Process Redesign) BPR, to predstavlja radikalni redizajn poslovnih procesa analizom moguih posljedica, procjenom alternativnih tehnologija, ukidanjem ili zamjenom pojedinih aktivnosti, analizom trokova - koristi i analizom rizika. 1

Sl.1. Mjesto analize sistema u projektovanju informacionog sistema

2. Analiza sistema i njene aktivnosti

U okviru analize sistema obavljaju se sledee aktivnosti: Pregled sistema i planiranje projekta; Prouavanje i analiza postojeeg poslovnog i informacionog sistema Definisanje poslovnih zahtjeva i prioriteta za novi ili poboljan postojei sistem.
1

Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.67

Aktivnosti analize mogu se sistematizovati u tri nivoa, gdje svaki nivo trai odgovor na odgovarajua pitanja; 1. Detaljna analiza postojeeg sistema, te utvrivanje potreba i zahtjeva: Kako radi postojei sistem?, Na koji nain korisnici koriste sistem da bi obavili posao?, Koji su problemi pri koritenju aplikacija?; 2. Detaljna specifikacija zahtjeva za informacioni sistem: Koji su podaci potrebni?, Ko ih treba?, Od koga?, Ko ih stvara?, Koji su izlazni podaci?, Kakav im jet oblik?, Koji su izvori izlaznih podataka?, Na koji se nain podaci prikupljaju i objedinjuju?; 3. Daljnja razrada granica projekta.2 Analiza sistema, je ustvari; detaljna analiza strukture poslovng sistema (organizacije), kojom se preciziraju poslovni zahtjevi i granice projekta i to u obliku i na nain razumljiv dizajnerima (projektantima) novog poboljanog informacionog sistema, koji treba da unaprijedi poslovni sistem. Sve ovo nije nimalo jednostavan posao, jer analitiari tokom ove faze, u projektovanju informacionog sistema, moraju da organizuju i sprovedu niz obimnih istraivanja, snimanja, analiza, personalnih intervjua itd. kako bi valjano i kvalitetno definisali informacione zahtjeve i potrebe korisnika. U projektovanju informacionog sistema, analiza sistema je veoma bitna, ako ne i najbitnija faza, jer ako se ne sprovede kvalitetno i na pravi nain, informacioni sistem nikada nee profunkcionisati kao podrka poslovnom sistemu, a i naknadne prepravke ove faze projektovanja, su veoma komplikovane i skupe, tako da bi bilo jednostavnije krenuti projektovanje ispoetka.

3. Postupci i tehnike analize

Moderna struktuirana analiza je procesno usmjerena tehnika modeliranja poslovnih zahtjeva za sistem.

Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.67, 68

Informaciono inenjerstvo je procesno osjetljiva tehnika, usmjerena podacima i prouavanju poslovnog sistema ili njegovih veih djelova kao cjeline, a ne projekat po projekat. Brzi razvoj aplikacija ( Rapid Application Development ) RAD je razvoj djelominih verzija aplikacija, koje mogu evoluirati do konanog rjeenja. Zdrueni razvoj aplikacija ( Joint Application Development ) JAD je analiza zasnovana na intezivnim sjednicama na kojima vlasnici, korisnici, analitiari, dizajneri I projektanti zajedniki definiu I oblikuju sistem. Objektno usmjerena analiza omoguava: Modeliranje uaurivanjem podataka i procesa u objekte; Prouavanje postojeih objekata, da bi se vidjelo mogu li se ponovo iskoristiti ili prilagoditi za nove primjene; Definisanje novih ili modifikovanih objekata koji e skupa sa postojeim objektima graditi novu aplikaciju.3 Navedene tehnike i postupci mogu se kombinovati, iako postoji miljenje da se meusobno iskljuuju.

3.1. Strukturirana analiza sistema

Moderna strukturirana analiza i Logiki dizajn su esti sinonimi koji su u upotrebi. Strukturirana analiza omoguava provoenje strukturiranog procesa i dobijanje rezultata analize. Sainjavaju je: Tehnika modeliranja poslovnih zahtjeva za sistem, koja je usmjerena procesima, ali se razvila tako da obuhvata podatke. Omoguava strukturiranje procesa, ulaza, izlaza I skladita podataka potrebnih da bi se odgovorilo na poslovne dogaaje; Logiki modeli kojima se prikazuje: ta je sistem, ta mora raditi a ne kako radi. Koriste se dijagrami toka podataka za logiki prikaz poslovnih zahtjeva, nezavisno od tehnikih rjeenja, to predstavlja logiki dizajn. Ti modeli izraavaju sutinu sistema. Ukljuivanje odreivanja prioriteta zahtjeva. Analiza sa ciljem automatizacije poslovnih procesa omoguava razumjevanje postojeeg sistema, ekstenzivno prikupljanje informacija i zahtjeva, kao i oblikovanje procesa i podataka. Osim toga, omoguava uoavanje moguih poboljanja (ako nije uinjeno ranije), analizu problema, identifikovanje problema, ustanovljavanje eljenh poboljanja, kao i analizu i traenje uzroka

Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.68

problema i prioritete njihovog rjeavanja. Razvoj koncepata budueg sistema obuhvata prikupljanje dodatnih informacija, reviziju I doradu modela.4 Strukturirana sistem analiza (SSA) je jedna od najpoznatijih tehnika za analizu sistema i zahtijeva korisnika. Metoda SSA je razvijena u okviru Yourdon Inc. Jedan od njenih tvoraca je E. Yourdon. Nastala je kao odgovor na problem neadekvatne specifikacije zahteva korisnika pomou klasinih sredstava funkcionalne analize. Daje jasan i detaljan opis sistema, primjenom metode apstrakcije, tako da se sistem na viim nivoima apstrakcije opisuje optije, a na niim detaljno. Predstavlja logiku, a ne fiziku specifikaciju procesa, specifikacija opisuje ta e budui sistem raditi i ta e pruati korisniku, a ne kako e biti primjenjen. SSA predstavlja jasnu grafika specifikaciju, pogodnu za komunikaciju sa korisnikom i posmatra informacioni sistem kao funkciju (proces obrade) koja, na bazi ulaznih, generie izlazne podatke. Ulazni podaci se dovode u proces obrade, a izlazni iz njega odvode preko tokova podataka.

Sl.2. Primjer dekompozicionog dijagrama

4. Definisanje zahtjeva sistema

Definisanje zahtjeva je voma bitan segment analize sistema. Smatra se da 40 do 60% greaka u projektu, je uzrokovano, grekama u postavljanju zahtjeva,
4

Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.69

to ima za posljedicu nefunkcionalnost sistema, odnosno veliku razliku od onoga to je klijent naruio i to je projektant mislio da treba napraviti. Naknadne prepravke mogu predstavljati do 40% trokova razvoja, od ega je 70 do 85% pripisivo pogrenim zahtjevima. Nepotpuno definisani zahtjevi ine nemoguim planiranje projekta i praenje promjena (Leffingwell, 1997). 5

4.1. Vrste zahtjeva

Zahtjevi mogu biti: Poslovni (zato), Korisniki (zahtjevi krajnjih korisnika), Fukcionalni (ta), Nefunkcionalni (kako ili kako dobro). Poslovni zahtjevi definiu ciljeve organizacije (korisniki zahtjevi na viem nivou), odnosno daju opis problema koje treba rijeiti (npr. poslovna potreba "Poboljanje usluge postojeim klijentima i pridobijanje novih") ili sadrani u dokumentima u kojima se opisuje vizija i opseg projekta (npr. poslovni zahtjev "Omoguiti Internet prodaju"). Korisniki zahtjevi (zahtjevi krajnjih korisnika) opisuju zadatke koje korisnik mora moi obaviti sluei se aplikacijama ili koji su sadrani u opisima sluajeva koritenja,tj. opisima scenarija rada. Funkcionalni zahtjevi (ta) definiu softversku funkcionalnost (oekivano ponaanje i operacije koje sistem moe izvoditi), koju treba ugraditi u proizvod da bi omoguio korisnicima obavljanje njihovih zadataka. U ovu grupu zahtjeva spadaju posebno zanimljive mogunosti programa, odnosno skup logiki povezanih funkcionalnih zahtjeva koje korisniku omoguavaju ispunjavanje poslovnih zahtjeva. Nefunkcionalni zahtjevi (kako ili kako dobro) su standardi, pravila i ugovori koje proizvod mora zadovoljiti, opisi vanjskih interfejsa, zahtjevi za performansama, ogranienja za dizajn i implementaciju, te osobine kvaliteta koje preciziraju opis proizvoda navodei karakteristike proizvoda u razliitim dimenzijama, a bitne su ili korisniku ili projektantu. 6 Prilikom definisanja zahtjeva treba voditi rauna o prioritetu pojedinanih zahtjeva.

4.2. Odreivanje zahtjeva

Poslovni zahtjevi: Sve to opisuje finansijski, trgovaki ili drugi poslovni prodor koji korisnici, ili organizacija koja razvija sistem, mogu dobiti je, najvjerovatnije, poslovni zahtjev.
5 6

Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.70 Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.70

Sluajevi koritenja ili scenariji: Opte izjave o korisnikim ciljevima ili poslovnim zadacima, koje korisnici moraju obavljati, najvjerojatnije su sluajevi koritenja, dok specifini opisi zadataka predstavljaju korisnike scenarije. Specifine zadatke treba generalisati u opte sluajeve koritenja. Poslovna pravila: Kada korisnik izjavi da neku aktivnost mogu obavljati samo pojedine osobe ili uloge, pod odreenim uslovima, on moda opisuje poslovno pravilo. Poslovna pravila su operativni principi poslovnih procesa. Ona nisu funkcionalni zahtjevi. Funkcionalni zahtjevi: Izjava koja poinje sa Korisnik mora moi da obavi neku funkciju, ili Sistem treba moi da demonstrira odreeno ponaanje je najvjerovatnije funkcionalni zahtjev. Funkcionalni zahtjevi opisuju vidljivo ponaanje sistema i definiu ta e sistem raditi. Treba svima biti jasno zato sistem mora biti u stanju da obavlja odreene funkcije. Predloeni funkcionalni zahtjevi ponekad predstavljaju zastarjele ili neefikasne poslovne procese koji ne trebaju biti ukljueni u novi sistem. Atributi kvaliteta: Izjave koje opisuju kako dobro sistem obavlja funkciju su atributi kvaliteta, tj. jedna vrsta nefunkcionalnih zahtjeva. Zahtjeve koji opisuju poeljne 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. Zahtjevi vanjskih interfejsa: Ova klasa zahtjeva opisuje veze izmeu sistema i vanjskog svijeta. Specifikacija sistemskih zahtjeva treba da ukljuuje odlomke za ove zahtjeve, ukljuujui i interfejse, te mehanizme komunikacije za korisnike, hardver i druge softverske sisteme. Ogranienja su uslovi koji ograniavanju izbor rjeenja raspoloivih dizajneru ili programeru. Spadaju u nefunkcionalne zahtjeve i trebaju biti dokumentovani. Neopravdana ogranienja treba pokuati odbaciti jer onemoguavaju postizanje najboljeg rjeenja. Takoe, mogu umanjiti primjenu komercijalnog softvera i komponenti u rjeenju. Neka ogranienja mogu pomoi u zadovoljavaju atributa kvaliteta. Primjer je poboljanje prenosivosti programa koritenjem samo standardnih naredbi nekog programskog jezika. Definicija podataka je bilo koji opis formata, dozvoljenih vrijednosti, pretpostavljenih vrijednosti ili kompozicija sloenih struktura podataka. Sve definicije treba pohraniti u Rjenik podataka, kao glavni orjentir za uesnike na projektu. Ideje o rjeenju: Ako korisnik opisuje specifian nain interakcije sa sistemom, kojom bi mogao obaviti neku akciju, npr. Korisnik odabira podatak koji eli iz padajue liste, on predlae rjeenje, a ne zahtjev. Predloeno rjeenje moe odvui panju od pravih zahtjeva. Kod postavljanja zahtjeva treba se usmjeriti na ono to je potrebno obaviti, a ne na nain realizacije. Treba istraiti zato

korisnik predlae odreenu ugradnju, jer to moe pomoi u razumijevanju stvarne potrebe i korisnikovih oekivanja o nainu kako sistem treba da raditi.7

4.3. Postavljanje prioriteta zahtjeva

Nuno svojstvo sistema namee pitanje: Da li vlasnik sistema neto stvarno mora imati? Postoji tendencija da se previe zahtjeva proglasi nunim! Po definiciji, ako sistem ne ukljuuje nune zahtjeve, taj sistem ne moe ispuniti svoju svrhu. Treba testirati svaki zahtjev koji se smatra nunim i probati ga rangirati. Ako se zahtjev moe rangirati onda nije obavezan. Potpuno obavezni zahtjevi se ne mogu rangirati, jer su nuni za prvu verziju sistema. Poeljno svojstvo sistema su funkcije koje korisnik eli na kraju da ima. Ranije verzije sistema mogu pruiti (ne potpunu) funkcionalnost bez tih zahtjeva. Poeljni zahtjevi mogu i trebaju biti rangirani. Neobvezna svojstva sistema su proizvoljni zahtjevi, svojstva i mogunosti bez kojih se moe, iako bi lijepo bilo ih imati. To nisu pravi zahtjevi. Ovi zahtjevi, takoe, mogu biti rangirani.8

4.4. Dokumentovanje analize zahtjeva

Kratke definicije zahtjeva glase: (1) izjava o stanju, ogranienjima i potrebama sistema, (2) narativni dokument namijenjen korisniku, ili ga pie korisnik, a sainjavaju ga poslovni i korisniki zahtjevi, kao i njihovi prioriteti, uoeni problemi, kljune pretpostavke i preporuke za njihovo rjeavanje. Specifikacija zahtjeva, esto nazvana i funkcionalnom specifikacijom, je strukturirani dokument sa detaljnim opisom oekivanog ponaanja sistema. Namijenjen je ugovaraima i izvriocima razvoja. Predstavlja cjeloviti i nezavisan pogled na sistem. Sainjavaju ga funkcionalni i nefunkcionalni zahtjevi 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).9

4.5. Uzroci loeg planiranja zahtjeva

Nedovoljna ukljuenost korisnika: Bez korisnika se ne moe tono znati ta korisnici ele. Takvi proizvodi su neprihvatljivi.
7 8

Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.72, 73 Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.73, 74 9 Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.74, 75

udni korisniki zahtjevi: Neopravdana promjena miljenja tokom izvedbe uzrokuje prekoraenje predvienog roka za realizaciju, kao i degradaciju kvaliteta proizvoda. Nejasni (dvosmisleni) zahtjevi: Situacija u kojoj italac zahtjeva, taj zahtjev tumai na vie naina. To uzrokuje prepravljanje i gubljenje vremena. Pretjerano ukraavanje: elja izvoaa da dodaju novu funkcionalnost "koja treba da se svidi korisnicima" i zahtjev korisnika za dodacima koji dobro izgledaju ali ne pridonose funkcionalnosti. Izrada takvih dodataka je nepotrebna i predstavlja gubljenje vremena. Minimalistike specifikacije: Tendencija postavljanja minimalnih zahtjeva ili skiciranja koncepata, uz elju da ih izvoai nadopune tokom izvedbe, izaziva frustracije izvoaa i neispunjena oekivanja korisnika. Zanemarivanje potreba: Zanemarivanje potreba odreenih (grupa) korisnika izaziva stvaranje opozicije projektu.10

4.6. Svojstva dobro postavljenih zahtjeva

Svojstva dobro postavljenih korisnikih zahtjeva su definisana IEEE standardom [1998]. Ta svojstva su: potpunost (cjelovitost), tanost, ostvarivost (izvodljivost), nunost, poredak po prioritetima, nedvosmislenost i mogunost provjere. Dobra specifikacija zahtjeva korisnika mora da sadri slijedea svojstva: potpunost, konzistentnost, mogunost izmjene mogunost praenja. Cilj je napisati dovoljno dobre zahtjeve, na osnovu kojih se moe pristupiti dizajnu i ugradnji pojedinih komponenata sistema, uz prihvatljiv stepen rizika.11

5. Zakljuak
Analiza sistema (sistem analiza) je veoma kompleksan i sloen proces. Najee ga obavljaju struni timovi pod rukovodstvom glavnog projektanta
10 11

Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.75 Poliuk E. Jaroslav; Projektovanje informacionih sistema; str.75

10

(koordinatora projekta), koji pored vrhunskog posjedovanja znanja iz informacionih tehnologija, treba da posjeduje i irok spektar znanja i iz drugih oblasti ljudske nauke i tehnologije (mada neki tvrde da poznavanje tih drugih oblasti i nije potrebno), a naroito oblasti za koju se projektuje konkretan informacioni sistem. Analiza sistema prestavlja temelj projektovanja dobrog informacionog sistema, i bez kvalitetno uraene sistem analize nema ni kvalitetnog informaciong sistema koji e sluiti svojoj svrsi, a to je unapreenje poslovanja, realnog poslovnog sistema ili organizacije.

Literatura:
Projektovanje informacionih sistema; Poliuk E. Jaroslav; Podgorica 11

www.wikipedia.org

12