Szoftverminőség - Vizsga 2011.01.04.

← Vissza az előző oldalra – Szoftverminőség

Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape

1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:

• ISO 9126: termék: definíció, minőségi attribútum, mérőszám (termék alapú)
• Boehm: termék: definíció, minőségi attribútum, mérőszám (termék alapú)
• McCall: termék: definíció, minőségi attribútum, mérőszám (termék alapú)
• ISO 9000: (folyamat alapú!)
• ISO 9001:2000 (MSZ EN ISO 9001): termék: minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú!)
• CMM (a.k.a. CMMI): termék: minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)
• SPICE: termék: folyamat minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú!)
• ISO 15504: termék: inőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú!)
• TSP: termék: minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)
• PSP: termék: minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)
• PM módszertanok, People CMM, Weinberg: folyamat: definíció; erőforrás: definíció, minőségi attribútum, mérőszám; (folyamat alapú ?)
• GQM: termék+folyamat+erőforás: mérőszám

• SPICE

Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése

• Boehm modell

A szoftver egyik első termékközpontú megközelítése

• Automotive SPICE

A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.

• ISO 9126

A termékközpontú szoftverminőség újragondolása.

• IFPUG

International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete. A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.

• CMMI

Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.

• PSP

Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.

• TSP

Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.

• GQM

Goal Question Metric

• ISO 9000:2000

2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!

Funkciópont számítás

• Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása
• Albrecht céljai a funkciópont számolással:
  • a szoftver méretének következetes mértéke legyen
  • legyen független a fejlesztésben alkalmazott technológiától
  • alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)
• Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor
• A mérés minden „divatos „ modellben fontos!
• A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg

Problémái:

• A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél
  • az adatgyűjtési ráfordítás „belefolyik” a projektekbe
  • az adatok elemzése nehéz, kevés a jó eredmény
  • a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani
• A számolási szabályok egyre bonyolódnak
• Egyre kevesebbet mond a számolás eredménye
• Kritikák az akadémiai szférából
• Sokfajta funkciópont számolási modell-változat
• A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak

Az IFPUG funkciópont számítási módszer

• :) legtöbbet használták, sok a tapasztalat, esettanulmány
• :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)
• :) adatfeldolgozó rendszerekben jól használható
• :( valós idejű rendszereknél nem használható
• :( csak alkalmazás - típusú szoftverekre használható
• :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses

Az MKII funkciópont számítási módszer

• :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni
• :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre
• :) A struktúrált elemzési módszerekkel konzisztens
• :) Az életciklus korai fázisában alkalmazható
• :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)
• :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni
• :( csak alkalmazás - típusú szoftverekre használható

A COSMIC funkciópont számítási módszer

• A szoftver funkcionalitásának egyszerű modelljén alapszik
• :) Egyszerű és egyértelmű
• :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)
• :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható
• :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...
• :( Kevesebb a tapasztalat, kevesebb esettanulmány
• :( Kevésbé részletes számolási útmutatók

3. Értelmezze a "Mérés és elemzés (MA)", a "Konfigurációmenedzsment (CM)" és a "Folyamat- és termék minőségbiztosítás (PPQA)" folyamatokra az alábbi általános célokat:

• GP 2.6 Konfigurációk menedzsmentje.
• GP 2.8 Folyamatkövetés és –vezérlés.
• GP 2.9 A megfelelőség tárgyilagos kiértékelése.

4. Az előző célok közül melyeknek felelnek meg:

• GQM
• ISO 9001:2000

5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?

Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:

• CMMI-DEV - Fejlesztés
• CMMI-SVC - Szolgáltatás
• CMMI-ACQ - Beszerzés

6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.

Csak CMMI-DEV:

• RD (Requirement Development) - Követelményfejlesztés
• TS (Technical Solution) - Műszaki megoldás
• PI (Product Integration) - termék integráció
• VAL (Validation) - Validáció
• VER (Verification) - Verifikáció

Mind a 3 konstellációban:

• Configuration Management
• Organization Process Definition
• Organizational Process Performance
• Quantitative Project Management
• Organization Training

Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:

• PI – termék integráció
• RD - Követelményfejlesztés
• SAM – Beszállítói megállapodás menedzsment
• TS – Műszaki megoldás
• VAL - Validáció
• VER – Verifikáció

CMMI-SVC-ben alkalmazott folyamatok:

TODO: ellenőrizni az alábbiakat

• SCON (3) - Service Continuity
• SD (2) - Service Delivery
• SSD (3) - Service System Development
• SST (3) - Service System Transition
• STSM (3) - Strategic Service Management
• CAM (3) - Capacity and Availability Management
• IRP (3) - Incident Resolution and Prevention

CCMMI-ACQ-ben alkalmazott folyamatok

TODO: mik tartoznak ide?

7. Mi a minőségköltsége és miből ered?

A minőség nincs "ingyen" (megfelelőség költsége), de olcsóbb, mint a lehetséges alternatíva (nem megfelelőség költsége).

CoQ = megfelelőség költsége + nemmegfelelőség költsége

• megfelelőség költsége = megelőzés költsége + értékelés költsége (mennyit fektetünk abba, hogy a fejlesztésben ne kelljen javítások miatt “visszatérni”)
  • Megelőzés:

    hibák megelőzésével kapcsolatos költségek:

    tervezés, dokumentálás, képzés, eszközök, eljárások és szabványok, minőségjavítási projektek, adatok gyűjtése ée elemzése, hibák okának elemzése, minőségi jelentések...

  • Értékelés

    hibakereséssel kapcsolatos költségek:

    szemlék (rendszer, követelmény, tervezés, teszetlési terv), kódszemlézés, tesztelés (első alkalommal), auditok, CMM felmérés...

• nemmegfelelőség költsége = belső hibák költsége + külső hibák költsége (mennyibe kerül “visszatérni” és javítani)
  • Belső hibák költsége

    a rendszer átadása előtt megtalált hibákkal kapcsolatos költségek:

    újraírás (követelmények, tervek, modellek, kód, dokumentáció), hibajavítás miatti újratesztelés, folyamatokban jelentkező veszteségek (tesztelés miatti kiesés, átadandók változtatása, időbeli csúszások, költsége-túllépések…)

  • Külső hibák költsége

    a rendszer átadása után megtalált hibákkal kapcsolatos költségek

    garancia, „apró” módosítások, sikertelen projektek, be nem tervezett verziók...

--Halacs (vita) 2014. január 17., 17:11 (UTC)

-- FaPe - 2011.01.06.