Asmeninis programų kūrimo procesas

1. Asmeninis programų kūrimo procesas 4 pratybos Andrius Adamonis 2013-03-22 / 2013-04-05

2. Projekto pradžios pavyzdys Situacija: konkurentai išleido naują produktą, kuriuo susidomėjo daug klientų. Vadovybės sprendimas: inicijuoti projektą ir mažiau kaip per 9 mėnesius sukurti naują dar geresnį produktą, nes kitu atveju kompanija praras labai daug klientų. Projekto komanda ką tik baigė nesėkmingą projektą, trukusį 2 metus, o naujas darbas tikrai nėra paprastesnis.

3. Projekto pradžios pavyzdys (2) Tradiciškai planavimui skiriamos 4 dienos. Komanda supranta, kad nespės projekto padaryti per 9 mėnesius. Kieno įsipareigojimas 9 mėnesiai? Ką daryti? Tradicinis scenarijus: einama pas vadovybę, sakoma, kad nespės, bet kadangi reikia, pažadama padaryti viską, kas įmanoma, t.y. prisiimami įsipareigojimai. Kas lieka kaltas, kai nepavyksta? Gal neverta planuoti? Galima sutaupyti 4 dienas, nėra pakankamai informacijos planavimui. Kada bus pakankamai informacijos? Kada labiausiai reikia plano?

4. Projekto pradžios pavyzdys (3) Rezultatas: komanda baigė projektą 6 savaitėmis anksčiau nei vadovybės patvirtinti 18 mėnesių (komandos nariai buvo įsisavinę PSP).

5. 3-ia užduotis: U3-PPS Projekto planavimas ir eigos sekimas Užduoties tikslai:- suplanuoti, kiek laiko prireiks vienos ADS arba OOP užduoties atlikimui ir konkrečioms veikloms;- užfiksuoti duomenis apie vienos programos kūrimą (sugaištą laiką ir defektus – kiek ir kuriose veiklose jie padaromi bei pašalinami). Užduotis turi būti pradėta daryti prieš pradedant kurti programą ir baigta po programos sukūrimopageidautina, kad atsiskaitant užduotį programa jau būtų atsiskaityta. Atsiskaitymui pateikti: (1) LFF, (2) DTS, (3) DFF, (4) PPS, (5) sukurtos programos išeities kodą.viskas siunčiama vienu laišku;atsiskaitinėjant pakartotinai vėl siunčiami visi failai.

6. Projekto planavimas

7. Projekto tvarkaraščio (PT) sudarymas • 1. Numatyti (įvertinti) resursus • PSP atveju tai yra bendras numatomų valandų skaičius • 2. Numatyti (įvertinti) užduotis • Suskaidyti darbą į smulkias užduotis ir numatyti laiką, reikalingą kiekvienai užduočiai atlikti; vertinant reikėtų remtis projekto plano suvestinės formos (PPS) „Iki šiol“ kolonėlės reikšmėmis • 3. Numatyti (įvertinti) savaitinėms užduotims skiriamas valandas per savaitę • Pagal savo užimtumo grafiką nustatyti, kiek laiko skiriama įvairioms pasikartojančios savaitinėms užduotims • 4. Suskaičiuoti („laisvą“) laiką, kurį įmanoma skirti projektui • 5. Suplanuoti užduočių priklausomybes • Surikiuoti užduotis apytiksliai ta tvarka, kaip ketinama jas vykdyti • 6. Paruošti tvarkaraštį • Pagal užduočių vertinimus ir laisvą laiką suplanuoti kurią dieną kuri užduotis bus pradėta ir baigta vykdyti • 7. Apibrėžti riboženklius (milestones) • Nusistatyti pagrindinius projekto tvarkaraščio taškus, kurių nesinorėtų judinti net, jeigu užduotys būtų atliekamos ne ta tvarka, kaip suplanuota pradiniame tvarkaraštyje

8. Darbų atlikimo tvarkaraštis • Galima variacija: • Projektas neskaidomas užduotimis, o tik numatoma, kiek valandų skiriama projektui kiekvieną dieną • Tuomet projektas vykdomas, kasdien pažymint, kiek valandų dirbta ir išskaičiuojant, kokia vertė per tą dieną sukurta • Pavyzdys formoje U3-DAT.xls

9. Papildoma informacija dėl 3-ios užduoties • Rekomenduojama planuoti ir vykdyti visas numatytas programos kūrimo veiklas (Planavimas, Projektavimas, Kodavimas, Kompiliavimas, Testavimas, Atsiskaitymas, PSP veikla) • Jei programos atsiskaitymo metu dėstytojas rado jūsų programos defektų, jie fiksuojami taip: - PPS paskutinėje eilutėje "Po kūrimo“,- DFF “Pašalintas fazėje” – “Aptarimas” • Jei vykdomos papildomos veiklos, nenumatytos šioje užduotyje siūlomame procese(pvz., Peržiūra, Dokumentavimas, Skaitymas), jų duomenis (laiką ir defektus) priskirti pagrindinei veiklai (pvz., jei kodavimo metu teko paskaityti C dokumentaciją, o prieš kompiliuojant programa dar buvo peržiūrėta, tai visas sugaištas laikas priskiriamas Kodavimui) • Nauja programos kūrimo fazė “Aptarimas” (postmortem), kurios tikslasperžiūrėti programos kūrimą ir jo metu surinktus duomenis: kaip jis vyko, kas buvo gerai ir kas blogai, ar visi duomenys užfiksuoti ir korektiški, kaip procesas turėtų būti gerinamas

10. Papildoma informacija dėl 3-ios užduoties: užduoties atlikimo eiga Pavaizduotas atvejis, kai programa kuriama vienu ciklu. Kuriant keliais ciklais, projektavimas, kodavimas, kompiliavimas ir testavimas kartojami.

11. Papildoma informacija dėl 3-ios užduoties: atliekamos veiklos ir jų priskyrimas fazėms Eilutėse pateikti 2 galimi variantai, kur priskiriamos PSP veiklos sąnaudos.Kiekvienas pasirenka jo nuomone tinkamesnį variantai. Koks variantas buvo pasirinktas turi būti aiškiai matoma iš LFF.

12. PSP siūlomas defektų tipų standartas

13. Papildoma informacija dėl 3-ios užduoties: keli patarimai savikontrolei • Fiksuojant programos dydį turi būti neįskaitomos tuščios ir komentarų eilutės • Pateiktame LFF turi būti aišku, kurios veiklos yra susijusios su šia užduotimi, arba nesusijusių veiklų turi nebūti • Detalūs projekto vykdymo duomenys, užfiksuoti LFF ir DFF, ir suminiai duomenys PPS turi sutapti (pavyzdžiui, suma DFF laikų, sugaištų defektų šalinimui kažkurioje fazėje, negali būti didesnė už tos fazės laiką PPS) • PPS “Faktas” ir “Iki šiol” turi sutapti • Padarytų ir pašalintų defektų skaičiai turi sutapti (PPS: visi defektai padaromi kūrimo metu, o pašalinami kūrimo metu arba po kūrimo) • LFF turi būti užfiksuota, kad darbas baigtas ir sukurtos programos dydis • Galima, bet pakankamai reta situacija – defekto padarymo ir pašalinimo fazės sutampa (vertėtų pasitikrinti, ar tai ne klaida)