Tehtävänanto (lyhennetty): Olet menestyvän KillerApp-ohjelmiston kehitystiimissä. Ohjelmistosi laadun varmistus (quality assurance) on kuitenkin lähes olematon ja tehtävänäsi on luoda menetelmiä ohjelmiston laadun varmistukseen. Kirjoita ehdotus, kuinka tähän päästään. Essee arvosteltiin asteikolla 0-10 p. Essee oli osa Teknillisen korkeakoulun kurssin T-76.3601 Ohjelmistotuotannon perusteet suorittamista.

Essee 3 - Ohjelmiston laatu (Software Quality)

Ohjelmiston laadun varmistuksen ensimmäinen vaihe on määritellä, millaista laatua ollaan hakemassa. Miten ohjelmiston laatu määritellään? Ensiksi pitääkin asettaa jotkin mittarit ja rajat, jolla laatua mitataan. Tämän tuotteen tapauksessa laatu voitaisiin määritellä ajamalla tiettyjä testejä ja katsomalla, miten ohjelmisto suoriutuu niistä. Testit pitää suunnitella hyvin etukäteen ja niiden pitää kattaa kaikki oleellisimmat käyttötilanteet. Laatua voidaan mitata myös katsomalla paljonko bugeja ohjelmisto sisältää, arvioimalla ohjelmiston toteutusta (esim. arkkitehtuuri ja itse ohjelmakoodi) tai testauttaa tuotetta käyttäjillä ja määritellä laadukkuus palautteen perusteella. Loppujen lopuksi tuote on asiakkaiden näkökulmasta laadukas vain silloin, kun se tekee sen kunnolla, mitä asiakkaat siltä halusivatkin.

Laadun varmistuksen tärkeä osa on myös sopia erilaisista käytännöistä, joiden avulla havaitaan heikkouksia ohjelmistosta tai vältetään näiden heikkouksien syntyminen. Tällaisia käytäntöjä ovat mm. erilaiset katselmukset, arvioinnit ja testit, joita käytetään koko tuotekehityksen ajan. Näiden käytäntöjen avulla löydetään ohjelmistosta heikkouksia ja saadaan niitä korjatuksi, luodaan uusia ideoita sekä pidetään ihmiset ajan tasalla siitä, missä vaiheessa ollaan menossa.

Esimerkiksi pariohjelmointia voisi käyttää hankaliksi oletettujen ominaisuuksien toteuttamisessa. Kaiksi päätä ajattelee aina paremmin kuin yksi ja samalla saadaan tehtyä arviointia sekä keskusteltua eri toteutustavoista. Ryhmäarviointia voitaisiin käyttää aina, kun jokin osa ohjelmistosta on saatu valmiiksi. Tälle osalle ohjelmistoa tehdään siis pienessä ryhmässä tapahtuva arviointi, jolla pyritään takaamaan, että se osa tuotteesta on laadukas. Tähän arviointiin osallistuisivat yleensä vain varsinaisen kehitystiimin jäsenet, koska esitetyt asiat voivat olla hieman liian teknisiä esim. loppukäyttäjille. Läpikäyntiä taas voitaisiin käyttää myös muiden sidosryhmien kanssa (esim. markkinointi, loppukäyttäjät), jotka eivät varsinaisesti ole suoranaisesti osallisia tuotteen kehittämisessä . Tällöin hekin saavat kuvan, missä vaiheessa ollaan menossa ja mitä on saatu aikaan sekä ehkä kerätä samalla uusia ideoita tai huomata virheitä.

Kaikkien ohjelmiston osasten pitäisi käydä nämä käytännöt läpi, jolloin niiden laadukkuudesta voidaan sanoa jotain. Näiden käytäntöjen käyttöä valvoo laadun valvonnasta vastaava tiimi, jonka tehtävänä on varmistaa, että kaikkia edellä mainittuja käytäntöjä käytetään, esim. että jokaiselle komponentille tehdään yksikkötestaus ja että toteutetut ominaisuudet käydään läpi ryhmissä. Tämä tiimi toimii eräänlaisena asiakkaan korvikkeena - he tarkastelevat tuotteen laadukkuutta asiakkaan näkökulmasta. Laadun valvonnasta vastaavan tiimin jäsenet eivät osallistu itse tuotteen kehittämiseen suoranaisesti. He keräävät ja analysoivat dataa testauksista, arvioinneista ja muista mittareista ja arvioivat, onko ohjelmisto niin laadukas, kun aluksi asetettiin tavoitteiksi. Jos ei ole, asiaan pitää puuttua.

Jos jokin käytäntö ei tunnu toimivan, yrittää tämä laadunvalvonnan tiimi opettaa ja motivoida kehitystiimin jäseniä tähän ja jos sekään ei auta, mietitään jotain vaihtoehtoista käytäntöä. Esimerkiksi pariohjelmointi ei välttämättä sovi kaikille ja sen tilalla voisi käyttää esim. menetelmää, jossa kehittäjä lähettää toteutuksensa arvioitavaksi toiselle tiimin jäsenelle.

Laadun varmistuksen suurimpia hyötyjä on se, että mitä aikaisemmin ohjelmiston heikkoudet löydetään, sitä vähemmän niiden korjaaminen tulee maksamaan. Hyvien käytäntöjen ja tarkkailun avulla saadaan löydettyä heikkouksia ohjelmistosta mahdollisimman aikaisessa vaiheessa ja mikä parasta yleensä estettyä heikkouksien syntymiset kokonaan.

Lähteet:

• Pressman. 2005. Software Engineering: A Practitioner's Approach, 6th edition. McGraw-Hill. 912 s. ISBN 007-123840-9.