T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä 28.10.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi Kirjoittajat Matti Kannala matti.kannala@hut.fi Muutokset PVM Tekijä Versio Selitys 27.10.2002 Matti Kannala 0.9 Dokumentti PP-vaiheen palautukseen 28.10.2002 Iiro Ojala 1.0 Dokumentin yhtenäistäminen 24.11.2002 Matti Kannala 1.1 Dokumentin yhtenäistäminen 30.11.2002 Matti Kannala 2.0 T1-vaiheen kokemukset 09.02.2003 Matti Kannala 3.0 T2-vaiheen kokemukset 21.03.2003 Matti Kannala 4.0 T3-vaiheen kokemukset 14.04.2003 Matti Kannala 5.0 LU-vaiheen kokemukset 1
Sisällysluettelo 1 Yleistä... 3 2 projektissa... 3 3 Vaatimusten hyväksyminen ja testaus... 4 4 Käyttöönottsuunnitelma... 4 5 Käyttöönotto kokemukset... 4 5.1 T1-vaihe... 4 5.2 T2-vaihe... 5 5.3 T3-vaihe... 6 5.4 LU-vaihe... 6 6 Lähteet... 6 2
1 Yleistä Vaatimukset ovat järjestelmän toimintoja, ominaisuuksia ja rajoituksia. on systemaattinen menetelmä vaatimuksien löytämiseen, dokumentointiin, organisointiin ja muutosten hallintaan. a tehdään koko projektin ajan. Vaatimusten määrittely Määrittely & Suunnittelu & Ohjelmointi & Testaus Hyväksymistestaus Vaatimusten hallinta 2 projektissa Tässä projektissa vaatimukset kerätään asiakastapaamisissa ja projektiryhmän palavereissa. Kaikille vaatimuksille annetaan yksilöllinen tunnus ja ne dokumentoidaan vaatimuslistaan. Vaatimuslista on yksinkertainen lista vaatimuksista tunnisteineen. Listasta jalostetaan käyttäjävaatimusdokumentti, johon toiminnalliset vaatimukset kirjataan käyttäjätapauksina ja ominaisuudet sekä rajoitukset kirjataan normaaleina vaatimuksina. Käyttäjävaatimusdokumentissa on vaatimusten lisäksi määritelty käyttäjäryhmät ja vaatimuksien prioriteettivaihtoehdot. Jokaiselle vaatimukselle määritellään molemmat näistä. Vaatimusten priorisointi tehdään Priorization scales - menetelmällä [1]. Käyttäjävaatimusdokumentissa on lisäksi kerrottu vaatimuksienmuutosprosessi ja vaatimuksientoteutumisen mittaamiseen käytettävät mittarit. Vaatimustenmäärittelyn jälkeen alkaa varsinainen vaatimustenhallinta. Keskimäärin 50% vaatimuksista tulee muuttumaan projektin aikana [2]. Vaatimustenhallinnassa ei käytetä mitään erityistä siihen tarkoitettua ohjelmistoa vaan käytössä on Microsoft Word 2000 ja tavallinen tekstieditori. Vaatimustenhallinnassa muutosehdotus käy läpi seuraavan prosessin: 1. Tehdään muutosehdoitus (mahdollisimman tarkka esitys) 2. Analysoidaan muutosehdoitus (vaikutus, kustannus, hyöty) 3. Tehdään päätös muutoksesta (sopimus asiakkaan kanssa) 4. Tehdään muutos (dokumentin päivitys, tiedotus) 3
3 Vaatimusten hyväksyminen ja testaus Projektisuunnitelma-vaiheen loputtua vaatimusmääritelmä hyväksytetään asiakkaalla ja samalla sitoudutaan noudattamaan vaatimuksia toimitettavassa tuotteessa. Sen jälkeen vaatimustenhallinnassa jokainen muutos vaatimuksiin käy läpi vaatimustenmuutosprosessin. Vaatimuksia, varsinkin käyttäjätapauksia käytetään tuotteen testien määrittelyyn. Näistä tärkein on vaatimuksien kannalta hyväksymistestaus, joka perustuu tarkasti vaatimuksiin. Sen avulla voidaan todeta onko tuote toteuttanut sille annetut vaatimukset ja onko se hyväksyttävä toimitettavaksi. 4 Käyttöönottsuunnitelma otettiin käyttöön projektissa heti projektin alettua. Projektin alkuvaiheessa vaatimustenhallinta oli lähinnä niiden keruuta ja vaatimusdokumentin kirjoittamista. Vaatimusten keruussa oli käytössä yksinkertainen teksti-editori, jolla asiakastapaamisissa tulleet vaatimukset listattiin. Vaatimustenkeruuta varten olisi kannattanut tehdä jonkinlainen kaavake, johon olisi ollut helppo syöttää vaatimuksia. Hyvä ratkaisu olisi ollut esimerkiksi HTML-kaavake, joka postittaa syötetyn vaatimuksen niiden kerääjälle. Seuraavassa vaiheessa alkaa varsinainen vaatimustenhallinta. Vaatimuksiin alkaa tulla muutoksia. Vaatimusten muutosehdoituksia varten tehdään HTML-lomake, jonne asiakas tai ryhmän jäsen voi syöttää muutosehdoituksen. Muutos ehdoitukset analysoidaan ryhmän viikkopalavarissa. Sen jälkeen niistä tehdään päätös asiakkaan kanssa asiakastapaamisessa. Lopuksi, jos päätös on myönteinen, muutetaan käyttäjävaatimusdokumenttia ja ilmoitetaan kaikilleosapuolille muutoksesta. 5 Käyttöönotto kokemukset 5.1 T1-vaihe Projektin suunnitteluvaiheessa kirjoitettuun käyttäjävaatimusdokumenttiin tuli muutoksia vain vaiheen alkupuolella. Asiakas antoi heti vaiheen alussa laajan palautteen, joka sisälsi korjaus- ja muutosehdoituksia. Pari ryhmän jäsentä kävi palautteen läpi ja sen jälkeen palaute käsiteltiin ryhmän viikkopalaverissa. Joitakin hieman epäselviä kohtia tarkennettiin asiakkaalta samaisen palaverin loppupuolella, jolloin asiakas oli myös paikalla. Lopuksi käyttäjävaatimusdokumenttiin tehtiin palaverin päätösten mukaiset muutokset. Lisäksi muutokset kirjattiin ylös dokumentissa niitä varten tarkoitettuun kappaleeseen. HTML-lomakketta ei käytetty tässä vaiheessa kertaakaan. Toisaalta asiakkaan palautteen lisäksi ei muita muutosehdoituksia tullut ja palautteen asioita olisi ollut turha lomakkeella kautta kierrättää. 4
Muutokset käyttäjävaatimusdokumenttiin T1-vaiheessa: Lisätty lokaaleihin valaistusmalleihin käyttötapaus valojen liikuttamisesta. Lisätty kaikkien visualisointien toimintoihin käyttötapaukset visualisointiohjelman ja yksittäisen visualisoinnin käynnistämisestä Lisätty käyttötapaus materiaalikirjastosta Varjot-visualisoinnin nimi muutettu Globaaleiksi valaistusmalleiksi ja prioriteetti laskettu suositeltavaksi Perustransformaatioiden prioriteettiä nostettu välttämättömäksi Lisätty kuva käyttöliittymän prototyypistä Dokumentti yhtenäistetty 5.2 T2-vaihe Projektin suunnitteluvaiheessa kirjoitettuun käyttäjävaatimusdokumenttiin tehtiin yksi suurempi päivitys vaiheen loppupuolella. Päivityksessä ei tullut yhtään uutta vaatimusta vaan olemassaoleviin vaatimuksiin tehtiin lisäyksiä ja poistoja. Asiakaspalavereissa esilletulleet muutosehdotukset kerättiin muistioista ja kirjattiin käyttäjävaatimusdokumenttiin, joka lähetettiin asiakkaalle hyväksyttäväksi. Hyväksynnän jälkeen muutokset tehtiin dokumenttiin ja ne kirjattiin myös ylös dokumentissa niitä varten tarkoitettuun kappaleeseen. HTML-lomakketta ei käytetty tässäkään vaiheessa kertaakaan. Muutokset käyttäjävaatimusdokumenttiin T2-vaiheessa: Lisäyksiä vaatimuksiin: o R503 Ohjelman käynnistyessä pitää visualisaation avautua automaattisesti. o R514 Visualisaation avaamisessa pitää näkyä selostus visualisaatiosta. o R509 Nauhoitus voi alkaa mistä nauhan kohdasta tahansa ja nauhoiteesta pitää voida poistaa pätkiä. Nauhoittaessa keskelle nauhan loppuosa siirtyy eteenpäin. o R607 Lokaalit valaistusmallit visualisaatiossa pitää myös valojen parametreja pystyä muuttamaan. o R407 3D-primitiiveissä pitää olla nuoliprimitiivi. Poistoja vaatimuksiin: o R514 Visualisaation avaamisessa ei syötetä tiedoston nimeä o R503, R508, R607, R606, R619 Visualisaation ei tarvitse tukea objektien valintaa hiiren kursorilla. Objektin valinta pitää olla kuitenkin mahdollista jotenkin. o R619 Valojen liikuttelu hiirellä ei ole vaadittua. 5
5.3 T3-vaihe Projektin suunnitteluvaiheessa kirjoitettuun käyttäjävaatimusdokumenttiin ei tehty muutoksia. Vaatimukset pysyivät siis samoina. Kaikki käyttötapaukset käytiin läpi ja niiden toteutumista vaiheen loppuun mennessä arvioitiin. Kaikki välttämättömät käyttötapaukset näyttivät toteutuvat ja samoin yli puolet suositeltavista käyttötapauksista. Näyttää siltä, etttä tuote tulee todennäköisesti kattamaan hyväksynnän vaatimukset. Vaatimukset, jotka näyttävät jäävät tuotteessa toteutumatta o R402 Visualisointi splineistä o R403 RIB-formaatin tuottaminen o R404 Objektikirjasto o R405 Tekstuurikirjasto o R408 Materiaalikirjasto o R603 A-puskurin visualisointi 5.4 LU-vaihe Projektin luovutusvaiheessa ei vaatimuksiin tehty enää muutoksia. Aktiviteettina vaatimustenhallinnassa oli lähinnä vaatimusten toteutumisen seuranta, testaaminen ja hyväksyntä. Hyväksyntätestaus tehtiin suoraan käyttävaatimusten käyttötapausten avulla. Tuote hyväksyttiin. Seuraavat vaatimukset jäivät lopullisesta tuotteesta toteuttamatta o R402 Visualisointi splineistä o R403 RIB-formaatin tuottaminen o R404 Objektikirjasto o R408 Materiaalikirjasto o R603 A-puskurin visualisointi oli minusta hyvä valinta kurssin henkilökohtaiseksi menetelmäksi. Siitä on varmasti hyötyä myös työelämässä. Käyttötapauslähtöinen vaatimustenhallinta on minusta todella hyvä vaatimustenhallintamenetelmä, jota aion käyttää myös tulevaisuudessa. 6 Lähteet [1] QURE-projekti (Quality through Requirements), 16.11.2001 [2] G. Kotonya and I. Sommerville, Requirements Engineering Processes and Techiques, John Wiley & Sons, New York, 1998 6