Beizer-Humprey-luokittelukäytäntö - Virheiden luokittelukäytäntöjä

2.2 Virheiden luokittelukäytäntöjä

2.2.3 Beizer-Humprey-luokittelukäytäntö

Ranisen, Toroin, Vainion ja Ahosen artikkelissa (2012) on esitetty kehittyneempi luo-kittelukäytäntö, joka pohjautuu luvussa 2.2.2 käsiteltyihin Beizerin ja Humphrey’n luokittelukäytäntöihin. Uuden luokittelumenetelmän päämääränä oli virheiden yksise-litteinen luokittelu ja toistettavuus. Uudessa luokittelukäytännössä on 10 virhetyyppiä, joista 9 on Humphrey’n ja 2 Beizeriltä (Taulukko 2). Humphrey’n ympäristövirhe-tyyppi on yhdistetty Beizerin ”Build and package” - tyypin kanssa. Taulukossa 3 on esitetty tarkemmin tämä kehittyneempi virheluokittelumalli.

# 1. 2. 3. 4. 5.

(Assignment) Versio (Build, package) Tarkistus

(Checking) Tieto (Data) Dokumentointi (Dokumentation)

(Environment) Toiminto (Function) Liittymä

(Interface) Syntaksi (Syntax) Systeemi (System)

Taulukko 3: Kehittyneempi luokittelumenetelmä, joka perustuu Humphrey’n ja Beizerin mal-leihin mukaillen lähdettä (Raninen et al. 2012).

Luokittelumalli vaikuttaa selkeältä, yksiselitteiseltä ja toistettavalta eri projekteissa ja eri henkilöiden tekemänä. Tätä menetelmää selkeyttää käyttöä avaavat virhetyyppien selitteet. (Raninen et al. 2012, Taulukko 3) Erityisesti avaavat selitteet auttavat virhe-luokituksen tekoa käytännön tilanteessa ja näin ollen saadaan homogeenisempi luoki-tus eri henkilöiden tekemänä eri projekteissa.

Taulukossa 4 on esitetty Ranisen, Toroin, Vainion ja Ahosen artikkelista oleva tau-lukko, missä kuvataan tämän virheluokitusmenetelmän luokittelun käytännön tuloksia kolmessa eri yhtiössä.

Nro Virhetyyppi Lähde Virhetyyppi selite

1. Assignment Humphrey Virheet muuttujien määrityksissä ja laajuuksissa 2. Build, package,

environment

Beizer, Humphrey

Ympäristövirheet, jotka vaikuttavat versio- ja muutoshallintaan (Kirjasto- ja muutos &

versiohallinnan kontrollivirheet) 3. Checking Humphrey Tarkistusvirheet, puutteelliset tarkistukset 4. Data Humphrey Tietovirheet tietokantojen rakenteissa 5. Documentation Humphrey Dokumentointivirheet (mm. käyttäjille

suunnatuissa viesteissä)

6. Function Humphrey Toimintavirheet laskenta- ja toimintalogiikassa 7. Integration Beizer Integrointivirheet (rajapintavirheet ja ongelmat) 8. Requirements Beizer Vaatimusvirheet (väärinymmärretyt tai

puutteelliset kuvaukset)

9. System Humphrey Järjestelmävirheet (kokoonpano-, ajoitus-, muisti- ja laitteistovirheet)

10. User Interface Humphrey Käyttöliittymävirheet (syöttö-, tulos- ja näyttövirheet)

Taulukko 4: Virhejakaumien vertailua kolmessa eri yhtiössä (Raninen et al. 2012)

Taulukosta voimme havaita, että jakaumat ovat melko samankaltaisia eri yhtiöissä.

Selkeästi yleisin virhetyyppi on toiminnalliset virheet, joita on keskimäärin yli puolet kaikista virheistä. Seuraavaksi yleisin virheluokka on käyttöliittymävirheet. Harvinai-semmat virheet liittyivät vaatimuksiin ja dokumentointiin.

Toiminnallisten virheiden suuri määrä edesauttaa ajattelemaan, että kenties olisi jär-kevää analysoida niitä vielä tarkemmalla tasolla, jotta varmistetaan laadukkaampi tie-tämys kehitysprosessin parantamiseksi.

2.2.4 Useamman tason virheluokittelumalli SAWO

Virheluokitusmenetelmissä virheet voivat jakaantua melko epätasaisesti eli johonkin tai joihinkin virheluokkiin kohdistuu valtaosa löydetyistä virheistä. Jos virheiden määrä luokkaa kohti on kovin suuri, niin niiden analysointi on haasteellista. Tätä on-gelmaa voidaan helpottaa käyttämällä monitasoista virheluokituskäytäntöä, jolloin päästään helpommin virheiden perussyiden analysointiin ja todellisempiin tuloksiin.

Tässä luvussa kuvataan Toroin, Ranisen, Vainion, Väätäisen artikkelissa kuvattua use-amman tason virheluokittelumenetelmää. Tämä menetelmä perustuu toiminnallisten virheiden luokitteluun ja on tarkoitettu käytettäväksi virhetiedon hyödyntämiseen oh-jelmiston kehittämisprosessissa. Menetelmän ansiosta virheet voidaan luokitella sopi-valla tarkkuudella, jotta voidaan tuottaa käytännöllisiä kehitysehdotuksia ohjelmisto-kehitysprosessin eri vaiheisiin ja niiden edelleen kehittämiseen. Virhedataa on harvoin hyödynnetty kehitysprosessin kehittämisessä, varsinaisesti sitä on käytetty hyödyksi

testauksen kehittämisessä. Hyvin luokitellun virhedatan käyttö prosessin kehittämi-sessä tarjoaa käytännöllisen, tehokkaan ja useimmiten melko halvan tavan prosessin kehittämiselle.

Toroin, Ranisen, Vainion, Väätäisen 2013 artikkelissa on kehitetty SAWO-luokittelu-käytäntö prosessien kehittämisen näkökulmasta. SAWO-luokitteluSAWO-luokittelu-käytäntö luokittelee virheet kolmella tasolla (Kuva 3). Ensimmäinen taso luokittelee virheet yleisellä ta-solla kuten edellä esitetyt virheluokitusmenetelmät. Toisella tata-solla kohteena ovat toi-minnalliset virheet (joita yleensä on yli puolet kaikista virheistä) ja kolmannella tasolla syvennetään virhetietoutta erityisesti kontrollitiedon, prosessoinnin, laskennan ja toi-minnallisen logiikan osalta.

Kuva 3: SAWO-luokittelukäytännön rakenne (mukaillen Toroi et al. 2013)

SAWO-luokittelukäytännössä virheet luokitellaan ensin yleisesti 10 eri luokkaan. Seu-raavaksi SAWO-luokittelukäytännössä luokitellaan yleisimmät eli toiminnalliset vir-heet kuuteen eri luokkaan ja kolmannessa vaiheessa vastaavasti luokitellaan virvir-heet kuuteen eri luokkaan ominaisuus-/toiminnollisten oikeellisuusvirheiden (feature / function correctness defects) osalta. Tällaisen luokittelun jälkeen on perussyiden ana-lyysin avulla helpompi löytää aitoja kehityskohteita ja kehitysideoita.

SAWO-menetelmän hyödyntämisen tulokset pohjautuvat kolmen eri yhtiön virhe-dataan usean vuoden ajalta (Toroi et al. 2013). Kyseisen aineiston (joka sisälsi yh-teensä 6363 virheen tiedot) perusteella ensimmäisellä tasolla eniten oli toiminnallisia

virheitä (59,7 %) ja samalla tasolla toiseksi eniten oli käyttöliittymävirheitä 15,6 %.

Vähiten oli vaatimusvirheitä, joita oli vain 0,2 %. Virheprofiilit ja virhejakaumat kol-messa kohdeyhtiössä olivat samanlaiset. SAWO-virheluokittelumenetelmän virhe-jakaumat eri tasoilla kolmen eri yhtiön virhedatan osalta kuvataan tarkemmin Toroin, Ranisen, Vainion ja Väätäisen 2013 artikkelin taulukoissa kaksi, kolme ja neljä.

SAWO-mallin tasolla kaksi luokiteltiin edellä mainitut toiminnalliset virheet, joita oli siis 59,75 % kaikista virheistä, 6 alaluokkaan. Tällä toisella tasolla puolestaan toimin-nallisista virheistä 56,7 % oli ominaisuus-/toiminnallinen oikeellisuusvirheitä (fea-ture/function correctness defect) (Toroi et al. 2013).

Tasolla kolme jaetaan vielä toiminnalliset oikeellisuusvirheet 6 alaluokkaan, koska niiden määrä oli niin suuri tasolla kaksi (56,7 %). Tällä kolmannella tasolla yleisin virhetyyppi oli selaus-, päivitys- ja siirtovirheet (51,8%) (Toroi et al. 2013).

Katsottaessa virheiden jakaumia näillä kolmella eri tasoilla, niin aina jokin virhetyyppi dominoi kutakin tasoa eli ao. tyypin virheitä on yli 50 % kyseisen tason virheistä ja seuraavaksi yleisimmän virheluokan virheiden määrä on noin 20 % -luokkaa. Lisäksi virhejakaumat Toroin, Ranisen, Vainion ja Väätäisen tutkimusaineiston perusteella ovat joka tasolla eri yhtiöissä jotakuinkin samanlaisia, mikä mielestäni vakuuttaa vir-heluokittelun toimivuuden ja toistettavuuden.

Kun virheet on luokiteltu edellä kuvatulla SAWO-menetelmällä ja analysoitu virhei-den juurisyyt, niin voidaan tuottaa virhedataan pohjautuvia kehitysehdotuksia ohjel-mistokehitysprosessiin. Koska eri organisaatioiden välillä oli kuitenkin hiukan eroja virhejakaumissa, niin myös prosessin kehittämisehdotukset ovat käytännössä organi-saatiokohtaisia. Virhejakaumat muistuttavat ainakin Toroin ja kumppaneiden (2012) artikkelin esimerkkiaineistossa niin paljon toisiaan, että on hyödyllistä vertailla orga-nisaatiokohtaisia virhedatan jakaumia ja niistä johdettuja kehitysehdotuksia.

18 2.2.5 Muita löytämiäni virheluokitteluita

Scopus-hakulausekkeella TITLE(software OR application) AND TI-TLE("Fagan Inspection" OR "Fagan" ) AND TITLE("defect classification") hakutulokseksi tuli 59 hakutulosta, joista valitsin seuraavat:

− “Defect management strategies in software development”, jossa käsitellään Fa-ganin tarkistusmenetelmää (Fagan Inspection) ja myös Humphrey tarkis-tusmenetelmää (Suma & Gopalakrishnan 2009).

− “Survey of software inspection research”, jossa käsitellään Faganin tarkistus-menetelmän kokonaisprosessin toimintaa (Kollanus, & Koskinen 2009).

− “A Practical Approach to Software Quality” verkkokirja, jossa käsitellään kat-tavasti Faganin tarkistusmenelmää (O’Regan 2002).

Muita käyttämiäni lähteitä ovat seuraavat:

− “A Replicate Empirical Comparison between Pair Development and Software De-velopment with Inspection” (Phongpaibul & Boehm 2007)

− “An Empirical Study on Software Error Detection: Voting, Instrumentation, and Fagan Inspection” (Sunsup et al. 1995)

Käyttämissäni lähteissä Faganin tarkistusmenetelmässä voidaan luokitella virheet vä-hintään kahteen eri luokkaan, jotka ovat päävirheet (major defects) eli ohjelman toi-mintaa estävät virheet ja vähäiset virheet (minor defects) eli ohjelman toitoi-mintaa ei-estävät virheet, kuten käyttöliittymävirheet. Lisäksi luokkia voi olla tarpeen mukaan enemmänkin. Muuten muissa Google Scholar -lähteissä kuvataan tarkemmin, kuinka Fagan tarkistusmenetelmää toteutetaan. (Sunsup et al. 1995; Phongpaibul & Boehm, 2007).

Kuvaus El Emam luokittelusta keskittyy ”The repeatability of code defect classificati-ons” artikkeliin, jossa El Emam on toteuttanut oman sopivan luokittelumenetelmänsä (Emam & Wieczorek 1998).

Tämän lisäksi olen käyttänyt lähdettä: ”Defect Data Analysis as Input for Software Process Improvement” (Raninen et al. 2012), joka käsittelee tätä luokittelua perustuen

”The repeatability of code defect classifications” (Emam & Wieczorek 1998) artikke-liin.

El Emam -virheluokitus, jota käsitellään myös Ranisen, Toroin, Vainion, Ahosen ar-tikkelissa, sisältää 11 virheluokkaa, jotka ovat parametri (assigment), versio (build, pagkage), tarkistus (check), tieto (data), dokumentointi (documentation), ympäristö (environment), toiminto (function), liittymä (interface), muisti (memory), nimeämis-käytännöt (naming conventions) ja ymmärrettävyys (understandability) virheluokat (Raninen et. al 2012, Taulukko 5).

Taulukko 5: El Emam virheluokitus mukaillen lähdettä (Raninen et al. 2012)

IEEE-julkaisussa vuodelta 2010 käsitellään IEEE Standardi -luokittelumallia, jossa voidaan luokitella virheitä useilla eri tavoilla muun muassa prioriteetin mukaisesti kor-keaksi, keskisuureksi tai vähäiseksi virheeksi. Lisäksi virheet voidaan luokitella vir-hetyypeittäin / virheluokittain. Virheluokat ovat muun muassa seuraavat: tietovirhe (data), käyttöliittymävirhe (interface), ohjausvirhe (logic), kuvausvirhe (description), syntaksivirhe (syntax), standardivirheet (standartds) ja muut virheet (other). Muita luo-kitteluita voidaan tehdä muista ominaisuuksista, joita ovat muun muassa tila (status), vakavuus (severity), todennäköisyys (probability), vaikutus (effect), malli (model), tarkistuksen toteutusvaihe (insertion activity), virheen havaitsemisvaihe (detection ac-tivity), virheen sijainti (disposition). (IEEE 2010)

# 1. 2. 3. 4. 5. 6.

(Checking) Tieto (Data) Dokumentointi (Documentation)

20 2.2.6 Yhteenvetoa luokitteluista

Edellä esitetyissä virheluokitusmalleissa luokkien määrä vaihtelee kahdesta (Fagan tarkistus) yhteentoista (El Emam luokittelu). Luvussa 2.2.1 esitetty versio ODC-luo-kittelu on varmaankin selkeä, mutta todennäköisesti - kun luokkia on vähän - virheet kasaantuvat (Kumaresh & Baskaran, 2010) ohjelmointi/koodaus - luokkaan, jolloin tähän kerääntyy hyvin monen tyyppisiä virheitä. Virheiden kasaantuessa liikaa johon-kin luokkaan, saattaa olla vaikeaa hyödyntää niistä saatavaa informaatiota prosessien kehittämisessä. Hyödyntämisen kannalta on tärkeää, että luokitus on riittävän kattava mutta ei kuitenkaan liian hienojakoinen, jotta voidaan tehdä kehittämisen kannalta oi-keita johtopäätöksiä.

Luokkien selkeys, yksiselitteisyys ja ymmärrettävyys ovat helposti haasteellisia, jos apuna ei ole mitään muuta kuin virheluokan nimi. Virheluokitusten eräs tärkeä näkö-kulma on, miten saadaan luokituksen tulokset helposti hyödynnettyä. Edellä mainittu varmistetaan sillä, että luokitus on riittävän kattava, helposti ymmärrettävä ja sitä tois-tettaessa tulokset ovat samanlaiset.

Käytännön tilanteissa edellä esitetyistä luokittelumenetelmistä on melko vaikeaa va-lita, mitä käyttäisi. Valinnan perusteena täytyy olla jotakin lisätietoa muun muassa vir-heluokkien sisällöstä (kuvaukset) ja ohjeita luokkien käytännön soveltamisesta.

3 Elinkaarimalliajattelu kehitysajurina

FiSTB eli Finnish Software Testing Board on kansanvälisen järjestön ISTQB®:n Suo-men paikallisjärjestö ja sen sivustolta löytyy ISTQB® Ketterä testaaja -sertifikaattiin liittyvä harjoituskoe⁸ ja vastaukset⁹. FiSTB:n sivustolta löytyy myös ISTQB® Perus-taso -sertifikaattiin liittyvä harjoituskoe¹⁰ ja vastaukset¹¹, joista löytyy elinkaarimallien merkitystä kuvaava kysymys eli ”Mitä on tärkeää tehdä, kun työskennellään ohjelmis-tokehitysmallien kanssa?” ja vastaus kuuluu ”Soveltaa tarpeen mukaan malleja pro-jektin ja tuotteen ominaisuuksien perusteella. Mallit tarjoavat yleisiä linjauksia ja eivät tarkkoja ja askel-askeleelta kirjaimellisesti noudatettavia prosesseja”.

Seuraavaksi tarkastelemme millaisia linjauksia antaa perättäisiä elinkaarinmalleja edustava vesiputousmalli (Luku 3.1), ketterä kehitys (Luku 3.2), DevOps (Luku 3.3) ja erilaiset kehitysputket ja konttikehitys (Luku 3.4), jotka ovat tulleet elinkaariajatte-lun rinnalle ja joilla havainnollistetaan esimerkiksi idean jalostumista käytettäväksi palveluksi. Ketterällä kehityksellä pyritään tuottamaan toimivia ohjelmistoja mahdol-lisimman nopeasti. DevOpsin tavoitteena on ohjelmistotuotannon automatisointi. De-vOps tulee sanoista Development (kehitys) ja Operations (tuotanto) - sen avulla lisä-tään kehityksen ja tuotannon/ylläpidon vuorovaikutusta ja tehokkuutta. Kehitysput-kella (pipeline) voidaan kuvata yleisellä tasolla kehitysprosessia ja kontilla (container) voidaan kuvata kehitettäviä sovelluskokonaisuuksia tai -palveluita (Kim et al. 2013).

8 http://www.fistb.fi/sites/fistb/files/liitteet/Kettera%20testaaja%20laajennus-%20Harjoituskoe.pdf

9 http://www.fistb.fi/sites/fistb/files/liitteet/Kettera%20testaaja%20laajennus%20-%20Harjo-ituskoe%20vastaukset.pdf

http://www.fistb.fi/sites/fistb/files/liitteet/CTFL%20Sam-ple%20exam%202011%20v%202.6%20k%C3%A4%C3%A4nnetty.pdf

http://www.fistb.fi/sites/fistb/files/liitteet/CTFL%20Sam-ple%20exam%202011%20v%202.6%20k%C3%A4%C3%A4nnetty%20perustelut.pdf

3.1 Vesiputousmalli

Vesiputousmalli on perinteisesti yleisesti käytetty lähestymistapa järjestelmien ja so-vellusten kehittämiseen ja tuottamiseen. Vesiputousmalliin kuuluu vaiheita, jotka seu-raavat toisiaan lineaarisesti. (Kuva 4) Vesiputousmallin vaiheita voivat olla esimer-kiksi seuraavat:

− Vaatimuksien määrittely (Requirements). Naveen 2017

− Analysointi (Analysis). Naveen 2017

− Suunnittelu (Desing). Naveen 2017.

− Toteutus/Koodaus (Implementation/Coding). Naveen 2017, Lotz 2013.

− Yksikkötestaus (Unit test). Lotz 2013.

− Järjestelmätestaus (System test). Lotz 2013.

− Käyttäjän hyväksymistestaus (User Acceptance Test eg. UAT). Lotz 2013.

− Virheiden korjaus (Fix any issues). Lotz 2013.

− Toimitus (Deployment). Lotz 2013.

− Ylläpito (Maintenance). Naveen 2017.

Eri vaiheiden välillä voi olla muun maussa asiakkaan tarkistus ja hyväksymispisteitä.

Mallissa pyritään etukäteissuunnitteluun ja huomioimaan tavoitteet sekä kaikki vai-kuttavat asiat alkuvaiheessa. Tehdyn suunnitelman odotetaan toteutuvan määritetyillä tavoilla, joten odottamattomia tilanteita tai korjauksia jälkikäteen on kallista toteuttaa.

(Lotz 2013, IT Knowledge portal 2017, Naveen 2017)

Kuva 4: Vesiputousmalliesimerkki (mukaillen Naveen 2017 ja Lotz 2013)

Mallissa toteutetaan tarkkaa suunnittelua kaikista toimista ja tehdään selkeä projektin rakenne, mikä selkeyttää tavoitteita ja aikataulutusta. Projektin jäsenet voivat tehdä eri tehtäviä vaiheesta riippuen ja asiakkaiden läsnäolo projektin aikana ei välttämättä ole pääosin kovin aktiivista. Mallia käytetään suurissa projekteissa ja useita ohjelmisto-komponentteja sisältäviä järjestelmiä kehitettäessä. Mahdollisia haasteita mallissa on esimerkiksi tehokkuus, joka voi osaltaan jäädä vajaaksi johtuen muun muassa vaati-musten määrittely-, dokumentointi- ja toimitusvaiheista. Jos nämä vaiheet on tehty puutteellisesti tai osapuolet eivät ole ymmärtäneet toisiaan oikein muun muassa tavoit-teissa ja määrittelyissä, lopputulos voi jäädä puutteelliseksi. Tällöin myöhemmin to-teutetut korjaukset ja muutokset projektissa tulevat olemaan entistä kalliimpia ja pa-himmillaan projektia ei ole kannattavaa toteuttaa loppuun asti. Malli ei sovellu riskialt-tiisiin projekteihin, joissa tapahtuu paljon muutoksia tai on paljon epävarmuutta joh-tuen mallin jäykkyydestä reagoida näihin. (Lotz 2013, Rasmusson 2017, ISTQB Exam Certification 2017)

3.2 Ketterä (agile) kehitys

Ketterässä (agile) kehityksessä on eri tarkoituksiin menetelmiä, joita ovat Mark Smal-leyn ja Dave Van Herpenin (2014) mukaan muun muassa seuraavat:

− projektinhallintaan tarkoitettu Scrum

− tuotannon (kuten pienkehitys tai ylläpidon tuki) ajoitusmenetelmä Kanban

− koko organisaation tai laajojen hankkeiden ohjelmisto- ja palvelukehityksen toimivaksi todennetut toimintatavat ja kokonaisvaltainen ohjeistus SAFe (Sca-led Agile Framework)

− ohjelmointiin tarkoitettuja menetelmiä kuten XP (Extreme Programming)

− ohjelmistokehitysmenetelmät DSDM (Dynamic Systems Development Method) ja FDD (Feature-driven development)

Ketterän ohjelmistokehityksen julistus¹² annettiin vuonna 2001 ja seuraavaksi käsitel-lään ketterän kehityksen neljää perusarvoa hieman tarkemmin (Kuva 5):

− Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja. Kehitys-tiimit ovat rakenteeltaan luonnollisia ja joustavia sen sijaan, että olisivat enem-män mekaanisia, byrokraattisia ja virallisia. Erityisroolit tiimeissä voivat olla hidasteena ketterien mallien päätöksenteossa operatiivisilla tasoilla, joten tii-meissä ei erityisesti pyritä rajoittumaan juuri tiettyihin tehtäviin tai tekniikoi-hin, vaan pyritään muun muassa tehtävien itsenäisiin järjestelyitekniikoi-hin, vaihtoihin ja yhdistämisiin. Tehtäviä päätöksiä voidaan tehdä myös jäsenten osaamisalu-een ulkopuolisista asioista. Kun ryhmässä yhdessä pyritään tunnistamaan on-gelmat, saadaan uusia ideoita, joita tutkitaan ja mahdollisesti pystytään ratkai-semaan havaittuja ongelmia. Tällaisella toimintatavalla projektissa pyritään tehokkaampaan projektinhallintaan ja tulosten tuottamiseen. (Drury-Grogan et al. 2016, Hoda et al. 2017, IT Knowledge portal 2017, Smalley 2014)

12 http://agilemanifesto.org/iso/fi/manifesto.html

− Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota. Projekteissa pyritään käyttämään mahdollisimman vähän aikaa erilliseen dokumentointiin ja hyödynnetään dokumentoinnissa hyödyllisiä dokumentointiominaisuuksia, joilla nopeutetaan toteutettavan tuotteen toimitusta. Koska ketterän mallin ke-hittämistiimit ovat pienikokoisia ja päätöksen teko on suoraviivaisempaa, niin tarvittava dokumentointikin on vähäisempää.

− Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja. Projektitiimit ovat yh-teydessä hyvin monessa vaiheessa keskenään, kuten päätöksenteossa, jatku-vassa testauksessa ja palautteen käsittelyssä sekä myös lopullisissa hyväksy-misvaiheissa. Perinteisessä kehittämisessä yhteydet painottuvat pääosin alku-vaiheeseen ja loppualku-vaiheeseen sekä lopulliseen hyväksymiseen.

− Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa. Esimer-kiksi Scrumissa pyritään useasti julkaisemaan “sprintin” tuloksia ja reagoi-maan tuloksiin mahdollisimman nopeasti seuraavia sprinttejä varten. Näin on mahdollista havaita esimerkiksi mahdollisia virheitä tai muita muutoksia ta-voitteissa nopeasti ja tehokkaasti. Korjaukset ja muutokset voidaan tehdä no-peasti ennen kuin ne ehtivät vaikuttaa laajemmin koko projektiin. Näin tavoit-teet on ohjattu oikeampaan suuntaan. (Drury-Grogan et al. 2016, Rasmusson 2017)

Kuva 5: Agile-mallin arvot ja haasteet (mukaillen Drury-Grogan et al. 2016)

Ketterän kehityksen projekteihin liittyy päätösten käsittely, tiedonkeruu ja laadun-käsittely. Jos jotakin näistä vaiheista ei tehdä kunnolla, voi syntyä huonompaa tulosta ja resurssien lisäkulutusta verrattuna hyvin suoritettuun sovellusprojektiin. Nämä kolme eri osiota vaikuttavat vastaavasti toisiinsa. Esimerkiksi liiallisen tarkka käsittely

ei ole täysin soveltuvaa ketterässä kehityksessä, sillä esimerkiksi liiallinen tiedonkeruu voi hidastaa tai vaikeuttaa työstämistä (Drury-Grogan et al. 2016).

Kuva 6: Ketterä (Agile)-malli (mukaillen Lotz 2013)

Ketterässä kehityksessä painopisteinä ovat kevyet työskentelytavat, kyky sopeutua no-peasti epävakaisiin vaatimuksiin, jatkuva toimitus ja asiakasyhteistyö pitkien suunni-teltujen joustamattomien työstämisvaiheiden ja raskaan dokumentoinnin sijaan. Ket-terille menetelmille on ominaista tiimityöskentely, asiakaslähtöisyys, yksinkertaisuus, trendien ja palautteiden seuraaminen ja muutoksiin reagoiminen. Ketterässä kehityk-sessä voidaan noudattaa annettuja ennakkotietoja ja joustavia käytäntöjä. Esimerkiksi sprinttien päätöksiä tehtäessä pyritään arvioimaan, mitä tiimi voi saada aikaiseksi ja siten ei välttämättä pyritä täysin täyttämään tavoitteita kuten muissa perinteisissä mal-leissa. Kuvassa 6 kuvataan sprinttiä kahtena eri nuolena kahden eri vaiheen välillä.

Ketterä kehitys keskittyy ohjelmistosuunnittelun inhimillisiin ja yhteiskunnallisiin nä-kökohtiin sekä ylipäätänsä yhteistyön lisäämiseen eri osapuolten välillä hyödyntäen muun muassa reaaliaikaista viestintää ja että viestintä on laadukasta ja sitä on riittä-västi eri osapuolten välillä. Jokaisessa kehitysjaksossa aikaa on rajoitetusti, mikä pa-kottaa priorisoimaan tehtäviä. (IT Knowledge portal 2017, Agile Alliance 2017, Hoda et al. 2017, Kupiainen et al. 2015, Bartsch 2011)

Ketterässä kehitysmallissa etuina on muun muassa asiakkaan toiveiden parempi huo-mioiminen projektin aikana ja tehokkaalla kommunikaatiolla eri osapuolien sitoutta-minen projektiin. Ketterällä kehitysmallilla on mahdollista tuottaa projektista perus-versioita ja myös laajempi lopullinen versio sekä lisäksi mallin käyttäjäystävällisyys helpottaa käyttäjien suhtautumista luotuun tuotteeseen. (TatvaSoft 2015, Lotz 2013, Bartsch 2011, Kröger 2017)

Haasteita ketterissä menetelmissä voidaan kohdata tehtäessä suuria projekteja, jotka tarvitsevat laaja-alaista suunnittelua. Myös ongelmana voi olla dokumenttien vähyys, asiakkaan puutteellinen osallistuminen, kiinnostus tai halukkuus osallistua projektiin, kommunikaation tai tarvittavan osaamisen puute projektiryhmässä, projektin jäsenien fyysiset sijainnit sekä kehityksen iteraatiot. Jos järjestelmän oikeaa laajuutta ei ole osattu ottaa huomioon, tarvittavat muutokset voivat johtaa uudelleen laajaan kokonai-suuden aktivointiin. Näin laatu, aikataulu ja projektin kustannukset voivat kärsiä eri-laisista virhearvioista. Myös liian läheiset suhteet tai luottamuksen puute eri osapuol-ten välillä voivat haitata neutraalia näkemystä projektista tai hankaloittaa toteutusta.

Esimerkiksi tietoturvaohjelman kehittäjän ja tarkastajan liian luottamuksellinen suhde voi vaarantaa objektiivisuuden tai kriittinen suhde voi haitata esimerkiksi tarvittavien oikeuksien toteuttamista projektissa. Muita haasteita voi olla esimerkiksi alan osaami-sen tai johtamiosaami-sen puute tiimiryhmässä. (TatvaSoft 2015, Lotz 2013, Bartsch 2011, Kröger 2017)

Laajojen projektien toteuttaminen voi olla hankalaa ketterillä menetelmillä verrattuna vesiputousmalliin. Vesiputousmallissa aluksi tehtävä kattava suunnittelu soveltuu suu-rille projekteille hyvin. Ketterässä kehityksessä pyritään suunnittelemaan ja suunnitel-mia tarkentamaan projektin aikana, joten heti alussa ei välttämättä ole kattavaa suun-nitelmaa projektin kokonaisuudesta selkeyttämässä isoja projekteja. Ketterää mallia on helpointa käyttää pienemmissä projekteissa. (TatvaSoft 2015, Lotz 2013, Bartsch 2011, Kröger 2017)

3.3 DevOps-malli

DevOps kehitettiin vuonna 2008 Patrick Deboisn ja Andrew Shaferin toimesta. Ylei-semmin tämä kokonaisuus esiteltiin Velocity Conference community -nimisessä kon-ferenssissa John Allspawn ja Paul Hammondin toimesta vuonna 2009 (Kim et al.

2013.). Automaatio on DevOpsin yksi keskeisimmistä tavoitteista, jopa testauksessa (Marschall 2010). Dev on käytetty lyhenteenä kehittäjistä (developer), mutta todelli-suudessa termi käsittää kaikki ihmiset ja asiat kehittämiseen liittyen. Ops ei viittaa pelkästään tuotantoon (operations), vaan osaltaan tällä voidaan viitata myös kaikkeen

mahdolliseen kuten työnimikkeisiin järjestelmäinsinööreistä turvallisuusinsinöörei-hin. Videolähteen perusteella DevOps tukee ja osin toteuttaa (Mueller 2017, Smalley

& Herpen 2014)

− Lean-johtamisfilosofiaa, joka keskittyy seitsemän (kuljetukset, varastot, liike, odotusaika, ylituotanto, yliprosessointi ja viallinen tuote) erilaisen ’turhuuden’

(tuottamattoman toiminnon) poistamiseen

− ToC (Theory of Constraints) ajattelutapaa, jossa asioita pyritään hallitsemaan paremmin tavoitteiden saavuttamiseksi

− ITIL (Information Technology Infrastructure Library) käytäntöjä IT-palvelui-den hallintaan ja johtamiseen

− ALM (Application Lifecycle Management) käytäntöjä sovelluksen elinkaaren hallintaan; erilaisia ketteriä (agile) menetelmiä

− Ketterää (agile) kehitystä

− Pilviympäristöjä (Cloud).

DevOps pohjautuu periaatteessa tarpeeseen hyödyntää käytössä olevia sovelluksia, joiden uusimpia ominaisuuksia voidaan lisätä tuotantoympäristöön milloin tahansa.

Tämä on hyödyllistä kehitettäessä esimerkiksi puhelinsovelluksia, joissa varsinaiseen perussovellukseen voidaan muokata ja lisätä tarvittavia ominaisuuksia. Myös voidaan hyödyntää mallin jatkuvaa integrointia eli pienempien komponenttien yhdistämistä toimiviksi kokonaisuuksiksi. Puhelinsovelluksissa esimerkiksi säännöllisesti tehtyjen integraatioiden avulla voidaan tuoda parhaiten uudet ominaisuudet perussovelluksiin sekä voidaan hyödyntää mahdollisuuksien mukaan myös muissa sovellustyypeissä ke-hitettyjä uusia ominaisuuksia. Lisäksi näin toteutettuja ominaisuuksia voidaan hyö-dyntää yleisemmin eri sovelluksissa. Ylipäätänsä kehitettäessä ja otettaessa käyttöön näitä uusia ominaisuuksia eri ryhmät kuten kehitysryhmä ja operatiivinen ryhmä pyr-kivät yhdessä jatkuvasti tuottamaan uusia versioita syyllistämättä toisiaan esimerkiksi mahdollista viivästyksistä tai virheistä. Näissä jatkuvissa tuotantokäyttöön otettavissa toiminnoissa on mahdollista hyödyntää automaatiota, jolloin voidaan helpottaa toteu-tettavien tehtävien määrää. Mallilla voidaan havaita tehtävät muutokset, kuinka

mah-29

dolliset muutokset voidaan toteuttaa ja kuinka testauksessa voidaan hyödyntää auto-maatiota. Tehtävät muutokset ja toiminnot pidetään riittävän pieninä, jolloin mahdol-lisia riskejä voidaan vähentää siirrettäessä muutoksia varsinaiseen tuotantoon ja siten helpotetaan esimerkiksi automaation toteuttamista ja ylipäätänsä hallintaa.

Kuva 7: DevOps-työkulkumalli (mukaillen Farroha & Farroha 2014 ja Kröger 2015)

DevOps hyödyntää ketterää kehitystä, mutta painottaa yhteistyötä eri liiketoimintaryh-mien lisäksi IT- ja kehitystyöryhliiketoimintaryh-mien kanssa keskittyen sekä nopeuteen että laadun parantamiseen prosessin aikana (Smalley 2014, Rowe 2013). Kröger (2016) on käsi-tellyt tutkimuksessaan IBM vuonna 2013 esittämää näkemystä, jonka mukaan DevOps on eräällä tavalla päättymätön silmukka, joka perustuu palautteen antamiseen ja sitä kautta kehittymiseen (Kuva 7). Kun pyritään yhdistämään asiakkaita, liiketoiminnan omistavia tahoja ja eri IT-tiimejä eli kehityksen, testauksen ja hallinnollisen instanssin toimijoita yhdeksi kokonaisuudeksi, niin tämän yhdistämisen pitäisi parantaa liiketoi-minnan suorituskykyä eli tuoda tasapainoa laadun ja kustannustenkin osalta (Perrow 2013). DevOps tukee jatkuvaa testausta, toimittamista ja palautteen käsittelyä sekä eri ryhmien välisten rajojen rikkomista, joiden ansiosta parannetaan ryhmien kommuni-kaatiota esimerkiksi katkoksien välttämiseksi. Projektissa tavoitteena on yksinkertai-sesti kehittää projektityöskentelyä paremmaksi samalla työstäen varsinaista projektia.

In document Ohjelmistovirheiden luokittelun hyödyntäminen ohjelmistotuotantoprosessin kehittämisessä (sivua 14-0)