Zašto projektujemo informacione sisteme

Šta učimo ovog semestra

Petnaest sedmica, svaka s tri časa teorije i tri časa prakse. Danas: poglavlje 1 (Sedmica 1, označeno). Isti primjer kroz knjigu: DeliveryApp, narudžba N-1001 (24,50 €).

Literatura

1. B. Popović, K. Kuk: Informacioni sistemi, Kriminalističko-policijski univerzitet, Beograd, 2017.
2. J. S. Valacich, J. F. George: Modern Systems Analysis and Design, 9th ed., Pearson, 2020.
3. L. Jelenković: Sustavi za rad u stvarnom vremenu – skripta, FER, Zagreb, 2015.
4. D. Milićev: Programiranje u realnom vremenu – skripta, Beograd, 2002.
5. V. Kovačević, M. Popović: Sistemska programska podrška u realnom vremenu 1, FTN, Novi Sad, 2013.

Zašto ovo poglavlje

Ovo je prvo poglavlje, pa se ne nastavlja ni na šta: dovoljno je da ste nekad koristili aplikaciju na mobitelu. Prije nego što naučimo ijedan dijagram, pogledaćemo pet istinitih priča. Četiri govore o sistemima koji su koštali stotine miliona, a nisu radili ono što su ljudi trebali. Peta govori o maloj zemlji koja je projektovala dobro i zato danas većinu državnih poslova obavlja preko interneta. Iz tih priča izlazi pitanje na koje odgovara cijeli predmet: šta treba uraditi prije prvog reda koda, da bi sistem radio za ljude koji ga koriste?

U drugom dijelu poglavlja objašnjavamo šta je informacioni sistem, koje vrste postoje i ko sve radi na njegovom projektovanju. U trećem dijelu upoznajemo DeliveryApp, izmišljenu aplikaciju za naručivanje hrane koju projektujemo kroz cijelu knjigu, i njenih šest pravila. Na praktičnoj nastavi otvaramo VS Code i GitHub i pišemo prvi projektni dokument.

Riječi ovog poglavlja (1/3)

• Sistem – skup dijelova koji zajedno rade jedan posao (npr. saobraćaj, ljudsko tijelo, bolnica).
• Informacioni sistem (IS) – ljudi, podaci, pravila i programi kojima organizacija obavlja posao.
• Podatak – zapisana činjenica bez tumačenja (npr. „21,50”).
• Informacija – podatak s kontekstom koji nekome nešto znači („narudžba N-1001 košta 21,50 € bez dostave”).
• Projektovanje – odlučivanje šta sistem radi i od čega se sastoji, prije i za vrijeme gradnje.
• Zahtjev – rečenica koja kaže šta sistem mora raditi ili kakav mora biti.

Riječi ovog poglavlja (2/3)

• Model – pojednostavljena slika sistema koja prikazuje samo ono što je važno za jedno pitanje (npr. plan instalacija u kući).
• Dijagram – nacrtan model: kutije, linije i strelice s dogovorenim značenjem.
• Naručilac – osoba ili organizacija koja plaća i za koju se sistem pravi.
• Korisnik – onaj ko sistem svakodnevno koristi (ne mora biti isti kao naručilac).
• Poslovno pravilo – pravilo posla koje sistem mora poštovati (npr. „dostava je besplatna od 30,00 €”).
• Markdown – jednostavan način pisanja teksta s naslovima i listama, koji se čita i bez programa.

Riječi ovog poglavlja (3/3)

• Git i GitHub – Git pamti svaku verziju fajlova; GitHub je web stranica na kojoj tim dijeli te verzije.

Ciljevi poglavlja

Nakon poglavlja možete:

ispričati bar dvije priče o propalim informacionim sistemima i reći šta je u njima pošlo naopako; nabrojati četiri dijela informacionog sistema i za svaki dati primjer; razlikovati podatak i informaciju; razlikovati transakcijski, izvještajni i sistem za podršku odlučivanju, te ERP i CRM sisteme; objasniti zašto je greška otkrivena u fazi zahtjeva jeftinija od greške otkrivene nakon isporuke; nabrojati uloge u timu koji pravi sistem; opisati problem koji rješava DeliveryApp i izračunati cijenu narudžbe N-1001 prema pravilima PP-1 do PP-6; napraviti GitHub repozitorij i u njemu prvi dokument vizija.md.

Plan poglavlja – Sedmica 1: tri časa teorije i tri časa praktične nastave

Priča 1 – Aerodrom koji je čekao na kofere (Denver, 1995)

• Novi aerodrom u Denveru trebao je imati potpuno automatski sistem za prenos prtljaga kolicima na šinama.
• Sistem je bio toliko složen da u probama nije radio: kolica su iskakala, a koferi se gubili i cijepali.
• Aerodrom je otvoren 28. februara 1995, šesnaest mjeseci kasnije od plana, a automatski sistem napušten je 2005.
• Pouka je da se složenost procjenjuje na početku i da se sistem prvo proba u malom.

Priča 2 – Program za istražitelje koji nikad nije proradio (FBI, 2001–2005)

• FBI je 2001. naručio program Virtual Case File, da svi istražitelji vide slučajeve na jednom mjestu.
• Zahtjevi su se tokom godina mijenjali, a isporučeni softver ocijenjen je kao nedovršen i loše projektovan.
• U aprilu 2005. projekat je napušten nakon oko 170 miliona potrošenih dolara.
• Pouka je da zahtjevi moraju biti jasno zapisani, a svaka promjena mora imati svoj dogovoreni put.

Priča 3 – Šest ljudi prvog dana (Healthcare.gov, 2013)

• Stranica Healthcare.gov otvorena je u oktobru 2013. i prvog dana imala je oko 4,7 miliona posjetilaca.
• Prvog dana upisalo se samo šestero ljudi, a drugog dana ukupno 248.
• Dijelove sistema pravile su različite firme i oni su zajedno isprobani tek pred otvaranje.
• Pouka je da se arhitektura i broj korisnika koje sistem mora podnijeti planiraju na početku, a ne na kraju.

Priča 4 – Kad računar optuži čovjeka (britanska pošta, 1999–2015)

• Britanske pošte od 1999. koriste sistem Horizon, koji na kraju dana kaže koliko novca treba biti u kasi.
• Sistem je pokazivao manjkove koje poslovođe nisu mogle objasniti, a firma je vjerovala sistemu više nego ljudima.
• Od 1999. do 2015. više od sedam stotina poslovođa krivično je gonjeno, a presude se poništavaju od 2020.
• Pouka je da sistem nije nepogrešiv i mora biti projektovan tako da se svaka njegova odluka može provjeriti.

Priča 5 – Zemlja koja pita samo jednom (Estonija, od 2001)

• Estonija je nakon nezavisnosti 1991. odlučila da državne usluge projektuje za internet.
• Svaka služba čuva svoje podatke, a razmjenjuju ih preko dogovorenog sistema X-Road, koji radi od 2001.
• Pravilo „samo jednom” znači da država isti podatak od građanina traži samo jednom.
• Pouka je da uspjeh dolazi od dobrog dogovora o podacima i razmjeni, a ne od najskupljeg alata.

Šta je zajedničko svim pričama

• U svim pričama problem nije bio u znanju programiranja, nego u pitanjima postavljenim prekasno.
• Pitanja o složenosti, zahtjevima, arhitekturi, provjeri i podacima postavljaju se na početku.
• Estonija pokazuje da dobar projektni dogovor donosi uspjeh i bez najskupljih alata.

1.1 Četiri dijela sistema

Riječ sistem koristimo svaki dan: saobraćajni sistem, nervni sistem, školski sistem. Uvijek mislimo na isto: skup dijelova koji zajedno rade jedan posao. Nijedan dio sam ne radi taj posao. Semafor sam ne vodi saobraćaj; treba mu i vozač koji ga poštuje, i propis koji kaže šta znači crveno.

Informacioni sistem (skraćeno IS) je sistem kojim neka organizacija (firma, škola, bolnica, restoran) prikuplja, čuva, obrađuje i dijeli podatke da bi obavila svoj posao. Čine ga četiri dijela:

1. Ljudi – oni koji podatke unose, koriste i od njih zavise: konobar, kuhar, kupac, računovođa, direktor.
2. Podaci – zapisane činjenice: šta je naručeno, koliko košta, kome se nosi, kada je stiglo.
3. Pravila – dogovori kako se posao radi: ko smije mijenjati cijenu, koliko se naplaćuje dostava, šta se radi kad kupac otkaže.
4. Programi i uređaji – računari, mobiteli, mreža, baza podataka i aplikacije.

Primijetite da su programi tek četvrti dio. Ako fale ljudi, program stoji prazan. Ako fale pravila, svako upisuje šta hoće i niko ne zna koji je broj tačan. Ako su podaci pogrešni, ostala tri dijela uredno rade, ali vode pogrešnu priču, kao u britanskoj pošti.

1.1 Četiri dijela sistema

Slika iz svakodnevnog života: zamislite šalter pošte prije računara. Službenica (ljudi) prima pismo, upisuje ga u knjigu (podaci) po pravilu koje kaže da preporučeno pismo dobija broj i potpis (pravila), a koristi pečat, vagu i knjigu (uređaji). To je bio informacioni sistem i bez ijednog računara. Računar ga je samo ubrzao i omogućio da se podatak vidi u drugom gradu.

1.1 Četiri dijela sistema

Podatak i informacija

Dvije riječi koje se često miješaju treba razdvojiti odmah. Podatak je zapisana činjenica, bez tumačenja: „21,50”. Informacija je podatak s kontekstom koji nekome nešto znači: „narudžba N-1001 košta 21,50 € bez dostave”. Isti podatak može biti beskoristan ili veoma važan, zavisno od toga da li uz njega stoji šta je, čije je i u kojoj jedinici.

Zato projektant uvijek pita: koje podatke čuvamo, i šta uz svaki mora stajati da bi postao informacija? Za cijenu to je valuta, za udaljenost jedinica (km), za vrijeme datum i vremenska zona. Ako se ta pitanja ne postave, isti broj 4,2 jedan programer čita kao kilometre, a drugi kao milje. U poglavlju 10 vidjećemo da je upravo takva greška 1999. godine koštala jednu svemirsku letjelicu.

Ukratko – 1.1 Četiri dijela sistema

• Informacioni sistem čine ljudi, podaci, pravila te programi i uređaji.
• Programi su samo jedan od četiri dijela; bez ljudi, pravila i tačnih podataka sistem ne radi.
• Šalter pošte s knjigom i pečatom bio je informacioni sistem i prije računara.
• Podatak postaje informacija tek kad uz njega stoji šta je, čije je i u kojoj jedinici.

1.2 Vrste informacionih sistema

Informacioni sistemi se razlikuju po tome kome služe i koji posao rade. Korisno je poznavati nekoliko klasičnih vrsta, jer ih sreće svaki projektant.

1.2 Vrste informacionih sistema

Ove vrste lakše se pamte kao spratovi zgrade. U prizemlju je transakcijski sistem: bez njega nema ničega, jer iznad njega svi računaju s njegovim brojevima. Na prvom spratu je izvještajni sistem, koji te brojeve sabira. Na drugom je podrška odlučivanju, koja na osnovu sabranih brojeva predlaže šta uraditi. Ako je u prizemlju pogrešno upisana jedna narudžba, svaki izvještaj iznad je pogrešan.

ERP i CRM nisu „spratovi” nego velike gotove porodice programa koje firme kupuju i prilagođavaju. Projektant često ne pravi sve od nule, nego odlučuje šta se kupuje, a šta pravi, i kako se to dvoje povezuje.

1.2 Vrste informacionih sistema

Ukratko – 1.2 Vrste informacionih sistema

• Transakcijski sistem bilježi svaki događaj, izvještajni sistem ih sažima, a sistem za podršku odlučivanju predlaže.
• ERP vodi unutrašnje poslove firme, a CRM odnos s kupcima.
• Sve vrste stoje na transakcijama: pogrešan zapis u prizemlju kvari svaki izvještaj iznad.
• Projektant odlučuje šta se kupuje gotovo, a šta se pravi, i kako se dijelovi povezuju.

1.3 Šta znači projektovati

Projektovati znači odlučiti šta sistem treba raditi i od čega će se sastojati, i te odluke zapisati i nacrtati tako da ih razumiju svi koji na sistemu rade. Projektovanje odgovara na tri grupe pitanja:

1. Šta? – Koji problem rješavamo, za koga, i kako ćemo znati da je riješen? (zahtjevi, poglavlje 3)
2. Kako radi? – Koji su procesi, podaci i ponašanja sistema? (modeli, poglavlja 4–8)
3. Od čega je napravljen? – Koji su dijelovi, gdje rade i kako razgovaraju? (arhitektura i integracija, poglavlja 9–10)

Najbolja slika iz života je gradnja kuće. Niko ozbiljan ne počinje gradnju tako što kupi cigle i krene zidati. Prvo se razgovara s porodicom: koliko vas ima, treba li vam radna soba, hoće li baka živjeti s vama (to su zahtjevi). Zatim arhitekta nacrta tlocrt, presjeke, plan struje i vode (to su modeli). Tek onda dolazi građevinar. Ako se usred gradnje sjetite da vam treba još jedno kupatilo, to je moguće, ali košta mnogo više nego da ste ga ucrtali na papiru.

1.3 Šta znači projektovati

Cijena greške raste s vremenom

To je možda najvažnija ideja cijelog predmeta. Greška otkrivena dok je sistem samo rečenica u dokumentu ispravlja se brisanjem i novom rečenicom. Ista greška otkrivena kad je sistem programiran traži izmjenu koda, testova i dokumentacije. Ako je otkrivena tek kad sistem koriste hiljade ljudi, ispravka uključuje i štetu koju je greška već napravila, kao u britanskoj pošti.

Istraživanja u softverskom inženjerstvu odavno pokazuju da cijena ispravke raste što se greška kasnije otkrije, često deset puta i više između faze zahtjeva i rada u praksi. Tačan faktor zavisi od projekta i istraživanja, pa ga ne treba pamtiti kao zakon. Važan je smjer: što ranije, to jeftinije.

1.3 Šta znači projektovati

Ukratko – 1.3 Šta znači projektovati

• Projektovati znači odlučiti šta sistem radi, kako radi i od čega se sastoji, i te odluke zapisati.
• Kao kod kuće: prvo razgovor s porodicom (zahtjevi), pa nacrt (modeli), pa gradnja.
• Greška otkrivena rano ispravlja se jeftino, a otkrivena kasno košta mnogo više.
• Agilni razvoj ne ukida projektovanje, nego ga radi u malim koracima.

Provjeri se

1. Koja su četiri dijela informacionog sistema? Ljudi, podaci, pravila te programi i uređaji.
2. Koja je razlika između podatka i informacije? Podatak je zapisana činjenica, a informacija je podatak s kontekstom (šta je, čije je, u kojoj jedinici).
3. Zašto je jeftinije ispraviti grešku u fazi zahtjeva? Tada treba promijeniti samo rečenicu, a kasnije i kod, testove, dokumentaciju i štetu kod korisnika.

Odgovori: tipka R ili klik na zamućeno polje.

1.4 Tim koji pravi sistem

Informacioni sistem ne pravi jedan čovjek. Čak i u malom timu od pet ljudi postoje različite uloge, a jedan čovjek često ima više njih. Uloga nije zvanje, nego posao koji neko radi u projektu.

1.4 Tim koji pravi sistem

1.4 Tim koji pravi sistem

U ovom predmetu vi ćete najčešće biti u ulozi analitičara i arhitekte: pitate, zapisujete, crtate i odlučujete. Ali dobar projektant razumije i ostale uloge, jer svaki njegov dokument neko od njih čita.

Ukratko – 1.4 Tim koji pravi sistem

• Sistem pravi tim s više uloga: naručilac, vlasnik proizvoda, analitičar, arhitekta, UX dizajner, programer, tester, DevOps i korisnik.
• Uloga je posao u projektu, a jedan čovjek može imati više uloga.
• U ovom predmetu najčešće igramo uloge analitičara i arhitekte.

1.5 Projektni dokumenti

Projektovanje ostavlja trag u dokumentima. To nisu debele knjige koje niko ne čita, nego kratki, jasni fajlovi koji odgovaraju na jedno pitanje i koji se mijenjaju zajedno sa sistemom. U ovoj knjizi napravićemo za DeliveryApp ove dokumente:

1.5 Projektni dokumenti

1.5 Projektni dokumenti

Sve ćemo pisati u Markdownu i čuvati u Gitu. Markdown je običan tekst s malo oznaka (# za naslov, - za listu), koji se čita i bez ikakvog programa, a GitHub ga lijepo prikaže. Git pamti svaku verziju, pa se uvijek vidi ko je i kada promijenio zahtjev. To je odgovor na pouku iz priče o FBI-ju: promjena ima trag.

Ukratko – 1.5 Projektni dokumenti

• Projektovanje ostavlja kratke dokumente koji odgovaraju na po jedno pitanje.
• Za DeliveryApp pravimo viziju, backlog, priče, modele, bazu, arhitekturu, API, prototip, model prijetnji i plan isporuke.
• Dokumente pišemo u Markdownu i čuvamo u Gitu, pa svaka promjena ima trag.

1.6 Modeli i dijagrami: zašto crtamo

Model je pojednostavljena slika sistema koja prikazuje samo ono što je važno za jedno pitanje. Geografska karta je model: ne prikazuje svako drvo, nego ceste i gradove, jer odgovara na pitanje „kako da stignem”. Plan električnih instalacija kuće je drugi model iste kuće: ne prikazuje boju zidova, nego gdje idu kablovi.

Isto je s informacionim sistemom. Nema jednog dijagrama koji prikazuje sve. Postoji više modela, svaki za svoje pitanje:

• model procesa – kojim redom ljudi i sistem rade posao (poglavlje 4);
• model slučajeva korištenja – ko sve koristi sistem i za šta (poglavlje 5);
• strukturni model – koje „stvari” sistem poznaje i kako su povezane (poglavlje 6);
• model ponašanja – kako dijelovi razmjenjuju poruke i kroz koja stanja prolazi narudžba (poglavlje 7);
• model podataka – koje tabele čuvamo (poglavlje 8);
• model arhitekture – od kojih dijelova se sistem sastoji (poglavlje 9).

1.6 Modeli i dijagrami: zašto crtamo

Modele crtamo kao dijagrame: kutije, linije i strelice s dogovorenim značenjem. Dogovor je važan. Ako svako crta po svome, dijagram razumije samo njegov autor. Zato postoje standardni jezici za crtanje, kao što su BPMN za procese i UML za softver, o kojima učimo od poglavlja 4.

Dijagrame ćemo uglavnom pisati kao tekst, u jeziku Mermaid. Napišete nekoliko redova, a program od njih nacrta sliku. Prednost je ogromna: tekst se čuva u Gitu kao i kod, vidi se šta se promijenilo, i lako se ispravlja. Evo prvog primjera, koji pokazuje DeliveryApp i ko s njim razgovara:

flowchart LR
    K["Kupac"] -->|narudžba| Z(("DeliveryApp"))
    Z -->|narudžba| R["Restoran"]
    R -->|spremno| Z
    Z -->|zadatak| D["Dostavljač"]
    Z -->|naplata| P["Sistem plaćanja"]
    Z -->|udaljenost?| M["Servis mapa"]

Svaki red je jedna veza: ko (lijevo), kome (desno) i šta šalje (tekst između uspravnih crta). Kada se ovaj tekst iscrta, dobije se slika 1.4. U vlastitom Markdown fajlu blok mora početi riječju mermaid umjesto text; u knjizi pišemo text da bi se vidio izvorni kod.

1.6 Modeli i dijagrami: zašto crtamo

Ukratko – 1.6 Modeli i dijagrami: zašto crtamo

• Model je pojednostavljena slika sistema za jedno pitanje, kao karta ili plan instalacija.
• Sistem ima više modela: proces, slučajevi korištenja, struktura, ponašanje, podaci i arhitektura.
• Dijagram prati dogovoren jezik (BPMN, UML) da bi ga razumjeli svi.
• U knjizi dijagrame pišemo kao tekst u Mermaidu i čuvamo ih u Gitu.

Provjeri se

1. Šta radi vlasnik proizvoda? Predstavlja korisnike u timu i slaže zahtjeve po važnosti.
2. Zašto dokumente čuvamo u Gitu? Git pamti svaku verziju, pa svaka promjena zahtjeva ima trag ko ju je i kada napravio.
3. Zašto postoji više modela istog sistema? Svaki model odgovara na jedno pitanje i prikazuje samo ono što je za njega važno.

Odgovori: tipka R ili klik na zamućeno polje.

1.7 Problem i vizija

U jednom malom gradu rade tri restorana: Picerija R-1, Roštilj R-2 i Salatarnica R-3. Svaki prima narudžbe za dostavu telefonom. Evo kako izgleda jedno obično podne:

• U 12:10 zvoni telefon u Piceriji. Konobar zapisuje „2 margarite, sok, Ulica lipa 7”, ali ne čuje dobro broj kuće.
• Kuhar čita papirić umrljan sosom i pravi tri pizze umjesto dvije.
• Dostavljač ne zna adresu, pa zove kupca s puta. Kupac ne odgovara jer je u kupatilu.
• Dostava se naplaćuje „od oka”: danas 2 €, sutra 3 €, za istu ulicu.
• Na kraju mjeseca vlasnik ne zna koliko je bilo narudžbi ni koje jelo se najviše prodaje.

Gradsko udruženje ugostitelja odlučilo je da napravi jednu aplikaciju za sve restorane i nazvalo je DeliveryApp. Prvi projektni dokument je vizija: kratak tekst koji kaže koji problem rješavamo, za koga i kako ćemo znati da smo uspjeli. Vizija DeliveryApp glasi:

1.7 Problem i vizija

Vizija namjerno nema riječi o programskom jeziku ili bazi. Ona kaže šta i za koga, a kako dolazi kasnije. Iz vizije se vidi i kako ćemo mjeriti uspjeh: narudžba bez ponovnog zapisivanja, ista cijena za istu adresu, izvještaj na kraju mjeseca.

Ukratko – 1.7 Problem i vizija

• Tri restorana danas primaju narudžbe telefonom, pa se narudžbe gube, a cijena dostave računa „od oka”.
• DeliveryApp je zajednička aplikacija za sve restorane grada.
• Vizija kaže koji problem rješavamo, za koga i kako ćemo znati da smo uspjeli, bez riječi o tehnologiji.

1.8 Šest pravila DeliveryApp

Prije nego što se ijedan ekran nacrta, vlasnici restorana su se dogovorili o pravilima posla. To su poslovna pravila (oznaka PP) i sistem ih mora poštovati bez izuzetka:

1.8 Šest pravila DeliveryApp

Jelovnik u primjerima je kratak:

1.8 Šest pravila DeliveryApp

1.8 Šest pravila DeliveryApp

Narudžba N-1001, rukom

Kupac K-01 naručuje iz Picerije R-1 dvije pizze Margarita i jedan sok. Adresa je 4,2 km od restorana. Koliko plaća? Idemo korak po korak, s pravilom uz svaki korak.

1. Artikli: 2 × 9,50 + 2,50 = 19,00 + 2,50 = 21,50 €.
2. PP-1: 21,50 € nije manje od 5,00 €, pa se narudžba prima.
3. PP-3: 4,2 km nije više od 10 km, pa je adresa u zoni dostave.
4. PP-4: 21,50 € je manje od 30,00 €, pa se dostava plaća.
5. PP-2: preko 3 km je 4,2 − 3 = 1,2 km. „Započeti kilometar” znači da se i dio kilometra računa kao cijeli: 1,2 km su dva započeta kilometra (prvi cijeli i drugi započeti). Dostava je 2,00 + 2 × 0,50 = 3,00 €.
6. Ukupno: 21,50 + 3,00 = 24,50 €.

Ako K-01 upiše kod STUDENT10, popust je 10 % od 21,50 € = 2,15 €, što je manje od granice od 5,00 €. Ukupno je tada 21,50 − 2,15 + 3,00 = 22,35 €. Popust ne dira dostavu (PP-5).

1.8 Šest pravila DeliveryApp

Primijetite koliko je pitanja otvorilo samo jedno pravilo PP-2. Šta je sa tačno 3,0 km? (Dostava je 2,00 €, jer preko 3 km nema ništa.) A sa 3,1 km? (Započet je jedan kilometar, pa je 2,50 €.) Šta ako kupac naruči za tačno 30,00 €? (PP-4 kaže „od 30,00 € i više”, pa je besplatno.) Ovakva pitanja na granicama pravila su mjesta gdje se greške najčešće kriju, i tester ih postavlja prvi (predmet Testiranje softvera). Projektant ih mora postaviti još ranije: dok piše pravilo.

Ukratko – 1.8 Šest pravila DeliveryApp

• DeliveryApp ima šest poslovnih pravila, PP-1 do PP-6, o najmanjoj narudžbi, dostavi, zoni, besplatnoj dostavi, popustu i otkazivanju.
• Narudžba N-1001 ima artikle od 21,50 €, dostavu od 3,00 € na 4,2 km i ukupno košta 24,50 €.
• Sa kodom STUDENT10 popust je 2,15 €, pa je ukupno 22,35 €.
• Greške se najčešće kriju na granicama pravila, pa se granice provjeravaju dok se pravilo piše.

1.9 Put kroz knjigu

Kroz petnaest poglavlja DeliveryApp će proći cijeli put od ideje do sistema koji radi. Svako poglavlje dodaje jedan sloj, a sve slojeve drži zajedno isti primjer, narudžba N-1001.

1.9 Put kroz knjigu

Ukratko – 1.9 Put kroz knjigu

• Svako poglavlje dodaje DeliveryApp jedan sloj, od načina rada tima do isporuke.
• Narudžba N-1001 drži sve slojeve zajedno i mora svuda dati isti iznos.
• Na kraju predmeta svaki student brani svoj projekat DeliveryApp.

Provjeri se

1. Šta piše u viziji, a šta ne? Koji problem rješavamo, za koga i kako mjerimo uspjeh; ne piše tehnologija.
2. Kolika je dostava za 3,1 km i artikle od 10,00 €? 2,50 €, jer je započet jedan kilometar preko 3 km.
3. Koliko košta N-1001 bez koda i sa kodom STUDENT10? 24,50 € bez koda, 22,35 € sa kodom.

Odgovori: tipka R ili klik na zamućeno polje.

Praktična nastava – radno mjesto projektanta

Cilj tri časa praktične nastave je da svaki student ima uređeno radno mjesto koje će koristiti cijeli semestar, i u njemu prvi dokument DeliveryApp. Na kraju se predaje link na GitHub repozitorij.

Korak 1 – VS Code i Markdown

1. Instalirajte Visual Studio Code sa [code.visualstudio.com](https://code.visualstudio.com) (u učionici je već instaliran).
2. Napravite folder deliveryapp-projekat i otvorite ga u VS Codeu (File → Open Folder).
3. Napravite fajl README.md i upišite:

# DeliveryApp – projekat

Aplikacija za naručivanje hrane iz tri restorana malog grada.

Autor: (vaše ime), Projektovanje informacionih sistema, 2026.

1. Pritisnite Ctrl+Shift+V: otvara se pregled, kako će tekst izgledati. Znak # je postao veliki naslov.

Korak 2 – Mermaid u VS Codeu

1. U dijelu Extensions (Ctrl+Shift+X) potražite Markdown Preview Mermaid Support i instalirajte.
2. U README.md dodajte dijagram iz odjeljka 1.6, ali blok počnite riječju mermaid:

flowchart LR K["Kupac"] -->|narudžba| Z(("DeliveryApp")) Z -->|narudžba| R["Restoran"]

1. U pregledu (Ctrl+Shift+V) vidite nacrtan dijagram. Dodajte ostale učesnike: dostavljača, sistem plaćanja i servis mapa.
2. Ako se dijagram ne iscrta, provjerite: navodnike oko natpisa, strelicu --> bez razmaka, i da su uspravne crte |…| uparene. Isti tekst možete zalijepiti i na [mermaid.live](https://mermaid.live) da vidite tačnu grešku.

Korak 3 – Git i GitHub

1. Napravite nalog na [github.com](https://github.com) (ako ga nemate) i provjerite da je Git instaliran: u terminalu VS Codea (Ctrl+) upišite git --version`.
2. Na GitHubu napravite novi repozitorij deliveryapp-projekat (New repository, bez README-a, jer ga već imate).
3. U terminalu, u folderu projekta:

git init
git add README.md
git commit -m "Prvi opis projekta DeliveryApp"
git branch -M main
git remote add origin https://github.com/VAŠE-IME/deliveryapp-projekat.git
git push -u origin main

1. Osvježite stranicu repozitorija na GitHubu: vidi se README.md s nacrtanim dijagramom. GitHub sam iscrtava Mermaid.

Korak 4 – Dokument vizija.md

Napravite fajl vizija.md po ovom šablonu i popunite ga za DeliveryApp vlastitim riječima:

# Vizija – DeliveryApp

## Problem
(Šta danas ne valja? Tri do pet rečenica.)

## Za koga
(Ko su korisnici? Lista.)

## Rješenje u jednoj rečenici
Za … koji …, DeliveryApp je … koji … . Za razliku od …, … .

## Kako mjerimo uspjeh
(Tri mjerljive stvari, npr. „nijedna narudžba se ne zapisuje dvaput”.)

## Pravila posla
(PP-1 do PP-6 iz udžbenika.)

## Šta nije u prvoj verziji
(Npr. „plaćanje gotovinom pri preuzimanju”, „program vjernosti”.)

Posljednji odjeljak je važniji nego što izgleda. Zapisati šta nije u prvoj verziji štiti tim od toga da svaki dan dobija nove želje, kao FBI u priči 2.

Na kraju: git add vizija.md, git commit -m "Vizija DeliveryApp", git push.

Korak 5 – AI kao sagovornik (opcionalno)

Zalijepite svoju viziju u AI asistenta po izboru i zatražite: „Postavi mi deset pitanja koja bi vlasnik restorana mogao postaviti o ovoj viziji.” Pročitajte pitanja i izaberite tri koja su zaista korisna; odgovore dopišite u viziju. AI ovdje glumi radoznalog sagovornika, a odluku donosite vi. U viziju ne upisujte ničije pravo ime ni broj telefona.

Rezultat koji se predaje: link na repozitorij deliveryapp-projekat u kojem su README.md s Mermaid dijagramom učesnika i popunjen vizija.md, s najmanje dva commita.

Vježba za studenta 1 – četiri dijela.

Vježba za studenta 1 – četiri dijela. – rješenje

Vježba za studenta 2 – vrsta sistema.

Vježba za studenta 2 – vrsta sistema. – rješenje

Vježba za studenta 3 – cijena dostave.

Vježba za studenta 3 – cijena dostave. – rješenje

Vježba za studenta 4 – narudžba N-1002.

Vježba za studenta 4 – narudžba N-1002. – rješenje

Vježba za studenta 5 – pitanje koje je trebalo postaviti.

Vježba za studenta 5 – pitanje koje je trebalo postaviti. – rješenje

Sažetak u pet rečenica

1. Informacioni sistem čine ljudi, podaci, pravila te programi i uređaji, a programi su samo jedan od tih dijelova.
2. Priče iz Denvera, FBI-ja, Healthcare.gova i britanske pošte pokazuju da sistemi propadaju zbog pitanja postavljenih prekasno, a priča iz Estonije da dobar dogovor o podacima donosi uspjeh.
3. Projektovati znači odlučiti šta sistem radi, kako radi i od čega se sastoji, jer je greška otkrivena rano mnogo jeftinija od greške otkrivene kod korisnika.
4. Sistem pravi tim s više uloga, a projektant ostavlja kratke dokumente i dijagrame, koje u ovoj knjizi pišemo kao Markdown i Mermaid tekst u Gitu.
5. DeliveryApp je izmišljena aplikacija za naručivanje hrane sa šest poslovnih pravila, a njena narudžba N-1001 košta 24,50 € i taj broj mora biti isti u svakom sloju sistema.

Pitanja za ponavljanje

1. Navedite četiri dijela informacionog sistema i po jedan primjer iz restorana.
2. Koja je razlika između podatka i informacije? Dajte primjer.
3. Šta je pošlo naopako s automatskim sistemom prtljaga u Denveru, i koja je pouka?
4. Zašto je propao projekat Virtual Case File u FBI-ju?
5. Šta je kod Healthcare.gova bilo „premalo i prekasno”?
6. Koja je najvažnija pouka priče o britanskoj pošti?
7. Šta znači pravilo „samo jednom” u Estoniji i kako ga ostvaruje X-Road?
8. Po čemu se transakcijski sistem razlikuje od izvještajnog? Šta su ERP i CRM?
9. Zašto se cijena ispravke greške povećava s vremenom?
10. Nabrojte pet uloga u timu koji pravi sistem i šta svaka radi.
11. Šta je model i zašto jedan sistem ima više modela?
12. Izračunajte cijenu narudžbe N-1001 korak po korak, bez koda i sa kodom STUDENT10.