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

Átírás

1 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

2 Budapest, 2003 Készítette: Halász József 3

3 Tartalomjegyzék 1. Szoftverkrízis és szoftverminőség Szoftverfolyamat-modellek Vízesésmodell Spirálmodell Evolúciós modell A folyamatérettségi keret Éretlen és érett szoftverszervezetek A folyamatérettség alapvető fogalmai A Capability Maturity Model áttekintése A szoftverfolyamat-érettség öt szintje Az érettségi szintek jellemzői A kezdeti szint (1) A megismételhető szint (2) A definiált szint (3) A menedzselt szint (4) Az optimalizáló szint (5) Betekintés a szoftverfolyamatba A folyamatképesség és a teljesítmény előrejelzése Érettségi szintek kihagyása A CMM műszaki definíciója Az érettségi szintek belső szerkezete Az érettségi szintek Kulcsfolyamat-területek A kulcs-folyamatterületek részletes céljai Általános jellemzők Kulcstevékenységek A CMM felhasználása A szoftverfolyamat-felmérés és a szoftverképesség-kiértékelés A szervezetben betöltött szerepkörök Szervezeti struktúra Külföldi tapasztalatok Hughes Aircraft Co A Fejlesztési paradigma A folyamat eredményességének bizonyítékai A CSWP vállalati-szintű alkalmazása A fejlesztési tervek folytatása Pozitív hatások A vállalat leírása A Hughes szoftverfolyamatának fejlesztése A megrendelők elégedettsége Innovációk Az ötödik szint elérése - ALC Felkészülés a felmérésre

4 10.2 A felméréssel kapcsolatos problémák külső nézőpontból Felkészülés a felmérésre belső nézőpontból A helyszíni (on-site) vizsgálat A Szoftverprojekt-tervezés A termék- és folyamat-szoftverminőség biztosítása Szervezeti folyamatközpontúság Folyamatfejlesztés Képzések Kvantitatív folyamatmenedzsment A felmérés eredménye A hazai alkalmazás kérdésköre A Képesség-Érettség Modell bírálata Összefoglalás...61 Irodalomjegyzék Melléklet

5 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

6 - 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

7 - 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

8 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 ú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

9 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

10 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 fejlődés csak a hatékony szoftvertechnológiai és menedzsment-tevékenységek felé irányuló koncentrált és kitartó 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

11 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

12 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 keret a következő fogalmak segítségével épül fel: szoftverfolyamat, szoftverfolyamat-képesség, szoftverfolyamat-teljesítmény, szoftverfolyamat-érettség. 13

13 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

14 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

15 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 az őket alkotó 16

16 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

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

18 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 a szoftvertechnológiai, mind 19

19 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

20 é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

21 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

22 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

23 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 korai felfedezése hozzájárul a projekt stabilitásához és teljesítményéhez. Érett szoftverfolyamat esetén a 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 É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

24 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

25 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

26 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

27 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

28 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 (Integrated Software Management) célja a szoftvertechnológiai és menedzsment-tevékenységek olyan koherens, 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

29 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

30 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

31 - 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

32 - 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

33 - 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