FER PIS Predavanja

Projektiranje informacijskih sustava

SVEUČILIŠTE U ZAGREBUFAKULTET ELEKTROTEHNIKE I

RAČUNARSTVAZavod za primijenjeno računarstvo

Prof.dr.sc. Krešimir FertaljProf.dr.sc. Damir Kalpić

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

Predmet

Nastavno opterećenje2 sata predavanja + 2 sata laboratorijskih vježbi tjedno

PredavanjaPohađanje predavanja nije uvjet za dobivanje potpisa

Laboratorijske vježbeProjektiranje mogućeg informacijskog sustava za izmišljenog korisnika.Rezultat je projektna dokumentacija, koja se predaje na pismenom ispitu.

IspitUsmenom ispitu mogu pristupiti studenti koji prikupe najmanje polovicu bodova za svaku od aktivnosti koje mu prethode.Pozitivna ocjena pristupa usmenom ispitu računa po sustavu bodovanja

Ukupna ocjena = f(modifikator)12.50%25Korak 2-550.00%100Nedovoljan

100.00%200Ukupno25.00%50510Pismeni ispit - zadaci60.00%120620Projektna dokumentacija15.00%30152Pohađanje predavanja

UdjelBodovaPutaPojedinačnoAktivnost


Materijali, informacije

Materijalihttp://www.zpm.fer.hr/courses/pis

• ažurirat će se nakon predavanja Vlastite bilješke

LiteraturaJ. A. Hoffer, J. F. George, J. S. Valacich: Modern Systems Analysis and Design, 3/e, Prentice Hall College Div, 2001J. L. Whitten, L. D. Bentley, K. C. Dittman: Systems Analysis & Design Methods, 5/e, McGraw-Hill Higher Education, 2000L. Maciaszek: Requirements Analysis and System Design: Developing InformationSystems with UML, 1/e, Addison Wesley Higher Education, 2002

KonzultacijeDoc.dr.sc. Krešimir Fertalj, Prof.dr.sc Damir KalpićZPM računarci, zgrada D/III kat, sjeverozapadno krilopoželjno uz najavu elektroničkom poštomobvezno s vlastitim bilješkama

E-mailTo: [email protected], [email protected]: PIS


Sadržaj

SadržajInformacijski sustav. Projektiranje i izgradnja informacijskih sustava.Životni ciklus i faze razvoja. Strategija i planiranje sustava.Prikupljanje i određivanje zahtjeva. Analiza. Oblikovanje funkcija. Oblikovanje procesa. Konceptualno oblikovanje podataka. Modeliranje događaja.Procjena alternativa izgradnje. Oblikovanje. Dizajn arhitekture sustava. Dizajn i ugađanje baze podataka. Oblikovanje programa i sučelja. Izrada sustava. Uvođenje u primjenu. Održavanje. Poduka i potpora. Modeli razvoja i metodologije. Moderni postupci.Organizacija projekta i upravljanje projektom.Programski alati i razvojna okruženja. CASE.

Informacijski sustav


Podatak, informacija i znanjeInformacija općenito

obavijest, podatak o nečemu, predana novost ili znanjeformalno, kolekcija simbola koji mogu imati određeno značenje

Podatak, informacija i znanjepodatak je sirova činjenica koja predstavlja neku istinu iz stvarnog svijeta

• pojedinačni podaci sami za sebe znače malo ili nemaju neko značenjeinformacija je interpretacija podatka - pročišćen, organiziran i obrađen podatak u smislenom kontekstu

• informacija je subjektivnog značenja, u kontekstu primateljaznanje se gradi na temelju novih informacija koje se nadovezuju na postojeće znanje

• isti podaci mogu biti različito interpretirani od strane različitih ljudi u ovisnosti o njihovom znanju

primjer:

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

-130000 ??? -130000 HRK ?

na računu ! broj 1313 (tj. Mojem) !!!


Sustav

Sustav općenito - sistem, poredakoblik društvene organizacije (npr. državni)skup dijelova, povezanih općom funkcijom (npr. živčani)skup jedinica, organizacijski ujedinjenih u cjelinu (npr. poduzeće)oblik, način ustrojstva, organizacija nečega (npr. izborni)uvjetovan planskim, pravilnim rasporedom dijelova (npr. sistem rada)

Komponente sustava jesu njegovi fizički dijelovi, ulazi i izlazi te procesi njihove pretvorbe i upravljački postupci (planiranje, organizacija, upravljanje i nadzor).

Sustav je uređeni poredak međuzavisnih komponenti povezanih prema zajedničkom planu za postizanje određenog cilja.


Elementi i značajke sustavaPodsustavi:

komponente koje pripadaju sustavuGranica:

definira opseg i domašaj sustavaOkolina:

sve što je izvan granica sustava, ali se još uvijek tiče sustava

Ulazi: elementi koji ulaze u sustav iz okoline

Izlazi: elementi koji napuštaju sustav

Sučelja: veze između sustava i njegove okoline (zaštita, filtri)

Ograničenja: unutarnji i vanjski čimbenici koji određuju i ograničavaju funkcioniranje sustava

Karakteristikeorganizacija – struktura i poredak, hijerarhijske veze koje određuju formalnu komunikaciju i upravljački lanac (pr. vojska, poduzeće)interakcija – način na koji pojedine komponente surađuju s drugim komponentama (pr. Nabava s Proizvodnjom, Proizvodnja s Prodajom)međuzavisnost – jedan podsustav ovisi o drugom (ulaz), da bi mogao funkcioniratiintegriranost – mjera povezanosti komponenti

Granica sustavaOkolina

PodsustavUlaz

Izlaz

Sučelje

Izlaz


Informacijski sustavInformacijski sustav (Information System)

obavijesni sustav, informacijski sistemsustav za upravljanje informacijama važnim za organizaciju i društvosustav za upravljanje sustavom ljudskih aktivnosti [Checkland, 1980]

Pojam IS podrazumijeva:sustave podržane računalom → računalni (“kompjuterizirani”, “kompjuterski”)sustave koji se ne oslanjaju na računala, ali obrađuju informacije

Svrhaprikupljanje i pružanje informacija korisnicima u jednoj ili više organizacija → organizacijski IS (poslovni IS)

Korisniciposlovodstvo, djelatnici (zaposlenici, osoblje), klijenti …

Upravljanje informacijama - Obavlja se bez obzira na vrstu sustava!prikupljanje (acquisition)zapisivanje, pamćenje (recording)obrada (processing)spremanje i pronalaženje (information storage and retrieval)prikaz u odgovarajućem obliku


Informacijski sustav podržan računalomTipovi (slojevi) informacijskih sustava

neformalni – složeni oblici ponašanja koji nisu formulirani, ali se od pridošlica u sustavu očekuje da ih usvojeformalni – eksplicitno utvrđena pravila ponašanja, a mogu biti propisana internim pravilima i zakonskom regulativomtehnički – opisuje organizaciju u terminima protoka poruka o aktivnostima i obradi podataka potrebnoj da se obavi posao

Informacijski sustav podržan računalomUređenje ljudi, podataka, procesa, sučelja, poveznica (mreža) i tehnologije koji djeluju međusobno sa svrhom podrške i poboljšanja svakodnevnih poslovnih aktivnosti (obrada podataka), kao i podrške rješavanju problema i donošenju odluka (informacijski servisi). [Whitten et. al, 2000]Komponente IS

• programska oprema (software) – sistemska, namjenska• računalna oprema (hardware) – računala i periferije, mrežna oprema• osobe (lifeware) - korisnici, informatičari• organizacija (orgware) – postupci povezivanja pojedinih dijelova u cjelinu

NEFORMALNI IS

FORMALNI IS

TEHNIČKI(RAČUNALOM PODRŽANI)

IS


Poslovni i informacijski sustavPoslovni 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

realizacijeskladišta: spremišta informacija (podataka)izvršitelji: osobe, strojevi, alatiskladišta: spremišta materijala

Informacijski sustavpodsustav poslovnog sustavaulazi i izlazi: ulazne informacije, obrađene informacijeprocesi: obrada informacija (podataka) o stanjima stvarnog sustavaizvršitelji: osobe, programi, računala

PrimjeriI(P)S: nabave, prodaje, proizvodnje, financija, ljudskih resursa i plaća, osnovnih sredstavaIS Subvencionirane Prehrane (ISSP)IS Visokih Učilišta (ISVU)IS Personalnog Upravljanja MORH


Vrste informacijskih sustava

Transaction Processing System (TPS), sinonim Data Processing System• evidencija i obrada podataka o poslovnim transakcijama

Management Information System (MIS) - upravljački• upravljanje temeljem dokazanih matematičkih/statističkih metoda

Decision Support System (DSS)• odlučivanje na temelju nestrukturiranih podataka iz različitih izvora• Executive Information System (EIS) – podvarijanta za izvršne

rukovoditeljeExpert System (ES) – sustav s ugrađenim znanjem i simulacijom zaključivanjaOAS: Office Automation SystemGSS: Group Support System, Groupware

Upravljanje i razine IS

Informacijski sustav

Informacije, kada

Korisnici, tko

Upravljanje

transakcijski obrada podataka, dnevno

niže poslovodstvo

operativno

upravljački zbirne, periodički

srednje poslovodstvo

taktičko (trendovi)

za potporu odlučivanju

sintetizirane, “ad hoc”

više poslovodstvo,

uprava

strategijsko (“što ako”,…)


Značajke informacijskih sustava

Značajke informacijskih sustavasložena okolina, koju je teško u potpunosti definirati složeno sučelje prema okolini, koje uključuje različite ulaze i izlazesložene veze između ulaza i izlaza (strukturno, algoritmički)obujam i složenost podataka

Problem projektiranja, izrade i održavanja

Važnost ISInformacija je postala upravljački resurs jednake važnosti kao što su vlasništvo (osnovna sredstva), ljudski resursi i kapital.

• IS sadrži/predstavlja znanje (know-how) organizacije koju podržava.• IS i aplikacije pokazuju se prijeko potrebnim za održanje konkurentnost

ili postizanje kompetitivnog prestiža organizacije.Organizacije u kojima se IS primjenjuju visoko su ovisne o stalnoj raspoloživosti IS kroz dulje vrijeme.

Projektiranje i izgradnja IS


Razvoj informacijskih sustavaCiljevi razvoja IS

izgraditi sustav koji radi i koji je pouzdan, unutar zadanih granicaizgraditi sustav koji zadovoljava poslovne ciljeve, prema zahtjevima korisnikaizgraditi sustav u prihvatljivom vremenu i po opravdanoj cijeni

Neki problemiprekoračenje planiranog vremena i financijskih sredstava neispunjenje zahtjeva ⇒neodgovarajući sustavnepouzdanost, nesigurnost, neelastičnost u primjeniteškoće u održavanju

70% sustava u svijetu smatra se neuspješnim (system failure)

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

Prosječni trošak projekta• velike kompanije: 2,32 M$• srednje kompanije 1.33 M$• male kompanije: 434 K$

Prosječno prekoračenje troškova 189%Prosječno prekoračenje rokova 222%Projekti završeni na vrijeme, u okviru predviđenih sredstava, sa svim predviđenim funkcijama - 16.2%Projekti završeni i u funkciji, ali uz veće troškove, dulje trajanje i/ili reduciranu funkcionalnost - 52.7%Prekinuti projekti - 31.1%

Standish Group, 2002: • 34% uspješnih projekata• 17% potpunih neuspjeha


Neki primjeri neuspješnih projekata/sustava

London Ambulance System (1992)Nakon uvođenja sustav se 2 puta "raspao" radi niza pogrešaka, naročito onih zbog upravljanja. Neposredni trošak bio je relativno nizak (£9m), ali se vjeruje da su neki ljudi umrli jer se do njih nije stiglo na vrijeme.

Taurus (1993)Projekt sustava automatiziranih transakcija Londonske burze prekinut je nakon 5 godina razvoja i troška od £75m te posljedični gubitak klijenata od £450m. Ukupni gubici smatra se da su neizračunljivi.

Denver Airport (1994)Nepouzdanost softvera za upravljanje prtljagom uzrokovala je odgodu otvaranja zračne luke u trajanju od 16 mjeseci uz troškove od 1.1 M$/dan.

Ariane 5 (1996)Eksplodirala u lanseru radi niza softverskih pogrešaka

Drugi primjeriChallenger - niz pogrešaka u dizajnuTeleskop Hubble - pogreške u dizajnu, propusti u testiranjuMars Climate Orbiter - problem navigacije zbog raskoraka između engleskog i metričkog mjernog sustava


Uzroci neuspjehaRazlozi neuspješnih projekata

složenost aplikacijanedostatak usmjerenosti korisnikuzanemarivanje okruženja organizacijepretjerani optimizamizostanak praćenja napretkanedostatak komunikacije između korisnika i izvođača

U Hrvatskoj se uzroci neuspjeha uglavnom ne istražuju, a informacije o neuspješnim projektima nerado se objavljuju. Među najčešćim uzrocima su [Kalpić, Fertalj & Mornar, 2001]

Loša organizacija i vođenje projekata • oslonac na vanjske voditelje i savjetnike, delegirano upravljanje projektima,

nerealno planiranje, formalno izvještavanje o napretku, formalni nadzor nad projektom, podcijenjena uloga vlastitih stručnjaka

Loša izvedba projekata • neodgovarajuća analiza sustava, pogreške u dizajnu i kontroli kvalitete,

neodgovarajuća CASE pomagala i krivo korištenje, pa čak i svojevrsna zloporaba CASE pomagala

Mnogi sustavi su propali ili su bili odbačeni jer su se izvođači trudili napraviti lijepa programska rješenja a nisu razumjeli suštinu organizacije i poslovanja.


Poboljšanje uspješnosti IS

Poboljšanje uspješnosti ISProjektiranje ISPlaniranje, upravljanje provedbom, praćenje napretkaUključivanje korisnika• Korisnik poznaje(?) poslovni proces i zna(?) odrediti potrebe.• Informatičar upoznaje(?) poslovanje i zna(?) kako izraditi IS.• Važno je da u procesu izgradnje sudjeluje i poslovodstvo, da bi se

upoznalo sa stvarnim mogućnostima i koristima uvođenja IS, posebice jer donosi konačne (za poduzeće sudbonosne) odluke.

Sažetak načela razvoja informacijskih sustavaKorisnici i vlasnici sustava moraju biti aktivno uključeniTreba koristiti pristup koji vodi k rješavanju problemaUspostaviti faze i aktivnostiUspostaviti standarde za konzistentan razvoj i dokumentiranjeOpravdati izgradnju sustava kao kapitalnu investicijuNe oklijevati ako treba projekt otkazati

Inženjerski pristup izgradnji IS


Programsko inženjerstvoProgramska oprema (software)

• programska podrška, naputbina• dio računalnog sustava koji nema fizikalnih dimenzija• opći pojam za sve vrste programa, programskih jezika itd

računalni programi, podaci, dokumentacijasvojstva:

• složenost, podložnost pogreškama,• ne troši se, teško se mjeri,• stari, dugo se koristi,• lako se kopira (zajedno s pogreškama)

Računalna aplikacija (application)namjenski program, primjenska programska opremaračunalom podržano rješenje jednog ili više poslovnih problema ili potreba

• informacijski sustav uobičajeno sadrži jednu ili više računalnih aplikacija

Informacijska tehnologija (information technology, IT)bilo koji oblik tehnologije, tj. oprema ili tehnika koju ljudi koriste za upravljanje informacijama (obavijestima)u današnje vrijeme obuhvaća računalsku tehnologiju (hardver i softver) i telekomunikacijsku tehnologiju (mreže za prijenos podataka, slika i zvuka)


Programsko inženjerstvoProgramsko inženjerstvo (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.orgProgramsko inženjerstvo je inženjerska disciplina koja obuhvaća sve aspekte izrade programske opreme. [Sommerville, 2000]Programsko inženjerstvo je inženjerska disciplina koja se bavi praktičnim problemima razvoja velikih programskih sustava [Sommerville 1992, 4. ur., str. v]„Programsko inženjerstvo... ima za cilj ekonomičan razvoj visokokvalitetne programske opreme“ [Pagel / Six 1994, str. 49]

Područje programskog inženjerstvaposlovi kojima se oblikuje i razvija programska opremasustavna primjena prikladnih alata i tehnika na čitav proces razvoja programskeopremesastoji se od analiziranja i pobližeg opisivanja (specifikacije) postupka koji treba programirati, izrade programa, tehnika testiranja (provjere valjanosti), pisanja dokumentacije, pokusnih izvedbi programa, analize vremenskog izvođenja itd.


U potrazi za srebrnim metkom

Postupci (metode) programskog inženjerstva1968: Prva NATO konferencija o programskom inženjerstvu, posvećena problemima razvoja programske podrške (“softverske krize”)kraj '60-ih, rane ’70-te: Strukturirano programiranje - disciplinirano programiranje temeljeno na prikladnoj sintaksi proceduralnih jezikasredinom ’70-ih: Strukturirani dizajn - izrada hijerarhijskih sustava modularne programske opreme, računalom podržana dokumentacijakasne ’70-te, rane '80-te: Strukturirana analiza - odvajanje logičkog opisa od fizičkog opisa (informacijskog) sustava, Oblikovanje podatakarane '80-te: CASE alati; prototipiranjesredinom '80-te: Informacijsko inženjerstvo, združeni razvoj aplikacija (JointApplication Development)kasne '80-te: Brzi razvoj aplikacija (Rapid Application Development)rane ‘90-te: Objektno usmjereni razvojkasne ‘90-te ...: ?

Brooks, F.P. (1987) No silver bullet: essence and accidents of software engineering. Computer, 20 (4), 10-19.

teškoće su sastavni dio softvera (složenost, promjenjivost, nevidljivost...)neprilike/nezgode postoje, ali nisu sastavni dio, tj. nisu neizbježne


Software Engineering Body of Knowledge

SWEBOK: Software Engineering Body of Knowledge

IEEE Computer Society, 2001http://www.swebok.org/

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

Carnegie Mellon University/Software Engineering Institutehttp://www.sei.cmu.edu/sei-home.html

Computing Fundamentals1.1 Algorithms and Data Structures1.2 Computer Architecture1.3 Mathematical Foundations1.4 Operating Systems1.5 Programming Languages

Software Product Engineering2.1 Software Requirements Engineering2.2 Software Design2.3 Software Coding2.4 Software Testing2.5 Software Operation and Maintenance

Software Management3.1 Software Project Management3.2 Software Risk Management3.3 Software Quality Management3.4 Software Configuration Management3.5 Software Process Management3.6 Software Acquisition


Informacijsko inženjerstvo

Informacijsko inženjerstvo (information engineering, IE)Inženjerski 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 podržan računalom

Sustavna primjena prikladnog skupa metoda, tehnika i alata u procesu razvoja informacijskih sustava.

Metoda (method)Smišljen i organiziran skup procedura izrade (modela, softvera), uz korištenje dobro definirane notacije

• sugerira proces obavljanja i način bilježenja• definira primjenu tehnika i njihovo povezivanje (pr. ERD-DFD)

Tehnika (technique)“Feature” metode, koji definira način provođenja određenog postupka i dokumentiranja rezultata tog postupkaNačin na koji se provodi određena aktivnost razvojnog procesa.

Pomagalo (tool)instrument, sredstvo (artefact) koje se koristi u razvoju IS


Body of Information Systems KnowledgeIS 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 Knowledgehttp://www.aisnet.org/Curriculum/

1.0 Information Technology1.1 Computer Architectures1.2 Algorithms and Data Structures1.3 Programming Languages1.4 Operating Systems1.5 Telecommunications1.6 Database1.7 Artificial Intelligence

2.0 Organizational and Management Concepts2.1 General Organization Theory2.2 Information Systems Management2.3 Decision Theory2.4 Organizational Behavior2.7 Managing the Process of Change2.8 Legal and Ethical Aspects of IS2.9 Professionalism2.10 Interpersonal Skills

3.0 Theory and Development of Systems3.1 Systems and Information Concepts3.2 Approaches to Systems Development3.3 Systems Development Concepts and

Methodologies3.4 Systems Development Tools and

Techniques3.5 Application Planning3.6 Risk Management3.7 Project Management3.8 Information and Business Analysis3.9 Information Systems Design3.10 Systems Implementation and Testing

Strategies3.11 Systems Operation and Maintenance3.12 Systems Development for Specific

Types of Information Systems


Sistemsko inženjerstvoNema općeprihvaćene 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 whatis expected to be most efficient possible manner, with each component of systemdesigned to function as part of a single entity”

SažetoSagledava sustav kao cjelinu pristupom s vrha prema dolje (top-down)Upravlja ciklusom koji sadržava sve faze od dizajna do umirovljenjaOsigurava djelotvornost i (dovoljno) rano donošenje odluka definiranjem zahtjeva i njihovim povezivanjem s odgovarajućim oblikovanjemInterdisciplinarni i/ili timski pristup oblikovanju i razvoju kojim se osigurava njihova djelotvornost i učinkovitost

Projektiranje informacijskih sustava


Projektiranje IS

Slijed izrade fizičkog i logičkog modela postojećeg IS, a zatim logičkog i fizičkog modela budućeg IS na temelju poslovnih zahtjeva i zahtjeva krajnjih korisnika.

fizički model (ugradbeni, implementacijski, tehnički) – opisuje kako je sustav fizički i tehnički ugrađen, te tko, gdje i kada nešto radilogički model (esencijalni, konceptualni, poslovni) – što je sustav, što radi, što su podacioperativni (budući fizički) sustav – što, tko i kada, ali ne i gdjeopcionalno, može se razmatrati organizacijska razina – različito značenje podataka zavisno od područja unutar organizacije i okoliša


Modeliranje

Izrada modela koji odgovaraju dijelovima stvarnog sustavamodel: apstrakcija ili reprezentacija dijela stvarnog svijetaKada otprije ne postoji sustav, potrebno je odrediti "surogat" postojećeg sustava po ugledu na istovrsne sustave u drugim organizacijama ili razvoj započeti s izradom logičkog modela.

Tehnike oblikovanja dijagramima Izradom modela nastoji se opisati situacija u kojoj:

• događaj iz vanjskog svijeta pokreće (okida) proces• proces ima određeni učinak na podatke u nekom stanju• obavljanjem procesa podaci prelaze u novo stanje.


Vrste modelaIzrada modela podataka / oblikovanje podataka (data modelling)

model podataka – ŠTO su podaci, odnosno što opisuju podaci • konceptualni model - opisuje podatke i veze između podataka, najčešće model

entiteti-veze (entity-relationship model)• logički model – opisuje strukturu podataka i logičkih datoteka, najčešće relacijski

model podataka (relational data model)Izrada modela procesa/funkcija (process modelling, functionaldecomposition)

model funkcija i procesa – KAKO se prikupljaju, obrađuju i distribuiraju podaci• model funkcija - oblikuje se razlaganjem (dekompozicijom) funkcija, iterativno od

vrha prema dolje (od globalnih funkcija do osnovnih procesa)• model procesa – opisuje obradu podataka promatranog sustava, najčešće

dijagram toka podataka (data-flow diagram)Izrada modela događaja

model događaja – KADA se podaci obrađuju• razmatranje učinka koji događaji imaju na procese i podatke te opis stanja, npr.

dijagram promjene stanja (state transition diagram)Modeliranje resursa/sredstava

izvršitelji - TKO obrađuje podatke, GDJE se nalaze podaci, GDJE se obrađuju podaciModeliranje programa

struktura (programskih) modula IS, primjerice strukturnim kartama


Ključne aktivnosti i sudioniciKljučne aktivnosti # u nekim metodama zajedno se zovu informacijsko inženjerstvo

Sistemska analiza, Analiza sustava (Systems analysis) • proučavanje poslovanja s ciljem preporuke poboljšanja i specificiranja zahtjeva na rješenje

Sistemski dizajn, Dizajn sustava (Systems design)• specifikacija ili konstrukcija računalom podržanog rješenja identificiranih poslovnih zahtjeva

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

• Vlasnik sustava – naručitelj (ovisno o vlasništvu: stvarni vlasnik ili predsjednik uprave)– naručuje i plaća razvoj i održavanje sustava, postavlja prioritete i određuje politiku njegovog korištenja

Projektant, Dizajner sustava (Designer)• tehnički stručnjak koji oblikuje sustav tako da zadovolji zahtjeve korisnika

– prevodi poslovne zahtjeve i ograničenja u tehničko rješenje– oblikuje datoteke, baze podataka, ulaze, izlaze, zaslone, mrežu i programe, integrira rješenje

• može biti i graditelj sustavaGraditelj sustava (Builder, Developer) - programer, razvojnik

• stručnjak koji izgrađuje sustav, provjerava njegovu ispravnost te ga isporučuje u primjenu– konstruira komponente sustava na temelju specifikacija koje rade dizajneri sustava


Sistem analitičarSistem analitičari razumiju i poslovanje i računarstvo

Provode sistemsku analizu i dizajnPovezuju one koji trebaju računalo i one koji poznaju IT

Formalna definicija [Whitten et. al, 2000]Sistem analitičar potpomaže proučavanje problema i potreba poslovanja radi određivanja kako poslovni sustav i informacijska tehnologija mogu najbolje riješiti problem i postići unaprjeđenje poslovanja. Plodovi ove aktivnosti mogu biti poboljšani poslovni procesi, poboljšani informacijski sustavi te nove ili poboljšane aplikacije, a često sve zajedno.

Uloga sistem analitičaraIstražitelj, arhitekt i nadzornikRješavatelj poslovnih problemaZagovaratelj promjenaPsiholog, trgovac, političar ...

Većina sistem analitičara koristi neku inačicu pristupa koji se naziva životni ciklus razvoja sustava sistematičan i metodičan pristup rješavanju problema sustava.

Životni ciklus razvoja sustava

Systems Development Life-Cycle (SDLC)


Ž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 način razvoja ISSvrha: planiranje, izvršenje i nadzor razvojnog projekta

životni ciklus definira faze i zadatke (aktivnosti) koje nužno treba obaviti tijekom razvoja bez obzira na veličinu sustava koji se gradisvaka pojedina aktivnost proizvodi skup rezultataciklus sigurava “kontrolne točke” za praćenje napretka, procjenu postignutih rezultata i donošenje odluka o daljnjim koracimaprojekt 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

Analiza

Oblikovanje

Izrada

Primjena,održavanje

Specifikacija zahtjeva

Funkcionalni sustavSpecifikacija sustava

PlaniranjePlan sustava

Pregled

Operabilnisustav

Potrebe (popravci,dorade, prerade, nadogradnje)

Planiranje (zašto)Zašto graditi sustav?

Analiza (tko, što, kada, gdje)Tko koristi sustav?Što mora raditi?Gdje i kada će se sustav koristiti?

Oblikovanje (kako)Kako će sustav raditi?

Izrada (+isporuka)ugradnja rješenja

Primjenaodržavanje i poboljšavanje

sistemskoinženjerstvo


Faze razvojaPlaniranje, strategija

Snimka stanja, Inicijalna strategija (initial strategy):• određivanje poslovnih ciljeva, identificiranje problema i ideja njihovog rješavanja

te određivanje zahtjeva za sustavStudija izvodljivosti (feasibility study):

• pregledna analiza problemskog područja i određivanje (granica) projekataPlaniranje projekta:

• Izrada plana rada, kadroviranje projekta, upravljanje i nadzor projektaPoslovni cilj i projekti, plan sustava, plan informatizacije (glavni projekt)

Analiza zahtjeva, specifikacija zahtjevaAnaliza zahtjeva (requirements analysis): detaljna analiza kojom se preciziraju granice projekta i poslovni zahtjevi

• detaljna analiza postojećeg sustava (problema i poslovnih zahtjeva)• modeliranje (postojećeg) sustava

Specifikacija zahtjeva (requirements specification): detaljni opis zahtjeva na IS, oblikovan tako da ga razumiju dizajneri

• modeliranje (budućeg) sustava• definiranje zahtjeva na budući IS

Poslovni model sustava, prijedlog sustava


Faze razvoja

OblikovanjeDizajn sustava (system design): modeliranje IS (pogled projektanta)

• donošenje odluke o tome kako graditi sustav • dizajn rješenja po potrebi (ima rješenja koja ne treba dizajnirati)• izrada zahtjeva kojima se opisuje kako izgraditi sustav

Detaljni dizajn (detailed design): razrada rješenja, izrada tehnološkog modela IS (pogled izvođača)

• dizajn arhitekture, sučelja, pohrane podataka i programaTehnička specifikacija sustava

Izrada, provedba• ugradnja oblikovanih rješenja

Izrada (implementation), konstrukcija: ugradnja baze podataka, kodiranje procesa (funkcija) novog IS, nakon odabira platformeTestiranje (testing): provjera komponentiIntegracija i provjera sustava (system integration, evaluation): udruživanje 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 tehnološki opis sustava


Faze razvoja

Uvođenje i održavanje• analiza ugrađenog rješenja, poboljšanje dizajna, ugradnja poboljšanja

Uvođenje u primjenu, primjena (operation, production): prijelaz radnih aktivnosti i prijenos (konverzija) podataka sa starog na novi sustavOdržavanje (maintenance): izmjene sustava radi poboljšanja radnih karakteristika (performanci), poboljšanja ili prilagodbe načina uporabePotpora (support): dobavljača opreme, tehničkog osoblja korisnicima Informacijski sustav u primjeni, plan održavanja

Novi razvojni ciklus Pregled (review): revizija, preispitivanje čitavog sustava kada su potrebne veće izmjene uslijed promjena u poslovanju ili promjena poslovnih ciljevaNovi projekti

Navedene su tipične 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

Viđenje studen(a)ta

Proučavanje problema(dan 1)

Kodiranje(dani 1 ...

n - 2)

Debugiranje(dan n - 1)

Dokumentiranje(dan n - ε)

Isporuka(dan n)

Prilagodba prema Modesitt, LNCS 750, pp. 42

Zaprimanje zadatka

(dan 1–n)

Strategija i planiranje


Strateško planiranjeStrateško planiranje

Definiranje poslovne strategije, planiranje akcija za postizanje cilja• Uprava definira viziju i misiju organizacije, tj. strateške ciljeve.

– http://www.fer.hr (Sustainable excellence - in education and research)– http://www.zaba.hr (O nama)– http://www.lura.hr (O nama)

Na temelju toga definiraju se poslovni ciljevi i određeniji zadaci kojima će organizacija u nekom razdoblju ispuniti svoju misiju.

• što se želi postići: prepoznatljivost, kvaliteta, prihodi, ...• kako to postići: promjenom organizacije, poboljšanjem sustava administracije, ...

– povećanje proizvodnosti ulaganjem u nove proizvodne tehnologije uz istovremeno održavanje kakvoće proizvoda

– osiguranje zadovoljstva i radnih sposobnosti zaposlenika doškolovanjem i mogućnostima napredovanja

Čimbenici koji utječu na postavljanje ciljevaograničenja (organizacijska, financijska, zakonska, …)potrebe i želje uprave, poslovodstva, zaposlenika (ugled, utjecaj, …)vremenski okviri, razdoblje [Awad, 1985]:

• kratkoročno, obično manje od 2 godine• srednjeročno, 2-5 godina• dugoročno, više od 5 godina


Planiranje IS

Planiranje informacijskog sustavaTraženje odgovora na pitanja:

• Čime se organizacija bavi (grana, proizvodi, tržište, konkurencija)?• Koji su problemi, zadaće i ciljevi poslovnog sustava?• Koja je željena uloga IS u postizanju postavljenih ciljeva?• Koje aplikacije postoje, čemu i kako služe, koje i kakve podatke sadrže?• Postoje li aplikacije čiji je razvoj u tijeku? U kojem su stadiju razvojni projekti?• Koje su potrebne aplikacije?• Koji su raspoloživi resursi (osoblje, tehnička sredstva, tehnologija, …)?

Razlozi zbog kojih treba planirati ISNa primjer, u Organizaciji koja se sastoji od više cjelina, kao što su Uprava, Financije, Proizvodnja i Informatika često postoji više različitih tehničkih sustava ili aplikacija (takozvanih informatičkih otoka) koji imaju za posljedicu:

• umnožavanje informacija uz različito tumačenje u različitim dijelovima• nepotpunost informacija, naročito kada svaka cjelina prikuplja samo njemu važne

informacije• problem povezivanja informacija pri pokušaju cjelovite interpretacije• problem različitog posluživanja, razmjene podataka i održavanja


Strateško planiranje IS

Tradicionalno planiranje ISprovodi se odvojeno od poslovnog planiranja iliprovodi se kao reakcija na promjene u poslovnoj politici

Strateško planiranje ISuspostava smjera i prioriteta usklađivanja informacijskih servisa sukladno misiji, viziji i ciljevima organizacijeplaniranje IS sukladno strategiji razvoja organizacije, tako da informatizacija bude potpora promjeni organizacije i poslovnih procesaprimjena metoda analize i dizajna na istraživanje poslovnog sustava s ciljem definiranja općeg (sveobuhvatnog) plana i arhitekture IS čiji razvoj slijedi

Strateško planiranje IS prikladno je za stabilne organizacije. U praksi je teško provedivo u uvjetima “preživljavanja”.

A zapravo u praksi ...Umjesto prema strateškom planu, organizacija se "dovodi u red" tijekominformatizacije i s pomoću informatizacije.Analizom sustava evidentiraju se problemi i slabosti poslovnih procesa.Dizajnom sustava predlažu se ili nameću poboljšanja.


Okosnica plana razvoja sustava

R.McLeod, E.Jordan (2002). Systems Development: A Project Management Approach,ISBN: 0-471-22089-2, Wiley Higher Education

Enterprisemodel

Enterprisedata model

Enterprise modeling

Strategic businessplanning

Strategic informationplanning

P

A

D

C

User review

P

A

D

C

User review

P

A

D

C

User review


Odabir i pokretanje projekataPokretači promjena

korisnici - nezadovoljstvo aplikacijama i/ili podacima (nepouzdanost, nedostupnost, manjkavost)

• npr. nestabilnost aplikacija, podaci koji nedostaju, potreba za novim funkcijamareorganizacija – promjene organizacijske strukture, promjene poslovnih procesa

• npr. promjene na Sveučilištu uzrokovane novim zakonompokazatelji poslovanja

• npr. pad prodaje, uska grla proizvodnje, neplanirano i nejasno povećanje troškovazastarjela tehnologija

• npr. razvojni alati (problem održavanja), sučelja (Internet), baze podatakaOdabir projekta (project selection) – natječaji i prijedlozi rješenja

sponzor projekta (organizator, predlagatelj) sastavlja prijedlog projekta (project proposal)

• sažetak projekta (naziv, cilj, svrha)• poslovne potrebe• očekivana funkcionalnost• očekivana korist• posebnosti i ograničenja

povjerenstvo za odabir (steering committee, approval comitee) odobrava projektePrimjeri: \Planiranje

natječaj: Obrazac za prijavu projekta primjene IT (MZT)interno: Zahtjev za uslugama informacijskog sustava


Pokretanje projekata (project initiation)

Snimka stanja, početno istraživanje (survey phase, initial study, preliminary investigation)

prethodno istraživanje, tj. istraživanje koje prethodi projektuprepoznavanje problema i potrebatraženje odgovora na pitanje "Da li je projekt vrijedan pažnje?"

Faza proučavanja problema (study phase) produbljenje snimkepostavljanje ciljeva, prijedlozi rješenja, procjena izvodljivosti "Da li su problemi vrijedni rješavanja?“, "Da li je gradnja isplativa?"

Planiranje projekta ( Organizacija i upravljanje projektom)Izrada plana radaUstroj projektne ekipe

• uključivanje sudionika iz različitih djelatnosti, npr. djelatnici različitih poslovnih područja ili organizacijskih jedinica, uprava, vanjski konzultanti

• važno je osigurati predanost sudionika zajedničkom cilju (commitment)Uspostava upravljanja i nadzora projekta


Snimka stanjaSnimka stanja

brzo istraživanje i evaluacija problema, mogućih prilika i direktiva• problem: neželjena situacija koja sprječava potpuno ispunjenje svrhe, postizanje

ciljeva, obavljanje zadaća• moguća prilika: mogućnost pozitivne promjene, čak i kada ne postoji problem• direktiva: zahtjev ili ograničenje nametnuti poslovnom politikom (npr. pravilnik) ili

vanjskim utjecajem (npr. zakon)opcionalno se provodi procjena mogućih tehničkih rješenja, pri čemu treba imati na umu da to treba biti detaljnije provedeno u kasnijim fazamaodređivanje dosega projekta i početnog plana projekta

Snimka poslovnog sustavapregled poslovnih planova, ako takvi postoje ili nisu “tajna”prikupljanje informacija, najčešće intervjuiranjem vlasnika i viših rukovoditeljaevidentiranje problema i prijedloga

Snimka stanja postojećeg (postojećih) ISidentifikacija korisnika i opsega postojećeg IS uočavanje problema i nedostataka postojećeg ISprocjena potreba za nadgradnjom (poboljšanjima)procjena potreba za izmjenama (prilagodbom i popravcima)procjena potreba za izradom novih IS ili podsustava IS


Primjer: postojeći problemi, prijedlozi rješenjaKratko obrazloženje problema, mogućnosti ili direktive Hitnost Vidljivost Korist Prioritet Predloženo rjesenje

1. Vrijeme odgovora na narudžbu mjereno od vremena zaprimanja narudžbe do isporuke klijentu se povećalo na prosječno 15 dana

HITNO Visoka 175,000 2 Novi razvoj

2. Nedavno preuzimanje kompanija: Privantna predstava i Filmsko platno nametnulo je povećanje zahtjeva za protokom informacija i dokumenata.

6 mjeseci

Srednja 75,000 2 Novi razvoj

3. Trenutno 3 različita sustava za unos narudžbi servisiraju odjele za audio, video i video igre. Svaki sustav ima vlastito sučelje prema različitom skladišnom sustavu, pa treba objediniti skladišnu evidenciju.

6 mjeseci

Srednja 515,000 2 Novi razvoj

4. Postoji nedostatak pristupa informacijama nužnim za upravljanje i donošenje odluka. Ovo ce se jos pogoršati preuzimanjem dva dodatna sustava za obradu narudžbi (iz Privatna predstava i Filmsko platno).

12 mjeseci

Niska 15,000 3 Po razvitku novog sustava, pružiti korisnicima lako svladive alate za pisanje izvještaja.

5. Izražena je nedosljednost (nekonzistentnost) između podataka u evedencijama članova i narudžbi.

3 mjeseca

Visoka 35,000 1 Brza ispravka, a zatim novi razvoj

6. Sustavi datoteka u Privatna predstava i Filmsko platno nisu kompatibilni s onim u Zvučna pozornica. Problemi s podacima obuhvaćaju nedosljednosti u podacima i nedostatak upravljanja ulazom i izmjenama.

6 mjeseci

Srednja nepoznato 2 Novi razvoj, dodatna ocjena koristi moze povećati žurnost

7. Postoji mogućnost uvođenja sustava naručivanja putem Interneta, ali su sigurnost i kontrola pristupa problematični.

12 mjeseci

Niska nepoznato 4 Buduće verzije tek razvijenog sustava

8. Postojeći sustav unosa narudžbi nije kompatibilan s planiranim sustavom za automatsku identifikaciju (štapićasti kod) koji se razvija za skladište.

3 mjeseca

Visoka 65,000 1 Brza ispravka, a zatim novi razvoj

•Vidljivost: U kolikoj mjeri će rješenje ili novi sustav biti dostupni korisnicima.•Korist: Paušalna procjena koliko bi rješenje povećalo dobit ili smanjilo trošak u jednoj godini.


Planiranje projekta

Određivanje cilja i svrhe projekta (goal, objective)• izdvajanje zadataka koji su sukladni poslovnim ciljevima, a mogu biti

informatiziraniKoji se probleme nastoji riješiti projektom?Koje su očekivane koristi?

Doseg i razgraničenje projekata ili pod-projekata (Scope)• System boundary, Constraints, Objectives, Permissions, End products

Koje su granice sustava? Koji će zahtjevi biti ispunjeni?Što ne može biti napravljeno? Što neće biti napravljeno?Tko će, kako i pod kojim uvjetima moći koristiti rješenje?Kako se mjeri ili određuje uspjeh (neuspjeh)?Kako će se znati da je projekt gotov?

Vremensko planiranjeodređivanje prioritetnih zadataka i vremenskih okvira prioriteta


Izrada početnog plana

Podjela projekta u podprojekterazrada projekta u manje cjeline i određivanje redoslijeda izrade

• za pojedini projekt izrađuje se plan rada (work breakdown structure)• obavlja se razrada i raspodjela poslova te izrada vremenskog rasporeda

mogući načini podjele posla na cjeline tako da:• cjelinu može obaviti jedna osoba ili ekipa • cjelina se može obaviti jednom metodom• posao završi jednim “proizvodom” (dokumentom, aplikacijom ili

podsustavom)Izrada početnog plana razvoja IS

početni glavni plan projekta (master plan, baseline plan)• podprojekti, prioriteti, … • okvirni vremenski plan po fazama• dorađuje se i ažurira sukladno napretku projekta

Prezentacija projekta radi traženja suglasnosti o nastavku projektakonsolidirani prijedlog projekta (project charter) može poslužiti kao interni ugovor projekta


Primjer: Početni plan informacijskog sustava

Primjer početnog (preliminarnog) plana

Primjeri: \Planiranje\Plan*.*

1. Nabavka sustava za upravljanje bazama podataka2. Tečaj opće informatičke pismenosti za rukovoditelje odjela3. Tečaj za programere u jeziku za upravljanje bazama podataka5. Tečaj za administratore baze podataka4. Izrada prototipa programske podrške za i-tu fazu realizacije6. Izrada α - verzije aplikacije7. Testiranje α - verzije u Informacijskim sustavima8. Uklanjanje uočenih nedostataka i izrada β - verzije programa9. Tečaj za odabrane korisnike na β - verziji10. Testiranje kod korisnika u paralelnom radu s dosadašnjim programom11. Uklanjanje nedostataka i izrada stabilne verzije12. Zamjena dotadašnjeg programa novim programom, uz preuzimanje podataka13. Tečaj za ostale korisnike14. Uvođenje korištenja programa kod ostalih korisnika15. Tečaj za upoznavanje s mogućnostima programa za odabrano poslovodstvo 16. Prikupljanje primjedbi korisnika i novih zahtjeva17. Izrada sljedeće faze/verzije programa. Povratak na točku 4).


Izvješće o projektu (problemima i dosegu projekta)

SažetakSažetak prijedlogaKratko obrazloženje očekivanih koristiKratko objašnjenje sadržaja izvještaja

Prikupljene informacije Kratak opis projektnog zahtjevaKratko objašnjenje provedenih aktivnosti

Činjenice i zaključci• može se potkrijepiti matricom

problema i mogućih rješenjaProblemi i analiza problemaMogućnosti i analiza mogućnosti Direktive i implikacije

Detaljan prijedlogObrazloženje prijedloga

• Hitne prepravke• Brze prepravke• Unaprjeđenja• Novi razvoj

Plan projekta• Početni ciljevi projekta• Početni glavni plan projekta (na

razini faza)• Detaljni plan za slijedeću fazu

PriloziZahtjev za uslugama sustavaMatrica obrazloženja problema(ostala dokumentacija)


Određivanje poslovnih ciljeva

Produbljivanje analize problema za projekte koji prođu početnu selekciju"Da li su problemi vrijedni rješavanja?“, "Da li je gradnja isplativa?"Detaljnija analiza problema, njihovih uzroka i posljedica

• "Ne pokušavaj popraviti prije nego shvatiš kako radi!"Analiza poslovnih procesa

• Koji su najveći problemi?• Koja su moguća rješenja problema?• Kako informatizacija može pomoći?

Grubo modeliranje postojećeg sustavaMogu se koristiti različite formalne metode

Analiza kritičnih faktora uspjeha (CSF - Critical Success Factors)• čimbenici kojima poslovodstvo posvećuje posebnu pažnju• č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• uočavanje podataka povezanih s procesima

Analiza izvodljivosti i procjena troškova-koristi


Uzroci i posljedice, ciljevi i ograničenja (primjeri)ANALIZA UZROKA I POSLJEDICA CILJEVI I OGRANIČENJA SUSTAVA

Problem ili mogućnost Uzroci i posljedice Ciljevi sustava Ograničenja sustava

1. Vrijeme odgovora na narudžbu je neprihvatljivo dugo.

1. Promet je povećan, a broj službenika smanjen Vrijeme obrade narudžbi je isto.

2. Sustav previše ovisi o ručnom unosu. Pojedine vrijednosti se unose više puta. Posljedica je da se narudžbe obrađuju dulje nego je potrebno.

3. Središnje računalo radi na maksimumu svojih kapaciteta, što se očituje u sporijem radu aplikacija za unos narudžbi. Budući da službenici pokušavaju brže raditi, povećao se broj pogrešaka pri unosu.

4. Obrasci za prikupljanje narudžbi iz skladišta nisu oblikovani za učunkovito popunjavanje, što dodatno usporava unos narudžbi.

1. Umanjiti vrijeme unosa pojedine narudžbe za 30%.

2. Ručni unos narudžbi svesti na 50% ukupnog broja.

3. Na zaslonu za ručni unos smanjiti broj potrebnih pritisaka na tipkovinicu.

4. Prenijeti unos podataka sa središnjeg na osobna računala.

5. Zamijeniti postojeće obrasce za prikupljanje narudžbi mrežnim sustavom između skladišta i prodaje tako da se eliminira uporaba papirnate dokumentacije.

1. Broj zaposlenih u obradi narudžbi se ne može uvećati.

2. Novi sustav mora biti kompatibilan s postojećim Windows XX standardom.

3. Novi sustav mora biti kompatibilan s već odobrenim sustavom za automatsku identifikaciju štapićastim kodom.


Istraživanje uzroka

Primjer: Istraživanje uzrokaProblem: pad prodajeVidljivi znak: povećani opoziv (storno) narudžbiRazlog: nezadovoljstvo kupacaUzrok: spor sustav za naručivanje

Zadatak analitičara je razdvojiti uzroke i posljedice problema. Na primjer, dugi red u nekoj videoteci nije zaseban problem nego može biti posljedica pomanjkanja osoblja, 'lijenosti' ili nezainteresiranosti osoblja za posao ili pak posljedica ručnog unosa podataka i izdavanja računa.

Vezana za definiranje problema je i provjera opravdanosti korisnikovih zahtjeva (potreba).

U našem bi primjeru analitičar trebao razmotriti da li je zahtjev vlasnika videoteke za ubrzanjem procesa izdavanja filmova realan.


Postavljanje ciljeva

Primjeri poslovnih ciljevaPotpomoći reorganizaciju u tržišno orijentirano poduzeće prema EU normama.Osigurati informacije o izvorima, razlozima i mjestu nastanka svakog troška u sustavu.Uskladiti hijerarhiju odlučivanja s hijerarhijom u poduzeću.Racionalizirati utrošak novca za ...

Primjer: postavljanje ciljeva ISProblem: Predugo vrijeme unosa narudžbiCilj: Ubrzanje unosa

• Kriterij: performance, izvedbaLoš primjer: Povećanje ili smanjenje

• “Povećati broj unijetih narudžbi u 24 sata za 5%”Bolji primjer: Razina provedbe

• “Unijeti 98% zaprimljenih narudžbi unutar 24 sata”Kriterij mora biti mjerljiv

• Apsolutni iznos ili relativni iznos konkretne vrijednosti• Može biti binaran – postoji ili ne postoji, npr. Omogućiti online pretraživanje


Ograničenja

OsobljeOdjel informatike smije zaposliti najviše tri stalna zaposlenika

Materijalni trošakNabavka uredskog i potrošnog materijala ne smije premašiti XXX HRK

Računalna opremaProjekt se mora obaviti bez nabavke novog hardvera (gospodarstvo?)Trošak opreme poželjno predstavlja barem 33% budžeta (znanost!)

Financijska sredstvaUkupni budžet projekta je XXXXX HRK (uvijek manji od traženog!)Naknade izvođačima ne smiju premašiti XX% ukupnog iznosa


Modeliranje postojećeg sustava

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

Taktika - Skrivanje informacija (information hiding)skrivanje/zanemarivanje detalja i usredotočenje na ono što je zaista važnonpr. izbjegavanje proučavanja tehničkih detalja u ranim fazama

Globalni, okvirni, grubi modeliModel organizacije i resursa

• kontekst, organizacijska struktura, prostorni raspored sredstavaGlobalni model procesa

• funkcionalna dekompozicija• tok ključnih poslovnih procesa

– kolanje dokumenata i protok informacijaGlobalni model entiteti-veze (enterprise data model)

• kategorije podataka – klase podataka (ne razredi objekata!)60FER-ZPM-GRZ, Fertalj & Kalpić: Projektiranje informacijskih sustava, akad.god. 2006/07.

Planiranje informacijskog sustavaAktivnosti

Analiza problema, povoljnih prilika i mogućih rješenja problema Definiranje ciljeva i zadataka informacijskog sustavaProcjena ograničenjaPonovna procjena i preciziranje opsega projektaRevizija glavnog plana

Puzeći doseg projekta (creeping scope)Tijekom izvedbe projekta često se događa polagano, ali značajno povećanje obujma uslijed pogrešne procjene ili različitog tumačenja ciljeva između korisnika i izvođačaGranice projekta moraju biti definirane što je moguće preciznijeTime se kasnije povećanje projekta možda neće ukloniti ali će se barem moći nadzirati

Opcionalno se planira i provodi:Izrada prototipa ili oglednog (pilot) projekta i procjena njegove uspješnosti

• projekt koji se može uspješno i “brzo” realizirati (npr. 3-9 mjeseci, ovisno o veličini čitavog projekta)

• poželjno takav koji će vratiti uloženu investicijuProcjena mogućih tehničkih rješenja IS (alternativa) i prijedlog najboljeg rješenja

Na kraju se (opet!) može očekivati pokretanje, odbacivanje, odgoda ili prilagodba (ostalih, pojedinih) projekata


Idejno rješenjeSažetak

Sažetak prijedlogaSažetak problema, mogućnosti i direktivaKratki navod ciljeva unaprjeđenja sustavaKratki navod sadržaja izvješća

Poznate informacijePopis održanih razgovora i koordiniranih grupnih sastanakaPopis ostalih izvora informacija Opis tehnika korištenih u analizi

Pregled postojećeg sustavaStrategijske odrednice (ako je projekt dioSPIS ili na njega utječe)Modeli postojećeg sustava

• Model sučelja (kontekst)• Model resursa (prostor)• Model procesa (funkcija)• Model podataka (kategorije)

Analiza postojećeg sustava• problemi, mogućnosti i analiza

uzroka i posljedica za pojedine elemente

PerformanceInformacijeEkonomijaKontrolaUčinkovitostUsluge (servisi)

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

• Precizirani doseg projekta• Revidirani glavni plan• Detaljni plan za slijedeći korak

DodaciModeli sustava (ako nisu dio studije)(ostala dokumentacija prema potrebi)


Primjeri

Primjeri: \PlaniranjeGlobalno idejno rješenje informatizacije za "SLJEME", d.d.Idejno rješenje IS Personalne upraveStrategic Plan For Alaska’s Criminal Justice Information System Integration

Analiza izvodljivosti i troškova-koristi


Analiza izvodljivosti

Za pojedine projekte analizira se izvodljivostmjerenje korisnosti, praktičnosti i isplativosti projekta - IStrebala bi se raditi tijekom planiranja, ali i kasnije (npr. nakon faze analize)

• nakon odluke o pokretanju projekta složenost i opseg projekta mogu se promijeniti pa početno izvodljiv projekt može postati neizvodljiv

• praktično gledano, točnost procjene izvodljivosti raste s dubinom analize

Analiza, Studija izvodljivosti (feasibility analysis, feasibility study)detaljna provjera projekata koju provode sistem analitičariprocjenjuje se da li je projekt izvodljiv s obzirom na raspoloživa sredstvaprocjenjuje se da li projekt omogućuje poboljšanjaradi se izvješće o izvodljivosti i prezentira se relevantnim sudionicima radi komentara i mišljenja

• može biti dio idejnog rješenja, a ponekad tako i izgledaeventualni povratak u studiju izvodljivosti → revidirano izvješće


Operativna izvodljivostOrganizacijska/Operativna izvodljivost

procjena hitnosti rješavanja problema (planiranje)procjena prihvatljivosti rješenja (kasnije faze)

Vrijedi li rješavati problem? Da li predloženo rješenje rješava problem?Performance – protočnost i odziv sustava s obzirom na ulazeInformacije – dovoljne, pravodobne, prikladne, ažurne, točne, korisneEkonomija – problemi troškova, mogućnosti uštedaKontrola – sigurnost i zaštita podatakaUčinkovitost – poboljšanje uporabe raspoloživih resursa (ljudi, oprema, novac, itd.)Usluge – poželjni i pouzdani servisi, elastičnost i mogućnost prilagodbe, zadovoljstvo

Koji je stav korisnika prema rješenju? Da li će se sustav koristiti?Podrška uprave i prihvaćanje od krajnjih korisnika – otpori njihovoj budućoj ulozi ili tehničkom rješenju i kako ih prevladatiPromjena radnog okruženja, procedura – prilagodba promjenamaProcjena upotrebljivosti (najčešće prototipom)

• Krivulja učenja – vrijeme osposobljavanja potrebno za postizanje pune primjene• Lakoća korištenja – jednostavno sučelje za početnike i povremene korisnike,

složenije operacije za iskusne korisnike• Zadovoljstvo – ponuđenom rješenju korisnik daje prednost pred postojećim


Tehničko-tehnološka izvodljivost» Može li se sagraditi? Može li se kupiti?

Procjena mogućih rješenja i alternativaprocjena stanja na tržištu opremeprocjena postojećih rješenja u drugim organizacijama (tamo gdje je moguće)procjena primjenjivosti različitih tehnologija

Primjenjivost rješenja, tehnologijeMože li se tehnologija jednostavno primijeniti?Pojedine sredine zagovaraju najsuvremeniju tehnologiju (state-of-the-art)

• naprednost, zanimljivostVećina je sklona zreloj i dokazanoj tehnologiji

• sigurnost, bolja podrškaRaspoloživost tehnologije (podrazumijeva se da je primjenjiva)

Može li se nabaviti?Ako je riječ o gotovom rješenju (IS iz dućana), ima li to rješenje potrebne karakteristike? Treba li ga i u kojoj mjeri prilagoditi ili doraditi?

StručnostPostoji li potrebna stručnost za primjenu tehnologije?

• I najnovija tehnologija može se svladatiPostoji li potrebna vještina za očekivani završetak prema rasporedu?

• Bitno je da usvajanje tehnologije i njezina primjena završe na vrijeme


Vremenska izvodljivost» Kada će biti gotovo? Može li biti gotovo na vrijeme?

Prihvatljivost vremenskog rasporedaRazmatra se opravdanost rokova s obzirom na raspoloživu stručnost

Očekivano vrijeme završetka može biti poželjno ili obveznoČvrsti rokovi – nesigurni projekt treba prekinuti/odgoditiPoželjni rokovi – može se predložiti alternativni vremenski plan

Bolje je isporučiti ispravan sustav dva mjeseca kasnije, nego neispravan ili beskoristan na vrijeme!!!


Ekonomska izvodljivost» Isplati li se graditi? Treba li graditi?

Trošak razvoja sustava (fiksni trošak)apsolutni iznos, početna procjena, ažuriranje tijekom napretka projektaprimjeri:

• osoblje: plaće, honorari• oprema – procjenjuje se nakon odabira tehničkog rješenja• izobrazba: tečajevi

Trošak primjene sustava (varijabilni trošak)relativan iznos, ovisan o uporabiprimjeri:

• režije (struja, telefon)• održavanje (ljudski rad)• obnova licenci

Analiza i usporedba ukupnih troškova-koristi (cost-benefit analysis)Troškovi i korist

• mjerljivi (npr. cijena opreme, iznos plaća, prodaja, prihod)• nemjerljivi (npr. zadovoljstvo korisnika, brzina odlučivanja, dobra referenca)

Financijski trošak i korist mogu se izraziti formulama• razlika korist-trošak u nekom razdoblju (Net Present Value)• povrat investicije (korist-trošak)/trošak (Internal Rate of Return)• trenutak u kojem korist nadvlada trošak (Payback Point)


Ekonomska izvodljivost

CBA računa troškove i korist projekta kao trenutnu vrijednost (Presentvalue - PV)

» $ označava novčanu jedinicu u bilo kojoj valuti

Današnja vrijednost onoga što će postati $1.00 nakon ‘n’ godina u budućnosti, ako uzmemo u obzir kamate ‘I’ iznosi:PV = 1/(1 + I)n = (1 + I)-n

Razlika predstavlja kamatu koja se može zaraditi tim novcemPrimjeri:

troškovi razvoja od $100.000 imaju trenutnu vrijednost od $100.000korist 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 investicijeROI - postotak relativnog iznosa koristi projektaROI = (ukupna korist – ukupan trošak) / (ukupan trošak)ROI se obično dijeli sa dužinom projekta kako bi se dobio godišnji ROINizak ROI (~ manji od 10% godišnje) može pokazivati da je korist preniska da bi bila isplativa


Primjer analize trošak-koristTrošak / Korist Godina 0 Godina 1 Godina 2 Godina 3 Godina 4 Godina 5 Godina 6Trošak razvoja (418,040 $)

Primjena i održavanje (15,045 $) (16,000 $) (17,000 $) (18,000 $) (19,000 $) (20,000 $)Faktor za kamatu 12% 1.000 0.893 0.797 0.712 0.636 0.567 0.507

Trenutna vrijednost (418,040 $) (13,435 $) (12,752 $) (12,104 $) (11,448 $) (10,773 $) (10,140 $)Kumulativni trošak (418,040 $) (431,475 $) (444,227 $) (456,331 $) (467,779 $) (478,552 $) (488,692 $)

Korist od novog IS 0 $ 150,000 $ 170,000 $ 190,000 $ 210,000 $ 230,000 $ 250,000 $Faktor za kamatu 12% 1.00 0.893 0.797 0.712 0.636 0.567 0.507

Trenutna vrijednost 0 $ 133,950 $ 135,490 $ 135,280 $ 133,560 $ 130,410 $ 126,750 $Kumulativna korist 0 $ 133,950 $ 269,440 $ 404,720 $ 538,280 $ 668,690 $ 795,440 $

0 1 2 3 4 5 6Ukupno (418,040 $) (297,525 $) (174,787 $) (51,611 $) 70,501 $ 190,138 $ 306,748 $

(500,000 $)

(400,000 $)

(300,000 $)

(200,000 $)

(100,000 $)

0 $

100,000 $

200,000 $

300,000 $

400,000 $

0 1 2 3 4 5 6


Izvodljivost i održivost projekta

Primjeri:\PIS-PrimjerProjekta\Planiranje\

• SurvivalTest [McConnell, 1998], http://www.construx.com/survivalguide/• OdrzivostProjekta• Izvodljivost-HZZO

Prikupljanje informacija i utvrđivanje zahtjeva

Prikupljanje informacija (information gathering)Prikupljanje podataka (data collection) Ustanovljavanje činjenica (fact finding)


Prikupljanje informacija

Intervjui s ključnim korisnicima i radne sjedniceAko naručitelj zapošljava informatičare svakako ih treba uključiti u analizu. Sučeljavanje korisnika i informatičara ubrzava rješavanje proturječnih iskaza.

Upitnici i anketeNadomjestak za intervju ili prikupljanje informacija o resursima.

Analiza dokumentacijeTreba prikupiti sve dokumente značajne za poslovanje, radi boljeg utvrđivanja pravila, poslovne politike, ciljeva poslovanja te strukture informacija.

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

PromatranjeNeposredni uvid u poslovne procese promatranjem radnih sredina (način izrade i razmjene dokumenata, procesi osnovne djelatnosti).

Drugi načiniPrototipiranje, …

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


Postupak intervjuiranja

Intervjuneusiljen i elastičan razgovor s ispitanikom, slijed pitanja i odgovora

• ispitanik se pojavljuje u ulozi pasivnog sugovornika (!?)• sugovornici: rukovoditelji, krajnji korisnici, ostali sudionici

standardno uključuje dva sugovornika ali može i više (korisnika, ispitivača):• individualni intervju – jedan korisnik ili suradnici koji rade isti posao • intervjuiranje grupe – više korisnika iz različitih područja

Organizacija razgovorainformacije se prikupljaju nizom pojedinačnih razgovora(prvi) razgovori trebali bi se voditi prema unaprijed dogovorenom planu i rasporedu koordinator

• Primjeri: \Analiza\PlanRazgovora• postupak je spor i neučinkovit, jer se organizacija razgovora mora obaviti za svaki

pojedini razgovornakon dovršetka analize i sinteze dobivenih informacija neke razgovore (ponekad i čitavu seriju) treba ponoviti da bi se upotpunile dobivene informacije ili uskladili proturječni iskaziukupan broj razgovora ne može se unaprijed točno odrediti i treba ga prilagoditi stvarnoj situaciji


Tehnika intervjuiranja

Priprema za razgovorutvrđivanje informacija koje treba saznatiproučavanje postojeće dokumentacije i prethodnih nalazaodređivanje 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

Primjeri: \Analiza\Podsjetnik-temePodsjetnik-kratkiPodsjetnik-dugi


Tehnika intervjuiranja

Planiranje i obavljanje razgovoraokvirno trajanje prvog razgovora je 2 sata (općenito 1,5 – 2,5 sata)Početak razgovora

• predstavljanje sudionika• upoznavanje sa svrhom razgovora (prikupljanje informacija o …)

Vođenje razgovora• postavljanje pitanja i bilježenje odgovora• prikupljanje dokumentacije

Završetak razgovora• približno 5-10 minuta prije isteka planiranog vremena• prekida se slijed postavljanja pitanja• provjerava se da li postoji nešto što je sugovornik htio reći a nije bilo

pitano• provjerava se da li treba proširiti 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

• zahvala na razgovoru


Tehnika intervjuiranjaPreispitivanje i pojašnjenje sadržaja (follow-up)

provjera zabilježenih navoda radi upotpunjavanja bilješkitelefonom, elektroničkom poštom, novim sastankom

Dokumentiranje razgovoraPisanje zapisnika

• samostalno pisati zapisnike (“Tko ne razumije, ne može bilježiti.”)• kada u razgovoru sudjeluje više analitičara, određuje se voditelj razgovora koji je

ujedno i zapisničar, a ostali ulažu primjedbeSadržaj zapisnika

– Projekt– Vrijeme i mjesto održavanja razgovora– Sudionici– Sadržaj razgovora (tekst zapisnika)– Popis prikupljene dokumentacije– Zapisničar

• zapisnik mora sadržavati ono što je rečeno i slijediti tok razgovora• zapisnik ne smije nametati zaključke, jer su oni rezultat analize

Autorizacija (ovjera) zapisnikazapisnik se šalje na uvid sugovorniku, koji šalje potvrdi o vjernosti zapisnikapo potrebi sugovornik može nadopuniti dijelove za koje smatra da nisu evidentirani ili pojasniti dijelove za koje misli da su krivo protumačeni

Primjeri: \Analiza\ Zapisnik, TragRazgovora


Preporuke za vođenje intervjua

Treba pitati o svemu što se smatra važnimništa nije samo po sebi razumljivo i svima jasnone pretpostavljati da se unaprijed zna o čemu se radi

Repertoar i vrste pitanjaPitanja zatvorenog tipa:

• Koliko ... obrađujete (u nekom razdoblju)?• Na koji način obrađujete ... ?

Pitanja otvorenog tipa:• Što mislite o ... ?• Koji su najveći problemi ... ?

“Probna” pitanja:• Zašto ?• Možete li navesti primjer za takvu situaciju?• Molim detaljnije objašnjenje za ...


Preporuke za vođenje intervjua

Analiza odgovorarazlučivanje činjenica od mišljenjautvrđivanje da li pojedine činjenice odgovaraju drugimaanaliza činjenica koje se ne poklapaju provjera odgovora različitih sugovornika na isto pitanje

Preporučljivo ponašanjeiskrenost i nepristranost

• cilj je naći za korisnika najprikladnije rješenje, a ne podupirati određeno programsko rješenje ili računalnu platformu

pažnja i jezgrovitost• “brzo misli, jasno govori”

izbjegavanje sugestivnih pitanjanenametanje zaključakaležernost (+ praćenje reakcija sugovornika)

Grupno intervjuiranjeizbjegavati i po potrebi nadomjestiti radnim sjednicama iznimno provesti, kada se želi utvrditi zajednički interes ili proturječje


Upitnici i anketeUpitnik (pismeni intervju)

sadrži pitanja koja se postavljaju tijekom razgovora (okvirno 20)može se dostaviti korisniku prije, umjesto ili nakon intervjuanedostaci:

• ispitanik može prilagoditi (kontrolirati) svoje odgovore• teško je procijeniti iskrenost (spontanost) odgovora• može obeshrabriti ispitanika

Primjer: Podsjetnik za SIOAnketa (inventar)

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

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


Proučavanje dokumenata

Prikuplja se sve do čega se može doćiAnaliza procesa

• Tipični dokumenti: pravilnici i zakoniAnaliza podataka

• Tipični dokumenti: obrasci (formulari), izvješća• Poželjno je da dokumenti budu reprezentativni, tj. popunjeni na tipičan način.

Tako se može ustanoviti koje informacije se uopće unose i na kakav način.– Reprezentativni dokumenti najčešće ne ukazuju na izuzetke, to jest podatke koji se

rjeđe bilježe ali ipak trebaju.– Također, stalno bilježenje nekih podataka ne mora značiti da su ti podaci stvarno

potrebni.– Treba prikupiti više uzoraka iste vrste dokumenta! ( sampliranje)

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

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

Primjeri: \Dokumenti


Analiza postojećih aplikacija i evidencija

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

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

Primjeri: \PIS-PrimjerProjekta


Analiza postojećih aplikacija i evidencija Nedostaci modela podataka

Različitost modela podataka postojećih aplikacija• entiteti iz stvarnog svijeta nisu jednako zastupljeni u postojećim modelima• isti entitet iz stvarnog svijeta pojavljuje se pod različitim nazivima• isti entitet iz stvarnog svijeta opisan je različitim atributima• dva ili više entiteta iz stvarnog svijeta prikazano je različitim brojem entiteta u

podatkovnim modelimaNedostaci unutar pojedinog modela

• nedefiniranost identifikatora (primarnih ključeva)• nedefiniranost veza među podacima, najčešće kao posljedica nepostojanja

primarnih ključeva• nedefiniranost veza unatoč postojanju primarnih i (drugih) stranih ključeva, kao

posljedica razvoja tijekom uporabe i nedosljednosti• naglašena zalihost uvedena prilikom izrade zahtjevnih ili složenih programskih

rješenja• ukupna nenormaliziranost modela

Primjer: ERwin Examiner

Navedeni nedostaci opreme, podrške i podataka najčešći su razlozi za izgradnju novog IS! ( Operativna izvodljivost)


Promatranje poslovnog sustavaUvid u poslovne procese promatranjem radnih sredina

promatra se lokacija i kretanje ljudi te tijek izvršavanja poslova• fizički ulazi i izlazi sustava• zaprimanje, izrada i razmjena dokumenata• procesi osnovne djelatnosti, primjerice proizvodnja

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

Nedostacineučinkovitost, ako se dobro ne provedeutrošak vremenaometanje i neugoda promatranih osobamogućnost manipulacije promatrača

• npr. prikrivanjem uobičajenog kršenja radnih procedura Dužina i učestalost promatranja

Podaci dobiveni iz malog broja kratkotrajnih promatranja mogu biti nepouzdani i netočni.

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


Radne sjedniceRadni sastanci, sjednice (workshop)

analitičari i korisnici zajednički provode analizu i oblikovanjecilj sjednice je (zajedničko) pronalaženje najboljeg rješenjaposeban prostor i izolacijamoderator, dnevni red i zapisnici

Genijalnost grupe (tzv. brainstorming)koristi se za prikupljanje ideja i definiranje inofrmacijskih potrebakorisnike se potiče na aktivno i kreativno sudjelovanjeizvodi se tako da se svakog ispitanika iz grupe zatraži da definira po njemu idealno rješenje svaki sudionik iznosi sve što mu pada na pamet u svezi s problemom koji se rješavaod predloženih rješenja odabire se najbolje prema realnoj izvodljivostipostupak je učinkovit tamo gdje postoje korisnici koji dobro poznaju sustav ali teško prihvaćaju nove ideje

Slika: A.Dennis & B. Haley Wixom, Systems Analysis and Design,John Wiley & Sons, 2000


Radne sjednicePrednosti

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

Nedostaci sadržaj i dinamika

• pasivnost sudionika• “usitnjavanje” razgovora• udaljavanje od tema

trajanje• sjednice bi trebale trajati više dana (5-10) u nekoliko tjedana• ovom zahtjevu u praksi je vrlo teško udovoljiti zbog obveza sudionika

otpor sjednici i pratećoj izolaciji• razmjeran je razini položaja konkretnog sudionika• naglašen kada poduzeće zapošljava informatičare, jer se podrazumijeva da je

informatizacija isključivo njihov posao.


Razvoj prototipa

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

Izrada prototipaIzgrađuje 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 korištenje sustava i modificiranja istog iterativno se ponavlja, a informacijske potrebe korisnika otkrivaju korištenjem sustava.

Izrada prototipa pogodna je u onim okruženjima gdje je teško definirati konkretni model sustava te u okruženjima gdje se informacijske potrebe korisnika mijenjaju ili razvijaju.


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

Taktika kuhinjskog sudopera • korisnik navodi (preko)brojne potrebe: hrpu nepotrebnih izvještaja, formi,

sortiranja, izračuna i sl.• ovakav pristup obično je uzrokovan pomanjkanjem iskustva korisnika koji ne zna

što bi mu stvarno trebalo zatrebati ili nije u stanju razlučiti ono što je bitnoTaktika dimne zavjese

• korisnik traži više mogućnosti a zapravo mu je potrebna samo jedna ili dvije• dodatni zahtjevi služe za postizanje bolje nagodbe s analitičarom• taktika obično oslikava korisnika s dobrim poznavanjem onoga što želi, a zahtjeve

treba reducirati na one realne i izvodljiveTaktika "Treba mi isto ali u boljem obliku"

• korisnik koji koristi ovu taktiku nedostaje volja ili znanje, a ponekad oboje• šanse za uspješno definiranje problema su male jer samo korisnik može izraziti

svoje potrebe i problemeKorisnik je sklon prešutjeti izuzetke, koji su bitni (nužni !!!) za uspješnu realizaciju, a obično zahtijevaju i najviše napora tijekom ugradnje.

"To je naša jedina procedura … (osim kada …)"Ne izjednačavati “tako se uvijek radi” s “tako treba raditi”!

primjer: Google Search "Company Policy"


Primjer: Poslovna politikaStart 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.... (Google search: company policy)

Analiza sustava


Analiza sustavaAnaliza sustava, sistemska analiza

Analiza sustava je raščlanjivanje sustava u njegove komponente da bi se proučilo kako te komponente rade i međusobno komuniciraju.provodi se s namjerom slijedeće sinteze sustava i razvoja aplikacijaSinteza sustava

• Ponovno objedinjavanje komponenti u cjeloviti, poželjno poboljšani, sustav.

Alternativna definicija Analiza sustava je (1) razmatranje i planiranje sustava i projekta, (2) proučavanje i analiza postojećeg poslovnog i informacijskog sustava te (3) definiranje poslovnih zahtjeva i prioriteta novog ili poboljšanog postojećeg sustava. [Whitten et. al, 2000]

Svrha, cilj i dubina analizeAutomatizacija poslovnih procesa - Business Process Automation (BPA)

• povećanje učinkovitosti korisnika analizom problema i uklanjanjem uzrokaPoboljšanje poslovnih procesa - Business Process Improvement (BPI)

• povećanje učinkovitosti i djelotvornosti, analizom trajanja i koštanja poslovnih procesa te predlaganjem poboljšanja (udruživanje procesa, paralelizam izvedbe)

Reinženjerstvo poslovnih procesa - Business Process Reengineering (BPR) ili Preoblikovanje poslovnih procesa - Business Process Redesign (BPR)

• radikalni redizajn poslovnih procesa, analizom mogućih posljedica, procjenom alternativnih tehnologija, ukidanjem ili zamjenom pojedinih aktivnosti, analizom troškova-koristi i analizom rizika


Aktivnosti analizeAktivnosti analize

detaljna analiza postojećeg sustava te utvrđivanje potreba i zahtjeva• Kako radi postojeći sustav?• Na koji način ljudi koriste sustav da bi obavili svoj posao?• Koji su problemi pri korištenju 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 način se podaci prikupljaju i objedinjuju?

daljnja razrada granica projektaprimjeri: ProtokDokumenata, RazmjenaPodataka

Pozadinska analizaVažno je da shvatiti strukturu organizacije, tko u njoj radi, tko je kome podčinjen, kako surađuju različiti odjeli, itd.

Provedba analize - modeliranje sustavaZa potrebe pozadinske analize može se izraditi shema organizacijske strukture iz koje će biti vidljivo koja osoba ili grupa ljudi obavlja koji dio posla ( Modeliranje funkcija).Za ostale elemente također se rade odgovarajući modeli ( Modeliranje procesa, modeliranje podataka)


Postupci i tehnike analizeModerna strukturirana analiza

procesno usmjerena tehnika modeliranja poslovnih zahtjeva na sustav Informacijsko inženjerstvo

podatkovno usmjerena, ali procesno osjetljiva tehnika, usmjerena proučavanju organizacije ili njenih većih dijelova kao cjeline, a ne projekt po projekt

Brzi razvoj aplikacija (Rapid Application Development - RAD)razvoj djelomičnih verzija aplikacija, koje mogu evoluirati do konačnog rješenja

Združeni razvoj aplikacije (Joint Application Development - JAD)analiza zasnovana na intenzivnim radnim sjednicama na kojima vlasnici, korisnici, analitičari, dizajneri i graditelji zajednički definiraju i oblikuju sustav

Objektno usmjerena analiza• modeliranje učahurivanjem podataka i procesa u objekte

proučavanje postojećih objekata da bi se vidjelo mogu li se ponovno iskoristiti ili prilagoditi za nove primjenedefiniranje novih ili modificiranih objekata koji će skupa s postojećim objektima graditi novu aplikaciju

Navedeni postupci mogu se komplementarno primjenjivati, unatočuvriježenom poimanju da je riječ o međusobno isključivim metodama!!


Strukturirana analizaModerna strukturirana analiza = Logički dizajn (česti sinonim)

strukturirana analiza → strukturirani proces i rezultati analizetehnika modeliranja poslovnih zahtjeva na sustav

• usmjerena procesima, ali se razvila tako da obuhvaća i podatke• strukturiranje procesa, ulaza, izlaza te spremišta podataka potrebnih da bi se

ogovorilo na poslovne događajelogički modeli – modelima se prikazuje ŠTO je sustav i ŠTO mora raditi (ne KAKO)

• koriste se dijagrami toka podataka za logički prikaz poslovnih zahtjeva nezavisno od tehničkih rješenja logički dizajn

• izražavaju suštinu sustava sinonimi: esencijalni, konceptualni, poslovni modeliuključuje određivanje prioriteta zahtjeva

Analiza s ciljem automatizacije poslovnih procesarazumijevanje postojećeg sustava

• ekstenzivno prikupljanje informacija i zahtjeva• oblikovanje procesa i podataka

uočavanje mogućih poboljšanja (ako nije učinjeno ranije)• analiza problema – identificiranje problema, ustanovljavanje željenih poboljšanja• analiza uzroka (root causes analysis) – prioriteti problema i traženje uzroka

razvoj koncepata budućeg sustava• prikupljanje dodatnih informacija• revizija i dorada modela


Definiranje zahtjevaIEEE standard definira zahtjeve kao:

(1) Uvjet ili sposobnost koje korisnik treba da bi riješio 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 mogućnosti definiranih pod (1) ili (2). [IEEE Std 830-1998], [IEEE Std 610.12-1990]

Zahtjevi ne sadrže detalje dizajna, detalje implementacije ili informacije vezane uz planiranje projekta. Pažnja se usmjerava na ono ŠTO se želi izgraditi, a ne ulazi se u detalje kako i kada to napraviti.

Za 40-60% pogrešaka u projektu uzrok leži u pogreškama napravljenim u fazi postavljanja zahtjeva. [Leffingwell, 1997]

Tipična posljedica su "prazna očekivanja" (expectation gap): razlika između onog što očekuje naručitelj i onoga što je izvoditelj mislio da treba napraviti.

Naknadne prepravke mogu predstavljati do 40% troškova razvoja, od čegaje 70-85% pripisivo pogrešnim zahtjevima [Leffingwell, 1997].

Nepotpuno definirani zahtjevi čine planiranje projekta i praćenje promjena nemogućim.


Vrste zahtjevaPoslovni zahtjevi (zašto)

ciljevi organizacije ili korisnički zahtjevi na višoj razini, opis problema koje treba riješiti • primjer: poslovna potreba, "Poboljšanje usluge postojećim klijentima i

pridobivanje novih"sadržani u dokumentima u kojima se opisuje vizija i opseg projekta

• primjer: poslovni zahtjev, "Omogućiti Internet prodaju"Korisnički zahtjevi (zahtjevi krajnjih korisnika)

opisuju zadatke koje korisnik mora moći obaviti služeći se aplikacijamasadržani u opisima slučajeva korištenja, tj. opisima scenarija rada

Funkcionalni zahtjevi (što)definiraju softversku funkcionalnost (očekivano ponašanje i operacije koje sustav može izvoditi) koju treba ugraditi u proizvod da bi omogućio korisnicima obavljanje njihovih zadatakaposebno zanimljiva mogućnost programa (feature) – skup logički povezanih funkcionalnih zahtjeva koje korisniku omogućuju ispunjavanje poslovnih zahtjeva

Nefunkcionalni zahtjevi (kako ili kako dobro)standardi, pravila i ugovori kojih se proizvod mora pridržavati, opisi vanjskih sučelja, zahtjevi na performance, ograničenja na dizajn i implementaciju, te svojstva kvalitete (preciziraju opis proizvoda navodeći karakteristike proizvoda u različitim dimenzija koja su važne ili korisniku, ili graditelju)

Prioriteti pojedinih elemenata


Primjeri zahtjeva vlasnika sustava

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

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

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


Primjeri zahtjeva krajnjih korisnika

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

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

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

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

Lakše ostvarivanje ostalih prava iz studentskog standardaNpr. javni prijevoz po povlaštenoj cijeni, kazališta, kina, smještaj u studentskim domovima, student-servis, itd.


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?

Zahtjev, preciznije i detaljnijeModul za nadzor će ispisivati statusnu poruku u za to određeni dio sučelja.Poruka će se ažurirati svakih 60 sekundi (plus minus 10 sekundi) nakon što započne izvođenje 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 pogrešci ukoliko dođe do zastoja u izvođenju.Problem je rastavljen u više zahtjeva jer će svaki zahtijevati posebno testiranje.

Ukoliko je više zahtjeva grupirano u jedan lakše je previdjeti neki od njih tijekom izrade ili testiranja.

Primijetiti da u zahtjevu nije detaljno opisano kako će se poruka i gdje ispisivati. To će biti odlučeno tijekom dizajna.


Primjer neostvarljivog zahtjeva

"Proizvod će se trenutno prebaciti između ispisivanja i skrivanja znakova koji se ne mogu tiskati."

Računala ništa ne mogu napraviti trenutno te je ovaj zahtjev neostvariv.Da li programska podrška sama odlučuje 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 označeni tekst, cijeli dokument ili nešto treće?Nejednoznačnost: da li su "znakovi koji se ne mogu tiskati" skriveni znakovi, posebne oznake ili kontrolni znakovi?

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 točno navedeno kakvu (npr. kombinacija tipki), što se prepušta dizajnerima.


Primjer neodređenog zahtjeva

"Parser će brzo generirati izvješće o pogreškama HTML oznaka, koje omogućava brzi ispravak pogrešaka kada program koriste početnici u HTML-u."

Riječ "brzo" je neodređena. Nije definirano što tvori izvješće i to čini zahtjev nekompletnim. Kako se ovjerava zahtjev? Pronaći nekoga tko se smatra početnikom u HTML-u i zatim vidjeti kako brzo će, uz pomoć izvješća, ispraviti pogreške? Kada se generira izvješće?

Bolje:Nakon što je HTML analizator obradio datoteku generirat će izvješće koje sadrži broj linije i tekst pronađenih HTML pogrešaka, te opis svake pogreške. Ukoliko nema pogrešaka prilikom analize, neće se generirati izvješće.


Određivanje zahtjevaPoslovni zahtjevi

Sve što opisuje financijski, trgovački, ili drugi poslovni probitak koji korisnici, ili organizacija koja razvija sustav, mogu dobiti je najvjerojatnije poslovni zahtjev.

Slučajevi korištenja ili scenarijiOpćenite izjave o korisničkim ciljevima ili poslovnim zadacima koje korisnici moraju obavljati najvjerojatnije su slučajevi korištenja, dok specifični opisi zadataka predstavljaju korisničke scenarije. Specifične zadatke treba generalizirati u općenite slučajeve korištenja.

Poslovna pravilaKada korisnik izjavi da se neku aktivnost mogu obavljati samo pojedine osobe ili uloge, pod određenim uvjetima, on možda opisuje poslovno pravilo. Poslovna pravila su operativni principi poslovnih procesa. Oni nisu funkcionalni zahtjevi.

Funkcionalni zahtjeviIzjava koja počinje s «Korisnik mora moći obaviti neku funkciju», ili «Sustav treba moći demonstrirati određeno ponašanje» je najvjerojatnije funkcionalni zahtjev. Funkcionalni zahtjevi opisuju vidljivo ponašanje sustava i definiraju što će sustav raditi. Treba biti svima jasno zašto sustav «mora» biti u stanju obavljati određene funkcije. Predloženi funkcionalni zahtjevi ponekad predstavljaju zastarjele ili neučinkovite poslovne procese koji ne trebaju biti uključeni u novi sustav.

Atributi kvaliteteIzjave koje opisuju kako dobro sustav obavlja funkciju su atributi kvalitete, tj. jedna vrsta nefunkcionalnih zahtjeva. Zahtjeve koji opisuju poželjne 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.


Određivanje zahtjeva IIZahtjevi vanjskih sučelja

Ovaj razred zahtjeva opisuje veze između sustava i vanjskog svijeta. Specifikacija sistemskih zahtjeva trebala bi uključivati odlomke za ove zahtjeve uključujući i sučelja te mehanizme komunikacije za korisnike, hardver i druge softverske sustave.

OgraničenjaOgraničenja su uvjeti koji ograničavanju izbor rješenja raspoloživih dizajneru ili programeru. Spadaju u nefunkcionalne zahtjeve i trebaju biti dokumentirani. Neopravdana ograničenja treba pokušati odbaciti jer onemogućavaju postizanje najboljeg rješenja. Također mogu umanjiti primjenu komercijalnog softvera i komponenti u rješenju. Neka ograničenja mogu pomoći u zadovoljavaju atributa kvalitete. Primjer je poboljšanje prenosivosti programa korištenjem samo standardnih naredbi nekog računalnog jezika.

Definicije podatakaDefinicija podataka je bilo koji opis formata, dozvoljenih vrijednosti, pretpostavljenih vrijednosti ili kompozicija složenih podatkovnih struktura. Sve definicije bi trebalo pohraniti u rječnik podataka, kao glavno kazalo za sudionike na projektu.

Ideje o rješenjuAko korisnik opisuje specifičan način interakcije sa sustavom kojom bi mogao obaviti neku akciju, npr. «Korisnik odabire podatak koji on želi iz padajuće liste», on predlaže rješenje, a ne zahtjev. Predloženo rješenje može odvući pažnju od pravih zahtjeva. Kod postavljanja zahtjeva treba se usmjeriti na ono što je potrebno obaviti, a ne na način realizacije. Treba istražiti zašto korisnik predlaže određenu ugradnju jer to može pomoći u razumijevanju stvarne potrebe i korisnikovih očekivanja o načinu kako bi sustav trebao raditi.


Postavljanje prioriteta

Nužno svojstvo - Da li vlasnik sustava nešto stvarno mora imati? Postoji tendencija da se previše zahtjeva proglasi nužnim!Po definiciji, ako sustav ne uključuje nužne zahtjeve, taj sustav ne može ispuniti svoju svrhu. Treba testirati svaki zahtjev koji se smatra nužnim i probati ga rangirati.

• Ako se zahtjev može rangirati onda nije obvezan! • Potpuno obvezni zahtjevi se ne mogu rangirati jer su nužni za prvu

verziju sustava!Poželjno svojstvo - Funkcije koje korisnik želi na kraju imati

Ranije verzije sustava mogu pružiti (ne potpunu) funkcionalnost bez tihzahtjeva. Poželjni zahtjevi mogu i trebaju biti rangirani.

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


Dokumentiranje analize (zahtjeva)

Definicija zahtjeva (Requirements Definition)izjava o stanju i ograničenjima sustava te potrebamanarativni dokument namijenjen korisniku ili ga piše korisnik

• poslovni i korisnički zahtjevi te njihovi prioriteti• uočeni problemi, ključne pretpostavke i preporuke rješenja

Specifikacija zahtjeva (Requirements Specification)često se naziva i funkcionalnom specifikacijomstrukturirani dokument s detaljnim opisom očekivanog ponašanja sustavanamijenjen ugovarateljima i izvoditeljima razvojaugradbeno 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\


Predložak dokumenta specifikacije zahtjeva1. Uvod

1.1 Namjena1.2 Konvencije dokumenta1.3 Tko treba čitati dokument i savjeti

za čitanje dokumenta1.4 Opseg proizvoda1.5 Reference

2. Sveobuhvatni pregled2.1 Kontekst proizvoda2.2 Funkcije proizvoda2.3 Kategorije korisnika i svojstva2.4 Okružje u kojem se izvodi proizvod2.5 Ograničenja dizajna i ugradnje2.6 Pretpostavke i ovisnosti

3. Zahtjevi za sučeljem3.1 Korisničko sučelje3.2 Hardversko sučelje3.3 Softversko sučelje3.4 Komunikacijsko sučelje

4. Svojstva sustava4.x Svojstvo X4.x.1 Opis i prioriteti4.x.2 Nizovi pobuda/odziv4.x.3 Funkcijski zahtjevi

5. Ostali nefunkcionalni zahtjevi5.1 Zahtjevi za performansama sustava5.2 Zahtjevi za sigurnošću korisnika5.3 Zahtjevi za sigurnošću podataka5.4 Kvaliteta programske podrške5.5 Poslovna pravila5.6 Korisnička dokumentacija

6. Ostali zahtjeviDodatak A: RječnikDodatak B: Modeli i dijagramiDodatak C: Lista nedovršenih/neodređenih

zahtjeva


Rizici lošeg planiranja zahtjevaNedovoljna uključenost korisnika

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

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

Nejasni (dvosmisleni) zahtjevi• situacija u kojoj čitatelj(i) zahtjeva zahtjev tumače na više načina gubljenje

vremena i prepravljanjePretjerano ukrašavanje

• želja izvođača da dodaju novu funkcionalnost "koja bi se trebala svidjeti korisnima" i zahtjev korisnika za dodacima koji dobro izgledaju ali ne pridonose funkcionalnosti nepotrebni dodaci i gubljenje vremena

Minimalističke specifikacije• tendencija postavljanja minimalnih zahtjeva ili skiciranja koncepta, uz želju da ih

izvođači nadopune tijekom izvedbe frustracije izvođača, neispunjena očekivanja korisnika

Zanemarivanje potreba• zanemarivanje potreba određenih (grupa) korisnika stvaranje 'opozicije'

projektu


Svojstva dobro postavljenih zahtjevaSvojstva dobrih izjava o zahtjevima [IEEE, 1998]

Potpunost (cjelovitost)TočnostOstvarivost (izvodljivost)NužnostPoredak po prioritetimaNedvosmislenostMogućnost provjere

Svojstva dobrih specifikacija zahtjevaPotpunostKonzistentnostMogućnost izmjeneMogućnost praćenja

Cilj je napisati dovoljno dobre zahtjeve, na temelju kojih se može pristupiti dizajnu i ugradnji uz prihvatljiv stupanj rizika.Nedovoljno definirani zahtjevi

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


Analiza i modeliranje sustava

Na temelju izjava korisnika i prikupljene dokumentacije modeliraju se pojedine komponente sustava (procesi, podaci, događaji)

Moguća su preslikavanja uočenih imenica i glagola u konkretne elemente modela kakvi će biti opisani u nastavku.

"Kemičar ili član osoblja kemijskog laboratorija može podnijeti zahtjev za jednom ili više kemikalija. Zahtjev može biti udovoljen ili dostavom pakiranja kemikalije koja se većnalazila na zalihi kemijskog laboratorija ili upućivanjem narudžbe za novim pakiranjem kemikalije od vanjskog dobavljača. Osoba koja upućuje zahtjev mora imati mogućnost pretraživanja kataloga kemikalija vanjskog dobavljača dok sastavlja narudžbu. Sustavmora pratiti status svakog zahtjeva za kemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Također, mora pratiti povijest svakog pakiranja kemikalija od trena kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbačen."

•Procesi(DFD) •Odnosi (ERD) •Prijelazi (iz stanja u stanje) (STD)•Metode razreda (dijagram razreda)

•Akcije, ono što korisnik može poduzeti, ili događaji koji se mogu dogoditi

Glagol

•Terminatori ili spremnici podataka (DFD)•Entiteti ili njihovi atributi (ERD)•Razredi ili njihovi atributi (dijagram razreda)

•Ljudi, organizacije, softverski sustavi, podatkovne jedinice, ili postojeći objekti

Imenica

Komponente analitičkog modelaPrimjerTip riječi


Preporuke za analizuTehnike i pomagala ne znače puno bez ispravnog pristupa.

Postupak analize mora biti prilagođen korisniku.Ključno je razumjeti suštinu organizacije i način poslovanjaPrimjer: \Analiza\ PreporukeZaAnalizu

Ono što korisnik želi često nije i ono što korisnik stvarno treba!

Da se priča o klasičnom razvoju ne bi ponavljala, rade se modeli sustava (postojeći fizički i logički, budući logički…).

Paraliza analizePostupak ponavljanog modeliranja postojećeg sustava i vrednovanja modela može utrošiti značajno vrijeme na modeliranje nečega što će vjerojatno biti izmijenjeno ili zamijenjeno.Ne pretjerivati s modeliranjem postojećeg sustava!

Slika: Awad, 1985; preveo Anonymous(WWW)

Modeliranje funkcija i procesa


Modeliranje procesa i funkcija

Logički procesi: funkcije, događaji i elementarni procesirad i akcije koji se obavljaju bez obzira na način ugradnje i resurse sustava (ljudi, strojevi, softver)Neke metode poistovjećuju funkcije i procese!

Postupak dekompozicijestvarni problemi su preveliki i presloženi da bi ih se riješilo odjednom (“u komadu”) strukturno raščlanjivanje, rastavljanjenačelo podijeli pa s/vladaj (lat. divide et impera, eng. divide and conquer)

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

• funkcije i procesi• organizacijska struktura• struktura podataka• struktura programske opreme

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


Logički procesiFunkcija

skup logički povezanih trajnih poslovnih aktivnosti i zadataka (djelatnost, posao)• funkcija se obavlja stalno (nema određeni početak i kraj)• funkciju obavljaju osobe, grupe djelatnika ili organizacijske cjeline

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

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

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

• pokreće se diskretnim ulazom i završava nakon što proces odgovori odgovarajućim izlazom

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

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

Proces (elementarni, primitivni proces)postupak, način rada, dosljedna izmjena stanjadiskretna odluka, aktivnost ili zadatak kojima se obavlja neki posao

• proces se obavlja uvijek na jednak način (za određeni ulaz daje isti izlaz)• trajanje procesa je konačno i odredivo (poznati početak, završetak, ponavljanje)• za obavljanje se koriste sredstva, npr. ljudska, materijalna (strojevi), financijska


Poslovna pravila i poslovna politika

Poslovno pravilo, poslovna politikaposlovno pravilo - instrukcije i logika koji određuju proceduru obavljanja procesa

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

poslovna politika – skup poslovnih pravila• u većini organizacija podloga za donošenje odluka

Primjer: subvencioniranje studentske prehraneOvisno o evidentiranoj razini prava, studenti imaju dnevno dozvoljeni iznos cijene konzumirane hrane koji je subvencioniran. Taj iznos ne predstavlja dnevno ograničenje, već se svakog prvog u mjesecu dodjeljuju prava za čitav mjesec kojima student raspolaže po želji. Mjesečni iznos raspoloživ za subvenciju jednak je umnošku 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 raspoloživo za subvenciju 16.70 * 31 = 517.7 Kn. Iznos raspoloživ za subvenciju se akumulira tijekom čitave akademske godine što znači da se neiskorištena prava iz jednog mjeseca prebacuju na slijedeći. Na kraju akademske godine akumulirani iznos se briše.Za ostvarivanje bilo koje razine prava veće od 1, potrebno je …Da bi student prvog u mjesecu stekao novi dozvoljeni subvencionirani iznos, moraju biti ispunjeni uvjeti: …


Modeliranje funkcija

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

0 The System

1 A Function of the System

1.1 Activity of the Function

Task 1.1.3

1.2 Another Activity of the Function

Task 1.1.1 Task 1.1.2

Task 1.2.2

Task 1.2.1

2 Another Function of the System

2.1 Activity of this Function

Task 2.1.1

Task 2.1.3 Task 2.1.4

Task 2.1.2

2.2 Another Activity of this Function

Task 2.2.1

Task 2.2.3

Task 2.2.2

0 The System

1 A Function

2 Another Function

1.1 Activity of the

Function

1.2 Another Activity of the Function

Task 1.2.2

Task 2.1.1Task 1.1.1

Task 1.1.2

Task 1.1.3

Task 1.2.1

2.2 Another Activity of this Function

2.1 Acivity of this

Function

Task 2.1.2

Task 2.1.3

Task 2.1.4

Task 2.2.1

Task 2.2.2

Task 2.2.3


Dijagram dekompozicije funkcija

Dijagram funkcionalne dekompozicijeeng. Functional Decomposition Diagram (FDD)ista notacija koristi se za razlaganje bilo koje hijerarhijske strukture pa se često zove samo Dijagram dekompozicije ili Mapa hijerarhije

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

Funkcija

Proces


Dijagram dekompozicije funkcija

Primjer, dijagram funkcija za jedan sustav/podsustav:

MARKATONE

ProdajaNabava Knjigovodstvo

Evidenti ranjedobavljača

Prodajarobe

Evidenti ranjekupaca

BrisanjeDodavanje Ažuriranje

Naručivanjerobe

Otpremarobe

Izradaotpremnica

Izradanarudžbi

Zaprimanjerobe

Knjiženje Fakturiranje


Hijerarhijski prikaz funkcija/procesa

Izrada globalnog modela funkcija može započeti izradom hijerarhijske liste funkcija po pojedinim organizacijskim cjelinama.Primjer:

NABAVA• Evidentiranje dobavljača• Nabavka robe

– Izrada narudžbi– Zaprimanje robe

UPRAVLJANJE OSOBLJEM• Evidentiranje službe

– Zaprimanje u službu– Praćenje službe

» redovan rad» prekovremeni rad» bolovanje» godišnji odmori

– Otpuštanje iz službe• Obračun plaća


Izrada dijagrama dekompozicije

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

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

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

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


Dijagram dekompozicije procesa

Primjer, stablo procesa (Process Node Tree Diagram)USED AT: AUTHOR: Norm Wold DATE:

REV:PROJECT: Reengineering Quil lComputers, Inc.

05.09.199709.11.2000

NOTES: 1 2 3 4 5 6 7 8 9 10

WORKINGDRAFTRECOMMENDEDPUBLICAT ION

READER DAT E CONTEXT:

A-0

TOP

NODE: T ITLE: NUMBER:Process Node Tree DiagramA0

USED AT: AUTHOR: Norm Wold DATE:REV:PROJECT: Reengineering Quil l

Computers, Inc.

05.09.199709.11.2000

NOTES: 1 2 3 4 5 6 7 8 9 10

WORKINGDRAFTRECOMMENDEDPUBLICAT ION

READER DAT E CONTEXT:

A-0

TOP

NODE: T ITLE: NUMBER:Process Node Tree DiagramA0

0$8,207,581

OperateQUILL

Business

1$1,103,222

Sell &Market

Products2$690,235

DesignConf iguration

3$628,802

PlanProduction

4$3,540,136

AssembleProduct

5$1,412,889

Store &Ship

6$832,297

Prov ideCustomerSupport

ManageAdv ertisingTake OrdersProv ide PricingInf ormationDev elopDocumentationPrepare WorkTicket

Identif yVendors &ComponentsDev elopSpecif icationsSpecif yComponentsTestConf igurationApprov eVendors

Order AssemblyComponentsIssue WorkTicketManageComponentInv entoryScheduleProductionDisposeOutdatedComponent Parts

PopulateMotherboardsAssembleConf igurePerf orm FinalTestTroubleshoot& RepairPrepareOrder f orShipment

Receiv e &StoreComponentsPick OrderItemsPackageOrderShipReturnDef ectiv eParts

Answer SupportInquiriesTrace Order &Specif icationsRun D iagnosticsProv ideSolutionsManageReturns


Dijagram organizacije

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


Modeliranje poslovnih procesa i funkcijaBusiness Process Modeling (IDEF0)

tehnika strukturirane analize i dizajna (Structured Analysis and DesignTechnique - SADT®, SofTech, 1960-ih), zamišljena kao inženjerska disciplina za razvoj složenih sustava koji uključuju strojeve i ljudemetoda za oblikovanje poslovnih funkcija

Grafički prikaz poslovnih procesa i angažiranih resursa

proces – niz aktivnosti (funkcija)aktivnost – prikazana ICOM konceptom

• ulaz (I=Input): nešto što se troši u procesu - opcionalan

• upravljanje (C=Control): ograničenje na obavljanje procesa - obvezno

• izlaz (O=Output): rezultat procesa -obvezan

• mehanizam (M=Mechanism): koristi se u procesu, ali se ne troši -opcionalan


Oblikovanje aktivnosti

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

USED AT : AUT HOR: DAT E:REV:PROJECT : Process Orders

05.09.199705.09.1997

NOT ES: 1 2 3 4 5 6 7 8 9 10

WORKINGDRAFTRECOMMENDEDPUBLICATION

READER DAT E CONTEXT :

T OP

New Cus tomerInformation

Payment Verification

OrderPolicy

Cus tomerStatus

PackingSlip

OrderInvoice

Produc tInventory

On-l ineProduc tCatalog

Produc tOrderSystem

Cus tomerCreditRecords

Order Number

0

PROCESS ORDERS

Compare this viewpoint with theOrdrProd.bp1 fi le. T his is an


Oblikovanje aktivnosti

Dekompozicija aktivnostiUSED AT: AUTHOR: DATE:

REV:PROJECT: Process Orders05.09.199705.09.1997

NOTES: 1 2 3 4 5 6 7 8 9 10


READER DATE CONTEXT:

A-0

NODE: TITLE: NUMBER:PROCESS ORDERSA0

ProductInventory

OrderPolicy

ProductOrderSystem

On-lineProductCatalog

CustomerStatus

CustomerCreditRecords

Packing Slip

NewCustomerInformation

Order Invoice

PaymentVerification

ProductRequest(s)

AvailableProducts

ProductsOrdered

CurrentPer UnitPrices

QuantitiesOrdered

FinalizedOrderInformation

POS(OrderModule)

POS(OrderModule)

POS(CreditModule)

Order Number

1

TAKE CUSTOMERORDER

2

CHECKPRODUCT

AVAILABILITY

3

DOCUMENTORDEREDPRODUCTS

4

DETERMINEPAYMENTMETHOD

5

PROVIDEORDER

VERIFICATION

Viewpoint: Order ClerkScope: New Customer Orders


Razrada poslovnih procesa

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

Tehnike modeliranjau širinu - svaki dijagram se detaljizira prije dekomponiranja (breadth-first)u dubinu - identificira se hijerarhija, a zatim se detaljizira (depth-first)

Razina dekompozicije (Kada stati)postupak se provodi do dubine dovoljne za razumijevanje modela (!?)napredak do stanja u kojem ulazi i izlazi prevladaju na dijagramunastavak se može provesti

• oblikovanjem tokova procesa (IDEF3) ili • oblikovanjem tokova podataka (DFD)

» Napomena: pomagala opće namjene, kao što je Visio, podržavaju neke dijagrame formalnih tehnika ali ih različito zovu ili se notacija razlikuje od izvorne (grupe dijagrama Business Process i Flowchart, npr. IDEF0, Cross Functional FlowChart)


Modeliranje toka procesa

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

• poslovna politika i poslovne procedure• preoblikovanje poslovnih procesa• modeliranje scenarija kojima se odgovara na pitanja "što-ako"


Modeliranje toka procesa

Veze između funkcija– prethođenje - prethodna aktivnost mora završiti da bi slijedeća započela– tok podataka - izlaz prethodne jest ulaz u slijedeću aktivnost– relacijska - povezivanje uz korisnički definirani uvjet

Prijelazi, spojišta (junction)& (logički I) - svaka povezana aktivnost uvijek se obavlja / završavaX (ekskluzivno ILI) - obavlja se samo jedna od povezanih aktivnostiO (ILI) - obavlja se jedna ili više povezanih aktivnosti


Primjer toka procesa

Primjer, provjera narudžbeUSED AT: AUTHOR: Bob Saunders DATE:

REV:PROJECT: It's not jus t IDEF anymore.06.05.199922.10.1999

NOTES: 1 2 3 4 5 6 7 8 9 10

WORKING

DRAFT

RECOMMENDED

PUBLICATION


A42

CustomerEnquiry /Order

No

No

Yes

Yes

Yes

No

Yes

Accounts tatusChange

No

A422.1.11

$0.00Cutsomer

Places Order

A422.1.12

$0.00Is Customer

Credit Wor thy?

A422.1.14

$0.00

Notify sales

A422.1.15

$0.00

Sourceelsewhere?

A422.1.13

$0.00Fulfill from

stock items?

A422.1.17

$0.00

Is s tock available?

A422.1.18

$0.00

Accept order

A422.1.16

$0.00

Rejec t Order


Primjer toka procesa

Primjer, modeliranje scenarijaUSED AT : AUT HOR: Norm Wold DAT E:

REV:PROJECT : Reengineering Quil lComputers, Inc .

06.11.200009.11.2000

NOT ES: 1 2 3 4 5 6 7 8 9 10


READER DAT E CONT EXT :

A12

original

true

false

true

false

1

$0CheckCredit

2

$0

Check CCN

3

$0

Check Dunn& Bradstreet

4

$0Pass CCN

Check

6

$0Fail CCN

Check

5

$0Pass D&B

7

$0Fail D&B

8

$0Set Credit

Rating High

9

$0Set CreditRating Low

&J1

XJ2

XJ3

&J4

&J5

CCN

Dunn &Brads treet

Customer

Bad CreditList


Dijagram aktivnosti

Activity Diagramtehnika za oblikovanje procedura koja se najčešće koristi u projektiranju objektnim pristupom.


Dijagram aktivnosti

Primjer dijagrama aktivnosti


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

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

sinonimi: transformacijski graf, mjehurasti graf, mjehurasti dijagram (Bubble Chart)

Tehnika se primjenjuje pri razvoju aplikacija, otkuda je i poteklaNe može se koristiti za opis programske logike, opis promjene stanja, izradu upravljačkih specifikacija ili dizajn korisničkog sučelja!!!

Koristi se pri modeliranju poslovnih procesadaljnja razrada IDEF0 IDEF3 (zavisnost procesa) ili DFD (tok informacija)

Spremištepodataka

Tokpodataka

Proces

Vanjski entitet

Tokmaterijala

a

Vanjskientitet

P1

Proces

D1Spremištepodataka

Tok podataka

Tok materijala


Elementi dijagrama toka podatakaTok podataka (data flow)

predstavlja skupove podataka koji se kreću kroz sustavtokovi ulaze u procese (ulazni), koriste se i mijenjaju tijekom obavljanja procesa (ulazno/izlazni) ili nastaju kao rezultat procesa (izlazni)tokovima se pridjeljuju jedinstveni nazivi oblika imenica ili pridjev+imenica, npr. Potvrđena prijavnica, Izlazni račun

Procespredstavlja aktivnost pretvorbe podataka (ulaznog u izlazni tok podataka)procesi se imenuju glagolskim izrazima oblika infinitiv+objekt (npr. Prijaviti ispit) ili glagolskom imenicom (npr. Prodaja, Prijava ispita)nazivom treba izraziti što proces obavlja, to jest treba izbjegavati općenite nazive (npr. Obavljanje računovodstvenih poslova) opis procesa sadrži opis aktivnosti (algoritam) njegovog djelovanja

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

Vanjski entitet (external entity, external agent)

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


Izrada dijagrama toka podatakaDekompozicija procesa

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

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


Izrada dijagrama toka podataka

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

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

P0

Videoteka

e

Osoba

b

Dobavljač

d

Član

IdentifikacijaNarudžba

Video

Članska karticaNovi video

Članska karticai plaćanje

Upit

Zahtjev zarezervaciju

Zahtjev zaidentifikaciju

Rezultat upita



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



Pregledni dijagram, određivanje dosega

e

Osoba

d

Član

P1

Upisatinovog člana

D1 Član

P2

Posuditivideo

D2 Posudba

D3 Video

D4 Rezervacija

P4

Rezervirativideo

P3

Vratitivideo

P6

Nabavitivideo

P5

Tražitivideo

b

Dobavljač


Posudba

Video

Članska karticai plaćanje

Identifikacija

Članska kartica

Posudba

Rezervacija

Rezervacija

Video

Novi videoNarudžba

Video

Posudba

Video

Član

Rezultat upitaUpit

Zahtjev zarezervaciju


Izrada dijagrama toka podatakaRazrada

za svaki proces s preglednog dijagrama identificirati podaktivnostina primjer, za proces Upisati novog člana:

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

Ponavljati postupak za svaki od procesa na poddijagramuuspostaviti razinu detalja slijedeći “pravilo 7±2”provjeriti potpunost i ispravnost modela

Model obrazložiti korisniku a zatim ga ažurirati po potrebiDubinu i uravnoteženost modela teško je odrediti.U praksi to može značiti doradu dijagrama u većem broju ponavljanja, čak i kada dijagrame rade iskusni analitičari!!!

P1.1

Zatražitiosobne podatke

D1 Član

P1.3

Izraditičlansku karticu

P1.4

Evidentiratinovog člana Član Članska karticaČlan

Osobni podaci


Identifikacija


Pravila i ograničenja prilikom izrade DTP

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

Ograničenja i posebni slučajeviSvi objekti modela moraju biti povezani. Nepovezanost pojedinih objekata ukazuje na nepotpunost modela, na primjer:

• postojanje procesa bez ulaza i/ili izlaza (tzv. čuda i crne rupe) • izlaze za koje ne postoji dovoljno ulaza (tzv. sive rupe – najčešće)• postojanje nepovezanih spremišta ili vanjskih entiteta

Ne dozvoljava se neposredna povezanost:• vanjskih entiteta• spremišta• spremišta i vanjskog entiteta

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


a

b b

ca

b b

c

Preporuke za izradu DTP

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

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

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

procese koji ne obavljaju pretvorbu podataka• ako je izlazni tok jednak ulaznom

– treba preimenovati jedan od tokova ili– treba obaviti prespajanje tokova

• primjer:

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


Metode koje koriste DTP

NotacijeGane/Sarson (korištena u primjerima)

Yourdon/DeMarco

SSADM

Proširenja modelaokidač (trigger) - prikaz učestalosti procesa (npr. tri puta dnevno)posebni simboli za prikaz ponavljanja procesarazdvajanje i spajanje tokova (alternativni tokovi) posebni simboli za tok resursa, tok dokumenata ili tok upravljanja (npr. različite linije ili ikone)

a

Vanjskientitet

P1

ProcesD1

Spremištepodataka

Ulazni tok Izlazni tok

Vanjskientitet

1

Proces Spremištepodataka


aVanjskientitet

1

ProcesD1

Spremištepodataka



Opisivanje podataka

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

• prvotno se pojavio kao proširenje dijagrama toka podataka, za pohranu opisa spremišta podataka i tokova podataka

• može se koristiti kao alternativna tehnika za prikaz modela podatakastandardno se upotrebljava BNF notacija (Backus-Naur Form), koja se inače koristi za opis sintakse programskih jezika

Najmanja logička cjelina podataka

Grupe sačinjene od podatkovnih elemenata

Grupe sačinjene od struktura podataka

Podatkovnielement

Spremištepodataka

Tokpodataka

Strukturapodataka


Definiranje podataka BNF notacijom

Notacija

Primjer, račun i stavke računa

Može se napisati i kao:

= struktura s lijeva sastoji se od dijelova s desna ("sastavljeno od") + agregacija elemenata (logičko I) ( ) opcionalnost elemenata u zagradi (0 ili 1) {} ponavljanje (iteracija) elemenata u zagradi, ni jednom do konačni broj puta [] alternativa (selekcija) elemenata u zagradi | odvajanje alternativnih elemenata u [] izrazu - počena i završna vrijednost raspona definiranog [] izrazom

** komentar @ oznaka ključa

Racun = @BrRac + DatRac + BrKupca+ { SifArt, NazArt, Cijena, Kol, Vrijednost }+ (IznosRac)

Racun = @BrRac + DatRac + BrKupca+ { StavkaRac }+ (IznosRac)

StavkaRac = @SifArt, NazArt, Cijena, Kol, Vrijednost144FER-ZPM-GRZ, Fertalj & Kalpić: Projektiranje informacijskih sustava, akad.god. 2006/07.

Elementarni procesi

Mini-specifikacije (funkcionalne primitive)specifikacije za opisivanje osnovnih procesa u dijagramu toka podatakamogu poprimiti različite oblike, ali imaju nekoliko zajedničkih 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 procesasadrži algoritam zadatka koji se procesom obavlja, koji može poprimiti različite oblike ( dizajn programa - opis programske logike)na temelju ovog algoritma može se, ovisno o alatu, generirati kôd

Mini-specifikacije kreira korisnik CASE pomagala. Budući 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: Provjera raspoloživosti filma

Opis: Provjera da li u videoteci postoji kopija filma koja se može iznajmiti

Ulazni tokovi: Upit (Film)RezervacijePosudbe

Izlazni tokovi: Rezultat upita (raspoloživ | nije raspoloživ | ne postoji)

Logika procesa: izračunaj broj kopija traženog filma u videoteciako je broj kopija veći od nule tada

ako je broj kopija veći od (broj posudbi + broj rezervacijarezultat = "Raspoloživ"

inačerezultat = "Nije raspoloživ"

inačerezultat = "Ne postoji"


Definiranje procesa

Primjer definicije procesa (2)

Proces 1: Provjera raspoloživosti filma

Opis: Provjera da li u videoteci postoji kopija filma koja se može iznajmiti

Ulazni tokovi: Upit (Film), Rezervacije, Posudbe

Izlazni tokovi: Film nije raspoloživ, Film je raspoloživ

Logika procesa: izračunaj broj kopija traženog filma u videoteci ako je broj kopija veći od nule tada ako je broj kopija veći od (broj posudbi + broj rezervacija nastavi s P2 (izl. tok Film je raspoloživ) inače ako član želi rezervirati film tada upiši rezervaciju (izl. tok Film nije raspoloživ) inače poruka "Ne postoji"


P2.1

PackageOrder

P2.2

CreateBack Order

D4 Stock

D1 Customer

D2 Order Details

a

Customer

CustomerInvoice

CustomerShipment

UnavailableItems

Ship Address

@BeginHeader@Text File : C:\ECPLUS\SAMPLES\GSDFD\pps21.pps@Linked to symbol : Package Order @on dfd Ship Order (Filename : dfd2.dfd)@---------------------------------------------@OUTPUT DATA FLOW : Customer Invoice @OUTPUT DATA FLOW : Customer Shipment @OUTPUT DATA FLOW : Unavailable Items @INPUT DATA FLOW : Customer Ship Address @INPUT DATA FLOW : Order Details @INPUT DATA FLOW : Stock@---------------------------------------------@EndHeaderTBD

Primjer definiranja procesa jednostavnim CASE alatom

Specifikacija procesa u pomagalu EasyCase


Primjena modela procesa

Strateško planiranje sustavadefiniranje arhitekture sustava u okviru strateškog plana, pri čemu se radi model procesa poduzeća (globalni model procesa)

• identificira poslovna područja i poslovne funkcije• najčešće u formi dijagrama dekompozicije funkcija ili nerazrađenog DTP

(npr. dijagramom konteksta određuju se doseg i sučelja sustava)Reinženjerstvo poslovnih procesa

analiza i restrukturiranje poslovnih procesa radi poboljšanja učinkovitosti i uklanjanja birokratizma, prije primjene informacijskih tehnologijapostojeći procesi se analiziraju i dokumentiraju prikladnim modelima procesa

• dijagrami doka podataka s fizikalnim primjesama, koje uključuju vremensku dimenziju, protočnost podataka i troškove

Analiza sustavaaplikacijski modeli procesa - logički modeli procesa sustava ili aplikacije

• teorijski, moguće je proizvesti DTP povratnim inženjerstvom postojećih aplikacija, ali će takav dijagram biti preopterećen fizikalnim primjesama

Dizajn sustavafizički modeli procesa - dodavanjem upravljačkih komponenti i resursa


Tablični prikaz modela funkcija/procesa

Prikupljanje i sređivanje informacija o funkcijama i procesima može se obaviti s pomoću tablica prije, ali i umjesto izrade dijagrama.

Proces Ulaz (od) Izlaz (prema) Vanjski entitet Spremište Komentar/Algoritam

Izraditinarudžbu

Podaci odobavljaču,Artikli zanaručiti

Ispisananarudžba(dobavljač)

Dobavljač Narudžba,

Dobavljač,

Stavka,

Artikl

Struktura tokova ne morau potpunosti odgovaratistrukturi spremišta

… … … … …

Zaprimanje uslužbu

Zahtjev zaprijam(osoba)

Rješenjezahtjeva(osoba,pismohrana…)

Osoba Osoba, Tijekslužbe

Provjeri zahtjev premaPravilniku ozapošljavanju, pa ispišerješenje


Povezivanje različitih modela

Model poslovnih procesa

Primjeri: \Modeli\ModeliProcesa

Dijagram toka podataka

USED AT: AUTHOR: Bob Saunders DATE:REV:PROJECT: It's not just IDEF anymore.

03.04.199604.11.2002

NOTES: 1 2 3 4 5 6 7 8 9 10

WORKING

DRAFT

RECOMMENDED

PUBLICATION


A0

NODE: TITLE: NUMBER:Manage Order/Enquiry A4

AuthorisedOrder

Product Order

CustomerContracts

Order/EnquiryStatus

CustomerInformation

Credit Worthiness

Enquiry Feasibility(Resources)

ProductSpecificationFeasibility

ProductEnquiry

CustomerEnquiry/Order

CustomerCommunicat ion

GO ProcessManagementInformation

SOP Module

A41$4.00

Manage CustomerQueries

A42$29.90

QualifyCustomer

Order

A43$5.90

Accept/ ReleaseOrder

USED AT: AUTHOR: Bob Saunders DATE:REV:PROJECT: It's not jus t IDEF anymore.

26.01.199822.10.1999

NOTES: 1 2 3 4 5 6 7 8 9 10

WORKING

DRAFT

RECOMMENDED

PUBLICATION


A4

NODE: TITLE: NUMBER:Accept/ Release OrderA43

StockRequirement

AvailableStock

CustomerCommunication

CustomerCommunication

ProductOrder

Allocateds tock

Allocateds tock

AuthorisedOrder

A431$0.00

Accept Order Spec

A432$0.00

Check Stock Available

A433$0.00

Allocate Stock

A434$0.00

Release and Ship Stock1 CUSTOMER

2 ORDER DETAILS

3 PRODUCT

4 STOCK

4CUSTOMER


Primjer dijagrama iz stvarnog projekta


Izrada DTP analizom izjava korisnika"Kemičar ili član osoblja kemijskog laboratorija može podnijeti zahtjev za jednom ili više kemikalija. Zahtjev može biti udovoljen ili dostavom pakiranja kemikalije koja se već nalazila na zalihi kemijskog laboratorija ili upućivanjem narudžbe za novim pakiranjem kemikalije od vanjskog dobavljača. Osoba koja upućuje zahtjev mora imati mogućnost pretraživanja kataloga kemikalija vanjskog dobavljačadok sastavlja narudžbu. Sustavmora pratiti status svakog zahtjeva za kemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Također, mora pratiti povijest svakog pakiranja kemikalija od trena kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbačen."

Kemičar

Osoblje kemijjskoglaboratorija

Odjel zakupovinu

1.podnošenjazahtjeva zakemikalijom

zahtjev za kemikalijom

7.pretraživanje

katalogadobavljača

2.ispunjavanjezahtjeva iz

zalihalaboratorija

6.ažuriranje

stanja zalihalaboratorija

5.generiranjeizvješća o

stanju zaliha4.generiranjeizvješća za

vladu

3.podnošenjezahtjeva zakemikalijom

zahtjev za kemikalijom

inventorij kemijskoglaboratorija

katalogdobavljača

Vladin odjel za sigurnost izdravlje

upit na katalog dobavljača

informacija o katalogudobavljača



zahtjev za informacijom

pakiranjekemikalija

laboratorijskizahtjev

pakiranjekemikalija

zahtjevza kemikalijom

pakiranjekemikalija

novo stanjeinventorija

pakiranjekemikalija novo stanje

inventorija

stanje inventorija

izvješćeo stanju

inventorija

zahjev za dobavljačevomkemikalijom

status dobavljačeve narudžbe

zahjev za dobavljačevomkemikalijomstatus

dobavljačevenarudžbe

izvješće ouporabi

kemikalija zahtijev zaizvješćem o

uporabi kemikalija

podacio promijenamau inventoriju


Primjer: Procesi sustava ISSP

ISSP se može podijeliti na slijedeće funkcionalne cjeline:

Članice sveučilišta i veleučilišta, čiji studenti ostvaruju pravo na subvencioniranu prehranu (ustanove)Restorane koji pružaju uslugu prehrane prehranu članovima ustanove (mjesta troška)Tvrtka zadužena za održavanje i nabavu opreme te tiskanje iskaznica članovaCentar za autorizaciju prava članova (CAP), kao ustanova zadužena za uvođenje i trajno održavanje sustava. U CAP-u se nalazi i središnja baza podataka sustava.

Unutar svake od navedenih cjelina obavlja se više specifičnih procesa koji čine osnovu sustava.

…

P1

Ustanova

P3

Restoran

P2

CAP

P4

Tvrtkaza tiskanje

a

Vlasnik(student)

b

Pokroviteljsubvencije

d

SCi ostali pruzatelj i usluge

Zatrazenakartica

Nova kartica Nova kartica

Vlasnik

Upis godine

Zatrazenakartica

Nova kartica

Zahtjev zaizdavanje kartice

Zahtjev zadokumentaciju

Zahtjev zapromjenu razine prav

Dokumentacija

Kartica

Pregledpotrosnje restorana

Nacinjen racun(dnevnik)

Dozvoljeno zasubvenciju

Kartica Vlasnik

Pregledpotrosnje restorana


Primjer: razrada procesa

Evidencija matičnih podataka članovaObvezni matični podaci studenta su: Ime, Prezime, JMBG, Matični broj (broj indeksa), Razina prava, JMBAGOmogućeno je evidentiranje i ostalih neobveznih podataka …

Evidencija podataka o statusu člana u ustanoviEvidentiran upis godine sadrži podatke o: …

P1.1

Upisnovog vlasnika (studenta)

P1.2

Upisgodine

P1.3

Promjenarazine prava vlasnika

P1.4

Obradazahtjeva za karticu

Upisnil ist

D1 Vlasnik D2 KarticaD3Upisgodine

P1.5

Izdavanjekartice vlasniku

Upisni l ist

Vlasnik

VlasnikKartica

Vlasnik

Nova kartica

Zahtijev zapromjenu razine prav

Zahtjiev zadokumentaciju

Dokumentacija

Vlasnik

Nova kartica

Kartica

Upis godine


Primjer: Sustav skladišnog poslovanja

inte

rna

pov

ratn

ica

Skladišnoposlovanje

p0

a

Dobavljači

d

Kupci

c

Skladišta

bRadnejedinice

nalo

g z

a p

ovra

tar

tikla

predračun/računuplata kupcaulazni račun

narudžba

isplata dobavljaču

povrat artiklaartikli artikli

povrat artikla

artiklipovrat artikla

nalo

g z

a m

eđus

klad

ište

nje

međ

uskl

adiš

nica

skla

dišn

a p

rimka

povr

atni

ca d

obav

ljaču

otpr

emni

capo

vrat

nica

kup

ca

inte

rna

izda

tnic

a

nalo

g z

a p

ovra

t ar

tikla

dob

avljaču

nalo

g z

a in

tern

o iz

dava

nje

arti

kla


Primjer: Osnovni procesiProces izrade ponude vodi služba prodaje. Na zahtjev kupca služba nabave izrađuje ponudu/predračun. Podaci o kupcu dohvaćaju se iz spremišta poslovnih partnera, a artikli i usluge dohvaćaju se iz spremišta artikala i usluga. Izrađena ponuda sprema se u spremište dokumenata, a kopija se ispostavlja kupcu.Račun je dokument koji kao potvrdu podmirivanja potraživanja od kupca izdaje služba prodaje. Račun se izrađuje iz predračuna, sprema se u spremište dokumenata, a kopija se šalje kupcu.Otpremnica kupcu skladišni je dokument na osnovu kojeg se izdaju artikli sa skladišta. Izrađuje se na osnovu računa i sprema u spremište dokumenata.…

a

Dobavljači

d

Kupac

upla

ta

artikl

potvrda opovratu

artik

l

Naruči artikle

p1

Izrada računa

p2

Otpremanjeartikala

p9

Izrada ponude

p4

Povrat artikaladobavljaču

p5

naru

džbe

nica

D1 artikli i usluge

raču

n

uslu

ga

predračun

raču

n

artik

l

D2 poslovni partneri kupac

artikl

doba

vljač

doba

vljač

artikl

artik

l

c

Skladišta

bPoslovnejedinice

D3 poslovne jedinice

Međuskladištenje

p7

artik

l

skla

dišt

e

Interno izdavanje ipovrat artikala

p6

artik

l

poslovnajedinica

međ

uskl

adiš

nica

artik

l

vrač

eni a

rtikl

i

nalog za povrat

prom

jena

kol

ičin

e

međ

uskl

adiš

nica

predračun

otpr

emni

ca

inte

ra iz

datn

ica

povr

atni

ca d

obav

ljaču

skladišna primkanarudžbenica D4 dokumenti

pred

raču

n

inte

rna

pov

ratn

ica

nalog za izdavanje

D5 cijene artikala

cijena

raču

n

zahtjev za ponudu

račun

D7 Stanje skladišta

promjeni količinu

prom

jeni

kol

ičin

u

zapr

imlje

ni a

rtikl

i

Prijem i povratartikala

p8

izda

ni a

rtikl

i

Izrada otpremnice

p3

otpremi artikle

uplate


Dekompozicija procesa narudžbe i prijema artikala

Proces narudžbe vodi služba nabave koja na osnovu praćenja stanja skladišta i potreba na tržištu odlučuje o nabavi artikla. Nabavna služba izrađuje narudžbenicu koja se zatim šalje dobavljaču.Dobavljač na temelju isporučene narudžbenice ispostavlja predračun s naručenim artiklima. Na temelju predračuna nabavna služba izrađuje ulazni račun, a isplatom potraživanja dobavljaču artikli se zajedno s dostavnicom primaju na skladište. Na skladištu se povećava količina te ako je potrebno mijenja se nabavna cijena. Naposljetku, ova poslovna promjena bilježi izradom skladišne primke koja se zatim sprema u spremište dokumenata.

Izraditinarudžbenicu

p1.1

a

Dobavljači

D1 artikli i usluge

D2 poslovni partneri

artik

l

doba

vljač

naruđžbenica

Preuzmi artikl

p1.2

artikl

Izraditi skladišnuprimku

p1.3

Promjenikoličinu

preu

zeti

artik

li

dobavljač ulaz

ni r

ačun

plać

anje

skladišna primka

D4 dokumentinarudžbenica

Izradi ulazni račun

p1.4

Isplati dobavljača

p1.5

dostavnica

dobavljač

ispl

ata

dob

avljaču

ulazni račun

doba

vljač

skladišna primka

rani

je i

spla

te p

o is

tom

ula

znom

rač

unu

D6 nabavne cijene

nabavnacijena

promjenanabavnecijene

D7 stanje skladišta


skladište


Dekompozicija procesa internog izdavanja i povrata artikala

Proces povrata artikala dobavljaču također vodi nabavna služba. Dobavljač na temelju vraćenih artikala izdaje potvrdu o povratu na osnovu koje se izrađuje povratnica dobavljaču. Povratnica dobavljaču sprema se u spremište dokumenata.Interno izdavanje i povrat artikala koristi se kod prijenosa artikala između skladišta i radne jedinice. Proces započinje prijemom naloga. U slučaju internog izdavanja artikala nalog prima skladište koje artikle treba izdati u radnu jedinicu, dok u slučaju internog povrata nalog prima radna jedinica koja treba vratiti artikle u skladište. Naloge za izdavanje u pravilu ispostavlja priprema rada, odnosno referada za otvaranje i praćenje provođenja radnih naloga, poslovođe ili sam vlasnik. Na temelju primljenog naloga izrađuje se interna izdatnica koja se prosljeđuje skladištaru dok se interna povratnica izrađuje se na temelju artikala vraćenih iz radne jedinice.Dokumenti interna izdatnica i interna povratnica dokazuju izvršenu poslovnu promjenu i pohranjuju se u spremištu dokumenata.

D3 poslovne jediniceIzrada interne

izdatnice

p6.1

radna jed. nalog

D1 artikli i usluge artikl

Izrada internepovratnice

p6.3

izdani artikli

Interni povrat

p6.4

inte

rna

pov

ratn

ica

artikl

promjena količine artikla

internaizdatnica

internapovratnica

D4 dokumenti

D6 nabavne cijene

bRadnejedinice

c

Skladišta

interna izdratnica

nalo

g

skla

dišt

era

dna

jedi

nica

skladište

cijena

cije

na

Zaprimanje naloga

p6.2

nalo

g

vračeni artikli

prom

jena

kol

ičin

e

Prijem i povratartikala

p8

D7 stanje skladišta


Dekompozicija procesa međuskladištenja artikala Međuskladištenje artikala koristi se kod prijenosa artikala između dva skladišta unutar istog poduzeća, a proces međuskladištenja prate dvije međuskladišnice – po jedna za svako od skladišta. Skladište koje daje artikle prima od poslovođe ili vlasnika nalog za međuskladištenje na osnovu kojeg izdaje artikle. Izdavanjem artikala njihova se količina na skladištu smanjuje, a kao dokaz izvršene poslovne promjene izrađuje se dokument međuskladišnica.Drugo skladište zaprimanjem artikala prima i međuskladišnicu potvrdom koje potvrđuje primljene količine.Skladište koje prima artikle na osnovi primljenih artikala također izrađuje međuskladišnicu.

D1 artikli i usluge

c

Skladišta


Izdavanje artikla

p7.2

primljeni artikliPrijem artikla

p7.3

Izradameđuškladišnice

p7.1

skladište koje prima artikleartikl

izdani artikli

međuskladišnica

međ

uskl

adiš

nica

D4 dokumenti

D6 nabavne cijene

nalo

g

skladište koje daje artikle

cijena

izda

ni a

rtikl

i

skla

dišt

e k

oje

prim

a a

rtikl

esk

ladi

šte

koj

e d

aje

arti

kle

Izradameđuškladišnice

p7.4

prim

ljeni

arti

kli

artik

l

cije

na

promjena količineartikla na skladištu

koje daje

promjena količineartikla na skladištu

koje prima

D7 Stanje skladišta

izda

ni a

rtikl

i

Modeliranje podataka


Modeliranje podataka

Modeliranje podataka (Data modeling)tehnika organiziranja i dokumentiranja podataka sustavasinonimi:

• modeliranje baze podataka (podaci se najčešće pohranjuju u BP)• modeliranje informacija (općenitije)

(po mnogima) najvažnija tehnika oblikovanja• podaci su resurs koji se dijeli između većeg broja procesa i zbog toga

moraju biti organizirani na način koji je prilagodljiv poslovnim zahtjevima kreativnost

• strukture podataka i njihova svojstva su trajniji i stabilniji od procesa• modeliranje podataka završava brže nego modeliranje procesa

– modeli podataka brže se približavaju rezultatu nego modeli procesa– modeli podataka su bitno manji od modela procesa i objektnih modela

• modeli podataka postojećeg i budućeg sustava međusobno su sličniji nego modeli procesa postojećeg i budućeg sustava, ili ih je lakše preoblikovati, pa se manje posla “baca”

• dobra komunikacija s korisnicima, utvrđivanje nazivlja• lakše određivanje definiranje dosega projekta • ...


Dijagram entiteti-veze

Dijagram entiteti-vezeeng. Entity-Relationship Diagram, ERDnaziva se još i dijagram objekti-veze (izbjegavati!)postoje različite notacije, npr. Chen, Martinosim osnovnih, koriste se i prošireni modeline postoje jednoznačni standardi postupka izrade

Mjesto

Osoba Zaposlen

OdnosiSeNa

OrgJedStanuje

Zanimanje

StavkaRacuna

Proizvod

Proizvodi

Igla Avion

Sastav

Pripada

ES

SuradnikDjelatnik

NS

Racun

RacStRac

1,N

1,N1,N0,N

1,1

0,M

1,1

0,N

0,N

0,1 0,1

0,M

Cjelina

0,N

Dio

0,1

NadJed

0,NPodJed

1,1

0,1 0,N

1,1

1,1

0,N

1,1

1,N


Entiteti

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

Entitet može biti: osoba, npr. Kit Karsonobjekt, npr. video traka Prohujalo s vihoromapstraktni pojam, npr. hrvatski jezik ili iskustvo (poznavanje jezika)ustanova (FER), organizacija (Hotel Proljeće) ili organizacijska cjelina (Ured za istraživanje ruda i gubljenje vremena)događaj (situacija, stanje) - prošli, sadašnji ili budući, npr. rođenje, školovanje, zaposlenje, smrtpovezanost različitih objekata stvarnog svijeta, npr. srodstvo


Entiteti

Pojedinačne pojave (instance) grupiraju se u skupoveovisno 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 može poistovjetiti pojam entitet sa skupom entiteta, ako se ne razmatraju konkretni podacioznačava se imenicom (u jednini) Osoba, Fakultet

Entiteti mogu poprimiti različite uloge ovisno o kontekstuprimjer: Osoba je Kupac i/ili Dobavljač, Student ili Nastavnik


Atributi i domene

Atributatribut predstavlja neko obilježje, značajku entiteta

• sinonimi: svojstvo (property), element, polje (field)• pojedinačne vrijednosti atributa pohranjuju se u bazu podataka → elementarni

podatak (data element, data item)po vrijednostima koje predstavljaju, atributi mogu biti:

• jednostavni atributi (simple attribute) - vrijednost atributa je pojedinačni podatak, – primjer: Prezime, Ime

• složeni, sastavljeni atributi (compound/composite/concatenated attribute, datastructure) - vrijednost je uređena n-torka ili logička grupa jednostavnih atributa,

– primjer: datum = (dan, mjesec, godina)• višeznačni atributi (multivalued attribute) - atributi koji predstavljaju ponavljajuće

grupe podataka, to jest atributi s više istovrsnih vrijednosti– primjer: Osoba.Telefon = (TelefonNaPoslu, TelefonKodKuce, MobilniTelefon)

s obzirom na pohranu vrijednosti, atributi mogu biti:• atributi pohrane (stored attribute)• izvedeni atributi (derived attribute) - vrijednost im se može odrediti na temelju

vrijednosti drugih atributa– primjer: starost = (DanašnjiDatum-DatumRođenja)


Atributi i domene

Vrijednosti atributa definirajutip podatka, domena i pretpostavljena ili standardna vrijednost (default)

Tipovi podatakanetehnički (logički)

• opći tipovi koji se koriste u sistem analizi i pri prikupljanju zahtjeva• primjeri: broj, datum-vrijeme, znakovni niz, tekst, BLOB

tehnički• generički tipovi podataka koji se mogu preslikati u konkretne tipove, npr.

integer, character• konkretni tipovi SUPB, npr. char, int, byte (SQLserver)

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


Identifikatorosobe

(IdOsobe)

Prezim e(Prezim e)

Im e(Im e)

Adresa(Adresa)

Šifra m jesta(SifMjesta)

8746 Karson Kit Melrose place 666 … 03837528 Ford Alan Vukovar avenue 63 …1164 Rock Bob … 001765 Ford Kit Sunset boulevard 2958 … 282

8746375281164

...

FordKarsonRock

...

AlanBobKit...

Melrose place xxSunset boulevard 2958

Vukovar avenue 63...

Atributi i domene

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

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

skup vrijednosti može se definirati • tipom podatka, npr. integer• podskupom vrijednosti tipa podatka, npr: formula AA99, interval [10-99]• skupom konstanti, npr. Spol = { M, Ž }


Ključevi

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

• mora se sastojati od bar jednog atributa → jednostavan ključ– primjer: OSOBA = @JMBG + Prezime + Ime …– primjer: MJESTO = @ŠifraMjesta + NazivMjesta ...

• može se sastojati od više atributa → složeni, sastavljeni, ulančani ključ– primjer: MJESTO = @ŠifraDržave+@ŠifraMjesta

ključ mora zadovoljavati sljedeće uvjete• jednoznačnost (u skupu entiteta ne smiju postojati dvije pojave s istim

vrijednostima svih ključnih atributa)– primjer: ne smiju postojati 2 osobe s JMBG=020946330097

• minimalnost (ne postoji podskup atributa ključa koji je također jednoznačan)– primjer loš: OSOBA = @JMBG + @Prezime ...– primjer dobar: TEČAJ = @KraticaValute + @DatumTečaja + ...

• određenost - postojanje vrijednosti u trenutku stvaranja instance• stabilnost - otpornost na promjene tijekom vremena• raspoloživost - dostupnost svim korisnicima• neutralnost - s obzirom na značenje vrijednosti ključa (samogovoreće šifre)


Ključevi

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

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

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

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

– primjer: Osoba.JMBG, Mjesto.PostBr

ponekad je potrebno identificirati podskupove entiteta• kriterij podskupa (subsetting criteria) – atribut (jednostavni ili ulančani) s

konačnim skupom vrijednosti za grupiranje instanci entiteta u podskupove, u nekim metodama naziva se inversion entry ne-jedinstveni indeks


Ključevi

Strani ključ (foreign key)skup atributa koji se odnosi na ključ drugog skupa entiteta, tj. skup atributa čije se vrijednosti odnose na vrijednosti ključa drugog entiteta (Osoba.SifMjesta odnosi se na Mjesto.SifMjesta)

Identifikatorosobe

(IdOsobe)

Prezime(Prezime)

Ime(Ime)

Adresa(Adresa)

Šifra mjesta(SifMjesta)

8746 Karson Kit Melrose place 666 … 03837528 Ford Alan Vukovar avenue 63 …1164 Rock Bob … 001765 Ford Kit Sunset boulevard 2958 … 282

Šifra mjesta(SifMjesta)

Poštanskibroj

(PostBr)

Naziv mjesta(NazMjesta)

038 10000 Zagreb001 20000 NewYork282 30000 Los Angeles


Ključevi

Strani ključ• ukazuje na povezanost između entiteta, odnosno skupova entiteta

– može poprimiti vrijednost primarnog ključa drugog entiteta ili– može poprimiti nul-vrijednost (null value)

• primjer:– Osoba.SifMjesta odnosi se na Mjesto.SifMjesta, odnosno– Entitet Osoba (IdOsobe=8746) ima SifMjesta=038, tj. referencira entitet

Mjesto s IdMjesta=038 Nul-vrijednost

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

• nul-vrijednost nije 0 (nula) niti “” (prazan znakovni niz)Primjer:

• Osoba (IdOsobe=37528) boravi u nepoznatom mjestu, pa joj je SifMjesta nedefinirana vrijednost

• Vozilo (tipa osobni automobil) nepoznatog registarskog broja, naspram vozila (tipa tenk) koje se ne registrira na isti način


Elementi dijagrama Entiteti-Veze

Primjer, atributi i ključevi u oglednom modelu

Mjesto Osoba

SifMjesta PostBr IdOsobeNazMjesta Prezime

SifMjesta

Adresa

Staz

Ime

Telefon


Veze

Veza (relationship)pokazuje odnos između entiteta

• analogno entitetima, pojedinačna veza uspostavlja se na razini instanci entiteta, a veze se grupiraju u skupove veza (relationship sets)

– kada se ne razmatraju instance, pojam veza podrazumijeva skup vezamože izražavati 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 OsobaStanujeStanovnikMjestoStan


Veze

Stupanj veze (degree of relationship)broj entiteta koji sudjeluju u veziopćenito, može se povezati bilo koji broj entiteta (oprez!)

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

posebni slučaj jest veza nekog entiteta s tim istim entitetom• veza prvog stupnja → unarna veza (refleksivna, rekurzivna, involucijska) • u nekim metodama smatra se posebnim slučajem binarne veze, to jest

posebnom vezom 2. stupnja


Veze

Tip, klasifikacija veze (type of relationship)označava način pridruživanja pojava entiteta u vezi

• jedan-prema-jedan (1:1)• jedan-prema-više (1:N)

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

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

• donja granica može biti 0, 1, pozitivni cijeli broj ili znak (npr. M) – donja granica = 0 → djelomično, neobavezno (optional) pridruživanje

» ne mora imati niti jednu instancu s druge strane veze– donja granica ≠ 0 → potpuno, obavezno (mandatory) pridruživanje

» mora imati barem neki broj ili općenito M instanci s druge strane veze

• gornja granica može biti 1, pozitivni cijeli broj ili znak (npr. N)» može imati konkretan broj ili općenito N instanci s druge strane veze

veze su dvosmjerne pa se kardinalnost definira za oba smjera veze


Mjesto OsobaStanuje0,N1,1

Veze

Primjer: binarna veza 1:N

Primjer, binarna veza M:N

ProizvodiOrgJed Proizvod0,M 0,N


Osoba Zaposlen OrgJed

Zanimanje

1,N

1,N1,N

Veze

Primjer, ternarna veza

Primjer, unarna veza 1:N i unarna veza M:N

OrgJed Pripada

0,1

NadJed

0,N

PodJed

Proizvod Sastav

0,N

Dio

0,M

Cjelina


Specijalizacija/Generalizacija

Specijalizacija/Generalizacijatakozvana "jest" veza (“is a” relationship)veza koja opisuje posebne slučajeve u nekom skupu entiteta, to jest odnos nekog entiteta (nadtip) i njegovih posebnosti (podtip)podređeni entiteti stvaraju se na temelju njima nadređenog entiteta u kojem dijele zajedničke atribute

• nadtip (supertype) - sadrži zajedničke atribute i predstavlja generalizaciju podređenih entiteta

• podtip (subtype) - sadrži samo njemu svojstvene atribute i predstavlja specijalizaciju nadređenog entiteta


Specijalizacija/Generalizacija

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

• neekskluzivna - Osoba jest Djelatnik ili Suradnik, ali u isto vrijeme može biti i Djelatnik i Suradnik

• ekskluzivna - Proizvod jest Igla ili Avion, ali ne može istovremeno biti i Igla i Avion

Osoba

Djelatnik

NS

Suradnik

0,1 0,N

1,1

ES

Proizvod

Igla Avion

0,1 0,1

1,1


Jaki i slabi entiteti

Jaki i slabi entitetiJaki entitet - entitet koji postoji (egzistira) samostalno,nezavisan/dominantan entitet, pr. Mjesto

Slabi entitet (weak entity) – postoji samo ako postoji jaki entitet u vezi, zavisan/podređen entitet

• egzistencijalno slab entitet - entitet koji ne postoji samostalno → entitet sa stranim ključem (pr. Osoba)

• identifikacijski slab entitet - entitet koji se ne identificira samostalno →entitet koji nema vlastiti ključ, nego se njegov ključ tvori od ključa 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.


Primjer, egzistencijalno slab entitet Osoba

Primjer, identifikacijska veza i identifikacijski slab entitet

Primjer, podtipovi: Djelatnik, Suradnik, Igla, Avion

Mjesto OsobaStanuje0,N1,1

Jaki i slabi entiteti

StavkaRacunaRacun RacStRac1,1 1,N


Nespecifične, neodređene veze

Asocijativni entitet (Gerund)• konkatenirani entitet (concatenated entity), • kompozitni entitet (composite entity)

binarna veza M:N, npr. Proizvoditernarna veza ili veza stupnja >3, npr. Zaposlenveza o kojoj se želi pohraniti podatke (veza s opisnim atributima), pr. Sastav

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

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


Proizvod Sastav BrDijelova

0,N

Dio

0,M

Cjelina Osoba Zaposlen OrgJed

Zanimanje

DatPoc DatZav

1,N

1,N1,N


ERD notacija - Chen

Primjer, dijagram modela poduzeća (Chen)Mjesto

Osoba Zaposlen

OdnosiSeNa

OrgJedStanuje

Zanimanje

StavkaRacuna

Proizvod

Proizvodi

Igla Avion

Sastav

Pripada

ES

SuradnikDjelatnik

NS

Racun

RacStRac

1,N

1,N1,N0,N

1,1

0,M

1,1

0,N

0,N

0,1 0,1

0,M

Cjelina

0,N

Dio

0,1

NadJed

0,NPodJed

1,1

0,1 0,N

1,1

1,1

0,N

1,1

1,N


ERD notacija - Martin

Primjer, dijagram modela poduzeća (Martin), doseg, podsustavi

Mjesto

Osoba OrgJedZaposlen

Suradnik

Proizvod

Zanimanje

Igla AvionDjelatnik StavkaRacuna

Racun

Stanuje

Pripada

Sastav


Izrada ERD analizom izjava korisnika"Kemičar ili član osoblja kemijskog laboratorija može podnijeti zahtjev za jednom ili više kemikalija. Zahtjev može biti udovoljen ili dostavom pakiranja kemikalije koja se već nalazila na zalihi kemijskog laboratorija ili upućivanjem narudžbe za novim pakiranjem kemikalije od vanjskog dobavljača. Osoba koja upućuje zahtjev mora imati mogućnost pretraživanja kataloga kemikalija vanjskog dobavljačadok sastavlja narudžbu. Sustavmora pratiti status svakog zahtjeva za kemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Također, mora pratiti povijest svakog pakiranja kemikalija od trena kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbačen."

Inventorijkemijskoglaboratorija

Pakiranje kemikalija

Zahtjevza kemikalijom

Kemikalija

Zahtijevač

DobavljačevkatalogPovijest pakiranja

kemikalija

pohranjuje

1

M

ispunjava

M

1

popisuje

M

M

zahtijeva

1

M

opisuje

M

Msadrži

M 1

prati

1

1

Razvoj modela podataka


Razvoj modela podataka

Razvoj modela podatakaGlobalni model podataka (enterprise data model)Model konteksta (context data model)Model s definiranim ključevima (key-based data model)Model s potpuno određenim atributima (fully attributed data model)Potpuno opisani model (fully described data model)

Kategorije entitetaosnovni, 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)


Konceptualni model podataka

Globalni model podatakapodatkovni model poduzeća (enterprise data model) u fazi planiranjakonceptualni model entiteti-veze koji najčešće sadrži neodređene veze i nerazrađene kategorije podataka, a pojedine veze mogu i nedostajatidefinira mogući doseg sustava i ukupne informacijske potrebe

Model konteksta podatakana početku analizekonceptualni model koji sadrži samo one entitete koji će biti obuhvaćeni tehničkim rješenjem aplikacijski model podataka rafinira doseg bez detalja o entitetima ili detalja o poslovnim pravilimaERD s entitetima i vezama (često nespecifičnim), bez atributa ili samo s osnovnim atributima

• obične veze, tj. veze tipa 1:N– npr. "račun ima više stavki"

• veze višeg stupnja– npr. “zaposlenje osobe u org. jedinici na radnom mjestu” → Zaposlen

• izbjegavati entitete koji se odnose na specifični kontekst ili uloguPrimjeri: Analiza\IdejnoSljeme , prethodni primjeri


Primjer: konceptualni model

TipStrankeTipStranke

Drzava

Šifrarnik država

Mjesto

Jedinica lokalne samouprave (općina ili grad)

OrgJedinica

Organizacijska jedinica (npr. Ministarstvo, Odjel, Odsjek, Područna jedinica)

Osoba

Fizička osoba

RadnoMjesto

Funkcija zaposlenika prema pravilniku o unutrašnjem redu

Zanimanje

Obavljanje srodnih poslova određene struke, kao i drugih odgovarajućih poslova

Zupanija

Jedinica područne (regionalne) samouprave

Stranka

Fizička ili pravna osoba

Kontakt

Telefoni, Mobiteli, Email, URL, Fax itd.

VrstaOrgJed

Šifrarnik vrsta org. jedinica (npr. uprava, odjel, odsjek, PJ, itd.)

Djelatnik

Fizička osoba koja je dio sustava


Logički modeli podataka

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

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

• odgovor na pitanja oblika “mora/može”: “ni jedan” (0), “barem jedan” (1), “više”(N) → donja/gornja granica kardinalnosti

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

definiranje generalizacijskih hijerarhija• određivanje specijalizacija, tj. podtipova entiteta

– npr. Igla, Avion• definiranje klasifikacijskog atributa nadtipa (diskriminator podtipa)

– npr. Proizvod.TipProizvoda ∈ { “Igla”, “Avion” }

Model s definiranim atributimadodavanje preostalih opisnih atributaodređivanje podskupova podatakadefiniranje domena, logičkih tipova podataka i standardnih vrijednosti atributa


Primjer: Model s definiranim ključevima


DrzavaRodjenja

MjestoPrebivalistaMjestoRodjenja

Ustanova

NadJedinica

OdgovornaOsoba

SredisteZupanije

NadCjelina

Drzava

SifDrzave

Mjesto

IdMjesta

OrgJedinica

IdOrgJedinice (FK)Osoba

IdOsobe (FK)

RadnoMjesto

IdRadnogMjesta

Zanimanje

IdZanimanja

Zupanija

SifZupanije

Stranka

IdStrankeKontakt

IdOsobe (FK)VrstaKontakta

VrstaOrgJed

TipOrgJedinice

Djelatnik

IdDjelatnika (FK)



DrzavaRodjenja

MjestoPrebivalistaMjestoRodjenjaUstanova

NadJedinica

OdgovornaOsoba

SredisteZupanije

NadCjelina

Drzava

SifDrzave

NazDrzave (IE1.1)KratDrzave

Mjesto

IdMjesta

NazMjesta (IE2.1)TipMjestaPostBrSifDrzave (FK)StariNazMjestaSifMjestaIdNadCjeline (FK)

OrgJedinica

IdOrgJedinice (FK)

NazOrgJedinice (IE1.1)MBR (IE2.1)KratOrgJediniceTipOrgJedinice (FK)MjOrgJedinice (FK)AdrOrgjediniceOpisOrgJediniceIdOdgovorneOsobe (FK)IdNadJedinice (FK)IdUstanove (FK)

Osoba

IdOsobe (FK)

JMBG (IE1.1)Ime (IE3.1)Prezime (IE2.1)RoditeljDatRodjenjaMjRodjenja (FK)DrzRodjenja (FK)MjPrebivalista (FK)AdrStanovanjaSifZanimanja (FK) (IE6.2)IdOrgJedinice (FK)OsobniDokument

RadnoMjesto

IdRadnogMjesta

IdOrgJedinice (FK)NazRadnogMjestaKratRadnogMjestaBrIzvrsiteljaPopunjenoIdSluzbenMjesta (FK)PosloviUvjeti

Zanimanje

IdZanimanja

NazZanimanja (IE1.1)KratZanimanja

Zupanija

SifZupanije

NazZupanije (IE1.1)IdSredistaZupanije (FK)

Stranka

IdStranke

NazStrankeTipStranke

Kontakt

IdOsobe (FK)VrstaKontakta

TekstKontakta

VrstaOrgJed

TipOrgJedinice

OpisOrgJedinice

Djelatnik

IdDjelatnika (FK)

SifDjelatnikaBrojIskazniceKorisnikZaporkaIdStruke (FK)SifSpreme (FK)SvjedodzbaIdZvanja (FK)DrzavniIspitStrucniIspitDatPrvogZaposlenjaStazUkupnoDatZaposlenjaMZOPUStazMZOPUNapomDjelatnikIdRadnogMjesta (FK)

Primjer: Model s definiranim atributima


Dokumentiranje i konverzija modela entiteti-veze

Potpuno opisani modelputpuni opis atributa, logičkih tipova podataka i standardnih vrijednostidodatni opisi: prava pristupa podacima, trajnost podataka (arhiviranje)vremenski najzahtjevniji zadatak, uobičajeno se provodi na kraju, ali može započeti usporedno s izradom modela zasnovanog na ključevima ili definiranjem opisnih atributa

Daljnja konverzija modelaPretvorba modela entiteti-veze u relacijski model podatakaFizičko oblikovanje podataka faza dizajna

• konverzija logičkog u fizički model (shema baze podataka)• normalizacija i prilagodba uslijed tehničkih ograničenja i performanci

Modeliranje podataka treba provesti CASE pomagalomPrimjer: ERwin


Definiranje objekata modela podataka

Definiranje entitetajedinstveni naziv opis - značenje i svrha entiteta, poslovni zahtjevi i ograničenjakratki naziv (kôd) – često potreban zbog ograničenja alata ili jezikakratice (akronimi) – izbjegavati osnovni atributi – atributi ključeva i ostali važni za razumijevanje smisla trag zahtjeva – porijeklo i primjena entitetaovlast (nad meta-podacima), odgovornost (za podatke)

Definiranje vezajedinstveni naziv – glagol, glagolska imenica, Roditelj-Dijete , Rnnznačenje veze – detalji dokumentacijetip – identifikacijske, neidentifikacijske vezemodalitet i kardinalnostključevidiskriminator generalizacije/specijalizacijepravila za očuvanje integriteta pri unosu i brisanju instanci


Definiranje objekata modela podataka

Određivanje ključevaključ jakog entiteta = identifikacijski atributključ identifikacijski slabog entiteta = ključ jakog entiteta i vlastiti atribut pripaziti na ključeve sastavljene od više atributa

• mogući nadomjesni ključevi• atributi ključa koji su ujedno ključevi drugih entiteta upućuju na veze

strani ključevi• migracija primarnog u strani ključ• uklanjanje neodređenosti stranih atributa

Definiranje atributa naziv atributa - jedinstven, s izuzetkom stranih ključevaznačenje atributadomena atributakardinalnost atributaizvedeni atributi (iz različitih instanci) i izračunati atributi (jedne instance) [Inmon 1989, Haeckel & Nolan, 1993]

• derivacijska formula, derivacijska zavisnost [McClure 1993]

Logičko modeliranje podataka


Pretvorba modela E-V u relacijski model

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

Atributi• kardinalnost 0 → opcionalna vrijednost (null)• kardinalnost 1 → zahtijevana vrijednost (not null)• kardinalnost N → višeznačni atribut (npr. Osoba.Telefon)

atribut → atribut, npr. Osoba.Prezime izvedeni atribut → atribut pohrane ili se izostavlja, npr. Osoba.Stazsloženi atribut → atribut (grupiranjem), npr. (dan, mjesec, godina) → datum

Osoba

IdOsobePrezim eIm eAdres aDatRodStaz



višeznačni atribut →• skup odgovarajućih atributa, npr. Osoba.Telefon →

Osoba.TelefonNaPoslu, Osoba.TelefonKodKuce, Osoba.MobilniTelefon• ili• slabi entitet, npr. Osoba.Telefon → Telefon (IdOsobe, VrstaTelefona,

BrojTelefona)

Osoba Telefon1,1 0,N

Telefon

VrstaTelefonaBrojTelefona

Osoba

IdOsobePrezim eIm eTelefonNaPosluTelefonKodKuceMobilniTelefonAdres aDatRodStaz



Ključeviključ→ primarni ključ, npr. Osoba.IdOsobe, Mjesto.SifMjestaalternativni ključ→ indeks nad jedinstvenim vrijednostima (unique index) + oznaka zahtijevane vrijednosti (not null), npr. Mjesto.PostBr

OsobaSKljucemIdOsobePrezim eIm eAdres aDatRodStaz

MjestoSi fMjestaPostBr <AK>NazMjesta



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

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

OsobaIdOsobePrezimeImeSifMjesta <FK1>AdresaDarRodStaz

RacunBrRacDatRacIdOsobe <FK>IznosRac

MjestoSifMjestaPostBr <AK>NazMjesta


OrgJedSifOrgJedNazOrgJedSifNadJed <F K1>



identifikacijski slabi entitet → nasljeđuje 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)

ProizvodSifProizvodaNazProizvodaJedCijenaTipProizvoda


StavkaRacBrRac <FK>Si fProizvoda <FK>JedCi jKolicina

StavkaRacunaBrRac <FK>RbrStRacSi fProizvoda <FK>JedCijenaKolicina


TelefonIdOsobe < FK>VrstaTelefonaBrojTelefona



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 može razmotriti udruživanje 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)



Nespecifične veze → asocijativni entitet + n binarnih veza 1:Nključ asocijativnog entiteta = unija ključeva entiteta spojenih vezom primjer: Zaposlen, Proizvodi, Sastav

Osoba Zaposlen OrgJed

Zanimanje

DatPoc DatZav

1,N

1,N1,N


Proizvod Sastav BrDijelova

0,N

Dio

0,M

Cjelina

SastavSifProizvoda <FK1>SifDijela <F K2>BrDijelova

OsobaIdOsobePrezimeImeSifMjesta < FK1>AdresaDarRodStaz

OrgJedSifOrgJedNazOrgJedSifNadJed < FK1>

ZaposlenIdOsobe <F K1>SifOrgJed < FK2>SifZanim <FK3>DatPocDatZavKoefPlace

ProizvodiSifOrgJed < FK1>SifProizvoda <FK2>


ZanimanjeSifZanimNazZanim



Specijalizacija nadtipa u n podtipova → n binarnih vezanadtip → (jaki) entitet, kojemu se po potrebi određuje klasifikacijski atribut, npr. Proizvod.TipProizvodapodtip → (identifikacijski) slabi entitet, npr. Igla, Avion, Djelatnik, Suradnik


DjelatnikIdOsobe <FK1>BrRadKnjBrTekRac

SuradnikIdOsobe <FK>BrUgovoraBrZiroRacUvjetiSuradnje


IglaSifProizvoda <FK>DuljinaPromjer

AvionSifProizvoda <FK>BrSjedalaDoletKM

Osoba

Djelatnik

NS

Suradnik

0,1 0,N

1,1

ES

Proizvod

Igla Avion

0,1 0,1

1,1


MjestoSifMjestaPostBr <AK>NazMjesta


OrgJedSifOrgJedNazOrgJedSifNadJed <FK1>Zaposlen

IdOsobe <FK1>Si fOrgJed <FK2>SifZanim <FK3>DatPocDatZavKoefPlace Proizvodi

Si fOrgJed <FK1>SifProizvoda <FK2>


ZanimanjeSifZanimNazZanim

IglaSifProizvoda <FK>DuljinaPromjer

AvionSifProizvoda <FK>BrSjedalaDoletKM

SastavSifProizvoda <FK1>SifDijela <FK2>BrDijelova

DjelatnikIdOsobe <FK1>BrRadKnjBrTekRac

SuradnikIdOsobe <FK>BrUgovoraBrZiroRacUvjetiSuradnje


StavkaRacBrRacSifProizvoda <FK>JedCijKolicina


Preporuke za izradu modela podatakaSinkronizacija s modelom procesa

spremišta podataka u modelu procesa su entiteti u modelu podatakaČistoća modela

izbjegavati entitete koji opisuju ugradnju (ulazno-izlazni uređaji, meta-podaci, itd)Provjera modela

pripaziti na sinonime (različite nazive istih objekata)pripaziti na homonime (jednake nazive različitih 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

• uklanjanje veza koje se daju izvesti iz drugih (npr. trijade) - pripaziti na kardinalnost veza u lancu

– primjer: Osoba 0,N:1,1 Mjesto 0,N:1,1 Drzava– naspram Osoba 0,N:0,1 Mjesto 0,N:0,1 Drzava

• ukloniti balansirane veze 1,1:1,1• pripaziti na nebalansirane veze 0,1:1,1 (zavisnost entiteta)• cirkularne reference

izbaciti izvedene atribute• oprez, mogući gubitak informacije o potrebnim izvedenim/izračunatim poljima

Modeliranje događaja


Događaji

Događajzgoda, zbivanje u sustavu koja vodi ili pokreće procese sustavasâm događaj nije proces, nego okidač procesa koji se njime pokrećeprimjer: kupac dostavi narudžbu pokreće proces provjere da li se radi o narudžbi postojećeg ili novog kupca, proces stvaranja podataka o narudžbi i stavkama narudžbe, provjeru prethodnih zaduženja kupca, provjeru stanja skladišta itd.

Vrste događajavanjski događaji – potaknuti od strane vanjskih entiteta, koji zahtijevaju informaciju ili ažuriranje podataka ulazni tokovi podataka

• imenuju se tako da naziv sadrži naziv vanjskog entiteta• primjer: zahtjev za upis studenta ili zaprimanje narudžbe kupca

vremenski događaji - vremenski uvjetovani (rok, učestalost) ulazni upravljački tokovi

• imenuju se tako da naziv sadrži vremensku oznaku• primjer: istek roka plaćanja računa, mjesečni obračun plaća, zaključivanje ispitnog

rokaunutarnji događaji, događaji stanja - posljedica prijelaza sustava iz jednog stanja u drugo, na takav način ta to zahtjeva obradu ulazni upravljački tokovi

• primjer: isporuka robe sa skladišta zahtijeva naručivanje nove robe


Modeliranje procesa vođeno događajimaRaspodjela događaja (event partitioning)1. Izrada dijagrama konteksta sustava

• postavljanje početnog dosega projekta2. Izrada dijagrama funkcionalne dekompozicije

• podjela sustava u logičke podsustave i/ili funkcije3. Izrada popisa događaja i odziva

• utvrđivanje poslovnih događaja na koje sustav mora odgovoriti• element popisa = događaj, ulaz, izlaz

4. Izrada dijagrama dekompozicije događaja• dodavanje procesa za rukovanje događajima (event handler)• dodaje se po jedan proces za svaki utvrđeni događaj

5. Izrada dijagrama događaja• razrada procesa za obradu događaja• po jedan dijagram za svaki svaki događaj

6. Izrada dijagrama sustava• udruživanjem dijagrama događaja

7. Izrada primitivnih dijagrama• razrada dijagramom toka podataka koji sadrži osnovne procese, spremišta i

tokove za svaki pojedini događaj


Modeliranje procesa vođeno događajima

The System

Event 1 Event 5 Event n

Function 1 Function n

. . .Event 1 Event 2 Event 3 Event 4 Event 5 Event n-2 Event n-1 Event n

. . .Function 2

The System

. . .. . .

1

2

4

3

Event-Response List

event 1 response event 2 response response event 3 response response response event 4 response

...

5

Slika: Whitten et.al, Systems Analysis and Design Methods,McGraw-Hill Higher Education, 2000


Modeliranje procesa vođeno događajima

Event 1

Event 3

Event 4

Event n-2

Event n-1

Event 2

Event n

Event 5

2.2

2.1

2.4

2.3

6

7

. . . . . .


Primjer: tablica događaja i procesa


Matrica Entiteti/DogađajiMatrica Entiteti/Događaji

Entity/Event Matrix, Event/Enquiry, Entity Access Matrixpogled na sustav usmjeren događajima (event oriented view)matrica sadrži:

• događaje (retci)• entitete (stupci)• elemente koji prikazuju učinak

događaja na entitete– Stvaranje: C (create)– Čitanje: R (read) - u nekim

metodama se ne bilježi – Ažuriranje: U (update) ili M

(modify)– Brisanje: D (delete)

provjera dovršenosti:• svaki događaj mora imati učinak

na barem jedan entitet• svaki entitet mora imati događaj

koji ga stvara i briše

Primjer: pojednostavnjena rezervacija sobe u hotelu Proljeće

Događaj/Entitet

koris

nik

reze

rvac

ija

sobe

zadu

ženj

e

soba

…

privremena rezervacija C/M C potvrda rezervacije C/M opoziv rezervacije M dolazak gosta C/M C/M M povećanje troškova M C plaćanje usluga M M M arhiviranje rezervacije D D


Matrični prikaz modela događaja

U primjeni su različite vrste prikaza, ovisno o metodologijimatrica entiteti/događaji (Entity/Event Matrix), npr. SSADM

• odnos događaja 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/događaji (Function/Event Matrix), npr. SSM

• odnos obrade i događaja: X (povezanost) ili praznina

Slične matrica može se iskoristiti za definiranje pravamatrica Korisnik / Proces / Xmatrica Korisnik / Entitet / CRUD

• Korisnik pri tome predstavlja grupu korisnika ili ulogu korisnika• Ovisno o detaljima ugradnje u fizičkom modelu Korisnik može biti i

konkretna osoba


Matrični prikaz modela događaja

Pimjer, prvi dio matrice procesi/entiteti za jedan stvarni sustavK3 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 CRUD CRUD CRUD R R R R R R R R R R R R R R R R R R

P6 CRUD R CRUD R R R

P10 CRUD R R R CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD R R

P11 CRUD R R R CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD R R

P12 CRUD R R R CRUD CRUD CRUD CRUD CRUD CRUD CRUD CRUD R R

P8 CRUD R R R R R R R R R R R R R R R R R R

P32 CRUD CRUD CRUD R

P44 R RU CRUD R

P37 R RU CRUD R

P22 R RU CRUD R

P20 CRUD CRUD R R CRUD

P1 R R R R CRUD

P4 R R R R CRUD CRUD

P3 R R CRUD R CRUD

P36 R R CRUD R CRUD CRUD

P48 R R R CRUD CRUD R R

P45 R R CRUD R

P18 R

P16 R R R R R R R R R R R R R R R R R

P7 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

P24 R R R CRUD R R R R R R R R

P30 R R R R R R R R R RU

P25 R R R R R R R R R R R

P29 R R R R R R RU R

P28 CRUD R R

P33 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

P19 R R R R R R R R R

P14 R R R R R R R R R R R R R R R R R

P38 R R R R R R R R R R R R R R R RU R

P50 R R R RU R

P52 R R R R R R R R R R R R RU R

P51 R R R R R R R R R R R R R R RU

P47 R R R R R R R R R R R R R R R R R R R R R RU R

P46 R R R R R R R R R R R RU R

P31 R R R

P15 R R

P49P26 R R R

P13 R R R

P27 R R R R

P21 RU RU RU RU RU RU RU RU RU RU RU RU RU RU RU RU RU RU RU

P17 R R R

P2 R R R R R R R R

P5 R R R R R

P35 R R R R R R R R R R R R R R R R R R R R

P34 R R R R R R R R R R R R R R R R R R R R R

P41P42P39P40P43P23


Model života entiteta

Povijest života entiteta (Entity Life History)pogled na sustav usmjeren učincima događaja koji uzrokuju promjene stanjaopisuje vremenski zavisno ponašanje (jednog) entiteta

• prati promjene ponašanja entiteta koji prolazi kroz sustavDijagram podudarnosti učinaka - Effect Correspondence Diagram (ECD)

entite t,blok

ponavl jan idogađaj (iteraci ja)

al ternativnidogađaj (selekcija)

sl ijednidogađaj (sli jed)

m n ooperaci je


Model života entiteta

Primjer, pojednostavnjena rezervacija sobe u hotelu Proljeće

1 1 2

stvaranjetroška

povećanjetroška

opozivrezervacije

nedolazakgosta

rezervacijasobe

rezervacija,nenajav. dolazak

potvrdarezervacije

opozivrezervacije ili nedolazak

privremenarezervacija

dolazakgosta

arhivi ranjerezervacije

3

3 3

najavljenidolazak

2

4

plaćanjeusluga

5

7

63

3

1. Kreirati rezervaciju2. Zauzeti sobu3. Ažurirati status rezervacije4. Kreirati zaduženje5. Poništiti zaduženje6. Osloboditi sobu7. Obrisati podatke o rezervaci ji


Dijagram prijelaza stanjaDijagram prijelaza stanja (State Transition Diagram)

zasniva se na ideji stroja s konačnim brojem stanja (finite state machine), hipotetičkom mehanizmu koji u nekom trenutku može biti u jednom od konačno mnogo diskretnih stanja grafički prikaz promjena stanja, tj vremenski zavisnog ponašanja sustava

Elementi prikaza:stanje – kumulativni rezultat ponašanja nekog objekta (pravokutnik, krug ili elipsa)prijelaz – promjena stanja uzrokovana nekim događajem (usmjerena linija od jednog stanja prema drugom)događaj – uvjet promjene stanja i akcija koja se obavlja (opis linije prijelaza oblika događaj/akcija)

DPS najčešće opisuje vremenski zavisno ponašanje čitavog sustava manji sustavi mogu se prikazati jednim dijagramom veći sustavi razlažu se slično dijagramima toka podataka, pri čemu stanje na nekoj razini postaje početno stanje dijagrama na nižoj razini

Primjenasustavi za rad u stvarnom vremenu (real-time system)jezična analiza (parsing)dizajn korisničkog sučelja

Primjeri: \Dizajn


Primjer: Stanja zahtjeva (narudžbe)U pripremi: Zahtjevatelj stvara novi zahtjev, pokrenuvši tu funkciju iz nekog drugog dijela sustavaOdgođen: Zahtjevatelj je snimio svoj rad (narudžbu) kako bi ju dovršio kasnije bez da ju je predao ili otkazaoZaprimljen: Zahtjevatelj je predao svoj zahtjev (narudžbu) koji je sustav ocijenio kao dobar i primio gaPodnesen: vanjski dobavljač je sposoban isporučiti zahtjev i kupac podnosi zahtjev (narudžbu) kod vanjskog dobavljačaIspunjen: zahtjev je zadovoljen bilo da je dostavljen iz zaliha kemijskog laboratorija ili da je dostavljen od strane vanjskog dobavljačaVraćen: dobavljač nije mogao zadovoljiti narudžbu i vratio je narudžbu uz mogućnost kasnije dostaveOtkazan: Zahtjevatelj je otkazao primljen zahtjev prije negoli je isporučen ili je kupac otkazao narudžbu kod vanjskog dobavljača prije nego što je dostavio narudžbu ili nakon što je dobavljač vratio narudžbu uz mogućnost kasnije dostave

u pripremi

primljeno

podnešen

vraćenispunjen otkazan

odgođen

korisnikstvaranovi

zahtjev

korisnikotkazuje

novizahtjev

korisnik snimanepotpun zahtjev

korisnik dohvaćanepotpun zahtjev

sustav prihvaćavaljan zahtjev

kupac podnosizahjtjev kod dobavljača

dobavljač vraćanarudžbu za kemikalijama

kupac otkazujenarudžbu

kupac otkazujenarudžbu

zahtijevač otkazujenarudžbu

kemikalija nabavljenaod dobavljača

kemikalija nabavljenaod dobavljača

kemikalija nabavljenaiz zaliha kem. laboratorija


Primjer: sustav za rad u stvarnom vremenu

Dijagrami sustava za rad u stvarnom vremenu razlikuju se po tomešto sadrže posebno stanje "besposlen"

Primjer, Sokomat hotela Proljeće ili Bankomat banke Oprosti nam duge naše

praznihod (idle)

čekanjena izbor

natočeno

čekanje navađenje kartice

ispravnakartica / 'Izaberite'

neispravnakartica / 'Neispravna

izvađeno /'Još nešto?'

kartica izvađena/ 'Umetnite'

izabran 'Kraj'/ 'Hvala, đenja'

obavljen odabir/ 'Pokupite'


Primjer: prijelazi statusa karticaU zagradama je navedeno tko promjenu smije načiniti.

Podaci ispravni(CAP)

A

Izrada zapisa(ustanova)

N

Slika i potpis(ustanova)

Z

Kontrola podatakaprije tiska(CAP)

Z

Postoje neispravnipodaci(CAP)

Y

Ispravak pogrešnihpodataka(ustanova, CAP)

Z

Tiskanje kartice(tvrtka za tiskanje)

T

Izdavanje vlasniku(ustanova)

A

Poništavanje kartice(ustanova, CAP)

PKJID O S R U

Ponovno aktiviranje(ustanova, CAP)

T

G

ZatraženaZ

Poništena zbog neispravnih podatakaY

NestalaX

UkradenaU

TiskanaT

OštećenaŠ

Student se ispisaoS

PoništenaP

Student je upisao prekidR

OduzetaO

NezavršenaN

Istekao apsolventski rokK

Poništena zbog promjene JMBG-aJ

IzgubljenaI

Pogrešni podaci (koristi samo tvrtka za tiskanje)G

Student je diplomiraoD

IzdanaA


Mape dijaloga

Korisničko sučelje u mnogim aplikacijama se može promatrati kaokonačni automat.

Jedan element sučelja (izbornik, radna površina, komandna linija ili dijalogprozor) može biti aktivan u određenom trenutku. Korisnik može doći do ograničenog broja drugih elemenata ovisno o akcijama koje poduzima.Broj putanji kojima korisnik može mijenjati dijaloge je obično vrlo velik, ali jekonačan i mogućnosti su najčešće poznate.

Mape dijaloga prikazuju sustav na visokoj razini apstrakcije. Prikazuju elemente dijaloga u sustavu i mogućnost navigacije između njih aliništa ne govore o dizajnu zaslona.Korisnici i razvojni tim mogu zajednički razmatrati dijalog mape kako bi postigli zajedničko gledište o tome kakva treba biti korisnikova interakcija sa sustavom kako bi postigao određeni zadatak.Dijalog mape su također korisne kod modeliranja vizualne arhitekture web sjedišta, pa se ponekad tako i nazivaju (eng. site maps). Navigacijski linkovina sjedištu pojavljuju se kao tranzicije na dijalog mapi.


Mape dijaloga

Koristi se notacija dijagrama prijelaza stanjaUvjet koji pokreće korisničku navigaciju prikazan kao tekst na strelicama. Postoji nekoliko vrsta pokretačkih uvjeta:

• Korisnička akcija, kao što je pritisak tipke ili klik na link ili gumb dijalog prozora

• Podatkovna vrijednost, kao što je pogrešan unos koji pokreće pojavljivanje poruke o pogrešci

• 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 EnterRadi pojednostavnjenja mogu se izostaviti neke općenite funkcije, npr.

pritiskanje tipke F1 da bi se dobila pomoćstandardni navigacijski linkovi koji se pojavljuju na svakoj stranici.


Primjer: mapa dijalogaDijalog mape moguprikazati

Alternativne putove (npr. naručiti od vanjskogdobavljača) kao grane kojeodstupaju od uobičajenogputa (kemikalija iz zaliha). Opcionalne putove (npr. Pregled povijesti pakiranja)Posebna stanja (npr, porukeo pogreškama)

Prilikom analize zahtjeva, dijalog mapa predstavlja interakciju korisnika i sustava na konceptualnoj razini. Konkretna ugradnja može biti drugačija.

Primjer: Korisnik inicira ovaj model korištenja odabirom opcije "zatraži kemikaliju" iz glavnog izbornika. Nije nužno prikazivati detalje (npr. Potvrdu otkazivanja čitavog zahtjeva)Ključno je da korisnik i razvojnik jednako “razumiju”opisanu funkcionalnost.

Trenutna listazahtjeva

zatražikemikaliju

otkažicijeli

zahtjev

Unesite šifruzahtijevanekemikalije

Prikaz porukeo pogrešci

Listadobavljača

za kemikaliju

Lista pakiranjau zalihamakemijskoglaboratorija

Povijestpakiranja

Potvrda da jezahtijevprimljen

podnijeti zahtjev za >0 kemikalija

brisanje kemikalije satrenutne liste zahtjeva

zahtijevanjedruge

kemikalije

otkaži zahtjevza novomkemikalijom

zatraži kemikalijuod dobavljača

zatraži različitukemikaliju

otkaži dodavanjenove kemikalije

odaberi dobavljača i dodavanje u listu

pogrešna šifrakemikalije

OK

zatraži kemikalijuiz zaliha

laboratorija

zatraži različitukemikaliju

zatraži pogledatipovijest pakiranja povratak

odaberi pakiranjei dodaj u listu

otkaži dodavanjenove kemikalije

u listu

Oblikovanje sustava


Oblikovanje sustava» Analiza – što sistem mora raditi» Dizajn – kako sustav treba izgraditi ili kakav sustav treba biti

Oblikovanje sustava, Dizajn sustava (systems design)Procjena alternativa i detaljna specifikacija računalom podržanog rješenja tehnička specifikacija sustavaIzrada ugradbeno zavisnog modela, kojim se opisuje kako sustav radifizički dizajn

Moderni strukturirani dizajnprocesno usmjerena tehnika razrade velikog programa u hijerarhiju modula s ciljem izrade programa koje je lakše napraviti i održavatistarije varijante: oblikovanje programa s vrha nadolje (top-down program design) i strukturirano programiranjealternative i/ili nadopune: informacijsko inženjerstvo, prototipiranje, JAD, RAD, objektno usmjereni dizajn


Opći dizajnOpći dizajn (konceptualni, visoki, dizajn arhitekture) → funkcionalne specifikacijeOdabir tehničke arhitekture sustava

Centralizirana ili distribuirana obrada i pohrana? Kako? Tehnologije?Softver: nabavljeni, napravljen po mjeri, mješavina? Razvojni alati?

Analiza i distribucija podatakapretvorba konceptualnog modela podataka u logički model (relacijski , postrelacijski, objektno-relacijski), ako nije učinjena ranijeizrada dobrog modela podataka - jednostavan, neredundantan, elastičan i prilagodljiv model

• analiza podataka (ako postoje) i normalizacija modelaanaliza događaja

• analiza entiteta normaliziranog modela i uočavanje događaja i uvjeta koji uzrokuju stvaranje, izmjenu i brisanje podataka i po potrebi ažuriranje modeli procesa

Analiza i distribucija procesapretvorba logičkog modela procesa u fizički model za odabranu arhitekturu shema aplikacije

• fizički procesi: poslužitelji, radne stanice, rad koji treba obaviti• fizička spremišta: baze podataka, tablice, datoteke

grupiranje i distribucija obrade na različite lokacijedizajn računalske mreže, povezivanje s drugim, postojećim sustavimadefiniranje prava pristupa logičkih grupa korisnika

Opći dizajn sučelja izgled, ergonomija, tzv. ‘look and feel’

Izrada planova konverzije i instalacije


Detaljni dizajn

Detaljni dizajn → tehničke specifikacijeIzrada fizičkog modela podataka

pretvorba logičkog modela podataka u fizički model podataka za odabrani SUBP shema baze podataka

• prilagodba modela mogućnostima i ograničenjima SUBP• fizički parametri (volumetrija) i ugađanje baze podataka

oblikovanje fizičkih datotekaDizajn programa

utvrđivanje strukture programa na temelju modela procesa • (logički) proces ili skup procesa ↔ jedan ili više programskih modula• određivanje veza između modula (standardno strukturnim kartama)

preciziranje programske logikeDizajn sučelja

dizajn sučelja sustava – protokoli pristupa i razmjene podatakaoblikovanje zaslonskih maski i izvješća

Prototipiranje detalja dizajnaIzrada procedura za provjeru ispravnosti i konverziju sustava


Pristupi oblikovanju i razvoju

Cjelovitoistovremeni (tzv. “frontalni”) razvoj cijelog ISveliki zahtjevi na ljudske resurse, problem koordinacije izvođača

Faznopodjela na podsustave te nezavisni razvoj pojedinih podsustava uz kasniju integraciju podsustava

• moguće kod velikih IS koji se daju rastavitiproblem rastavljanja i povezivanja podsustava

Optimalno rješenjeizrada jedinstvenog modela podataka na početku razvojarazvoj i postupna integracija aplikacija

Arhitektura sustava


Dizajn arhitekture sustava

Dizajn arhitekturesastoji se od planova koji definiraju pojedine komponente sustava

• računalnu opremu• programsku podršku• komunikacije• sustav zaštite• globalnu podršku aplikacije

Specifikacija hardvera i softvera podloga za nabavuUobičajeni modeli arhitekture

poslužiteljska (server-based) – obrada se obavlja na poslužiteljuklijentska (client-based) – obrada se obavlja na osobnom računaluklijent-poslužitelj (client-server based) – kombinacija prethodne dvije

Model mrežeprikaz glavnih komponenti sustava, njihove fizičke lokacije i način njihovog međusobnog povezivanja


Arhitektura sustava

Funkcije sustava = slojevi arhitekture

Pohrana podataka (data storage)Pristup podacima (data access logic)Elementi obrade (application logic)Sučelje (presentation logic)

PoslužiteljiVelika računala (Mainframe)Mala računala (Minicomputer)Mikroračunala (Microcomputer) – PC

KlijentiKlasični terminali - ansi, vt220, ...Mikroračunala – PC

• pristup terminal emulatorima ili udaljenim radnim plohama

Terminali posebne namjene • bankovni terminali (bankomati),

Internet kiosk, ručna računala,...

Data and DB process on server

All business logic on the mainframe server

All data on the mainframe server

Business logic on application server

User Interface on the PC Client

Network

Logic & user interface on PC

Network

Data on DB process on Server

User interface on the PC client

Network Network

Some logic on Intranet Server

Data on database server

Internal user interface on PC

Network

Secure intranet provides access

to data, logic, and interfaces

Distributed Presentation

Distributed Data (2-tier)

Distributed Data & Logic (3-tier)

Internet and Intranet

Some logic on Internet Server

External user PC client

Internet Connection provides access to

interfaces and some logic

Secure Gateway to protect applications

and data

Connection to outside

world

Secure connection to database

server


Centralizirana obrada

Višekorisničko računalo (mainframe, minicomputer) + terminalpohrana podataka (datoteke i baze podatka)poslovna logika (programska podrška)korisničko sučelje (uobičajeno znakovno sučelje )sučelje sustava (mrežne i druge komponente)

Distribuirana prezentacijaopcionalna nadgradnja središnjih aplikacija zamjenom znakovnog sučelja grafičkim, koje se izvodi na osobnom računaluproduljuje vijek starih aplikacija, ali se funkcionalnost ne može značajno poboljšati


Dvoslojna arhitektura klijent-poslužitelj (client-server)

Klijent - jednokorisničko računalosučelje, obrada i pohranapovezljivost na poslužitelje (opcionalno na druge klijente)

Poslužitelj - višekorisničko računalodijeljena baza podataka, obrada i servisi sučeljapovezljivost s klijentima i drugim poslužiteljima

Korisnicima izgleda kao da jedno računalo (njihov PC) obavlja cijeli posaoPrednosti

izolacija promjena u pojedinom slojukvalitetnija (lakša) obradasredišnje upravljanje integritetom podataka na poslužitelju

Nedostaciodržavanje aplikacijske logike (programa) na svim klijentimadebeli klijenti

Primjeri


Debeli klijent

Debeli klijentPodatkovna logika integrirana u klijentaNema obrade podataka na serveru ili je obrada minimalnaMinimalna ili nikakva elastičnost na promijene poslovne politike

Prednostibrzi početni razvoj aplikacijeveća samostalnost klijentarasterećenje glavnog računala (servera)može imati lokalnu bazu podatakamogu se nabaviti jeftina računala sa snažnim procesorima

Nedostaciposlovna logika integrirana na klijentapromjena poslovne logike znači instaliranje nove verzije aplikacije na svim klijentimavelika mogućnost rada sa zastarjelim podacimaako s vremenom aplikacija postane spora (zbog količine podataka), treba promijeniti sve klijenterazvoj velike aplikacije s vremenom postaje vrlo kompleksan (sav kod je na klijentu)


Tanki klijentTanki klijent

Podatkovna logika se nalazi na poslužiteljuOsnovna namjena klijenta je prikaz podatakaVećinom se koriste u poslovnim sustavimaTipičan primjer tankog klijenta je web preglednik

Prednostipromjena poslovne logike ne znači nužno i promjenu u klijentskom dijelu aplikacijepromjena poslovne logike može se obaviti centraliziranoračunala ne moraju imati veliku procesorsku snaguukoliko s vremenom obrada postane spora (zbog količine podataka), možemo jednostavno povećati snagu središnjeg računalakao tanki klijent može se koristiti npr. web preglednik (dobro definirano i svima dostupno)smanjena mogućnost 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)

Nedostaciveliko opterećenje glavnog računala, a to znači skupo glavno računaloukoliko se kao klijent koristi web preglednik moraju se poštivati njegova ograničenja


Troslojna ili višeslojna arhitektura klijent-poslužitelj

Distribucija baza podataka i poslovne logike na zasebne poslužitelje

poslužitelj aplikacija + poslužitelj baza podataka + klijentposlužitelj baza podataka

• upravljanje podacimaposlužitelj aplikacija

• upravljanje transakcijama, "preuzeto" s podatkovnog poslužitelja

• dio ili čitava poslovna logika, "preuzeta" s klijenta

klijent• korisničko sučelje• dio poslovne logike - onaj koji se ne

mijenja ili je osobnog karakteraPrednosti

bolja raspodjela opterećenjaveća skalabilnost - mogućnost ekspanzije, npr. povećanja broja korisnika, bez preopterećenja ili potrebe za promjenom procedura)+

Nedostacisloženi (komplicirani) dizajn i razvojproblem raspodjele podataka, procesa, sučeljaveće opterećenje mreže

Primjeri


Višeslojna arhitektura

Koristi se za razvoj složenih aplikacijaKod se može podijeliti u više 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)

Trenutno se često radi podjela u tri razineKlijent - GUI (u web aplikaciji je to web preglednik)Application server - BLL (npr. web servis)Baza podataka (npr. SQL Server)


Odabir arhitekture korisnik-poslužitelj

Odabir arhitekture može ovisiti o raspoloživim računalima i mrežnoj infrastrukturi. Općenito, mogu se primijeniti sljedeći kriteriji:

Aplikacije velikog opsega sa stotinama ili tisućama klijenata.Sustavi u kojima su i podaci i aplikacije promjenljivi.Aplikacije u kojima se integriraju podaci iz višestrukih izvora.

Troslojne ili višeslojne K/S arhitekture

Aplikacije gdje se aplikacijska obrada izvodi na klijentu COTS (Commercial Off-The Shelf Software) programskom podrškomAplikacije koje zahtijevaju računalno zahtjevne obrade podataka (npr. vizualizacija podataka – interaktivno ili izvješćima).Aplikacije s relativno čvrstom krajnje-korisničkom funkcionalnošću korištene u okolini gdje je dobro uspostavljeno upravljanje sustavom.

Dvoslojne K/S arhitekture s debelim klijentima

Naslijeđeni aplikacijski sustavi gdje je nepraktično i neisplativo odvajanje aplikacijske obrade i upravljanje podacima.Računalno-zahtjevne aplikacije s vrlo malo ili bez podatkovne obrade.Podatkovno zahtjevne aplikacije (pretraživanje i upiti) s vrlo malo ili bez aplikacijske obrade.

Dvoslojne K/S arhitekture s tankim klijentima

AplikacijeArhitekture


Primjer arhitektura klijent-poslužitelj

Napraviti aplikaciju koja će prikazivati:Kupce, prodavače i datume narudžbiNazive artikala, jediničnu cijenu i količinu za pojedinu narudžbuUkupnu količinu i ukupnu vrijednost narudžbeTreba prikazivati zadnjih 20 narudžbi

Rješenje – debeli klijentNa klijentu napravi SQL upit kojim se dohvaćaju podaci o zadnjih 20 narudžbi.Na klijentu napravi SQL upit kojim se dohvaćaju detalji za zadnjih 20 narudžbi.Kad se promjeni narudžba prođi kroz sve detalje i ispiši one koje pripadaju trenutnoj narudžbi. Usput računaj zbirne vrijednosti.

Rješenje – tanki klijentNa klijentu pozovi stored proceduru koja vraća podatke o zadnjih 20 narudžbiKad se promjeni trenutna narudžba pozovi stored proceduru koja vraća detalje trenutne narudžbe i zbirne vrijednosti


Primjer promjene zahtjeva

Promjena zahtjevaKorisnik se nakon mjesec dana rada aplikacije, naravno, predomislio i želi da se prikazuje zadnjih 50 narudžbi.

Ispunjenje promjene zahtjevaNa debelom klijentu treba promijeniti SQL upite u izvornom kodu, prevesti gau novu izvršnu inačicu te dostaviti aplikaciju korisnicima - sporo i skupoNa tankom klijentu treba na serveru promijeniti samo pohranjenu proceduru za dohvat narudžbi - brzo (manje od pet minuta) i jeftino


Primjer rješenja u višeslojnoj arhitekturi

Postoje sljedeće 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)


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 gridadataGridOrders.DataSource = _bLastOrders.OrdersEntityCollection;dataGridOrderDetalis.DataSource =

bLastOrders.OrderDetailsEntityCollection;// Ispiši detalje trenutno selektirane narudžbedataGridOrders_CurrentCellChanged(sender, e);

}

Prema pravilima višeslojnog 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 učitaju podaci o narudžbama.Nakon toga okinemo event na kojem se prikazuju podatci o detaljima narudžbe (sljedeći slide).


Primjer prezentacijskog sloja

private void dataGridOrders_CurrentCellChanged(object sender, System.EventArgs e) {// Dohvati podatke o trenutno selektiranoj narudžbi_bLastOrders.SelectOrderDetails(Convert.ToInt32(dataGridOrders[

dataGridOrders.CurrentRowIndex, 0]));// Ispiši zbirne podatke na formutextBoxTotalPrice.Text = _bLastOrders.TotalPrice.ToString("C");textBoxTotalQuantity.Text = _bLastOrders.TotalQuantity.ToString();

}

Kod promjene selektirane narudžbe treba osvježiti podatke o detaljima.To radimo tako da pozovemo pripadajuću metodu u b-klasi (SelectOrderDetails).Ta metoda dohvaća detalje neke narudžbe, a usput računa i zbirne podatke (ti podaci su dostupni preko property-a b-klase.


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 narudžbe_ordersEntityCollection = new EntityCollection(new OrdersEntityFactory());SelectLastOrders();// Definiranje EntityCollection-a za detalje narudžbe_orderDetailsEntityCollection = new EntityCollection(new OrderDetailsEntityFactory());

}

Primjer konstruktora u b-klasi (sloju poslovne logike).Sloj poslovne logike treba pametno definirati, tako da GUI služi samo za prikazivanje podataka, a sve veće 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 priloženog koda vidi se da je programiranje znatno jednostavnije nego upotrebom SQL upita.


Primjer poslovnog sloja (BLL)public EntityCollection SelectLastOrders() {

// Isprazni trenutni sadržaj_ordersEntityCollection.Clear();// Narudžbe treba sortirati prema datumi unatragISortExpression 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 korištenje sortera i dodatnih staza za dohvat)_dataAccessAdapter.FetchEntityCollection(_ordersEntityCollection, null, 20, sorter, path);// Vrati podatke dohvaćene iz bazereturn _ordersEntityCollection;

}

Primjer dohvata zadnjih 20 narudžbi u b-klasi. Tu ujedno možemo napraviti i promjenu da se dohvati zadnjih 50 narudžbi.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 mogućnost pogreške, a sljedeća prednost je preglednost koda.Na sličan način bi se riješio i dohvat detalja pojedine narudžbe.


Primjer podatkovnog sloja (DAL)

DALGeneric (generator koda LLBLGen -> C#) i DALSpecific(generator koda LLBLGen -> C#)

Ovaj dio služi za pristup bazi podataka (DAL)Ovaj dio koda se generira pomoću 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 specifični za pojedine

baze podatakaPrednosti rješenja upotrebom generatora koda:

• Mogućnost pristupa bazi podataka preko objekta (nije potrebno znanje SQL-a)

• Mogućnost promjene baze podataka• Nema velikog gubljenja vremena na pisanje koda za pristup bazi

podataka• Manja mogućnost pogreške• …

Dizajn baze podataka


Dizajn baze podatakaDizajn baze podataka

Izrada sheme baze podataka (fizički model, tehnički nacrt)• prevođenje podatkovnog modela u strukture podržane odabranom tehnologijom (SUBP)• primarni ključ, sekundarni ključ, strani ključ, opisna polja

Relacijske BP• strukturirani upitni jezik (SQL), • okidači (trigger), • pohranjene procedure (stored procedures), • dinamički skupovi podataka (cursor), • korisnički definirani tipovi podataka i funkcije• ...

Svrhapouzdanost - konzistentnost i integritet podatakaučinkovito rukovanje podacimaprilagodljivost na promjene zahtjevaskalabilnost

Analiza podatakapriprema modela podataka za ugradnjunormalizacija - tehnika organiziranja atributa, dovođenje modela u određeni stupanj organiziranosti, 3NF ili višu NF

Great news - the relational model is dead!Michael Gorman, Whitemarsh Information Systems, Corp., http://www.wiscorp.com


Normalizacija

Normalizacijapostupak strukturiranja sheme relacijske baze podataka tako da se ukloni što više neodređenosti (zalihosti)stupanj normalizacije povećava se od 1NF do 5NF

• većina dizajnera zaustavlja se na 3NF ili na BCNF (Boyce-Codd NF)svodi se na ispunjenje tzv "relacijske zakletve" [Finkelstein, 1989]:

• Ključ– 1NF: nema ponavljajućih grupa, definiran primarni ključ

• Cijeli ključ– 2NF: svi neključni atributi u potpunosti zavisni o čitavom PK

• Ništa drugo nego ključ– 3NF: svaki neključni atribut je neposredno zavisan samo o PK

• Tako mi Codd pomogao! » Dr. E. F. Codd - otac relacijske teorije BP

– BCNF: svi atributi koji određuju druge atribute čine moguće ključeve


Normalizacija

Prevođenje modela i normalizacija uporabom CASE pomagalaAutomatizirano pridjeljivanje stvarnih tipova podataka konkretnog SUBPStvaranje tablica za entitete nadtipa i podtipaAutomatizirana migracija ključa i prepoznavanje tzv. visećih veza (danglingrelationships) – veza na tablice koje nisu uključene u generiranje modelaVećina CASE alata normalizira u 1NF

• zamjena veza više-prema-više asocijativnim entitetima• zamjena višeznačnih atributa entitetima

Više normalne forme• problem prepoznavanja djelomičnih i tranzitivnih zavisnosti

Generiranje programskog koda okidača

Prije početka kodiranja obavlja se ograničeno uvođenje zalihosti i ugađanje baze podataka zbog poboljšanja elastičnosti i poboljšanja performanci

zahvat može rezultirati određenim brojem intervencija u logički modelDenormalizacija - ograničeno i kontrolirano narušavanje NF


Denormalizacija

Nadomjesni ključeviispred ključa složenog od većeg broja atributa (npr. >= 3) umeće ključ sa samopovećavajućim vrijednostima (serial), a na originalni ključ postavlja se jednoznačan (unique) kompozitni indeks

• teorijski se ne preporuča za asocijativne entitete, koji nasljeđuju ključeve svojih roditelja, jer se time gubi smisao identifikacijske veze

• praktično, nadomjestak treba ugraditi kada je tablica u koju se ugrađuje referencirana iz drugih tablica, a to nije u suprotnosti s poželjnim redundantnim vezama

– primjer: @IdRadnogMjesta = @IdOrgJedinice, @IdZanimanjaRadnoMjesto = @IdRadnogMjestaZaposlenje = @IdOsobe, @IdRadnogMjesta, @DatZaposlenja, …

– primjer: Drzava 1:N Mjesto 1:N Osoba, pri čemu je Mjesto = @IdDrzave, @IdMjesta, …

“čisti dizajn” – dosljedna ugradnja nadomjesnog ključa sa samopovećavajućim vrijednostima u sve tablice baze podataka

• pojednostavnjenje ugradnje • umnožavanje ključeva (nadomjesni primarni, originalni alternativni)• gubitak izvorne vrijednosti stranog ključa


Denormalizacija

Dijeljenje i udruživanje tablicadijeljenje tablica smještanjem rijetko korištenih atributa u posebnu tablicuudruživanje tablica ili uklanjanje pojedinih tablica stapanjem atributa

• obične veze 1:1• udruživanje nadtipa s podtipovima kardinalnosti 1:1, pod uvjetom da su

slične strukture i sadržajaUvođenje zalihosti

dodavanje atributa za pohranu izvedenih vrijednosti• atribut pohrane za izvedenu vrijednost koja se može izračunati

agregatnom funkcijom (npr. iznos računa kao suma iznosa stavki)• oznaka zadnje vrijednosti nekog stanja kada se vrijednosti pojedinih

stanja nalaze u tablici s velikim brojem zapisa (npr. stanje skladišta)• redundantna vrijednost koja se inače dohvaća složenim i/ili sporim

upitima (zadnje zaposlenje + zadnji izbor u zvanje + zadnje školovanje)dodavanje atributa kao što su zastavice za "trajno" označavanje zapisa

Podrazumijeva se da se denormalizacija obavlja samo na mjestima gdje je to stvarno nužno i na takav način da ne ugrožava integritet podataka aplikacijsko upravljanje integritetom


Ugradnja pravila za očuvanje integriteta

Očuvanje integriteta stvaranjem objekata u rječniku BPEntitetski integritet - postavljanjem primarnog ključaReferencijski integritet - postavljanjem stranog ključa i ograničenja na unos

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

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

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

• zabrana (restrict)• brisanje n-torki koje imaju odgovarajuću vrijednost stranog ključa

(cascade)• ažuriranje odgovarajućih vrijednosti stranih ključeva (set null)• postavljanje na standardnu vrijednost (set default)


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 ključa i provjeru postojanja referencirane n-torke pri unosupostojanje opcionalnog, tj. nedefiniranog stranog ključa (null)kaskadnu obradu n-torki koje referenciraju roditelja koji se ažurira ili briše

– [ ON DELETE { CASCADE | NO ACTION } ] – [ ON UPDATE { CASCADE | NO ACTION } ]

Upravljanje referencijskim integritetom okidačima (trigger)elastičniji pristup, koji omogućava ugradnju i ostalih postupaka prilikom unosa/izmjene/brisanja n-torki

Aplikacijsko upravljanje integritetompostupci unosa/izmjene/brisanja podržani programskim kodompojavljuje se problem umnažanja programskog koda, naročito kod hibridnih sustava (4GL + GUI)

Mješovitokombinacija navedenih mogućnosti, s tim da DRI ima prednost


Ugradnja referencijskog integriteta

Mogući problemiNeki atribut stranog ključa može biti primarni atribut.

• Pokušaj ažuriranja na nul-vrijednost stranog ključa koji je dio primarnog ključa u suprotnosti je s pravilom entitetskog integriteta.

• Prilikom ažuriranja stranog atributa koji je ujedno i primarni atribut ne smije se narušiti jedinstvena vrijednost ključa.

Postupak kaskadnog ažuriranja ili brisanja n-torki treba provesti rekurzivno, da bi se referencijalni integritet očuvao u svim dijelovima baze podataka, a ne samo na mjestu obrade.

• Problem kaskadnog brisanja “pola baze podataka”• Problem paralelnih kaskada


Ugađanje baze podataka

Postavljanje indeksa radi osiguranja integriteta podatakaubrzanja dohvata podataka

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

• općenito, u tom slučaju ne treba posebno kreirati indekse• ako su ključevi složeni pretraga će raditi brzo uglavnom po prvom polju

– po potrebi postaviti dodatne indekse nad preostalim poljimaGomilasti indeks (CLUSTERED INDEX), Faktor popunjenosti (FILL FACTOR), ....

Promjene podataka uzrokuju ažuriranje indeksa.Izbjegavati nepotrebne i indekse koji su sastavni dio drugih indeksa!Ukloniti indekse prigodom masovnih obrada podatakaKoristiti naredbe i opcije za uvoz podataka (BULK INSERT ... CHECK_CONSTR.)Treba li kreirati indeks u tablicama s malim brojem podataka?


Ugađanje baze podataka

Minimizacija nul-vrijednostiproblem neodređenih vrijednosti agregatnih funkcija, problem operacija s nul-vrijednostima

– primjer: SELECT AVG(polje), gdje polje ima/nema nul-vrijednosti• opisna polja - zahtijevana vrijednost + pretpostavljena vrijednost

problem vanjskih spojnih upita• strana polja – posebne vrijednosti u šifrarnicima

– primjer: 0-nepoznata vrijednost, 999-nepostojeća vrijednost Ubrzanje upita

analiza plana izvođenja (Execution Plan) i odabir poželjnog plana– primjer: SELECT ... OPTION (FORCE ORDER)

primoravanje korištenja određenog indeksa– primjer: SELECT ... WITH (INDEX(index, index...))

primoravanje nekorištenja indeksa primjenom neškodljive funkcije nad poljem nad kojim se uobičajeno koristi indeks

– primjer: WHERE NULLIF ( polje , “” ) = ...ostale opcije

– primjer: SELECT ... OPTION (FAST n_rows)


Pohrana podataka

Vrste datoteka/tablicaMatične - dodani zapis ostaje “zauvijek” u sustavu, može se mijenjati

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

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

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


Fizička raspodjelaFaktor blokiranja (blocking factor)

broj logičkih zapisa koji se obrađuju jednim čitanjem (fizički zapis)uobičajeno određen i automatski podešen, ali se može i ručno ugoditi

Distribucija podataka raspodjela pojedinih tablica, zapisa i/ili polja u različite fizičke BP ili različite fizičke segmente BPprimjer: odvajanje matičnih datoteka i šifrarnika od transakcijskih tablica

Replikacija podataka umnažanje tablica, zapisa i/ili polja u različite fizičke BPprimjer: replikacija šifrarnika između baze na poslužitelju i BP debelog klijenta

Smještaj fizičkih datotekapovećanje sigurnosti i brzine pristupa odvajanjem SUBP, podatkovnog prostora, dnevničkog prostora i rezervnih kopija na različite fizičke uređaje primjer: dvije fizičke jedinice, četiri logičke podjele

• C:\...\binn\MSSQL.exe• D:\...\data\*.mdf• E:\...\log\*.log• F:\...\backup\*.


Šifarski sustavSerijske šifre

brojevi koji se slijedno pridjeljuju svakoj novo dodanoj instanci entitetau modernim SUBP mogu se generirati uz opcionalna ograničenja

• primjer: SQL Server IDENTITY [ ( seed , increment ) ]Blok šifre

slično serijskim šiframa, s tim da su serijski brojevi grupirani prema značenju• primjer satelitskih TV kanala: 100-199 PAY PER VIEW, 200-299 CABLE

CHANNELS, 300-399 SPORT, 400-499 ADULT, 500-599 MUSIC-ONLY, ...Alfanumeričke oznake

ograničeni skup znakovnih oznaka, često kombiniranih s brojevima• primjer, oznake država: HR, DE, IT, SI

Samogovoreće šifre (significant position codes)svaka znamenka ili grupa znamenki opisuje neko svojstvo instance

• primjer: JMBG, a često se koriste i u skladišnoj evidenciji (dimenzije automobilske gume, električne ž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 ugroženosti vrsta: kriterij-podkriterij-temelj (A1a - redukcija, reverzibilna, direkto opažanje)


Izrada šifarskog sustava

Izrada šifarskog sustavaTamo gdje je to moguće treba preuzeti postojeće šifrarnike, od drugih ustanova ili iz postojećih sustavaOznake definirane zakonom ili drugim propisima treba preuzeti i prilagoditiOstale šifrarnike definirati tako da se naknadno mogu nadograđivati

Preporuke za izraduŠifre moraju biti dovoljno velike da opišu željene karakteristike, ali dovoljno male da se mogu interpretirati bez računalaSustav šifriranja bi trebao biti smislen i prikladan da dodavanje novih šifara bude jednostavnoIzbjegavati samogovoreće šifre


Primjeri šifrarnika

Primjer, studentska prehranaPravilnikom o studentskoj prehrani propisan je status upisa potreban za ostvariranje prava na subvencioniranu prehranu.Npr. mora biti upisan u tekuću akademsku godinu na redovnom studiju ili studiju za osobne potrebe.

Zasebno se evidentira način upisa

DAstudij za osobne potrebeO

DAparalelni studij s pravom prehraneL

NEvanredni studijV

NEstudij uz radU

NEparalelni studijP

DAredovan studijR

Pravo prehraneOpis statusaŠifra statusa

DAUpisuje apsolventski rokA

NEPrekid studijaE

DAPonavlja godinu – ne računa se u ponavljanje

B

DAPonovo upisuje godinu - ne računa se u ponavljanje

D

DAPonavlja godinu – računa se u ponavljanjeP

DAUpisuje godinu prvi putaR

DAUvjetno upisuje godinuU

PravoOpis indikatoraŠifra indikatora


Primjer jedinstvene šifreJMBAG je jedinstveni broj u sustavu kojeg student dobiva prilikom upisa na neko visoko učilište i zadržava sve do kraja svog studija.

Ako se isti student upiše na dvije ili više ustanova uvijek zadržava 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 označavaju matičnu ustanovu vlasnika• Sljedećih 5 zanmenki su oznaka vlasnika u ustanovi (matični broj vlasnika ili se

generira slijedno)• Unutar ustanove JMBG i matični broj (broj indeksa) su također jedinstveni.

Broj kartice generira se automatski, a u sebi sadrži 6 grupa znamenki:A. jedinstveni broj u međunarodnom kartičnom poslovanju (IIN)

• uvijek 601983 i prema međunarodnom standardu ISO/IEC 7812 na jedinstven način identificiraju Studentsku karticu u međunarodnom sustavu kartičnog poslovanja

B. oznaka vrste kartice (1 znamenka)• npr: 1 - student i 4 - privremena kartica

C. redni broj kartice koju je student dobio (1 znamenka)D. JMBAG (10 znamenki)E. Kontrolna znamenka (1 znamenka),

Meta-modeliranje

Rječnik podatakaMeta-baza

Primjena meta-modela


Meta-modeli

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

AttributeAttNameLongName

DomainDomNameTypeNameDomLenDomDecCaseJustDataMaskValRule

EntityEntNameShortNameLongName

FieldRequiredIndexSerialVirtualSN

FormFormNameEntNameFormWdthFormHght

Form FieldFormNameFFldNameSNFormFldIdVarRowVarColVarWdthVarHghtLabelLabRowLabColLabWdthLabHght

KeyKeyNoKeyName

Referent FieldRefFldNameDomFldNameSN

RelationshipRelNameShortNameParentAliasInsRuleDelRule

Relationship FieldParFldNameChiFldNameSN

Key FieldSN


Meta-modeli

Primjer praktične realizacije

ZZTables

PK TableName

DescriptionAbout

ZZFields

PK TableNamePK,I1 FieldName

SNTypeSizeRequiredAllowZeroLengthDefaultValueAutoNumberValidateOnSetValidationRuleValidationTextDescriptionTextLenCaptionFieldType

ZZTypes

PK Type

TypeNameTypeDescription

ZZIndexes

PK IndexNamePK,I1 TableNamePK,I1 FieldName

PrimaryUniqueForeign

ZZRels

PK,I3 szRelationshipPK icolumn

szColumnI1 szObject

szReferencedColumnI2 szReferencedObject

ccolumngrbit


Meta-modeli

Poopćenje strukture podatakaOrgCje l ina Propis

Plan

Zakon

Os obana dok umentu

Opisproc es a

Sas tavnic as reds tv a

Os oba Dokum ent

Stavk astruk turi ranog dok umantaPravna

os obaFizick aos oba

Svojs tv o

Hi jerarhi ja(Radno mjesto)

Dogadjaj

Sreds tv o Svojs tv os reds tv a

Vrstas reds tv a

Vrstadok umenta

Vrstadogadjaja

Dogadjajna dok umentu

v ez a

OsnovnoPotrosnoTehnick oFinanci jsk oNekretn inaOs talo

Organizaci jskiPravniIn formaci jskiFinanci jskiMateri jalni


Narudžba MBB-Nabava za osnovno tehničko sredstvo prema poduzeću IMBBr. xxxx od xx.xx.200x.Veza: Ponuda poduzeća IMB br. xxxx od xx.xx.200x.Narudžbu izradio: PeroOdobrio njegov šef: IvoStavke:

Računalo IMB Šestium: xx komMBO, CPU, RAM, HDD, CDR, FDD, CASE

Monitor 15” xx komŠtampač xx komSkener xx kom

Meta-modeli

Primjer, narudžba


Meta-modeli

Primjer, narudžbaMBBNabava

Pravilniko poslovanju

Plan

Zak on

MBB,Iv o, Pero, IMB

Opisprocesa narucivanja

MBO, CPU,RAM, HDD, CDR, FDD

OsobaBroj,Datum, Ponuda

SestiumMoni tor Stampac SkenerPrav na

osobaFizic kaosoba

Svojstvo

Sl jak er,Sef

Narucivanje

SredstvoSvojstvosredstva

Vrstasredstva

Narudzbenica

Vrstadogadjaja

Narudz ba

veza

Osnov noTehnic ko

PravniFinancijskiMateri ja lni


Praktična primjena meta-modeliranja

Primjena

Artikl

SifArt

TarBroj

Dokument

IdDok

VrDokIdPrethDokSifPartSifOtprSifPlacSIfZagSifNap

Mjesto

SifMje

NacinPlac

SifPlac

Napomena

SifNap

Otprema

SifOtpr

Parametar

KratParam

Partner

SifPart

SifMje

VrstaDok

VrDok

StandSifPlacStandSifOtprStandSifZagStandSifNap

Uplata

IdUplate

IdDok

Zaglav

SifZag

Koris

SifMje

StavkaDok

IdDokSifArt

Tarifa

TarBroj


Primjer aplikacije nad meta-modelom


Primjer podataka

Definiranje dokumenata


Primjer izračuna

Primjer, račun stanja skladišta

SELECT Artikl.SifArt, Artikl.NazArt,SUM(StavkaDok.Kolicina*VrstaDok.PredMat)

FROM Dokument INNER JOIN VrstaDok ON Dokument.VrDok=VrstaDok.VrDokINNER JOIN StavkaDok ON StavkaDok.IdDok = Dokument.IdDokINNER JOIN Artikl ON StavkaDok.SifArt = Artikl.SifArt

WHERE VrstaDok.PredMat <> 0AND Artikl.IdeSklad <> 0AND Dokument.DatSklad IS NOT NULLAND Dokument.DatStorno IS NULL

GROUP BY Artikl.SifArt, Artikl.NazArt


Primjer praktične primjeneDokument

PK IDDok

FK1

FK2

FK3FK4FK5FK6

GodBrojSifDokDatDokIDPredhodniDokStorniranDatStornDatIspisDatDospSifPosParSifPosJed1SifPosJed2SifNacPlacRabatPorezUkupnoBezPorezaSlovimaOpis

DokumentBSPK, FK1 IDDok

FK2

BrIzvodaOznZaZatvaranjeVezaPredmetSifDetOpisRadNalStorKnjizenjeBrojRacOdDobOsnovicaZa0PostoOsnovicaZaOporezivanje

DokumentSSPK, FK1 IDDok

FK2

FK3FK4FK5FK6

FK7

FK8

FK9

FK10

FK11

SifCjenikaModPlacanjaFakturiraoOdobrioTekstPrijeTekstPoslijeOznDevRacSifTecListeDatTecSifValRabatUracnatiPorezOpisOstalihTroskova1PorezOstalihTroskova1IznosOstalihTroskova1OpisOstalihTroskova2PorezOstalihTroskova2IznosOstalihTroskova2AktivanSifTipPred

StavkePK, FK1PK, FK2

IDDokSifArt

FK3

KolicinaJedinicnaCijenaBezPorezaTarifaRabat

ArtiklPK SifArt

FK1FK2

FK3

RedBrNazivTipSifJedMjeTarifaJedMasaSifFilArtDugiOpisArtMinZaliheMaxZalihe

0,M

0,M 0,M

0,1

0,M

0,M

1,10,1

0,1

1,1

0,M

0,1

0,M

0,1

0,1

0,1

0,M

0,M

0,M

1,1

0,1

0,M

0,1

0,1

0,M

1,1

0,M

1,1 0,M

0,1

0,M

0,1

0,M

0,M

1,1

Artikl

NacPlacanja

PosPar

KorProg DokumentSS

DokumentBS

DetOpisRadNal

Dokument

Stavke

PosJed

PopCjenika

Tarifa

TecLista

TipPred

VrstaDok

Valuta

IDPrethodniDok

Tecaj

DatumIznossUKn


1,11,1

1,1

0,1

0,M

1,1

0,1

0,1

0,M 0,M

0,1

0,1

1,1

1,1

1,1

1,1

1,1 1,1

0,M

0,M0,M0,M

0,M

0,1

0,M

0,M

1,1

1,1

Banka

Mjesto

PosPar

FilPosPar

Drzava

Osoba PosJed

Tvrtka

TipPorObveznika Valuta

Djelatnost

Adresa

Adresa

Adresa

BankaPK SifBanka

Naziv

DjelatnostPK SifDjelatnost

Naziv

FilPosParPK SifFilPosPar

NazivOpis

MjestoPK PostBr

Naziv

OsobaPK SifOsoba

FK1

FK2FK3

PrezimeImeSifPosParTitulaFunkcijaSluzTelE-mailSpolDatRodAdresaPostBrSifDrzavaPrivTelZebiljeske

PosParPK SifPosPar

FK1

FK2

FK3FK4FK5

FK6FK7

NazivPostBrAdresaSifDrzavaTelefonFaxE-mailWWWZiro-racun1Ziro-racun2MatBrSifFilPosParSifDjelatnostSifBankaRabatBrDanaOdgodeSifTipPorObvSifOsobaZabiljeske

TipPorObveznikaPK SifTipPorObv

NazivKratica

TvrtkaPK Naziv

FK1

FK2

FK3FK4

PostBrAdresaSifDrzavaTelefonFaxE-mailWWWZiro-racun1Ziro-racun2MatBrSifBankaSifTipPorObvPosGodOtvorenaPosGod

ValutaPK SifVal

ValutaKraticaJedIznos

DrzavaPK SifDrzava

FKNazivSifVal

Dizajn programske podrške


Specifikacija i dizajn programske podrške

Specifikacija programske podrške (software specification), specifikacija programa (program specification)

navođenje svih zadataka koje program treba obavitimeđusobne povezanosti različitih dijelova programa i podatakaopis vrste podataka, opis ulaznih i izlaznih podatakaspecifikacija prikaza podataka

\Dokumentacija\SpecifikacijaZahtjeva

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

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

\Dokumentacija\SpecifikacijaDizajna


Pristup oblikovanju programaFunkcionalni pristup (Yourdon, Constantine, 1979)

strukturirani dizajn programske podrške• svladavanje veličine i složenosti programa razradom u hijerarhiju modula• programski modul – grupa instrukcija

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

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

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

Podatkovno usmjereni pristup (Jackson, Warnier, 1981)struktura podataka određuje strukturu programa

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

Strukturirani dizajn


Strukturirani dizajn


Strukturna karta

Strukturna karta (Structure Chart)modeliranje programske podrške na temelju dijagrama toka podataka

• dijagram toka podataka prikazuje ŠTO treba postići• strukturnom kartom izražava se KAKO ostvariti zahtjeve

prikaz hijerarhije programskih modula koji uključuje• prijenos podataka i upravljanja između različitih razina obrade• prikaz slijedne, ponavljajuće i uvjetne obrade

elementi prikaza:f unkcija

ugrađenaf unkcija (modul) iteracija selekcija

podatak (datacouple)

indikator(control couple)

poziv

slijed


Strukturna karta

Primjer, izvješće o poslovanju tvrtke Tajkun & ortaci Sustav

izvješća o prodaji

Uzmidatum

Zapišiizvješće

Ispišizbir

Zapišizaglavlje

Zapiširedak

Računajzbir

Čitajpodatak

Pišipodatak

Uspjeh Katastrofa

datum

zbir

zbir

zbirdatum

datum

datumvrijednost

EOF

EOFpodatak

datum

vrijednost

zbirzbir

podatak


Transformacijska analiza

Transformacijska analiza (transform analysis)

analiza promjene/pretvorbe podatakaprimjenjiva na sustave koji imaju strukturu oblika “ulaz–središte-izlaz”, tj. aplikacije s jasno raspoznatljivim ulazima, središnjom obradom i izlazima, koji se daju prikazati linearnim tokom podataka

Struktura dizajna prikladna za ovakve sustave sastoji se od tri odgovarajuća elementa (ulaz, obrada, izlaz), tj. podsustava:

Get C, koji pribavlja podatak CC → I, koji obradom pretvara podatak C u podatak IPut I, koji ispisuje rezultat I

1 23

C I

ulazi

središteizlazi

System

Get C C → I Put I

CC I

I

1 2 3


Transakcijska analiza

Transakcijska analiza (transaction analysis)analiza izvršenja/obavljanja obradeprimjenjuje se na sustave sa jasno raspoznatljivim središtima izvršenja (transaction centre), tj. sustave u kojima se donosi odluka o tome koji će 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

Primjer,središte zaprima ulaz B, koji se usmjerava (kao B1, B2 ili B3) u odgovarajući proces (3, 4 ili 5)rezultirajući podatak (C1, C2 ili C3) koristi se kao izlazni tok C.

2

3

4

5

6

B

B1B2

B3

C1

C2

C3

C B → C

3 4 5

B1 C1B2

C2

B3

C3


Umreženi procesi

Ostale strukturesustavi koji nisu ni transformacijski niti transakcijski obrađuju se na poseban načinnajčešće se oblikuju plošnim razlaganjem glavnog procesa u sastavne procesenadređeni proces mora pribaviti sve ulaze potrebne za obavljanje pojedinih podređenih procesa te prikupiti i čuvati proizvedene rezultate obrade

Primjerstrukturna karta za DTP razložen plošnom dekompozicijom

7

8

9

10CD

E

F

H

GI C → I

7

8 9

10

DEC

G

F

D E H

F

G H

I


Složeni sustavi

Stvarni sustavi – primjena kombinacija osnovnih postupaka

1

2

3

4

5

6 7

8

9

10 1112

A

B

B1B2

B3

C1

C2

C3

CD

E

F

H

GI J

K

System

Get C C → I Put I

Get B 2 and 6:B → C

Get A 1: A → B 3 4 5

11: I → J Put J

12: J → K Put K

7

8 9

10B

A

B

AB

C

CC I

DEC

G

F

D E H

F

G H

I

I

I

J

J

JK KB1 C1

B2C2

B3

C3

Opis logike


Dijagram toka (blok dijagram)

Dijagram toka (Flowchart)grafički prikaz

• sustava (system flowchart) - zamjena za fizičke DTP• programa (program flowchart)

usredotočen na akcije koje sustav/program mora obavitispecifikaciju predstavlja skup simbola koji opisuju upravljački tok za opis akcije ili odluke unutar simbola može se primijeniti bilo koja notacija, npr. pseudokod ili prirodni jeziknedostaci: veliki skup simbola, veliki i neprikladni dijagrami, nedostatak formalizma, nemogućnost opisa podatkovnih struktura, nestrukturiranost, dozvola skokova koji vode uporabi GOTO naredbetehnika koja (nikako ne) izlazi iz uporabe


Dijagram toka

Primjer


Blok dijagram

Primjer, postupak prodaje (Visio)

Sales Process

Insi

de S

ales

Rep

Cus

tom

erSa

les

Man

ager

Out

side

Sale

s R

ep

No

Yes

No

Yes

Proceed? Pursue OtherLeads

CustomerVisit

Delivery &Follow-up

UncoverNeeds &Benefits

Prospect

DraftProposal

Accept?


Blok dijagram

Primjer: simboli i blok dijagram sustava (System Architect)


Strukturirani prirodni jezik - pseudokod

Strukturirani prirodni jezik (npr. Structured English)verbalni opis uobličen tako da se ukloni neodređenost, a zadrži naracijaugradbeno nezavisan ↔ tehnika analizerazumljiv korisnicima

Elementi:naredbe - zapovjedne rečenice

• pr. ČITAJ, PIŠIblok (odsječak):

• POČETAK akcija KRAJselekcija:

• AKO JE uvjet ONDA akcija1• AKO JE uvjet ONDA akcija1 INAČE akcija2

iteracija:• DOK JE uvjet RADI akcija • PONAVLJAJ akcija DO uvjet• ZA izraz RADI akcija

učitaj (a1,b1,a2,b2)ispiši (a1,b1,a2,b2)izračunaj nazivnik izrazaako su pravci paralelni onda

ispiši porukuinače

izračunaj x,yispiši (x,y)

kraj


PseudokodPseudokod

nastao pojednostavnjenjem i strukturiranjem prirodnog jezikakoristi se kada se želi opisati ugradnja → tehnika oblikovanjaopis algoritama naslijedio je narativnu formu

Moguće oznake za pisanje pseudokoda:Abc naziv algoritmaabc rezervirana riječ pseudojezika za opis algoritamaAbc ugrađena ili trivijalna funkcija (procedura):= pridruživanje↔ zamjena vrijednosti# komentarα konstanta ili parametars skalarv vektorM matrica∅ nul-vektor⎪v⎪ modul (duljina) vektora

skupSi 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) # veza moguća MultAlts() # umnažanje kandidata za j := 1 do Min(n) # za sve potpuno popunjene # strane ključeve ako je ¬(k = Mj ∧ EP ≡ Ec) ∧ {(EP, Ec, k, Mj)} ∩ M = ∅ ∧ {(EP, Ec, k, Mj)} ∩ R = ∅ R := R ∪ {(EP, Ec, k, Mj)} kraj GenRel.


Akcijski dijagram

Akcijski dijagram (Action Diagram)Formalizirana mješavina strukturiranog prirodnog jezika i pseudokoda


Primjena akcijskog dijagrama

Primjer: generator aplikacija Advantage:Plex


Stablo odlučivanja

Stablo odlučivanja (Decision Tree)Stablo odlučivanja je binarno stablo u kojem

• svaki nezavršni č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 složenih grananja u postupku odlučivanjalako razumljivo → dobro sredstvo za komunikaciju s korisnicima

Primjer: posjet zoološkom vrtu Živinaulaz za djecu do 3 godine je besplatanmladež do 18 godina plaća polovicu pune cijene ulaznicedjeca ispod 12 godina u pratnji odrase osobe plaćaju četvrtinu cijeneosobe iznad 18 godina plaćaju punu cijenuosim ako su studenti ili umirovljenici, koji plaćaju polovicu cijeneposjetitelji u grupi imaju 10% popusta na punu cijenustudentski popust ne vrijedi vikendom


Primjer stabla odlučivanja

Primjer: stablo odlučivanja za zoološki vrt Živina

Dob?

3 3-12

12-18

>18

UM

Slobodan

Pratnja?

Polovica

D

N

D

N

D

N

Četvrtina

Polovica

Student?

Polovica

Vikend?

Grupa?

Grupa?

Polovica

D

N Puna

90%

D

N Puna

90%


Politikaiznajmljivanja

filmova:

Kategorija filma:Ukupan broj filmova

koje član želi iznajmiti:Rok za vraćanje

posuđenog filma:

Hit film

Običan film

bilo koliko

manje od 3

3 - 6

više od 6

1 dan

1 dan

3 dana

7 dana

DTP – Stablo - Pseudokod

cijena = 0ako je hit film tada| rok posudbe = 1 dan| cijena = cijena + (osnovna cijena filma x 1,5)inače| ako je ukupan broj filmova manji od 3 tada| | rok posudbe = 1 dan| | cijena = cijena + osnovna cijena filma| inače| | ako je ukupan broj filmova manji od 7 tada| | | rok posudbe = 3 dana| | inače| | | rok posudbe = 7 dana| | ako film nije treći po redu (svaki treći običan film je besplatan) tada| | | cijena = cijena + osnovna cijena filma


Tablica odlučivanja

Tablica odlučivanja (Decision Table)tablični prikaz preslikavanja skupa ulaznih uvjeta u skup izlaznih akcijarelativno jednostavni uvjeti ograničeni skupovi mogućih odgovora, npr. da/ne ili nisko/srednje/visokoneki alati koji podupiru ovaj način izrade specifikacija generiraju programski kôd različitih jezika (pr. C, Pascal, Fortran i Basic)dobro sredstvo za opis poslovnog odlučivanja

Primjer, proširena tablica odlučivanja za zoološki vrt ŽivinaUvjeti

(condition stub)

Ispunjenost uvjeta (condition entries) Dob <3 3-12 3-12 12-18 >18 >18 >18 >18 >18 UM Pratnja D N Student D D D N N Vikend N D D Grupa D N D N

Akcije (action stub)

Izbor akcije (action entries)

Slobodan ulaz X Četvrtina cijene X Polovica cijene X X X X 90% cijene X X Puna cijena X X


Pravila izrade tablice odlučivanja

Preporučljivo je pridržavati se slijedećih pravila:Logika odlučivanja treba biti neovisna o tome kojim redoslijedom su uvjeti napisani. Međutim, nije uvijek svejedno kojim su redoslijedom napisane akcije.Potrebno je izbjegavati eventualno dupliciranje izraza i značenja.U gornjem djelu tablice treba pokušati rasporediti redove tako da oni retci koji sadrže više potvrda uvjeta (znak Y) budu što više dok oni koji sadrže minuse budu niže.Stupce u desnom dijelu tablice treba rasporediti tako da u istom retku oznake "-" buduispred oznaka Y a ove ispred znakova N.

Akcije

XXXcijena = cijena + osnovna cijena filma

XXXcijena = cijena +(osnovna cijena filma x 1,5)

XXXXrok posudbe je 1 dan

XXrok posudbe je 3 dana

XXrok posudbe je 7 dana

--NY-NY-film je treći po redu

YY------ukupan broj filmova manji od 3

NNYYY---ukupan broj filmova 3 - 6

NNNNNYYYukupan broj filmova veći od 6

NYNNYNNYhit film

Politika iznajmljivanja filmova


Struktogram

Nassi-Shneiderman dijagram (Nassi-Shneiderman Chart)grafički prikaz programskih strukturabitno prikladniji u odnosu na dijagram tokaneprikladan za ručnu izradu, naročito kada ga je potrebno često mijenjati

Osnovni elementi:

Slijed Selekcija Iteracija


Struktogram

Primjer, Nassi-Shneiderman dijagram u alatu Xper-C (reverzno inženjerstvo C programa i generiranje koda)

Standardizacija i modularnost programske podrške


Standardizacija i modularnost

Standardne funkcije modula aplikacije za rad s bazom podatakaUlaz u modul

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

Traženje (selekcija) podataka• mora podržavati traženje po uzorcima (query by example), koji se unose

s ekranske maske (query by form)• ako programski jezik nema neproceduralnih naredbi za konstrukciju

uvjeta selekcije, treba ih programski simulirati

Unos novog zapisa• obavlja odgovarajuću provjeru domenskog, entitetskog i referencijalnog

integriteta• treba omogućiti odabir i po potrebi unos podataka koji se nalaze u

drugim tablicama, a povezani su preko stranog ključa


Standardizacija i modularnostIzmjena postojećeg zapisa

• omogućuje se promjena vrijednosti prethodno dohvaćenog, a trenutno na zaslonu prikazanog zapisa

• načelno se zabranjuje izmjena vrijednosti identifikatora zapisa• dabir referenciranih podataka obavlja se kao kod unosa

Brisanje• brisanje dohvaćenog i prikazanog zapisa uz odgovarajuće integritetske

provjere i poruke• obavlja se uz dodatnu potvrdu

Pregledavanje (eng. browsing) prethodno dohvaćenih podataka• grupni pregled većeg broja dohvaćenih zapisa u “prozoru”

– po retcima, po stranicama, skok na prvi/zadnji/n-ti zapis– pretraživanje liste podataka po dijelu naziva (filter)– po želji može odabrati jedan ili više zapisa ili onemogućiti odabir

• standardno se prikazuju samo osnovni elementi zapisa (primarni ključ i relevantni zavisni atributi)


Standardizacija i modularnostPoredak (sort) zapisa koji se prikazuju

• određivanje poretka prije selekcije • naknadni preraspored već dohvaćenih zapisa

Zapisivanje izvješća (report)• sadržaj ispisa

– trenutno prikazani zapis– svi dohvaćeni zapisi

• format ispisa– osnovni podatci (šifra i naziv)– svi podatci

• odredište ispisa– pisač– zaslon– datoteka (nova datoteka, dodavanje na kraj postojeće datoteke)

Izlaz iz modula• s prijenosom informacija o odabranom zapisu

– primarni ključ– cijeli zapis


Standardizacija i modularnostPrimjer, dohvat po uzorku

Pretpostavljena naredba za selekciju podataka

• SELECT Vrsta.* FROM VrstaORDER 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.IdNarodnogImena = NarodnoIme.IdNarodnogImenaWHERE Rod.NazRoda LIKE "vitis*" AND NarodnoIme.NazNarodnogImena LIKE "*loza*" ORDER BY ImenaLat


Standardizacija i modularnost

Primjer, zapisivanje izvješća

Primjer, određivanje rasporeda


Ugradnja općenitih programskih rješenja

Standardni modulZa većinu tablica u bazi podataka dovoljno je napraviti modul s ugrađenim standardnim funkcijama.Standardne funkcije ugrađuju se tako da se, osim s izbornika unutar vlastitog modula, mogu aktivirati i iz bilo kojeg drugog modula.Poželjno je unaprijed oblikovati standardne module:

• Modul za obradu pojedinačnih zapisa• Modul za tabličnu obradu• Modul tipa glava-stavke (tzv. Master-detail)

Univerzalni modulAlternativno, preporuča se ugraditi univerzalni modul sa standardnim funkcijama, koji se može dinamički prilagoditi tako da obrađuje podatke u različitim tablicama.Univerzalni modul treba realizirati tako da u pogonu može istovremeno postojati više instanci istog modula prilagođenih pojedinim tablicama.Ovisno o pojedinom projektu, univerzalni modul može zamijeniti i preko polovice standardnih modula



Primjer, osnovni standardni moduli



Primjer, udruživanje standardnih modulaMaska kreirana kao kombinacija kopija osnovnih maski.Sofisticirane funkcije nadodaju se ručno.



Primjer, univerzalni modul za tabličnu obraduSadrži samo osnovne objekte i pozive na standardne procedure (metode) za obradu događaja vezanih uz te objekte.U trenutku aktiviranja obavlja se prilagodba tablice za obradu podataka strukturi tablice podataka.



Univerzalni modul za pojedinačnu obraduSadrži objekte za posluživanje standardnih funkcija te po jednu instancu objekata za prikaz/obradu podataka, koji se prilikom aktiviranja modula dinamički umnažaju sukladno strukturi tablice.Unaprijed se ugrađuju pozivi standardnih procedura vezanih uz standardne funkcije te objekte za prikaz/obradu podataka Dizajn sučelja


Sučelja

Korisnička sučeljatekstovna, grafičkamasovni unos (batch input) - periodičko pretipkavanjeinteraktivni unos (on-line) - na mjestu nastanka

Automatizirani unosbiometrijski uređaji - otisci prstiju, uzorci glasaelektromagnetski uređaji - identifikacija objekata s pomoću radio valovamagnetski uređaji - magnetske kartice i drugooptički čitači -

• optical-mark reader (OMR), • optical-character reader (OCR)

pametne kartice (smart cards) - mikroprocesor, memorija, baterijauređaji osjetljivi na dodir - touch screen, touch-pad, pen-based

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


Elementi grafičkog sučelja za unos podataka

Text Box i varijanteslobodni tekst

Radio Buttonvrijednosti iz konačnog malog skupa unaprijed poznatih, međusobno isključivih vrijednosti (2 do 3)

Check Boxbinarne vrijednosti, opcionalno "nepoznato"

Drop-Down ili Combination (Combo) Box

umjereno velik broj (?) poznatih (?), međusobno isključivih vrijednosti

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

Spin (Spinner), DomainUpDown, NumericUpDown

nevelik slijed diskretnih vrijednosti

Grid – mreža, matricakombinacije osnovnih elemenata


Oblikovanje i standardizacija sučelja

Organizacija sučeljaProgramska oprema mora imati standardan izgled zaslona.

– U svakom trenutku mora biti vidljiva informacija o dijelu obrade, vrsti prikazanih podataka, količini podataka te mogućim akcijama.

• područje za navigaciju - izbornici, pregled podataka• područje za prikaz statusa obrade• radno područje - rad s podacima

Sučeljem moraju biti podržane različite vrste izbornika (npr. vertikalni i kružni) uz mogućnost brzog odabira (funkcijskom tipkom ili slovom opcije).

• horizontalni izbornik (menu bar) - uvijek vidljiv, lako dohvatljiv• padajući (pull-down) i kaskadni - "nevidljivi", ali se opcije daju grupirati• skočni (pop-up) - nije očigledno da postoje, skaču na različitim mjestima• trake s ikonama (toolbar) - vidljivi, pamtljivi, problem ikona i skrivanja

Tipke za obavljanje standardnih funkcija moraju biti definirane pažljivo i jednoznačno, a unaprijed treba predvidjeti i one za aktiviranje dodatnih funkcija.

DOSLJEDNOST SUČELJA NUŽAN JE UVJET KOJI PROGRAMSKA OPREMA MORA ISPUNITI.



Primjer, standardni izgled zaslona



Ergonomija sučeljaPolja zaslonske maske moraju biti logički grupirana. Unos se mora obavljati u slijedu kojim su polja fizički poredana.Treba ustrajati na preglednosti podataka i minimizirati prekrivanje informacija (na primjer, u slučaju više istovremeno prikazanih "prozora"). Sučelje mora imati ujednačene standardne poruke, zvučne signale i upozorenja, kojima se pruža dovoljna informacija, a korisnik nepotrebno ne opterećuje.Poruke moraju biti jednostavne, precizne te ovisne o kontekstu. Izbjegavati računalski žargon i kratice.Svakako mora biti ugrađena interaktivna pomoć ovisna o kontekstu.Prilikom izgradnje sučelja treba ukloniti ili prevesti poruke na stranom jeziku (na primjer, one koje koje dojavljuje SUBP) i izbjegavati stručne izraze.


"Školski" primjer grafičkog sučelja


Drugi primjer grafičkog sučelja


Treći primjer grafičkog sučelja


Opći zahtjevi na funkcionalnost

Funkcionalnost sučeljaPoželjno je da se traženje, unos i izmjena podataka obavljaju na istom zaslonu i na isti način.Treba omogućiti prekid akcija koje predugo traju, pod uvjetom da se tim prekidom ne narušava integritet podataka (npr. selekcija velikog broja zapisa, prekid transakcija).U svakom dijelu obrade treba omogućiti odustajanje uz potvrdu korisnika da se to stvarno želi (pr. brisanje).Upozorenja i potvrde prekida pohrane podataka treba provoditi samo ukoliko je stvarno došlo do promjene.Unesene podatke treba provjeravati što ranije, po mogućnosti neposredno nakon promjene sadržaja zaslonskog polja.Na polju za unos šifara treba omogućiti odabir iz suženog skupa podataka smještenih u šifarnik. Suženje skupa treba moći obaviti na temelju dijela tekstovnog opisa šifre uz mogućnost uporabe metaznakova.Svakako treba korisniku omogućiti pregled teksta koji će se zapisati u izvješće. Pregled na zaslonu uklanja potrebu za ispisom na papir i olakšava 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.


Ulančavanje procedura

Često se događa da dio rada treba poništiti zbog toga što u sustavu ne postoji šifra koju se želi uporabiti, a nije ju moguće pohraniti.

Problem: korisnik je prisiljen …• poništiti do tog trenutka unesene podatke,• proći kroz nekoliko izbornika do šifarnika,• pohraniti novu šifru,• vratiti se na mjesto gdje je ona bila potrebna,• ponoviti unos prije poništenih podataka i tek tada ih pohraniti.

Rješenje: na polju za unos vrijednosti stranog ključa treba• otvaranje “prozora” s listom za pregled i odabir zahtijevanog podatka uz

prikaz svih zapisa u odgovarajućoj tablici• otvaranje liste za pregled uz prikaz ograničenog 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 moguće, treba smanjiti broj postupaka za jedan poslovni proces da korisnici ne bi ponavljali iste akcije.

Primjer, stablasta struktura taksonomije

Subkingdom

Taxon

Synonym

SpecieOriginator SubspecieOriginator

Aggregate

Genus

Family

Order

Subclass

Class

CommonName

Subdivision

Kingdom

OriginatorDivision




Organizacija modula i aplikacijaPri izradi prve globalne podjele modula i definiranju izbornika treba:

pažljivo grupirati poslovne procese u sustave procedura,dati prednost učestalijim 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, dužnosti, ustrojna mjesta)– Tijek službe (prijam, služba, posebna stanja, izlaz)– Dodjela činova i redova, ocjenjivanje– Dodjela odličja i medalja– Školovanje (povijest, izobrazba u HV)– Evidencija prekršaja, mjere– Razno (naknade, doplatci, …)– Šifarnici (korisnički i “sistemski” promjenjivi)– Administriranje sustava (baze podataka, korisnika, zaštite)

Postupakpočetni sustav kao skup modula za obradu podataka u jednoj tablici, pri čemu svaki od njih podržava standardne funkcije i poziva druge modulepostupno udruživanje i reorganizacija modula uz naknadno razdvajanje sistemskih od korisnički promjenjivih elemenata

Ovakav način izrade programske opreme zahtijeva veći početni trud, ali dugoročno donosi prednosti.


Organizacija modula i aplikacija

Početni sustav - moduli pune i reducirane funkcionalnostiPočetni sustav sastoji se od početnog izbornika i izvedbenih programa Pi, (i=1,…,n), koji sadrže glavni program Mi za poziv izbornika standardnog modula, skup standardnih funkcija {F}i te pridruženi reducirani skup funkcija {R}i.

R1

P1

F1

M1

R2

P2

F2

M2

Rn

Pn

Fn

Mn

Ri

Pi

Fi

Mi

x xxxxx x xxxxx x xxxxx x xxxxx x xxxxx x xxxxx x xxxxx x xxxxx x xxxxx x xxxxx x xxxxx x xxxxx

ο ο ο ο ο ο

Generatedmenu


Organizacija modula i aplikacija

Sustav nakon reorganizacije i kodiranja modulaHijerarhijski izbornik proizvoljne dubine nad ν izvedbenih programa koji sadrže udruženi glavni program M’j , μ(j) skupova standardnih funkcija, π(j) reduciranih skupova funkcija te ρ(j) skupova ručno ugrađenih funkcija, (j=1,…,ν)

x xxxxx x xxxxx x xxxxx




οοο

P'1

R'11F'11

M'1

H11 R'1π(1) H1ρ(1)

οοο

F'1μ(1)

P'ν

R'ν1F'ν1

M'ν

Hν1 R'νπ(ν) Hνρ (ν)

οοο

F'νμ (ν)

Hierarchicalmenu

Objektno usmjereni pristup

OOAD, OOLC


Slučajevi korištenja

Use case = Slučaj korištenja (primjene)Skup scenarija sa zajedničkim ciljem korištenja sustava

Scenarij - niz koraka koji opisuju interakciju korisnik-sustavPrimjer scenarija

• Kupac pregledava Web katalog i stavlja proizvode u košaricu. Kada odluči platiti, unosi podatke o otpremi i kreditnoj kartici te potvrđuje kupnju. Sustav provjerava autorizaciju kartice i potvrđuje prodaju interaktivno te putem elektroničkog pisma.

Autorizacija kreditne kartice je međutim mogla ne uspjeti!• Ovo bi bio posebni scenarij.


Primjer: Kupi proizvodKupi proizvod1. Kupac pregledava Web katalog i stavlja proizvode u košaricu2. Kupac odluči platiti3. Unosi podatke o otpremi4. Sustav prikazuje punu informaciju cijeni, uključujući otpremu5. Kupac unosi podatke o kreditnoj kartici6. Sustav autorizira kupnju7. Sustav potvrđuje prodaju interaktivno8. Sustav šalje elektroničko pismo potvrde.Alternativa: Neuspješna autorizacija

U koraku 6, sustav ne uspijeva autorizirati karticuDozvoliti kupcu ponovni unos podataka o kartici

Alternativa: Redoviti kupac3a. Sustav prikazuje informaciju o otpremi i cijeni te zadnje četiri znamenke broja kreditne kartice3b. Kupac potvrđuje prikazane pretpostavljene podatke ili unosi noveNastavak u koraku 6 primarnog scenarija


Dokumentiranje slučajeva korištenja

Dokumentiranje slučajeva korištenjaRadi se dokument toka događajaPiše se sa stajališta korisnikaSadrži detalje o tome što sustav mora omogućiti kada se izvršavaju pojedini slučajeviElementi obrasca za opis slučaja korištenja

• Autor• Datum• Slučaj korištenja• Sudionik (entitet, actor)• Opis• Normalni tok• Alternativni tok• Pred-uvjeti• Post-uvjeti• Pretpostavke


Primjer UC (1)


Primjer UC (2)


Modeliranje zahtjeva na temelju scenarija

UC specificira namjeravano ponašanje sustava.Prikazuje skup sljedova akcija, uključujući varijante.Reprezentira funkcionalni zahtjev na sustav kao cjelinu.

Koristi seZa opis zahtjeva korisnika u ranoj analizi.Za validaciju arhitekture i verifikaciju sustava u kasnijim fazama.

Analiza slučajeva korištenja (Use Case Analysis)tehnika analize poslovnih procesa iz perspektive korisnikaslučajevi korištenja uobičajeni su u metodama objektne analize, u kojima se crtaju kao dijagrami, se ali se koriste i u drugim modernim metodama

Opći standard izrade UC-a ne postoji.Čak ni UML ne specificira UC standard!U prethodnom primjeru alternativa Redoviti kupac mogla je biti zasebni slučaj korištenjaPostoje također dodatni elementi, npr. pretpostavke koje moraju biti zadovoljene da bi slučaj započeo


Dijagrami slučajeva korištenja

Sudionik, glumac (actor)Uloga koju ima korisnik u odnosu na sustavNetko ili nešto u uzajamnom djelovanju (interakciji ) sa sustavomProučava se da bi se odredile njegove potrebe

Slučaj ponašanja (use case)Primjer, uzorak, obrazac ponašanjaSlijed povezanih transakcija u kojima sudjeluju glumac i sustav

UC dijagrami predočuju veze između glumaca i slučajeva

Naziv sudionika

naziv slučaja korištenja


Vrste veza

asocijacija (association) – veza komunikacije u kojoj oba objekta mogu slati i primati porukeuključivanje («include») – povezuje dijelove ponašanja istovrsne ili slične za više slučajeva ponašanjaproširenje («extend») – za varijacije normalnog ponašanja uz dodatna pravilageneralizacija (generalization), poopćenje sličnog slučaja Specijalizirani slučaj "dijete" nasljeđuje ponašanje i značenje općeg slučaja "roditelj"

Dijete može dodati ili prekriti ponašanje roditeljaDijete može supstituirati roditelja gdje god se pojavi


Dijagram slučajeva korištenja



Objektno usmjerena paradigmaentiteti iz stvarnog svijeta opisuju se apstraktnim objektima (razredima, klasama objekata)integracija oblikovanja podataka i procesatokovi podataka, entiteti i veze te procesi integrirani u objektesloženi sustavi grade se iz pojedinačnih komponenti.

PROIZVOD

SifProizvoda#NazProizvodaTipProizvoda

DodajProizvod()BrisiProizvod()IzmijeniProizvod()

IGLA

DuljinaPromjer

RacunajMasu()

AVION

BrSjedalaDoletKM

RacunajMasu()

Dodaj proizvod (Igla štrikača 05)

RacunajMasu(Igla štrikača 05)



Elementi objektnog modelaobjekt - svaka pojava, pojam ili predmet (stvarni ili zamišljeni) o kojem se prate podatci i načini rukovanja podatcima (procesi)tip objekta ili razred objekta (abstract data type, class) – generalizacija grupe objekata, zajednički naziv za sve objekte sa zajedničkim svojstvima (property) i načinima rukovanja (process, method), npr. Proizvodpojava objekta (object instance) – pojedinačna pojava nekog tipa objekta, s vlastitim vrijednostima svojstava, npr. Igla štrikača 05, B-2učahurivanje (encapsulation) - podatkovne strukture i procedure povezuju se u cjelinu tako da su detalji ugradnje sakriveni objekti su “crne kutije” čijim se podacima rukuje putem ugrađenih metodarazmjena poruka (messaging) – objektu se šalje poruka da bi izveo neku od svojih metoda, npr. Dodaj proizvodnasljeđivanje (inheritance) – podrazred (subclass) nasljeđuje svojstva i metode nadrazreda (superclass), npr. Igla i Avion nasljeđuju Proizvodvišeobličje (polymorphism) – postupci koje objekti različitih razreda tumače zavisno o specijalizaciji objekta, npr. RacunajMasu(Igla štrikača 05)



Cilj objektno usmjerenog pristupa je analizirati stvarni sustav na takav način da se za potporu njegovom djelovanju može oblikovati programski sustav koji se velikim dijelom gradi od prije definiranih objekata.

Ukoliko se izrađuju jedinstvena rješenja (unikati) po mjeri unaprijed poznatog korisnika, onda primjenjivost ovog pristupa može postati upitna.

Neke objektno usmjerene metodeOMT (Object Modelling Technique)BOOCH (Booch’93)Schlaer-Mellor

Programska izvedba objektno usmjereni jezici, npr. Smalltalk, Eiffel, Java, C#hibridni jezici (3GL s objektnim svojstvima), npr. C++ i VBasic



Faze objektno usmjerenog razvoja ISFaza određivanja svih mogućih slučajeva (UC - Use Case)

• određuju se “svi mogući” scenariji interakcija u sustavuObjektno usmjerena analiza (OOA - Object Oriented Analysis)

• definiraju se razredi objekata kojima će se točno opisati sustav OO model područja primjene

– proučavanje postojećih objekata da bi se vidjelo mogu li biti ponovno iskorišteni ili prilagođeni za nove primjene

– definiranje novih ili modificiranih objekata koji će se kombinirati s postojećim objektima u novu aplikaciju

Objektno usmjereno oblikovanje (OOD - Object Oriented Design)• definira stvarne klase i objekte te njihove mehanizme, pri čemu se određuju

detalji o budućim fazama OO model softverskog sustava– razrada definicija zahtjeva na objekte napravljenih tijekom analize– revizija karakteristika podataka i procesa– definiranje novih skupova objekata, npr. objekata sučelja za oblikovane podatke

Objektno usmjereno programiranje (OOP - Object Oriented Programming)• programski se ugrađuju klase i njihove međusobne veze

Faza procjene (OOE - Object Oriented Evaluation)• evidentiraju se pogreške i problemi


UML

UML = Unified Modeling LanguageObjedinjeni (univerzalni) jezik za modeliranjeStandardni jezik za prikaz, specifikaciju, izradu i dokumentiranje elemenata sustava zasnovanih na programskoj podršciProširenje osnovne funkcionalnosti stereotipovima (“kalupima”)Može se koristiti tijekom cijelog životnog ciklusa razvoja i preko različitih tehnologija ugradnje

Sadrži koncepte zaModeliranje podataka (Entity Relationship Diagrams)Modeliranje poslovnih procesa (Business Modeling - workflow)Modeliranje objekata (Object Modeling)Modeliranje komponenti sustava/softvera (Component Modeling)


Vizualno modeliranje

Dijagrami strukture, Strukturalni dijagrami

Class DiagramObject DiagramComponent DiagramDeployment Diagram

Dijagrami ponašanjaUse Case DiagramSequence DiagramCollaboration DiagramStatechart DiagramActivity Diagram

Prikaz granica sustava i njegovih glavnih funkcija prikazom slučajeva korištenja i sudionika (glumaca)Ilustracija izvršenja slučajeva korištenja dijagramima interakcijePrikaz statičke strukture sustava dijagramima razreda i dijagramima objekataModeliranje ponašanja objekata dijagramima prijelaza stanjaPrikaz fizičke ugradnje arhitekture dijagramom komponenti i dijagramom razvijanja

Dijagrami razreda

Class Diagrams


Razredi

Razred (class) = kolekcija, skup objekata sa zajedničkom strukturom, zajedničkim ponašanjem, zajedničkim vezama i zajedničkom semantikom, na primjer cOsobaObjekt – pojedinačna pojava (objekt, instanca) iz nekog razreda, na primjer Zagor i Čiko razreda cOsobaDefiniranje razreda

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

/ * autor: Hrvoje Novak */Class Osoba {private string ime;private string prezime;public string PrezimeIme () {return ime + " " + prezime;

}}


Dijagrami razredaDijagrami razreda (Class Diagrams)

Prikaz statičke strukture sustava, odnosno njegovih elemenata (pr. razredi i tipovi), te njihovih međusobnih odnosa. Dijagram razreda može sadržavati i sučelja (interfaces), pakete (packages), odnose (relationships) te instance kao što su objekti (objects) i veze (links). Bolji naziv bio bi 'statički strukturni dijagram' (static structural diagram).

Elementi dijagramaRazredi, njihova struktura i ponašanje (atributi i operacije)

Statički odnosiObične veze ili asocijacije (associations)

• npr. "korisnik posuđuje više video-kazeta"Gomilanje ili udruživanje, agregacija (aggregation),

• npr. "motor je dio aviona" Zavisnost (dependency) i nasljeđivanje (inheritance)

• npr. "bolničarka je osoba"Dodatne oznake

Indikatori množine, mnogostrukosti (multiplicity) - kardinalnostIndikatori upravljivosti, navigabilnosti (navigability) – smjer povezivanjaUloge (role names)


Vidljivost atributa i operacija

Implementacijskaunutar paketa

~

Privatna (private)unutar razreda, članovima

-

Zaštićena (protected)unutar razreda/podrazreda

#

Javna (public)članovi dostupni svima

+

{pravo pristupa private

pravo pristupa public {{pravo pristupa protected

Odjel

- naziv: Name- nastavnici: Nastavnici[]

# dodajNastavnika()# ukloniNastavnika()+ dohvatiNastavnika()+ dohvatiSveNastavnike()


AsocijacijeVeze između objekata

Svaka asocijacija ima dva završetka asocijacije (association ends), od kojih je svaki spojen s jednim razredom.

Uloge (role)labele na kraju veze, postavljaju se bliže razredu na koji se odnosemogu se izostaviti

Ograničenja (constraint)uvjet povezivanja

Indikator mnogostrukosti (multiplicity)kardinalnost

Indikator upravljivosti (navigability)strelica označava smjer povezivanjajednosmjerna - preporuča se tamo gdje nema posebnih uloga, mora se navesti ako postoji ulogadvosmjerna (standardno)može uključiti stereotip (npr. «friend»)


Mnogostrukost

Označava broj objekata koji sudjeluju u veziPrikazuje s koliko se objekata JEDAN objekt može povezatiGleda se nezavisno za svaku stranu veze

Najčešće upotrebljavane oznake za mnogostrukost u praksi su 1, *, 0..1 (jedan ili niti jedan). Za prikaz mnogostrukosti možese koristiti diskretan broj

npr. 11 za broj članova nogometne ekipe), niz brojeva (npr. 2..4 za igrače koji sudjeluju u kartaškoj igri),kombinacije diskretnih brojeva ili brojeva u nizu (npr. 2, 4 za broj vrata na automobilu).

Od jednog do N objekata gdje je N>11..N

Od nula do N objekata gdje je N>10..N

Samo N objekata gdje je N>1N

X, Y ili Z objekataX,Y,Z

Jedan ili više1..*

Niti jedan ili više0..* ili *

Samo jedan1

Niti jedan ili jedan0..1

ZnačenjeIndikator


Dijagram razreda (class diagram)


Upravljivost

Primjer: odgovornost od narudžbe prema kupcu

Specifikacijski, Upravljivost ukazuje na to da za svaku narudžbu moramo znati kojem kupcu ona pripada. Za pojedinog kupca ne moramo znati sve njegove narudžbe.

Implementacijski, Upravljivost pokazuje da razred Narudžba ima pokazivač na razred Kupac, ali razred Kupac ne mora imati pokazivač na razred Narudžba.

Konceptualno, upravljivost nema neko posebno značenje


PrimjerPerson Company

-employee

1..*

-employer

0..1

WorksFor

// Person ima jednoznačnu vezu prema Company, pa // getCompany može vraćati vrijednost tipa Companyclass Person {

private Company _Employer;public Company getCompany() ;

}

// Company ima višeznačnu vezu prema Person, pa // getPersons vraća kolekciju ili Vektor objekata// razreda Person.class Company {

private Set _Employees;public Set getPersons_collection();private Vector _Persons;public Vector getPersons_vector();

}


Generalizacija

Odnos između općenitog i njemu određenijeg elementanadređeni razred ili tip (superclass, supertype)podređeni razred ili tip (subclass, subtype)

Sve što vrijedi za nadređeni element vrijedi i za podređeni element, ali ne i obrnuto

Strelice označavaju odnose derivacija: proširuje, implementira, "je tipa", "imaobilježja od", itd.

Primjer: Osoba je Fizička osoba ili Pravna osoba diskriminator


Generalizacija


Tumačenje generalizacijeKonceptualno

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 možemo reći o razredu Kupac – asocijacije, atributi, operacije, također vrijedi za razred Pravna osoba.

Specifikacijski (subtyping, nasljeđivanje veza)Generalizacija znači da sučelje podtipa mora uključiti sve elemente sučelja nadtipa. Za sučelje podtipa kaže se da je usklađeno sa sučeljem nadtipa.

Implementacijski (subclassing, implementacijsko nasljeđivanje)Podrazred nasljeđuje sve postupke i atribute nadrazreda, te može sadržavati jošneke, sebi svojstvene postupke.Podtipovi se mogu ugraditi i putem delegata bez korištenja podrazreda - Gamma, Helm, Johnson i Vlissides (1995) - primjeri korištenja dvaju razreda s istovrsnim vezama bez upotrebe podrazreda. Fowler (1997) prikazuje još neke druge načine implementacije podtipova.


Nasljeđivanje, višeobličje i zamjenjivost

NasljeđivanjeOmogućuje definiranje (deriviranje) novog razreda na temelju postojećeg razreda

Višeobličje (polymorphism)Operacija deklarirana u osnovnom razredu biva poništena u korist operacije jednako deklarirane u naslijeđenom razredu.Podtip na pojedine naredbe daje drugačiji odgovor u odnosu na nadtip ili neki drugi podtip.Gledajući sa strane pozivatelja, ta razlika nije bitna.

Zamjenjivost (supstitutability)Razred je podtip osnovnog razreda ako je u aplikaciji moguće zamijeniti osnovni razred podtipom, a da aplikacija normalno nastavi s radom. Drugim riječima, ako postoji kôd koji se odnosi na nadtip Kupac, umjesto njega može se supstituirati bilo koji njegov podtip.


Primjer nasljeđivanja

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(); // introduced in derived class

Kupac k = f; // subclass as base classk.pisiAdresu();


Agregacija

Agregacija (aggregation), sadržavanje, obuhvaćanjeposeban oblik asocijacije: veza "dio-od", "cjelina-dio"odnos se može kvantificirati mnogostrukost

Komponente su dijelovi objekta-agregata, takvi dadio može nastati i postojati nezavisno od cjelineuništenje "cjeline" ne uništava njene dijelove

Objekt može pripadati u više cjelinaistu instancu nekog objekta može dijeliti više agregata

Agregacija je jednosmjerno tranzitivnaali objekt (instanca) ne može biti svoj sastavni diopr. Organizacijska struktura poduzeća


Kompozicija

Kompozicija (Composition)"stroža" varijanta agregacijeobjekt može pripadati samo jednoj cjelini

Elementi postoje tako dugo dok postoji cjelina kaskadno brisanje, tj. uništenje sastavnih objekata

Kompozicija nije tranzitivna agregacija i generalizacija jesu

Ne postoji u Javi !Primjer C++

class Prozor {Obj *scrollbar;Obj naslov;

public:Prozor() { scrollbar = new Obj; }~Prozor(){ delete scrollbar; }

};


Agregacija i kompozicija

* * * 1..*

pohađa

1..** *

predaje

0..1predstojnik

polaznik

1..*

1..*1

ima

0..1

1..*

1..*

pridružen

Fakultet{persistent}

dodajStudenta()ukloniStudenta()dohvatiStudenta()dohvatiSveStudente()dodajOdjel()ukloniOdjel()dohvatiOdjel()dohvatiSveOdjele()

naziv: Nameadresa: Stringtelefon: Number

Odjel{persistent}

dodajNastavnika()ukloniNastavnika()dohvatiNastavnika()dohvatiSveNastavnike()

naziv: Name

Predmet{persistent}

naziv: NameMBodjela: Number

Student{persistent}

naziv: NameMBstudenta: Number

Nastavnik{persistent}

naziv: NameMBnastavnika: Number

31

Studomat

+ prijaviIspit()+ odjaviIspit()

StudentskaSlužba

+ dohvatiStudomat()+ dohvatiSveStudomate()+ azurirajStudomat()+ azurirajSveStudomate()

- studomati: Studomat


Primjer agregacije i rekurzijeclass 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 kompozicijeclass StudentskaSluzba{public:

StudentskaSluzba();virtual ~StudentskaSluzba();void dohvatiStudomat();void dohvatiSveStudomate();void azurirajStudomat();void azurirajSveStudomate();

private:Studomat studomati[3];

};StudentskaSluzba

::~StudentskaSluzba(){delete [] studomati;

}

class Studomat{public:

Studomat();virtual ~Studomat();void prijaviIspit();void odjaviIspit();

};

31

Studomat

+ prijaviIspit()+ odjaviIspit()

StudentskaSlužba

+ dohvatiStudomat()+ dohvatiSveStudomate()+ azurirajStudomat()+ azurirajSveStudomate()

- studomati: Studomat


Asocijacijski razred

Asocijacija s obilježjima razreda - razred s obilježjima asocijacijeKoristi se kada se od razreda zahtijeva da definira odnose.Nastaje dodavanjem atributa i operacija asocijacijiograničenje: smije postojati samo jedna instanca asocijacijskog razreda za par povezanih objekata, inače postaje pravi razred

Ponekad je potrebna dodatna veza za prikaz vlasništva Primjer: veza između osobe i avionske karte


Sučelja i apstraktni razredi

Sučelje (interface) - Specifikacija vanjski vidljivih postupakarazreda ili komponente bez implementacije.

Sadrži samo deklaracije (prototipove) operacijaČesto specificiraju samo ograničeni dio ponašanja razreda.Mogu se generalizirati.

Deklarira se apstraktnim razredomU C++, sučelje je razred koja sadrži čiste virtualne postupke. Java ih direktno podržava, npr. "abstract class" može sadržavati definicije za postupke i polja uz apstraktne deklaracije.

Realizacija (realisation): veza izvornog razreda i sučeljaProširena i skraćena (lollipop) notacija


Primjer prikaza sučelja

+create()+login(UserName, Passwd)+find(StoreId)+getPOStotals(POSid)+updateStoreTotals(Id,Sales)+get(Item)

-storeId: Integer-POSlist: List

Store

POSterminal

POSterminalHome

<<use>>

StoreHome

Store

POSterminal

+create()+login(UserName, Passwd)+find(StoreId)+getPOStotals(POSid)+updateStoreTotals(Id,Sales)+get(Item)

-storeId: Integer-POSlist: List

Store

POSterminal

POSterminalHome

<<use>>

StoreHome

POSterminal

+getPOStotals(POSid)+updateStoreTotals(Id,Sales)+get(Item)

<<interface>>Store


Objektni dijagrami

Objektni dijagram (Object diagram)Sadrži aktualne (instancirane) objekte te, opcionalno, razrede kojima ti objekti pripadajuKoriste se za ilustraciju ili objašnjenje nekog trenutka

order: return := event3 (arg4 ..)Object1: Class1arg1 = value1

Class1

Object2: Class2arg2 = value2

instantiates

data flow

Synchronisation- simple- synchronous- balking- timeout- aysnchhronous

AdornmentsA - association linkF - object fieldG - global variableL - local variableP - procedure parameterS - self reference


Razredi i instance objekata

Prikazuje seNaziv objekta (potcrtano)Naziv razreda (opcionalno)Vrijednost atributa (opcionalno)Task

setStartDate (d : Date = default)setEndDate (d : Date = default)

Assignment 1: TaskstartDate = 1.2.04endDate = 23.2.04



<<instanceOf>><<instanceOf>>

<<instanceOf>>

startDate : Date = 1.1.01endDate : Date = 1.6.01


Primjer objektnog dijagrama

Dijagram objekata

NarudzbaProdavatelj

stavka2:

Stavka

Kupac

stavka1: Stavka

stavka3:

stavka2:

stavka1:

stavka1:

Dom i vrt : Kupac

Nar 121: Narudzba

Krkatone :

: Narudzba

Štefica Cvek

Dijagram razreda

imenovana instanca

anonimna instanca

instanca siroče

Dijagrami interakcije

Interaction Diagrams


Realizacija slučajeva korištenja

UC dijagrami prikazuju vanjski pogled na sustavDijagrami interakcije

opisuju realizaciju slučajeva korištenja, pri čemu jedan dijagram uobičajeno prikazuje ponašanje pojedinačnog slučaja korištenjaprikazuju objekte sustava i njihovo međusobno djelovanjeopisuju ponašanje više objekata i poruke koje se razmjenjuju između tih objekata

Vrste dijagrama interakcijeDijagrami slijeda (Sequence diagrams) – vremenski pogledDijagrami suradnje (Collaboration diagrams) – organizacijski pogled


Dijagram slijedaPrikaz 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

NotacijaKućice predstavljaju objekte, ne razrede. Nazivu se može dodati ":class".Objekti i/ili razredi prikazani horizontalno na vrhu isprekidanih vertikalnih crta, linija životaPoruke prikazane strelicama između linija života objekata koji komunicirajuLinija života (lifeline): život objekta za vrijeme interakcije

Poslane porukePovratak iz metode

može se crtati za svaku poslanu poruku, ali je dijagram čitljiviji ako se podrazumijeva da postoji, a crta samo tamo gdje je to nužno radi jasnoće


Primjer slijeda


Tumačenje dijagrama slijedaObjekti

prvi stupac: uobičajeno sudionik koji inicira slučaj korištenjadrugi stupac: granični objekt (boundary object), kojim sudionik pokreće slučaj korištenjaostali stupci: objekti koji upravljaju slučajem korištenja

PorukePoruka predstavlja poziv postupka referenciranog objektaPoruke se označavaju barem nazivom porukeOznaka se može proširiti argumentima poruke te povratnim vrijednostima i/ili upravljačkim informacijama

Vremenska osnelinearna, određena događajimačita se s vrha prema dnuprikazuje redoslijed, a ne stvarno vrijeme

Linija života objektapovezuje postojanje i cjelokupno ponašanje objektaredoslijed linija nema posebno značenjeIzlomljena linija života označava da objekt nije aktivan, kvadrat označava da je objekt aktivan.


Pokretanje slijeda

Sudionik, događaj, granični objekt i operacija


Stvaranje i uništenje objektaPoruka može inicirati stvaranje novog objekta• Nova instanca pojavljuje se na kraju

strelice poruke za stvaranje.Aktivacijski odjeljak (activation box): oznaka da je objekt aktivan

u slučaju proceduralne interakcije, to može značiti da je na stogu

Uništenje objekta (deletion, destruction):

objekt uništava sam sebe ili ga drugi unište slanjem porukeUništavanje se obavlja prekidom linije života velikim X


Vrste poruka

Jednostavna: tumači se kao asinkrona

Sinkrona: "pozivi", prikazani punim vrhom strelice, pri čemu pozivatelj čeka na završetak aktivirane metode

Asinkrona: "signali", prikazani polu-strelicom, čime se označava da poziv ne blokira pošiljatelja porukePrimatelj odmah odgovara. Pošiljatelj i primatelj rade simultano.


Povratni pozivi i uvjetovane poruke

Asinkroni povratni pozivi (callback)

Povratni poziv pojavljuje se dok Pošiljatelj potencijalno izvodi nešto drugo.Samo-pozivanje (self-call, self-delegation): poruka koju objekt šalje samome sebi

Uvjetovane porukePoruka se šalje samo ako je uvjet zadovoljen.Uvjet je obično izražen implementacijskim jezikom.


Primjer dijagrama slijedaEkran za unos narudžbe šalje poruku pripremi() objektu Narudzba, koji prosljeđuje odgovarajuću poruku pojedinoj stavciSvaka stavka provjerava danu stavku skladišta i ovisno o tome pokreće daljnje akcije

Unos naružbe Narudžba

Stavka narudžbe

Stavka skladista

1: pripremi()2: * pripremi() 3: provjeri()

4: [check = true]ukloni() 5: ponovnoNaruci()

Iteration

Condition

Self delegation

AsynchronousMessage

Activation

Ponovljena stavka

6: [ponovnoNaruci = true]<<create>>


Primjer: Web kupovina


Dijagram kolaboracije, suradnje

Prikaz interakcije objekata koji naglašava međusobnu povezanost objekataKoristi se notacija slična dijagramima slijedaNe pokazuje vrijeme kao posebnu dimenziju, pa slijed interakcijamora biti označen rednim brojevima poruka.


Označavanje poruka

Označavanje rednim brojevima (1, 2, 3, ...)problem pri umetanju

Označavanje "decimalnim" brojevima (1, 1.1, 1.2, 2, 2.1, 2.2, ...)jasnije označavanje koja operacija koju zove"decimale" ukazuju na ugniježdene poruke, to jest one koje su poslane dok je početna još aktivnateže praćenje ukupnog slijeda

Proširenjaslovčane oznake za višetnitne operacijeoznačavanje povratnih vrijednosti


Primjer dijagrama suradnjeJ.Rumbaugh, I. Jacobson, G. Booch : The Unified Modeling Language

Reference Manual. Addison Wesley, 1999, fig 13-51 page 202


Dijagram slijeda naspram dijagrama suradnje

Dijagrami slijedanaglasak na izmjeni poruka u vremenukoriste se pri određivanju redoslijeda poruka

Dijagrami suradnjebolja preglednost scenarija i veza između objekatakoriste se pri određivanju veza između razreda

Obje vrste dijagrama moraju biti jednostavne i pregledne, što je u praksi dosta teško postićiNajčešće se za konkretnu situaciju radi samo jedna vrsta dijagrama


Prikaz suradnje dijagramom slijeda

Opis suradnje može se nadopuniti dijagramom razreda

reklamirati robu

prodavatelj:Stranka kupac 1:Stranka kupac 2:Stranka

dati ponudu

dati ponudu

odbiti ponudu

prihvatiti ponudu

Ponuda

Stranka Roba

**

kupac 1 1

1 *prodavatelj


CRC kartice

CRC = Classes-Responsibilities-CollaborationWard Cunningham i Kent Beck, kasne 80-te, učeći Smalltalknadomjestak za dijagrame suradnje

primjer

RazredOdgovornosti Suradnici

opis svrhe razredazadaci razreda

(kasnije postaju operacije razreda)

razredi koji zahtijevaju izvršenje zadataka

NarudžbaOdgovornosti Suradnici

provjeri raspoloživost robe na sklad.odredi cijenu robe

provjeri valjanost plaćanjaotpremi robu

StavkaNarudzbe

Kupac

Dijagrami stanja

State Diagrams


Dijagram stanjaPrikaz ponašanja objekta nekog razredaOpisuje mogući slijed djelovanja i stanja kroz koje element može proći za vrijeme svog postojanja kao rezultat reakcije na događaje (npr. signale).

sva moguća stanja objekta razredadogađaji koji uzrokuju prijelaz iz jednog stanja u drugonačin promjene stanja pod utjecajem uzročnih akcija (poruka koje objekt prima)opis ponašanja objekta kroz različite slučajeve korištenja

Stara tehnika koja se pojavljuje pod različitim nazivimadijagram prijelaza stanja (state transition diagram)Harel diagram (statechart, 1987)

Akcija: vezana uz prijelaz stanja, pojavljuje se "brzo" i nije prekidiva

Aktivnost:pridružena stanju, može dulje trajati i može se prekinuti


Elementi notacije

Stanje skup vrijednosti koje opisuju objekt (njegove uvjete/situaciju) u određenom vremenskom trenutkuodređeno zatečenim vrijednostima atributa

Događajizaprimljene poruke ili signaline moraju promijeniti stanje objekta => samo-prijelaz (self-transition)

Opis stanjaentry: akcija koja se obavlja pri ulasku u stanjeexit: obavlja se pri izlasku iz stanjado: aktivnost koja se provodi dok je objekt u nekom stanju (npr. prikaži prozor)on: akcija koja se izvodi kao posljedica određenog događaja


Stanja i prijelazi stanja

Početno stanje (start, Start state)nije dozvoljeno okidanje događajasamo jedno, ali se prijelazi mogu granati

Završno stanje (stop, End state)završava rad (stroja s konačnim brojem stanja)može ih biti više

Prijelaz stanjausmjerena veza koja označava promjenu stanja

Uvjet prijelaza (Guard condition)logički uvjet koji mora biti zadovoljen da dođe do prijelaza stanjaviše uvjeta za promjenu istog stanja su međusobno isključivi

Događaji, uvjeti i akcije prijelaza su opcionalniprijelaz bez događaja započinje čim završi aktivnost pridružena stanju

Initial state State BEvent(arguments ) [condition] / action


Primjer stanja narudžbe

[Nije sve provjereno]/uzmi slijed.stavku

IsporučenoStavka je primljena [neke stavke nisu

na skladištu]

[Sve stavke provjerenei nekih stavki nema]

stanje

Slanje

radi/započnislanje

ČekanjeIsporučeno

početak

/uzmi prvu stavku

aktivnost

[Sve stavke provjerenei sve stavke dostupne]

Stavka je primljena[sve stavke dostupne]

prijelaz

samo-prijelaz

Provjera

radi/provjeristavku

Obustavljeno



Početak dijagrama označen je simbolom početnog stanja. U stanje "Provjera" ulazi početni prijelaz koji čini samo akcija "uzmi prvu stavku". Nakon toga ulazi se u stanje "Provjera", koje sadrži aktivnost "provjeri stavku".

Kad postoji događaj, čeka se njegovo ispunjenje da bi akcija započela. Inače, prijelaz se događa odmah nakon završene aktivnosti.

Prijelazi nakon stanja "Provjera" nemaju događaja. Postoje tri moguća prijelaza nakon stanja "Provjera", s tim da se uvijek samo jedan prijelaz može (i treba) dogoditi.

ako nisu provjerene sve stavke, uzima se slijedeća stavka i vraća se u stanje "Provjera",ako su sve stavke provjerene i dostupne (a to znači da su na skladištu), prelazi se u stanje "Slanje",ako su sve stavke provjerene, ali nisu sve i dostupne, prelazi se u stanje "Čekanje" da roba dođe na skladište.



Stanje "Čekanje"Ne postoji aktivnost u tom stanju, već se čeka na događaj "Stavka je zaprimljena (na skladište)". U slučaju novog događaja, gleda se koji je uvjet ispunjen. U našem primjeru, da li su sve ili samo neke stavke na skladištu.Ako su nakon događaja sve stavke na skladištu, prelazi se u stanje "Slanje", a ako se nakon toga čeka na još barem jednu stavku, vraća se u stanje "Čekanje"

Stanje "Slanje"Aktivnost stanja "Slanje" je "Započni isporuku". Iz ovog stanja postoji jedan, neuvjetovani prijelaz, čiji je okidač događaj "Isporučeno", a ne završetak aktivnosti stanja !Kad završi aktivnost "Započni isporuku", narudžba ostaje u tom stanju dok se ne dogodi događaj "Isporučeno".A prijelaz će se dogoditi uvijek kad nastupi događaj "Isporučeno"…


Kompozitna stanja

Nadomjestak za 3 prijelaza obustavljeno

Provjera

radi / provjeristavku

Slanje

radi / započnislanje

Čekanje

Isporučeno

[Sve stavke provjerenei sve stavke dostupne]

[Nije sve provjereno]/uzmi slijed.stavku

Stavka je primljena[sve stavke dostupne]

[Sve stavke provjerenei nekih stavaka nema]

Stavka je primljena [neke stavke nisu

na skladištu]

Obustavljeno

obustavljeno

Aktivan

Ime kompozitnog stanja


Konkurentna stanja

Primjer: Provedba autorizacijekada aktivnost "Provjeri plaćanje" završi, signalizira da li je plaćanje u redu

• ako plaćanje nije u redu, odbija se zahtjev za autorizacijom, • inače narudžba čeka u stanju "Autorizirano" dok se ne dogodi "Isporuči"

Odbijeno

Autorizirano Isporučeno

[plaćanje nije u redu]

[plaćanje je u redu]

radi/provjeriplaćanje

Autorizacija

isporuči


Konkurentna stanja

Neke promjene mogu se događati istovremeno

Nadstanje s konkurentnim odjeljcimaSamo jedno izlazno/završno stanje

Koje će to biti, ovisi o tome koji se događaj dogodi prije

"Narudžba" može doći u stanje dva moguća istovremena stanja: "Provjera" i "Autorizacija"

Kada narudžba napusti konkurentna stanja, ona je opet samo u jednom stanju.

Provjera Slanje

Čekanje

Isporučeno

Obustavljeno

Autorizacija Autorizirano

Odbijeno

obustavljeno

kraj

Aktivno


Primjena dijagrama stanja

Dijagram stanja ne treba crtati za svaki razred u sustavu.Najbolje ih je koristiti samo za razrede sa zanimljivim ponašanjem te tamo gdje ti dijagrami pomažu bolje razumijevanje ili bolje uočavanje onoga što se događa u sustavu.

Dijagrami stanja dobro opisuju ponašanja jednog objekta u različitim slučajevima korištenja.Dijagrami stanja nisu prikladni za prikaz ponašanja koje uključuje suradnju više objekata.

Tada je bolje kombinirati tehniku dijagrama stanja s drugim tehnikama. Dosta se koriste u sustavima za rad u stvarnom vremenu, te za razrede korisničkih sučelja.

Dijagrami aktivnosti

Activity Diagrams


Elementi dijagrama aktivnostiPrikazuje

ili tok rada (workflow) između objekata nekog slučaja korištenjaili tok upravljanja za neku operaciju

Sadrži tok aktivnosti, ali ne i objektesva (ili većina) stanja su stanja akcijasva (ili većina) prijelaza obavlja se po dovršetku akcija u stanju

Osnovni simbol: stanje aktivnosti (aktivnost)

stanje radnje, npr. proces iz stvarnog svijeta ili izvođenje programske rutine

Ostali simboli su slični onima dijagrama stanja

s dodatkom oznaka ponavljanjaUvjetovano ponašanje

grananja (branches) udruživanja (merges)

Paralelizam, istovremenost procesarazdvajanje, račvanje (fork)spajanje, pripojenje (join)Svaka grana predstavlja nit izvođenja (thread)

Zaprimi narudzbu

Ispuni narudzbu

Nocna isporuka Obicna isporuka

Posalji racun

Zaprimi uplatu

Zatvori narudzbu

[zurna narudzba] [else]

Pocetak

Razdvajanje

Udruzivanje

Kraj

Spajanje

Uvjet

Aktivnost

Grananje


Paralelizam i uvjetne nitiOznake za razdvajanje i spajanje moraju se poklapati

Za svako razdvajanje mora postojati spajanje koje udružuje niti nastale razdvajanjem.Dodatna pravila

Nit koja izlazi iz razdvajanja može 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, može se izbaciti prvo spajanje, a niti koje bi išle u njega tada idu u drugo spajanje. Ovo je skraćeni način zapisivanja koji se koristi da se dijagram pojednostavni.Postoji posebno stanje, tzv. sinhronizacijsko stanje (sync state) koje omogućava sinhronizaciju na mjestima na kojima bi pravilo o parovima razdvajanja i spajanja inače sprječavalo.

Uvjetna nit (conditional thread)ako uvjet u niti koja izlazi iz oznake razdvajanja nije ispunjen, smatra se da je ta nit završila, to jest da se paralelne mogu obaviti do točke spajanja


Primjer skraćenog prikaza i uvjetnih niti

Skuhati tjesteninu Napraviti umak

Zamijesati

Otvoriti vino

[raspolozen za vino]

Uvjetna nit

Razdvajanjeizbaceno izdijagrama


Komponiranje aktivnosti i staze

Zaprimi narudzbu

Ispuni narudzbu

Nocna isporuka Obicna isporuka

Posalji racun

Zaprimi uplatu

Zatvori narudzbu

[zurna narudzba] [else]

Isporuka

SkladisteProdajaKupac

Zahtjevati robu

Preuzeti narudzbu

UplatitiIspuniti narudzbu

Dostaviti robu

Primiti robu


Primjena dijagrama aktivnostiAnaliza slučaja korištenja.

Dijagram aktivnosti dobro pokazuje opći slijed akcija za nekoliko objekata i nekoliko slučajeva korištenjaZa prikaz ponašanja objekata za jedan slučaj korištenja bolje je koristiti dijagram interakcijaNa ovoj razini nije bitno dodjeljivanje aktivnosti pojedinim objektima. Potrebno je dobiti opću sliku ponašanja sustava, te odrediti međuzavisnosti u ponašanju. Aktivnosti se vezuju sa objektima u kasnijim fazama razvoja.

Razumijevanje radnog procesa. Da bi se shvatio poslovni proces i omogućile eventualne izmjene i poboljšanja, poslovni proces se modelira dijagramom aktivnosti. Pri tome je potrebno uključivanje osobe koja je upućena u poslovni proces.

Opisivanje složenih sekvencijalnih algoritama. U ovom slučaju dijagram aktivnosti je samo UML oblik klasičnog dijagrama toka.

Opisivanje višenitnih aplikacija. Dijagramima aktivnosti moguće prikazati paralelizam pa ih to čini pogodnim za prikazivanje višenitnih aplikacija.

Dijagram paketa

Package Diagram


Dekompozicija sustavaProblem podjele sustava u (manje) podsustave

Rimsko načelo: podijeli pa s/vladaj (Divide et impera, Divide and conquer)Podjela sustava u "savladljive" dijeloveStrukturirane metode: funkcionalna dekompozicijaOO analiza i dizajn: grupiranje razreda u cjeline na višoj razini

Paketi (Packages)konceptualno strukturiranje modela sustava

• najčešće prikazuju strukturu, tj. organizaciju izvornog kodau fazi razvoja

Komponente (Components)fizičko povezivanje elemenata sustava

• elementi: fizičke komponente (COM+, CORBA), izvorni kod, dokumentacija tijekom pogona

Naziv paketa GUI.exe


Paketi

Paket = opći mehanizam grupiranja elemenata, logički povezana grupa elemenata modela, dio modela

Koncept grupiranja može se primijeniti na bilo koji element modela, a ne samo na razrede

Elementipodsustavidrugi (manji) paketirealizacija slučajeva korištenjasučelja (interfaces)

Svojstvapojedini element sadržan je samo u jednom paketunazivi unutar paketa moraju biti jedinstvenipaketi tvore imenike (namespace)paketi mogu referencirati druge paketeUML podrazumijeva da postoji anonimni paket-korijen (root package)


Dijagram paketa

Pokazuje pakete i razrede te zavisnosti između njih

To je, zapravo, dijagram razreda koji prikazuje skupove razreda i njihove zavisnosti, ali se nazivom "dijagram paketa" naglašava koji su glavni elementi dijagrama.

Paket se prikazuje s dva odjeljkaU manjem se navodi ime paketa, a u većem sadržaj paketa. U grubljem prikazu, naziv paketa piše se u većem umjesto razreda, a manji odjeljak ostaje prazan.


Ugnježđivanje paketa

Prostor imenaGrupira razrede slične funkcionalnosti.Imenici - C# i C++ namespace

• Izvedeni razredi ne moraju biti u istom paketu.

Vanjski paketi ponekad se nazivaju domene.

Naziv paketa koristi se za tvorbu punog naziva razreda

npr. puni naziv razreda Kamenko u paketu Kremenko je Kremenko.Kamenko

Kriteriji za grupiranje slučajeva korištenja u pakete

potpora određene poslovne funkcijepodrška određenom sudionikusrodni razredi i proširenja (generalizacija, veze)

Ciljlokalizacija promjena u sustavuvisoka povezanost elemenata (cohesion)mala vanjska zavisnost/skopčanost (coupling)

Primjeri pakiranja

Narudžbe

+Narudžba-Stavka

Narudžbe

+Narudžba-Stavka


Primjena dijagrama paketa

Slojevite (višeslojne) arhitekture

Veliki projektikoriste se kad dijagram razreda cijelog sustava ne stane na papir formata A4

TestiranjePonašanje paketa se testira tako da se jedan ili više razreda paketa koriste kao probni razredi.

Smanjenje zavisnostiPaketi ne nude odgovore kako smanjiti zavisnosti u sustavu, ali pomažu vidjeti koje zavisnosti postoje.

Održavanje kontrole nad strukturom cjelokupnog sustavaKad se koriste, lakše se naprave promjene u dobro definiranom sustavu. Primjerice, pri lokalizaciji programske podrške.


Primjer: logička organizacija tankog Web klijenta


Debeli Web

Fizički dijagrami

Physical Diagrams


Dijagrami komponenti

Dijagram komponenti (Component diagram)prikaz organizacije i zavisnosti softverskih komponenti

Komponenta: fizički modul programskog kodaizvorna datoteka, pogonska komponenta (run time) ili izvedbeni program (executable)

Komponenta sliči paketureprezentira fizičko pakiranje programskog kodapojedini razred može se koristiti u različitim komponentama, ali je definiran u samo jednom paketu

Zavisnost komponentiiskazuje na koji način promjena jedne komponente može utjecati na promjenu drugih komponentiprimjeri: zavisnost pri komunikaciji, zavisnost pri prevođenju


Dijagrami komponenti

Komponenta je tipično određena s jednim ili više klasifikatora koji obitavaju (reside) na komponenti.

Podskup ovih klasifikatoraeksplicitno definira sučelja komponente.Sučelja predstavljaju skup usluga koje pružaju elementi komponente.

Tip komponente ima naziv oblika: tip_komponente. Instanca komonente ima i ime i tip oblika ime_komponente : tip_komponente.

Ako se naziv tipa izostavi izostavlja se i dvotočka.

SesijaKupovine<<session>>SesijaKucneKupo

vine

SesijaKupovine

<<focus>>:Narudzba

<<auxiliary>>:NarudzbaPK

<<auxiliary>>:NarudzbaInfo

KucnaNarudzba

Narudzba

<<entity>>050677am:NarudzbaKucnaNarudzba

Narudzba


Generator rasporeda

Planer

GUI

rezervacije

azuriraj

Komponenta

Ovisnost

Sucelje

Zavisnost komponenti


Varijante prikaza

<<reside>>elementi sadržani u komponenti (npr. implementacijski razredi)

<<implement>>fizički element ugradnje

<<focus>>Katalog

<<auxiliary>>KatalogPK

<<auxiliary>>KatalogInfo

KucniKatalog

Katalog

<<file>>KatalogJAR

KucniKatalog

Katalog

<<entity>>KatalogSesijaKupovine

Kosarica

SesijaKucneKupovine

SesijaKupovine

<<session>>

<<entity>>

KucnaKosarica

Kosarica

Katalog

<<auxiliary>>KatalogInfo

<<focus>>Katalog

<<auxiliary>>KatalogPK

<<file>>KatalogJAR

<<reside>> <<reside>>

<<reside>>

<<implement>>

<<entity>>


Dijagram ugradnje

Dijagram ugradnje (Deployment Diagram)Prikazuju konfiguraciju pogonskih elemenata i softverskih komponenti, procesa, i objekata koji žive u njima.

Čvorovi (Nodes): izvršni resursinajčešće sklopovlje

Spojevi (Connections):komunikacijski putevi

Nazivlje: ime_čvora : tip_čvora (opcionalno)

Client

TCP/IP

Server

čvor1 čvor2

komp2

komp1+veza

* *


Čvorovi i komponente

Kombiniranje dijagrama komponenti i dijagrama ugradnje

prikaz fizičke zavisnosti između softvera i hardveralokacije komponenti unutar (distribuiranog) sustavainstance softverskih komponenti koje predstavljaju pogonsku manifestaciju jedinica programskog koda.

AccountServer

DeploysAccountDB.javaAccountMgt.java

AccountServer

AccountMgt.javaAccountDB.java

Server:Host

Korisnik:PC

: GUI.exe

: narudzbe.dll

: izbor.dll

: kontrola_zaliha.dll


Primjer odnosa čvorova i komponenti

Komponente smještene na čvoru, a koje nisu prikazane ugniježdenim simbolima, označavaju se zavisnošću sa stereotipom <<deploy>>

Zavisnost <<become>> prikazuje da se pričuvni broker u nekom trenutku izvođenja seli iz čvora pričuvnog poslužitelja na čvor primarnog poslužitelja dok ostale komponente ostaju tamo gdje jesu.

primarniPosluitelj:AplPosluzitelj

:OdrediKvotu

primarniBroker:Broker

:RacuniDB

pricuvniPosluzitelj:AplPosluzitelj

pricuvniBroker:Broker

:OdrediKvotu :RacuniDB

<<database>>

<<database>>

<<become>>

Izrada sustava


Izrada sustava

Implementacija sustava, ugradnja sustavaizrada novog sustava i isporuka tog sustava u produkciju, to jest svakodnevnu primjenu

Izrada sustavafaza u kojoj se obavlja

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

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

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

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

drugi nazivi: konstrukcija, izvedba, provedba


Kodiranje, programiranje

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

• neizbježno zbog veličine stvarnih problema i složenosti 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)

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

automatsko kodiranje• generiranje programskog koda, sučelja, sheme baze podataka

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

• primjer: 4gl + C


Kodiranje, programiranje

Strukturirano programiranje, Strukturno programiranjetehnika 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 početku, s uvjetom na kraju,

s unaprijed poznatim brojem koraka)• izbjegavanje bezuvjetnih skokova (GOTO naredbe)

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

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

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


Pristup programiranju

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

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


Pristup programiranjuInkrementalni pristup, primjer:

izrađuje se program čija je struktura prikazana slikomprvo se kodiraju sve funkcije, a zatim se udružuju pokretanje programa završava fatalnom pogreškomproblem: kako ustanoviti u kojoj funkciji se nalazi pogreškarješenje: postupnim kodiranjem i udruživanjem 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 sadrži poruku (“tu sam X”)

• prilikom izrade funkcije koja će biti pozvana iz neke druge, još neugrađene funkcije, izrađuje se pogonska funkcija (driver)

Funkcija A ()Poziv B()

Funkcija B()Ispis "Tu sam B"

Funkcija M (a, b, c, …)Program DriverM

Poziv M (1, "test", 3.14, …)

a

b c d

e gf

ih j

l

k

m



Programiranje od vrha prema dolje (Top-Down)

ako funkcija fGornja poziva funkciju fDonja, onda se fGornjakodira i integrira prije fDonjamogući 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 izrađuje beh, a drugi istovremeno radi cdfi

• nakon što su završeni d i odrezak f, treći programer započinje gjklm

prednost: bolja provjera logičkih funkcija (na višoj razini hijerarhije, u kojima se donose odluke) → brže otkrivanje logičkih pogrešaka, manji utrošak odrezakanedostatak: nedovoljna provjera operativnih funkcija (na nižim razinama, obavljaju stvarni posao)

a

b c d

e gf

ih j

l

k

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


Programiranje od dna prema gore (Bottom-Up)

ako se funkcija fDonja poziva iz funkcije fGornja, onda se fDonja izrađuje prije fGornjaredoslijed kodiranja: lmhijkefgbcda

• 1. programer radi heb• 2. programer radi ifc• 3. programer radi lmjkgd• nakon što su završene b, c i

d, pristupa se konačnom udruživanju

prednost: bolja provjera operativnih funkcija, manji utrošak pogonskog kodanedostatak: kasno otkrivanje logičkih pogrešaka

a

b c d

e gf

ih j

l

k

m



Mješoviti (sandwich) pristup prvo se od vrha prema dolje izrađuju logičke funkcije, pr. abcdgjzatim se od dna prema gore rade operativne funkcije, pr. efhiklmprednost: rano otkrivanje logičkih pogrešaka uz bolju provjeru operativnih funkcija

a

b c d

e gf

ih j

l

k

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

Programski standardi i preporuke

Povećanje čitljivostistandardizacijom nazivlja → Standardizacija nazivljaprogramskim komentarima → Programski komentaritehnikom i stilom programiranja → Tehnika i stil programiranjarazličitim označavanjem pojedinih elemenata jezika, kao što su rezervirane riječi, identifikatori, komentari, opcije prevoditelja (različita boja, "veličina" znakova)korištenjem predefiniranih simboličkih oznaka i konstantiizbjegavanjem programskih redaka koji duljinom prelaze širinu zaslonapisanjem po jedne programske naredbe u retkupodjelom sljedova naredbi na odsječke koji su u cjelini vidljivi na zaslonuformatiranjem izvornog koda - pomicanjem u desnu stranu naredbi unutar programskih struktura, tzv. "uvlačenje" (indentation)


Smjernice za nazivljeNazivlje 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 našeg jezika, Dat-Rođizbjegavati prekratke nazive koji, osim u nečitkost, vode u nedosljednost već pri prvoj pojavi iste kratice za različiti pojam

• npr. SifMje za Mjeru i Mjestoizbjegavati preduge nazive, pr. Redni_broj_stavke_kalkulacije, zbog

• smanjenja čitljivosti• učinkovitosti ručnog kodiranja (pojava sintaksnih pogrešaka izazvanih

pogreškama u pisanju produžuje vrijeme ispravljanja i prevođenja)• mogućih ograničenja 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


Smjernice za nazivlje

Nazivlje programskih varijablikoristiti smislene nazive

• izbjegavati "jednoslovčane" 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 značenjem sadržaja• pr. max za najveću vrijednost• pr. len za varijablu koja određuje duljinu

koristiti standardne prefikse/sufikse za srodne elemente/objekte• pr. frmOsoba ili fOsoba za zaslonsku masku• pr. repOsoba, rOsoba za izvješće …

koristiti kratice općih 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 olakšava snalaženje u programskom kodu i uklanja moguća "neodređenost" sadržaja

• pr. gCount, sCount, lCount, aCount


Smjernice za nazivljeStandardizacija nazivlja

Pridjeljivanje naziva objektima modela podataka odražava se na nazive programskih varijabli. O tome treba voditi brigu već prilikom oblikovanja baze podataka.Poželjno je oblikovanje obaviti takvim alatom za modeliranje koji osim stvarnih naziva ima mogućnost evidentiranja kodova koji će se koristiti prilikom stvaranja BP za stvaranje objekata BP.Uporaba različitih notacija kao što su korištenje velikih i malih slova (BrojCipela), umetanje podvlake između dijelova od kojih je sastavljen pojam (broj_cipela) ili kombiniranje spomenutih notacija može se smatrati razlikom u stilu.

PrimjeriPascalCase - početno slovo svake riječi u imenu je veliko slovo

• npr. BackColor• koristi se kod imenovanja prostora imena, razreda, sučelja, pobrojanih tipova,

postupaka i svojstava, static, public ili protected atributa • identifikator razreda može započeti znakom @

camelCase – početno slovo prve riječi u imenu je malo slovo, početna slova ostalih riječi u imenu su velika slova

• npr. backColor• koristi se kod zaštićenih atributa i lokalnih varijabli postupaka

Preporuke• Imena sučelja uobičajeno započinju slovom I• Koristiti imenice za imena razreda• Koristiti glagole za imena postupaka


Smjernice za komentare

Programski komentaripaziti da komentari budu ažurni, tj. da odgovaraju stvarnom stanju ne pretjerivati u pisanju komentaraloš kôd bolje je iznova napisati, nego (bezuspješno) pojašnjavatikomentirati smisao naredbi (izbjegavati "prepričavanje")

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


'*************************************************************'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 u zaglavlju modula


'#'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


Primjer, komentar programskog slijeda i retkovni komentar

Primjer, blok komentar

hFile = FtpFindFirstFileA(hservice, RemoteFileName, FindData, 0, 0)If hFile = 0 Then

'15.06.2000 by K'enum FTP files to compare Case-InsensitiveDim bFile As Long, FoundFile As StringFindData.cFileName = String(MAX_PATH, 0)hFile = FtpFindFirstFileA(hservice, "*.*", FindData, 0, 0)If hFile = 0 Then Exit Function 'empty directory, 05.03.2001 by K



Na početku izrade treba uspostaviti standarde kodiranja, a odabrani stil zatim dosljedno primjenjivati!

Primjeri: \Izrada\CodeConventionsPrimjer: MSDN "Hungarian notation"



Tehnika i stil programiranjaeksplicitno deklarirati programske varijable izbjegavati programske varijable općeg tipapostaviti početne vrijednosti varijabli prije uporabeugraditi podrazumijevane (default) vrijednosti ulaznih podatakaprovjeravati zahtijevanost i valjanost ulaznih podatakadosljedno formatirati podatkeolakšati ispravljanje neispravnih ulaznih podatakapripaziti na granične vrijednosti podataka, indeksiranih varijabli ...provjeriti moguće numeričke pogreške (10.0 * 0.1 nije uvijek 1.0)izbjegavati usporedbu na jednakost brojeva s pomičnim zarezom



Tehnika i stil programiranjakoristiti zagrade radi naglašavanja redoslijeda izračunavanja izraza presložiti i pojednostavniti nerazumljive izrazeizbjegavati nepotrebna grananjaizbjegavati trikove (ne žrtvovati jasnoću radi "efikasnosti")ponavljajuće blokove i izraze zamijeniti potprogramimarekurziju koristiti samo za rekurzivne strukture podatakaprvo napraviti jasno i ispravno rješenje, a zatim brzo rješenjeneučinkoviti kôd ne usavršavati, nego naći bolji algoritamrutinski posao i jednostavnu optimizaciju prepustiti prevoditeljunakon pronađene i ispravljene pogreške provjeriti ima li ih jošloš kôd bolje je napisati ponovno, nego ga popravljati ("krpati")nedovoljno općenita rješenja bolje je reorganizirati, nego ih prilagođavati radi višekratnog korištenja kodirati s osloncem na programske knjižnice



Programske knjižnicePrije početka kodiranja treba pripremiti programske knjižnice s funkcijama grupiranim po namjeni

• funkcije za rad s općim 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 sučelja (npr. sustav izbornika, poruka i pomoći)• funkcije za održavanje baze podataka (npr. provjera konzistentnosti

podataka i izrada rezervnih kopija)• funkcije za administriranje vanjskih uređaja (npr. terminali i pisači)• programski dio sustava zaštite (npr. definiranje programskih modula,

funkcija i korisnika te rukovanje pravima pristupa programima i podacima)

Grupiranje funkcija sučelja te poruka i tekstova pomoći pomaže kod promjene kodne stranice ili u slučaju potrebe za prijevodom na neki drugi jezik, kada sve tekstove treba odjednom mijenjati.

Provjera ispravnosti


Provjera ispravnostiTestiranje programa, provjeravanje, ispitivanje programa

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

• uspješan test je onaj test koji dokaže postojanje pogreškeNačini provjere

strukturalno (white-box, clear box testing)• provjera kako cjelina radi• probni slučajevi izvode se uvidom u programski kôd (inspekcija koda)• provode programeri

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

Verifikacija - ovjera ispravnostidokazivanje da je faza dobro provedena ili da je proizvod dobro napravljen, tj. da odgovara specifikaciji zahtjeva

Validacija - potvrda valjanostikojom se utvrđuje da je napravljen pravi proizvod, koji odgovara korisniku-namjeni


Vrste testiranja

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

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


Vrste testiranjaIntegracijska provjera (integration testing)

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

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

ispitivanje provodi nezavisni tim za testiranjetestovi su zasnovani na specifikaciji sustava

Provjera sustava (system testing)provjera rada sustava kao cjeline, kojom se osigurava da svi nezavisno razvijeni aplikacijski programi rade ispravno te sukladno specifikacijamaprovjere

• Funkcionalno testiranje – provjera funkcionalnosti prema zahtjevima• Testiranje performanci – provjera nefunkcionalnih zahtjeva

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

• Testiranje dokumentacije – provjera korisničke dokumentacije i primjera


Vrste testiranja

Test prihvatljivosti (acceptance testing)test sustava kojim se dokazuje da proizvod zadovoljava korisničke zahtjeve i potrebe organizacije te uvjete pod kojima ga je naručitelj spreman preuzetiiscrpan i konačan test nad stvarnim podacimaAlfa-testiranje (alpha testing) - verifikacijsko

• probna uporaba koju provode korisnici kod izvođača• simulacija stvarnog okruženja• traženje pogrešaka i propusta

Beta-testiranje (beta testing) – validacijsko• provode korisnici kod sebe, bez nazočnosti izvođača• provjera u stvarnim uvjetima

– performance sustava– vršna opterećenja– provjera upotrebljivosti i lakoće uporabe– metode i procedure– izrada rezervnih kopija i oporavak sustava

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


Plan testiranja

Plan testiranjatestiranje mora biti sustavno, prema unaprijed napravljenom planu koji sadrži

• 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• ponašanje programa (npr. neregularni završetak rada, neispravni podaci,

pogrešan prikaz podataka), po potrebi očekivani rezultatPrimjeri: \Izrada\ObrazacZaTest

Preporuke za provjeru u kojoj sudjeluju poznati korisniciProvjeru obavlja ogledna skupina krajnjih korisnika koja, koristeći napravljena rješenja, nastoji obaviti svoje svakodnevne poslove.Po želji krajnji korisnik dodatno iznosi svoja zapažanja ili prijedloge.Primjedbe se prikupljaju dnevno a pogreške uklanjaju po mogućnosti istog dana.Prikupljeni dodatni zahtjevi se procjenjuju te se izrađuje lista prioriteta ugradnje. Nerealni i preveliki zahtjevi se odbacuju ili se planira njihova naknadna ugradnja.


Primjer obrasca za test



Raspodjela broja otkrivenih pogrešaka


Izrada dokumentacije


Dokumentiranje

Projektna dokumentacijadokumentira razvoj i proizvode pojedinih faza

Primjer, dokumentacija po IEEE standardu 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


DokumentiranjeKorisnička dokumentacija

pomoć korisnicima pri uporabi sustavamora biti prilagođena korisnicima različitog iskustva

upute za uporabu (user manual)instalacijski priručnik (installations manual)detaljni priručnik (reference manual)upute za vježbu (training guide, tutorial)podsjetnici ili kratke upute (quick reference guide, pocket guide, cue cards)

broj, vrsta i obujam dokumenata ovise o aplikaciji


DokumentiranjeTehnička dokumentacija

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

upravljanje projektom i konfiguracijom sustava• plan razvoja• specifikacija dizajna• opis arhitekture sustava • specifikacija sučelja prema drugim sustavima

programska dokumentacija• izvorni kôd• opis baze podataka• probni podaci i rezultati provjere• dnevnik promjena• programski priručnici

instalacijski priručnik• opis instalacijske procedure

upute za rukovanje i održavanje (operations manual)• opis procedura za pokretanje/zaustavljanje (startup/shutdown)• opis izrade rezervnih kopija i vraćanja podataka (backup, restore) • opis postupka ponovnog pokretanja i oporavka (restart, recovery)


Preporuke za izradu dokumentacije

Izrada dokumentacijeizrada kvalitetne dokumentacije zahtijeva angažman i do nekoliko sati (3) po stranici mora biti planirana i započeti dovoljno rano, prije završetka kodiranja i testiranjaprije objavljivanja treba provjeriti/dokazati da odgovara namjeniprilikom izrade treba pripaziti na

• izbjegavati ponavljanje i neodređenost• Koristiti standardizirane dokumente

Između ostalog, dobra dokumentacija mora:biti napisana s gledišta čitatelja, a ne pisca

• konzistentnost pojmova, jednostavnost izraza, kratka poglavljabiti dobro ilustririrana (slikama zaslona i njihovog redoslijeda)opisivati postupak rada, a ne samo sadržaj zaslona

• npr. redoslijed popunjavanja šifrarnika, određivanje lozinki i prava pristupa, radne procedure

bilježiti načela (argumente odluka)odražavati stvarno stanje opreme u primjeni, tj. biti ažurnauključivati rječnik korištenih izraza


Preporuke za izradu dokumentacije

Nepostojanje dokumentacije može biti razlogom za prestanak korištenja aplikacija, naročito kada autor ili autori prestanu biti raspoloživima.

Preporuča se odvojeno pohranjivati odgovarajuću inačicu programske opreme (alata) kojom je proizvod napravljen.

Primjeri: \Dokumentacija

Internet adresehttp://www.rspa.com/docs/index.htmlhttp://www.construx.com/doc.htm

Primjena i održavanje


Uvođenje u primjenu

Uvođenje uključuje instaliranje opreme, završni prijenos podataka te prelazak na novi način rada. Aktivnosti i preduvjeti

• Test sustava– vidi Izrada\Testiranje

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

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

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

• Konverzija sustava– prelazak na novi način rada– evaluacija projekta i sustava



Način uvođenjaIzravno uvođenje (direct installation, abrupt cutover)

• početak rada novog sustava uz istovremeni prestanak rada starog sustava

• provodi se na određeni dan, uobičajeno datum završetka poslovnog razdoblja, po mogućnosti na kraju tjedna

• mogući problemi: pojava pogrešaka koje nisu bile uočene tijekom testiranja, nepredviđeno preopterećenje opreme u punom pogonu

• nedostatak: neposredna izloženost korisnika pogreškama sustava

Paralelno uvođenje (parallel installation, parallel conversion)• istovremeni rad starog i novog sustava tako dugo dok se ne pokaže da

novi sustav ispravno radi i da su se korisnici navikli na novi način rada• bitno manje rizičan postupak u odnosu na izravno uvođenje• nedostatak: potreba za dvostrukom obradom istih podataka, u starom i u

novom novom sustavu → otpor korisnika



Korisnici mogu biti raspršeni na različitim lokacijamaProbno uvođenje (pilot installation, location conversion)

• izravno/paralelno uvođenje sustava na jednoj lokaciji, a zatim i na ostalim lokacijama, nakon što se utvrdi da sustav ispravno radi

Postupno uvođenje (phased)• uvođenje grupa lokacija

Istovremeno (simultaneous conversion)• istovremeno uvođenje na svim lokacijama

Modularno uvođenje (modular installation, staged conversion)postupna zamjena starog sustava novim, uvođenjem po dijelovimaizvedivo samo ako je moguć istovremeni rad oba (nekompletna) sustavamogući problemi: potreba za spojnim programima, tj premošćivanjem



Karakteristike različitih načina uvođenja u primjenu

Uvođenje Rizik Trošak Trajanje Izravno visok niski (ako uspije) kratko (ako uspije) Paralelno nizak visoki dugo Ostalo srednji srednji varijabilno


Poduka

Poduka korisnikatehničko osobljekranji korisnici

Sadržaj podukePoduka krajnjih korisnika može uključivati:

• opću informatičku kulturu (npr. uporaba osobnih računala)• funkcije sustava i način uporabe sustava, to jest korištenje aplikacija• poduku iz posebnih znanja potrebnih za obavljanje osnovne djelatnosti

(npr. operacijska istraživanja, projektiranje primjenom računala)

Poduka tehničkog osoblja može uključivati:• operacijski sustav i uslužne programe• administriranje baze podataka• programske jezike i pomagala


Poduka

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

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

Poduku mogu obaviti djelatnici naručitelja (npr. odjel informatike ili grupa za to odabranih i osposobljenih djelatnika) ili vanjski izvođači poduke.

Održavanje


Održavanje i nadgradnja

Održavanje je trajna aktivnost koja započinje odmah po uvođenju u primjenu.

Bez obzira kako dobro je sustav dizajniran, konstruiran i testiran pogreške će se neizbježno pojaviti!

Ispravljanje pogrešaka u primjeni naziva se održavanjem sustava ili održavanjem programa.Održavanje samo po sebi ne podrazumijeva ugradnju poboljšanja ili novih mogućnosti, ali se ona uobičajeno provodi.

Tijekom primjene i održavanja obavlja se analiza dodatnih zahtjeva, planiranje i priprema aktivnosti koje slijede te tako započinje novi ciklus razvoja.

Primjeri: \Primjena


Održavanje sustava, servisiranje sustava

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

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

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

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


Uklanjanje pogrešaka i izmjene programa

Definicija i validacija problemauočavanje uzroka pogrešaka u primjeni (bugova)

• problem reprodukcije pogreškeproblem različitog tumačenja pogreške

• nerazumijevanje ili pogrešno korištenje programa• nepostojanje funkcije čija ugradnja nije bila planirana nije bug!

Ocjenjivanje sposobnosti (benchmarking)Održavanje može imati neželjene popratne učinke koji utječu 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.

Editiranje i testiranjepoznavanje programa upravljanje verzijama (version control)

• različite inačice u primjeni kod različitih korisnika• mogućnost povratka na prethodnu inačicu ako je ta bila bolja

regresijsko testiranje – ponavljanje svih testova da bi se provjerilo da izmjene nisu uzrokovale nove defekte

Ažuriranje dokumentacije468FER-ZPM-GRZ, Fertalj & Kalpić: Projektiranje informacijskih sustava, akad.god. 2006/07.

Poboljšanje sustava i reinženjerstvo

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

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

• prilagodba većim promjenama tehnologije• ispravak sustava prije nego što dođe do mogućeg prekida u radu• ispravak sustava koji će biti lakše popraviti ako dođe do prekida


Poboljšanje sustava i reinženjerstvo

Pisanje jednostavnih novih programajednostavni program – koji samo koristi postojeće podatke

• primjeri: pretraživanje i pregledavanje podataka, generiranje izvješćanajčešće i najsigurnije promjene

Restukturiranje datoteka i baza podataka promjena strukture u istoj bazi podatakaprelazak na novu tehnologiju upravljanja podacima – veliki rizik

Reinženjerstvo programareorganizacija koda – restrukturiranje organizacije modula ili programske logikekonverzija koda – prelazak na novi programski jezikrezanje koda, odsijecanje koda (slicing) – izdvajanje dijelova programa radi izrade odvojenog programa ili potprograma

Poboljšanja i reinženjerstvo moraju biti planski provedenimetrika programske podrške (software metrics) – mjerenje programaproračun troškova


1.01.2

1.1

1.2

1.3

1.2

1.01.1

1.0

1.0

Utilities.java

MainFrame.java

LICENCE.TXT

README.TXT

Configuration CFG1

1.2

1.1

1.1

1.0

1.1

1.01.11.2

requirementsspecification

class diagramsource code

userdocumentation

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 određenoj točki životnog ciklusa


Verzije konfiguracije

verzija, inačica (version) – određeno izdanje (issue, release) proizvoda objava, isporuka (release) – originalna verzija u primjeni, npr. zadnja v2.0revizija (revision) – ona koja se koristi umjesto originalne, podrazumijeva izmjene u određenim vremenskim intervalima, npr. V1.2varijanta (variant) – alternativa originalu (hardverska platforma, različiti jezik), živi paralelno s njim, npr. v1.1.2.1

V 1.1.4.1

V 1.1

V 1.1.2.2

V 1.2

V 1.1.2.1

V 2.0

V 1.1.4.2

V 1.0


Upravljanje verzijama (version control)


Upravljanje verzijama (version control)

Modaliteti izgradnje

Najčešće međufaza između Analize i Oblikovanja


Vlastiti razvoj

Vlastiti razvoj (Insourcing)Varijante

• Razvoj vlastitim informatičkim snagama (in-house), koji može sadržavati osposobljavanje i angažiranje netehničkog osoblja

• Razvoj unajmljenim osobljem povremeno ili dugoročno (buy-in, preferredsupplier), npr. PBZ

Prednosti• fleksibilnost i kreativnost• povećanje stručnosti vlastitog osoblja

Nedostaci • zahtijeva značajno vrijeme i napor skuplje, dugotrajnije• može povećati gomilanje zaostalog posla

razvoj vlastitim snagama ima smislakada se radi o programskoj podršci koja je posebnost organizacije, takva da ne postoje gotova rješenja na tržištu ili takva da organizacija s pomoću nje postiže komparativnu prednost u odnosu na konkurencijukada postoje dodatni ili posebni razlozi kao što su povećana tajnost podataka i poslovnih procesa ili povećana zaštita IS


Vanjski razvojVanjski razvoj (Outsourcing)

najam usluge razvoja informacijskog sustava ili njegovih dijelova• izobrazba djelatnika informatičke 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 složenih poslovnih funkcija

Varijante:• Ugovoreni razvoj - ugovara se isporuka gotovog proizvoda (contract out)• Dugoročna suradnja s isporučiteljem ili izdvajanje vlastitog informatičkog odjela u

preferiranog izvođača (preferred contractor) – strateškog partnera (pr. Agencija)Prednosti

• IS ili njegovi dijelovi izrađuju se po mjeri naručitelja– sustav je prilagođen organizaciji/poslovanju– po mogućnosti treba istovremeno poboljšati organizaciju/poslovanje

• razvoj podrazumijeva dugotrajan postupak i sukladno visoku cijenuNedostaci i rizici

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

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


Nabava gotovih aplikacija

Nabava gotovih programskih proizvodaCOTS = Commercial-Of-The-Shelf software

• u pravilu ne ispunjavanju poslovne potrebe u potpunosti• poželjno je da se mogu prilagoditi potrebama

Aplikacijski paketiprogramski paketi za uredsko poslovanje (office automation),

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

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

Sustavi za upravljanje poslovanjem Enterprise Resource Planning (ERP) systems

• npr. SAP, BAAN, J.D. Edvards, Peoplesoftcjeloviti sustavi za potporu poslovanju

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


Nabava poslovnih sustavaNabavka i prilagodba postojećih domaćih poslovnih sustava/aplikacija

prednosti:• usklađenost našim uvjetima, npr. zakonima• zahtijeva prvenstveno prilagodbu organizaciji/poslovanju

nedostatci• nepostojanje ili manjkavost pojedinih komponenti, mjestimična tehnološka zastarjelost• prekapacitiranost dobavljača

modaliteti:• otkup izvornog koda i samostalna dorada• kompletni outsourcing uz samostalno održavanje

Nabavka “gotovih” stranih poslovnih sustavaprednosti

• raskošna funkcionalnost• kompatibilnost sa svjetskim poslovnim standardima

nedostatci• neprilagođenost domaćim uvjetima i konkretnoj organizaciji/poslovanju - zahtijeva

istovremenu prilagodbu programske opreme i promjenu organizacije/poslovanja• prilagodba se obavlja slično razvoju - rješenja gube moguću komparativnu prednost (brzinu i

lakoću primjene)• (glomazni) paketi mogu zahtijevati angažman velikog broja konzultanata - vrlo visoka cijena

izrademodaliteti

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


Kriteriji za donošenje odluke o nabavi

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

Dodatni kriterijiOtvorenost sustava (Portabilnost, interoperabilnost)Tehničke mogućnosti (Client-Server, OLTP, OLAP, ...)…tehničke konzultacije,održavanje (dinamika razvoja i mogućnosti nabavke novih verzija),promptno otklanjanje problema,ponuda gotovih aplikacija,pomoć u razvoju vlastitih aplikacija


Narudžba izvedbenog programskog koda

Prednosti narudžbe izvedbenog kodaIzvedbeni kôd je jeftiniji.Brigu i odgovornost o njegovom održavanju preuzima isporučitelj, uz izuzetak nekih opće primjenjivih komercijalnih programa. Ne mora se kupiti (skupi) razvojni programski alat u kojem je programska oprema pisana.

Mane izvedbenog koda s obzirom na korisnika su sljedećeIzvedbeni kôd podrazumijeva potpunu zavisnost od isporučitelja.Ne postoji mogućnost prilagodbe specifičnim vlastitim potrebama, osim putem posebnog dogovora s isporučiteljem. Dodatna prilagodba lako može postati predmetom ucjene.Ne postoji mogućnost razvoja programske opreme vlastitim snagama.


Narudžba izvornog programskog koda

Prednosti nabavke izvornog kodaIzvorni kôd omogućuje stalni razvoj i praćenje vlastitih posebnosti, što se može pokazati kao prednost u odnosu na konkurenciju.Mogućnost prilagodbe vlastitim potrebama omogućuje elastičnost pri promjenama organizacije poslovanja.Nema bojazni da će nakon prve potrebne izmjene prestati uporaba PO zbog toga što isporučitelj nije trenutno dostupan, postavlja nerazumne uvjete ili je u međuvremenu nestao sa tržišta.Uvidom u kvalitetna gotova rješenja pomaže se razvoju vlastitih informatičkih djelatnika.

Mane narudžbe izvornog kodaIzvorni kôd je višestruko skuplji od izvedbenog.Potrebna je razvojna inačica programskog alata u kojem je PO napisana.Naručitelj se izlaže kušnji da nekompetentno mijenja nabavljeni izvorni kôd, onesposobi aplikaciju za rad, a izgubi pravo na održavanje.Poskupljuje se održavanje ukoliko se radi o programskoj opremi podložnoj promjenama.

Sniženje cijene izvornog koda može se postići automatizacijom kodiranja, uporabom generatora izvornog koda.


Preporuke korisnicima

Izvedbeni kôd treba preporučiti ondakad se radi o standardnim, masovno prodavanim aplikacijamakad korisnik nema vlastite informatičke stručnjakekad se radi o visokostručnim aplikacijama koje se neće mnogo mijenjati, a korisnik se nema namjeru baviti detaljima te strukekad korisnik nema novaca ili želje za vlastiti informatički razvoj

Izvorni kôd treba preporučiti ondakad programska oprema predstavlja stratešku investicijukad korisnik raspolaže kompetentnim informatičarima ili ima motiva razvijati vlastitu informatičku djelatnostkad isporučitelj ne može preuzeti obvezu održavanja ili ne može jamčiti da će ostati na tržištukad na tržištu ne postoji PO koja odgovara potrebama, ne može se povoljno kupiti slična, a korisnik raspolaže vlastitim informatičkim snagama dovoljnim za pisanje nove


Odabir rješenja

Određivanje mogućih rješenjaIdentifikacija rješenja na temelju poslovnih zahtjeva postavljenih tijekom analizeUlazi: specifikacija računalne opreme i programske podrške te odabrana tehnološka arhitekturaIzlazi: moguća rješenja novog sustava i njihove karakteristike

Analiza izvodljivosti alternativnih rješenjaProcjena alternativa s obzirom na tehničku, operativnu, ekonomsku i vremensku izvodljivostUlazi: karakteristike mogućih rješenja, karakteristike i cijene hardvera i softvera, reference i uvjeti dobavljačaIzlazi: analiza izvodljivosti za svako moguće rješenje

Prijedlog rješenja sustava koje će se oblikovati i ugraditiOdabir onog rješenja koje ima najbolju ukupnu kombinaciju izvodljivostiUlazi: napravljena analiza izvodljivosti, plan projekta, procjena veličine projektaIzlazi: prijedlog sustava s usvojenim promjenama dizajna predloženog sustava


Primjer: moguća rješenja i njihove karakteristike

-8000 kn8000 knCijena preporučenog računala (plus monitor, pisač i modem)

Cijena operacijskog sustava i licenci

3500 kn2200 kn4000 kn3500 knCijena min. potrebnog računala (plus monitor i pisač)

2000 kn500 kn100 kn1500 knCijena paketa

10/944/937/969/95Datum prve instalacije

871521027Broj instaliranih paketa

Preporučeno računalo

…………Min. potrebno računalo

vrlo malanevelikavelikaUpotreba konfiguracije za druge poslove

dadanedaArhiviranje podataka

1-2 dana / 1 tjedan1dan / 2 tjedna1 dan / 1 mjesec1-2 dana / 2 tjednaKrivulja učenja

nenenedaRad u mreži

nenedada Rad s različitim pisačima

velikavelikasrednjasrednjaBrzina ispisa računa

nenesrednjadobraIntegracija s drugim aplikacijama

velikemalevrlo malevelikeMogućnosti aplikacije

dobranenedobraDokumentacija (papirnata)

nenenedaIntegrirani sustav pomoći (on-line help)

tekstovnotekstovnografičkografičkoKorisničko sučelje

nedaneneRaspoloživ izvorni kod

ClarionCliperC++Visual BasicProgramski jezik

srednjamalavelikavelikaBrzina pretraživanja i dohvata podatka

MySQLdBase IIIParadox 8Access 2Baza podataka

LinuxDosWindowsWindowsOperacijski sustav

ZZ VideoVideoVideo BossSuperVideoKarakteristike


Ocjenjivanje kriterija

Na temelju opisa karakteristika ne može sa sigurnošću procijenitikoji je sustav najbolji.

Koristi se sustav bodovanja da bi se usporedio značaj različitih kriterija. Weighted Scoring Model

Odredi se težinski faktor za svaki kriterij (npr. 0-3).Pojedinačnom kriteriju svakog od rješenja dodjeljuje se ocjena iz dogovorenog raspona (npr. 0-5), pomnožena s odgovarajućom težinom.Dobiveni pojedinačni rezultati sumiraju se za svako od rješenja.

Što učiniti kada su sustavi (pod)jednako bodovani ?Što učiniti ako pojedino svojstvo ima više podsvojstava ?

∑=

=n

jjiji wsS

1

gdje su

Si = ukupna vrijednost i-tog rješenja

sij = vrijednost j-tog kriterija za i-to rješenje

wj = važnost ili težina j-tog kriterija


Primjer: analiza izvodljivosti za moguća rješenja

12497124171Ukupno bodova:

9315562933Cijena računala i sistemskog softvera

4284105422Cijena paketa

555533331Datum prve instalacije

555522331Broj instaliranih paketa

93001551553Upotreba konfiguracije za druge poslove

105105001052Arhiviranje podataka

335555331Vrijeme obuke korisnika

000000551Rad u mreži

00001551553Rad s različitim pisačima

205205123824Brzina ispisa računa

0000931243Integracija s drugim aplikacijama

20582412054Mogućnosti aplikacije

840000842Dokumentacija (papirnata)

0000001052Integrirani sustav pomoći (on-line help)

63631051052Korisničko sučelje

005500001Raspoloživ izvorni kod

222255441Programski jezik

164411642054Brzina pretraživanja i dohvata podatka

112244441Baza podataka

632184842Operacijski sustav

bodoviOcjenaBodoviOcjenaBodoviOcjenaBodoviOcjenaKarakteristike:

ZZ VideoVideoVideo BossSuperVideoTežinskifaktor


Izbor dobavljača

Definiranje kriterija i opcijaUlazi: specifikacije zahtjeva na programsku podršku i računalnu opremu

• funkcionalnost, dodatna svojstva, ključni parametri performanciIzlazi: lista potencijalnih dobavljača, proizvoda ili usluga te kriteriji za odabir

Prikupljanje ponuda, natječajzahtjev za reference (request for quotations - RFQ)

• kada je određen proizvod koji se može nabaviti od različitih dobavljača -prikupljaju se informacije o konfiguracijama, cijenama, održavanju

zahtjev za ponude (request for proposals - RFP)• kada postoje različiti dobavljači i/ili proizvodi, a želi se odabrati najbolje

rješenje - prikupljaju se ponude koje su skup "referenci"Odabir ponuda

provjera sadržaja ponudaizrada rang liste, poželjno odvojenim ocjenjivanjem pojedinačnih ponudaodabir objektivno najboljeg ponuđača

• To se nažalost vrlo teško uklapa u zakonske odredbe po kojima treba točno specificirati što se želi a mora se kupiti najjeftinije.


Ugovaranje i realizacija posla

Ugovaranje poslasklapanje ugovora koji definira uvjete suradnje, isporuke i naplate, integracije s postojećim sustavom, održavanja i slično

Ugovori se mogu raskinuti ili ne ispuniti kako je bilo zamišljenoIzvoditelj projekta treba biti stimuliran proporcionalno ostvarenoj, u praksi dokazanoj i od korisnika prihvaćenoj funkcionalnosti.

Neke cijene usluga u Hrvatskoj (okvirno, razni izvođači)programiranje: 200, 260, 380 HRK/h, prog. dugotrajno: 3000 HRK/dan, 12000 HRK/tjedan, 40000 HRK/mj.tečaj: 400, 750, … 1200 HRK/h, 7500 HRK/danpoduka korisnika: 400 HRK/hsavjet: 220, 300, 450, 600, … HRK/h, 7500 HRK/dan

Neke cijene softvera u Hrvatskoj…

Modeli razvoja i metodologije


Vodopadni (waterfall) model

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

Nedostaci• problem u slučaju pogrešaka ili novih/promijenjenih zahtjeva• uvođenje prema gore (bottom up): moduli, podsustavi, sustav• sustav nije upotrebljiv dok nije gotov u potpunosti• problem predodžbe o produktu na temelju pisane specifikacije



Analiza

Oblikovanje

Izrada

Evaluacija

Primjena

Analiza

Oblikovanje

Izrada

Evaluacija

Primjena



Pseudostrukturni vodopadni modelpovratna veza i mogućnost promjene rezultata prethodnih fazauvođenje prema dolje: moduli na višim, pa na nižim razinamaprimjena tehnika strukturiranog programiranja

Strukturni (radikalni)aktivnosti različitih faza mogu se obavljati istovremenokorištenje rječnika podataka, 4GL i generatora aplikacijaprikladan kada se unaprijed ne zna konačni izgled sustavamora nastati (papirnati) model sustava


“V” model

Validacija

Verifikacija

definiraju se rezultati (“proizvodi”) pojedinih faza koji se prosljeđuju u slijedeće fazeodređuju se rezultati kojima se testiraju elementi IS na različitim stupnjevima razvoja

AnalizaTest

prihvatljivosti

Specifikacijazahtjeva

Testirani sustav

Strukturno oblikovanje

Integracija sustava

Modelsustava

Testirani softver

Detaljno oblikovanje

Integracijamodula

Dizajnmodula

Testiranimoduli

Kodiranje i testiranje

Ogledni slučajevi

Ogledni slučajevi

Scenariji aplikacije


Prototipski model razvoja

Prototip koji se radi da bi se isprobale neke mogućnostiModel oponašanja (mock-up, model u naravnoj veličini)

• jednoekranski ili višeekranski model kojim se prikazuje kako će izgledati dio sustava (npr. sučelje)

Istraživački model (research model) • istraživanje dijelova sustava kako bi se provjerile neke ključne postavke

(npr. provjera performanci određenog modula)Ugradbeni model (implementation model)

• traženje različitih načina na koje se sustav može izraditi (npr. koji sustav za upravljanje BP, programski jezik, računala…)

Prototip koji postupno, inkrementanlnom doradom -“bistrenjem”(stepwise refinement) postaje dio završnog IS

podrazumijeva iterativni pristup, obično korištenjem 4GLradni model (working model) daje se na uvid korisnikuomogućuje korisniku stvaranje slike o izgledu sustavakorisnik daje primjedbe za popravak i poboljšanjastječe se bolja slika o zahtjevima korisnikauklanjaju se moguća iznenađenja na kraju razvoja


Brzo prototipiranje (rapid prototyping)funkcionalni prototip - zamjenom pravim rješenjima postaje radni sustavprikladno za male projekte (tzv. one-man project)Prednosti:

• iteracije promjena – korisnici se smiju predomisliti

• povećanje kreativnosti i brzine razvoja

Nedostaci:• “zaboravljanje” da prototip nije

pravi sustav • mogući neuspjeh zamjene

prototipa radnim sustavom• dokumentacija proizlazi iz

izrade, uz opasnost da pisane specifikacije nikad neće biti napravljene

• nemogućnost ispravne procjene i planiranja resursa

Radni sustav

Razvojprototipa

Dizajn prototipa

Određivanje zahtjeva

Izrada prototipa


Ograničeno/strukturirano (constrained prototyping)

izrada prototipa kao sredstvo određivanja zahtjevanefunkcionalni prototip (prikaz izgleda)u određenom trenutku se prekida i slijedi faza oblikovanja sustava


Evolucijski model

Primjena IS mijenja pogled korisnika, a njegove potrebe se mijenjaju (rastu) tijekom primjene. Informacijski sustav raste s organizacijom koju podržava.Udruživanje brzog i ograničenog prototipiranja

izrada u inkrementalnim koracima, dovoljno malim da se mogu obaviti prototipskislijedovi razvojnih aktivnosti - svaki od slijedova vodi operabilnom proizvodu koji se isporučuje i generira daljnje zahtjeve

OblikovanjeAnaliza EvaluacijaIzrada





Spiralni model

Na početku svake faze provodi se procjena rizika (risk analysis)nastoji se utvditi moguće rizike i razriješiti ih prije nastavka (uklanjanjem ili svođenjem na najmanju moguću mjeru)

U slučaju da je rizik prevelik, projekt se prekida.

Analiza rizika---------------------------

OBLIKOVANJE---------------------------

Verifikacija

Analiza rizika---------------------------

ANALIZA---------------------------

Verifikacija

Analiza rizika---------------------------

INTEGRACIJA---------------------------

Testiranje

Analiza rizika---------------------------

IZRADA---------------------------

Testiranje

PRIMJENA


1

1

1

1

2

2

2

2

3

3

3

4

4

4

4

kumulativni trošak

integracija

izrada

oblikovanje

analiza

Spiralni model

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

1. Analiza rizika, procjena alternativa2. Razvoj i verifikacija sljedećeg "produkta"3. Planiranje sljedeće faze4. Pregled - Određivanje ciljeva, alternativa i ograničenja


Spiralni model


Spiralni model

Primjeri rizika:rizik da isporučeni produkt neće odgovarati stvarnim zahtjevima

• izrada prototipa kao dio faze određivanja zahtjevarizik da će cijena izrade premašiti korist ostvarenu uporabom

• provođenje analize troškova-koristi (cost-benefit) prije provođenja svake pojedine faze

Primjena:interni projekti (naručitelj i izvođač iz iste organizacije) izgradnja velikih sustava (troškovi izrade malih sustava su mali)kada provođenje analize rizika ne predstavlja preveliki relativni trošak (npr. za projekte iznad 25 kUSD)

Analiza rizika može se provesti i za vanjske (ugovorene) projektenaručitelj je može provesti prije početka projekta da bi se osigurao od neuspjeha, primjerice prije potpisa ugovoraizvođači je mogu provesti tijekom izrade (primjerice radi procjene moguće uporabe novog alata)


Metodologije

Metodologija (methodology) = metoda + idejni pristupKolekcija procedura, tehnika, alata i dokumentacijskih pomagala,potkrijepljenih filozofijom, koji potpomažu izgradnju informacijskog sustava[Avison & Fitzgerald, 1995]Skup načela izrade IS, koji se u određenoj situaciji svodi na metodu jedinstveno prikladnu toj situaciji [Checkland]razrađen "plan bitke" ili "kuharica" za postizanje željenog rezultata

Komponente metodologije• A methodology will consist of phases, themselves consisting of sub-

phases, 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 projektazadaci za svaki pojedini stadijizlazi (projektna dokumentacija)preporuke (vodič) uporabe odabranih tehnika i pomagalanačin upravljanja projektom i nadzora projekta


Uloga metodologija

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


Uloga metodologija

Jeftinije je otkriti i popraviti pogrešku u ranim fazama, jer:lakše je popraviti dokumentaciju nego mijenjati programski kôdizmjene u kasnijim fazama zahtijevaju promjene rezultata prethodnih fazalakše je pronaći pogrešku tijekom faze u kojoj je nastala, nego tražiti je i popravljati na temelju posljedičnih učinaka primijećenih u kasnijim fazama

Relativno trajanje i cijena otkrivanja pogrešaka u različitim fazama

Cijena

Plan, Analiza, Oblikovanje, Izrada, Održavanje

M a in t en a nc e 6 7 %

In te gra t io n6 %

D e sign6 %

M o du leco d ing5%

M od u lete st in g7 %

P rob le m D e f3 %

R e qu ire m e n t s4 %

P la n n in g2 %


Pristup razvoju

Tijekom projektiranja IS izrađuju se uglavnom sve vrste modela, ali se razlikuje pristup razvoju pojedinih metoda (metodologija).Usmjerenost procesima (npr. SA/SD)

za korisnika jednostavniji pristupomogućuje opisivanje specifičnih funkcijaproblem određivanja razine dekompozicije (razine osnovnih procesa)nedovoljna pažnja modelu podataka, koja za posljedicu može imati neodgovarajući model baze podataka i otežanu integraciju aplikacija uslijed nekompatibilnih podataka

Usmjerenost podacima (npr. IEM)složeniji opis strukture podatakajednostavniji tokovi podatakaprocesi se definiraju analizom podataka (grupiraju oko podataka)brže konvergira kraju, jer je skup objekata (entiteta) modela konačan

Početak razvoja definiranjem događaja (npr. JSD)primjereniji sustavima za rad u stvarnom vremenu


Komercijalne metodologije

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

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


Komercijalne metodologije

Kuhanje po kuharici (receptu) ne znači da će jelo biti dobro!• Zahtjevi se mogu mijenjati u vremenu. • Preporučene aktivnosti ne moraju uvijek biti prikladne, primjenjive ili potrebne.

Inzistiranje na provođenju propisanih procedura vodi u zanemarivanje stvarnih problema, što za posljedicu može imati formalno dobro napravljen, a neuspješan sustav.

Većina metodologija namijenjena je analizi i oblikovanju. Rijetke podupiru sve faze životnog ciklusa (npr. IEM).

Metodologije bi trebale biti podržane odgovarajućim alatima za upravljanje i projektiranje (CASE), što nije uvijek ispunjeno u praksi.

Alternative komercijalnim metodologijamazdrav razumnajbolje dokazano u praksi - "Best practices"prečice do rješenja problema temeljene na temelju sličnih 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)učinkovita izrada programske opreme u relativno kratkom vremenusustavna i vremenski sažeta primjena sljedećih tehnika i pomagala:

• aktivno i učinkovito uključenje korisnika• odgovarajuće upravljanje projektom • ispravna uporaba metoda i tehnika razvoja• uporaba CASE pomagala i modernih programskih jezika (4GL)• upravljano prototipiranje

RAD se obavlja malim ekipama za 60-120 dana (približno 4*5=20 tjedana), nad podsustavima veličine 25-30 tablicaCijena postignutog ubrzanja može biti gubitak pregleda nad cjelinom sustava.Treba pripaziti da brzina ne postane sebi svrhom, jer tada vodi u improvizaciju (izradu priručnih rješenja) i “prljavi” razvoj.


Brzi razvoj programske opreme

Faze brzog razvojaJEM (Joint Enterprise Modeling )

• sjednice na kojima poslovodstvo i analitičari traže načine usmjerenja organizacije i načine kako je učiniti kompetitivnom

• stražuju se ciljevi organizacije, problemi, kritični čimbenici uspjeha te strategijske mogućnosti

JRP (Joint Requirements Planning)• analiza zahtjeva s obzirom na poslovni sustav• proučavaju se funkcije sustava, identificiraju upotrebljive i uklanjaju

nekorisne funkcije te istražuju i definiraju informacijske potrebeJAD (Joint Application Design)

• nastoji se oblikovati sustav tako potpuno odgovara zahtjevima• zahtijeva tijesnu suradnju korisnika, izvoditelja i menadžera

konstrukcija (construction)• iterativno prototipiranje

završetak projekta (cutover)• provjera rada, izrada dokumentacije, poduka korisnika


Primjer RAD projekta

Tjedni 1-4Pokretanje projektaIstraživanjePriprema JRP sjedniceObavljanje JRP sjednicePriprema JAD sjednice

Tjedni 5-9Prva JAD sjednicaPočetak dizajnaKonsolidacija JAD dizajna i prototipaPrototipovi za test uporabljivostiDruga JAD sjednicaZavršetak dizajna

Tjedni 10-14Razvoj i testiranjePriprema konverzijePlaniranje završetka

Tjedni 15-20Izrada dokumentacije, priprema podukePodukaZavršno testiranjeZavršetak projekta


Informacijsko inženjerstvo

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.

Značajke IEPodatkovno usmjerena ali procesno osjetljiva tehnika koja se primjenjuje na organizaciju kao cjelinu ili na neki njezin značajni dio, za razliku od klasične strukturne analize koja se odvija projekt-po-projektOsnovno načelo jest da se IS moraju graditi kao što se grade drugi “unikatni”proizvodi, npr. u graditeljstvu ili brodogradnji.


Informacijsko inženjerstvoFaze IE

Planiranje strategije IS - Information Strategy Planning (ISP)• promatranje poslovanja kao cjeline s ciljem definiranja općeg, sveobuhvatnog

plana i arhitekture za slijedni razvoj informacijskih (pod)sustava• izdvajanje poslovnih područja i pridjeljivanje prioriteta

– poslovno područje – skup poslovnih procesa koji se protežu organizacijom (cross-organizational business processes) a moraju biti visoko integrirani da bi se ostvarila strategija ili misija

Analiza poslovnih područja - Business Area Analysis (BAA)• proučavanje poslovnih područja i definiranje poslovnih zahtjeva za visoko

organizirani i integrirani skup informacijskih (pod)sustava i aplikacija potpore poslovnog područja

Definiranje aplikacija• izdvajanje aplikacija i definiranje njihovih prioriteta na temelju analize poslovnih

područja• aplikacije postaju projekti u kojima se primjenjuju drugi postupci analize i dizajna

Podatkovno usmjerena paradigmaBudući da je informacija proizvod podataka, podaci moraju biti planirani prvi!

• Modeliranje započinje modelima podataka• Zatim se rade modeli procesa slično onima u strukturiranoj analizi


Ekstremno programiranje (eXtreme Programming)

Načela [Kent Beck, 1996]Komunikacija (communication).

XP zahtijeva komunikaciju u svim fazama projekta, među svim njegovim sudionicima. Ovdje se prvenstveno misli na komunikaciju među članovima razvojnog tima, zatim na međusobnu komunikaciju članova tima s voditeljima projekta, te komunikaciju naručitelja s izvođačima (članovima razvojnog tima, te njihovim voditeljima).

Jednostavnost (simplicity). Dijelovi softvera, kao i njegova cjelokupna arhitektura moraju u svakoj fazi projekta biti jednostavni. Jednostavnost se ostvaruje kontinuiranim refactoring-om i svođenjem projektne dokumentacije na minimalnu prihvatljivu razinu.

Povratne informacije (feedback). XP nalaže kontinurane povratne informacija od svih sudionika projekta, što značajno podiže kvalitetu rada i ispunjenje rokova. Dobre povratne informacije onemogućavaju nerazumijevanje među sudionicima projekta, te drže projekt na "pravom putu".

Hrabrost (courage). U XP hrabrost podrazumijeva sposobnost provođenja teških 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. Također, hrabrost podrazumijeva međusobnu iskrenost svih članova projektnog tima.


XP tehnike"Svakodnevne prakse"

Igra planiranja (The Planning Game). XP uvažava mogućnost promjene specifikacija koje definiraju funkcionalnost sustava.

• prihvati promjenu! (embrace change!) – jedan od osnovnih XP postulata Igra planiranja definira funkcionalnosti sljedeće verzije, prije nego što njen razvoj stvarno i počne. U početku se kreira grubi plan koji se redefinira kroz razgovore s naručiteljima i korisnicima. Korisnici se izražavaju "pričama", tako da svaka priča definira jedan dio funkcionalnosti sustava. Pričama se dodjeljuju prioriteti i ciljano vrijeme implementacije. (1-3 tjedna po zahtjevu)

Mala izdanja/verzije (Small Releases). XP preporučuje relativno često izdavanje novih verzija sustava – obično u prvom trenutku u kojem to ima poslovnog smisla, tj. kada sustav zadovoljava funkcionalnost traženu od strane naručitelja.Često izdavanje novih verzija pojačava komunikaciju a time dotok povratnih i igru planiranja.

Metafora sustava (System Metaphor). Metafora sustava je analogna onome što većina drugih metodologija naziva arhitekturom sustava.Metafora mora biti jasno izražena te nedvosmisleno shvatljiva svim članovima projektnog tima.

• XP ne definira format ili tehniku u kojoj metafora mora biti izražena


XP tehnike

Jednostavan dizajn (Simple Design). Najčešći 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)

Prilagodba programskog kôda (Refactoring).Refactoring je tehnika kojom se pojednostavnjuje programski kod uklanjanjem ponavljanog koda i uklanjanjem (nepotrebnog) složenog koda.

Programiranje u paru (Pair Programming). Programeri rade u parovima, na način da jedan piše kôd, a drugi prati pisanje i revidira kôd pazeći da kod bude jasan i razumljiv.


XP tehnike

Zajedničko vlasništvo (Collective Ownership). Svi razvojni inženjeri koji sudjeluju u razvoju projekta imaju pravo mijenjati bilo koji njegov dio u bilo kojem trenutku.

Neprestana izgradnja novih verzija kôda (Continuous Integration). XP nalaže izgradnju novih verzija nekoliko puta dnevno, tj. nakon svake implementirane funkcionalnosti.

40-satni radni tjedan (40-hour week). Smatra se da umorni razvojnici ne mogu postići maksimalnu učinkovitost u radu, pa zabranjuje prekovremeni rad dva tjedna zaredom.

Nazočnost naručitelja (On-site customer). Naručitelj ili predstavnik naručitelja mora biti nazočan prilikom razvoja sustava kako bi bio dostupan u slučaju potrebe za pojašnjenima, te kako bi pomogao u definiranju sustava i pisanju testova.

Standardi pisanja kôda (Coding Standards). Programeri moraju pisati kôd u skladu s dogovorenim standardima.


Ujedinjeni razvojni proces

Unified software development process (skraćeno UDP)izvorno Objectorykasnije Rational Unified Process (RUP)

Iterativni i inkrementalni razvojsoftver se razvija i objavljuje po dijelovimaglavne faze obavljaju se kroz niz iteracijafaza konstrukcije (izrade)

• svaka iteracija obavlja se standardnim životnim ciklusom koji uključuje analizu, oblikovanje, ugradnju i provjeru

• rezultat iteracije je proizvod završne kakvoće (production-quality), provjeren i integriran, koji zadovoljava podskup ukupnih zahtjeva

• isporuke mogu biti interne ili prema korisnicima


Glavne faze razvojaPočinjanje (Inception)

opravdanje razloga za pokretanje projektaprikupljanje najvažnijih zahtjeva (10% detaljno)određivanje dosega projekta

Elaboracija (Elaboration)prikupljanje detaljnih zahtjeva (80%)globalna (high-level) analiza i dizajnustanovljavanje osnovne arhitektureplaniranje konstrukcije

Konstrukcija, gradnja (Construction)prikupljanje ostalih zahtjeva + promjene zahtjevarazrada arhitekture i izrada sustavakontinuirana integracija

Prijelaz (Transition)beta testiranje, podešavanje performansi, poduka korisnikaprovjera prihvatljivosti i zadovoljstva korisnika

Post-implementacija (Post-deployment)nastavak evolucijskog razvojauz očuvanje integriteta aplikacije


Glavne faze razvoja

Inception Elaboration Construction TransitionCore Workflows

Requirements

Analysis

Design

Implementation

Testing

iter.#1

iter.#2 — — — — — iter.

#n-1iter.#n

Increments


Određivanje iteracija

Broj i trajanje iteracijaza projekte do 18 mjeseci, otprilike 3 do 6 iteracijauobičajeno podjednakog trajanjamogu varirati ovisno o fazi (u konstrukciji duže)

Prva iteracijanajčešće najtežazahtijeva pripremu okruženja, ekipe i poslaopasna zbog moguće pretjeranog optimizmaako se krivo procijeni može izazvati pomake i neželjene učinke (smanjenje broja iteracija, ukupno slabije rezultate)

Organizacija i upravljanje projektom


Generički modeli organizacije

Projektna organizacijaosoblje organizirano unutar/oko projektaprednosti: brže odlučivanje, minimizira potrebno sučelje između članova, potiče identifikaciju osoblja s projektomnedostatci: prikladna za male projekte, minimalna raspodjela ekspertize

Funkcionalna organizacijaosoblje organizirano po funkcionalnim odgovornostimapojedina funkcija može podupirati više različitih projekataprednosti: potpomaže specijalizaciju (povećanje broja specijalista)nedostatci: smanjuje osjećaj pripadnosti projektu, tj. koheziju projekta

Matrična organizacijau osnovi funkcionalna, osoblje izmiješano u različitim projektimaprednosti:

• projektna komponenta pogoduje uspješnosti projekta• funkcionalna komponenta pogoduje povećanju specijalizacije

nedostatak: mogući sukob interesa


Organizacija i ekipni rad

Ekipni rad (teamwork)Ekipa je "samoupravljačka" jedinica, koja posluje u duhu suradnje svojih članova, njihove koordinacije i njima unaprijed poznatih procedura.Prednosti:

• kvalitetnije donošenje odluka – "ne treba nam soliti pamet"• motivacija članova – "zajedno smo jači"• inovativnost – "dvoje zna više nego jedan, …"

Sinergija• 2+2=5 ?


Razvoj ekipe

Razvoj ekipe (Forming, Storming, Norming, Performing)Formiranje – ljubaznost, nesklonost iznošenju stavova, prepuštanje vođenju"Jurišanje" – nesloga, sukob osobnosti, grupašenje/strančarstvo, pomanjkanje kvalitetne komunikacije, nesposobnost dogovaranjaNormiranje – uviđanje dobrih strana zajedničkog rada, uvažavanjePredstavljanje, djelovanje – povezivanje u učinkovitu operativnu grupu

Performing

NormingStorming

Forming

Group effort

Groupeffectiveness


Modeli ekipa

Klasična organizacija ekipe (Chief Programmer Team)glavni programer (chief programmer) utjelovljuje znanje i odlučivanje ekipe

• mora istovremeno biti dobar (vrhunski) programer i voditelj• u poboljšanoj (revidiranoj) organizaciji ima ulogu voditelja ekipe

rezervni programer (backup programmer)• služi kao zamjena za nekog od mlađih (junior) programera • u poboljšanoj (revidiranoj) organizaciji ima ulogu pomoćnika voditelja

Glavniprogramer (voditelj)

Programer

Rezervniprogramer (pomoćnik)

Administrator


Modeli ekipa

Moderna organizacija ekipe (4GL ekipa)voditelj projekta (project leader) – viši sistem analitičar suradnja s korisnikom (user liason) – poslovni analitičarkonceptualno i logičko oblikovanje – sistem analitičarisporuka sustava/aplikacija – poslovni analitičar nabava i pogon opreme – sistem inženjer za računalamrežni servisi – sistem inženjer za komunikacijeprogramsko inženjerstvo – programer-analitičarizrada dokumentacije – urednik/pisac (editor / technical writer)potporno osoblje: administrativni koordinator, tehničari, činovnici

Neke stvarne organizacije koriste gornju podjelu za opis radnih mjesta.


Modeli ekipa

Elastični model ekipeupravitelj ekipe – upravljanje osobljem (plaće, režije)voditelj ekipe – upravljanje razvojem (organizacija posla)projektant (analitičar-programer) – analiza, oblikovanje i izvedbaprogramer (programer aplikacija) – kodiranje, testiranjeadministrator baze podataka – administriranje baze podatakasistem inženjer(i) – održavanje mreže i računala

Sastav ekipe odgovara poslovima koje treba obaviti. Raspodjela uloga konkretnim članovima, kao i broj članova pojedine kategorije ovise o konkretnom projektu i raspoloživosti djelatnika.Na primjer:

• ulogu upravitelja ekipe i voditelja ekipe može imati ista osoba• ekipa može imati više programera• uloga administratora BP i sistem inženjera može se dodijeliti istoj osobi

Ovakav model ekipe može se primijeniti bez obzira na moguće različitu sistematizaciju radnih mjesta u nekoj organizaciji.


Organizacija velikih projekata

Upravitelj ili voditelj projekta, (project manager, project leader)

upravlja projektomposao obavlja više ekipanadređen voditeljima / upraviteljima ekipa

Ekipa može imati i dva voditelja

Upravitelj ekipe (team manager) planiranje, upravljanje i nadzor, rukovođenje ostalim članovima ekipe

Voditelj ekipe (team leader) tehnički aspekte aktivnosti koje se odnose na izradu i/ili uvođenje aplikacija/podsustava IS

voditelj projekta(project leader)

voditelj ekipe(team leader)

članoviekipe

upravitelj ekipe(team manager)

Upravljanje projektom



Upravljanje projektom (Project management)• “plan, staff, organize, schedule, direct, control”

Proces organiziranja, planiranja, upravljanja i nadzora razvoja sustava kojim će se postići prava funkcionalnost, na vrijeme i uz minimalne troškove.Uključuje različite 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 izvođače (ekipu)?• nadzor – Poštuje li se plan?

Elementi plana• Veličina projekta: funkcijske točke, broj linija koda• Napor izrade: čovjek-mjeseci• Vrijeme izrade: mjeseci

Izgradnja IS je posao koji se, unatoč posebnostima, obavlja kao neki drugi inženjerski poslovi, u planiranom vremenu i s planiranim resursima.



Planiranje projekta (planning)odrediti doseg, vremenski raspored i financijska sredstvaidentificirati pokroviteljstvo (sponsorship) kao jamstvo provedbeizabrati upravitelja/voditelja projekta odabrati alate za upravljanje projektompokrenuti projekt

Planiranje vremena, izrada rasporeda (scheduling)određivanje aktivnostiprocjena i pridjeljivanje sredstava potrebnih za pojedinu aktivnostprocjena trajanja pojedine aktivnostiodređivanje zavisnosti između aktivnostiizrada vremenskog rasporeda za projekt

Upravljanje, nadzor (controlling)određivanje postupka izvještavanja o napretku projektapraćenje napretka redovitim revizijamapreraspodjela sredstava i aktivnosti sukladno događajimaažuriranje vremenskog rasporeda


Planiranje projekata

Zašto planirati?Ako nešto može poći krivo, poći će krivo – u najgore vrijeme i na najgorem mjestu (Murphyjev zakon)Murphy je bio optimist (Grimmov korolar)

Što je plan (a što nije)plan ne predstavlja izvjesnost ili nešto što će se zacijelo dogoditiplan je naša najbolja procjena, zasnovana na pretpostavkama i iskustvuelementi plana: aktivnosti, ključni događaji (milestones), resursi (sredstva), troškovi

Programerski paradoks (Brooks, 1982)Nakon što je odgovarajući broj osoba pridružen nekom zadatku, dodavanje osoblja usporava razvoj, umjesto da ga ubrza.

Složeni projekti zahtijevaju velike ekipeNajbolja strategija je podijeliti projekt u niz manjih projekata (podprojekata) koji se mogu nezavisno obaviti.

Neuspješno planiranje = planiranje neuspjeha.


Planiranje projekta

Izrada planautvrditi ključne aktivnosti i događajeodrediti vremenski redoslijed aktivnosti i događajautvrditi potrebna sredstvapripisati/racionalizirati pripadne troškovepovezati pojedine pod-projekte/poslove u glavni projektiterativno razraditi plan revidirati plan sukladno postojećem iskustvu/saznanjima

Metode namijenjene upravljanju projektimaPRINCE (PRojects IN Controlled Environments)

• strukturirana metoda za upravljanje projektom• definiranje organizacijske strukture projekta• definiranje strukture i sadržaja plana projekta• definira skup provjera i izvješća koji se koriste za nadzor provedbe

COCOMOSUM


Tehnike za vremensko planiranje

Štapičasti/stupčasti dijagrami - Gantogrami (Gantt Charts)prikaz aktivnosti linijama, duljine razmjerne vremenu obavljanjaprikazuje predviđeni početak i kraj aktivnosti, njihovu međusobnu ovisnost te odgovornost za izvođenje aktivnostinaglašava vremensko preklapanje aktivnosti

ID Task Name Duration Start Finish Predeces

1 Projekt 110 days Mon 16.05.05 Fri 14.10.052 Određivanje zahtjeva 5 wks Mon 16.05.05 Fri 17.06.053 Oblikovanje sučelja 6 wks Mon 20.06.05 Fri 29.07.05 24 Oblikovanje izvješća 6 wks Mon 20.06.05 Fri 29.07.05 25 Modeliranje podataka 2 wks Mon 01.08.05 Fri 12.08.05 3;46 Kontrolna točka 0 days Fri 12.08.05 Fri 12.08.05 57 Korisnička dokumenta 5.5 wks Mon 15.08.05 Wed 21.09.05 68 Programiranje 5 wks Mon 15.08.05 Fri 16.09.05 69 Testiranje 3 wks Mon 19.09.05 Fri 07.10.05 810 Instalacija 1 wk Mon 10.10.05 Fri 14.10.05 7;9

5

Ana;ProgAna;ProgAna;Prog

Ana;Prog12.08

ProgProg

Prog

25 02 09 16 23 30 06 13 20 27 04 11 18 25 01 08 15 22 29 05 12 19 26 03 10May '05 Jun '05 Jul '05 Aug '05 Sep '05 Oct '05



Mrežni plan - PERT/CPM (Program Evaluation ReviewTechnique/Critical Path Method)

vremenski prikaz aktivnosti i njihovih uvjetovanosti• vidljivo je koje aktivnosti se mogu vršiti paralelno, a koje u sljedovima jer

zavise o ranijim aktivnostimanaglašava kritični put (critical path) projekta

Korisnička dokumentacijaStart: 15.08.05 ID: 7Finish: 21.09.05 Dur: 5.5 wks

Res: Prog

ProgramiranjeStart: 15.08.05 ID: 8Finish: 16.09.05 Dur: 5 wks

Res: Prog

TestiranjeStart: 19.09.05 ID: 9Finish: 07.10.05 Dur: 3 wks

Res: Prog

InstalacijaStart: 10.10.05 ID: 10Finish: 14.10.05 Dur: 1 wk

Res: Prog

Kontrolna točka

Milestone Date: Fri 12.08.05ID: 6

2.5 w ks

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 0May '05 Jun '05 Jul '05 Aug '05 Sep '05 Oct '05 Nov



Upravljanje ključnim događajima - (Milestone Management)prikaz planiranih aktivnosti i trenutnog statusa njihovog izvršenjau određenim vremenskim trenutcima razmatra se stupanj dovršenosti neke/nekih projektnih aktivnostiključni događaj je obično kraj neke faze ili aktivnosti

• očekuje se da faza ili aktivnost budu gotovi• druge aktivnosti započinju nakon što se to ostvari• pomak ključnog događaja ima za posljedicu vremenski preraspored

TEAM PROJECT – Recommended Milestone Management PlanTask/Deliverable Assigned Plan Date Actual Date Status

Prep Cover, Executive Summary, Contents, etc.Draft Introductions, Appendices, etc.Final Introductions, Appendices, etc.Full Edit of Final ReportEdit, Assemble, Distribute Final Copies

Write Status Report 1Write Status Report 2…Write Status Report 6

Draft Decomposition DiagramDraft Context DiagramDraft Essential Data Flow DiagramsDraft Typical Process SpecificationsFinal Decomposition DiagramFinal Context DiagramFinal Essential Data Flow DiagramsFinal Typical Process Specifications

2.5 w ks



Izrada plana

Definiranje zadataka i njihove međuzavisnostiPrimjer: zadatak T3 (npr. ugradnja komponenti) ovisi o zadatku T1 (npr. oblikovanje komponenti) oblikovanje mora biti završeno prije ugradnje.

Zadaci Trajanje (u danima) Ovisnosti T1 8 T2 15 T3 15 T1(M1) T4 10 T5 10 T2,T4(M2) T6 5 T1,T2 (M3) T7 20 T1(M1) T8 25 T4(M5) T9 15 T3,T6 (M4) T10 15 T5,T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)


Izrada plana

Izrada mrežnog plana na temelju definiranih zadataka i zavisnostiAktivna mreža čita se s desna na lijevo.Sve aktivnosti moraju završavati u ključnim točkama (M1 ,M2, M3, M4...). Tek kad se uspješno prijeđe ključna točka može se započeti sa sljedećom aktivnosti. Npr. zadatak T9, ne može započeti sve dok zadaci T3 i T6 nisu završeni. Dolazak na točku M4 pokazuje da su ti zadaci dovršeni.

T1

4/7/0225/7/02

25/7/02

25/8/02

18/7/02

4/8/02

5/9/02

19/9/02

14/7/02

11/8/02

Start

T4

M1

M3

T2

M5

T3

T6

M4M6

T9

M2

T7

T5M7

T8

T11

M8

T10

Kraj

T10


Izrada plana

Kritični putMinimalno vrijeme potrebno za završetak projekta može se procjenjivati prema najdužem putu na aktivnoj mreži (kritični put). U ovom primjeru to je 11 tjedana ili 55 radnih dana. (T1-T3-T9-T11-T12)Prekoračenje vremenskog roka najčešće je vezano uz kritični put

• Aktivnosti koje kasne, a ne leže na kritičnom putu ne bi trebale uzrokovati vremensko prekoračenje (npr. ako T8 kasni ne bi trebalo utjecati krajnji datum jer T8 ne leži na kritičnom putu).

T1

4/7/0225/7/02

25/7/02

25/8/02

18/7/02

4/8/02

5/9/02

19/9/02

14/7/02

11/8/02

Start

T4

M1

M3

T2

M5

T3

T6

M4M6

T9

M2

T7

T5M7

T8

T11

M8

T10

Kraj

T10


Prikaz plana

Gantogram je alternativni način prikaza vremenskog rasporedaVidimo da su neke od aktivnosti označene i zasjenjenim linijama što pokazuje da postoji određena fleksibilnost u datumu njihova završavanja.Ako se aktivnost ne završi na vrijeme kritični put neće biti ugrožen sve do završetka zasjenjene linije.

Start

M 1

M 5

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Fin ish

M 3

M 8

M 6

M 7

M 2

M 4

T1

T7

T2

T4

T 3

T12

T8

T11

T10

T5

T9

T6

2.5 w ks



Raspodjela zadataka

Štapićasti dijagram također pokazuje razdoblje u kojima je osoblje angažirano na projektu

Angažman ne mora biti kontinuiran –osobe mogu raditi na drugim projektima, ići na odmor ili obavljati neke druge aktivnosti.

Zadaci Inženjer T1 Anita T2 Ana T3 Anita T4 Josip T5 Jure T6 Ana T7 Igor T8 Josip T9 Anita T10 Ana T11 Josip T12 Josip

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T1

T2

T3

T4

T5

T6

T7

T8

T9

T10

T11T12

Josip

Anita

Ana

Igor

Tea


Evidencija projekta

Planovi, upravljanje, praćenje napretka, povijest projektaPrimjeri: \Upravljanje\*Drugi planovi ( Dokumentiranje)

Mogu se koristiti različiti programski proizvodi, pr.MS Project, CA Process Continuum, CASE pomagala za planiranjePrimjeri: \Upravljanje\*

Dokumentiranje planaPrimjeri: \Dokumentacija


Standard plana projekta

IEEE Standard for Software Project Management Plans 1058-1998Primjer, izvedenica

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

2. Project Organization 2.1 Process Model 2.2 Organizational Structure 2.3 Organizational Boundaries and Interfaces 2.4 Project Responsibilities

3. Managerial Process 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

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



a

Članekipe

b

Voditeljprojekta

D1 planprojekta

D2evidencijaradnih sati

P1

prilagodbaplana

P2

praćenjenapredovanja

Praćenje napretka (izvršenja)

Upravljanje projektom podrazumijeva stalni nadzor napredovanja.

Postavljanje projektnih ograničenjaNapraviti početnu procjenu projektnih parametaraDefiniranje ključnih točaka i izvještavanjewhile projekt nije završen ili otkazan loop

Nacrtaj vremenski raspored projektaPodijeli aktivnosti prema vremenskom rasporeduČekaj Provjeri napredak projektaRevizija procijenjenih projektnih parametaraAžuriranje vremenskog rasporeda projektaProvjeri projektna ograničenja i izvještajeIf (povećanje problema) then

Ponovni tehnički pregled i moguća revizijaend if

end loop

KomentarKašnjenjeStvarni završetak

% ispunjenja StatusStvarno trajanje

Planiranotrajanje

PrioritetPlanirani završetak

Planirani početak

IzvršiteljiZadatak


Elementi projektne evidencije

OsobaOsoba: NOT NULL

OznStatOsoba: Password: Rodjen: Zanimanje: Zvanje: SifDjelatnika: SifZnanstvenika:

PartnerKratPartner: NOT NULL

NazPartner: TipPartner: NOT NULLMBR: Email: URL: OpisPartner:

PosaoRbrPosao:

Osoba: NOT NULLDatPosao: NOT NULLKratProjekt: NOT NULLKratPosao: NOT NULLSati: NOT NULLOpisPosao: RbrZadatak: CijenaSata: NOT NULLrbr_posao:

PripadnostOsoba: NOT NULLKratPartner: NOT NULL

ProjektKratProjekt: NOT NULL

NazProjekt: KratPartner: NOT NULLSifProjekt: OznVrProjekt: OpisProjekt: KratRacun: URLprojekt: JavnoProjekt: NOT NULLAktivan: NOT NULL

StatZadatakOznStatZadatak: NOT NULL

NazStatZadatak: Aktivan: NOT NULL

UlogaKratUloga: NOT NULL

NazUloga:

UlogaOsobeRbrUlogaOsobe:

KratProjekt: NOT NULLOsoba: NOT NULLKratUloga: NOT NULL VrstaPosla

KratPosao: NOT NULL

NazPosao:

VrstaZadatkaVrstaZadatak: NOT NULL

ZadatakRbrZadatak:

KratProjekt: NazZadatak: NOT NULLVrstaZadatak: Nositelj: DatZadatak: RokZadatak: Prioritet: OznStatZadatak: DatStatZadatak: OpisZadatak: PlanPoc: PlanZav: StvarPoc: StvarZav: PlanTraj: StvarTraj: VrijZadatak: OznValuta: RbrDokument: LogAzur: DatAzur:


Nadzor napretka


Preporuke za planiranje poslova

Planiranje poslovaplanovi moraju biti ažurni, tj. prilagođeni stvarnom stanju izbjegavati detaljno planiranje poslova koji slijede u daljoj budućnosti – takve je dovoljno predvidjeti i najaviti, a pažnju usmjeriti na probleme koji se trenutno rješavajuplanovi trebaju što kraći, kako se vrijeme ne bi trošilo na detaljiziranje koje zbog moguće promjene stanja ionako neće biti istinitokonkretno razdoblje za koje se radi plan može varirati u ovisnosti o veličini projektanačelno je dovoljan jedan plan (i pregled realizacije) mjesečno, s tim da uključuje raspored tjednih aktivnostiposlove i zadatke treba uravnoteženo raspodijelitiviše pažnje treba posvetiti članovima koji zaostaju u izvršenju plana ili rješavaju složeniji problem u odnosu na ostale članovepo potrebi treba prerasporediti postojeće poslove


KolaboracijaKomunikacija

verbalna: brzo slušaj i misli - sporo i jasno govori, bilježi izrečenopisana: sadržaj, forma (predlošci), učestalostelektronička: E-mail, Chat, Newsobavješćivanje: pismenim putem, elektroničkom poštom (CC, BCC)pohrana informacija: mrežno kazalo, FTP kazalo, web poslužiteljorganizacija kazala: Admin, Materijali, Projekt, Backup, Tmp, itd.

Druženja moraju biti učinkovita!izbjegavati raspravu o općepoznatim ili nevažnim stvarimatreba 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 poboljšanje radaBrainstorming – iznošenje idejaIzbjegavanje "jedinih" rješenja – traženje alternativaBilježenje odluka – zapisivanje da bi se izbjegla pogrešna tumačenjaKonstruktivne povratne informacije – kritiziranje postupaka, a ne osobaRazumijevanje neuspjeha – analiza i poboljšanje svega što nije dobroRaspodjela moći i odgovornosti – ravnopravnost, izbjegavanje hijerarhije


Pomagala za podršku grupnom radu


Preporuke verbalnu komunikaciju

Konzultacije i razmjena informacijazajedničko dnevno druženje svih članova ekipedinamičko rješavanje detalja konkretnih praktičnih problemadnevno po 5 min., na početku radnog dana ili prije/poslije pauzepo potrebi se mogu sazvati i izvan dogovorenih termina

Sastanciupoznavanje s trenutnim stanjem, realizacijom plana i daljnjim poslovimarazmatranje problema, predlaganje načina i redoslijeda njihovog rješavanjajednom tjedno po 15 min., unaprijed dogovorenog dana, najbolje na početku tjednajednom mjesečno po 1 sat, prvog radnog dana u mjesecu (npr. ponedjeljak)po potrebi se mogu sazvati i izvan dogovorenih terminapoželjno je da se povremeno održe uz sudjelovanje nadređenih


Upravljanje vremenom (time management)

pravilno raspoređivanje poslova:točnom procjenom što i kada treba napravitipodjelom posla u pod-posloveizradom izvješća o napredovanju i gotovosti

izbjegavanje obavljanja tuđih poslova"mogu to i sam""mogu to brže""teže mi je objasniti, nego napraviti"

neprimjeren utrošak vremena (razbacivanje vremenom)druženje – telefonski razgovori, neproduktivna konverzacijazapočimanje – problem "prebacivanja" s jednog posla na drugi ili "promjene brzine" → pokušati s manje poslova i grupirati slične posloveugodni poslovi → izbjegavati produljenje rada na poslovima "za gušt"neugodni poslovi → izbjegavati odugovlačenje neugodnih ili teških poslova


Raspodjela uspjeha

Kriteriji za procjenu doprinosa članovauloženi trud (vrijeme)rezultati rada (korisnost, kvaliteta proizvoda i zadovoljstvo korisnika)objektivna težina posla (vrsta, uvjeti, intenzitet i trajanje)pristup radu (zalaganje, samoinicijativa, kooperativnost, odgovornost)sposobnost (svestranost, samostalnost)

Stimuliranje, nagrađivanje i trajno usavršavanjePretplata na stručne časopise, kupnja stručnih knjiga.Sudjelovanje na prezentacijama informatičke opreme i sajmovima, s ciljem praćenja stanja i trendova IT. Može se uključiti u sustav dodatnog nagrađivanja.Sudjelovanje na stručnim konferencijama, s ciljem praćenja razvoja struke. Može se uvjetovati pisanjem stručnih radova vezanih uz konkretne razvojne probleme.Stimulacija kroz formalnu izobrazbu (dodiplomski, poslijediplomski studij) kao uvjet ostanka u tvrtki u određenom razdoblju.Pohađanje stručnih tečajeva, prezentacija, radionica ili tečajeva iz engleskog jezika.


Neki kriteriji vrednovanja članova

JEZICI I POMAGALA Jezici treće generacije


Jezici treće generacije

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

Jezici za numeričke i znanstvene problemeFORTRAN (FORmula TRANslator), prvi rašireniji jezik za rješavanje numeričkih problemaALGOL (ALGOrithmic Language), jezik prikladan za rješavanje numeričkih i logičkih problemaBASIC (Beginner's All-Purpose Symbolic Instruction Code), prvotno jednostavan interpretator za interaktivno rješavanje numeričkih problema, kasnije se razvio u Visual Basic

Jezici za poslovne problemeCOBOL (COmmon Business Oriented Language), jezik prikladan za poslovne aplikacije i rad s podatcima

Jezici orijentirani listama i nizovimaLISP (LISt Processing), nastao s namjerom da se načini programski jezik primjeren za probleme iz područja umjetne inteligencije


Jezici treće generacije

Višenamjenski jeziciPL/I, prikladan za numeričko-inženjerske i poslovne aplikacijeC, razvijen radi izrade operacijskog sustava iz kojeg je nastao Unix, danas predstavlja standard kada se radi o proceduralnom programiranjuC++, C sa svojstvima objektnog programiranja Pascal, nastao s namjerom da se napravi jezik koji se može efikasno ugraditi na većinu računala, a koji će biti prikladan za učenje programiranja kao logičke i sistematske disciplineADA, pokušaj postavljanja standarda za jezik integriranih računalskih sustava (kontrola industrijskog pogona, zrakoplova ili bolničkih sustava za održavanje života)Modula-2 i Oberon, proširenje Pascala podrškom sistemskom programiranju, konceptom procesa i modula koji međusobno komuniciraju

Većina današnjih 3GL su višenamjenski jezici.

Jezici četvrte generacije


Jezici četvrte generacije

Jezici četvrte generacije (eng. 4th generation languages - 4GL)nastali krajem '70 i početkom '80 godinaneki 4GL čini skup raznorodnih pomagala povezanih u cjelinu

• 4GE = okruženja 4. generacije (4th Generation Environment)4GL naredbe integriraju naredbe jezika visoke razine

• 4GL = jezici vrlo visoke razine (Very High Level Languages)

Jezici posebne namjenespecijalizirani za određene klase problemazadovoljavaju potrebe za izradu 60 - 80 % svih aplikacija


Vrste i primjena 4GL

Jezici za rad s bazama podatakastrukturirani 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 rječniku 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

Primjeri: DB2, Oracle, Informix, MS SQL Server, MS Access



Matrični kalkulatori (Spreadsheet)tablica organizirana kao mreža redova i stupacaelementi tablice: konstante, izrazi (formule), grafički znakovi i objektielementi jezika

• aritmetičke i agregatne funkcije: SUM, COUNT, AVERAGE, MIN, MAX …• logički izrazi: OR, IF, AND, NOT• matematičke funkcije: SIN, COS,TAN, ASIN, EXP, SQRT, LN, LOG• statističke funkcije (npr. očekivanje) i financijske funkcije (npr. kamatni račun)

izračunavanje vrijednosti formula automatski slijedi promjenu podataka• pr. D31=ROUND(SUM(D1:D30) * 0.65;-1)

Integrirana programska podrška (Integrated Software)objedinjuje matrični kalkulator, obradu teksta i grafički prikaz podatakapristup bazama podataka (postavljanje upita)kreiranje dijalogaprimjena

• analiza, planiranje (financije, proizvodnja, prodaja)• pomoć pri donošenju odluka (problemi tipa "što ako")



Grafički orijentirani jeziciračunarska grafika - sinteza slika pomoću računala (dijagrami, animacija, digitalizacija) CAD/CAM (Computer Aided Design / Computer Aided Manufacturing) -računalom podržano projektiranje / računalom podržana proizvodnjasimulatori, programski paketi za prijenos slika, …

Zemljopisni IS (GIS - Geographic Information System)uključuju podatke o geometrijikoncept više slojevakoncept objekata

Programi i jezici za prijenos podatakakomunikacijski programi (modem, telefax, elektronička pošta...)rad u mreži računala (emulatori terminala, programi za prijenos podataka...)



Programska proširenja operacijskih sustava (ljuske) najrašireniji pristup nadgradnje OS (pr. Unix) - nad istom jezgrom (kernel), mogu se koristiti različite ljuske (shell)

• pr: Bourne shell, C shell, Mashey shellljuska - tumač (interpreter) naredbi

• kreiranje liste argumenata prilikom poziva programa (ls *.c ⇒ 1.c 2.c...)• sposobnost testiranja rezultata prethodno izvršene naredbe (if test prog then..)• slijedno izvođenje više programa (cd dir; ls; cd .. )• obrada u pozadini (background processing) (prog &, jobs, fg)• usmjeravanje ulaza i izlaza (prog > output.dat, prog < input.dat)• ulančavanje 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 proširenja OS• temelje se na primjeni računalne grafike• podržavaju rad s "prozorima", "ikone", izbornike...


Svojstva jezika četvrte generacije

Neproceduralna sintaksaproceduralni jezici - niz naredbi koji određuje KAKO se određena akcija obavlja

• npr. "otvori datoteku, ako nije EOF pomakni se, ..., zatvori datoteku"neproceduralni jezici - niz naredbi koji određuje ŠTO treba učiniti

• npr. "dohvati podatke … koji zadovoljavaju uvjet …"

Tipične 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 izvješća (selekcija, grupiranje, sortiranje, agregatne

funkcije...)

Uz neproceduralne, mnogi 4GL raspolažu proceduralnim naredbama da bi se omogućila ugradnja proceduralnih rješenja.



Primjer: Opisivanje podataka (SQL)

Primjer: Rukovanje podacima (selekcija u jeziku SQL)

Primjer: Definicija veze u rječniku podataka (ZIM)

Primjer: Rukovanje podacima (ZIM)

CREATE TABLE Osoba (IdOsobe INTEGER NOT NULL,Prezime CHAR(20) NOT NULL,Ime CHAR(20),Adresa CHAR(20),SifMjesta SMALLINT, NOT NULL

);

SELECT * FROM Osoba, Mjesto WHERE Osoba.SifMjesta = Mjesto.SifMjesta

AND Osoba.Prezime LIKE "K%"

Stanuje := Osoba.SifMjesta = Mjesto.SifMjesta

FIND ALL Osoba Stanuje MjestoFIND ALL Osoba (UNRELATED) Stanuje MjestoFIND ALL Osoba Stanuje Mjesto (COMPLETE)



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" "Dohvaćanje sljedećeg 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 OsobaDEFINE rMjesto RECORD LIKE Mjesto

...DISPLAY BY NAME rOsoba.*...INPUT BY NAME rOsoba.*

BEFORE FIELD SifMjestaMESSAGE "Unijeti šifru mjesta"

AFTER FIELD SifMjestaCALL Sel_Mjesto (rOsoba.SifMjesta)

RETURNING rMjesto.*IF status = NOTFOUND THEN

MESSAGE "Ne postoji mjesto"NEXT FIELD SifMjesta

END IF ...

END INPUT



Primjer: Izbornik i maska za obradu podataka



Primjer: Izvješće (ZIM)REPORT ALL FROM Osoba Stanuje Mjesto

SORTED BY Osoba.Prezime, Osoba.ImeFORMAT ACROSS 2 PAGESIZE 23 PAUSE 1

PAGE HEADING"Stranica:" $PAGE : MASK 'ZZ9' :

DETAIL LINEOsoba.Prezime : NEWLINE : Osoba.ImeOsoba.Adresa : NEWLINE :Mjesto.PostBr : NEWLINE : Mjesto.NazGrada

ENDREPORT Stranica 1

Ford AlanVukovar avenue 63383260 New York

Karson KitMelrose place 666282452 Los Angeles

Rock Bob

383260 New York

Ford KitSunset boulevard 2958



Integracija naredbi i razina jezikapojedina 4GL naredba zamjenjuje do nekoliko tisuća onih 3GL-akraće programske liste, jezgrovitiji i čitljiviji programski kod

• kodiranje s manje pogrešaka, olakšano otklanjanje pogrešakasličnost strukturiranom govornom jeziku

• pojednostavnjenje izrade programske dokumentacijeUčinkovitost kodiranja

izradi se pristupa u ranoj fazi razvoja (prototipski način rada)bitno ubrzana izrada (neproceduralna sintaksa, generatori koda)povećanje učinkovitosti 6-60 puta (ne i skraćenje vremena izrade!!!)

Učinkovitost uporabe računalapovećanje učinkovitosti uslijed smanjenja broja naredbi i interne optimizacije ista aplikacija napisana u jeziku SQL može na istom računalu biti 5-20 puta brža od odgovarajuće napisane u nekom 3GL kao što su COBOL ili FORTRANprednost se gubi u slučajevima kad se radi o aplikacijama koje uključuju rješenja proceduralnog tipa ⇒ rješenje: povezivanje na 3GL (npr. C)



Prenosivost (portabilnost) programske opremeoslonac na standardne OS (MS-DOS/WINDOWS, UNIX...)korištenje višerazinskih prevodilaca (pr. 4GL-EC-C-O-4GE)upravljački programi koji su nadgradnja OS (pr. SQLEXEC)manje dijalekata (npr. ANSI SQL standard)

Jednostavnost uporabe i rukovanjajednostavna i razumljiva sintaksa, sličnost govornom jezikukvalitetno razvojno i korisničko sučeljeprikladnost za učenje i rukovanje (jezikom i podacima)može se provjeriti tzv. dvodnevnim testom (TWO DAY TEST)

• većina korisnika bi morala moći naučiti osnove za 2-3 dana• nakon toga korisnik bi morao moći samostalno obaviti neke manje

poslove• poželjno je da korisnik nakon manjih prekida u radu (npr. 10 dana) bude

u mogućnosti nastaviti s radom bez poteškoćaNe vrijedi jednako za sve 4GL!

CASE pomagala


CASE

CASEeng. Computer Aided Software Engineeringeng. Computer Aided System Engineering

CAISEComputer Aided Information System Engineering

Računalom podržano programsko/informacijsko inženjerstvouporaba alata koji podupiru neku od faza životnog ciklusauporaba alata koji podupiru analizu zahtjeva i izradu specifikacija te uporaba alata koji potencijalno generiraju programski kôd na temelju specifikacije programske opremeautomatizacija programske opreme (Software Automation)


CASE pomagalaCASE pomagalo

programski sustav za pomoć pri izgradnji IS i razvoju programske opreme CASE pomagala podupiru (ne sva i ne uvijek!)

jednu ili više metoda informacijskog/programskog inženjerstva samo njima svojstvenu ili neku od standardnih metodologijamogućnost definiranja vlastite metodologije (meta-case)

Većina alata omogućuje izradu različitih vrsta dijagrama kao što sudijagrami dekompozicije funkcija/procesadijagrami modela podataka, npr. entiteti-vezegrafički prikaz programske logike, npr. akcijski dijagram

Često se radi o skupu alata integriranih u cjelinu kojom se podupire:jedna od faza životnog ciklusa (toolkit) ilicijeli životni ciklus (workbench)

Osnovne komponenterječnik podataka (data dictionary), meta-baza (meta-base) ili riznica (repository) za pohranu modelasučelje za izradu dijagrama i rukovanje meta-podacimaposebni dijelovi koji vode brigu o usklađivanju promjena načinjenih na različitim razinama raščlambe modela ili u različitim modelima.


CASE pomagala

Gornji CASE (Upper CASE, Front-End CASE)Automatizacija ili podrška ranih faza - planiranje, analiza i konceptualno oblikovanjekoristi se za definiranje zahtjeva i izradu modela ISneki alati podupiru reinženjerstvo poslovnih procesa, analizu isplativosti IS, planiranje prioriteta i dinamike razvoja te potreba za računalnom opremom

računalom podržano planiranje (Computer Aided Planning)analiza i dizajn, najčešće konceptualno i logičko oblikovanje

• oblikovanje baza podataka, prevođenje modela u 3NF• generiranje sheme BP (SQL naredbe)


CASE pomagala

Donji CASE (Lower CASE, Back-End CASE)potpora kasnijim fazama razvoja: detaljni dizajn, konstrukcija, ugradnja, održavanjegeneratori programske opreme (application generator, code generator)alati za održavanje programske opreme (version control) i prepravke (reengineering) alati za izradu programske dokumentacije (documentation tool)alati za povratno inženjerstvo (reverse engineering), npr. analizatori izvornog koda, alati za restrukturiranje kodaneki alati podupiru prototipni način rada oblikovanjem zaslonskih maski i izvješća 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 sadrže i dodatne module za povratno inženjerstvo, nadzor i upravljanje izvedbom te osiguranje kakvoće ISpotpuno integrirano CASE okruženje automatizira izradu modela organizacije, planiranje razvoja IS te izgradnju i primjenu ISintegracija alata ostvaruje se usvajanjem pravila određene metode razvoja, uporabom zajedničkog rječnika podataka i zajedničkog sučelja te automatiziranim prosljeđivanjem 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.


Generatori programske podrške

Programska oprema u osnovi podrazumijeva programski kôd.Aplikacija se također može sastojati od korisničkog sučelja i BP.Dobar generator mora biti u stanju proizvoditi sve dijelove PO.

Velik broj pomagala proizvodi samo neke dijelove, kao što su:zaslonske maske (screen painter, form generator)izbornici (menu generator)izvješća (report generator)programski kôd (code generator)baza podataka, tj. naredbe za kreiranje baze podatakanaredbe za grupnu (serijsku, batch) obradu podatakaprogramska dokumentacija

Često se generiraju srodne komponente:generator sučelja (standardno se radi o inteligentnom uređivaču zaslonskih maski) obično uključuje generator izbornika i dijalogageneratori koji proizvode programski kôd obično generiraju i ostale dijelove



Generatori se pojavljuju:u okviru pomagala za projektiranje programske opremekao dio jezika četvrte generacijekao zasebni proizvodi, koji integriraju svojstva 4GL i CASE pomagala namijenjenih oblikovanju

Generatore se može smatrati (donjim) CASE pomagalima.Kao minimalne odrednice za procjenu pripadnosti ovoj grupi mogu se uzeti mogućnost oblikovanja strukture podataka i oslonac na vlastiti rječnik podataka.

Mogućnost CASE pomagala da automatski generira izvorni kôd na osnovu opisa sustava obrnuto razmjerna broju metoda i tehnika ugrađenih u pomagalo.

Preporuča se koristiti dobar gornji CASE za početne faze razvoja, model prenijeti u rječnik podataka donjeg CASE alata, a zatim nastaviti s ostalim fazama.



Postojeći generatori iskazuju nedostatke o kojima u velikoj mjeri ovisi mogućnost i kvaliteta njihove primjene:

podsticanje izgradnje programskih sustava po dijelovimaad-hoc generiranje dijelova programske opreme koje vodi u neuravnoteženost ugrađenih rješenjanemogućnost generiranja složenih funkcija, što vodi ručnom kodiranjunesposobnost očuvanja ručno ugrađenih rješenja prilikom ponovnog generiranja

PreporukeNužno je odabrati alat koji generira izvorni kod i/ili dozvoljava ručne zahvate.Poželjno je koristiti alat koji omogućuje upravljanu izmjenu generiranog koda i održavanje naknadno ručno načinjenih izmjenaNažalost, ovakvi proizvodi još uvijek su rijetkost!


Primjer I-CASE alata

Popkin System Architect – ICASE koji podupire više metodologija (SSAD, OOAD), reverzno inženjerstvo i generiranje koda


Primjer alata za oblikovanje BP

CA AllFusion ERwin – dizajn i reinžnjerstvo BP, različite notacije (IDEF1X, IE, DM)


Primjer OO alata

Rational ROSE - potpora OO metodama (UML, OMT, Booch …)


Integracija CASE alata u razvojnu okolinu

Visual Paradigm for UMLSvi UML dijagramiAnaliza tekstaCRC kartice

Visual Paradigm for SDE (Smart Development Environment)integracija s Visual Studio, Eclipse, JBuilder, …reverzno inženjerstvogeneriranje izvornog kodaCommunity Edition

http://www.visual-paradigm.com


Reverzno inženjerstvo


Generiranje izvornog koda


Primjeri meta-CASE alata

Playground – uređivač dijagrama (objektni modeli, interakcije)MetaEdit – različiti dijagrami, definiranje vlastite notacije (meta-CASE)


Praćenje pogrešaka i upravljanje promjenama

OnTime Defect and Feature Management Systemhttp://www.axosoft.com/


Pomagalo za praćenje rada aplikacije

Visual Loggerhttp://www.axtools.com/


Web adrese

Internet adrese općenitohttp://www.qucis.queensu.ca/Software-Engineering/tools.htmlhttp://www.pittarese.com/Auburn/cse625/case.htm

Podrška životnom ciklusuhttp://www.visible.com/http://www.popkin.com/http://www.prolifics.com/do/panther.htmlhttp://www3.ca.com/Solutions/Solution.asp?ID=1629http://www3.ca.com/Solutions/Product.asp?ID=258http://www3.ca.com/Solutions/Product.asp?ID=256http://www.magicsoftware.com/bin/en.jsp?enPage=HomePage

UML i alatihttp://www.omg.org/uml/http://www.intelinfo.comhttp://www.objecteering.com/http://www.proxysource.com/http://argouml.tigris.org/http://www.sparxsystems.com.au/

SAŽETAK NAČELA IS


Korisnici i vlasnici sustava moraju biti aktivno uključeniZa uspješnu izgradnju IS apsolutno je nužan angažman vlasnika i korisnika.Osobe odgovorne za razvoj IS moraju naći vremena za vlasnike i korisnike, inzistirati na njihovu sudjelovanju i tražiti suglasnost od njih za sve odluke koje ih se tiču.

Treba koristiti pristup koji vodi k rješavanju problemaKorištenjem metodologija smanjuje se rizik zbog korištenja prečaca i pogrešaka.

• Metodologije proizvode potpunu i konzistentnu dokumentaciju, iz jednog projekta u drugi. Metodologija je, prije svega i najviše, postupak rješavanja problema prilikom izgradnje sustava!

Klasični pristup rješavanju problema je sljedeći::• Proučiti i shvatiti problem u kontekstu sustava,• Utvrditi zahtjeve koje mora ispuniti prikladno rješenje, • Prepoznati moguća rješenja i odabrati “najbolje”,• Projektirati i/ili ugraditi rješenje, • Promatrati i vrednovati utjecaj izrađenog rješenja te u skladu s time dotjerivati

rješenje.Kad se nema iskustva, postoji težnja da se preskoče ili skrate neki od koraka u rješavanju problema. Ishod se kreće u rasponu:

• rješava se krivi problem,• krivo se rješava problem,• izabere se krivo rješenje.

Uključenost sudionika i ispravan pristup problemima


Uspostava životnog ciklusa i standarda razvoja

Uspostaviti faze i aktivnostiVećina ž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, poboljšava rezultat, iterirajući kroz prethodne četiri faze, ali sada na umanjenim problemima i sa ciljem dotjerivanja i poboljšanja sustava.Faze se obično razlome na aktivnosti i zadatke kojima se može lako upravljati i lako ih riješiti,Faze projekta treba dovršavati u slijedu, od vrha do dna.

Uspostaviti standarde za konzistentan razvoj i dokumentiranjeStandardi za razvoj sustava obično opisuju:

• aktivnosti,• odgovornosti,• naputke ili zahtjeve za dokumentiranje,• provjere kvalitete.

Potreba za dokumentacijskim standardima ukazuje na uobičajenu pogrešku mnogih analitičara – njihov propust da izrađuju dokumentaciju kao trajnu aktivnost tijekom životnog ciklusa.


Opravdanje investicije u sustav

Opravdati izgradnju sustava kao kapitalnu investicijuInformacijski sustavi jesu kapitalna investicija,U kapitalnim investicijama, treba razmatrati:

• za svaki problem najvjerojatnije postoji nekoliko mogućih rješenja,• nakon što se prepoznaju varijante rješenja, analitičar treba vrednovati

svako od mogućih rješenja glede njegove izvodljivosti, a pogotovo ekonomičnosti.

– Ekonomičnost se definira kao odnos između dobiti ostvarene sustavom i troškova njegove izgradnje i pogona.


Ne oklijevati ako treba projekt otkazati

Ne oklijevati ako treba projekt otkazatiZnačajna prednost faznog pristupa razvoju sustava jest u tome što stvara nekoliko prilika da se ponovno ocijeni izvodljivost.Dugoročno gledano, otkazani projekti su jeftiniji od ugrađenih promašaja.Većina analitičara propusti podesiti procjenu troškova i rokova prilikom proširenja područja projekta. Kao rezultat, analitičar često nepotrebno prihvaća odgovornost za premašaj troškova i rokova.Pristup “puzećeg” preuzimanja obveza:

• Višestruke provjere izvodljivosti su ugrađene u metodologiju razvoja sustava.

• U bilo kojoj točki provjere, svi se već učinjeni troškovi smatraju nepovratnima i nevažnima za daljnje odlučivanje.

• Projekt treba u svakoj od točaka ponovno vrednovati da se utvrdi da li je još uvijek izvodljiv.

U svakoj točki provjere analitičar treba razmotriti:• ukidanje projekta ako više nije izvodljiv,• ponovnu procjenu troškova i rokova ako se opseg projekta povećava,• sužavanje opsega projekta ukoliko su proračun i rokovi fiksirani, ali

nedovoljni za ostvarenje svih ciljeva projekta.


Projektiranje i planiranje sustava

Podijeli pa vladajSvi su sustavi dijelovi većih sustava (nadsustava),Praktički svi sustavi sadrže manje sustave (podsustave),Sustav se podijeli u barem dva podsustava da bi se njime lakše ovladalo i sagradilo veći sustav,Podjelom većeg problema (sustava) u manje dijelove (podsustave) kojima je lakše upravljati, analitičaru se pojednostavnjuje postupak rješavanja problema.

Projektirati sustav tako da prati rast i promjeneMnogi analitičari upadnu u zamku izradivši sustav koji odgovara isključivo trenutnim zahtjevima,Entropijom se naziva prirodno i neizbježno kvarenje bilo kojeg sustava,Kada tijekom faze podrške sustavu, troškovi održavanja premaše troškove izgradnje novog sustava, sustav je zastario.


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, Vol33 (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.


ReferenceHirscheim, 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 EducationMurch R. (200): Project Management: Best Practices for IT Professionals,1/e, Prentice Hall PTR, ISBN 0130219142Pressman R.S. (2001): Software Engineering: A Practitioner's Approach, 5/e, McGraw-Hill, ISBN 0-07-249668-1Sommerville, 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.

Documents

FER PIS Predavanja