• OMX Baltic−0,06%269,85
  • OMX Riga0,03%867,91
  • OMX Tallinn−0,05%1 710,42
  • OMX Vilnius0,05%1 055,53
  • S&P 5000,88%6 087,72
  • DOW 30−0,1%44 201,97
  • Nasdaq 1,8%20 040,99
  • FTSE 1000,26%8 301,62
  • Nikkei 2250,01%39 372,23
  • CMC Crypto 2000,00%0,00
  • USD/EUR0,00%0,95
  • GBP/EUR0,00%1,21
  • EUR/RUB0,00%110,71
  • OMX Baltic−0,06%269,85
  • OMX Riga0,03%867,91
  • OMX Tallinn−0,05%1 710,42
  • OMX Vilnius0,05%1 055,53
  • S&P 5000,88%6 087,72
  • DOW 30−0,1%44 201,97
  • Nasdaq 1,8%20 040,99
  • FTSE 1000,26%8 301,62
  • Nikkei 2250,01%39 372,23
  • CMC Crypto 2000,00%0,00
  • USD/EUR0,00%0,95
  • GBP/EUR0,00%1,21
  • EUR/RUB0,00%110,71
  • 15.02.05, 00:00
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

Tarkvara tellimisele eelneb vajaduste analüüs

Kui ettevõttes kasutatav tarkvara pole piisav äriprotsesside toetamiseks või on seni Exceli tabelites peetav arvestus äritegevuse edenedes hakanud tegevust pidurdama, on õige aeg pöörduda tarkvaraarendajate poole sobiva lahenduse leidmiseks.
Võib juhtuda, et ettevõttes on aru saadud, et midagi on vaja ette võtta, kuid seda ei osata selgelt defineerida. Kas on see mõistlikul kujul Exceli kasutuselevõtt, olemasoleva süsteemide liidestamine või uue tarkvaratüki loomine?
Sel juhul on otstarbekas ettevõttes lasta läbi viia süsteemianalüüs, mille käigus kaardistatakse kogu ettevõtte (või mõne sektori) äriprotsessid, protsessides liikuv info ja vahendid (ka tarkvara), mille abil informatsiooni juhitakse. Kui ettevõttes on kasutusel (või ostetud, kuid ei kasutata) tarkvara, siis annab analüütik hinnangu selle kasutatavusest ja potentsiaalist äriprotsesside toetamisel. Analüüsi olulisimaks väljundiks on kirjeldus, milliseid meetmeid on võimalik rakendada äriprotsesside parendamiseks, ja koostöös tellijaga fikseeritud võimalikud tarkvaraarendused.
Kui olete veendunud, et mingi protsessi juhtimiseks on nõutav uue tarkvara loomine, soovitan ikkagi alustada analüüsist. Sellisel juhul viiakse läbi tarkvaranõuete analüüs, mille käigus kaardistatakse loodavale tarkvarale esitatavad funktsionaalsed ja mittefunktsionaalsed nõuded. Funktsionaalsete nõuete all mõeldakse detailset kirjeldust, mis tegevusi peab tarkvara eri kasutajagruppidele võimaldama. Mittefunktsionaalsete nõuete all peetakse silmas nõudeid turvalisusele, ergonoomiale, ohutusele jms, mis ei hakka välja paistma otse ekraanilt, kuid mis peab olema taustaprotsessides tagatud.
Sageli tehakse tarkvara hankimise otsus ilma tarkvaratootjaga konsulteerimata. Tarkvara hanke koostamiseks paneb ettevõtte IT-spetsialist (või määratud projektijuht) koostöös juhtkonnaga kokku mõnelehelise kirjelduse, mis funktsionaalsusi peaks loodav tarkvara omama ja mis nõudeid täitma. Selle põhjal peavad arendajad hindama, kui mahukaks loodav süsteem kujuneb. Tegelikult ei suuda ülesandepüstituse koostajad läbi näha ja kirjeldada kõiki kaasnevaid ning esmapilgul varjatud keerukusi. Sageli on probleemiks andmete importimine või andmevahetusüldse, samuti soovitav dünaamilisus.
Analüüsis selgub sageli, et klient soovib keerulisemat süsteemi, kui esialgses kirjelduses välja toodud. Tekib ebamugav olukord: realiseerimise hind on kokku lepitud, samas on soovitav funktsionaalsus märksa mahukam ja selle realiseerimiseks kulub rohkem aega kui esialgse kirjelduse põhjal arvestati. Arendajal tekib soov (ja vajadus) kliendiga hinna suhtes läbi rääkida, kuid klient reeglina seda ei soovi.
Situatsioon kordub sageli, kui tellija soovib täismahus arenduse hinnapakkumist ilma eelneva analüüsita. Arendajad on punnseisus: pakkumine tuleb teha suhteliselt vähese info põhjal, samas igaks juhuks liiga kõrget hinda pakkuda ei saa.
Tarkvaratootja poolt vaadatuna on parim, kui analüüs teostataks ülejäänud etappidest sõltumatult. Analüüsi aega ja ressurssi saab arendaja hinnata küllalt täpselt ettevõtte suuruse ja intervjueeritavate isikute hulga järgi. Tulemuste põhjal on oluliselt lihtsam anda hinnang tarkvara loomiseks tegelikult kuluva ressursi kohta.
Ka nende tarkvarasüsteemide korral, mis eeldatavasti pole mahukad, on ikkagi otstarbekas eraldada analüüs realiseerimisest. Analüüsis kaardistatud funktsionaalsed ja mittefunktsionaalsed nõuded on piisavalt täpne alus hindamaks tarkvara mahtu.
Tarkvaraarenduses ei kulge suurem osa arendusprojekte plaanipäraselt. Kaotatakse ajas ja kvaliteedis ning rahulolematud on nii klient kui tarkvara realiseerija. Hea tarkvara saamiseks tuleb eesmärgi saavutamiseks hakata liikuma sammhaaval: alustades vajaduste selgitamisest analüütiku abiga, millele järgneb tarkvara realiseerimine. Suuremate tarkvarasüsteemide korral peaks arendamine kindlasti toimuma tsükliliselt. Seejuures eelneb igale uuele tsüklile taas detailne analüüs.
Autor: Maret Meriste

Seotud lood

  • ST
Sisuturundus
  • 11.12.24, 10:55
Kuidas poliitikud ja keskpankurid on viinud meid kuristiku äärele
15 aastat kestnud keskpankade rahapoliitika tagajärjel ei ole meil enam vabu kapitaliturge ning kogu globaalne majanduskasv tuleneb võlakoorma suurenemisest, mitte tootlikkuse kasvust. See jätkusuutmatu kasv lõpeb peagi väga suure kollapsiga, kirjutab Soome majandusteadlane Tuomas Malinen.

Äripäeva TOPid

Hetkel kuum

Liitu uudiskirjaga

Telli uudiskiri ning saad oma postkasti päeva olulisemad uudised.

Tagasi Äripäeva esilehele