Usein puolustussektorille tehtävät ohjelmistot ovat pitkäikäisiä, ja sama ohjelmisto saattaa olla käytössä vuosikymmeniä. Ohjelmistot säilyvät käytössä pitkään, koska ne ovat laajoja ja tiettyyn käyttöön räätälöityjä, jolloin ohjelmistojen jatkuva kehittäminen on kannattavampaa kuin kokonaan uuden ohjelmiston tekeminen. Lisäksi ohjelmistoissa on tärkeintä loppukäyttäjän saama hyöty, eikä ohjelmistojen tarvitse kilpailla keskenään esimerkiksi ulkoasulla, jolloin samaa ohjelmistoalustaa voidaan käyttää pidempään. Vaikka ohjelmistoihin ei elinkaaren aikana kehitettäisikään uusia ominaisuuksia, tulee niitä silti päivittää esimerkiksi tietoturvan ylläpitämiseksi. Kokemukseni mukaan seuraavilla toimintatavoilla ohjelmistojen pitkää elinikää ja ylläpidettävyyttä on mahdollista edesauttaa.
Luota tuttuun ja turvalliseen
Oli sitten kyse ohjelmointikielestä, ohjelmistokehyksestä tai jostakin pienemmästä komponentista, kannattaa valita tekninen ratkaisu, joka on kypsää ja laajasti käytettyä. Teknologiapainotteisella alalla on suuri houkutus valita uusinta uutta edustavaa tekniikkaa. Pitkäjänteisyyden näkökulmasta tässä on kuitenkin kaksi ongelmaa:
Kehityksen alkuvaiheessa oleva teknologia muuttuu hyvin nopeaan tahtiin, josta seuraa suoraan ylimääräistä ylläpitotyötä omalle ohjelmistolle.
Alkutaipaleella olevasta teknologiasta on vielä mahdotonta sanoa, mikä sen elinkaari tulee olemaan. Osa teknologoista vakiinnuttaa paikkansa maailmassa, mutta osan tarina päättyy kuin kanan lento.
Myöskään elinkaaren loppuvaiheessa olevaa teknologiaa ei kannata valita, koska teknologian ylläpito voi loppua kokonaan kesken oman tuotteen elinkaaren. Tavoitteena on siis löytää teknologioita,
jotka ovat laajasti käytössä,
joita ylläpidetään aktiivisesti ja
joilla on vielä tulevaisuutta edessä.
Aktiivisuutta voi arvioida sillä, kuinka tiheään tahtiin ja milloin viimeksi kyseinen ratkaisu on päivittynyt. Käytön laajuutta voi arvioida esimerkiksi etsimällä aiheeseen liittyviä keskustelupalstoja. Jos teknologialla on paljon käyttäjiä, löytyy sen käytöstä myös paljon ohjeita, kysymyksiä ja aktiivista keskustelua. Ja jos teknologialla on paljon käyttäjiä, voidaan olettaa, että teknologia pysyy myös pitkään käytössä. Joissakin tapauksissa pitkäikäisyyttä voi myös arvioida sen mukaan, onko teknologialla olemassa jokin selvä tiekartta, jonka mukaan kehitystä tehdään pitkäjänteisesti.
Pidä langat omissa näpeissä
Perinteisesti ohjelmistoalalla on pyritty hakemaan kustannustehokkuutta käyttämällä mahdollisimman paljon valmiita ohjelmistokomponentteja. Valmiiden komponenttien käytössä piilee kuitenkin riski: komponenttien elinkaari ei ole oman projektin hallinnassa, joten komponentti voi kuolla ennenaikaisesti. Lisäksi on mahdollista, että vaikka komponentin elinkaari jatkuisikin, kehittyvät komponentin rajapinnat ja toiminta oman tuotteen kannalta epäedulliseen suuntaan. Edellisistä seikoista johtuen kolmannen osapuolen komponenttien päivittäminen ja ylläpitäminen on työlästä. Ennen jokaisen komponentin käyttöönottoa kannattaa siis punnita, onko komponentin tuoma hyöty niin suuri, ettei vastaavaa toteutusta kannata tehdä itse.

Valmista valmiskomponenttien lähdekoodin saatavuus
Valmiskomponenteille on omat käyttökohteensa, eikä niistä voi luonnollisesti kokonaan luopua. Tällöin komponentteihin liittyvää riskiä kannattaa pyrkiä minimoimaan. Käyttöön tulisi ottaa komponentteja, jotka ovat kypsiä ja laajasti käytettyjä sekä näyttävät elinvoimaisilta myös tulevaisuudessa. Lisäksi komponenttien lähdekoodi tulisi olla saatavissa, jotta sitä voidaan lisenssiehtojen salliessa hyödyntää myös silloin, jos komponentin kehitys muutoin lakkaa.
Kapseloi kolmannen osapuolen kirjastot rajapintojen taakse
Mikään ei ole niin varmaa kuin muutos.
Jo ohjelmistoa suunniteltaessa kannattaakin varautua siihen, että ohjelmiston elinkaaren aikana kolmannen osapuolen kirjastoja tullaan vaihtamaan toisiin ja omia moduuleita koodaamaan uusiksi. Vaihtotyötä helpottaa huomattavasti se, jos kirjaston käyttö on kapseloitu rajapintojen taakse, eikä kirjastoa käytetä suoraan eri puolilta sovellusta.
Tee kerralla kunnollista
Pääsääntöisesti koodi kirjoitetaan vain kerran, mutta se tullaan lukemaan ajan saatossa läpi kymmeniä tai jopa satoja kertoja. Tästä syystä kannattaa panostaa koodin laatuun ja selkeyteen kirjoitusvaiheessa, jotta koodia lukiessa ei tarvitse tuhlata aikaa epäselvän koodin ihmettelyyn.
Usein vanha koodi toimii mallina myös kaikelle uudelle koodille. Jos projektin alkutaipaleella tehdään huonoja ja epäselviä ratkaisuja, tuppaavat saman tapaiset rakenteet periytymään myös uusiin osuuksiin ja ongelman kertautuvat.
Jätä jälki jälkipolville
Pitkäikäisen tuotteen elinkaaren aikana tapahtuu väistämättä se, että tuotteen parissa työskentelevä henkilöstä vaihtuu ja lopulta kaikki alkueräisillä tekijöillä ollut hiljainen tieto katoaa. Tällöin ainoaksi tietolähteeksi jää projektin aikana tuotettu dokumentaatio, joten dokumentaatioon kannattaa panostaa. Ei ole olemassakaan niin pientä päätöstä, ettei sitä kannattaisi dokumentoida.
Lue lisää aikasemmista blogeistani
Siistiä koodia - Poimintoja luettavamman koodin kirjoittamiseksiTurvallista ohjelmistokehitystäKurkkaa myös Instan avoinna olevat työpaikat
Avoimet työpaikat
Marko Latvala
Kirjoittaja työskentelee Instan puolustusliiketoiminnassa ohjelmistoarkkitehtina.