Szoftverminsg menedzsment VIMIM 235 Autonm s hibatr informatikai

Szoftverminőség menedzsment (VIMIM 235 -Autonóm és hibatűrő informatikai rendszerek) Szőke Ákos aszoke@mit. bme. hu

Bevezető � Fontos, hogy a szoftver termékek minőségét mérni/értékelni tudjuk, előrejelezni ill. becsülni tudjuk a kibocsátást követő hibák számát illetve a két hibamegjelenés közötti időt � A fontosság magyarázata ◦ ◦ Fejlesztési folyamat irányítása Szoftver termék kibocsátása (mikor? ) Karbantarthatóság, karbantartási költségek Megrendelő megelégedése 2

Tipikus kérdések a szakterületen �A rendszer megbízhatósága növekszik, csökken vagy stabil? � Mi a valószínűsége, hogy a kibocsátást követően hiba fordul elő? � A kibocsátást követően mennyire megbízható szoftvert adunk át? � Melyik a legkevésbé és a leginkább megbízható komponense a rendszernek? � Mit tegyünk, ha növelni/csökkenteni szeretnénk a megbízhatóságot? � A fejlesztési folyamat mely fázisa okozza leginkább a rendszer alacsony megbízhatóságát? 3

Miért fontos a szoftverminőség menedzsment? � Szoftverek bármely más ember által készített terméknél jobban kritizáltak… � Gyenge szoftverminőség az egyik legdrágább dolog az emberiség történetében. ◦ Az USA-ban > $150 milliárd per év (cca. 30 e milliárd Ft) ◦ Az USA-n kívül > $ 500 milliárd per év (cca. 100 e milliárd Ft) �A szofver projektek 15%-a félbemarad a gyenge minőség miatt � Szoftverminőség növelés minden iparban kulcskérdés

? Alacsony és magas minőség költsége Mit jelentenek a diagramok tendenciái? Patologikus Egészséges Költség A gyenge minőség a kódolás végéig olcsóbb. A kódolást befejezve a jó minőség az olcsóbb. (Átmeneti előny. . . ) Idő

Célkitűzések � Bevezessük a szofver minőség fogalmát és a minőséget befolyásoló faktorokat � Megmutassuk a minőségmenedzsment folyamatot és fő tevékenységeit � Bemutassuk a szoftverminőség során leggyakrabban használt metrikákat és használatukat � Áttekintsük a legfontosabb minőségmenedzsment modelleket � Elmagyarázzuk a minőségmenedzsment szerepét és fontosságát 6

Tartalomjegyzék � Szoftverminőség definiálása � Szoftverminőség metrikák szerepe és használata � Fontosabb megbízhatósági és minőségmenedzsment modellek áttekintése � COQUAMO � Rayleigh modell bemutatása 7

Szoftverminőség 8

Mi a minőség? • A minőség köznapi nézetben: Valami jó dolog, de mennyiségileg nem kifejezhető Valami luxus dolog • A minőség szakértői nézetben: Követelményeknek való Crosby 1979 megfelelőség (Conformace to requirements) Használatra való alkalmasság (Fitness for use) Juran 1970 9

Minőség mérésének nehézsége � Szükségesebb a „követelmények tervezésének kreativitása”, mint a termék maga… …egyfajta művészet. Melyik a magasabb minőségű? 10

Mi a szoftver minőség? /1 � Követelményeknek megfelelőség való ◦ A követelmények egyértelműen meghatározottak és a terméknek ennek kell megfelelnie ◦ Bármely eltérés a követelményektől hibaként van meghatározva ◦ Egy jó minőségű termék kevesebb hibát tartalmaz � Használatra való alkalmasság Ami specifikálva van Amit a szoftver csinál Ami a felhasználók szükséglete ◦ A felhasználói elvárásoknak, szükségleteknek kell megfelelni ◦ Jó minőség jobb felhasználói megelégedettséget jelent 11

Mi a szoftver minőség? /2 �A minőség ISO 8402 szerinti definíciója (Quality management and quality assurance) ◦ „The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs” �A minőség ISO 9126 szerinti definíciója (Software Quality Assurance) ◦ „The totality of features and characteristics of a software product that bear on its ability to satisfy stated or implied needs” 12

Mi van hatással a szoftver minőségre? � Kiszállítás dátuma: ◦ Projekt határidőknek való megfelelés ◦ Megfelelő időben a piacra való kijutás � Költség: ◦ Megfelelőség a becsült (tervezett) projekt költségeknek � Teljesítmény: ◦ A kijelölt időtartamban a rendszer megfelelően működjön pl. megbízhatóság (reliability), rendelkezésre állás (availability) 13

Szoftverminőség: MS Windows XP End-User License Agreement 11. LIMITED WARRANTY FOR PRODUCT ACQUIRED IN THE US AND CANADA. Microsoft warrants that the Product will perform substantially in accordance with the accompanying materials for a period of ninety days from the date of receipt. (…) If an implied warranty or condition is created by your state/jurisdiction and federal or state/provincial law prohibits disclaimer of it, you also have an implied warranty or condition, BUT ONLY AS TO DEFECTS DISCOVERED DURING THE PERIOD OF THIS LIMITED WARRANTY (NINETY DAYS). (…) Some states/jurisdictions do not allow limitations on how long an implied warranty or condition lasts, so the above limitation may not apply to you. (…) YOUR EXCLUSIVE REMEDY. Microsoft's and its suppliers' entire liability and your exclusive remedy shall be, at Microsoft's option from time to time exercised subject to applicable law, (a) return of the price paid (if any) for the Product, or (b) repair or replacement of the Product, that does not meet this Limited Warranty and that is returned to Microsoft with a copy of your receipt. (. . ) This Limited Warranty is void if failure of the Product has resulted from accident, abuse, misapplication, abnormal use or a virus.

Szoftverminőség menedzsment (SQM) terjedelme � Minőség menedzsment különösen fontos nagy és komplex rendszereknél. A dokumentáció az előrehaladást rögzítik és támogatják a folytonos fejlesztést a fejlesztő csapat változásaival összhangban (a ceremónia kikényszeríti) � Kisebb rendszereknél a minőség menedzsmentnek kevéssé a dokumentáltságra, hanem inkább a minőségi kultúra kialakítására szükséges fókuszálnia (a kultúra biztosítja)

Minőség menedzsment tevékenységei � Minőségbiztosítás - Quality assurance (QA) ◦ Megalapozza a szervezeti procedúrákat és standardokat a minőséghez � Minőségtervezés - Quality planning (QP) ◦ Kiválasztja a alkalmazható procedúrákat és standardokat az adott projekthez, melyek később módosíthatók � Minőségkontroll - Quality control (QC) ◦ Biztosítja a procedúrákat és standardokat, melyet a szoftverfejlesztő csapatnak követnie kell A minőségmenedzsmentnek a projekt menedzsmenttől elkülönítve szükséges működnie

Minőségmenedzsment és szoftverfejlesztés (QA) (QP) (QC)

Szoftverminőség metrikák 18

Szoftver metrikák � Szoftver sorolni: metrikákat három kategóriába lehet ◦ Termék metrikák (product metrics), pl. méret, komplexitás, teljesítmény, minőség szint ◦ Folyamat metrikák (process metrics), és pl. hiba elhárítás hatékonysága a fejlesztés alatt, tesztelési hibák megjelenésének mintája, a javítási folyamat válaszideje ◦ Projekt metrikák (project metrics) pl. fejlesztők száma, projekttagok alkalmazási mintája a projekt teljes életciklusa alatt, költség, ütemezés, produktivitás

Szoftverminőség metrikák Szoftver metrikák részhalmaza, amely a termék, a folyamat és a projekt területek minőségi aspektusával foglalkozik � A szoftverminőség mérnökség (software quality engineering) lényege, hogy a folyamat (in-process), végtermék (end-product) minőségek közötti kapcsolatot vizsgálja � Szoftverminőség metrikák � ◦ Végtermék minőség metrikák � Lényegi termék minőség � Megrendelői megelégedés Termék minősége a kibocsátást után ◦ Folyamat minőség metrikák � Hiba sűrűsége a rendszer teszt alatt Termék minősége a fejlesztés alatt � Hibák megjelenésének mintája a rendszer teszt alatt ◦ Karbantartás minőség metrikák � backlog management index Termék minősége a karbantartás alatt

Rovartan � Különböző kifejezések használtak a szoftver problémákra…mi a következőket használjuk: ◦ Failure: A rendszer futása alatt a működésében való bármely eltérés a megrendelő/felhasználó elvárásaitól, szükségleteitől ◦ Hiba (defect, fault, bug): a failure okozója ◦ Error: emberi tevékenység, amely a hibát előidézi a szoftverben Error Hiba 21

Példa: Hibanyilvántartás 22

Végtermék-minőség metrikák lényegi termék minőség � Lényegi termék minőség ◦ Szokásosan a szoftverben előforduló funkcionális hibákkal (ráta), vagy két hiba között eltelt idővel jellemzett ◦ A fejlesztői csapat szempontjából fontos �A kapcsolódó két metrika: ◦ Hibasűrűség (rate) inkább kereskedelmi rendszereknél ◦ Mean time to failure (MTTF) inkább biztonságkritikus rendszereknél Korrelálnak, de mégis különbözőek! Reliability growth model-ek két típusához kapcsolódnak ◦ Példák: � Windows 2000 Professional MTTF: 2893 óra vagy 72 munkahét � Windows NT Workstation MTTF: 919 óra vagy 23 munkahét � Windows 98 MTTF: 216 óra vagy 5 munkahét

Hibasűrűség számítás �A számítás nem triviális, mivel két mérés között a forráskód gyakran változik � A következő összefüggés jellemzni a kiszállított (Shipped Source Instructions (SSI)) és a változott (Changed Source Instructions (CSI)) kódsorhossz közötti relációt (Minden kódmérés Lines-of-code (LOC)-on alapul):

További hibasűrűség metrikák �A hibasűrűségből további hasznos metrikát származtathatunk: ◦ Összes hibaszám per SSI (Total defects per SSI) a termék kódminőségének a mérésére ◦ Éles hibaszám per SSI (Field defects per SSI) az éles rendszerből származó hibák száma ◦ Kibocsátásból származó hibák (Release-origin defects) éles vagy belső hibaszám per CSI a fejlesztés minőségének mérésére Fejlesztő csapat veszi észre Megrendelő veszi észre 25

Példa: Megrendelői szempont � Termék kezdeti kibocsátása Megrendelői szemmel: 64% ◦ KCSI = KSSI = 50 KLOC Defects/KCSI = 2. 0 Összes hibaszám = 2. 0 x 50 = 100 � Második kibocsátás ◦ KCSI = 20 KSSI = 50 + 20 (új & változott KLOC) - 4 (20%-os változást feltételezve) = 66 Defect/KCSI = 1. 8 (10% -os javulást feltételezve) Összes addicionális hibaszám = 1. 8 x 20 = 36 � Harmadik kibocsátás Fejlesztői szemmel: 10% ◦ KCSI = 30 KSSI = 66 + 30 (új & változott KLOC) - 6 (20%-os változást feltételezve) = 90 Megcélzott addicionális hibaszám (nem több, mint az előző kibocsátásban) = 36 Hibaráta az új vagy változott KLOC-hoz: 36/30 = 1. 2 defects/KCSI vagy kisebb 26

Végtermék-minőség metrikák Megrendelői megelégedés � Megrendelői megelégedés ◦ Nem csak a szoftver hibák problémák megrendelői szemmel nézve: használhatósági problémák, nem világos dokumentáció vagy információ a rendszerben, többszörös hibák ◦ A megrendelői szempontból hasznos ◦ Szokásosan probléma per hónap módon számolt � Számítása Problem per User Month (PUM) � PUM szokásosan havi rendszerességgel van kiszámítva miután a szoftver ki lett bocsátva. Ritkán éves bontásban is követik a problémák alakulását.

Folyamat-minőség metrikák – Hibák a rendszerteszt alatt Az egyik célunk, hogy megértsük a fejlesztési folyamatot annak érdekében, hogy javíthassunk rajta (hatékonyság, minőség stb. ). A folyamat minőség metrikák ebben segítenek � A rendszerteszt alatt keletkező hibák száma szokásosan pozitívan korrelál az éles környezetben majd megjelenő hibák számával: Hibasűrűsége a rendszer teszt alatt � � A hibák megjelenésének mintája több információt ad az élesben keletkező hibákra vonatkozóan, mivel következtetni lehet a várható hibaszám a görbe alakja alapján Hibák megjelenésének mintája a rendszer teszt alatt Fontos szempont a tesztelés és az éles működés intenzítás különbsége!

Példa: Hibamegjelenési minták ? � Mi a különbség a két minta között? Mit jelentenek?

Folyamat-minőség metrikák – Hibák a fázisok alatt hibajavítási minta a hibasűrűség metrika egy kiterjesztése � A fejlesztési ciklus valamennyi fázisa alatt (tervezés áttekintés, kód átvizsgálás, formális ellenőrzés, …) követi a hibák javítását � A fázis-alapú hibajavítási minta a teljes fejlesztési folyamat hibajavítási képességét jellemzi � Fázis-alapú

Példa: Két hibajavítási minta ? � Mi a különbség a két minta között? Mit jelentenek? Jelölés: HL des. rev. (I 0) LL des. rev. (I 1) code insp. (I 2) unit test (UT) comp. test (CT) system test (ST)

Karbantartási minőség metrikák � Amikor a szoftver termék fejlesztési befejeződik és kiszállítódik a megrendelőnek/ kikerül a piacra, akkor a szoftver karbantartási fázisba kerül az életciklusán belül � A hibák és problémák megjelenésének számossága jelentősen függ az őt megelőző fejlesztési folyamattól � A karbantartás alatt a cél, hogy a megjelenő hibák mielőbb javítva legyenek. A gyors javítás nagy hatással van a vevői megelégedésre

Karbantartási minőség metrika – Backlog Management Index � Backlog Management Index (BMI) ◦ Metrika, mely a backlog elemek (megoldandó feladatok) kezelését támogatja (nyitott, lezárt, …) ◦ Tipikusan heti, havi riportok formájában készül � BMI számítása: ◦ Ha a BMI nagyobb, mint 100%, az azt jelenti, hogy a backlog mérete csökkent, ellenkező esetben növekszik 33

Példa: Heti probléma riport 34

? BMI diagram példák: trend és pseudo-control diagram Mit jelentenek a diagramok tendenciái? Jelölés: UCL: upper control limit LCL: lower control limit Havi riport Kiszállítás Jól működő folyamat Stabilizálás Mit jelent, ha meghaladjuk az UCL-t vagy az LCL-t? 35

Megbízhatósági és minőségmenedzsment modellek

Megbízhatóság és Reliability Engineering � Megbízhatóság (Reliability): Annak a valószínűsége, hogy a rendszer valamely funkciója egy specifikált időtartamban hiba nélkül képes működni � Reliability Engineering: a szoftver termékek megbízhatóságával foglalkozik � Reliability Engineering célja: Szoftver termékek fejlesztése, amely figyelembe veszi az alábbi rész célokat ◦ “minimális” fejlesztési idő alatt készüljön el ◦ “minimális” fejlesztési költséget igényeljen ◦ “maximális” megbízhatóságot nyújtson Több célfüggvényes optimalizálási feladat 37

Hardver megbízhatósági modellek � Egyenletes modell ◦ Hiba valószínűsége nem változik � Exponenciális modell ◦ A hiba valószínűsége az idő előrehaladtával csökken Hibás alkatrészt kicseréltük Pl. : az újonnan megvett autóban a szervízelés javítja a hibákat 38

Hardver és szoftver megbízhatóság görbéi Hardver megbízhatósági görbe („Kádgörbe”) Szoftver megbízhatósági görbe Különbség: 1. Szoftvernek nincs növekvő hibarátája 2. Szoftver megbízhatósági görbében a hibajavítás után egy-egy drasztikus hibaráta emelkedés figyelhető meg (hibajavítás további hibákat hoz be) 39

Szoftver vs. hardver megbízhatóság � Szoftver megbízhatósági görbe nem növekszik az idő előre haladtával (nincs öregedés) � Hardver hibák főként fizikai hibák pl. elhasználódás miatt � Szoftver hibák főként tervezési/programozási hibák, melyeket nehezebb mérni, modellezni, megtalálni � Hardver hibát gyakran az alkatrész cseréjével lehet javítani, ezért nincs növekedés a megbízhatóságban � Szoftver hibákat a kód változtatásával lehet javítani, ezért van növekedés a megbízhatóságban Következmény: hardver megbízhatósági modellek nem használhatók a szoftver megbízhatóság modellezésére 40

? Példa: 15 POSIX operációs rendszer tesztelési eredménye Mit mutat a diagram? Jelentős romlás Jelentős javulás 41

Megbízhatósági és minőségmenedzsment modellek � Szoftver megbízhatósági modellek a szoftver termékek megbízhatóságának mérésére illetve a kibocsátást követő hibák becslésére. A becslés két dolog miatt fontos: ◦ Egy objektív állítás a termék minőségéről ◦ Erőforrás tervezéshez használható a karbantartási fázishoz Kibocsátást követően fontos! � Szoftver minőség modellek a szoftver minőségének becslésére szolgál, amikor fejlesztés alatt van a termék. (Kevéssé pontos modellek, mint a megbízhatósági modellek) A becslés egy dolog miatt fontos: ◦ Korai jelzést biztosít a problémákról és ezért még időben tenni lehet a minőség javítása érdekében Kibocsátást előtt fontos!

Mwegbízhatósági modellek típusai � Két alapvető modellt lehet megkülönböztetni: ◦ Statikus modell: a projekt vagy program jellemzőire építve vetíti előre a szoftverben lévő hibák számát Finomabb felbontás esetén jobb (pl. program modul) Durvább felbontás esetén jobb (termék szintjén) Dinamikus modell: szokásosan statisztikai eloszlásokra épülnek, felhasználják az aktuális fejlesztés adatait hogy a végtermék megbízhatóságát előre vetítsék �Teljes folyamatra vonatkozóan (pl. Rayleigh) �Tesztelési fázisra vonatkozóan (pl. Reliability Growth Modellek)

Előrejelzés vs. becslés � Szoftver modellezési technikáknak két alapvető technikája va: előrejelzéses modellezés és becsléses modellezés � Mindkettő a hibák számának előre vetítését tűzi ki célul, azonban a lényegi különbség közöttük: ELŐREJELZŐ MODELLEK BECSLŐ MODELLEK ADAT REFERENCIA Historikus adatok Adatok az aktuális fejlesztési folyamatból MIKOR HASZNÁLT A FEJELSZTÉSBE N? Gyakran a fejlesztést, vagy tesztelést megelőzően használt; a koncepció kialakítás fázisában is használt Gyakran akkor használt, ha már adatok össze lettek gyűjtve a fejlesztési folyamatból; a koncepció és fejlesztés fáziaiban nem használt (nincsenek adatok) IDŐKERET Előrejelzi a szoftver megbízhatóságát a jövőre vonaktozóan Becsli a megbízhatóságot a jelenre és a jövőre vonatkozóan PÉLDÁK SLIM (Putnam), SEER-SEM, COQUALMO (Boehm) Rayleigh, Jelinski-Moranda, Littlewood, Goel-Okumoto, etc. 44

COQUAMO - egy előrejelző minőségmenedzsment modell

COQUALMO � COQUALMO (COnstructive QUALity MOdel) a COCOMO (COnstructive COst MOdel) kiterjesztése, amely előrejelzi a termékben megmaradó hibák számát ◦ COCOMO II inputjait kiegészíti hibajavítási mintával azért, hogy előrejelezze a belefejlesztett, megtalált és megmaradó hibák számát a követelmény, tervezés és kódolás fázisokra vonatkozóan ◦ 'what-if' analízist tesz lehetőve, amely segít dönteni: �Hibajavítási technikáról (automatikus analízis, átvizsgálás, és végrehajtási teszt) �Szükséges projekttagok számáról és jellemzőiről �A minőségbe való idő/energia/pénz befektetések előnyeiről és hátrányairól �A kiszállítás idejéről 46

CO*MO áttekintés A különböző modellek (n*100) projekt statisztikai elemzéséből állt elő COnstructive Phased Schedule and Effort MOdel COnstructive Rapid Application Development MOdel 47

COCOMOII áttekintés • • • 2 000 -100 000 LOC hosszú projektek voltak vizsgálva (számos programozási nyelv) Három fő verziója van: COCOMO 81, COCOMOII. 1997, COCOMOII. 2000 Jelen áttekintés a COCOMOII. 2000 -t mutatja be Becsült szoftver méret Termék, folyamat, személyi jellemzők Újrahasználás és karbantartás paraméterei Szoftver fejlesztési ráfordítás COCOMO Szoftver fejlesztés ütemetés Szoftver szervezet projekt adatai Paraméterek kalibrálása a szervezet jellemzői alapján 48

COCOMO modell fázisok 49

COCOMOII Project Scale Factor-ok � Az előrejelzést végző személy az egyes faktoroknál megadott osztályozás (rating) definíciója alapján meghatározza a faktor értékét (pl: Precedentness = VL) Jelölés: VL: very low L: low N: normal H: high VH: very high EH: extra high Ratings Project scale factors (W_i) Precedentedness Development Flexibility Architecture/Risk Resolution Team Cohesion Process Maturity Modellben használt paraméter VL L 6, 2 5, 07 7, 07 5, 48 7, 8 4, 96 4, 05 5, 65 4, 38 6, 24 Nom. 3, 72 3, 04 4, 24 3, 29 4, 68 H VH 2, 48 2, 03 2, 83 2, 19 3, 12 1, 24 1, 01 1, 41 1, 56 EH 50

COCOMOII Effort Multipliers (a PA modellhez) Ratings Effort Multipiers /EM_i/ (Cost Drivers) VL L Required Software Reliability Database Size Documentation Match to Lifecycle Needs Product Complexity Required Reusibility Platform attributes Execution Time Constraint Main Storage Constraint Platform Volatility Personnel attributes Analyst Capability Applications Experience Programmer Capability Platform Experience Language and Tool Experience Personnel Continuity Project attributes Use of Software Tools Required Development Schedule 0, 82 0, 91 0, 87 0, 95 Product attributes Multisite Development 0, 81 0, 73 0, 87 Nom. H VH EH 1 1 1, 14 1, 11 1, 17 1, 07 1, 26 1, 28 1, 23 1, 34 1, 15 1, 74 1, 24 1 1 0, 88 0, 91 0, 9 0, 76 0, 85 0, 84 0, 81 Az Early Design nodell 7 1 1, 11 a 1, 29 paramétere 17 1, 63 1 1, 05 1, 17 1, 46 paraméter 1 1, 15 1, 3 összevonásából keletkezik a 1 0, 85 (kezdetben 0, 71 részletek ismertek) 1 0, 88 nem 0, 81 1, 42 1, 22 1, 34 1, 19 1, 29 1, 15 1, 09 1, 12 1, 17 1, 43 1, 09 1, 14 1 1 0, 9 1 0, 78 1 1, 22 1, 09 1 0, 93 0, 86 0, 8 51

COCOMOII modell Boehm 2000 Kalibráció fontos! (A) 52

COCOMOII előrejelzés pontossága � Kalibrációval és kalibráció nélkül A modell felállításához használt projektek száma COCOMO 81 # Projektek 63 81% Ráfordítás Ütemezés 65% COCOMOII. 1997 83 52% 64% 61% 62% COCOMOII. 2000 161 75% 80% 72% 81% 53

Demo: COCOMOII http: //csse. usc. edu/tools/COCOMOSuite. php 54

COQUALMO Áttekintés / 1 � Hibák forrása: ◦ Inception, Elaboration, Construction fázisok (Követelmények, tervezés és kód termékek) 55

COQUALMO Áttekintés / 2 COCOMO II COQUALMO Becsült szoftver méret Termék, folyamat, személyi jellemzők Szoftver fejlesztési ráfordítás és ütemezés Defect Introduction Model Hibasűrűség Hibajavítás képességének szintje • automatikus analízis (Automated analysis), • átvizsgálás (Peer reviews) • végrehajtási teszt (Execution testing and tools) Defect Removal Model Megmaradó hibák száma • Követelményekben • Tervben • Kódban 56

COQUAMO Defect Removal Profile Factor-ok � Az előrejelzést végző személy az egyes faktoroknál megadott osztályozás (rating) definíciója alapján meghatározza a faktor értékét (pl: Precedentness = VL) Jelölés: VL: very low L: low N: normal H: high VH: very high EH: extra high Ratings Defect removal profile factors (DRF_ij) Automated Analysis Peer Reviews Execution Testing and Tools VL L Inception 0. 25 0. 23 Elaboration 0. 28 0. 23 0. 1 0. 38 Construction Nom. 0. 1 0. 4 0. 13 0. 43 0. 2 0. 48 0. 58 H 0. 27 0. 5 0. 28 0. 54 0. 3 0. 69 VH 0. 34 0. 58 0. 57 0. 44 0. 7 0. 65 0. 48 0. 73 0. 78 EH 0. 4 0. 7 0. 6 0. 5 0. 78 0. 7 0. 55 0. 83 0. 88 Ld. COQUALMO_minta_model. xls 57

Defect introduction (DI) modell A kalibráció fontos! (Aj) COCOMOII-ben használt faktorok W_i (5) + EM_i (17) azonosítja a 3 típusú terméket (követelmények, terv és kód) kalibrációs konstans a j-ik termékre hibabevezetési konstansok ami a j-ik termékre és az i-ik faktorra vonatkozik 58

Defect removal (DR) modell A kalibráció fontos! (Cj) azonosítja a 3 típusú terméket (követelmények, terv és kód) kalibrációs konstans a j-ik termékre előrejelzett hibák száma a j-ik termékre vonatkozóan hibajavítás hányada a hibajavító profil a a j-ik termékre és az i-ik faktorra vonaktozóan 59

Demo: COQUALMO COCOMOII-paraméterein felül http: //csse. usc. edu/tools/COCOMOSuite. php 60

További információ � Boehm, Abts, Brown, Chulani, Clark, Horowitz, Madachy, Reifer, Steece, Software Cost Estimation with COCOMO II, Prentice Hall, 2000 � COCOMO Suite of Constructive Cost Models http: //csse. usc. edu/tools/COCOMOSuite. php � Kiindulási pont: http: //csse. usc. edu/csse/index. html 61

Rayleigh - egy becslő minőségmenedzsment model

Rayleigh modell �A Rayleigh modell ◦ Egy parametrikus modell, olyan értelmeben, hogy egy adott statisztikai eloszláson alapul ◦ Miután az eloszlás paraméterei meg lettek becsülve (az aktuális projektből származó adatokból), a projekt hibarátáját előre lehet vetíteni a modell alapján ◦ A modell magába foglalja a hibamegelőzés (korai hibaszám csökkentését) és a korai hibajavítás támogatását ◦ Minőségmenedzsment keretrendszer

Rayleigh modell: A Weibull eloszlás: speciális esete • Rayleigh a. Weibull eloszlás m= 2 esete • Széles körben használt a megbízhatóság modellezésnél • Nagy mennyiségű adat alátámasztja a modell használhatóságát • Használható: 1) erőforrás szükségletek modellezésére 2) hibafelfedés és hibajavítás minták modellezésére PDF = 1 m – alak paraméter c – lépték paraméter (a tm függvénye, a tm azt adja meg, hogy mikor éri el a görbe a maximumot) tm

Rayleigh modell � Az előző PDF formulában a görbe alatti terület mérete 1. Ezért egy K multiplikatív konstanst használunk ami a teljes várható hibaszámot jelöli � Továbbá, ha a következő helyettesítést elvégezzük: �a következőket kapjuk: Ahhoz, hogy specifikáljuk a fenti Rayleight modellt, a folyamatból származó adatokból a K és tm modell paramétereket szükséges megbecsülnünk 65

Példa: Hibajavítás minta Jelölés: HL des. rev. (I 0) LL des. rev. (I 1) code insp. (I 2) unit test (UT) comp. test (CT) system test (ST) general-availability (GA)

Model által alkalmazott feltételezés /1 �A Rayleigh modell a szoftverfejlesztési minőségi modellezése során két alapvető feltételezéssel él: ? ◦ A fejlesztés alatt megfigyelt hibaráta pozitívan korrelál az éles működés során megfigyelt hibarátával Mit mutat a két diagram? Jelölés: HL des. rev. (I 0) LL des. rev. (I 1) code insp. (I 2) unit test (UT) comp. test (CT) system test (ST) general-availability (GA)

Model által alkalmazott feltételezés /2 ◦ Azonos hibabevezetést feltételezve, ha több hiba lesz javítva, akkor kevesebb marad ami az éles működésben jön elő Jelölés: HL des. rev. (I 0) LL des. rev. (I 1) code insp. (I 2) unit test (UT) comp. test (CT) system test (ST) general-availability (GA)

Rayleigh modell implementációk � Rayleigh modell implementáció nem nehéz. Ha a hibák (hibaszám) megbízható, a modell paraméterek statisztikai program csomagokkal könnyen számíthatók ◦ Software LIfe-cycle Model tool (SLIM), and ◦ Software Error Estimation Reporter (STEER)

Összefoglalás 70

Fontosabb gondolatok �A szoftverminőség definíciója, mérésének eszközei � Szoftverminőség menedzsment szerepe a termék fejlesztési folyamatában és a kibocsátást követően � Fontosabb megbízhatósági és minőségmenedzsment modellek használata 71