FER PIS Predavanja

SVEUILITE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAUNARSTVA Zavod za primijenjeno raunarstvo
Predmet
Nastavno optereenje
2 sata predavanja + 2 sata laboratorijskih vjebi tjedno
Predavanja
Pohaanje predavanja nije uvjet za dobivanje potpisa
Laboratorijske vjebe Prof.dr.sc. Kreimir Fertalj Prof.dr.sc. Damir Kalpi

Projektiranje mogueg informacijskog sustava za izmiljenog korisnika. Rezultat je projektna dokumentacija, koja se predaje na pismenom ispitu.
Ispit
Usmenom ispitu mogu pristupiti studenti koji prikupe najmanje polovicu bodova za svaku od aktivnosti koje mu prethode. Pozitivna ocjena pristupa usmenom ispitu rauna po sustavu bodovanja
Aktivnost Pohaanje predavanja Projektna dokumentacija Pismeni ispit - zadaci Pojedinano 2 20 10 Puta 15 6 5 Ukupno Nedovoljan Korak 2-5 Bodova 30 120 50 200 100 25 Udjel 15.00% 60.00% 25.00% 100.00% 50.00% 12.50%
2
Projektiranje informacijskih sustava
Ukupna ocjena = f(modifikator)

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.
Materijali, informacije
Materijali
http://www.zpm.fer.hr/courses/pis aurirat e se nakon predavanja Vlastite biljeke
Sadraj
Sadraj
Informacijski sustav. Projektiranje i izgradnja informacijskih sustava. ivotni ciklus i faze razvoja. Strategija i planiranje sustava. Prikupljanje i odreivanje zahtjeva. Analiza. Oblikovanje funkcija. Oblikovanje procesa. Konceptualno oblikovanje podataka. Modeliranje dogaaja. Procjena alternativa izgradnje. Oblikovanje. Dizajn arhitekture sustava. Dizajn i ugaanje baze podataka. Oblikovanje programa i suelja. Izrada sustava. Uvoenje u primjenu. Odravanje. Poduka i potpora. Modeli razvoja i metodologije. Moderni postupci. Organizacija projekta i upravljanje projektom. Programski alati i razvojna okruenja. CASE.
Literatura
J. A. Hoffer, J. F. George, J. S. Valacich: Modern Systems Analysis and Design, 3/e, Prentice Hall College Div, 2001 J. L. Whitten, L. D. Bentley, K. C. Dittman: Systems Analysis & Design Methods, 5/e, McGraw-Hill Higher Education, 2000 L. Maciaszek: Requirements Analysis and System Design: Developing Information Systems with UML, 1/e, Addison Wesley Higher Education, 2002
Konzultacije
Doc.dr.sc. Kreimir Fertalj, Prof.dr.sc Damir Kalpi ZPM raunarci, zgrada D/III kat, sjeverozapadno krilo poeljno uz najavu elektronikom potom obvezno s vlastitim biljekama
E-mail
To: kresimir.fertalj@fer.hr, damir.kalpic@fer.hr Subject: PIS
FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07. 3
Podatak, informacija i znanje

Informacija openito
obavijest, podatak o neemu, predana novost ili znanje formalno, kolekcija simbola koji mogu imati odreeno znaenje
Podatak, informacija i znanje
Informacijski sustav
podatak je sirova injenica koja predstavlja neku istinu iz stvarnog svijeta pojedinani podaci sami za sebe znae malo ili nemaju neko znaenje informacija je interpretacija podatka - proien, organiziran i obraen podatak u smislenom kontekstu informacija je subjektivnog znaenja, u kontekstu primatelja znanje se gradi na temelju novih informacija koje se nadovezuju na postojee znanje isti podaci mogu biti razliito interpretirani od strane razliitih ljudi u ovisnosti o njihovom znanju -130000 ??? primjer: -130000 HRK ? na raunu ! broj 1313 (tj. Mojem) !!!
Informacijska znanost, obavijesna znanost informatika (informatics, information theory).

Sustav
Sustav openito - sistem, poredak
oblik drutvene organizacije (npr. dravni) skup dijelova, povezanih opom funkcijom (npr. ivani) skup jedinica, organizacijski ujedinjenih u cjelinu (npr. poduzee) oblik, nain ustrojstva, organizacija neega (npr. izborni) uvjetovan planskim, pravilnim rasporedom dijelova (npr. sistem rada) Podsustavi:
Elementi i znaajke sustava

Karakteristike
organizacija struktura i poredak, hijerarhijske veze koje odreuju formalnu komunikaciju i upravljaki lanac (pr. vojska, poduzee) interakcija nain na koji pojedine komponente surauju s drugim komponentama (pr. Nabava s Proizvodnjom, Proizvodnja s Prodajom) meuzavisnost jedan podsustav ovisi o drugom (ulaz), da bi mogao funkcionirati integriranost mjera povezanosti komponenti komponente koje pripadaju sustavu
Granica:
definira opseg i domaaj sustava
Okolina:
sve to je izvan granica sustava, ali se jo uvijek tie sustava
Sustav je ureeni poredak meuzavisnih komponenti povezanih prema zajednikom planu za postizanje odreenog cilja.
Komponente sustava jesu njegovi fiziki dijelovi, ulazi i izlazi te procesi njihove pretvorbe i upravljaki postupci (planiranje, organizacija, upravljanje i nadzor).
Ulazi:
elementi koji ulaze u sustav iz okoline
Izlazi:
elementi koji naputaju sustav
Suelja:
veze izmeu sustava i njegove okoline (zatita, filtri)
Ogranienja:
unutarnji i vanjski imbenici koji odreuju i ograniavaju funkcioniranje sustava
Izlaz Ulaz Podsustav Suelje Izlaz Granica sustava Okolina

8
Informacijski sustav (Information System)
obavijesni sustav, informacijski sistem sustav za upravljanje informacijama vanim za organizaciju i drutvo sustav za upravljanje sustavom ljudskih aktivnosti [Checkland, 1980]
Informacijski sustav podran raunalom

Tipovi (slojevi) informacijskih sustava
neformalni sloeni oblici ponaanja koji nisu formulirani, ali se od pridolica u sustavu oekuje da ih usvoje formalni eksplicitno utvrena pravila ponaanja, a mogu biti propisana internim pravilima i zakonskom regulativom tehniki opisuje organizaciju u terminima protoka poruka o aktivnostima i obradi podataka potrebnoj da se obavi posao
N EF OR MALN I I S F ORMALNI I S
Pojam IS podrazumijeva:
sustave podrane raunalom raunalni (kompjuterizirani, kompjuterski) sustave koji se ne oslanjaju na raunala, ali obrauju informacije
Svrha
prikupljanje i pruanje informacija korisnicima u jednoj ili vie organizacija organizacijski IS (poslovni IS)
TEHN I KI (RA U NALOM POD R AN I) IS
Informacijski sustav podran raunalom

Ureenje ljudi, podataka, procesa, suelja, poveznica (mrea) i tehnologije koji djeluju meusobno sa svrhom podrke i poboljanja svakodnevnih poslovnih aktivnosti (obrada podataka), kao i podrke rjeavanju problema i donoenju odluka (informacijski servisi). [Whitten et. al, 2000] Komponente IS programska oprema (software) sistemska, namjenska raunalna oprema (hardware) raunala i periferije, mrena oprema osobe (lifeware) - korisnici, informatiari organizacija (orgware) postupci povezivanja pojedinih dijelova u cjelinu
9 FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07. 10
Korisnici
poslovodstvo, djelatnici (zaposlenici, osoblje), klijenti
Upravljanje informacijama - Obavlja se bez obzira na vrstu sustava!

prikupljanje (acquisition) zapisivanje, pamenje (recording) obrada (processing) spremanje i pronalaenje (information storage and retrieval) prikaz u odgovarajuem obliku
Poslovni i informacijski sustav

Poslovni sustav
materijalni ulazi i izlazi (sirovine, energija, proizvodi) i informacijski tokovi (poruke, dokumenti, ) Ulaz u neki PS predstavlja izlaz iz nekog drugog PS procesi: obrada, prerada, proizvodnja Povratne veze - usporedba plana i realizacije skladita: spremita informacija (podataka) izvritelji: osobe, strojevi, alati skladita: spremita materijala
Vrste informacijskih sustava

Transaction Processing System (TPS), sinonim Data Processing System evidencija i obrada podataka o poslovnim transakcijama Management Information System (MIS) - upravljaki upravljanje temeljem dokazanih matematikih/statistikih metoda Decision Support System (DSS) odluivanje na temelju nestrukturiranih podataka iz razliitih izvora Executive Information System (EIS) podvarijanta za izvrne rukovoditelje Expert System (ES) sustav s ugraenim znanjem i simulacijom zakljuivanja OAS: Office Automation System GSS: Group Support System, Groupware
Primjeri
I(P)S: nabave, prodaje, proizvodnje, financija, ljudskih resursa i plaa, osnovnih sredstava IS Subvencionirane Prehrane (ISSP) IS Visokih Uilita (ISVU) IS Personalnog Upravljanja MORH
podsustav poslovnog sustava ulazi i izlazi: ulazne informacije, obraene informacije procesi: obrada informacija (podataka) o stanjima stvarnog sustava izvritelji: osobe, programi, raunala
Upravljanje i razine IS
Informacijski sustav transakcijski upravljaki za potporu odluivanju
Informacije, kada obrada podataka, dnevno zbirne, periodiki sintetizirane, ad hoc
11
Korisnici, Upravljanje tko nie operativno poslovodstvo srednje taktiko poslovodstvo (trendovi) vie strategijsko poslovodstvo, (to ako,) uprava
12
Znaajke informacijskih sustava

Znaajke informacijskih sustava
sloena okolina, koju je teko u potpunosti definirati sloeno suelje prema okolini, koje ukljuuje razliite ulaze i izlaze sloene veze izmeu ulaza i izlaza (strukturno, algoritmiki) obujam i sloenost podataka
Problem projektiranja, izrade i odravanja Vanost IS

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

Ciljevi razvoja IS
izgraditi sustav koji radi i koji je pouzdan, unutar zadanih granica izgraditi sustav koji zadovoljava poslovne ciljeve, prema zahtjevima korisnika izgraditi sustav u prihvatljivom vremenu i po opravdanoj cijeni
Neki primjeri neuspjenih projekata/sustava

London Ambulance System (1992)
Nakon uvoenja sustav se 2 puta "raspao" radi niza pogreaka, naroito onih zbog upravljanja. Neposredni troak bio je relativno nizak (9m), ali se vjeruje da su neki ljudi umrli jer se do njih nije stiglo na vrijeme.
The CHAOS Report [Standish Group, 1994], http://www.standishgroup.com

Prosjeni troak projekta velike kompanije: 2,32 M$ srednje kompanije 1.33 M$ male kompanije: 434 K$ Prosjeno prekoraenje trokova 189% Prosjeno prekoraenje rokova 222% Projekti zavreni na vrijeme, u okviru predvienih sredstava, sa svim predvienim funkcijama - 16.2% Projekti zavreni i u funkciji, ali uz vee trokove, dulje trajanje i/ili reduciranu funkcionalnost - 52.7% Prekinuti projekti - 31.1%
Taurus (1993)
Projekt sustava automatiziranih transakcija Londonske burze prekinut je nakon 5 godina razvoja i troka od 75m te posljedini gubitak klijenata od 450m. Ukupni gubici smatra se da su neizraunljivi.
Neki problemi
prekoraenje planiranog vremena i financijskih sredstava neispunjenje zahtjeva neodgovarajui sustav nepouzdanost, nesigurnost, neelastinost u primjeni tekoe u odravanju
Denver Airport (1994)

Nepouzdanost softvera za upravljanje prtljagom uzrokovala je odgodu otvaranja zrane luke u trajanju od 16 mjeseci uz trokove od 1.1 M$/dan.
Ariane 5 (1996)
Eksplodirala u lanseru radi niza softverskih pogreaka
Drugi primjeri
Challenger - niz pogreaka u dizajnu Teleskop Hubble - pogreke u dizajnu, propusti u testiranju Mars Climate Orbiter - problem navigacije zbog raskoraka izmeu engleskog i metrikog mjernog sustava
70% sustava u svijetu smatra se neuspjenim (system failure)

Standish Group, 2002:

34% uspjenih projekata 17% potpunih neuspjeha
15
Uzroci neuspjeha
Razlozi neuspjenih projekata
sloenost aplikacija nedostatak usmjerenosti korisniku zanemarivanje okruenja organizacije pretjerani optimizam izostanak praenja napretka nedostatak komunikacije izmeu korisnika i izvoaa
Poboljanje uspjenosti IS
Poboljanje uspjenosti IS
Projektiranje IS Planiranje, upravljanje provedbom, praenje napretka Ukljuivanje korisnika Korisnik poznaje(?) poslovni proces i zna(?) odrediti potrebe. Informatiar upoznaje(?) poslovanje i zna(?) kako izraditi IS. Vano je da u procesu izgradnje sudjeluje i poslovodstvo, da bi se upoznalo sa stvarnim mogunostima i koristima uvoenja IS, posebice jer donosi konane (za poduzee sudbonosne) odluke.
U Hrvatskoj se uzroci neuspjeha uglavnom ne istrauju, a informacije o neuspjenim projektima nerado se objavljuju. Meu najeim uzrocima su [Kalpi, Fertalj & Mornar, 2001]
Loa organizacija i voenje projekata oslonac na vanjske voditelje i savjetnike, delegirano upravljanje projektima, nerealno planiranje, formalno izvjetavanje o napretku, formalni nadzor nad projektom, podcijenjena uloga vlastitih strunjaka Loa izvedba projekata neodgovarajua analiza sustava, pogreke u dizajnu i kontroli kvalitete, neodgovarajua CASE pomagala i krivo koritenje, pa ak i svojevrsna zloporaba CASE pomagala
Saetak naela razvoja informacijskih sustava

Korisnici i vlasnici sustava moraju biti aktivno ukljueni Treba koristiti pristup koji vodi k rjeavanju problema Uspostaviti faze i aktivnosti Uspostaviti standarde za konzistentan razvoj i dokumentiranje Opravdati izgradnju sustava kao kapitalnu investiciju Ne oklijevati ako treba projekt otkazati
Mnogi sustavi su propali ili su bili odbaeni jer su se izvoai trudili napraviti lijepa programska rjeenja a nisu razumjeli sutinu organizacije i poslovanja.
Programsko inenjerstvo
Programska oprema (software)
programska podrka, naputbina dio raunalnog sustava koji nema fizikalnih dimenzija opi pojam za sve vrste programa, programskih jezika itd raunalni programi, podaci, dokumentacija svojstva: sloenost, podlonost pogrekama, ne troi se, teko se mjeri, stari, dugo se koristi, lako se kopira (zajedno s pogrekama)
Inenjerski pristup izgradnji IS
Raunalna aplikacija (application)

namjenski program, primjenska programska oprema raunalom podrano rjeenje jednog ili vie poslovnih problema ili potreba informacijski sustav uobiajeno sadri jednu ili vie raunalnih aplikacija
Informacijska tehnologija (information technology, IT)

bilo koji oblik tehnologije, tj. oprema ili tehnika koju ljudi koriste za upravljanje informacijama (obavijestima) u dananje vrijeme obuhvaa raunalsku tehnologiju (hardver i softver) i telekomunikacijsku tehnologiju (mree za prijenos podataka, slika i zvuka)
Programsko inenjerstvo
Programsko inenjerstvo (software engineering)
Software Engineering: (1) The application of a systematic, disciplines, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1). [IEEE Std 610.12-1990, 1994] IEEE Std 610.12-1990 "Standard Glossary of Software Engineering Terminology" in IEEE Software Engineering Standards Collection, 1994 Edition, IEEE, New York, 1994, p. 67.
IEEE = Institute of Electrical and Electronic Engineers, http://www.ieee.org
U potrazi za srebrnim metkom

Postupci (metode) programskog inenjerstva
1968: Prva NATO konferencija o programskom inenjerstvu, posveena problemima razvoja programske podrke (softverske krize) kraj '60-ih, rane 70-te: Strukturirano programiranje - disciplinirano programiranje temeljeno na prikladnoj sintaksi proceduralnih jezika sredinom 70-ih: Strukturirani dizajn - izrada hijerarhijskih sustava modularne programske opreme, raunalom podrana dokumentacija kasne 70-te, rane '80-te: Strukturirana analiza - odvajanje logikog opisa od fizikog opisa (informacijskog) sustava, Oblikovanje podataka rane '80-te: CASE alati; prototipiranje sredinom '80-te: Informacijsko inenjerstvo, zdrueni razvoj aplikacija (Joint Application Development) kasne '80-te: Brzi razvoj aplikacija (Rapid Application Development) rane 90-te: Objektno usmjereni razvoj kasne 90-te ...: ?
Programsko inenjerstvo je inenjerska disciplina koja obuhvaa sve aspekte izrade programske opreme. [Sommerville, 2000] Programsko inenjerstvo je inenjerska disciplina koja se bavi praktinim problemima razvoja velikih programskih sustava [Sommerville 1992, 4. ur., str. v] Programsko inenjerstvo... ima za cilj ekonomian razvoj visokokvalitetne programske opreme [Pagel / Six 1994, str. 49]
Podruje programskog inenjerstva

poslovi kojima se oblikuje i razvija programska oprema sustavna primjena prikladnih alata i tehnika na itav proces razvoja programske opreme sastoji se od analiziranja i poblieg opisivanja (specifikacije) postupka koji treba programirati, izrade programa, tehnika testiranja (provjere valjanosti), pisanja dokumentacije, pokusnih izvedbi programa, analize vremenskog izvoenja itd.
Brooks, F.P. (1987) No silver bullet: essence and accidents of software engineering. Computer, 20 (4), 10-19.
tekoe su sastavni dio softvera (sloenost, promjenjivost, nevidljivost...) neprilike/nezgode postoje, ali nisu sastavni dio, tj. nisu neizbjene
Software Engineering Body of Knowledge

SWEBOK: Software Engineering Body of Knowledge
IEEE Computer Society, 2001 http://www.swebok.org/ Computing Fundamentals
1.1 Algorithms and Data Structures 1.2 Computer Architecture 1.3 Mathematical Foundations 1.4 Operating Systems 1.5 Programming Languages
Informacijsko inenjerstvo
Informacijsko inenjerstvo (information engineering, IE)
Inenjerski pristup izgradnji IS i upravljanju informacijama IS mora biti projektiran, kao to se to ini s drugim proizvodima razvoj IS kao strukturiran i planiran proces podran raunalom Sustavna primjena prikladnog skupa metoda, tehnika i alata u procesu razvoja informacijskih sustava.
A Software Engineering Body of Knowledge, CMU/SEI-99-TR-004

Carnegie Mellon University/Software Engineering Institute http://www.sei.cmu.edu/seihome.html
Software Product Engineering

2.1 Software Requirements Engineering 2.2 Software Design 2.3 Software Coding 2.4 Software Testing 2.5 Software Operation and Maintenance
Metoda (method)
Smiljen i organiziran skup procedura izrade (modela, softvera), uz koritenje dobro definirane notacije sugerira proces obavljanja i nain biljeenja definira primjenu tehnika i njihovo povezivanje (pr. ERD-DFD)
Software Management
3.1 Software Project Management 3.2 Software Risk Management 3.3 Software Quality Management 3.4 Software Configuration Management 3.5 Software Process Management 3.6 Software Acquisition
Tehnika (technique)
Feature metode, koji definira nain provoenja odreenog postupka i dokumentiranja rezultata tog postupka Nain na koji se provodi odreena aktivnost razvojnog procesa.
Pomagalo (tool)
instrument, sredstvo (artefact) koje se koristi u razvoju IS
Body of Information Systems Knowledge

IS 2002 - Model Curriculum and Guidelines for Undergraduate Degree Programs in Information Systems
Association for Computing Machinery (ACM) Association for Information Systems (AIS) Association of Information Technology Professionals (AITP) Body of IS Knowledge http://www.aisnet.org/Curriculum/ 1.0 Information Technology 1.1 Computer Architectures 1.2 Algorithms and Data Structures 1.3 Programming Languages 1.4 Operating Systems 1.5 Telecommunications 1.6 Database 1.7 Artificial Intelligence 2.0 Organizational and Management Concepts 2.1 General Organization Theory 2.2 Information Systems Management 2.3 Decision Theory 2.4 Organizational Behavior 2.7 Managing the Process of Change 2.8 Legal and Ethical Aspects of IS 2.9 Professionalism 2.10 Interpersonal Skills 3.0 Theory and Development of Systems 3.1 Systems and Information Concepts 3.2 Approaches to Systems Development 3.3 Systems Development Concepts and Methodologies 3.4 Systems Development Tools and Techniques 3.5 Application Planning 3.6 Risk Management 3.7 Project Management 3.8 Information and Business Analysis 3.9 Information Systems Design 3.10 Systems Implementation and Testing Strategies 3.11 Systems Operation and Maintenance 3.12 Systems Development for Specific Types of Information Systems
25
Sistemsko inenjerstvo
Nema opeprihvaene definicije. Neke od objavljenih
The application of scientific and engineering efforts to (a) transform an operational need into a description of system performance parameters and a system configuration through the use of an iterative process of definition, synthesis, analysis, design, test, and evaluation; (b) integrate related technical parameters and ensure compatibility of all physical, functional, and program interfaces in a manner that optimizes the total system definition and design; and (c) integrate reliability, maintainability, safety, survivability, human engineering, and other such factors into the total engineering effort to meet cost, schedule, supportability, and technical performance objectives. An interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and life-cycle balanced set of system, people, product, and process solutions that satisfy customer needs. Integrated approach to synthesis of entire systems designed to perform tasks in what is expected to be most efficient possible manner, with each component of system designed to function as part of a single entity
Saeto
Sagledava sustav kao cjelinu pristupom s vrha prema dolje (top-down) Upravlja ciklusom koji sadrava sve faze od dizajna do umirovljenja Osigurava djelotvornost i (dovoljno) rano donoenje odluka definiranjem zahtjeva i njihovim povezivanjem s odgovarajuim oblikovanjem Interdisciplinarni i/ili timski pristup oblikovanju i razvoju kojim se osigurava njihova djelotvornost i uinkovitost
Projektiranje IS
Slijed izrade fizikog i logikog modela postojeeg IS, a zatim logikog i fizikog modela budueg IS na temelju poslovnih zahtjeva i zahtjeva krajnjih korisnika.
Projektiranje informacijskih sustava
fiziki model (ugradbeni, implementacijski, tehniki) opisuje kako je sustav fiziki i tehniki ugraen, te tko, gdje i kada neto radi logiki model (esencijalni, konceptualni, poslovni) to je sustav, to radi, to su podaci operativni (budui fiziki) sustav to, tko i kada, ali ne i gdje opcionalno, moe se razmatrati organizacijska razina razliito znaenje podataka zavisno od podruja unutar organizacije i okolia
28
Modeliranje
Izrada modela koji odgovaraju dijelovima stvarnog sustava
model: apstrakcija ili reprezentacija dijela stvarnog svijeta Kada otprije ne postoji sustav, potrebno je odrediti "surogat" postojeeg sustava po ugledu na istovrsne sustave u drugim organizacijama ili razvoj zapoeti s izradom logikog modela.
Vrste modela
Izrada modela podataka / oblikovanje podataka (data modelling)
model podataka TO su podaci, odnosno to opisuju podaci konceptualni model - opisuje podatke i veze izmeu podataka, najee model entiteti-veze (entity-relationship model) logiki model opisuje strukturu podataka i logikih datoteka, najee relacijski model podataka (relational data model)
Tehnike oblikovanja dijagramima

Izradom modela nastoji se opisati situacija u kojoj: dogaaj iz vanjskog svijeta pokree (okida) proces proces ima odreeni uinak na podatke u nekom stanju obavljanjem procesa podaci prelaze u novo stanje.
Izrada modela procesa/funkcija (process modelling, functional decomposition)

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

model dogaaja KADA se podaci obrauju razmatranje uinka koji dogaaji imaju na procese i podatke te opis stanja, npr. dijagram promjene stanja (state transition diagram)
Modeliranje resursa/sredstava
izvritelji - TKO obrauje podatke, GDJE se nalaze podaci, GDJE se obrauju podaci
Modeliranje programa
struktura (programskih) modula IS, primjerice strukturnim kartama
29
30
Kljune aktivnosti i sudionici

Kljune aktivnosti # u nekim metodama zajedno se zovu informacijsko inenjerstvo
Sistemska analiza, Analiza sustava (Systems analysis) prouavanje poslovanja s ciljem preporuke poboljanja i specificiranja zahtjeva na rjeenje Sistemski dizajn, Dizajn sustava (Systems design) specifikacija ili konstrukcija raunalom podranog rjeenja identificiranih poslovnih zahtjeva
Sistem analitiar
Sistem analitiari razumiju i poslovanje i raunarstvo
Provode sistemsku analizu i dizajn Povezuju one koji trebaju raunalo i one koji poznaju IT
Sudionici, uvari uloga (stakeholders)

Korisnik, Korisnik usluga, Klijent (User, Customer, Client) osoba ili grupa za koju se gradi IS Korisnik sustava krajnji korisnik
neposredno koristi IS pri obavljanju svakodnevnih poslova ili koristi informaciju dobivenu iz IS
Formalna definicija [Whitten et. al, 2000]

Sistem analitiar potpomae prouavanje problema i potreba poslovanja radi odreivanja kako poslovni sustav i informacijska tehnologija mogu najbolje rijeiti problem i postii unaprjeenje poslovanja. Plodovi ove aktivnosti mogu biti poboljani poslovni procesi, poboljani informacijski sustavi te nove ili poboljane aplikacije, a esto sve zajedno.
Vlasnik sustava naruitelj (ovisno o vlasnitvu: stvarni vlasnik ili predsjednik uprave)
naruuje i plaa razvoj i odravanje sustava, postavlja prioritete i odreuje politiku njegovog koritenja
Projektant, Dizajner sustava (Designer) tehniki strunjak koji oblikuje sustav tako da zadovolji zahtjeve korisnika
prevodi poslovne zahtjeve i ogranienja u tehniko rjeenje oblikuje datoteke, baze podataka, ulaze, izlaze, zaslone, mreu i programe, integrira rjeenje
Uloga sistem analitiara

Istraitelj, arhitekt i nadzornik Rjeavatelj poslovnih problema Zagovaratelj promjena Psiholog, trgovac, politiar ...
moe biti i graditelj sustava Graditelj sustava (Builder, Developer) - programer, razvojnik strunjak koji izgrauje sustav, provjerava njegovu ispravnost te ga isporuuje u primjenu
konstruira komponente sustava na temelju specifikacija koje rade dizajneri sustava
Veina sistem analitiara koristi neku inaicu pristupa koji se naziva ivotni ciklus razvoja sustava sistematian i metodian pristup rjeavanju problema sustava.
FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07. 31 FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07. 32
ivotni ciklus razvoja

ivotni ciklus
naziva se ovisno o kontekstu systems development life-cycle software development life-cycle application development life-cycle konzistentan i standardizirani nain razvoja IS
ivotni ciklus razvoja sustava

Systems Development Life-Cycle (SDLC)
Svrha: planiranje, izvrenje i nadzor razvojnog projekta

ivotni ciklus definira faze i zadatke (aktivnosti) koje nuno treba obaviti tijekom razvoja bez obzira na veliinu sustava koji se gradi svaka pojedina aktivnost proizvodi skup rezultata ciklus sigurava kontrolne toke za praenje napretka, procjenu postignutih rezultata i donoenje odluka o daljnjim koracima projekt prolazi kroz faze ivotnog ciklusa Primjer: ivotni ciklus razvoja softvera Requirements Analysis & Specification Conceptual/System Design Detailed/Program Design Implementation/Coding Unit & Integration Testing System Testing System Delivery
ivotni ciklus i faze razvoja IS

Plan sustava Planiranje Potrebe (popravci, dorade, prerade, nadogradnje) Analiza
Faze razvoja
Planiranje, strategija
Snimka stanja, Inicijalna strategija (initial strategy): odreivanje poslovnih ciljeva, identificiranje problema i ideja njihovog rjeavanja te odreivanje zahtjeva za sustav Studija izvodljivosti (feasibility study): pregledna analiza problemskog podruja i odreivanje (granica) projekata Planiranje projekta: Izrada plana rada, kadroviranje projekta, upravljanje i nadzor projekta Poslovni cilj i projekti, plan sustava, plan informatizacije (glavni projekt)
Planiranje (zato)
Zato graditi sustav?
Analiza (tko, to, kada, gdje)

Tko koristi sustav? to mora raditi? Gdje i kada e se sustav koristiti?
Pregled
Specifikacija zahtjeva
sistemsko inenjerstvo
Oblikovanje (kako)
Kako e sustav raditi?
Operabilni sustav
Analiza zahtjeva, specifikacija zahtjeva

Analiza zahtjeva (requirements analysis): detaljna analiza kojom se preciziraju granice projekta i poslovni zahtjevi detaljna analiza postojeeg sustava (problema i poslovnih zahtjeva) modeliranje (postojeeg) sustava Specifikacija zahtjeva (requirements specification): detaljni opis zahtjeva na IS, oblikovan tako da ga razumiju dizajneri modeliranje (budueg) sustava definiranje zahtjeva na budui IS Poslovni model sustava, prijedlog sustava
Izrada (+isporuka)
Oblikovanje
ugradnja rjeenja
Primjena
odravanje i poboljavanje
Specifikacija sustava Izrada
Primjena, odravanje
Funkcionalni sustav
Faze razvoja
Oblikovanje
Dizajn sustava (system design): modeliranje IS (pogled projektanta) donoenje odluke o tome kako graditi sustav dizajn rjeenja po potrebi (ima rjeenja koja ne treba dizajnirati) izrada zahtjeva kojima se opisuje kako izgraditi sustav Detaljni dizajn (detailed design): razrada rjeenja, izrada tehnolokog modela IS (pogled izvoaa) dizajn arhitekture, suelja, pohrane podataka i programa Tehnika specifikacija sustava
Faze razvoja
Uvoenje i odravanje
analiza ugraenog rjeenja, poboljanje dizajna, ugradnja poboljanja Uvoenje u primjenu, primjena (operation, production): prijelaz radnih aktivnosti i prijenos (konverzija) podataka sa starog na novi sustav Odravanje (maintenance): izmjene sustava radi poboljanja radnih karakteristika (performanci), poboljanja ili prilagodbe naina uporabe Potpora (support): dobavljaa opreme, tehnikog osoblja korisnicima Informacijski sustav u primjeni, plan odravanja
Izrada, provedba
ugradnja oblikovanih rjeenja Izrada (implementation), konstrukcija: ugradnja baze podataka, kodiranje procesa (funkcija) novog IS, nakon odabira platforme Testiranje (testing): provjera komponenti Integracija i provjera sustava (system integration, evaluation): udruivanje dijelova i provjera cjeline, da bi se dokazalo da sustav radi (da je ispravno napravljen) te da radi ono to je zahtijevano (da je napravljen pravi sustav, koji ispunjava zahtjeve) Funkcionalni sustav i tehnoloki opis sustava
Novi razvojni ciklus

Pregled (review): revizija, preispitivanje itavog sustava kada su potrebne vee izmjene uslijed promjena u poslovanju ili promjena poslovnih ciljeva Novi projekti
Navedene su tipine faze ivotnog ciklusa, bez implikacije da se radi o diskretnim i/ili slijednim aktivnostima!
Primjer: IS LC Stages and Deliverables, DOE Software Development Methodology, http://cio.doe.gov/sqse
Primjer: Ciklus razvoja softvera

Vienje studen(a)ta
Zaprimanje zadatka (dan 1n)
Prouavanje problema (dan 1)
Kodiranje (dani 1 ... n - 2)
Isporuka (dan n)
Debugiranje (dan n - 1)
Dokumentiranje (dan n - )
Prilagodba prema Modesitt, LNCS 750, pp. 42
39
40
Strateko planiranje
Strateko planiranje
Definiranje poslovne strategije, planiranje akcija za postizanje cilja Uprava definira viziju i misiju organizacije, tj. strateke ciljeve.
http://www.fer.hr (Sustainable excellence - in education and research) http://www.zaba.hr (O nama) http://www.lura.hr (O nama)
Strategija i planiranje
Na temelju toga definiraju se poslovni ciljevi i odreeniji zadaci kojima e organizacija u nekom razdoblju ispuniti svoju misiju. to se eli postii: prepoznatljivost, kvaliteta, prihodi, ... kako to postii: promjenom organizacije, poboljanjem sustava administracije, ...
poveanje proizvodnosti ulaganjem u nove proizvodne tehnologije uz istovremeno odravanje kakvoe proizvoda osiguranje zadovoljstva i radnih sposobnosti zaposlenika dokolovanjem i mogunostima napredovanja
imbenici koji utjeu na postavljanje ciljeva

ogranienja (organizacijska, financijska, zakonska, ) potrebe i elje uprave, poslovodstva, zaposlenika (ugled, utjecaj, ) vremenski okviri, razdoblje [Awad, 1985]: kratkorono, obino manje od 2 godine srednjerono, 2-5 godina dugorono, vie od 5 godina
Planiranje IS
Planiranje informacijskog sustava
Traenje odgovora na pitanja: ime se organizacija bavi (grana, proizvodi, trite, konkurencija)? Koji su problemi, zadae i ciljevi poslovnog sustava? Koja je eljena uloga IS u postizanju postavljenih ciljeva? Koje aplikacije postoje, emu i kako slue, koje i kakve podatke sadre? Postoje li aplikacije iji je razvoj u tijeku? U kojem su stadiju razvojni projekti? Koje su potrebne aplikacije? Koji su raspoloivi resursi (osoblje, tehnika sredstva, tehnologija, )?
Strateko planiranje IS
Tradicionalno planiranje IS
provodi se odvojeno od poslovnog planiranja ili provodi se kao reakcija na promjene u poslovnoj politici
Strateko planiranje IS
uspostava smjera i prioriteta usklaivanja informacijskih servisa sukladno misiji, viziji i ciljevima organizacije planiranje IS sukladno strategiji razvoja organizacije, tako da informatizacija bude potpora promjeni organizacije i poslovnih procesa primjena metoda analize i dizajna na istraivanje poslovnog sustava s ciljem definiranja opeg (sveobuhvatnog) plana i arhitekture IS iji razvoj slijedi
Razlozi zbog kojih treba planirati IS

Na primjer, u Organizaciji koja se sastoji od vie cjelina, kao to su Uprava, Financije, Proizvodnja i Informatika esto postoji vie razliitih tehnikih sustava ili aplikacija (takozvanih informatikih otoka) koji imaju za posljedicu: umnoavanje informacija uz razliito tumaenje u razliitim dijelovima nepotpunost informacija, naroito kada svaka cjelina prikuplja samo njemu vane informacije problem povezivanja informacija pri pokuaju cjelovite interpretacije problem razliitog posluivanja, razmjene podataka i odravanja
Strateko planiranje IS prikladno je za stabilne organizacije.

U praksi je teko provedivo u uvjetima preivljavanja.
A zapravo u praksi ...

Umjesto prema stratekom planu, organizacija se "dovodi u red" tijekom informatizacije i s pomou informatizacije. Analizom sustava evidentiraju se problemi i slabosti poslovnih procesa. Dizajnom sustava predlau se ili nameu poboljanja.
Okosnica plana razvoja sustava

Enterprise modeling Enterprise model Enterprise data model
Odabir i pokretanje projekata

Pokretai promjena
korisnici - nezadovoljstvo aplikacijama i/ili podacima (nepouzdanost, nedostupnost, manjkavost) npr. nestabilnost aplikacija, podaci koji nedostaju, potreba za novim funkcijama reorganizacija promjene organizacijske strukture, promjene poslovnih procesa npr. promjene na Sveuilitu uzrokovane novim zakonom pokazatelji poslovanja npr. pad prodaje, uska grla proizvodnje, neplanirano i nejasno poveanje trokova zastarjela tehnologija npr. razvojni alati (problem odravanja), suelja (Internet), baze podataka
Strategic business planning
Strategic information planning
Odabir projekta (project selection) natjeaji i prijedlozi rjeenja

sponzor projekta (organizator, predlagatelj) sastavlja prijedlog projekta (project proposal) saetak projekta (naziv, cilj, svrha) poslovne potrebe oekivana funkcionalnost oekivana korist posebnosti i ogranienja povjerenstvo za odabir (steering committee, approval comitee) odobrava projekte
P A
User review
P A D C
User review
P A D C
User review
D C
R.McLeod, E.Jordan (2002). Systems Development: A Project Management Approach,ISBN: 0471-22089-2, Wiley Higher Education
Primjeri:
\Planiranje
natjeaj: Obrazac za prijavu projekta primjene IT (MZT) interno: Zahtjev za uslugama informacijskog sustava
Pokretanje projekata (project initiation)

Snimka stanja, poetno istraivanje (survey phase, initial study, preliminary investigation)
prethodno istraivanje, tj. istraivanje koje prethodi projektu prepoznavanje problema i potreba traenje odgovora na pitanje "Da li je projekt vrijedan panje?"
Snimka stanja
Snimka stanja
brzo istraivanje i evaluacija problema, moguih prilika i direktiva problem: neeljena situacija koja sprjeava potpuno ispunjenje svrhe, postizanje ciljeva, obavljanje zadaa mogua prilika: mogunost pozitivne promjene, ak i kada ne postoji problem direktiva: zahtjev ili ogranienje nametnuti poslovnom politikom (npr. pravilnik) ili vanjskim utjecajem (npr. zakon) opcionalno se provodi procjena moguih tehnikih rjeenja, pri emu treba imati na umu da to treba biti detaljnije provedeno u kasnijim fazama odreivanje dosega projekta i poetnog plana projekta
Faza prouavanja problema (study phase)

produbljenje snimke postavljanje ciljeva, prijedlozi rjeenja, procjena izvodljivosti "Da li su problemi vrijedni rjeavanja?, "Da li je gradnja isplativa?"
Snimka poslovnog sustava

pregled poslovnih planova, ako takvi postoje ili nisu tajna prikupljanje informacija, najee intervjuiranjem vlasnika i viih rukovoditelja evidentiranje problema i prijedloga
Planiranje projekta (
Organizacija i upravljanje projektom)
Izrada plana rada Ustroj projektne ekipe ukljuivanje sudionika iz razliitih djelatnosti, npr. djelatnici razliitih poslovnih podruja ili organizacijskih jedinica, uprava, vanjski konzultanti vano je osigurati predanost sudionika zajednikom cilju (commitment) Uspostava upravljanja i nadzora projekta
Snimka stanja postojeeg (postojeih) IS

identifikacija korisnika i opsega postojeeg IS uoavanje problema i nedostataka postojeeg IS procjena potreba za nadgradnjom (poboljanjima) procjena potreba za izmjenama (prilagodbom i popravcima) procjena potreba za izradom novih IS ili podsustava IS
Primjer: postojei problemi, prijedlozi rjeenja

Kratko obrazloenje problema, mogunosti ili direktive
1. Vrijeme odgovora na narudbu mjereno od vremena zaprimanja narudbe do isporuke klijentu se povealo na prosjeno 15 dana 2. Nedavno preuzimanje kompanija: Privantna predstava i Filmsko platno nametnulo je poveanje zahtjeva za protokom informacija i dokumenata. 3. Trenutno 3 razliita sustava za unos narudbi servisiraju odjele za audio, video i video igre. Svaki sustav ima vlastito suelje prema razliitom skladinom sustavu, pa treba objediniti skladinu evidenciju. 4. Postoji nedostatak pristupa informacijama nunim za upravljanje i donoenje odluka. Ovo ce se jos pogorati preuzimanjem dva dodatna sustava za obradu narudbi (iz Privatna predstava i Filmsko platno). 5. Izraena je nedosljednost (nekonzistentnost) izmeu podataka u evedencijama lanova i narudbi. 6. Sustavi datoteka u Privatna predstava i Filmsko platno nisu kompatibilni s onim u Zvuna pozornica. Problemi s podacima obuhvaaju nedosljednosti u podacima i nedostatak upravljanja ulazom i izmjenama. 7. Postoji mogunost uvoenja sustava naruivanja putem Interneta, ali su sigurnost i kontrola pristupa problematini. 8. Postojei sustav unosa narudbi nije kompatibilan s planiranim sustavom za automatsku identifikaciju (tapiasti kod) koji se razvija za skladite.
Planiranje projekta
Odreivanje cilja i svrhe projekta (goal, objective)
izdvajanje zadataka koji su sukladni poslovnim ciljevima, a mogu biti informatizirani Koji se probleme nastoji rijeiti projektom? Koje su oekivane koristi?
Hitnost
HITNO 6 mjeseci 6 mjeseci 12 mjeseci
Vidljivost
Visoka Srednja
Korist
175,000 75,000
Prioritet
2 2
Predloeno rjesenje
Novi razvoj Novi razvoj
Srednja
515,000
Novi razvoj
Niska
15,000
Po razvitku novog sustava, pruiti korisnicima lako svladive alate za pisanje izvjetaja. Brza ispravka, a zatim novi razvoj Novi razvoj, dodatna ocjena koristi moze poveati urnost Budue verzije tek razvijenog sustava Brza ispravka, a zatim novi razvoj
Doseg i razgranienje projekata ili pod-projekata (Scope)

System boundary, Constraints, Objectives, Permissions, End products Koje su granice sustava? Koji e zahtjevi biti ispunjeni? to ne moe biti napravljeno? to nee biti napravljeno? Tko e, kako i pod kojim uvjetima moi koristiti rjeenje? Kako se mjeri ili odreuje uspjeh (neuspjeh)? Kako e se znati da je projekt gotov?
3 mjeseca 6 mjeseci
Visoka Srednja
35,000 nepoznato
1 2
12 mjeseci 3 mjeseca
Niska Visoka
nepoznato 65,000
4 1
Vremensko planiranje
odreivanje prioritetnih zadataka i vremenskih okvira prioriteta
Vidljivost: U kolikoj mjeri e rjeenje ili novi sustav biti dostupni korisnicima. Korist: Paualna procjena koliko bi rjeenje povealo dobit ili smanjilo troak u jednoj godini.
Izrada poetnog plana

Podjela projekta u podprojekte
razrada projekta u manje cjeline i odreivanje redoslijeda izrade za pojedini projekt izrauje se plan rada (work breakdown structure) obavlja se razrada i raspodjela poslova te izrada vremenskog rasporeda mogui naini podjele posla na cjeline tako da: cjelinu moe obaviti jedna osoba ili ekipa cjelina se moe obaviti jednom metodom posao zavri jednim proizvodom (dokumentom, aplikacijom ili podsustavom)
Primjer: Poetni plan informacijskog sustava

Primjer poetnog (preliminarnog) plana
1. Nabavka sustava za upravljanje bazama podataka 2. Teaj ope informatike pismenosti za rukovoditelje odjela 3. Teaj za programere u jeziku za upravljanje bazama podataka 5. Teaj za administratore baze podataka 4. Izrada prototipa programske podrke za i-tu fazu realizacije 6. Izrada - verzije aplikacije 7. Testiranje - verzije u Informacijskim sustavima 8. Uklanjanje uoenih nedostataka i izrada - verzije programa 9. Teaj za odabrane korisnike na - verziji 10. Testiranje kod korisnika u paralelnom radu s dosadanjim programom 11. Uklanjanje nedostataka i izrada stabilne verzije 12. Zamjena dotadanjeg programa novim programom, uz preuzimanje podataka 13. Teaj za ostale korisnike 14. Uvoenje koritenja programa kod ostalih korisnika 15. Teaj za upoznavanje s mogunostima programa za odabrano poslovodstvo 16. Prikupljanje primjedbi korisnika i novih zahtjeva 17. Izrada sljedee faze/verzije programa. Povratak na toku 4).
Izrada poetnog plana razvoja IS

poetni glavni plan projekta (master plan, baseline plan) podprojekti, prioriteti, okvirni vremenski plan po fazama dorauje se i aurira sukladno napretku projekta
Prezentacija projekta radi traenja suglasnosti o nastavku projekta

konsolidirani prijedlog projekta (project charter) moe posluiti kao interni ugovor projekta
Primjeri:
\Planiranje\Plan*.*
52
Izvjee o projektu (problemima i dosegu projekta)

Saetak
Saetak prijedloga Kratko obrazloenje oekivanih koristi Kratko objanjenje sadraja izvjetaja
Odreivanje poslovnih ciljeva

Produbljivanje analize problema za projekte koji prou poetnu selekciju
"Da li su problemi vrijedni rjeavanja?, "Da li je gradnja isplativa?" Detaljnija analiza problema, njihovih uzroka i posljedica "Ne pokuavaj popraviti prije nego shvati kako radi!" Analiza poslovnih procesa Koji su najvei problemi? Koja su mogua rjeenja problema? Kako informatizacija moe pomoi? Grubo modeliranje postojeeg sustava
Detaljan prijedlog
Obrazloenje prijedloga Hitne prepravke Brze prepravke Unaprjeenja Novi razvoj Plan projekta Poetni ciljevi projekta Poetni glavni plan projekta (na razini faza) Detaljni plan za slijedeu fazu
Prikupljene informacije
Kratak opis projektnog zahtjeva Kratko objanjenje provedenih aktivnosti
injenice i zakljuci
moe se potkrijepiti matricom problema i moguih rjeenja Problemi i analiza problema Mogunosti i analiza mogunosti Direktive i implikacije
Mogu se koristiti razliite formalne metode

Analiza kritinih faktora uspjeha (CSF - Critical Success Factors) imbenici kojima poslovodstvo posveuje posebnu panju imbenici koji razmjerno brzo i lako doprinose ostvarivanju ciljeva (npr. brzi odgovor na zahtjeve klijenata, odnos cijene i kvalitete proizvoda) Planiranje poslovnog sustava (BSP - Business Systems Planning) analiza poslovnih procesa analizom od vrha prema dolje uoavanje podataka povezanih s procesima Analiza izvodljivosti i procjena trokova-koristi
Prilozi
Zahtjev za uslugama sustava Matrica obrazloenja problema (ostala dokumentacija)
Uzroci i posljedice, ciljevi i ogranienja (primjeri)

ANALIZA UZROKA I POSLJEDICA Problem ili mogunost 1. Vrijeme odgovora na narudbu je neprihvatljivo dugo. Uzroci i posljedice 1. Promet je povean, a broj slubenika smanjen Vrijeme obrade narudbi je isto. 2. Sustav previe ovisi o runom unosu. Pojedine vrijednosti se unose vie puta. Posljedica je da se narudbe obrauju dulje nego je potrebno. CILJEVI I OGRANIENJA SUSTAVA Ciljevi sustava Ogranienja sustava
Istraivanje uzroka
Primjer: Istraivanje uzroka
Problem: pad prodaje Vidljivi znak: poveani opoziv (storno) narudbi Razlog: nezadovoljstvo kupaca Uzrok: spor sustav za naruivanje
1. Umanjiti vrijeme unosa pojedine 1. Broj zaposlenih u obradi narudbi se ne moe uveati. narudbe za 30%. 2. Runi unos narudbi svesti na 50% ukupnog broja. 2. Novi sustav mora biti kompatibilan s postojeim Windows XX standardom.
3. Na zaslonu za runi unos smanjiti broj potrebnih pritisaka 3. Novi sustav mora biti kompatibilan s ve odobrenim na tipkovinicu. sustavom za automatsku 4. Prenijeti unos podataka sa 3. Sredinje raunalo radi na identifikaciju tapiastim sredinjeg na osobna raunala. maksimumu svojih kapaciteta, kodom. 5. Zamijeniti postojee obrasce za to se oituje u sporijem radu prikupljanje narudbi mrenim aplikacija za unos narudbi. sustavom izmeu skladita i Budui da slubenici prodaje tako da se eliminira pokuavaju bre raditi, poveao uporaba papirnate se broj pogreaka pri unosu. dokumentacije. 4. Obrasci za prikupljanje narudbi iz skladita nisu oblikovani za uunkovito popunjavanje, to dodatno usporava unos narudbi.
Zadatak analitiara je razdvojiti uzroke i posljedice problema.

Na primjer, dugi red u nekoj videoteci nije zaseban problem nego moe biti posljedica pomanjkanja osoblja, 'lijenosti' ili nezainteresiranosti osoblja za posao ili pak posljedica runog unosa podataka i izdavanja rauna.
Vezana za definiranje problema je i provjera opravdanosti korisnikovih zahtjeva (potreba).

U naem bi primjeru analitiar trebao razmotriti da li je zahtjev vlasnika videoteke za ubrzanjem procesa izdavanja filmova realan.
56
Postavljanje ciljeva
Primjeri poslovnih ciljeva
Potpomoi reorganizaciju u trino orijentirano poduzee prema EU normama. Osigurati informacije o izvorima, razlozima i mjestu nastanka svakog troka u sustavu. Uskladiti hijerarhiju odluivanja s hijerarhijom u poduzeu. Racionalizirati utroak novca za ...
Ogranienja
Osoblje
Odjel informatike smije zaposliti najvie tri stalna zaposlenika
Materijalni troak
Nabavka uredskog i potronog materijala ne smije premaiti XXX HRK
Raunalna oprema
Projekt se mora obaviti bez nabavke novog hardvera (gospodarstvo?) Troak opreme poeljno predstavlja barem 33% budeta (znanost!)
Primjer: postavljanje ciljeva IS

Problem: Predugo vrijeme unosa narudbi Cilj: Ubrzanje unosa Kriterij: performance, izvedba Lo primjer: Poveanje ili smanjenje Poveati broj unijetih narudbi u 24 sata za 5% Bolji primjer: Razina provedbe Unijeti 98% zaprimljenih narudbi unutar 24 sata Kriterij mora biti mjerljiv Apsolutni iznos ili relativni iznos konkretne vrijednosti Moe biti binaran postoji ili ne postoji, npr. Omoguiti online pretraivanje
Financijska sredstva
Ukupni budet projekta je XXXXX HRK (uvijek manji od traenog!) Naknade izvoaima ne smiju premaiti XX% ukupnog iznosa
57
58
Modeliranje postojeeg sustava

Svrha
Preciziranje dosega projekta Verifikacija razumijevanja problema i usaglaavanje percepcije sustava i stavova izmeu sudionika (korisnici, informatiari)
Planiranje informacijskog sustava

Aktivnosti
Analiza problema, povoljnih prilika i moguih rjeenja problema Definiranje ciljeva i zadataka informacijskog sustava Procjena ogranienja Ponovna procjena i preciziranje opsega projekta Revizija glavnog plana
Taktika - Skrivanje informacija (information hiding)

skrivanje/zanemarivanje detalja i usredotoenje na ono to je zaista vano npr. izbjegavanje prouavanja tehnikih detalja u ranim fazama
Puzei doseg projekta (creeping scope)

Tijekom izvedbe projekta esto se dogaa polagano, ali znaajno poveanje obujma uslijed pogrene procjene ili razliitog tumaenja ciljeva izmeu korisnika i izvoaa Granice projekta moraju biti definirane to je mogue preciznije Time se kasnije poveanje projekta moda nee ukloniti ali e se barem moi nadzirati
Globalni, okvirni, grubi modeli

Model organizacije i resursa kontekst, organizacijska struktura, prostorni raspored sredstava Globalni model procesa funkcionalna dekompozicija tok kljunih poslovnih procesa
kolanje dokumenata i protok informacija
Opcionalno se planira i provodi:

Izrada prototipa ili oglednog (pilot) projekta i procjena njegove uspjenosti projekt koji se moe uspjeno i brzo realizirati (npr. 3-9 mjeseci, ovisno o veliini itavog projekta) poeljno takav koji e vratiti uloenu investiciju Procjena moguih tehnikih rjeenja IS (alternativa) i prijedlog najboljeg rjeenja
Globalni model entiteti-veze (enterprise data model) kategorije podataka klase podataka (ne razredi objekata!)
Na kraju se (opet!) moe oekivati

pokretanje, odbacivanje, odgoda ili prilagodba (ostalih, pojedinih) projekata
Idejno rjeenje
Saetak
Saetak prijedloga Saetak problema, mogunosti i direktiva Kratki navod ciljeva unaprjeenja sustava Kratki navod sadraja izvjea
Primjeri
Primjeri: \Planiranje
Globalno idejno rjeenje informatizacije za "SLJEME", d.d. Idejno rjeenje IS Personalne uprave Strategic Plan For Alaskas Criminal Justice Information System Integration
Analiza postojeeg sustava

problemi, mogunosti i analiza uzroka i posljedica za pojedine elemente Performance Informacije Ekonomija Kontrola Uinkovitost Usluge (servisi)
Poznate informacije
Popis odranih razgovora i koordiniranih grupnih sastanaka Popis ostalih izvora informacija Opis tehnika koritenih u analizi
Pregled postojeeg sustava

Strategijske odrednice (ako je projekt dio SPIS ili na njega utjee) Modeli postojeeg sustava Model suelja (kontekst) Model resursa (prostor) Model procesa (funkcija) Model podataka (kategorije)
Detaljni prijedlozi
Ciljevi i prioriteti unaprjeenja sustava Prepreke unaprjeenja sustava Plan projekta Precizirani doseg projekta Revidirani glavni plan Detaljni plan za slijedei korak
Dodaci
Modeli sustava (ako nisu dio studije) (ostala dokumentacija prema potrebi)
61
62
Analiza izvodljivosti
Za pojedine projekte analizira se izvodljivost
mjerenje korisnosti, praktinosti i isplativosti projekta - IS trebala bi se raditi tijekom planiranja, ali i kasnije (npr. nakon faze analize) nakon odluke o pokretanju projekta sloenost i opseg projekta mogu se promijeniti pa poetno izvodljiv projekt moe postati neizvodljiv praktino gledano, tonost procjene izvodljivosti raste s dubinom analize
Analiza izvodljivosti i trokova-koristi
Analiza, Studija izvodljivosti (feasibility analysis, feasibility study)

detaljna provjera projekata koju provode sistem analitiari procjenjuje se da li je projekt izvodljiv s obzirom na raspoloiva sredstva procjenjuje se da li projekt omoguuje poboljanja radi se izvjee o izvodljivosti i prezentira se relevantnim sudionicima radi komentara i miljenja moe biti dio idejnog rjeenja, a ponekad tako i izgleda eventualni povratak u studiju izvodljivosti revidirano izvjee
64
Operativna izvodljivost
Organizacijska/Operativna izvodljivost
procjena hitnosti rjeavanja problema (planiranje) procjena prihvatljivosti rjeenja (kasnije faze)
Tehniko-tehnoloka izvodljivost
Moe li se sagraditi? Moe li se kupiti?
Procjena moguih rjeenja i alternativa

procjena stanja na tritu opreme procjena postojeih rjeenja u drugim organizacijama (tamo gdje je mogue) procjena primjenjivosti razliitih tehnologija
Vrijedi li rjeavati problem? Da li predloeno rjeenje rjeava problem?

Performance protonost i odziv sustava s obzirom na ulaze Informacije dovoljne, pravodobne, prikladne, aurne, tone, korisne Ekonomija problemi trokova, mogunosti uteda Kontrola sigurnost i zatita podataka Uinkovitost poboljanje uporabe raspoloivih resursa (ljudi, oprema, novac, itd.) Usluge poeljni i pouzdani servisi, elastinost i mogunost prilagodbe, zadovoljstvo
Primjenjivost rjeenja, tehnologije

Moe li se tehnologija jednostavno primijeniti? Pojedine sredine zagovaraju najsuvremeniju tehnologiju (state-of-the-art) naprednost, zanimljivost Veina je sklona zreloj i dokazanoj tehnologiji sigurnost, bolja podrka
Koji je stav korisnika prema rjeenju? Da li e se sustav koristiti?

Podrka uprave i prihvaanje od krajnjih korisnika otpori njihovoj buduoj ulozi ili tehnikom rjeenju i kako ih prevladati Promjena radnog okruenja, procedura prilagodba promjenama Procjena upotrebljivosti (najee prototipom) Krivulja uenja vrijeme osposobljavanja potrebno za postizanje pune primjene Lakoa koritenja jednostavno suelje za poetnike i povremene korisnike, sloenije operacije za iskusne korisnike Zadovoljstvo ponuenom rjeenju korisnik daje prednost pred postojeim
Raspoloivost tehnologije (podrazumijeva se da je primjenjiva)

Moe li se nabaviti? Ako je rije o gotovom rjeenju (IS iz duana), ima li to rjeenje potrebne karakteristike? Treba li ga i u kojoj mjeri prilagoditi ili doraditi?
Strunost
Postoji li potrebna strunost za primjenu tehnologije? I najnovija tehnologija moe se svladati Postoji li potrebna vjetina za oekivani zavretak prema rasporedu? Bitno je da usvajanje tehnologije i njezina primjena zavre na vrijeme
Vremenska izvodljivost
Kada e biti gotovo? Moe li biti gotovo na vrijeme?
Ekonomska izvodljivost
Isplati li se graditi? Treba li graditi?
Prihvatljivost vremenskog rasporeda

Razmatra se opravdanost rokova s obzirom na raspoloivu strunost
Troak razvoja sustava (fiksni troak)

apsolutni iznos, poetna procjena, auriranje tijekom napretka projekta primjeri: osoblje: plae, honorari oprema procjenjuje se nakon odabira tehnikog rjeenja izobrazba: teajevi
Oekivano vrijeme zavretka moe biti poeljno ili obvezno

vrsti rokovi nesigurni projekt treba prekinuti/odgoditi Poeljni rokovi moe se predloiti alternativni vremenski plan
Troak primjene sustava (varijabilni troak)

relativan iznos, ovisan o uporabi primjeri: reije (struja, telefon) odravanje (ljudski rad) obnova licenci
Bolje je isporuiti ispravan sustav dva mjeseca kasnije, nego neispravan ili beskoristan na vrijeme!!!
Analiza i usporedba ukupnih trokova-koristi (cost-benefit analysis)

Trokovi i korist mjerljivi (npr. cijena opreme, iznos plaa, prodaja, prihod) nemjerljivi (npr. zadovoljstvo korisnika, brzina odluivanja, dobra referenca) Financijski troak i korist mogu se izraziti formulama razlika korist-troak u nekom razdoblju (Net Present Value) povrat investicije (korist-troak)/troak (Internal Rate of Return) trenutak u kojem korist nadvlada troak (Payback Point)
67
68
Ekonomska izvodljivost
CBA rauna trokove i korist projekta kao trenutnu vrijednost (Present value - PV)
$ oznaava novanu jedinicu u bilo kojoj valuti
Troak / Korist Troak razvoja Primjena i odravanje Faktor za kamatu 12% Trenutna vrijednost Kumulativni troak Korist od novog IS Faktor za kamatu 12% Trenutna vrijednost Kumulativna korist Ukupno
400,000 $ 300,000 $ 200,000 $ 100,000 $ 0$ (100,000 $) (200,000 $) (300,000 $) (400,000 $) (500,000 $)
Primjer analize troak-korist

Godina 0 Godina 1 Godina 2 Godina 3 Godina 4 Godina 5 (418,040 $) (15,045 $) (16,000 $) (17,000 $) (18,000 $) (19,000 $) 1.000 0.893 0.797 0.712 0.636 0.567 (418,040 $) (13,435 $) (12,752 $) (12,104 $) (11,448 $) (10,773 $) (418,040 $) (431,475 $) (444,227 $) (456,331 $) (467,779 $) (478,552 $) 0 $ 150,000 $ 170,000 $ 1.00 0.893 0.797 0 $ 133,950 $ 135,490 $ 0 $ 133,950 $ 269,440 $ 0 1 2 (418,040 $) (297,525 $) (174,787 $) 190,000 $ 0.712 135,280 $ 404,720 $ 3 (51,611 $) 210,000 $ 0.636 133,560 $ 538,280 $ 4 70,501 $ 230,000 $ 0.567 130,410 $ 668,690 $ 5 190,138 $ Godina 6 (20,000 $) 0.507 (10,140 $) (488,692 $) 250,000 $ 0.507 126,750 $ 795,440 $ 6 306,748 $
Dananja vrijednost onoga to e postati $1.00 nakon n godina u budunosti, ako uzmemo u obzir kamate I iznosi: PV = 1/(1 + I)n = (1 + I)-n Razlika predstavlja kamatu koja se moe zaraditi tim novcem
Primjeri:
trokovi razvoja od $100.000 imaju trenutnu vrijednost od $100.000 korist projekta u iznosu od $30.000 za pet godina uz kamatnu stopu od 8% ima trenutnu vrijednost od samo: $30.000 / (1 + 0.08)5 = $20.417
Povrat investicije Return On Investment (ROI)

gleda se postotak povrata investicije ROI - postotak relativnog iznosa koristi projekta ROI = (ukupna korist ukupan troak) / (ukupan troak) ROI se obino dijeli sa duinom projekta kako bi se dobio godinji ROI Nizak ROI (~ manji od 10% godinje) moe pokazivati da je korist preniska da bi bila isplativa
70
Izvodljivost i odrivost projekta

Primjeri:
\PIS-PrimjerProjekta \Planiranje\ SurvivalTest [McConnell, 1998], http://www.construx.com/survivalguide/ OdrzivostProjekta Izvodljivost-HZZO
Prikupljanje informacija i utvrivanje zahtjeva

Prikupljanje informacija (information gathering) Prikupljanje podataka (data collection) Ustanovljavanje injenica (fact finding)
71
Prikupljanje informacija
Intervjui s kljunim korisnicima i radne sjednice
Ako naruitelj zapoljava informatiare svakako ih treba ukljuiti u analizu. Sueljavanje korisnika i informatiara ubrzava rjeavanje proturjenih iskaza.
Postupak intervjuiranja
Intervju
neusiljen i elastian razgovor s ispitanikom, slijed pitanja i odgovora ispitanik se pojavljuje u ulozi pasivnog sugovornika (!?) sugovornici: rukovoditelji, krajnji korisnici, ostali sudionici standardno ukljuuje dva sugovornika ali moe i vie (korisnika, ispitivaa): individualni intervju jedan korisnik ili suradnici koji rade isti posao intervjuiranje grupe vie korisnika iz razliitih podruja
Upitnici i ankete
Nadomjestak za intervju ili prikupljanje informacija o resursima.
Analiza dokumentacije
Treba prikupiti sve dokumente znaajne za poslovanje, radi boljeg utvrivanja pravila, poslovne politike, ciljeva poslovanja te strukture informacija.
Organizacija razgovora
informacije se prikupljaju nizom pojedinanih razgovora (prvi) razgovori trebali bi se voditi prema unaprijed dogovorenom planu i rasporedu koordinator Primjeri: \Analiza\PlanRazgovora postupak je spor i neuinkovit, jer se organizacija razgovora mora obaviti za svaki pojedini razgovor nakon dovretka analize i sinteze dobivenih informacija neke razgovore (ponekad i itavu seriju) treba ponoviti da bi se upotpunile dobivene informacije ili uskladili proturjeni iskazi ukupan broj razgovora ne moe se unaprijed tono odrediti i treba ga prilagoditi stvarnoj situaciji
Prosudba postojeih rjeenja na raunalu

Nuna je prosudba postojeih aplikacija i/ili raunalom podranih podataka, radi analize podataka ali i zbog njihove konverzije u novi sustav.
Promatranje
Neposredni uvid u poslovne procese promatranjem radnih sredina (nain izrade i razmjene dokumenata, procesi osnovne djelatnosti).
Drugi naini
Prototipiranje,
Postupak analize mora biti prilagoen korisniku. Evidentiranje rezultata analize poeljno je obaviti CASE pomagalom.
74
Tehnika intervjuiranja
Priprema za razgovor
utvrivanje informacija koje treba saznati prouavanje postojee dokumentacije i prethodnih nalaza odreivanje dokumentacije koju bi trebalo prikupiti priprema pitanja koja e biti postavljena tijekom razgovora izrada jezgre tema, to jest standardnih pitanja izrada sveobuhvatnog podsjetnika i izdvajanje prikladnih pitanja
Planiranje i obavljanje razgovora
okvirno trajanje prvog razgovora je 2 sata (openito 1,5 2,5 sata) Poetak razgovora predstavljanje sudionika upoznavanje sa svrhom razgovora (prikupljanje informacija o ) Voenje razgovora postavljanje pitanja i biljeenje odgovora prikupljanje dokumentacije Zavretak razgovora priblino 5-10 minuta prije isteka planiranog vremena prekida se slijed postavljanja pitanja provjerava se da li postoji neto to je sugovornik htio rei a nije bilo pitano provjerava se da li treba proiriti krug sugovornika dogovara se nastavak razgovora (dopunski razgovor) kada:
voditelj razgovora nije postavio sva planirana pitanja ili voditelj smatra da je razgovor nametnuo nova pitanja
Primjeri:
\Analiza\
Podsjetnik-teme Podsjetnik-kratki Podsjetnik-dugi
zahvala na razgovoru
Preispitivanje i pojanjenje sadraja (follow-up)
provjera zabiljeenih navoda radi upotpunjavanja biljeki telefonom, elektronikom potom, novim sastankom
Preporuke za voenje intervjua

Treba pitati o svemu to se smatra vanim
nita nije samo po sebi razumljivo i svima jasno ne pretpostavljati da se unaprijed zna o emu se radi
Dokumentiranje razgovora
Pisanje zapisnika samostalno pisati zapisnike (Tko ne razumije, ne moe biljeiti.) kada u razgovoru sudjeluje vie analitiara, odreuje se voditelj razgovora koji je ujedno i zapisniar, a ostali ulau primjedbe Sadraj zapisnika
Projekt Vrijeme i mjesto odravanja razgovora Sudionici Sadraj razgovora (tekst zapisnika) Popis prikupljene dokumentacije Zapisniar
Repertoar i vrste pitanja

Pitanja zatvorenog tipa: Koliko ... obraujete (u nekom razdoblju)? Na koji nain obraujete ... ? Pitanja otvorenog tipa: to mislite o ... ? Koji su najvei problemi ... ? Probna pitanja: Zato ? Moete li navesti primjer za takvu situaciju? Molim detaljnije objanjenje za ...
zapisnik mora sadravati ono to je reeno i slijediti tok razgovora zapisnik ne smije nametati zakljuke, jer su oni rezultat analize
Autorizacija (ovjera) zapisnika

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

Preporuke za voenje intervjua

Analiza odgovora
razluivanje injenica od miljenja utvrivanje da li pojedine injenice odgovaraju drugima analiza injenica koje se ne poklapaju provjera odgovora razliitih sugovornika na isto pitanje
Upitnici i ankete
Upitnik (pismeni intervju)
sadri pitanja koja se postavljaju tijekom razgovora (okvirno 20) moe se dostaviti korisniku prije, umjesto ili nakon intervjua nedostaci: ispitanik moe prilagoditi (kontrolirati) svoje odgovore teko je procijeniti iskrenost (spontanost) odgovora moe obeshrabriti ispitanika Primjer: Podsjetnik za SIO
Preporuljivo ponaanje
iskrenost i nepristranost cilj je nai za korisnika najprikladnije rjeenje, a ne podupirati odreeno programsko rjeenje ili raunalnu platformu panja i jezgrovitost brzo misli, jasno govori izbjegavanje sugestivnih pitanja nenametanje zakljuaka leernost (+ praenje reakcija sugovornika)
Anketa (inventar)
moe se obuhvatiti vie ispitanika pitanja zatvorenog tipa odgovori i obrada odgovora mogu se standardizirati pogodna za popis resursa Primjer: IS-Resursi
Intervjuiranje je elastinije!
Pomou intervjua moe se vie nauiti o stavovima, osjeajima i motivaciji osoblja. Tijekom intervjua analitiar i ispitanik nalaze se jedan nasuprot drugom, pa analitiar moe promatrati nain na koji ispitanik odgovara i po potrebi proiriti ili usmjeriti pitanja.
Grupno intervjuiranje
izbjegavati i po potrebi nadomjestiti radnim sjednicama iznimno provesti, kada se eli utvrditi zajedniki interes ili proturjeje
80
Prouavanje dokumenata
Prikuplja se sve do ega se moe doi
Analiza procesa Tipini dokumenti: pravilnici i zakoni Analiza podataka Tipini dokumenti: obrasci (formulari), izvjea Poeljno je da dokumenti budu reprezentativni, tj. popunjeni na tipian nain. Tako se moe ustanoviti koje informacije se uope unose i na kakav nain.
Reprezentativni dokumenti najee ne ukazuju na izuzetke, to jest podatke koji se rjee biljee ali ipak trebaju. Takoer, stalno biljeenje nekih podataka ne mora znaiti da su ti podaci stvarno potrebni. Treba prikupiti vie uzoraka iste vrste dokumenta! ( sampliranje)
Analiza postojeih aplikacija i evidencija

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

nepovezanost aplikacija (tzv. informatiki otoci) loa programska rjeenja (funkcionalnost, ergonomija) nepouzdanost integritet, zatita i sigurnost podataka nepostojanje programske dokumentacije tehnoloka zastarjelost (programski jezici i alati, nemogunost rada u viekorisnikom okruenju, grafiko suelje)
Vrijednost informacija o analiziranoj organizaciji prikupljena (samo) preko dokumenata je niska.

Praksa moe odudarati od pravilnika i administrativnih obrazaca. Treba shvatiti zato i kada dokumenti nastaju, kako se popunjavaju, koliko su potrebni te to treba promijeniti da bi ih se popravilo (sadraj, lakoa popunjavanja i itanja) Nuno je modele (podataka) razluene analizom provjeriti kod korisnika.
Primjeri:
\Dokumenti
81
Primjeri:
\PIS-PrimjerProjekta
82
Analiza postojeih aplikacija i evidencija

Nedostaci modela podataka
Razliitost modela podataka postojeih aplikacija entiteti iz stvarnog svijeta nisu jednako zastupljeni u postojeim modelima isti entitet iz stvarnog svijeta pojavljuje se pod razliitim nazivima isti entitet iz stvarnog svijeta opisan je razliitim atributima dva ili vie entiteta iz stvarnog svijeta prikazano je razliitim brojem entiteta u podatkovnim modelima Nedostaci unutar pojedinog modela nedefiniranost identifikatora (primarnih kljueva) nedefiniranost veza meu podacima, najee kao posljedica nepostojanja primarnih kljueva nedefiniranost veza unato postojanju primarnih i (drugih) stranih kljueva, kao posljedica razvoja tijekom uporabe i nedosljednosti naglaena zalihost uvedena prilikom izrade zahtjevnih ili sloenih programskih rjeenja ukupna nenormaliziranost modela
Promatranje poslovnog sustava

Uvid u poslovne procese promatranjem radnih sredina
promatra se lokacija i kretanje ljudi te tijek izvravanja poslova fiziki ulazi i izlazi sustava zaprimanje, izrada i razmjena dokumenata procesi osnovne djelatnosti, primjerice proizvodnja
Prednosti
analitiar je u stanju realno sagledati poslovni proces uinkovitost, ako se dobro provede pouzdanost prikupljenih informacija
Nedostaci
neuinkovitost, ako se dobro ne provede utroak vremena ometanje i neugoda promatranih osoba mogunost manipulacije promatraa npr. prikrivanjem uobiajenog krenja radnih procedura
Primjer: ERwin Examiner Navedeni nedostaci opreme, podrke i podataka najei su razlozi za izgradnju novog IS! ( Operativna izvodljivost)
Duina i uestalost promatranja

Podaci dobiveni iz malog broja kratkotrajnih promatranja mogu biti nepouzdani i netoni.
Promatranje na licu mjesta je najtea metoda za pronalaenja injenica.

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

koristi se za prikupljanje ideja i definiranje inofrmacijskih potreba korisnike se potie na aktivno i kreativno sudjelovanje izvodi se tako da se svakog ispitanika iz grupe zatrai da definira po njemu idealno rjeenje svaki sudionik iznosi sve to mu pada na pamet u svezi s problemom koji se rjeava od predloenih rjeenja odabire se najbolje prema realnoj izvodljivosti postupak je uinkovit tamo gdje postoje korisnici koji dobro poznaju sustav ali teko prihvaaju nove ideje
Nedostaci
sadraj i dinamika pasivnost sudionika usitnjavanje razgovora udaljavanje od tema trajanje sjednice bi trebale trajati vie dana (5-10) u nekoliko tjedana ovom zahtjevu u praksi je vrlo teko udovoljiti zbog obveza sudionika otpor sjednici i prateoj izolaciji razmjeran je razini poloaja konkretnog sudionika naglaen kada poduzee zapoljava informatiare, jer se podrazumijeva da je informatizacija iskljuivo njihov posao.
86
Razvoj prototipa
Prototipiranje (prototyping)
Koristi se kada korisnik ne moe tono definirati svoje informacijske potrebe prije nego to se izgradi informacijski sustav. Razlog tomu moe biti nedostatak postojeeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak teka vizualizacija budueg sustava.
Najei problemi pri prikupljanju informacija

Ponaanja korisnika
Taktika kuhinjskog sudopera korisnik navodi (preko)brojne potrebe: hrpu nepotrebnih izvjetaja, formi, sortiranja, izrauna i sl. ovakav pristup obino je uzrokovan pomanjkanjem iskustva korisnika koji ne zna to bi mu stvarno trebalo zatrebati ili nije u stanju razluiti ono to je bitno Taktika dimne zavjese korisnik trai vie mogunosti a zapravo mu je potrebna samo jedna ili dvije dodatni zahtjevi slue za postizanje bolje nagodbe s analitiarom taktika obino oslikava korisnika s dobrim poznavanjem onoga to eli, a zahtjeve treba reducirati na one realne i izvodljive Taktika "Treba mi isto ali u boljem obliku" korisnik koji koristi ovu taktiku nedostaje volja ili znanje, a ponekad oboje anse za uspjeno definiranje problema su male jer samo korisnik moe izraziti svoje potrebe i probleme
Izrada prototipa
Izgrauje se sustav koji zadovoljava neke osnovne, inicijalne potrebe. U radu s takvim sustavom korisnik otkriva svoje informacijske potrebe te se sustav modificira kako bi se zadovoljile te potrebe. Postupak koritenje sustava i modificiranja istog iterativno se ponavlja, a informacijske potrebe korisnika otkrivaju koritenjem sustava.
Izrada prototipa pogodna je u onim okruenjima gdje je teko definirati konkretni model sustava te u okruenjima gdje se informacijske potrebe korisnika mijenjaju ili razvijaju.
Korisnik je sklon preutjeti izuzetke, koji su bitni (nuni !!!) za uspjenu realizaciju, a obino zahtijevaju i najvie napora tijekom ugradnje.
"To je naa jedina procedura (osim kada )"
Ne izjednaavati tako se uvijek radi s tako treba raditi!

primjer: Google Search "Company Policy"
Primjer: Poslovna politika

Start with a cage containing five monkeys. In the cage, hang a banana on a string and put a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the Banana. As soon as he touches the stairs, spray all of the monkeys with cold water. After a while, another monkey makes an attempt with the same result - all the monkeys are sprayed with cold water. Pretty soon, when another monkey tries to climb the stairs, the other monkeys will try to prevent it. Now, turn off the cold water. Remove one monkey from the cage and replace it with a new one. The New monkey sees the banana and wants to climb the stairs. To his horror, all of the other monkeys attack him. After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted. Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous Newcomer takes part in the punishment with enthusiasm. Again, replace a third original monkey with a new one. The new one makes it to the stairs and is attacked as well. Two of the four monkeys that beat him have no idea why they were not permitted to climb the stairs, or why they are participating in the beating of the newest monkey. After replacing the fourth and fifth original monkeys, all the monkeys which have been sprayed with cold water have been replaced. Nevertheless, no monkey ever again approaches the stairs. Why not? Because that's the way it's always been around here. And that's how company policy begins....
Analiza sustava
(Google search: company policy)

89
Analiza sustava
Analiza sustava, sistemska analiza
Analiza sustava je ralanjivanje sustava u njegove komponente da bi se prouilo kako te komponente rade i meusobno komuniciraju. provodi se s namjerom slijedee sinteze sustava i razvoja aplikacija Sinteza sustava Ponovno objedinjavanje komponenti u cjeloviti, poeljno poboljani, sustav.
Aktivnosti analize
Aktivnosti analize
detaljna analiza postojeeg sustava te utvrivanje potreba i zahtjeva Kako radi postojei sustav? Na koji nain ljudi koriste sustav da bi obavili svoj posao? Koji su problemi pri koritenju aplikacija? detaljna specifikacija zahtjeva na IS Koji su podaci potrebni? Tko ih treba? Kada? Od koga? Tko ih stvara? Koji su izlazni podaci? Kakav im je oblik? Koji su izvori izlaznih podataka? Na koji nain se podaci prikupljaju i objedinjuju? daljnja razrada granica projekta primjeri: ProtokDokumenata, RazmjenaPodataka
Alternativna definicija
Analiza sustava je (1) razmatranje i planiranje sustava i projekta, (2) prouavanje i analiza postojeeg poslovnog i informacijskog sustava te (3) definiranje poslovnih zahtjeva i prioriteta novog ili poboljanog postojeeg sustava. [Whitten et. al, 2000]
Svrha, cilj i dubina analize

Automatizacija poslovnih procesa - Business Process Automation (BPA) poveanje uinkovitosti korisnika analizom problema i uklanjanjem uzroka Poboljanje poslovnih procesa - Business Process Improvement (BPI) poveanje uinkovitosti i djelotvornosti, analizom trajanja i kotanja poslovnih procesa te predlaganjem poboljanja (udruivanje procesa, paralelizam izvedbe) Reinenjerstvo poslovnih procesa - Business Process Reengineering (BPR) ili Preoblikovanje poslovnih procesa - Business Process Redesign (BPR) radikalni redizajn poslovnih procesa, analizom moguih posljedica, procjenom alternativnih tehnologija, ukidanjem ili zamjenom pojedinih aktivnosti, analizom trokova-koristi i analizom rizika
Pozadinska analiza
Vano je da shvatiti strukturu organizacije, tko u njoj radi, tko je kome podinjen, kako surauju razliiti odjeli, itd.
Provedba analize - modeliranje sustava

Za potrebe pozadinske analize moe se izraditi shema organizacijske strukture iz koje e biti vidljivo koja osoba ili grupa ljudi obavlja koji dio posla ( Modeliranje funkcija). Za ostale elemente takoer se rade odgovarajui modeli ( Modeliranje procesa, modeliranje podataka)
92
Postupci i tehnike analize

Moderna strukturirana analiza
procesno usmjerena tehnika modeliranja poslovnih zahtjeva na sustav
Strukturirana analiza
Moderna strukturirana analiza = Logiki dizajn (esti sinonim)
strukturirana analiza strukturirani proces i rezultati analize tehnika modeliranja poslovnih zahtjeva na sustav usmjerena procesima, ali se razvila tako da obuhvaa i podatke strukturiranje procesa, ulaza, izlaza te spremita podataka potrebnih da bi se ogovorilo na poslovne dogaaje logiki modeli modelima se prikazuje TO je sustav i TO mora raditi (ne KAKO) koriste se dijagrami toka podataka za logiki prikaz poslovnih zahtjeva nezavisno od tehnikih rjeenja logiki dizajn izraavaju sutinu sustava sinonimi: esencijalni, konceptualni, poslovni modeli ukljuuje odreivanje prioriteta zahtjeva
podatkovno usmjerena, ali procesno osjetljiva tehnika, usmjerena prouavanju organizacije ili njenih veih dijelova kao cjeline, a ne projekt po projekt
Brzi razvoj aplikacija (Rapid Application Development - RAD)

razvoj djelominih verzija aplikacija, koje mogu evoluirati do konanog rjeenja
Zdrueni razvoj aplikacije (Joint Application Development - JAD)

analiza zasnovana na intenzivnim radnim sjednicama na kojima vlasnici, korisnici, analitiari, dizajneri i graditelji zajedniki definiraju i oblikuju sustav
Objektno usmjerena analiza

modeliranje uahurivanjem podataka i procesa u objekte prouavanje postojeih objekata da bi se vidjelo mogu li se ponovno iskoristiti ili prilagoditi za nove primjene definiranje novih ili modificiranih objekata koji e skupa s postojeim objektima graditi novu aplikaciju
Analiza s ciljem automatizacije poslovnih procesa

razumijevanje postojeeg sustava ekstenzivno prikupljanje informacija i zahtjeva oblikovanje procesa i podataka uoavanje moguih poboljanja (ako nije uinjeno ranije) analiza problema identificiranje problema, ustanovljavanje eljenih poboljanja analiza uzroka (root causes analysis) prioriteti problema i traenje uzroka razvoj koncepata budueg sustava prikupljanje dodatnih informacija revizija i dorada modela
Navedeni postupci mogu se komplementarno primjenjivati, unato uvrijeenom poimanju da je rije o meusobno iskljuivim metodama!!
Definiranje zahtjeva
IEEE standard definira zahtjeve kao:
(1) Uvjet ili sposobnost koje korisnik treba da bi rijeio problem ili ostvario cilj. (2) Uvjet ili sposobnost koji mora posjedovati sustav ili komponenta sustava da bi zadovoljila ugovor, standard, specifikacije ili neki drugi ugovoreni dokument. (3) Dokumentiranu reprezentaciju uvjeta ili mogunosti definiranih pod (1) ili (2). [IEEE Std 830-1998], [IEEE Std 610.12-1990]
Vrste zahtjeva
Poslovni zahtjevi (zato)
ciljevi organizacije ili korisniki zahtjevi na vioj razini, opis problema koje treba rijeiti primjer: poslovna potreba, "Poboljanje usluge postojeim klijentima i pridobivanje novih" sadrani u dokumentima u kojima se opisuje vizija i opseg projekta primjer: poslovni zahtjev, "Omoguiti Internet prodaju"
Zahtjevi ne sadre detalje dizajna, detalje implementacije ili informacije vezane uz planiranje projekta. Panja se usmjerava na ono TO se eli izgraditi, a ne ulazi se u detalje kako i kada to napraviti. Za 40-60% pogreaka u projektu uzrok lei u pogrekama napravljenim u fazi postavljanja zahtjeva. [Leffingwell, 1997]
Tipina posljedica su "prazna oekivanja" (expectation gap): razlika izmeu onog to oekuje naruitelj i onoga to je izvoditelj mislio da treba napraviti.
Korisniki zahtjevi (zahtjevi krajnjih korisnika)

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

definiraju softversku funkcionalnost (oekivano ponaanje i operacije koje sustav moe izvoditi) koju treba ugraditi u proizvod da bi omoguio korisnicima obavljanje njihovih zadataka posebno zanimljiva mogunost programa (feature) skup logiki povezanih funkcionalnih zahtjeva koje korisniku omoguuju ispunjavanje poslovnih zahtjeva
Naknadne prepravke mogu predstavljati do 40% trokova razvoja, od ega je 70-85% pripisivo pogrenim zahtjevima [Leffingwell, 1997].
Nepotpuno definirani zahtjevi ine planiranje projekta i praenje promjena nemoguim.
Nefunkcionalni zahtjevi (kako ili kako dobro)

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

Primjeri zahtjeva vlasnika sustava

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

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

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

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

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

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

Npr. javni prijevoz po povlatenoj cijeni, kazalita, kina, smjetaj u studentskim domovima, student-servis, itd.
Primjer nepotpunog zahtjeva

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

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

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

"Parser e brzo generirati izvjee o pogrekama HTML oznaka, koje omoguava brzi ispravak pogreaka kada program koriste poetnici u HTML-u."
Rije "brzo" je neodreena. Nije definirano to tvori izvjee i to ini zahtjev nekompletnim. Kako se ovjerava zahtjev? Pronai nekoga tko se smatra poetnikom u HTML-u i zatim vidjeti kako brzo e, uz pomo izvjea, ispraviti pogreke? Kada se generira izvjee? Poslovni zahtjevi
Odreivanje zahtjeva
Sve to opisuje financijski, trgovaki, ili drugi poslovni probitak koji korisnici, ili organizacija koja razvija sustav, mogu dobiti je najvjerojatnije poslovni zahtjev.
Sluajevi koritenja ili scenariji

Openite izjave o korisnikim ciljevima ili poslovnim zadacima koje korisnici moraju obavljati najvjerojatnije su sluajevi koritenja, dok specifini opisi zadataka predstavljaju korisnike scenarije. Specifine zadatke treba generalizirati u openite sluajeve koritenja.
Poslovna pravila
Kada korisnik izjavi da se neku aktivnost mogu obavljati samo pojedine osobe ili uloge, pod odreenim uvjetima, on moda opisuje poslovno pravilo. Poslovna pravila su operativni principi poslovnih procesa. Oni nisu funkcionalni zahtjevi.
Bolje:
Nakon to je HTML analizator obradio datoteku generirat e izvjee koje sadri broj linije i tekst pronaenih HTML pogreaka, te opis svake pogreke. Ukoliko nema pogreaka prilikom analize, nee se generirati izvjee.
Funkcionalni zahtjevi
Izjava koja poinje s Korisnik mora moi obaviti neku funkciju, ili Sustav treba moi demonstrirati odreeno ponaanje je najvjerojatnije funkcionalni zahtjev. Funkcionalni zahtjevi opisuju vidljivo ponaanje sustava i definiraju to e sustav raditi. Treba biti svima jasno zato sustav mora biti u stanju obavljati odreene funkcije. Predloeni funkcionalni zahtjevi ponekad predstavljaju zastarjele ili neuinkovite poslovne procese koji ne trebaju biti ukljueni u novi sustav.
Atributi kvalitete
Izjave koje opisuju kako dobro sustav obavlja funkciju su atributi kvalitete, tj. jedna vrsta nefunkcionalnih zahtjeva. Zahtjeve koji opisuju poeljne karakteristike sustava: brzinu, jednostavnost, intuitivnost, robusnost, pouzdanost, sigurnost i efikasnost treba razmotriti s korisnicima da bi se precizno utvrdilo to oni misle pod tim dvosmislenim i subjektivnim terminima.
Odreivanje zahtjeva II
Zahtjevi vanjskih suelja
Ovaj razred zahtjeva opisuje veze izmeu sustava i vanjskog svijeta. Specifikacija sistemskih zahtjeva trebala bi ukljuivati odlomke za ove zahtjeve ukljuujui i suelja te mehanizme komunikacije za korisnike, hardver i druge softverske sustave.
Postavljanje prioriteta
Nuno svojstvo - Da li vlasnik sustava neto stvarno mora imati?
Postoji tendencija da se previe zahtjeva proglasi nunim! Po definiciji, ako sustav ne ukljuuje nune zahtjeve, taj sustav ne moe ispuniti svoju svrhu. Treba testirati svaki zahtjev koji se smatra nunim i probati ga rangirati. Ako se zahtjev moe rangirati onda nije obvezan! Potpuno obvezni zahtjevi se ne mogu rangirati jer su nuni za prvu verziju sustava!
Ogranienja
Ogranienja su uvjeti koji ograniavanju izbor rjeenja raspoloivih dizajneru ili programeru. Spadaju u nefunkcionalne zahtjeve i trebaju biti dokumentirani. Neopravdana ogranienja treba pokuati odbaciti jer onemoguavaju postizanje najboljeg rjeenja. Takoer mogu umanjiti primjenu komercijalnog softvera i komponenti u rjeenju. Neka ogranienja mogu pomoi u zadovoljavaju atributa kvalitete. Primjer je poboljanje prenosivosti programa koritenjem samo standardnih naredbi nekog raunalnog jezika.
Definicije podataka
Definicija podataka je bilo koji opis formata, dozvoljenih vrijednosti, pretpostavljenih vrijednosti ili kompozicija sloenih podatkovnih struktura. Sve definicije bi trebalo pohraniti u rjenik podataka, kao glavno kazalo za sudionike na projektu.
Poeljno svojstvo - Funkcije koje korisnik eli na kraju imati

Ranije verzije sustava mogu pruiti (ne potpunu) funkcionalnost bez tih zahtjeva. Poeljni zahtjevi mogu i trebaju biti rangirani.
Ideje o rjeenju
Ako korisnik opisuje specifian nain interakcije sa sustavom kojom bi mogao obaviti neku akciju, npr. Korisnik odabire podatak koji on eli iz padajue liste, on predlae rjeenje, a ne zahtjev. Predloeno rjeenje moe odvui panju od pravih zahtjeva. Kod postavljanja zahtjeva treba se usmjeriti na ono to je potrebno obaviti, a ne na nain realizacije. Treba istraiti zato korisnik predlae odreenu ugradnju jer to moe pomoi u razumijevanju stvarne potrebe i korisnikovih oekivanja o nainu kako bi sustav trebao raditi.
Neobvezna svojstva - Proizvoljni zahtjevi

Svojstva i mogunosti bez kojih se moe. Iako bi ih lijepo bilo imati, to nisu pravi zahtjevi. Ovi zahtjevi takoer mogu biti rangirani.
Dokumentiranje analize (zahtjeva)

Definicija zahtjeva (Requirements Definition)
izjava o stanju i ogranienjima sustava te potrebama narativni dokument namijenjen korisniku ili ga pie korisnik poslovni i korisniki zahtjevi te njihovi prioriteti uoeni problemi, kljune pretpostavke i preporuke rjeenja
Predloak dokumenta specifikacije zahtjeva

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

esto se naziva i funkcionalnom specifikacijom strukturirani dokument s detaljnim opisom oekivanog ponaanja sustava namijenjen ugovarateljima i izvoditeljima razvoja ugradbeno nezavisan pogled na sustav funkcionalni i nefunkcionalni zahtjevi te njihovi prioriteti model organizacijske strukture (strukturni dijagrami) opis protoka dokumenata (dijagrami toka) model procesa (dijagram toka podataka) konceptualni model podataka (dijagram entiteti-veze)
Primjeri:
\Analiza\ProtokDokumenata, RazmjenaPodataka \Dokumentacija\
106
Rizici loeg planiranja zahtjeva

Nedovoljna ukljuenost korisnika bez korisnika ne moe se tono znati to korisnici ele neprihvatljivi proizvodi udni korisniki zahtjevi neopravdana promjena miljenja tijekom izvedbe prekoraenja rokova i degradacije kvalitete proizvoda Nejasni (dvosmisleni) zahtjevi situacija u kojoj itatelj(i) zahtjeva zahtjev tumae na vie naina gubljenje vremena i prepravljanje Pretjerano ukraavanje elja izvoaa da dodaju novu funkcionalnost "koja bi se trebala svidjeti korisnima" i zahtjev korisnika za dodacima koji dobro izgledaju ali ne pridonose funkcionalnosti nepotrebni dodaci i gubljenje vremena Minimalistike specifikacije tendencija postavljanja minimalnih zahtjeva ili skiciranja koncepta, uz elju da ih izvoai nadopune tijekom izvedbe frustracije izvoaa, neispunjena oekivanja korisnika Zanemarivanje potreba zanemarivanje potreba odreenih (grupa) korisnika stvaranje 'opozicije' projektu
Svojstva dobro postavljenih zahtjeva

Svojstva dobrih izjava o zahtjevima [IEEE, 1998]
Potpunost (cjelovitost) Tonost Ostvarivost (izvodljivost) Nunost Poredak po prioritetima Nedvosmislenost Mogunost provjere
Svojstva dobrih specifikacija zahtjeva

Potpunost Konzistentnost Mogunost izmjene Mogunost praenja
Cilj je napisati dovoljno dobre zahtjeve, na temelju kojih se moe pristupiti dizajnu i ugradnji uz prihvatljiv stupanj rizika. Nedovoljno definirani zahtjevi
Ponekad nedostaju informacije o nekom zahtjevu. Takve zahtjeve treba dosljedno oznaiti posebnom, dogovorenom oznakom npr. TBD (engl. To Be Determined - za odluiti, razluiti). Dokument se kasnije moe pretraivati po tim oznakama. Implementaciju ovakvih zahtjeva treba odgoditi do razrjeenja nedoumice ili barem treba dizajnirati one dijelove sustava koje je lako promijeniti kad se zahtjev konano definira. U suprotnom e programeri zahtjev ugraditi prema vlastitom nahoenju, koje ne mora biti tono.
107
108
Analiza i modeliranje sustava

Na temelju izjava korisnika i prikupljene dokumentacije modeliraju se pojedine komponente sustava (procesi, podaci, dogaaji)
Mogua su preslikavanja uoenih imenica i glagola u konkretne elemente modela kakvi e biti opisani u nastavku.
Tip rijei Imenica Primjer Ljudi, organizacije, softverski sustavi, podatkovne jedinice, ili postojei objekti Akcije, ono to korisnik moe poduzeti, ili dogaaji koji se mogu dogoditi Komponente analitikog modela Terminatori ili spremnici podataka (DFD) Entiteti ili njihovi atributi (ERD) Razredi ili njihovi atributi (dijagram razreda) Procesi(DFD) Odnosi (ERD) Prijelazi (iz stanja u stanje) (STD) Metode razreda (dijagram razreda)
Preporuke za analizu
Tehnike i pomagala ne znae puno bez ispravnog pristupa.
Postupak analize mora biti prilagoen korisniku. Kljuno je razumjeti sutinu organizacije i nain poslovanja Primjer: \Analiza\ PreporukeZaAnalizu
Slika: Awad, 1985; preveo Anonymous (WWW)
Ono to korisnik eli esto nije i ono to korisnik stvarno treba!

Da se pria o klasinom razvoju ne bi ponavljala, rade se modeli sustava (postojei fiziki i logiki, budui logiki).
Glagol
Paraliza analize
Postupak ponavljanog modeliranja postojeeg sustava i vrednovanja modela moe utroiti znaajno vrijeme na modeliranje neega to e vjerojatno biti izmijenjeno ili zamijenjeno. Ne pretjerivati s modeliranjem postojeeg sustava!
"Kemiar ili lan osoblja kemijskog laboratorija moe podnijeti zahtjev za jednom ili vie kemikalija. Zahtjev moe biti udovoljen ili dostavom pakiranja kemikalije koja se ve nalazila na zalihi kemijskog laboratorija ili upuivanjem narudbe za novim pakiranjem kemikalije od vanjskog dobavljaa. Osoba koja upuuje zahtjev mora imati mogunost pretraivanja kataloga kemikalija vanjskog dobavljaa dok sastavlja narudbu. Sustav mora pratiti status svakog zahtjeva za kemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Takoer, mora pratiti povijest svakog pakiranja kemikalija od trena kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbaen."
110
Modeliranje procesa i funkcija

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

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

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

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

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

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

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

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

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

Task1.1.2 Task1.2.2 Task2.1.2 Task2.2.2
Proces
Task1.1.3
Task2.1.3
Task2.2.3
Task2.1.4
115
116
Dijagram dekompozicije funkcija

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

Izrada globalnog modela funkcija moe zapoeti izradom hijerarhijske liste funkcija po pojedinim organizacijskim cjelinama. Primjer:
NABAVA Evidentiranje dobavljaa Nabavka robe
Nabava
Knjigovodstvo
Prodaja
Izrada narudbi Zaprimanje robe

Prodaja robe
Evi denti ranje dobavljaa
Naruivanje robe
Knjienje
Evi denti ranje kupaca
Fakturiranje
UPRAVLJANJE OSOBLJEM Evidentiranje slube

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

Postupak
Korijen = sustav Razrada u podsustave i poslovne funkcije Daljnja razrada do razine operacionalizacije
Dijagram dekompozicije procesa

Primjer, stablo procesa (Process Node Tree Diagram)
USED AT: AUT HOR: Norm Wold PROJECT : Reengineering Quill Computers, Inc. NOT ES: 1 2 3 4 5 6 7 8 9 10 DAT E: 05.09.1997 REV: 09.11.2000 WORKING DRAFT RECOMMENDED PUBLICAT ION READER DAT E CONTEXT: T OP A-0
Pravila
svaki proces je roditelj ili dijete roditelj mora imati barem dvoje djece po veini standarda, dijete smije imati samo jednog roditelja
Sell & Market Products
$1,103,222 1
Operate QU ILL Busines s

$8,207,581 0
Design Conf iguration

$690,235 2
Plan Production
$628,802 3
As semble Product
$3,540,136 4
Store & Ship

$1,412,889 5
Preporuke
izostaviti procese koji samo premijetaju ili preusmjeravaju podatke, a da ih pri tom ostavljaju nedirnute panju usmjeriti na procese koji neto raunaju (npr. prosjek ocjena) donose ili potpomau odluke (npr. odreivanje raspoloivosti robe pri naruivanju) filtriraju ili sumariziraju podatke (npr. rauni kojima je istekao rok plaanja) organiziraju podatke u korisne informacije (npr. generiranje izvjea) pokreu druge procese (npr. mijenjaju modalitet rada stroja) rukuju podacima (npr. stvaranje, itanje, auriranje, brisanje) - Ne pretjerivati!
Prov ide Custom er Support

$832,297 6
Manage Adv ertising Tak e Orders Prov ide Pricing Inf orm ation Dev elop Docum entation Prepare W ork Tic ket
Identif y Vendors & Components
Order As sem bly Components Issue W ork Dev elop Ticket Specif ic ations Manage Specif y Component Components Inv entory Tes t Schedule Conf iguration Production Approv e Dis pose Vendors Outdated Component Parts
Populate Motherboards As semble Conf igure Perf orm Final Tes t Troubleshoot & Repair Prepare Order f or Shipment
Receiv e & Answer Support Store Inquiries Components Trace Order & Pick Order Spec if ications Items Run D iagnostics Pack age Prov ide Order Solutions Ship Manage Returns Return Def ectiv e Parts
NODE: A0
T IT LE:
Process Node Tree Diagram
NUMBER:
120
Dijagram organizacije
Shema, mapa, karta organizacije (Organization chart)
prikaz strukture organizacije hijerarhijom kutija ("kuica") svaka kutija reprezentira odreenu ulogu ili odgovornost u organizaciji
Modeliranje poslovnih procesa i funkcija

Business Process Modeling (IDEF0)
tehnika strukturirane analize i dizajna (Structured Analysis and Design Technique - SADT, SofTech, 1960-ih), zamiljena kao inenjerska disciplina za razvoj sloenih sustava koji ukljuuju strojeve i ljude metoda za oblikovanje poslovnih funkcija
Grafiki prikaz poslovnih procesa i angairanih resursa

proces niz aktivnosti (funkcija) aktivnost prikazana ICOM konceptom ulaz (I=Input): neto to se troi u procesu - opcionalan upravljanje (C=Control): ogranienje na obavljanje procesa - obvezno izlaz (O=Output): rezultat procesa obvezan mehanizam (M=Mechanism): koristi se u procesu, ali se ne troi opcionalan
121
122
Oblikovanje aktivnosti
Oblikovanje sustava hijerarhijom ugnijedenih aktivnosti Aktivnost konteksta - vrh hijerarhije, predstavlja itav sustav
USED AT : AUT HOR: PROJECT : Proc es s Orders NOT ES: 1 2 3 4 5 6 7 8 9 10 DAT E: 05.09.1997 REV: 05.09.1997 W ORKING DRAFT RECOMMENDED PUBLICATION READER DAT E CONTEXT : T OP
Oblikovanje aktivnosti
Dekompozicija aktivnosti
USED AT: AUTHOR: PROJECT: Process Orders NOTES: 1 2 3 4 5 6 7 8 9 10 DATE: 05.09.1997 REV: 05.09.1997 WORKING DRAFT RECOMMENDED PUBLICATION Order Policy READER DATE CONTEXT: A-0 Customer Status
Viewpoint: Order Clerk Scope: New Customer Orders
New Customer Information

Order Policy Cus tomer Status
TAKE CUSTOMER ORDER 1
Product Request(s)
CHECK PRODUCT AVAILABILITY 2

New Cus tomer Information Order Num ber
Available Products DOCUMENT ORDERED PRODUCTS 3 Current Per Unit Prices
Products Ordered
Quantities Ordered
PROCESS ORDERS
Paym ent Verification 0 Produc t Order System On-line Produc t Catalog Cus tomer Credit Rec ords
Pac king Slip Order Invoice
Payment Verification
DETERMINE PAYMENT METHOD 4
Finalized Order Information
Produc t Inventory
POS (Order Module) On-line Product Catalog NODE: TITLE: A0 Product Order System PROCESS ORDERS
POS (Credit Module)
PROVIDE ORDER VERIFICATION 5
Order Number Packing Slip Order Invoice
Com pare this viewpoint with the OrdrProd.bp1 file. T his is an
Product Inventory
Customer Credit Records NUMBER:
POS (Order Module)
123
124
Razrada poslovnih procesa

Radna procedura, poslovna procedura (workflow)
slijed koraka obrade koji u potpunosti obrauje jednu poslovnu transakciju definira logiku obrade i precizira nositelja moe imati vie varijanti (scenarija)
Modeliranje toka procesa

Metoda Process Flow Modeling (IDEF3)
strukturirana metoda za opis poslovne situacije ureenim slijedom dogaaja i objekata koji u njoj sudjeluju prikazuje slijed, zavisnost i konkurentnost aktivnosti prikladna za prikupljanje informacija tijekom analize i dizajna poslovna politika i poslovne procedure preoblikovanje poslovnih procesa modeliranje scenarija kojima se odgovara na pitanja "to-ako"
Tehnike modeliranja
u irinu - svaki dijagram se detaljizira prije dekomponiranja (breadth-first) u dubinu - identificira se hijerarhija, a zatim se detaljizira (depth-first)
Razina dekompozicije (Kada stati)

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

Veze izmeu funkcija
prethoenje - prethodna aktivnost mora zavriti da bi slijedea zapoela tok podataka - izlaz prethodne jest ulaz u slijedeu aktivnost relacijska - povezivanje uz korisniki definirani uvjet
U SED AT: AU THOR : Bob Saunders
Primjer toka procesa

Primjer, provjera narudbe
D ATE: 06.05.1999 R EV: 22.10.1999 WOR KIN G D RAFT R ECOMMEN D ED N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A42 R EADER D ATE C ON TEXT: PR OJ EC T: It's not jus t ID EF any more.
Prijelazi, spojita (junction)

& (logiki I) - svaka povezana aktivnost uvijek se obavlja / zavrava X (ekskluzivno ILI) - obavlja se samo jedna od povezanih aktivnosti O (ILI) - obavlja se jedna ili vie povezanih aktivnosti
Yes $0.00 C us tomer $0.00 C uts omer Enquiry /Or der Is C us tomer Plac es Order C redit Wor thy ? A422.1.11 A422.1.12 $0.00 Sourc e els ewher e? No A422.1.15 No No $0.00 N otify s ales A422.1.14 Ac c ount s tatus C hange $0.00 R ejec t Or der A422.1.16
$0.00 Fulfill from s toc k items ? A422.1.13 No
Yes
$0.00 Is s toc k av ailable? A422.1.17 Yes
$0.00 Yes Ac c ept or der A422.1.18
127
128
Primjer toka procesa

Primjer, modeliranje scenarija
USED AT : AUT HOR: Norm Wold PROJ ECT : Reengineering Quill Computers, Inc . NOT ES: 1 2 3 4 5 6 7 8 9 10 CCN DAT E: 06.11.2000 REV: 09.11.2000 WORKING DRAFT RECOMMENDED PUBLICATION READER DAT E CONT EXT : A12 Bad Credit List
Dijagram aktivnosti
Activity Diagram
tehnika za oblikovanje procedura koja se najee koristi u projektiranju objektnim pristupom.
$0 Pass CCN Chec k 4 true
$0 Chec k CCN 2 $0 Chec k Credit 1

original
X J2
false
$0 Fail CCN Chec k 6
& J4
$0 Set Credit Rating Low 9
& J1
$0 Chec k Dunn & Bradstreet 3 true $0 Pass D&B 5 $0 Set Credit Rating High 8
X J3
& J5
$0 false Fail D&B 7 Dunn & Brads treet
Customer
129
130
Dijagram aktivnosti
Primjer dijagrama aktivnosti
Modeliranje toka podataka

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

Ne moe se koristiti za opis programske logike, opis promjene stanja, izradu upravljakih specifikacija ili dizajn korisnikog suelja!!!
Koristi se pri modeliranju poslovnih procesa

daljnja razrada IDEF0
IDEF3 (zavisnost procesa) ili DFD (tok informacija)

132
Elementi dijagrama toka podataka

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

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

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

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

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

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

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

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

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

uspostaviti razinu detalja slijedei pravilo 72 provjeriti potpunost i ispravnost modela
Model obrazloiti korisniku a zatim ga aurirati po potrebi

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

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

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

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

DTP se ne smije tumaiti
140
Metode koje koriste DTP

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

Notacija = struktura s lijeva sastoji se od dijelova s desna ("sastavljeno od") + agregacija elemenata (logiko I) ( ) opcionalnost elemenata u zagradi (0 ili 1) {} ponavljanje (iteracija) elemenata u zagradi, ni jednom do konani broj puta [] alternativa (selekcija) elemenata u zagradi odvajanje alternativnih elemenata u [] izrazu | poena i zavrna vrijednost raspona definiranog [] izrazom ** komentar @ oznaka kljua Primjer, raun i stavke rauna
Racun = @BrRac + DatRac + BrKupca + { SifArt, NazArt, Cijena, Kol, Vrijednost } + (IznosRac) Racun = @BrRac + DatRac + BrKupca + { StavkaRac } + (IznosRac) StavkaRac = @SifArt, NazArt, Cijena, Kol, Vrijednost
143
Elementarni procesi
Mini-specifikacije (funkcionalne primitive)
specifikacije za opisivanje osnovnih procesa u dijagramu toka podataka mogu poprimiti razliite oblike, ali imaju nekoliko zajednikih elemenata: naziv i broj procesa listu podataka koji ulaze u proces (ulaznih tokova podataka) listu podataka koji iz procesa izlaze (izlaznih tokova podataka) tijelo opisa procesa
Opis procesa
sadri algoritam zadatka koji se procesom obavlja, koji moe poprimiti razliite oblike ( dizajn programa - opis programske logike) na temelju ovog algoritma moe se, ovisno o alatu, generirati kd
Moe se napisati i kao:
Mini-specifikacije kreira korisnik CASE pomagala.

Budui da se ne kreiraju automatski na temelju prethodno unesenih opisa (modela procesa i modela podataka), neosjetljive su na izmjene dijagrama!
Definiranje procesa
Primjer definicije procesa (1)
Proces 1: Opis: Ulazni tokovi: Provjera raspoloivosti filma Provjera da li u videoteci postoji kopija filma koja se moe iznajmiti Upit (Film) Rezervacije Posudbe Izlazni tokovi: Logika procesa: Rezultat upita (raspoloiv | nije raspoloiv | ne postoji) izraunaj broj kopija traenog filma u videoteci ako je broj kopija vei od nule tada ako je broj kopija vei od (broj posudbi + broj rezervacija rezultat = "Raspoloiv" inae rezultat = "Nije raspoloiv" inae rezultat = "Ne postoji"
Definiranje procesa
Primjer definicije procesa (2)
Proces 1: Opis: Ulazni tokovi: Izlazni tokovi: Logika procesa: Provjera raspoloivosti filma Provjera da li u videoteci postoji kopija filma koja se moe iznajmiti Upit (Film), Rezervacije, Posudbe Film nije raspoloiv, Film je raspoloiv izraunaj broj kopija traenog filma u videoteci ako je broj kopija vei od nule tada ako je broj kopija vei od (broj posudbi + broj rezervacija nastavi s P2 (izl. tok Film je raspoloiv) inae ako lan eli rezervirati film tada upii rezervaciju (izl. tok Film nije raspoloiv) inae poruka "Ne postoji"
145
146
Primjer definiranja procesa jednostavnim CASE alatom

Specifikacija procesa u pomagalu EasyCase
@BeginHeader @Text File : C:\ECPLUS\SAMPLES\GSDFD\pps21.pps @Linked to symbol : Package Order @on dfd Ship Order (Filename : dfd2.dfd) @--------------------------------------------a @OUTPUT DATA FLOW : Customer Invoice Customer @OUTPUT DATA FLOW : Customer Shipment @OUTPUT DATA FLOW : Unavailable Items Customer @INPUT DATA FLOW : Customer Ship Address Invoice @INPUT DATA FLOW : Order Details D4 Stock @INPUT DATA FLOW : Stock P2.1 @--------------------------------------------Packag e Ship Address @EndHeader Order TBD
D1 Customer
Primjena modela procesa

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

analiza i restrukturiranje poslovnih procesa radi poboljanja uinkovitosti i uklanjanja birokratizma, prije primjene informacijskih tehnologija postojei procesi se analiziraju i dokumentiraju prikladnim modelima procesa dijagrami doka podataka s fizikalnim primjesama, koje ukljuuju vremensku dimenziju, protonost podataka i trokove
Customer Shipment Unavailable Items
Analiza sustava
P2.2 Create Back Order
aplikacijski modeli procesa - logiki modeli procesa sustava ili aplikacije teorijski, mogue je proizvesti DTP povratnim inenjerstvom postojeih aplikacija, ali e takav dijagram biti preoptereen fizikalnim primjesama
Dizajn sustava
D2 Order D etails
fiziki modeli procesa - dodavanjem upravljakih komponenti i resursa

Tablini prikaz modela funkcija/procesa

USED AT: AUTH OR: Bob Saunder s PROJ EC T: It's not jus t IDEF any mor e. NOTES: 1 2 3 4 5 6 7 8 9 10 DATE: 03.04.1996 REV: 04.11.2002 DR AFT
Povezivanje razliitih modela

WORKIN G REC OMMEND ED PUBLICATION A0 READ ER DATE CONTEXT:
Prikupljanje i sreivanje informacija o funkcijama i procesima moe se obaviti s pomou tablica prije, ali i umjesto izrade dijagrama.
Customer Enquiry/Order Enquiry Feasibility (Resources)
Customer Contracts
GO Process Management Information Product Enquiry
Product Specification Feasibility
Manage Customer Queries

$4.00 A41
Customer Communication
Primjeri: \Modeli\ModeliProcesa Dijagram toka podataka

U SED AT: AU THOR : Bob Saunders PR OJ EC T: It's not jus t ID EF any more. N OTES: 1 2 3 4 5 6 7 8 9 10 3 PR OD U CT D ATE: 26.01.1998 R EV: 22.10.1999 WOR KIN G D RAFT R ECOMMEN D ED PU BLIC ATION A4 R EADER D ATE C ON TEXT:
Customer Information Credit Worthiness
Qualify Customer Order

$29.90 A42
Aut horised Order
Accept/ Release Order

$5.90 A43
Product O rder
Order/Enquiry Status SOP Module
Proces Izraditi narudbu
Ulaz (od) Podaci o dobavljau, Artikli za naruiti
Izlaz (prema) Ispisana narudba (dobavlja)
Vanjski entitet Dobavlja
Spremite Narudba, Dobavlja, Stavka, Artikl
Komentar/Algoritam Struktura tokova ne mora u potpunosti odgovarati strukturi spremita

NODE: TITLE:
Manage Order/Enquiry
NU MBER:
A4
Model poslovnih procesa

$0.00
Authoris ed Order
Av ailable Stoc k
4 STO CK
Alloc ated s toc k
A431 Stoc k R equir ement
$0.00
A432
Accept Order Spec
Check Stock Availabl e
Alloc ated s toc k
Zaprimanje u slubu
Zahtjev za prijam (osoba)
Rjeenje zahtjeva (osoba, pismohrana)
Osoba
Osoba, Tijek slube Provjeri zahtjev prema Pravilniku o zapoljavanju, pa ispie rjeenje
C us tomer C ommunic ation $0.00 A433
2 ORD ER D ETAILS
Allocate Stock
$0.00 C us tomer C ommunic ation 4 C USTOMER
A434
1 C USTOMER
Release and Shi p Stock
Produc t Order
N OD E:
TITLE:
Accept/ Release Order
N UMBER :
A43
149
150
Primjer dijagrama iz stvarnog projekta
Izrada DTP analizom izjava korisnika

laboratorija pretraivanje dobavljaa Kemiar "Kemiar ili lan osoblja kataloga dobavljaa upit na katalog dobavljaa zahtjev kemijskog laboratorija moe pakiranje pakiranje za kemikalijom kemikalija kemikalija podnijeti zahtjev za jednom ili vie novo stanje inventorija informacija o katalogu zahtjev za kemikalijom dobavljaa kemikalija. Zahtjev moe biti 6. auriranje udovoljen ili dostavom pakiranja stanja zaliha laboratorija 1. informacija o katalogu kemikalije koja se ve nalazila na katalog podnoenja dobavljaa dobavljaa zahtjeva za zalihi kemijskog laboratorija ili kemikalijom 2. pakiranje ispunjavanje upuivanjem narudbe za novim kemikalija novo stanje inventorija zahtjeva iz zaliha pakiranjem kemikalije od laboratorija zahtjev za informacijom vanjskog dobavljaa. Osoba koja pakiranje inventorij kemijskog upuuje zahtjev mora imati kemikalija laboratorija mogunost pretraivanja kataloga laboratorijski zahtjev zahtjev status dobavljaeve narudbe za kemikalijom kemikalija vanjskog dobavljaa podaci stanje inventorija o promijenama dok sastavlja narudbu. Sustav u inventoriju zahjev za dobavljaevom mora pratiti status svakog zahtjeva 5. kemikalijom generiranje izvjea o za kemikalijama od trenutka kad je 3. 4. stanju zaliha podnoenje generiranje ispunjen do trenutka kad je zahtjeva za izvjea za kemikalijom vladu udovoljen ili otkazan. Takoer, mora izvjee o pratiti povijest svakog pakiranja zahjev za dobavljaevom uporabi zahtijev za status kemikalija kemikalijom dobavljaeve izvjeem o kemikalija od trena kad stigne u uporabi kemikalija narudbe kompaniju do trenutka kad je potpuno upotrijebljen ili odbaen." Odjel za Vladin odjel za sigurnost i kupovinu zdravlje 7. informacija o katalogu Osoblje kemijjskog
izvjee o stanju inventorija
151
152
Primjer: Procesi sustava ISSP

ISSP se moe podijeliti na slijedee funkcionalne cjeline:
lanice sveuilita i veleuilita, iji studenti ostvaruju pravo na subvencioniranu prehranu (ustanove) Restorane koji pruaju uslugu prehrane prehranu lanovima ustanove (mjesta troka) Tvrtka zaduena za odravanje i nabavu opreme te tiskanje iskaznica lanova Centar za autorizaciju prava lanova (CAP), kao ustanova zaduena za uvoenje i trajno odravanje sustava. U CAP-u se nalazi i sredinja baza podataka sustava.
b d SC i ostali pruzatelji usluge Pokrovitelj subvencije
Primjer: razrada procesa

Evidencija matinih podataka lanova
Obvezni matini podaci studenta su: Ime, Prezime, JMBG, Matini broj (broj indeksa), Razina prava, JMBAG Omogueno je evidentiranje i ostalih neobveznih podataka
P1
Pregled potrosnje restorana
Pregled potrosnje restorana
P4
Zatrazena kartica
P2
Zatrazena kartica Vlasnik
Evidencija podataka o statusu lana u ustanovi

Evidentiran upis godine sadri podatke o:
Zahtjev za dokumentaciju Zahtjev za izdavanje kartice Zahtjev za promjenu razine prav
Tvrtka za tiskanje Nova kartica
CAP
Upis godine Nova kartica
Ustanova
Nova kartica
Dozvoljeno za subvenciju Nacinjen racun (dnevnik)
Kartica
Vlasnik
Nova kartica
Upisni list
P1.1 Upisni list Upis novog vlasnika (studenta)
P1.2 P1.5 Upis godine Izdavanje kartice vlasniku Nova kartica
P3
a Kartica Vlasnik (student) Dokumentacija
Restoran
Vlasnik Zahtijev za promjenu razine prav
Vlasnik
Upis godine Kartica
P1.3 Promjena razine prava vlasnika Vlasnik D1 Vlasnik D3 Upis godine D2 Kartica
Unutar svake od navedenih cjelina obavlja se vie specifinih procesa koji ine osnovu sustava.
Zahtjiev za dokumentaciju Dokumentacija
P1.4 Vlasnik Obrada zahtjeva za karticu Kartica
153
154
p8
vraeni artikli
Dobavljai
narudba ulazni raun isplata dobavljau
predraun/raun uplata kupca
Kupci
promjena koliine
narudbenica raun uplata artikl
Skladino poslovanje nalog za povrat artikla
narudbenica skladina primka dobavlja
D4
dokumenti
skladina primka nalog za povrat artikla dobavljau povratnica dobavljau
nalog za meuskladitenje meuskladinica otpremnica povratnica kupca nalog za interno izdavanje artikla interna izdatnica interna povratnica
p1 Narui artikle
p2 predraun otpremnica artikl D1 artikli i usluge uplate raun predraun Izrada rauna
artikl usluga
p3 Izrada otpremnice
dobavlja
p4 poslovni partneri cijena kupac Izrada ponude raun
D7
Stanje skladita
c artikli povrat artikla Skladita
artikli povrat artikla artikli povrat artikla
p9 promjeni koliinu Otpremanje artikala otpremi artikle zahtjev za ponudu predraun artikl d Kupac
155
raun
D2
156
promjeni koliinu
Radne jedinice
zaprimljeni artikli
D5
cijene artikala
meuskladinica
p0
Proces izrade ponude vodi sluba prodaje. Na zahtjev kupca sluba nabave izrauje ponudu/predraun. Podaci o kupcu dohvaaju se iz spremita poslovnih partnera, a artikli i usluge dohvaaju se iz spremita artikala i usluga. Izraena ponuda sprema se u spremite dokumenata, a kopija se ispostavlja kupcu. Raun je dokument koji kao potvrdu podmirivanja potraivanja od kupca izdaje sluba prodaje. Raun se izrauje iz predrauna, sprema se u spremite dokumenata, a kopija se alje kupcu. Otpremnica kupcu skladini je dokument na osnovu kojeg se izdaju artikli sa skladita. Izrauje se na osnovu rauna i sprema u spremite dokumenata.
Interno izdavanje i povrat artikala
poslovna jedinica
D3
poslovne jedinice
b Poslovne jedinice
nalog za povrat interna povratnica
p5 a Dobavljai potvrda o povratu artikl Povrat artikala dobavljau
intera izdatnica
povratnica dobavljau
Meuskladitenje artikl
artikl
artikl
skladite
p7
meuskladinica artikl
izdani artikli
Primjer: Sustav skladinog poslovanja
Primjer: Osnovni procesi
Skladita
nalog za izdavanje
Prijem i povrat artikala
p6
Dekompozicija procesa narudbe i prijema artikala

p1.4 Izradi ulazni raun skladina primka ulazni raun narudbenica D4 dokumenti
Dekompozicija procesa internog izdavanja i povrata artikala

p8 izdani artikli Prijem i povrat artikala vraeni artikli b Radne jedinice
p1.1 Izraditi narudbenicu
promjena koliine artikla
Interni povrat
interna povratnica
Promjeni koliinu
narubenica dostavnica
a Dobavljai
p6.2 Zaprimanje naloga
D6
nabavne cijene
cijena
p1.2 dobavlja dobavlja artikl Preuzmi artikl
D7
stanje skladita
p6.3 Izrada interne povratnice
artikl
D6
nabavne cijene nabavna cijena
preuzeti artikli
cijena
D1
artikli i usluge
promjena nabavne cijene
interna povratnica
nalog
nalog
D7
stanje skladita
D3
poslovne jedinice
p1.3 D2 poslovni partneri skladite dobavlja Izraditi skladinu primku skladina primka
p1.5 dobavlja Isplati dobavljaa
Proces narudbe vodi sluba nabave koja na osnovu praenja stanja skladita i potreba na tritu odluuje o nabavi artikla. Nabavna sluba izrauje narudbenicu koja se zatim alje dobavljau. Dobavlja na temelju isporuene narudbenice ispostavlja predraun s naruenim artiklima. Na temelju predrauna nabavna sluba izrauje ulazni raun, a isplatom potraivanja dobavljau artikli se zajedno s dostavnicom primaju na skladite. Na skladitu se poveava koliina te ako je potrebno mijenja se nabavna cijena. Naposljetku, ova poslovna promjena biljei izradom skladine primke koja se zatim sprema u spremite dokumenata.
157
p6.4
isplata dobavljau ulazni raun ranije isplate po istom ulaznom raunu
D1
artikli i usluge radna jedinica skladite
artikl artikl
c D4 dokumenti Skladita interna izdatnica
p6.1 radna jed. skladite Izrada interne izdatnice
D3
poslovne jedinice
nalog interna izdratnica
Proces povrata artikala dobavljau takoer vodi nabavna sluba. Dobavlja na temelju vraenih artikala izdaje potvrdu o povratu na osnovu koje se izrauje povratnica dobavljau. Povratnica dobavljau sprema se u spremite dokumenata. Interno izdavanje i povrat artikala koristi se kod prijenosa artikala izmeu skladita i radne jedinice. Proces zapoinje prijemom naloga. U sluaju internog izdavanja artikala nalog prima skladite koje artikle treba izdati u radnu jedinicu, dok u sluaju internog povrata nalog prima radna jedinica koja treba vratiti artikle u skladite. Naloge za izdavanje u pravilu ispostavlja priprema rada, odnosno referada za otvaranje i praenje provoenja radnih naloga, poslovoe ili sam vlasnik. Na temelju primljenog naloga izrauje se interna izdatnica koja se prosljeuje skladitaru dok se interna povratnica izrauje se na temelju artikala vraenih iz radne jedinice. Dokumenti interna izdatnica i interna povratnica dokazuju izvrenu poslovnu promjenu i pohranjuju se u spremitu dokumenata.
158
plaanje
Dekompozicija procesa meuskladitenja artikala

D6 Meuskladitenje artikala koristi se kod prijenosa artikala izmeu dva skladita unutar istog poduzea, a proces meuskladitenja prate dvije meuskladinice po jedna za svako od skladita. Skladite koje daje artikle prima od poslovoe ili vlasnika nalog za meuskladitenje na osnovu kojeg izdaje artikle. Izdavanjem artikala njihova se koliina na skladitu smanjuje, a kao dokaz izvrene poslovne promjene izrauje se dokument meuskladinica. Drugo skladite zaprimanjem artikala prima i meuskladinicu potvrdom koje potvruje primljene koliine. Skladite koje prima artikle na osnovi primljenih artikala takoer izrauje meuskladinicu. cijena nabavne cijene cijena
D3
poslovne jedinice
meuskladinica
D4
dokumenti
p7.1 skladite koje daje artikle skladite koje prima artikle artikl Izrada meukladinice izdani artikli
promjena koliine
Modeliranje podataka
D1
artikli i usluge promjena koliine artikla na skladitu koje daje
p7.2 Izdavanje artikla
izdani artikli
c skladite koje daje artikle skladite koje prima artikle izdani artikli Skladita
D7
Stanje skladita
nalog
p7.3 artikl promjena koliine artikla na skladitu koje prima Prijem artikla primljeni artikli
p7.4 Izrada meukladinice
primljeni artikli
159
meuskladinica
Modeliranje podataka
Modeliranje podataka (Data modeling)
tehnika organiziranja i dokumentiranja podataka sustava sinonimi: modeliranje baze podataka (podaci se najee pohranjuju u BP) modeliranje informacija (openitije) (po mnogima) najvanija tehnika oblikovanja podaci su resurs koji se dijeli izmeu veeg broja procesa i zbog toga moraju biti organizirani na nain koji je prilagodljiv poslovnim zahtjevima kreativnost strukture podataka i njihova svojstva su trajniji i stabilniji od procesa modeliranje podataka zavrava bre nego modeliranje procesa
modeli podataka bre se pribliavaju rezultatu nego modeli procesa modeli podataka su bitno manji od modela procesa i objektnih modela
Dijagram entiteti-veze
Dijagram entiteti-veze
eng. Entity-Relationship Diagram, ERD naziva se jo i dijagram objekti-veze (izbjegavati!) postoje razliite notacije, npr. Chen, Martin osim osnovnih, koriste se i proireni modeli ne postoje jednoznani standardi postupka izrade
0,1 Mjesto Zanimanj e NadJed 1,1 1,N PodJed 0,N Stanuj e Osoba 1,N Zaposlen 1,N Or gJed 0,M Proizvodi Pri pada
0,N
modeli podataka postojeeg i budueg sustava meusobno su sliniji nego modeli procesa postojeeg i budueg sustava, ili ih je lake preoblikovati, pa se manje posla baca dobra komunikacija s korisnicima, utvrivanje nazivlja lake odreivanje definiranje dosega projekta ...
FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07. 161 FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.
1,1 0,N 1,1 Racun 1,1 Proi zvod NS 1,1 1,1 RacStRac OdnosiSeNa ES Di o 0,N Cj elina
0,M
Sastav
0,N 0,1 0,1
0,1
0,N
1,N 0,N
Djel atni k
Suradni k
StavkaRacuna
Igl a
Avion
162
Entiteti
Entitet (entity)
neto to postoji u stvarnom svijetu i posjeduje znaajke koje ga opisuju i po kojima se razlikuje od svoje okoline Stvar koja se moe zasebno identificirati [P. Chen, 1976] Bilo koji objekt koji se moe razlikovati i predstaviti u bazi podataka [C.J.Date, 1986] Logika reprezentacija podatka [C.Finkelstein, 1989] Bilo to o emu pohranjujemo informaciju [J.Martin, 1989]
Entiteti
Pojedinane pojave (instance) grupiraju se u skupove
ovisno o metodi skup entiteta (entity set), tip entiteta (entity type), razred entiteta (entity class) primjeri: osobe (Kit Karson, Sir Oliver, Alan Ford, ...) fakulteti (FER, FF, ...) u praksi se moe poistovjetiti pojam entitet sa skupom entiteta, ako se ne razmatraju konkretni podaci oznaava se imenicom (u jednini) Osoba, Fakultet
Entitet moe biti:

osoba, npr. Kit Karson objekt, npr. video traka Prohujalo s vihorom apstraktni pojam, npr. hrvatski jezik ili iskustvo (poznavanje jezika) ustanova (FER), organizacija (Hotel Proljee) ili organizacijska cjelina (Ured za istraivanje ruda i gubljenje vremena) dogaaj (situacija, stanje) - proli, sadanji ili budui, npr. roenje, kolovanje, zaposlenje, smrt povezanost razliitih objekata stvarnog svijeta, npr. srodstvo
Entiteti mogu poprimiti razliite uloge ovisno o kontekstu

primjer: Osoba je Kupac i/ili Dobavlja, Student ili Nastavnik
164
Atributi i domene
Atribut
atribut predstavlja neko obiljeje, znaajku entiteta sinonimi: svojstvo (property), element, polje (field) pojedinane 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 pojedinani podatak,
primjer: Prezime, Ime
Atributi i domene
Vrijednosti atributa definiraju
tip podatka, domena i pretpostavljena ili standardna vrijednost (default)
Tipovi podataka
netehniki (logiki) opi tipovi koji se koriste u sistem analizi i pri prikupljanju zahtjeva primjeri: broj, datum-vrijeme, znakovni niz, tekst, BLOB tehniki generiki tipovi podataka koji se mogu preslikati u konkretne tipove, npr. integer, character konkretni tipovi SUPB, npr. char, int, byte (SQLserver)
sloeni, sastavljeni atributi (compound/composite/concatenated attribute, data structure) - vrijednost je ureena n-torka ili logika grupa jednostavnih atributa,
primjer: datum = (dan, mjesec, godina)
vieznani atributi (multivalued attribute) - atributi koji predstavljaju ponavljajue grupe podataka, to jest atributi s vie 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 moe odrediti na temelju vrijednosti drugih atributa
primjer: starost = (DananjiDatum-DatumRoenja)
Standardna vrijednost atributa

vrijednost koja se zapisuje kada korisnik ne specificira vrijednost atributa openito, veina atributa trebala bi imati standardnu vrijednost
Atributi i domene
Domena
skup moguih vrijednosti koje nad njom definirani atributi mogu poprimiti domene mogu biti jednostavne i sloene (vrijedi i za atribute) nad svakom domenom moe se definirati po volji mnogo atributa skup vrijednosti moe se definirati tipom podatka, npr. integer podskupom vrijednosti tipa podatka, npr: formula AA99, interval [10-99] skupom konstanti, npr. Spol = { M, }
8746 37528 1164 ... Ford Karson Rock ... Alan Bob Kit ... Melrose place xx Sunset boulevard 2958 Vukovar avenue 63 ...
Kljuevi
Klju (key) ili identifikator
atribut ili skup atributa koji (svojim vrijednostima) jednoznano identificira svaki od entiteta u nekom skupu entiteta mora se sastojati od bar jednog atributa jednostavan klju
primjer: OSOBA = @JMBG + Prezime + Ime primjer: MJESTO = @ifraMjesta + NazivMjesta ...
moe se sastojati od vie atributa sloeni, sastavljeni, ulanani klju

primjer: MJESTO = @ifraDrave+@ifraMjesta
klju mora zadovoljavati sljedee uvjete jednoznanost (u skupu entiteta ne smiju postojati dvije pojave s istim vrijednostima svih kljunih atributa)
primjer: ne smiju postojati 2 osobe s JMBG=020946330097
minimalnost (ne postoji podskup atributa kljua koji je takoer jednoznaan)

primjer lo: OSOBA = @JMBG + @Prezime ... primjer dobar: TEAJ = @KraticaValute + @DatumTeaja + ...
Identifikator osobe (IdO sobe) 8746 37528 1164 765
Prezim e (Prezim e) K arson Ford Rock Ford
Im e (Im e) Kit Alan Bob Kit
Adresa (Adresa) M elrose place 666 Vukovar avenue 63 Sunset boulevard 2958
ifra m jesta (SifM jesta) 038 001 282

167
odreenost - postojanje vrijednosti u trenutku stvaranja instance stabilnost - otpornost na promjene tijekom vremena raspoloivost - dostupnost svim korisnicima neutralnost - s obzirom na znaenje vrijednosti kljua (samogovoree ifre)
168
Kljuevi
entitet moe imati jedan ili vie kljueva entitet mora imati barem jedan klju entitet moe imati vie moguih kljueva, tj. kandidata za primarni klju (candidate key), koji ne moraju biti meusobno disjunktni, tj. mogu imati atribute presjeka jedan od kljueva odabire se za primarni klju (primary key)
primjer: Osoba.IdOsobe, Mjesto.SifMjesta
Kljuevi
Strani klju (foreign key)
skup atributa koji se odnosi na klju drugog skupa entiteta, tj. skup atributa ije se vrijednosti odnose na vrijednosti kljua drugog entiteta (Osoba.SifMjesta odnosi se na Mjesto.SifMjesta)
Identifikator osobe (IdOsobe) 8746 37528 1164 765 Prezime (Prezime) Karson Ford Rock Ford Ime (Ime) Kit Alan Bob Kit Adresa (Adresa) Melrose place 666 Vukovar avenue 63 Sunset boulevard 2958 ifra mjesta (SifMjesta) 038 001 282
nakon odabira primarnog kljua, ostali mogui kljuevi postaju alternativni kljuevi (alternate key)
primjer: Osoba.JMBG, Mjesto.PostBr
ponekad je potrebno identificirati podskupove entiteta kriterij podskupa (subsetting criteria) atribut (jednostavni ili ulanani) s konanim skupom vrijednosti za grupiranje instanci entiteta u nepodskupove, u nekim metodama naziva se inversion entry jedinstveni indeks
ifra mjesta Potanski broj (SifMjesta) (PostBr) 038 10000 001 20000 282 30000
169 FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.
Naziv mjesta (NazMjesta) Zagreb NewYork Los Angeles

170
Kljuevi
Strani klju ukazuje na povezanost izmeu entiteta, odnosno skupova entiteta
moe poprimiti vrijednost primarnog kljua drugog entiteta ili moe poprimiti nul-vrijednost (null value)
Elementi dijagrama Entiteti-Veze

Primjer, atributi i kljuevi u oglednom modelu
primjer:
Osoba.SifMjesta odnosi se na Mjesto.SifMjesta, odnosno Entitet Osoba (IdOsobe=8746) ima SifMjesta=038, tj. referencira entitet Mjesto s IdMjesta=038
SifMjesta
PostBr
NazMjesta
IdOsobe
Prezime
Ime
Nul-vrijednost
Nul-vrijednost oznaava nepoznatu vrijednost atributa ili neodreenu vrijednost atributa, tj. nadomijeta 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 vozila (tipa tenk) koje se ne registrira na isti nain
Mjesto
Osoba
Adresa
SifMjesta
Staz
Telefon
172
Veze
Veza (relationship)
pokazuje odnos izmeu entiteta analogno entitetima, pojedinana veza uspostavlja se na razini instanci entiteta, a veze se grupiraju u skupove veza (relationship sets)
kada se ne razmatraju instance, pojam veza podrazumijeva skup veza
Veze
Stupanj veze (degree of relationship)
broj entiteta koji sudjeluju u vezi openito, moe se povezati bilo koji broj entiteta (oprez!) veza drugog stupnja binarna veza veza treeg stupnja ternarna veza openito, veza moe biti n-tog stupnja n-arna veza posebni sluaj jest veza nekog entiteta s tim istim entitetom veza prvog stupnja unarna veza (refleksivna, rekurzivna, involucijska) u nekim metodama smatra se posebnim sluajem binarne veze, to jest posebnom vezom 2. stupnja
moe izraavati ulogu entiteta koje povezuje imenuje 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)
Mjesto MjestoStan
Stanuje Stanovnik
Osoba
173
174
Veze
Tip, klasifikacija veze (type of relationship)
oznaava nain pridruivanja pojava entiteta u vezi jedan-prema-jedan (1:1) jedan-prema-vie (1:N)
moe postojati vie (paralelnih) veza izmeu dva entiteta
Veze
Primjer: binarna veza 1:N
Mjesto
1,1
Stanuje
0,N
Osoba
vie-prema-vie (M:N)
Modalitet veze (modality) i Kardinalnost veze (cardinality)

minimalni i maksimalni broj pojava jednog entiteta za pojedinanu pojavu s njim povezanog entiteta donja i gornja granica kardinalnosti donja granica moe biti 0, 1, pozitivni cijeli broj ili znak (npr. M)
donja granica = 0 djelomino, neobavezno (optional) pridruivanje ne mora imati niti jednu instancu s druge strane veze donja granica 0 potpuno, obavezno (mandatory) pridruivanje mora imati barem neki broj ili openito M instanci s druge strane veze
Primjer, binarna veza M:N
OrgJed
0,M
Proizvodi
0,N
Proizvod
gornja granica moe biti 1, pozitivni cijeli broj ili znak (npr. N)
moe imati konkretan broj ili openito N instanci s druge strane veze
veze su dvosmjerne pa se kardinalnost definira za oba smjera veze

Veze
Primjer, ternarna veza
Zanimanje 1,N 1,N 1,N
Specijalizacija/Generalizacija
takozvana "jest" veza (is a relationship) veza koja opisuje posebne sluajeve u nekom skupu entiteta, to jest odnos nekog entiteta (nadtip) i njegovih posebnosti (podtip) podreeni entiteti stvaraju se na temelju njima nadreenog entiteta u kojem dijele zajednike atribute nadtip (supertype) - sadri zajednike atribute i predstavlja generalizaciju podreenih entiteta podtip (subtype) - sadri samo njemu svojstvene atribute i predstavlja specijalizaciju nadreenog entiteta
0,M Cjelina
Osoba
Zaposlen
OrgJed
Primjer, unarna veza 1:N i unarna veza M:N

0,1 NadJed OrgJed PodJed 0,N
Pripada
Proizvod Dio
Sastav
0,N
B jest podtip od A ako: B jest uvijek A, A jest ponekad B Djelatnik je uvijek Osoba, Osoba je ponekad Djelatnik (Suradnik) Igla jest uvijek Proizvod, Proizvod jest ponekad Igla (Avion) specijalizacija moe biti: neekskluzivna - Osoba jest Djelatnik ili Suradnik, ali u isto vrijeme moe biti i Djelatnik i Suradnik ekskluzivna - Proizvod jest Igla ili Avion, ali ne moe istovremeno biti i Igla i Avion
Osoba 1,1 NS
Proizvod 1,1 ES
Jaki i slabi entiteti

Jaki entitet - entitet koji postoji (egzistira) samostalno, nezavisan/dominantan entitet, pr. Mjesto Slabi entitet (weak entity) postoji samo ako postoji jaki entitet u vezi, zavisan/podreen entitet egzistencijalno slab entitet - entitet koji ne postoji samostalno entitet sa stranim kljuem (pr. Osoba) identifikacijski slab entitet - entitet koji se ne identificira samostalno entitet koji nema vlastiti klju, nego se njegov klju tvori od kljua jakog entiteta i (opcionalno) vlastitog atributa (deskriptora), pr. Djelatnik, Suradnik, StavkaRacuna Identifikacijski zavisan entitet ujedno je i egzistencijalno zavisan. Egzistencijalno zavisan entitet nije ujedno i identifikacijski zavisan.
0,1 Djelatnik
0,N Suradnik
0,1 Igla
0,1 Avion
179
180

Primjer, egzistencijalno slab entitet Osoba
Nespecifine, neodreene veze

Asocijativni entitet (Gerund)
OrgJed 0,M Proizvodi 0,N Proizvod
Mjesto
1,1
Stanuje
0,N
Osoba
konkatenirani entitet (concatenated entity), kompozitni entitet (composite entity) binarna veza M:N, npr. Proizvodi ternarna veza ili veza stupnja >3, npr. Zaposlen veza o kojoj se eli pohraniti podatke (veza s opisnim atributima), pr. Sastav
Agregacija (agregacijska veza) Primjer, identifikacijska veza i identifikacijski slab entitet

1,1 Racu n Ra cStRac 1,N Stavka Ra cun a
Cjelina Proizvod Dio Sastav BrDijelova
sinonim: agregacijski entitet (aggregate entity) veza koja sudjeluje u vezama s drugim entitetima u nekim metodama oznaava odnos cjelina-dio
0,M
Osoba 1,N
Zanimanje 1,N 1,N
Zaposlen
OrgJed
Primjer, podtipovi: Djelatnik, Suradnik, Igla, Avion

0,N
DatPoc
DatZav
182
ERD notacija - Chen

Primjer, dijagram modela poduzea (Chen)
0,1 Mjesto Zanimanj e NadJed 1,1 1,N PodJed 0,N Stanuj e Osoba 1,N Zaposlen 1,N Or gJed 0,M Proizvodi Pri pada
ERD notacija - Martin

Primjer, dijagram modela poduzea (Martin), doseg, podsustavi
Mjesto Zanimanj e
0,N
Pri pada Stanuj e Osoba Zaposlen Or gJed Sastav
1,1 0,N 1,1 Racun 1,1 Proi zvod NS 1,1 1,1 RacStRac OdnosiSeNa ES Di o 0,N Cj elina
0,M
Proi zvod
Sastav
Racun
0,N 0,1 0,1
0,1
0,N
1,N 0,N
Djel atni k
Suradni k
StavkaRacuna
Igl a
Avion
Djel atni k
Suradni k
StavkaRacuna
Igl a
Avion
183
184
Izrada ERD analizom izjava korisnika

"Kemiar ili lan osoblja kemijskog laboratorija moe podnijeti zahtjev za jednom ili vie kemikalija. Zahtjev moe biti udovoljen ili dostavom pakiranja kemikalije koja se ve nalazila na zalihi kemijskog laboratorija ili upuivanjem narudbe za novim pakiranjem kemikalije od vanjskog dobavljaa. Osoba koja upuuje zahtjev mora imati mogunost pretraivanja kataloga kemikalija vanjskog dobavljaa dok sastavlja narudbu. Sustav mora pratiti status svakog zahtjeva za kemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Takoer, mora pratiti povijest svakog pakiranja kemikalija od trena kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbaen."
Inventorij kemijskog laboratorija
Zahtjev za kemikalijom
zahtijeva
pohranjuje
ispunjava popisuje M Zahtijeva
Razvoj modela podataka
Pakiranje kemikalija
sadri
Kemikalija
opisuje
M 1 Dobavljaev katalog
prati
Povijest pakiranja kemikalija
185

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

Globalni model podataka
podatkovni model poduzea (enterprise data model) u fazi planiranja konceptualni model entiteti-veze koji najee sadri neodreene veze i nerazraene kategorije podataka, a pojedine veze mogu i nedostajati definira mogui doseg sustava i ukupne informacijske potrebe
Model konteksta podataka

na poetku analize konceptualni model koji sadri samo one entitete koji e biti obuhvaeni tehnikim rjeenjem aplikacijski model podataka rafinira doseg bez detalja o entitetima ili detalja o poslovnim pravilima ERD s entitetima i vezama (esto nespecifinim), bez atributa ili samo s osnovnim atributima obine veze, tj. veze tipa 1:N
npr. "raun ima vie stavki"
Kategorije entiteta
osnovni, fundamentalni jaki entiteti, ne spadaju u ostale kategorije (Mjesto) asocijativni (spojni, vezni) - koji proizlaze iz asocijativnih veza (Zaposlenje) atributivni koji opisuju ili kategoriziraju druge entitete (Zanimanje, Stanje) podtipovi specijalizacije (Djelatnik, Suradnik, Igla, Avion)
veze vieg stupnja

npr. zaposlenje osobe u org. jedinici na radnom mjestu Zaposlen
izbjegavati entitete koji se odnose na specifini kontekst ili ulogu
Primjeri:
Analiza\IdejnoSljeme , prethodni primjeri

188
Primjer: konceptualni model

VrstaOrgJed ifrarnik vrsta org. jedinica (npr. uprava, odjel, odsjek, PJ, itd.) Stranka Fizika ili pravna osoba TipStranke TipStranke Kontakt Telefoni, Mobiteli, Email, URL, Fax itd. OrgJedinica Organizacijska jedinica (npr. Ministarstvo, Odjel, Odsjek, Podruna jedinica) Osoba Fizika osoba Djelatnik Fizika osoba koja je dio sustava
Logiki modeli podataka

Model s definiranim kljuevima
eliminacija neodreenih veza i njihovo nadomjetanje asocijativnim entitetima odreivanje kljueva (primarnih, alternativnih, stranih) ako se PK ne moe odrediti, moda se ne radi o skupu entiteta preciziranje kardinalnosti veza odgovor na pitanja oblika mora/moe: ni jedan (0), barem jedan (1), vie (N) donja/gornja granica kardinalnosti
Koliko stavki rauna mora/moe imati raun ? 1,N Koliko se osoba mora/moe nalaziti u mjestu ? 0,N
Zanimanje Drzava ifrarnik drava Obavljanje srodnih poslova odreene struke, kao i drugih odgovarajuih poslova
definiranje generalizacijskih hijerarhija odreivanje specijalizacija, tj. podtipova entiteta

npr. Igla, Avion
Zupanija Jedinica podrune (regionalne) samouprave
definiranje klasifikacijskog atributa nadtipa (diskriminator podtipa)

npr. Proizvod.TipProizvoda { Igla, Avion }
Mjesto Jedinica lokalne samouprave (opina ili grad) RadnoMjesto Funkcija zaposlenika prema pravilniku o unutranjem redu
Model s definiranim atributima

dodavanje preostalih opisnih atributa odreivanje podskupova podataka definiranje domena, logikih tipova podataka i standardnih vrijednosti atributa
189 190

Stranka VrstaOrgJed IdStranke NazStranke TipStranke TipStranke Kontakt IdOsobe (FK) VrstaKontakta TipStranke TekstKontakta Zanimanje
Primjer: Model s definiranim kljuevima

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

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

Potpuno opisani model
putpuni opis atributa, logikih tipova podataka i standardnih vrijednosti dodatni opisi: prava pristupa podacima, trajnost podataka (arhiviranje) vremenski najzahtjevniji zadatak, uobiajeno se provodi na kraju, ali moe zapoeti usporedno s izradom modela zasnovanog na kljuevima ili definiranjem opisnih atributa
Definiranje objekata modela podataka

Definiranje entiteta
jedinstveni naziv opis - znaenje i svrha entiteta, poslovni zahtjevi i ogranienja kratki naziv (kd) esto potreban zbog ogranienja alata ili jezika kratice (akronimi) izbjegavati osnovni atributi atributi kljueva i ostali vani za razumijevanje smisla trag zahtjeva porijeklo i primjena entiteta ovlast (nad meta-podacima), odgovornost (za podatke)
Daljnja konverzija modela

Pretvorba modela entiteti-veze u relacijski model podataka Fiziko oblikovanje podataka faza dizajna konverzija logikog u fiziki model (shema baze podataka) normalizacija i prilagodba uslijed tehnikih ogranienja i performanci
Definiranje veza
jedinstveni naziv glagol, glagolska imenica, Roditelj-Dijete , Rnn znaenje veze detalji dokumentacije tip identifikacijske, neidentifikacijske veze modalitet i kardinalnost kljuevi diskriminator generalizacije/specijalizacije pravila za ouvanje integriteta pri unosu i brisanju instanci
Modeliranje podataka treba provesti CASE pomagalom

Primjer: ERwin
Definiranje objekata modela podataka

Odreivanje kljueva
klju jakog entiteta = identifikacijski atribut klju identifikacijski slabog entiteta = klju jakog entiteta i vlastiti atribut pripaziti na kljueve sastavljene od vie atributa mogui nadomjesni kljuevi atributi kljua koji su ujedno kljuevi drugih entiteta upuuju na veze strani kljuevi migracija primarnog u strani klju uklanjanje neodreenosti stranih atributa
Logiko modeliranje podataka
Definiranje atributa
naziv atributa - jedinstven, s izuzetkom stranih kljueva znaenje atributa domena atributa kardinalnost atributa izvedeni atributi (iz razliitih instanci) i izraunati atributi (jedne instance) [Inmon 1989, Haeckel & Nolan, 1993] derivacijska formula, derivacijska zavisnost [McClure 1993]
Pretvorba modela E-V u relacijski model

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

vieznani atribut skup odgovarajuih atributa, npr. Osoba.Telefon Osoba.TelefonNaPoslu, Osoba.TelefonKodKuce, Osoba.MobilniTelefon ili slabi entitet, npr. Osoba.Telefon Telefon (IdOsobe, VrstaTelefona, BrojTelefona)
Osob a
1,1 0,N Telefon
Atributi
kardinalnost 0 opcionalna vrijednost (null) kardinalnost 1 zahtijevana vrijednost (not null) kardinalnost N vieznani atribut (npr. Osoba.Telefon) atribut atribut, npr. Osoba.Prezime izvedeni atribut atribut pohrane ili se izostavlja, npr. Osoba.Staz sloeni atribut atribut (grupiranjem), npr. (dan, mjesec, godina) datum
Osob a IdOsob e Prezim e Im e Adres a DatRo d Staz
IdOsob e Prezim e Im e Te lefo nNaPosl u Tele fonKo dKuce Mobil niTe lefo n Adres a DatRo d Staz
197
Osoba
Te lefo n VrstaTel efon a Bro jTel efon a
198

Kljuevi
klju primarni klju, npr. Osoba.IdOsobe, Mjesto.SifMjesta alternativni klju indeks nad jedinstvenim vrijednostima (unique index) + oznaka zahtijevane vrijednosti (not null), npr. Mjesto.PostBr

Binarna veza 1:N strani klju
egzistencijalni slabi entitet obini strani klju npr. Stanuje Osoba.SifMjesta, Pripada OrgJed.SifNadJed, RacunOsoba Racun.SifOsobe
Oso baSKlj uce m IdOsob e Prezim e Im e Adres a DatRo d Staz
Mjesto Si fMjesta PostBr <AK> NazMjesta
Mjesto SifMjesta PostBr <A K> NazMjesta
O soba IdOsobe Prezime Ime SifMjesta <FK1> Adresa DarRod Staz

Osoba IdOsobe Prezi me Ime SifMjesta <FK1> Adresa Da rRod Staz
O rgJed SifOrgJed NazO rgJed SifNadJed <F K1>
Ra cun BrRa c Da tRac IdOsobe <FK> IznosRac
199
200

identifikacijski slabi entitet nasljeuje klju jakog entiteta spojni klju (compound key), npr. StavkaRacuna (BrRacuna, SifProizvoda, JedCijena, Kolicina) ili kompozitni klju (composite key), npr. StavkaRacuna (BrRacuna, RbrStRac, SifProizvoda, JedCij, Kolicina)
Racu n BrRac DatRac IdOsobe <FK> IznosRac StavkaRac BrRac <FK> Si fProizvoda <FK> Jed Ci j Koli cin a Pro izvo d SifProi zvod a NazProi zvod a Je dCijen a TipProi zvod a

Binarna veza 1,1:0,1 strani klju
transformira se u identifikacijski slabi entitet bez deskriptora Osoba (IdOsobe, Prezime, , Staz), SlikaOsobe (IdOsobe, Slika) opcionalno se moe razmotriti udruivanje entiteta u binarnoj vezi 1,1:1,1 (1,1:0,1) u jednu relaciju Osoba (IdOsobe, Prezime, , Staz), Komentar (IdOsobe, TekstKom) Osoba (IdOsobe, Prezime, , Staz, TekstKom)
Stavka Ra cun a BrRac <FK> RbrStRac Si fProizvoda <FK> Je dCijen a Koli cin a
Telefon IdOsobe < FK> VrstaTelefona BrojTelefona
201
202

Nespecifine veze asocijativni entitet + n binarnih veza 1:N
klju asocijativnog entiteta = unija kljueva entiteta spojenih vezom primjer: Zaposlen, Proizvodi, Sastav
OrgJed 0,M Proizvodi 0,N Proizvod

Specijalizacija nadtipa u n podtipova n binarnih veza
nadtip (jaki) entitet, kojemu se po potrebi odreuje klasifikacijski atribut, npr. Proizvod.TipProizvoda podtip (identifikacijski) slabi entitet, npr. Igla, Avion, Djelatnik, Suradnik
Zanimanje SifZanim NazZanim
Zanimanje 1,N 1,N 1,N
Osoba
Zaposlen
OrgJed
O soba IdOsobe Prezime Ime SifMjesta < FK1> Adresa DarRod Staz
Osoba
Zaposlen IdOsobe <F K1> SifOrgJed < FK2> SifZanim <FK3> DatPoc DatZav KoefPlace
O rgJed SifOrgJed NazO rgJed SifNadJed < FK1>
1,1 NS
0,1 Djelatnik
0,N Suradnik
Proizvod 1,1 ES
0,1 Igla
0,1 Avion
Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda
DatPoc
DatZav
0,M
Cjelina Proizvod Dio Sastav BrDijelova
Sastav SifProizvoda <FK1> SifDijela <F K2> BrDijelova
Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda
Proizvodi SifOrgJed < FK1> SifProizvoda <FK2>
Djelatnik IdOsobe <FK1> BrRadKnj BrTekRac
Suradnik IdOsobe <FK> BrUgovora BrZiroRac UvjetiSuradnje
Igla SifProizvoda <FK> Duljina Promjer
Avion SifProizvoda <FK> BrSjedala DoletKM
0,N FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.
203
204
Mjesto SifMjesta PostBr <AK> NazMjesta
Zanimanje SifZani m NazZani m
Preporuke za izradu modela podataka

OrgJed SifOrgJed NazOrgJed SifNadJed <FK1>
Sinkronizacija s modelom procesa

spremita podataka u modelu procesa su entiteti u modelu podataka
Osoba IdOsobe Pr ezime Ime SifMjesta <FK1> Adresa DarRod Staz
Zaposlen IdOsobe <FK1> Si fOrgJed <FK2> SifZanim <FK3> DatPoc DatZav KoefPlace
istoa modela
izbjegavati entitete koji opisuju ugradnju (ulazno-izlazni ureaji, meta-podaci, itd)
Provjera modela
Proizvodi Si fOrgJed <FK1> SifPr oizvoda <FK2>
Racun BrRac DatRac IdOsobe <FK> IznosRac Dj elatnik IdOsobe <FK1> BrRadKnj BrTekRac Suradnik IdOsobe <FK> BrUgovora BrZiroRac Uvj etiSuradnje
pripaziti na sinonime (razliite nazive istih objekata) pripaziti na homonime (jednake nazive razliitih objekata) provjeriti sumnjive i redundantne veze i po potrebi ih ukloniti (oprez!) uklanjanje neke od paralelnih veza OrgJedinica-Osoba
primjer: OrgJedinica 1:N Djelatnik i OrgJedinica N:1 Djelatnik-Upravitelj primjer: MjestoRodjenja 1:N Osoba i MjestoPrebivalista 1:N Osoba
StavkaRac BrRac SifProizvoda <FK> JedCij Kolicina
Pr oizvod SifProizvoda NazProizvoda JedCijena Ti pProizvoda
Sastav SifPr oizvoda <FK1> SifDij ela <FK2> BrDijelova
uklanjanje veza koje se daju izvesti iz drugih (npr. trijade) - pripaziti na kardinalnost veza u lancu
primjer: naspram Osoba 0,N:1,1 Mjesto 0,N:1,1 Drzava Osoba 0,N:0,1 Mjesto 0,N:0,1 Drzava
Igla SifProizvoda <FK> Duljina Promj er FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.
Avion SifProizvoda <FK> BrSjedala DoletKM
ukloniti balansirane veze 1,1:1,1 pripaziti na nebalansirane veze 0,1:1,1 (zavisnost entiteta) cirkularne reference izbaciti izvedene atribute oprez, mogui gubitak informacije o potrebnim izvedenim/izraunatim poljima
Dogaaji
Dogaaj
zgoda, zbivanje u sustavu koja vodi ili pokree procese sustava sm dogaaj nije proces, nego okida procesa koji se njime pokree primjer: kupac dostavi narudbu pokree proces provjere da li se radi o narudbi postojeeg ili novog kupca, proces stvaranja podataka o narudbi i stavkama narudbe, provjeru prethodnih zaduenja kupca, provjeru stanja skladita itd.
Modeliranje dogaaja
Vrste dogaaja
vanjski dogaaji potaknuti od strane vanjskih entiteta, koji zahtijevaju informaciju ili auriranje podataka ulazni tokovi podataka imenuju se tako da naziv sadri naziv vanjskog entiteta primjer: zahtjev za upis studenta ili zaprimanje narudbe kupca vremenski dogaaji - vremenski uvjetovani (rok, uestalost) ulazni upravljaki tokovi imenuju se tako da naziv sadri vremensku oznaku primjer: istek roka plaanja rauna, mjeseni obraun plaa, zakljuivanje ispitnog roka unutarnji dogaaji, dogaaji stanja - posljedica prijelaza sustava iz jednog stanja u drugo, na takav nain ta to zahtjeva obradu ulazni upravljaki tokovi primjer: isporuka robe sa skladita zahtijeva naruivanje nove robe
Modeliranje procesa voeno dogaajima

Raspodjela dogaaja (event partitioning)
1. 2. 3.

Event-Response List
event 1 event 2 response response response response response response response
1
The System
event 3
4.
5.
6. 7.
Izrada dijagrama konteksta sustava postavljanje poetnog dosega projekta Izrada dijagrama funkcionalne dekompozicije podjela sustava u logike podsustave i/ili funkcije Izrada popisa dogaaja i odziva utvrivanje poslovnih dogaaja na koje sustav mora odgovoriti element popisa = dogaaj, ulaz, izlaz Izrada dijagrama dekompozicije dogaaja dodavanje procesa za rukovanje dogaajima (event handler) dodaje se po jedan proces za svaki utvreni dogaaj Izrada dijagrama dogaaja razrada procesa za obradu dogaaja po jedan dijagram za svaki svaki dogaaj Izrada dijagrama sustava udruivanjem dijagrama dogaaja Izrada primitivnih dijagrama razrada dijagramom toka podataka koji sadri osnovne procese, spremita i tokove za svaki pojedini dogaaj
event 4
...
Slika: Whitten et.al, Systems Analysis and Design Methods, McGraw-Hill Higher Education, 2000
The System
Function 1
Function 2
...
Function n
Event 1
Event 2
Event 3
Event 4
Event 5
...
Event n-2
Event n-1
Event n
Event 1
...
Event 5
...
Event n
209
210

Event 2 Event n-2
Primjer: tablica dogaaja i procesa
Event 1
Event 4 Event n
Event n-1
Event 5 Event 3
2.3
...
2.1 2.4
...
2.2
211
212
Matrica Entiteti/Dogaaji
Matrica Entiteti/Dogaaji Primjer: pojednostavnjena
Entity/Event Matrix, Event/Enquiry, rezervacija sobe u hotelu Proljee Entity Access Matrix pogled na sustav usmjeren dogaajima (event oriented view) matrica sadri: dogaaje (retci) Dogaaj/Entitet entitete (stupci) elemente koji prikazuju uinak dogaaja na entitete privremena rezervacija C/M C
rezervacija sobe zaduenje korisnik soba
Stvaranje: C (create) itanje: R (read) - u nekim metodama se ne biljei Auriranje: U (update) ili M (modify) Brisanje: D (delete)
Matrini prikaz modela dogaaja

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

M C M D M
matrica Korisnik / Proces / X matrica Korisnik / Entitet / CRUD Korisnik pri tome predstavlja grupu korisnika ili ulogu korisnika Ovisno o detaljima ugradnje u fizikom modelu Korisnik moe biti i konkretna osoba
213
214
Matrini prikaz modela dogaaja

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

Povijest ivota entiteta (Entity Life History)
pogled na sustav usmjeren uincima dogaaja koji uzrokuju promjene stanja opisuje vremenski zavisno ponaanje (jednog) entiteta prati promjene ponaanja entiteta koji prolazi kroz sustav Dijagram podudarnosti uinaka - Effect Correspondence Diagram (ECD)
en tite t, bl o k
R R R R RU R R RU RU RU RU RU RU RU RU RU RU RU RU RU RU RU RU R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R
R R R RU
R RU R
sl ij e dn i do ga a j (sli j ed )
al tern ati vni do ga a j (sel ekcij a )
po na vl j an i do ga a j (ite ra ci j a)
R R
R R R R
R R R R
R R
R R
R R
R R
R R
R R
m
215
op era ci je
o
216
Model ivota entiteta

Primjer, pojednostavnjena rezervacija sobe u hotelu Proljee
rezervacij a sobe
Dijagram prijelaza stanja

Dijagram prijelaza stanja (State Transition Diagram)
zasniva se na ideji stroja s konanim brojem stanja (finite state machine), hipotetikom mehanizmu koji u nekom trenutku moe biti u jednom od konano mnogo diskretnih stanja grafiki prikaz promjena stanja, tj vremenski zavisnog ponaanja sustava
Elementi prikaza:
rezervacij a, nenajav. dolazak opozi v rezervacij e ili nedolazak
potvrda rezervacij e 3
najavljeni dolazak 2 3
stvaranj e troka
pl aanje usluga
arhivi ranje rezervacij e 7
stanje kumulativni rezultat ponaanja nekog objekta (pravokutnik, krug ili elipsa) prijelaz promjena stanja uzrokovana nekim dogaajem (usmjerena linija od jednog stanja prema drugom) dogaaj uvjet promjene stanja i akcija koja se obavlja (opis linije prijelaza oblika dogaaj/akcija)
DPS najee opisuje vremenski zavisno ponaanje itavog sustava

manji sustavi mogu se prikazati jednim dijagramom vei sustavi razlau se slino dijagramima toka podataka, pri emu stanje na nekoj razini postaje poetno stanje dijagrama na nioj razini
3 privremena rezervacij a dolazak gosta opozi v rezervacij e nedolazak gosta poveanje troka
Primjena
1. 2. 3. 4. 5. 6. 7. Kreirati rezervaciju Zauzeti sobu Aurirati status rezervacij e Kreirati zaduenje Ponititi zaduenje Osloboditi sobu Obrisati podatke o rezervaci ji
217
sustavi za rad u stvarnom vremenu (real-time system) jezina analiza (parsing) dizajn korisnikog suelja
Primjeri:
\Dizajn
218
Primjer: Stanja zahtjeva (narudbe)

U pripremi: Zahtjevatelj stvara novi zahtjev, pokrenuvi tu funkciju iz nekog drugog dijela sustava Odgoen: Zahtjevatelj je snimio svoj rad (narudbu) kako bi ju dovrio kasnije bez da ju je predao ili otkazao Zaprimljen: Zahtjevatelj je predao svoj zahtjev (narudbu) koji je sustav ocijenio kao dobar i primio ga Podnesen: vanjski dobavlja je sposoban isporuiti zahtjev i kupac podnosi zahtjev (narudbu) kod vanjskog dobavljaa Ispunjen: zahtjev je zadovoljen bilo da je dostavljen iz zaliha kemijskog laboratorija ili da je dostavljen od strane vanjskog kemikalija nabavljena iz zaliha kem. laboratorija dobavljaa Vraen: dobavlja nije mogao zadovoljiti narudbu i vratio je narudbu uz mogunost kasnije dostave Otkazan: Zahtjevatelj je otkazao primljen kemikalija nabavljena zahtjev prije negoli je isporuen ili je kupac od dobavljaa otkazao narudbu kod vanjskog dobavljaa prije nego to je dostavio narudbu ili nakon to je dobavlja vratio narudbu uz mogunost kasnije dostave
ispunjen
kemikalija nabavljena od dobavljaa korisnik stvara novi zahtjev korisnik otkazuje novi zahtjev korisnik snima nepotpun zahtjev
Primjer: sustav za rad u stvarnom vremenu

Dijagrami sustava za rad u stvarnom vremenu razlikuju se po tome to sadre posebno stanje "besposlen"
Primjer, Sokomat hotela Proljee ili Bankomat banke Oprosti nam duge nae
odgoen
u pripremi
korisnik dohvaa nepotpun zahtjev
prazni hod (idle)

sustav prihvaa valjan zahtjev
primljeno
zahtijeva otkazuje narudbu
ispravna kartica / 'Izaberite'
neispravna kartica / 'Neispravna
kartica izvaena / 'Umetnite'
kupac podnosi zahjtjev kod dobavljaa
izabran 'Kraj' / 'Hvala, enja' ekanje na izbor
ekanje na vaenje kartice
podneen
kupac otkazuje narudbu
obavljen odabir / 'Pokupite'

dobavlja vraa narudbu za kemikalijama
izvaeno / 'Jo neto?'
vraen
kupac otkazuje narudbu
natoeno
otkazan
219
220
Izrada zapisa (ustanova) N
Mape dijaloga
Korisniko suelje u mnogim aplikacijama se moe promatrati kao konani automat.
Primjer: prijelazi statusa kartica

U zagradama je navedeno tko promjenu smije nainiti.
A D G I J K N O P R S T U X Y Z Izdana Student je diplomirao Pogreni podaci (koristi samo tvrtka za tiskanje) Izgubljena Ponitena zbog promjene JMBG-a Istekao apsolventski rok Nezavrena Oduzeta Ponitena Student je upisao prekid Student se ispisao Oteena Tiskana Ukradena Nestala Ponitena zbog neispravnih podataka Zatraena Izdavanje vlasniku (ustanova) A
Slika i potpis (ustanova) Z
Kontrola podataka prije tiska (CAP)
Ispravak pogrenih podataka (ustanova, CAP)
Jedan element suelja (izbornik, radna povrina, komandna linija ili dijalog prozor) moe biti aktivan u odreenom trenutku. Korisnik moe doi do ogranienog broja drugih elemenata ovisno o akcijama koje poduzima. Broj putanji kojima korisnik moe mijenjati dijaloge je obino vrlo velik, ali je konaan i mogunosti su najee poznate.
Podaci ispravni (CAP)

Z
Postoje neispravni podaci (CAP) G Y
Mape dijaloga prikazuju sustav na visokoj razini apstrakcije.

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

A
Ponitavanje kartice (ustanova, CAP) D I J K P O S R U
221
222
Mape dijaloga
Koristi se notacija dijagrama prijelaza stanja
Uvjet koji pokree korisniku navigaciju prikazan kao tekst na strelicama. Postoji nekoliko vrsta pokretakih uvjeta: Korisnika akcija, kao to je pritisak tipke ili klik na link ili gumb dijalog prozora Podatkovna vrijednost, kao to je pogrean unos koji pokree pojavljivanje poruke o pogreci Sistemski uvjet, kao to je signal da je pisa ostao bez papira Kombinacija navedenih, kao to je tipkanje opcije iz menija i pritisak na tipku Enter
Dijalog mape mogu prikazati
Primjer: mapa dijaloga

Alternativne putove (npr. naruiti od vanjskog dobavljaa) kao grane koje odstupaju od uobiajenog puta (kemikalija iz zaliha). Opcionalne putove (npr. Pregled povijesti pakiranja) odaberi Posebna stanja (npr, poruke i dodajpakiranje u listu o pogrekama)
zatrai kemikaliju
otkai cijeli zahtjev
Potvrda da je zahtijev primljen
Trenutna lista zahtjeva
podnijeti zahtjev za >0 kemikalija odaberi dobavljaa i dodavanje u listu otkai dodavanje nove kemikalije
brisanje kemikalije sa trenutne liste zahtjeva
zahtijevanje druge kemikalije
otkai zahtjev za novom kemikalijom
pogrena ifra kemikalije
Radi pojednostavnjenja mogu se izostaviti neke openite funkcije, npr.

pritiskanje tipke F1 da bi se dobila pomo standardni navigacijski linkovi koji se pojavljuju na svakoj stranici.
Prilikom analize zahtjeva, dijalog mapa predstavlja interakciju korisnika i sustava na konceptualnoj razini. Konkretna ugradnja moe biti drugaija.
Primjer: Korisnik inicira ovaj model koritenja odabirom opcije "zatrai kemikaliju" iz glavnog izbornika. Nije nuno prikazivati detalje (npr. Potvrdu otkazivanja itavog zahtjeva) Kljuno je da korisnik i razvojnik jednako razumiju opisanu funkcionalnost.
otkai dodavanje nove kemikalije u listu
Prikaz poruke o pogreci

OK
Unesite ifru zahtijevane kemikalije
zatrai kemikaliju od dobavljaa
zatrai razliitu kemikaliju
Lista dobavljaa za kemikaliju
zatrai kemikaliju zatrai razliitu iz zaliha kemikaliju laboratorija
Lista pakiranja u zalihama kemijskog laboratorija
zatrai pogledati povijest pakiranja
povratak
Povijest pakiranja
223
224
Oblikovanje sustava
Analiza to sistem mora raditi Dizajn kako sustav treba izgraditi ili kakav sustav treba biti
Oblikovanje sustava, Dizajn sustava (systems design)
Oblikovanje sustava
Procjena alternativa i detaljna specifikacija raunalom podranog rjeenja tehnika specifikacija sustava Izrada ugradbeno zavisnog modela, kojim se opisuje kako sustav radi fiziki dizajn
Moderni strukturirani dizajn

procesno usmjerena tehnika razrade velikog programa u hijerarhiju modula s ciljem izrade programa koje je lake napraviti i odravati starije varijante: oblikovanje programa s vrha nadolje (top-down program design) i strukturirano programiranje alternative i/ili nadopune: informacijsko inenjerstvo, prototipiranje, JAD, RAD, objektno usmjereni dizajn
226
Opi dizajn
Opi dizajn (konceptualni, visoki, dizajn arhitekture) funkcionalne specifikacije Odabir tehnike arhitekture sustava
Centralizirana ili distribuirana obrada i pohrana? Kako? Tehnologije? Softver: nabavljeni, napravljen po mjeri, mjeavina? Razvojni alati?
Detaljni dizajn
Detaljni dizajn tehnike specifikacije Izrada fizikog modela podataka
pretvorba logikog modela podataka u fiziki model podataka za odabrani SUBP shema baze podataka prilagodba modela mogunostima i ogranienjima SUBP fiziki parametri (volumetrija) i ugaanje baze podataka oblikovanje fizikih datoteka
Analiza i distribucija podataka

pretvorba konceptualnog modela podataka u logiki model (relacijski , postrelacijski, objektnorelacijski), ako nije uinjena ranije izrada dobrog modela podataka - jednostavan, neredundantan, elastian i prilagodljiv model analiza podataka (ako postoje) i normalizacija modela analiza dogaaja analiza entiteta normaliziranog modela i uoavanje dogaaja i uvjeta koji uzrokuju stvaranje, izmjenu i brisanje podataka i po potrebi auriranje modeli procesa
Dizajn programa
utvrivanje strukture programa na temelju modela procesa (logiki) proces ili skup procesa jedan ili vie programskih modula odreivanje veza izmeu modula (standardno strukturnim kartama) preciziranje programske logike
Analiza i distribucija procesa

pretvorba logikog modela procesa u fiziki model za odabranu arhitekturu fiziki procesi: posluitelji, radne stanice, rad koji treba obaviti fizika spremita: baze podataka, tablice, datoteke grupiranje i distribucija obrade na razliite lokacije dizajn raunalske mree, povezivanje s drugim, postojeim sustavima definiranje prava pristupa logikih grupa korisnika shema aplikacije
Dizajn suelja
dizajn suelja sustava protokoli pristupa i razmjene podataka oblikovanje zaslonskih maski i izvjea
Opi dizajn suelja

izgled, ergonomija, tzv. look and feel
Izrada planova konverzije i instalacije

Prototipiranje detalja dizajna Izrada procedura za provjeru ispravnosti i konverziju sustava

Pristupi oblikovanju i razvoju

Cjelovito
istovremeni (tzv. frontalni) razvoj cijelog IS veliki zahtjevi na ljudske resurse, problem koordinacije izvoaa
Fazno
podjela na podsustave te nezavisni razvoj pojedinih podsustava uz kasniju integraciju podsustava mogue kod velikih IS koji se daju rastaviti problem rastavljanja i povezivanja podsustava
Arhitektura sustava
Optimalno rjeenje
izrada jedinstvenog modela podataka na poetku razvoja razvoj i postupna integracija aplikacija
229
Dizajn arhitekture sustava

Dizajn arhitekture
sastoji se od planova koji definiraju pojedine komponente sustava raunalnu opremu programsku podrku komunikacije sustav zatite globalnu podrku aplikacije Specifikacija hardvera i softvera podloga za nabavu
Arhitektura sustava
Funkcije sustava = slojevi arhitekture
Pohrana podataka (data storage) Pristup podacima (data access logic) Elementi obrade (application logic) Suelje (presentation logic)
All data on the mainframe server
Distributed Presentation
Network User Interface on the PC Client
All business logic on the mainframe server
Distributed Data (2-tier)

Network Data and DB process on server Logic & user interface on PC
Posluitelji
Velika raunala (Mainframe) Mala raunala (Minicomputer) Mikroraunala (Microcomputer) PC
Data on DB process on Server
Distributed Data & Logic (3-tier)
Network Business logic on application server
Network User interface on the PC client
Uobiajeni modeli arhitekture

posluiteljska (server-based) obrada se obavlja na posluitelju klijentska (client-based) obrada se obavlja na osobnom raunalu klijent-posluitelj (client-server based) kombinacija prethodne dvije
Klijenti
Klasini terminali - ansi, vt220, ... Mikroraunala PC pristup terminal emulatorima ili udaljenim radnim plohama Terminali posebne namjene bankovni terminali (bankomati), Internet kiosk, runa raunala, ...
231
Network Data on database server Secure connection to database server
Internet and Intranet

Secure intranet provides access to data, logic, and interfaces Some logic on Intranet Server Secure Gateway to protect applications and data Connection to outside world
Internal user interface on PC
Model mree
prikaz glavnih komponenti sustava, njihove fizike lokacije i nain njihovog meusobnog povezivanja
Internet Connection provides access to interfaces and some logic Some logic on Internet Server
External user PC client
232
Centralizirana obrada
Viekorisniko raunalo (mainframe, minicomputer) + terminal
pohrana podataka (datoteke i baze podatka) poslovna logika (programska podrka) korisniko suelje (uobiajeno znakovno suelje ) suelje sustava (mrene i druge komponente)
Dvoslojna arhitektura klijent-posluitelj (client-server)

Klijent - jednokorisniko raunalo
suelje, obrada i pohrana povezljivost na posluitelje (opcionalno na druge klijente)
Primjeri
Posluitelj - viekorisniko raunalo

dijeljena baza podataka, obrada i servisi suelja povezljivost s klijentima i drugim posluiteljima
Distribuirana prezentacija
opcionalna nadgradnja sredinjih aplikacija zamjenom znakovnog suelja grafikim, koje se izvodi na osobnom raunalu produljuje vijek starih aplikacija, ali se funkcionalnost ne moe znaajno poboljati
Korisnicima izgleda kao da jedno raunalo (njihov PC) obavlja cijeli posao Prednosti
izolacija promjena u pojedinom sloju kvalitetnija (laka) obrada sredinje upravljanje integritetom podataka na posluitelju
Nedostaci
odravanje aplikacijske logike (programa) na svim klijentima debeli klijenti
Debeli klijent
Debeli klijent
Podatkovna logika integrirana u klijenta Nema obrade podataka na serveru ili je obrada minimalna Minimalna ili nikakva elastinost na promijene poslovne politike
Tanki klijent
Tanki klijent
Podatkovna logika se nalazi na posluitelju Osnovna namjena klijenta je prikaz podataka Veinom se koriste u poslovnim sustavima Tipian primjer tankog klijenta je web preglednik
Prednosti
brzi poetni razvoj aplikacije vea samostalnost klijenta rastereenje glavnog raunala (servera) moe imati lokalnu bazu podataka mogu se nabaviti jeftina raunala sa snanim procesorima
Prednosti
promjena poslovne logike ne znai nuno i promjenu u klijentskom dijelu aplikacije promjena poslovne logike moe se obaviti centralizirano raunala ne moraju imati veliku procesorsku snagu ukoliko s vremenom obrada postane spora (zbog koliine podataka), moemo jednostavno poveati snagu sredinjeg raunala kao tanki klijent moe se koristiti npr. web preglednik (dobro definirano i svima dostupno) smanjena mogunost rada sa zastarjelim podacima (gotovo za svaku promjenu ide se na server) manja kompleksnost razvoje velikih aplikacija (kod je podijeljen na serverski dio i klijentski dio)
Nedostaci
poslovna logika integrirana na klijenta promjena poslovne logike znai instaliranje nove verzije aplikacije na svim klijentima velika mogunost rada sa zastarjelim podacima ako s vremenom aplikacija postane spora (zbog koliine podataka), treba promijeniti sve klijente razvoj velike aplikacije s vremenom postaje vrlo kompleksan (sav kod je na klijentu)
Nedostaci
veliko optereenje glavnog raunala, a to znai skupo glavno raunalo ukoliko se kao klijent koristi web preglednik moraju se potivati njegova ogranienja
Troslojna ili vieslojna arhitektura klijent-posluitelj

Distribucija baza podataka i poslovne logike na zasebne posluitelje
posluitelj aplikacija + posluitelj baza podataka + klijent posluitelj baza podataka upravljanje podacima posluitelj aplikacija upravljanje transakcijama, "preuzeto" s podatkovnog posluitelja dio ili itava poslovna logika, "preuzeta" s klijenta klijent korisniko suelje dio poslovne logike - onaj koji se ne mijenja ili je osobnog karaktera
Vieslojna arhitektura
Koristi se za razvoj sloenih aplikacija Kod se moe podijeliti u vie razina, npr.
kod na formi (GUI - Graphic User Interface) kod u sloju poslovne logike (BLL - Business Logic Layer ) kod u sloju pristupa podacima (DAL - Data Access Layer) kod na bazi podataka (stored procedure)
Primjeri
Trenutno se esto radi podjela u tri razine

Klijent - GUI (u web aplikaciji je to web preglednik) Application server - BLL (npr. web servis) Baza podataka (npr. SQL Server)
Prednosti
bolja raspodjela optereenja vea skalabilnost - mogunost ekspanzije, npr. poveanja broja korisnika, bez preoptereenja ili potrebe za promjenom procedura)+
Nedostaci
sloeni (komplicirani) dizajn i razvoj problem raspodjele podataka, procesa, suelja vee optereenje mree
Odabir arhitekture korisnik-posluitelj

Odabir arhitekture moe ovisiti o raspoloivim raunalima i mrenoj infrastrukturi. Openito, mogu se primijeniti sljedei kriteriji:
Arhitekture Dvoslojne K/S arhitekture s tankim klijentima Aplikacije Naslijeeni aplikacijski sustavi gdje je nepraktino i neisplativo odvajanje aplikacijske obrade i upravljanje podacima. Raunalno-zahtjevne aplikacije s vrlo malo ili bez podatkovne obrade. Podatkovno zahtjevne aplikacije (pretraivanje i upiti) s vrlo malo ili bez aplikacijske obrade. Aplikacije gdje se aplikacijska obrada izvodi na klijentu COTS (Commercial Off-The Shelf Software) programskom podrkom Aplikacije koje zahtijevaju raunalno zahtjevne obrade podataka (npr. vizualizacija podataka interaktivno ili izvjeima). Aplikacije s relativno vrstom krajnje-korisnikom funkcionalnou koritene u okolini gdje je dobro uspostavljeno upravljanje sustavom. Aplikacije velikog opsega sa stotinama ili tisuama klijenata. Sustavi u kojima su i podaci i aplikacije promjenljivi. Aplikacije u kojima se integriraju podaci iz viestrukih izvora.
239
Primjer arhitektura klijent-posluitelj

Napraviti aplikaciju koja e prikazivati:
Kupce, prodavae i datume narudbi Nazive artikala, jedininu cijenu i koliinu za pojedinu narudbu Ukupnu koliinu i ukupnu vrijednost narudbe Treba prikazivati zadnjih 20 narudbi
Rjeenje debeli klijent

Na klijentu napravi SQL upit kojim se dohvaaju podaci o zadnjih 20 narudbi. Na klijentu napravi SQL upit kojim se dohvaaju detalji za zadnjih 20 narudbi. Kad se promjeni narudba proi kroz sve detalje i ispii one koje pripadaju trenutnoj narudbi. Usput raunaj zbirne vrijednosti.
Dvoslojne K/S arhitekture s debelim klijentima
Rjeenje tanki klijent

Na klijentu pozovi stored proceduru koja vraa podatke o zadnjih 20 narudbi Kad se promjeni trenutna narudba pozovi stored proceduru koja vraa detalje trenutne narudbe i zbirne vrijednosti
Troslojne ili vieslojne K/S arhitekture
Primjer promjene zahtjeva

Promjena zahtjeva
Korisnik se nakon mjesec dana rada aplikacije, naravno, predomislio i eli da se prikazuje zadnjih 50 narudbi.
Primjer rjeenja u vieslojnoj arhitekturi

Postoje sljedee razine:
GUI - (Visual Studio .NET 2003 - C#) BLL (Visual Studio .NET 2003 - C#) DALGeneric (generator koda LLBLGen -> C#) DALSpecific (generator koda LLBLGen -> C#) Baza podataka (MS SQL Server)
Ispunjenje promjene zahtjeva

Na debelom klijentu treba promijeniti SQL upite u izvornom kodu, prevesti ga u novu izvrnu inaicu te dostaviti aplikaciju korisnicima - sporo i skupo Na tankom klijentu treba na serveru promijeniti samo pohranjenu proceduru za dohvat narudbi - brzo (manje od pet minuta) i jeftino
241
242
Primjer prezentacijskog sloja

GUI - (Visual Studio .NET 2003 - C#)
private void FormLastOrders_Load(object sender, System.EventArgs e){ // Konstruiraj bklasu _bLastOrders = new BLastOrders(_connectionString); // Postavi DataSource na oba grida dataGridOrders.DataSource = _bLastOrders.OrdersEntityCollection; dataGridOrderDetalis.DataSource = bLastOrders.OrderDetailsEntityCollection; // Ispii detalje trenutno selektirane narudbe dataGridOrders_CurrentCellChanged(sender, e); } Prema pravilima vieslojnog programiranja na prezentacijskom sloju (formi) koristimo sloj poslovne logike (B-Klasa). U ovom primjeru trebamo konstruirati b-klasu i ispisati podatke u gridu. U konstruktoru b-klase se uitaju podaci o narudbama. Nakon toga okinemo event na kojem se prikazuju podatci o detaljima narudbe (sljedei slide).
Primjer prezentacijskog sloja

private void dataGridOrders_CurrentCellChanged(object sender, System.EventArgs e) { // Dohvati podatke o trenutno selektiranoj narudbi _bLastOrders.SelectOrderDetails(Convert.ToInt32(dataGridOrders[ dataGridOrders.CurrentRowIndex, 0])); // Ispii zbirne podatke na formu textBoxTotalPrice.Text = _bLastOrders.TotalPrice.ToString("C"); textBoxTotalQuantity.Text = _bLastOrders.TotalQuantity.ToString(); } Kod promjene selektirane narudbe treba osvjeiti podatke o detaljima. To radimo tako da pozovemo pripadajuu metodu u b-klasi (SelectOrderDetails). Ta metoda dohvaa detalje neke narudbe, a usput rauna i zbirne podatke (ti podaci su dostupni preko property-a b-klase.
244
Primjer poslovnog sloja (BLL)

BLL (Visual Studio .NET 2003 - C#)
public BLastOrders(string connectionString) { // Konstruiranje adaptera za pristup bazi podataka _dataAccessAdapter = new DataAccessAdapter(connectionString); // Definiranje EntityCollection-a za narudbe _ordersEntityCollection = new EntityCollection(new OrdersEntityFactory()); SelectLastOrders(); // Definiranje EntityCollection-a za detalje narudbe _orderDetailsEntityCollection = new EntityCollection(new OrderDetailsEntityFactory()); } Primjer konstruktora u b-klasi (sloju poslovne logike). Sloj poslovne logike treba pametno definirati, tako da GUI slui samo za prikazivanje podataka, a sve vee obrade i rad s bazom moraju se odvijati u b-klasi. U ovom primjeru uz b-klasu postoji i sloj pristupa podacima (DAL) prije same baze podataka. U b-klase se intenzivno koristi DAL, a iz priloenog koda vidi se da je programiranje znatno jednostavnije nego upotrebom SQL upita.
Primjer poslovnog sloja (BLL)

public EntityCollection SelectLastOrders() { // Isprazni trenutni sadraj _ordersEntityCollection.Clear(); // Narudbe treba sortirati prema datumi unatrag ISortExpression sorter = new SortExpression( SortClauseFactory.Create(OrdersFieldIndex.OrderDate, SortOperator.Descending)); // Definiranje dodatnih staza za dohvat podataka (treba dohvatiti podatke o kupcima i djelatnicima) IPrefetchPath2 path = new PrefetchPath2((int)EntityType.OrdersEntity); path.Add(OrdersEntity.PrefetchPathCustomers); path.Add(OrdersEntity.PrefetchPathEmployees); // Dohvat podataka iz baze (uz koritenje sortera i dodatnih staza za dohvat) _dataAccessAdapter.FetchEntityCollection(_ordersEntityCollection, null, 20, sorter, path); // Vrati podatke dohvaene iz baze return _ordersEntityCollection; }
Primjer dohvata zadnjih 20 narudbi u b-klasi. Tu ujedno moemo napraviti i promjenu da se dohvati zadnjih 50 narudbi. Ovo je primjer pristupa bazi podataka preko objekata. Taj primjer se ne ini ba jednostavan, ali u praksi se pokazuje da ima mnoge prednosti u odnosu na pisanje SQL upita. Osnovna prednost je manja mogunost pogreke, a sljedea prednost je preglednost koda. Na slian nain bi se rijeio i dohvat detalja pojedine narudbe.
Primjer podatkovnog sloja (DAL)

DALGeneric (generator koda LLBLGen -> C#) i DALSpecific (generator koda LLBLGen -> C#)
Ovaj dio slui za pristup bazi podataka (DAL) Ovaj dio koda se generira pomou generatora koda. DAL se u ovom primjeru dijeli na dva dijela: DALGeneric - Objekti za pristup bazi koji su isti za sve baze DALDBSpecific - Objekti za pristup bazi koji su specifini za pojedine baze podataka Prednosti rjeenja upotrebom generatora koda: Mogunost pristupa bazi podataka preko objekta (nije potrebno znanje SQL-a) Mogunost promjene baze podataka Nema velikog gubljenja vremena na pisanje koda za pristup bazi podataka Manja mogunost pogreke
Dizajn baze podataka

Izrada sheme baze podataka (fiziki model, tehniki nacrt) prevoenje podatkovnog modela u strukture podrane odabranom tehnologijom (SUBP) primarni klju, sekundarni klju, strani klju, opisna polja Relacijske BP strukturirani upitni jezik (SQL), okidai (trigger), pohranjene procedure (stored procedures), dinamiki skupovi podataka (cursor), korisniki definirani tipovi podataka i funkcije ...
Normalizacija
Normalizacija
postupak strukturiranja sheme relacijske baze podataka tako da se ukloni to vie neodreenosti (zalihosti) stupanj normalizacije poveava se od 1NF do 5NF veina dizajnera zaustavlja se na 3NF ili na BCNF (Boyce-Codd NF) svodi se na ispunjenje tzv "relacijske zakletve" [Finkelstein, 1989]: Klju
1NF: nema ponavljajuih grupa, definiran primarni klju
Svrha
pouzdanost - konzistentnost i integritet podataka uinkovito rukovanje podacima prilagodljivost na promjene zahtjeva skalabilnost
Cijeli klju
2NF: svi nekljuni atributi u potpunosti zavisni o itavom PK
Nita drugo nego klju

3NF: svaki nekljuni atribut je neposredno zavisan samo o PK
Analiza podataka
priprema modela podataka za ugradnju normalizacija - tehnika organiziranja atributa, dovoenje modela u odreeni stupanj organiziranosti, 3NF ili viu NF
Tako mi Codd pomogao!

Dr. E. F. Codd - otac relacijske teorije BP BCNF: svi atributi koji odreuju druge atribute ine mogue kljueve
Great news - the relational model is dead! Michael Gorman, Whitemarsh Information Systems, Corp., http://www.wiscorp.com
Normalizacija
Prevoenje modela i normalizacija uporabom CASE pomagala
Automatizirano pridjeljivanje stvarnih tipova podataka konkretnog SUBP Stvaranje tablica za entitete nadtipa i podtipa Automatizirana migracija kljua i prepoznavanje tzv. viseih veza (dangling relationships) veza na tablice koje nisu ukljuene u generiranje modela Veina CASE alata normalizira u 1NF zamjena veza vie-prema-vie asocijativnim entitetima zamjena vieznanih atributa entitetima Vie normalne forme problem prepoznavanja djelominih i tranzitivnih zavisnosti Generiranje programskog koda okidaa
Denormalizacija
Nadomjesni kljuevi
ispred kljua sloenog od veeg broja atributa (npr. >= 3) umee klju sa samopoveavajuim vrijednostima (serial), a na originalni klju postavlja se jednoznaan (unique) kompozitni indeks teorijski se ne preporua za asocijativne entitete, koji nasljeuju kljueve svojih roditelja, jer se time gubi smisao identifikacijske veze praktino, nadomjestak treba ugraditi kada je tablica u koju se ugrauje referencirana iz drugih tablica, a to nije u suprotnosti s poeljnim redundantnim vezama
primjer: @IdRadnogMjesta = @IdOrgJedinice, @IdZanimanja RadnoMjesto = @IdRadnogMjesta Zaposlenje = @IdOsobe, @IdRadnogMjesta, @DatZaposlenja, primjer: Drzava 1:N Mjesto 1:N Osoba, pri emu je Mjesto = @IdDrzave, @IdMjesta,
Prije poetka kodiranja obavlja se ogranieno uvoenje zalihosti i ugaanje baze podataka zbog poboljanja elastinosti i poboljanja performanci
zahvat moe rezultirati odreenim brojem intervencija u logiki model Denormalizacija - ogranieno i kontrolirano naruavanje NF
isti dizajn dosljedna ugradnja nadomjesnog kljua sa samopoveavajuim vrijednostima u sve tablice baze podataka pojednostavnjenje ugradnje umnoavanje kljueva (nadomjesni primarni, originalni alternativni) gubitak izvorne vrijednosti stranog kljua
Denormalizacija
Dijeljenje i udruivanje tablica
dijeljenje tablica smjetanjem rijetko koritenih atributa u posebnu tablicu udruivanje tablica ili uklanjanje pojedinih tablica stapanjem atributa obine veze 1:1 udruivanje nadtipa s podtipovima kardinalnosti 1:1, pod uvjetom da su sline strukture i sadraja
Ugradnja pravila za ouvanje integriteta

Ouvanje integriteta stvaranjem objekata u rjeniku BP
Entitetski integritet - postavljanjem primarnog kljua Referencijski integritet - postavljanjem stranog kljua i ogranienja na unos mora postojati vrijednost stranog kljua (mandatory not null) strani klju smije se postaviti na nul-vrijednost (optional null) Domenski integritet - postavljanjem ogranienja na skup vrijednosti Alternativni kljuevi - obveznim atributima i jedinstvenim indeksima
Uvoenje zalihosti
dodavanje atributa za pohranu izvedenih vrijednosti atribut pohrane za izvedenu vrijednost koja se moe izraunati agregatnom funkcijom (npr. iznos rauna kao suma iznosa stavki) oznaka zadnje vrijednosti nekog stanja kada se vrijednosti pojedinih stanja nalaze u tablici s velikim brojem zapisa (npr. stanje skladita) redundantna vrijednost koja se inae dohvaa sloenim i/ili sporim upitima (zadnje zaposlenje + zadnji izbor u zvanje + zadnje kolovanje) dodavanje atributa kao to su zastavice za "trajno" oznaavanje zapisa
Pravila referencijskog integriteta opi sluaj

Postupci prilikom unosa, auriranja i brisanja roditelja ili djeteta zabrana (restrict) brisanje n-torki koje imaju odgovarajuu vrijednost stranog kljua (cascade) auriranje odgovarajuih vrijednosti stranih kljueva (set null) postavljanje na standardnu vrijednost (set default)
Podrazumijeva se da se denormalizacija obavlja samo na mjestima gdje je to stvarno nuno i na takav nain da ne ugroava integritet podataka aplikacijsko upravljanje integritetom
254
Ugradnja referencijskog integriteta

Neposredno upravljanje referencijalnim integritetom od strane SUPB (DRI - Direct Referential Integrity), svodi se na:
restrikciju pri unosu, tj. obvezni unos (not null) stranog kljua i provjeru postojanja referencirane n-torke pri unosu postojanje opcionalnog, tj. nedefiniranog stranog kljua (null) kaskadnu obradu n-torki koje referenciraju roditelja koji se aurira ili brie
[ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ]
Ugradnja referencijskog integriteta

Mogui problemi
Neki atribut stranog kljua moe biti primarni atribut. Pokuaj auriranja na nul-vrijednost stranog kljua koji je dio primarnog kljua u suprotnosti je s pravilom entitetskog integriteta. Prilikom auriranja stranog atributa koji je ujedno i primarni atribut ne smije se naruiti jedinstvena vrijednost kljua. Postupak kaskadnog auriranja ili brisanja n-torki treba provesti rekurzivno, da bi se referencijalni integritet ouvao u svim dijelovima baze podataka, a ne samo na mjestu obrade. Problem kaskadnog brisanja pola baze podataka Problem paralelnih kaskada
Upravljanje referencijskim integritetom okidaima (trigger)

elastiniji pristup, koji omoguava ugradnju i ostalih postupaka prilikom unosa/izmjene/brisanja n-torki
Aplikacijsko upravljanje integritetom

postupci unosa/izmjene/brisanja podrani programskim kodom pojavljuje se problem umnaanja programskog koda, naroito kod hibridnih sustava (4GL + GUI)
Mjeovito
kombinacija navedenih mogunosti, s tim da DRI ima prednost
Ugaanje baze podataka

Postavljanje indeksa radi
osiguranja integriteta podataka ubrzanja dohvata podataka
Ugaanje baze podataka

Minimizacija nul-vrijednosti
problem neodreenih vrijednosti agregatnih funkcija, problem operacija s nul-vrijednostima
primjer: SELECT AVG(polje), gdje polje ima/nema nul-vrijednosti
Preporuke za postavljanje indeksa

Jedinstveni indeks nad primarnim i alternativnim kljuem (integritet) Indeks nad stranim kljuem (ubrzanje provjere integriteta i spojnih upita) Indeksi nad najee koritenim poljima, tj poljima koja se koriste za grupiranje, sortiranje ili selekciju uz uvjet (ubrzanje pretraivanja) Neki sustavi implicitno kreiraju indekse za primarne i strane kljueve openito, u tom sluaju ne treba posebno kreirati indekse ako su kljuevi sloeni pretraga e raditi brzo uglavnom po prvom polju
po potrebi postaviti dodatne indekse nad preostalim poljima
opisna polja - zahtijevana vrijednost + pretpostavljena vrijednost problem vanjskih spojnih upita strana polja posebne vrijednosti u ifrarnicima
primjer: 0-nepoznata vrijednost, 999-nepostojea vrijednost
Ubrzanje upita
analiza plana izvoenja (Execution Plan) i odabir poeljnog plana
primjer: SELECT ... OPTION (FORCE ORDER)
primoravanje koritenja odreenog indeksa

primjer: SELECT ... WITH (INDEX(index, index...))
Gomilasti indeks (CLUSTERED INDEX), Faktor popunjenosti (FILL FACTOR), ....
Promjene podataka uzrokuju auriranje indeksa.

Izbjegavati nepotrebne i indekse koji su sastavni dio drugih indeksa! Ukloniti indekse prigodom masovnih obrada podataka Koristiti naredbe i opcije za uvoz podataka (BULK INSERT ... CHECK_CONSTR.) Treba li kreirati indeks u tablicama s malim brojem podataka?
primoravanje nekoritenja indeksa primjenom nekodljive funkcije nad poljem nad kojim se uobiajeno koristi indeks
primjer: WHERE NULLIF ( polje , ) = ...
ostale opcije
primjer: SELECT ... OPTION (FAST n_rows)
Pohrana podataka
Vrste datoteka/tablica
Matine - dodani zapis ostaje zauvijek u sustavu, moe se mijenjati primjer: Kupac, Artikl, Predmet, OrgJedinica Transakcijske (prometne) zapisi poslovnih dogaaja, ogranieni vijek, uklanjanje zapisa uz arhiviranje primjer: Racun, Prijavnica ifrarnici statiki podaci koji se koriste od razliitih aplikacija radi ouvanja konzistentnosti podataka i poboljanja performansi primjer: Mjesto (potanski brojevi), StatusNecega Dokumentacijske kopije povijesnih podataka za laki dohvat i pregled bez regeneriranja dokumenata Arhivske uklonjene iz medija za direktni (on-line) pristup Dnevnici (audit, log) evidencija pristupa i promjena podataka
Fizika raspodjela
Faktor blokiranja (blocking factor)
broj logikih zapisa koji se obrauju jednim itanjem (fiziki zapis) uobiajeno odreen i automatski podeen, ali se moe i runo ugoditi
Distribucija podataka
raspodjela pojedinih tablica, zapisa i/ili polja u razliite fizike BP ili razliite fizike segmente BP primjer: odvajanje matinih datoteka i ifrarnika od transakcijskih tablica
Replikacija podataka
umnaanje tablica, zapisa i/ili polja u razliite fizike BP primjer: replikacija ifrarnika izmeu baze na posluitelju i BP debelog klijenta
Smjetaj fizikih datoteka

poveanje sigurnosti i brzine pristupa odvajanjem SUBP, podatkovnog prostora, dnevnikog prostora i rezervnih kopija na razliite fizike ureaje primjer: dvije fizike jedinice, etiri logike podjele C:\...\binn\MSSQL.exe D:\...\data\*.mdf E:\...\log\*.log F:\...\backup\*.
259
ifarski sustav
Serijske ifre
brojevi koji se slijedno pridjeljuju svakoj novo dodanoj instanci entiteta u modernim SUBP mogu se generirati uz opcionalna ogranienja primjer: SQL Server IDENTITY [ ( seed , increment ) ]
Izrada ifarskog sustava

Izrada ifarskog sustava
Tamo gdje je to mogue treba preuzeti postojee ifrarnike, od drugih ustanova ili iz postojeih sustava Oznake definirane zakonom ili drugim propisima treba preuzeti i prilagoditi Ostale ifrarnike definirati tako da se naknadno mogu nadograivati
Blok ifre
slino serijskim iframa, s tim da su serijski brojevi grupirani prema znaenju primjer satelitskih TV kanala: 100-199 PAY PER VIEW, 200-299 CABLE CHANNELS, 300-399 SPORT, 400-499 ADULT, 500-599 MUSIC-ONLY, ...
Alfanumerike oznake
ogranieni skup znakovnih oznaka, esto kombiniranih s brojevima primjer, oznake drava: HR, DE, IT, SI
Preporuke za izradu
ifre moraju biti dovoljno velike da opiu eljene karakteristike, ali dovoljno male da se mogu interpretirati bez raunala Sustav ifriranja bi trebao biti smislen i prikladan da dodavanje novih ifara bude jednostavno Izbjegavati samogovoree ifre
Samogovoree ifre (significant position codes)

svaka znamenka ili grupa znamenki opisuje neko svojstvo instance primjer: JMBG, a esto se koriste i u skladinoj evidenciji (dimenzije automobilske gume, elektrine arulje)
Hijerarhijski kodovi
podjela u grupe, podgrupe itd. primjer, ifre predmeta: ZPM03A1 - ZPM 3. izborni u 1. semestru, hijerarhija vojnih sredstava n*m znamenki primjer, IUCN kriteriji ugroenosti vrsta: kriterij-podkriterij-temelj (A1a - redukcija, reverzibilna, direkto opaanje)
Primjeri ifrarnika
Primjer, studentska prehrana
Pravilnikom o studentskoj prehrani propisan je status upisa potreban za ostvariranje prava na subvencioniranu prehranu. Npr. mora biti upisan u tekuu akademsku godinu na redovnom studiju ili studiju za osobne potrebe.
ifra statusa R P U V L O Opis statusa redovan studij paralelni studij studij uz rad vanredni studij paralelni studij s pravom prehrane studij za osobne potrebe Pravo prehrane DA NE NE NE DA DA
Primjer jedinstvene ifre

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

ifra indikatora U R P D B E A Opis indikatora Uvjetno upisuje godinu Upisuje godinu prvi puta Ponavlja godinu rauna se u ponavljanje Ponovo upisuje godinu - ne rauna se u ponavljanje Ponavlja godinu ne rauna se u ponavljanje Prekid studija Upisuje apsolventski rok Pravo DA DA DA DA DA NE DA
Broj kartice generira se automatski, a u sebi sadri 6 grupa znamenki:

A.
B. C. D. E.
jedinstveni broj u meunarodnom kartinom poslovanju (IIN) uvijek 601983 i prema meunarodnom standardu ISO/IEC 7812 na jedinstven nain identificiraju Studentsku karticu u meunarodnom sustavu kartinog poslovanja oznaka vrste kartice (1 znamenka) npr: 1 - student i 4 - privremena kartica redni broj kartice koju je student dobio (1 znamenka) JMBAG (10 znamenki) Kontrolna znamenka (1 znamenka),
264
263
Meta-modeli
Meta-model model baze podataka Meta-baza baza podataka o bazi podataka
Domain DomName TypeName DomLen DomDec Case Just DataMask ValRule Field Required Index Serial Virtual SN Key KeyNo KeyName Form FormName EntName FormWdth FormHght Referent Field RefFldName DomFldName SN Relationship RelName ShortName ParentAlias InsRule DelRule Relationship Field ParFldName ChiFldName SN
Meta-modeliranje
Rjenik podataka Meta-baza Primjena meta-modela
Attribute AttName LongName
Entity EntName ShortName LongName
Key Field SN
Form Field FormName FFldName SN FormFldId VarRow VarCol VarWdth VarHght Label LabRow LabCol LabWdth LabHght
266
Meta-modeli
ZZTables PK TableName Description About PK PK,I1 ZZFields TableName FieldName SN Type Size Required AllowZeroLength DefaultValue AutoNumber ValidateOnSet ValidationRule ValidationText Description TextLen Caption FieldType PK,I3 PK I1 I2 ZZRels szRelationship icolumn szColumn szObject szReferencedColumn szReferencedObject ccolumn grbit
Hi j erarhi j a (Rad no mje sto) Org Cje l in a Pro pi s
Meta-modeli
Poopenje strukture podataka
Opi s proc es a Za ko n V rsta do gad j aj a
V rsta dok ume nta
P la n
Org ani za ci j ski Pra vni In fo rma ci j ski Fi nan ci j ski Ma te ri j al ni
v ez a Os ob a Os ob a na dok ume ntu Do kum ent Doga dj aj na dok ume ntu Doga dj aj
ZZIndexes PK PK,I1 PK,I1 IndexName TableName FieldName Primary Unique Foreign
ZZTypes PK Type TypeName TypeDescription

S ta vk a struk tu ri ran og dok uma nta Osno vn o P otro sn o Teh ni ck o Fi na nci j sk o Nekretn in a Os tal o V rsta s re ds tv a S voj s tv o
P ra vn a os ob a
Fi zi ck a os ob a
Primjer praktine realizacije

S as ta vn ic a s re ds tv a S re ds tv o
S voj s tv o s re ds tv a
267
268
Meta-modeli
Primjer, narudba
Narudba MBB-Nabava za osnovno tehniko sredstvo prema Br. xxxx od xx.xx.200x. Veza: Ponuda poduzea IMB br. xxxx od xx.xx.200x. Narudbu izradio: Pero Odobrio njegov ef: Ivo Stavke: Raunalo IMB estium: xx MBO, CPU, RAM, HDD, CDR, FDD, CASE Monitor 15 xx tampa xx Skener xx poduzeu IMB
S l jak er, Sef
Meta-modeli
Primjer, narudba
MBB Naba va P ra vil ni k o po slo vanj u Opi s pro cesa naruci vanj a Zak on Vrsta d ogadj aj a
Narudzb eni ca
P l an
Pravni Fi nan cij ski Mate ri ja lni
ve za
kom kom kom kom

P rav na oso ba
Oso ba
MB B, Iv o, P ero, IMB
B roj, Datum, P onu da
Narudz ba
Naruci vanj e
Fi zic ka oso ba
Se sti um Moni tor Stampac S kener Osnov no Teh nic ko Vrsta sre dstva S voj stvo
MBO, CP U, RAM, HDD, CDR, FDD
S re dstvo
S voj stvo sre dstva
269
270
Praktina primjena meta-modeliranja

Koris Zaglav SifZag SifMje VrstaDok VrDok StandSifPlac StandSifOtpr StandSifZag StandSifNap Tarifa Mjesto SifMje Napomena SifNap NacinPlac SifPlac TarBroj Otprema SifOtpr Parametar KratParam
Primjer aplikacije nad meta-modelom
Dokument IdDok Partner SifPart SifMje Uplata IdUplate IdDok

Artikl SifArt TarBroj StavkaDok IdDok SifArt
Primjena
VrDok IdPrethDok SifPart SifOtpr SifPlac SIfZag SifNap
Primjer podataka
Definiranje dokumenata
Primjer izrauna
Primjer, raun stanja skladita
SELECT Artikl.SifArt, Artikl.NazArt, SUM(StavkaDok.Kolicina*VrstaDok.PredMat) FROM Dokument INNER JOIN VrstaDok ON Dokument.VrDok=VrstaDok.VrDok INNER JOIN StavkaDok ON StavkaDok.IdDok = Dokument.IdDok INNER JOIN Artikl ON StavkaDok.SifArt = Artikl.SifArt WHERE VrstaDok.PredMat <> 0 AND Artikl.IdeSklad <> 0 AND Dokument.DatSklad IS NOT NULL AND Dokument.DatStorno IS NULL GROUP BY Artikl.SifArt, Artikl.NazArt
273
274
TipPorObveznika
Djelatnost
PK SifDjelatnost Naziv PK
FilPosPar
SifFilPosPar Naziv Opis
Primjer praktine primjene

NacPlacanja
0,1
PK
SifTipPorObv Naziv Kratica
Dokument
PK IDDok God Broj SifDok DatDok IDPredhodniDok Storniran DatStorn DatIspis DatDosp SifPosPar SifPosJed1 SifPosJed2 SifNacPlac Rabat Porez UkupnoBezPoreza Slovima Opis
DokumentBS
PK, FK1 IDDok BrIzvoda OznZaZatvaranje Veza Predmet SifDetOpisRadNal StorKnjizenje BrojRacOdDob OsnovicaZa0Posto OsnovicaZaOporezivanje
Tvrtka
PK Naziv PostBr Adresa SifDrzava Telefon Fax E-mail WWW Ziro-racun1 Ziro-racun2 MatBr SifBanka SifTipPorObv PosGod OtvorenaPosGod PK FK1 FK2
PosPar
SifPosPar Naziv PostBr Adresa SifDrzava Telefon Fax E-mail WWW Ziro-racun1 Ziro-racun2 MatBr SifFilPosPar SifDjelatnost SifBanka Rabat BrDanaOdgode SifTipPorObv SifOsoba Zabiljeske
PosPar
0,1
0,1
DokumentBS
0,M
FK1 FK2
FK2
TipPorObveznika
1,1
1,1
1,1
Banka
1,1
Valuta
0,1
FK1 FK2
0,1 0,M
0,M 0,M
1,1 0,M
PosJed
0,M 0,1
Dokument
0,M 1,1
0,1
IDPrethodniDok
0,1
FK3 FK4 FK5 FK6
DetOpisRadNal
0,1 0,1
0,M
FK3 FK4
Tvrtka
0,1
0,1
Drzava
1,1 1,1
FK3 FK4 FK5
VrstaDok
1,1
FK6 FK7
Drzava
Artikl PopCjenika
0,1 1,1
Stavke
PK, FK1 PK, FK2 IDDok SifArt Kolicina JedinicnaCijenaBezPoreza Tarifa Rabat FK2 FK3 FK4 FK5 FK6 FK7
DokumentSS
PK, FK1 IDDok SifCjenika ModPlacanja Fakturirao Odobrio TekstPrije TekstPoslije OznDevRac SifTecListe DatTec SifVal Rabat UracnatiPorez OpisOstalihTroskova1 PorezOstalihTroskova1 IznosOstalihTroskova1 OpisOstalihTroskova2 PorezOstalihTroskova2 IznosOstalihTroskova2 Aktivan SifTipPred
0,M 0,M
0,M
0,M 0,M
PK FK
SifDrzava Naziv SifVal PK
PosPar
0,M
Banka
SifBanka Naziv
0,M
Adresa
FK3
0,1 0,M 0,M 0,1 1,1 0,M 0,M
Valuta
PK SifVal Valuta Kratica JedIznos
KorProg
0,1
DokumentSS
0,M 0,M 0,M
Stavke
0,M
Adresa
1,1 1,1
1,1
Mjesto
PK PostBr Naziv
Artikl
PK SifArt RedBr Naziv Tip SifJedMje Tarifa JedMasa SifFilArt DugiOpisArt MinZalihe MaxZalihe
FK8
Mjesto
1,1 1,1
FilPosPar
1,1
Osoba
PK SifOsoba Prezime Ime SifPosPar Titula Funkcija SluzTel E-mail Spol DatRod Adresa PostBr SifDrzava PrivTel Zebiljeske
FK9
TipPred
0,1
1,1
Tarifa Datum IznossUKn

0,M 0,M
FK1 FK2 FK3
FK10
Djelatnost
Adresa
0,M 0,1 0,M
FK1
FK11
Osoba
PosJed
Valuta
Tecaj
TecLista
FK2 FK3
275
276
Specifikacija i dizajn programske podrke

Specifikacija programske podrke (software specification), specifikacija programa (program specification)
navoenje svih zadataka koje program treba obaviti meusobne povezanosti razliitih dijelova programa i podataka opis vrste podataka, opis ulaznih i izlaznih podataka specifikacija prikaza podataka \Dokumentacija\SpecifikacijaZahtjeva
Dizajn programske podrke
Dizajn programske podrke (software design) dizajn programa (program design, software design)
proces pretvorbe zahtjeva na programsku podrku u oblik koji omoguuje programiranje opis jezikom za oblikovanje programa (PDL - Progam Design Language) pri emu program napisan pomou PDL nema oblik izvedbenog programa \Dokumentacija\SpecifikacijaDizajna
278
Pristup oblikovanju programa

Funkcionalni pristup (Yourdon, Constantine, 1979)
strukturirani dizajn programske podrke svladavanje veliine i sloenosti programa razradom u hijerarhiju modula programski modul grupa instrukcija
paragraf, blok, potprogram, subrutina
podjela 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 buduim programima
Strukturirani dizajn
mala vanjska zavisnost modula skopavanje (coupling)

moduli trebaju biti minimalno meusobno zavisni minimizacija utjecaja promjene jednog modula na druge module
Podatkovno usmjereni pristup (Jackson, Warnier, 1981)

struktura podataka odreuje strukturu programa
Objektno usmjereni pristup

podjela u razrede (klase) koji istovremeno sadre podatkovne strukture i procedure (metode) koje se obavljaju nad objektima (instancama) razreda kohezija i skopavanje takoer se uvaavaju, a provode kontroliranim nasljeivanjem, sueljima i fasadama izmeu razreda i komponenti
Strukturirani dizajn
Strukturna karta
Strukturna karta (Structure Chart)
modeliranje programske podrke na temelju dijagrama toka podataka dijagram toka podataka prikazuje TO treba postii strukturnom kartom izraava se KAKO ostvariti zahtjeve prikaz hijerarhije programskih modula koji ukljuuje prijenos podataka i upravljanja izmeu razliitih razina obrade prikaz slijedne, ponavljajue i uvjetne obrade elementi prikaza:
podatak (dat a couple)
f unkcija slijed indikator (control couple)
poziv ugraena f unkcija (modul) iteracija selekcija
281
282
Strukturna karta
Primjer, izvjee o poslovanju tvrtke Tajkun & ortaci
datum Sustav izvjea o prodaji zbir zbir Uzmi datum Zapii izvjee Ispii zbir
Transformacijska analiza
Transformacijska analiza (transform analysis)
analiza promjene/pretvorbe podataka primjenjiva na sustave koji imaju strukturu oblika ulazsredite-izlaz, tj. aplikacije s jasno raspoznatljivim ulazima, sredinjom obradom i izlazima, koji se daju prikazati linearnim tokom podataka
sredite
1 C
izlazi
2 I 3
datum
zbir
zbir
ulazi
System
C C I
datum datum
vrijednost EOF vrijednost
zbir
Uspjeh
Katastrofa
Struktura dizajna prikladna za ovakve sustave sastoji se od tri odgovarajua elementa (ulaz, obrada, izlaz), tj. podsustava:
Get C, koji pribavlja podatak C C I, koji obradom pretvara podatak C u podatak I Put I, koji ispisuje rezultat I
Zapii zaglavlje datum EOF itaj podatak
Zapii redak podatak podatak Pii podatak
Raunaj zbir
Get C
CI
Put I
1
3
284
Transakcijska analiza
Transakcijska analiza (transaction analysis)
analiza izvrenja/obavljanja obrade primjenjuje se na sustave sa jasno raspoznatljivim sreditima izvrenja (transaction centre), tj. sustave u kojima se donosi odluka o tome koji e se proces koristiti za pretvorbu ulaza u izlaze (npr. interaktivne aplikacije) ulaz se usmjerava nekom od modula obrade, a pojedini izlazi se kasnije koriste u daljnjoj obradi
Umreeni procesi
Ostale strukture
sustavi koji nisu ni transformacijski niti transakcijski obrauju se na poseban nain najee se oblikuju plonim razlaganjem glavnog procesa u sastavne procese nadreeni proces mora pribaviti sve ulaze potrebne za obavljanje pojedinih podreenih procesa te prikupiti i uvati proizvedene rezultate obrade
Primjer,
sredite zaprima ulaz B, koji se usmjerava (kao B1, B2 ili B3) u odgovarajui proces (3, 4 ili 5) rezultirajui podatak (C1, C2 ili C3) koristi se kao izlazni tok C.
3 B1 2 B B3 5 C1 C2 B2 4 C3 6 C
BC
B3 B1 C1 B2 C3 C2
Primjer
strukturna karta za DTP razloen plonom dekompozicijom
D C 7 E F 9 H 8 G 10 I
E C F F G E H I D
CI
7
5
10
9
286
Sloeni sustavi
Stvarni sustavi primjena kombinacija osnovnih postupaka
3 B1 2 B 1 A Get C
E C B B C F F G E H I I J J D
C1 C2 6 C3 C 7
D F E
G 10 I 11 J 12 K
B2 B3
4 5
C
System
I C I
Opis logike
CI
Put I
H
7 2 and 6: BC
B B1 C1 B2
10
Get B
A A
8
B3 C3 C2
11: I J
J K
Put J
K
Get A
1: A B
12: J K
Put K
287
Dijagram toka (blok dijagram)

Dijagram toka (Flowchart)
grafiki prikaz sustava (system flowchart) - zamjena za fizike DTP programa (program flowchart) usredotoen na akcije koje sustav/program mora obaviti specifikaciju predstavlja skup simbola koji opisuju upravljaki tok za opis akcije ili odluke unutar simbola moe se primijeniti bilo koja notacija, npr. pseudokod ili prirodni jezik nedostaci: veliki skup simbola, veliki i neprikladni dijagrami, nedostatak formalizma, nemogunost opisa podatkovnih struktura, nestrukturiranost, dozvola skokova koji vode uporabi GOTO naredbe tehnika koja (nikako ne) izlazi iz uporabe
Dijagram toka
Primjer
289
290
Blok dijagram
Primjer, postupak prodaje (Visio)
Blok dijagram
Primjer: simboli i blok dijagram sustava (System Architect)
Sales Process
Outside Sales Rep
No
Customer Visit
Proceed?
Pursue Other Leads
Inside Sales Rep
Prospect
Uncover Needs & Benefits Draft Proposal
No
Customer
Accept?
Yes Yes
Sales Manager
Delivery & Follow-up
291
292
Strukturirani prirodni jezik - pseudokod

Strukturirani prirodni jezik (npr. Structured English)
verbalni opis uoblien tako da se ukloni neodreenost, a zadri naracija ugradbeno nezavisan tehnika analize razumljiv korisnicima uitaj (a1,b1,a2,b2) Elementi: ispii (a1,b1,a2,b2) izraunaj nazivnik izraza naredbe - zapovjedne reenice ako su pravci paralelni onda pr. ITAJ, PII ispii poruku blok (odsjeak): inae izraunaj x,y POETAK akcija KRAJ ispii (x,y) selekcija: kraj AKO JE uvjet ONDA akcija1 AKO JE uvjet ONDA akcija1 INAE akcija2 iteracija: DOK JE uvjet RADI akcija PONAVLJAJ akcija DO uvjet ZA izraz RADI akcija
Pseudokod
Pseudokod
nastao pojednostavnjenjem i strukturiranjem prirodnog jezika koristi se kada se eli opisati ugradnja tehnika oblikovanja opis algoritama naslijedio je narativnu formu
Mogue oznake za pisanje pseudokoda: Abc naziv algoritma rezervirana rije pseudojezika za opis algoritama abc ugraena ili trivijalna funkcija (procedura) Abc := pridruivanje zamjena vrijednosti # komentar konstanta ili parametar s skalar vektor v matrica M nul-vektor modul (duljina) vektora v skup Si element skupa kardinalni broj skupa prazan skup
Pseudokod
Primjer, pseudokod procedure za
procedura GenRel(EP, Ec) R := formiranje c za svaki K K formiranje k ako je PrepAlts(EP, Ec) MultAlts() za j := 1 do Min(n) ako je R := kraj GenRel.
Akcijski dijagram
Akcijski dijagram (Action Diagram)
Formalizirana mjeavina strukturiranog prirodnog jezika i pseudokoda
# veza mogua # umnaanje kandidata
# za sve potpuno popunjene # strane kljueve (k = Mj EP Ec) {(EP, Ec, k, Mj)} M = {(EP, Ec, k, Mj)} R = R {(EP, Ec, k, Mj)}
Primjena akcijskog dijagrama

Primjer: generator aplikacija Advantage:Plex
Stablo odluivanja
Stablo odluivanja (Decision Tree)
Stablo odluivanja je binarno stablo u kojem svaki nezavrni vor predstavlja odluku koja se donosi u tom voru zavisno o donijetoj odluci tok programa prenosi se u podstablo vora list reprezentira rezultat niza odluka na putu od korijena do tog lista prikladno za opis sloenih grananja u postupku odluivanja lako razumljivo dobro sredstvo za komunikaciju s korisnicima
Primjer: posjet zoolokom vrtu ivina

ulaz za djecu do 3 godine je besplatan mlade do 18 godina plaa polovicu pune cijene ulaznice djeca ispod 12 godina u pratnji odrase osobe plaaju etvrtinu cijene osobe iznad 18 godina plaaju punu cijenu osim ako su studenti ili umirovljenici, koji plaaju polovicu cijene posjetitelji u grupi imaju 10% popusta na punu cijenu studentski popust ne vrijedi vikendom
297
298
Primjer stabla odluivanja

Primjer: stablo odluivanja za zooloki vrt ivina
Slobodan Pratnja? 3 3-12 12-18 Dob? >18 Student? UM Polovica
DTP Stablo - Pseudokod

Kategorija filma: Ukupan broj filmova koje lan eli iznajmiti: Rok za vraanje posuenog filma:
etvrtina
Hit film Politika iznajmljivanja filmova: Obian film
bilo koliko manje od 3
1 dan 1 dan 3 dana 7 dana
Polovica D Grupa? D
3-6 vie od 6
90%
cijena = 0 ako je hit film tada | rok posudbe = 1 dan | cijena = cijena + (osnovna cijena filma x 1,5) inae | ako je ukupan broj filmova manji od 3 tada | | rok posudbe = 1 dan | | cijena = cijena + osnovna cijena filma | inae | | ako je ukupan broj filmova manji od 7 tada | | | rok posudbe = 3 dana | | inae | | | rok posudbe = 7 dana | | ako film nije trei po redu (svaki trei obian film je besplatan) tada | | | cijena = cijena + osnovna cijena filma 299 FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07. 300
Polovica Vikend? D
N N D Polovica 90% Puna
Puna
Grupa? N
Tablica odluivanja
Tablica odluivanja (Decision Table)
tablini prikaz preslikavanja skupa ulaznih uvjeta u skup izlaznih akcija relativno jednostavni uvjeti ogranieni skupovi moguih odgovora, npr. da/ne ili nisko/srednje/visoko neki alati koji podupiru ovaj nain izrade specifikacija generiraju programski kd razliitih jezika (pr. C, Pascal, Fortran i Basic) dobro sredstvo za opis poslovnog odluivanja
Pravila izrade tablice odluivanja

Preporuljivo je pridravati se slijedeih pravila:
Logika odluivanja treba biti neovisna o tome kojim redoslijedom su uvjeti napisani. Meutim, nije uvijek svejedno kojim su redoslijedom napisane akcije. Potrebno je izbjegavati eventualno dupliciranje izraza i znaenja. U gornjem djelu tablice treba pokuati rasporediti redove tako da oni retci koji sadre vie potvrda uvjeta (znak Y) budu to vie dok oni koji sadre minuse budu nie. Stupce u desnom dijelu tablice treba rasporediti tako da u istom retku oznake "-" budu ispred oznaka Y a ove ispred znakova N.
Politika iznajmljivanja filmova hit film Y Y N Y Y N Y N Y N Y N N Y Y N N Y N Y N N Y N N N Y -
Primjer, proirena tablica odluivanja za zooloki vrt ivina

Uvjeti (condition stub) Dob Pratnja Student Vikend Grupa Akcije (action stub) Slobodan ulaz etvrtina cijene Polovica cijene 90% cijene Puna cijena <3 3-12 D Ispunjenost uvjeta (condition entries) 3-12 12-18 >18 >18 >18 >18 N D D D N N D D D N D Izbor akcije (action entries) X X X X X X X X X
301
>18 N N
UM
ukupan broj filmova vei od 6 ukupan broj filmova 3 - 6 ukupan broj filmova manji od 3 film je trei po redu Akcije rok posudbe je 7 dana rok posudbe je 3 dana
X X X X X X X 302 X
rok posudbe je 1 dan cijena = cijena +(osnovna cijena filma x 1,5) cijena = cijena + osnovna cijena filma
X X X
X X
Struktogram
Nassi-Shneiderman dijagram (Nassi-Shneiderman Chart)
grafiki prikaz programskih struktura bitno prikladniji u odnosu na dijagram toka neprikladan za runu izradu, naroito kada ga je potrebno esto mijenjati
Struktogram
Primjer, Nassi-Shneiderman dijagram u alatu Xper-C (reverzno inenjerstvo C programa i generiranje koda)
Osnovni elementi:
Slijed
Selekcija
Iteracija
303
304
Standardizacija i modularnost
Standardne funkcije modula aplikacije za rad s bazom podataka
Ulaz u modul automatski prikaz podataka na temelju uvjeta / parametera
Standardizacija i modularnost programske podrke
niti jedan zapis svi zapisi odabrani zapisi (primarni klju, uvjet za selekciju zapisa)
Traenje (selekcija) podataka mora podravati traenje 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 zapisa obavlja odgovarajuu provjeru domenskog, entitetskog i referencijalnog integriteta treba omoguiti odabir i po potrebi unos podataka koji se nalaze u drugim tablicama, a povezani su preko stranog kljua
Izmjena postojeeg zapisa omoguuje se promjena vrijednosti prethodno dohvaenog, a trenutno na zaslonu prikazanog zapisa naelno se zabranjuje izmjena vrijednosti identifikatora zapisa dabir referenciranih podataka obavlja se kao kod unosa Brisanje brisanje dohvaenog i prikazanog zapisa uz odgovarajue integritetske provjere i poruke obavlja se uz dodatnu potvrdu Pregledavanje (eng. browsing) prethodno dohvaenih podataka grupni pregled veeg broja dohvaenih zapisa u prozoru
po retcima, po stranicama, skok na prvi/zadnji/n-ti zapis pretraivanje liste podataka po dijelu naziva (filter) po elji moe odabrati jedan ili vie zapisa ili onemoguiti odabir
Poredak (sort) zapisa koji se prikazuju odreivanje poretka prije selekcije naknadni preraspored ve dohvaenih zapisa Zapisivanje izvjea (report) sadraj ispisa
trenutno prikazani zapis svi dohvaeni zapisi
format ispisa
osnovni podatci (ifra i naziv) svi podatci
odredite ispisa
pisa zaslon datoteka (nova datoteka, dodavanje na kraj postojee datoteke)
Izlaz iz modula s prijenosom informacija o odabranom zapisu

primarni klju cijeli zapis
307 308
standardno se prikazuju samo osnovni elementi zapisa (primarni klju i relevantni zavisni atributi)
Primjer, dohvat po uzorku
Pretpostavljena naredba za selekciju podataka SELECT Vrsta.* FROM Vrsta ORDER BY ImenaLat Modificira se u: SELECT DISTINCTROW Vrsta.* FROM (((Vrsta) INNER JOIN Rod ON Vrsta.IdRoda = Rod.IdRoda) INNER JOIN NarodnoImeVrste ON NarodnoImeVrste.IdVrste = Vrsta.IdVrste) INNER JOIN NarodnoIme ON NarodnoImeVrste.IdNarodnogIm ena = NarodnoIme.IdNarodnogImena WHERE Rod.NazRoda LIKE "vitis*" AND NarodnoIme.NazNarodnogImen a LIKE "*loza*" ORDER BY ImenaLat
Primjer, zapisivanje izvjea
Primjer, odreivanje rasporeda
309
310
Ugradnja openitih programskih rjeenja

Standardni modul
Za veinu tablica u bazi podataka dovoljno je napraviti modul s ugraenim standardnim funkcijama. Standardne funkcije ugrauju se tako da se, osim s izbornika unutar vlastitog modula, mogu aktivirati i iz bilo kojeg drugog modula. Poeljno je unaprijed oblikovati standardne module: Modul za obradu pojedinanih zapisa Modul za tablinu obradu Modul tipa glava-stavke (tzv. Master-detail)

Primjer, osnovni standardni moduli
Univerzalni modul
Alternativno, preporua se ugraditi univerzalni modul sa standardnim funkcijama, koji se moe dinamiki prilagoditi tako da obrauje podatke u razliitim tablicama. Univerzalni modul treba realizirati tako da u pogonu moe istovremeno postojati vie instanci istog modula prilagoenih pojedinim tablicama. Ovisno o pojedinom projektu, univerzalni modul moe zamijeniti i preko polovice standardnih modula

Primjer, udruivanje standardnih modula
Maska kreirana kao kombinacija kopija osnovnih maski. Sofisticirane funkcije nadodaju se runo.

Primjer, univerzalni modul za tablinu obradu
Sadri samo osnovne objekte i pozive na standardne procedure (metode) za obradu dogaaja vezanih uz te objekte. U trenutku aktiviranja obavlja se prilagodba tablice za obradu podataka strukturi tablice podataka.
313
314

Univerzalni modul za pojedinanu obradu
Sadri objekte za posluivanje standardnih funkcija te po jednu instancu objekata za prikaz/obradu podataka, koji se prilikom aktiviranja modula dinamiki umnaaju sukladno strukturi tablice. Unaprijed se ugrauju pozivi standardnih procedura vezanih uz standardne funkcije te objekte za prikaz/obradu podataka
Dizajn suelja
315
Suelja
Korisnika suelja
tekstovna, grafika masovni unos (batch input) - periodiko pretipkavanje interaktivni unos (on-line) - na mjestu nastanka
Elementi grafikog suelja za unos podataka

Text Box i varijante
slobodni tekst
Grid mrea, matrica

kombinacije osnovnih elemenata
Radio Button
vrijednosti iz konanog malog skupa unaprijed poznatih, meusobno iskljuivih vrijednosti (2 do 3)
Automatizirani unos
biometrijski ureaji - otisci prstiju, uzorci glasa elektromagnetski ureaji - identifikacija objekata s pomou radio valova magnetski ureaji - magnetske kartice i drugo optiki itai optical-mark reader (OMR), optical-character reader (OCR) pametne kartice (smart cards) - mikroprocesor, memorija, baterija ureaji osjetljivi na dodir - touch screen, touch-pad, pen-based
Check Box
binarne vrijednosti, opcionalno "nepoznato"
Drop-Down ili Combination (Combo) Box

umjereno velik broj (?) poznatih (?), meusobno iskljuivih vrijednosti
Izlazi - izvjea
dokument - npr. prijavnica, raun detaljna - dokumentiranje obrade, povijest i stanja evidencije zbirna - grupiranje, sortiranje, iznimke grafika - tokasti, tapiasti, linijski, torta, ...
List Box
umjereno velik broj (?) poznatih, ne nuno iskljuivih vrijednosti
Spin (Spinner), DomainUpDown, NumericUpDown

nevelik slijed diskretnih vrijednosti
Oblikovanje i standardizacija suelja

Organizacija suelja
Programska oprema mora imati standardan izgled zaslona.
U svakom trenutku mora biti vidljiva informacija o dijelu obrade, vrsti prikazanih podataka, koliini podataka te moguim akcijama.

Primjer, standardni izgled zaslona
podruje za navigaciju - izbornici, pregled podataka podruje za prikaz statusa obrade radno podruje - rad s podacima Sueljem moraju biti podrane razliite vrste izbornika (npr. vertikalni i kruni) uz mogunost brzog odabira (funkcijskom tipkom ili slovom opcije). horizontalni izbornik (menu bar) - uvijek vidljiv, lako dohvatljiv padajui (pull-down) i kaskadni - "nevidljivi", ali se opcije daju grupirati skoni (pop-up) - nije oigledno da postoje, skau na razliitim mjestima trake s ikonama (toolbar) - vidljivi, pamtljivi, problem ikona i skrivanja Tipke za obavljanje standardnih funkcija moraju biti definirane paljivo i jednoznano, a unaprijed treba predvidjeti i one za aktiviranje dodatnih funkcija.
DOSLJEDNOST SUELJA NUAN JE UVJET KOJI PROGRAMSKA OPREMA MORA ISPUNITI.


Ergonomija suelja
Polja zaslonske maske moraju biti logiki grupirana. Unos se mora obavljati u slijedu kojim su polja fiziki poredana. Treba ustrajati na preglednosti podataka i minimizirati prekrivanje informacija (na primjer, u sluaju vie istovremeno prikazanih "prozora"). Suelje mora imati ujednaene standardne poruke, zvune signale i upozorenja, kojima se prua dovoljna informacija, a korisnik nepotrebno ne optereuje. Poruke moraju biti jednostavne, precizne te ovisne o kontekstu. Izbjegavati raunalski argon i kratice. Svakako mora biti ugraena interaktivna pomo ovisna o kontekstu. Prilikom izgradnje suelja treba ukloniti ili prevesti poruke na stranom jeziku (na primjer, one koje koje dojavljuje SUBP) i izbjegavati strune izraze.
"kolski" primjer grafikog suelja
321
322
Drugi primjer grafikog suelja
Trei primjer grafikog suelja
323
324
Opi zahtjevi na funkcionalnost

Funkcionalnost suelja
Poeljno je da se traenje, unos i izmjena podataka obavljaju na istom zaslonu i na isti nain. Treba omoguiti prekid akcija koje predugo traju, pod uvjetom da se tim prekidom ne naruava integritet podataka (npr. selekcija velikog broja zapisa, prekid transakcija). U svakom dijelu obrade treba omoguiti odustajanje uz potvrdu korisnika da se to stvarno eli (pr. brisanje). Upozorenja i potvrde prekida pohrane podataka treba provoditi samo ukoliko je stvarno dolo do promjene. Unesene podatke treba provjeravati to ranije, po mogunosti neposredno nakon promjene sadraja zaslonskog polja. Na polju za unos ifara treba omoguiti odabir iz suenog skupa podataka smjetenih u ifarnik. Suenje skupa treba moi obaviti na temelju dijela tekstovnog opisa ifre uz mogunost uporabe metaznakova. Svakako treba korisniku omoguiti pregled teksta koji e se zapisati u izvjee. Pregled na zaslonu uklanja potrebu za ispisom na papir i olakava prilagodbu uvjeta za selekciju podataka. Dijelove aplikacije kojima se obavlja masovni unos podataka potrebno je prilagoditi kretanje unutar zaslonske maske i minimizirati potreban broj tipki.
Ulanavanje procedura
esto se dogaa da dio rada treba ponititi zbog toga to u sustavu ne postoji ifra koju se eli uporabiti, a nije ju mogue pohraniti.
Problem: korisnik je prisiljen ponititi do tog trenutka unesene podatke, proi kroz nekoliko izbornika do ifarnika, pohraniti novu ifru, vratiti se na mjesto gdje je ona bila potrebna, ponoviti unos prije ponitenih podataka i tek tada ih pohraniti. Rjeenje: na polju za unos vrijednosti stranog kljua treba otvaranje prozora s listom za pregled i odabir zahtijevanog podatka uz prikaz svih zapisa u odgovarajuoj tablici otvaranje liste za pregled uz prikaz ogranienog skupa zapisa na temelju prethodno postavljenog uvjeta aktiviranje funkcije za unos ili izmjenu vezanog podatka aktiviranje itavog modula za obradu vezanih podataka
Programska oprema mora slijediti poslovne procese. Gdje god je to mogue, treba smanjiti broj postupaka za jedan poslovni proces da korisnici ne bi ponavljali iste akcije.
Primjer, stablasta struktura taksonomije
Kingdom Subkingdom Originator Subdivision SpecieOriginator Subclass Order Family Synonym Genus Aggregate Taxon CommonName
327
Division
Class
SubspecieOriginator
328
Organizacija modula i aplikacija

Pri izradi prve globalne podjele modula i definiranju izbornika treba:
paljivo grupirati poslovne procese u sustave procedura, dati prednost uestalijim poslovnim procesima, paziti da se grupiranje obavi po funkcionalnim cjelinama. Primjer, IS za upravljanje osobljem PU MORH:
Podaci o osobama (osobine, civilna i vojna povijest) Ustroj (postrojbe, dunosti, ustrojna mjesta) Tijek slube (prijam, sluba, posebna stanja, izlaz) Dodjela inova i redova, ocjenjivanje Dodjela odlija i medalja kolovanje (povijest, izobrazba u HV) Evidencija prekraja, mjere Razno (naknade, doplatci, ) ifarnici (korisniki i sistemski promjenjivi) Administriranje sustava (baze podataka, korisnika, zatite)

Poetni sustav - moduli pune i reducirane funkcionalnosti
Poetni sustav sastoji se od poetnog izbornika i izvedbenih programa Pi, (i=1,,n), koji sadre glavni program Mi za poziv izbornika standardnog modula, skup standardnih funkcija {F}i te pridrueni reducirani skup funkcija {R}i. x xxxxx x xxxxx x xxxxx x xxxxx Generated x xxxxx x xxxxx x xxxxx x xxxxx menu x xxxxx x xxxxx x xxxxx x xxxxx
P1 M1 F1 R1
P2 M2 F2 R2
Pi Mi Fi Ri
Pn Mn Fn Rn
Postupak
poetni sustav kao skup modula za obradu podataka u jednoj tablici, pri emu svaki od njih podrava standardne funkcije i poziva druge module postupno udruivanje i reorganizacija modula uz naknadno razdvajanje sistemskih od korisniki promjenjivih elemenata
Ovakav nain izrade programske opreme zahtijeva vei poetni trud, ali dugorono donosi prednosti.

Sustav nakon reorganizacije i kodiranja modula
Hijerarhijski izbornik proizvoljne dubine nad izvedbenih programa koji sadre udrueni glavni program Mj , (j) skupova standardnih funkcija, (j) reduciranih skupova funkcija te (j) skupova runo ugraenih funkcija, (j=1,,)
x xxxxx x xxxxx x xxxxx
Hierarchical menu

OOAD, OOLC
P'1 M'1 F'11 R'11 H11 F'1(1) R'1(1) H1(1) F'1 R'1 H1
P' M' F' () R'() H ()
331
Sluajevi koritenja
Use case = Sluaj koritenja (primjene)
Skup scenarija sa zajednikim ciljem koritenja sustava Kupi proizvod
1. 2. 3. 4. 5. 6. 7. 8.
Primjer: Kupi proizvod

Kupac pregledava Web katalog i stavlja proizvode u koaricu Kupac odlui platiti Unosi podatke o otpremi Sustav prikazuje punu informaciju cijeni, ukljuujui otpremu Kupac unosi podatke o kreditnoj kartici Sustav autorizira kupnju Sustav potvruje prodaju interaktivno Sustav alje elektroniko pismo potvrde. U koraku 6, sustav ne uspijeva autorizirati karticu Dozvoliti kupcu ponovni unos podataka o kartici
Scenarij - niz koraka koji opisuju interakciju korisnik-sustav

Primjer scenarija Kupac pregledava Web katalog i stavlja proizvode u koaricu. Kada odlui platiti, unosi podatke o otpremi i kreditnoj kartici te potvruje kupnju. Sustav provjerava autorizaciju kartice i potvruje prodaju interaktivno te putem elektronikog pisma. Autorizacija kreditne kartice je meutim mogla ne uspjeti! Ovo bi bio posebni scenarij.
Alternativa: Neuspjena autorizacija Alternativa: Redoviti kupac

3a. Sustav prikazuje informaciju o otpremi i cijeni te zadnje etiri znamenke broja kreditne kartice 3b. Kupac potvruje prikazane pretpostavljene podatke ili unosi nove Nastavak u koraku 6 primarnog scenarija
333
334
Dokumentiranje sluajeva koritenja

Dokumentiranje sluajeva koritenja
Radi se dokument toka dogaaja Pie se sa stajalita korisnika Sadri detalje o tome to sustav mora omoguiti kada se izvravaju pojedini sluajevi Elementi obrasca za opis sluaja koritenja Autor Datum Sluaj koritenja Sudionik (entitet, actor) Opis Normalni tok Alternativni tok Pred-uvjeti Post-uvjeti Pretpostavke
Primjer UC (1)
336
Primjer UC (2)
Modeliranje zahtjeva na temelju scenarija

UC specificira namjeravano ponaanje sustava.
Prikazuje skup sljedova akcija, ukljuujui varijante. Reprezentira funkcionalni zahtjev na sustav kao cjelinu.
Koristi se
Za opis zahtjeva korisnika u ranoj analizi. Za validaciju arhitekture i verifikaciju sustava u kasnijim fazama.
Analiza sluajeva koritenja (Use Case Analysis)

tehnika analize poslovnih procesa iz perspektive korisnika sluajevi koritenja uobiajeni su u metodama objektne analize, u kojima se crtaju kao dijagrami, se ali se koriste i u drugim modernim metodama
Opi standard izrade UC-a ne postoji.

ak ni UML ne specificira UC standard! U prethodnom primjeru alternativa Redoviti kupac mogla je biti zasebni sluaj koritenja Postoje takoer dodatni elementi, npr. pretpostavke koje moraju biti zadovoljene da bi sluaj zapoeo
Dijagrami sluajeva koritenja

Sudionik, glumac (actor)
Uloga koju ima korisnik u odnosu na sustav Netko ili neto u uzajamnom djelovanju (interakciji ) sa sustavom Prouava se da bi se odredile njegove potrebe
Vrste veza
asocijacija (association) veza komunikacije u kojoj oba objekta mogu slati i primati poruke ukljuivanje (include) povezuje dijelove ponaanja istovrsne ili sline za vie sluajeva ponaanja proirenje (extend) za varijacije normalnog ponaanja uz dodatna pravila generalizacija (generalization), poopenje slinog sluaja Specijalizirani sluaj "dijete" nasljeuje ponaanje i znaenje opeg sluaja "roditelj"
Dijete moe dodati ili prekriti ponaanje roditelja Dijete moe supstituirati roditelja gdje god se pojavi
Sluaj ponaanja (use case)

Primjer, uzorak, obrazac ponaanja Slijed povezanih transakcija u kojima sudjeluju glumac i sustav
UC dijagrami predouju veze izmeu glumaca i sluajeva
naziv sluaja koritenja
Naziv sudionika
339
340
Dijagram sluajeva koritenja

Objektno usmjerena paradigma
entiteti iz stvarnog svijeta opisuju se apstraktnim objektima (razredima, klasama objekata) integracija oblikovanja podataka i procesa tokovi podataka, entiteti i veze te procesi integrirani u objekte sloeni sustavi grade se iz pojedinanih komponenti.
PROIZVOD SifProizvoda# NazProizvoda TipProizvoda DodajProizvod() BrisiProizvod() IzmijeniProizvod() Dodaj proizvod (Igla trikaa 05)
RacunajMasu(Igla trikaa 05)
IGLA Duljina Promjer

AVION BrSjedala DoletKM

342
RacunajMasu() FER-ZPM-GRZ, Fertalj & Kalpi:RacunajMasu() Projektiranje informacijskih sustava, akad.god. 2006/07.

Elementi objektnog modela
objekt - svaka pojava, pojam ili predmet (stvarni ili zamiljeni) o kojem se prate podatci i naini rukovanja podatcima (procesi) tip objekta ili razred objekta (abstract data type, class) generalizacija grupe objekata, zajedniki naziv za sve objekte sa zajednikim svojstvima (property) i nainima rukovanja (process, method), npr. Proizvod pojava objekta (object instance) pojedinana pojava nekog tipa objekta, s vlastitim vrijednostima svojstava, npr. Igla trikaa 05, B-2 uahurivanje (encapsulation) - podatkovne strukture i procedure povezuju se u cjelinu tako da su detalji ugradnje sakriveni objekti su crne kutije ijim se podacima rukuje putem ugraenih metoda razmjena poruka (messaging) objektu se alje poruka da bi izveo neku od svojih metoda, npr. Dodaj proizvod nasljeivanje (inheritance) podrazred (subclass) nasljeuje svojstva i metode nadrazreda (superclass), npr. Igla i Avion nasljeuju Proizvod vieoblije (polymorphism) postupci koje objekti razliitih razreda tumae zavisno o specijalizaciji objekta, npr. RacunajMasu(Igla trikaa 05)

Cilj objektno usmjerenog pristupa je analizirati stvarni sustav na takav nain da se za potporu njegovom djelovanju moe oblikovati programski sustav koji se velikim dijelom gradi od prije definiranih objekata.
Ukoliko se izrauju jedinstvena rjeenja (unikati) po mjeri unaprijed poznatog korisnika, onda primjenjivost ovog pristupa moe postati upitna.
Neke objektno usmjerene metode

OMT (Object Modelling Technique) BOOCH (Booch93) Schlaer-Mellor
Programska izvedba
objektno usmjereni jezici, npr. Smalltalk, Eiffel, Java, C# hibridni jezici (3GL s objektnim svojstvima), npr. C++ i VBasic
344

Faze objektno usmjerenog razvoja IS
Faza odreivanja svih moguih sluajeva (UC - Use Case) odreuju se svi mogui scenariji interakcija u sustavu Objektno usmjerena analiza (OOA - Object Oriented Analysis) definiraju se razredi objekata kojima e se tono opisati sustav podruja primjene
UML
UML = Unified Modeling Language
Objedinjeni (univerzalni) jezik za modeliranje Standardni jezik za prikaz, specifikaciju, izradu i dokumentiranje elemenata sustava zasnovanih na programskoj podrci Proirenje osnovne funkcionalnosti stereotipovima (kalupima) Moe se koristiti tijekom cijelog ivotnog ciklusa razvoja i preko razliitih tehnologija ugradnje
OO model
prouavanje postojeih objekata da bi se vidjelo mogu li biti ponovno iskoriteni ili prilagoeni za nove primjene definiranje novih ili modificiranih objekata koji e se kombinirati s postojeim objektima u novu aplikaciju
Objektno usmjereno oblikovanje (OOD - Object Oriented Design) definira stvarne klase i objekte te njihove mehanizme, pri emu se odreuju detalji o buduim fazama OO model softverskog sustava
razrada definicija zahtjeva na objekte napravljenih tijekom analize revizija karakteristika podataka i procesa definiranje novih skupova objekata, npr. objekata suelja za oblikovane podatke
Sadri koncepte za
Modeliranje podataka (Entity Relationship Diagrams) Modeliranje poslovnih procesa (Business Modeling - workflow) Modeliranje objekata (Object Modeling) Modeliranje komponenti sustava/softvera (Component Modeling)
Objektno usmjereno programiranje (OOP - Object Oriented Programming) programski se ugrauju klase i njihove meusobne veze Faza procjene (OOE - Object Oriented Evaluation) evidentiraju se pogreke i problemi
Vizualno modeliranje
Dijagrami strukture, Strukturalni dijagrami
Class Diagram Object Diagram Component Diagram Deployment Diagram Prikaz granica sustava i njegovih glavnih funkcija prikazom sluajeva koritenja i sudionika (glumaca) Ilustracija izvrenja sluajeva koritenja dijagramima interakcije Prikaz statike strukture sustava dijagramima razreda i dijagramima objekata Modeliranje ponaanja objekata dijagramima prijelaza stanja Prikaz fizike ugradnje arhitekture dijagramom komponenti i dijagramom razvijanja
Dijagrami razreda
Class Diagrams
Dijagrami ponaanja
Use Case Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram
347
Razredi
Razred (class) = kolekcija, skup objekata sa zajednikom strukturom, zajednikim ponaanjem, zajednikim vezama i zajednikom semantikom, na primjer cOsoba Objekt pojedinana pojava (objekt, instanca) iz nekog razreda, na primjer Zagor i iko razreda cOsoba Definiranje razreda
Naziv Opis (komentar) slobodan tekst u vitiastim zagradama Atributi - struktura kojom su odreena svojstva objekata Operacije - procesi/servisi koje razred (objekt) zna obaviti, ime se odreuje ponaanje objekata
/ * autor: Hrvoje Novak */ Class Osoba { private string ime; private string prezime; public string PrezimeIme () { return ime + " " + prezime; } }
Dijagrami razreda
Dijagrami razreda (Class Diagrams)
Prikaz statike strukture sustava, odnosno njegovih elemenata (pr. razredi i tipovi), te njihovih meusobnih odnosa. Dijagram razreda moe sadravati i suelja (interfaces), pakete (packages), odnose (relationships) te instance kao to su objekti (objects) i veze (links). Bolji naziv bio bi 'statiki strukturni dijagram' (static structural diagram).
Elementi dijagrama
Razredi, njihova struktura i ponaanje (atributi i operacije)
Statiki odnosi
Obine veze ili asocijacije (associations) npr. "korisnik posuuje vie video-kazeta" Gomilanje ili udruivanje, agregacija (aggregation), npr. "motor je dio aviona" Zavisnost (dependency) i nasljeivanje (inheritance) npr. "bolniarka je osoba"
Dodatne oznake
Indikatori mnoine, mnogostrukosti (multiplicity) - kardinalnost Indikatori upravljivosti, navigabilnosti (navigability) smjer povezivanja Uloge (role names)
350
Vidljivost atributa i operacija

+ # ~
Javna (public) lanovi dostupni svima Zatiena (protected) unutar razreda/podrazreda Privatna (private) unutar razreda, lanovima Implementacijska unutar paketa Veze izmeu objekata
Asocijacije
Svaka asocijacija ima dva zavretka asocijacije (association ends), od kojih je svaki spojen s jednim razredom.
Uloge (role)
labele na kraju veze, postavljaju se blie razredu na koji se odnose mogu se izostaviti
Ogranienja (constraint)
uvjet povezivanja
Indikator mnogostrukosti (multiplicity)

kardinalnost
Indikator upravljivosti (navigability)

Odjel pravo pristupa private pravo pristupa protected pravo pristupa public
{ { {
- naziv: Name - nastavnici: Nastavnici[] # dodajNastavnika() # ukloniNastavnika() + dohvatiNastavnika() + dohvatiSveNastavnike()

351
strelica oznaava smjer povezivanja jednosmjerna - preporua se tamo gdje nema posebnih uloga, mora se navesti ako postoji uloga dvosmjerna (standardno) moe ukljuiti stereotip (npr. friend)
352
Mnogostrukost
Oznaava broj objekata koji sudjeluju u vezi Prikazuje s koliko se objekata JEDAN objekt moe povezati Gleda se nezavisno za svaku stranu veze Najee upotrebljavane oznake za mnogostrukost u praksi su 1, *, 0..1 (jedan ili niti jedan). Za prikaz mnogostrukosti moe se koristiti diskretan broj
npr. 11 za broj lanova nogometne ekipe), niz brojeva (npr. 2..4 za igrae koji sudjeluju u kartakoj igri), kombinacije diskretnih brojeva ili brojeva u nizu (npr. 2, 4 za broj vrata na automobilu).
Dijagram razreda (class diagram)
Indikator 0..1 1 0..* ili * 1..* X,Y,Z N 0..N 1..N
Znaenje Niti jedan ili jedan Samo jedan Niti jedan ili vie Jedan ili vie X, Y ili Z objekata Samo N objekata gdje je N>1 Od nula do N objekata gdje je N>1 Od jednog do N objekata gdje je N>1
353
354
Upravljivost
Primjer: odgovornost od narudbe prema kupcu Specifikacijski,
Upravljivost ukazuje na to da za svaku narudbu moramo znati kojem kupcu ona pripada. Za pojedinog kupca ne moramo znati sve njegove narudbe.
Person -employee 1..*
Primjer
WorksFor -employer 0..1 Company
Implementacijski,
Upravljivost pokazuje da razred Narudba ima pokaziva na razred Kupac, ali razred Kupac ne mora imati pokaziva na razred Narudba.
Konceptualno,
upravljivost nema neko posebno znaenje
// Person ima jednoznanu vezu prema Company, pa // getCompany moe vraati vrijednost tipa Company class Person { private Company _Employer; public Company getCompany() ; } // Company ima vieznanu vezu prema Person, pa // getPersons vraa kolekciju ili Vektor objekata // razreda Person. class Company { private Set _Employees; public Set getPersons_collection(); private Vector _Persons; public Vector getPersons_vector(); }
355
356
Generalizacija
Odnos izmeu openitog i njemu odreenijeg elementa
nadreeni razred ili tip (superclass, supertype) podreeni razred ili tip (subclass, subtype)
Generalizacija
Sve to vrijedi za nadreeni element vrijedi i za podreeni element, ali ne i obrnuto

Strelice oznaavaju odnose derivacija: proiruje, implementira, "je tipa", "ima obiljeja od", itd.
Primjer:
Osoba je Fizika osoba ili Pravna osoba
diskriminator
357
358
Tumaenje generalizacije
Konceptualno
Razred Pravna osoba je podtip razreda Kupac, ukoliko su sve pojave razreda Pravna osoba istovremeno i pojave razreda Kupac. Pravna osoba je samo posebna kategorija kupca. Sve to moemo rei o razredu Kupac asocijacije, atributi, operacije, takoer vrijedi za razred Pravna osoba.
Nasljeivanje, vieoblije i zamjenjivost

Nasljeivanje
Omoguuje definiranje (deriviranje) novog razreda na temelju postojeeg razreda
Vieoblije (polymorphism)
Operacija deklarirana u osnovnom razredu biva ponitena u korist operacije jednako deklarirane u naslijeenom razredu. Podtip na pojedine naredbe daje drugaiji odgovor u odnosu na nadtip ili neki drugi podtip. Gledajui sa strane pozivatelja, ta razlika nije bitna.
Specifikacijski (subtyping, nasljeivanje veza)

Generalizacija znai da suelje podtipa mora ukljuiti sve elemente suelja nadtipa. Za suelje podtipa kae se da je usklaeno sa sueljem nadtipa.
Implementacijski (subclassing, implementacijsko nasljeivanje)

Podrazred nasljeuje sve postupke i atribute nadrazreda, te moe sadravati jo neke, sebi svojstvene postupke. Podtipovi se mogu ugraditi i putem delegata bez koritenja podrazreda - Gamma, Helm, Johnson i Vlissides (1995) - primjeri koritenja dvaju razreda s istovrsnim vezama bez upotrebe podrazreda. Fowler (1997) prikazuje jo neke druge naine implementacije podtipova.
Zamjenjivost (supstitutability)
Razred je podtip osnovnog razreda ako je u aplikaciji mogue zamijeniti osnovni razred podtipom, a da aplikacija normalno nastavi s radom. Drugim rijeima, ako postoji kd koji se odnosi na nadtip Kupac, umjesto njega moe se supstituirati bilo koji njegov podtip.
359
360
Primjer nasljeivanja
class Kupac { public void PisiAdresu() { } } class PravOsoba: Kupac { public string VrstaRacuna() { return "R-1"; } } class FizOsoba: Kupac { public string VrstaRacuna() { return "R-2"; } } FizOsoba f = new FizOsoba(); f.pisiAdresu(); // inherited from base class string s = f.VrstaRacuna(); Kupac k = f; k.pisiAdresu(); // introduced in derived class
Agregacija
Agregacija (aggregation), sadravanje, obuhvaanje
poseban oblik asocijacije: veza "dio-od", "cjelina-dio" odnos se moe kvantificirati mnogostrukost
Komponente su dijelovi objekta-agregata, takvi da

dio moe nastati i postojati nezavisno od cjeline unitenje "cjeline" ne unitava njene dijelove
Objekt moe pripadati u vie cjelina

istu instancu nekog objekta moe dijeliti vie agregata
Agregacija je jednosmjerno tranzitivna

ali objekt (instanca) ne moe biti svoj sastavni dio pr. Organizacijska struktura poduzea
// subclass as base class
361
362
Kompozicija
Kompozicija (Composition)
"stroa" varijanta agregacije objekt moe pripadati samo jednoj cjelini
Agregacija i kompozicija
StudentskaSluba - studomati: Studomat 1 + dohvatiStudomat() + dohvatiSveStudomate() + azurirajStudomat() + azurirajSveStudomate()
Odjel
Studomat 3
Elementi postoje tako dugo dok postoji cjelina

kaskadno brisanje, tj. unitenje sastavnih objekata
+ prijaviIspit() + odjaviIspit()
Fakultet
{persistent}
Kompozicija nije tranzitivna

agregacija i generalizacija jesu
naziv: Name adresa: String telefon: Number dodajStudenta() ukloniStudenta() dohvatiStudenta() dohvatiSveStudente() dodajOdjel() ukloniOdjel() dohvatiOdjel() dohvatiSveOdjele() 1..* ima 1
{persistent}
0..1
naziv: Name 1..* dodajNastavnika() ukloniNastavnika() dohvatiNastavnika() dohvatiSveNastavnike() 1..* 1..*
Ne postoji u Javi ! Primjer C++

class Prozor { Obj *scrollbar; Obj naslov; public: Prozor() { scrollbar = new Obj; } ~Prozor(){ delete scrollbar; } };
polaznik
pridruen 0..1 * predstojnik Nastavnik

{persistent}
* Student
{persistent}
pohaa * *
1..* Predmet
{persistent}
predaje *
naziv: Name MBstudenta: Number
naziv: Name MBodjela: Number
naziv: Name 1..* MBnastavnika: Number
364
Primjer agregacije i rekurzije

class Firma { private Djelatnik[] nadnicar = new Djelatnik[n]; public void Daj_mi_povisicu( Djelatnik e ) { ... } } class Djelatnik { private Firma vlasnik; private Djelatnik sef; private Vector sluga = new Vector(); public void Otpusten_si() { ... } }
Primjer kompozicije
class Studomat{ class StudentskaSluzba{ public: public: Studomat(); StudentskaSluzba(); virtual ~Studomat(); virtual ~StudentskaSluzba(); void prijaviIspit(); void dohvatiStudomat(); void odjaviIspit(); }; void dohvatiSveStudomate(); void azurirajStudomat(); void azurirajSveStudomate(); private: Studomat studomati[3]; }; StudentskaSluba Studomat StudentskaSluzba ::~StudentskaSluzba(){ - studomati: Studomat 1 3 delete [] studomati; + prijaviIspit() + dohvatiStudomat() + odjaviIspit() } + dohvatiSveStudomate()
+ azurirajStudomat() + azurirajSveStudomate()
365
366
Asocijacijski razred
Asocijacija s obiljejima razreda - razred s obiljejima asocijacije
Koristi se kada se od razreda zahtijeva da definira odnose. Nastaje dodavanjem atributa i operacija asocijaciji ogranienje: smije postojati samo jedna instanca asocijacijskog razreda za par povezanih objekata, inae postaje pravi razred
Suelja i apstraktni razredi

Suelje (interface) - Specifikacija vanjski vidljivih postupaka razreda ili komponente bez implementacije.
Sadri samo deklaracije (prototipove) operacija esto specificiraju samo ogranieni dio ponaanja razreda. Mogu se generalizirati.
Ponekad je potrebna dodatna veza za prikaz vlasnitva Primjer: veza izmeu osobe i avionske karte
Deklarira se apstraktnim razredom

U C++, suelje je razred koja sadri iste virtualne postupke. Java ih direktno podrava, npr. "abstract class" moe sadravati definicije za postupke i polja uz apstraktne deklaracije.
Realizacija (realisation): veza izvornog razreda i suelja Proirena i skraena (lollipop) notacija
367
368
Primjer prikaza suelja

StoreHome POSterminalHome POSterminal <<use>> POSterminal Store -storeId: Integer -POSlist: List <<interface>> Store +getPOStotals(POSid) +updateStoreTotals(Id,Sales) +get(Item) +create() +login(UserName, Passwd) +find(StoreId) +getPOStotals(POSid) +updateStoreTotals(Id,Sales) +get(Item)
Objektni dijagrami
Objektni dijagram (Object diagram)
Sadri aktualne (instancirane) objekte te, opcionalno, razrede kojima ti objekti pripadaju Koriste se za ilustraciju ili objanjenje nekog trenutka Class1
instantiates
Object1: Class1
arg1 = value1
StoreHome POSterminalHome POSterminal POSterminal Store <<use>> Store -storeId: Integer -POSlist: List +create() +login(UserName, Passwd) +find(StoreId) +getPOStotals(POSid) +updateStoreTotals(Id,Sales) +get(Item)
order: return := event3 (arg4 ..)

data flow
Object2: Class2
arg2 = value2
Adornments A - association link F - object field G - global variable L - local variable P - procedure parameter S - self reference
369
Synchronisation - simple - synchronous - balking - timeout - aysnchhronous
370
Razredi i instance objekata

Prikazuje se
Naziv objekta (potcrtano) Naziv razreda (opcionalno) Vrijednost atributa (opcionalno)
Primjer objektnog dijagrama
Prodavatelj Dijagram razreda
Narudzba Kupac
Stavka
Task startDate : Date = 1.1.01 endDate : Date = 1.6.01 setStartDate (d : Date = default) setEndDate (d : Date = default)
tefica Cvek
<<instanceOf>>
Nar 121: Narudzba Dom i vrt : Kupac : Narudzba Krkatone :
stavka1: Stavka stavka2: stavka3: stavka1: stavka1: stavka2:

372
imenovana instanca
<<instanceOf>> Assignment 1: Task startDate = 1.2.04 endDate = 23.2.04
<<instanceOf>> Assignment 2: Task startDate = 1.3.02 endDate = 23.3.02
Assignment 3: Task startDate = 1.4.03 endDate = 23.4.03
Dijagram objekata
anonimna instanca instanca siroe
371
Realizacija sluajeva koritenja

UC dijagrami prikazuju vanjski pogled na sustav Dijagrami interakcije
opisuju realizaciju sluajeva koritenja, pri emu jedan dijagram uobiajeno prikazuje ponaanje pojedinanog sluaja koritenja prikazuju objekte sustava i njihovo meusobno djelovanje opisuju ponaanje vie objekata i poruke koje se razmjenjuju izmeu tih objekata
Dijagrami interakcije
Interaction Diagrams
Vrste dijagrama interakcije

Dijagrami slijeda (Sequence diagrams) vremenski pogled Dijagrami suradnje (Collaboration diagrams) organizacijski pogled
374
Dijagram slijeda
Prikaz interakcije grupa objekata porukama u vremenskom slijedu
Prikazuju interakciju objekata u vremenskom slijedu. Koriste se za specifikacije sustava za rad u stvarnom vremenu i kompleksne scenarije
Primjer slijeda
Poslane poruke Povratak iz metode

moe se crtati za svaku poslanu poruku, ali je dijagram itljiviji ako se podrazumijeva da postoji, a crta samo tamo gdje je to nuno radi jasnoe
Notacija
Kuice predstavljaju objekte, ne razrede. Nazivu se moe dodati ":class". Objekti i/ili razredi prikazani horizontalno na vrhu isprekidanih vertikalnih crta, linija ivota Poruke prikazane strelicama izmeu linija ivota objekata koji komuniciraju Linija ivota (lifeline): ivot objekta za vrijeme interakcije
375
376
Tumaenje dijagrama slijeda

Objekti
prvi stupac: uobiajeno sudionik koji inicira sluaj koritenja drugi stupac: granini objekt (boundary object), kojim sudionik pokree sluaj koritenja ostali stupci: objekti koji upravljaju sluajem koritenja
Pokretanje slijeda
Sudionik, dogaaj, granini objekt i operacija
Poruke
Poruka predstavlja poziv postupka referenciranog objekta Poruke se oznaavaju barem nazivom poruke Oznaka se moe proiriti argumentima poruke te povratnim vrijednostima i/ili upravljakim informacijama
Vremenska os
nelinearna, odreena dogaajima ita se s vrha prema dnu prikazuje redoslijed, a ne stvarno vrijeme
Linija ivota objekta

povezuje postojanje i cjelokupno ponaanje objekta redoslijed linija nema posebno znaenje Izlomljena linija ivota oznaava da objekt nije aktivan, kvadrat oznaava da je objekt aktivan.
377
378
Stvaranje i unitenje objekta

Poruka moe inicirati stvaranje novog objekta Nova instanca pojavljuje se na kraju strelice poruke za stvaranje. Aktivacijski odjeljak (activation box): oznaka da je objekt aktivan
u sluaju proceduralne interakcije, to moe znaiti da je na stogu
Vrste poruka
Jednostavna:
tumai se kao asinkrona
Sinkrona:
"pozivi", prikazani punim vrhom strelice, pri emu pozivatelj eka na zavretak aktivirane metode
Unitenje objekta (deletion, destruction):

objekt unitava sam sebe ili ga drugi unite slanjem poruke
Asinkrona:
"signali", prikazani polu-strelicom, ime se oznaava da poziv ne blokira poiljatelja poruke Primatelj odmah odgovara. Poiljatelj i primatelj rade simultano.
Unitavanje se obavlja prekidom linije ivota velikim X
379
380
Povratni pozivi i uvjetovane poruke

Asinkroni povratni pozivi (callback)
Povratni poziv pojavljuje se dok Poiljatelj potencijalno izvodi neto drugo. Samo-pozivanje (self-call, selfdelegation): poruka koju objekt alje samome sebi
Primjer dijagrama slijeda

Ekran za unos narudbe alje poruku pripremi() objektu Narudzba, koji prosljeuje odgovarajuu poruku pojedinoj stavci Svaka stavka provjerava danu stavku skladita i ovisno o tome pokree daljnje akcije
Unos narube
Uvjetovane poruke
Poruka se alje samo ako je uvjet zadovoljen. Uvjet je obino izraen implementacijskim jezikom.
Narudba
1: pripremi()
Stavka narudbe
3: provjeri() 4: [check = true] ukloni()
Iteration Condition
Stavka skladista
Self delegation
2: * pripremi()
5: ponovnoNaruci()
6: [ponovnoNaruci = true] <<create>>
Asynchronous Message
Ponovljena stavka
Activation
381
382
Primjer: Web kupovina
Dijagram kolaboracije, suradnje

Prikaz interakcije objekata koji naglaava meusobnu povezanost objekata Koristi se notacija slina dijagramima slijeda Ne pokazuje vrijeme kao posebnu dimenziju, pa slijed interakcija mora biti oznaen rednim brojevima poruka.
383
384
Oznaavanje poruka
Oznaavanje rednim brojevima (1, 2, 3, ...)
problem pri umetanju
Primjer dijagrama suradnje

J.Rumbaugh, I. Jacobson, G. Booch : The Unified Modeling Language Reference Manual. Addison Wesley, 1999, fig 13-51 page 202
Oznaavanje "decimalnim" brojevima (1, 1.1, 1.2, 2, 2.1, 2.2, ...)

jasnije oznaavanje koja operacija koju zove "decimale" ukazuju na ugnijedene poruke, to jest one koje su poslane dok je poetna jo aktivna tee praenje ukupnog slijeda
Proirenja
slovane oznake za vietnitne operacije oznaavanje povratnih vrijednosti
385
386
Dijagram slijeda naspram dijagrama suradnje

Dijagrami slijeda
naglasak na izmjeni poruka u vremenu koriste se pri odreivanju redoslijeda poruka
Prikaz suradnje dijagramom slijeda

Opis suradnje moe se nadopuniti dijagramom razreda
prodavatelj:Stranka reklamirati robu kupac 1:Stranka kupac 2:Stranka
Dijagrami suradnje
bolja preglednost scenarija i veza izmeu objekata koriste se pri odreivanju veza izmeu razreda
dati ponudu dati ponudu odbiti ponudu prihvatiti ponudu Ponuda * kupac 1 prodavatelj 1 * Roba 1
Obje vrste dijagrama moraju biti jednostavne i pregledne, to je u praksi dosta teko postii Najee se za konkretnu situaciju radi samo jedna vrsta dijagrama
Stranka
387
388
CRC kartice
CRC = Classes-Responsibilities-Collaboration
Ward Cunningham i Kent Beck, kasne 80-te, uei Smalltalk nadomjestak za dijagrame suradnje
Razred
Odgovornosti Suradnici
Dijagrami stanja
State Diagrams
opis svrhe razreda zadaci razreda (kasnije postaju operacije razreda)
razredi koji zahtijevaju izvrenje zadataka
primjer Narudba
Odgovornosti Suradnici
provjeri raspoloivost robe na sklad. odredi cijenu robe provjeri valjanost plaanja otpremi robu
StavkaNarudzbe Kupac
389
Dijagram stanja
Prikaz ponaanja objekta nekog razreda Opisuje mogui slijed djelovanja i stanja kroz koje element moe proi za vrijeme svog postojanja kao rezultat reakcije na dogaaje (npr. signale).
sva mogua stanja objekta razreda dogaaji koji uzrokuju prijelaz iz jednog stanja u drugo nain promjene stanja pod utjecajem uzronih akcija (poruka koje objekt prima) opis ponaanja objekta kroz razliite sluajeve koritenja
Elementi notacije
Stanje
skup vrijednosti koje opisuju objekt (njegove uvjete/situaciju) u odreenom vremenskom trenutku odreeno zateenim vrijednostima atributa
Opis stanja
entry: akcija koja se obavlja pri ulasku u stanje exit: obavlja se pri izlasku iz stanja do: aktivnost koja se provodi dok je objekt u nekom stanju (npr. prikai prozor) on: akcija koja se izvodi kao posljedica odreenog dogaaja
Dogaaji
zaprimljene poruke ili signali ne moraju promijeniti stanje objekta => samo-prijelaz (self-transition)
Stara tehnika koja se pojavljuje pod razliitim nazivima

dijagram prijelaza stanja (state transition diagram) Harel diagram (statechart, 1987)
Akcija:
vezana uz prijelaz stanja, pojavljuje se "brzo" i nije prekidiva
Aktivnost:
pridruena stanju, moe dulje trajati i moe se prekinuti
391
392
Stanja i prijelazi stanja

Poetno stanje (start, Start state)
nije dozvoljeno okidanje dogaaja samo jedno, ali se prijelazi mogu granati
poetak
Primjer stanja narudbe
/uzmi prvu stavku [Nije sve provjereno] /uzmi slijed.stavku Provjera radi/provjeri stavku [Sve stavke provjerene i nekih stavki nema] Stavka je primljena [neke stavke nisu na skladitu] ekanje [Sve stavke provjerene i sve stavke dostupne] Stavka je primljena [sve stavke dostupne] Slanje radi/zaponi slanje
Zavrno stanje (stop, End state)

zavrava rad (stroja s konanim brojem stanja) moe ih biti vie
Prijelaz stanja
usmjerena veza koja oznaava promjenu stanja
Uvjet prijelaza (Guard condition)

logiki uvjet koji mora biti zadovoljen da doe do prijelaza stanja vie uvjeta za promjenu istog stanja su meusobno iskljuivi
aktivnost
Isporueno
prijelaz Isporueno
Dogaaji, uvjeti i akcije prijelaza su opcionalni

prijelaz bez dogaaja zapoinje im zavri aktivnost pridruena stanju
Initial state
Event(arguments ) [condition] / action
State B
samo-prijelaz
stanje
Obustavljeno
394

Poetak dijagrama oznaen je simbolom poetnog stanja.
U stanje "Provjera" ulazi poetni prijelaz koji ini samo akcija "uzmi prvu stavku". Nakon toga ulazi se u stanje "Provjera", koje sadri aktivnost "provjeri stavku".

Stanje "ekanje"
Ne postoji aktivnost u tom stanju, ve se eka na dogaaj "Stavka je zaprimljena (na skladite)". U sluaju novog dogaaja, gleda se koji je uvjet ispunjen. U naem primjeru, da li su sve ili samo neke stavke na skladitu. Ako su nakon dogaaja sve stavke na skladitu, prelazi se u stanje "Slanje", a ako se nakon toga eka na jo barem jednu stavku, vraa se u stanje "ekanje"
Kad postoji dogaaj, eka se njegovo ispunjenje da bi akcija zapoela. Inae, prijelaz se dogaa odmah nakon zavrene aktivnosti.
Prijelazi nakon stanja "Provjera" nemaju dogaaja.
Stanje "Slanje"
Aktivnost stanja "Slanje" je "Zaponi isporuku". Iz ovog stanja postoji jedan, neuvjetovani prijelaz, iji je okida dogaaj "Isporueno", a ne zavretak aktivnosti stanja ! Kad zavri aktivnost "Zaponi isporuku", narudba ostaje u tom stanju dok se ne dogodi dogaaj "Isporueno". A prijelaz e se dogoditi uvijek kad nastupi dogaaj "Isporueno"
Postoje tri mogua prijelaza nakon stanja "Provjera", s tim da se uvijek samo jedan prijelaz moe (i treba) dogoditi.
ako nisu provjerene sve stavke, uzima se slijedea stavka i vraa se u stanje "Provjera", ako su sve stavke provjerene i dostupne (a to znai da su na skladitu), prelazi se u stanje "Slanje", ako su sve stavke provjerene, ali nisu sve i dostupne, prelazi se u stanje "ekanje" da roba doe na skladite.
396
Kompozitna stanja
Nadomjestak za 3 prijelaza obustavljeno
Ime kompozitnog stanja Aktivan [Nije sve provjereno] /uzmi slijed.stavku [Sve stavke provjerene i sve stavke dostupne]
Konkurentna stanja
Primjer: Provedba autorizacije
kada aktivnost "Provjeri plaanje" zavri, signalizira da li je plaanje u redu ako plaanje nije u redu, odbija se zahtjev za autorizacijom, inae narudba eka u stanju "Autorizirano" dok se ne dogodi "Isporui"
Provjera radi / provjeri stavku
Slanje radi / zaponi slanje Autorizacija radi/provjeri plaanje [plaanje nije u redu] Odbijeno
[Sve stavke provjerene i nekih stavaka nema] Stavka je primljena [neke stavke nisu na skladitu] ekanje
Stavka je primljena [sve stavke dostupne]
[plaanje je u redu] isporui obustavljeno Autorizirano Isporueno
Obustavljeno
Isporueno
397
398
Konkurentna stanja
Neke promjene mogu se dogaati istovremeno
Nadstanje s konkurentnim odjeljcima
Primjena dijagrama stanja

Dijagram stanja ne treba crtati za svaki razred u sustavu.
Najbolje ih je koristiti samo za razrede sa zanimljivim ponaanjem te tamo gdje ti dijagrami pomau bolje razumijevanje ili bolje uoavanje onoga to se dogaa u sustavu.
"Narudba" moe doi u stanje dva mogua istovremena stanja: "Provjera" i "Autorizacija"
Kada narudba napusti konkurentna stanja, ona je opet samo u jednom stanju.
obustavljeno Obustavljeno
Samo jedno izlazno/zavrno stanje

Koje e to biti, ovisi o tome koji se dogaaj dogodi prije
Aktivno
ekanje
Dijagrami stanja dobro opisuju ponaanja jednog objekta u razliitim sluajevima koritenja. Dijagrami stanja nisu prikladni za prikaz ponaanja koje ukljuuje suradnju vie objekata.
Tada je bolje kombinirati tehniku dijagrama stanja s drugim tehnikama.
Provjera
Slanje
Dosta se koriste u sustavima za rad u stvarnom vremenu, te za razrede korisnikih suelja.

Isporueno
Autorizacija
Autorizirano
kraj
Odbijeno
Elementi dijagrama aktivnosti

Prikazuje
ili tok rada (workflow) izmeu objekata nekog sluaja koritenja ili tok upravljanja za neku operaciju
Pocetak
Zaprimi narudzbu
Razdvajanje
Sadri tok aktivnosti, ali ne i objekteAktivnost
Dijagrami aktivnosti
Activity Diagrams
sva (ili veina) stanja su stanja akcija sva (ili veina) prijelaza obavlja se po dovretku akcija u stanju
Ispuni narudzbu Grananje
Posalji racun
Osnovni simbol: stanje aktivnosti Uvjet (aktivnost)

stanje radnje, npr. proces iz stvarnog svijeta ili izvoenje programske rutine
[zurna narudzba]
[else]
Ostali simboli su slini onima dijagrama stanja

s dodatkom oznaka ponavljanja
Zaprimi uplatu Nocna isporuka Obicna isporuka
Uvjetovano ponaanje
grananja (branches) udruivanja (merges)
Spajanje Udruzivanje
Paralelizam, istovremenost procesa

razdvajanje, ravanje (fork) spajanje, pripojenje (join) Svaka grana predstavlja nit izvoenja (thread)
Zatvori narudzbu
Kraj
402
Paralelizam i uvjetne niti

Oznake za razdvajanje i spajanje moraju se poklapati
Za svako razdvajanje mora postojati spajanje koje udruuje niti nastale razdvajanjem.
Primjer skraenog prikaza i uvjetnih niti
Dodatna pravila
Nit koja izlazi iz razdvajanja moe se i sama razdvojiti tako da se novonastale niti spoje prije spajanja koje odgovaraj prvom razdvajanju. Ako nit koja izlazi iz razdvajanja ide direktno u novo razdvajanje, dozvoljeno je izbaciti drugo razdvajanje i niti koje bi izlazile iz njega premjestiti tako da izlaze iz prvog razdvajanja. Analogno, ako spajanje ide direktno u drugo spajanje, moe se izbaciti prvo spajanje, a niti koje bi ile u njega tada idu u drugo spajanje. Ovo je skraeni nain zapisivanja koji se koristi da se dijagram pojednostavni. Postoji posebno stanje, tzv. sinhronizacijsko stanje (sync state) koje omoguava sinhronizaciju na mjestima na kojima bi pravilo o parovima razdvajanja i spajanja inae sprjeavalo.
Razdvajanje izbaceno iz dijagrama Skuhati tjesteninu Napraviti umak
[raspolozen za vino]
Uvjetna nit
Otvoriti vino
Uvjetna nit (conditional thread)

ako uvjet u niti koja izlazi iz oznake razdvajanja nije ispunjen, smatra se da je ta nit zavrila, to jest da se paralelne mogu obaviti do toke spajanja
Zamijesati
403
404
Komponiranje aktivnosti i staze

Kupac
Zaprimi narudzbu
Primjena dijagrama aktivnosti

Skladiste
Prodaja
Analiza sluaja koritenja.

Dijagram aktivnosti dobro pokazuje opi slijed akcija za nekoliko objekata i nekoliko sluajeva koritenja Za prikaz ponaanja objekata za jedan sluaj koritenja bolje je koristiti dijagram interakcija Na ovoj razini nije bitno dodjeljivanje aktivnosti pojedinim objektima. Potrebno je dobiti opu sliku ponaanja sustava, te odrediti meuzavisnosti u ponaanju. Aktivnosti se vezuju sa objektima u kasnijim fazama razvoja.
Zahtjevati robu
Ispuni narudzbu Posalji racun
Preuzeti narudzbu
Isporuka [zurna narudzba] [else]
Razumijevanje radnog procesa.

Da bi se shvatio poslovni proces i omoguile eventualne izmjene i poboljanja, poslovni proces se modelira dijagramom aktivnosti. Pri tome je potrebno ukljuivanje osobe koja je upuena u poslovni proces.
Uplatiti
Zaprimi uplatu
Ispuniti narudzbu
Opisivanje sloenih sekvencijalnih algoritama.

U ovom sluaju dijagram aktivnosti je samo UML oblik klasinog dijagrama toka.
Nocna isporuka
Obicna isporuka
Opisivanje vienitnih aplikacija.

Dostaviti robu
Dijagramima aktivnosti mogue prikazati paralelizam pa ih to ini pogodnim za prikazivanje vienitnih aplikacija.
Primiti robu
Zatvori narudzbu
405
406
Dekompozicija sustava
Problem podjele sustava u (manje) podsustave
Rimsko naelo: podijeli pa s/vladaj (Divide et impera, Divide and conquer) Podjela sustava u "savladljive" dijelove Strukturirane metode: funkcionalna dekompozicija OO analiza i dizajn: grupiranje razreda u cjeline na vioj razini
Dijagram paketa
Package Diagram
Paketi (Packages)
konceptualno strukturiranje modela sustava najee prikazuju strukturu, tj. organizaciju izvornog koda u fazi razvoja
Komponente (Components)
fiziko povezivanje elemenata sustava elementi: fizike komponente (COM+, CORBA), izvorni kod, dokumentacija tijekom pogona
Naziv paketa
GUI.exe
408
Paketi
Paket = opi mehanizam grupiranja elemenata, logiki povezana grupa elemenata modela, dio modela
Koncept grupiranja moe se primijeniti na bilo koji element modela, a ne samo na razrede
Dijagram paketa
Pokazuje pakete i razrede te zavisnosti izmeu njih
To je, zapravo, dijagram razreda koji prikazuje skupove razreda i njihove zavisnosti, ali se nazivom "dijagram paketa" naglaava koji su glavni elementi dijagrama.
Elementi
podsustavi drugi (manji) paketi realizacija sluajeva koritenja suelja (interfaces)
Paket se prikazuje s dva odjeljka

U manjem se navodi ime paketa, a u veem sadraj paketa. U grubljem prikazu, naziv paketa pie se u veem umjesto razreda, a manji odjeljak ostaje prazan.
Svojstva
pojedini element sadran je samo u jednom paketu nazivi unutar paketa moraju biti jedinstveni paketi tvore imenike (namespace) paketi mogu referencirati druge pakete UML podrazumijeva da postoji anonimni paket-korijen (root package)
409
410
Ugnjeivanje paketa
Prostor imena
Grupira razrede sline funkcionalnosti. Imenici - C# i C++ namespace Izvedeni razredi ne moraju biti u istom paketu. Vanjski paketi ponekad se nazivaju domene.
Primjena dijagrama paketa

Slojevite (vieslojne) arhitekture Veliki projekti
koriste se kad dijagram razreda cijelog sustava ne stane na papir formata A4
Kriteriji za grupiranje sluajeva koritenja u pakete

potpora odreene poslovne funkcije podrka odreenom sudioniku srodni razredi i proirenja (generalizacija, veze)
Testiranje
Ponaanje paketa se testira tako da se jedan ili vie razreda paketa koriste kao probni razredi.
Cilj
lokalizacija promjena u sustavu visoka povezanost elemenata (cohesion) mala vanjska zavisnost/skopanost (coupling)
Naziv paketa koristi se za tvorbu punog naziva razreda

npr. puni naziv razreda Kamenko u paketu Kremenko je Kremenko.Kamenko
Narudbe +Narudba
Smanjenje zavisnosti
Paketi ne nude odgovore kako smanjiti zavisnosti u sustavu, ali pomau vidjeti koje zavisnosti postoje.
Primjeri pakiranja
Narudbe
-Stavka
Odravanje kontrole nad strukturom cjelokupnog sustava

Kad se koriste, lake se naprave promjene u dobro definiranom sustavu. Primjerice, pri lokalizaciji programske podrke.
+Narudba -Stavka
Primjer: logika organizacija tankog Web klijenta
Debeli Web
413
414
Dijagrami komponenti
Dijagram komponenti (Component diagram)
prikaz organizacije i zavisnosti softverskih komponenti
Komponenta: fiziki modul programskog koda

izvorna datoteka, pogonska komponenta (run time) ili izvedbeni program (executable)
Fiziki dijagrami
Physical Diagrams
Komponenta slii paketu

reprezentira fiziko pakiranje programskog koda pojedini razred moe se koristiti u razliitim komponentama, ali je definiran u samo jednom paketu
Zavisnost komponenti
iskazuje na koji nain promjena jedne komponente moe utjecati na promjenu drugih komponenti primjeri: zavisnost pri komunikaciji, zavisnost pri prevoenju
416
Dijagrami komponenti
Komponenta je tipino odreena s jednim ili vie klasifikatora koji obitavaju (reside) na komponenti.
Podskup ovih klasifikatora eksplicitno definira suelja komponente. Suelja predstavljaju skup usluga koje pruaju elementi komponente.
SesijaKucneKupo vine SesijaKupovine <<session>> SesijaKupovine
Zavisnost komponenti
Generator rasporeda
rezervacije
Tip komponente ima naziv oblika: KucnaNarudzba tip_komponente. Instanca komonente ima i ime i tip oblika ime_komponente : tip_komponente.
Ako se naziv tipa izostavi izostavlja se i dvotoka.
Narudzba
<<entity>> 050677am:Narudzba <<auxiliary>> :NarudzbaPK KucnaNarudzba Narudzba <<focus>> :Narudzba <<auxiliary>> :NarudzbaInfo
Komponenta Ovisnost Planer azuriraj
Sucelje
GUI
417
418
Varijante prikaza
SesijaKucneKupo vine SesijaKupovine KucniKatalog KucniKatalog Katalog <<session>> SesijaKupovine <<entity>> Katalog <<auxiliary>> KatalogPK
Dijagram ugradnje
Dijagram ugradnje (Deployment Diagram)
Prikazuju konfiguraciju pogonskih elemenata i softverskih komponenti, procesa, i objekata koji ive u njima.
<<focus>> Katalog
vorovi (Nodes): izvrni resursi

<<auxiliary>> KatalogInfo
najee sklopovlje
Client
Katalog
<<file>> KatalogJAR
Spojevi (Connections):
komunikacijski putevi
KucnaKosarica
Nazivlje: ime_vora : tip_vora (opcionalno)

Kosarica
<<entity>> Kosarica
<<auxiliary>> KatalogInfo
<<focus>> Katalog
<<auxiliary>> KatalogPK
TCP/IP <<reside>>
elementi sadrani u komponenti (npr. implementacijski razredi)
<<reside>> <<reside>>
vor1
<<reside>>
vor2 +veza * * komp2 komp1
<<implement>>
fiziki element ugradnje
<<entity>> Katalog
Server
<<implement>>
<<file>> KatalogJAR
419
420
vorovi i komponente
Kombiniranje dijagrama komponenti i dijagrama ugradnje
prikaz fizike zavisnosti izmeu softvera i hardvera lokacije komponenti unutar (distribuiranog) sustava instance softverskih komponenti koje predstavljaju pogonsku manifestaciju jedinica programskog koda.
Server:Host
Primjer odnosa vorova i komponenti

: kontrola_zaliha.dll
: narudzbe.dll
: izbor.dll
Komponente smjetene na voru, a koje nisu prikazane ugnijedenim simbolima, oznaavaju se zavisnou sa stereotipom <<deploy>> Zavisnost <<become>> prikazuje da se priuvni broker u nekom trenutku izvoenja seli iz vora priuvnog posluitelja na vor primarnog posluitelja dok ostale komponente ostaju tamo gdje jesu.
primarniPosluitelj:AplPosluzitelj
<<database>>
:RacuniDB :OdrediKvotu
Korisnik:PC
primarniBroker:Broker
: GUI.exe
<<become>>
pricuvniPosluzitelj:AplPosluzitelj
Account Server Account Server Deploys AccountDB.java AccountMgt.java
pricuvniBroker:Broker
<<database>>
:OdrediKvotu
:RacuniDB
AccountDB.java
AccountMgt.java
Izrada sustava
Implementacija sustava, ugradnja sustava
izrada novog sustava i isporuka tog sustava u produkciju, to jest svakodnevnu primjenu
Izrada sustava
Izrada sustava
faza u kojoj se obavlja izgradnja i testiranje mrea (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
424
Kodiranje, programiranje
Kodiranje
pretvorba detaljnog programskog opisa u stvarni program, najee primjenom nekog formalnog programskog jezika runo kodiranje neizbjeno zbog veliine stvarnih problema i sloenosti procesa sporo 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)
Kodiranje, programiranje
Strukturirano programiranje, Strukturno programiranje
tehnika programiranja koja podrazumijeva pristup odozgo prema dolje (top-down programming) i uporabu 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 poetku, s uvjetom na kraju, s unaprijed poznatim brojem koraka)
izbjegavanje bezuvjetnih skokova (GOTO naredbe)
poeljno je da konkretni jezik uz prevodilac (compiler) ukljuuje interpretator (interpreter) te alat za otkrivanje pogreaka (debugger) automatsko kodiranje generiranje programskog koda, suelja, sheme baze podataka
Proceduralno programiranje
nain programiranja koji omoguuje da se program definira kao skup programskih cjelina, poeljno takvih da se mogu opetovano koristiti programska cjelina (unit) skup programskih naredbi koje obavljaju jedan zadatak ili jedan dio zadatka, npr. glavni program, potprogrami (procedure, funkcije) programski modul skup logiki povezanih programskih cjelina modularno programiranje komponenta bilo koji sastavni dio softvera, uobiajeno podrazumijeva fizike cjeline
Istovremeno koritenje razliitih programskih jezika, a naroito jezika razliitih generacija treba koristiti samo po potrebi, primjerice kada se eli ukloniti neke nedostatke osnovnog jezika kojim se obavlja razvoj.
primjer: 4gl + C
Pristup programiranju
Monolitni pristup (build and fix)
dugotrajno kodiranje, a zatim niz ponavljanja oblika provjera+ispravak odgaa otkrivanje problema (pogreaka u kodu i dizajnu) prosljeuje probleme u primjenu i odravanje
Inkrementalni pristup, primjer:
izrauje se program ija je struktura prikazana slikom prvo se kodiraju sve funkcije, a zatim se udruuju pokretanje programa zavrava fatalnom pogrekom problem: kako ustanoviti u kojoj funkciji se nalazi pogreka rjeenje: postupnim kodiranjem i udruivanjem funkcija prilikom izrade funkcije koja poziva neke druge funkcije, pozvane funkcije kodiraju se kao odresci ili okrajci (stub), tako da je tijelo funkcije prazno ili sadri poruku (tu sam X) prilikom izrade funkcije koja e biti pozvana iz neke druge, jo neugraene funkcije, izrauje se pogonska funkcija (driver)
a b c d
f j l
Inkrementalni pristup (stupnjevito, postupno programiranje)

niz ponavljanja oblika kodiranje+provjera+ispravak omoguuje raniju provjeru i izdvajanje pogreaka (fault isolation) omoguuje raniju raspoloivost djelominih (nedovrenih) verzija omoguuje ravnomjerniju podjelu posla odozgo prema dolje, odozdo prema gore te mjeovito
h
Funkcija A ()
Poziv B()
k m
Funkcija B()
Ispis "Tu sam B"
Funkcija M (a, b, c, ) Program DriverM

Poziv M (1, "test", 3.14, )
428
427
Programiranje od vrha prema dolje (Top-Down)
ako funkcija fGornja poziva funkciju fDonja, onda se fGornja kodira i integrira prije fDonja mogui redoslijed kodiranja: abcdefghijklm, pisanjem odrezaka (pr. bcd za a) alternativni redoslijed: a+beh+cdfi+gjklm nakon to je funkcija a napravljena i provjerena, jedan programer izrauje beh, a drugi istovremeno radi cdfi nakon to su zavreni d i odrezak f, trei programer zapoinje gjklm
Programiranje od dna prema gore (Bottom-Up)
ako se funkcija fDonja poziva iz funkcije fGornja, onda se fDonja izrauje prije fGornja redoslijed kodiranja: lmhijkefgbcda 1. programer radi heb 2. programer radi ifc 3. programer radi lmjkgd nakon to su zavrene b, c i d, pristupa se konanom udruivanju prednost: bolja provjera operativnih funkcija, manji utroak pogonskog koda nedostatak: kasno otkrivanje logikih pogreaka
prednost: bolja provjera logikih funkcija (na vioj razini hijerarhije, u kojima se donose odluke) bre otkrivanje logikih pogreaka, manji utroak odrezaka nedostatak: nedovoljna provjera operativnih funkcija (na niim razinama, obavljaju stvarni posao)
a b c d
a b c d
f j l
f j l
h
h i k m
k m
430
429
Mjeoviti (sandwich) pristup
prvo se od vrha prema dolje izrauju logike funkcije, pr. abcdgj zatim se od dna prema gore rade operativne funkcije, pr. efhiklm prednost: rano otkrivanje logikih pogreaka uz bolju provjeru operativnih funkcija
Programski standardi i preporuke

Poveanje itljivosti
standardizacijom nazivlja Standardizacija nazivlja programskim komentarima Programski komentari tehnikom i stilom programiranja Tehnika i stil programiranja razliitim oznaavanjem pojedinih elemenata jezika, kao to su rezervirane rijei, identifikatori, komentari, opcije prevoditelja (razliita boja, "veliina" znakova) koritenjem predefiniranih simbolikih oznaka i konstanti izbjegavanjem programskih redaka koji duljinom prelaze irinu zaslona pisanjem po jedne programske naredbe u retku podjelom sljedova naredbi na odsjeke koji su u cjelini vidljivi na zaslonu formatiranjem izvornog koda - pomicanjem u desnu stranu naredbi unutar programskih struktura, tzv. "uvlaenje" (indentation)
a c
f j l
k m
Smjernice za nazivlje
Nazivlje struktura podataka
pridjeljivati nazive iz kojih se vidi na to se odnose Primjerice: Osoba.SifraOsobe, Mjesto.SifraMjesta Umjesto: Osoba.Sifra, Mjesto.Sifra, Artikl.Sifra izbjegavati uporabu posebnih znakova koje sintaksa jezika/sustava ne dozvoljava pri tvorbi identifikatora pr. operatori i znakovi za palatale naeg jezika, Dat-Ro izbjegavati prekratke nazive koji, osim u neitkost, vode u nedosljednost ve pri prvoj pojavi iste kratice za razliiti pojam npr. SifMje za Mjeru i Mjesto izbjegavati preduge nazive, pr. Redni_broj_stavke_kalkulacije, zbog smanjenja itljivosti uinkovitosti runog kodiranja (pojava sintaksnih pogreaka izazvanih pogrekama u pisanju produuje vrijeme ispravljanja i prevoenja) moguih ogranienja jezika (pr. duljina identifikatora do 18 znakova) izbjegavati nazive dobivene rutinskim spajanjem naziva entiteta i atributa jer mogu djelovati nezgrapno unutar upita, na primjer: umjesto SELECT Posao.* FROM Posao WHERE Posao.posao_datum bolje je SELECT Posao.* FROM Posao WHERE Posao.DatPosla koristiti nazive koji se daju izgovoriti pr. Nstvnk.SifNstvnk Nastav.SifNastav ili Nastavnik.SifNastavnika
Nazivlje programskih varijabli
koristiti smislene nazive izbjegavati "jednoslovane" varijable, pr. i, j, k ili i, ii, iii, ili, x1, x2, x3 osim za indekse i dimenzije polja, pr. i, n nazive odabirati u skladu sa znaenjem sadraja pr. max za najveu vrijednost pr. len za varijablu koja odreuje duljinu koristiti standardne prefikse/sufikse za srodne elemente/objekte pr. frmOsoba ili fOsoba za zaslonsku masku pr. repOsoba, rOsoba za izvjee koristiti kratice opih pojmova kao to su pr. broj, redni broj, ifra, kratica, oznaka, datum br, rbr, sif, krat, ozn, dat razlikovati nazive globalnih i lokalnih varijabli te formalnih argumenata koji se odnose na isti pojam, ime se olakava snalaenje u programskom kodu i uklanja mogua "neodreenost" sadraja pr. gCount, sCount, lCount, aCount
434
Standardizacija nazivlja
Pridjeljivanje naziva objektima modela podataka odraava se na nazive programskih varijabli. O tome treba voditi brigu ve prilikom oblikovanja baze podataka. Poeljno je oblikovanje obaviti takvim alatom za modeliranje koji osim stvarnih naziva ima mogunost evidentiranja kodova koji e se koristiti prilikom stvaranja BP za stvaranje objekata BP. Uporaba razliitih notacija kao to su koritenje velikih i malih slova (BrojCipela), umetanje podvlake izmeu dijelova od kojih je sastavljen pojam (broj_cipela) ili kombiniranje spomenutih notacija moe se smatrati razlikom u stilu.
Smjernice za komentare
Programski komentari
paziti da komentari budu aurni, tj. da odgovaraju stvarnom stanju ne pretjerivati u pisanju komentara lo kd bolje je iznova napisati, nego (bezuspjeno) pojanjavati komentirati smisao naredbi (izbjegavati "prepriavanje")
Primjeri
PascalCase - poetno slovo svake rijei u imenu je veliko slovo npr. BackColor koristi se kod imenovanja prostora imena, razreda, suelja, pobrojanih tipova, postupaka i svojstava, static, public ili protected atributa identifikator razreda moe zapoeti znakom @ camelCase poetno slovo prve rijei u imenu je malo slovo, poetna slova ostalih rijei u imenu su velika slova npr. backColor koristi se kod zatienih atributa i lokalnih varijabli postupaka Preporuke Imena suelja uobiajeno zapoinju slovom I Koristiti imenice za imena razreda Koristiti glagole za imena postupaka
Primjer, komentar u zaglavlju potprograma

'************************************************************* 'Function : FormatField 'Purpose : Formats a field 'Arguments: ' Col Index of field ' Value Value to format 'Returns : True if successful 'Created : K.Fertalj, V.Mornar, 24.04.96 'Modified : K.Fertalj, V.Mornar, 24.04.96 '************************************************************* Function FormatField(Col As Integer, Value As String) As Integer
Primjer, komentar u zaglavlju modula
'************************************************************* 'Module: dh69libClient - C:\VbProjs\dh69cd\dh69libClient.bas 'Purpose: Client Library - Transfer related 'Modified: 05.03.2001 by K '************************************************************* 'Public Method TestTransfer 'Public Method SetConnectVars 'Public Method ErrExportImport '... 'Public Const EXCHANGEINPROGRESS 'Public Const CHECKSYSTEMDATE 'Public Const TRYTOEXCHANGELATER '... 'Public Variable ImmediateTransfer '... 'Public Const FTP_APPDIR 'Public Const FTP_DIR '... '*************************************************************
Primjer, komentar programskog slijeda i retkovni komentar
hFile = FtpFindFirstFileA(hservice, RemoteFileName, FindData, 0, 0) If hFile = 0 Then '15.06.2000 by K 'enum FTP files to compare Case-Insensitive Dim bFile As Long, FoundFile As String FindData.cFileName = String(MAX_PATH, 0) hFile = FtpFindFirstFileA(hservice, "*.*", FindData, 0, 0) If hFile = 0 Then Exit Function 'empty directory, 05.03.2001 by K
Primjer, blok komentar

'#'Block Out 22.09.2000 by K '#'Ellerman - "already changed by" request '@ 'reset Status and Flags for imported ads '@ SQL = "UPDATE AD SET NewStatus=Status, NewCDFlag=CDFlag, " & _ '@ " NewNPFlag=NPFlag, UpdatedOnServer=True" '@ If MinImportedAdSN > 0 Then '@ SQL = SQL & " WHERE Ad.SN > " & MinImportedAdSN '@ End If '@ daoExecute SQL, IIf(QuietMode, "", "Updating local flags...") '#'End Block Out 22.09.2000 by K

Na poetku izrade treba uspostaviti standarde kodiranja, a odabrani stil zatim dosljedno primjenjivati!
Primjeri: \Izrada\CodeConventions Primjer: MSDN "Hungarian notation"

Tehnika i stil programiranja
eksplicitno deklarirati programske varijable izbjegavati programske varijable opeg tipa postaviti poetne vrijednosti varijabli prije uporabe ugraditi podrazumijevane (default) vrijednosti ulaznih podataka provjeravati zahtijevanost i valjanost ulaznih podataka dosljedno formatirati podatke olakati ispravljanje neispravnih ulaznih podataka pripaziti na granine vrijednosti podataka, indeksiranih varijabli ... provjeriti mogue numerike pogreke (10.0 * 0.1 nije uvijek 1.0) izbjegavati usporedbu na jednakost brojeva s pominim zarezom
439
440

Tehnika i stil programiranja
koristiti zagrade radi naglaavanja redoslijeda izraunavanja izraza presloiti i pojednostavniti nerazumljive izraze izbjegavati nepotrebna grananja izbjegavati trikove (ne rtvovati jasnou radi "efikasnosti") ponavljajue blokove i izraze zamijeniti potprogramima rekurziju koristiti samo za rekurzivne strukture podataka prvo napraviti jasno i ispravno rjeenje, a zatim brzo rjeenje neuinkoviti kd ne usavravati, nego nai bolji algoritam rutinski posao i jednostavnu optimizaciju prepustiti prevoditelju nakon pronaene i ispravljene pogreke provjeriti ima li ih jo lo kd bolje je napisati ponovno, nego ga popravljati ("krpati") nedovoljno openita rjeenja bolje je reorganizirati, nego ih prilagoavati radi viekratnog koritenja kodirati s osloncem na programske knjinice

Programske knjinice
Prije poetka kodiranja treba pripremiti programske knjinice s funkcijama grupiranim po namjeni funkcije za rad s opim tipovima podataka (npr. nizovi znakova i datumi) funkcije za rad s podacima u bazi podataka (npr. funkcije za upravljanje transakcijama i provjeru statusa izvedenih upita) funkcije suelja (npr. sustav izbornika, poruka i pomoi) funkcije za odravanje baze podataka (npr. provjera konzistentnosti podataka i izrada rezervnih kopija) funkcije za administriranje vanjskih ureaja (npr. terminali i pisai) programski dio sustava zatite (npr. definiranje programskih modula, funkcija i korisnika te rukovanje pravima pristupa programima i podacima) Grupiranje funkcija suelja te poruka i tekstova pomoi pomae kod promjene kodne stranice ili u sluaju potrebe za prijevodom na neki drugi jezik, kada sve tekstove treba odjednom mijenjati.
441
Provjera ispravnosti
Testiranje programa, provjeravanje, ispitivanje programa
provjera programa izvoenjem, uz uporabu ispitnih podataka te analizom rezultata obrade testiranje i ispravljanje pogreaka mora se obavljati redoslijedom kojim su moduli kodirani, uobiajeno s vrha prema dolje cilj testiranja na pogreke je utvrivanje pogreaka odnosno nedostataka unutar programa uspjean test je onaj test koji dokae postojanje pogreke
Provjera ispravnosti
Naini provjere
strukturalno (white-box, clear box testing) provjera kako cjelina radi probni sluajevi izvode se uvidom u programski kd (inspekcija koda) provode programeri funkcionalno (black-box testing) provjera to cjelina radi, to jest da li zadovoljava zahtjeve probni sluajevi izvode se iz specifikacija funkcija provodi osoblje proizvoaa ili korisnici
Verifikacija - ovjera ispravnosti

dokazivanje da je faza dobro provedena ili da je proizvod dobro napravljen, tj. da odgovara specifikaciji zahtjeva
Validacija - potvrda valjanosti

kojom se utvruje da je napravljen pravi proizvod, koji odgovara korisniku-namjeni
Vrste testiranja
Testiranje okrajaka (stub testing, unit testing)
testiranje upravljakih struktura i vrijednosti sadranih u kodu ispitivanje pojedinanih cjelina ( Proceduralno programiranje) nedovreni elementi mogu se simulirati ( odresci i pogonski moduli)
Vrste testiranja
Integracijska provjera (integration testing)
Ispitivanje grupa komponenti koje integrirane ine cijeli sustav ili neki njegov dio provjere test korisnikog suelja provjera svake funkcije suelja test sluajeva koritenja provjera svakog pojedinanog sluaja test toka podataka provjera procesa korak-po-korak test suelja sustava provjera prijenosa podataka izmeu sustava ispitivanje provodi nezavisni tim za testiranje testovi su zasnovani na specifikaciji sustava
Testiranje komponenti (module testing)

Ispitivanje pojedinih programskih komponenti provodi razvojnik komponente (postoje iznimke za kritine sustave) testovi nastaju iz iskustva te osobe
Provjera 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 zahtjevima Testiranje performanci provjera nefunkcionalnih zahtjeva
stress verifikacija velikog broja simultanih pristupa volume test na koliinu podataka, sloenost algoritama, fragmentaciju security provjera prava pristupa timing brzina odziva recovery mogunost oporavka pri forsiranom padu sustava
446
Testiranje dokumentacije provjera korisnike dokumentacije i primjera

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07. 445 FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.
Vrste testiranja
Test prihvatljivosti (acceptance testing)
test sustava kojim se dokazuje da proizvod zadovoljava korisnike zahtjeve i potrebe organizacije te uvjete pod kojima ga je naruitelj spreman preuzeti iscrpan i konaan test nad stvarnim podacima Alfa-testiranje (alpha testing) - verifikacijsko probna uporaba koju provode korisnici kod izvoaa simulacija stvarnog okruenja traenje pogreaka i propusta Beta-testiranje (beta testing) validacijsko provode korisnici kod sebe, bez nazonosti izvoaa provjera u stvarnim uvjetima
performance sustava vrna optereenja provjera upotrebljivosti i lakoe uporabe metode i procedure izrada rezervnih kopija i oporavak sustava
Plan testiranja
Plan testiranja
testiranje mora biti sustavno, prema unaprijed napravljenom planu koji sadri identifikator programa ili dijela obrade (npr. naziv opcije izbornika ili zaslona) naziv funkcije (npr. unos ili izmjena) vrstu poduzete akcije (npr. potvrda pohrane ili prekid obrade) identifikator ili opis podatka koji se eli obraditi ponaanje programa (npr. neregularni zavretak rada, neispravni podaci, pogrean prikaz podataka), po potrebi oekivani rezultat Primjeri: \Izrada\ObrazacZaTest
Preporuke za provjeru u kojoj sudjeluju poznati korisnici

Provjeru obavlja ogledna skupina krajnjih korisnika koja, koristei napravljena rjeenja, nastoji obaviti svoje svakodnevne poslove. Po elji krajnji korisnik dodatno iznosi svoja zapaanja ili prijedloge. Primjedbe se prikupljaju dnevno a pogreke uklanjaju po mogunosti istog dana. Prikupljeni dodatni zahtjevi se procjenjuju te se izrauje lista prioriteta ugradnje. Nerealni i preveliki zahtjevi se odbacuju ili se planira njihova naknadna ugradnja.
Nadzorni test (Audit test) provodi se opcionalno potvrda da je sustav gotov, ispravan i spreman za primjenu provode nezavisne tvrtke ili odjeli za osiguranje kvalitete
448
Primjer obrasca za test
Raspodjela broja otkrivenih pogreaka
449
Dokumentiranje
Projektna dokumentacija
dokumentira razvoj i proizvode pojedinih faza
Primjer, dokumentacija po IEEE standardu
Izrada dokumentacije
Software 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 code Software Test Documentation (STD) User's manual
452
Dokumentiranje
Korisnika dokumentacija
pomo korisnicima pri uporabi sustava mora biti prilagoena korisnicima razliitog iskustva upute za uporabu (user manual) instalacijski prirunik (installations manual) detaljni prirunik (reference manual) upute za vjebu (training guide, tutorial) podsjetnici ili kratke upute (quick reference guide, pocket guide, cue cards)
Dokumentiranje
Tehnika dokumentacija
namijenjena tehnikom osoblju potrebna za razumijevanje, izradu i odravanje sustava upravljanje projektom i konfiguracijom sustava plan razvoja specifikacija dizajna opis arhitekture sustava specifikacija suelja prema drugim sustavima programska dokumentacija izvorni kd opis baze podataka probni podaci i rezultati provjere dnevnik promjena programski prirunici instalacijski prirunik opis instalacijske procedure upute za rukovanje i odravanje (operations manual) opis procedura za pokretanje/zaustavljanje (startup/shutdown) opis izrade rezervnih kopija i vraanja podataka (backup, restore) opis postupka ponovnog pokretanja i oporavka (restart, recovery)
broj, vrsta i obujam dokumenata ovise o aplikaciji
Preporuke za izradu dokumentacije

Izrada dokumentacije
izrada kvalitetne dokumentacije zahtijeva angaman i do nekoliko sati (3) po stranici mora biti planirana i zapoeti dovoljno rano, prije zavretka kodiranja i testiranja prije objavljivanja treba provjeriti/dokazati da odgovara namjeni prilikom izrade treba pripaziti na izbjegavati ponavljanje i neodreenost Koristiti standardizirane dokumente
Preporuke za izradu dokumentacije

Nepostojanje dokumentacije moe biti razlogom za prestanak koritenja aplikacija, naroito kada autor ili autori prestanu biti raspoloivima. Preporua se odvojeno pohranjivati odgovarajuu inaicu programske opreme (alata) kojom je proizvod napravljen. Primjeri: \Dokumentacija
Izmeu ostalog, dobra dokumentacija mora:

biti napisana s gledita itatelja, a ne pisca konzistentnost pojmova, jednostavnost izraza, kratka poglavlja biti dobro ilustririrana (slikama zaslona i njihovog redoslijeda) opisivati postupak rada, a ne samo sadraj zaslona npr. redoslijed popunjavanja ifrarnika, odreivanje lozinki i prava pristupa, radne procedure biljeiti naela (argumente odluka) odraavati stvarno stanje opreme u primjeni, tj. biti aurna ukljuivati rjenik koritenih izraza
Internet adrese
http://www.rspa.com/docs/index.html http://www.construx.com/doc.htm
456
Uvoenje u primjenu
Uvoenje ukljuuje instaliranje opreme, zavrni prijenos podataka te prelazak na novi nain rada. Aktivnosti i preduvjeti
Test sustava
vidi Izrada\Testiranje
Primjena i odravanje
Izrada plana konverzije (migracije) za uspjean prijelaz

nain uvoenja, 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 postojeih podataka uz konverziju uspostava sustava zatite i odravanja
Poduka tehnikog osoblja i krajnjih korisnika

verbalna poduka raspodjela dokumentacije
Konverzija sustava
prelazak na novi nain rada evaluacija projekta i sustava
458
Uvoenje u primjenu
Nain uvoenja
Izravno uvoenje (direct installation, abrupt cutover) poetak rada novog sustava uz istovremeni prestanak rada starog sustava provodi se na odreeni dan, uobiajeno datum zavretka poslovnog razdoblja, po mogunosti na kraju tjedna mogui problemi: pojava pogreaka koje nisu bile uoene tijekom testiranja, nepredvieno preoptereenje opreme u punom pogonu nedostatak: neposredna izloenost korisnika pogrekama sustava Paralelno uvoenje (parallel installation, parallel conversion) istovremeni rad starog i novog sustava tako dugo dok se ne pokae da novi sustav ispravno radi i da su se korisnici navikli na novi nain rada bitno manje rizian postupak u odnosu na izravno uvoenje nedostatak: potreba za dvostrukom obradom istih podataka, u starom i u novom novom sustavu otpor korisnika
Uvoenje u primjenu
Korisnici mogu biti raspreni na razliitim lokacijama
Probno uvoenje (pilot installation, location conversion) izravno/paralelno uvoenje sustava na jednoj lokaciji, a zatim i na ostalim lokacijama, nakon to se utvrdi da sustav ispravno radi Postupno uvoenje (phased) uvoenje grupa lokacija Istovremeno (simultaneous conversion) istovremeno uvoenje na svim lokacijama
Modularno uvoenje (modular installation, staged conversion)

postupna zamjena starog sustava novim, uvoenjem po dijelovima izvedivo samo ako je mogu istovremeni rad oba (nekompletna) sustava mogui problemi: potreba za spojnim programima, tj premoivanjem
459
460
Uvoenje u primjenu
Poduka korisnika
tehniko osoblje kranji korisnici
Poduka
Sadraj poduke
Poduka krajnjih korisnika moe ukljuivati: opu informatiku kulturu (npr. uporaba osobnih raunala) funkcije sustava i nain uporabe sustava, to jest koritenje aplikacija poduku iz posebnih znanja potrebnih za obavljanje osnovne djelatnosti (npr. operacijska istraivanja, projektiranje primjenom raunala)
Karakteristike razliitih naina uvoenja u primjenu
Uvoenje Izravno Paralelno Ostalo
Rizik visok nizak srednji
Troak niski (ako uspije) visoki srednji
Trajanje kratko (ako uspije) dugo varijabilno

461
Poduka tehnikog osoblja moe ukljuivati: operacijski sustav i uslune programe administriranje baze podataka programske jezike i pomagala
462
Poduka
Redoslijed poduke
prvo se obavlja poduka tehnikog osoblja koje e odravati sustav i pruati potporu krajnjim korisnicima, da bi se mogla pokrenuti primjena zatim bi trebalo obrazovati (nie) rukovodstvo, da bi se stekla njegova potpora pri poduci ostalih korisnika te tijekom primjene slijedi kolovanje (krajnjih) korisnika, koje treba prilagoditi funkcijama koje oni obavljaju u svakodnevnom radu
Odravanje
Postupci i tehnike poduke

teajevi probni rad fazi provjere rada sustava kvalitetni sustav interaktivne pomoi prikladna dokumentacija potpora tijekom primjene
Poduku mogu obaviti djelatnici naruitelja (npr. odjel informatike ili grupa za to odabranih i osposobljenih djelatnika) ili vanjski izvoai poduke.
Odravanje i nadgradnja
Odravanje je trajna aktivnost koja zapoinje odmah po uvoenju u primjenu. Bez obzira kako dobro je sustav dizajniran, konstruiran i testiran pogreke e se neizbjeno pojaviti!
Ispravljanje pogreaka u primjeni naziva se odravanjem sustava ili odravanjem programa. Odravanje samo po sebi ne podrazumijeva ugradnju poboljanja ili novih mogunosti, ali se ona uobiajeno provodi.
Odravanje sustava, servisiranje sustava

preventivno
podrazumijeva zatitu od moguih problema redovita izrada sigurnosnih kopija (backup) obavlja se periodiki (dnevno, tjedno, mjeseno)
korektivno
podrazumijeva popravak nakon to se problem pojavio vraanje podataka iz sigurnosne kopije (restore) uklanjanje uzroka pogreke (ispravljanje programa)
adaptivno
prilagodba funkcionalnosti (naina posluivanja) prilagodba strukture (promjene strukture podataka) poboljanje performanci (optimizacija programa)
Tijekom primjene i odravanja obavlja se analiza dodatnih zahtjeva, planiranje i priprema aktivnosti koje slijede te tako zapoinje novi ciklus razvoja. Primjeri: \Primjena
perfektivno
nadgradnja sustava da bi se rijeili novi problemi ugradnja novih mogunosti (features)
465
466
Uklanjanje pogreaka i izmjene programa

Definicija i validacija problema
uoavanje uzroka pogreaka u primjeni (bugova) problem reprodukcije pogreke problem razliitog tumaenja pogreke nerazumijevanje ili pogreno koritenje programa nepostojanje funkcije ija ugradnja nije bila planirana nije bug!
Poboljanje sustava i reinenjerstvo

Poboljanje sustava (system enhancement)
dorada i nadgradnja sustava prema novim zahtjevima analiza novih zahtjeva i povratak u odgovarajuu fazu (analiza, dizajn, izrada) veina novih zahtjeva uzrokovana je promjenama u poslovanju, potrebama za dodatnim informacijama ili novim idejama (eljama korisnika)
Ocjenjivanje sposobnosti (benchmarking)

Odravanje moe imati neeljene popratne uinke koji utjeu na funkcionalnost i performance aplikacija. Prije izmjene programa, programi bi trebali biti izmjereni da se utvrdi osnovica (baseline) prema kojoj e se ocijeniti izmijenjeni programi.
Reinenjerstvo (reengineering)
neke aplikacije teko je odravati (npr. uslijed zastarjelosti tehnologije), a troak odravanja pojedinih aplikacija moe dosei troak izrade novih reinenjerstvo - adaptacija s ciljem smanjenja trokova odravanja prilagodba veim promjenama tehnologije ispravak sustava prije nego to doe do mogueg prekida u radu ispravak sustava koji e biti lake popraviti ako doe do prekida
Editiranje i testiranje
poznavanje programa upravljanje verzijama (version control) razliite inaice u primjeni kod razliitih korisnika mogunost povratka na prethodnu inaicu ako je ta bila bolja regresijsko testiranje ponavljanje svih testova da bi se provjerilo da izmjene nisu uzrokovale nove defekte
Auriranje dokumentacije
Poboljanje sustava i reinenjerstvo

Pisanje jednostavnih novih programa
jednostavni program koji samo koristi postojee podatke primjeri: pretraivanje i pregledavanje podataka, generiranje izvjea najee i najsigurnije promjene
Upravljanje konfiguracijom
Element konfiguracije (IEEE)
agregacija hardvera i/ili softvera koja se tretira kao jedinka u procesu upravljanja konfiguracijom
Konfiguracija
imenovani skup konfiguracijskih elemenata u odreenoj toki ivotnog ciklusa
Configuration CFG1
1.2
Restukturiranje datoteka i baza podataka

promjena strukture u istoj bazi podataka prelazak na novu tehnologiju upravljanja podacima veliki rizik
Reinenjerstvo programa
reorganizacija koda restrukturiranje organizacije modula ili programske logike konverzija koda prelazak na novi programski jezik rezanje koda, odsijecanje koda (slicing) izdvajanje dijelova programa radi izrade odvojenog programa ili potprograma
user documentation
1.2
1.1
1.0
1.1 1.0 requirements specification
README.TXT
1.1
1.0
LICENCE.TXT
Poboljanja i reinenjerstvo moraju biti planski provedeni

metrika programske podrke (software metrics) mjerenje programa proraun trokova
1.2
1.1 1.0
1.2
1.1
1.0
MainFrame.java source code
1.3
1.2 1.1 1.0
class diagram
Utilities.java
Verzije konfiguracije
verzija, inaica (version) odreeno izdanje (issue, release) proizvoda objava, isporuka (release) originalna verzija u primjeni, npr. zadnja v2.0 revizija (revision) ona koja se koristi umjesto originalne, podrazumijeva izmjene u odreenim vremenskim intervalima, npr. V1.2 varijanta (variant) alternativa originalu (hardverska platforma, razliiti jezik), ivi paralelno s njim, npr. v1.1.2.1
Upravljanje verzijama (version control)
V 1.0
V 1.1
V 1.2
V 2.0
V 1.1.2.1
V 1.1.2.2
V 1.1.4.1
V 1.1.4.2
471
472
Upravljanje verzijama (version control)
Modaliteti izgradnje
Najee meufaza izmeu Analize i Oblikovanja
473
Vlastiti razvoj
Vlastiti razvoj (Insourcing)
Varijante Razvoj vlastitim informatikim snagama (in-house), koji moe sadravati osposobljavanje i angairanje netehnikog osoblja Razvoj unajmljenim osobljem povremeno ili dugorono (buy-in, preferred supplier), npr. PBZ Prednosti fleksibilnost i kreativnost poveanje strunosti vlastitog osoblja Nedostaci zahtijeva znaajno vrijeme i napor skuplje, dugotrajnije moe poveati gomilanje zaostalog posla
Vanjski razvoj
Vanjski razvoj (Outsourcing)
najam usluge razvoja informacijskog sustava ili njegovih dijelova izobrazba djelatnika informatike struke pomo pri analizi i oblikovanju ili provedba analize i oblikovanja kodiranje (generiranje) cjelovitog programskog sustava upravljanje provedbom i/ili nadzor provedbe konzultativna pomo prilikom ugradnje sloenih poslovnih funkcija Varijante: Ugovoreni razvoj - ugovara se isporuka gotovog proizvoda (contract out) Dugorona suradnja s isporuiteljem ili izdvajanje vlastitog informatikog odjela u preferiranog izvoaa (preferred contractor) stratekog partnera (pr. Agencija) Prednosti IS ili njegovi dijelovi izrauju se po mjeri naruitelja
sustav je prilagoen organizaciji/poslovanju po mogunosti treba istovremeno poboljati organizaciju/poslovanje
razvoj vlastitim snagama ima smisla

kada se radi o programskoj podrci koja je posebnost organizacije, takva da ne postoje gotova rjeenja na tritu ili takva da organizacija s pomou nje postie komparativnu prednost u odnosu na konkurenciju kada postoje dodatni ili posebni razlozi kao to su poveana tajnost podataka i poslovnih procesa ili poveana zatita IS
razvoj podrazumijeva dugotrajan postupak i sukladno visoku cijenu Nedostaci i rizici gubitak povjerljivih informacija gubitak nadzora nad sadanjim i/ili buduim razvojem (zavisnost o dobavljau) gubitak vlastite strunosti
Nuno je da upravljanje projektom informatizacije na sebe preuzme vlastito kompetentno osoblje koje ima mogunost odluivanja.
Nabava gotovih aplikacija

Nabava gotovih programskih proizvoda
COTS = Commercial-Of-The-Shelf software u pravilu ne ispunjavanju poslovne potrebe u potpunosti poeljno je da se mogu prilagoditi potrebama
Nabava poslovnih sustava

Nabavka i prilagodba postojeih domaih poslovnih sustava/aplikacija
prednosti: usklaenost naim uvjetima, npr. zakonima zahtijeva prvenstveno prilagodbu organizaciji/poslovanju nedostatci nepostojanje ili manjkavost pojedinih komponenti, mjestimina tehnoloka zastarjelost prekapacitiranost dobavljaa modaliteti: otkup izvornog koda i samostalna dorada kompletni outsourcing uz samostalno odravanje
Aplikacijski paketi
programski paketi za uredsko poslovanje (office automation), npr. Microsoft Office programi za upravljanje dokumentima (document management), npr. Lotus Domino specijalistike aplikacije za odreene namjene
Nabavka gotovih stranih poslovnih sustava

prednosti raskona funkcionalnost kompatibilnost sa svjetskim poslovnim standardima nedostatci neprilagoenost domaim uvjetima i konkretnoj organizaciji/poslovanju - zahtijeva istovremenu prilagodbu programske opreme i promjenu organizacije/poslovanja prilagodba se obavlja slino razvoju - rjeenja gube moguu komparativnu prednost (brzinu i lakou primjene) (glomazni) paketi mogu zahtijevati angaman velikog broja konzultanata - vrlo visoka cijena izrade modaliteti prilagodba vlastitim snagama uz savjetnitvo i pomo dobavljaa
Sustavi za upravljanje poslovanjem

Enterprise 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 plae (HR management, payroll).
Kriteriji za donoenje odluke o nabavi

Opi kriteriji za donoenje odluke
cijena funkcionalnost, kapacitet, brzina, broj korisnika mogunost poduke i trajne potpore kredibilitet i odrivost dobavljaa na tritu (referencama) elastinost, tj. mogunost prilagodbe i prepravki raspoloivost dokumentacije
Narudba izvedbenog programskog koda

Prednosti narudbe izvedbenog koda
Izvedbeni kd je jeftiniji. Brigu i odgovornost o njegovom odravanju preuzima isporuitelj, uz izuzetak nekih ope primjenjivih komercijalnih programa. Ne mora se kupiti (skupi) razvojni programski alat u kojem je programska oprema pisana.
Dodatni kriteriji
Otvorenost sustava (Portabilnost, interoperabilnost) Tehnike mogunosti (Client-Server, OLTP, OLAP, ...) tehnike konzultacije, odravanje (dinamika razvoja i mogunosti nabavke novih verzija), promptno otklanjanje problema, ponuda gotovih aplikacija, pomo u razvoju vlastitih aplikacija
Mane izvedbenog koda s obzirom na korisnika su sljedee

Izvedbeni kd podrazumijeva potpunu zavisnost od isporuitelja. Ne postoji mogunost prilagodbe specifinim vlastitim potrebama, osim putem posebnog dogovora s isporuiteljem. Dodatna prilagodba lako moe postati predmetom ucjene. Ne postoji mogunost razvoja programske opreme vlastitim snagama.
479
480
Narudba izvornog programskog koda

Prednosti nabavke izvornog koda
Izvorni kd omoguuje stalni razvoj i praenje vlastitih posebnosti, to se moe pokazati kao prednost u odnosu na konkurenciju. Mogunost prilagodbe vlastitim potrebama omoguuje elastinost pri promjenama organizacije poslovanja. Nema bojazni da e nakon prve potrebne izmjene prestati uporaba PO zbog toga to isporuitelj nije trenutno dostupan, postavlja nerazumne uvjete ili je u meuvremenu nestao sa trita. Uvidom u kvalitetna gotova rjeenja pomae se razvoju vlastitih informatikih djelatnika.
Preporuke korisnicima
Izvedbeni kd treba preporuiti onda
kad se radi o standardnim, masovno prodavanim aplikacijama kad korisnik nema vlastite informatike strunjake kad se radi o visokostrunim aplikacijama koje se nee mnogo mijenjati, a korisnik se nema namjeru baviti detaljima te struke kad korisnik nema novaca ili elje za vlastiti informatiki razvoj
Izvorni kd treba preporuiti onda

kad programska oprema predstavlja strateku investiciju kad korisnik raspolae kompetentnim informatiarima ili ima motiva razvijati vlastitu informatiku djelatnost kad isporuitelj ne moe preuzeti obvezu odravanja ili ne moe jamiti da e ostati na tritu kad na tritu ne postoji PO koja odgovara potrebama, ne moe se povoljno kupiti slina, a korisnik raspolae vlastitim informatikim snagama dovoljnim za pisanje nove
Mane narudbe izvornog koda

Izvorni kd je viestruko skuplji od izvedbenog. Potrebna je razvojna inaica programskog alata u kojem je PO napisana. Naruitelj se izlae kunji da nekompetentno mijenja nabavljeni izvorni kd, onesposobi aplikaciju za rad, a izgubi pravo na odravanje. Poskupljuje se odravanje ukoliko se radi o programskoj opremi podlonoj promjenama.
Snienje cijene izvornog koda moe se postii automatizacijom kodiranja, uporabom generatora izvornog koda.
Odabir rjeenja
Odreivanje moguih rjeenja
Identifikacija rjeenja na temelju poslovnih zahtjeva postavljenih tijekom analize Ulazi: specifikacija raunalne opreme i programske podrke te odabrana tehnoloka arhitektura Izlazi: mogua rjeenja novog sustava i njihove karakteristike
Primjer: mogua rjeenja i njihove karakteristike

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

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

Odabir onog rjeenja koje ima najbolju ukupnu kombinaciju izvodljivosti Ulazi: napravljena analiza izvodljivosti, plan projekta, procjena veliine projekta Izlazi: prijedlog sustava s usvojenim promjenama dizajna predloenog sustava
484
Ocjenjivanje kriterija
Na temelju opisa karakteristika ne moe sa sigurnou procijeniti koji je sustav najbolji.
Koristi se sustav bodovanja da bi se usporedio znaaj razliitih kriterija.
Primjer: analiza izvodljivosti za mogua rjeenja

Karakteristike: Operacijski sustav Baza podataka Brzina pretraivanja i dohvata podatka Programski jezik Raspoloiv izvorni kod Korisniko suelje Integrirani sustav pomoi (on-line help) Dokumentacija (papirnata) Mogunosti aplikacije Integracija s drugim aplikacijama Brzina ispisa rauna Teinski faktor 2 1 4 1 1 2 2 2 4 3 4 3 1 1 2 3 1 1 2 3 SuperVideo Ocjena 4 4 5 4 0 5 5 4 5 4 2 5 5 3 5 5 3 3 2 3 Bodovi 8 4 20 4 0 10 10 8 20 12 8 15 5 3 10 15 3 3 4 9 171 Video Boss Ocjena 4 4 4 5 0 5 0 0 1 3 3 5 0 5 0 5 2 3 5 2 Bodovi 8 4 16 5 0 10 0 0 4 9 12 15 0 5 0 15 2 3 10 6 124 Video Ocjena 1 2 1 2 5 3 0 0 2 0 5 0 0 5 5 0 5 5 4 5 Bodovi 2 2 4 2 5 6 0 0 8 0 20 0 0 5 10 0 5 5 8 15 97 ZZ Video Ocjena 3 1 4 2 0 3 0 4 5 0 5 0 0 3 5 3 5 5 2 3 bodovi 6 1 16 2 0 6 0 8 20 0 20 0 0 3 10 9 5 5 4 9 124 486
Weighted Scoring Model

Odredi se teinski faktor za svaki kriterij (npr. 0-3). Pojedinanom kriteriju svakog od rjeenja dodjeljuje se ocjena iz dogovorenog raspona (npr. 0-5), pomnoena s odgovarajuom teinom. Dobiveni pojedinani rezultati sumiraju se za svako od rjeenja. gdje su Si = ukupna vrijednost i-tog rjeenja sij = vrijednost j-tog kriterija za i-to rjeenje wj = vanost ili teina j-tog kriterija
Rad s razliitim pisaima Rad u mrei Vrijeme obuke korisnika Arhiviranje podataka Upotreba konfiguracije za druge poslove Broj instaliranih paketa Datum prve instalacije Cijena paketa Cijena raunala i sistemskog softvera Ukupno bodova: 485
S i = sij w j
j =1
to uiniti kada su sustavi (pod)jednako bodovani ? to uiniti ako pojedino svojstvo ima vie podsvojstava ?
Izbor dobavljaa
Definiranje kriterija i opcija
Ulazi: specifikacije zahtjeva na programsku podrku i raunalnu opremu funkcionalnost, dodatna svojstva, kljuni parametri performanci Izlazi: lista potencijalnih dobavljaa, proizvoda ili usluga te kriteriji za odabir
Ugovaranje i realizacija posla

Ugovaranje posla
sklapanje ugovora koji definira uvjete suradnje, isporuke i naplate, integracije s postojeim sustavom, odravanja i slino
Prikupljanje ponuda, natjeaj

zahtjev za reference (request for quotations - RFQ) kada je odreen proizvod koji se moe nabaviti od razliitih dobavljaa prikupljaju se informacije o konfiguracijama, cijenama, odravanju zahtjev za ponude (request for proposals - RFP) kada postoje razliiti dobavljai i/ili proizvodi, a eli se odabrati najbolje rjeenje - prikupljaju se ponude koje su skup "referenci"
Ugovori se mogu raskinuti ili ne ispuniti kako je bilo zamiljeno

Izvoditelj projekta treba biti stimuliran proporcionalno ostvarenoj, u praksi dokazanoj i od korisnika prihvaenoj funkcionalnosti.
Neke cijene usluga u Hrvatskoj (okvirno, razni izvoai)

programiranje: 200, 260, 380 HRK/h, prog. dugotrajno: 3000 HRK/dan, 12000 HRK/tjedan, 40000 HRK/mj. teaj: 400, 750, 1200 HRK/h, 7500 HRK/dan poduka korisnika: 400 HRK/h savjet: 220, 300, 450, 600, HRK/h, 7500 HRK/dan
Odabir ponuda
provjera sadraja ponuda izrada rang liste, poeljno odvojenim ocjenjivanjem pojedinanih ponuda odabir objektivno najboljeg ponuaa To se naalost vrlo teko uklapa u zakonske odredbe po kojima treba tono specificirati to se eli a mora se kupiti najjeftinije.
Neke cijene softvera u Hrvatskoj
487
488
Vodopadni (waterfall) model

Klasini vodopadni model
slijedno napredovanje iz faze u fazu nisu dozvoljene naknadne promjene rezultata prethodnih faza primjeren velikim projektima (investicijama) prikladan za dobro definirano okruenje, gdje postoje razraene procedure rune obrade ili raunalski sustav koji treba unaprijediti Nedostaci problem u sluaju pogreaka ili novih/promijenjenih zahtjeva uvoenje prema gore (bottom up): moduli, podsustavi, sustav sustav nije upotrebljiv dok nije gotov u potpunosti problem predodbe o produktu na temelju pisane specifikacije
Modeli razvoja i metodologije
490

Pseudostrukturni vodopadni model
povratna veza i mogunost promjene rezultata prethodnih faza uvoenje prema dolje: moduli na viim, pa na niim razinama primjena tehnika strukturiranog programiranja
Analiza
Analiza
Oblikovanje
Oblikovanje
Strukturni (radikalni)
aktivnosti razliitih faza mogu se obavljati istovremeno koritenje rjenika podataka, 4GL i generatora aplikacija prikladan kada se unaprijed ne zna konani izgled sustava mora nastati (papirnati) model sustava
Izrada
Izrada
Evaluacija
Evaluacija
Primjena
Primjena
491
492
V model
Validacija
Analiza Scenariji aplikacije Test prihvatljivosti
Prototipski model razvoja

Prototip koji se radi da bi se isprobale neke mogunosti
Model oponaanja (mock-up, model u naravnoj veliini) jednoekranski ili vieekranski model kojim se prikazuje kako e izgledati dio sustava (npr. suelje) Istraivaki model (research model) istraivanje dijelova sustava kako bi se provjerile neke kljune postavke (npr. provjera performanci odreenog modula) Ugradbeni model (implementation model) traenje razliitih naina na koje se sustav moe izraditi (npr. koji sustav za upravljanje BP, programski jezik, raunala)
Verifikacija
Specifikacija zahtjeva
Testirani sustav
Strukturno oblikovanje
Ogledni sluajevi
Integracija sustava
Model sustava
Testirani softver
Prototip koji postupno, inkrementanlnom doradom -bistrenjem (stepwise refinement) postaje dio zavrnog IS
podrazumijeva iterativni pristup, obino koritenjem 4GL radni model (working model) daje se na uvid korisniku omoguuje korisniku stvaranje slike o izgledu sustava korisnik daje primjedbe za popravak i poboljanja stjee se bolja slika o zahtjevima korisnika uklanjaju se mogua iznenaenja na kraju razvoja
definiraju se rezultati (proizvodi) pojedinih faza koji se prosljeuju u slijedee faze odreuju se rezultati kojima se testiraju elementi IS na razliitim stupnjevima razvoja
Detaljno oblikovanje
Ogledni sluajevi
Integracija modula
Dizajn modula
Testirani moduli
Kodiranje i testiranje
Brzo prototipiranje (rapid prototyping)

funkcionalni prototip - zamjenom pravim rjeenjima postaje radni sustav prikladno za male projekte (tzv. oneman project) Prednosti: iteracije promjena korisnici se smiju predomisliti poveanje kreativnosti i brzine razvoja Nedostaci: zaboravljanje da prototip nije pravi sustav mogui neuspjeh zamjene prototipa radnim sustavom dokumentacija proizlazi iz izrade, uz opasnost da pisane specifikacije nikad nee biti napravljene nemogunost ispravne procjene i planiranja resursa
Ogranieno/strukturirano (constrained prototyping)

izrada prototipa kao sredstvo odreivanja zahtjeva nefunkcionalni prototip (prikaz izgleda) u odreenom trenutku se prekida i slijedi faza oblikovanja sustava
Odreivanje zahtjeva
Dizajn prototipa
Izrada prototipa
Razvoj prototipa
Radni sustav
495
496
Evolucijski model
Primjena IS mijenja pogled korisnika, a njegove potrebe se mijenjaju (rastu) tijekom primjene. Informacijski sustav raste s organizacijom koju podrava. Udruivanje brzog i ogranienog prototipiranja
izrada u inkrementalnim koracima, dovoljno malim da se mogu obaviti prototipski slijedovi razvojnih aktivnosti - svaki od slijedova vodi operabilnom proizvodu koji se isporuuje i generira daljnje zahtjeve
Analiza Oblikovanje Izrada Evaluacija
Spiralni model
Na poetku svake faze provodi se procjena rizika (risk analysis)
nastoji se utvditi mogue rizike i razrijeiti ih prije nastavka (uklanjanjem ili svoenjem na najmanju moguu mjeru)
U sluaju da je rizik prevelik, projekt se prekida.

Analiza rizika --------------------------ANALIZA --------------------------Verifikacija
Analiza rizika --------------------------OBLIKOVANJE --------------------------Verifikacija
PRIMJENA
Analiza
Oblikovanje
Izrada
Evaluacija
Analiza rizika --------------------------IZRADA --------------------------Testiranje
Analiza
Oblikovanje
Izrada
Evaluacija
Analiza rizika --------------------------INTEGRACIJA --------------------------Testiranje
Analiza
Oblikovanje
Izrada
Evaluacija
497
498
Spiralni model
Spiralni prikaz
radijalna koordinata predstavlja kumulativni troak svaka petlja spirale od osi X predstavlja jednu fazu razvoja faza moe biti realizirana slijedno, prototipski ili evolucijski odluka o nastavku razvoja donosi se prolaskom kroz os X
kumulativni troak 4 4 4 4 1 1 1 1 integracija izrada oblikovanje analiza
Spiralni model
2 2 2 2
1. Analiza rizika, procjena alternativa 2. Razvoj i verifikacija sljedeeg "produkta" 3. Planiranje sljedee faze 3 4. Pregled - Odreivanje ciljeva, alternativa i ogranienja
Spiralni model
Primjeri rizika:
rizik da isporueni produkt nee odgovarati stvarnim zahtjevima izrada prototipa kao dio faze odreivanja zahtjeva rizik da e cijena izrade premaiti korist ostvarenu uporabom provoenje analize trokova-koristi (cost-benefit) prije provoenja svake pojedine faze
Metodologije
Metodologija (methodology) = metoda + idejni pristup
Kolekcija procedura, tehnika, alata i dokumentacijskih pomagala, potkrijepljenih filozofijom, koji potpomau izgradnju informacijskog sustava [Avison & Fitzgerald, 1995] Skup naela izrade IS, koji se u odreenoj situaciji svodi na metodu jedinstveno prikladnu toj situaciji [Checkland] razraen "plan bitke" ili "kuharica" za postizanje eljenog rezultata
Primjena:
interni projekti (naruitelj i izvoa iz iste organizacije) izgradnja velikih sustava (trokovi izrade malih sustava su mali) kada provoenje analize rizika ne predstavlja preveliki relativni troak (npr. za projekte iznad 25 kUSD)
Komponente metodologije
A methodology will consist of phases, themselves consisting of subphases, which will guide the systems developers in their choice of techniques that might be appropriate at each stage of the project and also help manage, control and evaluate system projects. [Avison & Fitzgerald, 1995] etape, stadiji projekta zadaci za svaki pojedini stadij izlazi (projektna dokumentacija) preporuke (vodi) uporabe odabranih tehnika i pomagala nain upravljanja projektom i nadzora projekta
Analiza rizika moe se provesti i za vanjske (ugovorene) projekte

naruitelj je moe provesti prije poetka projekta da bi se osigurao od neuspjeha, primjerice prije potpisa ugovora izvoai je mogu provesti tijekom izrade (primjerice radi procjene mogue uporabe novog alata)
Uloga metodologija
Cilj metodologija
omoguiti sustavni postupak razvoja kojem e se moi pratiti napredak uspostaviti komunikaciju izmeu sudionika ukljuenih u izgradnju IS (poslovodstvo, korisnici, analitiari, programeri ) osigurati skup tehnika koji e omoguiti da se zadaci izvravaju na standardne i provjerene naine osigurati uinkovit nadzor sa ciljem uoavanja pogreaka u ranim fazama omoguiti elastine promjene poslovanja i tehnologije (npr. odvajanjem analize i oblikovanja) uokviriti razvojnu strategiju kojom e se ukloniti ad hoc rjeavanje problema odrediti ili ukazati kada i u kojoj mjeri je potrebno ukljuivanje korisnika, te poticati i omoguiti ukljuivanje korisnika kada se za to ukae potreba osigurati da se dovoljno panje posveti analizi poslovanja, ime e se osigurati izrada sustava koji odgovara poslovanju i zahtjevima korisnika
Uloga metodologija
Jeftinije je otkriti i popraviti pogreku u ranim fazama, jer:
lake je popraviti dokumentaciju nego mijenjati programski kd izmjene u kasnijim fazama zahtijevaju promjene rezultata prethodnih faza lake je pronai pogreku tijekom faze u kojoj je nastala, nego traiti je i popravljati na temelju posljedinih uinaka primijeenih u kasnijim fazama
Relativno trajanje i cijena otkrivanja pogreaka u razliitim fazama

M o d u le co d i n g 5% M od ule te st in g 7% In te g r a t io n 6%
C i j e n a
D e si g n 6%
R e q u ir e m e n t s 4% P ro b le m D e f 3%
P la n n in g 2%
M a inten a nc e 6 7 %
P n A a , O liko n , Izra a O ra n la , n liza b va je d , d va je

Pristup razvoju
Tijekom projektiranja IS izrauju se uglavnom sve vrste modela, ali se razlikuje pristup razvoju pojedinih metoda (metodologija). Usmjerenost procesima (npr. SA/SD)
za korisnika jednostavniji pristup omoguuje opisivanje specifinih funkcija problem odreivanja razine dekompozicije (razine osnovnih procesa) nedovoljna panja modelu podataka, koja za posljedicu moe imati neodgovarajui model baze podataka i oteanu integraciju aplikacija uslijed nekompatibilnih podataka
Komercijalne metodologije
Neke strukturirane metodologije:
AD/Cycle (Application Development Cycle) BSP (Business System Planning) CASE*Method IEM (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)
Usmjerenost podacima (npr. IEM)

sloeniji opis strukture podataka jednostavniji tokovi podataka procesi se definiraju analizom podataka (grupiraju oko podataka) bre konvergira kraju, jer je skup objekata (entiteta) modela konaan
Objektno usmjerene metodologije:

Yourdon/OO (Yourdon / Object Oriented) OMT (Object Modelling Technique) BOOCH (Booch93) Schlaer-Mellor Unified Modelling Process (Rational)
Poetak razvoja definiranjem dogaaja (npr. JSD)

primjereniji sustavima za rad u stvarnom vremenu
Komercijalne metodologije
Kuhanje po kuharici (receptu) ne znai da e jelo biti dobro!
Zahtjevi se mogu mijenjati u vremenu. Preporuene aktivnosti ne moraju uvijek biti prikladne, primjenjive ili potrebne. Inzistiranje na provoenju propisanih procedura vodi u zanemarivanje stvarnih problema, to za posljedicu moe imati formalno dobro napravljen, a neuspjean sustav.
Veina metodologija namijenjena je analizi i oblikovanju. Rijetke podupiru sve faze ivotnog ciklusa (npr. IEM). Metodologije bi trebale biti podrane odgovarajuim alatima za upravljanje i projektiranje (CASE), to nije uvijek ispunjeno u praksi. Alternative komercijalnim metodologijama
zdrav razum najbolje dokazano u praksi - "Best practices" preice do rjeenja problema temeljene na temelju slinih iskustava - "Rules of thumb" prilagodba razvojnog procesa http://www.rspa.com/apm/index.html
Moderni postupci
Brzi razvoj programske opreme

Brzi razvoj aplikacija (RAD - Rapid Application Development)
uinkovita izrada programske opreme u relativno kratkom vremenu sustavna i vremenski saeta primjena sljedeih tehnika i pomagala: aktivno i uinkovito ukljuenje korisnika odgovarajue upravljanje projektom ispravna uporaba metoda i tehnika razvoja uporaba CASE pomagala i modernih programskih jezika (4GL) upravljano prototipiranje
Brzi razvoj programske opreme

Faze brzog razvoja
JEM (Joint Enterprise Modeling ) sjednice na kojima poslovodstvo i analitiari trae naine usmjerenja organizacije i naine kako je uiniti kompetitivnom strauju se ciljevi organizacije, problemi, kritini imbenici uspjeha te strategijske mogunosti JRP (Joint Requirements Planning) analiza zahtjeva s obzirom na poslovni sustav prouavaju se funkcije sustava, identificiraju upotrebljive i uklanjaju nekorisne funkcije te istrauju i definiraju informacijske potrebe JAD (Joint Application Design) nastoji se oblikovati sustav tako potpuno odgovara zahtjevima zahtijeva tijesnu suradnju korisnika, izvoditelja i menadera konstrukcija (construction) iterativno prototipiranje zavretak projekta (cutover) provjera rada, izrada dokumentacije, poduka korisnika
RAD se obavlja malim ekipama za 60-120 dana (priblino 4*5=20 tjedana), nad podsustavima veliine 25-30 tablica Cijena postignutog ubrzanja moe biti gubitak pregleda nad cjelinom sustava. Treba pripaziti da brzina ne postane sebi svrhom, jer tada vodi u improvizaciju (izradu prirunih rjeenja) i prljavi razvoj.
Primjer RAD projekta

Tjedni 1-4
Pokretanje projekta Istraivanje Priprema JRP sjednice Obavljanje JRP sjednice Priprema JAD sjednice
Information Engineering (IE)
IE zasniva se na analizi poslovnih zahtjeva iz koje se izdvajaju aplikacije IS i prioriteti tih aplikacija. Aplikacije postaju projekti u kojima se provode postupci analize i dizajna da bi se razvili produkcijski sustavi.
Tjedni 10-14
Razvoj i testiranje Priprema konverzije Planiranje zavretka
Tjedni 15-20
Izrada dokumentacije, priprema poduke Poduka Zavrno testiranje Zavretak projekta
Tjedni 5-9
Prva JAD sjednica Poetak dizajna Konsolidacija JAD dizajna i prototipa Prototipovi za test uporabljivosti Druga JAD sjednica Zavretak dizajna
Znaajke IE
Podatkovno usmjerena ali procesno osjetljiva tehnika koja se primjenjuje na organizaciju kao cjelinu ili na neki njezin znaajni dio, za razliku od klasine strukturne analize koja se odvija projekt-po-projekt Osnovno naelo jest da se IS moraju graditi kao to se grade drugi unikatni proizvodi, npr. u graditeljstvu ili brodogradnji.
511
512
Faze IE
Planiranje strategije IS - Information Strategy Planning (ISP) promatranje poslovanja kao cjeline s ciljem definiranja opeg, sveobuhvatnog plana i arhitekture za slijedni razvoj informacijskih (pod)sustava izdvajanje poslovnih podruja i pridjeljivanje prioriteta
poslovno podruje skup poslovnih procesa koji se proteu organizacijom (crossorganizational business processes) a moraju biti visoko integrirani da bi se ostvarila strategija ili misija
Ekstremno programiranje (eXtreme Programming)

Naela [Kent Beck, 1996] Komunikacija (communication).
XP zahtijeva komunikaciju u svim fazama projekta, meu svim njegovim sudionicima. Ovdje se prvenstveno misli na komunikaciju meu lanovima razvojnog tima, zatim na meusobnu komunikaciju lanova tima s voditeljima projekta, te komunikaciju naruitelja s izvoaima (lanovima razvojnog tima, te njihovim voditeljima).
Analiza poslovnih podruja - Business Area Analysis (BAA) prouavanje poslovnih podruja i definiranje poslovnih zahtjeva za visoko organizirani i integrirani skup informacijskih (pod)sustava i aplikacija potpore poslovnog podruja Definiranje aplikacija izdvajanje aplikacija i definiranje njihovih prioriteta na temelju analize poslovnih podruja aplikacije postaju projekti u kojima se primjenjuju drugi postupci analize i dizajna
Jednostavnost (simplicity).
Dijelovi softvera, kao i njegova cjelokupna arhitektura moraju u svakoj fazi projekta biti jednostavni. Jednostavnost se ostvaruje kontinuiranim refactoring-om i svoenjem projektne dokumentacije na minimalnu prihvatljivu razinu.
Povratne informacije (feedback).

XP nalae kontinurane povratne informacija od svih sudionika projekta, to znaajno podie kvalitetu rada i ispunjenje rokova. Dobre povratne informacije onemoguavaju nerazumijevanje meu sudionicima projekta, te dre projekt na "pravom putu".
Hrabrost (courage). Podatkovno usmjerena paradigma

Budui da je informacija proizvod podataka, podaci moraju biti planirani prvi! Modeliranje zapoinje modelima podataka Zatim se rade modeli procesa slino onima u strukturiranoj analizi
U XP hrabrost podrazumijeva sposobnost provoenja tekih odluka (npr. odbacivanja dijelova koda kada je to neophodno ili nametanja velikih promjena u kasnoj fazi projekta) ili odluka koje u danom trenutku nisu pretjerano popularne. Takoer, hrabrost podrazumijeva meusobnu iskrenost svih lanova projektnog tima.
XP tehnike
"Svakodnevne prakse" Igra planiranja (The Planning Game).
XP uvaava mogunost promjene specifikacija koje definiraju funkcionalnost sustava. prihvati promjenu! (embrace change!) jedan od osnovnih XP postulata Igra planiranja definira funkcionalnosti sljedee verzije, prije nego to njen razvoj stvarno i pone. U poetku se kreira grubi plan koji se redefinira kroz razgovore s naruiteljima i korisnicima. Korisnici se izraavaju "priama", tako da svaka pria definira jedan dio funkcionalnosti sustava. Priama se dodjeljuju prioriteti i ciljano vrijeme implementacije. (1-3 tjedna po zahtjevu)
XP tehnike
Jednostavan dizajn (Simple Design).
Najei argument osporavatelja XP-a, koji tvrde da XP zanemaruje dizajn sustava. A zapravo, dizajn arhitekture sustava je kontinuirani proces koji se u malim koracima odvija tijekom itavog razvoja.
Testiranje (Testing).
testovi komponenti (unit testing) testovi prihvatljivosti (acceptance testing)
Mala izdanja/verzije (Small Releases).

XP preporuuje relativno esto izdavanje novih verzija sustava obino u prvom trenutku u kojem to ima poslovnog smisla, tj. kada sustav zadovoljava funkcionalnost traenu od strane naruitelja. esto izdavanje novih verzija pojaava komunikaciju a time dotok povratnih i igru planiranja.
Prilagodba programskog kda (Refactoring).

Refactoring je tehnika kojom se pojednostavnjuje programski kod uklanjanjem ponavljanog koda i uklanjanjem (nepotrebnog) sloenog koda.
Programiranje u paru (Pair Programming).

Programeri rade u parovima, na nain da jedan pie kd, a drugi prati pisanje i revidira kd pazei da kod bude jasan i razumljiv.
Metafora sustava (System Metaphor).

Metafora sustava je analogna onome to veina drugih metodologija naziva arhitekturom sustava. Metafora mora biti jasno izraena te nedvosmisleno shvatljiva svim lanovima projektnog tima. XP ne definira format ili tehniku u kojoj metafora mora biti izraena
516
XP tehnike
Zajedniko vlasnitvo (Collective Ownership).
Svi razvojni inenjeri koji sudjeluju u razvoju projekta imaju pravo mijenjati bilo koji njegov dio u bilo kojem trenutku.
Ujedinjeni razvojni proces

Unified software development process (skraeno UDP)
izvorno Objectory kasnije Rational Unified Process (RUP)
Neprestana izgradnja novih verzija kda (Continuous Integration).

XP nalae izgradnju novih verzija nekoliko puta dnevno, tj. nakon svake implementirane funkcionalnosti.
Iterativni i inkrementalni razvoj

softver se razvija i objavljuje po dijelovima glavne faze obavljaju se kroz niz iteracija faza konstrukcije (izrade) svaka iteracija obavlja se standardnim ivotnim ciklusom koji ukljuuje analizu, oblikovanje, ugradnju i provjeru rezultat iteracije je proizvod zavrne kakvoe (production-quality), provjeren i integriran, koji zadovoljava podskup ukupnih zahtjeva isporuke mogu biti interne ili prema korisnicima
40-satni radni tjedan (40-hour week).

Smatra se da umorni razvojnici ne mogu postii maksimalnu uinkovitost u radu, pa zabranjuje prekovremeni rad dva tjedna zaredom.
Nazonost naruitelja (On-site customer).

Naruitelj ili predstavnik naruitelja mora biti nazoan prilikom razvoja sustava kako bi bio dostupan u sluaju potrebe za pojanjenima, te kako bi pomogao u definiranju sustava i pisanju testova.
Standardi pisanja kda (Coding Standards).

Programeri moraju pisati kd u skladu s dogovorenim standardima.
517
518
Glavne faze razvoja

Poinjanje (Inception)
opravdanje razloga za pokretanje projekta prikupljanje najvanijih zahtjeva (10% detaljno) odreivanje dosega projekta
Glavne faze razvoja

Core Workflows
Requirements Analysis Design Implementation Testing
iter. #1 iter. #2 iter. #n-1 iter. #n
Inception
Elaboration
Construction
Transition
Elaboracija (Elaboration)
prikupljanje detaljnih zahtjeva (80%) globalna (high-level) analiza i dizajn ustanovljavanje osnovne arhitekture planiranje konstrukcije
Konstrukcija, gradnja (Construction)

prikupljanje ostalih zahtjeva + promjene zahtjeva razrada arhitekture i izrada sustava kontinuirana integracija
Prijelaz (Transition)
beta testiranje, podeavanje performansi, poduka korisnika provjera prihvatljivosti i zadovoljstva korisnika
Post-implementacija (Post-deployment)
nastavak evolucijskog razvoja uz ouvanje integriteta aplikacije
Increments
Odreivanje iteracija
Broj i trajanje iteracija
za projekte do 18 mjeseci, otprilike 3 do 6 iteracija uobiajeno podjednakog trajanja mogu varirati ovisno o fazi (u konstrukciji due)
Prva iteracija
najee najtea zahtijeva pripremu okruenja, ekipe i posla opasna zbog mogue pretjeranog optimizma ako se krivo procijeni moe izazvati pomake i neeljene uinke (smanjenje broja iteracija, ukupno slabije rezultate)
Organizacija i upravljanje projektom
521
Generiki modeli organizacije

Projektna organizacija
osoblje organizirano unutar/oko projekta prednosti: bre odluivanje, minimizira potrebno suelje izmeu lanova, potie identifikaciju osoblja s projektom nedostatci: prikladna za male projekte, minimalna raspodjela ekspertize
Organizacija i ekipni rad

Ekipni rad (teamwork)
Ekipa je "samoupravljaka" jedinica, koja posluje u duhu suradnje svojih lanova, njihove koordinacije i njima unaprijed poznatih procedura. Prednosti: kvalitetnije donoenje odluka "ne treba nam soliti pamet" motivacija lanova "zajedno smo jai" inovativnost "dvoje zna vie nego jedan, " Sinergija 2+2=5 ?
Funkcionalna organizacija
osoblje organizirano po funkcionalnim odgovornostima pojedina funkcija moe podupirati vie razliitih projekata prednosti: potpomae specijalizaciju (poveanje broja specijalista) nedostatci: smanjuje osjeaj pripadnosti projektu, tj. koheziju projekta
Matrina organizacija
u osnovi funkcionalna, osoblje izmijeano u razliitim projektima prednosti: projektna komponenta pogoduje uspjenosti projekta funkcionalna komponenta pogoduje poveanju specijalizacije nedostatak: mogui sukob interesa
Razvoj ekipe
Razvoj ekipe (Forming, Storming, Norming, Performing)
Formiranje ljubaznost, nesklonost iznoenju stavova, preputanje voenju "Jurianje" nesloga, sukob osobnosti, grupaenje/stranarstvo, pomanjkanje kvalitetne komunikacije, nesposobnost dogovaranja Normiranje uvianje dobrih strana zajednikog rada, uvaavanje Predstavljanje, djelovanje povezivanje u uinkovitu operativnu grupu
Performing Group effectiveness Forming
Modeli ekipa
Klasina organizacija ekipe (Chief Programmer Team)
glavni programer (chief programmer) utjelovljuje znanje i odluivanje ekipe mora istovremeno biti dobar (vrhunski) programer i voditelj u poboljanoj (revidiranoj) organizaciji ima ulogu voditelja ekipe rezervni programer (backup programmer) slui kao zamjena za nekog od mlaih (junior) programera u poboljanoj (revidiranoj) organizaciji ima ulogu pomonika voditelja
Administrator
Norming
Glavni programer (voditelj) Rezervni programer (pomonik) Programer
Storming
Group effort
Modeli ekipa
Moderna organizacija ekipe (4GL ekipa)
voditelj projekta (project leader) vii sistem analitiar suradnja s korisnikom (user liason) poslovni analitiar konceptualno i logiko oblikovanje sistem analitiar isporuka sustava/aplikacija poslovni analitiar nabava i pogon opreme sistem inenjer za raunala mreni servisi sistem inenjer za komunikacije programsko inenjerstvo programer-analitiar izrada dokumentacije urednik/pisac (editor / technical writer) potporno osoblje: administrativni koordinator, tehniari, inovnici
Modeli ekipa
Elastini model ekipe
upravitelj ekipe upravljanje osobljem (plae, reije) voditelj ekipe upravljanje razvojem (organizacija posla) projektant (analitiar-programer) analiza, oblikovanje i izvedba programer (programer aplikacija) kodiranje, testiranje administrator baze podataka administriranje baze podataka sistem inenjer(i) odravanje mree i raunala
Sastav ekipe odgovara poslovima koje treba obaviti.

Raspodjela uloga konkretnim lanovima, kao i broj lanova pojedine kategorije ovise o konkretnom projektu i raspoloivosti djelatnika. Na primjer: ulogu upravitelja ekipe i voditelja ekipe moe imati ista osoba ekipa moe imati vie programera uloga administratora BP i sistem inenjera moe se dodijeliti istoj osobi
Neke stvarne organizacije koriste gornju podjelu za opis radnih mjesta.
Ovakav model ekipe moe se primijeniti bez obzira na mogue razliitu sistematizaciju radnih mjesta u nekoj organizaciji.
527
528
Organizacija velikih projekata

Upravitelj ili voditelj projekta, (project manager, project leader)
upravlja projektom posao obavlja vie ekipa nadreen voditeljima / upraviteljima ekipa
Upravitelj ekipe (team manager)

planiranje, upravljanje i nadzor, rukovoenje ostalim lanovima ekipe
Voditelj ekipe (team leader)

tehniki aspekte aktivnosti koje se odnose na izradu i/ili uvoenje aplikacija/podsustava IS
voditelj projekta (project leader)
Ekipa moe imati i dva voditelja
Upravljanje projektom
voditelj ekipe (team leader)
upravitelj ekipe (team manager)
lanovi ekipe
529
Upravljanje projektom (Project management)
plan, staff, organize, schedule, direct, control Proces organiziranja, planiranja, upravljanja i nadzora razvoja sustava kojim e se postii prava funkcionalnost, na vrijeme i uz minimalne trokove. Ukljuuje razliite aspekte: plan Koje aktivnosti i u kojem vremenskom razdoblju treba obaviti? sredstva/resursi Koji su kadrovi (osoblje) i oprema potrebni? organizacija Koji je odnos pojedinih resursa? raspored Koji je redoslijed aktivnosti? upravljanje Kako usmjeriti i motivirati izvoae (ekipu)? nadzor Potuje li se plan? Elementi plana Veliina projekta: funkcijske toke, broj linija koda Napor izrade: ovjek-mjeseci Vrijeme izrade: mjeseci
Planiranje projekta (planning)
odrediti doseg, vremenski raspored i financijska sredstva identificirati pokroviteljstvo (sponsorship) kao jamstvo provedbe izabrati upravitelja/voditelja projekta odabrati alate za upravljanje projektom pokrenuti projekt
Planiranje vremena, izrada rasporeda (scheduling)

odreivanje aktivnosti procjena i pridjeljivanje sredstava potrebnih za pojedinu aktivnost procjena trajanja pojedine aktivnosti odreivanje zavisnosti izmeu aktivnosti izrada vremenskog rasporeda za projekt
Upravljanje, nadzor (controlling)

odreivanje postupka izvjetavanja o napretku projekta praenje napretka redovitim revizijama preraspodjela sredstava i aktivnosti sukladno dogaajima auriranje vremenskog rasporeda
Izgradnja IS je posao koji se, unato posebnostima, obavlja kao neki drugi inenjerski poslovi, u planiranom vremenu i s planiranim resursima.
Planiranje projekata
Zato planirati?
Ako neto moe poi krivo, poi e krivo u najgore vrijeme i na najgorem mjestu (Murphyjev zakon) Murphy je bio optimist (Grimmov korolar)
Planiranje projekta
Izrada plana
utvrditi kljune aktivnosti i dogaaje odrediti vremenski redoslijed aktivnosti i dogaaja utvrditi potrebna sredstva pripisati/racionalizirati pripadne trokove povezati pojedine pod-projekte/poslove u glavni projekt iterativno razraditi plan revidirati plan sukladno postojeem iskustvu/saznanjima
to je plan (a to nije)
plan ne predstavlja izvjesnost ili neto to e se zacijelo dogoditi plan je naa najbolja procjena, zasnovana na pretpostavkama i iskustvu elementi plana: aktivnosti, kljuni dogaaji (milestones), resursi (sredstva), trokovi
Programerski paradoks (Brooks, 1982)

Nakon to je odgovarajui broj osoba pridruen nekom zadatku, dodavanje osoblja usporava razvoj, umjesto da ga ubrza.
Metode namijenjene upravljanju projektima

PRINCE (PRojects IN Controlled Environments) strukturirana metoda za upravljanje projektom definiranje organizacijske strukture projekta definiranje strukture i sadraja plana projekta definira skup provjera i izvjea koji se koriste za nadzor provedbe COCOMO SUM
Sloeni projekti zahtijevaju velike ekipe

Najbolja strategija je podijeliti projekt u niz manjih projekata (podprojekata) koji se mogu nezavisno obaviti.
Neuspjeno planiranje = planiranje neuspjeha.

Tehnike za vremensko planiranje

tapiasti/stupasti dijagrami - Gantogrami (Gantt Charts)
prikaz aktivnosti linijama, duljine razmjerne vremenu obavljanja prikazuje predvieni poetak i kraj aktivnosti, njihovu meusobnu ovisnost te odgovornost za izvoenje aktivnosti naglaava vremensko preklapanje aktivnosti
ID 1 2 3 4 5 6 7 8 9 10 Task Name Projekt Odreivanje zahtjeva Oblikovanje suelja Oblikovanje izvjea Modeliranje podataka Kontrolna toka Korisnika dokumenta Programiranje Testiranje Instalacija Duration Start Finish Fri 14.10.05 Fri 17.06.05 Fri 29.07.05 2 Fri 29.07.05 2 Fri 12.08.05 3;4 Predeces5

Mreni plan - PERT/CPM (Program Evaluation Review Technique/Critical Path Method)
vremenski prikaz aktivnosti i njihovih uvjetovanosti vidljivo je koje aktivnosti se mogu vriti paralelno, a koje u sljedovima jer zavise o ranijim aktivnostima naglaava kritini put (critical path) projekta
May '05 Jun '05 Jul '05 Aug '05 Sep '05 Oct '05 Nov 18 25 02 09 16 23 30 06 13 20 27 04 11 18 25 01 08 15 22 29 05 12 19 26 03 10 17 24 31 0
110 days Mon 16.05.05 5 wks Mon 16.05.05 6 wks Mon 20.06.05 6 wks Mon 20.06.05 2 wks Mon 01.08.05 0 days
Fri 12.08.05 Fri 12.08.05 5 May '05 Jun '05 Jul '05 Aug '05 Sep '05 Oct '05 5.5 wks Mon 15.08.05 Wed 21.09.05 6 25 02 09 16 23 30 06 13 20 27 04 11 18 25 01 08 15 22 29 05 12 19 26 03 10 5 wks Mon 15.08.05 Fri 16.09.05 6 3 wks Mon 19.09.05 1 wk Mon 10.10.05 Fri 07.10.05 8 Ana;Prog Fri 14.10.05 7;9
2.5 w ks
Ana;Prog Ana;Prog Ana;Prog 12.08 Prog Prog Prog

Programiranje
Start: 15.08.05 Finish: 16.09.05 Res: Prog ID: 8 Dur: 5 wks
Kontrolna toka
Milestone Date: Fri 12.08.05 ID: 6
Korisnika dokumentacija
Start: 15.08.05 Finish: 21.09.05 Res: Prog ID: 7 Dur: 5.5 wks
Instalacija
Start: 10.10.05 Finish: 14.10.05 Res: Prog ID: 10 Dur: 1 wk
Testiranje
Start: 19.09.05 Finish: 07.10.05 Res: Prog ID: 9 Dur: 3 wks
535
536

Upravljanje kljunim dogaajima - (Milestone Management)
prikaz planiranih aktivnosti i trenutnog statusa njihovog izvrenja u odreenim vremenskim trenutcima razmatra se stupanj dovrenosti neke/nekih projektnih aktivnosti kljuni dogaaj je obino kraj neke faze ili aktivnosti oekuje se da faza ili aktivnost budu gotovi druge aktivnosti zapoinju nakon to se to ostvari pomak kljunog dogaaja ima za posljedicu vremenski preraspored
TEAM PROJECT Recommended Milestone Management Plan Task/Deliverable Prep Cover, Executive May '05 Summary, Contents, etc. Jun '05 Draft Introductions,25 02 09 16 etc. 30 06 13 20 Appendices, 23 18 Final Introductions, Appendices, etc. Full Edit of Final Report Edit, Assemble, Distribute Final Copies Write Status Report 1 Write Status Report 2 Write Status Report 6 Draft Decomposition Diagram Draft Context Diagram Draft Essential Data Flow Diagrams Draft Typical Process Specifications Final Decomposition Diagram Final Context Diagram Final Essential Data Flow Diagrams Final Typical Process Specifications FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.
2.5 w ks
Izrada plana
Definiranje zadataka i njihove meuzavisnosti
Primjer: zadatak T3 (npr. ugradnja komponenti) ovisi o zadatku T1 (npr. oblikovanje komponenti) oblikovanje mora biti zavreno prije ugradnje.
Zadaci T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Trajanje (u danima) 8 15 15 10 10 5 20 25 15 15 7 10 Ovisnosti T1(M1) T2,T4(M2) T1,T2 (M3) T1(M1) T4(M5) T3,T6 (M4) T5,T7 (M7) T9 (M6) T11 (M8)
Assigned
Plan Date
Actual Date
Status
Jul '05 Aug '05 Sep '05 Oct '05 Nov 27 04 11 18 25 01 08 15 22 29 05 12 19 26 03 10 17 24 31 0
537
538
Izrada plana
Izrada mrenog plana na temelju definiranih zadataka i zavisnosti
Aktivna mrea ita se s desna na lijevo. Sve aktivnosti moraju zavravati u kljunim tokama (M1 ,M2, M3, M4...). Tek kad se uspjeno prijee kljuna toka moe se zapoeti sa sljedeom aktivnosti. Npr. zadatak T9, ne moe zapoeti sve dok zadaci T3 i T6 nisu zavreni. Dolazak na toku M4 pokazuje da su ti zadaci dovreni.
14/7/02
M1
Izrada plana
Kritini put
Minimalno vrijeme potrebno za zavretak projekta moe se procjenjivati prema najduem putu na aktivnoj mrei (kritini put). U ovom primjeru to je 11 tjedana ili 55 radnih dana. (T1-T3-T9-T11-T12) Prekoraenje vremenskog roka najee je vezano uz kritini put Aktivnosti koje kasne, a ne lee na kritinom putu ne bi trebale uzrokovati vremensko prekoraenje (npr. ako T8 kasni ne bi trebalo utjecati krajnji datum jer T8 ne lei na kritinom putu).
14/7/02
M1
T3
4/8/02
M4
T9
T1 4/7/02
Start
25/8/02
M6
25/7/02
M3
T3
T6 T11
T1
4/8/02
M4
T9
25/8/02
M6
25/7/02
M3
T2
T7 25/7/02
M2
5/9/02 11/8/02 T5
M7 M8
4/7/02
Start
T6 T11 T7
T2
25/7/02
M2
5/9/02 11/8/02 T5
M7 M8
T4
18/7/02
M5
T10
T10
T4
19/9/02 T8
Kraj
18/7/02
M5
T10
T10 19/9/02
T8
Kraj
540
Prikaz plana
Gantogram je alternativni nain prikaza vremenskog rasporeda
Vidimo da su neke od aktivnosti oznaene i zasjenjenim linijama to pokazuje da postoji odreena fleksibilnost u datumu njihova zavravanja. Ako se aktivnost ne zavri na vrijeme kritini put nee biti ugroen sve do zavretka zasjenjene linije.
4 /7 1 1 /7 1 8 /7 2 5 /7 1 /8
S ta rt T4 T1 T2 M1 T7 T3 M5 May '05 Jul '05 Aug '05 Sep '05 Oct '05 Nov T 8 Jun '05 18 25 02 09 16 23 30 06 13 320 27 04 11 18 25 01 08 15 22 29 05 12 19 26 03 10 17 24 31 0 M M2 T6 T5 M4 T9 M7 T 10 2.5 w ks M6 T 11 M8 T 12 F in is h
Raspodjela zadataka
tapiasti dijagram takoer pokazuje razdoblje u kojima je osoblje angairano na projektu
Angaman ne mora biti kontinuiran osobe mogu raditi na drugim projektima, ii na odmor ili obavljati neke druge aktivnosti.
Zadaci T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Inenjer Anita Ana Anita Josip Jure Ana Igor Josip Anita Ana Josip Josip
8 /8 1 5 /8 2 2 /8 2 9 /8 5 /9 1 2 /9 1 9 /9
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Josip T4 T8 T11
T12
Anita T1
T3
T9 T6 T7 T5 T10
Ana T2 Igor Tea
541
542
Evidencija projekta
Planovi, upravljanje, praenje napretka, povijest projekta
Primjeri: \Upravljanje\* Drugi planovi ( Dokumentiranje)
Standard plana projekta
1. Introduction
1.1 Project Overview 1.2 Project Deliverables 1.3 Evolution of the Software Project Management Plan 1.4 Reference Materials 1.5 Definitions and Acronyms
IEEE Standard for Software Project Management Plans 10582. Project Organization 1998 2.1 Process Model 2.2 Organizational Structure Primjer, izvedenica
3. Managerial Process
Mogu se koristiti razliiti programski proizvodi, pr.

MS Project, CA Process Continuum, CASE pomagala za planiranje Primjeri: \Upravljanje\*
2.3 Organizational Boundaries and Interfaces 2.4 Project Responsibilities 3.1 Management Objectives and Priorities 3.2 Assumptions, Dependencies, and Constraints 3.3 Risk Management 3.4 Monitoring and Controlling Mechanisms 3.5 Staffing Plan
Dokumentiranje plana
Primjeri: \Dokumentacija
4. Technical Process
4.1 Methods, Tools, and Techniques 4.2 Software Documentation 4.3 Project Support Functions
5. Work Packages, Schedule, and Budget

5.1 Work Packages 5.2 Dependencies 5.3 Resource Requirements 5.4 Budget and Resource Allocation 5.5 Schedule
6. Additional Components 7. Index 8. Appendices

Pomagala za upravljanje projektima
545
546
Praenje napretka (izvrenja)

Upravljanje projektom podrazumijeva stalni nadzor napredovanja.
P1 prilagodba plana plan D1 projekta P2 praenje napredovanja
Elementi projektne evidencije

Projekt KratProjekt: NOT NULL NazProjekt: KratPartner: NOT NULL SifProjekt: OznVrProjekt: OpisProjekt: KratRacun: URLprojekt: JavnoProjekt: NOT NULL Aktivan: NOT NULL StatZadatak OznStatZadatak: NOT NULL NazStatZadatak: Aktivan: NOT NULL Zadatak RbrZadatak: KratProjekt: NazZadatak: NOT NULL VrstaZadatak: Nositelj: DatZadatak: RokZadatak: Prioritet: OznStatZadatak: DatStatZadatak: OpisZadatak: PlanPoc: PlanZav: StvarPoc: StvarZav: PlanTraj: StvarTraj: VrijZadatak: OznValuta: RbrDokument: LogAzur: DatAzur: Uloga KratUloga: NOT NULL NazUloga:
b Voditelj projekta
a lan ekipe
evidencija D2 radnih sati
Postavljanje projektnih ogranienja Napraviti poetnu procjenu projektnih parametara Definiranje kljunih toaka i izvjetavanje while projekt nije zavren ili otkazan loop Nacrtaj vremenski raspored projekta Podijeli aktivnosti prema vremenskom rasporedu ekaj Provjeri napredak projekta Revizija procijenjenih projektnih parametara Auriranje vremenskog rasporeda projekta Provjeri projektna ogranienja i izvjetaje If (poveanje problema) then Ponovni tehniki pregled i mogua revizija end if end loop
VrstaZadatka VrstaZadatak: NOT NULL Posao RbrPosao:
UlogaOsobe RbrUlogaOsobe: KratProjekt: NOT NULL Osoba: NOT NULL KratUloga: NOT NULL
Partner KratPartner: NOT NULL NazPartner: TipPartner: NOT NULL MBR: Email: URL: OpisPartner:
Osoba: NOT NULL DatPosao: NOT NULL KratProjekt: NOT NULL KratPosao: NOT NULL Sati: NOT NULL OpisPosao: RbrZadatak: CijenaSata: NOT NULL rbr_posao:
VrstaPosla KratPosao: NOT NULL NazPosao:
Osoba Osoba: NOT NULL OznStatOsoba: Password: Rodjen: Zanimanje: Zvanje: SifDjelatnika: SifZnanstvenika:
Pripadnost Osoba: NOT NULL KratPartner: NOT NULL
Zadatak
Izvritelji
Planirani poetak
Planirani zavretak
Prioritet Planirano Stvarno Status trajanje trajanje
% ispunjenja
Stvarni zavretak
Kanjenje Komentar
547
548
Nadzor napretka
Preporuke za planiranje poslova

Planiranje poslova
planovi moraju biti aurni, tj. prilagoeni stvarnom stanju izbjegavati detaljno planiranje poslova koji slijede u daljoj budunosti takve je dovoljno predvidjeti i najaviti, a panju usmjeriti na probleme koji se trenutno rjeavaju planovi trebaju to krai, kako se vrijeme ne bi troilo na detaljiziranje koje zbog mogue promjene stanja ionako nee biti istinito konkretno razdoblje za koje se radi plan moe varirati u ovisnosti o veliini projekta naelno je dovoljan jedan plan (i pregled realizacije) mjeseno, s tim da ukljuuje raspored tjednih aktivnosti poslove i zadatke treba uravnoteeno raspodijeliti vie panje treba posvetiti lanovima koji zaostaju u izvrenju plana ili rjeavaju sloeniji problem u odnosu na ostale lanove po potrebi treba prerasporediti postojee poslove
549
550
Kolaboracija
Komunikacija
verbalna: brzo sluaj i misli - sporo i jasno govori, biljei izreeno pisana: sadraj, forma (predloci), uestalost elektronika: E-mail, Chat, News obavjeivanje: pismenim putem, elektronikom potom (CC, BCC) pohrana informacija: mreno kazalo, FTP kazalo, web posluitelj organizacija kazala: Admin, Materijali, Projekt, Backup, Tmp, itd.
Pomagala za podrku grupnom radu
Druenja moraju biti uinkovita!

izbjegavati raspravu o opepoznatim ili nevanim stvarima treba ih prekinuti u trenutku kada se pretvore u razgovor o temama koje se ne odnose na posao
Sastanci moraju biti pripremljeni

mjesto, vrijeme, teme, sudionici
Tehnike za poboljanje rada

Brainstorming iznoenje ideja Izbjegavanje "jedinih" rjeenja traenje alternativa Biljeenje odluka zapisivanje da bi se izbjegla pogrena tumaenja Konstruktivne povratne informacije kritiziranje postupaka, a ne osoba Razumijevanje neuspjeha analiza i poboljanje svega to nije dobro Raspodjela moi i odgovornosti ravnopravnost, izbjegavanje hijerarhije
Preporuke verbalnu komunikaciju

Konzultacije i razmjena informacija
zajedniko dnevno druenje svih lanova ekipe dinamiko rjeavanje detalja konkretnih praktinih problema dnevno po 5 min., na poetku radnog dana ili prije/poslije pauze po potrebi se mogu sazvati i izvan dogovorenih termina
Upravljanje vremenom (time management)

pravilno rasporeivanje poslova:
tonom procjenom to i kada treba napraviti podjelom posla u pod-poslove izradom izvjea o napredovanju i gotovosti
izbjegavanje obavljanja tuih poslova

"mogu to i sam" "mogu to bre" "tee mi je objasniti, nego napraviti"
Sastanci
upoznavanje s trenutnim stanjem, realizacijom plana i daljnjim poslovima razmatranje problema, predlaganje naina i redoslijeda njihovog rjeavanja jednom tjedno po 15 min., unaprijed dogovorenog dana, najbolje na poetku tjedna jednom mjeseno po 1 sat, prvog radnog dana u mjesecu (npr. ponedjeljak) po potrebi se mogu sazvati i izvan dogovorenih termina poeljno je da se povremeno odre uz sudjelovanje nadreenih
neprimjeren utroak vremena (razbacivanje vremenom)

druenje telefonski razgovori, neproduktivna konverzacija zapoimanje problem "prebacivanja" s jednog posla na drugi ili "promjene brzine" pokuati s manje poslova i grupirati sline poslove ugodni poslovi izbjegavati produljenje rada na poslovima "za gut" neugodni poslovi izbjegavati odugovlaenje neugodnih ili tekih poslova
553
554
Raspodjela uspjeha
Kriteriji za procjenu doprinosa lanova
uloeni trud (vrijeme) rezultati rada (korisnost, kvaliteta proizvoda i zadovoljstvo korisnika) objektivna teina posla (vrsta, uvjeti, intenzitet i trajanje) pristup radu (zalaganje, samoinicijativa, kooperativnost, odgovornost) sposobnost (svestranost, samostalnost)
Neki kriteriji vrednovanja lanova
Stimuliranje, nagraivanje i trajno usavravanje

Pretplata na strune asopise, kupnja strunih knjiga. Sudjelovanje na prezentacijama informatike opreme i sajmovima, s ciljem praenja stanja i trendova IT. Moe se ukljuiti u sustav dodatnog nagraivanja. Sudjelovanje na strunim konferencijama, s ciljem praenja razvoja struke. Moe se uvjetovati pisanjem strunih radova vezanih uz konkretne razvojne probleme. Stimulacija kroz formalnu izobrazbu (dodiplomski, poslijediplomski studij) kao uvjet ostanka u tvrtki u odreenom razdoblju. Pohaanje strunih teajeva, prezentacija, radionica ili teajeva iz engleskog jezika.
JEZICI I POMAGALA
Jezici tree generacije

Jezici tree generacije (eng. 3rd generation languages - 3GL)
jezici visoke razine (HLL - High Level Languages) proceduralno usmjereni programski jezici podjela jezika po namjeni

Vienamjenski jezici
PL/I, prikladan za numeriko-inenjerske i poslovne aplikacije C, razvijen radi izrade operacijskog sustava iz kojeg je nastao Unix, danas predstavlja standard kada se radi o proceduralnom programiranju C++, C sa svojstvima objektnog programiranja Pascal, nastao s namjerom da se napravi jezik koji se moe efikasno ugraditi na veinu raunala, a koji e biti prikladan za uenje programiranja kao logike i sistematske discipline ADA, pokuaj postavljanja standarda za jezik integriranih raunalskih sustava (kontrola industrijskog pogona, zrakoplova ili bolnikih sustava za odravanje ivota) Modula-2 i Oberon, proirenje Pascala podrkom sistemskom programiranju, konceptom procesa i modula koji meusobno komuniciraju
Jezici za numerike i znanstvene probleme

FORTRAN (FORmula TRANslator), prvi raireniji jezik za rjeavanje numerikih problema ALGOL (ALGOrithmic Language), jezik prikladan za rjeavanje numerikih i logikih problema BASIC (Beginner's All-Purpose Symbolic Instruction Code), prvotno jednostavan interpretator za interaktivno rjeavanje numerikih problema, kasnije se razvio u Visual Basic
Jezici za poslovne probleme

COBOL (COmmon Business Oriented Language), jezik prikladan za poslovne aplikacije i rad s podatcima
Jezici orijentirani listama i nizovima

LISP (LISt Processing), nastao s namjerom da se naini programski jezik primjeren za probleme iz podruja umjetne inteligencije
Veina dananjih 3GL su vienamjenski jezici.
560
Jezici etvrte generacije

Jezici etvrte generacije (eng. 4th generation languages - 4GL)
nastali krajem '70 i poetkom '80 godina neki 4GL ini skup raznorodnih pomagala povezanih u cjelinu 4GE = okruenja 4. generacije (4th Generation Environment) 4GL naredbe integriraju naredbe jezika visoke razine 4GL = jezici vrlo visoke razine (Very High Level Languages)
Jezici etvrte generacije
Jezici posebne namjene

specijalizirani za odreene klase problema zadovoljavaju potrebe za izradu 60 - 80 % svih aplikacija
562
Vrste i primjena 4GL

Jezici za rad s bazama podataka
strukturirani upitni jezici (SQL - Structured Query Language) u prednjem planu SUBP (DBMS - DataBase Management System) jezik za opis podataka (DDL - Data Description Language) definiranje sheme BP u rjeniku podataka (kreiranje objekata) jezik za rukovanje podacima (DML - Data Manipulation Language) rad s podacima (postavljanje upita, unos, izmjena, brisanje) jezik za upravljanje podacima (DCL Data Control Language) kontrola pristupa podatcima (dodjeljivanje i ukidanje prava) 4GL kao programski jezik koristi se za pisanje aplikacija nad bazom podataka

Matrini kalkulatori (Spreadsheet)
tablica organizirana kao mrea redova i stupaca elementi tablice: konstante, izrazi (formule), grafiki znakovi i objekti elementi jezika aritmetike i agregatne funkcije: SUM, COUNT, AVERAGE, MIN, MAX logiki izrazi: OR, IF, AND, NOT matematike funkcije: SIN, COS,TAN, ASIN, EXP, SQRT, LN, LOG statistike funkcije (npr. oekivanje) i financijske funkcije (npr. kamatni raun) izraunavanje vrijednosti formula automatski slijedi promjenu podataka pr. D31=ROUND(SUM(D1:D30) * 0.65;-1)
Integrirana programska podrka (Integrated Software)

objedinjuje matrini kalkulator, obradu teksta i grafiki prikaz podataka pristup bazama podataka (postavljanje upita) kreiranje dijaloga primjena analiza, planiranje (financije, proizvodnja, prodaja) pomo pri donoenju odluka (problemi tipa "to ako")
Primjeri: DB2, Oracle, Informix, MS SQL Server, MS Access
563
564

Grafiki orijentirani jezici
raunarska grafika - sinteza slika pomou raunala (dijagrami, animacija, digitalizacija) CAD/CAM (Computer Aided Design / Computer Aided Manufacturing) raunalom podrano projektiranje / raunalom podrana proizvodnja simulatori, programski paketi za prijenos slika,

Programska proirenja operacijskih sustava (ljuske)
najraireniji pristup nadgradnje OS (pr. Unix) - nad istom jezgrom (kernel), mogu se koristiti razliite ljuske (shell) pr: Bourne shell, C shell, Mashey shell ljuska - tuma (interpreter) naredbi kreiranje liste argumenata prilikom poziva programa (ls *.c 1.c 2.c...) sposobnost testiranja rezultata prethodno izvrene naredbe (if test prog then..) slijedno izvoenje vie programa (cd dir; ls; cd .. ) obrada u pozadini (background processing) (prog &, jobs, fg) usmjeravanje ulaza i izlaza (prog > output.dat, prog < input.dat) ulanavanje naredbi na principu "cjevovoda" (cat | more) elementi programskog jezika prijenos i zamjena parametara (script prog arg1 arg2 $1=arg1 $2=arg2) supstitucija varijabli (set TERM=vt100, echo $TERM) naredbe za kontrolu programskog toka (while, if-then-else, case...) ostala programska proirenja OS temelje se na primjeni raunalne grafike podravaju rad s "prozorima", "ikone", izbornike...
Zemljopisni IS (GIS - Geographic Information System)

ukljuuju podatke o geometriji koncept vie slojeva koncept objekata
Programi i jezici za prijenos podataka

komunikacijski programi (modem, telefax, elektronika pota...) rad u mrei raunala (emulatori terminala, programi za prijenos podataka...)
Svojstva jezika etvrte generacije

Neproceduralna sintaksa
proceduralni jezici - niz naredbi koji odreuje KAKO se odreena akcija obavlja npr. "otvori datoteku, ako nije EOF pomakni se, ..., zatvori datoteku" neproceduralni jezici - niz naredbi koji odreuje TO treba uiniti npr. "dohvati podatke koji zadovoljavaju uvjet " Tipine neproceduralne naredbe naredbe za definiranje strukture podataka te rukovanje podacima u BP (nema potrebe za poznavanjem imena i lokacije datoteka, adresa...) naredbe za unos ili ispis podataka putem zaslonske maske (form) naredbe za izbor posla (menu) naredbe za izvjea (selekcija, grupiranje, sortiranje, agregatne funkcije...)

Primjer: Opisivanje podataka (SQL)
CREATE TABLE Osoba ( IdOsobe INTEGER NOT NULL, Prezime CHAR(20) NOT NULL, Ime CHAR(20), Adresa CHAR(20), SifMjesta SMALLINT, NOT NULL );
Primjer: Rukovanje podacima (selekcija u jeziku SQL)

SELECT * FROM Osoba, Mjesto WHERE Osoba.SifMjesta = Mjesto.SifMjesta AND Osoba.Prezime LIKE "K%"
Primjer: Definicija veze u rjeniku podataka (ZIM)

Stanuje := Osoba.SifMjesta = Mjesto.SifMjesta
Uz neproceduralne, mnogi 4GL raspolau proceduralnim naredbama da bi se omoguila ugradnja proceduralnih rjeenja.
Primjer: Rukovanje podacima (ZIM)

FIND ALL Osoba Stanuje Mjesto FIND ALL Osoba (UNRELATED) Stanuje Mjesto FIND ALL Osoba Stanuje Mjesto FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07. (COMPLETE)
568

Primjer: Izbornik (Informix-4GL)
MENU Osoba" COMMAND "Dohvat" "Postavljanje uvjeta za dohvat zapisa" CALL dohvat() IF status != NOTFOUND THEN NEXT OPTION "Sljedeci" END IF COMMAND "Sljedeci" "Dohvaanje sljedeeg zapisa" CALL sljed() ... COMMAND "Unos" "Unos novog zapisa" CALL unos() .... COMMAND "Kraj" "Kraj rada" EXIT MENU END MENU

Primjer: Rukovanje podacima putem zaslonske maske
DEFINE rOsoba RECORD LIKE Osoba DEFINE rMjesto RECORD LIKE Mjesto ... DISPLAY BY NAME rOsoba.* ... INPUT BY NAME rOsoba.* BEFORE FIELD SifMjesta MESSAGE "Unijeti ifru mjesta" AFTER FIELD SifMjesta CALL Sel_Mjesto (rOsoba.SifMjesta) RETURNING rMjesto.* IF status = NOTFOUND THEN MESSAGE "Ne postoji mjesto" NEXT FIELD SifMjesta END IF ... END INPUT
569
570

Primjer: Izbornik i maska za obradu podataka

Primjer: Izvjee (ZIM)
REPORT ALL FROM Osoba Stanuje Mjesto SORTED BY Osoba.Prezime, Osoba.Ime FORMAT ACROSS 2 PAGESIZE 23 PAUSE 1 PAGE HEADING "Stranica:" $PAGE : MASK 'ZZ9' : DETAIL LINE Osoba.Prezime : NEWLINE : Osoba.Ime Osoba.Adresa : NEWLINE : Mjesto.PostBr : NEWLINE : Mjesto.NazGrada ENDREPORT Stranica 1 Ford Alan Vukovar avenue 63 383260 New York Karson Kit Melrose place 666 282452 Los Angeles Ford Kit Sunset boulevard 2958
Rock Bob 383260 New York
571
572

Integracija naredbi i razina jezika
pojedina 4GL naredba zamjenjuje do nekoliko tisua onih 3GL-a krae programske liste, jezgrovitiji i itljiviji programski kod kodiranje s manje pogreaka, olakano otklanjanje pogreaka slinost strukturiranom govornom jeziku pojednostavnjenje izrade programske dokumentacije

Prenosivost (portabilnost) programske opreme
oslonac na standardne OS (MS-DOS/WINDOWS, UNIX...) koritenje vierazinskih prevodilaca (pr. 4GL-EC-C-O-4GE) upravljaki programi koji su nadgradnja OS (pr. SQLEXEC) manje dijalekata (npr. ANSI SQL standard)
Jednostavnost uporabe i rukovanja

jednostavna i razumljiva sintaksa, slinost govornom jeziku kvalitetno razvojno i korisniko suelje prikladnost za uenje i rukovanje (jezikom i podacima) moe se provjeriti tzv. dvodnevnim testom (TWO DAY TEST) veina korisnika bi morala moi nauiti osnove za 2-3 dana nakon toga korisnik bi morao moi samostalno obaviti neke manje poslove poeljno je da korisnik nakon manjih prekida u radu (npr. 10 dana) bude u mogunosti nastaviti s radom bez potekoa Ne vrijedi jednako za sve 4GL!
Uinkovitost kodiranja
izradi se pristupa u ranoj fazi razvoja (prototipski nain rada) bitno ubrzana izrada (neproceduralna sintaksa, generatori koda) poveanje uinkovitosti 6-60 puta (ne i skraenje vremena izrade!!!)
Uinkovitost uporabe raunala

poveanje uinkovitosti uslijed smanjenja broja naredbi i interne optimizacije ista aplikacija napisana u jeziku SQL moe na istom raunalu biti 5-20 puta bra od odgovarajue napisane u nekom 3GL kao to su COBOL ili FORTRAN prednost se gubi u sluajevima kad se radi o aplikacijama koje ukljuuju rjeenja proceduralnog tipa rjeenje: povezivanje na 3GL (npr. C)
CASE
CASE
eng. Computer Aided Software Engineering eng. Computer Aided System Engineering
CAISE
CASE pomagala
Computer Aided Information System Engineering
Raunalom podrano programsko/informacijsko inenjerstvo

uporaba alata koji podupiru neku od faza ivotnog ciklusa uporaba alata koji podupiru analizu zahtjeva i izradu specifikacija te uporaba alata koji potencijalno generiraju programski kd na temelju specifikacije programske opreme automatizacija programske opreme (Software Automation)
576
CASE pomagala
CASE pomagalo
programski sustav za pomo pri izgradnji IS i razvoju programske opreme
CASE pomagala
Gornji CASE (Upper CASE, Front-End CASE)
Automatizacija ili podrka ranih faza - planiranje, analiza i konceptualno oblikovanje koristi se za definiranje zahtjeva i izradu modela IS neki alati podupiru reinenjerstvo poslovnih procesa, analizu isplativosti IS, planiranje prioriteta i dinamike razvoja te potreba za raunalnom opremom raunalom podrano planiranje (Computer Aided Planning) analiza i dizajn, najee konceptualno i logiko oblikovanje oblikovanje baza podataka, prevoenje modela u 3NF generiranje sheme BP (SQL naredbe)
CASE pomagala podupiru (ne sva i ne uvijek!)

jednu ili vie metoda informacijskog/programskog inenjerstva samo njima svojstvenu ili neku od standardnih metodologija mogunost definiranja vlastite metodologije (meta-case)
Veina alata omoguuje izradu razliitih vrsta dijagrama kao to su

dijagrami dekompozicije funkcija/procesa dijagrami modela podataka, npr. entiteti-veze grafiki prikaz programske logike, npr. akcijski dijagram
esto se radi o skupu alata integriranih u cjelinu kojom se podupire:

jedna od faza ivotnog ciklusa (toolkit) ili cijeli ivotni ciklus (workbench)
Osnovne komponente
rjenik podataka (data dictionary), meta-baza (meta-base) ili riznica (repository) za pohranu modela suelje za izradu dijagrama i rukovanje meta-podacima posebni dijelovi koji vode brigu o usklaivanju promjena nainjenih na razliitim razinama ralambe modela ili u razliitim modelima.
CASE pomagala
Donji CASE (Lower CASE, Back-End CASE)
potpora kasnijim fazama razvoja: detaljni dizajn, konstrukcija, ugradnja, odravanje generatori programske opreme (application generator, code generator) alati za odravanje programske opreme (version control) i prepravke (reengineering) alati za izradu programske dokumentacije (documentation tool) alati za povratno inenjerstvo (reverse engineering), npr. analizatori izvornog koda, alati za restrukturiranje koda neki alati podupiru prototipni nain rada oblikovanjem zaslonskih maski i izvjea te simuliranjem rada programa, npr. ProtoGen, CASE za metodu vizualne izrade prototipa (visual prototyping method)
CASE pomagala
Integrirana CASE pomagala (ICASE - Integrated CASE)
cjeloviti CASE sustavi koji pokrivaju sve faze razvoja, a sadre i dodatne module za povratno inenjerstvo, nadzor i upravljanje izvedbom te osiguranje kakvoe IS potpuno integrirano CASE okruenje automatizira izradu modela organizacije, planiranje razvoja IS te izgradnju i primjenu IS integracija alata ostvaruje se usvajanjem pravila odreene metode razvoja, uporabom zajednikog rjenika podataka i zajednikog suelja te automatiziranim prosljeivanjem informacija iz jedne faze razvoja u drugu.
Smatra se da je samo 25-30% specifikacija prenosivo iz gornjeg u donji CASE, to predstavlja ozbiljnu prepreku potpuno automatiziranoj izradi programske opreme.
579
580
Generatori programske podrke

Programska oprema u osnovi podrazumijeva programski kd.
Aplikacija se takoer moe sastojati od korisnikog suelja i BP. Dobar generator mora biti u stanju proizvoditi sve dijelove PO.

Generatori se pojavljuju:
u okviru pomagala za projektiranje programske opreme kao dio jezika etvrte generacije kao zasebni proizvodi, koji integriraju svojstva 4GL i CASE pomagala namijenjenih oblikovanju
Velik broj pomagala proizvodi samo neke dijelove, kao to su:

zaslonske maske (screen painter, form generator) izbornici (menu generator) izvjea (report generator) programski kd (code generator) baza podataka, tj. naredbe za kreiranje baze podataka naredbe za grupnu (serijsku, batch) obradu podataka programska dokumentacija
Generatore se moe smatrati (donjim) CASE pomagalima.

Kao minimalne odrednice za procjenu pripadnosti ovoj grupi mogu se uzeti mogunost oblikovanja strukture podataka i oslonac na vlastiti rjenik podataka.
esto se generiraju srodne komponente:

generator suelja (standardno se radi o inteligentnom ureivau zaslonskih maski) obino ukljuuje generator izbornika i dijaloga generatori koji proizvode programski kd obino generiraju i ostale dijelove
Mogunost CASE pomagala da automatski generira izvorni kd na osnovu opisa sustava obrnuto razmjerna broju metoda i tehnika ugraenih u pomagalo.
Preporua se koristiti dobar gornji CASE za poetne faze razvoja, model prenijeti u rjenik podataka donjeg CASE alata, a zatim nastaviti s ostalim fazama.
581
582

Postojei generatori iskazuju nedostatke o kojima u velikoj mjeri ovisi mogunost i kvaliteta njihove primjene:
podsticanje izgradnje programskih sustava po dijelovima ad-hoc generiranje dijelova programske opreme koje vodi u neuravnoteenost ugraenih rjeenja nemogunost generiranja sloenih funkcija, to vodi runom kodiranju nesposobnost ouvanja runo ugraenih rjeenja prilikom ponovnog generiranja
Primjer I-CASE alata

Popkin System Architect ICASE koji podupire vie metodologija (SSAD, OOAD), reverzno inenjerstvo i generiranje koda
Preporuke
Nuno je odabrati alat koji generira izvorni kod i/ili dozvoljava rune zahvate. Poeljno je koristiti alat koji omoguuje upravljanu izmjenu generiranog koda i odravanje naknadno runo nainjenih izmjena Naalost, ovakvi proizvodi jo uvijek su rijetkost!
583
584
Primjer alata za oblikovanje BP

CA AllFusion ERwin dizajn i reinnjerstvo BP, razliite notacije (IDEF1X, IE, DM)
Primjer OO alata
Rational ROSE - potpora OO metodama (UML, OMT, Booch )
585
586
Integracija CASE alata u razvojnu okolinu

Visual Paradigm for UML
Svi UML dijagrami Analiza teksta CRC kartice
Reverzno inenjerstvo
Visual Paradigm for SDE (Smart Development Environment)

integracija s Visual Studio, Eclipse, JBuilder, reverzno inenjerstvo generiranje izvornog koda Community Edition
http://www.visual-paradigm.com
587
588
Generiranje izvornog koda
Primjeri meta-CASE alata

Playground ureiva dijagrama (objektni modeli, interakcije) MetaEdit razliiti dijagrami, definiranje vlastite notacije (metaCASE)
589
590
Praenje pogreaka i upravljanje promjenama

OnTime Defect and Feature Management System
http://www.axosoft.com/
Pomagalo za praenje rada aplikacije

Visual Logger
http://www.axtools.com/
591
592
Web adrese
Internet adrese openito
http://www.qucis.queensu.ca/Software-Engineering/tools.html http://www.pittarese.com/Auburn/cse625/case.htm
Podrka ivotnom ciklusu

http://www.visible.com/ http://www.popkin.com/ http://www.prolifics.com/do/panther.html http://www3.ca.com/Solutions/Solution.asp?ID=1629 http://www3.ca.com/Solutions/Product.asp?ID=258 http://www3.ca.com/Solutions/Product.asp?ID=256 http://www.magicsoftware.com/bin/en.jsp?enPage=HomePage
SAETAK NAELA IS
UML i alati
http://www.omg.org/uml/ http://www.intelinfo.com http://www.objecteering.com/ http://www.proxysource.com/ http://argouml.tigris.org/ http://www.sparxsystems.com.au/
Ukljuenost sudionika i ispravan pristup problemima

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

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

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

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

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

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

Podijeli pa vladaj
Svi su sustavi dijelovi veih sustava (nadsustava), Praktiki svi sustavi sadre manje sustave (podsustave), Sustav se podijeli u barem dva podsustava da bi se njime lake ovladalo i sagradilo vei sustav, Podjelom veeg problema (sustava) u manje dijelove (podsustave) kojima je lake upravljati, analitiaru se pojednostavnjuje postupak rjeavanja problema.
Reference
Awad A.M. (1985): System Analysis and Design, Irwin.
Avison, D.E. & Fitzgerald, G. (1998) Information Systems development: methodologies, techniques and tools. 2nd. ed. McGraw-Hill. Blum, B.I. (1994) A taxonomy of software development methods. Comm. of the ACM, vol. 37 (no. 11), 82-94. Boehm, B.W. (1983), Seven Basic Principles of Software Engineering, Journal of Systems & Software, 3(1) | March 1983, pp. 3-24. Brooks, F.P. (1975). The Mythical Man Month. AddisonWesley. Brooks, F.P. (1987) No silver bullet: essence and accidents of software engineering. Computer vol.20 (no 4), 10-19. Cameron, J.R., Campbell, A. & Ward, P.T. (1991) Comparing software development methods: example. Information and Software Technology, Vol 33 (no. 6) 386 - 402. IEEE Std 610.12-1990 "Standard Glossary of Software Engineering Terminology" in IEEE Software Engineering Standards Collection, 1994 Edition, IEEE, New York, 1994, p. 67. Harel, D. (1992) Biting the Silver Bullet: Toward Brighter Future for System Development, Computer, vol.25 (no.1), 8-20.
Projektirati sustav tako da prati rast i promjene

Mnogi analitiari upadnu u zamku izradivi sustav koji odgovara iskljuivo trenutnim zahtjevima, Entropijom se naziva prirodno i neizbjeno kvarenje bilo kojeg sustava, Kada tijekom faze podrke sustavu, trokovi odravanja premae trokove izgradnje novog sustava, sustav je zastario.
599
Reference
Hirscheim, R. and Klein, H.K. (1989) Four paradigms of information systems development, Comm. of the ACM Vol 32 (no. 10) 1199 - 1216. Hornby, P et al (1992) Human and organisational issues in information systems development Behaviour and Information Technology vol.11 (no. 3) 160-174. Maciaszek L. (2002): Requirements Analysis and System Design: Developing Information Systems with UML, 1/e, Addison Wesley Higher Education. McConnell S. (1998): Software Project Survival Guide Microsoft Press, ISBN: 1-57231-621-7. McLeod R., Jordan E. (2002). Systems Development: A Project Management Approach,ISBN: 0-471-22089-2, Wiley Higher Education Murch R. (200): Project Management: Best Practices for IT Professionals,1/e, Prentice Hall PTR, ISBN 0130219142 Pressman R.S. (2001): Software Engineering: A Practitioner's Approach, 5/e, McGraw-Hill, ISBN 0-07-249668-1 Sommerville, I. (2000). Software Engineering. Addison-Wesley Publishing Company. Whitten J. L., Bentley L. D., Dittman K. C. (2001): Systems Analysis & Design Methods, McGraw-Hill/Irwin; ISBN: 0072552360; 5th ed.

FER PIS Predavanja

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FER PIS Predavanja

Uploaded by

Copyright:

Available Formats

SVEUILITE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAUNARSTVA Zavod za primijenjeno raunarstvo

Laboratorijske vjebe Prof.dr.sc. Kreimir Fertalj Prof.dr.sc. Damir Kalpi

Projektiranje informacijskih sustava

Ukupna ocjena = f(modifikator)

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

Podatak, informacija i znanje

Podatak, informacija i znanje

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

Elementi i znaajke sustava

Izlaz Ulaz Podsustav Suelje Izlaz Granica sustava Okolina

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

Informacijski sustav podran raunalom

TEHN I KI (RA U NALOM POD R AN I) IS

Informacijski sustav podran raunalom

Upravljanje informacijama - Obavlja se bez obzira na vrstu sustava!

Poslovni i informacijski sustav

Vrste informacijskih sustava

Informacijski sustav transakcijski upravljaki za potporu odluivanju

Informacije, kada obrada podataka, dnevno zbirne, periodiki sintetizirane, ad hoc

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

Znaajke informacijskih sustava

Problem projektiranja, izrade i odravanja Vanost IS

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

Razvoj informacijskih sustava

Neki primjeri neuspjenih projekata/sustava

The CHAOS Report [Standish Group, 1994], http://www.standishgroup.com

Denver Airport (1994)

70% sustava u svijetu smatra se neuspjenim (system failure)

Standish Group, 2002:

Saetak naela razvoja informacijskih sustava

Inenjerski pristup izgradnji IS

Raunalna aplikacija (application)

Informacijska tehnologija (information technology, IT)

U potrazi za srebrnim metkom

Podruje programskog inenjerstva

Software Engineering Body of Knowledge

A Software Engineering Body of Knowledge, CMU/SEI-99-TR-004

Software Product Engineering

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

Body of Information Systems Knowledge

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

Projektiranje informacijskih sustava

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

Tehnike oblikovanja dijagramima

Izrada modela procesa/funkcija (process modelling, functional decomposition)

Izrada modela dogaaja

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

Kljune aktivnosti i sudionici

Sudionici, uvari uloga (stakeholders)

Formalna definicija [Whitten et. al, 2000]

Uloga sistem analitiara

ivotni ciklus razvoja

ivotni ciklus razvoja sustava

Svrha: planiranje, izvrenje i nadzor razvojnog projekta

ivotni ciklus i faze razvoja IS

Analiza (tko, to, kada, gdje)

Analiza zahtjeva, specifikacija zahtjeva

FER-ZPM-GRZ, Fertalj & Kalpi: Projektiranje informacijskih sustava, akad.god. 2006/07.

Novi razvojni ciklus

Primjer: IS LC Stages and Deliverables, DOE Software Development Methodology, http://cio.doe.gov/sqse

Primjer: Ciklus razvoja softvera