INFORMÁCIÓS RENDSZEREK

INFORMÁCIÓS RENDSZEREK Szoftver minőségbiztosítás témakör jegyzet (V.03. / 2015-06-01) Készítette: Dr. Horváth Zsolt László

Tartalomjegyzék Tartalomjegyzék... 2 0 Miről lesz szó ebben a tárgyban?... 4 1 Minőségirányítás a szoftverfejlesztésben... 5 1.1 A szoftverfejlesztési projekt... 5 1.2 Ellenőrzési tevékenységek a szoftverfejlesztésben... 7 1.2.1 A review (dokumentumszemle)... 7 1.2.2 A tesztelés... 8 1.2.3 Hibák kezelése, életciklusa... 8 1.3 A konfiguráció menedzsment... 9 1.4 Folyamatmenedzsment alapelvek a szoftverfejlesztésben... 9 1.5 Ellenőrző kérdések...10 2 Szoftverfejlesztési általános módszertanok...12 2.1 SW fejlesztési metodikák, módszertanok...12 2.1.1 Áttekintés a módszerekről... 12 2.1.2 A vízesés modell... 12 2.1.3 A V-Modell alap-felépítése... 13 2.1.4 Agilis szoftver projektvezetés... 13 2.1.5 A SPICE... 15 2.2 A CMMI módszertan...16 2.2.1 Általános áttekintés a CMMI-ről... 16 2.2.2 CMMI modell ábrázolása... 17 2.2.3 A CMMI egyes verzióinak jellegzetességei... 20 2.2.4 A CMMI V.1.2 jellemzése... 21 2.2.5 A CMMI V.1.3 kulcsfolyamatok (változások)... 23 2.3 Ellenőrző kérdések...25 3 Követelménykezelés a szoftverfejlesztésben...26 3.1 Követelménykezelési alapelvek...26 3.1.1 Meghatározások... 26 3.1.2 A követelménykezelés feladatai... 26 3.1.3 A követelménykezelés lépései... 27 3.1.4 Tervezés több szinten... 27 3.1.5 Ellenőrzési relációk a V-modellben... 28 3.2 Példák különböző rendszerek vizsgálati szempontjaira...29 3.2.1 Vizsgálati szempontok biztonságkritikus rendszerekre... 29 3.2.2 Vizsgálati szempontok IEEE 830:1998 szabvány alapján... 29 3.2.3 Vizsgálati szempontok reaktív (irányítástechnikai) rendszerekre... 30 3.3 A követelménykezelés problémái...30 3.4 Követelménykezelés a CMMI-ben...31 3.5 Ellenőrző kérdések...31 4 Tesztelés a szoftverfejlesztésben...32 4.1 A tesztelés életciklusa...32 4.1.1 Tesztelés célja... 32 4.1.2 Tesztelés objektuma... 32 4.1.3 Tesztelés helye a fejlesztési folyamatban... 33 4.1.4 Hogyan tesztelünk? Tesztelések csoportosítása... 34 4.1.5 Tesztesetek meghatározása... 35 4.1.6 Hány teszteset futtatása szükséges?... 36 Dr. Horváth Zsolt László 2

4.1.7 Tesztek végrehajtása... 36 4.1.8 Tesztek kiértékelése... 36 4.1.9 Tesztelés sikerkritériumai... 37 4.1.10 Tesztelési toolok... 38 4.2 Különleges kód-ellenőrzések...38 4.3 Ellenőrző kérdések...38 5 Tooling használata a szoftverfejlesztésben...39 5.1 Tool-ok használata...39 5.2 Példák különböző kategóriájú tool-okra...39 5.2.1 Modellező toolok... 39 5.2.2 Verziókezelő tool-ok... 40 5.2.3 Feladat követő tool-ok... 41 5.2.4 Statikus kódanalízis toolok... 43 5.3 Ellenőrző kérdések...43 6 Metrikák használata a szoftverfejlesztésben...44 6.1 Metrikák célja, alkalmazása...44 6.1.1 Metrikák (mérőszámok) meghatározása... 44 6.1.2 Problémák. Miért nem működnek sokszor a metrikák?... 44 6.1.3 Metrikák bevezetésének sikertényezői... 44 6.1.4 Egy metrika alkalmazási folyamatának szereplői... 44 6.1.5 A megfelelő metrikák kiválasztásának kritériumai... 45 6.2 Példák metrikákra...45 6.2.1 A metrikák csoportosítása... 45 6.2.2 Projektmetrikák példák... 45 6.2.3 Kódmetrikák példák... 48 6.3 Ellenőrző kérdések...50 Dr. Horváth Zsolt László 3

0 Miről lesz szó ebben a tárgyban? A tantárgy ezen részének a célja: Áttekintés és alapismeretek a szoftverfejlesztés során a szoftver minőségbiztosítási kérdéseiről, azok jelentőségének és gyakorlati alkalmazásának bemutatásáról. Az előadások a következő témaköröket tárgyalják: Minőségirányítás és a szoftverfejlesztésben Szoftverfejlesztési általános módszertanok Követelménykezelés a szoftverfejlesztésben Tesztelés a szoftverfejlesztésben Tooling használata a szoftverfejlesztésben Metrikák használata a szoftverfejlesztésben Előadások törzsanyaga elérhető jegyzetben! Előadásokon további példák, magyarázatok. Jegyzet: www.uni-obuda.hu/users/horvath.zsolt.laszlo ftp site-on. Előadó érhetőségei: - Név: Dr. Horváth Zsolt László, ÓE KVK MAI - E-Mail: horvath.zsoltlaszlo@kvk.uni-obuda.hu - Tel: +36 70 4198599 - Munkahely: KVK Tavaszmező u. C épület, 410-es szoba Dr. Horváth Zsolt László 4

1 Minőségirányítás a szoftverfejlesztésben 1.1 A szoftverfejlesztési projekt A szoftverfejlesztési projekt-team szereplői: - projektvezető - projektasszisztens - minőségbiztosítási felelős - konfiguráció menedzsmentért felelős - fejlesztők - tesztelők A szoftverfejlesztési projekt fázisai: - kezdeményezés pozitív projektdöntés esetén: o definíció o tervezés o megvalósítás o bevezetés (üzembe helyezés) - lezárás A szoftverfejlesztési projekt fázisaira mindegyik metodika strukturáltan előírja az adott fázishoz tartozó: - bemeneteket (inputokat) - tevékenységeket - eredményeket - kapcsolódó feljegyzéseket mind a technikai (szakmai), mind a projektvezetési valamint mind a minőségbiztosítási nézőpontból. PÉLDA: Az egyes fázisokhoz tartozó tevékenységek, eredmények és feljegyzések egy általános (nagyobb) szoftverfejlesztési projekt esetén, például a következők lehetnek: Fázis Tevékenység Eredmény Feljegyzés Kezdeményezés Tenderkiírás / ajánlatkérés megvalósíthatóságának (technikai) vizsgálata Erőforrás-becslés Durva projekttervezés (erőforrások felhasználási terve, megvalósítási időterv, kockázatok, pénzügyi, ) Ajánlat elkészítése, ellenőrzése, kiküldése Döntés a továbblépésről Becsült ráfordítás-igény Durva projektterv (mibe ugrunk bele, ha ) Ajánlat Technikai feljegyzések Számítások feljegyzései, alapadatok, egyeztetések jegyzőkönyvei, Ajánlatot készítő és ellenőrző aláírásai legalább Dr. Horváth Zsolt László 5

Fázis Tevékenység Eredmény Feljegyzés Definíció Az ügyfél követelményeinek pontosítása, majd az alapján a termék funkcionalitásának részletes tervezése, és annak ellenőrzése A rendszer-tesztelés megtervezése Konfiguráció menedzsment terv előkészítése. Specifikáció, ami a termék minden funkcionalitását, szolgáltatását részletesen leírja (R-Spec, F-Spec vagy logikai rendszerterv) Tesztelési terv, ami tartalmazza a rendszer teszt-stratégiát, teszteseteket, és a lefolytatás körülményeit, elfogadási kritériumokat, Specifikáció ellenőrzésének (review-jának) feljegyzései, ami igazolja mind a validálást, mind a verifikálást. Tesztelési terv (rendszerteszthez) ellenőrzésének feljegyzései, Durva konfiguráció menedzsment terv. Tervezés A termék struktúrájának, működési algoritmusának megtervezése, és annak ellenőrzése A kapcsolódó tesztelés megtervezése, specifikálása. A konfiguráció menedzsment rendszer megtervezése Specifikáció, amely részletesen tartalmazza a termék struktúráját, belső felépítését, működési elvét, valamint a megvalósítási eszközöket és lépéseket. (D-Spec, vagy fizikai rendszerterv) Specifikáció ellenőrzésének (review-jának) feljegyzései, ami igazolja mind a validálást, mind a verifikálást. Konfiguráció menedzsment terv ellenőrzésének feljegyzései, Tesztelési terv integrációs teszthez. Konfiguráció menedzsment terv (és rendszer és eszköz) Tesztelési terv (integrációs teszthez) ellenőrzésének feljegyzései, Megvalósítás Implementálás - Kódolás - Modulteszt végrehajtása - Dokumentáció elkészítése Illesztés meglévő (vásárolt vagy újra felhasznált) modulokhoz Integráció és tesztelés - Integráció, önálló termékkomponensek összeállítása - Integrációs teszt végrehajtása - Produkció (release) legyártása - Rendszerteszt végrehajtása Ellenőrzött és jóváhagyott: - termék - termékdokumentáció Termék bevezetési terv (SW-)Technikai feljegyzések, specifikációk Aktualizált tervek (projekt terv, minőségterv, CM-terv, tesztelési terv) CM rendszer bejegyzései, tesztelési jegyzőkönyvek, hibák életciklus dokumentációja, Átadás előkészítése Dr. Horváth Zsolt László 6

Fázis Tevékenység Eredmény Feljegyzés Bevezetés Próbaüzem (pilotálás) Éles-üzembe helyezés + kapcsolódó képzések, betanítások Éles-üzemi karbantartás Termék használatának támogatása Hibajavítás Változások kezelése Bevezetett, átadott és működő termék Próbaüzemi és átadási tesztek tervei és jegyzőkönyvei Átadás-átvételi jegyzőkönyv Karbantartási megállapodás és tervek Lezárás Projektek lezáró értékelése Projektdokumentumok archiválása Projektzáró jelentés (értékelések, statisztikák, tapasztalatok) Lezárt projektmappa 1.2 Ellenőrzési tevékenységek a szoftverfejlesztésben A SW-fejlesztés életciklusa során a résztermékek megfelelőségét mérni (ellenőrizni) kell! Az egyes eredménytermékek jellemző mérési módszerei: Résztermékek Ajánlat, szerződés Projekttervek (inc. minőségtervek, CM-tervek, tesztelési tervek, ) Ügyfél igények (requirements) Specifikációk (funkcionalitás specifikáció, design specifikáció,..) Forráskód Termék leírás Lefordított modulok, komponensek Teljes futtatható termék Ellenőrzési módszer Review (dokumentum szemle) Tesztelés 1.2.1 A review (dokumentumszemle) A review fogalma: A review szisztematikus, kritikus, dokumentált ellenőrzési eljárás. A review tárgya: - dokumentum (= adathordozón rögzített információ) - termék-dokumentum (pl. forrás kód, felhasználói kézikönyv,...) - kísérő- v. munka-dokumentum (pl. Functional specification, vagy teszt-terv,...) > külön értelmezünk a kód review -t és a dokumentum review -t. A review célja: hibát találni, (és nem bűnbakot)...... magában a dokumentumban, illetve... abban az eljárás-specifikációban, aminek alapján készítették. A review haszna A hibás megvalósítás korai felismerése, mind...... a validálás, mind ( ez az, ami kell? ) Dr. Horváth Zsolt László 7

... a verifikálás tekintetében ( ilyennek kell ennek lennie? ) Olyan hiányosságok megtalálása, amelyek a teszt (üzemeltetés) során nem jönnének elő, csak a karbantartásnál vagy a továbbfejlesztésnél, pl. : - rosszul strukturált, bonyolultan felépített, nehezen átlátható kód, - rosszul dokumentált programrész, rosszul kommentált forráskód. Bizonylatolt minőségbiztosítási eljárás (pl. ISO 9001 szerint), amivel a termék minőségét igazolni tudjuk, és aminek alapján tovább lehet javítani magát a fejlesztési eljárást is. A know-how elterjesztése, tapasztalatcsere, egységes szemlélet. 1.2.2 A tesztelés A tesztelés fogalma: - egy (vagy több) futtatható állapotban levő szoftver komponens - meghatározott feltételek mellett (adat, esemény) történő futtatása, - és a működés eredményének értékelése (elvárt viselkedésnek megfelel vagy nem). A tesztelés célja: - egy rendszer-komponens (szükséges mértékig) hibátlan állapotának igazolása; - egy tesztelhető objektum létrehozása, amivel különféle vizsgálat végezhető; - az elvárt rendszertulajdonságoktól való eltérés (nagyságának) kimutatása; - a rendszer minőségéről információ a vezetőség felé (továbbfelhasználás...); - a rendszer validálása: megfelel-e az eredeti felhasználói kívánságoknak; A teszteket csoportosíthatjuk a tesztobjektum teljessége szerint: komponens teszt stand alone teszt integrációs teszt több, együttműködő komponens összetett vizsgálata rendszer teszt ( systemtest ) a teljes termék, átadásra kész állapotban a teszt célja szerint (példák): átadási teszt a felhasználónak üzemi használatra történő átadás előtt regressziós teszt annak igazolására, hogy módosítás továbbfejlesztés esetén a korábbi funkciók változatlanul helyesen működnek performance (stressz) teszt nagy terhelés szimulálására stb vagy más módon. 1.2.3 Hibák kezelése, életciklusa A különböző tesztelésekkor megtalált hibák kezelésével szembeni követelmények: Hibák (dokumentált) nyomon követése egységes segédeszközben biztosított legyen, ahol - folyamatosan nyomon követhető minden egyes hiba aktuális állapota (státusza), és múltja, és - amelyik biztosítja minden fontos hiba kijavításának kikényszerítését. A hiba kijavításának ellenőrzése vonatkozik: a megállapított hibás funkcióra, valamint arra, hogy nem került-e a módosítással újabb hiba a rendszerbe! (regresszió tesztelés) Dr. Horváth Zsolt László 8

Tesztelési program közben ne változtassunk a tesztelés objektumán! 1.3 A konfiguráció menedzsment Konfiguráció a rendszerfejlesztés során: - tartalmilag: olyan összetett rendszerről van szó, ahol az egyes összetevők is (részegységek, alkatrészek) folyamatosan módosulnak, fejlődnek (életciklus). A verziószámok nyilvántartása a verziókövetés elkerülhetetlen! - termék esetén: a konfiguráció az a tevékenység, amikor egy adott verziójú, konkrét végtermékhez meghatározzuk az oda beépülő részegységek verzióit A konfiguráció menedzsment csoport tevékenysége: Mindaz a szervező és operatív tevékenység, ami biztosítja a fenti cél teljesülését. - a megfelelő (számítógépes) nyilvántartási rendszer kialakítása - a folyamatok, a szervezet és a munkakörök kialakítása - megfelelő tool-ok érdemi használatának biztosítása és kikényszerítése - az előírásoknak megfelelő folyamatos üzemvitel A konfiguráció menedzsment feladatai: - A számítástechnikai jellegű feladatok: az objektumok verzióinak nyilvántartása; a megfelelő adattárolási biztonság megtervezése az egyes verziók sajátosságainak nyilvántartása (címkézés: ki, mikor, miért, hogyan módosított) a nyilvántartott objektumok közötti kapcsolatok és függőségek kezelése ezáltal megoldható az automatikus szoftverprodukció az egyes objektum(változat)okhoz való hozzáférési jogosultságok kezelése A projektvezetést támogató feladatok: a hibafelismerés és javítás folyamatának, valamint a változtatási igényeknek a támogatása a csoportmunka támogatása; egyszerre többen ugyanazon rendszer különböző részét fejleszthetik 1.4 Folyamatmenedzsment alapelvek a szoftverfejlesztésben Dr. Horváth Zsolt László 9

Folyamatok és alkalmazásuk legyen: Alkalmas - A definiált folyamatok és azok alkalmazása (a megvalósulás a gyakorlatban) kielégítik a résztvevő érdekelt felek elvárásait. - A célok eléréséhez az optimális (legmegfelelőbb) módszer kiválasztása, körülményekhez és helyzethez igazodó testre szabási kritériumok szerint Módszeres módszertan szerinti - Tervezett, végrehajtott, ellenőrzött - folyamatosan - Tevékenység végzése és ellenőrzése a módszertan előírásai szerint - Módszer alkalmazása minden tevékenységre, a folyamat teljes életciklusában Következetes - Tevékenység végzése mindig ugyanolyan módon illetve szemlélet / előírások szerint - Segédeszközök, sablonok, tool-ok használata Dokumentált - A dokumentáltság fogalmába beleértendő minden, ami az összes érdekelt releváns fél számára hozzáférhető információkat biztosít, beleértve egyidejűleg a vonatkozó speciális követelmények (pl. törvényi előírások, különleges ügyfél általi elvárások, stb.) teljesítését is. - Az információhordozó médium bármi alkalmasan megválasztott lehet. Ellenőrzött - A folyamat eredményeinek és végrehajtási módja megfelelésének a folyamatos ellenőrzése - Megfelelő folyamatmutatók mérése, célértékek kitűzése és tartása Javított továbbfejlesztett - A mérések és tapasztalatok visszacsatolása az intézményesített folyamat fejlesztésébe - Tapasztalatok, tudás gyűjtésének és feldolgozásának bevezetett módszerei működnek rendszeresen - Rendszerezett eredményeken (adatbázisokon) alapuló tanuló szervezet 1.5 Ellenőrző kérdések - Mutassa be egy szoftverfejlesztési projekt jellemző szereplőit, és azok fő feladatait! - Mutassa be egy szoftverfejlesztési projekt kezdeményezési fázisának fő tevékenységeit és eredmény-termékeit! - Mutassa be egy szoftverfejlesztési projekt definíciós fázisának fő tevékenységeit és eredmény-termékeit! - Mutassa be egy szoftverfejlesztési projekt megvalósítási fázisának fő tevékenységeit és eredmény-termékeit! - Mutassa be egy szoftverfejlesztési projekt tervezési fázisának fő tevékenységeit és eredmény-termékeit! - Mutassa be egy szoftverfejlesztési projekt bevezetési fázisának fő tevékenységeit és eredmény-termékeit! - Mutassa be egy szoftverfejlesztési projekt lezárási fázisának fő tevékenységeit és eredmény-termékeit! Dr. Horváth Zsolt László 10

- Milyen ellenőrzési tevékenységeket ismer a szoftverfejlesztés során, jellemezze röviden őket! - Mi a review célja, és használati területei a szoftverfejlesztési projekt során? - Mutassa be a tesztelés célját a szoftverfejlesztési projekt során, valamint mutassa be, hogy hogyan csoportosíthatóak a különböző tesztelések! - Melyek a konfiguráció menedzsment feladatai a szoftverfejlesztési projekt során? - Mikor milyen kritériumok alapján mondhatjuk azt, hogy a folyamatok hatékonyan bevezetetten, magas szinten működnek? Dr. Horváth Zsolt László 11

2 Szoftverfejlesztési általános módszertanok 2.1 SW fejlesztési metodikák, módszertanok 2.1.1 Áttekintés a módszerekről Általános módszerek, modellek SSADM Vízesés modell V-Modell Agilis módszertanok (XP, TDD, Scrum, ) SPICE (spec területen: Automotive SPICE) CMMI Gyártó-, termék-, fejlesztőcég- specifikus módszerek Nagyobb fejlesztői környezethez készített, gyártói keretrendszerek, módszerek (RATIONAL RUP, vagy MS fejlesztői környezetbe ágyazott módszerek) Ábrázolással, logikai modellel kapcsolatos módszerek (pl. UML, XML-hez kötött modellek) Multik saját módszertanai (pl. SIEMENS CHESTRA, SEM, SEPP, ) 2.1.2 A vízesés modell - Előnyök: o Jól áttekinthető, könnyen érthető o Jól strukturált o Feladatok jól megoszthatók o Időben tervezhető - Hátrányok: o Merev, nem rugalmas (a folyamat ideje alatt új igények merülhetnek fel, melyeket a modell elutasít) o Ha a hiba későn derül ki, akkor drága a javítás (a megvalósítási fázisban felfedezett tervezési hibákat (elvileg) nem lehet visszadobni) o Nagyon pontos specifikációt igényel, és ez sokszor az elején nem ismert (nem mindig tudja az ügyfél, hogy pontosan mit is akar ) o A megrendelő csak a legvégén látja az eredményt (nincs ízelítő; a termék a folyamat végén jelenik meg) o Elnyúló (a fejlesztő elfelejti egy-egy fázis sajátosságait, mire újra találkozik velük) o Becslésre nem keletkezik mérési adat. Dr. Horváth Zsolt László 12

2.1.3 A V-Modell alap-felépítése A V-Modell lényege, hogy (jellemzően a vízesés modell szerinti folyamatmodell során) a tervezés (specifikációk készítése) minden szintjéhez tartozik egy-egy tesztelési fázis, ami annak a szintnek a megtervezett (specifikált) megfelelő működését ellenőrzi. Ezen tesztfázisok tesztelései tervezésének az alapját mindig az annak megfeleltetett tervezési szint, a megfelelő specifikáció képezi, abból levezetve készülnek a megfelelő tesztelési tervek. 2.1.4 Agilis szoftver projektvezetés Agilitás: olyan adottság, amely egyaránt képes létrehozni és reagálni a változasokra és ezzel előnyt szerezni egy turbulens üzleti környezetben Agilis szoftverfejlesztési projektvezetés ismérvei: Adaptív (alkalmazkodó) nincs hosszú távú tervezés, hanem rövid távon probléma megoldás de az szigorúan Együttműködés a megrendelővel követelmény változásokkal Változásokra való gyors reagálás Feladatok alábontása részfeladatokra Rövid ciklusok tervezése azok szigorú tartása Egyén (tudás és motiváció), és személyes kommunikáció jelentősége SCRUM mint az egyik legelterjedtebb agilis szoftverfejlesztési módszertan Dr. Horváth Zsolt László 13

Agile manifesto: SCRUM mint az egyik legelterjedtebb agilis szoftverfejlesztési módszertan Scrum elemek: Kiemelt szerepkörök a Scrum-ban: o o o Product owner (PO) Felelős a termék elkészüléséért. Meghatározza a termék tulajdonságait (features). Priorizálja a feladatokat. Egyeztet minden érintettel, de ő dönt. A sprintek elején és végén feltétlenül találkozik a csapattal. Csapat 7±2 tag átfogó szaktudással. Önszervező, független és felelős csapat. A munka becslésében felelős. Megegyezik a munkamennyiségről, és törekszik ezt teljesíteni. Demo keretében adja át a munkát. Scrum master (SM) Ő ismeri a folyamatokat, amiket betartat. Tanítja a PO-t, a csapatot és egyéb érintetteket. Megvédi a csapatot a külső behatásoktól. Elhárítja az akadályokat. Megszervezi a scrum eseményeket. Közvetítő és képviselő a menedzsment és csapat között Dr. Horváth Zsolt László 14

A Scrum életciklusa 2.1.5 A SPICE - SPICE = Software Process Improvement and Capability Evaluation - ISO/IEC 15504:2004 Information Technology. Process Assessment - Egyes szakmai területeken még tovább él (pl. autóipar) A SPICE képességi szintjei: Dr. Horváth Zsolt László 15

2.2 A CMMI módszertan 2.2.1 Általános áttekintés a CMMI-ről Mire használható a CMMI? A CMMI a szoftver-előállítási folyamatok képességének - felmérésére - javítására - fejlesztésére - szinten tartására - önértékelésére - benchmarkingra, - marketingre szolgáló modell, illetve módszertan. A CMMI kialakulása és fejlődése - Értékelési kérdőív (módszer) kidolgozása szoftverfejlesztő vállalatok számára (1987) - Ezt a módszert az USA-ban a Carnegie Mellon Egyetem Software Engineering Institute (SEI) intézete dolgozta ki (1991) - Referenciamodell a később ez alapján levezetett modellek számára, pl.: Bootstrap- Assessment (európai értékelési módszer) (1992) - Először csak szoftver folyamat értékelése (SW-CMM), majd kibővül általános folyamatmodell értékeléssel (SW-A-CMM, SE-CMM, People-CMM) (1995) - CMMI V1.0 (2001) CMMI = {SW CMM + SE CMM + IPPD + SS} - CMMI V1.1 (2003) - CMMI V1.2 DEV (2006) - CMMI V1.3 DEV (2010) A (SW)-CMM érettségi szintjei Dr. Horváth Zsolt László 16

2.2.2 CMMI modell ábrázolása A szervezet választhat a fejlesztési folyamat irányultsága, fókusza szerint. A CMMI modell ábrázolási lehetőségei két gondolkodásmódot támogatnak: Folyamatok képessége folyamatos ábrázolás, Az egyes folyamatok fejlesztése egymástól függetlenül, de ugyanolyan út mentén történik. A szervezet saját igényei szerint határozza meg az egyes folyamataiban megcélzott képességi szintet. Szervezeti érettség lépcsőzetes ábrázolás A szervezet egészét vizsgálja és fejleszti. Az egyes folyamatok fejlesztése szintenként egyszerre, ugyanazon az úton történik. A megkövetelt folyamatok köre szintről szintre bővül. A FOLYAMATOS ÁBRÁZOLÁS A folyamatoknak kétféle követelményeket kell teljesíteniük, az általános célok és hozzájuk kapcsolódó általános tevékenységek a folyamatmenedzsment követelményeket határozzák meg, és ezen keresztül az adott folyamat érettségi szintjét, a speciális célok és a speciális tevékenységek pedig az adott folyamat saját, szakmai követelményeit. A folyamatok jellemzése, képessége Az éretlen folyamat jellemzői - A folyamat ad hoc jellegű, és jellemző az alapvető improvizálás (fejlesztők és menedzserek részéről). - Az eljárási előírásokat amennyiben vannak nem követik. - Egyes személyektől (guruktól) való erős függőség. - A termék minősége előre csak nehezen jelezhető. - Hiányok a termék minőségében és funkcionalitásában a határidő tartása érdekében, vagy határidőcsúszások. - Új technológiák alkalmazása kockázatos. - Stressz alatt a felsőbb szintű előírásokat és irányelveket, mint fölösleges ballasztot figyelmen kívül hagyják. Az érett folyamat jellemzői - Standardizált folyamat, definiált és dokumentált, Dr. Horváth Zsolt László 17

o megértett és elfogadott o gyakorlatba átültetett, alkalmazott - Érezhető a menedzsment támogatása - A szerepek és felelősségek egyértelmű meghatározása és megértése - Működő kontrolling a folyamat betartása ellenőrzött - Konzisztens a munkatársak munkastílusával - Mérhető és mért - Alkalmas technológia és tool-ok használata Általános célok (GG2 és GG3) értelmezése GG2: A folyamat intézményesítése menedzselt folyamatként. A menedzselt folyamat jellemzői: - a vállalati stratégia és politika alapján és - az érintetteket bevonásával alakítják ki, - oktatják, - erőforrásokkal ellátják, - ellenőrzik, - betartják. GG3: A folyamat intézményesítése definiált folyamatként. A definiált folyamat jellemzői: - menedzselt folyamat, - vannak szervezeti szintű standard folyamatok - és ezekből vezetik le (testre szabják), - folyamatleírással rendelkezik, - meghatározottak a be/kimenetek, - a folyamat javításához szükséges információkat gyűjtik. A LÉPCSŐZETES ÁBRÁZOLÁS Dr. Horváth Zsolt László 18

Az érettségi szintek - Az érettségi szint (ML) egy jól-definiált fejlődési szint, amely a szervezet érettségét írja le a teljes működése vonatkozásában, azaz azt mutatja meg, hogy mennyire képes a szervezet vállalásait megbízhatóan teljesíteni. - 5 érettségi szint van! (1.. 5) - Az egyes érettségi szintekhez adott általános (közös) cél megfelel az azonos folyamatképességi szint általános céljának. - Az általános (közös) célokhoz tartozó általános gyakorlatok is megfelelnek az azonos folyamatképességi szintekhez meghatározott általános gyakorlatoknak. - Az érettségi szintek kumulatívak, azaz a magasabb szint tartalmazza az alacsonyabb szint teljesülését. Az érett szoftverház jellemzése: 2 -es érettségi szint jellemzése - Projektekre alkalmazott folyamatmenedzsment és projektmenedzsment irányvonal - Szabályozott projekttervezés és követés - Konfigurációmenedzsment és minőségbiztosítási alapkövetelmények - Tervezhető és kézben tartott projekt-teljesítés 3 -as érettségi szint jellemzése - Kialakult (szabványosított) folyamatmodell testre szabottan működik a projektekben - Projektfolyamatok hozzájárulnak a szervezeti folyamatmodellek fejlesztéséhez - Szervezeti szinten egységesen kontrollált folyamat, és megbízható teljesítés és projektsiker 4 -es érettségi szint jellemzése - Folyamatteljesítmény mérése - Kulcsfolyamatok statisztikai folyamatszabályozása - Folyamatok és projektek hatékonyságra optimalizáltak 5 -ös érettségi szint jellemzése - Hibamegelőzés - Folyamatos fejlesztés és innováció - Folyamatosan fejlődő és tanuló szervezet, elért tudás és eredmények hatékony újrafelhasználása Érettségi szintek elérésének feltételei A szervezeti érettségi szintek (ML) elérésének feltételei: (kapcsolat a két modellábrázolás között) - ML2: mindegyik ML2 szinthez tartozó folyamatterületen CL2 elérése - ML3: mindegyik ML2 és ML3 szinthez tartozó folyamatterületen CL3 elérése - ML4: mindegyik folyamatterületen az ML4 szintig CL3 elérése, és a kritikus részfolyamatoknál CL4 elérése - ML5: mindegyik folyamatterületen az ML5 szintig CL3 elérése, és a kritikus részfolyamatoknál CL5 elérése Dr. Horváth Zsolt László 19

2.2.3 A CMMI egyes verzióinak jellegzetességei A CMMI V.1.1 modellek Modellek - Szoftver engineering (SW) - Rendszer + Szoftver engineering (SE + SW) - Rendszer + Szoftver engineering + Integrált termék- és folyamatfejlesztés (SE + SW + IPPD) - Rendszer + Szoftver engineering + Integrált termék- és folyamatfejlesztés + beszállítói erőforrás-menedzsment (SE + SW + IPPD + SS) Ábrázolások - lépcsőzetes - folyamatos A CMMI V.1.2 modellek Modellek - CMMI Keret (CMMI Framework) modell leírás, modell auditálásának leírása, oktatási anyagok - Megosztott CMMI anyag (Shared CMMI material) ez mindegyik CMMI alkalmazásban azonos, mindig használni kell >> ez a kötelező alap - CMMI konstellációk (CMMI Constellations) Szakterületekhez tartozó speciális folyamatok követelményei. Ezek lehetnek: o DEV (Development) fejlesztés (szoftver-fejlesztés) o A (Acquisition) akvizíció o S (Services) - szolgáltatás Ábrázolások - lépcsőzetes - folyamatos A CMMI V1.3 modellek Modellek - Ábrázolás - Alapvetően a V1.2 modellje és ábrázolási módjai mennek tovább Változások - Néhány apró változás kulcsfolyamatokban, illetve egyes kulcsfolyamatokhoz tartozó követelményekben (SAM, RD, PI, OPD) - Kikerült az IPPD (Integrált termék és folyamat fejlesztés), és helyette hangsúlyt kapott a Teaming (teammunka) - Általános célok egyszerűsítése, könnyebb használhatósága - Folyamat képességi szintek csak 3-ig mennek > a 4. és az 5. képességi szint általános céljainak törlése - Folyamatokhoz minőségjellemzők (Quality attributes) szerepének növekedése - Architektúra-központos fejlesztési gyakorlatok, előírások - Team-munka és szerepkörök jelentőségének növelése - Közelítés az agilis fejlesztéshez Dr. Horváth Zsolt László 20

Minőségjellemzők fókusz - Minőségjellemzők értelmezése összhangban az ISO/IEC 9126:2001 Information Technology. Software Product Quality szabvánnyal - Minőségjellemzők nemcsak a funkcionalitásra, hanem a nem-funkcionális követelményekre is vonatkoznak Főbb minőségjellemzők csoportjai - Funkcionalitás - Megbízhatóság - Használhatóság - Hatékonyság - Karbantarthatóság - Hordozhatóság 2.2.4 A CMMI V.1.2 jellemzése A CMMI V.1.2 DEV kulcsfolyamatai: Projektmenedzsment: - Projekttervezés (PP) - Projektkövetés és vezérlés (PMC) - Beszállítói megállapodás menedzsment (SAM) - Integrált projektmenedzsment + IPPD (IPM+IPPD) - Kockázatmenedzsment (RSKM) - Mennyiségi projektmenedzsment (QPM) Folyamatmenedzsment: - Szervezeti szintű folyamatszemlélet (OPF) - Szervezeti szintű folyamatdefiníció + IPPD (OPD + IPPD) - Szervezeti szintű képzés (OT) - Szervezeti szintű folyamatteljesítmény (OPP) - Szervezeti szintű innováció és fejlesztés (OID) Fejlesztés: - Követelményfejlesztés (RD) - Követelménymenedzsment (REQM) - Műszaki megoldás (TS) - Termékintegráció (PI) - Verifikáció ellenőrzés (VER) - Validáció érvényesítés (VAL) Szupport: - Konfigurációmenedzsment (CM) - Folyamat- és termék- minőségbiztosítás (PPQA) - Mérés és elemzés (MA) - Döntéselemzés és döntéshozatal (DAR) - Ok-elemzés és megoldás (CAR) A CMMI V1.2 képességi szintek - A képességi szint (CL) egy jól-definiált fejlődési szint, amely a szervezet képességét írja le az adott kulcsfolyamat-terület (KPA) vonatkozásában. Dr. Horváth Zsolt László 21

- 6 képességi szint van! (0.. 5) - Az 1 5 képességi szintekre adott egy-egy közös cél. - A képességi szintek kumulatívak, azaz a magasabb szint tartalmazza az alacsonyabb szint teljesülését. - Egy kulcsfolyamat-területre (KPA) levetítve is értékelhető annak képességi szintje. (Magasabb érték magasabb folyamatképességet jelent.) - Vizsgálhatók bizonyos folyamatcsoportok is külön, ekkor azok képességi szintjeinek együttese adja az ún. képességi szint profilt (capability level profile). Így egyes folyamatok vagy folyamatcsoportok külön-külön is vizsgálhatók, fejleszthetők. - A CMMI V.1.2 képességi szintek: 0. befejezetlen Esetleg néhány GP vagy SP értelmezett, részben alkalmazott 1. végrehajtott GP 1.1, és mindegyik SP értelmezett, alkalmazott 2. menedzselt GP 1.1 GP 2.10, és mindegyik SP értelmezett, alkalmazott 3. definiált GP 1.1 GP 3.2, és mindegyik SP értelmezett, alkalmazott 4. mennyiségileg menedzselt GP 1.1 GP 4.2, és mindegyik SP értelmezett, alkalmazott 5. optimalizált GP 1.1 GP 5.2, és mindegyik SP értelmezett, alkalmazott A CMMI V.1.2. Általános célok és gyakorlatok GG1. A sajátos célok elérése - GP 1.1 Az alapgyakorlatok végrehajtása GG2. A menedzselt folyamat intézményesítése - GP 2.1 Szervezeti irányvonal (policy) meghatározása - GP 2.2 A folyamat tervezése - GP 2.3 Erőforrások rendelkezésre bocsátása - GP. 2.4 Felelősségek kijelölése - GP 2.5 Emberek képzése - GP 2.6 Konfigurációk menedzselése - GP 2.7 A folyamatban érdekelt felek azonosítása és bevonása - GP 2.8 A folyamat követése és vezérlése - GP 2.9 A folyamat betartásának objektív kiértékelése - GP 2.10. Állapot szemlézése a felsőbb vezetőséggel GG3. A definiált folyamat intézményesítése - GP 3.1 A definiált folyamat létrehozása - GP 3.2 Fejlesztési információk összegyűjtése GG4. A mennyiségileg menedzselt folyamat intézményesítése - GP 4.1 Mennyiségi célok meghatározása a folyamat számára - GP 4.2 A részfolyamatok teljesítményének stabilizálása GG5. Az optimalizáló folyamat intézményesítése - GP 5.1 Folytonos folyamatjavítás biztosítása - GP 5.2 A problémák kiváltó okainak megszüntetése Dr. Horváth Zsolt László 22

A CMMI V1.2 szintek kulcsfolyamat-területei 2.2.5 A CMMI V.1.3 kulcsfolyamatok (változások) A CMMI V.1.3 DEV kulcsfolyamatai: Projektmenedzsment: - Projekttervezés (PP) - Projektkövetés és vezérlés (PMC) - Beszállítói megállapodás menedzsment (SAM) - Integrált projektmenedzsment + IPPD (IPM+IPPD) - Kockázatmenedzsment (RSKM) - Mennyiségi projektmenedzsment (QPM) - Követelménymenedzsment (REQM) Folyamatmenedzsment: - Szervezeti szintű folyamatszemlélet (OPF) - Szervezeti szintű folyamatdefiníció + IPPD (OPD + IPPD) - Szervezeti szintű képzés (OT) - Szervezeti szintű folyamatteljesítmény (OPP) - Szervezeti szintű innováció és fejlesztés (OID) - Szervezeti teljesítmény menedzsment (OPM) Fejlesztés: - Követelményfejlesztés (RD) - Követelménymenedzsment (REQM) - Műszaki megoldás (TS) - Termékintegráció (PI) Dr. Horváth Zsolt László 23

- Verifikáció ellenőrzés (VER) - Validáció érvényesítés (VAL) Szupport: - Konfigurációmenedzsment (CM) - Folyamat- és termék- minőségbiztosítás (PPQA) - Mérés és elemzés (MA) - Döntéselemzés és döntéshozatal (DAR) - Ok-elemzés és megoldás (CAR) A CMMI V.1.3 Általános célok és gyakorlatok (változásokkal) GG1. A sajátos célok elérése - GP 1.1 Az alapgyakorlatok végrehajtása GG2. A menedzselt folyamat intézményesítése - GP 2.1 Szervezeti irányvonal (policy) meghatározása - GP 2.2 A folyamat tervezése - GP 2.3 Erőforrások rendelkezésre bocsátása - GP. 2.4 Felelősségek kijelölése - GP 2.5 Emberek képzése - GP 2.6 Konfigurációk menedzselése Munkaeredmények ellenőrzése - GP 2.7 A folyamatban érdekelt felek azonosítása és bevonása - GP 2.8 A folyamat követése és vezérlése - GP 2.9 A folyamat betartásának és kijelölt munkaeredmények objektív kiértékelése - GP 2.10. Állapot szemlézése a felsőbb vezetőséggel GG3. A definiált folyamat intézményesítése - GP 3.1 A definiált folyamat létrehozása - GP 3.2 Fejlesztési információk összegyűjtése Folyamattal kapcsolatos tapasztalatok összegyűjtése Dr. Horváth Zsolt László 24

A CMMI V1.3 szintek kulcsfolyamat-területei 2.3 Ellenőrző kérdések - Mutassa be a V-Modell alapelvét! - Mutassa be a Scrum szerinti szoftverfejlesztés főbb szerepköreit és főbb lépéseit! - Hasonlítsa össze a hagyományos vízesés modell jellegű szoftverfejlesztést a Scrum szerinti szoftverfejlesztéssel, mik a főbb előnyök-hátrányok? - Jellemezze a CMMI modell folyamatos és lépcsős ábrázolási módjait? - Mi jellemzi a CMMI modell értelmezése szerint az éretlen és az érett folyamatokat? - Melyek a CMMI modell érettségi szintjei, és jellemezze röviden őket? - Mit határoznak meg a CMMI egyes kulcsfolyamat területeire (KPA-kra) vonatkozó általános célok (GG) és sajátságos célok (SG)? Dr. Horváth Zsolt László 25

3 Követelménykezelés a szoftverfejlesztésben Tapasztalat: - Sok hiba visszavezethető hiányos vagy ellentmondásos specifikációra. - A követelmények definiálatlansága a projektek bukásának leggyakoribb oka. 3.1 Követelménykezelési alapelvek 3.1.1 Meghatározások A követelmény egy önmagában kifejezett igény a rendszer vagy az azt létrehozó projekt valamilyen jellemzőjére. - Bejövő igény, elvárás (felhasználóktól, megrendelőtől, más érdekelt felektől) - Validáció alapja A követelménykezelés a projektben megvalósítandó szoftver jellemzőinek meghatározása - szisztematikus művelet a követelmények összegyűjtésére és rögzítésére; - kifejezi és rögzíti a megrendelő és a projekt közötti megegyezés tartalmát; - egyértelművé teszi a későbbi követelmény változásokat; - elkerülhetővé teszi a plusz funkciók begyűrűzését ; A specifikáció - a (szoftver-) tervezők, fejlesztők felé átalakított elvárások - a követelménykezelés eredménye - megvalósulhat többféle szinten is, különböző elnevezései vannak pl. követelményterv (requirement spec.), funkció-terv (function spec.), architektúraterv (architecture spec.), design-terv (design spc.), rendszerterv (system spec.), stb. - a verifikáció alapja - Elvárások a specifikációval szemben: o A követelmények teljes lefedése Funkcionális követelmények Extra-funkcionális (vagy nem-funkcionális) követelmények o Megfogalmazás: egyértelmű, igazolható, megvalósítható o Javasolt megoldások: Szigorú specifikációs nyelv (pl. formális nyelvek) Ellenőrzött (tervezés ill. specifikációs) minták, módszerek használata Utólagos ellenőrzés 3.1.2 A követelménykezelés feladatai - A követelmények hatékony, strukturált tárolása - A követelmények finomítása és kapcsolódása o pl.: követelményterv -> rendszerterv -> modulterv -> forráskód -> teszt - A követelmények életciklusának támogatása o felvétel törlés változás finomítás kapcsolatok ábrázolása - Elemzési lehetőségek o Hatás analízis Mit befolyásol, ha a követelmény megváltozik? Dr. Horváth Zsolt László 26

o o Eredet analízis Milyen követelményre vezethető vissza? Miért van itt, szükséges-e? Fedettség analízis Mely követelmények nincsenek implementálva? Mely követelmények nincsenek tesztelve? 3.1.3 A követelménykezelés lépései 1. A probléma feltárása és elemzése o o A szakma megismerése Követelmények összegyűjtése 2. Követelmények részletezése o 2 vagy több-szintű részletezettséggel 3. Követelmények rendszerezése o o o Osztályozás Összefüggések felvétele Ellenőrzés, ellentmondások feloldása 4. Változások követése, követelmény-karbantartás 3.1.4 Tervezés több szinten Három-szintű követelmény-struktúra 1 Felhasználói követelmények 2 Rendszerkövetelmények 3 Szoftverterv-specifikáció (architektúra, design, ) Egyszerűsített, két-szintű követelmény-struktúra 1 Ad-hoc: rendszerképességek + résztvevői igények vázlatos, nem rendszerezett, ismétlődéseket és ellentmondásokat is tartalmazhat 2 Rendszerezett követelmények szisztematikus, konszolidált, konzisztens funkcionális és nem-funkcionális követelményeket eredményez (funkcionális követelmények általában használati eseteket írnak le) Dr. Horváth Zsolt László 27

Kétszintű követelménykezelés ábrázolása Ad hoc szint (első szint): Rendszerképességek = Features - A rendszer szolgáltatásainak többé-kevésbé szabatos leírása - Forrása általában: előzetes specifikáció (v. koncepcióterv, ) o A projekt ötletgazdái készíthetik, vagy o Gyakran az ajánlatkérés / projekt tervezés alapja o Természetes nyelven, mérsékelten szabados stílusban Résztvevői igények - Készül ált. kezdeti fázisban, de lehet a később is - Célja a rendszer tulajdonságainak, elvárásoknak a pontosítása, részletezése - Bárki érintett javasolhatja /// interjúk, ötletbörzék, stb. eredményei 3.1.5 Ellenőrzési relációk a V-modellben Dr. Horváth Zsolt László 28

3.2 Példák különböző rendszerek vizsgálati szempontjaira 3.2.1 Vizsgálati szempontok biztonságkritikus rendszerekre Teljesség - Funkciók, hivatkozások, eszközök Konzisztencia (ellentmondás-mentesség) - Külső és belső - Követhetőség Megvalósíthatóság - Erőforrások - Használhatóság - Karbantarthatóság - Kockázatok: költségbeli, technikai, környezeti Tesztelhetőség - Specifikus - Egyértelmű - Számszerűsíthető 3.2.2 Vizsgálati szempontok IEEE 830:1998 szabvány alapján IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications Helyes - A szoftverre vonatkozó követelményeknek megfelel - Konzisztens a külső forrásokkal Egyértelmű Teljes - Nem félreérthető, csak egy jelentés - Hasznosak a formális, fél-formális specifikációs nyelvek - Minden bemenetre van specifikált viselkedés - TBD csak indoklással oldható fel Konzisztens (TBD = to bo determined ) - Nincs belső ellentmondás - Egységes terminológia Fontosság és stabilitás szempontjából rendezett - Követelmények szükségessége, változatlansága felmérve Ellenőrizhető - Egyértelmű egy követelmény nem-teljesülése Módosítható - Nem redundáns, jól strukturált Dr. Horváth Zsolt László 29

- Jól elválasztott követelmények Követhető - Eredet becsatolható - További hatások hivatkozhatóak 3.2.3 Vizsgálati szempontok reaktív (irányítástechnikai) rendszerekre Állapotdefiníció - Biztonságos a kezdőállapot - Belső modell aktualizálva van a környezettel (kimaradó bemeneti események esetén time-out van, és nincs kimenet akció) Bemenetek (események) - Minden bemenetre, minden állapotban van specifikált viselkedés (reakció) - Egyértelműek a reakciók - Van bemeneti ellenőrzés (értékbeli, időbeli) - Hibás bemenetek kezelése specifikálva - Megszakítások gyakorisága korlátozva Kimenetek - Hihetőség-vizsgálat kritériumai specifikáltak - Nincsenek fel nem használt kimenetek - Környezeti feldolgozó-képesség be van tartva Kimenetek és trigger kapcsolata - Kimenetek hatása a bemeneteken keresztül ellenőrizve - A szabályzási kör stabil Állapotátmenetek - Minden állapot elérhető statikusan - Állapotátmenetek visszafordíthatók (visszaút van) - Több átmenet van veszélyes állapotból biztonságosba - Megerősített átmenet van biztonságos állapotból veszélyes állapotba Ember-gép interfész Kezelő felé kimenő események specifikációja: - Sorrendezés előírt (prioritással) - Frissítés előírt - Gyakoriság korlátozott (kezelő terhelhetősége) 3.3 A követelménykezelés problémái Szerződéses fejlesztésnél (egyedi megrendelésnél): Érdekellentétek A megrendelő palotát remél, de a fejlesztő legszívesebben kockaházat építene. Világképek különbözősége Szakterületi és szoftver tudás. Nincs közös nyelv a megrendelő és a szoftverfejlesztő között; mindketten csak korlátozottan alkalmasak követelménykezelésre. (Sokszor vak vezet világtalant.) Dr. Horváth Zsolt László 30

Változó igények, és későn eszmélő / lusta megrendelő Feature creep, azaz a követelmények utólagos belopódzása a fejlesztés során. (Sokszor a megrendelő az elején nincs is tisztában azzal, mit és hogyan szeretne majd később mindent ) Piaci fejlesztésnél (dobozos terméknél): Piaci és felhasználói igények eltalálása Sőt. Más az, amiért megveszik, és más az, amiért szeretni fogják. Time to market pressure Hamarabb kell megjelenni, mint a konkurencia. Benefit vs. Cost Az extra funkcionalitás megéri-e a plusz fejlesztési erőforrásokat? Tényleg kell-e? (reális veszély: dagadt, lassú programok) Megéri-e ill. van-e keret a kellő ellenőrzésekre, minőségbiztosításra? Napjaink divatos pályázatai, ahol csak az ár számít 3.4 Követelménykezelés a CMMI-ben A CMMI-ben két kulcsfolyamat (Keyprocess) van a követelmények kezelésével kapcsolatban. Ezek: RD Requirements Developement - Folyamat célja: az ügyfélre, a termékre és a termék-komponensekre vonatkozó követelmények előállítása és elemzése. - Speciális célok (specific goals): o SG1: Develop Customer Requirements (ügyfél követelmények meghatározása) o SG2: Develop Product Requirements (termék követelmények meghatározása) o SG3: Analyse and Validate Requirements (követelmények elemzése és validálása) RM Requirements Management - Folyamat célja: a projekt termékei és termék-komponensei követelményeinek kezelése, és azon követelmények és a projekttervek és munkatermékek közötti inkonzisztenciák azonosítása. - Speciális célok (specific goals): o SG1: Manage Requirements (követelmények kezelése) 3.5 Ellenőrző kérdések - Mutassa be a követelménykezelés alapvető feladatait! - Mutassa be a követelménykezelés fő lépéseit! - Mutassa be a követelménykezelés jellemző gyakorlati problémáit egyedi megrendelésre fejlesztés, illetve dobozos termék fejlesztés esetén? - Milyen szempontok alapján csoportosíthatóak a vizsgálati szempontok bizonyos rendszerek esetén? Mondjon példát ilyen csoportosítási szempontokra, csoportosításra! - Milyen CMMI kulcsfolyamat területek (KPA-k) foglalkoznak a követelménykezeléssel, és mutassa be azok fő célját? Dr. Horváth Zsolt László 31

4 Tesztelés a szoftverfejlesztésben A tesztelési folyamat során átgondolandó kérdések 1. Mi a tesztelés célja? 2. Mit tesztelünk? 3. Hogyan illeszkedik a tesztelés a fejlesztési folyamatba? 4. Hogyan tesztelünk? 5. Hogyan határozzuk meg a teszteseteket? 6. Hány teszteset futtatása szükséges? 7. Hogyan hajtjuk végre a teszteket? 8. Hogyan értékeljük ki a teszteket? 9. Mik az eredményes tesztelés előfeltételei? 10. Milyen tool-ok állnak rendelkezésre a teszteléshez? 4.1 A tesztelés életciklusa 4.1.1 Tesztelés célja Mi a tesztelés célja? - A tesztelés célja hibák megtalálása, feltárása. - A tesztelés hivatalos célja még: az ügyfél számára a termék minőségének igazolható bizonyítása. - Miért jó ez? Hibák megtalálása, amilyen hamar csak lehet o o o o o Ezeket kijavítjuk (de legalább tudunk róla ) Gyorsítjuk a fejlesztés menetét Projekt érettségéről információ Károkozás megelőzése Rizikó számszerűsítése 4.1.2 Tesztelés objektuma Mit tesztelünk? - A funkcionális és a nem-funkcionális minőségjellemzők tesztelése. o funkcionális: funkcionalitás, GUI viselkedése, beadandó mezők szintaxisa, stb o nem-funkcionális: terhelhetőség (performancia), megbízhatóság, rendelkezésre állás, használhatóság, stb Dr. Horváth Zsolt László 32

4.1.3 Tesztelés helye a fejlesztési folyamatban Tesztelés Megfelel-e az elvárt viselkedésnek / követelményeknek? Egy vagy több futtatható állapotban levő szoftver komponens/modul/rendszer meghatározott feltételek mellett (adat, esemény) történő futtatása, és a működés eredményének értékelése. Verifikálás A szoftver megfelel-e a specifikációnak? Igazoló ellenőrzése az előírt követelmények teljesítésének. Validálás A szoftver megfelel-e a felhasználó igényeinek? Érvényesítő ellenőrzése a valamilyen tervezett felhasználásra vonatkozó konkrét követelményeknek. A tesztmérnök feladatai a követelmények fázisban: A feladatot tisztázni. Érthetőek és tisztázottak-e a követelmények? Tesztelhetőek-e a követelmények? Vannak-e ellentmondások a követelmények között? Teljes rendszert alkotnak-e a követelmények, vagy egyes részek csak elnagyoltan jelennek meg? a tervezési / megvalósítási fázisban: Teszt stratégia. Automatizálás célja és módja, felhasználandó eszközök, tesztlabor felszerelése és elrendezése, biztonsági sebezhetőség teszt módja. Teszt terv Konkrét leírása (szcenárió) minden tesztesetnek. Előfeltételek, lebonyolítás, elvárt eredmény. Negatív eseményekre is tesztet (pl. hibás input, memóriahiány, stb.). Dr. Horváth Zsolt László 33

4.1.4 Hogyan tesztelünk? Tesztelések csoportosítása Tesztelések szintjei: - Stand-alone-test (modulteszt vagy unit-teszt): egyes modulok (vagy modulcsoportok) önálló tesztelése - Integrációs teszt: az interfészek működésének tesztelése - Rendszerteszt: egy kész rendszer tesztelése, viszonyítva a követelményspecifikációban meghatározott funkciókhoz, teljesítményekhez, illetve minőségi követelményekhez. - Átadási teszt: az ügyfél követelményeinek megfelelő működés bemutatása. - Regressziós teszt: a kód megváltoztatása utáni újabb hibák megjelenésének elkerülése érdekében végrehajtott tesztelések Tesztelések követelményei: Unit-teszt (komponens teszt): Célja: Az elkülönülten kezelhető komponensek/unitok működését igazolja, és a hibákat feltárja. - Tesztelés iránya o Funkcionális jellemzők, melyeket a rendszerterv előír. o Nem funkcionális jellemzők, mint pl. memória szivárgás, robusztusság, kódlefedettség. - Test driven development o A komponens tesztkörnyezetét hamarabb írják meg, mint magát a kódot. o Az inkrementális-iteratív fejlesztéshez nagyon alkalmas. o Alapértelmezett automatikus, regressziós teszt. Integrációs teszt o Több modult összekapcsolunk, és mint egységet tekintjük. Az modulok száma, mérete és fontossága szerint az integráció több szinten is megvalósul. o Teszteljük a modulok közötti interfészt, és azok együtt-működését. Az egyes modulok saját működésének ellenőrzése nincs fókuszban. o Black-box szemlélet! o Ellentmondásokat keresünk. Nagyobb csoport esetén bonyolultabb hibaképek keletkeznek, a hibát nehezebb egy-egy modulhoz hozzárendelni. o Nem funkcionális szempontok figyelembe veendők! Teljesítmény, megbízhatóság,... Rendszerteszt - Célja: A teljes rendszer futásának, működésének egyben történő ellenőrzése. - Szempontok: o Jellemzően black-box teszt, elsősorban verifikációs céllal. o Legyen gyanakvó a hozzáállásunk! Ez egy destruktív fázis. Azt keressük, milyen szempontok alapján buktatható meg a rendszer. Minden eszköz megengedett. Átadási teszt - Célja: Egy teljességében integrált rendszert tesztelünk, hogy igazoljuk, hogy teljesíti a vele kapcsolatban támasztott igényeket. - Szintjei: o Kiszállítás előtt közbenső teszteket definiálnak: Dr. Horváth Zsolt László 34

o o Alfa teszt: A felhasználó a fejlesztő telephelyén teszteli az aktuálisan működő rendszert. Tipikusan dobozos termékek esetén használják. Béta teszt: (Bemutató változat) A béta verziót a felhasználók szűk körének adják ki. Így valódi felhasználói tesztelésnek vetik alá. Egyes termékek esetén a teljes felhasználói közösség megkapja a béta terméket, hogy növeljék a visszajelzések mennyiségét. Feature freeze. Nem építenek be új funkciókat. Gamma, delta (release candidate). A termék kész, nem tartalmazhat súlyos hibákat (code complete). Felhasználói átvételi teszt. Jellemzően igazolja, hogy a rendszer alkalmas-e az üzleti felhasználásra. Az tesztet a felhasználó irányítja, hogy elfogadja-e a terméket. Üzemeltetési átvételi teszt. A rendszer-adminisztrátorok ellenőrzik a nekik fontos funkciókat (Mentésvisszaállítás, katasztrófa visszaállítás, ügyfélmenedzsment, karbantartási feladatok, sebezhetőség ellenőrzése). Tesztelések fajtái - Black-box teszt: tesztelés a specifikáció és a program viselkedésbeli eltéréseinek meghatározására Jellemzői: o A forráskód a teszt során nem ismert; o Adott bemenetre elvárt kimenetek; o Kapott és elvárt eredmények összehasonlítása; o Mindegyik tesztelési szinten használható; - White-box teszt: tesztelés a specifikáció és a program viselkedésbeli eltéréseinek meghatározására Jellemzői: o o o o A forráskód a teszt során ismert; Strukturális tesztelés; A kód egyes részeinek a tesztelése; Technikák: Adat folyam tesztelés Vezérlési folyamat tesztelés Ágak tesztelése Utasítás lefedettség Döntés lefedettség 4.1.5 Tesztesetek meghatározása Tesztesetek előállításakor: - Tesztelés befejezési ( testend- ) kritérium meghatározása (tesztelési tervben!) - Tesztelés struktúrájának meghatározása Dr. Horváth Zsolt László 35

- Teszt-fajták meghatározása (pl. black-boksz v. white-boksz tesztelés, nem funkcionális tulajdonságok tesztelése (performancia, stabilitás, használhatóság, ) - Teszt-fajtánként a tesztesetek vagy tesztelési csomagok meghatározása Tesztesetek dokumentálásakor megadni: - Megnevezés - Teszteset célja - Pozitív / negatív eredmény - Kézi / automatizált - HW/SW konfiguráció - A tesztelés tárgyának (objektumának) kiindulási állapota - Minden bemeneti adat - Tesztelés lefutása, az egyes lépések megadásával - Lépésenkénti elvárt eredmények 4.1.6 Hány teszteset futtatása szükséges? Teszt-befejezési kritériumok - Hány tesztesetet határozzunk meg? - A rendszer állapotához fel kell mérni a meg nem talált hibák hatását és következményét. - A rendszer megbízhatósága. - A hibaszám metrika megjósolja, hogy mikor kerül érett fázisba a termék. Hibatrendek. A tesztelést nem lehet befejezni, csak abbahagyni. - Fejezzük be, ha a következő hiba felfedezésének határköltsége nagyobb, mint a hiba miatti veszteség Hány tesztesetet határozzunk meg? Pl. Black-box teszt esetén tesztelt funkciókhoz a szükséges tesztesetek száma meghatározásának szempontjai: - rendelkezésre álló büdzsé, - funkció kritikussága, - funkció összetettsége, - eddigi tapasztalatok, - bemeneti / kimeneti értéktartomány lehetséges és hibás értékeire, határértékeire is, - stb 4.1.7 Tesztek végrehajtása Hogyan hajtjuk végre a teszteket? - Megfelelő teszt-csomag összeállítása (a tesztesetekből) - Tesztelés végrehajtása (manuálisan v. automatizáltan) - Tesztelés dokumentálása 4.1.8 Tesztek kiértékelése - Teszt-jegyzőkönyvek/-jelentések készítése - A sikertelen (hibásan lefutott) tesztesetek elemzése Dr. Horváth Zsolt László 36