Tarkvaraarendus - metoodikata või ilma ?
Tarkvaraarendus on suhteliselt noor tööstus (teadus)haru. Kõikvõimalikud uuringud tarkvaraarendusmetoodikatest (vettpidavamaid ehkData Evans Corporation omad) viitavad siiski, et pole olemas ühest ja kõigile sobivat viisi, kasutatakse peamiselt kosemudeli modifikatsioone ja iteratiivseid meetodeid. Samas olen näinud läbi mitmete riigihanke pakkumiste RUP-i (Rational Unified Process) pakutavat ja nüüd, olles ise täitja ehk siis arendaja rollis - lubatagu kahelda RUP-i läbi tööde realiseerimises. Kogu projekti aur kulubki nii vaid RUP-i protseduuride jälgimiseks ja real action ehk siis tarkvara tootmine jääb teisejärguliseks. Aga RUPi autorid on oma metoodikat viitsinud ehk visuaalselt kõige põhjalikumalt seletada ning riigihangetel jätab see ka usutava mulje...
Oleme mitmeid kordi oma arendusmeeskonnaga arutlenud teemal, et mis ikkagi on kliendi nõuetele vastava tarkvara tootmise edukuse kriteeriumiks ja jõudnud järeldusele, et peamine on kliendi motivatsioon. Motivatsioon antud kontekstis ei tähenda, et klient on jõudnud järeldusele - vajan uut tarkvara. See tähendab ka seda, et on mõeldud ka sügavamalt järele MILLIST? tarkvara. Hetkel olemegi arendusmeeskonnaga üsna hädas... klient soovib SÜSTEEMI. Aga samas puudub asutuses inimene, kel oleks süsteemne ülevaade süsteemist:) Vähemalt meie temaga kokku ei saanud...
Ja nii me kohtumegi analüüsi käigus erinevate valdkondadega ja kaardistame erinevate valdkondade vajadusi. Ja ilusast terviksüsteemist võib ainult unistada. Tulebki selline Tootsi peenar, sest igal erialaspetsialistil on personaalselt õigus öelda, kuhu tema nuppu või rippmenüüd tahab... Parim lahendus selle asutuse jaoks oleks üks IT-tudeng, kes mitmeid aastaid asutuses töötanuna ja piisavalt uudishimulikuna teeks korraliku äriprotsesside analüüsi. Muidugi on panustanud teenuse sisseostmisele - ehk siis kombekohaselt oli äriprotsesside analüüs tellitud ühelt teiselt firmalt. Ikkagi - seesama real action, töö teostamine on ikkagi niivõrd erinev. Siinkohal jääbki mulle mõistatuseks, miks tellitakse analüüs lahusolevalt ja erineva täitja poolt? Kas nii on põnevam?:)
Ja nii me kohtumegi analüüsi käigus erinevate valdkondadega ja kaardistame erinevate valdkondade vajadusi. Ja ilusast terviksüsteemist võib ainult unistada. Tulebki selline Tootsi peenar, sest igal erialaspetsialistil on personaalselt õigus öelda, kuhu tema nuppu või rippmenüüd tahab... Parim lahendus selle asutuse jaoks oleks üks IT-tudeng, kes mitmeid aastaid asutuses töötanuna ja piisavalt uudishimulikuna teeks korraliku äriprotsesside analüüsi. Muidugi on panustanud teenuse sisseostmisele - ehk siis kombekohaselt oli äriprotsesside analüüs tellitud ühelt teiselt firmalt. Ikkagi - seesama real action, töö teostamine on ikkagi niivõrd erinev. Siinkohal jääbki mulle mõistatuseks, miks tellitakse analüüs lahusolevalt ja erineva täitja poolt? Kas nii on põnevam?:)
Kommentaarid
Kui kellelgi on kuhugi vaja nuppu või dropdowni ja tegemist on ikka täiesti lampi nõudmisega, siis tuleb sedagi põhjendada.
Paduhumanitaaridest kliendiga tegime kunagi nii. Kogusime kolm inimest kokku ning andsime neile kätte paberi ja pliiatsi. Palusime järgmiseks päevaks joonistada paberi peale, et kuidas nad oma süsteemi ette kujutavad. Tulemus oli peale kerget vooru täpsustavaid küsimusi tõsiselt super - poleks neid joonistama pannud, oleks võinud nädalaga hulluks minna. Tähendab, tellijal tekkis olukord, kus ta ise tegi enda jaoks otsad kenasti lahti.
Mis puutus aga igasuguseid asjakohatuid lisavidinaid erinevates kohtades, siis sellegi jaoks sai leitud hea lahendus - istu maha ning selgita inimesele rahulikult ja talle arusaadavas keeles, et miks see asi ei sobi sinna vaid peab asuma seal.
Kordagi ei tekkinud probleeme teemal rumal tellija või pirtsutav arendaja.
Aga äkki tookord lihtsalt vedas... :P
Tänud esimese kommentaari eest!:)
Sinu poolt kirjeldatud lahendus toimiks kenasti kui tellijapoolseid otsustajaid oleks piiritletud ring, aga kõnealuses projektis paraku on see laiem ja kõikide otsustajate jooniseid realiseerima hakates läheksime tõenäoliselt ikkagi rappa. Hetkel püüame töötada põhimõttel, et teostame analüüsi ja tellija kirjelduste põhjal prototüübi, mida siis vajadusel nõuetekohaseks viia. Aga kurat, nagu öeldakse, peitub detailides - ja siin näemegi riski...lõpmatuseni prototüüpi lihvides on raskusi ajagraafikus püsimisega...
Kui vaadata näiteks tootmisettevõtteid, siis ühe ja sama toote kohta käiva info kohta tunneb tootjate seltskond ühede ja müük teiste andmete vastu esmast huvi.
Sel juhul on lihtsam minna seda teed, et igal huvigrupil on neile mõeldud vaated, millest nemad aru saavad. Andmed on samad.
Tegemist on hiljem rohkem, kuid see-eest hundid söönud ja lambad terved.
Tegelikult on kordumised just andmetöötluse protseduurides ja siinkohal võikski "ilusale süsteemile" panustada, juhul kui tellija oma äriprotsesse ühtlustaks.
Paraku tundub kohati, et loodetakse et loodav infosüsteem teeb seda:) Süsteem ei salli ebaloogilisi ja õhku rippumajäävaid protsesse,sealt tulevad ka välja kitsaskohad. Eriti kui eesmärgiks andmete ühilduvus.
Samas pole just tarkvaraarendaja asi muuta/ümberkujundada ettevõtte igapäevaseid protsesse, olgugi et näeme, kust king pigistab. See ka tavaliselt aeganõudev ja ei mahu arenduprojekti piiridesse.
Ise arvan, et kvaliteetseima elektroonse infosüsteemi saab luua siiski vaid siis, kui organisatsiooni infosüsteem paigas;-)