Brachmann Ferenc PTE-TTK/KTK 2009

Az előadások a következő témára: "Brachmann Ferenc PTE-TTK/KTK 2009"— Előadás másolata:

1 Brachmann Ferenc PTE-TTK/KTK 2009
A szoftverfejlesztési folyamatok, konfigurációkezelés, tesztelés és követelménykezelés minőségbiztosítása Brachmann Ferenc PTE-TTK/KTK 2009

2 Szoftverfejlesztési folya-matok minőségbiztosítása
A szoftverminőség összetevői A szoftverminőség „piaci” megfogalmazása Minőségi profil kialakítása Szoftverminőségi modellek A szoftverfejlesztés folyamatának minősége Szoftverfolyamat-fejlesztési modellek

3 Szoftverfejlesztési folya-matok minőségbiztosítása
A tapasztalat azt mutatja, hogy a szoftverben hibák lehetnek. Miért vannak hibák a szoftverben? Komplex feladatok elvégzésénél az emberek követnek el hibákat Tapasztalt programozók átlagban minden 10 forrássorban vétenek 1 hibát Ezen hibák felét a fordításkor kijavítják A tesztelés során további hibák is kijavulnak, de a hibák 15%-a bent marad az ügyfélnek való átadáskor

4 Szoftverfejlesztési folya-matok minőségbiztosítása
A szoftverminőség összetevői Termék Folyamatok Erőforrások Definíció Minőségi attribútum Mérőszám

5 Szoftverfejlesztési folya-matok minőségbiztosítása
Mitől függ a szoftverminőség definíciója? A minőséget értékelő személyétől / nézőpontjától / értékrendjétől Felhasználó …érdekli: a szoftver használata, a szoftver teljesítménye, a használatának következményei (pl. funkcionalitás, megbízhatóság, hatékonyság, használhatóság, hordozhatóság) ...nem érdekli a szoftver belső szerkezete sem az, hogy hogyan fejlesztették

6 Szoftverfejlesztési folya-matok minőségbiztosítása
Mitől függ a szoftverminőség definíciója? A minőséget értékelő személyétől / nézőpontjától / értékrendjétől Fejlesztő …a köztes termék-minőség, és a végtermék minősége (karbantarthatóság, tesztelhetőség...) Menedzser …érdekli a minőség, átfogóan , a menedzsment szempontjából történő minőségjavítás (csúszások, költségtúllépések kiküszöbölése). … nem érdeklik specifikus minőségi attribútumok

7 Szoftverfejlesztési folya-matok minőségbiztosítása
Mitől függ a szoftverminőség definíciója? A szoftvergyártás típusától Rendszer típusától / szoftver alkalmazási területétől Üzletpolitikától

8 Szoftverfejlesztési folya-matok minőségbiztosítása
A szoftverminőség „piaci” megfogalmazása „Jó” a szoftver, ha: tetszik a felhasználónak, kielégíti az igényeit, azt csinálja, amit a felhasználó szeretne... időben, olcsón elkészül az átadáskor stabilan működik kevés hibát tartalmaz...

9 Minőségi profil kialakítása
jellemzők / attribútumok Szoftver termék Üzleti folyamat Vevő / felhasználó Lefordítási folyamat Minőségi profil

10 Minőségi profil kialakítása
A fejlesztőnek és felhasználónak közösen kell kialakítania A minőségi profil tartalmaz folyamatra termékre erőforrásra vonatkozó minőségi attribútumokat

11 Minőségi profil kialakítása
Például: A szoftver készüljön el időre, ne lépje túl a szerződésben szereplő árat, használjon a felhasználónál meglévő technológiát Ha a szoftvertől emberi életek függhetnek: fontos az integritás, megbízhatóság, helyesség, ellenőrizhetőség Tartós „fogyasztási cikk”esetében fontos, hogy karbantartható, bővíthető , könnyen kezelhető, tanulható, jól dokumentált, „szép” felhasználói felületű legyen

12 Szoftverminőségi modellek
GQM Folyamat Termék Erőforrás Definíció Minőségi attribútum Mérőszám Objektumok Jellemzők ISO 9126 (Boehm, McCall)... ISO 9001:2000 CMM SPICE CMMI ISO 15504 TSP, PSP PM módszertanok People CMM Weinberg...

13 Szoftverminőségi modellek
accuracy suitability interoperability compliance security understandability learnability operability time behaviour resource utilisation analysability changeability stability testability adaptability installability co-existence conformance replaceability quality in use functionality usability efficiency maintainability portability reliability maturity fault tolerance recoverability effectiveness productivity safety satisfaction availability Szoftvertermék alapú megközelítés: Az ISO szabvány

14 Szoftverminőségi modellek
Erőforrás alapú megközelítés PM módszertanokban hangsúlyos P-CMM, szervezeti modellek, team-szerepek, vezetési stílusok, ösztönzési elméletek... Erőforrások minősége szám szerint mennyi és milyen típusú erőforrást használtunk fel. az emberi erőforrás szakmai tapasztalata és termelékenysége programozó teljesítménye: megírt LOC / ember-hónap – releváns?

15 Szoftverminőségi modellek
Folyamat alapú megközelítés PM módszertanok (pl. PRINCE, PROPS, Ideal, BPMM...) Tervezési, fejlesztési módszertanok (pl. RUP, SSADM...)

16 Szoftverminőségi modellek
Folyamat alapú megközelítés Folyamatok minősége tervezett és tényleges befejezés, ráfordítás, költség, projekt egészére és feladatokra tesztelési folyamat időtartama a tesztelés során megtalált hibák száma és súlyossága hibasűrűség egy modulban: hibák száma / modul mérete hibamegtalálási hatékonyság: megtalált hibák száma / összes hibák száma követelmények stabilitása: kezdeti követelmények száma / összes követelmény száma

17 Szoftverminőségi modellek
ISO 9001:2000 CMM : Capability Maturity Model SPICE / ISO (Software Process Improvement and Capability dEtermination) CMMI: Capability Maturity Model Integration

18 Capability Maturity Model
A projektek tipikusan átlépik az idő- és költségkeretet 1 A projekt tervezés és vezetés megfelelő Szoftver konfigurációkezelés Szoftver minőségbiztosítás Szoftver alvállalkozók kezelése Szoftver projekt követés & felügyelet Szoftver projekt tervezés Követelmények menedzsmentje Hatékony módszerek léte 2 A termékminőség lényeges javulása Kölcsönös szemlék Csoportok közötti koordináció Szoftver termék fejlesztés Integrált szoftver menedzsment Képzési terv Szervezeti szintű folyamatok meghatározása Odafigyelés a folyamatokra A leghatékonyabb módszerek dokumentáltak és minden projektben használtak 3 A termelékenység és a ciklusidő javulása Szoftver minőség menedzsment Mennyiségi folyamat menedzsment A hatékonyság, hatásosság, termelékenység és minőség mennyiségi biztosítása 4 Termelékenység és ciklus idő javítása Folyamat változás menedzsment Technológia változás menedzsment Hibamegelőzés Javításra felhasznált mennyiségi visszacsatolás 5

19 A SPICE modell Folyamat érettségi szintek Folyamatok 5. Optimalizált
4. Jósolható Vevővel-értékesítővel kapcs. Fejlesztési Támogató Menedzsment Szervezeti 3. Meghatározott 2. Menedzselt 1. Végrehajtott 0. Nem létező

20 CMMI: Capability Maturity Model Integration
A lépcsős megközelítés a folyamatokat 5 szervezeti érettségi szinthez (maturity levels) társítja, ezzel támogatva és vezérelve a folyamatjavítást. 1. Kezdeti (Initial) 2. Menedzselt (Managed) 3. Meghatározott (Defined) 4. Minőségileg menedzselt (Quantitatively Managed) 5. Optimalizáló (Optimizing) A folytonos megközelítés 6 képességi szintet határoz meg, bármely folyamatra 0. Hiányos (Incomplete) 1. Végrehajtott (Performed)

21 CMMI: Capability Maturity Model Integration
CMMI lépcsős megközelítés elemek 2. Szint (projekt központú): Követelménykezelés, projekt tervezés és vezérlés, beszállítók kezelése, mérés és elemzés, termék és folyamat minőségbiztosítás, konfigurációkezelés 3. Szint (szervezet központú): Követelmények meghatározása, műszaki megoldások, termék integráció, termék ellenőrzés, termék igazoló ellenőrzése, szervezeti szintű folyamatok léte, szervezeti szintű folyamatok meghatározása, szerv szintű képzés, integrált termék menedzsment, kockázatkezelés, döntéselemzés és támogatás 4. Szint (mennyiségi kontroll): Szervezeti szintű folyamatok teljesítménye, mennyiségi projekt menedzsment 5. Szint (folytonos javítás): Szervezeti szintű innováció és bevezetés, eseti elemzés és döntéskezelés A folytonos megközelítés elemek Folyamat menedzsment Szervezeti szintű folyamatok léte , szervezeti szintű folyamatok meghatározása , szervezeti szintű képzés, szervezeti szintű folyamatok hatékonysága, szervezeti szintű innováció és bevezetés Projekt menedzsment: Projekt tervezés, projekt követés és vezérlés , beszállítók kezelése, integrált projekt menedzs-ment, kockázatkezelés, integrált csapat-építés, mennyiségi projekt menedzsment Fejlesztés: Követelmények meghatározása, követelmény-menedzsment, műszaki megoldások,termék integráció, ellenőrzés,igazoló ellenőrzés Support Konfigurációkezelés, folyamat és termék minőségbiztosítás, mérés és elemzés, integrá-cióra alkalmas szervezeti környezet , döntés elemzés és támogatás ,eseti elemzés és döntés

22 Választás a modellek között
ISO 9001:2000 – piaci alapkövetelmény, szükségszerűség (+ szakirányú szabvány, pl. orvosi, autóipari...) Erre épülhet rá pl. a CMM vagy CMMI CMM – 2005 decemberig auditálták CMMI – folyamatosan auditálják

23 Választás a modellek között
Választás a CCMI elemei között Függ a vállalat céljaitól, korábbi tapasztalatától Lépcsős vagy folytonos? Folytonos modell könnyen tanítható, nehezebben használható Lépcsős modell nehezen tanítható, könnyebben használható Mindenképpen a nekünk megfelelőt kell választani!

24 A szoftver tesztelése során vallott misszió #1
Gyorsan felfedezzük a fontos programhibákat Általános kulcsunk legyen a termék minőségének megállapításához Igazoljuk, hogy a termék megfelel bizonyos standardoknak A felhasználók is hozzájáruljanak a termék minőségének és tesztelhetőségének javításához

25 A szoftver tesztelése során vallott misszió #2
A tesztelési folyamat feleljen meg bizonyos "számonkérhetőségi" standardoknak Fejlessze a felhasználókat is a tesztelésben és a tesztelőkkel való együttműködésben Bizonyos előre meghatározott módszerek és szabályok érvényesüljenek a tesztelés során Elősegítse a terméktámogatás költségének megállapítását és ellenőrzését

26 A szoftver tesztelése során vallott misszió #3
Segítse a felhasználókat munkafolyamataik javításában A munka a lehető legkisebb indokolt költséggel, a lehető legrövidebb idő alatt, "mellékhatások" nélkül készüljön el Együttműködés alakuljon ki a programozókkal Szinte mindent megkérdőjelezzenek, de ne kürtöljenek ki mindent azonnal a külvilágba A sikertelen dolgokra koncentráljanak annak érdekében, hogy a felhasználó a sikert érzékelje Mindent megtegyenek annak érdekében, hogy felhasználók elégedettek legyenek

27 A teszteléssel nem biztosítjuk a minőséget
Viszonylag könnyű arra gondolni, hogy a tesztelők a minőség őrei Azonban a minőség a termék készítőitől származik Missziónk nagy része arra irányul, hogy a készítők foglalkozzanak a minőséggel és hatékonyabban, mint egyébként tennék Amennyiben mi végezzük a tesztelést, csoportunk "minőségbiztosítási" csoportnak is nevezhető Teszt eredményeink és hibalistáink valóban elősegítik a termék minőségének javítását, azonban ez a javulás nem csak a tesztelők érdeme, hanem az egész munkacsoport munkájának az eredménye

28 A "nem a mi problémánk" kérdése a tesztelés során
A tesztelés komplex folyamat és tevékenység, amely szorosan kapcsolódik más tevékenységekhez. Ennek ellenére egyesek szívesen leszűkítenék a tesztelés folyamatát a terméknek a tervtől való eltéréseire Érdemes ennél sokkal szélesebb értelemben felfogni a tesztelést A tesztelés valójában foglalkozik a következőkkel Használhatóság mi szükséges a programhoz, futtatásához adatok minősége program támogathatósága melyek mind ugyancsak a "mi problémánk"

29 Jelentésre és kijavításra érdemes programhibák #1
A programhibák megzavarják a felhasználókat és csökkentik a szoftver iránti bizalmukat A gyakori programhibák a következők: Helyesírási hibák Képernyő formázási hibák Egérnyom (kis foltok, nyomok jelennek meg az egér mögött mozgatása során) Számítási hibák Az ábrák, grafikonok nem megfelelő méretűek

30 Jelentésre és kijavításra érdemes programhibák #2
Hibák a képernyőre hívható segítségben Menüpontok, amelyek nem szürkülnek el, amikor kellene, illetve elszürkülnek, amikor nem kellene Nem működő billentyűkombinációk Helytelen hibaüzenetek Szélső értékek (túl nagy vagy túl kicsi számok) helytelen kezelése Időbeállítások, időkorlátozások helytelen működése Egyéb hibák

31 Gondolkodjunk tesztelőként
A jó tesztelők technikai szempontból, kreatívan, kritikusan és gyakorlatiasan gondolkodnak Valamennyi gondolkodási típusnak jelentősége van a tesztelés során. Ezek: Technikai gondolkodás Kreatív gondolkodás Kritikai gondolkodás Gyakorlatias gondolkodás

32 Implicit és explicit specifikációk #1
Specifikáció alatt a program működésének és peremfeltételeinek meghatározását értjük Az explicit, kimondott, leírt specifikáció igen hasznos, mert a készítők vagy a felhasználók által elfogadott követelményeket, kritériumokat önt formába egyértelműen

33 Implicit és explicit specifikációk #2
Az implicit specifikáció viszont nincs egyértelműen elfogadva vagy leírva a készítők vagy a felhasználók által Az implicit specifikáció gyakran nem annak alapján keletkezik, hogy a program legjobb legyen a felhasználók szempontjából, hanem sokszor a meggyőző ereje vagy a hihetősége határozza meg.

34 Implicit és explicit specifikációk #3
Nemegyszer az implicit specifikációknak alig van közük a kifejlesztendő termékhez. Az implicit specifikációknak számos formája létezik: Hasonlítás versengő termékekhez Hasonlítás kapcsolódó termékekhez Hasonlítás ugyanazon termék korábbi verzióihoz A fejlesztés során váltott ek tartalma A fogyasztók által tett észrevételek, megjegyzések  Saját jól megalapozott tapasztalataink

35 Heurisztikák alkalmazása a tesztelés során #1
A heurisztika lényegében ökölszabály, hüvelykujjszabály Célja, hogy képzett emberek által jóváhagyott módon cselekedjünk új helyzetben Jóllehet a heurisztika nem biztosítja a helyes cselekvést kritikus helyzetekben, mindazonáltal időnként jó szolgálatot tehet

36 Heurisztikák alkalmazása a tesztelés során #2
Példák heurisztikák alkalmazására Szélső értékek tesztelése Valamennyi hibajelzés tesztelése Beállítások tesztelése Futtatási teszt

37 A tesztelés tárgyára irányuló technikák #1
A tesztelés tárgyára irányuló technikák a termékre koncentrálnak Számos technika áll rendelkezése, amelyek különbözőképpen csoportosíthatók attól függően, hogy mire kívánjuk használni ezeket

38 A tesztelés tárgyára irányuló technikák #2
Például a az egyes program tulajdonságok integráltságának tesztelése termék orientált, amennyiben azt vizsgáljuk, hogy minden funkció megfelelően működik-e a többi funkcióval együtt (kombinációban) Ugyanez probléma orientált, amennyiben van valamilyen elképzelésünk arról, hogy miért van valamilyen hiba, és ennek keletkezését nyomon szeretnénk követni. Lehet például, hogy az egyik függvénynek vagy szubrutinnak nem vagy nem jól adjuk át az értékeket

39 A tesztelés tárgyára irányuló technikák #2
Működés tesztelése Minden egyes működési elem, függvény, szubrutin tesztelése egyenként Az elemek, függvények, szubrutinok lehetőleg teljes körű tesztelése annak megállapítása érdekében, hogy azok valóban jól működnek Fehér doboz függvény tesztelés Ezt rendszerint egység tesztelésnek is nevezik, és rendszerint az egyes, forráskódban megjelenő önálló függvények vagy szubrutinok tesztelését jelenti

40 A tesztelés tárgyára irányuló technikák #3
Fekete doboz függvény tesztelés Ennek során a parancsokra és olyan dolgokra, tulajdonságokra figyelünk elsősorban, amelyeket a felhasználó ki tud választani, vagy amellyel elő tud idézni valamilyen működést Ajánlott a függvény tesztelés elvégzése mielőtt bonyolultabb tesztek során több függvény együttes tesztelését végeznénk el Összetett tesztelés során az első hibás függvény leállítja a program futását, és esetleg nem állapítható meg egykönnyen, hogy melyik függvény volt a hibás

41 A tesztelés tárgyára irányuló technikák #4
Tulajdonságok és függvények integráltságának tesztelése  Ennek során elemezzük, hogy a tulajdonságok, függvények megfelelően kapcsolódnak-e egymáshoz, integrált-e a rendszer Menü vizsgálat Végig kell menni valamennyi menüponton a grafikus felhasználói felületen és minden választási lehetőséget kipróbálni

42 A tesztelés tárgyára irányuló technikák #5
Domain tesztelés A domain olyan (matematikai) halmaz, amely magában foglalja egy változó, illetve függvény valamennyi lehetséges értékét A domain tesztelés során azonosítjuk a változókat és függvényeket A változók bemeneti és kimeneti változók egyaránt lehetnek Minden egyes változóhoz a lehetséges változókat ekvivalencia osztályokba soroljuk és kiválasztjuk belőlük kis részhalmazukat, rendszerint a szélső értékek környékén a teszteléshez

43 A tesztelés tárgyára irányuló technikák #6
Ekvivalencia osztály tesztelés Az ekvivalencia osztály a változó azon értékei, amelyeket ekvivalensnek tekintünk A teszt-esetek ekvivalensek, ha úgy gondoljuk, hogy Valamennyien ugyanazt tesztelik Ha az egyikkel kapcsolatban programhiba van, akkor valószínűleg a másikkal kapcsolatban is Ha az egyikkel kapcsolatban nincs programhiba, akkor valószínűleg a másikkal kapcsolatban sincs

44 A tesztelés tárgyára irányuló technikák #7
Határoló érték tesztelés Az ekvivalencia osztály értékek halmazából áll Ha le tudjuk képezni ezeket az értékeket a számegyenesre, akkor a határoló értékek az osztály legkisebb és legnagyobb értékei A határoló érték tesztelésnél ezeket az értékeket teszteljük, továbbá a közelükben fekvő további értékeket is

45 A tesztelés tárgyára irányuló technikák #8
Állapot tesztelés A program működése közben egyik állapotából másik állapotába mehet át Adott állapotban bizonyos bemenő értékek elfogadhatóak, míg másik állapotban nem. Például bizonyos mezők akár el is szürkülhetnek, vagy nem lehet oda adatot bevinni, míg máskor igen A helyes érték bevitelekor a program tesz valamit, és nem tesz olyat, amit nem tehet meg Az állapot tesztelés során a tesztelő végigmegy a programon és az ilyen típusú működéseket teszteli körültekintően

46 A tesztelés tárgyára irányuló technikák #9
Specifikáció alapú tesztelés Ebben az esetben a tesztelés azoknak a kívánalmaknak a tesztelésére vonatkozik, amelyeket a programmal szemben támasztottak Ezeknek a kívánalmaknak a tesztelése általában igen/nem típusú válasszal fejeződik be Ezek a kívánalmak rendszerint megjelennek a program dokumentációban, kézikönyvben, a piacra kerülést kísérő egyéb dokumentumokban, hirdetésekben, valamint a technikai támogatásra vonatkozó leírásokban, amelyeket a felhasználókhoz eljuttatnak Követelmény alapú tesztelés A követelmény alapú tesztelés során kitérnek mindazon szempontok ellenőrzésére, amelyek szerepelnek a dokumentumokban