Programrendszerek tanúsítása szoftverminőség mérése

UNIVERSITAS SCIENTIARUM SZEGEDIENSIS SZEGEDI TUDOMÁNYEGYETEM Szoftverfejlesztés Tanszék

Programrendszerek tanúsítása – szoftverminőség mérése Dr. Gyimóthy Tibor Dr. Ferenc Rudolf


Szoftverminőség biztosítás Fő cél: az üzemelő IT rendszerekben csökkenteni a hibák számát Az éles működés alatt jelentkező hibák nagyon veszélyesek

2008. 05. 21.

■ Rontják a cég presztízsét ■ Nagyon költséges a javításuk ■ Egy ilyen hiba sokmillió forintos kárt okozhat ■ Az IT rendszerek kritikus mértékű lassulását is hibának tekintjük NESSI-HU: Programrendszerek tanúsítása - szoftverminőség mérése

2


Szoftverminőség biztosítás Szoftverminőség javítás ■ Folyamatos romlás megállítása ■ Kevesebb hiba lesz a rendszerekben

Tesztelési hatékonyság növelés ■ Üzembe helyezés előtt kell minél több hibát megtalálni

IT üzemeltetés hatékonyság növelés

2008. 05. 21.

■ Követhetőbb és optimálisabb üzemeltetési folyamatok NESSI-HU: Programrendszerek tanúsítása - szoftverminőség mérése

3


Szoftverminőség romlása Törvényszerű: A szoftver változtatások növelik a hibák számát

2008. 05. 21.

NESSI-HU: Programrendszerek tanúsítása - szoftverminőség mérése

4


Mi a szoftver minőség? ISO 9126 szerint: • Funkcionalitás • Megbízhatóság • Használhatóság

„Külső metrikák” = a (szoftvert tartalmazó) rendszer és használatának jellemzői ! Nehéz közvetlenül mérni őket, túl absztraktak !

Példa alábontásra:

• Hatékonyság

•

Elemezhetőség

• Karbantarthatóság

•

Módosíthatóság •

• Hordozhatóság •

Tesztelhetőség

2008.05.21.

2008. 05. 21.

Stabilitás

5


5


Mi a szoftver minőség? (folyt.)

2008. 05. 21.


6


Mi a szoftver minőség? (folyt.)

2008. 05. 21.


7


Szoftverminőség javítás Columbus módszertan és eszközök Folyamatos mérés és auditálás ■ ■ ■ ■

Termékmetrikák Kódolási szabálysértések Kód duplikáció (copy & paste) Tervezési hiányosságok (bad smells)

Folyamatos monitorozás ■ Baseline-ok ■ Automatikus riasztás ■ Automatikusan generált riportok

Támogatott platformok

2008. 05. 21.

■ Java, C#, C/C++, SQL, Forrás SQL


8


Tesztelési hatékonyság növelés Fő cél: a program változtatások és hatásaik minél teljesebb körű tesztelése

2008. 05. 21.

■ Tesztkeretek, tesztesetek kezelése ■ Tesztlefedettség mérése ■ Tesztesetek szelekciója, prioritizálása ■ Hatásanalízis ■ Szükség van folyamat leírásokra és szoftver architektúrára


9


IT üzemeltetés hatékonyság növelés Rendszerfejlesztési Életciklus Módszertan (RÉM)

2008. 05. 21.

Forráskód analizálók

Folyamatok (EPC, BPEL) Monitorozás

Teszt menedzser

Üzemeltetés Performancia Architektúra rekonstrukció

■ Csak azt a folyamatot tudjuk irányítani, amelyről megfelelő mérési adatokkal (metrikák) rendelkezünk NESSI-HU: Programrendszerek tanúsítása - szoftverminőség mérése

10


SOA minőségbiztosítás Szolgáltatás orientált architektúrák (SOA) esetében új kihívásokkal is szembe kell néznie a minőségbiztosításnak

2008. 05. 21.

■ Hagyományos (monolit vagy kliens/szerver) rendszer átültetése SOA világba ■ Hibakeresés és költségbecslés SOA rendszerben ■ SOA rendszer tesztelése, tesztelési hatékonyság mérése ■ Mérés, auditálás és monitorozás NESSI-HU: Programrendszerek tanúsítása - szoftverminőség mérése

11


Régi rendszer átültetése SOA-ba A Gartner előrejelzése szerint 2008-ban ■ a SOA-alapú lesz a szoftverfejlesztés domináns hányada és ■ az új SOA-alapú rendszerek legalább 65%-a régi rendszerek átültetéséből fog előállni – adaptálás (wrapping) útján

Tipikus esetek (monolit, kliens/szerver) ■ Közigazgatásban használt régi rendszerek ■ Levéltári szoftverek


Régi rendszer átültetése (folyt.) Funkcionalitás azonosítása és kiemelése Web szolgáltatásba (WS) ■ Architektúra feltárás ■ Komponens beazonosítás ■ Programmegértés

Az új WS-t kívülről hívják

2008. 05. 21.

■ Minden előfeltétel adott? ■ Hatásanalízis ■ Párhuzamosan több példánya is futhat ■ GUI használat? NESSI-HU: Programrendszerek tanúsítása - szoftverminőség mérése

13


Hibakeresés és költségbecslés Egy hiba okának a felderítése nehezebb

2008. 05. 21.

■ Nincs klasszikus debugger SOA-ra ■ Elosztott rendszer, párhuzamos futtatás ■ Forráskód néha nem áll rendelkezésre ■ A hiba akár a WSDL dokumentum tartalmában és/vagy formátumában is lehet


14


Hibakeresés (folyt.) SOA függőségi gráf felépítése szükséges ■ A SOA dinamikus természete miatt bizonyos esetekben nem lehetséges – Ilyenkor ez üzemeltetési kockázatot is jelent

■ WSDL és BPEL elemzése is szükséges

Hatásanalízis ■ Hibakeresés – mely WS-ektől függ a hiba megjelenési helye?

■ Költségbecslés – mely WS-ek függnek a módosítandó WS-től?


Tesztelés, tesztelési hatékonyság A tesztelés jár a szoftver változtatásakor a legnagyobb költséggel ■ Rossz minőségű szoftver tesztelése drágább

SOA: Teszteset generálás BPEL alapján Tesztlefedettség mérés Tesztesetek szelekciója ■ Változások és hatásaik (hatásanalízis)

Tesztesetek generálása Performancia teszt hangsúlyosabb

2008. 05. 21.


16


Tesztelés (folyt.) Nehézségek

2008. 05. 21.

■ Osztott rendszer lévén nehéz követni a teszt menetét (futásnaplót készíteni) ■ Külső WS-ek esetében sokszor nem áll rendelkezésre a forráskód ■ A WS-ek közül futás közben akár választani is lehet – Nehéz megismételhető teszteket készíteni


17


Mérés, auditálás és monitorozás Hagyományos forráskód analízis kiegészül WSDL és BPEL analízissel ■ Teljes SOA rendszer részletes szerkezeti és függőségi gráfja szükséges

Minőségi jellemzők (metrikák) mérése ■ Csatolási mérték (coupling) hangsúlyosabb

Szabálysértések auditálása ■ pl. kommunikál-e két WS a BPEL-ben leírt üzleti folyamattól függetlenül?

Metrikák és szabálysértések folyamatos monitorozása szükséges Csak azt a folyamatot tudjuk irányítani, amelyről megfelelő mérési adatokkal rendelkezünk

2008. 05. 21.


18


Kapcsolat

2008. 05. 21.

www.sed.hu

www.frontendart.hu


19

Programrendszerek tanúsítása szoftverminőség mérése

Recommend Documents