Krizsán Norbert - Pálmai László A CMM Képesség Fejlettségi Modell 2. szintjének megfeleltetése az eXtreme Programing életciklus modell segítségével (ver.

Az előadások a következő témára: "Krizsán Norbert - Pálmai László A CMM Képesség Fejlettségi Modell 2. szintjének megfeleltetése az eXtreme Programing életciklus modell segítségével (ver."— Előadás másolata:

1 Krizsán Norbert - Pálmai László A CMM Képesség Fejlettségi Modell 2. szintjének megfeleltetése az eXtreme Programing életciklus modell segítségével (ver 1.1) 2004. május 13.

2 A dolgozat célja Szándék: ► Az eXtreme Programming életciklus modell megfeleltetése a CMM Képességfejlettségi Modell második szintjének. Megvalósítás lépései: ► a CMM Képesség Fejlettségi Modell rövid bemutatása, ► az eXtreme Programing életciklus modell rövid bemutatása, ► a kettő közötti megfeleltetés, ► végül rövid összefoglalásban megfogalmazzuk, hogy milyen főbb kételyek merülhetnek fel a megfeleltetéssel és a továbblépéssel kapcsolatban, és hogy mik lehetnek erre a megoldások.

3 A CMM története ► A CMM (Capability Maturity Model) : Képesség-fejlettségi Modell ► Az új szoftvertechnológiák bevezetésével járó termelésbeli és minőségbeli javulásról szóló kétévtizednyi hiábavaló ígérgetések után a vállalatok ráébredtek, hogy a hiba a munkafolyamatok menedzselésének hiányában keresendő. ► 1986. novemberében az USA Védelmi Minisztériumának megbízásából a Software Engineering Institute (SEI) a Mitre Corp.-nel karöltve megkezdte a munka­folyamat fejlettségi váz fejlesztését. ► A modell számos kulcsfolyamat területen (Key Process Area, KPA) és az azokhoz tartozó javasolt gyakorlatokon keresztül mutatja meg, hogy hogyan fejleszthető a cég teljesítőképessége (software process capability).

4 A CMM definíciója ► A Software-Capability Maturity Model (Képességfejlettségi Modell):  a munkafolyamat menedzsment számára egy józanésszel létrehozott és a szoftverfejlesztés számára minőségbeli fejlesztésekkel kapcsolatos elképzeléseket tartalmazó alkalmazás.  egy közösség által fejlesztett útmutató. A CMM jelenlegi formáját több száz szoftver-szakértő segítségével nyerte el.  a cégszintű fejlődés egy modellje.  támaszt nyújtó váz a megbízható és konzisztens CMM-alapú felbecslő és értékelő eljárásokhoz. Ezeket az eljárásokat széles körben használják a szoftvercégek a fejlesztésben és a megbízók a lehetséges szolgáltatókkal kapcsolatos kockázatok felméréséhez.

5 A CMM szintjei (1) ► A modell 5 szintje a folyamatérettség megállapításán felül segít prioritást felállítani a fejlesztési tervek között. ► A fejlettségi szint mindegyike egy jóldefiniált evolúciós fennsík. Mindegyik szint teljesítéséhez számos, a folyamatfejlesztéssel kapcsolatos célt kell megvalósítani, amelyek együttes teljesülésekor a fejlődés eredménye fontos komponensként fog stabilizálódni a munkafolyamatokban. Minden szinten újabb komponensek épülnek be, így biztosítva a folyamatos fejlődést. SzintMegnevezés Fókusz 5. Szint Optimalizált Állandó munkafolyamat fejlődés 4. Szint Irányított Termék és munkafolyamat minőség 3. Szint Határozott A munkafolyamatok és a szervezett támogatás tervezettsége 2. Szint Ismétlő Projektmenedzsment alapú folyamatok 1. szint Kezdeti Hozzáértő és "hősies" emberek

6 A CMM szintjei (2) Kezdeti (1) Ismétlő (2) Határozott (3) Irányított (4) Optimalizált (5) Ellenőrzött folyamatok („fegyelmezett” projekt) Standard, konzisztens folyamatok (életciklus modell) Előrejelezhető folyamatok (mérés) Folyamatosan fejlesztetett folyamatok (cégszintű javítások mérések alapján)

7 Fejlettségi szintek struktúrája Fejlettségi szint Teljesítőképesség mutatja Kulcsfolyamat területek tartalmaz Célok megvalósít Közös Jellemzők rendszerez Implementálás vagy Intézményesítés céloz Kulcsgyakorlatok tartalmaz Infrastruktúra vagy Tevékenységek leír

8 Az XP (eXtreme Programming) 4 alap értéke és alaptevékenysége Alapértékek ► Bátorság (kockázat, és a vele járó felelősség vállalása) ► Kommunikáció ► Egyszerűség (mindig a legegyszerűbb működő megoldások) ► Visszajelzés Alaptevékenységek ► Kódolás ► Tesztelés ► Meghallgatás ► Design Bátorság Kommunikáció Egyszerűség Visszajelzés

9 Az XP alapelvei ► Gyors visszajelzés ► Egyszerűség feltételezése ► Fokozatos változtatások ► Változtatások választásának elve ► Minőségi munka ► Taníts tanulni ► Kicsi kezdeti befektetés ► Dolgozz a győzelemért ► Konkrét kísérletek ► Nyílt, becsületes kommunikáció ► Elfogadott felelősség ► Helyi adaptáció ► Utazz könnyen ► Becsületes mérések ► Dolgozz mások ösztöneivel

10 Az XP gyakorlati területei ► A tervezési játék ► Gyakori megjelentetés ► Metafora ► Egyszerű design ► Tesztelés ► Újraszerkesztés (refactoring) ► Páros programozás ► Közös tulajdonjog ► Folyamatos integrálás ► 40 órás hét ► Helyben lévő megrendelő ► Kódolási normák

11 Egy ideális XP projekt életciklusa ► Feltárás (néhány hét) ► Tervezés (1-2 nap) ► Iterációk az első kiadásig (2-6 hónap)  Az első, már használható verziója a szoftverterméknek itt jelenik meg (legkésőbb fél évvel a projekt kezdete után!) ► Termelésbe vitel (néhány hét) ► Karbantartás (a következő fázisig)  Ez a normál állapota az XP-nek. ► Vég

12 A megfeleltetés sémája CMM 2. szintjének kulcsterületei Követelmény Menedzsment [KM] Szoftver Projekt-tervezés [SzPT] Szoftver Projekt-követés és - Felügyelet [SzPKF] Szoftver Alvállalkozói Menedzsment [SzAM] Szoftver Minőségbiztosítás [SzMB] Szoftver Konfiguráció Menedzsment [SzKM] XP Bátorság Egyszerűség Kommunikáció Visszajelzés Kódolás Tesztelés Meghallgatás Design Tervezési Játék Helyben Lévő Megrendelő Folyamatos Integrálás Kódolási Normák Gyakori Megjelentetés Közös Tulajdon 40 Órás Hét Újrafaktorálás Páros Programozás

13 Követelmény Menedzsment [KM] Feladata: létrehozni egy stabil álláspontot a megrendelő és a szoftver-projekt között a megrendelő azon követelményei alapján, melyeket majd a szoftver- projekt fog teljesíteni. Célok: ► A szoftverhez kapcsolódó rendszerkövetelmények megfelelő alapot teremtsenek a szoftver tervezéséhez és menedzseléséhez. ► A szoftverrel kapcsolatos terveknek, termékeknek és tevékenységeknek mindig hűeknek kell maradniuk a szoftverhez kapcsolódó követelményekhez. Megoldhatóság XP-vel: ► Helyben Lévő Megrendelő – mint állandó információforrás a változások követésére, ► Folyamatos Integrálás – állandó visszajelzést ad a megrendelő felé, ► Felhasználói Esetek – az előző kettő összekapcsolására

14 Szoftver Projekt-tervezés [SzPT] Feladata: a szoftvertervezés megvalósítására és a szoftver projekt irányítására ésszerű tervek létrehozása. Célok: ► A szoftverrel kapcsolatos becsl é sek dokument á ltak, í gy felhaszn á lhat ó k a szoftver-projekt k ö vet é s é re é s a vele kapcsolatos tervez é sre. ► A szoftver-projekttel kapcsolatos tev é kenys é gek é s k ö telezetts é gek tervezettek é s dokument á ltak. ► Az é rintett csoportok é s egy é nek meg á llapodnak a szoftver-projekttel kapcsolatos k ö telezetts é geikről. Megoldhatóság XP-vel: ► Tervez é si J á t é k – sűrűn iteráló lépések, ► Gyakori Megjelentet é s – dokumentációs fázisok, ► Segít a Bátorság, a rugalmas vezetőség és a szakemberek.

15 Szoftver Projekt-követés és - Felügyelet [SzPKF] Feladata: a jelenlegi előmenetelről megfelelő, kielégítő képet biztosítani, hogy a vezetés hatékonyan közbeléphessen, ha a szoftver-projekt véghezvitele érezhetően eltér a tervezettől. Célok: ► A jelenlegi eredmények és a teljesítmény nyomon követhetőek és összevethetőek a tervekkel ► A tervezettől való eltérés esetén korrigáló lépések történnek ► A szoftverrel kapcsolatos kötelezettségekben történt változásokról az érintett csoportok és egyének állapodnak meg Megoldhatóság XP-vel: ► A vezetőségnek elég a projekt sebességét (egy iterációs lépésben megvalósítandó „sztorik” száma) és az előző (sűrűn frissített) alapverziót figyelnie, hogy megfelelő betekintéssel rendelkezzen a projekt előmenetelébe. ► A nyílt kommunikációs csatorna a vezetőség és a fejlesztők között biztosítja a második célt, a fejlesztők és a megrendelők között pedig a harmadik célt.

16 Szoftver Alvállalkozói Menedzsment [SzAM] Feladata: képesített alvállalkozók kiválasztása és hatékony vezetése Célok: ► Képzett alvállalkozó kiválasztása ► Megállapodás az egymáshoz fűződő kötelességekről ► Folyamatos kapcsolattartás a fő- és az alvállalkozó között ► A fővállalkozó nyomon követi az alvállalkozó teljesítményét és eredményeit Megoldhatóság XP-vel: ► Probléma: az XP-nek erre nincs gyakorlata, sem infrastruktúrája ► Ellenben hozzáértő, rugalmas vezetéssel megoldható ► Az alvállalkozónál egy ember a csoportból, mint helyben lévő megrendelő ► Három optimális eset:  Nincs alvállalkozás  Az XP-t adaptált csoport az alvállalkozó  Az alvállalkozói csoport legalább CMM 2-es szinten van (probléma: közös tulajdon)

17 Szoftver Minőségbiztosítás [SzMB] Feladata: a projekt által használt folyamatokba és készülő termékekbe megfelelő betekintéssel bíró irányítás biztosítása Célok: ► Az SzMB tevékenységek kellően megtervezettek ► Használatban lévő folyamatokhoz, normákhoz, eljárásokhoz ragaszkodás ► Az érintett csoportok megfelelően informáltak az SzMB eredményekről ► A projekten belül megoldhatatlannak ítélt tételek nyilvántartása Megoldhatóság XP-vel: ► Kódolási Normák és a Közös Tulajdon segítik a kód gyors megértését ► Az előre meghatározott normák segítik a minőség javítását ► A Páros Programozás jobb munkára ösztönöz, és csökkenti a hibák előfordulásának esélyét

18 Szoftver Konfiguráció Menedzsment [SzKM] Feladata: a szoftver-projekt termékeinek a teljes életciklus alatti integritás létrehozása és megőrzése Célok: ► A konfigurációs menedzsment tevékenységei megtervezettek ► A kiválasztott szoftver munkaeszközök azonosítottak és ellenőrzöttek ► A munkaeszközökben beállt változások kontrolláltak ► Az érintett egyének és csoportok informáltak az alapkiadás állapotáról és tartalmáról Megoldhatóság XP-vel: ► A Közös Tulajdon biztosítja a fejlesztés folyamatosságát ► A Folyamatos Integrálás biztosítja a konzisztenciát ► A Gyakori Megjelentetés és a sűrűn létrehozott alapverziók biztosítják a projekt helyes menetét, és segítik az irányítását

19 Konklúziók Főbb megoldandó feladatok: ► Dokumentálni, dokumentálni, dokumentálni  Az XP nehezményezi a programozók általi dokumentáció folyamatát, mondván a minimális dokumentáció felesleges, mert aki írta a kódot az úgyis érti azt.  Olyan alkalmazott felvételével megoldható, akinek semmi más feladata nincs, mint a folyamatos dokumentáció. ► Csoportok létrehozása  A második szintre való lépéshez a következő csoportok létrejövette szükséges: ► Szoftver Tervező Csoport ► Alvállalkozói Csoport ► Minőségbiztosító Csoport  A csoportok feladataiban van átfedés.

20 Potenciális hibalehetőségek Szintátugrás megvalósíthatatlansága: ► A Képesség Fejletségi Modellben történő szintátugrás nem kivitelezhető, mert az egyes szintek úgy lettek meghatározva, hogy biztos alapot nyújtsanak a következő szint eléréséhez. ► Azonban megalapozható bármelyik kulcsterület, ha vállalt a kockázat, hogy az adott kulcsterület nem funkcionálhat megfelelően a neki hátteret biztosító kulcsterületek nélkül. Hamis szembenállás: ► A SW-CMM részben vagy alig érinti a menedzsment és a cég kérdéseit  Az olyan erősen kollaboráló környezet implementálása, mint amit az XP képvisel, felvilágosult vezetést és megfelelő céges infrastruktúrát igényel. ► A SW-CMM csak azt mondja meg, hogy „mit” tegyen a cég, ha fejlődni akar. ► Az XP pedig azt mondja meg, hogy „hogyan” tegye meg ezt a cég. ► Összességében elmondhatjuk, hogy az XP gyakorlatai kompatibilisek a CMM gyakorlataival (céljaival, stb.) még akkor is, ha nem tudja mindet 100%-an teljesíteni.

21 Előnyök - CMM - ► Szintlépések ideje:  Második szintre: 3-tól 5 évig  Harmadik szintre: Másféltől 3 évig ► Megtakarítások:  Hughes Aircraft a második szintről a harmadikra való lépéssel évenkénti 2 millió dolláros megtakarítást ért el. (Miközben az 1987-től 1990-ig terjedő időszakban félmillió dollárt költött évenként folyamat fejlesztésre)  A Raytheon 1988-ban még első szintű volt, de mire 1993-ra elérte a harmadik szintet a termelékenysége megduplázódott, és minden befektetett dollárért 7,70 dollárt kapott vissza.

22 Előnyök - XP - ► Az XP legfőbb előnye, hogy legfeljebb 6 hónap elteltével egy használható, üzleti szempontból is értékes szoftver termékkel szolgál! ► Kis létszámú projektekre tervezett (8-9 fő) ► Az XP gyakorlatai alacsony erőforrás (anyagi, humán, hardveres) igényűek

23 Köszönjük a figyelmet!