Ostaisinko ohjelmiston ylläpitoa?

Ostan yritykseni käyttöön ohjelmiston projektina. Kun se tulee valmiiksi, toivotamme projektitiimille hyvää loppuelämää ja elämme ohjelmiston kanssa onnellisina työuramme loppuun asti. Näinhän voisi toivoa, mutta niin ei vain koskaan tapahdu. Siksi myyjän pitäisi osata myydä ja ostajan ostaa siten että odotukset ja realiteetit kohtaavat.

Ylläpitämättömässä ohjelmistossa tekninen velka pääsee kasvamaan korkoa. Jos tekijöitä ja rahaa ohjelmiston ylläpitoon ei varata, ohjelmisto osuu ennen pitkää tuulettimeen ja tiedossa on paniikki ja pitkä käyttökatko. Siinä vaiheessa pystymetsästä otetulla porukalla kestää korjauksissa ehkä pidempi aika kuin minkä bisnes kestää.

Projektissa tehtiin bugeja

Bugit, eli ohjelmointivirheet ovat väistämättömiä. Pätevä koodari tekee niitä huonoa koodaria vähemmän, kurinalainen automaattitestaus ja taitava testaaja saavat niistä kiinni suuren osan, mutta ei koskaan kaikkia. Ohjelmisto, jonka voi todistaa oikeaksi järjellisellä työmäärällä, on myös niin triviaali, ettei sellaisia tule vastaan oikeassa elämässä.

Usein ohjelmistoprojekteilla on takuuaika, jonka sisällä havaitut viat ja puutteet luvataan korjata tuntihinnalla tai ilman. Ja silloin sitä ohjelmistoa muuten kannattaakin testata ja kovaa. Vaikka asiakkaita haluttaisiinkin palvella hyvin, ei kuitenkaan ole mahdollista lupautua tekemään korjauksia enää sen jälkeen, varsinkaan ilmaiseksi. Tekijät täytyy myydä muihin projekteihin ja tokihan palkan maksua varten rahaa pitää tulla sisäänkin. 

Projektissa käytettiin bugeja

Nykyään ohjelmistotuotannon tuottavuus perustuu paljolti valmiiden ilmaisten komponenttien käyttöön. Koska niidenkin kehittäjät ovat ihmisiä, bugeja on ja niitä löytyy myös niistä riippuvan projektin päättymisen jälkeen. Pahimmillaan bugit mahdollistavat pääsyn kaikkeen palvelimella olevaan dataan, kuten kävi reilu vuosi sitten Log4Shell-haavoittuvuuden kanssa. Jos tämä oli ensimmäinen kerta kun kuulit Log4Shellistä, ostamasi ylläpitämätön ohjelmisto olisi ollut viimeisen vuoden hakkereiden leikkikenttä. Verkossa toimivissa sovelluksissa on paljon hyökkäyspintaa ja päivityksiin pitää suhtautua asiaan kuuluvalla vakavuudella. Riippuvuuksien mukanaan tuomien haavoittuvuuksien etsinnän voi onneksi automatisoida, esimerkiksi Dependency-Track sovelluksella.

Maailma muuttuu

Harva sovellus toimii nykyään umpiossa, eikä muu maailma suo armoa “päättyneille” projekteille. Esimerkiksi omassa pienkehitysvaiheessa (ylläpito++) olevassa projektissa on viimeisen puolen vuoden aikana vaihdettu mm. maksurajapinta tuoreempaan ja useampia Microsoftin rajapintoja. Jos kukaan ei olisi näitä ilmoituksia ollut lukemassa ja korjaamassa: Boom!

Ja toki se lähiympäristökin voi muuttua. Palvelimelta voi loppua levytila tai palaa sulake. Pilvessä, eli “jonkun toisen tietokoneella” sulakkeenkin onneksi vaihtaa “joku toinen”.

Toiveet muuttuvat

Yksi urani mukavimmista hetkistä oli kun asiakas kertoi olleensa huolissaan kun tiimiltäni tuli  projektipalaverien välissä niin vähän kysymyksiä. Lopputulos toimi kuitenkin kuin olisimme lukeneet ajatukset. Näin kuitenkin tapahtui koska toimiala oli verrattaen helposti ymmärrettävä, asiakkaan kanssa oltiin “samalla aaltopituudella” ja ohjelmiston haluttu toiminta voitiin käydä läpi kasvokkain ja ajan kanssa.

Aina kuitenkin löytyy jokin reunatapaus, jota asiakas tajuaa kokeilla vasta myöhemmin, eikä toteutus vastaakaan asiakkaan oletusta. Eikä ole myöskään ennenkuulumatonta, että asiakkaan toiveet ohjelmiston käytöksestä muuttuisivat ajan ja kokemuksen myötä.

Ehdotus toimintasuunnitelmaksi:

Projektin aikana projektitiimi:

1. Automatisoi testauksen
2. Automatisoi haavoittuvuuksien skannauksen
3. Pystyttää monitoroinnin
4. Kirjoittaa riittävän dokumentaation

Olisi parasta jos joku projektitiimistä voisi jäädä ainakin pienellä allokaatiolla osallistumaan ylläpitoon, mutta ainakin olisi syytä järjestää riittävä perehdytys.

Projektin jälkeen ylläpitotiimi:

1. Korjaa löydetyt bugit
2. Korjaa löydetyt haavoittuvuudet
3. Lopulla allokaatiolla avustaa asiakastapausten selvittelyssä ja tekee pienemmän prioriteetin muutoksia