Miika Laitila

KETTERÄT MENETELMÄT TURVALLISUUSKRIITTISESSÄ OHJELMISTOKEHITYKSESSÄ

JYVÄSKYLÄN YLIOPISTOTIETOJENKÄSITTELYTIETEIDEN LAITOS

2023

TIIVISTELMÄ

Laitila, MiikaKetterät menetelmät turvallisuuskriittisessä ohjlelmistokehityksessäJyväskylä: Jyväskylän yliopisto, 2016, 31 s.Tietojärjestelmätiede, kandidaatin tutkielma Ohjaaja: Halttunen, Veikko

Ketterät ohjelmistokehitysmenetelmät ovat raivanneet tiensä ei-kriittiseen järjestelmäkehitykseen viime vuosikymmenen aikana ja näin ne ovat syrjäyttäneet perinteisiä kurinalaisia suunnitelmavetoisia menetelmiä. Ketteryys on todistetusti tehostanut ohjelmistojen kehitystä nopeuttamalla toimitusaikoja ja parantamalla järjestelmien laatua. Tähän on päästy ketterän filosofian inkrementaalisen kehityksen ja projektien eri osakkaiden läheisen yhteistyön avulla. Jonkin aikaa epäiltiin ketteryyden olevan sopimaton lähestymistapa suuriin, monimutkaisiin ja hajautettuihin kehitysprojekteihin, mutta tämä väite on myöhemmin saatu todistettua vääräksi. Kuitenkin ketterien menetelmien sopivuus turvallisuuskriittiseen kehitystyöhön, jossa kehitetään tiukasti viranomaisten puolesta säädeltyä järjestelmää, on vielä melko niukasti tutkittu alue. Tiukkoja säädöksiä pidetäänkin suurimpana esteenä löyhään dokumentointiin perustuvien ketterien menetelmien käytölle turvallisuuskriittisellä alueella. On kuitenkin todisteita ketteryyden onnistuneista implementoinneista alueella, kuin myös selkeitä teoreettisia suosituksia niiden käytölle. Ketteriä menetelmiä ei ole voitu implementoida puhtaasti yksin, koska säädökset vaativat kehityselinkaarelta säädösvaatimusten jäljitettävyyttä aina vaatimusmäärittelystä kooditasolle asti. Siksi ketteriä menetelmiä täytyy räätälöidä siten, että inkrementaalisen kehitystyön rinnalla toteutetaan jatkuvaa dokumentaatiota ja järjestelmän testausta. Tämä taas monimutkaistaa yksinkertaisuuteen perustuvaa kehitysfilosofiaa ja lopputuloksena saatu menetelmä on eräänlainen hybridi, joka sekoittaa ketterän menetelmän ja suunnitelmavetoisen menetelmän piirteitä.

Asiasanat: Turvallisuuskriittisyys, ketterät menetelmät, suunnitelmavetoiset menetelmät, V-malli, säädökset, Scrum, XP

ABSTRACT

Laitila, MiikaBachelor’s ThesisJyväskylä: University of Jyväskylä, 2016, 31 p.Information Systems, Bachelor’s Thesis Supervisor: Halttunen, Veikko

Agile methods have pushed their way to non-critical software devel-opment area during last decade and they have little by little over-taken traditional plan driven software development methods. There is strong evidences, that agile methods have enhanced software devel-opment process, which has resulted faster development times and more quality products. Agile method’s incremental development cy-cles and close interactions with different stakeholders have mainly made it possible. While ago, it was thought that agile methods cannot be implemented to large and complicated projects, but studies have proved that they can. However there is not yet much proves that ag-ile methods can be fitted to safety-critical development projects, which has been regulated strictly by authorities. Strict regulations can be seen as the largest barrier in agile adoption in this area because regulations require accurately documented traceability from develop-ment process, and agile methods do not generally provide that process. Even so, there is some practical findings how agile methods have been implemented successfully in safety-critical area, also some theoretical recommendations have been given in literature. Agile methods cannot be implemented alone in the safety-critical area, be-cause of regulation authorities required traceability which must been documented from requirements to down until code. But they can be implemented, if agile methods are tailored and blended with tradi-tional plan-driven methods. With careful tailoring, it is possible to make living documentation which is updated incrementally during it-erations. This makes development method more complicated which is not in harmony with agile values. So development process won’t be generic agile, but some kind of hybrid method with agile and plan-driven practices.

Keywords: Safety-critical, agile methods, plan-driven methods, V-model, regulations, Scrum, XP

KUVIOT

Kuvio 1 V-mallin mukainen kehityselinkaari (Ge ym., 2010)..............11Kuvio 2 Kokonaiskuva Scrumista, jonka sprintin pituus on 30 päivää (Wolff, 2012; Fitzgerald ym., 2013)....................................................15Kuvio 3 Kotikenttäanalyysi, jonka profiili on ketteryyden ja kurinalaisuuden sekoitus (Boehm & Turner, 2003)............................21Kuvio 4 Ketterä V-malli McHughin ym. (2013) mukaan......................23Kuvio 5 QUMAS:n räätälöity Scrum, joka on sovitettu säädeltyyn turvallisuuskriittiseen kehitystyöhön (Fitzgerald ym., 2013)..............25

TAULUKOT

Taulukko 1 Järjestelmäkehitysmenetelmän ymmärtämisen ja käytön tasot...................................................................................................20

SISÄLLYS

TIIVISTELMÄABSTRACTKUVIOTTAULUKOT1 JOHDANTO.....................................................................................6

2 TURVALLISUUSKRIITTINEN JÄRJESTELMÄ JA SEN KEHITYS.............82.1 Säädökset ja turvallisuuskriittinen järjestelmä......................82.2 Turvallisuuskriittisyyden vaatimat kehityksen osaprosessit..92.3 Perinteinen tapa kehittää turvallisuuskriittistä järjestelmää

............................................................................................10

3 KETTERÄT MENETELMÄT.............................................................133.1 Ketterän ohjelmistokehityksen evoluutio ja filosofia...........133.2 Ketterien menetelmien käytön oletetut rajoitteet...............16

4 KETTERÄT MENETELMÄT TURVALLISUUSKRIITTISESSÄ OHJELMISTOKEHITYKSESSÄ................................................................18

4.1 Organisaatiorakenteen määrittäminen kotikenttäanalyysin avulla...................................................................................18

4.2 Yleisiä suosituksia ketterien menetelmien käyttöön turvallisuuskriittisessä ympäristössä...................................21

4.3 Ketteryyden käytännön implementointi..............................23

5 YHTEENVETO JA JOHTOPÄÄTÖKSET.............................................26

LÄHTEET.............................................................................................28

1 JOHDANTO

Ketterien menetelmien käyttö ohjelmistokehitysmenetelminä on kasvanut valtavasti viime vuosikymmenen aikana ja niiden käytön tehokkuudesta on hiljalleen saatu luotettavia tuloksia erilaisissa projektiympäristöissä, myös sellaisista ympäristöistä joihin menetelmät katsottiin epäsopiviksi. Kuitenkin ketteryyden käyttämisestä turvallisuuskriittisissä projekteissa on melko niukasti raportteja ja tutkimusjulkaisuja, ja pääsääntöisesti kriittisiä ohjelmistoja on kehitetty suunnitelmavetoisten menetelmien avulla. Fitzgerald (2013) toteaakin nasevasti turvallisuuskriittisen kehitysalueen olevan ketterien menetelmien tutkimuksen viimeinen virstanpylväs.

Ketteryyden käytöstä on kuitenkin todisteita turvallisuuskriittisistä kehitysympäristöistä, ja menetelmistä eniten on implementoitu Scrumia ja XP:tä. Kirjallisuuden perusteella on havaittavissa, että ketteriä menetelmiä ei ole otettu käyttöön puhtaasti yksin, vaan useimmiten suunnitelmavetoisten menetelmien kanssa yhdessä. (Cawley, Wang & Richardson, 2010). Tämän vuoksi tässä tutkielmassa esitellään perinteinen tapa kehittää turvallisuuskriittistä järjestelmää ja ketteristä menetelmistä esitellään lyhyesti eniten käytetyt Scrum ja XP. Lukijan oletetaan kuitenkin tuntevan ketterien menetelmien perusperiaatteet.

Turvallisuuskriittiset järjestelmät ovat järjestelmiä joiden häiriöistä voi seurata henkien menetyksiä, huomattavia omaisuusvahinkoja tai vahinkoja ympäristölle. Turvallisuuskriittiseksi järjestelmäksi voidaan myös katsoa järjestelmä, jonka häiriö voi johtaa seurauksiin jotka on määritelty ei-hyväksytyiksi. (Knight, 2002). Adbelaziz ym. (2015) toteavat turvallisuuskriittisen järjestelmän olevan järjestelmä, joka on vapautettu onnettomuusmahdollisuuksilta, ja Heeager ja Nielsen (2009) kertoo turvallisuuskriittisten järjestelmien olevan useimmiten upotettuja järjestelmiä. Tällaisten järjestelmien kehitystyötä usein säädellään ja valvotaan erilaisten säädösten ja standardien avulla, joiden tarkoitus on taata kehitettävän laitteen turvallinen käyttö (Fitzgerald ym., 2013

7

). Turvallisuuskriittisyys ja säätely kulkevat siis poikkeuksetta käsi kädessä. Järjestelmäkehitys ei siis automaattisesti ole turvallisuuskriittistä, mutta kohdealue johon järjestelmää kehitetään, voi tehdä siitä sellaista. Kohdealueita joiden nähdään olevan säädeltyjä ja turvallisuuskriittisiä ovat muun muassa ilmailu-, auto-, ydinvoima- ja ravitsemusteollisuus sekä lääkinnälliset teollisuuden alat (Fitzgerald ym., 2013). Turvallisuustekijät ja säädökset tuovat kehitystyöhön nipun välttämättömiä vaatimuksia, jotka on pakko toteuttaa ja todistaa toteutetuksi, jotta järjestelmä on turvallinen käyttöönotettavaksi. Näin ollen tällaisen järjestelmän kehittäminen eroaa ei-kriittisen järjestelmän kehittämisestä, koska kehitykseltä vaaditaan käytännössä kahden asiakkaan vaatimusten toteutusta ja viranomaistahojen säädösvaatimuksien toteutus tulee todistaa tarkasti koko kehityselinkaaren ajalta. Tämän vuoksi myös ketterät menetelmät on nähty sopimattomiksi turvallisuuskriittisiin projekteihin, koska ne vaativat huomattavan paljon raskasta dokumentaatiota ja se on ristiriidassa ketteryyden arvoja vastaan.

Tämän kandidaatin tutkielman tarkoituksena on tehdä kirjallisuuskatsaus siitä miten turvallisuuskriittisiä järjestelmiä on totuttu kehittämään, sekä miten ketteriä menetelmiä on onnistuttu implementoimaan kyseisissä kriittisissä kehitysympäristöissä. Tutkielmassa läpikäytävät raportit käsittelevät pääsääntöisesti järjestelmäkehitysprojekteja, jotka toteuttavat Yhdysvaltain ruoka- ja lääkehallinnon (FDA) säädöksiä lääkinnällisellä kehitysalueella. Tutkimuskysymys on siis lyhyesti seuraavanlainen: Miten ketteriä menetelmiä on onnistuttu implementoimaan turvallisuuskriittisessä järjestelmäkehityksessä ja millaisia suosituksia niiden käytöstä on kirjallisuudessa havaittavissa? Tutkielma perustuu kirjallisiin lähteisiin, jotka ovat tutkimusraportteja, case-tutkimuksia, konferenssijulkaisuja ja alan oppikirjoja. Ensimmäisessä sisältöluvussa tarkastellaan perinteistä turvallisuuskriittistä kehitystä, jossa on totuttu käyttämään suunnitelmavetoisia menetelmiä, annetaan muutama esimerkki turvallisuuskriittisestä järjestelmästä sekä kuvaillaan turvallisuuskriittisyyden tuomat osaprosessit kehitykseen. Tämän jälkeen lukijalle avataan ketterien menetelmien filosofiaa, niiden evoluutiota sekä ketterien menetelmien oletettuja rajoitteita tietyissä kehitysympäristöissä. Viimeisessä sisältöluvussa tarkastellaan, miten organisaatio voi kartoittaa oman suuntautumisensa joko ketteryyteen tai kurinalaisempaan suuntaan sekä kartoitetaan kirjallisuudesta löytyviä suosituksia ketterien menetelmien käyttöön ja implementointiin, kuin myös käytännön kokemuksia menetelmien käytöstä turvallisuuskriittisellä alueella.

2 TURVALLISUUSKRIITTINEN JÄRJESTELMÄ JA SEN KEHITYS

Tässä luvussa kerrotaan mitä säädökset ja turvallisuuskriittiset järjestelmät ovat ja millaisia lisäprosesseja ne tuovat kehitystyöhön. Tämän jälkeen käydään läpi miten säädeltyihin ympäristöihin on perinteisesti totuttu kehittämään järjestelmiä, jonka jälkeen tarkastellaan käytetyn perinteisen kehitysmenetelmän hyviä ja huonoja puolia turvallisuuskriittisessä kehitystyössä.

2.1 Säädökset ja turvallisuuskriittinen järjestelmä

Tietokoneita ja ohjelmistoja käytetään lääkinnällisissä toimenpiteissä enemmissä määrin hyödyksi. Muun muassa insuliinipumpussa käytetään usein mikrosirua, joka annostelee potilaalle annettavan insuliinin määrää. Myös kirurgisissa toimenpiteissä käytettävä robotiikka korvaa yhä useammin kirurgin käyttämiä tavanomaisia työkaluja taaten huomattavaa hyötyä potilaalle. Ilmailualalla taas lentokoneen infrastruktuurissa sekoittuu monta eri teknologiaa joista yksi on turvallisuuskriittiset tietojärjestelmät joiden tarkoitus on tukea pilotin työskentelyä muun muassa takaamalla tehostetun järjestelmän korkeuden ilmoittamiseen. (Knight, 2002).

Koska elektronisten laitteiden ja ohjelmistojen yhdentyminen sekä määrä kasvaa yhä nopeammin, on selvää, että myös tällaiset laitteet näyttelevät suurempaa roolia ihmisten jokapäiväisessä elämässä, ja siksi järjestelmäkehityksessä tämä on otettava huomioon. Jokapäiväisessä käytössä olevien laitteiden turvallisuustekijät ovat ylimpiä huolenaiheita ja siksi erilaisia säädöksiä on asetettu kehitystyötä säätelemään, jotta laitteiden turvallinen käyttö voidaan taata. Vaikka säädökset ovat melko tarkkoja, ne eivät välttämättä ole ohjailevia. (Cawley, Wang & Richardson, 2010.) Esimerkiksi ilmailuteollisuuden DO-178B standardi ja lääketeollisuuden ISO 12385:2003 standardi ei määrää mitään

9

tiettyä järjestelmäkehitysmenetelmää käytettäväksi (Cawley, Wang & Richardson, 2010). Ne määräävät mitä todisteita kehitystyön on tuotettava, jotta voidaan todistaa, että kehitystyössä on huomioitu säädökset ja standardit kuin myös sen, että niitä on seurattu (Wils ym., 2006; McHugh ym., 2013).

Säädöksiä, standardeja ja ohjenuoria, jotka koskevat säädeltyjä ympäristöjä on yletön määrä ja niiden sisältö riippuu mistä kohdealueesta on kyse, kuin myös toteutetun järjestelmän käyttöönottomaasta ja käyttöönoton maantieteellisestä sijainnista (Fitzgerald ym., 2013). Esimerkiksi lääkinnällisiä laitteita valmistavat yritykset toimivat hyvin säädellyllä teollisuudenalalla ja heidän seurattavat säädökset riippuvat siitä, millä maantieteellisellä alueella kehitettävää laitetta aiotaan markkinoida (Hrgarek, 2012). Kuitenkin esimerkiksi lääkinnällisiä laitteita valmistavien yritysten kanssa tehdyssä tutkimuksessa havaittiin, että laitteita valmistavien yritysten kehitysprosessit perustuvat lähinnä toteuttamaan Yhdysvaltojen ja Euroopan viranomaisten asettamat säädökset (McCaffery ym., 2005).

2.2 Turvallisuuskriittisyyden vaatimat kehityksen osaprosessit

Koska osa turvallisuuskriittisen järjestelmän säädösvaatimukset on pakko toteuttaa todistetusti ja niiden tulee läpäistä tiukat testitapaukset, tuottaa se yksinään jo järjestelmäkehitykseen tiettyjä erikoispiirteitä, jotka eroavat ei-kriittisen järjestelmän kehittämisestä. Myös turvallisuuskriittistä järjestelmää kehitettäessä on otettava huomioon, että säädösten viranomaistarkastajat täytyy tyydyttää tilaaja-asiakkaan lisäksi, jotta järjestelmä on lainvoimainen ja turvallinen otettavaksi käyttöön. Näin ollen säädeltyihin ympäristöihin järjestelmää kehitettäessä täytyy kehitystyön ottaa huomioon kaksi asiakasta; tilaaja-asiakas ja säädösten viranomaistarkastajat (McHugh ym., 2013). Tämä johtaa siihen, että säädellyssä kehitystyössä on oltava erilaisia vaiheita tai osaprosesseja, jotka tukevat säädösten vaatimia todisteita kehitystyöstä ja kehitetyn järjestelmän turvallisuudesta. Tällaisia kehitysprosessin osakokonaisuuksia ovat jäljitettävyys, validointi, verifikointi, sertifiointi ja säätelyjen noudattaminen.

Jäljitettävyys (Traceability) on prosessi, jonka tuloksena jokainen vaatimus pitäisi olla jäljitettävissä eri vaiheiden kautta aina testaus- ja kooditasolle asti. Näin voidaan todistaa, että vaatimus on toteutettu ja testattu suunnitelmallisesti (Storey, 1996, s.323; ). Jäljitettävien linkkien luominen ja ylläpitäminen voi olla vaivalloista ja riskialtista puuhaa, jonka vääränlainen toteuttaminen voi myöhästyttää projektia ja nostaa sen kustannuksia. Näin ollen jäljitettävyys prosessina tulee suunnitella ja käyttöönottaa huolellisesti (Mäder ym. 2013). Ketterässä kehityksessä tämä prosessi koetaan usein raskaaksi ja

työlääksi käytänteeksi, joka tuo melko vähän lisäarvoa projektille (Cleland-Huang, 2012).

Validointi on prosessi jossa arvioidaan sitä, että tyydyttääkö järjestelmä tai komponentti sille laaditut vaatimukset (Ikoma ym., 2009). Boehm(1984) on määritellyt validoinnin vastaavan kysymykseen: Teemmekö oikeaa tuotetta? Verifikointivaiheessa arvioidaan, että täyttääkö tietyssä vaiheessa toteutettu komponentti sille asetetut ehdot ja edellytykset (Ikoma ym., 2009). Boehm (1984) on määritellyt verifikointivaiheen vastaavan kysymykseen: Teemmekö tuotetta oikein? Nämä molemmat prosessit esiintyvät myös ei-kriittisessä järjestelmäkehityksessä ja ovat siten käytänteinä tuttuja tavanomaisessa kehitystyössäkin.

Sertifiointi on prosessi, jossa todetaan tuotteen toteuttavan vaaditut säädökset, standardit ja ohjenuorat. Tämän jälkeen tuotteelle voidaan myöntää lakiperusteinen lisenssi tai todistus (Storey, 1996, s.359). Tämä vaihe on erityisen tärkeä säädeltyä järjestelmää kehitettäessä, sillä jos tuote ei läpäise sertifiontiprosessia, ei sitä myöskään välttämättä voida vielä ottaa käyttöön tai laskea markkinoille (Abdelaziz, El-Tahir & Osman, 2015). Esimerkiksi lentokoneeseen kehitetyn järjestelmän täytyy läpäistä sertifiointivaihe ennen kuin lentokonetta voidaan käyttää (Storey, 1996, s.359). Sertifioinnin tueksi projektin on tuotettava kattavat todisteet siitä, että järjestelmä on turvallinen otettavaksi käyttöön sekä turvallisuustodisteet siitä, miten turvallisuusvaatimukset on saavutettu ja toteutettu projektissa (Ge ym., 2010). Voisi oikeastaan todeta, että muut osaprosessit toteutetaan sertifiointivaihetta silmällä pitäen, ja niiden avulla pystytään lopuksi todistamaan kehitystyön ottaneen huomioon asetetut säädökset ja tätä kautta tuote voi läpäistä sertifioinnin.

Sääntelyjen noudattaminen (regulatory compliance) on koko kehityksen rinnalla kulkeva kokonaisprosessi, jonka avulla kehittäjä todistaa, että säädökset on otettu huomioon. Tähän prosessiin kuuluu laaja todiste siitä millaisia kehitysmenetelmiä on käytetty ja kuinka järjestelmä on testattu kehityskaaren aikana. Lisäksi tämän prosessin on taattava hyvät todisteet siitä, että järjestelmä on riittävän turvallinen ja että se on sitä myös koko sen käytön ajan (Storey, 1996 s.360).

2.3 Perinteinen tapa kehittää turvallisuuskriittistä järjestelmää

Tyypillisesti turvallisuuskriittisen järjestelmän kehittäminen on aikaa vievää puuhaa ja suurin osa tämän tyyppisistä kehitystöistä kehitetään V-mallin mukaisella kehitysmenetelmällä (Ge ym., 2010; Abdelaziz ym., 2015). V-mallin tyylisen kehitysmenetelmän on alun perin esitellyt Boehm (Deuter, A. & Engels, G., 2014), sen kehityskaari

11

on suunnitelmavetoista joka koostuu peräkkäisistä vaiheista, joissa aina edellisen vaiheen tulee olla valmis ennen seuraavaan siirtymistä. Tässä menetelmässä painotetaan testausta enemmän kuin vesiputousmallissa ja testitapausten suunnittelu aloitetaan ennen kuin itse ohjelmointityötä ruvetaan toteuttamaan (Munassar & Govardhan, 2010, s. 97-98). Malli myös esittää yhteydet rinnakkaisten vaiheiden välillä, joiden avulla pystytään määrittelemään onko kaikki vaiheet toteutettu hyväksytysti. Jos ei ole, joudutaan vaihetta tarkastelemaan uudelleen tai se joudutaan toteuttamaan kokonaan uudelleen. Käytännössä siis menetelmän toisella puolella viedään suunnittelua eteenpäin ja toinen puoli keskittyy suunnitelmien testaamiseen (Kuva 1) ja tarkasteluun (McHugh ym., 2013).

Kuvio 1 V-mallin mukainen kehityselinkaari (Ge ym., 2010)

Menetelmä esittelee kehitystyön perustekijät ja ohjatun, tyypillisesti peräkkäisen, kehitysprosessin joka on luonteenomaista menetelmälle. Prosessin vaiheiden peräkkäisyys tukee kehitystyön kommunikointia sekä eri vaiheiden ajoittamisen helppoutta. Myös vaiheistus ja testiskenaarioiden aikainen suunnittelu helpottaa jäljitettävyyttä ja sertifiointitarkoituksia, jotka ovat tärkeitä turvallisuuskriittisen kehitystyön osakokonaisuuksia (Ge ym., 2010). Malli antaa hyvän opastuksen dokumentoinnille ja ohjeet oikeellisuuden todistamiseksi verifikaatio- ja sertifiointivaiheisiin (Deuter & Engels, 2014). Menetelmän etuna, kuten muidenkin suunnitelmavetoisten menetelmien, voidaan nähdä myös se, että se on melko tunnettu ja hyväksytty eri aloilla, sekä se on integroitu onnistuneesti turvallisuuskriittisten järjestelmien kehitykseen (Ge

ym., 2010). Tästä johtuen menetelmän käyttökynnys on pieni ja sen käyttäminen on tuttua ja turvallista. Koska testitapauksien suunnittelu aloitetaan aikaisessa vaiheessa, tukee se myös säädösten noudattamista ja jäljitettävyyttä kriittisessä kehityksessä.

Vaikka Munassaarin ja Govardhan (2010) toteamat menetelmän hyvät puolet piti sisällään sen, että menetelmä sopii hyvin pieniin projekteihin joissa vaatimukset ovat tiedossa aikaisessa vaiheessa, ei tämä pääse oikeastaan toteutumaan turvallisuuskriittisessä kehityksessä joka on raskaasti säädeltyä. Ensinnäkin, turvallisuuskriittisten järjestelmien kehittäminen on usein monen vuoden kestävää projektityötä, jolloin on selvää, että järjestelmän kaikkia vaatimuksista ei voida kartoittaa heti projektin alkuvaiheessa. Esimerkiksi monimutkaisen lääkinnällisen laitteen tyypillinen kehitysaika kestää kolmesta viiteen vuoteen ja on hyvin todennäköistä, että vaatimukset muuttuvat, tai lisääntyvät, tuona aikana (Rasmussen ym., 2009). Projektien pitkäikäisyydestä seuraa myös se, että projektit eivät ole kovinkaan pieniä, vaan pitkän elinkaaren omaavia monen vuoden projekteja.

Munassar ja Govardhan (2010) listaavat julkaisussaan menetelmän huonoja puolia yleisesti, joita on myös havaittavissa kirjallisuudessa joka käsittelee turvallisuuskriittistä säädeltyä ohjelmistokehitystä. Käytännössä turvallisuuskriittisiin järjestelmiin vaikuttavat säädökset tekevät kehitysprosessista jäykkää, huonosti muutoksiin reagoivaa ja näin aiheuttaa myös myöhäisiä käyttöönottoja ja budjetin ylityksiä (Jonsson, Larsson & Punnekkat, 2012; McHugh ym., 2013). Myöskään menetelmä ei tuota aikaisia prototyyppejä ohjelmistosta, koska sitä kehitetään hiljalleen koko kehityselinkaaren ajan (Munassar & Govardhan, 2010). Tästä johtuen kehitettävän järjestelmän laatu kärsii ja vasta myöhäisessä vaiheessa saatetaan huomata muutosvaatimuksia, jotka taas on vaikea korjata. Säädösten lisäksi kehitystyötä jäykistää entistä pahemmin se, että usein tällaisessa kehitystyössä käytetään suunnitelmavetoisia kehitysmenetelmiä, joissa vaatimukset pyritään kiinnittämään mahdollisimman varhaisessa vaiheessa. Toisaalta voi olla myös, että säädökset eivät tee kehityksestä raskasta, vaan suunnitelmavetoisen kehitysprosessin käyttö aiheuttaa kehitystyön joustamattomuuden. Joka tapauksessa ketterien menetelmien käyttö turvallisuuskriittisessä kentässä pitäisi tuoda vähintäänkin helpotusta kehitystyön jäykkyyteen.

13

3 KETTERÄT MENETELMÄT

Tämän luvun aluksi selvitetään mistä ketterät ohjelmistokehitysmenetelmät kumpuavat, mitä ne ovat ja millaisiin filosofisiin periaatteisiin ketterät menetelmät perustuvat. Tämän jälkeen selvitetään projektiympäristöjä joihin perinteisesti on ketterä lähestymistapa nähty soveltumattomaksi, yhtenä ympäristönä on säädelty kehitystyö.

3.1 Ketterän ohjelmistokehityksen evoluutio ja filosofia

Viimeisen vuosikymmenen aikana ketteriin menetelmiin on kohdistettu paljon tutkimusresursseja, menetelmien käytöstä ollaan kiinnostuneita ja niitä on ruvettu jo käyttämään hyvin laajalti ohjelmistokehityksessä ympäri maailmaa. Dybå ja Dingsøyr (2008) huomasivat tekemässään ketterien menetelmien tarkastelussa, että menetelmät voivat parantaa ohjelmistoprojektin tehokkuutta sekä työskentely- ja asiakastyytyväisyyttä. Ketterä ohjelmistokehitys kehittyi vaihtoehdoksi suunnitelmavetoiselle kehitystyölle, kun suunnitelmavetoiset menetelmät eivät pystyneet joustavasti vastaamaan teknologian ja toimialojen muuttuviin vaatimuksiin kehitystyön aikana (Lindvall ym., 2002). Ketteryys siis syntyi, kun haluttiin päästä eroon raskaista dokumentointiin perustuvista kehitysmenetelmistä (Cohen, Lindvall & Costa, 2003, s. 2). Aivan tyhjästä uusi kehitysfilosofia ei syntynyt, vaan se kehittyi jo olemassa olevasta vesiputousmallista uudeksi tavaksi kehittää ohjelmistoja (Beck, 1999). Roycen (1970) alkuperäisen vesiputousmallin mukaan järjestelmää kehitetään vaihe vaiheelta kohti käyttöönottoa, eikä edelliseen kehitysvaiheeseen enää palata. Tämä kuitenkin todettiin jäykäksi tavaksi kehittää järjestelmää, kun muun muassa vaatimukset muuttuivat kehitysprosessin aikana ja siksi menetelmää muokattiin

siten että se paloiteltiin iteraatioihin, joissa jokaisessa iteraatiossa toistuu alkuperäisen menetelmän vaiheet (Beck, 1999). Iteraatioiden käyttöönoton jälkeen pystyttiin vastaamaan muutoksiin paremmin ja itse kehitysprosessia pystyttiin nopeuttamaan (Cohen ym., 2003, s. 3-4).

Pelkkien iteraatioiden käyttöönotto ei vielä riittänyt synnyttämään uutta kehitysmenetelmää, tarvittiin vielä jotain muuta. Vuonna 2001 joukko ketterien kehitysmenetelmien puolestapuhujia kokoontui keskustelemaan uusista kehitysmenetelmistä ja loivat niin kutsutun Agile Manifeston, jossa listataan arvot joihin ketterät menetelmät perustuvat. Tämä julistus on tärkeä ketterien menetelmien artefakti, koska se kertoo filosofian johon menetelmät perustuvat sekä määrittelevät miten ketterät menetelmät eroavat perinteisistä menetelmistä ja siten määräävät perusperiaatteet jotka tekevät kehityksestä ketterää. (Cohen ym., 2003, s, 7.) Itse julistuksessa on listattu seuraavat neljä tärkeintä perusperiaatetta, joihin ketterät menetelmät nojaavat. Mutta samassa julistuksessa on lueteltu yhteensä 12 ketterän kehityksen perusperiaatetta.

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

(Flower & Highsmith, 2001; Ketterän ohjelmistokehityksen julistus, 2001)

Ketterien kehitysmenetelmien julistus antaa yhteisen kehyksen eri menetelimille, jotka taas eroavat toisistaan erilaisten tekniikoiden ja käytänteiden käytön vuoksi, mutta ne jakavat kuitenkin yhteiset julistuksessa ilmoitetut arvot. Tunnetuimmat, laajalti dokumentoidut ja testatut kehitysmenetelmät ovat Scrum ja XP (Salo & Abrahamsson, 2008). Scrum tähtää ketterään lähestymistapaan projektin hallinnoinnin keinoin, joiden avulla pyritään jäljittämään reaaliaikaisesti kehitysprosessin ongelmia (Cardozo ym., 2010). Menetelmän keskiössä on projektin jäsenten roolittaminen ja itseorganisoituva tiimi, jonka tehokkaan työskentelyn mahdollistaa Scrum master, joka myös päättää seuraavassa sprintissä toteutettavat toiminnallisuudet backlogista. Asiakas pidetään mukana kehitystyössä ja työskentelyprosessi jaksotetaan noin viikon mittaisiin sprintteihin, joiden alussa suunnitellaan ja lopussa tarkastellaan aikaansaatua työtä. Päivittäin järjestetyissä tapaamisissa tiimiläiset koordinoivat omaa työskentelyään ja selvittävät toisilleen omien

15

tehtävien senhetkisen tilanteen (Dybå & Dingsør, 2008). Scrumin kokonaiskuva ja prosessi esitellään alla (Kuva 2).

Kuvio 2 Kokonaiskuva Scrumista, jonka sprintin pituus on 30 päivää (Wolff, 2012; Fitzgerald ym., 2013)

XP taas keskittyy enemmän projektitasolla käytettäviin, parhaiksi koettuihin työskentelymenetelmiin ja aktiviteetteihin joiden avulla toteutetaan järjestelmää. Näihin työskentelymenetelmiin kuuluu 12 käytännettä, joista hyvin tunnettuja ovat muun muassa testivetoinen kehitys, pariohjelmointi, refaktorointi ja pienet julkaisut (Salo & Abrahamsson, 2008; Dybå & Dingsor, 2008). Jotta XP voidaan tulkita ketteräksi menetelmäksi, täytyy sen käytänteiden lisäksi toteuttaa ketterän julistuksen arvoja projektin hallinnoinninkin tasolla. Siksi se nojaakin lyhyissä iteraatioissa toteutettaviin julkaisuihin, joissa myös asiakas on aina mukana (Munassaar & Govardhan, 2010). Menetelmä myös painottaa vahvasti, miten toimistotilat ja fyysinen työskentely-ympäristö tulisi olla järjestettynä, jotta se tukisi mahdollisimman hyvin tiimin kommunikointia ja työskentelytehokkuutta (Beck, 1999).

Kuitenkin eri menetelmien tekniikoita ja käytänteitä voidaan käyttää sekaisin. Scrumia käytetäänkin usein projektin hallinnoinnin apuna ja XP:stä taas otetaan käytänteitä itse projektityöskentelyyn (Cardozo ym., 2010). Näiden kahden menetelmän yhdistäminen keskenään onkin mahdollista, koska Scrum antaa hyvät työkalut projektin hallinnolliseen prosessiin ja XP taas listaa parhaiksi koettuja työskentelymetelmiä ja tekniikoita projektitason työskentelyyn.

3.2 Ketterien menetelmien käytön oletetut rajoitteet

Ketterät menetelmät ovat todistetusti kasvattaneet ohjelmistoprojektien onnistumismäärää huomattavasti, mutta ne ovat kohdanneet laajaa kritiikkiä koska ne rikkovat perinteisten kehitysmenetelmien kurinalaisuutta, periaatteita ja käytänteitä (Mandal & Pal, 2014). Kuitenkin uusi kehitysfilosofia on ratkaissut suunnitelmavetoisten menetelmien ongelmia tuomalla asiakas lähelle kehitystyötä, keskittymällä kehitystiimin yhteistyöhön ja toteuttamalla järjestelmän määrittelyä, suunnittelua ja toteutusta inkrementaalisesti iteroiden. Menetelmien tarkoituksena on jokaisen lyhyen syklin päätteeksi julkaista uusi toimiva palanen järjestelmästä, joka toisi arvoa asiakkaalle (Jonsson, Larsson & Punnekkat, 2012). Ketteryyden sovittaminen on silti nähty vaikeaksi, tai jopa mahdottomaksi, muun muassa ohjelmistoprojekteihin jotka ovat hajautettuja, omaavat suuren kehitystiimin, toteuttavat turvallisuuskriittistä tai suurta ja monimutkaista järjestelmää (Turk, Robert & Rumbe, 2005). On siis tiedettävä millaisissa projekteissa ketterää lähestymistapaa voi käyttää ja koska täytyy menetelmien käytölle hankkia parempia perusteluja, tai jättää niiden käyttö kokonaan väliin.

Hajautetussa järjestelmäkehityksessä kaikki kehittäjäosapuolet eivät sijaitse samalla paikkakunnalla tai edes samassa maanosassa. Tämä johtaa moniin ongelmiin, joista huomattavimpana voi pitää kommunikaation vaikeutta, koska projektin eri osapuolet ovat kaukana toisistaan, jopa eri aikavyöhykkeillä, eivätkä pysty face-to-face keskusteluun jota pidetään yhtenä ketteryyden tärkeimpänä kommunikaatiokeinona. Projektijäsenien hajautuminen aiheuttaa myös ongelmia yhteisen tuotevision säilyttämiseen, siksi hajautetussa kehitystyössä formaali dokumentaatio nähdään välttämättömäksi, jotta eri osapuolet säilyttäisivät yhtäaikaisen näkemyksen kehitettävästä tuotteesta ja projektin tilanteesta. (Turk ym., 2005). Bannermanin, Hossainin ja Jefferyn (2012) tekemässä laadullisessa case-tutkimuksessa kuitenkin todettiin, että Scrumin käyttö tuotti selkeitä parannuksia hajautetun kehistystyön kommunikointi- ja koordinointiongelmiin, joita aiemmin oli hoidettu suunnitelmavetoisten menetelmien avulla. Hyödyt saatiin lähinnä siksi, että nykyteknologia mahdollistaa nopean kommunikoinnin verkon kautta ja neljässä case-projekteissa käytettiinkin kommunikoinnin apuna erilaisia aputyökaluja, jotka tukivat yhteydenpitoa ja tiedon jakamista verkon välityksellä eri tiimien välillä. Myös Fitzgerald ym., (2013) listaa useamman tutkimuksen, jotka ovat todistaneet ketterien menetelmien käytön onnistuneen hajautetuissa kehitysprojekteissa.

17

Kun järjestelmässä on satoja tuhansia, miljoonia jne. rivejä koodia ja/tai se sisältää useita eri osakokonaisuuksia joiden tulisi toimia keskenään luotettavasti, voidaan puhua suuresta ja monimutkaisesta ohjelmistosta. Monimutkaisuus ja laajuus vaativat kehitystyöltä kurinalaisuutta sekä suuremman määrän formaalia dokumentointia. Tällaisen projektin kehityselinkaareen vaikuttaa luonnollisesti myös suuri tai useampi tiimi, jotka saattavat olla hajautettuna maantieteellisesti. Dokumentoinnin määrä kasvaa jo pelkästään kun on suurempi määrä vaatimuksia, toiminnallisuuksia ja suunnitteluratkaisuja toteutettavaksi. Myös suuren ohjelmiston arkkitehtuurin tarkka määrittely on tärkeää, jotta koko järjestelmä pystyttäisiin ymmärtämään kokonaisuutena ja jotta kehityksen jälkeen järjestelmän parissa työskentelevät uudet työntekijät voisivat järjestelmän ymmärtää. Suuren tiimin face-to-face kommunikointi taas on hankalampaa ja siksi tiimin koordinointi vaatii enemmän formaaleja käytänteitä. (Turk ym., 2005). Lagerbergin ym., (2013) julkaisemassa empiirisessä case-tutkimuksessa havaittiin ketterien menetelmien tuovan kuitenkin selvää hyötyä suureen monen tiimin projektiin, jossa ketteryys implementoitiin kokonaan. He havaitsivat ketteryyden tuovan myös hyötyjä toiseen, lähes samaa tuotetta kehittävään, suureen suunnitelmavetoiseen projektiin, jossa ketteryydestä oli käytössä joitain käytänteitä osittain. On olemassa myös useita muita tutkimusjulkaisuja, joissa ketterien menetelmien on todettu toimivan suurissa projekteissa joissa työskentelee suuri tiimi (Fitzgerald ym., 2013).

Kuten toisessa kappaleessa todettiin, vaatii turvallisuuskriittisten järjestelmien kehitys vankkoja todisteita turvallisuusmääräysten toteuttamisesta. Tähän todistukseen tähdätään erilaisilla kehityksen osaprosesseilla, joita ovat sertifiointi, sääntelyn noudattaminen ja jäljitettävyys. Näiden käytänteiden toteuttaminen vaatii melko raskasta muodollista raportointia, joka taas sotii ketterän julistuksen dokumentointikohtaa vastaan. Ketterät menetelmät nähdäänkin melko kevyiksi kehitysmenetelmiksi, jotka eivät tuota kovinkaan paljoa dokumentaatiota, eivätkä siksi tarjoa jäljitettävyyttä tukevia todisteita (Cleland-Huang, 2012). Kriittisen järjestelmän kehittäminen vaatii usein monen vuoden työn sekä suuren projektin ja/tai jopa hajautettua projektityöskentelyä. Tällainen ympäristö on siis yhdistelmä useammasta kehitysympäristön piirteestä, joissa kaikissa ketterien menetelmien hyödyntäminen koetaan haasteelliseksi. Näiden syiden yhteissummana täytyy todellakin pohtia ja tarkastella menetelmien käyttöedellytyksiä säädellyssä turvallisuuskriittisessä projektissa. Vaikka ketterät menetelmät koetaan vaikeaksi sovittaa turvallisuuskriittiselle kentälle, ollaan niiden potentiaalista alueella kuitenkin kiinnostuneita. Onhan ketterät menetelmät osoittautuneet sopiviksi myös suuriin ja monimutkaisiinkin projekteihin, joihin ne alun perin nähtiin sopimattomaksi.

4 KETTERÄT MENETELMÄT TURVALLISUUSKRIITTISESSÄ OHJELMISTOKEHITYKSESSÄ

Tässä luvussa selvitetään miten ketterien menetelmien käyttö on onnistuttu implementoimaan turvallisuuskriittisissä ympäristöissä. Aluksi tarkastellaan sopivatko ketterät menetelmät säädeltyyn kehitykseen ja lopuksi käydään läpi, miten ketteryyttä on onnistuttu käytännössä hyödyntämään turvallisuuskriittisessä kehitystyössä.

4.1 Organisaatiorakenteen määrittäminen kotikenttäanalyysin avulla

Jotta organisaatio ymmärtäisi millainen kehitysmenetelmä sopisi omaan kehitystyöhön parhaiten, on sen ymmärrettävä kehitettävän järjestelmän luonne, kuin myös oman organisaation rakenne. Boehm ja Turner (2003) ovat esitelleet niin kutsutun kotikenttäanalyysin (Home-Ground analysis), jonka avulla organisaatio voi viiden kriittisen tekijän perusteella arvioida oman organisaation rakennetta siten että onko organisaatio taipuvaisempi ketteryyteen, kurinalaisuuteen eli suunnitelmavetoisten menetelmien suuntaan, vai sijoittuuko se kenties jonnekin edellä mainittujen välille. Tämän analyysin avulla voidaan myös määritellä, millä viidellä osa-alueilla organisaation tulisi tehdä muutoksia, jotta se tukisi ketteryyttä tai suunnitelmavetoisia menetelmiä paremmin (McHugh ym., 2013).

Viidestä kriittisestä tekijästä neljä on melko itsensä selittäviä (kriittisyys, koko, kulttuuri ja dynaamisuus), mutta henkilöstön ammattitaito on jaettu viiteen mahdolliseen kategoriaan, joista osa tukee ketterää kehitystä ja osa kurinalaisempaa kehitystyötä. Kriittisyyttä kuvataan järjestelmän toimintavirheen aiheuttaman vaaran määrästä, jota mitataan ihmishenkien menetysmahdollisuuden määrällä. Jos kriittisyys on suurta, voidaan

19

todeta, kuten aiemmissa luvuissa on kerrottu, että se ohjaa kehitystä suunnitelmavetoisempaan suuntaan. Kokoa mitataan projektiin osallistuvien henkilöiden ja osakkaiden määrällä. Mitä suurempi henkilöstön ja projektin koko, sitä suunnitelmavetoisempaa kehitysmenetelmää on perusteellista käyttää. Kulttuuria katsotaan sen mukaan, onko organisaatio taipuvainen kurinalaisuuteen ja järjestäytyneisyyteen, vai onko työskentely vapaampaa ja itseohjautuvampaa. Itseohjautuvuus, eli suurempi kaaos, tukee ketterien menetelmien käyttämistä. Dynaamisuus riippuu kehitystyön kohtaamien muutosten määrästä. Jos muutoksia ilmaantuu paljon, on kehitysmenetelmän pystyttävä mukautumaan siihen, joka taas viittaa selkeästi ketterien menetelmien käyttöön. (Boehm & Turner, 2003; McHugh ym., 2013).

Viidestä kriittisestä kotikenttäanalyysin tekijästä henkilöstön ammattitaito vaatii hieman selittämistä. Henkilöstön ammattitaito on jaettu viiteen eri tasoon (Taulukko 1). Nämä tasot on johdettu Cockburnin (2002) määrittelemistä henkilöstön ammattitaidon tasoista, joista jokainen kuvaa miten hyvin eri tason työntekijän odotetaan osaavan käyttää annettua kehitysmenetelmäviitekehystä. Kolmannen ja toisen tason henkilöt ovat kokeneita ja luovia menetelmän käytänteiden asiantuntijoita, jotka kykenevät myös johtamaan tiimiä. Tämän tason tekijät ovat ketterän kehityksen välttämättömiä resursseja. Ensimmäisen tason työntekijät taas ovat vähemmän kokeneita, mutta tuntevat ja osaavat käyttää menetelmän käytänteitä. Tämän tason tekijät kykenevät ketterään tai suunnitelmavetoiseen kehitykseen jos heitä kaitsee tarpeeksi monta toisen tai kolmannen tason työntekijää. Miinus yksi tason työntekijöitä taas eivät ole välttämättä soveliaita työskentelemään yhteisten pelisääntöjen mukaan lainkaan ja näin aiheuttavat kitkaa kehitykselle. Jos kolmannen ja toisen tason työntekijöitä on suhteessa enemmän ensimmäiseen tason verrattuna, on organisaatio kykenevä henkilöstön ammattitaidon puolesta toteuttamaan ketterää kehitystä. Jos taas toisin päin, on kurinalaiset menetelmät soveliaampia. (Boehm & Turner, 2003; McHugh ym., 2013; Cocburn, 2002).

Taulukko 1 Järjestelmäkehitysmenetelmän ymmärtämisen ja käytön tasot

Taso Tunnusmerkit3 Kykenevä mukauttamaan toimintatapaa (rikkomaan sen sääntöjä),

jotta se sopisi uuteen odottamattomaan tilanteeseen. Pystyy johtamaan suuria ja pieniä projekteja ennalta-arvaamattomassa ympäristössä. Soveltaminen, luovuus ja kokemus on tunnusomaista tämän tason työntekijälle.

2 Kykenevä mukauttamaan toimintatapaa tiedossa olevan tilanteen mukaiseksi ja johtamaan pieniä tiimejä sekä ennalta-arvattavaa projektia.

1A Koulutuksen avulla kykenevä suoriutumaan harkinnanvaraisista toimintatavan vaiheista ja luomaan niitä tilanteen mukaan (mm. mitoittamaan toteutusta inkrementteihin, luomaan suunnittelumalleja). Kokemuksen kautta voi edetä tasolle kaksi.

1B Koulutuksen avulla kykenevä suoriutumaan kehitysmenetelmän proseduraalisista toimintatavoista. Kova työskentelijä, mutta vaatii kurinalaisuutta ja järjestelmällisyyttä.

-1 Omaa mahdollisesti teknisiä taitoja, mutta kykenemätön tai haluton yhteistyöhön tai seuraamaan menetelmän toimintatapoja.

Kun viisi kriittistä tekijää on määritelty, viedään tulokset ns. tutkataulukkoon (radar chart) josta nähdään organisaation kehitysympäristön rakenne (Kuva 3). Mitä lähempänä keskiötä pisteet ovat, sitä ketterämpi se on ja sitä paremmat perustelut ketterien menetelmien käytölle saadaan (Boehm & Turner, 2003). Kotikenttäanalyysin profiilista nähdään, kumpaa kehitysmenetelmäfilosofiaa organisaation rakenne tukee. Sitä voidaan myös käyttää hyväksi, kun pohditaan mitä osa-alueita organisaation tulisi muuttaa, jotta se tukisi paremmin joko ketteriä tai suunnitelmavetoisia menetelmiä. Yksi osa-alue ei siis saisi olla perustelu kehitysviitekehyksen valintaan, vaan organisaatiorakennetta tulisi kartoittaa laajemmin, useamman rakenteen määrittävän tekijän perusteella. Tietenkin voidaan nähdä, että yhdelle tai useammalle tekijälle annetaan painoarvoa enemmän ja päätetään kehitysmenetelmän käyttö näiden tekijöiden perusteella yksin tai painotetusti.

21

Kuvio 3 Kotikenttäanalyysi, jonka profiili on ketteryyden ja kurinalaisuuden sekoitus (Boehm & Turner, 2003)

4.2 Yleisiä suosituksia ketterien menetelmien käyttöön turvallisuuskriittisessä ympäristössä

Vaikka vielä tällä hetkellä ketterien menetelmien implementoinnista turvallisuuskriittiselle alueelle on melko niukasti hyvin raportoitua ja tutkittua tietoa, on ketteryyden soveltamisen suosituksista julkaistu laadukkaita julkaisuja. McHugh ym. (2013) toteuttivat haastatteluja turvallisuuskriittisiä ohjelmistoja kehittävien organisaatioiden kanssa ja huomasivat, että kehittäjät kokevat suunnitelmavetoisten menetelmien käytön ongelmallisena, koska niiden avulla on vaikea vastata muutoksiin. Ketterät menetelmät sen sijaan sopivat projekteihin, joissa muutosmäärät ovat suuria tai ylipäätään mahdollisia (Beck, 1999). Turvallisuuskriittisyyden johdosta viranomaistahot vaativat järjestelmältä korkeaa laatua, jonka vuoksi myös moninaisia säädösvaatimuksia on säädetty tällaisille järjestelmille. Ketterät menetelmät pyrkivät kehitysprosessissa vastaamaan asiakkaan tarpeisiin tehokkaammin kuin tavanomaiset menetelmät. Tästä seuraa se, että jatkuvalla integroinnilla ja toimivalla ohjelmistolla pystytään toteuttamaan laadukkaampaa ohjelmistoa, joka vastaa myös säädösten vaatimaan laatukriteeriin (Cawley ym., 2010). Ketterästi ei pystytä pelkästään kehittämään laadukkaampaa sovellusta toiminnallisten vaatimusten näkökulmasta, vaan myös ei-laadullisten joihin kuuluu muun muassa ohjelmiston luotettavuus (Ge ym., 2010). Näiden edellä mainittujen parannusten lisäksi ketteryyden on havaittu lyhentävän kehitysaikoja, joten niiden

soveltaminen turvallisuuskriittisellä alueella on perusteltua ja suositeltavaa.

McHugh ym. (2013) esittelevät artikkelissaan räätälöidyn ketterän V-mallin menetelmän, joka yhdistelee suunnitelmavetoisia käytänteitä ja ketteriä käytänteitä (Kuva 4). Hybridimenetelmän rungoksi valittiin V-malli, koska se on turvallisuuskriittisellä alueella, varsinkin lääkinnällisiä kehittävällä alueella, tunnettu, sen käyttö osataan, se tukee säädösten seuraamisen vaatimuksia ja se on yleisesti hyväksytty. Malli kuitenkin jaettiin kahteen vaiheeseen siten että abstraktimmassa ylemmässä osassa on toiminnot jotka voidaan toteuttaa vain kerran. Näitä toimintoja ovat kehitystyön alussa toteutettava vaatimusmäärittely ja kehitystyön lopussa suoritettava tuotteen sertifiointi, jotka ovat Yhdysvaltain ruoka- ja lääkehallinnon (FDA) vaatimat kehityksen osaprosessit. Yleisempi vaihe taas pitää sisällään arkkitehtuurin ja itse järjestelmän suunnittelun sekä toteutuksen testeineen. Tätä yleisempää vaihetta iteroidaan ja tuotetta kehitetään näin inkrementaalisesti ketterien käytänteiden mukaan. Tutkimusjulkaisujen analysoinnin jälkeen menetelmään valittiin lääkinnällisessä kehityksessä onnistuneita ketteriä käytänteitä, joita ovat muun muassa iteratiivinen ja testivetoinen kehitys, pariohjelmointi ja jatkuva integrointi. (McHugh ym., 2013). Artikkelissa esitellään siis hybridimenetelmä, jonka räätälöinnin ja käytänteiden valinnat perustellaan nykytutkimuksen perusteella. Tätä menetelmää voisi pitää eräänlaisena ohjenuorana, jos halutaan siirtyä ketterämpään suuntaan turvallisuuskriittisellä kehitysalueella. Tosin menetelmä on rakennettu lääkinnällisten järjestelmien kehittämistä silmällä pitäen, mutta kirjoittajat kertovat sen olevan sovellettavissa myös tiukasti säädeltyyn kehitystyöhön yleisestikin.

Koska turvallisuuskriittisen järjestelmän tulee läpäistä lopuksi sertifiointivaihe, jonka läpäisemiseksi kehitystyön on tuotettava kattavat todisteet säädösten toteutumisesta, täytyy kehitystyön ottaa tämä huomioon. Ketterät menetelmät eivät takaa kovinkaan kattavia todisteita tätä prosessia varten ja siksi niihin tulee lisätä käytänteitä tätä prosessia tukemaan (Ge ym., 2010). On siis selvää, että ketterät menetelmät eivät voi puhtaasti yksin näitä todisteita taata, ja siksi ei voida puhua puhtaasta ketterästä turvallisuuskriittisestä kehitystyöstä, vaan on todellakin osattava räätälöidä suunnitelmavetoisista ja ketteristä menetelmistä jonkinlainen hybridimenetelmä, joka tukee jatkuvaa säädösten noudattamista ja turvallisen ohjelmiston kehitystä. Seuraavassa kappaleessa käydään läpi kaksi esimerkkitapausta, joissa tämä prosessi on onnistuneesti räätälöity ja implementoitu käytännössä.

23

Kuvio 4 Ketterä V-malli McHughin ym. (2013) mukaan

4.3 Ketteryyden käytännön implementointi

Rasmmusen ym. (2009) ovat julkaisseet käytännön kokemuksiin perustuvan raportin ketterien menetelmien käyttöönotosta turvallisuuskriittisessä kehitysympäristössä, jossa tarkastellaan lääkinnällisiä laitteita kehittävän organisaation (Abbot) menetelmän käyttöönottoa, kun tuotteet ovat tiukasti säädeltyjä Yhdysvaltain ruoka- ja lääkehallinnon (FDA) toimesta. Kehitystiimi oli tietoisia ketterien menetelmien mahdollistamista hyödyistä ja he päättivät käyttöönottaa menetelmän eräässä projektissa. Koska perinteisesti oli käytetty vesiputousmalliin perustuvaa kehitysmenetelmää, ei henkilöstöllä ollut käytännön kokemusta ketterien menetelmien käytöstä, joten he päättivät turvautua ulkopuoliseen konsultointiapuun jonka henkilöstö koulutti kehitystiimiä käyttämään ja toteuttamaan ketteriä menetelmiä. Pilottiprojektiin valittiin käytettäväksi käytänteitä ketteristä menetelmistä kuin myös suunnitelmavetoisista, joten pilotissa käytettiin eräänlaista hybridimenetelmää. Järjestelmää kehitettiin inkrementaalisesti iteroiden, päivittäin järjestettiin tiimitapaamiset ja joka iteraation jälkeen suoritettiin jälkikatsaus sprinttiin sekä sen aikana toteutettuun ohjelmisto-osaseen tärkeimpien osakkaiden toimesta. Jokainen

metodi yksikkötestattiin, testit ajettiin metoditasolla ja myös koko järjestelmän testaukset ajettiin jokaisen koodi-integraation jälkeen joita tehtiin päivittäin. Näin pidettiin huolta, että järjestelmä läpäisi testit jatkuvasti sekä toimiva järjestelmä oli aina saatavilla ja tuettiin sääntelyjen vaatimaa jäljitettävyyttä. Jokaisen iteraation jälkeen tärkeimmät osakkaat katselmoivat tuotetta ja hoitivat verifiointia ja validointia, josta muodostui lopullinen jäljitettävyys viranomaistarkistuksia varten. Jos puutteita havaittiin, ne raportoitiin ja korjattiin seuraavan iteraation aikana. Kehityksen mukana siis toteutettiin suunnitelmavetoisista menetelmistä tuttua melko raskasta jatkuvaa tuotteen elinkaaren dokumentaation päivitystä, jotta sen hetkinen tuotteen kehitystilanne oli selvä jokaiselle osakkaalle ja että saataisiin tarpeelliset todistukset sääntelyjen noudattamisen tueksi. Organisaatio arvioi, että pilottiprojekti suoriutui kehitystyöstä nopeammin ja pienemmällä henkilöstömäärällä kuin tavanomaisesti kehitetyt projektit. Samaan aikaan toteutettiin tavanomaisin keinoin eräs samankaltainen projekti, joka vaati enemmän henkilöstöä ja aikaa. Jälkikäteen arvioitiin, että tavanomaisesti toteutettu projekti olisi pystytty toteuttamaan nopeammalla aikataululla ja pienemmällä henkilöstömäärällä, jos siinä olisi myös käytetty ketterämpää lähestymistapaa. Ketterän projektin yhtenä suurimpana hyötynä koettiin olevan testien jatkuva ajaminen ja toimivan järjestelmän jatkuva saatavuus joka piti tuotteen laadun korkeana jo kehitysvaiheessa. Suunnitelmavetoisessa projektissa havaittiin sertifiointivaiheessa huomattavasti enemmän virheitä, kuin ketterässä projektissa. Pilottiprojekti oli siis varsin onnistunut, mutta se toisaalta oli vasta ensimmäinen organisaation ketterä projekti.

Fitzgerald ym. (2013) julkaisivat myös käytännön kokemukseen perustuvan raportin, jossa käytiin läpi ketteryyden pilotointia organisaatiossa (Qumas), joka on toteuttanut säädeltyjä ohjelmistoratkaisuja aina 1994 vuodesta lähtien. Ketteryydellä pyrittiin korvaamaan aikaisemmin käytetty jäykkään vesiputousmalliin perustuva kehitysmenetelmä. Qumas päätti implementoida Scrumin räätälöitynä siten, että se sopii säädeltyyn ja turvallisuuskriittiseen kehitystyöhön (Kuva 5). Tästä sovittamisesta seurasi se, että alkuperäiseen Scrumiin (Kuva 2) integroitiin sääntelyn vaatimia toimenpiteitä ja kehitysprosessiin luotiin uusia rooleja tukemaan säädösten noudattamisen vaatimia toimenpiteitä (Kuva 5). Uudet roolit on kuvattu harmailla hahmon kuvilla ja alkuperäiset Scrumin roolit mustalla. Jokaisen sprintin jälkeen tarkasteltiin itse ohjelmisto-osaa ja sen lisäksi myös peilattiin toteutettuja vaatimuksia säädösten vaatimuksiin ja siten ylläpidettiin jatkuvaa jäljitettävyyttä dokumentaation jatkuvan ylläpidon avulla. Uusi koodi integroitiin testeineen aina neljän tunnin välein, jonka avulla taattiin toimivan sovelluksen jatkuva saatavuus asiakkaan tarkistettavaksi. Raportin mukaan ketterät menetelmät koettiin jopa suotuisaksi turvallisuuskriittiseen kehitykseen, jos ketteryys osattiin vain

25

räätälöidä tukemaan sääntelyjen vaatimia osaprosesseja, jotka taas ovat melko raskaita dokumentaatioon liittyviä käytänteitä ja rikkovat ketterän filosofian arvoista ainakin löyhää dokumentaatiota ja yksinkertaisuutta. Myös elävän dokumentoinnin ja jäljitettävyyden apuna käytetyt aputyökalut koettiin tärkeäksi onnistumisen kannalta. Eli käytännössä tässäkin esimerkkitapauksessa käytettiin ketterien menetelmien ja suunnitelmavetoisten menetelmien hybridiä, mutta kuitenkin myös onnistuneesti.

Kuvio 5 QUMAS:n räätälöity Scrum, joka on sovitettu säädeltyyn turvallisuuskriittiseen kehitystyöhön (Fitzgerald ym., 2013)

Jos tarkastelemme McHughin ym. (2013) esittelemää ketterää V-mallia (Kuva 4), huomaamme, kuinka siinä suositellaan tiettyjä ketteriä käytänteitä ja kehitysprosesseja käytettäväksi yhdessä suunnitelmavetoisten menetelmien kanssa turvallisuuskriittisessä kehityksessä. Näitä ketteriä käytänteitä ovat muun muassa jokaisessa iteraatiossa toteutettava tarina, testivetoinen kehitys, pariohjelmointi, jatkuva integrointi ja jatkuva automatisoitu testaus. Näillä käytänteillä pyritään kasvattamaan tuotteen laatua ja tukemaan järjestelmän jäljitettävyyttä. Voimme myös nähdä melko pitkälti samoja käytänteitä, joita on käytetty oikeissa onnistuneissa projekteissakin (Fitzgerald ym. 2013; Rasmussen ym. 2009). Myös Rottier ja Rodrigues (2008) toteavat, että varsinkin testivetoinen kehitys oli elintärkeää lääkinnällistä järjestelmää kehitettäessä. He kokivat, että yhden sprintin käyttäjätarinaa ei olisi ilman etukäteen tehtyjä testejä saatu laisinkaan valmiiksi. Rottier ja Rodrigues (2008) kertovat myös, että projektissa käytettiin iteratiivista Scrumin mallista

kehitysprosessia ja aputyökaluja vaatimustenhallintaan, jolla tuettiin säädösten noudattamista. Näyttäisi siis siltä, että McHugh ym. (2013) ovat oikeilla jäljillä ketterän V-mallin suosituksissa, ja että ketteryys ja kurinalaisuus voidaan sovittaa yhteen, mutta niiden integrointi ei ole kuitenkaan helppoa, vaan joudutaan pohtimaan mitä käytänteitä ja aputyökaluja integroidaan (Heeager & Nielsen, 2009). Toki vielä on melko niukasti käytännön raportteja ketteryyden implementoinnista turvallisuuskriittisellä alueella, johon toivoisi tulevan muutosta.

27

5 YHTEENVETO JA JOHTOPÄÄTÖKSET

Ketterien ohjelmistokehitysmenetelmien riemumarssi on pitkälti syrjäyttämässä perinteisten suunnitelmavetoisen kehitystavan järjestelmiä kehittävissä organisaatioisssa. Myös ketteryys on havaittu toimivaksi filosofiaksi kehitysalueilla, joiden on alun perin nähty sopimattomaksi ketterille menetelmille, kuten suuren tiimin omaaviin hajautettuihin ja monimutkaisia ohjelmistoja kehittäviin projekteihin (Bannerman ym., 2012; Fitzgerald ym., 2013). Kuitenkin turvallisuuskriittisessä järjestelmäkehityksessä ketteryyden käytöstä on vielä melko niukasti tietoa, mutta tällekkin alueelle on kehitetty jo suosituksia ja viitekehyksiä, joissa pyritään yhdistelemään ketterien menetelmien käytänteitä perinteisten suunnitelmavetoisten menetelmien käytänteiden kanssa (McHugh ym., 2013; Ge ym., 2010). Nämä suositukset näkyvät käytännön raporteissa, joissa organisaatio on implementoinut ketteriä menetelmiä turvallisuuskriittiseen kehitysympäristöön (Fitzgerald ym., 2013; Rasmussen ym., 2009; Rottier & Rodrigues, 2008). Koska turvallisuuskriittiset säädökset vaativat kehitystyöltä runsaasti dokumentoituja todisteita koko kehityselinkaaren ajalta tuotteen sertifiointia varten, on implementoinnissa jouduttu rikkomaan ketterän menetelmän julistuksen yhtä tärkeintä arvoa, eli löyhään dokumentointiin perustuvaa kehitystapaa (Ge ym., 2010). Tämän toimintakokonaisuuden tarkoituksena on tukea järjestelmän jäljitettävyyttä, laadun valvontaa ja näin tukea myös koko sääntelyjen noudattamisen kokonaisprosessia. Pelkkä elävän dokumentoinnin implementointi kehitystyöhön ei kuitenkaan riitä, vaan tämän seurauksena joudutaan kehitystyöhön ottamaan enemmän henkilöstöä, koska elävän dokumennoin seurauksena kehitystyöprosessiin tulee uusia rooleja ja ne pitää täyttää (Fitzgerald ym., 2013). Tästä taas seuraa se, että vaikkapa Scrumin kaltainen kehitysprosessi muuttuu monimutkaisemmaksi, ja tämä taas rikkoo ketterien menetelmien julistuksen menetelmän yksinkertaisuuden arvoa. Näin ollen ei voida puhua puhtaasta ketterästä kehityksestä, vaan jonkinlaisesta hybridimenetelmästä, jossa on ketteryyttä ja

kurinalaisuutta sekoitettu keskenään. Tämä kuitenkin antaa viitteitä siitä, että kurinalaisuus ja ketteryys voidaan implementoida yhdessä, vaikka niiden on epäilty olevan epäsopivia keskenään, mutta kuitenkin kehitysalueeseen ja organisaatiorakenteeseen huolellisesti sovitettuna. Sopivaa kehitysmenetelmää ei voida yleisesti antaa kaikkien käyttöön, vaan suositusten ja oman harkinnan mukaan organisaatiot itse voivat sovittaa menetelmät ja niiden käytänteet omien tarpeidensa mukaan räätälöimällä ja mahdollisesti ulkopuolisen konsultoinnin avulla sekä oikeita kehitystyökaluja käyttämällä.

On jokseenkin mahdollista, että turvallisuuskriittisellä alueella ketterien menetelmien käyttöä karsastetaan, koska todisteita ketteryyden onnistuneelle käyttöönotolle ja käytölle alueella on vielä niukasti. Tämänhetkisten raporttien mukaan implementoinnit ovat pääsääntöisesti onnistuneet, mutta toisaalta kriittisessä ympäristössä kauan toimineiden ketterien projektien onnistumistodisteet puuttuvat. Tämä alue siis tarvitsee enemmän huomiota, raportointia ja tutkimusta. Toinen mahdollinen syy ketterien menetelmien välttämiselle on se, että organisaatiot toteuttavat järjestelmiä tyydyttämään tiettyjä säädöksiä. Näiden säädösten viranomaistarkastajat ovat tottuneet ja hyväksyneet nykyisen pääsääntöisesti kurinalaisen kehitysmenetelmän, jolloin ketterien menetelmien käyttöönotto muuttaisi nykyistä menetelmää ja näin viranomaisten hyväksyntä ja luottamus tulisi ansaita uudelleen. Näin ollen muutoksia nykyiseen menetelmään ei haluta tehdä, koska ei haluta pitkää hyväksyttämisprosessia uudelle menetelmälle. Vielä jos huomioon otetaan, että todisteet ketteryyden menestykselle turvallisuuskriittisellä alueella on niukat, ei voida olla varmoja menetelmän muuttamisen kannattavuudesta. Voi olla, että turvallisuuskriittisellä alueella toimivat kehitysorganisaatiot odottelevat rannalla ja seuraavat, koska ensimmäiset rohkeat uskaltavat mahdollisille heikoille jäille ensin. Jos jäät kestävät, muut ryntäävät porukalla perässä.

On jokseenkin erikoista huomata, että lähes kaikissa julkaisuissa ketteryyden sopivuutta pohditaan pelkästään turvallisuuskriittisestä näkökulmasta ja säädösten tuomista haasteista menetelmän käytölle. Toki läpikäydyt julkaisut perustuvat juurikin ketteryyden ja kriittisyyden sovittamiseen, mutta toisaalta muutkin tekijät vaikuttavat ketterien menetelmien mahdolliselle käytölle, jolloin nekin tulisi huomioida. Kuten Boehmin ja Turnerin (2003) esittelemässä kotikenttäanalyysissä nähdään, vaikuttaa menetelmän valintaan organisaation järjestäytymisen kannalta viisi eri tekijää (Kuva 3). Tosin nykyhavaintojen perusteella ketteryys on mahdollista implementoida myös suurissa projekteissa. Turvallisuuskriittisyys saattaa myös kadota ketteryyden esteiden listalta, ainakin viitteitä on havaittavissa siihen suuntaan. Mutta organisaation järjestäytyminen ja henkilöstön menetelmän soveltamisen taito jäävät mielenkiintoisiksi tekijöiksi, jotka tulisi ehdottomasti ottaa huomioon menetelmän valinnassa. Nämä myös ovat tekijöitä, joihin voidaan

29

ulkopuolisella konsultoinnilla saada helpotusta, kuten muun muassa Rasmussen ym. (2009) olivat tehneetkin. Olisi mielenkiintoista lukea julkaisuja, joissa käytäisiin läpi ketterien menetelmien käyttöönoton, tai käytön, totaalisesta epäonnistumisesta ja kehityslaadun huonontumisesta. Varsinkin syyt siihen, miksi kehitysmenetelmän käyttö oli epäonnistunut. Olisiko se kenties henkilöstön osaaminen, organisaatiokulttuuri, jotain muuta vai kaikki yhdessä. Vaikka ketteryys on auttamatta lyönyt läpi ohjelmistokehitysprosessina, on tällä saralla vielä paljon tutkittavaa.

LÄHTEET

Abdelaziz, A., El-Tahir, Y. & Osman, R. (2015). Adaptive Software Development for Developing Safety Critical Software, IEEE Computer Society

Bannerman, P., Hossain, E. & Jeffery, R. (2012). Scrum Practice Mitigation of Global Software Development Coordination Challenges: A Distinctive Advantage?, 45th Hawaii International Conference of System Sciences

Beck, K. (1999). Embracing Change with Extreme Programming, IEEE Computer Society

Boehm, B. & Turner, R. (2003). Rebalancing Your Organization’s Agility and Discipline, XP/Agile Universe, Springer-Verlag Berlin Heidenberg

Boehm, B. (1984). Verifying and Validating Software Requirements and Design Specifications, IEEE Software

Cardonzo, E., Neto, J., Barza, A., Franca, A. & Silva, G. (2010). Scrum and Productivity in Software Projects: A Systematic Literature Review, 14th International Conference on Evaluation and Assesment in Software Engineering

Cawley, O., Wang, X. & Richardson, I. (2010). Lean/Agile Software Development Methodologies In Regulated Environments - State of the art, Int’l Conference Lean Enterprise Software and Systems, LNBIP 65

Cleland-Huang, J. (2012). Traceability in Agile Projects, Springer-Verlag, London, England

Cockburn, A. (2002). Agile Software Development, Addison WesleyCohen, D., Lindvall, M. & Costa, P. (2003). Agile Software

Development, DACS SOAR Report Deuter, A. & Engels, G. (2014). Measuring the Software Size of Sliced

V-model Projects, IEEE Computer SocietyDybå, T. & Dingsøyr, T. (2009). What Do We Know about Agile

Software Development?. IEE Computer SocietyDybå, T. & Dingsøyr, T. (2008). Empirical Studies of Agile Software

Development: A Systematic Review, ScienceDirectFitzgerald, B., Stol, K., O’Sullivan, R. & O’Brien, D. (2013). Scaling

Agile Methods to Regulated Environments: An Industry Case Study, the International Conference on Software Engineering, San Francisco

Ge, X., Paige, R. & McDermid, J. (2010). An Iterative Approach for Development of Safety-Critical Software and Safety Arguments, IEEE Computer Society, Agile Conference

Hrgarek, N. (2012). Certification and Regulatory Challenges in Medical Device Software Development, IEE, Software Engineering in Health Care, Zurich, Switzerland

31

Heeager, L. & Nielsen, P. (2009). Agile Software Development and its Compatibility with a Document-Driven Approach? A Case Study, 20th Australasian Conference on Information Systems, Melbourne

Ikoma, M., Ooshima, M., Tanida, T., Oba, M. & Sakai, S. (2009). Using a Validation Model to Measure the Agility of Software Development in a Large Software Development Organization, IEEE, Vancuver, Canada

Jonsson, H., Larsson, S. & Punnekkat, S. (2012). Agile Practices in Regulated Railway Software Development, IEEE 23rd International Symposium on Software Reliability Engineering Workshops

Ketterän ohjelmistokehityksen julistus (2001). Haettu 6.3.2016 osoitteesta http://agilemanifesto.org/iso/fi/

Knight, J. (2002). Safety Critical Systems: Challenges and Directions, the International Conference on Software Engineering, Orlando, Florida, USA

Lagerberg, L., Skude, T., Emanuelsson, P. & Sandahl, K. (2013). The Impact of Agile Principles and Practices on Large-Scale Software Development Projects, ACM/IEEE International Symposium on Empirical Software Engineering and Measurement

Lindvall, M., Basili, V., Boehm, B., Costa, P., Dangle, J., Shull, F., Tesoriero, R., Williams, L. & Zelkowitz, M. (2002). Empirical Findings in Agile Methods, Springer-Verlag Berlin Heidelberg

Mandal, A. & Pal, S. (2014), Achieving Agility Through BRIDGE Process Model: An Approach to Integrate Agile and Discipline Software Development, Springer-Verlag London

McCaffery, F., McFall, D., Donnelly, P., Wilkie, F.G. & Sterritt, R. (2005). A Software Process Improvement Livecycle Framework for the Medical Device Industry, IEEE International Conference and Workshops on the Engineering of Computer-Based Systems

McHugh, M., McCaffery, F., Fitzgerald, B., Stol, K. & Coady, G. (2013). Balancing Agility and Discipline in a Medical Device Software Organisation, Springer, Germany

McHugh, M., Cawley, O., McCaffery, F., Richardson, I. & Wang, X. (2013). An Agile V-Model for Medical Device Software Development to Overcome the Challenges with Plan-Driven Software Development Lifecycles, IEEE Computer Society, San Francisco, USA

Munassar, N. & Govardhan, A. (2010). A Comparison Between Five Models of Software Engineering, IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, ISSN

Mäder, P., Jones, P., Zhang, Y & Cleland-Huang, J. (2013). Traceability for Safety-Critical Projects, IEEE Computer Society

Rasmussen, R., Hughes, T., Jenks, J.R. & Skach, J. (2009). Adopting Agile in an FDA Regulated Environment, IEEE Computer Society, Agile Conference

Rottier, A. & Victor, R. (2008). Agile Development in a Medical Device Company, Agile Conference, IEE Computer Society

Royce, W. (1970). Managing the Development of Large Software Systems, IEEE WESCON, The Institute of Electrical and Electronics Engineers

Salo, O, & Abrahamsson, P. (2008). Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum, The Institution of Engineering and Technology, Oulu, Finland

Storey, N. (1996). Safety Critical Computer Systems, Addison-Wesley Longman Publishing Co.

Turk, D., France, R. & Rumpe, B. (2005). Assumptions Underlying Agile Software Development Processes, Journal of Database Management, Volume 16, No. 4, pp. 62-87

Wils, A., Van Baelen, S., Holvoet, T. & De Vlaminck, K. (2006) Agility in the Avionics Software World, Springer-Verlag Berlin Heidelberg

Wolff, S. (2012). Scrum Goes Formal: Agile Methods for Safety-Critical Systems, FormSERA, IEEE Computer Society