Szoftver min ség és menedzsment 12.. Dr. Balla Katalin 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 2002 / 2003 1
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 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 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 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 2002 / 2003 2
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 2002 / 2003 3
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 2002 / 2003 4
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 2002 / 2003 5
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: id intervallum, 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 2002 / 2003 6
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 2002 / 2003 7
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érhetsé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 2002 / 2003 8
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].DSFVROyGyÃNULWpULXP $MiQORWW SOÃPHWULNiUD 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 (Gillies: Software quality.theory and management, 1992) Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 27 1 2 1 1 Gilb (1977) 2002 / 2003 9
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 VpJLÃDWWULE~WXP /pwh] ÃOHtU W PHWULNiNÃV]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 GpVLÃNpV]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 OÃDÃEHIHMH]pVLJÃHOWHOWÃKyQDSRNÃV]iPD Befejezett projekt Id WDUWDP A kezdett OÃDÃEHIHMH]pVLJÃHOWHOWÃQDSRVÃV]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 OÃDÃYpJpLJÃHOWHOW ó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 2002 / 2003 10
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 2002 / 2003 11
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 2002 / 2003 12
A szoftvertermék mérése Boehm Felhasználói alapszempontok (3): termék Felhasználói alapszempontok (3): m ködés, termék felülvizsgálat, termék-átvitel ahogy van használhatóság, általános felhasználhatóság, karbantarthatóság Min ségfaktorok (11): felhasználási kényelem, integritás, hatékonyság, helyesség, megbízhatóság, Min ségfaktorok (7): hordozhatóság, megbízhatóság, hatékonysá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 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 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 3ULPLWLYHÃFRQVWUXFWV Device independence &ULWHULD Operability Training )DFWRU Usability 8VH Communicativeness Portability Completeness 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 Metrics Error tolerance Consistency Simplicity Conciseness Instrumentation Expandability Testability Flexibility Product revision McCall model Augmentability Generality Reusability Self-descriptiveness Boehm model Modularity Machine independence Portability Product transition Sw system independence Interoperability Comms commonality, Data commonality 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 2002 / 2003 13
ISO 9126 min. modell quality in use effectiveness productivity safety satisfaction functionality reliability usability efficiency maintainability accuracy suitability interoperability compliance security maturity fault tolerance recoverability availability understandability learnability operability time behaviour resource utilisation analysability changeability stability testability adaptability installability portability 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 2002 / 2003 14
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 PpU V]iP FpOMD Hibas U VpJ Hány hibát észleltek? $ONDOPD]iVLÃPyG 6]iPROiVÃÃÃNpSOHW $ÃPpUWÃpUWpN puwhoph]pvh Meg kell számolni Hibas U VpJÃ;Ã 0<=X az észlelt hibákat, észlelt hibák száma Függ a és ki kell számolni / termék mérete tesztelési a s U VpJ NHW fázistól. A tesztelés végén az a jó, ha ez a szám minél kisebb 0pUpVLÃVNiOD abszolut 0pUWÃpUWpN WtSXVD X = számolt érték termék mérete: számolt érték $ÃPpUpV.LN EHPHQHWH KDV]QiOKDWMiNÃIHO DÃPpUpV HUHGPpQ\pW tesztelési Fejleszt jelentés, Tesztel problémajelent és, m N GpVL jelentés Dr. Balla Katalin Szoftver min ség és menedzsment - 12. 43 Bels metrikák. Alkalmassági (suitability) mér számok (példa) 0pU V]iP $ $ONDOPD]iVLÃPyG 6]iPROiVÃÃÃNpSOHW $ÃPpUWÃpUWpN 0pUpVLÃVNiOD 0pUWÃpUWpN $ÃPpUpV.LN QHYH PpU V]iP puwhoph]pvh WtSXVD EHPHQHWH KDV]QiOKDWMiNÃIHO FpOMD DÃPpUpV HUHGPpQ\pW Funkcionális Mennyire Mérjük, hogy mekkora a X = 1 A/B 0<=X<=1 abszolut X = szám / szám Követelményspecifikáció, Fejleszt Felhasználó alkalmasság megfelel HN megfelel Ãfunkciók A = azon funkciók Annál adekvátabb, A = számolt érték (adekvátak) a aránya a megadott száma, amelyek minél közelebb B = számolt érték tervezés, vizsgált feladat elvégzését m N GpVpEHQÃproblémát van 1-hez forráskód, funkciók? implementáló összes észlelünk felülvizsgálati funkcióhoz képest B= a vizsgált funkciók jelentés száma A funkcionális Mennyire Felülvizsgálat X=1-A/B 0<=X<=1 abszolut X = szám / szám Követelményspecifikáció, Fejleszt Felhasználó implementáció teljes az A= a felfedezett hiányzó Annál teljesebb, A = számolt érték teljessége implementáció? B = A van 1-hez forráskód, funkciók száma minél közelebb B = számolt érték tervezés, követelményspecifikáció felülvizsgálati ban meghatározott jelentés funkciók száma A funkcionális Milyen a Felülvizsgálat X = A / B 0<=X<=1 abszolut X = szám / szám Követelményspecifikáció, Fejleszt Felhasználó implementáció megfelel HQ A = a megfelel HQ Annál jobb, minél A = számolt érték lefedettsége implementált implementált funkciók közelebb van 1- B = számolt érték tervezés, funkciók száma hez forráskód, aránya a B = A felülvizsgálati követelményb követelményspecifikáció jelentés en ban leírt funkciók száma meghatározott funkciók számához képest? A funkcionális A fejlesztés Megszámoljuk azokat a X = 1-A/B 0<=X<=1 abszolut A = számolt érték Követelményspecifikáció, karbantartó Fejleszt specifikáció életciklusa funkcionális A= a fejlesztés során Annál jobb, minél B = méret stabilitása alatt specifikációkat, megváltozott funkciók közelebb van 1- X = Számolt érték / felülvizsgálati mennyire amelyeket meg kellett száma hez méret jelentés stabil a változtatni a fejlesztés B= a funkcionális során követelményspecifikáció specifikáció? ban leírt funkciók száma, vagy bármilyen funkcionális komplexitásra / méretre utaló szám 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 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 2002 / 2003 15
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 $]ÃDONDOPD]iVÃÃN UQ\H]HWÃMHOOHP] L 6ZÃPLQÃMHOOHP] N PHWULNiN 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 2002 / 2003 16
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: ellenrí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Ã&RVWÃRIÃ:RUN3HUIRUPHGÃÃ$&:3 Adott idõszakra ütemezett munkára tervezett költség %XGJHWÃ&RVWÃRI :RUNÃ6KFHGXOHGÃ%&:6 Megvalósult érték =Elvégzett munkára tervezett költség (DUQHG 9DOXHÃ ÃÃ%XGJHWÃ&RVWÃRIÃ:RUNÃ3HUIRUPHGÃÃ%&:3 Indirekt mérések: Elvégzett munka alapján számolt költségeltérés &RVWÃ9DULDQFHÃÃ&9 Ã%&:3ÃÃ$&:3 Elvégzett munka és eltelt id alapján számolt költségeltérés 6FKHGXOH 9DULDQFHÃÃ69 %&:3%&:6 Költség szerinti teljesítmény index &RVWÃ3HUIRUPDQFHÃ,QGH[ &3, %&:3$&:3 Id zítés szerinti teljesítmény index 6FKHGXOHÃ3HUIRUPDFHÃ,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 2002 / 2003 17
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, mindenre kiterjed szintaktikai helyesség karbantarthatóság Tervek méret, újrahasználhatóság, modularitás, összekapcsolódás, összetartozás, min VpJÃNRPSOH[LWiV karbantarthatóság funkcionalitás Kód méret, újrahasználhatóság, modularitás, megbízhatóság, használhatóság, összekapacsolódás, funkcionalitás, karbantarthatóság algoritmikus komplexitás, strukturáltság Teszt adatok méret, lefedettség min VpJ )RO\DPDW Specifikáció készítése id ÃUiIRUGtWiVÃPHJYiOWR]RWW min VpJÃN OWVpJVWDELOLWiV specifikációk száma Részletes tervezés id ÃUiIRUGtWiVÃPHJWDOiOWÃVSHFLILNiFLyV költség-hatékonyság hibák száma Tesztelés id ÃUiIRUGtWiVÃPHJWDOiOWÃKLEiNÃV]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 PpUVpNOHWÃIpQ\ 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 2002 / 2003 18