A SZOFTVERTECHNOLÓGIA ALAPJAI

Az előadások a következő témára: "A SZOFTVERTECHNOLÓGIA ALAPJAI"— Előadás másolata:

1 A SZOFTVERTECHNOLÓGIA ALAPJAI
13. előadás: Szoftvertesztelés, A szoftver becslése A SZOFTVERTECHNOLÓGIA ALAPJAI Szoftvertesztelés A szoftver becslése előadás PPKE-ITK PPKE-ITK A Szoftvertechnológia alapja-2011

2 13. előadás: Szoftvertesztelés, A szoftver becslése
Tartalom 1. A hiányosságok tesztelése 1.1 A fekete doboz tesztelés 1.2 Ekvivalencia-osztályozás 1.3 Struktúrateszt 1.4 Útvonal tesztelés 2. Integrációs tesztelés 2.1 Az integrációs tesztelés stratégiái 2.2 Interfésztesztelés 2.3 Terhelési (stressz) tesztek 3. Objektumorientált tesztelés PPKE-ITK Szoftvertechnológia-2011 PPKE-ITK A Szoftvertechnológia alapja-2011

3 13. előadás: Szoftvertesztelés, A szoftver becslése
A szoftvertesztelés A tesztelési folyamat alapelemei: Komponens tesztelés: Az egyedi programkomponensek tesztelése. Általában a komponens fejlesztőjének feladata (a kritikus rendszerek kivételével). Integrációs tesztelés Komponensek, majd modulok csoportjának tesztelése, amelyek egy rendszert vagy alrendszert alkotnak. Független tesztelő csoport feladata. A tesztek a rendszer specifikációja alapján készülnek. PPKE-ITK Szoftvertechnológia-2011 PPKE-ITK A Szoftvertechnológia alapja-2011

4 Funkció- és objektumorientált rendszerek tesztelése
A funkcióorientált rendszereknél: A rendszer alapvető program-egységei (függvények – modulok) jól elkülöníthetők, Ezek külön tesztelhetők. Az objektumorientált rendszerek esetén: Az ilyen megkülönböztetés nem lehetséges, az objektumok lehetnek egyszerű ( pl. lista), vagy komplex entitások (pl. egy alrendszer objektumai), Olykor nincs egyértelmű hierarchia az objektumok között, ezért az integrációs tesztek (fentről lefelé, vagy lentről felfelé) nem alkalmazhatók. PPKE-ITK Szoftvertechnológia-2011

5 1. A hiányosságok tesztelése
A cél: feltárni a rejtett hibákat a rendszerben. A sikeres hiányosság teszt a rendszer helytelen működését eredményezi (ellentétben a validációs teszttel, amely a rendszer helyes működését ellenőrzi). A hibák jelenlétét és nem azok hiányát mutatja ki. Tesztadatok és tesztesetek: A tesztesetek a teszthez szükséges inputok és a várt outputok specifikációi, A tesztadatok a rendszer tesztelésére kidolgozott input adatok. PPKE-ITK Szoftvertechnológia-2011

6 A tesztelés súlyponti kérdései
Csak teljes körű tesztelés bizonyíthatná, hogy a rendszer hibamentes, de a teljes tesztelés lehetetlen. A funkcionális teszteknek a rendszer a képességeit kell vizsgálniuk, nem a komponenseket. A fejlesztés során a rendszer régi (korábban már letesztelt) képességeinek tesztelése sokszor fontosabb, mint az újonnan hozzáadott képességeké. A tipikus helyzetek tesztelése fontosabb, mint a határesetek tesztelése. PPKE-ITK Szoftvertechnológia-2011

7 A hiányosságok tesztelésének folyamata
Teszt- esetek Teszt- adatok Teszt- eredmények Teszt- jelentések Teszt- esetek tervezése Teszt- adatok készítése Program futtatása tesztadatokkal Eredmények összevetése a tesztesetekkel PPKE-ITK Szoftvertechnológia-2011

8 1.1 A fekete doboz tesztelés
Funkcionális tesztelésnek is nevezik. A programot fekete doboznak tekintjük, a tesztesetek a programspecifikáció alapján készülnek. Nem foglalkozik a program implementációjával. A tesztek tervezése a szoftverfolyamat korai szakaszában megkezdődhet. (Egyes Agilis módszereknél előbb, mint a program tervezése!) Az előreláthatóan hibát okozó tesztesetek tervezéséhez szakterületi ismeretekre van szükség. PPKE-ITK Szoftvertechnológia-2011

9 A fekete doboz tesztelés
Input tesztadatok Rendellenes viselkedést okozó input adatok Ie Rendszer Output teszt- eredmények A hiányosságokat felfedő outputok Oe PPKE-ITK Szoftvertechnológia-2011

10 1.2 Ekvivalencia-osztályozás
A rendszer input és output adatait valamilyen közös jellegzetesség szerint csoportosítják, amelyekre a rendszer hasonló módon reagál: Például: ha az input 5 jegyű valós szám és között, akkor az ekvivalencia-osztályok: < , – , < A fejlesztők legtöbbször az inputok tipikus értékeit veszik figyelembe. A teszteseteket a határértékek közelében és az osztályok közepéből célszerű kiválasztani: 00000, 09999, 10000, 99999, 10001 PPKE-ITK Szoftvertechnológia-2011

11 1.3 Struktúrateszt Fehér doboz vagy üvegdoboz tesztelésnek is nevezik, mert a tesztek a program struktúrájának, implementációjának ismeretében készülnek. A struktúra és a kód ismeretében újabb ekvivalencia-osztályok definiálhatók. A tesztelő a tesztesetek készítésekor elemzi a kódot, hogy biztosítsa minden utasítás legalább egyszeri végrehajtását (az összes lehetséges út-kombináció tesztelésére nincs reális lehetőség). PPKE-ITK Szoftvertechnológia-2011

12 1.4 Útvonal tesztelés Az útvonal tesztelés strukturális tesztelési stratégia. Célja, hogy minden független útvonalon végighaladjon a teszt. Ekkor legalább egyszer biztosan sor került minden utasítás végrehajtására, és minden feltételes utasítás igaz és hamis eseteire. A kiindulás a program folyamat-gráfja, amely a döntéseket reprezentáló csomópontokból és a vezérlés irányát képviselő élekből áll. Előállítása viszonylag egyszerű, ha programban nincs goto. Csak kisebb programok tesztelhetők ilyen módon. PPKE-ITK Szoftvertechnológia-2011

13 Ciklomatikus komplexitás
A független utak száma a programban. Egy program ciklomatikus komplexitása: CC = Élek száma – Csomópontok száma + 2 CC megmutatja, hogy hány tesztet kell végrehajtani az összes független út végrehajtásához, vagyis minden vezérlő utasítás legalább egyszeri végrehajtásához. Nem lehet a független utak összes kombinációját végrehajtani. A dinamikus programelemzők a fordításkor kiegészítő kódot adnak a programhoz, amelyek mérik, hogy az egyes vezérlő utasítások hányszor kerültek végrehajtásra. PPKE-ITK Szoftvertechnológia-2011

14 2. Integrációs tesztelés
Teljes rendszerek vagy alrendszerek tesztelése, amelyek előzőleg már tesztelt komponensekből állnak. A komponensek együttműködéséből származó hibák feltárására szolgál. Az integrációs teszt fekete doboz tesztelés, a tesztek a specifikációból származnak. Komplex rendszerben az észlelt hibás eredményből nehéz a hiba helyére következtetni. Az inkrementális integrációs tesztelés némileg segít. PPKE-ITK Szoftvertechnológia-2011

15 Inkrementális integrációs tesztelés
A B C D Tesztsorozat 1. Tesztsorozat 2. Tesztsorozat 3. T3 T5 T4 T2 T1 PPKE-ITK Szoftvertechnológia-2011

16 2.1 Az integrációs tesztelés stratégiái
Fentről lefelé tesztelés: A rendszer magas szintű komponenseit még a tervezés és az implementáció alatt integrálják. A még el-nem készült komponenseket azonos interfésszel készült „csonkok” helyettesítik, ahol szükséges. Ezeket fokozatosan kicserélik a kész elemekkel. (Evolúciós fejlesztésnél alkalmazható) Lentről felfelé tesztelés: A hierarchia alsó szintjein lévő modulok integrálásával és tesztelésével kezdik, ahol a magasabb szinteket tesztgenerátorok helyettesítik. (Inkrementális és újrafelhasználás alapú fejlesztésnél alkalmazható) A gyakorlatban a kettő kombinációját alkalmazzák. PPKE-ITK Szoftvertechnológia-2011

17 Tesztelés fentről lefelé
A tesztelés sorrendje 1. szint 1. szint 2. szint 2. szint 2. szint 2. szintű csonkok 3. szintű csonkok PPKE-ITK Szoftvertechnológia-2011

18 Tesztelés lentről felfelé
Teszt meghajtók N. szint N. szint N. szint N. szint N. szint A tesztelés sorrendje Teszt meghajtók N-1 szint N-1 szint N-1 szint PPKE-ITK Szoftvertechnológia-2011

19 A tesztelési stratégiák összehasonlítása
Szerkezeti validáció A fentről lefelé teszteléssel felfedhetők a hibák a rendszerarchitektúrában és a magas szintű tervekben, még a folyamat korai szakaszában. Ez a lentről felfelé tesztelésnél csak később lehetséges. Rendszerdemonstráció A fentről lefelé integráció korán lehetővé teszi a korlátozott demonstrációt. Újrafelhasználható komponensek alkalmazásával a lentről felfelé megközelítéssel is lehetséges. Tesztimplementáció A programcsonkokat nehéz implementálni, a lentről felfelé tesztelés tesztmeghajtóit valamivel egyszerűbb, de mindenképpen jelentős addicionális fejlesztést igényel. Tesztmegfigyelés A tesztek eredményét mindkét módszernél nehéz megfigyelni. Mesterséges környezetre, extra kódra van szükség. Különösen a fentről lefelé megközelítésnél, ahol a magasabb szintek sokszor nem szolgáltatnak outputokat. PPKE-ITK Szoftvertechnológia-2011

20 2.2 Interfésztesztelés Interfésztesztelésre akkor van szükség, amikor egy nagyobb rendszer összeépítésekor modulokat vagy alrendszereket integrálunk. Célja az interfészek specifikációs- (félreértések), vagy implementációs hibáinak felfedése. Az interfésztesztelés az objektumorientált fejlesztésnél fontos (különösen objektumok és osztályok újrafelhasználásakor), mert az objektumokat az interfészeikkel definiáljuk. Egyedi objektum tesztelésével az interfészhibákat nem lehet felfedni. A hibák az objektumok közti interakciókban jelentkeznek, nem egy egyedi objektum sajátosságaiként. PPKE-ITK Szoftvertechnológia-2011

21 Interfész típusok Paraméter interfészek: Osztott memória interfészek:
Adatok továbbítása az egyik alrendszertől a másikhoz. Osztott memória interfészek: Az alrendszerek közös memóriablokkon keresztül cserélnek adatot egymással. Procedurális interfészek: Egy alrendszer más alrendszerek által hívható eljárásokat tartalmaz. Üzenet alapú interfészek: Egy alrendszer úgy kér szolgáltatást egy másik alrendszertől, hogy üzenetet juttat el hozzá. A szolgáltatás eredményeit egy válaszüzenetben kapja meg. PPKE-ITK Szoftvertechnológia-2011

22 Tipikus interfészhibák
Interfész hibás alkalmazása: Egy hívó komponens hibája lehet: rossz típusú vagy sorrendű paraméterek, hibás számú paraméter, stb. Interfész félreértése: A hívó komponens hibásan értelmezi az interfészt, vagy a hívott komponens válaszait. Időzítési hibák: A hívó és a hívott komponens különböző sebességgel működik (osztott memória, vagy üzenettovábbító interfész esetén), és a hívott nem aktuális információt kap. PPKE-ITK Szoftvertechnológia-2011

23 Az interfésztesztelés irányelvei
A teszteket úgy kell tervezni, hogy a paraméterek értékei a határértékek közelében legyenek. A pointer jellegű paramétereket null értékkel is tesztelni kell. Olyan tesztesetet is tervezni kell, amely a hívott komponens hibáját okozza. (A specifikációs hibák többsége a hibák értelmezéséből fakad.) Üzenettovábbító, vagy interaktív rendszereknél terhelési (stressz) tesztet kell végrehajtani. Osztott memóriájú interfészeket a komponensek aktiválódása sorrendjének megváltoztatásával is tesztelni kell (szinkronizációs hibák). PPKE-ITK Szoftvertechnológia-2011

24 2.3 Terhelési (stressz) tesztek
A rendszereket a tervezettnél nagyobb terheléssel is tesztelni kell. Fokozatosan növelni kell a terhelést, amíg a rendszer hibázik, vagy teljesítménye elfogadhatatlanná válik. Feladatai: Szélsőséges körülmények között teszteli a rendszer viselkedését. A túlterhelés nem okozhat adatvesztést, vagy a szolgáltatások teljes eltűnését. Erre tervezni kell a rendszert. Olyan hiányosságokat fed fel, amelyek normális esetben nem okoznak rendszerhibát. Különösen fontos az osztott rendszereknél, ahol a nagyobb terhelés a koordinációs adatokkal túlterheli a hálózatot. Ez a folyamatokat lassítja, önmagát erősítő folyamatként túltelíti a rendszert. PPKE-ITK Szoftvertechnológia-2011

25 3. Objetumorientált tesztelés
A komponens- és integrációs tesztelés az objektumorientált rendszereknél is alkalmazható. Fontos különbségek: A tesztelendő objektumok komponensként gyakran nagyobbak, mint az egyszerű függvények. (A fehér doboz tesztelés nehezebben alkalmazható.) Az objektumok lazán kötődnek, és a rendszernek/alrendszernek nincs egyértelmű teteje. Az újrafelhasznált komponensek kódjához nem mindig lehet hozzájutni, elemezni. PPKE-ITK Szoftvertechnológia-2011

26 Az objektumorientált tesztelés szintjei
Az objektumokhoz kapcsolódó műveletek tesztelése: Függvények, vagy eljárások, fekete- vagy fehér doboz eljárással tesztelhetők. Objektumosztályok tesztelése: A fekete doboz eljárás alkalmazható, de az ekvivalencia-osztályokat a műveletsorozatokra is ki kell terjeszteni. Együttműködő objektumcsoportok tesztelése: Forgatókönyv alapján kijelölhető az objektumok csoportja. Objektumorientált rendszer tesztelése: A rendszerkövetelmények verifikációja és validációja más rendszerekhez hasonlóan történhet. PPKE-ITK Szoftvertechnológia-2011

27 3.1 Objektumosztályok tesztelése
A teljes (minden utasítás és minden független útvonal) teszt lefedettséghez szükség van: Az objektumhoz kapcsolódó összes művelet tesztelésére, Az összes attribútum beállítására és tesztelésére, Az objektum összes lehetséges állapotának végrehajtására. Az öröklődés még nehezíti az objektumosztályok tesztelését, mert az összes örökölt műveletet is tesztelni kell. PPKE-ITK Szoftvertechnológia-2011

28 3.2 Objektumintegráció Az objektumorientált rendszerekben az integráció szintjét nehéz meghatározni. A modultesztnek nincs megfelelője, de alkalmazható az együttműködő objektumosztályok csoporttesztje. A csoportok az objektumok működésének és a rendszer tulajdonságainak ismeretében jelölhetők ki. PPKE-ITK Szoftvertechnológia-2011

29 Csoporttesztelés Használati eset vagy forgatókönyv alapján:
A tesztek a felhasználói interakciókon alapulnak. Előnye, hogy a felhasználók által leggyakrabban használt részeket teszteli. Száltesztelés: A rendszernek egy eseményre adott válaszát vizsgálja, amint az a rendszeren keresztülhalad. Objektum együttműködési teszt: Az objektumok együttműködésének egy sorozatát vizsgálja, amely akkor ér véget, ha egy objektumművelet nem hív meg más objektumszolgáltatást. PPKE-ITK Szoftvertechnológia-2011

30 Forgatókönyv alapú tesztelés
A használati eset diagram alapján meghatározott forgatókönyvet kiegészíti egy olyan szekvencia diagrammal, amely az érintett objektumokat is megmutatja. Olyan forgatókönyveket kell választani, amelyek végül biztosítják, hogy minden objektum minden művelete legalább egyszer tesztelve legyen. A szekvencia diagram arra is alkalmas, hogy meghatározzuk a teszt input és output adatait. A forgatókönyvben ki kell térni a kivételekre (hibaesetekre) is.! PPKE-ITK Szoftvertechnológia-2011

31 4. Tesztelő eszközök A tesztelés drága és időigényes folyamat.
A tesztelő eszközök automatizálják, amit lehet, így csökkentik a tesztelés idő- és erőforrásigényét, ezáltal a költségeket. Nagy rendszerek esetén a tesztelő eszközöket a rendszer funkcióihoz és felelősségéhez szabják. A tesztelő eszközöket nem könnyű integrálni a tervező, fejlesztő CASE eszközökkel. PPKE-ITK Szoftvertechnológia-2011

32 Tesztelő eszközrendszer
Tesztadat- generátor Specifi- káció Teszt menedzser Forráskód Tesztadat Előrejelző Dinamikus elemző Tesztelt program Teszt- eredmények Teszt- előrejelzések Futtatási jelentés Szimulátor Állomány össze- hasonlító Jelentés- generátor Teszteredmény jelentések PPKE-ITK Szoftvertechnológia-2011

33 Összefoglalás Legfontosabb a rendszer gyakran használt részeit tesztelni. Az ekvivalenciaosztályozás egy lehetőség a tesztadatok előállítására. Az osztály határára eső értékek fedik fel a hibákat a legnagyobb valószínűséggel. A strukturális tesztelés a programon átvezető útvonalak tesztelésén alapul. Az integrációs tesztek a komponensek és interfészeik közti interakciót vizsgálják. Interfészhibák a specifikáció hibás értelmezéséből és hibás időzítésből származhatnak. Az objektumosztályokat úgy kell tesztelni, hogy minden műveletet kipróbálunk, minden attribútumnak értéket adunk, minden állapotot tesztelünk. Az OO rendszereket a használati esetek alapján összegyűjtött objektumcsoportokban lehet tesztelni. PPKE-ITK Szoftvertechnológia-2011

34 A szoftver költségei

35 A szoftver költségbecslés alapvető kérdései
Mekkora munkát igényel egy feladat elvégzése? Mennyi időbe kerül a feladat végrehajtása? Mennyi a tevékenység összes költsége? A költségbecslés és projektütemezés folyamatos projektvezetési tevékenység. A szoftverfejlesztési projekt költségelemei: A hardver és szoftver költségei a karbantartással együtt, Utazási és képzési költségek, Munkaköltségek (bér, közteher, helység, kisegítő munkák, kommunikáció, rekreáció, ...) PPKE-ITK Szoftvertechnológia-2011

36 A szoftver költsége és ára
A költség és az ár között nincs egyszerű arányosság. Befolyásolják: Piaci lehetőségek, A költségbecslés bizonytalanságai, A szerződéses feltételek (tulajdonjog), A követelmények változékonysága, A fejlesztő gazdasági helyzete. PPKE-ITK Szoftvertechnológia-2011

37 A szoftverfejlesztés termelékenysége
Mérni kell a szoftver valamilyen jellemzőjét és osztani a fejlesztési idővel. Mennyiségi mérések: (Forráskód sorok száma, utasítások száma, dokumentáció oldalszáma, stb.) Funkcionális mérések: (Az időegység alatt előállított hasznos funkciók száma: Funkciópontok, objektumpontok.) A termelékenység összehasonlítása: Alacsonyabb szintű nyelven több kódsort lehet írni, de azonos funkciót több kóddal kell megvalósítani, A jó programozó ugyanazt a funkciót kevesebb kóddal készíti el, mint a „bőbeszédű” programozó, Hogyan vegyük figyelembe a kommenteket? PPKE-ITK Szoftvertechnológia-2011

38 Funkciópontok A program jellemzőinek kombinációján alapuló, nyelv-független módszer. Méri az alábbi jellemzőket: Külső bemenetek és kimenetek Felhasználói interakciók Külső interfészek A rendszer által használt fájlok Mindegyikhez súlyozási tényezőt rendel: Egyszerű külső bemenet: 3 Bonyolult belső állományok: 15 A súlyozási tényezőt egy szervezeten belül, hasonló jellegű szoftverek készítése során gyűjtött statisztikák alapján finomítja. PPKE-ITK Szoftvertechnológia-2011

39 A funkciópontok számítása
A funkciópontok (FP) alapján a kódsorok számára (LOC – Lines Of Code) lehet következtetni: LOC = AVC * FP ahol: AVC nyelvfüggő szorzófaktor ( az assembly és 2-40 a 4GL nyelvekre) A funkciópont számítás nagyon sok szubjektív elemet tartalmaz. Automatikus számítása nem lehetséges, mert a specifikáció alapján kell a funkciópontokat megbecsülni. PPKE-ITK Szoftvertechnológia-2011

40 Objektumpontok 4GL vagy más magas szintű nyelvek esetén a funkciópontok alternatívája. Magas szintű specifikáció alapján könnyebben becsülhető. Az objektumpont (NTC) nem azonos az objektumok számával, hanem az alábbiakból számítható: A külön megjelenítendő képernyők száma, az egyszerűtől (1), a nagyon bonyolultig (3), A készítendő jelentések száma (2 – 5 – 8) A 4GL kiegészítése miatt szükséges 3GL modulok száma (10) PPKE-ITK Szoftvertechnológia-2011

41 A termelékenység becslése
Valósidejű, beültetett rendszerek: 40 – 160 LOC / hó Rendszerprogramok: 150 – 400 LOC / hó Kereskedelmi alkalmazások: 200 – 800 LOC / hó Objektumpontban számolva a termelékenység 4 és 50 pont / hónap közötti, az eszköztámogatottságtól és a fejlesztők képességeitől függően. PPKE-ITK Szoftvertechnológia-2011

42 A termelékenységet befolyásoló tényezők
Az alkalmazási terület ismerete: A hatékony szoftverfejlesztéshez szükséges a szakterület ismerete. A folyamat minősége: A fejlesztési folyamat minőségének jelentős hatása van a termelékenységre. A projekt mérete: A nagyobb projekt több csoportkommunikációs és adminisztrációs tevékenységet igényel. Technológiai támogatás: Támogató technológiával (pl. CASE) a termelékenység növelhető. Munkakörnyezet: A jó munkakörülmények és légkör javítják a termelékenységet. PPKE-ITK Szoftvertechnológia-2011

43 Algoritmikus költségmodellezés COCOMO
Empirikus modell, a projektek gyakorlatából gyűjtött adatokon alapul. Jól dokumentált, hosszú tapasztalat áll mögötte (első verzió: 1981) A COCOMO 2 (1995) három szintű modellt alkalmaz: Korai prototípuskészítés szintje (becslés objektumpontok alapján) Korai tervezés szintje (funkciópontok alapján a forráskódok számát becsli) Poszt-architekturális szint (az architektúra terv elkészülte után becsli a szoftver méretét) PPKE-ITK Szoftvertechnológia-2011

44 Korai prototípuskészítés szintje
Prototípuskészítést és újrafelhasználást is figyelembe vesz. A fejlesztői produktivitást objektumpontokkal számolja és a CASE használatot is bekalkulálja. A formula: PM = (NOP * (1 - %reuse)) / PROD Ahol: PM – a munka emberhónapban, NOP – az objektumpontok száma, PROD - produktivitás A fejlesztő gyakorlata és képessége Nagyon kevés Kevés Átlagos Sok Nagyon magas A CASE érettsége és lehetőségei PROD (NOP/hónap) 4 7 13 25 50 PPKE-ITK Szoftvertechnológia-2011

45 Korai tervezési szint A követelmények tisztázása után végezhető a becslés. Az alábbi képlettel számol: PM = A * MéretB * M + PMm ahol M=PERS*RCPX*RUSE*PDIF*PREX*FCIL*SCED PMm= (ASLOC*(AT/100))/ATPROD A = 2,5 a kezdeti számításban B = 1,1 – 1,24 a projekt mérete, újdonsága függvényében. M = projekttényezők: PERS – személyi képességek, RCPX – termék megbízhatóság, RUSE – szükséges újrafelhasználás, PDIF – platform nehézségei PREX – személyek gyakorlata, FCIL – támogató eszközök, SCED – ütemezés ASLOC = automatikusan generált kódsorok, AT = aut. rendszerkód, ATPRO = termelékenység, PPKE-ITK Szoftvertechnológia-2011

46 Poszt-architekturális szint
Ugyanazt a formulát alkalmazza, mint a korai tervezési becslés, de két tényezőt figyelembe vesz: A követelmények változékonysága, A lehetséges újrafelhasználás mértéke. A szükséges új kódsorok számának becslésekor statisztikai és egyéb értékeket is figyelembe vesz, mint: A korábbi hasonló projektek hiánya, A fejlesztés rugalmassága, A csapat összetartása, A folyamat fejlettsége. PPKE-ITK Szoftvertechnológia-2011