Asmeninis programų kūrimo procesas

1. Asmeninis programų kūrimo procesas 6 pratybos Andrius Adamonis 2011-04-27 / 2011-05-04

2. 4-a užduotis: U4-ESE Kokie X srities įgūdžiai PĮ inžinierių padaro geru PĮ inžinieriumi?(PĮ inžinierius – angl. developer, software engineer, ne programmer ar coder) ▪ Kiekvienam bus pateiktas patikslinimas, kurioje srityje. Pvz.: reikalavimų surinkimas iš užsakovo, reikalavimų analizė, PĮ projektavimas, testavimas, versijų kontrolė, planavimas, apimties įvertinimas ir pan.). Paskelbsiu asmeniškai kiekvienam PSP kurio medžiagos puslapyje. ▪ Teksto apimtis – ne mažiau nei 2 lapai arba 500 žodžių, lietuvių kalba, apiforminama pagal darbo kursiniam darbui reikalavimus.

3. Kaip rašyti ese Esė yra teksto kompozicija, išreiškianti idėją, teiginį ar koncepciją su pagrindžiančiais sakiniais. Struktūra: ▪ Įžanga • Pradėkite sudominančiu sakiniu • Apibūdinkite temą (temos „talpios“ – patikslinkite nagrinėjamą klausimą) • Pateikite savo teiginį (tezę) ▪ Turinys (maždaug trimis paragrafais, kiekvienama išaiškinate jūsų hipotezę pagrindžiančią mintį ir pateikiate ją pagrindžiančius teiginius; esė nėra referatas – turite rašyti savo mintis, jeigu nurodote į kitus autorius, įdėkite nuorodą į šaltinį, bet cituokite minimaliai; wikipedija ir marketinginė medžiaga nėra laikomi šaltiniais) ▪ Išvados (pateikia turinio samprotavimų santrauką ir dar sykį patvirtina jūsų tezę)

4. Programos peržiūra Iki šiol vienintelis būdas, naudojamas programos kokybės užtikrinimui, buvo testavimas (žinoma, defektai buvo randami ir kompiliavimo metu). Tačiau testavimas nėra vienintelis naudojamas būdas, nemažiau tinkamas ir efektyvus būdas yra peržiūros (autoriaus ir kolegų) ir inspekcijos (formalios peržiūros darbo grupėje). Tinkamai atliekamos peržiūros (ir inspekcijos) yra netgi efektyvesnės negu testavimas. Peržiūros gali (turi) būti taikomos visiems kuriamiems darbo produktams, bet pirmiausia PSP įveda programos (kodo) peržiūras. Peržiūros yra efektyvus būdas apmokyti naujus (nepatyrusius) darbuotojus.

5. Pasiruošimas peržiūrai • Kad peržiūra būtų efektyvi (t.y. būtų kuo didesnė defektų radimo tikimybė), tikslinga ją atlikti pagal pasiruoštą Kodo Peržiūros Sąrašą (Code Review Checklist), į kurį įtraukiami tikrintini punktai (aspektai). • Pasiruošimo peržiūrai tikslas susikurti savo KPS (Kodo Peržiūros Sąrašą). • Pateikiama ne KPS forma, bet užpildytas pavyzdys (KPSpvzC.xls). Jo tikrintinų punktų sąrašas nėra pilnas, jis skirtas tik tam, kad geriau suprasti, kas turėtų/galėtų KPS būti. • Remiantis šiuo pavyzdžiu ir asmenine patirtimi, kiekvienas turi susikurti savo KPS kiekvienai naudojamai programavimo kalbai. • Pasiruošimas gali būti atliekamas arba Planavimo fazėje, arba prieš pačią Peržiūrą.

6. Kodo Peržiūros Sąrašo pavyzdys (užpildytas)

7. Peržiūros atlikimas • Pagal PSP programos peržiūra turi būti atliekama prieš kompiliavimą. • Pagal pasiruošimo metu susikurtą KPS: • Programa tikrinama pagal kiekvieną punktą. • Baigus tikrinti punktą įrašomas rastų defektų skaičius. Jei defektų nerasta, būtina įrašyti 0 (kas reiškia, jog šis punktas buvo patikrintas). • Pagal PSP procesą peržiūros metu rastus defektus nepakanka fiksuoti tik KPS, juos reikia dubliuoti ir DFF, nes KPS nėra numatyta galimybė užfiksuoti fazę, kurioje defektas buvo padarytas. Akivaizdu, kad defektas rastas (ir pašalintas) Peržiūros metu. • KPS fiksuojami tik defektai rasti Peržiūros metu.

8. 5-a užduotis: U5-PP2 Patobulintas projekto planavimas ir vykdymas Pateikti vienos programos kūrimo pagal Patobulintą programos kūrimo procesą duomenis tokiose formose: (1) PDF, (2) DVF, (3) KPS, (4) PPS. Kartu su formomis pateikti ir (5) sukurtos programos tekstą. Formų LFF ir DFF pateikti nebūtina: • nepateikus įvertinimas nebus mažinamas; • pateikus įvertinimas nebus nei didinamas, nei mažinamas. Išskirtiniais atvejais, kilus neaiškumų, ar iš viso užduotis buvo atlikta, gali būti paprašyta pateikti LFF ir DFF formas (ankstesniais metais tokių atvejų nebūdavo daugiau nei po 2 per metus).

9. Patobulintas planavimo procesas Užpildoma PDF (Programos Dydžių Forma) Užpildoma DVF (Dydžio Vertinimo Forma) Pradedama pildyti PPS (Projekto Plano Suvestinė): 1) užpildoma antraštė 2) užpildoma dalis Planas: - Produktyvumas (Min/ES): imamas iš PDF (jei skiriasi nuo paskutinės programos, būtinas komentaras) - Programos dydis (ES): 3 numatomi dydžiai imami iš DVF (turi tiksliai sutapti, tik surašomi kita tvarka) - Apskaičiuotas laikas paskirstomas po fazes (turi sutapti su Viso – kol nesutampa rodomas raudonai)

10. 5-os užduoties atlikimo eiga Pavaizduotas atvejis, kai programa kuriama vienu ciklu. Kuriant keliais ciklais, projektavimas, kodavimas, peržiūra, kompiliavimas ir testavimas kartojami.

11. Svarbi informacija dėl 5-os užduoties • Užduočiai atlikti būtina turėti istorinių duomenų – bent vieną programą: • sukurtą ta pačia programavimo kalba; • pagal PSP siūlomą procesą (3-ios arba 5-os užduoties); • pagal tą patį Kodavimo standartą (blogiausiu atveju programą galima pertvarkyti).

12. Istoriniai duomenys programos dydžio vertinimui Naujų programų dydžio vertinimui PSP siūlo kaupti 2 tipų istorinius duomenis: 1) informaciją apie sukurtų programų dydžius, sugaištą laiką ir darbo produktyvumą (kiek minučių sugaištama vienos kodo eilutės sukūrimui) /kaupiama Programų Dydžių Formoje - PDF/; 2) informaciją apie sukurtų programų dalių dydžius(kodo eilutėmis) /kaupiama Dydžio Vertinimo Formoje - DVF/.

13. Programų Dydžių Forma (PDF) Forma naudojama viena programavimo kalba padarytų programų dydžių fiksavimui. Kaupiama informacija tik apie programas, kurios buvo darytos pagal atitinkamą PSP procesą ir pagal tą patį Kodavimo standartą. Formoje įvedama tokia informacija: 1) Programa: programos identifikatorius (pvz., ADS1). 2) Laikas (min): visas laikas, sugaištas šios programos kūrimui, pradedant Planavimu ir baigiant “Aptarimu” (pvz., 300). 3) Dydis (ES): programos dydis (eilučių skaičius) (pvz., 60). 4) Funkcijos: programos funkcijos* (pvz., Įvedimas iš failo; Rūšiavimas burbuliuko metodu; Rezultatų išvedimas į failą). Pagrindinis rodiklis produktyvumas – kiek minučių sugaištama vienos eilutės sukūrimui (Min/ES) – išskaičiuojamas automatiškai. * funkcijos suprantamos programos funkcionalumo požiūriu, realizacijos požiūriu tai tiesiog programos dalys (nebūtinai realizuotos kaip funkcijos ar procedūros)

14. Dydžio Vertinimo Forma (DVF) Forma naudojama: 1) padarytų programų dalių dydžių fiksavimui (istorinė dalis - geltona); 2) naujos programos dydžio vertinimui. Kaupiama informacija tik apie programas, kurios rašomos: 1) viena programavimo kalba 2) pagal tą patį Kodavimo standartą. Tikslas: Įvertinti kuriamos programos dydį, remiantis istoriniais duomenimis. Be to, tai gali padėti nustatyti jau realizuotas funkcijas, kurios gali būti pakartotinai panaudotos.

15. DVF pildymo pastabos - Istorinės dalies informacija yra iš esmės tokia pati kaip tos pačios programavimo kalbos PDF (Programų dydžių formoje) tik detalesnė, t.y. jei PDF yra kaupiama informacija visos programos dydį, tai šioje formoje programa yra išskaidyta į dalis (funkcijas) ir kaupiama informacija apie kiekvienos dalies (funkcijos) dydį. - Istorinė informacija lentelėje rūšiuojama ne pagal programas, kuriose funkcijos realizuotos, bet pagal funkcijų giminingumą (pavyzdžiui, pradžioje funkcijos, susijusios su duomenų įvedimu, po to funkcijos, susijusios su rūšiavimu, ir t.t.). - Prieš pradedant kuriamos programos dydžio vertinimą, ją reikia išskaidyti į dalis (funkcijas). - Kuriamos programos dalių (funkcijų) dydžiai vertinami, lyginant jas su labiausiai panašiomis jau realizuotomis funkcijomis. - Baigę kurti programą, iš karto atnaujinkite istorinę informaciją dydžio vertinimo formos šablone, kuris bus naudojamas kitai programai (padaryti tai iš karto, baigus programos kūrimą, užima mažiau laiko). Užduoties atsiskaitymui pateikiama neatnaujinta forma.

16. 5-os užduoties punktai savikontrolei • Ar PPS Produktyvumas sutampa su paskutinės programos, užfiksuotu PDF? Jei ne, ar yra komentaras kodėl. • Ar PPS Programos dydžiai sutampa su DVF? Ar jie surašyti tinkama tvarka? • Ar PPS suplanuotas laikas Viso sutampa su Apskaičiuotu laiku? • Ar užpildytas PPS stulpelis Faktas, įskaitant ir sukurtos programos dydį (skaičiuojamos tik naujos ir pakeistos kodo eilutės, tuščios ir komentarai neskaičiuojami)? • Ar užpildytas PPS stulpelis Iki šiol? Ar jame nurodytos reikšmės nemažesnės nei atitinkamos Faktas reikšmės? • PPS formoje 0 nerašomi. • Ar PPS užfiksuotas Peržiūros metu Pašalintų defektų skaičius sutampa su užfiksuotu KPS? ir t.t.

17. 5-os užduoties atsiskaitymas: ankstesnių metų esminės klaidos • Prieštaringa informacija skirtingose formose, pavyzdžiui:- skiriasi “istorinės” programos dydis PDF ir PPS- skiriasi “istorinei” programai sugaištas laikas PDF ir PPS- skiriasi peržiūros metu rastų ir pašalintų defektų skaičius KPS ir PPS • Prieštaringa informacija vienoje formoje, pavyzdžiui:- skiriasi padarytų ir pašalintų defektų skaičius • Nekorektiškai pildomas PPS stulpelis “Iki šiol”:- jame turi būti pateikiama suminė informacija istorinių programų ir šioje užduotyje sukurtos programos (stulpelis “Faktas”)

18. 5-os užduoties atsiskaitymas: ankstesnių metų kitos klaidos • Nekorektiškai skaičiuojamos programos eilutės (tuščios ir komentarų turėtų būti neskaičiuojamos) • Skirtingose formose skirtingai įvardinama kuriama programa • DVF istorinėje dalyje yra tik ta istorinės programos funkcija, kuria pasinaudojama vertinant (pvz., turėtų būti iš esmės visa programa) • Daugumos funkcijų dydis vertinamas nesiremiant istorine informacija • Dydžio vertinimai neturėtų skirtis kelis kartus (pvz., minimalus 3 kartus mažesnis už tikėtiną, o šis 2 kartus mažesnis už maksimalų) • Nepakankamai laiko skiriama peržiūrai (pvz., 5 minutės) • Po peržiūros absoliuti dauguma defektų lieka • PPS rašomi 0