Transcript SE_12-eloadas

A
SZOFTVERTECHNOLÓGIA
ALAPJAI
Szoftvertesztelés
A szoftver becslése
12. előadás
PPKE-ITK
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
13/ 2
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
13/ 3
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
13/ 4
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
13/ 5
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
13/ 6
A hiányosságok tesztelésének folyamata
Tesztesetek
Tesztesetek
tervezése
Tesztadatok
Tesztadatok
készítése
PPKE-ITK Szoftvertechnológia-2011
Teszteredmények
Program
futtatása
tesztadatokkal
Tesztjelentések
Eredmények
összevetése a
tesztesetekkel
13/ 7
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
13/ 8
A fekete doboz tesztelés
Input
tesztadatok
Ie
Rendellenes
viselkedést okozó
input adatok
Rendszer
Output
teszteredmények
PPKE-ITK Szoftvertechnológia-2011
Oe
A hiányosságokat
felfedő outputok
13/ 9
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 10.000 és 99.000
között, akkor az ekvivalencia-osztályok:
10.001 – 99.000,
< 10.000,
< 99.999
• 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
13/ 10
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 ekvivalenciaosztá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
13/ 11
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/ 12
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
13/ 13
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
13/ 14
Inkrementális integrációs tesztelés
A
T1
T1
A
T1
A
T2
T2
B
T3
T2
B
B
T3
C
T4
T3
C
T4
T5
D
Tesztsorozat
1.
Tesztsorozat
2.
PPKE-ITK Szoftvertechnológia-2011
Tesztsorozat
3.
13/ 15
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
13/ 16
Tesztelés fentről lefelé
1. szint
A tesztelés
sorrendje
2. szint
1. szint
2. szint
2. szint
2. szintű csonkok
3. szintű csonkok
PPKE-ITK Szoftvertechnológia-2011
13/ 17
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
PPKE-ITK Szoftvertechnológia-2011
N-1 szint
N-1 szint
13/ 18
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
13/ 19
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
13/ 20
Interfész típusok
• Paraméter 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
13/ 21
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
13/ 22
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
13/ 23
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
13/ 24
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
13/ 25
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 ekvivalenciaosztá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
13/ 26
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
13/ 27
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
13/ 28
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
13/ 29
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
13/ 30
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
13/ 31
Tesztelő eszközrendszer
Forráskód
Teszt
menedzser
Dinamikus
elemző
Tesztelt
program
Futtatási
jelentés
Szimulátor
Tesztadatgenerátor
Specifikáció
Tesztadat
Előrejelző
Teszteredmények
Állomány
összehasonlító
Jelentésgenerátor
PPKE-ITK Szoftvertechnológia-2011
Tesztelőrejelzések
Teszteredmény
jelentések
13/ 32
Ö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
13/ 33
A szoftver költségei
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
13/ 35
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
13/ 36
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
13/ 37
Funkciópontok
• A program jellemzőinek kombinációján alapuló, nyelvfü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
13/ 38
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
(200-300 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
13/ 39
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
13/ 40
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
13/ 41
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
13/ 42
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
13/ 43
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
Nagyon kevés
Kevés
Átlagos
Sok
Nagyon magas
PROD
(NOP/hónap)
4
7
13
25
50
PPKE-ITK Szoftvertechnológia-2011
13/ 44
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
13/ 45
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
13/ 46