Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

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.

Hasonló előadás


Az előadások a következő témára: "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."— Előadás másolata:

1 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 Lefordítási folyamat Lefordítási folyamat Minőségi profil Minőségi jellemzők / attribútumok Minőségi jellemzők / attribútumok Szoftver termék Szoftver termék Üzleti folyamat Üzleti folyamat Vevő / felhasználó

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

13 Szoftverminőségi modellek • Szoftvertermék alapú megközelítés: – Az ISO 9126 szabvány 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

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 Folyamatok Folyamat érettségi szintek 0. Nem létező 1. Végrehajtott 2. Menedzselt 3. Meghatározott 4. Jósolható 5. Optimalizált •Vevővel-értékesítővel kapcs. •Fejlesztési •Támogató •Menedzsment •Szervezeti

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) 2.Menedzselt (Managed) 3.Meghatározott (Defined) 4.Minőségileg menedzselt (Quantitatively Managed) 5.Optimalizáló (Optimizing )

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


Letölteni ppt "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."

Hasonló előadás


Google Hirdetések