Asmeninis programų kūrimo procesas(PSP)

6 paskaita

Saulius Ragaišis, VU MIFsaulius.ragaisis@mif.vu.lt

2008-05-07

Einamoji situacija

Grupė Studentų Sem1 Sem2 Viso Pažymys

1 24 3,04 0,48 3,52 3,54

2 23 3,05 0,26 3,32 3,26

3 25 3,46 0,57 4,02 3,96

4 23 3,21 0,22 3,43 3,43

5 21 3,13 0,22 3,35 3,33

Iš viso: 116 3,18 0,36 3,54 3,52

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

4-os užduoties atsiskaitymasKaž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ų)

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

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)

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.

Pasiruošimas peržiūraiKad 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ą.

Kodo Peržiūros Sąrašo pavyzdys (užpildytas)Grupė: 6 Data: 2003.04.26

Studentas:Programa: OP2 Programavimo kalba: C++

Aspektas Rasta defektųIšbaigtumas 0

Inicializacija 1

Funkcijų iškvietimas

0

Vardai 2

{} poros 0

Loginiai operatoriai 0

Nuoseklus patikrinimas

1

Standartai 3

Failai 0

7Viso

Patikrinti, vardų rašybą ir naudojimą:- ar visi vardai korektiški;- ar visi aprašyti reikiamame lygyje;- ar visose struktūrose/klasėse naudojamas '.'.

Patikrinti, ar riestiniai skliausteliai sudėti tinkamai

Patikrinti, ar korektiškai naudojami ==, =, || ir t.t.Patikrinti, ar tinkamai sudėti ().

Patikrinti kiekvieną programos kodo eilutę:- ar teisinga operatorių sintaksė;- ar teisinga skyryba.

Patikrinti, ar programos kodas atitinka naudojamą Kodavimo standartą

Patikrinti, ar visi failai:- tinkamai aprašyti;- atidaromi;- uždaromi.

Jonas Jonaitis

Patikrinti, funkcijų iškvietimų formatus:- parametrus;- rodykles;- '&' panaudojimus.

Tikrinami punktaiPatikrinti, ar visos funkcijos yra realizuotos

Patikrinti, ar visi kintamieji ir parametrai inicializuoti:- pradedant vykdyti programą;- prieš kiekvieną ciklą;- prieš funkcijos iškvietimą.

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.

5-os užduoties punktai savikontroleiAr 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.

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”)

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 programaDVF 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 informacijaDydž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

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

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

Gerinimo procesasNustatyk tikslą

Matuok produkto kokybę

Suprask procesą

Pakoreguok procesą

Naudok pakoreguotą procesą

Matuok rezultatus

Lygink rezultatus su tikslu

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.

Periodo ir produkto planavimas

Yra 2 tipų planavimas:

1) tam tikro periodo (laikotarpio);

2) tam tikros užduoties atlikimo (pvz., sukurti programą).

PSP struktūraPSP 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”).

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.

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.

PSP prognozavimo modelisPSP 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).

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

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

Klausimai

?