• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
PI_12paskaita
 

PI_12paskaita

on

  • 963 views

 

Statistics

Views

Total Views
963
Views on SlideShare
902
Embed Views
61

Actions

Likes
0
Downloads
17
Comments
0

2 Embeds 61

http://paskaitos.roleka.lt 60
http://roleka.elekta.lt 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    PI_12paskaita PI_12paskaita Presentation Transcript

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