SOPIMUS ASIAKAS- JA POTILASTIETOJÄRJESTELMÄSTÄ
SOPIMUS ASIAKAS- JA POTILASTIETOJÄRJESTELMÄSTÄ
Liite H Projektimenetelmät
VERSIOHISTORIA
Päivä | Versio | Kuvaus | Tekijä |
12.3.2015 | 3.0 | Tarjouspyynnön liite | Hanketoimisto |
24.4.2015 | 3.01 | Tarjouspyynnön liite Korjattu kielioppivirheitä. Korjattu / tarkennettu kappaleita: 3.2.1, 3.2.2.1, 5.2.2.1, 5.2.4, 5.2.5, 5.4, 6.3, 6.4.2 | Hanketoimisto |
Sisällysluettelo
1 Johdanto ja dokumentin tarkoitus 5
2.1 Projektinhallinnan prosessit 5
2.3 Projektien elinkaarimalli, prosessiryhmät ja projektinhallinnan alueet 6
2.4 Projektinhallinnan roolit ja vastuut projektin elinkaarella 9
2.5 Projektisuunnittelu yleisesti 11
2.7 Ratkaistavien asioiden hallinta 14
2.9 Aikataulusuunnittelu ja -seuranta, valmiusasteseuranta 21
2.12 Resurssisuunnittelu ja -seuranta 23
2.13 Viestintä ja sidosryhmähallinta 23
2.16 Hyötyjen ja muutoksen johtaminen 25
2.17 Projektien hyväksyminen ja lopettaminen 25
3 Käyttäjäkeskeinen suunnittelu 26
3.1 Käyttäjäkeskeisen suunnittelun periaatteet ja prosessi 26
3.2 Käyttäjäkeskeisen suunnittelun soveltaminen 27
4 Ketterä ohjelmistokehitys 35
5.1 Testauksen laajuus ja lähestymistapa 37
5.4 Testausprosessi ja havaintojen luokittelu 47
5.5 Testiympäristöt ja niiden hallinta 50
5.7 Testaustyövälineet ja tuki 51
5.9 Testausrooli ja vastuut 53
5.10 Konfiguraation hallinta testauksen aikana 56
5.11 Tuotettava dokumentaatio 57
5.12 Testauksen vastuunjako 58
6 Julkaisun- ja konfiguraationhallinta 64
6.4 Julkaisun- ja konfiguraationhallinnan roolit ja vastuut 68
7 Projekteissa käytettävät ohjelmistotyökalut 70
1 Johdanto ja dokumentin tarkoitus
Tässä dokumentissa
• kuvataan ylätason projektimenetelmät, jotka ovat voimassa sekä Toimitussopimuksen että Palvelusopimuksen alaisissa projekteissa.
• asetetaan vaatimuksia projekteissa noudatettavista hallintamenettelyistä. Tämä dokumentti on toissijainen projektikohtaisiin sopimuksiin ja suunnitelmiin nähden, mutta tämän dokumentin ehtoja noudatetaan, mikäli muuta ei ole sovittu.
2 Projektinhallinta
2.1 Projektinhallinnan prosessit
Koska kyseessä on mittava ja haastava toiminnan muutos-, kehitys- ja IT-hanke, näkee Asiakas laadukkaan projektinhallinnan keskeisenä keinona riskien vähentämiseen. Tämän vuoksi myös Järjestelmätoimittajalta edellytetään laadukasta projektinhallintaa. Projektinhallinnassa noudatetaan Asiakkaan määrittelemiä työmenetelmiä ja -prosesseja, ellei toisin ole yhteistyössä sovittu. Järjestelmätoimittaja sitoutuu ylläpitämään ja aktiivisesti kehittämään käyttämiään työmenetelmiä, käytäntöjä ja prosesseja.
Projektimenetelmistö pohjautuu kansainvälisiin malleihin (Prince2 ja PMBoK), joita on mukautettu hankkeen tarpeisiin. Pohjalla oleva kansainvälinen projektinhallinnan viitekehys varmistaa yhteisen kielen projektipäälliköiden kesken.
Luvussa 2 määrittelyt asiat koskevat kaikkia hankinnan laajuudessa olevia projekteja ja osaprojekteja, riippumatta siitä, miten toteutus- ja käyttöönottovaihe tullaan jakamaan osaprojekteihin. Asiat ovat voimassa myös Palvelusopimuksen alaisissa Erillisprojekteissa
2.2 Projektin alkaminen
Tämä luku koskee Erillisprojekteja. Palvelusopimuksen mukaisista Erillisprojekteista sovitaan Asiakkaan ja Järjestelmätoimittajan kesken Palvelusopimuksen ehtojen mukaisesti.
• Asiakas ja Järjestelmätoimittaja allekirjoittavat projektisopimuksen Erillisprojektista. Tässä vaiheessa sovitaan esim. käytettävä hinnoittelumalli sekä määrätään reunaehdot kiinteähintaiselle budjetille (budjetti, aikataulu, tuotokset) tai ei-kiinteähintaiselle projektille asetetaan tavoitteet, budjetti ja aikataulu.
• Asiakas ja Järjestelmätoimittaja pitävät järjestäytymiskokouksen, jossa sovitaan yhdessä projektin aikataulua, sisältöä (luonnetta ja laajuutta), tarvittavaa osaamista ja resursointia, kustannuksia ja tuloksia koskevista seikoista sekä sovitaan projektisuunnitelman laadinnasta ja sisällöstä
• Projektisuunnitelma hyväksytään käynnistyskokouksessa, jossa varmistetaan molemmin puolin yhteinen ymmärrys toimeksiannon tavoitteista, tehtävistä, työnjaosta, vastuista työskentelymenetelmistä ja kommunikointitavoista sekä viestinnästä
• Projektisuunnitelman hyväksymisen jälkeen projektin aikana tulevat mahdolliset ongelmat aikataulun, sisällön, henkilöresurssien tai kustannusten osalta tai yhteistyön sujumisessa on otettava esille
välittömästi, kun jompikumpi osapuoli tunnistaa tilanteen. Ongelmat raportoidaan Asiakkaan ja Järjestelmätoimittajan yhteyshenkilöille ja käsitellään projektipalavereissa
2.3 Projektien elinkaarimalli, prosessiryhmät ja projektinhallinnan alueet
Vaatimus: Projekteissa ja osaprojekteissa noudatetaan seuraavassa kuvassa (Kuva 1) esitettyä elinkaarimallia.
Malli jakaa yksittäisen projektin elinkaaren neljään päävaiheeseen: Projektin valmistelu, projektin suunnittelu, projektin toteutus ja projektin lopetus. Vaiheita erottavat toisistaan päätöksentekopisteet, joita kutsutaan porteiksi (P0–P4). Porttipäätökset, eli luvat edetä seuraavaan vaiheeseen tehdään ns. projektisalkunhallinnan tasolla, Apotti-hankkeessa se tarkoittaa hankkeen johtoryhmää. Koska moni projekti on pitkään ennen alkamistaan osana hankkeen pitkän tähtäimen suunnitelmaa, jää P0-portti tyypillisesti pois. P1-portti on näin ollen ensimmäinen formaali päätös projektin toteuttamisesta. P1-päätökseen mennessä projektille on formuloitu tavoitteet (kuten hyötytavoite, lopputulostavoite, aikataulutavoite, kustannustavoite), jotka ovat dokumentoitu ns. asettamiskirjeeseen. Tässä kohtaa on myös valittu projektin toteutusmalli, eli esimerkiksi toteutetaanko projekti ketterillä menetelmillä tai esimerkiksi vesiputousmallilla vai suunnitellaanko toteutus aivan erikseen, mikäli kyseessä on hyvin uniikki projekti.
Kuva 1 Projektin elinkaarimalli
Projektin suunnitteluvaiheen tarkoitus on vastata kysymykseen, miten tavoitteisiin päästään kaikkein tehokkaimmalla tavalla. Myös tavoitteiden realistisuus varmistetaan tässä vaiheessa. Kuvaan on piirretty punaisella projektinhallinnan neljä pääprosessia, jotka limittyvät keskenään ja jatkuvat yli vaiheitten. Esimerkiksi asettamisprosessi jatkuu vielä projektin suunnitteluvaiheessa, sillä tavoitteita voidaan joutua muuttamaan projektisuunnittelun tuodessa lisää tietoa tavoitteiden realistisuudesta. Projektisuunnitteluvaiheen tulokset dokumentoidaan projektisuunnitelmaan, joka hyväksytään P2-portissa, joka on lähtölupa projektin toteutukselle.
Tähän mennessä projektin toteutuksen vaatimat resurssit on myös oltava suunniteltuina. Lisäksi yhtenä prosessina on Erillisprojektin sopimuksen laadinta ja allekirjoittaminen, mutta tämä koskee vain Erillisprojekteja.
Projektin suunnitteluprosessi kuitenkin jatkuu, sillä kaikissa projekteissa tulee vastaan poikkeamia ja muutoksia, jotka tarkoittavat, että jäljellä oleva osa projektista pitää suunnitella ainakin osittain uudelleen. Pitkissä projekteissa tehdään myös rullaavaa, tarkentavaa suunnittelua toteutusvaiheen aikana. Pitkissä projekteissa voi olla myös tarpeen nostaa projekti uudestaan projektisalkunhallinnan tasolle etenemispäätökseen. Tätä havainnollistaa Kuva 1 harmaalla piirretty P2.N-päätös. P2-päätöksessä päätetään, mikäli projekti on pitkä eikä riittävän ennustettava, tuodaanko projekti kerran tai useammin projektisalkkutason päätökseen projektin toteutusvaiheen aikana.
Toteutusvaiheessa aktivoituu myös projektin toimeenpanon, seurannan ja ohjauksen prosessi. Seurannassa tilannetta verrataan suunnitelmaan eli baselineen1 (joka on P2-päätöksessä hyväksytty). Mikäli poikkeamia on, ennustetaan, kuinka paljon ne vaikuttavat projektin loppuun mennessä ja ryhdytään tarvittaviin toimenpiteisiin poikkeamien korjaamiseksi.
Pääosa projektin varsinaisesta sisällöllisestä tekemisestä tehdään projektin toteutusvaiheessa. Elinkaarimallissa on erotettuna tekemisen taso projektinhallinnan tasosta. Tämä tarkoittaa sitä, että projektinhallinnan taso säilyy mallissa samanlaisena riippumatta projektin sisällöstä ja valitusta toteutusmenetelmästä. Projektin sisällöstä kuitenkin merkittävästi riippuu, miltä toteutuksen taso näyttää. Tyypillisesti toteutus on syytä jakaa joihinkin vaiheisiin, jotka päättyvät virstanpylväisiin eli välietappeihin (milestoneihin). Virstanpylväät toimivat projektin ohjausryhmälle paikkana tarkistaa tulokset ja edistyminen. Kuva 2 esittää erilaisia toteutuksen vaiheistusmalleja sovitettuna samaan projektin elinkaarimalliin.
1 Baseline on SFS-ISO 21500 -standardissa suomennettu seuraavasti: Vertailukohta (baseline)= vertailun lähtökohta, jonka avulla projektin suorituskykyä seurataan ja valvotaan.
Kuva 2 Esimerkkejä erilaisista toteutustason vaiheistusmalleista
P3-portti on päätös tai toteamus siitä, että kaikki projektin lopputulokset ovat valmiina. Tätä seuraa vielä lyhyt projektin lopetusvaihe, jossa varmistetaan, että kaikki tulokset on siirretty linjaorganisaation käyttöön (tai seuraaville projekteille). Toisaalta mietitään, mitä projektista voidaan oppia. Projektin lopettamisprosessin voi toki aloittaa jo toteutusvaiheen aikana. Isoissa ja pitkissä projekteissa näin kuuluukin toimia. Lopetusvaiheen tulokset dokumentoidaan vielä projektin loppuraporttiin, joka hyväksytään portissa P4, joka sulkee projektin.
Projektille merkitään kustannuksia ja tunteja välille P1–P4. Valmisteluvaihe on hanketason työtä tai mikäli kyseessä on osaprojekti, pääprojektin työtä.
2.3.1 Projektinhallinnan prosessit ja projektinhallinnan osa-alueet
Projektinhallinnan neljä pääprosessia sisältävät kymmenen eri osa-aluetta2, jotka ovat listattu alla olevassa taulukossa. Alla oleva Taulukko 1 Projektinhallinnan prosessit ja projektinhallinnan osa-alueet linkittää osa-alueet tämän dokumentin osioihin.
2 vrt. PMI PMBoK, jossa tunnistetaan viisi prosessiryhmää, joista tässä mallissa toisiinsa yhdistetty Executing- ja Controlling - ryhmät. PMBoK:n Knowledge Area:ihin lisätty Hyötyjen ja muutoksen johtaminen.
Taulukko 1 Projektinhallinnan prosessit ja projektinhallinnan osa-alueet
Projektinhallinnan pääprosessit: Projektin- hallinnan osa-alueet: | Projektin asettamis- prosessi | Projektin suunnitteluprosessi | Projektin toimeenpanon, seurannan ja ohjauksen prosessi | Projektin lopettamis- prosessi |
Yleishallinta | Osio 2.3 | Osio 2.5 Projektisuunnittelu yleisesti | Osio 2.6 Edistymisraportointi Osio 2.7 Ratkaistavien asioiden hallinta | Osio 2.17 |
Laajuudenhallinta | Osio 2.8 Laajuudenhallinta Osio 2.8.1 ja 2.8.2 Vaatimustenhallinta Osio 2.83 ja 2.8.4 Muutoshallinta ja baseline käytännöt | |||
Aikataulunhallinta | Osio 2.9 Aikataulusuunnittelu | |||
Kustannushallinta | Ei kuvattu | Osio 2.10 Kustannusseuranta | ||
Laadunhallinta | Osio 2.11 Laadunhallinta | |||
(Henkilö)- resurssienhallinta | Osio 2.12 Resurssisuunnittelu ja -seuranta | |||
Viestintä | Osio 2.13 Viestintä ja sidosryhmähallinta Osio 2.14 Dokumentinhallinta | |||
Riskienhallinta | Osio 2.15 Riskienhallinta | |||
Hankintojen hallinta | Ei kuvattu | |||
Hyötyjen- ja muutoksenjohtaminen | Osio 2.16 Hyötyjen ja muutoksen johtaminen | |||
2.4 Projektinhallinnan roolit ja vastuut projektin elinkaarella
Tämä osio täydentää Liite D1 Hallintamalli -dokumentissa määriteltyjä roolikuvauksia projektinhallinnan näkökulmasta ja myös esittelee joitakin rooleja, joita ei ole mainittu hallintamallissa. Kuva 3 määritetään projektinhallinnan roolit ja xxxxxx roolin vastuu projektin elinkaarella, joka on esitetty aiemmin osiossa 2.3.
Kuva 3 Projektinhallinnan roolit3 ja vastuut
Projektien käytännön tekeminen on annettu projektien projektitiimin jäsenille, joita projektipäällikkö johtaa ja ohjaa. Projektipäälliköitä on mahdollista olla omat sekä Asiakkaalla että Järjestelmätoimittajalla, mutta vähintään aina Järjestelmätoimittajalla. Myös projektitiimin jäsenet voivat olla sekä Asiakkaan että Järjestelmätoimittajan organisaatiosta.
Hankepäällikkö vastaa projektista osana laajempaa hanketta. Hän varmistaa, että projekti etenee hankkeen ehdoilla. Hän toimii hankejohtajan ohjauksessa. Hankepäälliköllä on tukenaan PMO (Programme Management Office, johon hallintamallissa viitataan termillä Hankehallintatoimisto).
Resurssin omistaja vastaa siitä, että projekti resursoidaan linjaorganisaatiosta asettamiskirjeen ja projektisuunnitelman mukaisesti. Resurssin omistaja saattaa olla myös projektin ohjausryhmän jäsen, mikäli hänen alaisuudessaan olevia henkilöitä tarvitaan projektissa merkittävästi.
Projektin omistaja vastaa projektin tavoitteiden (so. hyöty-, lopputulos-, aikataulu-, työmäärä- ja kustannustavoitteet) määrittelystä ja huolehtii, että projekti etenee kohti saavutettuja tavoitteita. Projektin omistaja mm. päättää, koska eri projektin vaiheet on saatu suoritettua ja ehdottaa vaiheen päättämistä projektin
3 Kuvassa A = Asiakas ja T = Järjestelmätoimittaja. Asiakkaan rooleja voi täyttää myös Tilaaja.
ohjausryhmälle. Projektin omistaja on Asiakkaan edustaja. Projektin omistajalla on oikeus tehdä mandaattinsa rajoissa muutoksia projektin tavoitteisiin. Projektin omistaja toimii ohjausryhmän puheenjohtajana.
Projektin ohjausryhmään kootaan ne henkilöt, jotka vastaavat projektin liiketoimintahyödyistä (tyypillisesti hankkeen johtoryhmän jäsen), käyttäjänäkökulmasta (voi tulla Tilaajalta) sekä resursseista. Ohjausryhmä pitää kuitenkin pitää käytännöllisen kokoisena. Esimerkiksi kaikkia projektissa tarvittavien asiantuntijoiden esimiehiä ei ole mielekästä koota ohjausryhmään, vaan resursointi hoidetaan muutoin, sovittujen käytäntöjen mukaisesti.
Ohjausryhmä tukee projektin omistajaa projektin ohjaamisessa ja päätettäessä muutoksista tavoitteisiin.
Hankkeen johtoryhmä johtaa projektisalkkua eli tekee projektien käynnistyspäätökset (P1) ja samalla vahvistaa kunkin projektin tavoitteet. Mikäli tavoitteita tarvitsee muuttaa, tuodaan projekti uudestaan päätöksentekoon joko P2-portissa tai projektin muutoshallinnan kautta. Muutoin johtoryhmä ainoastaan seuraa operatiivisen salkunhallinnan kautta projektikokonaisuuden edistymistä ja puuttuu ainoastaan suurimpiin poikkeamiin tavoitteista. Projektisalkunhallinnan tehtäviin kuuluu myös tasapainottaa resurssienkäyttöä, mikä voi johtaa siihen, että hankkeen johtoryhmän tarvitsee puuttua myös jo asetettujen projektien aikatauluihin, resursointiin tai muihin tavoitteisiin. Hankkeen johtoryhmään kuuluu sekä Asiakkaan että Järjestelmätoimittajan edustajia. Asiakkaan hankejohtaja toimii ryhmän puheenjohtajana. Xxxxxxxxxxxx päättää Erillisprojektien sopimuksista mandaattinsa puitteissa.
2.4.1 Järjestelmätoimittajan projektihenkilöstö
Tässä osiossa on kirjattuna yleisiä projektihenkilöstöön liittyviä vaatimuksia.
Vaatimus: Järjestelmätoimittajan on laadittava luettelo sellaisista projektin tuottamiseen osallistuvista Järjestelmätoimittajan tai sen alihankkijan henkilöistä, joilla on pääsy Asiakkaan tietoaineistoihin ja tunnistetietoihin. Luetteloa on päivitettävä säännöllisesti. Järjestelmätoimittajan on huolehdittava, että Asiakas voi tarvittaessa teettää turvallisuusselvitykset edellä mainituista henkilöistä.
Vaatimus: Järjestelmätoimittaja vastaa siitä, että ennen projektihenkilön osoittamista sopimuksen mukaisiin projektitehtäviin kaikki projektia suorittavat henkilöt ovat sitoutuneet sopimuksen mukaiseen luottamuksellisuuteen.
Vaatimus: Projektihenkilöstön käytön ja mahdollisen työskentelyn Asiakkaan tiloissa on aina oltava Asiakkaan turvallisuus-, tietosuoja-, yleisten käytös- sekä muiden Asiakkaan kohtuullisten ohjeiden ja määräysten mukaista. Asiakkaan on ilmoitettava etukäteen kaikista tällaisista Järjestelmätoimittajan henkilöstön noudatettaviksi tarkoitetuista menettelytapavelvoitteista.
2.5 Projektisuunnittelu yleisesti
Vaatimus: Projektisuunnitelmista tulee tallentaa nk. Baselineja4, joita vastaan edellytetään raportoitavan toteutunutta ja ennustettua aikataulua, laajuutta sekä työmääriä.
4 Baseline on SFS-ISO 21500 -standardissa suomennettu seuraavasti: Vertailukohta (baseline)= vertailun lähtökohta, jonka avulla projektin suorituskykyä seurataan ja valvotaan.
Xxxxxxxx suunnittelu: Hankkeessa sovelletaan rullaavan suunnittelun menetelmää, jossa aikataulu, työmäärä ja resursointi suunnitellaan neljällä eri aikajänteellä:
• Pitkä tähtäin = koko hanke
• Keskipitkä tähtäin, roolitaso = seuraavat 9 kuukautta
• Keskipitkä tähtäin, henkilötaso = seuraavat 6 kuukautta
• Lyhyt tähtäin = seuraavat 1-2 kuukautta
Suunnitelmat ja ennusteet | ||||
HANKETASO (Master Plan) | Toteuman raportointi | Keskipitkä tähtäin, seuraavat 6 kk | Keskipitkä tähtäin, seuraavat 9 kk | Pitkä tähtäin, koko hanke |
Aikataulu | Toteutuneet tehtävien alku- ja loppupäivämäärät Päivityssykli: Kerran kuukaudessa | Projektoitu (portit ja tarpeelliset virstanpylväät, vaiheet) tai max 1 kk hanketason tehtäviä Päivityssykli: Kerran kuukaudessa | Hanke pilkottu projekteiksi, joilla alku ja loppu Isot virstanpylväät Päivityssykli: joka 3. kuukausi | |
Työmäärä | Toteutunut htp / projekti / kk Päivityssykli: kerran kuussa | htp5 / projekti / kk Päivityssykli: kerran kuussa | htp / projekti / Q6 Päivityssykli: joka 3. kuukausi | |
Henkilöresurssit | Toteutunut htp / hlö tai rooli / projekti / kk Päivityssykli: kerran kuussa | htp / hlö / projekti / kk Päivityssykli: kerran kuussa | htp / rooli / projekti / kk Päivityssykli: kerran kuussa | htp / rooli / projekti / Q Päivityssykli: joka 3. kuukausi |
Suunnitelmat ja ennusteet | ||||
PROJEKTITASO | Toteuman raportointi | Lyhyt tähtäin, seuraavat 1-2 kk | Koko projekti | |
Aikataulu | Toteutuneet tehtävien alku- ja loppupäivämäärät Tehtävän % valmiina (soveltuvissa kohdissa) Päivityssykli: Kerran viikossa tai joka toinen viikko | Konkreettiset työsuunnitelmat Päivityssykli: Kerran viikossa tai joka toinen viikko | Tehtävät pilkottu max. kahden viikon mittaisiin Päivityssykli: Kerran viikossa tai joka toinen viikko | |
Työmäärä7 | Tehtävän toteutunut htp / kk Päivityssykli: kerran kuussa | Ennuste htp / tehtävä Päivityssykli: kerran kuussa | ||
Henkilöresurssit8 | Toteutunut htp / hlö tai rooli / kk Päivityssykli: kerran kuussa | Ennuste htp / hlö tai rooli / kk Päivityssykli: kerran kuussa | ||
Vaatimus: Järjestelmätoimittajalta edellytetään vähintään Taulukko 2 määritellyn tarkkuustason rullaavaa suunnittelua ja suunnitelmien sekä ennusteiden esittämistä Asiakkaalle.
5 htp = henkilötyöpäivä.
6 Q = kvartaali, neljännesvuosi.
7 Järjestelmätoimittajan ennusteista ja toteumaraporteista edellytetty tarkkuus riippuu valittavasta hinnoittelumallista (kiinteä hinta vs. tavoitehinta). Taulukossa mainittu tarkkuustaso sopii kiinteähintaiseen toimitukseen. Tavoitehintaisissa (ja mahdollisissa tuntihintaisissa) osuuksissa tullaan edellyttämään tarkempaa raportointia.
8 Kiinteähintaisessa projektissa ei edellytetä, että Järjestelmätoimittajan henkilöstön resurssisuunnitelmia tai -toteumia esitetään henkilötasolla. Näissä riittää hyvälaatuisen suunnitelman esittäminen tarkkuudella htp / rooli / kk ja työmäärätoteuman raportointi ei ole välttämätöntä. Tavoite- ja tuntihintaisissa projekteissa edellytetään henkilötason suunnitelmaa ja toteumaraportointia.
2.6 Edistymisraportointi
Edistymisraportoinnin tarkempi formaatti tullaan määrittelemään myöhemmin yhteistyössä Järjestelmätoimittajan kanssa.
2.7 Ratkaistavien asioiden hallinta
Projektin ratkaistavien asioiden hallinta on koko projektin elinkaaren jatkuva prosessi, jossa tunnistetaan, pidetään kirjaa, analysoidaan ja pyritään ratkaisemaan projektin ratkaistavia asioita (engl. issue). Tarvittaessa ratkaistava asia nostetaan (eli eskaloidaan) projektista ylöspäin joko hankkeelle tai projektin johtoryhmälle ratkaistavaksi. Projektin ratkaistava asia on asia, joka häiritsee projektin työskentelyä, mutta jota ei (välttämättä) pystytä projektin sisäisesti ratkaisemaan. Ratkaistava asia voi siis olla ongelma, tai avoin/selvitettävä asia. Esimerkkejä ratkaistavista asioista voisivat olla esimerkiksi:
• Jokin epäselvyys projektin tavoitteissa
• Jokin epäselvyys projektin laajuudessa (scopessa)
• Jokin projektin sisältötyöhön/tuotoksiin liittyvä epäselvyys
• Resurssikiistat hankkeen projektien välillä
Ratkaistavien asioiden hallinnan tarkoituksena on, että ratkaistavat asiat tunnistetaan ajoissa, niihin puututaan, ne pyritään käsittelemään ja ratkaisemaan järjestelmällisesti, niistä ollaan tietoisia, niiden tilasta pidetään kirjaa, ja niiden suhteen tehdään tietoisia päätöksiä. Tarkoituksena on myös, että merkittävät ratkaistavat asiat nostetaan (eskaloidaan) projektista ylöspäin hankkeen ja/tai linjaorganisaation ratkaistaviksi. Tavoitteena on minimoida ratkaistavista asioista projektille aiheutuvat negatiiviset vaikutukset, sekä maksimoida projektin onnistumisen todennäköisyys. Mikäli ratkaistavaan asiaan ei eskaloinnista huolimatta löydy ratkaisua, täytyy asia hyväksyä projektin työskentelyä haittaavana ongelmana tai riskinä. Ongelmat otetaan huomioon projektisuunnitelmassa/- ennusteessa. Riskit käsitellään projektin riskienhallintaprosesseissa.
Kuva 4 on esitetty ratkaistavien asioiden prosessi.
Kuva 4 Ratkaistavien asioiden prosessi
Taulukko 3 Ratkaistavien asioiden prosessin askelet
Askel | Kuvaus | Tila |
1. Kirjaa ratkaistava asia | Henkilö jolla on joku ratkaistava asia kirjaa sen lokiin ja informoi siitä projektipäällikköä. Projektipäällikkö organisoi ja koordinoi asian ratkaisemisen joko projektin sisällä tai hanketasolla. | Tila = Uusi |
2. Ota käsittelyyn | Ratkaisija vastaanottaa asian. Jos kyse on hanketason asiasta, hankkeen johtoryhmä organisoi ja koordinoi asian ratkaisemista. | Tila = Etsitään ratkaisua projektin sisäisesti tai Eskaloitu hankkeelle |
3. Kirjaa ratkaisu/vastaus | Kun asiaan on saatu ratkaisu, kirjataan se lokille. | Tila = Etsitään ratkaisua projektin sisäisesti tai Eskaloitu hankkeelle |
4. Merkitse ratkaistuksi | Ratkaistavan asian kirjaaja tai projektipäällikkö sulkee ratkaistavan asian. | Tila = Suljettu ratkaistuna |
5. Kirjaa ongelmaksi tai riskiksi | Jos asiaan ei saada ratkaistuksi, siitä syntyy uusi ongelma, joka kirjataan projektisuunnitelmaan ja huomioidaan esim. aikataulu- ja kustannusennusteissa. Asia voidaan myös tunnistaa riskiksi, jolloin se kirjataan riskilokiin ja siirtyy riskienhallinnan prosessin käsittelyyn. | Tila = Hyväksytty riskinä tai ongelmana projektille |
Vaatimus: Järjestelmätoimittajalta edellytetään määrämuotoista ja kirjattua ratkaistavien asioiden hallintaa sekä osallistumista yhteisten ratkaistavien asioiden hallintaan. Asiakkaalla on oikeus auditoida Järjestelmätoimittajan ratkaistavien asioiden hallinta Toimitussopimuksen ja/tai Palvelusopimuksen mukaisesti.
2.8 Laajuudenhallinta
Toteutus- ja käyttöönottovaiheen ja sen sisältämien projektien laajuus ja lopputulokset kuvataan sopimusliitteissä TS 2.1 ja TS 2.2. Erillisprojekteista laaditaan niistä sovittaessa erilliset sopimukset, joissa laajuus ja lopputulokset kuvataan.
Kunkin projektin ja osaprojektin asettamis- ja suunnitteluvaiheissa laajuuden ja lopputuloksien määritelmiä tarkennetaan. Mahdolliset muutokset projektin toteutuksen aikana kulkevat muutoshallinnan (ks. osio 2.8.3) kautta.
Laajuuden hallinta jakaantuu siis laajuuden suunnitteluun ja hallintaan toteutuksen aikana. Tässä luvussa keskitytään erityisesti Toteutusprojektin lopputuloksena syntyvän järjestelmäkokonaisuuden vaatimustenhallintaan (osio 2.8.1) ja toisaalta toteutus- ja käyttöönottovaiheen aikaisten projektien muutoshallintaan (ks. osio 2.8.3).
Huom.: Muutostenhallinnasta (sekä ns. projektimuutosten että järjestelmämuutosten) on säädetty ylätasolla dokumentissa Liite D1 Hallintomalli.
2.8.1 Vaatimustenhallinta
Vaatimukset toimivat lähtökohtana Järjestelmän tarkemmalle määrittelylle ja tekniselle suunnittelulle, joiden pohjalta Järjestelmä toteutetaan (konfigurointi + sovitut räätälöinnit) ja testataan.
Vaatimustenhallinta on projektin koko elinkaaren ajan jatkuva prosessi, johon kuuluu:
• Vaatimusten jäljittäminen. Kaikkien9 vaatimuksien toteutus todennetaan Asiakkaan toimesta testaamalla.
o Hankkeen vaatimushallinnan prosessissa määritellään kullekin vaatimukselle alustava todentamistapa. Tällainen todentamistapa voi olla esimerkiksi testaus tai katselmointi. Todentamistapaa voidaan vaatimuskohtaisesti tarkentaa tai yhteisesti sopien vaihtaa.
o Testaus on pääasiallinen todennustapa. Testitapaukset voivat olla käyttötapauspohjaisia. Yksittäinen testitapaus voi toimia useamman vaatimuksen todentamistapana.
o Katselmointia käytetään mm. määrittelydokumentaation todentamiseen.
• Vaatimusten muutoshallinta. Vaatimuksia voidaan muuttaa tai tarkentaa ainoastaan muutoshallinnan kautta (ks. tarkemmin muutoshallinnan prosessi osio 2.8.3).
• Konfiguraation- ja versionhallinta. Sovelluksesta tuotetaan projektin aikana uusia versioita tehdyn suunnitelman mukaisesti eri ympäristöihin. Järjestelmätoimittaja vastaa, että jokainen versio sisältää siihen sovitut vaatimukset, muutokset sekä virhekorjaukset ja versio pystytään asentamaan siihen ympäristöön, mihin se on tarkoitettu. Version sisältö yksilöidään versionkuvausdokumentissa ja sen liitteenä on Järjestelmätoimittajan tuottama asennusohje.
9 Asiakas voi projektikohtaisesti myös valita vain otoksen vaatimuksista testitapaussuunnittelun pohjaksi.
Kuva 5 Vaatimusten kerääminen ja hallinta
Kuva 6 on havainnollistettu projekteissa sovellettava vaatimustenhallinnan elinkaaren periaate. Elinkaaren perustana on vaatimustenhallinnan prosessi, joka linkittyy hyötyjenhallinnan prosessiin kiinteästi. Vaatimukset toimivat pohjana projektien toteutusvaiheelle eli uusi Järjestelmä tai Erillisprojektina toteutettava Järjestelmän lisäosa rakennetaan niiden pohjalta. Projektin aikana validoidaan hyötyjen toteutumista tarkastuspisteiden kautta ja käyttöönoton jälkeen hyötyjen toteutuminen todennetaan mittaamalla. Vaatimuksien muuttaminen saattaa johtaa myös projekti- tai sopimusmuutoksiin (ks. Liite D1 Hallintamalli), jolloin sovelletaan muutoshallintaa (ks. osio 2.8.2)
Kuva 6 Vaatimustenhallinnan elinkaari projekteissa
2.8.2 Vaatimusten täyttyminen
Vaatimusanalyysi
Vaatimusanalyysivaiheessa kukin vaatimus käydään läpi ja lyhyesti kuvataan miten vaatimus täyttyy Järjestelmässä. Mikäli Asiakkaalla ja/tai Tilaajilla sekä Järjestelmätoimittajalla ei ole yhteistä näkemystä vaatimuksen toteutustavasta, kuvataan osapuolien näkemykset eroanalyysissa.
Jokaisen vaatimuksen muutokset voidaan jäljittää.
Toteutus ja testaus (ks. tarkemmin luku 5)
Prosessi-/työnkulku- ja toiminnallisuuskuvauksissa kuvataan kunkin vaatimuksen täyttyminen. Kuvauksissa kerrotaan, mitkä vaatimukset täyttyvät tässä kohdassa.
Toteutus suoritetaan hyväksyttyjen määrittelyjen mukaisesti.
Testitapausten kuvauksissa todetaan, mitkä vaatimukset todennetaan kyseisessä testitapauksessa.
Sama vaatimus, sen toteuttava toiminnallisuus tai tekninen ratkaisu, tai sen toteuttavan toiminnallisuuden tai teknisen ratkaisun osa voi esiintyä useammassa testitapauksessa todennuskohteena. Vaatimus on todennettu vasta, kun kaikki sen todentamiseen liittyvät testitapaukset on onnistuneesti suoritettu, ellei muuta yhteisesti sovita.
2.8.3 Muutoshallinta- ja baseline-käytännöt
Muutosten hallinta on projektin koko elinkaaren ajan jatkuva prosessi, jossa käsitellään hallitusti projektin muutospyynnöt ja tehdään tietoisia päätöksiä muutosten suhteen. Muutos tarkoittaa tässä yhteydessä muutosta projektin hyväksyttyyn projektisuunnitelmaan10. Muutoksella voi olla vaikutuksia projektin kokonaislaajuuteen, laatuun, kokonaisaikatauluun tai kokonaiskustannuksiin, mutta on myös muutoksia, jotka eivät vaikuta mihinkään näistä. Muutoshallinnan tarkoitus on estää projektin hallitsematon muuttuminen ja varmistaa, että tarpeet muutoksille kirjataan ylös ja perustellaan, tarpeet muutoksille tutkitaan ja muutoksen vaikutukset analysoidaan, muutoksista tehdään tietoisia päätöksiä, ja muutoksen läpivientiä valvotaan. Muutospyynnön analysoinnissa on tärkeää tunnistaa, mihin kaikkialle muutoksen toteuttaminen vaikuttaa. Muutoksen toteuttamisessa puolestaan on tärkeää muuttaa kaikkia suunnitelmia ja tuotoksia joihin muutos vaikuttaa. Muutoshallinnalla tarkoitetaan projektin muutosten ja muutosehdotuksien käsittelyprosessia.
Mikäli muutoksella on vaikutusta projektin laajuuteen, aikatauluun tai kustannuksiin, se tulee myös hyväksyttää eskalointikäytännön (ks. Liite D1 Hallintomalli) mukaisesti oikealla tasolla. Projektin muutoksella voi olla vaikutuksia projektin ulkopuolelle, esim. hankkeen muihin projekteihin. Tämän takia projektipäällikön tulee tiedottaa hankkeelle projektin muutoksista. Hanke myös hyväksyy projektin muutospyynnöt hankkeen kannalta. Muutospyynnön täytyy olla hyväksytty ennen kuin muutosta voi alkaa toteuttamaan.
Projektipäällikkö tai hänen nimeämänsä henkilö kirjaa muutokset muutoslokiin ja kuvaa
• Muutoksen sisällön
10 dokumentissa Liite D1 Hallintomalli tämän tyyppisistä muutoksista käytetään termiä Projektimuutos.
• Muutospyynnön syyt
• Kuvauksen mahdollisista jatkotoimenpiteistä
• Vaikutuksen työmääriin, aikatauluihin, kustannuksiin ja resursseihin.
Apotti-hankkeen projektien muutoshallintaprosessin prosessikaavio on esitetty kKuva 7 ja vaiheet on avattu t Taulukko 4.
Kuva 7 Projektien muutoshallinnan prosessi
Taulukko 4 Projektien muutoshallinnan prosessin kuvaus
Askel | Kuvaus | Tila |
1. Kirjaa muutospyyntö | Muutos kirjataan muutoslokiin ja ilmoitetaan siitä projektipäällikölle. Kirjauksen voi tehdä kuka tahansa hankkeeseen tai projektiin osallistuva henkilö. | Tila = Uusi |
2. Hyväksy analysoitavaksi | Projektipäällikkö hyväksyy muutoksen analysoitavaksi ja koordinoi analysoinnin. | Tila = Käsittelyssä |
3. Lisää työmääräarvio ja aikatauluvaikutus | Järjestelmätoimittaja ja/tai Asiakas (riippuen siitä kummalle työ kohdistuu) arvioi muutoksen työmäärää ja vaikutusta aikatauluun ja lisää tiedot lomakkeelle sekä ilmoittaa tästä projektipäällikölle. | Tila = Käsittelyssä |
4. Hyväksytä muutos | Muutos käsitellään eskalointiprosessin mukaisesti ja joko hyväksytään tai hylätään. Pienempien muutoksien hyväksyntäoikeudet voidaan myös myöntää projektipäällikölle (projektipäällikön hyväksyntärajat sovitaan projektin asettamisen yhteydessä). | Tila jos muutospyyntö hyväksytään = Odottaa toteuttamisen aloittamista Tila jos muutospyyntö hylätään = Suljettu hylättynä |
5. Aloita työskentely | Järjestelmätoimittaja ja/tai Asiakas (riippuen siitä kummalle työ kohdistuu) ottaa muutoksen työn alle. Järjestelmätoimittaja ja/tai Asiakas päivittää projektisuunnitelman, mikäli muutoksella on tähän vaikuttaa. Järjestelmätoimittaja ja/tai Asiakas raportoi muutoksen toteutuksen edistymisestä normaalin edistymisraportoinnin yhteydessä. HUOM: Muutoksen toteutus voi olla esim. - Siirtymistä suoraan muutoksen tekemiseen Järjestelmään. Myös dokumentaatio päivitetään. - Muutos dokumentaatioon: esim. vaatimuslistaa päivitetään ja viedään varsinainen toteutus osaksi projektisuunnitelman tehtäväluetteloa - Mikäli muutos on hyvin suuri, voidaan koko muutoksen toteutus viedä vain uudeksi tehtäväksi projektisuunnitelmaan ja tämän jälkeen merkitä muutospyyntö valmiiksi. | Tila = Toteutuksessa |
6. Merkitse tehdyksi | Järjestelmätoimittaja ja/tai Asiakas merkitsee muutoksen tehdyksi kun se on valmis Järjestelmätoimittajan ja/tai Asiakkaan näkemyksen mukaan. | Tila = Tehty |
7. Organisoi muutoksen todentaminen | Projektipäällikkö organisoi muutoksen todentamisen esim. sopivan henkilön, testauksen tai katselmoinnin kautta. | Tila = Tehty |
8. Merkitse valmiiksi | Tarkistaja merkitsee muutospyynnön valmiiksi, jos muutos on tehty sovitusti ja informoi muutosvastaavaa tästä. | Tila = Valmis |
9. Sulje muutospyyntö | Projektipäällikkö sulkee muutospyynnön. | Tila = Suljettu tehtynä |
10. Palauta työn alle | Projektipäällikkö palauttaa muutoksen 5. askeleeseen ”Aloita työskentely” Järjestelmätoimittajalle ja/tai Asiakkaalle. | Tila = Toteutuksessa |
Vaatimus: projekteissa noudatetaan osiossa 2.8.2 kuvattua Muutostenhallinnan prosessia
2.8.4 Hyväksytty muutos ja projektin baseline
Projektin baselinella tarkoitetaan sitä projektisuunnitelmaa, joka hyväksyttiin P2-päätöksessä (ks. osio 2.3). Hyväksytty muutos muuttaa projektin voimassa olevaa baselinea alla kuvatun mukaisesti.
Taulukko 5 Baselinen käsittely muutosten hyväksymisessä
Ositusrakenne | Aikataulu | Kustannus ja työmäärä | |
Lopputulostavoitteen | Lisätään uusi, | Mikäli hyväksytty myös | Aiempi baseline päivitetään lisäämällä |
laajennus | muutoksen | laajennoksesta johtuva | uuden tehtävän työmäärä ja kustannus |
toteuttamista kuvaava | aikataulumuutos, tallennetaan | siihen. | |
tehtävä | uusi aikataulubaseline (koskien | Aiempien tehtävien osalta pidetään | |
niitä tehtäviä joihin muutos | kuitenkin alkuperäinen baseline arvo eikä | ||
liittyy) | esim. uusinta ennustetta. |
Tarkemmat baseline käytännöt (esim. muut kuin Lopputulostavoitteen laajennukset) määritellään projektikohtaisesti osana projektisuunnittelua.
2.9 Aikataulusuunnittelu ja -seuranta, valmiusasteseuranta
Vaatimus: Aikataulusuunnitelmien ja raporttien formaatti: Asiakas varaa tässä vaiheessa oikeuden määritellä toimitettavien aikataulusuunnitelmien ja raporttien ohjelmistoformaatin joko Microsoft Excel- tai Microsoft Project
-formaattiin. Asiakas määrittelee myös tarvittavat tietokentät. Asiakas haluaa tällä varmistaa saavansa mahdollisimman tehokkaasti integroitua Järjestelmätoimittajan aikataulutiedon hankkeen master-aikatauluun ja näkevänsä mahdollisten aikataulupoikkeamien vaikutuksen omaan työhönsä ja muihin projekteihin.
Vaatimus: Aikataulutilanne tulee raportoida vähintään viikoittain, ellei toisin sovita.
Vaatimus: Keskipitkän ja lyhyen tähtäimen aikataulusuunnitelmista tulee käydä ilmi tehtävien väliset loogiset riippuvuudet sekä niitten vaikutus tehtävien aikatauluun. Kunkin tehtävän kokonaispelivara (ns. total float tai total slack) tulee esittää.
Vaatimus: Aikatauluraporteista tulee käydä ilmi toteutuneet tehtävien aloitus- ja lopetuspäivämäärät.
Vaatimus: Keskeneräisistä tehtävistä raportoidaan valmiusaste sekä ennustettu päättymispäivämäärä. Kunnollista valmiusasteseurantaa varten projektin baseline-suunnitelmasta tulee ilmetä kunkin tehtävän suunniteltu työmäärä.
Valmiusasteen laskennasta: Valmiusastelaskennan tarkemmat käytännöt määritellään projektikohtaisesti osana projektisuunnittelua.
Kuva 8 Esimerkki projektin valmiusasteraportista
2.10 Kustannusseuranta
2.11 Laadunhallinta
Projektien laadunhallinta on läpi kunkin projektin elinkaaren ajan jatkuva prosessi, jossa projektille laadittavan laatusuunnitelman mukaisesti varmistetaan (esim. katselmoinnein, mittaroinnin tai testauksen keinoin) ja arvioidaan systemaattisesti
• projektin lopputulokset hankkeen tavoitteisiin nähden,
• jatkuvien prosessien toimivuus,
• poikkeavien tilanteiden hallinta.
Toimittamisessa on noudatettava hyvää teknistä tapaa, sovittua laatujärjestelmää ja sopijapuolten hyväksymiä kirjallisia ohjeita.
Laatusuunnitelmaa laadittaessa hyödynnetään hyväksi todettuja käytäntöjä ja kokemuksia ottamalla huomioon projektin luonne ja sen eri sidosryhmien tarpeet. Lähtökohtana on laadunhallinnan jatkuvan parantamisen (plan- do-check-act) periaatteet, joita soveltamalla ja erilaisia kypsyysanalyysejä suorittamalla tuetaan tavoiteltavien hyötyjen realisoitumista, sekä organisaatioiden kyvykkyyksiä ottaa uudet toimintatavat ja järjestelmät käyttöön tehokkaasti.
Katselmoinnit rytmitetään projektin muiden jatkuvien prosessien ja etenemisvaiheiden kannalta tarkoituksenmukaisiin etappeihin antamaan kokonaisvaltaista tietoa ohjausryhmälle päätöksenteon tueksi. On varauduttava, että projekteissa on katselmointeja 1–2 kuukauden välein. Katselmoinnit suorittaa projektin tai tehtävän toteutukseen nähden riippumaton toimija sekä projektin sisäisesti että ulkoisesti. Katselmoinneissa käydään lävitse tavoiteasetanta, tärkeimmät tallenteet kuten edistymisraportit, analyysit, tuotokset ja avoimet/ratkaistavat asiat sekä esitetään parannusehdotukset ja korjaavien toimenpiteiden ehdotukset sekä johtopäätökset. Johtopäätöksissä tulee varmistaa, että ne auttavat viemään asioita eteenpäin eivätkä johda ”lähtöruutuun” palaamiseen. Huom. katselmointiprosessia on kuvattu myös alempana kohdassa 2.14.
Laatumittarit: Laatusuunnitelmassa saatetaan asettaa laatumittareita, joilla mitataan esimerkiksi projektinhallinnan ja ohjelmiston toteutuksen laatua. Laatumittarit voivat olla esimerkiksi seuraavanlaisia:
• Projektin läpiviemiseen liittyviä mittareita esim.:
o aikataulu
o kustannukset
o resurssien käyttö
o muutoshallinnan järjestelmällisyys
o yhteistyön toimivuus
• Projektin toteutukseen liittyviä mittareita esim.:
o vaatimusten jäljitettävyys
o sisällöllisten muutosten hallittavuus
o testauksen kattavuus
o testauksen laadukkuus (koodattu tai konfiguroitu kerralla oikein eli testauksessa ei löydetä virheitä tai toimii ensimmäisen korjauksen jälkeen (testauskertoja per korjaus))
2.12 Resurssisuunnittelu ja -seuranta
Xxxxx Xxxxxxx voi varmistua Järjestelmätoimittajan aikataulusuunnitelmien ja -ennusteiden realistisuudesta, Asiakas haluaa saada tietynasteisen näkyvyyden Järjestelmätoimittajan resurssisuunnitteluun ja seurantaan.
Vaatimus: Järjestelmätoimittajan tulee esittää Asiakkaan antamassa formaatissa resurssien käytön suunnitelma sekä toteuma, josta selviää resurssitarpeen määrä per aikayksikkö per rooli/henkilö Taulukko 2 mainittujen eri aikajänteiden vaatimusten mukaisesti. Tästä raportista on myös käytävä ilmi edellä mainitun tarpeen suhde Järjestelmätoimittajan projektiin allokoimaan henkilökapasiteettiin. Resurssisuunnitelman on oltava linjassa tehtäväkohtaisen aikataulusuunnitelman kanssa. Aikataulun tehtäville on tämän vuoksi esitettävä työmäärä Taulukko 2 esitetyn tarkkuustason mukaisesti. Suunnitelman on koskettava kaikkia projektissa tarvittavia henkilöresursseja (Järjestelmätoimittajan, Asiakkaan, Tilaajan sekä mahdollisten kolmansien osapuolien).
Kuva 9 Yksinkertaistettu esimerkki resurssiraportista
2.13 Viestintä ja sidosryhmähallinta
Vaatimus: Järjestelmätoimittajan viestintäpäällikkö osallistuu Asiakkaan viestintäpäällikön johdolla viestinnän suunnitteluun ja toteutukseen. Kunkin osaprojektin sisäisen viestinnän johtamisesta vastaa ensisijaisesti projektipäällikkö, ellei toisin määritellä.
Vaatimus: Projektisuunnittelun osana tehdään sidosryhmäanalyysi ja sen perusteella viestintäsuunnitelma. Viestintäsuunnitelma kuvaa viestittävän asian per sidosryhmä, viestinnän suunnan, välineen, vastuuhenkilön ja ajankohdan/-kohdat. Viestinnän toteutuminen suunnitelman mukaisesti varmistetaan raportoimalla viestintätilanne osana tilanneraportointia.
Vaatimus: Projektin aikatauluun tulee merkitä viestinnällisesti tärkeimmät ajankohdat erikseen. Nämä ovat niitä kohtia, joissa on pakko kertoa tilannetietoa, vaikka sanoma olisi ”ei mitään uutta”. Myös kriisiviestintäsuunnitelma tulee tarvittaessa laatia.
Vaatimus: Järjestelmätoimittajan tulee viestiä kaikista projektin kannalta tärkeistä asioista läpinäkyvästi ja säännöllisesti käyttäen yhteisesti sovittuja viestinnän työkaluja ja kanavia.
Viestintätoimintaa pitää myös arvioida jatkuvasti ja viestinnässä esiin tulleisiin asioihin pitää tehdä muutoksia välittömästi, mikäli tarvetta esiintyy.
2.14 Dokumentinhallinta
Dokumentoinnissa käytetään vain yhteisesti sovittuja ja Asiakkaan hyväksymiä dokumenttipohjia. Dokumentoinnin tulee tapahtua sopimuksen mukaisella kielellä. Dokumentteja säilytetään dokumenttienhallintatyökalussa ja ne nimetään ja versioidaan yhteisesti sovittujen käytäntöjen mukaisesti. Kaikki dokumentaatio julkaistaan saman tien dokumenttienhallintatyökalussa, myös työversiot, niille osoitetussa hakemistossa. Dokumenttien luku- ja kirjoitusoikeuksia rajoitetaan tarvittavissa määrin roolipohjaisella oikeuksienhallinnalla ja erilaisilla työtiloilla.
Järjestelmätoimittajan vastuulla on tuottaa sovittu dokumentaatio, ylläpitää sitä koko projektin ajan sekä huolehtia, että Asiakkaalla on aina käytettävissä ajantasainen ja viimeisin versio.
Dokumentit hyväksytään Asiakkaan toimesta Kuva 10 esitetyn katselmointiprosessin mukaisesti:
2.15 Riskienhallinta
Projekteissa suoritetaan jatkuvaa riskienhallintaa. Projektisuunnittelun aikana tehdään Järjestelmätoimittajan ja Asiakkaan yhteinen riskianalyysi. Samassa yhteydessä tarkennetaan myös yhteiset riskienhallintakäytännöt.
Riskilistaus pidetään yhteisessä riskirekisterissä, joka jakaantuu hanketason riskeihin ja tarkempiin kunkin projektin ja osaprojektin riskeihin. Yhteinen riskirekisteri on tärkeä, jotta päällekkäiset riskit voidaan yhdistää ja esim. kukin vastuuhenkilö näkee kaikki omalla vastuullaan olevat riskit ja riskien torjuntatoimenpiteet.
Hanketason riskilista jaetaan osakokonaisuuksiin, joita käsitellään eri ryhmissä aiheen ja asiantuntemuksen mukaan. Riskilista tulee päivittää kokonaisuudessaan neljä kertaa vuodessa (uudet riskit, riskien yhdistely ja sulkeminen, riskien todennäköisyys- ja vaikutusarviot, toimenpiteiden listaus pahimmille riskeille). Kuukausittain tarkistetaan sovittujen toimenpiteiden toteuttaminen määrätyssä aikataulussa. Hanketason riskienhallinnan toimimisesta vastaa hankepäällikkö.
Projekteissa riskienhallinnan sykli on kerran kuussa.
Projekteissa suoritetaan jatkuvaa riskienhallintaa. Projektisuunnittelun aikana tehdään Järjestelmätoimittajan ja Asiakkaan yhteinen riskianalyysi. Samassa yhteydessä tarkennetaan myös yhteiset riskienhallintakäytännöt.
Vaatimus: Järjestelmätoimittajalta edellytetään aktiivista osallistumista hanketason ja projektien riskienhallinnan tapahtumiin ja toimenpiteisiin. Järjestelmätoimittajan tulee nimetä edustajansa hanketason riskienhallintaan sekä kunkin Järjestelmätoimittajaa koskevan projektin riskienhallintaan.
2.16 Hyötyjen ja muutoksen johtaminen
Merkittävä osa Apotti-hanketta on hyötyjen ja muutoksen johtamista. Apotti-hankkeessa termeistä käytetään seuraavia määrityksiä:
• Muutoksen johtaminen -termille synonyymejä: Organisaation muutoksen johtaminen, Management of Change, Organizational Change Management
• Muutoshallinta on osa projektin laajuuden hallintaa. Synonyymejä: Scope control. Change management. Change control. Kuvattu tarkemmin osiossa 2.8.3
Muutosjohtaminen on Asiakkaan ja Xxxxxxxx vastuulla.
2.17 Projektien hyväksyminen ja lopettaminen
Projektin hyväksymismenettelyn yksityiskohdat kuvataan projektisuunnitelmissa. Mikäli hyväksymisen yhteydessä havaitaan korjattavaa, Asiakkaan on ilmoitettava Järjestelmätoimittajalle lopputuloksessa havaitsemastaan virheestä kirjallisesti viivytyksettä hyväksymismenettelylle varatun ajan puitteissa. Xxx Xxxxxxx ei ole ilmoittanut virheistä 30 päivän kuluessa, Asiakkaan katsotaan hyväksyneen lopputuloksen. Mikäli kyseessä on Järjestelmän luovutus, hyväksymistestaukseen tulee varata vähintään 60 päivää.
Projekti hyväksytään, kun kaikki seuraavat kriteerit sekä projektisuunnitelmassa muut hyväksymiselle määritellyt kriteerit täyttyvät:
1. Järjestelmätoimittaja on toteuttanut kaikki projektisuunnitelman mukaiset tehtävät ja projektin lopputulokset on hyväksytty hallintamallin mukaisesti
2. Lopputuotosten laatu on varmistettu projektisuunnitelmassa sovittujen laadunvarmistusmenettelyjen mukaisesti
3. Mikäli kyseessä on tietojärjestelmän toimitusprojekti
a. Hyväksymistestaus on suoritettu projektin testaussuunnitelman mukaisesti
b. Kaikki havaitut merkittävät virheet on korjattu ja muiden virheiden korjaamisesta on sovittu osapuolten välillä
4. Järjestelmätoimittaja ja Asiakas ovat hyväksyneet palvelun siirron projektilta ylläpitoon
5. Ohjausryhmä (tai muu projektisuunnitelmassa määritelty taho) on päättänyt hyväksymisestä ja hyväksynyt projektin loppuraportin
Projektin elinkaarimallin mukaisesti projekti päätetään hallitusti lopetusvaiheella, jonka aikana projektista kirjoitetaan loppuraportti. Loppuraportissa kuvataan mitä projektissa tehtiin, kuka teki, mitä lopputuloksia syntyi ja mistä ne löytyvät. Lopputulosta, toteutunutta aikataulua sekä resurssien ja rahan käyttöä verrataan projektisuunnitelmassa asetettuihin tavoitteisiin ja analysoidaan syyt poikkeamiin. Loppuraporttiin kirjataan myös opit projektista – niin sisällölliset opit kuin projektinhallinnalliset opitkin. Loppuraporttiin kirjataan myös jäljelle jääneet projektin kohdetta koskevat tehtävät, jotka siirretään seuraaville projekteille tai jatkuville prosesseille. Loppuraporttien tarkempi sisällys ja formaatti määritellään myöhemmin.
Vaatimus: Loppuraportin kirjoittamisesta vastaa Järjestelmätoimittaja
3 Käyttäjäkeskeinen suunnittelu
Tässä luvussa kuvataan käyttäjäkeskeisen suunnittelun toteuttaminen osana Järjestelmän Toteutusprojektia, Pilottiprojektia, Hankintarenkaan Käyttöönottoprojekteja (ks. Liite TS 2.1 Toteutus- ja Käyttöönottoprojektien kuvaus) sekä mahdollisesti myöhemmin toteutettavia Erillisprojekteja.
Käyttäjäkeskeistä suunnittelua sovelletaan Asiakkaalle tehtävään ohjelmistokehitykseen sekä mukautukseen. Sitä ei sovelleta Järjestelmätoimittajan omaan tuotekehitykseen.
3.1 Käyttäjäkeskeisen suunnittelun periaatteet ja prosessi
Yksi merkittävimmistä syistä järjestelmien epäonnistumiseen on se, että niitä kehitetään perustuen väärään tai vajaaseen käyttäjätarpeiden ymmärtämiseen11.
Käyttäjäkeskeisellä suunnittelulla tarkoitetaan lähestymistapaa vuorovaikutteisten järjestelmien kehittämiseen, jossa tavoitellaan käytettävyydeltään hyvien järjestelmien suunnittelua ja tätä kautta tuloksellisuuden, tehokkuuden ja käyttäjätyytyväisyyden parantamista. Suunnittelussa lähtökohtana ovat Loppukäyttäjät, heidän tarpeensa ja vaatimuksensa. Suunnittelussa hyödynnetään ergonomia- ja käytettävyystietoa sekä erilaisia tekniikoita ja menetelmiä. Käyttäjäkeskeisen suunnittelun prosessi ja periaatteet sekä menetelmät on kuvattu standardeissa “ISO 9241-210 Ihmisen ja järjestelmän vuorovaikutuksen ergonomia, osa 210: Vuorovaikutteisten järjestelmien käyttäjäkeskeinen suunnittelu” ja “ISO/TR 16982 Ergonomics of human-centred interaction – Usability methods supporting human-centred design”.
Standardin12 mukaan käyttäjäkeskeisen suunnittelun kuusi periaatetta ovat:
• suunnittelu perustuu käyttäjien, tehtävien ja ympäristöjen selkeään ymmärtämiseen
• Loppukäyttäjät ovat mukana koko suunnittelun ja kehityksen ajan
• käyttäjäkeskeinen arviointi ohjaa ja tarkentaa suunnittelua
• prosessi on iteratiivinen
• suunnittelu kohdistuu käyttäjäkokemukseen kokonaisuutena
• suunnittelutiimillä on monialaisia taitoja ja näkökulmia
Käyttäjäkeskeisen suunnittelun prosessiin kuuluvat neljä aktiviteettia ovat: 1) käyttötilanteen ymmärtäminen ja määrittely, 2) käyttäjävaatimusten määrittely, 3) suunnitteluratkaisujen tuottaminen sekä 4) suunnitteluratkaisujen arviointi13. Näitä aktiviteetteja toistetaan iteratiivisesti siten, että kukin aktiviteetti käyttää toisten aktiviteettien tuotoksia, kunnes päästään lopputulokseen, joka vastaa määriteltyjä vaatimuksia.
Aktiviteettien toteuttamista edeltää käyttäjäkeskeisen suunnitteluprosessin suunnitelman tekeminen. Kuvatut aktiviteetit vastaavat ylätasolta katsottuna suunnittelun ja kehityksen yleisiä vaiheita vaatimuksista suunnitteluun, todentamiseen ja hyväksymiseen.
3.2 Käyttäjäkeskeisen suunnittelun soveltaminen
Projekteissa sovelletaan standardien “ISO 9241-210 Ihmisen ja järjestelmän vuorovaikutuksen ergonomia, osa 210: Vuorovaikutteisten järjestelmien käyttäjäkeskeinen suunnittelu” ja “ISO/TR 16982 Ergonomics of human- centred interaction – Usability methods supporting human-centred design” mukaisia käyttäjäkeskeisen suunnittelun periaatteita, prosessia ja menetelmiä riippumatta suunnitteluprosessista ja vastuunjaosta suunnittelussa. Projektit sisältävät soveltuvin osin käyttäjäkeskeisen suunnittelun aktiviteetit: 1) määrittely, 2) suunnitteluratkaisujen tuottaminen ja 3) arviointi. Riippuen projektin luonteesta on projektitiimissä tärkeää olla erilaista osaamista ja näkökulmia mm. seuraavista osa-alueista: käytettävyys ja esteettömyys, käyttäjätutkimus, Loppukäyttäjät ja muut sidosryhmät, sovellusalueen asiantuntijat, käyttöliittymäsuunnittelu, ohjelmointi, ohjelmistosuunnittelu ja -tuotanto. Projektikohtaisesti sovitaan yhdessä siinä käytetyistä menetelmistä, kuten luvussa 2 kuvataan.
Käyttäjäkeskeisen suunnittelun periaatteita, menetelmiä ja standardeja sovelletaan hankkeessa sellaiseen sisältöön, räätälöintiin ja konfigurointiin, joka tehdään hankkeessa Asiakasta varten, joko Järjestelmätoimittajan toimesta (perustuen yhteiseen määrittelyyn), Asiakkaan ja Järjestelmäntoimittajan yhdessä tekemänä tai Asiakkaan yksinään tekemänä. Järjestelmätoimittajan oma tuotekehitys ei siten kuulu tässä dokumentissa tarkoitettuun sovellusalueeseen.
Järjestelmän sisällön/räätälöinnin/mukauttamisen kehittämisen näkökulmasta on tunnistettu kolme erityyppistä toteutettavaa kokonaisuutta (Taulukko 6), jotka eroavat toisistaan suunnittelun lähtökohtien ja laajuuden osalta:
12 ISO 9241-210 -standardi, 2010, s.18
Taulukko 6 Toteutettavat erityyppiset kokonaisuudet
Tyyppi | Selite |
K1 | Määritellään ja suunnitellaan järjestelmätoteutus sellaiselle työprosessille/työnkululle, jota valmistuote ei lainkaan sisällä, ja joka vaatii ohjelmistokehitystä sisältäen sekä Järjestelmän liiketoimintalogiikan että käyttöliittymän laajennoksia. |
K2 | Kehitetään uusi käyttöliittymä ja käyttöliittymätason toiminnallisuuksia olemassa olevan Järjestelmän liiketoimintalogiikan päälle. |
K3 | Järjestelmän käyttöliittymätason viimeistely / konfigurointi. Järjestelmän mukauttaminen Asiakkaan tarpeisiin käyttöliittymän valmiilla mukautustyökaluilla. Esimerkiksi työnkulkujen konfigurointi. |
Huom: Oletuksena on, että suurin osa Toteutusprojektin aikana toteuttavasta toiminnallisuudesta (erityisesti terveydenhuollon toiminnallisuus) kuuluu kategoriaan K3.
Nämä eri laajuiset kokonaisuudet toteutetaan keskenään erilaisten käyttäjäkeskeisen suunnittelun prosessien ja niihin sisältyvien aktiviteettien kautta. Käyttäjäkeskeisen suunnittelun iteratiivisuutta ja aktiviteetteja kolmen erityyppisen kokonaisuuden toteutuksessa on kuvattu tTaulukko 7. Esimerkiksi kokonaisuudessa K1 määrittely- ja esisuunnitteluvaihe on erittäin keskeinen ja laaja, varsinaisia toteutusvaiheita pohjustava vaihe. Kokonaisuudessa K3, jossa käyttäjäkeskeisen suunnittelun toteuttaminen pohjautuu melko valmiiseen käyttöliittymäkokonaisuuteen, painottuvat suunnitteluratkaisujen toteutus- ja arviointiaktiviteetit. Taulukko 7 on lisäksi nimetty eri aktiviteettien toteutusta vastaavat tahot ja lopputulokset sekä dokumentaatio, jota eri aktiviteetit tuottavat.
Tämän dokumentin seuraavissa osioissa kuvataan tarkemmin taulukossa esitettyjä vaiheita ja niihin liittyviä käyttäjäkeskeisen suunnittelun aktiviteetteja sekä aktiviteettien toteuttamiseen liittyviä vaatimuksia.
Taulukko 7. Sellaisten projektien, joissa toteutetaan järjestelmätoiminnallisuutta, eri vaiheisiin liittyvät käyttäjäkeskeisen suunnittelun aktiviteetit ja vastuutahot14, aktiviteettien toteuttamisen luonteeseen liittyvä iteratiivisuus, sekä eri aktiviteettien lopputulokset ja dokumentaatio (merkitty*).
Tyyppi | Tehtävä | Lopputulos | Järjestelmä- toimittaja | Asiakas ja/tai Tilaaja |
K1, K2, K3 | Pohjustava vaihe: projektin suunnittelu | |||
Käyttäjäkeskeisen suunnittelun suunnittelu | Käyttäjäkeskeisen suunnittelun suunnitelma osana projekti- suunnitelmaa | V | O, H | |
K1,K2 | Vaihe: Määrittely & toteutuksen esisuunnittelu | |||
a) Käyttötilanteen kuvaus ja liittyvät vaatimukset (tarkennukset/olemassa oleva dokumentaatio) | Käyttötilanteen spesifikaatio | V | O, H | |
b) Suunnitteluratkaisujen hahmottelu | Käyttäjävuorovaikutuksen spesifikaatio (skenaario/prototyyppi) | V | H | |
c) Käytettävyyden katselmointi/arviointi | Käytettävyyden arviointitulokset (havainnot) | O | V, H | |
🡪 Tulosten perusteella: iteraatio siirtyminen kohtaan a) TAI siirtyminen kohtaan d) | Päätös seuraavasta vaiheesta | O | V,H | |
14 V = Vastaa, O = osallistuu, H = hyväksyy, I = informoidaan
15 Päätöksessä arvioidaan, onko kyseessä poikkeama suhteessa vaatimusmäärittelyyn vai muutospyyntö, jolloin sovelletaan muutoshallintaa Hallintamallin mukaisesti
Tyyppi | Tehtävä | Lopputulos | Järjestelmä- toimittaja | Asiakas ja/tai Tilaaja |
d) Suunnitteluratkaisujen tarkentaminen | Käyttöliittymäspesifikaatio (prototyyppi) | V | O, H | |
e) Käytettävyyden arviointi | Käytettävyyden arviointitulokset (havainnot) | O | V, H | |
🡪Tulosten perusteella iteraatio: Määrittely & toteutuksen | Päätös seuraavasta vaiheesta | O | V, H | |
esisuunnittelu jatkuu kohdasta d) TAI siirrytään Toteutus: | ||||
Suunnitteluratkaisut ja arviointi-vaiheeseen | ||||
K3 | Vaihe: Määrittely & toteutuksen esisuunnittelu | |||
a) Viimeistely/ konfigurointikohteiden määrittely (käyttötapaukset, toiminnalliset vaatimukset, käytettävyysvaatimukset) | Käyttötilanteen ja käyttäjävuorovaikutuksen spesifikaatio (skenaario / prototyyppi) | V | O, H | |
🡪 Tulosten perusteella: siirrytään kohtaan b) TAI siirrytään Toteutus: Suunnitteluratkaisut ja niiden arviointi -vaiheeseen | O | V, H | ||
b) Suunnitteluratkaisujen tarkentaminen | Käyttöliittymäspesifikaatio (prototyyppi) | V | O, H | |
c) Käytettävyyden arviointi | Käytettävyyden arviointitulokset (havainnot) | V/O V/O, H Vastuu tarkennetaan projektisuunnitteluvaiheessa | ||
🡪 Tulosten perusteella iteraatio: Määrittely & toteutuksen esisuunnittelu jatkuu kohdasta b) TAI siirrytään Toteutus: Suunnitteluratkaisut ja arviointi- vaiheeseen | O | V, H | ||
Vaihe: Toteutus / Suunnitteluratkaisut ja niiden arviointi | ||||
a) Suunnitteluratkaisujen toteutus16 | Käyttöliittymän toteutus | V | O, H | |
b) Käytettävyystestaus (toiminnalliset ja käytettävyysvaatimukset) | Käytettävyyden arviointitulokset (havainnot, vaatimustenmukaisuus) | V/O | V/O, H | |
🡪Tulosten perusteella joko siirrytään vaiheeseen c) TAI vaiheeseen d) | O | V, H | ||
K1, K2, K3 | c) Suunnitteluratkaisujen jatkosuunnittelu 🡪 siirtyminen vaiheeseen a) | |||
d) Hyväksymistestaus (käytettävyysvaatimukset) | Käytettävyyden hyväksymistestauksen tulokset (vaatimustenmukaisuus) | I | V | |
🡪 Tulosten perusteella siirtyminen vaiheeseen c) TAI ratkaisun kiinnittäminen | V, H | |||
3.2.1 Projektisuunnitelma käyttäjäkeskeisen suunnittelun soveltamiseksi
Käyttäjäkeskeisen suunnittelun toteutus suunnitellaan projektisuunnitelmavaiheessa. Suunnitelmaan sisällytetään soveltuvin osin Järjestelmän elinkaaren vaiheet sisältäen määrittelyt ja toteutuksen esisuunnittelun, suunnitteluratkaisujen toteutukset, arvioinnit ja lopulliset testaukset.
Vaatimus: Yleisen tason käyttäjäkeskeisen suunnittelun suunnitelma: Järjestelmätoimittajan tulee esittää projekteissa, joissa toteutetaan järjestelmätoiminnallisuutta, tehtävää käyttäjäkeskeistä suunnittelua varten suunnitelma, jota noudatetaan projekteissa ja mahdollisissa osaprojekteissa. Suunnitelmassa kuvataan yleisellä tasolla, miten projekteissa noudatetaan käyttäjäkeskeisen suunnittelun periaatteita ja hyödynnetään käyttäjäkeskeisen suunnittelun menetelmiä, jotka on kuvattu standardeissa ISO 9241-210 ja ISO/TR 16982. Tämä
16 Ks. toteutuksen vastuunjako liitteessä TS 2.1
suunnitelma on osa järjestelmätoteutuksen projektisuunnitelmaa. Järjestelmätoimittaja on vastuussa suunnitelmasta. Asiakas osallistuu suunnitelman tekoon ja hyväksyy suunnitelman.
Vaatimus: Tämän yleisen tason suunnitelman tulee sisältää alla luetellut kohdat (mikäli jokin alla olevista kohdista on jo kuvattu kyseisen projektin tai osaprojektin projektisuunnitelmassa, kyseistä kohtaa ei ole välttämätöntä kuvata uudelleen):
1. käytettävien menetelmien ja resurssien tunnistaminen
2. prosessikuvaus, josta ilmenee miten suunnittelu- ja arviointiaktiviteetit seuraavat toisiaan
3. sovellettavien käyttäjäkeskeisen suunnittelun menetelmien kuvaukset
4. Loppukäyttäjien tai heidän edustajiensa mukana olo suunnittelun ja arvioinnin/testauksen eri vaiheissa
5. menettelytavat ja menetelmät käyttäjäkeskeisten aktiviteettien ja niiden tuotosten liittämiseksi osaksi muuta Järjestelmän toteutusta
6. työnjako ja vastuut: aktiviteettien toteuttamisesta vastaavien tahojen ja heidän osaamisalueidensa nimeäminen (Asiakas/Järjestelmätoimittaja, henkilöt)
7. kommunikointi ja viestintäsuunnitelma: menettelytavat tilanteisiin, joissa käyttäjäkeskeiset aktiviteetit vaikuttavat muihin Järjestelmän toteutuksen aktiviteetteihin, sekä menettelytavat tuotosten dokumentoimiseksi ja viestimiseksi suunnittelutiimin sisällä
8. välitavoitteet suoritettaville aktiviteeteille
9. iteroinnin, palautteen hyödyntämisen ja mahdollisten suunnittelumuutosten sekä suunnitteludokumentaation hyväksymiseen liittyvän uusintatarkastuksen vaatiman ajan huomioiminen projektin aikataulussa
Vaatimus: Osaprojektikohtainen käyttäjäkeskeisen suunnittelun soveltamisen suunnitelma: Osaprojektikohtaisessa suunnitelmassa tarkennetaan yleisen tason suunnitelmaa aktiviteettien ja menetelmien osalta. Tämän suunnitelman laajuus ja soveltaminen määritellään projektikohtaisesti yhdessä Asiakkaan kanssa. Pienemmissä projekteissa (K3-tasoiset projektit) suunnitelma voi olla useammalle projektille yhteinen ja sisällöltään suppeampi. Osaprojektikohtaisesta suunnitelman tekemisestä on vastuussa joko Järjestelmätoimittaja tai Asiakas, ja tämä sovitaan projektikohtaisesti. Asiakas hyväksyy suunnitelman.
3.2.2 Käyttäjäkeskeisen suunnittelun aktiviteetit
Toteutusprosessit tähtäävät käytettävyys- ja toiminnalliset vaatimukset täyttävien (järjestelmä)lopputulosten tuottamiseen. Seuraavassa on kuvattu käyttäjäkeskeisen suunnittelun aktiviteetit – määrittely, suunnitteluratkaisujen toteutus ja arviointi – ja näihin liittyvät vaatimukset. Käyttäjäkeskeisen suunnittelun periaatteiden ja Taulukko 7 mukaisesti prosessin tulee sisältää iteratiivisuutta ja käyttäjäkeskeisen suunnittelun aktiviteettien toistamista siten, että aktiviteetit käyttävät toisten aktiviteettien tuotoksia.
Vaatimus: Järjestelmätoimittajan tulee ohjata toteutusprosessia sen aikana projektisuunnitelman mukaisesti siten, että toteutuksessa sovelletaan ko. projektiin määriteltyjä käyttäjäkeskeisen suunnittelun periaatteita ja hyödynnetään käyttäjäkeskeisen suunnittelun menetelmiä. Tämä sisältää mm. vaatimuksen iteratiivisuudesta Taulukko 7 kuvatun mukaisesti. Iteratiivisuus on välttämätöntä, koska käyttäjän ja Järjestelmän vuorovaikutus on luonteeltaan monimutkaista ja moninaista eikä toteutuksen alussa ole mahdollista määritellä täydellisesti ja tarkasti vuorovaikutuksen yksityiskohtia.
Vaatimus: Järjestelmätoimittajan tulee suunnitella kaikki käyttöliittymätoteutukset siten, että eri määriteltyjen loppukäyttäjäryhmien tavoitteet ja tarpeet sekä käyttöympäristö ja -tilanne otetaan huomioon.
Vaatimus: Asiakas edellyttää, että projekteihin sisältyy määrittelyjen/vaatimusten ja kuvauksien/prototyyppien muokkaaminen ja tarkentaminen tiedon karttuessa mm. arviointien myötä.
Huom.: Järjestelmälle suoritetaan käytettävyyden arviointeja toteutusprosessin eri vaiheissa myös Asiakkaan toimesta (ks. Taulukko 7). Arvioinneissa käytettävät menetelmät määritellään vaiheeseen ja aikatauluun sopivaksi projektikohtaisesti.
3.2.2.1 Määrittely
Määrittelyvaihe on suunnittelu- ja arviointiaktiviteetteja pohjustava vaihe, joka sisältää käyttötilanteen kuvaamisen ja määrittelyn sekä käyttäjätarpeiden ja liittyvien vaatimusten määrittelyn. Käyttäjien ominaisuudet, tehtävät sekä ympäristö määrittelevät käyttötilanteen, jossa Järjestelmää käytetään.
Vaatimus: Järjestelmätoimittajan tulee kuvata Järjestelmän käyttötilanne riittävän yksityiskohtaisesti, jotta se tukee suunnittelu- ja arviointiaktiviteetteja. Käyttötilanteen kuvauksen tulee sisältää seuraavat:
• Loppukäyttäjät ja muut sidosryhmät
• Loppukäyttäjien ja loppukäyttäjäryhmien ominaisuudet
• Loppukäyttäjien tavoitteet ja tehtävät
• Järjestelmän käyttöympäristöt: tekninen, fyysinen, sosiaalinen ja kulttuurinen ympäristö.
Vaatimus: Järjestelmätoimittajan tulee hyödyntää olemassa olevaa dokumentaatiota, joka sisältää mm. toiminnalliset vaatimukset, käyttötapaukset, käyttäjätarinat ja käytettävyysvaatimukset projektien eri vaiheissa soveltuvin osin, erityisesti määrittely- ja esisuunnitteluvaiheissa.
Vaatimus: Järjestelmätoimittajan tulee tunnistaa Asiakkaan toteuttamaan, olemassa olevaan vaatimusmäärittelydokumentaatioon perustuen ne toiminnalliset ja käytettävyysvaatimukset, jotka liittyvät projektiin. Tarvittaessa näitä vaatimuksia voidaan täydentää ja tarkentaa Toteutusprojektin tavoitteita tukeviksi. Nämä vaatimukset ohjaavat Toteutusprojektin etenemistä ja toimivat projektin myöhemmissä vaiheissa käytettävyysarviointien ja -testausten sekä hyväksymistestausten kriteereinä.
3.2.2.2 Suunnitteluratkaisujen tuottaminen
Suunnitteluratkaisujen tuottaminen sisältää Järjestelmän vuorovaikutuksen suunnittelun ja käyttöliittymän suunnittelun standardin ISO 9241-210 mukaisesti. Vuorovaikutuksen suunnittelu tarkoittaa päätösten tekemistä siitä, miten Loppukäyttäjät suorittavat tehtäviä Järjestelmän avulla. Vuorovaikutussuunnittelu ei sisällä kuvausta siitä, miltä Järjestelmä näyttää, kun taas käyttöliittymäsuunnittelu kohdistuu Loppukäyttäjälle näkyviin komponentteihin, jotka tarjoavat tietoa ja ohjauskeinoja tehtävien suorittamiseksi kyseisellä Järjestelmällä.
Suunnitteluratkaisujen tuottamiseen kuuluvat seuraavat ala-aktiviteetit:
1. käyttäjän ja Järjestelmän välisen vuorovaikutuksen ja käyttöliittymän suunnittelu, jossa on huomioitu Loppukäyttäjän kokonaisvaltainen kokemus, liittyminen Loppukäyttäjän tehtäväprosessiin ja työnkulkuun sekä liittyvät vaatimukset
2. suunnitteluratkaisujen havainnollistaminen esimerkiksi skenaarioilla, prototyypeillä ja simulaatioilla
3. suunnitteluratkaisujen muokkaaminen ja kehittäminen kohdan 2 tuotosten käyttäjäkeskeisen arvioinnin tulosten pohjalta
4. suunnitteluratkaisujen kommunikointi relevanteille tahoille, erityisesti toteutuksesta vastaaville
Vaatimus: Järjestelmätoimittaja on pääasiallisesti vastuussa prototyyppien, mallien ja käyttöliittymätoteutusten tuottamisesta ellei muuta ole sovittu projektisuunnitelmassa.
Vaatimus: Järjestelmätoimittaja tuottaa ratkaisuehdotukset perustuen käyttötilanteen kuvauksiin, vaatimuksiin, aiemmin toteutettujen arviointien tuloksiin, sovellusalueen vakiintuneisiin käytäntöihin, suunnittelu- ja käytettävyysohjeistoihin sekä standardeihin ja suunnittelutiimin kokemukseen ja tietoon.
Vaatimus: Järjestelmätoimittaja hyödyntää käyttöliittymän yksityiskohtaisessa suunnittelussa olemassa olevaa ergonomia- ja käyttöliittymätietoa, standardeja ja ohjeita.
Vaatimus: Mikäli Järjestelmätoimittajalla on olemassa tyyliopas, todennetaan sen laadukkuus toteutusprosessin alussa Asiakkaan toimesta. Mikäli Asiakkaan puolesta katsotaan tarpeelliseksi tuottaa tyyliopas, se tuotetaan lisätyönä Asiakkaan ja Järjestelmäntoimittajan kanssa ja Järjestelmätoimittajan tulee noudattaa tuotettua tyyliopasta.
Vaatimus: Ratkaisuehdotusten ensimmäisessä vaiheessa Järjestelmätoimittaja tuottaa kuvauksen siitä, miten asetetut toiminnalliset vaatimukset ja käyttötapauksiin liittyvät työprosessit käytännössä ratkaistaan (järjestelmäkuvin niiltä osin kun pohjautuu valmiiseen ratkaisuun tai komponentteihin). Mikäli prosesseihin liittyy useampia osajärjestelmiä tai saman järjestelmän erillisiä osioita, kuvataan näiden rooli ja miten ne toimivat yhteen.
Vaatimus: Suunnitteluratkaisujen tuottamisen yhteydessä Järjestelmätoimittajan tulee dokumentoida mitkä liittyvät toiminnalliset vaatimukset ratkaisu toteuttaa ja mitkä käytettävyysvaatimukset ratkaisun tulisi toteuttaa.
Vaatimus: Järjestelmätoimittajan tulee liittää suunnitteluratkaisujen yhteyteen selitykset ja perustelut silloin, kun näihin liittyy kompromissiratkaisuja.
Huom: Suunnitteluratkaisujen tuottamiseen liittyen tulee huomioida, että toiminnallisia vaatimuksia ja käytettävyysvaatimuksia voi ilmetä lisää tai ne voivat tarkentua suunnitteluratkaisuja tarkennettaessa ja arvioitaessa. Lisäykset ovat muutoshallinnan alaisia.
3.2.2.3 Arviointi
Suunnitteluratkaisujen arviointi käyttäjien kanssa ja käytettävyystestaus on oleellinen osa projekteja sekä määrittely-, suunnittelu- että toteutusvaiheissa kuten Taulukko 7 on kuvattu. Toteutettavan sisällön/räätälöinnin/mukauttamisen käytettävyyttä katselmoidaan, arvioidaan ja testataan projektikohtaisesti sovitusti useissa eri kohdissa toteutusprosessia. Alustavien suunnitteluratkaisujen kohdalla arviointi kohdistuu työnkulkujen tai toimintaprosessien ja käyttöliittymien muutostarpeiden tunnistamiseen ja näihin liittyviin parannusehdotuksiin. Toteutuksen myöhemmissä vaiheissa arvioinnin pääpaino on toiminnallisuuksien yksityiskohtien ja käyttöliittymätason parantamisessa. Toteutusvaiheessa tapahtuvaa käytettävyystestausta on kuvattu myös luvussa 5.3.6, jossa varmistetaan, että käytettävyysvaatimukset täyttyvät. Käytettävyystestaus on myös osa hyväksymistestausta.
Käyttäjäkeskeisen arvioinnin menetelmät jakautuvat pääosin kahteen lähestymistapaan:
• käyttäjätestaus, jossa on mukana todellisia tai potentiaalisia Loppukäyttäjiä
• käytettävyyden asiantuntija-arviointi, jossa käytettävyysasiantuntijat suorittavat arvioinnin esimerkiksi olemassa oleviin käytettävyysohjeisiin ja -suunnittelusääntöihin perustuen.
Käytettävyysarvioinnin menetelmiä on kuvattu tarkemmin “ISO/TR 16982 Ergonomics of human-centred interaction – Usability methods supporting human-centred design” -dokumentissa.
Vaatimus: Järjestelmätoimittajan tulee soveltaa käyttäjäkeskeistä arviointia projektien eri vaiheissa seuraaviin tarkoituksiin:
• käyttäjätarpeisiin liittyvän tiedon keräämiseen
• alustavien suunnitteluratkaisujen väliseen vertailuun
• alustavien suunnitteluratkaisujen kehittämiseen ja toteutusvaiheessa ratkaisujen parantamiseen
• sen arviointiin, ovatko toiminnalliset vaatimukset ja käytettävyysvaatimukset täyttyneet.
Vaatimus: Järjestelmätoimittajan tulee käyttää projektien aikaisen arvioinnin tuloksia suunnitteluratkaisujen ja toteutuksen parantamiseen. Projektisuunnitelmassa tulee olla varattuna aikaa näiden parannusten tekemiselle.
Vaatimus: Projektisuunnitelmassa tulee määritellä arvioinnin toteuttamisen vastuutahot (Asiakas /
Järjestelmätoimittaja) kussakin kohdassa ja arviointien tuloksena tuotettava dokumentaatio. Käytettävyysarvioinneissa sovellettavat menetelmät, arvioinnissa läpikäytävät tehtävät ja toiminnallisuudet sekä testikäyttäjät hyväksyy Asiakas. Nämä kuvataan projektisuunnitelmassa ja ne voivat tarkentua projektin edetessä. Projektisuunnitelmasta on vastuussa Järjestelmätoimittaja.
Käytettävyysarvioinnin käytännön toteuttamiseen liittyviä vaatimuksia ovat:
• Vaatimus: Käytettävyyden arvioinnin suunnittelusta vastaa aina käytettävyysasiantuntija tai - asiantuntijat.
• Vaatimus: Alustavia suunnitteluratkaisuja prototyypeillä (toiminnallinen / ei-toiminnallinen) arvioitaessa käyttäjien tulee suorittaa tehtäviä prototyypeillä sen sijaan, että heille demonstroidaan tai esitellään suunnitteluratkaisuja.
• Vaatimus: Kehittyneempiä toteutuksia tulee arvioida käytettävyysongelmien tunnistamiseksi ja parannusehdotusten keräämiseksi sekä asiantuntija-arviointi- että käyttäjätestausmenetelmillä.
• Vaatimus: Käytettävyyden asiantuntija-arviointia voidaan suorittaa myös yhteistyössä sovellusalueen asiantuntijoiden kanssa.
• Vaatimus: Lähtökohtaisesti toteutuksen aikana yhden käyttäjätestauksen tulosten tulee perustua vähintään viiden Loppukäyttäjän kanssa toteutettuihin arviointeihin.
• Vaatimus: Käytettävyyden arvioinneissa läpikäytävät Loppukäyttäjien tehtävät luokitellaan sen perusteella, miten tärkeä se on Loppukäyttäjän operatiivisen toiminnan näkökulmasta:
1. kriittinen – tehtävät pääasiallisten ja tärkeimpien tavoitteiden saavuttamiseksi
2. tärkeä – tehtävät, jotka liittyvät muihin operatiivisen toiminnan näkökulmasta usein toistuviin tehtäviin
3. toissijainen – harvemmin toistuvat lisäinformaatiota tuottavat tehtävät, jotka eivät ole edellytyksenä tärkeiden tai kriittisten tehtävien suorittamiselle
• Vaatimus: Toteutusprosessin loppuvaiheissa suunnitteluratkaisuja tulee arvioida suhteessa käytettävyysvaatimuksiin sisältäen tavoite- ja hyväksyttävät tasot.
• Vaatimus: Käytettävyyden arvioinnin tulokset ovat tyypillisesti laadullista aineistoa, jota ei voida määritellä yksiselitteisesti. Tästä johtuen kunkin yksittäisen havainnon luokittelu on Asiakkaan harkinnanvarainen päätös, joka perustuu ongelman todennäköiseen esiintymistiheyteen sekä ongelman vaikutuksiin siihen törmättäessä.
Huom: Asiakkaalla on oikeus tehdä omalla kustannuksellaan myös hyväksytyn projektisuunnitelman ulkopuolisia käytettävyyden arviointeja, joiden tulokset tulee huomioida suunnitteluratkaisujen kehittämisessä samalla tavalla kuin suunnitelmassa mainittujen arviointien tulokset. Tällaisten ylimääräisten arviointien ei tarvitse mahtua Toteutusprojektissa liitteessä TS 2.1 määritellyn maksimiresurssiraamin sisälle.
3.2.3 Lopputulokset
Käyttäjäkeskeisen suunnittelun aktiviteettien lopputulokset on kuvattu Taulukko 7.
Vaatimus: Järjestelmätoimittajan tulee tuottaa projektikohtaisesti sovitussa laajuudessa suorittamiensa aktiviteettien lopputuloksena Taulukko 7 kuvatut lopputulokset.
3.2.3.1 Arviointitulokset ja niiden hyödyntäminen
Käytettävyyden arvioinnin tulokset ohjaavat suunnitteluratkaisujen parantamista sekä alustavien että toteutettujen suunnitteluratkaisujen osalta.
Vaatimus: Järjestelmätoimittajan tulee korjata arvioinneissa havaitut puutteet ja kehittää suunnitteluratkaisuja tuloksiin perustuen.
Vaatimus: Järjestelmätoimittajan tulee korjata alustavien suunnitteluratkaisujen arvioinneissa havaitut puutteet seuraavalla tavalla:
• Kriittiset tehtävät: kriittiset, merkittävät ja haittaavat ongelmat on korjattava. Vähäiset ongelmat on korjattava, mikäli niitä on runsaasti.
• Tärkeät tehtävät: kriittiset ja merkittävät ongelmat on korjattava. Haittaavat ja vähäiset ongelmat on korjattava, mikäli niitä on runsaasti
• Toissijaiset tehtävät: Vähintään kriittiset ongelmat on korjattava. Huom.: Asiakas voi poiketa näistä vaatimuksista tapauskohtaisesti.
Vaatimus: Toteutusvaiheessa Järjestelmätoimittajan tulee korjata suunnitteluratkaisujen arvioinneissa havaitut puutteet noudattaen pääsääntöisesti luvussa 4 esitettyjä testaus- ja hyväksymiskriteerejä. Kuitenkin käytettävyyden arvioinnissa kriittisiin tehtäviin kohdistuvat ongelmat tulee korjata samalla tavalla kuin yllä on kuvattu: kriittisten ja merkittävien ongelmien lisäksi myös haittaavat ongelmat on korjattava.
Vaatimus: Kun Järjestelmätoimittaja on tehnyt korjaukset ylläkuvatun mukaisesti, Asiakas voi päättää tehdä uuden käytettävyyden arvioinnin ennen kuin toteutusprosessissa siirrytään seuraavaan vaiheeseen. Arvioinneissa käytettävät menetelmät päätetään tapauskohtaisesti. Kriittisten ongelmien löytyminen johtaa oletusarvoisesti uuden käytettävyyden arvioinnin suorittamiseen korjausten jälkeen.
3.2.3.2 Lopputulosten hyväksyminen
Jokainen käyttäjäkeskeisen suunnittelun aktiviteetti tuottaa lopputuloksen, joka toimii syötteenä seuraavalle aktiviteetille. Alla lueteltuihin aktiviteetteihin sovelletaan vastuiden osalta Taulukko 7. Lopputulokset ovat seuraavanlaisia:
• aktiviteetteja edeltävä suunnittelu: käyttäjäkeskeisen suunnittelun suunnitelma osana projektisuunnitelmaa
• määrittelyaktiviteetti: käyttötilanteen spesifikaatio ja vaatimusten tarkennukset
• suunnitteluratkaisujen tuottaminen -aktiviteetti: käyttäjävuorovaikutuksen spesifikaatio (skenaario/prototyyppi), käyttöliittymäspesifikaatio (prototyyppi), käyttöliittymän toteutus
• käytettävyyden arviointi -aktiviteetti: käytettävyyden arviointitulokset (havainnot, vaatimustenmukaisuus), hyväksymistestauksen tulokset (vaatimustenmukaisuus).
Lopputulosten liittyminen vaiheisiin ja aktiviteetteihin on kuvattu myös Taulukko 7. Lopputulosten sisältö määritellään käyttäjäkeskeisen suunnittelun suunnitelmassa osana projektisuunnitelmaa.
Vaatimus: Asiakas hyväksyy jokaisen aktiviteetin lopputuloksen ennen seuraavaan aktiviteettiin siirtymistä. Järjestelmätoimittajan tulee korjata mahdolliset puutteet lopputuloksissa/dokumentaatiossa. Käytettävyyden arvioinnin lopputulos voi johtaa myös aiemman aktiviteetin toistamiseen tai aiempien aktiviteettien iteratiiviseen toistamiseen.
3.3 Pilottiprojekti
Toteutusprojektin rinnalla toteutettavan Pilottiprojektin aikana kerätään käyttö- ja käyttäjäkokemuksia Järjestelmästä. Asiakkaan tulee voida tarkentaa vaatimuksia ja prosessien määrittelyjä näiden kokemusten perusteella. Kokonaan uudet vaatimukset ja määrittelyt käsitellään ja toteutetaan muutoshallinnan kautta.
Pilottiprojektin yhteydessä aloitetaan pitkäaikaisseuranta, jolla tarkoitetaan pitkän ajan kuluessa kerättävää käyttö- ja käyttäjätietoa. Tämä tieto mahdollistaa seuranta-arvioinnin toteuttamisen tietyn ajan, esimerkiksi vuoden kuluttua Järjestelmän käyttöönoton aloittamisesta. Seuranta-arviointeihin sisältyy Järjestelmän suorituskyvyn testaus sekä käyttäjätarpeiden ja käytettävyysvaatimusten täyttymisen arviointi.
Pitkäaikaisseuranta on Asiakkaan vastuulla.
4 Ketterä ohjelmistokehitys
Ketterä ohjelmistokehitys on ollut tärkeimpiä ohjelmistotuotannon kehitysaskelia 90-luvulla ja 2000-luvun alussa. Asiakas tunnistaa ketterien menetelmien mukanaan tuomat hyödyt, mutta ymmärtää myös ketterien menetelmien soveltamisen haasteet tämän tyyppisessä projektissa. Asiakas arvostaa Järjestelmätoimittajan näkemyksiä ja ehdotuksia ketterien toimintamallien soveltamisesta, mutta toisaalta pyrkii arvioimaan kriittisesti niiden realistiset soveltamismahdollisuudet.
Tässä kappaleessa kuvataan, miten ketteriä menetelmiä sovelletaan projekteissa.
Ns. Agile-manifestin perusarvot ovat17:
”Löydämme parempia tapoja tehdä ohjelmistokehitystä, kun teemme sitä itse ja autamme muita siinä. Kokemuksemme perusteella arvostamme:
• Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja
• Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota
• Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja
• Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän.”
Sopijapuolet suunnittelevat projektien projektisuunnitelmien laatimisen yhteydessä, käyttäen hyväkseen Järjestelmätoimittajan best practice -malleja, kuinka Apotti-hankkeessa toteutetaan ja huomioidaan Agile - manifestin perusarvoja ja missä kohdin hankkeen projekteja.
Ketteryyden soveltaminen Apotti-hankkeessa: Xxxxxxx seuraavia ketteryyden periaatteita tai hyviä käytäntöjä tavoitellaan Apotti-hankkeen toteutusvaiheessa
• Hyvä projektisuunnittelu. Valitaan sopiva toteutusmenetelmä kuhunkin projektin osioon. Tunnistetaan, missä voidaan olla ketteriä ja missä ei.
• Pilkotaan laaja hanke itsenäisiin osakokonaisuuksiin, joilla voi olla dedikoidut, itsenäiset pienet toteutustiimit. Henkilöt ovat näissä projekteissa täydellä työpanoksella, ei osapäiväisinä tai oman toimen ohessa.
• Miehitetään hanke moniosaajilla, mikä on edellytys pienille ja tehokkaille tiimeille. Moniosaajalla tarkoitetaan henkilöä, joka toimii toteutustehtävässä, mutta ymmärtää myös järjestelmäarkkitehtuuria sekä kykenee testaussuunnitteluun ja testaamiseen.
• Tuodaan käyttäjä lähelle toteuttajia mahdollisimman usein ja aikaisessa vaiheessa.
• Toteutus lyhyinä iteraatioina, joista saadaan valmista, demottavaa tuotosta.
Yllä olevat periaatteet ja käytännöt koskevat molempia sopijapuolia.
5 Testauksen hallinta
Laadukas ja riittävän kattava testaus on nostettu yhdeksi Apotti-hankkeen kriittisimmäksi menestystekijäksi johtuen Järjestelmän suuresta toiminnallisesta laajuudesta, Järjestelmän kriittisyydestä sekä monitoimittajaympäristössä tehtävästä vaiheistetusta toteutuksesta.
Tässä luvussa kuvataan testaukset sekä niihin liittyvät vastuut projektin toteutuksen sekä Jatkuvien palvelujen ohjelmistokehityksen ja ylläpidon aikana. Järjestelmälle asetettujen vaatimusmäärittelyjen täyttyminen todennetaan eritasoisten sekä erityyppisten testausten kautta. Testauksessa noudatetaan mm. hankkeen vaatimusten- ja muutoshallinnan prosesseja sekä hyväksymiskäytäntöjä.
17 xxxx://xxxxxxxxxxxxxx.xxx/xxx/xx/ (viitattu 28.12.2013)
5.1 Testauksen laajuus ja lähestymistapa
Testauksen laajuus kattaa
• koko ohjelmistokehityksen elinkaaren mukaan lukien Jatkuvien palvelujen ylläpidon aikaisen kehityksen
• koko toiminnallisen ja teknisen laajuuden mukaan lukien mm. ohjelmistot, uudet ohjelmakoodit, portaalit, tietovarastot, ohjeistukset, konversiot ja integraatiot
• laadulliset piirteet, kuten suorituskyky, tietoturva ja käytettävyys
• tekniseen alustaan liittyvät testaukset, kuten mm. tietoliikenne, palvelimet, lääkintälaitteet, eri ympäristöjen varmistukset ja palautukset.
Testauksen avulla arvioidaan järjestelmätoteutuksen vaatimustenmukaisuutta ja todennetaan Järjestelmälle asetettujen vaatimuksien täyttyminen. Hankkeessa noudatetaan vaatimustenhallinnan prosessia; alkuperäisiä vaatimuksia voidaan tarvittaessa päivittää muutoshallinnan kautta. Testaus on osa hankkeen hyväksymismenettelyä.
Testauksen tarkoituksena on todentaa tehtyjen konfiguraatioiden, mukautusten ja ominaisuuksien toimivuutta ja laatua vaatimusmäärittelyistä johdettuja testitapauksia vasten. Testauksessa ei ole tarkoitus todentaa Järjestelmän pohjana olevien valmisohjelmistotuotteiden ja niiden sisäisten liittymien toimivuutta: oletuksena on että tuoteratkaisu on testattu laadukkaasti ja kattavasti osana Järjestelmätoimittajan tuotekehitystä. Yhtenä testauksen lopputuloksena syntyy päätös siirtymisestä seuraavaan testaustasolle, käyttöönoton aloittamisesta tai korjauksen siirrosta tuotantoon.
Testauksen lähestymistapa pohjautuu yleisesti käytettyyn V-malliin (Kuva 11). Testauksen tavoitteena on löytää ja korjata virheet sekä huomata esim. mahdolliset vaatimuksien väärinymmärrykset sekä puutteet mahdollisimman varhaisessa vaiheessa. Projektien toimitusmallin (kuvattu liitteessä TS2.1 Toteutus- ja Käyttöönottoprojektien kuvaus) ollessa vaiheittainen ja iteratiivinen, testausta tehdään sitä mukaan kuin toteutuksesta valmistuu uusia toiminnallisuuksia (Kuva 12). Ohjelmistokehityksen elinkaaren näkökulmasta testauksia tehdään prosessin eri vaiheissa, jolloin testausten avulla tarkennetaan määrittelyjä sekä kehitetään ja tarkennetaan määrittelyihin perustuvia suunnitteluratkaisuja, kuten esimerkiksi vuorovaikutteisten järjestelmien käyttäjäkeskeistä suunnittelua kuvaavassa ISO 9241-210 -standardissa on esitetty (ks. luku 3).
Kuva 11 Testauksen V-malli (periaatekuva)
Kuva 12 Iteratiivinen testaus (periaatekuva)
5.2 Testauksen tasot
Tässä luvussa kuvataan eri testaustasojen sisältöä. Testaustasolla tarkoitetaan yksikkö-, integraatio-, järjestelmä-, hyväksymis- ja tuotantotestausta.
Tässä luvussa kuvataan yhteenvetona testaustasoja, testityyppejä ja käytettäviä testausympäristöjä. Testaustasoihin sisältyy eri testityyppejä, joita voidaan tarvittaessa suorittaa myös erikseen. Nämä tullaan kuvaamaan tarkemmin kunkin testauksen testaussuunnitelmissa. Testaustasot ja testityypit kuvataan seuraavissa luvuissa tarkemmin.
Taulukko 8 Testaustasot ja testityypit sekä testausympäristöt
Xxxxxxxxxx tyypit | ||||||||||||||||
Tietoliikenne (yhteydet) | Asennustestaus | Varmistus- ja palautustestaus | Tietoturvallisuus | Konversiotestaus | Toiminnallinen ja tekninen testaus | Tietosuoja | Käytettävyystestaus | Suorituskyky- ja kuormitustestaus | Regressiotestaus | Vikasietoisuustestaus | Savutestaus | Luovutustestaus | Vastaanottotestaustaus | |||
Testauksen tasot | Projekti | Ympäristö | ||||||||||||||
Yksikkö- testaus | Toteutus- projekti | Kehitysympäristöt | x | x | x | x | x | x | x | x | x | |||||
Integraatio- testaus | Toteutus- projekti | Integraatiotes- tausympäristöt | x | x | x | x | x | x | x | |||||||
Järjestelmä- testaus | Toteutus- projekti | Järjestelmätes- tausympäristö | x | x | x | x | x | x | x | x | x | |||||
Hyväksymis- testaus | Toteutus- projekti | Hyväksymistes- tausympäristö/ Tuotantotes- tausympäristö | x | x | x | x | x | x | x | x | x | x | x | |||
Tuotanto- testaus | Pilotti/Käyt- töönotot | Tuotantoympäristö | x | x | x | x | x | x | x | x | ||||||
5.2.1 Yksikkötestaus
Yksikkötestauksella tarkoitetaan toteutuksesta vastaavan osapuolen (Järjestelmätoimittaja tai Asiakas/Tilaajat) toteutuksen; Järjestelmän konfiguroinnin ja mukautuksen tai asiakaskohtaisen ohjelmistokehityksen yhteydessä tekemää esim. yksittäisen toiminnallisuuden, ohjelmiston itsenäisen komponentin, integraation tai moduulin testausta. Tällä ei tarkoiteta Järjestelmätoimittajan valmisohjelmistojen ja niiden sisäisten liittymien tuotekehityksessä tekemää yksikkötestausta. Yksikkötestaus tehdään kehitysympäristöissä.
Toteutuksesta vastaavan osapuolen vastuulla on tehdä riittävän kattava yksikkötestaus. Järjestelmätoimittaja voi käyttää yksikkötestauksessa omia menetelmiään ja valitsemiaan työvälineitä, kunhan yksikkötestauksen kattavuus on riittävän laajaa. Toteutuksesta vastaava osapuoli vastaa testauksessa mahdollisesti tarvittavien ohjelmasimulaatioiden (testiajurit; stubs and drivers) toteutuksesta ja testauksesta. Tuotetun ohjelmakoodin tehokkuus (ohjelmakoodin suorituskyky) ja käytettävyys testataan yksikkötestauksen yhteydessä. Lisäksi kootaan asennuspaketti ohjeineen, joka myös testataan.
Testiaineistona käytetään toteutuksesta vastaavan osapuolen generoimaa testidataa tai konvertoitua dataa, jos se on mahdollista. Järjestelmätoimittajan tulee automatisoida yksikkötestitapaukset regressiotestauksen ja jatkokehityksen helpottamiseksi tarkoituksenmukaisissa tapauksissa.
5.2.2 Integraatiotestaus
Integraatiotestauksen vastuut jaetaan kahteen osaan:
• kansalliset ja alueelliset integraatiot
• paikalliset integraatiot.
Järjestelmätoimittaja vastaa kansallisten ja alueellisten integraatioiden testauksen läpiviennistä ja koordinoinnista päästä-päähän (end-to-end). Testausta tukee Asiakkaan käyttöpalvelutoimittaja.
Asiakas vastaa integraatiotestauksen läpiviennistä ja koordinoinnista paikallisten integraatioiden osalta (päästä- päähän). Testausta tukevat Asiakkaan käyttöpalvelutoimittaja ja integroitavien järjestelmien nykyiset toimittajat tehdyn testaussuunnitelman mukaisesti.
Integraatiotestaukset tehdään Asiakkaan integraatiotestausympäristössä. Testauksessa voidaan tarvittaessa simuloida testidataa ja rajapintoja.
Vaikka integraatiotestauksen pääpainopiste on osien yhteentoimivuuden testauksessa, mukana voi olla myös ei- toiminnallisten ominaisuuksien, esimerkiksi suorituskyvyn, testausta tai esimerkiksi havainnointia uuden ohjelmakoodin tai valmisohjelmiston nopeudesta.
5.2.2.1 Kansallisten palvelujen integraatiotestaus
Kansallisten palvelujen integraatiotestaus on Järjestelmätoimittajan vastuulla. Järjestelmätoimittajan on otettava huomioon Kelan vaatimat sertifioinnit ja testauskäytännöt.
Sertifiointiprosessin aikana todennetaan tietojärjestelmän täyttävän määritellyt vaatimukset, jotka liittyvät toiminnallisuuteen, yhteentoimivuuteen ja tietoturvaan. Kaikki Kanta-palveluihin liittyvät organisaatiot sekä välityspalveluja tarjoavat tahot laativat omavalvontasuunnitelman. Viestintäviraston hyväksymä arviointilaitos todentaa välityspalveluiden toteuttajan teknisen tietoturvan.
Sertifiointi koostuu kolmesta kokonaisuudesta:
• Toiminnalliset vaatimukset Järjestelmätoimittaja todentaa ennen yhteistestausta
• Yhteentoimivuus, joka todennetaan Kelan yhteistestauksella
• Tietoturvallisuus, jonka todentaa Viestintäviraston hyväksymä arviointilaitos
Sertifiointi on suoritettu valmiiksi, kun järjestelmä on todettu vaatimukset täyttäväksi. Järjestelmätoimittaja ilmoittaa hyväksynnästä Valviralle.
Tietojärjestelmät testataan Kelan yhteistestauksessa eli Kanta-asiakastestipalvelussa. Testauksen tarkoituksena on varmistaa järjestelmien välinen yhteentoimivuus.
Kela laatii järjestelmien testausaikataulut, suunnittelee suoritettavat testitapaukset sekä koordinoi ja valvoo testauksen etenemistä. Kunkin järjestelmän testaajina toimivat Järjestelmätoimittaja ja Asiakkaan nimeämä testausryhmä. Yhteistestaukseen osallistuminen edellyttää, että Järjestelmä on läpäissyt ennalta määritellyt testit ja että Järjestelmätoimittaja sitoutuu yhteistestauksen toteuttamiseen yhteisen aikataulun ja suunnitelman mukaan.
Yhteistestaukseen liittyvän Järjestelmän tulee olla valmis ja Järjestelmätoimittajan omissa testauksissa Xxxxx- vaatimukset täyttävä ennen yhteistestauksen aloittamista. Yhteistestauksen läpivienti vaatii arviolta 5–6 kuukautta. Yhteistestaus on osa potilas- ja apteekkijärjestelmien sertifiointia, jonka läpäiseminen on edellytys Järjestelmän tuotantokäytön aloittamiselle.
5.2.3 Järjestelmätestaus
Järjestelmätestauksella tarkoitetaan Järjestelmätoimittajan tekemää testausta, jossa validoidaan koko Järjestelmän toiminnallisuus ja tarkoituksena on löytää Järjestelmästä mahdolliset ongelmat ja virheet. Lisäksi testataan ei-toiminnallisia, Järjestelmän laatuun liittyviä ominaisuuksia, kuten suorituskykyä, käytettävyyttä ja ylläpidettävyyttä. Testaus tehdään Asiakkaan testausympäristössä, ellei muuta sovita.
Järjestelmätoimittajan vastuulla on tehdä osana toteutusta riittävän kattava Järjestelmän järjestelmätestaus. Asiakas ja Tilaajat osallistuvat siihen vähintään hyväksymällä Järjestelmätoimittajan tekemän järjestelmätestaussuunnitelman, tulokset sekä testausraportit. Asiakkaan ja Tilaajan testaajat voivat osallistua toiminnalliseen testaukseen testaussuunnitelmassa sovittavalla tavalla. Menettely on suositeltavaa erityisesti erittäin kompleksisten toiminnallisuuksien kohdalla, jolloin esim. mahdolliset puutteet tai tarkennettavat asiat määrittelyissä havaitaan mahdollisimman aikaisin.
Asiakas voi suorittaa käytettävyystestausta järjestelmätestauksen aikana.
Osana järjestelmätestausta Järjestelmätoimittajan tulee tehdä jatkuvaa regressiotestausta. Järjestelmätoimittaja voi käyttää järjestelmätestauksessa omia menetelmiään ja valitsemiaan työvälineitä, kunhan järjestelmätestauksen kattavuus on riittävän laajaa. Testiaineistona käytetään Järjestelmätoimittajan generoimaa testidataa tai konvertoitua dataa jos se on mahdollista. Järjestelmätoimittajan tulee automatisoida järjestelmätestitapaukset regressiotestauksen ja jatkokehityksen helpottamiseksi tarkoituksenmukaisissa testauksen kohteissa.
5.2.4 Hyväksymistestaus
Testauksessa sovelluksen toimivuus ja laatu todennetaan sekä yksittäisen toiminnallisuuden osalta että prosessi/työnkulku- ja roolitasolla. Hyväksymistestaus tehdään tuotannon kaltaisessa ympäristössä (hyväksymistestaus-/tuotantotestausympäristö), joka vastaa tarkoituksenmukaisella tavalla tuotantoympäristöä. Asiakas ja Tilaajat voivat halutessaan hyödyntää Järjestelmätoimittajan laatimia järjestelmätestauksen testitapauksia osana hyväksymistestausta.
Hyväksymistestauksen aluksi Järjestelmätoimittaja validoi, että Järjestelmä toimii oikein hyväksymistestaus-
/tuotantotestausympäristössä (savutestaus). Järjestelmätoimittaja esittelee Järjestelmän toimintaa tuotantotestiympäristössä ennalta sovittujen käyttö- tai testitapausten pohjalta, millä voidaan varmistaa järjestelmän päätoiminnallisuudet ja kriittiset ohjelmatoiminnot (luovutustestaus). Tämän jälkeen Asiakas ja
Tilaajat varmistavat omalla vastaanottotestauksellaan, että toteutuksen laatu on sillä tasolla, että laajempi hyväksymistestaus voidaan aloittaa.
Periaatteena on, ellei muuta sovita, että kaikkia testauksen laajuuteen kuuluvia toiminnallisuuksia on päästävä testaamaan, jotta hyväksymistestaus voidaan aloittaa. Yksittäiset virheet tai ongelmat (esim. väärä tieto/arvo käyttöliittymän yksittäisessä kentässä) eivät sen sijaan estä hyväksymistestauksen aloittamista.
Järjestelmätoimittaja toimittaa Asiakkaalle julkaisumuistion.
Testiaineistona käytetään konvertoitua, integraatioilla tuotua sekä manuaalisesti lisättyä dataa. Testauksen aikana tuotettua dataa käytetään Järjestelmästä ulospäin lähtevissä integraatioissa. Käytettävyystestauksessa käytettävästä datasta sovitaan erikseen.
Testaajien käytettävissä olevat ohjeet (mm. uudet toimintatapaohjeet, Järjestelmän käyttöohjeet ja teknologian operatiivisen käytön ohjeet) ovat päivitettynä tai laadittuna ennen hyväksymistestauksen aloittamista.
Asiakas ja Xxxxxxxx suorittavat hyväksymistestauksen tekemänsä suunnitelman mukaisesti ja raportoivat testitapausten pohjalta havaitsemansa havainnot toteutuksesta vastanneelle osapuolelle viipymättä yhden työpäivän sisällä testauksen suorittamisesta. Toteutuksesta vastaava osapuoli tekee tarvittavat virhekorjaukset sovitun testauskierrossyklin mukaisesti sekä raportoi virhekorjauksen edistymistä. Asiakas ja Tilaajat muodostavat testauksen edistymisraportin, josta selviää testauksen kokonaisedistyminen (mitkä testitapaukset on ajettu, kuinka moni on mennyt onnistuneesti läpi, montako päätynyt virheeseen, mikä on korjausvelka jne.).
Järjestelmätoimittaja varmistaa savutestauksella uuden version asennuksen yhteydessä, että versio on asentunut oikein ja vahvistaa Asiakkaalle ja Xxxxxxxxxx tämän jälkeen, että hyväksymistestausta voidaan jatkaa.
Järjestelmätoimittaja kuvaa uuden versiosisällön julkaisumuistiossa, jonka pohjalta testaajat tietävät esim. mitä havaintoja uudessa versiossa pitäisi olla korjaantunut. Hyväksymistestausta jatketaan kunnes hyväksymiskriteerit täyttyvät.
Asiakas ja Xxxxxxxx tekevät hyväksymistestausta ensisijaisesti vaiheittain (eli toteutusinkrementti kerrallaan) ja vaiheen sisällä mahdollisesti iteratiivisesti. Hyväksymistestausvaiheen lopuksi Asiakas ja Xxxxxxx suorittavat tarkoituksenmukaisten testitapausten regressiotestauksen. Järjestelmätoimittaja vastaa, että kertaalleen toimiviksi todetut esim. toiminnallisuudet tai moduulit toimivat myös seuraavissa testauksissa. Vaiheittaista sekä iteratiivista mallia käytettäessä oletuksena on, ellei toisin sovita, että Järjestelmätoimittaja on korjannut edellisen hyväksymistestausvaiheen tunnistetut virheet kohdan 5.4 vaatimusten mukaisesti, vaikka ne eivät olisikaan olleet hyväksymistä estäviä. Tällä estetään korjausvelan kasvu toteutuksen edetessä. Tästä voidaan poiketa Asiakkaan ja Järjestelmätoimittajan yhteisellä päätöksellä iteratiivisen testauksen sujuvan etenemisen varmistamiseksi.
Hyväksymistestauksen osana toteutettava käytettävyystestaus on kuvattu luvussa Käytettävyystestaus.
5.2.5 Tuotantotestaus
Järjestelmän tuotantoon siirtoa ja teknistä käyttöönottoa edeltää Järjestelmätoimittajan suorittama luovutustestaus, jolla tarkoitetaan tässä yhteydessä Järjestelmätoimittajan suorittamaa komponentin tai Järjestelmän toiminnallisuuden testausta, jolla validoidaan tuotantoympäristöön tehdyn asennuksen toimivuus ja varmistetaan, että kaikkein kriittisimmät ohjelman toiminnot toimivat ennen käytön aloitusta.
Järjestelmätoimittajan tekemää testausta voidaan tukea tai täydentää Asiakkaan ja Tilaajien tekemällä
vastaanottotestauksella. Vastaanottotestauksella varmistetaan, että Järjestelmä toimii oikein ja Järjestelmässä oleva data on oikein.
Tuotantotestausta tehdään ensimmäisen käyttöönoton yhteydessä ja tämän jälkeen aina uusien asennusten jälkeen. Ensimmäisen käyttöönoton yhteydessä testaus on laajempaa, mutta päivitysversioiden asennuksen yhteydessä Järjestelmän toimivuus todennetaan vain esim. päätestitapauksilla. Testauksen suorituksen voi myös automatisoida, jos se nähdään tarkoituksenmukaiseksi tavaksi.
5.3 Testityypit
Tässä osiossa kuvataan testityyppejä, joita suoritetaan eri testaustasojen sisällä tai tarvittaessa erikseen.
5.3.1 Tietoliikennetestaus
Tietoliikenteen testauksessa todennetaan yhteys Järjestelmään (ml. portaalit) sekä integraatioiden osalta tarkoituksenmukaiseen ympäristöön ja versioon sekä lähde- että kohdejärjestelmissä. Tarkoituksena on varmistaa yhteyksien toiminta esimerkiksi lähettämällä testitiedosto toiselle palvelimelle. Yllä kuvattu tekninen tietoliikennetestaus tehdään ennen Järjestelmätoimittajan luovutustestausta.
5.3.2 Asennustestaus
Asennustestauksessa testataan, että toteutetun komponentin asennusskripti toimii ja että asennusohjeet pitävät paikkaansa. Tällä testauksella varmistetaan se, että asennuksia voi tehdä myös 3. osapuoli.
5.3.3 Savutestaus
Savutestauksella varmistetaan, että ”piipusta nousee savu”. Savutestaus on nopea, muuta testausta edeltävä testi, jolla varmistetaan Järjestelmän osa-alueen tai korjatun toiminnallisuuden toimivuus esim. tehdään tietojen päivitys tai kysely, ajetaan raportti; varmistetaan, että integroidut palvelimet tunnistavat toisensa.
5.3.4 Toiminnallinen ja tekninen testaus
Toiminnallisessa ja teknisessä testauksessa todennetaan tarkoituksen mukaisissa testaustasoissa mm. seuraavia asioita:
• valmisohjelmiston mukautukset, näkymät ja työnkulut
• tietojen luonti, päivitys ja poisto
• käyttäjien roolit ja niiden oikeudet
• tietojen näkyminen ja suojaukset
• virhekäsittelyt
• käyttöliittymä, raportin ulkoasu, näkymät
• kielisyys
• portaalit
• asennusrutiinit ja -ohjeet
• ulkoiset ja sisäiset liittymät
• konvertoidut tiedot
• käsin syötetyt tiedot
• tarkistukset ja laskennat
• ohjelmien uudelleenkäynnistys
• ohjelmien suorituskyky, käytön vasteajat
• viestintä
• raportit
• tulostus
• uusi ohjelmakoodi
• käyttäjien ohjeistukset (mm. toimintatapa-, Järjestelmän käyttöohjeet)
• käytön ohjeet
5.3.5 Regressiotestaus
Regressiotestaus on aiemmin testatun ohjelman testaus siihen tehtyjen muutosten jälkeen. Testauksella varmistetaan, että muutokset eivät ole tuottaneet tai paljastaneet uusia vikoja ohjelmiston alueilla, joita ei ole muutettu.
5.3.6 Käytettävyystestaus
Käytettävyystestaus on laadullisten ominaisuuksien testausta. Hyvä käytettävyys luo kuvaa laadukkaista Apotti- palveluista sekä vähentää käyttötuen ja koulutuksen tarvetta.
Käytettävyyden osa-alueita ovat:
• Tuloksellisuus
• Tehokkuus
• Opittavuus ja muistettavuus
• Virheettömyys
• Käyttäjätyytyväisyys Käytettävyystestaus kohdistuu seuraaviin:
• ammattilaiskäyttäjien järjestelmät sekä asiakas- ja potilasportaali
• valmisohjelmiston moduulien konfiguraatiot, käyttöliittymänäkymät, mukautukset ja työnkulut
• uudet toiminnallisuudet: käyttöliittymänäkymät ja työnkulut
• käyttäjän suorittamat yksittäiset toiminnot, kuten tietojen luonti, päivitys ja poisto
• Järjestelmän käyttö eri käyttäjäryhmien ja -roolien näkökulmasta, sisältäen asiakas- ja potilaskäyttäjät
• erilaiset käyttöliittymänäkymät, sisältäen mm. käyttöohjeet, raportit ja niiden ulkoasut
• käyttöliittymän terminologia ja sen vastaavuus käyttäjän kieleen
• Järjestelmän ulkoiset integraatiot ja sisäiset liittymät, siltä osin kuin ne näyttäytyvät käyttäjälle toimintojen suorittamisen yhteydessä/taustalla
• Järjestelmän automaattisesti suorittamat toiminnot (esim. päätöksenteon tuki) siinä määrin kuin ne näyttäytyvät käyttäjälle toimintojen suorittamisen yhteydessä
• Järjestelmän yhteiskäyttö ja tuki eri tahojen väliselle yhteistyölle
• käyttäjien ohjeistukset: Järjestelmän käyttöohjeet
• esteettömyys ja saavutettavuus liittyen asiakas- ja potilasportaaliin
Käytettävyyden arviointia tehdään toteutuksen eri vaiheissa alkaen suunnitteluratkaisujen hahmottelusta ja prototyypeistä käyttäjäkeskeisen suunnittelun prosessimallin mukaisesti (ks. luku 3). Käytettävyystestausta tehdään yksikkö-, järjestelmä- ja hyväksymistestauksien aikana. Käytettävyystestausta tehdään tasosta ja testauksen vastuutahosta riippuen eri ympäristöissä: Järjestelmätoimittajan tai Asiakkaan kehitys-, testaus- tai tuotantotestaus-/hyväksymistestausympäristöissä.
Yksikkö- ja järjestelmätestauksen osana toteutettava käytettävyystestaus on luonteeltaan jatkuvaa, iteratiivista ja eritasoisiin toteutuksiin kohdistuvaa. Tavoitteena tässä testauksessa on käytettävyysongelmien havaitseminen ja korjaaminen. Käytettävyysvaatimukset ohjaavat tätä testausta. Testauksen toteuttamisesta voi olla vastuussa joko Asiakas tai Järjestelmätoimittaja. Tämä määritetään testaussuunnitelmassa. Jos Järjestelmätoimittaja on vastuussa testauksen toteuttamisesta, Asiakas toimii testauksessa ohjaavassa ja hyväksyvässä roolissa.
Testauksen tuloksia hyödynnetään käyttötilanteen kuvauksen/määrittelyn tarkentamisessa, liittyvien vaatimusten tarkentamisessa sekä arvioitujen suunnitteluratkaisujen kehittämisessä ja uusien toteuttamisessa.
Hyväksymistestauksen osana toteutettavassa käytettävyystestauksessa lähtökohtana on, että testaus toteutetaan vain niille toiminnallisuuksille tai Järjestelmän osioille, jotka ovat viimeisteltyjä ja joihin ei tule enää muutoksia. Tämä tarkoittaa sitä, että hyväksymistestauksessa ei testata uudelleen jo aiemmin hyväksymistestattuja ja hyväksymistestit läpäisseitä toiminnallisuuksia tai osioita. Tavoitteena tässä testauksessa on käytettävyysvaatimusten toteutumisen varmistaminen ja todentaminen. Käytettävyysvaatimukset toimivat testauksen hyväksymiskriteeristönä. Testauksen toteuttaa Asiakas.
Käytettävyystestauksen menetelminä ovat käyttäjätestausmenetelmät ja käytettävyyden asiantuntija-arvioinnin menetelmät. Käytettävät menetelmät ja niiden soveltaminen määritellään tarkemmin testaussuunnitelmassa.
Käytettävyystestauksesta vastaavat käytettävyysasiantuntijat ja käyttäjätestauksiin osallistuvat tulevat ja potentiaaliset Loppukäyttäjät. Järjestelmätoimittaja tukee käytettävyystestausta tehdyn käytettävyystestaussuunnitelman mukaisesti.
5.3.7 Varmistus- ja palautustestaus
Järjestelmän varmistus- ja palautustestaukset suunnitellaan tehtäväksi otettaessa uusi ympäristö käyttöön. Järjestelmätoimittaja vastaa Järjestelmän varmistus- ja palautustestauksen läpiviennistä ja koordinoinnista. Testausta tukevat Asiakkaan Käyttöpalvelutoimittaja ja integroitavien järjestelmien nykyiset ylläpitotoimittajat tehdyn testaussuunnitelman mukaisesti.
Myös palautusten suorituskyky testataan, jotta voidaan todentaa palautuksien vaatima aika.
Varmistusten ja palautusten suunnittelussa pitää ottaa huomioon liittymät ja muiden järjestelmien varmistus- ja muu operointiaikataulu. Järjestelmän varmistusten pitää olla synkronoitu, jotta voidaan palauttaa tietyn hetken tilanne Tilaajien integroituviin järjestelmiin.
5.3.8 Suorituskyky- ja kuormitustestaus
Suorituskyky- ja kuormitustestauksella tarkoitetaan Järjestelmätoimittajan tekemää testausta, jossa todennetaan Järjestelmän vaatimusten mukainen suorituskyky (esim. vasteajat) ja toisaalta Järjestelmän kyky kestää kuormaa vaatimusten mukaisesti (esim. yhtäaikaisien käyttäjien määrä).
Suorituskyky- ja kuormitustestaus ajoitetaan siten, että se tehdään, kun Järjestelmä on riittävän stabiili ja toteutuksen osalta lähes valmis. Testaus tulee tehdä ajoissa ennen käyttöönottoa, jotta mahdolliset hitaudet ehditään selvittää ennen tuotantoon siirtoa. Jos Järjestelmä otetaan osissa käyttöön, suorituskykytestaus tehdään tarkoituksen-mukaisissa kokonaisuuksissa ennen tuotantoon siirtoa.
Käyttöpalvelutoimittaja osallistuu testaukseen testaussuunnitelman mukaisesti ja on vastuussa suorituskykyongelmien ratkaisemisesta teknisten ympäristöjen osalta. Järjestelmätoimittaja saa käyttää testaukseen valitsemaansa työvälineitä, kunhan ne ovat tarkoitukseen sopivia. Testausta jatketaan niin kauan kunnes Järjestelmän suorituskyky on vaatimusten edellyttämällä tasolla.
Asiakas ja Xxxxxxxx varaavat oikeuden teettää täydentävä suorituskyky- ja kuormitustestaus ulkopuolisella taholla, jos kokevat sen aiheelliseksi. Järjestelmätoimittaja on tällöin velvollinen avustamaan testauksessa sekä korjaamaan mahdolliset havainnot hankkeen virheenkorjausprosessin mukaisesti.
5.3.9 Vikasietoisuustestaus
Vikasietoisuustestauksella tarkoitetaan Järjestelmän kykyä ylläpitää määritettyä suoritustasoa ohjelmistovikojen tai rajapintojen rikkoutumistapauksissa. Vikasietoisuustestaukseen kuuluvat toipuvuus-, vakaus- ja luotettavuustestaukset. Testaus tehdään tuotannon kaltaisessa ympäristössä tai tuotannossa.
Vikasietoisuustestauksen suunnittelusta, läpiviennistä ja koordinoinnista vastaa Käyttöpalvelutoimittaja. Järjestelmätoimittaja osallistuu testaukseen tehdyn testaussuunnitelman mukaisesti ja vastaa Järjestelmän osalta sen toimimisesta oikein mahdollisissa häiriötilanteissa. Lisäksi vikasietoisuustestauksessa testataan mm. käyttökatkon aikainen toimintamalli sekä käyttökatkon aikaiset tulosteet.
5.3.10 Konversiotestaus
Konversiotestauksella tarkoitetaan konversioiden teknistä ja toiminnallista testausta. Teknisessä konversiotestauksessa suoritetaan migraatioteknologioiden päästä päähän -testaus toteutettujen työkalujen yhteistoiminnan ja laadun varmistamiseksi. Testaus kattaa kaikki konversion vaiheet datan pudotuksesta ja sen muunnosta aina aineiston lataamiseen saakka. Toiminnallista testausta tekevät sekä Järjestelmätoimittaja että Asiakas ja Tilaajat. Järjestelmätoimittajan edellytetään todentavan konversion toiminnallinen toimivuus (eli tiedot konvertoituvat oikeisiin kenttiin Järjestelmän tietokannoissa sekä tietoa pystytään päivittämään sekä käyttämään työnkuluissa ja ne näkyvät käyttöliittymällä tai raporteissa oikein) osana järjestelmätestaustaan.
Konversiotestausta tehdään järjestelmätestauksen osana konversiotestaus- sekä järjestelmätestaus- ympäristöissä. Konversiotestausympäristöön voidaan suorittaa konversioita selväkielisenä, jolloin konvertoitavien tietojen määrä tulee pitää suppeana. Konversioiden testaus vaatii yleensä toistoja, eli konversioajon jälkeen tiedot voidaan tarpeen mukaan poistaa seuraavaa ajokertaa varten. Järjestelmätestausympäristöön voidaan lähtökohtaisesti suorittaa ainoastaan konversioita anonymisoituna (katso selitys tässä luvussa hyväksymistestauksen kohdalta). Konversiotestaus suoritetaan konversiotestaussuunnitelman määrittämässä laajuudessa.
Hyväksymistestauksessa suoritetaan konversioiden päästä päähän -testaus. Hyväksymistestauksen tavoitteena on varmistaa konversioprosessin toiminta konversioiden toteuttamiseksi sekä varmistaa käytäntöjen ja
menetelmien toimivuus tuotantokonversioiden toteuttamiseen. Hyväksymistestauksessa konvertoitujen tietojen oikeellisuus todennetaan käyttämällä konvertoituja tietoja prosessien läpiviennissä.
Hyväksymistestauksessa tiedot tulee riittävässä laajuudessa anonymisoida konversiossa siten, että henkilö ei ole tunnistettavissa (esim. henkilön nimi ja katuosoite muutetaan yleisimmiksi), eikä ole suoraan yhdistettävissä hänen henkilötunnukseensa. Hyväksymistestaus suoritetaan hyväksymistestaussuunnitelman määrittämässä laajuudessa.
Konversioiden toteutus on kuvattu tarkemmin migraatio- ja konversiodokumentissa (Liite TS 2.3 Migraatiot ja konversiot).
5.3.11 Tietoturva- ja tietosuojatestaus
Tietoturva- ja tietosuojatestauksella tarkoitetaan testausta, jolla todennetaan Järjestelmän tietoturvallisuus ja tietosuoja vaatimuksia vasten.
Järjestelmätoimittaja on velvollinen huolehtimaan osana toteutusta Järjestelmän tietoturvallisuus- ja tietosuojaperiaatteiden ja vaatimusten täyttymistä. Järjestelmätoimittaja todentaa tämän osana järjestelmätestausta ja esittelee tulokset Asiakkaalle.
Käyttöpalvelutoimittaja vastaa tietoturvasta teknisen ympäristön osalta.
Asiakas ja Tilaajat varaavat oikeuden teettää ulkopuolisella taholla auditoinnin Järjestelmän tietoturvaan ja tietosuojaan ennen käyttöönottoa. Auditoinnin kautta löydetyt mahdolliset poikkeamat ja haavoittuvuudet korjataan normaalin virhekorjausprosessin mukaisesti.
5.3.12 Luovutus- ja vastaanottotestaus
Luovutus ja vastaanottotestaus eivät ole varsinaisesti testaustyyppejä, vaan ne ovat käytännössä 1–3 päivän tilaisuuksia, joihin valitaan tilanteen mukaan tiettyjä toimitettavan Järjestelmän osioita (jos esim. tiedetään Järjestelmätoimittajan takunneen jonkun kanssa, mikä pitää erikseen vielä käydä läpi). Näiden testausten tausta on sopimuksellinen: Järjestelmätoimittaja luovuttaa ja toinen vastaanottaa. Jos lyhyissä tilaisuuksissa todetaan osio toimivaksi, se lähtee laajempaan testaukseen.
• Luovutustestaus: toteutetun järjestelmäjulkaisun luovutus Asiakkaan testaukseen. Sisältö sovitaan ko. testauksen suunnitelmassa. Järjestelmätoimittaja esittelee Järjestelmän toimintaa tuotantotestiympäristössä ennalta sovittujen käyttö- tai testitapausten pohjalta, millä voidaan varmistaa Järjestelmän päätoiminnallisuudet ja kriittiset ohjelmatoiminnot (luovutustestaus).
• Vastaanottotestaus: Järjestelmätoimittajan luovuttaman järjestelmäjulkaisun testaus Asiakkaan toimesta. Sisältö sovitaan ko. testauksen suunnitelmassa. Järjestelmätoimittajan luovutustestauksen jälkeen Asiakas ja Xxxxxxxx varmistavat omalla vastaanottotestauksellaan, että toteutuksen laatu on sillä tasolla, että laajempi hyväksymistestaus voidaan aloittaa.
5.4 Testausprosessi ja havaintojen luokittelu
Kaikista testauksista tehdään erilliset testaussuunnitelmat ja testitapaukset. Asiakas ja Tilaajat hyväksyvät Järjestelmätoimittajan testaussuunnitelmat sekä validoivat halutessaan testitapaukset.
Yksikkötestaussuunnitelmien ja -testitapauksien hyväksynnässä Asiakas ja Tilaajat keskittyvät Järjestelmän sisäisten liittymien (useamman tuotteen kokonaisuus integroidaan toimimaan yhteen) tai uuden tuotetun ohjelmakoodin testaussuunnitelmien ja testitapausten hyväksyntään: Asiakas ja Tilaajat eivät siis hyväksy kaikkia yksikkötestaussuunnitelmia.
Testaussuunnitelmassa kuvataan hankkeen yleisten käytäntöjen (esim. raportointi) lisäksi minimissään:
• Testauksen tavoitteet ja testaustasot
• Testauksen kohde ja rajaus
• Testauksen vaiheet ja aikataulu
• Testauksen riskit ja niiden vaikutuksien välttäminen tai lieventäminen
• Testausprosessi ja testausmenetelmät
• Resursointi sekä roolitus ja vastuut
• Testikierrokset ja testitapaukset
• Testauksen aloitus- ja päättämiskriteerit (pl. käytettävyystestaus)
• Testauksen hyväksymiskriteerit
• Testiympäristöt ja aineistojen hallinta
• Testauksen raportoinnin käytännöt (mm. raportointi, kokoukset)
Järjestelmätoimittaja sekä Asiakas ja Tilaajat nimeävät testaukselle testauspäällikön ja osa-alueiden testausvastaavat. Testauksen etenemisestä raportoidaan sovittujen käytäntöjen mukaan. Asiakas ja Tilaajat hyväksyvät testauksen valmistumisen, kun testaukselle asetetut hyväksymiskriteerit täyttyvät. Kaikista testauksista laaditaan erilliset raportit, jollei muuta ole sovittu.
Tarkempi testausprosessi ja sitä tukevat työvälineet kuvataan varsinaisissa testaussuunnitelmissa sen tahon toimesta, joka on vastuussa testauksen suunnittelusta ja läpiviennistä.
Testauksien aikana dokumentoidaan havaintoja, jotka voivat olla mm. ohjelmavirheitä, muutostarpeita, kehitysehdotuksia, käyttövaltuuksiin tai käyttöympäristöihin liittyviä ongelmia, kielikäännöksiin, dokumentaatioon (mm. käyttäjän ohjeet, käytön ohjeet) liittyviä virheitä tai puutteita tai muita havaintoja.
Alla olevassa taulukossa (Taulukko 9) on kuvattu havaintojen vakavuusluokitus. Vakavuusluokitusta käytetään havaintojen raportoinnissa ja priorisoinnissa, testauksen edistymisraportoinnissa sekä hyväksymiskriteereitä määriteltäessä.
Havainnon vakavuus | Kuvaus | Vaatimuksen varmistus |
1 – Kriittinen | Erittäin vakava virhe tai ongelma, joka on korjattava, jotta testaus voi jatkua. / Testitapausta ei voida testata. / Käyttöönoton estävä virhe tai ongelma. / Kriittinen käytettävyysongelma, joka estää käyttäjää saavuttamasta tavoitetta. | Vaatimusta ei ole toteutettu Järjestelmässä. Valmisohjelman tuotevirhe joka estää testauksen tai käyttöönoton. |
2 – Merkittävä | Testitulos on virheellinen, mutta testaus voi jatkua. Esimerkiksi tieto tallentuu tietokantaan virheellisesti. / Käyttöönoton estävä virhe tai ongelma. / Vakava käytettävyysongelma, joka haittaa merkittävästi tavoitteen saavuttamista. | Osa vaatimuksesta on toteuttamatta tai toteutus on tehty vaatimuksen vastaisesti. Toteutuksen laatu ei täytä vaatimusta. |
3 – Haittaava | Muut virheet tai ongelmat, joilla ei ole suurta merkitystä toiminnan suorittamisen kannalta.. | Toteutuksessa on vähäinen poikkeama vaatimukseen. |
4 – Vähäinen | Vähäinen virhe, ongelma tai muutospyyntö esim. virheilmoituksen muotoiluun liittyvä huomio tai toive, jolla ei ole merkittävää merkitystä käyttäjän toimintaan. Ei estä hyväksyntää tai käyttöönottoa. | Toiminnallisuuden määrittely tai ohje on epätarkka. |
Testauksen kannalta jotkut havainnot eivät ole virheitä tai puutteita toimituksessa, vaan mahdollisia uusia vaatimuksia tai vaatimuksien täydennyksiä. Tällaiset havainnot käsitellään muutoshallinnan prosessin (Liite D Hallintamalli) mukaisesti. Havainto voi olla esimerkiksi käyttöönoton estävä, mutta samalla muutospyyntö.
Havainnolle lisätään muutospyynnön numero havainnon vakavuuden pysyessä samana.
Järjestelmätoimittajan järjestelmätestaus ja Asiakkaan hyväksymistestaus voidaan päättää kun seuraavat hyväksymiskriteerit ovat täyttyneet:
• Kaikki testaussuunnitelman mukaiset testitapaukset on suoritettu onnistuneesti
• Ei avoimia kriittisen (1) tai merkittävän (2) tason havaintoja, tai muutospyynnöt ja poikkeamat tästä ehdosta on käsitelty ja hyväksytty hankkeen johdon kanssa
• Haittaava-tason (3) havainnoista korkeintaan 10 % testauksen löydetyistä havainnoista on korjaamatta, nämä avoimet havainnot on käsitelty ja niiden korjausaikataulusta sovittu
• Vähäinen-tason (4) havainnoille, muutospyynnöille tai kehitysehdotuksille on korjaus- tai toteutussuunnitelma.
• Tunnistetut muutospyynnöt on dokumentoitu ja ei ole avoimia käyttöönoton estäviä muutospyyntöjä.
Testaajat ilmoittavat havainnot Järjestelmätoimittajalle: ilmoituksessa on oltava mukana riittävät tiedot havainnon paikantamiseen sekä toistamiseen. Järjestelmätoimittaja selvittää havainnot ja korjaa Järjestelmän virheet; lisäksi ko. valmisohjelmistojen tuotekehitys selvittää ja korjaa tuotevirheet mahdollisuuksien mukaan.
Havainnon kirjauksessa on tärkeää kuvata mahdollisimman tarkasti mm. seuraavat asiat:
1. Havainnon kirjaajan tunnistetiedot
Havainnon kirjaajan nimi, yhteystiedot, käyttäjärooli sekä havainnon kirjaushetki. Tyypillisesti virheiden hallintajärjestelmä kirjaa nämä tiedot automaattisesti.
2. Ympäristön tunnistetiedot
Havainnon kirjaajan tulee määritellä käytetty ympäristö mahdollisimman tarkasti. Määrittelyyn kuuluu vähintään käytetty tuote/järjestelmäversio sekä siihen oleellisesti liittyvät muut versiotiedot. Näitä ovat mm. käytetty selainversio, käyttöjärjestelmä, työasema, mobiili.
3. Havainnon otsikko
Otsikon tulee olla kuvaava ja yksiselitteinen. Esim. ”Virhe tulostuksessa” vrt. ”Tulostaessa viikkoraporttia vaaka-arkille, otsikkotiedoista puuttuu päiväys”
4. Havainnon tarkka kuvaus
Kuvauksessa pitää selkeästi kertoa yksityiskohtaisesti mitä käyttäjä Järjestelmässä teki. Tämä sisältää käytön mm:
• vaiheet
• syötteet ja näppäinkomennot
• toimintaketjun kuvauksen
• valikkovalinnat
• ohjelman mahdollisesti antamat virheilmoitukset
• onko havainto toistettavissa toisella työasemalla tai eri testihenkilöllä/aineistolla
• erittäin tärkeää on myös kertoa miten käyttäjä odotti Järjestelmän toimivan, koska tämä nopeuttaa havainnon katselmointia ja korjausta.
5. Havainnon liitteet
Havaintoa täydentävät liitteet kuten kuvaruutukaappaukset, antavat arvokasta tietoa Järjestelmätoimittajalle havainnon analysoinnissa ja nopeuttavat käsittelyä.
Järjestelmätoimittaja täydentää havaintoa mm. ohjelmavirheen korjauksen toimitusaikataulusta.
5.5 Testiympäristöt ja niiden hallinta
Tilaajien järjestelmiin integroitu testausympäristö pyritään rakentamaan viimeistään järjestelmä- ja/tai integraatiotestausympäristöihin ja siitä eteenpäin. On mahdollista, että kaikilla Järjestelmään integroituvilla järjestelmillä ei ole erillistä testausympäristöä. Tilaajilta selvitetään testauksen suunnitteluvaiheessa järjestelmäkohtaisesti voidaanko testauksessa käytetty testiaineisto jättää tuotantojärjestelmään, onko testiaineisto poistettava (tälle on varattava aikaa) tai käytetäänkö testiajureita/-simulaatiota.
Tuotantokäyttöä tukevat omat erilliset ympäristöt, jotka ovat tuotannon kopioita: näitä ympäristöjä käytetään vain tuotannon virheiden korjaamiseen ja testausta varten. Tuotantokäytön rinnalla jatkuu Järjestelmän toteutus ja jatkokehitys, joka tarvitsee omat erilliset kehitys-, testaus- ja koulutusympäristöt.
Ympäristöjä on kuvattu tarkemmin Liitteessä L ”Teknisten käyttöympäristöjen kuvaus”.
5.6 Testiaineistot
Järjestelmäkokonaisuutta testataan:
• käsin syötetyllä
• konvertoiduilla
• liittymistä tulevalla ja lähtevällä testiaineistolla.
Testiaineisto (data) suunnitellaan ennen testauksen aloittamista. Testiaineisto pitää tarvittavin osin muokata Järjestelmässä tai anonymisoida testauksissa. Kaikissa testauksissa käytetään konvertoitua dataa, mikäli sitä on jo saatavilla ko. testauksen aikana.
Yksikkötestauksessa käytetään toteutuksesta vastaavan osapuolen generoimaa testidataa tai konvertoitua dataa. Paikallisten integraatioiden testauksessa Asiakas ja Tilaajat vastaavat datan tuottamisesta ja Järjestelmätoimittaja Kansallisten ja alueellisten integraatioiden testauksessa. Järjestelmätestauksessa käytetään Järjestelmätoimittajan generoimaa dataa tai konvertoitua dataa (jos on saatavilla).
Konversio- ja käytettävyystestauksessa käytetään Asiakkaan ja Tilaajien tuottamaa dataa. Vikasietoisuus-, tietoturva- ja tietosuojatestauksien data suunnitellaan ko. testaussuunnitelmissa.
Järjestelmätoimittaja vastaa varmistus- ja palautustestauksien sekä suorituskyky- ja kuormitustestauksen testidatasta. Suorituskyky- ja kuormitustestauksessa käytetään konvertoitua sekä liittymistä tuotettua dataa, testauksen aikana syntynyttä dataa Järjestelmästä ulospäin lähtevissä liittymissä sekä kuormitustyövälineellä tuotettua kuormaa.
Hyväksymistestauksessa Asiakas ja Tilaajat vastaavat datasta: testauksessa käytetään konvertoitua dataa, Järjestelmään sisääntulevista integraatioista tuotettua dataa sekä käsin lisättyä dataa. Hyväksymistestauksessa luotua dataa käytetään Järjestelmästä ulospäin lähtevissä liittymissä.
Tuotantotestauksessa Asiakas vastaa käytettävästä datasisällöstä; esimerkiksi käytetään tätä käyttötarkoitusta varten luotu testiasiakasta tai -potilasta.
5.7 Testaustyövälineet ja tuki
Testaustyövälineet sovitaan projektin suunnitteluvaiheessa: tavoitteena on yhteiskäyttöiset ja teknisesti yhteensopivat työvälineet erityisesti testitapauksien ja havaintojen hallintaan Asiakkaan ja Järjestelmätoimittajan välillä. Järjestelmätoimittajan ei oleteta sisällyttävän automatisoituja testaustyövälineitä tarjoukseensa. Mutta oletuksena on, että Järjestelmätoimittaja pyrkii tehokkuuteen ja hyvään laatuun esimerkiksi hyödyntämällä automatisoitua regressiotestausta.
Järjestelmätoimittaja kouluttaa Asiakkaan ja Tilaajan testaajat Järjestelmätoimittajan testauksen työvälineiden käyttöön tarvittavalla tasolla. Asiakas kouluttaa testaajansa sekä Järjestelmätoimittajan työvälineiden käyttöön, mikäli päädytään eri testaustyövälineeseen kuin mitä Järjestelmätoimittajalla on.
Testauksessa tarvitaan myös muita testausresursseja kuten tietokoneita, mobiililaitteita (tabletit, puhelimet), skannauskoneita sekä lääkintälaitteita.
Taulukko 10 Yhteenveto testauksessa tarvittavista työvälineistä
Työväline | Tarkoitus |
Testauksenhallinta | Vaatimusten hallinta Testauksen suunnittelu (mm. testitapauksien luonti ja ylläpito, linkitys vaatimuksiin) Testauksen suorittaminen Virheiden hallinta Testaustilanteen raportointi |
Testauksen automatisointi | Mitä testejä automatisoidaan ja millä työvälineillä (esim. Load runner), kuvataan ao. testauksen työsuunnitelmassa. |
Testiajurit (testaussimulaatio) | Ohjelmistokomponentti tai testaustyöväline, joka korvaa sen osan, jolla kontrolloidaan tai kutsutaan nyt testattavaa komponenttia tai järjestelmää (drivers, stubs). |
Järjestelmän konfiguraation versionhallinta ja asennustyöväline | Xxxx konfiguraation versionhallintaan ja asennuksien seurantaan eri kehitys- ja testausympäristöissä |
Asennuspakettien siirto eri ympäristöjen välillä | Konfiguraatioiden ja ohjelmakoodien siirrossa käytettävät työvälineet kuvataan testaussuunnitelmassa. |
Järjestelmä/verkko: seurantajärjestelmä tai puhelinnumero | Ilmoitetaan esim. verkkohäiriöistä niiden selvitystä varten • Asiakkaan yhteystiedot • Järjestelmätoimittajan yhteystiedot |
Testausdokumenttien tallennuspaikka | Testaussuunnitelmat ja raportit tallennetaan hankkeen työtilaan. • SharePoint (avataan omat kansiot) |
Avointen asioiden hallinta | Käytetään esim. MS Exceliä, sijainti hankkeen työtilassa. |
Työajankirjaus | Testaukseen käytetyn työajan seuranta |
Muiden järjestelmien tuki | Xxxxxxx mukaan tuen yhteystiedot mm. • Sharepoint/työtila • MS Office • sähköposti • livemeeting (esim. Lync) • kirjoittimet • työasema • puhelin / puhelinkokoukset (conference meeting). |
Työväline | Tarkoitus |
Muut testauksessa tarvittavat välineet | Järjestelmän toiminnallisuuden testaaminen: mm. työasemat, kannettavat tietokoneet, mobiililaitteet, skannerit, viivakoodin lukulaitteet. lääkintälaitteet. |
5.8 Testaajien koulutus
Ennen testauksen aloittamista testaajille järjestetään testauksen aloituspalaveri, jossa käydään läpi mm. testausprosessi havaintojen ja muutoshallinnan prosessien kanssa, testaustyövälineiden käyttö ja Järjestelmätoimittajan julkaisumuistio.
Lisäksi käydään läpi testaussuunnitelmat mm.
• tiedottaminen, kokoukset
• aikataulut
• resurssit
• riskit, niiden ennaltaehkäisy ja vaikutuksien lieventäminen
• testausalueet, aineistot, ympäristöt
• testausmenetelmät, työvälineet, dokumentointitavat, myös virheenkirjaus ja tallennuspaikat
• testiluokan materiaali, työasemat, kirjautuminen, tulostaminen
• tuntikirjaukset
Lisäksi testauksen informointipalavereja järjestetään ajoittain riippuen testauksen vaiheesta tai toiminnon kriittisyydestä. Testauksen seurantapalavereja järjestetään erillisen testaussuunnitelman mukaisesti.
Asiakkaan ja Xxxxxxxxx testaajat sekä Järjestelmätoimittajan asiantuntijat heidän tukenaan testaavat samassa fyysisessä tilassa (esim. koulutusluokassa). Tämä työskentelymuoto tukee ratkaisun ja Järjestelmän oppimista sekä nopeuttaa havaintojen ja mahdollisten virheiden käsittelyä.
5.9 Testausrooli ja vastuut
Taulukko 11 on kuvattu testauksessa tarvittavat roolit ja niiden vastuut. Oletetaan että Järjestelmätoimittajalla on vastaavat vastinpariroolit ja -resurssit kuin Asiakkaalla.
Taulukko 11 Testausroolit ja vastuut
Rooli | Kuvaus |
Asiakkaan testauspäällikkö | • suunnittelee ja johtaa testausta sekä raportoi • valvoo ja varmistaa testauksen laatua ja edistymistä • varmistaa, että testaussuunnitelmia noudatetaan • suunnittelee ja priorisoi Asiakkaan testaukset yhdessä osa-alueiden testausvastaavien kanssa • raportoi Asiakkaan hankepäällikölle |
Järjestelmätoimittajan testauspäällikkö | • suunnittelee, johtaa Järjestelmätoimittajan testausta sekä raportoi • valvoo ja varmistaa testauksen laatua ja edistymistä • suunnittelee ja toteuttaa Järjestelmätoimittajan testaukset • varmistaa, että testaussuunnitelmia noudatetaan • vastaa julkaisumuistion kokoamisesta ja toimittamisesta Asiakkaalle • raportoi Asiakkaan testauspäällikölle ja hankepäällikölle |
Asiakkaan osa-alueiden testausvastaavat | • suunnittelee, johtaa ja raportoi osa-alueensa testauksen • vastaa testitapausten ja testitulosten hyväksynnästä • päättää havaintojen luokituksesta yhdessä Järjestelmätoimittajan kanssa • Järjestelmän julkaisujen suunnittelu yhdessä Asiakkaan kanssa • raportoivat Asiakkaan testauspäällikölle |
Asiakkaan ja Xxxxxxxxx julkaisupäällikkö (Release Manager) | • Järjestelmän julkaisujen suunnittelu ja toteutus yhdessä Tilaajien järjestelmien julkaisuvastaavien, testauspäälliköiden sekä palvelupäälliköiden kanssa • koordinointi eri osapuolien kesken |
Asiakkaan konfiguraation hallintavastaava / teknisen ympäristön vastaava | • vastaa testausympäristöjen versioista ja julkaisuista sekä niiden hallinnasta • koordinoi testausympäristön aktiviteetteja • informoi Järjestelmän käytössä olosta ja käyttökatkoista • Järjestelmän julkaisujen suunnittelu yhdessä Asiakkaan kanssa • raportoi osa-alueen testausvastaaville |
Asiakkaan testauksen työvälineiden asiantuntija | • vastaa testaustyövälineiden konfiguroinnista ja koulutuksesta • tukee testaajia testien suunnittelussa ja havaintojen kirjaamisessa testaustyövälineiden osalta • tukee testauspäällikköä ja osa-aluevastaavia testausraportoinnissa |
Asiakkaan Käyttöpalvelutoimittaja | • vastaa teknisistä ympäristöistä • vastaa tietyistä teknisistä testauksista testaussuunnitelman mukaisesti • raportoi Asiakkaan testauspäällikölle ja konfiguraation hallintavastaavalle / teknisen ympäristön vastaavalle |
Asiakkaan ratkaisuarkkitehdit - toiminnallinen ja tekninen | • vastaa toiminnallisten/teknisten vaatimusten täyttymisestä • vastaa testitapausten ja testitulosten hyväksynnästä yhdessä osa- alueen testausvastaavien kanssa • kirjaavat ja ylläpitävät testien tuloksia ja havaintoja • havaintojen analysointi ja ratkaisuehdotuksien teko yhdessä asiantuntijoiden, pääkäyttäjien ja testaajien kanssa • raportoi testausvastaaville ja testauspäällikölle |
Asiakkaan asiantuntijat | • luovat testitapaukset yhdessä xxxxxxxxxx kanssa • tukevat testausta • havaintojen kirjaus, analysointi ja ratkaisuehdotuksien teko yhdessä pääkäyttäjien, testaajien, ratkaisuarkkitehtien ja Järjestelmätoimittajan asiantuntijoiden kanssa |
• raportoi testausvastaavalle | |
Käytettävyys- asiantuntijat | • osallistuvat käytettävyystestauksen suunnitteluun • luovat käytettävyystestitehtävät ja määrittelevät arvioitavat kohteet yhdessä substanssiasiantuntijoiden kanssa • toteuttavat käytettävyystestaukset • kirjaavat havainnot, analysoivat tulokset ja kuvaavat kehitysehdotukset yhdessä substanssiasiantuntijoiden kanssa • raportoivat käytettävyysosa-alueen testausvastaavalle ja testauspäällikölle |
Asiakkaan Järjestelmän pääkäyttäjät | • luovat testitapaukset yhdessä testaajien ja asiantuntijoiden kanssa • testaavat • kirjaavat ja ylläpitävät testien tuloksia ja havaintoja • havaintojen analysointi ja ratkaisuehdotuksien teko yhdessä asiantuntijoiden, testaajien, ratkaisuarkkitehtien ja Järjestelmätoimittajan asiantuntijoiden kanssa • ylläpitää Järjestelmän konfigurointeja (mm. valintalistojen arvoja) • vastaa käyttäjien pääsystä Järjestelmään • raportoivat osa-alueen testausvastaavalle |
Asiakkaan testaajat | • luovat testitapaukset yhdessä asiantuntijoiden ja Järjestelmän pääkäyttäjien kanssa • testaavat • kirjaavat ja ylläpitävät testien tuloksia ja havaintoja • havaintojen analysointi ja ratkaisuehdotuksien teko yhdessä asiantuntijoiden, pääkäyttäjien, ratkaisuarkkitehtien ja Järjestelmätoimittajan asiantuntijoiden kanssa • raportoivat osa-alueen testausvastaavalle • Huom. Käytettävyystestauksiin osallistuvat erilaisiin käyttäjäryhmiin kuuluvat käyttäjät; he eivät pääsääntöisesti osallistu testien suunnitteluun tai raportointiin. |
Tilaajien integraatioiden järjestelmävastaavat | • koordinoivat muiden järjestelmien integraatioiden testausta • luovat testitapaukset yhdessä asiantuntijoiden, Järjestelmän pääkäyttäjien ja Tilaajien kanssa • kirjaavat ja ylläpitävät testien tuloksia ja havaintoja • havaintojen analysointi ja ratkaisuehdotuksien teko yhdessä asiantuntijoiden, pääkäyttäjien, ratkaisuarkkitehtien ja Järjestelmätoimittajan asiantuntijoiden kanssa • raportoivat osa-alueen testausvastaavalle |
Järjestelmätoimittajan toiminnalliset ja tekniset asiantuntijat | • tukevat Asiakkaan testaussuunnitelmien ja testitapausten laadinnassa • kirjaavat ja ylläpitävät testien tuloksia ja havaintoja |
• havaintojen analysointi ja ratkaisuehdotuksien teko yhdessä asiantuntijoiden, pääkäyttäjien, testaajien ja ratkaisuarkkitehtien kanssa • virheiden korjaus ja testaukset (mm. yksikkö-, regressiotestaukset) • tukevat Asiakkaan testausta • raportoivat testausvastaavalle | |
Järjestelmätoimittajan Toteutusprojektin projektipäällikkö | • testauksessa havaittujen korjauksien suunnittelu ja toimitus testaukseen • Järjestelmän julkaisujen suunnittelu yhdessä Asiakkaan kanssa |
Asiakkaan Jatkuvien palvelujen palvelupäällikkö | • tuotannossa havaittujen korjauksien suunnittelu ja toimitus testaukseen • Järjestelmän julkaisujen suunnittelu yhdessä Asiakkaan ja Xxxxxxxxx julkaisupäällikköjen, testauspäälliköiden ja Järjestelmätoimittajan palvelupäällikön kanssa |
5.10 Konfiguraation hallinta testauksen aikana
Asiakkaan konfiguraation hallintavastaava vastaa Asiakkaan testausympäristöjen tasosta ja versionhallinnasta. Hän suunnittelee Järjestelmän korjaustoimenpiteet yhdessä Järjestelmätoimittajan teknisen arkkitehdin ja muiden asiantuntijoiden kanssa.
Järjestelmätoimittajan tekninen tiimi paketoi omassa kehitysympäristössään testatun asennuspaketin, jonka Järjestelmätoimittajan asiantuntijat asentavat Järjestelmätoimittajan ohjeistuksen mukaisesti Asiakkaan kehitys- ja testausympäristöihin. Asennuspaketti sisältää muutetut osiot ja niiden asennusohjeistuksen. Muutoksien sisältö ja testattavat osa-alueet kuvataan julkaisumuistioissa (release notes).
Toimitetuista asennuspaketeista ilmoitetaan Asiakkaan konfiguraation hallintavastaavalle, joka pitää toimitetuista järjestelmäasennuksista/muutoksista lokia.
Järjestelmätoimittajan tekninen tiimi ylläpitää konfiguraatiolokia (mitä korjauksia lisätty perusasennuspakettiin, mitä parametreja on muutettu, mitä lisätoiminnallisuuksia on asennettu sekä asennuspakettien lähetyksestä jne.).
Asiakkaan konfiguraation hallintavastaava vastaa Järjestelmätoimittajan (Jatkuvat palvelut) sekä Käyttöpalvelutoimittajan kanssa Asiakkaan kehitys-, testaus-, koulutus- ja tuotantoympäristöjen päivittämisestä. Mukautuksen laajuudesta ja kokonaisuudesta riippuen Järjestelmätoimittaja tai Käyttöpalvelutoimittaja toteuttavat/asentavat toimitetut muutokset (esim. mukautukset) ja uudet versiot Asiakkaan hallinnoimiin ympäristöihin sekä ylläpitävät asennuslokia.
5.11 Tuotettava dokumentaatio
Alla olevaan tTaulukko 12 on kuvattu testaukseen liittyvä dokumentaatio ja vastuujako sen tuottamisessa. Asiakas ja Tilaajat hyväksyvät kaiken Järjestelmätoimittajan tekemän dokumentaation.
Taulukko 12 Tuotettava dokumentaatio
Dokumentti | Kuvaus |
Testaussuunnitelmat | Jokaisesta testauksesta tehdään oma testaussuunnitelma. Suunnitelman teosta vastaa testauksesta vastuussa oleva taho (esim. järjestelmätestauksen suunnittelusta vastaa Järjestelmätoimittaja ja vastaavasti hyväksymistestauksen suunnittelusta Asiakas ja Tilaajat). Asiakas ja Tilaajat hyväksyvät Järjestelmätoimittajan tekemät testaussuunnitelmat ennen testauksien alkua. |
Informaatiomateriaali | Testauksen kickoff-/infomateriaali: mm. testaus-, havaintojen ja muutoshallinnan prosessit, testausohjeistus (yleisellä tasolla ja per testauskierros), testaustyövälineiden käyttö, julkaisumuistioiden läpikäynti. |
Testitapaukset | Jokaiselle testille tunnistetaan ja dokumentoidaan testitapaukset, joiden pohjalta testaus tehdään. Testitapaukset pohjautuvat vaatimuksiin ja määrittelyihin ja niiden teosta vastaa testauksesta vastuussa oleva taho (esim. järjestelmätestauksen testitapauksien tekemisestä vastaa Järjestelmätoimittaja ja vastaavasti hyväksymistestauksen testitapauksien tekemisestä Asiakas ja Tilaajat). Testitapauksien tulee olla riittävän tarkalla tasolla ja mahdolliset poikkeamat raportoidaan havaintoina. |
Versiosisällön julkaisumuistio (release notes) | Testaukseen toimitetun version julkaisumuistiossa kuvataan mm. ko. ratkaisun tai Järjestelmän versiossa tuodut uudet piirteet sekä korjaukset, niiden vaikutukset muualle sekä testattavat alueet, asennettavat tiedostot, asennusohjeet, käyttäjädokumentaatio, muutokset ja virhekorjaustilanne. |
Havaintoloki | Xxxxxx kirjataan kaikki eri testauksissa tehdyt havainnot, joita käsitellään esimerkiksi koulutuksen (mikä on tyypillisin käyttäjän tekemä virhe) tai ohjeistuksen (miten ohjetta pitäisi selkiyttää) näkökulmasta. |
Konfiguraatioloki | Loki, johon kirjataan kunkin ympäristön sisältö ja versiot. |
Testauksen edistymisraportti | Testauksen edistymisestä raportoidaan säännöllisesti eli aina testikierroksen päätteeksi tai muuna sovittuna ajankohtana. Raportointi voidaan tehdä osana projektin viikkoraporttia, jos niin sovitaan. Raportoinnista vastaa testauksesta vastuussa oleva taho, kuitenkin siten, että esim. hyväksymistestauksen osalta Järjestelmätoimittaja tukee raportointia raportoimalla virheiden tai ongelmien korjausten edistymisestä. Raportissa yksilöidään testauksen tilanne testitapauksia vasten (montako suoritettu, montako suoritettu onnistuneesti, montako päätynyt virheeseen) sekä tehtyjen havaintojen määrä virheiden/ongelmien vakavuusluokituksen sekä tilan (esim. avoinna/avattu uudelleen, selvityksessä, korjauksessa, uudelleen testauksessa, suljettu) mukaan, kuinka monta kertaa samaa virheen korjausta on |
testattu, korjausvelka, ennuste korjauksen toimituspäivästä, trendi ja ennuste testin kestosta/päätöspäivämäärästä, ottaen huomioon nykyinen testausvauhti/edistyminen, riskien tilanne ja muutostarpeet. | |
Loppuraportti | Kaikista testausvaiheista laaditaan loppuraportti, joka esitellään. Loppuraportin tekemisestä vastaa testauksesta vastuussa oleva taho. Loppuraportissa kuvataan mm. testauksen eteneminen ja tulokset (esim. tilanne testauksen päättyessä, poikkeamat testauksessa), avoimiksi jääneet havainnot ja virheet sekä korjausaikataulu, testauksen työmäärät, sekä mahdolliset huomiot ja suositukset. |
5.12 Testauksen vastuunjako
Taulukko 13 on kuvattu testauksen tehtävien vastuunjako.
Taulukko 13 Testauksen vastuujako
Työvaihe | Tehtävä | Järjestelmä- toimittaja | Asiakas | Tilaajat | Muut |
Suunnittelu | Xxxxxxxxxx suunnitelmat | ||||
Testauksen pääsuunnitelman luonti | O | V, H | O | O | |
Testauksen aikataulun tarkentaminen | V | V, H | O | I | |
Testauskierroksien sisältöjen suunnittelu | O | V, H | O | O | |
Testauksen resursointi | V | V | O | O | |
Testauksen pääsuunnitelman hyväksyntä | O | V, H | O | O | |
Informaatiomateriaali ja tilaisuudet | O | V, H | O | O | |
Julkaisunhallinta | |||||
Julkaisunhallinnan strategia | O | V | O | O | |
Julkaisunhallinnan suunnitelma ja aikataulu | O | V | O | O | |
Testauksen työvälineet | |||||
Testausvälineiden hankinta | I | V, H | I | I | |
Testausvälineiden asennus, konfigurointi ja testaus | I | V | I | I | |
Testaajien koulutus | O | V | O | O | |
Vaatimusmäärittelyjen siirto testauksen hallintavälineeseen | I | V | I | I | |
Ohjelmasimulaatioiden (testiajurit; stubs and drivers) toteutus ja testaus | V | V | I | - | |
Asiakkaan järjestelmäympäristöjen tekniset testaukset | Järjestelmän varmistus- ja palautustestaus | O | H | O | V |
Tietoliikenteen testaus | O | H | O | V | |
Vikasietoisuustestaus | O | H | O | V | |
Täydentävä suorituskyky- ja kuormitustestaus: ulkopuolisen asiantuntijan testaus | O | V, H | O | O | |
Tietoturvallisuus ja - suojatestaus: ulkopuolisen auditoijan testaus | O | V, H | O | O | |
Testauksen hallinta testauksien ajan | Havaintojen hallinta | ||||
Havaintojen dokumentointi (havaintoloki) | V | V | V | V | |
Havaintojen analysointi ja priorisointi | V | V | V | V | |
Virheiden korjaus ja uudelleentestaus | V | V | V | V | |
Testauksen seuranta ja raportointi päävastuun mukaisesti | |||||
Testauksen edistymisraportit | V | V | O | O | |
Testauksen loppuraportin hyväksyntä | O | V, H | O | O | |
Konfiguraationhallinta | Konfiguraationhallinta | ||||
Asennuspaketin toimittaminen | V | I | - | I | |
Järjestelmäympäristöjen konfiguraation hallinta | V | I | - | V | |
Yksikkötestaus | Yksikkötestaus – kukin osapuoli vastaa oman toteutuksensa testauksesta | ||||
Testaussuunnitelman luonti | V | V, H | O | O | |
Testiskenaarioiden ja tapauksien luonti | V | V, H | O | O | |
Testiaineiston luonti | V | V | O | O | |
Varmistus- ja palautustestaus | V | H | - | O | |
Asennustestaus | V | V | O | O | |
Yksikkötestaus (toiminnallinen ja tekninen testaus) | V | V | O | O | |
Yksikkötestaus (konversio-ohjelmat) | V | V | O | O | |
Käytettävyystestaus | V | V | O | O | |
Suorituskykytestaus (ohjelmakoodi) | V | V | O | O | |
Tietoturvallisuus ja - suojatestaus | V | V | O | O | |
Regressiotestaus | V | V | O | O | |
Yksikkötestauksen hyväksyntä | V, H | V, H | I | I | |
Integraatiotestaus | Integraatiotestaus – Kansalliset ja alueelliset | ||||
Kansallinen sertifiointi | V | I | - | - | |
Testaussuunnitelman luonti | V | H | I | O (käyttöpalvelut), V | |
Testiskenaarioiden ja tapauksien luonti | V | I | I | V | |
Testiaineiston luonti | V | I | I | - | |
Julkaisumuistio | V | I | I | I | |
Asennustestaus | V | I | I | O | |
Integraatiotestaus (toiminnallinen ja tekninen testaus) | V | I | I | I | |
Suorituskykytestaus | V | I | - | O | |
Tietoturvallisuus ja - suojatestaus | V | O | O | O | |
Regressiotestaus | V | O | O | O | |
Integraatiotestaus – Tilaajakohtaiset | |||||
Testaussuunnitelman luonti | O | V | O | O | |
Testiskenaarioiden ja tapauksien luonti | I | V, H | O | - | |
Testiaineiston luonti | I | V, H | O | - | |
Julkaisumuistio | O | V | I | I | |
Asennustestaus | O | I | I | V | |
Integraatiotestaus (toiminnallinen ja tekninen testaus) | O | V | O | O | |
Suorituskykytestaus | O | V | O | O | |
Tietoturvallisuus ja - suojatestaus | O | V | O | O | |
Regressiotestaus | O | V | O | O | |
Integraatiotestauksen hyväksyntä | |||||
Integraatiotestauksien hyväksyntä (kansalliset, alueelliset, tilaajakohtaiset) | I | V, H | I | I | |
Järjestelmätestaus | Järjestelmätestaus | ||||
Asennustestaus | V | I | I | O | |
Testaussuunnitelman luonti | V | H | O | O | |
Testiskenaarioiden ja tapauksien luonti | V | I | I | I | |
Testiaineiston luonti | V | O | I | I | |
Julkaisumuistio | V | H | I | I | |
Järjestelmätestaus (toiminnallinen ja tekninen testaus) | V | O, H | I | I | |
Käytettävyystestaus | V | V | I | I | |
Suorituskykytestaus | V | I | - | O | |
Tietoturvallisuus ja - suojatestaus | V | O | O | O | |
Regressiotestaus | V | O | O | O | |
Konversiotestaus | O | V | O | O | |
Järjestelmätestauksen hyväksyntä | I | V, H | I | I | |
Hyväksymistestaus | Hyväksymistestaus | ||||
Testaussuunnitelman luonti | O | V, H | O | O | |
Testiskenaarioiden ja tapauksien luonti | O | V | O | O | |
Testiaineiston luonti | I | V | O | O | |
Savutestaus | V | H | I | I | |
Luovutustestaus | V | H | I | I | |
Vastaanottotestaus | I | V, H | O | O | |
Hyväksymistestaus (toiminnallinen ja tekninen testaus) | O | V | O | O | |
Hyväksymistestauksen tuki | V | I | I | I | |
Käytettävyystestaus | O | V | I | I | |
Suorituskyky- ja kuormitustestaus | O | V | O | O | |
Tietoturvallisuus ja - suojatestaus | O | V | O | O | |
Regressiotestaus | O | V | O | O | |
Konversiotestaus | O | V | O | O | |
Hyväksymistestauksen hyväksyntä | I | V, H | I | I | |
Tuotantotestaus | Tuotantotestaus | ||||
Testaussuunnitelman luonti | O | V, H | O | O | |
Testiskenaarioiden ja - tapauksien luonti | O | V | O | O | |
Testiaineiston luonti | I | V | O | O | |
Tietoturvallisuus ja - suojatestaus | O | V | O | O | |
Suorituskyky- ja kuormitustestaus | O | V | O | O | |
Luovutustestaus | V | H | I | I | |
Vastaanottotestaus | I | V, H | O | O | |
6 Julkaisun- ja konfiguraationhallinta
Tässä luvussa kuvataan julkaisun- ja konfiguraationhallinnan prosessit ylätasolla. Prosessit tarkennetaan Toteutusprojektin projektisuunnitteluvaiheessa. Näitä prosesseja noudatetaan sekä Toteutus- ja Käyttöönottoprojektien että Jatkuvien palvelujen aikana. Tavoitteena on taata Järjestelmän tehokas ja häiriötön käyttö erityisesti hyväksymistestauksessa ja tuotantokäytössä. Hyvin toimivien prosessien avulla varmistetaan järjestelmäversion tehokas ja häiriötön siirto teknisestä ympäristöstä toiseen ja eri ympäristöissä kehitettyjen osaversioiden yhdistely. Alla oleva kKuva 13 antaa periaatekuvan näiden prosessien laajuudesta ja soveltamiskohteesta.
Kuva 13 havainnollistetaan järjestelmäversion julkaisua erityisesti siltä osin, miten uusi versio etenee Järjestelmätoimittajan ympäristöstä Asiakkaan ympäristöihin. Järjestelmätoimittaja kehittää järjestelmäversiota ensin omassa ympäristössään, josta se tuodaan Asiakkaan Kehityspalvelut (KEPA) -palvelualueelle, Järjestelmätoimittajalle varattuun JDEV- ja JCONF -ympäristöön. Järjestelmätoimittajan JDEV- ja JCONF -
ympäristöstä se tuodaan Asiakkaan ADEV- ja ACONF -ympäristöihin, versionumero jäädytettynä ja dokumentoituna muutoksineen. Myös rinnakkainen kehitystyö on mahdollista.
Asiakkaan KEPA-palvelualueelta versio viedään Asiakkaan Testauspalveluihin (TEPA), josta versio lopulta viedään Asiakkaan Tuotantopalveluihin (TUPA) eli tuotantoon.
Järjestelmän julkaisun-, konfiguraation-, version- ja jakelunhallinta perustuu vakioituihin toimintamalleihin ja rooleihin.
Tässä luvussa kuvattuja julkaisun-, jakelun- ja konfiguraationhallinnan prosesseja ei edellytetä noudatettavan Järjestelmätoimittajan omassa tuotekehityksessä. Niiden tarkoitus on tuottaa ja ylläpitää kokonaiskuvaa siitä, mitä testattuja ja hyväksyttyjä ohjelmistomoduuleita Asiakkaalle toimitettavassa Järjestelmässä kulloinkin on, mitkä moduulit muodostavat yhdessä toimivan kokonaisuuden ja missä komponentteja käytetään.
Vaatimus: Järjestelmätoimittajalta edellytetään osioissa 6.4.1–6.4.5 esiteltyjen Asiakkaan roolien tai Järjestelmän oman julkaisu-, jakelun-, konfiguraation- ja versionhallinnan kehysraamin sisältämien Asiakkaalle määriteltyjen roolien koulutusta ja tukea koko Järjestelmän elinkaaren ajan käyttöönoton alusta alkaen (Asiakkaan kehitysympäristön käyttöönotosta alkaen). Koulutusvastuut on määritetty tarkemmin Koulutuksen pääsuunnitelma -dokumentissa (ks. liite TS 2.7 Koulutuksen pääsuunnitelma). Koulutuksen ja tuen tarkoitus on
mahdollistaa Asiakkaan oma toiminta Järjestelmän tehokkaan ja häiriöttömän päivittämisen ja käytön varmistamisessa.
6.1 Julkaisunhallinta
Julkaisunhallinta tarkoittaa Järjestelmän tulevien toiminnallisten ja teknisten ominaisuuksien käyttöönoton suunnittelua, aikataulusta ja hallittua käyttöönottoa yhteen koottuna nk. julkaisuihin (Release). Jokainen julkaisukokonaisuus hallinnoidaan, testataan ja käyttöönotetaan yhtenä kokonaisuutena. Julkaisunhallintaa tehdään tiiviissä yhteistyössä toteutuksen, testauksen ja käyttöönoton kanssa.
Julkaisut sisältävät ensimmäisen käyttöönoton sisällön lisäksi muutosehdotuksia, tuotannon kehitysehdotuksia sekä projektin ja tuotannon havaitsemien virheiden korjauksia. Muutosehdotuksia tulee johtuen mm. lainsäädännön, valtionhallinnon toiminnan tai muista vastaavista muutoksista. Mahdolliset muutokset käsitellään hankkeen muutosprosessin mukaisesti ja toteutetaan julkaisunhallinnan päätösten mukaisesti.
Julkaisunhallinnassa suunnitellaan julkaisujen aikataulut (julkaisukalenterissa esim. neljä vuosittaista pääjulkaisua ja tarvittaessa välijulkaisuja) ja kuvataan julkaisujen hyväksyntämenetelmät ja -kriteerit sekä menettelytavat normaali- ja hätäjulkaisujen (ad hoc) läpivientiin.
Aikataulujen suunnittelussa otetaan huomioon toiminnan rauhoitetut ajankohdat, julkaisun rauhoitus-
/jäädytysajankohdat, Järjestelmän ohjelmistokehityksen, hankkeen projektien vaiheistuksen ja valmisohjelmistojen tuotekehityksen julkaisut, mahdolliset ohjelmistojen versionkorotukset sekä Järjestelmään integroituvien järjestelmien omat julkaisut.
Asiakkaan julkaisusta vastaava henkilö luo hankkeen julkaisunhallinnan suunnitelman yhteistyössä Tilaajien sekä Järjestelmä- ja Käyttöpalvelutoimittajien kanssa Toteutus- ja Käyttöönottoprojektien suunnitteluvaiheessa.
Julkaisuhallintaa suunnitellaan ja tehdään yhteistyössä Asiakkaan ja toimittajien (mm. projektipäälliköiden, testauspäälliköiden, konfiguraation hallintavastaavien / teknisen ympäristön vastaavien sekä toiminnallisten ja teknisten ratkaisuarkkitehtien) välillä.
Asiakkaan julkaisusta vastaava henkilö johtaa ja koordinoi julkaisua Asiakkaan ympäristöön. Julkaisun suunnittelussa analysoidaan mahdolliset julkaisukohteet sekä päätetään kunkin julkaisun laajuus, sisältö ja aikataulu. Julkaisukohteisiin liittyvät muutokset tunnistetaan ja niputetaan ko. julkaisuun (käytännössä näiden toteuttaminen aikataulutetaan ja aloitetaan).
Julkaisun sisällön toteuttaminen ja testaus tehdään Toteutus- tai Käyttöönottoprojektien tai Jatkuvien palvelujen puitteissa. Asiakkaan julkaisupäällikkö tai julkaisuvastaava osallistuu näiden projektien ja palvelujen edistymiskokouksiin ja he saavat tilanneraportit.
Julkaisun hyväksynnän ja siitä seuraavan hyväksymistestaukseen ja tuotantoon viennin jälkeen julkaisun käyttäytymistä seurataan tehostetusti ja tehdään tarvittavia korjaavia toimenpiteitä. Julkaisun hyväksymistestaukseen ja tuotantoon viennin jälkeen alkaa rauhoitusajanjakso (julkaisun stabilisointi), jolloin käyttöönotetaan vain hätäjulkaisuja.
Järjestelmätoimittaja osallistuu julkaisunhallinnan suunnitteluun ja toteuttamiseen mm. tuomalla suunnitteluun mukaan omat best practice -käytäntönsä, osallistumalla sisällön ja aikataulujen suunnitteluun, ylläpitämällä konfiguraatiota ja jakelutietoja sekä toimittamalla toteutuksen julkaisumuistiot (release notes /release record).
6.2 Jakelunhallinta
Jakelunhallinta vastaa Asiakkaan kehitys-, testaus-, koulutus- ja tuotantoympäristöihin tehtävien Järjestelmän jakeluversioiden suunnittelusta, aikatauluttamisesta ja siirron kontrolloinnista.
Jakelunhallinnan ensisijainen tavoite on varmistaa, että ympäristöjen eheys on suojattu ja oikeat konfiguraatiorakenneosat jaettu oikeisiin ympäristöihin.
6.3 Konfiguraationhallinta
Järjestelmän konfiguraationhallinnalla tarkoitetaan vakioitujen ja hyväksyttyjen määritelmien ja sääntöjen noudattamista Järjestelmän ja sen sisältämien ohjelmistojen sekä toiminnallisten ympäristöjen kehitys, testaus- ja ylläpitotyössä, sekä prosessia joka vastaa toteutuksessa tarvittavien konfiguraation rakenneosiin liittyvästä informaatiosta ja niiden suhteista. Informaatiota hallitaan koko konfiguraation rakenneosan (Configurable Item, CI) elinkaaren ajan.
IEEE standardin (729–1983) mukaan konfiguraationhallinta sisältää neljä osa-aluetta;
1. Identifioinnin (Identification)
2. Versionhallinnan (Control)
3. Tilatiedon ylläpidon (Status Accounting)
4. Auditoinnin ja arvioinnin (Audit and Review) Nämä neljä osa-aluetta on määritelty seuraavasti:
• Identifiointi
Identifiointimalli kuvaa Järjestelmän ohjelmistotuotteen rakenteen ja siihen liittyvien sovellusten, varusohjelmistojen ja tietovarastojen tuottajat ja versiot, nimeää siihen kuuluvat komponentit ja niiden tyypit sekä kokoaa ne mahdollisesti yhdeksi identifioitavaksi järjestelmäkokonaisuudeksi (Järjestelmä). Identifioinnin tuloksena voidaan tarvittaessa osoittaa yksilöity sovellus tai sovelluskomponentti kokonaisuudesta, johon voidaan tarvittaessa viitata muista Järjestelmän osista ja kuvauksista.
• Versionhallinta
Versionhallinta sisältää Järjestelmän ohjelmistotuotteen julkaistujen versioiden ja niihin tehtyjen muutosten hallintatuotteen (Järjestelmän) koko elinkaaren ajan. Versionhallinnalla varmistetaan ohjelmiston yhtenäisyys luomalla ns. perustuotteen pääversiot ja niistä Järjestelmän elinkaaren aikana tuotettavat mahdolliset päivitysversiot. Toteutusprojektissa versionhallinta on Järjestelmätoimittajan vastuulla. Tuotantovaiheessa noudatetaan palvelukuvauksessa määritettyä versionhallintaa (ks. Liite PS 2.1).
• Tilatiedon ylläpito
Tilatiedon ylläpito sisältää Järjestelmän komponenttien ja siihen tehtyjen muutospyyntöjen tallentamisen ja niiden raportoinnin sekä tuotteen komponentteja koskevien tietojen kokoamisen ja ylläpidon.
• Auditointi ja arviointi (testaus)
Auditoinnilla ja arvioinnilla pystytään takaamaan Järjestelmän käytettävyyden ja virheettömyyden (täydellisyyden ja eheyden) validointi ja yhtenäisen komponenttikokoelman säilyttäminen. Tämä saavutetaan mm. varmistamalla Järjestelmän komponentteihin liittyvien kuvausten oikeellisuus ja riittävyys ja tarvittava historiatieto.
Järjestelmätoimittaja noudattaa Asiakkaalle julkaisemansa kokonaisuuden osalta seuraavia perusperiaatteita:
• Järjestelmätoimittaja ylläpitää kirjastoa, jossa on kaikki määritellyt ja hyväksytyt versiot:
1) Järjestelmän osista sekä
2) muista osista, jotka muodostavat luotettavan ja tehokkaasti toimivan Järjestelmäkokonaisuuden. Esimerkkejä edellä mainituista ovat toimitetut ohjelmistokomponentit, tietokantaohjelmistot, kolmannen osapuolen järjestelmäkomponentit ja Järjestelmän käyttöön soveltuvat selainohjelmistot.
• Kaikki osat edellä mainitussa kirjastossa ovat muutoksen- ja jakelunhallinnan alaisena ja kirjattu konfiguraationhallintajärjestelmään.
• Järjestelmätoimittaja käyttää konfiguraationhallintajärjestelmää (CMS) tai vastaavaa menetelmää hallinnoidakseen toimittamansa Järjestelmän konfiguraatiotietoja ammattimaisella tavalla. CMS sisältää työkalut konfiguraation rakenneosien tietojen ja niiden suhteiden keräämiseen, säilyttämiseen, hallinnointiin, päivittämiseen ja esittämiseen.
• Jakeluversioissa käytetään ohjelmistoja vain edellä mainitusta kirjastosta.
• Jokainen jakeluversio tunnistetaan yksilöllisesti (nimeämiskäytäntö). Jakeluversion tunniste tyypillisesti sisältää viittauksen konfiguraation rakenneosaan (ts. komponentin nimeen) ja version numeron.
• Konfiguraatioiden rakenneosat ja riippuvuudet tallennetaan konfiguraatiotietokantaan tai vastaavaan.
• Konfiguraation rakenneosat versioidaan olemassa olevan versiointi-/nimeämiskäytännön mukaisesti, joka mahdollistaa perustason järjestyksen tai päiväyksen identifioimisen.
• Järjestelmätoimittaja säilyttää muodollisesti hyväksyttyä konfiguraation perustasoa, jota hallitaan muutosprosessilla. Konfiguraation perustasoa käytetään tulevien kokoonpanojen, jakeluversioiden ja muutosten perustana. Konfiguraationhallinnan perustasoa voidaan käyttää Järjestelmän palauttamiseen tunnettuun konfiguraatioon, jos muutos tai jakeluversio epäonnistuu.
Selvyyden vuoksi mainitaan, että Järjestelmätoimittajan vastuulla ei ole ylläpitää jatkuvan palvelun aikana tässä kappaleessa kuvatulla tavalla tietoa sellaisista muutoksista, jotka Asiakas on tehnyt Järjestelmään käyttäen Järjestelmän ominaisuuksia. Näiden muutosten hallinnointi on Asiakkaan vastuulla.
6.4 Julkaisun- ja konfiguraationhallinnan roolit ja vastuut
Tässä osiossa esitellään Asiakkaan julkaisun- ja konfiguraationhallinnan roolit ja vastuut, jotka on esitelty kKuva
14. Kuva myös havainnollistaa, missä eri vaiheissa rooleja käytetään. Järjestelmätoimittajan vastuulla on kouluttaa Asiakkaan henkilöstö siten, että Asiakkaan nimetyiltä henkilöiltä löytyy roolien vaatima osaaminen.
Kuva 14 Julkaisun- ja konfiguraationhallinnan roolit ja vastuu
6.4.1 Järjestelmäversion projektipäällikkö
Projektipäällikön tehtävänä on varmistaa jokaisen uuden järjestelmäversion valmistus ja toimitus sovitussa ajassa läpi jokaisen palvelualueen Jatkuviin palveluihin luovutukseen asti. Projektin aikana järjestelmäversion projektipäällikön on voitava seurata projektin edistymistä ja pystyttävä reagoimaan siinä mahdollisesti eteen tuleviin ongelmakohtiin. Tämä tapahtuu määrämuotoisella projektimallilla, johon liittyvät versioiden siirrot teknisestä ympäristöstä seuraavaan käyttöönottomallin mukaisesti. Arviointi- ja tarkistuspisteillä tarkistetaan version käytettävyys käyttämällä vakiomuotoisia tehtäviä ja raportteja projektin tilasta.
6.4.2 Järjestelmän kehitys- ja konfiguraatiopäällikkö
Kehitys- ja konfiguraatiopäällikön tavoitteena on varmistaa, että sovittuja menetelmiä Järjestelmän mukauttamisessa ja mahdollisessa ohjelmakoodin luomisessa, muuttamisessa ja testaamisessa noudatetaan. Mukauttamisen ja ohjelmakoodin hallitsemiseksi kehitys- ja konfiguraatiopäällikön on tarjottava ohjelmistosuunnittelijoille järjestelmä, joka mahdollistaa Järjestelmään kohdistuvien muutospyyntöjen tekemisen ja niihin vastaamisen. Hän ylläpitää järjestelmäkehityksen tiekarttaa sekä mahdollistaa projektien ja merkittävien muutosten toteuttamisen luomalla yksityiskohtaisen projektisuunnitelman. Muutosten ja projektien vetovastuu siirtyy Järjestelmäversion projektipäällikölle suunnitelmien hyväksynnän jälkeen.
6.4.3 Ohjelmistosuunnittelijat
Ohjelmistosuunnittelijan tehtävänä on työstää omalta osaltaan projektin vaatimia tehtäviä, joita voivat olla mm. mukautus, ohjelmointi, testaus ja dokumentointi. Tehtävien suoritus ei saa tarpeettomasti häiritä muiden ohjelmistosuunnittelijoiden työtä. Ohjelmistosuunnittelijoiden on myös kyettävä kommunikoimaan ja koordinoimaan työtä keskenään esim. ilmoittamalla työtehtävien saamisesta päätökseen tai selvittämällä mahdollisesti komponenttien välillä esiintyneitä konflikteja. Kustakin ohjelmistokomponentista pidetään yllä versiohistoriaa, sekä tietoa siitä, miksi ja millaisia muutoksia komponentteihin on tehty. Ohjelmisto voidaan jäädyttää perusversioiksi Järjestelmätoimittajan toimittajamallin mukaisesti tietyissä kohdissa, mikä mahdollistaa esim. kehitystä eri laitealustoja tai toiminnallisuuksia varten toisistaan riippumatta.
6.4.4 Testaajat
Testaajat varmistavat tuotteen olevan alkuperäisen määritelmän ja tavoitteen mukainen. Testaajien on kyettävä testaamaan eri versioita sekä ylläpitämään testaustapahtumista kirjaa siitä, mitä vakio- ja määrämuotoisia testejä millekin versiolle on tehty ja millaisin tuloksin. Mahdollisesti havaitut poikkeustilanteet tai virheet raportoidaan sopiville henkilöille (projektipäällikkö ja ohjelmistosuunnittelijat) ja korjatut kohdat testataan uudelleen.
6.4.5 Laatupäällikkö
Laatupäällikön tehtävänä on varmistaa Järjestelmän korkea laatu. Tämä tarkoittaa Apotti- järjestelmäympäristössä sovittujen menettelytapojen suorittamista ja tulosten asianmukaista kirjaamista ja hyväksymistä määrämuotoisella ja hyväksytyllä tavalla. Mahdollisesti havaitut poikkeustilanteet ja virheet on huomioitava ja korjautettava ja korjaukset toimitettava kaikkiin ohjelmiston versioihin, joita korjaus koskee. Käyttöönotettaville versiolle on tehtävä määrämuotoiset vakioidut ja hyväksytyt testaustapahtumat ennen tuotantoon siirtoa sekä seurattava Loppukäyttäjien mahdollisesti tuotteesta antamaa palautetta.
7 Projekteissa käytettävät ohjelmistotyökalut
Järjestelmätoimittaja käyttää Asiakkaan niin vaatiessa Asiakkaan tarjoamia ohjelmistotyökaluja projektinhallintaan (aikataulu, resurssit, riski, Avoimet asiat, ratkaistavat asiat, Vaatimustenhallinta, Muutoshallinta, Dokumentinhallinta, Laadunhallinta)
Järjestelmätoimittajalla tulee olla valmiudet käyttää tarvittaessa myös omia riittävän laadukkaita työkalujaan projektiensa ja niiden tehtävien hallitsemiseen.