Ohjelmistoremontti tarkoittaa ohjelmistokehitysprojektia, missä tavoitteena on korjata, muokata tai laajentaa vanhaa ohjelmistoa ilman kattavia lähtötietoja sen rakenteesta ja toiminnasta. Tyypillisesti ohjelmistoremontin suorittavat eri henkilöt kuin ketkä ohjelmiston ovat alunperin kehittäneet. Tämä vaatii remontoijalta poikkeuksellisen hyvää kykyä hahmottaa ohjelmiston kokonaisarkkitehtuuri ja toiminta nopeasti ja tarkasti sekä luoda näppäriä ja toimivia ratkaisuja niillä resursseilla, joita on käytössä.
Ohjelmistoremontin tarve voi syntyä esimerkiksi seuraavilla tavoilla:
1) Kova hoppu ja niukka budjetti
Yritys kehittää ripeällä aikataululla ohjelmiston, jolla uusi liikeidea saadaan nopeasti markkinoille. Ohjelmistokehitys rahoitetaan pienehkön avustuksen tai sijoituksen avulla eli rajatulla budjetilla, mikä pakottaa tinkimään toiminnallisuudesta ja laadusta. Ohjelmisto otetaan kuitenkin lopulta käyttöön, mutta liiketoiminta ei lähdekään liikkeelle halutulla tahdilla, rahat loppuvat ja alkuperäiset koodarit kaikkoavat. Lopputuloksena on erittäin kiperä tilanne, missä ohjelmisto on jo tuotantokäytössä, mutta se ei ole vielä riittävä täysipainoiseen bisnekseen tai lisärahoituksen saamiseen, eikä yrityksellä ei ole kykyä kehittää sitä.
Tarvitaan ohjelmistoremontti, jossa ohjelmiston kipukohdat ja keskeiset puutteet ratkaistaan niin, että liiketoiminta pääsee taas kasvuun.
2) Pikkuhiljaa pala kerrallaan
Yritys on aikoinaan kehittänyt ohjelmiston ja saanut sen avulla liiketoimintansa mukavasti käyntiin. Vuosien varrella ohjelmistoon on tehty lukuisia uusia ominaisuuksia akuuttien asiakastarpeiden tyydyttämiseksi, mutta silloin tällöin on jouduttu “oikomaan mutkia” kehitystyössä, koska alkuperäinen design ei ihan tukenut uutta toiminnallisuutta. Pikkuhiljaa toteutus onkin pirstaloitunut ja monimutkaistunut, kunnes himmelistä ei ota enää mitään tolkkua eikä kukaan uskalla koskea siihen pitkällä tikullakaan. Pahimmassa tapauksessa kriittinen tieto-taito on ollut vain yksittäisten kehittäjien pääkopassa ja eräänä päivänä he eivät enää olekaan yrityksen palveluksessa.
Tarvitaan ohjelmistoremontti, jossa ohjelmiston arkkitehtuuri ja dokumentaatio tuodaan nykypäivän tasolle ja villit viritykset korvataan päivänvalon kestävillä ratkaisuilla.
3) Maailma ja tarpeet muuttuvat
Yritys kehitti mainion ohjelmiston liiketoimintaansa tukemaan, mutta ympäröivä maailma ja tarpeet muuttuvat niin, että ohjelmistoa pitäisi laajentaa tavalla, jota ei alunperin osattu ottaa huomioon. Ohjelmiston ydinarkkitehtuuri ja tietomallit eivät yksinkertaisesti vain taivu uusiin tavoitteisiin, vaan niiden toteuttaminen on erittäin hankalaa. Vaatii suurta rohkeutta kajota ohjelmiston perustana oleviin rakenteisiin, koska pienikin muutos heijastuu joka puolelle koodia ja on iso riski rikkoa jotain olennaista.
Tarvitaan ohjelmistoremontti, missä arkkitehtuuria ja tietomalleja päivitetään niin, että ohjelmistoa voidaan taas jatkokehittää haluttuun suuntaan.
4) Halvalla saatiin
Yritys tilasi ohjelmiston halvalla ulkomailta. Ulkoistettujen kehitysprojektien perimmäinen ongelma on yleensä tilaajan toimittamissa spekseissä ja siinä, että tiettyjen halpatyövoimaa tarjoavien kultturien koodarit noudattavat niitä kirjaimellisesti. Suomalaiset koodarit saattavat uskaltaa kyseenalaistaa pöljät toimeksiannot, mutta auta armias, jos tiimi päättääkin edetä kiltisti heppoisten speksien mukaan ja lopputulos on sen mukaista…
Ohjelmiston toiminnallisuuden ja ulkoasun määrittely sujuu yleensä hyvin, mutta harva tilaaja osaa ja uskaltaa vaatia riittävästi tekniseltä toteutustavalta. Tällöin speksiä tulkitseva kehitystiimi päätyy helposti toteuttamaan “ketterästi” vain sen, mikä on välttämätöntä, jolloin ohjelmiston ylläpidettävyys ja laajennettavuus voikin olla huteralla pohjalla. Myöhemmin, kun jotain pitäisi muuttaa tai lisätä, paljastuu tarve tehdä ensin merkittäviä muutoksia ohjelmistoarkkitehtuuriin.
Tarvitaan ohjelmistoremontti, missä ohjelmiston arkkitehtuuria ja tietomallia jatkokehitetään sellaisiksi, että tulevat muutokset ja laajennukset onnistuvat helposti, jopa pelkästään konfiguroimalla.
5) Protyyppi lipsahti tuotantoon
Yritys kehitti nopean prototyypin ohjelmistosta voidakseen testata uutta liikeideaansa. Idea osoittautui niin lupaavaksi, että ohjelmisto päätettiinkin viedä saman tien tuotantokäyttöön. Kaikki meni hyvin, kunnes käyttäjämäärät ylittivät kriittisen pisteen, jonka jälkeen prototyypiksi tarkoitettu ratkaisu ei enää skaalautunutkaan, vaan ohjelmisto alkoi hidastua ja kaatuilla. Tämän seurauksena kehittäjätiimi joutui käyttämään kaiken työaikansa tulipalojen sammuttamiseen sen sijaan, että olisi pystynyt keskittymään ohjelmiston perimmäisten ongelmien ratkaisemiseen.
Tarvitaan ohjelmistoremontti, jossa etsitään ohjelmiston pullonkaulat eli selkeimmät skaalautumisen esteet ja korjataan ne, jotta akuutti kriisitilanne laukeaa. Samalla kannattaa remontoida myös ohjelmiston arkkitehtuuri, jonka pohjalta kehittäjätiimi voi luoda uuden ja skaalautuvamman version ohjelmistosta.
6) Myydään ennen kuin tehdään
Yritys myy vahvassa etukenossa ohjelmistotuotteita, joita ei oikeastaan ole vielä olemassa. Periaatteena on, että tuotekehitys laskutetaan asiakkaalta “käyttöönottoprojektin” tai “kustomoinnin” muodossa, jotta ei tarvitsisi investoida kehitystyöhön etukäteen. Jokaisen asiakkaan tarpeet ovat pikkaisen erilaisia ja toimitusajat haastavia, mikä ratkaistaan käytännössä niin, että koodipohjasta luodaan erillinen versio jokaiselle asiakkaalle, jota lähdetään muokkaamaan myytyjen speksien mukaiseksi. Toisin sanoen, yrityksellä ei oikeastaan ole yhtä ohjelmistotuotetta, vaan erillisiä asiakasprojekteja, joiden lähdekoodit ovat hämärästi sukua toisilleen, mutta erkaantuneet vuosien kuluessa omiksi rönsyikseen. Koskaan ei ole aikaa pysähtyä miettimään, että kuinka nuo rönsyt yhdistettäisiin yhtenäiseksi tuotteeksi, jota olisi helpompi ylläpitää ja jatkokehittää.
Tarvitaan ohjelmistoremontti, jossa tunnistetaan versioille yhtenäisiä ominaisuuksia ja ryhdytään pala kerallaan muokaamaan niitä uudelleenkäytettäviksi ohjelmistomoduuleiksi, kunnes koodipohja on yhtenäinen. Ominaisuudet, jotka ovat käytössä vain osalla asiakkaista, muokataan sellaisiksi, että ne voidaan kytkeä päälle/pois konfiguroimalla.
Tuttu tarina – mikä avuksi?
Tuntuuko jokin noista tarinoista kovin tutulta? Kävikö yrityksellesi juuri noin? Ei syytä huoleen!
Softaremppa on ohjelmistoremonttien ammattilainen. Kutsu Reiska apuun, niin saat ohjelmistoosi uutta puhtia remontoimalla.