Poglavlje 2: Životni ciklus i metodologije razvoja
Priča za početak. U februaru 2001. godine sedamnaest programera i konsultanata iz Amerike i Evrope sastalo se u skijalištu Snowbird u planinama američke savezne države Utah. Svaki od njih imao je svoj način vođenja softverskih projekata, s imenima kao što su Scrum, Extreme Programming i Crystal. Svađali su se oko detalja, ali su se složili oko jednog: veliki projekti koji godinama pišu dokumentaciju prije prvog programa koji radi previše često propadaju. Za dva dana napisali su jednu stranicu teksta, Manifest agilnog razvoja softvera: četiri vrijednosti i dvanaest principa. Stranica je i danas na internetu, u izvornom obliku, a riječ „agilno” je od tada postala svakodnevica u firmama širom svijeta. Zanimljivo je da ni „vodopad”, protiv kojeg su ustali, nije bio zamišljen kao slijepo pravilo: inženjer Winston Royce, čiji se rad iz 1970. uzima kao njegov prvi opis, u istom tom radu upozorio je da je čisti redoslijed faza bez povratka rizičan.
U poglavlju 1 vidjeli smo da sistemi propadaju kad se prava pitanja postave prekasno. Ovo poglavlje odgovara na pitanje kojim redom se ta pitanja postavljaju i kako tim organizuje posao od ideje do sistema koji radi. Prvo upoznajemo faze kroz koje prolazi svaki sistem i najstariji način da se one poredaju, vodopad. Zatim agilni pristup i Scrum, koji danas koristi većina timova. Na kraju Kanban, DevOps i alate koje programeri koriste kroz cijeli ciklus. Na praktičnoj nastavi pravimo tablu zadataka za DeliveryApp na GitHubu i planiramo prvi sprint.
Literatura. Osnovna literatura predmeta:
- B. Popović, K. Kuk: Informacioni sistemi, Kriminalističko-policijski univerzitet, Beograd, 2017.
- J. S. Valacich, J. F. George: Modern Systems Analysis and Design, 9th ed., Pearson, 2020.
- L. Jelenković: Sustavi za rad u stvarnom vremenu – skripta, FER, Zagreb, 2015.
- D. Milićev: Programiranje u realnom vremenu – skripta, Beograd, 2002.
- V. Kovačević, M. Popović: Sistemska programska podrška u realnom vremenu 1, FTN, Novi Sad, 2013.
Riječi ovog poglavlja.
- Životni ciklus sistema – sve faze kroz koje sistem prolazi, od ideje do gašenja.
- Metodologija razvoja – dogovoren način kojim tim redom i u kojim koracima radi posao.
- Vodopad – metodologija u kojoj faze idu jedna za drugom, bez vraćanja.
- V-model – vodopad u kojem svaka faza projektovanja ima svoj par u fazi provjere.
- Iteracija – jedan kratki krug rada na kraju kojeg imamo nešto što se može pokazati.
- Inkrement – komad sistema koji radi i dodaje se prethodnim komadima.
- Agilni razvoj – pristup u kojem se sistem pravi u kratkim iteracijama, uz stalan razgovor s korisnikom.
- Scrum – najpoznatija agilna metodologija: sprintovi, tri uloge i pet događaja.
- Sprint – iteracija u Scrumu, obično od jedne do četiri sedmice.
- Backlog – lista svega što treba napraviti, poredana po važnosti.
- Kanban – metoda u kojoj se posao vidi na tabli s kolonama i ograničava koliko se radi odjednom.
- WIP ograničenje (work in progress) – najveći broj zadataka koji smiju biti „u radu” istovremeno.
- DevOps – način rada u kojem razvoj i održavanje sistema rade kao jedan tim i automatizuju isporuku.
- Kompajler, povezivač, debager – programi koji pretvaraju izvorni kod u izvršni program i pomažu da se pronađe greška.
Ciljevi poglavlja. Nakon poglavlja možete: nabrojati faze životnog ciklusa sistema i za svaku reći šta nastaje; opisati vodopad i V-model i navesti kada su dobar izbor; objasniti razliku između iterativnog i inkrementalnog razvoja; navesti četiri vrijednosti agilnog manifesta; opisati tri uloge, tri artefakta i pet događaja Scruma; izračunati koliko sprintova treba za backlog ako je poznata brzina tima; objasniti Kanban tablu i WIP ograničenje i izračunati prosječno vrijeme zadatka po Littleovom zakonu; reći šta je DevOps; nabrojati sistemske programske alate od editora do debagera; za dati projekat obrazložiti izbor metodologije; napraviti GitHub Projects tablu i plan prvog sprinta za DeliveryApp.
Plan poglavlja – Sedmica 2: tri časa teorije i tri časa praktične nastave
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 2.1–2.3 Faze, vodopad, V-model | Kuća po fazama; svaka faza ima svoj test |
| Teorija 2 | 2.4–2.6 Iterativno, agilni manifest, Scrum | Skejtbord, bicikl, auto; sprint DeliveryApp |
| Teorija 3 | 2.7–2.10 Kanban, DevOps, alati, izbor | Tabla s WIP ograničenjem; Littleov zakon |
| Praksa 1–3 | GitHub Projects: backlog, sprint, Definicija gotovog | Tabla DeliveryApp i plan Sprinta 1 |
Dio 1 – Faze i vodopad
2.1 Faze životnog ciklusa
Svaki informacioni sistem, od male aplikacije do bankarskog sistema, prolazi kroz iste faze. Zovemo ih životni ciklus razvoja sistema (engleski systems development life cycle, SDLC). Faze se mogu raditi jednom, redom, ili mnogo puta u malim krugovima, ali posao u njima je uvijek isti.
| Faza | Pitanje | Šta nastaje (primjer za DeliveryApp) |
|---|---|---|
| 1. Planiranje | Vrijedi li ovo raditi? Koliko će koštati i trajati? | vizija, procjena troška, odluka „krećemo” |
| 2. Analiza | Šta tačno treba? Kako se posao danas radi? | zahtjevi, korisničke priče, model procesa |
| 3. Projektovanje | Kako ćemo to napraviti? | modeli (UML), baza, arhitektura, prototip ekrana |
| 4. Implementacija | Pišemo kod. | program, baza, API |
| 5. Testiranje | Radi li ono što smo tražili? | testovi, izvještaji o greškama |
| 6. Isporuka | Kako ga puštamo u rad? | sistem na serveru, obuka korisnika |
| 7. Održavanje | Kako ga čuvamo živim? | ispravke, nove verzije, nadzor |
Faze lako pamtimo uz gradnju kuće. Planiranje je odluka da gradimo i koliko imamo novca. Analiza je razgovor s porodicom o sobama. Projektovanje je arhitektov nacrt. Implementacija je zidanje. Testiranje je tehnički prijem kuće: da li curi krov, da li radi struja. Isporuka je useljenje. Održavanje je krečenje i popravka bojlera narednih trideset godina.
Posljednja faza najčešće traje najduže i najviše košta. Sistem koji je napravljen za godinu dana može se koristiti i deset godina, a za to vrijeme mijenjaju se zakoni, cijene, uređaji i želje korisnika. Zato se dobar projektant pita i „kako će se ovo mijenjati za pet godina?”, a ne samo „kako ovo napraviti do roka?”.
Ukratko.
- Svaki sistem prolazi kroz planiranje, analizu, projektovanje, implementaciju, testiranje, isporuku i održavanje.
- U svakoj fazi nastaje nešto konkretno: vizija, zahtjevi, modeli, kod, testovi, sistem u radu, nove verzije.
- Održavanje najčešće traje najduže, pa se sistem projektuje i za promjene koje će doći.
2.2 Vodopad
Najstariji i najjednostavniji način da se faze poredaju je vodopad (engleski waterfall). Faze idu jedna za drugom, kao voda niz stepenice: kad se završi analiza, počinje projektovanje, i u analizu se više ne vraća. Na kraju svake faze nastaje dokument koji se odobri i „zamrzne”, i on je ulaz u sljedeću fazu.
Vodopad ima prave prednosti:
- jasno je šta se radi kada i ko je odgovoran;
- lako se planira budžet i rok;
- dokumentacija je potpuna, što je važno kad sistem pregledaju nadležni organi (npr. softver za medicinske uređaje, avione, željeznicu).
Ali ima i ozbiljnu manu: korisnik vidi sistem tek na kraju. Ako je u analizi nešto pogrešno shvaćeno, to se otkrije tek kad je sve programirano, a to je, sjetimo se slike 1.3, najskuplji trenutak za ispravku. Pored toga, svijet se ne zaustavlja dok tim radi: za dvije godine razvoja mogu se promijeniti i zakon i tržište.
U priči o FBI-ju (poglavlje 1) problem je bio upravo u tome što su se zahtjevi mijenjali, a projekat je bio organizovan kao da se neće mijenjati. Vodopad radi dobro samo kad su zahtjevi jasni, stabilni i dobro poznati od početka.
Za radoznale. Winston Royce je 1970. objavio rad o upravljanju razvojem velikih softverskih sistema. Na jednoj slici nacrtao je faze kao stepenice, a odmah ispod napisao da je takav pristup „rizičan i poziva na neuspjeh”, i predložio povratne korake i pravljenje probne verzije. Kasnije su mnogi preuzeli samo sliku, bez upozorenja. Ime „vodopad” nije dao Royce; nastalo je kasnije, zbog oblika slike.
Ukratko.
- U vodopadu faze idu jedna za drugom, a na kraju svake nastaje odobren dokument.
- Prednosti su jasan plan, budžet i potpuna dokumentacija.
- Mana je da korisnik vidi sistem tek na kraju, kad je ispravka najskuplja.
- Vodopad je dobar izbor samo kad su zahtjevi jasni i stabilni od početka.
2.3 V-model: svaka faza ima svoju provjeru
V-model je vodopad nacrtan u obliku slova V, da bi se istaklo nešto što vodopad zanemaruje: svaka faza projektovanja ima svoj par u fazi provjere. Lijeva strana slova V spušta se od opšteg ka detaljnom (zahtjevi, arhitektura, detaljan dizajn, kod). Desna strana se penje od detaljnog ka opštem i provjerava svaku lijevu fazu:
| Lijevo (šta smo odlučili) | Desno (kako provjeravamo) |
|---|---|
| Zahtjevi korisnika | Prihvatno testiranje: korisnik potvrdi da sistem radi ono što mu treba |
| Zahtjevi sistema i arhitektura | Sistemsko testiranje: cijeli sistem zajedno |
| Detaljan dizajn dijelova | Integraciono testiranje: dijelovi zajedno |
| Kod jedne funkcije | Jedinično testiranje: svaka funkcija posebno |
Ključna ideja V-modela je da se test planira u istom trenutku kad se piše ono što test provjerava. Kad zapišemo pravilo PP-4 („od 30,00 € dostava je besplatna”), odmah zapišemo i kako ćemo ga provjeriti: narudžba od tačno 30,00 € mora imati dostavu 0,00 €, a narudžba od 29,99 € mora je platiti. Tako se nejasna pravila otkriju odmah, a ne kad tester dođe na red.
V-model se i danas koristi u industrijama gdje greška može ugroziti život: automobili, avioni, medicinski uređaji. O nivoima testiranja detaljno govori predmet Testiranje softvera, a u ovoj knjizi poglavlje 14.
Ukratko.
- V-model je vodopad u kojem svaka faza projektovanja ima svoj par u fazi provjere.
- Zahtjevi se provjeravaju prihvatnim, arhitektura sistemskim, dizajn integracionim, a kod jediničnim testom.
- Test se planira u istom trenutku kad se piše zahtjev, pa se nejasnoće otkriju rano.
- V-model se koristi tamo gdje greška može ugroziti život.
Provjeri se.
- Koja faza životnog ciklusa obično traje najduže? – Održavanje.
- Kada je vodopad dobar izbor? – Kad su zahtjevi jasni, stabilni i poznati od početka, a potrebna je potpuna dokumentacija.
- Koji test u V-modelu provjerava zahtjeve korisnika? – Prihvatno testiranje.
Dio 2 – Iterativno i agilno
2.4 Iterativni i inkrementalni razvoj
Umjesto da cijeli sistem prođe kroz sve faze jednom, može se raditi u krugovima. U svakom krugu tim malo analizira, malo projektuje, programira, testira i pokaže rezultat korisniku. Taj krug se zove iteracija. Na kraju iteracije postoji inkrement: komad sistema koji stvarno radi i koji se dodaje prethodnim komadima.
Dvije riječi znače različito, pa ih razdvojimo:
- iterativno znači „ponavljamo i doterujemo”: prvu verziju ekrana napravimo grubo, pokažemo, pa je popravljamo;
- inkrementalno znači „dodajemo komad po komad”: prvo samo naručivanje, pa plaćanje karticom, pa praćenje dostavljača.
Dobri timovi rade i jedno i drugo istovremeno.
Najpoznatija slika za ovu razliku je put do automobila. Ako kupac hoće prevozno sredstvo, pogrešan inkrementalni put je napraviti prvo točak, pa šasiju, pa karoseriju: kupac do kraja nema čime da se vozi. Dobar put je napraviti prvo skejtbord, pa romobil, pa bicikl, pa motor, pa automobil. Svaka verzija je mala, ali već vozi, i kupac može reći „zapravo mi treba nešto s krovom” prije nego što je potrošen sav novac.
Za DeliveryApp bi „skejtbord” bio: jedan restoran, jelovnik od tri jela, narudžba bez plaćanja karticom (plaća se dostavljaču), i e-mail restoranu. To je malo, ali neko već može naručiti ručak i reći šta mu smeta.
Ukratko.
- Iteracija je kratak krug analize, projektovanja, programiranja i testiranja s rezultatom koji se pokaže korisniku.
- Iterativno znači doterivati, a inkrementalno dodavati komad po komad.
- Svaki inkrement treba da „vozi”, kao skejtbord prije automobila.
- Najmanji DeliveryApp je jedan restoran, tri jela i narudžba bez kartice.
2.5 Agilni manifest
Manifest iz Snowbirda (2001) kaže da tim više cijeni stvari s lijeve strane, iako i one s desne imaju vrijednost:
| Više cijenimo… | …nego |
|---|---|
| ljude i saradnju | procese i alate |
| softver koji radi | iscrpnu dokumentaciju |
| saradnju s naručiocem | pregovaranje o ugovoru |
| reagovanje na promjenu | slijepo praćenje plana |
Važno je pročitati i sitna slova: manifest ne kaže da dokumentacija, plan i ugovor nisu potrebni. Kaže da su ljudi, softver koji radi, saradnja i promjena važniji. Tim koji ne piše nikakvu dokumentaciju i kaže „mi smo agilni” nije pročitao manifest do kraja.
Iz dvanaest principa manifesta izdvajamo četiri koja ćemo stalno koristiti:
- Najveći prioritet je zadovoljan korisnik, kroz ranu i stalnu isporuku softvera koji ima vrijednost.
- Softver koji radi isporučuje se često, svakih nekoliko sedmica.
- Ljudi iz posla (npr. vlasnici restorana) i programeri rade zajedno, svakodnevno.
- U redovnim razmacima tim razmisli kako da radi bolje i to promijeni.
Česta zabluda. „Agilno znači bez planiranja.” Agilni timovi planiraju češće, a ne manje: na početku svakog sprinta, svaki dan na kratkom sastanku i na kraju sprinta. Razlika je u tome što plan za dvije sedmice smije biti detaljan, a plan za godinu dana ostaje grub i mijenja se.
Ukratko.
- Agilni manifest napisan je 2001. u Snowbirdu i ima četiri vrijednosti i dvanaest principa.
- Ljudi, softver koji radi, saradnja i promjena važniji su od procesa, dokumentacije, ugovora i plana, ali ih ne ukidaju.
- Softver se isporučuje često, a tim redovno razmišlja kako da radi bolje.
2.6 Scrum
Scrum je najrašireniji agilni okvir. Ime je pozajmljeno iz ragbija, gdje „scrum” znači zbijenu grupu igrača koji zajedno guraju loptu naprijed. Scrum je namjerno jednostavan i ima tri grupe pojmova: uloge, artefakte (stvari koje tim pravi i čuva) i događaje.
Tri uloge
| Uloga | Šta radi | U DeliveryApp |
|---|---|---|
| Vlasnik proizvoda (product owner) | odlučuje šta je najvažnije; slaže backlog | predstavnik udruženja ugostitelja |
| Scrum master | pomaže timu da radi po Scrumu i uklanja prepreke | jedan član tima, npr. iskusniji programer |
| Razvojni tim (developers) | pravi inkrement: analitičari, programeri, testeri | tri do devet ljudi |
Scrum master nije šef. On je više kao trener: ne igra umjesto tima, nego pazi da tim može igrati.
Tri artefakta
- Backlog proizvoda (product backlog) – lista svega što bi DeliveryApp mogao imati, poredana po važnosti. Na vrhu su sitne, jasne stavke, na dnu krupne i nejasne.
- Backlog sprinta (sprint backlog) – stavke koje je tim izabrao za ovaj sprint, s planom kako ih napraviti.
- Inkrement – ono što na kraju sprinta radi i ispunjava Definiciju gotovog.
Definicija gotovog (Definition of Done) je lista uslova koje svaka stavka mora ispuniti da bi se smjela nazvati gotovom. Za DeliveryApp bi mogla glasiti: kod je u Gitu, prošao je recenziju kolege, svi testovi prolaze, kriteriji prihvatanja su provjereni, dokumentacija je dopunjena. Bez ovakve liste svako „gotovo” znači nešto drugo.
Pet događaja
| Događaj | Kada i koliko | Pitanje |
|---|---|---|
| Sprint | jedna do četiri sedmice; DeliveryApp ima dvije | (okvir za sve ostale) |
| Planiranje sprinta | na početku, do oko četiri sata za dvije sedmice | Šta pravimo u ovom sprintu i kako? |
| Dnevni sastanak (daily scrum) | svaki dan, 15 minuta, uvijek u isto vrijeme | Šta smo uradili, šta danas, šta nas koči? |
| Pregled sprinta (sprint review) | na kraju, s vlasnikom proizvoda i korisnicima | Šta smo napravili? Šta sada ima smisla? |
| Retrospektiva | poslije pregleda | Kako da sljedeći sprint radimo bolje? |
Brzina tima i plan izdanja
Timovi često procjenjuju veličinu stavki u bodovima (story points): to nisu sati, nego relativna težina („ova stavka je otprilike duplo veća od one”). Zbir bodova završenih u jednom sprintu zove se brzina tima (velocity).
Primjer: tim DeliveryApp je u prva tri sprinta završio 18, 22 i 20 bodova. Prosječna brzina je
\[ \bar v = \frac{18 + 22 + 20}{3} = \frac{60}{3} = 20 \text{ bodova po sprintu}. \]
Čemu služi. Ako je u backlogu još 120 bodova, potrebno je otprilike 120 / 20 = 6 sprintova, a to je kod sprintova od dvije sedmice oko 12 sedmica. Ovo je procjena, ne obećanje: backlog se mijenja, a brzina varira. Ali je mnogo bolja od „biće gotovo kad bude gotovo”.
Na času. Ako tim od četiri člana kaže da je u sprintu završio „skoro sve” od 25 bodova, a dvije stavke od po 4 boda nisu prošle testove, kolika je brzina tog sprinta? (Odgovor: 25 − 8 = 17 bodova; stavka koja ne ispunjava Definiciju gotovog ne broji se.)
Ukratko.
- Scrum ima tri uloge: vlasnika proizvoda, scrum mastera i razvojni tim.
- Artefakti su backlog proizvoda, backlog sprinta i inkrement koji ispunjava Definiciju gotovog.
- Pet događaja su sprint, planiranje, dnevni sastanak, pregled i retrospektiva.
- Brzina tima je zbir završenih bodova po sprintu; kod brzine 20 i backloga od 120 bodova treba oko šest sprintova.
Provjeri se.
- Koja je razlika između iterativnog i inkrementalnog razvoja? – Iterativno znači doterivati isti dio, a inkrementalno dodavati nove dijelove.
- Da li agilni manifest ukida dokumentaciju? – Ne; kaže da je softver koji radi važniji, ali dokumentacija i dalje ima vrijednost.
- Šta je Definicija gotovog? – Lista uslova koje svaka stavka mora ispuniti da bi se smjela nazvati gotovom.
Dio 3 – Kanban, DevOps i alati
2.7 Kanban
Kanban (japanski: „kartica”, „tabla”) potiče iz fabrike automobila Toyota u Japanu, iz sredine dvadesetog vijeka. Tamo je kartica putovala s dijelovima i govorila kada treba proizvesti nove, tako da se ne gomilaju zalihe. U softveru Kanban znači tablu s kolonama na kojoj svaki zadatak ima svoju karticu, a kartice putuju s lijeva na desno.
Tipična tabla DeliveryApp ima pet kolona: Backlog, Spremno, U radu, Pregled, Gotovo. Svako odmah vidi gdje je koji posao i gdje se posao gomila.
Najvažnija ideja Kanbana nije tabla, nego ograničenje posla u toku (WIP ograničenje, od engleskog work in progress). Ako kolona „U radu” smije imati najviše tri kartice, niko ne smije početi četvrti zadatak dok se jedan ne završi. To zvuči kao kočnica, a zapravo ubrzava: ljudi završavaju započeto umjesto da istovremeno žongliraju s deset poluzavršenih stvari.
Slika iz života: kasa u prodavnici. Ako jedna blagajnica istovremeno počne naplaćivati pet kupaca (kod jednog skenira mlijeko, kod drugog hljeb…), niko ne izlazi iz prodavnice. Ako naplati jednog po jednog, svaki kupac čeka kraće.
Littleov zakon
Postoji jednostavna veza između broja zadataka u radu, brzine kojom se završavaju i vremena koje jedan zadatak provede na tabli. Zove se Littleov zakon, po matematičaru Johnu Littleu:
\[ W = \frac{L}{\lambda} \]
Čemu služi. W je prosječno vrijeme koje jedan zadatak provede u sistemu (od „Spremno” do „Gotovo”). L je prosječan broj zadataka koji su istovremeno u radu. λ (čita se „lambda”) je propusnost, prosječan broj zadataka koje tim završi u jedinici vremena. Primjer: ako je na tabli DeliveryApp stalno oko 6 kartica u radu, a tim dnevno završi 3 kartice, jedna kartica u prosjeku putuje W = 6 / 3 = 2 dana. Ako tim smanji WIP na 3, a završava i dalje 3 dnevno, prosječno vrijeme pada na 1 dan. Ista ekipa, isti posao, a kupac dobija ispravku duplo brže.
Kanban nema sprintove ni propisane uloge. Zato je dobar za timove kojima posao stiže neravnomjerno: podrška korisnicima, održavanje, ispravke grešaka. Mnogi timovi kombinuju Scrum i Kanban: rade u sprintovima, a sprint prate na Kanban tabli.
Ukratko.
- Kanban potiče iz Toyote; posao se vidi kao kartice koje putuju kroz kolone table.
- WIP ograničenje kaže koliko zadataka smije biti u radu odjednom i tako ubrzava završavanje.
- Littleov zakon W = L / λ: sa 6 zadataka u radu i 3 završena dnevno, zadatak traje 2 dana.
- Kanban nema sprintove i dobar je za podršku i održavanje.
2.8 DevOps: razvoj i rad kao jedan tim
U starijim firmama postojala su dva odvojena tima. Razvoj (development) je pisao novi kod i želio ga što prije pustiti. Održavanje rada (operations) brinulo je o serverima i željelo da se ništa ne mijenja, jer svaka promjena može nešto pokvariti. Između njih je stajao „zid” preko kojeg se kod bacao jednom u nekoliko mjeseci, uz mnogo stresa.
DevOps (od development i operations) je način rada u kojem ta dva tima rade zajedno i automatizuju sve što se ponavlja:
- svaka izmjena koda automatski se prevede i testira (kontinuirana integracija, continuous integration, CI);
- ako testovi prođu, izmjena se automatski pripremi ili pusti u rad (kontinuirana isporuka, continuous delivery/deployment, CD);
- sistem u radu se stalno nadzire, a tim brzo vidi kad nešto ne valja.
Umjesto jedne velike, strašne isporuke svaka tri mjeseca, DevOps timovi isporučuju male izmjene često, nekad i više puta dnevno. Mala izmjena se lakše provjeri, a ako nešto pođe naopako, lakše se vrati. DevOps detaljno radimo u poglavlju 14, gdje ćemo vidjeti i šta se desi kad automatska isporuka nije dovoljno pažljivo projektovana.
Ukratko.
- DevOps spaja razvoj i održavanje rada u jedan tim.
- Kontinuirana integracija automatski prevodi i testira svaku izmjenu, a kontinuirana isporuka je pušta u rad.
- Česte male izmjene sigurnije su od rijetkih velikih.
2.9 Alati kroz životni ciklus
Kroz faze životnog ciklusa tim koristi mnogo alata. Neki pomažu da se razmišlja i dogovara, a neki pretvaraju naš tekst u program koji računar izvršava. Ove druge zovemo sistemski programski alati i vrijedi znati šta svaki radi, jer projektant odlučuje i o njima (posebno kod sistema u realnom vremenu, poglavlje 13).
| Alat | Šta radi | Slika iz života |
|---|---|---|
| Editor / IDE (integrisano razvojno okruženje, npr. VS Code) | mjesto gdje se piše kod, uz pomoć, pretragu i pokretanje | radni sto s alatom na dohvat ruke |
| Asembler | prevodi asemblerski jezik (instrukcije procesora riječima, npr. ADD) u mašinski kod (brojeve) |
rječnik riječ-za-riječ |
| Makroasembler | asembler koji dozvoljava da se ponovljeni niz instrukcija nazove jednim imenom (makro) | skraćenica „itd.” umjesto nabrajanja |
| Kompajler (prevodilac) | prevodi cijeli program iz višeg jezika (C, Java) u mašinski ili međukod | prevodilac koji prevede cijelu knjigu |
| Optimizujući kompajler | prevodi tako da program bude brži ili manji | prevodilac koji uz to skrati rečenice |
| Interpreter | izvršava program red po red, bez prethodnog prevođenja cijelog programa (npr. Python) | simultani prevodilac na konferenciji |
| Povezivač (linker) | spaja više prevedenih dijelova i biblioteka u jedan izvršni program | knjigovezac koji poveže poglavlja u knjigu |
| Punjač (loader) | učita program u memoriju i pokrene ga | bibliotekar koji knjigu stavi na sto |
| Debager (debugger) | zaustavlja program na izabranom mjestu i pokazuje vrijednosti varijabli | usporeni snimak utakmice |
| Simulator / emulator | glumi uređaj ili procesor koji nemamo na stolu | simulator leta za pilota |
| Sistem za verzije (Git) | pamti svaku verziju koda i dokumenata | dnevnik izmjena |
| CI server (npr. GitHub Actions) | automatski pokreće prevođenje i testove pri svakoj izmjeni | kontrolor kvaliteta na traci |
U DeliveryApp pišemo u Pythonu, koji se izvršava interpreterom, pa kompajler i povezivač ne vidimo direktno. Ali aplikacija za mobitel, baza i operativni sistem servera prevedeni su upravo ovim alatima. U sistemima koji upravljaju uređajima (poglavlje 13), program se često piše u C-u, prevodi kompajlerom za mali procesor, isproba u simulatoru i tek onda učita u uređaj.
Ukratko.
- IDE je mjesto rada, a asembler, kompajler i interpreter prevode ili izvršavaju kod.
- Povezivač spaja dijelove u jedan program, a punjač ga učitava u memoriju.
- Debager zaustavlja program i pokazuje varijable, a simulator glumi uređaj koji nemamo.
- Git i CI server prate i automatski provjeravaju svaku izmjenu.
2.10 Kako izabrati metodologiju
Ne postoji jedna metodologija koja je najbolja za sve. Izbor zavisi od toga koliko su zahtjevi poznati i stabilni, koliko je greška opasna i kako posao stiže.
| Situacija | Dobar izbor | Zašto |
|---|---|---|
| Zahtjevi poznati i stabilni, propisi traže dokumentaciju (npr. softver pejsmejkera) | vodopad ili V-model | svaka faza se dokumentuje i provjerava |
| Novi proizvod, korisnici još ne znaju tačno šta žele (npr. DeliveryApp) | Scrum | česti inkrementi otkrivaju prave želje |
| Posao stiže neravnomjerno, mnogo malih zahtjeva (podrška, održavanje) | Kanban | nema čekanja na kraj sprinta |
| Sistem se mijenja svaki dan i mora stalno raditi (web servis) | Scrum ili Kanban uz DevOps | automatizacija čini česte izmjene sigurnim |
Za DeliveryApp biramo Scrum sa sprintovima od dvije sedmice i Kanban tablu na GitHubu. Razlog: vlasnici restorana i kupci tek treba da vide prvu verziju da bi rekli šta im zaista treba. Kad sistem bude u radu i pređe u održavanje, tim može preći na čisti Kanban.
Na času. Za svaki projekat predložite metodologiju i jednom rečenicom obrazložite: a) softver za upravljanje semaforima u gradu; b) web stranica studentske organizacije; c) ispravke grešaka u aplikaciji banke koja već radi.
Ukratko.
- Nijedna metodologija nije najbolja za sve projekte.
- Vodopad i V-model odgovaraju stabilnim zahtjevima i strogim propisima, Scrum novim proizvodima, a Kanban neravnomjernom poslu.
- Za DeliveryApp biramo Scrum sa sprintovima od dvije sedmice i Kanban tablu.
Provjeri se.
- Šta je WIP ograničenje? – Najveći broj zadataka koji smiju istovremeno biti u radu.
- Šta radi povezivač? – Spaja prevedene dijelove programa i biblioteke u jedan izvršni program.
- Zašto DeliveryApp radi po Scrumu? – Jer je proizvod nov i korisnici tek kroz česte inkremente vide šta im zaista treba.
Praktična nastava – tabla i prvi sprint DeliveryApp
Cilj je da tim (ili svaki student sam, u ulozi cijelog tima) napravi tablu zadataka za DeliveryApp na GitHubu, popuni backlog i isplanira Sprint 1. Radi se u repozitoriju deliveryapp-projekat iz poglavlja 1.
Korak 1 – Stavke backloga kao GitHub Issues
- U repozitoriju otvorite karticu Issues i kliknite New issue.
- Napravite bar 12 stavki iz vizije. Naslov je kratak i počinje glagolom, a opis kaže zašto stavka postoji. Primjeri:
- „Prikazati jelovnik jednog restorana”
- „Dodati jelo u korpu i vidjeti zbir”
- „Izračunati dostavu po pravilima PP-2 do PP-4”
- „Primijeniti kod STUDENT10 (PP-5)”
- „Restoran prihvata ili odbija narudžbu”
- „Kupac otkazuje narudžbu (PP-6)”
- „Plaćanje karticom”
- „Praćenje dostavljača na mapi”
- „Mjesečni izvještaj za restoran”
- Svakoj stavci dodajte oznaku (label) veličine:
S(mala),M(srednja),L(velika). Na sljedećem času oznake ćemo zamijeniti bodovima.
Korak 2 – Tabla u GitHub Projects
- Kartica Projects → New project → Board. Nazovite je „DeliveryApp”.
- Napravite kolone: Backlog, Spremno, U radu, Pregled, Gotovo.
- U postavkama kolone U radu upišite ograničenje (limit) 3. GitHub će upozoriti kad ga pređete.
- Dodajte sve stavke na tablu, u kolonu Backlog, i poredajte ih po važnosti prevlačenjem: na vrh ide ono bez čega DeliveryApp ne može (jelovnik, korpa, dostava), na dno „lijepo je imati” (mapa, izvještaj).
Korak 3 – Plan Sprinta 1
- Napišite cilj sprinta u jednoj rečenici, npr. „Kupac može naručiti iz jednog restorana i vidjeti tačnu cijenu s dostavom.”
- Iz vrha backloga izaberite stavke koje služe tom cilju i prebacite ih u Spremno. Za sprint od dvije sedmice izaberite tri do pet stavki.
- U
README.mddodajte odjeljak Definicija gotovog s najmanje četiri uslova (kod u Gitu, prošao recenziju, testovi prolaze, kriteriji prihvatanja provjereni). - Napravite fajl
sprint-1.mdpo šablonu:
# Sprint 1
- Trajanje: 2 sedmice
- Cilj: (jedna rečenica)
## Stavke
| Issue | Naslov | Veličina |
| --- | --- | --- |
| #1 | Prikazati jelovnik jednog restorana | S |
## Rizici
(Šta bi nas moglo zakočiti?)Korak 4 – Simulacija dnevnog sastanka i retrospektive
U grupama od četiri studenta odigrajte dnevni sastanak od tačno 15 minuta: svako kaže šta je „juče” uradio, šta će „danas” i šta ga koči. Jedan član je scrum master i pazi na vrijeme. Zatim odigrajte kratku retrospektivu: svako na papirić napiše jednu stvar koja je išla dobro i jednu koju bi promijenio. Zaključak retrospektive (jedna promjena za sljedeći put) upišite na kraj sprint-1.md.
Korak 5 – AI kao pomoćnik u backlogu (opcionalno)
Dajte AI asistentu viziju DeliveryApp i zatražite prijedlog dodatnih stavki backloga. Za svaku predloženu stavku odlučite: ide u backlog, ide u „nije u prvoj verziji”, ili se odbacuje, i zapišite zašto. Provjerite da AI nije izmislio pravilo koje vlasnici nisu tražili (npr. „dostava besplatna nedjeljom”).
Rezultat koji se predaje: link na GitHub Projects tablu s najmanje 12 stavki i WIP ograničenjem 3, te fajl sprint-1.md s ciljem, stavkama, rizicima i zaključkom retrospektive.
Vježbe
Vježba za studenta 1 – faze.
Za svaku stvar recite u kojoj fazi životnog ciklusa nastaje: a) dijagram stanja narudžbe; b) odluka udruženja da uloži u aplikaciju; c) ispravka greške u obračunu dostave šest mjeseci nakon početka rada; d) intervju s konobarom o tome kako danas prima narudžbe; e) obuka osoblja restorana.
Rješenje. a) projektovanje; b) planiranje; c) održavanje; d) analiza; e) isporuka.
Vježba za studenta 2 – V-model.
Za zahtjev „Za artikle od 30,00 € i više dostava je besplatna” napišite dva testa koji bi se u V-modelu planirali odmah, s očekivanim rezultatom. Na kojem su nivou?
Rješenje. Test 1: artikli tačno 30,00 €, udaljenost 5 km → dostava 0,00 €. Test 2: artikli 29,99 €, udaljenost 5 km → dostava 3,00 € (preko 3 km su 2 km: 2,00 + 2 × 0,50). Oba provjeravaju zahtjev korisnika, pa su na nivou prihvatnog testa; isti slučajevi mogu postati i jedinični testovi funkcije za dostavu.
Vježba za studenta 3 – brzina tima.
Tim je u četiri sprinta završio 15, 21, 18 i 22 boda. U backlogu je ostalo 95 bodova. Koliko sprintova od dvije sedmice treba, otprilike?
Rješenje. Prosjek (15 + 21 + 18 + 22) / 4 = 76 / 4 = 19 bodova. 95 / 19 = 5 sprintova, dakle oko 10 sedmica.
Vježba za studenta 4 – Littleov zakon.
Na tabli podrške DeliveryApp u prosjeku je 8 kartica u radu, a tim sedmično završi 16 kartica. Koliko u prosjeku traje jedna kartica? Šta bi se desilo ako bi se WIP smanjio na 4, uz istu propusnost?
Rješenje. W = L / λ = 8 / 16 = 0,5 sedmice, odnosno oko 2,5 radna dana (sedmica od 5 radnih dana). Sa WIP 4: W = 4 / 16 = 0,25 sedmice, oko 1,25 radnih dana, duplo brže.
Vježba za studenta 5 – izbor metodologije.
Opština naručuje softver za izdavanje građevinskih dozvola. Zakon tačno propisuje korake i rokove, a aplikacija mora proći reviziju nadležnog ministarstva. Koju metodologiju biste predložili i zašto? Šta biste ipak pozajmili iz agilnog pristupa?
Rješenje. Pošto su koraci propisani zakonom (stabilni zahtjevi) i potrebna je potpuna dokumentacija za reviziju, razuman izbor je V-model. Iz agilnog pristupa vrijedi pozajmiti rane prototipe ekrana koje službenici isprobaju, i redovne preglede s naručiocem, da se nejasnoće u tumačenju zakona otkriju prije programiranja.
Sažetak u pet rečenica
- Svaki sistem prolazi kroz planiranje, analizu, projektovanje, implementaciju, testiranje, isporuku i održavanje, a održavanje obično traje najduže.
- Vodopad radi faze jednom i redom, a V-model svakoj fazi projektovanja daje par u fazi provjere; oba su dobra kad su zahtjevi stabilni i propisi strogi.
- Agilni razvoj, opisan u manifestu iz Snowbirda 2001, pravi sistem u kratkim iteracijama s inkrementima koji rade i stalnim razgovorom s korisnikom.
- Scrum ima tri uloge, tri artefakta i pet događaja, a brzina tima pomaže da se procijeni koliko je sprintova potrebno za backlog.
- Kanban s WIP ograničenjem i DevOps s automatizovanom isporukom ubrzavaju završavanje posla, a sistemski programski alati od editora do debagera prate kod kroz cijeli ciklus.