Tarkvara tellimisel tasub mõelda selle hooldusvajadusele
Juba tarkvara tellimisel tuleks mõelda selle hooldamise vajadusele isegi siis, kui esmapilgul tundub olevat marginaalse programmijupiga, millele ei ole uusi funktsionaalsusi kavas lisada. Praktika näitab, et aja jooksul kipub taoliste rakenduste olulisus kasvama ning arendusvajadus tekib sageli ettevõttest sõltumatult, ent on möödapääsmatult vajalik ärikriitiliseks muutunud tarkvara töös hoidmiseks.
Paljudes ettevõtetes on veel kasutusel tarkvara, mis on loodud sajandivahetuse paiku. Ainuüksi vanuse pärast ei ole vajadust toimivat lahendust välja vahetada, ent tihti saavad probleemid alguse hoopis sellest, et toona oli tarkvaraarenduse praktika märksa teistsugune kui praegu. Sageli pole üle 10 aasta tagasi loodud rakenduse kohta mingit dokumentatsiooni ega arendustuge, võibolla pole ka enam arendusettevõtet või lõi selle oma töötaja, kes on juba ammu töökohta vahetanud. Isegi kui tarkvara ise toimib kenasti, tekivad varem või hiljem selle töös hoidmisega probleemid, sest tehnoloogiline maailm meie ümber on selle ajaga lihtsalt tundmatuseni muutunud.
Kuidas tarkvara vananeb?
Otseselt loomulikult programmikood ei kulu ning ka programmeerimisvead on pikema aja jooksul tavaliselt välja tulnud ja parandatud, ent kõik rakendused on seotud teiste keskkondade ja IT-süsteemidega ning enamasti üle võrgu ligipääsetavad. Arvestades küberohtude pidevat lisandumist ei ole 10-20 aastat tagasi loodud tarkvara kindlasti enam turvaline, vaid seal on kahtlemata turvaauke, mida saab kurjasti ära kasutada. Pahalastest veelgi suurem mõjutaja on aga tehnoloogiaplatvormide pidev areng, olgu selleks tarkvara majutuskeskkond, serverite operatsioonisüsteem või turvapoliitika, mis uuendamise korral lõpetavad tahtmatult nii mõnegi vana rakenduse toimimise.
Kõige lihtsam näide on veebilehitseja uus versioon, millega mõnda vanemat tarkvara kasutada ei saa. On ette tulnud juhtumeid, et Android teeb operatsioonisüsteemi uuenduse ning nutiseadmetes kasutatav rakendus enam ei tööta, ent ilma selleta ei ole võimalik konkreetset liikuvat tööd teha. Või muutub andmevahetuse formaat liidestuses kolmandate osapooltega ning ettevõtte rakendustes tuleb sellest lähtuvalt teha ka omapoolsed muudatused. Seega võib arendusvajadus tekkida ootamatult isegi siis, kui ettevõte ise ei taha mingeid uusi funktsionaalsusi rakendusele lisada.
Enamik tarkvaraarendaja ajast võib kuluda rakenduse uurimisele
Iseenesest ei pruugi vanema rakenduse uuendamine olla töömahukas, ent probleem tekib siis, kui konkreetse arendajaga ei saa enam kontakti ning igasugune dokumentatsioon tema loodud tarkvara kohta puudub. Uuel programmeerijal kulub sellisel juhul väga palju aega, et vana programmikoodi uurida ja aru saada, mis on üldse tehtud ja kuidas lahendus peaks töötama. Seepärast ei soovigi paljud arendusettevõtted vanade rakenduste uuendamist ette võtta, kuna ajakulu enda kurssi viimiseks on ebamõistlikult suur. Kui lisaks dokumentatsioonile on kadunud ka lähtekood ning tarkvara loomiseks kasutatud tehnoloogia on iganenud või pole enam üldse kasutusel, on vahel mõistlikum luua nullist uus rakendus, ehkki korrapärase hoolduse korral oleks selle uuendamine olnud kordi soodsam.
Kas sellises olukorras on viga kliendi või arendaja poolel? Ühest vastust siin pole: tellija võibolla ei osanud arendajalt küsida kogu infot ja lähtekoodi või surus eelarve nii kokku, et arendaja tegigi nii vähe kui võimalik. Samuti võis tellijale tunduda imelik maksta igakuist väikest tasu tarkvara hoolduse eest. Teisalt pole ka paljud arendajad huvitatud hooldustoe pakkumisest ning tahavad liikuda uute projektide tegemise juurde. Nii naudibki tellija igakuiste püsikulude puudumist kuni jõutakse punkti, kui rakenduse kasutamist ei ole enam võimalik jätkata turvaprobleemide või tehnoloogiaplatvormide uuenemise tõttu. Kolmandast osapoolest tingitud muutmisvajadus võib aga tekkida võib üsna lühikese etteteatamisajaga, mille jooksul ühtki uut tarkvara luua ei jõua.
Kuidas tagada tarkvara jätkusuutlikkus?
Kuigi see võib tunduda esimesel hetkel aja ja raha raiskamisena, tuleks alati kirja panna lähteülesanne ning arvestada eelarvesse ka arendajapoolne dokumenteerimiskulu. Tänapäevane tarkvara loomise praktika on küll palju parem kui 10-20 aastat tagasi, kuid ei saa eeldada, et kõik arendajad alati dokumenteerimist vaikimisi oma kohustuseks peavad.
Teiseks tuleks alati hinnata loodava rakenduse eluiga. Seda kiputakse sageli alahindama ja tarkvara on kasutusel kordi pikemalt ehk sisuliselt nii kaua kui vähegi võimalik. 10 aastaga võib marginaalsena planeeritud programmijupist saada ettevõtte äriprotsesside süda, mis on seotud paljude teiste IT-süsteemidega ning mille kasutamisest loobumine tähendab sisuliselt äritegevuse lõpetamist.
Kolmandana tasub arenduspartneriks valida pigem ettevõte kui eraisik ning eelistada arendajat, kes on valmis tulevikus ka hooldustuge pakkuma. Alternatiiviks on leida kohe eraldi ettevõte hoolduspartneriks, kes viib end arendusprotsessiga algusest peale kurssi.
Hoolduskulu on enamasti minimaalse mahuga
Viimasena tuleks arvestada arendusprojekti eelarvesse minimaalne jooksva toe kulu, mis võrreldes arenduse enda maksumusega on tühine summa. See aga kohustab hoolduspartnerit hoidma end pidevalt kursis nii rakenduse enda kui ka tehnoloogiaplatvormide uuendamisest tingitud muutmisvajadustega. Kui tuleb teha suuremaid arendustöid, tasutakse nende eest tavaliselt vastavalt panustatud töötundidele. See tähendab küll lisakulu, kuid eeliseks on riski puudumine, et ettevõtte jaoks ärikriitiline rakendus lakkab ootamatult töötamast ning abi ei ole kuskilt leida.
Vahel eeldavad kliendid, et arendaja antud garantiiga ongi tarkvara hooldusvajadus kaetud. Esiteks kehtib garantii piiratud perioodi, näiteks 6-12 kuud. Teiseks on see mõeldud üksnes otseste programmeerimisvigade parandamiseks, mis testimisest on läbi lipsanud. Kolmandate osapoolte arendustega kaasnevat rakenduse muutmisvajadust garantiitööks ei peeta ning seda käsitleb arendusettevõte enamasti uue projektina.
Korralikult dokumenteerimata ja hoolduslepinguga katmata tarkvara kasutamisel tuleks selle uuendamine võtta päevakorrale esimeste anomaaliate ilmnedes. Kui rakendus juba hetkel mõne uuema platvormi või brauseriga ei tööta, siis on selge, et need probleemid ei lahene iseenesest nagu ka hambaarsti külastamise vajadus ning aja jooksul ainult süvenevad. Mida rohkem lahendust edasi lükata, seda väiksema tõenäosusega õnnestub üles leida senine arendaja või luua tagantjärele dokumentatsiooni, mis hoiaks arenduskulu mõistliku. Kui aga rakendus enam üldse ei toimi ning selle ajakohastamiseks tuleks 20 aasta taguselt tarkvaraversioonilt minna kohe üle tänapäevasele, siis ei pruugi see olla võimalik ning tulebki nullist luua päris uus lahendus.
Kui sul tekkis küsimusi, siis kirjuta meile:
Hardi Ots
Artikkel ilmus Finantsuudised.ee portaalis 3.märtsil 2023.
Loe lisaks:
Äriline digipööre loob majanduslanguse üleelamiseks piiramatuid võimalusi
Äriliseks digipöördeks saab taotleda eurotoetust