Szoftverminőség menedzsment

Szoftverminőség menedzsment

(VIMIM235-Autonóm és hibatűrő informatikai rendszerek)

Szőke Á[email protected]

2

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

Bevezető

3

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?

Tipikus kérdések a szakterületen

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. 30e milliárd Ft) ◦ Az USA-n kívül > $ 500 milliárd per év (cca. 100e 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

Miért fontos a szoftverminőség menedzsment?

Alacsony és magas minőség költsége

Requirements Design Coding Testing Maintenance

Költség

Idő

Patologikus

Egészséges

A gyenge minőség a kódolás végéigolcsóbb. A kódolást befejezve a jó minőség az olcsóbb. (Átmeneti előny...)

Mit jelentenek a diagramok tendenciái??

6

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

7

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 modell bemutatása

Rayleigh modell bemutatása

Tartalomjegyzék

8

Szoftverminőség

9

Mi a minőség?• A minőség köznapi nézetben:

Valami jó dolog, de mennyiségileg nem kifejezhetőValami luxus dolog

Crosby 1979

Juran 1970

• A minőség szakértői nézetben:Követelményeknek való megfelelőség (Conformace to requirements)

Használatra való alkalmasság(Fitness for use)

10

Szükségesebb a „követelmények tervezésének kreativitása”, mint a termék maga…

…egyfajta művészet.

Minőség mérésének nehézsége

Melyik a magasabb minőségű?

11

Követelményeknek való megfelelőség◦ 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◦ A felhasználói elvárásoknak,

szükségleteknek kell megfelelni◦ Jó minőség jobb felhasználói

megelégedettséget jelent

Mi a szoftver minőség? /1

Ami specifikálva

van

Ami a felhasználók szükséglete

Amit a szoftver csinál

12

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”

Mi a szoftver minőség? /2

13

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)

Mi van hatással a szoftver minőségre?

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

Software developmentprocess

Quality managementprocess

D1 D2 D3 D4 D5

Standards andprocedures

Qualityplan

Quality review reports

(QP) (QC)(QA)

18

Szoftverminőség metrikák

Szoftver metrikák Szoftver metrikákat három kategóriába lehet

sorolni: ◦ 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

◦ Folyamat minőség metrikák Hiba sűrűsége a rendszer teszt 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 kibocsátást után

Termék minősége a fejlesztés alatt

Termék minősége a karbantartás alatt

21

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

22

Példa: Hibanyilvántartás

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élKorrelá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):

25

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

További hibasűrűség metrikák

Megrendelő veszi észre

Fejlesztő csapat veszi észre

26

Termék kezdeti kibocsátása ◦ 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◦ 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

Példa: Megrendelői szempont

Fejlesztői szemmel: 10%

Megrendelői szemmel: 64%

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!

Mi a különbség a két minta között? Mit jelentenek?

Példa: Hibamegjelenési minták?

Folyamat-minőség metrikák –Hibák a fázisok alatt Fázis-alapú 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

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. (I0)LL des. rev. (I1)code insp. (I2)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

33

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

Karbantartási minőség metrika –Backlog Management Index

34

Példa: Heti probléma riport

35

BMI diagram példák: trend és pseudo-control diagram

Havi riport

Jól működő folyamat

Jelölés:UCL: upper control limitLCL: lower control limit

Mit jelent, ha meghaladjuk az UCL-t vagy az LCL-t?

Kiszállítás

Stabilizálás

Mit jelentenek a diagramok tendenciái??

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

modellek

37

Megbízhatóság (Reliability): Annak a valószínűsége, hogy a rendszer vagy 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

Megbízhatóság és Reliability Engineering

Több célfüggvényes optimalizálási feladat

38

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ávalcsökken

Hardver megbízhatósági modellek

1 ( )

0

t Tf t

t T

0( ) tf t e

Hibás alkatrésztkicseréltük

Pl.:az újonnan megvettautóban a szervízelésjavítja a hibákat

39

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ája2. 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)

40

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

Szoftver vs. hardver megbízhatóság

Következmény: hardver megbízhatósági modellek nem használhatók a szoftver

megbízhatóság modellezésére

41

Példa: 15 POSIX operációs rendszer tesztelési eredményeMit mutat a diagram??

Jelentős javulás

Jelentős romlás

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

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 követően fontos!

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

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)

Finomabb felbontás esetén jobb (pl. program modul)Durvább felbontás esetén jobb (termék szintjén)

44

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és vs. becslés

ELŐREJELZŐ MODELLEK

BECSLŐ MODELLEK

ADAT REFERENCIA

Historikus adatok Adatok az aktuális fejlesztési folyamatból

MIKOR HASZNÁLT A FEJELSZTÉSBEN?

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.

COQUAMO - egy előrejelző

minőségmenedzsment modell

46

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

COQUALMO

47

CO*MO áttekintés

COCOMO II.COCOMO II. Cost drivers

SIZE

COQUALMOCOCOMO II. Cost drivers

Defect Removal Profile factors

Person Months

total number of defects introduced

Estimated number of residual defects

CORADMOCOPSEMOEffort schedule per

phase

Schedule

Schedule per phase

RAD factors

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

48

COCOMOII áttekintés

Becsült szoftver méret

Termék, folyamat, személyi Szoftver fejlesztési ráfordításjellemzők

Újrahasználás és karbantartás Szoftver fejlesztés ütemetésparaméterei

Szoftver szervezet projekt adatai Paraméterek

kalibrálása a szervezet jellemzői

alapján

COCOMO

• 2 000-100 000 LOC hosszú projektek voltak vizsgálva (számos programozási nyelv)

• Három fő verziója van: COCOMO81, COCOMOII.1997, COCOMOII.2000• Jelen áttekintés a COCOMOII.2000-t mutatja be

49

COCOMO modell fázisok

Feasibility

Concept ofOperation

Rqts.Spec.

Plansand

Rqts.

ProductDesign

ProductDesignSpec.

DetailDesignSpec.

DetailDesign

Devel.and Test

AcceptedSoftware

Phases and Milestones

RelativeSize Range x

4x

2x

1.25x

1.5x

0.25x

0.5x ApplicationsComposition

(3 parameters)

Early Design(13 parameters)

Post-Architecture(23 parameters)0.67x

0.8x

50

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)

COCOMOII Project Scale Factor-ok

Project scale factors (W_i)

Ratings

VL L Nom. H VH EHPrecedentedness 6,2 4,96 3,72 2,48 1,24Development Flexibility 5,07 4,05 3,04 2,03 1,01Architecture/Risk Resolution 7,07 5,65 4,24 2,83 1,41Team Cohesion 5,48 4,38 3,29 2,19 1,1Process Maturity 7,8 6,24 4,68 3,12 1,56

Jelölés:VL: very lowL: lowN: normalH: highVH: very highEH: extra high

Modellben használt paraméter

51

COCOMOII Effort Multipliers (a PA modellhez)

Effort Multipiers /EM_i/ (Cost Drivers)

Ratings

VL L Nom. H VH EHProduct attributes

Required Software Reliability 0,82 0,92 1 1,1 1,26Database Size 0,9 1 1,14 1,28Documentation Match to Lifecycle Needs 0,81 0,91 1 1,11 1,23Product Complexity 0,73 0,87 1 1,17 1,34 1,74Required Reusibility 0,95 1 1,07 1,15 1,24Platform attributesExecution Time Constraint 1 1,11 1,29 1,63Main Storage Constraint 1 1,05 1,17 1,46Platform Volatility 0,87 1 1,15 1,3Personnel attributesAnalyst Capability 1,42 1,19 1 0,85 0,71Applications Experience 1,22 1,1 1 0,88 0,81Programmer Capability 1,34 1,15 1 0,88 0,76Platform Experience 1,19 1,09 1 0,91 0,85Language and Tool Experience 1,2 1,09 1 0,91 0,84Personnel Continuity 1,29 1,12 1 0,9 0,81Project attributesUse of Software Tools 1,17 1,09 1 0,9 0,78Required Development Schedule 1,43 1,14 1 1 1

Multisite Development 1,22 1,09 1 0,93 0,86 0,8

Az Early Design nodell 7 paramétere a 17 paraméter összevonásából keletkezik (kezdetben a részletek nem ismertek)

52

COCOMOII modell

adjusted nominal1

*m

ii

PM PM EfforMultiplier

7 Early Design modellben (7 Effort multiplier-ek)m 17 Post Architecture modellben (17 Effort multiplier-ek)m

nominal *( )BPM A Size - productivity (projekt méret constans)A

- LOC of UFPSize5

1

0.91 0.01* ii

B W

project scale factor-ok (PREC,FLEX,RESL,TEAM,PMAT)iW

5

10.91 0.01*

adjusted1

*( ) *i

iW m

ii

PM A Size EfforMultiplier

scale exponentB

Boehm 2000

Kalibráció fontos! (A)

53

Kalibrációval és kalibráció nélkül

COCOMOII előrejelzés pontossága

COCOMO81 COCOMOII.2000COCOMOII.1997

# Projektek 63 83 161

Ráfordítás

Ütemezés

81% 52%64%

75%80%

61%62%

72%81%

65%

A modell felállításához használt projektek száma

54

Dem

o:

CO

CO

MO

II

http://csse.usc.edu/tools/COCOMOSuite.php


55

Hibák forrása:◦ Inception, Elaboration, Construction fázisok

(Követelmények, tervezés és kód termékek)

COQUALMO Áttekintés / 1

56

COQUALMO Áttekintés / 2COCOMO II

COQUALMO

Becsült szoftver méret

Termék, folyamat, személyi jellemzők

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)

Szoftver fejlesztési ráfordításés ütemezés

Megmaradó hibák száma

Defect Introduction

Model

Hibasűrűség

• Követelményekben• Tervben• Kódban

Defect Removal

Model

57

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)

COQUAMO Defect Removal Profile Factor-ok

Defect removal profile factors (DRF_ij)

Ratings

VL L Nom. H VH EHAutomated Analysis

Inception0.1 0.27 0.34 0.4

Peer Reviews 0.25 0.4 0.5 0.58 0.7Execution Testing and Tools 0.23 0.4 0.5 0.57 0.6Automated Analysis

Elaboration0.13 0.28 0.44 0.5

Peer Reviews 0.28 0.4 0.54 0.7 0.78Execution Testing and Tools 0.23 0.43 0.54 0.65 0.7Automated Analysis

Construction0.1 0.2 0.3 0.48 0.55

Peer Reviews 0.3 0.48 0.6 0.73 0.83Execution Testing and Tools 0.38 0.58 0.69 0.78 0.88

Jelölés:VL: very lowL: lowN: normalH: highVH: very highEH: extra high

Ld. COQUALMO_minta_model.xls

58

Defect introduction (DI) modell

3 22

1 1

*( ) *jBEst j ijj i

DI A Size DI

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

jA

ijDI

j

A kalibráció fontos! (Aj)

COCOMOII-ben használt faktorokW_i (5) + EM_i (17)

59

Defect removal (DR) modell

21

, ,1

* * 1Est j j Est j iji

DRes C DI DRF

azonosítja a 3 típusú terméket (követelmények, terv és kód)

kalibrációs konstans a j-ik termékreelőrejelzett hibák száma a j-ik termékre

vonatkozóanhibajavítás hányada a hibajavító profil a a j-

ik termékre és az i-ik faktorra vonaktozóan

,Est jDI

jC

j

ijDRF

A kalibráció fontos! (Cj)

60

Dem

o:

CO

QU

ALM

O


COCOMOII-paraméterein felül


61

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

További információ


http://csse.usc.edu/csse/index.html

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 aWeibull 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

/CDF: ( ) 1m

t cF t e

/PDF: f ( )m

mt cm t

t et c

Weibull eloszlás:

PDF = 1m – alak paraméterc – 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

65

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

Rayleigh modell

2 21/ 2CDF: ( ) 1 mt t

F t K e

2 22

1/ 21PDF: f ( ) mt t

m

t K tet

2mc t

Példa: Hibajavítás minta

Jelölés:HL des. rev. (I0)LL des. rev. (I1)code insp. (I2)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??

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ő


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)

70

Összefoglalás

71

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

Fontosabb gondolatok

Documents

Szoftverminőség menedzsment