Ohjelmistovirheiden luokittelun hyödyntäminen ohjelmistotuotantoprosessin kehittämisessä
Juho Burman
Pro gradu -tutkielma
Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede
Marraskuu 2017
i
ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Kuopio Tietojenkäsittelytieteen laitos
Tietojenkäsittelytiede
Opiskelija, Juho Burman: Ohjelmistovirheiden luokittelun hyödyntäminen ohjelmis- totuotantoprosessin kehittämisessä
Pro gradu -tutkielma, 62 s.
Pro gradu -tutkielman ohjaaja: FT Virpi Hotti Marraskuu 2017
Tietojärjestelmillä on erittäin suuri rooli ja merkitys yritysten jokapäiväisessä toimin- nassa. Näin ollen tietojärjestelmien häiriötön toiminta sekä tietojärjestelmäprojektien tehokas toteuttaminen ovat yrityksen toiminnan kannalta ensisijaisen tärkeitä. Tehokas vianhallinta edistää näitä tavoitteita.
Virheluokittelukäytännöt kehittyvät ajan edetessä tarkemmiksi ja tehokkaammiksi, niillä voidaan entistä paremmin hallinnoida ja analysoida havaittuja virheitä projek- teissa sekä kehittää ohjelmistokehitysprosessia entistä paremmaksi. Lisäksi varsinaiset kehittämisen elinkaarimallit ovat kehittyneet vesiputousmallista ketteriin malleihin (Agile) ja DevOps-malleihin, jotka ovat entistä tehokkaampia ja vähemmän virheitä tuottavia käytäntöjä. Elinkaarimallit ovat kehittymässä suuntaan, jossa mallit itsessään vähentävät virheitä lisääntyvän automaation avulla. Tutkittavaksi asiaksi nousee vir- heluokitteluiden merkitys nykyaikaisissa kehittämismalleissa.
Tässä tutkielmassa vikojen hallintaa tarkastellaan esittelemällä erilaisia virheiden luo- kittelutapoja/-menetelmiä. Näiden lisäksi tutkielmassa on kuvattu yksinkertainen, te- hokas ja helposti toteutettava ohjelmistokehitysprosessin kehittämismalli, joka poh- jautuu virheiden luokitteluun ja analysointiin. Projektien tehokasta läpivientiä tarkas- tellaan esittelemällä sovelluskehityksen erilaisia elinkaarimalleja.
Tutkielmassa käsitellään virheiden määritelmiä, virheluokitteluiden kuvauksia, mo- derneja elinkaarimalleja kuten agile- ja DevOps-mallit sekä uusia kehittämisen termejä kuten kehitysputki (pipeline) ja konttikehitys (container). Tutkielmassa käsitellään ly- hyesti myös perinteistä vesiputousmallia. Tutkielma keskittyy käsittelemään pääasi- assa modernien elinkaarimallien sekä kehitysputki ja konttikehitys -termien suhdetta virheluokitteluihin ja selvittämään virheluokitteluiden tarpeellisuutta ja hyödyntämistä näissä elinkaarimalleissa.
Tutkielmassa on käytetty tieteellisiä tietolähteitä, toteutettu tietokantahakuja maini- tuista kehitysmenetelmistä, käsitelty hakutuloksia, tehty yhteenvetoa ja pohdintaa.
Avainsanat: Virheluokittelu, ISO-standardi, DevOps-malli, Agile-malli, Kehitysputki, Konttikehitys, ODC, SAWO, Mikropalvelut
ii
UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, Kuopio School of Computing
Computer Science
Student, Juho Burman: Defect classification exploitation in the development of soft- ware production process
Master’s Thesis, 62 p.
Supervisors of the Master’s Thesis: PhD Virpi Hotti November 2017
Information systems have a very large role and importance for companies in their daily operations. Therefore, interference-free operation of information systems, as well as effective implementation of information system projects are essential to the operation of the company. Effective failures management contributes to these goals.
Defect classification practices are evolving more accurately and more efficiently as time progresses, and they can better manage and analyze detected defects in projects and improve the software development process even better. In addition, the actual de- velopment life cycle models have evolved from the waterfall model to agile models and DevOps models, which are more efficient and less error-generating practices. The life cycle models are developing in a direction where models in themselves reduce defects without the use of actual classifications by increasing automation. An issue to be considered is the importance of defect classifications in modern development mod- els.
In this thesis, defect management is examined by presenting a variety of methods for classification defects. In addition, the thesis describes a simple, efficient, and easy de- veloped model by which the software development process can be improved based on the classification and analysis of defects. Effective implementations of projects are examined by introducing different life cycle models for application development.
The thesis deals with the definitions of defect, descriptions of defect classifications, modern life-cycle models such as agile and DevOps models, as well as the new terms of software development such as development pipeline and container development.
The thesis also briefly discusses the traditional waterfall model. The thesis focuses mainly on modern life cycle models including development pipeline and container de- velopment terms and specially their relationships to the defect classifications and to find out the need for defect classifications in these life cycle models.
In the thesis is used scientific data sources, implemented database searches on these development methods, processed search results, made summaries and reflections.
Keywords: Defect Classification, ISO-Standard, DevOps-model, Agile-model, Devel- opment pipeline, Container development, ODC, SAWO, Microservices
iii
Esipuhe
Tämä tutkielma on tehty Itä-Suomen yliopiston Tietojenkäsittelytieteen laitokselle vuonna 2017.
Parhaat kiitokset ohjaajalleni saamastani ohjauksesta tutkielmani toteuttamisessa.
Haasteena tutkielmassa oli hahmottaa aihe sopivana kokonaisuutena. Saamastani oh- jauksesta tutkielman teossa on ollut suuri apu mm. tutkielman rakenteiden ja lähtei- den käsittelyssä ja niiden saattamisessa viimeisteltyyn muotoonsa.
iv
SISÄLLYSLUETTELO
1 Johdanto ... 5
2 Viat ja niiden luokittelu ... 7
2.1 ISO-standardien määritelmät ... 7
2.2 Virheiden luokittelukäytäntöjä ... 9
2.2.1 Ortogonaalinen virheluokittelu ... 10
2.2.2 Beizerin ja Humphreyn virheluokittelut ... 12
2.2.3 Beizer-Humprey-luokittelukäytäntö ... 13
2.2.4 Useamman tason virheluokittelumalli SAWO ... 15
2.2.5 Muita löytämiäni virheluokitteluita ... 18
2.2.6 Yhteenvetoa luokitteluista ... 20
3 Elinkaarimalliajattelu kehitysajurina ... 21
3.1 Vesiputousmalli ... 22
3.2 Ketterä (agile) kehitys ... 24
3.3 DevOps-malli ... 27
3.4 Kehitysputket ja konttikehitys ... 34
4 Virheluokitusten hyödyntämisen arviointi ... 38
4.1 Agile ja virheluokitteluiden hyödyntäminen ... 38
4.1.1 Agile ja virhehallinnan suhde ... 38
4.1.2 Agile ja ODC-luokittelun suhde ... 40
4.1.3 Agile ja Beizer-luokittelun suhde ... 41
4.1.4 Agile ja muut luokittelut ... 42
4.1.5 Agile ja virheluokitteluiden suhteen yhteenveto ... 42
4.2 DevOps ja virheluokitteluiden hyödyntäminen ... 43
4.2.1 DevOps ja virhehallinnan suhde ... 43
4.2.2 Devops ja ODC-luokittelu suhde ... 44
4.2.3 DevOps ja muut virheluokittelut ... 44
4.2.4 DevOps ja virheluokitteluiden yhteenvetoa ... 44
4.3 Kehitysputkien ja konttikehityksen suhde virheluokitteluun... 45
4.3.1 Kehitysputkien ja konttikehityksen haut ... 45
4.3.2 Kehitysputken ja konttikehityksen yhteenveto ... 46
5 Johtopäätökset ja pohdinta ... 49
Lähdeluettelo ... 53
5
1 Johdanto
Palvelun tai tuotteen, kuten ohjelmistojen ja sovellusten, kehittämiseen on olemassa erilaisia elinkaaria (lifecycles), joissa on erilaisia vaiheita (phases). Määrittely (plan), suunnittelu (specify), toteutus (build tai implement) ja testaus (test) vaiheita täydenne- tään tai korvataan eri sidosryhmien vuorovaikutusta tukevilla vaiheilla: yhteistyö (col- laboration), käyttöönotto (deploy) ja käyttö (run) (Kuva 1).
Kuva 1: Elinkaarimallin vaiheet (mukaillen Lotz 2013 ja IT Knowledge portal 2017)
Ohjelmistokehityselinkaarimalli (Softare Development Lifecycle model, SDLC mo- del) vaikuttaa esimerkiksi testauskäytäntöihin. Kun kansainvälinen testaussertifikaat- teja myöntävä ISTQB eli International Software Testing Qualifications Board1 kysyi vuonna 2015 yli 3000 henkilöltä, mitä ohjelmistokehityselinkaarimallia käytettiin, noin 70 % käytti ketteriä elinkaarimalleja (Scrum, XP eli eXtreme Programming ja Kanban), noin 50 % perättäisiä (sequential) elinkaarimalleja (Waterwall eli vesipu- tousmalli ja V-malli), noin 20 % iteratiivisia elinkaarimalleja (RUP ja Spiral eli spi- raali-malli) ja noin 3 % myös jotain muuta (ISTQB, 20162).
Kun tehdään prosessien kehittämistä, se yleensä alkaa puutteellisuuksien tai vikojen (defects) tunnistamisella, luokittelulla ja analysoinnilla. Seuraavaksi etsitään niin sa- nottuja syy-seuraussuhteista ja pyritään ennaltaehkäisemään vikoja (Kuva 2).
1 http://www.istqb.org/references/surveys/istqb-worldwide-software-testing-practices-report.html
2 ISTQB eli International Software Testing Qualifications Board (2016) ISTQB® Worldwide Software Testing Practices Report 2015 - 2016, https://goo.gl/blSLH8
Määrittely Suunnittelu Toteutus Testaus Käyttöönotto Käyttö
6
Kuva 2: Prosessikehittämisen työnkulku (mukaillen Kumaresh & Baskaran 2010)
Kandidaatin tutkielmassa ”Ohjelmistovirheiden luokittelu prosessin kehittämisen työ- kaluna” käsittelin virheluokitteluiden hyödyntämistä yleisellä tasolla (Burman 2015).
Tässä tutkielmassa keskitytään arvioimaan vika-/virheluokittelujen (Luku 2) merki- tystä, kun tehdään kehitystyötä erilaisten elinkaarimallien mukaisesti kuten vesipu- tousmallilla tai ketterästi ja mahdollisimman automatisoidusti (Luku 3). Tutkimusky- symys, johon annetaan vastauksia (Luku 4), on seuraava: Onko vika-/virheluokitte- luilla merkitystä nykyaikaisessa ohjelmisto-/sovellustuotannossa?
Prosessin kehittämismalli
(Process Improvement Workflow)
7
2 Viat ja niiden luokittelu
Testauksen perustarkoituksia ovat kelpuuttaminen eli validointi ja todentaminen eli verifiointi. ISTQB® testaussanastossa, joka on suomennettu vuonna 2015, kelpuutta- minen ja todentaminen määritellään ISO 9000 -laatustandardin mukaan. Kun mukaan otetaan myös muita ISO-standardeja, voidaan esittää vikoihin liittyvät keskeiset käsit- teet ja niiden määritelmät (Luku 2.1). Vikojen/virheiden luokitteluja on erilaisia ja nii- hin liittyen tehdään luokittelukohtaisia Scopus-hakuja (Luku 2.2). (ISTQB 2012)
2.1 ISO-standardien määritelmät
Koska ISO 9000:n laatustandardista tuli vuonna 2015 päivitetty versio, niin hyödyn- nämme niitä kelpuuttamisen ja todentamisen sekä niissä esiintyvien termien määritte- lemisessä. Kelpuuttaminen eli validointi (validation) on erityistä aiottua käyttöä varten tai sovellukselle (a specific intended use or application) asetettujen vaatimusten täyt- tymisen vahvistamista objektiivisen todistusaineiston avulla. Todentaminen eli verifi- ointi (verification) on eriteltyjen vaatimusten (specified requirements) täyttymisen vahvistamista objektiivisen todistusaineiston avulla. (ISO 2015)
Objekti (object), entiteetti tai kokonaisuus (entity) ja kohde (item) ovat nimityksiä mille tahansa havaittavissa tai ajateltavissa olevalle, johon liittyy tosiasioita eli dataa.
Objektiivinen todistusaineisto (objective evidence) on dataa, joka tukee jonkun ole- massaoloa tai jonkun todentamista. Objektiivista todistusaineistoa saadaan esimerkiksi havainnoimalla, mittaamalla tai testaamalla. Testaus on yhden tai useamman ominais- piirteen ja niiden ominaisarvojen selvittämistä. Ominaispiirteet (characteristics) voivat olla luontaisia tai määriteltyjä, laadullisia tai määrällisiä. Lisäksi ominaispiirteet voi- daan luokitella eri tavoin. Kun puhutaan laatuominaisuudesta tai -ominaispiirteestä (quality chatateristic), niin silloin kyse on vaatimukseen liittyvästä objektin luontai- sesta ominaispiirteestä. Vaatimus (requirement) on todettu tarve tai odotus (need or expectation that is stated), joka on yleisesti oletettu tai pakollinen (generally implied or obligatory). Vika tai puuttellisuus (defect) on aiottuun tai eriteltyyn käyttöön (an
8
intended or specified use) liittyvän vaatimuksen täyttämättä jättämistä (nonconfor- mity)3. Vaatimuksen täyttäminen eli yhdenmukaisuus (conformity) on synonyymi vaa- timustenmukaisuudelle (conformance) ja yhteensopivuudelle (compliance), jotka ovat ISO 9000:2015 mukaan vanhentuneita. (ISO 2015)
SWEBOK (2014) mukaan erilaiset poikkeudet (anomalies4) mielletään olevan puut- teellisuuksia tai vikoja (defects). ISO/IEC 25051:2014 standardissa poikkeus (ano- maly) on poikkeavuutta odotuksista, jotka pohjautuvat esimerkiksi vaatimusten mää- rittelyihin, suunnitteludokumentteihin, standardeihin tai jonkun käsityksiin tai koke- muksiin. Puutteellisuus tai vika on määritelty ISO 9001:2015 standardissa aiottuun tai eriteltyyn käyttöön liittyvän vaatimuksen täyttämättä jättämiseksi. SWEBOK viittaa ISO/IEC/IEEE 24765:2010 standardiin, jossa standardissa vika5 määritellään ongel- maksi, epätäydellisyydeksi tai termiksi, joka viittaa joko virheellisyyteen (fault) tai toimintahäiriöön (failure). Vikojen, virheellisyyksien ja toimintahäiriöiden lisäksi määritellään virhe (error), joka on järjestelmän virheellinen tila6 tai virheellisen tulok- sen tuottava toiminnan lopputulema7. Kun poikkeavuuksia hallinnoidaan, niin yleisesti puhutaan insidenttien eli häiriöiden hallinnasta (incident management) tai vikojen hal- linnasta (defect management).
3 nonconformity (3.6.9 [non-fulfilment of a requirement (3.6.4 [need or expectation that is stated, gen- erally implied or obligatory])]) related to an intended or specified use
4 ISO/IEC 25051:2014(en) Software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Ready to Use Software Product (RUSP) and in- structions for testing, https://www.iso.org/obp/ui#iso:std:iso-iec:25051:ed-2:v1:en:term:4.1.2
5 ISO/IEC/IEEE 24765:2010(en) Systems and software engineering — Vocabulary, https://www.iso.org/obp/ui#iso:std:iso-iec-ieee:24765:ed-1:v1:en:term:3.764
6 ISO/IEC 15026-1:2013(en) Systems and software engineering — Systems and software assurance — Part 1: Concepts and vocabulary, https://www.iso.org/obp/ui#iso:std:iso-iec:15026:-1:ed- 1:v1:en:term:3.4.4
7 ISO/IEC/IEEE 24765:2010(en) Systems and software engineering — Vocabulary, https://www.iso.org/obp/ui#iso:std:iso-iec-ieee:24765:ed-1:v1:en:term:3.1027
9
2.2 Virheiden luokittelukäytäntöjä
Tietojärjestelmiä ylläpitävissä yhtiöissä ylläpidetään virhetietokantaa testausprosessin hallinnan varmistamiseksi ohjelmistotuotantoprosesseissa. Lisäksi virhetietokantaa (virhedataa) hyödynnetään sekä testauksen että tarkastustoimintojen kehittämiseen.
Saadaksemme mahdollisimman suuren ja monipuolisen hyödyn virhedatasta sen pitää olla yksiselitteinen ja luokiteltu (Raninen et al. 2012).
Hyvän luokittelumenetelmän pitää täyttää seuraavat kriteerit. Ensimmäiseksi menetel- män pitää olla yksiselitteinen eli virheiden tyypit on mahdollista luokitella selkeästi sopiviin virheluokkiin, joissa kuvauksen pitää olla selkeä. Toiseksi menetelmää on pystyttävä käyttämään nykyisessä ja tulevissa projekteissa helposti samalla tavalla.
Selkeästi ja yksiselitteisesti omiin virheluokkiinsa luokitellusta virhedatasta on mah- dollista kerätä helposti tietoapäätöksentekoa varten (Raninen et al. 2012).
Luokittelumenetelmiä käytetään, kun halutaan mitata ja kehittää prosessin ja tuoteke- hityksen toimivuutta ja tehokkuutta testauksen hallinnan varmistamisen sekä testaus- ja tarkastustoimintojen kehittämisen lisäksi. Virheiden luokittelumenetelmät helpotta- vat ja tarkentavat tietoa virheistä, niiden jakaumista ja yleisyydestä, joten niitä on hel- pompi analysoida ja tehdä päätöksiä korjaus- ja kehitystoimista. Luokittelumenetel- millä voidaan myös seurata prosessin laadukkuuden parantumista (Raninen et al.
2012).
Kirjallisuudessa on esitelty useita eri virheiden luokittelumenetelmiä, joista muutamia esitetään seuraavissa kappaleissa erikseen. Sen sijaan kirjallisuudesta ei löydy merkit- tävästi arviointeja niiden sopivuudesta ja hyödyllisyydestä virheiden käsittelyssä (Ra- ninen et al. 2012).
Virhedatan luokittelukäytäntöjä on useita, joista tässä tutkielmassa käydään läpi seu- raavat luokittelutekniikat:
− ortogonaalinen virheiden luokittelu eli ODC (Orthogonal Defect Classifi- cation), joka on yleisesti käytetty virheenluokittelutekniikka ja jossa virheet ryhmitellään määriteltyjen tyyppien mukaan. (Taulukko 1)
10
− Beizer ja Humphreyn virheluokittelutekniikat, joissa virheet määritellään eri tyyppien mukaisesti omilla tavoillaan. Beizerin luokittelutekniikassa on yh- deksän eri luokkaa ja Humphreyn luokittelutekniikassa 10 eri luokkaa. (Tau- lukko 2)
− Beizer - Humpreyn luokitteluihin perustuva luokittelukäytäntö. Tässä yhdiste- tyssä luokittelukäytännössä on pohjana käytetty sekä Beizerin että Humpreyn luokitteluja ja muodostettu niistä kattavampi luokittelu (Taulukko 3).
− useamman tason luokittelutekniikkaa SAWO, jossa voidaan hallinnoida ja tar- kastella virheitä tarkemmalla tasolla.
− katsaus muihin löytämiini virheluokittelutekniikoihin (mm. Fagan, El Emam ja IEEE:n standardivirheluokittelutekniikat).
− yhteenveto käsitellyistä virheluokittelutekniikoista yleisellä tasolla.
2.2.1 Ortogonaalinen virheluokittelu
Scopus-hakulauseke TITLE(software OR application) AND TITLE ("Orthogonal Defect Classification" OR ODC) tuotti 16 osumaa, joista valitsin seuraavat artikkelit:
− “Software for Embedded Systems: A Quality Assessment based on improved ODC taxonomy” (Silva & Vieira 2016), koska se havainnollistaa, kuinka ODC:tä voidaan käytännössä hyödyntää prosessin kehittämisessä, artikkelissa kuvataan prosessin käyttöä kokonaisuutena ja kuvaillaan tarkemmin, kuinka ODC luokittelua voidaan kohdistaa prosesseissa eri osa alueisiin.
− “Using ODC to diagnose an Agile enterprise application development project”
(Chillarege 2013): artikkelissa kuvataan luokittelua hyödyllisenä diagnoo- sityökaluna laadun ja tuottavuuden havainnoinnissa käytettäessä esimerkiksi agile-kehittämismallia.
− “Testing techniques selection based on ODC fault types and software metrics”
(Cotroneo et al. 2013): artikkelissa kuvataan testaustekniikkojen toteuttamista hyödyntäen mm. ODC-virheluokituksien määrittelyjä ja luokitteluita.
− “OSDC: Adapting ODC for developing more secure software” (Hunny et al.
2013): artikkelissa kuvataan ODC-luokittelun hyödyntämistä analysoinnissa ja
11
sovelluksien heikkouksien selvittämisessä virhedatan avulla. Virheet voivat synnyttää mm. tietoturvauhkia, joita vastaan voidaan kehittää keinoja näiden korjaamiseksi ja ehkäisemiseksi.
Muita käyttämiäni lähteitä:
− ”Defect Data Analysis as Input for Software Process Improvement” (Raninen et al. 2012), jossa käsitellään prosessin parantamista hyödyntämällä virheiden luokittelua sekä käsitellään Beizer, Humphreyn, El Emam ja ODC luokittelu- käytäntöjä.
− “Defect Analysis and Prevention for Software Process Quality Improvement”
(Kumaresh & Baskaran 2010), jossa käsitellään ohjelmistoprosessin kehittä- mistä hyödyntämällä virheanalyysiä sekä virheiden ennaltaehkäisyä hyödyn- täen virheluokitteluita. Lisäksi artikkelissa käsitellään ODC-virheluokittelu- tekniikkaa.
Alkuperäinen luokiteltu ODC eli ortogonaalinen virheluokittelu (Orthogonal Defect Classification) koostuu viidestä eri virhekategorialuokasta. Virheluokittelut tässä luo- kittelussa ovat vaatimus (requirements), suunnittelu (design error), ohjelmointi/koo- daus (logical error), käyttöliittymä (graphical error) ja dokumentointi (documentation) virheluokat. Virheluokitteluita on toisaalta mahdollista päivittää paremmiksi ja täsmäl- lisemmäksi. Näin on tehty ODC-luokittelusta paranneltu versio (Redefined ODC), joka koostuu kahdeksasta eri kategorialuokasta. Näin virheitä voidaan luokitella ja kä- sitellä tarkemmalla tasolla. Virheluokat parannellussa versiossa ovat algoritmi (algo- rithm), toimeksianto (assigment), paketti/versio/lajittelu (build/package/merge), tar- kistus (checking), dokumentointi (documentation), toiminto (function), liittymä (inter- face) ja ajoitus-/sarjallistamisvirhe (timing/sosialization). (Raninen et al. 2012, Kuma- resh & Baskaran 2010, Burman 2015)
Löytämissäni Scopus-lähteissä käsitellään myös kattavasti virheluokittelujen käyttöä, mihin eri osa-alueisiin voidaan hyödyntää luokitteluja ja miten mukauttaa niitä. ODC- virheluokittelua voidaan mukauttaa ja kohdistaa tarpeiden mukaan selvitettäessä ja rat- kaistaessa tiettyjä virhealueita kuten turvallisuuteen liittyviä virheitä ja riskejä.
12
Taulukossa 1 on esiteltynä virheluokittelumallit perinteinen ODC ja paranneltu ODC.
Taulukosta voidaan havainnoida erot ja tarkkuuksien vaihtelut.
Taulukko 1: Ortogonaalisen virheluokittelun perinteinen ja paranneltu malli (mukaillen Rani- nen et al. 2012)
2.2.2 Beizerin ja Humphreyn virheluokittelut
Scopus-hakulauseke "Beizer" OR "Humphrey" AND TITLE("defect classification")” tuotti 106 osumaa ja hakulauseke "Beizer" AND
"Humphrey" AND TITLE("defect classification")tuotti yhdeksän osumaa. Näistä molemmista hakulausekkeista ei löytynyt suoria tuloksia, joissa olisi käsitelty näitä mainittuja luokitteluita tarkemmin. Molemmissa hakulausekkeissa sen sijaan ainoastaan esiintyi “Identifying Process Problems with the SAWO Functional Defect Classification Scheme” artikkeli (Toroi et al. 2013), jossa käsiteltiin mainittujen virheluokittelujen rakenteita. Muut hakutulokset viittasivat varsinaisiin kirjallisuus- lähteisiin.
Muita käyttämiäni lähteitä:
− “Identifying Process Problems with the SAWO Functional Defect Classifi- cation Scheme” (Toroi et al. 2013), jossa käsitellään monitasoisen SAWO-mal- lin lisäksi Beizer ja Humphrey virheluokitteluiden hyödyntämistä ja yhdistä- mistä.
− ”Defect Data Analysis as Input for Software Process Improvement” (Raninen et al. 2012), jossa käsitellään prosessin parantamista hyödyntämällä virhe- luokitteluita ja käsitellään Beizer, Humphreyn, El Emam ja ODC luokitteluita.
ODC 1. 2. 3. 4.
Paranneltu (Redefined)
Algoritmi (Algorithm)
Toimeksianto (Assigment)
Paketti/versio/lajittelu
(Build/Package/Merge) Tarkistus (Checking) Perinteinen
(Traditional)
Vaatimus (Requirements)
Suunnittelu (Design error)
Ohjelmointi/koodi (Logical Error)
Käyttöliittymä (Graphical Error)
ODC 5. 6. 7. 8.
Paranneltu (Redefined)
Dokumentointi (Documentation)
Toiminto
(Function) Liittymä (Interface) Ajoitus-/sarjallistamis (Timing /Sorialization) Perinteinen
(Traditional)
Dokumentointi (Documentation)
13
Taulukossa 2 on esiteltynä Beizer ja Humphrey virheluokittelumallit, joista voidaan havainnoida eroja luokkien määrissä ja termistöissä.
Taulukko 2: Beizer ja Humphrey virheluokittelumalleista muokattu taulukko (Raninen et. al 2012).
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.
Beizer Tieto (Data)
Ominaisuus ja toiminnollisuus
(Feature and functionality)
Toteutus ja koodaus (Implementation
and coding)
Integrointi (Integration)
Vaatimus (Requirements)
Humphrey Parametri
(Assignment) Versio (Build, package) Tarkistus
(Checking) Tieto (Data) Dokumentointi (Dokumentation)
# 6. 7. 8. 9. 10.
Beizer
Rakenne (Structural
bugs)
Järjestelmä- ja ohjelmistoarkkitehtuuri
(System and Software achitecture)
Testin määrittely ja toteutus (Test definition and execution)
Muut ja määrittelemättömät
(Other and unspecified) Humphrey Ympäristö
(Environment) Toiminto (Function) Liittymä
(Interface) Syntaksi (Syntax) Systeemi (System)
14
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)
15
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
16
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-luokittelukäytäntö luokittelee virheet kolmella tasolla (Kuva 3). Ensimmäinen taso luokittelee virheet yleisellä ta- solla kuten edellä esitetyt virheluokitusmenetelmät. Toisella tasolla 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 virheet 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
17
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 toimintaa 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).
19
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.
EL EMAM Parametri (Assignment)
Versio (Build, package)
Tarkistus
(Checking) Tieto (Data) Dokumentointi (Documentation)
Ympäristö (Environment)
# 7. 8. 9. 10.
EL EMAM Toiminto (Function)
Liittymä (Interface)
Muisti (Memory)
Nimeämiskäytännöt (Naming Conventions)
11.
Ymmärrettävyys (Understandability)
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.
21
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ä harjoituskoe8 ja vastaukset9. FiSTB:n sivustolta löytyy myös ISTQB® Perus- taso -sertifikaattiin liittyvä harjoituskoe10 ja vastaukset11, 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
9http://www.fistb.fi/sites/fistb/files/liitteet/Kettera%20testaaja%20laajennus%20-%20Harjo- ituskoe%20vastaukset.pdf
10http://www.fistb.fi/sites/fistb/files/liitteet/CTFL%20Sam-
ple%20exam%202011%20v%202.6%20k%C3%A4%C3%A4nnetty.pdf
11http://www.fistb.fi/sites/fistb/files/liitteet/CTFL%20Sam-
ple%20exam%202011%20v%202.6%20k%C3%A4%C3%A4nnetty%20perustelut.pdf
22
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)
23
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)
Vaatimuksien määrittely (Requirements)
Analysointi (Analysis)
Suunnittelu (Desing)
Toteutus/
Koodaus (Implementation
/ Coding)
Kaikki testaukset (All testings)
Virheiden korjaus (Fix any issues)
Toimitus (Deployment)
Ylläpito (Maintenance)
24
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 julistus12 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ärjestelyihin, 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
25
− 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 loppuvaiheeseen 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
26
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)
27
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 johtamisen 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
28
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öryhmien 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.
(Virmani 2015, Kröger 2017)
Eri toimijoilla on erilaisia intressejä. Kehityksestä vastaavat ryhmät (development) ha- luavat toimittaa uuden version tuotantoon mahdollisimman nopeasti sen sijaan tuotan-
Suunnittelu (Plan)
Implementointi/
Koodaus (Implementation/
Coding)
Kokoaminen
(Build) Testaus (Test)
Julkaisu (Release) Toimitus (Deploy)
Tuotanto (Operate) Ylläpito (Monitor)
30
nolliset ryhmät (operations) haluavat ennen kaikkea varmistaa sen, että tuotantoympä- ristö on vakaa ja saatavilla. Kokonaisuutena DevOps-kehitys voidaan nähdä koostuvan neljästä vaiheesta (Kuva 8).
Kuva 8: DevOps-kehitys (mukaillen Kröger 2017)
Näihin eri kokonaisuuksiin liittyvät tietyt osa-alue sidonnaiset vaiheet niihin kuuluvine tehtävineen. Merkittävin ero varsinaiseen ketterään malliin on toiminnallisuuksien, muutosten ja korjausten testaaminen ja toimittaminen reaaliaikaisesti (Kim et al.
2013). Ketterässä kehityksessä keskitytään tuotteeseen ja sen kehittämiseen sekä toi- minnollisuuksien lisäämiseen tuotteen kehitysversioon. DevOpsissa keskittyminen kohdistuu enemmän asiakkaisiin ja asiakkaiden haluamien ominaisuuksien nopeaan ja virheettömään toimittamiseen asiakkaiden tuotantoversioon. (Kröger 2017)
DevOpsin keskeinen tavoite on ennen kaikkea selvittää problematiikkaa, kuinka asia- kasta ja eri osapuolia osallistutetaan kehitysprosessin eri vaiheissa. Toisaalta De- vOpsin selkeä tavoite on vapauttaa työntekijät tekemään tuottavampaa työtä ja opti- moida operatiivista toimintaa suhteessa muihin oman organisaation toimijoihin (kehi- tystyö). Käytännössä tällä tavoitellaan uusien kokemuksien, kassavirran ja liiketoimin- tojen luomista. DevOps sisältää jatkuvaa integraatiota, jatkuvaa toimittamista ja tes-
1. Määrittely (Define requirements)
2. Toteutus ja yksikkötestaus (Implementation and unit testing) 3. Integraatio
(Integration) 4. Julkaisun hallinta
(Release management)
DevOps
31
tauksesta automatisointiin fokusoivan mallin, jonka avulla eri osapuolet voivat tavoi- tella selkeää lisäarvoa tuottaessaan uusia palveluita asiakkailleen tai tehostaessaan omaa toimintaansa suhteessa kilpailijoihin. (Kröger 2017)
DevOps-mallin etuja ovat muun muassa jatkuvan asiakaspalautteen saaminen ja hyö- dyntäminen esimerkiksi erottamalla kiinnostavat ja motivoivat asiakaskokemukset, asiakasuskollisuuden parantaminen, kasvavan markkinaosuuden ja nopeamman lisä- arvon saavuttaminen, etulyöntiaseman vahvistuminen kilpailijoihin nähden, markki- noiden hallitseminen tietokonepohjaisilla innovaatioilla, ennustettavuuden lisääntymi- nen, tehokkaampi ja kohdistetumpi resurssien käyttö tuottaviin kohteisiin sekä lopuksi tuotteistaminen eli uudelleenkäytettävyys sovellusten toimittamisessa. (Kröger 2017) Onnistuneeseen DevOps-projektiin vaaditaan eri ryhmien välistä kommunikaatiota huomioiden eri tekijöitä, kuten kulttuuri, sanasto, työvälineet ja ryhmien omat raken- teet. Parhaimmillaan julkaistaan tuloksia tunneittain, kun vastaavasti vesiputousmal- lissa pahimmillaan kerran vuodessa. Tieto-konsernilla on esimerkiksi eri ryhmien neu- vonantajat (mentors) eli asiantuntijat, joiden tehtävänä on opastaa DevOps toteuttami- sessa, tuoda varmuutta sekä varmistaa kommunikaatiota ja vastuita. (Suro 2017, Soli- nor 2017)
DevOpsin ominaisuuksiin kuuluu esimerkiksi jatkuvaa tuottamista ja julkaisua, val- vontaa, jatkuvaa testausta, yhteistyötä ja sopimista huomioiden kulttuureita, automaa- tiota, perusrakenteita, ominaisuuksien vaihtamista, työkalutukea, pieniä muutoksia, jatkuvaa kokeilua ja nopeaa virheistä toipumista. Näiden ominaisuuksien avulla jul- kaisunopeus ja palautenopeus nousevat, mukautumiskyky kehittyy, luotettavuus ja laadukkuus parantuvat, sekä ajallisesti että kustannuksissa säästetään, tuottavuus li- sääntyy, sopiminen ja yhteistyö ylipäänsä kehittyvät ja asiakastyytyväisyys nousee.
Haasteena mainitaan kulttuuri-, rakenne- ja ympäristöerot. Myös erilaisten kustannus- ten lisääntyminen, puutteellinen osaaminen, mahdollinen projektin monimutkaisuus ja turvallisuusuhat ovat haasteita. Mikkosen omat näkemykset haasteista liittyvät muun muassa tekniseen toteutukseen, yksinkertaistamiseen, säädöksiin ja suunnitteluun.
(Mikkonen 2017)
32
DevOps kuvataan uudeksi termiksi, jossa on törmännyt kaksi suurta trendiä (Mueller 2017). Ensimmäisenä trendinä on "ketterä järjestelmän hallinnan" (”agile system ad- mistration”) tai "ketterän toiminnan" käyttö (”agile operation”). Uudempia Agile- ja Lean-lähestymistapoja sovelletaan operatiiviseen työhön. Toisena trendinä on laa- jempi käsitys kehittäjien ja operatiivisen henkilöstön yhteistyön arvosta kaikissa vai- heissa luotaessa ja toteutettaessa palvelua tai tuotetta ja kuinka merkittäväksi palvelu- keskeisyys tuotteissa on tullut. Sivuston artikkelissa mainitaan myös Jez Humblen se- litys mallille ”monitieteellisten käytäntöjen yhteisö omistautuen tutkimaan järjestel- mien rakentamista, kehittymistä ja toimintaa”.
DevOps voidaan Agile Admit-sivuston artikkelin (Mueller 2017) mukaan katsoa myös ylikasvaneeksi malliksi ketterästä mallista eli agile-mallista. Molemmissa malleissa tehdään yhteistyötä muun muassa asiakkaan, tuotehallinnan ja kehittäjien kanssa kai- kissa vaiheissa ja myös käytetään kysymys-, palaute- ja vastausvaiheita täyttämään projektin puutteellisia osia tai muuten kiihdyttämään iteraatio eli toisto vaiheita pa- remmiksi tiedonkeruusta ylläpitoon. DevOps-mallissa voidaan käsitellä tuotetta ja sii- hen liittyviä asioita tarkemmin, nämä voivat olla koodauksen ulkopuolella olevia toi- mintoja kuten palveluja. Ketterä malli eli Agile tyytyisi työstämään tuotetta rajoittuen enimmäkseen koodaukseen. Koska DevOps-malli perustuu ketterään eli agile-malliin, niin arvoiltaan DevOps noudattaa muun muassa ”Agile Manifestiä” ja painottaa kehit- tämis- ja operatiivisten ryhmien yhteistyötä (Hussaini 2014).
DevOps-mallissa ei ole määritelty toistaiseksi kirjallisia periaatteita, mutta DevOps noudattaa agile-mallin periaatteita, joita noudatetaan vaihtelevasti riippuen organisaa- tioista. The agile admin -sivustolla lainataan James Turnbull’n omaa määritelmää, jossa hyödynnetään Agile manifestoa ja periaatteita. Hänen mielestään DevOps on kä- sitteellisellä tasolla ”lähinnä vain Agile-periaatteiden laajentaminen järjestelmien ja toimintojen lisäämiseksi sen sijaan, että se huolehtisi vain koodin tarkastamisesta”.
DevOps-mallissa tehdään samoin kuin agile-mallissa jatkuvaa integraatiota ja käyt- töönottoa esimerkiksi sopimalla ja olemalla yhteydessä säännöllisin väliajoin eri osa- puolten kesken, myös on mahdollista hyödyntää pilvipalveluita, joiden avulla työstä- minen on hyvin nopeaa (Mueller 2017).
33
DevOps-malli voidaan määritellä myös joukoksi keinoja, joiden avulla kehittäjät ja operatiivinen henkilökunta kommunikoivat ja työstävät yhdessä toimitettavaa sovel- lusta tai palvelua nopeasti, luotettavasti ja korkealla laadukkaalla tavalla. Tehtävät ja niiden vastuut jaetaan ryhmien ja yksilöiden kesken kaikissa eri vaiheissa. Ryhmät pyrkivät toteuttamaan päätavoitteita, joita ovat pyrkiä liiketaloudellisesti kannattavaan jatkuvaan ja laadukkaaseen toimintaan, yksinkertaisuuteen ja joustavuuteen kaikissa mahdollisissa asioissa teknologiasta työntekijöihin, ryhmien välisten toimintojen tu- kemiseen, yhteistyöhön ja innovaatioihin sekä dynaamisten rakenteiden hallintaan.
Etuina on tuottavuuden kasvaminen ja laadun parantuminen, mutta tätä mallia toteu- tettaessa haittana voi olla puutteellinen hallintarakenne ja tarvittavan osaaminen puute toteuttamisessa. Tieto omassa organisaatiossaan on ottanut nämä mahdolliset haitat huomioon kouluttamalla ja käyttämällä neuvonantajia eli asiantuntijoita ratkaisemaan kyseisiä ongelmia. (Perera et al. 2017, Suro 2017)
DevOps-malliin liittyen on luotu CAMS-malli, joka koostuu neljästä eri elementistä ja on nimetty elementtien alkukirjainten mukaan. CAMS elementit ovat kulttuuri (”Cul- ture”), automaatio (”Automation”), arviointi (”Measurement”) and jakaminen (”Sha- ring”). Kulttuureista johtuen erot voivat vaihdella esimerkiksi tavoitellussa tuotteen laadussa eri maissa, automatisoinnissa miten ja missä se on mahdollista, prosessien arvioinnissa ja palautteen jakamisessa ilman eri osapuolien syyllistämistä. (Suro 2017, Perera et al. 2017)
CAMS-mallissa kommunikoinnin haastavuuteen vaikuttavat esimerkiksi eri osapuol- ten erot. Tarkemmin syyt yhteistyön ja kommunikoinnin haastavuuteen voivat johtua muun muassa tavoista, menetelmistä, työvälineistä, osaamisesta ja tavoitteista.
DevOps-mallissa on kehitetty eri keinoja auttaa organisaatioita huomioimaan eri teki- jöitä sekä selvittämään ja ratkaisemaan haasteita systemaattisesti, kuten SNACTM si- dosryhmäanalyysi, jota Hussaini 2014 artikkelissa kuvaillaan. SNACTM-menetelmän lyhenne tulee selitteen sanojenkorostuksesta ”Stakeholders, their Needs, the system factors, which can be Altered and Constraints, which come in the way of fulfilling the needs” eli käännettynä ”Sidosryhmät, näiden tarpeet, järjestelmätekijät, joita voidaan muuttaa ja rajoittaa, joilla pyritään tietyillä tavoilla tyydyttämään tarpeita” lainattuna
