Poglavlje 6: Nefunkcionalni zahtjevi
Priča za početak. U julu 2016. firma Niantic pustila je igru Pokémon GO: igrači hodaju po stvarnom gradu i na ekranu mobitela hvataju čudovišta. Igra je prvo puštena u Australiji i Novom Zelandu, i u roku od petnaest minuta promet je prešao sve procjene. Niantic je planirao kapacitet za najgori slučaj od pet puta više igrača nego što je procijenio. Stvarni promet bio je oko pedeset puta veći od procjene. Igra je, funkcionalno, radila savršeno: čudovišta su se pojavljivala, lopte letjele, bodovi se brojali. Ali igrači satima nisu mogli ni ući u nju, jer su serveri bili zagušeni. Inženjeri Niantica i Googlea, čiji je oblak igra koristila, danima su dodavali kapacitet i mijenjali dijelove sistema, i tek tada je igra mogla biti puštena u Japanu i Evropi. Lekcija je stara koliko i softver, ali Pokémon GO ju je ispričao milionima ljudi: igra koja ne može da se otvori ne radi, bez obzira na to koliko su dobro napisana pravila.
U poglavlju 5 naučili smo kako izmjena brzo i bez straha stiže do korisnika. Ali korisnik ne ocjenjuje samo šta proizvod radi, nego i kako: da li je brz, da li je stalno dostupan, da li čuva podatke, da li ga je lako koristiti. To su nefunkcionalni zahtjevi. Prvi dio govori šta su, kako se klasifikuju i kako se zapisuju tako da se mogu izmjeriti. Drugi dio govori kako se implementiraju: keš, skaliranje, redovi poruka, otpornost na kvarove, i kako se DeliveryApp 2.0 redizajnira da izdrži ručak u tri grada.
Literatura. Osnovna literatura predmeta:
- I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlje 4 i dio o pouzdanosti).
- L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, 4th ed., Addison-Wesley, 2021 (scenariji i taktike kvaliteta).
- ISO/IEC 25010: Systems and software Quality Requirements and Evaluation (SQuaRE) – Product quality model.
Riječi ovog poglavlja.
- Nefunkcionalni zahtjev (NFR) – zahtjev koji opisuje kako sistem radi (brzina, dostupnost, sigurnost…), a ne šta radi.
- ISO/IEC 25010 – međunarodni standard koji dijeli kvalitet softverskog proizvoda u karakteristike.
- Scenarij kvaliteta – mjerljiv opis NFR-a: šta se desi, u kojim uslovima, i kako sistem mora odgovoriti.
- Vrijeme odziva – vrijeme od zahtjeva do odgovora.
- Percentil p95 – vrijednost ispod koje je 95 % mjerenja.
- Dostupnost – procenat vremena u kojem sistem radi; „devetke”: 99 %, 99,9 %…
- Keš – brza memorija za podatke koji se često čitaju, da se ne traže svaki put iz spore baze.
- Skaliranje – povećanje kapaciteta: vertikalno (jača mašina) ili horizontalno (više mašina).
- Red poruka – „poštansko sanduče” između dijelova sistema, da posao ne čeka da drugi završi.
- Taktika – provjeren način da se postigne neki kvalitet (npr. keš za performanse).
- Prekidač kola (circuit breaker) – zaštita koja prestaje zvati servis koji ne radi, dok se ne oporavi.
- Test opterećenja – provjera kako se sistem ponaša pod velikim brojem istovremenih korisnika.
Ciljevi poglavlja. Nakon poglavlja možete: objasniti razliku između funkcionalnih i nefunkcionalnih zahtjeva i zašto NFR mogu „oboriti” funkcionalnost; nabrojati karakteristike kvaliteta po ISO/IEC 25010; klasifikovati NFR prema tome gdje se implementiraju; zapisati NFR kao mjerljiv scenarij; izračunati dozvoljeni zastoj iz procenta dostupnosti; objasniti taktike za performanse, skalabilnost, dostupnost i otpornost; izmjeriti efekat keša; predložiti redizajn proizvoda za novi NFR.
Plan poglavlja – Predavanje 6: dva časa teorije i jedan čas dopunske prakse
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 6.1–6.4 Šta su NFR, ISO 25010, klasifikacija, mjerljivi scenariji | Prepiši „brzo” u scenarij; tabela devetki |
| Teorija 2 | 6.5–6.8 Performanse, dostupnost, ostali kvaliteti, redizajn | Od 200 do 600 korisnika: šta mijenjamo? |
| Dopunska praksa | Mjerenje odziva s kešom i bez keša | 10 s naspram 0,05 s |
Dio 1 – Šta su i kako se zapisuju
6.1 Šta su nefunkcionalni zahtjevi i zašto su važni
Funkcionalni zahtjev kaže šta sistem radi: „Kupac može ponoviti prošlu narudžbu.” Nefunkcionalni zahtjev kaže kako to radi: „Ponovljena narudžba se prikaže za najviše 2 sekunde, i u vrijeme ručka.”
Analogija s automobilom: funkcionalno, automobil vozi, koči i skreće. Nefunkcionalno, troši 5 litara na sto kilometara, ima pet zvjezdica za sigurnost, pali se i na −20 °C i servisira se svakih 15.000 km. Automobil koji vozi, ali ne pali po hladnoći, za vlasnika na sjeveru jednostavno ne radi.
Zato kažemo da NFR mogu oboriti funkcionalnost. Pokémon GO je imao sve funkcije, ali bez skalabilnosti igrači nisu mogli ništa. DeliveryApp s tačnim obračunom dostave, ali sa stranicom koja se učitava deset sekundi u podne, gubi kupce koji odu telefonom naručiti direktno od restorana.
NFR su teži od funkcionalnih zahtjeva iz tri razloga:
- Često se ne kažu. Kupac ne kaže „hoću da bude brzo”, nego to podrazumijeva.
- Pogađaju cijeli sistem. Funkcija „Ponovi narudžbu” je u jednom dijelu koda; brzina zavisi od baze, mreže, servera, keša i koda zajedno.
- Skupo se dodaju naknadno. Dostupnost od 99,9 % traži arhitekturu s više servera. Ako je sistem napravljen za jedan server, „dodati dostupnost” znači prepraviti pola sistema.
Ukratko.
- Funkcionalni zahtjev kaže šta sistem radi, a nefunkcionalni kako to radi.
- NFR mogu oboriti funkcionalnost: sistem koji se ne može otvoriti ne radi.
- NFR se često ne izgovore, pogađaju cijeli sistem i skupo se dodaju naknadno.
6.2 Klasifikacija po ISO/IEC 25010
Da bi se o kvalitetu razgovaralo istim riječima, međunarodni standard ISO/IEC 25010 dijeli kvalitet softverskog proizvoda u karakteristike. Izdanje iz 2011. ima osam karakteristika; revizija iz 2023. dodala je sigurnost u smislu bezbjednosti (safety, da softver ne ugrozi ljude i okolinu) i preimenovala dvije postojeće.
| Karakteristika | Pitanje | NFR DeliveryApp |
|---|---|---|
| Funkcionalna prikladnost | radi li tačno ono što treba? | dostava tačna na cent |
| Efikasnost performansi | koliko brzo i s koliko resursa? | NZ-1a: 95 % odgovora ≤ 2 s pri 600 korisnika |
| Kompatibilnost | radi li s drugim sistemima? | sistem plaćanja, servis mapa |
| Upotrebljivost (2023: sposobnost interakcije) | lako se koristi? pristupačno? | NZ-4: prva narudžba ≤ 3 min; kontrast ≥ 4,5 : 1 |
| Pouzdanost | radi li stalno, oporavlja li se? | NZ-2: dostupnost 99,5 % |
| Sigurnost (zaštita) | jesu li podaci zaštićeni? | NZ-3: heš lozinke, 2FA za restoran |
| Održivost | lako se mijenja i testira? | NZ-7: novi grad za 1 dan, bez novog koda |
| Prenosivost (2023: fleksibilnost) | radi li u drugom okruženju? | kontejner radi kod bilo kojeg pružaoca oblaka |
| Bezbjednost (safety, od 2023) | može li ugroziti ljude? | dostavljač ne dobija poruke dok vozi |
Za radoznale. Standard ISO/IEC 25010 je dio porodice SQuaRE (Systems and software Quality Requirements and Evaluation). Uz model kvaliteta proizvoda ima i model kvaliteta u upotrebi: koliko je korisnik efikasan, zadovoljan i bezbjedan kad koristi proizvod u stvarnom životu.
Ukratko.
- ISO/IEC 25010 dijeli kvalitet proizvoda u karakteristike: funkcionalna prikladnost, performanse, kompatibilnost, upotrebljivost, pouzdanost, sigurnost, održivost, prenosivost, a od 2023. i bezbjednost.
- Standard daje zajednički rječnik za razgovor o kvalitetu.
- Svaki NFR DeliveryApp pripada jednoj karakteristici.
6.3 Klasifikacija prema implementaciji
Programeru je važno i drugo pitanje: gdje se NFR implementira? Odgovor određuje ko ga radi i koliko košta.
| Vrsta | Gdje se implementira | Primjeri u DeliveryApp 2.0 |
|---|---|---|
| Arhitekturalni | u strukturi sistema; teško se mijenja kasnije | skalabilnost (više servera), dostupnost (redundancija), izolacija gradova (NZ-6) |
| Lokalni (u kodu) | u jednoj komponenti ili funkciji | heš lozinke (NZ-3), provjera unosa, kontrast boja (NZ-4) |
| Procesni | u načinu rada tima | održivost: CI, testovi, pregled koda; brzina isporuke |
| Operativni | u radu sistema u produkciji | nadzor, logovi, rezervne kopije, brisanje starih podataka (NZ-5) |
| Ograničenja | nametnuti spolja, ne biraju se | zakon o zaštiti ličnih podataka, fiskalizacija, obavezni jezik |
Sommerville predlaže i podjelu po porijeklu: proizvodni NFR (ponašanje proizvoda: brzina, pouzdanost), organizacioni (pravila firme: jezik, alati, proces) i vanjski (zakoni, etika, regulatori).
Praktična posljedica: arhitekturalni NFR moraju biti poznati rano, prije nego što se arhitektura izabere (poglavlje 7). Lokalni se mogu dodati u bilo kojem sprintu. Zato Lana i Amar prvo pitaju za broj korisnika i dostupnost, a tek poslije za boju dugmeta.
Ukratko.
- Prema implementaciji NFR su arhitekturalni, lokalni, procesni, operativni i ograničenja.
- Po porijeklu su proizvodni, organizacioni i vanjski.
- Arhitekturalni NFR moraju biti poznati rano, jer se kasnije teško mijenjaju.
6.4 Mjerljivi NFR: scenariji kvaliteta
„Sistem mora biti brz” nije zahtjev, nego želja: niko ne može provjeriti da li je ispunjena. NFR mora biti mjerljiv. Bass, Clements i Kazman predlažu scenarij kvaliteta sa šest dijelova:
| Dio | Pitanje | Primjer: ručak u tri grada |
|---|---|---|
| izvor | ko ili šta izaziva događaj? | kupci u gradovima A, B i C |
| podsticaj | šta se desi? | 600 istovremenih korisnika pregleda jelovnike i naručuje |
| okruženje | u kojim uslovima? | normalan rad, radni dan 12–14 h |
| artefakt | koji dio sistema? | cijeli DeliveryApp 2.0 |
| odgovor | šta sistem radi? | prikaže jelovnik i primi narudžbu |
| mjera | kako mjerimo? | 95 % odgovora za najviše 2 s (p95 ≤ 2 s) |
Zašto p95, a ne prosjek? Prosjek sakriva loše slučajeve. Ako 90 zahtjeva traje 0,5 s, a 10 zahtjeva 15 s, prosjek je 1,95 s, „ispod 2 sekunde”, ali svaki deseti kupac čeka petnaest sekundi i odlazi. Percentil p95 kaže: 95 % zahtjeva je brže od ove vrijednosti.
Devetke dostupnosti. Dostupnost se piše u procentima, a lakše se razumije kao dozvoljeni zastoj. Za mjesec od 30 dana (720 sati):
| Dostupnost | Zastoj mjesečno | Šta to znači |
|---|---|---|
| 99 % | 7,2 sata | jedan radni dan |
| 99,5 % (NZ-2) | 3,6 sati | jedno popodne |
| 99,9 % | 43,2 minute | jedna pauza za kafu |
| 99,99 % | oko 4,3 minute | jedna pjesma |
Svaka nova devetka obično znači više servera, više automatizacije i više novca. Zato se pita: koliko košta sat zastoja DeliveryApp u podne? Ako je odgovor „mnogo manje nego treći server”, 99,5 % je pravi izbor.
Na času. Prepišite kao mjerljiv scenarij: „Aplikacija treba biti sigurna” i „Lako se dodaje novi grad”.
Ukratko.
- NFR mora biti mjerljiv; scenarij kvaliteta ima izvor, podsticaj, okruženje, artefakt, odgovor i mjeru.
- Za vrijeme odziva koristi se percentil (p95), jer prosjek sakriva loše slučajeve.
- Dostupnost se prevodi u dozvoljeni zastoj: 99,5 % je 3,6 sati mjesečno.
Provjeri se.
- Da li je „lozinke se čuvaju kao heš” funkcionalni ili nefunkcionalni zahtjev? – Nefunkcionalni (sigurnost), lokalni u kodu.
- Koliko zastoja mjesečno dozvoljava 99,9 %? – 43,2 minute u 30 dana.
- Zašto p95, a ne prosjek? – Prosjek sakriva spore zahtjeve; p95 kaže koliko čeka 95 % korisnika.
Dio 2 – Kako se implementiraju
6.5 Performanse i skalabilnost
Performanse govore koliko je sistem brz za jednog korisnika; skalabilnost govori da li ostaje brz kad korisnika bude deset puta više. Za DeliveryApp 2.0 važno je oboje: verzija 1.x zadovoljava NZ-1 (200 korisnika), a 2.0 mora izdržati 600.
Taktike za performanse i skalabilnost:
- Keš. Jelovnik restorana mijenja se možda jednom sedmično, a čita hiljadu puta dnevno. Umjesto da se svaki put čita iz baze, prvi put se pročita i čuva u brzoj memoriji. Analogija: konobar zna napamet današnju ponudu, ne ide u kuhinju za svako pitanje. Opasnost keša: zastarjeli podaci. Ako restoran promijeni cijenu, keš se mora poništiti.
- Vertikalno skaliranje – jača mašina (više procesora i memorije). Jednostavno, ali ima granicu i jednu tačku kvara.
- Horizontalno skaliranje – više istih mašina iza raspoređivača opterećenja (load balancer), koji svaki zahtjev šalje slobodnoj mašini. Analogija: više otvorenih kasa u prodavnici umjesto jedne brže kasirke. Uslov je da servisi ne pamte ništa „kod sebe” (stateless), nego u bazi ili kešu.
- Red poruka i asinhroni rad. Kad kupac naruči, sistem ne mora čekati da se pošalje SMS restoranu i e-pošta kupcu. Narudžba se sačuva, poruka ide u red, a poseban servis je obradi malo kasnije. Kupac dobija odgovor odmah.
- Repliciranje baze za čitanje. Većina zahtjeva samo čita (jelovnik, status narudžbe); čitanje se može raspodijeliti na kopije baze.
Mjeri, ne nagađaj. Prije bilo koje taktike, izmjeri gdje se vrijeme troši. U dopunskoj praksi mjerimo jelovnik koji se čita iz simulirane baze (50 ms po čitanju). Na računaru autora rezultat je:
bez keša : prosjek 50.457 ms, p95 50.859 ms, 200 zahtjeva za 10.09 s
s kešom : prosjek 0.252 ms, p95 0.000 ms, 200 zahtjeva za 0.05 sS kešom samo prvi zahtjev ide u bazu (50 ms), a ostalih 199 traje manje od hiljaditog dijela milisekunde. Zato je prosjek 0,25 ms (50 ms podijeljeno na 200 zahtjeva), a p95 praktično nula. Brojevi se razlikuju od računara do računara, ali odnos ostaje: oko dvjesto puta brže.
Česta zabluda. „Ako je sporo, kupićemo jači server.” Jači server pomaže dok ne dođete do njegove granice, a kod koji za listu od 100 narudžbi pravi 101 upit (problem N + 1 iz poglavlja 4) biće spor i na najjačem serveru. Prvo se mjeri, pa popravlja uzrok, pa tek onda skalira.
Ukratko.
- Performanse su brzina za jednog korisnika, a skalabilnost brzina kad ih je mnogo.
- Taktike: keš, vertikalno i horizontalno skaliranje, red poruka, replike baze za čitanje.
- Keš donosi rizik zastarjelih podataka, pa se mora poništiti kad se podatak promijeni.
- Prvo se mjeri, pa se bira taktika.
6.6 Dostupnost i otpornost
Dostupnost je procenat vremena u kojem sistem radi; otpornost je sposobnost da radi i kad nešto pukne. U sistemu s mnogo dijelova, nešto uvijek puca: server se restartuje, mreža zakašnjava, servis mapa ne odgovara. Pitanje nije „hoće li”, nego „šta onda”.
Taktike:
- Redundancija – svaki važan dio ima bar dvije kopije (dva servera, baza s rezervnom kopijom u drugom data centru). Ako jedna padne, druga preuzima. Analogija: rezervna guma u autu.
- Vremensko ograničenje (timeout) – ako servis mapa ne odgovori za 2 sekunde, ne čekamo zauvijek.
- Ponovni pokušaj s pauzom (retry with backoff) – pokušaj ponovo nakon 0,5 s, pa nakon 1 s, pa nakon 2 s; ne „bombarduj” servis koji se već muči.
- Prekidač kola (circuit breaker) – kao osigurač u kući: ako servis mapa pet puta zaredom ne odgovori, prestajemo ga zvati na minut i odmah koristimo rezervni plan. Michael Nygard ga je popularizovao u knjizi Release It! (2007).
- Gracilna degradacija – kad nešto ne radi, sistem radi „slabije”, ali radi. Ako servis mapa ne radi, DeliveryApp koristi posljednju poznatu udaljenost za tu adresu ili pita kupca da potvrdi adresu ručno, umjesto da odbije narudžbu.
- Nadzor i upozorenja – tim mora saznati za kvar prije kupaca: grafikon grešaka, vrijeme odziva, upozorenje na mobitel dežurnog.
Iz stvarnog svijeta. Netflix je 2011. opisao alat Chaos Monkey, koji u radnom vremenu namjerno gasi slučajno izabrane servere u njihovoj produkciji. Ideja je da inženjeri moraju graditi sistem koji preživi gubitak bilo kojeg servera, jer znaju da će se to sigurno desiti, i to danju, kad su svi na poslu, a ne u tri ujutro.
Ukratko.
- Dostupnost je procenat vremena rada, a otpornost sposobnost da se radi i kad nešto pukne.
- Taktike: redundancija, vremensko ograničenje, ponovni pokušaj s pauzom, prekidač kola, gracilna degradacija, nadzor.
- Sistem se projektuje s pretpostavkom da će dijelovi otkazivati.
6.7 Sigurnost, upotrebljivost i održivost u praksi
Ostali NFR DeliveryApp 2.0 i kako se implementiraju:
| NFR | Vrsta | Implementacija |
|---|---|---|
| NZ-3 lozinke kao heš, 2FA za restoran | lokalni | biblioteka za heširanje (npr. bcrypt, Argon2); drugi faktor (aplikacija ili SMS) |
| NZ-4 prva narudžba ≤ 3 min, kontrast | lokalni + procesni | test upotrebljivosti s 5 korisnika; automatska provjera kontrasta u CI-ju |
| NZ-5 brisanje adrese i telefona nakon 12 mjeseci | operativni | noćni posao koji briše stare lične podatke; izvještaj o broju obrisanih |
| NZ-6 izolacija gradova | arhitekturalni | svaki red u bazi ima oznaku grada (zakupca); svaki upit filtrira po gradu; test koji to provjerava |
| NZ-7 novi grad za 1 dan, bez novog koda | arhitekturalni + održivost | tarifa kao podatak (poglavlje 3); skripta za uključivanje novog grada |
| održivost | procesni | CI, testovi, pregled koda, složenost ≤ 10 (poglavlja 4–5) |
Princip najmanjih prava važi za sigurnost: dostavljač vidi samo adresu narudžbe koju vozi, a ne istoriju kupca; servis obavještenja može čitati telefon, ali ne i plaćanja. Privatnost se ugrađuje u dizajn od početka (privacy by design), a ne dodaje na kraju.
Ukratko.
- Svaki NFR dobija konkretnu implementaciju i provjeru: biblioteku, test, noćni posao, pravilo u CI-ju.
- Izolacija gradova (NZ-6) i novi grad bez koda (NZ-7) su arhitekturalni NFR.
- Najmanja prava i privatnost po dizajnu su osnovni sigurnosni principi.
6.8 Redizajn proizvoda zbog NFR
Kad se NFR promijene, nekad nije dovoljno „podesiti” sistem; treba ga redizajnirati. DeliveryApp 1.x je napravljen za jedan grad i 200 korisnika: jedna aplikacija na jednom serveru, jedna baza, SMS se šalje odmah dok kupac čeka. Za DeliveryApp 2.0 važi NZ-1a (600 korisnika), NZ-6 i NZ-7.
Tim radi redizajn u četiri koraka:
- Izmjeri postojeće stanje. Test opterećenja (alati kao k6, Locust ili JMeter) na kopiji sistema: pri 200 korisnika p95 je 1,4 s; pri 400 korisnika 3,8 s; pri 600 korisnika dio zahtjeva ističe. Uska grla su čitanje jelovnika iz baze i slanje SMS-a dok kupac čeka.
- Izaberi taktike za uska grla. Keš za jelovnike; red poruka za obavještenja; dvije instance aplikacije iza raspoređivača opterećenja; replika baze za čitanje.
- Ugradi arhitekturalne NFR. Oznaka grada u svakoj tabeli (NZ-6), tarife kao podaci (NZ-7).
- Ponovi mjerenje. Isti test opterećenja nakon izmjena; cilj je p95 ≤ 2 s pri 600 korisnika, uz rezervu.
| DeliveryApp 1.x | DeliveryApp 2.0 | |
|---|---|---|
| aplikacija | jedan server | dvije ili više instanci iza raspoređivača |
| jelovnik | čita se iz baze svaki put | keš, poništava se kad restoran promijeni cijenu |
| obavještenja | SMS dok kupac čeka | red poruka, poseban servis |
| baza | jedna | glavna + replika za čitanje; oznaka grada u svakoj tabeli |
| pravila dostave | u kodu | tarifa grada kao podatak |
| nadzor | logovi na serveru | grafikoni p95, grešaka i dostupnosti; upozorenja |
Primijetite da se funkcionalni zahtjevi u ovoj tabeli skoro nisu promijenili: kupac i dalje naručuje, plaća i prati narudžbu. Promijenili su se NFR, i to je bilo dovoljno da se promijeni pola arhitekture. O tome kako se takve odluke zapisuju govori poglavlje 7.
Ukratko.
- Novi NFR mogu tražiti redizajn, a ne samo podešavanje.
- Redizajn: izmjeri, izaberi taktike za uska grla, ugradi arhitekturalne NFR, izmjeri ponovo.
- DeliveryApp 2.0 dobija keš, red poruka, više instanci, repliku baze i oznaku grada u podacima.
Provjeri se.
- Koja je razlika između vertikalnog i horizontalnog skaliranja? – Vertikalno: jača mašina; horizontalno: više mašina iza raspoređivača opterećenja.
- Šta radi prekidač kola? – Nakon niza neuspjelih poziva prestaje zvati servis na neko vrijeme i odmah koristi rezervni plan.
- Koji je prvi korak redizajna zbog NFR? – Izmjeriti postojeće stanje testom opterećenja.
Dopunska praksa – mjerenje odziva i keš
Cilj je izmjeriti efekat keša i napisati jedan mjerljiv scenarij. Trajanje: jedan čas.
Korak 1 – Mjerenje
Pokrenite primjeri/python/kes.py. Program 200 puta čita jelovnik iz simulirane baze (50 ms po čitanju), pa isto to s kešom (functools.lru_cache), i ispisuje prosjek, p95 i ukupno vrijeme.
python primjeri/python/kes.pyZapišite svoje rezultate. Zašto je prosjek s kešom oko 0,25 ms, a ne nula?
Korak 2 – Zastarjeli keš
Dodajte u program promjenu jelovnika (npr. novo jelo) poslije prvog čitanja. Šta vraća verzija s kešom? Pozovite jelovnik_s_kesom.cache_clear() nakon promjene i provjerite ponovo. Zapišite jednom rečenicom kada DeliveryApp mora poništiti keš.
Korak 3 – Promijenite kašnjenje
Postavite KASNJENJE_BAZE = 0.005 (5 ms) i ponovite mjerenje. Da li se keš i dalje isplati? Šta to govori o pravilu „prvo izmjeri”?
Korak 4 – Scenarij kvaliteta
U repozitoriju deliveryapp-2 napravite docs/nfr.md i upišite dva scenarija u tabeli sa šest dijelova (izvor, podsticaj, okruženje, artefakt, odgovor, mjera): jedan za performanse (NZ-1a), jedan za izolaciju gradova (NZ-6).
Rezultat: izmjereni rezultati za 50 ms i 5 ms, odgovor o poništavanju keša i docs/nfr.md s dva scenarija.
Vježbe
Vježba za studenta 1 – funkcionalno ili nefunkcionalno.
Razvrstajte: a) kupac može platiti karticom; b) plaćanje se završi za najviše 5 sekundi; c) podaci kartice se ne čuvaju u bazi DeliveryApp; d) restoran može označiti jelo kao rasprodato; e) aplikacija radi na Androidu od verzije 10 i iOS-u od verzije 15.
Rješenje. a) funkcionalni; b) nefunkcionalni – performanse; c) nefunkcionalni – sigurnost (i ograničenje zbog pravila kartičnih kuća); d) funkcionalni; e) nefunkcionalni – kompatibilnost/prenosivost.
Vježba za studenta 2 – devetke.
Udruženje traži dostupnost 99,95 % mjesečno (30 dana). Koliko je dozvoljeno zastoja? Šta biste pitali prije nego što prihvatite?
Rješenje. 720 h × 0,0005 = 0,36 h ≈ 21,6 minuta mjesečno. Pitao bih koliko košta sat zastoja (izgubljene narudžbe), da li zastoj noću (kad nema narudžbi) uopšte smeta, i koliko udruženje može platiti za redundanciju koju takva dostupnost traži. Moguće je da je 99,5 % u vrijeme rada restorana pravi zahtjev.
Vježba za studenta 3 – scenarij.
Zahtjev glasi: „DeliveryApp mora brzo prihvatati restorane iz novih gradova.” Napišite ga kao scenarij kvaliteta.
Rješenje. Izvor: administrator DeliveryApp. Podsticaj: zahtjev za uključivanje novog grada s 10 restorana i tarifom. Okruženje: normalan rad, proizvod u produkciji. Artefakt: podešavanja i baza DeliveryApp 2.0. Odgovor: grad je dostupan kupcima s tačnim cijenama, bez izmjene koda i nove isporuke. Mjera: najviše 1 radni dan, 0 linija novog koda, svi testovi tarife prolaze.
Vježba za studenta 4 – taktike.
Za svaki problem predložite taktiku: a) stranica jelovnika je spora jer se svaki put čita iz baze; b) kupac čeka 4 s dok se šalje SMS; c) servis mapa povremeno ne odgovori po 30 sekundi; d) jedan server je pao i DeliveryApp nije radio sat vremena.
Rješenje. a) keš s poništavanjem pri promjeni; b) red poruka i asinhrono slanje; c) vremensko ograničenje od 2 s, ponovni pokušaj s pauzom, prekidač kola i gracilna degradacija (posljednja poznata udaljenost ili ručna potvrda adrese); d) redundancija: bar dvije instance iza raspoređivača opterećenja i nadzor s upozorenjem.
Sažetak u pet rečenica
- Pokémon GO je 2016. imao sve funkcije, ali je dobio oko pedeset puta više prometa od procjene, i igrači nisu mogli ući: nefunkcionalni zahtjevi mogu oboriti funkcionalnost.
- ISO/IEC 25010 daje zajednički rječnik kvaliteta (performanse, pouzdanost, sigurnost, upotrebljivost, održivost i druge), a prema implementaciji NFR su arhitekturalni, lokalni, procesni, operativni i ograničenja.
- NFR mora biti mjerljiv scenarij s izvorom, podsticajem, okruženjem, artefaktom, odgovorom i mjerom, uz percentile umjesto prosjeka i devetke dostupnosti prevedene u dozvoljeni zastoj.
- Performanse i skalabilnost postižu se kešom, skaliranjem, redovima poruka i replikama baze, a dostupnost i otpornost redundancijom, vremenskim ograničenjima, ponovnim pokušajima, prekidačem kola i gracilnom degradacijom, i uvijek se prvo mjeri.
- DeliveryApp 2.0 je zbog novih NFR (600 korisnika, izolacija gradova, novi grad bez koda) redizajniran, iako su funkcije ostale skoro iste.