SZOFTVER- MINŐSÉGBIZTOSÍTÁS

Átírás

1 SZOFTVER- MINŐSÉGBIZTOSÍTÁS DR. SZIRAY JÓZSEF DR. BENYÓ BALÁZS HECKENAST TAMÁS 2005.

2 Minőség koncepciók Különböző minőség fogalmak A minőség filozófiai értelmezése A minőség fogyasztói értelmezése A minőség termelői értelmezése A minőség társadalmi értelmezése A minőség minőségügyi értelmezése 2

3 A minőség filozófiai értelmezése A minőség általános filozófiai értelmezése a dolgok tulajdonságokkal történő leírása. A minőség értékszemléletű filozófiai értelmezése szubjektív, értékrenden alapuló, személyhez kötött. 3

4 A minőség fogyasztói értelmezése A termék és a fogyasztási folyamat minőségének fogyasztói értelmezése a minőség értékszemléletű filozófiai értelmezésén alapul. A fogyasztási folyamat minőségét a fogyasztó szempontjából azok a funkciók határozzák meg, amelyek alkalmassá teszik a terméket a fogyasztás során a fogyasztó által igényelt funkciók kielégítésére. Ez másképp a termék hasznosságának is nevezhető. 4

5 A minőség termelői értelmezése Az igénykielégítési folyamat termelői minősége attól függ, hogy a termelési folyamat és a termék a termelői érdekeltek szempontjából megfelelő-e, így a termelés folyamata az érdekeltek számára hasznos-e, gazdaságos-e, kellően veszélytelen-e. 5

6 A minőség társadalmi értelmezése Az igénykielégítési folyamat társadalmi minősége attól függ, hogy a termelési és fogyasztási folyamatok a társadalom számára kellően hasznosak-e és védelmi, különösen életvédelmi, valamint környezetvédelmi szempontból veszélytelenek-e. A minőség társadalmi értelmezése alapján a minőségügy magában foglalja a fogyasztóvédelem mellett a biztonságtechnikát, a munkavédelmet, az élet és egészségvédelmet, az erkölcsvédelmet, a környezetvédelmet, továbbá a vagyon és a tűzvédelmet is. 6

7 A minőség minőségügyi értelmezése A jó minőség négyféle követelmény egyensúlya műszaki (fizikai, kémiai, biológiai, stb.) /technical/ erkölcsi /ethical/ piaci /marketing/ gazdasági /economical/ 7

8 A minőség mérése a minőséget meghatározó tulajdonságok mérése általában nem objektív a minőséget meghatározó funkciók, tulajdonságok jelentős része nem mérhető a minősítés szubjektív, mivel a minőség nem más, mint az emberek értékítélete, és nincs társadalmilag elfogadott értékrend a minősítés időben és környezettől függően változó sokan megfelelő háttér ismeret hiányában minősítenek, ami a minősítés jóságát ronthatja 8

9 Szoftver-minőség (Software quality) A szoftver-minőség egy többdimenziós fogalom. A minőség azt jelenti, hogy a fejlesztési folyamat a specifikációs követelményeket kielégíti 9

10 Szoftver-minőség (Software quality) Szoftverek esetében nehézségek akadnak A specifikációnak a felhasználó áltak kívánt termék karakterisztikáját kell követni, azonban a fejlesztési szervezetnek is vannak követelményei amelyek nem szerepelnek a specifikációban. A szoftver specifikációk rendszerint nem teljesek. 10

11 Szoftver-minőség (Software quality) A szoftver-minőség menedzserek 3 fajta tevékenységért felelősek: Minőségbiztosítás (quality assurance): szervezeti eljárásokat, valamint szabványokat kell rögzíteni, amelyek jó minőségű szoftverekehez vezetnek. Minőség tervezés (quality planning): ki kell választani az alkalmas eljárásokat, és szabványokat, és ezeket illeszteni kell a speciális szoftver projektekhez. Minőség szabályozás (quality control): biztosítani kell, hogy ezeket az eljárásokat és szabványokat követi a szoftver fejlesztő csapat 11

12 A szoftver minősége Minősítési, illetve kiértékelési szempontok Minőségfaktorok (hordozhatóság, megbízhatóság, hatékonyság, felhasználási kényelem, tesztelhetőség, érthetőség, módosíthatóság), minőségjegyek Szoftverjellemzők (eszközfüggetlenség, teljesség, pontosság, konzisztencia, hatékonyság, elérhetőség, strukturálhatóság, dokumentáltság, tömörség, érthetőség, olvashatóság, bővíthetőség Szoftvermértékek, szoftvermérőszámok 12

13 Szoftver metrikák A szoftver metrika egy mérési típus, amely egy szoftverrendszerhez, folyamathoz, vagy kapcsolódó dokumentációhoz tartozik. A metrikák két osztályba sorolhatók az egyik az ellenőrző (control metrics), a másik a prediktor (predictor metrics) metrika 13

14 Prediktor és ellenőrző metrikák szoftver termék (software product) szoftver folyamat (software process) prediktor mérések (predictor measurements) ellenõrzõ mérés (control measurement) menedzsment döntések (management decisions) 14

15 Prediktor és ellenőrző metrikák Az ellenőrző metrika biztosítja az információt a folyamat minőségéről, és ezért kapcsolódik a termék minőségéhez. A prediktor metrika a termék minőségének előzetes megjósolására használható. 15

16 Külső és belső jellemzők A külső jellemzők olyan dolgok, amelyek csak a szoftver üzembehelyezése után fedezhetők fel. A belső jellemzőket azonban a közvetlenül szoftverből határozhatjuk meg. 16

17 Külső és belső jellemzők kapcsolata Nyomonkövethetõség (Maintainability) Eljárás paraméterek száma Megbízhatóság (Reliability) Ciklomatikus komplexitás Hordozhatóság (Portability) Programméret kódsorban Használhatóság (Usability) Hibaüzenetek száma Felhasználói segédlet hossza 17

18 Külső és belső jellemzők kacsolata Ahhoz, hogy a belső tulajdonságok mérése hasznos prediktora legyen a külső szoftver-karakterisztikának, három feltételnek kell teljesülnie: A belső jellemzőket pontosan kell mérni. A mért és a külső tulajdonsági jellemzők között kapcsolatnak kell lenni. A kapcsolat érthető, valós, valamint egy formulával, vagy modellel leírható legyen. 18

19 Metrikák alkalmazása A modell formalizálás a modellben szereplő paraméterek meghatározását, ezek beállítását a létező adatok használatával. A modellfejlesztés statisztikai technikai gyakorlatot követel, tehát ebbe a folyamatba statisztikusokat kell bevonni. Számos nagy cég gyűjti és használja ezeket a metrikákat a fejlesztések folyamán. Növekszik a metrikák ipari használatának is a fontossága. 19

20 Termék minőségmértéke Minőségbiztosító csoportnak kell kiértékelni a metrikát egy lokális adatokat használó szisztematikus úton a helyi eljárásokat és szabványokat is figyelembe véve. Alapvetően a rendszer minden egyes komponensét függetlenül vizsgálják, és a metrika különböző értékeit összehasonlítják, mind egymással, mind régebbi projektből származó adatokkal. 20

21 A termék mérésének folyamata mérések választása rendhagyó komponensek vizsgálata a kiértékelendõ komponensek kiválasztása rendhagyó mérések meghatározása komponensek karakterisztiikájának mérése 21

22 A tervezés minőségmértéke Legfontosabb tervezési tulajdonság a karbantarthatóság. közvetlenül nem mérhető A karbantarthatóság kapcsolódik: Kohézióhoz (Cohesion):A komponens részei milyen szorosan kapcsolódnak? Csatoláshoz (Coupling): Mennyire független a komponens? Érthetőséghez (Understandability): Milyen könnyű megérteni a komponens funkcióját? Alkalmazhatósághoz (Adaptability): Milyen könnyű komponenst cserélni? 22

23 A karbantarthatóság mérése A komponensek csatolása mérhető a komponensek-közti kapcsolatok számával A komponensek érthetősége, alkalmazhatósága nem mérhető közvetlenül. Azonban kapcsolat van ezen tulajdonságok, és a komponens komplexitása között. 23

24 Kapcsolódó metrikák Constantine és Yourdon (1979) javaslatára a tervezés társítása meghatározható a tervezési komponensek fan-in, és fan-out mérésével. A fan-in azon komponensek száma, amelyek ezt a komponenst meghívják, a fan-out pedig azon komponensek számát jelenti, amelyeket a komponens meghív. 24

25 Kapcsolódó metrikák Henry és Kafura javasolta a komponens komplexitásának meghatározására a következő képletet az információs Fan-in, valamint Fan-out-okkal: Complexity = Length x (Fan-in x Fan-out) 2 ahol, a length a hosszúságnak egy mértéke, ami lehet pl a programkódok sorainak száma. 25

26 A program minőségmértéke A programban lévő hibák megjóslására az alábbi metrikák használhatók: Kódhossz (Length of code) Ciklomatikus komplexitás (Cyclomatic complexity) Azonosítók hossza (Length of identifiers) Feltételes szerkezetek mélysége 26

27 Komponensek komplexitása Egy eljárás ciklomatikus komplexitása a komponensek belső komplexitásának mértéke. Problémák: A program döntési komplexitását méri, amely feltételes állítások, valamint előfeltételekkel vannak meghatározva. Ha a program adat-irányított, akkor a ciklomatikus komplexitásra alacsony értéket ad, ami még mindig elég komplex, és nehezen érthető. Ugyanazon súllyal szerepelnek a beágyazott, és nem beágyazott körök. Azonban a mélyen beágyazott feltételes struktúrákat nehezebb megérteni, mint a nem-beágyazottat. 27

28 Komponensek komplexitása Oviedo (1980) program komplexitási metrika C = ae + bn, ahol a: folyamráf éleinek száma, N: adatentitásokra való hivatkozások száma, amelyek nincsenek deklarálva a komponensben 28

29 Szoftver megbízhatóság Formálisan a megbízhatóságot egy speciális célra egy adott környezetben egy adott idő alatti hibamentes műveletek valószínűségeként definiálják. A szoftver megbízhatóság egy függvénye a szoftver bizonyos felhasználói által tapasztalt hibák számának. 29

30 Szoftver hibák A szoftver hiba (failure) a szoftver futása közben jelentkezik. Ez az eset, amikor a szoftver nem teljesíti a felhasználó által elvárt szolgáltatást. Szoftver hiba (fault) lehet programozási vagy tervezési hiba, amikor is a szoftver nem felel meg a rendszer specifikációnak. A szoftver hiba (fault) okozza a szoftver rendellenességét (failure), amikor a hibás kód olyan input halmazzal fut, amely a szoftver hibát eredményezi. 30

31 A szoftver megbízhatóság és hibák A szoftverrendszer egy leképezés, egy input halmazból egy output halmazba. Az input halmaz egy részhalmaza tartalmazza azokat az inputokat, amelyek hatására a program rossz outputokat generál. A szoftver megbízhatósága pedig annak a valószínűségéhez kapcsolódik, hogy a program egy bizonyos futtatása során a rendszer inputja eleme-e annak a részhalmaznak, amely a hibás outputokat okozza. 31

32 A szoftver megbízhatóság és hibák Mills (1987) megmutatta, hogy a szoftver hibák nem egyforma valószínűséggel okozzák a szoftver rendellenességét. A program megbízhatósága leginkább a hibás outputokat okozó inputok halmazától függ. Szoftver ritkán használt részeiből ha eltávolítjuk a szoftver hibákat, akkor a megbízhatóság csak kis mértékben növekszik. 32

33 Formális módszerek Megbízhatóbb szoftvert eredményez ha formális módszereket használunk a szoftver fejlesztésre Azonban a formális specifikáció még nem garantálja hogy a gyakorlati használatban a szoftver megbízható lesz. Az okok a következők: A felhasználók valódi igényeit a specifikáció nem mindig tükrözi teljesen. A bizonyítás is tartalmazhat hibát. Ha a rendszert nem úgy használják, ahogyan előre látható volt, akkor a bizonyítás is hibás lehet. 33

34 Megbízhatóság és teljesítmény A megbízhatóság növelése gyakran a program hatékonyságénak csökkenését is okozhatja Gyakran a megbízhatóság előnyt élvez a hatékonysággal szemben a következő okok miatt: A számítógépek jelenleg olcsók és gyorsak A felhasználó hajlamos arra, hogy eldobja a nem megbízható szoftvereket A rendszer hibák költsége óriási lehet A nem-megbízható rendszert nehéz fejleszteni A nem-hatékonyság előre megjósolható A nem-megbízható szoftverek információvesztést okozhatnak 34