Arendus- ja ärimudelid

Antud nädala teemaks oli analüüsida konkreetsete projektide näitel ühte arendus- ning ühte ärimudelit.

QGIS on vabavaraline GIS (Geographic Information System) tarkvara, mis toimib GNU GPL litsentsipõhimõtete alusel. QGIS on OSGeo (Open Source Geospatial Foundation) ametlik projekt ning selle plussiks omandvaralise ESRI ArcGISi ees on just see, et see on kasutatav ka Mac OSX, Linuxi ja Unixiga operatsioonisüsteemidega. 
QGISi ärimudel põhineb annetustepõhisel skeemil - valmis on arendatud hästi toimiv vägagi funktsionaalne süsteem, mis pakub tõsist konkurentsi omandvaralisele ArcGIS-ile. Kuid selleks, et parandada rakenduse kvaliteeti, on võimalik teha annetusi. QGIS on oma veebilehel toonud välja, et saadud annetused võimaldavad neil:

• motiveerida arendajaid, et nad töötaksid spetsiifilisemate teemadega ning arendaksid uusi funkstionaalsusi; 
• rahastada arendajate kokkusaamisi - eesmärgiks oleks kaks arendajate koosolekut aastas;
• toetada täiendavat vigade testimist enne uute versioonide väljatulekut.

Arendusmudelite juures olen ise kõige enam kokku puutunud kosemudeliga ja saanud tunda/näinud selle mudeli ühte peamist puudust - jäikust. Tradistiooniline kosemudel käib siis järgmise skeemi järgi: Analüüs -> Disain -> Arendus -> Testimine -> Hooldus. Suurte avaliku sektori projektide puhul on selline mudel väga tavaline ja eks see ole ka üks põhjuseid, miks arendatavad rakendused on vigasid täis ja ei täida ettenähtud funktsionaalsusi. Siin mängib kindlasti rolli ka analüüsi jaoks sisendit andvate ja seda läbiviivate inimeste kompetentsus - kui klient ei tea täpselt, mida ta soovib või ei oska kõiki oma soove ette näha, siis ei ole selline arendusmudel soovitatav (pigem võiks valida midagi iteratiivset).

Üks konkreetne näide - umbes kolm aastat tagasi lasime arendada Statistikaameti kaardirakenduse (http://kaart.stat.ee ). Võrreldes teiste arendusprojektidega, mis meil majas tol ajal töös olid, oli kaardirakenduse ärianalüüsi pool üsna põhjalik.  Seega ei põdenud me väga seda, et peame projekti valdavalt kosemudeli põhimõttel läbima - teadsime ju täpselt, mida me saada tahame :) . Praeguseks oleme igapäevase töö käigus avastanud kõiksuguseid väikseid nüansse, mida rakendus ei tohiks üldse teha - näiteks on võimalik mingeid liugureid nihutada seal, kus neid ei tohiks saada nihutada ning neid lausa üksteise peale tõsta. Need on küll väiksed vead, mis üldist funktsionaalsust ei sega aga igapäevase kasutamise korral hakkavad ikka häirima. Aga kust oleksid pidanud mitte IT taustaga spetsialistid oskama sellist asja ette näha? Ja justnimelt siinkohal tahangi välja tuua kosemudeli jäikuse tagamaad - kasutajad saavad funktsioneeriva rakenduse kätte alles lõppfaasis, kus tavaliselt riigihangete puhul ei ole enam aega mitmekuulist testimist teha (rääkimata veel kasutatavuse testimisest!). Ja isegi kui siis selguvad mingid vead, siis olenevalt vea kriitilisusest, käkerdatakse mingi ajutine "lip-lipi ja lap-lapi peal" lahendus kokku, mis üldiselt mingi aja pärast hakkab hoopis kolmandat viga põhjustama. Ehk siis loo moraal - kasutajate kasutusharjumuste monitoorimine ja testimine on samuti väga oluline osa tarkvaraarendusest ning aitab oluliselt vähendada just selliste vigade arvu, mida rakenduste kasutajad ei oska projekti alguses uneski näha. Paraku ei mahu sellised täiendavad testimised kosemudeli alusel läbiviidava tarkvara arenduse ajakavasse.

Allikad:
http://qgis.org/en/site/