Poglavlje 1: Softver kao proizvod
Priča za početak. U oktobru 1968. godine, od 7. do 11. oktobra, u gradiću Garmisch u bavarskim Alpama okupilo se pedesetak najboljih stručnjaka za računare iz Evrope i Amerike. Skup je organizovao naučni komitet NATO-a, a naslov mu je bio neobičan: „Softversko inženjerstvo” (Software Engineering). Organizatori su priznali da su naslov izabrali namjerno provokativno. Tada niko nije pravio softver kao što se prave mostovi: s proračunom, standardima i provjerom. Programi su kasnili godinama, koštali višestruko više od plana i puni grešaka stizali do korisnika. Učesnici su za to stanje skovali izraz koji se i danas koristi: softverska kriza. Izvještaj sa skupa, koji su uredili Peter Naur i Brian Randell, počinje mišlju da softver mora postati inženjerska disciplina, sa svojim teorijama i praksom, kao i druge grane inženjerstva. Ovaj predmet je, na neki način, pedeset godina kasnije napisan odgovor na pitanja iz Garmischa.
Ovo je prvo poglavlje, pa se ne nastavlja ni na šta, osim na ono što već znate: kako se piše program. Ovdje učimo zašto napisati program i napraviti proizvod nisu ista stvar. Prvi dio objašnjava razliku između projekta i proizvoda, šta tržište danas traži od softvera i šta znači biti profesionalac u ovom poslu. Upoznajemo i DeliveryApp 2.0, proizvod koji ćemo razvijati kroz cijelu knjigu. Drugi dio govori o inženjerskom pristupu: zašto je razvoj softvera inženjerstvo, s kojim alatima se radi i koliko je posla danas automatizovano, uključujući i AI asistente.
Literatura. Osnovna literatura predmeta:
- I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlje 1).
- R. S. Pressman, B. R. Maxim: Software Engineering: A Practitioner’s Approach, 9th ed., McGraw-Hill, 2019 (poglavlja 1–2).
- S. Malkov: Razvoj softvera, Matematički fakultet, Beograd, 2024.
Riječi ovog poglavlja.
- Programski proizvod – softver koji se nudi mnogim korisnicima, razvija i održava godinama i ima svoje tržište.
- Projekat – privremen poduhvat s početkom, krajem, budžetom i ciljem.
- Softversko (programsko) inženjerstvo – disciplina koja softver razvija sistematski, mjerljivo i s provjerom, kao što druga inženjerstva grade mostove i mašine.
- Softverska kriza – izraz iz 1968. za stanje u kojem softver stalno kasni, prekoračuje budžet i ima previše grešaka.
- Zainteresovana strana (stakeholder) – svako koga se proizvod tiče: kupac, korisnik, vlasnik, regulator, tim.
- Vlasnik proizvoda (product owner) – osoba koja odlučuje šta proizvod treba da radi i šta je najvažnije.
- Etički kodeks – zapisana pravila ponašanja struke; za softver to je kodeks ACM-a i IEEE-a iz 1999.
- Razvojna okolina – skup alata s kojima tim radi: editor, prevodilac, Git, testovi, isporuka.
- IDE (integrated development environment) – program koji objedinjuje editor, pokretanje, otklanjanje grešaka i testove.
- Automatizirani razvoj – sve što umjesto čovjeka radi alat: gradnja, testovi, isporuka, generisanje koda.
- Low-code – alati u kojima se aplikacija sklapa uglavnom mišem, s malo ručno pisanog koda.
- AI asistent za programiranje – alat zasnovan na jezičkom modelu koji predlaže kod, testove i objašnjenja.
Ciljevi poglavlja. Nakon poglavlja možete: objasniti razliku između projekta i proizvoda; nabrojati pet trendova koji danas oblikuju razvoj softvera; navesti osam principa etičkog kodeksa softverskih inženjera; objasniti šta inženjerski pristup dodaje „samom programiranju”; nabrojati alate razvojne okoline i reći čemu koji služi; opisati stepenice automatizacije razvoja, od prevodioca do AI asistenta, i kako se rezultat AI asistenta provjerava; opisati DeliveryApp 2.0 i njegove zainteresovane strane.
Plan poglavlja – Predavanje 1: dva časa teorije i jedan čas dopunske prakse
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 1.1–1.4 Projekat i proizvod, trendovi, etika, DeliveryApp 2.0 | Šta je proizvod, a šta projekat? Zainteresovane strane DeliveryApp |
| Teorija 2 | 1.5–1.8 Inženjerski pristup, alati, automatizacija, kako se uči | Most i aplikacija; stepenice automatizacije |
| Dopunska praksa | Repozitorij deliveryapp-2, README i vizija proizvoda |
Prvi commit proizvoda |
Dio 1 – Od programa do proizvoda
1.1 Projekat ili proizvod?
Zamislite da vas komšija zamoli da mu napravite program koji sabira račune njegove radnje. Napišete ga za jedan vikend, pokažete mu kako radi, on je zadovoljan i to je kraj priče. To je bio projekat: imao je početak, kraj, jednog naručioca i jasan cilj.
Sada zamislite da se za vaš program pročuje i da ga za godinu dana koristi trista radnji u pet gradova. Svaka radnja ima svoje želje. Jedna hoće izvještaj za porez, druga radi na starom računaru, treća ima dvadeset kasa. Program se mora mijenjati svake sedmice, a da pri tome ni jedna radnja ne ostane bez rada ni sat vremena. Vi ste ga napisali sami, a sada vam treba pet ljudi. To više nije projekat, nego proizvod.
| Projekat | Proizvod | |
|---|---|---|
| Trajanje | ima kraj | traje dok ima korisnika (godinama) |
| Naručilac | jedan, poznat | mnogo korisnika, često nepoznatih |
| Cilj | isporučiti dogovoreno | stvarati vrijednost i prihod iz godine u godinu |
| Zahtjevi | dogovoreni na početku | stalno se mijenjaju, tržište ih diktira |
| Uspjeh se mjeri | rok, budžet, obim | korisnici, prihod, zadovoljstvo, brzina promjena |
| Najveći trošak | izrada | održavanje i razvoj novih verzija |
Proizvod nastaje kroz mnogo projekata: verzija 1.0 je projekat, verzija 2.0 je novi projekat, a između njih stalno teče održavanje. Zato se za proizvod koristi slika životnog ciklusa proizvoda: ideja, prva verzija, rast, zrelost i na kraju povlačenje.
Česta zabluda. „Kad je softver isporučen, posao je gotov.” Za proizvod je isporuka tek početak. Većina ukupnog troška softvera koji se koristi godinama nastaje poslije prve isporuke: ispravke, prilagođavanje novim uređajima i zakonima, nove funkcije. O brojevima govori poglavlje 10.
Za ovaj predmet važno je zapamtiti: kad pravimo proizvod, svaka odluka se mjeri i pitanjem „kako će ovo izgledati za tri godine i sa deset puta više korisnika?”.
Ukratko.
- Projekat je privremen poduhvat s početkom i krajem, a proizvod traje dok ima korisnika.
- Proizvod nastaje kroz niz projekata (verzija), a između njih stalno teče održavanje.
- Uspjeh proizvoda mjeri se korisnicima, prihodom i brzinom promjena, a ne samo rokom i budžetom.
- Najveći dio troška proizvoda dolazi poslije prve isporuke.
1.2 Šta tržište danas traži od softvera
Softver iz 1968. radio je na jednom velikom računaru u jednoj zgradi. Danas proizvod radi u oblaku, na mobitelu, u automobilu i na satu, a korisnik ga poredi s najboljim aplikacijama koje svakodnevno koristi. Pet trendova najviše oblikuje zahtjeve koje proizvod mora ispuniti:
- Oblak i softver kao usluga. Korisnik ništa ne instalira i ne plaća licencu jednom zauvijek, nego koristi uslugu preko interneta i plaća mjesečno. Proizvođač zato mora održavati sistem koji radi 24 sata dnevno (poglavlje 9).
- Mobilnost i mnogo uređaja. Isti proizvod mora raditi na telefonu, tabletu i računaru, na različitim veličinama ekrana i sporim mrežama.
- Brzina isporuke. Korisnici očekuju ispravke za dane, a ne za mjesece. Najbolji timovi isporučuju izmjene više puta dnevno, zahvaljujući automatizaciji (poglavlje 5).
- Sigurnost i privatnost. Proizvod je stalno izložen napadima, a zakoni (npr. evropski GDPR) traže zaštitu ličnih podataka. Sigurnost više nije dodatak, nego dio svakog koraka.
- Vještačka inteligencija. AI ulazi i u proizvod (preporuke, razgovor s korisnikom) i u način rada tima (AI asistenti pišu kod i testove). O tome više u 1.7.
Ovim trendovima treba dodati i zahtjeve koji su uvijek tu, ali danas su stroži: proizvod mora biti upotrebljiv bez uputstva, pristupačan osobama s invaliditetom, brz i dostupan stalno. Te zahtjeve zovemo nefunkcionalni i njima je posvećeno poglavlje 6.
Na času. Uzmite aplikaciju za dostavu hrane koju poznajete. Za svaki od pet trendova nađite jedan znak u aplikaciji: šta je u njoj „oblak”, šta „mobilnost”, šta „brzina isporuke” (kada ste zadnji put dobili ažuriranje?), šta „sigurnost” i šta „AI”.
Ukratko.
- Danas softver radi kao usluga u oblaku, na mnogo uređaja, i mijenja se često.
- Sigurnost i privatnost dio su svakog koraka razvoja, a ne dodatak na kraju.
- AI je i dio proizvoda i alat tima.
- Upotrebljivost, pristupačnost, brzina i dostupnost su zahtjevi koje korisnik podrazumijeva.
1.3 Profesionalni razvoj softvera i etika
Programirati može svako ko je naučio jezik. Profesionalni programer se razlikuje po tome što piše softver koji koriste drugi ljudi, koji će mijenjati drugi programeri, i za koji neko odgovara. Sommerville to kaže jednom rečenicom: profesionalni softver nije samo program, nego i dokumentacija, podaci za podešavanje i sve što treba da bi program radio i mogao se mijenjati.
Profesionalac zato pazi na stvari koje početnika ne zanimaju: da li će kolega razumjeti kod za šest mjeseci, da li postoji test koji će uhvatiti grešku kad neko promijeni pravilo, da li je lozinka korisnika sigurno sačuvana, da li je posao procijenjen pošteno.
Softver danas upravlja avionima, bolnicama, bankama i izborima. Zato struka ima i svoj etički kodeks. Udruženja ACM i IEEE usvojila su 1999. godine Etički kodeks i pravila profesionalne prakse softverskog inženjerstva. Kodeks ima osam principa:
| Princip | Šta znači, prostim riječima |
|---|---|
| Javnost | radi u interesu javnosti; ne isporučuj softver za koji znaš da je opasan |
| Klijent i poslodavac | radi u interesu klijenta, ali ne protiv javnosti |
| Proizvod | proizvod neka bude što kvalitetniji, provjeren i testiran |
| Prosudba | sačuvaj nezavisnost i poštenje profesionalne procjene |
| Upravljanje | rukovodioci neka vode posao etički, s poštenim procjenama |
| Profesija | čuvaj ugled struke |
| Kolege | budi pošten i pomažući prema kolegama |
| Lično | uči cijeli život i ponašaj se etično |
Etika nije apstraktna. Programer u DeliveryApp može dobiti zahtjev da „sakrije” dio cijene dostave dok kupac ne potvrdi narudžbu, jer to „povećava prodaju”. To je tamni obrazac (dark pattern): dizajn koji korisnika navodi na odluku koju ne bi donio da je sve vidio. Profesionalac kaže zašto je to loše i predlaže pošten način (poglavlje 3).
Iz stvarnog svijeta. U skandalu „Dieselgate” iz 2015. godine pokazalo se da je softver u milionima Volkswagenovih dizel automobila prepoznavao kad je vozilo na testu emisije i tada smanjivao ispušne gasove, a na cesti ne. Firma je platila desetine milijardi dolara kazni i odšteta, a pojedini inženjeri i rukovodioci krivično su gonjeni. Kod je radio „tačno ono što je traženo”, i baš zato je pitanje odgovornosti postalo pitanje za cijelu struku.
Ukratko.
- Profesionalni softver uključuje i dokumentaciju, podešavanja i sve što treba da bi se mogao mijenjati.
- Profesionalac misli na druge korisnike, druge programere i odgovornost.
- Etički kodeks ACM/IEEE iz 1999. ima osam principa; prvi je interes javnosti.
- Tamni obrasci su primjer zahtjeva koje profesionalac ne prihvata bez pitanja.
1.4 Upoznajemo DeliveryApp 2.0
Kroz cijelu knjigu razvijamo jedan izmišljeni proizvod. DeliveryApp je aplikacija za naručivanje hrane iz tri restorana malog grada (R-1 Picerija, R-2 Roštilj, R-3 Salatarnica). Kupac bira jela, plaća karticom, a dostavljač donosi hranu. Godinu dana radi u Gradu A, sada u verziji 1.4.2.
DeliveryApp je uspio, i udruženje ugostitelja ima novu ideju: ponuditi ga drugim gradovima kao uslugu uz mjesečnu pretplatu. Tako DeliveryApp prestaje biti projekat jednog grada i postaje proizvod. Cilj verzije 2.0:
- dva nova grada, Grad B i Grad C, svaki sa svojim cijenama dostave;
- nova funkcija „Ponovi narudžbu” (jednim dodirom ponoviti prošlu narudžbu);
- nova funkcija „Praćenje dostavljača uživo” (tačka na mapi koja se pomjera);
- sistem mora izdržati ručak u tri grada istovremeno.
| Grad | Dostava do uključenih km | Uključeno | Po započetom km preko toga | Najdalje |
|---|---|---|---|---|
| Grad A | 2,00 € | 3 km | 0,50 € | 10 km |
| Grad B | 2,00 € | 2 km | 0,60 € | 8 km |
| Grad C | 2,50 € | 3 km | 0,50 € | 12 km |
Ista narudžba N-1001 (artikli 21,50 €, adresa 4,2 km od restorana) u tri grada košta različito. U Gradu A dostava je 2,00 + 2 × 0,50 = 3,00 €, ukupno 24,50 €. U Gradu B preko 2 km ostaje 2,2 km, to su tri započeta kilometra: 2,00 + 3 × 0,60 = 3,80 €, ukupno 25,30 €. U Gradu C dostava je 2,50 + 2 × 0,50 = 3,50 €, ukupno 25,00 €. Već sada vidimo prvi zadatak za dizajn: pravilo dostave više ne smije biti „zakucano” u kodu, nego mora biti podešavanje po gradu (poglavlja 3, 8 i 9).
Proizvod pravi tim od šest ljudi: Lana je vlasnica proizvoda, Amar je scrum master i programer, Sara, Dino i Emir su programeri, a Ena radi dizajn sučelja i testiranje. Kako se takav tim organizuje, govori poglavlje 2.
DeliveryApp se tiče mnogih ljudi. To su zainteresovane strane:
| Zainteresovana strana | Šta želi od DeliveryApp 2.0 |
|---|---|
| Kupac | brzo naručiti, tačna cijena, hrana stiže topla |
| Restoran | više narudžbi, jednostavan ekran, mala provizija |
| Dostavljač | jasna adresa, kratka ruta, isplata na vrijeme |
| Udruženje (vlasnik) | proizvod koji se isplati i širi u nove gradove |
| Grad (opština) | red u dostavi, poštovanje propisa |
| Tim | jasni prioriteti, kod koji se lako mijenja |
| Regulator | zaštita ličnih podataka, fiskalni računi |
Na času. Koja dva zahtjeva iz gornje tabele se mogu sukobiti? (Primjer: restoran želi malu proviziju, a vlasnik želi proizvod koji se isplati.) Ko odlučuje kad se zahtjevi sukobe?
Ukratko.
- DeliveryApp je aplikacija za naručivanje hrane koja godinu dana radi u Gradu A.
- Verzija 2.0 širi ga na Grad B i Grad C, uz funkcije „Ponovi narudžbu” i „Praćenje dostavljača uživo”.
- Ista narudžba N-1001 košta 24,50 € u Gradu A, 25,30 € u Gradu B i 25,00 € u Gradu C.
- Proizvod ima mnogo zainteresovanih strana čiji se zahtjevi mogu sukobiti; o prioritetima odlučuje vlasnica proizvoda.
Provjeri se.
- Po čemu se proizvod razlikuje od projekta? – Proizvod traje dok ima korisnika i nastaje kroz niz projekata, a projekat ima početak i kraj.
- Koji je prvi princip etičkog kodeksa ACM/IEEE? – Rad u interesu javnosti.
- Koliko košta N-1001 u Gradu B i zašto? – 25,30 €: 21,50 € artikli + 2,00 € + 3 započeta km × 0,60 € = 3,80 € dostave.
Dio 2 – Inženjerski pristup
1.5 Zašto je razvoj softvera inženjerstvo
Kad inženjer gradi most, ne počinje tako što na rijeku nabaca grede pa gleda da li drži. Prvo izmjeri rijeku i opterećenje, izračuna nosivost, koristi standarde (propisane materijale i postupke), napravi plan, a na kraju most ispita opterećenjem prije nego što ga otvori. Kad se most sruši, istraga utvrdi uzrok i propisi se promijene, da se greška ne ponovi.
Inženjerski pristup razvoju softvera prenosi iste navike:
| Navika inženjera | U razvoju softvera |
|---|---|
| mjeri prije nego što gradi | zahtjevi i nefunkcionalni zahtjevi zapisani mjerljivo (poglavlje 6) |
| crta plan | modeli i dizajn prije koda (poglavlje 3) |
| koristi standarde i provjerene elemente | obrasci dizajna, okviri, komponente (poglavlja 4, 7, 8) |
| ispituje prije otvaranja | automatizirani testovi i kontinuirana integracija (poglavlje 5) |
| procjenjuje trošak | procjena napora i isplativosti (poglavlje 10) |
| uči iz nesreća | analiza incidenata bez traženja krivca, poboljšanje procesa (poglavlje 2) |
Ali softver nije most, i zato se ne može sve prepisati od građevinara. Softver se ne troši (ne hrđa), ali stari, jer se svijet oko njega mijenja. Softver je nevidljiv, pa je teško vidjeti koliko je „sagrađeno”. Softver se lako mijenja, i upravo zato ga svi stalno mijenjaju, često bez plana. Most se gradi jednom, a softver se gradi stalno.
Česta zabluda. „Inženjerski pristup znači mnogo papira.” Ne znači. Inženjerski pristup znači da se rezultat provjerava i da se zna zašto je nešto urađeno. Jedan dobar automatski test vrijedi više od deset stranica dokumenta koji niko ne čita. Kad vidite riječ „inženjerski”, mislite „mjerljivo i provjerljivo”, a ne „birokratski”.
Ukratko.
- Inženjerski pristup znači mjeriti, planirati, koristiti standarde, ispitivati i učiti iz grešaka.
- Softver se ne troši, ali stari; nevidljiv je i lako se mijenja.
- Inženjerski ne znači birokratski, nego mjerljivo i provjerljivo.
1.6 Alati i okoline kao podrška razvoju
Stolar ima radionicu: stol, testere, stege, mjernu traku. Programerski tim ima razvojnu okolinu: skup alata koji prate kod od prve linije do korisnika. Za DeliveryApp 2.0 okolina izgleda ovako:
| Posao | Alat (primjeri) | Šta radi za tim |
|---|---|---|
| pisanje i čitanje koda | VS Code, Visual Studio, JetBrains Rider ili PyCharm | editor, dopunjavanje, otklanjanje grešaka |
| pamćenje verzija | Git, GitHub | ko je šta promijenio i kada; povratak na staru verziju |
| zadaci i plan | GitHub Projects, Jira | backlog, sprint, tabla |
| dijagrami | Mermaid, draw.io, Figma | modeli i prototipi |
| provjera | pytest (Python), xUnit (C#), ruff, SonarQube | testovi i statička analiza |
| gradnja i isporuka | GitHub Actions, Docker | automatska provjera i pakovanje svake izmjene |
| rad u produkciji | logovi, nadzor, upozorenja | vidimo šta se dešava kod korisnika |
| komunikacija | Slack, Teams, e-pošta | razgovor i dogovori |
Alati sami ne čine dobar tim, ali loši alati sigurno usporavaju dobar tim. Pravilo je jednostavno: sve što se radi više od dva puta ručno, treba prepustiti alatu. Ručno pokretanje testova prije svakog spajanja koda zaboraviće se; automatsko neće.
Za radoznale. Riječ „IDE” znači integrisano razvojno okruženje. Prvi IDE-ovi pojavili su se sedamdesetih i osamdesetih godina (npr. Turbo Pascal iz 1983. imao je editor i prevodilac u jednom programu koji je stajao na jednoj disketi). Današnji VS Code nije pravi IDE dok mu se ne dodaju ekstenzije; zato ga mnogi zovu „editor koji može postati IDE”.
Ukratko.
- Razvojna okolina je skup alata koji prate kod od prve linije do korisnika.
- Za svaki posao (pisanje, verzije, plan, dijagrami, provjera, isporuka, nadzor) postoji alat.
- Ono što se radi više od dva puta ručno, treba automatizovati.
1.7 Automatizirani razvoj: od prevodioca do AI asistenta
Istorija razvoja softvera može se ispričati kao niz stepenica. Na svakoj stepenici programer manje radi „ručno” i više opisuje šta hoće, a alat odlučuje kako.
- Mašinski kod i asembler (1940-ih i 1950-ih) – programer piše instrukcije procesora.
- Viši programski jezici i prevodioci (FORTRAN 1957, kasnije C, Java, Python, C#) – programer piše
ukupno = artikli + dostava, a prevodilac pravi instrukcije. - Okviri i biblioteke – ne piše se svaki put prijava korisnika ili rad s bazom; uzme se gotovo (poglavlje 4).
- Generatori koda – iz modela ili opisa nastaje kod (npr. iz OpenAPI opisa nastaje klijent za API).
- Automatizacija gradnje, testova i isporuke – svaka izmjena se sama prevede, testira i isporuči (poglavlje 5).
- Low-code i no-code – aplikacija se sklapa mišem od gotovih blokova; pogodno za interne obrasce i jednostavne tokove.
- AI asistenti – na osnovu opisa riječima predlažu kod, testove, objašnjenja i ispravke. Šira upotreba počinje oko 2021. godine.
Svaka stepenica je izazvala strah da „programeri više neće trebati”. Desilo se suprotno: što je pravljenje softvera lakše, to ga se više pravi, i to za teže probleme. Ono što se mijenja je gdje programer troši vrijeme: manje na kucanje, više na razumijevanje problema, dizajn, provjeru i odgovornost.
Kako tim DeliveryApp koristi AI asistenta. Sara treba funkciju koja računa dostavu za Grad B. Asistentu opiše pravilo i dobije kod za nekoliko sekundi. Ali posao tek tada počinje:
- Pročita kod i provjeri da li razumije svaku liniju. Kod koji ne razumije, ne smije predati.
- Pokrene testove s poznatim primjerima: N-1001 u Gradu B mora dati dostavu 3,80 €, a adresa na 2 km tačno 2,00 €.
- Provjeri granice: šta za 8 km (najdalje u Gradu B), šta za 8,1 km?
- Ne lijepi tajne: u razgovor s asistentom ne ide lozinka baze, ključ sistema plaćanja ni podaci stvarnih kupaca.
Česta zabluda. „AI je napisao kod, znači da je tačan.” AI asistent predlaže kod koji izgleda uvjerljivo, ali može izmisliti funkciju koja ne postoji ili pogrešno razumjeti pravilo (npr. računati „pune” kilometre umjesto „započetih”). Odgovornost za kod je uvijek na čovjeku koji ga je predao.
Ukratko.
- Automatizacija razvoja ide stepenicama: prevodilac, okviri, generatori, automatska isporuka, low-code, AI asistenti.
- Na svakoj stepenici programer više opisuje šta želi, a manje kako se to radi.
- AI asistent ubrzava pisanje, ali kod se uvijek čita, testira i provjerava na granicama.
- Tajne i lični podaci ne idu u razgovor s AI asistentom.
1.8 Kako se uči ovaj zanat
Razvoj proizvoda se ne uči napamet. Uči se kao vožnja bicikla: malo teorije, mnogo vježbe, i na kraju navike koje rade same. Zato ova knjiga ima stalni primjer (DeliveryApp 2.0) i dopunsku praksu na kraju svakog poglavlja.
Tri navike vrijedi početi graditi od prvog dana:
- Zapiši prije nego što napraviš. Jedna rečenica cilja („Kupac može ponoviti prošlu narudžbu jednim dodirom”) uštedi sate pogrešnog rada.
- Provjeri automatski. Za svako pravilo, jedan test. Test je „pamćenje” tima koje ne zaboravlja.
- Pitaj „šta ako ih bude deset puta više?” Deset puta više korisnika, programera, gradova. Proizvod raste, i dizajn mora rasti s njim.
Na času. Koja od tri navike vam je najteža i zašto? Napišite jednu rečenicu cilja za aplikaciju koju koristite svaki dan.
Ukratko.
- Razvoj proizvoda se uči vježbom na stalnom primjeru.
- Tri navike: zapiši prije nego što napraviš, provjeri automatski, pitaj šta ako ih bude deset puta više.
Provjeri se.
- Šta inženjer radi s mostom prije nego što ga otvori, i šta je to u softveru? – Ispituje ga opterećenjem; u softveru su to automatizirani testovi i kontinuirana integracija.
- Kad treba nešto automatizovati? – Kad se radi više od dva puta ručno.
- Šta Sara mora uraditi s kodom koji je predložio AI asistent? – Pročitati ga, pokrenuti testove s poznatim primjerima, provjeriti granice i ne lijepiti tajne u razgovor.
Dopunska praksa – repozitorij i vizija proizvoda
Cilj je napraviti „kuću” proizvoda DeliveryApp 2.0: repozitorij na GitHubu s README-om i dokumentom vizije. Trajanje: jedan čas.
Korak 1 – Repozitorij
- Na GitHubu napravite novi repozitorij
deliveryapp-2(javni ili privatni), s fajlovimaREADME.mdi.gitignoreza Python. - Klonirajte ga na računar i otvorite folder u VS Codeu:
git clone https://github.com/<vaše-ime>/deliveryapp-2.git
cd deliveryapp-2
code .Korak 2 – README
U README.md napišite četiri kratka odjeljka:
# DeliveryApp 2.0
Aplikacija za naručivanje hrane za više gradova, kao usluga uz mjesečnu pretplatu.
## Za koga
Kupci, restorani i dostavljači u gradovima A, B i C.
## Kako pokrenuti
(dopunićemo u poglavlju 4)
## Tim
Vlasnica proizvoda: Lana · Scrum master: Amar · Programeri: Sara, Dino, Emir · Dizajn i testiranje: EnaKorak 3 – Vizija proizvoda
Napravite fajl docs/vizija.md po šablonu za viziju proizvoda (jedna rečenica koja se čita naglas):
# Vizija DeliveryApp 2.0
Za **stanovnike malih gradova** koji žele **brzo naručiti hranu iz lokalnih restorana**,
**DeliveryApp 2.0** je **aplikacija za naručivanje i dostavu**
koja **u tri dodira daje tačnu cijenu i prati dostavljača uživo**.
Za razliku od **naručivanja telefonom**, naš proizvod **nikad ne gubi narudžbu i radi isto u svakom gradu**.
## Zainteresovane strane
(tabela iz odjeljka 1.4)
## Mjere uspjeha
- 3 grada do kraja godine
- 95 % narudžbi bez žalbeKorak 4 – Prvi commit
git add .
git commit -m "Dodaj README i viziju proizvoda"
git pushKorak 5 – AI kao sagovornik (opcionalno)
Dajte AI asistentu viziju i tražite tri pitanja koja bi postavio skeptični investitor. Za svako pitanje u vizija.md dopišite jednu rečenicu odgovora. Provjerite da asistent nije „dodao” funkcije koje niko nije tražio.
Rezultat: link na repozitorij s README.md i docs/vizija.md i bar jednim commitom.
Vježbe
Vježba za studenta 1 – projekat ili proizvod.
Za svaki primjer recite da li je projekat ili proizvod i zašto: a) web stranica za jednu konferenciju 2027. godine; b) aplikacija za mobilno bankarstvo; c) prelazak baze jedne firme sa starog servera u oblak; d) igra koja dobija novi nivo svakog mjeseca.
Rješenje. a) projekat: ima jasan kraj (konferencija prođe); b) proizvod: traje godinama, mnogo korisnika, stalne nove verzije; c) projekat: privremen posao s ciljem i rokom (iako je dio života nekog proizvoda); d) proizvod: stalno se razvija za mnogo igrača.
Vježba za studenta 2 – cijena u tri grada.
Narudžba ima artikle od 12,00 € i adresu 6,5 km od restorana. Koliko je ukupno u Gradu A, B i C?
Rješenje. Grad A: preko 3 km je 3,5 km, započeta su 4 km: 2,00 + 4 × 0,50 = 4,00 €; ukupno 16,00 €. Grad B: preko 2 km je 4,5 km, započeto 5 km: 2,00 + 5 × 0,60 = 5,00 €; ukupno 17,00 €. Grad C: preko 3 km je 3,5 km, 4 km: 2,50 + 4 × 0,50 = 4,50 €; ukupno 16,50 €.
Vježba za studenta 3 – etika.
Lana traži da se u DeliveryApp dugme „Otkaži pretplatu” za restorane sakrije u peti nivo podešavanja, „da manje restorana otkazuje”. Koji princip etičkog kodeksa je u pitanju i šta predlažete?
Rješenje. U pitanju su principi „javnost” i „proizvod” (pošten odnos prema korisniku), a sakrivanje dugmeta je tamni obrazac. Prijedlog: dugme ostaje vidljivo, a prije otkazivanja kratko pitanje „Zašto odlazite?” s ponudom pomoći. Tako proizvod dobija informaciju, a korisnik nije prevaren.
Vježba za studenta 4 – provjera AI prijedloga.
AI asistent je za Grad B predložio ovaj kod. Nađite grešku pomoću primjera N-1001.
def dostava_grad_b(km):
if km <= 2:
return 200
return 200 + int(km - 2) * 60Rješenje. Za 4,2 km kod daje int(2.2) = 2, pa 200 + 120 = 320 centi (3,20 €), a tačno je 3,80 € jer su započeta tri kilometra. int odsijeca decimale, a pravilo traži zaokruživanje naviše (math.ceil). Kod uz to ne provjerava granicu od 8 km.
Sažetak u pet rečenica
- Na konferenciji u Garmischu 1968. godine nastao je naziv „softversko inženjerstvo” kao odgovor na softversku krizu: softver je kasnio, koštao previše i imao previše grešaka.
- Projekat ima početak i kraj, a proizvod traje dok ima korisnika, nastaje kroz niz verzija i najveći dio troška ima poslije prve isporuke.
- Danas proizvod oblikuju oblak, mobilnost, brzina isporuke, sigurnost i vještačka inteligencija, a profesionalac radi po etičkom kodeksu čiji je prvi princip interes javnosti.
- Inženjerski pristup znači mjeriti, planirati, koristiti standarde, ispitivati i učiti iz grešaka, uz pomoć razvojne okoline u kojoj se sve što se ponavlja automatizuje.
- DeliveryApp 2.0 je naš proizvod za tri grada, koji pravi tim od šest ljudi, a AI asistent u tom timu predlaže kod koji čovjek uvijek čita, testira i provjerava.