PIS Predavanja01

O predmetu
Zavod za primijenjeno raunarstvo

Kratki opis
Obrauju se postupci i tehnike strukturiranog i objektno usmjerenog pristupa razvoju informacijskih sustava namijenjenog krajnjem korisniku. Izlau se tehnike analize i oblikovanja, analiza izvodljivosti, pristupi izradi informacijskog sustava, procedure provjere sustava, instalacija i konverzija te postupci odravanja sustava. Razmatra se utjecaj informatizacije na organizaciju.
Prof.dr.sc. Kreimir Fertalj
Kompetencije
Predmet prua znanja potrebna za sudjelovanje u svim fazama razvoja informacijskog sustava. Studenti e sudjelovati u projektiranju sloenog, po mogunosti stvarnog, informacijskog sustava. Studenti e biti osposobljeni za prouavanje postojeeg sustava, definiranje zahtjeva na novi sustav, predlaganje i evaluaciju alternativnih rjeenja, oblikovanje sloene programske podrke, izradu projektne dokumentacije te provedbu postupaka uvoenja i odravanja i potpore informacijskog sustava.
Razvoj informacijskih sustava
Optereenje = 3 h tjedno + 15 LiV + 90 samostalan rad ECTS = 5

Zatieno Creative Commons licencom, http://creativecommons.org
FER \ Fertalj: Razvoj informacijskih sustava 2
Izvedba
Predavai & izvoai
prof. dr. sc. Kreimir Fertalj mr.sc. Boris Milainovi Marija Kati, prof.
Materijali
Nastavni materijali folije s predavanja, pratei primjeri http://creativecommons.org/licenses/by-nc-sa/2.5/hr/ podsjetnici, "alabahteri", e-knjiga, .... http://www.fer.hr/predmet/ris - formalna stranica http://bob.zpr.fer.hr/predmeti/RIS/ - kolaboracijski portal
Administracija
Zavod za primijenjeno raunarstvo, III kat zgrada D tajnica Sonja Majstorovi, Tel: 6129-915
Obavijesti
web-stranica predmeta http://www.fer.hr/predmet/ris ulaz u Zavod za primijenjeno raunarstvo (3. kat zgrade D)
Literatura:
J.A. Hoffer, J.F. George, J.S. Valacich: Modern Systems Analysis and Design, 4th ed., Prentice Hall, 2004. ISBN 0131454617 A. Dennis, B.H. Wixom, D.Tegarden: Systems Analysis & Design: An Object-Oriented Approach with UML, Wiley & Sons, 2002. ISBN 0471348066 G. B. Shelly, T. J. Cashman, H. J. Rosenblatt: Systems Analysis and Design, 5th ed, Course Technology, 2003. ISBN 0789566494
Konzultacije i primjedbe
ZPR, D/III, sjeverozapadno krilo e-mail nastavniku ili suradniku To: ime.prezime@fer.hr Subject: [RIS] U potpisu navesti puno ime i prezime te JMBAG
FER \ Fertalj: Razvoj informacijskih sustava
Sadraj
Osnove informacijskih sustava. Uvod u analizu i projektiranje sustava. Strategija organizacije. Identifikacija, selekcija, pokretanje i planiranje projekata. Modaliteti i alternative izgradnje. Prikupljanje informacija i definiranje problema. Specifikacija zahtjeva. Strukturirana analiza i dizajn. Modeliranje funkcija, procesa i podataka. Objektno usmjerena analiza i dizajn. Odabir arhitekture programske podrke. Oblikovanje korisnikog suelja i izvjea. Konstrukcija, integracija i provjera ispravnosti te dokumentiranje sustava. Uvoenje sustava u primjenu. Postupci odravanja. Potpora korisnicima. Raunalom podrano inenjerstvo. Obrnuto inenjerstvo. Preoblikovanje programske podrke. Metodologije razvoja informacijskih sustava. Osnove upravljanja projektom razvoja informacijskog sustava. Sustavi za upravljanje poslovanjem. Pozvano predavanje tvrtki koje se bave razvojem IS.
Vrednovanje rada
Sudjelovanje na predavanjima
cijeni se aktivnost prema subjektivnom dojmu predavaa minimum je dolazak (i ostanak) na barem pola predavanja
Domae zadae individualni projekti

realizacija individualnog projekta (planiranje, analiza, projektiranje, ...) isporuka rezultata obavlja se u tjednu zadavanja do nedjelje, 23:59:59
Test na raunalu, AHyCo blic

ocjenjivanje znanja "teorije" 3 testa maksimalnog doprinosa po 10% bodova svako od 20 generiranih pitanja vrijedi 0,5 % bodova pogrean odgovor odnosi 0,1% bodova trajanje testa 60 minuta generirani test se rjeava pod nadzorom student se treba samostalno i na vrijeme pripremiti provjera korisnikog imena i lozinke, pokusni rad sa sustavom Ahyco
Meuispit(i), (ponovljeni) zavrni ispit

Pismeni ispiti
rjeavanje problema znanje kljunih teorijskih koncepata
Ocjenjivanje
Za pozitivnu ocjenu (prolaz) treba ostvariti barem 50,00 % bodova svake pojedine komponente u tablici
Raspodjela prolaznih ocjena provodi se prema Gaussovoj raspodjeli
Meuispit I
strukturirana analiza i oblikovanje u tjednu 06.04.2009. 10.04.2009.
Nemogunost ispunjenja obveza treba dojaviti najkasnije tjedan dana od dana kada je nemogunost nastupila
nema isprinice "za cijeli semestar" na dan provjere znanja!!!
Meuispit II
objektno-orijentirana analiza i oblikovanje u tjednu 18.05.2009. - 22.05.2009.
Zavrni ispit
izrada, uvoenje, upravljanje projektom u tjednu 22.06.2009. 26.06.2009.
Ponovljeni zavrni ispit

u tjednu 06.07.2009. 10.07.2009. mogu pristupiti samo studenti koji nisu ostvarili prolaz na zavrnom ispitu
Aktivnost Pojedina no Predavanja 7 Doma e zada e 2-4 Test (blic) 10 I meuispit 15 II meuispit 15 Zavrni ispit 15
Puta Bodova Udio 1 7 7.00% 6 18 18.00% 3 30 30.00% 1 15 15.00% 1 15 15.00% 1 15 15.00% Ukupno 100 100.00%
8
Ostalo
Ankete
anonimne, slue za analizu i unaprjeenje nastave ulazna anketa - tijekom prva tri tjedna predavanja zavrna anketa - tijekom zadnja tri tjedna predavanja obrazac e biti objavljen na webu FER Ahyco
Laboratorij programskog inenjerstva i informacijskih sustava 2

Ukupno tjedno optereenje 3 h Ukupno optereenje temeljem predmeta RIS 15 h Izrada prototipa projektiranog sustava
Informacijski sustav
Preporua se dolazak na predavanja

na kojima e se komentirati primjeri stvarnih projekata iz prakse, a to iz vie razloga ne moe biti stavljeno na folije ili stavljeno na web.
Dostupni Primjeri: ???

\PosebnoOznaeniNaFolijama
10
Podatak, informacija i znanje

Informacija openito
obavijest, podatak o neemu, predana novost ili znanje formalno, kolekcija simbola koji mogu imati odreeno znaenje
Sustav
Sustav = ureeni poredak meuzavisnih komponenti povezanih za postizanje zajednike svrhe ili cilja. Fiziki sustav materijalne naravi
skup jedinica, organizacijski ujedinjenih u cjelinu (npr. poduzee) skup dijelova, povezanih opom funkcijom (npr. ivani)
Podatak, informacija i znanje

podatak je sirova injenica koja predstavlja neku istinu iz stvarnog svijeta pojedinani podaci sami za sebe znae malo ili nemaju neko znaenje informacija je interpretacija podatka - proien, organiziran i obraen podatak u smislenom kontekstu informacija je subjektivnog znaenja, u kontekstu primatelja znanje se gradi na temelju novih informacija koje se nadovezuju na postojee znanje isti podaci mogu biti razliito interpretirani od strane razliitih ljudi u ovisnosti o njihovom znanju -130000 ??? primjer: -130000 HRK ? na raunu ! broj 1313 (tj. Mojem) !!!
Apstraktni sustav konceptualni, proizvod ljudske mate

oblik drutvene organizacije (npr. dravni) oblik, nain ustrojstva, organizacija neega (npr. izborni) uvjetovan planskim, pravilnim rasporedom dijelova (npr. sistem rada)
Informacijska znanost, obavijesna znanost informatika (informatics, information theory).

FER \ Fertalj: Razvoj informacijskih sustava 11 FER \ Fertalj: Razvoj informacijskih sustava 12
Elementi sustava
Komponente - podsustavi
nerazdvojivi dijelovi ili agregacije dijelova koje pripadaju sustavu npr. Nabava, Proizvodnja, Prodaja npr. Studentska sluba, Zavodi, Financijska sluba mogu biti zamijenjeni bez potrebe za promjenom itavog sustava (!?) organizacija, interakcija, meuzavisnost, integriranost
Informacijski sustav (Information System) = skup meusobno povezanih komponenti koji prikuplja, obrauje, pohranjuje i prua informacije potrebne za obavljanje poslovne zadae
obavijesni sustav, informacijski sistem sustav za upravljanje sustavom ljudskih aktivnosti [Checkland, 1980]
Granica
definira sadraj i domaaj sustava
Svrha
prikupljanje i pruanje informacija korisnicima u jednoj ili vie organizacija organizacijski IS (poslovni IS)
Okolina
sve to je izvan granica sustava, ali se jo uvijek tie sustava npr. MZO i studentske udruge kao okolina visokog uilita
Podrazumijeva
sustave podrane raunalom raunalni (kompjuterizirani, kompjuterski) sustave koji se ne oslanjaju na raunala, ali obrauju informacije
Ulazi i izlazi
sve to ulazi u sustav iz okoline ili ga naputa
Korisnici
poslovodstvo, djelatnici (zaposlenici, osoblje), klijenti
Suelja
veze-diralita izmeu sustava i njegove okoline (zatita, filtri)
Ogranienja
unutarnji i vanjski imbenici koji odreuju i ograniavaju funkcioniranje sustava npr. ogranienja prostora ili ljudstva, pravilnici, zakonske odredbe
Informacijski sustav podran raunalom

Informacijski sustav podran raunalom
Ureenje ljudi, podataka, procesa, suelja, poveznica (mrea) i tehnologije koji djeluju meusobno sa svrhom podrke i poboljanja svakodnevnih poslovnih aktivnosti (obrada podataka), kao i podrke rjeavanju problema i donoenju odluka (informacijski servisi). [Whitten et. al, 2000]
Poslovni i informacijski sustav

Poslovni sustav
materijalni ulazi i izlazi (sirovine, energija, proizvodi) i informacijski tokovi (poruke, dokumenti, ) Ulaz u neki PS predstavlja izlaz iz nekog drugog PS procesi: obrada, prerada, proizvodnja Povratne veze - usporedba plana i realizacije izvritelji: osobe, strojevi, alati skladita: spremita materijala
Komponente IS
programska oprema (software) sistemska, namjenska raunalna oprema (hardware) raunala i periferije osobe (lifeware) - korisnici, informatiari mrena infrastruktura (netware) - mrena oprema organizacija (orgware) postupci povezivanja pojedinih dijelova u cjelinu Okolina sustava ...
Sustav Granica sustava Automatizirani dio sustava
I(P)S: nabave, prodaje, proizvodnje, financija, ljudskih resursa i plaa, osnovnih sredstava IS Subvencionirane Prehrane (ISSP) Integrirani PIS Visokih Uilita (IPISVU) IS Personalnog Upravljanja MORH
podsustav poslovnog sustava ulazi i izlazi: ulazne informacije, obraene informacije procesi: obrada informacija (podataka) o stanjima stvarnog sustava izvritelji: osobe, programi, raunala skladita: spremita informacija (podataka)
Granica automatizacije
15
16
Slojevi poslovnih informacijskih sustava

Transaction Processing System (TPS), Data Processing System
evidencija i obrada podataka o poslovnim transakcijama pr. uplate i isplate po raunima, upis predmeta, prodaja, narudba ili zaprimanje robe
Upravljanje IS
Upravljanje i razine IS
Informacijski sustav transakcijski upravljaki za potporu odlu ivanju Informacije, kada obrada podataka, dnevno zbirne, periodiki sintetizirane, ad hoc Korisnici, Upravljanje tko nie operativno poslovodstvo srednje taktiko poslovodstvo (trendovi) vie strategijsko poslovodstvo, (to ako,) uprava
Management Information System (MIS) - upravljaki

obrada transakcijskih podataka izrada izvjea potrebnih za upravljanje i nadzor poslovanja
Decision Support System (DSS) za potporu odluivanju

odluivanje na temelju podataka iz razliitih izvora transakcijskih sustava ali i povijesnih podataka interaktivno okruenje za donoenje odluka (to-ako, analiza hijerarhijski strukturiranih podataka drill down, grafiki modeli poslovnih procesa)
Executive Information System (EIS) (pod)varijanta DSS za izvrne rukovoditelje

koristi se za donoenje stratekih odluka informacije dolaze iz IS organizacije ali i vanjskih izvora, npr. novosti o konkurenciji, ekonomska predvianja, izvjea s burza dionica
Ostale vrste IS
Expert System (ES) ekspertni sustav
sustav pravila i mehanizam zakljuivanja ugraena struna znanja za koritenje od strane manje
Primjer poslovnog IS (1)

Financijsko raunovodstvo
Upravljanje glavnom knjigom. Bilanca i Raun dobiti i gubitka (financijski izvjetaji). Analitika kupaca. Analitika dobavljaa. Raunovodstvo osnovnih sredstava. Raunovodstvo zaliha. Porezno raunovodstvo
Nabava, skladitenje i logistika

Zahtjevnice. Obrada narudbenica. Evidencija primki materijala. Ovjera faktura (likvidacija). Upravljanje ugovorima. Upravljanje zalihama i skladitem, ukljuujui inventuru i fiziki promet robe.
Office Automation System (OAS), Office support systems (OSS)

potpora uredskom poslovanju upravljanje elektronikom potom, kolanje dokumenata, dijeljenje kalendara
Group Support System (GSS), Groupware

potpora grupnom radu kolaboracija, obavjeivanje, zakljuavanje dokumenata
Upravljako raunovodstvo (Kontroling)

Raunovodstvo trokovnih centara. Raunovodstvo profitnih centara. Raunovodstvo internih naloga. Raunovodstvo profitabilnosti.
Upravljanje ljudskim potencijalom

Kadrovska evidencija. Obraun plaa.
Supply Chain Management (SCM)

upravljanje lancem nabave integrira razvoj proizvoda, nabavu proizvoda, proizvodnju i upravljanje zalihama.
Proizvodnja
Planiranje proizvodnje. Izvrenje proizvodnje. Proizvodnja po narudbi. Procesna proizvodnja.
Prodaja i distribucija
Upravljanje nalozima za prodaju. Upravljanje ugovorima. Fakturiranje.
19
Customer relationship management (CRM)

upravljanje odnosom s kupcima podrava marketing, prodaju i servis, ukljuujui interakciju s korisnicima
Upravljanje kvalitetom
Ispitivanje kvalitete.
Izvjetaji
Primjeri IS (2), (3)

IS biljnih vrsta
Taksonomija Herbar Nalazita Narodna imena Sinonimi Literatura Ekonomska upotrebljivost Zemljopisna rasprostranjenost Ugroenost ...
Znaajke informacijskih sustava

Znaajke informacijskih sustava
sloena okolina, koju je teko u potpunosti definirati sloeno suelje prema okolini, koje ukljuuje razliite ulaze i izlaze sloene veze izmeu ulaza i izlaza (strukturno, algoritmiki) obujam i sloenost podataka
IS personalnog upravljanja
Osnovni podaci o osobama (osobine, civilna i vojna povijest) Ustroj (postrojbe, dunosti, ustrojna mjesta) Tijek slube (prijam, sluba, posebna stanja, izlaz) Dodjela inova i redova, ocjenjivanje Dodjela odlija i medalja kolovanje (povijest, izobrazba u HV) Evidencija prekraja, mjere Ostalo (naknade, doplatci, )
Problem projektiranja, izrade i odravanja Vanost IS

Informacija je postala upravljaki resurs jednake vanosti kao to su vlasnitvo (osnovna sredstva), ljudski resursi i kapital. IS sadri/predstavlja znanje (know-how) organizacije koju podrava. IS i aplikacije pokazuju se prijeko potrebnim za odranje konkurentnosti ili postizanje kompetitivnog prestia organizacije. Organizacije u kojima se IS primjenjuju visoko su ovisne o stalnoj raspoloivosti IS kroz dulje vrijeme.
21
22
Razvoj informacijskih sustava

The CHAOS Report [Standish Group, 1994], http://www.standishgroup.com Prosjeni troak projekta velike kompanije: 2,32 M$ srednje kompanije 1.33 M$ male kompanije: 434 K$ Prosjeno prekoraenje trokova 189% Prosjeno prekoraenje rokova 222% Projekti zavreni na vrijeme, u okviru predvienih sredstava, sa svim predvienim funkcijama 16.2% Projekti zavreni i u funkciji, ali uz vee trokove, dulje trajanje i/ili reduciranu funkcionalnost 52.7% Prekinuti projekti - 31.1%
23 FER \ Fertalj: Razvoj informacijskih sustava
Standish Group, 2002: 34% uspjenih projekata 17% potpunih neuspjeha Ciljevi razvoja IS izgraditi sustav koji radi i koji je pouzdan, unutar zadanih granica izgraditi sustav koji zadovoljava poslovne ciljeve, prema zahtjevima korisnika izgraditi sustav u prihvatljivom vremenu i po opravdanoj cijeni
Projektiranje i izgradnja IS
24
Neki primjeri neuspjenih projekata/sustava

London Ambulance System (1992)
Nakon uvoenja sustav se 2 puta "raspao" radi niza pogreaka, naroito onih zbog upravljanja. Neposredni troak bio je relativno nizak (9m), ali se vjeruje da su neki ljudi umrli jer se do njih nije stiglo na vrijeme. dispeerski centar i ambulantne jedinice (vozila) na terenu preoptereenje ve u normalnom pogonu produljenje odziva u hitnim sluajevima na 7h, radi krutosti sustava niz propusta nabave, projektiranja, ugradnje i primjene sustava
Uzroci neuspjeha
Informacije o neuspjenim projektima u RH se rjee objavljuju. Meu najeim uzrocima su [Kalpi, Fertalj & Mornar, 2001]
Loa organizacija i voenje projekata oslonac na vanjske voditelje i savjetnike, delegirano upravljanje projektima, nerealno planiranje i pretjerani optimizam, formalno izvjetavanje o napretku, formalni nadzor nad projektom, podcijenjena uloga vlastitih strunjaka Loa izvedba projekata neodgovarajua analiza sustava, pogreke u dizajnu i kontroli kvalitete, neodgovarajua CASE pomagala i krivo koritenje, pa ak i svojevrsna zloporaba CASE pomagala
Taurus (1993)
Projekt sustava automatiziranih transakcija Londonske burze prekinut je nakon 5 godina razvoja i troka od 75m te posljedini gubitak klijenata od 450m. Ukupni gubici smatra se da su neizraunljivi. strateki projekt eljeno najvee burze na svijetu, "de-materijalizacija" dionica sloenost, prostorno rasprene ekipe, loa arhitektura, nepridravanje metodologije, loe upravljanje projektom i kontrola kvalitete
Denver Airport (1994)

Nepouzdanost softvera za upravljanje prtljagom uzrokovala je odgodu otvaranja zrane luke u trajanju od 16 mjeseci uz trokove od 1.1 M$/dan. uoeni mehaniki problemi rjeavani su dodavanjem upravljake opreme sustav je prvotno puten u pogon unato saznanju da ne radi dobro
Mnogi sustavi su propali ili su bili odbaeni jer su se izvoai trudili napraviti lijepa programska rjeenja a nisu razumjeli sutinu organizacije i poslovanja.
26
Poboljanje uspjenosti IS
Poboljanje uspjenosti IS
Projektiranje IS Planiranje, upravljanje provedbom, praenje napretka Ukljuivanje korisnika Korisnik poznaje(?) poslovni proces i zna(?) odrediti potrebe. Informatiar upoznaje(?) poslovanje i zna(?) kako izraditi IS. Vano je da u procesu izgradnje sudjeluje i poslovodstvo, da bi se upoznalo sa stvarnim mogunostima i koristima uvoenja IS, posebice jer donosi konane (za poduzee sudbonosne) odluke.
Programska potpora
Programska oprema/podrka/potpora, softver (software)
dio raunalnog sustava koji nema fizikalnih dimenzija opi pojam za sve vrste programa, programskih jezika itd Skup elemenata ili objekata u jedinstvenoj konfiguraciji koju ine raunalni programi + podaci + dokumentacija svojstva: sloenost, podlonost pogrekama, ne troi se, teko mjerljiv, stari, dugo se koristi, lako se kopira (zajedno s pogrekama)
Saetak naela razvoja informacijskih sustava

Korisnici i vlasnici sustava moraju biti aktivno ukljueni Treba koristiti pristup koji vodi k rjeavanju problema Uspostaviti faze i aktivnosti Uspostaviti standarde za konzistentan razvoj i dokumentiranje Opravdati izgradnju sustava kao kapitalnu investiciju Ne oklijevati ako treba revidirati doseg ili otkazati projekt Projektirati za rast i promjene
Primijenjena programska potpora = Raunalna aplikacija (application)

namjenski program, primjenska programska oprema raunalom podrano rjeenje jednog ili vie poslovnih problema ili potreba
Informacijski sustav = sustav aplikacija za upravljanje ljudskim aktivnostima

Programsko inenjerstvo
Programsko inenjerstvo (software engineering)
Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1). [IEEE Std 610.12-1990, 1994] IEEE Std 610.12-1990 "Standard Glossary of Software Engineering Terminology", IEEE, New York, 1994, p. 67.
IEEE = Institute of Electrical and Electronic Engineers, http://www.ieee.org
Informacijsko inenjerstvo
Informacijsko inenjerstvo (information engineering, IE)
Inenjerski pristup izgradnji IS i upravljanju informacijama IS mora biti projektiran, kao to se to ini s drugim proizvodima razvoj IS kao strukturiran i planiran proces podran raunalom Sustavna primjena prikladnog skupa metoda, tehnika i alata u procesu razvoja informacijskih sustava.
Metoda (method), metodologija (methodology)

Smiljen i organiziran skup procedura izrade (modela, softvera), uz koritenje dobro definirane notacije sugerira proces obavljanja i nain biljeenja definira primjenu tehnika i njihovo povezivanje (pr. ERD-DFD)
sistematian, discipliniran i mjerljiv pristup razvoju, primjeni i odravanju softvera primjena inenjerskog pristupa na programsku opremu Programsko inenjerstvo je inenjerska disciplina koja obuhvaa sve aspekte izrade programske opreme. [Sommerville, 2004] Programsko inenjerstvo... ima za cilj ekonomian razvoj visokokvalitetne programske opreme [Pagel / Six 1994, str. 49]
Tehnika (technique)
definira nain provoenja postupka i dokumentiranja rezultata tog postupka npr. tehnika intervjuiranja, strateko planiranje, strukturirano programiranje
Podruje programskog inenjerstva

poslovi kojima se oblikuje i razvija programska oprema sustavna primjena prikladnih alata i tehnika na itav proces razvoja programske potpore
Pomagalo, alat (tool)

instrument, sredstvo (artefact) koje se koristi u razvoju IS npr. aplikacija za upravljanje projektima, CASE pomagalo, generator
Projektiranje IS
Slijed izrade fizikog i logikog modela postojeeg IS, a zatim logikog i fizikog modela budueg IS na temelju poslovnih zahtjeva i zahtjeva krajnjih korisnika.
fiziki model (ugradbeni, implementacijski, tehniki) opisuje kako je sustav fiziki i tehniki ugraen, te tko, gdje i kada neto radi logiki model (esencijalni, konceptualni, poslovni) to je sustav, to radi, to su podaci operativni (budui fiziki) sustav to, tko i kada, ali ne i gdje opcionalno, moe se razmatrati organizacijska razina razliito znaenje podataka zavisno od podruja unutar organizacije i okolia
Postojei fiziki Postojei logiki Budui logiki Budui fiziki
Modeliranje IS
Izrada modela koji odgovaraju dijelovima stvarnog sustava
model: apstrakcija ili reprezentacija dijela stvarnog svijeta Kada otprije ne postoji sustav, potrebno je odrediti "surogat" postojeeg sustava po ugledu na istovrsne sustave u drugim organizacijama ili razvoj zapoeti s izradom logikog modela.
Tehnike oblikovanja dijagramima

Izradom modela nastoji se opisati situacija u kojoj: dogaaj iz vanjskog svijeta pokree (okida) proces proces ima odreeni uinak na podatke u nekom stanju obavljanjem procesa podaci prelaze u novo stanje.
Korisniki/poslovni zahtjevi
Budui organizacijski
31 FER \ Fertalj: Razvoj informacijskih sustava 32
Tehnike modeliranja
Modeliranje podataka / oblikovanje podataka (data modelling)
model podataka TO su podaci, odnosno to opisuju podaci konceptualni model - opisuje podatke i veze izmeu podataka, najee model entiteti-veze (entity-relationship model) logiki model opisuje strukturu podataka i logikih datoteka, najee relacijski model podataka (relational data model)
Kljune aktivnosti i sudionici

Kljune aktivnosti # skupni sinonim ponekad informacijsko inenjerstvo
Sistemska analiza, Analiza sustava (Systems analysis) prouavanje poslovanja s ciljem preporuke poboljanja i specificiranja zahtjeva na rjeenje Sistemski dizajn, Dizajn sustava (Systems design) specifikacija ili konstrukcija raunalom podranog rjeenja identificiranih poslovnih zahtjeva
Modeliranje procesa/funkcija (process modelling, functional decomposition)

model funkcija i procesa KAKO se prikupljaju, obrauju i distribuiraju podaci model funkcija - oblikuje se razlaganjem (dekompozicijom) funkcija, iterativno od vrha prema dolje (od globalnih funkcija do osnovnih procesa) model procesa opisuje obradu podataka promatranog sustava, najee dijagram toka podataka (data-flow diagram)
Dionici, interesni sudionici (stakeholders)

Korisnik, Klijent (User, Customer, Client) osoba ili grupa za koju se gradi IS Korisnik sustava krajnji korisnik
neposredno koristi IS pri obavljanju svakodnevnih poslova ili koristi informaciju dobivenu iz IS
Modeliranje objekata
uahurivanje podataka i procesa u objekte objektni modeli dijagrami koji dokumentiraju strukturu objekata i njihove interakcije (UML)
Vlasnik sustava naruitelj (stvarni vlasnik ili upravitelj organizacije)

naruuje i plaa razvoj i odravanje IS, odreuje prioritete i politiku njegovog koritenja
Modeliranje dogaaja
model dogaaja KADA se podaci obrauju razmatranje uinka koji dogaaji imaju na procese i podatke te opis stanja, npr. dijagram promjene stanja (state transition diagram)
Projektant, Dizajner sustava (Designer) tehniki strunjak koji oblikuje sustav tako da zadovolji zahtjeve korisnika
prevodi poslovne zahtjeve i ogranienja u tehniko rjeenje, modeliranjem
Modeliranje resursa/sredstava
izvritelji - TKO obrauje podatke, GDJE se nalaze podaci, GDJE se obrauju podaci
Graditelj sustava (Builder, Developer) - programer, razvojnik izgrauje sustav, provjerava njegovu ispravnost te ga isporuuje u primjenu
konstruira komponente sustava na temelju specifikacija koje rade projektanti sustava
Modeliranje programa
struktura (programskih) modula IS, primjerice strukturnim kartama, UML dijagramima
34
Kljune uloge
Sistem analitiar [Whitten et. al, 2000]
Sistem analitiar potpomae prouavanje problema i potreba poslovanja radi odreivanja kako poslovni sustav i informacijska tehnologija mogu najbolje rijeiti problem i postii unaprjeenje poslovanja. Plodovi ove aktivnosti mogu biti poboljani poslovni procesi, poboljani informacijski sustavi te nove ili poboljane aplikacije, a esto sve zajedno. identifikacija tehnolokih poboljanja poslovnih procesa, oblikovanje poslovnih procesa, projektiranje IS, osiguranje sukladnosti IS standardima
ivotni ciklus razvoja sustava
Poslovni analitiar
analiza poslovanja, identifikacija koristi, oblikovanje (novih) procesa i procedura
[drugi analitiari, npr. infrastrukturni, upravljanja promjenama] Upravitelj projekta

upravljanje ekipom analitiara, razvojnika i drugih strunjaka izrada plana, raspodjela resursa i nadzor provedbe
Systems Development Life-Cycle (SDLC)
Analitiar ?= konzultant
ivotni ciklus razvoja

Openiti proces razvoja sustava
Ustanovljavanje problema Prouavanje i razumijevanje problema Identifikacija zahtjeva na rjeenje ili oekivanja Procjena alternativnih rjeenja i odabir "najboljeg" smjera Oblikovanje odabranog rjeenja Ugradnja odabranog rjeenja Vrednovanje rezultata. Ukoliko problem nije rijeen povratak na korak 1 ili 2
Faze ivotnog ciklusa

Plan sustava Planiranje Potrebe (popravci, dorade, prerade, nadogradnje)
Planiranje (zato)
Analiza
Zato graditi sustav?
Analiza (tko, to, kada, gdje)

Tko koristi sustav? to mora raditi? Gdje i kada e se sustav koristiti?
Pregled
Specifikacija zahtjeva
Oblikovanje (kako)
Kako sustav napraviti i kako e raditi?
SDLC = software/systems development life-cycle

konzistentan i standardizirani nain razvoja IS model razvojnog procesa - unaprijed propisan proces razvoja definira faze i zadatke (aktivnosti) koje treba obaviti tijekom razvoja ciklus osigurava kontrolne toke za praenje napretka, procjenu postignutih rezultata i donoenje odluka o daljnjim koracima
Oblikovanje
Operabilni sustav
Izrada
ugradnja i provjera rjeenja
Primjena
isporuka, odravanje i poboljavanje
Primjena, odravanje
Specifikacija sustava
FER \ Fertalj: Razvoj informacijskih sustava 37 FER \ Fertalj: Razvoj informacijskih sustava
Izrada
Funkcionalni sustav
38
Planiranje sustava
Traenje odgovora na pitanje zato graditi sustav
Faza analize
Traenje odgovora na pitanje tko e koristiti sustav, to e sustav raditi te gdje i kada e biti koriten. Prouavaju se postojei sustavi, ustanovljavaju mogua poboljanja i razvija koncept novog sustava
Inicijacija projekta
Zahtijevanje sustava (system request), Inicijalna strategija (initial strategy) odreivanje poslovnih ciljeva, problema i ideja njihovog rjeavanja snimka stanja, saetak poslovnih potreba Studija izvodljivosti (feasibility study) analiza problemskog podruja i odreivanje (granica) projekata procjena kljunih aspekata predloenog projekta
tehnika izvodljivost (moe li se izgraditi) ekonomska izvodljivost (hoe li se isplatiti) organizacijska izvodljivost (da li e se koristiti)
Strategija analize (analysis strategy)

vodi kroz analizu postojeeg (as-is) i projektiranje novog (to-be) sustava
Analiza zahtjeva (requirements analysis): detaljna analiza kojom se preciziraju granice projekta i poslovni zahtjevi
detaljna analiza postojeeg sustava (problema i poslovnih zahtjeva) modeliranje (postojeeg) sustava
Posebno povjerenstvo (steering committee, approval committee) odobrava projekte
Upravljanje projektom
po odobrenju projekta Izrada plana rada, kadroviranje projekta, upravljanje i nadzor projekta
Specifikacija zahtjeva (requirements specification): detaljni opis zahtjeva na IS, oblikovan tako da ga razumiju projektanti
modeliranje (budueg) sustava definiranje zahtjeva na budui IS
Poslovni cilj i projekti, plan sustava, plan informatizacije (glavni projekt)

Poslovni model sustava, prijedlog sustava

Oblikovanje sustava
odreuje kako e sustav funkcionirati, sa stanovita hardvera, softvera i mrene infrastrukture, korisnikog suelja, programa te spremita podataka
Izrada sustava
Provedba - ugradnja ili nabava oblikovanih rjeenja
Strategija projekta (design strategy)

odluka da li graditi vlastitim snagama (insourcing), naruiti razvoj po mjeri (outsourcing) ili kupiti gotovo rjeenje
Izrada, implementacija (implementation), konstrukcija

ugradnja baze podataka, kodiranje procesa (funkcija) novog IS
Dizajn sustava (system design)

modeliranje cjelokupnog sustava (pogled projektanta) odabir tehnike arhitekture sustava konceptualno modeliranje podataka opi dizajn suelja
Testiranje (testing)
provjera komponenti
Integracija i provjera sustava (system integration, evaluation)

udruivanje dijelova i provjera cjeline, da bi se dokazalo da sustav radi (da je ispravno napravljen) te da radi ono to je zahtijevano (da je napravljen pravi sustav, koji ispunjava zahtjeve)
Detaljni dizajn (detailed design)

razrada rjeenja, izrada tehnolokog modela IS (pogled izvoaa) dizajn suelja, pohrane podataka i programa
Funkcionalni sustav i tehnoloki opis sustava
Tehnika specifikacija sustava

kolekcija specifikacija arhitekture, suelja, pohrane podataka i programa
Po potrebi se revidira studija izvodljivosti i plan projekta

Primjena sustava
Uvoenje u primjenu i odravanje
Uvoenje u primjenu, primjena (operation, production) prijenos (konverzija) podataka sa starog na novi sustav uspostava novih radnih aktivnosti Odravanje (maintenance) odravanje sustava u upotrebi izmjene sustava radi poboljanja radnih karakteristika (performanci), poboljanja ili prilagodbe naina uporabe Potpora (support) dobavljaa opreme, tehnikog osoblja korisnicima
Primjer: IS LC Stages and Deliverables, DOE Software Development Methodology, http://cio.doe.gov/sqse
Informacijski sustav u primjeni, plan odravanja Pregled (review)

revizija, preispitivanje itavog sustava kada su potrebne vee izmjene uslijed promjena u poslovanju ili promjena poslovnih ciljeva
Novi projekti, novi razvojni ciklus Navedene su tipine faze ivotnog ciklusa, bez implikacije da se radi o diskretnim i/ili slijednim aktivnostima!
Razvoj projekta po stadijima

U nastavku su navedene tipine aktivnosti i rezultati aktivnosti po fazama razvoja, neznatno modificirano prema [McConnel, 1998].
Iako slii metodologiji, rije o skupu praktinih preporuka. Pojedine aktivnosti mogu biti opcionalne, ovisno o tipu projekta. Aktivnosti
Pokretanje projekta
Rezultati
donesena odluka o pokretanju projekta (ako se isplati) kreirani i provjereni dokumenti: vizija projekta (svrha i ciljevi) studija izvodljivosti i isplativosti plan kontrole promjena lista moguih rizika dnevnik softverskog projekta dnevnik problema postavljanje upravitelja projekta postavljanje ciljeva projekta izrada vizije projekta analiza isplativosti projekta studija izvodljivosti plan kontrole promjena sastavljanje liste rizika otvaranje dnevnika projekta otvaranje dnevnika problema angaman 23 iskusna razvojnika
Resursi
Kontrolne liste za provjeru i predloci projektne dokumentacije nalaze se na http://www.construx.com Prilagodljivi razvojni proces (Adaptable Process Model) opisan je na http://www.rspa.com Prije spomenuti http://cio.doe.gov/sqse
45
46
Analiza
Aktivnosti
prikupljanje informacija stvaranje vodia za stil suelja kreiranje i revizija prototipa korisnikog suelja razrada procjena priprema prijedloga o koritenju postojeih dijelova softvera, odnosno nabavi novih izrada i revizija plana razvoja softvera (prvo preliminarni, a potom i detaljni) analiza i klasifikacija zahtjeva okupljanje i suradnja svih zainteresiranih strana s ciljem otklanjanja problema povezanih sa zahtjevima razrjeavanje nejasnih i dvosmislenih zahtjeva kreiranje i revizija korisnikog prirunika / specifikacija zahtjeva izrada i revizija plana testiranja revizija i auriranje rizika projekta revizija i auriranje dnevnika projekta revizija i auriranje prototipa suelja i vodia za stil suelja revizija i auriranje dnevnika problema kontrola kvalitete svih proizvoda
Oblikovanje
Aktivnosti
zapoljavanje veine razvojne ekipe priprema preliminarnih dijagrama dizajna priprema PDL-a za funkcije/objekte dizajna visoke razine razrjeavanje problema preostalih iz faze razvoja zahtjeva zapoljavanje veine QA osoblja definiranje dizajna visoke razine (arhitekture sustava) kreiranje i revidiranje dokumenta o arhitekturi softvera auriranje procjena auriranje rizika auriranje dnevnika projekta auriranje korisnikog prirunika / specifikacije zahtjeva auriranje dnevnika problema auriranje plana razvoja definiranje dizajna niske razine kreiranje i revizija plana isporuke po stadijima izrada plana izrade za prvi stadij kreiranje i revizija testova za prvi stadij kontrola kvalitete svih proizvoda
Rezultati
detaljan prototip korisnikog suelja kreirani i provjereni dokumenti: matrica praenja zahtjeva korisniki prirunik / specifikacija zahtjeva plan za osiguranje kvalitete softvera detaljan plan razvoja softvera plan testiranja rjenik podataka procjene aurirani ostali dokumenti
Rezultati
kreirani i revidirani slijedei dokumenti: dokument o arhitekturi softvera plan gradnje softvera po stadijima dokument detaljnog dizajna testovi za 1. stadij plan isporuke po stadijima aurirani i revidirani svi ostali dokumenti
47
48
Ugradnja
Aktivnosti
zapoljavanje cijele razvojne ekipe i QA osoblja korekcija pogreaka iz prethodnih faza kreiranje i revizija testova za sljedei stadij kreiranje i revizija plana konstrukcije za trenutni stadij kreiranje liste mini koraka za trenutni stadij postavljanje standarda kodiranja pisanje programskog koda testiranje i integracija cjelina tehnika revizija auriranje i revizija dokumenta detaljnog dizajna auriranje liste rizika auriranje dnevnika projekta auriranje korisnikog prirunika / specifikacije zahtjeva auriranje dnevnika problema auriranje plana razvoja auriranje procjena kreiranje i revizija plana testiranja kreiranje i revizija testova sustava izrada plana alfa i beta testiranja izrada nacrta testova prihvatljivosti izrada rijeenih problemskih primjera (Test case) kontrola kvalitete svih proizvoda
Integracija i provjera
kreirani i revidirani slijedei dokumenti: plan integracijskih i sistemskih testiranja plan alfa i beta testiranja nacrt testova za prihvaanje softvera napisana lista mini koraka napisan programski kod obavljena testiranja komponenti obavljena integracija komponenti aurirani svi ostali dokumenti
Rezultati
Aktivnosti
provjera sustava, alfa i beta testiranja sastavljanje izvjetaja o rezultatima testiranja popravljanje i prepravljanje programskog koda auriranje korisnikog prirunika identificiranje kandidata za ponovo uporabive programske knjinice kreiranje plana testiranja za prihvaanje konanog proizvoda kreiranje konanog plana konverzije kreiranje nacrta plana odravanja priprema za provjeru prihvatljivosti auriranje plana projekta auriranje procjena auriranje dnevnika projekta auriranje dnevnika problema kontrola kvalitete svih proizvoda
Rezultati
izvjetaji napravljeni na temelju svih obavljenih testiranja plan testova za prihvaanje finalnog proizvoda instalacijski plan softver koji radi kako treba (testirani sistemski kod i datoteke podrke)
50
Instalacija i prihvaanje
Aktivnosti
auriranje dnevnika projekta auriranje procjena izrada konane verzija plana odravanja kompletiranje korisnike dokumentacije izrada kontrolne liste isporuke finalno testiranje prije isporuke (mjerilo prihvaanja finalne verzije) izrada izvjetaja o rezultatima testova za prihvaanje softvera izrada dokumenata o zavretku (obrasci, suglasnost o primopredaji) izrada instalacijske inaice auriranje dnevnika problema
Isporuka i odravanje
Aktivnosti
isporuka funkcionalnog proizvoda arhiviranje projekta (izvornog koda, razvojnih pomagala, dokumenata, ...) finalno auriranje dnevnika projekta kreiranje i revizija povijesnih dokumenata uspostava distribucije upravljanje distribucijom (kome isporuiti, kada, kako) uspostavljanje slube (centra) za suradnju i pomo korisnicima odravanje, nadgradnja ili izdavanje novih verzija nove verzije se prije isporuke testiraju i u skladu s tim korigira se korisniki prirunik
Rezultati
instalacijska verzija softvera izvjetaj o rezultatima testova za prihvaanje softvera konana verzija korisnike dokumentacije aurirani ostali dokumenti
Rezultati
isporuka potpuno dovrenog i ispravnog proizvoda arhivirani projektni mediji dokument o povijesti projekta instalacijski paketi korisnicima omogueno da predlau dalje korekcije softvera ili da se obrate za pomo ako im zatreba
51
52
Statistika razvoja softvera (Mynatt)

1. Tipini projekt razvoja softvera traje a) 1 - 5 b) 6 - 11 c) 12 - 23 d) 24 - 48 mjeseca. 2. Za programski sustav srednje veliine, a) manje od 10 b) 10 - 20 c) 21 - 30 d) vie od 30 redaka izvornog programskog koda se tipino proizvede dnevno po osobi, tijekom cijelog razdoblja razvoja sustava. 3. Priblian broj pogreaka koje se pronau u svakih 1000 redaka izvornog izvrnog programskog koda tijekom razvoja programskog sustava jest: a) manje od 30 b) 30 - 40 c) 40 - 50 d) 50 - 60 4. Priblian broj pogreaka koje se pronau u svakih 1000 redaka izvornog izvrnog programskog koda u isporuenom sustavu jest: a) manje od 4 b) 4 - 8 c) 8 - 12 d) vie od 12 5. Koji je priblian postotak programskih sustava iji je razvoj zapoeo, a da budu i konano dovreni? a) 90 - 100% b) 80 - 90% c) 70 - 80% d) 60 - 70%
Statistika u svezi razvoja softvera (Mynatt)

6. Troak posjedovanja i odravanja softvera je tipino a) za polovicu b) jednako c) dvostruko puta vei nego to je bio troak razvoj softvera. 7. Veina pogreaka koje korisnici pronau u softveru su rezultat a) programerove pogreke b) problema u oblikovanju zadatka ili njegova razumijevanja c) administrativnih pogreaka d) pogreaka u projektu 8. Koliki je udio programiranja u razvoju softvera? a) 99% b) 70% c) 50% d) 20% e) 10% 9. Prema dananjem stanju razvoja softvera, sustav se smatra velikim ako sadri barem a) 2.000 b) 10.000 c) 100.000 d) 1000.000 redaka izvornog koda
54
Razdioba trokova u ivotnom ciklusu softvera

Analiza zahtjeva 3% Specifikacija 3% Projekt 5% Kodiranje 7% Provjera modula 8%
Uee aktivnosti kao funkcija veliine projekta

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
kodiranje uklanjanje pogreaka administriranje upravljanje i podrka
10 24 0 51 20 25 60 12 80 64 0 32 0 16 0 80
40 20
veliina projekta (funkcijske toke)

10
Odravanje 67%
Provjera integracije 7%
Vodopadni (waterfall) model

Klasini vodopadni model
slijedno napredovanje iz faze u fazu nisu dozvoljene naknadne promjene rezultata prethodnih faza zahtjevi za kvalitetom proizvoda su naglaeniji od zahtjeva za smanjivanjem trokova projekta i vremena razvoja proizvoda
Analiza
Primjenjivost
dobro definirano i stabilno okruenje, gdje postoje razraene procedure rune obrade ili raunalski sustav koji treba unaprijediti veliki projekti (investicije) zaposlenici neiskusni ili posjeduju ogranieno tehniko znanje
Modeli razvoja
Nedostaci
uvoenje prema gore (bottom up): moduli, podsustavi, sustav sustav nije upotrebljiv dok nije gotov u potpunosti problem predodbe o proizvodu na temelju pisane specifikacije korisnici prekasno uoe nedostatke problem u sluaju pogreaka ili novih/promijenjenih zahtjeva
Primjena
58
Oblikovanje
Izrada
Uvoz asopisa
Pseudostrukturni i radikalni vodopadni model

Pseudostrukturni model povratna veza i mogunost promjene rezultata prethodnih faza primjena tehnika strukturiranog programiranja uvoenje prema dolje: moduli na viim, pa na niim razinama Strukturni (radikalni) aktivnosti razliitih faza mogu se obavljati istovremeno koritenje rjenika podataka, 4GL i generatora aplikacija prikladan kada se unaprijed ne zna konani izgled sustava u konanici mora nastati (papirnati) model sustava
V model
Validacija
Verifikacija
Autodijelovi
59
definiraju se rezultati (proizvodi) pojedinih faza koji se prosljeuju u slijedee faze odreuju se rezultati kojima se testiraju elementi IS na razliitim stupnjevima razvoja
Paralelni razvoj po podprojektima

Projekt se razdvaja na nezavisne podprojekte koji se oblikuju i izrauju paralelno.
Gotovi podprojekti se integriraju u konaan sustav.
Prototipski model razvoja

Prototip = model koji se radi da bi se isprobale neke mogunosti Vrste prototipova
Model oponaanja (mock-up, model u naravnoj veliini) jednoekranski ili vieekranski model kojim se prikazuje kako e izgledati dio sustava (npr. suelje) Istraivaki model (research model) istraivanje dijelova sustava kako bi se provjerile neke kljune postavke (npr. provjera performanci odreenog modula) Ugradbeni model (implementation model) traenje naina na koje se sustav moe izraditi (npr. koji sustav za upravljanje BP, programski jezik, raunala)
Prednost ubrzanje razvoja, vidljivost rezultata Nedostatci rizik nezamijeenih zavisnosti meu podprojektima, problem integracije.
uklanja se zajednikom arhitekturom Ministarstvo
61
62
Brzo prototipiranje (rapid prototyping)

Funkcionalni prototip
nedovreni proizvod koji simulira rad pravog sustava
Ogranieno prototipiranje (constrained prototyping)

Nefunkcionalni prototip prikaz izgleda prototip nije i ne postaje radni sustav Prototipiranje kao sredstvo odreivanja zahtjeva prototipom se smanjuje rizik loeg odreivanja zahtjeva po dovretku analize prototip se odbacuje (throwaway prototyping) slijedi faza oblikovanja sustava
Evolucijsko prototipiranje (sinonim)

razvoj na osnovi povratnih informacija prototip inkrementanlnom doradom -bistrenjem (stepwise refinement) postaje dio zavrnog IS kada prototip postane dovoljno dobar, zavrava se preostali posao i prototip postaje konaan proizvod prikladno za male projekte (tzv. one-man) s promjenjivim zahtjevima
Prednosti
stjee se bolja slika o zahtjevima korisnika uklanjaju se mogua iznenaenja na kraju razvoja mogue su promjene zahtjeva korisnika poveanje kreativnosti i brzine razvoja
Prednost
postoji dokumentacija mogue je planiranje Izdavaka kua Njemaki naruitelj
Nedostaci
zaboravljanje da prototip nije pravi sustav mogui neuspjeh zamjene prototipa sustavom dokumentacija proizlazi iz izrade, uz opasnost da pisane specifikacije nikad nee biti napravljene nemogunost ispravne procjene i planiranja resursa
Fazni razvoj, model postupne isporuke

Fazni razvoj, model postupne isporuke (Staged Delivery), evolucijski razvoj, evolucijsko prototipiranje, inkrementalni razvoj
predstavnik brzog razvoja aplikacija, RAD (Rapid Application Development) sustav je podijeljen po verzijama koje se izrauju slijedno svaki od slijedova vodi proizvodu koji se isporuuje i generira zahtjeve u ranim fazama slian vodopadnom modelu, dok se kasnije faze obavljaju zasebno za pojedinu isporuku projekta
Evolucijski model, model postupne isporuke

Varijanta: projektiranje prema rokovima (design to schedule)
verzije se grade prema prioritetu projekt se zbog nedostignutog roka moe zaustaviti prije nego sve verzije budu isporuene
Prednosti
omoguuje isporuku dijelova proizvoda prije konanog zavretka projekta bra uporaba - ranije vidljiva vidi korist sustava korisnici bre identificiraju dodatne zahtjeve
Nedostaci
korisnici upotrebljavaju sustav koji je namjerno nedovren potreba za paljivim planiranjem (raspodjela resursa, ovisnosti izmeu pojedinih faza isporuke) - kljuno je da najpotrebnije i najkorisnije mogunosti budu ugraene prve
konana isporuka
Evidencija biljnih vrsta

Spiralni model
Iterativno se analizira rizik i planira naredna iteracija od 6 koraka:
Odreivanje ciljeva, alternativnih metoda i ogranienja, Odreivanje i pronalaenje rjeenja za rizike koji se mogu pojaviti, Procjenjivanje alternativnih rjeenja, Razvoj izlaznih proizvoda iteracije i potvrivanje njihove tonosti, Planiranje sljedee iteracije, Pokretanje sljedee iteracije (ako se odlui krenuti u novu iteraciju).
Spiralni model
Svaka iteracija dovodi projekt blie kraju.

U sluaju da je rizik prevelik, projekt se obustavlja ili prekida. Radijalna koordinata predstavlja kumulativni troak Zadnja iteracija predstavlja klasini ciklus
Primjena
izgradnja velikih sustava (trokovi izrade malih sustava su mali) kada provoenje analize rizika ne predstavlja preveliki relativni troak najee na interne projekte (naruitelj i izvoa iz iste organizacije)
Prednosti
praenje napretka, sigurnost
Nedostaci
sloenost, troak
Objektno usmjereni pristup razvoju

Objektno usmjereni pristup razvoju
mogao bi se provoditi bilo kojim od klasinih modela razvoja najvie slii faznom razvoju kljuna razlika je u pristupu dekompoziciji tradicionalno, proces dekompozicije je usmjeren procesima (process-centric) ili podacima (data-centric) OO dekompozicija je usmjerena na objekte koji sadre i podatke i procese
Osnovni objektno orijentirani model

Minimalist Object-Oriented Systems Analysis & Design (MOOSAD)
generiki pristup OOSAD zasnovan na konceptima ujedinjenog procesa (Unified Process) i ekstremnog programiranja (eXtreme Programming) UML kao sredstvo dokumentiranja
OO pristup razvoju treba biti [Booch, Jacobson, Rumbaugh]

Voen sluajevima primjene (Use-Case Driven) UC kao glavno pomagalo za definiranje ponaanja sustava Inherentno jednostavni, opisuju po jednu aktivnost (pa nema potrebe za ugnijeedenom dekompozicijom i ulananim dijagramima) Usmjeren arhitekturi, s arhitekturom u sreditu (Architecture-Centric) arhitektura vodi specifikaciju, konstrukciju i dokumentiranje, kroz tri pogleda funkcionalni opisuje vanjsko ponaanje sustava, pogled korisnika statiki struktura sustava (atributi, postupci, razredi, veze) dinamiki opisuje unutarnje ponaanje razmjenom poruka izmeu objekata i promjnama njihovog stanja (dijagramima ponaanja) Iterativan i inkrementalan (Iterative and Incremental) ponavljani postupci, postupno poveanje dovrenosti
Provode se gradnje sustava

gradnja (build) inaica softvera u razvoju gradnje se temelje na sluajevima koritenja po prioritetima svaka gradnja predstavlja inkrementalni napredak zavretku svaka gradnja obuhvaa analizu, oblikovanje i izradu svaka izgradnja vraa povratnu informaciju o utvrivanje zahtjeva, isporuuje funkcionalni sustav za sljedei izgradnju i skup predloaka koji se mogu dodavati u programske knjinice gradnje omoguuju upravljanje projektom zasnovano na vrstim rokovima (timeboxing), pri emu su vremenski okviri pojedinog timeboxa od jednog do dva tjedna ili mjeseca ovisno o veliini i sloenosti projekta
70
MOOSAD pristup
Planiranje Odreivanje zahtjeva i razvoj sluajeva koritenja Analiza Oblikovanje Izrada Verzija 1 Knjinice predloaka
Nabava gotovih proizvoda

Alternativa razvoju je kupnja postojeeg proizvoda.
Off the Shelf, Commercial-Off-The-Shelf (COTS), Shrink-wrap openito Enterprise Resource Planning (ERP) sustav za podrku poslovanju
Postojei proizvodi rijetko zadovoljavaju svu potrebnu funkcionalnost, ali nabava moe imati i prednosti.
Knjinice predloaka
Analiza
Oblikovanje
Izrada
Verzija 2 Knjinice predloaka
Analiza
Oblikovanje
Izrada
Verzija n
Proizvod je vidljiv i moe se ocijeniti (!?) Proizvod je "odmah" dostupan po nabavi (!?) Ovo vrijedi uglavnom za pakete namijenjene irokom krugu nepoznatih korisnika. U sluaju ERP, treba obaviti prilagodbu koja moe potrajati mjesecima ili godinama. npr. SAP: 20k tablica, 20k zaslona, ABAP (Advanced Business Application Programming)
ivotni ciklus ERP proizvoda

Analiza (Project Planning, Project Preparation) Specifikacija zahtjeva (Business Blueprint) Implementacija i testiranje (Realization) Kontrola kvalitete i poduka (Final Preparation) Uvoenje u primjenu i odravanje (Going Live i podrka)
Primjena
Debeli klijent Vieslojni poslovni sustav
71
72
ivotni ciklus ERP proizvoda
NAELA IS
Priprema projekta
Dizajn rje rjeenja Produkcija I Produkcija II PostPostprodukcijska podr podrka
Faza 1: Projektni standardi Metodologija Sastav timova Identifikacija poslovnih procesa Koncept rjeenja Realizacija Priprema Poetak produkcije
Faza 2: Realizacija Priprema Poetak produkcije
Kraj projekta
02.11.2007.
16.12.2007.
30.04.2008.
1.12.2008.
31.12.2008.
Integrirani PIS visokih uilita
Ukljuenost sudionika i pristup rjeavanju problema

Korisnici i vlasnici sustava moraju biti aktivno ukljueni
Za uspjenu izgradnju IS apsolutno je nuan angaman vlasnika i korisnika. Osobe odgovorne za razvoj IS moraju nai vremena za vlasnike i korisnike, inzistirati na njihovu sudjelovanju i traiti suglasnost od njih za sve odluke koje ih se tiu.
Uspostava ivotnog ciklusa i standarda razvoja

Uspostaviti faze i aktivnosti
Veina ivotnih ciklusa i metodologija sastoji se od faza, U najjednostavnijem obliku, ivotni se ciklus sustava sastoji od etiri faze: pregled, analiza, projekt, ugradnja. Peta aktivnost, potpora sustavu, poboljava rezultat, iterirajui kroz prethodne etiri faze, ali sada na umanjenim problemima i sa ciljem dotjerivanja i poboljanja sustava. Faze se obino razlome na aktivnosti i zadatke kojima se moe lako upravljati i lako ih rijeiti, Faze projekta treba dovravati u slijedu, od vrha do dna.
Treba koristiti pristup koji vodi k rjeavanju problema

Koritenjem metodologija smanjuje se rizik zbog koritenja preaca i pogreaka. Metodologije proizvode potpunu i konzistentnu dokumentaciju, iz jednog projekta u drugi. Metodologija je, prije svega i najvie, postupak rjeavanja problema prilikom izgradnje sustava! Klasini pristup rjeavanju problema je sljedei:: Prouiti i shvatiti problem u kontekstu sustava, Utvrditi zahtjeve koje mora ispuniti prikladno rjeenje, Prepoznati mogua rjeenja i odabrati najbolje, Projektirati i/ili ugraditi rjeenje, Promatrati i vrednovati utjecaj izraenog rjeenja te u skladu s time dotjerivati rjeenje. Kad se nema iskustva, postoji tenja da se preskoe ili skrate neki od koraka u rjeavanju problema. Ishod se kree u rasponu: rjeava se krivi problem, krivo se rjeava problem, izabere se krivo rjeenje.
Uspostaviti standarde za konzistentan razvoj i dokumentiranje

Standardi za razvoj sustava obino opisuju: aktivnosti, odgovornosti, naputke ili zahtjeve za dokumentiranje, provjere kvalitete. Potreba za dokumentacijskim standardima ukazuje na uobiajenu pogreku mnogih analitiara njihov propust da izrauju dokumentaciju kao trajnu aktivnost tijekom ivotnog ciklusa.
Opravdanje investicije u sustav

Opravdati izgradnju sustava kao kapitalnu investiciju
Informacijski sustavi jesu kapitalna investicija, U kapitalnim investicijama, treba razmatrati: za svaki problem najvjerojatnije postoji nekoliko moguih rjeenja, nakon to se prepoznaju varijante rjeenja, analitiar treba vrednovati svako od moguih rjeenja glede njegove izvodljivosti, a pogotovo ekonominosti.
Ekonominost se definira kao odnos izmeu dobiti ostvarene sustavom i trokova njegove izgradnje i pogona.
Ne oklijevati ako treba projekt otkazati

Ne oklijevati ako treba projekt otkazati
Znaajna prednost faznog pristupa razvoju sustava jest u tome to stvara nekoliko prilika da se ponovno ocijeni izvodljivost. Dugorono gledano, otkazani projekti su jeftiniji od ugraenih promaaja. Veina analitiara propusti podesiti procjenu trokova i rokova prilikom proirenja podruja projekta. Kao rezultat, analitiar esto nepotrebno prihvaa odgovornost za premaaj trokova i rokova. Pristup puzeeg preuzimanja obveza: Viestruke provjere izvodljivosti su ugraene u metodologiju razvoja sustava. U bilo kojoj toki provjere, svi se ve uinjeni trokovi smatraju nepovratnima i nevanima za daljnje odluivanje. Projekt treba u svakoj od toaka ponovno vrednovati da se utvrdi da li je jo uvijek izvodljiv. U svakoj toki provjere analitiar treba razmotriti: ukidanje projekta ako vie nije izvodljiv, ponovnu procjenu trokova i rokova ako se opseg projekta poveava, suavanje opsega projekta ukoliko su proraun i rokovi fiksirani, ali nedovoljni za ostvarenje svih ciljeva projekta.
Projektiranje i planiranje sustava

Podijeli pa vladaj
Svi su sustavi dijelovi veih sustava (nadsustava), Praktiki svi sustavi sadre manje sustave (podsustave), Sustav se podijeli u barem dva podsustava da bi se njime lake ovladalo i sagradilo vei sustav, Podjelom veeg problema (sustava) u manje dijelove (podsustave) kojima je lake upravljati, analitiaru se pojednostavnjuje postupak rjeavanja problema.
Resursi
Association for Information Systems, http://home.aisnet.org/ Kontrolne liste za provjeru i predloci projektne dokumentacije nalaze se na http://www.construx.com Prilagodljivi razvojni proces (Adaptable Process Model) opisan je na http://www.rspa.com http://www.itjungle.com/tfh/tfh053105-story03.html
Projektirati sustav tako da prati rast i promjene

Mnogi analitiari upadnu u zamku izradivi sustav koji odgovara iskljuivo trenutnim zahtjevima, Entropijom se naziva prirodno i neizbjeno kvarenje bilo kojeg sustava, Kada tijekom faze podrke sustavu, trokovi odravanja premae trokove izgradnje novog sustava, sustav je zastario.
79
80
Reference
Avison, D.E. & Fitzgerald, G. Information Systems development: methodologies, techniques and tools. 2nd. ed. McGraw-Hill, 1998. Awad A.M. System Analysis and Design, Irwin, 1985. Blum, B.I. A taxonomy of software development methods. Comm. of the ACM, vol. 37(11), 1994, 82-94. Boehm, B.W. Seven Basic Principles of Software Engineering, Journal of Systems & Software, 3(1) | March 1983, pp. 3-24. Brooks, F.P. The Mythical Man Month. Addison Wesley, 1975. Brooks, F.P. No silver bullet: essence and accidents of software engineering. Computer vol.20 (no 4), 1987, 10-19. Davis W.S, Yen D.C. The Information System Consultant's Handbook: Systems Analysis and Design. CRC Press, 1999. Dennis A., Wixom B.H., Tegarden D. Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, 2nd Edition, 2005
Reference
IEEE Std 610.12-1990 "Standard Glossary of Software Engineering Terminology" in IEEE Software Engineering Standards Collection, 1994 Edition, IEEE, New York, 1994, p. 67. Harel, D. Biting the Silver Bullet: Toward Brighter Future for System Development, Computer, 25 (1), 1992, 8-20. Hirscheim, R. and Klein, H.K. Four paradigms of information systems development, Comm. of the ACM, 32 (10), 1989, 1199 - 1216. Maciaszek L. Requirements Analysis and System Design: Developing Information Systems with UML, 3/ed, Addison Wesley Higher Education, 2007. McConnell S. Software Project Survival Guide Microsoft Press, 1998. McConnell S. : Rapid Development: Taming Wild Software Schedules. Redmond, Wa.: Microsoft Press, 1996.
81
82
Strateko planiranje poslovanja

Strateko planiranje poslovanja
Definiranje poslovne strategije, dugorono planiranje resursa i akcija Uprava definira viziju i misiju organizacije, tj. strateke ciljeve. misija svrha (postojanja) organizacije, odreuje postojee stanje i procese vizija namjeravano, oekivano stanje u daljoj budunosti primjer: http://www.zaba.hr (O nama) Na temelju toga definiraju se poslovni ciljevi, poslovni procesi i zadaci kojima e organizacija u planiranom razdoblju ispuniti svoju misiju. to se eli postii (vrijednosti): prepoznatljivost, kvaliteta, prihodi, ... kako to postii: promjenom organizacije, poboljanjem sustava administracije, ...
poveanje proizvodnosti ulaganjem u nove proizvodne tehnologije uz istovremeno odravanje kakvoe proizvoda osiguranje zadovoljstva i radnih sposobnosti zaposlenika dokolovanjem i mogunostima napredovanja
Strategija organizacije Identifikacija i selekcija projekata Pokretanje i planiranje projekata
Corporate strategy Project Identification and Selection Project Initiation and Planning
imbenici koji utjeu na postavljanje ciljeva

ogranienja (organizacijska, financijska, zakonska, ) potrebe i elje uprave, poslovodstva, zaposlenika (ugled, utjecaj, )
Vremenski okviri, razdoblje [Awad, 1985]:

kratkorono, obino manje od 2 godine srednjerono, 2-5 godina dugorono, vie od 5 godina
Planiranje informacijskog sustava

Traenje odgovora na pitanja:
ime se organizacija bavi (grana, proizvodi, trite, konkurencija)? Koji su problemi, zadae i ciljevi poslovnog sustava? Koja je eljena uloga IS u postizanju postavljenih ciljeva? Koje aplikacije postoje, emu i kako slue, koje i kakve podatke sadre? Postoje li aplikacije iji je razvoj u tijeku? U kojem su stadiju razvojni projekti? Koje su potrebne aplikacije? Koji su raspoloivi resursi (osoblje, tehnika sredstva, tehnologija, )?
Strateko planiranje IS
Tradicionalno planiranje IS
provodi se odvojeno od poslovnog planiranja ili provodi se kao reakcija na promjene u poslovnoj politici
Strateko planiranje IS
procjena alternativnih usluga, aplikacija i infrastrukture uspostava smjera i prioriteta usklaivanja informacijskih servisa sukladno misiji, viziji i ciljevima organizacije planiranje IS sukladno strategiji razvoja organizacije, tako da informatizacija bude potpora promjeni organizacije i poslovnih procesa primjena metoda analize i dizajna na istraivanje poslovnog sustava s ciljem definiranja opeg (sveobuhvatnog) plana i arhitekture IS iji razvoj slijedi
Razlozi zbog kojih treba planirati IS

U Organizaciji sastavljenoj od vie cjelina, kao to su Uprava, Financije, Proizvodnja i Informatika postoji vie sustava ili aplikacija (informatikih otoka) uz posljedicu: umnoavanje informacija uz razliito tumaenje u razliitim dijelovima nepotpunost informacija, naroito kada svaka cjelina prikuplja samo njoj vane informacije problem povezivanja informacija pri pokuaju cjelovite interpretacije problem razliite arhitekture, razliitog posluivanja, razmjene podataka i odravanja
U praksi ...
Umjesto prema stratekom planu, organizacija se "dovodi u red" tijekom informatizacije i s pomou informatizacije. Analizom sustava evidentiraju se problemi i slabosti poslovnih procesa. Dizajnom sustava predlau se ili nameu poboljanja.
Primjer: Pilot projekt informatizacije visokih uilita

Okosnica plana razvoja sustava

Enterprise modeling Enterprise model Enterprise data model
Primjer strategije: Drutvo (1)

Poslovna strategija
Kljune vrijednosti su nematerijalne: Tradicija, Ugled, Povjerenje, Iskustvo, Znanje, Motivacija, IS Potpora IT za konkurentnost na tritu ne moe se kupiti (od/za izravnog konkurenta)
Strategic business planning
Orijentacija ka klijentu (CRM)

Strategic information planning
P A
User review
P A D C
User review
P A D C
User review
Ponuda proizvoda ponuda usmjerena na klijente Zadovoljavati stalno promjenjive potrebe klijenata visoko personalizirani proizvodi djelotvorna prodaja putem kanala distribucije, ukljuivi mobilnu prodaju
D C
R.McLeod, E.Jordan (2002). Systems Development: A Project Management Approach,ISBN: 0471-22089-2, Wiley Higher Education
Razvoj poslovne inteligencije (BI)

pronalaenje skrivenih zakonitosti (znanja) potpora poslovnom odluivanju: informacije: pravovremene, pouzdane, relevantne doprinos poveanju konkurentnosti i dinaminosti poslovanja

Infrastruktura
Stanje: prikladno odabrana i adekvatna potrebama Budunost: zadravanje + proirenje ~ potrebe Poboljanja: upravljanje IT infrastrukturom ugradnja koncepata i praksi za upravljanje i nadzor informacijskih servisa koristi: definiranost i efikasnost procesa IT potpore npr. uspostava jedinstvenog kontaktnog centra (service desk) za pomo korisnicima IT sustava te pozivnog (call) centra za krajnje korisnike

Poslovne aplikacije
Zadovoljavajua funkcionalnost prijedlozi konkretnih poboljanja unaprjeenje, zamjena, integracija ... Nedostatna integriranost potekoe u iskoristivosti, prepreka daljem razvoju (npr. CRM, jedinstvena autentifikacija/autorizacija korisnika) temeljem procjene
Service Oriented Architecture (SOA) Event Driven Architecture (EDA) Enterprise Service Bus (ESB) integraciju temeljiti na matinim podacima i standardnim sueljima
Usvajanje nadolazeih regulativa

Financijska industrija sve vie regulirana (Basel II, Solvency II) Znaajni zahtjevi na infrastrukturu i ostale dijelove IS
Sigurnost i zatita informacijskog sustava

uvesti SABSA, ISO (COBIT) zatita od neovlatenog pristupa oporavak nakon incidenta osiguranje kontinuiteta poslovanja, rezervna raunalna lokacija formirati odbor za informacijsku sigurnost
Arhitektura IS
prelazak sa dvoslojne na vieslojne web aplikacije odabir razvojnog alata uvaavajui strategiju proizvoaa RDBMS odabir i migracija razvojne platforme - pilot projektima upravljanje projektima i razvojem aplikacija agilnost, modeliranje procesa

Upravljanje informacijskim sustavom
uskladiti ciljeve i djelovanje Informatike sa strategijom i ciljevima poslovanja Problem - neureenost odnosa Informatike i poslovanja zahtjevi na Informatiku dolaze kaotino odluke bez Informatike Osnovati Odbor za informatiku (IT Steering Committee) istaknuti predstavnici poslovnih podruja usmjeravanje, prioritizacija i nadzor poslova Informatike Reorganizacija Sektora informatike Ured za upravljanje projektima Centar kompetencije za poslovnu inteligenciju Sluba za poslovne procese Upravljanje IT servisima prema ITIL smjernicama
ID 1 4 2 13 18 35 3 9 11 5 6 36 8 12 14 25 17 15 16 29 10 19 20 22 28 7 26 21 34 30 24 27 31 33 23 32 37 38 39

Plan informatizacije za razdoblje 2008-2012
Drutvo-Strategija.mpp
Task Name Osnivanje Odbora za informatiku Dovretak konsolidacije baza podataka, standardizacije i dokumentiranja postoje Plan rada i prorauna za 2008. i do 2010. Formirati odbor za informacijsku sigurnost i to prije postaviti CISO-a (Voditelja sig Reorganizacija Sektora informatike Osnivanje Ureda za upavljanje projektima Zapoljavanje novih 15 dipl.ing. raunarstva /informatiara Odabir vanjskog dobavljaa usluga govorne telefonije i njena implementacija. Zapoljavanje strunjaka iz podruja informacijske sigurnosti (ljudi s posjedovanje Pilot projekt primjene objektno usmjerene razvojne platforme (JDeveloper naspra Projekt mobilnog kompleta za prodaju ... Uspostvljanje uoravitelja promjenama i Odbora za upravljanje promjenama Osnivanje grupe za izradu i odravanje web-sjedita i poetak izrade novog sjedi Oblikovanje ekipe za odgovore na sigurnosne incidente Pristupiti oblikovanju ekipe za provoenje analize informacijskih rizika. Implementacija sustava za spreavanje napada (IPSs - Intrusion Prevention Syste Realizacija projekta Kontinuirani automatski back-up podataka poslovnog sustav Nastaviti s projektom ISMS-a (Upravljanje sustavom informacijske sigurnosti) sve Izraditi i revidirati sve ugovore s vanjskim dobavljaima u pogledu osiguranja infor Izrada Plana kontinuiranog poslovanja (BCP) prema normi BS 25999- 1:2006 za s Proirenje skladita podataka na podruje prodaje ... Zapoljavanje novih 20 dipl.ing. raunarstva /informatiara Nabava alata za oblikovanje procesa, standardizacija i dokumentiranje poslovnih Procjena stanja na podruju programske potpore meusloju aplikacija te nabava s Uvoenje uravnoteenih kartica postignua (balanced scorecards) Implementacija kontakt centra potpore krajnjim korisnicima Certifikacija prema normi ISO 27001:2005 Konana odluka o buduoj arhitekturi sustava i migraciji postojeih aplikacija. Projekt automatiziranog upravljanja poslovnim procesima. Dovretak preoblikovan Uvoenje dubinske analize podataka Implementacija reorganizirane potpore korisnicima informacijskog sustava (Servic Implementacija PKI infrastrukture kroz koritenje nacionalnog Certifikacijskog tijel Zapoljavanje novih 25 dipl.ing. raunarstva /informatiara Certifikacija za kontinuitet poslovanja prema normi BS 25999-2:2007 ( norma u ob Integracija sustava Realizacija jedinstvene prijave na informacijski sustav (Single-Sign-On). Implementacija sustava za upravljanje odnosa s kupcima (CRM) Individualiziranje ponude proizvoda klijentima Migracija aplikacija Duration 3 mons 12 mons 2 mons 2 mons 12 mons 6 mons 200 days 6 mons 3 mons 12 mons 12 mons 3 mons 6 mons 3 mons 3 mons 6 mons 18 mons 12 mons 12 mons 6 mons 12 mons 263 days 6 mons 6 mons 6 mons 12 mons 6 mons 3 mons 12 mons 6 mons 6 mons 6 mons 522 days 6 mons 24 mons 12 mons 12 mons 6 mons Start Fri 28.3.08 Fri 28.3.08 Fri 20.6.08 Fri 20.6.08 Fri 20.6.08 Fri 20.6.08 Fri 15.8.08 Fri 15.8.08 Fri 7.11.08 Fri 5.12.08 Fri 5.12.08 Fri 5.12.08 Fri 30.1.09 Fri 30.1.09 Fri 30.1.09 Fri 30.1.09 Fri 27.2.09 Fri 24.4.09 Fri 24.4.09 Fri 24.4.09 Fri 22.5.09 Fri 22.5.09 Fri 22.5.09 Fri 22.5.09 Fri 22.5.09 Fri 17.7.09 Fri 17.7.09 Fri 6.11.09 Fri 6.11.09 Fri 23.4.10 Wed 26.5.10 Wed 26.5.10 Wed 26.5.10 Fri 16.7.10 Fri 8.10.10 Fri 25.5.12 Fri 26.4.13 Fri 28.3.14 Finish Thu 19.6.08 Thu 26.2.09 Thu 14.8.08 Thu 14.8.08 Thu 21.5.09 Thu 4.12.08 Thu 21.5.09 Thu 29.1.09 Thu 29.1.09 Thu 5.11.09 Thu 5.11.09 Thu 26.2.09 Thu 16.7.09 Thu 23.4.09 Thu 23.4.09 Thu 16.7.09 Thu 15.7.10 Thu 25.3.10 Thu 25.3.10 Thu 8.10.09 Thu 22.4.10 Tue 25.5.10 Thu 5.11.09 Thu 5.11.09 Thu 5.11.09 Thu 17.6.10 Thu 31.12.09 Thu 28.1.10 Thu 7.10.10 Thu 7.10.10 Tue 9.11.10 Tue 9.11.10 Thu 24.5.12 Thu 30.12.10 Thu 9.8.12 Tue 26.4.11 Thu 25.4.13 Thu 27.3.14 Thu 11.9.14 2008 2009 2010 2011 2012 2013 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1 Qtr 2 Qtr 3 Qtr 4 Qtr 1
Ljudski resursi
Za standardne funkcije (financije, kadrovi, ...) mogua nabava standardnih aplikacija Vlastiti razvoj ili potpuno upravljanje nabavljenim softverom za osnovnu djelatnost Outsourcing, insourcing, multisourcing kao modaliteti angamana vanjskih usluga kriterij: tehnika, tehnoloka i podatkovna kompatibilnost nedostatak resursa - postupno udvostruiti broj strunjaka stimulativno zapoljavanje i zadravanje osoblja
6 mons Wed 10.11.10
92
Primjer strategije: Poduzee (1)

Prosinac 2005.
Tridesetak aplikacija Informacijski otoci Razliite tehnologije Zastarjela tehnologija Raspreno osoblje Zastarjela podjela posla

Direktor
Definiranje smjernica razvoja i organizacije informatike podrke

sistematizacija radnih mjesta u informatici i reorganizacija slube poduka informatikih djelatnika
Uprava
Rukovoditelj Slube informatike
Definiranje smjernica razvoja i arhitekture raunalnog sustava

integracija sustava nad zajednikim modelom podataka razvoj aplikacija
Primjena
Funkcionalnost je dobra uz 3 (od 17) izuzetka. Aplikacije su izrazito potrebne. Korisnicima je lako koristiti aplikacije. Veina aplikacija je dosta fleksibilna, samo dvije su izuzetak. Tonost je prilina. Stabilnost zadovoljavajua. Brzina vrlo dobra. Dostupnost i adekvatnost opreme vie nego vrlo dobra uz samo 1 izuzetak. Korisnika dokumentacija je osrednja. Obuenost korisnika je dobra, ali bi mogla biti i bolja. Podrka je svagdje dobra do odlina.
Smjernice upravljanja IS-om Smjernice upravljanja sigurnosti IS-a Taktiki plan provedbe projekta izgradnje IS
Odjel razvoja
Vii sistem analitiar
Odjel pomoi korisnicima

Voditelj Odjela pomoi korisnicima/Zamjenik rukovoditelja Slube Instruktor korisnike podrke
Odjel tehnike potpore

Glavni sistem inenjer/Voditelj Odjela tehnike podrke Sistem inenjer Administrator baze podataka Administrator mree
Sistem analitiar
Analitiar Serviser informatike opreme Programer

93 94

Plan za razdoblje 2006-2009.
Poduzee-Strategija.mpp
ID 1 2 51 126 49 94 108 146 16 28 50 Task Name Odravanje aplikacija Faza pripreme Vladanje informacijskim sustavom Izgradnja imenike infrastrukture Sistemski poslovi Osiguranje IT sustava na razini cjelokupne infrastrukture Izgradnja sigurnosnih politika/procedura/uputa usklaeni Implementacija sustava za upravljanje IT infrastrukturom Aplikacije osnovne djelatnosti Poslovne i raunovodstvene aplikacije Skladite podataka Duration 900 days 274 days 188 days 53 days 800 days 17 days 40 days 34 days 334 days 476 days 6 mons Start Mon 21.11.05 Mon 16.1.06 Mon 13.2.06 Wed 5.4.06 Mon 17.4.06 Mon 19.6.06 Wed 12.7.06 Wed 6.9.06 Fri 2.2.07 Fri 2.2.07 Mon 1.12.08 Finish 5 2 H2 H Fri 1.5.09
ID 1 2 3 4 5 6 7 8 9

Aurirani plan pripreme 2009.
Task Name Faza pripreme Uspostava infrastrukture projekta (TFS, SP kolovanje za modeliranje podataka kolovanje za SQL kolovanje za razvojno okruenje Formiranje ekipa Metodologija razvoja Razvoj programske okosnice Poduka primjene metodologije i okosnice
Duration 80 days 5 days 5 days 5 days 15 days 30 days 30 days 60 days 10 days
Start Mon 26.1.09 Mon 26.1.09 Mon 2.2.09 Mon 16.2.09 Mon 2.3.09 Mon 23.3.09 Mon 26.1.09 Mon 26.1.09 Mon 11.5.09
Finish Fri 22.5.09 Fri 30.1.09 Fri 6.2.09 Fri 20.2.09 Fri 20.3.09 Fri 8.5.09 Fri 6.3.09 Fri 24.4.09 Fri 22.5.09
Qtr 1, Jan
Thu 1.2.07 Wed 1.11.06 Fri 16.6.06 Fri 8.5.09 Tue 11.7.06 Tue 5.9.06 Mon 23.10.06 Wed 14.5.08 Fri 28.11.08 Fri 15.5.09
95
96
Kontekst pokretanja projekata

1 Survey and plan the project Unplanned System Request System Users Production System training, support, and feedback Project and System Scope 2 Study and analyze the existing system the business, problems, causes, and effects requirements and rriorities System Objectives ideas and opinions demonstrations and feedback ideas and opinions Functional System 7 Construct and test the target system Design Specifications 6 Design and integrate the target system Design Requirements Prototypes consulting services Information Technology Vendors 8 Install and implement the production system
scope
Odabir i pokretanje projekata

technical leadership executive leadership
Planned System Project
technical support installation support
problem statement and feasibility analysis
3 Define and priortize the business requirements
Business Requirements
Feasibility Assessment and Project Plan technology standards System Owners system proposal technology proposal
Business Requirements
4 Target a feasible system solution
Technology Integration Requirements
Request for Proposals
Technology Requirements
Business Requirements technology standards
5 Purchase any new hardware and software
Proposals
Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley
98
Identifikacija projekta
Sponzor projekta = osoba ili grupa koja ustanovi poslovne potrebe
najee netko iz poslovnog podruja (Financije, Studentska, Proizvodnja)
Predlaganje projekata
Predlaganje projekata
temeljem (prethodno napravljenog) plana informatizacije planu prethodi analiza i prijedlog strategije temeljem zahtjeva na sustav unutar organizacije sponzor projekta interno dostavlja zahtjev na sustav (system request) uoavanjem poslovnih potreba provodi se snimka stanja i izrada internog prijedloga - povelje projekta temeljem prijava na natjeaj organizacije/institucije koja trai rjeenje u sluaju natjeaja otvorenog tipa vanjski predlagatelj navodi potencijalno trite ili korisnike te oekivanu korist primjeri:
Program hrvatskog inovacijskog tehnologijskog razvitka (HITRA) Razvoj na znanju utemeljenih poduzea (RAZUM) natjeaj MZO za prijavu i-projekta (iprojekti.mzos.hr)
Pokretai promjena
korisnici - nezadovoljstvo aplikacijama i/ili podacima (nepouzdanost, nedostupnost, manjkavost), prijedlog novih mogunosti npr. nestabilnost aplikacija, potrebe za podacima, potreba za novim funkcijama reorganizacija, utjecaji okoline promjene organizacijske strukture, promjene poslovnih procesa npr. promjene na Sveuilitu uzrokovane novim Zakonom, restrukturiranje studija, smjerova i zavoda pokazatelji poslovanja npr. pad prodaje, uska grla proizvodnje, neplanirano i nejasno poveanje trokova zastarjela tehnologija zahtjev za novim tehnologijama npr. razvojni alati (problem odravanja), korisnika suelja (Internet), baze podataka, neintegriranost sustava (informacijski otoci)
Odabir projekta (project selection)

povjerenstvo/odbor za odabir (steering committee, approval comitee) odobrava projekte, nakon ega slijedi dublja analiza i ponovna procjena
Zahtjev na sustav
Zahtjev na sustav
saetak projekta (sponzor, naziv, cilj, svrha) npr. odjel Financija, dopredsjednik Marketinga poslovne potrebe poslovni razlozi za pokretanje npr. poveanje prodaje, poveanje udjela na tritu, poboljtanje pristupa podacima, poboljanje usluge krajnjim korisnicima poslovni zahtjevi poboljane mogunosti poslovanja npr. pristup putem interneta, prikupljanje podataka o kupcima, izrada upravljakih izvjea oekivana korist poslovna vrijednost npr. poveanje prodaje 3%, poveanje udjela na tritu 1%, utede u odravanju sustava posebnosti i ogranienja - argumenti relevantni za odobrenje npr. rok do kraja poslovne godine, kompatibilnost s politikom sigurnosti i zatite
Pokretanje projekata (project initiation)

Snimka stanja, poetno istraivanje (survey phase, initial study, preliminary investigation)
prethodno istraivanje, tj. istraivanje koje prethodi projektu pokree se na zahtjev za sustav prepoznavanje problema i potreba traenje odgovora na pitanje "Da li je projekt vrijedan panje?" rezultat je povelja projekta (project charter) i poetni (grubi, okvirni) plan projekta povjerenstvo odobrava, odbacuje ili odgaa prijedlog
Analiza izvodljivosti, Faza prouavanja problema (study phase)

produbljenje snimke uoavanje problema, uzroka i moguih posljedica odreivanje dosega preciziranje ciljeva, prijedlozi rjeenja, procjena izvodljivosti "Da li su problemi vrijedni rjeavanja?, "Da li je gradnja isplativa?" povjerenstvo odobrava, odbacuje ili reducira projekt
Upravljanje projektom (
Organizacija i upravljanje projektom)
Primjer:
\Planiranje\ZahtjevZaUslugamaIS
101
Izrada plana rada Ustroj projektne ekipe ukljuivanje sudionika iz razliitih djelatnosti, npr. djelatnici razliitih poslovnih podruja ili organizacijskih jedinica, uprava, vanjski konzultanti vano je osigurati predanost dionika zajednikom cilju (commitment) Uspostava upravljanja i nadzora projekta
Snimka stanja
Snimka stanja
brzo istraivanje i procjena problema, moguih prilika i direktiva problem: neeljena situacija koja sprjeava potpuno ispunjenje svrhe, postizanje ciljeva, obavljanje zadaa mogua prilika: mogunost pozitivne promjene, ak i kada ne postoji problem direktiva: zahtjev ili ogranienje nametnuti poslovnom politikom (npr. pravilnik) ili vanjskim utjecajem (npr. zakon) odreivanje poetnog dosega projekta i poetnog plana projekta
Primjer: postojei problemi, prijedlozi rjeenja

Kratko obrazloenje problema, mogunosti ili direktive
1. Vrijeme odgovora na narudbu mjereno od vremena zaprimanja narudbe do isporuke klijentu se povealo na prosjeno 15 dana 2. Nedavno preuzimanje kompanija: Privantna predstava i Filmsko platno nametnulo je poveanje zahtjeva za protokom informacija i dokumenata. 3. Trenutno 3 razliita sustava za unos narudbi servisiraju odjele za audio, video i video igre. Svaki sustav ima vlastito suelje prema razliitom skladinom sustavu, pa treba objediniti skladinu evidenciju. 4. Postoji nedostatak pristupa informacijama nunim za upravljanje i donoenje odluka. Ovo ce se jos pogorati preuzimanjem dva dodatna sustava za obradu narudbi (iz Privatna predstava i Filmsko platno ). 5. Izraena je nedosljednost (nekonzistentnost) izme u podataka u evedencijama lanova i narudbi. 6. Sustavi datoteka u Privatna predstava i Filmsko platno nisu kompatibilni s onim u Zvu na pozornica . Problemi s podacima obuhvaaju nedosljednosti u podacima i nedostatak upravljanja ulazom i izmjenama. 7. Postoji mogunost uvo enja sustava naruivanja putem Interneta, ali su sigurnost i kontrola pristupa problematini. 8. Postojei sustav unosa narudbi nije kompatibilan s planiranim sustavom za automatsku identifikaciju (tapiasti kod) koji se razvija za skladite.
Hitnost
HITNO 6 mjeseci 6 mjeseci 12 mjeseci
Vidljivost
Visoka Srednja
Korist
175,000 75,000
Prioritet
2 2
Predloeno rjesenje
Novi razvoj Novi razvoj
Srednja
515,000
Novi razvoj
Snimka poslovnog sustava

pregled poslovnih planova, ako takvi postoje ili nisu tajna prikupljanje informacija, najee intervjuiranjem vlasnika i viih rukovoditelja evidentiranje problema i prijedloga
Niska
15,000
Po razvitku novog sustava, pruiti korisnicima lako svladive alate za pisanje izvjetaja. Brza ispravka, a zatim novi razvoj Novi razvoj, dodatna ocjena koristi moze poveati urnost Budue verzije tek razvijenog sustava Brza ispravka, a zatim novi razvoj
3 mjeseca 6 mjeseci
Visoka Srednja
35,000 nepoznato
1 2
Snimka postojeeg (postojeih) IS

identifikacija korisnika i opsega postojeeg IS uoavanje problema i nedostataka postojeeg IS procjena potreba za nadgradnjom (poboljanjima) procjena potreba za izmjenama (prilagodbom i popravcima) procjena potreba za izradom novih IS ili podsustava IS
12 mjeseci 3 mjeseca
Niska Visoka
nepoznato 65,000
4 1
Primjeri:
\Planiranje\PISFER-Snimka-*
103
temeljem jednog kruga intervjua, prikupljanja dokumentacije i provjere

Vidljivost: U kolikoj mjeri e rjeenje ili novi sustav biti dostupni korisnicima. Korist: Paualna procjena koliko bi rjeenje povealo dobit ili smanjilo troak u jednoj godini.
Poetno planiranje projekta

Odreivanje cilja i svrhe projekta (goal, objective)
izdvajanje zadataka koji su sukladni poslovnim ciljevima, a mogu biti informatizirani Koji se probleme nastoji rijeiti projektom? Koje su oekivane koristi?
Izrada poetnog plana

Izrada poetnog plana razvoja IS
poetni glavni plan projekta (master plan, baseline plan) potprojekti, prioriteti, mogui naini podjele posla na cjeline tako da: cjelinu moe obaviti jedna osoba ili ekipa cjelina se moe obaviti jednom metodom posao zavri jednim proizvodom (dokumentom, aplikacijom ili podsustavom) okvirni vremenski plan po fazama dorauje se i aurira sukladno napretku projekta
Doseg i razgranienje projekata ili pod-projekata (Scope)

System boundary, Constraints, Objectives, Permissions, End products Koje su granice sustava? Koji e zahtjevi biti ispunjeni? Koja su ogranienja (tehnoloka, organizacijska, financijska) ? to ne moe biti napravljeno? to nee biti napravljeno? to e se postii ? emu e sluiti ? Tko e, kako i pod kojim uvjetima moi koristiti rjeenje? Kako se mjeri ili odreuje dovrenost i uspjeh (neuspjeh)?
Odobrenje (nastavka) projekta

konsolidirani prijedlog projekta, povelja projekta (project charter) moe posluiti kao interni ugovor projekta
Vremensko planiranje
odreivanje prioritetnih zadataka i okvirnih rokova prioriteta
Primjer: Poetni plan informacijskog sustava

Primjeri: \Planiranje\PlanStandardni, RIS-OkvirniPlan Primjer poetnog (preliminarnog) plana za Ministarstvo
1. Nabavka sustava za upravljanje bazama podataka 2. Teaj ope informatike pismenosti za rukovoditelje odjela 3. Teaj za programere u jeziku za upravljanje bazama podataka 4. Teaj za administratore baze podataka 5. Izrada prototipa programske podrke za i-tu fazu realizacije 6. Izrada - verzije aplikacije 7. Testiranje - verzije u Informacijskim sustavima 8. Uklanjanje uoenih nedostataka i izrada - verzije programa 9. Teaj za odabrane korisnike na - verziji 10. Testiranje kod korisnika u paralelnom radu s dosadanjim programom 11. Uklanjanje nedostataka i izrada stabilne verzije 12. Zamjena dotadanjeg programa novim programom, uz preuzimanje podataka 13. Teaj za ostale korisnike 14. Uvoenje koritenja programa kod ostalih korisnika 15. Teaj za upoznavanje s mogunostima programa za odabrano poslovodstvo 16. Prikupljanje primjedbi korisnika i novih zahtjeva 17. Izrada sljedee faze/verzije programa. Povratak na toku 5).
Povelja projekta
Primjeri: \Planiranje\
PrijavaProjektaPrimjeneIT PrijedlogProjektaPIS
108
Analiza problema
Produbljivanje analize za projekte koji prou poetnu selekciju
"Da li su problemi vrijedni rjeavanja?, "Da li je gradnja isplativa?" Detaljnija analiza problema, njihovih uzroka i posljedica "Ne pokuavaj popraviti prije nego shvati kako radi!" Analiza poslovnih procesa Koji su najvei problemi? Koja su mogua rjeenja problema? Kako informatizacija moe pomoi? Grubo modeliranje postojeeg sustava
Analiza izvodljivosti
Mogu se koristiti razliite formalne metode

Analiza kritinih faktora uspjeha (CSF - Critical Success Factors) imbenici kojima poslovodstvo posveuje posebnu panju imbenici koji razmjerno brzo i lako doprinose ostvarivanju ciljeva (npr. brzi odgovor na zahtjeve klijenata, odnos cijene i kvalitete proizvoda) Analiza izvodljivosti i procjena trokova-koristi
110
Primjer: uzroci i posljedice, ciljevi i ogranienja

ANALIZA UZROKA I POSLJEDICA Problem ili mogunost 1. Vrijeme odgovora na narudbu je neprihvatljivo dugo. Uzroci i posljedice 1. Promet je povean, a broj slubenika smanjen Vrijeme obrade narudbi je isto. 2. Sustav previe ovisi o runom unosu. Pojedine vrijednosti se unose vie puta. Posljedica je da se narudbe obrauju dulje nego je potrebno. CILJEVI I OGRANIENJA SUSTAVA Ciljevi sustava Ogranienja sustava
Istraivanje problema, uzroka i posljedica

Primjer: Istraivanje uzroka
Problem: pad prodaje Vidljivi znak: poveani opoziv (storno) narudbi Razlog: nezadovoljstvo kupaca Uzrok: spor sustav za naruivanje
1. Umanjiti vrijeme unosa pojedine 1. Broj zaposlenih u obradi narudbi se ne moe uveati. narudbe za 30%. 2. Runi unos narudbi svesti na 50% ukupnog broja. 2. Novi sustav mora biti kompatibilan s postojeim Windows XX standardom.
3. Na zaslonu za runi unos smanjiti broj potrebnih pritisaka 3. Novi sustav mora biti kompatibilan s ve odobrenim na tipkovinicu. sustavom za automatsku 4. Prenijeti unos podataka sa identifikaciju tapiastim 3. Sredinje raunalo radi na sredinjeg na osobna raunala. kodom. maksimumu svojih kapaciteta, 5. Zamijeniti postoje e obrasce za to se oituje u sporijem radu prikupljanje narudbi mrenim aplikacija za unos narudbi. sustavom izmeu skladita i Budui da slubenici prodaje tako da se eliminira pokuavaju bre raditi, poveao uporaba papirnate se broj pogreaka pri unosu. dokumentacije. 4. Obrasci za prikupljanje narudbi iz skladita nisu oblikovani za uunkovito popunjavanje, to dodatno usporava unos narudbi.
Zadatak analitiara je razdvojiti uzroke i posljedice problema.

Na primjer, sporost sustava nije izoliran problem nego moe biti posljedica pomanjkanja osoblja, nezainteresiranosti osoblja za posao ili posljedica rune obrade podataka.
112
Postavljanje ciljeva
Primjeri poslovnih ciljeva
Potpomoi reorganizaciju u trino orijentirano poduzee prema EU normama. Osigurati informacije o izvorima, razlozima i mjestu nastanka svakog troka u sustavu. Uskladiti hijerarhiju odluivanja s hijerarhijom u poduzeu. Racionalizirati utroak novca za ...
Ogranienja
Osoblje
Odjel informatike smije zaposliti najvie tri stalna zaposlenika
Materijalni troak
Nabavka uredskog i potronog materijala ne smije premaiti XXX HRK
Raunalna oprema
Projekt se mora obaviti bez nabavke novog hardvera (gospodarstvo?) Troak opreme poeljno predstavlja barem 33% budeta (znanost!)
Primjer ciljeva IS
Problem: Predugo vrijeme unosa narudbi Cilj: Ubrzanje unosa Kriterij: performance, izvedba Lo primjer: Poveanje ili smanjenje Poveati broj unijetih narudbi u 24 sata za 5% Bolji primjer: Uinkovitost provedbe Unijeti 98% zaprimljenih narudbi unutar 24 sata Kriterij mora biti mjerljiv Apsolutni iznos ili relativni iznos konkretne vrijednosti Moe biti binaran postoji ili ne postoji, npr. Omoguiti online pretraivanje
Financijska sredstva
Ukupni budet projekta je XXXXX HRK (uvijek manji od traenog!) Naknade izvoaima ne smiju premaiti XX% ukupnog iznosa
113
114
Kljuni imbenici uspjeha

Primjer: Urudbeni zapisnik
Izrada adekvatne programske podrke Unos svih podataka iz knjiga urudbenog zapisnika u bazu podataka Povezivanje sa slubama na fakultetu koji koriste iste dokumente (napraviti dijeljene dokumente) Osposobiti djelatnike za rad na novom sustavu
Analiza izvodljivosti
Analiza, Studija izvodljivosti (feasibility analysis, feasibility study)
mjerenje korisnosti, praktinosti i isplativosti projekta procjenjuje se da li je projekt izvodljiv s obzirom na raspoloiva sredstva procjenjuje se da li projekt omoguuje poboljanja radi se izvjee o izvodljivosti (feasibility report) i prezentira se relevantnim dionicima ili dostavlja odboru za odabir eventualni povratak u studiju izvodljivosti revidirano izvjee trebala bi se raditi tijekom planiranja, ali i kasnije (npr. nakon faze analize) nakon odluke o pokretanju projekta sloenost i opseg projekta mogu se promijeniti pa poetno izvodljiv projekt moe postati neizvodljiv
Primjer: CIP
odobrenje samostalnog budeta, te dodatno investiranje u softver, hardver i sustav rezervnog napajanja integracija sustava investicije u fiziku zatitu (protupoarni i protuprovalni sustav) zapoljavanje dodatnih djelatnika sa SSS
Svaki projekt je u poetku neodreen i "mutan"

"bistri" se prikupljanjem informacija i inkrementalnom doradom tonost procjene izvodljivosti raste s dubinom analize procjena izvodljivosti moe biti ponovljena u kontrolnim tokama izmeu kljunih faza projekta
Organizacijska izvodljivost
Ima li smisla graditi ? Hoe li se koristiti?
Organizacijska izvodljivost
Socio-psiholoka izvodljivost
Da li e rjeenje zadovoljiti korisnikove potrebe? Do kojeg stupnja? Kako e rjeenje promijeniti korisnikovu radnu okolinu?
Operativna izvodljivost
procjena hitnosti rjeavanja problema (planiranje) procjena prihvatljivosti rjeenja (kasnije faze)
Vrijedi li rjeavati problem? Da li predloeno rjeenje rjeava problem?

PIECES koncept
P [performance] potreba za poboljanjem performansi, npr. protonost i odziv sustava I [information] potreba za poboljanjem informacija (i podataka), pravodobne, prikladne, aurne, korisne informacije E [economics] potreba za poboljanjem ekonomije, kontrole trokova ili poveanje profita, npr. usluge i kapaciteti, smanjenje trokova C [control] potreba za poboljanjem kontrole ili osiguranja, npr. tonost, sigurnost i zatita podataka E [efficiency] potreba za poboljanjem efikasnosti ljudi i procesa, npr. maksimalna uporaba raspoloivih resursa (ljudi, vrijeme) S [service] potreba za poboljanjem usluge kupcima, dobavljaima, partnerima, zaposlenicima, npr. poeljni i pouzdani servisi, elastinost i mogunost prilagodbe
Koji je stav korisnika prema rjeenju? Da li e se sustav koristiti?

Podrka uprave Prihvaanje od krajnjih korisnika otpori njihovoj buduoj ulozi ili tehnikom rjeenju i kako ih prevladati Promjena radnog okruenja, procedura prilagodba promjenama Rizici slabe informatike pismenosti, straha od neznanja, novog naina rada ili gubitka posla, otpora radi gubitka kontrole i utjecaja
Procjena upotrebljivosti (najee prototipom u kasnijim fazama)

Krivulja uenja vrijeme osposobljavanja potrebno za postizanje pune primjene Lakoa koritenja jednostavno suelje za poetnike i povremene korisnike, sloenije operacije za iskusne korisnike Zadovoljstvo ponuenom rjeenju korisnik daje prednost pred postojeim
Tehniko-tehnoloka izvodljivost
Moe li se sagraditi? Moe li se kupiti?
Vremenska izvodljivost
Kada e biti gotovo? Moe li biti gotovo na vrijeme?
Procjena moguih rjeenja i alternativa

procjena postojeih rjeenja na tritu ili u drugim organizacijama procjena primjenjivosti razliitih tehnologija
Prihvatljivost vremenskog rasporeda

Razmatra se opravdanost rokova s obzirom na raspoloivu strunost
Poeljni rokovi
Bolje je isporuiti ispravan sustav neto kasnije, nego neispravan ili beskoristan na vrijeme!!!
Primjenjivost rjeenja, tehnologije

Moe li se tehnologija jednostavno primijeniti? Najsuvremenija tehnologija - naprednost, zanimljivost, rizik Zrela i dokazana tehnologija - sigurnost, bolja podrka
kanjenje pojedinih zadataka ili dodavanje novih zadataka (uslijed upravljanja promjenama) posmie zavretak projekta iterativno se aurira ili predlae alternativni vremenski plan
vrsti rokovi (timeboxing)

1. 2. 3. 4. 5. 6.
Raspoloivost tehnologije (podrazumijeva se da je primjenjiva)

Moe li se nabaviti? Ako je rije o gotovom rjeenju (IS iz duana), ima li to rjeenje potrebne karakteristike? Treba li ga i u kojoj mjeri prilagoditi ili doraditi?
Strunost
Postoji li potrebna strunost za primjenu tehnologije? Postoji li potrebna vjetina za oekivani zavretak prema rasporedu?
postavlja se vrsti rok isporuke odreuju prioriteti funkcionalnosti koju treba ugraditi gradi se jezgra sustava (nune funkcionalnosti) odgaa se ugradnja funkcionalnosti koja ne moe biti dovrena na vrijeme u roku se isporuuje sustav s dosegnutom funkcionalnou ponavljaju se koraci 3. do 5. s nadodanom funkcionalnou iskustvo na slinim projektima (najbolje) modeli koji su predvieni za tip industrije i tip razvoja (npr. COCOMO) opi modeli razvojnog procesa (npr. Rapid Development)
Koliko je razuman predloeni plan?
Primjer: Uprava-IzborAlata
120
Preciznost procjene
Faza projekta Poetni koncept projekta Odobreni koncept projekta Specifikacija zahtjeva Specifikacija dizajna detaljni dizajn projekta Potrebni rad i veliina projekta Optimistino 0.25 0.50 0.67 0.80 0.90 Pesimistino 4.0 2.0 1.5 1.25 1.10 Trajanje projekta Optimistino 0.60 0.80 0.85 0.90 0.95 Pesimistino 1.6 1.25 1.15 1.10 1.05
Postupak procjenjivanja
Osnovni koraci
Procjena veliine projekta (broj programskih redaka ili funkcijskih toaka). Ovaj korak je intelektualno najzahtjevniji i to je jedan od razloga zato ga ljudi esto preskau. Alternativno, veliina se moe odrediti usporedbom u odnosu prema odgovarajuim dijelovima starog projekta Procjena potrebnog uloenog rada u ovjek-mjesecima (m). Moe se izraunati iz procjene veliine projekta i povijesnih podataka rada na slinim projektima. Procjena trajanja (vremenski plan) projekta npr. u kalendarskim mjesecima. Trivijalno se rauna iz procjena veliine i potrebnog rada.
Trokovi projekta (veliina i potrebni rad) 4x 2x 1.5 1.25x 1.0x 0.8x 0.67x 0.5x 0.25x Poetni koncept projekta Odobreni koncept projekta Specifikacija zahtjeva Specifikacija dizajna
Trajanje projekta
1.6x 1.25x 1.15x 1.1x 1.0x 0.9x 0.85x 0.8x 0.6x Detaljni dizajn projekta Zavren projekt
121
Meta korak
Procjene treba izraavati u rasponima i, kako projekt napreduje, postupno smanjivati raspone i poveavati preciznost procjene.
122
Procjena veliine postupkom funkcijskih toaka

Funkcijska toka je umjetna mjera veliine programa (Albrecht 1979).
Iz specifikacije zahtjeva lake je odrediti funkcijske toke nego broj programskih redaka, i one daju toniju mjeru veliine programa u ranim fazama projekta.
Raunanje funkcijskih toki

Nemodificirani zbroj funkcijskih toaka. Potrebno je
odrediti elemente programa (ulaz, izlaze, upite i datoteke), odrediti njihovu sloenost, te ih zbrojiti pomnoene odreenim koeficijentom (tablica).
Broj toaka odreuje se iz broja i sloenosti elemenata programa: Ulazi u program

Ekrani, ekranski obrasci, dialog prozori, kontrole i poruke kroz koje krajnji korisnik ili drugi programi dodaju, briu ili mijenjaju podatke u programu. Ovo ukljuuje sve ulaze koji imaju jedinstveni oblik ili jedinstvenu logiku obrade podataka.
Izlazi iz programa
Ekrani, izvjetaji, grafovi ili poruke koje program stvara za krajnjeg korisnika ili druge programe . Ovo ukljuuje sve izlaze koji imaju jedinstveni oblik ili trae razliitu logiku obrade podataka od ostalih izlaza.
Nemodificirani zbroj moe se pomnoiti faktorom utjecaja

Rauna se koliki utjecaj na produktivnost imaju imbenici poput protoka podataka, sloenosti programske logike, jednostavnosti instalacije i sl. Faktori mogu imati vrijednosti izmeu 0.65 i 1.35.
Karakteristike Programa Broj ulaza Broj izlaza Upiti Unutarnje datoteke Vanjske datoteke
Upiti
Kombinacije ulaza i izlaza gdje ulaz rezultira trenutnim i jednostavnim izlazom. Izraz dolazi iz baza podataka i odnosi se na izravnu potragu za podacima koristei jedinstveni klju. U suvremenim aplikacijama s grafikim korisnikim sueljem granica izmeu upita i izlaza je nejasna jer su upiti nad bazom jednostavni, a izlazi mogu obraivati podatke i mogu sadravati sloene formate.
Funkcijske toke mala sloenost x3 x4 x3 x7 x5 srednja sloenost x4 x5 x4 x10 x7 velika sloenost x6 x7 x6 x15 x10
124
Unutarnje logike datoteke

Glavne logike skupine podataka koje program u potpunosti kontrolira. Logika datoteka se moe odnositi na obinu datoteku ili na tablicu u bazi podataka.
Vanjske datoteke suelja

Datoteke koje kontroliraju drugi programi s kojima na program komunicira.
Primjer zbroja funkcijskih toki

Pretpostavimo da imamo unutarnju datoteku koja sadri podatke o djelatnicima nekog poduzea. Podacima manipuliramo preko ulaza kojima unosimo, briemo i mijenjamo podatke o djelatnicima. Takoer imamo i upit koji prikazuje trenutne podatke o djelatnicima. Jednom mjeseno ispisuje se telefonski imenik djelatnika u kojem se nalazi i raspored djelatnika po uredima. Ovo raunamo kao izlaz.
Karakteristike Programa Broj ulaza Broj izlaza Upiti Unutarnje datoteke Vanjske datoteke Funkcijske toke mala sloenost 3x3 = 9 0x4 = 0 1x3 = 3 1x7 = 7 1x5 = 5 srednja sloenost 0x4 = 0 1x5 = 5 0x4 = 0 0x10 = 0 0x7 = 0 velika sloenost 0x6 = 0 0x7 = 0 0x6 = 0 0x15 = 0 0x10 = 0 29
125
Odreivanje faktora utjecaja

Zbroj funkcijskih toki mnoi se faktorom dobivenim temeljem 14 opih karakteristika sustava
Stupanj utjecaja - Degree of Influence (DI) Faktor utjecaja - Value Adjust Factor (VAF) = (TDI*0.01)+0.65
Ope karakteristike (GSCs) 1 Prijenos/Komunikacija podataka, npr. Web 2 Raspodijeljena obrada, npr. klijent posluitelj 3 Performanse npr. min. Vrijeme odziva 4 Konfiguriranje, npr. esto postavljanje (setup) 5 Uestalost transakcija 6 Interaktivni unos podataka (On line data entry) 7 Dizajn obzirom na uinkovitost korisnika 8 Dinamiko auriranje (Online updates) 9 Sloena obrada, npr. izrauni, pogledi 10. Korisnost u drugim aplikacijama 11. Lakoa uvoenja (instalacije) 12. Lakoa primjene (Operational Ease) 13. Rairenost (Multiple sites) 14. Mogunost promjena Ukupni stupanj utjecaja (TDI) Value Adjust Factor (VAF) = (TDI*0.01)+0.65
Telefonski imenik ukljuuje podatke iz datoteke o djelatnicima kojom upravlja druga aplikacija. Ovo raunamo kao vanjsku datoteku. Pretpostavimo da je sloenost svih karakteristika programa osim telefonskog imenika (izlaz) mala.
Stupanj utjecaja (DI) 1 0 0 3 0 3 5 4 0 0 2 4 0 3 25 (25*0.01)+0.65 = 0.9

126
Nemodificirani zbroj funkcijskih toaka:

Procjena objektnim tokama i sluajevima koritenja

Objektne toke (aplikacijske toke, ne razredi!)
Pojednostavljena alternativa procjeni funkcijskim tokama Procjenjuje se broj zaslonskih maski, izvjea i programskih modula za pristup podacima Moe se koristiti u ranim fazama
Procjena analogijom
Skaliranje poznavanjem ciklusa i provedene aktivnosti
npr. poznata je razdioba optereenja za poslovne projekte: Planiranje (15%), Analiza (20%), Dizajn (35%), Izrada (30%) ako je na planiranje utroeno 4m, slijedi Analiza (5.33m), Dizajn (9.33m), Izrada (8m)
Skaliranje analizom povijesnih podataka Funkcijske i objektne toke

mogu se odrediti temeljem dijagrama dekompozicije funkcija, dijagrama toka podataka i ER dijagrama, odnosno UC dijagrama i dijagrama razreda struktura proizvoda, vrste projekata, evidencija utroenog vremena,
DBMS Entities Relationships Generated Manually coded Zim 56 27 75% sophisticated functions Zim 106 310 55% sophisticated functions Informix 78 90 20% sophisticated functions Informix 85 116 10% sophisticated functions Informix 39 44 90% sophisticated reports Zim 47 83 80% sophisticated functions Model Domains Attributes Entities Primary Keys Initial Model of the central system 285 285 103 99* The model at the end of integration 553 636 146 151* The model at the end of design 338 459 131 135 Project EOM ISPAP* ISSA** ISTM** ROS SEE Coding 84% 31% 73% 64% 58% 71% Foreign Keys 0 243 228
Program element Program module Form TOTAL

No. of elements 400 170 570
No. of source code lines 250.000 10.000 260.000
Source code size (KB) 8.200 300 8.500

128
Odreivanje produktivnosti
Standardne vrijednosti za LOC
Real-time embedded systems, 40160 LOC/P-month. Systems programs , 150-400 LOC/P-month. Commercial applications, 200-900 LOC/P-month.
Language SLOC/UFP Ada 71 AI Shell 49 APL 32 Assembly 320 Assembly (Macro) 213 ANSI/Quick/Turbo Basic 64 Basic-Compiled 91 Basic-Interpreted 128 C 128 C++ 29 ANSI COBOL 85 91 Fortran 77 105 Forth 64 Jovial 105 Lisp 64 Modula 2 80 Pascal 91
Procjena produktivnog vremena IT osoblja

Produktivnost pada prema broju osoba u ekipi.
Ukupno vrijeme je izraeno s:
n ( n 1) TPT = nH p 0.0001 2
gdje je:
Produktivnost za objektne toke

Izmeu 4 i 50 OT / mjesec, ovisno o alatu i vjetini
TPT p H n
vrijeme produktivnosti tima u satima po tjednu postotak radnog tjedna koji se smatra produktivan broj radnih sati jedne osobe po radnom tjednu broj ljudi zaposlenih u timu
Ukupna produktivnost raste s brojem lanova i dostie maksimum na n=60 Ukupna produktivnost za n=20 i n=94 lana priblino je jednaka
Broj lanova tima (n) 20 40 60 80 94 100
Ukupno vrijeme produktivnosti (TPT) [sati/tjedan] 424,8 755,2 895,2 748,8 424,5 220
130
Procjena trajanja projekta

Iskustveno pravilo za raunanje optimalne procjene trajanja (procjena trajanja koja daje najmanje trokove) iz procjene rada je:
Ekonomska izvodljivost
Isplati li se graditi? Kada e se isplatiti?
Analiza trokova-koristi (cost-benefit analysis - CBA) Troak razvoja sustava (fiksni troak)
apsolutni iznos, poetna procjena, auriranje tijekom napretka projekta primjeri: osoblje: plae, honorari oprema procjenjuje se nakon odabira tehnikog rjeenja izobrazba: teajevi
trajanje u mjesecima =
3.0(ovjek-mjeseci)1/3
Ako je procijenjeno da e projekt zahtijevati 65 ovjek-mjeseci, optimalno trajanje projekta je 12 mjeseci (3.0*65^1/3). To dalje znai da je optimalna veliina tima 5-6 lanova. to se dogaa kada projekt treba dovriti bre?
Prema razliitim izvorima faktor 3.0 moe varirati od 4.0 do 2.5.
Gornja formula je razlog zato su rasponi procjene iri za procjenu rada nego za procjenu trajanja.
Vei projekti traju due, ali i imaju vee razvojne timove, pa se potrebni rad poveava neproporcionalno bre od trajanja projekta. Ovo podrazumijeva da se veliina razvojnog tima mijenja s veliinom projekta. Ako veliina tima ostaje konstantna, onda su rasponi procjene za potreban rad i trajanje projekta jednaki.
Troak primjene sustava (varijabilni troak)

relativan iznos, ovisan o uporabi primjeri: reije (struja, telefon) odravanje (ljudski rad) obnova licenci
132
Kategorije trokova i koristi

Mjerljivi (tangible opipljiv, odreen, shvatljiv)
zna se toan iznos ili iznos moe biti procijenjen
Primjeri trokova i koristi

Vrijednost novog kupca
Vrijednost 300 novih kupaca godinje koji u prosjeku potroe $500 po proizvodu koji nakon trokova donosi 12% profita godinji profit iznosi 300 * $500 * 12% = $18.000
Nemjerljivi (intangible)
Pretpostavlja se ili se zna da postoje, ali im se postojanje ili "vrijednost" ne moe egzaktno dokazati
Vrijednost postojeih kupaca

Ako izgubimo 100 kupaca od kojih svaki troi $2500 godinje, a za njihovo nadomjetanje potrebno je potroiti $50.000 za reklamu, kratkotrajni gubitak tih kupaca iznosi (pod pretpostavkom da je razina dobiti 12% ): 100 * $2500 * .12 + $50.000 = $80.000
Mjerljive koristi
Najee izraene kao godinja uteda ili uteda po proizvedenom predmetu
Nemjerljivi trokovi
pad morala, pad produktivnosti (nemjerljivi) ili gubitak trita
Smanjenje cijene rada ili uteda smanjenjem posla

Ako smanjimo rad za neki zadatak s 5 minuta na 30 sekundi, a zadatak radi osoba plaena $50 na sat uteda je (5 30/60)/60 sati po zadatku * $50 na sat = $3,75 po zadatku
Nemjerljive koristi
Neopipljive koristi mogu pomoi ili odmoi korisnosti sustava, npr. poboljano zadovoljstvo kupca, zadovoljstvo zaposlenika, ...
Nemjerljive koristi se ponekad mogu kvantificirati postavljanjem nekoliko pretpostavki o njihovom uinku:
nezadovoljni kupci naruuju manje i rjee ako se to kvantificira moemo dobiti postotak u gubitku posla
133
134
Osoblje: Vrsta Analitiar sustava Programer Strunjak za komunikacije Administrator baza podataka Pisac dokumentacije Tajnica Unos podataka Edukacija: Vrsta in-house poduke za programere in-house poduka za korisnike Materijal: Vrsta Kopiranje Diskovi, trake, papir Sklopovlje i programska podrka: Vrsta Windows licence Memorija za 20 klijenata Periferni ureaji za 20 klijenata Mreni programi Office alati Koliina Cijena 500 kn 650 kn Cijena 1,000 kn 8,000 kn 2,500 kn 15,000 kn 20,000 kn
Koliina 900h * 45kn/h 1375h * 36kn/h 60h * 40kn/h 30h * 42kn/h 240h * 25kn/h 160h * 15kn/h 80h * 12kn/h Koliina 3 dana 3 dana
Cijena 40,500 kn 49,500 kn 2,400 kn 1,260 kn 6000 kn 2,400 kn 960 kn Cijena 7,000 kn 10,000 kn
Primjer: godinji trokovi rada

Osoblje: Vrsta Programer odravanja/analitiar Mreni administrator Koliina 250h/god*42kn/h 300h/god*50kn/h Cijena 10,500 kn 15,000 kn Cijena 5,000 kn 6,000 kn 3,500 kn
Primjer: trokovi razvoja
Nadogradnja sklopovlja i programske podrke: Vrsta Koliina Sklopovlje Programska podrka Ostali trokovi
Koliina
Sadanja vrijednost trokova i koristi

Sadanja vrijednost (Present value - PV)
$ oznaava novanu jedinicu u bilo kojoj valuti
Neto sadanja vrijednost

Neto sadanja vrijednost - Net Present Value (NPV)
budui troak i korist s obzirom na gubitak vrijednosti sredstava razlika izmeu sadanje vrijednosti buduih priljeva i sadanje vrijednosti buduih odljeva NPV = ukupna korist ukupni trokovi
Dananja vrijednost onoga to e postati $1.00 nakon n godina u budunosti, ako uzmemo u obzir kamate I iznosi: PV = 1/(1 + I)n = (1 + I)-n Razlika predstavlja kamatu koja se moe zaraditi tim novcem
Primjer: Koji je projekt isplativiji ? Primjeri:

trokovi razvoja od $100.000 imaju trenutnu vrijednost od $100.000 oroenje tih sredstava uz kamatu od 8% donijelo bi 47.93% dobiti od kamata korist projekta u iznosu od $30.000 za pet godina uz kamatnu stopu od 8% ima sadanju vrijednost od samo: $30.000 / (1 + 0.08)5 = $20.417 korist projekta u iznosu od $300.000 postignuta za tri godine uz kamatnu stopu od 8% ima sadanju vrijednost od samo: $300.000 / (1 + 0.08)3 = $238.140
Kamata Projekt 1 Troak Korist Cash flow Projekt 2 Troak Korist Cash flow 10% 0 -5,000 0 -5,000 1 -1,000 2,000 1,000 2 -1,000 3,000 2,000 3 -1,000 4,000 3,000 4 -1,000 5,000 4,000 Ukupno -9,000 14,000 5,000
NPV
2,316
-2,000 1,000 -1,000
-2,000 2,000 0
-2,000 4,000 2,000
-2,000 4,000 2,000
-2,000 4,000 2,000
-10,000 15,000 5,000
3,201
138
137
Povrat investicije
Povrat investicije
Ulaganja donose korist koja s vremenom postaje sve vea. U jednom trenutku prihod dosegne rashod
Primjer: Vrijeme povrata investicije

Kamata Troak / Korist Troak razvoja Operativni trokovi Faktor za kamatu Sadanja vrijednost Kumulativni troak Korist od novog IS Faktor za kamatu Sadanja vrijednost Kumulativna korist Ukupno NPV
300,000
Indeks profitabilnosti (Cost Benefit ratio)

omjer sadanje vrijednosti i poetnog ulaganja
12.00% Godina 0 Godina 1 Godina 2 Godina 3 Godina 4 Godina 5 (418,040) (15,045) (16,000) (17,000) (18,000) (19,000) 1.00 0.893 0.797 0.712 0.636 0.567 (418,040) (13,435) (12,752) (12,104) (11,448) (10,773) (418,040) (431,475) (444,227) (456,331) (467,779) (478,552) 150,000 0.893 133,950 133,950 1 (297,525) 170,000 0.797 135,490 269,440 2 (174,787) 190,000 0.712 135,280 404,720 3 (51,611) 210,000 0.636 133,560 538,280 4 70,501 230,000 0.567 130,410 668,690 5 190,138
Vrijeme povrata investicije (payback period)

Vrijeme povrata ukupnog troka Razdoblje potrebno da prihod dosegne rashod
1.00 0 0 0 (418,040)
Toka povrata investicije (break-even point)

Trenutak u kojem prihod dosegne rashod
Vrijeme povrata
= 3 + 51611 / (70501 + 51611) = 3.42 godine
200,000 100,000
(100,000) (200,000) (300,000) (400,000) (500,000)
139
140
Primjer: Analiza povrata investicije

Kamata Troak / Korist Troak razvoja Operativni trokovi Faktor za kamatu Sadanja vrijednost Kumulativni troak Korist od novog IS Faktor za kamatu Sadanja vrijednost Kumulativna korist Ukupno NPV
400,000
Povrat investicije
Postotak povrata investicije
ROI - postotak relativne koristi projekta u odnosu na troak ROI = (ukupna korist ukupan troak) / (ukupan troak) preraunato u sadanju vrijednost, ROI = NPV / (ukupan sadanji troak) Za primjer s kamatom 12%, ROI = 190378 / 478552 = 0.3973 = 39.73% Za primjer s kamatom 6%, ROI = 301284 / 489196 = 0.6159 = 61.59%
6.00% Godina 0 Godina 1 Godina 2 Godina 3 Godina 4 Godina 5 (418,040) (15,045) (16,000) (17,000) (18,000) (19,000) 1.00 0.943 0.890 0.840 0.792 0.747 (418,040) (14,187) (14,240) (14,280) (14,256) (14,193) (418,040) (432,227) (446,467) (460,747) (475,003) (489,196) 150,000 0.943 141,450 141,450 1 (290,777) 170,000 0.890 151,300 292,750 2 (153,717) 190,000 0.840 159,600 452,350 3 (8,397) 210,000 0.792 166,320 618,670 4 143,667 230,000 0.747 171,810 790,480 5 301,284
1.00 0 0 0 (418,040)
Faktor obnavljanja kapitala

ROI se obino dijeli sa duinom projekta kako bi se dobio godinji ROI faktor obnavljanja kapitala Nizak ROI (~ manji od 10% godinje) moe pokazivati da je korist preniska da bi bila isplativa Za primjer s kamatom 12%, ROI% = 7.95% godinje Za primjer s kamatom 6%, ROI% = 12.32% godinje
Za kamatu 6%
NPV = 300k VP = 3.05 godina
300,000 200,000 100,000 0 1 2 3 4 5
(100,000) (200,000) (300,000) (400,000) (500,000)
141
142
Povrat investicije
Interna stopa rentabilnosti - Internal Rate of Return (IRR)
Interna stopa povrata investicije Izraava potrebni postotak povrata potreban da bi se troak i korist izjednaili u nekom vremenskom razdoblju Kamatna stopa pri kojoj je NPV = 0
Modeliranje postojeeg sustava tijekom planiranja

Svrha
Preciziranje dosega projekta Verifikacija razumijevanja problema i usaglaavanje percepcije sustava i stavova izmeu sudionika (korisnici, informatiari)
Globalni, okvirni, grubi modeli

Model organizacije i resursa kontekst, organizacijska struktura, prostorni raspored sredstava Globalni model procesa funkcionalna dekompozicija tok kljunih poslovnih procesa
kolanje dokumenata i protok informacija
50,000 (50,000) 0 (100,000) (150,000) (200,000) (250,000) (300,000) (350,000) (400,000) (450,000) 1 2 3 4 5
Globalni model entiteti-veze (enterprise data model) kategorije podataka klase podataka (ne razredi objekata!)
Primjeri:
\Planiranje\
MesnaIndustrija-Idejno, Ministarstvo-Idejno
Pospjeenje odrivosti projekta

"Puzei" doseg projekta (creeping scope)
Tijekom izvedbe projekta esto se dogaa polagano, ali znaajno poveanje obujma uslijed pogrene procjene, razliitog tumaenja zahtjeva izmeu korisnika i izvoaa ili promjene zahtjeva Granice projekta moraju biti definirane to je mogue preciznije Time se kasnije poveanje projekta moda nee ukloniti ali e se barem moi nadzirati
Modaliteti izgradnje sustava
Opcionalno se planira i provodi:

Izrada prototipa ili oglednog (pilot) projekta i procjena njegove uspjenosti projekt koji se moe uspjeno i brzo realizirati (npr. 3-9 mjeseci) Primjer: Projekt informatizacije zdravstva Primjer: Pilot projekt PIS visokoobrazovnih uilita Procjena odrivosti projekta SurvivalTest [McConnell, 1998], http://www.construx.com/survivalguide/ Primjer: \Planiranje\OdrzivostProjekta, SurvivalTest
Dio analize izvodljivosti ili meukorak analize i dizajna
145
Vlastiti razvoj
Vlastiti razvoj (Insourcing)
Varijante Razvoj vlastitim informatikim snagama (in-house), koji moe sadravati osposobljavanje i angairanje netehnikog osoblja
Primjeri: Ministarstvo, Drutvo, Poduzee
Vanjski razvoj
Vanjski razvoj (Outsourcing)
najam usluge razvoja informacijskog sustava ili njegovih dijelova poduka djelatnika informatike struke savjetnitvo pri provedbi pojedinih faza ciklusa izrada rjeenja po specifikaciji naruitelja Varijante: Ugovoreni razvoj isporuke gotovog proizvoda (contract out) Dugorona suradnja s isporuiteljem (stratekim partnerom) ili izdvajanje odjela informatike u preferiranog izvoaa (preferred contractor) Kljuna karakteristika: zavisnost o dobavljau
Razvoj unajmljenim osobljem povremeno ili dugorono (buy-in, preferred supplier)

Primjer: Banka
Prednosti poveanje strunosti naruitelja, samostalnost Nedostaci trajni troak kune informatike problem paralelnog razvoja i odravanja, gomilanje posla
Razvoj od strane vanjskih dobavljaa

Prednost: rjeenje po mjeri naruitelja Nedostatak: visoka cijena unikata Primjer: TuristikaAgencija
Nabava gotovog rjeenja

aplikacije za standardno poslovanje financijsko poslovanje (accounting) robno-materijalno poslovanje (material management/distribution) upravljanje ljudskim resursima i plae (HR management, payroll) proizvodnja (manufacturing) nia cijena i krae vrijeme "konfekcije" takoer zahtijeva prilagodbu (parametrizaciju) i konverziju podataka !
Argumenti za vlastiti razvoj

informatizacija osnovnog posla (core business), kada ne postoje gotova rjeenja na tritu ili takva da organizacija s pomou njih postigne komparativnu prednost u odnosu na konkurenciju kada postoje dodatni ili posebni razlozi kao to su poveana tajnost podataka i poslovnih procesa ili poveana zatita IS
Odabir rjeenja
Odreivanje moguih rjeenja
Identifikacija rjeenja na temelju analize poslovnih zahtjeva Ulazi: specifikacija raunalne opreme i programske podrke te odabrana tehnoloka arhitektura Izlazi: mogua rjeenja novog sustava i njihove karakteristike
Primjer: mogua rjeenja i njihove karakteristike

Karakteristike Operacijski sustav Baza podataka Brzina pretraivanja i dohvata podatka Programski jezik Raspoloiv izvorni kod Korisniko suelje Integrirani sustav pomoi (on-line help) Dokumentacija (papirnata) Mogunosti aplikacije Integracija s drugim aplikacijama Brzina ispisa rauna Rad s razliitim pisaima Rad u mrei Krivulja uenja Arhiviranje podataka Upotreba konfiguracije za druge poslove Min. potrebno raunalo Preporueno raunalo Broj instaliranih paketa Datum prve instalacije Cijena paketa Cijena min. potrebnog raunala (plus monitor i pisa) Cijena preporuenog raunala (plus monitor, pisa i modem) Cijena operacijskog sustava i licenci 27 9/95 1500 kn 3500 kn 8000 kn 10 7/96 100 kn 4000 kn 8000 kn 152 4/93 500 kn 2200 kn 87 10/94 2000 kn 3500 kn SuperVideo Windows Access 2 velika Visual Basic ne grafiko da dobra velike dobra srednja da da 1-2 dana / 2 tjedna da velika Video Boss Windows Paradox 8 velika C++ ne grafiko ne ne vrlo male srednja srednja da ne 1 dan / 1 mjesec ne velika Video Dos dBase III mala Cliper da tekstovno ne ne male ne velika ne ne 1dan / 2 tjedna da ne ZZ Video Linux MySQL srednja Clarion ne tekstovno ne dobra velike ne velika ne ne 1-2 dana / 1 tjedan da vrlo mala
Analiza izvodljivosti alternativnih rjeenja

Procjena alternativa s obzirom na tehniku, operativnu, ekonomsku i vremensku izvodljivost Ulazi: karakteristike moguih rjeenja, cijene hardvera i softvera, reference i uvjeti dobavljaa Izlazi: analiza izvodljivosti za svako mogue rjeenje
Prijedlog rjeenja sustava koje e se oblikovati i ugraditi

Odabir onog rjeenja koje ima najbolju ukupnu kombinaciju izvodljivosti Ulazi: analiza izvodljivosti, plan projekta, procjena veliine projekta Izlazi: prijedlog sustava
Kriteriji za odabir
Primjeri: \Planiranje\IEEE-KriterijiNabave
149
150
Vrednovanje moguih rjeenja

Svojstva treba kvantificirati da bi se mogla usporediti
Koristi se sustav bodovanja da bi se usporedio znaaj razliitih kriterija.
Primjer: analiza izvodljivosti za mogua rjeenja

Karakteristike: Operacijski sustav Baza podataka Brzina pretraivanja i dohvata podatka Programski jezik Raspoloiv izvorni kod Korisniko suelje Integrirani sustav pomoi (on-line help) Dokumentacija (papirnata) Mogunosti aplikacije Integracija s drugim aplikacijama Brzina ispisa rauna Rad s razliitim pisaima Rad u mrei Vrijeme obuke korisnika Arhiviranje podataka Upotreba konfiguracije za druge poslove Broj instaliranih paketa Datum prve instalacije Cijena paketa Cijena raunala i sistemskog softvera Ukupno bodova: 151 FER \ Fertalj: Razvoj informacijskih sustava Teinski faktor 2 1 4 1 1 2 2 2 4 3 4 3 1 1 2 3 1 1 2 3 SuperVideo Ocjena 4 4 5 4 0 5 5 4 5 4 2 5 5 3 5 5 3 3 2 3 Bodovi 8 4 20 4 0 10 10 8 20 12 8 15 5 3 10 15 3 3 4 9 171 Video Boss Ocjena 4 4 4 5 0 5 0 0 1 3 3 5 0 5 0 5 2 3 5 2 Bodovi 8 4 16 5 0 10 0 0 4 9 12 15 0 5 0 15 2 3 10 6 124 Video Ocjena 1 2 1 2 5 3 0 0 2 0 5 0 0 5 5 0 5 5 4 5 Bodovi 2 2 4 2 5 6 0 0 8 0 20 0 0 5 10 0 5 5 8 15 97 ZZ Video Ocjena 3 1 4 2 0 3 0 4 5 0 5 0 0 3 5 3 5 5 2 3 bodovi 6 1 16 2 0 6 0 8 20 0 20 0 0 3 10 9 5 5 4 9 124 152
Model ponderiranog vrednovanja (Weighted Scoring Model)

Odredi se teinski faktor za svaki kriterij (npr. 0-3). Pojedinanom kriteriju svakog od rjeenja dodjeljuje se ocjena iz dogovorenog raspona (npr. 0-5), pomnoena s odgovarajuom teinom. Dobiveni pojedinani rezultati sumiraju se za svako od rjeenja.
S i = sij w j
j =1
gdje su Si = ukupna vrijednost i-tog rjeenja sij = vrijednost j-tog kriterija za i-to rjeenje wj = vanost ili teina j-tog kriterija
to uiniti kada su sustavi (pod)jednako bodovani ?

Primjer: Uprava-IzborAlata
to uiniti ako pojedino svojstvo ima vie podsvojstava ?

http://www.zpr.fer.hr/zpr/Projekti/IPIS/
Kadrovska
Financije i blagajna
Obraun plaa
Nastava i procedure
Zavodi i projekti
Urudbeni zapisnik
Opa sluba
Skladite i materijalno
Komponente poslovno upravljakog IS-a
Primjer: \Planiranje\ PISFER-StudijaIzvodljivosti

Operativna Nadogradnja Tehnika Vremenska Ekonomska Ocjena alternative Operativna Izrada vlastitog Tehnika Vremenska Ekonomska Ocjena alternative Operativna Nabava gotovog Tehnika Vremenska
3 3 3 3 3 1 1 1 1 1 2 3 3 1 2.25 x
3 3 3 3 3 1 1 1 1 1 2 2 2 2 2 x
3 3 3 3 3 1 1 1 1 1 1 1 1 1 1 x
3 3 2 3 2.75 2 2 1 1 1.5 1 1 1 1 1 x
1 1 1 1 1 3 2 2 2 2.25 2 2 3 1 2
1 1 1 1 1 3 2 1 1 1.75 1 1 1 1 1
1 1 1 1 1 3 2 1 1 1.75 1 2 2 1 1.5
2 2 1 2 1.75 2 1 1 1 1.25 2 2 3 1 2 x
0 0 0 0 0 2 2 1 1 1.5 1 2 3 2 2
Prikupljanje informacija i utvrivanje zahtjeva

Prikupljanje informacija (information gathering) Prikupljanje podataka (data collection) Ustanovljavanje injenica (fact finding)
Ekonomska Ocjena alternative Konaan prijedlog alternative Nadogradnja Izrada vlastitog Nabava gotovog
x x
Postupak intervjuiranja
Intervju
neusiljen i elastian razgovor s ispitanikom, slijed pitanja i odgovora ispitanik se pojavljuje u ulozi pasivnog sugovornika (!?) sugovornici: rukovoditelji, krajnji korisnici, ostali sudionici standardno ukljuuje dva sugovornika ali moe i vie (korisnika, ispitivaa): individualni intervju jedan korisnik ili suradnici koji rade isti posao intervjuiranje grupe vie korisnika iz razliitih podruja
Tehnika intervjuiranja
Priprema za razgovor
utvrivanje informacija koje treba saznati prouavanje postojee dokumentacije i prethodnih nalaza odreivanje dokumentacije koju bi trebalo prikupiti priprema pitanja koja e biti postavljena tijekom razgovora izrada jezgre tema, to jest standardnih pitanja izrada sveobuhvatnog podsjetnika i izdvajanje prikladnih pitanja
Organizacija razgovora
informacije se prikupljaju nizom pojedinanih razgovora (prvi) razgovori trebali bi se voditi prema unaprijed dogovorenom planu i rasporedu koordinator Primjeri: \Analiza\PlanRazgovora postupak je spor i neuinkovit, jer se organizacija razgovora mora obaviti za svaki pojedini razgovor nakon dovretka analize i sinteze dobivenih informacija neke razgovore (ponekad i itavu seriju) treba ponoviti da bi se upotpunile dobivene informacije ili uskladili proturjeni iskazi ukupan broj razgovora ne moe se unaprijed tono odrediti i treba ga prilagoditi stvarnoj situaciji
Primjeri:
\Analiza\
Podsjetnik-teme Podsjetnik-priprema Podsjetnik-upitnik
156
Planiranje i obavljanje razgovora
okvirno trajanje prvog razgovora je 2 sata (openito 1,5 2,5 sata) Poetak razgovora predstavljanje sudionika upoznavanje sa svrhom razgovora (prikupljanje informacija o ) Voenje razgovora postavljanje pitanja i biljeenje odgovora prikupljanje dokumentacije Zavretak razgovora priblino 5-10 minuta prije isteka planiranog vremena prekida se slijed postavljanja pitanja provjerava se da li postoji neto to je sugovornik htio rei a nije bilo pitano provjerava se da li treba proiriti krug sugovornika dogovara se nastavak razgovora (dopunski razgovor) kada:
voditelj razgovora nije postavio sva planirana pitanja ili voditelj smatra da je razgovor nametnuo nova pitanja
Preispitivanje i pojanjenje sadraja (follow-up)
provjera zabiljeenih navoda radi upotpunjavanja biljeki telefonom, elektronikom potom, novim sastankom
Dokumentiranje razgovora
Pisanje zapisnika samostalno pisati zapisnike (Tko ne razumije, ne moe biljeiti.) kada u razgovoru sudjeluje vie analitiara, odreuje se voditelj razgovora koji je ujedno i zapisniar, a ostali ulau primjedbe Sadraj zapisnika
Vrijeme i mjesto odravanja razgovora Sudionici Sadraj razgovora (tekst zapisnika) Popis prikupljene dokumentacije Zapisniar
zapisnik mora sadravati ono to je reeno i slijediti tok razgovora zapisnik ne smije nametati zakljuke, jer su oni rezultat analize
Autorizacija (ovjera) zapisnika

zapisnik se alje na uvid sugovorniku, koji alje potvrdi o vjernosti zapisnika po potrebi sugovornik moe nadopuniti dijelove za koje smatra da nisu evidentirani ili pojasniti dijelove za koje misli da su krivo protumaeni
Primjeri:
\Analiza\
zahvala na razgovoru
Zapisnik-* TragRazgovora
Preporuke za voenje intervjua

Treba pitati o svemu to se smatra vanim
nita nije samo po sebi razumljivo i svima jasno ne pretpostavljati da se unaprijed zna o emu se radi
Preporuke za voenje intervjua

Analiza odgovora
razluivanje injenica od miljenja utvrivanje da li pojedine injenice odgovaraju drugima analiza injenica koje se ne poklapaju provjera odgovora razliitih sugovornika na isto pitanje
Repertoar i vrste pitanja

Pitanja zatvorenog tipa: Koliko ... obraujete (u nekom razdoblju)? Na koji nain obraujete ... ? Pitanja otvorenog tipa: to mislite o ... ? Koji su najvei problemi ... ? Probna pitanja: Zato ? Moete li navesti primjer za takvu situaciju? Molim detaljnije objanjenje za ...
Preporuljivo ponaanje
iskrenost i nepristranost cilj je nai za korisnika najprikladnije rjeenje, a ne podupirati odreeno programsko rjeenje ili raunalnu platformu panja i jezgrovitost brzo misli, jasno govori izbjegavanje sugestivnih pitanja nenametanje zakljuaka leernost (+ praenje reakcija sugovornika)
Grupno intervjuiranje
izbjegavati i po potrebi nadomjestiti radnim sjednicama iznimno provesti, kada se eli utvrditi zajedniki interes ili proturjeje
Upitnici i ankete
Upitnik (pismeni intervju)
sadri pitanja koja se postavljaju tijekom razgovora (okvirno 20) moe se dostaviti korisniku prije, umjesto ili nakon intervjua nedostaci: ispitanik moe prilagoditi (kontrolirati) svoje odgovore teko je procijeniti iskrenost (spontanost) odgovora moe obeshrabriti ispitanika Primjer: \Analiza\Upitnik
Prouavanje dokumenata
Prikuplja se sve do ega se moe doi
Analiza procesa Opis radnih procedura Tipini dokumenti: opis radnih procedura !?, pravilnici i zakoni Analiza podataka Tipini dokumenti: obrasci (formulari), izvjea Poeljno je da dokumenti budu reprezentativni, tj. popunjeni na tipian nain. Tako se moe ustanoviti koje se informacije i kako unose.
Reprezentativni dokumenti najee ne ukazuju na izuzetke, to jest podatke koji se rjee biljee ali ipak trebaju. Stalno biljeenje nekih podataka ne mora znaiti da su ti podaci stvarno potrebni. Treba prikupiti vie uzoraka iste vrste dokumenta! ( uzorkovanje)
Anketa (inventar)
moe se obuhvatiti vie ispitanika pitanja zatvorenog tipa odgovori i obrada odgovora mogu se standardizirati pogodna za popis resursa Primjer: \Analiza\Anketa-resursi
Vrijednost informacija dobivenih analizom (samo) dokumenata je niska.

Praksa moe odudarati od pravilnika i administrativnih obrazaca. Treba shvatiti zato i kada dokumenti nastaju, kako se popunjavaju, koliko su potrebni te to treba promijeniti da bi ih se popravilo (sadraj, lakoa popunjavanja i itanja) Nuno je modele (podataka) razluene analizom provjeriti kod korisnika.
Intervjuiranje je elastinije!
Pomou intervjua moe se vie saznati o stavovima, osjeajima i motivaciji osoblja. Tijekom intervjua analitiar moe promatrati nain na koji ispitanik odgovara i po potrebi proiriti ili usmjeriti pitanja.
Primjeri:
\Analiza\PrimjeriDokumenata\
162
Radne sjednice (zdrueni razvoj)

Radni sastanci, sjednice (workshop)
analitiari i korisnici zajedniki provode analizu i oblikovanje cilj sjednice je (zajedniko) pronalaenje najboljeg rjeenja poseban prostor i izolacija moderator, dnevni red i zapisnici
Slika: A.Dennis & B. Haley Wixom, Systems Analysis and Design, John Wiley & Sons, 2000
Radne sjednice
Prednosti
Sjednice su pogodne za projekte kojima se rjeavaju problemi vani za itavu organizaciju ili vei dio poslovanja. Izbjegavanje specifinih (egzotinih) i nejasnih zahtjeva Preciznije ustanovljavanje dosega projekta Bolje uoavanje proturjenih zahtjeva
Genijalnost grupe (tzv. brainstorming)

koristi se za prikupljanje ideja i definiranje inofrmacijskih potreba korisnike se potie na aktivno i kreativno sudjelovanje izvodi se tako da se svakog ispitanika iz grupe zatrai da definira po njemu idealno rjeenje svaki sudionik iznosi sve to mu pada na pamet u svezi s problemom koji se rjeava od predloenih rjeenja odabire se najbolje prema realnoj izvodljivosti postupak je uinkovit tamo gdje postoje korisnici koji dobro poznaju sustav ali teko prihvaaju nove ideje
Nedostaci
sadraj i dinamika pasivnost sudionika usitnjavanje razgovora udaljavanje od tema trajanje sjednice bi trebale trajati vie dana (5-10) u nekoliko tjedana ovom zahtjevu u praksi je vrlo teko udovoljiti zbog obveza sudionika otpor sjednici i prateoj izolaciji razmjeran je razini poloaja pojedinog sudionika izraeniji meu korisnicima koji smatraju da je to informatiki posao
Primjeri: Plastika, VisokoUilite

Promatranje poslovnog sustava

Uvid u poslovne procese promatranjem radnih sredina
promatra se lokacija i kretanje ljudi te tijek izvravanja poslova fiziki ulazi i izlazi sustava zaprimanje, izrada i razmjena dokumenata procesi osnovne djelatnosti, primjerice proizvodnja
Prednosti
analitiar je u stanju realno sagledati poslovni proces uinkovitost, ako se dobro provede pouzdanost prikupljenih informacija, za dobro planirano promatranje
Nedostaci
utroak vremena ometanje i neugoda promatranih osoba mogunost manipulacije promatraa npr. prikrivanjem uobiajenog krenja radnih procedura problem odreivanja duine i uestalosti promatranja informacije dobivene iz malog broja kratkotrajnih promatranja mogu biti nepouzdane
Promatranje na licu mjesta je najtea metoda za pronalaenja injenica. Primjer: Ministarstvo

Izbor prikladne tehnike prikupljanja zahtjeva

Tip informacije podruje primjene Dubina informacije stupanj detaljizacije, mogunost razumijevanja razloga Raspon informacije irina, raznolikost Integracija informacije mogunost povezivanja ili provjere informacija dobivenih iz razliitih izvora Sudjelovanje korisnika stupanj ukljuenosti, angairanost Troak organizacije, provedbe
Analiza postojeih aplikacija i evidencija

Procjena aplikacija i (baza) podataka u primjeni
koriteni programski jezici i pomagala, ukljuujui programe za uredsko poslovanje (npr. Excel) podrane funkcije i nain posluivanja programa meusobna povezanost razliitih aplikacija i podataka postojee platforme (raunalo, operacijski sustav, mrea, SUBP) sastav i stupanj informatike izobrazbe korisnika
Procjena nedostatka zahtjevi na unaprjeenja

Intervju Tip informacije Ankete Analiza dokumenata as-is mali veliki mali mali mali Udrueni razvoj Promatranje as-is mali mali mali mali do srednji
as-is, pooboljanja, as-is, to-be pooboljanja veliki srednji Dubina informacije mali veliki Raspon informacije mali mali Integracija informacije srednje mali Sudjelovanje korisnika srednje mali Troak
as-is, pooboljanja, to-be veliki srednji veliki veliki srednji do velik mali
nepovezanost aplikacija (tzv. informatiki otoci) zalihost i nenormaliziranost modela pojedinih aplikacija loa programska rjeenja (funkcionalnost, ergonomija) nepouzdanost integritet, zatita i sigurnost podataka nepostojanje programske dokumentacije tehnoloka zastarjelost (programski jezici i alati, nemogunost rada u viekorisnikom okruenju, grafiko suelje)
167
Razvoj prototipa
Prototipiranje (prototyping)
Koristi se kada korisnik ne moe tono definirati svoje informacijske potrebe prije nego to se izgradi informacijski sustav. Razlog tomu moe biti nedostatak postojeeg modela na kojem bi korisnik zasnivao svoje potrebe ili tea vizualizacija budueg sustava.
Izrada prototipa
Izgrauje se sustav koji zadovoljava neke osnovne, inicijalne potrebe. U radu s takvim sustavom korisnik otkriva svoje informacijske potrebe te se sustav modificira kako bi se zadovoljile te potrebe. Postupak koritenje sustava i modificiranja istog iterativno se ponavlja, a informacijske potrebe korisnika otkrivaju koritenjem sustava.
Analiza sustava
Izrada prototipa pogodna je u onim okruenjima gdje je teko definirati konkretni model sustava te u okruenjima gdje se informacijske potrebe korisnika mijenjaju ili razvijaju.
Analiza sustava
Analiza sustava, sustavska analiza
Analiza sustava je (1) razmatranje i planiranje sustava i projekta, (2) prouavanje i analiza postojeeg poslovnog i informacijskog sustava te (3) definiranje poslovnih zahtjeva i prioriteta novog ili poboljanog postojeeg sustava. [Whitten et. al, 2000]
Analiza sustava (2)

Pozadinska analiza
Vano je shvatiti strukturu organizacije, tko u njoj radi, tko je kome podinjen, kako surauju razliiti odjeli, itd.
Aktivnosti analize
detaljna analiza postojeeg sustava te utvrivanje potreba i zahtjeva Kako radi postojei sustav? Na koji nain ljudi koriste sustav da bi obavili svoj posao? Koji su problemi pri koritenju aplikacija ili uslijed nedostatka aplikacija? detaljna specifikacija zahtjeva na IS Koji su podaci potrebni? Tko ih treba? Kada? Od koga? Tko ih stvara? Koji su izlazni podaci? Kakav im je oblik? Koji su izvori podataka? Na koji nain se podaci prikupljaju i objedinjuju? daljnja razrada granica projekta
Modeliranje sustava
Za potrebe pozadinske analize moe se izraditi shema organizacijske strukture iz koje e biti vidljivo koja osoba ili grupa ljudi obavlja koji dio posla ( Modeliranje funkcija). Za ostale elemente takoer se rade odgovarajui modeli ( Modeliranje procesa, modeliranje podataka)
Svrha, cilj i dubina analize

automatizacija, poboljanje i preoblikovanje poslovnih procesa
Primjeri:
\Analiza\ ProtokDokumenata, RazmjenaPodataka

Automatizacija poslovnih procesa

Automatizacija poslovnih procesa - Business Process Automation (BPA)
Poveanje uinkovitosti korisnika primjenom raunalne tehnologije
Primjer: automatizacija poslovnog procesa

Primjer: Izrada putnih naloga
izrauje se 2700 putnih naloga godinje nalog za putovanje odobravaju redom voditelj projekta, predstojnik zavoda te dekan ili osoba koja ga zamjenjuje nalozi se urudbiraju (2 djelatnice) i knjie te isplauje predujam za putovanje (1 djelatnica) po povratku s putovanja putnik popunjava zapisnik o putovanju, a nalog se obraunava (1 djelatnica) te se na blagajni (1 djelatnica) isplauje razlika po trokovima ili povrat nerealiziranog ostatka predujma u pojedinim razdobljima broj putovanja znaajno je povean nastaje gomilanje zaprimljenih naloga u pisarnici este su guve na blagajni
Tehnike
Analiza problema (problem analysis) Otkrivanje problema postojeeg sustava i predlaganje rjeenja budueg sustava uz pomo korisnika Poboljanja su mala i inkrementalna (npr. otkrivanje da je potreban izvjetaj koji ne postoji), ali poboljavaju uinkovitost i lakou koritenja sustava Poboljanja poslovne vrijednosti (business value) su mala Analiza uzroka (root cause analysis) Usmjerenost na probleme (simptome), a ne na rjeenja Problemima se dodjeljuju prioriteti te trae svi mogui uzroci Uzroci se analiziraju sve dok se ne utvrdi pravi uzrok Najbolje je analizirati one uzroke koji se pojavljuju kod vie problema
Rjeenja:
kreiranje i auriranje naloga na mjestu nastanka (podnositelj) automatizacija postupka odobravanja isplata predujmova putem tekueg rauna
Poboljanje poslovnih procesa

Poboljanje poslovnih procesa - Business Process Improvement (BPI)
Manje promjene poslovnih procesa radi boljeg iskoritenja tehnologije i poveanja uinkovitosti i djelotvornosti
Primjer: paralelizacija poslovnog procesa

Primjer: poboljanje obrade putnih naloga
izvjee s putovanja temeljem predloka putnog naloga s funkcijom za urudbiranje urudbiranje se obavlja web servisom koji uz atribute pohranjuje i dokument (BLOB) potpisani primjerak dostavlja se u pisarnicu na skeniranje nalog se moe paralelno knjiiti jer je u meuvremenu urudbiran
Tehnike
Analiza trajanja (duration analysis) Analiza vremena po svim koracima procesa postojeeg sustava Procese koje obavlja vie ljudi istovremeno treba integrirati i paralelizirati
Integracija procesa je mijenjanje glavnog procesa tako da manje ljudi radi na ulazima potrebnim za proces Paralelizacija procesa je mijenjanje procesa tako da se pojedinani koraci procesa izvode istovremeno
Kotanje poslovnih procesa (activity-based costing) Analiza trokova po svim koracima procesa Odreivanje direktnog troka rada i resursa za svaki ulaz Badarenje i usporedba (Informal benchmarking) Prouavanje poslovanja drugih organizacija Predstavljanje novih ideja koje mogu imati dodatnu vrijednost Uobiajeno za procese kod kojih se obavlja interakcija s korisnicima
Primjer: integracija poslovnog procesa

Primjer: obraun nastave na poslijediplomskom studiju
Stanje: (velik broj sitnih transakcija ugovaranja i isplata, uz prijepis) po obavljenoj nastavi Studentska sluba dostavlja evidenciju o angamanu na predavanjima izvoai zasebno potpisuju autorski ugovor u Pravnoj slubi nezavisno se za voenje (mentorstvo) i sudjelovanja u povjerenstvima za obranu disertacija sastavlja pojedinani ugovor sve isplate temeljem ugovora provodi Raunovodstvo Poboljanje: jednom godinje (za nastupajuu ak. godinu) izrauje se autorski ugovor s definiranim opim uvjetima, na kojem su kao izvoditelji ukljueni svi predvidivi nastavnici i vanjski predavai jedan primjerak potpisanog ugovora dostavlja se u Studentsku slubu tijekom godine naknadno angairani izvoai potpisuju dodatak ugovoru Studentska sluba po obavljenom poslu evidentira obavljeno te generira nalog za isplatu izvoditeljima s pozivom na broj autorskog ugovora
177
Preustroj poslovnih procesa

Preustroj poslovnih procesa
Reinenjerstvo poslovnih procesa - Business Process Reengineering (BPR) Preoblikovanje poslovnih procesa - Business Process Redesign (BPR) radikalni redizajn poslovnih procesa, analizom moguih posljedica, procjenom alternativnih tehnologija, ukidanjem ili zamjenom pojedinih aktivnosti, analizom trokova-koristi i analizom rizika
Tehnike
Analiza posljedica (outcome analysis) Razumijevanje osnovnih rezultata koji osiguravaju vrijednost za korisnika, procjena to bi se moglo ponuditi krajnjim korisnicima Analiza tehnologije (technology analysis) Analitiari i voditelji razvijaju listu vanih i zanimljivih tehnologija te donose odluke o koristi i primjeni u poslovnim procesima Uklanjanje aktivnosti (activity elimination) Analitiari i voditelji donose odluke za svaku aktivnost unutar poslovnog procesa o mogunosti njenog uklanjanja i posljedicama
178
Primjer: heuristiki preustroj procesa

Kree se od postojeeg stanja poslovnog procesa
npr. potproces unutar poslovnog procesa nabave Poslovni proces sastoji se od otvaranja ponuda pristiglih od ponuaa, tehnike evaluacije tih ponuda (u sluaju da je potrebna), slanja dodatnih pitanja ponuaima (ukoliko postoje), definiranja miljenja tehnike komisije o ponudama, potvrivanja tog dokumenta i na koncu odabira dobavljaa. U procesu sudjeluju samo dva resursa, predsjednik povjerenstva nabave (15 ljudi) i tehnika komisija (400 ljudi).
Primjer: heuristiki preustroj procesa (2)

simulira se izvoenje postojeeg procesa, vri se preoblikovanje npr. pretpostavit e se da nije potrebno traiti dodatna pojanjenja od ponuaa, jer su zahtjevi dobro definirani u kontaktu s naruiteljem tijekom izrade ponude te se simulira izvoenje preoblikovanog poslovnog procesa.
Stanje poslovnog procesa Prije preoblikovanja

Ukupno prosjeno vrijeme trajanja procesa 213.849,88 min 198.256,66 min
Ukupan prosjeni broj resursa bez posla 45,980225 46,1718

180
Nakon preoblikovanja
Izbor prikladne tehnike analize

Poslovna vrijednost Troak projekta Doseg analize Rizik BPA mala do umjerena mali ogranien mali do umjeren BPI umjerena mali do umjeren ogranien do umjeren mali do umjeren BPR velika veliki vrlo irok vrlo veliki
Preporuke za analizu
Tehnike i pomagala ne znae puno bez ispravnog pristupa.
Postupak analize mora biti prilagoen korisniku. Kljuno je razumjeti sutinu organizacije i nain poslovanja Primjer: \Analiza\ PreporukeZaAnalizu
Slika: Awad, 1985; preveo Anonymous (WWW)
Potencijalna poslovna vrijednosti (potential business value)

BPA ne mijenja poslovne procese, poboljava uinkovitost BPI poboljava i uinkovitost i djelotvornost BPR daje velike koristi jer radikalno poboljava prirodu poslovanja
Troak projekta (project cost)

BPA zahtjeva najnii troak jer ima ogranien doseg BPI ovisi o dosegu projekta BPR je obino skup zbog koliine utroenog vremena i zbog koliine preoblikovanja procesa
Ono to korisnik eli esto nije i ono to korisnik stvarno treba!

Da se pria o klasinom razvoju ne bi ponavljala, rade se modeli sustava (postojei fiziki i logiki, budui logiki).
Paraliza analize
Postupak ponavljanog modeliranja postojeeg sustava i vrednovanja modela moe utroiti znaajno vrijeme na modeliranje neega to e vjerojatno biti izmijenjeno ili zamijenjeno. Ne pretjerivati s modeliranjem postojeeg sustava!
Doseg analize (breadth of analysis)

BPA obino radi s jednim procesom BPI ima ogranien doseg i radi s nekoliko procesa BPR ima vrlo irok doseg i radi s glavnim poslovnim procesima
Rizik pogreke (risk of failure)

BPA ima mali do umjeren rizik jer je budui sustav jasan BPI ima mali do umjeren rizik jer je budui sustav jasan BPR je manje predvidiv i podloan riziku te se provodi uz odobrenje
182
Definiranje zahtjeva
IEEE standard definira zahtjeve kao [IEEE Std 610.12-1990]
(1) Uvjet ili sposobnost koje korisnik treba da bi rijeio problem ili ostvario cilj. (2) Uvjet ili sposobnost koji mora posjedovati sustav ili komponenta sustava da bi zadovoljila ugovor, standard, specifikacije ili neki drugi ugovoreni dokument. (3) Dokumentiranu reprezentaciju uvjeta ili mogunosti definiranih pod (1) ili (2).
Inenjerstvo zahtjeva
Zahtjevi ne sadre detalje dizajna, detalje implementacije ili informacije vezane uz planiranje projekta.
Panja se usmjerava na ono TO se eli izgraditi, a ne ulazi se u detalje kako i kada to napraviti.
Za 40-60% pogreaka u projektu uzrok lei u pogrekama napravljenim u fazi postavljanja zahtjeva. [Leffingwell, 1997]
Tipina posljedica su "neispunjena oekivanja" (expectation gap): razlika izmeu onog to oekuje naruitelj i onoga to je izvoditelj mislio da treba napraviti.
Naknadne prepravke mogu predstavljati do 40% trokova razvoja, od ega je 70-85% pripisivo pogrenim zahtjevima [Leffingwell, 1997].
Nepotpuno definirani onemoguuju planiranje projekta i praenje promjena.
184
Vrste zahtjeva
Poslovni zahtjevi (zato)
ciljevi organizacije ili korisniki zahtjevi na vioj razini, opis problema koje treba rijeiti primjer: poslovna potreba, "Poboljanje usluge postojeim klijentima i pridobivanje novih" sadrani u dokumentima u kojima se opisuje vizija i doseg projekta primjer: poslovni zahtjev, "Omoguiti Internet prodaju"
Kontekst postavljanja zahtjeva

Poslovni zahtjevi
Dokument vizije i dosega
Korisniki zahtjevi (zahtjevi krajnjih korisnika)

opisuju zadatke koje korisnik mora moi obaviti sluei se aplikacijama sadrani u opisima sluajeva koritenja, tj. opisima scenarija rada
Korisniki zahtjevi Atributi kvalitete
Funkcionalni zahtjevi (to)

definiraju softversku funkcionalnost (oekivano ponaanje i operacije koje sustav moe izvoditi) koju treba ugraditi u proizvod da bi omoguio korisnicima obavljanje njihovih zadataka posebno zanimljiva mogunost programa (feature) skup logiki povezanih funkcionalnih zahtjeva koje korisniku omoguuju ispunjavanje poslovnih zahtjeva
Dokument sa sluajevima primjene Ostali nefunkcionalni zahtjevi
Nefunkcionalni zahtjevi (kako ili kako dobro)

standardi, pravila i ugovori kojih se proizvod mora pridravati, opisi vanjskih suelja, zahtjevi na performance, ogranienja na dizajn i implementaciju, te svojstva kvalitete (preciziraju opis proizvoda navodei karakteristike proizvoda u razliitim dimenzija koja su vane ili korisniku, ili graditelju)
Sistemski zahtjevi Funkcionalni zahtjevi Ogranienja
Prioriteti pojedinih elemenata

SRS - Specifikacija softverskih zahtjeva
186
Primjeri poslovnih zahtjeva

Oekivana novana uteda
Sustav mora biti tako koncipiran da prava na subvencioniranu prehranu moe koristiti samo student koji ih je stekao i da ih moe koristiti samo u svrhu prehrane.
Primjeri zahtjeva krajnjih korisnika

Prehrana kod bilo kojeg pruatelja usluga
Novi sustav mora omoguiti da student ostvaruje svoje pravo kod bilo kojeg pruatelja usluge subvencionirane prehrane. Dosadanja praksa je bila da svaki pruatelj usluga izdaje svoje bonove koji se mogu koristiti samo u odreenim restoranima.
Sustav mora onemoguiti:

koritenje subvencije od strane osoba koje nemaju na to pravo zaradu ilegalnih posrednika koritenje subvencije za druge svrhe osim prehrane naplatu usluga koje nisu pruene
Ukinuti plaanje unaprijed

Treba izbjei bilo kakvo plaanje od strane studenata za potrebe ostvarivanja prava, a posebice unaprijed.
Ukloniti nepotrebne postupke za ostvarivanje prava

Sustav mora biti tako koncipiran da kad se studentu jednom zavedu prava na matinoj ustanovi nisu potrebna nikakva daljnja dokazivanja za ostvarivanje prava kod pruatelja usluga.
U idealnom sluaju zahtjevi naruitelja podudaraju se s poslovnim ciljevima!
Smanjiti rizik gubitka ostvarenih prava

Sustav mora onemoguiti zloporabu steenih prava.
Lake ostvarivanje ostalih prava iz studentskog standarda

Npr. javni prijevoz po povlatenoj cijeni, kazalita, kina, smjetaj u studentskim domovima, student-servis, itd.
Primjer: sistemski zahtjevi

Primjer: PISFER-Podprojekt
Sustav bi trebao biti integriran, tako da se sve informacije unose na mjestu nastanka Mogunost da sve organizacijske jedinice imaju pravo pregleda, auriranja i unosa podataka uz odreene dozvole Omoguiti kontinuirani pristup podacima (ne samo krajem mjeseca) Svi podaci bi trebali biti u digitalnom obliku Jednostavno i intuitivno koritenje sustava Koritenje jedinstvene baze podataka za sve slube
Primjer: funkcionalni zahtjevi

Primjer: storno dokumenta
Radi se storno ulaznih dokumenata, unosom odgovarajueg dokumenta. Dokument storna nasljeuje konto dokumenta koji bude storniran. Stavka storna moe se obrisati Storno storna nije mogu storno nuno ne ponitava cijeli iznos primarnog dokumenta, nego ga korigira za iznos storna, iznos je pozitivan ili negativan, to po volji korisnika moe biti i cijeli iznos primarnog dokumenta s negativnim predznakom Ne obavlja se storno uplate. Uz storno omoguiti i ispravak dokumenta (koji ne utjee na proknjiene stavke). Ako je dokument uplata iznos uplate uvijek mora odgovarati sumi vezanih iznosa po raunima pa i nakon ispravka, s tim da je u fazi ispravka mogue izmijeniti specifikaciju rauna i pripadajuih iznosa.
Primjer: izvjee otvorenih stavaka (zahtjev referencira primjere izvjea)

IOSi za tekuu poslovnu godinu (IOSI.doc) Sumarni IOSi (SumarniIOSI.doc) Kartica dobavljaa (KarticaTekuca.doc) Kartica dobavljaa s ukljuenom arhivom i kontinuiranim nastavkom u tekuu poslovnu godinu (KarticaArhiva.doc)
Primjer: nefunkcionalni zahtjevi

Vievalutni rad
Devizni izvod poslovne banke sadri iznose po teaju poslovne banke. Za devizne uplate evidentirat e se uz kunski iznos i devizni iznos te valuta. Sva izvjea osim Kartica moraju sadravati mogunost konverzije primarne valute u zadanu valutu po srednjem teaju NBH na datum knjienja.
Zahtjevi na kvalitetu programske podrke

Jedna podjela moe biti kao to je prikazano tablicom:
Odabire se podskup kvalitativnih svojstva vanih za konkretni projekt.
Pojedini nefunkcionalni zahtjevi su meusobno proturjeni.

Proturjenost se razrjeava postavljanjem prioriteta
Praenje promjena nad podacima

svaki zapis sadri identifikator korisnika i datum unosa/promjene
Izvoz podataka
Omoguiti izvoz izvjea u Excel formatu
Svojstva vanija korisnicima Dostupnost Uinkovitost Prilagodljivost Integritet Interoperabilnost Pouzdanost Robustnost Upotrebljivost
Svojstva vanija razvojnicima Lakoa odravanja Prenosivost Ponovna upotrebljivost Podlonost testiranju
192
Zahtjevi na kvalitetu programske podrke

Dostupnost
Dostupnost predstavlja postotak predvienog aktivnog vremena sustava tijekom kojeg bi sustav trebao biti u potpunosti funkcionalan. Formalno, dostupnost je omjer MTTF / (MTTF+MTTR), to jest srednjeg vremena do kvara i sume srednjeg vremena do kvara i srednjeg vremena do oporavka od kvara Primjer: "Sustav e biti barem 99.5% dostupan radnim danima od 6 do 24 i barem 99.95 posto dostupan izmeu 16 i 18 sati."
Zahtjevi na kvalitetu programske podrke (2)

Integritet
Integritet (ili sigurnost) sprjeava neovlateni pristup funkcijama sustava, sprjeava gubitak informacija, titi sustav od virusa i titi tajnost podatka unesenih u sustav. Integritet je vrlo bitno svojstvo za mrene aplikacije. Primjer: "Pristup transakcijama isplate imaju samo korisnici grupe A."
Interoperabilnost
Interoperabilnost definira koliko lako sustav moe razmjenjivati podatke ili usluge s drugim sustavima. Procjenjuje se koje druge aplikacije se namjerava koristiti i koji podaci e se razmjenjivati. Npr. "Sustav e moi uitati podatke o transakcijama iz MS Access baze podataka."
Uinkovitost
Uinkovitost je mjera koja govori koliko dobro sustav iskoritava kapacitet procesora, diskovni prostor, memoriju ili komunikacijske strukture. Primjer: "10% procesorskog kapaciteta i 15% memorije sustava e biti raspoloivo za vrijeme maksimalnog optereenja sustava." Potrebno je razmotriti minimalne hardverske konfiguracije.
Pouzdanost
Pouzdanost je vjerojatnost da e se softver u nekom razdoblju raditi bez pogreke. Mjeri se postotkom ispravno izvedenih operacija, trajanjem rada bez pogreaka ili uestalou pogreaka. Treba uspostaviti kvantitativne zahtjeve za pouzdanou s obzirom na veliinu tete u slulaju pogreke i procijeniti da li se isplati maksimizirati pouzdanost. Ukoliko proizvod zadovolji zahtjeve za pouzdanou moe se smatrati isporuivim (s obzirom na pouzdanost) ak i ako je poznato da jo uvijek postoje defekti. Primjer: "Najvie 5 od 1000 kemijskih eksperimenata smije propasti zbog programske podrke."
Prilagodljivost
Prilagodljivost govori koliko je napora potrebno da bi se proizvodu dodale nove mogunosti. Svojstvo je presudno za proizvode koji se rade inkrementalno ili iterativno.

Robustnost
Robustnost je stupanj do kojeg sustav nastavlja ispravno funkcionirati u sluaju pojave pogrenih podataka, defekata u softverskim ili hardverskim komponentama ili nepredvienim operativnim uvjetima. Primjer: "Kod uitavanja podatka iz neispravne ulazne datoteke sustav e, kad naie na redak s pogrekom, prijaviti pogreku i broj retka te pitati korisnika da li da nastavi uitavati datoteku od sljedeeg retka ili otkae uitavanje."

Prenosivost
Napor potreban da bi se dio softvera prenio iz jedne operacijske okoline u drugu jest mjera prenosivosti. Dizajnerski principi koji ine softver prenosivim su slini onima koji ga ine ponovno iskoristivim. Procjenjuju se dijelovi koji moraju biti prenosivi te okoline na koje softver treba moi prenijeti.
Upotrebljivost
Upotrebljivost mjeri napor koji treba uloiti da bi se podaci pripremili za unos, obradili i protumaili, to jest lakou koritenja proizvoda (eng. user friendliness).. Procjenjuju se krivulja uenja te mogunost uporabe od strane poetnika odnosno iskusnih korisnika. Sukladnost standardima ili uzoru: "Sve kratice na u izborniku File e biti iste kao i u File izborniku programa XXXX.")
Ponovna upotrebljivost
Ovo svojstvo govori do koje mjere se softverska komponenta moe upotrebljavati u drugim aplikacijama. Razvoj ponovno iskoristive softverske komponente znatno je skuplje od razvoja jednokratno koritene komponente. Ponovno iskoristiv softver mora biti modularan, dobro dokumentiran, neovisan o specifinoj aplikaciji i operativne okoline i donekle openit.
Lakoa odravanja
To je mjera koliko lako je popraviti pogreku ili napraviti izmjenu u softveru. Ovisi o tome koliko lako je razumjeti softver, promijeniti ga i ponovno testirati. Lakoa odravanja se moe mjeriti prosjenim vremenom potrebnim da se rijei problem i postotkom popravaka koji su ispravno obavljeni. Primjer: "Izvjea e biti izmijenjeno u roku od tjedan dana od zaprimanja novih obrazaca za izvjea."
Podlonost testiranju
Podlonost testiranju govori o tome koliko lako je testirati softversku komponentu kako bi se pronala pogreka. Oekuje se kod proizvoda sa sloenim logikom obrade te kod proizvoda sa sloenim poveznicama izmeu funkcija. Ovo svojstvo je takoer bitno kod proizvoda koji e se esto mijenjati, da bi se olakalo regresijsko testiranje.
Podlonost testiranju
Lakoa odravanja
Interoperabilnost
Meu zavisnost
Prilagodljivost Uinkovitost Dostupnost Integritet
Karakteristike dobrih izjava o zahtjevima [IEEE]

Upotrebljivost
Ponovna isupotrebljivost
Prenosivost
Pouzdanost
Robustnost
Potpunost
Svaki zahtjev mora potpuno opisivati funkcionalnost i sadravati sve informacije potrebne izvoau pri dizajnu i ugradnji funkcionalnosti.
Tonost
Svaki zahtjev mora tono opisivati funkcionalnost koju treba ugraditi. Referenca za tonost je izvor zahtjeva, npr. korisnik ili specifikacija sistemskih zahtjeva. U sluaju da softverski zahtjev nije u skladu sa sistemskim zahtjevom, smatra se netonim. Samo predstavnici korisnika mogu odluiti je li neki korisniki zahtjev ispravno zapisan.
Dostupnost Uinkovitost Prilagodljivost Integritet Interoperabilnost Lakoa odravanja Prenosivost Pouzdanost Ponovna isupotrebljivost Robustnost Podlonost testiranju Upotrebljivost
+ + + + + + + + + + + + + + + + + + + + + + + + + -
+ + + + + + + + + + 197
Ostvarivost (izvodljivost)
Zahtjevi moraju biti izvodljivi s obzirom na sredstva i tehnologiju te ogranienja i okolinu sustava. U prikupljanju zahtjeva trebaju sudjelovati razvojnici, radi procjene to se i kako moe napraviti .
Nunost
Pojedini zahtjev treba sadravati ono to korisnik stvarno treba ili ono to je potrebno radi povezivanja s drugim sustavima ili radi standarda.
Redoslijed po prioritetu
Svakom zahtjevu treba pridijeliti prioritet Kada bi svi zahtjevi bili jednako vani ne bi se moglo mijenjati i replanirati
Nedvosmislenost
Svi se zahtjevi moraju moi na jedinstven nain i konzistentno interpretirati.
Mogunost provjere
Svaki zahtjev treba moi provjeriti zahtjevi koje nije mogue testirati nisu dobro postavljeni.
198
Primjer nepotpunog zahtjeva

"Proizvod e dostaviti statusnu poruku u redovitim intervalima ne manjim od 60 sekundi."
to je statusna poruka i pod kojim uvjetima e biti dostavljena? Koliko dugo ostaje vidljiva? Koji dio proizvoda e dostaviti poruku? Koliko dosljedni intervali moraju biti?
Primjer neostvarivog zahtjeva

"Program e se trenutno prebaciti izmeu ispisivanja i skrivanja znakova koji se ne mogu tiskati."
Raunala nita ne mogu napraviti trenutno te je ovaj zahtjev neostvariv. Da li programska podrka sama odluuje kad e se prebaciti iz jednog stanja u drugo ili je to inicirano akcijom korisnika? Na koji dio teksta e se primijeniti promjena prikaza: da li samo oznaeni tekst, cijeli dokument ili neto tree? Nejednoznanost: da li su "znakovi koji se ne mogu tiskati" skriveni znakovi, posebne oznake ili kontrolni znakovi?
Zahtjev, preciznije i detaljnije

Modul za nadzor e ispisivati statusnu poruku u za to odreeni dio suelja. Poruka e se aurirati svakih 60 sekundi (plus minus 10 sekundi) nakon to zapone izvoenje pozadinskog zadatka i bit e vidljiva cijelo vrijeme. Ukoliko se pozadinski zadatak izvodi normalno, modul za nadzor e ispisivati postotak obavljenog posla. Modul za nadzor e ispisati "Zadatak obavljen." nakon to se zadatak obavi. Modul e ispisati poruku o pogreci ukoliko doe do zastoja u izvoenju.
Bolji zahtjev:
"Korisnik e posebno dogovorenom akcijom, odabrati da li e se HTML oznake u trenutno otvorenom dokumentu prikazivati ili ne." Sad je jasno da je rije o HTML oznakama te da korisnik mora obaviti nekakvu akciju, ali nije tono navedeno kakvu (npr. kombinacija tipki), to se preputa dizajnerima.
Problem je rastavljen u vie zahtjeva jer e svaki zahtijevati posebno testiranje.

Ukoliko je vie zahtjeva grupirano u jedan lake je previdjeti neki od njih tijekom izrade ili testiranja.
Primijetiti da u zahtjevu nije detaljno opisano kako e se poruka i gdje ispisivati. To e biti odlueno tijekom dizajna.
Primjer neodreenog zahtjeva

"Parser e brzo generirati izvjee o pogrekama HTML oznaka, koje omoguava brzi ispravak pogreaka kada program koriste poetnici u HTML-u."
Rije "brzo" je neodreena. Nije definirano to tvori izvjee i to ini zahtjev nekompletnim. Kako se ovjerava zahtjev? Pronai nekoga tko se smatra poetnikom u HTML-u i zatim vidjeti kako brzo e, uz pomo izvjea, ispraviti pogreke? Kada se generira izvjee?
Inenjerstvo zahtjeva dijeli se na: razvoj zahtjeva i upravljanje zahtjevima. Razvoj zahtjeva dalje se dijeli na odreivanje (iznalaenje) zahtjeva (elicitation), analizu, specificiranje i verifikaciju. Ove poddiscipline obuhvaaju sve aktivnosti vezane za prikupljanje, vrednovanje i dokumentiranje zahtjeva.
Bolje:
Nakon to je HTML analizator obradio datoteku generirat e izvjee koje sadri broj retka i tekst HTML pogreaka, te opis pojedine pogreke. Ukoliko nema pogreaka prilikom analize, nee se generirati izvjee.
Razvoj zahtjeva Upravljanje zahtjevima
Odreivanje
Analiza
Specificiranje
Verifikacija
202
Razvoj zahtjeva i upravljanje zahtjevima

Razvoj zahtjeva
Identificiranje razreda korisnika i njihovih predstavnika ("najbolji", kljuni korisnik). Iznoenje potreba korisnika. Razumijevanje poslovnih potreba, zadataka i ciljeva. Analiza prikupljenih informacija, kategorizacija, odbacivanje nebitnih informacija. Razdioba zahtjeva s razine sustava na podsustave i odreivanje udjela tih zahtjeva u komponentama. Razumijevanje relativne vanosti (teine) svojstava kvalitete. Odreivanje prioriteta ugradnje. Dokumentiranje i modeliranje zahtjeva Provjera specifikacije zahtjeva
Razvoj zahtjeva naspram upravljanja zahtjevima
Upravljanje zahtjevima
Rokovi prihvaanja zahtjeva Pregled promjena zahtjeva i procjena njihovog utjecaja, prije nego to se donese odluka o prihvaanju ili odbijanju promjene Kontrolirana ugradnja prihvaenih promjena zahtjeva. Auriranje plana projekta sukladno promjeni zahtjeva Pregovori o rokovima isporuke ovisno o utjecaju promjena Praenje i povezivanje pojedinih zahtjeva s odgovarajuim izvornim kodom i primjerima za testiranje. Praenje statusa aktivnosti i promjena zahtjeva tijekom projekta
203
204
Zakljuivanje zahtjeva
Prikupljanje zahtjeva zavrava postizanjem (i potpisivanjem) sporazuma o zahtjevima. Vano je da obje strane znaju to potpisuju.
U ranoj fazi projekta nije mogue odmah i detaljno znati sve zahtjeve. Nedvojbeno je da e se neki zahtjevi tokom vremena promijeniti.
Tehnike inenjerstva zahtjeva
Razvojna ekipa ne bi smjela imati stav da se potpisani dokument zahtjeva ne moe kasnije mijenjati !!!
Specifikacija zahtjeva sadri osnovicu zahtjeva, a kasniji zahtjevi ili promjene ulaze u proces upravljanja promjenama.
Primjer:
\Analiza\DOO-Specifikacija
dvije iteracije teksta, prototip, nekoliko promjena pred isporuku
205
Odreivanje zahtjeva
Poslovni zahtjevi
Sve to opisuje financijski, trgovaki ili drugi poslovni probitak koji korisnici, ili organizacija koja razvija sustav, mogu dobiti je najvjerojatnije poslovni zahtjev.
Odreivanje zahtjeva (2)

Zahtjevi vanjskih suelja
Ovaj razred zahtjeva opisuje veze izmeu sustava i vanjskog svijeta. Specifikacija sistemskih zahtjeva trebala bi ukljuivati odlomke za ove zahtjeve ukljuujui mehanizme komunikacije za korisnike, hardver i druge softverske sustave.
Sluajevi koritenja ili scenariji

Openite izjave o poslovnim zadacima koje korisnici moraju obavljati najvjerojatnije su sluajevi koritenja, dok specifini opisi zadataka predstavljaju korisnike scenarije. Specifine zadatke treba generalizirati u openite sluajeve koritenja.
Ogranienja
Ogranienja su uvjeti koji ograniavanju izbor rjeenja raspoloivih projektantu ili programeru. Spadaju u nefunkcionalne zahtjeve. Neka ogranienja mogu pomoi u zadovoljavaju atributa kvalitete. Primjer je poboljanje prenosivosti koritenjem samo standardnih naredbi programskog jezika.
Poslovna pravila
Kada korisnik izjavi da neku aktivnost mogu obavljati samo pojedine osobe ili uloge, pod odreenim uvjetima, on moda opisuje poslovno pravilo. Poslovna pravila su operativni principi poslovnih procesa. Oni nisu funkcionalni zahtjevi.
Funkcionalni zahtjevi
Izjava koja poinje s Korisnik mora moi obaviti neku funkciju, ili Sustav treba moi demonstrirati odreeno ponaanje je najvjerojatnije funkcionalni zahtjev. Funkcionalni zahtjevi opisuju vidljivo ponaanje sustava i definiraju to e sustav raditi. Treba biti svima jasno zato sustav mora biti u stanju obavljati odreene funkcije. Predloeni funkcionalni zahtjevi ponekad predstavljaju zastarjele ili neuinkovite poslovne procese.
Definicije podataka
Definicija podataka je bilo koji opis formata, dozvoljenih vrijednosti, pretpostavljenih vrijednosti ili kompozicija sloenih podatkovnih struktura. Sve definicije bi trebalo pohraniti u rjenik podataka.
Ideje o rjeenju
Ako korisnik opisuje specifian nain interakcije sa sustavom kojom bi mogao obaviti neku akciju, npr. Korisnik odabire podatak koji on 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 bi sustav trebao raditi.
Atributi kvalitete
Izjave koje opisuju kako dobro sustav obavlja funkciju su atributi kvalitete, tj. jedna vrsta nefunkcionalnih zahtjeva. Zahtjeve koji opisuju poeljne karakteristike sustava: brzinu, jednostavnost, intuitivnost, robusnost, pouzdanost, sigurnost i efikasnost treba razmotriti s korisnicima da bi se precizno utvrdilo to oni misle pod tim dvosmislenim i subjektivnim terminima.
Najei problemi pri odreivanju zahtjeva

Ponaanja korisnika
Taktika kuhinjskog sudopera korisnik navodi (preko)brojne potrebe: hrpu nepotrebnih izvjetaja, formi, sortiranja, izrauna i sl. ovakav pristup obino je uzrokovan pomanjkanjem iskustva korisnika koji ne zna to bi mu stvarno trebalo zatrebati ili nije u stanju razluiti ono to je bitno Taktika dimne zavjese korisnik trai vie mogunosti a zapravo mu je potrebna samo jedna ili dvije dodatni zahtjevi slue za postizanje bolje nagodbe s analitiarom taktika obino oslikava korisnika s dobrim poznavanjem onoga to eli, a zahtjeve treba reducirati na one realne i izvodljive Taktika "Treba mi isto ali u boljem obliku" korisnik koji koristi ovu taktiku nedostaje volja ili znanje, a ponekad oboje anse za uspjeno definiranje problema su male jer samo korisnik moe izraziti svoje potrebe i probleme
Analiza zahtjeva
Analiza zahtjeva
Analiza zahtjeva obuhvaa proiavanje, analizu i pomno ispitivanje prikupljenih zahtjeva kako bi bili sigurni da svi sudionici projekta razumiju to zahtjevi znae, a ujedno slui da se pronau pogreke, nedostatci i ostali defekti. Izrada dijagrama konteksta sustava Jednostavni model koji definira ograde i suelja sustava te identificira tok informacija i materijala kroz suelje Izrada prototipova korisnikog suelja model oponaanja kao sredstvo razjanjenja zahtjeva Analiza ostvarivosti zahtjeva procjena trokova, performanci, rizika, konflikata prema ostalim zahtjevima Postavljanje prioriteta odreuje se relativni prioritet implementacije za pojedini sluaj koritenja, svojstvo proizvoda ili drugi zahtjev Modeliranje zahtjeva izrada modela strukture, ponaanja i stanja Izrada rjenika podataka sredinji repozitorij za definiranje podataka i struktura koritenih u sustavu te zajedniku terminologiju
Korisnik je sklon preutjeti izuzetke, koji su bitni (nuni !!!) za uspjenu realizaciju, a obino zahtijevaju i najvie napora tijekom ugradnje.
"To je naa jedina procedura (osim kada )"
Ne izjednaavati tako se uvijek radi s tako treba raditi!

Primjer: Google Search "Company Policy"
Analiza i modeliranje sustava

Na temelju izjava korisnika i prikupljene dokumentacije modeliraju se pojedine komponente sustava (procesi, podaci, dogaaji)
Mogua su preslikavanja uoenih imenica i glagola u konkretne elemente modela kakvi e biti opisani u nastavku.
Tip rijei Imenica Primjer Ljudi, organizacije, softverski sustavi, podatkovne jedinice, ili postojei objekti Akcije, ono to korisnik moe poduzeti, ili dogaaji koji se mogu dogoditi Komponente analitikog modela Terminatori ili spremnici podataka (DFD) Entiteti ili njihovi atributi (ERD) Razredi ili njihovi atributi (dijagram razreda) Procesi(DFD) Odnosi (ERD) Prijelazi (iz stanja u stanje) (STD) Metode razreda (dijagram razreda)
Postavljanje prioriteta
Nuno svojstvo (must have) - Da li se neto stvarno mora imati?
Postoji tendencija da se previe zahtjeva proglasi nunim! Po definiciji, ako sustav ne ukljuuje nune zahtjeve, taj sustav ne moe ispuniti svoju svrhu. Treba testirati svaki zahtjev koji se smatra nunim i probati ga rangirati. Ako se zahtjev moe rangirati onda nije obvezan! Nuni zahtjevi se ne mogu rangirati jer su potrebni za prvu verziju!
Glagol
Poeljno svojstvo (should have) Treba ispuniti do kraja projekta

Ranije verzije sustava mogu pruiti (ne potpunu) funkcionalnost bez tih zahtjeva. Poeljni zahtjevi mogu i trebaju biti rangirani.
"Kemiar ili lan osoblja kemijskog laboratorija moe podnijeti zahtjev za jednom ili vie kemikalija. Zahtjev moe biti udovoljen ili dostavom pakiranja kemikalije koja se ve nalazila na zalihi kemijskog laboratorija ili upuivanjem narudbe za novim pakiranjem kemikalije od vanjskog dobavljaa. Osoba koja upuuje zahtjev mora imati mogunost pretraivanja kataloga kemikalija vanjskog dobavljaa dok sastavlja narudbu. Sustav mora pratiti status svakog zahtjeva za kemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Takoer, mora pratiti povijest svakog pakiranja kemikalija od trena kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbaen."
Neobvezno svojstvo (could have) Moglo bi se ispuniti

Svojstva i mogunosti bez kojih se moe. Iako bi ih lijepo bilo imati, to nisu pravi zahtjevi. Ovi zahtjevi takoer mogu biti rangirani.
Nepotrebna svojstva (won't have)

Primjeri rangiranja prioriteta

znaenje mission-critical zahtjevi, potrebni za slijedee izdanje (release ) srednji podrka potrebnim sistemskim operacijama; zahtjeva se, ali moe se odgoditi za slijedee izdanje ukoliko je potrebno nizak poboljanje funkcionalnosti ili kvalitete neophodan softverski proizvod neprihvatljiv ukoliko ovi zahtjevi nisu ispunjeni na dogovoreni nain kondicionalan moe poboljati proizvod, ali proizvod nee biti neprihvatljiv bez toga opcionalan klasa funkcija koje bi mogle biti vrijedne ukljuivanja, ali moda i ne 3 mora biti savreno implementirano 2 treba raditi, no ne spektakularno dobro 1 moe sadravati pogreke (bugove) oznaka visok referenca Wiegers 99
Formalno odreivanje prioriteta

Formalni postupci
Quality Function Deployment (QFD) - odnos izmeu osobina predloenog proizvoda i koristi/vrijednosti za naruitelja, Total Quality Management (TQM) - rangira se svaki zahtjev u odnosu na nekoliko kriterija vanih za uspjeh projekta
Primjer, QFD
Navesti u tablici sve zahtjeve (requirements), osobine (features) ili sluajeve koritenja (use cases) za koje se ele postaviti prioriteti. Vei broj elemenata po potrebi hijerarhijski grupirati. Procijeniti relativnu korist (benefit) svakog svojstva za klijenta ili posao u rasponu od 1 do 9, pri emu 1 predstavlja dvojbenu korist, a 9 enormnu vrijednost. Procijeniti relativnu kaznu (penalty) ukoliko svojstvo ne bude ugraeno. Na ljestvici od 1 do 9, 1 predstavlja nepostojanje kazne, a 9 vrlo ozbiljan nedostatak. Pripaziti na zahtjeve koji imaju i nisku korist i nisku kaznu, jer oni pridonose trokovima, a imaju malu vrijednost. Stupac koji predstavlja ukupnu vrijednost je zbroj relativne koristi i relativne kazne pomnoenih s odgovarajuim teinama. Procijeniti relativni troak (cost) implementacije pojedinog svojstva, od 1 (nisko) do 9 (visoko). Razvojnici mogu rangirati trokove na temelju procjena koje ukljuuju sloenost zahtjeva, koliinu rada koje je potrebno uloiti za razvoj korisnikog suelja, mogunost ponovne uporabe koda, obujma potrebne dokumentacije, testova itd. Na slian nain, procijeniti relativni stupanj rizika vezanog uz svako svojstvo od 1 (izuzetno mali rizik) do 9 (ozbiljna zabrinutost oko izvedivosti, problemi s osobljem ili tehnologijom). Uobiajeno je da su korist, kazna i troak jednake teine, no svakom od tih faktora moe se dodijeliti razliita teina.
IEEE 98
Kovitz 99
Primjer formalnog odreivanja prioriteta

Proraunati vrijednost prioriteta (priority value) za svaku osobinu:
prioritet =
Teina 2
Verifikacija zahtjeva
Aktivnosti ovjere osiguravaju da su izjave o zahtjevima precizne, potpune i da demonstriraju eljene karakteristike.
vrijednost (% ) (troak (% ) * teina _ troka ) + (rizik (% ) * teina _ rizika )

1 1 0.5 Rel. Troak% rizik Rizik% Prioritet 11.11% 1 4.00% 1.152937 27.78% 3 12.00% 0.860618 16.67% 2 8.00% 0.843961 5.56% 4 16.00% 0.428898 22.22% 8 32.00% 0.517171 16.67% 7 28.00% 0.417088 100.00% 25 100.00%
Provjera dokumentacije sa zahtjevima

Formalna provjera zahtjeva smatra se jednom od najkorisnijih softverskih tehnika. Provodi je mala ekipa (analitiari, dizajneri, ... , korisnici) koja pomno ispituje specifikacije i modele.
Rel. Rel. Rel. Mogunost korist kazna Vrijednost Vrijednost% troak M1 5 3 13 15.12% 2 M2 9 7 25 29.07% 5 M3 5 5 15 17.44% 3 M4 2 1 5 5.81% 1 M5 4 9 17 19.77% 4 Mn 4 3 11 12.79% 3 Ukupno 29 28 86 100.00% 18
Pisanje testova, probnih sluajeva

Razvoj prototipa, izvoenje specifinih scenarija koritenja, kako bi se provjerilo oekivano ponaanje proizvoda u odreenim uvjetima. Probne sluajeve treba povezati unatrag s funkcionalnim zahtjevima kako bi se osiguralo da nijedan zahtjev nije zanemaren. Koritenjem test sluajeva verificira se tonost modela i prototipova.
Pisanje korisnikog prirunika

Skica korisnikog prirunika koja se radi na poetku razvoja zahtjeva moe posluiti kao specifikacija zahtjeva ili kao pomo u analizi zahtjeva. Dobar korisniki prirunik opisuje svu vidljivu funkcionalnost. Ostali zahtjevi dokumentiraju se u SRS.
Lista se sortira u padajuem redoslijedu prema prioritetu.

Ono to je na vrhu liste ima najpoeljniji odnos vrijednosti, troka i rizika, te zato treba imati najvii prioritet.
Definiranje kriterija prihvatljivosti

U suradnji s korisnicima definiraju se uvjeti pod kojima e proizvod zadovoljiti zahtjeve i biti spreman za koritenje. Testovi prihvatljivosti rade se na osnovu scenarija koritenja ili opisanih sluajeva koritenja.
Upravljanje zahtjevima
Upravljanje promjenama podrazumijeva proces za predlaganje promjena i ispitivanje potencijalnih trokova i utjecaja promjena na projekt.
Upravljanje zahtjevima (2)

Uspostava vremenske osnovice (baseline) i kontrole verzija
Potrebno je definirati vremensku osnovicu za zahtjeve, tj. sliku dogovorenih zahtjeva u odreenom vremenskom trenutku. Nakon to je osnovica definirana, zahtjevi prolaze postupak promjena. Svaka verzija specifikacije zahtjeva mora biti jednoznano oznaena da bi se izbjegle zabune uslijed razlika izmeu prethodnih i trenutne verzije.
Definiranje postupka za promjenu zahtjeva

Treba definirati postupak kojim se novi zahtjev ili promjena postojeeg zahtjeva analizira i odluuje o eventualnom prihvaanju. Sve predloene promjene moraju slijediti unaprijed definiranu proceduru.
Uspostava odbora za promjene

Zahtjevima najee upravlja poseban odbor, koji sainjavaju kljuni lanovi projekta. Odbor odluuje o usvajanju zahtjeva te postavlja prioritete i rokove njihove ugradnje.
Praenje povijesti promjena zahtjeva

Zapisi promjena sadre podatke o vremenu promjene, vrsti i sadraju promjena, razlozima promjene, oznakom verzije te podatkom o tome tko je aurirao dokument.
Praenje statusa zahtjeva

Evidentiraju se kljuni atributi funkcionalnih zahtjeva i njihov status (predloen, odobren, ugraen, provjeren), da bi se u svakom trenutku moglo znati broj zahtjeva u pojedinoj kategoriji.
Analiza utjecaja promjena zahtjeva

Za pojedinu promjenu zahtjeva procjenjuje se utjecaj na organizaciju projekta, vremenski raspored ili druge zahtjeve. Analiza utjecaja promjena treba posluiti donoenju dobrih (ispravnih, jedino moguih) odluka o (ne)prihvaanju promjena.
Mjerenje stabilnosti zahtjeva

Ako je broj odobrenih promjena tjedno ili mjeseno jako velik moe biti da problem nije dobro shvaen, da opseg projekta nije dobro definiran ili da projekt nije dobro upravljan.
Praenje promjena zahtjeva na svim proizvodima

Kada je promjena nekih zahtjeva prihvaena potrebno je kroz matricu praenja zahtjeva pronai sve ovisne komponente (izvorni kod, testni sluajevi, neki drugi zahtjev,...).
Koritenje alata za upravljanje zahtjevima

evidencija zahtjeva, meusobne povezanosti i statusa verzioniranje zahtjeva i dokumentacije
Dokumentiranje zahtjeva
Definicija zahtjeva (Requirements Definition)
izjava o stanju i ogranienjima sustava te potrebama narativni dokument namijenjen korisniku ili ga pie korisnik poslovni i korisniki zahtjevi te njihovi prioriteti uoeni problemi, kljune pretpostavke i preporuke rjeenja
Dokumentiranje zahtjeva
Specifikacija zahtjeva (Requirements Specification)

esto se naziva i funkcionalnom specifikacijom strukturirani dokument s detaljnim opisom oekivanog ponaanja sustava namijenjen ugovarateljima i izvoditeljima razvoja ugradbeno nezavisan pogled na sustav funkcionalni i nefunkcionalni zahtjevi te njihovi prioriteti model organizacijske strukture (strukturni dijagrami) opis protoka dokumenata (dijagrami toka rada) model procesa (dijagram toka podataka, dijagrami sluajeva koritenja) konceptualni model podataka (dijagram entiteti-veze)
Primjeri:
\Analiza\Firma-Zahtjevi, DOO-Specifikacija \Predloci\SpecifikacijaZahtjeva
Predloak dokumenta specifikacije zahtjeva

Predloak nastao na temelju standarda IEEE 830
Stavke koje nisu primjenjive u konkretnom projektu se izostavljaju. Treba ukljuiti i sadraj i povijest ispravki dokumenta
1. Uvod 1.1 Namjena 1.2 Konvencije dokumenta 1.3 Tko treba itati dokument i savjeti za itanje dokumenta 1.4 Opseg proizvoda 1.5 Reference 2. Sveobuhvatni pregled 2.1 Kontekst proizvoda 2.2 Funkcije proizvoda 2.3 Kategorije korisnika i svojstva 2.4 Okruje u kojem se izvodi proizvod 2.5 Ogranienja dizajna i ugradnje 2.6 Pretpostavke i ovisnosti 3. Zahtjevi za sueljem 3.1 Korisniko suelje 3.2 Hardversko suelje 3.3 Softversko suelje 3.4 Komunikacijsko suelje 4. Svojstva sustava 4.x Svojstvo X 4.x.1 Opis i prioriteti 4.x.2 Nizovi pobuda/odziv 4.x.3 Funkcijski zahtjevi 5. Ostali nefunkcionalni zahtjevi 5.1 Zahtjevi za performansama sustava 5.2 Zahtjevi za sigurnou korisnika 5.3 Zahtjevi za sigurnou podataka 5.4 Kvaliteta programske podrke 5.5 Poslovna pravila 5.6 Korisnika dokumentacija 6. Ostali zahtjevi Dodatak A: Rjenik Dodatak B: Modeli i dijagrami Dodatak C: Lista nedovrenih/neodreenih zahtjeva
Preporuke za pisanje zahtjeva

Preporuke:
koristiti kratke reenice i odlomke reenice trebaju biti kompletne, pravopisno i gramatiki ispravne pojmove treba upotrebljavati dosljedno zahtjeve treba izricati dosljedno: "Sustav e..." ili "Korisnik e..." iza ega slijedi glagol popraen uoljivim rezultatom, npr.: "Sustav za nadzor skladita e ispisati sva pakiranja zatraenog artikla u skladitu." mora biti jasno to znai da e sustav "procesirati", "podrati", "upravljati". izbjegavati nejasne, subjektivne izraze kao to su: lagano, jednostavno, brzo, efikasno, podrati, nekoliko, prihvatljivo izbjegavati izraze usporedbe kao to su: poboljati, maksimizirati, minimizirati, umanjiti, optimirati... kvantificirati stupanj poboljanja ili odrediti maksimalne ili minimalne prihvatljive vrijednosti nekog svojstva.
221
222
Preporuke za pisanje zahtjeva

Zahtjeve vie razine treba razloiti u dovoljan broj zahtjeva nie razine da bi se razjasnio zahtjev i uklonila mogua neodreenost.
Dobra mjera su zahtjevi koji se mogu nezavisno testirati. Zahtjev za koji moete smisliti mali broj test sluajeva najvjerojatnije je opisan dovoljno detaljno. Ukoliko su sluajevi za testiranje veliki i sloeni, najvjerojatnije se radi o vie zahtjeva koje treba razloiti. Svi bi zahtjevi trebali biti dosljedno napisani priblino jednakom razinom detalja. Izbjegavati veznike "i" i "ili" jer je to naznaka da se radi o vie zahtjeva u kombinaciji. Pojedini zahtjev mora biti naveden samo na jednom mjestu. Za poveanje itljivosti teksta koristiti reference unutar dokumenta.
Oznaavanje zahtjeva
Uzastopni brojevi
Novi zahtjev dobiva raspoloivi serijski broj (npr. Z01, Z02, ... ). Broj obrisanog zahtjeva ne koristi se ponovno. Nepregledno, teko za pratiti vei broj zahtjeva
Hijerarhijsko numeriranje
Zahtjev u poglavlju 3.2. ima oznaku koja poinje s 3.2., npr. 3.2.4. Vie znamenaka u oznaci oznaava detaljniji zahtjev. Jednostavna i najee koritena tehnika. Ureiva teksta se moe podesiti da automatski dodjeljuje oznake. Znamenke ne govore nita o namjeni zahtjeva. Problem brisanja zahtjeva koje uzrokuje posmak slijednih oznaka. Poboljanje: tekstovne oznake unutar brojanih hijerarhija Primjer: "Poglavlje 3.2. - Funkcije editora", sa zahtjevima u poglavlju oznaenim s "ED-01", "ED-02", itd. Ovaj pristup omoguuje hijerarhiju i organizaciju, oznake su kratke i smislene te manje osjetljive na promjene teksta.
223
Oznaavanje zahtjeva (nastavak)

Hijerarhijske tekstovne oznake
Primjer zahtjeva: "Sustav e upozoriti korisnika da potvrdi svaki zahtjev za ispisom vie od 10 kopija". Ovaj zahtjev moe se oznaiti s: ISPIS.KOPIJE.POTVRDA. Hijerarhijske tekstovne oznake su strukturirane i semantiki smislene a zahtjevi se briu i dodaju bez problema. Glavni nedostatak jest da su nezgrapnije u odnosu na hijerarhijsko numeriranje.
Inenjerstvo zahtjeva i upravljanje projektom

Planovi projekta trebaju biti temeljeni na funkcionalnosti koja se ugrauje i promjenama u zahtjevima koji utjeu na te planove. Odabir odgovarajueg ivotnog ciklusa razvoja
Ako su poetni zahtjevi kolebljivi, treba odabrati razvojni ciklus koji e omoguiti ugradnju zahtjeva kad oni budu bolje shvaeni. Klasini "vodopadni" ivotni ciklus razvoja moe se odrati samo u sluaju da su zahtjevi potpuno definirani na poetku projekta. Kada su doseg ili zahtjevi loe definirani prikladniji je inkrementalni pristup uz robusnu arhitekturu.
Zasnivanje plana projekta na zahtjevima
Potpunost
Nijedan zahtjev ili informacija ne smiju nedostajati. Zahtjeve koje nedostaju teko je uoiti. Razumijevanje poslovnog procesa moe pomoi u sprjeavanju nepotpunosti. Informacije koje nedostaju treba u specifikaciji oznaiti posebnom oznakom (npr. TBD - "to be determined"), te ih razrijeiti prije poetka ugradnje.
Plan i raspored moraju se dinamiki (iterativno) prilagoavati, sukladno poveanju jasnoe opsega i zahtjeva. Prva procjena truda uobiajeno se zasniva na inicijalnoj viziji i dosegu projekta. Rane procjene su nesigurne i treba ih aurirati nakon to zahtjevi budu bolje definirani i/ili shvaeni.
Pregovaranje termina isporuke prilikom promjena zahtjeva

Prilikom usvajanja novih zahtjeva treba procijeniti da li se moe odrati postojei raspored i kvaliteta isporuke s postojeim resursima. Ako ne, potrebno je dogovoriti novi rok isporuke. U sluaju neuspjelih pregovora, treba priopiti vjerojatni ishod te u plan ugraditi stanje rizika i mogue prijetnje uspjehu.
225
226
Rizici loeg planiranja zahtjeva

Nedovoljna ukljuenost korisnika
Bez korisnika ne moe se tono znati to korisnici ele neprihvatljivi proizvodi. Uz ukljuivanje krajnjih korisnika, nuna je i potpora rukovodstva!
Rizici loeg planiranja zahtjeva

Pretjerano ukraavanje
elja izvoaa da dodaju novu funkcionalnost "koja bi se trebala svidjeti korisnima" i zahtjev korisnika za dodacima koji dobro izgledaju ali ne pridonose funkcionalnosti nepotrebni dodaci i gubljenje vremena Nuna je procjena izvodljivosti s obzirom na zadane okvire.
udni korisniki zahtjevi

Neopravdana promjena miljenja tijekom izvedbe prekoraenja rokova i degradacije kvalitete proizvoda Definirati viziju, opseg, ciljeve i ogranienja na projekt, kriterije za mjerenje uspjenosti te mehanizam upravljanja promjenama.
Minimalistike specifikacije
Tendencija postavljanja minimalnih zahtjeva ili skiciranja koncepta, uz elju da ih izvoai nadopune tijekom izvedbe frustracije izvoaa, neispunjena oekivanja korisnika.
Zanemarivanje potreba
Zanemarivanje potreba odreenih (grupa) korisnika stvaranje 'opozicije' projektu Uvaiti ciljane grupe korisnika, uz objanjenje prioriteta.
Nejasni (dvosmisleni) zahtjevi

Situacija u kojoj itatelj(i) zahtjeva zahtjev tumae na vie naina gubljenje vremena i prepravljanje Rjeenje moe biti analiza/provjera zahtjeva koju provode osobe koje nisu sudjelovale u prikupljanju zahtjeva.
Povrna analiza zahtjeva - loe planiranje

"Ovo je moja ideja za . Kad bi moglo biti gotovo?" Slabo razumijevanje zahtjeva vodi do pretjerano optimistinih procjena. Na prethodno pitanje je teko dati toan odgovor bez detaljnog uvida u zahtjeve. U sluajevima nedovoljne informacije ili nedovoljnog razumijevanja problema, preuranjeni konkretni odgovor na pitanje treba izbjegavati. Alternativno, moe se dati okvirnu procjenu koristei termine: "u najboljem sluaju", "vjerojatno", "u najgorem sluaju" ili izraavajui postotak sigurnosti procjene.
Reference
http://www.jiludwig.com/Requirements_Management_Tools.html
Modeliranje funkcija i procesa
4/13
229
Strukturirana analiza
Moderna strukturirana analiza = Logiki dizajn (esti sinonim)
strukturirana analiza strukturirani proces i rezultati analize tehnika modeliranja poslovnih zahtjeva na sustav usmjerena procesima, ali se razvila tako da obuhvaa i podatke strukturiranje procesa, ulaza, izlaza te spremita podataka potrebnih da bi se ogovorilo na poslovne dogaaje logiki modeli odreivanje TO je sustav i TO mora raditi (ne KAKO) koriste se dijagrami toka podataka za logiki prikaz poslovnih zahtjeva nezavisno od tehnikih rjeenja logiki dizajn izraavaju sutinu sustava sinonimi: esencijalni, konceptualni, poslovni modeli ukljuuje odreivanje prioriteta zahtjeva
Dekompozicija procesa i funkcija

Logiki procesi: funkcije, dogaaji i elementarni procesi
rad i akcije koji se obavljaju bez obzira na nain ugradnje i resurse sustava (ljudi, strojevi, softver) Neke metode poistovjeuju funkcije i procese!
Postupak dekompozicije
stvarni problemi su preveliki i presloeni da bi ih se rijeilo odjednom (u komadu) strukturno ralanjivanje, rastavljanje naelo podijeli pa s/vladaj (lat. divide et impera, eng. divide and conquer)
Sustav se razlae i opisuje hijerarhijskim modelima

modeli sustava oblikuju se iterativnim razlaganjem s vrha prema dolje razlagati se mogu funkcije i procesi organizacijska struktura struktura podataka struktura programske opreme
Aplikacijski model procesa = logiki model procesa sustava ili aplikacije koji se radi u fazi analize
Logiki procesi
Funkcija
skup logiki povezanih trajnih poslovnih aktivnosti i zadataka (djelatnost, posao) funkcija se obavlja stalno (nema odreeni poetak i kraj) funkciju obavljaju osobe, grupe djelatnika ili organizacijske cjeline tipini primjeri: prodaja, proizvodnja, otprema, raunovodstvo funkcija se moe sastojati od desetina pa i stotina diskretnih procesa funkcije se mogu hijerarhijski razloiti do razine diskretnih procesa koji obavljaju odreeni zadatak kojim odgovaraju na poslovne dogaaje
Poslovna pravila i poslovna politika

Poslovno pravilo, poslovna politika
poslovno pravilo - instrukcije i logika koji odreuju proceduru obavljanja procesa ugrauje se u raunalni program (npr. preduvjeti izlaska na ispit, broj polaganja ispita, uvjeti upisa) poslovna politika skup poslovnih pravila u veini organizacija podloga za donoenje odluka
Dogaaj
logiki dio posla koji se obavlja kao nedjeljiva cjelina esti naziv transakcija pokree se diskretnim ulazom i zavrava nakon to proces odgovori odgovarajuim izlazom poslovni dogaaj moe se predstaviti jednim procesom kojim sustav reagira na taj dogaaj logiki dogaaj dalje se razlae do elementarnih procesa kojima se prikazuje reakcija sustava na taj dogaaj
Primjer: subvencioniranje studentske prehrane

Ovisno o evidentiranoj razini prava, studenti imaju dnevno dozvoljeni iznos cijene konzumirane hrane koji je subvencioniran. Taj iznos ne predstavlja dnevno ogranienje, ve se svakog prvog u mjesecu dodjeljuju prava za itav mjesec kojima student raspolae po elji. Mjeseni iznos raspoloiv za subvenciju jednak je umnoku broja dana u mjesecu i dnevnog subvencioniranog iznosa za razinu prava. Npr. za razinu prava 1 (studenti domicilni) dnevno subvencionirani iznos je 16.70 Kn (cijena jednog menija), pa student te razine u mjesecu svibnju ima raspoloivo za subvenciju 16.70 * 31 = 517.7 Kn. Iznos raspoloiv za subvenciju se akumulira tijekom itave akademske godine to znai da se neiskoritena prava iz jednog mjeseca prebacuju na slijedei. Na kraju akademske godine akumulirani iznos se brie. Za ostvarivanje bilo koje razine prava vee od 1, potrebno je Da bi student prvog u mjesecu stekao novi dozvoljeni subvencionirani iznos, moraju biti ispunjeni uvjeti:
Proces (elementarni, primitivni proces)

postupak, nain rada, dosljedna izmjena stanja diskretna odluka, aktivnost ili zadatak kojima se obavlja neki posao proces se obavlja uvijek na jednak nain (za odreeni ulaz daje isti izlaz) trajanje procesa je konano i odredivo (poznati poetak, zavretak, ponavljanje) za obavljanje se koriste sredstva, npr. ljudska, materijalna (strojevi), financijska
Modeliranje funkcija
Funkcionalna dekompozicija, dekompozicija funkcija
koristi se za izradu opeg modela funkcija (modela poslovnih funkcija) promatranog sustava u fazi planiranja strukturirano planiranje hijerarhija funkcija iterativno se razlae do razine procesa, tj. do trenutka kada se pone opisivati to se nekom funkcijom obavlja
0 The System
Dijagram dekompozicije funkcija

Dijagram funkcionalne dekompozicije
eng. Functional Decomposition Diagram (FDD) ista notacija koristi se za razlaganje bilo koje hijerarhijske strukture pa se esto zove samo Dijagram dekompozicije ili Mapa hijerarhije
Elementi
funkcije - oznaavaju se (glagolskom) imenicom, npr. Prodaja, Proizvodnja procesi - oznaavaju se glagolskim izrazom oblika infinitiv+objekt spojnice - spojevi izmeu funkcija i procesa (connector) vanjski spojevi - spojevi s dijelovima dijagrama na drugim stranicama (offpage connector)
0 The System 1 AFunctionof the System 1.1 Activity of the Function

Task 1.1.1 Task 1.1.3 Task 1.1.2
1 AFunction
2 Another Function
1.2 Another Activity of the Function

Task 1.2.1 Task 1.2.2
1.1 Activityof the Function
1.2 Another Activity of the Function
2.1 Acivityof this Function
2.2 Another Activity of thisFunction
Funkcija
2 Another Functionof the System 2.1 Activity of this Function

Task 2.1.1 Task 2.1.2 Task 2.2.1 Task 2.1.3 Task 2.1.4 Task 2.2.3 Task 2.2.2
Task1.1.1
Task1.2.1
Task2.1.1
Task2.2.1
2.2 Another Activity of this Function

Task1.1.2 Task1.2.2 Task2.1.2 Task2.2.2
Proces
Task1.1.3
Task2.1.3
Task2.2.3
Task2.1.4
235
236
Dijagram dekompozicije funkcija

Primjer, dijagram funkcija za jedan sustav/podsustav:
MARKATONE
Hijerarhijski prikaz funkcija/procesa

Izrada globalnog modela funkcija moe zapoeti izradom hijerarhijske liste funkcija po pojedinim organizacijskim cjelinama. Primjer:
NABAVA Evidentiranje dobavljaa Nabavka robe
Izrada narudbi Zaprimanje robe
Nabava
Knjigovodstvo
Prodaja
Evi denti ranje dobavljaa
Naruivanje robe
Knjienje
Evi denti ranje kupaca
Fakturiranje
Prodaja robe
UPRAVLJANJE OSOBLJEM Evidentiranje slube

Zaprimanje u slubu Praenje slube redovan rad prekovremeni rad bolovanje godinji odmori Otputanje iz slube
Izrada narudbi
Zaprimanje robe
Izrada otpremnica
Otprema robe
Dodavanje
Au riranje
Brisanje
Primjeri:
\Modeliranje\PutniNaloziBlagajna
237
Obraun plaa
Izrada dijagrama dekompozicije

Postupak
Korijen = sustav Razrada u podsustave i poslovne funkcije Daljnja razrada do razine operacionalizacije
Dijagram organizacije
Shema, mapa, karta organizacije (Organization chart)
prikaz strukture organizacije hijerarhijom pravokutnika ("kuica") svaki pravokutnik reprezentira odreenu ulogu ili odgovornost u organizaciji
Pravila
svaki proces je roditelj ili dijete roditelj mora imati barem dvoje djece po veini standarda, dijete smije imati samo jednog roditelja
Dekan XXX
Preporuke
izostaviti procese koji samo premjetaju ili preusmjeravaju podatke, a da ih pri tom ostavljaju nedirnute panju usmjeriti na procese koji neto raunaju (npr. prosjek ocjena) donose ili potpomau odluke (npr. odreivanje raspoloivosti robe pri naruivanju) filtriraju ili sumariziraju podatke (npr. rauni kojima je istekao rok plaanja) organiziraju podatke u korisne informacije (npr. generiranje izvjea) pokreu druge procese (npr. mijenjaju modalitet rada stroja) rukuju podacima (npr. stvaranje, itanje, auriranje, brisanje) - Ne pretjerivati!
Tajnica dekana XXXX Prodekan za nastavu
Prodekan za znanstvenoistraivaki rad
Prodekan za poslovanje
Tajnitvo Tajnik XXX
Studentska sluba Voditelj XXX
Financijska sluba
Sredinja knjinica
ZPR Predstojnik XXX
...
...
240
Primjer: hijerarhija funkcija aplikacije
Razrada poslovnih procesa

Tehnike modeliranja
u irinu - svaki dijagram se detaljizira prije dekomponiranja (breadth-first) u dubinu - identificira se hijerarhija, a zatim se detaljizira (depth-first)
Razina dekompozicije (Kada stati)

postupak se provodi do dubine dovoljne za razumijevanje modela (!?) napredak do stanja u kojem ulazi i izlazi prevladaju na dijagramu nastavak se moe provesti oblikovanjem toka rada (npr dijagramom aktivnosti) ili
Napomena: pomagala ope namjene, kao to je Visio, podravaju neke dijagrame formalnih tehnika ali ih razliito zovu ili se notacija razlikuje od izvorne (grupe dijagrama Business Process i Flowchart, npr. IDEF0, Cross Functional FlowChart)
oblikovanjem toka podataka (Data Flow Diagram - DFD )
Tok rada (workflow) - radna procedura, poslovna procedura

slijed koraka obrade koji u potpunosti obrauje jednu poslovnu transakciju definira logiku obrade i precizira nositelja moe imati vie varijanti (scenarija)
Oblikovanje toka rada

Primjer: Raspis natjeaja za izbor u zvanje ili na radno mjesto
U urudbeni zapisnik se predaje zahtjev za raspisom natjeaja u zvanje i/ili radno mjesto. Podnesak za izbor u znanstveno zvanje moe biti na osobni zahtjev ili na zahtjev organizacije (zavoda). Kako je FER jedna od ustanova s ovlatenjem za provoenje postupka biranja u zvanja, zahtjev potekao s FER-a provodi sam, ali isto tako provodi postupak i na zahtjev s drugih znanstvenih organizacija koje nisu ovlatene za provedbu postupka. Zahtjev se prosljeuje Odboru za izbore u zvanja koje predlae lanove Strunog povjerenstva za provedbu postupka i definira javni natjeaj Prijedlog razmatra Fakultetsko vijee te ga ili alje nazad na doradu Odboru za izbore u zvanja ili samo definira nove lanove Strunog povjerenstva Opa sluba prosljeuje odluku Fakultetskog vijea Kadrovskoj slubi Kadrovska sluba raspisuje natjeaj i obavjetava lanove Strunog povjerenstva
Primjer: Raspis natjeaja
243
244
Primjer: postupak izbora u zvanje

Izbor u znanstveno zvanje moe se provesti neovisno o radnom mjestu na zahtjev pojedinca ili znanstvene organizacije u kojoj pojedinac radi. Na visokim uilitima izbor u zvanje odvija usporedo s izborom na radno mjesto ukoliko je to potrebno.
Zakonom su predviena sljedea znanstvena zvanja: znanstveni suradnik vii znanstveni suradnik znanstveni savjetnik. Pristupnik moe biti izabran u znanstveno-nastavno zvanje ako ispunjava uvjete za izbor u odgovarajue znanstveno zvanje: docenta: znanstveni suradnik, vii znanstveni suradnik ili znanstveni savjetnik, izvanrednog profesora: vii znanstveni suradnik ili znanstveni savjetnik, redovitog profesora: znanstveni savjetnik.
Primjer: Izbor u zvanje 1/2
Postupak je opisan narednim dijagramima (slika vrijedi 1024 rijei)

postoje varijante izbora u nastavna zvanja ili suradnika mjesta koje ovdje nisu prikazane
Modeliranje toka podataka

Dijagram toka podataka (DFD - Data Flow Diagram)
skup dijagrama za dokumentiranje fizikog i logikog modela sustava te zahtjeva prikaz protoka, strukture i obrade podataka dokumentiranje logike, poslovnih pravila i procedura sinonimi: transformacijski graf, mjehurasti graf, mjehurasti dijagram (Bubble Chart)
Spremite podataka Tok podataka
D1 Spremite podataka
Tok podataka
Tok materijala Vanjski entitet
Proces
a Vanjski entitet
P1 Proces
Tok materijala
Primjer: Izbor u zvanje 2/2
Tehnika se primjenjuje pri razvoju aplikacija, otkuda je i potekla

Ne moe se koristiti za opis programske logike, opis promjene stanja, izradu upravljakih specifikacija ili dizajn korisnikog suelja!!!
247
248
Elementi dijagrama toka podataka

Tok podataka (data flow)
predstavlja skupove podataka koji se kreu kroz sustav tokovi ulaze u procese (ulazni), koriste se i mijenjaju tijekom obavljanja procesa (ulazno/izlazni) ili nastaju kao rezultat procesa (izlazni) tokovima se pridjeljuju jedinstveni nazivi oblika imenica ili pridjev+imenica, npr. Potvrena prijavnica, Izlazni raun
Izrada dijagrama toka podataka

Dekompozicija procesa
polazni dijagram ili dijagram konteksta (context diagram) hijerarhijski se razlae na poddijagrame do razine osnovnih procesa proces na nekoj razini (parent) razrauje se (explode) dijagramom na nioj razini (child) leveling = nivelizacija preporua se izrada dijagrama koji sadre izmeu 2 i 9 procesa, a poeljno je slijediti pravilo 72 postupak se zaustavlja kada postane oigledna ugradnja (implementacija) procesa na najnioj razini
Spremite podataka (data store)

predstavlja organizirani i trajni skup podataka oznaava mjesto pohrane podataka, npr. dokument, registrator, datoteka, tablica u bazi podataka (izbjegavati u nazivlju) promjena sadraja spremita (punjenje, auriranje, pranjenje) i koritenje (itanje) obavlja se procesima spremite se oznaava imenicom (imenicom u mnoini), npr. Prijavnica (Prijavnice)
Proces
predstavlja aktivnost pretvorbe podataka (ulaznog u izlazni tok podataka) procesi se imenuju glagolskim izrazima oblika infinitiv+objekt (npr. Prijaviti ispit) ili glagolskom imenicom (npr. Prodaja, Prijava ispita) nazivom treba izraziti to proces obavlja, to jest treba izbjegavati openite nazive (npr. Obavljanje raunovodstvenih poslova) opis procesa sadri opis aktivnosti (algoritam) njegovog djelovanja
Vanjski entitet (external entity, external agent)

objekt vanjskog svijeta povezan s promatranim sustavom odreuje granice promatranog sustava vanjski entiteti predstavljaju izvorita i odredita podataka, to jest izvore i ponore podataka (source, sink) vanjski entiteti mogu biti osobe, org. jedinice, ustanove, drugi sustavi za oznaavanje entiteta koriste se imenice, npr. Student, Kupac, Dobavlja
249
Preporuke za oznaavanje elemenata

procesi - hijerarhijske brojane oznake, razina konteksta = 0 spremita, izvori i odredita nazivlje velikim slovima, oznake oblika slovo ili slovo+broj procesi i tokovi podataka - malim slovima
250

Dijagram konteksta
prikazuje sustav na najvioj razini hijerarhije prikaza (top level diagram) definira okruenje sustava i podruje analize (environmental model) prikazuje jedan proces i vanjske entitete zapoeti s procesom koji prikazuje sustav u cjelini odrediti vanjske entitete i njihovu povezanost sa sustavom
e Osoba lanska kartica Videoteka Novi video Zahtjev za identifikaciju Identifikacija P0 Narudba b Dobavlja

Pregledni dijagram (initial diagram)
uoiti glavne tokove informacija (npr. koriteni dokumenti, potrebni podaci) odrediti glavne aktivnosti sustava i prikazati ih odgovarajuim procesima ukljuiti vanjske entitete i tokove podataka s dijagrama konteksta sloiti se s korisnikom oko granica sustava utvrditi procese i spremita podataka
Rezultat upita
Zahtjev za rezervaciju Video lan lanska kartica i plaanje
d Upit
251
252

Pregledni dijagram, odreivanje dosega
e Osoba Zahtjev za identifikaciju Identifikacija lanska kartica P1 Upisati novog lana Rezervacija P4 Rezervirati video Video D3 Video Video

Razrada
za svaki proces s preglednog dijagrama identificirati podaktivnosti na primjer, za proces Upisati novog lana: Zahtjev za Zatraiti osobne podatke P1.1 identifikaciju Evidentirati novog lana Zatraiti osobne Izraditi lansku karticu
Identifikacija podatke
D4 Rezervacija
Rezervacija D1 lan P5 Traiti video Posudba P2 Posudba D2 Posudba Posuditi video lanska kartica i plaanje Video P3 Vratiti video
lan
P6 Nabaviti video
P1.4 Evidentirati novog lana
Osobni podaci D1 lan lan lan
P1.3 Izraditi lansku karticu
lanska kartica
Upit
Rezultat upita
Narudba b
Novi video
Ponavljati postupak za svaki od procesa na poddijagramu

uspostaviti razinu detalja slijedei pravilo 72 provjeriti potpunost i ispravnost modela
d lan Video Zahtjev za rezervaciju
Model obrazloiti korisniku a zatim ga aurirati po potrebi

Posudba Dobavlja
Dubinu i uravnoteenost modela teko je odrediti. U praksi to moe znaiti doradu dijagrama u veem broju ponavljanja, ak i kada dijagrame rade iskusni analitiari!!!
Pravila i ogranienja prilikom izrade DTP

Pravilo bilance (ouvanja) tokova (level balance rule)
koliina tokova koji ulaze u proces i izlaze iz procesa mora odgovarati koliini tokova podprocesa na nioj razini hijerarhije nije dozvoljeno variranje tokova neke razine na niim razinama (npr. tok T na niim razinama prikazivati kao T1, T2)
Preporuke za izradu DTP

Treba pripaziti na:
trivijalne tokove izlazi iz procesa koji ne ulaze u spremita ili odredita obino imaju posebno znaenje, a mogu se koristiti za prikaz posebnih stanja kao to je dojava poruke sustava (npr. dojava pogreke) neposredno povezane procese ako postoje, to znai da jedan od procesa eka na zavretak prethodnog procese koji ne obavljaju pretvorbu podataka ako je izlazni tok jednak ulaznom
treba preimenovati jedan od tokova ili treba obaviti prespajanje tokova
b b
Ogranienja i posebni sluajevi

Svi objekti modela moraju biti povezani. Nepovezanost pojedinih objekata ukazuje na nepotpunost modela, na primjer: postojanje procesa bez ulaza i/ili izlaza (tzv. uda i crne rupe) izlaze za koje ne postoji dovoljno ulaza (tzv. sive rupe najee) postojanje nepovezanih spremita ili vanjskih entiteta Ne dozvoljava se neposredna povezanost: vanjskih entiteta spremita spremita i vanjskog entiteta Nije dozvoljeno: grananje toka u razliite tokove, spajanje razliitih tokova postojanje rekurzivnih procesa
primjer:
a b c b
Procesi se mogu zbivati istovremeno kao dijagram toka (flowchart)!

DTP se ne smije tumaiti
256
Metode koje koriste DTP

Notacije
Gane/Sarson (koritena u primjerima)
a Vanjski entitet P1 Proces D1 Izlazni tok Spremite podataka
Opisivanje podataka
Rjenik podataka (Data Dictionary)
mjesto pohrane definicija podatkovnih elemenata i struktura podataka strukturirano spremite meta-podataka, to jest podataka o podacima prvotno se pojavio kao proirenje dijagrama toka podataka, za pohranu opisa spremita podataka i tokova podataka moe se koristiti kao alternativna tehnika za prikaz modela podataka standardno se upotrebljava BNF notacija (Backus-Naur Form), koja se inae koristi za opis sintakse programskih jezika
Najmanja logika cjelina podataka
Podatkovni element
Ulazni tok
Yourdon/DeMarco
1 Vanjski entitet Proces Ulazni tok
1 Proces D1 Izlazni tok Spremite podataka
Izlazni tok
Spremite podataka
SSADM
a Vanjski entitet Ulazni tok
Proirenja modela
okida (trigger) - prikaz uestalosti procesa (npr. tri puta dnevno) posebni simboli za prikaz ponavljanja procesa razdvajanje i spajanje tokova (alternativni tokovi) posebni simboli za tok resursa, tok dokumenata ili tok upravljanja (npr. razliite linije ili ikone)
Grupe sainjene od podatkovnih elemenata
Struktura podataka
Grupe sainjene od struktura podataka
Tok podataka
Spremite podataka
258
Definiranje podataka BNF notacijom

Notacija struktura s lijeva sastoji se od dijelova s desna ("sastavljeno od") = agregacija elemenata (logiko I) + ( ) opcionalnost elemenata u zagradi (0 ili 1) {} ponavljanje (iteracija) elemenata u zagradi, ni jednom do konani broj puta [] alternativa (selekcija) elemenata u zagradi odvajanje alternativnih elemenata u [] izrazu | poetna i zavrna vrijednost raspona definiranog [] izrazom ** komentar @ oznaka kljua Primjer, raun i stavke rauna
Racun = @BrRac + DatRac + BrKupca + { SifArt, NazArt, Cijena, Kol, Vrijednost } + (IznosRac) Racun = @BrRac + DatRac + BrKupca + { StavkaRac } + (IznosRac) StavkaRac = @SifArt, NazArt, Cijena, Kol, Vrijednost
Elementarni procesi
Mini-specifikacije (funkcionalne primitive)
specifikacije za opisivanje osnovnih procesa u dijagramu toka podataka mogu poprimiti razliite oblike, ali imaju nekoliko zajednikih elemenata: naziv i broj procesa listu podataka koji ulaze u proces (ulaznih tokova podataka) listu podataka koji iz procesa izlaze (izlaznih tokova podataka) tijelo opisa procesa
Opis procesa
sadri algoritam zadatka koji se procesom obavlja, koji moe poprimiti razliite oblike ( dizajn programa - opis programske logike) na temelju ovog algoritma moe se, ovisno o alatu, generirati kd
Moe se napisati i kao:
260
Definiranje procesa
Primjer definicije procesa (1)
Proces 1: Opis: Ulazni tokovi: Provjera raspoloivosti filma Provjera da li u videoteci postoji kopija filma koja se moe iznajmiti Upit (Film) Rezervacije Posudbe Izlazni tokovi: Logika procesa: Rezultat upita (raspoloiv | nije raspoloiv | ne postoji) izraunaj broj kopija traenog filma u videoteci ako je broj kopija vei od nule tada ako je broj kopija vei od (broj posudbi + broj rezervacija rezultat = "Raspoloiv" inae rezultat = "Nije raspoloiv" inae rezultat = "Ne postoji"
Definiranje procesa
Primjer definicije procesa (2)
Proces 1: Opis: Ulazni tokovi: Izlazni tokovi: Logika procesa: Provjera raspoloivosti filma Provjera da li u videoteci postoji kopija filma koja se moe iznajmiti Upit (Film), Rezervacije, Posudbe Film nije raspoloiv, Film je raspoloiv izraunaj broj kopija traenog filma u videoteci ako je broj kopija vei od nule tada ako je broj kopija vei od (broj posudbi + broj rezervacija) nastavi s P2 (izl. tok Film je raspoloiv) inae ako lan eli rezervirati film tada upii rezervaciju (izl. tok Film nije raspoloiv) inae poruka "Ne postoji"
261
262
Primjena modela procesa

Strateko planiranje sustava
definiranje arhitekture sustava u okviru stratekog plana, pri emu se radi model procesa poduzea (globalni model procesa) identificira poslovna podruja i poslovne funkcije najee u formi dijagrama dekompozicije funkcija ili nerazraenog DTP (npr. dijagramom konteksta odreuju se doseg i suelja sustava)
Primjer dijagrama iz stvarnog projekta
Preoblikovanje poslovnih procesa

analiza i restrukturiranje poslovnih procesa radi poboljanja uinkovitosti i uklanjanja birokratizma, prije primjene informacijskih tehnologija postojei procesi se analiziraju i dokumentiraju prikladnim modelima procesa dijagrami toka podataka s fizikalnim primjesama, koje ukljuuju vremensku dimenziju, protonost podataka i trokove
Analiza sustava
aplikacijski modeli procesa - logiki modeli procesa sustava ili aplikacije teorijski, mogue je proizvesti DTP povratnim inenjerstvom postojeih aplikacija, ali e takav dijagram biti preoptereen fizikalnim primjesama
Dizajn sustava
fiziki modeli procesa - dodavanjem upravljakih komponenti i resursa
DTP analizom izjava korisnika
7. pretraivanje kataloga dobavlja a
informacija o katalogu dobavlja a upit na katalog dobavlja a
Kemi ar zahtjev za kemikalijom
Osoblje kemijjskog laboratorija
Primjeri DTP
novo stanje "Kemiar ili lan osoblja inventorija informacija o katalogu zahtjev za kemikalijom kemijskog laboratorija moe dobavlja a 6. podnijeti zahtjev za jednom ili auriranje stanja zaliha vie kemikalija. Zahtjev moe laboratorija 1. informacija o katalogu biti udovoljen ili dostavom katalog podnoenja dobavlja a dobavlja a zahtjeva za pakiranja kemikalije koja se ve kemikalijom 2. pakiranje nalazila na zalihi kemijskog ispunjavanje kemikalija novo stanje inventorija zahtjeva iz laboratorija ili upuivanjem zaliha laboratorija narudbe za novim pakiranjem zahtjev za informacijom kemikalije od vanjskog dobavljaa. Osoba koja upuuje pakiranje inventorij kemijskog kemikalija laboratorija zahtjev mora imati mogunost laboratorijski pretraivanja kataloga zahtjev zahtjev status dobavlja eve narudbe za kemikalijom kemikalija vanjskog podaci stanje inventorija o promijenama dobavljaa dok sastavlja u inventoriju narudbu. Sustav mora pratiti zahjev za dobavlja evom 5. status svakog zahtjeva za kemikalijom generiranje izvje a o kemikalijama od trenutka kad je 3. 4. stanju zaliha ispunjen do trenutka kad je podnoenje generiranje zahtjeva za izvje a za udovoljen ili otkazan. Takoer, kemikalijom vladu mora pratiti povijest svakog izvje e o pakiranja kemikalija od trena zahjev za dobavlja evom uporabi zahtijev za status kemikalija kemikalijom izvje em o dobavlja eve kad stigne u kompaniju do uporabi kemikalija narudbe trenutka kad je potpuno upotrijebljen ili odbaen." ... Odjel za kupovinu Vladin odjel za sigurnost i zdravlje
pakiranje kemikalija
pakiranje kemikalija
izvje e o stanju inventorija
266
Primjer: Procesi sustava ISSP

ISSP se moe podijeliti na slijedee funkcionalne cjeline:
lanice sveuilita i veleuilita, iji studenti ostvaruju pravo na subvencioniranu prehranu (ustanove) Restorane koji pruaju uslugu prehrane prehranu lanovima ustanove (mjesta troka) Tvrtka zaduena za odravanje i nabavu opreme te tiskanje iskaznica lanova Centar za autorizaciju prava lanova (CAP), kao ustanova zaduena za uvoenje i trajno odravanje sustava.
b
Primjer: razrada procesa ISSP

Evidencija matinih podataka lanova
Obvezni matini podaci studenta su: Ime, Prezime, JMBG, Matini broj (broj indeksa), Razina prava, JMBAG Omogueno je evidentiranje i ostalih neobveznih podataka
Unutar svake od cjelina obavlja se vie specifinih procesa koji ...

d SC i ostali pruzatelji usluge
Evidencija podataka o statusu lana u ustanovi

Evidentiran upis godine sadri podatke o:
Upisni list P1.1 Upisni list Upis novog vlasnika (studenta) P1.2 P1.5 Upis godine Izdavanje kartice vlasniku Nova kartica Nova kartica
Pokrovitelj subvencije
Pregled potrosnje restorana
Pregled potrosnje restorana
P4
Zatrazena kartica
P2
Zatrazena kartica Vlasnik
P1
Vlasnik Zahtijev za promjenu razine prav Zahtjiev za dokumentaciju

Zahtjev za dokumentaciju Zahtjev za izdavanje kartice Zahtjev za promjenu razine prav
Vlasnik
Upis godine Kartica
Tvrtka za tiskanje Nova kartica
CAP
Upis godine Nova kartica
Ustanova
P1.3 Promjena razine prava vlasnika Vlasnik D1 Vlasnik D3 Upis godine D2 Kartica
Dozvoljeno za subvenciju Nacinjen racun (dnevnik)
Kartica
Vlasnik
Nova kartica
Dokumentacija
P3
a Kartica Vlasnik (student) Dokumentacija
P1.4 Vlasnik Obrada zahtjeva za karticu Kartica
Restoran
267
268
Dogaaji
Dogaaj
zgoda, zbivanje u sustavu koja vodi ili pokree procese sustava sm dogaaj nije proces, nego okida procesa koji se njime pokree primjer: kupac dostavi narudbu, pokree proces provjere da li se radi o narudbi postojeeg ili novog kupca, proces stvaranja podataka o narudbi i stavkama narudbe, provjeru prethodnih zaduenja kupca, provjeru stanja skladita itd.
Modeliranje dogaaja
270
Vrste dogaaja
Vrste dogaaja
vanjski dogaaji potaknuti od strane vanjskih entiteta, koji zahtijevaju informaciju ili auriranje podataka ulazni tokovi podataka imenuju se tako da naziv sadri naziv vanjskog entiteta primjer: zahtjev za upis studenta ili zaprimanje narudbe kupca vremenski dogaaji - vremenski uvjetovani (rok, uestalost) ulazni upravljaki tokovi imenuju se tako da naziv sadri vremensku oznaku primjer: istek roka plaanja rauna, mjeseni obraun plaa, zakljuivanje ispitnog roka unutarnji dogaaji, dogaaji stanja - posljedica prijelaza sustava iz jednog stanja u drugo, na takav nain ta to zahtjeva obradu ulazni upravljaki tokovi primjer: isporuka robe sa skladita zahtijeva naruivanje nove robe
1. 2. 3.
Modeliranje procesa voeno dogaajima

Raspodjela dogaaja (event partitioning)
Izrada dijagrama konteksta sustava postavljanje poetnog dosega projekta Izrada dijagrama funkcionalne dekompozicije podjela sustava u logike podsustave i/ili funkcije Izrada popisa dogaaja i odziva utvrivanje poslovnih dogaaja na koje sustav mora odgovoriti element popisa = dogaaj, ulaz, izlaz Izrada dijagrama dekompozicije dogaaja dodavanje procesa za rukovanje dogaajima (event handler) dodaje se po jedan proces za svaki utvreni dogaaj Izrada dijagrama dogaaja razrada procesa za obradu dogaaja po jedan dijagram za svaki svaki dogaaj Izrada dijagrama sustava udruivanjem dijagrama dogaaja Izrada primitivnih dijagrama razrada dijagramom toka podataka koji sadri osnovne procese, spremita i tokove za svaki pojedini dogaaj
4.
5.
6. 7.
271
272

Event-Response List
event 1 event 2 response response response response response response response

Event 2 Event n-2
1
The System
event 3
event 4
...
Slika: Whitten et.al, Systems Analysis and Design Methods, McGraw-Hill Higher Education, 2000
Event 1
Event 4 Event n
The System
Event n-1
2
Event 3
Event 5
Function 1
Function 2
...
Function n
Event 1
Event 2
Event 3
Event 4
Event 5
...
Event n-2
Event n-1
Event n
2.3
...
2.1 2.4
...
Event 1
...
Event 5
...
Event n
2.2
273
274
Tablica dogaaja u sustavu

Dogaaj
Dogaaj zbog kojeg sustav obavlja odreene aktivnosti
Primjer: tablica dogaaja i procesa

Doga aj 1. Kupac eli provjeriti raspoloivost artikla Okida Izvor Aktivnosti Provjeriti raspoloivost Odgovor Podaci o raspoloivosti Real-time veza Potvrda narudbe Podaci o narudbi Transakcija Odredite Kupac Kreditni ured Kupac Otpremnitvo Banka Upit o Kupac proizvodu
Okida
Kako sustav zna da se dogodio dogaaj? Za vanjske dogaaje, ovo su podaci koji ulaze u sustav. Za privremene dogaaje, odreivanje toke u vremenu koja pokree rad sustava.
2. Narudba
Nova narudba
Kupac
Stvoriti novu narudbu
Izvor
Za vanjski dogaaj, vanjski uzronik, tj. izvor podataka koji ulaze u sustav
4. Vrijeme za zatraiti izvjetaje o poslovanju 5. Vrijeme za izraditi izvjetaje o transakcijama 6. Kupac, ili uprava, eli provjeriti stanje narudbe Kraj tjedna, mjeseca, godine Kraj dana Napraviti izvjetaje Izvjetaji Uprava
Aktivnosti
to sustav radi u sluaju dogaaja?
Odgovor
Koji/kakav izlaz (ako postoji) izlazi iz sustava
Odredite
Kamo ide odgovor?
Napraviti Izvjetaji o izvjetaje o Ra unovodstvo transakcijama transakcijama Uprava Ispitati stanje ili narudbe Kupac Podaci o narudbi Uprava ili Kupac
276
Primjeri:
\Modeliranje\StrukturiranaAnalizaDizajn
275
Upit o stanju narudbe
Matrica Entiteti/Dogaaji
Matrica Entiteti/Dogaaji Primjer: pojednostavnjena
Entity/Event Matrix, Event/Enquiry, rezervacija sobe u hotelu Proljee Entity Access Matrix pogled na sustav usmjeren dogaajima (event oriented view) matrica sadri: dogaaje (retci) Dogaaj/Entitet entitete (stupci) elemente koji prikazuju uinak dogaaja na entitete privremena rezervacija C/M C
rezervacija sobe zaduenje korisnik soba
Stvaranje: C (create) itanje: R (read) - u nekim metodama se ne biljei Auriranje: U (update) ili M (modify) Brisanje: D (delete)
Matrini prikaz modela dogaaja

U primjeni su razliite vrste prikaza, ovisno o metodologiji
matrica entiteti/dogaaji (Entity/Event Matrix), npr. SSADM odnos dogaaja i entiteta: C (create), M (modify), D (delete) matrica funkcije/entiteti (Function/Entity Matrix), npr. IEM odnos obrade i podataka: C (create), R (read), U (update), D (delete) matrica funkcije/dogaaji (Function/Event Matrix), npr. SSM odnos obrade i dogaaja: X (povezanost) ili praznina
provjera dovrenosti: svaki dogaaj mora imati uinak na barem jedan entitet svaki entitet mora imati dogaaj koji ga ita, stvara, mijenja ili brie
potvrda rezervacije opoziv rezervacije dolazak gosta poveanje trokova plaanje usluga arhiviranje rezervacije
C/M
C/M M C/M M M D
Sline matrica moe se iskoristiti za definiranje prava

M C M D M
matrica Korisnik / Proces / X matrica Korisnik / Entitet / CRUD Korisnik pri tome predstavlja grupu korisnika ili ulogu korisnika Ovisno o detaljima ugradnje u fizikom modelu Korisnik moe biti i konkretna osoba
277
278
Primjer: matrica entiteti/dogaaji

Primjeri: \Modeliranje\StrukturiranaAnalizaDizajn
Katalog Provjeriti raspoloivost artikla Stvoriti novu narudbu Aurirati narudbu Provjeriti status narudbe Zabiljeiti ispunjenje narudbe Zabiljeiti istek zaliha Stvoriti povrat narudbe Dati informacije o katalogu Aurirati korisni ki raun Distribuirati promo pakete Prilagodba napla ene cijene Auriranje kataloga Kreiranje posebne promocije Kreiranje novog kataloga Muterija Raspoloiv artikl R CRU RU RU RU RU C RUD R C RUD R RU RU CRU R R RU R C CRUD R RU R R CRUD R R R RU C C RUD RUD Narudba Narueni artikl Transakcija (narudba)
Odreivanje podsustava matricom dogaaja

Primjer, prvi dio matrice procesi/entiteti za jedan stvarni sustav
K3 K54 K55 K38 K30 K39 K5 K31 K40 K7 K32 K41 K8 K42 K14 K63 K36 K50 K37 K46 K53 K12 K26 K61 K60 K13 K6 K29 K52 K15 K22 P9 P6 P10 P11 P12 P8 P32 P44 P37 P22 P20 P1 P4 P3 P36 P48 P45 P18 P16 P7 P24 P30 P25 P29 P28 P33 P19 P14 P38 P50 P52 P51 P47 P46 P31 P15 P49 P26 P13 P27 P21 P17 P2 P5 P35 P34 P41 P42 P39 P40 P43 P23
CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD R R R R R R R R R CRUD R R R R R R R R R R CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD R R R R R R R R R R R R R R R CRUD CRUD CRUD R R R R R R CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD R R R R CRUD CRUD CRUD R R R RU RU RU CRUD CRUD CRUD R R R R CRUD CRUD R R R R R R R R R R R R R R R R R R R R R R CRUD R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R RU RU RU RU RU RU R R R R R R R R R R R R CRUD R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R CRUD CRUD R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R RU R R RU R R R R R R R R R R R R R R CRUD R R R R CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD R R CRUD CRUD CRUD R R R R R R R R R R R R R
R R R R RU R R RU RU RU RU RU RU RU RU RU RU RU RU RU RU RU RU R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R
R R R RU
R RU R
R R
R R R R
R R R R
R R
R R
R R
R R
R R
R R
279
280
Dijagram prijelaza stanja

Dijagram prijelaza stanja (State Transition Diagram)
zasniva se na ideji stroja s konanim brojem stanja (finite state machine), hipotetikom mehanizmu koji u nekom trenutku moe biti u jednom od konano mnogo diskretnih stanja grafiki prikaz promjena stanja, tj vremenski zavisnog ponaanja sustava
Primjer: Stanja zahtjeva

U pripremi: Zahtjevatelj stvara novi zahtjev, pokrenuvi tu funkciju iz nekog drugog dijela sustava Odgoen: Zahtjevatelj je snimio svoj rad (narudbu) kako bi ju dovrio kasnije bez da ju je predao ili otkazao Zaprimljen: Zahtjevatelj je predao svoj zahtjev (narudbu) koji je sustav prihvatio kao valjan Podnesen: vanjski dobavlja je sposoban isporuiti zahtjev i kupac podnosi zahtjev (narudbu) kod vanjskog dobavljaa Ispunjen: zahtjev je zadovoljen bilo da je dostavljen iz zaliha kemijskog laboratorija ili da je dostavljen od strane vanjskog dobavljaa Vraen: dobavlja nije mogao zadovoljiti narudbu i vratio je narudbu uz mogunost kasnije dostave Otkazan: Zahtjevatelj je otkazao primljen zahtjev prije negoli je isporuen ili je kupac otkazao narudbu kod vanjskog dobavljaa prije nego to je dostavio narudbu ili nakon to je dobavlja vratio narudbu uz mogunost kasnije dostave
Elementi prikaza:
stanje kumulativni rezultat ponaanja nekog objekta (pravokutnik, krug ili elipsa) prijelaz promjena stanja uzrokovana nekim dogaajem (usmjerena linija od jednog stanja prema drugom) dogaaj uvjet promjene stanja i akcija koja se obavlja (opis linije prijelaza oblika dogaaj/akcija)
DPS najee opisuje vremenski zavisno ponaanje itavog sustava

manji sustavi mogu se prikazati jednim dijagramom vei sustavi razlau se slino dijagramima toka podataka, pri emu stanje na nekoj razini postaje poetno stanje dijagrama na nioj razini
Primjena
sustavi za rad u stvarnom vremenu (real-time system) jezina analiza (parsing) dizajn korisnikog suelja
Primjer: sustav za rad u stvarnom vremenu

Dijagrami sustava za rad u stvarnom vremenu razlikuju se po tome to sadre posebno stanje "besposlen"
Primjer, Sokomat hotela Proljee ili Bankomat banke Oprosti nam duge nae
A
Izrada zapisa (ustanova) N
Primjer: prijelazi statusa kartica

U zagradama je navedeno tko promjenu smije nainiti.
Izdana Student je diplomirao Pogreni podaci (koristi samo tvrtka za tiskanje) Izgubljena Ponitena zbog promjene JMBG-a Istekao apsolventski rok Nezavrena Oduzeta Ponitena Student je upisao prekid Student se ispisao Oteena Tiskana Ukradena Nestala Ponitena zbog neispravnih podataka Zatraena FER \ Fertalj: Razvoj informacijskih sustava Izdavanje vlasniku (ustanova) A
Slika i potpis (ustanova) Z
Kontrola podataka prije tiska (CAP)
Ispravak pogrenih podataka (ustanova, CAP) Z
prazni hod (idle) neispravna kartica / 'Neispravna
D G
kartica izvaena / 'Umetnite'
I J K
Podaci ispravni (CAP)

Z
Postoje neispravni podaci (CAP) G Y
ispravna kartica / 'Izaberite'
izabran 'Kraj' / 'Hvala, enja' ekanje na izbor
ekanje na vaenje kartice
N O P R S T
Tiskanje kartice (tvrtka za tiskanje) T
Ponovno aktiviranje (ustanova, CAP)

A
obavljen odabir / 'Pokupite'
izvaeno / 'Jo neto?'
U X Y
natoeno
Ponitavanje kartice (ustanova, CAP) D I J K P O S R U
284
Mape dijaloga
Korisniko suelje u mnogim aplikacijama se moe promatrati kao konani automat.
Jedan element suelja (izbornik, radna povrina, komandna linija ili prozor dijaloga) moe biti aktivan u odreenom trenutku. Korisnik moe doi do ogranienog broja drugih elemenata ovisno o akcijama koje poduzima. Broj putanji kojima korisnik moe mijenjati dijaloge je obino vrlo velik, ali je konaan i mogunosti su najee poznate.
Mape dijaloga
Koristi se notacija dijagrama prijelaza stanja
Uvjet koji pokree korisniku navigaciju prikazan kao tekst na strelicama. Postoji nekoliko vrsta pokretakih uvjeta: Korisnika akcija, kao to je pritisak tipke ili klik na link ili gumb dijaloga Podatkovna vrijednost, npr. pogrean unos koji izaziva poruku o pogreci Sistemski uvjet, kao to je signal da je pisa ostao bez papira Kombinacija navedenih, npr. tipkanje opcije iz menija i pritisak na tipku Enter
Mape dijaloga prikazuju sustav na visokoj razini apstrakcije.

Prikazuju elemente dijaloga u sustavu i mogunost navigacije izmeu njih ali nita ne govore o dizajnu zaslona. Korisnici i razvojni tim mogu zajedniki razmatrati dijalog mape kako bi postigli zajedniko gledite o tome kakva treba biti korisnikova interakcija sa sustavom kako bi postigao odreeni zadatak. Dijalog mape su takoer korisne kod modeliranja vizualne arhitekture web sjedita, pa se ponekad tako i nazivaju (eng. site maps). Navigacijski linkovi na sjeditu pojavljuju se kao tranzicije na dijalog mapi.
Radi pojednostavnjenja mogu se izostaviti neke openite funkcije, npr.

pritiskanje tipke F1 da bi se dobila pomo standardni navigacijski linkovi koji se pojavljuju na svakoj stranici.
Pri analizi mapa predstavlja interakciju na konceptualnoj razini

Konkretna ugradnja moe biti drugaija. Primjer: Korisnik inicira model koritenja odabirom opcije "zatrai kemikaliju" iz glavnog izbornika a to se ne vidi na dijagramu. Nije nuno prikazivati detalje (npr. Potvrdu otkazivanja itavog zahtjeva) Kljuno je da korisnik i razvojnik jednako razumiju opisanu funkcionalnost.
285
286
Mape dijaloga mogu prikazati Alternativne putove (npr. naruiti od dobavljaa) koji odstupaju od uobiajenog puta (kemikalija iz zaliha). Opcionalne putove (npr. Pregled povijesti pakiranja) Potvrda da je Posebna stanja (npr, poruke o pogrekama) otkai zahtijev
Primjer: mapa dijaloga
zatrai cijeli kemikaliju zahtjev
primljen
podnijeti zahtjev za >0 kemikalija Trenutna lista zahtjeva odaberi dobavljaa i dodaj u listu otkai dodavanje kemikalije
Strukturirani dizajn programa
brisanje kemikalije sa trenutne liste zahtjeva
zahtijevanje druge kemikalije
otkai zahtjev za novom kemikalijom
odaberi pakiranje i dodaj u listu otkai dodavanje nove kemikalije u listu
Prikaz poruke o pogreci
pogrena ifra kemikalije OK
Unesite ifru zahtijevane kemikalije
zatrai kemikaliju od dobavljaa zatrai razliitu kemikaliju
Lista dobavljaa za kemikaliju
zatrai kemikaliju zatrai razliitu iz zaliha kemikaliju laboratorija
Lista pakiranja u zalihama kemijskog laboratorija
zatrai pogledati povijest pakiranja povratak
Povijest pakiranja
287
Strukturirani dizajn
Strukturna karta
Strukturna karta (Structure Chart)
modeliranje programske podrke na temelju dijagrama toka podataka dijagram toka podataka prikazuje TO treba postii strukturnom kartom izraava se KAKO ostvariti zahtjeve prikaz hijerarhije programskih modula koji ukljuuje prijenos podataka i upravljanja izmeu razliitih razina obrade prikaz slijedne, ponavljajue i uvjetne obrade elementi prikaza:
podatak (dat a couple)
f unkcija slijed indikator (control couple)
poziv ugraena f unkcija (modul) iteracija selekcija
289
290
Strukturna karta
Primjer, izvjee o poslovanju tvrtke Tajkun & ortaci
datum Sustav izvjea o prodaji zbir zbir Uzmi datum Zapii izvjee Ispii zbir
Transformacijska analiza
Transformacijska analiza (transform analysis)
analiza promjene/pretvorbe podataka primjenjiva na sustave koji imaju strukturu oblika ulazsredite-izlaz, tj. aplikacije s jasno raspoznatljivim ulazima, sredinjom obradom i izlazima, koji se daju prikazati linearnim tokom podataka
sredite
1 C
izlazi
2 I 3
datum
zbir
zbir
ulazi
System
C C I
datum datum
vrijednost EOF vrijednost
zbir
Uspjeh
Katastrofa
Struktura dizajna prikladna za ovakve sustave sastoji se od tri odgovarajua elementa (ulaz, obrada, izlaz), tj. podsustava:
Get C, koji pribavlja podatak C C I, koji obradom pretvara podatak C u podatak I Put I, koji ispisuje rezultat I
Zapii zaglavlje datum EOF itaj podatak

Zapii redak podatak podatak Pii podatak
Raunaj zbir
Get C
CI
Put I
1
3
292
Transakcijska analiza
Transakcijska analiza (transaction analysis)
analiza izvrenja/obavljanja obrade primjenjuje se na sustave sa jasno raspoznatljivim sreditima izvrenja (transaction centre), tj. sustave u kojima se donosi odluka o tome koji e se proces koristiti za pretvorbu ulaza u izlaze (npr. interaktivne aplikacije) ulaz se usmjerava nekom od modula obrade, a pojedini izlazi se kasnije koriste u daljnjoj obradi
Umreeni procesi
Ostale strukture
sustavi koji nisu ni transformacijski niti transakcijski obrauju se na poseban nain najee se oblikuju plonim razlaganjem glavnog procesa u sastavne procese nadreeni proces mora pribaviti sve ulaze potrebne za obavljanje pojedinih podreenih procesa te prikupiti i uvati proizvedene rezultate obrade
Primjer,
sredite zaprima ulaz B, koji se usmjerava (kao B1, B2 ili B3) u odgovarajui proces (3, 4 ili 5) rezultirajui podatak (C1, C2 ili C3) koristi se kao izlazni tok C.
3 B1 2 B B3 5 C1 C2 B2 4 C3 6 C
BC
B3 B1 C1 B2 C3 C2
Primjer
strukturna karta za DTP razloen plonom dekompozicijom
D C 7 E F 9 H 8 G 10 I
E C F F G E H I D
CI
7
5
10
9
294
Sloeni sustavi
Stvarni sustavi primjena kombinacija osnovnih postupaka
3 B1 2 B 1 A Get C
E C B B C F F G E H I I D
Primjeri
\Modeliranje\StrukturiranaAnalizaDizajn
primjer strukturiranog oblikovanja
C1 C2 6 C3 C 7
D F E
G 10 I 11 J 12 K
B2 B3
4 5
C
\Modeliranje\KakoRazmiljajuPoslovniLjudi
Izvor: Howard Smith - The Third Wave of Business Process Management
System
I C I
CI
Put I
H
7 2 and 6: BC
B B1 C1 B2
10
J
Get B
A A
8
B3 C3 C2
11: I J
J K
Put J
K
Get A
1: A B
12: J K
Put K
Kako razmiljaju poslovni ljudi Stranka Upravljanje narudbama Skladite Proizvodnja Isporuka
Slanje narudbe
Zaprimanje narudbe Provjera kredita
Provjera skladita Lista artikala Provjera artikla PI Raspoloivost artikla Artikl nije raspoloiv Da Zahtjev za proizvodnju
Zahtjev za proizvodnju Provjera dijelova Nedostajui dijelovi Narudba dijelova
Zahtjev za isporuku
Odobrenje narudbe Da Ne Odbijanje narudbe ON OD Ne
Provjera valjanosti Da Odobrenje narudbe
Definiranje puta Prijenosna lista Definiranje prijevoznika Podizanje isporuke
Odobrenje narudbe
Odbijanje narudbe
ZP
Ne
Provjera skladita Raspoloivost artikla Raspoloivost narudbe Potvrda narudbe Da Potvrda narudbe RN Raspoloivost narudbe Potvrda narudbe Ne Obustava narudbe CO PN Zahtjev za isporuku Definiranje prijevoznika Datum isproruke DI Datum isporuke Obustava narudbe Da Potvrda narudbe
Datum raspoloivosti dijelova Raspored proizvodnje IS Isporuka
, ???
Isporuka RA
Valjano pravilo Yes Prijenosna lista
Ne
Raspoloivost artikla ZI
Narudba za isporuku
Definiranje prijevoznika DP
297
Modeliranje podataka
Modeliranje podataka (Data modeling)
tehnika organiziranja i dokumentiranja podataka sustava sinonimi: modeliranje baze podataka (podaci se najee pohranjuju u BP) modeliranje informacija (openitije)
(Konceptualno) Modeliranje podataka
(po mnogima) najvanija tehnika oblikovanja

podaci su resurs koji se dijeli izmeu veeg broja procesa strukture podataka i njihova svojstva su trajniji i stabilniji od procesa modeliranje podataka zavrava bre nego modeliranje procesa modeli podataka bre se pribliavaju rezultatu nego modeli procesa modeli podataka su bitno manji od modela procesa i objektnih modela modeli podataka postojeeg i budueg sustava meusobno su sliniji nego modeli procesa postojeeg i budueg sustava, ili ih je lake preoblikovati, pa se manje posla baca dobra komunikacija s korisnicima, utvrivanje nazivlja lake odreivanje definiranje dosega projekta ...
5/13
Vrste modela
Konceptualni
najee model entiteti-veze poslovni pogled na podatke zanemaruje nekritine detalje uglavnom sadri znaajne entitete i veze "vie prema vie" moe sadravati vane atribute i kljueve
Model entiteti-veze
Model entiteti-veze
model baze podataka koji opisuje entitete (pojavnosti, instance), njihove atribute i veze. "The entity-relationship model: toward a unified view of data", P.P. Chen, ACM Transactions on Database Systems 1:1 pp 9-36, 1976. za prikaz se koristi dijagram entiteti-veze (Entity-Relationship Diagram, ERD naziva se jo i dijagram objekti-veze (izbjegavati!) postoje razliite notacije, npr. Chen, Martin, ... ne postoje jednoznani standardi postupka izrade
0,1 Mjesto Zanimanj e NadJed 1,1 1,N PodJed 0,N Stanuj e Osoba 1,N Zaposlen 1,N Or gJed 0,M Proizvodi Pri pada
Logiki
relacijski (najee), postrelacijski, objektno-relacijski uobiajeno podlijee relacijskoj teoriji podrazumijeva potpuno normalizirane entitete (samo veze jedan prema vie) potpuno definirani atributi i njihove domene (logike tipove vrijednosti) potpuno definirani kljuevi
0,N
Fiziki
logiki model preveden u model model podataka za odabrani SUBP ukljuuje stvarne tipove, indekse, poglede, ugradnju referencijskog integriteta te fizike parametre (podatkovni prostor, volumetrija)
NS 0,1
1,1 0,N 1,1 Racun 1,1 Proi zvod 1,1 1,1 RacStRac OdnosiSeNa ES Di o 0,N Cj elina
0,M
Sastav
0,N 0,1 0,1
0,N
1,N 0,N
Djel atni k
Suradni k
StavkaRacuna
Igl a
Avion
302
Entiteti
Entitet (entity)
Stvar koja se moe zasebno identificirati [P. Chen, 1976] Logika reprezentacija podatka [C.Finkelstein, 1989] Bilo to o emu pohranjujemo informaciju [J.Martin, 1989]
Atributi
Atribut - predstavlja neko obiljeje, znaajku entiteta
sinonimi: svojstvo (property), element, polje (field) po vrijednostima koje predstavljaju, atributi mogu biti: jednostavni atributi (simple attribute) - vrijednost atributa je pojedinani podatak,
primjer: Prezime, Ime
Primjeri entiteta:
osoba, npr. Kit Karson objekt, npr. video zapis Prohujalo s vihorom apstraktni pojam, npr. hrvatski jezik ili iskustvo (poznavanje jezika) ustanova (FER), organizacija (Hotel Proljee) ili organizacijska cjelina (Ured za istraivanje ruda i gubljenje vremena) dogaaj (situacija, stanje) - npr. roenje, kolovanje, zaposlenje, smrt povezanost razliitih objekata stvarnog svijeta, npr. srodstvo
sloeni, sastavljeni atributi (compound/composite/concatenated attribute, data structure) - vrijednost je ureena n-torka jednostavnih atributa
primjer: datum = (dan, mjesec, godina)
vieznani atributi (multivalued attribute) - atributi s vie vrijednosti istog tipa

primjer: Osoba.Telefon = (TelefonNaPoslu, TelefonKodKuce, MobilniTelefon)
Grupiranje pojedinanih pojava (instanci)

ovisno o metodi skup entiteta (entity set), tip entiteta (entity type), razred entiteta (entity class) moemo poistovjetiti pojam entitet sa skupom entiteta, kada ne razmatramo podatke oznaava se imenicom (u jednini) Osoba, Fakultet
s obzirom na pohranu vrijednosti, atributi mogu biti: atributi pohrane (stored attribute) izvedeni atributi (derived attribute) - vrijednost temeljem vrijednosti drugih atributa
primjer: starost = (DananjiDatum-DatumRoenja)
Tipovi podataka atributa

netehniki (logiki) - opi tipovi koji se koriste u sistem analizi primjeri: broj, datum-vrijeme, znakovni niz, tekst, BLOB tehniki - generiki, koji se mogu preslikati u konkretne tipove, npr. integer, character konkretni tipovi SUPB, npr. char, int, byte (SQLserver)
Kljuevi
Klju (key) ili identifikator
atribut ili skup atributa koji (svojim vrijednostima) jednoznano identificira svaki od entiteta u nekom skupu entiteta mora se sastojati od bar jednog atributa jednostavan klju primjer: OSOBA = @JMBG + Prezime + Ime moe se sastojati od vie atributa sloeni, sastavljeni, ulanani klju primjer: MJESTO = @ifraDrave+@ifraMjesta +... moe postojati vie kandidata za klju primjer: Valuta.ifraValute (385), Valuta.KraticaValute (HRK) nakon odabira (primarnog) kljua, ostali mogui kljuevi postaju alternativni kljuevi (alternate key) Primjer,
Elementi dijagrama Entiteti-Veze

Atributi mogu imati kardinalnost
0, pozitivni cijeli broj ili znak (npr. N) entiteti Mjesto i Osoba primarni klju Mjesto.SifMjesta i strani klju Mjesto.SifMjesta izvedeni atribut Staz vieznani atribut Telefon
Sastavljeni atributi imaju atribute

primjer, Adresa
SifMjesta
PostBr
NazMjesta
IdOsobe
Prezime 1
Ime
Ulica
Mjesto
Osoba
Adresa
Strani klju (foreign key)

skup atributa ije vrijednosti odgovaraju vrijednostima kljua drugog entiteta primjer: Osoba.SifMjesta odnosi se na Mjesto.SifMjesta
SifMjesta Staz
N
KBr
Telefon
305
306
Veze
Veza (relationship)
pokazuje odnos izmeu entiteta analogno entitetima, pojedinana veza uspostavlja se na razini instanci entiteta, a veze se grupiraju u skupove veza (relationship sets) kada se ne razmatraju instance, pojam veza podrazumijeva skup veza moe izraavati ulogu entiteta koje povezuje imenuje se glagolom ili glagolskom imenicom
Stupanj, tip i kardinalnost veze

Stupanj veze (degree of relationship)
broj entiteta koji sudjeluju u vezi (1, 2, 3, ... N) - unarna veza (refleksivna, rekurzivna, involucijska), binarna, ternarna, ..., n-arna veza
Tip, klasifikacija veze (type of relationship) - odnos entiteta u vezi

jedan-prema-jedan (1:1), jedan-prema-vie (1:N), pri emu mogu postojati paralelne veze vie-prema-vie (M:N)
Modalitet veze (modality) i kardinalnost veze (cardinality) Primjer (veza i uloge)

Osoba STANUJE u Mjestu (Osoba je STANOVNIK Mjesta) u Mjestu STANUJE Osoba (Mjesto je MJESTO STANOVANJA) minimalni i maksimalni broj drugih instanci s kojima se pojava nekog entiteta moe povezati pojednostavnjeno, donja i gornja granica kardinalnosti donja granica (modalitet) moe biti 0, pozitivni cijeli broj ili znak (npr. M)
donja granica = 0 djelomino, neobavezno (optional) pridruivanje donja granica 0 potpuno, obavezno (mandatory) pridruivanje
Mjesto MjestoStan
Stanuje Stanovnik
Osoba
gornja granica (kardinalnost) moe biti pozitivni cijeli broj ili znak (npr. N) veze su dvosmjerne pa se kardinalnost definira za svaku stranu veze stil oznaavanja: donja,gornja kao donja..gornja, pr. 0,N kao 0..N
Binarne i unarne veze

Primjer: binarna veza 1:N
to kada bi kardinalnost mjesta bila 0,1 ?
Spojni entiteti, veze vieg stupnja, veze s podacima

Asocijativni entitet (Gerund)
0,1 NadJed
Primjer: unarna veza 1:N

to kada bi modalitet bio 1 ?
Mjesto
1,1
Stanuje
0,N
Osoba
OrgJed PodJed
Pripada
konkatenirani entitet (concatenated entity), kompozitni entitet (composite entity) binarna veza M:N, npr. Proizvodi ternarna veza ili veza stupnja >3, npr. Zaposlen veza o kojoj se eli pohraniti podatke (veza s opisnim atributima), pr. Sastav
0,N
Primjer, binarna veza M:N

to kada bi kardinalnost s bilo koje strane bila 1,N, odnosno 1,M ?
OrgJed
0,M
Proizvodi
0,N
Proizvod
Zanimanje 0,N
Primjer, unarna veza M:N

0,M
0,M Cjelina Proizvod Sastav Dio BrDijelova
Osoba 0,N 0,N
OrgJed
0,M
Proizvodi
0,N
Proizvod
Cjelina Proizvod Dio 0,N Sastav
Zaposlen
OrgJed
0,N
DatPoc
DatZav
310
309
Agregacija
Agregacija (aggregation) - agregacijska veza
sinonim: agregacijski entitet (aggregate entity) veza koja sudjeluje u vezama s drugim entitetima poimlje se kao apstraktni entitet u nekim metodama oznaava odnos cjelina-dio
Specijalizacija/Generalizacija
Generalizacija/Specijalizacija - takozvana "jest" veza (is a)
odnos nekog entiteta (nadtip) i njegovih posebnosti (podtip) nadtip (supertype) - generalizacija podreenih, sadri zajednike atribute podtip (subtype) - pecijalizacija nadreenog, sadri svojstvene atribute potpunost generalizacije: djelomina ne mora se specijalizirati potpuna mora se specijalizirati specijalizacija moe biti: neekskluzivna - Osoba u isto vrijeme moe biti i Djelatnik i Suradnik ekskluzivna - Proizvod je Igla ili Avion, ali ne istovremeno uvjetovana umirovljenici su samo osobe preko N godina
Osoba 1,1 Proizvod 1,1 ES
N N N
N 1
0,1 Djelatnik
NS
0,N Suradnik
0,1 Igla
0,1 Avion
312
311
Jaki i slabi entiteti, Identifikacijska veza

Jaki entitet
postoji samostalno, nezavisan/dominantan entitet, pr. Mjesto zanimljivo, to su uglavnom ifrarnici
Proirena Chenova notacija (1)

Potpuna participacija svaki entitet mora sudjelovati u barem jednoj vezi
Slabi entitet (weak entity)

postoji samo ako postoji jaki entitet u vezi veina baze je slaba ! entitet moe biti slab uslijed vie veza slabost/jakost razmatrati lokalno
Identifikacijska veza
definira identifikacijski slabi entitet - entitet koji se ne identificira samostalno, tj. entitet koji nema vlastiti klju, nego se njegov klju tvori od kljua jakog entiteta i (opcionalno) vlastitog atributa (deskriptora), pr. StavkaRacuna Primjer, identifikacijska veza i identifikacijski slab entitet
1,1 Racu n Ra cStRac 1,N Stavka Ra cun a
Specijalizacije su u pravilu identifikacijski slabe

Primjer, podtipovi: Djelatnik, Suradnik, Igla, Avion
Komentirati kardinalnost primjera

Proirena Chenova notacija (2)

Potpuna generalizacija entitet se mora specijalizirati
ERD notacija - Chen

Primjer, dijagram modela poduzea (Chen)
0,1 Mjesto Zanimanj e NadJed 1,1 1,N PodJed 0,N Stanuj e Osoba 1,N Zaposlen 1,N Or gJed 0,M Proizvodi Pri pada
0,N
1,1 0,N 1,1 Racun 1,1 Proi zvod NS 1,1 1,1 RacStRac OdnosiSeNa ES Di o 0,N Cj elina
0,M
Sastav
0,N 0,1 0,1
0,1
0,N
1,N 0,N
Djel atni k
Suradni k
StavkaRacuna
Igl a
Avion
315
316
ERD notacija - Martin

Primjer, dijagram modela poduzea (Martin), doseg, podsustavi
Mjesto Zanimanj e
Izrada ERD analizom izjava korisnika

"Kemiar ili lan osoblja kemijskog laboratorija moe podnijeti zahtjev za jednom ili vie kemikalija. Zahtjev moe biti udovoljen ili dostavom pakiranja kemikalije koja se ve nalazila na zalihi kemijskog laboratorija ili upuivanjem narudbe za novim pakiranjem kemikalije od vanjskog dobavljaa. Osoba koja upuuje zahtjev mora imati mogunost pretraivanja kataloga kemikalija vanjskog dobavljaa dok sastavlja narudbu. Sustav mora pratiti status svakog zahtjeva za kemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Takoer, mora pratiti povijest svakog pakiranja kemikalija od trena kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbaen."
Pri pada Stanuj e Osoba Zaposlen Or gJed Sastav
Proi zvod Racun
Djel atni k
Suradni k
StavkaRacuna
Igl a
Avion
Primjer: hijerarhija specijalizacija
Partner
ISA
Razvoj modela podataka

Osoba
ISA
Tvrtka
Djelatnik
ISA
Korisnik
319

Globalni model podataka (enterprise data model) Model konteksta podataka (context data model) Model s definiranim kljuevima (key-based data model) Model s potpuno odreenim atributima (fully attributed data model) Potpuno opisani model (fully described data model)
Konceptualni model podataka

Globalni model podataka
podatkovni model poduzea (enterprise data model) u fazi planiranja konceptualni model entiteti-veze koji najee sadri neodreene veze i nerazraene kategorije podataka, a pojedine veze mogu i nedostajati definira mogui doseg sustava i ukupne informacijske potrebe Primjer: Analiza\IdejnoSljeme
Konceptualni model postane logiki u trenutku kada sadri samo veze 1:N s definiranim stranim kljuevima ili se takve mogu jednoznano generirati
Odluke o konanom dizajnu donose se tijekom pretvorbe konceptualnog modela u relacijski Logiko modeliranje podataka
Model konteksta podataka

na poetku analize konceptualni model koji sadri samo one entitete koji e biti obuhvaeni tehnikim rjeenjem aplikacijski model podataka rafinira doseg bez detalja o entitetima ili detalja o poslovnim pravilima ERD s entitetima i vezama,bez atributa ili samo s osnovnim atributima uz obine veze tipa 1:N sadri veze vieg stupnja i specijalizacije
321
322
Primjer: konceptualni model konteksta

VrstaOrgJed ifrarnik vrsta org. jedinica (npr. uprava, odjel, odsjek, PJ, itd.) Stranka Fizi ka ili pravna osoba TipStranke TipStranke Kontakt Telefoni, Mobiteli, Email, URL, Fax itd. OrgJedinica Organizacijska jedinica (npr. Ministarstvo, Odjel, Odsjek, Podru na jedinica) Osoba Fizi ka osoba Djelatnik Fizi ka osoba koja je dio sustava
Prijelaz prema logikim modelima

Model s definiranim kljuevima
eliminacija neodreenih veza (veze vieg stupnja, veze s atributima, agregacije) i njihovo nadomjetanje asocijativnim entitetima odreivanje kljueva (primarnih, alternativnih, stranih) ako se PK ne moe odrediti, moda se ne radi o skupu entiteta preciziranje kardinalnosti veza definiranje generalizacijskih hijerarhija odreivanje specijalizacija, tj. podtipova entiteta, npr. Igla, Avion definiranje klasifikacijskog atributa nadtipa (diskriminator podtipa)
npr. Proizvod.TipProizvoda { Igla, Avion }
Zanimanje Drzava ifrarnik drava Obavljanje srodnih poslova odreene struke, kao i drugih odgovaraju ih poslova
Zupanija Jedinica podru ne (regionalne) samouprave
Model s definiranim atributima

dodavanje preostalih opisnih atributa odreivanje podskupova podataka definiranje domena, logikih tipova podataka i standardnih vrijednosti atributa
Mjesto Jedinica lokalne samouprave (op ina ili grad) RadnoMjesto Funkcija zaposlenika prema pravilniku o unutranjem redu
323
324
Stranka VrstaOrgJed IdStranke NazStranke TipStranke TipStranke Kontakt IdOsobe (FK) VrstaKontakta TipStranke TekstKontakta Zanimanje
Primjer: Model s definiranim kljuevima

VrstaOrgJed TipOrgJedinice TipStranke Stranka IdStranke TipStranke Zanimanje IdZanimanja OdgovornaOsoba OrgJedinica IdOrgJedinice (FK) Osoba IdOsobe (FK) NadJedinica Ustanova MjestoRodjenja DrzavaRodjenja Drzava SifDrzave Mjesto IdMjesta NadCjelina RadnoMjesto IdRadnogMjesta
TipOrgJedinice OpisOrgJedinice
Kontakt IdOsobe (FK) VrstaKontakta
Primjer: Model s definiranim atributima

OrgJedinica IdOrgJedinice (FK) NazOrgJedinice (IE1.1) MBR (IE2.1) KratOrgJedinice TipOrgJedinice (FK) MjOrgJedinice (FK) AdrOrgjedinice OpisOrgJedinice IdOdgovorneOsobe (FK) IdNadJedinice (FK) IdUstanove (FK) Osoba IdOsobe (FK) JMBG (IE1.1) Ime (IE3.1) Prezime (IE2.1) Roditelj DatRodjenja MjRodjenja (FK) DrzRodjenja (FK) MjPrebivalista (FK) AdrStanovanja SifZanimanja (FK) (IE6.2) IdOrgJedinice (FK) OsobniDokument
IdZanimanja NazZanimanja (IE1.1) KratZanimanja
Djelatnik IdDjelatnika (FK) SifDjelatnika BrojIskaznice Korisnik Zaporka IdStruke (FK) SifSpreme (FK) Svjedodzba IdZvanja (FK) DrzavniIspit StrucniIspit DatPrvogZaposlenja StazUkupno DatZaposlenjaMZOPU StazMZOPU NapomDjelatnik IdRadnogMjesta (FK)
OdgovornaOsoba
DrzavaRodjenja NadJedinica
MjestoPrebivalista Djelatnik IdDjelatnika (FK) SredisteZupanije Zupanija SifZupanije
Ustanova Drzava SifDrzave
MjestoRodjenja Mjesto IdMjesta
MjestoPrebivalista
NazDrzave (IE1.1) KratDrzave
NazMjesta (IE2.1) TipMjesta PostBr SifDrzave (FK) StariNazMjesta SifMjesta IdNadCjeline (FK) NadCjelina RadnoMjesto IdRadnogMjesta IdOrgJedinice (FK) NazRadnogMjesta KratRadnogMjesta BrIzvrsitelja Popunjeno IdSluzbenMjesta (FK) Poslovi Uvjeti
SredisteZupanije
Zupanija SifZupanije NazZupanije (IE1.1) IdSredistaZupanije (FK)
326
Dokumentiranje i konverzija modela entiteti-veze

Potpuno opisani model
potpuni opis atributa, logikih tipova podataka i standardnih vrijednosti dodatni opisi: prava pristupa podacima, ... vremenski najzahtjevniji zadatak, uobiajeno se provodi na kraju, ali moe zapoeti usporedno s izradom modela zasnovanog na kljuevima ili definiranjem opisnih atributa
Logiko modeliranje podataka
Daljnja konverzija modela

Pretvorba modela entiteti-veze u relacijski model podataka Fiziko oblikovanje podataka faza dizajna konverzija logikog u fiziki model (shema baze podataka) normalizacija i prilagodba uslijed tehnikih ogranienja i performanci
327
Pretvorba modela E-V u relacijski model

Entiteti
entitet (skup entiteta) relacija, npr. Mjesto, Osoba
Pretvorba vieznanih atributa

vieznani atribut skup odgovarajuih atributa, npr. Osoba.Telefon Osoba.TelefonNaPoslu, Osoba.TelefonKodKuce, Osoba.MobilniTelefon ili slabi entitet, npr. Osoba.Telefon Telefon (IdOsobe, VrstaTelefona, BrojTelefona)
Osob a
1,1 0,N Telefon
Atributi
kardinalnost 0 opcionalna vrijednost (null) kardinalnost 1 zahtijevana vrijednost (not null) kardinalnost N vieznani atribut (npr. Osoba.Telefon) atribut atribut, npr. Osoba.Prezime izvedeni atribut atribut pohrane ili se izostavlja, npr. Osoba.Staz sloeni atribut atribut (grupiranjem), npr. (dan, mjesec, godina) datum
Osob a IdOsob e Prezim e Im e Adres a DatRo d Staz
IdOsob e Prezim e Im e Te lefo nNaPosl u Tele fonKo dKuce Mobil niTe lefo n Adres a DatRo d Staz
Osoba
Te lefo n VrstaTel efon a Bro jTel efon a
330
Pretvorba kljueva
Kljuevi
klju primarni klju, npr. Osoba.IdOsobe, Mjesto.SifMjesta alternativni klju indeks nad jedinstvenim vrijednostima (unique index) + oznaka zahtijevane vrijednosti (not null), npr. Mjesto.PostBr
Pretvorba binarnih veza

Binarna veza 1:N strani klju
egzistencijalni slabi entitet obini strani klju npr. Stanuje Osoba.SifMjesta, Pripada OrgJed.SifNadJed, RacunOsoba Racun.SifOsobe
Oso baSKlj uce m IdOsob e Prezim e Im e Adres a DatRo d Staz
Mjesto Si fMjesta PostBr <AK> NazMjesta
Mjesto SifMjesta PostBr <A K> NazMjesta
O soba IdOsobe Prezime Ime SifMjesta <FK1> Adresa DarRod Staz
O rgJed SifOrgJed NazO rgJed SifNadJed <F K1>
Osoba IdOsobe Prezi me Ime SifMjesta <FK1> Adresa Da rRod Staz
Ra cun BrRa c Da tRac IdOsobe <FK> IznosRac
331
332
Pretvorba identifikacijskih veza
1,1 Racu n Ra cStRac
1,N Stavka Ra cun a
Pretvorba identifikacijskih veza (2)

Spoj prema vrsti telefona ne treba postojati
1,1 Osoba 0,N Telefon
identifikacijski slabi entitet nasljeuje klju jakog entiteta spojni klju (compound key), npr. StavkaRacuna (BrRacuna, SifProizvoda, JedCijena, Kolicina)
ili
kompozitni klju (composite key), npr. StavkaRacuna (BrRacuna, RbrStRac, SifProizvoda, JedCij, Kolicina)
Racu n BrRac DatRac IdOsobe <FK> IznosRac StavkaRac BrRac <FK> Si fProizvoda <FK> Jed Ci j Koli cin a Pro izvo d SifProi zvod a NazProi zvod a Je dCijen a TipProi zvod a
Telefon IdOsobe < FK> VrstaTelefona BrojTelefona
Stavka Ra cun a BrRac <FK> RbrStRac Si fProizvoda <FK> Je dCijen a Koli cin a
Pretvorba nespecifinih veza

Nespecifine veze asocijativni entitet + n binarnih veza 1:N
klju asocijativnog entiteta = unija kljueva entiteta spojenih vezom odreivanje ostalih kljunih atributa, ako nije bilo obavljeno ranije Zanimanje primjer: Zaposlen, Proizvodi, Sastav SifZanim
NazZanim
OrgJed 0,M Proizvodi 0,N Proizvod
Pretvorba specijalizacija
Specijalizacija nadtipa u n podtipova n binarnih veza
nadtip (jaki) entitet, kojemu se po potrebi odreuje klasifikacijski atribut, npr. Proizvod.TipProizvoda podtip (identifikacijski) slabi entitet, npr. Igla, Avion, Djelatnik, Suradnik
Da li i kada koristiti klasifikacijski atribut ?

O soba IdOsobe Prezime Ime SifMjesta < FK1> Adresa DarRod Staz Zaposlen IdOsobe <F K1> SifOrgJed < FK2> SifZanim <FK3> DatPoc DatZav KoefPlace
Osoba
Zanimanje 1,N 1,N 1,N
O rgJed SifOrgJed NazO rgJed SifNadJed < FK1>
1,1 NS
0,1 Djelatnik
0,N Suradnik
Osoba
Zaposlen
OrgJed
Proizvod 1,1 ES
0,1 Igla
0,1 Avion
Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda
DatPoc
DatZav
0,M Cjelina Proizvod Dio Sastav BrDijelova
Sastav SifProizvoda <FK1> SifDijela <F K2> BrDijelova
Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda
Proizvodi SifOrgJed < FK1> SifProizvoda <FK2>
Djelatnik IdOsobe <FK1> BrRadKnj BrTekRac
Suradnik IdOsobe <FK> BrUgovora BrZiroRac UvjetiSuradnje
Igla SifProizvoda <FK> Duljina Promjer
Avion SifProizvoda <FK> BrSjedala DoletKM
FER \ Fertalj:0,N Razvoj informacijskih sustava
335
336
Pretvorba ostalih binarnih veza

Binarna veza 1,1:0,1 i binarna veza 1,1:1,1 strani klju
identifikacijski slabi entitet bez deskriptora
Mjesto SifMjesta PostBr <AK> NazMjesta
Zanimanje SifZani m NazZani m
Osoba IdOsobe Pr ezime Ime SifMjesta <FK1> Adresa DarRod Staz
Zaposlen IdOsobe <FK1> Si fOrgJed <FK2> SifZanim <FK3> DatPoc DatZav KoefPlace
OrgJed SifOrgJed NazOrgJed SifNadJed <FK1>
Proizvodi Si fOrgJed <FK1> SifPr oizvoda <FK2>
Osoba PK IdOsobe Prezime Ime PK,FK2
Slika IdOsobe SlikaOsobe

Dj elatnik IdOsobe <FK1> BrRadKnj BrTekRac Suradnik IdOsobe <FK> BrUgovora BrZiroRac Uvj etiSuradnje
Racun BrRac DatRac IdOsobe <FK> IznosRac
StavkaRac BrRac SifProizvoda <FK> JedCij Kolicina
Pr oizvod SifProizvoda NazProizvoda JedCijena Ti pProizvoda
Sastav SifPr oizvoda <FK1> SifDij ela <FK2> BrDijelova
337
Igla SifProizvoda <FK> Duljina Promj er
Avion SifProizvoda <FK> BrSjedala DoletKM
338
Preporuke za izradu modela podataka

Sinkronizacija s modelom procesa
spremita podataka u modelu procesa su entiteti u modelu podataka
Uklanjanje veza koje se daju izvesti iz drugih ?

DrzavaOsoba Osoba IdOsobe Prezime Ime IdDrzave (FK) IdMjesta (FK) MjestoOsoba Mjesto IdDrzave (FK) IdMjesta NazMjesta PostBr DrzavaMjesto Drzava IdDrzave NazDrzave KratDrzave
Provjera modela
pripaziti na sinonime (razliite nazive istih objekata) pripaziti na homonime (jednake nazive razliitih objekata) provjeriti sumnjive i redundantne veze i po potrebi ih ukloniti (oprez!) uklanjanje neke od paralelnih veza uklanjanje veza koje se daju izvesti iz drugih (tzv. trijade) - pripaziti na kardinalnost veza u lancu ukloniti balansirane veze 1,1:1,1 (ukoliko je mogue!) pripaziti na nebalansirane veze 0,1:1,1 (zavisnost entiteta) cirkularne reference izbaciti izvedene atribute mogui gubitak informacije o potrebnim izvedenim/izraunatim poljima
DrzavaOsoba Osoba IdOsobe Prezime Ime IdDrzave (FK) IdMjesta (FK) MjestoOsoba Mjesto IdDrzave (FK) IdMjesta NazMjesta PostBr DrzavaMjesto
Drzava IdDrzave NazDrzave KratDrzave
Osoba
OID Ime prezime Drava Mjesto Enter Text Enter Text Id. drave Id. mjesta Naziv drave Naziv mjesta
340
339
Problem paralelnih i cirkularnih veza - ukloniti?

primjer: Zupanija 1:N Mjesto i Zupanija 1:1 MjestoSrediste slino: OrgJedinica 1:N Djelatnik i OrgJedinica 1:1 DjelatnikUpravitelj problem: zahtijevanost vrijednosti stranih kljueva problem: realizacija veze 1:1, redundantna sredita upanija
Mjesto IdMjesta NazMjesta (IE2.1) TipMjesta PostBr SifDrzave (FK) StariNazMjesta SifMjesta SifZupanije (FK) IdNadCjeline (FK) SredisteZupanije Zupanija SifZupanije ZupanijaMjesto NazZupanije (IE1.1) IdSredistaZupanije (FK)
Balansirane i nebalansirane binarne veze

Udruivanje u zajedniku tablicu
Binarna veza 1,1:1,1 slika NOT NULL Binarna veza 1,1:0,1 slika NULL
Razlozi za udruivanje
jednostavniji dohvat podataka ubrzanje upita
Osoba PK IdOsobe Prezime Ime PK,FK2
Slika IdOsobe SlikaOsobe
Razlozi za razdvajanje
NadCjelina
uteda diskovnog prostora utjecaj na fiziki raspored podatka tablice u vezi 1:1 s prevelikim brojem stranih kljueva
341
342
Za sladokusce: konceptualni UML model ...
... i model nakon transformacije
343
344
UML ...
... i Object Role Modeling (ORM)
345
346
ifarski sustav
Serijske ifre
brojevi koji se slijedno pridjeljuju svakoj novo dodanoj instanci entiteta u modernim SUBP mogu se generirati uz opcionalna ogranienja primjer: SQL Server IDENTITY [ ( seed , increment ) ]
Blok ifre
ifarski sustav
slino serijskim iframa, s tim da su serijski brojevi grupirani prema znaenju primjer satelitskih TV kanala: 100-199 PAY PER VIEW, 200-299 CABLE CHANNELS, 300-399 SPORT, 400-499 ADULT, 500-599 MUSIC-ONLY, ...
Alfanumerike oznake
Odreivanje kljueva
ogranieni skup znakovnih oznaka, esto kombiniranih s brojevima primjer, oznake drava: HR, DE, IT, SI
Samogovoree ifre (significant position codes)

svaka znamenka ili grupa znamenki opisuje neko svojstvo instance primjer: JMBG, a esto se koriste i u skladinoj evidenciji (dimenzije automobilske gume, elektrine arulje)
Hijerarhijski kodovi
podjela u grupe, podgrupe itd.
348
Primjeri ifrarnika
Primjer, studentska prehrana
Pravilnikom o studentskoj prehrani propisan je status upisa potreban za ostvariranje prava na subvencioniranu prehranu. Npr. mora biti upisan u tekuu akademsku godinu na redovnom studiju ili studiju za osobne potrebe.
ifra statusa R P U V L O Opis statusa redovan studij paralelni studij studij uz rad vanredni studij paralelni studij s pravom prehrane studij za osobne potrebe Pravo prehrane DA NE NE NE DA DA
Primjer jedinstvene ifre

JMBAG je jedinstveni broj u sustavu kojeg student dobiva prilikom upisa na neko visoko uilite i zadrava sve do kraja svog studija.
Ako se isti student upie na dvije ili vie ustanova uvijek zadrava JMBAG koji je dobio na prvoj ustanovi. Djelatnici u ustanovama ne unose taj podatak ve se on automatski generira. JMBAG ima deset znamenki podijeljenih u dvije grupe te kontrolnu znamenku: Prve etiri zanmenke oznaavaju matinu ustanovu vlasnika Sljedeih 5 zanmenki su oznaka vlasnika u ustanovi (matini broj vlasnika ili se generira slijedno) Unutar ustanove JMBG i matini broj (broj indeksa) su takoer jedinstveni.
Primjer, IUCN kriteriji ugroenosti

IdIUCN A A1 A1a A1b ... B1biii B1biv B1bv B1c ... NazIUCN Redukcija populacija (smanjivanje broja jedinki) reverzibilna, razumljiva, obustavljena a-direktno opaanje b-indeks uestalosti iii- podruja, obima i/ili kvalitete stanita iv- broja lokaliteta ili subpopulacija v- broja zrelih individuuma kolebanje NazIUCNENG Reduction in population size reversible AND understood AND ceased a-direct observation b-an index of abundance iii-area, extent and/or quality of habitat iv-number of locations or populations v-number of mature individuals fluctuations
Broj kartice generira se automatski, a u sebi sadri 6 grupa znamenki:

A.
B. C. D. E.
jedinstveni broj u meunarodnom kartinom poslovanju (IIN) uvijek 601983 i prema meunarodnom standardu ISO/IEC 7812 na jedinstven nain identificiraju Studentsku karticu u meunarodnom sustavu kartinog poslovanja oznaka vrste kartice (1 znamenka) npr: 1 - student i 4 - privremena kartica redni broj kartice koju je student dobio (1 znamenka) JMBAG (10 znamenki) Kontrolna znamenka (1 znamenka),
350
349
Izrada ifarskog sustava

Izrada ifarskog sustava
Sustav ifriranja bi trebao biti smislen i prikladan da dodavanje novih ifara bude jednostavno Tamo gdje je to mogue treba preuzeti postojee ifrarnike, od drugih ustanova ili iz postojeih sustava Oznake definirane zakonom ili drugim propisima treba preuzeti i prilagoditi Ostale ifrarnike definirati tako da se naknadno mogu nadograivati Izbjegavati samogovoree ifre
Dizajn baze podataka
Primjer: IPISVU
ifre djelatnika kao redni brojevi, honorarci oblika 9999* dobavljai iz dravne riznice, nadopunjeni vlastitim
Ugaanje i (de)normalizacija
351
Normalizacija
Normalizacija
postupak strukturiranja sheme relacijske baze podataka tako da se ukloni to vie neodreenosti (zalihosti) stupanj normalizacije poveava se od 1NF do 5NF veina dizajnera zaustavlja se na 3NF ili na BCNF (Boyce-Codd NF)
Denormalizacija
Denormalizacija - postupak dovoenja (redukcije) baze podataka u niu normalnu formu
Ne smije se mijeati s pogrekom nedovoenja u jau normalnu formu, tj. loim dizajnom (bad design)
svodi se na ispunjenje tzv "relacijske zakletve" [Finkelstein, 1989]:

Klju 1NF: nema ponavljajuih grupa, definiran primarni klju Cijeli klju 2NF: svi nekljuni atributi u potpunosti zavisni o itavom PK Nita drugo nego klju 3NF: svaki nekljuni atribut je neposredno zavisan samo o PK Tako mi Codd pomogao! (Dr. E. F. Codd - otac relacijske teorije BP) BCNF: ne postoje kompozitni i/ili preklapajui kandidati kljueva
Razlozi za denormalizaciju
poboljanje performanci, npr. ubrzanje upita eliminacijom vanjskih spajanja pad performanci meutim moe biti uzrokovan loim dizajnom, pa bi u tom sluaju denormalizacija mogla dovesti do jo veih problema ! olakanje pristupa nekim podacima koje je komplicirano dohvatiti
Denormalizaciju treba obaviti samo tamo gdje je to stvarno nuno i na takav nain da ne ugroava integritet podataka
Terapija Uinak
Dat Pacijent# Kirurg# Operacije
Ime Pacijenta
Adr Pacijenta
Ime Kirurga
Naz Operacije
odravanje redundancije podataka zahtijeva aplikacijsko upravljanje integritetom podataka koje je "skupo"
353
354
Preporuke za denormalizaciju
Poznavati vlastitu bazu podataka
kako je logiki strukturirana te kako ju aplikacije koriste poznavanje frekvencije obrade podataka
(umjesto denormalizacije)
Postavljanje indeksa
primarni i strani kljuevi implicitno indeksirani postaviti indekse nad najee koritenim poljima, tj poljima koja se koriste za grupiranje, sortiranje ili selekciju uz uvjet (ubrzanje pretraivanja) ako su kljuevi sloeni pretraga e raditi brzo uglavnom po prvom polju po potrebi postaviti dodatne indekse nad preostalim poljima ukloniti indekse prigodom masovnih obrada podataka, pa ih kasnije vratiti
Denormalizirati mjestimino i oprezno

Prije denormalizacije ili za usporedbu probati druge tehnike, primjerice mehanizme izraunatih stupaca koje moderne baze podataka podravaju
Analizirati postupke pristupa podacima

Performance se mogu poboljati paljivim postavljanjem indeksa i optimizacijom upita te forsiranjem odgovarajueg plana njihovog izvrenja
Ubrzanje i optimizacija upita

forsira redoslijed spajanja naveden u upitu primjer: SELECT ... OPTION (FORCE ORDER) primoravanje nekoritenja indeksa primjenom nekodljive funkcije nad poljem nad kojim se uobiajeno koristi indeks primjer: WHERE NULLIF ( polje , ) = uvjet optimizacija za odreeni broj prvih zapisa primjer: SELECT ... OPTION (FAST n_rows) izbjegavanje "ILI" uvjeta
Procijeniti fizike resurse

poveanje ili bolja raspodjela radne memorije dodavanje ili zamjena procesora fiziki raspored smjetaja podataka kvaliteta i optimizacija diskovnog prostora
Uklanjanje nul-vrijednosti
Indeksi ne pomau u sluaju nul-vrijednosti
opisna polja - zahtijevana vrijednost + pretpostavljena vrijednost
Nadomjesni kljuevi (pojednostavnjenje veza)

Nadomjesni (surogatni) kljuevi
ispred kljua sloenog od veeg broja atributa (npr. >= 3) umee klju sa samopoveavajuim vrijednostima (serial), a na originalni klju postavlja se jednoznaan (unique) kompozitni indeks teorijski se ne preporua za asocijativne entitete, koji nasljeuju kljueve svojih roditelja, jer se time gubi smisao identifikacijske veze praktino, nadomjestak treba ugraditi kada je tablica u koju se ugrauje referencirana iz drugih tablica (npr. Placa referencira Zaposlen)
NULL strani kljuevi - vanjska spajanja koja ne koriste indekse

strane kljueve postaviti na NOT NULL definirati posebne vrijednosti u ifrarnicima primjer: 0-nepoznata vrijednost, 999-nepostojea vrijednost
PK UI
FK
357
358
Nadomjesni kljuevi (aplikacijski razlozi)

Problem odabira vrijednosti sloenog stranog kljua u padajuim listama koje evidentiraju samo jednu vrijednost odabranog retka Primjer: Prethodni dokument (RPPP)
"isti" dizajn
Takozvani isti dizajn dosljedna ugradnja nadomjesnog kljua sa samopoveavajuim vrijednostima u sve tablice baze podataka
Prednost: pojednostavnjenje ugradnje Nedostatci: umnoavanje kljueva (nadomjesni primarni, originalni alternativni) nepreglednost izvornog stranog kljua
primjer: umetanje Valuta.IdValute (serial 876) ispred OznValute (string HRK) za posljedicu ima, npr. Dokument.IdValute umjesto Dokument.OznValute
359
360
Uvoenje zalihosti
Dodavanje atributa za vrijednosti koje se daju izraunati iz drugih
atribut pohrane za izvedenu vrijednost koja se moe izraunati agregatnom funkcijom, na primjer: iznos dokumenta kao suma iznosa stavki oznaka zbirnog stanja kada se vrijednosti pojedinih stanja nalaze u tablici s velikim brojem zapisa (stanje skladita, saldo na raunu)
Uvoenje zalihosti (2)

Redundantna vrijednost koja se inae dohvaa sloenim i/ili sporim upitima Primjer, osoba s identifikatorom zadnjeg zaposlenja
moe naravno i drugim operatorima, npr. >= ALL
SELECT Osoba.IdOsobe, IdZaposlen = (SELECT IdZaposlen FROM Zaposlen WHERE Zaposlen.IdOsobe=Osoba.IdOsobe AND DatPocetka = (SELECT Max(DatPocetka) FROM Zaposlen AS Z WHERE Z.IdOsobe=Osoba.IdOsobe)) FROM Osoba
Primjer: iznos dokumenta

aplikacijski, pisanjem programskog koda za izraun (pogledati RPPP) pohranjenom procedurom, po potrebi uz IdDokumenta kao argument uz: WHERE Dokument.IdDokumenta = @IdDokumenta okidaem tablice Stavka uz:
WHERE Dokument.IdDokumenta IN Select (IdDokumenta FROM inserted) UPDATE Dokument SET IznosDokumenta = (SELECT SUM(KolArtikla*JedCijArtikla*(100-PostoRabat)/100) *(1+Dokument.PostoPorez) FROM Stavka WHERE Stavka.IdDokumenta=Dokument.IdDokumenta)
Primjer: redundantni strani klju na vrh hijerarhije

OrgJedinica IdOrgJedinice (FK)
NadJedinica Ustanova
Udruivanje i razdvajanje tablica

Pogledati foliju "Balansirane i nebalansirane binarne veze" Udruivanje tablica (Combined tables) najee onih u vezi 1:1
Baza Firma: Partner+Tvrtka+Osoba Model RIS: Proizvod+Igla+Avion
Meta-modeliranje
Rjenik podataka Meta-baza Primjena meta-modela u izradi aplikacija
363
Meta-modeliranje
Meta-modeliranje = modeliranje podataka o podacima
oznaka "meta" oznaava viu razinu apstrakcije metapodaci su podaci o podacima metamodel je model za opisivanje drugih modela
Pohrana meta-modela
Meta-model model modela Meta-baza baza podataka za pohranu modela
rjenik podataka, repozitorij, riznica
Primjene
Definiranje i odravanje baze podataka Generiranje aplikacija, generiranje podataka, generiranje meta podataka, ... Dinamika prilagodba aplikacije podacima, supstitucija slinih tablica, ...
Rjenik podataka dio SUBP s podacima potrebnim za upravljanje bazama podataka, kao to su definicija strukture, evidencija dozvola, ...
365
366
Shema rjenika SUBP

Primjer: Resursi\SQL2005_Sys_Views.pdf
objects columns indexes constraints ...
Sistemske tablice i objekti

Sistemske tablice
Vrste objekata
SELECT name AS 'ObjectName' , 'ObjectType' = CASE xtype WHEN 'C' THEN 'CHECK' WHEN 'D' THEN 'DEFAULT' WHEN 'F' THEN 'FOREIGNKEY' WHEN 'L' THEN 'Log' WHEN 'FN' THEN 'ScalarFunction' WHEN 'IF' THEN 'InlineTableFunction' WHEN 'P' THEN 'StoredProcedure' WHEN 'PK' THEN 'PRIMARYKEY' WHEN 'RF' THEN 'ReplicationFilterStoredProcedure' WHEN 'S' THEN 'SystemTable' WHEN 'TF' THEN 'TableFunction' WHEN 'TR' THEN 'Trigger' WHEN 'U' THEN 'UserTable' WHEN 'UQ' THEN 'UNIQUEConstraint' WHEN 'V' THEN 'View' WHEN 'X' THEN 'ExtendedStoredProcedure' END FROM sysobjects ORDER BY xtype, name;
Pohranjene procedure za rad s rjenikom

sp_Help ...
367
368
Koritenje rjenika
Primjer:
CREATE PROCEDURE ap_CountALL AS DECLARE @tablename varchar(30) DECLARE @sql varchar(75) DECLARE cu_names CURSOR FOR SELECT name FROM sysobjects WHERE type = 'U' OPEN cu_names FETCH NEXT FROM cu_names INTO @tablename WHILE (@@fetch_status <> -1) BEGIN IF (@@fetch_status <> -2) BEGIN SELECT @sql = 'SELECT ''' + @tablename + ''', COUNT(*) FROM ' + @tablename EXEC (@sql) END FETCH NEXT FROM cu_names INTO @tablename END DEALLOCATE cu_names GO
Model meta-baze generatora aplikacija

Form FormName EntName FormWdth FormHght Referent Field RefFldName DomFldName SN Relationship RelName ShortName ParentAlias InsRule DelRule Key KeyNo KeyName Relationship Field ParFldName ChiFldName SN
Domain DomName TypeName DomLen DomDec Case Just DataMask ValRule Field Required Index Serial Virtual SN
Entity EntName ShortName LongName
Attribute AttName LongName
Key Field SN
Form Field FormName FFldName SN FormFldId VarRow VarCol VarWdth VarHght Label LabRow LabCol LabWdth LabHght
369
370
Primjer generiranja programskog koda

ForEach Ent -> sEnt << CREATE TABLE >> Print sEnt.EntName <<
Meta-modeliranje aplikacije
Prednosti
Pojednostavnjivanje modela Smanjenje broja objekata
(>>
ForEach Fld Where Fld.EntName=sEnt.EntName -> sFld << >> Print sFld.Fldname, " "; ...
Nedostatci
Oteano razumijevanje Problem preslikavanja realnih objekata u objekte metamodela
CREATE TABLE Drzava ( OznDrz CHAR(2) NOT NULL, NazDrz CHAR(25) NOT NULL, PRIMARY KEY (OznDrz) CONSTRAINT pk_drzava ); ...
371
372
Ideja aplikacijskog meta-modeliranja (1)

Poopenje strukture podataka
Org Cje l in a Pro pi s Opi s proc es a Za ko n V rsta do gad j aj a

Primjer, narudba
Narudba MBB-Nabava za osnovno tehniko sredstvo prema poduzeu IMB Br. xxxx od xx.xx.200x. Veza: Ponuda poduzea IMB br. xxxx od xx.xx.200x. Narudbu izradio: Pero Odobrio njegov ef: Ivo Stavke: Raunalo IMB estium: xx kom MBO, CPU, RAM, HDD, CDR, FDD, CASE Monitor 15 xx kom tampa xx kom Skener xx kom
Hi j erarhi j a (Rad no mje sto)
V rsta dok ume nta
P la n
Org ani za ci j ski Pra vni In fo rma ci j ski Fi nan ci j ski Ma te ri j al ni
v ez a Os ob a Os ob a na dok ume ntu Do kum ent Doga dj aj na dok ume ntu Doga dj aj
P ra vn a os ob a
Fi zi ck a os ob a
S ta vk a struk tu ri ran og dok uma nta
Osno vn o P otro sn o Teh ni ck o Fi na nci j sk o Nekretn in a Os tal o V rsta s re ds tv a S voj s tv o
S as ta vn ic a s re ds tv a
S re ds tv o
S voj s tv o s re ds tv a
373
374

Primjer, narudba
MBB Naba va P ra vil ni k o po slo vanj u Opi s pro cesa naruci vanj a Zak on Vrsta d ogadj aj a
Primjena na opisivanje podataka

Primjer: opisivanje podataka
Vrsta
S l jak er, Sef
Narudzb eni ca
P l an
Pravni Fi nan cij ski Mate ri ja lni
Igla Avion
ve za Oso ba MB B, Iv o, P ero, IMB B roj, Datum, P onu da Narudz ba Naruci vanj e
P rav na oso ba
Fi zic ka oso ba
Se sti um Moni tor Stampac S kener Osnov no Teh nic ko Vrsta sre dstva S voj stvo
B52 F117 A300
Vrsta Avion Avion Igla Igla
Svojstvo BrojSjedala Dolet Duljina Promjer
F117 F117
Sjedala Dolet
1 6578
MBO, CP U, RAM, HDD, CDR, FDD
S re dstvo
S voj stvo sre dstva
to s tipovima vrijednosti ?
Praktina primjena meta-modeliranja

Supstitucija veeg broja tablica jednake ili sline strukture
Upit, Ponuda, Narudba, Otpremnica, Primka, Raun, ... sa stavkama
Koris Zaglav SifZag SifMje VrstaDok VrDok StandSifPlac StandSifOtpr StandSifZag StandSifNap Tarifa Mjesto SifMje Napomena SifNap NacinPlac SifPlac TarBroj Otprema SifOtpr Parametar KratParam
Primjer meta-podataka
Definiranje dokumenata, modeliranje poslovnih pravila
Dokument IdDok Partner SifPart SifMje Uplata IdUplate IdDok

Artikl SifArt TarBroj StavkaDok IdDok SifArt
VrDok IdPrethDok SifPart SifOtpr SifPlac SIfZag SifNap
Primjer aplikacije nad meta-modelom

Primjer, prilagodba funkcionalnosti
Primjer: kaskada slinih entiteta

Svi imaju identifikator i naziv, neki imaju opis i objavljeno ... Mogua rjeenje: generalizacija s 9 specijalizacija
Primjer: pojednostavnjenje izrauna
FER \
SELECT Artikl.SifArt, Artikl.NazArt, SUM(StavkaDok.Kolicina*VrstaDok.PredMat) FROM Dokument INNER JOIN VrstaDok ON Dokument.VrDok=VrstaDok.VrDok INNER JOIN StavkaDok ON StavkaDok.IdDok = Dokument.IdDok INNER JOIN Artikl ON StavkaDok.SifArt = Artikl.SifArt WHERE VrstaDok.PredMat <> 0 AND Artikl.IdeSklad <> 0 AND Dokument.DatSklad IS NOT NULL AND Dokument.DatStorno IS NULL 379 BY Artikl.SifArt, Artikl.NazArt Fertalj: RazvojGROUP informacijskih sustava
380
Primjer: kaskada slinih entiteta (2)

Neki entiteti meutim imaju i spojne tablice na narodna imena i sinonime, priblino jednake strukture Rjeenje: jo tri specijalizacije ?
Primjer: kaskada nakon modeliranja

Zadrana rekurzivna hijerarhija, izjednaene strukture, jednom specijalizacijom te spojnim entitetima na narodna imena i sinonime koji e se evidentirati samo za entitete koji ih stvarno imaju
NarodnoImeKlase IdKlase: int IdNarodnogImena: int Kategorija IdKategorije: varchar(2) NazKategorije: varchar(128) RazinaKategorije: smallint
NarodnoIme IdNarodnogImena: int NazNarodnogImena: varchar(128) IdJezika: varchar(2) PodrucjePrimjene: varchar(255) IdReference: int Klasa IdKlase: int NazKlase: varchar(128) NazKlaseHR: varchar(255) KratKlase: varchar(64) Objavljeno: varchar(255) OpisKlase: text IdKategorije: varchar(2) StatPodatka: varchar(2) IdNadKlase: int Vrsta IdVrste: int ImenaLat: varchar(255) KratVrste: varchar(64) OznVrste: varchar(64) Objavljeno: varchar(255) Endem: bit IdAlohtone: varchar(16) OpisVrste: text OpisPodrijetla: varchar(4000) RasprostVrsteWR: varchar(4000) RasprostVrsteEU: varchar(4000) RasprostVrsteHR: varchar(4000) OpisUzrokaUgroze: varchar(4000) OpisMjeraZastite: varchar(4000) LocusTipicus: varchar(4000) OpisIshrane: varchar(4000) OpisRazmnozavanja: varchar(4000) CestocaObilje: varchar(4000) IdUcestalosti: int StatPodatka: varchar(2)
Sinonim IdSinonima: int NazSinonima: varchar(100) Objavljeno: varchar(128)
SinonimKlase IdSinonimaKlase: int IdSinonima: int IdKlase: int IdTipaSinonima: smallint IdOsobe: int DatVazenja: datetime OpaskaSinonimaKlase: varchar(255) FER \ Fertalj: Razvoj informacijskih sustava IdReference: int
381
382
Zadaci
Zadaci za razgibavanje
ER model videoteke (lan, Posudba, Rezervacija, Video) Na posudbu se plaa zakasnina
[neke] Reference
Great News - The Relational Model is Dead
http://www.wiscorp.com/SQLStandards.html http://www.tdan.com/view-articles/5093
A UML Profile for Data Modeling

http://www.agiledata.org/essays/umlDataModelingProfile.html
Mapping Objects to Relational Databases ER model cjenika u restoranu brze prehrane Razliite cijene samostalnog proizvoda i proizvoda u paketu
http://www.ambysoft.com/essays/mappingObjects.html
Mapping Objects to Relational Databases: O/R Mapping In Detail

http://www.agiledata.org/essays/mappingObjects.html
Entity Relationship Modeling with UML
Domaa zadaa
ime crtati ?
http://www.ibm.com/developerworks/rational/library/content/03July/2500/2785/2785_u ml.pdf
A Repository Model - Business Rules

http://www.tdan.com/view-articles/4978/
Why (not) ORM?

Modeliranje\ITI2006 UMLORM PID236496.pdf
OMG's MetaObject Facility

http://www.omg.org/mof
383
384

PIS Predavanja01

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PIS Predavanja01

Uploaded by

Copyright:

Available Formats

O predmetu

Zavod za primijenjeno raunarstvo

Prof.dr.sc. Kreimir Fertalj

Razvoj informacijskih sustava

Optereenje = 3 h tjedno + 15 LiV + 90 samostalan rad ECTS = 5

FER \ Fertalj: Razvoj informacijskih sustava

Domae zadae individualni projekti

Test na raunalu, AHyCo blic

Meuispit(i), (ponovljeni) zavrni ispit

Ponovljeni zavrni ispit

FER \ Fertalj: Razvoj informacijskih sustava

Laboratorij programskog inenjerstva i informacijskih sustava 2

Preporua se dolazak na predavanja

Dostupni Primjeri: ???

FER \ Fertalj: Razvoj informacijskih sustava

Podatak, informacija i znanje

Podatak, informacija i znanje

Apstraktni sustav konceptualni, proizvod ljudske mate

Informacijska znanost, obavijesna znanost informatika (informatics, information theory).

Informacijski sustav podran raunalom

Poslovni i informacijski sustav

FER \ Fertalj: Razvoj informacijskih sustava

FER \ Fertalj: Razvoj informacijskih sustava

Slojevi poslovnih informacijskih sustava

Management Information System (MIS) - upravljaki

Decision Support System (DSS) za potporu odluivanju

Executive Information System (EIS) (pod)varijanta DSS za izvrne rukovoditelje

Primjer poslovnog IS (1)

Nabava, skladitenje i logistika

Office Automation System (OAS), Office support systems (OSS)

Group Support System (GSS), Groupware

Upravljako raunovodstvo (Kontroling)

Upravljanje ljudskim potencijalom

Supply Chain Management (SCM)

Customer relationship management (CRM)

Primjeri IS (2), (3)

Znaajke informacijskih sustava

Problem projektiranja, izrade i odravanja Vanost IS

FER \ Fertalj: Razvoj informacijskih sustava

FER \ Fertalj: Razvoj informacijskih sustava

Razvoj informacijskih sustava

FER \ Fertalj: Razvoj informacijskih sustava

Neki primjeri neuspjenih projekata/sustava

Denver Airport (1994)

FER \ Fertalj: Razvoj informacijskih sustava

Saetak naela razvoja informacijskih sustava

Primijenjena programska potpora = Raunalna aplikacija (application)

Informacijski sustav = sustav aplikacija za upravljanje ljudskim aktivnostima

Metoda (method), metodologija (methodology)

Podruje programskog inenjerstva

Pomagalo, alat (tool)

Tehnike oblikovanja dijagramima

Kljune aktivnosti i sudionici

Modeliranje procesa/funkcija (process modelling, functional decomposition)

Dionici, interesni sudionici (stakeholders)

Vlasnik sustava naruitelj (stvarni vlasnik ili upravitelj organizacije)

FER \ Fertalj: Razvoj informacijskih sustava

ivotni ciklus razvoja sustava

[drugi analitiari, npr. infrastrukturni, upravljanja promjenama] Upravitelj projekta

Systems Development Life-Cycle (SDLC)

ivotni ciklus razvoja

Faze ivotnog ciklusa

Zato graditi sustav?

Analiza (tko, to, kada, gdje)