Mobiilirakenduse loomine restoranile

Kuidas käib mobiilirakenduse arendus?

Sissejuhatus

Kas sul on tekkinud mõte luua mobiilirakendus aga ei oska millestki alustada? Või soovid täpsemalt teada saada kuidas ühe mobiiliäpi arendusprotsess välja näeb? Käesolevas artiklis võtamegi ette ühe näidisäpi loomise protsessi alates mobiiliäpi ideest kuni selle allalaadimiseni äpipoest. Siinkohal tasub ära märkida, et samad põhimõtted kehtivad ka veebirakenduste ja kodulehtede tegemisel.

Projekti osad

Infosüsteemide arendamisel on kasutusel erinevaid metoodikaid, kuid suures osas koosneb see järgnevatest sammudest:

  1. Planeerimine
  2. Analüüs
  3. Disain
  4. Testimine
  5. Implementatsioon
  6. Integratsioon
  7. Hooldus

Idee ja mobiiliäpi tegemine

Kujutame ette, et sa oled eduka restorani omanik ning kliendid peavad sinu restorani külastamiseks laua broneerima. Broneerimine käib kas telefoni või näiteks Facebook Messengeri kaudu. Kuna selle info haldamine on keerukas ja nõuab, et keegi sinu töötajatest sellega tegeleks tekib sul äpi idee – oma restorani broneerimissüsteem, mille abil saavad kliendid ise broneeringuid lisada ja muuta. Kuna mobiilirakenduse loomine on sulle võõras ja sa ei kujuta ka ette mis võib olla ühe äpi maksumus siis on mõistlik pöörduda mõne tarkvaraarendusettevõtte, näiteks meie poole. Siit jõuamegi projekti esimese sammu ehk planeerimiseni.

1. Planeerimine

Planeerimine algab tegelikult juba enne töö teostaja poole pöördumist. Planeerimise etapis tehakse kindlaks millist rakendust üldse vaja oleks, mida see peaks tegema ning milliseid väljundeid andma. Koostöös arendajaga täpsustatakse neid mõtteid ja ideid edasi ning otsustatakse kas ja kuidas projekt läbi viiakse. Näiteks tehakse kindlaks millist vajadust peaks loodav mobiilirakendus rahuldama ja piiritletakse loodava süsteemi funktsionaalsus.

Esmalt fikseeritakse projekti skoop – meie mobiilirakenduse näitel on selleks iOS ja Android platvormidel töötav äpp, millega saab broneeringuid lisada ja muuta. Ülejäänu jäetakse skoobist välja ehk selle arendamisega antud projekti raames ei tegeleta. Etteruttavalt võib öelda, et selline skoop on juba eos liiga piirav aga sellest räägime järgmises punktis täpsemalt 🙂

Planeerimise faas on küll kõige esimene samm ja kindlasti ei ole kõik detailid veel selgunud aga äpi tellija soovib saada mingit ajalist raami ja teada mis on äpi tegemise hind. Seega antakse esmased hinnangud projekti tähtajale ja kulule ning seatakse verstapostid.

2. Analüüs

Analüüs on üks olulisemaid etappe ning kahjuks pööratakse sellele tihti kas liiga vähe tähelepanu või jäetakse üldse vahele. Seisukoht “vaatame jooksvalt kuidas välja tuleb ja mõtleme lahendusele siis, kui probleem tekib” viib pahatihti selleni, et osa juba tehtud tööst tuleb ringi teha, suureneb aja- ja närvikulu ning kokkuvõttes tõuseb ka mobiilirakenduse maksumus.

Analüüsi etapis tehakse kindlaks süsteemi nõuded. Kindlasti uuritakse ka alternatiive olemasolevate lahenduste näol – võimalik, et midagi taolist on juba olemas ning seda saab lihtsasti enda vajadustele vastavaks kohandada. Kui sellist võimalust ei ole või oleks see liiga töömahukas siis tuleb mobiilirakenduse arendus ise ette võtta.

Infosüsteemi analüüs peab kindlasti välja tooma ka selle kas uus süsteem üldse lahendab ettevõtte probleeme või tekitab neid pikas perspektiivis hoopis hoolduste ja uuenduste näol juurde.

Lisaks tuleb leida vastused järgnevatele küsimustele:

  • Mida lõppkasutajad uue süsteemi puhul ootavad ja vajavad?
  • Mis on uue süsteemi ülesanded ja mida see peab tegema?

Analüüsi tulemusel peavad tekkima nõuded, piirangud ja soovitatavad lahendused, mille alusel hakatakse uut süsteemi disainima. Kindlasti luuakse ka wireframe’d ehk äpi esmased ja üldised vaated.

Meie broneerimisäpi näitel tuleks esmalt teha kindlaks kas restorani kliendid on üldse piisavalt aktiivsed nutitelefonide kasutajad? Siin on üks hea ja odav lahendus neilt seda lihtsalt küsida – näiteks võib lasta teenindajatel muu jutu sees küsida “kuidas teile tunduks see mõte, kui saaksite meie restoranis laua ise mobiiliäpi kaudu broneerida?”. Sellest lihtsast asjast võib juba päris palju järeldusi teha.

Järgmine samm on mõelda äpi enda ja kogu infrastruktuuri peale. Kui on olemas mobiiliäpp ja klient teeb seal broneeringu siis kuhu see info jõuab? Kas see saadetakse kellelegi e-postile (mis ei vähenda kindlasti töömahtu) või tuleks need tellimused koondada kokku selleks eraldi loodud rakendusse? Kas mobiiliäpis peaks hoiustama ka kasutaja andmeid ja kas neid tuleks hoida kuskil pilves tagavarakoopiana? Ja juba lähebki projekti skoop algselt planeeritust laiemaks. See ongi analüüsietapi eesmärk leida võimalikult palju selliseid aspekte, millele algselt ei oska tähelepanu pöörata ning mille põhjal saab teha edasised otsused.

3. Disain

Infoüsteemi disain koosneb reeglina kahest põhilisest osast:

  • Loogiline disain ehk süsteemi ärilised aspektid
  • Füüsiline disain ehk süsteemi tehnilised aspektid

Disaini käigus leitakse tarkvaraline lahendus analüüsi käigus kogutud nõuetele ja tingimustele. Lahendusi võib olla mitu ning nende hulgast tuleb valida antud olukorras parim. Disaini käigus tuleb jälgida, et süsteem täidaks püstitatud nõuded, kas see sobib kokku teiste platvormidega, millised saavad olema jooksvad kulutused süsteemi tööshoidmiseks jne.

Kindlasti tuleb juba disaini etapis arvestada süsteemi turvalisusega mitte testida seda hiljem ja seejärel turvaauke parandada.

Ärilisi aspekte tuleb silmas pidada, kui disainitakse andmevoogusid ja näiteks kasutajaliidest. Ehk rakenduses toimuv peab vastama ettevõtte äriloogikale ja seda toetama mitte sundima asjatult protsesse muutma.

Sarnaselt analüüsile võib ka disainietapis projektiplaanis muudatusi toimuda. Näiteks võib selguda, et mingeid äpi osasid ei olegi vaja või peaks midagi juurde lisama. Tihti selgub ka töö käigus, et millegi arendamiseks kulub planeeritust rohkem/vähem aega.

4. Implementatsioon

Implementatsiooni etapis toimub vajaliku riistvara ja tarkvara installeerimine ning programmeerimine ehk äpi arendus. Selles etapis toimub ka valminud osade paigaldus ning vähemalt osale kasutajatele kättesaadavaks tegemine. Selle eesmärgiks on ühest küljest saada kiirelt tagasisidet ning teisest küljest anda juba võimalus uue süsteemi võimalusi kasutada.

Mobiiliäpi näitel laetakse esmane versioon ka äpipoodidesse üles ja tehakse testkasutajatele kättesaadavaks. Meie näitel võib selle võimaluse anda ka näiteks restorani püsiklientidele, kes on sellisest võimalusest kindlasti meelitatud.

5. Testimine

Testimine algab tegelikult juba jooksvalt programmeerimise käigus ehk testid kirjutatakse jooksvalt koodi sisse. Olenevalt süsteemi keerukusest võib testide hulk olla väga erinev. Väga lihtsa süsteemi puhul jäetakse aja- ja rahalise ressursi tõttu tihti automaattestid kirjutamata ning süsteemi testivad inimesed ise.

Testimise käigus kinnitatakse, et loodud süsteem vastav nõutud kvaliteedile. Tarkvaraarenduses on tavaline, et kõiki vigu ei parandatagi kuna need ei sega süsteemi kasutamist ning iga väiksema paranduse tegemine ei ole rahaliselt mõõtes mõstlik ehk kokkuvõttes jäävad need vead nõutud kvaliteedi sisse.

6. Integratsioon

Integratsiooni käigus tehakse viimased liidestused teiste süsteemidega ning alustatakse kasutajate koolituse, dokumentatsiooni koostamisega. Äppi ei tule integreerida mitte ainult väliste süsteemidega vaid tihti ka ettevõtte siseste süsteemidega, näiteks olemasolevad rakendused, WordPressil baseeruv koduleht ja muu taoline. Integratsioon toimub ka ettevõtte enda protsessidega ehk kuidas ja millistes tööetappides peaksid inimesed uut lahendust kasutama, sest nagu me teame on paljud inimesed harjunud olemasolevate töövahendite ja teadmistega ning iga uus asi on esmalt võõras ja hirmutav.

Integratsiooni etapp lõpeb lõpetamisdokumendi ehk akti allakirjutamisega ning vajadusel edasise plaani kokkuleppimisega. Üleandmisaktiga algab garantiiperiood ning fikseeritakse saladuse hoidmise kohustus.

7. Hooldus

Olenevalt süsteemist võib olla vajalik ka järelhooldus või hilisem laiendamine uute arenduste näol. Näiteks võib tekkida vajadus algselt mõne kasutaja jaoks loodud süsteemi skaleerida selliselt, et seda saaks kasutada tuhanded inimesed korraga. See eeldab arhitektuuri ülevaatamist ja vajadusel muutmist ning tõenäoliselt ka riistvaralise poole täiustamist.

Kokkuvõte

Selles artiklis vaatasime üle, kuidas käib ühe mobiilirakenduse tegemine projektina. Tuleb välja, et see ei olegi nii lihtne, kui esmapilgul paistab ning planeerimist ja analüüsi on isegi rohkem, kui arendustööd ennast.

Meeles tuleb pidada seda, et kogu süsteemi kvaliteet sõltub programmeerimise ja testimise kvaliteedist, mis sõltub disaini kvaliteedist ja mis omakorda sõltub analüüsi kvaliteedist. Seega ei ole ühe rakenduse loomine pelgalt kasutajaliideses kastide õigesse kohta lohistamine nagu võimaldavad paljud “Tee ise äpp” lahendused.

Kui kogu eelnev ülevaade ei hirmutanud Sind liigselt ära ja soovid enda mobiilirakenduse või muu infosüsteemi arendusega edasi minna võta meiega julgelt ühendust kontaktivormi kaudu.

Photo by Natanael Cuenca on Unsplash