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

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

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

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

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)

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

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

Mjesto V&V unutar softverskog procesa 1/2

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

Planovi za testiranje softvera

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

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

Proces debuggiranja

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

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

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

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

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

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

Primjer 'check-liste' 1/2

Primjer 'check-liste' 2/2

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

Primjer popisa sumnjivih situacija

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!

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

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

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

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

Primjer je IBM-ov: "Cleanroom software development"