A SZOFTVERFEJLESZTÉSI FOLYAMAT MINŐSÉGÜGYI VIZSGÁLATA; A CMM (CAPABILITY MATURITY MODEL)

BGF KKFK Elektronikus Könyvtár Az elektronikus könyvtár teljes szövegű dokumentumokat tartalmaz biztosítva a szabad információ-hozzáférést. A szerzői és egyéb jogok a dokumentum szerzőjét/tulajdonosát illeti. Az elektronikus könyvtár dokumentumai szabadon felhasználhatók változtatások nélkül a forrásra való megfelelő hivatkozással, de csak saját célra nem kereskedelmi jellegű alkalmazásokhoz.

04.03.17

Budapesti Gazdasági Főiskola KÜLKERESKEDELMI FŐISKOLAI KAR NEMZETKÖZI MARKETING ÉS TQM SZAK Újabb diplomás, levelező tagozat Business to Business szakirány

A SZOFTVERFEJLESZTÉSI FOLYAMAT MINŐSÉGÜGYI VIZSGÁLATA; A CMM (CAPABILITY MATURITY MODEL) BEVEZETÉSE, ALKALMAZÁSA

2


04.03.17 Budapest, 2003

3

Készítette: Halász József


04.03.17

Tartalomjegyzék 1. Szoftverkrízis és szoftverminőség................................................................................... 5 2. Szoftverfolyamat-modellek............................................................................................. 9 2.1 Vízesésmodell ............................................................................................................... 9 2.2 Spirálmodell .................................................................................................................. 9 2.3 Evolúciós modell........................................................................................................... 8 3. A folyamatérettségi keret .............................................................................................. 10 3.1 Éretlen és érett szoftverszervezetek ............................................................................ 10 4. A folyamatérettség alapvető fogalmai........................................................................... 13 5. A Capability Maturity Model áttekintése...................................................................... 14 5.1 A szoftverfolyamat-érettség öt szintje......................................................................... 16 5.2 Az érettségi szintek jellemzői ..................................................................................... 17 5.3 A kezdeti szint (1) ....................................................................................................... 17 5.4 A megismételhető szint (2) ......................................................................................... 18 5.5 A definiált szint (3) ..................................................................................................... 18 5.6 A menedzselt szint (4)................................................................................................. 19 5.7 Az optimalizáló szint (5) ............................................................................................. 20 5.8 Betekintés a szoftverfolyamatba ................................................................................. 20 5.9 A folyamatképesség és a teljesítmény előrejelzése..................................................... 22 5.10 Érettségi szintek kihagyása ....................................................................................... 22 6. A CMM műszaki definíciója......................................................................................... 24 6.1 Az érettségi szintek belső szerkezete .......................................................................... 24 6.2 Az érettségi szintek ..................................................................................................... 24 6.3 Kulcsfolyamat-területek .............................................................................................. 25 6.4 A kulcs-folyamatterületek részletes céljai................................................................... 29 6.5 Általános jellemzők..................................................................................................... 32 6.6 Kulcstevékenységek .................................................................................................... 33 7. A CMM felhasználása................................................................................................... 35 7.1 A szoftverfolyamat-felmérés és a szoftverképesség-kiértékelés................................. 35 7.2 A szervezetben betöltött szerepkörök ......................................................................... 37 7.3 Szervezeti struktúra ..................................................................................................... 38 8. Külföldi tapasztalatok ................................................................................................... 39 9. Hughes Aircraft Co ....................................................................................................... 40 9.1 A Fejlesztési paradigma .............................................................................................. 40 9.2 A folyamat eredményességének bizonyítékai ............................................................. 40 9.3 A CSWP vállalati-szintű alkalmazása......................................................................... 42 9.4 A fejlesztési tervek folytatása ..................................................................................... 43 9.5 Pozitív hatások ............................................................................................................ 43 9.6 A vállalat leírása.......................................................................................................... 43 9.7 A Hughes szoftverfolyamatának fejlesztése ............................................................... 44 9.8 A megrendelők elégedettsége...................................................................................... 46 9.9 Innovációk................................................................................................................... 47 10. Az ötödik szint elérése - ALC ..................................................................................... 49 10.1 Felkészülés a felmérésre............................................................................................ 50

4


04.03.17 10.2 A felméréssel kapcsolatos problémák – külső nézőpontból...................................... 51 10.3 Felkészülés a felmérésre – belső nézőpontból .......................................................... 52 10.4 A helyszíni (on-site) vizsgálat................................................................................... 53 10.5 A Szoftverprojekt-tervezés........................................................................................ 54 10.6 A termék- és folyamat-szoftverminőség biztosítása ................................................. 55 10.7 Szervezeti folyamatközpontúság – Folyamatfejlesztés............................................. 55 10.8 Képzések ................................................................................................................... 56 10.9 Kvantitatív folyamatmenedzsment............................................................................ 57 10.10 A felmérés eredménye............................................................................................. 58 11. A hazai alkalmazás kérdésköre ................................................................................... 59 12. A Képesség-Érettség Modell bírálata.......................................................................... 60 13. Összefoglalás............................................................................................................... 61 Irodalomjegyzék................................................................................................................ 64 Melléklet............................................................................................................................ 66

5


04.03.17

1. Szoftverkrízis és szoftverminőség A modernizáció és a globalizáció erősödésével egyre növekszik azon feladatok száma, amelyeknek elvégzését szoftverekre bízzuk, a szoftver mára tömegtermékké vált. [Tóth (1999):p.361] A nagy programrendszerek olykor több millió soros forráskódot jelentenek, s minél nagyobb egy rendszer, annál több potenciális hibalehetőséget (és hibát) tartalmaz. A magas fejlesztési költségek mellett sokszor kevés a realizálható eredmény. A méretek növekedésével a megbízhatóság rohamosan csökken; a bonyolultabb rendszerek hordozhatósága általában kisebb, karbantartási költsége azonban lényegesen nagyobb (az elkészült rendszerek nehezen módosíthatók, rugalmatlanok). Az összetett rendszerek dokumentációja a „tűzoltás” jellegű szoftverfejlesztés miatt felületes és pontatlan. A gyakorlat bebizonyította,

hogy

bonyolult,

sok

ember

összehangolt

munkáját

igénylő

szoftverrendszereket nem lehet közvetlen kódolással kifejleszteni. [Vég (1999):p.7] A komplexitás növekedése miatt a nagy szoftverrendszerek tervezésének és kivitelezésének koordinálása sokszor megoldhatatlannak tűnő feladat. A fejlesztési idő legtöbbször meghaladja a tervezettet, ugyanakkor a felhasználói követelmények gyakran kielégítetlenül maradnak, felhasználóbarát programokról csak kivételes esetekben beszélhetünk. A fentiek tükrében a szoftverfejlesztés gazdaságossága olykor megkérdőjelezhető. A minőségi szoftverkészítési folyamat (szoftverfolyamat) előtérbe kerülése az 1980-as évek közepére tehető [Tóth (1999):p.362]; az évtized végéig azonban csak rendkívül kevés szakember foglalkozott ezzel a kérdéskörrel. A szoftverfolyamat jelentőségét az indokolja, hogy a termék minőségét nagymértékben meghatározza az előállítására szolgáló folyamat. A termékek tulajdonságainak ellenőrzése és javítása a folyamat ellenőrzésén és javításán keresztül valósítható meg. A minőségi szoftver előállításához a elsősorban a fentebb említett problémákat kell orvosolni. A minőségi szoftver kritériumai [Angster (1999):p.3] röviden a következők:

6


04.03.17 - helyesség: a helyes szoftver pontosan a specifikációjában előírt feladatot látja el; ez elsődleges minőségi követelmény. -

hibatűrés: a hibatűrő szoftver abnormális rendszerkörülmények között is (a lehetőségekhez képest) normálisan, definiáltan működik.

-

karbantarthatóság, bővíthetőség: egy szoftver karbantartható, ha az könnyen javítható, módosítható; egy szoftver bővíthető, ha az újabb felhasználói igények könnyen teljesíthetők.

-

újrafelhasználhatóság: az újrafelhasználható szoftver meghatározott részei (vagy maga a szoftver) újabb szoftverekben hasznosítható.

-

kompatibilitás: egy adott szoftver egy másik szoftverrel kompatibilis, ha azok könnyedén összeépíthetők.

-

felhasználóbarátság: egy szoftver felhasználóbarát, ha felhasználói felületének megjelenése kellemes, használata egyértelmű, logikus.

-

hordozhatóság: egy szoftvert hordozhatónak nevezünk, ha az könnyedén átvihető más hardver- illetve szoftverkörnyezetbe.

-

hatékonyság: egy szoftver hatékony, ha a rendelkezésére álló hardver- és szoftvererőforrásokat maximálisan kihasználja (idő- és memória-igénybevétel csökkentése).

-

ellenőrizhetőség: egy szoftver ellenőrizhető, ha a tesztelési adatok és eljárások könnyedén összeállíthatók.

-

integritás: egy szoftver integritásáról akkor beszélünk, ha a különböző rendszerhibák nem okoznak helyreállíthatatlan hibákat.

7


04.03.17 - szabványosság: egy szoftver szabványos, ha az működésében, megjelenésében és dokumentálásában megfelel a szabványnak. A szoftvertermék minőségének megítélése az információtechnológia egyik alapkérdése. Az ISO/IEC 9126 szabvány meghatároz egy hierarchikus szempontrendszert, amelynek első szintje a következő elemeket tartalmazza [Tóth (1999):p.364]: -

funkcionalitás: működési funkciókkal és azok meghatározott tulajdonságaival összefüggő attribútumok halmaza. A működési funkciók megadott vagy értelemszerű igényeket elégítenek ki

-

megbízhatóság: a szoftver azon attribútumainak halmaza, amelyek utalnak a szoftver adott feltételek mellett, adott időtartamon keresztül fenntartható, rendeltetésének megfelelő működési szintjére

-

használhatóság: a szoftver használatához szükséges erőfeszítésekkel, valamint a megadott vagy értelemszerűen számba vehető felhasználók egyéni megítélésével kapcsolatos attribútumok halmaza

-

hatékonyság: a szoftver teljesítményszintje és a felhasznált erőforrások mennyisége közötti kapcsolatra vonatkozó attribútumok halmaza, az erőforrások közé értve minden más szoftverterméket, hardvert stb.

-

karbantarthatóság: a módosításokhoz szükséges erőfeszítéseket jellemző attribútumok halmaza; ide tartozik a hibajavítás, továbbfejlesztés, a szoftver környezeti változtatásokhoz és változó követelményekhez történő igazítása

-

hordozhatóság: a szoftvernek egyik (szervezeti, hardver-, szoftver-) környezetből a másikba átviteli lehetőségével kapcsolatos attribútumok halmaza

Az ISO 9000 szabványsorozat a „képes-e a szállítószervezet a termékét úgy előállítani, hogy az nagy megbízhatósággal megfeleljen a követelményeknek” kérdésre válaszul a hangsúlyt a 8


04.03.17 termék helyett a folyamatra helyezi [Tóth (1999)]. A szoftverfolyamatra általánosan az ISO 9001 szabvány alkalmazható, amelyet kiegészít a konkrétan szoftverfejlesztésre vonatkozó ISO 9000-3 útmutató. A szoftverfolyamat-felmérési módszertanok és az azok eredményeként előálló akciótervek az ISO 9000-es szabványsorozatnál jobban támogatják a folyamatok javítását, több segítséget nyújtanak a minőségjavítási prioritások meghatározásához.

9


04.03.17

2. Szoftverfolyamat-modellek Nagyon sok szoftverfejlesztő vállalatnál még ma is a „szoftverfejlesztés” kezdetén használt két lépcsős lépéssort alkalmazzák, iterációról-iterációra (amennyiben ezeket az eseteket valódi iterációnak lehet nevezni): kódolás, majd hibajavítás. Mivel a tervezési tevékenység minimális, illetve teljesen elmarad, így a megírt programkód strukturálatlan, áttekinthetetlen lesz. A rendkívüli nehézségeket okozó hibajavítási tevékenység maga is jelentős hibaforrást jelent.

2.1 Vízesésmodell Ma a könnyen megérthető és alkalmazható vízesésmodell tekinthető a legelterjedtebbnek, mellyel kapcsolatban már sok tapasztalat halmozódott fel. A vízesésmodellnek a használat során sok változata alakult ki; visszacsatolást is lehetővé tevő főbb lépései általában a következők: követelményanalízis, tervezés, programozás, tesztelés, követés.

2.2 Spirálmodell A spirálmodell alkalmazását Boehm javasolta 1988-ban [Boehm (1988)], mely nagy figyelmet fordít a kockázatokra és költségproblémákra, továbbá kihangsúlyozza a prototípusépítés

fontosságát.

A

modell

lényeges

tulajdonsága,

hogy

a

minden

ciklust

érvényességvizsgálati és ellenőrzési szemle követ. Ciklusonként készül prototípus a rendszer bemutatásának lehetővé tétele és a hibák korai kiküszöbölése érdekében. [Tóth (1999)]

2.3 Evolúciós modell Az evolúciós modell előtérbe helyezi a használhatóságot, a felhasználó-orientáltságot és a karbantarthatóságot is; korai és gyakori iterációkat, minden lépésben teljes elemzést, tervezést, kódolást és tesztet javasol. A programozás mellett kihangsúlyozza a

10


04.03.17 rendszerszempontú

megközelítést,

az

adaptálható

és

változtatástűrő

rendszerek

kifejlesztésének szükségességét, továbbá az eredményorientáltságot. [Tóth (1999):p.368]

3. A folyamatérettségi keret Az új szoftver-módszertanok és technológiák alkalmazásából adódó produktivitásnövekedésről és minőségjavulásról szóló betartatlan ígéretek évtizedei után a szoftveripar és az Amerikai Egyesült Államok kormányzata ráébredt arra, hogy a legalapvetőbb probléma a szoftverfolyamat menedzselési képességének hiánya. A fejlett módszerek és eszközök előnyeit, fegyelmezetlen szervezésű projektek esetén nem lehet megfelelően kihasználni. Sok szervezet projektjei jelentős késést szenvednek, és eredeti költségvetésüket többszörösen túllépik. [Siegel (1990)] Ezekben az esetekben a szervezet többnyire nem biztosította a projektek számára a fenti problémák elkerüléséhez szükséges infrastruktúrát és támogatást. Néhány szoftverprojekt azonban még a fenti jellemzőkkel rendelkező szervezeti keretek között is kiváló eredményekkel végződik. Amikor egy ilyen projekt sikerrel végződik az általában nem egy érett szoftverfolyamattal rendelkező szervezet kipróbált módszerei ismételt felhasználásának, hanem egy elkötelezett csapat komoly erőfeszítéseinek köszönhető. Az egész szervezetre kiterjedő szoftverfolyamat hiányában az eredmények megismétlésének képessége jelentős részben azon múlik, hogy ugyanazok a meghatározó személyek vesznek-e részt a következő projektben is. Bizonyos személyek elérhetőségétől függő siker nem biztosít megfelelő alapot a szervezet számára a hosszú távú termelékenység-növeléshez és minőségjavuláshoz.

Folyamatos

menedzsment-tevékenységek

felé

fejlődés

csak

irányuló

a

hatékony

koncentrált

és

szoftvertechnológiai kitartó

és

erőfeszítések

következményeként jöhet létre. [Paulk (1993)] Megbízható és jól használható szoftverek fejlesztése meghatározott idő- és költségkereten belül számos szervezet számára teljesíthetetlen feladat. A későn átadott, költségvetést túllépő, nem megfelelően működő szoftvertermékek a megrendelőnek is problémát jelentenek. A szoftverprojektek méretének és fontosságának növekedésével ezek a problémák még 11


04.03.17 súlyosabbakká válnak, amelyek a hatékony szoftvertechnológiai és menedzsmenttevékenységek folyamat-infrastruktúrájának kiépítésére irányuló koncentrált és hosszan tartó erőfeszítések eredményeként küszöbölhetők ki. Ennek a folyamat-infrastruktúrának a kiépítéséhez a szoftverszervezeteknek tudniuk kell, hogyan mérhetik fel szoftverfolyamatuk sikeres végigviteléhez szükséges képességeiket. Ehhez hasonlóan, folyamatképességük fejlesztéséhez is útmutatásra van szükségük. A megrendelőknek is tudniuk kell, hogyan mérhetik fel hatékonyan leendő szerződéses feleik szoftvertechnológiai képességeit.

3.1 Éretlen és érett szoftverszervezetek Komoly

folyamatfejlesztési

célok

kitűzéséhez

szükséges

az

érett

és

az

éretlen

szoftverszervezetek közötti különbség megértése. Éretlen szervezet esetén többnyire a menedzsment és a fejlesztők „improvizálják” a projektek folyamán a szoftverfolyamatokat. Ha létezik is meghatározott szoftverfolyamat, azt nem követik, illetve nincs kényszerítő erő a követésére. Az alapvetően csak reagáló jellegű (vagyis éretlen) szoftverszervezetekben a menedzserek az éppen aktuális krízishelyzet megoldására koncentrálnak („tűzoltás”). Az ütemtervet nem képesek tartani és a költségvetést is rendszeresen túllépik, hiszen ezek nem valós becsléseken alapszanak. Nehezen betartható határidők esetén kényszerkompromisszumokat kell kötniük a szoftver funkcionalitásával és minőségével kapcsolatban. Egy éretlen szervezetben nincs objektív alap a termék minőségének megítélésére, illetve a termékkel és a folyamatokkal összefüggő problémák megoldására, így a termék minősége nehezen előrejelezhető. Ha a projekt elmarad az ütemtervtől, a minőséget javító tevékenységek (review, tesztelés) háttérbe szorulnak vagy teljesen eltűnnek. Egy érett szoftverszervezet azonban rendelkezik (az egész szervezetre kiterjedően) a szoftverfejlesztési és karbantartási folyamatok menedzselési képességével. A régebbi és az újabb munkatársak is pontosan értik a szoftverfolyamatot, és a munkát a tervezett folyamatok

12


04.03.17 alapján végzik, a folyamatok a munkavégzés módjával konzisztensek. Amikor szükséges, ezeket a definiált folyamatokat felülvizsgálják, és a változtatásokat próbatesztek és költséghaszon elemzések után vezetik be. A szerepek és a felelősségi körök az adott folyamatra vonatkozóan a projekt és a szervezet szintjén is egyértelműen meghatározottak. Egy érett szervezetben a menedzserek megvizsgálják a szoftvertermékek minőségét és az ügyfelek elégedettségét; létezik objektív, mennyiségi alap a termék minőségének megítéléséhez, valamint a termékkel és a folyamattal kapcsolatos problémák elemzéséhez. Az ütemtervek és a költségvetések reálisak és a korábbi projektek eredményein alapszanak, a meghatározott költségkeretek és határidők betarthatóak, az elvárt funkcionalitás és minőség elérhető. Minden munkatárs tisztában van a folyamat követésének előnyeivel és fontosságával; a folyamat számára szükséges infrastruktúra és támogatás rendelkezésre áll. Az érett és éretlen szoftverszervezetekkel kapcsolatos megfigyelések alapján kialakítható egy szoftverfolyamat-érettségi keret. Ez a keret megjelenít egy evolúciós jellegű utat az „ad hoc” folyamatoktól az érett szoftverfolyamatokig. E keret nélkül nincs szükséges támogató alapja a fejlesztési lépéseknek, s emiatt általában nem bizonyulnak hatásosnak. A

szoftverfolyamat-érettségi

szoftverfolyamat,

keret

a

következő

szoftverfolyamat-képesség,

szoftverfolyamat-érettség.

13

fogalmak

segítségével

épül

fel:

szoftverfolyamat-teljesítmény,


04.03.17

4. A folyamatérettség alapvető fogalmai Szoftverfolyamat: a szoftver és a hozzátartozó termékek (tervek, kód, dokumentáció, stb.) fejlesztésére és karbantartására szolgáló tevékenységek, módszerek és transzformációk összessége. Ahogyan egy szervezet egyre érettebbé válik a szoftverfolyamat is egyre pontosabban definiálttá és következetesebben megvalósítottá válik. Szoftverfolyamat-képesség:

leírja

azokat

az

elvárt

eredményeket,

amelyek

a

szoftverfolyamat követésével érhetőek el. A szoftverfolyamat-képesség egy eszközt biztosít a szervezet következő szoftverprojektje legvalószínűbb kimenetének előrejelzéséhez. Szoftverfolyamat-teljesítmény:

az

aktuális

eredményeket

jelenti,

melyeket

a

szoftverfolyamat követésével értek el. A szoftverfolyamat-teljesítmény tehát az elért eredményekre koncentrál, míg a szoftverfolyamat-képesség az elvártakra. Szoftverfolyamat-érettség: az érettség a képességnövekedési lehetőségeket foglalja magába, továbbá jelzi a szervezet szoftverfolyamatának jellemzőit és azt a következetességet, amellyel a szoftverfolyamatot a szervezet projektjeiben alkalmazzák. Egy érett szervezet munkatársai értik a szoftverfolyamat lényegét (ezt dokumentációk és képzések is segítik), folyamatosan figyelik és fejlesztik azt. A szoftverfolyamat érettsége azt jelenti, hogy a szervezet szoftverfolyamatából eredő produktivitás és minőség jobbá tehető. Ahogyan egy szervezet érettebbé válik, irányelvek, szabványok és szervezeti struktúrák segítségével

intézményesíti szoftverfolyamatát.

Az

intézményesítés

a

módszereket,

tevékenységeket és eljárásokat hosszútávon támogató infrastruktúra és vállalati kultúra felépítését jelenti.

14


04.03.17

5. A Capability Maturity Model áttekintése Bár a szoftverfejlesztők és a menedzserek gyakran igen részletesen ismerik problémáikat, mégis sokszor nem értenek egyet abban, hogy mely tevékenységek, fejlesztések a legfontosabbak. Szervezett fejlesztési stratégia nélkül nehéz a menedzsment és a programozók között konszenzust teremteni a fontossági sorrenddel kapcsolatban. A folyamatfejlesztési erőfeszítésekből származó hosszútávú eredmények elérése érdekében szükséges egy olyan evolúciós jellegű fejlődési út megtervezése, amely a szervezet szoftverfolyamatának érettségét növeli. A szoftverfolyamat-érettségi keret [Humphrey (1987)] az érettségi szinteket úgy szervezi, hogy minden szinten a fejlesztések a következő szint fejlesztéseinek alapját képezik. Ily módon, a szoftverfolyamat érettségi keretéből származó fejlesztési stratégia egyfajta „térképet” biztosít a folyamatos fejlesztés számára; segít az előrelépésben és azonosítja a szervezet hiányosságait. A Capability Maturity Model (Képesség-Érettség Modell) a szoftverszervezetek számára útmutatást biztosít a szoftverfejlesztési és karbantartási folyamataik feletti ellenőrzéshez, továbbá a szoftvertechnológiai és a menedzsmentbeli kiválóság megteremtéséhez. A modellt azért hozták létre, hogy segítsen a szoftverszervezeteknek folyamatfejlesztési stratégiájuk kialakításában, a jelenlegi folyamatérettség meghatározásával, továbbá a szoftverminőségre és a folyamatfejlesztésre nézve kritikus tényezők azonosításával. Kevés számú tevékenységre koncentrálva a szervezet folyamatosan képes szoftverfolyamatát fejleszteni, és így komoly hosszútávú eredményeket érhet el a szoftverfolyamat-képesség területén. A CMM kerete meghatározza a hatékony szoftverfolyamat kulcsfontosságú elemeit. A CMM kulcstevékenységei hozzájárulnak ahhoz, hogy a szervezet a tervezés, a fejlesztés és a karbantartás során elérje a költségekre, ütemezésre, funkcionalitásra és minőségre vonatkozó céljait. A kulcstevékenységek meghatározásának célja azonban nem egy adott szoftver-életciklus modell, egy adott szervezeti struktúra, egy adott technológiai vagy menedzsment-

15


04.03.17 megközelítés támogatása, hanem a hatékony szoftverfolyamat nélkülözhetetlen elemeinek leírása. A kulcstevékenységek olyan alapelveket határoznak meg, amelyek szoftverek, projektek, és szervezetek széles körére alkalmazhatóak, és feltehetően időtállónak bizonyulnak. Ez a megközelítés tehát az alapelvek konkrét megvalósítását a szervezetekre, azok menedzsereire és szoftverfejlesztőire hagyja. A CMM kulcstevékenységei általános elveket rögzítenek, nem feltételeznek adott szoftverfejlesztési technológiákat, mint pld: prototype készítés, objektum-orientált tervezés, szoftverelemek újrahasznosítása stb. Hasonlóan viszonyul a CMM a szervezeti struktúrákhoz és a szervezetben betöltött szerepkörökhöz: amennyire lehetséges, megkísérel független maradni, ugyanakkor a kulcstevékenységek leírásához és példák biztosításához természetesen szükséges a fentiek terminológiájának meghatározása. A CMM szintstruktúrája a termékminőség évtizedek alatt lerakott alapjain nyugszik. Walter Shewart a minőség statisztikai megközelítésével kapcsolatos munkáját W. Edwards Deming és Joseph Juran fejlesztette tovább. [Deming (1986)] [Juran (1988), Juran (1989)] Ezeket az irányelveket a CMM a folytonos folyamatfejlesztés alapját jelentő mennyiségi ellenőrzés érdekében az érettségi keretbe integrálta. Philip Crosby „Quality is Free” című könyvében [Crosby (1979)] a minőségügyi tevékenységek alapján öt érettségi szintet különböztet meg. Ezt az érettségi keretet Ron Radice és munkatársai (IBM) alkalmazták először a szoftverfolyamatokra. [Radice (1985)] A Carnegie Mellon Egyetem Szoftvertechnológiai intézetébe Watts Humphrey vitte magával az érettségi keret koncepcióját, majd ott éveken át fejlesztette, finomította a modellt. A CMM mindmáig meghatározó szerepet játszik a szoftverfolyamat-felmérés és –fejlesztés területén. Az Humphrey és munkatársai munkájának eredménye a 18 kulcs-folyamatterületet öt érettségi

szintre

felosztó

modell.

A

kulcs-folyamatterületek 16

az

őket

alkotó


04.03.17 kulcstevékenységekkel jó megközelítést adnak a teljes szoftverfolyamat lefedéséhez. A megközelítés Crosby munkájával ellentétben nem a kulcs-folyamatterületek érettségét, hanem az egész szervezet szoftverkészítési érettségét méri. Ennek eredményeképpen kielégítő választ lehet adni a folyamatjavítás lehetséges irányai közötti prioritásokra vonatkozó döntési problémákra. [Tóth (1999):p.369]

5.1 A szoftverfolyamat-érettség öt szintje A folytonos folyamatfejlesztés a legtöbb esetben nem forradalmi újításokból áll, hanem apróbb lépések sorozata. A CMM keretet biztosít ezeknek a lépéseknek öt érettségi szintbe történő szervezéséhez, amelyek a fokozatos folyamatfejlesztés alapjait jelentik. Ez az öt érettségi szint meghatároz egy skálát, a szervezet szoftverfolyamatának méréséhez és a szoftverfolyamat-képességének felméréséhez, továbbá segítséget nyújt a szervezet fejlesztési erőfeszítései sorrendiségének meghatározásához. Az adott érettségi szint egy jól definiált kiindulópont az érett szoftverfolyamat eléréséhez. Minden érettségi szint egy réteget képez a folytonos folyamatfejlesztés alapjában. Minden szint olyan folyamatcélok összességét jeleníti meg, melyeket elérve a szoftverfolyamat egyegy lényeges eleme stabilizálódik, és ily módon a szervezet folyamatképessége javul. Az érettségi szintek következő leírása rávilágít az egyes szinteken történő legfontosabb folyamatváltozásokra. Kezdeti: A szoftverfolyamat „ad hoc” jelzővel illethető, olykor káoszra emlékeztet. Kevés a definiált folyamat és a siker az egyéni erőfeszítések következménye. Ismételhető: Léteznek alapvető menedzsmentfolyamatok a költségek, az ütemterv és a funkcionalitás követésére, továbbá folyamatfegyelem a korábbi hasonló projektek sikereinek megismétlésére. Definiált: A szoftverfolyamat a technikai és a menedzsment tevékenységekre vonatkozóan dokumentált, szabványosított, és a szervezet szoftverfolyamatába integrált. A szoftver

17


04.03.17 fejlesztéséhez

és

karbantartásához

minden

projekt

a

szervezet

szabványos

szoftverfolyamatának testreszabott változatát alkalmazza. Menedzselt: A szoftverfolyamat méréséhez és a szoftver minőségének megítéléséhez részletes adatok állnak rendelkezésre. A szoftverfolyamat és a szoftvertermékek mennyiségi mérőszámokkal ellenőrzöttek. Optimalizáló: A folyamat kvantitatív visszacsatolása és innovatív ötletek, technológiák segítségével a folytonos folyamatfejlesztés megvalósítható.

5.2 Az érettségi szintek jellemzői Az érettségi szintek (másodiktól az ötödikig) a következő szempontokkal jellemezhetők: -

a szervezet által a szoftverfolyamat alapjainak lerakása, illetve fejlesztése érdekében végrehajtott tevékenységek

-

az egyes projekteken végrehajtott tevékenységek

-

projektek folyamatképessége

5.3 A kezdeti szint (1) Kezdeti (initial) szinten a szervezet általában nem teremt megfelelő környezetet a szoftver fejlesztése és karbantartása számára. Megfelelő menedzsment-tevékenységek nélkül a szoftvertechnológiai tevékenységek színvonalának előnyei nem használhatók ki teljeskörűen, mivel a tervezés nem hatékony és a menedzsment-rendszerek csak reagáló jellegűek. Az ezen a szinten elhelyezkedő projektek krízishelyzetben általában elhagyják a tervezési eljárásokat, és csupán a kódolásra és a tesztelésre hagyatkoznak. A siker gyakorlatilag teljes mértékben egy kivételes képességű menedzseren és egy hatékony szoftverfejlesztő csapaton múlik. Amikor a meghatározó jelentőségű szerepet betöltő menedzser elhagyja a projektet, akkor rendszerint elkötelezett személyiségének motiváló hatása is vele együtt távozik. A

18


04.03.17 szervezett menedzsment-tevékenységek hiányát a legjobb technikai megoldások sem tudják pótolni. Az első szinten lévő szervezetek szoftverfolyamat-képessége meghatározhatatlan, mivel a projekt előrehaladásával a szoftverfolyamat igen gyakran változik (azaz „ad hoc” jellegű). Az ütemtervek, a költségvetések, a funkcionalitás és a termékminőség előrejelezhetetlen. A teljesítmény az egyéni képességektől, tudástól és motivációtól függ.

5.4 A megismételhető szint (2) A megismételhető (repeatable) szinten léteznek irányelvek a szoftverprojekt menedzselésére, továbbá léteznek eljárások ezeknek az irányelveknek a megvalósítására. Új projektek tervezése és menedzselése régebbi, hasonló projektek tapasztalatai alapján történik. A kettes szint elérésének célja a szoftverprojektek olyan hatékony menedzsmentfolyamatainak intézményesítése, amelyek (az egyes projektspecifikus folyamatok különbözősége ellenére) korábbi projektek sikeres tevékenységeinek „újrahasznosítását” lehetővé teszik. A szoftverrel kapcsolatos követelmények meghatározottak, az elvárások teljesítésével kapcsolatos problémákat előfordulásukkor azonosítják. A szoftverprojekt szabványos eljárásai definiáltak, és a szervezet felügyelete mellett követik őket. Az erős eladó-vevő kapcsolat érdekében a szoftverprojekt a szerződéses felekkel szoros együttműködésben dolgozik. A

CMM

megismételhető

szintjén

lévő

szervezetek

szoftverfolyamat-képessége

a

„fegyelmezett” kifejezéssel jellemezhető, mivel a szoftverprojekt tervezése és követése stabil alapokon nyugszik és a korábbi siker megismételhető. A projekt szoftverfolyamata a menedzsment hatékony ellenőrzése alatt áll.

5.5 A definiált szint (3) A definiált (defined) szinten a szervezet szabványos szoftverfejlesztési és karbantartási folyamata

dokumentált,

beleértve

mind 19

a

szoftvertechnológiai,

mind


04.03.17 menedzsmentfolyamatokat, és ezek a folyamatok koherens egészet alkotnak. Ezt a szabványos folyamatot a CMM a szervezet szabványos szoftverfolyamatának nevezi. A harmadik szint folyamatai segítenek a menedzsereknek és a szoftverfejlesztőknek a teljesítmények még hatékonyabb elérésében. A szoftvertechnológiai folyamatcsoport (software engineering process group, SEPG) felelős a szervezet szoftverfolyamattal kapcsolatos tevékenységeiért. [Fowler (1990)] A teljes szervezetre kiterjedő képzési program biztosítja, hogy a menedzserek és a szoftverfejlesztők egyaránt birtokában legyenek azoknak a képességeknek és tudásnak, melyek feladataik elvégzéséhez szükségesek. A projektek a szervezet szabványos szoftverfolyamatát saját jellemzőik alapján testreszabják. Ezt a folyamatot a CMM a projekt definiált szoftverfolyamatának nevezi, amely tartalmazza a készenléti

feltételeket,

bemeneteket,

szabványokat,

eljárásokat,

verifikációs

mechanizmusokat, kimeneteket és befejezési feltételeket. Mivel a szoftverfolyamat jól definiált, a menedzsment minden projekt előrehaladását megfelelően vizsgálni tudja. A harmadik szinten a szervezetek szoftverfolyamat-képessége a „szabványos” és „konzisztens” szavakkal jellemezhető, mivel a szoftvertechnológiai és menedzsmenttevékenységek biztos alapokon nyugszanak és megismételhetőek. A folyamatképesség a tevékenységek, szerep- és felelősségi körök a szervezet egészére kiterjedő megértésén alapszik.

5.6 A menedzselt szint (4) A menedzselt (managed) szinten a szervezet kvantitatív minőségi célokat határoz meg a szoftverfolyamatokkal és a szoftvertermékekkel kapcsolatban. Az egész szervezetre kiterjedő mérési program részeként minden projekt fontos szoftverfolyamat-aktivitásai mérésre kerülnek a termelékenység és a minőség szempontjából. A szervezet szoftverfolyamatadatbázist épít a projektek definiált szoftverfolyamatai adatainak összegyűjtése és elemzése

20


04.03.17 érdekében. A mérések kvantitatív alapot jelentenek a projektek szoftverfolyamatainak és szoftvertermékeinek kiértékeléséhez. A projektek folyamatteljesítményük jellemzőinek meghatározott mennyiségi korlátok közé szorításával ellenőrzést nyernek termékeik és folyamataik felett. A teljesítményjellemzők jelentéssel bíró változásai megkülönböztethetőek a véletlenszerű változásoktól. Az új alkalmazási területekkel kapcsolatos tanulási folyamat kockázatai ismertek és kezelhetőek. A negyedik szinten a szervezet szoftverfolyamat-képessége az „előrejelezhető” kifejezéssel jellemezhető, mivel a folyamat mérhető és meghatározott keretek közé szorítható. Ezen a szinten a folyamatképesség lehetővé teszi a szervezetek számára a folyamattal és a termék minőségével kapcsolatos trendek előrejelzését. A kvantitatív határok túllépése esetén a megfelelő intézkedések megtehetőek.

5.7 Az optimalizáló szint (5) Az optimalizáló (optimizing) szinten a teljes szervezet a folytonos folyamatfejlesztésre koncentrál. A szervezet a hibák előfordulásának megakadályozása érdekében alkalmazza rendelkezésre álló eszközeit a folyamat gyengeségeinek és erősségeinek azonosítására. A szoftverfolyamat hatékonyságával kapcsolatos adatok a bevezetendő új technológiák és változtatások költség-haszon elemzésének elősegítését szolgálják. A szoftvertechnológiai innovációk elterjednek a szervezetben. Az ötödik szinten lévő szervezetekben a teamek elemzik a hibákat a bekövetkezési okok meghatározása érdekében. A szoftverfolyamat értékelésével megakadályozzák az ismert hibatípusok ismételt előfordulását, a tapasztalatokat átadják a szervezet többi projektjének is. Az ötödik szinten lévő szervezetek szoftverfolyamat-képessége a „folytonosan fejlődő” kifejezéssel jellemezhető, ami egyrészt lépésről-lépésre történő fejlesztéssel, másrészt új technológiák és módszerek innovációjával történik.

21


04.03.17 A CMM egy leíró modell: meghatározza az adott érettségi szinten lévő szervezettel szemben támasztott alapvető elvárásokat. A CMM azonban nem előíró modell: nem határozza meg a szervezet számára, hogyan fejlődjön. A szoftverfolyamat fejlesztését a szervezet stratégiai terveinek és üzleti céljainak, a szervezeti felépítésnek, a használt technológiának stb. megfelelően kell megtervezni és kivitelezni.

5.8 Betekintés a szoftverfolyamatba A szoftvermérnökök „első kézből” származó információik révén részletes betekintést nyernek a projekt állapotába. Nagyobb projekt esetén azonban mindez saját felelősségi körükön belüli személyes tapasztalataikra korlátozódik. A szenior menedzsereknek nincs hasonló részletességű betekintésük a projekt folyamataiba, az időközönként végrehajtott review tevékenységekre hagyatkozva jutnak a projekt előrehaladása követéséhez szükséges információkhoz. A projekt állapotának és teljesítményének megfigyelését lehetővé tévő betekintési szint érettségi szintenként változik. Az első (kezdeti) szinten a szoftverfolyamat egy fekete doboz, amelybe meglehetősen korlátozott a betekintés. Mivel a tevékenységek állapota nem egyértelműen meghatározható, így a projekt előrehaladásának állapota is nehezen felmérhető. A követelmények átültetésének módja a szoftverfolyamatba nem ellenőrzött. A második (megismételhető) szinten léteznek alapvető menedzsment eszközök az elvárások és az elkészülő szoftvertermék összhangjának megteremtésére, amelyek meghatározott pontokon (mérföldkövek) betekintést engednek a szoftverfolyamatba, amely fekete dobozok sorozataként fogható fel. Bár a menedzsment nem lát bele az egyes fekete dobozokba, de az ellenőrzőpontokon képes megvizsgálni a projekt állapotát, s problémák felbukkanása esetén megfelelően reagálni. A harmadik (definiált) szinten a dobozok belső szerkezete is láthatóvá válik. A belső szerkezet a szervezet szabványos szoftverfolyamata alkalmazásának módját reprezentálja,

22


04.03.17 vagyis ahogyan az a projektben megjelenik. A menedzsment felkészül az esetleg fellépő kockázatokra. A projektről gyors és pontos állapotjelentések készíthetők. A negyedik (menedzselt) szinten a szoftverfolyamatok ellenőrzése kvantitatív, a menedzsment képes az előrehaladás mérésére, s ennek alapján hozza döntéseit. A kimenetek előrejelzése pontosabbá válik. Az ötödik (optimalizáló) szinten a szervezet folyamatosan próbál ki új módszereket a termelékenység és a minőség szintjének emelése érdekében. A nem hatékony tevékenységeket a szervezet felülvizsgálja

és ellenőrzött módon helyettesíti. A menedzsment képes a

változtatások hatásának és hatékonyságának előzetes felmérésére, majd kvantitatív vizsgálatára.

23


04.03.17

5.9 A folyamatképesség és a teljesítmény előrejelzése A szervezet szoftverfolyamatának érettsége segít a projektek célelérési képességének felmérésében, előrejelzésében. Az első szinten lévő szervezetek többnyire jelentősen eltérnek a költségekkel, ütemtervvel, funkcionalitással és minőséggel kapcsolatos céljaiktól. Az érettségi szint növekedésével a projektek kitűzött és elért céljai közötti eltérés csökken, az átadási határidők pontosabban betarthatóvá válnak. Az ötödik szinten a határidők kitűzése a szoftverfolyamat-teljesítmény paramétereinek pontos ismeretén alapszik. Az első szinten elhelyezkedő szervezetek esetében a szoftverfejlesztéshez szükséges idő a hibák felmérése és kijavításukhoz szükséges átdolgozás (újraírás) miatt igen hosszú lehet. A szoftverfejlesztési idő lerövidítése és a szoftverfolyamat hatékonysága érdekében az ötödik szinten lévő szervezetek folytonos folyamatfejlesztést és hibamegelőző technikákat alkalmaznak.

A

hibák

teljesítményéhez.

Érett

korai

felfedezése

szoftverfolyamat

hozzájárul esetén

a a

projekt

stabilitásához

és

kockázatmenedzsment

a

projektmenedzsment szerves része. A szervezet érett szoftverfolyamatának köszönhetően a kilátástalan projektek a szoftver-életciklus korai szakaszában azonosíthatóak.

5.10 Érettségi szintek kihagyása A CMM érettségi rendszerében minden köztes szint a következő szint(ek) folyamatainak alapját teremti meg. Egy adott szinten elhelyezkedő szervezet természetesen felsőbb szintek tevékenységeit is megvalósít(hat)ja. A követelményanalízis, a tervezés, a kódolás és a tesztelés témakörét a CMM a harmadik szintig nem érinti, de természetesen egy első szinten elhelyezkedő szervezetnek is szüksége van minderre. Ezek a folyamatok azonban nem tudnak teljes hatásfokkal működni megfelelően lerakott alapok nélkül. A CMM meghatározza a szervezet számára azokat az érettségi szinteket, melyek segítségével megteremtheti a szoftvertechnológiai kiválóság kultúráját.

24


04.03.17 Néhány magasabb szintű folyamat megvalósításának képessége nem jelenti az adott magasabb szintek átléphetőségét. Megfelelő alapok nélkül a folyamatok nem teremthetnek lehetőséget a továbbfejlődésre.

25


04.03.17

6. A CMM műszaki definíciója A CMM kerete a szoftverfolyamat-képesség növelése érdekében határoz meg egy fejlődési utat a szoftverszervezetek számára. A modellnek legalább négyféle felhasználási lehetősége ismert: -

a felmérő teamek a szervezet erősségeinek és gyengeségeinek azonosítására használják

-

a kiértékelő teamek a szerződésre kész lehetséges partnerek közötti szelekcióra használják

-

a menedzserek és a szoftverfejlesztők a szoftverfolyamat-fejlesztési program tervezéséhez és megvalósításához szükséges tevékenységek meghatározásához használják

-

a folyamatfejlesztési teamek (pld. SEPG) a szervezet szoftverfolyamatának meghatározására és fejlesztése érdekében használják.

Az eltérő felhasználási lehetőségek miatt az aktuális folyamatfejlesztési javaslatok megkülönböztetése érdekében a modell érettségi szintstruktúráját megfelelő részletességgel fel kell bontani.

6.1 Az érettségi szintek belső szerkezete Minden érettségi szint alkotóelemekre bontható. Az első szint kivételével minden szint felbontása az általános leírástól a kulcstevékenységek műszaki definíciójáig terjed. Minden érettségi szintet kulcsfolyamat-területek alkotnak. Minden kulcsfolyamat-terület az általános jellemzők szerint szerveződik. Az általános jellemzők meghatározzák a kulcstevékenységeket, amelyek együttesen képesek a kulcs-folyamatterület eléréséhez hozzásegíteni a szervezetet.

6.2 Az érettségi szintek

26


04.03.17 Minden érettségi szint (maturity level) egy jól definiált kiindulópont az érett szoftverfolyamat elérésének fejlődési útján. Minden érettségi szint a folyamatképesség egy szintjét jelenti. (Például a második szintet elérő szervezet folyamatképessége „ad hoc” jellegűtől „fegyelmezetté” válik.)

6.3 Kulcsfolyamat-területek Az első szint kivételével minden érettségi szint felosztható kulcs-folyamatterületekre (key process areas), amelyekre a szervezetnek koncentrálnia kell a szoftverfolyamat fejlesztése és az adott érettségi szint elérése érdekében. A kulcs-folyamatterület céljai elérésének módja a különböző alkalmazási területek és az eltérő környezeti paraméterek miatt projektenként változó lehet. Egy szervezet akkor tudja intézményesíteni a kulcs-folyamatterület által leírt folyamatképességet, ha a projektjei az adott kulcs-folyamatterület összes célját elérik. A „kulcs” szó azt fejezi ki, hogy léteznek folyamatterületek, amelyek kulcsfontosságúak egy érettségi szint eléréséhez, és léteznek olyanok, amelyek nem azok. A CMM nem tartalmazza a szoftverfejlesztés és a –karbantartás összes folyamatterületét, csak azokat, amelyek a folyamatképesség szempontjából kulcsfontosságúak. Egy érettségi szint eléréséhez az adott szinten lévő összes kulcs-folyamatterületet meg kell valósítani. Egy kulcs-folyamatterület megvalósításához annak összes célját el kell érni. A célok összefoglalják a kulcs-folyamatterület kulcstevékenységeit, és felhasználhatóak annak megítélésére, hogy egy szervezet illetve projekt megvalósította-e az adott kulcsfolyamatterületet. A célok jelzik a kulcs-folyamatterület kiterjedését. A CMM kulcs-folyamatterületei az érett szervezetté válás egy útját írják le. A kulcsfolyamatterületek definíciói sok év szoftvertechnológiai, menedzsment, szoftverfolyamatfelmérési és szoftverképesség-kiértékelési tapasztalatain alapszanak.

27


04.03.17 A második szint kulcs-folyamatterületei a projektmenedzsment alapvető ellenőrző tevékenységeire összpontosítanak: A Követelménymenedzsment (Requirements Management) célja a megrendelő és a szoftverprojekt közötti egyetértés biztosítása a követelményekkel kapcsolatban. Ez a megegyezés az alapja a tervezésnek (Szoftverprojekt-tervezés) és a menedzselésnek (Szoftverprojekt-követés). A megrendelővel tartott kapcsolat függvénye egy hatékony változást felügyelő folyamatnak (Szoftverkonfiguráció-menedzsment) A Szoftverprojekt-tervezés (Software Project Planning) célja a szoftverprojekt technikai és menedzsment szempontú kivitelezéséhez szükséges megfelelő tervek elkészítése. Realisztikus tervek nélkül a projektmenedzsmentet nem lehet hatékonyan megvalósítani. A Szoftverprojekt-követés (Software Project Tracking and Oversight) célja a projekt előrehaladásába való megfelelő betekintés biztosítása annak érdekében, hogy a menedzsment képes legyen hatékony lépéseket tenni, ha a szoftverprojekt teljesítménye jelentősen eltér a tervektől. A Szoftveralvállalkozó-menedzsment (Software Subcontract Management) célja a szoftveralvállalkozók

kiválasztása

és

a

velük

való

kapcsolat

menedzselése.

Ehhez

a

Szoftveralvállalkozó-menedzsment felhasználja az összes többi (második szintű) kulcsfolyamatterületet. A Szoftverminőség-biztosítás (Software Quality Assurance) célja a szoftverprojekt által alkalmazott folyamatba és a készülő termékekbe való betekintés biztosítása a menedzsment számára. A Szoftverkonfiguráció-menedzsment (Software Configuration Management) célja a szoftveréletciklusban a szoftverprojekt termékei integritásának biztosítása. A harmadik szint kulcs-folyamatterületei szervezeti és projektelemekkel is foglalkoznak.

28


04.03.17 A Szervezeti folyamatközpontúság (Organization Process Focus) célja a szoftverfolyamattevékenységekért érzett felelősség kialakítása, amely növeli a szervezet szoftverfolyamatképességét. A Szervezeti folyamatközpontúság tevékenységeinek elsődleges eredményei szoftverfolyamat-értékek, melyeket a Szervezeti folyamat-meghatározás ír le. A Szervezeti folyamatmeghatározás (Organization Process Definition) célja folyamat-értékek elérése és fenntartása, amelyek növelik a projektek folyamatteljesítményét és a szervezet számára hosszú távú előnyöket biztosítanak. A Képzési program (Training Program) célja az egyének képességeinek fejlesztése és tudásának növelése annak érdekében, hogy szerepüket hatásosabban és hatékonyabban tudják betölteni. A képzés szervezeti felelősség, de a szoftverprojekteknek is azonosítaniuk kell saját képzési igényeiket. Az

Integrált

szoftvermenedzsment

szoftvertechnológiai

és

(Integrated

Software

menedzsment-tevékenységek

Management)

olyan

koherens,

célja

a

definiált

szoftverfolyamattá szervezése, mely a Szoftvertermék-technológia által meghatározott módon származik a szervezet szabványos szoftverfolyamatából (az üzleti környezet és a technikai szükségletek figyelembevételével).

Az Integrált szoftvermenedzsment a második szinten

elhelyezkedő Szoftverprojekt-tervezés és Szoftverprojekt-követés kulcsfolyamat-területek továbbfejlesztése. A Szoftvertermék-technológia (Software Product Engineering) célja egy olyan technikai jellegű folyamat követése, amely megfelelő szoftvertermékek hatékony és hatásos előállítása érdekében szervezi egységgé a szoftvertechnológiai tevékenységeket. A Szoftverterméktechnológia írja le a projekt műszaki tevékenységeit: követelményanalízis, tervezés, kódolás, tesztelés. A Csoportközi együttműködés (Intergroup Coordination) célja, hogy koordinált módon lehetővé tegye a szoftvermérnök-teamek számára az interakciót más teamekkel, a megrendelő szükségleteinek jobb kielégítése érdekében.

29


04.03.17 A Vizsgálati szemlék (Peer Reviews) célja a hibák korai és hatékony eltávolítása a szoftvertermékekből. Ennek eredménye a szoftvertermékek jobb, átfogóbb megértése és a hibák megelőzésének elősegítése. A negyedik szinten a kulcs-folyamatterületek a szoftverfolyamat és a szoftvertermékek kvantitativitására helyezik a hangsúlyt: A

Kvantitatív

folyamatmenedzsment

(Quantitative

Process

Management)

célja

a

szoftverprojekt folyamatteljesítményének kvantitatív ellenőrzése. A szoftverfolyamatteljesítmény jeleníti meg a szoftverfolyamat követése következtében elért aktuális eredményeket. A cél egy mérhető, stabil folyamaton belüli eltérések okainak azonosítása és a megfelelő intézkedések megtétele. A kvantitatív folyamatmenedzsment átfogó mérési programmal egészíti ki a következő kulcs-folyamatterületeket: Szervezeti folyamatmeghatározás, Integrált szoftvermenedzsment, Csoportközi kommunikáció, Vizsgálati szemlék. A Szoftverminőség-menedzsment (Software Quality Management) célja a projekt szoftvertermékei minősége kvantitatív módon történő mérhetőségének lehetővé tétele, továbbá a minőségügyi célok elérése. A Szoftverminőség-menedzsment a Szoftverterméktechnológia által leírt szoftvertermékek számára átfogó mérési programot biztosít. Az ötödik szinten a kulcs-folyamatterületek a folytonos és mérhető szoftverfolyamat fejlesztését ölelik fel: A Hibamegelőzés (Defect Prevention) célja a hibák okainak meghatározása és újbóli bekövetkezésük megakadályozása. A szoftverprojekt elemzi a hibákat, meghatározza az okokat és megváltoztatja definiált szoftverfolyamatát. A széleskörűen alkalmazható változtatásokat a Technológiai változásmenedzsmentben leírt módon más projektek is átveszik. A Technológiai változásmenedzsment (Technology Change Management) célja a hasznos, új technológiák azonosítása (eszközök, módszerek, folyamatok stb.) és átültetése a szervezeti 30


04.03.17 keretek közé a Folyamatváltozás-menedzsment által meghatározott módon. A Technológiai változásmenedzsment az innovációra helyezi a hangsúlyt. A Folyamatváltozás-menedzsment (Process Change Management) célja a szoftverfolyamat folytonos fejlesztése (minőség, produktivitás stb.) és a fejlesztési idő csökkentése. A Folyamatváltozás-menedzsment terjeszti el a Hibamegelőzés evolúciós jellegű és a Technológiai változásmenedzsment forradalmi változtatásait a szervezetben.

6.4 A kulcs-folyamatterületek részletes céljai A második szinten elhelyezkedő kulcs-folyamatterületek céljai [Paulk (1993)]: A Követelménymenedzsment kulcs-folyamatterület céljai: -

Cél 1: a szoftverrel kapcsolatos rendszerelvárások ellenőrzöttek legyenek, ily módon alapot teremtve a szoftvertechnológia és a menedzsment számára

-

Cél 2: a szoftverrel kapcsolatos tervek, termékek és tevékenységek konzisztensek legyenek a „Cél 1”-ben említett elvárásokkal

A Szoftverprojekt-tervezés kulcs-folyamatterület céljai: -

Cél 1: a szoftverre vonatkozó becslések dokumentáltak legyenek a szoftverprojekt tervezése és követése során való felhasználás érdekében

-

Cél 2: a szoftverprojekt tevékenységei és kötelezettségei tervezettek és dokumentáltak legyenek

-

Cél 3: az érintett csoportok és személyek egyetértenek a szoftverprojektre vonatkozó kötelezettségekkel

A Szoftverprojekt-követés kulcs-folyamatterület céljai: -

Cél 1: az éppen aktuális eredmények és teljesítmények összevetése a szoftvertervekkel

-

Cél 2: az aktuális eredmények és teljesítmények a szoftvertervektől való eltérése esetén a megfelelő helyesbítő lépések megtétele, menedzselése

31


04.03.17 - Cél 3: a szoftverkötelezettségek módosítása az érintett csoportok és személyek egyetértésével történik A Szoftveralvállalkozó-menedzsment kulcs-folyamatterület céljai: -

Cél 1: a szervezet megfelelően kvalifikált szoftver-alvállalkozókat választ ki

-

Cél 2: a szervezet és a szoftver-alvállalkozó megegyeznek egymással szembeni kötelezettségeikről

-

Cél 3: a szervezet és a szoftver-alvállalkozó aktív kommunikációt tart fenn

-

Cél 4: a szervezet a szoftver-alvállalkozó aktuális eredményeit és teljesítményét összeveti a kötelezettségekkel

A Szoftverminőség-biztosítás kulcs-folyamatterület céljai: -

Cél 1: a szoftverminőség-biztosítási tevékenységek biztosítottak legyenek

-

Cél 2: objektív módon igazolható, hogy a szoftvertermékek és –tevékenységek a vonatkozó előírások, eljárások és elvárások pontos betartásával kivitelezettek

-

Cél 3: az érintett csoportok és személyek értesülnek a Szoftverminőség-biztosítás tevékenységeiről és eredményeiről

-

Cél 4: a szoftverprojekten belül nem kezelhető nem-megfelelő teljesítményeket a felső vezetés kezeli

A Szoftverkonfiguráció-menedzsment kulcs-folyamatterület céljai: -

Cél 1: a Szoftverkonfiguráció-menedzsment tevékenységei tervezettek legyenek

-

Cél 2: a kiválasztott szoftvertermékek azonosítottak, ellenőrzöttek és elérhetőek legyenek

-

Cél 3: a „Cél 2” szoftvertermékeivel kapcsolatos változtatások ellenőrzöttek legyenek

-

Cél 4: az érintett csoportok és személyek tájékoztatása a szoftverkörnyezet állapotáról és tartalmi elemeiről

A harmadik szint kulcs-folyamatterületeinek céljai: A Szervezeti folyamatközpontúság kulcs-folyamatterület céljai:

32


04.03.17 - Cél 1: a szoftverfolyamat-fejlesztési és –javítási tevékenységek koordináltak legyenek a szervezetben -

Cél 2: a használatban lévő szoftverfolyamatok a szabványos folyamathoz viszonyított erősségei és gyengeségei azonosítottak legyenek

-

Cél 3: a szervezet-szintű folyamatfejlesztési és –javítási tevékenységek tervezettek legyenek

A Szervezeti folyamat-meghatározás kulcs-folyamatterület céljai: -

Cél 1: a szervezeti szabványos szoftverfolyamat kifejlesztése és karbantartása

-

Cél 2: a szoftverprojekteknek a szervezeti szabványos szoftverfolyamattal kapcsolatos információinak összegyűjtése, felülvizsgálata és elérhetővé tétele

A Képzési program kulcs-folyamatterület céljai: -

Cél 1: a képzési tevékenységek tervezettek legyenek

-

Cél 2: a menedzsmentbeli és a szoftvertechnológiai szerepek betöltéséhez nélkülözhetetlen tudás és képességek megszerzéséhez szükséges képzés biztosított legyen

-

Cél 3: a szoftvertechnológiai és a szoftver-vonatkozású csoportok tagjai megkapják a szerepük betöltéséhez szükséges képzést

Az Integrált szoftvermenedzsment kulcs-folyamatterület céljai: -

Cél

1:

a

projektek

definiált

szoftverfolyamata

a

szervezet

szabványos

szoftverfolyamatának testreszabott változata legyen -

Cél 2: a projekt annak definiált szoftverfolyamata szerint tervezett és menedzselt legyen

A Szoftvertermék-technológia kulcs-folyamatterület céljai: -

Cél 1: a szoftver előállításához szükséges szoftvertechnológiai feladatok definiáltak, integráltak és következetesen véghezvittek legyenek

-

Cél 2: a szoftvertermékek egymással konzisztensek legyenek

A Csoportközi együttműködés kulcs-folyamatterület céljai: 33


04.03.17 - Cél 1: a felhasználó elvárásait illetően minden érintett csoport egyetértésre jut -

Cél 2: a csoportok közötti kötelezettségeket illetően egyetértés alakul ki

-

Cél 3: a több csoportot érintő feladatokat az érintett csoportok felismerik és sikeresen megoldják

A Vizsgálati szemlék kulcs-folyamatterület céljai: -

Cél 1: a Vizsgálati szemlék tevékenységei tervezettek legyenek

-

Cél 2: a szoftvertermékek hibáinak azonosítása és kijavítása

A negyedik szint kulcs-folyamatterületeinek céljai: A Kvantitatív folyamatmenedzsment kulcs-folyamatterület céljai: -

Cél 1: a Kvantitatív folyamatmenedzsment tevékenységei tervezettek legyenek

-

Cél 2: a projekt definiált szoftverfolyamatának teljesítménye kvantitatív módon ellenőrzött legyen

-

Cél 3: a szervezet szabványos szoftverfolyamatának képessége kvantitatív módon kifejezhető legyen

A Szoftverminőség-menedzsment kulcs-folyamatterület céljai: -

Cél 1: a projekt szoftverminőség-menedzsmentjének tevékenységei tervezettek legyenek

-

Cél 2: a szoftvertermék minőségével kapcsolatos mérhető célok és célprioritások definiálása

-

Cél 3: a szoftvertermék minőségi céljai elérésének aktuális állapota mennyiségileg kifejezhető és menedzselhető legyen

Az ötödik szint kulcs-folyamatterületeinek céljai: A Hibamegelőzés kulcs-folyamatterület céljai: -

Cél 1: a Hibamegelőzés tevékenységei tervezettek

-

Cél 2: a hibák általános okainak megkeresése és azonosítása

34


04.03.17 - Cél 3: a hibák általános okai prioritásának meghatározása, az okok szisztematikus eltávolítása A Technológiai változásmenedzsment kulcs-folyamatterület céljai: -

Cél 1: a technológiai változtatások bevezetése tervezett legyen

-

Cél 2: új technológiák kiértékelése a minőséggel és a termelékenységgel kapcsolatos hatások megismerése érdekében

-

Cél 3: a megfelelő technológiák átültetése a gyakorlatba az egész szervezetre kiterjedő módon

A Folyamatváltozás- menedzsment kulcs-folyamatterület céljai: -

Cél 1: a folytonos folyamatfejlesztés tervezett legyen

-

Cél 2: a teljes szervezet részt vesz a szervezet szoftverfolyamatának fejlesztési tevékenységeiben

-

Cél

3:

a

szervezet

szabványos

szoftverfolyamata

és

a

projekt

definiált

szoftverfolyamata folytonosan fejlesztett legyen

6.5 Általános jellemzők A kulcs-folyamatterületek az általános jellemzők (common features) szerint szerveződnek. Az általános jellemzők mutatják meg azt, hogy a kulcs-folyamatterület megvalósítása és intézményesítése megfelel-e a következő követelményeknek: hatásosság, megismételhetőség, tartósság. Öt általános jellemző létezik. Az Elvégzés iránti elkötelezettség (Commitment to Perform) azokat a lépéseket írja le, amelyeket a szervezetnek a tartós folyamatlétesítéshez meg kell tennie. Az Elvégzés iránti elkötelezettség általában a szervezeti alapelveket és a felső vezetés támogatását jelenti. Az Elvégzés képessége (Ability to Perform) a szoftverfolyamat megfelelő megvalósításához szükséges előfeltételeket írja le. Az Elvégzés képessége általában az erőforrásokat, a szervezeti struktúrákat és képzéseket foglalja magában.

35


04.03.17 Az Elvégzett tevékenységek (Activities Performed) azokat a szerepköröket és eljárásokat írják le,

amelyek

a

kulcs-folyamatterület

megvalósításához

szükségesek.

Az

Elvégzett

tevékenységekhez tartozik a tervek és eljárások kidolgozása, a munka végrehajtása, követése, és a szükséges helyesbítő tevékenységek elvégzése. A Mérés és elemzés (Measurement and Analysis) a folyamat mérését és a mérések elemzését írja le. A Mérés és elemzés az Elvégzett tevékenységek állapotának és hatékonyságának meghatározására szolgáló mérési példákat tartalmaz. A Megvalósítás ellenőrzése (Veryfying Implementation) azokat a lépéseket írja le, amelyek biztosítják, hogy a tevékenységek elvégzése a meghatározott folyamat szerint történjen. A Megvalósítás ellenőrzése a vezetői szemléket (review) és auditokat, továbbá a szoftverminőség- biztosítást jelenti. Az „Elvégzett tevékenység” általános jellemző tevékenységei azt írják le, mi szükséges a folyamatképesség létrehozásához. A többi tevékenység azt az alapot alkotja, melynek segítségével a szervezet intézményesíteni tudja a fenti általános jellemző által leírt tevékenységeket.

6.6 Kulcstevékenységek Minden kulcs-folyamatterület leírása kulcstevékenységek (key practices) segítségével történik,

amelyek

kulcstevékenységek

hozzájárulnak a

a



hatékony

céljainak

eléréséhez.

megvalósításához

A és

intézményesítéséhez leginkább szükséges infrastruktúrát és tevékenységeket írják le. Minden kulcstevékenység egyetlen mondatból áll, amelyet gyakran egy részletesebb leírás követ, amely példákat és kidolgozást is tartalmazhat. Ezek a kulcstevékenységek (felső szintű kulcstevékenységek) határozzák meg a kulcs-folyamatterület alapvető irányelveit, eljárásait és teendőit. A részletes leírás elemeit gyakran résztevékenységeknek hívják.

36


04.03.17 A kulcstevékenységek kizárólag azt írják le, hogy „mit” szükséges tenni (nem azt, „hogyan”) a célok elérése érdekében, de példák segítségével többnyire a cél elérésének módjáról is tájékoztatást adnak. A kulcstevékenységek mindig racionálisan értelmezendők, s ily módon kell megvalósítani a kulcs-folyamatterület céljait.

37


04.03.17

7. A CMM felhasználása A CMM meghatározza az érett szoftverszervezetek jellemző kritériumait. Ezeket a kritériumokat a szervezetek szoftverfejlesztési és –karbantartási folyamataik fejlesztéséhez, a kormányzat és a kereskedelmi szervezetek egy adott vállalattal kötendő (szoftverprojektre irányuló) szerződés kockázatának felmérésére használhatják. A SEI két módszert dolgozott ki a szervezetek szoftverfolyamat-végrehajtása érettségének vizsgálatára. A CMM közös alapként szolgál a szoftverfolyamat-felmérés és a szoftverképesség-kiértékelés számára egyaránt, azonban a két módszer céljai meglehetősen eltérőek. A szoftverfolyamat-felmérés (Software Process Assessment) a szervezet jelenlegi szoftverfolyamata

állapotának

meghatározására,

a

szervezet

előtt

álló

fontos

(szoftverfolyamattal kapcsolatos) elemek meghatározására és a szoftverfolyamat-fejlesztés szervezeti támogatásának elérésére használható. A SEI által kifejlesztett másik módszer, a szoftverképesség-kiértékelés (Software Capability Evaluation) a megfelelően kvalifikált szerződő felek szoftverfolyamata állapotának megfigyelésére használható.

7.1 A szoftverfolyamat-felmérés és a szoftverképesség-kiértékelés A

szoftverfolyamat-felmérés

a

vállalat

saját

szoftverfolyamatán

belüli

fejlesztési

prioritásainak azonosítására koncentrál. A felmérő-teamek a CMM modellt a felmérés eredményeinek és prioritásainak meghatározására használják. Ezek az eredmények a CMM kulcstevékenységeivel együtt segítséget nyújtanak a szoftvertechnológiai folyamatcsoport számára a szervezet fejlesztési stratégiájának tervezésében. A szoftverképesség-kiértékelés egy adott ütemezéssel és költségvetéssel rendelkező projekt, illetve szerződés kockázataira koncentrál. A kiértékelés eredményei segítenek a megfelelő 38


04.03.17 szerződő fél kiválasztásában, továbbá a már megkötött szerződésekhez kapcsolódó folyamatteljesítmény

alakulásának

megfigyelésében,

fejlesztési

lehetőségeinek

meghatározásában. A szoftverfolyamat-felmérés és a szoftverképesség-kiértékelés közös lépései: -

Az első lépés a team összeállítása. A team tagjainak érteniük kell a CMM, a szoftverfolyamat-felmérés és a szoftverfolyamat-kiértékelés lényegi elemeit, továbbá megfelelő szoftvertechnológiai és menedzsmentbeli tudással kell rendelkezniük.

-

A második lépés a felmérendő, illetve kiértékelendő „helyszín” képviselőivel kitöltetni (többek között) az érettségi kérdőívet

-

A harmadik lépés a válaszelemzés, melynek során a felmérő illetve a kiértékelő team a válaszok alapján meghatározza a további vizsgálatok területeit.

-

A negyedik lépés során a team látogatást tesz a felmérendő, illetve kiértékelendő helyszínen. A válaszelemzés eredményei alapján a team interjúk lebonyolításával és a megfelelő dokumentáció elolvasásával átfogó képet kap az adott szoftverfolyamatról. A CMM kulcs-folyamatterületei és kulcstevékenységei segítséget nyújtanak a team tagjainak a kérdések feltevésében és az információ elemzésében. Végül a team eldönti, hogy a kulcs-folyamatterület megvalósítása a kulcs-folyamatterület céljaiban foglaltakat

kielégíti-e;

a

CMM

kulcstevékenységeitől

való

eltérések

okait

dokumentálják. -

Az ötödik lépésben a team elkészíti az eredménylistát, amely meghatározza a szervezet szoftverfolyamatának erősségeit és gyengeségeit. Szoftverfolyamat-felmérés esetén az eredmények folyamatfejlesztési javaslatok alapjaként szolgálnak, míg szoftverképesség-kiértékelés esetén a kockázatelemzés részét képezik.

39


04.03.17 - A hatodik lépésben a team elkészíti a kulcs-folyamatterület profilját, amely rámutat azokra a területekre, ahol a szervezet sikeresen elérte a kulcs-folyamatterület céljait, illetve ahol a célok elérése nem következett be.

7.2 A szervezetben betöltött szerepkörök Az alábbi bekezdések felvázolják a CMM által hivatkozott szervezeti szerepköröket. Egy adott projekt esetén természetesen nem szükséges egy-egyértelmű megfeleltetésnek fennállnia a személyek és az alábbi szerepkörök között; egy személy képességeinek megfelelően több szerepkört is betölthet. Menedzser: olyan szerepet tölt be, amely magában foglalja a menedzser felelősségi területén belüli feladatokat ellátó személyek technikai és adminisztratív irányítását és ellenőrzését. Hagyományosan a menedzser feladatai közé tartozik: a tervezés, az erőforrás-kezelés, a szervezés, az irányítás, az ellenőrzés (a meghatározott felelősségi körön belül). Szenior

menedzser:

meglehetősen

magas

szinten

tölt

be

szerepet

a

szervezet

menedzsmentjében. Elsődlegesen a szervezet hosszabb távú érdekeire koncentrál; általában egyszerre több projektért is felelős; a szoftverfolyamat hosszabb távú fejlesztéséhez biztosítja az eszközöket, erőforrásokat. Projekt menedzser: egy egész projektért vállal üzleti felelősséget; szerepe felöleli a szoftver, illetve a szoftver-hardver rendszer elkészítésének irányítását, ellenőrzését és felügyeletét. Egy projekt-orientált szervezeti struktúrában a projekten dolgozó személyek elsősorban a projekt menedzsernek tartoznak jelentési kötelezettséggel. Projekt szoftver-menedzser: egy projekt szoftverrel kapcsolatos feladataiért vállal teljes felelősséget; a projekt szoftver-erőforrásainak felügyeletét biztosítja. First-line szoftver-menedzser: felelőssége egy projekt-team tevékenységeinek technikai irányítására és személyzeti kérdéseire terjed ki.

40


04.03.17 Szoftver feladatvezető: egy team technikai vezetője, adott feladatra vonatkozóan. Szoftvertechnológiai személyzet: elemzők, programozók, mérnökök stb.

7.3 Szervezeti struktúra Szervezet: egy vállalat olyan egysége, melyen belül több projektet együtt kezelnek. A szervezeten belüli projektek közös felsőszintű menedzserrel és irányelvekkel rendelkeznek. Projekt: egy adott hardver-, szoftver-, és egyéb komponenseket tartalmazó termék fejlesztésére és karbantartására koncentrál. Általában saját költségvetéssel, számlázással és ütemezéssel rendelkezik. A CMM által meghatározott és hivatkozott csoportok a következők: -

Szoftvertechnológiai csoport

-

Szoftvertechnológiai folyamatcsoport

-

Rendszermérnöki csoport

-

Rendszerteszt csoport

-

Szoftverkonfiguráció-menedzsment csoport

-

Képzési csoport

-

Szoftver-vonatkozású csoportok

41


04.03.17

8. Külföldi tapasztalatok A nemzetközi tapasztalatok alapján a CMM modell érettségi útján haladva a szervezetek jelentős pénzügyi, működtetési, termelési, marketing- és emberi erőforrás előnyökre tehetnek szert. [Tóth (1999)] 1994-ben tizenhárom olyan szervezet járult hozzá bizalmas adatainak közléséhez, amelynél CMM alapú szoftverfejlesztés történt, ezek a következők: -

Bull HN

-

GTE Government Systems

-

Hewlett Packard

-

Hughes Aircraft Co.

-

Loral Federal Systems

-

Lockheed Sanders

-

Motorola

-

Northrop

-

Schlumberger

-

Siemens Stromberg-Carlson

-

Texas Instruments

-

United States Air Force Oklahoma City Air Logistics Center

-

United States Navy Fleet Combat Direction Systems Support Activity

42


04.03.17

9. Hughes Aircraft Co. Ez a fejezet felvázolja a Hughes tevékenységét, melynek eredményeként 1997-ben elnyerte az IEEE szoftverfolyamat-fejlesztésért járó díját. A folytonosan fejlődő szoftverfolyamat létesítése a következőket tartalmazta [Willis (1998)]: -

a CMM és az ISO elvárásainak megfelelő bizonyított hatékonyságú szoftverfolyamat létrehozása

-

ennek a folyamatnak az elterjesztése a szervezeten belül

-

jelentős pozitív hatás a szervezetre, az iparra, a kormányzatra stb.

A kötelezettségeknek és a minőségi elvárásoknak való megfelelés érdekében a Hughes már negyedévszázada fejleszti szoftverfolyamatait. A Hughes volt az első szervezet, amely 1990ben, egy a SEI segítségével készült felmérés alapján elérte a harmadik szintet. Bármilyen legyen is az adott folyamat fejlettsége, valódi eredményekről csak a folyamat intézményesítése után lehet beszámolni. Az Általános Szoftverfolyamat (CSWP) 22 tevékenységet foglal magába a Hughes-en belül, amelyet a szoftverek 85%-át elkészítő 13 részlegben 4800 szoftverfejlesztő alkalmaz.

9.1 A fejlesztési paradigma A szervezet fejlesztési kultúrája az 1970-es évek első feléből származik. Bár időközben különböző elnevezéseket kapott (teljeskörű minőségbiztosítás, kaizen, null-hiba), mindvégig ugyanazt jelentette: folytonos mérhető fejlesztést. A fejlesztési kultúra célja a megrendelők elvárásainak való megfelelés a folyamat fejlesztésével.

9.2 A folyamat eredményességének bizonyítékai

43


04.03.17 A Hughes az alábbi utat követve az elsők között volt a szoftverfolyamat definíciójának felállításában és mérési lehetőségeinek vizsgálatát tekintve: -

az 1970-es években kezdte folyamatfejlesztési munkálatait

-

szakértőkből álló teamek és a tapasztalatok felhasználása révén 1987-re a folyamat érettsége elérte a második szintet (egy a SEI segítségével elvégzett felmérés alapján)

-

a mérések a Szoftvertechnológiai Tevékenységek és Eljárások (SEPP) képessége igazolásának alapjává váltak

-

1990-re a harmadik szint elérése is bekövetkezett (első szervezetként)

-

bizonyos projektek esetén a negyedik és az ötödik szint elérése

1977-től a szervezet szabványos jelentési folyamatot alkalmaz, mely fokozatosan a CSWP részévé vált, s amely a Hughes véleménye szerint megkülönbözteti a szervezetet azoktól, akik a harmadik, illetve negyedik szint elérésénél kudarcot vallottak. Az 1980-as évek során a szervezet a folyamatteljesítmény diagnosztizálására és igazolására koncentrált, e célból az egyes projektek mérési eredményei és jelentései szervezeti szinten is összegzésre kerültek; a szervezet megpróbálta a költség-teljesítmény index és a szoftverfolyamat-fejlesztési

mérőszám

hányadosát

(CPI/SPI)

1,0-hoz

közelíteni.

A

vizsgálatok során kiderült, hogy a CPI erősen korrelál az érettségi szinttel, ily módon igazolva a CPI optimalizálási mérőszámként való alkalmazását. Az 1987-ben elvégzett felmérés után a szervezet a szoftverszemlék (review) hatékonyságát választotta általános hatékonysági mérőszámnak, mivel minél több hibára derül fény még abban a fázisban, amelyben azokat elkövették, annál kevesebb munkára (és kiadásra) van szükség a későbbi fázisokban a rejtőzködő hibák eltávolításához. Jelentős mértékű fejlődésként, az adott fázison belüli (követelményekre vonatkozó hibákkal kapcsolatos) hatékonyság 43%-ról 84%-ra növekedett, ami 1249 hibát érintett és 987 munkanap megtakarítást jelentett.

44


04.03.17 1992-ben és 1993-ban a védelmi kiadások csökkenése és az átszervezések következtében az elsődleges szoftverközpont egyes részei más Hughes-szervezetekhez kerültek: -

a vállalat elnöke meghirdette a szoftverfolyamat-fejlesztés egész vállalatra való kiterjesztésének irányelveit

-

létrejött a „Rendszer- és szoftvertechnológiai alelnök” pozíció

-

létrejött a Rendszer- és Szoftvertechnológiai Tanácstestület (SSEC) a Hughesszervezetek

rendszer-

és

szoftvertechnológiai

folyamat-tulajdonosainak

együttműködése érdekében -

igyekeztek az átszervezés előnyeit kihasználni

A Hughes akvizíciói során beolvadó szervezetek érettsége rendkívül különböző, amely hatással van a Hughes folyamatérettségi összetételére. A beolvadó szervezetek vezetőivel a Hughes (és az SSEC) megosztja a felhalmozódott tapasztalatokat a folyamatok érettségének további növelése érdekében.

9.3 A CSWP vállalati-szintű alkalmazása 1990-ben a Hughes vezetői összeállítottak egy (több részleg tagjaiból álló) csapatot a SEPPeken alapuló CSWP kifejlesztése érdekében. A CSWP a SEI CMM és az ISO szoftverre vonatkozó elvárásainak egyaránt megfelel. A CSWP a Hughes minden szoftverfejlesztője számára hozzáférhető (Intranet és CD-ROM segítségével is), a folyamatlétesítéshez szükséges kiegészítőkkel együtt. A szervezet felmérési és fejlesztési tevékenységei a CSWP hatékony létesítését támogatják; a szoftvertechnológiai folyamatcsoportok (SEPG-k) a vállalat szintjén összesen több mint 50 folyamatmérnökből állnak. A Hughes a CSWP létesítését a következő területeken találta hasznosnak:

45


04.03.17 - gyorsabb alkalmazás: az egyik szoftverszervezet (Tucson) kevesebb, mint három év alatt érte el az első szintről indulva a harmadik szintet, annak köszönhetően, hogy egy már kipróbált folyamatot létesített, s nem újat kellett kifejlesztenie. -

a tapasztalatok újrahasznosítása, megosztása más részlegekkel

-

könnyebb képzés

46


04.03.17

9.4 A fejlesztési tervek folytatása A Hughes célként tűzte maga elé: minden szervezetnek el kell érnie a harmadik (vagy annál magasabb) szintet, és legalább egy szervezetnek el kell jutnia az ötödik szintig. Ezt alátámasztotta, hogy a Hughes már rendelkezett tapasztalatokkal a harmadik szint gyors elérésének lehetőségével kapcsolatban, továbbá bizonyos szervezetek már aktuális érettségi szintjüknél magasabb szinten elhelyezkedő kulcs-folyamatterületek céljait is megvalósították. A folyamatok érettségének következményeként a hatékony mérési eljárások bevezetésének képessége is megnövekedett, így a harmadik és negyedik szintet elérő szervezetek több mérési eljárást alkalmaztak. A „Békepajzs” projekt során a szervezet a CPI/SPI indexet tekintve 0,99/0,99 arányt ért el, ami a CSWP hatékonyságának is köszönhető. A projektek során megszerzett tapasztalatok segítségével a részlegek és a vállalat szintjén összegzik a teljesítménymutatókat a költség, az ütemterv, az érettség, a minőség és a termelékenység tekintetében. Mindez a folyamatfejlesztés jövőbeli irányszámainak meghatározását szolgálja.

9.5 Pozitív hatások A Hughes üzleti tevékenységeit illetően a következő pozitív hatások érvényesültek: -

25

Szoftverképesség-kiértékelés

(SCE),

számos

Szoftverfejlesztés-képességi

kiértékelés (SDCE), és ISO minősítések sikeressége -

a hatékony folyamatoknak köszönhetően új üzleti lehetőségek: pld. a „Békepajzs” projekt elnyerése

-

több mint 200 projekt esetében bizonyultak a fejlesztések hasznosnak

-

növekvő eladások a szoftver-intenzív piacokon

9.6 A vállalat leírása

47


04.03.17 A Hughes a védelmi elektronikus rendszerek (elektro-optikai, kommunikációs és radarrendszerek, rakéták), továbbá a légiforgalmi irányító-, légvédelmi és műholdas rendszerek, képfeldolgozó rendszerek, képzési rendszerek és az ezekhez kapcsolódó szolgáltatások vezető szállítója. A fenti rendszerek kifejlesztését szolgáló szoftverprojektek mérete változó: a kisebb teamektől egészen az igen nagy, összetett, sok csapatból illetve vállalatból álló, több millió kódsort leszállító projektekig terjed. A fenti rendszerek sikeressége érdekében a vállalat tíz év alatt 23 millió dollárt költött folyamatfejlesztésre. Ezekben az erőfeszítésekben 28 Hughes-szervezet vett részt, amelyek között természetesen találhatóak régebbi és újabban beolvadt egységek is. 53 folyamatmérnök dolgozik együttműködve a lokális szoftvertechnológiai folyamatcsoportokban.

9.7 A Hughes szoftverfolyamatának fejlesztése A Hughes az üzleti egységek szintjén már az 1970-es évek elejétől fogva elkötelezettje volt a szoftverfolyamat fejlesztésének. 1989-ben azonban optimális megközelítésként felmerült a probléma

általános,

szoftverszervezetek

vállalati

szintű

kezelésének

szoftverfolyamat-képessége

szükségessége.

sokat

javult,

a

Bár

az

Hughes

egyes vállalati

menedzsmentje az egész vállalatra kiterjedő kihívásként értékelte a folyamatfejlesztés kérdését. Az 1980-as évék végén (az átszervezések idején) a menedzsment a Védelmi Minisztérium és más kormányzati szervezetek számára történő szoftverfejlesztést tekintette a legfontosabb tevékenységnek; az új piaci kihívásoknak való megfelelés érdekében megalakult a Szoftvertechnológiai

Tanácsadó

Testület

(STAC),

mely

1989

végén

a

Vállalati

Szoftverkezdeményezési (CSI) program létrehozását indítványozta. A CSI program egy olyan, több szervezet tagjaiból összeállítandó team megalakulását tartalmazta, melynek célja a szoftverfejlesztés során felhasznált eszközök, eljárások és a szoftverfolyamat hatékonyabb alkalmazásából eredő versenyképességi előny növelése volt.

48


04.03.17 A CSI programot a vállalati technológiai iroda hozta létre és menedzselte, de a tervezést és a személyek bevonását a vállalat egyes szoftverfejlesztési egységei támogatták, ily módon segítve az eltérő tulajdonságokkal rendelkező megrendelők számára történő szoftverfejlesztés problémájának megoldását. Teamek szerveződtek érett szoftverfolyamatok definiálása, létesítése és automatizálása érdekében. Mivel egyértelmű volt, a program sikere (költségek, minőség és ütemterv) és az adott szervezet folyamatérettsége közötti erős korreláció, így a CSI program egyik fő irányvonala a működési egységek érettségi szintjének növelése volt. Ekkoriban a program célként tűzte ki, hogy minden szervezet érje el legalább a második, a száz szoftverfejlesztőnél többet foglalkoztató szervezetek legalább a harmadik szintet. Tehát a menedzsment az egész vállalat versenyképességének növelését tekintette céljának (nem egy-két magasabb és sok alacsonyabb érettségi szintű szervezet kialakítását). A működési egységek önállósága és a változatos megrendelői kör miatt minden szervezet feladatul kapta saját folyamatfejlesztési megközelítésének kidolgozását. Ahelyett, hogy minden szoftver számára közös szoftverfolyamatot alakítottak volna ki, inkább bizonyos területek közös vonásaira koncentráltak. Ilyen területek pld.: költség- és ütemezési becslések, kockázat-menedzsment, CASE eszközök használata stb. 1991-ben újabb átszervezések következtek, melyek célja a vállalati munkaerő optimalizálása volt; sok technológiai funkció került kihelyezésre. Ekkor jött létre a Szoftvertechnológiai Hálózat (STN), melynek céljai a következők voltak: -

a szoftverekre vonatkozó tervek koordinált elkészítésének elősegítése

-

közös design-ra, fejlesztési és előállítási eljárásokra vonatkozó tervek koordinált kialakítása

-

szövetségek, kapcsolatok kialakítása egyetemekkel, konzorciumokkal, stb.

-

az információ továbbításával kapcsolatos általános tevékenységek segítése

-

a technológiai kapacitások kiértékelése a piac igényeihez viszonyítva (összehasonlító elemzések segítségével)

-

kiválósági központok felállítási munkálataiban való részvétel 49


04.03.17 Az alkalmazott benchmarking-nak és az érettségi szintekkel kapcsolatos tapasztalatoknak köszönhetően, a Hughes kihasználhatta a szoftverprojektek (vállalati szinten) közös menedzselésének előnyeit. Az általános folyamattól az érettségi szintek gyorsabb elérését remélték. Az új megközelítés az Általános Szoftverfolyamat (CSWP) elnevezést kapta. Alakult egy team, mely célul tűzte ki, hogy elérhetővé tegye a CSWP-t minden főbb Hughesszoftverszervezet számára, mely feladat magában foglalta az alkalmazási nyelvezet általánosítását is. 1995 után a Hughes az STN és a Rendszermérnöki Hálózat (SEN) összeolvasztásával létrehozta a Rendszer és Szoftvertechnológiai Tanácsadó Testületet (SSEC), melynek célja a CSWP létesítésének folytatása és felgyorsítása volt. A Hughes részt vett abban a teamben, amely a CMU SEI vezetésével megalkotta az SE CMM-et a rendszertechnológiai érettség vizsgálatára. Az SSEC a SEI által kiképzett vezetőfelmérőket a CBA-IPI (CMM-Based Appraisal for Internal Process Improvement) felmérések lebonyolítására alkalmazza a Hughes főbb szoftverszervezeteiben. Az SSEC felügyeli az időközönként elvégzett felmérések által meghatározott akcióterveket.

9.8 A megrendelők elégedettsége A folyamatfejlesztés legnyilvánvalóbban megjelenő előnye kvantitatív módon a CPI és az SPI indexeken keresztül tükröződik. 1988 és 1990 között, miközben a folyamatérettség elérte a harmadik szintet, a Szoftvertechnológiai Részleg összes projektjét tekintve az átlagos CPI (költség-teljesítmény index) 0,94-ről 0,97-re növekedett. Ekkor a szervezet éves működési költsége 62 millió dollár volt; a CPI növekedés 2 millió dollár megtakarítást jelentett, 400 ezer dolláros ráfordítás eredményeként. A megrendelők elemzői mindezt ötszörös befektetési hozamként értékelték (ROI: Return On Investment). Valójában a ROI nehezen számítható, mivel a megtakarítás évről-évre érezteti hatását, ily módon az elemzők tulajdonképpen alábecsülték a megtérülést.

50


04.03.17 A folyamatfejlesztésnek köszönhetően a CPI/SPI indexek átlagtól való eltérése fokozatosan csökkent. A szoftverfolyamattal kapcsolatos kockázat csökkent, pontosabbakká váltak az árajánlatok, elégedettebbekké váltak a megrendelők. Természetesen, ha egy projekt a fenti jellemzőktől eltér, akkor a teljesítmények mellett azt is megvizsgálják, mennyire pontosan követték az általánosan előírt folyamatot. A költségmegtakarítás mértékének megállapítása rendkívül nehéz, mivel nem lehetséges az ütemezés előrejelezhetőségéből, az elkerült kellemetlen meglepetésekből és a helyesbítőkiegészítő munkák megspórolásából származó előnyök pénzben történő pontos kifejezése. Mindezen eredmények a belső (menedzserek és üzleti vezetők) és a külső vevők (megrendelők) igényeinek kielégítését is lehetővé tették. A review-k hatékonyságának növekedése mellett (amely kockázatkezelési és minőségügyi szempontból is rendkívül fontos), az egyes hibák kijavításának átlagos időszükséglete is jelentősen csökkent: 0,63 munkanapról 0,09 munkanapra; sőt a szoftvertermékekben előforduló hibák abszolút száma is csökkent. A korábban felvázolt fejlődésnek köszönhetően a Hughes számos sikert ért el, pld. a „Békepajzs” projekt során, ahol a szervezet a korai szállításért 50 millió dollár jutalmat kapott (ezzel szemben, a szoftver átadásának csúszása esetén 50 millió dollár büntetéssel kellett volna számolnia a szervezetnek). A szerződésben előírt határidő 54 hónap volt, az 50 millió dolláros jutalom elnyeréséhez azonban 51 hónap alatt kellett elkészíteni a több mint egymillió kódsort tartalmazó rendszert. Végül a projekt (0,99-es CPI és SPI mellett) 48 hónap alatt befejeződött: a siker kulcsa kétségtelenül az érett szoftverfolyamat volt.

9.9 Innovációk A Hughes több mint negyedévszázados munkája során sokat tett a szoftverfolyamat-fejlesztés sikeréért. Elsősorban a következő innovációk és eredmények révén: -

kvantitatív folyamatmenedzsment

51


04.03.17 - szoftverminőség-technológia -

projekt review

-

egymillió kódsor feletti programok fejlesztése (C++)

-

segítségnyújtás a CMM megalkotásában

-

a harmadik szint elérése első szervezetként

-

a „6 Sigma” alkalmazása szoftverekre

A következő fejezet az Odgen Légi Logisztikai Központ folyamatfejlesztési törekvéseinek kiértékelését mutatja be. Látható, hogy több mint félévtizedes munkára volt szükség a CMM szerinti ötödik szint eléréséhez.

52


04.03.17

10. Az ötödik szint elérése - ALC Ez a fejezet leírja az Odgen Légi Logisztikai Központ (ALC) Szoftvertechnológiai Részlegének (TIS) a CMM szerinti ötödik szint elérését eredményező felmérését. Leírja továbbá a felmérésre való felkészülés folyamatát, a TIS folyamatainak belső és külső felmérési szempontból történő felülvizsgálatát: a felmérés felé vezető út problémáit és azok megoldásait, a felmérő team által megvitatott különböző megvalósítási alternatívákat, az ellentmondásos témákkal kapcsolatos konszenzus kialakulását a felmérő teamen belül. Vázolja továbbá a folyamat- és a termékbiztosítási felelősségek elválasztását, a folytonosan fejlődő

folyamatok

stabilitását,

az

intézményesítés

bizonyítékait,

a

Kvantitatív

folyamatmenedzsment megfelelő megvalósítását. [Putman (1999)] A TIS az 1990-es évek eleje óta mélyen elkötelezte magát a CMM felhasználásával történő folyamatfejlesztés mellett, melynek köszönhetően 1995-ben elérte a harmadik szintet. További fejlesztések után a belső folyamatfejlesztésre koncentráló CBA-IPI (CMM Based Appraisal for Internal Process Improvement) módszer alapján végeztek egy újabb felmérést, amely a CMM modell legmagasabb szintjének elérését bizonyította. A felmérés a részlegen belül minden szoftverfejlesztési és -karbantartási tevékenységre kiterjedt. A részlegen belül a szoftvertevékenységek különbözősége a jóval több, mint 100 embert foglalkoztató Operációs Repülési Program (OFP) fejlesztésétől a mindössze egyetlen ember munkáját igénylő Automatikus Tesztelő Berendezésig (ATE) terjedt. A felmérés céljai a következők voltak: -

az 1995-ben elvégzett felmérés óta végbement szoftverfolyamat-fejlődés mérése

-

a TIS érettségi szintjének meghatározása

-

olyan megfelelő részletességű eredmények biztosítása, amelyek alapján a TIS az egész részlegre

kiterjedően

újragondolhatja


termékvonalak számára új fejlesztési lehetőségek tárhatók fel.

53

erőfeszítéseit

és

a


04.03.17

10.1 Felkészülés a felmérésre A felmérő team kilenc személyből állt, közülük hárman a Carnegie Mellon University Szoftvertechnológiai Intézetéből, ketten a Warner Robins Légi Logisztikai Központból érkeztek. A felmérés elkezdése előtt a team a negyedik és ötödik szintű kulcsfolyamatterületekkel és a felmérési módszerekkel kapcsolatos egyetértés és a közös látásmód kialakítása érdekében röviden áttekintette a CBA-IPI módszer és a CMM negyedik és ötödik szintjének leírását. A felmérés a CMM kulcs-folyamatterületei mindegyikére kiterjedt, a Szoftveralvállalkozómenedzsment kivételével, mivel ezt a TIS-re nem vonatkozónak ítélték. A korábbi felmérések, melyek a második és a harmadik érettségi szint kulcs-folyamatterületeire irányultak, két hetet vettek igénybe. Ezekben a felmérésekben a team tagjai reggel nyolc órakor kezdték, és olykor éjfél után fejezték be a munkát. Az 1998-as felmérés kiterjedt a negyedik és az ötödik szint kulcs-folyamatterületeire is, a TIS munkaidő-ütemezése miatt mégis egy nappal rövidebbre tervezték. A felmérés hatókörének kiterjesztése és a helyszíni (on-site) felmérési idő lerövidítése kockázattal járt, azonban egy magas érettségi szinten elhelyezkedő szervezet rendelkezik a megfelelő adatokkal, továbbá folyamatai képességének, hatékonyságának bemutatása is elvárható, így a kockázat kezelhetőnek tűnt. A vezetés elvárása volt, hogy a TIS egész szervezetként tekintve bizonyítsa érettségét, s mégis mindkét termékvonal külön-külön kerüljön vizsgálat alá. A felmérés egyik előre meghatározott célja volt, hogy a felmérő team azonosítsa a TIS lehetséges fejlődési területeit, ily módon a TIS a felmérés után a megadott területeken a javaslatok felhasználásával fejlesztheti

folyamatait.

Ennek

érdekében

termékvonalanként

külön

végezték

a

megfigyeléseket a fontosnak illetve veszélyesnek igényelt területeken. A részleg mindkét termékvonalából két-két mintaprojektet választottak ki. Aggodalmakat ébresztett, hogy mindössze négy fókuszprojekt kiválasztása nem teszi lehetővé a felmérő team számára a megfelelő adatgyűjtést. Emiatt a következőképpen jártak el:

54


04.03.17 - a team kilenc projektvezetővel készített csoportos interjút (ezeket „működésterületi képviselők (FAR) ülésének” nevezték), továbbá a fókuszprojektek vezetőivel különkülön is készítettek interjút -

a team minden projektből megkérdezett munkatársakat

-

minden

megkérdezettet

tájékoztattak

a

termékvonalak

külön-külön

történő

vizsgálatáról A felmérést megelőzően 51 CMM-kérdőívet töltöttek ki a TIS alkalmazottai, amelyeket azután a felmérő team kielemzett. A felmérők számára a kérdőívek elemzéséből származó legfontosabb eredmény a kérdéses területek megfelelő folyamatainak és dokumentációinak válaszadók általi megjelölése volt.

10.2 A felméréssel kapcsolatos problémák – külső nézőpontból Külső nézőpontból három probléma látszott fontosnak: -

a menedzsment támogatása a valódi fejlődés iránt

-

a szoftvertechnológiai folyamatcsoport tagjainak lehetséges érdekellentéte

-

a „szervezet” definíciója

A felmérő team tagjai pontosan tudták, hogy a vezetésnek valóban motiváltnak és elkötelezettnek kell lennie a folyamatfejlesztés és a minőségkultúra iránt, nem egyszerűen jó eredmények kimutatására, hanem a valódi képességekre kell összpontosítania. Már a felmérés kezdete előtt nyilvánvalóvá vált az elvárás, mely szerint a TIS-nek mindenképpen jól kell szerepelnie. A felmérés során azonban a TIS minőségkultúrájának bizonyítékai a felmérő team számára meggyőzőek voltak. Mivel az SEPG tagjai a folyamatfejlesztésért felelősek, kedvezőtlen eredmények esetén érdekellentétek léphetnek fel. Emiatt az SEPG tagok az interjúk során folyamatosan cserélgették szerepeiket, s többnyire a megkérdezettek közé tartoztak.

55


04.03.17 Az utolsó problémát a „szervezet” definíciója okozta. Mivel a TIS két termékvonallal rendelkezik, melyekhez egyértelműen megkülönböztethető szervezeti folyamatok tartoznak, így lehetségesnek tűnt, hogy az egyik termékvonalban talált problémák az egész szervezet érettségét kérdőjelezik meg. Lehetséges lett volna a két termékvonal érettségét külön-külön szervezetként vizsgálni (mivel a fejlesztési lehetőségek vizsgálata is külön-külön történt), de a részleg folyamatképességének megismerése érdekében a részleg egészét tekintették szervezetnek, és ennek megfelelően értelmezték a CMM modellt a TIS-re.

10.3 Felkészülés a felmérésre – belső nézőpontból A felmérés előkészítésénél a TIS célként fogalmazta meg azt, hogy a felmérés a lehető legkönnyebben elvégezhető legyen mind a felmérő team tagjai, mind a megkérdezettek számára. A megkérdezettek nézőpontjának vizsgálatakor a TIS a korábbi felmérések eredményeire támaszkodhatott. A felmérők munkájának megkönnyítése érdekében a TIS SEPG áttanulmányozta a korábbi felmérések dokumentumait, megkérdezte a korábbi felmérések SEPG-tagjait. (Az SEPG tagokat rotációs elv alapján jelölték ki, így a korábbi felméréseket végző SEPG-tagok már elhagyták a csoportot.) A TIS minőségtámogatási csoportja (QuEST) egy előfelmérést készített; ez volt az első alkalom, hogy a TIS a CMM negyedik és ötödik szintjén leírt tevékenységei felmérésre kerültek; az eredmények biztosították a TIS-t arról, hogy erőfeszítései hasznosak és kifizetődőek voltak. Az SEPG véleménye szerint amellett, hogy a felmérés a szervezet érettségi szintjének meghatározására szolgált, az is megmutatta, mennyire volt eredményes az SEPG által a felmérésre való felkészülés során a projekteknek nyújtott segítség. Hat hónappal a felmérés előtt az SEPG készített egy magas szintű Gantt-diagramot, melyen megtervezte a felmérés előkészítéséhez szükséges (még hátralévő) tevékenységeket, ily módon csökkentve a szervezeten belüli felkészülés okozta stresszt. Ezek a rendkívül hasznosnak bizonyult tevékenységek segítettek a felmérő teamnek a szervezet érettségének meghatározásában.

56


04.03.17 A TIS akciótervek többnyire a QuEST kifogásaira válaszként adott javasolt változtatásokból, és ezen korrekciós intézkedések megtételére javasolt határidőkből álltak. Az SEPG a felmérésre való felkészülés során a váratlan meglepetések elkerülése érdekében egy táblázatban egymáshoz rendelte a TIS szervezeti szintű folyamatait és a CMM tevékenységeit. Ennek a leképezésnek számos előnye volt: segítségével a folyamatok tisztábban láthatóak lettek, a TIS biztos lehetett benne, hogy a felmérés minden szükséges területre kiterjedt, továbbá az interjúk és a felmérés folyamatának meghatározása során is hasznosnak bizonyult. Már a felmérést megelőzően is nyilvánvaló volt, hogy a felmérő team példákat szeretne látni a TIS tevékenységeire vonatkozóan. A példák biztosítása érdekében az SEPG és a projektvezetők együttműködtek. A megfelelő példák hozzáférhetőségéért a projektvezetők voltak felelősek. Az SEPG azt javasolta, hogy megfelelő kontaktszemélyek megnevezésével és a dokumentációk biztosításával tegyék egyértelművé, hogyan juthat a felmérő team további példákhoz. A TIS dokumentumai a belső hálózat segítségével is elérhetőek voltak a felmérő team számára, de az SEPG a TIS folyamatainak, terveinek és eljárásainak leírását nyomtatott formában is elérhetővé tette. Az interjúk könnyebb lebonyolítása érdekében az SEPG a TIS és a CMM terminológiája között táblázatos leképezést hozott létre. Ezt a leképezést a felmérő team tagjainak meg kellett ismernie ahhoz, hogy az interjúk során a kérdéseket megfelelően tehessék fel, és a kapott válaszokat helyesen értékelhessék ki.

10.4 A helyszíni (on-site) vizsgálat A CMM kulcs-folyamatterületei leírják, hogy egy szervezetnek „mit” kell tennie az érettség felé vezető úton, gyakran példákat is tartalmaz segítségül a célok eléréséhez. Azonban a szervezet felelőssége folyamatainak a célok elérése érdekében történő tervezése. A kulcs-

57


04.03.17 folyamatterületek megértése révén a TIS képessé vált a szervezet szükségleteinek és a CMM elvárásainak megfelelő folyamat-megvalósításra. Négy kétfős miniteam végezte a kulcs-folyamatterületek vizsgálatát, de minden teamtag részt vett az ágazati vezetőkkel, a technikai programmenedzserekkel (TPM), a FAR-okkal folytatott interjúkon, továbbá minden megfigyelés és következtetés a team teljes egyetértésével történt. A felmérő team egyenként kérdezte meg mind a négy fókuszprojekt technikai programmenedzsereit, míg a TIS többi projektjének TPM-jeit egy FAR ülés keretein belül. Az SEPG és QuEST team tagjaival együtt a felmérő team a TIS 67 munkatársával készített interjút a vizsgálat két hete alatt. Az interjúk, a dokumentumok áttanulmányozása és a kérdőívek eredményeként a felmérő team 477 megfigyelési pontot gyűjtött össze a TIS folyamataival kapcsolatban. A következő bekezdések ezek közül vázolnak néhányat.

10.5 A Szoftverprojekt-tervezés A TIS-nél a projektek teamtagjai segítséget nyújtanak a technikai programmenedzserek számára a két termékvonalra vonatkozó becslések elkészítésében, amelyeket azután több formában dokumentálnak. Az érettség növekedésével a becslések pontosabbá válnak és a projekt definiált szoftverfolyamatával összhangban kialakított ütemtervek, dokumentumok elkészítésénél jobban lehet rájuk hagyatkozni. A projekt definiált szoftverfolyamatának dokumentálása az OFP termékvonalra vonatkozóan az OFP fejlesztési útmutatóban (ODG), az ATE termékvonalra vonatkozóan a karbantartás-technikai folyamatleírásban (MEP) történt.

A projektterv számos dokumentum együtteseként állt össze: az ODG és a MEP nem tartalmazta a projektterv alkotóelemeinek részletes leírását. Egy új programmenedzser számára nem volt egyszerű feladat a projekttervezési folyamat megértése és követése. A

58


04.03.17 felmérő team is csak kisebb nehézségek árán tudta megtalálni a projekttervvel kapcsolatos elvárások kielégítésének területeit. Ennek a problémának a megoldása érdekében a felmérő team egy bevezető bekezdés alkalmazását javasolta, amely a termékvonal folyamatai előtt a terv különböző komponenseit és a tervezési szempontokat is leírja. A technikai programmenedzserek a projekt kezdetén a csoportközi tevékenységek megtervezésére projekt-teameket hoztak

létre,

melyek

meghatározott

időközönként

találkoztak a több csoportot érintő témakörök követése és az ilyen jellegű problémák megoldása könnyebbé tételének érdekében. A felmérő team tagjai egyetértettek abban, hogy a TIS projektjei a termékvonali folyamatokat tekintve következetesen az ODG-ben és a MEPben előírtaknak megfelelően dolgoznak. Szintén nyilvánvaló volt, hogy a technikai programmenedzserek számára a tervezéshez és az esetleges helyesbítő tevékenységek előkészítéséhez a szükséges termékvonali információk rendelkezésre álltak.

10.6 A termék- és folyamat-szoftverminőség biztosítása A szoftverminőség-biztosítási (SQA) tevékenységek a QuEST és a konfigurációmenedzsment (CM)

között

kerültek

felosztásra;

a

QuEST

a

folyamat

minőségéért,

míg

a

konfigurációmenedzsment a termék minőségéért vállalt felelősséget. A QuEST a részleg irányelveinek betartásáért volt felelős, továbbá a termékvonal-folyamatokra és –eljárásokra felügyelt, míg a konfigurációmenedzsment a termékek tervezési mintáknak és sablonoknak való megfelelésére koncentrált. A felmérő team mindezt a hagyományos, független, a folyamatokért és a termékekért egyaránt felelős SQA csoport alternatívájaként értékelte, és megfelelőnek találta. A felmérő team örömmel figyelte meg, hogy a projekt tagjai nagyra értékelik a konfigurációmenedzsment fegyelmezett munkáját és a QuEST javaslatait, képzéseit. Az SQA tevékenységek felosztása a CM és a QuEST között, lehetővé tette a QuEST számára a szoftvertechnológiai

tevékenységek

mérésének

és

állapotjelentéseinek

kivitelezését, továbbá a TIS-en belüli informális képzés biztosítását.

59

megfelelő


04.03.17

10.7 Szervezeti folyamatközpontúság – Folyamatfejlesztés Mikor a TIS megkezdte folyamatfejlesztési munkáját, sok független folyamatot létesített. A szervezet érettebbé válásával a részlegen belül két alapvető szoftvertermék-vonalat határozott meg: az OFP-t és az ATE-t; a folyamatok idővel fokozatosan beolvadtak a két termékvonal folyamatai közé (ODG, MEP). A TIS termékvonal-folyamatai a részleg szabványos technikai folyamatából származnak (SEP), melynek kerete alkalmas arra, hogy az egyes termékvonalak erősségeit és változatosságát egyaránt magába foglalja. A felmérő team tagjai könnyedén tájékozódtak a SEP termékvonal-látásmódját tükröző termékvonalak folyamatainak dokumentációiban. A felmérő team a termékvonal-folyamatokat a TIS egyik erősségeként azonosította. Bár a két termékvonal környezete és terminológiája meglehetősen eltérő volt, a felmérő team úgy ítélte meg, hogy a TIS-ben a jelentős folyamat-karbantartási költségcsökkenést okozó termékvonali folyamatlétesítésnek köszönhetően a CMM tevékenységei általánosabbakká váltak. A TIS mérés-lebonyolítási útmutatója (MIG) leírja a költségekkel, ütemtervekkel és a minőséggel kapcsolatos elvégzendő méréseket. Ez rendkívül fontos az egész részlegre kiterjedő következetes és összehasonlítható mérések meghatározásához. A MIG-adatok valódi felhasználása

azonban

az

adott

termékvonalon

belül

történt,

és

néhány

mérés

termékvonalanként eltérően volt definiálva. A felmérő team tagjai egyetértettek abban, hogy a TIS munkatársai elkötelezettek a CMM által elérhető stabil folyamatok iránt és megértették az intézményesítés jelentőségét. A felmérő team olyan környezetben tanulmányozhatta az eljárások, minták és ellenőrző listák alkalmazását, ahol a folyamatfegyelem és a folyamatfejlesztés együttes megvalósítását a sikeres munka alapvető feltételének tekintik. A TIS-en belül a folyamatfejlesztési tevékenységeket projektként kezelik, az eredmények havonta kerülnek prezentálásra. Az SEPG más munkatársakkal szoros együttműködésben

60


04.03.17 azonosítja a folyamatok erősségeit és gyengeségeit. A szervezet bármely tagjának lehetősége van folyamatfejlesztési és technológia-változtatási javaslatok benyújtására.

10.8 Képzések A TIS-nél az új munkatársak betanítása a TIS ODG és MEP folyamataival kapcsolatban többnyire informális „on-the-job” képzés keretében történik. A képzési mátrixok, az elvárt tudásszintet leíró dokumentumok és az egyéni képzési terv segítségével készíthető elő és követhető nyomon a betanítás. A tréningek megvalósításának módját a felmérő team részletesen megvizsgálta. A fenti gyakorlat a részleg képzési szükségleteiért felelős Képzési Bizottság tudatos döntése alapján alakult ki. Nyilvánvaló volt, a TIS stabil munkaerejét képviselő munkatársak rendkívül fontos szerepet játszanak az informális képzések lebonyolításában és sikerében. Ebben az időben azonban a TIS munkaterhelésének és vásárlói körének jelentős bővítésén fáradozott, amely csak igen sok új munkatárs felvételével volt lehetséges. Mindez veszélyt jelentett a TIS folyamatainak stabilitására, de a TIS a bővítést mindenképpen szükségesnek látta és a kockázatokat elfogadhatónak tekintette. A felmérő team úgy ítélte meg, hogy a TIS a CMM képzési követelményeinek eleget tesz.

10.9 Kvantitatív folyamatmenedzsment A

felmérő

team

a

TIS

kvantitatív

folyamatmenedzsment

kulcs-folyamatterülete

tevékenységeinek jóváhagyását tekintette a legnehezebb döntésnek, mivel bár az adatok gyűjtése és felhasználása szerves részét képezte a TIS folyamatainak és kultúrájának, azonban a team észrevette, hogy bizonyos statisztikai eljárásokat nem megfelelően alkalmaznak. A TIS számtalan ellenőrző diagramot alkalmazott a munka során, de az ellenőrzési határok nem mindig a statisztikai alapelvek szerint kerültek kijelölésre, olykor a menedzsment szabta meg a korlátokat.

61


04.03.17 A felmérő team ezeket a problémákat részletesen megvitatta, majd a tagok egyetértésre jutottak abban, hogy bár a folyamatok ellenőrzési módszereivel kapcsolatban találtak néhány hibát, de a döntéshozatal adatok által alátámasztott általános kultúráját elfogadhatónak ítélték, az alkalmazott elemzések megfelelősége más, a CMM szerinti negyedik illetve ötödik érettségi szintű szervezetekével összemérhető volt. Újabb kihívásként várt a TIS-re és a felmérő teamre a folytonos folyamatfejlesztés következtében az érvényességüket rövid idő alatt elveszítő folyamat-adatok kiértékelése. Sok folyamatbeli változás történt a felmérést megelőző néhány hónapban, amelyek a folyamatok előrejelzésének és ellenőrzésének megbízhatóságára hatással voltak. Emiatt a TIS az utóbbi 12 hónap alapján kiértékelt projektek képessége mellett az utóbbi négy hónap átlagát is prezentálta. A projektek minőségügyi céljainak kijelölése a korábbi eredmények alapján történik, felülvizsgálatra negyedévenként kerülnek. A felmérő team úgy ítélte meg, hogy a TIS sikeresen érte el azt a célját, hogy kevesebb hibát tartalmazzanak a felhasználókhoz kerülő termékei; a projektek eredményei tükrözték a megfigyelt folyamatképességet.

10.10 A felmérés eredménye A felmérő team dokumentálta vizsgálatainak eredményét és javaslatait. A TIS munkatársai nagy örömmel értesültek a CMM szerinti ötödik érettségi szint eléréséről, de a dinamikusan változó üzleti környezet kihívásainak való sikeres megfelelés érdekében a folytonos folyamatfejlesztés feladata továbbra is központi szerepet játszik a TIS működésében pld. a következő lépések segítségével: -

a QuEST tevékenységének további tervezése

-

a szervezeti stratégiai terv változtatásai a felmérő team javaslatai alapján

-

a CMMI SW/SE (Capability Maturity Model – Integrated Software / System Engineering) alkalmazási lehetőségeinek vizsgálata

62


04.03.17

63


04.03.17

11. A hazai alkalmazás kérdésköre Amikor 2000-ben, a Kandó Kálmán Műszaki Főiskolát befejezvén a szerző elhatározta, hogy a szoftverfolyamat-fejlesztés és a Képesség-Érettség Modell témaköréből készíti következő szakdolgozatát, sejtette, hogy a modell hazai ismertsége meglehetősen korlátozott. 2003-ra (azaz napjainkra) a szoftverszervezetek minőségügyi vezetőinek többsége már hallott a CMM-ről (és annak jelentősen kibővített „változatáról” a CMMI modellről), annak részleteit azonban nem ismerik. Azok a szervezetek, amelyek hazánkban megkísérelték a CMM alapján fejleszteni szoftverfolyamatukat, nem értek el (legalábbis a CMU SEI által felkészített minőségügyi szakemberek vezetésével lebonyolított felméréssel alátámasztva) CMM szerinti érettségi szintet. Egyedül a Tata Consulting Services indiai anyavállalata rendelkezik CMM 5 szinttel. A korábban CMM 3 szintet célul kitűző Fathom Technology minőségügyi vezetője szerint ennek több oka van: -

költségtényezők

-

a szervezetek még nem ismerték fel az érettségi szint publikálásából eredő marketingelőnyöket

-

hazánkban minden szervezet inkább az ISO minősítések elérésére törekszik

A fentieknek megfelelően a szakdolgozat szerzője nem talált Magyarországon olyan szoftvertechnológiai és/vagy minőségügyi szakembert, akivel érdemben elbeszélgethetett volna

a

Képesség-Érettség

Modell

alkalmazási

lehetőségeiről;

Európát

(beleértve

természetesen Magyarországot is) még nem hódította meg a CMM. Az ISO szabványcsalád „uralma” miatt ez a közeljövőben nem is várható, annak ellenére, hogy (miként az a szakdolgozatból is kiderül) az elért eredmények önmagukért beszélnek.

64


04.03.17

12. A Képesség-Érettség Modell bírálata -

A CMM modell leírásában található példák mennyisége nem elégséges

-

Nem tér ki a modell a kisebb szervezetek érettségi folyamata megvalósításának specialitásaira

-

A CMM szerinti érettségi szintek elérésének feltételei nem pontosan definiáltak

-

Számos szervezet számára a CMM folyamatfejlesztési útja a költségtényezők miatt nem megvalósítható

-

Még a CMM 5 szint elérése sem jelent egyértelmű garanciát a minőségi szoftverek fejlesztésére

-

A modell ismeretlensége miatt sok szervezetben fel sem merül alkalmazásának lehetősége

-

A CMM által lefedett terület szűk (igaz, erre megoldást kínál a CMMI modell)

-

Kvantitatív folyamatmenedzsmentet csak a negyedik szinttől vár el a modell

-

A modell csak a "mit" kérdésre válaszol, a "hogyan" kérdés megválaszolásához kevés segítséget ad

-

Európában a CMM kevésbé ismert, így itt nem halmozódott fel elegendő tapasztalat a modellel kapcsolatban

-

Az emberi tényezőket a CMM nem veszi figyelembe (létezik CMM People modell, amely igen)

65


04.03.17 - Nehéz egyértelműen megállapítani, hogy egy szervezet az adott kulcs-folyamatterület adott célját megvalósította-e

13. Összefoglalás A modernizáció és a globalizáció erősödésével egyre növekszik azon feladatok száma, amelyeknek elvégzését szoftverekre bízzuk, a szoftver mára tömegtermékké vált. Az összetett rendszerek dokumentációja a „tűzoltás” jellegű szoftverfejlesztés miatt felületes és pontatlan. A gyakorlat bebizonyította, hogy bonyolult, sok ember összehangolt munkáját igénylő szoftverrendszereket nem lehet közvetlen kódolással kifejleszteni. A komplexitás növekedése miatt a nagy szoftverrendszerek tervezésének és kivitelezésének koordinálása sokszor megoldhatatlannak tűnő feladat. A szoftverfolyamat-felmérési módszertanok és az azok eredményeként előálló akciótervek az ISO 9000-es szabványsorozatnál jobban támogatják a folyamatok javítását, több segítséget nyújtanak a minőségjavítási prioritások meghatározásához. Az új szoftver-módszertanok és technológiák alkalmazásából adódó produktivitásnövekedésről és minőségjavulásról szóló betartatlan ígéretek évtizedei után a szoftveripar és az Amerikai Egyesült Államok kormányzata ráébredt arra, hogy a legalapvetőbb probléma a szoftverfolyamat menedzselési képességének hiánya. A fejlett módszerek és eszközök előnyeit, fegyelmezetlen szervezésű projektek esetén nem lehet megfelelően kihasználni. Sok szervezet projektjei jelentős késést szenvednek, és eredeti költségvetésüket többszörösen túllépik. Ezekben az esetekben a szervezet többnyire nem biztosította a projektek számára a fenti problémák elkerüléséhez szükséges infrastruktúrát és támogatást. Megbízható és jól használható szoftverek fejlesztése meghatározott idő- és költségkereten belül számos szervezet számára teljesíthetetlen feladat. A későn átadott, költségvetést túllépő, nem megfelelően működő szoftvertermékek a megrendelőnek is problémát jelentenek. A szoftverprojektek méretének és fontosságának növekedésével ezek a problémák még

66


04.03.17 súlyosabbakká válnak, amelyek a hatékony szoftvertechnológiai és menedzsmenttevékenységek folyamat-infrastruktúrájának kiépítésére irányuló koncentrált és hosszan tartó erőfeszítések eredményeként küszöbölhetők ki. Komoly


célok

kitűzéséhez

szükséges

az

érett

és

az

éretlen

szoftverszervezetek közötti különbség megértése. Éretlen szervezet esetén többnyire a menedzsment és a fejlesztők „improvizálják” a projektek folyamán a szoftverfolyamatokat. Ha létezik is meghatározott szoftverfolyamat, azt nem követik, illetve nincs kényszerítő erő a követésére. Az alapvetően csak reagáló jellegű (vagyis éretlen) szoftverszervezetekben a menedzserek az éppen aktuális krízishelyzet megoldására koncentrálnak („tűzoltás”). Egy éretlen szervezetben nincs objektív alap a termék minőségének megítélésére, illetve a termékkel és a folyamatokkal összefüggő problémák megoldására, így a termék minősége nehezen előrejelezhető. Ha a projekt elmarad az ütemtervtől, a minőséget javító tevékenységek (review, tesztelés) háttérbe szorulnak vagy teljesen eltűnnek. Egy érett szervezetben a menedzserek megvizsgálják a szoftvertermékek minőségét és az ügyfelek elégedettségét; létezik objektív, mennyiségi alap a termék minőségének megítéléséhez, valamint a termékkel és a folyamattal kapcsolatos problémák elemzéséhez. Az ütemtervek és a költségvetések reálisak és a korábbi projektek eredményein alapszanak, a meghatározott költségkeretek és határidők betarthatóak, az elvárt funkcionalitás és minőség elérhető. Minden munkatárs tisztában van a folyamat követésének előnyeivel és fontosságával; a folyamat számára szükséges infrastruktúra és támogatás rendelkezésre áll. A folyamatfejlesztési erőfeszítésekből származó hosszútávú eredmények elérése érdekében szükséges egy olyan evolúciós jellegű fejlődési út megtervezése, amely a szervezet szoftverfolyamatának érettségét növeli. A szoftverfolyamat-érettségi keret [Humphrey87a] az érettségi szinteket úgy szervezi, hogy minden szinten a fejlesztések a következő szint fejlesztéseinek alapját képezik. Ily módon, a szoftverfolyamat érettségi keretéből származó fejlesztési stratégia egyfajta „térképet” biztosít a folyamatos fejlesztés számára; segít az előrelépésben és azonosítja a szervezet hiányosságait.

67


04.03.17 A Capability Maturity Model (Képesség-Érettség Modell) a szoftverszervezetek számára útmutatást biztosít a szoftverfejlesztési és karbantartási folyamataik feletti ellenőrzéshez, továbbá a szoftvertechnológiai és a menedzsmentbeli kiválóság megteremtéséhez. A modellt azért hozták létre, hogy segítsen a szoftverszervezeteknek folyamatfejlesztési stratégiájuk kialakításában, a jelenlegi folyamatérettség meghatározásával, továbbá a szoftverminőségre és a folyamatfejlesztésre nézve kritikus tényezők azonosításával. Kevés számú tevékenységre koncentrálva a szervezet folyamatosan képes szoftverfolyamatát fejleszteni, és így komoly hosszútávú eredményeket érhet el a szoftverfolyamat-képesség területén. A CMM kerete meghatározza a hatékony szoftverfolyamat kulcsfontosságú elemeit. A CMM kulcstevékenységei hozzájárulnak ahhoz, hogy a szervezet a tervezés, a fejlesztés és a karbantartás során elérje a költségekre, ütemezésre, funkcionalitásra és minőségre vonatkozó céljait. A Carnegie Mellon Egyetem Szoftvertechnológiai intézetébe Watts Humphrey vitte magával az érettségi keret koncepcióját, majd ott éveken át fejlesztette, finomította a modellt. A CMM mindmáig meghatározó szerepet játszik a szoftverfolyamat-felmérés és –fejlesztés területén. Az Humphrey és munkatársai munkájának eredménye a 18 kulcs-folyamatterületet öt érettségi

szintre

felosztó

modell.

A

kulcs-folyamatterületek

az

őket

alkotó

kulcstevékenységekkel jó megközelítést adnak a teljes szoftverfolyamat lefedéséhez. A megközelítés Crosby munkájával ellentétben nem a kulcs-folyamatterületek érettségét, hanem az egész szervezet szoftverkészítési érettségét méri. Ennek eredményeképpen kielégítő választ lehet adni a folyamatjavítás lehetséges irányai közötti prioritásokra vonatkozó döntési problémákra. A folytonos folyamatfejlesztés a legtöbb esetben nem forradalmi újításokból áll, hanem apróbb lépések sorozata. A CMM keretet biztosít ezeknek a lépéseknek öt érettségi szintbe történő szervezéséhez, amelyek a fokozatos folyamatfejlesztés alapjait jelentik. Ez az öt érettségi szint meghatároz egy skálát, a szervezet szoftverfolyamatának méréséhez és a szoftverfolyamat-képességének felméréséhez, továbbá segítséget nyújt a szervezet fejlesztési erőfeszítései sorrendiségének meghatározásához.

68


04.03.17

69


04.03.17

Irodalomjegyzék 1. [Angster (1999)]: Angster Erzsébet; Az objektum-orientált tervezés és programozás alapjai; Akadémiai Nyomda, Martonvásár, 1999, 3. oldal 2. [Boehm (1988)]: B. Boehm; Software Engineering Economics (Szoftvertechnológiai gazdaságtan); Prentice Hall, Englewood Cliffs, NY, 1988 3. [Crosby (1979)]: P. B. Crosby; Quality is Free (Minőség díjmentesen); McGraw-Hill, New York, NY, 1979 4. [Deming (1986)]: W. E. Deming; Out of the Crisis (Kitörés a krízishelyzetből); MIT Center for Advanced Engineering Study, Cambridge, MA, 1986 5. [Fowler (1990)]: P. Fowler, S Rifkin; Software Engineering Process Group Guide (Szoftvertechnológiai folyamatcsoport útmutató); CMU/SEI- 90-TR-24, ADA235784, Sept 1990 6. [Humphrey (1987)]: W. S. Humphrey; Characterizing the Software Process: A Maturity Framework (A szoftverfolyamat leírása: az érettségi keret); CMU/SEI-87TR-11, ADA182895, June 1987 7. [Juran (1988)]: J. M. Juran; Juran on Planning for Quality (Juran minőségtervezése), Macmillan, New York, NY, 1998 8. [Juran (1989)]: J. M. Juran; Juran on Leadership for Quality (Juran minőségközpontú vezetése); The Free Press, New York, NY, 1989 9. [Paulk (1993)]: M. C. Paulk és társai; Key Practices of The Capability Maturity Model (A Képesség-Érettség Modell kulcstevékenységei); CMU/SEI-93-TR-25, Febr 1993 10. [Putman (1999)]: D. Putman, M. C. Paulk; Assessing a Level 5 Organization (Az ötödik szintű szervezet elérése); Crosstalk: The Journal of Defense Software Engineering, Vol. 12, No. 5, May 1999 11. [Radice (1985)]: R. A. Radice és társai; A Programming Process Study (Programozási folyamat - tanulmány); IBM Systems Journal, Vol 24., No. 2, 1985 12. [Siegel (1990)]: J. A. L. Siegel és társai; National Software Capacity: Near-Term Study (Nemzeti szoftverképesség), CMU/SEI-90-TR-12, ADA226694, May 1990 13. [Tóth (1999)]: Tóth Tibor; Minőségmenedzsment és informatika, Műszaki Könyvkiadó, Budapest, 1999, 361-373 oldalak (Bíró Miklós: Szoftverminőség)

70


04.03.17 14. [Vég (1999)]: Vég Csaba; Alkalmazásfejlesztés az Unified Modeling Language szabványos jelöléseivel; Logos 2000, Debrecen, 1999, 7. oldal 15. [Willis (1998)]: R. R. Willis és társai: Hughes Aircraft’s Widespread Deployment of a Continously Improving Software Process (A Hughes Aircraft folytonosan fejlőső szoftverfolyamatának széleskörű létesítése); CMU/SEI-98-TR-006, May 1998

71


04.03.17

Melléklet: 1. ábra

A CMM érettségi szintjei Optimalizált Folyamatváltozás-menedzsment Technológiai változásmenedzsment Hibamegelőzés

Menedzselt Kvantitatív folyamatmenedzsment Szoftverminőség-menedzsment

Meghatározott Szervezeti folyamat meghatározása Szervezeti folyamatközpontúság Képzési program Integrált szoftvermenedzsment Szoftvertermék-technológia Csoportközi együttműködés Vizsgálati szemlék

Ismételhető Szoftverkonfiguráció-menedzsment Szoftverminőség-biztosítás Szoftveralvállalkozó-menedzsment Szoftverprojekt-követés Szoftverprojekt-tervezés Követelménymenedzsment

Kezdeti 72

A SZOFTVERFEJLESZTÉSI FOLYAMAT MINŐSÉGÜGYI VIZSGÁLATA; A CMM (CAPABILITY MATURITY MODEL)

Recommend Documents