PI_12paskaita

981 views
918 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
981
On SlideShare
0
From Embeds
0
Number of Embeds
66
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

PI_12paskaita

  1. 1. Program ų inžinerija Programinės įrangos kūrimas
  2. 2. Turinys <ul><li>Bazinės problemos, susijusios su PĮ kūrimu </li></ul><ul><li>PĮ kūrimo valdymas </li></ul><ul><li>PĮ kūrime taikomos priemonės ir metodai </li></ul><ul><li>Ekstremalus programavimas </li></ul>
  3. 3. Bazinės problemos, susijusios su PĮ kūrimu
  4. 4. Pagrindinės PĮ kūrimo problemos <ul><li>Sudėtingumo mažinimas </li></ul><ul><li>Pakeitimų prognozavimas </li></ul><ul><li>Sukurtos PĮ patikrinimas </li></ul><ul><li>PĮ kūrimo standartai </li></ul>
  5. 5. Sudėtingumo mažinimas <ul><li>Svarbiausias tikslas realizuojant PĮ yra kuo labiau sumažinti jos sudėtingumą </li></ul><ul><li>PĮ kodo sudėtingumo laipsnis įtakoja: </li></ul><ul><ul><li>PĮ testavimą </li></ul></ul><ul><ul><li>PĮ priežiūrą ir palaikymą </li></ul></ul><ul><li>PĮ kodo sudėtingumą galima sumažinti laikantis PĮ kūrimo standartų, taikant įvairias PĮ kūrimo priemones bei PĮ kūrimo kokybę užtikrinančius metodus </li></ul>
  6. 6. Pakeitimų prognozavimas <ul><li>PĮ keisis viso savo gyvavimo ciklo metu, todėl labai svarbu jos kūrimo fazėje įvertinti šį faktą </li></ul><ul><li>PĮ yra labai priklausoma nuo savo veikimo aplinkos, kurios pokyčiai gali labai įvairiai įtakoti sukurtą PĮ </li></ul>
  7. 7. Sukurtos PĮ patikrinimas (1) <ul><li>PĮ turi būti kuriama taip, kad jos kode būtų galima nesunkiai aptikti klaidas, atlikti nepriklausomą PĮ testavimą bei papildyti naujomis galimybėmis atidavus ją naudoti vartotojams </li></ul>
  8. 8. Sukurtos PĮ patikrinimas (2) <ul><li>Lengvai patikrinamą PĮ padeda sukurti specialiai PĮ kodavimui skirti standartai, kurie rekomenduoja: </li></ul><ul><ul><li>nuolat atlikti programos kodo peržiūras </li></ul></ul><ul><ul><li>vienetų testavimą </li></ul></ul><ul><ul><li>kuo rečiau naudoti sudėtingas ir sunkiai suprantamas programavimo kalbų konstrukcijas </li></ul></ul>
  9. 9. PĮ kūrimo standartai (1) <ul><li>PĮ kūrimo standartai apima: </li></ul><ul><ul><li>programavimo kalbas (pavyzdžiui, programavimo kalbų, tokių kaip Java ar C++, standartai) </li></ul></ul><ul><ul><li>komunikavimo metodus (pavyzdžiui, standartai, apibrėžiantys dokumento formatą ir turinį) </li></ul></ul><ul><ul><li>platformas (pavyzdžiui, programavimo interfeisų standartai, aprašantys operacinės sistemos kreipinius) </li></ul></ul><ul><ul><li>priemones (pavyzdžiui, objektinio projektavimo notacijos standartas UML) </li></ul></ul>
  10. 10. PĮ kūrimo standartai (2) <ul><li>Įmonėje taikomi standartai gali būti: </li></ul><ul><ul><li>išoriniai (sukurti įvairių už standartus atsakingų institucijų, tokių kaip IEEE, OMG, ISO ir pan.) </li></ul></ul><ul><ul><li>vidiniai (sukurti pačios įmonės darbuotojų) </li></ul></ul>
  11. 11. PĮ kūrimo valdymas
  12. 12. Programų inžinerijos proceso modeliai ir PĮ kūrimas <ul><li>Egzistuoja nemažai programų inžinerijos proceso modelių: vieni jų labiau akcentuoja PĮ kūrimo fazę, kiti – mažiau </li></ul>
  13. 13. Tiesiniai programų inžinerijos proceso modeliai <ul><li>Kai kurie modeliai yra labiau tiesiniai PĮ kūrimo atžvilgiu negu kiti: jie labiau akcentuoja etapus, einančius prieš PĮ kūrimą ir yra linkę atskirti kiekvieną šių veiklų </li></ul><ul><li>Pavyzdžiui, krioklio modelis traktuoja PĮ kūrimą, kaip veiklą, atliekamą tik po kruopščios reikalavimų analizės, projektavimo ir planavimo </li></ul><ul><li>Tiesiniuose programų inžinerijos proceso modeliuose PĮ kūrimo fazė traktuojama kaip jos kodo rašymas ( coding ) </li></ul>
  14. 14. Iteraciniai programų inžinerijos proceso modeliai <ul><li>Kiti modeliai yra labiau iteraciniai: jiems priklauso evoliucinis modelis, ekstremalus programavimas ( extreme programming ) ir t.t. </li></ul><ul><li>Šie modeliai linkę traktuoti PĮ kūrimą kaip veiklą, kuri vyksta lygiagrečiai arba net persidengia su kitomis programų inžinerijos veiklomis, tokiomis kaip reikalavimų inžinerija, projektavimas, planavimas ir kt. </li></ul><ul><li>Iteraciniuose programų inžinerijos proceso modeliuose PĮ kūrimas traktuojamas kaip visų šių veiklų kombinacija, plius programos kodo rašymas </li></ul>
  15. 15. PĮ kūrimo planavimas (1) <ul><li>PI proceso modelio pasirinkimas nulemia visą tolimesnį PĮ kūrimo planavimą </li></ul><ul><li>Priklausomai nuo pasirinkto PI proceso modelio, reikia nustatyti prieš-sąlygas ir nurodyti iki kokio lygio jos turi būti patenkintos, kad būtų galima pradėti PĮ kūrimą </li></ul><ul><li>Taip pat pasirinktas PI proceso modelis įtakoja sudėtingumo mažinimo, pakeitimų prognozavimo ir sukurtos PĮ patikrinimo tikslų įgyvendinimą </li></ul>
  16. 16. PĮ kūrimo planavimas (2) <ul><li>Pasirinktas PI proceso modelis taip pat apibrėžia, kaip bus kuriami ir integruojami PĮ komponentai, tikrinama sukurtos PĮ kokybė bei paskirstomos užduotys projekte dalyvaujantiems žmonėms </li></ul>
  17. 17. PĮ kūrimo proceso rezultatai <ul><li>Daugelis PĮ kūrimo proceso rezultatų gali būti išmatuojami </li></ul><ul><li>Jiems priklauso sukurtas kodas, modifikuotas kodas, pakartotinai panaudotas kodas, kodo peržiūrų statistika, ištaisytų ir surastų klaidų koeficientas ir t.t. </li></ul><ul><li>P Į kūrimo proceso matavimai gali būti naudingi užtikrinant PĮ kokybę, tobulinant kūrimo procesą ir kt. tikslams pasiekti </li></ul>
  18. 18. PĮ kūrime taikomos priemonės ir metodai
  19. 19. PĮ kūrimo kalbos <ul><li>PĮ kūrimo kalbos apima bet kokias komunikavimo formas, kurių pagalba žmogus gali užrašyti problemos sprendimą, kurį turi įvykdyti kompiuteris </li></ul>
  20. 20. PĮ kūrimo kalbų tipai <ul><li>Konfigūracijos kalbos (configuration languages) </li></ul><ul><li>Programuotojo paketai (toolkits) </li></ul><ul><li>Programavimo kalbos (programming languages) </li></ul>
  21. 21. Konfigūracijos kalbos <ul><li>Jų pagalba PĮ kūrėjai riboto pasirinkimų skaičiaus pagalba kuria naują arba tipinę PĮ produkto instaliaciją </li></ul><ul><li>J ų pavyzdžiais gali būti Windows arba Unix konfigūraciniai failai </li></ul>
  22. 22. Programuotojo paketai <ul><li>Tai programų, paprogramių, standartinių procedūrų rinkiniai skirti programoms kurti </li></ul>
  23. 23. Programavimo kalbos (1) <ul><li>Tai lanksčiausias PĮ kūrimo kalbų tipas </li></ul><ul><li>Jose pateikiama mažiausiai informacijos apie taikymo sritį ir kūrimo procesą, todėl programavimo kalbos reikalauja gero pasiruošimo ir apmokymų </li></ul>
  24. 24. Programavimo kalbos (2) <ul><li>Skiriamos trys programavimo kalbose naudojamos notacijos: </li></ul><ul><ul><li>lingvistinė </li></ul></ul><ul><ul><li>formali </li></ul></ul><ul><ul><li>vizuali </li></ul></ul>
  25. 25. Lingvistinės notacijos <ul><li>Lingvistinės notacijos atveju naudojami kasdienės kalbos žodžiai, kurie grupuojami į tam tikrą formą </li></ul><ul><li>Ši forma pasižymi sintakse, labai panašia į paprasto sakinio </li></ul>
  26. 26. Formalios notacijos <ul><li>Formalios notacijos naudoja tikslius, nedviprasmiškus ir formalius (arba matematinius) užrašus </li></ul>
  27. 27. Vizualios notacijos (1) <ul><li>Vizualios notacijos grindžiamos sistemą sudarančių elementų vizualiu atvaizdavimu </li></ul><ul><li>Jos leidžia išdėlioti sistemą sudarančius elementus kompiuterio ekrane ir dažniausiai naudojamos vartotojo sąsajos programavime </li></ul>
  28. 28. Vizualios notacijos (2)
  29. 29. Dažniausiai užduodami klausimai programuojant <ul><li>Kaip sukurti suprantamą programos kodą, naudojant prasmingus kintamųjų vardus bei tvarkingai išdėstant programos kodą? </li></ul><ul><li>Kaip valdyti programoje pasirodančias klaidas: tiek planuotas, tiek ne ( exceptions )? </li></ul><ul><li>Kaip suskirstyti programos kodą į klases, paketus ar kitas panašias struktūras? </li></ul><ul><li>Kaip dokumentuoti programos kodą? </li></ul><ul><li>Kaip atlikti programos kodo suderinimą ( tuning )? </li></ul>
  30. 30. PĮ kūrimas ir testavimas <ul><li>PĮ kūrimo metu dažniausiai yra atliekamas dviejų rūšių testavimas: </li></ul><ul><ul><li>vienetų testavimas </li></ul></ul><ul><ul><li>integracijos testavimas </li></ul></ul><ul><li>Kartais testavimas yra atliekamas užbaigus rašyti programos kodą, o kartais testavimo atvejai paruošiami dar prieš rašant programą </li></ul>
  31. 31. Pakartotinis panaudojimas (1) <ul><li>Kartais PĮ yra kuriama panaudojant jau sukurtus komponentus </li></ul><ul><li>Ši technologija yra vadinama pakartotiniu panaudojimu </li></ul>
  32. 32. Pakartotinis panaudojimas (2) <ul><li>Naudojant pakartotinį panaudojimą PĮ kūrimo procese, reikia: </li></ul><ul><ul><li>Parinkti komponentus, duomenų bazes, testavimo procedūras bei duomenis, kuriuos galima panaudoti pakartotinai </li></ul></ul><ul><ul><li>Įvertinti atrinktų elementų pakartotinio panaudojimo laipsnį </li></ul></ul><ul><ul><li>Aprašyti, kaip buvo panaudoti atrinkti elementai naujame programos kode, testavimo procedūrose bei testavimo duomenyse </li></ul></ul>
  33. 33. Programos kodo kokybės užtikrinimas <ul><li>Sukurto programos kodo kokybę galima užtikrinti naudojant šiuos metodus: </li></ul><ul><ul><li>vienetų ir integracijos testavimą </li></ul></ul><ul><ul><li>programos derinimą ( debugging ) </li></ul></ul><ul><ul><li>programos kodo peržiūras </li></ul></ul><ul><ul><li>statinę kodo analizę </li></ul></ul>
  34. 34. Ekstremalus programavimas
  35. 35. Ekstremalaus programavimo struktūra
  36. 36. Visa komanda (1) <ul><li>Visi projekte dalyvaujantys asmenys susirenka drauge ir sudaro komandą </li></ul><ul><li>Į ją būtinai turi įeiti verslo atstovas arba klientas (“Customer”) , kuris pateikia reikalavimus, nustato prioritetus bei valdo projektą </li></ul><ul><li>Taip pat į komandą įeina programuotojai ir testuotojai. Pastarieji turi padėti klientui sudaryti programos priėmimo ( acceptance ) testus </li></ul><ul><li>Komandai priklausantys analitikai padeda vartotojui suformuluoti reikalavimus sistemai </li></ul>
  37. 37. Visa komanda (2) <ul><li>Dažniausiai kiekviena komanda turi trenerį, kuris padeda komandai dirbti kartu ir valdo visą procesą, bei vadybininką, teikiantį resursus, palaikantį ryšius su išore bei koordinuojantį komandos veiksmus </li></ul><ul><li>Geriausia kuomet komandoje nėra ypatingų “specialistų”, o tik žmonės, turintys reikalingas žinias bei įgūdžius </li></ul>
  38. 38. Žaidimo planavimas (1) <ul><li>Žaidimo planavimas susideda iš dviejų dalių: </li></ul><ul><ul><li>numatyti, kas bus padaryta paskirtai datai </li></ul></ul><ul><ul><li>numatyti, ką reikės daryti toliau </li></ul></ul><ul><li>Visas dėmesys ekstremaliame programavime yra sukoncentruotas ties projekto valdymu, kur svarbiausia atsakyti į du klausimus: </li></ul><ul><ul><li>Kaip suplanuoti versijas? </li></ul></ul><ul><ul><li>Kaip suplanuoti iteracijas? </li></ul></ul>
  39. 39. Žaidimo planavimas (2) <ul><li>Kaip suplanuoti versijas? </li></ul><ul><ul><li>Šiame etape klientas pateikia programuotojams savo pageidavimus, o šie įvertina, ar sunku tuos pageidavimus realizuoti ir kiek tai kainuos </li></ul></ul><ul><ul><li>Tuomet klientas pateikia projekto planą, kuriame yra pateikiamas preliminarus versijų sąrašas ir jų pristatymo datos </li></ul></ul>
  40. 40. Žaidimo planavimas (3) <ul><li>Kaip suplanuoti iteracijas? </li></ul><ul><ul><li>Dažniausiai komanda gauna nurodymus kas porą savaičių, todėl kiekviena iteracija dažniausiai ir trunka dvi savaites </li></ul></ul><ul><ul><li>Kiekvienos iteracijos pabaigoje yra pristatoma veikianti sistemos dalis. Ją įvertinęs, vartotojas pateikia pakoreguotą projekto planą, o programuotojai, įvertinę, kas buvo padaryta prieš tai, nusprendžia, ką jie padarys iš pateikto plano </li></ul></ul><ul><ul><li>Užduotys vėl išskaidomos į smulkesnes, apskaičiuojamos sąnaudos ir t.t. </li></ul></ul>
  41. 41. Nedidelės versijos <ul><li>Programa pristatoma klientui nedideliais gabaliukais </li></ul><ul><li>Klientas turi nuspręsti, ką daryti su gauta nauja sistemos versija. Pageidautina, kad jis ją atiduotų naudoti galutiniams vartotojams </li></ul><ul><li>Internetinių programų atveju naujos versijos galutiniams vartotojams gali būti pateikiamos kas kelias dienas, o informacinės sistemos – kas mėnesį arba dažniau </li></ul>
  42. 42. Vartotojo testai <ul><li>Kiekvienos iteracijos rezultatui klientas pateikia priėmimo testus, kurie įrodytų, kad sukurta sistemos dalis funkcionuoja teisingai </li></ul><ul><li>Šiuos testus naudoja ne tik klientas, vertindamas pristatomą sistemos dalį, bet ir komanda, kurdama programą </li></ul><ul><li>Jeigu testas duoda pageidaujamus rezultatus, laikoma, kad sistema funkcionuoja teisingai </li></ul>
  43. 43. Kodavimo standartai <ul><li>Visi projekte dalyvaujantys programuotojai turi prisilaikyti tam tikrų įmonėje galiojančių programavimo standartų, kad sukurtas kodas atrodytų tarsi jį būtų programavęs vienas asmuo </li></ul>
  44. 44. Nuolatinė integracija (1) <ul><li>Kadangi kiekvienos iteracijos metu sistema yra papildoma vis naujomis funkcijomis, vyksta nuolatinė sistemos komponentų integracija </li></ul><ul><li>Dažnai visos sistemos veikimo klaidos atsiranda pradėjus integracijos procesą </li></ul>
  45. 45. Nuolatinė integracija (2) <ul><li>Jeigu komponentai integruojami retai, tuomet padidėja tikimybė, kad jie bus tarpusavyje nesuderinami, kadangi kiekvienas programuotojas yra įsigilinęs tik į savo kodo gabalėlį ir dirbdamas visai negalvoja visos sistemos mastu </li></ul><ul><li>Kadangi integracijos klaidų taisymas užima nemažai laiko, visas projektas stoja, tuo pačiu padidėja rizika, kad konkurentai gali įmonę aplenkti greičiau sukūrę panašaus funkcionalumo produktą </li></ul>
  46. 46. Į testavimą orientuotas kūrimas <ul><li>Kadangi kiekvienas klientui pateikiamas programos gabaliukas yra testuojamas, galima teigti, kad sistema yra ištestuota beveik 100% </li></ul>
  47. 47. Paprastas projektavimas <ul><li>Ekstremalaus programavimo atveju, sistema projektuojama tik vienai iteracijai, t.y. projektuojama ne visa sistema, o tik jos dalis, kuri turi būti realizuota einamosios iteracijos metu </li></ul>
  48. 48. Programavimas poromis <ul><li>Realizuoti kiekvienai sistemos funkcijai yra paskiriami du programuotojai, t.y. du programuotojai tarsi daro vieno programuotojo darbą </li></ul><ul><li>Taip yra užtikrinama, kad programos kodas bus peržiūrėtas bent vieno programuotojo, kuris prie jo nedirbo, taip pat bus atliktas geresnis projektavimas ir testavimas </li></ul><ul><li>Be to, programuotojai gali pasimokyti vienas iš kito, pasidalinti idėjomis ir taip tobulinti savo profesinius įgūdžius </li></ul>

×