Näin luodaan räätälöity sovellus

Sovelluskehitys on itseään toistava prosessi

Piirtäisitkö minulle talon, jossa on kolme ikkunaa, katto ja ovi? Mielellään punaisen. Kiitos!

Arkkitehdin on tässä vaiheessa kysyttävä vielä monta tarkentavaa kysymystä. Millaiset asukkaat talo saa, entä kuinka monta heitä on? Rakennetaanko talo kallion päälle vai savipatjalle? Millainen infrastruktuuri tontilla on; löytyykö kunnallistekniikkaa, vai pitääkö kaikesta huolehtia itse? Kuinka tiukasti kaava määrittää talon ulkomuodon?

Myös sovelluskehityksen alkuvaiheessa voi olla vaikeaa ymmärtää ja hahmottaa, miten esitetty idea, konsepti tai näkemys toimii käytännössä, kun kaikkia toiveita, tarpeita tai rajoituksia ei ole tiedossa, eikä piirustusta tai kokeiltavaa mallia ole.

Räätälöidyn sovelluksen toimivuutta on hyvä testata ennen varsinaisen tekemisen aloittamista. Hankkeen haastavuus, laajuus tai esimerkiksi taustajärjestelmien monimutkaisuus voi muuten yllättää kesken kehitysprojektin.

Käyttäjien lukuisat toiveet, tarpeet ja vaatimukset voivat myös hukuttaa ydinajatuksen alleen, ja niiden priorisointi olla vaikeaa.

Koska järeä ohjelmistosuunnittelu- ja kehitys on aikaa vievää (ja harvoin myös halpaa), on järkevintä aloittaa yritykselle räätälöidyn sovelluksen tekeminen testaamalla ja varmistamalla, onko valittu lähestymistapa oikea.

Räätälöidyn sovelluksen eri testaustavat

Proof of Concept eli POC

Proof of Conceptissa uusi idea, malli tai oletus testataan pienimuotoisesti. Räätälöidyn sovelluksen POCin aikana voidaan esimerkiksi selvittää, onko toiminnallisuuden X toteutus mahdollinen, tai keskusteleeko teknologia X teknologian Y kanssa.

Lopputuotteena syntyy selvitys tai dokumentti, joka tiivistää oletuslähtökohdan sekä POCin aikana tehdyt päätelmät sovelluksen jatkokehitysmahdollisuuksista.

Jos jatkamme talovertausta, POCin aikana arkkitehti olisi selvittänyt kunnallistekniikan ja kaavan vaatimukset, ja haastatellut asukkaat heidän toiveidensa kartoittamiseksi. Voidaanko unelmien talo, eli räätälöity sovellus edes ylipäätään tehdä, kyllä vai ei?

Lue lisätietoja Systems Gardenin tavasta toteuttaa räätälöityjen sovellusten Proof of Concept.

Prototyyppi

Prototyypin rakentaminen taas on räätälöidyn sovelluksen POCia laajempi harjoitus, jonka avulla visualisoidaan sovelluksen toimintaa. Sen lopputuotteena on malli, joka antaa käsityksen räätälöidyn sovelluksen käyttöliittymästä, navigoinnista ja ulkoasusta.

Prototyypit voivat niiden laajuuden mukaan olla luonnosmaisia, joskus paperille piirrettyjä hahmotelmia, tai interaktiivisia käyttöliittymädemoja.

Arkkitehti piirtäisi talon ensimmäisen prototyypin paperille, ja mahdollisesti rakentaisi talosta myös karkean pienoismallin, aivan kuten sovelluskehittäjä rakentaisi räätälöidyn sovelluksen prototyypin testaamaan sen toimivuutta. Lue lisää prototyypin kehittämisestä täältä.

POC osoittaa, onko tuote, idea tai ominaisuus on jatkokehityskelpoinen, kun taas prototyyppi näyttää, kuinka se tehdään.

Ensimmäisiin prototyyppeihin ei ole tarkoitus sitoutua. Se on yksi monista sovelluksen tekemisen askeleista. Prototyyppi luodaan, sitä testataan ja kerätään tulokset, ja sen jälkeen hanke menee vielä kerran suunnittelun läpi.

Prototyyppi on ennen kaikkea keino kerätä tietoa:

• Kuinka paljon työtä räätälöidyn sovelluksen kehittäminen vaatii?
• Millaisilla teknologioilla se kannattaa rakentaa?
• Palveleeko lopputulos liiketoimintaa ja loppukäyttäjiä, entä onko hanke kokonaisuudessaan kannattava?

Räätälöidyn sovelluksen tekeminen ei myöskään ole helpoin mahdollinen projekti, mutta kokemuksen perusteella osaamme välttää pahimmat sudenkuopat.

Mitä seuraavaksi testaamisen jälkeen?

Testauksen jälkeen sovellus palautetaan takaisin suunnittelupöydälle, ja mietitään mitä tehdään, ja mitä kenties jätetään tekemättä.

Havainnot, tarpeet ja ominaisuudet kootaan suunnitelmaksi. Teemme yhdessä listan ominaisuuksista, jotka räätälöidyssä sovelluksessa on oltava. Niiden perusteella arvioimme tarvittavien sprinttikierrosten määrän, ja teemme työmääräarvion kierrosten määrään perustuen. POC tai prototyyppi tekee arviosta luotettavamman.

Kun suunnitelmasta ja toteutusarviosta on sovittu hyvässä yhteisymmärryksessä, edetään sprinttimallilla vaiheittain maaliin.

Kaikkia ominaisuuksia ei ole tarkoitus toteuttaa kerralla, vaan etenemme tuttuun Scrum-tyyliin pala kerrallaan.

Mikäli räätälöidyn sovelluksen toiminnallisuuksien määrä lisääntyy projektin aikana, tai sprinttikierrosten määrä kasvaa, tuumimme yhdessä, miten haluttuun lopputulokseen päästään projektin tavoitteiden, aikataulun ja budjetin puitteissa.

Niin kuin talonrakennuksessakin, yllätyksiä saattaa tulla vastaan sovelluksen tekemisen aikana. Tärkeintä on säilyttää avoin keskusteluyhteys, ja yhdessä priorisoida tarpeita ja vaatimuksia projektin edetessä.

Tutustu ketteriin ohjelmistokehityksen palveluihimme ja löydä parhaat ratkaisut juuri teille.