Upload
galvin-cohen
View
31
Download
2
Embed Size (px)
DESCRIPTION
Szoftverminőség menedzsment. (VIMIM235-Autonóm és hibatűrő informatikai rendszerek). Szőke Ákos [email protected]. Bevezető. - PowerPoint PPT Presentation
Citation preview
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
http://csse.usc.edu/tools/COCOMOSuite.php
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ó
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
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)
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ő
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)
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