PREDMET

Programsko Inženjerstvo (PRI)

 eMPIRICA – III Semestar: PRI 2013

PREDAVANJE 1

POJAM PROGRAMSKOG INŽENJERSTVA

Softverski produkt je skup računarskih programa i pripadne dokumentacije, stvoren
da bi se prodao nekom korisniku. Može biti razvijen za sasvim određenog korisnika
(bespoke product, customized product) ili općenito za tržište (generic product).
Za današnji softver podrazumijeva se da on mora biti kvalitetan. Preciznije, od
softverskog produkta se očekuje da se on odlikuje sljedećim atributima kvalitete.
 Mogućnost održavanja - Softver se mora moći mijenjati u skladu s
promijenjenim potrebama korisnika.
 Pouzdanost i sigurnost - Softver se mora ponašati na predvidiv način te ne
smije izazivati fizičke ili ekonomske štete.
 Efikasnost - Softver mora imati zadovoljavajuće performanse te on treba
upravljati strojnim resursima na štedljiv način.
 Upotrebljivost - Softver treba raditi ono što korisnici od njega očekuju, sučelje
mu treba biti zadovoljavajuće te za njega mora postojati dokumentacija.

Programiranje je relativno mala komponenta oblasti programsko inženjerstva. Neke

druge komponente (uključujući na primer, specifikaciju softvera i projektovanje) su jednako
važne.

Programsko inženjerstvo je disciplina koja se bavi svim aspektima proizvodnje

softvera. Dakle, programsko inženjerstvo bavi se modelima, metodama i alatima koji su
nam potrebni da bi na što jeftiniji način mogli proizvoditi što kvalitetnije softverske
produkte.

2
 eMPIRICA – III Semestar: PRI 2013

Programsko inženjerstvo može se smatrati znanstvenom disciplinom no također i

tehničkom strukom. U oba slučaja, ono je u bliskoj vezi s još dva područja znanja:
 Računarstvo (computer science). Poznavanje teorijskog računarstva potrebno
je softverskom inženjeru na sličan način kao što je poznavanje mehanike
potrebno mašinskom inženjeru.
 Sistemsko inženjerstvo (system engineering). Bavi se razvojem složenih sistema
koji se sastojtoje od hardvera, softvera i ljudskih aktivnosti. Softverski inženjer
mora svoje softversko rješenje uklopiti u takav složeniji sistem

.
Odnos između računarske nauke i programskog inženjerstva

DEFINICIJE I CILJEVI PROGRAMSKOG

INŽENJRSTVA
Neke od značajnijih definicija programskog inžejerstva su:
 Inženjerska disciplina koja je usmjerena na praktične probleme razvoja velikih
programskih sistema.
 Definiran proces, korak po korak, koji omogućava specifikaciju, dizajn,
primjenu i testiranje softverskih rješenja grupe zahtjeva na najefikasniji i
najdohodovniji način.

3
 eMPIRICA – III Semestar: PRI 2013

 Primjena sistematizovanog, disciplinovanog i mjerljivog pristupa razvoju,

uvođenju i održavanju programa, tj. primjena inženjerstva na program.
 Stroga primjena inženjerstva,naučnih i matematičkih principa i metoda u
ekonomičnoj proizvodnji kvalitetnog softvera.

Ciljevi programskog inženjerstva uključuju:

 izrada visokokvalitetnih programa s predvidljivim djelovanjem,
 izrada za održavanje jednostavnih programa,
 pojednostavljenje programa i njihova razvojnog procesa,
 bolja predvidljivost i lakše slijeđenje tijekom razvojnog procesa,
 brži i jeftiniji razvoj

Osobe zadužena za razvoj softvera obavljaju sljedeće zadatke:

 Analiza zahtjeva datog sistema
 Analiza izvodljivosti i procjena truda
 Tehničke specifikacije
 Proširenje postojećih softverskih modula
 Regresiono testiranje i postupci ažuriranja softvera

METODOLOGIJE I HISTORIJA
Metodologije za razvoj informacijskih sistema prvi put su se pojavile krajem
šezdesetih, a na važnosti su dobile tek u sedamdesetim godinama. Na početku, istraživanja
iz područja informacijske tehnologije usmjerena su prije svega na istraživanje novih,
efikasnijih programskih jezika i tehnika (velika tehnička ograničenja brzine procesora i
kapaciteta memorije). Prve tehnike za opisivanje računarskih programa i sistema: dijagrami
toka, dijagrami toka podataka i tabele odlučivanja
Sedamdesetih godina javlja se više metodologija (strukturna analiza i planiranje,
strukturna analiza, strukturno planiranje itd.) s karakterističnim strukturnim pristupom, s
naglašenim odabirom i organizacijom programskih modula u cjelovitu strukturu koja
omogućava rješavanje određenog problema. Može se reći da su sedamdesete bile u znaku
strukturnih metodologija koje su prije svega naglašavale procesno gledište informacijskog
sistema (procesni pristup), dok su nove metodologije osamdesetih godina
(npr. Informacijski inženjering) dale prednost podacima (podatkovni pristup). Promjena
načina razmišljanja su razlog za brži razvoj sistema za upravljanje bazama podataka
zasnovan na relacijskoj teoriji, a koji su postali jezgra svih kompleksnijih informacijskih
sistema
Model ER (Entity Relationship) definitivno se potvrdio kao osnovna dijagramska
tehnika za opis podataka na konceptualnom nivou, a na tržištu su se pojavili i prvi CASE alati
4
 eMPIRICA – III Semestar: PRI 2013

(Computer Aided Software Engineering) za podršku analizama i planiranju. Današnji

integrirani CASE alati podržavaju cjelokupan postupak gradnje informacijskog sistema, od
sakupljanja zahtjeva do same izrade te dokumentiranja programskih rješenja. Pojavom i
brzom prihvaćenošću objektno usmjerene tehnologije početkom devedesetih godina
pojavile su se i prve ideje o novom, objektnom pristupu analizi i planiranju informacijskih
sistema.
Različni autori predstavili su metode i dijagramske tehnike, među kojima je najveća
pozornost posvećena OMT (Object Modeling Techniques), OOA (Object Oriented Analysis)
i Objectory.
Praktična upotreba nije zaživjela zbog sljedećih razloga:
 nepostojanje standardiziranih koncepata,
 nedostatak jedinstvenog procesa planiranja.

U želji za širom prihvaćenošću objektnog modeliranja tri priznata autora objektnih

tehnika (Rumbaugh, Boch i Jacobson) su ujedinili svoje snage i stvorili jezik za objektno
modeliranje UML (Unified Modeling Language).
UML ne definira nijedan postupak za gradnju informacijskih sistema, zbog toga se
može koristiti u svim poznatim pristupima od modela vodopada do prototipnog i
evolucijskog modela. U želji za što većom efikasnošću razvoja brojna su poduzeća
prilagodila svoje postojeće metodologije za korištenje zajedno s jezikom UML, a razvilo se i
nekoliko sasvim novih od kojih jenajpoznatiji proces RUP (Rational Unified Process),
poduzeća Rational (IBM).
Agilne metodologije predstavljaju odgovor
na probleme koji su posljedica korištenja
kompleksnih procesa za razvoj programskih
rješenja, primjerice RUP (predugačak razvojni
ciklus, odvraćanje pažnje od ključnog proizvoda
‒ programska rješenja, preobimna
dokumentacija, prevelika formalizacija
postupaka i interakcija itd.). U prvi plan stavljaju
aktivno/djelujuće programsko rješenje,
neformalnu komunikaciju, saradnju s
korisnicima i prilagođavanje promjenama kako
one dolaze.

5
 eMPIRICA – III Semestar: PRI 2013

MODELI RAZVOJA PROGRAMSKIH

RJEŠENJA
Danas postoji puno različitih metoda, metodologija, procesa i tehnika za usmjerivanje
životnog ciklusa razvoja projekata informacijskih sistema. Modeli razvoja informacijskih
sistema imaju slične ciljeve tj. dijele više zajedničkih zadataka.

Model razvoja informacijskog sistema tipično uključuje sljedeće aktivnosti:

 koncipiranje sistema,
 analiza zahtjeva i koristi sistema,
 planiranje opsega projekta,
 planiranje sistema,
 specifikacija zahtjeva programskog rješenja,
 planiranje arhitekture,
 detaljnije planiranje,
 razvoj programskih jedinica,
 integracija i testiranje programskog rješenja,
 integracija i testiranje sistema,
 postavljanje i testiranje kod korisnika,
 obrazovanje i dokumentiranje
 održavanje.

Svaki model razvoja uključuje određenu kombinaciju navedenih aktivnosti.

Većina danas korištenih modela razvojnih procesa proizlazi iz tri osnovna pristupa:
 spontani (ad hoc) razvoj,
 model vodopada,
 iterativni proces.

SPONTANI RAZVOJ
Izgradnja prvih informacijskih sistema većinom se odvijala bez unaprijed određenog
razvojnog procesa, uspjeh projekata zavisio je od iskustava i znanja pojedinaca. Spontani
razvoj predstavlja razvojni proces koji se mijenja s obzirom na napredovanje rada. I danas se
programska rješenja često razvijaju bez odgovarajućeg razvojnog procesa, prije svega, ako
je riječ o manjim projektima.
Spontani razvoj ima za posljedicu nekonzistentnost osnovnih faktora projekta:
rokova, budžeta, funkcionalnosti i kvalitete proizvoda. I u slučaju odsutnosti razvojnog
6
 eMPIRICA – III Semestar: PRI 2013

procesa postoji mogućnost da neki, prije svega manji projekti izgradnje programskih
rješenja uspijevaju ‒ posljedica napora članova projektne grupe, a ne provjerenih metoda
vođenja projekta.

MODEL VODOPADA
Model vodopada (waterfall model) nastao je u ranim 70-im godinama 20. stoljeća,
kao neposredna analogija s procesima iz drugih inženjerskih struka (na primjer
mostogradnja). Model vodopada, koji je ponekad označavan i kao sekvencijalni odnosno
klasični model životnog ciklusa, najstarija je metoda strukturiranog razvoja informacijskih
sistema. Još uvijek relativno često korišten model razvoja, iako ga često kritiziraju prije
svega u smislu krutosti za brzo reagiranje na zahtjeve koji se brzo mijenjaju. Velik naglasak
se stavlja na dokumentaciju, prije svega, specifikaciji zahtjeva i plana sistema.
Svaka faza u redoslijedu životnog ciklusa mora biti sasvim završena prije početka
sljedeće faze. Nakon zaključka svake faze izrađuje se revizija, ako se projekt odvija u okviru
traženih standarda,specifikacija i vremenskog plana.

Model je dobio ime zbog oblika dijagrama. Vidimo da se aktivnosti odvijaju kao faze
sekvencijalno jedna iza druge. Svaka faza daje neki rezultat koji „teče“ po vodopadu i
predstavlja polazište za iduću fazu. Makar je na slici naznačena mogućnost povratka u raniju
fazu (u slučaju naknadnog otkrivanja greške), ta mogućnost samo se iznimno koristi.
Povratak je nepoželjan jer remeti normalni tijek procesa te izaziva kašnjenje.

7
 eMPIRICA – III Semestar: PRI 2013

PREDNOSTI I NEDOSTACI MODELA

VODOPADA
Model vodopada je pogodan za upotrebu:
 na projektima kod kojih je zahtjeve moguće detaljno opredijeliti već u početnoj
fazi projekta i naknadno se ne mijenjaju,
 ako postoji zahtjev za formalnim potvrđivanjem nakon pojedinih faza projekta,
 ako je projektna grupa, kao i njezin vođa, neiskusna, a očekuje se i fluktuacija
kadrova,
 ako krajnji korisnici sistema dobro vladaju poslovnim procesima koje će
informacijski sistem podržavati.

Prednosti modela vodopada su:

 jednostavno izvođenje, što je značajno kod manjih projekata,
 testiranje je uključeno u svaku fazu, svaka faza sadrži detaljno određene
proizvode, čiji se kvalitet potvrđuje revizijom

Nedostaci modela vodopada su:

 velik rizik jer je teško osigurati da je pojedina faza detaljno odrađena do
prelaska na sljedeću fazu (iz tog razloga neke varijante modela vodopada
uvode određenu mjeru pokrivanja između faza)
 prva rješenja koja funkcioniraju nastaju relativno kasno u životnom ciklusu,
 većina problema otkrije se tek tijekom testiranja,
 kapaciteti se ne mogu provjeriti prije zaključka kodiranja,
 problem konzistentnog održavanja opsežne dokumentacije.

Model nije prikladan za kompleksne projekte sa zahtjevima koji se često mijenjaju, kao i za
manje projekte s kratkim rokovima.
8
 eMPIRICA – III Semestar: PRI 2013

INKREMENTALNI MODEL RAZVOJA

Kao odgovor na probleme modela vodopada nastao je inkrementalni model koji
kombinira uzastopni i iterativni pristup. Iterativni pristup vrši podjela projekta na više
manjih dijelova, što omogućava raniju prezentaciju prvih proizvoda i brže dobivanje
povratnih informacija od korisnika. Informacijski sistem je podijeljen na više modula, čiji se
razvoj odvija manje ili više nezavisno.
Postoji više mogućih implementacija inkrementalnog modela:
 izvedba više manjih pristupa vodopada (za pojedini modul sistema izvedu se
sve faze razvoja, prije prelaska na sljedeću iteraciju),
 definiranje općih zahtjeva sistema prije prelaska u prvu iteraciju
 korištenje uzastopnog pristupa za sakupljanje zahtjeva, analizu i planiranje, za
čim slijedi iterativni prototipni pristup.

Sistem se razvija u nizu iteracija. Pojedina iteracija ne dotjeruje već realizirani dio
sistema, nego mu dodaje sasvim novi dio - inkrement. Razvoj jednog inkrementa unutar
jedne iteracije odvija se po bilo kojem modelu - na primjer kao vodopad. Ideja je prikazana
na slici.

Inkrementalni razvoj programa

PREDNOSTI I NEDOSTACI
INKREMENTALNOG MODELA
Inkrementalni model razvoja je pogodan za:
 projekte čiji su zahtjevi loše definirani i često se mijenjaju
 promjene u budžetu,
 brzorazvijajuće tehnologije

9
 eMPIRICA – III Semestar: PRI 2013

Međutim nije pogodan za manje i kratkotrajne projekte i projekte kod kojih postoje mali
integracijski i arhitekturni rizici.

Prednosti inkrementanog modela su:

 brža izrada prvih proizvoda,
 mogućnost korištenja spoznaja i iskustava dobivenih u početnim iteracijama
tijekom razvoja kasnijih iteracija,
 ranije otkrivanje potencijalnih arhitektonskih i integracijskih rizika,
 spontana kontrola i analiza promjena,
 utvrđivanje problema i neposredno izvođenje potrebnih ispravaka.

Nedostaci modela – zavisno od implementacije:

 nedovoljan pregled sistema kao cjeline (i s poslovnog i s informacijskog
gledišta),
 potreba za dobro određenim sučeljem (neki su moduli završeni dosta prije
drugih),
 opasnost odlaganja problematičnih modula na kasnije iteracije, s namjerom da
se poslovodstvu prikažu rani uspjesi projekta.

Inkrementalni model je vrlo uporabljiv model koji se intenzivno koristi u praksi. Svi generički
softverski paketi poput Microsoft Office-a i slični zapravo su se razvijali u inkrementima.
Svaka njihova nova verzija donosila je nove mogućnosti.

PROTOTIPNI MODEL RAZVOJA

Prototipni model je razvijen na pretpostavci da je često teško znati za sve zahtjeve na
početku projekta. Korisnici su upoznati samo s glavnim ciljevima koje žele postići
programskim rješenjem, a ne znaju sve detalje podataka, funkcionalnosti i kapacitete.
Pristup korištenjem prototipa diktira izgradnju pojednostavljene verzije predloženog
programskog rješenja koje se prezentira korisniku. Korisnik ga pregleda i navodi svoje
napomene koje se nakon toga uključe u samu specifikaciju, a izrađuje se i nova verzija
prototipa. Nakon konačnog određivanja svih potrebnih specifikacija u većini se slučajeva
prototipni kod odbaci i napravi se sasvim novo programsko rješenje.

10
 eMPIRICA – III Semestar: PRI 2013

Inicijalni model simulira funkcije sistema da bi korisnik bolje definirao zahtjeve. Korisnik vrlo
rano vidi kako će sistem funkcionirati.Rezultat razvoja –– korisnički interfejs.
Prototip - moguć kao koncept unutar konteksta drugog modela.
Prototipni model se sastoji od sljedećih koraka:
skupljanje zahtjeva,
planiranje,
izrada i izmjena prototipa,
korisnikova ocjena prototipa,
dopuna i poboljšanje prototipa
izvođenje programskog rješenja.

PREDNOSTI, NEDOSTACI I UPOTREBA

PROTOTIPNOG MODELA
Prednosti prototipnog modela su :
 sposobnost prepoznavanja korisničkih informacijskih potreba na osnovu
testnog sistema,
 omogućuje realan prikaz značajnih gledišta sistema već u ranoj fazi razvoja,

11
 eMPIRICA – III Semestar: PRI 2013

 poboljšava uključenost krajnjih korisnika u projekt i komunikaciju između svih

uključenih strana,
 omogućava identifikaciju nejasnih funkcionalnosti i funkcionalnosti koje
nedostaju.

Nedostaci prototipnog modela su :

 manje stroga kontrola pojedinih faza projekta,
 opasnost izrade nepotpune ili neprikladne problemske analize prije izrade prve
verzije prototipa,
 često dolazi do većih promjena u zahtjevima,
 može voditi u loše planirane sisteme,
 može dovesti do pogrešnih očekivanja jer korisnici pogrešno misle da je sistem
završen, a zapravo još nije (izrađena je samo konačna verzija prototipa),
 svaka iteracija prototipa podrazumijeva dodatne troškove i kašnjenja projekta,
što treba prosuditi s obzirom na očekivanu korist.

Prototipni model koristimo u sljedećim situacijama:

 na opsežnim projektima s velikim brojem korisnika, brojnim funkcionalnostima
i prepletenim odnosima (potrebno je smanjiti rizik povezan sa specifikacijom
zahtjeva),
 ako su ciljevi projekta nejasni,
 ako postoji pritisak za neposrednim rezultatima,
 ako ne postoje predviđena stroga odobrenja prema pojedinim obavljenim
fazama i
 ako korisnici nisu sasvim iskusni u obavljanju svojih zadataka, pod
pretpostavkom da su razvojna grupa i vođa projekta iskusni te sastav grupe
stabilan.

PROTOTIPNI MODEL RAZVOJA – RAD

Uporaba prototipnog modela upitna je:
 ako su ciljevi objekta jasno definirani,
 ako je rizik povezan s definicijom zahtjeva zanemariv.
 RAD (Rapid Application Development) ‒ raširena verzija prototipnog modela

RAD uvodi detaljne vremenske okvire u svaku razvojnu fazu i uzda se u korištenje
alata za brzo planiranje i razvoj programskih rješenja. Osnovni naglasak metode je na
ispunjavanju poslovnih zahtjeva, dok su tehnologija i arhitektonska savršenost stavljeni u

12
 eMPIRICA – III Semestar: PRI 2013

drugi plan. Metoda RAD obično uključuje i metodu JAD (Joint Application Development),
koja naglašava intenzivnu uključenost korisnika već u samo planiranje sistema.
Pojam “Rapid Application Development” (brzi razvoj aplikacija) upotrijebio je, James
Martin, 1991.godine. Ova metoda koristeći kombinaciju više modela, stvara prototipove
koji se koriste u razvoju različitih programa koji nisu u nikakvoj međusobnoj vezi, ali su tako
koncipirani da mogu opisivati njihove poslovne procese. Ugrađen je i “Demingov krug”
kvalitete koji omogućava stalnu nadogradnju i poboljšanja prototipa u koji je uključen i
korisnik sa mogučnošću sudjelovanja u njegovom oblikovanju.
Tako je došlo do pojave raznih automatiziranih alata koji su u sebi već imali
predefinirane procedure za određeni proces upotrebljavajući znanje koje je već postojalo,
time se izbjeglo pisanje koda koji je bio karakterističan za neku radnju, recimo okvir za upis
tekstualnog podatka. Dostupnost “CASE” alata i odstupanje od tradicionalnog razvoja,
rapidno je povećalo učinkovitost programera i stabilnost programa.
Ovi alati programerima omogućuju “drag-and-drop” povlačenje generiranog koda i uz
minimalno kodiranje dobivanje traženog rezultata. Isto se događa na polju samog kodiranja,
granice između jezika u kojima se razvijaju programima nestaju, primjer je i Visual Studio
koji omogućava odabir jezika u kojem će programer raditi (C# ili VisualBasic), pa postoje i
“on-line” konvertori iz jednog u drugi jezik
(http://www.carlosag.net/tools/codetranslator/), ili ako ste navikli na “Pascal” tu je
dodatak “Oxygene for.NET” za Visual Studio. Sve u cilju što bržeg, kvalitetnijeg i jeftinijeg
razvoja programa koji će sa što većom fleksibilnošću pratiti rađanje i promjene poslovnih
procesa.

PREDNOSTI I KLOPKE RAD

Prednosti verzije RAD su:
 brz nastanak operativne verzije programskog rješenja u poređenju s ostalim
razvojnim modelima,
 mogućnost izvođenja brzih promjena plana sistema s obzirom na promjenljive
zahtjeve,
 fokusira se na bitne elemente sistema gledano s korisničkog stajališta
 općenito drastično smanjuje vrijeme potrebno za izvođenje projekta, sredstva i
ljudske resurse za izvođenje projekta.

Klopke verzije RAD:

 brži razvoj može dovesti do smanjenja kvaliteta sistema kao cjeline,
 opasnost nekonzistentnog planiranja unutar sistema i u vezi s drugim
sistemima,
 problem ponovnog korištenja modula,
 upitna nadgradivost sistema
13
 eMPIRICA – III Semestar: PRI 2013

PREPORUKE ZA RAD
RAD se preporučuje kod projekata:
 manji i srednje veliki razvojni projekti s kratkim rokovima,
 područje projekta je ograničeno,
 poslovni ciljevi su detaljno definirani,
 korisnici posjeduju podrobno znanje o području na kojem rade
 zahtjevi sistema su nepoznati odnosno nesigurni,
 članovi grupe su vješti i u tehnologiji i u poslovnoj domeni,
 uspostavljena je efikasna kontrola nad projektom,
 arhitektura sistema je jasno određena,
 osnovne programske komponente su već izrađene i provjerene,
 tehnološki zahtjevi su prihvatljivi i u granicama mogućnosti korištene
tehnologije.

RAD se ne preporučuje:
 U slučaju izgradnje opsežnih infrastrukturnih projekata (npr. opsežni podijeljeni
informacijski sistemi),
 kod sistema u realnom vremenu,
 kod sigurnosno-kritičkih sistema,
 kod sistema s kompleksnim računskim operacijama.

SPIRALNI MODEL RAZVOJA

Spiralni model je planiran s namjerom ujedinjavanja najboljih karakteristika modela
vodopada i prototipnog modela, a uključuje i novu komponentu ‒ ocjenu rizika. Slično kao
kod prototipnog modela, najprije se izradi početna verzija sistema koja se nakon toga
dopunjuje u skladu s napomenama korisnika. Ono što je kontrast s prototipnim je to da
razvoj svake sljedeće verzije sistema je brižljivo planiran, uključuje sve razvojne korake za
svaki dio proizvoda i za svaki nivo obrade, od općeg koncepta do samog izvođenja
programskog koda. Svaka iteracija rezultira u potpunijoj verziji sistema u izgradnji. Ocjena
rizika je uključena u razvojni proces s namjerom vrijednovanja svake verzije sistema i
primanja odluke o daljnjem radu a može i o prekidu.
Postupak spiralnog modela razvoja:
 Prvi korak svake iteracije je definisanje ciljeva projekta, predviđanje prepreka
za njihovo dostizanja, a razmišlja se i o mogućim alternativnim pristupima.
14
 eMPIRICA – III Semestar: PRI 2013

 U okviru ocjene rizika razmotre se moguće alternative i s njima povezani rizici i

problemi.
 Vrijednuju se potrebne aktivnosti za uklanjanje rizika, pri čemu se može
koristiti i prototipni pristup za uklanjanje nejasnoća.
 U slučaju odluke o nastavku projekta slijedi korak inženjeringa i izvođenja, u
kojem se specificiraju detaljniji zahtjevi i izrađuje se programsko rješenje.
 U koraku planiranja i upravljanja programsko rješenje analizira korisnik koji
navodi svoje konstatacije o ispitanoj verziji sistema, a izrađuje se i plan sljedeće
iteracije.

PREDNOSTI, NEDOSTACI I UPOTREBA

SPIRALNOG MODELA
Prednosti spiralnog modela su :
 Veća sposobnost izbjegavanja rizika
 Omogućavanje odabira najprikladnijeg modela (vodopada, prototipnog,
inkrementalnog itd.) za razvoj pojedine iteracije s obzirom na ocjenu rizika.

Nedostaci spiralnog modela su:

 moguće sumnje oko odabira prave kombinacije korištenih modela,
15
 eMPIRICA – III Semestar: PRI 2013

 tijesna povezanost i prilagođenost na svaki pojedini projekt, što povećava

kompleksnost i ograničava ponovno korištenje modela,
 odsutnost uvedenih kontrola za prelazak iz jedne iteracije u drugu,
 odsutnost detaljno definiranih rokova.

Spiralni model se koristi u sljedećim slučajevima :

 u projektima za koje je izbjegavanje rizika visoki prioritet,
 ako potrošnja izvora nije problematična,
 ako izvođenje ima prednost pred funkcionalnostima (one se mogu dodavati
naknadno),
 ako je vođa projekta vrlo iskusan,
 ako je od velike važnosti visok stupanj tačnosti i postoji zahtjev za jakom
kontrolom dokumentacije te dobivanjem odobrenja.

MODEL PONOVNOG KORIŠTENJA

Osnovni zahtjev modela ponovnog korištenja je da sistem mora biti izgrađen
korištenjem postojećih komponenata, a ne izgradnjom rješenja koja su prilagođena
korisnicima. Odgovara prije svega objektno orijentiranim razvojnim okolinama. Naglašava
izgradnju biblioteka modula (postupaka i podataka), koje se koriste u proizvoljnom sistemu.
Tokom izgradnje novog sistema, planer u što većoj mjeri uključuje postojeće module, inače
stvara nov, općekoristan modul koji podržava funkcionalnost koja nedostaje. Koraci
definiranja zahtjeva, definiranja potrebnih objekata, odabira postojećih i izrade novih,
izrade i vrednovanja prototipa, daljnji razvoj prototipa te prilagođavanje zahtjeva i samih
objekata.

Koraci modela ponovnog korištenja su:

 definiranja zahtjeva,
 definiranja potrebnih objekata,
 odabira postojećih i izrade novih,
 izrade i vrednovanja prototipa,
 daljnji razvoj prototipa te prilagođavanja zahtjeva i samih objekata.

Načelo ponovno korištenje programskog koda, objekata, strukture podataka i drugih

komponenata ‒ nepogrešno kod bilo kakvog razvoja modernih informacijskih sistema, bez
obzira na korišteni model razvojnog procesa, metodu ili metodologiju.

ISTRAŽIVAČKI MODEL RAZVOJA

16
 eMPIRICA – III Semestar: PRI 2013

U određenim situacijama je vrlo teško, ako ne i nemoguće, identificirati bilo kakav zahtjev
sistema na samom početku projekta. Projekti iz područja vještačke inteligencije gdje se
većina istraživanja temelji na hipotezama, ocjenama i nagađanjima.
Najprije se treba napraviti pretpostavka, na koji način bi sistem trebao djelovati, nakon čega
se koriste brze iteracije za uključivanje predloženih primjena i izgradnju upotrebljivog
sistema.Ocjena napravljenog sistema temelji se na primjernosti konačnog rezultata, a ne na
ostvarivanju prethodno određenih zahtjeva.
Koraci istraživačkog modela su:
 početni razvoj kratkih specifikacija (početna temeljna tačka),
 više iteracija izrade,
 prilagođavanje i testiranje sistema,
 implementacija konačnog rješenja u ciljnu okolinu.
Problemi istraživačkog modela su:
 ograničenost na visokorazinske programske jezike koji omogućavaju brz razvoj
(npr. Lisp),
 problemi kod predviđanja i mjerenja troškovne efikasnosti,
 opasnost izrade neefikasnih i loše planiranih sistema jer cjelokupni sistem nije
unaprijed promišljen

17
 eMPIRICA – III Semestar: PRI 2013

PREDAVANJE 2

INFORMACIJSKI INŽENJERING
Predstavlja primjer strukturnog pristupa koji je bio popularan u drugoj polovini '80-ih
godina – Martin, Finkelstain.
Temeljni principi strukturnog pristupa su :
 analiza podataka (Data Analysis),
 nezavisnost podataka (Data Independence),
 strateško podatkovno planiranje (Strategic Data Planning),
 jednostavan pristup korisnika bazi podataka (End-User Access).

Podatkovno gledište informacijskog inženjeringa čini:

 Globalni model podataka
 Konceptualni model podataka
 Logički model podataka
 Fizički model
 Baza podataka

18
 eMPIRICA – III Semestar: PRI 2013

Globalni model podataka se koristi za prikupljanju ideja za rješenje problemske

domene. Neovisan je o implementacijskim detaljima (izabranoj bazi, programskom jeziku).
Svrha je definiranje značenja, pojmova i koncepata koje eksperti koriste u razradi
problemske domene za pronalaženje ispravnih odnosa između različitih koncepata.
Konceptualni model (conceptual data model) opisuje semantiku organizacije. Sastoji se od
odnosa (relationships)–tvrdnji o asocijacijama između parova klasa entiteta.
Logički model (logical data model) opisuje semantiku kakva je data izborom modela za
manipulaciju podataka. Opisuje logičku reprezentaciju svojstava neovisno o tehnologiji za
manipulaciju podatcima. Sastoji se od opisa atributa (uloge koju podatkovni elementi igraju
u odnosu na stvari (entitete) koje predstavljaju ) od tablica i kolona, objektno orijentiranih
klasa, XML tagova.
Fizički model ( physical data model) opisuje fizičko značenje pohranjenih podataka –
način kako se pristupa podatcima u tablicama, procesorske karakteristike i slično.

MODEL ER
Konceptualno planiranje podataka čini prezentacija korisničkih podatkovnih zahtjeva
korištenjem konceptualnog (semantičkog) modela podataka. Najrašireniji konceptualni
model za planiranje baza podataka je model odnos entiteta ER (Entity Relationship) ‒ koji je
1976. godine utemeljio Peter P. Chen. Model se temelji na ljudskom percipiranju realnog
svijeta koji je moguće prikazati sa dva osnovna koncepta: entitet i odnos.
Model ER doživio je još nekoliko promjena i dopuna, ali je osnovna ideja ostala
nepromijenjena:
 razvoj različitih grafičkih notacija odnosno dijagramskih tehnika ‒ (IDEFIX,
informacijski inženjering itd.), koje se više ili manje približavaju
karakteristikama površinskih podatkovnih modela,
 uvođenje novih koncepata – generalizacija, agregacija ‒>nastaje rašireni model
ER (Extended Entity Relationship).
Brzi razvoj CASE alata (Computer Aided Software Engineering) u devedesetim
godinama je dodatno pridonio značaju modela ER kao temeljnom opisnom mehanizmu za
konceptualno planiranje baza podataka. CASE alati omogućavaju automatsko prevođenje
modela ER u relacijski model i daljnje uspostavljenje fizičke baze podataka korištenjem
jezika SQL.
Konkretni sistemi za upravljanje bazama podataka zasnovan na ER modelu podataka
(često nazivan i prošireni model objekti-veze tj. PMOV) ne postoji, nego se vrši prevođenje
iz ovog semantički bogatijeg u semantički siromašniji relacioni model. Za geometrijsku
reprezentaciju koncepata modela koriste se grafovi (intenzija) i tabele (ekstenzija modela).
Iako je ER model podataka kompletan (postoje opisi sve tri komponente modela podataka),
sam model je prije svega namjenjen projektovanju statičkog modela – zbog dijagramskog
19
 eMPIRICA – III Semestar: PRI 2013

prikaza i bogate semantike. Model je smisaono (semantički) bogat ako se njegovim

konceptima mogu modelirati praktično svi realni sistemi.
Jednostavno ER model je konceptualni model podataka koji realni svijet “vidi” kroz
entitete i njihove odnose. Osnovno svojstvo modela je dijagramska tehnika kojom se objekti
podataka predstavljaju vizuelno.

TEMELJNI KONCEPTI MODELA ER

Temeljni koncepti ER modela su:

Entitet: objekt koji postoji i može se odvojiti od drugih objekata. Entitete dijelimo
na realne (predstavljaju neki realan objekt, događaj) i apstraktne (predstavljaju
ideju).

Atribut: pojedina karakteristika entiteta. S gledišta brojnosti dijelimo atribute

na osnovne ili složene (nije moguća daljnja
podjela), sastavljene ili složene (sastavljene od većeg broja osnovnih) te
na totalne (atribut uvijek sadrži vrijednost) iparcijalne (vrijednost nije obavezna).

Tip entiteta: mnoštvo entiteta istoga tipa. Tip entiteta određen je odgovarajućim
mnoštvom atributa. Tipu entiteta pripada skup entiteta, koje definiramo kao entitetni
skup.

Ključ (identifikator entiteta): atribut ili grupa atributa koji jednolično određuju
entitet unutar tipa entiteta. Svaki tip entiteta sadrži barem jedan glavni ključ, a može i
više pomoćnih.

Odnos (tip povezivanja): opis grupe istovrsnih povezanosti. Može ujedinjavati sva
povezivanja istog tipa između dva ili više entiteta.
Uz osnovne koncepte prošireni model ER sadrži još:

Generalizacija: specificira odnos tip – podtip između dva ili više tipa entiteta odnosno
skup – podskup, ako tip entiteta uzimamo kao skup entiteta.

Domena: skup vrijednosti koje može imati neki atribut. Model ER direktno ne
prikazuje domen, ali ih koriste CASE alati.

20
 eMPIRICA – III Semestar: PRI 2013

ENTITET
Naziv entiteta zajedno sa svojim atributima čini tip entiteta unutar kojega može postojati
više instanci (pojava) entiteta.Entiteti se predstavljaju imenicama.
Entiteti mogu biti: živa bića, predmeti, događaji iz realnog sistema. Entiteti posjeduju neka
svojstva (osobine, obilježja) i mogu se postaviti u različite odnose sa drugim entitetima, a
takođe, moguće je ustanoviti i hijerahiju nasljeđivanja (IS-a hijerarhiju) u klasama tipova
entiteta.
Entitet po svojoj prirodi može biti različit:
 Dio okruženja (član kolektiva, aparat, zgrada, artikal, vozilo ...)
 Apstraktni pojam (neka mjera, nečije zvanje, boja, ...)
 Događaj (udes, postupak upisa studenata,...)
 Asocijacija (student-predmet, predmet-profesor, ..., fakultet-profesor)

Nezavisni entiteti su entiteti koji imaju sopstvenu identifikaciju, tj. nisu zavisni od
drugog entiteta.
Zavisni entiteti su entiteti čija je egzistencija i identifikacija zavisna od drugog ili
drugih entiteta. Zavisan (slab) objekat ne može da postoji bez (egzistencijalno je zavisan od)
nadređenog (jakog)objekta. Slab objekat ne može da se identifikuje bez (identifikaciono je
zavisan od) veze sa nadređenim objektom.
U grafičkom prikazu se prikazuje pravougaonikom unutar kojega je upisan naziv tipa
entiteta

ASOCIJATIVNI ENTITET
Asocijativni entitet je entitet koji može da postoji samo između dva ili više drugih
entiteta, i koji egzistira da bi pamtio informacije o odnosu između tih entiteta. Na primjer,
osoba može da bude član u većem broju klubova i klub može da ima više članova, što se
predstavlja sljedećim ER dijagramom :

21
 eMPIRICA – III Semestar: PRI 2013

Prethodni ER dijagram možemo da preformulišemo tako da više prema- više odnos

zamjenimo sa dva jedan – prema - više odnosa sa asocijativnim entitetom u sredini:

Ova reprezentacija je poželjnija jer se direktno preslikava na bazu podataka koja će

biti kreirana kao rezultat ovog odnosa. Odnos više prema - više mora biti predstavljen
posebnom tabelom, baš kao što se i posebni tipovi entiteta predstavljaju posebnim
tabelama. U tom slučaju imamo asocijativni entitet koji se koristi da predstavi odnos
između dva tipa entiteta.
Za očekivanje je da se odnosu osoba i klubova pridruži podatak o datumu učlanjenja.
Ovaj atribut se ne može pridružiti tipu entiteta osoba jer se ne bi znalo na članstvo u kom
klubu se odnosi. Ne bi mogao da se pridruži ni tipu entiteta klub jer se ne bi znalo na
učlanjenje kog njegovog člana se datum učlanjenja odnosi. Rješenje je da se “datum
učlanjenja” dodjeli kao atribut asocijativnom entitetu članstvo.
Postupak kojim smo došli do asocijativnog entiteta je uobičajeni postupak razvoja ER
dijagrama: prvo jednostavniji dijagrami (sa više – prema - više odnosima) a zatim
profinjeniji, sa asocijativnim entitetima koji ih zamenjuju.

ATRIBUT
Atribut predstavlja karakteristiku (svojstvo) koja pobliže opisuje entitet. Može poprimiti
vrijednost iz određenog skupa vrijednosti koji predstavlja domen (tip vrijednosti) tog
atributa. Svaki atribut u u jednom trenutku ima neku vrijednost. Atribut ili skup atributa koji
jednoznačno određuje svaku pojavu entiteta se naziva ključ tipa entiteta.
Vanjski ključ: grupa atributa koji jednolično određuju pojedini entitet unutar povezujućeg
tipa entiteta.
 Model ER formalno ne sadržava vanjski ključ koji faktički predstavlja zamjenu
tipa povezivanja modela ER u relacijskoj teoriji.
 Kasnije notacije, nastale prije svega u svjetlu modeliranja relacijskih baza
podataka, to su promijenile i u skup svojih elemenata uvele i koncepte
relacijske teorije (vanjski ključ i domen)
22
 eMPIRICA – III Semestar: PRI 2013

Grafički se prikazuje elipsom unutar koje je upisan naziv atributa. Ključni atributi se
podvlače.

Atribut je zajednička osobina koju poseduju svi entiteti jedne klase. Broj atributa nije fiksan
a relevantne atribute definiše kompetentna osoba od čega zavisi upotrebljivost dobijenih
informacija. Atributi svih entiteta poprimaju određene vrijednosti.

Premalo atributa:
 model jednostavan za predstavljanje i analizu,
 vjerodostojnost mala,
 ograničen je broj upotrebljivih informacija

Previše atributa:
 vjerodostojnost odlična,
 kompleksnost velika,
 manipulacija podacima teško izvodljiva,
 dobijaju se konfuzne informacije.

Zadatak projektanta: prepoznavanje prave mjere pri modelovanju (izbor relevantnih

atributa).
Primjer: Vrijednosti atributa entiteta STUDENT (jedan entitet iz klase studenata):
BrInd: 123/13
Ime: Alen
Prezime: Alić
Studijski program: Inženjerska informatika
Adresa: Bosne Srebrne 16, Brčko

Osnovna pravila za definisanje atributa su:

 Svaki entiteta ima proizvoljan broj atributa
 Određeni atribut pripada jednom i samo jednom entitetu
23
 eMPIRICA – III Semestar: PRI 2013

 Svako pojavljivanje entiteta ima vrijednosti za sve atribute tog enititeta

 Atribut određenog pojavljivanja entiteta može imati samo jednu vrijednost
 Različita pojavljivanja entiteta mogu, a ne moraju imati različite vrijednosti za
isti atribut
 Svaki atribut mora imati samo jedno konzistentno značenje

ODNOS (TIP POVEZIVANJA)

Odnos ili veza između pojava jednog ili više tipova entiteta koji je od značaja za
poslovanje. Veza upućuje na to da je se pojavio događaj ili da postoji prirodna veze između
tipa entiteta. Grafički se prikazuju rombom.
Stepen veze predstavja broj entiteta koje promatrana veza povezuje:
 Binarna, ternarna itd.
 Refleksivna - kada jedan entitet u vezi ima dvije različite uloge

Postoje tri osnovne kardinalnosti binarnog odnosa (između tipova entiteta X i Y):
• 1:1
– jedan prema jedan — Jedan entitet tipa X može biti pridružen najviše jednom entitetu
tipa Y. Jedan entitet tipa Y može biti pridružen najviše jednom entitetu tipa X. Primjer:
automobil i volan.
• 1:M
– jedan prema više — Jedan entitet tipa X može biti pridružen većem broju entiteta tipa Y.
Jedan entitet tipa Y može biti pridružen najviše jednom entitetu tipa X. Primer: zgrada i
prostorije.
• M:M

24
 eMPIRICA – III Semestar: PRI 2013

– više prema više — Jedan entitet tipa X može biti pridružen većem broju entiteta tipa Y.
Jedan entitet tipa Y može biti pridružen većem broju entiteta tipa X. Primer: automobil i
oprema.

Odnosu se može odrediti naziv i brojnost.

Brojnost: broj entiteta pojedinog tipa entiteta koji mogu surađivati u odnosu s entitetima
drugih tipova entiteta i koji mogu imati vrijednosti 0 (nijedan), 1 (tačno jedan) i N (više).
 Neke notacije modela ER (npr. osnovna Chenova) omogućuju korištenje
konstanti (npr. 5) kod određivanja brojnosti, dok većina ostalih (prije svega
onih koji se naginju prema relacijskim podatkovnim modelima) dopušta samo
određivanje uvjetnog, obaveznog ili višekratnog odnosa

GENERALIZACIJA
Proces uzimanja nekoliko srodnih entiteta i kreiranje generalne superklase.
Generalizacija je apstrakcija u kojoj se skup sličnih tipova objekata pretstavlja opštijim
generičkim tipom (nadtipom).
Pod sličnim tipovima objekata ovdje se mogu tretirati tipovi objekata koji imaju jedan
broj istih (zajedničkih) atributa, tipova veza sa drugim objektima i operacija.

25
 eMPIRICA – III Semestar: PRI 2013

Primjeri generalizacije (IS_A hijerarhija)

26
 eMPIRICA – III Semestar: PRI 2013

Martinova notacija

Poveznice (veze) s brojnošću 1:N

27
 eMPIRICA – III Semestar: PRI 2013

Poveznice (veze) s brojnošću M:N

Identifikujuće veze koje entitet dijete identifikuje kroz njegovu vezu sa entitetom
roditelj (ljekar-pacijent).
Neidentifikujuće veze koje ne identifikuju entitet dijete preko identifikatora entiteta
roditelja.
Veza prema podtipovima uspostavlja vezu između entiteta i njegovih zavisnih,
klasnih entiteta.
Neodređujuće veze koje se smatraju veze više prema više.

28
 eMPIRICA – III Semestar: PRI 2013

GLAVNI KORACI MODELA

Glavni koraci modela su :
 Odrediti tipove entiteta
 Odrediti koji tipovi entiteta grade odnos
 Profiniti definiciju odnosa
 Postoji više metoda / tehnika za grafičku reprezentaciju ER modela.

Za predstavljanje odnosa neke koriste liniju sa nazivima na njoj, drugi koriste romb.
Najčešći scenario:
 Poći od tekstualnog opisa problema
 Analizirati ga i uvesti neophodne pretpostavke
 Kreirati ER dijagram koji odslikava situaciju i eksplicira odnose među tipovima
entiteta
 Korak od ER dijagrama ka implementaciji baze podataka biće pravolinijski
 Kreiranje baze podataka jeste glavni cilj

PRELAZAK IZ KONCEPTUALNOG U
LOGIČNO MODELIRANJE
Model ER predstavlja prelazak iz konceptualnog u logično modeliranje

Preslikavanje odnosa s kardinalnošću 1:M

 Ključ na strani odnosa s kardinalnošću 1 dodamo kao nov stupac u tablicu koja
predstavlja tip entiteta na strani M. Takav ključ označujemo kao strani (foreign)
ključ.
29
 eMPIRICA – III Semestar: PRI 2013

Preslikavanje odnosa s kardinalnošću M:N

 Odnos s kardinalnošću M:N uvijek preslikavamo u novu relaciju.
 Atributi tabele su ključevi tipova entiteta, koji su povezani s odnosom i zajedno
sačinjavaju ključ novonastale relacije. Ključ relacije, koji nastaje kao posljedica
odnosa M:N, uvijek je sastavljen.
 U novonastalu relacijsku shemu dodamo još i atribute odnosa. Ti atributi u
načelu nisu sastavni dio ključa odnosa, ali postoje i iznimke.

30
 eMPIRICA – III Semestar: PRI 2013

PREDAVANJE 3

DEKOMPOZICIJSKI DIJAGRAM
Raščlanjivanje cjeline na njegove dijelove naziva se dekompozicijskim
dijagramom.Dekompozicijskim dijagramom se informacijski sistem raščlanjuje na
podsisteme (funkcije), podsistemi (funkcije) na procese, procesi na potprocese, potprocesi
na aktivnosti (Varga, 2007.). Aktivnosti se isto tako mogu raščlanjivati.
Na sljedećoj slici je prikazan način formiranja općeg dekompozicijskog dijagrama.

Aktivacija potprocesa može biti:

 Uzastopna - ako se sljedeći proces aktivira nakon završetka prethodnog
 Iterativna - ako se nakon završetka zadnjeg procesa ponovno aktivira prvi
proces.
 Paralelna / istovremeno.
 Vjerojatna / stohastičko - na aktivaciju utječu slučajni događaji.
 Po odabiru / selektivno - ako se aktivacija procesa izvodi izvana (meniji).
Dekompozicijski dijagram sklapanja osiguranja prikazan je na sljedećoj slici:

31
 eMPIRICA – III Semestar: PRI 2013

Karakteristike dekompozicijskih dijagrama:

 ne prikazuju uvijek paralelni tok procesa,
 ne prikazuju uvijek pravilan redoslijed procesa, iako pokušavamo tokom
modeliranja uzimati u obzir najčešći redoslijed.
Pravila oblikovanja dekompozicijskog dijagrama su:
 svaki dekompozicijski dijagram prikazuje se na jednom listu papira (A3 ili A4),
 svaki proces dijeli se na 5 do 9 potprocesa,
 sve komponente jednog nivoa moraju biti na otprilike jednakom nivou
apstrakcije,
 unutarnja povezanost procesa na nižim nivoima mora uvijek biti jača, a vanjska
uvijek slabija,
 elementarni procesi ne raščlanjuju se dalje.

32
 eMPIRICA – III Semestar: PRI 2013

VRSTE DEKOMPOZICIJSKIH DIJAGRAMA –

DEKOMPOZICIJSKI DIJAGRAM PROCESA
Postoji pet vrsta dekompozicijskih dijagrama:
 Dekompozicijski dijagram procesa
 Dekompozicijski dijagram lokacija
 Dekompozicijski dijagram organizacijskih jedinica
 Dekompozicijski dijagram problema
 Dekompozicijski dijagram ciljeva

Dekompozicijski dijagram procesa

U dekompozicijskom dijagramu sistema prodaje možemo prepoznati više procesa
koje ćemo razvrstati u sljedeće skupine:
 Nabava
 Skladište
 Proizvodnja
 Prodaja
 Ekspedit
 Financije, knjigovodstvo i računovodstvo

Uvjet kod ovakvog sistema jest da postoje kupci ili klijenti koji su zainteresirani i voljni
kupiti proizvod ili uslugu. Kada imamo zainteresiranu stranu, procesi su ništa drugo nego
životni ciklus proizvoda koji će se na kraju isporučiti kupcu.

33
 eMPIRICA – III Semestar: PRI 2013

Opis procesa koji je predstavljen na dekompozicijskom dijagramu procesa:

34
eMPIRICA – III Semestar: PRI 2013

35
eMPIRICA – III Semestar: PRI 2013

36
 eMPIRICA – III Semestar: PRI 2013

DEKOMPOZICIJSKI DIJAGRAM PROBLEMA

Glavni problem poduzeća prodaje jest neefikasno poslovanje. Problem se najviše
odnosi na potporne funkcije poduzeća kao što su financije, knjigovodstvo i računovodstvo
kao i komercijala u kojima se stvaraju velike količine dokumentacije, a manjim dijelom na
samu operativu, odnosno proizvodnju. Poduzeće susreće se sa nekoliko problema u svom
poslovanju vezanih uz borbu sa konkurencijom, rokovima, tržištem i prodajom.

Opis problema
Neefikasno poslovanje kao glavni problem predstavlja skup pojedinih problema
poduzeća vezanih uz neefikasnost dokumentacije i nedovoljnu povezanost organizacijskih
jedinica.
Zaostajanje za konkurencijom je problem koji dovodi do smanjenja prodaje na
domaćem i inozemnom tržištu, a samim time i manje prihode i ostvarenje profita. Ovaj

37
 eMPIRICA – III Semestar: PRI 2013

problem se konkretno sastoji od problema upotrebe zastarjelih strojeva za proizvodnju te

zastarjelog informacijskog sustava i nedovoljnu upotrebu ICT-a.
Upotreba zastarjelih strojeva za proizvodnju i tiskanje materijala dovodi do manjeg
proizvodnog kapaciteta i većih troškova proizvodnje po jednici proizvoda u odnosu na
konkurenciju, a samim time i zaostajanje za konkurencijom.
Zastarjeli IS je također izvor problema poduzeća u smislu sporije obrade podataka,
informacija i dokumenata vezanih uz organizacijske jedinice poduzeća, kao i veće troškove
obrade što ponovno dovodi do zaostajanja za konkurencijom, dok se nedovoljna upotreba
ICT-a odnosi na ne razvijen sistem komunikacije sa suradnicima, dobavljačima, kupcima
preko informacijske tehnologije koji bi doveo do znatnog smanjenja troškova komunikacije.
Nepridržavanje rokova je problem koji se javlja usred zakašnjenja proizvodnje i isporuke
proizvoda kupcima, a koji pak dovodi do smanjenja lojalnosti kupaca, a time i smanjenje
prodaje.
Nestabilno tržište je problem koji eksterno utječe na poslovanje poduzeća preko pada
kupovne moći kupaca te problema s naplatom prodanih proizvoda radi svjetske krize i
općeg stanja tržišta u državi.
Smanjenje prodaje je također problem vezan uz svjetsku krizu i pad kupovne moći koji
dovode do smanjenja prodaje na domaćem i inozemnom tržištu što sigurno ima jako loš
utjecaj na poslovanje poduzeća.

DEKOMPOZICIJSKI DIJAGRAM PROCESA

Ciljevi i problemi su usko povezani, odnosno, ciljevi su donekle generirani iz
problema. Glavni cilj koji je preduzeće prodaje postavio za tekuću godinu jest ostvariti
dobit. Ciljeve i strategije poduzeća donosi nadzorni odbor, a sprovode se na nižim razinama,
dakle upravi i izvođenju.
Da bi poduzeće to uspješno obavilo predviđanja su pokazala da je potrebno:
 Zadržati barem 75% prodaje iz prethodne godine
 Povećati zadovoljstvo kupaca za minimalno 10%
 Smanjiti potrošnju neobnovljivih izvora energije za minimalno 20%
 Zadržati ISO 9001 i ISO 14001 certifikate i
 Unaprijediti postojeći informacijski sustav

38
 eMPIRICA – III Semestar: PRI 2013

Dekompozicijski dijagram procesa je predstavljen na sjedećoj slici:

Raščlanljivanjem cilja da se zadrži 75% prodaje od prethodne godine može se vidje da

za njegovo ostvarenje je potrebno povećati prodaju na domaćem tržištu za barem 15%,
također je potrebno povećati prodaju na inozemnom tržištu za barem 10%, te je potrebno
povećati online marketing jer smatra se da putem interneta poduzeće može zadobiti nove
klijente. Da bi cilj povećanja zadovoljstva kupaca za 10% bio ostvaren, potrebno je nabaviti
5 novih kamiona kako bi se isporuka mogla izvršiti čim većem broju klijenata.
Ostali ciljevi koji su vezani direktno za glavni cilj su smanjiti potrošnju neobnovljivih
izvora za 20%. Neobnovljivi izvori su skuplji, pa su i troškovi proizvodnje veći. Cilj zadržati
ISO 9001 i ISO 14001 su za poduzeću bitni jer prisiljavaju na vršenje proizvodnje po
standardima koji ujedno smanjuju nepotrebne korake u poslovnom procesu i štite okoliš.
Cilj poboljšavanja informacijskog sistema jest na kraju, ali je vrlo važan. IS radi one dosadne

39
 eMPIRICA – III Semestar: PRI 2013

poslove koji se daju automatizirati, te tako ostavlja vremena radnicima da rade poslove
bitne za poduzeće.

DEKOMPOZICIJSKI DIJAGRAM
ORGANIZACIJSKIH JEDINICA

40
 eMPIRICA – III Semestar: PRI 2013

Poduzeće prodaje sastoji se od sedam glavnih organizacijskih jedinica i to:

 Komercijala
 Uprava
 Proizvodnja
 Skladište
 Financije
 Knjigovodstvo i računovodstvo
 Kontrola i razvoj (KiR)
 Ekspedit
Komercijala je u mnogim poduzećima organizacijska jedinica koja integrira nabavu i
prodaju. Kroz komercijalne poslove vezane uz nabavu obrađuju se razne narudžbe i upiti
dok se kroz komercijalne poslove vezane uz prodaju obrađuju razni predračuni i ponude.
Uprava je organizacijska jedinica koja se nalazi neovisno od proizvodnje, a kao što
sam naziv govori, osnovna joj je zadaća upravljati cijelim poduzećem, odnosno svim
poslovima unutar njega.
Proizvodnja je organizacijska jedinica unutar koje se vrši osnovna djelatnost
poduzeća: priprema materijala i održavanje. Organizacijske jedinice unutar proizvodnje su
formirane tako da se prolaze slijedno od početka do kraja izrade proizvoda. Proizvodnja je
ustrojena na ovaj način s ciljem specijalizacije, odnosno povedanja učinkovitosti i kvalitete
proizvodnje te smanjenja troškova.
Skladište je organizacijska jedinica koja je direktno povezana s nabavom. Jedinica
nabave naručuje robu i materijale potrebne za proizvodnju, dobavljači ih isporučuju te se
oni primaju na skladište gdje se njima manipulira i na posljetku izdaje u proces proizvodnje.
Financije, knjigovodstvo i računovodstvo kao organizacijska jedinica sastoji se od
pravnih i općih poslova, financija, knjigovodstva te planer analitičara. U ovom se sektoru
vrše poslovi financijskog praćenja transakcija te poslovnih promjena, izdanih računa,
izrađuju se financijski izvještaji, obračunavaju se i isplaćuju plate itd.
KiR se sastoji od jedinica kontrole i razvoja koje se bave kontrolom kvalitete
proizvoda, materijala, tehnika i tehnologija te u skladu s kontrolama i mjerenjima predlažu i
uvode razne tehnike poboljšanja izrade, skladištenja i prodaje proizvoda.
Ekspedit je organizacijska jedinica koja se bavi skladištenjem i organiziranjem gotovih
materijala i proizvoda, izašlih iz proizvodnje, do vremena isporuke kupcima.

41
 eMPIRICA – III Semestar: PRI 2013

DEKOMPOZICIJSKI DIJAGRAM LOKACIJA

Primjer opisa i dijagram dekompozicije lokacija za poduzeće prodaje dato je u
nastavku:
Poduzeće prodaje smješteno je na samom ulazu u grad. Prometno je vrlo dobro
povezano i lako dostupan preko ne tako davno izgrađene zaobilaznice. Cijeli kompleks
poduzeća smješten je na ogromnih 50.000 m2 koji je izvrsno uređen i uvijek održavan. Oko
cijelog kompleksa nalaze se sadnice jabuka gdje zaposlenici tvrtke prakticiraju
svojevrstan team-building, a nerijetko se u berbu pozivaju sadašnji i potencijalni poslovni
partneri.
Na ulazu u poduzede smještena je porta u kojoj dežuraju zaštitar i portir, te prate
svaki ulaz u kompleks. Oni su također zaduženi za sigurnost imovine na parkiralištu koje
poduzede djelomično dijeli s susjednom firmom.
U upravnoj zgradi poduzeća nalazi se:
 Uprava
 Komercijala
 Financije, knjigovodstva i računovodstva i
 Kontrola i razvoj (KiR)

Skladište se nalazi nekoliko koraka od upravne zgrade i „logički“ je odvojeno na

ulazno i izlazno skladište tj. skladište u koje se zaprimaju materijali koji služe u proizvodnji i
ekspedit u kojem se otpremaju gotovi proizvodi. Pogon čini posebna hala u kojoj se vrši
priprema za proizvodnju i sama proizvodnja. U sklopu kompleksa izgrađena je i posebna
zgrada u kojoj se nalazi kantina i restoran gdje zaposlenici provode svoje odmore.
42
 eMPIRICA – III Semestar: PRI 2013

DIJAGRAMI TOKOVA PODATAKA

Dijagram tokova podataka prikazuju što aplikacija radi odnosno što će raditi na logičkom
nivou. Mogu opisivati svakovrsne tokove podataka. Ne samo elektroničke. Značajni su za
komunikaciju između korisnika i analitičara.
Postoji više faza izrade dijagrama toka podataka:
 kontekstni dijagram,
 razrađeni pojedini procesi,
 analiza strukture podataka,
 rječnik podataka,
 vrednovanje.
Osnovni elementi dijagrama toka podataka su :
 procesi koji pretvaraju ulazne tokove podataka u izlazne,
 skladišta podataka,
 vanjski izvori i ponori podataka / vanjski izvori podataka,
 tok podataka.

43
 eMPIRICA – III Semestar: PRI 2013

DIJAGRAM TOKA PODATAKA - TOK

PODATAKA
Tok podataka predstavlja: grupa ulaznih ili izlaznih podataka procesa. Tok podataka
povezuje ostale elemente dijagrama. Kanal preko kojeg teku podaci.
Postoje dva značenja:
 Predstavlja agregat grupe podataka:
o elementarni podatak (devizni kurs)
o formalizirani dokument (upisni list)
o formaliziranu grupu dokumenata (molba za izdavanje građevinske dozvole)
o drugi formalizirani i neformalizirani oblici podataka i informacija
o Prikazuju put podataka kroz sistem
o od vanjskog izvora u proces ili iz procesa prema vanjskom izvoru
o među procesima
o među procesima i skladištem podataka

Svaki tok podataka ima opis ‒ podaci u skladište / iz skladišta podataka obično nose
ime samog skladišta
Postoje sljedeće vrste tokova:
 ulazni,
 izlazni i
 unutarnji.

44
 eMPIRICA – III Semestar: PRI 2013

DIJAGRAMI TOKOVA PODATAKA ‒ PROCES

Proces je grupa aktivnosti koja grupu ulaznih tokova podataka pretvara u grupu
izlaznih. Proces je opšti pojam za sve funkcionalne komponente (funkcijsko područje,
aktivnost, zadatak) i predstavlja jedini aktivni element. Svaki proces ima najmanje jedan
ulazni i najmanje jedan izlazni tok podataka. Temeljni procesi nisu međusobno direktno
povezani, nego preko skladišta podataka..Direktno povezivanje dvaju procesa često znači
kombinaciju ručne i strojne obrade podataka
Skladište podataka pohranjuje izlazne podatke procesa koji su na raspolaganju
drugim procesima. Možemo ga opisati kao akumulaciju tokova podataka
Skladište podataka može biti:
 dokument (tablica),
 datoteka ili baza podataka,
 informacijsko-dokumentacijski centar…

U fazi analize obrađujemo logičke grupe podataka, čiji budući fizički oblik još nije
bitan. U skladištu možemo izvoditi sve operacije s podacima ali ne možemo uzimati podatke
koji nisu bili pohranjeni u skladištu. Strukturu skladišta određujemo podatkovnim modelom.
Vanjski izvori podataka predstavljaju vanjske procese ili sisteme. Za takve izvore nas ne
zanima njihova struktura. Zanimaju nas samo podaci koji se izmjenjuju s procesima našeg
dijagrama. Svi procesi koji nisu dio obrađivanog sklopa pripadaju vanjskim sistemima, što
znači da postaju vanjski izvori podataka.

45
 eMPIRICA – III Semestar: PRI 2013

Tokom analize definira se velik broj procesa. Dijagrami s previše elemenata su nečitki.
Dijagrami tokova podataka i dijagrami funkcionalne dekompozicije mogu se graditi skladno
‒ svako čvorište dijagrama funkcionalne dekompozicije predstavlja svoj dijagram tokova
podataka. Numeriranje je uređeno u skladu s hijerarhijskom strukturom (1.4.3.6). Uglavnom
je broj dijagrama na nižem nivou jednak broju procesa na višem nivou. Dijagrami tako nose
imena procesa koje raščlanjuju. Vanjski izvori podataka ne bi se trebali prikazivati na nižim
nivoima. Zakon o očuvanju tokova podataka. Svi tokovi podataka koji ulaze i izlaze iz
procesa moraju biti sačuvani na nižem nivou.

DIJAGRAMI TOKOVA PODATAKA –

KONTEKSTNI DIJAGRAM – NIVO 0

Pravila koja je potrebno poštovati prilikom izgradnje dijagrama toka podataka:

 Tok podataka mora proizlaziti iz procesa ili u njega ulaziti. Tok podataka ne
smije povezivati dva pasivna elementa.
 Ne postoje procesi samo s ulaznim ili samo s izlaznim tokovima.
 Svako skladište podataka mora imati barem jedan ulazni i barem jedan izlazni
tok podataka. Procesi kojima trebaju podaci ili koji dostavljaju podatke
skladišta mogu postojati na drugom nivou.

46
 eMPIRICA – III Semestar: PRI 2013

 Skladište podataka javlja se na onom nivou gdje povezuje dva ili više procesa.
Ako se skladištem bavi samo jedan proces, to je pitanje procesa koji će se
razgraditi na nižem nivou.
 Raščlanjivanje je smisleno dok procesi nisu temeljni odnosno dok teško
definiramo skladišta podataka među njima. U načelu se mogu opisati kao
samostalni procesi.

DIJAGRAMI TOKOVA PODATAKA ‒

KONTEKSTNI DIJAGRAM RESTORANA

Prvi nivo naručivanja hrane

47
 eMPIRICA – III Semestar: PRI 2013

PREPORUKE I KARAKTERISTIKE
DIJAGRAMA TOKOVA PODATAKA
Preporuke koje je dobro pratiti prilikom pravljenja dijagrama toka:
 dijagram bi trebao sadržavati od 5 do 9 procesa,
 mora biti jasno oblikovan,
 sve komponente i dijagrami moraju biti jasno i jednoznačno imenovani,
 svako ponavljanje na jednom ili različitim dijagramima mora biti
označeno; procesi se prikazuju samo jedanput
 izrađujemo ih u više koraka i oni su tehnika logičkoga oblikovanja –
analiza.
Karakteristike izrade dijagrama toka:
 postupak je iterativan,
 dijagrami su logički modeli, zbog toga ne smijemo težiti tehničkom
savršenstvu,
 izbjegavanje programerskog sindroma tehničkog savršenstva jer korisnici
nisu programeri.

48
 eMPIRICA – III Semestar: PRI 2013

PREDAVANJE 4

STRUKTURNI DIJAGRAMI
Strukturni dijagram ‒ hijerarhijski prikazuje uređenost modula programskog rješenja.
Svaki modul predstavljen je s pravougaonikom, a poveznice (strelice) između njih određuju
vlasništvo modula (smjerove pozivanja) odnosno njihovih aktivnosti i podaktivnosti.
Strukturni dijagrami planerima omogućavaju podjelu kompleksnog problema na
podprobleme u skladu s principom podijeli pa vladaj (funkcionalna dekompozicija). Iz
strukturnog dijagrama razvidni su opseg i kompleksnost sistema, broj modula unutar
pojedine funkcije i kompleksnost svake pojedine funkcije (potreba po daljnjoj podjeli).
Izrada strukturnog dijagrama počinje od vrha prema dolje ‒ najprije se definira korijen
hijerarhijske strukture. Slijedi analiza ključnih aktivnosti koje sistem mora izvesti za potrebe
dostizanja konačnog rezultata, iz čega nastaje skup modula na nižem hijerarhijskom nivou.
Dekompozicija se nastavlja dalje sve dok listovi drveta ne opisuju pojedine metode sistema
u izradi-

Strukturni dijagram prikazuje tok podataka i kontrole između modula:

 Tok podataka: strelice s praznim kružićem na repu
 Tok kontrole: strelice s punim kružićem
Strelice možemo dodatno opremiti još i nazivima podatkovnih elemenata odnosno
kontrolnih polja. U osnovi, strukturni dijagrami ne tumače redoslijed izvođenja programa,
petlja i uvjetnih struktura, ti detalji prepušteni su realizaciji pojedinih modula. Ali, postoje
proširenja dijagrama koja sadrže i dodatne elemente (npr. dijamant za prikazivanje uvjetnog
izvođenja) za potpuniji opis sistema.

49
eMPIRICA – III Semestar: PRI 2013

50
 eMPIRICA – III Semestar: PRI 2013

AKCIJSKI DIJAGRAM
Akcijski dijagrami predstavjaju redoslijeda izvođenja koda i poziva
potprograma.Hijerarhija je s lijeve prema desnoj, redoslijed odozgo prema dolje.

51
 eMPIRICA – III Semestar: PRI 2013

DIJAGRAMI TOKA
Dijagrami toka su grafovi koji predstavljaju pojedine korake računarskih algoritama ili
poslovnih procesa. Koriste se na različitim područjima za analizu, planiranje i dokumentaciju
Postoji više podjela dijagrama toka, npr:
 programske (tumače programsku logiku),
 podatkovne (tumače tok podataka),
 dokumentne (tumače tok dokumenata),
 sistemske (obrađuju fizički – sistemski nivo),
 procesne (opisuju izvođenje redoslijeda aktivnosti poslovnog procesa)
 itd.
Opći simboli dijagrama toka su:
 početak i kraj procesa,
 aktivnost: pojedini korak procesa,
 kontrolni tok: bira tok izvođenja procesa,
 odluka ili razgranjivanje: sadrži pitanje (uvjet), na osnovi kojeg dolazi do
podjele kontrolnog toka na dva ili više tokova,
 potproces: uključuje redoslijed aktivnosti.
Pored navedenih koriste se još brojni drugi simboli koji imaju specifičnija područja
upotrebe:
 dokument,
 ručno unošenje podataka,
 ručna operacija,
 podatkovna datoteka,
52
 eMPIRICA – III Semestar: PRI 2013

 čekanje itd.

Simboli toka predstavljeni su na sljedećoj slici zajedno sa opisom.

53
 eMPIRICA – III Semestar: PRI 2013

Primjeri pisanja dijagrama toka dati su u nastavku.

54
 eMPIRICA – III Semestar: PRI 2013

Testiranje dijagrama toka:

 Dijagram toka provjeravamo korištenjem različitih podataka
 Koristimo tako standardne podatke kao i za program netipične podatke

55
 eMPIRICA – III Semestar: PRI 2013

PSEUDOKOD – STRUKTURIRANI JEZIK

Pseudokod ‒ sažet neformalan opis algoritma programskog rješenja na visokom
nivou. Koristi strukturna pravila programskih jezika, a namijenjen je ljudima, a ne
računarima (zbog neformalnosti). Koristi se kod planiranja programskih rješenja za
skiciranje strukture programa prije njihove faktičke implementacije u odabranom
višerazinskom programskom jeziku. Pseudokod omogućava lakše razumijevanje algoritama
nego ako su oni opisani u nekom konkretnom programskom jeziku. Usredotočuje se na
ključne principe algoritama, a ne na detalje izvođenja; pored toga je nezavisan od okoline
implementacije. Obično ispušta detalje koji nisu bitni za ljudsko razumijevanje algoritma
(npr. deklaracija algoritama).
Pseudokod ne slijedi konkretna sintaktička pravila nekog od programskih jezika. Oblik
pseudokoda je u domeni pojedinih pisaca, pri čemu svaki obično odabere svoj stil
prezentacije programskih konstrukta (grananje, petlje, procedure itd.). Uglavnom stil
posuđuje iz njemu bliskih programskih jezika kao što su npr. Basic, Pascal, Java itd. Zavisno
od pisca pseudokod može gotovo u cjelini oponašati sintaksu nekog programskog jezika ili
je zapisan u sasvim slobodnom slogu korištenjem prirodnog jezika.

Poslovni proces

56
 eMPIRICA – III Semestar: PRI 2013

PREDAVANJE 5

57