Ohjelmiston tarkastus

Tähän artikkeliin tai osioon ei ole merkitty lähteitä, joten tiedot kannattaa tarkistaa muista tietolähteistä.
Voit auttaa Wikipediaa lisäämällä artikkeliin tarkistettavissa olevia lähteitä ja merkitsemällä ne ohjeen mukaan.

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

Johdanto

[muokkaa | muokkaa wikitekstiä]

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

[muokkaa | muokkaa wikitekstiä]

Michael Fagan kehitti Fagan-tarkastusmenetelmän (engl. Fagan inspection) ja julkaisi sen vuonna 1976.[1][2][3] Faganin menetelmä ulottuu vaatimusmäärittelydokumenteista ja suunnitteludokumenteista varsinaiseen toteutukseen ja voi soveltaa jo varhaisessa tuotantovaiheessa, joka johtaa alhaisempiin virheen poistamisen kustannuksiin.[3] Tarkastus ei kuitenkaan voi osoittaa, että varsinainen toteutus on oikein varsinaisessa käytössä.[3] Alkuperäistä on useiden tutkijoiden puolesta kritisoitu ja sitä on muutettu useita kertoja, joka on johtanut useisiin muunnelmiin.[3] 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).[3]

Faganin ehdottamassa menetelmässä on viisi vaihetta ja neljä roolia tarkastusryhmässä.[3] Apumenetelmiksi on ehdotettu "lukutekniikoita" (engl. Reading Techniques).[3]

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

[muokkaa | muokkaa wikitekstiä]

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

[muokkaa | muokkaa wikitekstiä]

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

[muokkaa | muokkaa wikitekstiä]

Koodin katselmointi

[muokkaa | muokkaa wikitekstiä]

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

[muokkaa | muokkaa wikitekstiä]

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

Kritiikkiä

[muokkaa | muokkaa wikitekstiä]

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

Faganin menetelmälle ehdotetuissa vaihtoehtoisissa tavoissa pyritään pienempiin tapaamisiin ja pienempiin ryhmiin sekä pienempiin kokonaisuuksiin.[3] 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.[3] 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.[3]

Katso myös

[muokkaa | muokkaa wikitekstiä]

Lähteet

[muokkaa | muokkaa wikitekstiä]
  1. ↑ M. E. Fagan: Design and code inspections to reduce errors in program development ieeexplore.ieee.org. doi:10.1147/sj.153.0182 Viitattu 13.3.2022. (englanniksi)
  2. ↑ E. P. Doolan: Experience with Fagan’s Inspection Method (PDF) ida.liu.se. helmikuu 1992. Viitattu 13.3.2022. (englanniksi)
  3. ↑ a b c d e f g h i j Hanna Scott: A Balance between Testing and Inspections (PDF) diva-portal.se. kesäkuu 2004. Viitattu 13.3.2022. (englanniksi)
  4. ↑ a b c Geshwaree Huzooree & Vimla Devi Ramdoo: Evaluation of Code Inspection on an Outsourced Software Project in Mauritius (PDF) citeseerx.ist.psu.edu. maaliskuu 2015. Viitattu 13.3.2022. (englanniksi)
  5. ↑ a b c Bill Brykczynski & Reginald Meeson & David A. Wheeler: Software Inspection: Eliminating Software Defects (PDF) citeseerx.ist.psu.edu. Viitattu 13.3.2022. (englanniksi)
  6. ↑ Mounisha Kasireddy: Evaluating the Usability of Collaboration Tool for Software Inspection Process (PDF) (sivu 7) library.ndsu.edu. huhtikuu 2019. Viitattu 13.3.2022. (englanniksi)