Appendix A — Dodaci
Dodatak A – Rječnik
| Pojam | Značenje | Poglavlje |
|---|---|---|
| ADR | kratak zapis arhitekturalne odluke: kontekst, odluka, posljedice, alternative | 7 |
| AOP | aspektno orijentirano programiranje: presjecajuće brige na jednom mjestu | 9 |
| Backlog | lista svega što treba napraviti, poredana po važnosti | 2 |
| Bod priče | relativna mjera veličine posla | 2 |
| Brooksov zakon | dodavanje ljudi zakašnjelom projektu čini ga još zakašnjelijim | 2 |
| Brzina tima | bodovi završeni u jednom sprintu | 2 |
| C4 model | dijagrami u četiri nivoa: kontekst, kontejneri, komponente, kod | 7 |
| CBSE | razvoj softvera sklapanjem komponenata | 8 |
| Ciklomatska složenost | broj nezavisnih putanja kroz funkciju | 4, 10 |
| CI / CD | kontinuirana integracija / kontinuirana isporuka | 5 |
| CMMI | model pet nivoa zrelosti procesa | 2 |
| COCOMO | Boehmov model procjene napora i trajanja | 10 |
| Čista arhitektura | pravila poslovanja u centru, zavisnosti samo prema unutra | 7 |
| Dostupnost | procenat vremena u kojem sistem radi | 6 |
| DORA metrike | učestalost isporuke, vrijeme izmjene, neuspjele izmjene, vrijeme oporavka | 5 |
| Funkcijske tačke | mjera veličine prema onome što softver radi za korisnika | 10 |
| IaaS, PaaS, SaaS | infrastruktura, platforma i softver kao usluga | 9 |
| IDE | integrisano razvojno okruženje | 1, 4 |
| IoT / IoE | internet stvari / internet svega | 9 |
| ISO/IEC 25010 | standard karakteristika kvaliteta softverskog proizvoda | 6 |
| Kanarinac | postepeno puštanje nove verzije dijelu korisnika | 5 |
| Kohezija | koliko dijelovi komponente pripadaju zajedno | 8 |
| Kontejner | paket programa sa svim zavisnostima | 5 |
| Miris koda | znak u kodu koji upućuje na problem dizajna | 4 |
| MVC / MVVM | obrasci koji odvajaju prikaz od logike | 4 |
| NFR | nefunkcionalni zahtjev: kako sistem radi | 6 |
| NPV | neto sadašnja vrijednost | 10 |
| ORM | prevođenje objekata u redove tabela i obrnuto | 4 |
| p95 | vrijednost ispod koje je 95 % mjerenja | 6 |
| Period povrata | vrijeme za koje se ulaganje vrati | 10 |
| Povezanost | koliko komponenta zavisi od drugih | 8 |
| Prekidač kola | zaštita koja privremeno prestaje zvati servis koji ne radi | 6 |
| Prekidač funkcije | uključivanje i isključivanje funkcije podešavanjem | 5 |
| Proizvodna linija | porodica proizvoda sa zajedničkim jezgrom i planiranom varijabilnošću | 9 |
| Pull request | zahtjev za spajanje izmjena uz pregled | 5 |
| Reaktivno programiranje | rad s tokovima događaja na koje kod reaguje | 9 |
| Refaktoring | promjena strukture koda bez promjene ponašanja | 4 |
| Repozitorij (obrazac) | objekat koji skriva bazu od logike | 7 |
| SBOM | spisak svih komponenata proizvoda | 8 |
| Scenarij kvaliteta | mjerljiv NFR: izvor, podsticaj, okruženje, artefakt, odgovor, mjera | 6 |
| SDD | dokument specifikacije dizajna | 3 |
| Semantička verzija | glavna.sporedna.zakrpa s tačnim značenjem | 8 |
| SOA | arhitektura sklopljena od servisa | 9 |
| SOLID | pet principa objektno orijentiranog dizajna | 3 |
| Tehnički dug | budući trošak lošijeg, bržeg rješenja | 4 |
| TCO | ukupna cijena vlasništva | 10 |
| Troslojna arhitektura | prezentacija, poslovna logika, podaci | 7 |
| UX | korisničko iskustvo | 3 |
| Višezakupnička usluga | jedna instalacija za mnogo zakupaca s odvojenim podacima | 9 |
Dodatak B – Podsjetnici
B.1 Mermaid i UML
```mermaid
classDiagram
Narudzba "1" *-- "1..*" Stavka : sadrži
Stavka "*" --> "1" Jelo : za
```| Dijagram | Početak bloka | Poglavlje |
|---|---|---|
| klasni | classDiagram |
3 |
| sekvencijalni | sequenceDiagram |
3 |
| stanja | stateDiagram-v2 |
3 (PIS 7) |
| tok, C4, komponente | flowchart TB ili flowchart LR |
7, 8 |
| Git grane | gitGraph |
5 |
Natpisi s razmacima, zagradama ili dvotačkom stavljaju se pod navodnike. Dijagram se uvijek provjeri iscrtavanjem (VS Code, GitHub ili mermaid.live).
B.2 Git u timu
| Naredba | Šta radi |
|---|---|
git switch -c ime-grane |
nova grana i prelazak na nju |
git status |
šta je promijenjeno |
git add fajl |
priprema izmjene za commit |
git commit -m "Dodaj tarifu za Grad B" |
zapis izmjene s porukom |
git push -u origin ime-grane |
slanje grane na GitHub |
git pull |
preuzimanje tuđih izmjena |
git switch main |
povratak na glavnu granu |
git log --oneline --graph |
istorija kao graf |
Tok rada (GitHub flow): grana → commit → push → pull request → pregled i CI → spajanje → brisanje grane.
B.3 Python i C# rame uz rame
| Ideja | Python | C# |
|---|---|---|
| objekat s podacima | @dataclass(frozen=True) class Tarifa: ... |
record Tarifa(...) |
| svojstvo samo za čitanje | @property def stanje(self): ... |
public string Stanje { get; private set; } |
| interfejs | class ServisMapa(Protocol): ... |
interface IServisMapa { ... } |
| greška | raise ValueError("…") |
throw new ArgumentException("…"); |
| hvatanje greške | try: … except ValueError as e: |
try { … } catch (ArgumentException e) { … } |
| zaokruživanje naviše | math.ceil(x) |
Math.Ceiling(x) |
| rječnik | {"A": t1, "B": t2} |
new Dictionary<string, Tarifa> { ["A"] = t1 } |
| lista s filtrom | [x for x in xs if x > 0] |
xs.Where(x => x > 0).ToList() |
| test | pytest: def test_...(): assert ... |
xUnit: [Fact] public void ...() { Assert.Equal(...); } |
| paket | pyproject.toml, PyPI, pip install |
.csproj, NuGet, dotnet add package |
| pokretanje | python fajl.py |
dotnet run Fajl.cs (.NET 10) |
B.4 Formule iz knjige
| Formula | Značenje | Primjer DeliveryApp |
|---|---|---|
| broj sprintova = backlog / brzina | plan izdanja | 126 / 21 = 6 |
| k = n(n − 1)/2 | kanali komunikacije | 6 ljudi → 15 |
| prioritet = V × U | rizik | RZ-1: 4 × 4 = 16 |
| zastoj = (1 − dostupnost) × 720 h | dozvoljeni zastoj u 30 dana | 99,5 % → 3,6 h |
| E = 2,4 × KLOC^1,05; T = 2,5 × E^0,38 | osnovni COCOMO | 6,4 KLOC → 16,9 čm, 7,3 mj |
| NPV = −I + Σ Pt/(1 + r)^t | neto sadašnja vrijednost | 9.950 € |
| povrat = godine prije + nedostaje / priliv te godine | period povrata | 2 + 12/18 = 2,67 |
Dodatak C – Šabloni dokumenata
C.1 Vizija proizvoda
Za **(ciljna grupa)** koji **(potreba)**,
**(ime proizvoda)** je **(vrsta proizvoda)**
koji **(glavna korist)**.
Za razliku od **(alternativa)**, naš proizvod **(ključna razlika)**.C.2 Registar rizika
| Oznaka | Rizik | V (1–5) | U (1–5) | V × U | Odgovor | Vlasnik | Pregled |
| --- | --- | --- | --- | --- | --- | --- | --- |
| RZ-1 | ... | | | | izbjeći / ublažiti / prenijeti / prihvatiti | | datum |C.3 Dokument specifikacije dizajna (SDD)
# Dizajn: (naziv funkcije)
1. Svrha i obim (šta radi, šta ne radi)
2. Kontekst (ko koristi, na šta utiče)
3. Struktura (klasni dijagram)
4. Ponašanje (sekvencijalni dijagram, alternativni tokovi)
5. Sučelje (wireframe)
6. Podaci (nove tabele i polja)
7. Nefunkcionalni zahtjevi
8. Odluke i alternative
9. Otvorena pitanjaC.4 Scenarij kvaliteta
| Dio | Vrijednost |
| --- | --- |
| Izvor | |
| Podsticaj | |
| Okruženje | |
| Artefakt | |
| Odgovor | |
| Mjera | |C.5 ADR
# ADR-00N: (naslov odluke)
Status: predloženo / prihvaćeno / zamijenjeno (ADR-…)
## Kontekst
## Odluka
## Posljedice (+ i −)
## Razmatrane alternativeC.6 Bilješke o izdanju (CHANGELOG)
## 2.1.0 – (datum)
### Dodano
- Tarifa za Grad D.
### Ispravljeno
- Poruka greške za adresu izvan zone.Dodatak D – Ispitni zadaci s rješenjima
Zadatak 1 (poglavlja 1–2). Tim od 7 ljudi ima brzinu 20, 26, 24 i 22 boda; backlog ima 184 boda; sprint traje dvije sedmice. a) Koliko sprintova i sedmica treba? b) Koliko je kanala komunikacije? c) Šta biste rekli rukovodiocu koji predlaže da se tim u sredini projekta poveća na 12 ljudi?
Rješenje. a) Brzina (20 + 26 + 24 + 22) / 4 = 23; 184 / 23 = 8 sprintova = 16 sedmica. b) 7 × 6 / 2 = 21 kanal. c) Sa 12 ljudi kanala je 66, više od tri puta više; novi ljudi bi prvo učili, a stari ih podučavali (Brooksov zakon). Bolje je smanjiti obim, pomjeriti rok ili, ako se ljudi ipak dodaju, napraviti drugi tim sa svojim jasnim dijelom proizvoda.
Zadatak 2 (poglavlje 3). Za funkciju „Ocijeni dostavu” (kupac nakon isporuke daje 1–5 zvjezdica i komentar) nacrtajte dopunu konceptualnog modela i navedite koji princip SOLID kaže da obavještenje restoranu o lošoj ocjeni ne ide u klasu Ocjena.
Rješenje. Novi pojam Ocjena (zvjezdice 1–5, komentar, datum), veza Narudzba “1” – “0..1” Ocjena, i posredno Dostavljac “1” – “*” Ocjena preko narudžbe. Princip jedne odgovornosti: Ocjena čuva pravila ocjene (npr. zvjezdice samo 1–5), a slanje obavještenja je odgovornost servisa obavještenja.
Zadatak 3 (poglavlje 4). Navedite četiri mirisa koda u funkciji i prepišite je čisto:
def f(n, t):
if t == 1:
return n * 0.9
if t == 2:
return n * 0.8
return nRješenje. Nejasno ime funkcije i parametara, magični brojevi (1, 2, 0.9, 0.8), grananje po tipu, decimalni broj za novac. Čisto: konstanta POPUSTI = {"STUDENT": 10, "VJERNI": 20} (procenti), funkcija iznos_s_popustom(iznos_centi, vrsta_kupca) koja vraća iznos_centi - round(iznos_centi * POPUSTI.get(vrsta_kupca, 0) / 100), i testovi za svaku vrstu kupca i nepoznatu vrstu.
Zadatak 4 (poglavlje 5). Opišite put izmjene „Dodaj tarifu za Grad D” od grane do svih korisnika, koristeći pojmove: grana, commit, pull request, pregled, CI, linter, test, kontejner, kanarinac, povratak.
Rješenje. Programer napravi granu tarifa-grad-d, doda tarifu i testove granica, napravi commit i push, otvori pull request. CI pokrene linter i testove; kolega pregleda kod i odobri. Nakon spajanja CI napravi sliku kontejnera s novom verzijom, koja ide na test okruženje, pa kao kanarinac na 5 % korisnika uz praćenje grešaka, pa svima. Ako greške porastu, radi se povratak na prethodnu sliku.
Zadatak 5 (poglavlje 6). Dostupnost je 99,8 % mjesečno (30 dana). a) Koliko je dozvoljeno zastoja? b) Prepišite „aplikacija mora biti brza i kad ima mnogo korisnika” kao scenarij kvaliteta. c) Predložite dvije taktike.
Rješenje. a) 0,002 × 720 h = 1,44 h ≈ 86 minuta. b) Izvor: kupci; podsticaj: 600 istovremenih korisnika pregleda jelovnike i naručuje; okruženje: normalan rad, 12–14 h; artefakt: DeliveryApp 2.0; odgovor: prikaz jelovnika i prijem narudžbe; mjera: p95 ≤ 2 s. c) Keš jelovnika i horizontalno skaliranje iza raspoređivača opterećenja (ili red poruka za obavještenja).
Zadatak 6 (poglavlje 7). Napišite ADR za odluku da se modul izvještaja za udruženje napiše u C# (ASP.NET Core), iako je ostatak DeliveryApp u Pythonu.
Rješenje (primjer). Kontekst: izvještaje će održavati partnerska firma koja radi u .NET-u; Dino i Emir bolje znaju C#; modul samo čita podatke. Odluka: poseban modul u ASP.NET Core, čita bazu preko repozitorija samo za čitanje, ne mijenja podatke. Posljedice: + partner ga lako održava, + jasna granica; − dva jezika u proizvodu, dva CI posla, dvije vrste testova. Alternative: izvještaji u Pythonu (odbijeno zbog održavanja kod partnera); gotov alat za izvještaje (odbijeno zbog licence i pravila po gradu).
Zadatak 7 (poglavlje 8). Komponenta deliveryapp-obavjestenja je u verziji 1.3.0. Odredite sljedeću verziju: a) dodan kanal „Viber”, stari rade; b) ispravljena greška zbog koje se SMS slao dva puta; c) funkcija posalji(telefon, tekst) zamijenjena sa posalji(poruka: Poruka). Za c) navedite šta moraju uraditi korisnici komponente.
Rješenje. a) 1.4.0; b) 1.3.1; c) 2.0.0 – korisnici moraju promijeniti sve pozive da prave objekat Poruka i ažurirati zavisnost na >=2,<3; poželjno je da 1.x još neko vrijeme dobija sigurnosne zakrpe.
Zadatak 8 (poglavlje 9). Objasnite kako bi „Praćenje dostavljača uživo” koristilo IoT i reaktivno programiranje, i navedite dva sigurnosna zahtjeva.
Rješenje. Uređaj (mobitel ili torba) šalje lokaciju svakih nekoliko sekundi kroz mrežu u oblak; u oblaku lokacije čine tok događaja na koji se pretplaćuje aplikacija kupca, uz filter (samo dostavljač te narudžbe) i map (lokacija → tačka na mapi). Sigurnost: lokacija je lični podatak, vidi je samo kupac čija je narudžba na putu i samo dok je na putu; uređaj nema fabričku lozinku, komunicira šifrovano i samo s oblakom DeliveryApp.
Zadatak 9 (poglavlje 10). Ulaganje 30.000 €, prilivi 10.000, 12.000, 14.000 i 14.000 €, stopa 10 %. Izračunajte NPV i period povrata i dajte preporuku.
Rješenje. Diskontovano: 9.091 + 9.917 + 10.518 + 9.562 = 39.088 €; NPV ≈ 9.088 € > 0, isplati se. Kumulativno: 10.000, 22.000, 36.000 – nakon dvije godine nedostaje 8.000 od 14.000, pa je povrat 2 + 8/14 ≈ 2,57 godina. Preporuka: prihvatiti, uz provjeru pesimističnog scenarija i kontrolnu tačku nakon prve godine.
Zadatak 10 (cijeli predmet). Tim od četiri studenta pravi mini-proizvod „Rezerviši termin” za frizerske salone. U deset tačaka opišite plan: od vizije do odluke o isplativosti, i za svaku tačku navedite poglavlje knjige.
Rješenje (primjer). 1) Vizija i zainteresovane strane (1). 2) Scrum, backlog, procjena bodovima, registar rizika (2). 3) Konceptualni model, sekvencijalni dijagram rezervacije, wireframe (3). 4) Kod po slojevima, čisti kod, Python ili C# (4). 5) Git grane, pull request, CI s testovima (5). 6) NFR: npr. potvrda rezervacije za ≤ 2 s, dostupnost 99,5 % (6). 7) Arhitektura: modularni monolit, ADR, C4 (7). 8) Komponenta „kalendar slobodnih termina” s verzijom (8). 9) SaaS za više salona (zakupci), podsjetnici kao reaktivni tok (9). 10) Funkcijske tačke, procjena napora, NPV i povrat uz pretpostavljene pretplate (10).
Dodatak E – Izvori priča i činjenica
Sve priče na početku poglavlja i okviri „Iz stvarnog svijeta” zasnovani su na javno dostupnim izvorima. Brojevi su provjereni u oktobru 2026; gdje se izvori razilaze, u tekstu stoji opreznija formulacija („oko”, „više od”).
| Poglavlje | Događaj | Glavni izvori |
|---|---|---|
| 1 | NATO konferencija, Garmisch, 7–11. 10. 1968 | P. Naur, B. Randell (ur.): Software Engineering: Report on a conference sponsored by the NATO Science Committee, 1969; B. Randell: „Fifty Years of Software Engineering”, 2018 |
| 1 | Dieselgate, 2015 | izvještaji američke agencije EPA i Ministarstva pravde, 2015–2017 |
| 2 | Brooks i OS/360 | F. P. Brooks: The Mythical Man-Month, 1975 (izdanje 1995) |
| 2 | Googleov projekat Aristotel, 2015 | Google re:Work, „Guide: Understand team effectiveness” |
| 3 | Apple u Xerox PARC-u, decembar 1979 | Computer History Museum; M. Hiltzik: Dealers of Lightning, 1999 |
| 4 | Toyota, presuda Bookout, oktobar 2013 | EDN, „Toyota’s killer firmware”, 2013; transkript svjedočenja M. Barra |
| 5 | CrowdStrike, 19. 7. 2024 | CrowdStrike, preliminarni izvještaj nakon incidenta (PIR) i analiza uzroka, 2024; Microsoft blog, 20. 7. 2024; CISA |
| 6 | Pokémon GO, juli 2016 | Google Cloud blog, L. Stone, 29. 9. 2016 |
| 6 | Netflix Chaos Monkey, 2011 | Netflix Tech Blog, „The Netflix Simian Army”, 2011 |
| 7 | Prime Video, 2023 | Prime Video Tech blog, mart 2023; devclass.com, 5. 5. 2023 |
| 8 | McIlroy, 1968 | M. D. McIlroy: „Mass Produced Software Components”, izvještaj NATO konferencije, str. 138–155 |
| 8 | left-pad, 22. 3. 2016 | npm blog, „kik, left-pad, and npm”, 2016; The Register, 23. 3. 2016 |
| 8 | Ariane 5, let 501, 4. 6. 1996 | izvještaj istražne komisije (J. L. Lions), 19. 7. 1996 |
| 8 | Log4j, decembar 2021 | CVE-2021-44228; CISA |
| 9 | Mirai i Dyn, 21. 10. 2016 | Dyn, izjava od 26. 10. 2016; Flashpoint; KrebsOnSecurity |
| 10 | NHS NPfIT, 2002–2011 | National Audit Office, 2013; House of Commons Public Accounts Committee, 2011 i 2013 |
Godine i autori pojmova (Royce 1970, Boehm 1981 i 1986, Tuckman 1965, Cunningham 1992, Reenskaug 1979, Kruchten 1995, Nygard 2011, Cockburn 2005, Gamma i dr. 1994, Szyperski 1998/2002, Kiczales i dr. 1997, McCabe 1976, Albrecht 1979, Porter 1985, Cohn 2009, Reaktivni manifest 2014, NIST 2011) navedeni su prema osnovnoj i dodatnoj literaturi predmeta.