INFORMÁCIÓS RENDSZEREK

INFORMÁCIÓS RENDSZEREK Szoftver minőségbiztosítás témakör

jegyzet (V.03. / 2015-06-01)

Készítette: © Dr. Horváth Zsolt László

Jegyzet

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01)

Tartalomjegyzék Tartalomjegyzék .................................................................................................................. 2 0 Miről lesz szó ebben a tárgyban? ............................................................................... 4 1 Minőségirányítás a szoftverfejlesztésben .................................................................. 5 1.1 A szoftverfejlesztési projekt ..................................................................................... 5 1.2 Ellenőrzési tevékenységek a szoftverfejlesztésben ................................................. 7 1.2.1 A review (dokumentumszemle) ....................................................................................... 7 1.2.2 A tesztelés ........................................................................................................................ 8 1.2.3 Hibák kezelése, életciklusa .............................................................................................. 8 1.3 A konfiguráció menedzsment .................................................................................. 9 1.4 Folyamatmenedzsment alapelvek a szoftverfejlesztésben ...................................... 9 1.5 Ellenőrző kérdések .................................................................................................10 2 Szoftverfejlesztési általános módszertanok .............................................................12 2.1 SW fejlesztési metodikák, módszertanok ...............................................................12 2.1.1 Áttekintés a módszerekről ............................................................................................. 12 2.1.2 A vízesés modell ............................................................................................................. 12 2.1.3 A V-Modell alap-felépítése ............................................................................................ 13 2.1.4 Agilis szoftver projektvezetés ........................................................................................ 13 2.1.5 A SPICE ........................................................................................................................... 15 2.2 A CMMI módszertan...............................................................................................16 2.2.1 Általános áttekintés a CMMI-ről ................................................................................... 16 2.2.2 CMMI modell ábrázolása............................................................................................... 17 2.2.3 A CMMI egyes verzióinak jellegzetességei .................................................................... 20 2.2.4 A CMMI V.1.2 jellemzése ............................................................................................... 21 2.2.5 A CMMI V.1.3 kulcsfolyamatok (változások) ................................................................. 23 2.3 Ellenőrző kérdések .................................................................................................25 3 Követelménykezelés a szoftverfejlesztésben ...........................................................26 3.1 Követelménykezelési alapelvek ..............................................................................26 3.1.1 Meghatározások............................................................................................................ 26 3.1.2 A követelménykezelés feladatai .................................................................................... 26 3.1.3 A követelménykezelés lépései........................................................................................ 27 3.1.4 Tervezés több szinten .................................................................................................... 27 3.1.5 Ellenőrzési relációk a V-modellben ................................................................................ 28 3.2 Példák különböző rendszerek vizsgálati szempontjaira ..........................................29 3.2.1 Vizsgálati szempontok biztonságkritikus rendszerekre ................................................. 29 3.2.2 Vizsgálati szempontok IEEE 830:1998 szabvány alapján .............................................. 29 3.2.3 Vizsgálati szempontok reaktív (irányítástechnikai) rendszerekre ................................. 30 3.3 A követelménykezelés problémái ...........................................................................30 3.4 Követelménykezelés a CMMI-ben ..........................................................................31 3.5 Ellenőrző kérdések .................................................................................................31 4 Tesztelés a szoftverfejlesztésben..............................................................................32 4.1 A tesztelés életciklusa ............................................................................................32 4.1.1 Tesztelés célja ................................................................................................................ 32 4.1.2 Tesztelés objektuma ...................................................................................................... 32 4.1.3 Tesztelés helye a fejlesztési folyamatban ...................................................................... 33 4.1.4 Hogyan tesztelünk? – Tesztelések csoportosítása ......................................................... 34 4.1.5 Tesztesetek meghatározása .......................................................................................... 35 4.1.6 Hány teszteset futtatása szükséges? ............................................................................. 36 © Dr. Horváth Zsolt László

2

Jegyzet

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) 4.1.7 Tesztek végrehajtása ..................................................................................................... 36 4.1.8 Tesztek kiértékelése ....................................................................................................... 36 4.1.9 Tesztelés sikerkritériumai .............................................................................................. 37 4.1.10 Tesztelési toolok ............................................................................................................ 38 4.2 Különleges kód-ellenőrzések ..................................................................................38 4.3 Ellenőrző kérdések .................................................................................................38 5 Tooling használata a szoftverfejlesztésben ..............................................................39 5.1 Tool-ok használata .................................................................................................39 5.2 Példák különböző kategóriájú tool-okra ..................................................................39 5.2.1 Modellező toolok ........................................................................................................... 39 5.2.2 Verziókezelő tool-ok ...................................................................................................... 40 5.2.3 Feladat követő tool-ok ................................................................................................... 41 5.2.4 Statikus kódanalízis toolok ............................................................................................ 43 5.3 Ellenőrző kérdések .................................................................................................43 6 Metrikák használata a szoftverfejlesztésben ............................................................44 6.1 Metrikák célja, alkalmazása....................................................................................44 6.1.1 Metrikák (mérőszámok) meghatározása ...................................................................... 44 6.1.2 Problémák. – Miért nem működnek sokszor a metrikák? ............................................. 44 6.1.3 Metrikák bevezetésének sikertényezői .......................................................................... 44 6.1.4 Egy metrika alkalmazási folyamatának szereplői ......................................................... 44 6.1.5 A megfelelő metrikák kiválasztásának kritériumai ....................................................... 45 6.2 Példák metrikákra ..................................................................................................45 6.2.1 A metrikák csoportosítása ............................................................................................. 45 6.2.2 Projektmetrikák – példák............................................................................................... 45 6.2.3 Kódmetrikák – példák .................................................................................................... 48 6.3 Ellenőrző kérdések .................................................................................................50

© Dr. Horváth Zsolt László

3

Jegyzet


0 Miről lesz szó ebben a tárgyban? A tantárgy ezen részének a célja: Áttekintés és alapismeretek a szoftverfejlesztés során a szoftver minőségbiztosítási kérdéseiről, azok jelentőségének és gyakorlati alkalmazásának bemutatásáról. Az előadások a következő témaköröket tárgyalják: •

Minőségirányítás és a szoftverfejlesztésben

•

Szoftverfejlesztési általános módszertanok

•

Követelménykezelés a szoftverfejlesztésben

•

Tesztelés a szoftverfejlesztésben

•

Tooling használata a szoftverfejlesztésben

•

Metrikák használata a szoftverfejlesztésben

Előadások törzsanyaga elérhető jegyzetben! Előadásokon további példák, magyarázatok. Jegyzet: www.uni-obuda.hu/users/horvath.zsolt.laszlo ftp site-on. Előadó érhetőségei: -

Név: Dr. Horváth Zsolt László, ÓE KVK MAI E-Mail: [email protected] Tel: +36 70 4198599 Munkahely: KVK Tavaszmező u. „C” épület, 410-es szoba


4

Jegyzet


1 Minőségirányítás a szoftverfejlesztésben 1.1 A szoftverfejlesztési projekt A szoftverfejlesztési projekt-team szereplői: -

projektvezető projektasszisztens minőségbiztosítási felelős konfiguráció menedzsmentért felelős fejlesztők tesztelők

A szoftverfejlesztési projekt fázisai: -

-

kezdeményezés pozitív projektdöntés esetén: o definíció o tervezés o megvalósítás o bevezetés (üzembe helyezés) lezárás

A szoftverfejlesztési projekt fázisaira mindegyik metodika strukturáltan előírja az adott fázishoz tartozó: -

bemeneteket (inputokat) tevékenységeket eredményeket kapcsolódó feljegyzéseket

mind a technikai (szakmai), mind a projektvezetési valamint mind a minőségbiztosítási nézőpontból. PÉLDA: Az egyes fázisokhoz tartozó tevékenységek, eredmények és feljegyzések egy általános (nagyobb) szoftverfejlesztési projekt esetén, például a következők lehetnek: Fázis Kezdeményezés

Tevékenység Tenderkiírás / ajánlatkérés megvalósíthatóságának (technikai) vizsgálata Erőforrás-becslés Durva projekttervezés (erőforrások felhasználási terve, megvalósítási időterv, kockázatok, pénzügyi, …)

Eredmény

Feljegyzés

Döntés a továbblépésről

Technikai feljegyzések

Becsült ráfordítás-igény

Számítások feljegyzései, alapadatok, egyeztetések jegyzőkönyvei, …

Durva projektterv (mibe ugrunk bele, ha …) Ajánlat

Ajánlatot készítő és ellenőrző aláírásai legalább

Ajánlat elkészítése, ellenőrzése, kiküldése


5

Jegyzet Fázis Definíció

Tevékenység

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Eredmény Feljegyzés

Az ügyfél követelményeinek pontosítása, majd az alapján a termék funkcionalitásának részletes tervezése, és annak ellenőrzése A rendszer-tesztelés megtervezése Konfiguráció menedzsment terv előkészítése.

Specifikáció, ami a termék minden funkcionalitását, szolgáltatását részletesen leírja (R-Spec, F-Spec vagy logikai rendszerterv) Tesztelési terv, ami tartalmazza a rendszer teszt-stratégiát, teszteseteket, és a lefolytatás körülményeit, elfogadási kritériumokat, …

Specifikáció ellenőrzésének (review-jának) feljegyzései, ami igazolja mind a validálást, mind a verifikálást. Tesztelési terv (rendszerteszthez) ellenőrzésének feljegyzései, …

Durva konfiguráció menedzsment terv. Tervezés

A termék struktúrájának, működési „algoritmusának” megtervezése, és annak ellenőrzése A kapcsolódó tesztelés megtervezése, specifikálása. A konfiguráció menedzsment rendszer megtervezése

Specifikáció, amely részletesen tartalmazza a termék struktúráját, belső felépítését, működési elvét, valamint a megvalósítási eszközöket és lépéseket. (D-Spec, vagy fizikai rendszerterv) Tesztelési terv – integrációs teszthez. Konfiguráció menedzsment terv (és rendszer és eszköz)

Megvalósítás

Implementálás -

Kódolás Modulteszt végrehajtása Dokumentáció elkészítése

Illesztés meglévő (vásárolt vagy újra felhasznált) modulokhoz Integráció és tesztelés -

Integráció, önálló termékkomponensek összeállítása Integrációs teszt végrehajtása Produkció (release) legyártása Rendszerteszt végrehajtása

Ellenőrzött és jóváhagyott: -

termék termékdokumentáció

Termék bevezetési terv

Specifikáció ellenőrzésének (review-jának) feljegyzései, ami igazolja mind a validálást, mind a verifikálást. Konfiguráció menedzsment terv ellenőrzésének feljegyzései, … Tesztelési terv (integrációs teszthez) ellenőrzésének feljegyzései,

(SW-)Technikai feljegyzések, specifikációk Aktualizált tervek (projekt terv, minőségterv, CM-terv, tesztelési terv) CM rendszer bejegyzései, tesztelési jegyzőkönyvek, hibák életciklus dokumentációja, …

Átadás előkészítése


6

Jegyzet Fázis

Tevékenység

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Eredmény Feljegyzés

Bevezetés Próbaüzem (pilotálás) Éles-üzembe helyezés + kapcsolódó képzések, betanítások

Bevezetett, átadott és működő termék

Próbaüzemi és átadási tesztek tervei és jegyzőkönyvei Átadás-átvételi jegyzőkönyv

Éles-üzemi karbantartás Termék használatának támogatása Hibajavítás Változások kezelése Lezárás

Projektek lezáró értékelése Projektdokumentumok archiválása

Karbantartási megállapodás és tervek Projektzáró jelentés (értékelések, statisztikák, tapasztalatok) Lezárt projektmappa

1.2 Ellenőrzési tevékenységek a szoftverfejlesztésben A SW-fejlesztés életciklusa során a résztermékek megfelelőségét mérni (ellenőrizni) kell! Az egyes eredménytermékek jellemző mérési módszerei: Résztermékek

Ellenőrzési módszer

Ajánlat, szerződés Projekttervek (inc. minőségtervek, CM-tervek, tesztelési tervek, …) Ügyfél igények (requirements) Specifikációk (funkcionalitás specifikáció, design specifikáció, ..) Forráskód Termék leírás

Review (dokumentum szemle)

Lefordított modulok, komponensek Teljes futtatható termék

Tesztelés

1.2.1 A review (dokumentumszemle) A review fogalma: A review szisztematikus, kritikus, dokumentált ellenőrzési eljárás. A review tárgya: -

dokumentum (= adathordozón rögzített információ) termék-dokumentum (pl. forrás kód, felhasználói kézikönyv, ...) kísérő- v. munka-dokumentum (pl. ‘Functional specification’, vagy teszt-terv, ...)

> külön értelmezünk a „kód review”-t és a „dokumentum review”-t. A review célja: hibát találni, (és nem bűnbakot) ... ... magában a dokumentumban, illetve ... abban az eljárás-specifikációban, aminek alapján készítették. A review haszna A hibás megvalósítás korai felismerése, mind ... ... a validálás, mind


( ez az, ami kell? )

7

Jegyzet

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) ... a verifikálás tekintetében ( ilyennek kell ennek lennie? )

Olyan hiányosságok megtalálása, amelyek a teszt (üzemeltetés) során nem jönnének elő, csak a karbantartásnál vagy a továbbfejlesztésnél, pl. : -

rosszul strukturált, bonyolultan felépített, nehezen átlátható kód, rosszul dokumentált programrész, rosszul kommentált forráskód.

„Bizonylatolt” minőségbiztosítási eljárás (pl. ISO 9001 szerint), amivel a termék minőségét igazolni tudjuk, és aminek alapján tovább lehet javítani magát a fejlesztési eljárást is. A know-how elterjesztése, tapasztalatcsere, egységes szemlélet.

1.2.2 A tesztelés A tesztelés fogalma: -

egy (vagy több) futtatható állapotban levő szoftver komponens meghatározott feltételek mellett (adat, esemény) történő futtatása, és a működés eredményének értékelése (elvárt viselkedésnek megfelel vagy nem).

A tesztelés célja: -

egy rendszer-komponens (szükséges mértékig) hibátlan állapotának igazolása; egy „tesztelhető objektum” létrehozása, amivel különféle vizsgálat végezhető; az elvárt rendszertulajdonságoktól való eltérés (nagyságának) kimutatása; a rendszer „minőségéről” információ a vezetőség felé (továbbfelhasználás ...); a rendszer validálása: megfelel-e az eredeti felhasználói kívánságoknak;

A teszteket csoportosíthatjuk •

a tesztobjektum teljessége szerint: komponens teszt „stand alone” teszt integrációs teszt több, együttműködő komponens összetett vizsgálata rendszer teszt („systemtest”) a teljes termék, átadásra kész állapotban

•

a teszt célja szerint (példák): átadási teszt a felhasználónak üzemi használatra történő átadás előtt regressziós teszt annak igazolására, hogy módosítás továbbfejlesztés esetén a korábbi funkciók változatlanul helyesen működnek performance (stressz) teszt nagy terhelés szimulálására stb…

•

vagy más módon.

1.2.3 Hibák kezelése, életciklusa A különböző tesztelésekkor megtalált hibák kezelésével szembeni követelmények: Hibák (dokumentált) nyomon követése egységes segédeszközben biztosított legyen, ahol -

folyamatosan nyomon követhető minden egyes hiba aktuális állapota (státusza), és múltja, és amelyik biztosítja minden fontos hiba kijavításának kikényszerítését.

A hiba kijavításának ellenőrzése vonatkozik: a megállapított hibás funkcióra, valamint arra, hogy nem került-e a módosítással újabb hiba a rendszerbe! (regresszió tesztelés) © Dr. Horváth Zsolt László

8

Jegyzet

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Tesztelési program közben ne változtassunk a tesztelés objektumán!

1.3 A konfiguráció menedzsment „Konfiguráció” a rendszerfejlesztés során: -

-

tartalmilag: olyan összetett rendszerről van szó, ahol az egyes összetevők is (részegységek, alkatrészek) folyamatosan módosulnak, fejlődnek (életciklus). A verziószámok nyilvántartása – a „verziókövetés” – elkerülhetetlen! termék esetén: a konfiguráció az a tevékenység, amikor egy adott verziójú, konkrét végtermékhez meghatározzuk az oda beépülő részegységek verzióit

A „konfiguráció menedzsment” csoport tevékenysége: Mindaz a szervező és operatív tevékenység, ami biztosítja a fenti cél teljesülését. -

a megfelelő (számítógépes) nyilvántartási rendszer kialakítása a folyamatok, a szervezet és a munkakörök kialakítása megfelelő tool-ok érdemi használatának biztosítása és kikényszerítése az előírásoknak megfelelő folyamatos üzemvitel

A konfiguráció menedzsment feladatai: -

A számítástechnikai jellegű feladatok: • • • • •

az objektumok verzióinak nyilvántartása; a megfelelő adattárolási biztonság megtervezése az egyes verziók sajátosságainak nyilvántartása (címkézés: ki, mikor, miért, hogyan módosított) a nyilvántartott objektumok közötti kapcsolatok és függőségek kezelése ezáltal megoldható az automatikus szoftverprodukció az egyes objektum(változat)okhoz való hozzáférési jogosultságok kezelése

A projektvezetést támogató feladatok: • •

a hibafelismerés és –javítás folyamatának, valamint a változtatási igényeknek a támogatása a csoportmunka támogatása; egyszerre többen ugyanazon rendszer különböző részét fejleszthetik

1.4 Folyamatmenedzsment alapelvek a szoftverfejlesztésben


9

Jegyzet


Folyamatok és alkalmazásuk legyen: •

Alkalmas -

•

Módszeres – módszertan szerinti -

•

-

-

A „dokumentáltság” fogalmába beleértendő minden, ami az összes érdekelt releváns fél számára hozzáférhető információkat biztosít, beleértve egyidejűleg a vonatkozó speciális követelmények (pl. törvényi előírások, különleges ügyfél általi elvárások, stb.) teljesítését is. Az információhordozó médium bármi alkalmasan megválasztott lehet.

Ellenőrzött -

•

Tevékenység végzése mindig ugyanolyan módon illetve szemlélet / előírások szerint Segédeszközök, sablonok, tool-ok használata

Dokumentált -

•

Tervezett, végrehajtott, ellenőrzött - folyamatosan Tevékenység végzése és ellenőrzése a módszertan előírásai szerint Módszer alkalmazása minden tevékenységre, a folyamat teljes életciklusában

Következetes -

•

A definiált folyamatok és azok alkalmazása (a megvalósulás a gyakorlatban) kielégítik a résztvevő érdekelt felek elvárásait. A célok eléréséhez az optimális (legmegfelelőbb) módszer kiválasztása, körülményekhez és helyzethez igazodó testre szabási kritériumok szerint

A folyamat eredményeinek és végrehajtási módja megfelelésének a folyamatos ellenőrzése Megfelelő folyamatmutatók mérése, célértékek kitűzése és tartása

Javított – továbbfejlesztett -

A mérések és tapasztalatok visszacsatolása az intézményesített folyamat fejlesztésébe Tapasztalatok, tudás gyűjtésének és feldolgozásának bevezetett módszerei működnek rendszeresen Rendszerezett eredményeken (adatbázisokon) alapuló – tanuló szervezet

1.5 Ellenőrző kérdések -

Mutassa be egy szoftverfejlesztési projekt jellemző szereplőit, és azok fő feladatait! Mutassa be egy szoftverfejlesztési projekt „kezdeményezési fázisának” fő tevékenységeit és eredmény-termékeit! Mutassa be egy szoftverfejlesztési projekt „definíciós fázisának” fő tevékenységeit és eredmény-termékeit! Mutassa be egy szoftverfejlesztési projekt „megvalósítási fázisának” fő tevékenységeit és eredmény-termékeit! Mutassa be egy szoftverfejlesztési projekt „tervezési fázisának” fő tevékenységeit és eredmény-termékeit! Mutassa be egy szoftverfejlesztési projekt „bevezetési fázisának” fő tevékenységeit és eredmény-termékeit! Mutassa be egy szoftverfejlesztési projekt „lezárási fázisának” fő tevékenységeit és eredmény-termékeit!


10

Jegyzet -

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Milyen ellenőrzési tevékenységeket ismer a szoftverfejlesztés során, jellemezze röviden őket! Mi a review célja, és használati területei a szoftverfejlesztési projekt során? Mutassa be a tesztelés célját a szoftverfejlesztési projekt során, valamint mutassa be, hogy hogyan csoportosíthatóak a különböző tesztelések! Melyek a konfiguráció menedzsment feladatai a szoftverfejlesztési projekt során? Mikor – milyen kritériumok alapján – mondhatjuk azt, hogy a folyamatok hatékonyan bevezetetten, magas szinten működnek?


11

Jegyzet


2 Szoftverfejlesztési általános módszertanok 2.1 SW fejlesztési metodikák, módszertanok 2.1.1 Áttekintés a módszerekről Általános módszerek, modellek • • • • • •

SSADM Vízesés modell V-Modell Agilis módszertanok (XP, TDD, Scrum, …) SPICE (spec területen: Automotive SPICE) CMMI

Gyártó-, termék-, fejlesztőcég- specifikus módszerek • • •

Nagyobb fejlesztői környezethez készített, gyártói keretrendszerek, módszerek (RATIONAL – RUP, vagy MS fejlesztői környezetbe ágyazott módszerek) Ábrázolással, logikai modellel kapcsolatos módszerek (pl. UML, XML-hez kötött modellek) Multik saját módszertanai (pl. SIEMENS – CHESTRA, SEM, SEPP, …)

2.1.2 A vízesés modell -

-

Előnyök: o Jól áttekinthető, könnyen érthető o Jól strukturált o Feladatok jól megoszthatók o Időben tervezhető Hátrányok: o Merev, nem rugalmas (a folyamat ideje alatt új igények merülhetnek fel, melyeket a modell elutasít) o Ha a hiba későn derül ki, akkor drága a javítás (a megvalósítási fázisban felfedezett tervezési hibákat (elvileg) nem lehet visszadobni) o Nagyon pontos specifikációt igényel, és ez sokszor az elején nem ismert (nem mindig tudja az ügyfél, hogy pontosan mit is akar…) o A megrendelő csak a legvégén látja az eredményt (nincs ízelítő; a termék a folyamat végén jelenik meg) o Elnyúló (a fejlesztő elfelejti egy-egy fázis sajátosságait, mire újra találkozik velük) o Becslésre nem keletkezik mérési adat.


12

Jegyzet


2.1.3 A V-Modell alap-felépítése

A V-Modell lényege, hogy (jellemzően a vízesés modell szerinti folyamatmodell során) a tervezés (specifikációk készítése) minden szintjéhez tartozik egy-egy tesztelési fázis, ami annak a szintnek a megtervezett (specifikált) megfelelő működését ellenőrzi. Ezen tesztfázisok tesztelései tervezésének az alapját mindig az annak megfeleltetett tervezési szint, a megfelelő specifikáció képezi, abból levezetve készülnek a megfelelő tesztelési tervek.

2.1.4 Agilis szoftver projektvezetés •

Agilitás: olyan adottság, amely egyaránt képes létrehozni és reagálni a változasokra és ezzel előnyt szerezni egy turbulens üzleti környezetben

•

Agilis szoftverfejlesztési projektvezetés ismérvei:

•

–

Adaptív (alkalmazkodó) – nincs hosszú távú tervezés, hanem rövid távon probléma megoldás – de az „szigorúan”

–

Együttműködés a megrendelővel – követelmény változásokkal

–

Változásokra való gyors reagálás

–

Feladatok alábontása részfeladatokra

–

Rövid ciklusok tervezése – azok szigorú tartása

–

Egyén (tudás és motiváció), és személyes kommunikáció jelentősége

SCRUM – mint az egyik legelterjedtebb agilis szoftverfejlesztési módszertan


13

Jegyzet


•

Agile manifesto:

•

SCRUM – mint az egyik legelterjedtebb agilis szoftverfejlesztési módszertan –

Scrum elemek:

–

Kiemelt szerepkörök a Scrum-ban: o

Product owner (PO) Felelős a termék elkészüléséért. Meghatározza a termék tulajdonságait (features). Priorizálja a feladatokat. Egyeztet minden érintettel, de ő dönt. A sprintek elején és végén feltétlenül találkozik a csapattal.

o

Csapat 7±2 tag átfogó szaktudással. Önszervező, független és felelős csapat. A munka becslésében felelős. Megegyezik a munkamennyiségről, és törekszik ezt teljesíteni. Demo keretében adja át a munkát.

o

Scrum master (SM) Ő ismeri a folyamatokat, amiket betartat. Tanítja a PO-t, a csapatot és egyéb érintetteket. Megvédi a csapatot a külső behatásoktól. Elhárítja az akadályokat. Megszervezi a scrum eseményeket. Közvetítő és képviselő a menedzsment és csapat között


14

Jegyzet

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) –

A Scrum életciklusa

2.1.5 A SPICE -

SPICE = Software Process Improvement and Capability Evaluation ISO/IEC 15504:2004 Information Technology. Process Assessment Egyes szakmai területeken még tovább él (pl. autóipar)

A SPICE képességi szintjei:


15

Jegyzet


2.2 A CMMI módszertan 2.2.1 Általános áttekintés a CMMI-ről Mire használható a CMMI? A CMMI a szoftver-előállítási folyamatok képességének - felmérésére - javítására - fejlesztésére - szinten tartására - önértékelésére - benchmarkingra, - marketingre szolgáló modell, illetve módszertan. A CMMI kialakulása és fejlődése -

Értékelési kérdőív (módszer) kidolgozása szoftverfejlesztő vállalatok számára (1987) Ezt a módszert az USA-ban a Carnegie Mellon Egyetem Software Engineering Institute (SEI) intézete dolgozta ki (1991) Referenciamodell a később ez alapján levezetett modellek számára, pl.: BootstrapAssessment (európai értékelési módszer) (1992) Először csak szoftver folyamat értékelése (SW-CMM), majd kibővül általános folyamatmodell értékeléssel (SW-A-CMM, SE-CMM, People-CMM) (1995) CMMI V1.0 (2001) CMMI = {SW CMM + SE CMM + IPPD + SS} CMMI V1.1 (2003) CMMI V1.2 – DEV (2006) CMMI V1.3 – DEV (2010)

A (SW)-CMM érettségi szintjei


16

Jegyzet


2.2.2 CMMI modell ábrázolása A szervezet választhat a fejlesztési folyamat irányultsága, fókusza szerint. A CMMI modell ábrázolási lehetőségei két gondolkodásmódot támogatnak: –

Folyamatok képessége folyamatos ábrázolás, Az egyes folyamatok fejlesztése egymástól függetlenül, de ugyanolyan út mentén történik. A szervezet saját igényei szerint határozza meg az egyes folyamataiban megcélzott képességi szintet.

–

Szervezeti érettség lépcsőzetes ábrázolás A szervezet egészét vizsgálja és fejleszti. Az egyes folyamatok fejlesztése szintenként egyszerre, ugyanazon az úton történik. A megkövetelt folyamatok köre szintről szintre bővül.

A FOLYAMATOS ÁBRÁZOLÁS

A folyamatoknak kétféle követelményeket kell teljesíteniük, az általános célok és hozzájuk kapcsolódó általános tevékenységek a folyamatmenedzsment követelményeket határozzák meg, és ezen keresztül az adott folyamat érettségi szintjét, a speciális célok és a speciális tevékenységek pedig az adott folyamat saját, szakmai követelményeit. A folyamatok jellemzése, képessége •

Az éretlen folyamat jellemzői -

•

A folyamat ad hoc jellegű, és jellemző az alapvető improvizálás (fejlesztők és menedzserek részéről). Az eljárási előírásokat – amennyiben vannak – nem követik. Egyes személyektől (guruktól) való erős függőség. A termék minősége előre csak nehezen jelezhető. Hiányok a termék minőségében és funkcionalitásában a határidő tartása érdekében, vagy határidőcsúszások. Új technológiák alkalmazása kockázatos. Stressz alatt a felsőbb szintű előírásokat és irányelveket, mint fölösleges ballasztot figyelmen kívül hagyják.

Az érett folyamat jellemzői -

Standardizált folyamat, definiált és dokumentált,


17

Jegyzet

-


o megértett és elfogadott o gyakorlatba átültetett, alkalmazott Érezhető a menedzsment támogatása A szerepek és felelősségek egyértelmű meghatározása és megértése Működő kontrolling – a folyamat betartása ellenőrzött Konzisztens a munkatársak munkastílusával Mérhető és mért Alkalmas technológia és tool-ok használata

Általános célok (GG2 és GG3) értelmezése •

GG2: A folyamat intézményesítése menedzselt folyamatként. A menedzselt folyamat jellemzői: -

•

a vállalati stratégia és politika alapján és az érintetteket bevonásával alakítják ki, oktatják, erőforrásokkal ellátják, ellenőrzik, betartják.

GG3: A folyamat intézményesítése definiált folyamatként. A definiált folyamat jellemzői: -

menedzselt folyamat, vannak szervezeti szintű standard folyamatok és ezekből vezetik le (testre szabják), folyamatleírással rendelkezik, meghatározottak a be/kimenetek, a folyamat javításához szükséges információkat gyűjtik.

A LÉPCSŐZETES ÁBRÁZOLÁS


18

Jegyzet


Az érettségi szintek -

-

Az érettségi szint (ML) egy jól-definiált fejlődési szint, amely a szervezet érettségét írja le a teljes működése vonatkozásában, azaz azt mutatja meg, hogy mennyire képes a szervezet vállalásait megbízhatóan teljesíteni. 5 érettségi szint van! (1 .. 5) Az egyes érettségi szintekhez adott általános (közös) cél megfelel az azonos folyamatképességi szint általános céljának. Az általános (közös) célokhoz tartozó általános gyakorlatok is megfelelnek az azonos folyamatképességi szintekhez meghatározott általános gyakorlatoknak. Az érettségi szintek kumulatívak, azaz a magasabb szint tartalmazza az alacsonyabb szint teljesülését.

Az „érett” szoftverház jellemzése: •

„2”-es érettségi szint jellemzése -

•

„3”-as érettségi szint jellemzése -

•

Kialakult (szabványosított) folyamatmodell testre szabottan működik a projektekben Projektfolyamatok hozzájárulnak a szervezeti folyamatmodellek fejlesztéséhez Szervezeti szinten egységesen kontrollált folyamat, és megbízható teljesítés és projektsiker

„4”-es érettségi szint jellemzése -

•

Projektekre alkalmazott folyamatmenedzsment és projektmenedzsment irányvonal Szabályozott projekttervezés és követés Konfigurációmenedzsment és minőségbiztosítási alapkövetelmények Tervezhető és kézben tartott projekt-teljesítés

Folyamatteljesítmény mérése Kulcsfolyamatok statisztikai folyamatszabályozása Folyamatok és projektek hatékonyságra optimalizáltak

„5”-ös érettségi szint jellemzése -

Hibamegelőzés Folyamatos fejlesztés és innováció Folyamatosan fejlődő és tanuló szervezet, elért tudás és eredmények hatékony újrafelhasználása

Érettségi szintek elérésének feltételei A szervezeti érettségi szintek (ML) elérésének feltételei: (kapcsolat a két modellábrázolás között) -

ML2: mindegyik ML2 szinthez tartozó folyamatterületen CL2 elérése ML3: mindegyik ML2 és ML3 szinthez tartozó folyamatterületen CL3 elérése ML4: mindegyik folyamatterületen az ML4 szintig CL3 elérése, és a kritikus részfolyamatoknál CL4 elérése ML5: mindegyik folyamatterületen az ML5 szintig CL3 elérése, és a kritikus részfolyamatoknál CL5 elérése


19

Jegyzet


2.2.3 A CMMI egyes verzióinak jellegzetességei A CMMI V.1.1 modellek Modellek -

Szoftver engineering (SW) Rendszer + Szoftver engineering (SE + SW) Rendszer + Szoftver engineering + Integrált termék- és folyamatfejlesztés (SE + SW + IPPD) Rendszer + Szoftver engineering + Integrált termék- és folyamatfejlesztés + beszállítói erőforrás-menedzsment (SE + SW + IPPD + SS)

Ábrázolások -

lépcsőzetes folyamatos

A CMMI V.1.2 modellek Modellek -

CMMI Keret (CMMI Framework) – modell leírás, modell auditálásának leírása, oktatási anyagok Megosztott CMMI anyag (Shared CMMI material) – ez mindegyik CMMI alkalmazásban azonos, mindig használni kell >> „ez a kötelező alap” CMMI konstellációk (CMMI Constellations) – Szakterületekhez tartozó speciális folyamatok követelményei. Ezek lehetnek: o DEV (Development) – fejlesztés (szoftver-fejlesztés) o A (Acquisition) – akvizíció o S (Services) - szolgáltatás

Ábrázolások -

lépcsőzetes folyamatos

A CMMI V1.3 modellek Modellek - Ábrázolás -

Alapvetően a V1.2 modellje és ábrázolási módjai mennek tovább

Változások -

Néhány apró változás kulcsfolyamatokban, illetve egyes kulcsfolyamatokhoz tartozó követelményekben (SAM, RD, PI, OPD) Kikerült az IPPD (Integrált termék és folyamat fejlesztés), és helyette hangsúlyt kapott a „Teaming” (teammunka) Általános célok egyszerűsítése, könnyebb használhatósága Folyamat képességi szintek csak 3-ig mennek > a 4. és az 5. képességi szint általános céljainak törlése Folyamatokhoz „minőségjellemzők” (Quality attributes) szerepének növekedése Architektúra-központos fejlesztési gyakorlatok, előírások Team-munka és szerepkörök jelentőségének növelése Közelítés az agilis fejlesztéshez


20

Jegyzet


Minőségjellemzők fókusz -

Minőségjellemzők értelmezése összhangban az ISO/IEC 9126:2001 Information Technology. Software Product Quality szabvánnyal Minőségjellemzők nemcsak a funkcionalitásra, hanem a nem-funkcionális követelményekre is vonatkoznak Főbb minőségjellemzők csoportjai -

Funkcionalitás Megbízhatóság Használhatóság Hatékonyság Karbantarthatóság Hordozhatóság

2.2.4 A CMMI V.1.2 jellemzése A CMMI V.1.2 – DEV kulcsfolyamatai: •

•

•

•

Projektmenedzsment: - Projekttervezés (PP) - Projektkövetés és vezérlés (PMC) - Beszállítói megállapodás menedzsment (SAM) - Integrált projektmenedzsment + IPPD (IPM+IPPD) - Kockázatmenedzsment (RSKM) - Mennyiségi projektmenedzsment (QPM) Folyamatmenedzsment: - Szervezeti szintű folyamatszemlélet (OPF) - Szervezeti szintű folyamatdefiníció + IPPD (OPD + IPPD) - Szervezeti szintű képzés (OT) - Szervezeti szintű folyamatteljesítmény (OPP) - Szervezeti szintű innováció és fejlesztés (OID) Fejlesztés: - Követelményfejlesztés (RD) - Követelménymenedzsment (REQM) - Műszaki megoldás (TS) - Termékintegráció (PI) - Verifikáció – ellenőrzés (VER) - Validáció – érvényesítés (VAL) Szupport: - Konfigurációmenedzsment (CM) - Folyamat- és termék- minőségbiztosítás (PPQA) - Mérés és elemzés (MA) - Döntéselemzés és döntéshozatal (DAR) - Ok-elemzés és megoldás (CAR)

A CMMI V1.2 képességi szintek -

A képességi szint (CL) egy jól-definiált fejlődési szint, amely a szervezet képességét írja le az adott kulcsfolyamat-terület (KPA) vonatkozásában.


21

Jegyzet -

-


6 képességi szint van! (0 .. 5) Az 1 – 5 képességi szintekre adott egy-egy közös cél. A képességi szintek kumulatívak, azaz a magasabb szint tartalmazza az alacsonyabb szint teljesülését. Egy kulcsfolyamat-területre (KPA) levetítve is értékelhető annak képességi szintje. (Magasabb érték magasabb folyamatképességet jelent.) Vizsgálhatók bizonyos folyamatcsoportok is külön, ekkor azok képességi szintjeinek együttese adja az ún. „képességi szint profilt” (capability level profile). Így egyes folyamatok vagy folyamatcsoportok külön-külön is vizsgálhatók, fejleszthetők. A CMMI V.1.2 képességi szintek: 0. befejezetlen – Esetleg néhány GP vagy SP értelmezett, részben alkalmazott 1. végrehajtott – GP 1.1, és mindegyik SP értelmezett, alkalmazott 2. menedzselt – GP 1.1 … GP 2.10, és mindegyik SP értelmezett, alkalmazott 3. definiált – GP 1.1 … GP 3.2, és mindegyik SP értelmezett, alkalmazott 4. mennyiségileg menedzselt – GP 1.1 … GP 4.2, és mindegyik SP értelmezett, alkalmazott 5. optimalizált – GP 1.1 … GP 5.2, és mindegyik SP értelmezett, alkalmazott

A CMMI V.1.2. Általános célok és gyakorlatok •

GG1. A sajátos célok elérése -

•

GG2. A menedzselt folyamat intézményesítése -

•

GP 3.1 A definiált folyamat létrehozása GP 3.2 Fejlesztési információk összegyűjtése

GG4. A mennyiségileg menedzselt folyamat intézményesítése -

•

GP 2.1 Szervezeti irányvonal (policy) meghatározása GP 2.2 A folyamat tervezése GP 2.3 Erőforrások rendelkezésre bocsátása GP. 2.4 Felelősségek kijelölése GP 2.5 Emberek képzése GP 2.6 Konfigurációk menedzselése GP 2.7 A folyamatban érdekelt felek azonosítása és bevonása GP 2.8 A folyamat követése és vezérlése GP 2.9 A folyamat betartásának objektív kiértékelése GP 2.10. Állapot szemlézése a felsőbb vezetőséggel

GG3. A definiált folyamat intézményesítése -

•

GP 1.1 Az alapgyakorlatok végrehajtása

GP 4.1 Mennyiségi célok meghatározása a folyamat számára GP 4.2 A részfolyamatok teljesítményének stabilizálása

GG5. Az optimalizáló folyamat intézményesítése -

GP 5.1 Folytonos folyamatjavítás biztosítása GP 5.2 A problémák kiváltó okainak megszüntetése


22

Jegyzet

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) A CMMI V1.2 szintek kulcsfolyamat-területei

2.2.5 A CMMI V.1.3 kulcsfolyamatok (változások) A CMMI V.1.3 – DEV kulcsfolyamatai: •

Projektmenedzsment: -

•

Folyamatmenedzsment: -

•

Projekttervezés (PP) Projektkövetés és vezérlés (PMC) Beszállítói megállapodás menedzsment (SAM) Integrált projektmenedzsment + IPPD (IPM+IPPD) Kockázatmenedzsment (RSKM) Mennyiségi projektmenedzsment (QPM) Követelménymenedzsment (REQM)

Szervezeti szintű folyamatszemlélet (OPF) Szervezeti szintű folyamatdefiníció + IPPD (OPD + IPPD) Szervezeti szintű képzés (OT) Szervezeti szintű folyamatteljesítmény (OPP) Szervezeti szintű innováció és fejlesztés (OID) Szervezeti teljesítmény menedzsment (OPM)

Fejlesztés: -

Követelményfejlesztés (RD) Követelménymenedzsment (REQM) Műszaki megoldás (TS) Termékintegráció (PI)


23

Jegyzet •


Verifikáció – ellenőrzés (VER) Validáció – érvényesítés (VAL)

Szupport: -

Konfigurációmenedzsment (CM) Folyamat- és termék- minőségbiztosítás (PPQA) Mérés és elemzés (MA) Döntéselemzés és döntéshozatal (DAR) Ok-elemzés és megoldás (CAR)

A CMMI V.1.3 Általános célok és gyakorlatok (változásokkal) •

GG1. A sajátos célok elérése -

•

GG2. A menedzselt folyamat intézményesítése -

•

GP 1.1 Az alapgyakorlatok végrehajtása

GP 2.1 Szervezeti irányvonal (policy) meghatározása GP 2.2 A folyamat tervezése GP 2.3 Erőforrások rendelkezésre bocsátása GP. 2.4 Felelősségek kijelölése GP 2.5 Emberek képzése GP 2.6 Konfigurációk menedzselése Munkaeredmények ellenőrzése GP 2.7 A folyamatban érdekelt felek azonosítása és bevonása GP 2.8 A folyamat követése és vezérlése GP 2.9 A folyamat betartásának és kijelölt munkaeredmények objektív kiértékelése GP 2.10. Állapot szemlézése a felsőbb vezetőséggel

GG3. A definiált folyamat intézményesítése -

GP 3.1 A definiált folyamat létrehozása GP 3.2 Fejlesztési információk összegyűjtése Folyamattal kapcsolatos tapasztalatok összegyűjtése


24

Jegyzet

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) A CMMI V1.3 szintek kulcsfolyamat-területei


Mutassa be a V-Modell alapelvét! Mutassa be a Scrum szerinti szoftverfejlesztés főbb szerepköreit és főbb lépéseit! Hasonlítsa össze a hagyományos vízesés modell jellegű szoftverfejlesztést a Scrum szerinti szoftverfejlesztéssel, mik a főbb előnyök-hátrányok? Jellemezze a CMMI modell folyamatos és lépcsős ábrázolási módjait? Mi jellemzi a CMMI modell értelmezése szerint az „éretlen” és az „érett” folyamatokat? Melyek a CMMI modell érettségi szintjei, és jellemezze röviden őket? Mit határoznak meg a CMMI egyes kulcsfolyamat területeire (KPA-kra) vonatkozó általános célok (GG) és sajátságos célok (SG)?


25

Jegyzet


3 Követelménykezelés a szoftverfejlesztésben Tapasztalat: -

Sok hiba visszavezethető hiányos vagy ellentmondásos specifikációra. A követelmények definiálatlansága a projektek bukásának leggyakoribb oka.

3.1 Követelménykezelési alapelvek 3.1.1 Meghatározások A követelmény egy önmagában kifejezett igény a rendszer vagy az azt létrehozó projekt valamilyen jellemzőjére. -

Bejövő igény, elvárás (felhasználóktól, megrendelőtől, más érdekelt felektől) Validáció alapja

A követelménykezelés a projektben megvalósítandó szoftver jellemzőinek meghatározása -

szisztematikus művelet a követelmények összegyűjtésére és rögzítésére; kifejezi és rögzíti a megrendelő és a projekt közötti megegyezés tartalmát; egyértelművé teszi a későbbi követelmény változásokat; elkerülhetővé teszi a plusz funkciók „begyűrűzését”;

A specifikáció -

-

a (szoftver-) tervezők, fejlesztők felé átalakított elvárások a követelménykezelés eredménye megvalósulhat többféle szinten is, különböző elnevezései vannak pl. követelményterv (requirement spec.), funkció-terv (function spec.), architektúraterv (architecture spec.), design-terv (design spc.), rendszerterv (system spec.), stb. a verifikáció alapja Elvárások a specifikációval szemben: o A követelmények teljes lefedése Funkcionális követelmények Extra-funkcionális (vagy nem-funkcionális) követelmények o Megfogalmazás: egyértelmű, igazolható, megvalósítható o Javasolt megoldások: Szigorú specifikációs nyelv (pl. formális nyelvek) Ellenőrzött (tervezés ill. specifikációs) minták, módszerek használata Utólagos ellenőrzés

3.1.2 A követelménykezelés feladatai -

A követelmények hatékony, strukturált tárolása A követelmények finomítása és kapcsolódása o pl.: követelményterv -> rendszerterv -> modulterv -> forráskód -> teszt A követelmények életciklusának támogatása o felvétel – törlés – változás – finomítás – kapcsolatok ábrázolása Elemzési lehetőségek o Hatás analízis – Mit befolyásol, ha a követelmény megváltozik?


26

Jegyzet o o

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Eredet analízis – Milyen követelményre vezethető vissza? Miért van itt, szükséges-e? Fedettség analízis – Mely követelmények nincsenek implementálva? Mely követelmények nincsenek tesztelve?

3.1.3 A követelménykezelés lépései 1. A probléma feltárása és elemzése o o

A szakma megismerése Követelmények összegyűjtése

2. Követelmények részletezése o

2 vagy több-szintű részletezettséggel

3. Követelmények rendszerezése o o o

Osztályozás Összefüggések felvétele Ellenőrzés, ellentmondások feloldása

4. Változások követése, követelmény-karbantartás

3.1.4 Tervezés több szinten Három-szintű követelmény-struktúra 1 2 3

Felhasználói követelmények Rendszerkövetelmények Szoftverterv-specifikáció (architektúra, design, …)

Egyszerűsített, két-szintű követelmény-struktúra 1 2

Ad-hoc: rendszerképességek + résztvevői igények vázlatos, nem rendszerezett, ismétlődéseket és ellentmondásokat is tartalmazhat Rendszerezett követelmények szisztematikus, konszolidált, konzisztens funkcionális és nem-funkcionális követelményeket eredményez (funkcionális követelmények általában „használati eseteket” írnak le)


27

Jegyzet

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Kétszintű követelménykezelés ábrázolása

Ad hoc szint (első szint): Rendszerképességek = „Features” -

A rendszer szolgáltatásainak többé-kevésbé szabatos leírása Forrása általában: „előzetes specifikáció” (v. koncepcióterv, …) o A projekt ötletgazdái készíthetik, vagy o Gyakran az ajánlatkérés / projekt tervezés alapja o Természetes nyelven, mérsékelten szabados stílusban

Résztvevői igények -

Készül ált. kezdeti fázisban, de lehet a később is Célja a rendszer tulajdonságainak, elvárásoknak a pontosítása, részletezése Bárki érintett javasolhatja /// interjúk, ötletbörzék, stb. eredményei

3.1.5 Ellenőrzési relációk a V-modellben


28

Jegyzet


3.2 Példák különböző rendszerek vizsgálati szempontjaira 3.2.1 Vizsgálati szempontok biztonságkritikus rendszerekre Teljesség -

Funkciók, hivatkozások, eszközök

Konzisztencia (ellentmondás-mentesség) -

Külső és belső Követhetőség

Megvalósíthatóság -

Erőforrások Használhatóság Karbantarthatóság Kockázatok: költségbeli, technikai, környezeti

Tesztelhetőség -

Specifikus Egyértelmű Számszerűsíthető

3.2.2 Vizsgálati szempontok IEEE 830:1998 szabvány alapján IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications Helyes -

A szoftverre vonatkozó követelményeknek megfelel Konzisztens a külső forrásokkal

Egyértelmű -

Nem félreérthető, csak egy jelentés Hasznosak a formális, fél-formális specifikációs nyelvek

Teljes -

Minden bemenetre van specifikált viselkedés TBD csak indoklással oldható fel (TBD = „to bo determined”)

Konzisztens -

Nincs belső ellentmondás Egységes terminológia

Fontosság és stabilitás szempontjából rendezett -

Követelmények szükségessége, változatlansága felmérve

Ellenőrizhető -

Egyértelmű egy követelmény nem-teljesülése

Módosítható -

Nem redundáns, jól strukturált


29

Jegyzet -


Jól elválasztott követelmények

Követhető -

Eredet becsatolható További hatások hivatkozhatóak

3.2.3 Vizsgálati szempontok reaktív (irányítástechnikai) rendszerekre Állapotdefiníció -

Biztonságos a kezdőállapot Belső modell aktualizálva van a környezettel (kimaradó bemeneti események esetén time-out van, és nincs kimenet akció)

Bemenetek (események) -

Minden bemenetre, minden állapotban van specifikált viselkedés (reakció) Egyértelműek a reakciók Van bemeneti ellenőrzés (értékbeli, időbeli) Hibás bemenetek kezelése specifikálva Megszakítások gyakorisága korlátozva

Kimenetek -

Hihetőség-vizsgálat kritériumai specifikáltak Nincsenek fel nem használt kimenetek Környezeti feldolgozó-képesség be van tartva

Kimenetek és trigger kapcsolata -

Kimenetek hatása a bemeneteken keresztül ellenőrizve A szabályzási kör stabil

Állapotátmenetek -

Minden állapot elérhető statikusan Állapotátmenetek visszafordíthatók (visszaút van) Több átmenet van veszélyes állapotból biztonságosba Megerősített átmenet van biztonságos állapotból veszélyes állapotba

Ember-gép interfész Kezelő felé kimenő események specifikációja: -

Sorrendezés előírt (prioritással) Frissítés előírt Gyakoriság korlátozott (kezelő terhelhetősége)

3.3 A követelménykezelés problémái Szerződéses fejlesztésnél (egyedi megrendelésnél): •

Érdekellentétek – A megrendelő palotát remél, de a fejlesztő legszívesebben kockaházat építene.

•

Világképek különbözősége – „Szakterületi” és „szoftver” tudás. – Nincs közös nyelv a megrendelő és a szoftverfejlesztő között; mindketten csak korlátozottan alkalmasak követelménykezelésre. (Sokszor „vak vezet világtalant”.) ☺


30

Jegyzet •

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Változó igények, és későn eszmélő / lusta megrendelő – „Feature creep”, azaz a követelmények utólagos belopódzása a fejlesztés során. (Sokszor a megrendelő az elején nincs is tisztában azzal, mit és hogyan szeretne…majd később mindent ☺ )

Piaci fejlesztésnél (dobozos terméknél): •

Piaci és felhasználói igények eltalálása – Sőt. Más az, amiért megveszik, és más az, amiért szeretni fogják.

•

„Time to market” pressure – Hamarabb kell megjelenni, mint a konkurencia.

•

„Benefit vs. Cost” – Az extra funkcionalitás megéri-e a plusz fejlesztési erőforrásokat? – Tényleg kell-e? (reális veszély: dagadt, lassú programok) – Megéri-e ill. van-e keret a kellő ellenőrzésekre, minőségbiztosításra? – Napjaink divatos pályázatai, ahol „csak az ár számít”…

3.4 Követelménykezelés a CMMI-ben A CMMI-ben két kulcsfolyamat kapcsolatban. Ezek:

(Keyprocess)

van

a

követelmények

kezelésével

RD – Requirements Developement -

Folyamat célja: az ügyfélre, a termékre és a termék-komponensekre vonatkozó követelmények előállítása és elemzése. Speciális célok (specific goals): o SG1: Develop Customer Requirements (ügyfél követelmények meghatározása) o SG2: Develop Product Requirements (termék követelmények meghatározása) o SG3: Analyse and Validate Requirements (követelmények elemzése és validálása)

RM – Requirements Management -

-

Folyamat célja: a projekt termékei és termék-komponensei követelményeinek kezelése, és azon követelmények és a projekttervek és munkatermékek közötti inkonzisztenciák azonosítása. Speciális célok (specific goals): o SG1: Manage Requirements (követelmények kezelése)


-

Mutassa be a követelménykezelés alapvető feladatait! Mutassa be a követelménykezelés fő lépéseit! Mutassa be a követelménykezelés jellemző gyakorlati problémáit egyedi megrendelésre fejlesztés, illetve dobozos termék fejlesztés esetén? Milyen szempontok alapján csoportosíthatóak a vizsgálati szempontok bizonyos rendszerek esetén? Mondjon példát ilyen csoportosítási szempontokra, csoportosításra! Milyen CMMI kulcsfolyamat területek (KPA-k) foglalkoznak a követelménykezeléssel, és mutassa be azok fő célját?


31

Jegyzet


4 Tesztelés a szoftverfejlesztésben A tesztelési folyamat során átgondolandó kérdések 1. Mi a tesztelés célja? 2. Mit tesztelünk? 3. Hogyan illeszkedik a tesztelés a fejlesztési folyamatba? 4. Hogyan tesztelünk? 5. Hogyan határozzuk meg a teszteseteket? 6. Hány teszteset futtatása szükséges? 7. Hogyan hajtjuk végre a teszteket? 8. Hogyan értékeljük ki a teszteket? 9. Mik az eredményes tesztelés előfeltételei? 10. Milyen tool-ok állnak rendelkezésre a teszteléshez?

4.1 A tesztelés életciklusa 4.1.1 Tesztelés célja Mi a tesztelés célja? -

A tesztelés célja hibák megtalálása, feltárása. A tesztelés „hivatalos” célja még: az ügyfél számára a termék minőségének igazolható bizonyítása. Miért jó ez? Hibák megtalálása, amilyen hamar csak lehet… o o o o o

Ezeket kijavítjuk (de legalább tudunk róla…) Gyorsítjuk a fejlesztés menetét Projekt érettségéről információ Károkozás megelőzése Rizikó számszerűsítése …

4.1.2 Tesztelés objektuma Mit tesztelünk? -

A funkcionális és a nem-funkcionális minőségjellemzők tesztelése. o funkcionális: funkcionalitás, GUI viselkedése, beadandó mezők szintaxisa, stb… o nem-funkcionális: terhelhetőség (performancia), megbízhatóság, rendelkezésre állás, használhatóság, stb…


32

Jegyzet


4.1.3 Tesztelés helye a fejlesztési folyamatban

Tesztelés •

Megfelel-e az elvárt viselkedésnek / követelményeknek? Egy vagy több futtatható állapotban levő szoftver komponens/modul/rendszer meghatározott feltételek mellett (adat, esemény) történő futtatása, és a működés eredményének értékelése.

Verifikálás •

A szoftver megfelel-e a specifikációnak? Igazoló ellenőrzése az előírt követelmények teljesítésének.

Validálás •

A szoftver megfelel-e a felhasználó igényeinek? Érvényesítő ellenőrzése a valamilyen tervezett felhasználásra vonatkozó konkrét követelményeknek.

A tesztmérnök feladatai a követelmények fázisban: • • • • •

A feladatot tisztázni. Érthetőek és tisztázottak-e a követelmények? Tesztelhetőek-e a követelmények? Vannak-e ellentmondások a követelmények között? Teljes rendszert alkotnak-e a követelmények, vagy egyes részek csak elnagyoltan jelennek meg?

a tervezési / megvalósítási fázisban: •

Teszt stratégia. Automatizálás célja és módja, felhasználandó eszközök, tesztlabor felszerelése és elrendezése, biztonsági sebezhetőség teszt módja.

•

Teszt terv Konkrét leírása (szcenárió) minden tesztesetnek. Előfeltételek, lebonyolítás, elvárt eredmény. Negatív eseményekre is tesztet (pl. hibás input, memóriahiány, stb.).


33

Jegyzet


4.1.4 Hogyan tesztelünk? – Tesztelések csoportosítása Tesztelések szintjei: -

-

Stand-alone-test (modulteszt vagy unit-teszt): egyes modulok (vagy modulcsoportok) önálló tesztelése Integrációs teszt: az interfészek működésének tesztelése Rendszerteszt: egy kész rendszer tesztelése, viszonyítva a követelményspecifikációban meghatározott funkciókhoz, teljesítményekhez, illetve minőségi követelményekhez. Átadási teszt: az ügyfél követelményeinek megfelelő működés bemutatása. Regressziós teszt: a kód megváltoztatása utáni újabb hibák megjelenésének elkerülése érdekében végrehajtott tesztelések

Tesztelések követelményei: Unit-teszt (komponens teszt): – Célja: Az elkülönülten kezelhető komponensek/unitok működését igazolja, és a hibákat feltárja. - Tesztelés iránya o Funkcionális jellemzők, melyeket a rendszerterv előír. o Nem funkcionális jellemzők, mint pl. memória szivárgás, robusztusság, kódlefedettség. - Test driven development o A komponens tesztkörnyezetét hamarabb írják meg, mint magát a kódot. o Az inkrementális-iteratív fejlesztéshez nagyon alkalmas. o Alapértelmezett automatikus, regressziós teszt. Integrációs teszt o Több modult összekapcsolunk, és mint egységet tekintjük. Az modulok száma, mérete és fontossága szerint az integráció több szinten is megvalósul. o Teszteljük a modulok közötti interfészt, és azok együtt-működését. Az egyes modulok saját működésének ellenőrzése nincs fókuszban. o Black-box szemlélet! o Ellentmondásokat keresünk. Nagyobb csoport esetén bonyolultabb hibaképek keletkeznek, a hibát nehezebb egy-egy modulhoz hozzárendelni. o Nem funkcionális szempontok figyelembe veendők! Teljesítmény, megbízhatóság, ... Rendszerteszt - Célja: A teljes rendszer futásának, működésének egyben történő ellenőrzése. - Szempontok: o Jellemzően „black-box” teszt, elsősorban verifikációs céllal. o Legyen gyanakvó a hozzáállásunk! Ez egy destruktív fázis. Azt keressük, milyen szempontok alapján buktatható meg a rendszer. Minden eszköz megengedett. Átadási teszt - Célja: Egy teljességében integrált rendszert tesztelünk, hogy igazoljuk, hogy teljesíti a vele kapcsolatban támasztott igényeket. - Szintjei: o Kiszállítás előtt közbenső teszteket definiálnak:


34

Jegyzet

o

o

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Alfa teszt: A felhasználó a fejlesztő telephelyén teszteli az aktuálisan működő rendszert. Tipikusan dobozos termékek esetén használják. Béta teszt: (Bemutató változat) A béta verziót a felhasználók szűk körének adják ki. Így valódi felhasználói tesztelésnek vetik alá. Egyes termékek esetén a teljes felhasználói közösség megkapja a béta terméket, hogy növeljék a visszajelzések mennyiségét. Feature freeze. Nem építenek be új funkciókat. Gamma, delta… (release candidate). A termék kész, nem tartalmazhat súlyos hibákat (code complete). Felhasználói átvételi teszt. Jellemzően igazolja, hogy a rendszer alkalmas-e az üzleti felhasználásra. Az tesztet a felhasználó irányítja, hogy elfogadja-e a terméket. Üzemeltetési átvételi teszt. A rendszer-adminisztrátorok ellenőrzik a nekik fontos funkciókat (Mentésvisszaállítás, katasztrófa visszaállítás, ügyfélmenedzsment, karbantartási feladatok, sebezhetőség ellenőrzése).

Tesztelések fajtái -

„Black-box” teszt: tesztelés a specifikáció és a program viselkedésbeli eltéréseinek meghatározására Jellemzői:

-

o A forráskód a teszt során nem ismert; o Adott bemenetre elvárt kimenetek; o Kapott és elvárt eredmények összehasonlítása; o Mindegyik tesztelési szinten használható; „White-box” teszt: tesztelés a specifikáció és a program viselkedésbeli eltéréseinek meghatározására Jellemzői: o o o o

A forráskód a teszt során ismert; Strukturális tesztelés; A kód egyes részeinek a tesztelése; Technikák: Adat folyam tesztelés Vezérlési folyamat tesztelés • Ágak tesztelése • Utasítás lefedettség • Döntés lefedettség

4.1.5 Tesztesetek meghatározása Tesztesetek előállításakor: -

Tesztelés befejezési („testend-”) kritérium meghatározása (tesztelési tervben!) Tesztelés struktúrájának meghatározása


35

Jegyzet -

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Teszt-fajták meghatározása (pl. black-boksz v. white-boksz tesztelés, nem funkcionális tulajdonságok tesztelése (performancia, stabilitás, használhatóság, …) Teszt-fajtánként a tesztesetek vagy tesztelési csomagok meghatározása

Tesztesetek dokumentálásakor megadni: -

Megnevezés Teszteset célja Pozitív / negatív eredmény Kézi / automatizált HW/SW konfiguráció A tesztelés tárgyának (objektumának) kiindulási állapota Minden bemeneti adat Tesztelés lefutása, az egyes lépések megadásával Lépésenkénti elvárt eredmények

4.1.6 Hány teszteset futtatása szükséges? Teszt-befejezési kritériumok -

Hány tesztesetet határozzunk meg? A rendszer állapotához fel kell mérni a meg nem talált hibák hatását és következményét. A rendszer megbízhatósága. A hibaszám metrika megjósolja, hogy mikor kerül érett fázisba a termék. Hibatrendek.

A tesztelést nem lehet befejezni, csak abbahagyni. -

Fejezzük be, ha a következő hiba felfedezésének határköltsége nagyobb, mint a hiba miatti veszteség

Hány tesztesetet határozzunk meg? Pl. „Black-box” teszt esetén tesztelt funkciókhoz a szükséges tesztesetek száma meghatározásának szempontjai: -

rendelkezésre álló büdzsé, funkció kritikussága, funkció összetettsége, eddigi tapasztalatok, bemeneti / kimeneti értéktartomány lehetséges és hibás értékeire, határértékeire is, stb…

4.1.7 Tesztek végrehajtása Hogyan hajtjuk végre a teszteket? -

Megfelelő teszt-csomag összeállítása (a tesztesetekből) Tesztelés végrehajtása (manuálisan v. automatizáltan) Tesztelés dokumentálása

4.1.8 Tesztek kiértékelése -

Teszt-jegyzőkönyvek/-jelentések készítése A sikertelen (hibásan lefutott) tesztesetek elemzése


36

Jegyzet -


Hibalokalizálás A megtalált (azonosított) hibák felvitele egy hibakezelő rendszerbe Regressziós tesztesetek aktualizálása

Tesztelés dokumentumai -

Tesztelési stratégia Teszt-tervek (benne tesztelési forgatókönyvek, és teszteset leírások, …) Teszt-jegyzőkönyvek Teszt-jelentések

Tesztelés dokumentumainak életciklusa -

-

Tesztelési stratégia és tervek >> előíró dokumentumok o Készítés – ellenőrzés – (javítás / újra ellenőrzés) – jóváhagyás – felhasználás (közben szükség esetén módosítás / ellenőrzés / jóváhagyás) – archiválás Teszt jegyzőkönyvek, jelentések >> igazoló dokumentumok o Készítés – (ellenőrzés) – jóváhagyás - archiválás

PÉLDA: Tesztjelentés tartalma – egy rendszerteszthez (példa) -

-

Bevezetés Tesztelés végrehajtása o A tesztelés tárgya o Tesztelési eljárások o Teszt-specifikációk, tesztadatok o Tesztelők o Tesztelés időpontja o Tesztelés ráfordítása o Tesztelés feljegyzései o Teszteléshez megjegyzések Tesztelési eredmények o A tesztelés tárgyában talált hibák o A tesztelési specifikáció hibái o A tesztelés értékelése o Hibák javítási módja

4.1.9 Tesztelés sikerkritériumai Tervezett ráfordítások biztosítása -

Tesztelést a projekt részeként betervezni Tesztelési erőforrások és infrastruktúra biztosítása

Specifikáció készítésekor a tesztelhetőségre odafigyelni -

Tesztelhetőség: o Mennyire könnyű tesztkritériumok definiálása? – elsősorban a specifikációtól függ. o Mennyire könnyű ezen tesztkritériumok vizsgálatára teszteket végrehajtani? – technikai tényezőktől függ.)


37

Jegyzet


4.1.10 Tesztelési toolok Az interneten rengeteg elérhető, lásd pl.: -

http://en.wikipedia.org/wiki/Category:Software_testing_tools http://en.wikipedia.org/wiki/Test_management_tools

4.2 Különleges kód-ellenőrzések Statikus és dinamikus kódellenőrzések (kódanalízis) Statikus kódanalízis Automatikus eszközzel, metrikák használatával kódelemzés, ami a kód komplexitására, strukturáltságára, kommentár-részére, logikai hibákra, konvenciók alkalmazására, stb. tesz állításokat Dinamikus kódanalízis Kód futtatása azzal a céllal, hogy minél nagyobb területet (funkciók / elágazások / memória-használat / stb…) fedjen le, és a programfutás viselkedéséből szűrje ki a lehetséges hibákat, inkonzisztenciákat, …


Mutassa be a V-Modell alapján a termék életciklusa során a tesztelés főbb fázisait, és azok alapján az egyes tesztfázisok feladatát, célját! Hasonlítsa össze a modul teszt – integráció teszt – rendszer teszt – átadási teszt tárgyát, célját és követelményeit! Mutassa be, milyen a termék nem-funkcionális működésére vonatkozó teszteket ismer, és mutassa be azok célját? (legalább 2 példát mutasson be) Mutassa meg, hogy melyek a tesztmérnök alapvető feladatai a szoftverfejlesztési életciklus követelmények, implementálási és tesztelési fázisaiban! Hasonlítsa össze a Black-box és a White-box teszteléseket, és jellemezze őket! Melyek a tesztesetek meghatározásának szempontjai? Mit (milyen információkat) kell megadni az egyes tesztesetek megadásakor? Mit kell alapvetően egy tesztjelentésnek tartalmaznia? Mutassa be a tesztelés alapvető előíró és igazoló dokumentumait, és jellemezze azok használati célját?


38

Jegyzet


5 Tooling használata a szoftverfejlesztésben 5.1 Tool-ok használata Tool-ok használatának a célja A munkavégzés -

tervezésének, szervezésének, irányításának nyomon követésének, kontrollingjának végrehajtásának ellenőrzésének dokumentálásának egészének vagy csak egyes szakaszainak (fázisainak)

a támogatása, megkönnyítése, átláthatóvá tétele, hogy az mindig, egységesen és következetesen ugyanúgy történjen. (Módszertani támogatás is egyben!) A használt tool-ok forrása -

Saját fejlesztésű eszközök Kapott eszközök (anyaháztól, megrendelőtől – lehet ott saját fejlesztésű vagy vett/beszerzett) Vásárolt/beszerzett eszközök o Kereskedelmi forgalomban lévő Jellemzően szupport (termék támogatás) tartozik hozzá o Open source termék Vásárolt szupporttal Nincs vásárolt szupport (lehet szupport nélkül, vagy a fejlesztői közösség által nyílt támogatás van)

5.2 Példák különböző kategóriájú tool-okra Tool-ok felhasználás szerint -

-

Fejlesztés támogatás – fejlesztői környezet (CASE) o Debugging tool-ok sokszor a fejlesztői környezettel integráltak Modellező eszközök (követelmények, tervezés támogatás, pl. UML …) Verziókezelés Feladat követés (issue tracking, ticketing, …) o Felhasználásuk több célra is lehet: projektmenedzsment, feladatok kiosztása követése és kontrollja, workflow menedzsment, hiba követés, üzemeltetés és HelpDesk menedzsment, munkaidő menedzsment, … Statikus kódanalízis (forráskód ellenőrzése)

5.2.1 Modellező toolok Modellező tool-ok haszna (példák) -

Követelmények strukturált bevitele, fejlesztendő szoftver által támogatott működés modellezése (magas szinten) Adatbázis modellezés, funkciók modellezése


39

Jegyzet -


Grafikus ábrázolások Követelmény-struktúrában ellentmondások kiszűrése Fejlesztői dokumentációk (dokumentáció-vázak) generálása Felhasználói dokumentációk (dokumentáció-vázak) generálása Forráskód-generálás (vagy legalább alap-struktúra a modell alapján) Reverse engineering Teszt-esetek (teszt szcenáriók) generálása Tesztelés támogatása

Modellező tool-ok – példák -

-

Ingyenes (open-source) tool-ok: o NClass http://nclass.sourceforge.net/ forráskód generálás, főképp Java és C# támogatás, reverse codeengineering, o Eclipse http://www.eclipse.org/ integrált fejlesztői környezet, több nyelv támogatása (Java, Ada, C, C++, COBOL, Perl, stb.), modellező környezet (UML, …) o Umbrello UML Modeller http://umbrello.kde.org/ UML modellező (KDE Technology alapon), számos programnyelv támogatása (C++, Java, Ada, Perl, PHP, …), struktúrák, grafikák … Fizetős tool-ok: o Enterprise Architekt (EA) http://www.sparxsystems.com/ üzleti folyamat modellezése, UML, prototyping és szimuláció, követelmények kezelése és követése, kódgenerálás (ca 10 programozási nyelv támogatása), tervezési dokumentációk (specifikációk) generálása, debugging, tesztelés és tesztelés tervezése, projekt menedzsment támogatás és követés, .. o IBM Rational Rhapsody (és a többi Rational termék is …) http://www-03.ibm.com/software/products/en/ratirhapfami UML modellezés, követelmény kezelés és követés, kódgenerálás (C, C++, Java, …), reverse code-engineering, verziókezelés, statikus modell ellenőrzés, termék automatikus dokumentálás, …

5.2.2 Verziókezelő tool-ok Verziókezelő tool-ok haszna Objektumok (dokumentumok, forráskódok, kódok) verziókezelése, azaz: -

csoportmunkában történő készítésének támogatása (ellentmondások feloldása); különböző változatainak követése, tárolása, kezelése; különböző verziók és státuszok (munkaanyag, ellenőrzött, jóváhagyott, …) kezelése; régi változatok tárolása, visszakeresése repository-ban; kódoknál build-ek támogatása (összetartozó komponensek megfelelő verzióinak kezelése);


40

Jegyzet


Verziókezelő tool-ok – példák -

-

Ingyenes (open-source) tool-ok : o Concurrent Versions System (CVS) http://savannah.nongnu.org/projects/cvs szerver-kliens alkalmazás, több fejlesztő egyidejű munkájának támogatása, verziókövetés, változáskövetés a szövegben (forráskódban) o Apache Subversion (SVN) http://subversion.apache.org/ szerver-kliens alkalmazás, több fejlesztő egyidejű munkájának támogatása, változáskövetés a szövegben (forráskódban) , könyvtárak verzionálása is o GIT http://git-scm.com/ elosztott kódú verzió követés, több fejlesztő osztott munkájának támogatása, nincs központi szerver, nincs központi repository, mindenki a saját munkakönyvtárában teljes (saját) repository-t használ, kapcsolat egyedi megosztásokon és szinkronizálásokon keresztül o Fossil http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki elosztott kódú verzió kontroll és hiba követés, wiki alapú szoftver, több fejlesztő osztott munkájának támogatása, nem szükséges központi szerver (de a multi-platform szinkronizálásához előnyös, ha van egy). o Mercurial http://mercurial.selenic.com/ elosztott kódú verzió kontroll, nagy performancia és jó skálázhatóság, text fájlok és forráskódok elosztott verziókövetése, web alapú interfész o Veracity http://veracity-scm.com/ elosztott kódú verzió kontroll és hiba követés, integrált agilis build management, wiki alapú felület, Fizetős tool-ok: o Team Foundation Server (TFS) – Microsoft termék http://www.visualstudio.com/products/tfs-overview-vs szerver-kliens alkalmazás, több fejlesztő egyidejű munkájának támogatása, verzió kontroll, agilis feladat tervezés és követés támogatása, együttműködés más rendszerekkel (natív szupport a GIT-hez is), build management, web alapú test case menedzsment, riportozási funkció o IBM Rational Team Concert https://jazz.net/products/rational-team-concert/ szerver-kliens alkalmazás, több fejlesztő egyidejű munkájának támogatása, verzió kontroll, feladat tervezés és követés támogatása, együttműködés más rendszerekkel (pl. SVN, GIT, ClearCase, JIRA), build management, riportozási funkció

5.2.3 Feladat követő tool-ok Feladat követő tool-ok haszna Feladatok – mint tevékenységek – tervezése, követése, elemzése, … © Dr. Horváth Zsolt László

41

Jegyzet -

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Munkatársak napi tevékenységének, munkájának tervezése, követése, értékelése – munkaidő kontroll, ráfordítás kontroll, stb. Feladatok workflow-tervezése, követése, kontrollja Projektek tervezése, követése, menedzselése, ábrázolása, … Szolgáltatások (karbantartás, ügyfél-szolgálat, stb.) irányítási, kontrollja, elszámolása, SLA-menedzsment

Feladatok – mint elvégzendő objektumok – tervezése, követése, elemzése -

Pl. hiba életciklus követés, fejlesztési, tesztelési, karbantartási, stb. tevékenység és objektum menedzsmentje

Feladat követő tool-ok – példák -

-

Ingyenes (open-source) tool-ok : o Bugzilla – Mozilla Foundation termék http://www.bugzilla.org/ szerver-kliens alkalmazás, web felület, hiba követés és tesztelés támogatás o Trac – Edgewall Software termék http://trac.edgewall.org/ szerver-kliens alkalmazás, wiki felület, projekt menedzsment eszköz, ticketrendszer alapú, hiba követés, workflow támogatás, interfész SVN-hez illetve GIT-hez, riportozás támogatása o MANTIS http://www.mantisbt.org/ Eredetileg bugtracker funkcióra alakították ki, de használható bármilyen feladatkövető funkcióra. szerver-kliens alkalmazás, wiki felület, ticket-rendszer alapú, hiba követés, workflow támogatás o Redmine http://www.redmine.org/ szerver-kliens alkalmazás, web felület, projektmenedzsment tervezés, támogatás, követés, párhuzamosan több projektre is, erőforrás tervezés és követés, változások követése, grafikus ábrázolások és riportok o OTRS (Open-source Ticket Request System) http://www.otrs.org/ szerver-kliens alkalmazás, wiki felület, feladat-kezelő rendszer, különösen alkalmas üzemeltetési-, HelpDesk-, feladat követési-, hiba kezelési-, incidens kezelési-, probléma kezelési- és egyéb hasonló feladatok irányítására, ITIL támogatás, automatikus üzenetgenerálás, workflow támogatás, riportozás támogatása Fizetős tool-ok: o JIRA – Atlassian termék https://www.atlassian.com/software/jira szerver-kliens alkalmazás, projekt menedzsment és követés, feladatok – erőforrások tervezése és követése, feladatsorok workflow-ban megtervezése és követése, hibakövetés, build and release management o FogBugz – Fog Creek Software termék http://www.fogcreek.com/fogbugz/ szerver-kliens alkalmazás, wiki felület, web-alapú projekt menedzsment


42

Jegyzet

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) eszköz, workflow támogatás, mező paraméterezhetőség, több projekt kezelése, becslés kezelés, teljesítmény követés, diagramok, …

5.2.4 Statikus kódanalízis toolok Statikus kódanalízis toolok haszna -

Potenciális hibák megtalálása – még a fejlesztési szakaszban Ezek az eszközök sokkal szigorúbban ellenőriznek, mint azt a normális compiler-ek teszik Programozási irányelveknek való megfelelés vizsgálata Programozási irányelvek (programing guidelines) o Csökkentik a kódolási hibalehetőségeket o Könnyebben olvasható forráskódok o Könnyebben hordozható forráskódok o Kevesebb energia szükséges a kódok megértéséhez (könnyebben karbantartható)

Statikus kódanalízis eszközök (tool-ok hibafeltárásra) – példák -

-

Ingyenes (open-source) tool-ok – Alkalmazások: o Splint (C, C++ only): http://www.splint.org Fizetős tool-ok – Alkalmazások: o FlexeLint, PC-Lint (C, C++): http://www.gimpel.com o Coverity Prevent (C, C++): http://www.coverity.com o Klocwork K7 (C, C++): http://www.klocwork.com o Jlint (Java): http://artho.com/jlint Fizetős tool-ok – Szolgáltatások: o Cleanscape (C, C++, Fortran): http://www.cleanscape.net

Statikus kódanalízis eszközök (tool-ok irányelveknek megfelelésre) – példák -

Fizetős tool-ok: o Telelogic – Logiscope (C, C++, Java): http://www.telelogic.de o QA-C; QA-C++;QA-J (C, C++, Java): http://programmingresearch.com o Codewizard (C, C++): http://www.parasoft.com o CodeCheck (C, C++): http://www.abraxas-software.com


Melyek az alapvető különbségek a fizetős, az ingyenes illetve az open-source toolok alkalmazásában? A szoftverfejlesztés folyamatában milyen feladatokat támogathatnak tool-ok használata? Mutasson mindegyikre egy-egy példát is! Milyen feladatokat látnak el a modellező toolok? Mutasson rá egy példát! Milyen feladatokat látnak el a verziókezelő toolok? Mutasson rá példát! Milyen feladatokat látnak el a feladatkövető toolok? Mutasson rá példát! Mire használhatóak a statikus kódanalízis toolok, milyen előnnyel járnak?


43

Jegyzet


6 Metrikák használata a szoftverfejlesztésben 6.1 Metrikák célja, alkalmazása 6.1.1 Metrikák (mérőszámok) meghatározása Az elérendő célhoz konkrét – operatív – kérdések feltétele, amihez meghatározhatóak kvantitatív mérőszámok (metrikák), amelyek alapján egyértelmű, kvantitatív döntések hozhatóak – a kitűzött célok teljesítése érdekében.

6.1.2 Problémák. – Miért nem működnek sokszor a metrikák? -

A metrikák célja nem közismert Egy „halott adatbázis” létrehozásának érzése; a metrikák haszna / használata nem ismert A végrehajtásban érintettek nem tudják, hogy mit is kéne csinálniuk (... és miért) Kiegészítő információk nélkül a mérőszámoknak (metrikáknak) nincs mondanivalójuk A végrehajtóknak és az érintetteknek hiányzik a hasznosságról, eredményről a visszacsatolás Hiányzik a felhasznált metrikák használatának és aktualizálásának szabályzása

6.1.3 Metrikák bevezetésének sikertényezői -

Általánosan elfogadott, teljesítendő cél (célkitűzés) A metrika felhasználója részéről egy explicit, egyértelműen megfogalmazott igény a metrika használatára Vezetőségi (menedzsment) támogatás A metrika használatára szükséges erőforrások (munkaidő, eszköz) biztosítása Felelősségek tisztázása Metrika felhasználási folyamatának részletes szabályozása Metrika-programban résztvevők számára (a szükséges) támogatás (support) biztosítása Metrika felhasználásának számonkérése, eredmények visszacsatolása

6.1.4 Egy metrika alkalmazási folyamatának szereplői Mérési felelős -

Egy metrika (mérőszám) mérési felelőse felelős az adatminőségért, a számadatok eltéréseinek felismeréséért, és ennek következtében a használhatatlan adatok kizárásáért, valamint az eredmények összefogásáért, feldolgozásáért és értelmezéséért.

Adatszolgáltató -

Egy metrika (mérőszám) adatszolgáltatója felelős a legjobb tudása szerint, a metrika felhasználója által kívánt formában a korrekt és valós mérési adatok szolgáltatásáért, továbbításáért.


44

Jegyzet


Felhasználó -

Egy metrika (mérőszám) felhasználója az a személy, aki a metrikák alapján döntéseket hoz. Általánosságban a metrika felhasználója határozza meg a metrika bevezetését és nevezi ki a metrika mérési felelősét és adatszállítóját, és követeli meg a metrika mérési eredményeit.

6.1.5 A megfelelő metrikák kiválasztásának kritériumai Érvényesség

a metrika valóban megragadja a mért tevékenységet

Robosztusság

a metrikát a felhasználók hasonlóan értelmezik, időben, térben és szervezeti egységek között összehasonlítható és megismételhető

Hasznosság

a metrika a döntéshozó számára érthető; döntést támogat

Gazdaságosság

a metrika haszna felülmúlja használatának költségeit (adatgyűjtés, elemzés, beszámolás, stb.)

Részletezettség foka

a metrika a megfelelő aggregáltsági szintet ragadja meg

Magatartási fitség

a metrika minimalizálja a nem szándékolt magatartásra való ösztönzést (manipulálás)

Mérhetőség

a metrika legalább évente egyszer mérhető

6.2 Példák metrikákra 6.2.1 A metrikák csoportosítása Metrika felhasználási ideje szempontjából -

-

Eredmény-mutatók – azt mutatják, hogy az adott dimenzióban mit ért el az adott folyamat, mik a folyamat eredményének a hatásai, következményei, visszacsatolásai, … (jellemzően utólagos mutatók) Folyamat-mutatók – azt mutatják meg, hogy az adott folyamat jellemző működési paraméterei milyenek, hol tart a folyamat a megvalósításban, … (jellemzően folyamat közbeni jellemzők)

Vizsgált terület szempontjából -

Vállalati / stratégiai célkitűzések mérőszámai (BSC, …) Projekt metrikák (projekt költségek, határidők, keretek tervezésének, tartásának, termelékenységének mérőszámai, stb.) Folyamat metrikák (folyamatidő, ügyfél elégedettség, módszertanok alkalmazása, stb.) Minőség metrikák (hiba-statisztikák, hibakeresési metrikák, tesztelési metrikák, stb. – a kódmetrikák is elsősorban ide tartoznak)

6.2.2 Projektmetrikák – példák -

Ráfordítás stabilitása Ráfordítás tartása Költség stabilitása Költség tartása Határidő stabilitása Határidő tartása


45

Jegyzet -


Produktivitás Módszerek alkalmazása (pl. erőforrás becslésnél) …

Ráfordítás stabilitása -

-

Kategória: projekt metrika Értelmezése: bemutatja a projekt során a kezdeti időponttól számítva a megvalósult személyi ráfordítás arányát az (első) tervezethez képest. A ráfordítás stabilitása (illetve a tervezés megbízhatósága is egyben) annál jobb, minél közelebb van ez az érték az 1-hez. Kiszámítása: valós személyi ráfordítások / (első) tervezett személyi ráfordítások Mérési felelős: projektvezető Mérési adatszolgáltató: projektvezető – tervadatok; projektben a munkatársak – a valós ráfordítási adatok tekintetében Metrika felhasználója (pl.): vállalati operatív vagy gazdasági vezető

Ráfordítás tartása -

-

Kategória: projekt metrika Értelmezése: bemutatja a projekt során a kezdeti időponttól számítva a megvalósult személyi ráfordítás arányát az (aktuálisan érvényes) tervezethez képest. A ráfordítás tartása annál jobb, minél közelebb van ez az érték az 1-hez. (ráfordítás tartása > 1, akkor az az aktuális projektkeret túllépése) Kiszámítása: valós személyi ráfordítások / (aktuálisan érvényes) tervezett személyi ráfordítások Mérési felelős: projektvezető Mérési adatszolgáltató: projektvezető – tervadatok; projektben a munkatársak – a valós ráfordítási adatok tekintetében Metrika felhasználója (pl.): vállalati operatív vagy gazdasági vezető

Költség stabilitása -

-

Kategória: projekt metrika Értelmezése: bemutatja a projekt során a kezdeti időponttól számítva a megvalósult költségek arányát az (első) tervezethez képest. A költség stabilitása (illetve a tervezés megbízhatósága is egyben) annál jobb, minél közelebb van ez az érték az 1-hez. Kiszámítása: valós költségek / (első) tervezett költségek Mérési felelős: projektvezető Mérési adatszolgáltató: projektvezető – tervadatok; beszerzés és a projektben a munkatársak – a valós költségek ill. a ráfordítási adatok tekintetében Metrika felhasználója (pl.): vállalati operatív vagy gazdasági vezető, kontroller

Költség tartása -

-

Kategória: projekt metrika Értelmezése: bemutatja a projekt során a kezdeti időponttól számítva a megvalósult költségek arányát az (aktuálisan érvényes) tervezethez képest. A költség tartása annál jobb, minél közelebb van ez az érték az 1-hez. (költség tartása > 1, akkor az az aktuális projektbüdzsé túllépése) Kiszámítása: valós költségek / (aktuálisan érvényes) tervezett költségek


46

Jegyzet -


Mérési felelős: projektvezető Mérési adatszolgáltató: projektvezető – tervadatok; beszerzés és a projektben a munkatársak – a valós költségek ill. a ráfordítási adatok tekintetében Metrika felhasználója (pl.): vállalati operatív vagy gazdasági vezető, kontroller

Határidő stabilitása -

-

Kategória: projekt metrika Értelmezése: bemutatja a projekt során a kezdeti időponttól számítva az eltelt időtartam arányát az (első) tervezethez képest. A határidő stabilitása (illetve a tervezés megbízhatósága is egyben) annál jobb, minél közelebb van ez az érték az 1-hez. Kiszámítása: valós projektidő [nap]/ (első) tervezett projektidő [nap] Mérési felelős: minőségbiztosító, MIR vezető Mérési adatszolgáltató: projektvezető Metrika felhasználója (pl.): vállalati operatív vagy gazdasági vezető, projektvezető

Határidő tartása -

-

Kategória: projekt metrika Értelmezése: bemutatja a projekt során a kezdeti időponttól számítva az eltelt időtartam arányát az (aktuálisan érvényes) tervezethez képest. A határidő tartása annál jobb, minél közelebb van ez az érték az 1-hez. (határidő tartása > 1, akkor az az aktuális projekt időkeret túllépése) Kiszámítása: valós projektidő [nap]/ (aktuálisan érvényes) tervezett projektidő [nap] Mérési felelős: minőségbiztosító, MIR vezető Mérési adatszolgáltató: projektvezető Metrika felhasználója (pl.): vállalati operatív vagy gazdasági vezető, projektvezető

Produktivitás -

-

Kategória: projekt metrika Értelmezése: bemutatja (pl. fejlesztési vagy integrációs projektek esetén) az egységnyi ráfordítással megvalósuló objektum méretet (pl. FP becsléssel), hatékonysági mutató Kiszámítása: termék mérete [FP] / ráfordítás [h] Mérési felelős: minőségbiztosító Mérési adatszolgáltató: projektvezető és minőségbiztosító, FP szakértők – FP becslések; a projektben a munkatársak – a ráfordítási adatok tekintetében Metrika felhasználója (pl.): projektvezető, minőségbiztosító, ágazati operatív vezető, …

Módszerek alkalmazása – pl. erőforrás becslésnél -

-

Kategória: projekt metrika Értelmezése: bemutatja (pl. ajánlatadási fázisban, az erőforrások becslésekor – módszerek pl.: FP*, szakértői becslés, kettő együtt, más, semmi, …) az egyes módszerek alkalmazásának megoszlását (arányát) a projektekben; módszertanok alkalmazásának gyakoriságát mutatja Ábrázolása: pl. kördiagramon az egyes módszereket felhasználó projektek számaival Mérési felelős: minőségbiztosító(k), MIR vezető Mérési adatszolgáltató: projektvezetők


47

Jegyzet -

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Metrika felhasználója (pl.): ágazati operatív vezető, MIR vezető, …

6.2.3 Kódmetrikák – példák -

Hibamegtalálási mutató Hibaarány mutató Hibastatisztika Szemle intenzitás Tesztelési intenzitás Tesztelési hatékonyság Követelmény stabilitás …

Hibamegtalálási mutató -

Kategória: kódmetrika, minőségjellemző Értelmezése: bemutatja a dokumentumszemlén a szemlézett forráskódban vagy dokumentumban a megtalált hibák számát. Kiszámítása: a dokumentumszemlén megtalált hibák száma [db]/ szemlézett objektum mérete [FP vagy BLOC* vagy doku-oldalszám] Mérési felelős: projektvezető vagy minőségbiztosító Mérési adatszolgáltató: dokumentumszemle vezetője Metrika felhasználója (pl.): projektvezető, minőségbiztosító, … * BLOC = Bruttó Line of Codes

Hibaarány mutató -

Kategória: kódmetrika, minőségjellemző Értelmezése: bemutatja a tesztek (illetve a felhasználás során) a kódban megtalált hibák számát a tesztelt objektum méretének függvényében. Kiszámítása: a teszteken megtalált hibák száma [db]/ tesztelt objektum mérete [FP vagy BLOC] Mérési felelős: projektvezető vagy minőségbiztosító Mérési adatszolgáltató: tesztelők, tesztelési vezető Metrika felhasználója (pl.): projektvezető, minőségbiztosító, …

Hibastatisztika -

-

Kategória: kódmetrika, minőségjellemző Értelmezése: bemutatja a termék (dokumentumok, kódok) ellenőrzések során megtalált különböző fajtájú hibák számát illetve arányát. Különböző hibatípusok lehetnek (különböző szempontok szerint) pl.: o új hiba – kijavított hiba – nyitott hiba, o helyesírási hiba – szintaktikai hiba – konvenciós hiba – algoritmikus hiba o lényegtelen hiba – kis jelentőségű hiba – kritikus (nagy prioritású) hiba Ábrázolása: diagramon a különböző fajta / típusú megtalált hibák száma [db] vagy aránya [%] Mérési felelős: projektvezető vagy minőségbiztosító Mérési adatszolgáltató: dokumentumszemle vezetője, tesztelési vezető Metrika felhasználója (pl.): projektvezető, minőségbiztosító, …


48

Jegyzet


Szemle intenzitás -

-

Kategória: kódmetrika, minőségjellemző Értelmezése: bemutatja a dokumentumszemlére ráfordított munkaidőt / ráfordítást (a javítások megismételt szemléi nélkül) a szemlézett forráskód vagy dokumentum méretének függvényében. Kiszámítása: a dokumentumszemlére fordított munkaidő [Mh]/ szemlézett objektum mérete [FP vagy BLOC vagy doku-oldalszám] Mérési felelős: projektvezető vagy minőségbiztosító Mérési adatszolgáltató: dokumentumszemle vezetője Metrika felhasználója (pl.): projektvezető, minőségbiztosító, …

Tesztelési intenzitás -

Kategória: kódmetrika, minőségjellemző Értelmezése: bemutatja a tesztelésre ráfordított munkaidőt / ráfordítást (a javítások megismételt tesztjei nélkül) a tesztelt objektum méretének függvényében. Kiszámítása: a tesztelésre fordított munkaidő [Mh]/ tesztelt objektum mérete [FP vagy BLOC] Mérési felelős: projektvezető vagy minőségbiztosító Mérési adatszolgáltató: tesztelők, tesztelési vezető Metrika felhasználója (pl.): projektvezető, minőségbiztosító, …

Tesztelési hatékonyság -

-

Kategória: kódmetrika, minőségjellemző Értelmezése: bemutatja a tesztek során a kódban megtalált hibák számát a tesztelésre ráfordított munkaidő (a javítások megismételt tesztjei nélkül) függvényében. Kiszámítása: a teszteken megtalált hibák száma [db] / a tesztelésre fordított munkaidő [Mh] Mérési felelős: projektvezető vagy minőségbiztosító Mérési adatszolgáltató: tesztelők, tesztelési vezető Metrika felhasználója (pl.): projektvezető, minőségbiztosító, …

Követelmény stabilitás -

-

Kategória: kódmetrika, minőségjellemző Értelmezése: bemutatja az ügyféllel való követelmény-megállapodás lezárta után a követelményekben való változási igények (CR – Change Request-ek) mennyiségét. (Lehet mérni pl. darabszámban, értékben, objektum-méretben.) Ábrázolása: pl. oszlopdiagramon havonta a CR-ek mennyisége (pl. darabszámban, vagy költség-értékben, vagy FP-ben) Mérési felelős: projektvezető vagy minőségbiztosító Mérési adatszolgáltató: projektvezető Metrika felhasználója (pl.): projektvezető

További kódmetrikák még, mint további lehetőségek … -

Szemlézett dokumentumok aránya Végrehajtott szemlék aránya Különböző szemlézési módszerek alkalmazásának aránya


49

Jegyzet -

INFORMÁCIÓS RENDSZEREK / Szoftver minőségbiztosítás V.03. (2015.06.01) Tervezett tesztelési arány (tesztelésre kitűzött / összes objektum aránya) Végrehajtott tesztek aránya Kijavított hibák aránya Megtalált hibák aránya életciklus fázisonként Szemléken – teszteléskor megtalált hibák aránya (ugyanazon a kódon) Hibajavítás utáni újabb ellenőrzések ráfordításai, aránya Karbantartási időszakokra nyitott – lezárt hibák aránya / bejelentett hibákhoz képest (prioritásonként is figyelhető) …


Milyen feltételek szükségesek a metrikák sikeres bevezetéséhez egy vállalatnál? Mutassa be egy metrika-használat folyamatának szereplőit és feladatait! Mutassa meg, hogy milyen szempontokra kell a metrikák megfelelő kiválasztásánál odafigyelni, hogy alkalmazásuk sikeres lehessen! Mutasson példákat (szoftverfejlesztési) projekt-metrikákra, és mutassa meg a kiválasztott példák alkalmazási módját is! Mutasson példákat kódmetrikákra, és mutassa meg a kiválasztott példák alkalmazási módját is!


50

INFORMÁCIÓS RENDSZEREK

Recommend Documents