PlugIT/TEHO Tutkimussuunnitelma jatkohankkeelle Teho-osaprojektin näkökulma on kliinisen sovelluksen tekijän näkökulma. Tutkimusalueena on sovellusliittymien ja sovelluskomponenttien hyödyntäminen. Tehtävänä on: Komponenttipohjaisen ohjelmiston tehokas ja luotettava tuotantoprosessi, Komponenttipohjaisen ja hajautetun ohjelmiston testaus, Ohjelmistotekniikan menetelmät, kuten mallinnus, rajapintojen dokumentointi, käänteistekniikat ja suunnittelumallit Rajapintamäärittelyjen ja kehitettyjen menetelmien pilotointi asiakasyrityksissä. TUTKIMUS JA MENETELMÄTUOTOKSET MÄÄRITYKSET Vuosi 2002: Komponenttiteknologiat Komponenttien tuotantoprosessi, Rajapintojen määrittely Testauksen automatisointi Hajautettujen järjestelmien Testitapausten määrittely testaus Ohjelmistotuotantoprosessi & testaus & jäljitettävyys Vuosi 2003: Kehitetyn menetelmän kokeilu Tuotteenhallinta, Oliokeskeisten ohjelmien testaus Käänteistekniikat Hajautettujen Regressiotestaus Suunnittelumallit järjestelmien testaus Virheenjäljitys Ohjelmistotuotantoprosessi &testaus & jäljitettävyys & komponentit Erillisjärjestelmien rajapinta määrittelyt suunnittelu ja pilotoinnin aloitus Määrittelyjen kokeilu ja dokumentointi Testitapaukset asiakasvaatimuksista Kehitettyjen menetelmätulosten pilotointi Kehitettyjen menetelmä ja määrittely tulosten dokumentointi Organisaatioiden väliset rajapinta määrittelyt suunnittelu ja pilotoinnin aloitus Määrittelyjen kokeilu ja dokumentointi Vuosi 2004: Kehitetyn menetelmän kokeilu Komponenttien muutoksen hallinta Hajautettujen järjestelmien testausmenetelmän kokeilu ja tarkennus Regressiotestaus menetelmän viimeistely ja testaus Ohjelmistotuotantoprosessi &testaus & regressiotestaus & jäljitettävyys & komponentit & hajautetut järjestelmät Julkaisujen viimeistely Kehitettyjen menetelmätulosten pilotointi Testitapaukset regressiotestaus Kehitettyjen menetelmä ja määrittely tulosten dokumentointi 1
Toinen ja kolmas jakso 1.5.2002-30.4.2003 Toisen ja kolmannen jakson aikana tutkitaan ohjelmistotuotantoprosessia ja määritellään tehokas ja taloudellinen komponenttipohjaisten ohjelmistojen tuotantoprosessi, joka testausta ja jäljitettävyyttä hyödyntäen varmistaa, että asiakasvaatimukset siirtyvät tuotteeseen ja tuote toimii luotettavasti. Tämä on tärkeää, koska nykyiset menetelmät eivät ota riittävästi huomioon perinnejärjestelmiä, valmiiden komponenttien käyttöä, jäljitettävyyden hyödyntämistä, rajapintamäärittelyjen mukaisesti toimimista, sekä prosessikuvausten hyödyntämistä komponenttien ja toimintarutiinien määrittelyssä. On kiinnitettävä huomiota myös ohjelmistotuotannon erilaisiin rooleihin. Sovelluksen kehittäjä, integraattori ja loppukäyttäjä hyödyntävät erilaisia testausmenetelmiä. Myös suunnittelumallien, sovelluskehysten ja arkkitehtuurityylien hyväksikäyttöä prosessin aikana kehitetään. Ohjelmistojen/komponenttien tuotantoprosessin lisäksi huomioidaan toimitusprosessi, ylläpito ja erityisesti muutoksenhallinta. PlugIT/TEHO osaprojektin ja yritysten välistä yhteistyötä tehostetaan. Pyritään löytämään toimintatapa, joka mahdollistaa joustavan tiedonkulun tutkimustuloksista yritysten käytännön toimintaan ja yritysten käytännön ongelmista tutkimusryhmälle. Tämä mahdollistaa sen, että tutkimusryhmä käsittelee oikeita asioita, mikä on hankkeen menestymisen ja tutkimustulosten hyödyntämisen kannalta olennaisen tärkeää. Komponenttipohjaisessa sovellustuotannossa rajapintamäärittelyt ovat keskeisessä asemassa. PlugIT/TEHO osaprojekti vetää erillisjärjestelmien välisten liittymien ja organisaatioiden välisten liittymien rajapintojen määrittelyn yhdessä näistä liittymistä kiinnostuneiden yritysten, sairaanhoitopiirien ja muiden osaprojektien kanssa. Samalla saadaan näkemystä komponenttien ja rajapintamäärittelyjen huomioon ottamiseksi tuotantoprosessin kehittämisessä. Rajapintojen testauksella voidaan lisätä ohjelmistojen toimintavarmuutta ja helpottaa virheen paikallistamista. Projektissa arvioidaan esi- ja jälkiehtojen sekä invarianttien käyttökelpoisuutta käytännön sovelluskehityksessä. PlugIT/TEHO osallistuu myös rajapintamäärittelyihin liittyvän teorian ja menetelmien kehittämiseen yhteistyössä kaikkien muiden PlugIT-hankkeen osaprojektien kanssa. Seuraavassa kuvaillaan jäljitettävyyteen ja testaukseen liittyviä tehtäviä erikseen. Jaksojen 2 ja 3 päätulos on testauksen ja jäljitettävyyden liittäminen kiinteäksi osaksi komponenttipohjaista ohjelmistotuotantoprosessia. JÄLJITETTÄVYYS OHJELMISTOTUOTANNON TUKENA PlugIT/TEHO ryhmän keskeisenä teemana on jäljitettävyys. Jäljitettävyys on tullut ohjelmistotuotantoon 1970-luvun jälkeen USA:sta kriittisten järjestelmien valmistuksen oheistuotteena. Jäljitettävyys voidaan määritellä suppeasti toiminnallisen määrittelydokumentin ja tuotteen välille tehtynä kaksisuuntaisena yhteytenä. Laaja määrittely lisää edelliseen vaatimusten määrittelyprosessin aikaisen työn, eli jäljitettävyys merkitsee osoitettavissa olevaa polkua asiakasvaatimuksista tuotteeseen tai komponenttiin ja takaisin. Jäljitettävyyden sisällöt on mahdollista tuottaa matalan tason menetelmin käyttämällä tavanomaista taulukkokirjanpitoa toimisto-ohjelmistojen avustamana. Tämä toimintatapa soveltuu pieniin ohjelmistoprojekteihin, joissa asiakasvaatimusten määrä on alle sata vaatimusta. Toimisto-ohjelmien 2
avulla toteutettuna jäljitettävyyden tuottaminen on hidasta ja vaatii merkittävää työpanoksen käyttöä menetelmien laadintaan ja käyttöönottoon. Korkeatasoinen jäljitettävyys saavutetaan käyttämällä monipuolisesti erikoisohjelmistoja ja multimediaa vaatimusten määrittelyssä, vaatimusten hallinnassa ja spesifikaatioiden laadinnassa. Myös notaatioiden väliset riippuvuudet on määriteltävä huolellisesti. Vaatimusten hallintaan ja jäljitettävyyden tuottamiseen on tänä päivänä olemassa runsaasti tietokoneohjelmistoja ja ohjelmistoperheitä, joiden avulla vaatimuksissa tapahtuvat muutokset voidaan jäljittää aina koodiin asti. Ohjelmistojen laajuus ja niiden avulla laaditun jäljitettävyyden taso vaihtelevat suuresti. Laajimmat ohjelmistot soveltuvat teollisten tuotantoprosessien hallintaan. Pienten yritysten käyttöön soveltuvien ohjelmistojen olemassaoloa tulisi kartoittaa. Kaikkea ei voida jäljittää, vaan on valittava olennaisimmat asiat, dokumentit ja tulokset. Näin menetellen ohjelmistojen muutoksenhallinta ja ylläpidettävyys tulee taloudellisemmaksi ja muutosten läpimenoaika lyhenee. Jäljitysasiaa on tutkittu myös OMG n piirissä, jossa on määritelty Model Driven Architecture (MDA). MDA:n kantavana ideana on erottaa systeemien toiminnalliset määrittelyt niihin liittyvistä erilaisista teknisistä toteutuksista. MDA:n avulla saadaan tuotettua pysyvämpiä ja paremmin uudelleenkäytettäviä ratkaisuja. MDA mahdollistaa myös mallien uudelleenkäytön ja ennen kaikkea säilyttää yhteyden analyysi- ja suunnitteluvaiheesta toteutukseen kuvaamalla säännöt, miten suunnittelumallit kuvautuvat eri toteutuksiksi. Jäljitettävyydellä ja testauksella on läheinen yhteys ohjelmistoprosessin sisällä. Jäljitettävyys tukee testausta ohjelmistovaatimusten oikeellisuuden ja ristiriidattomuuden todentamisessa. Testauksen ja vaatimusten välillä on oltava yhteys ja sitä ylläpidetään jäljitettävyyden avulla. 3
Komponenttiohjelmistotuotannon ongelmana pidetään yleisesti tuotteen pirstoutumista hallitsemattomaksi kokonaisuudeksi. Tämän lisäksi nopeasta muutosrytmistä aiheutuvat versioiden hallintaongelmat on ratkaistava. Jäljitettävyyden toteuttamisen suurimpia hyötyjä ovat tuotteenhallinnan ja muutoksenhallinnan kehittyminen. Jäljitettävyyden avulla pystytään osoittamaan: Mihin komponentteihin asiakasvaatimuksessa tapahtunut muutos vaikuttaa? Mihin asiakasryhmiin komponenttiin tehtävä muutos vaikuttaa? Sisältääkö tuote sopimuksessa määritellyt toiminnot oikein toteutettuina? Projektin toisessa ja kolmannessa jaksossa määritellään jäljitettävyyttä hyödyntäen prosessi ohjelmiston muutostenhallinnan tukemiseen ja tehokkaaseen muutosten toteuttamiseen. Tässä käytetään hyväksi myös ohjelmistojen uudistamisen ja takaisinmallinnuksen tuloksia. Muutostenhallinnan tärkeys korostuu, kun tuotetta myydään sadoille asiakkaille eri puolella maailmaa, jolloin joudutaan tekemään asiakaskohtaisia sovituksia maakohtaisten piirteiden toteuttamiseksi. Lisäksi tarkastellaan automaattisten Case-työvälineiden avulla tapahtuvaa vaatimusten määrittelyn ja jäljitettävyyden tarvetta ja toteutusta komponenttipohjaisessa ohjelmistotuotannossa. Ohjelmistojen uudistamiseen liittyvä tutkimus ja käänteinen suunnittelu sisältävät tuloksia, joita voidaan hyödyntää ohjelmistojen testauksessa, etenkin regressiotestauksessa. Käsitteet liittyvät kiinteästi myös jäljitettävyyteen, etenkin taaksepäin jäljitettävyyteen. Ohjelmistojen uudistamisessa (re-engineering) on kyse ohjelmiston ymmärrettävyyden ja laadun (ominaisuuksien kuten ylläpidettävyys, uudelleenkäytettävyys ja muutettavuus) parantamisesta. Uudistamista voidaan hyödyntää terveydenhuoltoalan vanhojen ohjelmistojen muokkaamisessa. Esimerkiksi Cobol-kielellä tehtyjä ohjelmistoja voidaan uudistaa Java- tai C++-kielelle, ja siten helpottaa niiden ylläpitoa. Ohjelmistojen uudistamisen eräs osa-alue on käänteistekniikka eli takaisinmallinnus (reverse engineering). Takaisinmallinnus tähtää ohjelmistojen ymmärrettävyyden (program comprehension) parantamiseen. Takaisinmallinnuksen avulla voidaan lähdekoodin ja olemassa olevan dokumentaa- 4
tion avulla selvittää ohjelmiston vaatimukset. Takaisinmallinnuksessa analysoidaan järjestelmää sekä tunnistetaan sen osat sekä osien väliset suhteet ja sen jälkeen luodaan ohjelmistosta abstraktiotasoltaan korkeampi (tai muulla tavalla erilainen) kuvaus. Eli esimerkiksi ohjelmakoodista voidaan luoda UML-kuvauksia (luokka- tai sekvenssikaavioita ja näistä taas muita kaavioita). Tätä voidaan käyttää hyväksi regressiotestauksessa. Jos ohjelmakoodista saadaan johdettua ohjelmiston suunnittelun pohjalla olleet kaaviot, ollaan onnistuttu ohjelmiston muuttamisessa. Tätä ja mahdollisia olemassa olevia välineitä tämän toteuttamiseen tulee tutkia lisää, jotta niistä pääsevät hyötymään myös terveydenhuollonjärjestelmiä tuottavat pienet ja keskisuuret yritykset. OHJELMISTOJEN TESTAUS Testauksen osalta projektin toinen ja kolmas jakso etenevät pääosin alkuperäisen suunnitelman (kts. liite 1) mukaan. Suunnitelmaa kuitenkin tarkennetaan seuraavasti: Käytetty komponenttiteknologia (esim EJB-, CORBA) ja ohjelmistojen hajautus tuo sovellusten testaamiseen omat haasteensa. Hajautettujen ohjelmistojen testausta aletaan tutkia jaksolla kaksi ja tutkimus kestää jakson kolme loppuun. Tavoitteena on määritellä tehokas, kattava ja taloudellinen menettely hajautettujen ohjelmistojen testaamiseen. Tässä otetaan huomioon, että ohjelmistoja rakentavat ryhmät ovat Suomessa usein pieniä (< 30 henkilöä), jolloin testausmenetelmän tulee olla mahdollisimman selkeä, yksinkertainen ja vähätöinen. Menettelytavan määrittelyn jälkeen tuloksia testataan käytännön toimintaympäristössä. PlugIT/TEHO ryhmässä toivotaan, että kokeilun järjestämiseen löytyy yritys, kunhan menetelmä kuvaus saadaan pilotointivaiheeseen. Hajautettujen ohjelmistojen testaukseen liittyvät seuraavat ongelmat: Palvelujen hallinnan testaus heterogeenisessa ympäristössä (nimipalvelun testaus). Miten palvelut löydetään heterogeenisessa ympäristössä? Kun tarkastellaan useiden organisaatioiden välistä yhteistoimintaa ja eri hajautettujen teknologioiden integrointia keskeiseksi kysymykseksi nousee samanaikaisuuden hallinnan oikeellisuus. Käsitys siitä, mikä on tiedon oikea arvo, pitää säilyä vaikka tietoa käsiteltäisiin ja päivitettäisiin useissa eri pisteissä ja ohjelmissa. Tiedon ristiriidattomuuden toteutuminen tapahtumapohjaisissa järjestelmissä, kun käytössä on useita erilaisia tekniikoita ja useita tietokantoja. Autentikointi ja tietoturvavaatimusten toteutuminen. Käyttäjäoikeuksien ristiriidattomuuden toteutuminen heterogeenisessa ympäristössä. Kaksi edellistä kysymystä korostuvat työpöytäintegraatiossa, jossa käytössä on ns. single sign-on, eli käyttäjän tunnistus tapahtuu keskitetysti, jonka jälkeen useat järjestelmät käyttävät tätä tunnistusta. Useimmissa nykyaikaisissa järjestelmissä on käytössä useita tietokantoja ja monet palvelut vaativat tietojen tallentamista samaan aikaan useisiin tietokantoihin (esim. pankkitilin päivitys). Useita tietokantoja käytetään esimerkiksi tehokkuussyyistä tai skaalautuvuuden mahdollistamiseksi. Tietojen päivitys täytyy onnistua jokaiseen paikkaan, muutoin toimintoa ei voida toteuttaa. Tämä asettaa haasteita testaukselle Erillisjärjestelmien ja organisaatioiden välisen tiedonkulun testaus on esimerkki rajapintojen toiminnan testauksesta. Pääpaino testauksessa asetetaan perinnejärjestelmien ja uusien järjestelmien yhteistoimivuuden testaukseen, siten että integrointivaiheen jälkeen voidaan varmistua järjestelmän kokonaistoiminnasta. Tässä vaiheessa tehdään yhteistyötä PlugIT/Ydin-osaprojektin kanssa. Lisäksi rajapintojen 5
testauksessa tehdään yhteistyötä muiden osaprojektien kanssa. Testauksen määrittelyssä saatuja tuloksia hyödynnetään pilotointivaiheessa rajapintojen toiminnan testauksessa. Ensimmäisen jakson aikana osoittautui, että testitapausten suunnittelu ja kehittäminen on tärkeä kysymys, joka vaikuttaa olennaisesti testauksen ja tulevien ohjelmistojen laatuun sekä koko tuotantoprosessin tehokkuuteen. Testitapausten valinnan tärkeys korostuu etenkin regressiotestauksen kohdalla. Koska toisessa ja kolmannessa jaksossa selvitetään tuotantoprosessia ja neljännessä ja viidennessä jaksossa regressiotestausta, kulkee testitapausten kehittämisteema mukana koko projektin ajan. Testitapausten muodostamista rakeisten komponenttien tapauksessa on esitelty raportissa How to derive test cases from user requirements. Testauksen automatisointi tutkimusta jatketaan suorittamalla löydettyjen ohjelmistojen arviointi loppuun. Tavoite on selvittää kuhunkin ohjelmistotuotantovaiheeseen parhaiten sopivat välineet. Samalla hahmottuu se, antavatko olemassa olevat välineet riittävästi tukea hajautettujen komponenttipohjaisten sovellusten testaukseen ja miten välineitä tulee kehittää, jotta niistä saadaan riittävä tuki. Keskeisiä selvitettäviä kysymyksiä ovat: Miten automatisoidaan? Mitä automatisoidaan? Eri menetelmät ja tuotantoprosessin vaiheet. Työkalujen ryhmittely testauksen V-mallin eri vaiheisiin. Automatisoidun testauksen elinkaaren malli (ATML). Milloin voidaan ja kannattaa automatisoida? Automatisoinnin hyödyt ja kustannukset? Miten testauksen työkalut valitaan? Miten arvioidaan eri työkaluja? Ostetaanko vai rakennetaanko työkalu itse? Miten parannetaan työkalujen hallittavuutta? Menestystarinat ja epäonnistumiset automatisoinnissa. Yrityskyselyn avulla selvitetään tällä hetkellä Suomessa käytössä olevia työkaluja, testauksen tasoa ja automatisoinnin laajuutta. Uudet ohjelmat on usein toteutettu oliokeskeisellä ohjelmointikielellä (esim. Java- tai C++ ), tämä tuo testaukseen omat lisäpiirteensä. Oliokeskeisissä sovelluksissa on perinteisiin ohjelmiin verrattuna suurempi määrä erilaisia riippuvuuksia. Komponenttiajattelu takaa sen, että kerralla tarkasteltava luokkien määrä ei ole suuri, mutta periytyminen ja olioiden välisen viestinvälityksen oikeellisuus on joka tapauksessa testattava. Olioiden tiloja tarkastelemalla voidaan myös varmistaa ohjelmiston oikeellisuutta ja toimintavarmuutta. Projektin ensimmäisen jakson aikana löytyi runsaasti materiaalia oliokeskeisten sovellusten testaamiseen liittyen. Kolmannen jakson aikana laaditaan selvitys oliokeskeisten ohjelmien testauksesta. Sekä toisen että kolmannen jakson lopuksi tarkistetaan tutkimussuunnitelma vastaamaan tutkimuksessa saavutettua uutta näkemystä. PlugIT/TEHO jakson 2 tulokset Toinen jakso: 1.5.2002-31.10.2002 Ohjelmistotuotantoprosessin määrittely siten, että testaus ja jäljitettävyys on liitetty prosessiin joustavalla ja tehokkaalla tavalla. Käytännönläheinen ehdotus, joka kuvaa, miten jäljitettävyysajatusta voidaan tehokkaasti ja taloudellisesti hyödyntää ohjelmistotuotannossa pienissä ja keskisuurissa ohjelmistotaloissa kuvattaessa notaatioiden välisiä riippuvuuksia. 6
Selvitys testauksen automatisointimenettelyistä. Alustava kartoitus hajautettujen ohjelmistojen testaukseen liittyvästä tutkimuksesta. Tieteellisiä julkaisuja 1-2, muita julkaisuja 1-2, raportteja 1-2, pro graduja 1-2 Jakson 3 suunnitelman tarkennus. PlugIT/TEHO jakson 3 tulokset Kolmas jakso: 1.11.2002-30.4.2003 Ohjelmistotuotantoprosessin tarkennus siten, että komponenttiajattelu on siinä mukana. Hajautettujen ohjelmistojen testausmenettely valmis versio käytännössä testattavaksi. Selvitys ohjelmistojen muutoksenhallintamenettelyn kehittämisestä jäljitettävyyden avulla. Selvitys ohjelmistojen uudistamiseen liittyvän teorian käyttömahdollisuuksista. Oliokeskeisten ohjelmistojen testauksen määrittely. Asiakasvaatimusten pohjalta määritellyt testitapaukset. Jäljitettävyyden automatisointimahdollisuuksien selvitys. Tieteellisiä julkaisuja 2-3, muita julkaisuja 1-2, raportteja 1-2, pro graduja 1-3 Tarkennettu suunnitelma jaksoja 4 ja 5 varten. PlugIT/TEHO jaksojen 4 ja 5 suunnitelma Jakso 4 ja 5: 1.5.2003-31.4.2004 Jaksojen 4 ja 5 tutkimuksen suuntaaminen tehdään jaksojen 2 ja 3 tulosten perusteella. Keskeisessä asemassa on kuitenkin regressiotestausmenettelyn määrittely ja sijoittaminen osaksi ohjelmistotuotantoprosessia. Tässä hyödynnetään ohjelmistojen uudistamisen tutkimustuloksia. Tärkeää on huomioida testitapausten suunnittelu ja regressiotestauksen testitapausten valinta alkuperäisten testitapausten joukosta. Tärkeää on myös panostaa riittävästi virheenjäljityksen kehittämiseen. Jaksolla 2 ja 3 määriteltyä hajautettujen ohjelmistojen testausmenettelyä kokeillaan käytännössä. Jäljitettävyys tutkimuksessa tarkastellaan ohjelmistojen toimittamiseen ja versiohallintaan liittyvää jäljitettävyyttä. Tehtävänä on hallita asiakkaiden tuotekonfiguraatiot, jotta ohjelmistopäivitykset voidaan toimittaa oikeassa aikataulussa ja luotettavasti. Jaksolla 4 ja 5 arvioidaan käytännössä jäljitettävyyttä ja testausta tukevaa komponenttipohjaista tuotantoprosessia sekä tehdään menetelmään tarvittavat korjaukset. Vuosittain julkaistaan kansainvälisissä konferensseissa tai lehdissä tieteellisiä julkaisuja 3-5, muita julkaisuja esimerkiksi ammattilehdissä 2-4, raportteja 2-4, pro graduja 3-4. Tutkimusjakson päättyessä vuonna 2004 valmistuu 2-3 filosofian lisensiaatin tutkintoa. 7
PlugIT/TEHO Kuudennen jakson 1.5.2004-31.8.2004 suunnitelma Viimeistellään projektin aikana saavutetut tulokset ja laaditut dokumentit, jotka sisältävät hajautettujen komponenttipohjaisten sovellusten rakentamiseksi käytännönläheisen menetelmäkuvauksen testausta ja jäljitettävyyttä hyväksikäyttävästä ohjelmistotuotantoprosessista, joka varmistaa asiakasvaatimusten toteutumisen lopputuloksena saatavassa tuotteessa. 8
Liite 1 Integraatiotestauksen tutkimussuunnitelma Anne Eerola, Tanja Toroi Kuopion yliopisto, Tietojenkäsittelytieteen ja sovelletun matematiikan laitos Hannele Toroi, Deio Tutkimuksen tavoitteena on kehittää yhteistyöyritysten toimintaperiaatteita ja yhteisiä pelisääntöjä ja ratkaisuja ohjelmistotuotantoon, laadunvarmistukseen ja testaukseen. Tämä lisää yritysten tuotteiden integroitavuutta ja mahdollistaa kokonaisuuden integraatiotestauksen. 1. Lähtötilanne Projektissa oletetaan, että käytetään iteratiivista ja inkrementaalista ohjelmistokehitysprosessia ja V-mallin mukaista sovellustuotantoa. Tämä tarkoittaa, että koko isoa ohjelmistoa ei valmisteta ja toimiteta monoliittisena yhtenä isona sovelluksena, vaan sovellusrakenne jaetaan autonomisiin ja itsenäisiin komponentteihin, joilla on selkeät rajapinnat. Liikkeellelähtö tapahtuu ohjelmistolle asetettujen vaatimusten määrittelyllä. Tämän vaiheen ohjelmistokehittäjät tekevät yhteistyössä asiakkaiden tai tuotekehityksestä vastaavien asiantuntijoiden kanssa. Vaatimusten hallinnan tulee olla dynaamista siten, että tulevat kehitystrendit ja visiot huomioidaan ja vaatimukset kehittyvät ja muuttuvat tuotteen elinkaaren aikana. Koska vaatimukset ovat muuttuvia, täytyy säilyttää yhteys ohjelmistokehitysprojektin väli- ja lopputulosten ja vaatimusten välillä. Näin tiedetään, mihin ohjelmiston osaan yksittäinen muutos vaikuttaa, mihin muihin vaatimuksiin muutos vaikuttaa ja ketkä ovat ominaisuuksien asiakkaina. Vaatimukset mallinnetaan käyttötapauksilla ja luokkakaavioilla. Asiakasvaatimusten perusteella suunnitellaan ohjelmiston arkkitehtuuri ja komponenttien vastuut. Kaikkia komponentteja ei tarvitse valmistaa itse, vaan osa kannattaa hankkia yhteistyöyrityksiltä tai alihankkijoilta. Tämä lyhentää ohjelmiston valmistamisaikaa, ohjelmisto saadaan nopeammin markkinoille, valmistuskustannukset pienenevät ja kuormitushuiput tasaantuvat. Komponenttiteknologia mahdollistaa myös erikoistumisen, eli yritys voi valmistaa ja myydä niitä komponentteja, joissa yrityksen asiantuntemus on paras. Valmis kokonainen sovellus muodostetaan integroimalla itse tehtyjä komponentteja yhteistyöyrityksiltä hankittujen ostettujen komponenttien kanssa. Myös kokonaisten sovellusten välinen integraatio on suunniteltava ja toteutettava, jotta vältytään turhalta päällekkäisyydeltä (esim. potilastietojen hallinta on erikseen jokaisessa sairaalan sovelluksessa). Ohjelmistokehitys pitää saada mahdollisimman nopeaksi. Tästä seuraa, että rajapinnat, joiden avulla komponenttia käytetään, pyritään julkistamaan mahdollisimman aikaisessa vaiheessa. Näin yhteistyökumppanit saavat jo omien sovellustensa suunnitteluaikana tietoa siitä, millaisia komponentteja toiset ovat valmistamassa. Ideaalitilanteessa komponentin valmistaja toimittaa komponentin mukana välipalvelimen, jonka komponentin käyttäjä voi rakentamisaikana liittää omaan ohjelmistoonsa. Kun toimitaan edellä kuvatussa ympäristössä ja käytetään valmiita komponentteja tai valmistetaan komponentteja yhteistyökumppaneille, laatuvaatimukset ovat korkeat, eli komponentin pitää toimia 9
niin kuin sopimuksessa on määritelty ja täyttää niin toiminnalliset kuin ei-toiminnallisetkin vaatimukset. Myös komponenttiin liittyvien rajoitusten pitää olla selkeästi määritelty. Tällöin keskeiseksi asiaksi nousee ohjelmistojen ja komponenttien testaus ja laadunvarmistus. Myös komponenttien integrointi ja sovellusten yhteentoimivuus on testattava. Tämä tutkimus tapahtuu PlugIT- hankkeen yhtenä osana. Tutkimuksella on kiinteä ja tiivis yhteys FixIT/DoIT- hankkeeseen, jossa on määritelty terveydenhuollon tietojärjestelmien tavoitearkkitehtuuri ja jossa tutkitaan komponenttien toteutukseen ja eri teknologisiin vaihtoehtoihin liittyviä ratkaisuja. Lisäksi tutkimuksella on kiinteä yhteys THT/Sotlab:iin asiakasvaatimusten määrittelyn ja analyysin kehittämisessä. 2. Tavoitteet Projektissa tarkastellaan systeemien ja komponenttien integraatiota tavoitteena määritellä, kuvata ja testata vientikelpoisia ratkaisuja integrointiongelmaan. Vientikelpoisten ohjelmistojen tuotantoprosessilta edellytetään seuraavia asioita: 1. Vaatimustenhallinnan tulee olla dynaamista siten, että käsitys tuotteen ominaisuuksista täsmentyy ja kehittyy vallitsevien trendien mukaisesti. Vaatimukset on määriteltävä selkeästi ja toimialan tärkeimpiä tavoitteita painottaen. Näistä vaatimuksista on kyettävä valmistamaan vaatimukset täyttävä sovellus. Näin siinäkin tapauksessa, että asiakas tai tuotekehityshenkilöstö ei kykene määrittelemään tarpeitaan muodossa, jota teknisesti orientoitunut atk-ammattilainen ymmärtää helposti. 2. On suunniteltava laadukas ja taloudellinen ohjelmistotuotantoprosessi. Tuotteiden laadun varmistaminen on aloitettava sovelluksen elinkaaren alkuvaiheessa. Tällöin puhutaan yleensä tarkastuksesta. Asiakasvaatimuksista edetään analyysi-, suunnittelu- ja rakentamisvaiheiden kautta kohti vaatimukset täyttävää tuotetta siten, että edellisen vaiheen tulos (vaihetuote) on seuraavan vaiheen syöte ja jokaisen vaiheen jälkeen varmistetaan, että välitulos toteuttaa sille asetetut vaatimukset. Prosessin välituloksia havainnollistetaan asiakkaalle aikaisessa vaiheessa prototyyppien avulla. Tällaisessa ohjelmistotuotantoprosessissa (V-malli), syntyy eritasoisia kuvauksia, kuten käyttötapauskaaviot, luokkakaaviot, skenaariot, arkkitehtuurikuvaukset, komponenttikaaviot, vuorovaikutuskaaviot ja lopulta ohjelmakoodi. Myös valmiiden ohjelmakoodien testaus tapahtuu vaiheittain moduulitestaus, integrointitestaus, järjestelmätestaus ja hyväksymistestaus. Taloudellinen ohjelmistotuotantoprosessi tarkoittaa, että tulokset saadaan valmiiksi mahdollisimman nopeasti ja mahdollisimman pienillä kustannuksilla. Tässä auttavat tehtävien priorisointi, valmiiden ohjelmisto-osien hankinta ja turhan byrokratian välttäminen tuotantoprosessissa. Testaus on työläs ja aikaa vaativa prosessi. Jotta toimintaa saadaan tehostettua on kyettävä automatisoimaan testauksesta ne vaiheet, jotka ovat toistuvia ja jotka voidaan suorittaa koneellisesti. Huolellisimmin on testattava ohjelmiston ydinosat, koska niiden toimivuus vaikuttaa useisiin sovelluksiin. Erityistä huomiota on kiinnitettävä myös käyttäjän määrittelemiin kriittisiin ohjelmisto-osiin. Jäljitettävyyden avulla voidaan seurata polkua vaatimuksista tuotteeseen ja päinvastoin tuotteesta asiakkaisiin. Edelleen jäljitettävyyden avulla voidaan selvittää tuotteen edellisiä vaiheita, kun testauksessa havaitaan ongelmia. Ylläkuvatun kaltainen ohjelmistotuotantoprosessi on teoriassa määritelty, mutta siinä on seuraavat ongelmat: -Komponenttien tuotantoprosessia ei ole tuettuna, -Prosessi on liian raskas sovellettavaksi pienissä (noin 20-30 henkeä) ohjelmistotuotantoyksiköissä, 10
-Eri mallien ja kuvausten riippuvuudet toisistaan on epätäsmällisesti määritelty niin teoriassa kuin käytännön ohjelmistotyössäkin, -Tarkastusta ja testausta ei ole integroitu kiinteästi ohjelmistotuotantoprosessiin. Tämän mahdollistamisessa jäljitettävyys antaa hyvän välineen. 3. Asiakasvaatimusten perusteella määritellään sovelluksen arkkitehtuuri ja ratkaisussa tarvittavat komponentit. Tämän jälkeen tehdään päätös, mitä komponentteja valmistetaan itse ja mitä hankitaan ulkopuolelta. Jotta tämä onnistuisi on tiedettävä ostettavissa olevien komponenttien ominaisuudet. Tässä komponentti on mustalaatikko ja komponentin kuvauksen (rajapintamäärittely) pitäisi olla niin selkeä, että siitä selviää komponentin toiminnalliset ja laadulliset ominaisuudet. Myös komponenttiin liittyvät rajoitukset on kuvattava selkeästi ja komponentin käyttöä tulisi havainnollistaa esimerkein. Yritysverkostot voivat tässä tehostaa yhteistyötään yhtenäistämällä ja standardoimalla sopimusten ja rajapintamäärittelyjen sisältöä. 4. Kun komponentti hankitaan, tarvitaan ympäristö (ajuri), joka mahdollistaa komponentin testauksen erillisenä komponenttina. Näin saadaan varmuus, että komponentti toimii rajapintamäärittelyjen mukaisesti ja on hankittu asiakasvaatimukset täyttävä komponentti. Tämä testaus on niin sanottua mustalaatikkotestausta. Kun komponentti valmistetaan itse on testattava, että komponentti toimii niin kuin rajapinnassa on määritelty. Näin varmistetaan komponentin laatu ja toimivuus ennen julkistusta. Tätä kutsutaan lasilaatikkotestaukseksi. 5. On suunniteltava ja kehitettävä ympäristö, joka mahdollistaa systeemien ja komponenttien integraation testaamisen. Liikkeellelähtö voi tapahtua esim. rajapintojen testauksella, jolloin on huomioitava rajapinta loppukäyttäjiin, toisiin komponentteihin (provides interface, uses interface), komponentin suoritusympäristöön (laitealusta, teknologia yms.) ja toisiin systeemeihin. Rajapinta kutsujan ja kutsutun välillä määritellään sopimuksella, mutta lopullinen hyväksymistesti voi tapahtua vain todellisessa ympäristössä ja todellisten käyttäjien toimesta. Integroinnissa on huomioitava komponenttien yhteistoiminnallisuus ja eri komponenttiteknologioiden käyttömahdollisuudet. Integrointitestauksen nopeuttamiseksi kannattaa valmistaa tyngät niistä komponenteista, jotka eivät ole valmiina. 3. Testaus ideaalitilanteessa Testaus on prosessi, jonka avulla suunnitellaan, toteutetaan ja mitataan tietojärjestelmän ominaisuuksia ja verrataan niitä asetettuihin vaatimuksiin. Testaus tapahtuu siis aina vaatimuksia vasten. Yleensä enemmän kuin puolet virheistä syntyy vaatimustenmäärittelyvaiheessa. Jotta virheiden leviäminen ohjelmistoon estettäisiin pitää tulosten validoinnin ja testauksen tapahtua heti sovelluksen elinkaaren alkuvaiheissa. Tätä tukee V-malli-pohjainen lähestymistapa, jossa kunkin vaiheen tulokset tarkastetaan ennen kuin toimintaa jatketaan seuraavasta vaiheesta ja jossa sovellusta määriteltäessä asetetaan sovelluksen hyväksymiskriteerit. Jokaisessa ohjelmiston kehitysvaiheessa tehdään siis vastaavat testausvaiheen suunnitelmat. Suunnitelmien tekemiseen osallistuvat sekä ohjelmoijat että testaajat, jotta vaatimusten testattavuusnäkökulma otettaisiin huomioon. Kaikki tärkeimmät dokumentit tarkastetaan tarkastusmenetelmän (katselmointi) avulla. Ainakin vaatimustenmäärittelydokumentti on tarkastettava sekä testisuunnitelmat. Tarkastuksessa käytetään apuna tarkastuslistoja, joihin kootaan useimmin esiintyvät virheet ja niiden aiheuttajat. Näin virheet löytyvät jo mahdollisimman aikaisessa vaiheessa ja virheiden korjauskustannukset pysyvät mahdollisimman pieninä. Tarkastusprosessiin osallistujille kerrotaan, mihin tarkastuksen idea perustuu ja osallistujat motivoidaan huolella. Tarkastuskokouksessa pyritään pääsemään synergia etuun, jolloin virheitä löydetään enemmän kuin jokainen on yksin löytänyt. 11
Yritykselle laaditaan dokumentointiohjeet. Dokumentointiohjeissa kerrotaan, mitä dokumentteja tuotetaan jokaisesta testausprosessista sekä millainen on dokumenttien ulkoasu. Yhtenäiset dokumentit helpottavat eri osapuolten työtä. Testauksesta täytyy toimittaa myös virheraportit, joissa virheet ryhmitellään eri ryhmiin ja luokitellaan vakavuuden perusteella. Vakavimmat virheet korjataan aina, kosmeettiset virheet voidaan jättää korjaamatta, jos aikaa ja resursseja ei ole tarpeeksi. Kaikki virheet täytyy kuitenkin kirjata ylös. Testaajat ovat ammattitaitoisia, koulutettuja tehtäviinsä. Ohjelmoijat voivat myös olla testaajana, jos yrityksessä ei ole pelkästään testaukseen erikoistuneita työntekijöitä. Tärkeää on kuitenkin testaajien ammattitaito. Myös yritysjohto on sitoutettava testausprosessiin. Tämä varmistaa sen, että testaamiseen saadaan tarvittavat resurssit: aikaa, työntekijöitä ja rahaa. Tämän tutkimuksen tulokset ovat hyödyllisiä yritysten yhteistoiminnan kehittämisessä. Samoin alihankintayhteyksien hoitoon saadaan tietoa. Tätä tarkastellaan seuraavissa kappaleissa testauksen kannalta. 3.1 Komponentin toimittajan näkökulma testaukseen Komponentin toimittajan on varmistettava, että valmistettu tuote toimii rajapintamäärittelyjen ja voimassa olevan sopimuksen mukaisesti. Tässä voidaan hyödyntää lasilaatikkotestausta, koska ohjelman sisäinen rakenne ja koodi ovat testaajalla käytettävissä. Lasilaatikkotestauksen ideana on käydä läpi mahdollisimman paljon ohjelman eri polkuja. Silloin tutkitaan ohjelman kontrollivirtaa eli kuinka ohjelman kontrolli haarautuu eri ehtosolmuissa (if, while, repeat ). Apuna tässä on erilaiset kattavuuskriteerit, jotka voidaan valita testauksen lähtökohdaksi (lause-, päätös-, ehto- ja moniehtokattavuus). Kattavuuskriteerit kuvaavat, kuinka kattavasti ohjelman eri suorituspolkuja on testattu. Lausekattavuus on kriteereistä heikoin, moniehtokattavuus tehokkain. Kattavuuskriteeriksi kannattaa valita moniehtokattavuus. Täydellistä moniehtokattavuutta ei välttämättä saavuteta, mutta testauksen lopetuskriteeriksi voidaan valita esim. 80% moniehtokattavuus. Lasilaatikkotestauksessa voidaan tutkia myös ohjelman tietovirtaa eli mitä ohjelman eri muuttujille tapahtuu ohjelman suorituksen aikana. Myös tietovirtatestauksessa on eri kriteerejä, joihin testaus voidaan perustaa (esim. all-definition-, all-uses- ja all-du-path-kriteeri). Kriteerit helpottavat testitapausten valintaa ja testauksesta saadaan tehokkaampaa kuin valitsemalla testitapaukset satunnaisesti. Lasilaatikkotestausta kannattaa siis tehdä sekä ohjelman kontrollivirralle että tietovirralle. Oliokeskeisiä sovelluksia testattaessa on huomioitava jokaisen luokan - Metodien ja attribuuttien testaus, joka tapahtuu edellä kuvattuja lasilaatikkomenetelmiä käyttäen. - Olioiden tilojen testaus, joka tapahtuu tilakaavioiden avulla. - Luokkien periytymisen testaus, joka tapahtuu luokkakaavion avulla. Lisäksi on testattava luokkien olioiden välinen yhteistoiminta eli viestinvälitys ja assosiaatiot. Lasilaatikkotestauksen päätyttyä menestyksellisesti toimittaja käyttää mustalaatikkotestausta, jolloin koodi ei ole nähtävissä, ja varmistaa, että tuote, joka julkistetaan toimii rajapintamäärittelyjen mukaisesti. 12
3.2 Komponentin käyttäjän näkökulma testaukseen Komponentin käyttäjälle hankittu ohjelmisto-osa on mustalaatikko. Ohjelman toteutus ja sisäinen rakenne eivät siis ole testaajan käsillä. Testitapausten muodostaminen pohjautuu siten rajapintamäärittelyihin, toimittajan kanssa tehtyyn sopimukseen ja komponentista laadittuun käyttäjille tarkoitettuun kuvaukseen. Tämän vuoksi on erittäin tärkeää, että komponenttiin liittyvät kuvaukset on laadittu huolella ettei asiakkaan tarvitse testata vääriä määrittelyjä vastaan. Mustalaatikkotestauksen menetelmiä ovat ekvivalenssiositus sekä raja-arvoanalyysi. Koska kaikkia mahdollisia syötteitä on todellisuudessa mahdoton testata, täytyy ohjelmiston syöteavaruus jakaa luokkiin (ekvivalenssiluokkiin). Yhteen luokkaan kuuluvat syötteet käyttäytyvät kaikki samankaltaisesti. Jokaisesta luokasta valitaan vähintään yksi arvo suoritukseen. Raja-arvoanalyysin perusteella tiedetään, että syötteiden ja esim. silmukoiden raja-alueet ovat erittäin virhealttiita tilanteita. Jokaisesta ekvivalenssiluokasta valitaan syötteeksi sekä rajatapauksia että luokan keskellä olevia arvoja. Näin syöteavaruus saadaan haravoitua tarpeeksi tarkalla tasolla, vaikka kaikkia mahdollisia syötteitä ei testatakaan. Mustalaatikkotestauksen onnistumiseen vaikuttaa se, onko luokat osattu muodostaa oikein. Mustalaatikkotestauksella ei useinkaan löydetä virheitä, jotka ovat piiloutuneet syvälle ohjelmakoodiin. Toisaalta menetelmällä löydetään virheet, jotka liittyvät asiakkaan vaatimuksiin. 3.3 Komponentin jatkokehitys ja testaus Järjestelmän päivitys hoidetaan tietyin väliajoin, ei jatkuvasti. Ohjelmistokehityksessä käytetään versionhallintaohjelmistoa, jonka avulla ohjelmiston ja komponenttien eri versioista ja konfiguraatioista pidetään kirjaa. Regressiotestaukselle laaditaan ohjeistus, jonka mukaan ohjelman muuttuneet versiot testataan. Regressiotestauksessa kannattaa käyttää automaattista työkalua testitapausten ajamisessa sekä testitapausten valinnassa ja tallennuksessa. Kaikkia olemassa olevia testitapauksia ei ajeta automaattisesti uudelleen vaan testitietokannasta valitaan tietyt, muuttunutta ohjelman osaa testaavat testitapaukset sekä testitapaukset, joihin muutos vaikuttaa. Lisäksi voidaan joutua tekemään uusia testitapauksia, jotka testaavat ohjelmaan lisättyjä uusia ominaisuuksia. Komponenttien ja konfiguraatioiden regressiotestaus on mielenkiintoinen ongelma niin käytännön ohjelmistotuotannon kuin teoreettisenkin tutkimuksen kannalta. 4. Testauksen automatisointi Testaus tarvitsee tuekseen hyvät jäljitettävyysapuvälineet. Tämä tarkoittaa, että asiakasvaatimuksen elinkaarta on kyettävä seuraamaan läpi sovelluksen analyysin, suunnittelun, rakentamisen, käyttöönoton ja ylläpidon. Jäljitettävyyttä varten on kehitetty eritasoisia välineitä, kuten käyttötapauspuut, luokkakuvausten navigointivälineet sekä erilaiset dokumentti- ja rakennekeskeiset välineet. Tutkimuksissa ja käytännön työvälineissä ei kuitenkaan ole yhdistetty testausta ja jäljitettävyyttä tehokkaasti toisiinsa. Myöskään komponentteihin liittyviä jäljitysongelmia ei ole analysoitu, suunniteltu ja ratkaistu. Ideaalitilanteessa olisi voimassa seuraava: - Loppukäyttäjän vaatimuksen muuttuessa päästään navigointipolkua pitkin komponentteihin, joihin muutosehdotus vaikuttaa. - Muutosehdotuksen alaisena olevasta komponentista päästään jäljitettävyyden avulla taaksepäin loppukäyttäjiin ja komponentin asiakkaisiin ja voidaan ratkaista, miten hyvin ehdotettu muutos sopii toisille komponentin käyttäjille. 13
Testauksessa käytetään apuna erilaisia automatisointityökaluja. Välineitä on olemassa paljon (satoja), mutta niiden laatu ja sopivuus käyttötarkoitukseen vaihtelee suuresti. Apua on ainakin testauksen hallinnan työkalusta, joka tallettaa testitapaukset ja testimateriaalin testitietokantaan ja etsii oikeat testitapaukset regressiotestausta varten. Testitapausten ajamiseen kannattaa myös hankkia työkalu, joka vähentää testaajan tekemää toistuvaa yksitoikkoista testausta. Testitapausten kattavuutta kannattaa myös tutkia ja hankkia sellainen työkalu, joka hoitaa tutkimisen automaattisesti. Kaikkea ei kuitenkaan automatisoida, ainoastaan sellaiset vaiheet, joiden automatisoinnista on jotakin hyötyä pitkällä tähtäimellä. Järjestelmätestaus ja hyväksymistestaus suoritetaan asiakkaan tiloissa. Testaajia on sekä ohjelmiston toimittajan puolelta että käyttäjiä asiakkaan puolelta. Jos mahdollista, käyttäjiä olisi hyvä palkata testaajiksi myös yrityksen sisälle. Näin käytettävyysnäkökohdat tulisi huomioitua jo aikaisemmissa testausvaiheissa. Testaamista pitää tarvittaessa tehdä kellon ympäri, jotta voidaan varmistua, että järjestelmä toimii myös öiseen aikaan esim. vuorokauden vaihtuessa. Tätä voidaan mahdollisesti automatisoida. Testauksen laadun parantamisessa käytetään apuna mittareita. Mittarit antavat vastauksia esim. seuraavanlaisiin kysymyksiin: Kuinka kauan testausvaiheet kestävät? Kuinka paljon virheitä löytyy tietyssä vaiheessa? Kuinka tehokasta testaus on? Mittausten avulla pystytään myös pitämään kirjaa suunniteltujen testien suorittamisesta. Onko kaikki suunnitellut testit suoritettu ja läpäisty vai onko testejä suorittamatta tai läpäisemättä? 5. Testauksen käytännön ongelmia Edellä on kuvattu, kuinka testausprosessi etenisi ideaalitilanteessa. Käytännössä testauksessa esiintyy kuitenkin seuraavanlaisia ongelmia. - Asiakkaan vaatimukset kirjoitetaan liian yleisellä tasolla ja ilman testauksen tukea, joten vaatimuksia vastaan on mahdoton testata. Spesifikaatiot taas kirjoitetaan liian teknisesti, jolloin käyttäjänäkökulma unohdetaan. Tähän voisi olla apuna testaajien ottaminen mukaan määrittelyjen laatimiseen sekä käyttäjänäkökulmaan panostaminen. Spesifikaatiot on kirjoitettava asiakkaan kielellä. Yritykselle on muodostettava dokumentointiohjeet. - Testitapausten taso on huono. Testitapaukset eivät testaa komponenttia kattavasti ja samoja alueita käydään läpi useaan otteeseen. Lisäksi testitapaukset eivät sisällä kaikkea informaatiota, mitä niiden tulisi sisältää (syötteet, oikeat tulokset, tarvittavat testiympäristö ja apuohjelmat ). Testaajien pitäisi siis olla ammattitaitoisia, koulutettuja testaukseen. Apuna pitäisi myös käyttää kattavuustyökaluja, jotka tutkivat, kuinka kattavasti komponenttia on testattu. Testitapausten dokumentointiohjeet. Ohjeet testausprosessin läpiviemiseen. - Testauksen suunnittelun hankaluudet johtuvat ohjelmistoprojektien huonosta hallinnasta, aikataulut ovat ympäripyöreitä ja liian epätarkkoja. Toisaalta aikataulut on vedetty niin tiukalle, ettei niissä anneta testaajille hengähdystaukoa. - Testaukset kasaantuvat kaikki yhteen ajankohtaan, jolloin resursseja ei ole riittävästi. Resurssit on varattu alkuperäisen aikataulun mukaan, joten projektien myöhästyminen sotkee testaajien aikatauluja. Testauksen suunnitteluun ja organisointiin pitäisi panostaa. - Testiympäristöjen ylläpito on hankalaa, koska tekniikka kehittyy nopeasti. - Ohjelmakoodi vaihtuu liian useasti, korjauksia tehdään pitkin matkaa. Tuotekehityksen pitäisi tehdä korjaukset ryppäissä ja antaa rauha testaajille. Virheraportointiin pitää panostaa. Raporttien tulee olla sellaisia, että kehittäjät tietävät, mikä on vikana ja osaavat paikantaa vian ilman testaajan apua. 14
- Testauksen optimointi. Turhat ja päällekkäiset testit pitää poistaa. Kattavuustyökalu ja testauksen huolellinen suunnittelu. - Automatisoinnin puute. Valitaan muutama hyvä työkalu, joista on oikeasti hyötyä testauksessa ja joiden käyttöönotto ei vaadi liikoja. - Komponenttiohjelmistojen testaus. Komponenttiteknologia on uutta käytännön ohjelmistotuotannossa eikä sitä vielä osata välttämättä käyttää. Komponenttien testaus asettaa omat ongelmat varsinkin integrointitestaukselle, kun ei tiedetä, missä kaikissa mahdollisissa ympäristöissä komponenttia tullaan käyttämään. - Regressiotestaus aiheuttaa omat murheensa testaukselle. Ohjelmakoodin muuttumisen jälkeen on tiedettävä, mitä ohjelman osia on testattava uudelleen. Jäljitettävyys ohjelmakoodista vaatimuksiin ja vaatimuksista ohjelmakoodiin. 6. Mitä tutkimuksessa tehdään? Tutkimuksessa kehitetään yhteistyöyritysten tuotteiden integraatiotestausta. Tavoitteet saavutetaan seuraavien osatehtävien avulla (kts. Liite 2): - ohjelmistotuotantoprosessin kehittäminen tuotekehityksen vaatimukset huomioiden; mitä vaiheita, mitä missäkin vaiheessa tapahtuu, dokumentointiohjeet, - testausprosessin määrittäminen; testausprosessin pitää olla taloudellinen ja helppo toteuttaa käytännössä, - jäljitettävyyden hyväksikäytön mahdollisuuksien selvittäminen, - testauksen, tarkastuksen ja jäljitettävyyden yhdistäminen toisiinsa dynaamiseksi, joustavaksi ja luotettavaksi tuotantoprosessiksi, - testauksen automatisointityökalututkimus, sen selvittäminen millainen työkalun pitäisi olla, - testausvaiheiden sisältö komponenttimaailmassa: moduulitestaus, integrointitestaus, järjestelmätestaus, hyväksymistestaus, - komponenttien regressiotestaus; mitä osia komponenteista on testattava muutoksen jälkeen sekä missä ympäristössä testaus tapahtuu, - yhteenveto ja lopputulosten raportointi. 7. Tutkimuksesta saatavat hyödyt ja tulokset Tutkimus mahdollistaa yhteistyöyritysten yhteisten pelisääntöjen ja toimintaperiaatteiden kehittämisen ohjelmistotuotantoon, laadunvarmistukseen ja testaukseen. Ohjelmistotuotantoprosessin kehittyminen ja testauksen nivoutuminen kiinteästi tuotantoprosessiin - parantaa tuotteiden laatua ja kilpailukykyä, - on välttämättömyys tuotteiden integroinnille, - varmistaa vaatimusten toteutumista, - mahdollistaa komponenttien myynnin ja hankinnan, - lisää prosessin hallittavuutta ja vähentää kuormitushuippuja, koska virheet ja poikkeamat tavoitteista havaitaan varhaisessa vaiheessa, jolloin korjaaminen on mahdollista ja edullisempaa. Ohjelmistotuotannon hallittavuus ja taloudellisuus paranee jäljitettävyyden kehittämisen avulla. Kun tiedetään entistä paremmin, millä asioilla on riippuvuuksia, ei tarvitse tehdä kaikkia mahdollisia testejä. Jäljitettävyyden vaatimus tullee nousemaan tulevaisuudessa entistä tärkeämmäksi sairaaloiden tietojärjestelmissä, joilta edellytetään suurta luotettavuutta. 15
Yritysten ohjelmistotuotannossa pystytään reagoimaan nopeasti ja dynaamisesti asiakasvaatimusten ja tuotekehitysideoiden mukaan kohdealueen kehitystrendit huomioiden. Testausprosessin hallittavuus ja taloudellisuus paranee testauksen ja testitapausten suunnittelun ja automatisoinnin avulla. Yritykset saavat uutta hyödynnettävää tietotaitoa regressiotestauksesta, komponenttien testauksesta ja integrointitestauksesta, mikä mahdollistaa luotettavan sovellusten yhteistoiminnan. Tutkimuksen yhteydessä suoritetaan seuraavat ohjelmistotekniikan jatkotutkinnot: - Tanja Toroi, FL v. 2003 ja - Tomi Tikkanen, FL v. 2004. 8. Raportointi Tutkimuksen tulokset julkaistaan selvityksinä, jotka ovat yhteistyöyritysten käytettävissä. Tieteelliset tulokset julkaistaan kansainvälisissä tieteellisissä lehdissä ja konferensseissa. Yhteistyöyritysten kanssa järjestetään teemapäiviä, joissa keskustellaan tuloksista ja suunnitellaan projektin jatkotoimenpiteitä. Kirjallisuusluettelo Beizer B.: Black Box Testing Techniques for Functional Testing of Software and Systems. John Wiley & Sons, 1995. Beizer B.: Software Testing Techniques, 2 nd Ed. Van Nostrand Reinhold, 1990. Chen, H. Y., Tse, T. H., Chan, F. T. - Chen, T. Y. 1998: In Black and White: An Integrated Approach to Class-Level Testing of Object-Oriented Programs. ACM Transactions on Software Engineering and Methodology, Vol. 7, No. 3, July 1999, s. 250-295. Cook, J. E., Wolf, A. L. 1999: Sofware Process Validation: Quantitive Measuring the Correspondence of a Process to a Model. ACM Transactions on Software Engineering and Methodology, Vol. 8, No. 2, April 1999, s. 147-176. Demillo, R. A., Offut, J. A.: Experimental Results from an Automatic Test Case Generator. ACM Transactions on Software Engineering and Methodology, Vol. 2, No. 2, April 1993, s. 109-127. Devanbu, P. T., Rosenblum, D. S., - Wolf, A. L.: Generating Testing and Analysis Tools with Aria. ACM Transactions on Software Engineering and Methodology, Vol. 5, No. 1, January 1996, s. 42-62. Doong, R., Frankl, P. G.: The ASTOOT Approach to Testing Object-Oriented Programs. ACM Transactions on Software Engineering and Methodology, Vol. 3, No. 2, April 1994, s. 101-130. Fewster, M., Graham, D.: Automating Software Testing: Effective use of Test Execution Tools, Addison-Wesley, 1999. 16
Gilb, T., Graham, D.: Software Inspection. Addison-Wesley, 1993. Harrold, M. J., Gupta, R., Soffa, M. L. 1993: A Methodology for Controlling the Size of a Test Suite. ACM Transactions on Software Engineering and Methodology, Vol. 2, No. 3, July 1993, s. 270-285. Herzum, P., Sims, O.:Busines Component Factory. John Wiley & Sons, 1999. Howden, W. E., Huang, Y.: Sofware Trustability Analysis. ACM Transactions on Software Engineering and Methodology, Vol. 4, No. 1, January 1995, s. 36-64. Humphrey, W.: Introduction to the Team Software Process. Addison-Wesley,1999. Jacobson, I., Booch, G., Rumbaugh, J.: The Unified Software Development Process. Addison- Wesley, 1998. Jeng, B., Weyuker, E. J.: A Simplified Domain-Testing Strategy. ACM Transactions on Software Engineering and Methodology, Vol. 3, No. 3, July 1994, s. 254-270. Kaner C., Falck J., Nguyen H.: Testing Computer Software, 2 nd Ed. John Wiley & Sons, 1993. Kit, E.: Software Testing in the Real World. Addison-Wesley, 1995. Koomen, T., Pol, M.: Test Process Improvement. Addison-Wesley, 1999. Kung, D., Hsia, P, Gao, J: Testing Object-Oriented Software. IEEE Computer Society, 1998. Myers, G. J.: The Art of Software Testing. John Wiley & Sons, 1979. Perry, W.: Year 2000 Software Testing. John Wiley & Sons, 1999. Podgurski, A., Masri, W., Mccleese, Y., Wolff, F.G., Yang, C.: Estimation of Software Reliability by Stratified Sampling. ACM Transactions on Software Engineering and Methodology, Vol. 8, No. 3, July 1999, s. 263-283. Pol, M., van Veenendaal, E.: Structured Testing of Information Systems. Kluwer, 1998 Pong, F., Dubois, M.: Verification Techniques for Cache Coherence Protocols. ACM Computing Surveys, Vol. 29, No. 1, March 1997, s. 119-126. Porter, A., Siy, H., Mockus, A., Votta, L.: Understanding the Sources of Variation in Software Inspections. ACM Transactions on Software Engineering and Methodology, Vol. 7, No. 1, January 1998, s. 41-79. Reiss, S. P.: Software Tools and Environments. ACM Computing Surveys, Vol. 28, No. 1, March 1996, s. 281-284. Rothermel, G., Harrold, M. J.: A Safe, Efficient Regression Test Selection Technique. ACM Transactions on Software Engineering and Methodology, Vol. 6, No. 2, April 1997, s. 173-210. Roper, M.: Software Testing. McGraw-Hill, 1994. 17
Schach, S. R. 1996: Testing: Principles and Practice. ACM Computing Surveys, Vol. 28, No. 1, March 1996, s. 277-279. Weyuker, E. J.: Using Failure Cost Information for Testing and Reliability Assessment. ACM Transactions on Software Engineering and Methodology, Vol. 5, No. 2, April 1996, s. 87-98. Zhu, H., Hall, P. A. V., May, H. R. 1997: Software Unit Test Coverage and Adequacy. ACM Computing Surveys, Vol. 29, No. 4, December 1997, s.366-427. 18
Liite 2 ID Task Name Duration Start 1 Projektin aloitus 0 days Mon 1.10.01 2 Tuotantoprosessin määrittäminen 3 mons Mon 1.10.01 3 Testausprosessin määrittäminen 3 mons Mon 1.10.01 4 Jäljitettävyys 4 mons Wed 2.1.02 5 Tulosten analysointi 4 mons Wed 24.4.02 6 Testauksen ja jäljitettävyyden yhdistäminen 6 mons Thu 12.9.02 7 Automatisointityökalututkimus 13,79 mons Mon 1.10.01 8 Yhteentoimivuustestaus 6 mons Mon 29.7.02 9 Tulosten analysointi 4 mons Wed 22.1.03 10 Testausvaiheiden sisältö komponenttimaailmassa 8 mons Thu 15.5.03 11 Komponenttien regressiotestaus 8 mons Mon 3.11.03 12 Raportointi 35,04 mons Mon 1.10.01 13 Yhteistyöyritysten tuotteiden integrointitestaus 35,04 mons Mon 1.10.01 14 Yhteenveto 3 mons Tue 8.6.04 15 Projektin lopetus 0 days Tue 31.8.04 2002 2004 Sep Nov Jan Mar May Jul Sep Nov Jan Mar May Jul Sep Nov Jan Mar May Jul Sep 1.10 26.3.2002 31.8 19