Programų sistemų inžinerija

1. Programų sistemų inžinerija Saulius Ragaišis, VU MIF saulius.ragaisis@mif.vu.lt

2. Komandinis programų kūrimo procesas angl. Team Software Process (TSP). TSP procesas apibrėžia projektuose dalyvaujančių asmenų roles, jų atsakomybes bei tikslus. Visas procesas išskaidomas žingsniais, kuriuose aprašoma, kaip turi būti elgiamasi kiekvieno projekto etapo metu, kas turėtų būti akcentuojama, o ko geriau vengti, kad projekto įgyvendinimas vyktų sklandžiai ir be trukdžių. Ypatingai daug dėmesio skiriama tiksliam viso proceso žingsnių dokumentavimui ir nuosekliam jų vykdymui. Tai turi padėti pereiti nuo bandymų ir ieškojimų kelio, prie konkrečiai ir labai tiksliai apibrėžto proceso metodų įsisavinimo ir jų įgyvendinimo.

3. TSP projektiniai sprendimai • Procesas turi remtis PSP • Kurti produktus keliais ciklais • Pasiūlyti standartinius kokybės ir progreso vertinimo būdus • Pateikti komandos ir narių vertinimo būdus • Naudoti rolių vertinimą • Reikalauti iš inžinierių proceso disciplinos • Pateikti komandinio darbo problemų sprendimo gaires

4. Startavimas1 Startavimas 2 Strategija 1 Startavimas 3 Planavimas 1 Strategija 2 Reikalavimai 1 Planavimas 2 Strategija 3 Projektavimas 1 Reikalavimai 2 Planavimas 3 Įgyvendinimas 1 Reikalavimai 3 Projektavimas 2 Testavimas1 Įgyvendinimas 2 Projektavimas 3 Aptarimas 1 Testavimas 2 Įgyvendinimas 3 Testavimas 3 Aptarimas 2 Aptarimas 3 Galutinis produktas TSP kūrimo ciklų struktūra

5. Startavimas Projekto startavimo tikslai: suformuoti komandą, pasiskirstyti rolėmis, nusistatyti projekte siekiamus tikslus. TSP siūlomos rolės: (1) komandos lyderis; (2) kūrimo vadovas; (3) planavimo vadovas; (4) kokybės/proceso vadovas; (5) palaikymo vadovas. TSP nurodymai tikslams nusistatyti:1. Tikslų nustatymas turi būti orientuotas į klientą bei pagrindinius rezultatus.2. Nustatyti matavimus, kurie įgalintų įvertinti, ar tikslas pasiektas. 3. Remiantis sukaupta patirtimi gerinti (tikslinti) bei išskirti naujus tikslus. Siūlomi komandos tikslai: (1) kurti kokybiška produktą; (2) gerai valdyti projektą ir jį produktyviai vykdyti; (3) baigti laiku. Siūlomi komandos narių tikslai: (1) būti efektyviu bei bendradarbiaujančiu komandos nariu; (2) dirbti tvarkingai (drausmingai metodiškai); (3) planuotis ir sekti savo asmeninį darbą; (4) kurti kokybišką produktą TSP taip pat siūlo standartinius tikslus kiekvienai rolei.

6. Strategija Pagal TSP reikia planuoti prieš atliekant pilną reikalavimų analizę. Tam yra trys pagrindinės priežastys: (1) planuojant komanda susipažįsta su projektu; (2) planas padeda įvertinti darbo dydį, prognozuoti, ar darbas bus padarytas per numatytą laiko tarpą, taip pat numatyti kitus rizikos faktorius; (3) jei nėra plano, komanda yra priversta pasirašyti sutartį pagal vadovo nustatytas datas, nors jie nežino, ar spės laiku atlikti darbą. Strategija turi apibrėžtikeliais ciklais bus kuriama sistema, kokios sistemos dalys bus įgyvendinamos kiekviename cikle. Siūloma pradėti nuo koncepcinio projektavimo, kuris sudaro pagrindą projekto planui. Tam netinka poreikių specifikacija, nes ji atspindi kliento požiūrį į sistemą, bet neduoda jokių gairių, kaip sistema bus realizuota. Pagrindinis tikslas kuriant strategiją - minimizuoti riziką. Strategijos kūrimo žingsnyje identifikuojamos rizikos, prognozuojamas produkto dydis ir laikas, reikalingas jam sukurti, sudaromas konfigūracijos valdymo planas.

7. Planavimas Kam reikalingi planai? (1) Efektyvesnis darbas. (2) Įsipareigojimų vykdymas. (3) Kokybiškesnis darbas. Subalansuoti planai. Kaip sekti progresą pagal planą. Uždirbtos vertės metodas (Earned Value Method) Planavimo detalumas. TSP reikalauja planuoti 10 valandų arba mažesniais darbais. Neplanuotos užduotys. Siūloma pirmuosiuose cikluose kiekvieną savaitę palikti joms šiek tiek laiko (5-10% viso projekto laiko). Kokybės planas: santraukų rodikliai (angl. Summary Rates); procentas be defektų (angl. Percent Defect-Free); defektai puslapyje (angl. Defects Per Page); defektai / KLOC (angl. Defects / KLOC); defektų santykiai (angl. Defect Ratios); projekto vykdymo laiko santykiai (angl. Development Time Ratios); A / FR; peržiūrų ir inspekcijų greičiai (angl. Review and Inspection Rates); defektų darymo greičiai (angl. Defect-Injection Rates); defektų šalinimo greičiai (angl. Defect-Removal Rates); defektų šalinimas etapuose (angl. Phase Yield); defektų šalinimas procese (angl. Process Yield).

8. Reikalavimai Reikalavimai turi būti aiškūs ir prasmingi. Reikalavimai formuluojami remiantis poreikių specifikacija. Reikalavimų dokumentavimas: Sistemos Reikalavimų Specifikacija (SRS). Kodėl reikalavimai yra svarbūs? Svarbiausia yra reikalavimų apibrėžimo procesas. Reikalavimų formulavimo rezultatas yra bendras susitarimas. Reikalavimų pasikeitimai ir jų valdymas. Visi reikalavimų pakeitimai kainuoja. Reikalavimų formulavimas, kai poreikių specifikacija yra nepilna ar neaiški.

9. Projektavimas Programos projekto specifikacija (angl. Software Design Specification - SDS). Projektavimas komandose. Projektavimas pakartotiniam panaudojimui. Projektavimas naudojimo patogumui. Projektavimas testavimui. Projekto peržiūra ir inspektavimas.

10. Įgyvendinimas Prieš imantis realizacijos, svarbu įsitikinti, kad baigtas aukšto lygio projektavimas (siūlomas atominių elementų sudėtingumas – ne daugiau kaip 150 kodo eilučių). Realizacijos standartai. Standartų peržiūra. Kodavimo standartai. Dydžių standartai. Defektų standartai. Realizacijos strategija. Realizacijos strategija susijusi su peržiūromis, pakartotiniu panaudojimu bei testavimu. Peržiūros ir inspekcijos.

11. Testavimas Pagrindinės TSP testavimo veiklos:1. Surinkti sistemą, naudojant sukurtus ir jau ištestuotus atskirus modulius.2. Atlikti integracijos testus: patikrinti, ar sistema “teisingai” surinkta, ar yra visi komponentai ir kaip jie kartu funkcionuoja.3. Atlikti sistemos testus: patikrinti, ar produktas atlieka tai, kas apibrėžta sistemos reikalavimuose. Tuo pat metu atliekamos ir šios veiklos:- Identifikuoti prastos kokybės modulius ir sugrąžinti juos kokybės/proceso vadovui, kuris turi juos įvertinti bei atiduoti ištaisyti.- Identifikuoti modulius, kurie yra vis dar prastos kokybės net ir po pataisymų bei grąžinti juos kokybės/proceso vadovui, kuris turi juos atiduoti perdirbti arba pakeisti. Testų planavimas. Testų rezultatų sekimas ir matavimas.

12. Dokumentavimas Kalbama iš esmės apie vartotojo vadovo kūrimą testavimo etape. Kokia turi būti gera vartotojo dokumentacija (“vartotojo vadovas”): • Reikia rašyti ne tai, kokia sistema buvo sukurta, o tai, ko labiausiai reikia vartotojui, dirbančiam su sistema: kaip vartotojui pradėti naudotis, ką gali daryti su produktu, kaip surasti reikiamą informaciją; • Siūloma naudoti: Terminų žodyną; Klaidų pranešimų skyrių; Esminių skyrių rodyklę; Detalų turinį; • Rašyti trumpus sakinius; Naudoti paprastus žodžius ir frazes; Naudoti sąrašus bei kitaip struktūrizuoti informaciją; • Dokumentas turi būti gerai skaitomas ir suprantamas. Peržiūrint, turi būti paliesti šie aspektai: dokumento struktūra; terminologija, turinys, kruopštumas, skaitomumas, suprantamumas Gera praktika laikoma, kai vartotojo dokumentacija duodamas peržiūrėti vartotojams, anksčiau nesinaudojusiems šia sistema ir jų prašoma atlikti veiksmus su sistema, aprašytus vartotojo dokumentacijoje.

13. Aptarimas Aptarimas - tvarkingas būdas nustatyti sritis, kurios reikalauja tobulinimo, ir padaryti reikiamus pakeitimus. Kodėl reikalingas aptarimas? Kaip aptarimas gali padėti? Proceso pagerinimo pasiūlymai.

14. Pagrindiniai TSP principai • Programų sistemų kūrėjai dirbs efektyviai, jei naudos apibrėžtą ir matuojamą procesą. • Komanda bus motyvuota, jei dirbs turėdama bendrą viziją ir žinodama jai keliamus tikslus. • Procesas geriausiai atitiks komandos poreikius, jei bus jai pritaikytas. • Komandos nariai žinos už ką jie atsakingi ir kam turi atsiskaityti, jei komandoje bus įtvirtintos aiškios atsakomybės ir atskaitomybė. • Programų sistemų kūrėjai aktyviai keisis informacija ir žiniomis, jei komandoje bus skatinamas nuolatinis bendravimas. • Suteikti galimybę programų sistemų kūrėjams dirbti taip, kaip jie įpratę, tačiau prisilaikant nustatyto komandos proceso ir atsižvelgiant į jų pačių surinktus duomenis ir kolegų patirtį. • Norint pastoviai gerinti savo veiklą, reikia nuolat tobulinti procesą, atsižvelgiant į proceso metu sukauptus istorinius duomenis ir rodiklius. • Skatinti būsimų produktų kokybės užtikrinimą ir galimų rizikų įvertinimą bei valdymą.

15. TSP praktikos 1. Komandos tikslų suformulavimas ir dokumentavimas. 2. Rolių ir jų atsakomybių apibrėžimas bei priskyrimas. 3. Komunikavimo procedūrų apibrėžimas. 4. Projekto progreso sekimas. 5. Komandos proceso evoliucionavimo/pritaikymo plano paruošimas ir jo įgyvendinimas. 6. Produkto kūrimo strategijos ruošimas. 7. Produkto kūrimo plano ir tvarkaraščio ruošimas. 8. Reikalavimų specifikacijos ruošimas. 9. Projektavimas. 10. Rizikų įvertinimas ir valdymas. 11. Kokybės planavimas ir valdymas.

16. PSP ir TSP taikymų patirties analizės išvados • Įdiegus procesus, nepastebėta jokių esminių produktyvumo pokyčių, tačiau sumažėjo laiko skiriamo produkto kompiliavimui ir testavimui sąnaudos. • Procesų taikymas padidina laiko sąnaudas, tačiau ilgainiui jos turėtų sumažėti, kadangi proceso veiklų taikymas turi tapti įpročiu. • Ženkliai padidėjo darbuotojų motyvacija kurti kokybiškus produktus. • Pagerėjo kuriamų produktų kokybė. • Padidėjo darbuotojų pasitenkinimas jų atliekamu darbu, o tai suteikia galimybę toliau optimizuoti procesus bei juos pritaikyti kitose srityse.

17. PSP ir TSP taikymų patirties analizės išvados (2) • Būtina naudoti įrankius, leidžiančius automatizuoti procesų metu surenkamų duomenų agregavimą ir analizę. Šie įrankiai turi būti pilnai integruoti, t.y. komandos narys pateikia tik pradinius proceso duomenis, o visos apskaičiuotų rodiklių reikšmės automatiškai pernešamos į kitas formas be programuotojo įsikišimo. Tai yra viena iš pagrindinių sąlygų, norint sėkmingai naudoti įdiegtus procesus ir būti užtikrintiems gautų duomenų kokybe. • Proceso vertinimui nenaudoti paties proceso metrikų. Tam tikslui turi būti naudojami “išoriniai” proceso vertinimo metodai. • Nors automatiniai įrankiai užtikrina surinktų duomenų analizės kokybę, tačiau užtikrinti surenkamų duomenų kokybę beveik neįmanoma. Tai priklauso nuo kiekvieno procesą vykdančio asmens noro ir motyvacijos pateikti pilnus ir korektiškus duomenis. • Aiškiai apibrėžti, kokiu tikslu renkami duomenys, kad būtų išvengta tyčinio duomenų klastojimo.

18. ?