Kehittämistutkimus: Informatiivinen kysely vihreän ohjelmointiosaamisen tukemiseksi

Jenni Yrjänä Kehittämistutkimus: Informatiivinen kysely vihreän ohjelmointiosaamisen tukemiseksi Tietotekniikan pro gradu -tutkielma 14. toukokuuta 2024 Jyväskylän yliopisto Informaatioteknologian tiedekunta Kokkolan yliopistokeskus Chydenius Tekijä: Jenni Yrjänä Yhteystiedot: jenni.a.yrjana@jyu.fi Puhelinnumero: 040-864 9772 Ohjaaja: Lasse Harjumaa Työn nimi: Kehittämistutkimus: Informatiivinen kysely vihreän ohjelmointiosaamisen tukemiseksi Title in English: Design Science Research: An informative survey to support green software development Työ: Tietotekniikan pro gradu -tutkielma Sivumäärä: 111+12 Tiivistelmä: Vihreästä ohjelmoinnista on tullut tärkeä osa ohjelmointiosaamista. On kuitenkin tärkeää, että ohjelmistokehittäjät tuntevat vihreän ohjelmoinnin käytänteitä ja osaavat hyödyntää niitä ohjelmistotuotannossa. Tässä työssä tehtiin tutkittuun tietoon perustuva vihreää ohjelmistokehitysprosessia ja ohjelmointia koskeva informatiivinen sähköinen kysely. Tutkielma toteutettiin yhteistyössä suomalaisen ICT-ratkaisuja ja -palveluja eri toimialoille toimittavalle ohjelmistoyhtiö Digia Oyj:n kanssa. Tutkimusmenetelmänä käytettiin Design Science Research Methodology - prosessia. Tutkimuksen empiirisessä osassa hyödynnettiin teemahaastattelua. Tutkimuksen tuloksena syntyneellä artefaktilla pyritään edistämään ohjelmistokehitykseen osallistuvien työntekijöiden vihreää ohjelmistokehitysprosessia ja ohjelmointia koskevaa tietämystä. Luotu artefakti edistää työntekijöiden tietotaitoja vihreästä ohjelmoinnista kysymysten ja välittömän informatiivisen palautteen avulla. Kyselyn lopussa annetaan palaute kyselyn tuloksista sekä ohjataan kyselyyn vastaaja hakemaan tarvittaessa lisäinformaatiota aiheeseen liittyviltä nettisivuilta. Haastateltavat pitivät kyselyä tehokkaana ja hyvänä tapana lisätä ohjelmistokehittäjien tietämystä vihreistä ohjelmointikäytänteistä. Kyselyllä pystyttiin lisäämään ohjelmistokehittäjien tietämystä vihreistä ohjelmointikäytänteistä. Avainsanat: Vihreä IT, vihreä ohjelmistokehitys, kehittämistutkimus, informatiivinen kysely Abstract: Green programming has become an important part of programming skills. However, it is important that software developers know the practices of green programming and know how to use them in software production. In this work, an informative electronic survey about the green software development process and programming based on researched information was made. The study was carried out in cooperation with the Finnish software company Digia Oyj, which supplies ICT solutions and services to various industries. The Design Science Research Methodology process was used as a research method. Furthermore, in the empirical part of the study, a theme interview was utilized. The artifact, which was created as a result of the research, aims to promote the green software development process and programming knowledge of the employees involved in software development. The created artifact promotes employees knowledge of green programming through questions and immediate informative feedback. At the end of the survey, feedback is given on the results of the survey and the survey respondent is directed to search for additional information on the related websites if necessary. The interviewees considered the survey to be an effective and good way to increase software developers knowledge of green programming practices. The survey was able to increase software developers knowledge of green programming practices. Keywords: Green IT, Green software development, Design Science Research, Informative survey Copyright © 2024 Jenni Yrjänä All rights reserved. ii Sanasto Black-box testing Musta laatikko -testaus Bulk Operation Massaoperaatio DRAM Dynamic Random Access Memory FaaS Function-as-a-Service FASTA DNA and protein sequence alignment software package I/O Input/Output IoT Internet of Things, Esineiden Internet Lazy Initialization Laiska initialisointi Peak Memory Huippumuisti PUE Power Usage Effectiveness, Virrankäytön tehokkuus TDD Test-Driven Developing, Testilähtöinen kehittäminen TDRE Test-driven requirements engineering, Testilähtöinen vaatimusmäärittely White-box testing Valkoinen laatikko -testaus i Sisällys Sanasto i 1 Johdanto 1 2 Tutkimuksen toteuttaminen 4 2.1 Tutkimuksen tarkoitus, tavoitteet ja tutkimuskysymykset . . . . . . . 4 2.2 Tutkimusmenetelmän valinta . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Kehittämistutkimus tutkimusmenetelmänä . . . . . . . . . . . . . . . 6 2.4 Aineistonkeruu teemahaastattelulla . . . . . . . . . . . . . . . . . . . 9 2.5 Tutkimuksen luotettavuus . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6 Tutkimuskohde ja haastateltavat . . . . . . . . . . . . . . . . . . . . . 12 3 Kestävän kehityksen mukainen ohjelmisto 15 3.1 Vihreiden käytänteiden implementointi käytäntöön . . . . . . . . . . 16 3.2 Vihreä ohjelmistokehitysprosessi . . . . . . . . . . . . . . . . . . . . . 17 3.2.1 Vihreän ohjelmistokehitysprosessin menestystekijöitä ja käytänteitä................................ 17 3.2.2 Ohjelmistokehitysprosessin vihreyden mittaaminen ja raportointi................................. 20 3.3 Vihreän ohjelmiston elinkaarimalli . . . . . . . . . . . . . . . . . . . . 22 3.3.1 Vaatimusmäärittely . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.2 Suunnittelu ............................. 23 3.3.3 Toteutus............................... 24 3.3.4 Testaus................................ 24 3.3.5 Ylläpito ............................... 25 3.4 Vihreäohjelmisto .............................. 26 3.4.1 Ohjelmiston vihreyden mittaaminen . . . . . . . . . . . . . . . 26 3.4.2 Laitteisto............................... 28 3.4.3 Säästävät ohjelmistostrategiat . . . . . . . . . . . . . . . . . . . 29 3.4.4 Algoritmit.............................. 30 3.4.5 Pilvipalvelut ja reunalaskenta . . . . . . . . . . . . . . . . . . . 31 ii 3.4.6 Ohjelmointikieli . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.4.7 Datan ja muistin käyttö . . . . . . . . . . . . . . . . . . . . . . 33 3.4.8 Sähköinenjäte............................ 35 4 Kyselyn rakentamisesta 37 5 Ensimmäinen iteraatio 39 5.1 Ensimmäisen iteraation kulku . . . . . . . . . . . . . . . . . . . . . . . 39 5.2 Ensimmäisen teemahaastattelun runko . . . . . . . . . . . . . . . . . 40 5.3 Ensimmäisen iteraation haastattelujen tulokset . . . . . . . . . . . . . 42 5.3.1 Kyselyn informatiivisuus ja hyödyllisyys . . . . . . . . . . . . 42 5.3.2 Kyselyn aihealueet . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3.3 Kyselyn kysymykset . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3.4 Kyselynulkoasu .......................... 48 5.3.5 Kyselyn kieliasu ja termistö . . . . . . . . . . . . . . . . . . . . 51 5.3.6 Sähköinen kysely . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.3.7 Vihreyden toteutuminen organisaatiossa . . . . . . . . . . . . 52 5.4 Ensimmäisen iteraation kehittämistuotos . . . . . . . . . . . . . . . . 53 6 Toinen iteraatio 74 6.1 Toisen iteraation kulku . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.2 Toisen haastattelun teemahaastattelun runko . . . . . . . . . . . . . . 77 6.3 Toisen iteraation haastattelujen tulokset . . . . . . . . . . . . . . . . . 78 6.3.1 Haastateltavien yleinen mielipide kyselystä . . . . . . . . . . 78 6.3.2 Kyselyn kysymykset . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3.3 Kysymysten kysymyksenasettelu ja vastausvaihtoehdot . . . 81 6.3.4 Kyselynulkoasu .......................... 82 6.3.5 Kyselynpituus ........................... 83 6.3.6 Kyselyn informatiiviset osuudet . . . . . . . . . . . . . . . . . 83 6.4 Toisen iteraation kehittämistuotos . . . . . . . . . . . . . . . . . . . . 85 7 Tulokset 96 8 Pohdinta 98 9 Yhteenveto 103 Lähteet 105 iii Liitteet A Saatekirje haastateltaville 112 B Vihreän ohjelmoinnin osaamisen kartoittamisen kysely 1.0 113 iv 1 Johdanto Viime vuosikymmeninä tietotekniikan määrä on kasvanut huomattavasti. Sitä mukaa, kun laitteiden ja ohjelmistojen määrä kasvaa, myös niiden tarvitsema energia kasvaa huomattavasti. [61] Mitä enemmän tietotekniikkaa ja ohjelmistoja käytetään, sitä suuremman hiilijalanjäljen ne jättävät. Jokainen koodirivi, joka kirjoitetaan tänään, voi olla käynnissä vielä vuosien päästä valtavassa määrässä prosessoreita. Sen takia ohjelmistokehittäjien tulisi kiinnittää erityistä huomiota hyviin vihreisiin käytänteisiin, joilla voidaan pienentää ohjelmistokehitysprosessin sekä itse ohjelmistoon liittyvää hiilijalanjälkeä. Vihreän IT:n tarkoituksena on erityisesti vaikuttaa ilmastonmuutoksen hillitsemiseen, mutta tämän tutkielman kirjoittamisen ajankohdalle sattuvan energiakriisin aikana, aihe on vielä enemmän käsinkosketeltava kuin aikaisemmin. Ohjelmistokehittäjille on tarjolla paljon yksityiskohtaisia ohjelmistotekniikoita vihreän ohjelmiston rakentamiseksi. Näitä tekniikoita hyödyntämällä voidaan pienentää ohjelmistokehitysprosessin ja ohjelmiston energiankulutusta ja hiilidioksidipäästöjä. Näihin tavoitteisiin pääseminen kuitenkin vaatii ohjelmistokehittäjien olevan tietoisia ohjelmistokehitysprosessin ja ohjelmiston energiankulutukseen ja hiilidioksidipäästöihin vaikuttavista asioista. Heillä täytyy olla myös osaamista tehdä näistä vähemmän energiaa kuluttavia, vähemmän hiilidioksidipäästöjä tuottavia ja siten vihreämpiä. Työnantajilla onkin haasteena varmistaa työntekijöidensä vihreä ohjelmointiosaaminen. Kuluttajat ja sijoittajat haluavat tuotteiden sekä yritysten olevan ekologisesti yhä kestävämpiä. Hiilijalanjäljen pienentämiseksi on kehitetty uusiutuvia energianlähteitä, mutta se ei ratkaise varsinaista ongelmaa, joka on liiallinen energian käyttäminen. Siksi tarvitaan vihreitä ohjelmistoratkaisuja, jotka vähentävät energiankulutusta itsessään. Yrityksille tämä tarkoittaa sitä, että toimintatapojen ja tuotteiden tulee olla ekologisia ja kestävän kehityksen mukaisia. Vihreiden arvojen näkymisen koetaan vaikuttavan positiivisesti yritykseen niin työyhteisön sisällä kuin yrityksen kilpailukykyynkin [11]. Ahmad et al. [6] tutkimustuloksista käy myös ilmi, että kaikki yritykset eivät ole adaptoineet vihreitä käytänteitä ohjelmistokehitysprosessiin. Ohjelmistokehittäjät välittävät ohjelmiston energiankulutuksesta, mutta ei- 1 vät onnistu sen vähentämisessä parhaalla mahdollisella tavalla, koska heidän tietämyksensä aiheesta on puutteellinen. He myös uskovat voivansa oppia parantamaan ohjelmiston energiatehokkuutta ohjelmistokehityksen eri vaiheissa. [36] Ohjelmiston vihreys täytyy ottaa huomioon kaikissa ohjelmistokehitykseen liittyvissä vaiheissa. Energiatehokkuus voidaan ajatella koskevan jokaista ohjelmistokehitysprojektin vaihetta aina suunnittelusta testaukseen, koodaukseen, käyttöönottoon, käyttöön sekä käytöstä luopumiseen. Ohjelmistosta voidaan tehdä vihreämpi pitämällä itse kehitysprojekti vihreänä, mutta myös huolehtimalla itse tuotteen kestävyydestä. Kehitysprosessin monimutkaisuuden takia kehittäjät tarvitsevat sekä selkeitä vihreitä ohjelmistokehitysprosessin malleja että käytännön ohjeita siitä miten ympäristöystävällisen ohjelmiston rakentaminen on mahdollista. Tutkimuksen päätavoitteena on kehittää informatiivinen kysely, jolla voidaan arvioida ja lisätä ohjelmistokehittäjien tietämystä vihreän ohjelmistokehitysprosessin ja vihreän ohjelmiston käytänteiden suhteen. Tavoitteena on myös lisätä tietämystä vihreästä ohjelmoinnista ja vaikuttaa positiivisesti ohjelmistokehittäjien suhtautumiseen vihreää ohjelmistokehitystä kohtaan. Samalla tavoitteena on kartoittaa tutkimukseen osallistuvien mielipiteitä siitä, onko kysely tehokas metodi kartoittaa ja lisätä ohjelmistokehittäjien vihreää ohjelmointiosaamista ja motivoiko kysely implementoimaan vihreitä ohjelmointikäytänteitä käytännön työhön. Tutkimus toteutetaan kehittämistutkimuksena Digia Oyj:n asiakasprojekteja toteuttavassa organisaatioyksikössä. Tutkimuksen tutkimuskysymykset ovat seuraavat: 1. Mitkä ovat keskeisimmät vihreän ohjelmistokehityksen käytänteet? 2. Millaisella informatiivisella kyselyllä voidaan edistää vihreiden ohjelmistokehitykseen liittyvien käytänteiden tietämystä? 3. Miten vihreän ohjelmoinnin käytänteet toteutuvat organisaatiossa? Kehittämistutkimuksen empiirinen osa toteutetaan teemahaastattelujen avulla ja näitä tuloksia hyödynnetään kehitettäessä informatiivista kyselyä. Tuloksena kehitetään Digia Oyj:lle iteratiivisesti sähköinen informatiivinen kysely. Tämän kyselyn aiheet ovat valikoituneet kirjallisuuskatsauksen perusteella, johon on kerätty keskeisimpiä vihreään ohjelmointiin liittyviä käytänteitä. Haastattelujen tuloksissa selvitetään myös vihreiden käytänteiden toteutumista organisaatiossa. Luvussa kaksi kerrotaan tutkimuksen toteuttamisesta. Luvussa kolme kerrotaan kestävän kehityksen mukaisesta ohjelmistosta ohjelmistokehitysprosessin, ohjelmis- 2 2.4 Aineistonkeruu teemahaastattelulla Tässä tutkielmassa aineisto kerättiin teemahaastattelun avulla. Teemahaastattelu on puolistrukturoitu haastattelu, jossa käytetään haastattelurunkoa tarkkojen kysymysten sijaan. Haastattelurunko koostuu teemoista ja tarkkoja kysymysmuotoja ei määritellä. Haastattelu voi myös edetä joustavasti ja sen ei tarvitse noudattaa ennalta määrättyä järjestystä. Teemojen ansiosta tiedonantajat voivat kertoa aiheesta omin sanoin ja he voivat tuoda esille myös sellaisia näkökulmia, joita tutkielman kirjoittaja ei ehkä ole osannut ajatella. Tällä tavalla voidaan myös vähentää tutkijan omien ennakko-odotusten vaikutusta tutkimustuloksiin. Vihreä ohjelmointi on laaja aihealue, joten on odotettavaa, että tutkimuksen aihe tuottaa vastauksia tutkimuksen kohteena olevan kyselylomakkeen aihealueiden ulkopuolelta. Teemahaastattelun aikana tutkijalla on mahdollisuus syventää saatuja tietoja tai selventää saatuja vastauksia. Näiden asioiden takia teemahaastattelun valinta on perusteltua. [22, s. 47–49] [23, s. 204–205, 208] Haastattelut toteutettiin Microsoft Teams -sovelluksen avulla. Tällä ohjelmistolla voidaan sopia ja toteuttaa etätapaamisia ja tapaamiset voidaan myös nauhoittaa mp4-tallenteiksi. Nauhoitteet tallentuivat automaattisesti Jyväskylän yliopiston pilvipalvelimelle. Haastattelujen apuna käytettiin haastattelurunkoja 5.2 ja 6.2. Haastateltavien työkokemus ja asema työyhteisössä olivat erilaisia ja haastatteluja pyrittiin syventämään haastateltavien erikoisosaamisen perusteella. Ensimmäiset haastattelut olivat kestoltaan noin 45–75 minuuttia. Seuraavat haastattelut olivat lyhyempiä, noin 10–25 minuuttia. Aineiston analysointi suoritettiin induktiivisella sisällönanalyysimenetelmällä, joka on perinteinen laadullisen tutkimuksen analysointimenetelmä. Sisällönanalyysin vahvuutena on se, että sillä voidaan tavoittaa merkityksiä, seurauksia ja sisältöjä sekä kuvata ilmiöiden välisiä suhteita. Sisällönanalyysi haastaa tutkijan prosessoimaan tuloksia aktiivisesti. [58, s. 91] Aineisto litteroitiin Microsoft Word -tekstinkäsittelyohjelman litterointityökalua hyödyntäen ja tämän jälkeen puhtaaksikirjoitettiin poistamalla täytesanoja, toistoja sekä tutkimukselle merkityksettömiä lauseita. Litteroimisen jälkeen aineistoon tutustuttiin syvällisemmän kokonaiskuvan saamiseksi. Seuraavana vaiheena päätettiin aineistossa olevat kiinnostavat asiat, kerättiin yhteen ja siirrettiin erilleen muusta aineistosta jatkokäsittelyä varten. Viimeisenä vaiheena aineisto teemoitettiin, jolloin aineisto pilkottiin ja ryhmiteltiin aihepiirin mukaisesti. [58, s. 92–93] Sisällönanalyysi sopi tähän tutkimukseen, koska tarkoituksena oli kuvata aineis- 9 ton sisältöä sanallisesti sekä saamaan ilmiöstä kuvaus tiivistetyssä muodossa. Sisällönanalyysillä pystyttiin järjestämään saatu aineisto tiiviiseen ja selkeään muotoon. Näin aineistosta pystyttiin luomaan selkeää ja yhtenäistä informaatiota, jotta tutkittavasta ilmiöstä voitiin tehdä selkeitä ja luotettavia johtopäätöksiä. [58, s. 103] Kuvassa 2.2 esitetään esimerkki suoritetusta sisällönanalyysistä. Sisällönanalyysi on saatavissa pyydettäessä kokonaisuudessaan. Kuva 2.2: Esimerkki sisällönanalyysistä. 2.5 Tutkimuksen luotettavuus Koska kehittämistutkimus ei ole oma tutkimusmenetelmänsä, luotettavuutta tulee arvioida niiden menetelmien luotettavuuskriteereillä, joita on käytetty tutkimusta tehtäessä. Perinteisesti tieteellisten tutkimusten luotettavuutta on arvioitu validiteetin sekä reliabiliteetin avulla. Nämä käsitteet ovat kuitenkin peritty määrällisen 10 tutkimuksen puolelta, ja niitä ei voi sellaisenaan soveltaa laadulliseen tutkimukseen. Tavallinen tapa tarkastella laadullisen tutkimuksen luotettavuutta on soveltaa Lincolnin ja Guban kehittämää luokittelua [33]. Tämä luokittelu koostuu neljästä luokasta: uskottavuus, siirrettävyys, luotettavuus sekä vahvistettavuus. Näistä luokitteluista on useita erilaisia suomennoksia sekä tulkintoja. [58, s. 138–139] [23, s. 231–233] [26, s. 172] Kehittämistutkimuksen luotettavuutta tulisi kuitenkin arvioida myös kehittämistutkimuksen ominaispiirteiden näkökulmasta. Kehittämistutkimuksen luonteeseen kuuluu vaiheittainen tuotekehitys, joten on perusteltua arvioida tutkimuksen luotettavuutta prosessivaliditeetin näkökulmasta. Prosessivaliditeettia arvioidessa otetaan huomioon erityisesti tutkimusprosessin hallinta ja johdonmukaisuus. Pohdittavia asioita ovat esimerkiksi se, onko tutkimusta teoreettisia ja käytännöllisiä lähtökohtia kehitetty iteratiivisesti, onko kehittämistyön tuloksia hyödynnetty seuraavassa vaiheessa ja onko kehittämistutkimuksen iteratiivinen luonne huomioitu raportoinnissa. Tässä arvioidaan tutkimukseen osallistuvien yhteistyötä ja pohdittavia asioita ovat tutkimukseen osallistuneiden asiantuntijuusalueiden moninaisuus ja onko raportissa kuvattu osallisten yhteistyötä. [60, s. 243–248] Tämä tarkoittaa siis kehittämistutkimuksessa hyvää tutkimusprosessin vaiheiden ja tulosten dokumentaatiota. Dokumentaatiolla voidaan todentaa se mitä on tehty ja miten toimittu. Aineiston tuottamisen olosuhteista kerrotaan selkeästi ja totuudenmukaisesti. Tämä tarkoittaa esimerkiksi sitä, että kerrotaan haastatteluihin käytetystä ajasta, häiriötekijöistä, mahdollisista virhetulkinnoista ja tutkijan oma itsearviointi tilanteesta. [23, s. 232] Kehittämistutkimuksen toisena tarkoituksena itse tuotteen kehittämisen lisäksi on teoreettisten näkökulmien jäsentely, joten luotettavuutta on tarkoituksenmukaista tarkastella erityisesti yleistettävyyden näkökulmasta. Yleistettävyyttä arvioidaan analyyttiseltä kannalta eli arvioidaan, tuotetaanko tutkimuksen tuotteesta tai aihepiiristä käsitteellistä tai teoreettista tietoa, jota voitaisiin soveltaa muissa yhteyksissä. Toisena näkökulmana pohditaan sitä, onko tutkielmassa kuvattu kehittämisen kohteena ollutta kontekstia riittävästi, että tuotetta voitaisiin hyödyntää muissa kehittämisympäristöissä. [60, s. 246–248] Tämän tutkimuksen tarkoituksena on myös selvittää, voidaanko informatiivisella kyselyllä edistää tietämystä vihreän ohjelmoinnin suhteen ja motivoida ohjelmistokehittäjiä sisällyttämään asiaan liittyviä käytäntöjä käytännön työhön. Tällöin tutkimuksen luotettavuutta pitäisi arvioida myös käytännöllisen validiteetin näkökul- 11 masta. Tällöin tulisi arvioida sitä, onko tuote relevantti käytännöllisesti katsottuna. Tulisi myös arvioida, toimiiko tuote autenttisissa tilanteissa, saadaanko käytännössä hyödynnettäviä tuloksia ja tuotetaanko tutkimuksella kestäviä vaikutuksia. [60, s. 245–246] Pernaa [48] kirjoittaa väitöskirjassaan, että tutkimuksen luotettavuutta voidaan arvioida vertaamalla Design-Based Research Collectiven [10] kriteereitä yhdessä Lincolnin ja Guban [33] määritelmiin tutkimuksen luotettavuudesta (suora lainaus Pernaa [48, s. 13–14] [10].): • "Kehittämisen tulee olla kokonaisvaltaista, jolloin kehittämistuloksena saadaan sekä ohjaavia malleja ja teorioita että kuvailevia teorioita (uskottavuus ja siirrettävyys)" • "Kehittämisen tulee edetä sykleittäin ja sisältää jatkuvaa kehittämistä ja arviointia (uskottavuus, luotettavuus ja vahvistettavuus)" • "Kehittämisessä tulee pyrkiä teorioihin, jotka ovat siirrettävissä kentälle opettajien tai muiden opetusalan ammattilaisten käyttöön (siirrettävyys)" • "Kehittämisprosessiin tulee sisältyä testaamista autenttisissa olosuhteissa (siirrettävyys, luotettavuus ja vahvistettavuus)" • "Kehittämistutkimuksen kaikki syklit tulee dokumentoida tarkasti (luotettavuus ja vahvistettavuus)" Kehittämistutkimuksen heikkoutena on se, että kvalitatiivisena tutkimuksena toteutettuna se toteutetaan usein pienellä otoskoolla ja se ei siten anna kattavaa kuvaa tutkittavasta perusjoukosta. Toisaalta kehittämistutkimuksen vahvuutena ajatellaan olevan tutkimustulosten yleistettävyys ja sen kyky selittää ilmiöitä sekä käytännöllisyys. Kehittämistuotokset ovat pragmaattisesta näkökulmasta katseltuna toimivia ja hyödyllisiä. [58, s. 135] [15] Luotettavan kehittämistutkimuksen edellytyksenä voidaan ajatella olevan toimivien ratkaisujen tuottaminen paikallisesti ja näiden ratkaisujen siirtäminen yleisempään käyttöön vasta tämän ensimmäisen vaiheen jälkeen. [7] Validointimetodi sekä konteksti tulisi reflektoida sidosryhmien näkökulmia ja kontekstia. [17] 2.6 Tutkimuskohde ja haastateltavat Tutkimuksen kohdeyritys on ohjelmisto- ja palveluyritys Digia Oyj. Digia Oy perustettiin vuonna 1997 ja vuonna 2005 Digia Oy yhdistyi SysOpen Oyj:n kanssa. 12 Yhdistymisen jälkeen yrityksen nimeksi muodostui SysOpen Digia Oyj. SysOpen Digia Oyj:n nimi muutettiin Digia Oyj:ksi vuonna 2008 ja vuonna 2012 Digia osti Nokialta Qt-liiketoiminnan. Vuonna 2016 yrityksen toiminta jakautui siten, että Qt-liiketoiminta eriytettiin uudeksi yhtiöksi, jonka nimeksi tuli Qt Group Oyj. Tämän yhteydessä Digia uudisti strategiansa ja on jatkanut uudistuksia myös tämän jälkeen ja liikevaihto on kasvanut tämän jälkeen tasaisesti. Digian toimialana on tarjota tietotekniikkaan, liikkeenjohtoon, atk-tarkastuksiin, sisäisiin tarkastuksiin ja riskienhallintaan liittyvää konsultointia, koulutusta ja palveluja. Digia myy alaan kuuluvaa kirjallisuutta, ohjelmistoja ja laitteita sekä harjoittaa muuta näihin liittyvää liiketoimintaa. Lisäksi Digia harjoittaa markkinointi- , myynti- ja hallintopalvelua. Se voi omistaa erilaisia arvopapereita, kiinteistöjä ja kulkuneuvoja, käydä niillä kauppaa ja vuokrata niitä. Digian omistaa osakkeenomistajat. Digian toiminnasta vastaa hallitus, valiokunnat sekä johtokunta. Digian henkilöstön määrä vuoden 2022 joulukuun lopussa oli 1426 ja liikevaihto vuonna 2022 oli 170,8 miljoonaa euroa. Markkinastrategiassaan Digia panostaa digitalisaatioon liiketoiminnan saralla. Toimintaympäristöjen muuttuminen monimutkaisimmiksi luo tarpeen älykkään liiketoiminnan kehittämiselle sekä datan tehokkaammalle hyödyntämiselle. Automaation ja datan merkitys lisääntyy ja tekoälyn hyödyntäminen tulee olemaan yhä isommassa asemassa ja näkyy sovelluksissa sekä liiketoimintaprosesseissa. Sovellus- ja IT-järjestelmät laajenevat pistemäisistä kokonaisuuksista suuremmiksi. Digia pyrkii tarjoamaan asiakkaalle sopivia toimintamalleja ja laajoja ratkaisukokonaisuuksia erikoistuneiden palvelualueiden yksilöllisiin tarpeisiin ja huolehtii samalla ratkaisujen turvallisuudesta sekä kestävyydestä. Digian yhteyshenkilö auttoi haastateltavien kutsumisessa haastatteluun. Haastateltavat ovat valikoituneet Digian sisäisestä projektiryhmästä. Haastateltavien työkokemus vaihteli neljästä vuodesta kahteenkymmeneenviiteen vuoteen ja heidän työnkuvansa vaihteli ohjelmistokehittäjästä projektipäällikköön sekä arkkitehdin tehtäviin saakka. Osalla haastateltavista ei ollut kokemusta ohjelmoinnista ollenkaan. Kaikille paitsi yhdelle ohjelmointiin ja ohjelmistokehitysprosessiin liittyvät käytänteet olivat tuttuja. Haastateltavien suhtautuminen vihreyteen arvona vaihteli. Osa haastateltavista piti vihreyttä arvona tärkeänä, ja he pyrkivät henkilökohtaisessa elämässä toteuttamaan ekologisia toimintatapoja. Osa haastateltavista piti vihreyttä keskimääräisen tärkeänä tai ei juurikaan tärkeänä. Vihreyden tärkeys arvona katsottiin kuitenkin nousseen viimeisen kymmenen vuoden aikana. 13 Osa haastateltavista suhtautui vihreyden toteuttamiseen pragmaattisesti ja tärkeänä motivaationa vihreyden toteuttamiseen koettiin kustannussyyt. Haastateltavat katsoivat, että epäekologiset toimintatavat johtuivat usein tottumuksesta ja tiedon puutteesta. Vihreyden arvojen tärkeys maailman mittakaavassa ymmärrettiin. Osa haastateltavista oli sitä mieltä, että haluaisi lisätä vihreitä toimintatapoja omassa työssään ja vihreyden yhdistäminen työhön tuntuisi luontevalta. Kaikki haastateltavat kokivat vihreän ohjelmointiosaamisensa huonoksi tai kokivat tarvitsevansa lisää tietoa vihreästä ohjelmointiosaamisesta. 14 3 Kestävän kehityksen mukainen ohjelmisto Vihreän ohjelmistokehityksen onnistumisen kannalta ohjelmoijan tulisi tietää minkälainen hyvä vihreä ohjelmisto on sekä miten voidaan varmistua ja arvioida ohjelmiston laadukkuutta vihreästä näkökulmasta [56]. Vihreän ohjelmiston voidaan ajatella olevan sellainen, jonka suorat ja välilliset kielteiset vaikutukset talouteen, yhteiskuntaan, ihmisiin ja ympäristöön sen kehittämisen, käyttöönoton ja käytön seurauksena ovat mahdollisimman vähäiset tai sillä on myönteinen vaikutus kestävään kehitykseen [13]. Ohjelmiston tarkoituksesta riippuen se voi itsessään olla vihreä (Green In It) ja vihreästi tuotettu. Toisaalta ohjelmiston voidaan ajatella edistävän vihreyttä (Green By It) tai lisäävän tietoutta vihreistä toimintatavoista. [40] Microsoft on määritellyt kahdeksan ja Green Software Foundation kuusi vihreän ohjelmiston kehittämisen periaatetta. Periaatteet korostavat hiili- ja energiatehokkuutta ja ovat näiltä osin samanlaiset. Alla olevassa listassa on mukaillen yhdistettynä nämä periaatteet. Hiilitehokkuus Rakenna hiilitehokkaita sovelluksia. Energiatehokkuus Rakenna energiatehokkaita sovelluksia. Hiilitietoisuus Käytä sähköä pienimmällä hiili-intensiteetillä. Laitteistotehokkuus Rakenna sovelluksia, jotka käyttävät laitteistoa mahdollisimman tehokkaasti. Laitteiston energiatehokkuus Maksimoi laitteiston energiatehokkuus. Verkkotehokkuus Vähennä datan määrää ja sen kulkemaa matkaa Mittaus Mittaa sovelluksen toimintaa. Optimointi Lisää yleistä hiilitehokkuutta optimoinnin avulla. Ilmastositoumukset Ymmärrä hiilidioksidin vähentämisen merkitys ja mekanismi. 15 Vihreät laatutekijät määrittelevät, mitä vaatimuksia ohjelmiston on täytettävä ollakseen vihreä, ja mittareilla on tarkoitus mallintaa mitatun ohjelman laatutekijöitä sekä antaa tietoa ohjelmasta. Ensimmäisenä vaatimuksena on, että ohjelmiston suunnittelu-, ohjelmointi, ylläpitosekä hävittämisprosessi tulee säästää resursse- ja ja vähentää jätettä. Toisena vaatimuksena ohjelmiston ajaminen tulee säästää resursseja ja tuottaa vähän jätettä. Kolmanneksi ohjelmiston tulee tukea kestävää kehitystä. Näistä vaatimuksista voidaan johtaa kolme vihreää laatutekijää, joita ovat sovellettavuus, suorituskyky sekä kestävyys. Sovellettavuus tarkoittaa sitä, kuinka tehokkaasti sovellus on kehitettävissä, ylläpidettävissä ja uudelleenkäytettävissä. Suorituskyky viittaa siihen, kuinka tehokkaasti sovellus on ajettavissa ja kestävyys viittaa siihen, kuinka hyvin ohjelmisto tukee kestävää kehitystä. Ohjelmiston vihreyttä ajatellessa ei siis riitä, että huomioidaan pelkästään tuotteeseen liittyvät näkökulmat, vaan huomioon täytyy ottaa myös ohjelmistokehitysprosessi. [56] [51]. 3.1 Vihreiden käytänteiden implementointi käytäntöön Ahmad et al. [6] ovat haastatelleet tutkimuksessaan eri yritysten työntekijöitä liittyen vihreiden ohjelmointikäytänteiden toteutumiseen omassa työssään. Tutkimuksesta käy ilmi, että vain osalla yrityksistä on käytössään vihreisiin ohjelmointikäytäntöihin liittyviä ohjeistuksia. Osa haastatelluista ilmoitti, että yrityksellä ei ole tarkkoja ohjeita vihreiden käytänteiden implementoinnista ohjelmointiprosessiin. Tutkimuksessa tulee esille se, että kaikki yritykset eivät myöskään kampanjoi vihreiden käytänteiden esille tuomiseksi. [6] Rajallinen tekninen asiantuntemus ja tietämys, riittämätön infrastruktuuri, asioiden monimutkaisuus ja taloudelliset resurssit ovat esteitä vihreyden implementoinnille [43]. Sugih P. et al. [11] tutkimuksessa tuodaan kuitenkin esille, että kestävän kehityksen mukaisiin työskentelytapoihin kannustetaan myös organisaatiotasolla ja vihreiden käytänteiden huono soveltaminen käytäntöön koskee vain hyvin pientä osaa yrityksistä. Tämän lisäksi työntekijät suhtautuvat pääasiassa positiivisesti vihreisiin sovelluksiin, vaikka niiden käyttämisessä koetaan olevan riskejä. [11] Vihreään ohjelmistokehitysprosessiin liittyvät käytännöt vaihtelivat. Vaatimusmäärittelyvaiheessa vain osa haastatelluista ilmoitti hyödyntävänsä aikaan, liikkumiseen sekä toimistotiloihin liittyviä säästötoimenpiteitä, etäyhteyksiä, dokumenttien elektronista dokumentointia ja jaettua dokumenttia. Suunnitteluvaiheessa vain osa hyödynsi avoimen lähdekoodin ohjelmistoja, oikeanlaisia käyttöliittymiä, pa- 16 perin säästämistä ja joustavaa suunnittelua. Osa haastateltujen työpaikoista ei käyttänyt suunnitteluvaiheessa mitään vihreitä käytänteitä. Samoin implementointi- ja testausvaiheessa vihreiden käytänteiden hyödyntäminen oli puutteellista. Koodin optimointia, versiointia, olio-ohjelmointia sekä järjestelmän etätarkistusta hyödynnettiin vain osassa yrityksissä. [6] Yritysten tulisikin luoda kokonaisvaltainen kestävään kehitykseen ja vihreyteen liittyvä strategia, siihen liittyvät tavoitteet, käytänteet ja toimintatavat sekä aikataulu tavoitteiden saavuttamiseksi [40]. 3.2 Vihreä ohjelmistokehitysprosessi Vihreässä ohjelmistokehityksessä vaatimusmäärittely- ja suunnitteluvaihe korostuvat suhteessa tuotantovaiheeseen. Tämä on ristiriidassa ketterien menetelmien kanssa, jossa painotetaan ohjelmistokehityksen kehittämisvaihetta ja suunnitelmat voivat muuttua useasti prosessin edetessä. Ketterien menetelmien etuna on kuitenkin se, että epäkohtiin niin prosessissa kuin tuotteessakin voidaan puuttua varhaisessa vaiheessa ja tuotteen vihreyttä voidaan parantaa myös prosessin ollessa käynnissä. Oleellista on, että kestävän kehityksen mukaiset toimintatavat integroidaan prosessiin ja suunnitelmiin jo varhaisessa vaiheessa. [12] [8] Yhtä oleellista on kuitenkin parantaa prosessia sen edetessä ja viedä hyväksi havaittuja asioita myös tuleviin projekteihin. Vihreässä ohjelmistokehityksessä on myös tärkeää dokumentoida ohjelmistoon ja prosessiin liittyvät kestävän kehityksen ongelmat, toimenpiteet ja tulokset. Tämäkin on kuitenkin ristiriidassa ketterän ohjelmistokehityksen kanssa, jossa painotetaan kehitystyötä dokumentoinnin sijaan. Ylimääräinen dokumentointi heikentää prosessin vihreyttä, mutta toisaalta se on oleellista, että voidaan todentaa kestävään kehitykseen liittyvät tulokset, raportoida niistä asiakkaalle ja kehittää ohjelmistokehitysprosessin vihreyttä edelleen. Tästä voidaan tehdä johtopäätös, että dokumentoinnin tulisi olla mahdollisimman tiivistä, mutta kuitenkin tarpeek- si kattavaa, jotta se on tarkoituksenmukaista ja ei aiheuta negatiivisia vaikutuksia ohjelmistokehitysprosessiin tai ohjelmistoon. 3.2.1 Vihreän ohjelmistokehitysprosessin menestystekijöitä ja käytänteitä Hiilijalanjäljen pienentämiseksi organisaatioiden tulisi käyttää vihreitä ja kestäviä käytäntöjä. Vihreän ohjelmistokehitysprosessin merkittävimmät menestystekijät o- 17 vat vähäiset hiilidioksidipäästöt sekä tehokas resurssien käyttäminen ajan ja laskentaresurssien suhteen. [51] [50] Ohjelmistokehitysprosessin tehokkuutta voidaan edistää useilla eri keinoilla. Pariohjelmointi on tehokas tapa koodata ohjelmistoja. Pariohjelmointi voi tuoda lisäaikaa yksinkertaisten tehtävien suorittamisessa ja toisaalta helpottaa monimutkaisten tehtävien ratkaisemista laadukkaammin. Tiimin tulisi myös kehittää uudellenkäytettävää koodia. [19] [50] [52] Tuotteen luovutus asiakkaalle tulisi aikatauluttaa ja seurata kehitysprosessin nopeutta, jotta ohjelmisto tulee luovutettua ajoissa. Sprintit/iteraatiot tulisi pitää lyhyinä ja prosessin aikana tulisi huolehtia siitä, että korjattavat viat eivät kasaannut. Ohjelmistokehitykseen tulisi käyttää olemassa olevia työkaluja. [50] Hyvä ja tehokas viestintä on yksi vihreän ja ketterän ohjelmistoprojektin menestystekijöistä. Tiimin keskinäistä sekä tiimin ja asiakkaan välistä viestintää ja yhteistyötä voidaan edistää esimerkiksi valmentamalla tiimiä ennen projektin alkamista. Viestintää voidaan myös tehostaa kasvokkain tapahtuvilla tapahtumilla sekä verkon välityksellä tapahtuvalla viestinällä. Tehokkaan viestinnän näkökulmasta tiimin koko tulisi pitää mahdollisimman pienenä. Epävirallisten tapaamiset sekä sosiaaliset aktiviteetit edistävät niin ikään tiimin välistä sekä tiimin ja asiakkaan välistä kommunikointia. Positiivinen työympäristö ja riittävä tuki työntekijöille luo edellytyksiä tiimin sisäiselle yhteistyölle sekä tehokkaalle ohjelmistokehitykselle ja lisää siten tuottavuutta. [50] Minimaalin dokumentointi on yksi kriittisistä menestystekijöistä vihreässä ketterässä ohjelmistokehityksessä. Minimaalisella dokumentaatiolla tarkoitetaan sitä, että ohjelmistokehityksessä painotetaan koodin kirjoittamista raskaan dokumentaation sijasta. Ohjelmistokehitysprosessina aikana tulisi järjestää tapaamisia asiakkaan ja tiimin välillä, jotta saavutettaisiin mahdollisimman hyvä ymmärrys projektin monimutkaisuudesta ja vähennettyä turhaa dokumentaatiota. Raskasta dokumentaatiota voidaan pienentää epävirallisella viestinnällä tiimin jäsenten kesken sekä tehokkaalla ohjelmistokehitystä koskevien tietojen jakamisella. [50] Minimaaliseen dokumentaatioon liittyy kuitenkin ongelmia, jotka saattavat haitata myöhemmissä vaiheissa ohjelmistokehitysprosessia tai ohjelmiston elinkaarimallia. Dokumentaation tulisi olla riittävää ja laadukasta. Minimaalinen dokumentointi olisikin hyvä yhdistää dokumentoinnin automatisointiin erilaisilla työkaluilla. [57] Tästä voidaan päätellä, että dokumentoinnin tulisi olla optimoitua, jotta dokumentaation puute ei haittaa ohjelmistokehitystä muissa vaiheissa. Toisaalta pitää huolehtia siitä, 18 lyysissä pyritään tunnistamaan ohjelmiston osia tai alueita koodista, jotka vaativat enemmän matalan tason testausta. Testitapaukset ja testien hallinta instrumentointiin testin tehokkuuden tunnistamiseksi. Tehokkuutta pyrittiin parantamaan kohdistamalla testausta aiemmin kattamattomiin koodisegmentteihin. Testattavuutta pyrittiin parantamaan testivetoisen kehityksen (TDD) ja testilähtöisen vaatimussuunnittelun (TDRE) avulla, joka määrittelee toiminnot testitapauksiksi. Näillä toimenpiteillä pystyttiin poistamaan toisteisuutta testauksessa ja parantamaan tehokkuutta. Testilähtöinen ohjelmistokehitys ja testilähtöinen vaatimussuunnittelu helpottavat regressiotestausta ja tekevät siitä tehokkaampaa. [61] Projektin toisessa vaiheessa otettiin käyttöön riskilähtöinen testaus. Tällä pyritään vastaamaan kysymyksiin siitä, miten järjestelmän toimivuus, turvallisuus ja luotettavuus voidaan varmistaa, jos ohjelmiston ajonaikainen toimintahäiriö vaikuttaa johonkin ohjelmiston toisen osan alikomponenttiin tai jos päivityksiä tehdään vain osaan ohjelmistoa. Riskilähtöinen testaus arvioi funktioiden riippuvuuksia sekä valkoinen laatikko- ja musta laatikko -testauksena (White-box and Black-box - testing). Projektin viimeisessä vaiheessa otettiin käyttöön älykäs testaus tekoälyn kanssa. Älykäs testaus auttaa määrittelemään mitkä testitapaukset on toteutettava ja missä määrin. Älykäs validointi auttaa testitapausten valinnassa ja luomisessa. Projektin tuloksena testaamiseen käytettäviä resursseja saatiin vähennettyä ja testien tehokkuutta parannettua. [61] 3.3.5 Ylläpito Ohjelmistot, joita voidaan käyttää pidempään ilman muutoksia tai parannuksia, vähentävät ylläpitotoimia ja puolestaan auttavat pienentämään hiilijalanjälkeä. Kaikki ohjelmiston ylläpitotoimet katsotaan tuoreeksi kehitystyöksi ja johtavat koko SDLC- prosessin toistamiseen. Siten ohjelmistoja, joiden käyttöikä on pidempi, voidaan pitää myös kestävänä ohjelmistona. Termi kestävä koskee sekä ohjelmiston pidempää elinikää että vihreämpiä näkökohtia. [3] Ylläpitovaiheessa huomioidaan ohjelmiston käyttämisestä ja ylläpitämisestä syntyvät suorat ja epäsuorat vaikutukset. Ylläpitovaiheeseen liittyvät asiat tulee kuitenkin ottaa huomioon jo ohjelmistoa suunniteltaessa ja kehitettäessä. Tässä vaiheessa tulisi huomioida esimerkiksi järjestelmän tuki- ja konfigurointitehtävät. Loppukäyttäjille voidaan myös tarjota energiansäästöohjeita. Ohjelmiston elinkaaren viimeisessä vaiheessa huomioidaan ne asiat, jotka ovat merkityksellisiä, kun ohjelmistoa poistetaan käytöstä. Tällöin tulisi päättää mitkä tiedostot säästetään, voidaanko nii- 25 tä muuttaa uusiin tiedostomuotoihin vai voidaanko ne poistaa kokonaan ja säästä siten muistiresursseja. [13] Ohjelmiston ylläpitovaiheeseen kuuluu myös koodin refaktorointi, joka vihreässä asiayhteydessä tarkoittaa lähdekoodin energiatehokkuuden optimointia muuttamatta lähdekoodin rakennetta. Kaikki olemassa olevat refaktorointitekniikat eivät kuitenkaan vaikuta ohjelmiston energiatehokkuuteen. [18] Verdecchia et al. tutkimus [61] tarjoaa näkökulman käytön aikana syntyvän hiilijalanjäljen pienentämiseen sillä, että käyttäjät ovat myös vastuussa ja pystyvät vaikuttamaan omalla toiminnallaan tähän. Yksinkertainen esimerkki on mainosten estäminen, jolla voidaan vähentää energian kulutusta datakeskuksissa, tietoliikenneväylillä sekä omassa tietokoneessa. Ohjelmiston kehittäjän vastuulla on mahdollistaa energiaa säästävät ja hiilijalanjälkeä pienentävät toiminnot ja tehdä niistä helppokäyttöisiä sekä informatiivisia. Koulutusohjelmien vastuulla on, että tulevaisuuden tekijöillä on tarpeeksi tietotaitoa toteuttaa energiatehokkaita sekä vihreitä ohjelmistoja. 3.4 Vihreä ohjelmisto Seuraavissa luvuissa käydään läpi ohjelmiston rakentamiseen liittyviä käytänteitä, joilla pyritään edistämään näitä vihreän ohjelmiston kehittämisen periaatteita. 3.4.1 Ohjelmiston vihreyden mittaaminen Ketterässä kehityksessä on tavallista, että tuotteita kehitetään testilähtöisesti. Tavallisesti on totuttu siihen, että testaus kohdistuu muihin ohjelmiston laatutekijöihin kuin vihreyteen ja siksi kehittäjien tulisi integroida testipakettiin myös testejä energiatehokkuuden arvioimista varten. [12] Aggrawal et al. [5] kertovat tutkimuksessaan, että järjestelmäkutsuprofiili korreloi ohjelmiston energiankulutuksen kanssa. Ohjelmistokehittäjät voivat hyödyntää järjestelmäkutsuprofilointia ohjelmistoon tehtyjen muutosten yhteydessä arvioimaan ohjelmiston energiankulutuksen muutoksia. Järjestelmäkutsuprofilointiin on olemassa myös yksinkertaisia työkaluja, kuten Aggrawal et al. [4] kehittämä GreenAdvisor. Hyvä ohjelmisto säästää resurssejaan ja aika sekä vähentää hukkaa. Tehokkuus määrittelee, miten ohjelmisto käyttäytyy resurssien säästämisessä ja tuhlauksen vält- 26 tämisessä. Tehokkuuden mittareita ovat muun muassa CPU-intensiteetti, muistin käyttö, perifeerinen intensiteetti, joutokäynti sekä heijastuskyky. CPU-intensiteetillä mitataan kuinka monta CPU-jaksoa ohjelmisto kuluttaa. Jokaisen syklin vaatima energia on mitattavissa ja mukautettavissa muihin mittareihin. Muistin käytöllä voidaan seurata esimerkiksi päämuistin kulutusta. Tämän lisäksi seurataan, kuinka muistia käytetään. Erittäin vähän energiaa kuluttavassa ympäristössä on hyödyllistä minimoida muistin kulutus ja nollata käyttämättömät tavut. Tällä säästetään energiaa siten, että nollattu bitti on edullisempaa päivittää kuin asetettu bitti. [56] Perifeerisellä intensiteetillä seurataan sitä, kuinka paljon oheislaitteita käytetään. Tämä voidaan arvioida esimerkiksi laskemalla, kuinka monta pyyntöä ohjelmis- to tekee oheislaitteille ja mitä resursseja tarvitaan. Toinen yksinkertainen tapa on laskea oheislaitteen energiatarve. Tarkoituksena on, että suorittimien syklit olisivat jollain tavalla hyödyllisiä ja auttaisi ohjelmistoa saavuttamaan tavoitteensa. Tyhjäkäynti ei kuitenkaan koskaan ole hyödyllistä ja sillä hukataan resursseja. Joutokäynnillä siis seurataan, kuinka paljon ohjelmisto on käyttämättömänä. Joutokäynnin minimoimiseen on kehitetty muun muassa IT-palvelinratkaisuja. Heijastuskyvyllä mitataan kuinka ohjelmisto vaikuttaa epäsuorasti sen toimialueeseen. Heijastuskyky on ehkä tärkein tehokkuuden tekijä, koska siitä syntyvän jätteen määrä voi olla tuhoisa. Esimerkiksi muistiin perustuva ohjelmisto käyttää resursseja yleensä silloin kun tietokone käynnistetään. Tämä hidastaa tietokoneen käynnistystä ja tietokoneen käyttäjä jättää herkemmin tietokoneen päälle välttääkseen odottelua. Tämä lisää suorasti energiankulutusta sekä huonontaa tehokkuutta. Näillä tekijöillä arvioidaan, kuinka ohjelmistot vähentävät jätettä. Tehokkuusmittareiden tulkinta ei kuitenkaan ole yksinkertaista. [56] Kestävyyttä mitattaessa halutaan tietää mikä ohjelmistojen arvo on kestävässä kehityksessä sekä kuinka ohjelmisto tukee hävikin vähentämistä. Kestävyys on suhteellinen tekijä, joten kahden ohjelmiston kestävyyttä ei voi verrata, jos ne eivät ole samanlaisissa ohjelmistojärjestelmissä. Kestävyys on vaikeinta mitata sen abstraktin luonteen takia. [56] Kestävä kehitys voidaan määritellä tarkoitukseen sopivuudella, reduktiolla sekä kauneudella. Se voidaan myös jakaa myös ekonomiseen, sosiaaliseen ja ympäristölliseen ulottuvuuteen. [24] Tarkoitukseen sopivuus määrittää kuinka ohjelmisto auttaa järjestelmää saavuttamaan tavoitteet. Reduktio määrittää kuinka ohjelmisto tukee jätteen vähentämisessä. Kauneus määrittelee ohjelmiston arvon kestävässä kehityksessä. Näillä tekijöillä ei kuitenkaan ole mahdollista saada absoluuttisia mittareita. Tekijät ovat riippuvaisia järjestelmästä, jossa ohjelmis- 27 toa suoritetaan sekä toimialueesta, jossa järjestelmää käytetään. Tämän takia näiden tekijöiden mittaaminen on toimialuekohtaista ja jokaiselle järjestelmälle täytyy määritellä vertailujärjestelmä. [56] 3.4.2 Laitteisto Verdecchia et al. [61] kirjoittavat artikkelissaan, että kaiken kaikkiaan tuotteet tuli- si suunnitella joustavaksi tulevaisuutta ajatellen. Yksinkertaisinta on varmistaa, että ohjelmiston ydintoiminnot toimivat edelleen vanhemmissa laitteissa. Laitteiden ikääntyminen on väistämätöntä, mutta tämänhetkinen tilanne, jossa laitteiston odotetaan vanhenevan todella lyhyessä ajassa, on kestämätöntä tulevaisuutta ajatellen. IoT-laitteiden ohjelmoijat ovat ratkaisseet tämän ongelman siten, että he eriyttävät ohjelmiston laitteistosta. Tämä mahdollistaa esimerkiksi tietoturvakorjaukset sekä ohjelmisto päivitykset ilman laitteistoin uusimista. Usein päivitykset tapahtuvat ilmateitse, kuten IoT-laitteiden luonteeseen kuuluu. Ilmateitse tapahtuvat päivitykset mahdollistavat myös tietoturvapäivitykset ja virheiden korjaukset ilman uusia laitteistoja. Myös pilvipalvelujen käyttö vähentää tarvittavien laitteistojen määrää ja tarvetta päivittää laitteistoja. [2]. Osa isoista laitevalmistajista on alkanut strategisesti kehittää laitteita hiilineutraaliin suuntaan. Asiakkaat voivat arvioida tuotteiden ominaisuuksia esimerkiksi standardien ja tuoterekisterien avulla. Laitevalmistajat ovatkin alkaneet valmistaa vihreämpiä tietokoneita esimerkiksi käyttämällä myrkyttömiä vaihtoehtoja materiaaleille sekä tekemällä niistä vähemmän energiaa kuluttavia. Käyttöikää on pyritty pidentämään tekemällä tietokoneista päivitettävämpiä. Ydinprosessoreiden määrän lisääminen sirun taajuuden lisäämisen sijaan säästää energiaa ja lisää myös tietokoneen suorituskykyä. Esimerkiksi 15 % säästö taajuudessa vähentää virrankulutusta 50 %. Myös välimuistin jakaminen segmentteihin ja niiden käyttäminen vain tarvittaessa säästää energiaa. Flash-muistia voidaan käyttää välimuistina kiintolevyllä, pöytäkoneilla ja palvelimilla. Näytöissä energiaa voidaan säästää myös käyttämällä tummempaa taustavaloa. [40] Edelleen laitteistojen kehittyessä ja tutkimuksen edetessä on mahdollista, että tulevaisuudessa otetaan käyttöön non-Von Neumann -tekniikoita, kuten neuromorfisen laskennan. Tämä mahdollistaisi laskennan suorittamisen murto-osalla nykyisistä energiakustannuksista. [61] 28 3.4.3 Säästävät ohjelmistostrategiat Säästävillä ohjelmistostrategioilla pyritään minimoimaan virrankulutus, joten se voidaan katsoa olevan tärkeä osa vihreää ohjelmistokehitystä. [51] Kehittäjien tulisi adaptoida ohjelmointitekniikoita, jotka ovat mahdollisimman tehokkaita tiedon varastoinnin, laskennan sekä verkkoresurssien käytön suhteen. Tämä voi tarkoittaa esimerkiksi ohjelmiston koordinointia laitteiston kanssa, tyhjäkäyntitehokkuuden optimoimista tai laiskaa initialisointia (Lazy Initialization). Laskennan ei tarvitse kaikissa tapauksissa olla tarkkaa ja oikea-aikaista. Energiaa voidaankin säästä myös viivästyttämällä sitä ohjelmiston vaatimusten niin salliessa. [61] [49] [40] [36] Energiaa voidaankin säästä myös approksimoimalla laskennan tarkkuutta. [36] Mitra et al. [38] selvittivät tutkimuksessaan ohjelmiston laskennan approksimoimista jakamalla ohjelmiston toiminnan vaiheisiin ja tutkimalla yksittäisten vaiheiden vaikutusta palvelunlaatuun, nopeuteen sekä energiankulutukseen. Tällaisen vaiheittaisen optimoinnin avulla pystyttiin säästämään energiaa ilman, että approksimoiminen vaikutti liikaa ohjelmiston laatuvaatimuksiin. Ohjelmiston käytöksellä on merkittävä vaikutus alustaan sisäänrakennettujen energiansäästöominaisuuksien tehokkuuteen. Ohjelmiston energiatehokkuutta on laskentatehokkuus. Laskentatehokkuus tarkoittaa sitä, että ohjelmisto tulee rakentaa tehokkailla algoritmeilla, hyödyntämällä rinnakkaislaskentaa sekä vektorointia. [55] [49] [25] Kambadur ja Kim [25] totesivat tutkimuksessaan rinnakkaislaskennan olevan toimiva tapa vähentää ohjelmiston energiankulutusta. Tuloksia heikensi kuitenkin se, että osa testatuista ohjelmista soveltui huonosti rinnakkaislaskentaan. Energiansäästöjä saavutettiin kuitenkin myös huonosti soveltuvien ohjelmien rinnakkaistamisessa. Datatehokkuudella tarkoitetaan sitä, että datan liikkuminen operoinnin aikana pidetään mahdollisimman vähäisenä. Tämä tarkoittaa I/O-kutsujen (Input/Output -kutsujen) optimointia sekä pollauksen eli laitteiden tilan tarkastamisen välttämistä. Data tulisi siirtää massaoperaationa (Bulk Operation). Algoritmien lisäksi muistihierarkian ja datastruktuurien hyvä suunnittelu sekä välimuistin tehokas käyttäminen ovat tärkeässä roolissa. Kolmas kategoria eli kontekstitietoisuus tarkoittaa sitä, että sovellus pystyy tarkkailemaan ympäristöään ja reagoimaan ympäristön muutoksiin. [61] [49] Suurin ohjelmistokeskeisen Green IT -lähestymistavan mahdollistanut teknologia on virtualisointi. Sekä suuret että pienet organisaatiot hyödyntävät virtualisointia lähinnä palvelimiensa ja työasemiensa kustannusten alentamiseksi. Epähuo- 29 miossa tämä on myös vaikuttanut paljon kestävään ohjelmistoympäristöön. Siksi ohjelmiston käyttötapa on tärkeä ohjelmiston kestävyyden kannalta. [3] Myös tekoälyllä ja koneoppimisella voidaan saada säästöjä siten, että tunnistetaan eri datankäyttöprofiileja ja optimoidaan palvelimien käyttöä entistä tehokkaammaksi. Ohjelmistoihin tulisi sisällyttää käyttäjien mahdollisuus vaikuttaa ohjelmiston energiankulutukseen. Käyttöliittymä tulisi olla sellainen, että käyttäjä pystyy selvästi havaitsemaan ohjelmiston energiankulutuksen esimerkiksi värien avulla. [61] [13] Käyttäjälle tulisi myös tehdä helpoksi tarpeettomien energiaa kuluttavien ominaisuuksien pois kytkemisen ja yötilan käyttämisen. Myös mainosten estäminen sekä videoiden resoluution laskeminen säästää kaistanleveyttä ja energiaa. Tämä voidaan jopa automatisoida tekoälyn avulla seuraamalla toimintaa ja laskemalla käyttämättömien prosessien tilaa lepotilaan tai jopa sammuttamalla ne. [61] [49] 3.4.4 Algoritmit Ohjelmistokehityksessä on joitain yleisiä käytäntöjä, jotka eivät ole vihreitä. Esimerkiksi kehittynyt tietokonelaitteisto ja uusin teknologia kompensoivat ohjelmistotuotteen puutteet, ja siksi hitaampia, tehottomia ja kalliimpia ohjelmistoja on ollut olemassa pitkään ilman, että suorituskyky on heikentynyt. Ohjelmistoinsinöörit tekevät kustannusanalyysin siten, että työtunteja pidetään arvokkaimpana hyödykkeenä ja siksi painopiste on kehitysajan lyhentämisessä. Tehokkaamman algoritmin kehittämistä, jonka suorittaminen vie vähemmän aikaa, ei kuitenkaan juurikaan ajatella. Koska ohjelmistoa ajetaan tuhansia ja miljoonia kertoja, ajan säästäminen suorituksessa voi olla parempi ratkaisu sekä kustannusten että kestävyyden kannalta. Ihmisinä ohjelmistosuunnittelijat vihaavat saman ongelman ratkaisemista yhä uudelleen ja uudelleen, joten rakennamme koodikirjastoja ja käytämme muita kirjastoja mahdollisimman paljon. Mutta yhä enemmän luotamme kolmannen osapuolen komponentteihin, jotka ovat tuhansia kertoja suurempia mitä todella haluamme käyttää. [3] Koodin optimoinnilla voidaan kuitenkin saavuttaa huomattavia energiasäästöjä [1] [30]. Epäpuhtaiden funktioiden, eli funktioiden välttäminen joilla on syöteparametreja, voi vähentää energiankulutusta. Myös silmukoiden ja tietokantahakujen määrän vähentäminen uudelleen faktoroimalla voi vähentää energiankulutusta. [39]. Algoritmien energiankulutusta sekä hiilidioksidipäästöjä voidaan arvioida arviointityökaluilla, joista yksi esimerkki on https://www.green-algorithms.org/ [30]. 30 3.4.5 Pilvipalvelut ja reunalaskenta Palvelujen sijoittamisella pilveen on monia energiaa säästäviä ratkaisuja ja tällä tavalla voidaan vähentää jopa 64 % energiankäytössä. Pilveen voidaan datan varastoinnin lisäksi sijoittaa laskentaa ja ohjelmiston ominaisuuksia. Pilvipohjaisissa palveluissa resursseja käytetään pyynnöstä, joka mahdollistaa isossa mittaskaalassa datakeskusten energiatehokkuuden optimoinnin. Pilvipalvelut mahdollistavat esimerkiksi hyödyllisyyslaskennan, joka on esimerkki pyynnöstä tapahtuvasta laskennasta. [61] [27] Pilvipalveluilla on vähemmän yleiskustannuksia sekä tehokkaampi skaalautuvuus. Tässä voidaan samalla tehokkaammin hyödyntää vihreitä energianlähteitä ja esimerkiksi ottaa talteen laitteiston lämpenemisestä tuleva hukkaenergia. Tiedon käsittelemisessä keskitetyissä palvelimissa on myös se hyöty, että palvelimet ovat tehokkaammin käytössä ja niin kutsuttua joutokäyntiä on vähemmän. [61] Palvelinkeskusten energiatehokkuutta mitataan PUE-arvolla. [54] Pilvipalvelujen käyttäminen ei kuitenkaan tarkoita automaattisesti kestävämpiä ja vihreämpiä ohjelmistoja ja ohjelmistoarkkitehtuuri voi vaatia suuriakin muutoksia. Ohjelmiston tulisi käsitellä dataa ja datan liikkumista tehokkaasti. Tällä pyritään vähentämään datan varastoinnin tarvetta, laskentaresurssien tarvetta sekä tietoliikenneresurssien tarvetta sekä reunasta pilveen, että asiakkaalle. Tämä tarkoittaa käytännössä datan siirtelyn optimoimista, kaksoisdatan poistamista sekä älykästä tietojen pakkaamista datan käyttötiheyteen perustuen. Tämän lisäksi pitäisi hyödyntää palvelitonta laskentaa sekä FaaS-toimintoa (Function-as-a-Service), jotka mahdollistavat resurssien saumattoman skaalautumisen. Datan käytön profiloinnilla ja tekoälypohjaisten profilointisovellusten avulla voidaan löytää käyttäjien toimintamalleja ja säätää sovelluksen toimintaa tarpeen mukaisesti ja lisätä tehokkuutta. [61] [31] Palvelimien virtualisointi on hyvä tapa säästää energiaa [40] [13] [31]. Virtualisoinnin avulla yksi fyysinen palvelin pystyy vastaamaan useasta virtuaalisesta palvelimesta, jolloin palvelinta käytetään tehokkaammin ja tyhjäkäyntiä on vähemmän. Tällä tavoin voidaan säästää energiaa, mutta myös fyysisen tilan tarvetta [40] [39]. Sovelluskehittäjille vihreät palvelinkeskukset aiheuttavat haasteita, koska laitepuolen kehittyessä myös sovellusten tulisi voida hyödyntää laitatason kehitystä. Jos näin ei tapahdu, oletettu energiansäästö jää saavuttamatta. [27] Tulevaisuudessa tullaan kuitenkin hyödyntämään hajautettua tiedonhallintaa eli reunalaskentaa. Täl- 31 löin laskenta suoritetaan mahdollisimman lähellä ohjelmiston loppukäyttäjää, jolloin pystytään vähentämään datan siirtelystä aiheutuvaa energiankulutusta. [61] Pilvipalvelimien käytön yleistyminen on kuitenkin aiheuttanut sen ongelman, että ne myös käyttävät entistä enemmän energiaa ja tulevaisuudessa haasteena onkin pilvipalvelimien käytön optimointi. Esimerkiksi konttiteknologiasta on saatu hyviä kokemuksia, mutta vaatii lisää tutkimusta jotta niiden potentiaalia voidaan hyödyntää mahdollisimman optimaalisella tavalla. [28] Kaikki pilvipalvelut eivät myöskään ole automaattisesti kestävän kehityksen mukaisia. Pilvipalveluja valitessa tulisi huomioida niiden ympäristöystävällisyys. Huomioitavia asioita ovat esimerkiksi energiatehokkuus sekä uusiutuvien energialähteiden käyttäminen. Pitää kuitenkin muistaa, että pilvipalvelut eivät hyödyllisyydestään huolimatta ratkaise kaikkia kestävään kehitykseen liittyviä ongelmia. [61] [2] [39] [31] 3.4.6 Ohjelmointikieli Ohjelmointikielien energiatehokkuutta tarkastellessa ennakko-oletuksena on, että ohjelmiston energiankäyttö on sähkövirta kerrottuna ajalla. Tästä voitaisiin päätellä, että ajallisesti nopein olisi myös tehokkain. Pereira et al. [46] ovat tutkineet 27 eri ohjelmointikielen ominaisuuksia kolmesta eri näkökulmasta: suoritusaika, muistin kulutus ja energiankulutus. Tulosten perusteella he ovat vertailleet myös näiden ominaisuuksien käytön välisiä suhteita. Tuloksissa esitellään binääripuun, Fannkuch-redux-ongelman ja FASTA:n avulla muodostetut tulokset energiatehokkuuden suhteen ja myös se miten ohjelmointikieli sijoittuisi suoritusajan ja muistin käytön suhteen. Tuloksista käy ilmi, että C-pohjaiset sekä imperatiiviset kielet ovat energiankulutuksen suhteen kaikista tehokkaimpia [46] [1]. Tulokset kuitenkin jakaantuvat ratkaistavana olevan ongelman mukaisesti ja esimerkiksi kun käsitellään binääripuuta tai Fannkuch-Redux -ongelmaa, C ja C++ ovat energiatehokkaimpia. FASTA:n tapauksessa kuitenkin Rust ja Fortran olisivat energiatehokkaimpia. Normalisoiduissa tuloksissa C, Rust ja C++ ovat kolme ensimmäistä energiatehokkainta ohjelmointikieltä. Tulosten perusteella käy ilmi, että kulutettu energia ei ole suoraan verrannollinen kulutettuun aikaan ja tulokset ovat riippuvaisia kielistä ja käsiteltävänä olevasta ongelmasta. Pereira et al. [47] ovat myöhemmässä tutkimuksessaan tulleet samaan johtopäätökseen. Ohjelmointikielen energiankulutus on vain joissain tapauksissa riippuvainen suoritusajasta. Vaikka tuloksista käy ilmi, että energiatehokkain kieli on usein myös nopein, ei ole yhtä ainoaa, joka on aina parempi kuin jokin toinen. Kielen energiatehokkuus on riippuvainen ohjelmointiongelmasta, jo- 32 hon sitä aiotaan käyttää. Esimerkiksi regex-redux vertailussa tulkitut kielet vaikuttavat olevan energiatehokkaampi valinta, vaikka tulkitut kielet eivät ole kovinkaan energiatehokkaita muita skenaarioita tarkasteltaessa. Artikkelien [46] [47] kirjoittajat ovat tutkineet myös sitä voiko ohjelmointikielen valintaa automatisoida optimointitavoitteiden avulla. He käyttivät Pareto-op- timointia, koska on mahdollista, että ei ole vain yhtä ainoaa vaihtoehtoa optimaalisimmaksi kieleksi ohjelmointiongelmaan vaan joukko kieliä, jotka ovat saman arvoisia ohjelmointiongelman ratkaisemissa. Tätä kutsutaan Pareto-optimaaliseksi joukoksi. Esimerkiksi ajan- ja muistinkäytön suhteen C, Pascal ja Go ovat saman arvoisia sekä energian- ja muistinkäytön suhteen C ja Pascal ovat saman arvoisia. Tuloksista käy ilmi, että energian- ja ajankäytön optimoimisen suhteen parhaimman ohjelmointikielen valitseminen on mahdollista ja Pareto-optimaalisia kielijoukkoja oli vain muutama. Kääntämisen aikainen ohjelmiston optimointi voi vähentää ohjelmiston energiankulutusta. Energiankulutuksen väheneminen johtuu kuitenkin pääasiassa ohjelmiston ajamiseen käytettävän ajan vähenemisestä, joka vähentää myös ohjelmiston energiankulutusta. [25] [41] 3.4.7 Datan ja muistin käyttö Pereira et al. [46] ovat vertailleet tutkimuksessaan myös ohjelmistokielien vaikutusta huippumuistin (peak memory) energiankäyttöön. Heidän tulostensa mukaan DRAM-muistin energiankulutus korreloituu hyvin vähän muistin käytön suhteen. Keskimäärin käännetyt kielet kuluttivat DRAM:n suhteen 14J, virtuaalikoneen kielet 52J ja tulkitut kielet 236J. Myöhemmässä tutkimuksessaan Pereira et al. [47] tulivat siihen tulokseen, että koodin optimointi, jonka tarkoituksena on vähentää prosessorin energiankulutusta voi vähentää myös DRAM-muistin energiankulutusta. Viisi parasta kieltä DRAM-muistin energiankulutuksen suhteen olivat C, Rust, C++, Ada ja Java. He havaitsivat myös, että kokonaismuistin määrän ja DRAM-muistin energiankulutuksen välillä on suora yhteys. Mitä enemmän muistia ohjelmisto käyttää elinkaarensa aikana, sitä enemmän kuluu energiaa DRAM-muistin käyttämiseen. Moises et al. [39] tutkimuksessa kerrotaan, että sivujen välimuisti voisi vähentää verkkosivujen energiankulutusta. Kuitenkin Malavolta et al. [35] uudemmassa tutkimuksessa on tultu siihen tulokseen, että välimuistin käytöllä ei ole vaikutusta verkkosivun energiankulutukseen merkittävissä määrin. 33 Taulukko 3.1: Ohjelmointikielien vertailun normalisoidut tulokset energian, ajan ja muistin suhteen. Mukaillen [46]. Kieli Energia C 1.0 Rust 1.03 C++ 1.34 Ada 1.70 Java 1.98 Pascal 2.14 Chapel 2.18 Lisp 2.27 Ocaml 2.40 Fortran 2.52 Swift 2.79 Haskell 3.10 C# 3.14 Go 3.23 Dart 3.83 F# 4.13 JavaScript 4.45 Racket 7.91 TypeScript 21.50 Hack 24.02 PHP 29.30 Erlang 42.23 Lua 45.98 Jruby 46.54 Ruby 69.91 Python 75.88 Perl 79.58 Kieli Aika C 1.00 Rust 1.04 C++ 1.56 Ada 1.85 Java 1.89 Chapel 2.14 Go 2.83 Pascal 3.02 Ocaml 3.09 C# 3.14 Lisp 3.40 Haskell 3.55 Swift 4.20 Fortran 4.20 F# 6.30 JavaScript 6.52 Dart 6.67 Racket 11.27 Hack 26.99 PHP 27.64 Erlang 36.71 Jruby 43.44 TypeScript 46.20 Ruby 59.34 Perl 65.79 Python 71.90 Lua 82.91 Kieli Mb Pascal 1.00 Go 1.05 C 1.17 Fortran 1.24 C++ 1.34 Ada 1.47 Rust 1.54 Lisp 1.92 Haskell 2.45 PHP 2.57 Swift 2.71 Python 2.80 Ocaml 2.82 C# 2.85 Hack 3.34 Racket 3.52 Ruby 3.97 Chapel 4.00 F# 4.25 JavaScript 4.59 TypeScript 4.69 Java 6.01 Perl 6.62 Lua 6.72 Erlang 7.20 Dart 8.64 Jruby 19.84 34 (b) Mitä mieltä haastateltava on kysymyksistä? i. Onko kysymykset liian helppoja tai vaikeita? ii. Onko kysymykset informatiivisia? iii. Onko väittämissä "kyllä/ei-vastausvaihtoehto riittävä vai olisiko hyödyllistä lisätä "En tiedä-vastausvaihtoehto? (c) Mitä mieltä haastateltava on kyselylomakkeessa olevista aiheista? i. Oliko kaikki aiheet tarpeellisia? ii. Mikä aihe nousi esille hyödyllisenä? iii. Onko kaikki aiheet tarpeellisia ohjelmointityötä ajatellen? iv. Olisiko lomake kaivannut lisää jostain aiheesta tai puuttuiko jokin aihe kokonaan? (d) Mitä mieltä haastateltava on vihreää ohjelmistokehitysprosessia käsittelevistä kysymyksistä ja aiheista? (e) Mitä mieltä haastateltava on vihreää elinkaarimallia käsittelevistä kysymyksistä ja aiheista? (f) Mitä mieltä haastateltava on vihreää ohjelmistoa käsittelevistä kysymyksistä ja aiheista? 3. Kysymysten formaatti (a) Onko kysymystenasettelu selkeä? (b) Minkälaiset kysymykset haastateltava kokee hyvänä? (c) Onko kieliasu ymmärrettävää? 4. Kyselylomakkeen ulkoasu (a) Mitä mieltä haastateltava on kyselylomakkeen ulkoasusta? i. Onko runko selkeä? ii. Erottuvatko aihekokonaisuudet hyvin toisistaan? iii. Eteneekö lomake loogisesti? iv. Onko kyselylomake sopivan pituinen? v. Olisiko hyödyllistä jakaa kyselylomake kahteen tai useampaan osaalueeseen ja vastattavat aihealueet valikoituisivat työntekijän työnkuvan perusteella? 41 5.3 Ensimmäisen iteraation haastattelujen tulokset Ensimmäisen haastattelun tuloksissa käsitellään kyselylomakkeen informatiivisuuteen ja hyödyllisyyteen, aihealueisiin, kysymyksiin, ulkoasuun sekä kieliasuun, termistöön sekä sähköisen kyselylomakkeen toteuttamiseen liittyvät tulokset. 5.3.1 Kyselyn informatiivisuus ja hyödyllisyys Haastattelun aikana kysyttiin haastateltavien mielipidettä liittyen kyselylomakkeen hyödyllisyyteen ja informatiivisuuteen. Haastateltavat olivat sitä mieltä, että kyselylomake on informatiivinen ja ajatuksia herättävä. He kertoivat myös, että kyselylomakkeesta jää mieleen asioita ja se parantaa heidän mielestään ohjelmistokehityksen laatua. "Ihan siis kattavasti tai siis opin ihan tämän kyselylomakkeen perusteellakin uusia asioita varmaankin, että ihan mielenkiintoinen ja kattavan oloinen." "Tää parantaa myös sitä ohjelmistokehityksen laatua sen lopputuloksen laatua, vaikka se pitäisi tulla jo ilman tätäkin." Haastateltavat pitivät kyselylomaketta pääasiassa hyödyllisenä tai osittain hyödyllisenä. Yksi haastateltavista oli sitä mieltä, että kyselylomake ei ole hyödyllinen. "Joo kyllä mä sanoisin, että tää on hyödyllinen just ehkä siitä näkökulmasta, että sellainen tyyppi joka ei ole ihan hirveän paljon miettinyt näitä asioita niin tavallaan tästä niin kun käy aika hyvin ilmi ainakin toi asian kokonaisvaltaisuus..." "Että varmasti uutta tietoa olisi tässä ainakin muutamat termit mitkä on nyt voisi tästä googlettaa, mutta ehkä niitä lukuun ottamatta en nyt nähnyt tätä itselleni silleen hyödyllisenä." 5.3.2 Kyselyn aihealueet Haastateltavat pitivät elinkaarimallia, vihreää ohjelmistoa, ohjelmistokehitysprosessia, dokumentaatioon ja viestintään sekä tehokkuuteen käsittelevien aihealueiden kysymyksiä hyvinä. Työtapoja koskevat kysymykset olivat helposti lähestyttäviä ja 42 nopeita vastattavia sekä testaus- ja ylläpitovaiheen kysymykset helppoja vastattavia. Mittaamiseen liittyvät kysymykset koettiin hankalina vastattavina. "Täälläkin (vihreää ohjelmistoa käsittelevissä kysymyksissä) on tosiaan ihan mielenkiintoisia kysymyksiä." "Sitten tuli näitä vähän hankalampia taas, tähän vihreään ohjelmistoon liittyvät kysymykset ohjelmiston vihreiden mittaaminen..." Haastateltavien kokemukset aiheiden tarpeellisuudesta sekä kattavuudesta vaihtelivat. Haastateltavien mielestä kaikki kyselylomakkeessa olevat aiheet olivat tarpeellisia ja mitään aihetta ei ole tarpeellista poistaa kyselylomakkeesta. "Kyllä juuri näin ja sitten se kokonaisuus ratkaisee, se on hyvä että tää käsittelee näitä asioita niin monesta eri näkökulmasta." Toisaalta erityisen hyödyllistä aihetta kyselylomakkeen kannalta ei ollut. "...en mä ehkä osaa sanoa, että mikä täällä olisi erityisen hyödyllinen..." Ohjelmistokehitysprosessia ja ohjelmiston elinkaarimallia vertailtaessa koettiin ne yhtä tärkeinä tai ohjelmiston elinkaarimalli koettiin parempana. Kaikista aihealueista koettiin olevan kattavasti kysymyksiä. Yksi vastaajista olisi kuitenkin toivonut joihinkin aiheisiin lisätietoa. "Tietyssä mielessä mä ehkä nää elinkaarikysymykset näen silleen geneerisempinä, joka tietyllä tapaa on ehkä ihan hyvä asia, koska geneerisemmät on ehkä sovellettavissa helpommin." "Mutta siis kyllähän se monipuolinen oli ja monelta näkökulmalta sitä asiaa pyörittää, että siinä mielessä ihan kattava mun mielestä." "Pitäisi palata takaisin niihin kysymyksiin, mutta ehkä sellainen fiilis mulla tällä hetkellä, että joistakin asioista tai aiheista olisi voinut olla lisääkin tietoa." 43 Todellisten käytäntöjen kannalta kehittämisvaihetta ja ohjelmistokehitystä koskevat kysymykset olivat oleellisimpia. "No siis varmaan ehkä tottakai itselleni toi kehittämisvaihe tietysti on aina se niin kun kiinnostavin, se on sitä omaa tekemistä eniten." "...niin tavallaan on asioita, joihin mihin me Digiana IT toimittajana, just tässä asiakkuudessa voidaan vaikuttaa, just siihen ohjelmistokehitykseen." Sen sijaan ohjelmistokehitysprosessiin, pariohjelmointiin, tarkistuslistoihin ja testausvaiheeseen liittyvät kysymykset eivät vastanneet oikeita käytänteitä. "Tässä on, esimerkiksi kehittämisvaiheessa, on pariohjelmoinnista kysymys, mä veikkaan, että sitä pariohjelmointia ei välttämättä hirveästi käytetä meillä..." "Ja tuota ehkä sitten toi testaus oli ehkä semmoinen mikä ei sitten itselle ole niin ehkä lähellä." Haastateltavat toivat ilmi joitain kyselylomakkeessa olevia kehitettäviä asioita. Ohjelmistokehitysprosessiin, prosessin mittaamiseen ja elinkaarimallin osuus koettiin raskaana. Ohjelmistokehitysprosessin osuudessa tulisi myös käyttää geneerisempää ilmaisua "iteraatio"sanan "sprintti"sijasta. Sitten toi ohjelmistokehitysprosessiin liittyvät kysymykset, prosessin mittaaminen ja elinkaarimalli niin mä veikkaan, että näissä on aika monta eri vaihtoehtoa, nää voi hidastaa varsinkin tässä kehittämisvaiheessa, niin nää on vähän semmoisia, että näissä varmaan voi energiaa alkaa näitten jälkeen loppumaan. "Siinä mielessä, että ne oli ihan tässä kysymyksessäkin sprinttiin/iteraation, niin voi tietysti ajatella, että iteraatio ei välttämättä aina tarkoita tiettyä yksittäistä sprinttiä vaan jotain iteraatiota." Elinkaarimallia koskevat kysymykset koettiin irrallisina ja pariohjelmointia koskeva kysymys tulisi sijoittaa uudelleen suunnitteluvaiheosioon. 44 "...itselleni nää yksittäiset kysymykset vähän tuntuu irrallisilta (elinkaarimallia käsittelevässä osiossa)." "Tavallaan se (pariohjelmointi) varmaan kuuluisi olla suunnitteluvaiheessa, että tavallaan kun lähdetään sitä ohjelmistoa arkkitehtuuria suunnittelemaan, että otetaanko siinä huomioon." 5.3.3 Kyselyn kysymykset Haastateltavat kokivat kysymykset pääasiassa vaikeina. "Nää oli vähän vaikeita kysymyksiä." Toisaalta haastateltavat kokivat, että kysymykset eivät olleet helppoja eikä vaikeita tai kysymykset olivat helppoja ja vaikeita. "...en oikeastaan osaa nähdä sitä niin, että helppoja tai vaikeita." "... osa oli siis semmoisia, että helpommin saa vastattua ja osa oli sitten, että vähän vaikeampi vastata..." Kaksi haastateltavaa piti kysymyksiä helppoina tai osittain helppoina. Kysymysten vaikeus koettiin riippuvan vastaajan taustasta ja työtehtävistä. Vastauksissa korostui se, että johtotehtävissä työskenteleville ja ohjelmointia osaamattomille henkilöille kysymykset ovat vaikeampia. "... niin sitten mä ajattelin, että jos tavallaan kyselylomakkeeseen vastaa semmoinen management tason henkilö, joka ei ole kauheasti enää kehittäjä, niin nää voi olla vaikeita." Haastateltavat kokivat kysymyksenasettelun jyrkäksi ja ohjailevaksi. "Ja ehkä siitä kyselylomakkeesta, niin tuli semmoinen kovin mustavalkoinen olo sen kanssa, että moneen kysymykseen, että jos kysytään vaan että vastaat a tai b, niin tuli vähän semmoinen fiilis kun aika monestikin tämmöisissä monivalintakysymyksissä, että eikö nyt oikeasti ole mitään välimaastoa, että aika osa oli aika semmoisia omasta näkökulmasta semmoisia äärimmäisyyksiä." 45 "...että nää kysymykset on vähän ehkä ohjailevia, että mä veikkaan, että sillä ei tietämättä mitään aiheesta tästä tulisi ihan kohtalaisen hyvät pisteet." He myös kokivat, että kysymyksenasettelu on osittain epäselvä ja osittain selkeä. "Niinku sanoin, että tuskailin vähän sitä, että mitä tässä pitää vastata, että just se itsessään vai suhteessa johonkin, se tuntui itselleen vähän epäselvältä ja sitten mikä on, puhutaan merkittävästi, niin mikä itseasiassa on merkittävä, et onko mun merkittävä nyt sama kuin kysymyksenasettelijan merkittävä?" Polaariset kysymykset koettiin sopivan joihinkin aiheisiin ja silloin kun kysytään kysymyksiä, joihin on vain yksi oikea vastaus. "Kyllä ne tietyssä asiassa toimii tämmöiset kyllä ei kysymykset." Näiden koettiin olevan herätteleviä sekä nopeampia vastata. Osa polaarisista kysymyksistä oli haastavia ja osa oli helppoja vastattavia. Näiden kysymysten koettiin olevan myös johdattelevia. "Siis siinä mielessä, että tavallaan näihin on se teknisesti, oli se sitten kyllä/ei tai tommoinen useampi monivalinta, näihin on tosi nopea sinänsä vastata." Ne kyllä/ei kysymykset on ehkä just semmoisia mistä mulla tulee tää ns. johdatteleva fiilis tai semmoinen. Monivalintakysymyksiä pidettiin loogisina ja helppoina vastata, mutta haastavina. "No siis joo ihan niin kuin kaikki tämmöiset kyselyt missä on monivalintoja (on loogisia ja helppoja vastata)." "...useimmiten noi missä on sitten enemmän näitä sanallisia vaihtoehtoja, niin sitten tietysti niissä joutuu pikkaisen enemmän miettimään itsekin, että mitenköhän se nyt sitten menee." 46 Näissä myös ajateltiin olevan hyvä ohjeistus, mutta monivalintavaihtoehtoja sisältävät kysymykset eivät sovellu hyvin kaikkiin kysymyksiin. Monivalintakysymyksissä olevat käänteiset vastausvaihtoehdot eivät olleet loogisia. "Mutta ei varmaan kaikkia kysymyksiä ei pysty muotoilemaan monivalinnoiksi." "Sitten täällä oli näitä valintakohtia niin niissähän tai aika monessa valintakohdassa on silleen, että on niin kun mun käänteiset valinnat, että tavallaan siinä siis se ei niin kun äkkiseltään tunnu ihan loogiselta, että sulla on niin kun eri valintoja, sitten jokaisesta niistä on vielä käänteinen valinta olemassa." Haastateltavat pitivät siitä, että kyselylomakkeessa oli sekä polaarisia ja monivalintakysymyksiä. Kuitenkin monivalintakysymyksiä tulisi suosia polaaristen kysymysten sijaan. Se, että vapaan tekstin kenttiä ei ole, oli hyvä asia. "Mutta kyllä mä itse tykkäsin just tästä, että tässä on välillä näitä kyllä/eitä ja välillä on sitten näitä tämmöisiä monivalintoja." "Mutta lähtökohtaisesti semmoiset mitkä pystyy muotoilemaan monivalinnoiksi niin." Osa haastateltavista oli sitä mieltä, että "en tiedä-vastausvaihtoehto tulisi lisätä vastausvaihtoehdoksi kysymyksiin ja osa oli sitä mieltä, että sitä ei tulisi lisätä vastausvaihtoehdoksi. "Jos tosiaan tää on enemmän just semmoinen niin kun tietoutta lisäävä niin sitten ehkä se "en tiedä"olisi sinällään ihan hyvä, että jos ei ole tarkoituskaan pitää tätä semmoisena tenttimäisenä, että pitäisi saada ne vastaukset oikein vaan ehkä enemmän just semmoista tietoisuuden tasoa mittavana kyselynä, niin sitten se "en tiedä"olisi silleen hyvä." "Että tosiaan se en osaa sanoa tulee turhan heppoisin perustein sitten, että en mä nyt oikein tiedä tästä aiheesta niin laitan "en osaa sanoa".." Kyselylomakkeessa tulisi vastaamisen jälkeen tarjota oikea vastausvaihtoehto vastaamisen jälkeen. 47 "Musta se on hyvä kognitiivisestikin hyvä sellainen, että sä otat siitä b ja no väärin meni koska a ja c olisi ollut näin, se on musta hyvä." Haastateltavat kertoivat pitävänsä joitain kysymyksiä epäoleellisina, itsestään selvinä tai näiden katsottiin olevan kyseenalaisia hyödyllisyyden kannalta. "Tää (Onko totta, että kestävä kehitys voidaan määritellä tarkoitukseen sopivuudella, reduktiolla ja kauneudella?) on todella hassu silleen, että en nyt silleen ihan suoraan tästä esimerkiksi ymmärrä mitä tässä nyt niin kun tarkoitetaan." "...mä en osaa sanoa onko esim. just tossa, vähän tuollaista niinku agilekulmaan, että onko siitä aidosti tuossa vihreässä ohjelmistokehityksessä hyötyä vai onko siitä hyötyä noin ylipäänsä ohjelmistokehityksessä." Kyselylomakkeeseen tulisi lisätä kysymyksiä liittyen ohjelmiston vihreyden mittaamiseen, hukkaenergian vähentämiseen ja optimointiin, sisäisen kehitysprosessin tehostamiseen, skaalautuvuuteen, itse ohjelmointiin, itse vihreästä ohjelmistokehitykseen sekä pilvipalveluihin. Näiden lisäksi elinkaarimallin ylläpito- ja suunnitteluvaiheen osuuteen tulisi lisätä kysymyksiä. "Tässä on tosi paljon muitakin hyviä tulokulmia, mutta jos nyt yksi pitää valita, niin mä nostan tuon (vihreä ohjelmisto ja vihreyden mittaaminen) sen takia kärkeen, että se on varsinkin teknisille ihmisille helposti lähestyttävin, semmoinen millä pystytään parantamaan asioita mittaamalla niitä." "Ja mun mielestä se kantava teema, mikä tuossa ehkä kuitenkin ehkä tuli sieltä rivien välistä, on nimenomaan se hukkaenergia ja sen tyyppinen optimointi minkä ehkä tiesin jo vähän ennakkoonkin jo, mutta se on mun mielestä ihan semmoinen asia mitä on myös syytä korostaa." 5.3.4 Kyselyn ulkoasu Haastateltavat kokivat kyselylomakkeen etenevän loogisesti ja kyselylomake olevan rakenteeltaan selkeä. Yksi vastaajista ei osannut ottaa kyselylomakkeen loogisuuteen kantaa. Työtapoja koskeva osuus koettiin kuitenkin irralliseksi. 48 "Joo kyllä tää ihan loogisesti mun mielestä etenee." "...se, että eteneekö se jotenkin loogisesti en osaa siihen vastata" Osa haastateltavista piti kyselylomaketta liian pitkänä ja sen pituutta tulisi heidän mukaansa vähentää. Toisaalta kyselylomake koettiin olevan sopivan pituinen. "Aika laaja se oli tietysti, että siinä oli paljon kysymyksiä." "Että varmaan siinä käytännön kyselylomakkeessa, niin voisi olla tiivistettävää" Osa haastateltavista oli sitä mieltä, että kyselylomake voitaisiin jakaa useampaan osa-alueeseen, joihin vastaaminen perustuisi työntekijärooliin. Osa-alueet voisivat jakautua kaikille yhteisiin kysymyksiin, ohjelmistokehittäjille suunnattuihin kysymyksiin sekä ohjelmistokehitysprosessiin liittyviin kysymyksiin. "Tai siis olisi tavallaan esimerkiksi kaikille yhteisiä kysymyksiä ja sitten voisi olla ehkä roolipohjainen jonkinlainen jaottelu tai vaihtoehtoisia." "...mä vähän luulen, että riippuu vähän vastaajan esimerkiksi teknisestä tasosta (pitäisikö kyselylomake jakaa erillisiin osa-alueisiin)" Toisaalta kysymykset voisi jakaa ohjelmistokehittäjille suunnattuihin kysymyksiin sekä syventäviin kysymyksiin. Työtapoihin liittyvät kysymykset voisivat olla kaikille yhteisiä ja elinkaarimallia koskevat kysymykset voisi osoittaa ohjelmistokehittäjille. "Voisi olla, mutta ei ehkä välttämättä enempää tarvitsisi olla kuin kaksi, että tavallaan olisi se itse ohjelmistokehitys niin, jos siihen löytää syventäviä kysymyksiä, niin sitten voisi sitä laajentaa..." "Mun mielestä kaikki nää ylhäällä olevat asiat on yhteisiä ja sitten voi voisi ehkä miettiä vihreään ohjelmistokehitysprosessiin liittyvät." 49 Elinkaarimallia koskevista kysymyksistä vaatimusmäärittelyvaiheen kysymykset voisivat olla kaikille yhteisiä ja suunnitteluvaiheen kysymykset ohjelmistokehittäjille suunnattuja. "...sitten noille tuota kehittäjille olisi vähän semmoiset kehittäjän rooliin sopivammat kysymykset ja sitten olisi tavallaan tämmöiselle prosessihenkilöille, joita voi olla muunlaisia rooleja kuin minä, niin olisi sitten toisen tyyppisiä kysymyksiä." "Että jos haluaa tehdä semmoisen kyselyn et ikään kuin voisi olla teknisille asiantuntijoille, koodareille kohdennettu, silloin siinä voisi olla esimerkiksi just näitä ohjelmiston elinkaarimallin kysymyksiä." Osa haastateltavista oli sitä mieltä, että kyselylomaketta ei tulisi jakaa osa-alueisiin. Tätä perusteltiin erityisesti sillä, että kaikkien ohjelmistokehittäjien tulisi tietää vihreään ohjelmistokehitykseen vaikuttavista asioista kokonaisvaltaisesti. Tätä perusteltiin myös sillä, että erillisistä osioista ei katsottu saavutettavan hyötyä tai niitä ei pidetty tarpeellisina. "Mutta sitten taas, kun katselee täältä vähän pidempää, niin mun mielestä ei tää ole semmoinen, että pystyy (jakamaan osa-alueisiin). Siellä taisi jossain kysymyksessäkin olla vähän semmoista, että ei tätä pysty vaan ottaa semmoista pientä palaa ja olla tyytyväinen elämäänsä, että nyt mä teen vihreätä koodia mun mielestä kyllä tää pitäisi ymmärtää laajemmin, että kyllä sen kehittäjän pitää ymmärtää testauksenkin asiat ja päinvastoin." Yksi haastateltavista ei osannut sanoa pitäisikö kyselylomake jakaa osa-alueisiin. "En tiedä (olisiko hyvä, että kyselylomakkeessa pääsee hyppäämään johonkin tiettyyn aihealueeseen)." Haastateltavien mielestä kyselylomakkeen alkuun tulisi lisätä hakemisto kyselylomakkeen sisällöstä ja kyselylomakkeen alussa tulisi kertoa kyselylomakkeen tarkoituksesta. "...tälleen kun reflektoin tuota vähän taaksepäin niin siitä olisi saanut semmoisen vähän table of contents, mikä tää nyt on, hakemisto/luettelo tyyppisen." 50 (f) Vihreästä ohjelmistokehityksestä vastaava henkilö ei ole vastuussa prosessin ja ohjelmiston vihreyden raportoinnista, vaan vastuu on tiiminjohtajalla / Scrum Masterilla. 6. Onko totta, että ohjelmistokehitysprosessin vihreyttä ei tarvitse arvoida koko prosessin ajan vaan riittää, että prosessin vihreyttä arvioidaan kehittämisvaiheessa sekä testauksen aikana? Kyllä (0) Ei (1) En tiedä (0) Ohjelmistokehitysprosessin vihreyttä tulisi arvioida koko prosessin keston ajan. 7. Alla on kaksi väittämää. Valitse näistä se, joka tukee paremmin vihreää ohejelmistokehitysprosessia. (a) Asiakkaan mukana oleminen vihreässä ohjelmistokehitysprosessissa koko prosessin keston ajan on tarpeellista. (1) (b) Asiakas on mukana vihreässä ohjelmistokehitysprosessissa vain vaatimusmäärittelyn aikana sekä ottamassa vastaan loppuraporttia. (0) Vihreän ohjelmistokehityksen näkökulmasta olisi hyvä, että asiakas on mukana tiiviisti koko ohjelmistokehitysprosessin ajan. Vaatimusmäärittelyn ja suunnittelun lisäksi asiakas on mukana myös jatkuvassa validoinnissa / hyväksymistestauksessa. Asiakas voi olla hyvinkin kiinnostunut ohjelmiston ja ohjelmistokehitysprosessin vihreyttä koskevista tuloksista, joten on perusteltua että myös hän saa raportin vihreyteen liittyvistä mittauksista ja kehityskohteista. Validoinnissa varmistetaan, että ohjelmisto täyttää asiakkaan sille asettamat odotukset. Ketterissä menetelmissä validointi tapahtuu yleensä iteraatioiden päätteeksi. Jatkuvalla validoinnilla tarkoitetaankin sitä, että validointi suoritetaan säännöllisesti, jotta ohjelmistosta tulee tarkoituksenmukainen ja mahdollisiin epäkohtiin päästään puuttumaan mahdollisimman varhaisessa vaiheessa. 8. Alla on sprinttiin / iteraatioon liittyviä väittämiä. Valitse näistä oikeat. (a) Sprintin kestolla ei ole vaikutusta ohjelmistokehitysprosessin vihreyteen. 57 (b) Vihreän ohjelmistokehitysprosessin yksi menestystekijöistä on sprinttien / iteraatioiden pitäminen lyhyinä. (c) Sprintin loppuvaiheessa tulisi pitää vihreää ohjelmistokehitysprosessia ja ohjelmistoa koskeva arviointitapaaminen. (d) Sprintin / iteraation loppuvaiheessa ei tarvitse pitää vihreää ohjelmistokehitysprosessia ja ohjelmistoa koskevaa arviointitapaamista, vaan vihreyttä koskeva arviointi tapahtuu yhdessä sprintin / iteraation arvioinnin yhteydessä. (e) Sprintin / iteraation arvioinnin yhteydessä tulisi käydä läpi myös ohjelmistokehitysprosessin ja ohjelmiston vihreyttä koskevat tulokset. 9. Onko totta, että prosessin vihreyttä dokumentoiva päiväkirjaa voidaan käyttää tukemaan vihreää ohjelmistokehitysprosessia? Kyllä (1) Ei (0) En tiedä (0) Prosessin vihreyttä dokumentoiva päiväkirja on lyhyt dokumentti, johon kirjataan prosessin vihreyttä koskevat arviot sekä parannusehdotukset. Tämän dokumentin päivittäminen on koko tiimin vastuulla. 10. Onko totta, että ohjelmistokehitysprosessin päättyessä pidettävä ohjelmiston vihreyttä koskeva retrospektiivi on hyvä tapa lisätä tulevien projektien vihreyttä? Kyllä Ei Vihreän ohjelmistokehitysprosessin mittaaminen 1. Onko totta, että vihreän ohjelmistokehitysprosessin tärkein mittari on hiilijalanjäljen mittaaminen? Kyllä (1) Ei (0) En tiedä (0) Hiilijalanjälki määrittää, kuinka paljon hiilidioksidia ohjelmistokehitys-, hallinta- tai ylläpitovaihe tuottaa. Tämä on tärkein vihreä mittari ja lopulta kaikki vihreät tekijät pitäisi laskea sen avulla. Hiilijalanjälki on kuitenkin ongelmallinen siinä suhteessa, että sitä voidaan manipuloida esimerkiksi valitsemalla uusiutuvia energianlähteitä sähkön tuottamiseen. 58 2. Onko totta, että ohjelmistokehitysprosessin aikaisen / tuottaman hukan määrää voi myös mitata? Kyllä (1) Ei (0) En tiedä (0) Hukkaa voi myös mitata. Ohjelmistokehitysprosessin aikainen hukka voi olla esimerkiksi energiahukkaa, käyttämätöntä kehitysaikaa tai jotain fyysistä hukkaa. Vihreän ohjelmiston elinkaarimalli Tässä osiossa kysytään vihreän ohjelmiston elinkaareen liittyviä kysymyksiä. Vaatimusmäärittelyvaihe 1. Onko totta, että ohjelmiston vihreyttä koskevat vaatimukset tulisi asettaa tarkkoilla määritelmillä? Kyllä (1) Ei (0) En tiedä (0) Vihreyttä koskevat vaatimukset tulisi asettaa tarkoilla määritelmillä toiveiden, epätarkkojen tai vaillinaisten vaatimusten sijasta. 2. Onko totta, että energiankulutusta koskevat vaatimukset tulisi ilmaista energiankäyttöön liittyvillä ilmaisuilla? Kyllä (1) Ei (0) En tiedä (0) Energiankäyttövaatimukset tulisi ilmaista suoraan energiankäyttöön liittyvillä ilmaisuilla. Energiankäyttöön liittyviä ilmauksia ovat esimerkiksi Energia (E), Energiankulutus (kWh) jne. 3. Onko totta, että epätarkat ja vaillinaiset vaatimukset voivat johtaa esimerkiksi siihen, että joutokäynnin (eng. idle) aikainen energiankulutus huomioidaan paremmin kuin suorituksenaikainen energiankulutus? Kyllä (1) Ei (0) En tiedä (0) Epätarkat ja puutteelliset vaatimusmäärittelyt voivat johtaa siihen, että kaikkia ohjelmiston toimintoja ei huomioida ohjelmistokehityksen aikana. Joutokäynnin aikainen energiankulutus tulee huomioida, mutta huomiota tulee kiiinnittää myös ajonaikaiseen energiankulutukseen. 59 4. Onko totta, että ohjelmistolle asetetut vaatimukset voivat olla ristiriidassa keskenään ja johtaa esimerkiksi siihen, että taloudelliset vaatimukset asetetaan ohjelmiston vihreyttä koskevien vaatimusten edelle? Kyllä Ei 5. Mikä on vihreä arvioija? Valitse oikea. (a) Ohjelmisto, joka arvioi kehitettävän ohjelmiston energiankulutusarvion. (1) (b) Ohjelmisto, joka arvioi ohjelmistokehitysprosessin energiankulutusarvion. (0) (c) Ohjelmisto, joka arvioi kehittävän ohjelmiston hiilijalanjäljen. (0) Vihreä arvioija on ohjelmisto, joka arvoi vaatimusmäärittelyiden perusteella kehitettävän ohjelmiston energiankulutusarvion. Näitä ovat esimerkiksi Green Tracker tai Green Oracle https://dl-acm-org.ezproxy.jyu.fi/doi/pdf/10.1- 145/2901739.2901763 Suunnitteluvaihe 1. Onko totta, että säännöllisten suunnittelukokousten pitäminen on yksi vihreän ohjelmiston menestystekijöistä? Kyllä (1) Ei (0) En tiedä (0) Suunnittelukokouksissa voidaan puuttua edelliskerran jälkeen havaittuihin epäkohtiin, tehostaa prosessia tai lisätä suunnitelmaan toimintoja joilla pyritään parantamaan ohjelmiston laatua ja vihreyttä. 2. Onko totta, että vihreän ohjelmistosuunnitelun näkökulmasta ohjelmistoja suunniteltaessa ei tarvitse ottaa huomioon vanhempia laitteistoja. Kyllä (0) Ei (1) En tiedä (0) Yksinkertainen keino edistää sovelluksen vihreytää on varmistaa ohjelmistojen ydintoimintojen toimiminen myös vanhemmissa laitteistoissa. 3. Alla on suunnitteluvaiheeseen liittyviä väittämiä. Valitse näistä oikeat. (a) Ohjelmistot tulisi suunnitella siten, että ne eivät kuluta ainakaan enempää energiaa kuin edellinen versio. 60 (b) Ohjelmistoja suunniteltaessa ei tarvitse huomioida edellisen version energiankulutusta. (c) Ohjelmistot tulisi suunnitella siten, että ne eivät kuluttaisi ainakaan enempää muistia kuin edellinen versio. (d) Ohjelmistoja suunniteltaessa ei tarvitse huomioda edellisen version muistinkäyttöä. (e) Ohjelmistot tulisi suunnitella siten, että ne eivät kuluttaisi ainakaan enempää kaistanleveyttä kuin edellinen versio. (f) Ohjelmistoja suunniteltaessa ei tarvitse huomioida edellisen version kaistanleveyden kulutusta. 4. Valitse oikea suunnitteluvaihetta koskeva väite. (a) Ohjelmistot tulisi suunnitella siten, että ne eivät kuluta ainakaan enempää energiaa kuin edellinen versio. (1) (b) Ohjelmistoja suunniteltaessa ei tarvitse huomioida edellisen version energiankulutusta. (0) Ohjelmistot tulisi suunnitella siten, että ne käyttävät energiaa mahdollisimman tehokkaasti. Ohjelmistoa suunniteltaessa tulisi ottaa huomioon edellisen ohjelmistoversion energiankulutus ja pyrkiä parantamaan paljon energiaa kuluttavien toimenpiteiden tehokkuutta tai ainakin pyrkiä pitämään uusi ohjelmistoversio mahdollisuuksien mukaan samalla tasolla edellisen version kanssa energiankulutuksen suhteen. 5. Valitse oikea suunnitteluvaihetta koskeva väite. (a) Ohjelmistot tulisi suunnitella siten, että ne eivät kuluttaisi ainakaan enempää muistia kuin edellinen versio. (1) (b) Ohjelmistoja suunniteltaessa ei tarvitse huomioda edellisen version muistinkäyttöä. (0) Muistin käyttäminen käyttää myös energiaa. Uutta ohjelmistoversiota suunniteltaessa tulisi ottaa huomioon ohjelmiston muistin käyttö ja pyrkiä vähentämään turhaa muistinkäyttöä tai ainakin pitämään muistin käyttö mahdollisuuksien mukaan samalla tasolla edellisen version kanssa. Muistin käyttöä suunniteltaessa tulisi huomioida myös datan siirtelystä aiheutuvat kus- 61 tannukset. Jos datan siirtelyä ei voi välttää, sen voi yrittää ajoittaa sellaisiin ajanjaksoihin jolloin voidaan esimerkiksi hyödyntää enemmän vihreää sähköä ja pienentää siten hiilidioksidipäästöjä. 6. Valitse oikea suunnitteluvaihetta koskeva väite. (a) Ohjelmistot tulisi suunnitella siten, että ne eivät kuluttaisi ainakaan enempää kaistanleveyttä kuin edellinen versio. (1) (b) Ohjelmistoja suunniteltaessa ei tarvitse huomioida edellisen version kaistanleveyden kulutusta. (0) Suurten tietomäärien siirtäminen kuluttaa myös energiaa. Ohjelmistoja suunniteltaessa tulisi ottaa huomioon tietoliikenneyhteyksien käyttäminen ja huomioida kuinka usein ja paljon tietoa siirretään. 7. IoT-laitteiden (eng. IoT-devices) suunnittelussa ja toteutuksessa on paljon hyviä resursseja säästäviä periaatteita, joita voidaan hyödyntää myös muussa ohjelmoinnissa. Valitse näistä oikeat. (a) Ohjelmistot suunnitellaan siten, että ne eivät kulutua virtaa jatkuvasti. (1) (b) Ohjelmistot suunnitellaan siten, että ne eivät käytä jatkuvaa tietoliikenneyhteyttä. (1) (c) Ohjelmistot pyritään suunnittelemaan siten, että ne välttävät ylimääräistä muistinkäyttöä. (1) (d) Ohjelmistot pyritään suunnittelmaan siten, että ne käyttävät mahdollisimman tehokkaita algoritmeja. (1) IoT-laitteet suunnitellaan siten, että ne kuluttavat virtaa vain jaksottain pyrkimyksenä säästää rajallisia energiaresursseja. IoT-laitteet suunnitellaan siten, että tietoliikenneyhteyksiä käytetään vain tarvittaessa ja lähettämiseen käytetään mahdollisimman vähän energiaa. IoT- laitteet saattavat kerätä suuren määrän dataa, mutta sitä esikäsitellään ja vain kaikista oleellisin tieto lähetetään eteenpäin. IoT-laitteet suunnitellaan siten, että rajallista muistikapasiteettia käytetään vain tarvittaessa ja turhan tiedon säilyttämistä vältetään. IoT-laitteet suunnitellaan siten, että algoritmit käyttävät mahdollisimman vähän energiaa. Näin säästetään IoT-laitteiden rajallisia energiaresursseja. 62 Kehittämisvaihe 1. Valitse oikeat väitteet koskien pariohjelmointia. (a) Pariohjelmointi voi vähentää yksinkertaisten tehtävien suorittamiseen käytettävää aikaa. (b) Pariohjelmointi voi lisätä yksinkertaisten tehtävien suorittamiseen käytettävää aikaa. (c) Pariohjelmointi helpottaa monimutkaisten tehtävien ratkaisemista. (d) Pariohjelmointi vaikeuttaa monimutkaisten tehtävien ratkaisemista. (e) Pariohjelmoinnilla voidaan ratkaista monimutkaisia tehtäviä laadukkaammin. (f) Pariohjelmoinnilla monimutkaisten tehtävien ratkaisut ovat usein huonolaatuisia. 2. Voidaanko uudelleenkäytettävällä koodilla vähentää energiankulutusta ja hiilidioksidipäästöjä? Kyllä (1) Ei (0) En tiedä (0) Uudelleenkäytettävän koodin kirjoittaminen vähentää kehitystyöhön käytettävän ajan määrää ja siten se vähentää myös energiankulutusta ja hiilidioksidipäästöjä. 3. Valitse oikeat väitteet koskien komponenttipohjaista kehitysstrategiaa. (a) Komponenttipohjainen kehitysstrategia vähentää ajankäyttöä ja kustannuksia prosessissa. (b) Komponenttipohjainen kehitysstrategia lisää ajankäyttöä ja kustannuksia prosessissa. (c) Komponenttipohjainen kehitysstrategia mahdollistaa ohjelmiston osien uudelleenkäytön. (d) Komponenttipohjainen kehitysstrategia estää ohjelmiston osien uudelleenkäytön. (e) Komponenttipohjaisen ohjelmiston refaktoroinnon avulla voidaan selkeyttää ja tehostaa ohjelmistoa. 63 (f) Komponenttipohjaisen ohjelmiston tehostaminen refaktoroinnin avulla on mahdotonta. 4. Valitse oikea komponenttipohjaista kehitysstrategiaa koskeva väite. (a) Komponenttipohjainen kehitysstrategia vähentää ajankäyttöä ja kustannuksia prosessissa. (1) (b) Komponenttipohjainen kehitysstrategia lisää ajankäyttöä ja kustannuksia prosessissa. (0) 5. Valitse oikea komponenttipohjaista kehitysstrategiaa koskeva väite. (a) Komponenttipohjainen kehitysstrategia mahdollistaa ohjelmiston osi- en uudelleenkäytön. (1) (b) Komponenttipohjainen kehitysstrategia estää ohjelmiston osien uudelleenkäytön. (0) 6. Valitse oikea komponenttipohjaista kehitysstrategiaa koskeva väite. (a) Komponenttipohjaisen ohjelmisto refaktoroinnon avulla voidaan selkeyttää ja tehostaa ohjelmistoa. (1) (b) Komponenttipohjainen ohjelmisto tehostaminen refaktoroinnin avulla on mahdotonta. (0) Testausvaihe 1. Onko totta, että testitapausten suorittaminen testausstrategian mukaisesti vähentää energiankulutusta ja parantaa testauksen laatua? Kyllä (1 Ei (0) En tiedä (0) 2. Onko totta, että jatkuvan integraatioympäristön (eng. continuous integration) testipakettiin ei voi sisällyttää energia- ja suorituskykymittauksia? Kyllä (0) Ei (1) En tiedä (0) Jatkuvan integraatioympäristön testipakettiin voidaan sisällyttää myös energia- ja suorituskykymittauksia. Nämä tulokset voidaan näin toimittaa yhdessä muiden testitulosten kanssa kehittäjille sekä asiakkaalle. 64 3. Onko totta, että raakaan voimaan (eng. brute force) perustuva testaus korreloi suoraan energiankulutuksen kanssa. Kyllä (1) Ei (0) En tiedä (0) Raakaan voimaan perustuva testaus korreloi energiankulutuksen kanssa. Mitä enemmän raakaan voimaan perustuvaa testausta, sitä enemmän testaus kuluttaa energiaa. Ylläpitovaihe 1. Onko totta, että ylläpitovaiheen vihreyteen liittyvät asiat tulisi ottaa huomioon jo tuotteen suunnittelu- ja kehittämisvaiheessa? Kyllä (1) Ei (0) En tiedä (0) Ylläpitovaiheeseen liittyvät asiat tulisi ottaa huomioon ja tuotetta suunniteltaessa ja kehittäessä. Näissä vaiheessa voidaan huomioida esimerkiksi järjestelmän tuki- ja konfigurointitehtävät. 2. Onko totta, että ylläpitovaihe ei ole merkittävässä osassa ohjelmiston vihreyttä arvioitaessa? Kyllä (0) (1) En tiedä (0) Tuotteen hiilijalanjälki määritetään ohjelmistokehityksen, hallinnan ja ylläpitovaiheen aikaisen hiilidioksidipäästöjen avulla. Kaikki ohjelmiston ylläpitotoimet katsotaan tuoreeksi kehitystyöksi ja johtavat koko ohjelmiston elinkaariprosessin eli SDLC-prosessin toistamiseen. 3. Onko totta, että ylläpitovaiheen vihreyttä voidaan kasvattaa tarjoamalla käyttäjille energiansäästöohjeita sekä tapoja säätää ohjelmiston toimintaa energiaystävällisemmäksi? Kyllä (1) Ei (0) En tiedä (0) Ohjelmiston käyttämän energian määrää voidaan vähentää tarjoamalla käyttäjille energiansäästöohjeita. Tämän lisäksi ohjelmiston tulisi olla rakennettu sellaiseksi, että käyttäjät voivat säätää ohjelmiston toimintoja tarpeidensa mukaan siten, että se kuluttaa vähemmän energiaa. Esimerkiksi käyttäjä voi säästää energiaa estämällä mainokset. 65 4. Onko totta, että vain osa refaktorointitekniikoista vähentää ohjelmiston energiankulutusta? Kyllä (1) Ei (0) En tiedä (0) Vain osa refaktorointitekniikoista vähentää myös ohjelmiston energiankulutusta. Ohjelmiston refaktorointitekniikkaa valitessa tulisi ottaa huomioon muiden laatutekijöiden lisäksi myös energiankulutuksen väheneminen. 5. Onko totta, että ohjelmiston käytöstä poistamisen aikana ei voida kiinnittää huomiota vihreisiin näkökulmiin? Kyllä (0) Ei (1) En tiedä (0) Ohjelmiston käytöstä poistamisen aikana voidaan ottaa huomioon esimerkiksi tiedostojen kierrätys tai niiden poistaminen kokonaan. Vihreä ohjelmisto Ohjelmiston vihreyden mittaaminen 1. Onko totta, että vihreä ohjelmisto säästää resursseja ja vähentää hukkaa? Kyllä Ei 2. Alla on listattu asioita, joilla mitataan ohjelmiston tehokkuutta. Valitse näistä oikeat. (a) CPU-intensiteetti (1) (b) Muistin käyttö (1) (c) Perifeerinen intensiteetti (1) (d) Joutokäynti (1) (e) Heijastuskyky (1) CPU-intensiteetillä mitataan kuinka monta CPU-jaksoa ohjelmisto kuluttaa. Jokaisen syklin vaatima energia on mitattavissa ja mukautettavissa muihin mittareihin. Muistin käytöllä voidaan seurata esimerkiksi päämuistin kulutusta. Tämän lisäksi seurataan kuinka muistia käytetään. 66 Sähköinen jäte lisää energiankäyttöä sekä hiilijalanjälkeä, joten sitä voidaan pitää kriittisenä menestystekijänä virheässä ohjelmoinnissa. 3. Onko totta, että sähköistä jätettä syntyy vaatimusmäärittelyvaiheessa esimerkiksi silloin, kun vaatimukset ovat kirjattu virheellisesti ja ne eivät vastaa asiakkaan vaatimuksia? Kyllä (1) Ei (0) En tiedä (0) Virheelliset vaatimukset johtavat siihen, että koodia joudutaan kirjoittamaan uudestaan vastaamaan asiakkaan vaatimuksia. Se voi johtaa myös turhien ominaisuuksien toteuttamiseen ohjelmistossa. 4. Onko totta, että monimutkainen koodi ja dokumentaatio lisäävät sähköistä jätettä? Kyllä (1) Ei (0) En tiedä (0) Monimutkainen koodi ja monimutkainen sekä liian yksityiskohtainen dokumentaatio lisäävät sähköistä jätettä. 5. Onko totta, että ohjelmoijan puutteelliset taidot lisäävät sähköistä jätettä? Kyllä (1) Ei (0) En tiedä (0) Ohjelmoijan puutteelliset taidot lisäävät sähköisen jätteen määrää. Parhaiten sähköisen jätteen määrää voidaan vähentää toimimalla sovittujen mallien mukaisesti aluste lähtien. Loppuviesti Pääsit loppuun! Hienoa! Toivottavasti löysit kyselystä uusia ajatuksia ja idoita! Loppujen lopuksi vihreässä ohjelmoinnissa on paljon sellaista, jota toteutetaan jo sellaisenaan tämän hetkisessä ohjelmistokehityksessä. Vihreä ohjelmisto kuitenkin vaatii sen, että vihreät näkökulmat otetaan huomioon ohjelmiston elinkaaren jokaisessa vaiheessa ja viedään hyväksi havaittuja asioita vielä pidemmälle. Lisäksi ohjelmisto ja ohjelmistokehitysprosessi vaatii kriittistä tarkastelua ja halua muuttaa epäekologisia toimenpiteitä enemmän ekologisiksi. 73 6 Toinen iteraatio Tässä luvussa esitetään toisen iteraation kulku. Toisen iteraation tavoitteena oli kerätä palautetta kyselyn toisesta versiosta ja hyödyntää tätä palautetta kyselyn kolmatta versiota kehittäessä. 6.1 Toisen iteraation kulku Tulosten perusteella kyselyn toisessa versiossa aihealueita tulisi muokata siten, että loppuyhteenvetoon lisätään linkkejä sivustoille, joista saa lisäinformaatiota vihreästä ohjelmoinnista. Tämän lisäksi loppuyhteenvetoa kehitetään siten, että se antaa kyselyn tekijälle palautetta siitä, millä kypsyystasolla hän on vihreän ohjelmointiosaamisen suhteen. Kyselyn kysymykset käydään läpi siten, että yli neljä vastausvaihtoehtoa sisältävistä kysymyksistä poistetaan yli menevät vastausvaihtoehdot. Tästä esimerkki kuvassa 6.1. Samoin poistetaan sellaiset kysymykset, jotka ovat liian samankaltaisia jonkin toisen kysymyksen kanssa tai ovat muuten epäoleellisia eivätkä tuo siten lisäarvoa kyselyssä. Tällaisten kysymysten poistamisella pystytään myös lyhentämään kyselyä kuudestakymmenestä kysymyksestä viiteenkymmeneenviiteen kysymykseen. Kyselyn loppuun lisätään taustakysymyksiä ja esiintuotujen kysymysten kysymyksenasettelua tarkistetaan yksiselitteiseksi sekä kirjoitusvirheet korjataan. Kyselyä ei jaeta roolipohjaisesti eri osioihin, koska työntekijöiden kokonaisvaltainen tuntemus ohjelmistoon vihreyteen vaikuttavista tekijöistä koettiin tärkeäksi asiaksi. Kyselyyn lisätään mahdollisuus palata takaisinpäin, jotta kyselyyn vastaava voi lukea informatiiviset osiot uudelleen niin halutessaan. Samoin vastaamisen aikaisia toimintoja muutetaan niin, että vastaaja ei voi siirtyä eteenpäin ennen kuin on checkbox-kysymyksissä vastannut kaikkiin tarvittaviin kohtiin. 74 Kuva 6.1: Esimerkki monivalintakysymyksestä. Informatiiviset osiot asetetaan kyselyssä korostetummin esille isontamalla fonttikokoa sekä asettamalla informatiivisen osuuden teksti kehyksen sisään. Aihealueiden vaihtumista korostetaan isontamalla aihealueen otsikon fonttikokoa. Informatiiviset osuudet värikoodataan siten, että oikeasta vastauksesta teksti esitetään vihreällä värillä vihreän kehyksen sisällä. Oikeasta vastauksesta ja infotekstistä esimerkki kuvassa 6.2. Väärästä vastauksesta teksti esitetään punaisella värillä punaisen kehyksen sisällä. Esimerkki väärästä vastauksesta ja infotekstistä kuvassa 6.3. "En tiedä-vastauksen teksti esitetään oranssilla värillä oranssin kehyksen sisällä. Tästä esimerkki kuvassa 6.4. Ensimmäisessä kysymyksessä on poikkeuksena sininen osio, jossa kerrotaan kaikkien vastausten olevan oikein. 75 Kuva 6.2: Esimerkki "Oikein-vastauksesta. Kuva 6.3: Esimerkki "Väärin-vastauksesta. Kyselyn termit tarkistettiin ja termejä täsmennettiin tarvittavilta osin. Vastaamisen jälkeen esitettävistä informatiivisista osuuksista "En tiedä-vastauksen teks- 76 ti muutetaan neutraaliksi sekä kaikkiin kysymyksiin lisätään tarvittaessa puuttuva informatiivinen osuus. Kuva 6.4: Esimerkki "En tiedä-vastauksesta. Opetusmateriaaliin ja tarkistuslistaan liittyviä asioita ei kehitetä tässä tutkimuksessa eteenpäin, koska nämä aiheet vaatisivat oman tutkimustyön toteuttamisen. Kyselyyn ei myöskään lisätä faktoihin perustuvia laskelmia, koska näitä ei kirjallisessa osuudessa tullut esille. 6.2 Toisen haastattelun teemahaastattelun runko Tässä osassa esitetään toisen teemahaastattelun runko. Haastattelun teemat toistavat ensimmäisen haastattelujen teemoja, mutta tarkentavia kysymyksiä on suppeammin. 1. Taustatiedot: (a) Onko haastateltava tutustunut etukäteen sähköiseen kyselyyn? 2. Kyselylomakkeen sisältö (a) Mitä mieltä haastateltava on kyselylomakkeesta? (b) Mitä mieltä haastateltava on kysymyksistä? 77 (c) Mitä mieltä haastateltava on kyselyn informatiivisista osuuksista? (d) Mitä mieltä haastateltava on kyselylomakkeessa olevista aiheista? 3. Kysymysten formaatti (a) Mitä mieltä haastateltava on kysymyksenasettelusta? (b) Mitä mieltä haastateltava on vastausvaihtoehdoista? 4. Kyselylomakkeen ulkoasu (a) Mitä mieltä haastateltava on kyselylomakkeen ulkoasusta? 6.3 Toisen iteraation haastattelujen tulokset Toisen haastattelun tuloksissa käsitellään haastateltavien yleistä mielipidettä kyselystä, kysymyksistä, kysymyksenasettelusta ja vastausvaihtoehdoista, ulkoasusta, pituudesta sekä informatiivisista osuuksista. 6.3.1 Haastateltavien yleinen mielipide kyselystä Haastateltavat pitivät kyselyä yleisesti hyvänä ja kattavana. Heidän mielestään kysely tuntui tarkistuslistalta tai opetusmateriaalilta sekä formaattina hyvältä tällaiseen tarkoitukseen. "On tosi kattava ja monipuolinen ja herättää varmasti miettimään kun noita väittämiä alkaa pohtimaan." "...mutta kaikin puolin tykkäsin tästä, että tää oli tällainen, niin kun tämä opetti samalla kun siihen vastattiin niin siinä tuli semmoista, voiko sitä sanoa jopa vuorovaikutusta?" Kyselyyn toivottiin luettavaksi ennakkomateriaalia ennen kyselyn läpikäymistä. "Ja ehkä just muutenkin silleen vaikka nää tässä selittää sitten auki itseään, niin ehkä silti pitäisin tehokkaimpana sitä, että sitä olisi jonkinlainen pieni opetusmateriaali olemassa..." 78 Loppuyhteenvetoa toivottiin kehitettävän siten, että se kertoisi vastaajalle hänen oman tasonsa vihreän ohjelmoinnin suhteen sekä linkkejä lisäinformaation hankkimista varten. "...voisiko siitä olla jotenkin johdettavissa jotain lisää tavallaan, että millä vaikka kypsyystasolla mä nyt oon tässä vihreässä ohjelmistokehitysprosessissa vaikka tai onko jotain mihin voisi kiinnittää huomiota jatkossa..." Kyselyn hyödyntäminen sellaisenaan töitä tehdessä koettiin hankalana ja haastateltavat toivatkin esille, että kyselyn sisältämä tieto olisi helpompi hyödyntää tarkistuslistan muodossa. "Mutta se, että koska tässä oli tosi paljon hyödyllisiä juttuja, niin sitten taas, jos joutuisi klikkailemaan tätä kyselyä läpi ja muistelemaan, että mitäs kaikkea tässä pitikään ottaa huomioon, niin sehän ei ole kätevää sitten taas sitten kun tekee oikeita töitä totta." "Tuli ehkä semmoinen olo myös, että jos tän ensin tekee ja sitten alkaisi tällainen vihreän ohjelmistokehityksen projekti sen jälkeen, niin sitten olisi just kiva saada tästä jonkinlainen checklisti materiaali mitä sitten olisi helppo hyödyntää siellä tämän, kun on tämän ensin tehnyt tämän kyselyn, niin sitten voisi hyödyntää siinä oikeasti niitä töitä tehdä." 6.3.2 Kyselyn kysymykset Kysymykset koettiin hyvinä, selkeinä, kuvaavina ja informatiivisina. "Ne (kysymykset) on kyllä ihan hyviä." "Ne (kysymykset) on tosiaan siis semmoisia, että sieltä uutta informaatiotakin tulee." Osa kysymyksistä koettiin keskittymistä vaativana ja näihin vastaaminen vei enemmän aikaa kuin muihin kysymyksiin vastaaminen. "Että niitä oli ehkä kaksi semmoista kysymystä, niin ne on ehkä se ainoa mikä jäi semmoiseen, että nää on vähän pitkiä, nää vaatii keskittymistä..." 79 Osassa kysymyksissä koettiin olevan liikaa vastausvaihtoehtoja ja samalla myös liikaa informaatiota kerralla. "...mut ihan siellä loppusuoralla, on varmaan semmoinen missä voisiko olla 7-8:kin (vastausvaihtoehtoa) jopa?" "Muutama kysymys niistä, mulla ei ole numeroa, jäi vähän semmoinen informaatioähkyä ne oli niitä kysymyksiä missä oli tosi paljon vastausvaihtoehtoja." Kuva 6.5: Esimerkki monivalintakysymyksestä. Haastateltavien mielestä joitain kysymyksiä voisi poistaa kyselystä. Tällaisten kysymysten koettiin olevan toistoa aikaisemmista kysymyksistä tai muuten epäolennaisia. "...sanotaan ennen puolta väliä oli varmaan olisiko ollut 34. kysymys, että vähän täysin samaa aihepiiriä uudelleen ja uudelleen. Mietin sitä, että voiko niitä jotenkin yhdistää?" Kyselyssä toivottiin olevan taustakysymyksiä. "mutta ehkä itse asiassa tilastollisesti varmaan voisi olla hyvä kyllä saada se henkilön 80 rooli tohon, että missä roolissa toimii, niin sanottuna taustakysymyksenä, varmaan muunkinlaisia taustakysymyksiä tässä on ehkä hyvä olla." 6.3.3 Kysymysten kysymyksenasettelu ja vastausvaihtoehdot Kysymysten kysymyksenasettelu koettiin hyvänä ja käänteisen kysymyksenasettelun koettiin pitävän vastaajan hereillä kyselyn aikana. Kysymystenasettelun koettiin olevan myös edelleen tenttimäisiä, mutta vastausten ja lisäinformaation saaminen vastaamisen jälkeen pehmensi kyselyä. "...että se tavallaan kysymyksenasettelu käännetään välillä toisinpäin, niin mun mielestä se on kuitenkin ihan hyvä, että se pitää sen kyselyn täyttäjä vähän hereillä siinä sitten joo." Vastausvaihtoehdot koettiin pääasiassa hyvänä. "En tiedä-vastausvaihtoehto jakoi mielipiteitä ja sitä pidettiin toisaalta tarpeellisena ja toisaalta sille ei nähty tarvetta. "Kun itse tein omasta näkökulmasta, niin kyllä mä useampaan vastasin En tiedä ja mun mielestä se on ihan hyvä, että tavallaan ei aivan oikeasti nyt oikein tiedä tai näin, että se on ainakin hyvä, että siellä on sellainen vaihtoehto olemassa." "No sekin ("En tiedä-vastaus) on tietysti validi vastaus varmaan sitten, että ehkä sitä en ymmärtänyt, että miksi se siellä on, mutta en siihen koskenut niin se ei sillä ei koskettanut mua." Joitakin kysymyksiä tulisi muuttaa, koska näiden kysymysten kysymyksenasettelu antaa virheellisen kuvan käsiteltävänä olevasta asiasta. "Mutta joo tosiaan siinä (kysymys nro. 14) ehkä se kysymyksenasettelu on semmoinen mitä voisi varmaan vielä viilata, koska se nyt antaa vähän liian semmoisen, että yksiselitteinen vähentäminen on hyvä ratkaisu." 81 6.3.4 Kyselyn ulkoasu Kyselyn ulkoasua pidettiin hyvänä ja selkeänä. "Se oli ihan hyvä aika silleen niin kun miellyttävää tosiaan, että ei niin kun oikeastaan mitään suurempaa kritiikkiä." Kyselyn yläosassa sijaitseva kyselyn etenemisestä kertova indikaattori koettiin positiivisena asiana. "Että mä tykkäsin siitä kun se oli se progressbar ylhäällä ja tiesin aika lailla just silleen että missä kohtaa ollaan menossa ja paljon jäljellä." Kyselyn toiminnallisuuteen liittyviä kehittämiskohteita olivat mahdollisuus palata kyselyssä takaisinpäin sekä checkbox-kysymyksissä tulisi varmistaa se, että vastaaja ei siirry liian aikaisin seuraavaan kysymykseen. "Joo yksi semmoinen mikä tuli ainakin mieleen oli toi, että siinä kyselyssä ei päässyt klikkaamaan takaisinpäin niihin vanhoihin vastauksiin, että siinä mielessä se on huono, että jos haluaisi lukea vaikka uudelleen jonkun tekstin sieltä niin sitten siihen ei pääse ja esimerkiksi just jos vahingossa klikkaan liian nopeasti eteenpäin niin silloin sitten tosiaan ei pääse tarkistamaan sitä." "Joo sitten se oli ne monivalinta tai ne semmoiset checkbox valittavat, niin niissä oli tosiaan se huomio, että kun tsekkaa sen ensimmäisen checkboxin, niin sehän antaa sitten sen "vastaus on oikein"tyyppisen palautteen, niin siinä kyselyn käyttäjälle voi tulla se fiilis että "OK tää kysymys on nyt taputeltu"ja sitten se voi painaa sen jälkeen next ja sitten se lomake ei tavallaan anna siihen mitään palautetta, että siinä voi jäädä ihmisiltä mahdollisesti lukematta vaihtoehtoja." Aihealueiden vaihtumista ja informatiivisia osuuksia haluttiin korostettavan. "...että kun tulee niitä vastauksia sitten siihen tai niitä selityksiä näihin vastauksiin, niin ne saisi ehkä olla mun mielestä jotenkin selkeämmin jonkun vaikka freimin sisässä tai jollain vähän eri värikorotuksella, että ne huomaa silleen paremmin, että ne siihen ilmestyy." Haastateltavat olivat pääasiassa sitä mieltä, että kyselyä ei ole tarpeellista jakaa 82 Ylläpitovaihe 1. Valitse oikea refaktorointia koskeva väite. (a) Refaktoroinnin avulla voidaan selkeyttää ja tehostaa ohjelmistoa. (1) (b) Refaktoroinnin avulla voidaan selkeyttää ohjelmistoa, mutta ei tehostaa. (0) Komponenttipohjaisen ohjelmiston refaktoroinnin avulla voidaan selkeyttää ja tehostaa ohjelmistoa. Refaktorointi tarkoittaa vihreässä asiayhteydessä lähdekoodin energiatehokkuuden optimointia muuttamatta lähdekoodin rakennetta. Refaktoroinnilla tarkoitetaan prosessia, jossa lähdekoodin sisäistä rakennetta muutetaan siten, että toiminnallisuus kuitenkin säilyy ennallaan. Muutokset voivat kohdistua esimerkiksi koodin luettavuuteen tai komponenttien työnjaon selkeyttämistä. Refaktoroinnin aikana ei lisätä ominaisuuksia tai pyritä lähtökohtaisesti korjaamaan ohjelmointivirheitä. Vihreä ohjelmisto Ohjelmiston vihreyden mittaaminen 1. Alla on listattu asioita, joilla mitataan ohjelmiston tehokkuutta. Valitse näistä oikeat. (a) CPU-intensiteetti (1) (b) Muistin käyttö (1) (c) Perifeerinen intensiteetti (1) (d) Joutokäynti (1) (e) Heijastuskyky (1) CPU-intensiteetillä mitataan kuinka monta CPU-jaksoa ohjelmisto kuluttaa. Jokaisen syklin vaatima energia on mitattavissa ja mukautettavissa muihin mittareihin. Muistin käytöllä voidaan seurata esimerkiksi päämuistin kulutusta. Tämän lisäksi seurataan, kuinka muistia käytetään. 89 Perifeerisellä intensiteetillä seurataan sitä, kuinka paljon oheislaitteita käytetään. Tämä voidaan arvioida esimerkiksi laskemalla montako pyyntöä ohjelmisto tekee oheislaitteille ja mitä resursseja tarvitaan. Toinen yksinkertainen tapa on laskea oheislaitteen energiantarve. Joutokäynti ei koskaan ole hyödyllistä ja sillä hukataan resursseja. Joutokäynnillä siis seurataan, kuinka paljon ohjelmisto on käyttämättömänä. Heijastuskyvyllä tarkoitetaan sitä miten ohjelmiston käyttäytyminen heijastuu muihin toimintoihin. Esimerkiksi muistiin perustuva ohjelmisto käyttää resursseja yleensä silloin kun tietokone käynnistetään. Tämä hidastaa tietokoneen käynnistymistämistä ja siitä voi seurata se, että tietokoneen käyttäjä jättää tietokoneen herkemmin päälle. 2. Onko totta, että kahta ohjelmistoa ei voida verrata kestävän kehityksen näkökulmasta, jos ne eivät ole samanlaisissa ohjelmistojärjestelmissä? Kyllä (1) Ei (0) En tiedä (0) Järjestelmäkutsujen profiilin on osoitettu korreloivan ohjelmiston energiankulutuksen kanssa. Tämän takia järjestelmäkutsujen profiloinnilla voidaan epäsuorasti arvioida esimerkiksi ohjelmistoon tehtävien muutosten yhteydessä aiheuttavatko muutokset energiankulutuksen kasvua. Järjestelmäkutsujen profilointiin on kehitetty yksinkertaisia työkaluja ohjelmistokehittäjien avuksi. Pilvipalvelut ja reunalaskenta 1. Valitse oikea pilvipalvelujen hyödyllisyyttä koskeva väite. (a) Pilvipohjaisissa palveluissa resursseja käytetään pyynnöstä, joka mahdollistaa isossa mittaskaalassa datakeskusten energiatehokkuuden optimoinnin. (1) (b) Pilvipohjaisissa palveluissa resursseja käytetään pyynnöstä, joka mahdollistaa asiakaslaitteiden energiatehokkuuden optimoinnin. (0) Pilvipohjaisissa palveluissa resursseja käytetään pyynnöstä, joka mahdollistaa isossa mittaskaalassa datakeskusten energiatehokkuuden optimoinnin. Pilvipalvelut mahdollistavat esimerkiksi hyödyllisyyslaskennan, joka on esimerkki pyynnöstä tapahtuvasta laskennasta. 2. Valitse oikea pilvipalvelujen hyödyllisyyttä koskeva väite. 90 (a) Pilvipalveluissa on vähemmän yleiskustannuksia, tehokkaampi skaalautuvuus sekä joutokäyntiä on vähemmän. (1) (b) Pilvipalveluissa on enemmän yleiskustannuksia, mutta tehokkaampi skaalautuvuus sekä joutokäyntiä on vähemmän. (0) Pilvipalveluissa on vähemmän yleiskustannuksia, tehokkaampi skaalautuvuus sekä joutokäyntiä on vähemmän. Näiden asioiden lisäksi pilvipalvelimet voivat hyödyntää tehokkaammin vihreitä energianlähteitä sekä esimerkiksi kerätä laitteistoista vapautuvan hukkaenergian talteen. 3. Valitse oikea pilvipalvelujen hyödyllisyyttä koskeva väite. (a) Datakeskukset voivat tehokkaammin hyödyntää vihreitä energianlähteitä ja laitteiden lämpenemisestä syntyvän hukkaenergian. (1) (b) Datakeskukset hyödyntävät huonosti vihreitä energianlähteitä ja laitteista syntyvää hukkaenergiaa. (0) 4. Pelkästään pilvipalvelujen käyttäminen ei takaa kuitenkaan vihreämpää ohjelmistoa. Mitä ohjelmistokehittäjän tulee ottaa huomioon, jotta pilvipalvelujen käyttämisestä saadaan oletettu hyöty? Valitse oikeat. (a) Ohjelmistoarkkitehtuuri tulee suunnitella pilvipalvelujen käyttöä ajatellen. (1) (b) Datan siirtely tulee optimoida ja kaksoisdata poistaa. (1) (c) Kaksoisdata tulee pyrkiä poistamaan. (1) (d) Ohjelmistokehittäjän tulisi hyödyntää älykästä tietojen pakkaamista datan käyttötiheyteen perustuen. (1) (e) Ohjelmiston tulisi hyödyntää myös palvelitonta laskentaa. (1) (f) Ohjelmiston tulisi hyödyntää Faas-toimintoa (function-as-service). (1) (g) Ohjelmistossa tulisi tarpeen mukaan hyödyntää datan käytön profilointia. (1) Ohjelmistoarkkitehtuuri voi vaatia suuriakin muutoksia. Palveliton laskenta ja Faas-toiminto mahdollistavat resurssien saumattoman skaalautumisen. 91 Datan käytön profiloinnilla ja tekoälypohjaisilla profilointisovelluksilla voidaan löytää käyttäjien toimintamalleja ja säätää sovelluksen toimintaa tarpeen mukaisesti ja lisätä siten tehokkuutta. Ohjelmiston datan käsittely ja siirtely tulisi hoitaa mahdollisimman tehokkaasti. Näillä toimilla pyritään vähentämään varastoitavan datan määrää, laskentaresurssien tarvetta sekä tietoliikenneresurssien tarvetta. Ohjelmistossa tulisi tarpeen mukaan hyödyntää datan käytön profilointia ja älykästä tietojen pakkaamista datan käyttötiheyteen perustuen. Näiden lisäksi pitäisi hyödyntää palvelitonta laskentaa, joka mahdollistaa resurssien saumattoman skaalautumisen. Sähköinen jäte 1. Onko totta, että monimutkainen koodi ja dokumentaatio lisäävät sähköistä jätettä? Kyllä (1) Ei (0) En tiedä (0) Monimutkainen koodi ja monimutkainen sekä liian yksityiskohtainen dokumentaatio lisäävät sähköistä jätettä. Taustakysymykset 1. Koulutus (a) Lukio (b) Ammattikoulu (c) Ammattikorkeakoulu (d) Alempi korkeakoulututkinto (e) Ylempi korkeakoulututkinto (f) Ulkomailla suoritettu tutkinto (g) Muu 2. Sukupuoli (a) Nainen (b) Mies 92 (c) Muu (d) En halua sanoa 3. Ikä (a) Alle 25 (b) 25–34 (c) 35–44 (d) yli 45 Loppuviesti Pääsit loppuun! Hienoa! Loppujen lopuksi vihreässä ohjelmoinnissa on paljon sellaista, jota toteutetaan jo sellaisenaan tämänhetkisessä ohjelmistokehityksessä. Vihreä ohjelmisto kuitenkin vaatii sen, että vihreät näkökulmat otetaan huomioon ohjelmiston elinkaaren jokaisessa vaiheessa ja viedään hyväksi havaittuja asioita vielä pidemmälle. Lisäksi ohjelmisto ja ohjelmistokehitysprosessi vaatii kriittistä tarkastelua ja halua muuttaa epäekologisia toimenpiteitä enemmän ekologisiksi. Sait X pistettä vihreistä työtavoista! 9-10 pistettä = Mahtavaa! Osaat määritellä vihreän ohjelmiston ja tiedät tavallisimmat vihreät työtavat! 4-8 pistettä = Hienoa! Tiedät joitain vihreitä työtapoja ja tiedät suunnilleen, miten vihreä ohjelmisto määritellään. Toivottavasti löysit myös jotain uutta, jota voisit toteuttaa työssäsi! 0-3 pistettä = No höh! Tiedät vielä aika vähän vihreistä työtavoista ja ehkä vihreä ohjelmisto on sinulle uusi asia. Vihreät työtavat ovat melko yksinkertaisia tapoja vähentää energiankulutusta ja hiilidioksidipäästöjä työpaikalla, joten sinulle jäi varmasti mieleen joitain pääkohtia vihreistä työtavoista! 93 Sait X pistettä vihreää ohjelmistokehitysprosessia koskevista kysymyksistä! 6-7 pistettä = Mahtavaa! Tiedät paljon ohjelmistokehitysprosessin vihreyteen vaikuttavista asioista! 3-5 pistettä = Hienoa! Tiedät jo jotain ohjelmistokehitysprosessin vihreyteen vaikuttavista asioista! Toivottavasti löysit jotain uutta, jota voisi ehkä soveltaa seuraavassa projektissa! 0-2 pistettä = No höh! Ohjelmistokehitysprosessin vihreyteen vaikuttavat asiat ovat sinulle varmaan vielä uutta! Helppo tapa aloittaa ohjelmistokehitysprosessin vihreyden parantaminen on esimerkiksi edistää tiimin ja asiakkaan viestintää. Sait X pistettä elinkaarimallia koskevista kysymyksistä! 20-27 pistettä = Vau! Tiedät jo todella paljon vihreän ohjelmiston elinkaarimalliin liittyvistä asioista! Jatka samaan malliin! 10-20 pistettä = Hienoa! Tiedät jo aika paljon vihreän ohjelmiston elinkaarimalliin liittyvistä asioista! Toivottavasti löysit jotain uutta, jota voisi ehkä toteuttaa seuraavassa projektissa! 0-10 pistettä = No höh! Ohjelmiston elinkaarimalliin liittyvät vihreät asiat ovat sinulle ehkä uutta. Elinkaarimallin näkökulmasta vaatimusmäärittely- ja suunnitteluvaiheella on iso vaikutus elinkaarimallin loppuvaiheiden vihreyteen. Voit kiinnittää huomiota esimerkiksi tulevan ohjelmiston virrankulutukseen, muistinkäyttöön, tietoliikenneyhteyksien käyttöön sekä pyrkiä suunnittelemaan tehokkaita algoritmeja. Näillä pääsee jo hyvään alkuun! Sait X pistettä vihreää ohjelmistoa koskevista kysymyksistä! 19-26 pistettä = Mahtavaa! Tiedät jo todella paljon vihreään ohjelmistoon vaikuttavista asioista! Jatka samaan malliin! 94 8-18 pistettä = Hienoa! Tiedät jo aika paljon vihreään ohjelmistoon vaikuttavista asioista! Toivottavasti löysit jotain uutta, jolla voit parantaa seuraavan ohjelmiston vihreyttä! 0-7 pistettä = No höh! Vihreä ohjelmisto taitaa olla sinulle vielä aika uusi asia! Ohjelmistosta voi saada vihreämmän melko yksinkertaisillakin asioilla, kuten esimerkiksi valitsemalla ohjelmiston vaatimusten puitteissa tehokkaimman ohjelmointikielen ja pilveistämällä toimintoja, mutta osa toimenpiteistä voi olla vähän työläämpiä, kuten rinnakkaislaskenta. Helppo tapa aloittaa on esimerkiksi pyrkiä vähentämään ohjelmistoon liittyvää sähköistä jätettä. Sait kyselystä yhteensä X pistettä! 55-70 pistettä = Vau! Tiedät jo todella paljon ohjelmiston vihreyteen vaikuttavista asioista! Olet tainnut ennenkin olla tekemässä vihreitä ja energiatehokkaita ohjelmistoja! 25-54 pistettä = Mahtavaa! Tiedät jo melko paljon ohjelmiston vihreydestä ja siihen vaikuttavista toimenpiteistä. Toivottavasti sait uusia ideoita, joita voisi toteuttaa seuraavassa projektissa! 0-24 pistettä = No höh! Vihreä ohjelmisto taitaa olla sinulle vielä melko uusi asia. Ohjelmiston vihreyteen voidaan vaikuttaa monilla erilaisilla toimenpiteillä ja valinnoilla. Kaikki toimenpiteet eivät sovi kaikkiin projekteihin, mutta useimpia voidaan soveltaa kuitenkin. 95 7 Tulokset Tutkimuksen tavoitteena oli kehittää informatiivinen kysely, jolla voidaan myös mitata ohjelmistokehittäjien tietämystä vihreän ohjelmistokehitysprosessin ja vihreän ohjelmiston tekijöiden suhteen. Lopputuloksena syntynyt sähköinen kysely vastaa tätä tavoitetta. Kehittämisprosessin aikana pystyttiin luomaan informatiivinen kysely, joka koettiin opettavaisena sekä pääasiassa hyödyllisenä. Haastateltavat kokivat, että kysely on hyvä lähestymistapa parantamaan tietoisuutta vihreän ohjelmistokehityksen käytänteistä. Tietämyksen lisäämisen voidaan ajatella olevan hyödyllistä siinäkin mielessä, että jotkin ennestään käytössä olleet vakiintuneet käytänteet tehdä parempia ohjelmistoja tulevat perustelluksi ja paremmin ymmärretyiksi vihreyden kontekstissa. Kysely antaa kokonaisvaltaisen kuvan vihreään ohjelmistoon ja ohjelmistokehitysprosessiin vaikuttavista tekijöistä ja antaa käytännönläheisiä keinoja siihen, miten ohjelmiston ja ohjelmistokehitysprosessin eri osa-alueita voitaisiin tehdä vihreämmin. Kyselyn lopussa vastaajalle esitetään yhteenveto kyselyn tuloksista. Digia Oyj:n Green Code Experttinä toimiva yhteyshenkilön arvio kyselystä oli positiivinen. Yhteyshenkilö piti kyselyä hyödyllisenä. Informatiivinen kysely otetaan käyttöön Digia Oyj:n sisäisessä koulutuksessa Digian omassa Moodle-alustassa. Kyselyä jatkokehitetään Digia Oyj:n omilla resursseilla ja tutkielmaa tullaan mahdollisesti hyödyntämään kokonaisuudessaan koulutusmateriaalin kehittämisessä. Kirjallisuuskatsauksen perusteella pystyttiin selvittämään keskeisimmät vihreän ohjelmistokehityksen käytänteet. Ohjelmiston tuottamaan hiilijalanjälkeen voidaan vaikuttaa ohjelmistokehitysprosessin kautta, jolloin esimerkiksi vihreyttä koskevien huomioiden dokumentoinnilla, lyhyillä iteraatioilla ja asiakkaan tiiviillä mukana ololla voidaan vaikuttaa turhaan käytetyn työajan ja sähköisen jätteen määrään. Ohjelmiston elinkaarimallin kannalta vaatimusmäärittelysekä suunnitteluvaihe korostuvat ohjelmiston vihreyden kannalta. Tässä vaiheessa pitää miettiä mitä ja miten lähdetään kehittämään, jotta ohjelmiston toiminta olisi mahdollisimman optimoitu ja tehokas. Vaatimusmäärittely ja suunnitteluvaiheessa valitut asiat ovat usein sellaisia, joita on vaikea perustavanlaatuisesti muuttaa enää myöhemmissä vaiheissa. Vaatimusmäärittelyvaiheessa tulisi kiinnittää huomiota erityisesti siihen, että asia- 96 kas ja yritys kommunikoivat tehokkaasti, jotta kehitetään varmasti asiakkaan haluamia asioita ja toisaalta, että ei kehitetä turhia asioita. Suunnitteluvaiheessa esimerkiksi arkkitehtuurisuunnittelulla ja energiatehokkaiden kielten valinnalla voidaan vaikuttaa valmistuvan ohjelmiston energiankulutukseen. Huomioitavaa on myös, että pilveistämisellä ja virtualisoinnilla on pystytty saavuttamaan huomattaviakin energiansäästöjä. Tässä vaiheessa pitäisi myös muistaa ottaa huomioon edellisissä projekteissa hyväksi havaitut asiat ja toisaalta välttää huonoiksi todettuja ratkaisuja. Näkemys vihreiden käytänteiden toteutumisesta organisaatiossa vaihteli. Vastaus riippui myös siitä, kuinka pitkä ja laaja työkokemus haastateltavalla oli. Kokeneemmat ohjelmistokehittäjät osasivat nimetä vihreään ohjelmistokehitykseen liittyviä käytänteitä, vaikka vihreys terminä oli kaikille haastateltavalle melko uusi. Näitä olivat esimerkiksi optimointi, vältetään turhaa datan siirtelyä, yritetään tehdä uudelleenkäytettävää koodia ja pyritään muutenkin hyödyntämään resursseja järkevästi. Toisin sanoen vihreät käytänteet toteutuvat osittain organisaatiossa jo ennestään, vaikka haastateltavat eivät pitäneet näitä välttämättä vihreinä käytänteinä. Ja vaikka asioita kyllä tehdään vihreästi jo nyt, kaikki työntekijät eivät tiedä esimerkiksi ohjelmiston energiankulutukseen vaikuttavista asioista tai toimenpiteistä, joilla sitä voitaisiin vähentää. Laaja-alaisin näkemys asiasta oli sellaisilla haastateltavilla, joilla on pitkä työkokemus ohjelmistokehityksestä ja kokemusta useasta ohjelmiston elinkaarimallin vaiheesta. Toisaalta ilmi tuli myös sellaisia asioita, joita organisaatiossa ei ollut vielä käytössä. Tällaisia asioita olivat esimerkiksi tarkistuslistojen käyttäminen tai ohjelmiston energiankäytön mittaamisen automatisoiminen jatkuvan integraatioympäristön avulla. Näin ollen tietämys vihreistä ohjelmistokehitysprosessiin ja ohjelmistokehitykseen liittyvistä käytänteistä lisääntyi ja tutkimuksen tulokset olivat näiltä osin myönteisiä. 97 8 Pohdinta Tutkimuksen tulokset ovat linjassa aikaisempien tutkimusten kanssa. Haastateltavat kertoivat, että haastatteluhetkellä heillä ei ollut vielä käytössä vihreisiin käytänteisiin liittyviä ohjeistuksia. Osa haastateltavista ei esimerkiksi tiennyt, onko toimeksiantajan organisaatiolla vihreyteen tai kestävään kehitykseen liittyvää strategiaa tai onko heillä vihreydestä vastaavaa henkilöä. He kuitenkin suhtautuivat pääasiassa positiivisesti vihreyteen ja ajatukseen toteuttaa vihreämpiä sovelluksia. Tutkimuksen tulokset ovat myös linjassa Ahmad et al. [6] tutkimuksen kanssa siinä, että vihreään ohjelmistokehitykseen liittyvät käytänteet vaihtelivat. Vihreiden käytänteiden hyödyntäminen oli joiltain osin puutteellista. Suhtautuminen vihreyteen oli hyvin käytännönläheistä, myönteistä ja kustannusten hallinnan näkökulmasta ohjailtua. Tämä näkyi esimerkiksi pyrkimyksenä säästää energiaa. Ohjelmistotuotannossa ei myöskään vielä haastatteluhetkellä hyödynnetty esimerkiksi testaamisen aikaisia mittauksia. Olisikin mielenkiintoista tietää, voitaisiinko työntekijöitä motivoida vihreyden edistämiseen esimerkiksi palkitsemisella samalla tavalla kuin palkitaan esimerkiksi kouluttautumisesta tai muista ansioista? Tai pystyttäisiinkö ohjelmiston energiankulutuksen näkyväksi tuomisella paremmin motivoimaan työntekijöitä adaptoimaan energiaa säästäviä tekniikoita omaan työhön? Tutkimus toteutettiin kehittämistutkimuksena ja kyselyn kehittämiseen tarvittava aineisto kerättiin teemahaastattelujen avulla, joten on aiheellista tarkastella tutkimusasetelmaa sekä kehittämistutkimuksen prosessin sekä teemahaastattelun ja sisällönanalyysin kannalta. Tutkimuksen prosessia voidaan arvioida Hevner et al. [21] hyvän suunnittelutieteellisen tutkimuksen tutkimusohjeisiin. Tämän tutkimuksen lopputuloksena pystyttiin tuottamaan käytettävissä oleva kysely. Kysely luotiin ratkaisemaan Digia Oyj:n ongelma jakaa tietoa vihreistä käytänteistä ohjelmistokehityksessä omassa organisaatiossaan. Kehitetty kyselyä kehitettiin ja arvioitiin Digia Oyj:n henkilökuntaan kuuluvien haastateltavien toimesta sekä yhteyshenkilönä toimineen henkilön toimesta. Tutkimus on pyritty suorittamaan tarkasti ja tämä on pyritty osoittamaan raportoimalla prosessin kulku yksityiskohtaisesti ja selkeästi. Empiirisen osan suo- 98 Lähteet [1] ABDULSALAM, S., LAKOMSKI, D., GU, Q., JIN, T., JA ZONG, Z. Program energy efficiency: The impact of language, compiler and implementation choices. Julkaisusarjassa International Green Computing Conference (2014), 1–6. [2] ACHAR, S. Cloud computing: Toward sustainable processes and better environmental impact. Journal of Computer Hardware Engineering (JCHE) 1, 1 (2022). [3] AGARWAL, S., NATH, A., JA CHOWDHURY, D. Sustainable approaches and good practices in green software engineering. International Journal of Research and Reviews in Computer Science 3, 1 (2012), 1425. [4] AGGARWAL, K., HINDLE, A., JA STROULIA, E. Greenadvisor: A tool for analyzing the impact of software evolution on energy consumption. Julkaisusarjassa 2015 IEEE International Conference on Software Maintenance and Evolution (ICSME) (2015), 311–320. [5] AGGARWAL, K., ZHANG, C., CAMPBELL, J. C., HINDLE, A., JA STROULIA, E. The power of system call traces: predicting the software energy consumption impact of changes. Julkaisusarjassa CASCON (2014), vol. 14, 219–233. [6] AHMAD IBRAHIM, S. R., YAHAYA, J., JA SALLEHUDIN, H. Green software process factors: A qualitative study. Sustainability 14, 18 (2022). [7] BARAB, S., JA SQUIRE, K. Design-based research: Putting a stake in the ground. The Journal Of The Learning Sciences 13, 1 (2004), 1–14. [8] CAPRA, E., FRANCALANCI, C., JA SLAUGHTER, S. A. Is software green? application development environments and energy efficiency in open source applications. Information and Software Technology 54, 1 (2012), 60–71. [9] CHEN, P.-S. D., LAMBERT, A. D., JA GUIDRY, K. R. Engaging online learners: The impact of web-based learning technology on college student engagement. Computers Education 54, 4 (2010), 1222–1232. 105 [10] COLLECTIVE, D.-B. R. Design-based research: An emerging paradigm for educational inquiry. Educational researcher 32, 1 (2003), 5–8. [11] DENY ARTHAWAN SUGIH, P. I. P., NUGROHO, E., JA HARTANTO, R. Analysis on green it applications usage for the firm’s competitive advantage strategy. Julkaisusarjassa 2017 15th International Conference on Quality in Research (QiR) : International Symposium on Electrical and Computer Engineering (2017), 29–33. [12] DICK, M., DRANGMEISTER, J., KERN, E., JA NAUMANN, S. Green software engineering with agile methods. Julkaisusarjassa 2013 2nd International Workshop on Green and Sustainable Software (GREENS) (2013), 78–85. [13] DICK, M., NAUMANN, S., JA KUHN, N. A model and selected instances of green and sustainable software. Julkaisusarjassa What Kind of Information Society? Governance, Virtuality, Surveillance, Sustainability, Resilience: 9th IFIP TC 9 International Conference, HCC9 2010 and 1st IFIP TC 11 International Conference, CIP 2010, Held as Part of WCC 2010, Brisbane, Australia, September 20-23, 2010. Proceedings (2010), Springer, 248–259. [14] DRESCH, ALINE,K., ANTUNES, JUNICO,K., JA LACERDA, DANIEL PACHECO, K.Design science research : a method for science and technology advancement. Springer, Cham, 2015. [15] EDELSON, D. C. Design research: What we learn when we engage in design. The Journal of the Learning sciences 11, 1 (2002), 105–121. [16] ENCARNACION, R. F. E., GALANG, A. A. D., JA HALLAR, B. J. A. The impact and effectiveness of e-learning on teaching and learning. Online Submission 5, 1 (2021), 383–397. [17] ENGSTRÖM, E., STOREY, M.-A., RUNESON, P., HÖST, M., JA BALDASSARRE, M. T. How software engineering research aligns with design science: a review. Empirical Software Engineering 25 (2020), 2630–2660. [18] GEORGIOU, S., RIZOU, S., JA SPINELLIS, D. Software development lifecycle for energy efficiency: Techniques and tools. ACM Comput. Surv. 52, 4 (aug 2019). [19] HANNAY, J. E., DYBÅ, T., ARISHOLM, E., JA SJØBERG, D. I. The effectiveness of pair programming: A meta-analysis. Information and Software Technology 51, 7 (2009), 1110–1122. Special Section: Software Engineering for Secure Systems. 106 [20] HANNULA, M., JA ANTTI, L. Concetps of performance measurement, Suorituskyvyn mittauksen käsitteet. Metalliteollisuuden kustannus Oy, 2002. [21] HEVNER, A., R, A., MARCH, S., T, S., PARK, PARK, J., RAM,JA SUDHA. Design science in information systems research. Management Information Systems Quarterly 28 (03 2004), 75–. [22] HIRSJÄRVI, S., JA HURME, H. Tutkimushaastattelu. Gaudeamus Helsinkin University Press, 2014. [23] HIRSJÄRVI, S., REMES, P., JA SAJAVAARA, P. Tutki ja kirjoita. Kustannusosakeyhtiö Tammi, 1996. [24] IMPERATIVES, S. Report of the world commission on environment and development: Our common future. Accessed Feb 10 (1987), 1–300. [25] KAMBADUR, M., JA KIM, M. A. An experimental survey of energy management across the stack. SIGPLAN Not. 49, 10 (oct 2014), 329344. [26] KANANEN, J. Kehittämistutkimus opinnäytetyönä Kehittämistutkimuksen kirjoittamisen käytännön opas. Jyväskylän ammattikorkeakoulu, Jyväskylä, 2012. [27] KATAL, A., DAHIYA, S., JA CHOUDHURY, T. Energy efficiency in cloud computing data centers: a survey on software technologies. Cluster Computing, The Journal of Networks, Software Tools and Applications (2022). [28] KATAL, A., DAHIYA, S., JA CHOUDHURY, T. Energy efficiency in cloud computing data centers: a survey on software technologies. Cluster Computing 26, 3 (2023), 1845–1875. [29] KROSNICK, J. A., JA PRESSER, S. Question and questionnaire design. [30] LANNELONGUE, L., GREALEY, J., JA INOUYE, M. Green algorithms: quantifying the carbon footprint of computation. Advanced science 8, 12 (2021), 2100707. [31] LEE, H., CHOI, Y., VAN NGUYEN, T., HAI, Y., KIM, J., BAHJA, M., JA HOCAO ˘ GLU, H. Covid19 led virtualization: Green data center for information systems research. Information Systems Management 37, 4 (2020), 272–276. 107 [32] LEE, J., SONG, H.-D., JA HONG, A. J. Exploring factors, and indicators for measuring students sustainable engagement in e-learning. Sustainability 11, 4 (2019). [33] LINCOLN, Y. S., JA GUBA, E. G. Naturalistic inquiry. sage, 1985. [34] LÖNNQVIST, A., KUJANSIVU, P., JA ANTOLA, J. Aineettoman pääoman johtaminen. JTO-Palvelut Oy, 2005. [35] MALAVOLTA, I., CHINNAPPAN, K., JASMONTAS, L., GUPTA, S., JA ALI KARAM SOLTANY, K. Evaluating the impact of caching on the energy consumption and performance of progressive web apps. [36] MANOTAS, I., BIRD, C., ZHANG, R., SHEPHERD, D., JASPAN, C., SADOWSKI, C., POLLOCK, L., JA CLAUSE, J. An empirical study of practitioners’ perspectives on green software engineering. Julkaisusarjassa Proceedings of the 38th International Conference on Software Engineering (New York, NY, USA, 2016), ICSE ’16, Association for Computing Machinery, 237248. [37] MIRELES, G. A. G., MORAGA, M. Á., GARCÍA, F., JA PIATTINI, M. A classification approach of sustainability aware requirements methods. Julkaisusarjassa 2017 12th Iberian conference on information systems and technologies (CISTI) (2017), IEEE, 1–6. [38] MITRA, S., GUPTA, M., MISAILOVIC, S., JA BAGCHI, S. Phase-aware optimization in approximate computing. Julkaisusarjassa CGO 2017 - Proceedings of the 2017 International Symposium on Code Generation and Optimization (United States, 2017), V. Reddi, A. Smith, ja L. Tang, Eds., CGO 2017 - Proceedings of the 2017 International Symposium on Code Generation and Optimization, Institute of Electrical and Electronics Engineers Inc., 185–196. [39] MOISES, A. C., MALUCELLI, A., JA REINEHR, S. Practices of energy consumption for sustainable software engineering. Julkaisusarjassa 2018 Ninth International Green and Sustainable Computing Conference (IGSC) (2018), 1–6. [40] MURUGESAN, S. Harnessing green it: Principles and practices. IT Professional 10 (02 2008), 24 – 33. 108 [41] NOUREDDINE, A., JA RAJAN, A. Optimising energy consumption of design patterns. Julkaisusarjassa New Ideas and Emerging Resuts (NIER) of the 37th International Conference on Software Engineering (ICSE’15). Florence, Italy, May 2015. (May 2015). [42] NUHFER, E., JA KNIPP, D. 4: The knowledge survey: A tool for all reasons. To improve the academy 21, 1 (2003), 59–78. [43] PAUL, S. G., SAHA, A., AREFIN, M. S., BHUIYAN, T., BISWAS, A. A., REZA, A. W., ALOTAIBI, N. M., ALYAMI, S. A., JA MONI, M. A. A comprehensive review of green computing: Past, present, and future research. IEEE Access 11 (2023), 87445–87494. [44] PEFFERS, K., TUUNANEN, T., ROTHENBERGER, M. A., JA CHATTERJEE, S. A design science research methodology for information systems research. Journal of management information systems 24, 3 (2007), 45–77. [45] PENZENSTADLER, B. Infusing green: Requirements engineering for green in and through software systems. Julkaisusarjassa RE4SuSy@ RE (2014), 44–53. [46] PEREIRA, R., COUTO, M., RIBEIRO, F., RUA, R., CUNHA, J., FERNANDES, J. A. P., JA SARAIVA, J. A. Energy efficiency across programming languages: How do energy, time, and memory relate? SLE 2017, Association for Computing Machinery, 256267. [47] PEREIRA, R., COUTO, M., RIBEIRO, F., RUA, R., CUNHA, J., FERNANDES, J. P., JA SARAIVA, J. Ranking programming languages by energy efficiency. Science of Computer Programming 205 (2021), 102609. [48] PERNAA, J. Kehittämistutkimus: Tieto-ja viestintätekniikkaa kemian opetukseen. [49] PINTO, G., CASTOR, F., JA LIU, Y. D. Mining questions about software energy consumption. Julkaisusarjassa Proceedings of the 11th Working Conference on Mining Software Repositories (New York, NY, USA, 2014), MSR 2014, Association for Computing Machinery, 2231. [50] RASHID, N., JA KHAN, S. U. Agile practices for global software development vendors in the development of green and sustainable software. Journal of Software: Evolution and Process 30, 10 (2018), e1964. e1964 JSME-17-0140.R3. 109 [51] SALAM, M., JA KHAN, S. U. Developing green and sustainable software: Success factors for vendors. Julkaisusarjassa 2016 7th IEEE International Conference on Software Engineering and Service Science (ICSESS) (2016), IEEE, 1059– 1062. [52] SAPUTRI, T. R. D., JA LEE, S.-W. Integrated framework for incorporating sustainability design in software engineering life-cycle: An empirical study. Information and Software Technology 129 (2021), 106407. [53] SCRUM GUIDES. The 2020 scrum guide. URL https://scrumguides.org/ scrum-guide.html, viitattu 22.5.2023. [54] SHARMA, M., ARUNACHALAM, K., JA SHARMA, D. Analyzing the data center efficiency by using pue to make data centers more energy efficient by reducing the electrical consumption and exploring new strategies. Procedia Computer Science 48 (2015), 142–148. International Conference on Computer, Communication and Convergence (ICCC 2015). [55] STEIGERWALD, B., JA AGRAWAL, A. Developing green software. Intel White Paper 9 (2011). [56] TAINA, J. Good, bad, and beautiful software-in search of green software quality factors. Cepis Upgrade 12, 4 (2011), 22–27. [57] THEUNISSEN, T., VAN HEESCH, U., JA AVGERIOU, P. A mapping study on documentation in continuous software development. Information and Software Technology 142 (2022), 106733. [58] TUOMI, J., JA SARAJÄRVI, A. Laadullinen tutkimus ja sisällönanalyysi. Kustannusosakeyhtiö Tammi, 2018. [59] UUSI-RAUVA, E. Ohjauksen tunnusluvut ja suoritusten mittaus. Tampereen teknillinen korkeakoulu, 1994. [60] VALLI, R., JA AALTOLA, J. Ikkunoita tutkimusmetodeihin: 1, metodin valinta ja aineistonkeruu: virikkeitä aloittelevalle tutkijalle. Jyväskylä: PS-kustannus (2018). [61] VERDECCHIA, R., LAGO, P., EBERT, C., JA DEVRIES, C. Green it and green software. IEEE Software 38, 6 (2021), 7–15. 110 [62] VIITALA, R. johda osaamista!: Osaamisen johtaminen teoriasta käytäntöön. Inforviestintä Oy, 2005. [63] WBCSD. Visio 2050. URL https://fibsry.fi/wp-content/uploads/2022/ 03/Visio-2050_Muutoksen-aika_WBCSD.pdf, viitattu 9.5.2023. 111 A Saatekirje haastateltaville Tervetuloa osallistumaan vihreän ohjelmoinnin osaamisen kartoittamiseen tarkoitetun kyselylomakkeen kehittämistä koskevaan tutkimukseen! Tutkimus toteutetaan Jyväskylän yliopistossa vuoden 2023 aikana informaatioteknologian Pro Gradu - tutkielmaa varten. Tutkimuksen tarkoituksena on kehittää teoriaan pohjautuva informatiivinen kyselylomake vihreän ohjelmointiosaamisen arvioimiseksi sekä kartoittaa tutkimukseen osallistuvien kokemuksia kyselylomakkeesta. Haastatteluiden tulosten avulla kyselylomaketta pyritään kehittämään ja täydentämään edelleen. Haastattelut toteutetaan vähintään kahtena erillisenä teemahaastatteluna. Yhden haastattelun pituus on arvilta 30 – 50 minuuttia. Haastatteluun osallistuvat saavat liitteenä ohjelmistokehittäjien vihreän ohjelmoinnin osaamisen kartoittamisen kyselylomakkeen etukäteen tutustuttavaksi. Haastattelut toteutetaan etäyhteyden avulla ja haastattelut tallennetaan myöhempää käsittelyä varten. Haastattelutallenteita ja niiden pohjalta laadittuja litterointeja käsitellään luottamuksellisesti eikä niitä luovuteta kolmansille osapuolille tai säilytetä siten, että ne voisivat päätyä kolmansien osapuolten käsiin. Haastatteluja käytetään ainoastaan kyseessä olevaa tutkielmaa varten sekä sen sisältöä ja mahdollisia sitaatteja käytetään tutkielmassa siten, että haastateltavaa ei voida näiden perusteella tunnistaa. Mikäli Teillä on kysyttävää tutkimuksen toteutusta tai tulosten käsittelyä koskien, voitte ottaa minuun yhteyttä joko sähköpostitse tai puhelimitse. Kiitos etukäteen tutkimukseen osallistumisesta! Ystävällisin terveisin, Jenni Yrjänä jenni.a.yrjana@jyu.fi puh +358 40 8649 772 112 B Vihreän ohjelmoinnin osaamisen kartoittamisen kysely 1.0 Työtapoihin liittyvät kysymykset Tässä osiossa kysytään vihreisiin työtapoihin liittyviä kysymyksiä. 1. Onko totta, että etätyöskentely vähentää hiilidioksidipäästöjä? Kyllä Ei 2. Onko totta, että töihin pyöräily tai yleisten kulkuvälineiden käyttäminen vähentää hiilidioksidipäästöjä? Kyllä Ei 3. Onko totta, että paperitulostaminen ei lisää merkittävästi hiilidioksidipäästöjä? Kyllä Ei 4. Onko totta, että tietokoneen sammuttaminen tai lepotilaan laittaminen lyhyik- si ajoiksi, esimerkiksi kahvi- tai ruokatauon ajaksi, ei merkittävästi vähennä tietokoneen energiankulutusta? Kyllä Ei 5. Onko totta, että etäyhteyksien avulla järjestettävät tapaamiset eivät vähennä hiilidioksidipäästöjä? Kyllä Ei 6. Onko kevyiden asiakaspäätteiden käyttämisellä työtehtävissä merkitystä hiilidioksidipäästöjen vähentämisessä? Kyllä Ei Vihreään ohjelmistokehitysprosessiin liittyvät kysymykset Tässä osiossa kysytään vihreään ohjelmistokehitysprosessiin liittyviä kysymyksiä. 113 1. Onko tarkistuslistojen käytöstä hyötyä vihreässä ohjelmistokehitysprosessissa? Kyllä Ei 2. Onko totta, että dokumentaation vähentäminen lisää ohjelmistokehitysprosessin ja ohjelmiston vihreyttä? Kyllä Ei 3. Onko totta, että jatkuvalla validoinnilla ei ole merkitystä ohjelmistokehitysprosessin vihreyden kannalta? Kyllä Ei 4. Onko totta, että tehokas viestintä on eräs vihreän ohjelmistokehitysprosessin menestystekijöistä? Kyllä Ei 5. Jos ohjelmistokehitystiimissä on vihreästä ohjelmistokehityksestä vastaava henkilö, mitkä ovat hänen vastuulla olevat asiat? Voit valita useita. (a) Vihreästä ohjelmistokehityksestä vastaava henkilö on vastuussa prosessin ja ohjelmiston vihreyden mittaamisesta. (b) Vihreästä ohjelmistokehityksestä vastaava henkilö ei ole vastuussa prosessin ja ohjelmiston vihreyden mittaamisesta, vaan vastuu on tiiminjohtajalla / Scrum Masterilla. (c) Vihreästä ohjelmistokehityksestä vastaava henkilö on vastuussa prosessin ja ohjelmiston vihreyden dokumentoimisesta. (d) Vihreästä ohjelmistokehitykestä vastaava henkilö ei ole vastuussa prosessin ja ohjelmiston vihreyden dokumentoinnista, vaan vastuu on jaettu tiimin kaikkien jäsenten kesken. (e) Vihreästä ohjelmistokehityksestä vastaava henkilö on vastuussa prosessin ja ohjelmiston vihreyden raportoinnista. (f) Vihreästä ohjelmistokehityksestä vastaava henkilö ei ole vastuussa prosessin ja ohjelmiston vihreyden raportoinnista, vaan vastuu on tiiminjohtajalla / Scrum Masterilla. 114 1. Onko totta, että säästävillä ohjelmistostrategioilla pyritään minimoimaan CPU:n ja muistin käyttöä? Kyllä Ei Pilvipalvelut ja reunalaskenta 1. Onko totta, että pilvipalvelujen käyttäminen lisää ohjelmiston energiankäyttöä? Kyllä Ei 2. Alla on listattu väitteitä siitä, miksi pilvipalvelut ovat hyödyllisiä ajateltaessa vihreää ohjelmistokehitystä. Valitse näistä oikeat. (a) Pilvipohjaisissa palveluissa resursseja käytetään pyynnöstä, joka mahdollistaa isossa mittaskaalassa datakeskusten energiatehokkuuden optimoinnin. (b) Pilvipohjaisissa palveluissa resursseja käytetään pyynnöstä, joka mahdollistaa asiakaslaitteiden energiatehokkuuden optimoinnin. (c) Pilvipalveluissa on vähemmän yleiskustannuksia sekä tehokkaampi skaalautuvuus. (d) Pilvipalveluissa on enemmän yleiskustannuksia, mutta tehokkaampi skaalautuvuus. (e) Datakeskukset voivat tehokkaammin hyödyntää vihreitä energianlähteitä ja laitteiden lämpenemisestä syntyvän hukkaenergian. (f) Laitteiden joutokäyntiä on vähemmän. 3. Pelkästään pilvipalvelujen käyttäminen ei takaa kuitenkaan vihreämpää ohjelmistoa. Mitä ohjelmistokehittäjän tulee ottaa huomioon, jotta pilvipalvelujen käyttämisestä saadaan oletettu hyöty? Valitse oikeat. (a) Ohjelmistoarkkitehtuuri tulee suunnitella pilvipalvelujen käyttöä ajatellen. (b) Datan siirtely tulee optimoida. (c) Kaksoisdata tulee pyrkiä poistamaan. (d) Ohjelmistokehittäjän tulisi hyödyntää älykästä tietojen pakkaamista datan käyttötiheyteen perusteuen. 121 (e) Ohjelmiston tulisi hyödyntää myös palvelitonta laskentaa. (f) Ohjelmiston tulisi hyödyntää Faas-toimintoa (function-as-service). (g) Ohjelmistossa tulisi tarpeen mukaan hyödyntää datan käytön profilointia. Ohjelmointikieli 1. Onko totta, että ajallisesti nopein ohjelmointikieli on myös tehokkain? Kyllä Ei 2. Onko totta, että tulkitut kielet ovat energiatehokkaampia muihin kieliin verrattuna? Kyllä Ei 3. Onko totta, että on mahdollista valita yksi ohjelmointikieli, joka on parempi muihin ohjelmointikieliin verrattuna? Kyllä Ei 4. Onko totta, että C-pohjaiset kielet eivät ole kovinkaan energiatehokkaita? Kyllä Ei Datan ja muistin käyttö 1. Onko totta, että kokonaismuistin määrän ja DRAM-muistin energiankulutuksen välillä on suora yhteys? Kyllä Ei Sähköinen jäte 1. Onko totta, että sähköisellä jätteellä voidaan tarkoittaa elektroniikkajätettä tai datajätettä? Kyllä Ei 2. Onko totta, että sähköinen jäte ei ole merkittävä tekijä ohjelmiston hiilijalanjälkeä arvioitaessa? Kyllä Ei 122 3. Onko totta, että sähköistä jätettä syntyy vaatimusmäärittelyvaiheessa esimerkiksi silloin, kun vaatimukset ovat kirjattu virheellisesti ja ne eivät vastaa asiakkaan vaatimuksia? Kyllä Ei 4. Onko totta, että monimutkainen koodi ja dokumentaatio lisäävät sähköistä jätettä? Kyllä Ei 5. Onko totta, että ohjelmoijan puutteelliset taidot lisäävät sähköistä jätettä? Kyllä Ei 123