Szoftverminőség monitorozás forráskód alapján

Slides:



Advertisements
Hasonló előadás
„Esélyteremtés és értékalakulás” Konferencia Megyeháza Kaposvár, 2009
Advertisements

A MINŐSÉG MEGTERVEZÉSE
PTE PMMK ÉPÍTÉSKIVITELEZÉSI ÉS MÉRNÖKI MENEDZSMENT TANSZÉK MINŐSÉGMENEDZSMENT 4. ELŐADÁS.
Valós idejű tesztlefedettség- monitorozás JEE környezetben Dr. Ferenc Rudolf, Szegedi Tudományegyetem Bakota Tibor, FrontEndART Szoftver Kft.
Szoftverminőség, 2010 Farkas Péter. SG - Sajátos célok  SG 1. Termék / komponens megoldás kiválasztása  SP 1.1. Alternatívák és kiválasztási kritériumok.
Egy kisvállakozás dinamikus weboldalának fejlesztése: tervezés, problémák, megoldások Szilágyi Gábor.
A szoftver minősége A szoftverfejlesztési folyamat azt igényli, hogy a fejlesztők és felhasználók ugyanazokat a minőségi jellemzőket használják a szoftver.
Erőállóképesség mérése Találjanak teszteket az irodalomban
MINŐSÉGMENEDZSMENT 5. előadás PTE PMMK MÉRNÖKI MENEDZSMENT TANSZÉK 2011.
Humánkineziológia szak
Tanuló (projekt)szervezet a Magyar Nemzeti Bankban
Rendszerfejlesztés II gyak
INFORMÁCIÓRENDSZEREK FEJLESZTÉSÉNEK IRÁNYÍTÁSA.. Alkalmazás - projekt Alkalmazás - a vállalat tökéletesítésére irányuló új munkamódszer projekt - az új.
A webes tesztelés jövője
Programozás alapjai A programozás azt a folyamatot jelenti, melynek során a feladatot a számítógép számára érthető formában írjuk le. C++, Delphi, Java,
A tételek eljuttatása az iskolákba
Forráskód metrikák szerepe a szoftver minőségbiztosításban
Szoftverfejlesztés és szolgáltatás kiszervezés Folyamatjavítási mérföldkövek a világon és Magyaroszágon Bevezető gondolatok Dr. Biró Miklós.
Bevezetés a gépi tanulásba február 16.. Mesterséges Intelligencia „A számítógépes tudományok egy ága, amely az intelligens viselkedés automatizálásával.
MI 2003/ Alakfelismerés - még egy megközelítés: még kevesebbet tudunk. Csak a mintánk adott, de címkék nélkül. Csoportosítás (klaszterezés, clustering).
Rendszerfejlesztés gyakorlat - © Nagy Csaba
Rendszerfejlesztés gyakorlat - © Fülöp Lajos Minőségmérés.
Informatika a felsőoktatásban augusztus Debrecen A Magyarországon alkalmazott könyvtári szoftverek értékelése a többtényezős döntéshozatal.
1 Apertus Közalapítvány Nemzeti Fejlesztési Program
Szoftver bonyolultsági mértékek alkalmazási területei Király Roland 2011.
RFID labor az Intézetünkben
Zalayné Kovács Éva: Minőség és könyvtár
A CRM bevezetési projektek sajátosságai
Funkciópont elemzés: elmélet és gyakorlat
Szoftver mértékek Szoftver mérték: –A fejlesztési folyamat mérése –Végtermék mérése (termék mérték) Termék mérték: –Külső mértékek: Megbízhatósági mértékek.
Megvalósíthatóság és költségelemzés Készítette: Horváth László Kádár Zsolt.
Brachmann Ferenc PTE-TTK/KTK A kurzus szerepe és célja A minőségbiztosítás általános alapelveire történő folyamatos hivatkozással áttekinti a szoftverminőség.
1 Szoftverfejlesztési folyamat a gyakorlatban Tamás Árpád – QualSoft Kft
Brachmann Ferenc PTE-TTK/KTK 2009
Szoftvertechnológia Ember-gép rendszerek. Mit értünk rendszer alatt? Kapcsolódó komponensek halmaza – egy közös cél érdekében működnek együtt A rendszer.
NATO minőségbiztosítási követelmények a tervezésre, fejlesztésre és gyártásra Termék Műszaki kiszolgálás, karbantartás, javítás Csomagolás,
Objektum Vezérelt Szoftverek Analízise Ferenc Rudolf és Beszédes Árpád Szegedi Tudományegyetem FrontEndART.
Adatfolyam modellezés az SSADM-ben
Matematikai alapok és valószínűségszámítás
szakmérnök hallgatók számára
Budapesti Műszaki és Gazdaságtudományi Egyetem Biokémiai és Élelmiszertechnológiai Tanszék Mintavétel Élelmiszeranalitika előadás december 3.
S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN
R EQUIREMENTS D EVELOPMENT Készítette: Devecseri Viktor.
Programtesztelés. Hibák keletkezésének okai nem egyértelmű vagy hiányos kommunikáció fejlesztés közben maga a szoftver bonyolultsága programozói (kódolási)
3.2. A program készítés folyamata Adatelemzés, adatszerkezetek felépítése Típus, változó, konstans fogalma, szerepe, deklarációja.
Topológia felderítés hibrid hálózatokban
UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Copyright 2009 SZTE Szoftverfejlesztés Tanszék1.
Rendszertervezés Alapfogalmak; Az informatikai rendszer
IV. Terjeszkedés 2..
2006. Peer-to-Peer (P2P) hálózatok Távközlési és Médiainformatikai Tanszék.
dr. Banai Miklós ügyvezető MultiRáció Kft.
Geotechnikai feladatok véges elemes
1 Vállalati együttműködések általános tapasztalatai Gyimóthy Tibor Szoftverfejlesztési Tanszék.
Refaktoring projekt az InfoPólus klaszterben GOP Nagy Csaba - Refactoring 2011 Kft.
UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Okostelefon köztesréteg Dr. Bilicki Vilmos Szegedi Tudományegyetem.
Okostelefon köztesréteg (1.3-5)
Szoftver születik Eötvös Konferencia Köllő Hanna.
CMMI 1.3 – Verifikáció Készítette: Kis Gergely. Bevezetés A specifikációt, követelményt vetjük össze a kész/készülő termékkel Itt nem vizsgáljuk, hogy.
Gyurkó György. Az OO programozás és tervezés története 1960-as évek: SIMULA (véletlen folyamatokat szimuláló programok írása) az OO nyelvek őse 1970-es.
TEROTECHNOLÓGIA Az állóeszközök újratermelési folyamata.
A Bologna-folyamat a munkáltatók szempontjából Gerner Péter
Incremental change © 2013 Betyár Gábor Rendszerfejlesztés II. 3. Óra.
UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED D epartment of Software Engineering Gépi tanulás a fejlesztés, karbantartás költségének becslésére.
Reverse Engineering Rendszerfejlesztés II. 2. óra.
Continuous delivery: cél a működő szoftver
Biztonságos szoftverfejlesztés kipipálva!? TickIT követelmények
UNIVERSITAS SCIENTIARUM SZEGEDIENSIS SZEGEDI TUDOMÁNYEGYETEM S zoftverfejlesztés Tanszék Programrendszerek tanúsítása – szoftverminőség mérése Dr. Gyimóthy.
Szoftvermenedzsment A szoftver fogalma programmodulok rendszerdokumentáció konfigurációs adatok, és ezeket tároló fájlok felhasználói dokumentáció a szoftver.
"Ha nem tudod, hogy hová mész,
MINŐSÉG BS 4778 "Egy termék vagy szolgáltatás jellemzőinek és sajátosságainak összessége, amelyek együttesen egy adott szükséglet kielégítésére képesek".
Előadás másolata:

Szoftverminőség monitorozás forráskód alapján Dr. Beszédes Árpád Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum “You can’t manage what you can’t control, and you can’t control what you don’t measure.” (Tom DeMarco) 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum Szoftvermérés DeMarco: Csak mérés alapján végezhetjük a minőségmenedzsmentet Igen, mérjünk, de mit? Minőségkezelés eredeti alapfeltevése: Fejlesztési folyamat minősége meghatározza a termék minőségét Erre építenek a különböző minőségirányítási rendszerek: ISO, CMMI 2006. május 3. Szoftvertechnológiai Fórum

Szoftvermérés (folyt.) Azonban, két alapvető módon befolyásolhatjuk a vezetői döntéshozatalt: Vezérlési metrikákkal. Folyamattal kapcsolatosak, pl. egy hiba javításához szükséges átlagos idő (folyamat és projekt metrikák) Prediktor metrikákkal. Termékkel kapcsolatosak, pl. LOC, ciklomatikus komplexitás, osztály metódusainak száma, kódolási szabályok megsértésének mértéke (termék metrikák) 2006. május 3. Szoftvertechnológiai Fórum

Termékmetrikák jelentősége Minőségirányítási rendszer bevezetésekor már létezik a szoftver egy verziója Fejlesztés további része Karbantartás és Továbbfejlesztés lesz (termékmenedzsment) A teljes életciklus 80%-át, a költségek 65%-át teszi ki Kezdeti fejlesztési költségek többszörösét teszik ki, és idővel csak növekednek! Szoftverváltozás elkerülhetetlen Pl. új követelmények, új üzleti környezet, hibajavítás, teljesítmény vagy megbízhatóság javítása Változás hatékony kezelése a kulcsprobléma 2006. május 3. Szoftvertechnológiai Fórum

Termékmetrikák (folyt.) Stratégiák változás kezelésére: Szoftverkarbantartás Architekturális átalakítás Szoftver újratervezése Nagyon sokszor az egyetlen hiteles leírása a rendszernek a forráskód maga Meg kell határozni annak kiindulási minőségét Hogy a költségeket becsülni tudjuk, és Képesek legyünk javítani a folyamatunkon Folyamat és termék mérése együtt kell hogy történjen, egymást kiegészítve 2006. május 3. Szoftvertechnológiai Fórum

Minőségmérés forráskód alapján Ember: Leletkészítés → Diagnózis → Kezelés/Megelőzés → Ellenőrzés → … Szoftver: Mérés → Megértés/Minőségjellemzők → Refactoring/Újratervezés/Folyamatjavítás → Ellenőrzés (újabb mérés) → … 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum Szoftver evolúciója 2006. május 3. Szoftvertechnológiai Fórum

Forráskód-alapú minőségbiztosítási módszertan rendszer-architektúrája Folyamatos mérés és monitorozás szükséges, melyhez eszközkészlet is kell! 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum Columbus technológia FrontEndART Szoftver Kft. Nagy C++ rendszerek analizálására alkalmas Ezen belül minőség mérésére, monitorozására Eddigi tapasztalatok (1-30 MLOC) Nokia platform kódja Graphisoft ArchiCAD Nuance Scansoft Recognita Mozilla OpenOffice/MagyarOffice (Multiráció) 2006. május 3. Szoftvertechnológiai Fórum

Visszatervezés és újratervezés Nagy mennyiségű örökölt kód létezik Kritikus fejlesztők elérhetetlenek Új munkatársak Programmegértés támogatása Ún. ősrendszerek (legacy system) esetében nagyon fontos Visszatervezés (Reverse Engineering) Forráskódból modell előállítása Újratervezés (Reengineering) Visszatervezett modell továbbfejlesztése, új rendszer megvalósítása 2006. május 3. Szoftvertechnológiai Fórum

utólagos dokumentálás függőségek és tervezési minták felismerése termékmetrikák Program megértés Architektúra visszanyerés Mérés C++ séma monitorozás Adatcsere Visszatervezett modell hibára való hajlamosság vizsgálata Forrás- kód Vizsgálat tényfeltárási eljárás stb. Vizualizálás Transzformált modell Módosított forráskód Újratervezés javítás, refactoring 2006. május 3. Szoftvertechnológiai Fórum

Minőségi jellemzők mérése Jellemzőket lehetetlen közvetlenül mérni Magasabb szintű absztrakciók, sok mindentől függnek Hierarchikus összetétel (jellemzők származtatása) Sokszor szervezet- vagy termékfüggő Több metrika együttes vizsgálata Metrikák változása az idő függvényében Statisztikai technikák alkalmazása Metrikák (belső jellemző) és (külső) jellemzők közötti kapcsolatokra fel kell állítani egy modellt Sok projekt esettanulmányának vizsgálata 2006. május 3. Szoftvertechnológiai Fórum

Mérési modell, példa Eljárás paramétereinek száma Karbantarthatóság Ciklomatikus komplexitás Megbízhatóság Program mérete kódsorokban Hordozhatóság Hibaüzenetek száma Használhatóság Felhasználói kézikönyv hossza 2006. május 3. Szoftvertechnológiai Fórum

Termékmetrikák forráskód alapján Dinamikus Szorosabb kapcsolat egyes minőségi jellemzőkkel (pl. teljesítmény, hibák száma) Statikus Közvetett kapcsolat Számtalan konkrét metrikát ajánlottak már Kritikus kérdés: hogyan következtetünk a minőségi jellemzőkre a sok számból? Mérések (OO rendszerek esetében) Eljárásszintű Osztályszintű Rendszerszintű 2006. május 3. Szoftvertechnológiai Fórum

Példák egyszerű metrikákra Forráskód sorok száma: LOC (többféle) McCabe ciklomatikus komplexitás eljárásokra Kohézió: LCOM (Lack of COhesion in Methods) Minél nagyobb, a metódusok annál kevésbé koherensek Csatolás (coupling): CBO (Coupling Between Objects). Ha az osztály egy másik osztály attribútumát vagy metódusát használja, akkor növekszik Minél kisebb kell hogy legyen Rendszerszintű metrikák: U (reUse ratio) = ősosztályok / összes osztály S (Specialization ratio) = származtatott osztályok / ősosztályok 2006. május 3. Szoftvertechnológiai Fórum

További fontos metrikák Forráskód auditálás Verifikációnál is alkalmazzák Automatikus, eszközök segítségével, pl. LINT Kódolási stílus, külalak Potenciálisan veszélyes szerkezetek felismerése Hibák, biztonsági rések statikus felfedezése Nem helyettesíti a tesztelést, de pl. hibák 60%-a felderíthető így Számszerűsíthető! Szabálysértések száma osztályonként 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum Rossz előjelek Speciálisan auditálható tulajdonságok „Bad smell”-ek Nem feltétlenül jelentenek problémát De jó alapjaik a refactoring-nak Egyszerűek is vannak, pl. túl nagy osztály Az egyik legfontosabb: Kód-duplikáció detektálása „Klónok” felfedezése 2006. május 3. Szoftvertechnológiai Fórum

Metrikák és hibák kapcsolata Nincs hiba 50% Nincs hiba 36% Közepes hibaszám 38% Nincs hiba 18% Közepes hibaszám 28% Magas hibaszám 20% Közepes hibaszám 30% Magas hibaszám 35% Magas hibaszám 44% Magas kohézió Közepes kohézió Alacsony kohézió 2006. május 3. Szoftvertechnológiai Fórum

Metrikák és hibák kapcsolata (folyt.) Kísérlet Mozilla rendszerrel (3,000 osztály), és a Bugzilla hiba-követő rendszerével (250,000 hiba) Mozilla különböző verziói javultak (1.0 [2002] és 1.6 [2005] között) Hibák száma szerint is Metrikák szerint is Korreláció vizsgálata a hibák száma és egyes metrikák között Gépi tanulási modellt állítottunk elő, mellyel előre jelezhetők a problémás osztályok 2006. május 3. Szoftvertechnológiai Fórum

Metrikák és hibák kapcsolata (folyt.) 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum Monitorozás A megalkotott modelleket egy monitorozó rendszerben implementáltuk Rendszeresen méri a szoftvert Különféle vizualizációk és lekérések, pl. Hisztogram Metrikus értékek időbeni változásai Mesterséges intelligencia Speciális hibamodell: kódolási konvenciók megsértésének hatása a hibákra További modellek építhetők: karbantarthatóság, biztonság, stb. 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum 2006. május 3. Szoftvertechnológiai Fórum

Szoftvertechnológiai Fórum Összegzés Csak mérés alapján végezhetjük a minőségmenedzsmentet Termékmetrikák: közvetetten irányíthatják a minőségbiztosítási folyamatokat Karbantartás és továbbfejlesztés fázisában fontosak, amikor meglévő rendszerről kell mondani valamit Folyamatméréssel együtt kell(ene) alkalmazni Forráskód-alapú minőségbiztosítási módszertan 4 rétegű architektúra Eszközkészlet és monitorozás szükséges Columbus technológia 2006. május 3. Szoftvertechnológiai Fórum