Asmeninis programų kūrimo procesas (PSP)

1. Asmeninis programų kūrimo procesas(PSP) 6 paskaita Saulius Ragaišis, VU MIF saulius.ragaisis@mif.vu.lt 2008-05-07

2. Einamoji situacija Deja, dėl objektyvių priežasčių yra dar labai daug neištaisytų darbų. Pirmiausia bus taisomi 4-os privalomos užduoties darbai, o tada papildomos užduoties darbai. Prašymas – turėti kantrybės...

3. 4-os užduoties atsiskaitymas • Kažkokių “naujų” klaidų šiais metais nėra. • Kartojasi ankstesnių metų klaidos. • Kai kurios klaidos absoliučiai tiksliai atitinka įvardintas praeitos paskaitos skaidrėse, pvz.: Pagal pateiktą aprašymą nepagrįstai apribojamos programavimo kalbos galimybės (pvz., unit/implementation neleidžiama aprašyti nei konstantų, nei tipų, nei kintamųjų, nei papildomų funkcijų/procedūrų)

4. 5-a užduotis: U5-PP2 (priminimas) Patobulintas projekto planavimas ir vykdymas 2 taškai iki gegužės 18 d. (1 iki gegužės 25; 0,5 iki birželio 1)Už atsiskaitymą iš antro karto skiriamas 1 balas, iš trečio karto - 0.5 balo, iš ketvirto karto - 0.2 balo 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).

5. Patobulintas planavimo procesas(priminimas) 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)

6. 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.

7. 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ą.

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

9. 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.

10. 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.

11. 5-os užduoties atsiskaitymas: 2007 m. 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”)

12. 5-os užduoties atsiskaitymas: 2007 m. 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

13. Programų sistemų inžinerija Programų (sistemų) inžinieriaus darbas yra pateikti aukštos kokybės programinius produktus sutartu laiku už sutartą kainą. Yra 3 efektyvaus šio darbo atlikimo aspektai: (1) kurti aukštos kokybės produktus, (2) atlikti darbą su numatytomis sąnaudomis (kaina), (3) baigti darbą sutartu laiku. Tam reikia:- planuoti darbą;- atlikti darbą pagal planą;- siekti sukurti aukščiausios kokybės produktą. Kodėl svarbi gera inžinerija? Daugelis projektų viršija numatytą kainą ir laiką, o sukurti produktai neatitinka vartotojo reikalavimų.

14. Asmeninis programų kūrimo procesas Esminė mokymosi dalis yra rinkimas savo duomenų, atliekant užduotis. Šie PSP duomenys leis stebėti savo darbo procesą ir jį gerinti. Darbo disciplina. Disciplina yra apibrėžiama kaip veikla, kurianti ar vystanti įgūdžius. PSP tikslas pateikti struktūrizuotą būdą formavimui asmeninių įgūdžių ir metodų, reikalingų programų (sistemų) inžinieriaus darbe. Aukštos kokybės darbo svarba. Vienas žmogus kuria tik dalį programų sistemos, tačiau ir mažiausios dalies kokybė yra svarbi. Kaip pagerinti savo darbo kokybę? Svarbu apibrėžti matavimus, rinkti duomenis, juos analizuoti, daryti išvadas ir keisti savo darbo būdą. Keistis visada sunku ...

15. Gerinimo procesas

16. Laiko valdymo logika Šią savaitę jūs dirbsite panašiai kaip praeitą savaitę (žinoma, yra išimčių, pavyzdžiui, per sesiją). Kad kurti realistiškus planus reikia stebėti, kaip leidžiate laiką. Realūs duomenys dažnai skiriasi nuo įsivaizduojamų. Kad patikrinti vertinimų ir planų tikslumą, reikia juos dokumentuoti ir po to lyginti juos su tikraisiais duomenimis. Pirmas žingsnis, mokantis kurti gerus planus, yra kurti planus. Kad kurti tikslesnius planus, reikia išsiaiškinti, kokios buvo klaidos ankstesniame plane ir kas gali būti padaryta geriau. Duomenis reikia rinkti pakankamu tikslumu, išskiriant skirtingus darbus. Turint planą ir realius duomenis, galima juos analizuoti ir daryti išvadas. Kad valdyti laiką, reikia planuoti laiką ir dirbti pagal planą. Suplanuoti yra nesunku, žymiai sunkiau laikytis plano (pvz., laikytis dietos, mesti rūkyti). Svarbu mokėti kurti planus, bet tiesiog būtina mokėti jų laikytis. Pirmas žingsnis yra suprasti, kaip leidžiate laiką. Sukaupti duomenys (patirtis) įgalina geriau (tiksliau) planuoti.

17. Periodo ir produkto planavimas Yra 2 tipų planavimas: 1) tam tikro periodo (laikotarpio); 2) tam tikros užduoties atlikimo (pvz., sukurti programą).

18. PSP struktūra PSP procesas apima tris stambias programų sistemų kūrimo fazes: 1) užduočių planavimas, 2) kūrimas ir 3) proceso peržiūra (“aptarimas”). Planavimo fazės metu paruošiamas planas, įtraukiantis prognozuojamą kuriamo produkto dydį bei jo sukūrimui reikalingą laiką. Kūrimo fazė apima visą „gamybinį“ procesą. Proceso gerinimo fazės metu peržiūrimi surinkti duomenys ir siūlomi patobulinimai. Procesą galima skaidyti į tokias mažesnes fazes: asmeninių užduočių planavimas, eskizinio projekto kūrimas, eskizinio projekto peržiūra, detaliojo projekto kūrimas, detaliojo projekto peržiūra, kodavimas, kodo peržiūra, kompiliavimas, testavimas ir proceso peržiūra (“aptarimas”).

19. PSP metrikos PSP procesas naudoja pagrindines metrikas: • laikas, • defektai,• dydis. Iš šių bazinių metrikų išvedamos visos kitos PSP metrikos. Metrikos, kurios paremtos bazine laiko metrika, būtinos sudarant grafiką ir užduočių planus, matuojant produktyvumą ir t.t. Metrikos, paremtos bazine defektų metrika, būtinos produkto kokybei matuoti, prognozuoti ir valdyti, taip užtikrinant kokybiško produkto kūrimą. Metrikos, paremtos bazine dydžio metrika, būtinos dydžio matavimui bei prognozavimui, taip pat, kaip sudėtinis dėmuo, naudojamas defektų “tankiui” bei produktyvumui matuoti.

20. PSP kokybės modelis PSP procesas produkto kokybę užtikrina trimis pagrindiniais būdais: • kiekvienam produktui yra atliekama peržiūra (eskizinio projekto peržiūra, detaliojo projekto peržiūra, kodo peržiūra), didžiausią dėmesį skiriant defektams, užfiksuotiems dažniausiai asmens paliekamų defektų sąraše; • projektavimas atliekamas pagal projektavimo procedūrą, apimančią projektavimo šablonų naudojimą bei projekto patikrinimą (design verification); • produkto kokybė stebima ir vertinama, naudojantis proceso metu surinktais duomenimis.

21. PSP prognozavimo modelis PSP proceso metu prognozavimas vykdomas remiantis prielaida, jog ateityje procesas vyks taip, kaip vyko praeityje, t.y. ateities prognozėms naudojami istoriniai duomenys. PSP procesas pristato prognozavimo metodą PROBE (Proxy Based Estimating). Šis metodas naudojamas laiko ir dydžio prognozavimui. Jis įgalina pakankamai tiksliai prognozuoti, nes remiasi istoriniais duomenimis, kuriuos kiekvienas pagal PSP procesą dirbantis asmuo renka projektų metu. Duomenys kategorizuojami, atsižvelgiant į objekto tipą (pvz., duomenų įvedimą užtikrinantis objektas). Turint keletą tai pačiai kategorijai priklausančių objektų bei kiekvieno iš jų kūrimui sugaišto laiko įverčius ir dydžius, galima apskaičiuoti, kiek laiko užtruktų tokios kategorijos objekto kūrimas ir kokio dydžio jis būtų (skaičiuojamas aritmetinis vidurkis arba naudojamasi sudėtingesniais statistiniais metodais).

22. PSP tobulinimo modelis Asmeninio proceso evoliucionavimas yra vienas iš svarbiausių PSP proceso aspektų. PSP procesas tobulinamas, remiantis pasiūlymais, pateiktais proceso peržiūros fazės metu. Tam tikslui yra paruošta proceso gerinimo pasiūlymų forma, kurioje fiksuojami visi galimi proceso tobulinimo būdai bei siūlomi pakeitimai. Patobulinimai pateikiami su metrikomis, kad būtų galima išmatuoti pakeitimo naudą.

23. PSP praktikos PSP procese išskiriamos tokios praktikos: 1. Laiko fiksavimas.2. Defektų fiksavimas.3. Dydžio fiksavimas.4. Standartų apibrėžimas.5. Dydžio prognozavimas.6. Laiko prognozavimas.7. Peržiūros.8. Proceso tobulinimas

24. Klausimai ?