Navigeerimine tarkvaraarendus elutsüklis

Kas oled kunagi mõelnud, kui palju närve, pisaraid ja kaost sinu lemmikrakenduse loomiseks kuluda võis? Kujutle sellist pilti: grupp säravaid mõtlejaid, igaühel enda omapärad, oma isiksus. Lisame siia nüüd veel tiksuva kella ja kliendi, kelle soovid ja tahtmised on sageli reaalsusest kaugel.

Selles artiklis paljastame, mis toimub kulisside taga – räägime tarkvaraarenduse struktuurist ja vaatame üle ka mõned inimestega seotud teemad, mis lisavad kogu protsessile veel oma võlu. Võta nüüd lugemisasend sisse ja saa hea ülevaade tarkvaraarenduse elutsükli üksikasjadest.

Mismoodi tarkvaraarenduse elutsükkel üldse välja näeb?

Iga tarkvaraarendusettevõte vajab rakenduste ja programmide loomiseks tegevuskava. Sellest võib mõelda kui sammudest, mis juhivad ettevõtte läbi kogu arendustsükli. Mõnel on ees kindel kava, näiteks Agile, PMI või Waterfall, mõni kasvav ettevõte soovib aga asjale veidi vabamalt läheneda ja rohkem improviseerida. Ükskõik, mille kasuks ka otsustatakse, kindel protsess aitab kindlasti asju paremini organiseerida ja tõhusamalt korraldada.

Erinevad meetodid võivad küll mõningaid nüansse muuta, kuid suures plaanis seisab enamik tarkvaraettevõtteid oma arendusprotsessides silmitsi sarnaste probleemidega. Tutvustades Net Groupi protsessi, tutvustame ilmselt ka paljusid teisi meiesuguseid ettevõtteid, kus on kasutusel sarnased protsessid. Vaatame nüüd neid tarkvaraarenduse elutsükli etappe lähemalt, mis meie arvates meie valdkonda üldisemalt iseloomustavad.

1. etapp: projekti planeerimine

Meie Net Groupis alustame oma tarkvaraarenduse tsüklit süsteemse lähenemisega, mis on kooskõlas Project Management Institute’i (PMI) metoodikaga. Algetapis seame esikohale integreeritud projektide tehnilised aspektid ja ka sotsiaalse dünaamika. See tähendab ressursside põhjalikku läbivaatamist, projekti kavandamist ja eelarvestamist ning riskihindamist.

Riskihindamise etapis vaatame peamiselt neid asju, mis võivad projekti plaani või ajakava oluliselt muuta. Kontrollime üle ka kliendi ressursid, mis on projekti juures olulised. Projektijuht tagab, et projektiga töötav tiim saab nõuete kohta piisavalt infot ja ka muud tagasisidet, mis võib projekti mõjutada.

Kui esimese koosoleku ajal selgub midagi, mille tõttu tuleb projekti üksikasju muuta, märgime sellised muutused projekti kirjeldusse. Pärast seda täpsustame kõik uuesti üle ja koostame projekti jaoks uue plaani, mille kooskõlastame kõigi huvigruppidega.

2. etapp: disain ja arendamine

See on see osa, kus planeerime ja loome seda, milles planeerimisetapis kokku leppisime. Kõigepealt koostame tarkvara spetsifikatsioonidest disainikava. Loomulikult vaatavad kõik olulised osapooled disaini üle, annavad tagasisidet ja käivad välja ideid selle täiustamiseks. Kõigi heakskiit tuleks saada nii kiiresti kui võimalik. Kui siin mõne asja tähelepanuta jätame, võib see meile hiljem kulukalt ja närvesöövalt kätte maksta. Ning seda ei taha ju keegi.

Kui roheline tuli on antud, hakkame reaalselt tarkvara looma. Iga arendaja lähtub plaanist, milles me kõik kokku leppisime. Paigas peavad olema selged reeglid, nagu milline peaks kood välja nägema ja millist stiili me kasutame. Näiteks reeglid selle kohta, kuidas faile nimetada, kuidas infrastruktuur peaks arendusetappi toetama, kuidas tiimid peaks koostööd tegema jne. See võimaldab tiimil luua selget ja korrektset koodi ning lihtsustab ka järgmises etapis selle mõistmist ja testimist.

3. etapp: testimine

Järgmiseks paneme pähe detektiivimütsid ja otsime koodis vigu või kohti, mis ei vasta nõutule. Näeme kõvasti vaeva ja kõrvaldame need vead, kuni meie looming vastab algselt kavandatule. Lihtsamalt öeldes tahame veenduda, et kood vastab meie kehtestatud reeglitele. 

Meie tiim kasutab tarkvaras vigade leidmiseks segu peenest automaatikast ja käsitsi testimisest. Samuti vaatame tarkvara üle sellise pilguga, et kas lisaks hästi töötamisele vastab see kõigele, mida meie klient soovis.

4. etapp: juurutamine

Siin on eesmärk anda tarkvara käiku reaalsetele kasutajatele reaalses maailmas. Mõni tiim soovib enne suurt debüüti veel erinevates testimis- või proovikeskkondades väikeseid boksipeatusi teha. Nii saavad kõik asjaosalised toodet näha ja enne selle turule jõudmist on võimalik veel viimased murekohad kõrvaldada.

Tarkvara arendamisel tehakse kogu kodeerimine ja testimine ära eraldi versiooni peal, mitte sellel, mille kasutaja enda kasutusse saab. Kasutaja pääseb ligi lõppversioonile, arendustiim kasutab „ehitamise“ või „testimise“ faasi versiooni.

Kui need versioonid eraldi hoida, saab kasutaja tarkvara kasutada ka siis, kui meie seda parasjagu veidi häälestame või uuendame. Juurutamise juurde kuuluvad mitmed ülesanded, nagu uusima versiooni valmis seadmine ja veendumine, et lõpptulemuses on kõik korralikult olemas ja töökorras.

Karm reaalsus protsessi taga

Esiteks, tarkvaraarenduse planeerimise etapis võib aset leida kommunikatsioonilõhe (1). Kujutle, et hakkad tellima oma lemmikkatetega pitsat, aga eeldad, et kokk juba teab, mis sulle meeldib, nii et sa ei pea seda talle ütlemagi.

See on natuke sarnane olukorraga, kus klient ja arendaja püüavad üksteise öeldut tõlgendada. Klient ei oska oma soove võib-olla kõige täpsemini väljendada ja jätab seega palju ruumi vabaks tõlgendamiseks. Ilma selge infovahetuse plaanita – aga ka siis, kui see paigas on – tekitab selline olukord vahel projekti alguses stressi.

Kui algab arendusetapp… noh, see on koht, kus probleemid alles pihta hakkavad. Sul on originaalsete ja iseseisvate mõtlejate tiim, kus igaühel on oma iseloom ja omapärad ning kus seetõttu tekivad vaidlused.Tiimiliidrite jaoks on arendajate juhtimine (2) vahel nagu teismeliste haldamine – üks möllab ringi, teine uneleb nurgas, kolmas ütleb, et ta ei taha Valio juustu (Microsoft) asemel juustupulkasid (Apple) süüa. Liidame siia nüüd veel ülima intelligentsi ja saamegi tulemuseks reaalse arendajate tiimi dünaamika. Ütleme lihtsalt nii, et kõigi nende erinevate energiate balansseerimine on omaette kunst.

Peale selle on ka tehnoloogiatrendide haldamine (3) pehmelt öeldes keeruline. Kujutle tehnikamaailma kui dünaamilist malelauda. Sinu käik võib küll olla strateegiline ja ettenägelik, kuid just siis, kui oled omast arust üks samm ees, ilmub kusagilt mingi uus nupp ja kogu laua seis muutub, muutes ka mängu reegleid. Tuleb mõni uus raamistik või keel, AI/ML, 5G võrk, küberturbe strateegia, uued arengud IoT-s.

Arendamisega seotud inimesed teavad liigagi hästi, mida tähendab võidujooks ajaga. Asi ei ole ainult sammu pidamises, vaid ka tagamises, et sinu tehnoloogia ei muutuks juba lähitulevikus antiikseks.

Tegelikult seisab tiimidel pidevalt ees ka muid dünaamilisi muutusi (4). Tarkvaraarenduse valdkonna kiires tempos põrkab tarkvaraarenduse elutsükli teoreetiline elegants sageli kokku selle juurutamise karmi reaalsusega. Tuleb teha enamat kui vaid kohaneda tehnoloogia muutustega. Turutingimused muutuvad, projektiga liituvad uued inimesed, muutuvad ka projektijuhtimise tööriistad jne. On ütlematagi selge, et suuremates IT-ettevõtetes ei ole tarkvaraarendusel ainult üks elutsükkel … Neid on kümneid ja need kõik võitlevad ressursside eest ning püüavad oma prioriteete läbi suruda.

Ja viimaseks räägime ühest uusimast väljakutsest ehk kaugtööst (5). Üha rohkem tiime tegutseb erinevatest kohtadest, nii et suhtlemine ja koostöö on muutunud veidi keerulisemaks. Nüüd on seega eriti tähtis tagada, et kõik järgiks samu kodeerimisreegleid ja suhtleks omavahel. Õnneks on see trend pigem rõhutanud protsessile suunatud töö tähtsust.

Viimased mõtted

Oleme tarkvaraarenduse elutsükliga seoses rääkinud sellest, kuidas erinevate väljakutsetega hakkama saada ja kuidas klientide soove realiseerida. Asi ei ole ainult koodi kirjutamises või vajalike etappide läbimises, vaid planeerimise, loomise ja testimise järel lõpuks reaalse toote ellu toomises. See on nagu pusle kokku panemine, kus iga tükk alates kliendisuhtluses ette tulevatest takistustest kuni dünaamiliste tiimide juhtimise ja tehnoloogiliste muutustega arvestamiseni keerab väljakutsele vinti juurde ja toob lisapõnevust. 

Lõpetuseks pea meeles, et iga rakenduse või programmi taga on lugu paindlikkusest, kohanemisest ja väsimatust püüdlusest parima nimel. Elagu tarkvara arendamise kunst ja teadus!