Ohjelmiston tarkastus

Ohjelmiston tarkastus () ohjelmistotuotannossa viittaa hyvin määriteltyyn prosessiin, jossa ohjelmistoalan ammattilaiset tarkastavat jonkin tuotteen () löytääkseen virheitä. Tarkastus voi myös viitata tarkemmin ottaen Fagan-tarkastukseen joka on Michael Faganin kehittämä ohjelmistotarkastusprosessi.

Johdanto

Ohjelmistojen tarkastus on yksi yleisimpiä katselmointimenetelmiä joita ohjelmistoprojekteissa käytetään. Tarkastuksen päämääränänä on, että tarkastajat pääsevät yhteisymmärrykseen tuotteesta ja hyväksyvät sen käyttöön projektissa. Yleisimpiin tarkastuksen kohteisiin kuuluu mm. ohjelmiston vaatimusmäärittely, suunnitteludokumentit ja testaussuunnitelma.

Prosessin alussa valitaan tarkastuksen kohde ja kerätään yhteen tiimi joka huolehtii prosessin läpikäymisestä. Seuraavaksi valitaan puheenjohtaja tarkastuspalaverin pitäjäksi. Jokainen tarkastaja valmistautuu palaveriin käymällä läpi tarkastuksen kohteen ja kirjoittamalla ylös jokaisen mahdollisen vian tai puutteen.
Tarkastuksen päämääränä on löytää viat ja puutteet. Tarkastuksessa vika tai puute on mikä tahansa asia liittyen tuotteeseen joka estää tarkastajaa hyväksymästä sitä. Esimerkiksi, jos tiimi tarkastaa ohjelmiston vaatimusmäärittelyä jokainen tekstinkohta dokumentissa josta tarkastaja on eri mieltä, on vika.

Prosessi

Michael Fagan kehitti Fagan-tarkastusmenetelmän () ja julkaisi sen vuonna 1976. 
Faganin menetelmä ulottuu vaatimusmäärittelydokumenteista ja suunnitteludokumenteista varsinaiseen toteutukseen ja voi soveltaa jo varhaisessa tuotantovaiheessa, joka johtaa alhaisempiin virheen poistamisen kustannuksiin. Tarkastus ei kuitenkaan voi osoittaa, että varsinainen toteutus on oikein varsinaisessa käytössä.
Alkuperäistä on useiden tutkijoiden puolesta kritisoitu ja sitä on muutettu useita kertoja, joka on johtanut useisiin muunnelmiin. Muunnelmia ovat esittäneet Parnas ja Weiss (1985), Bisant ja Lyle (1989), Martin ja Tsai (1990), Knight ja Myers (1993), Votta (1993), Gilb ja Graham (1993).

Faganin ehdottamassa menetelmässä on viisi vaihetta ja neljä roolia tarkastusryhmässä. Apumenetelmiksi on ehdotettu "lukutekniikoita" ().

Prosessiin tulisi kuulua aloituskriteerit jotka määrittävät milloin tarkastusprosessi on mahdollista käynnistää. Tämä estää keskeneräisten tuotteiden tarkastuksen. Aloituskriteerit voidaan esimerkiksi kirjoittaa listan muotoon, jolloin listalla voi olla vaikka kohta: "dokumentti on oikoluettu".

Vaiheet 
Tarkastusprosessin vaiheet ovat: suunnittelu, yleiskatsaus, valmistautuminen, tarkastuspalaveri, virheiden korjaus ja seuranta. Valmistautuminen, tarkastuspalaveri ja virheiden korjaus -vaiheita voidaan iteroida.

 Suunnittelu: tarkastuksen puheenjohtaja suunnittelee tarkastuksen.
 Yleiskatsaus: tekijä esittelee tuotteen taustoja.
 Valmistautuminen: jokainen tarkastaja tutkii tuotteen mahdollisten virheiden varalta.
 Tarkastuspalaveri: palaverin aikana sihteeri lukee tuotteen läpi kohta kohdalta ja tarkastajat ilmoittavat jokaiseen kohtaan löytämänsä virheet.
 Virheiden korjaus: tekijä korjaa virheet tarkastuspalaverissa saadun palautteen mukaan.
 Seuranta: tekijän tekemät muutokset tarkastetaan jotta virheet on saatu varmasti korjattua.

Puheenjohtaja lopettaa prosessin kun ennalta määritellyt lopetuskriteerit täyttyvät.

Roolit 

Seuraavat roolit ovat käytössä tarkastuksen aikana.

 Tekijä: henkilö joka on tehnyt tarkastuksen alaisena olevan tuotteen.
 Puheenjohtaja: toimii tarkastuksen johtajana - puheenjohtaja suunnittelee tarkastuksen ja koordinoi sitä.
 Lukija: henkilö joka lukee dokumentit ääneen yksi kohta kerrallaan. Toiset tarkastajat sen jälkeen esittävät löydetyt virheet.
 Sihteeri: henkilö joka kirjaa ylös tarkastuksen aikana löydetyt virheet.
 Tarkastaja: henkilö joka tarkastaa tuotteen löytääkseen virheitä.

Muut tarkastustyypit

Koodin katselmointi 

Koodin katselmointi on tarkastuksen erikoistapaus jossa tiimi käy läpi lähdekoodia ja etsii toteutuksesta mahdolliset virheet. Vika lähdekoodissa voi olla kohta koodissa joka ei kunnolla täytä vaatimuksia tai ei toimi kuten ohjelmoija tarkoitti. Katselmoinnissa voidaan myös nostaa esiin puutteet lähdekoodissa jotka eivät ole varsinaisesti bugeja mutta seikkoja joita voitaisiin muuten parantaa, kuten tekemällä koodilohko helppolukuisemmaksi tai suorituskykyisemmäksi.

Lisäksi, että koodin katselmoinnit auttavat bugien löydössä, ne myös tutustuttavat tiimin mahdolliset uudet ohjelmoijat koodiin ja näyttävät kokemattomille ohjelmoijille uusia ohjelmointitekniikoita.

Edut 
Tarkastus vähentää virheitä ja aikaisessa vaiheessa tehtynä säästää kustannuksissa ja aikataulussa sekä vähentää uudelleentyöstämistä. Tuottavuus pysyy korkeampana kun uudelleentyöstäminen vähenee. Kustannusten ja aikataulun säästöt ovat tyypillisesti 30 prosentin luokkaa. Virheistä 30–90 prosenttia voi löytyä tarkastuksessa.

Kritiikkiä 
Faganin tarkastusmenetelmä on käytännössä toimiva, mutta se on aikaa vievä ja työläs tapa.

Faganin menetelmälle ehdotetuissa vaihtoehtoisissa tavoissa pyritään pienempiin tapaamisiin ja pienempiin ryhmiin sekä pienempiin kokonaisuuksiin. Parnasin ja Weissin mukaan tarkastuksen ongelmakohtia on, että tarkistaja hukkuu tietomäärään, tarkistaja ei tunne tavoitteita riittävästi, yksilöillä ei ole selkeää vastuuta, suuri tapaaminen antaa vain kahdelle henkilölle mahdollisuuden vuorovaikuttaa, väärät henkilöt ovat paikalla tapaamisessa ja tarkastajien pitää tutkia asioita, joihin näillä ei ole osaamista. Knightin ja Myersin mukaan tarkastuksen ongelmakohtia ovat, että perinteisessä tarkastuksessa laatuun ei kiinnitetä riittävästi huomiota, menetelmiä ei sovelleta johdonmukaisesti, tulokset eivät ole luotettavia koska ne eivät ole riittävän kattavia, henkilöresursseja ei käytetä tehokkaasti (vain yksi henkilö voi puhua kun muut kuuntelevat ilman rinnakkaista aktiviteettia), ryhmä ei voi tarkistaa kaiken tyyppisiä virheitä yhtäaikaisesti tapaamisessa ja olemassaoleville tarkastusmenetelmille ei ole tietokoneellista tukea.

Katso myös 

 Ohjelmistotuotanto
 Ohjelmiston testaaminen
 Ohjelmiston laatu

Lähteet 

Ohjelmistotuotanto
Ohjelmiston katselmointi