Szoftver min ség és menedzsment

Szoftver min ség és menedzsment 12. Mérési alapfogalmak. Dr. Balla Katalin

Mérési alapfogalmak Mi a mérés? Miért mérünk? Egy kis méréselmélet Direkt és indirekt mérések Mérési skálák Objektív és szubjektív mérések Mérés a szoftvergyártásban A szoftvermérés története A szoftvermérés tárgya Lehetséges szoftver - mér számok Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 2

Mérés egy összehasonlítás: a megmérend dolognak, tulajdonságnak a hasonlítása, viszonyítása egy ugyanolyan jelleg, de jól ismert és szélesebb körben elfogadott dologhoz, tulajdonsághoz, amit mértéknek nevezünk (Szentes) az a folyamat, amelynek során a valós világ elemeinek attribútumaihoz számokat vagy szimbólumokat rendelünk, abból a célból, hogy valamilyen, jól meghatározott szabály alapján leírjuk, jellemezzük ket. (Fenton) Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 3

A mérés története Megfigyelés, szemlélés összehasonlítás Az összehasonlítandó dolgok közös viszonyítási alapja: mérték láb, arasz, könyök különbözhet egyénenként etalon (egységes alapmérték) A mindennapi tevékenységekkel kapcsolatos mérések, mértékek (mér számok, metrikák) hossz, súly, id, térfogat stb. A mérés bizonyos szabályokhoz kötött Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 4

A mérés története Változások a mértékekben pl: a h mérséklet mérése: i.e. 2000: besorolás, melegebb, mint.... 1600: Az els h mér 1720: Fahrenheit skála 1742: Celsius skála 1854: Abszolút 0 fok, Kelvin skála Ma: mindent szeretünk megmérni. Ez jó lehet. De: Sok esetben nem értjük eléggé a mérés tárgyát, célját Nem jól választunk mér számot Össze nem ill dolgokat próbálunk összehasonlítani pl. IQ-teszt pl.: hosszmérték: 1 m: a Föld egyenlít jének negyvenmilliomod része 1 m: a 86-os tömegszámú kriptonatom narancsszín színképvonala vákuumban mért hullámhosszának 1650763.73-szorosa Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 5

Miért mérünk ma? Valamilyen céllal. Nem tudjuk irányítani azt, amit nem tudunk megmérni. (Tom DeMarco) Azért mérünk, hogy dolgokat, összefüggéseket megértsünk hogy irányítani tudjuk az eseményeket hogy az elkészült dolgokat, elvégzett feladatokat értékelni tudjuk, össze tudjuk hasonlítani egymással hogy a jöv ben bekövetkez eseményeket minél pontosabban meg tudjuk jósolni Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 6

Miért mér a... Menedzser: hogy nyereséges árat tudjon meghatározni - mérnie kell a költségeket hogy az alkalmazottak bérét meg tudja határozni - mérnie kell a teljesítményt hogy reális terveket tudjon készíteni - mérnie kell a lefutott projekteket, több szempontból is hogy fel tudja mérni, szükséges-e egyik vagy másik új technológiát / eszközt bevezetni a cégnél - mérnie kell az eszközök jellemz it... Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 7

Miért mér a... Szoftverfejleszt védi magát, ha méri a specifikáció változásait védi magát, ha az átadási kritériumokat pontosan és mérhet en meg tudja határozni szeretné bizonyítani, hogy mennyire komplex feladatot oldott meg / mennyire komplex rendszert fejlesztett esetleg a szoftvertermék jellemz it min síttetnie kell meg kell becsülnie, hogy egy feladat mennyi ideig fog tartani... Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 8

Eredményes méréshez... Érteni kell, hogy milyen elem (objektum) milyen vonatkozását (attribútumát) mérjük, és miért A sok lehet ség közül ki kell tudnunk választani az adott célnak megfelel t Jó mér számot és mérési módszert kell választani A mérés eredményét elemezni kell és fel kell használni Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 9

A jó mér számok kritériumai Watts, 1987: Objektivitás: Az eredménynek függetlennek kell lennie minden szubjektivitástól. Nem számíthat, hogy ki végzi a mérést. Megbízhatóság: Az eredmény legyen pontos és megismételhet. Érvényesség: A mér szám a helyes jellemz t mérje. Szabványosság: A mér szám legyen egyértelm és tegye lehet vé az összehasonlítást. Összehasonlíthatóság: A mér szám legyen összehasonlítható más, azonos típusú mér számokkal. Gazdaságosság: Minél egyszer bb és olcsóbb egy mér szám alkalmazása, annál jobb. Hasznosság: A mér számnak egy igényhez kell kapcsolódnia, nem lehet önmagáért való. Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 10

Egy kis méréselmélet Direkt és indirekt mérések Mérési skálák Objektív és szubjektív mérések Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 11

Direkt és indirekt mérés Direkt mérés egy attribútum vagy entitás mérése nem feltételezi más attribútumok vagy entitások bevonását. (pl. hosszúság) Indirekt mérés egy attribútum vagy entitás mérése csak további entitások vagy attribútumok bevonásával lehetséges (pl. s r ség = tömeg / térfogat) Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 12

A mérések eredménye Igyekszünk a megfigyelt rendszer elemeit egy számokkal jelölt rendszerbe leképezni Cél, hogy a numerikus rendszerben az attribútumok milyenségét jelöl számértékekkel valamilyen m veleteket végezzünk, s ebb l megértsük a milyenségüket A leképezéshez használt rendszer megszabja, hogy milyen típusú elemzést végezhetünk a mért értékekkel A különbségek miatt bevezették a mérési skálákat. Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 13

Mérési skálák A tulajdonság különböz állapotai közötti viszonyok határozzák meg a mérési skálákat. Alapvet mérési skálák: nominális (nominal) rendezési (ordinal) intervallum (interval) arány (ratio) abszolút (absolute) Minél több összehasonlítási, m veleti lehet ség van egy skálán, annál gazdagabb az a skála Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 14

Mérési skálák Nominális skála bizonyos kategóriához való hozzátartozás kifejezésére nem tartalmaz sorrendet m veletei: =, = / Pl: entitások címkézése, osztályozása hiba: 1, ha specifikációs hiba hiba: 2, ha tervezési hiba hiba: 3, ha kódolási hiba Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 15

Mérési skálák Rendezési skála Elemek közötti sorrend fejezhet ki. A sorrend valamilyen attribútum szerint alakul ki. m veletei: =, =, / <, > Pl: preferencia, keménység, leveg min sége, intelligencia tesztek Kód komplexitása: 1, ha triviális 2, ha egyszer 3, ha közepes 4, ha komplex 5, ha nem érthet Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 16

Mérési skálák Intervallum skála a mért értéket ekvivalens intervallumok számával fejezzük ki Sorrend kifejezésre kerül m veletei: =, =, / <, >, +, - Pl: relatív id (naptári), h mérséklet egy adott esemény bekövetkezésének ideje a projektben» A projekt kezdetét l számított 87. nap. Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 17

Mérési skálák Arány skála kifejez sorrendet van egy nulla elem (azt jelöli, hogy az illet attribútum hiányzik) m veletei: =, =, <, >, +, -, / / Pl: idintervallum, hosszúság szoftverkód hossza fizikai objektumok hossza Lényeg: lehet ség arra, hogy megállapítsuk (pl): egy elem kétszer olyan hosszú, mint egy másik. Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 18

Mérési skálák Abszolút skála A mérés egy bizonyos entitás elemeinek megszámlálását jelenti Egyetlen leképezés lehetséges, az aktuálisan számolt szám A mérés eredményével mindenfajta aritmetikai analízis értelmes. Pl: egy adott személy életkora ( a leélt éveket meg kell számolni) egy adott program forrássorainak száma De: nem abszolút mér számai: a forrássorok száma a kód hosszának (mert ugyanazt 100, 1000 sorban is lehet mérni) az évek száma az életkornak (mert ugyanazt hónapokban, napokban stb. is lehet mérni) Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 19

Objektív és szubjektív mér számok Objektivitásra törekszünk A szubjektív mér számok is jók lehetnek ha megértjük a szubjektív mér szám korlátait Pl: egy specifikáció min ségének meghatározása 1: rossz, 5: jó Ha pl. az interfészre vonatkozó követelmények között sok rossz szerepel, ezt felül kell vizsgálni Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 20

Szubjektív mér számok a szoftver esetében Fontos és jó, de nem biztos, hogy szigorú értelemben vett mérés Példák: Tetszési skála: Pl: A program megbízható (Teljesen egyetértek, egyetértek, nem tudom, nem értek egyet, egyáltalán nem értek egyet) Er ltetett besorolás: n alternatíva, 1(legrosszabb)-t l n (legjobb)-ig Pl: soroljuk be a következ szv modulokat a karbantarthatóság nehézsége szerint. 1 : legkevésbé nehéz, 5 : legnehezebb Gyakorisági skála Pl: milyen gyakran fagy le a rendszer? (állandóan, gyakran, néha, ritkán, soha) Rendezési skála Pl: milyen gyakran fagy le a rendszer? (1: óránként, 2: naponta, 3: hetente, 4: havonta, 5: évente néhányszor, 6: évente egyszer v. kétszer, soha) Összehasonlítás Pl: A és B: 1:sokkal jobb 5 : nagyjából azonos.10: sokkal rosszabb Numerikus skála Pl: 1: nem fontos 10: fontos Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 21

A szoftver mérése Miért más? Összetett jelenség gyorsan változik a felhasználási folyamata, nehéz állandó mértékeket találni nehéz a mér számok és mérési eljárások hitelességének igazolása Akkor került el térbe, amikor a számítástechnikai alkalmazásokban a szoftverköltségek megn ttek a hardverköltségekhez képest (kb. 1970) Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 22

A szoftvermérés története A szoftver mérésének skora, primitív mér számok Utasításstatisztikák Hibastatisztikák Programok irányított gráf reprezentációja szögpontok: a program utasításai élek: minden szögpontból azokba és csak azokba a szögpontokba mutat irányított él, amelyek az adott szögpont által képviselt utasítás lehetséges rákövetkez utasításainak felelnek meg Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 23

A szoftvermérés története A vezérlési struktúra bonyolultságának mér számai Ciklomatikus szám n számú szögpontot és e számú élt tartalmazó p komponensb l álló G gráfra a gráf ciklomatikus száma: e-n+p. Ha a vizsgált program vagy modul 1 komponensb l áll, akkor a ciklomatikus szám: e-n+1. (komponens: összefügg részgráf. Összefügg egy gráf, ha bármelyik két szögpontja között létezik út.) A keresztez dési pontok száma A vezérlés folyamatkomplexitása Elérhet ség, vezérlési s r ség, vezérlési utak száma A vezérlési struktúra entrópiaszer mértékei Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 24

A szoftvermérés története A hívási hierarchia mérése A komponensek elérhet sége, tesztelhet sége A rendszerstruktúra entrópiájának mértékei A Myers-féle stabilitási mérték A hívási gráf partíciói és komplexitása A Halstead - féle mér számok 1979. A szoftver mérend tulajdonságait olyan számokkal méri, amelyek bármiféle megfeleltetés vagy reprezentáció alkalmazása nélkül magából a programból közvetlenül megfigyelhet k, megállapíthatók. A 4 legfontosabb alapfogalom: a programban szerepl különböz operátorok száma, különböz operandusok száma, összes operátorok száma, összes operandusok száma Implementációs szint, a nyelv szintje A szellemi ráfordítás mértéke Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 25

A szoftvermérés története Összetett mértékek A komponensekre és a bel lük összeálló rendszerre vonatkozó mértékeknek együttes kezelését, kombinációját adják. A McClure-féle komplexitási modell vezérlési változók és ezeknek a program moduljaihoz való viszonya segítségével 3 lépésben eljut egy, a teljes program bonyolultságára jellemz mér számhoz Programrendszerek logikai stabilitása a funkcionális változtatási hatások továbbterjedése elleni védettség Az Oviedo-féle komplexitási modell Algoritmus + adatok = program A TRW komplexitásmodellje Pl: logikai komplexitás: L TOT = LS / EX + L loop + L IF +L BR LS: a logikát befolyásoló utasítás száma, EX: az összes végrehajtható utasítás száma,, L loop = a ciklusok komplexitásának mér száma, L IF = az IF utasítások bonyolultságának mér számai,,, L BR = az ugrások számnak ezredrésze Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 26

A szoftvermérés története 0pUKHW MHOOHP].DSFVROyGyNULWpULXP $MiQORWW SOPHWULNiUD PHWULNiN V]iPD Olvashatóság Használhatóság Karbantarthatóság 2 3 Gunning (1968) Gordon (1979) Hiba el UHMHO]pV Helyesség 2 Halstead (1977) Hiba érzékelés Helyesség 1 Remus és Zilles (1981) Komplexitás Megbízhatóság Karbantarthatóság 7 6 McCabe (1976) McCabe (1976) Mean time to failure Megbízhatóság 5 Musa(1975) Modularitás Karbantarthatóság 4 Kentger (1981) Tesztelhet VpJ Karbantarthatóság 5 Paige (1980) Más Metrikák és mérhet jellemz k kapcsolata: Hordozhatóság Használhatóság Kiterjeszthet VpJ Integritás Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 27 1 2 1 1 Gilb (1977) (Gillies: Software quality.theory and management, 1992)

A szoftvermérés története A különböz min ségi attribútumok mérésére ajánlott mér számok: 0LQ VpJLDWWULE~WXP /pwh] OHtUW PHWULNiNV]iPD karbantarthatóság 18 megbízhatóság 12 használhatóság 4 helyesség 3 integritás 1 kiterjeszthet VpJ 1 hordozhatóság 1 hatékonyság 0 adaptálhatóság 0 együttm N GpVLNpV]VpJ 0 újrafelhasználhatóság 0 (Watts, 1987) Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 28

Tipikus szoftver-mér számok Direkt mér számok (példák): forráskód hossza tesztelési folyamat id tartama a tesztelés során megtalált hibák száma egy programozó által a projekten töltött id Indirekt mér számok (példák): programozó teljesítménye: megírt LOC / ember-hónap 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öv. sz. tesztelési hatékonysági arány: tesztelt elemek száma / összes elem száma hulladék-arány : a hibajavítás ráfordítása / a projekt teljes ráfordítása Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 29

Tipikus szoftver - mér számok (QWLWiV $WWULE~WXP 0pU V]iP Befejezett projekt Id WDUWDP A kezdést ODEHIHMH]pVLJHOWHOWKyQDSRNV]iPD Befejezett projekt Id WDUWDP A kezdett ODEHIHMH]pVLJHOWHOWQDSRVV]iPD Programkód Hosszúság Forrássorok száma (LOC) Programkód Hosszúság Végrehajtható utasítások száma Integrációs tesztelési folyamat Id WDUWDP A tesztelési folyamat kezdetét ODYpJpLJHOWHOW órák száma Integrációs tesztelési folyamat Hibamegtalálás Az 1000 forrássorban (KLOC) talált hibák száma aránya Tesztel Hatékonyság Az 1000 forrássorban (KLOC) talált hibák száma Programkód Min VpJ Az 1000 forrássorban (KLOC) talált hibák száma Programkód Megbízhatóság Mean time to failure CPU órákban Programkód Megbízhatóság A hibák megjelenésének aránya CPU órákban (Fenton, Pfleeger: Software Metrics. A rigorous and practical approach.1997.) Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 30

Bels és küls attribútumok Bels attribútumok: azon attribútumai, amelyek csakis a mérés tárgyát képez objektumtól magától függenek és közvetlenül mérhet k (általában direkt mér számokkal mérhet k) Szoftver esetében: a tesztelés során talált hibák száma, kód hossza Küls attribútumok: azon attribútumok, amelyek csak a mérés tárgyának a környezethez való viszonyát figyelembe véve értelmesek és mérhet ek (általában indirekt mér számokkal mérhet k) szoftver esetében: folyamatok költség-hatékonysága, termék használhatósága, termék hordozhatósága, programozók hatékonysága... Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 31

A szoftvermérések célja Folyamatok, er sségek, gyengeségek megértése További folyamatok becslése, tervezése Fejl dés helyes irányának meghatározása (pl. jó-e, ha egy adott technológiát választunk?) Min ségellen rzés és - biztosítás Megbízhatóság bizonyítása Termék méretének becslése Adatgy jtés vállalati stratégiai célból Projektek el rehaladásának követése Kollektív memória kialakítása... Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 32

Miért kell szoftverméréseket végezni? 1. A szoftver megértése céljából alapmodellek és kapcsolatok folyamatok alapvet jellemz i 2. A szoftvergyártási folyamat irányítása céljából tervezés és becslés a valós értékek követése a tervezettekhez képest validációs modellek alkalmazása 3. Folyamatjavítás irányítása céljából a folyamatok megértése a folyamatok felmérése a folyamatok szabványosítása / újrafelhasználhatóvá tétele (Software Measurement Guidebook, NASA, Software Engineering Laboratories, NASA-GB-001-94) Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 33

A szoftver mérésének tárgya Mér szám Min ségi attribútum Definíció -HOOHP] N Folyamat Termék Er forrás 2EMHNWXPRN Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 34

A szoftver mérésének tárgya Mér szám Min ségi attribútum Definíció Termék M szaki folyamat PM folyamat Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 35

A szoftver mérésének tárgya Választani kell a mérhet elemek között Küls és bels attribútumok minden esetben megkülönböztetésre kerülnek A választást mérési módszereket leíró megközelítések, modellek segíthetik de dönteni nekünk kell! Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 36

A szoftvertermék mérése Boehm Felhasználói alapszempontok (3): ahogy van használhatóság, általános felhasználhatóság, karbantarthatóság Min ségfaktorok (7): 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 Szoftvermin ség-jellemz k (12): eszközfüggetlenség, teljesség, pontosság, konzisztencia, eszközhatékonyság, elérhet ség, kommunikatívitás, strukturáltság, öndokumentáltság, tömörség, olvashatóság, b víthet ség McCall Felhasználói alapszempontok (3): termék m ködés, termék felülvizsgálat, termék-átvitel Min ségfaktorok (11): felhasználási kényelem, integritás, hatékonyság, helyesség, megbízhatóság, karbantarthatóság, tesztelhet ség, módosíthatóság, újrahasználhatóság, hordozhatóság, együttm ködési képesség Szoftvermin ség- jellemz k (22): m köd képesség, elsajátíthatóság, kommunikativítás, I/O mennyiség, I/O gyakoriság, a hozzáférés szabályozottsága, a hozzáférés felügyeltsége, tárolási hatékonyság, m ködési hatékonyság, követhet ség, teljesség, pontosság, hibat r képesség, konzisztencia, egyszer ség, tömörség, felszereltség, b víthet ség, általánosság, öndokumentáltság, modularitás, gépfüggetlenség, szoftverfüggetlenség, a kommunikáció elterjedtsége, az adatábrázolás elterjedtsége Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 37

3ULPDU\XVHV,QWHUPHGLDWH FRQVWUXFWV 3ULPLWLYHFRQVWUXFWV Device independence &ULWHULD Operability Training )DFWRU Usability 8VH Portability Completeness Communicativeness I/O volume, I/O rayte Integrity As is utility Reliability Accuracy Consistency Access control, access audir Storage efficiency Efficiency Product operation General utility Efficiency Device efficiency Acessibility Execution efficiency Traceability Completeness Correctness Reliability Human engineering Communicativeness Accuracy Maintainability Maintainability Testability Understandability Modifiability Structuredness Self descriptiveness Conciseness Legibility Augmentability Metrics Error tolerance Consistency Simplicity Conciseness Instrumentation Expandability Generality Testability Flexibility Reusability Product revision McCall model Self-descriptiveness Boehm model Modularity Machine independence Portability Product transition Sw system independence Comms commonality, Data commonality Interoperability Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 38

A szoftvertermék mérése ISO 9126 : Szoftvertermék min ségi attribútumai ISO 9126-1: Szoftvertermék min sége. Min ségi modell ISO 9126-2: Szoftvertermék min sége. Küls mér számok ISO 9126-3: Szoftvertermék min sége. Bels mér számok ISO 9126-4: Szoftvertermék min sége. Alkalmazási min ség mér számok A különböz min ségi attribútumok és mér számok kapcsolata Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 39

ISO 9126 min. modell quality in use effectiveness productivity safety satisfaction functionality reliability usability efficiency maintainability portability accuracy suitability interoperability compliance security maturity fault tolerance recoverability availability understandability learnability operability time behaviour resource utilisation analysability changeability stability testability adaptability installability co-existence conformance replaceability Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 40

Az alkalmazási min ség Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 41

A termék attribútumainak mérése az ISO9126-ban Részletes útmutatók a küls, bels és használat során tapasztalt min ségi attribútumok mérésére Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 42

Küls metrikák. Érettségi (maturity) mér számok (példa) Az érettség a megbízhatóság egyik al-jellemz je. Megbízhatóság: érettség, hibat rés, visszaállíthatóság, megfelel ség 0pU V]iP QHYH Hibas U VpJ $ PpU V]iP FpOMD Hány hibát észleltek? $ONDOPD]iVLPyG 6]iPROiVNpSOHW $PpUWpUWpN puwhoph]pvh Meg kell számolni az észlelt hibákat, és ki kell számolni a s U VpJ NHW Hibas U VpJ; észlelt hibák száma / termék mérete 0<=X Függ a tesztelési fázistól. A tesztelés végén az a jó, ha ez a szám minél kisebb 0pUpVLVNiOD abszolut 0pUWpUWpN WtSXVD X = számolt érték termék mérete: számolt érték $PpUpV EHPHQHWH tesztelési jelentés, problémajelent és, m N GpVL jelentés.ln KDV]QiOKDWMiNIHO DPpUpV HUHGPpQ\pW Fejleszt Tesztel Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 43

0pU V]iP QHYH Funkcionális alkalmasság A funkcionális implementáció teljessége A funkcionális implementáció lefedettsége A funkcionális specifikáció stabilitása Bels metrikák. Alkalmassági (suitability) mér számok (példa) $ PpU V]iP FpOMD Mennyire megfelel HN (adekvátak) a vizsgált funkciók? Milyen a megfelel HQ implementált funkciók aránya a követelményb en meghatározott funkciók számához képest? A fejlesztés életciklusa alatt mennyire stabil a funkcionális specifikáció? $ONDOPD]iVLPyG 6]iPROiVNpSOHW $PpUWpUWpN puwhoph]pvh Mérjük, hogy mekkora a megfelel Ãfunkciók aránya a megadott feladat elvégzését implementáló összes funkcióhoz képest Felülvizsgálat Felülvizsgálat Megszámoljuk azokat a funkcionális specifikációkat, amelyeket meg kellett változtatni a fejlesztés során X = 1 A/B A = azon funkciók száma, amelyek m N GpVpEHQÃproblémát észlelünk B= a vizsgált funkciók száma X=1-A/B A= a felfedezett hiányzó funkciók száma B = A követelményspecifikáció ban meghatározott funkciók száma X = A / B A = a megfelel HQ implementált funkciók száma B = A követelményspecifikáció ban leírt funkciók száma X = 1-A/B A= a fejlesztés során megváltozott funkciók száma B= a követelményspecifikáció ban leírt funkciók száma, vagy bármilyen funkcionális komplexitásra / méretre utaló szám 0<=X<=1 Annál adekvátabb, minél közelebb van 1-hez 0<=X<=1 Annál teljesebb, minél közelebb van 1-hez 0<=X<=1 Annál jobb, minél közelebb van 1- hez 0<=X<=1 Annál jobb, minél közelebb van 1- hez 0pUpVLVNiOD 0pUWpUWpN WtSXVD $PpUpV EHPHQHWH.LN KDV]QiOKDWMiNIHO DPpUpV HUHGPpQ\pW Felhasználó Fejleszt Funkcionalitás : megfelel ség, pontosság, együttm ködés, biztonság, összeegyeztethet ség Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 44 abszolut abszolut abszolut abszolut X = szám / szám A = számolt érték B = számolt érték X = szám / szám A = számolt érték B = számolt érték X = szám / szám A = számolt érték B = számolt érték A = számolt érték B = méret X = Számolt érték / méret Követelményspecifikáció, tervezés, forráskód, felülvizsgálati jelentés Mennyire teljes az implementáció? Követelményspecifikáció, tervezés, forráskód, felülvizsgálati jelentés Követelményspecifikáció, tervezés, forráskód, felülvizsgálati jelentés Követelményspecifikáció, felülvizsgálati jelentés Felhasználó Fejleszt Felhasználó Fejleszt Fejleszt karbantartó

Használat során tapasztalt min ség metrikák. Alkalmassági (suitability) mér számok (példa) Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 45

Termékre vonatkozó mérési terv kialakítása Az üzleti terület módszeres vizsgálata a felhasználóval közösen Az üzleti folyamat jellemz inek azonosítása A szoftvertermék jellemz inek azonosítása A felhasználók jellemz inek azonosítása A termék min ségi jellemz inek meghatározása a felhasználó szemszögéb l 6. A min ségi jellemz k lefordítása a fejleszt k nyelvére 7. A jellemz knek megfelel mér számok kiválasztása Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 46

A lényeges min ségi jellemz k kiválasztása Üzleti folyamat Min ségi jellemz k Szoftver termék Lefordítási folyamat Min ségi profil Vev / felhasználó Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 47

Min ségi profil -példák PHWULNiN $]DONDOPD]iVN UQ\H]HWMHOOHP] L 6ZPLQMHOOHP] N Emberéletek függnek t le Integritás Megbízhatóság Helyesség Ellen rízhet ség Tartós "cikk" (hosszú életciklus) Karbantarthatóság B víthet ség Kísérleti rendszer vagy sok módosítás Hajnlékonyság (flexibility) Kísérleti technológia hardver tervezésbenhordozhatóság Sok változás az életciklus folyamán Flexibilitás Újrahasználhatóság Kiterjeszthet ség Valós idej rendszer Hatékonyság Megbízhatóság Helyesség Fedélzeti számítógépes alkalmazás Hatékonyság Megbízhatóság Helyesség Bizalmas információk kezelése Integritás Megbízhatóság Helyesség Ellen rízhet ség Kölcsönösen kapcsolódó rendszerek Együttm ködési képesség Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 48 ISO 9126 alapján

A projektmenedzsment folyamatok és er források mérése Projekthez kapcsolódó mér számok, projektkövetés során mérhet k Bels folyamat-attribútumok: a projektre fordított id, a szükséges er források és a költségek. Ezek mérése egyszer feljegyzést jelent: fel kell jegyezni egyrészt a tervezett értékeket, másrészt a projekt végrehajtása során megvalósult értékeket. Az id mérésénél hasznos lehet, ha a tevékenységeket a lehet legjobban alábontjuk, és az egyes résztevékenységekre fordított id t jegyezzük fel. Küls folyamat-attribútumok: pl: ellen rízhet ség, megfigyelhet ség, stabilitás. Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 49

A projektmenedzsment folyamatok és er források mérése Direkt mérések: Felhasznált költségek $FWXDO&RVWRI:RUN3HUIRUPHG$&:3 Adott idõszakra ütemezett munkára tervezett költség %XGJHW&RVWRI :RUN6KFHGXOHG%&:6 Megvalósult érték =Elvégzett munkára tervezett költség (DUQHG 9DOXH %XGJHW&RVWRI:RUN3HUIRUPHG%&:3 Indirekt mérések: Elvégzett munka alapján számolt költségeltérés &RVW9DULDQFH&9 %&:3$&:3 Elvégzett munka és eltelt id alapján számolt költségeltérés 6FKHGXOH 9DULDQFH69 %&:3%&:6 Költség szerinti teljesítmény index &RVW3HUIRUPDQFH,QGH[ &3, %&:3$&:3 Id zítés szerinti teljesítmény index 6FKHGXOH3HUIRUPDFH,QGH[ 63, %&:3%&:6 Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 50

A projektmenedzsment folyamatok és er források mérése Az er források mérése fontos lehet feljegyezni, hogy szám szerint mennyi és milyen típusú er forrást használtunk fel. Emberi er forrásoknál jól használható adat lehet az er forrás szakmai tapasztalata és termelékenysége, mert ezekb l következtetni lehet egy bizonyos típusú feladat emberi er forrás-igényeire. Az emberi er források termelékenységének mérése nem egyszer feladat, mert pl. az adott id alatt megírt kód nagysága nem biztos, hogy releváns információt szolgáltat. Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 51

A m szaki folyamatok mérése Id, költség, er forrás-felhasználás itt is fontos lehet Hibák mérése a különböz folyamatokban (szám, típus/ súlyosság, kijavítás ráfordítása) A folyamat típusától függ en, további attribútumokat lehet meghatározni Tervezésnél: kezdeti követelmények száma, módosult követelmények, új követelmények, törölt köv. Kódolásnál figyelhet a komplexitás (pl. funkciópont analízissel), valamint a kódolás során felfedezett és kijavított hibák száma és típusa. Tesztelésnél figyelhet a megtalált hibák száma és súlyossága, kijavítás ráfordítása. Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 52

Fenton kerete a szoftvermérésekre (QWLWiVRN $WWULE~WXPRN 7HUPpN %HOV DWWULE~WXP. OV DWWULE~WXP Specifikáció méret, újrahasználhatóság, modularitás, szintaktikai helyesség mindenre kiterjed karbantarthatóság Tervek méret, újrahasználhatóság, modularitás, összekapcsolódás, összetartozás, funkcionalitás min VpJNRPSOH[LWiV karbantarthatóság Kód méret, újrahasználhatóság, modularitás, összekapacsolódás, funkcionalitás, algoritmikus komplexitás, strukturáltság Teszt adatok méret, lefedettség min VpJ )RO\DPDW Specifikáció készítése id UiIRUGtWiVPHJYiOWR]RWW megbízhatóság, használhatóság, karbantarthatóság min VpJN OWVpJVWDELOLWiV specifikációk száma Részletes tervezés id UiIRUGtWiVPHJWDOiOWVSHFLILNiFLyV költség-hatékonyság hibák száma Tesztelés id UiIRUGtWiVPHJWDOiOWKLEiNV]iPD költség-hatékonyság, stabilitás (U IRUUiV Alkalmazottak életkor, ár termelékenység, tapasztalat, intelligencia Csapatok méret, kommunikáció, strukturáltság termelékenység, min VpJ Szoftver ár, méret használhatóság, megbízhatóság Hardver ár, gyorsaság, memória mérete megbízhatóság Irodák méret, h PpUVpNOHWIpQ\ komfortosság, min VpJ Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 53

Mir l volt szó... Mér szám Min ségi attribútum Definíció Termék M szaki folyamat PM folyamat Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 54