Napomena Predmet Sustav za ocjenjivanje Kriteriji za ocjenjivanje

1

OIIS -2013/14

OBLIKOVANJE I IMPLEMENTACIJA INFORMACIJSKIH SUSTAVA

Prof.dr.sc. Josip MesarićMag.oec. Dario Šebalj

OIIS -2013/14

Napomena

Materijali u ovoj prezentaciji predstavljaju pomoćni radni materijal za svladavanje gradiva na predmetu Oblikovanje i implementacija IS-a. Sadrže dijelove koji se moraju revidirati i nadopuniti uz dozvole citiranih autora i izvora.

OIIS -2013/14

PredmetNastava2 sata predavanja + 2 sata vježbePredavanjaVježbe: Objektno orijentirano modeliranje - UMLSeminar: Opcionalno za višu ocjenu - projektna dokumentacija za realni/ zamišljeni poslovni sustavTemeObrazac

OIIS -2013/14

Sustav za ocjenjivanjeAktivnosti koje će se bodovati:Prisustvovanje predavanjima: max:15 x 2= 30Aktivnost na nastavi: max: 6 x5 = 50Obavljene vježbe i zadatci: min=60, max=120Pismeni ispit na računalu min=110, max=200Seminarski rad: max=100, min=60Ukupna ocjena: min=150,max=300Raspon ocjena:

160 - 190 = 2>190 – 230 = 3>230 – 270 = 4>270 – 300 = 5

OIIS -2013/14

Kriteriji za ocjenjivanje projektne dokumentacije

Identifikacija i originalnost problemaPostavljanje ciljaIzbor analitičkog postupka i izvedba analizePrikupljanje podataka i analiza zahtjevaModel funkcija poslovnog procesaModel procesaModel podatakaModel događajaModel organizacijeModel programaArhitektura Prijedlog izvedbe

OIIS -2013/14

Primjeri IS-a za seminarPoslovna funkcija

Knjiženje ulaznih računaKnjiženje izlaznih računaFormiranje financijskih izvješćaBlagajničko poslovanjeSkladišno poslovanjeIsporuka robeCall centar

Banka.....Marketing ISIS turističke agencijeCRMSCMBolnički IS za zaprimanje pacijenataIS kladionice.....

2

OIIS -2013/14

Materijali i informacijeMaterijaliLiteraturaMajdandžić, Niko: Izgradnja informacijskih sustava proizvodnih poduzeća, Slavonski Brod : Strojarski fakultet, 2004. ISBN 953-6048-25-6Ćerić, Vlatko, Varga Mladen: Informacijska tehnologija u poslovanju, Element, Zagreb, 2004, ISBN 953-197-640-6Pavlić, Mile: Razvoj informacijskih sustava, Zagreb : Znak, 1996. ISBN 953-180:004.6 Pavlić, Mile: Informacijski sustavi, Školska knjiga, Zagreb, 2011, ISBN 978-953-0-30882-4Cassidy, Anita. A Practical Guide to Information Systems Strategic Planning, Second Edition, AUERBACH; 2 edition (October 14, 2005) ISBN-10: 0849350735 ISBN-13: 978-0849350733 Gupta, Uma: Inforamtion Systems, Succes in 21. century, Prentice Hall, London, 2000. ISBN 0-13-010857-XOstali izvori uz pojedina poglavljaKonzultacije

e-mail: [email protected]

OSNOVE SISTEMSKE TEORIJEOBLIKOVANJE I IMPLEMENTACIJA IS-A

OIIS -2013/14

OIIS -2013/14

SUSTAV: definicije Neke definicije sustava:

Sustav je skup različitih stvari, (komponenata odnosno elemenata) koje zajedno mogu proizvesti rezultat koji ne može postići njegov dio ili komponenta sama (Maier and Richtin) –

Načelno, sustav je skup ili tvorevina stvari (objekata, elemenata) čije se ponašanje iskazuje u zajedništvu tih stvari (Murray Cantor)

važnoOIIS -2013/14

SUSTAV: Opće karakteristike1. Sustav je skup; cjelina dijelova, komponenata odnosno elemenata2. U datom se kontekstu mogu definirati granice između sustava i okoline3. Među njegovim dijelovima uspostavljaju se različite veze – interakcije4. U njemu postoji kontinuirani i cikličan proces transformacije ulaza u izlaze5. Sustav ovisi o kontinuiranom prilivu materije, energije i informacija da bi

opstao odnosno sveo stanje svoje entropije na minimum,6. Homeostatičnost ili težnja k određenim stabilnim stanjima,7. Svrhovitost odnosno definirane ciljeve (teleološko načelo)8. Svojstvo ekvifinaliteta donosno sposobnosti da kombinacijom različitih ulaza

postigne svoje ciljeve9. Diferencijacija odnosno tendencija razvijanja strukture (elemenata i odnosa

među njima),10. Sinergija – rezultat funkcioniranja sustava (objekta) je više od rezultata

sume funkcioniranja njegovih dijelova zasebno

OIIS -2013/14

SUSTAV - konceptualni prikaz

Materijalni

Energetski

Informacijski

U L

A Z

I

Materijalni

Energetski

Informacijski

I Z L

A Z

I

Granica sustava i okoline

PodsustavElementi

filteri

OIIS -2013/14

SUSTAV: struktura i funkcijaStrukturu sustava čine komponente sustava, položaj jedne komponente u odnosu na drugu i u odnosu na cjelinu te veze među njima. Između pojedinih komponenti sustava veze se mogu uspostaviti neposredno ili posredno preko drugih komponenata.

Pod funkcijom sustava podrazumijevamo svrhu postojanja sustava, ulogu koju sustav ima u svojoj okolini i način ostvarivanja svrhe. Funkcija sustava proizlazi iz stajališta promatranja. Iz jasno definirane funkcije sustava utvrđuju se njegove komponente i njihovi međuodnosi (struktura). (Pavlić)

3

OIIS -2013/14

SUSTAV: kontrola i upravljanje sustavom

Proces 1

Proces n

Kontrola izlaza iz sustava

ULAZ IZLAZProces 2

Sustav

Povratna veza (utjecaj na ulaz i u sustav, povratna informacija) je skup aktivnosti kojima se kontrolira i mijenjafunkcioniranje sustava kako bi se postigao željeni cilj (izlazi) sustava.

Povratna veza

OIIS -2013/14

Negativna povratna veza (povratna informacija) je utjecaj na sustav koji će korigirati faktore u procesima i podsustavima te kvaliteti ulaza koji uzrokuju greške. Negativna povratna veza ima za cilj da smanji fluktuaciju oko izlaza, tako da veličina izlaza zadovoljava postavljeni standard.

Pozitivna povratna veza je utjecaj na sustav koji uzrokuje da se kod procesa koji su dali željeni rezultat postigne daljnje povećanje tako da sustav brže ili jače ponavlja svoju funkciju. Izvor: Pavlić, http://www.

SUSTAV: kontrola i upravljanje sustavom

SUSTAV: Arhitektura sustava

Arhitektura predstavlja strukturu, dinamiku, funkcije i načine njihove izgradnje i realizacije. Mora obuhvatiti sve razine promatranja (kontekst, koncept, logiku, fiziku i potrebne razine detaljiziranosti) a istovremeno odgovoriti na pitanja: tko, što, zašto, kako, kada i gdje

OIIS -2013/14

SUSTAV – problem kompleksnosti

Kompleksnost sustava proizlazi iz:Prirode, broja i odnosa među elementimaRazina upravljanjaCiljeva i njihovih odnosaOrganizacije i dinamike sustavaSudionika Procesa i tehnoloških osnova

OIIS -2013/14

SUSTAV: okvir za razvoj (arhitekture)

Dvo- i višedimenzijske matrične strukture u kojima dimenzije opisuju:Razinu promatranja (pogled)Sudionike (Tko), Sredstva (materijalna i informacijska) (Što)Procese i funkcije (Kako)Ciljeve i motive (Zašto)Gdje (prostornu raspoređenost i veze)Kada (vremenski raspored i tajming)

OIIS -2013/14

Okviri za razvoj (arhitektura) kompleksnih sustava

Mnoštvo okvira za razvoj arhitektura za različite vrste sustava Primarno su razvijani za razvoj informacijskih sustavaMnoštvo izvedenica – postaju okviri za razvoj poslovnih sustava i drugih kompleksnih sustava općenitoPretežito dvodimenzijske strukture koje u osnovi predstavljaju metamodele za razvoj sustavaMogu se ujedinjavati u višedimenzijske arhitektureNisu modeliĆelije i područja ćelija matrice određuju izbor modela i metoda za njihovo oblikovanje

OIIS -2013/14

4

Konceptualne dimezije arhitektura

Okviri: daju logičku klasifikaciju i organizaciju kompleksnih informacijaArhitektura: identificira organizacijske strukture kao sistemske komponente i odnose, principe i upute kojima se treba voditi u oblikovanju i evoluciji kroz vrijemeŽivotni ciklus: serija stanja u procesima razvoja arhitekturePerspektiva: točka motrišta pojedinih sudionikaMotrišta: skup perspektiva s kojih se opisuje sustavApstrakcija: pojednostavljena reprezentacija ili opis motrišta koje se uzima za modeliranje arhitekture

OIIS -2013/14

Izvor: Osvalds, G.: Enterprise Arcitecture Reference Cube, EACOE, 2008

Tko, što, zašto, kako, kada, gdje izgrađuje i oblikuje IS

Tko: uloga pojedinca, organizacijskih cjelina i njihovih odnosa u oblikovanju sustavaŠto: informacijski entiteti i objekti, podatci i odnosi među njimaZašto: ciljevi i odnosi među njima, pravila pod kojim sustav funkcionira; motivi sudionika na pojedinim razinamaKako: koji se procesi funkcije moraju uključitiKada: koji se događaji javljaju u oblikovanju sustavaGdje: na kojim prostornim i organizacijskim lokacijama će se sustav oblikovati i implementirati i kako će se ostvariti veze

OIIS -2013/14

Tko, što, zašto, kako, kada, gdje oblikuje i izgrađuje IS

U kojem kontekstuNa kojim konceptualnim osnovamaNa kakvim logičkim postavkamaNa kakvoj fizičkoj osnoviDo koje razine detaljiziranosti

OIIS -2013/14

Primjeri okvira za arhitekturu sustava: Zachman architecture

OIIS -2013/14

Zašto(Motivacija)

Kako (Procesi)

Što(Sredstva)

Tko (Uloge i

odgovornosti)

Gdje(Mjesta,

komunikacija i distribucija)

Kada(Tajming –početak –trajanje –završetak)

Kontekst(Poslovni model)

ListaCiljeva

Lista procesa

Lista materijala

Organizac. Cjelina i lista uloga

Lista geograf. lokacija

Lista događaja

Koncept(Sistemskimodel)

Odnosi među ciljevima

Model procesa

Entitet –odnos model

Model organzacije i uloga

Lokacijski model

Model događaja

Logika (Poslovnalogika)

Dijagrami i pravila

Dijagram procesa

Modeldijagrama podataka

Dijagram odnosa uloga

Lokacijskidijagram

Dijagram događaja

FizičkaOsnova (Tehnologija)

Specifikacija pravila

Specifikacija procesa funkcija

Specifikac.Podatkov. entiteta

Specifikacija uloga

Specifikacija lokacije

Specifikacija dogđaja

Detalji(Detaljnareprezentacija)

Detalji pravila

Procesni detalji

Detalji podataka

Detalji uloga Detalji lokacije

Detalji događaja

Primjeri okvira za arhitekturu sustava: Zachman architecture

OIIS -2013/14

Pravila za korištenje okviraPravila

Kolone nemaju određen redosljedSvaka kolona ima jednostavan temeljni modelSvaki redak predstavlja jedinstveni pogled –perspektivu na sustav koji se razmatraKombinacija ćelija u jednom retku predstavlja kompletan opis perspektive tog retka Svaka je ćelija jedinstvena u pogledu modela i prikazaLogika je rekurzivna

OIIS -2013/14

5

KORIŠTENJE OKVIRA U OBLIKOVANJU I IZGRADNJI IS-A

DODATAK

OIIS -2013/14

Konceptualna razrada -biblioteka

Odnosi među ciljevima – detaljna analiza ciljeva sudionika: biblioteka: dovoljan broj bibliotečnih jedinica; max. Prihoda od članarine, minimiziranje troškova; korisnik: raspoloživost bibliot. Jedinica, dovoljan period posudbeRazrada procesa na sve aktivnosti i definiranje podatkovnih jedinica: zaprimanje zahtjeva za članstvo, učlanjivanje, posudba, vraćanje, obračun zakasnine, produživanje posudbe, naručivanje knjiga, obrada ponuda, pribavljanje knjiga, uvođenje u evidenciju, slaganje u police, posuđivanje, rashodovanje. Podatci: korinsik – član, članska iskaznica, djelatnik u biblioteci i njegovi podatci, knjige i njihovi podatci, posudbe i podatci, rezervacije i podatci Odnosi među podatcima – logički model entiteta i odnosaIdentifikacija svih sudionika i njihovih aktivnosti s vremenskim ograničenjima i uvjetima: aktivnosti voditelja biblioteke, bibliotekara, potencijalnog korisnika, člana bibliotekeRaspored radnih mjesta, mjesta kontakta, uređaja i veza među njimaAnaliza događaja koji pokreću procese i rezultati procesa koji pokreću nove događaje npr. zahtjev za učlanjenje, upit o raspoloživosti, rezervacija, posudba, povrat, naplata zakasnine…

OIIS -2013/14Koncept(Sistemskimodel)

Odnosi među ciljevima

Model procesa


Model organzacije i uloga

Lokacijski model

Model događaja

Primjer korištenja okvira u izgradnji informacijskog sustava

OIIS -2013/14

Kontekst: BibliotekaLista ciljeva: Pribavljati i posuđivati bibliotečni materijalProcesi: Evidentirati članove, Raditi posudbe, Pribavljati knjigeLista materijala: članovi, bibliotečne jedinice, posudbe, nabavkeOrganizaciske cjeline i lista uloga: odjel nabave, odjel posudbe, rezervacije Lokacije: biblioteka 1, biblioteka2Nabaviti knjigu, Evidentirati novu bibliotečnu jedinicu, učlaniti člana, rezervirati knjigu, posuditi knjigu, evidentirati povratak


ListaCiljeva

Lista procesa

Lista materijala

Organizac. Cjelina i lista uloga

Lista geograf. lokacija

Lista događaja

Poslovna logika

OIIS -2013/14

Opis poslovnih pravila – tko i pod kojim uvjetima može postati član, dokumentacija potrebna za članstvo, načini rezerviranja građe, opis poslova bibiliotekara, pravila za posudbu (rokovi, produžeci, kazne, pravila za obračun zakasnine, pravila za traženje ponuda, pravila za izbor dobavljača….Detaljna analiza svih procesnih koraka i radnih tokva s opisom podataka koji se prikupljaju, čuvaju, pretražuju, ispisuju na zaslonu, pisaču, koriste za označavanjeOpis svih podatkovnih entiteta i njihovih atributa, ključeva i odnosa Detaljna analiza uloga pojedinih sudionika, opis alata i uređaja, opis programskih rješenja za pojedine sudionikePrikaz detalja razmještaja uređaja, opis mreže i uređaja te protokolaDetaljan opis slijeda događaja i uvjeta grananja aktivnosti, prekida i tokova


Dijagrami i pravila

Dijagram procesa


Dijagram odnosa uloga

Lokacijskidijagram

Dijagram događaja

Fizička osnova – specifikacija programskog rješenja i baze

Raščlanjivanje programa na cjeline – module i definiranje pravila i ograničenja na programske module i bazu podataka Način povezivanja programskih modula Izrada kompletne sheme podataka, normalizacija, Mapiranje modela podataka na izabranu bazu podatakaDefiniranje sučelja za unos, pohranu pretraživanje i izvještavanjeOblikovanje programskih rješenja za pojdeine sudionike i uređajeRazrada događaja na razini programskog rješenja (automatizmi, upiti, pokretanje modula)

OIIS -2013/14


Specifikacija pravila



Specifikacija uloga

Specifikacija lokacije

Specifikacija dogđaja

Detaljna razrada –implementacijsko rješenje

Specifikacija pravila u konkretnom programskom rješenju s konkretnim programskim jezikom i bazom podatakaDetalji programskog rješenja do razine programske naredbeDetaljna specifikacija podataka s pravilima za očuvanje integriteta, domene i tipovi podataka, implementacija na izabrani SQLUloga programskih modula do razrade aktivnosti na sučeljima i automatizmima pojedinih programskih rješenjaProgramski zadatci u konkretnom programskom rješenju koji aktiviraju druge procese i njihova manifestiacija nad podatcima i programskim sučeljima

OIIS -2013/14Detalji(Detaljnareprezentacija)

Detalji pravila

Procesni detalji

Detalji podataka

Detalji uloga

Detalji lokacije

Detalji događaja

6

Modeli za razvoj sustava

Svaka ćelija može imati vlastiti model za razvoj arhitektureAspekt ima skup modelaModeli bliskih ćelija su međusobno povezani

OIIS -2013/14

Što nedostaje u okvirima za izgradnju?

Slijed aktivnostiPerformanse postignuća ciljevaKriteriji izbora

OIIS -2013/14

OIIS -2013/14

Informacijski sustav –definicija – ontološko načelo

Informacijski sustav je sustav koji čine ljudi, programska i računalna oprema koja je napravljena, oblikovana i dovedena u operativno stanje te služi skupljanju, zapisivanju, spremanju i pronalaženju te prikazivanju informacija u odgovarajućem obliku (Kiš, 2002).

OIIS -2013/14

Informacijski sustav –teleološko načelo

Informacijski sustav se razmatra s aspekta svrhe kojoj služi u datom kontekstu. Tipični kontekst uključuje poslovne sustave, državne ustanove, neprofitne organizacije (škole, biblioteke i druge…) ili može biti tehnološki proces ili neki drugi ograničeni kontekst u organizaciji. (http://www.cs.kau.se/~gustas/student/em/paperonEMapproach.pdf)

OIIS -2013/14

Dijelovi ISIS predstavlja skup povezanih dijelova, i to:

Ljudi (analitičari, dizajneri, programeri i poslovni korisnici, upravitelji…),IT (hardver, strojevi, mreža, alati, softver …),Procedure (pravila, propisi, ograničenja, znanja, metodologija …),Podataka i informacija različitih pojavnih oblika na različitim nositeljima podataka podesnih za prihvat, obradu, pohranu, pretraživanje i distribucijuPrograma kojima se procedure mogu dovoljno dobro opisati i izvoditi nebrojeno mnogo puta (prvenstveno u svrhu automatizacije)Organizacija (hijerarhija, mjesta odlučivanja, linije kontrole i izvještavanja, odgovornost, raspodjela posla, timovi…)

Zahtjevi koji se postavljaju pred (informacijske) sustave

Funkcionalnost – spsobnsot sustava da osigura korisniku i ostalim sustavima postizanje poslovnih potrebaKorisnost : lakoću pristupa svim sistemskim funkcijamaOdrživost: lakoću dodavanja novih funkcionalnostiSkalabilnost: sposobnost da se koristi od strane povećanog broja korisnika, povećanog broja podataka i rastućih zahtjevaPouzdanost i raspoloživost: vjerojatnost da će sustav raditi ispravno uključujući i zahtjeve sigurnostiPerformance: očekivano vrijeme odgovora na zahtjev u slučaju odgovarajućeg opterećenja kapacitetaKapacitet: očekivani broj korisnika i broj podataka koji se može obraditi u jeidnici vremenaOsiguranje potpore: lakoća dobivanja usluge u određenom polju (proizvodnji, financijama i sl.)Minimiziranje troškova uvođenja sustavaSmanjenje operacionih troškova – troškova funkcioniranja sustava

OIIS -2013/14

7

OIIS -2013/14

Nužnost “poravnavanja” PS i IS

POSLOVNI SUSTAV (PS)

INFORMACIJSKI SUSTAV (IS)

ICT IZVEDBA

Zahtjevi

Način realizacije

Način realizacije

Zahtjevi

“Dobro definiran PS «ulaz» je u IS. Cilj modeliranja IS-a jest načiniti projekt IS-a – razraditi 3 cjeline: model informacijskih procesa, model podataka i model resursa. Poslovni i informacijski procesi nisu isti. Model IS-a nam pokazuje kako treba, organizirati informacijski sustav da on stvarno daje potporu PS-u. IS mora biti neovisan i neopterećen od bilo kakve konkretne ICT tehnologije.” Izvor:http://www.foi.hr/studiji/dodiplomski/IS/kolegiji/uis/nastavni_materijali.html

OIIS -2013/14

Koncepti i metode povezivanja PS-a i IS-a

Uvođenje i primjena IS-a može biti uspješno samo onda ako je razvoj IS-a usklađen sa strategijom razvoja poslovnog sustava. Ovakav pristup naziva se strateškim planiranjem razvoja IS-a. za to postoji više mogućnosti kao što su:

strateško poravnanje PS-a i IS-a,strateško planiranje IS-a imetoda CoBIT.

OIIS -2013/14

Strateško poravnanje PS-a i IS-aOsnovna ideja jest uskladiti potrebe PS-a s mogućnostima IS-a.

Tehnologijapodržava strategiju

podržava

PSPoslovna strategija

Strateško poravnanje

IS Strategija

Strategija koristitehnologiju

koristi

strategijaIS ne uspjevapodržati PS(IS deficit)

nedovoljnokorišten IS(IS suficit)

IT

IT

strategija

Izvor:http://www.foi.hr/studiji/dodiplomski/IS/kolegiji/uis/nastavni_materijali.html

OIIS -2013/14

Strateško poravnanje PS-a i IS-aOrganizacijska zrelost PS-a

tehnička razina,potpora poslovanju,strateško upravljanje iučenje i organizacijski razvoj

Uloge IS-a baziranog na ICT-a u PS-u:potpora aktivnostima u vrijednosnom lancu,integracije vrijednosnog lanca,poboljšanje poslovnih procesa promjena opsega poslovanja Izbor strategije

Strategija operativne potpore – strategiji operativne potpore odgovara uloga IS kao potpora aktivnostima lanca stvaranja vrijednosti. Strategija integracije poslovanja – njoj odgovara uloga IS kao integratora lanca stvaranja vrijednosti. Strategija stvaranja organizacijske vrijednosti – u organizacijama koje primjenjuju strategiju stvaranja organizacijske vrijednosti IS mora (s obzirom na zrelost svojih mogućnosti) biti na razini strateškog upravljanja.

OIIS -2013/14

Strateško planiranje IS-a Metode i metodike strateškog planiranja IS-aNajstarije BSP metoda i Rockard-ova analiza, nakon kojih je nastao čitav splet drugih metoda i modela kao što su: Earl model, End-Means, CSF analiza, 5F-metoda, SWOT, BCG itd. A. Cassidy načinila je praktični priručnik za strateško planiranje IS-a. Također, i pojedine metodike razvoja IS-a kao što su SPIS, SSADM, MIRIS, ARIS, CASE*Method i druge, omogućavaju izradu strateškog plana IS-a.

OIIS -2013/14

BSP- bussiness system planning

Izvor:http://www.foi.hr/studiji/dodiplomski/

IS/kolegiji/uis/nastavni_materijali.html

CiljeviPS-a

OrganizacijaPS-a

Osnovnaarhitektura IS-a

Baze podataka i aplikacije

Izvedba IS-a putem ICT

Informacijski procesi

Klase podataka za potrebe PS-a

Ciljevi IS-a i procjena učinaka

Poslovni procesi u PS-u

Top-

dow

n

PS

Boo

tom

-up

IS

Model strukture IS-a

Dio kojipokriva BSP

metoda

8

OIIS -2013/14

Ostale metode strateškog planiranja IS-aSSADM (Structured Systems Analysis And Design

Methodology) sastoji se iz sljedećih 7 faza:1. Studije izvedivosti,2. Ispitivanja postojećeg stanja,3. Moguće izvedbe poslovnog sustava,4. Definiranja zahtjeva,5. Moguće tehničke izvedbe sustava,6. Logičkog oblikovanja sustava i7. Fizičkog oblikovanja sustava.

http://en.wikipedia.org/wiki/SSADMhttp://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.htmlhttp://www.ogcio.gov.hk/eng/prodev/es3.htm

OIIS -2013/14

Ostale metode strateškog planiranja IS-a

Metodika MIRIS (Metodika za razvoj IS-a)sastoji se od dvije temeljne faze projektiranja: logičkog i fizičkog oblikovanja, koje se dalje dijele na po 3 koraka. Logičko oblikovanje čini strateško planiranje IS-a, glavni projekt i izvedbeni projekt, dok je fizičko oblikovanje izvedba programske potpore, uvođenje i primjena te održavanje.http://www.ris.hr/page.php?id=4

OIIS -2013/14


CASE*Method se sastoji od 6 faza: strategije, analize, oblikovanja, izgradnje + dokumentiranja, uvođenja i primjene IS-a

http://www.sei.cmu.edu/legacy/case/case_whatis.htmlhttp://www.cs.queensu.ca/Software-Engineering/tools.html

Literatura

Mark W. Maier and Eberhardt Rechtin, The Art of Systems Architecting (second edition),CRC Press, 2000, p 8.Murray Cantor, Rational Unified Process for System Engineering, Part 1, http://www.therationaledge.com/content/aug_03/f_rupse_mc.jsp

OIIS -2013/14

MODELI I METODE ZA RAZVOJ INFORMACIJSKIH SUSTAVA


OIIS -2013/14 OIIS -2013/14

Modeli i modeliranje“Modeliranje se može definirati kao čin predstavljanja nečega , obično u manjem obujmu ili sa manje detalja. Uz upotrebu alata za modeliranje (npr. poslovnih procesa) modeliranje se može shvatiti kao čin grafičke reprezentacije poslovnih procesa ili softvera. Model tako kreiran može se koristitit za određene aspekte sustava koji se predstavlja modelom (podatci, dokumenti, komunikacija). Studija modela omogućava uvid u razumijevanje modeliranog sustava”. (Enterprise Architect)Model – pojednostavljena slika stvarnosti u kojoj se ističu najvažnija svojstva te stvarnostiOpis stvarnosti (konstrukcija modela) može se izvesti različitim “jezicima” – izražajnim sredstvimaU tom opisu trebala bi postojati izomorfija – jednoznačno preslikavanje svojstava iz modela u svojstva iz stvarnostiU tom opisu uvijek dolazi do gubitka informacija i podataka

9

OIIS -2013/14

O čemu treba voditi računa kod modeliranja

Vrijednost modela ovisi od konzistentnosti, obilja i točnosti podataka koji se koriste u konstrukciji modela,Izbor ključnih varijabli ovisi o osobnim procjenama, ciljevima, opsegu problema, ekonomiji modeliranja,Jake statističke veze među varijablama ne znače i jaku uzročno posljedičnu vezuRelevantnost modela za budućnost sustava koji je modeliran je suštinski problem modeliranja; vrijednost modela određena je inherentnim hipotezama,Model će predstavljati osnovu za akcijuPredviđanja nisu nikad bezgrešna i modelar mora prepoznavati i ocijeniti odstupanje od realnosti pri izboru alata za modeliranjeKada je jedanput izabran model, tada rješavamo model a ne stvarnost; implementacija ubrzo pokazuje kvalitetu modela

(Izvor: Godet, M: Scenarios and strategic management, Butterworths, London, 1987.)

OIIS -2013/14

O čemu treba voditi računa kod modeliranja

Ulazno izlazna preslikavanja nemaju u toku dužeg vremenskog perioda invarijantan karakterDinamika i struktura objekta kao i relacije s okruženjem mijenjaju se tijekom vremena a tako i granice sustava s okruženjemNe postoje objektivni kriteriji da se utvrdi koji atributi sustava su mjerljivi a koji nisu,Poslovni sustavi su sustavi s nedestruktivnom memorijom –evolucijski sustavi, što znači da je prošlost integralni dio objekta; oni sa svakim novim stanjem generiraju nove oblike ponašanja,Poslovni sustavi su anticipativni objekti, što znači da će akcije koje se predviđaju za budućnost snažno utjecati na odluke u sadašnjosti,Poslovni sustavi su sustavi u kojima se mogu identificirati brojne povratne sprege, što znači da ponašanje sustava ovisi od njegove vlastite dinamike.

OIIS -2013/14

Metode i metodologijaMetoda – ukupnost procedura koje dovode do rješenja modela

Zahtjevi za metodom:Jednostavnost i lakoća korištenja,Koncepcijska osnova i matematički aparat koji se primjenjuje za rješavanje modela,Generalnost metode – sposobnost metode da obuhvati različite klase i strukture,Snaga metode – sposobnost dolaženja do konačnog rješenja za dati tip zadatka,Višekriterijalnost – sposobnost metode da rješava model s različitih aspekata,Bliskost pravila izbora čovjekovom misaonom procesu,Način tretiranja neizvjesnosti i uključivanja vjerojatnosti u model

Metoda mora zadovoljiti:Opće kriterije (originalnost, uopćenost)Sintaktičke kriterije (jasno formuliranje pojmova, unutrašnja neproturječnost, sklad nalaza izvedenih dedukcijom),Semantičke (izdiferenciranost pojmova, mogućnost emprijske interpretacije pojmova, homogenost)Ontološke kriterije (znanstvena objektivnost i sklad s općim karakteristikama objektivne stvarnosti)Kriterije spoznajne vrijednosti (sklad informacija i hipoteza i mogućnost emprijske verifikacije istinitosti informacija)(Izvor: Ackoff, L.R.: Scientific method, J.Willey&Sons, New York, 1965)

OIIS -2013/14

Uloga metodologijeCilj metodologija

omogućiti sustavni postupak razvoja kojem će se moći pratiti napredakuspostaviti komunikaciju između sudionika uključenih u izgradnju IS (poslovodstvo, korisnici, analitičari, programeri …)osigurati skup tehnika koji će omogućiti da se zadaci izvršavaju na standardne i provjerene načineosigurati učinkovit nadzor sa ciljem uočavanja pogrešaka u ranim fazama omogućiti elastične promjene poslovanja i tehnologije (npr. Odvajanjem analize i oblikovanja)uokviriti razvojnu strategiju kojom će se ukloniti ad hoc rješavanje problemaodrediti ili ukazati kada i u kojoj mjeri je potrebno uključivanje korisnika, te poticati i omogućiti uključivanje korisnika kada se za to ukaže potrebaosigurati da se dovoljno pažnje posveti analizi poslovanja, čime će se osigurati izrada sustava koji odgovara poslovanju i zahtjevima korisnika(Izvor: http://www.zpm.fer.hr/courses/pis)

OIIS -2013/14

Vrste modela u modeliranju IS-aModeli za pristup razvoju informacijskih sustava. Određuju:

Faze u izgradnji sustavaDinamiku izgradnje

Modeli strukturnih elemenata i strukturne analize. Određuju:Strukture sustava s različitih aspekataStrukturalne odnose

Konceptualni modeli. Određuju:Domenu (kontekstni model, informacijski model, model ciljeva i funkcija, sistemski model, model sudionika i njihvoih uloga)Obuhvat

Modeli aspekata s kojih se promatra IS. Određuju:Model podatakaModel funkcija i procesaModel događajaModel resursaModel programa

Integrativni modeli – objedunjuju modele strukturnih elemenata i konceptualne modele (strukturalni modeli – s osnovom na relacijskim bazama i objektno orijenirani modeli temeljeni na UML notifikaciji)Metamodeli navedenih modela i modelskih podsustava

OIIS -2013/14

Povjesni razvoj modela

Pionirskiradovi

Pročišćavanje iproširivanje

modela

Istraživanjazajedničkih

okvira

Sudjelovanje i razumijevanje

60-e

70-e

80-e

90-e

2005

-Proširenje obujma

-StandardizacijeModeli (baza)podataka

Modeli informacijskihSustava

Modeli poslovnih sustava

Aspektvemena

Obrazovanje korisnika i sudjelovanje u projektima

Domenski specifični“Ontološki modeli”

i jezici

Modeli poslovnihpravila

Formalizacija vs neformalizacija

Izvor: Janis A. Bubenko jr, A Historical Perspective on Conceptual Modelling: from Information Algebra to Enterprise Modelling and Ontologies, Royal Institute of Technology, Stockholm, Sweden, [email protected],

10

OIIS -2013/14

Tehnike i alati za opis modela

Jezične strukture prirodnog jezikaPseudojezici (pseudokod)Grafički prikaz s dogovorenim (standardiziranim) skupom simbola i notacija za pojedine aspekte sustava

MODELI FAZA RAZVOJA –ŽIVOTNI CIKLUS RAZVOJA

Modeli za pristup razvoju informacijskih sustava. Faze u izgradnji sustavaDinamiku izgradnje

OIIS -2013/14

Životni ciklus razvoja sustava (SDLC- systems development life cycle)

SDLC je “sistemski pristup rješavanju problema kroz faze koje sadrže više koraka”. Ovisno o konceptu (prirodi sustava) to može biti:Software development life cycleISDLC- information system development life cyclePDLC – project development life cycle

Osigurava slijed logičkih faza i njima pripadajućih koraka za razvoj (planiranje, izvršenje, nadzor) projektaSvaka faza rezultira nekim “izlazima” (deliverables) koji su važni za ili se isporučuju u slijedeću fazuMoraju postojati metrike i kontrole izvršenja u svakoj fazi radi donošenja odluka o daljnjim fazama

OIIS -2013/14

SDLC – definicija U.S. Department of Justice (DOJ)

Systems Development Life Cycle (SDLC) ili ponekad (SLC) definira se kao software development process, iako se može shvatiti kao proces neovisan o softveru ili razmatranju IT-a. Koriste ga sistem analitičari za razvoj IS a uključuje analizu zahtjeva, vrednovanje, obuku, oblikovanje, implementaciju i održavanje sustava.

OIIS -2013/14

SDLC – nekoliko metoda i izvedenica

Klasični (izvorni) – Royce modelPristup DOJ (Department of Justice USA)UK administration modelCIO.GOV (Glavni informacijski ured američke vlade)

OIIS -2013/14 OIIS -2013/14

Modeli i metodologije za pristup izgradnji IS-a Izbor modela i metodologije ovisi o:

Veličini i obujmu projekta IS-aPrirodi problema (ciljevima) koji se uvođenjem IS-a želi riješitiVremenu raspoloživom za stvaranje IS-aZnanju raspoloživom o problemu za koji se IS razvijaRaspoloživim resursimaModalitetima izgradnje

11

OIIS -2013/14

Modeli i metodologije za pristup izgradnji IS-a – prepoznavanje faza izgradnje

Vodopadni (klasični i modificirani) pristupV – modelEvolucijski modelSpiralni modelPrototipiranjeBrzi razvoj aplikacija (Rapid Application Development)Agilno programiranje i ujedinjeni razvojni procesEkstremno programiranje (eXstreme Programming) Ograničeno programiranje (Constraint programming)

OIIS -2013/14

Vodopadni (waterfall) pristup

Klasični vodopadni model

slijedno napredovanje iz faze u fazunisu dozvoljene naknadne promjene rezultata prethodnih fazaprimjeren velikim projektima (investicijama)prikladan za dobro definirano okruženje, gdje postoje razrađene procedureručne obrade ili računalski sustav koji treba unaprijediti

Analiza i specifikacija

zahtjeva

Oblikovanje

Implementacija

Provjera -vrednovanje

Primjena i održavanje

Izvorni Royce's waterfall model

Vodopadni (waterfall) pristupPrednosti:

Temeljitost – bolje je pogriješiti u inicijalnim fazama i ispraviti grešku nego u kasnijim fazamaDokumentiranost svake fazeDisciplinirani pristup

Nedostatci:Vremenski zahtjevno –nemoguće je do perfekcije dovesti svaku fazuNemogućnost predviđanja budućih događajaZahtjeve i oblikovanje kao i ostale faze moraju analizirati visokostručni ljudiTeško je predvidjeti troškove pojedinih fazaNe postoji procjena rizikaSustav je upotrebljiv kad je gotov u potpunosti

OIIS -2013/14

Vodopadni pristup - analiza zahtjeva

strukturna sistemska analiza nalaženje skupa “atomarnih” temeljnih funkcija sustava, njihovih ulaza i izlazaopis ulaza, izlaza i spremišta preko rječnika ssa.opis pojedinačnih atomarnih funkcija preko pseudokoda

OIIS -2013/14

Vodopadni pristup – oblikovanje sustava

Logičko oblikovanje (projektiranje)Izgradnja odgovarajućeg modela podataka (model objekti-veze)Transformacija modela objekti-veze u normalizirani relacijski model. Oblikovanje strukturnih programa (programskih struktura)

Fizičko oblikovanjeFizičko oblikovanje baza podatakaOblikovanje korisničkih sučeljaDodavanje “fizičkih elemenata” strukturnim programima.

OIIS -2013/14

Vodopadni pristup –implementacijaImplementacija

Kodiranje u nekom strukturnom jeziku i testiranje ili Primjena generatora aplikacija (jezika četvrte generacije)Relacijske baze podataka i dvoslojna klijent-server arhitektura.

OIIS -2013/14

12

Vodopadni pristup – primjena i održavanje

Testiranje na probnim podatcimaKonverzija podataka iz postojećeg sustavaPuna funkcionalnost i dokumentiranjeObuka korisnika

OdržavanjeKorektivnoAdaptivnoPreventivno

OIIS -2013/14 OIIS -2013/14

Modificirani vodopadni pristup

Uvode se povratne veze i mogućnost promjene rezultata prethodnih fazauvođenje prema dolje: moduli na višim, pa na nižim razinamaprimjena tehnika strukturiranog programiranjaaktivnosti različitih faza mogu se obavljati istovremenokorištenje rječnika podataka, 4GL i generatora aplikacijaprikladan kada se unaprijed ne zna konačni izgled sustavamora nastati (papirnati) model sustava

Analiza zahtjeva

Oblikovanje

Implementacija

Provjera -vrednovanje

Primjena i održavanje

SDLC DOJ – SHEMA

Inicijalizacija

Razvoj sistemskog koncepta

Planiranje

Analiza korisničkih zahtjeva

Oblikovanje

Razvoj

Integracija i testiranje

Implementacija

Operabilni sustav i održavanjeDispozicija

INFORMATION RESOURCES MANAGEMENT, The Department of Justice Systems Development Life Cycle Guidance Document, January 2003 Izvor: http://www.usdoj.gov/jmd/irm/lifecycle/table.htmOIIS -2013/14

SDLC- DOJ – detaljna razrada

The DOJ SDLC sadrži 10 faza:Inicijalna faza

Započinje identifikacijom poslovnih potreba ili poslovnih prilika. Imenuje se projektni manager. Izlaz: Dokument o konceptualnom oblikovanju. Management odobrava projekt.

Faza razvoja sistemskog konceptaObuhvaća studije izvodljivosti i prikladnosti; definiraju se sistemske granice i ograničenja; obuhvat (SCOPE) projektnih zadataka; Izlazi: idejni projekt i odobrenje financiranja i obujma projekta.

Faza planiranjaPregled i analiza postojećeg stanja. Usuglašavanje ciljeva PS-a i IS-a; planiranje aktivnosti, redosljeda i rasporeda financijskih resursa, kadrova i opreme, sigurnosti, upravljanje i nadzor nad izvršenjem pojedinih zadataka. Izlaz: glavni projekt

OIIS -2013/14

SDLC-DOJ – detaljna razrada - nastavak 1

Faza analize zahtjevaAnaliziraju se i definiraju svi funkcionalni zahtjevi u pojmovima potrebnih podataka, sistemskih karakteristika, sigurnosti i održavanja sustava; detaljna analiza postojećeg stanja (As is model sustava) i budućeg stanja stanja (To be model sustava); svi zahtjevi moraju biti mjerljivi i provedivi i usuglašeni s poslovnim potrebama identificiranim u inicijalnoj fazi.

Faza oblikovanjaSustav se promatra s aspekta projektanta; logički fizički dizajn; definiranje podsustava i operativne platforme; definiranje ulaza, izlaza, procesa i resursa; podsustavi se oblikuju u module. Priređuje se detaljna logička specifikacija pojedinih modula. Definiraju se fizičke karakteristike sustava (pogled izvođača). Izlaz: tehnološka specifikacija sustava

OIIS -2013/14

SDLC-DOJ – detaljna razrada –nastavak2

Faza ravoja Specifikacije iz prethodne faze prevode se na hardversku platformu i operacijski sustav, komunikacije i izvršni oblik softvera. Softverkski moduli se testiraju, Hardver se testira i podešava.

Integracija i testiranjeRazličite komponente sustava se testiraju i i integriraju. Korisnici testiraju sustav; provjeravaju se funkcionalni zahtjevi i podešavaju prema korisničkim zahtjevima. Certificiranje softverskih rješenja.

Faza implementacijeSistemske komponenete se instaliraju na datoj platformi; faza se nastavlja sve dok se ne dobije oerativni sustav koji funkcionira prema korisničkim zahtjevima. Izlaz: specifikacija funkcionalnosti sustava

OIIS -2013/14

13

SDLC-DOJ – detaljna razrada –nastavak3

Faza operativne upotrebe i održavanjaOperativni sustav se promatra u svim fazama procesa; sustav se povremeno procjenjuje i prilagođava manjim novim i promjenjenim zahtjevima radi povećanja učinkovitosti i boljeg iskorištenja. Izlaz: plan održavanja sustava

Faza dispozicijeOsigurava redovite i neplanirane prekide sustava i očuvanje vitalnih informacija o sustavu tako da se mogu reaktivirati u budućnosti i/ili migrirati na drugi sustav

INFORMATION RESOURCES MANAGEMENT, The Department of Justice Systems Development Life Cycle Guidance Document, January 2003 Izvor: http://www.usdoj.gov/jmd/irm/lifecycle/table.htm

OIIS -2013/14

Planiranje

Studija izvodljivostiPlaniranje projektaPlan osiguranja kvalitetePlan upravljanja projektomStrukrirani pregledProcjena stanja fazaIzlazi iz faze planiranja

Definiranje zahtjeva

Matrica informacijskih zahtjevaPlan kontinuiteta operacijaNacrt rječnika podatakaSpecifikacija zahtjevaNacrt plana prihvaćanjaRevidirani projektni planStrukturirani prikazProcjena fazeIzlazi iz faze definiranja zahjteva

Funkcionalno oblikovanje

Logički modelRječnik podatakaSpecifikacija zahtjevaMatrica slijednosti zahtjevaDokument funkcionalnog planaRevidirani projektni planStrukturirani pregled fazeProcjena fazeIzlazi iz faze funkcionalnog oblikovanja

Sistemskooblikovanje

Prošireni rječnik podatakaModel fizičkog sustavaNacrt plana za testiranje integracijeProšrena matrica slijednosti zahtjevaPlan prevođenjaDokument sistemskog oblikovanjaSpecifikacija programaProgramski standardiRevidirani projektni planStrukturirani pregled fazeProcjena fazeIzlazi iz faze sistemskog oblikovanja

Izrada /konstrukcija

Plan prihvaćanjaPlan instalacije opremeProširena matrica slijednosti zahtjevaFinalni plan za testiranje integracije

Prošrena matrica slijednosti zahtjevaPlan prijelaza na novi sustavNacrt operativnih dokumenataPlan obuke Revidirani projektni planStrukturirani pregled fazeProcjena fazeIzlazi iz faze izrade

Razvoj informacijske arhitekture poslovnog sustava

Razvoj informacijske arhitekture; IS LC Stages and Deliverables, DOE Software development Methodology, http://cio.doe.gov/sqse

OIIS -2013/14

SDLC – rekapitualcija

Planiranje

Analiza

Oblikovanje Primjena i održavanje

Pregled

Izradba

Plan sustava

Specifikacija zahtjeva

Specifikacija sustava Funkcionalni

sustav

Operabilni sustav

Dorada, prerada, nadogradnja

Izvor: Kalpić, PIS, predavanja

Planiranje (zašto)Zašto graditi sustav?Analiza (tko, što, kada, gdje)Tko koristi sustav?Što mora raditi?Gdje i kada će se sustav koristiti?Oblikovanje (kako)Kako će sustav raditi?Izrada (+isporuka)ugradnja rješenjaPrimjenaodržavanje i poboljšavanje

OIIS -2013/14

SDLC – faze u ovisnosti o kompleksnosti projekta

1. Implementacija

2. Testiranje 3.Vrednovanje

1. Studija izvodljivosti

2. Analiza 3. Oblikovanje 4. Razvitak sustava

5. Uvođenje 6. Održavanje


2. Analiza 3. Oblikovanje 4. Uvođenje 5. Održavanje


2. Analiza 3. Oblikovanje 4. Razvitak sustava

5. Testiranje 6. Uvođenje

1. Analza uključivo i Studija izvodljivosti

2. Oblikovanje

3. Razvitak sustava

4. Uvođenje 5. Vrednovanje


2. Analiza 3. Oblikovanje 4. Uvođenje 5. Testiranje 6. Vrednovanje 7. Održavanje

Kompleksnost sustava

OIIS -2013/14

ŽIVOTNI CIKLUS RAZVOJA SUSTAVA – OSTALI MODELI

SDLC

OIIS -2013/14 OIIS -2013/14

V- modelNastao kao rezultat evolucije softverskog testiranjaNakon svake faze provodi se testiranje i ispravljaju greške

Analiza zahtjeva

Oblikovanje testa prihvatljivosti

Test prihvatljivosti

Sistemskooblikovanje

Oblikovanjesistemskog

testa

Testiranjesustava

Oblikovanje arhitekture

OblikovanjeTesta

integracije

Test integrativnosti

Oblikovanjemodula

Oblikovanje testne

jedinice

Testna jedinica

Kodiranje

14

Inkrementalni model

OIIS -2013/14

Prethodi mu podjelana podsustave –polazna arhitektura je definirana

OIIS -2013/14

Spiralni modelSpiralni prikaz

ordinata predstavlja kumulativni trošaksvaka petlja spirale od osi X predstavlja jednu fazu razvojafaza može biti realizirana slijedno, prototipski ili evolucijskiodluka o nastavku razvoja donosi se prolaskom kroz os X

Faze:1. Analiza rizika, procjena alternativa2. Razvoj i verifikacija sljedećeg

"produkta"3. Planiranje sljedeće faze4. Pregled - Određivanje ciljeva,

alternativa i ograničenja

kumulativni trošak

Integracija

Izrada

Oblikovanje

Analiza1

1

1

1

2

22

2

3

3

3

4

4

4

4

OIIS -2013/14

Spiralni (Boehm-ov) model

OIIS -2013/14

PrototipiranjePrototip se radi da bi se isprobale neke mogućnostiIzvodi se da bi se testirale neke osobine sustava, prikupile potrebne informacije i provjerile ideje – Prethodi mu definiranje arhitekture sustava – skupa aplikacija i modela bezeIstraživački model (research model)traženje različitih načina na koje se sustav može izraditiPogodan za razvoj manjih sustavaPrototip koji postupno, inkrementanlnom doradom -“bistrenjem” (stepwise refinement) postaje dio završnog IS (Fertalj, Kalpić)

PrednostiUbrzana izgradnja i relativno niski troškoviMogu se procijeniti rizici projektaPodržava aktivno sudjelovanje zainteresiranih stranaRano uočavanje pogrešaka...

NedostaciBojazan da se sustav neće razviti do krajaTeže upravljanje projektom; loša dokumentiranost iNemogućnost implementacije u cjelosti.. Teško održavanje

OIIS -2013/14

Brzi razvoj aplikacija (Rapid application development - RAD

Razvio se kao odgovor na spore i često neefikasne metode kao što je vodopadni pristup.Starting with the ideas of Brian Gallagher, Barry Boehm and Scott Shultz, James Martin developed the Rapid Application Development approach during the 1980s at IBM and finally formalised it by publishing a book in 1991. Podatci o metodologiji: http://csweb.cs.bgsu.edu/maner/domains/RAD.htm

OIIS -2013/14

Agilno modeliranjeAgile Unified Process obuhvaća (Rational Unfied Process)

slijedeće fazePočinjanje

Identificira se inicijalni obujam projekta, potencijalna arhitektura sustava i prihvaćanje od zainteresiranih strana

Elaboracija Pokazuje se arhitektura sustava

KonstrukcijaRazvija se softver na postepenoj osnovi polazeći od najviših prioriteta

Prijelaz Vrednuje se i provjerava softver na operativnom okruženju

15

OIIS -2013/14

Agilno modeliranjeDisciplineModel – razvija se poslovni model organizacije, identificira se problemska domena i raspoloživa rješenjaImplementacija – transformira se model u izvršni oblik koda i izvodi temeljno testiranje na jedinici za testiranjeTestiranje – pronalaženje grešaka, testiranje sustava na realnom okruženju i provjera da li sustav udovoljava zahtjevimaUpravljanje konfiguracijom – upravljanje projektnim smtenjama i prilagođavanje sustava za njihovo izbjegavanjeUpravljanje projektom – usmjeravanje aktivnosti koje su vezane uz izvođenje projekta; upravljanje rizicima, usmjeravanje ljudi na zadatke i provjeravanje napretka, koordinacija aktivnostiOkruženje – potpora radu u skupini uz osiguranje hardverskih softverskih alata, vodiča kroz projekt i standarda kvalitete

Filozofija Jednostavnost AgilnostFokusiranje na aktivnosti “viših vrijednosti”Neovisnost o alatuPrilagodba AUP-a potrebama korisnika http://www.ambysoft.com/unifiedprocess/agileUP.html, http://www.agilealliance.org/,

OIIS -2013/14

Ekstremno programiranje (XP -eXtreme Programming)Jedna od metoda agilnog programiranja. Temelji se na 5 vrijednosnih grupa:

Komunikativnost – razvojni tim ima dijeljeni korisnikov. Favorizira se jednostavan dizajn, zajedničke metafore, kolaboracija i verbalna komunikacija. Jednostavnost –započinje se s najjednostavnijim rješenjem; fokus je na rješenjima potrebnim danasPovratna veza – testiranje

Povratna veza sa sustavom – izabiru jedinice za testiranje i periodičnu integraciju Povratna veza s klijentom – radi se test prihvatljvosti Povratna veza s razvojnim timom – nakon provjere zadovljnosti klijenta razvojni tim daje procjenu vremena za implementaciju

Povjerenje – članovi tima imaju visoko međusobno povjerenje i ne zahtjeva se provjera ispravnosti jer se vjeruje u njihovu visoku profesionalnost (rad u parovima; kolktivno vlasništvo nad softverom)Poštovanje – nitko u timu se ne zapostavlja; postoji visoka lojalnost timu

OIIS -2013/14

Ekstremno programiranje –aktivnosti i prikladnost AKTIVNOSTI

Kodiranje. Testiranje SlušanjeOblikovanje

Prikladnost XP-a:Za prototipski pristup gdje zahtjevi mijenjaju često i gdje je nema provjerenih rješenjaU istraživačkim projektima gdje razvoj softvera nije glavni cilj već razvoj domenskog znanja U manjim projektima gdje poželjno neformalno vođenje projektaGdje se može okupiti motivirani visoko profesionalni tim

Neprikladnost XP i upotreba klasičnih metoda:u projektima sa stabilnom tehnologijom i fiksnim zahtjevima te predvidljvim promjenama U projektima gdje se moraju poštivati formalne metode i traži se visoka sigurnost U velikm projektima gdje mora postojati formalna komunikacija U kompleksnim sustavima gdje projektna dokumentacija predstavlja temelj za operativno djelovanje i održavanje sustava(Izvor: http://www.extremeprogramming.org/index.html)

Modelom vođena arhitektura (razvoj)

Model Driven Architecture (MDA) koju je 2001 predložila Object Management Group je “an approach to using models in software development”.Pojam arhitektura se vezuje za činjenicu da se preko asptraktnih modela (PIM) može ostvariti inteoperabilnost heterogenih sustava

Modelom vođeni razvojomogućava:

Specifikaciju sustava neovisnu od bilo kakve implementacije;Specifikaciju platforme;Izbor platforme za implementaciju specificiranog sustavaTransformaciju specifikacije sistema u izabranu platformu.

OIIS -2013/14

Modelom vođena arhitektura (razvoj)

OIIS -2013/14

Platformskinezavisan model

PIM

Model za opisPlatforme

PDM

Transformacija

Platformski zavisanmodelPSM

Računarskinezavisan model

CIM

Computation Independent Model –CIM – model odgovarajuće domene, zajednički riječnik za korisnika i projektanta

Platform Independent Model – PIM.Model IS nezavisan od implementacijske platforme. Specifikacija sustava

Platform Description Model –PDMModel implementacijske platforme

Platform Specific Model- PSMModel IS implementiran u datomokruženju.

TRENDOVI U RAZVOJU ŽIVOTNOG CIKLUSA – Razvoj sofvera kao usluge u Cloud Computing-u

OPEN SOA SaaS SDLC – moderni konceptSDLC se definira kao kombinacija vrata (dveri), uloga i odgovornosti; SDLC aktivnosti se dijele u procese kao grupe primjerenim im aktivnostima. Vrata (gate) – točka odluke ili prijelaza na drugu aktivnost u projektuUloga – pojedinca ili grupe koji sudjeluje u projektuOdgovornost - cilj (akcija, dokument ili drugo postignuće za koje je uloga dodjeljena nositeljuProces/Procedura – jedna ili više aktivnosti usmjerena na pojedinačnu ulogu i njezinu odgovornost za projekt

OIIS -2013/14

16

OPEN SOA SaaS SDLC

Izvor: http://www.saassdlc.com/OIIS -2013/14

Kompleksnost faza u SaaS SDLC Primjer: Inicijalizacija... Početno istraživanje (survey phase, initial study)

prethodna istraživanja; prepoznavanje problema, potreba ili prilikaŠto su pokretači promjena

nezadovoljstvo aplikacijama i/ili podacima (nepouzdanost, nedostupnost,manjkavost)nestabilnost aplikacija, podaci koji nedostaju, potreba za novim funkcijamareorganizacija – promjene organizacijske strukture, promjene poslovnih procesapokazatelji poslovanjanpr. pad prodaje, uska grla proizvodnje, neplanirano i nejasno povećanje troškovazastarjela tehnologija(problem održavanja), sučelja (Internet), baze podataka

Treba li pokrenuti projekt?Postavljanje svrhe

OIIS -2013/14

Kompleksnost faza u SaaS SDLC Primjer: Inicijalizacija... Generiranje projektne ideje (poslovnog slučaja)

Reference - Naziv projekta/reference, Izvor/osnova/postojeće stanje Kontekst – poslovni ciljevi, poslovna strateška opredjeljenja, prioriteti Pretpostavljene vrijednosti – Poželjni izlazi, Očekivane koristi, Kvantificirane vrijednosti izlaza, Finacijske procjene, Procjene rizikaFokus – Obujam problema/rješenja, pretpostavke/ograničenja, moguće opcije , procjena kompleksnosti Postignuća - načelne koristi koje se očekuju, organizacijska područja na koja se projekt odnosi, zainteresirane strane i njihvoe ovisnostiRadni učinci – Pristup, faze, aktivnosti, raspored aktivnsoti, procijenjeni kritični putevi Phase/stage definitions (Project (change) activities, Technical delivery activities, Workload estimate/breakdown, Project plan and schedule, Critical path) Resursi – Projektni tim i vodstvo, Upravljanje projektom, Financiranje Obveze – projektna kontrola, izvječćivanje, raspored budžetaPovjerenstvo za odobrenje projekta

Izvor: http://en.wikipedia.org/wiki/Business_case)

OIIS -2013/14

Kompleksnost faza u SaaS SDLC Primjer: Definicija...

Snimka – analiza postojećeg stanjaBrzo vrednovanje identificiranih problema, potreba ili prilika ili direktivaProcjena mogućih rješenjaSnimka postojećeg poslovnog sustavaSnimka postojećih informacijskih podsustava

OIIS -2013/14

Kompleksnost faza u SaaS SDLC Primjer: Definicija... Planiranje

Izrada početnog plana Podjela projekta u potprojekterazrada projekta u manje cjeline i određivanje redoslijeda izradeza pojedini projekt izrađuje se plan rada (work breakdown structure)obavlja se razrada i raspodjela poslova te izrada vremenskog rasporedamogući načini podjele posla na cjeline tako da:cjelinu može obaviti jedna osoba ili ekipacjelina se može obaviti jednom metodomposao završi jednim “proizvodom” (dokumentom, aplikacijom ili podsustavom)

Izrada početnog plana razvoja ISpočetni glavni plan projekta (master plan, baseline plan)podprojekti, prioriteti, …okvirni vremenski plan po fazamadorađuje se i ažurira sukladno napretku projekta

Prezentacija projekta radi traženja suglasnosti o nastavku projektakonsolidirani prijedlog projekta (project charter) može poslužiti kao interniugovor projekta (Izvor: PIS, Kalpić,51)

OIIS -2013/14

Kompleksnost faza u SaaS SDLC Primjer: Definicija... Ciljevi

Primjeri poslovnih ciljevaZaprimanje narudžbe i rezervacije od klijenata putem internetaPrecizna evidencija materijalnih troškova po pogonimaMinimizacija zaliha materijala i trgovačke robe na skladištu s dojavom o minimumima, vremenu stajanja i aktivnim mjerama prodajeOnline prodaja izbor iz kataloga i marketinške promidžbe na internetu

OgraničenjaOsoblje

Nužnost obrazovanja postojećeg kadraDozvoljeni broj novih kadrova

Materijalni trošakUredski materijalPotrošni materijalSoftver – sistemski i opći

Računalna opremaRačunala (osobna i serveri)MrežaPisači i ostala oprema

Financijska sredstvaNeposredni troškovi uvođenja sustavaTroškovi održavanja sustava

OIIS -2013/14

17

Kompleksnost faza u SaaS SDLC Primjer: Definicija...

Modeliranje postojećeg sustava –SvrhaPreciziranje dosega projektaVerifikacija razumijevanja problema i usaglašavanje percepcije sustava i stavova između sudionika (korisnici, informatičari)

Globalni, okvirni, grubi modeliModel organizacije i resursa

kontekst, organizacijska struktura, prostorni raspored sredstavaGlobalni model procesa

funkcionalna dekompozicijatok ključnih poslovnih procesakolanje dokumenata i protok informacija

Globalni model entiteti-veze (enterprise data model)kategorije podataka – klase podataka (ne razredi objekata!)

(Izvor: http://www.zpm.fer.hr/courses/pis)

OIIS -2013/14

Kompleksnost faza u SaaS SDLC Primjer: Definicija... Prijedlog idejnog rješenja -dokument

SažetakSažetak problema, mogućnosti i direktivaKratki navod ciljeva unaprjeđenja sustavaStrategijske odredniceKratki navod sadržaja izvješćaPoznate informacijePopis održanih razgovora i koordiniranihgrupnih sastanakaPopis ostalih izvora informacijaOpis tehnika korištenih u analiziPregled postojećeg sustavaStrategijske odrednice Modeli postojećeg sustava

Analiza postojećeg sustavaproblemi, mogućnosti i analizauzroka i posljedica za pojedineelementePerformanceInformacijeEkonomijaKontrolaUčinkovitostUsluge (servisi)

Detaljni prijedloziCiljevi i prioriteti unaprjeđenja sustavaPrepreke unaprjeđenja sustavaPlan projekta

Precizirani doseg projektaRevidirani glavni planDetaljni plan za slijedeći korak

Izvor: http://www.zpm.fer.hr/courses/pis

OIIS -2013/14

Procesi razvoja – Ujedinjeni razvojni proces

OIIS -2013/14

Danas: RATIONAL UNIFIED PROCESS

Rational Unified ProcessPočinjanje (Inception)opravdanje razloga za pokretanje projektaprikupljanje najvažnijih zahtjeva (10% detaljno)određivanje dosega projektaElaboracija (Elaboration)prikupljanje detaljnih zahtjeva (80%)globalna (high-level) analiza i dizajnustanovljavanje osnovne arhitektureplaniranje konstrukcije

Konstrukcija, gradnja (Construction)prikupljanje ostalih zahtjeva + promjene zahtjevarazrada arhitekture i izrada sustavakontinuirana integracijaPrijelaz (Transition)beta testiranje, podešavanje performansi, poduka korisnikaprovjera prihvatljivosti i zadovoljstva korisnikaPost-implementacija (Post-deployment)nastavak evolucijskog razvojauz očuvanje integriteta aplikacija

OIIS -2013/14

SDLC - situacijeTko i kako izgrađuje

sustavInsourcingSelfsourcingPrototypingOutsourcing

Obujam projektaMinorna poboljšanjaZnačajne promjeneNovi sustavMali sustavVeliki sustav

OIIS -2013/14

Tko i kako izrađuje sustav -Insourcing

Provodi se ako u poslovnom sustavu postoje IT stručnjaci koji su u stanju kreirati novi sustav. Provodi se kroz slijedeće faze:Planiranje – utvrđivanje plana za informacijskog sustava kroz:

Definiranje sustava koji se namjerava razviti – temeljem priroriteta i kritičnih faktora uspjeha Obujam projekta – (scope) – identificiraju se zahtjevi i poželjni rezultati Razvoj projektnog plana – detaljiziraju se i formaliziraju zaatci koji se moraju izvršitiUpravljanje nadzorom nad projektnim planom

Analiza – korisnici i IT specijalisti surađuju na prikupljanju, razumijevanju i objašnjavanju korisničkih zahtjeva, prioritetima i sugestijama za poboljšanjeOblikovanje – stvara se tehnički opis sustava kroz:

Oblikovanje tehničke arhitekture (softver, hardver, komunikacije....) Oblikovanje sistemskog modela – grafičko kreiranje modela, prijedlog grafičkih sučelja, arhitekture baze podataka.Popis testnih uvjeta za pojedina rješenja i zahtjeve

OIIS -2013/14

18

Tko i kako izrađuje sustav -Insourcing - nastavak

Razvoj – prevođenje oblikovanog logičkog sustava u fizički kroz: Izgradnju tehničke arhitekture kroz nabavku potrebne opreme Izgradnju baze i programa za pojedine zahtjeve

Testiranje – testiranje razvijenog sustava Provjera sustava prema planiranim (željenim) izlazima i stvarnim izlazima; ako postoji razlika proces treba se vratiti na prethodnu fazu.;

Upotreba (implementacija) – sustav se stavlja u službu korisnicima: Kreiraju se uputeProvodi se obuka korisnika

Održavanje – sustava se održava “up to date” stanju respektirajući promjene u organizaciji i okruženju:

Izgrađuje se help desk kao potpora korisnicimaImplementiraju promjene kada su u sustavu potrebne.

OIIS -2013/14

Tko i kako izrađuje sustav -Selfsourcing

Provodi se u slučaju da postoje stručnjaci koji su sposobni izraditi plan i koncipirati sustavUsuglašavanje sustava s ciljevima organizacije i snažni naglasak na vremenu potrebnom za stvaranje sustava. Utvrđivanje potrebnih vanjskih usluga od IT specijalista Dokumentiranje i formaliziranje sustava za konačne korisnikeOsiguravanje potrebne potpore u slučaju promjena u poslovnom sustavu i okruženju.

OIIS -2013/14

Tko i kako izrađuje sustav -Prototyping

kreiranje modela koji prikazuje nužne karakteristike predloženog sustavaPrikupljanje zahtjeva – obavljaju ih kompetentni stručnjaci u poslovnom sustavu uspoređujući ih s postojećim sustavomKreiranje prototipa sustava – tehnički profesionalna rješenja s potrebnim sučeljima i izvješčima. Pregled sustava od profesionalaca koji poznaju poslovne procese i poslovni sustav – kreiranje modela sustava koji će se analizirati , pregled i vrednovanje rješenja, davanje preporuka za postizanje potrebnih izlazaRevidiranje prototipa ako je potrebno Plasiranje ideja o novom sustavu na tržište

OIIS -2013/14

Tko i kako izrađuje sustav -Outsourcing

Zapošljava se vanjska firma tako da se dobije sustav najbolje moguće kvlaitete:Outsourcing za razvoj softvera-

Kupovina gotovog softvera i posebne nadoplate za modifikacije Outsourcing razovja cjelokupnog sustava za koji ne postoji softver

Izbor ciljnog sustava - treba osigurati da ne postoje kritičke informacije koje treča strana ne bi trebala vidjeti. Utvrditi logičke zahtjeve – IT specijalisti i stručnjaci iz poslovnog sustava surađuju na oblikovanju aplikacije i raspravljaju koji se zadatci moraju poduzeti da bi se dobila rješenja koja u potpunosti pokrivaju zahtjeve korisnikaKreiranje zahtjeva za ponudu – zahtjev mora sadržavati sve specifikacije koje sustav mora imati da bi se temeljem toga napravio poslovni ugovor. Procjenjuju se ponude i vrši izbor ponuđača. Testiranje i prihvaćanje rješenja i potpis ugovoraPromatranje, kontrola i ponovo vrednovanje – sustav se mora održavati i prilagođavati promjenama relevantnim za poslovnu organizaciju.

OIIS -2013/14

OIIS -2013/14

MODELI ASPEKATA IS-AModeli podataka / oblikovanje podataka (data modelling)

model podataka – ŠTO su podaci, odnosno što opisuju podacikonceptualni model - opisuje podatke i veze između podataka entiteti-veze (entity-relationship model)logički model – opisuje strukturu podataka i logičkih datoteka, najčešće relacijskimodel podataka (relational data model)

Modeli procesa/funkcija (process modelling, functional decomposition)model funkcija i procesa – KAKO se prikupljaju, obrađuju 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, najčešće dijagram toka podataka (data-flow diagram)

OIIS -2013/14

Modeli aspekata IS-a

Modeli događajamodel događaja – KADA se podaci obrađujurazmatranje učinka koji događaji imaju na procese i podatke te opis stanja, npr.dijagram promjene stanja (state transition diagram)

Modeli resursa/sredstavaizvršitelji - TKO obrađuje podatke, GDJE se nalaze podaci, GDJE se obrađuju podaci

Modeli programastruktura (programskih) modula IS, primjerice strukturnim kartama(http://www.zpm.fer.hr/courses/pis)

19

OIIS -2013/14

Komercijalne metodologijeNeke strukturirane metodologije:

AD/Cycle (Application Development Cycle)BSP (Business System Planning)CASE*MethodIEM (Information Engineering Methodology, Martin)JSD/JSP (Jackson System Development / Jackson System Programming)SA/SD (Structured Analysis / Structured Design)SASS (Structured Analysis and System Specification)SSM/M (Soft Systems Method / Multiview)SSA (Structured System Analysis)SSADM (Structured System Analysis and Design Method)Yourdon (Yourdon Structured Method) (http://www.yourdon.com/strucanalysis/wiki/

Objektno usmjerene metodologije:Yourdon/OO (Yourdon / Object Oriented)OMT (Object Modelling Technique)BOOCH (Booch’93)Schlaer-MellorUnified Modelling Process (Rational)

Ključni problemi s metodamaSTRUKTURNE

Podesne za statički prikaz dobro definiranih sustavaNisu riješile problem dinamike sustava i nepodesne su za vremenski brzo promjenjive podatkeNefleksibilnostVremenski zahtjevne

OBJEKTNEOpisuju sustav sa svih aspekata uključujući njegovu dinamikuZahtijevaju visoku razinu apstrakcijeFleksibilnost i adaptabilnost definiranih klasa na različite tipove problema

OIIS -2013/14

OIIS -2013/14

Integrativni “alati” za modeliranje

Tendiraju sustav modelirati s različitih aspekataPokušavaju prikazati statičku i dinamičku stranu sustavaInkorporirati ciljeve poslovnog sustavaEkonomiju izgradnje sustavaPraćenje performanci sustavaOmogućiti ponovnu upotrebu modela u promjenjenim uvjetima funkcioniranja sustavaBiti razumljivi i korisnicima i kreatorima IS-aIntegriraju modele podataka, procesa, funkcija, resursa iorganizacije

OIIS -2013/14

Integrativni “alati” za modeliranjePrednosti:

razumijevanje procesapomoć pri određivanju ključnih faktora koji utječu na performanse procesaanaliza osjetljivosti procesa na promjeneizrada “što-ako” scenarija i razvoj alternativnih rješenjapoboljšanje procesastandardizacija procesa i proceduraprimjena modela procesa za razvoj IS

OIIS -2013/14

Integrativni “alati” za modeliranjeNedostaci:

ispreplitanje modela postojećeg i željenog stanjapogrešno odabrani sudionici projektapuno ispravaka modelaproblemi pri prikupljanju podataka o procesimapostojanje iznimkimodel nikada nije gotovprikaz modela na jako niskom nivou (detaljizacija)problem prevođenja modela procesa u model ISproblem održavanja i korištenja modela procesa

(Izvor: http://www.efzg.hr/default.aspx?id=4018)

OIIS -2013/14

Standardi za (konceptualno) modeliranje (i metamodeliranje) poslovnih procesa i IS-a

OMG – BOMSIG (OMG Business Object Management Special Interest Group springs form the mainstream of the Object Management Group)

CORBAUML

Lista principa ili kriterija za vrednovanje ciljeva:Obujam i granice onoga što će se modeliratiVrednovanje direktnosti modelaPročiščavanje primarne i sekundarne upotrebe modelaVrenovanje vještina i znanja za kreiranje i korištenje modelaVrednovanje upotrebe modela od strane strojaIdentifikacija alata i jezika za modeliranje

Projekti razvoja modelaIS TR 9007.

ISO/IEC JTC1 project 21.63.1 Conceptual Schema Modelling Facility Work of the OMG Business Object Management Special Interest Group ISO/IEC 10746 Basic Reference Model of OpenDistributed Processing ISO/IEC 13249-1:2007ISO/IEC 19763-3:2007ISO/IEC 19763-1:2007

20

OIIS -2013/14

Strukturni modeli SDAT - IDEF – modeli i metodologijeIDEF metode

IDEF0 – funkcionalno modeliranjeIDEF1 – informacijsko modeliranje temeljeno na relacijskom modeluIDEF2 – simulacijsko modeliranje –sistemska dinamikaIDEF1X – modeliranje podataka temeljeno na relacijskom modeluIDEF3 – obuhvat za opis tokova procesaIDEF4 – objektno-orijentirani dizajnIDEF5 – obuhvat za opis ontologijeIDEF6 – Logička podloga za obuhvat oblikovanja

IDEF7- metoda za reviziju IS-aIDEF8 – modeliranje korisničkih sučeljaIDEF9 – specifikacija za oblikovanje IS-a vođena scenarijemIDEF10 – implementacija modelske arhitektureIDEF11 – modeliranje informacijskih smetnjiIDEF12 – modeliranje organizacijeIDEF13 – oblikovanje i mapiranje sheme stablaIDEF14 – oblikovanje mreže

Objektno orijentirani modeli -aspekti

OIIS -2013/14

Za svaki aspekt daje se statički i dinamički opis sustava

Objektno orijentirani modeli –dijagrami UML -a

OIIS -2013/14

Use CaseDiagramsUse Case

DiagramsDijagramislučajeva korišćenja

ScenarioDiagramsScenario

DiagramsDijagramikolaboracije

StateDiagramsState

DiagramsDijagramikomponenti

ComponentDiagramsComponent

DiagramsDijagrami Rasporeda

StateDiagramsState

DiagramsDijagramiobjekata

ScenarioDiagramsScenario

DiagramsDijagrami prelaza stanja

Use CaseDiagramsUse Case

DiagramsDijagramisekvenci

StateDiagramsState

DiagramsDijagrami klasa

Dijagramiaktivnosti

ModeliDinamički Statički

OIIS -2013/14

OMG modeli i specifikacije (Object Management Group Initiative)

http://www.omg.org/technology/documents/spec_catalog.htmBUSINESS MODELING SPECIFICATIONS

Business Motivation ModelBusiness Process Definition MetamodelBusiness Process Maturity ModelBusiness Process Modeling NotationSemantics of Business Vocabulary and Business RulesWorkflow Management Facility

MIDDLEWARE SPECIFICATIONSCORBA/IIOP SpecificationsData Distribution Service (DDS) SpecificationsSpecialized CORBA Specifications

LANGUAGE MAPPING SPECIFICATIONSIDL / Language Mapping SpecificationsMODELING AND METADATA SPECIFICATIONSUML, MOF, CWM and XMI Specifications

Literaturahttp://en.wikipedia.org/wiki/Systems_Development_Life_Cyclehttp://www.usdoj.gov/jmd/irm/lifecycle/table.htmhttp://www.house.gov/cao-opp/PDFSolicitations/SDLCPOL.pdfhttp://www.isaca.org/http://www.ambysoft.com/essays/agileLifecycle.htmlhttp://www.saassdlc.com/http://www.zpm.fer.hr/courses/pisBill Olivier, Development Director, JISC Domain Mapping & Modelling, http://www.jisc.ac.uk/http://www.via-nova-architectura.org/proceedings/emmsad-05/a-historical-perspective-on-conceptual-modelling-from-information-algebra-4.htmlhttp://www.ambysoft.com/unifiedprocess/agileUP.html, http://www.agilealliance.org/, http://www.agile.comhttp://www.extremeprogramming.org/index.html

OIIS -2013/14 OIIS -2013/14

Strateško planiranje, analiza sustava i korisničkih zahtjeva, studija izvodljivosti


21

STRATEŠKO PLANIRANJE INFORMACIJSKOG SUSTAVA

POSLOVNI SUSTAV I INFORMACIJSKI SUSTAV

OIIS -2013/14 OIIS -2013/14

Strateško planiranje IS-a Metode i metodike strateškog planiranja IS-aNajstarije BSP metoda i Rockard-ova analiza, nakon kojih je nastao čitav splet drugih metoda i modela kao što su: Earl model, End-Means, CSF analiza, 5F-metoda, SWOT, BCG itd. A. Cassidy načinila je praktični priručnik za strateško planiranje IS-a. Također, i pojedine metodike razvoja IS-a kao što su SPIS, SSADM, MIRIS, ARIS, CASE*Method i druge, omogućavaju izradu strateškog plana IS-a.

OIIS -2013/14

Earl-ov model

Značajke Faza 1 Faza 2 Faza 3 Faza 4 Faza 5

Fokus Projektiranje aplikacija

Definiranje potreba korisnika

Detaljno planiranje IS-a

Procjena strateške prednosti

Uključivanje IS-a u strategiju poslovanja

Ključni ciljevi Pridobivanje poslovodstva

Usaglašavanje prioriteta razvoja aplikacija

Usklađivanje funkcija aplikacija

Postizanje poslovnih učinaka

Povezivanje IS-a i poslovne strategije

Inicijatorplaniranja

Ponuda informacijskih tehnologija

Više poslovodstvoKorisnici i razvoj

informacijskih tehnologija

Poslovodstvo i korisnici

Usuglašeno: poslovodstvo, korisnici i IT

Pristupplaniranju

Razvoj aplikacija “odozdo prema gore”

Analiza potreba “odozgo prema dolje”

Uravnoteženo: “odozdo gore” i “odozgo dolje”

Poduzetnički –korisničke inovacije

Više kombiniranih pristupa

Opća značajka Planiranje vođeno tehnologijom

Planiranje vođeno metodama

Planiranje vođeno troškovima

Planiranje prema poslovnim ciljevima

Planiranje prema strateškim ciljevima

OIIS -2013/14

Cassidy model

Vizija poslovnog sustava

IS misija i ciljevi

IS strategija

IT arhitektura

Sadašnji sustav

OIIS -2013/14

Cassidy model – faze razvoja IS-aKonceptualna poslovna razina je prva faza

A. Cassidy modela za koju u praksi treba 2-4 tjedna, a čiji je rezultat dokumentacija sljedećeg sadržaja:poslovni plan (misija, vizija, ciljevi, poslovni prioriteti),poslovne informacije,zahtjevi okoline,eksterni zahtjevi,operativna vizija.

Detaljna poslovna analiza je druga faza koju fokusira poslovanje i za koju u praksi treba 3-6 tjedana. Njen rezultat je sljedeća dokumentacija:poslovni procesi,informacijske potrebe,poslovni zahtjevi.

Konceptualni plan i vizija IS-a je treća faza koja pozornost usmjerava na IS. U praksi traje 2-4 tjedna, a njen rezultat je sljedeća dokumentacija:sadašnji IS (razina izgrađenosti, struktura, aplikacije, okolina, očekivanja),eksterni razvoj (industrijski trendovi, itd.)novi pravci razvoja IS-a (vizija, misija, strategija, Strateški ciljevi, IS arhitektura, IT arhitektura, politika i odgovornosti).

Izrada detaljnih IS smjernica. U praksi obično traje 6-12 mjeseci, a daje sljedeću dokumentaciju:GAP analiza sadašnje – buduće,preporuke (troškovi, vrijeme, resursi, prednosti, nedostatci, usporedba) iROI analiza.



OIIS -2013/14

SPIS – dugoročno planiranje korisnih učinaka informacijskog sustava (IS) i uporabe informacijske tehnologije (IT) u poslovanju

Problemi/koraci kod modeliranja

Metode i tehnike§ - strateške

# - strukturne- objektne

Ulazne/Izlazne vrijednosti metodeUlazi Izlazi

Metoda

Ocjena metodeV – vrlo snažnaS – snažnaK - korisna

1.Usklađivanje buduće strategije poslovnog sustava s raspoloživim informacijskim tehnologijama

§ Balanced Scorecard§ BCG – matrica§ 5F – model§ “Value chain” model

Poslovni sustav / Procjena performansi sustavaPoslovna strategija / Prioriteti razvoja IS-aPoslovna strategija / Informacije za ostvarenje poslovnih ciljevaPrimarni procesi / Doprinos IT profitabilnosti primarnih procesa

KSKV

2. Određivanje osnovnih procesa postojećeg poslovnog sustava

# BSP – dekompozicija# BSP – analiza životnog

ciklusa resursa

Poslovi / Poslovni procesiOsnovni resursi sustava / Poslovni procesi

VS

3. Preustroj (reinženjering) sustava u skladu s odabranom poslovnom strategijom

§ BPR§ SWOT analiza

# Funkcionalna shema

Poslovni procesi / Korisnički usmjereni procesiNovi poslovni procesi / Ocjena provedivostiPoslovni procesi / Poslovna tehnologija

SVK

22

OIIS -2013/14

SPIS-4. Određivanje optimalne arhitekture informacijskog sustava

# Matrica poslovne tehnologije

# Analiza afiniteta (adhezije)# Genetički algoritmi

Veze među procesima / Podsustavi novog IS-aVeze među procesima / Rojevi (Clusters)Veze među procesima / Grupirani procesi

VSK

5. Određivanje kritičnih faktora uspjeha i informacija za upravljanje sustavom

§ CSF analiza (Rockart)# “Ends-Means” analiza

Poslovna tehnologija / Kritične informacijePoslovni procesi / Informacije za povećanje učinkovitosti i djelotvornosti poslovnih procesa

SK

6. Fizičko modeliranje poslovnih procesa novog sustava

# Organizacijski dijagram toka podataka (OFD)

# Tok aktivnosti (AFD)# Radni dijagram (WFD)

Organizacijski ustroj / Hijerarhijske veze među organizacijskim jedinicamaPoslovni procesi / Veze među aktivnostimaPoslovni procesi / Radni koraci izvršitelja

VSS

7. Logičko modeliranje procesa za informacijski sustav novog poslovnog sustava

# Dijagram toka podataka (DFD)

# Akcijski dijagram (AD)# Stabla i tablice odlučivanja

Poslovni procesi / Informacijski procesi s tokovima, spremištima i okolinomPoslovni procesi / Informacijski procesiPoslovni procesi / Unutrašnja logika informacijskih procesa

VSK

OIIS -2013/14

SPIS8 .Procjena učinaka novog

informacijskog sustava# Simulacijsko modeliranje

(npr. ARIS)Poslovna tehnologija / Performanse

nove poslovne tehnologijeK

9. Osnovno oblikovanje programskih rješenja (procedure, događaji, transakcije)

# Objektno prošireni HIPO dijagramTranzicijskidijagram

Podsustavi novog IS-a / Osnovna struktura programskih rješenja (SW-a)

Transakcije / Događaji

VS

10. Modeliranje podataka sustava # ERA modelObjektni model

Poslovni podaci / ERA modelPoslovni podaci / Objekti (podaci,

operacije) i klase objekata

VS

11. Detaljno oblikovanje strukture i algoritama za programe i procedure

# Akcijski dijagramObjektni scenarij

Informacijski procesi / Logički odnosi programskih procedura (podprocesa)

Objekti / Ponašanje objekata

V

S

OIIS -2013/14

SPIS12. Izrada relacijskog modela podataka

# Relacijski model# Normalizacija

ERA model / Relacijski modelRelacijski model / Normalizirane relacije

VV

13. Izrada programske opreme (Aplication Softwre)

# CASE alati i 4 GLOO-CASE alati

Normalizirane relacije, HIPO / ProgramiPonašanje objekata /Klase procedura, nasljeđivanje i OO-Programi

VS

14. Integracija i procjena složenosti aplikacije

# Function Point Analiza Programi i OO-Programi / Složenost aplikacija S

15. Uvođenje IS-a, njegovo vrednovanje i procjena učinaka na poslovni sustav

# SPICE, TQM# Balanced Scorecard

Informacijski sustav / Kvaliteta IS-aNovi poslovni sustav / Usklađena procjena performansi novog sustava

KK


IS/kolegiji/uis/nastavni_materijali.htmlOIIS -2013/14

Ostale metode strateškog planiranja IS-aSSADM (Structured Systems Analysis And Design

Methodology) sastoji se iz sljedećih 7 faza:1. Studije izvedivosti,2. Ispitivanja postojećeg stanja,3. Moguće izvedbe poslovnog sustava,4. Definiranja zahtjeva,5. Moguće tehničke izvedbe sustava,6. Logičkog oblikovanja sustava i7. Fizičkog oblikovanja sustava.

http://en.wikipedia.org/wiki/SSADMhttp://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.htmlhttp://www.ogcio.gov.hk/eng/prodev/es3.htm

OIIS -2013/14


Metodika MIRIS (Metodika za razvoj IS-a)sastoji se od dvije temeljne faze projektiranja: logičkog i fizičkog oblikovanja, koje se dalje dijele na po 3 koraka. Logičko oblikovanje čini strateško planiranje IS-a, glavni projekt i izvedbeni projekt, dok je fizičko oblikovanje izvedba programske potpore, uvođenje i primjena te održavanje.http://www.ris.hr/page.php?id=4

OIIS -2013/14


CASE*Method se sastoji od 6 faza: strategije, analize, oblikovanja, izgradnje + dokumentiranja, uvođenja i primjene IS-a

http://www.sei.cmu.edu/legacy/case/case_whatis.htmlhttp://www.cs.queensu.ca/Software-Engineering/tools.html

23

OIIS -2013/14

Metodika CoBIT (Control of Objectives of IT) kao osnova povezivanja PS-a i IS-a (http://www.isaca.org/ )

Kako bi se osiguralo da je informacijska tehnologija usklađena s poslovanjem i poslovnim ciljevima, razvijeno je sljedeće:modeli zrelosti za strateški izbor i usporedbu s drugima (benchmarking)kritični faktori uspjeha za dovođenje IS procesa pod nadzorključni indikatori ciljeva za nadzor ostvarenja ciljeva IS procesaključni indikatori izvršenja za nadzor provedbe unutar svakog IT procesa.

OIIS -2013/14

Klasični poslovni procesi i nužnost reinžinjerstva poslovnih procesa

“klasično strukturiranje poslovnih sustava temelji na uobičajenim organizacijskim oblicima, kao što su funkcionalni, predmetni, matrični, projektni i drugi oblici. Međutim, takve organizacije uspješne su samo do određene razine kojom se postiže ograničena učinkovitost poslovnog sustava. Razlog tome jest nejasno postavljena poslovna tehnologija, poslovni procesi najčešće nisu niti definirani, a ako i jesu, obično u njima ima puno nelogičnosti, uskih grla, ponavljanja i praznih hodova.”(Krakar,str.149)Uobičajeno pitanje “Kako bolje raditi ono što radimo?” zamjenjuju se s pitanjem “Zašto radimo ono što radimo i možemo li raditi nešto što daje veći učinak?” To je bio početak koncepta suvremenog BPI-a



OIIS -2013/14

(Re)inžinjerstvo poslovnih procesa

Rezultat inženjeringa i reinženjeringa poslovnih procesa je moderna poslovna organizacija. Koristi koji se dobivaju ovakovim pristupom su:jasna vidljivost procesa,mogućnost njihovog preoblikovanja,mogućnost otklanjanja nelogičnosti među procesima,određivanje vremena i troškova procesa,bolja integracija s dobavljačima i kupcima,bolja integracija dijelova poslovnog sustava, efikasnije upravljanje,kvalitetnija i brža proizvodnja/usluge,olakšana informatizacija itd.” (Krakar,str.149)

OIIS -2013/14

(Re)inžinjerstvo poslovnih procesa

Reinženjering je mogućnost promjene industrijske organizacije i načina upravljanja. Hammer i Champy (M. Hammer-a (Reeingineering work: don't automate - obliterate, 1990. g.), a naročito knjigom M. Hammer-a i J. Champy-a (Reeingineering the Corporation, 1993. g.) zaključili su da reinženjering započinje strateškim pitanjem – kako bolje anticipirati stalne promjene želja kupaca i kako uspostaviti bolju poslovnu organizaciju da bi se postigla maksimalna poslovna uspješnost?Definicija reinženjeringa prema ovim autorima kaže da je to temeljita promjena načina razmišljanja i radikalni redizajn organizacije putem poslovnih procesa na način da se postignu dramatična poboljšanja u bitnim značajkama, kao što su troškovi, kvaliteta, usluge i brzina. Ova definicija dakle sadrži 4 ključne riječi: temeljito, radikalno, dramatično i procesno.

OIIS -2013/14

Funkcionalni i procesni pristup

Funkcionalni-organizacija struktura radi postizanja cilja

Procesni: stvaranje lanca vrijednosti

Porterov lanac vrijednosti

nabava za proizvodnju

skladištenje i distribucijaproizvodnja prodaja i

marketing

potpora nakon

prodaje

razvoj infrastrukture poslovnog sustava

administracija, opći i pravni poslovi

informacijski sustav

upravljanje ljudskim resursima

računovodstvo i financije dodanavrijednost

seku

ndar

ni p

roce

si

primarni procesi

OIIS -2013/14

Suvremeni modeli i metodolgijeARIS (Architecture of Integrated Information Systems) razvija se od 1992. g. kao metodika za cjelovito povezivanje poslovnog i informacijskog sustava (http://www2.ids-scheer.com)Zachman-ov kocept http://www.zifa.com/

Ostali koncepti:CIMOSA nastao u okviru ESPRIT programa Europske zajednice, nastojanja IBM-ovog AD/CYCLE-a koja su rezultirala proizvodom AIX/CASE, Microsoft-ov pristup vrlo sličan AD/CYCLE-ovom, objektno orijentirani koncepti itd.

24

ANALIZA KORISNIČKIH ZAHTJEVA

OIIS -2013/14

O čemu treba voditi računa

Nemoguće je izgraditi učinkoviti programski sustav za korisnika koji ne zna što treba; sve što mu napravite nije ono što on “očekuje” (Majdanžić)

Ako imate računalo pete generacije, softver četvrte, organizaciju treće a kadrove druge generacije sustav će raditi u drugoj generaciji (Srića)

Ako napravite sustav koji i budala može koristiti, samo budala će ga i koristiti (Shaw)

OIIS -2013/14

Analiza zahtjeva – definicije

U softverskom inžinjerstvu obuhvaća zadatke kojima se određuju potrebe ili uvjeti koje mora imati alternativni proizvod uzimajući u obzir moguće konfliktne zahtjeve različitih strana (krajnjeg korisnika i kreatora sustava, na primjer.)

OIIS -2013/14

Odakle se polazi u analizi zahtjeva

Intervjui, radne sjednice i promatranja korisnika u radu sustavaZdruženi zahtjevi kao rezultat analiza zahtjeva korisnika i radnih sjednica (Joint requirements development) managera (poslovnih analitičara), izvršitelja i ICT stručnjaka radi utvrđivanja zahtjeva koji se preklapaju, ukrštavaju i/ili izvode paralelno i na sličan načinListe zahtjeva koji su ugovorom definiraniMjerljivosti izvršenja ciljeva

OIIS -2013/14

Analiza zahtjevaŠto je zahtjev:

IEEE standard definira zahtjeve kao:Uvjet ili sposobnost koje korisnik treba da bi riješio problem ili ostvario cilj.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 mogućnosti definiranih pod (1) ili (2). [IEEE Std 830-1998], [IEEE Std 610.12-1990]Zahtjev mora biti izvediv, mjerljiv, provjerljiv, vezan uz identificiranu poslovnu potrebu ili priliku i dovoljno jasno definiran da bude dostatan za oblikovanje novog sustava

Zahtjevi ne sadrže detalje dizajna, detalje implementacije ili informacije vezane uz planiranje projekta. Pažnja se usmjerava na ono ŠTO se želi izgraditi, a ne ulazi se u detalje kako i kada to napraviti.Za 40-60% pogrešaka u projektu uzrok leži u pogreškama napravljenim u fazi postavljanja zahtjeva. [Leffingwell, 1997]Tipična posljedica su "prazna očekivanja" (expectation gap): razlika između onog što očekuje naručitelj i onoga što je izvoditelj mislio da treba napraviti.Naknadne prepravke mogu predstavljati do 40% troškova razvoja, od čega je 70-85% pripisivo pogrešnim zahtjevima [Leffingwell, 1997].Nepotpuno definirani zahtjevi čine planiranje projekta i praćenje promjena(Izvor: http://www.zpm.fer.hr/courses/pis)

OIIS -2013/14

Što sadrži analiza zahtjevaTri tipa aktivnosti:

Otkrivanje – utvrđivanje zahtjeva; opis svih zahtjeva nakon komunikacije s korisnicima zahtjevamodeliranje zahtjeva. Analiza i komunikacija zahtjeva- određivanje jasnoće, cjelovitosti, nedvosmislenosti, kontradiktornosti zahtjeva i njihovo potrebno razrješenje i mogućnost upravljanja zahtjevimaPostizanje dogovora oko zahtjeva i bilježenje zahtjeva u nekom dokumentiranom obliku (prirodnim jezikom- korisničke priče, slučaja upotrebe ili procesne specifikacije) http://en.wikipedia.org/wiki/Requirements_analysis

Bashar Nuseibeh, Steve Easterbrook, Requirements Engineering: A Roadmap

OIIS -2013/14

25

Primjer zahtjeva MZOŠ –sustav prehranePrimjeri zahtjeva vlasnika sustava

Očekivana novčana uštedaSustav mora biti tako koncipiran da prava na subvencioniranu prehranu može koristiti samo student koji ih je stekao i da ih može koristiti samo usvrhu prehrane.

Sustav mora onemogućiti:korištenje subvencije od strane osoba koje nemaju na to pravozaradu ilegalnih posrednikakorištenje subvencije za druge svrhe osim prehrane naplatu usluga koje nisu pružene

U idealnom slučaju zahtjevi vlasnika podudaraju se s poslovnim ciljevima!


OIIS -2013/14

Primjeri zahtjeva krajnjih korisnika

Prehrana kod bilo kojeg pružatelja uslugaNovi sustav mora omogućiti da student ostvaruje svoje pravo kod bilo kojeg pružatelja usluge subvencionorane prehrane. Dosadašnja praksa je bila da svaki pružatelj usluga izdaje svoje bonove koji se mogu koristiti samo u određenim restoranima.Ukinuti plaćanje unaprijed

Treba izbjeći bilo kakvo plaćanje od strane studenata za potrebe ostvarivanja prava, a posebice unaprijed.

Ukloniti nepotrebne postupke za ostvarivanje pravaSustav mora biti tako koncipiran da kad se studentu jednom zavedu prava na matičnoj ustanovi nisu potrebna nikakva daljnja dokazivanja za ostvarivanje prava kod pružatelja usluga.

Smanjiti rizik gubitka ostvarenih pravaSustav mora onemogućiti zloporabu stečenih prava.

Lakše ostvarivanje ostalih prava iz studentskog standardaNpr. javni prijevoz po povlaštenoj cijeni, kazališta, kina, smještaj u studentskim domovima, student-servis, itd. (Izvor: http://www.zpm.fer.hr/courses/pis)

OIIS -2013/14

Vrste zahtjevaPoslovni zahtjevi (zašto)

Načelni zahtjevi zbog kojih se projekt IS-a pokreće i koi su definirani u strateškim opredjeljenjima tvrtke• primjer: poslovni zahtjev, "Omogućiti Internet prodaju“

Korisnički zahtjevi (zahtjevi krajnjih korisnika)opisuju zadatke koje korisnik mora moći obaviti služeći se aplikacijamasadržani u opisima slučajeva korištenja, tj. opisima scenarija rada

Funkcionalni zahtjevi (što)Funkciopnalni zahtjevi se mogu opisati kao skup ulaza, ponašanja, izlaza, manipulacije podatcima, vrste obrade itd.definiraju softversku funkcionalnost (očekivano ponašanje i operacije koje sustavmože izvoditi) koju treba ugraditi u proizvod da bi omogućio korisnicima obavljanjenjihovih zadataka

Nefunkcionalni zahtjevi (kako ili kako dobro)su zahtjevi koji se mogu smatrati ograničenjima ili zahtjevima za kvalitetom izvedbe; Tipični su takvi zahtjevi raspoloživost sustava, proširivost i troškovi,standardi, pravila i ugovori kojih se proizvod mora pridržavati, opisi vanjskih sučelja,zahtjevi na performance, ograničenja na dizajn i implementaciju, te svojstva kvalitete(preciziraju opis proizvoda navodeći karakteristike proizvoda u različitim dimenzijakoja su važne ili korisniku, ili graditelju)


OIIS -2013/14

Vrste zahtjevaZahtjevi vanjskih sučeljaOvaj razred zahtjeva opisuje veze između sustava i vanjskog svijeta. Specifikacijasistemskih zahtjeva trebala bi uključivati odlomke za ove zahtjeve uključujući i sučeljate mehanizme komunikacije za korisnike, hardver i druge softverske sustave.OgraničenjaOgraničenja su uvjeti koji ograničavanju izbor rješenja raspoloživih dizajneru iliprogrameru. Spadaju u nefunkcionalne zahtjeve i trebaju biti dokumentirani. Neopravdana ograničenja treba pokušati odbaciti jer onemogućavaju postizanjenajboljeg rješenja. Također mogu umanjiti primjenu komercijalnog softvera ikomponenti u rješenju. Neka ograničenja mogu pomoći u zadovoljavaju atributa kvalitete. Primjer je poboljšanje prenosivosti programa korištenjem samo standardnih naredbi nekog računalnog jezika.Definicije podatakaDefinicija podataka je bilo koji opis formata, dozvoljenih vrijednosti, pretpostavljenih vrijednosti ili kompozicija složenih podatkovnih struktura. Sve definicije bi trebalo pohraniti u rječnik podataka, kao glavno kazalo za sudionike na projektu.Ideje o rješenjuAko korisnik opisuje specifičan način interakcije sa sustavom kojom bi mogao obaviti neku akciju, npr. «Korisnik odabire podatak koji on želi iz padajuće liste», on predlaže rješenje, a ne zahtjev. Predloženo rješenje može odvući pažnju od pravih zahtjeva.Kod postavljanja zahtjeva treba se usmjeriti na ono što je potrebno obaviti, a ne na način realizacije. Treba istražiti zašto korisnik predlaže određenu ugradnju jer to može pomoći u razumijevanju stvarne potrebe i korisnikovih očekivanja o načinu kako bi sustav trebao raditi.


OIIS -2013/14

Analiza prioriteta zahtjevaNužno svojstvo - Da li vlasnik sustava nešto stvarno mora imati?

Postoji tendencija da se previše zahtjeva proglasi nužnim!Po definiciji, ako sustav ne uključuje nužne zahtjeve, taj sustav ne može ispuniti svoju svrhu.Treba testirati svaki zahtjev koji se smatra nužnim i probati ga rangirati.Ako se zahtjev može rangirati onda nije obvezan!Potpuno obvezni zahtjevi se ne mogu rangirati jer su nužni za prvuverziju sustava!

Poželjno svojstvo - Funkcije koje korisnik želi na kraju imatiRanije verzije sustava mogu pružiti (ne potpunu) funkcionalnost bez tihzahtjeva.Poželjni zahtjevi mogu i trebaju biti rangirani.

Neobvezna svojstva - Proizvoljni zahtjeviSvojstva i mogućnosti bez kojih se može iako bi ih lijepo bilo imati, to nisu pravi zahtjevi. Ovi zahtjevi također mogu biti rangirani.

OIIS -2013/14

Dokumentiranje analize zahtjevaDefinicija zahtjeva (Requirements Definition)

izjava o stanju i ograničenjima sustava te potrebama - narativni dokument namijenjen korisniku ili ga piše korisnikposlovni i korisnički zahtjevi te njihovi prioritetiuočeni problemi, ključne pretpostavke i preporuke rješenja

Specifikacija zahtjeva (Requirements Specification)često se naziva i funkcionalnom specifikacijom - strukturirani dokument s detaljnim opisom očekivanog ponašanja sustava -namijenjen ugovarateljima i izvoditeljima razvojaugradbeno nezavisan pogled na sustavfunkcionalni i nefunkcionalni zahtjevi te njihovi prioritetimodel organizacijske strukture (strukturni dijagrami)opis protoka dokumenata (dijagrami toka)model procesa (dijagram toka podataka)konceptualni model podataka (dijagram entiteti-veze)

OIIS -2013/14

26

Rizici lošeg planiranja zahtjevaNedovoljna uključenost korisnika

bez korisnika ne može se točno znati što korisnici žele � neprihvatljivi proizvodiČudni korisnički zahtjevi

neopravdana promjena mišljenja tijekom izvedbe � prekoračenja rokova i degradacije kvalitete proizvoda

Nejasni (dvosmisleni) zahtjevisituacija u kojoj čitatelj(i) zahtjeva zahtjev tumače na više načina

Gubljenje vremena i prepravljanjePretjerano ukrašavanježelja izvođača da dodaju novu funkcionalnost "koja bi se trebala svidjeti korisnima" i zahtjev korisnika za dodacima koji dobro izgledaju ali ne pridonose

Funkcionalnostinepotrebni dodaci i gubljenje vremenaminimalističke specifikacije - tendencija postavljanja minimalnih zahtjeva ili skiciranja koncepta, uz želju da ih izvođači nadopune tijekom izvedbefrustracije izvođača, neispunjena, očekivanja korisnika

Zanemarivanje potrebazanemarivanje potreba određenih (grupa) korisnika � stvaranje 'opozicije‘ projektu

OIIS -2013/14

Kakteristike dobro postavljenih zahtjeva

Cilj je napisati dovoljno dobre zahtjeve, na temelju kojih se može pristupiti dizajnu iugradnji uz prihvatljiv stupanj rizika.Svrha: dobro postavljeni zahtjevi su osnova za dobro oblikovanje sustava

OIIS -2013/14

Karakteristike dobro postavljenih zahtjeva

Zahjtev Opis

Kohezivnost Zahtjev definira jednu i samo jednu stvar

Cjelovitost Zahtjev je u potpunost definiran na jednom mjestu bez nedostataka

Konzistentnost Zahtjev nije kontradiktoran ni s koim drugim zahtjevom ili vanjskim zahtjevom

Korektnost Zahtjev u potpunosti udovoljava zahtjevima poslovodstva i korisnika

Aktualnost Zahtjev će biti aktualan duže vrijeme

Observabilnost Zahtjev je vidljiv (prepoznatljiv) vanjskom korisniku i respektira ograničenja

Izvodljivost Zahtjev je izvediv u okviru ograničenja projekta

Nedvosmislenost Zahtjev je jasno iskazan i opisan

Provjerljivost Zahtjev se može provjeriti isnpekcijom, analizom ili testiranjem na sustavu

OIIS -2013/14

Nedovoljno dobro definirani zahtjevi

Nedovoljno definirani zahtjeviPonekad nedostaju informacije o nekom zahtjevu.Takve zahtjeve treba dosljedno označiti posebnom, dogovorenom oznakom npr. TBD (engl. To Be Determined - za odlučiti, razlučiti). Dokument se kasnije može pretraživati po tim oznakama.Implementaciju ovakvih zahtjeva treba odgoditi do razrješenja nedoumice ili barem treba dizajnirati one dijelove sustava koje je lako promijeniti kad se zahtjev konačno definira.U suprotnom će programeri zahtjev ugraditi prema vlastitom nahođenju, koje ne mora biti točno.

OIIS -2013/14

KOJE INFORMACIJE TREBAJU

Korisnički zahtjeviIntervjui Upitnici i ankete

Informacije o postojećem sustavuInformacije o aplikacijama – softverska rješenjaDokumentacijaPoslovni procesi i informacijski tokovi

OIIS -2013/14

Kako doći do informacijaIntervjui s ključnim korisnicima i radne sjednice

Ako naručitelj zapošljava informatičare svakako ih treba uključiti u analizu.Sučeljavanje korisnika i informatičara ubrzava rješavanje proturječnih iskaza.

Upitnici i anketeNadomjestak za intervju ili prikupljanje informacija o resursima.

Analiza dokumentacijeTreba prikupiti sve dokumente značajne za poslovanje, radi boljeg utvrđivanja pravila,

poslovne politike, ciljeva poslovanja te strukture informacija.Prosudba postojećih rješenja na računaluNužna je prosudba postojećih aplikacija i/ili računalom podržanih podataka, radi analize podataka ali i zbog njihove konverzije u novi sustav.Promatranje

Neposredni uvid u poslovne procese promatranjem radnih sredina (način izrade irazmjene dokumenata, procesi osnovne djelatnosti).Drugi načini

Prototipiranje, …Postupak analize mora biti prilagođen korisniku.Evidentiranje rezultata analize poželjno je obaviti CASE pomagalom.

OIIS -2013/14

27

IntervjuiIntervju – ispitivanje pojedinca kroz razgovor s planiranim pitanjima ali i s mogućnošću prilagođavanja s neplaniranim pitanjima; ispitanik ima punu slobodu odgovaranjaIspitanici Neposredni korisnici, rukovoditelji, suradnciIspitivač: osoba iz projektnog tima; organizator, planer, projektantIndividualni intervju – ispitivanje pojedinca ili grupe koja se bavi istim poslom Grupni intervju – ispitivanje grupe u kojoj su korisnici iz više različitih ali međusobno povezanih područja

Primjer intervjua:

Analiza rezultata intervjuiranja; rijetko se samo jednim krugom intervjuiranja dobiva skup svih potrebnih informacija već se intervju ponavlja za neke korisnike i/ili skupine korisnika

OIIS -2013/14

Tehnika intervjuaPriprema za razgovorutvrđivanje informacija koje treba saznatiproučavanje postojeće dokumentacije i prethodnih nalazaodređivanje dokumentacije koju bi trebalo prikupitipriprema pitanja koja će biti postavljena tijekom razgovoraizrada jezgre tema, to jest standardnih pitanjaizrada sveobuhvatnog podsjetnika i izdvajanje prikladnih pitanja

OIIS -2013/14

Upitnici i anketeUpitnik (pismeni intervju)

sadrži pitanja koja se postavljaju tijekom razgovora (okvirno 20)može se dostaviti korisniku prije, umjesto ili nakon intervjuanedostaci:ispitanik može prilagoditi (kontrolirati) svoje odgovoreteško je procijeniti iskrenost (spontanost) odgovoramože obeshrabriti ispitanika

Anketa (inventar)može se obuhvatiti više ispitanikapitanja zatvorenog tipaodgovori i obrada odgovora mogu se standardiziratipogodna za popis resursaPrimjer: IS-Resursi

Intervjuiranje je elastičnije!Pomoću intervjua može se više naučiti o stavovima, osjećajima i motivaciji osoblja.Tijekom intervjua analitičar i ispitanik nalaze se jedan nasuprot drugom, pa analitičarmože promatrati način na koji ispitanik odgovara i po potrebi proširiti ili usmjeritipitanja.


OIIS -2013/14

Proučavanje dokumenataPrikuplja se sve do čega se može doći

Analiza procesaTipični dokumenti: pravilnici i zakoni

Analiza podatakaTipični dokumenti: obrasci (formulari), izvješća

Poželjno je da dokumenti budu reprezentativni, tj. popunjeni na tipičan način.Tako se može ustanoviti koje informacije se uopće unose i na kakav način.

Reprezentativni dokumenti najčešće ne ukazuju na izuzetke, to jest podatke koji se rjeđe bilježe ali ipak trebaju.Također, stalno bilježenje nekih podataka ne mora značiti da su ti podaci stvarno potrebni.Treba prikupiti više uzoraka iste vrste dokumenta! (� sampliranje)

Vrijednost informacija o analiziranoj organizaciji prikupljena (samo) preko dokumenata je niska.

Praksa može odudarati od pravilnika i administrativnih obrazaca.Treba shvatiti zašto i kada dokumenti nastaju, kako se popunjavaju, koliko su potrebnite što treba promijeniti da bi ih se popravilo (sadržaj, lakoća popunjavanja i čitanja)Nužno je modele (podataka) razlučene analizom provjeriti kod korisnika.(Izvor: Kalpić, PIS)

OIIS -2013/14

Analiza postojećih aplikacijaProcjena aplikacija i (baza) podataka u primjeni

korišteni programski jezici i pomagala, uključujući programe za uredsko poslovanje (npr. Excel)podržane funkcije i način posluživanja programameđusobna povezanost različitih aplikacija i podatakapostojeće platforme (računalo, operacijski sustav, mreža, SUBP)sastav i stupanj informatičke izobrazbe korisnika

Nedostaci sklopovske opreme i programske podrškenepovezanost aplikacija (tzv. informatički otoci)loša programska rješenja (funkcionalnost, ergonomija)nepouzdanostintegritet, zaštita i sigurnost podatakanepostojanje programske dokumentacijetehnološka zastarjelost (programski jezici i alati, nemogućnost rada uvišekorisničkom okruženju, grafičko sučelje)

OIIS -2013/14

Analiza postojećih aplikacijaNedostaci modela podatakaRazličitost modela podataka postojećih aplikacijaentiteti iz stvarnog svijeta nisu jednako zastupljeni u postojećim modelimaisti entitet iz stvarnog svijeta pojavljuje se pod različitim nazivimaisti entitet iz stvarnog svijeta opisan je različitim atributimadva ili više entiteta iz stvarnog svijeta prikazano je različitim brojem entiteta upodatkovnim modelimaNedostaci unutar pojedinog modelanedefiniranost identifikatora (primarnih ključeva)nedefiniranost veza među podacima, najčešće kao posljedica nepostojanja primarnih ključevanedefiniranost veza unatoč postojanju primarnih i (drugih) stranih ključeva, kao posljedica razvoja tijekom uporabe i nedosljednostinaglašena zalihost uvedena prilikom izrade zahtjevnih ili složenih programskih rješenjaukupna nenormaliziranost modela

OIIS -2013/14

28

Promatranje procesa poslovnog sustava

Uvid u poslovne procese promatranjem radnih sredinapromatra se lokacija i kretanje ljudi te tijek izvršavanja poslovafizički ulazi i izlazi sustavazaprimanje, izrada i razmjena dokumenataprocesi osnovne djelatnosti, primjerice proizvodnja

Prednostianalitičar je u stanju realno sagledati poslovni procesučinkovitost, ako se dobro provedepouzdanost prikupljenih informacija

Nedostacineučinkovitost, ako se dobro ne provedeutrošak vremenaometanje i neugoda promatranih osobamogućnost manipulacije promatrača npr. prikrivanjem uobičajenog kršenja radnih procedura

Dužina i učestalost promatranjaPodaci dobiveni iz malog broja kratkotrajnih promatranja mogu biti nepouzdani inetočni.

Promatranje na licu mjesta je najteža metoda za pronalaženja činjenica.

OIIS -2013/14

Radni sastanci i sjednice

Radni sastanci, sjednice (workshop)analitičari i korisnici zajednički provode analizu i oblikovanje

Cilj sjednice je (zajedničko) pronalaženjenajboljeg rješenja

poseban prostor i izolacijamoderator, dnevni red i zapisnici

OIIS -2013/14

Radni sastanci i sjednicePrednosti

Sjednice su pogodne za projekte kojima se rješavaju problemi važni za čitavu organizaciju ili veći dio poslovanja.Izbjegavanje specifičnih (egzotičnih) i nejasnih zahtjevaPreciznije ustanovljavanje dosega projektaBolje uočavanje proturječnih zahtjeva

Nedostacisadržaj i dinamikapasivnost sudionika“usitnjavanje” razgovoraudaljavanje od tematrajanjesjednice bi trebale trajati više dana (5-10) u nekoliko tjedanaovom zahtjevu u praksi je vrlo teško udovoljiti zbog obveza sudionikaotpor sjednici i pratećoj izolacijirazmjeran je razini položaja konkretnog sudionikanaglašen kada poduzeće zapošljava informatičare, jer se podrazumijeva da je informatizacija isključivo njihov posao.

Tehnika brainstorminga

OIIS -2013/14

Razvoj prototipaPrototipiranje (prototyping)

Koristi se kada korisnik ne može točno definirati svoje informacijske potrebe prije nego što se izgradi informacijski sustav.Razlog tomu može biti nedostatak postojećeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak teška vizualizacija budućeg sustava.Izrada prototipa

Izgrađuje se sustav koji zadovoljava neke osnovne, inicijalne potrebe.U radu s takvim sustavom korisnik otkriva svoje informacijske potrebe te sesustav modificira kako bi se zadovoljile te potrebe.Postupak korištenje sustava i modificiranja istog iterativno se ponavlja, a informacijske potrebe korisnika otkrivaju korištenjem sustava.

Izrada prototipa pogodna je u onim okruženjima gdje je teško definirati konkretni model sustava te u okruženjima gdje

OIIS -2013/14

Najčešći problemi pri prikupljanju informacijaPonašanja korisnika

Taktika kuhinjskog sudoperakorisnik navodi (preko)brojne potrebe: hrpu nepotrebnih izvještaja, formi, sortiranja, izračuna i sl.ovakav pristup obično je uzrokovan pomanjkanjem iskustva korisnika koji ne zna što bi mu stvarno trebalo zatrebati ili nije u stanju razlučiti ono što je bitno

Taktika dimne zavjesekorisnik traži više mogućnosti a zapravo mu je potrebna samo jedna ili dvijedodatni zahtjevi služe za postizanje bolje nagodbe s analitičaromtaktika obično oslikava korisnika s dobrim poznavanjem onoga što želi, a zahtjevetreba 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 uspješno definiranje problema su male jer samo korisnik može izraziti svoje potrebe i probleme

Korisnik je sklon prešutjeti izuzetke, koji su bitni (nužni !!!) za uspješnu realizaciju, a obično zahtijevaju i najviše napora tijekom ugradnje."To je naša jedina procedura … (osim kada …)"Ne izjednačavati “tako se uvijek radi” s “tako treba raditi”!(Izvor: http://www.zpm.fer.hr/courses/pis)

OIIS -2013/14

STUDIJA IZVODLJIVOSTI IS-A

OIIS -2013/14

29

Analiza izvodljivosti – studija izvodljivosti

Svrha: provjera izvodljivosti sustava s različitih stanovišta; izvješće – studija izvodljivosti projekta sastavni je dio idejnog projekta sustava:Aspekti:Tehnološka izvodljivostEkonomska izvodljivostOperativna izvodljivostVremenska izvodljivost

OIIS -2013/14

Tehnološka izvodljivostAnaliza i procjena mogućih rješenjaProcjena softverskih zahtjeva

Operacijski sustavi i upravljanje komunikacijamaMreže i sigurnostBaze podataka, aplikacijski i razvojni softver

Procjena hardverskih rješenja u odnosu aktuelne trendoveServeriKomunikacije i mrežeRadne stanicePeriferije

Procjena novih rješenja i iskoristivost postojećih rješenja (hardverskih i sofvertskih)Procjena stručnosti i sposobnsoti korisnika za usvajanje novih tehnoloških rješenjaProcjena vremena i sredstava za prihvaćanje izvodljivosti -> vremenska studija, ekonomska studija

OIIS -2013/14

Operativna izvodljivostProcjena performanci budućeg sustava

Brzina obradbe u odnosu na postojeći sustavObuhvat podataka i kvaliteta izlaznih informacijaUčinkovitost resursa – ljudi, opreme, programaKontrolabilnost sustavaPitanja sigurnosti sustava Pouzdanost i lakoća ispravka grešaka u sustavuLakoća korištenja i prolagođenost korisničkim zahtjevimaUpotrebljivost sustava za zadatak, mjesto, zahtjev i raspoložive podatkePrenosivost podataka s postojećeg na novi sustav

OIIS -2013/14

Vremenska izvodljivostProcjena vremena za realizaciju i punu funkcionalnost sustavaOčekivano vrijeme realizacije sustavaPoželjni rokoviČvrsti rok do kada sustav mora profunkcioniratiIzvodljivost pojedinih faza i angažman resursa po fazamaProcjena alternativnih puteva realizacije i vremena potrebnog za realizaciju alternativa

OIIS -2013/14

Ekonomska izvodljivostProcjenjuju se troškovi i koristi od izgradnje sustava kroz financijske vrijednostiTroškovi

Troškovi razvoja sustava (fiksni troškovi projekta)Troškovi opremeTroškovi softvera Plaće i honorariTroškovi obuke i izobrazbe

Troškovi primjene i eksploatacije sustava Naknade za održavanje sustavaTroškovi licenci Režijski troškovi (struja, telefoni, naknade za korištenje linija)Plaće zaposlenika na sustavu

OIIS -2013/14

Ekonomska izvodljivost-nastavak

Analiza trošak – koristFinancijski izraz za troškoveFinancijski izraz za koristi od sustatva

Vrijeme povrata investicijaProsječna stopa povrataNeto sadašnja vrijednost ulaganjaInterna stopa rentabilnosti

Nemjerljivi troškovi i koristi sustava(ne)zadovoljstvo korisnika upotrebom sustavaPrekidi u radu i “iskakanje” sustavaLakoća korištenja sustavskih rješenjaKvaliteta informacija s aspekta odlučivanja

OIIS -2013/14

30

Problemi ekonomske procjeneProcjena troškova je relativno jednostavna i egzaktnaProcjena koristi a pogotovo njihovo mjerenje nije jednostavno niti standardizirano.Direktne koristi: integracija podataka, ubrzani rad (unos, obrada, izvješčivanje) i ubrzano pretraživanje podataka. Problem: mjerenjeEfikasan informacijski sustav doprinosi povećanju prihoda; mjerljivi pokazatelj ali je doprinos IS-a nejasanIndirektne koristi odnosno smanjenje troškova uvođenjem novog sustava

OIIS -2013/14

Ekonomska izvodljivost

Trošak/korist Godina 0 Godina1 Godina 2 Godina3 Godina 4 Godina 5 Godina 6

Trošak razvoja 100000

Primjena i odžavanje 0 10000 11000 12000 13000 14000 15000

Faktor za kamatu 12% 1 0,893 0,797 0,712 0,636 0,567 0,507

Trenutna vrijednost 100000 8930 8767 8544 8268 7938 7605

Kumulativni trošak 100000 108930 117697 126241 134509 142447 150052

Primitci (koristi) 0 30000 38000 45000 46000 48000 55000

Faktor za kamatu 12% 1 0,893 0,797 0,712 0,636 0,567 0,507

Trenutna vrijednost 0 26790 30286 32040 29256 27216 27885

Kumulativna korist 0 26790 57076 89116 118372 145588 173473

0 1 2 3 4 5 6

Razlika trošak - korist -100000 -82140 -60621 -37125 -16137 3141 23421

OIIS -2013/14

Ekonomska izvodljivost

-120000-100000-80000-60000-40000-20000

02000040000

1 2 3 4 5 6 7 Razlika trošak -korist

Točka povrata

OIIS -2013/14

Modeliranje funkcija, procesa i događaja

OIIS -2013/14

Kompleksnost poslovnih sustava i nužnost dekompozicije

Stvarni problemi su preveliki i presloženi da bi ih se riješilo odjednom (“u komadu”)

strukturno raščlanjivanje, rastavljanjeLogički procesi: funkcije, događaji i elementarni procesi

rad i akcije koji se obavljaju bez obzira na način ugradnje i resurse sustava (ljudi, strojevi, softver)

Postupak dekompozicije

Sustav se razlaže i opisuje hijerarhijskim modelimamodeli sustava oblikuju se iterativnim razlaganjem s vrha prema dolje razlagati se mogu

funkcije i procesiorganizacijska strukturastruktura podatakastruktura programske opreme

Aplikacijski model procesa = logički model procesa sustava ili aplikacije koji se radi u fazi analize

OIIS -2013/14

Osnovna polazištaProces (elementarni, primitivni

proces)Skup međusobno povezanih aktivnosti ili zadataka koji proizvode specifičan rezultat za nekog klijentapostupak, način rada, dosljedna izmjena stanjadiskretna odluka, aktivnost ili zadatak kojima se obavlja neki posao

proces se obavlja uvijek na jednak način (za određeni ulaz daje isti izlaz)trajanje procesa je konačno i odredivo (poznati početak, završetak, ponavljanje)

za obavljanje se koriste sredstva, npr. ljudska, materijalna (strojevi), financijska

AktivnostDjelovanje nekog ili nečeg u sustavu i sustava samog što proizvodi neki rezultat ili kontroluSlijed koraka (radnog toka) koji se izvode u okviru funkcije i/ili procesa

OIIS -2013/14

31

Osnovna polazištaFunkcija

skup logički povezanih trajnih poslovnih aktivnosti i zadataka (djelatnost, posao)

funkcija se obavlja stalno (nema određeni početak i kraj)funkciju obavljaju osobe, grupe djelatnika ili organizacijske cjeline

tipični primjeri: prodaja, proizvodnja, otprema, računovodstvofunkcija se može sastojati od desetina pa i stotina diskretnih procesa

funkcije se mogu hijerarhijski razložiti do razine diskretnih procesa koji obavljajuodređeni zadatak kojim odgovaraju na poslovne događaje

Događajlogički dio posla koji se obavlja kao nedjeljiva cjelina � česti naziv transakcija

pokreće se diskretnim ulazom i završava nakon što proces odgovoriodgovarajućim izlazom

poslovni događaj može se predstaviti jednim procesom kojim sustav reagira na taj događaj

logički događaj dalje se razlaže do elementarnih procesa kojima se prikazuje reakcija sustava na taj događaj

Okidač – triger za aktivnost koja iz njega proizlazi

OIIS -2013/14

Procesi u sistemskom okviruKako

(Procesi)

Lista procesa

Model procesa

Dijagram procesa


Procesni detalji






Strukturni modeli

IDEF0 –dijagram konteksta

IDEF0 –konceptualni dijagram

IDEF0Razrada do elementarnih procesa (Poslovnalogika)

IDEF0 -Fizička osnova (Tehnologija)

IDEF0 -(Detaljnareprezentacija)

OIIS -2013/14

Procesi u sistemskom okviruKako

(Procesi)


Lista procesa


Model procesa


Dijagram procesa




Procesni detalji

Što(Sredstva)

Lista entiteta




Detalji podataka

Strukturni modeli

DFD dijagram kontekstaDFDkonceptualni dijagramDFD (Poslovnalogika)

Workflow -

Detalji DFD -programa(Detaljnareprezentacija)

+ +

OIIS -2013/14

Poslovna pravila i poslovna politikaPoslovno pravilo, poslovna politika

poslovno pravilo - instrukcije i logika koji određuju proceduru obavljanja procesa

ugrađuje se u računalni program (npr. preduvjeti izlaska na ispit, broj polaganja ispita, uvjeti upisa)

poslovna politika – skup poslovnih pravilau većini organizacija podloga za donošenje odluka

Primjer: zaprimanje robe na skladištu i knjiženje ulaznih dokumenataTemeljem ulaznih dokumenata (račun-otpremnica, tovarni list, carinska deklaracija) provjerava se kvantiteta i kvaliteta isporučene robe. Glavni skladištar unosi podatke o primljenoj robi sa svim stavkama iz prateće dokumentacije. Račun otpremnica knjiži se u knjigovodstvu dobavljača. Zadužuje se skladište i obračunava vrijednost robe. Obračunati porez na dodanu vrijednost predstavlja pretporez za umanjenje poreznih obveza za mjesec u kojem je porezna obveza nastala.

OIIS -2013/14

Poslovna pravila -karakteristike

Deklarativnost: poslovno pravilo je izjava istinitosti o organizaciji. Njezina je namjera da opiše operacije u organizaciji a ne da ih propiše; poslovno pravilo se otkriva ili uočava a ne kreira. Elementarno pravilo: pravilo je ili u potpunosti istinito ili u potpunosti krivo. Razlikovnost i neovisni konstrukt: razdvojite pravila od procesa, ne izgrađujte ciklične ovisnosti i pojednostavite konstrukciju pravila Izrazite pravilo u prirodnom jeziku bez upotrebe tehničkog žargonaPravilo mora biti orijentirano poslovanju a ne tehnologijiPravila su rezultat poslovnih odluka a ne korištene tehnologije od koje bi trebale biti neovisne (Izvor: http://en.wikipedia.org/wiki/Business_rules)

OIIS -2013/14

Izbor modela za oblikovanje procesa, funkcija i događaja1. Strukturni modeli temeljeni na SAS (strukturna analiza

sustava) i SSADM metodologiji:1. IDEF0 – modeliranje funkcija (funkcionalnosti) sustava2. modeliranje tokova procesa (događaja, aktivnosti i objekata

koji sudjeluju u procesu i ograničenja) IDEF3 Modeliranje promjena stanja objekata u procesima

(kako objekti mijenjaju stanja u procesu (DFD)koji procesi i kada mijanjaju ta stanja (EPC)

Modeliranje resursa – sudionika i njihovih aktivnosti (BPN)2. Objektno orijentirani modeli (UML)

1. Dijagram aktivnosti2. Dijagram slučajeva, 3. Dijagram klasa4. Dijagram slijeda

OIIS -2013/14

32

Strukturni modeli: modeliranje funkcija

Funkcijasustava

1

Fukcija sustava

2

Aktivnost funkcije1.1.

Poslovni sustav0

Zadatak 1.1.1.

Zadatak1.1.2.


Zadatak 2.1.1.

Zadatak2.1.2.


Zadatak 1.2.1.

Zadatak1.2.2.

Aktivnost funkcije 2.2.

Zadatak 2.2.1.

Zadatak2.2.2.

Zadatak1.1.3.

Zadatak 2.1.3.

Zadatak2.1.4. Zadatak

2.2.3.

POSLOVNISUSTAV

0

Poslovna funkcija

1

Poslovna funkcija

2

Aktivnost funkcije

1.1.

Aktivnost funkcije

1.2.

Aktivnost funkcije

2.1.

Aktivnost funkcije

2.2.

Zadatak 1.1.1.

Zadatak 1.1.2.

Zadatak 1.1.3.

Zadatak 1.2.1.

Zadatak 1.2.2.

Zadatak 2.1.1.

Zadatak 2.1.2.

Zadatak 2.2.1.

Zadatak 2.2.2.

Zadatak 2.2.3.

Zadatak 2.1.3.

Zadatak 2.1.4.

Funkcionalna dekompozicija, dekompozicija funkcija•koristi se za izradu općeg modela funkcija (modela poslovnih funkcija) promatranog sustava u fazi planiranja •strukturirano planiranje•hijerarhija funkcija iterativno se razlaže do razine procesa, tj. do trenutka kada se počne opisivati što se nekom funkcijom obavlja

OIIS -2013/14

Dijagram dekompozicije funkcijaDijagram 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

Elementifunkcije - označavaju se (glagolskom) imenicom, npr. Prodaja, Proizvodnjaprocesi - označavaju se glagolskim izrazom oblika infinitiv+objektspojnice - spojevi između funkcija i procesa (connector)vanjski spojevi -- spojevi s dijelovima dijagrama na drugim stranicama (offpageconnector)

OIIS -2013/14

Izrada dijagrama dekompozicijePostupak

Korijen = sustavRazrada u podsustave i poslovne funkcijeDaljnja razrada do razine operacionalizacije

Pravilasvaki proces je roditelj ili dijeteroditelj mora imati barem dvoje djecepo većini standarda, dijete smije imati samo jednog roditelja

Preporukeizostaviti procese koji samo premiještaju ili preusmjeravaju podatke, a da ih pri tomostavljaju nedirnutepažnju usmjeriti na procese koji

nešto računaju (npr. prosjek ocjena)donose ili potpomažu odluke (npr. određivanje raspoloživosti robe pri naručivanju)filtriraju ili sumariziraju podatke (npr. računi kojima je istekao rok plaćanja)organiziraju podatke u korisne informacije (npr. generiranje izvješća)pokreću druge procese (npr. mijenjaju modalitet rada stroja)rukuju podacima (npr. stvaranje, čitanje, ažuriranje, brisanje) - Ne pretjerivati!

OIIS -2013/14

Dijagram poslovne organizacije

Shema, mapa, karta organizacije (Organization chart)• prikaz strukture organizacije hijerarhijom kutija ("kućica")• svaka kutija reprezentira određenu ulogu ili odgovornost u organizaciji

Primjer: EFOS

OIIS -2013/14

Modeliranje poslovnih funkcija i procesa - metodologija

Business Process Modeling (IDEF0) (http://www.idef.com/IDEF0.html)tehnika strukturirane analize i dizajna (Structured Analysis and Design Technique - SADT®, SofTech, 1960-ih), zamišljena kao inženjerska disciplina za razvoj složenih sustava koji uključuju strojeve i ljude; metoda za oblikovanje poslovnih funkcijaGrafički prikaz poslovnih procesa i angažiranih resursaproces – niz aktivnosti (funkcija)aktivnost – prikazana ICOM konceptom

ulaz (I=Input): nešto što se troši u procesu - opcionalanupravljanje (C=Control): ograničenje na obavljanje procesa - obveznoizlaz (O=Output): rezultat procesa - obvezanmehanizam (M=Mechanism): koristi se u procesu, ali se ne troši -opcionalan

OIIS -2013/14

Dijagram funkcija IDEF0

Opća notacija IDEF0:

kontekst

OIIS -2013/14

33

IDEF0- dijagram konteksta-primjer

A0

OBRADA NARUDŽBI

Inf. O novom korisniku

Verifikacijaplaćanja

Broj narudžbe

Tovarni list

Račun-otpremnica

Oblikovanje sustava hijerarhijom ugniježdenih aktivnostiAktivnost konteksta -vrh hijerarhije, predstavlja čitav sustav

OIIS -2013/14

IDEF0 – dijagram funkcija i aktivnosti – 1.razina

OIIS -2013/14

Razrada poslovnih funkcijaRadna procedura, poslovna procedura (workflow)

slijed koraka obrade koji u potpunosti obrađuje jednu poslovnu transakcijudefinira logiku obrade i precizira nositeljamože imati više varijanti (scenarija)

Tehnike modeliranjau š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 dijagramunastavak se može provesti

oblikovanjem tokova procesa (IDEF3) ilioblikovanjem tokova podataka (DFD)Napomena: pomagala opće namjene, kao što je Visio, podržavaju neke dijagrameformalnih tehnika ali ih različito zovu ili se notacija razlikuje od izvorne (grupedijagrama Business Process i Flowchart, npr. IDEF0, Cross Functional FlowChart)

OIIS -2013/14

Dekompozicija procesaDekompozicija procesa

polazni dijagram ili dijagram konteksta (context diagram) hijerarhijski se razlaže na poddijagrame do razine osnovnih procesaproces na nekoj razini (parent) razrađuje se (explode) dijagramom na nižoj razini (child) – leveling = nivelizacijapreporuča se izrada dijagrama koji sadrže između 2 i 9 procesa, a poželjno je slijediti “pravilo 7±2” postupak se zaustavlja kada postane očigledna ugradnja implementacija) procesa na najnižoj razini

Preporuke za označavanje elemenataprocesi - hijerarhijske brojčane oznake, razina konteksta = 0 spremišta, izvori i odredišta – nazivlje velikim slovima, oznake oblika slovo ili slovo+brojprocesi i tokovi podataka - malim slovima

DFD dijagramRAZINA 1


DIJAGRAMKONTEKSTA

0

Informacijski sustav

Entitet A Entitet B

X

YZ

1

Proces T

3

Proces V

2

Proces UD1 Spremište podataka N

Entitet A

Entitet B

X

YB

AN

N

2.1.

Proces D

2.2.

Proces E

2.3.

Proces FD1 Spremište podataka N

N

N

B

Z

AY

J

G

G


N

2.2.1.

Proces K

2.2.2.

Proces L2.2.3.

Proces M

D1 Spremište podataka N N

H1 G1

R

Q

G2

G

H2

H

S

OIIS -2013/14

Modeliranje funkcija IDEF0Procedura u VISIO programuFunkcije se modeliraju kao skup hijerarhijskih čvorova; tu hijerarhiju treba imati na umu jer s njom počinje i završava modelirane procesaKreira se konceptualni blok koji će predstavljati vrhovni čvor; U njemu se kreira activity box s osnovnim ulazima, izlazima, kontrolama i mehanizmima, navode se subdijagrami koji se iz njega izvode Konceptualni blok s procesom se sprema kao datoteka u zajednički katalogNa isti način izrađuju se aktivnosti na nižim razinamaNa kraju se kreira hijerarhijski dijagram čvorova i označavaju linkovi na funkcije (spremljene kao datoteke).

OIIS -2013/14

Modeliranje procesaOpisuje procese čijim se djelovanjem ostvaruju ciljevi sustavaOsnova za razvoj informacijskog sustavaRezultat analize sustava i definiranja zahtjevaModel “Kako je” i model “Kako treba biti”

Logički model procesaPrikazuje procese koji se u sustavu odvijaju nezavisno od načina realizacije i sredstavaPrikaz logičke strukture – što se u sustavu zbiva, a ne i kako

OIIS -2013/14

34

Modeliranje toka podatakaDijagram toka podataka (DFD - Data Flow Diagram)

skup dijagrama za dokumentiranje fizičkog i logičkog modela sustava te zahtjeva prikaz protoka, strukture i obrade podatakadokumentiranje logike, poslovnih pravila i procedura

sinonimi: transformacijski graf, mjehurasti graf, (Bubble Chart)Tehnika se primjenjuje pri razvoju aplikacija, otkuda je i poteklaNe može se koristiti za opis programske logike, opis promjene stanja, izradu upravljačkih specifikacija ili dizajn korisničkog sučelja!!!Koristi se pri modeliranju poslovnih procesa

daljnja razrada IDEF0 procesnog dijagramaIDEF3 (zavisnost procesa) ili DFD (tok informacija)

OIIS -2013/14

Elementi dijagrama toka podatakaTok podataka (data flow)

predstavlja skupove podataka koji se kreću kroz sustavtokovi 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.

Procespredstavlja 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 općenite nazive (npr. Obavljanje računovodstvenih poslova)opis procesa sadrži opis aktivnosti(algoritam) njegovog djelovanja

OIIS -2013/14

Elementi dijagrama toka podatakaSpremište podataka (data store)

predstavlja organizirani i trajni skup podatakaoznačava mjesto pohrane podataka, npr. dokument, registrator, datoteka, tablica u bazi podataka (izbjegavati u nazivlju)promjena sadržaja spremišta (punjenje, ažuriranje, pražnjenje) i korištenje (čitanje) obavlja se procesimaspremište se označava imenicom(imenicom u množini), npr. Prijavnica (Prijavnice)

Vanjski entitet (external entity,external agent)objekt vanjskog svijeta povezan s promatranim sustavomodređuje granice promatranog sustava vanjski entiteti predstavljaju izvorišta i odredišta podataka, to jest izvore i ponore podataka (source, sink)vanjski entiteti mogu biti osobe, org. jedinice, ustanove, drugi sustavi …za označavanje entiteta koriste seimenice, npr. Student, Kupac, Dobavljač

OIIS -2013/14

Izrada dijagrama toka podatakaDijagram konteksta

prikazuje sustav na najvišoj razini hijerarhije prikaza (top level diagram)definira okruženje sustava i područje analize (environmental model)prikazuje jedan proces i vanjske entitete

započeti s procesom koji prikazuje sustav u cjeliniodrediti vanjske entitete i njihovu povezanost sa sustavom

OIIS -2013/14

Izrada dijagrama toka podataka

Pregledni dijagram (initial diagram)uočiti glavne tokove informacija (npr. korišteni dokumenti, potrebni podaci)odrediti glavne aktivnosti sustava i prikazati ih odgovarajućim procesimauključiti vanjske entitete i tokove podataka s dijagrama kontekstasložiti se s korisnikom oko granica sustavautvrditi procese i spremišta podataka

OIIS -2013/14

Izrada dijagrama toka podataka

OsobaUpisati novog

člana1

D4 EZERVACIJE

D1 ČLANOVI

Tražiti video

ČlanDobavljač

Nabaviti video

Posuditi Video

3

Vratitivideo

D3 POSUDBA

Identifikacija

Članskaiskaznica

Zahtjev zaidentifikaciu

Rezervirati video

4Rezervacija D2 VIDEO

Rezervacija

Posudba

Video

Video

Narudžba Novivideo

Upit Rezultat upita

Članskaiskaznica

Posudba

Posudba

Član

Pregledni dijagram

OIIS -2013/14

35

Izrada dijagrama toka podatakaRazradaza svaki proces s preglednog dijagrama identificirati podaktivnosti na primjer, za proces Upisati novog člana:

• Zatražiti osobne podatke• Evidentirati novog člana• Izraditi člansku karticu

Ponavljati postupak za svaki od procesa na poddijagramu

•uspostaviti razinu detalja slijedeći “pravilo 7±2”•provjeriti potpunost i ispravnost modela Model obrazložiti korisniku a zatim ga ažurirati po potrebi

Dubinu i uravnoteženost modela teško je odrediti.U praksi to može značiti doradu dijagrama u većem broju ponavljanja, čak i kadadijagrame rade iskusni analitičari!!!

OIIS -2013/14

Povezivanje procesa i podataka

D1 PROIZVODI

D2 KUPCI Kupac

D3 ZALIHE

D4 DETALJI NARUDŽBE

Prihvati specifikaciju narrudžbe

A431

Provjeri raspoloživost na skladištu

A432

Alociraj zalihe

A433

Iszuzmi sa skladišta i isporuči

A434

Komunikacija s kupcem

Komunikacija skupcem

Raspoloživazaliha

Alociranazaliha

AlociranezaliheZahtjev za

zalihe

Autorizirana

narudžba

OIIS -2013/14

Pravila i ograničenja prilikom izrade DTPPravilo bilance (očuvanja) tokova (level balance rule)

količina tokova koji ulaze u proces i izlaze iz procesa mora odgovarati količini tokova podprocesa na nižoj razini hijerarhijenije dozvoljeno variranje tokova neke razine na nižim razinama (npr. tok T na nižim razinama prikazivati kao T1, T2)

Ograničenja i posebni slučajeviSvi 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 – najčešće)postojanje nepovezanih spremišta ili vanjskih entiteta

Ne dozvoljava se neposredna povezanost:vanjskih entitetaspremištaspremišta i vanjskog entiteta

Nije dozvoljeno:grananje toka u različite tokove, spajanje različitih tokovapostojanje “rekurzivnih” procesa

OIIS -2013/14

Preporuke za izradu DTP

Treba pripaziti na:trivijalne tokove – izlazi iz procesa koji ne ulaze u spremišta ili odredišta

obično imaju posebno značenje, a mogu se koristiti za prikaz posebnih stanja kao što je dojava poruke sustava (npr. dojava pogreške)

neposredno povezane proceseako postoje, to znači da jedan od procesa čeka na završetak prethodnog

procese koji ne obavljaju pretvorbu podatakaako je izlazni tok jednak ulaznom

treba preimenovati jedan od tokova ilitreba obaviti prespajanje tokova

Procesi se mogu zbivati istovremeno DTP se ne smije tumačiti kao dijagram toka (flowchart)!

OIIS -2013/14

Notacije koje koriste DTPGane-SarsonYourdon/DeMarcoSSADM

Proširenja:Cikličnost procesaOznake ponavljanja procesaPosebni simboli za tok resursa, tok dokumenata ili tok upravljanja

OIIS -2013/14

Opisivanje podataka

Rječnik podataka (Data Dictionary)mjesto pohrane definicija podatkovnih elemenata i struktura podatakastrukturirano spremište meta-podataka, to jest podataka o podacima

prvotno se pojavio kao proširenje dijagrama toka podataka, za pohranu opisa spremišta podataka i tokova podatakamože se koristiti kao alternativna tehnika za prikaz modela podatakastandardno se upotrebljava BNF notacija (Backus-Naur Form), koja se inače koristi za opis sintakse programskih jezika

Podatkovni element

Struktura podtaka

Tok podataka

Spremište podataka

Najmanja logička cjelina podataka

Grupe podatkovnih elemenata

Grupe struktura podataka

OIIS -2013/14

36

Modeliranje toka procesaMetoda Process Flow Modeling (IDEF3)strukturirana metoda za opis poslovne situacije uređenim slijedom događaja i objekata koji u njoj sudjelujuprikazuje slijed, zavisnost i konkurentnost aktivnostiprikladna za prikupljanje informacija tijekom analize i dizajna

poslovna politika i poslovne procedurepreoblikovanje poslovnih procesamodeliranje scenarija kojima se odgovara na pitanja "što-ako"

OIIS -2013/14

Opisi procesa

Opis prirodnim jezikomDijagram strukture procesa

Prikaz globalne strukture procesaPrikaz potprocesa i veza među njimaSlijed izvođenja potprocesa

Dijagram aktivnostiDetaljni prikaz procesa (potprocesa)

Stabla i tabele odlučivanjaOpis procesa s mnogo uvjetovanih potprocesa i točaka grananja OIIS -2013/14

Procesi, događaji i osnovni algoritmi glavnih programa

Primjer: PROCESI I DOGAĐAJI U SLUŽBI NABAVESlužba nabave dobiva specifikaciju materijala, opreme ili trgovačke robe u obliku naloga za nabavu. Referenti šalju upite dobavljačima. Za eventualne promjene upita šalju nadopune. Dobavljači vraćaju referentima svoje ponude. Referenti ih uspoređuju i izabiru optimalan s obzirom na cijenu, rokove, kvalitetu i uvjete isporuke. Dobavljaču se šalje narudžba ili ugovor i od njega očekuje potvrda narudžbe. U skladu s dogovorenim načinima plaćanja od dobavljača očekuje se predračun. Za veće iznose sukcesivnih isporuka i odgođena plaćanja dobavljač može tražiti jamstva za plaćanje (zadužnica, bankovna garancija). Isto tako nabava može tražiti kontra garancije za slučajeve većeg avansa. U skladištu dobavljača se pravi otpremnica koja prati robu na putu a u skladištu kupca se pravi primka vezana uz narudžbu. Materijal se kontrolira kvalitativno i količinski. U slučaju manjkavosti pravi se zapisnik i šalje reklamacija dobavljaču. Za otpremnicom se šalje račun, atesti i jamstva.

Majdandžić, 113-121, 333-343, 349-353

OIIS -2013/14

Poslovni procesi i događaji u nabavi

Preuzimanje naloga za nabavuOtvaranje novog naloga za nabavuSlanje upita dobavljačimaDopuna upita dobavljačuPonuda dobavljačaDopuna ponude dobavljačaIzbor dobavljačaTehnička ovjera ponudeSlanje narudžbe dobavljačuDopuna narudžbePotvrda narudžbe i evidencijaPrijem robe – otpremnica dobavljačaEvidencija reklamacija - zapisnikPrijem računa dobavljača

Ispostava računa u druge službeTraženje jamstava za narudžbuDobivanje potrebnih jamstava za narudžbuTraženje potrebnih atestaDobivanje potrebnih atestaTraženje bankovnih jamstavaDobivanje bankovnih jamstavaDobivanje predračuna od dobavljačaPlaćanje predračuna dobavljačuPlaćanje po osnovi računa

OIIS -2013/14

EPC (Event-Process-Chain) dijagrami

OIIS -2013/14

Procesi i sudionici u Business Modeling Notation

BPMN - dijagram procesa brzojavne usluge

OIIS -2013/14

37

Događaji

EPC dijagram procesa brzojavne usluge

OIIS -2013/14

Modeliranje podataka

OIIS -2013/14

Napomena

Materijali u ovoj prezentaciji predstavljaju pomoćni radni materijal za svladavanje gradiva na predmetu Modeliranje i izgradnja IS-a. Sadrže dijelove koji se moraju revidirati i nadopuniti uz dozvole citiranih autora i izvora.

OIIS -2013/14

Modeliranje podatakaModeliranje podataka obuhvaća strukturiranje podataka i organizaciju podataka i njihovu implementaciju na DBMSModel podataka – proizlazi iz modela procesa (dekompozicije procesa i funkcija) i analize korisničkih zahtjevaModeliranje podataka = kreiranje modela podataka primjenom teorije podatkovnih modela (danas aktualnih: relacijskih, objektnih, XML)

OIIS -2013/14

Modeliranje podataka

Obuhvaća:Definiranje podatkovnih entitetaDefiniranje atributa entitetaDefiniranje domena atributaDefiniranje ključevaDefiniranje veza među entitetimaKreiranje dijagrama entiteti-vezeRazvoj logičkog modela podataka kao osnove za razvoj fizičkog modela i implementaciju na izabranu bazu podataka

OIIS -2013/14

Modeli podatakaKonceptualni model – opisuje semantiku organizacije; sastoji se od klasa eniteta (koje predstavljaju stvari od značaja za organizaciju) i odnosa među njimaLogički model – polazi od konceptualnog modela i opisuje semantiku na način kako se podatcima manipulira izabranom tehnologijom; sadrži opis tablica, kolona, objektno orijentiranih klasa ili XML tagovaFizički model –polazi od logičkog modela uzimajući u obzir arhitekturu baze (strukture podataka - tablice, odnose, indekse, i fizičke karakteristike ) i zahtjeve za hardverskim specifikacijama za izabrani DBMShttp://www.agiledata.org/essays/dataModeling101.html

OIIS -2013/14

38

Konceptualni model podatakaGlobalni model podatakaKoristi se u prikupljanju ideja za rješenje problemske domene; Neovisan je implementacijskim detaljima (izabranoj bazi, programskom jeziku)Svrha je definiranje značenja, pojmova i koncepata koje eksperti koriste u razradi problemske domene; za pronalaženje ispravnih odnosa između različitih koncepatapodatkovni model poduzeća (enterprise data model) u fazi planiranjakonceptualni model entiteti-veze koji najčešće sadrži neodređene veze i nerazrađene kategorije podataka, a pojedine veze mogu i nedostajatidefinira mogući doseg sustava i ukupne informacijske potrebe

OIIS -2013/14

Kontekstualni model podatakaModel konteksta podataka

Identificira klase entiteta koje predstavljaju stvari od značaja za organizaciju Provodi se na početku analizeNe obuhvaća detalje o entitetima ili detalje o poslovnim pravilimasadrži samo one entitete koji će biti obuhvaćeni tehničkim rješenjem ERD s entitetima i vezama (često nespecifičnim), bez atributa ili samo s osnovnim atributima

obične veze, tj. veze tipa 1:Nnpr. "račun ima više stavki"

veze višeg stupnjanpr. “zaposlenje osobe u org. jedinici na radnom mjestu” → Zaposlen

OIIS -2013/14

Logički model podatakaModel s definiranim ključevima

eliminacija neodređenih veza i njihovo nadomještanje asocijativnim entitetimaodređivanje ključeva (primarnih, alternativnih, stranih)

ako se PK ne može odrediti, možda se ne radi o skupu entitetapreciziranje kardinalnosti veza

odgovor na pitanja oblika “mora/može”: “ni jedan” (0), “barem jedan” (1), “više”

(N) → donja/gornja granica kardinalnosti– Koliko stavki računa mora/može imati račun ? → 1,N– Koliko se osoba mora/može nalaziti u mjestu ? → 0,N

definiranje generalizacijskih hijerarhijaodređivanje specijalizacija, tj. podtipova entiteta

definiranje klasifikacijskog atributa nadtipa (diskriminator podtipa)– npr. Proizvod.TipProizvoda { “Igla”, “Avion” }

OIIS -2013/14

Struktura podatakaModel podataka opisuje strukturu podataka u datoj domeni i implicitno strukturu te domene; podatkovni model specificira i gramatiku (programskog) jezika za tu domenu Model podataka predstavlja klase entiteta (vrste stvari) o kojima se u poslovnom sustavu drže podatci, sadrži atribute tih podataka, odnose među entitetima i implicitno odnose među atributima; model opisuje organizaciju podataka neovisno o tome kako će se oni predstaviti računalnim sustavom. Struktura podatka je način kako će se podatci smještati u računalo da bi se mogli efikasno iskorištavati. Struktura podataka može se promatrati kao primjena metode pristupa smještaju podataka koji je organiziran prema združenim tipovima podataka.

Atomizirani podatak – podatak pojedinačni podatak koji ne mora biti vezan ni uz koji drugi podatak (slovo)Strukturirani podatak – podatak kojem je definicija vezana uz njegovu vrijednost tj. uz interne odnose ili organizaciju odnosno strukturalne odnose. http://en.wikipedia.org/wiki/List_of_data_structures

OIIS -2013/14

Ograničenja modelaPrikladni konceptualni model podataka opisuje semantiku subjektnog područja. On je skup tvrdnji (izraza) o prirodi informacija koje se koriste u jednoj ili više organizacija. Prikladna klasa entiteta imenuje se rječima prirodnog jezika a ne u tehničkom žargonu. Isto tako prikladno imenovani odnosi čine konkretne tvrdnje o subjektnom području.

OIIS -2013/14

Tehnike za modeliranje podataka

Postoji više tehnika koje su razvijene za oblikovanje modela podataka. Metode su vodilje za rad onima koji modeliraju i često će se dogoditi da dvoje ljudi koristeći istu metodologiju dobiju drugačije rezultate. Najčešće korištene metode su:Entity-relationship modelIDEF1xObject Role Modeling (ORM) or Nijssen's Information Analysis Method (NIAM) Business rules or business rules approachRM/TBachman diagramsObject-relational mappingBarker's NotationEBNF Grammars

OIIS -2013/14

39

Metoda ENTITETI - VEZE (EV model)(Entity-Relationship Method - ER model)

Koristi koncepte bliske korisnikuShema modela podataka je laka za razumijevanje i komunikaciju između projektanta i korisnikaOsnova za mnoge komercijalne DBMS (Data Base Management System) softverske produkteDFD dijagrami su okrenuti procesima i funkcijama sustava a ne podatcima koje trebaju; ERD komponente (pravokutnici) korespondiraju sa spremištima podataka u DFD-u a rombovi sa vezama u DFD-u.

Prvi korak procesa izrade logičkog modela (baze) podatakaGrafički prikaz temeljnih podataka informacijskog sustavaPri izradi logičkog modela baze podataka prethodi relacijskom modeluManje formalan od relacijskog modelaBliži (razumljiviji) korisniku

OIIS -2013/14

Metoda ENTITETI - VEZE (EV model)(Entity-Relationship Method - ER model)

Koncept entiteta – prikaz korisniku važnih “objekata” o kojima će se voditi zapisiKoncept odnosa (veza) – prikaz odnosa među objektima na temelju nekih svojstavaKoncept atributa – prikaz svojstava entiteta i zapis pojedinog svojstva za određenu pojavu (instancu) entitetaKoncept zavisnosti – entitet koji generira novi entitet (roditelj i dijete)

OIIS -2013/14

Komponente ERD-a

Tipovi objekata (Object types)Odnosi (Relationships )Pokazivači pridruženih tipova objekata (Associative object type indicators)Pokazivači nadtipa/podtipa (Supertype/subtype indicators)

OIIS -2013/14

Elementi dijagrama Entiteti-Veze (ERD (E-R) notacija)

Ovisi o notaciji (sintaksi) koju primjenjujemo u izradi modela podatakaChenova notacija

Romb i crte koje povezuju entiteteNaziv veze - glagol, glagolska imenica unutar romba

Martinova notacijaCrta s nazivom veze

OIIS -2013/14

EntitetiEntitet je:

nešto što postoji u stvarnom svijetu i posjeduje značajke koje ga opisuju i po kojima se razlikuje od svoje okolineStvar koja se može zasebno identificirati [P. Chen, 1976]Bilo koji objekt koji se može razlikovati i predstaviti u bazi podataka [C.J.Date, 1986]Logička reprezentacija podatka [C.Finkelstein, 1989]Bilo što o čemu pohranjujemo informaciju [J.Martin, 1989]

Entitet može biti:Osoba (Ivana Marić)Objekt (knjiga u biblioteci)apstraktni pojam (npr. hrvatski jezik ili iskustvo (poznavanje jezika)ustanova (EFOS), organizacija (Saponia Osijek) ili organizacijska cjelina, događaj (situacija, stanje) - prošli, sadašnji ili budući, npr. rođenje, školovanje, zaposlenje, smrtpovezanost različitih objekata stvarnog svijeta, npr. Srodstvo

OIIS -2013/14

Tip entiteta i instanca entitetaTIP entiteta je obrazac ili pojava o kojoj se prikupljaju informacije (student,

nastavnik, predmet)Instanca eniteta – pojava entiteta (primjer tipa entiteta) (Ivo Ivić, Prof. Ana

Anić, Bilogija)

I tip i instanca imaju imaju skup svojih atributa

Student

Prezime Ime Godina studija

Status Spol

Ivić Ivo 2 Redoviti M

Perković Sanja 4 Izvanredni Ž

Tip entiteta

Atributi

Instance entiteta

Instance entiteta

Vrijednost atributaOIIS -2013/14

40

Tip entiteta - pojava entitetaTip entiteta STUDENTPojava entiteta - Ante, Filip, Mate,.... (svistudenti sustava koji razmatramo – fakultet,odjel, Veleučilište, Sveučilište, itd.)Svakom tipu entiteta odgovara određen brojpojava entitetaPojedinačno pojavljivanje entiteta -(INSTANCA) tipa entitetaTip entiteta određuje kontekst (Pr. OSOBA je u pravilu tip entiteta ali u kontekstu skupljača antiknih figura može biti atribut figure)

OIIS -2013/14

Imenovanja tipa entiteta

Ime bi trebalo biti jedinstvenoIme mora biti samobjašnjavajuće u nazivuNavodi se kao imenica u jedniniPišu se u pravilu VELIKIM SLOVIMANe bi trebalo biti ime individualnog objektaTreba izraziti jedan koncept skupa podatakaTreba biti dokumentirano u specifikacijama za oblikovanje sustava

OIIS -2013/14

Tip ObjektaPrikazani pravokutnikom; Entitet realnog svijeta (materijalni i nematerijalni koji je u sustavu predstavljen kao tip objekta

Svaki se može identificirati na neki način (mora postojati način za razlikovanje jednog od drugog; ime ID…)Svaki igra neku nužnu ulogu u sustavu kojeg izgrađujemoSvaki se može opisati jednim ili više podatkovnih elemenata

Kupac

OIIS -2013/14

Tip entiteta (Entity type, Entity set, Entityclass)

Skup entiteta iste vrsteDobiva se procesom klasifikacije prema zajedničkim svojstvimaMogu biti stvarni i apstraktniPrimjer: KUPAC, RADNIK, KNJIGA, STROJ (stvarni)METODA, AKTIVNOST, TRANSAKCIJA (apstraktni)Grafičko predstavljanje

OIIS -2013/14

Atributi i domeneAtributatribut predstavlja neko obilježje, značajku entitetasinonimi: svojstvo (property), element, polje (field)pojedinačne vrijednosti atributa pohranjuju se u bazu podataka → elementarni podatak (data element, data item)po vrijednostima koje predstavljaju, atributi mogu biti:

jednostavni atributi (simple attribute) - vrijednost atributa je pojedinačni podatak, –primjer: Prezime, Imesloženi, sastavljeni atributi (compound/composite/concatenated attribute, data structure) - vrijednost je uređena n-torka ililogička grupa jednostavnih atributa, – primjer: datum = (dan, mjesec, godina) višeznačni atributi (multivalued attribute) - atributi koji predstavljaju ponavljajuće grupe podataka, to jest atributi s više istovrsnih vrijednosti – primjer: Osoba.Telefon = (TelefonNaPoslu, TelefonKodKuce, MobilniTelefon)

s obzirom na pohranu vrijednosti, atributi mogu biti:atributi pohrane (stored attribute)izvedeni atributi (derived attribute) - vrijednost im se može odrediti na temelju vrijednosti drugih atributa – primjer: starost = (DanašnjiDatum-DatumRođenja)

OIIS -2013/14

Pravila vezana uz atribute1. ENTITET može imati proizvoljan broj atributa2. ATRIBUT može pripadati samo jednom entitetu3. ATRIBUT može imati samo jednu vrijednost za određeno pojavljivanje entiteta (u određenom vremenu)4. ATRIBUT ima samo jedno značenje5. RAZLIČITA POJAVLJIVANJA ENTITETA mogu ali ne moraju imati različite vrijednosti za isti atribut

OIIS -2013/14

41

Atributi i domeneVrijednosti atributa definiraju

tip podatka,domena ipretpostavljena ili standardna vrijednost (default)

Tipovi podatakanetehnički (logički)

opći tipovi koji se koriste u sistem analizi i pri prikupljanju zahtjevaprimjeri: broj, datum-vrijeme, znakovni niz, tekst, tehnički izrazgenerički tipovi podataka koji se mogu preslikati u konkretne tipove, npr.integer, characterkonkretni tipovi SUPB, npr. char, int, byte (SQLserver)

Standardna vrijednost atributavrijednost koja se zapisuje kada korisnik ne specificira vrijednost atributaopćenito, većina atributa trebala bi imati standardnu vrijednost

OIIS -2013/14

Atributi i domeneDomena

skup mogućih vrijednosti koje nad njom definirani atributi mogu poprimiti

domene mogu biti jednostavne i složene (vrijedi i za atribute)nad svakom domenom može se definirati po volji mnogo atributa

skup vrijednosti može se definiratitipom podatka, npr. integerpodskupom vrijednosti tipa podatka, npr: formula AA99, interval [10-99]skupom konstanti, npr. Spol =

OIIS -2013/14

Vrijednost atributaSve dozvoljene vrijednostiOdređene pravilima (mogu biti vrlo složena)Pripadaju nekoj domeni

JEDNOZNAČNOSTSvaki atribut mora biti određen tako da osnovno značenje ostaje jednako bez obzira

na specifičnu vrijednost.Šifre kupca < 5000 znače jedno (dobar bonitet),a > 5000 drugo (plaćaju sa zakašnjenjem)

DOSLJEDNOST / ISKLJUČIVOSTOdređena vrijednost tipa atributa ne smije obuhvaćatiznačenja druge vrijednosti tog istog atributa

Atribut: Bračni statusoženjen, neoženjen, razveden, udovacVrijednost oženjen ne isključuje vrijednost razveden.Rješenje: Uvesti novi atribut npr. Broj brakova

OIIS -2013/14

Izvedeni atributiIZVORI

Atributi istog pojavljivanja istog entiteta (Starost)Atributi iz različitih pojavljivanja istog entiteta (Broj redovnih studenata na nekom odjelu)

Atributi iz različitih pojavljivanja različitih entiteta(Tjedno opterećenje nastavnika)

Postojanje nekog entiteta (Status zaposlenja na osnovu ugovora)Broj pojavljivanja jednog ili više entiteta

(Broj otvorenih narudžbi za kupca)

OIIS -2013/14

Vrijednost atributaVišestruke vrijednosti atributa

U određeno vrijemeIme OSOBE (neki ljudi imaju više imena)Cijena PROIZVODA (može se razlikovati po područjima)

U različito vrijemePrezime OSOBE (dodatno prezime kod sklapanja braka)Cijena PROIZVODA (nova cijena za novo područje)

Rješenje: Kvalificirati naziv atributa (Krsno ime, Djevojačko prezime)Dodati novi atribut/e (Bazna cijena, Varijabilni dio)Dodati novi entitet/e (Područje)

Nul-vrijednost atributaTrenutno nepoznata vrijednost atributa

Broj telefona za entitet RADNIK (9999999999).Ne nastupa za sve pojave entiteta(neprimjenjivo svojstvo)

Djevojačko prezime za entitet OSOBA.Nul vrijednost nije 0 (nula) niti “ “ (prazan znakovni niz) već vrijednost koja nadomješta nepoznatu ili neodređenu

vrijednost atributa ( - )

OIIS -2013/14

Određivanje atributaRazmatranjem svakog entiteta i traženjem njegovih atributa

Poslovna dokumentacijaZahtjevi korisnika

Dokumentacija postojećeg IS-aRazmatranjem svakog atributa i utvrđivanjem njegove pripadnosti entitetu

Iz neke postojeće liste atributa

KUPAC NARUDŽBA KUPCAŠifra kupca Broj narudžbeJMBG Šifra kupcaIme Datum zaprimanjaPrezime Datum isporukeAdresa Adresa isporukeŠifra mjesta Vrijednost narudžbeTelefon Datum storniranjaStatusPROIZVOD STAVKA NARUDŽBE KUPCAŠifra proizvoda Redni brojNaziv proizvoda Broj narudžbe kupcaVrsta pakiranja Šifra proizvodaCijena Naručena količinaKoličina na zalihi Iznos stavke

OIIS -2013/14

42

Entiteti i atributi – koncepti zavisnosti

Identifikator entitetaJedan ili više atributa koji jednoznačno definiraju pojavu entitetaMinimalno jedan atribut (jednostavan)

OSOBA JMBGMože se sastojati od više atributa (složeni)

TEČAJ Oznaka valute + Datum tečajaPostojeći atributi istog entiteta

JMBG za OSOBUPostojeći atributi nezavisnog entiteta o kojem zavisni entitet ovisi

Šifra kupca + Šifra proizvoda za STAVKA NARUDŽBEUmjetni atribut – ima samo svrhu identifikacije

Matični broj za KLIJENTA (kreiran unutar sustava npr. u banci)

OIIS -2013/14

Koncepti zavisnostiJaki (nezavisni) entitet

Egzistira samostalnoNpr. ŠKOLA, RADNIK

Slabi (zavisni) entitetNe egzistira samostalno - egzistencijalno ovisan

Npr. DIJETE nekog radnika u kadrovskoj evidenciji

Ne identificira samostalno - identifikacijski ovisanNpr. RAZRED određene škole

OIIS -2013/14

Jaki i slabi entiteti

OIIS -2013/14

Podtip entitetaPODTIP ENTITETA

Podskup skupa svih pojavljivanja nekog entitetaNadtip - nadređeni entitet

Sadrži zajedničke atributePodtip - podređeni entitet

Sadrži samo njemu svojstvene atribute (posebnosti)

VOZILO (PLOVILA, KOPNENA VOZILA, ZRAKOPLOVI)KOPNENA VOZILA (CESTOVNA VOZILA, ŽELJEZNIČKA VOZILA)CESTOVNA VOZILA (PUTNIČKA VOZILA, TERETNA VOZILA, OSOBNA VOZILA)POSLOVNI PARTNER (PODUZEĆE, FIZIČKA OSOBA)

PODTIP ENTITETA DEFINIRA SE U SLIJEDEĆIM SLUČAJEVIMA

Definiramo u sljedećim slučajevima:Sadrži neki atribut svojstven samo podskupu pojava entitetaPostoje veze samo nekih pojava entiteta s drugim entitetimaDefiniranje podtipa je prirodno i logičnoNadređenom tipu pristupamo preko podtipa

OIIS -2013/14

Indikator nadtipa i podtipaNadtip/podtip tip objekta sastoji od tipa objekta i jedne ili više potkategorija povezanih odnosom (relationship-om) subcategories, connected by a relationship. ZAPOSLENIK EMPLOYEE može imati kategorije STALNO_ZAPOSLEN i ZAPOSLEN_NA_ODREĐENOPodtipovi su povezani na nadtip preko neimenovanog romba (odnosa). Nadtipje na odnos povezan ukrštenom vezomZAPOSLENIK: Ime, Adresa, Godine_stažaSTALNO_ZAPOSLEN: Plaća, Nadređena_osoba, Org_jedinicaZAPOSLEN_NA_ODREĐENO: Satnica, Početak_zaposlenja, Prekovremeni rad

OIIS -2013/14

Specijalizacija/GeneralizacijaSpecijalizacija/Generalizacija

takozvana "jest" veza (“is a” relationship)veza koja opisuje posebne slučajeve u nekom skupu entiteta, to jest odnos nekog entiteta (nadtip) i njegovih posebnosti (podtip)

podređeni entiteti stvaraju se na temelju njima nadređenog entiteta u kojem dijele zajedničke atribute

nadtip (supertype) - sadrži zajedničke atribute i predstavlja generalizaciju podređenih entitetapodtip (subtype) - sadrži samo njemu svojstvene atribute i predstavlja specijalizaciju nadređenog entiteta

B jest podtip od A ako: B jest uvijek A, A jest ponekad BDjelatnik je uvijek Osoba, Osoba je ponekad Djelatnik (Suradnik)Igla jest uvijek Proizvod, Proizvod jest ponekad Igla (Avion)

specijalizacija može biti:neekskluzivna - Osoba jest Djelatnik ili Suradnik, ali u isto vrijeme može biti i Djelatnik i Suradnikekskluzivna - Proizvod jest Igla ili Avion, ali ne može istovremeno biti I Igla i Avion

OIIS -2013/14

43

Specijalizacija/GeneralizacijaKoliko tipova entiteta za “slične” stvariKriteriji:

Različiti atributiOdvojenost procesiranjaSubjektivna procjena projektanta

KriterijaPoslovnog interesa za praćenje “različitosti”

Kako razlikovati pojavljivanja entiteta u slučaju generalizacije (definiranja jednog entiteta)?Pomoću različitih vrijednosti atributa (neki imaju nul vrijednost)Pomoću različitih tipova zavisnih entiteta -PRODAJNI UGOVOR, UGOVOR S DOBAVLJAČEM

(pojava entiteta PRODAJNI UGOVOR za određenu pojavu entiteta POSLOVNI PARTNER znači da seradi o kupcu)

OIIS -2013/14

Involucija (povratni tip veze)Veza među instancama (pojavama) jednog tipa entiteta

“Veza entiteta samog sa sobom”Tipični slučajevi:

Organizacijska shemaSastavnica (dijelovi proizvoda)

Pogled korisnika (više međusobno zavisnih entiteta):Za svaki tip organizacijske jedinice jedan entitetSEKTOR, DIREKCIJA, POSLOVNICA, ODJEL, …Proizvod i dijelovi su entitetiAUTOMOBIL, KOTAČ, KOMPJUTER, EKRAN, DISK, …

Model:Jedan entitetPovratna veza

OIIS -2013/14

Povratne veze

OIIS -2013/14

Indikator asocijativnog tipa objekta

predstavlja nešto što istovremeno funkcionira kao objekt i kao odnos;predstavlja odnos o kojem bismo željeli održavati neke informacije Pr. KupovinaKUPUJE ne znači ništa do li pridruživanje (asocijaciju) KUPCA i jednog ili više predmetaUkoliko želimo memorirati datum kupovine ili vrijeme (koje nije atribut niti KUPCA niti PREDMETA) tada se vrijeme pridružuje kupovini i ona postaje TIP OBJEKTA i ODNOS Označava se usmjerenom strelicom

OIIS -2013/14

Agregirani (mješoviti) tip entiteta

Koncept koji omogućava promatranje više tipova entiteta i njihovih veza kao novi tip entiteta u sljedećim slučajevima:

Pojavljuje se atribut u tipu veze (Veza ima svojstvo, obilježje)Povezuju se dva tipa vezeRastavljanje višestrukih tipova veze u binarne veze

OIIS -2013/14

Atributi - KljučeviKljučevi

Ključ (key) ili identifikatoratribut ili skup atributa koji (svojim vrijednostima) jednoznačno identificira svaki od entiteta u nekom skupu entiteta

mora se sastojati od bar jednog atributa → jednostavan ključ primjer: OSOBA = @JMBG + Prezime + Ime …– primjer: MJESTO = @ŠifraMjesta + NazivMjesta ...može se sastojati od više atributa → složeni, sastavljeni, ulančani ključ – primjer: MJESTO = @ŠifraDržave+@ŠifraMjesta

ključ mora zadovoljavati sljedeće uvjetejednoznačnost (u skupu entiteta ne smiju postojati dvije pojave s istim vrijednostima svih ključnih atributa)

– primjer: ne smiju postojati 2 osobe s JMBG=020946330097minimalnost (ne postoji podskup atributa ključa koji je također jednoznačan)

– primjer loš: OSOBA = @JMBG + @Prezime ...– primjer dobar: TEČAJ = @KraticaValute + @DatumTečaja + ...

određenost - postojanje vrijednosti u trenutku stvaranja instancestabilnost - otpornost na promjene tijekom vremenaraspoloživost - dostupnost svim korisnicimaneutralnost - s obzirom na značenje vrijednosti ključa (samogovoreće šifre)

OIIS -2013/14

44

Ključevientitet može imati jedan ili više ključeva

entitet mora imati barem jedan ključentitet može imati više mogućih ključeva, tj. kandidata za primarni ključ

(candidate key), koji ne moraju biti međusobno disjunktni, tj. mogu imati atribute presjeka

jedan od ključeva odabire se za primarni ključ (primary key)– primjer: Osoba.IdOsobe, Mjesto.SifMjesta

nakon odabira primarnog ključa, ostali mogući ključevi postajualternativni ključevi (alternate key)

– primjer: Osoba.JMBG, Mjesto.PostBrponekad je potrebno identificirati podskupove entiteta

kriterij podskupa (subsetting criteria) – atribut (jednostavni ili ulančani) s konačnim skupom vrijednosti za grupiranje instanci entiteta upodskupove, u nekim metodama naziva se inversion entry Nejedinstveni indeks

OIIS -2013/14

KljučeviStrani ključ (foreign key)

skup atributa koji se odnosi na ključ drugog skupa entiteta, tj. skup atributa čije se vrijednosti odnose na vrijednosti ključa drugog entiteta

(Osoba.SifMjesta odnosi se na Mjesto.SifMjesta)

OIIS -2013/14

KljučeviKljučeviStrani ključ

ukazuje na povezanost između entiteta, odnosno skupova entiteta – može poprimiti vrijednost primarnog ključa drugog entiteta ili – može poprimiti nul-vrijednost (null value)primjer: – Osoba.SifMjesta odnosi se na Mjesto.SifMjesta, odnosno – Entitet Osoba (IdOsobe=8746) ima SifMjesta=038, tj. referencira entitet Mjesto s IdMjesta=038

Nul-vrijednostNul-vrijednost označava nepoznatu vrijednost atributa ili neodređenu vrijednost atributa, tj. nadomiješta vrijednost atributa koji se ne koristi

nul-vrijednost nije 0 (nula) niti “” (prazan znakovni niz)Primjer: Osoba (IdOsobe=37528) boravi u nepoznatom mjestu, pa joj je SifMjesta nedefinirana vrijednost Vozilo (tipa osobni automobil) nepoznatog registarskog broja, naspram

OIIS -2013/14

Veze - Odnosi (Relationships)Veza (relationship)

pokazuje odnos između entitetaanalogno entitetima, pojedinačna 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

može izražavati ulogu entiteta koje povezujeimenuje se glagolom ili glagolskom imenicom

Primjer (veza i uloge)Osoba STANUJE u Mjestu (Osoba je STANOVNIK Mjesta) u Mjestu STANUJE Osoba (Mjesto je MJESTO STANOVANJA)

OIIS -2013/14

Veze - Odnosi (Relationships)Svaka instanca odnosa predstavlja asoscijaciju između nula ili više pojavnosti jednog objekta i nula ili više pojavnosti drugog objekta KUPUJE može sadržavati slijedeće individualne instance :

instanca 1: kupac 1 kupuje predmet 1 instanca 2: kupac 2 kupuje predmet 2 i 3 instanca 3: kupac 3 kupuje predmet 4 instanca 4: kupac 4 kupuje predmet 5, 6 i 7 itd.Odnos mora biti nešto što će biti zapamćeno od strane sustava (Isto vrijedi i za Tip objekta)

KUPAC KUPUJE PREDMET

Alternative notacije za odnose:

OIIS -2013/14

VezeStupanj veze (degree of relationship)

broj entiteta koji sudjeluju u veziopćenito, može se povezati bilo koji broj entiteta (oprez!)

veza drugog stupnja → binarna vezaveza trećeg stupnja → ternarna vezaopćenito, veza može biti n-tog stupnja → n-arna veza

posebni slučaj jest veza nekog entiteta s tim istim entitetom

veza prvog stupnja → unarna veza (refleksivna, rekurzivna, involucijska) u nekim metodama smatra se posebnim slučajem binarne veze, to jest posebnom vezom 2. stupnja

OIIS -2013/14

45

VezeTip, klasifikacija veze (type of relationship) označava način pridruživanja pojava

entiteta u vezijedan-prema-jedan (1:1)jedan-prema-više (1:N)

može postojati više (paralelnih) veza između dva entitetaviše-prema-više (M:N)

Modalitet veze (modality) i Kardinalnost veze (cardinality)minimalni i maksimalni broj pojava jednog entiteta za pojedinačnu pojavu s njim povezanog entiteta donja i gornja granica kardinalnosti

donja granica može biti 0, 1, pozitivni cijeli broj ili znak (npr. M) donja granica = 0 → djelomično, neobavezno (optional) pridruživanje » ne mora imati niti jednu instancu s druge strane vezedonja granica ≠ 0 → potpuno, obavezno (mandatory) pridruživanje » mora imati barem neki broj ili općenito M instanci s druge strane veze gornja granica može biti 1, pozitivni cijeli broj ili znak (npr. N)

» može imati konkretan broj ili općenito N instanci s druge strane veze veze su dvosmjerne pa se kardinalnost definira za oba smjera veze

OIIS -2013/14

Kardinalnost veze

OIIS -2013/14

Opcionalnost

OIIS -2013/14

Veze

Primjer: binarna veza 1:N

Primjer, binarna veza M:N

OIIS -2013/14

Veze

OIIS -2013/14

Proširenja riječnika podataka na ERD

Objekti i instanceSpremište podataka KUPCITip objekta KUPAC je istovremeno i instanca od KUPCINotacija:KUPCI ={KUPAC}KUPAC = @ime_kupca+adresa+telefon

OIIS -2013/14

46

Nespecifične, neodređene veze

Asocijativni entitet (Gerund)konkatenirani entitet (concatenated entity),kompozitni entitet (composite entity)binarna veza M:N, npr. Proizvoditernarna veza ili veza stupnja >3, npr. Zaposlen

veza o kojoj se želi pohraniti podatke (veza s opisnim atributima), pr. Sastav

Agregacija (agregacijska veza)sinonim: agregacijski entitet (aggregate entity)

veza koja sudjeluje u vezama s drugim entitetimau nekim metodama označava odnos cjelina-dio

OIIS -2013/14

Napomene za kreiranje ERD-aNakon prve verzije ERD-a treba definirati atribute podatkovnih elemenata na jedan od slijedećih načina:

Ako je razvijen DFD ili se radi paralelno s ERD-om tada bi trebao biti razvijen i riječnik podataka koji bi trebao biti u prvoj verziji dostatan za razvoj atributa podatkovnih elemenataAko procesni model nije razvijen potrebno je intervjuiranjem prikupiti podatkovne elemente i dodjeliti im atribute u ERD-u (vremenski zahtjevno)Ako postoji profesionalna grupa za prkupljanje podataka vjerojatno je rječnik podataka razvijen i može se započeti proces dodjeljivanja atributa

http://yourdon.com/strucanalysis/wiki

U dodjeljivanju atributa može se pojaviti potreba za kreiranjem novog tipa objekta zbog: Otkrivanja podatkovnog elementa koji se može atribuirati nekoj instanci objektnog tipa ali ne i drugim instancama (Pr. Zaposleni: u drugom stanju; podjela će se morati napraviti na podtip muški i ženski)Mogu se otkriti neki podatkovni elementi koji su primjenjivi na sve instance dva različita objekta –treba napraviti nadtipMože se otkriti da neki podatkovni elementi opisuju odnose između ostalih tipova objekata (treba uvesti prazan odnos)

OIIS -2013/14

Napomene za kreiranje ERD-aPonekad inicijalni ERD može sadržavati tipove objekata koji koji imaju asocijativni akarakter. Primjer: U ERD-u s tri objekta pri dodjeljivanju atributa tipu objekta npr. Vrijeme isporuke pripada objektu NARUDŽBA jer isporuka ne mora biti obavljena ili je isporuka PROIZVOD urađena na temelju NARUDŽBE koja je u stvari odnos između KUPCA I PROIZVODA o kojem treba memoriarti podatke

OIIS -2013/14

Napomene za kreiranje ERD-aUklanjanje objekta

1. Tip objekta koji sadrži samo jedan identifikator

2. Tip objekta za koji postoji samo jedna instanca

3. “Klimajući” asocijativni tip objekta

4. Izvedeni odnos

1

2

3

4OIIS -2013/14

Pretvorba modela E-V u relacijski model

Izvor: Fertalj, Kalpić: http://www.zpm.fer.hr/courses/pis

Binarna veza 1:N → strani ključegzistencijalni slabi entitet → obični strani ključ

npr. Stanuje → Osoba.SifMjesta, Pripada → OrgJed.SifNadJed,RacunOsoba → Racun.SifOsobe

E-V model predstavlja osnovu za oblikovanje baze na konkretnom sustavu za upravljanje bazom podataka pri čemu se mora voditi računa o:

Tipu vezeKljučevimaNespecifičnim vezamaSpecijalizaciji (tipovima i nadtipovima)

-Primjer:

OIIS -2013/14

Pretvorba modela E-V u relacijski model –integracija

Fertalj, Kalpić: http://www.zpm.fer.hr/courses/pisOIIS -2013/14

47

Literaturahttp://www.aisintl.com/case/datamdl.htmlhttp://www.aisintl.com/case/user_groups/logicworks/library/1997_conference_ppt/index.htm (Logical data modeling)http://en.wikipedia.org/wiki/Data_modelinghttp://en.wikipedia.org/wiki/Entity-relationship_modelhttp://www.idef.com/IDEF1.htmlhttp://www.agiledata.org/essays/dataModeling101.htmlhttp://www.bpmn.org/Fertalj, Kalpić: http://www.zpm.fer.hr/courses/pis

OIIS -2013/14

Literaturahttp://www.aisintl.com/case/datamdl.htmlhttp://www.aisintl.com/case/user_groups/logicworks/library/1997_conference_ppt/index.htm (Logical data modeling)http://en.wikipedia.org/wiki/Data_modelinghttp://en.wikipedia.org/wiki/Entity-relationship_modelhttp://www.idef.com/IDEF1.htmlhttp://www.agiledata.org/essays/dataModeling101.htmlhttp://www.bpmn.org/

OIIS -2013/14

Oblikovanje baze podataka

Izrada sheme baze podatakaNormalizacija i ugađanje bazePostupci za očuvanje integritetaMeta podatci i metabaza

OIIS -2013/14

Napomena


OIIS -2013/14

Oblikovanje baze podatakaJe proces izrade detaljnog modela podataka u bazi podataka: Taj logički model sadrži sve potrebne logičke i fizičke opcije i parametre fizičke pohrane u DDL-u (Data Definition Language) koji se mogu koristiti u krieranju baze (Ključevi, opisna polja)To je logički dizajn strukture baze za pohranu podataka; u relacijskom modelu to su tablice i pogledi, u objektnim bazama to su entiteti i odnosi koji se mapiraju na objektne klase i odnose.Oblikovanje podataka može se shvatiti i kao oblikovanje ne samo strukture baze podataka već i formi i upita koji se koriste u DBMS sustavu. prevođenje podatkovnog modela u strukture podržane odabranom tehnologijom (SUBP)

OIIS -2013/14

Oblikovanje baze podataka –proces oblikovanja

Određivanje podataka koji se moraju pohraniti u bazu podatakaOdređivanje konceptualne sheme - odnosa (relationship) između podatkovnih elemenataLogičko strukturiranje podataka koje će se mapirati na objekte pohrane podržane DBMS-om (tablice koje spremaju podatke u redove i kolone)Fizički dizajn baze – specificira fizički dizajn konfiguracije baze: detaljnu specifikaciju podatkovnih elemenata , tipova podatka, opcionalnih indeksa i ostalih parametara iz rječnika podatka DBMS sustava

OIIS -2013/14

48

Podatkovna shema – shema baze podataka

Proizlazi iz (logičkog) modela podataka odnosno rječnika podataka i obuhvaća: Entitete, atribute i njihove domene:

Tablice – kolone zaglavlja tabliceTip podatka za dati atributRaspone – domene podatka za svaki atributInstance (slogove)

Odnose među njimaSubshema – podskup sheme koji uključuje samo one slogove i odnose potrebne pojedinim korisnicima ili grupi korisnika.

OIIS -2013/14

Normalizacija Postupak za oblikovanje tablica u bazi podataka čiji je cilj minimiziranje dupliciranja informacija, osiguravajući bazu od logičkih i/ili stukturalnih problema (anomalija u podatcima)

Primjer: kada se višestruka instanca (jedan te isti podatak u različitim tablicama) ažurira postoji mogućnost da se ne ažurira u svim tablicama

Problemi vezani uz normalizaciju:Anomalija ažuriranjaAnomalija unosa novog slogaAnomalija brisanja

Postupak za uklanjanje nekih anomalija koje se javljaju kod unosa, brisanja i ažuriranja podataka u bazu podatakaSvrha normalizacije je: da se ukloni (nepotrebna) redundancija (zalihost) podataka,da se ubrza i olakša pretraživanje baze podataka uz upotrebu SQL jezikaPoveća pouzdanost u ispravnost unešenih i pretraživanih podataka

OIIS -2013/14

Normalizacija Teorija normalizacije definirala je

veći broj ograničenja pomoću kojih se definiraju normalne forme. Za definiranje spomenutih normalnih formi važne su:

Funkcijska zavisnostVišeznačna zavisnostSpojna zavisnost (zavisnost spajanja)

Postoji 6 normalnih formi, razvrstanih od nižih(blažih) do viših(strožih):

Prva normalna forma (1NF)Druga normalna forma (2.NF)Treća normalna forma (3.NF)Boyce-Coddova normalna forma (BCNF)Četvrta normalna forma (4.NF)Peta normalna forma (5.NF)

OIIS -2013/14

PARTNER_SIFRA# PARTNER_NAZIV PARTNER_ADRESA MB10 Zagreb d.o.o. Zagreb 3

20 Horizont d.d. Pula 5

30 Josip Ferić Dugo Selo 11

30 Amalija d.d. Rijeka 9

Funkcijska ovisnost

Ključ relacije je PARTNER_SIFRA, a definirane funkcijske zavisnosti su:PARTNER_SIFRA PARTNER_NAZIVPARTNER_SIFRA PARTNER_ADRESAPARTNER_SIFRA MBRelacija nije legalna, funkcijska zavisnost PARTNER_SIFRA PARTNER_NAZIV nije ispunjena jer partner s brojem 30 ima dva naziva.

Izvor; Pavlić, M: Normalizacija podataka,OIIS -2013/14

Nenormalizirana relacijaDefinicija: Relacija se nalazi u prvoj normalnoj formi (1NF) ako su svi neključni

atributi funkcijski ovisni o ključu relacije. Svi atributi moraju biti atomarni; Tablica je u prvoj normalnoj formi (1NF) ako i samo ako ne dozvoljava dupliciranje redaka (ne postoje dva retka s istim primarnim ključem)- uvjet za 1NF je da je definiran primarni ključ

PRIMJER:

MB IME_PREZIME ODJEL_BROJ ODJEL_NAZIV PARTNER_NAZIV

3 Ana Horvat P1 O-Zagreb Zagreb d.o.o.Horizont d.d.

5 Josip Antić P2 O-Osijek Horizont d.d.Kompakt d.o.o.

9 Ante Ivić P3 O-Split Vicko StićHotel F

Amalija d.d.

11 Maja Markić P1 O-zagreb Josip FerićBrzopromet

? ? ? ? A-banka d.d.

Ključ MB ima više vrijednosti atributa PARTNER_NAZIV. Funkcijska zavisnost nije ispunjena.

Neatomarni atribut


1.Normalna formaTok normalizacijeRedudancija relacije koja je u 1NF je velika i pojavljuju se anomalije unosa, brisanja i promjene podataka. Npr. ako se promijeni atribut ODJEL_BROJ P1 u P5 tu promjenu morat ćemo upisivati na sva mjesta gdje se pojavljuje P1, a ne samo na jednom mjestu.Što je uzrok redudancije?Ključ relacije sastavljen je od atributa MB i PARTNER_NAZIV. Pritom atributi IME_PREZIME, ODJEL_BROJ, i ODJEL_NAZIV nisu ovisni o cijelom ključu, nego samo o njegovom dijelu, točnije atributu MB. Taj problem rješava sljedeća normalna forma.

MB IME_PREZIME ODJEL_BROJ ODJEL_NAZIV PARTNER_NAZIV

3 Ana Horvat P1 O-Zagreb Zagreb d.o.o.

3 Ana Horvat P1 O-Zagreb Horizont d.d.

5 Josip Antić P2 O-Osijek Horizont d.d.

5 Josip Antić P2 O-Osijek Kompakt d.o.o.

9 Ante Ivić P3 O-Split Vicko Stić

9 Ante Ivić P3 O-Split Hotel F

9 Ante Ivić P3 O-Split Amalija d.d.

11 Maja Markić P1 O-zagreb Josip Ferić

11 Maja Markić P1 O-zagreb Brzopromet

? ? ? ? A-banka d.d.


49

2.Normalna forma (Potpuna funkcionalna ovisnost)

Tablica je u 2NF ako je prethodno normalizirana u 1NF

Definicija:• Relacija se nalazi u drugoj normalnoj formi (2NF)

ako su svi neključni atributi potpuno funkcijski ovisni o bilo kojem (mogućem) ključu relacije, odnosno funkcijski ovise o svim djelovima ključa.Niti jedan ne-primarni atribut nije funkcionalno ovisan o kandidatnom ključu; drugaim riječima, sve funkcionalne ovisnosti ne-primarnih atributa su potpuno funkcionalno neovisne

OIIS -2013/14

2. NF –tok normalizacijePRIMJER: Relacija TRGOVAC_PARTNER na na prethodnoj slici nije u 2NF.TOK NORMALIZACIJE: Izdvajaju se svi atributi koji djelomično ovise o ključu, zajedno s dijelom ključa o kojem ovise, u novu relaciju.Pregledom relacije TRGOVAC_2 vidi se da još uvijek postoji redudancija koja uzrokuje anomalije pri obradi. Ovdje problem proizlazi iz zavisnosti neključnog atributa ODJEL_NAZIV o drugom neključnom atributu ODJEL_BROJ.Vrjede ove funkcijske ovisnosti: MB ODJEL_BROJ i ODJEL_BROJ ODJEL_NAZIV. Zbog tranzitivnosti vrijedi i MB ODJEL_NAZIV stoga je ova ovisnost u relaciji TRGOVAC_2 nepotrebna odnosno redudantna. Ovaj problem rješava treća normalna forma koja izbacuje tranzitivne ovisnosti.

MB IME_PREZIME ODJEL_BROJ ODJEL_NAZIV

3 Ana Horvat P1 O-Zagreb

5 Josip Antić P2 O-Osijek

9 Ante Ivić P3 O-Split

11 Maja Markić P1 O-Zagreb

MB PARTNER_NAZIV

3 Zagreb d.o.o.

3 Horizont d.d.

5 Horizont d.d.

5 Kompakt d.o.o

9 Vicko Stić

9 Hotel F

9 Amalija d.d.

11 Josip Ferić

11 Brzopromet

TRGOVAC_2(2NF)

TRGOVAC_PARTNER_2 (2NF)


3. Normalna forma (tranzitivna ovisnost)CILJ: Uklanjanje anomalija izmjene odnosno tranzitivnih ovisnosti.

Definicija: Relacija se nalazi u trećoj normalnoj formi (3NF) ako je u 2NF i ako ni jedan neključni atribut nije tranzitivno ovisan o bilo kojem ključu relacije odnosno:Svaki neključni atribut mora ovisiti o ključu, cijelom ključu i samo o ključu!

Ključ A Atribut B1 Atribut B2

Tranzitivna ovisnost

Ključ A Atribut B1 Atribut B1 Atribut B2

Funkcionalne ovisnosti:

A B1 i B1 B2 A B2

B2 je tranzitivno ovisan o ključu A


3.NF - TOK NORMALIZACIJEPRIMJER: Dekompozicija relacije TRGOVAC_2 (2NF) na TRGOVAC_3 (3NF) i

ODJEL(3NF)TOK NORMALIZACIJE: Svi neključni atributi između kojih postoji funkcijska ovisnost

(ODJEL_BROJ ODJEL_NAZIV u primjeru) izdvajaju se u posebnu relaciju.3NF dovoljna je za većinu praktičnih situacija. Ali ne rješava probleme složenih primarnih

ključeva.

MB IME_PREZIME

ODJEL_BROJ

ODJEL_NAZIV

3 Ana Horvat P1 O-Zagreb

5 Josip Antić P2 O-Osijek

9 Ante Ivić P3 O-Split

11 Maja Markić P1 O-Zagreb

MB IME_PREZIME ODJEL_BROJ

3 Ana Horvat P1

5 Josip Antić P2

9 Ante Ivić P3

11 Maja Markić P1

ODJEL_BROJ ODJEL_NAZIV

P1 O-Zagreb

P2 O-Osijek

P3 O-Split

TRGOVAC_2(2NF)

TRGOVAC_3 (3NF)

ODJEL (3NF)

= +

OIIS -2013/14

Boyce-Coddova normalna forma (strožiji oblik 3NF)CILJ: Uklanjanje anomalija izmjeneDefinicija 1: Relacija je u Boyce-Coddov normalnoj formi (BCNF) ako sve

funkcijske ovisnosti proizlaze iz njezinog ključa.Definicija 2: Ako je atribut iz složenog ključa ovisan o nekom atributu A

sheme relacije, tada taj atribut mora biti ključ.

PRIMJER: Relacija koja je u 3NF, a koja ne udovoljava BCNF.

MB POSAO_SIFRA PARTNER_SIFRA

1 A1 10

3 B2 20

5 C1 75

5 C2 75

9 D3 30

TRGOVAC_POSAO

mora biti ključ

Funkcijske ovisnosti:

MB,POSAO_SIFRA PARTNER_SIFRA

PARTNER_SIFRA MB

Javlja se redudantnost. Npr. informacija da je partner 75 vezan uz trgovca 5 navedena je u dvije n-torke. Pošto vrijedi PARTNER_SIFRA MB informacija bi trebala biti zabilježena samo jednom


BC NFTOK NORMALIZACIJE: Izdvaja se neključni atribut preko kojeg je

ostvarena tranzitivna funkcijska ovisnost dijela ključa u novu shemu relacije koja sadrži i atribut o kojemu je izdvojeni atribut funkcijski ovisan.

PARTNER_ŠIFRA MB

10 1

20 3

75 5

30 9

PARTNER_ŠIFRA POSAO_ŠIFRA

10 A1

20 B2

75 C1

75 C2

30 D3

PARTNER_TRGOVAC PARTNER_POSAO

Dekompozicija je pouzdana (reverzibilna), ali u njoj nisu sačuvane funkcijske ovisnosti zadane početnom relacijom. Izgubljena je funkcijska ovisnost MB,POSAO_ŠIFRA PARTNER_ŠIFRA. U ovom slučaju bolje je zadržati relaciju u 3NF nego izgubiti jednu funkcijsku ovisnost.


50

Denormalizacija

Prije početka kodiranja obavlja se ograničeno uvođenje zalihosti i ugađanje baze podataka zbog poboljšanja elastičnosti i poboljšanja performancizahvat može rezultirati određenim brojem intervencija u logički modelDenormalizacija - ograničeno i kontrolirano narušavanje NF

OIIS -2013/14

DenormalizacijaDijeljenje i udruživanje tablica

dijeljenje tablica smještanjem rijetko korištenih atributa u posebnu tablicuudruživanje tablica ili uklanjanje pojedinih tablica stapanjem atributaobične veze 1:1• udruživanje nadtipa s podtipovima kardinalnosti 1:1, pod uvjetom da su slične strukture i sadržaja

Uvođenje zalihostidodavanje atributa za pohranu izvedenih vrijednosti

atribut pohrane za izvedenu vrijednost koja se može izračunati agregatnom funkcijom (npr. iznos računa kao suma iznosa stavki)

oznaka zadnje vrijednosti nekog stanja kada se vrijednosti pojedinih stanja nalaze u tablici s velikim brojem zapisa (npr. stanje skladišta)redundantna vrijednost koja se inače dohvaća složenim i/ili sporim upitima (zadnje zaposlenje + zadnji izbor u zvanje + zadnje školovanje)dodavanje atributa kao što su zastavice za "trajno" označavanje zapisaPodrazumijeva se da se denormalizacija obavlja samo na mjestima gdje je to stvarno nužno i na takav način da ne ugrožava integritet podataka - aplikacijsko upravljanje integritetom

OIIS -2013/14

Očuvanje integriteta bazeOčuvanje integriteta stvaranjem objekata u rječniku BP

Entitetski integritet - postavljanjem primarnog ključaReferencijski integritet - postavljanjem stranog ključa i ograničenja na unos

mora postojati vrijednost stranog ključa (mandatory→ not null)strani ključ smije se postaviti na nul-vrijednost (optional→ null)

Domenski integritet - postavljanjem ograničenja na skup vrijednostiAlternativni ključevi - obveznim atributima i jedinstvenim indeksima

Pravila referencijskog integriteta – opći slučajPostupci prilikom unosa, ažuriranja i brisanja roditelja ili djeteta

zabrana (restrict) brisanje n-torki koje imaju odgovarajuću vrijednost stranog ključa (cascade)ažuriranje odgovarajućih vrijednosti stranih ključeva (set null)postavljanje na standardnu vrijednost (set default)

OIIS -2013/14

Ugađanje baze podatakaPostavljanje indeksa radi

osiguranja integriteta podatakaubrzanja dohvata podataka

Preporuke za postavljanje indeksaJedinstveni indeks nad primarnim i alternativnim ključem (integritet)Indeks nad stranim ključem (ubrzanje provjere integriteta i spojnih upita)Indeksi nad najčešće korištenim poljima, tj poljima koja se koriste za grupiranje, sortiranje ili selekciju uz uvjet (ubrzanje pretraživanja)

Neki sustavi implicitno kreiraju indekse za primarne i strane ključeveopćenito, u tom slučaju ne treba posebno kreirati indekseako su ključevi složeni pretraga će raditi brzo uglavnom po prvom polju

– po potrebi postaviti dodatne indekse nad preostalim poljimaGomilasti indeks (CLUSTERED INDEX), Faktor popunjenosti (FILL FACTOR), ....Promjene podataka uzrokuju ažuriranje indeksa.Izbjegavati nepotrebne i indekse koji su sastavni dio drugih indeksa!Ukloniti indekse prigodom masovnih obrada podatakaKoristiti naredbe i opcije za uvoz podataka (BULK INSERT ... CHECK_CONSTR.)Treba li kreirati indeks u tablicama s malim brojem podataka?

OIIS -2013/14

Ugađanje baze podatakaMinimizacija nul-vrijednosti

problem neodređenih vrijednosti agregatnih funkcija, problem operacija s nul-vrijednostima– primjer: SELECT AVG(polje), gdje polje ima/nema nul-vrijednostiopisna polja - zahtijevana vrijednost + pretpostavljena vrijednostproblem vanjskih spojnih upita

strana polja – posebne vrijednosti u šifrarnicima– primjer: 0-nepoznata vrijednost, 999-nepostojeća vrijednost

Ubrzanje upitaanaliza plana izvođenja (Execution Plan) i odabir poželjnog plana

– primjer: SELECT ... OPTION (FORCE ORDER)primoravanje korištenja određenog indeksa

– primjer: SELECT ... WITH (INDEX(index, index...))primoravanje nekorištenja indeksa primjenom neškodljive funkcije nad poljem nad kojim se uobičajeno koristi indeks

– primjer: WHERE NULLIF ( polje , “” ) = ...ostale opcije– primjer: SELECT ... OPTION (FAST n_rows)

OIIS -2013/14

Pohrana podataka – vrste bazaVrste datoteka/tablicaMatične - dodani zapis ostaje “zauvijek” u sustavu, može se mijenjati

primjer: Kupac, Artikl, Predmet, OrgJedinicaTransakcijske (prometne) – zapisi poslovnih događaja, ograničeni vijek, uklanjanje zapisa uz arhiviranje

primjer: Racun, PrijavnicaŠifrarnici – statički podaci koji se koriste od različitih aplikacija radi očuvanja konzistentnosti podataka i poboljšanja performansi

primjer: Mjesto (poštanski brojevi), StatusNecegaDokumentacijske – kopije povijesnih podataka za lakši dohvat i pregled bez regeneriranja dokumenataArhivske – uklonjene iz medija za direktni (on-line) pristupDnevnici (audit, log) – evidencija pristupa i promjena podataka

OIIS -2013/14

51

Metamodeli (baza) podataka

Meta-model – model baze podatakaMeta-baza – baza podataka o bazi podatakaŠifrarnici

DokumentiOpisi događajaOpisi procesa

OIIS -2013/14

Metamodel

OIIS -2013/14

Metamodel

OIIS -2013/14

Oblikovanje programskih rješenja

OIIS -2013/14

Napomena


OIIS -2013/14

Specifikacija i dizajn programske podrškeSpecifikacija programske podrške (software specification),

specifikacija programa (program specification)navođenje svih zadataka koje program treba obavitimeđusobne povezanosti različitih dijelova programa i podatakaopis vrste podataka, opis ulaznih i izlaznih podatakaspecifikacija prikaza podataka\Dokumentacija\SpecifikacijaZahtjeva

Dizajn programske podrške (software design) dizajn programa (program design, software design)

proces pretvorbe zahtjeva na programsku podršku u oblik koji omogućuje programiranjeopis jezikom za oblikovanje programa (PDL - Progam Design Language) pri čemu program napisan pomoću PDL nema oblik izvedbenog programa Dokumentacija\SpecifikacijaDizajna

Fertalj, Kalpić: http://www.zpm.fer.hr/courses/pis

OIIS -2013/14

52

Pristup oblikovanju programaFunkcionalni pristup (Yourdon, Constantine, 1979)

strukturirani dizajn programske podrškesvladavanje veličine i složenosti programa razradom u hijerarhiju modulaprogramski modul – grupa instrukcija

paragraf, blok, potprogram, subrutinapodjela programa i/ili sustava module ili tzv. crne kutije (black box)

veliko unutarnje prianjanje modula – kohezija (cohesion)– moduli moraju biti interno visoko povezani–svaki modul treba obavljati jednu i samo jednu funkciju– postizanje ponovne upotrebljivosti u budućim programima

mala vanjska zavisnost modula – skopčavanje (coupling)– moduli trebaju biti minimalno međusobno zavisni– minimizacija utjecaja promjene jednog modula na druge module


Pristup oblikovanju programaPodatkovno usmjereni pristup (Jackson, Warnier,

1981)struktura podataka određuje strukturu programa

Objektno usmjereni pristuppodjela u razrede (klase) koji istovremeno sadrže podatkovne strukture i procedure(metode) koje se obavljaju nad objektima (instancama) razredakohezija i skopčavanje također se uvažavaju, a provode kontroliranim nasljeđivanjem, sučeljima i fasadama između razreda i komponenti


Strukturirani dizajn

OIIS -2013/14

Strukturna kartaStrukturna karta (Structure Chart)� modeliranje programske podrške na temelju dijagrama toka podataka• dijagram toka podataka prikazuje ŠTO treba postići• strukturnom kartom izražava se KAKO ostvariti zahtjeve� prikaz hijerarhije programskih modula koji uključuje• prijenos podataka i upravljanja između različitih razina obrade• prikaz slijedne, ponavljajuće i uvjetne obrade� elementi prikaza:

funkcija

iteracija selekcijaUgrađena funkcija -

modul

podatakpoziv

kontrola

OIIS -2013/14

Transakcijska analizaTransakcijska analiza (transaction analysis)analiza izvršenja/obavljanja obradeprimjenjuje se na sustave sa jasno raspoznatljivim središtima izvršenja(transaction centre), tj. sustave u kojima se donosi odluka o tome koji će seproces koristiti za pretvorbu ulaza u izlaze (npr. interaktivne aplikacije)Ulaz se usmjerava

3

25

46

B2B1

BC3

B3

CC1C2

B C

55 5

C2

C3C1

B3

B2B1

OIIS -2013/14

Opis logike programa

Dijagram toka Blok dijagramPseudokodAkcijski dijagramiTablice odlučivanjaStruktogrami

OIIS -2013/14

53

Standardizacija i modularnostprogramske podrške

U brojnim programskim aplikacijama postoje rješenja za određene vrste poslova koji su tijekom razvoja velikog broja sustava standardiziraniProcedure za te procese standardizirane su i u pojedinim vrstama programskih alata i programskih jezikaPoslovna i druga složena programska rješenja uobičajeno se izrađuju kao moduli za pojedine vrste procesa i u kompleksnoj aplikaciji mogu se preko jedinstvene baze podataka međusobno lako povezati

OIIS -2013/14

Standardizacija i modularnostprogramske podrške

Standardne funkcije modula aplikacije za rad s bazom podatakaUlaz u modul

automatski prikaz podataka na temelju uvjeta / parametera– niti jedan zapis– svi zapisi– odabrani zapisi (primarni ključ, uvjet za selekciju zapisa)

Traženje (selekcija) podatakamora podržavati traženje po uzorcima (query by example), koji se unose s ekranske maske (query by form)ako programski jezik nema neproceduralnih naredbi za konstrukciju uvjeta selekcije, treba ih programski simulirati

Unos novog zapisaobavlja odgovarajuću provjeru domenskog, entitetskog i referencijalnog integritetatreba omogućiti odabir i po potrebi unos podataka koji se nalaze u drugim tablicama, a povezani su preko stranog ključa


OIIS -2013/14

Oblikovanje sučeljaKorisnička sučelja

tekstovna, grafičkamasovni unos (batch input) - periodičko pretipkavanjeinteraktivni unos (on-line) - na mjestu nastanka

Automatizirani unosbiometrijski uređaji - otisci prstiju, uzorci glasaelektromagnetski uređaji - identifikacija objekata s pomoću radio valovamagnetski uređaji - magnetske kartice i drugooptički čitači - • optical-mark reader (OMR), • optical-character reader (OCR)pametne kartice (smart cards) - mikroprocesor, memorija, baterijauređaji osjetljivi na dodir - touch screen, touch-pad, pen-based

Izlazi - izvješćadokument - npr. prijavnica, račundetaljna - dokumentiranje obrade, povijest i stanja evidencijezbirna - grupiranje, sortiranje, iznimkegrafička - točkasti, štapičasti, linijski, torta, ...


OIIS -2013/14

Elementi grafičkog sučelja za unos podatakaText Box i varijante

slobodni tekstRadio Button

vrijednosti iz konačnog malog skupaunaprijed poznatih, međusobnoisključivih vrijednosti (2 do 3)

Check Boxbinarne vrijednosti, opcionalno"nepoznato"

Drop-Down ili Combination(Combo) Boxumjereno velik broj (?) poznatih (?),međusobno isključivih vrijednosti

List Boxumjereno velik broj (?) poznatih, nenužno isključivih vrijednosti

Spin (Spinner), DomainUpDown,NumericUpDown

nevelik slijed diskretnih vrijednostiGrid – mreža, matrica

kombinacije osnovnih elemenata


OIIS -2013/14

Objektno orijentirani pristup

OIIS -2013/14

Karakteristike objektnog pristupa

IntuitivnostLakoća uočavanja pogrešakaLakoća održavanja Lakoća oblikovanjaMogućnost za ponovu upotrebu istih koncepata na drugim slučajevima

OIIS -2013/14

54

Konceptualne osnove Objekt je stvar iz realnog svijeta o kojoj se vode podatci i način manipulacije tim podatcimaPodatci o objektu (atributi) i procesi nad tim podatcima se integrirajuObjekti sličnih svojstava se grupiraju u klase Pojedinačni objekt je instanca (pojava) klase objekataSloženi sustavi grade se iz pojedinačnih komponenti.

OIIS -2013/14

Konceptualne osnoveučahurivanje (encapsulation) – podatci (atributi) i metode (procesi) kojima se pristupa podatcima ili vrši bilo kakva manipulacija nad podatcima su združeni u objektu (detalji ugradnje su sakriveni - objekti su “crne kutije” čijim se podacima rukuje putem ugrađenih metoda)razmjena poruka (messaging/signaling) – objekti su izolirani i za međusobnu komunikaciju se šalje poruka da bi izveo neku od svojih metoda, i time promijenio stanje nekog od svojih atributa npr. Promjena stanja objekta generira signal koji pokreće metodu na drugom objektu Dodaj proizvodnasljeđivanje (inheritance) – podrazred (subclass) nasljeđuje svojstva i

metode nadrazreda (superclass), npr. Desktop računali i Notebook računalo nasljeđuju superklasu Računalo višeobličje (polymorphism) – operacija ili metoda je polimorfna ako proizvodi slične rezultate na različitim objektima ili na različitim razinama objekta. Npr. Prodaja robe kupcu, povrat robe, isporuka robe su događaji koji mijenjaju stanje zaliha robe na skladištu. Struktura metode za ažuriranje podataka m ože se naslijediti s klase najviše razine i nakon toga ju prilagoditi za svaki od posebnih slučajeva.

OIIS -2013/14

Objektno usmjereni razvojObuhvaća:

Objektno orijentiranu analizuIdentifikacija i opis klasa objekata koji opisuju (čine) sustav

postojeći objekti i mogućnost nihova korištenjaNovi objekti važni za buduću primjenu IS sustava

Objektno orijentirano oblikovanje (design)Definiranje softverskih objekata koji će se implementirati u OO jezikuRazrada zahtjeva, karakteristika podataka i procesaDefiniranje novih skupova objekata

Objektno orijentirana konstrukcija (programiranje)Implementacija objekata na objektno orijentirani jezik (C++, Java, Visual basic)

OIIS -2013/14

Objektno orijentirano modeliranje vizualno modeliranje – dijagrami i jezici

DijagramiDijagrami struktura

Dijagrami klasaDijagrami objekataDijagram komponentiDijagram upotrebe

Dijagrami ponašanjaDijagrami slučajeva korištenjaDijagrami sekvenicijaDijagrami suradnjeDijagrami aktivnosti

Jezici:UML – Unified Modelling Language (objedinjeni jezik za modleiranje)Može se koristiti za sve faze životnog ciklusa razvoja IS-aMože se koristiti za:

Modeliranje podatakaModeliranje procesaModeliranje komponenata i odnosa

OIIS -2013/14

Dijagrami klasa (razreda)Razred (class) = kolekcija, skup objekata sa zajedničkom strukturom, zajedničkim ponašanjem, zajedničkim vezama i zajedničkom semantikom, na primjer C-StudentObjekt – pojedinačna pojava (objekt, instanca) iz nekog razreda, na primjer C-Maja Majić i C-Pero Perić iz razreda C-student Definiranje razreda

NazivOpis (komentar) – slobodan tekst u vitičastim zagradamaAtributi - struktura kojom su određena svojstva objekataOperacije - procesi/servisi koje razred (objekt) zna obaviti, čime se određuje ponašanje objekata

OIIS -2013/14

Primjer za klasu (razred)Primjer: Definirati klasu StudentSvaki student ima svoj broj indeksa, prezime, ime i prosjek ocjena. Student može prijaviti i odjaviti ispit te mu pristupiti. Za prijavu i odjavu ispita potrebna je šifra predmeta, a operacije vraćaju vrijednosti jesu li uspjele ili ne. U slučaju pristupanja ispitu povratna vrijednost je dobivena ocjena na ispitu.

OIIS -2013/14

55

Atributisvojstva klasanavode se u pravokutniku ispod naziva klaseimaju i svoja svojstva:

naziv – prva riječ piše se malim slovom, početno slovo ostalih riječi velikim (brojIndeksa)vidljivost

javno (public) – dostupan svim klasama i paketima (simbol: +)privatno (private) – dostupan unutar iste klase (simbol: - )zaštićeno (protected) – dostupan unutar iste klase i izvedenih klasa (simbol: #)paket (package) – dostupan svim klasama istog paketa (simbol: ~)

tipUML tipovi (Boolean, Integer, String, UnlimitedInteger)Java tipovi (byte, char, double, float, int)

početna vrijednost – moguće je atributima dodati neku inicijalnu vrijednost (npr. za klasu automobil definiramo atribut brojVrata i dodijeljujemo mu vrijednost 4 brojVrata = 4)

OIIS -2013/14

OperacijeOperacije su procesi koje klasa može izvršiti. Navode se u pravokutniku ispod atributa.Svojstva operacija mogu biti:vidljivost (isto kao i kod atributa)ulazni i izlazni parametri – svojstveni samo za operacije. Određuju ulazne vrijednosti koje operacija dobiva i izlazne koje vraća.

Pravilo pisanja operacija:[vidljivost] imeOperacije (parametri)

OIIS -2013/14

Odnosi među klasamaPostoje 2 osnovna tipa odnosa među klasama: pridruživanje i podtip. Pridruživanjepredstavlja statične odnose između dvije klase, dok podtip predstavlja oblik odnosa između klasa (jedna klasa je 'roditelj' jednoj ili više drugih klasa)

PRIDRUŽIVANJE (ASOCIJACIJA)

OIIS -2013/14

PridruživanjeVrste pridruživanja (veza):•jednosmjerne (unidirekcionalna) – smjer definiran samo na jednom vrhu•dvosmjerne (bidirekcionalna) – smjer definiran na oba vrha•agregacije•refleksivne

Dozvoljene vrijednosti:

1 = točno 1 pojedinacn1 = bilo koji točno određen broj (0, 1, 5, 23)n1.. n2 = između n1 i n2 (5..8 5, 6, 7 ili 8)n1..n = između n1 i više pojedinacan1...n2, n3 = kombinacija (4..7,9 4, 5, 6, 7 ili 9)n..* = n ili više pojedinaca, neograničeno (5..* 5 ili više)

Primjer: Višestrukost veze između klase Student i Indeks

OIIS -2013/14

AgregacijaAgregacija predstavlja vezu u kojoj promatrana klasa pripada kolekciji unutar neke druge klase, tj. da jedna klasa sadrži druge (klasa je agregirana u drugoj klasi). To je oblik odnosa nadskup-podskup, odnosno cjelina-dio.

simbol:

Primjer: U nekom poduzeće postoje odjeli nabave, prodaje, financija... Zaposlenici su zaposleni u tim odjelima.

OIIS -2013/14

KompozicijaKompozicija je slična agregaciji, ali se uništavanjem agregata (cjeline) uništavaju i njegovi dijelovi. Kaže se da je ona jaki tip agregacije. U slučaju kompozicije promatrana klasa ne može egzistirati bez neke druge klase. Označavanje kompozicije identično je agregaciji.

Simbol:

OIIS -2013/14

56

NasljeđivanjeIzmeđu različitih klasa često postoje sličnosti. Dvije ili više klasa mogu dijeliti iste atribute i/ili iste metode. Budući da se želi izbjeći nepotrebno ponavljanje programskog koda, koristi se koncept nasljeđivanja koji omogućava ponovno korištenje postojećih podataka i kodova.

Kada klasa A nasljeđuje od B, kaže se da je A podklasa klase B, a B nadklasa klase A. Nadalje, termin „čisto nasljeđivanje“ označava kada klasa A nasljeđuje sve atribute i metode od klase B.

Jedna klasa je 'roditelj' jednoj ili više drugih klasa, a veza nasljeđivanja uvijek je usmjerena od podklase prema nadklasi

OIIS -2013/14

Generalizacija i SpecijalizacijaOdnos između općenitog i njemu određenijeg elementanadređeni razred ili tip (superclass, supertype)podređeni razred ili tip (subclass, subtype)Sve što vrijedi za nadređeni element vrijedi i za podređeni element,ali ne i obrnutoStrelice označavaju odnose derivacija: proširuje, implementira, "je tipa", "ima obilježja od", itd.Generalizacijastvaranje nadklase koja objedinjuje ponašanje zajedničko za nekoliko klasausmjerena je od podklase prema nadklasi

Specijalizacijastvaranje podklasa koja predstavlja dodavanje novih elemenatausmjerena je od nadklase prema podklasi

OIIS -2013/14

Ovisnostiodnos koji pokazuje da jedna klasa ovisi o drugoj klasi. promjena u jednom (neovisnom) entitetu može utjecati na drugi (ovisni) entitetneovisni entitet isporučiteljovisni entitet klijentjednosmjerna vezasimbol:

Primjer: Postoje 2 klase: A i B. Klasa B ovisi o promjenama klase A.

OIIS -2013/14

DIJAGRAM OBJEKATA (OBJECT DIAGRAM)

Prikazuju stukturu sustava u nekom trenutku. Taj prikaz može biti djelomičan ili cjelovit, tj. nije nužno prikazati objekte svih razreda sustava.Dijagrami objekata generiraju se iz dijagrama klasa predstavljaju instancu klase

Simbol objekta je pravokutnik u kojem se prikazuju 2 dijela – jedan za naziv objekta, a drugi za vrijednost atributa. Objekti se razlikuju od klasa jer nemaju definicije atributa i operacija, ali imaju jasno naznačeno stanje važnih atributa.

Naziv objekta piše se podvučeno, a u nastavku stavlja se znak dvotočke te naziv klase kojoj pripada.

OIIS -2013/14

Veze među objektimaDijagrami objekata sastoje se od objekata i veza. Za pridruživanja objekata najčešće se koristI dvosmjerna veza, a dozvoljeno je korištenje i kompozicije. Ako su dvije klase povezane nasljeđivanjem, veza između njihovih objekata biti će dvosmjerna. Višestrukost veze je uvijek 1.

U izradu dijagrama objekata prvo odaberemo klase čije objekte ćemo prikazati. Najčešće su to najvažnije klase za ispravno funkcioniranje sustava.Nakon toga unosimo proizvoljne vrijednosti u objekte, ali pazimo da one ispravno demonstriraju vrijednosti koje će atributi imati tijekom rada sustava.Na kraju povezujemo objekte, označavamo veze gdje je to potrebno i završavamo izradu dijagrama.

Primjer:

OIIS -2013/14

Nasljeđivanje objekataPojedinci klase koji nasljeđuju druge klase automatski nasljeđuju i sve atribute roditelja.

Primjer: Naveden je primjer dijagrama klasa koji prikazuje nasljeđivanje klasa Student i Profesor. Na temelju tog dijagrama potrebno je kreirati dijagram objekata.

OIIS -2013/14

57

DIJAGRAM SLUČAJEVA KORIŠTENJA (USE-CASE DIAGRAM)

Dijagrami slučajeva korištenja prikazuju ponašanje sustava, dijelova sustava ili konkretne klase na način vidljiv korisniku sustava. Ponašanje sustava opisano je pomoću ciljeva i sudionika koji predstavljaju apstrakciju korisnika sustava. Ovi dijagrami opisuju samo poglede na ponašanje sustava sa strane korisnikovepercepcije i ne opisuju kako je funkcionalnost izvedena unutar sustava.

OIIS -2013/14

DIJAGRAM SLUČAJEVA KORIŠTENJA – simboli i veze

Slučaj korištenja (use case) je skup scenarija povezanih jednim ciljem korisnika. Predstavlja apstraktni zadatak kojeg izvode sudionici. Izvršavanje svakog slučaja korištenja neovisno je od drugih slučajeva korištenja.Sudionik (actor) je vanjski entitet direktno povezan sa sustavom. Inicijator svih akcija je sudionik. Oni su vanjski dijelovi sustava te su njihove odgovornosti također van sustava.Sudionicima se dodjeljuju imena, koja ne bi smjela biti povezana sa organizacijom poduzeća ili nekim određenim korisnikom. Može biti živo biće ili neki drugi sustav. Na dijagramima sudionici su prikazani pojednostavljenim prikazom čovjeka.Dva su tipa sudionika – primarni i sekundarni. Primarni sudionik pokreće slučaj korištenja (smjer strelice je od sudionika prema slučaju korištenja), a sekundarni je sudionik slučaja korištenja nakon što je on pokrenut (smjer strelice je od slučaja korištenja prema sudioniku).

OIIS -2013/14

DIJAGRAM SLUČAJEVA KORIŠTENJA – asocijacija

Asocijacijom se povezuju sudionici sa slučajevima korištenja u kojima sudjeluju. Moguće je koristiti i višestrukost pri čemu se određuje koliko puta neki sudionik sudjeluje u određenom slučaju korištenja te koliko sudionika može izvesti određeni slučaj korištenja.

OIIS -2013/14

DIJAGRAM SLUČAJEVA KORIŠTENJA – generalizacija

Generalizacijom se povezuju dva sudionika ili dva slučaja korištenja.U slučaju da se generalizacijom povezuju dva sudionika, specifičniji sudionik preuzima sve uloge apstraktnijeg uz dodatak novih uloga. Kod korištenja generalizacije između dva slučaja korištenja specifičniji proširuje odnosno mijenja funkcionalnosti apstraktnijeg.

OIIS -2013/14

DIJAGRAM SLUČAJEVA KORIŠTENJA – uključivanje

Vezom uključivanja se povezuju dva slučaja korištenja na način da jedan slučaj u tijeku svog izvođenja u potpunosti izvede uključeni slučaj korištenja.

OIIS -2013/14

DIJAGRAM KOMPONENTI (COMPONENT DIAGRAM)

Komponenta je zasebna cjelina programske potpore s vlastitim sučeljem.Dijagrami komponenti prikazuju komponente sustava i njihove međusobne odnoseKomponentni dijagrami pomažu u modeliranju fizičkih cjelina sustava kao što su izvršne datoteke, programske biblioteke, tablice, datoteke i svi drugi dokumenti. Dijagrami komponenti su strukturni UML-dijagrami. Prikazuju vremenski nepromjenjiva (statička) svojstva sustava s fizičkog aspekta implementacije.

Primjer: Prikazati sistemsku datoteku 'gdi32.dll' operacijskog sustava Windows. Datoteka eksportira Graphics Device Interface(GDI) programsko sučelje.

OIIS -2013/14

58

DIJAGRAM KOMPONENTI –vrste komponenata

Komponente razmještaja - nužne i dovoljne za ispravan rad dizajniranog sustava. Npr. dinamički povezane biblioteke (dynamic linked libraries DLL) i izvršne datoteke (*.exe)Komponente radnog proizvoda su nastale tijekom razvoja sustavaNpr.datoteke s izvornim kodom (source code) i datoteke s podacima (data filesKomponente izvođenja su nastale kao posljedica izvođenja i rada sustava.Npr. COM+ objekti jer nastaju izvođenjem DLL datotekaProgram Debug Database (PDB) datoteke nastale tijekom izrade .NET projekata

OIIS -2013/14

DIJAGRAM KOMPONENTI –stereotipovi komponenataPostoji 5 standardnih stereotipova:

<<executable>> komponenta može biti izvršna u čvoru<<library>> komponenta je statička ili dinamička biblioteka<<table>> komponenta je tablica baze podataka<<file>> komponenta je dokument s izvornim kodom ili podacima<<document>> komponenta je dokument općeg značenja ili sadržaja

OIIS -2013/14

DIJAGRAM KOMPONENTI –sučelja komponenti

Sučelje je kolekcija operacija koja određuju usluge komponente. Ponašanje komponente definirano je pomoću njezinih sučelja. Komponenta može biti zamijenjena drugom ako i samo ako su njihova sučelja identična.

OIIS -2013/14

DIJAGRAMI PAKETA

Paket - opći mehanizam grupiranja lemenata, logički povezana grupa elemenata modela, dio modelaDijelovi paketa – općenito podsustavi, manji paketi, usecase, komponenteKoriste se u fazi razvoja sustava za npr. organizaciju izvornog koda

OIIS -2013/14

Dijagram paketa

Primjena paketa

•Za veće projekte•Za testiranje•Za uočavanje zavisnosti•Održavanje kontrole nad strukturom cjelokupnog sustava

.

OIIS -2013/14

SEKVENCIJSKI DIJAGRAM (SEQUENCE DIAGRAM)

Prikazuju interakciju objekata u vremenskom slijedu - daje naglasak vremenskom radoslijedu kojim se odvija međudjelovanje sudionika u sustavuSudionici koji se modeliraju na sekvencijskim dijagramima mogu biti sudionici (predočavanjem komunikacije sudionika s dijagrama slučajeva korištenja) ili objekti, pri čemu se prikazuje komunikacija instanci klasa prikazanih na dijagramu klasa.Sudionici se crtaju u obliku pravokutnika s nazivom sudionika unutar njega koji je podcrtan.Ispod sudionika proteže se linija koja se naziva životna linija sudionika i može biti puna ili isprekidana. Ona označava boravak sudionika u međudjelovanju unutar sustava koji se modelira.Objekti i/ili razredi prikazani horizontalno na vrhu isprekidanih vertikalnih crta, linija životaPoruke prikazane strelicama između linija života objekata koji komunicirajuLinija života (lifeline): život objekta za vrijeme interakcije

OIIS -2013/14

59

SEKVENCIJSKI DIJAGRAM –primjer: otvaranje računa

OIIS -2013/14

Sekvencijski dijagram -tumačenje

Objektiprvi stupac: uobičajeno sudionik koji inicira slučaj korištenjadrugi stupac: granični objekt (boundary object), kojim sudionik pokreće slučaj korištenjaostali stupci: objekti koji upravljaju slučajem korištenjaPorukePoruka predstavlja poziv postupka referenciranog objektaoruke se označavaju barem nazivom porukeOznaka se može proširiti argumentima poruke te povratnim vrijednostima i/ili upravljačkim informacijamaVremenska osnelinearna, određena događajimačita se s vrha prema dnuprikazuje redoslijed, a ne stvarno vrijemeLinija života objektapovezuje postojanje i cjelokupno ponašanje objektaredoslijed linija nema posebno značenjezlomljena linija života označava da objekt nije aktivan, kvadrat označava da je objekt aktivan.

OIIS -2013/14

Modeliranje i implementacija IS-a

Implemantacija IS-a

OIIS -2013/14

Napomena


OIIS -2013/14

Implementacija – izrada i ugradnja sustavaImplementacija sustava, ugradnja sustava

izrada novog sustava i isporuka tog sustava u produkciju, to jest svakodnevnu primjenuIzrada sustavafaza u kojoj se obavlja

izgradnja i testiranje mreža (po potrebi)izrada i provjera baze podataka

– kreiranje baze podataka,– transfer probnih podataka,– testiranje operacija nad podacima

instalacija i testiranje novih softverskih paketa (po potrebi)pisanje i testiranje novih programa, pisanje programske dokumentacije

– provodi se prema detaljnom planu programiranja– prethodno se stvara izvedbena ekipa i pridjeljuju odgovornosti članovima

drugi nazivi: konstrukcija, izvedba, provedba


OIIS -2013/14

Kodiranje, programiranjeKodiranje

pretvorba detaljnog programskog opisa u stvarni program, najčešće primjenom nekog formalnog programskog jezikaručno kodiranje

neizbježno zbog veličine stvarnih problema i složenosti procesasporo i dugotrajno → primjena jezika visoke razine

– jezici četvrte generacije (4GL – Fourth Generation Language)– objektno zasnovani jezici (Object Based Language)– objektno usmjereni jezici (Object Oriented Language)

poželjno je da konkretni jezik uz prevodilac (compiler) uključuje interpretator (interpreter) te alat za otkrivanje pogrešaka (debugger)

automatsko kodiranjegeneriranje programskog koda, sučelja, sheme baze podataka

Istovremeno korištenje različitih programskih jezika, a naročito jezika različitih generacija treba koristiti samo po potrebi, primjerice kada se želi ukloniti neke nedostatke osnovnog jezika kojim se obavlja razvoj.

OIIS -2013/14

60

Kodiranje, programiranjeStrukturirano programiranje, Strukturno programiranje

tehnika programiranja koja podrazumijevapristup odozgo prema dolje (top-down programming) iuporabu programskih struktura:

– slijed, tj. blok naredbi s jednim ulazom i izlazom– uvjetno grananje, npr. naredbe if, case/switch/select– ponavljanje, tj. programske petlje (s uvjetom na početku, s uvjetom na kraju, s unaprijed poznatim brojem koraka)

izbjegavanje bezuvjetnih skokova (GOTO naredbe)Proceduralno programiranje

način programiranja koji omogućuje da se program definira kao skup programskih cjelina, poželjno takvih da se mogu opetovano koristitiprogramska cjelina (unit)

skup programskih naredbi koje obavljaju jedan zadatak ili jedan dio zadatka, npr. glavni program, potprogrami (procedure, funkcije)

programski modul – skup logički povezanih programskih cjelina →modularno programiranjekomponenta – bilo koji sastavni dio softvera, uobičajeno podrazumijeva fizičke cjeline

OIIS -2013/14

Pristup programiranjuMonolitni pristup (build and fix)

dugotrajno kodiranje, a zatim niz ponavljanja oblika provjera+ispravakodgađa otkrivanje problema (pogrešaka u kodu i dizajnu)prosljeđuje probleme u primjenu i održavanje

Inkrementalni pristup (stupnjevito, postupno programiranje)niz ponavljanja oblika kodiranje+provjera+ispravakomogućuje raniju provjeru i izdvajanje pogrešaka (fault isolation)omogućuje raniju raspoloživost djelomičnih (nedovršenih) verzijaomogućuje ravnomjerniju podjelu poslaodozgo prema dolje, odozdo prema gore te mješovito


OIIS -2013/14

Provjera ispravnostiTestiranje programa, provjeravanje, ispitivanje programaprovjera programa izvođenjem, uz uporabu ispitnih podataka te analizom rezultata obradetestiranje i ispravljanje pogrešaka mora se obavljati redoslijedom kojim su moduli kodirani, uobičajeno s vrha prema doljecilj testiranja na pogreške je utvrđivanje pogrešaka odnosno nedostataka unutar programa

• uspješan test je onaj test koji dokaže postojanje pogreške

Načini provjerestrukturalno (white-box, clear box testing)

provjera kako cjelina radiprobni slučajevi izvode se uvidom u programski kôd (inspekcija koda)provode programeri

funkcionalno (black-box testing)provjera što cjelina radi, to jest da li zadovoljava zahtjeveprobni slučajevi izvode se iz specifikacija funkcijaprovodi osoblje proizvođača ili korisnici

Verifikacija - ovjera ispravnostidokazivanje da je faza dobro provedena ili da je proizvod dobro napravljen, tj. da odgovara specifikaciji zahtjevaValidacija - potvrda valjanostikojom se utvrđuje da je napravljen pravi proizvod, koji odgovara korisniku-namjeni


Vrste testiranjaTestiranje okrajaka (stub testing, unit testing)

testiranje upravljačkih struktura i vrijednosti sadržanih u koduispitivanje pojedinačnih cjelina (� Proceduralno programiranje)nedovršeni elementi mogu se simulirati (� odresci i pogonski moduli)

Testiranje komponenti (module testing)Ispitivanje pojedinih programskih komponentiprovodi razvojnik komponente (postoje iznimke za kritične sustave)testovi nastaju iz iskustva te osobe


OIIS -2013/14

Vrste testiranjaIntegracijska provjera (integration testing)

Ispitivanje grupa komponenti koje integrirane čine cijeli sustav ili neki njegov dioprovjere

test korisničkog sučelja – provjera svake funkcije sučeljatest slučajeva korištenja – provjera svakog pojedinačnog slučajatest toka podataka – provjera procesa korak-po-koraktest sučelja sustava – provjera prijenosa podataka između sustava

ispitivanje provodi nezavisni tim za testiranjetestovi su zasnovani na specifikaciji sustavadokumentacije – provjera korisničke dokumentacije i primjera


Vrste testiranjaProvjera sustava (system testing)

provjera rada sustava kao cjeline, kojom se osigurava da svi nezavisno razvijeni aplikacijski programi rade ispravno te sukladno specifikacijama provjere

Funkcionalno testiranje – provjera funkcionalnosti prema zahtjevimaTestiranje performanci – provjera nefunkcionalnih zahtjeva

– stress – verifikacija velikog broja simultanih pristupa– volume – test na količinu podataka, složenost algoritama, fragmentaciju– security – provjera prava pristupa– timing – brzina odziva– recovery – mogućnost oporavka pri “forsiranom” padu sustava

Testiranje dokumentacije – provjera korisničke dokumentacije i primjera


OIIS -2013/14

61

Izrada dokumentacijeProjektna dokumentacija

dokumentira razvoj i proizvode pojedinih fazaPrimjer, dokumentacija po IEEE standarduSoftware Validation and Verification Plan (SVVP)Software Quality Assurance Plan (SQAP)Software Configuration Management Plan (SCMP)Software Project Management Plan (SPMP)Software Requirements Specification (SRS)Software Design Document (SDD)Source codeSoftware Test Documentation (STD)User's manual Fertalj, Kalpić: http://www.zpm.fer.hr/courses/pis

OIIS -2013/14

Izrada dokumentacijeKorisnička dokumentacija

pomoć korisnicima pri uporabi sustavamora biti prilagođena korisnicima različitog iskustvaupute za uporabu (user manual)instalacijski priručnik (installations manual)detaljni priručnik (reference manual)upute za vježbu (training guide, tutorial)podsjetnici ili kratke upute (quick reference guide, pocket guide, cue cards)broj, vrsta i obujam dokumenata ovise o aplikaciji


OIIS -2013/14

Izrada dokumentacijeTehnička dokumentacija

namijenjena tehničkom osobljupotrebna za razumijevanje, izradu i održavanje sustavaupravljanje projektom i konfiguracijom sustava

plan razvojaspecifikacija dizajnaopis arhitekture sustavaspecifikacija sučelja prema drugim sustavima

programska dokumentacijaizvorni kôdopis baze podataka

probni podaci i rezultati provjerednevnik promjenaprogramski priručnici

instalacijski priručnikopis instalacijske procedure

upute za rukovanje i održavanje (operations manual)

opis procedura za pokretanje/zaustavljanje (startup/shutdown)opis izrade rezervnih kopija i vraćanja podataka (backup, restore)opis postupka ponovnog pokretanja i oporavka (restart, recovery)


OIIS -2013/14

Primjena i održavanje sustava

OIIS -2013/14

Napomena


OIIS -2013/14

Uvođenje u primjenuUvođenje uključuje instaliranje opreme, završni prijenos podataka te prelazak

na novi način rada.Aktivnosti i preduvjeti

Test sustava– vid Izrada\Testiranje

Izrada plana konverzije (migracije) za uspješan prijelaz– način uvođenja, poslovi, odgovornosti, resursi i redoslijed izvedbe– plan testa prihvatljivosti, ako nije obavljen ranije

Instalacija opreme, aplikacija i baze (baza) podataka novog sustava– inicijalni unos podataka– prijenos postojećih podataka uz konverziju– uspostava sustava zaštite i održavanja

Poduka tehničkog osoblja i krajnjih korisnika– verbalna poduka– raspodjela dokumentacije

Konverzija sustavaprelazak na novi način radaevaluacija projekta i sustava


OIIS -2013/14

62

Uvođenje u primjenuNačin uvođenja

Izravno uvođenje (direct installation, abrupt cutover)početak rada novog sustava uz istovremeni prestanak rada starog sustavaprovodi se na određeni dan, uobičajeno datum završetka poslovnog razdoblja, po mogućnosti na kraju tjednamogući problemi: pojava pogrešaka koje nisu bile uočene tijekom testiranja, nepredviđeno preopterećenje opreme u punom pogonunedostatak: neposredna izloženost korisnika pogreškama sustava

Paralelno uvođenje (parallel installation, parallel conversion)istovremeni rad starog i novog sustava tako dugo dok se ne pokaže da novi sustav ispravno radi i da su se korisnici navikli na novi način radabitno manje rizičan postupak u odnosu na izravno uvođenjenedostatak: potreba za dvostrukom obradom istih podataka, u starom i u novom novom sustavu → otpor korisnika


OIIS -2013/14

PodukaPoduka korisnikatehničko osobljekranji korisniciSadržaj podukePoduka krajnjih korisnika može uključivati:

opću informatičku kulturu (npr. uporaba osobnih računala)funkcije sustava i način uporabe sustava, to jest korištenje aplikacijapoduku iz posebnih znanja potrebnih za obavljanje osnovne djelatnosti (npr. operacijska istraživanja, projektiranje primjenom računala)

Poduka tehničkog osoblja može uključivati:operacijski sustav i uslužne programeadministriranje baze podatakaprogramske jezike i pomagala


OIIS -2013/14

PodukaRedoslijed poduke

prvo se obavlja poduka tehničkog osoblja koje će održavati sustav i pružati potporu krajnjim korisnicima, da bi se mogla pokrenuti primjenazatim bi trebalo obrazovati (niže) rukovodstvo, da bi se stekla njegova potpora pri poduci ostalih korisnika te tijekom primjeneslijedi školovanje (krajnjih) korisnika, koje treba prilagoditi funkcijama koje oni obavljaju u svakodnevnom radu

Postupci i tehnike poduketečajeviprobni rad fazi provjere rada sustavakvalitetni sustav interaktivne pomoćiprikladna dokumentacijapotpora tijekom primjene

Poduku mogu obaviti djelatnici naručitelja (npr. odjel informatike ili grupa za to odabranih i osposobljenih djelatnika) ili vanjski izvođači poduke. Fertalj, Kalpić: http://www.zpm.fer.hr/courses/pis

OIIS -2013/14

OdržavanjeOdržavanje je trajna aktivnost koja započinje odmah po

uvođenju u primjenu.Bez obzira kako dobro je sustav dizajniran, konstruiran i testiran pogreške će se neizbježno pojaviti!spravljanje pogrešaka u primjeni naziva se održavanjem sustava ili održavanjem programa.Održavanje samo po sebi ne podrazumijeva ugradnju poboljšanja ili novih mogućnosti, ali se ona uobičajeno provodi.Tijekom primjene i održavanja obavlja se analiza dodatnih zahtjeva, planiranje i priprema aktivnosti koje slijede te tako započinje novi ciklus razvoja.


OIIS -2013/14

Održavanje – vrste i ciljeviPreventivno

podrazumijeva zaštitu od mogućih problemaredovita izrada sigurnosnih kopija (backup)obavlja se periodički (dnevno, tjedno, mjesečno)

Korektivnopodrazumijeva popravak nakon što se problem pojaviovraćanje podataka iz sigurnosne kopije (restore)uklanjanje uzroka pogreške (ispravljanje programa)

Adaptivnoprilagodba funkcionalnosti (načina posluživanja)prilagodba strukture (promjene strukture podataka)poboljšanje performanci (optimizacija programa)

Perfektivnonadgradnja sustava da bi se riješili novi problemiugradnja novih mogućnosti (features)


OIIS -2013/14

Poboljšanje sustava i reinženjerstvoPoboljšanje sustava (system enhancement)

dorada i nadgradnja sustava prema novim zahtjevimaanaliza novih zahtjeva i povratak u odgovarajuću fazu (analiza, dizajn, izrada)većina novih zahtjeva uzrokovana je promjenama u poslovanju, potrebama za dodatnim informacijama ili novim idejama (željama korisnika)

Reinženjerstvo (reengineering)neke aplikacije teško je održavati (npr. uslijed zastarjelosti tehnologije), a trošak održavanja pojedinih aplikacija može doseći trošak izrade novihreinženjerstvo - adaptacija s ciljem smanjenja troškova održavanja

prilagodba većim promjenama tehnologijeispravak sustava prije nego što dođe do mogućeg prekida u raduispravak sustava koji će biti lakše popraviti ako dođe do prekida


OIIS -2013/14

63

Modaliteti izgradnjeVlastiti razvoj

VarijanteRazvoj vlastitim informatičkim snagama (in-house), koji može sadržavatiosposobljavanje i angažiranje netehničkog osobljaRazvoj unajmljenim osobljem povremeno ili dugoročno (buy-in, preferred supplier

Prednostifleksibilnost i kreativnostpovećanje stručnosti vlastitog osoblja

Nedostacizahtijeva značajno vrijeme i napor skuplje, dugotrajnijemože povećati gomilanje zaostalog poslarazvoj vlastitim snagama ima smisla kada se radi o programskoj podršci koja je posebnost organizacije, takva da ne postoje gotova rješenja na tržištu ili takva da organizacija s pomoću nje postiže komparativnu prednost u odnosu na konkurencijukada postoje dodatni ili posebni razlozi kao što su povećana tajnost podataka i poslovnih procesa ili povećana zaštita IS

OIIS -2013/14

Modaliteti izgradnjeVanjski razvoj (Outsourcing)

najam usluge razvoja informacijskog sustava ili njegovih dijelova

izobrazba djelatnika informatičke strukepomoć pri analizi i oblikovanju ili provedba analize i oblikovanjakodiranje (generiranje) cjelovitog programskog sustavaupravljanje provedbom i/ili nadzor provedbekonzultativna pomoć prilikom ugradnje složenih poslovnih funkcija

Varijante:Ugovoreni razvoj - ugovara se isporuka gotovog proizvoda (contract out)Dugoročna suradnja s isporučiteljem ili izdvajanje vlastitog informatičkog odjela upreferiranog izvođača (preferred contractor) – strateškog partnera (pr. Agencija)

PrednostiIS ili njegovi dijelovi izrađuju se po mjeri naručitelja

– sustav je prilagođen organizaciji/poslovanju– po mogućnosti treba istovremeno poboljšati organizaciju/poslovanje

razvoj podrazumijeva dugotrajan postupak i sukladno visoku cijenu

Nedostaci i rizicigubitak povjerljivih informacijagubitak nadzora nad sadašnjim i/ili budućim razvojem (zavisnost o dobavljaču)gubitak vlastite stručnosti

Nužno je da upravljanje projektom informatizacije na sebe preuzme vlastito kompetentno osoblje koje ima mogućnost odlučivanja


OIIS -2013/14

Modaliteti izgradnjeNabava gotovih programskih

proizvodaCOTS = Commercial-Of-The-Shelf software

u pravilu ne ispunjavanju poslovne potrebe u potpunostipoželjno je da se mogu prilagoditi potrebama

Aplikacijski paketiprogramski paketi za uredsko poslovanje (office automation),

npr. Microsoft Officeprogrami za upravljanje dokumentima (document management),

npr. Lotus Dominospecijalističke aplikacije za određene namjene

Sustavi za upravljanje poslovanjemEnterprise Resource Planning (ERP) systems

npr. SAP, BAAN, J.D. Edvards, Peoplesoft

cjeloviti sustavi za potporu poslovanju

financijsko poslovanje (accounting),proizvodnja (manufacturing),robno-materijalno poslovanje (material management/distribution),upravljanje ljudskim resursima i plaće (HR management, payroll).

OIIS -2013/14

Modaliteti izgradnjeNabava poslovnih sustavaNabavka i prilagodba postojećih domaćih poslovnih sustava/aplikacijaprednosti:

usklađenost našim uvjetima, npr. zakonimazahtijeva prvenstveno prilagodbu organizaciji/poslovanju

nedostatcinepostojanje ili manjkavost pojedinih komponenti, mjestimična tehnološka zastarjelostprekapacitiranost dobavljača

modaliteti:otkup izvornog koda i samostalna doradakompletni outsourcing uz samostalno održavanje

Nabavka “gotovih” stranih poslovnih sustavaprednosti

raskošna funkcionalnostkompatibilnost sa svjetskim poslovnim standardimanedostatcineprilagođenost domaćim uvjetima i konkretnoj organizaciji/poslovanju -zahtijeva

istovremenu prilagodbu programske opreme i promjenu organizacije/poslovanja

prilagodba se obavlja slično razvoju -rješenja gube moguću komparativnu prednost (brzinu ilakoću primjene)(glomazni) paketi mogu zahtijevati angažman velikog broja konzultanata -vrlo visoka cijena izrade

modalitetiprilagodba vlastitim snagama uz savjetništvo i pomoć dobavljača

OIIS -2013/14

Kriteriji za donošenje odluke o nabavi

Opći kriteriji za donošenje odlukecijenafunkcionalnost, kapacitet, brzina, broj korisnikamogućnost poduke i trajne potporekredibilitet i održivost dobavljača na tržištu (referencama)elastičnost, tj. mogućnost prilagodbe i prepravkiraspoloživost dokumentacije

Dodatni kriterijiOtvorenost sustava (Portabilnost, interoperabilnost)

Tehničke mogućnosti (Client-Server, OLTP, OLAP, ...)tehničke konzultacije,održavanje (dinamika razvoja i mogućnosti nabavke novih verzija),promptno otklanjanje problema,ponuda gotovih aplikacija,pomoć u razvoju vlastitih aplikacija(Veliki broj kriterija moguće je pronaći nan npr. http://www.technologyevaluation.com)

OIIS -2013/14

Documents

Napomena Predmet Sustav za ocjenjivanje Kriteriji za ocjenjivanje