Šių metų rugsėjo 29d., tikrai netikėtai man pačiam, buvau pakviestas į Microsoft padalinio Lietuvoje rengiamus „Spaudos pusryčius“, kuriuose buvo supažindinta su kompanijos ateities planais, į šį renginis buvo pakviesti spaudos atstovai ir tinklaraštininkai. Iš tiesų aš savęs ne tik kad nelaikau profesionaliu tinklaraštininku, bet ir apskritai tinklaraštininku, esu tik žmogus, kartas nuo karto pasidalinantis savo [...]
Programuotojo darbo procesas: #7 Programos apimties ir kūrimo trukmės įvertinimas
Programos apimties ir kūrimo trukmės įvertinimas yra bene sudėtingiausias uždavinys, su kuriuo tenka susidurti kiekvienam programuotojui. Taip pat ir man, gerai įvertinti programos apimties ir kūrimo trukmę, yra sudėtingas uždavinys. Tiesa sakant, aš pats įvertinu tik kūrimo trukmę, o šis terminas vis dar “užsilikęs” iš perskaitytų Watts S. Humphrey knygų. Nors apimties įvertinimas yra pakankamai gerai aprašytas ir neabejotinai pateiktų patikimus duomenis, bet, mano nuomone, nauda neatperka laiko, skirto atrinkti tinkamą istorinę informaciją, atlikti geriems programos apimtiems įvertinimams, ir atlikti pačius apimties įvertinimus. Todėl ir šiame įraše rašysiu apie tai, kaip aš siūlyčiau įvertinti programos kūrimo trukmę.
Taigi, pradėkime nuo pradžių, sudarinėjant planą, didžiausią problemą sudaro informacijos trūkumas, kadangi apie programą, kurią reikia sukurti, ar vykdoma užduotį, dažniausiai yra žinoma ypač mažai. Pagrindinė turima informacija yra tik programos ar užduoties reikalavimai. Įvertinti būsimos programos kūrimo trukmę, yra ypač sunku. Todėl svarbiausia kuo geriau išsianalizuoti reikalavimus ir pasinaudoti visa turima istorine informacija. Kad vertinimai būtų kuo tikslesni, iš pradžių reikia susidaryti konceptualų programos projektą, kuris turi atspindėti, programos kūrimo ir veikimo principus. Svarbiausia, jog konceptualus projektas būtų sudarytas iš tokių programos elementų, kuriuos jau yra tekę kurti arba bent jau būtų žinoma, kaip tai reikėtų padaryti.
Sekančiu žingsniu, sudarinėjant planą, yra vertinamas programos kūrimo laikas, skirtas programai sukurti. Kadangi konceptualiame projekte yra aprašyti programos elementai, tai reikia atsirinkti istorinę informaciją, kuri suteiktų duomenų apie panašių programos elementų kūrimą. Programos kūrimo trukmės vertinimas, remiantis panašių, anksčiau kurtų programų istorine informacija, yra vadinamas atitikmenimis grįstu vertinimu (angl. Proxy-based estimating – PROBE). Atitikmuo, kaip ir sufleruoja pavadinimas, yra programa ar jos elementas, kuris atlieka tokį patį arba labai panašų darbą, kaip ir programa arba jos elementas, kurį reikės sukurti. Atitikmenys, kuriais būtų galima pasinaudoti vertinant būsimos kūrimo trukmę, turi būti kuo panašesni į naujai kuriama programą/modulį. Taigi, atitikmenimis grįstas vertinimas yra sudarytas iš tokių žingsnelių.
- Išsiaiškinami programos reikalavimai.
- Surenkama kuo daugiau istorinės atitikmenų informacijos.
- Sudaromas konceptualus projektas iš į atitikmenis panašių programos elementų.
- Visiems programos elementams atrenkama pati tinkamiausia atitikmenų istorinė informacija ir, naudojantis ta informacija, įvertinama kiekvieno elemento kūrimo trukmė.
- Paskutiniu žingsniu įvertinama bendra programos kūrimo trukmė.
Vertinimas yra įgūdis, kurį galimą tobulinti ir gerinti. Yra keletas būdų, kaip vertinimo rezultatus galima pagerinti. Pirmasis patarimas – sudarinėjant konceptualų planą, reikia išskaidyti programą į mažesnius elementus, kadangi taip sumažinama prastų vertinimų įtaka galutiniam visos programos vertinimui, nei vertinant visos programos kūrimo trukmę iš karto, neskaidant programos į mažesnius elementus. Ypač svarbu palyginti kiekvienos programos realius kūrimo trukmės rezultatus su suplanuotaisiais, kadangi vertinant gali būti padaromos tendencingos paklaidos, pavyzdžiui, vertinimų duomenys visuomet yra ~40% mažesni nei gauti realūs rezultatai. Todėl, atliekant tolimesnius vertinimus, reikia įtraukti šią paklaidą, atitinkamai sumažinant arba padidinant galutinį vertinimo rezultatą. Tačiau reikia nepamiršti pastoviai lyginti realius duomenis su suplanuotaisiais, kadangi paklaidos gali kisti. Sekantis patarimas – kuriant konceptualų projektą, atrasti optimalų programos elementų išskaidymo lygį. Svarbu, jog konceptualus projektas nebūtų nei per daug nei per mažai detalus, kadangi tai stipriai įtakoja vertinimų tikslumą ir kokybę.
Na o ar jūs vertinate savo būsimų programų kūrimo trukmę? Jei taip, tai kaip tai darote?
Žymos: Planavimas, Resursų įvertinimas
- PDP: #8 Programinės įrangos kokybė
- PDP: #7 Tvarkaraščiai ir darbo progreso sekimas
- Darbo žurnalas – “patobulinta” užrašinė




