710 likes | 845 Views
Szoftverminőség menedzsment. (VIMIM235-Autonóm és hibatűrő informatikai rendszerek). Szőke Ákos aszoke@mit.bme.hu. Bevezető.
E N D
Szoftverminőség menedzsment (VIMIM235-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
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?
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árdper év (cca. 30e milliárd Ft) • Az USA-n kívül > $ 500 milliárdper é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
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
Tartalomjegyzék • Szoftverminőség definiálása • Szoftverminőség metrikák szerepe és használata • Fontosabb megbízhatóságiésminőségmenedzsment modellek áttekintése • COQUAMO modell bemutatása • Rayleigh modell bemutatása
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ó megfelelőség (Conformace to requirements) • Használatra való alkalmasság(Fitness for use) Crosby 1979 Juran 1970
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ű?
Mi a szoftver minőség? /1 • 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? /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 servicethat 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 productthat bear on its ability to satisfy stated or implied needs”
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)
Szoftverminőség: MS Windows XP End-User License Agreement 11. LIMITED WARRANTY FOR PRODUCT ACQUIRED IN THE US AND CANADA. Microsoft warrants that theProduct 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)
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), éspl. 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 • Folyamatminő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
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
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 óravagy 72 munkahét • Windows NT Workstation MTTF: 919 óravagy 23 munkahét • Windows 98 MTTF: 216 óravagy 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 SourceInstructions (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 Megrendelő veszi észre Fejlesztő csapat veszi észre
Példa: Megrendelői szempont Megrendelői szemmel: 64% • 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áltozottKLOC) - 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áltozottKLOC) - 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 Fejlesztői szemmel: 10%
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 • 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
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
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 Jól működő folyamat Havi riport Kiszállítás Stabilizálás Mit jelent, ha meghaladjuk az UCL-t vagy az LCL-t?
Megbízhatóság és Reliability Engineering • 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 Több célfüggvényes optimalizálási feladat
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égeaz idő előrehaladtávalcsökken Pl.:az újonnan megvett autóban a szervízelés javítja a hibákat Hibás alkatrészt kicseréltük
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: Szoftvernek nincs növekvő hibarátája 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)
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: hardvermegbízhatósági modellek nem használhatók a szoftver megbízhatóság modellezésére
Példa: 15 POSIX operációs rendszer tesztelési eredménye Jelentős romlás ? Mit mutat a diagram? Jelentős javulás
Megbízhatósági és minőségmenedzsment modellek • Szoftver megbízhatósági modelleka 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)
Előrejelzés vs. becslés • Szoftver modellezési technikáknak két alapvető technikája va:előrejelzéses modellezésésbecslé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:
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, ésvé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
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
COCOMOII áttekintés • 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 Becsült szoftver méret • Termék, folyamat, személyi Szoftver fejlesztési ráfordítás jellemzők Újrahasználás és karbantartás Szoftver fejlesztés ütemetés paraméterei Szoftver szervezet projekt adatai Paraméterek kalibrálása a szervezet jellemzői alapján COCOMO
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 Modellben használt paraméter