1 / 22

Ekstreemprogrammeerimine

Ekstreemprogrammeerimine. Sven Heiberg. Arendusprotsess. Arendusprotsessi mõiste abil püütakse mõista tarkvaraarendust kui protsessi eesmärgiga parandada nii protsessi kui ka tulemust Arendusprotsessi parandamiseks on võetud kasutusele erinevaid metoodikaid

jamal-tran
Download Presentation

Ekstreemprogrammeerimine

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ekstreemprogrammeerimine Sven Heiberg 3.3. Ekstreemprogrammeerimine

  2. Arendusprotsess • Arendusprotsessi mõiste abil püütakse mõista tarkvaraarendust kui protsessi eesmärgiga parandada nii protsessi kui ka tulemust • Arendusprotsessi parandamiseks on võetud kasutusele erinevaid metoodikaid • sunnivad tegutsema distsiplineeritumalt • suunavad jõupingutused konkreetsete probleemide lahendamisele 3.3. Ekstreemprogrammeerimine

  3. XP • Ekstreemprogrammeerimine (XP) • Kergekaaluline, kohanduv, inimese- ja suhtluskeskne ning probleemilahendamisele orienteeritud arendusprotsess väikestele meeskondadele olukordadeks, kus kergesti muudetava lahenduse loomine on tulevikuennustamisest odavam • XP on n.n. väle arendusprotsess ja eelistab • isikuid ja suhtlust protsessile ja vahenditele • töötavat tarkvara kõikehaaravale dokumentatsioonile • kliendiga suhtlust lepinguläbirääkimistele • muutustele vastamist plaani järgimisele 3.3. Ekstreemprogrammeerimine

  4. Neli muutujat • Arendusprotsessi kontrollivad neli muutujat • Maksumus • Aeg • Kvaliteet • Ulatus • Neljast muutujast kolme väärtused võib lasta määrata välistel jõududel, arendusmeeskond määrab neljanda muutuja väärtuse 3.3. Ekstreemprogrammeerimine

  5. Väärtushinnangud • Lühiajalised individualistlikud eesmärgid vs. pikaajalised kollektiivsed eesmärgid • Suhtlus – arendusprotsessi efektiivsuse aluseks on suhtlus kõigi osapoolte vahel • Lihtsus – lahendada tuleb tegelikke probleeme • Tagasiside – adekvaatne tagasiside aitab tarkvara täiustada • Julgus – muutustega kaasa minemine nõuab julgust, vigade tunnistamine nõuab julgust 3.3. Ekstreemprogrammeerimine

  6. Printsiibid • Printsiibid tulenevad väärtustest, printsiibide järgimine on mõõdetavam kui väärtuste järgimine • Kiire tagasiside • Lihtsuse eeldamine • Inkrementaalsed muutused • Muutuste aksepteerimine • Kvaliteet 3.3. Ekstreemprogrammeerimine

  7. Õppimise õpetamine Järk järguline alustamine Võidu nimel tegutsemine Konkreetsed katsetused Avatud ja aus suhtlus Tegutsemine inimese loomust arvestades Vastutuse võtmine Kohandamine vastavalt vajadustele Paindlik tegutsemine Mõistlik mõõtmine Veel printsiipe 3.3. Ekstreemprogrammeerimine

  8. Tarkvaraarenduse etapid • Millistest etappidest koosneb vähegi mahukama programmi koostamine? • Kodeerimine – lahenduse koostamine probleemile • Testimine – lahenduse kvaliteedi mõõtmine • Kuulamine – lahendatava probleemi leidmine, täpsustamine • Projekteerimine – lahendusele loogilise, edasiarendatava struktuuri andmine 3.3. Ekstreemprogrammeerimine

  9. Plaanimismäng Väikesed redaktsioonid Metafoor Lihtsad lahendused Testimine Rekodeerimine Paarisprogrammeerimine Kollektiivne omand Pidev integreerimine 40-tunnine töönädal Klient meeskonnas Koodimisstandardid XP praktikad 3.3. Ekstreemprogrammeerimine

  10. Äriinimeste otsustada Projekti ulatus Alamülesannete prioriteedid Redaktsioonide koostis Redaktsioonide väljalaske ajad Arendajate otsustada Mahuhinnangud Strateegiliste äriotsuste tehnilised tagajärjed Arendusprotsess Detailne ajagraafik Plaanimismäng 3.3. Ekstreemprogrammeerimine

  11. Väikesed redaktsioonid • Arendusmeeskonnale on oluline kliendi tagasiside • Õigeagne tagasiside aitab projekti ebaõnnestumist vältida • Redaktsioon • On nii väike kui võimalik • Sisaldab olulisi ärivajadusi • Omab tervikuna mõtet 3.3. Ekstreemprogrammeerimine

  12. Metafoor • Metafoor on lugu, mis ütleb nii programmeerijale, kliendile kui ka juhile, kuidas süsteem töötab • Ühine vaade • Ühine sõnavara • Loomingulisus • Arhitektuur 3.3. Ekstreemprogrammeerimine

  13. Lihtsad lahendused • Korrektselt kirjutatud tarkvara • Läbib kõik testid • Ei sisalda dubleeritud loogikat • Väljendab ilmutatult kõiki programmeerija olulisi kavatsusi • Ei oma liigseid klasse ja meetodeid • Täna tuleb lahendada tänaseid probleeme • XP ei tegele ennustamisega vaid valmisolekuga jätkata ükskõik millise tuleviku korral 3.3. Ekstreemprogrammeerimine

  14. Testimine • Erisust ilma automaatse testita ei eksisteeri • Komponenditeste kirjutavad programmeerijad • Funktsionaalsed testid koostatakse koos kliendiga • Testid on kvaliteedi tagatis ja mõõdupuu • 100% • Komponenditestid võimaldavad rahulikult katsetada ja rekodeerida • Test kirjutatakse enne koodi, ehk siis • Kõigepealt projekteeritakse liides • Pannakse kirja tulemus, mida soovitakse saada 3.3. Ekstreemprogrammeerimine

  15. Rekodeerimine • Rekodeerimine on XP viis projekteerida • Rekodeerimine on programmi struktuuri teisendamine selliselt, et funktsionaalsus säilib • Enne erisuse lisamist rekodeerida nii, et erisust oleks lihtne lisada • Peale erisuse lisamist lihtsustada koodi säilitades samal ajal funktsionaalsuse • Rekodeeritakse vaid siis kui süsteem seda palub • Näide – dubleeritud kood 3.3. Ekstreemprogrammeerimine

  16. Paarisprogrammeerimine • Kogu kood kirjutatakse paaris • Kaks inimest töötavad koos ühe arvuti taga • Juht – kirjutab koodi • Kaardilugeja – jälgib juhi tööd, mõtleb kaasa, leiab vigu • Rolle ja paarilisi vahetatakse • Toimub suhtlus, informatsiooni vahetamine 3.3. Ekstreemprogrammeerimine

  17. Koodi omandivormid Ei kellegi kood Viimase, kes muutis kood Kollektiivne omand Armastus oma koodi vastu Eikellegi vastutus? Igal klassil (kihil) oma peremees Rendikood Kollektiivne omand Arusaadavus Mõistmine Pidev integreerimine Kollektiivne omand 3.3. Ekstreemprogrammeerimine

  18. Millal integreerida? Vahetult enne väljalaset? Iga päev. Pidevalt! Pidev integreerimine Iga paari tunni tagant Eraldi masin integreerimiseks Integreerimise käigus ilmnevad probleemid lahendavad integreerijad 100%!!! Pidev integreerimine 3.3. Ekstreemprogrammeerimine

  19. 40-tunnine töönädal • Pidevad ületunnid on tunnistuseks tõsisematest probleemidest • XP korral teist nädalat ületunde ei tehta vaid otsitakse lahendust tegelikule probleemile • Puhkus on oluline eeldus töötahte tekkimiseks ja töövõime säilimiseks 3.3. Ekstreemprogrammeerimine

  20. Klient meeskonnas • Tulevase süsteemi reaalne kasutaja on arendusmeeskonna liige • Vastab küsimustele • Määrab prioriteete • Koostab lähtematerjale testide tarbeks • Kui firma leiab, et üks töötaja on talle tulusam kui töötav süsteem, siis tuleb küsida, kas seda süsteemi üldse vaja on 3.3. Ekstreemprogrammeerimine

  21. Koodimisstandardid • Suhtumine koodimistandarditesse • Standard puudub, kirjutan, kuidas juhtub • Igaühele oma, kasutab igal pool • Igaühele oma, aga teise koodi muutes kasutan tema standardit • Meeskonnal on ühine koodimisstandard 3.3. Ekstreemprogrammeerimine

  22. Infoallikad • Addison-Wesley XP seeria • www.extremeprogramming.org • www.xprogramming.com • http://www.xp123.com/xplor/ • c2.com/cgi/wiki?ExtremeProgrammingRoadmap • www.egroups.com/group/extremeprogramming/ • www.refactoring.com • www.pairprogramming.com 3.3. Ekstreemprogrammeerimine

More Related