Softver kao proizvod

Šta učimo ovog semestra (1–5)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas: poglavlje 1 (označeno). Isti primjer kroz knjigu: DeliveryApp 2.0.

Šta učimo ovog semestra (6–10)

Deset predavanja: dva časa teorije i jedan čas dopunske prakse. Danas je poglavlje 1. Isti primjer kroz knjigu: DeliveryApp 2.0.

Priča za početak

Priča za početak

Literatura

1. I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlje 1).
2. R. S. Pressman, B. R. Maxim: Software Engineering: A Practitioner's Approach, 9th ed., McGraw-Hill, 2019 (poglavlja 1–2).
3. S. Malkov: Razvoj softvera, Matematički fakultet, Beograd, 2024.

Zašto ovo poglavlje

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.

Riječi ovog poglavlja (1/2)

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

Riječi ovog poglavlja (2/2)

• 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

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.

1.1 Projekat ili proizvod?

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.

1.1 Projekat ili proizvod?

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 – 1.1 Projekat ili proizvod?

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

1. 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).
2. 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.
3. 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).
4. 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.
5. 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.

1.2 Šta tržište danas traži od softvera

Ukratko – 1.2 Šta tržište danas traži od softvera

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

1.3 Profesionalni razvoj softvera i etika

1.3 Profesionalni razvoj softvera i etika

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

1.3 Profesionalni razvoj softvera i etika

Ukratko – 1.3 Profesionalni razvoj softvera i etika

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

1.4 Upoznajemo DeliveryApp 2.0

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.

1.4 Upoznajemo DeliveryApp 2.0

DeliveryApp se tiče mnogih ljudi. To su zainteresovane strane:

1.4 Upoznajemo DeliveryApp 2.0

1.4 Upoznajemo DeliveryApp 2.0

Ukratko – 1.4 Upoznajemo DeliveryApp 2.0

• 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

1. Po čemu se proizvod razlikuje od projekta? Proizvod traje dok ima korisnika i nastaje kroz niz projekata, a projekat ima početak i kraj.
2. Koji je prvi princip etičkog kodeksa ACM/IEEE? Rad u interesu javnosti.
3. 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.

Odgovori: tipka R ili klik na zamućeno polje.

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:

1.5 Zašto je razvoj softvera inženjerstvo

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.

Ukratko – 1.5 Zašto je razvoj softvera inženjerstvo

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

1.6 Alati i okoline kao podrška razvoju

1.6 Alati i okoline kao podrška razvoju

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.

Ukratko – 1.6 Alati i okoline kao podrška razvoju

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

1. Mašinski kod i asembler (1940-ih i 1950-ih) – programer piše instrukcije procesora.
2. Viši programski jezici i prevodioci (FORTRAN 1957, kasnije C, Java, Python, C#) – programer piše ukupno = artikli + dostava, a prevodilac pravi instrukcije.
3. Okviri i biblioteke – ne piše se svaki put prijava korisnika ili rad s bazom; uzme se gotovo (poglavlje 4).
4. Generatori koda – iz modela ili opisa nastaje kod (npr. iz OpenAPI opisa nastaje klijent za API).
5. Automatizacija gradnje, testova i isporuke – svaka izmjena se sama prevede, testira i isporuči (poglavlje 5).
6. Low-code i no-code – aplikacija se sklapa mišem od gotovih blokova; pogodno za interne obrasce i jednostavne tokove.
7. AI asistenti – na osnovu opisa riječima predlažu kod, testove, objašnjenja i ispravke. Šira upotreba počinje oko 2021. godine.

1.7 Automatizirani razvoj: od prevodioca do AI asistenta

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:

1. Pročita kod i provjeri da li razumije svaku liniju. Kod koji ne razumije, ne smije predati.
2. Pokrene testove s poznatim primjerima: N-1001 u Gradu B mora dati dostavu 3,80 €, a adresa na 2 km tačno 2,00 €.
3. Provjeri granice: šta za 8 km (najdalje u Gradu B), šta za 8,1 km?
4. Ne lijepi tajne: u razgovor s asistentom ne ide lozinka baze, ključ sistema plaćanja ni podaci stvarnih kupaca.

1.7 Automatizirani razvoj: od prevodioca do AI asistenta

Ukratko – 1.7 Automatizirani razvoj: od prevodioca do AI asistenta

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

1. 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.
2. Provjeri automatski. Za svako pravilo, jedan test. Test je „pamćenje” tima koje ne zaboravlja.
3. Pitaj „šta ako ih bude deset puta više?” Deset puta više korisnika, programera, gradova. Proizvod raste, i dizajn mora rasti s njim.

Ukratko – 1.8 Kako se uči ovaj zanat

• 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

1. Š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.
2. Kad treba nešto automatizovati? Kad se radi više od dva puta ručno.
3. Š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.

Odgovori: tipka R ili klik na zamućeno polje.

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

1. Na GitHubu napravite novi repozitorij deliveryapp-2 (javni ili privatni), s fajlovima README.md i .gitignore za Python.
2. 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: Ena

Korak 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 žalbe

Korak 4 – Prvi commit

git add .
git commit -m "Dodaj README i viziju proizvoda"
git push

Korak 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žba za studenta 1 – projekat ili proizvod.

Vježba za studenta 1 – projekat ili proizvod. – rješenje

Vježba za studenta 2 – cijena u tri grada.

Vježba za studenta 2 – cijena u tri grada. – rješenje

Vježba za studenta 3 – etika.

Vježba za studenta 3 – etika. – rješenje

Vježba za studenta 4 – provjera AI prijedloga.

def dostava_grad_b(km):
    if km <= 2:
        return 200
    return 200 + int(km - 2) * 60

Vježba za studenta 4 – provjera AI prijedloga. – rješenje

Sažetak u pet rečenica

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Pitanja za ponavljanje

1. Šta se desilo u Garmischu 1968. i šta znači izraz „softverska kriza”?
2. Navedite tri razlike između projekta i proizvoda.
3. Zašto najveći dio troška proizvoda dolazi poslije prve isporuke?
4. Nabrojte pet trendova koji danas oblikuju razvoj softvera.
5. Šta razlikuje profesionalni softver od programa koji je neko napisao za sebe?
6. Koliko principa ima etički kodeks ACM/IEEE i koji je prvi? Navedite još dva.
7. Šta je tamni obrazac? Navedite primjer.
8. Šta je novo u DeliveryApp 2.0 u odnosu na verziju 1.4.2?
9. Koje navike inženjera gradnje prenosimo u razvoj softvera? Po čemu se softver razlikuje od mosta?
10. Nabrojte alate razvojne okoline DeliveryApp i za svaki recite čemu služi.
11. Opišite stepenice automatizacije razvoja.
12. Kako se provjerava kod koji je predložio AI asistent?