1 / 71

Szoftverminőség menedzsment

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

galvin-cohen
Télécharger la présentation

Szoftverminőség menedzsment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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?

  4. 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

  5. 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ő

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

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

  10. 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ű?

  11. 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

  12. 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”

  13. 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)

  14. 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.

  15. 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)

  16. 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

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

  18. Szoftverminőség metrikák

  19. 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

  20. 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

  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

  23. 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

  24. 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):

  25. 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

  26. 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%

  27. 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.

  28. 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!

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

  30. 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

  31. 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)

  32. 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. 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

  34. Példa: Heti probléma riport

  35. 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?

  36. Megbízhatóságiésminőségmenedzsment modellek

  37. 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

  38. 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

  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: 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)

  40. 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

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

  42. 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!

  43. 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. 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:

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

  46. 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

  47. 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

  48. 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

  49. COCOMO modell fázisok

  50. 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

More Related