Hallittu sovelluskehitys ja sovellusten julkaisu Qlikillä, osa 2

/ Arto Nimander

Blogin ensimmäisessä osassa kävin läpi perusteita hyvälle ja tehokkaalle kehitykselle. Jatkan tässä blogin toisessa osassa tarkemmin prosessin eri vaiheiden käsittelyä.

Ennen kuin itse sovellusta päästään tekemään, pitää tietenkin olla määritelty, mitä halutaan. Jos liiketoiminnalta vaaditaan hyvin tarkat tekniset määrittelyt heti lähdössä, syntyy prosessiin usein jo tässä pullonkaula, kun määrittelyjä ei synny. Hedelmällisempää voi olla jakaa määrittely kahteen osaan, jossa liiketoiminta kertoo ensin tarpeensa: Mitä halutaan analysoida, mitä päätöksiä analyysin perusteella tehdään, ketkä sitä käyttävät. Tarve saattaa monesti hoitua jo olemassa olevia sovelluksia muokkaamalla tai useita tarpeita voi olla syytä koordinoida ja koota yhteen yhdeksi kokonaisuudeksi. Toinen osa määrittelyjä on teknisempi osuus, johon on hyvä kytkeä sovelluskehittäjä jo aikaisessa vaiheessa mukaan kysymään oikeita kysymyksiä. Tässä vaiheessa käydään tarkemmin läpi tarvittava data ja siihen liittyvät muokkaukset sekä käyttöliittymä ja mittareiden laskentasäännöt. Varsinainen kehitystyö aloitetaan vasta, kun tiedot näistä eli edellytykset tekemiselle ovat olemassa.

Varsinaiseen toteutukseen voi liittyä tarpeen mukaan useampia kehityssyklejä ja välikatselmointeja. Kun sovellus on valmistumassa, kehittäjän vastuulla on tehdä yksikkötestaus. Lopullinen hyväksymistestaus on kuitenkin asiakkaan vastuulla. Kunnollisessa testauksessa on määritelty testitapaukset eli mitä ollaan testaamassa. Erityisen tärkeää on datan validointi esimerkiksi perusjärjestelmiä vasten, jolloin pitää ymmärtää, mitä ollaan vertaamassa. Pelkkä datan kokonaistäsmäytys ei myöskään riitä, vaan vertailuja pitää myös tehdä eri dimensioiden suhteen. Testihavaintojen systemaattinen käsittely ja rekisteröinti ovat tärkeitä (myös havaintojen perusteella tehtyjen muutosten ja korjausten osalta).

Hallituu sovelluskehittely Qlikillä

Usein käyttäjiltä tulee testivaiheessa uusia ideoita sovelluksen edelleen kehittämiseksi. Tämä voi pahimmillaan johtaa kierteeseen, jossa sovellusta määritellään testivaiheessa uudestaan ja hiotaan hiomasta päästyään, eikä itse asiassa saada mitään tuotantoon. Monesti fiksuinta on koota nämä kehitysehdotukset yhteen ja projektoida näistä selkeä erillinen paketti. Mikäänhän ei estä kehitysversion tekemistä alkuperäiseen sovellukseen, sen julkaisun jälkeen.

Seuraava laatuporttimme on tuotannointi. Mikä ihmeen tuotannointi? Julkaistaan sovellus ja sillä selvä?

Kun sovelluksia ja käyttäjiä alkaa kertyä, sellaiset asiat kuin Qlik-ympäristön ja sovellusten vakaus ja käytettävyys sekä sovellusten yhtenäisyys muuttuvat kriittisemmiksi. Miten tällaiset asiat sitten varmistetaan? Keskittämällä tuotantoympäristön hallinta ja sovellusten julkaisu saadaan kontrollipiste, jossa voidaan vielä ennen julkaisua varmistua sovelluksen teknisestä toimivuudesta sekä sovittujen periaatteiden noudattamisesta. Näihin periaatteisiin kuuluu esimerkiksi dokumentointi. Vakioidulla ratkaisukuvauksella voidaan varmistaa tarvittavien tietojen löytyminen sovelluksesta myöhemminkin ylläpidon ja mahdollisen jatkokehityksen tarpeisiin. Ylläpito ja kehitys tehostuvat huomattavasti, kun virhetilanteen sattuessa ei tarvitse arvailla, kuinka sovelluksen olisi pitänyt toimia. Toisaalta jatkokehitystä suunniteltaessa datavirrat ja datan muokkaukset on valmiiksi kuvattu, eikä ensimmäiseksi tarvitse ryhtyä salapoliisitöihin näiden selvittämiseksi.

Kun sovellus on näin hallitun prosessin kautta saatu julkaistua käyttäjille, se siirtyy ylläpitoon, mutta ei suinkaan laadunvarmistuksen ulkopuolelle. Laadunvarmistusprosessi jatkuu yhtälailla vielä tuotantovaiheessa. Mahdolliset muutokset ja kehitys sovellukselle tapahtuvat saman prosessin ja periaatteiden mukaisesti kuin varsinainen kehityskin. Versionhallinta ja tuotanto- sekä kehitys-/testiympäristön eriyttäminen vain korostuvat jatkokehityksessä. Kun ympäristö ja sovellukset ovat vielä jatkuvassa seurannassa, voidaan varmistua sovelluksen toimivuudesta ja suorituskyvystä siinäkin tilanteessa, että data- ja käyttäjämäärät kasvavat. Tärkeäksi muodostuu myös toimiva tukiprosessi, jossa mahdollisten virhetilanteiden juurisyyt nostetaan aktiivisesti kehitysehdotuksiksi. Seurantaa luonnollisesti helpottaa, kun tätä varten on olemassa työkaluja, joilla esimerkiksi yksittäisen sovelluksen resurssikäyttöä palvelimella voidaan seurata.