1 / 21

(ver 1.0) 2004. április 27.

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.0) 2004. április 27. A dolgozat célja. Szándék:

clarke
Download Presentation

(ver 1.0) 2004. április 27.

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. 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.0) 2004. április 27.

  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 a Software Engineering Institute (SEI) a Mitre Corp.-nel karöltve megkezdte a munka­folyamat fejlettségi váz fejlesztését. • 1987. szeptemberében jelentette meg a SEI ennek a váznak egy rövid leírását. • Humphrey: A szoftver munkafolyamatok menedzselése (1989.) • 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.

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

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

  8. 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 Az XP (eXtreme Programming)4 alap értéke és alaptevékenysége Bátorság Egyszerűség Kommunikáció 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) • 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 Bátorság Követelmény Menedzsment [KM] Páros Programozás Visszajelzés Egyszerűség Szoftver Projekt-tervezés [SzPT] Kommunikáció Folyamatos Integrálás Tervezési Játék Szoftver Projekt-követés és -Felügyelet [SzPKF] Design XP Tesztelés Újrafaktorálás Szoftver Alvállalkozói Menedzsment [SzAM] Helyben Lévő Megrendelő Kódolás Gyakori Megjelentetés Szoftver Minőségbiztosítás [SzMB] Kódolási Normák Meghallgatás Közös Tulajdon Szoftver Konfiguráció Menedzsment [SzKM] 40 Órás Hét

  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ósforrá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. Konkluzió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. Köszönjük a figyelmet!

More Related