Asiakkaan osallistuminen

kirjoittaa, koska ei ole välttämättä tehty esimerkiksi teknologiavalintoja, jotka saattaisivat vaikuttaa suojausten rakentamiseen.

Mikäli pidettäisiin kiinni siitä, että kaikki määritykset tehtäisiin tuotekehityksen alussa, määritystyöhön menisi niin paljon aikaa, että tuotetta ei enää tarvittaisi.

6.1.2 Asiakkaan osallistuminen

Asiakkaan osallistumista ohjelmistokehityksen eri vaiheisiin pidettiin hyvin tärkeänä.

Osallistumista toivottiin ketterän kehityksen menetelmien mukaisesti vaatimusten analysoinnista aina valmiin tuotteen testaukseen asti.

Koettiin, että järjestelmätoimittajan voi olla vaikea ymmärtää vaatimuksia ja hahmottaa, miten ne pitäisi tehdä järjestelmään. Asiakkaan kanssa pitäisi neuvotella sopimusneuvotteluvaiheessa, mitä vaatimukset tarkoittavat. Koska toimittaja joutuu pilkkomaan asiakkaan vaatimukset teknisiksi vaatimuksiksi tai Scrum -maailmassa tehtäviksi, pidettiin hyvänä, että asiakas tai auditoija katsoisi toimittajan näkemyksen vaatimuksista. Asiakas pystyisi arvioimaan, onko järjestelmän toimittaja ymmärtänyt vaatimukset oikein ja vaikuttavatko toteutusratkaisut hyviltä.

Ehdotettiin, että käytäisiin vaatimukset läpi yhdessä ja purettaisiin ne auki ohjelmistoon tarvittavien toimintojen kautta. Yhdessä mietittäisiin esimerkiksi lokitus -toimintoa; mitkä vaatimukset kuuluvat siihen toimintoon. Jos asiakkaan toimintaympäristö ei tue kaikkia vaatimuksista toteutettavia ratkaisuja, sellaiset vaatimukset pitäisi pystyä poistamaan vaatimuksista. Ihmeteltiin, miksi pitäisi tehdä ratkaisuja, joita ei pysty hyödyntämään, kun niillä on kuitenkin eurovaikutus kaikilla. Toivottiin, että tehtäisiin vain ne toiminnot, joita todellisuudessa tarvitaan sekä jätettäisiin pois ne vaatimukset, joilla ei ole vaikutuksia operatiiviseen toimintakykyyn.

Ennen tilauksen tai sopimuksen tekemistä olisi tärkeää yhdessä purkaa vaatimukset käyttötapauksiksi. Tällöin jo alussa saataisiin molemmin puolin yhteisymmärrys, missä selviäisi asiakkaan toiveet. Toimittajalle selviäisi tällöin, että kykeneekö hän tekemään oikeanlaisen tuotteen. Tietoturva-arviointeja ja katselmointeja on pyritty saamaan jo

62

suunnitteluvaiheessa, jossa katsotaan toteuttamiskelpoisuus tietoturvan osalta.

Katselmointeja on voitu myös pitää voitetun tarjouskilpailun jälkeen ennen suunnitteluvaihetta, mikäli projektissa on ollut tarvetta tarkentaa vaatimuksia.

Yhdessä yrityksessä tietoturvavaatimusten tarkennus oli osana tuotekehitysprosessia.

Asiakkaalta pyydettiin vahvistukset esitettyihin ratkaisuihin, koska haluttiin varmistaa, että ratkaisut olisivat riittävällä tasolla. Ennen kaikkea oli havaittu, että epäselvät tai tulkinnanvaraiset ehdottomat tietoturvavaatimuksen oli parempi selvittää edeltä käsin.

Todettiin, että tällainen menettely ei ole ollut toimittajalle edullista kiinteähintaisissa sopimuksissa, mutta toisaalta sitä ei voi kiertääkään, vaan työ oli ollut pakko tehdä.

Toimittaja esitti, että tietoturvavaatimukset käytäisiin tarkemmin läpi työpajoissa, joita pidettäisiin sopimuksen jälkeen noin kuukauden verran. Siinä toimittajalle ja asiakkaalle tarkentuisi ohjelmiston tietoturvaan liittyvät ominaisuudet.

Myös näissä (tietoturva) määrityksissä voisi olla tällaisia työpajoja. Olisi alussa tiedostettu, että nämä käydään toimittajan kanssa läpi ja sovitaan, miten olisi optimaalisin tehdä tietoturva. Tai vaatimuksen tulisi olla niin yleisellä tasolla, että sen voisi joustavasti ottaa käyttöön siihen omaan ympäristöönsä sen vaatimuksen. Olisi mahdollisuus, että käytäis yhteistyössä työpajana tällaiset vaatimukset, että täyttää asiakkaan antaman idean.

Hankintavaiheessa sitä ei välttämättä osata kuvata, kun sitä järjestelmää ollaan tilaamassa/ostamassa… Voisi olla hankintaprosessin osana. Että kaikilla on alussa selvänä, että nämä on vaatimukset, jotka tiedetään, mutta sen jälkeen meillä on kuukauden aika, jossa nää vaatimukset sitten katotaan, mitä se tarkottaa.

Vaatimukset kehittyvät työn edetessä iteratiivisessa ohjelmistokehityksessä. Asiakkaan pitäisi siten olla mukana arvioimassa tietoturvan riittävyyttä kehitystyön aikana. Asiakas haluttaisiin pitää mukana, koska tietoturvaan liittyviin rajausten ja ohjauksen tekemiseen tarvitaan asiakkaalta ohjausta missä tahansa projektin vaiheessa. Mikäli tietoturva tehdään todella laadukkaasti, se myös maksaa paljon. Hintaan vaikuttavasta määrityksestä annettiin esimerkkinä loppukäyttäjän konfiguraatiomahdollisuudet. Mitä laajemmat mahdollisuudet käyttäjille annetaan, sitä enemmän tietoturva-asioita pitäisi ottaa huomioon.

63

Käyttäjien osallistuminen kehitysprosessiin katsottiin myös tarpeelliseksi. Kun käyttäjät olivat olleet mukana aina muutaman viikon välein, he olivat nähneet esittelyä kehittyvästä ohjelmistosta ja sitä kautta oli pystytty vastaamaan paremmin käyttäjän tarpeisiin. Tällä oli pyritty pääsemään myös parempaan laatuun.

Haastateltavat toivat esille, että tietoturva on käytettävyyden kanssa käsi kädessä, sekä käytettävyys liittyy olennaisesti tuotteeseen ja toteutettaviin ratkaisuihin. Tämän vuoksi olisikin hyvä yhdessä sopia tietoturvan ja käytettävyyden kannalta optimaaliset ratkaisut.

Yhdessä projektissa kehitystyö oli tehty tiiviisti asiakkaan kanssa ilman kattavaa vaatimusmäärittelyä. Ohjelmistokehitystä tehnyt asiantuntija vaikutti tyytyväiseltä työtapaan.

Joo, että sen (iteratiivinen kehitys) oon kokenu erittäin hyvänä. Ei oikeestaan paremmin ois voinu mennä. Et sitä harjotellaan ensin, missä oon ollu mukana, tämmönen yhteistyöhanke puolustusvoimien kanssa. Sitä on tietosesti yhdessä kehitetty ja yhdessä määritelty ja keksitty lisää ominaisuuksia ja tälleen iteratiivisesti tehty eteenpäin.

Kaikkien asioitten ottaminen huomioon alkuvaiheessa on varmasti mahotonta tai se vaatii äärimmäistä asiantuntevuutta, että pystyy niin tarkasti määrittelemään kaiken. Sitä mukaa, ku asioita tulee vastaan tuotekehityksen aikana, on hyvä, jos niihin pystyy puuttumaan siinä. Tämmösiä kokemuksia mulla on ollu. Ehkä tuo hanke, missä ite oon ollu mukana, on ollu hieman erilainen. Puolustusvoimat on ollu siinä mukana tavallaan kehityskumppanina. Se ei oo sillä tavalla valmiin laitteen hankkimista.

Lisäksi hän toivoi tietoturva-asiantuntijan osallistumista ohjelmistokehitykseen koko tuotekehitysprosessin ajan. Asiantuntijan tulisi tietää, millä tavalla auditointi tehdään ja mitä järjestelmältä siihen vaaditaan. Suunnittelija oli saanut käsityksen, että auditoinnit tehdään vähän tapauskohtaisesti, sekä vaatimukset auditoinnille voivat muuttua kehitettävän ohjelmiston mukaan. Tietoturva-asiantuntijan toivottiin siis osallistuvan pitkäjänteisesti kehitystyöhön. Koettiin, että muutaman päivän mukana olemisesta ei ole juurikaan apua tietoturvan kehittämiseen. Palaute voi jäädä liian vajaaksi, kun hän ei tiedä missä mennään ja missä tietoturva-asioita käydään läpi.

64

Mikäli tietoturvaa tarkasteltaisiin koko kehitystyön ajan, ero tavoiteltavan ja toteutuneen tietoturvan välillä ei kasvaisi liian suureksi. Työ voitaisiin ohjata takaisin kohti tavoitetilaa, kun olisi enemmän tarkastuspisteitä. Toisaalta koettiin myös, että projektin edistymistä käydään jo nykyään säännöllisesti läpi. Katsotaan yhdessä, miten järjestelmä rakentuu ja missä vaiheessa ollaan menossa. Tällaista edistymistä voitaisiin seurata säännöllisesti myös tietoturvan osalta.