18. aprill 2016

Tähelepanu! Artikkel on enam kui 5 aastat vana ning kuulub väljaande digitaalsesse arhiivi. Väljaanne ei uuenda ega kaasajasta arhiveeritud sisu, mistõttu võib olla vajalik kaasaegsete allikatega tutvumine.

IT-TÖÖJÕUKRII S

Kuidas leida parim IT-töötaja oma firmasse?

Konverents toimub 12.05.Hotellis Meriton, Toompuiestee 27

Tutvu programmiga ja registreeru SIIN.

 „Ekslikult arvatakse, et tarkvara loomine on ainult arendaja mure, kes peab ise oskama süsteemi nullist üles ehitada ning teadma kõikidele küsimustele vastuseid,“ selgitas Aavik ning lisas, et tegelikkuses tuleb tarkvara soetaval ettevõttel endal põhjalik eeltöö ära teha, et lõpptulemus oleks eesmärgipärane.

Aaviku sõnul tuleb projekti õnnestumiseks silmas pidada järgmisi nõuandeid:

1. Analüüsi põhjalikult tarkvara loomise majanduslikku edukust

Enne tarkvara soetamist tasub põhjalikult analüüsida, millist protsessi tarkvara peaks asendama, muutma või looma. Vahet tuleb teha selles, kas tarkvara eesmärk on luua uut võimekust, uusi ärivõimalusi või muuta juba olemasolevat protsessi efektiivsemaks. Samuti tuleb välja arvutada oodatav rahaline kulu ja tulu, kui kiiresti peaks projekt end ära tasuma ning kuidas investeeringutega väärtust luuakse. Kindlasti on oluline kalkulatsiooni lisada ka nähtamatud kulud nagu hoolduskulud, tuleviku lisaarendused, turvalisuse tagamine, tehnoloogia areng ning tarkvara platvormide uuendamise vajadus.

2. Kaasa töötajad ning määra vastutajad

Tarkvara arendusse tuleb kaasata projekti ettevõtte töötajad, kes peavad olema teadlikud, et projekt on ettevõtte jaoks prioriteetne.

Lisaks tuleb äri poolelt määrata projekti eest vastutaja, kellel on õigus ka sisulisi otsuseid vastu võtta. Kui projekt hõlmab erinevaid ärivaldkondi, tuleb määrata vastutaja igast valdkonnast. Samuti tasub kaasata töögrupi näol kõik osapooled, kes suudavad anda projektile sisendit või kelle tööd loodav tarkvara mõjutab, sest vaid nii on protsessist ja tulemusest reaalne kasu.

3. Koosta lähteülesanne ning riskianalüüs

Enne tarkvara hankimist tasub koostada lähteülesanne ehk taustinfo koos nõuete nimekirjaga, kus on lahti seletatud ootused ärifunktsionaalsuse, turvalisuse, jõudluse, kasutatavuse jms osas.

Samuti tuleb teha riskianalüüs, mis toob välja projekti ohustavad suurimad sisesed ja välised nõrkused ning võimalused riskide maandamiseks. Kindlasti peaks riskianalüüsi hoidma ajakohasena kogu projekti kestel.

4. Arendamisel pane rõhku tarkvara kasutatavusele

Tarkvara arendamisel peab põhirõhk olema kasutatavusel – mida kergem on tarkvara kasutada, seda efektiivsem on selle kasutaja (töötaja).

Seetõttu on oluline süveneda arendaja esitatud küsimustesse ning vastata neile, sest mis võib esmapilgul tunduda ilmne, ei pruugi seda olla kellelegi väljastpoolt valdkonda. Olulist rolli tarkvara arendamise juures mängivad ka tarkvara demosessioonid. Mida põhjalikum tagasiside demosessioonidel anda, seda paremini saab arendaja ootustele vastata. Demosessioone tasub korraldada vähemalt iga kahe nädala tagant.

Lisaks tasub planeerida aega ning ressurssi vastuvõtutestimisele, mille raames kontrollitakse tarkvara funktsionaalsuse vastavust ärinõuetele. Mittefunktsionaalsete nõuete nagu koormustaluvus ja kasutatavus jaoks on mõistlik kasutada eksperdi abi. Testimisse tasub kaasata ka tulevased kasutajad, mille boonuseks on kasutajate varane tutvus programmiga ja põhjalikum tagasiside, mida arendusel arvesse võtta.

5. Nõua arendajalt parimatele praktikatele vastavat teostust

Projekti õnnestumiseks tuleb arenduspartnerilt küsida detailset arendusgraafikut, mis võimaldab jälgida projekti käiku ning saada võimalikult varakult teada kõrvalekalletest. Lisaks on vajalik arendajapoolne riskianalüüs, kust potentsiaalsed projekti ohustavad probleemid ning nende maandamisviisid arendaja poolt ära kaardistatakse.

Samuti tasub kokku leppida etapiviisiline tarne, sest varajane tutvus arendatava programmiga võimaldab anda täpsemat tagasisidet ning jaotada vastuvõtuga seotud töökoormus pikema perioodi peale. Lisaks peab arendaja järgima häid arendustavasid nii koodi kirjutamises, koodihalduses kui projektihalduses ning tegelema aktiivselt kvaliteedijuhtimisega. Mida varem viga avastatakse, seda kergem ja odavam on seda parandada.

Ära ei tohi unustada ka dokumentatsiooni, mis peab olema eelkõige kvaliteetne ning kirjeldama lühidalt ning täpselt, kuidas süsteem on üles ehitatud, sest see on aluseks edaspidistele uuendustele ja täiendustele. Samuti aitab dokumentatsioon ära hoida ka niinimetatud tarnija lõksu jäämist, kus kogu teadmus, kuidas tarkvaralahendus on üles ehitatud, kuidas seda edasi arendada või vigu parandada, on vaid ühe arenduspartneri käes. Maja ehitades ei oleks ka keegi nõus, et kõiki hooldustöid tuleks kogu kasutatava eluea jooksul tellida ühest ettevõttest.

Kui ettevõttes puudub eelnev tarkvara arenduse kogemus tasub projekti kaasata ka kolmas osapool ehk järelevalve, kes oskab seista Sinu õiguste ja vajaduste eest ning toetab ühise keele leidmisel. Rääkimata tehnilisest korrektsusest.

Andres Aavik