Rječnik, podsjetnici, šabloni, ispitni zadaci i izvori priča.
Materijale priredio Erkan Islamović
erkan.islamovic@eubd.edu.ba · erkan.islamovic@gmail.com
Dodaci prate sva predavanja: rječnik, podsjetnici, šabloni, ispitni zadaci i izvori priča.
| Pred. | Dio 1 | Dio 2 | Praksa |
|---|---|---|---|
| 1 | Projekat i proizvod, trendovi, etika | Inženjerski pristup, alati, automatizacija | Repozitorij i vizija proizvoda |
| 2 | Modeli, uloge, planiranje | Rizici, tim, kvalitet, poboljšanje procesa | Plan izdanja, registar rizika |
| 3 | Konceptualni model, UML, SOLID | Prototip, UX, specifikacija dizajna | Wireframe i SDD |
| 4 | IDE, organizacija koda, OOP, okviri | Podaci, MVC/MVVM, čisti kod, refaktoring | Refaktoring funkcije |
| 5 | Git, pull request, CI | Testovi, CD, kontejneri | GitHub Actions |
Dodaci prate sva predavanja: rječnik, podsjetnici, šabloni, ispitni zadaci i izvori priča.
| Pred. | Dio 1 | Dio 2 | Praksa |
|---|---|---|---|
| 6 | Klasifikacija, mjerljivost | Taktike i redizajn | Mjerenje i keš |
| 7 | Odluke, pogledi, stilovi | Troslojna i čista arhitektura, predlošci | ADR i C4 |
| 8 | CBSE, odlike, interfejsi | Principi, smjernice, provođenje | Paket sa verzijom |
| 9 | SaaS, SOA, IoT, proizvodne linije | Aspekti, reaktivno programiranje | Dekorator i tok događaja |
| 10 | Vrijednost, troškovi, razvoj ili kupnja, TCO | Metrike, procjena, NPV, povrat | NPV u Pythonu |
| 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 |
| Pojam | Značenje | Poglavlje |
|---|---|---|
| Č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 |
| Pojam | Značenje | Poglavlje |
|---|---|---|
| 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 |
| Pojam | Značenje | Poglavlje |
|---|---|---|
| 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 |
| Pojam | Značenje | Poglavlje |
|---|---|---|
| Višezakupnička usluga | jedna instalacija za mnogo zakupaca s odvojenim podacima | 9 |
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).
| 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.
| 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) |
| 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 + Σ P~t~/(1 + r)^t | neto sadašnja vrijednost | 9.950 € |
| povrat = godine prije + nedostaje / priliv te godine | period povrata | 2 + 12/18 = 2,67 |
Za **(ciljna grupa)** koji **(potreba)**,
**(ime proizvoda)** je **(vrsta proizvoda)**
koji **(glavna korist)**.
Za razliku od **(alternativa)**, naš proizvod **(ključna razlika)**.| Oznaka | Rizik | V (1–5) | U (1–5) | V × U | Odgovor | Vlasnik | Pregled |
| --- | --- | --- | --- | --- | --- | --- | --- |
| RZ-1 | ... | | | | izbjeći / ublažiti / prenijeti / prihvatiti | | datum |# 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 pitanja| Dio | Vrijednost |
| --- | --- |
| Izvor | |
| Podsticaj | |
| Okruženje | |
| Artefakt | |
| Odgovor | |
| Mjera | |# ADR-00N: (naslov odluke)
Status: predloženo / prihvaćeno / zamijenjeno (ADR-…)
## Kontekst
## Odluka
## Posljedice (+ i −)
## Razmatrane alternative## 2.1.0 – (datum)
### Dodano
- Tarifa za Grad D.
### Ispravljeno
- Poruka greške za adresu izvan zone.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?
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.
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.
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.
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 nNejasno 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.
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.
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.
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.
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).
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.
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).
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.
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.
Objasnite kako bi „Praćenje dostavljača uživo” koristilo IoT i reaktivno programiranje, i navedite dva sigurnosna zahtjeva.
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.
Ulaganje 30.000 €, prilivi 10.000, 12.000, 14.000 i 14.000 €, stopa 10 %. Izračunajte NPV i period povrata i dajte preporuku.
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.
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.
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).
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 |
| Poglavlje | Događaj | Glavni izvori |
|---|---|---|
| 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.