1. IV. dio Verifikacija i validacija
10. predavanje
IV. dio
Verifikacija i validacija

2. U ovom predavanju trebali bi...
definirati verfifikaciju i validaciju i razumjeti razliku između njih
navesti i opisati metode za verfikaciju i validaciju

3. Općenito
Verifikacija i validacija (V&V) je skup aktivnosti kojima se nastoji utvrditi odgovara li softver specifikacijama
Konačni cilj je uvjeriti se da je softver dovoljno dobar i pouzdan kako bi služio svojoj svrsi
To ne znači da nema niti jednu grešku, ali da je dovoljno dobar i pouzdan za predviđeni oblik korištenja

4. Razlika između verifikacije i validacije
Verifikacija ("Are we building the product right?") je provjera da li softver odgovara specifikaciji, dakle dokumentu o zahtjevima
Validacija ("Are we building the right product?") je provjera da li softver zadovoljava "stvarnim" potrebama korisnika
Ova razlika nastaje zato što specifikacija ne uspijeva u potpunosti zabilježiti stvarne potrebe korisnika

5. Metode za V&V
Statička V&V – analiziraju se i provjeravaju dokumenti, modeli sustava i oblikovanja, te programski kod (odvija se bez stvarnog izvođenja softvera)
Testiranje – pokusno izvođenje softvera ili njegovih dijelova na umjetno pripravljenim podacima, uz pažljivo analiziranje rezultata (ovo je uobičajena metoda)

6. Prednosti statičke V&V 1/2
Jedna statička provjera može otkriti puno grešaka (testiranje obično otkriva samo jednu grešku, obično prvu, nakon koje se program ili "ruši" ili nastavlja raditi s krivim podacima)
Statička provjera omogućuje bolje korištenje znanja o programiranju u aplikacijskoj domeni. Osobe koje obavljaju provjeru znaju koje se vrste grešaka često pojavljuju u dotičnom prog. jeziku, pa se na njih koncentriraju

7. Prednosti statičke V&V 2/2
Smatra se da se statičkim metodama može otkriti 60-90% grešaka
Troškovi su puno manji za statičku provjeru, pa su onda troškovi za testiranje isto tako manji

8. Mjesto V&V unutar softverskog procesa 1/2

9. Mjesto V&V unutar softverskog procesa 2/2
V&V se prvenstveno primjenjuje na programski kod, ali poželjna je primjena i u ranijim fazama razvoja softvera
Statička provjera se može obavljati u raznim fazama softverskog procesa
Testiranje je primjenjivo samo na program, odnosno prototip
Program se najprije provjerava statičkim metodama, a nakon toga se još i testira

10. Planovi za testiranje softvera

11. Dokument: plan za testiranje softvera
Ovaj dokument trebao bi nastati već u fazi specifikacije i oblikovanja sustava
Sastoji se od:
- opis procesa testiranja
- popis zahtjeva koji će se testirati
- popis dijelova softvera koji će se testirati
- kalendar testiranja
- opis načina bilježenja rezultata testiranja
- popis hardvera i softvera koji je potreban za testiranje
- ograničenja koja utječu na proces testiranja

12. Debuggiranje Tijekom V&V otkrivaju se greške
Softver se mijenja kako bi se greške popravile
Proces debuggiranja je često integriran s V&V, iako su to različiti procesi:
V&V utvrđuje postojanje grešaka u softveru
Debuggiranje je proces koji locira i popravlja greške

13. Proces debuggiranja

14. Kako se provodi Debuggiranje?
Kreativni proces – teško ga je precizno opisati
Vješti programeri se pouzdaju u svoje iskustvo, poznavanje čestih grešaka i poznavanje svojstava programskog jezika
Od pomoći mogu biti interaktivni debuggeri ugrađeni u lower-CASE alate (izvođenje koda liniju po liniju, praćenje stanja varijabli...)

15. Statička verifikacija
Može se obavljati u svim fazama softv. proces
Najčešći oblik: statička verifikacija programa
Analiza i pregled programskog koda bez stvarnog izvođenja koda
Primjenjuje se prije testiranja programa – otkriva se glavnina grešaka
Nakon toga testiranje ide brže, ukupni troškovi verifikacije su manji

16. Poznate tehnike statičke verifikacije
Inspekcija programa
Automatska statička analiza
Formalna verifikacija

17. Inspekcija programa
Prakticirala se u velikim firmama poput IBM, HP tijekom '70-tih, '80-tih i '90-tih godina prošlog stoljeća
Sudjeluje grupa ljudi sa strogo zadanim ulogama:
- autor ili vlasnik – programer odgovoran za kod i popravak grešaka
- inspektor – pronalazi greške, propuste i nekonzistentnosti u programu
- čitač – glasno čita programski kod na sastanku
- zapisničar – bilježi rezultate sastanka
- moderator – planira i organizira sastanke, upravlja procesom

18. Proces inspekcije programa
Najvažnija faza je dobro pripremljen sastanak
Ne raspravlja se kako će se greške popraviti, to kasnije radi autor
Moderator odlučuje da li je potrebno sve ponoviti

19. Važne stvari za uspješan sastanak
treba postojati precizna specifikacija programa
treba postojati ažurna dovršena verzija programskog koda
treba postojati 'check-lista' čestih programerskih pogrešaka
članovi grupe su upoznati s organizacijskim standardima i žele surađivati

20. Primjer 'check-liste' 1/2

21. Primjer 'check-liste' 2/2

22. Automatska statička analiza
obavlja se pokretanjem softverskih alata koji prolaze kroz izvorni kod našeg programa i otkrivaju moguće greške i anomalije u tom kodu
skreće se pažnja na 'sumnjiva mjesta' i ispisuju se poruke
popis sumnjivih situacija koje upućuju na grešku ovisi o programskom jeziku

23. Primjer popisa sumnjivih situacija

24. Primjer C programa i rezultata analize pomoću UNIX-ovog 'lint' alata
C program nema nekog naročitog smisla
prevođenje (kompajliranje) programa u ovom slučaju nije javilo niti jednu grešku!

25. Efikasnost automatske statičke analize
Kod jezika poput C-a, automatska statička analiza predstavlja efikasnu tehniku
Kod jezika 'strože' sintakse poput JAVA-e, izbjegnute su neke jezične konstrukcije koje lako dovode do grešaka, pa je automatska statička analiza u tom slučaju manje isplativa

26. Formalna verifikacija
Matematičko dokazivanje da je program konzistentan sa svojom specifikacijom, moguće je pod uvjetima:
- semantika programskog jezika je formalno definirana
- postoji formalna specifikacija za program

27. Provođenje dokaza
polazni uvjeti iz specifikacije i same naredbe iz programa se uzimaju kao činjenice
iz njih se izvode konačni uvjeti koji po specifikaciji moraju biti zadovoljeni nakon izvršenja programa

28. Povijest formalne specifikacije
Ovom idejom su se bavila mnoga velika imena računarstva tijekom '70-tih godina prošlog stoljeća (Hoare, Dijkstra, Writh)
Ipak, nije se došlo dalje od malih akademskih primjera, ali ideja se i dalje njeguje u krugovima pobornika formalnih metoda za razvoj softvera
U praksi se ova tehnika obično reducira na malo strožu inspekciju: razvijaju se strogi (no ne sasvim formalni) argumenti da program radi korektno

29. Primjer je IBM-ov: "Cleanroom software development"