Laadunvarmistussuunnitelma Ryhmä Jämät

Transkriptio

1 Laadunvarmistussuunnitelma Ryhmä Jämät Kyykkä Jarno, Palomäki Kari, Piirainen Esko, Seise Matti

2 Johdanto Laadunvarmistussuunnitelmassamme sovelletaan Juranin määritelmää, siltä osin kun se kettärään prosessimalliimme taipuu. Tärkeimmiksi tekijöiksi nousevat asiakastyytyväisyys ja tuotteen vapaus puutteista, niin pitkälle kuin on mahdollista. Asiakkaan tyytyväisyys Asiakkaiden tyytyväisyys tarkistetaan asiakkailta jokaisen syklin päättyessä. Tässä tapauksessa tarkistus tapahtuu viikottain esittäessämme työmme tuotoksen muulle ryhmälle laskuharjoitustilaisuudessa perjantaisin. Vapaa puutteista Täysin puutteetonta ohjelmistoa emme voi projektin ollessa kesken asiakkaalle toimittaa. Pyrimme siihen, että jokaisen syklin luvatut toiminnallisuudet ovat vapaat puutteista, sikäli kun niihin ei liity seuraavien syklien osien riippuvuuksia. Vaatimukset Ohjelmistossamme, kuten kaikissa muissakin ohjelmistoissa, on toiminnallisuuksia joiden toiminta ja oikeellisuus voidaan suhteellisen todentaa ja mitata. Haastavampaa onkin miettiä miten saamme tarkastettua ei-toiminnallisten vaatimusten toteutumisen ohjelmistossamme. Toiminnalliset vaatimukset Toiminnallisuudet käydään jokaisen syklin päättyessä läpi tarkistuslistan avulla. Tässä tarkistetaan toimminnallisuuksien toimivan asiakkaan kanssa sovitulla tavalla. Ennen sykliä on laadittu luettelo siitä, mitä toimintoja sykliin aikana tehdään. Tälläisenä tarkistuslistana meillä toimii projektimme backlog. Ei-toiminnalliset vaatimukset Sovelletaan Juha Tainan luennolla esittämää yhdistettyä laatutekijämallia. Sykleittän tarkastellaan ja arvioidaan kunkin laatutekijän toteutuminen tarkistuslistan avulla. Meille tärkeimmiksi laatutekijöiksi tässä on korostettu Luotettavuus, Tehokkuus ja Käytettävyys. Muiltakin osin pyrimme tekemään mahdollisimman laadukkaan lopputuloksen ja

3 tarkistamme myös muut ohjelmiston laadun osatekijät, vaikka emme niiden toteutumiseen tässä projektissa keskitykkään. Nämä osatekijät ovat Juha Tainan kurssin aikana listaamat: 1) Oikeellisuus 2) Luotettavuus - tärkeä 3) Tehokkuus - tärkeä 4) Yhtenäisyys 5) Käytettävyys - tärkeä 6) Ylläpidettävyys 7) Joustavuus 8) Verifioitavuus 9) Siirrettävyys 10) Uudelleenkäytettävyys 11) Yhteentoimivuus 12) Käyttöturvallisuus 13) Hallittavuus Projektin ennakkovaiheiden laadunvarmistus Sopimuksen laadunvarmistus Tässä tapauksessa on laadittava luettelo ominaisuuksista ja varmistettava, että ne ovat järkeviä ja oikeassa suhteessa käytössä oleviin resursseihin eli projektin jäsenten ajankäyttömahdollisuuksiin ja osaamistasoon. Tässä asiakkaat ovat osittain samalla projektin tekijöitä, on asiakkaiden ajankäyttö ja osaaminen sidoksissa tekijöiden vastaaviin resursseihin ja siten automaattisesti kunnossa, jos ne tekijöiden kohdalla ovat kunnossa. Projektisuunnitelma & Riskit Aikataulu Aikataulumme on sidottu kurssin pituuteen, ja tämä kurssin pituus on lomitettu viiteen sykliin. Jokaisen syklin päättymispäivä on ryhmällemme perjantaisin klo 12 koko kurssin ajan. Henkilö-ja laiteresurssit Meillä on käytettävissämme henkilöresursseina ryhmämme jäsenet (ks. yltä) ja laitteistoresursseina ryhmäläisten henkilökohtaisten tietokoneiden lisäksi myös Helsingin Yliopiston asiakaspäätteitä, joilla voimme projektin toteutumista edistää. Projektin riskit Projektissa on yksi käytännön riski: Se ettemme saa toteutettua ohjelmistoa viikoittain sovitussa aikataulussa. Syinä tähän ovat projektiryhmäläisten henkilökohtaiset esteet ja laitteiden rikkoutumiset. Asiakkaiden toiveiden täyttäminen tai asiakasrajapinnan katoaminen olisi isommassa projektissa oma riskinsä, mutta tässä projektissa saamme onneksi toimia kokoajan asiakasrajapinnassa. Projektin jäsenet ja alihankkijat Projektin jäsenet ovat ryhmämme jäsenet (ks. yltä), asiakkaina projektillemme toimivat muut kurssilaiset. Alkuperäinen ohjelmisto tuli ryhmäläiseltämme. Muita mahdollisia

4 alihankkijoiksi mahdollisesti miellettäviä ryhmiä voisivat olla työkalujen toimittajat, kuten eclipse, eclemma, code.google, googledocs ja eclipse meters. Käytettävä prosessimalli Projektissa käytämme sovellettua ketterää prosessimallia. Käytettävät työkalut Työkaluina käytämme projektinhallintajärjestelmä code.google.com:ia, versionhallintana Subversionia ja kehitysympäristönä Eclipseä. Eclipseen otamme käyttöön testaamista helpottavan eclemma-liitännäisen, sekä projektin metriikoita seuraavan eclipsemetersliitännäisen. Uudelleenkäyttösuunnitelma Tätä projektia ei ole tarkoitettu käytettäväksi uudelleen. Laatusuunnitelma Laatutavoitteet Ensisijaisiksi laatutekijöiksi on valittu luotettavuus, tehokkuus ja käytettävyys. Näitä havainnoidaan ensisijaisesti käyttäjien kokemuksista. Projektin osavaiheiden aloitus-ja lopetusehdot Toteutamme projektimme sykleissä, joten syklien aloitus- ja lopetusehdot ovat ensisijaisesti aikaan sidottuja. Toissijaisena, joskin aivan yhtä tärkeänä lopetusehtona edelliselle syklille on se, että syklin osa on toteutettu ja ryhmäläisten yhdessä hyväksi toteama. Tämän jälkeen tuotteen osa esitellään asiakkaalle, joka ilmaisee vielä mielipiteensä tuotteesta tai tarkasteltavasta tuotteen osasta. Mikäli asiakas on tyytyväinen tuotteeseen / tuotteen osaan, todetaan se riittävän laadukkaaksi. Mikäli tuotteen osassa on puutteita, siirretään puutteiden korjaus korkealle tärkeysasteelle seuraavan syklin alkuun. Käytettävät laadunvarmistusmenetelmät Ohjelmistomme laadunvarmistusmenetelminä käytämme katselmointeja ja testausta. Testausstrategiamme on sijoitettu mahdollisimman alkuvaiheeseen ja pyrimme testaamaan ohjelmistoa koko sen elinkaaren ajan. Testaamista ei voitu aloittaa ennen kun ohjelmiston arkkitehtuuri suunniteltiin uudellen. Käytännössä tämä tarkoittaa sitä, että testaaminen painottuu meillä kolmanteen sykliin ja siitä eteenpäin testaamme yksikkötestein jokaisen uuden toiminnallisuuden.

5 Projektin elinkaaren laadunvarmistus Kehitystyön laadunvarmistus toteutetaan meillä ensisijaisesti katselmoinnein (review), ja tämän toteutusmuotona on tarkastuksen ja verataisarvioinnin sovellettu yhdistelmä. Kuten on aiemmin mainittua, kuuluu testaus (software testing) laadunvarmistukseemme. Pyrimme testaamaan riittävästi jokaisen syklin toteutuksen yhteydessä. Laatukehyksen laadunvarmistus Virheiden välttäminen toteutetaan huolellisella koodauksella ja kattavalla testauksella jokaisen syklin aikana. Dokumenttipohjia ja tarkistuslistoja käytetään tarvittaessa ja käytettävät pohjat tallennetaan projektinhallintaamme googlecodeen. Projektin henkilöstön koulutus, ammattitaidon ylläpito ja sertifiointi eivät tule kyseeseen tässä yhteydessä, mutta työhyvinvoinnista ja projektin läpiviennin jaksamisesta pyritään huolehtimaan eikä ketään kuormiteta yli omien voimavarojensa. Versionhallintaa sovelletaan tarvittavassa määrin. Dokumenttien hallintaa varten käytämme googledocs-palvelua, sekä code.google.comprojektinhallintapalvelua. Yritystason laadunvarmistusta ei ole tarpeen soveltaa tässä projektissa Projektinhallinnan laadunvarmistus Projektin seurantaa tapahtuu jokaiseen sykliin liittyvässä harjoitusryhmien kokoontumisessa, jossa saadaan myös ohjausta. Laatua mitataan ja arvoidaan jokaisen syklin aikana ja syklien päättyessä. Laadun kustannuksia ei tässä projektissa mitata eikä arvioida. Yleisesti käytettyjä metriikoita, kuten koodirivien määrä/kuukausi, virheiden määrä/1000 ohjelmariviä tai tuottava työaika/kokonaistyöaika ei ole mielekästä soveltaa näin suppeassa projektissa. Näiden sijaan käytämme Eclipse-kehittimeen rakennettua liitännäistä, Eclipsemeters:iä, jonka perusasetukset sopivat tämän kokoisille projekteille. Käytettäviä metriikoita käsitellään tarkemmin omassa kappaleessaan. Standardointi Standardien systemaattinen soveltaminen ei näin pienessä projektissa ole mielekästä. Laadunvarmistuksen organisointi Tämän tyyppisessä ja näin suppeassa projektissa ei ole mielekästä perustaa laadunvarmistusryhmää eikä muutenkaan soveltaa miktään laatustrategiaa. Henkilöhallintakaan ei ole tässä yhteydessä relevantti asia. Laatukäsikirjaa ei ole mielekästä tai mahdollista laatia tämän projektin yhteydessä, ellei sitten laadittuja ja laadittavia muutamia laatuun liittyviä irrallisia dokumentteja pidetä suppeana laatukäsikirjana.

6 Projektissa käytettävät mittarit ja työkalut Laatutekijöitä tulisi pystyä arvioimaan numeerisesti sopivien mittarien avulla. Mittareiden valinnan hyvä periaate on valita pieni joukko hyvin määriteltyjä metriikoia kaiken mahdollisen mittaamisen sijasta. Käytämme tässä projektissa seuraavia mittareita: Ohjelmiston koko koodiriveinä (KLOC Kilos Lines Of Code) Toimintojen määrä (FP, Function Points) Luokkien ja metodien määrä Kenttien määrä Kokonaistyöaika DevH. Näiden perusteella voidaan voidaan laskea kehitystyön tuottavuudet DevP=DevH/KLOC ja FDevP=DevH/FP. Kokonaistyöajanseuranta toteutetaan backlogiin. Metodien yhtenäisyyden puute (Lack of Cohesion on Methods), LCOM. Tästä nähdään montako erillistä metodijoukkoa luokassa on. Metodijoukot ovat erilliset, jos niiden jäsenet eivät viittaa samoihin luokan attribuutteihin. Emme salli riippuvuussyklien muodostumista tämän kokoisessa ohjelmassa Asikkaiden tyytyväisyyttä peräänkuulutetaan katselmoinneissa. Kysylykaavaketutkimus olisi tehokkaampi tapa, mutta tämän kokoisessa projektissa ja meille varatussa ajassa ei sellaista voida toteuttaa. Mikäli se toteutettaisiin laskettaisiin pinotettu keskiarvo siten että 1.00 on täydellinen tyytyväisyys ja 0.00 täydellinen tyytymätömyys Suurin osa käyttämistämme mittareista saadaan tulkittua käyttämällä Eclipsemetersliitännäistä vakioasetuksilla. (Asiakastyytyväisyys poislukien kaikki muut) Koodin ulkoasun yhtenäistämiseen käytämme Eclipse -koodityylitemplatea koodin ulkoasun yhdenmukaistamiseen. Ryhmällä on käytössään templatetiedosto, joka asetetaan projektin tyylitiedostoksi. Eclipse muotilee koodin jokaisen käännöksen (tallennuksen) yhteydessä. Versiohallinta toteutetaan code.goole.com -palvelun SVN-versiohallinnan avulla Liitteet Projektin backlog Java Code Style -template

7 Litteet Java Code Style template Change non static accesses to static members using declaring type Change indirect accesses to static members to direct accesses (accesses through subtypes) Convert for loops to enhanced for loops Remove unnecessary parentheses Remove unused imports Remove unused private methods Remove unused private constructors Remove unused private types Remove unused private fields Add missing annotations Add missing annotations Add missing serial version ID (generated) Remove unnecessary casts Remove unnecessary '$NON-NLS$' tags Add unimplemented methods Organize imports Format source code Remove trailing white spaces on all lines Correct indentation