Kaks erinevat lähenemist tarkvaraarendusele

Tarkvaraarendus on keeruline, selle juhtimine on väljakutse ja läbikukkumise tõenäosus suur.

Vaatame kahte erinevat tarkvaraarenduse protsessi.

 Traditsiooniline tarkvara arendusprotsess

  1.  Tellija koostab koos analüütikuga detailse ülesandepüstituse, mis on tarkvara arenduslepingu oluline osa.
  2. Ülesandepüstituse järgi alustab tööd lahenduse arhitekt, kes loob tarkvaralahenduse arhitektuuri. Suure tõenäosusega erineb arhitektuur mingis osas  ülesandepüstituses kirja pandust – st tekib viga.
  3. Pärast arhitekti asub tööle disainer, kes disainib erinevad ekraanipildid.  Siin võib samuti tekkida erinevus algsest ülesandepüstitusest.
  4. Järgneb tarkvara arendusprotsess, kus realiseeritakse lahendus vastavalt loodud arhitektuurile ja disainile. Ka siin võib ilmneda vigu.
  5. Lõpuks testitakse loodu vastavust ülesandepüstitusele.

Ilmnenud puudused funktsionaalsuses kõrvaldatakse muudatuste abil.

Milles on probleem?
Loodud lahendus erineb enamusel juhtumitel algsest ülesandepüstitusest. Mida suurem on projekt, seda suurem on viga.

Keegi ei suuda ülesande püstitusel täpselt öelda, mis on tegelikult vajalik lahenduse funktsionaalsus ja mida tegelikkuses keegi kasutama ei hakka.

Standish Gruppi läbiviidud uurimusest selgub, et üle poole arenduse funktsionaalsusest ei kasutata kunagi!
Seega traditsionaalse arenduse puhul tehakse suur töö ära, ja siis hakatakse tellima muudatusi lisatööna.
See viib projekti kallimaks ja lõpptähtaja hilisemaks, kusjuures osa töö tulemusest ei leiagi praktikas kasutust.

 Paindlik (agiilne) tarkvara arendusprotsess

Tellija ja arendaja vahel sõlmitakse paindlik leping, mis määratleb koostöövormi põhimõtted, kaasa arvatud lepingu ennetähtaegse lõpetamise võimaluse.

Ülesandepüstitus on tellijal olemas, aga see ei pea olema väga detailne. Pigem on tegemist visiooniga. Koostöö tellija ja arendaja vahel on etapiviisiline. Realiseeritakse kiirelt üks etapp – näiteks lahenduse üks visuaalne osa ja kohe kontrollitakse tellija peal üle – kas see on see, mida tegelikult on vaja!

Ja nii edasi, kuni kas projekt on realiseeritud, või on selgunud, et sellist lahendust tellijal tegelikult polegi vaja. Viimasel juhul katkestatakse leping ennetähtaegselt, ja tavaliselt makstakse arendajale mingi protsent arenduse plaanitavast lõpphinnast kompensatsiooniks. Ka selline  juhtum on tellija jaoks kasulikum, sest ei raisata mõttetult raha ega aega.

 Paindliku tarkvaraarenduse eelised:

  • Otsuseid saab teha kiirelt kogu arendusprotsessi jooksul.
  • Tellijal on selgem arusaam loodava lahenduse tegelikust vastavusest soovitavale.
  • Protsessi käigus tekib just selline lõppprodukt, mis on tellijale vajalik.
  • Kui selgub, et projektiga pole mõtet edasi minna, saab selle lihtsalt lõpetada, ja kaotus pole nii suur kui tavaprotsessi korral.

 Kindlasti on ka paindlikul meetodil oma puudused, mistõttu pole seda alati võimalik rakendada:

  • Tellija ja arendaja vahel peab olema usalduslik suhe, et saaks selliselt projekte realiseerida
  • Tellijal peab olema tellitava lahenduse selge visioon ja detailide mõistmise võimekus
  • Tellija peab olema väga aktiivselt projektis kaasas, tal peab olema selleks aega
  • Leping peab olema vormistatud paindlikule arendusele sobivas vormis

 Üheks paindliku tarkvaraarenduse meetodiks on SCRUM, aga sellest juba edaspidi.

Enno Veikesaar
teenuste juht




Sulge