Poglavlje 1: Zašto projektujemo informacione sisteme

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.

Literatura. Osnovna literatura predmeta:

  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.

Riječi ovog poglavlja.

  • 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.
  • 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.
  • 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

Čas Sadržaj Na času
Teorija 1 Uvodne priče; 1.1 Četiri dijela sistema Denver, FBI, Healthcare.gov, pošta, Estonija; šalter pošte
Teorija 2 1.2–1.6 Vrste sistema, projektovanje, tim, modeli Cijena kasne greške; plan kuće
Teorija 3 1.7–1.9 DeliveryApp: problem, pravila, put kroz knjigu N-1001 rukom: 24,50 €
Praksa 1–3 VS Code, Markdown, Mermaid, Git i GitHub Repozitorij deliveryapp-projekat i vizija.md

Uvodne priče predavač čita iz udžbenika; na slajdu su samo teze. Okviri „Za radoznale” i vježbe za studenta čitaju se i rade kod kuće.

Uvodne priče – kad sistem ne radi ono što ljudi trebaju

Prije prve definicije, pet istinitih priča. U nijednoj od njih problem nije bio u tome što programeri nisu znali programirati. Problemi su bili u pitanjima koja niko nije na vrijeme postavio: šta tačno treba napraviti, za koga, koliko je to teško, kako ćemo znati da radi, i šta radimo ako ne radi. Upravo ta pitanja uči projektovanje.

Ljudi, mjesta, godine i brojevi u ovim pričama su stvarni. Izvori su navedeni u SADRZAJ.md (Izvori priča) i u Dodacima.

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

Početkom devedesetih godina grad Denver u Sjedinjenim Američkim Državama gradi novi, ogroman aerodrom. Ponos projekta je automatski sistem za prtljag: kofer se preda na šalteru, stavi u mala kolica na šinama, i ta kolica ga sama, kroz kilometre podzemnih tunela, odvezu do pravog aviona. Bez ljudi koji guraju kolica, bez gubljenja vremena. Na papiru je to izgledalo kao budućnost.

U stvarnosti, kad su inženjeri počeli probe, kolica su iskakala iz šina, koferi su padali, a neki su bili doslovno pocijepani. Kofer bi stigao do pogrešnog aviona ili nikako. Problem nije bio jedan pokvaren dio, nego to što je sistem bio nevjerovatno složen: hiljade kolica, motora, senzora i računara koji su morali savršeno sarađivati, a vrijeme za projektovanje i probe bilo je prekratko za takvu složenost.

Aerodrom je zato otvoren tek 28. februara 1995. godine, 16 mjeseci kasnije nego što je planirano, i to s običnim, ručnim sistemom kao rezervom. Automatski sistem je godinama radio samo djelimično, za jednu aviokompaniju, a 2005. godine napušten je potpuno. Ostale su prazne šine u tunelima.

Pouka za projektanta: složenost se mora procijeniti na početku, a sistem se mora probati u malom prije nego što se od njega zavisi u velikom. U poglavlju 2 vidjećemo kako se veliki posao dijeli na male korake koji se provjeravaju jedan po jedan.

Ukratko.

  • 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)

Američka savezna policija, FBI, 2001. godine još radi s mnogo papira. Istražitelj koji želi vidjeti šta o nekom slučaju zna kolega u drugom gradu, često mora tražiti fasciklu poštom. Zato FBI naručuje novi program, nazvan Virtual Case File („virtuelni dosije slučaja”), koji bi sve slučajeve držao na jednom mjestu, dostupne svakom ovlaštenom istražitelju.

Posao je dobila velika softverska firma. Kroz naredne godine, kako su se mijenjale prilike i ljudi u FBI-ju, mijenjali su se i zahtjevi: šta program treba raditi, kako treba izgledati, s čim se mora povezati. Firma je kasnije tvrdila da je većina problema nastala upravo zbog zahtjeva koji su se mijenjali usput, a nezavisna provjera rađena početkom 2005. godine ocijenila je isporučeni softver kao nedovršen i loše projektovan. Istina je, kao i obično, bila na obje strane.

U aprilu 2005. godine FBI je odustao od projekta. Potrošeno je oko 170 miliona dolara, a istražitelji su i dalje radili po starom. Kasnije je napravljen drugi sistem, drugim pristupom: u manjim koracima, s čestim provjerama.

Pouka za projektanta: zahtjevi se moraju zapisati jasno, a promjene zahtjeva moraju imati svoj put (ko ih traži, ko ih odobrava, koliko koštaju). O tome je poglavlje 3.

Ukratko.

  • 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)

U oktobru 2013. godine američka vlada otvara web stranicu Healthcare.gov, na kojoj su građani trebali uporediti i kupiti zdravstveno osiguranje. Zakon je bio jedna od najvažnijih odluka tadašnje vlade, a stranica je bila mjesto na kojem su milioni ljudi trebali osjetiti njegovu korist.

Prvog dana stranicu je posjetilo oko 4,7 miliona ljudi. Mnogi nisu mogli ni otvoriti nalog. Stranice su se učitavale minutama, forme su se zaglavljivale, a podaci iz jednog dijela sistema nisu stizali u drugi. Interni zapisi koje je kasnije objavio Kongres pokazali su da se prvog dana kroz stranicu uspješno upisalo šestero ljudi, a do kraja drugog dana 248.

Šta se desilo? Sistem je pravilo mnogo različitih firmi, svaka svoj dio. Dijelovi su se prvi put zaista sastavili i probali zajedno tek pred samo otvaranje. Niko nije dovoljno rano provjerio koliko ljudi sistem može podnijeti odjednom. Popravke su trajale mjesecima, a stranica je proradila kako treba tek krajem te godine.

Pouka za projektanta: arhitektura (od kojih se dijelova sistem sastoji i kako oni razgovaraju) i zahtjevi za performanse („koliko ljudi odjednom”) nisu detalji za kraj. O njima su poglavlja 9 i 10, a o provjeri prije isporuke poglavlje 14.

Ukratko.

  • 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)

Velika Britanija ima hiljade malih pošta koje vode samostalni poslovođe, često u prodavnici u selu. Od 1999. godine sve pošte koriste novi računarski sistem za blagajnu i knjigovodstvo, nazvan Horizon. Na kraju dana sistem kaže koliko novca treba biti u kasi.

Ubrzo su poslovođe počele prijavljivati da im sistem pokazuje manjak novca koji ne mogu objasniti: danas 300 funti, sutra hiljadu. Novac nisu uzeli, a broj na ekranu kaže da fali. Firma koja je vodila pošte vjerovala je sistemu, a ne ljudima. Od 1999. do 2015. godine više od sedam stotina poslovođa krivično je gonjeno za krađu i lažno knjigovodstvo na osnovu podataka iz sistema. Neki su otišli u zatvor, mnogi su vraćali „manjak” iz svoje ušteđevine, porodice su se raspadale.

Godinama kasnije, sudovi su utvrdili da je sistem imao greške koje su mogle proizvesti takve manjkove, i da je o njima bilo poznato više nego što je priznato. Od 2020. godine presude se poništavaju jedna za drugom. Ovo se danas smatra jednom od najvećih sudskih grešaka u britanskoj istoriji.

Pouka za projektanta je možda najvažnija u knjizi: sistem nije nepogrešiv i mora biti projektovan tako da se njegova odluka može provjeriti. To znači da sistem čuva trag ko je, kada i šta uradio, da korisnik može prijaviti problem i da neko taj problem zaista istraži. O tragu i sigurnosti govori poglavlje 12, a o provjeri sistema poglavlje 14.

Ukratko.

  • 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)

Posljednja priča je drugačija, jer govori o uspjehu. Estonija je mala zemlja na Baltiku, s oko milion i trista hiljada stanovnika. Kad je 1991. godine postala nezavisna, imala je malo novca i nije imala stari državni računarski sistem koji bi je kočio. Odlučila je da projektuje državu za internet.

Ključna odluka nije bila jedna velika baza svih podataka. Bila je obrnuta. Svako ministarstvo i svaka služba drže svoje podatke u svojoj bazi, ali se dogovore kako će razgovarati. Taj dogovor i program koji ga provodi zovu se X-Road („X-cesta”) i rade od 2001. godine. Kad bolnica treba podatak o osiguranju, ona ga preko X-Roada pita službu za osiguranje, umjesto da od pacijenta traži novi papir. Pravilo koje iz toga slijedi zove se „samo jednom”: država od građanina isti podatak traži samo jednom, a dalje ga službe razmjenjuju same, uz zapis ko je i zašto podatak pogledao.

Danas preko X-Roada sarađuju stotine organizacija i hiljade usluga, a isti pristup preuzele su i druge zemlje. Uspjeh nije došao od najskupljeg programa, nego od dobrog projektnog dogovora: jasnih pravila ko šta čuva, kako se pita i ko smije vidjeti.

Pouka za projektanta: dobar sistem počinje od dogovora o podacima i razmjeni (poglavlja 8 i 10) i od pravila o privatnosti (poglavlje 12), a ne od izbora najmodernijeg alata.

Ukratko.

  • 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 prve četiri priče sistem je propao, kasnio ili nanio štetu. U svakoj se može pokazati trenutak u kojem bi jedno dobro postavljeno pitanje uštedjelo godine i milione:

Priča Pitanje koje je trebalo postaviti ranije Poglavlje
Denver, 1995 Koliko je sistem složen i kako ćemo ga probati u malom? 2, 14
FBI, 2005 Šta tačno treba napraviti i ko odobrava promjene? 3
Healthcare.gov, 2013 Od kojih dijelova se sistem sastoji i koliko korisnika mora podnijeti? 9, 10, 14
Britanska pošta Kako će korisnik dokazati da sistem griješi, i ko će to istražiti? 12, 14
Estonija, 2001 Ko čuva koji podatak i kako se službe dogovaraju? 8, 10, 12

Primijetite da nijedno pitanje nije „u kojem programskom jeziku ćemo pisati?”. Programski jezik je važan, ali dolazi kasnije. Projektovanje je posao koji se radi prije i za vrijeme programiranja, da bi programiranje gradilo pravu stvar.

Slika 1.1 – Pet uvodnih priča na vremenskoj liniji: četiri upozorenja i jedan uspjeh

Ukratko.

  • 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.

Dio 1 – Šta je informacioni sistem

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.

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.

Slika 1.2 – Četiri dijela informacionog sistema na primjeru restorana

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.

Na času. Uzmite telefonsku narudžbu hrane kakva se danas radi u većini malih restorana. Imenujte jednog čovjeka, jedan podatak, jedno pravilo i jedan uređaj u tom sistemu. Ima li u njemu ijedan računar?

Ukratko.

  • 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.

Vrsta Šta radi Primjer u DeliveryApp
Transakcijski sistem (TPS, transaction processing system) bilježi svaki pojedinačni događaj, brzo i tačno prijem narudžbe N-1001, naplata 24,50 €
Upravljački (izvještajni) sistem (MIS, management information system) sažima transakcije u izvještaje za rukovodstvo broj narudžbi po restoranu u oktobru
Sistem za podršku odlučivanju (DSS, decision support system) pomaže u odluci na osnovu podataka i modela „koliko dostavljača trebamo u petak od 12 do 14 h?”
ERP (enterprise resource planning) jedan sistem za sve unutrašnje poslove firme: nabavka, zalihe, plate, knjigovodstvo zalihe brašna i sira u Piceriji R-1
CRM (customer relationship management) vodi odnos s kupcima: ko je šta kupio, žalbe, ponude kupac K-01 naručuje svake srijede; pošalji mu ponudu

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.

Iz stvarnog svijeta. U svakoj priči iz uvoda pogođen je baš transakcijski sloj. U britanskoj pošti pogrešni su bili dnevni zbirovi kase, pa je pogrešan bio i svaki izvještaj i svaka optužba izgrađena na njima.

Ukratko.

  • 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.

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.

Slika 1.3 – Cijena ispravke greške raste s fazom u kojoj je otkrivena (ilustracija, ne tačni brojevi)

Česta zabluda. „Projektovanje je gubljenje vremena; bolje odmah programirati pa popravljati.” Kod male skripte za sebe to je tačno. Kod sistema koji koriste drugi ljudi, svaki sat projektovanja štedi mnogo sati popravki. Agilni pristup iz poglavlja 2 ne ukida projektovanje, nego ga radi u malim komadima, stalno.

Ukratko.

  • 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.

Dio 2 – Ko projektuje i čime

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.

Uloga Šta radi Pitanje koje stalno postavlja
Naručilac (sponzor) plaća projekt i odlučuje šta je važno „Šta dobijamo za ovaj novac?”
Vlasnik proizvoda (product owner) predstavlja korisnike u timu, slaže zahtjeve po važnosti „Šta je najvažnije sljedeće?”
Poslovni analitičar (sistem-analitičar) razgovara s korisnicima, zapisuje zahtjeve i procese „Kako se posao danas radi i šta boli?”
Arhitekta softvera bira od kojih dijelova se sistem sastoji i kako razgovaraju „Hoće li ovo izdržati 200 korisnika odjednom?”
Dizajner korisničkog iskustva (UX) crta ekrane i provjerava ih s ljudima „Može li novi kupac naručiti bez pomoći?”
Programer (razvojni inženjer) piše kod „Kako ovo napraviti jednostavno i ispravno?”
Tester (inženjer za kvalitet) traži greške prije korisnika „Šta bi ovdje moglo poći naopako?”
DevOps inženjer brine o isporuci, serverima i nadzoru „Kako ovo pustimo u rad bez prekida?”
Korisnik koristi sistem i govori šta mu treba „Zašto ovo dugme ne radi ono što očekujem?”

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.

Na času. Ko je u projektu Healthcare.gov iz priče 3 mogao prvi postaviti pitanje „koliko ljudi odjednom?”. Postoji li samo jedan tačan odgovor?

Ukratko.

  • 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:

Dokument Na koje pitanje odgovara Poglavlje
Vizija (vizija.md) Koji problem rješavamo i za koga? 1
Backlog (lista zahtjeva po važnosti) Šta radimo prvo, a šta kasnije? 2, 3
Korisničke priče s kriterijima prihvatanja Šta tačno sistem mora raditi i kako to provjeriti? 3
Modeli procesa i UML dijagrami Kako posao teče i kako se sistem ponaša? 4–7
Model podataka i SQL skripta Koje podatke čuvamo i kako su povezani? 8
Arhitektura (C4) i arhitektonske odluke Od čega se sistem sastoji i zašto baš tako? 9
Specifikacija API-ja (OpenAPI) Kako dijelovi razgovaraju? 10
Prototip ekrana Kako sistem izgleda korisniku? 11
Model prijetnji Šta može poći naopako sa sigurnošću? 12
Plan isporuke i nadzora Kako sistem pustimo u rad i pratimo? 14

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.

  • 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).

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.

Slika 1.4 – DeliveryApp i njegovi učesnici, iscrtano iz Mermaid teksta

Česta zabluda. „Dijagram je ukras dokumentacije.” Dobar dijagram je alat za razmišljanje: dok ga crtate, otkrijete pitanje koje niste postavili (npr. „ko javlja kupcu da restoran nije prihvatio narudžbu?”). Ako dijagram ne izaziva nijedno pitanje, vjerovatno je previše opšti.

Ukratko.

  • 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.

Dio 3 – Upoznajemo DeliveryApp

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:

Za stanovnike grada koji žele naručiti hranu iz lokalnih restorana, DeliveryApp je aplikacija na mobitelu i webu kojom se za nekoliko minuta izabere jelo, vidi tačna cijena s dostavom, plati i prati narudžba do vrata. Za razliku od narudžbe telefonom, ništa se ne zapisuje dvaput, cijena je uvijek ista za istu adresu, a restoran na kraju mjeseca zna šta je prodao.

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.

Na času. Ko su korisnici DeliveryApp? Nabrojte ih i za svakog recite jednu stvar koja ga danas, kod narudžbe telefonom, najviše nervira.

Ukratko.

  • 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:

Oznaka Pravilo
PP-1 Najmanja narudžba je 5,00 € (zbir artikala).
PP-2 Dostava je 2,00 € do 3 km, plus 0,50 € za svaki započeti kilometar preko 3 km.
PP-3 Dostava ide najdalje 10 km; dalje se narudžba ne prima.
PP-4 Za artikle od 30,00 € i više dostava je besplatna.
PP-5 Kod STUDENT10 daje 10 % popusta na artikle (ne na dostavu), najviše 5,00 €.
PP-6 Kupac smije otkazati narudžbu dok restoran nije počeo pripremu.

Jelovnik u primjerima je kratak:

Restoran Jelo Cijena
R-1 Picerija Pizza Margarita 9,50 €
R-1 Picerija Pizza Capricciosa 11,00 €
R-1 Picerija Sok 2,50 €
R-2 Roštilj Ćevapi (10 komada) 8,00 €
R-2 Roštilj Pljeskavica 7,50 €
R-2 Roštilj Jogurt 1,50 €
R-3 Salatarnica Salata s piletinom 9,00 €
R-3 Salatarnica Voćna salata 4,50 €
R-3 Salatarnica Limunada 3,00 €

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).

Broj za pamćenje. Narudžba N-1001 košta 24,50 €. Ovaj broj ćemo sresti u zahtjevima, dijagramima, bazi, API-ju i testovima. Svaki put mora izaći isti.

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.

Česta zabluda. „Pravila su jasna, to je samo sabiranje.” Pravilo PP-2 vlasnici su prvo napisali kao „0,50 € po kilometru preko 3 km”. Tek kad je neko pitao „a 3,1 km?”, dopisano je „za svaki započeti kilometar”. Jedna riječ je odlučila koliko će hiljade kupaca platiti.

Ukratko.

  • 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.

Poglavlje Šta dodajemo DeliveryApp
2 način rada tima: backlog i sprintovi
3 zahtjeve i korisničke priče
4 model procesa narudžbe (BPMN)
5 slučajeve korištenja
6 klase: Narudžba, Stavka, Restoran, Kupac
7 sekvencu naručivanja i stanja narudžbe
8 bazu podataka u SQLiteu
9 arhitekturu (C4)
10 API i mali server
11 prototip ekrana
12 sigurnost i privatnost
13 praćenje dostave i hladnjak restorana u realnom vremenu
14 automatsku provjeru i isporuku
15 AI pomoć i završnu odbranu

Slika 1.5 – Put DeliveryApp kroz knjigu: od vizije do isporuke

Ukratko.

  • 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.

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 (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:
```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 da vidite tačnu grešku.

Korak 3 – Git i GitHub

  1. Napravite nalog na github.com (ako ga nemate) i provjerite da je Git instaliran: u terminalu VS Codea (Ctrl+) upišitegit –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žbe

Vježba za studenta 1 – četiri dijela.

Za sistem biblioteke na fakultetu navedite po dva primjera za svaki od četiri dijela informacionog sistema.

Rješenje. Ljudi: bibliotekar, student. Podaci: naslov knjige, datum posudbe. Pravila: knjiga se vraća za 15 dana; najviše tri knjige odjednom. Programi i uređaji: program za evidenciju posudbi, čitač bar-koda. Prihvatljivi su i drugi primjeri, ako je svaki u pravoj grupi (npr. „rok vraćanja” je pravilo, a ne podatak; „datum vraćanja upisan za jednu posudbu” je podatak).

Vježba za studenta 2 – vrsta sistema.

Razvrstajte: transakcijski, izvještajni ili sistem za podršku odlučivanju.

  1. Upis da je narudžba N-1002 plaćena u 12:31.
  2. Grafikon broja narudžbi po danima u sedmici za vlasnika restorana.
  3. Prijedlog „u petak od 12 do 14 h angažujte i četvrtog dostavljača”.

Rješenje. 1 transakcijski (bilježi jedan događaj). 2 izvještajni (sažima mnogo događaja). 3 podrška odlučivanju (predlaže odluku na osnovu podataka).

Vježba za studenta 3 – cijena dostave.

Kolika je dostava (u €) za iznos artikala 12,00 € i udaljenost: a) 2 km, b) 3 km, c) 5,5 km, d) 10 km, e) 10,5 km?

Rješenje. a) 2,00 € (do 3 km). b) 2,00 € (tačno 3 km nije „preko 3 km”). c) Preko 3 km je 2,5 km, a to su tri započeta kilometra: 2,00 + 3 × 0,50 = 3,50 €. d) Preko 3 km je 7 km: 2,00 + 7 × 0,50 = 5,50 €. e) Narudžba se ne prima, jer je adresa dalje od 10 km (PP-3).

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

Kupac K-02 naručuje iz Roštilja R-2 četiri porcije ćevapa, na adresu 2,5 km od restorana. Koliko plaća? Navedite pravilo za svaki korak.

Rješenje. Artikli: 4 × 8,00 = 32,00 €. PP-1: više od 5,00 €, prima se. PP-3: 2,5 km je u zoni. PP-4: 32,00 € je više od 30,00 €, pa je dostava besplatna. Ukupno 32,00 €.

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

Za svaku uvodnu priču napišite jedno pitanje koje bi vi, kao projektant, postavili na prvom sastanku, i kome biste ga postavili.

Rješenje. Primjeri: Denver – „Možemo li prvo napraviti probnu liniju za jedan terminal?” (naručiocu i inženjerima). FBI – „Ko odobrava promjenu zahtjeva i kako mjerimo njenu cijenu?” (naručiocu). Healthcare.gov – „Koliko ljudi očekujemo prvog dana i kada probamo sve dijelove zajedno?” (arhitekti i naručiocu). Pošta – „Kako poslovođa može dokazati da je broj u kasi pogrešan, i ko to istražuje?” (naručiocu i korisnicima). Estonija – „Ko čuva koji podatak i ko smije pitati za njega?” (svim službama). Dobar odgovor ima pitanje i osobu kojoj je upućeno.

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.

Odgovori na pitanja za ponavljanje.

  1. Ljudi (konobar, kuhar, kupac), podaci (šta je naručeno, adresa, cijena), pravila (dostava se naplaćuje po udaljenosti) te programi i uređaji (aplikacija, mobitel, server).
  2. Podatak je zapisana činjenica bez tumačenja, npr. „21,50”. Informacija je podatak s kontekstom koji nekome nešto znači, npr. „narudžba N-1001 košta 21,50 € bez dostave”.
  3. Sistem kolica na šinama bio je toliko složen da u probama nije radio: kolica su iskakala, a koferi se gubili i cijepali. Aerodrom je otvoren 16 mjeseci kasnije, 1995, a sistem je napušten 2005. Pouka je da se složenost procjenjuje rano i da se sistem prvo proba u malom.
  4. Zahtjevi su se tokom godina mijenjali bez jasnog puta za promjene, a isporučeni softver ocijenjen je kao nedovršen i loše projektovan. FBI je odustao 2005. nakon oko 170 miliona dolara.
  5. Premalo je bilo zajedničkog probanja dijelova koje su pravile različite firme i provjere koliko korisnika sistem može podnijeti, a to je urađeno prekasno, tek pred otvaranje. Prvog dana upisalo se šestero ljudi.
  6. Sistem nije nepogrešiv i mora biti projektovan tako da se njegova odluka može provjeriti: da čuva trag, da korisnik može prijaviti problem i da se problem zaista istraži.
  7. Država od građanina isti podatak traži samo jednom. Službe čuvaju svoje podatke i razmjenjuju ih preko dogovorenog sistema X-Road, uz zapis ko je i zašto podatak pogledao.
  8. Transakcijski sistem bilježi svaki pojedinačni događaj (jednu narudžbu), a izvještajni sažima mnogo događaja za rukovodstvo (broj narudžbi u mjesecu). ERP vodi unutrašnje poslove firme (nabavka, zalihe, plate), a CRM odnos s kupcima.
  9. Rano se mijenja samo rečenica u dokumentu, a kasnije i kod, testovi, dokumentacija, pa i šteta koju je greška već napravila kod korisnika.
  10. Na primjer: vlasnik proizvoda slaže zahtjeve po važnosti; analitičar zapisuje zahtjeve i procese; arhitekta bira dijelove sistema; programer piše kod; tester traži greške prije korisnika. Mogu se navesti i naručilac, UX dizajner, DevOps inženjer i korisnik.
  11. Model je pojednostavljena slika sistema koja prikazuje samo ono što je važno za jedno pitanje. Sistem ima više modela jer ima više pitanja: kako teče posao, ko koristi sistem, koje podatke čuva, od čega se sastoji.
  12. Artikli 2 × 9,50 + 2,50 = 21,50 €. Narudžba je iznad 5,00 € (PP-1), u zoni (4,2 ≤ 10 km, PP-3) i ispod 30,00 € (PP-4), pa se dostava plaća. Preko 3 km je 1,2 km, dva započeta kilometra: 2,00 + 2 × 0,50 = 3,00 €. Ukupno 24,50 €. Sa STUDENT10: popust 10 % od 21,50 = 2,15 € (manje od 5,00 €), pa je 21,50 − 2,15 + 3,00 = 22,35 €.