Szoftverarchitektúra - implementáció tervezése -
Szoftverarchitektúra - implementáció tervezése -
Szoftverarchitektúra - implementáció tervezése -
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Szoftverarchitektúra</strong><br />
- <strong>implementáció</strong><br />
<strong>tervezése</strong> -<br />
Architektúra<br />
• Architektúra:<br />
– strukturálisan fontos elemek és ezek<br />
kapcsolata.<br />
1
Architektúra központú<br />
• A rendszer architektúrája<br />
– (egy adott pillanatban) a rendszer<br />
alapvető komponenseinek<br />
szerveződése, melyek egymással<br />
meghatározott felületeken keresztül<br />
kommunikálnak, és hierarchikus<br />
szervezésű, egyre finomabb, egymással<br />
szintén megfelelő, alacsonyabb szintű<br />
felületeken keresztül kommunikáló<br />
komponensekből épülnek fel.<br />
Architektúra - nézet<br />
• Egy architektúrát több nézet szerint lehet<br />
leírni.<br />
• A különböző módszertanok különböző<br />
nézeteket javasolnak:<br />
– Statikus nézet: rendszert alkotó elemek,<br />
kapcsolatok.<br />
– Dinamikus nézet: a rendszer időbelisége.<br />
– Funkcionális nézet: a rendszer funkcionalitása,<br />
a rendszer milyen adatokat milyen<br />
algoritmusok alapján generál.<br />
2
Architektúra az alkalmazás<br />
jellege alapján<br />
• Az objektumok csoportosítása az<br />
MVC koordináta rendszer alapján<br />
– Model-View-Control<br />
– Smalltalk vezette be<br />
– Sztereotípus<br />
– Minden jól tervezett objektum valamelyik<br />
koordináta fele húz.<br />
MVC koordináta rendszer<br />
• Koordináták:<br />
– Határ,<br />
– Entitás,<br />
– Control objektumok.<br />
• Ez a gondolatmenet általánosítható<br />
alkalmazásokra, egy-egy alkalmazás<br />
olyan mint egy nagy objektum.<br />
3
MVC koordináta rendszer<br />
• Határ:<br />
– Felület dominenciájú alkalmazások:<br />
• Jellegzetes desktop alkalmazások, szövegszerkesztők,<br />
vizuális felhasználói környezetek stb.<br />
• Entitás:<br />
– Klasszikus információrendszerek<br />
– Fő feladatuk az adatkezelés<br />
• Control<br />
– Algoritmus dominenciájú alkalmazások<br />
– Tudományos, műszaki számításokat végző<br />
alkalmazások<br />
– Az architektúrát az algoritmusok befolyásolják<br />
– Ritka a gyakorlatban.<br />
Mi a szoftverarchitektúra?<br />
• A rendszert felépítő alrendszerek<br />
(szoftver komponensek) kerete<br />
– alrendszerek meghatározása<br />
– alrendszerek tulajdonságai<br />
– Vezérlési, valamint kommunikációs<br />
kapcsolataik<br />
4
Mi még a szoftverarchitektúra?<br />
• Magasszintű terv<br />
• A rendszer átfogó struktúrája<br />
– több nézet -> több struktúra<br />
• Komponensek és összekötők<br />
összesége<br />
Architektúra központú<br />
• Architektúrális komponensek:<br />
– A rendszer alapvető működését meghatározó<br />
szoftver részek, rendszerszervezési<br />
megoldások.<br />
• A fejlesztés fázisaiban központi szerepet<br />
kap a robosztus architektúra:<br />
– Robosztus = rugalmas, jól tűri a változásokat<br />
• Az architektúra megalapozása az<br />
elsődleges feladat, hiszen ha itt hibázunk,<br />
az nagyon sokba kerül.<br />
5
A SW architektúra szerepe<br />
• Az érdekelt szereplők<br />
kommunikációjának lehetővé tétele.<br />
• A korai fejlesztási fázisok<br />
döntéseinek támogatása a<br />
követelmények tükrében.<br />
• Nagyléptékű újrafelhasználhatóság<br />
elősegítése.<br />
A SW architektúra célja<br />
• Az architektúra célja:<br />
– átláthatóvá teszi a fejlesztést,<br />
– könnyebben felismerhetők az<br />
újrafelhasználható elemek,<br />
– átlátható projekt menedzsment,<br />
– kockázatok csökkentése,<br />
– lehetővé válik a párhuzamos fejlesztés.<br />
6
A SW architektúrák forrása<br />
• Üzleti és technológiai döntések<br />
eredménye<br />
• Meghatározó a környezet szerepe<br />
• A fejlesztők céljai és stratégiája által<br />
befolyásolt követelmények vezetnek<br />
különféle szoftver architektúrákhoz<br />
Az architektúra ciklus<br />
• Az architektúra meghatározó a fejlesztő<br />
szervezet szerkezetére<br />
• Az architektúra befolyásolja a fejlesztő<br />
szervezet céljait<br />
• Az architektúra hatással van a<br />
követelményekre<br />
• A fejlesztés során a fejlesztők<br />
tapasztalatokat szereznek architektúráról<br />
• Bizonyos rendszerek hatással vannak a<br />
fejlesztési kultúrára<br />
7
Az architektúra ciklus<br />
Fejlesztõ szervezet<br />
A rendszer szereplõi<br />
Követelmények<br />
Technológiai<br />
követelmények<br />
A tervezõ tapasztalata<br />
Tervezõ/fejlesztõ<br />
Mitől jó egy architektúra?<br />
• Kis számú vezető tervező<br />
Architektúra<br />
Rendszer<br />
• Jól definiált funkcionális követelmények és<br />
minőségi jellemzők<br />
• Jól dokumentált az architektúra<br />
• Az architektúra értékelésében az összes<br />
érintett szereplő részt vesz<br />
• Kvantitatív minőségi mértékek<br />
• Inkrementális architektúra <strong>implementáció</strong><br />
• Kevés erőforrás versenyhelyzet a<br />
fejlesztés során<br />
8
Architektúra elemek<br />
• Architektúrális minta<br />
– típus elemek és kapcsolatok, kényszerek<br />
– pl. kliens-szerver minta<br />
• Referencia modell<br />
– standard funkcionális felosztás és adatfolyam<br />
megoldások<br />
– pl. adatbázis kezelő rendszer<br />
• Referencia architektúra<br />
– referencia modell leképezése szoftver<br />
elemekre<br />
– pl. ISO OSI architektúra<br />
Az architektúra rétegei<br />
• A rendszer különböző szinten<br />
elhelyezkedő elemei rétegekbe<br />
sorolhatók.<br />
9
Rétegzett architektúra<br />
• Általánosan használt<br />
modell<br />
• Mit jelent a rétegzettség:<br />
– Fizikai rétegek (tier): az egyes rétegek különböző<br />
futtatható állományokban vannak, ezek a<br />
futtatható állományok különböző gépeken<br />
helyezkednek el, az egyes futtatható elemek<br />
hálózati protokollon keresztül beszélgetnek<br />
– Logikai rétegek (layer): a forráskód belső<br />
tagozódása.<br />
• Egyirányú a logikai függés: a fizikai<br />
rétegzettség feltételezi a logikait, de fordítva<br />
nem!<br />
Javasolt rétegek<br />
• Rendszerszoftver réteg.<br />
• Közép réteg (elosztott komponensek:<br />
EJB, CORBA, DCOM).<br />
• Általános alkalmazási réteg.<br />
• Felhasználó specifikus alkalmazási<br />
réteg (user interfészek).<br />
• RUP által javasolt.<br />
10
Szokásos logikai rétegek<br />
• Kezelői felület<br />
• Alkalmazás logika<br />
• Adatbázis logika<br />
• Frameworks, middleware, rendszer szoftver<br />
– Minden, ami kiszolgál.<br />
Szokásos logikai rétegek<br />
• Kezelői felület<br />
– Csak a megjelenés.<br />
• Alkalmazás logika<br />
– Az alkalmazásra jellemző elemek.<br />
11
Szokásos logikai rétegek<br />
• Adatbázis logika<br />
– Egész szervezetre, egész adatbázisra jellemző,<br />
nem alkalmazás függő. Általában egy<br />
adatbázison több, különböző célú alkalmazás is<br />
dolgozhat (Számlázó-, Megrendelés kezelő-,<br />
Raktárkészlet kezelő alkalmazás), amik részben<br />
vagy egészében ugyan azokat az adatokat<br />
használják és az adatok között vannak olyan<br />
összefüggések, amik függetlenek a feldolgozás<br />
céljától.<br />
• Frameworks, middleware, rendszer szoftver<br />
– Minden, ami kiszolgál.<br />
Együttműködés<br />
• Kliens-szerver architektúra.<br />
12
Néhány elterjedt<br />
architektúrális modell<br />
• Osztott adatokra épített architektúra<br />
– CASE eszközök<br />
• Kliens-szerver architektúra<br />
– hálózati, kommunikációs szoftverek<br />
• Réteg szerkezet architektúra<br />
– protokoll referencia modellek<br />
• Funkcionális csőrendszerek<br />
• Eseményvezérelt rendszerek<br />
Osztott adatok<br />
• Az alrendszerek adatokat cserélnek<br />
– központi adatbázis<br />
– saját adatbázisok, explicit adatcsere<br />
• Közös adatigényű alkalmazások<br />
13
Osztott adatok<br />
• Előnyök<br />
– nagy mennyiség" adat<br />
hatékonymegosztása<br />
– központi adat kezelés lehetősége<br />
• Hátrányok<br />
– minden részrendszerben azonos<br />
adatszervezés<br />
– elosztottság nehézkes<br />
Osztott adatok<br />
• Integrált CASE eszköz<br />
14
Réteg szerkezet<br />
modell<br />
• Speciális alrendszer elrendezés<br />
• Rétegekbe szervezett modulok,<br />
szolgáltatások<br />
• Jól definiált interfészek<br />
• Inkrementálisan, egymástól<br />
elkülönülten fejleszthető rétegek<br />
• Mesterségesen kialakított rétegek<br />
Az OSI modell 7 rétege<br />
• fizikai réteg<br />
• adatkapcsolati réteg<br />
• hálózati réteg<br />
• szállítási réteg<br />
• viszony réteg<br />
• megjelenítési réteg<br />
• alkalmazási rétegek<br />
15
A hoszt B hoszt<br />
Alkalmazási<br />
Megjelenítési<br />
Viszony<br />
Szállítási<br />
Hálózati<br />
Adatkapcsolati<br />
Fizikai<br />
Alkalmazási protokoll<br />
Megjelenítési protokoll<br />
Viszony protokoll<br />
Szállítási protokoll<br />
Hálózati protokoll<br />
Adatkapcsolati protokoll<br />
Fizikai protokoll<br />
Eseményvezérelt<br />
rendszerek<br />
Alkalmazási<br />
Megjelenítési<br />
Viszony<br />
Szállítási<br />
Hálózati<br />
Adatkapcsolati<br />
Fizikai<br />
• A rendszer vezérlésén kívülről érkező<br />
események határozzák meg a<br />
viselkedést<br />
– Pl. Ha a vállalat eseményvezérelten<br />
működik, a felhasználói rendelések<br />
közvetlenül meghatározzák a<br />
legyártandó termékek számát (a<br />
rendelés beérkezése "kiváltja" a gyártás<br />
indítását).<br />
• Eseményvezérelt modell<br />
– broadcast modell<br />
16
a végzendő<br />
feladatok<br />
mennyisége<br />
Broadcast modell<br />
• Elosztott alrendszerek integrálása<br />
• Az alrendszerek “előfizetnek” az őket<br />
érdeklő eseményekre az<br />
eseménykezelőnél<br />
• Események időbeli bekövetkezte<br />
ismeretlen<br />
A programtervezés jelentősége<br />
karbantartás<br />
tesztelés<br />
programtervezés<br />
kódolás<br />
Megvalósítás tervezés nélkül<br />
karban-<br />
tartás<br />
tesztelés<br />
kódolás<br />
tervezés<br />
Megvalósítás tervezéssel<br />
17
A programtervezési módszerek<br />
sajátosságai<br />
• cél az információs domének tervezési<br />
reprezentációvá alakítása<br />
• megoldás szimbólumkészlettel, amely a<br />
komponensek, azok viszonyának és az<br />
algoritmusnak a leírására szolgál<br />
• ajánlás az eljárások finomításának és<br />
komponensre bontásának<br />
végrehajtására<br />
• szempontokat ad a szoftverminőség<br />
biztosításához<br />
A Warnier-féle strukturált<br />
programtervezési lépések<br />
• adatszerkezetek <strong>tervezése</strong><br />
• a programszerkezet kialakítása<br />
• funkcionális leírás<br />
• tevékenységek programstruktúrákhoz<br />
rendelése<br />
18
A Lorensen-féle OO<br />
programtervezés lépései<br />
• az alrendszerek adatigényét kielégítő<br />
osztályabsztrakciók meghatározása<br />
• az absztrakciós osztályok jellemzőinek<br />
specifikálása<br />
• az osztályok műveleteinek meghatározása<br />
• objektumok közötti kommunikáció<br />
módjának (üzenetek) specifikációja<br />
• felhasználói igények leírása scenárióval<br />
• öröklődés vizsgálata<br />
A programtervezés feladatai<br />
A programtervezés a korábbi fázisokban kialakított modellek<br />
(adat- illetve objektum-modell, funkcionális modell és a<br />
rendszer viselkedését leíró dinamikus modell) alapján történik.<br />
A programspecifikációt lépései:<br />
– adat-tervezés:<br />
az adatstruktúrák és ábrázolási módok specifikálása<br />
– architektúra tervezés:<br />
a programrendszer egyes komponenseinek, azok<br />
egymáshoz való viszonyának meghatározása<br />
– folyamatok (procedures) <strong>tervezése</strong><br />
a szerkezeti komponensek működési folyamatokhoz<br />
illesztésének specifikációja<br />
19
Dinamikus<br />
Adat/objektum modell<br />
modell<br />
adatok <strong>tervezése</strong><br />
Funkcionális<br />
modell<br />
Egyéb elvárások,<br />
körülmények<br />
Programtervezés<br />
procedurális<br />
tervezés<br />
Az <strong>implementáció</strong>s<br />
fázis szakaszai<br />
Kódolás<br />
architektúra-terv Programmodulok<br />
Tesztelés<br />
Tervezési alapelvek<br />
tesztelt<br />
szoftver-rendszer<br />
(integrációs és<br />
validitási ellenõrzés)<br />
• absztrakció<br />
• lépésenkénti finomítás<br />
• modularitás, komponens szemlélet<br />
• szoftver-architektúra<br />
• vezérlési hierarchia<br />
• adatstruktúra és adatfolyam<br />
• szoftverfolyamatok<br />
• komponens architektúra<br />
• információelrejtés<br />
20
Modularitás<br />
• modul, komponens értelmezése<br />
beépülési, aktivitási jellemző, vezérlési mód<br />
típusok: compile time~, corutin~, conrutin~<br />
definíció:<br />
a modul, a komponens a programrendszer legkisebb,<br />
önállóan is működőképes, cserélhető,<br />
újrafelhasználható egysége, amely interfészeken<br />
keresztül csatlakozik a környezetéhez<br />
• funkcionális függetlenség<br />
kohézió (binding), csatolás (link, coupling)<br />
Architektúra adatfolyamdiagram<br />
Cél:<br />
az architektúra-komponensek<br />
A B<br />
0. szint<br />
közötti adat- és vezérlési<br />
információk áramlásának, az<br />
üzenettovábbítási<br />
folyamatoknak a szemléltetése<br />
1. szint<br />
21
Objektumorientált<br />
fejlesztőkörnyezet -<br />
komponensdiagram<br />
Alkalmazások, kliens oldal<br />
user interface<br />
(felhasználói felü-<br />
let komponens)<br />
TCP/IPv6<br />
protokoll<br />
Rendszer szerver<br />
object database<br />
(objektum<br />
adatbázis)<br />
Fejlesztõ rendszer Project-<br />
management<br />
rendszer-<br />
szolgáltatások<br />
CASE eszközök,<br />
alkalmazás-<br />
generátorok<br />
repository domain<br />
(fejlesztési<br />
adatbázis)<br />
A programtervezés feladatai<br />
• adat- és objektumtervezés<br />
• architektúra tervezés<br />
bemeneti, kimeneti információk, működési, vezérlési<br />
funkciók, tesztelési feladatok<br />
• folyamat-terv készítése<br />
• működési algoritmus<br />
• fejlesztőkörnyezet kiválasztása<br />
• kódolás<br />
22
A program-architektúra<br />
tervezés feladatai<br />
• a rendszer bemeneti információinak<br />
meghatározása<br />
• felhasználói interfészek <strong>tervezése</strong><br />
• a rendszer működését vezérlő funkciók terve:<br />
menüszerkezet<br />
• architektúra kontextus diagram: információ<br />
forrása,típusa, kommunikációs útvonal<br />
• szolgáltatások, outputok specifikációja<br />
• karbantartási, diagnosztikai és tesztelési tervek<br />
A működési algoritmus<br />
<strong>tervezése</strong><br />
• folyamatábra<br />
• Warnier-Orr diagram<br />
• Jackson ábra avagy struktúra diagram<br />
• Nassi-Shneidermann avagy Chapin-Chart ábra<br />
• komponensdiagram<br />
• vezérlési struktúradiagram<br />
lásd szemléletesen:<br />
23
Folyamatábra szimbólumok<br />
start/stop<br />
kapcsolódási pont<br />
manuális mûvelet<br />
funkció, mûvelet<br />
elõkészítõ funkció<br />
lemez állomány<br />
rutinmûvelet , könyvtárprogram<br />
logikai döntés, elágaztatás<br />
mûveletek sorrendje<br />
általános adat szimbólum<br />
forrás-dokumentum vagy<br />
nyomtatott output<br />
on-line input<br />
szalag állomány<br />
on-line output<br />
adatkommunikáció<br />
Folyamatábrakészítés<br />
START<br />
Input a,b<br />
c= 2a+ 5b<br />
d= 7ab-4b/a<br />
c= d? igen<br />
nem<br />
x= 5b-3d<br />
igen<br />
x= 4a+ 7c x= d+ a? kiír a,b,x<br />
END<br />
Folyamatábra minta<br />
Műveleti struktúrák folyamatábrával<br />
Mûveletek<br />
szekvenciája<br />
utasítás<br />
utasítás<br />
A szelekció<br />
logikai struktúrája<br />
IF ...<br />
nem<br />
feltétel<br />
igen<br />
ELSE ág THEN ág<br />
ciklus-<br />
utasítások<br />
DO UNTIL<br />
felltétel<br />
igen<br />
nem<br />
Iteratív mûveletek ciklikus szerkezetei<br />
hátultesztelõ elõltesztelõ<br />
nem<br />
DO UNTIL DO WHILE<br />
ciklus-<br />
utasítások<br />
DO WHILE<br />
felltétel igen<br />
nem<br />
24
o<br />
a= 1?<br />
*<br />
end: k= 50<br />
k= k+ 1<br />
a= a*k+ 1<br />
Szekvencia<br />
1. feladat<br />
2. feladat<br />
3. feladat<br />
JACKPR<br />
o<br />
a«0?<br />
o<br />
o<br />
a= 1000? különben<br />
k= 25 k= k*2<br />
o<br />
a= 9999?<br />
vege<br />
Jackson-féle<br />
struktúradiagram<br />
Chapin-Chart szerkezetek<br />
IF THEN ... ELSE ...<br />
szelekció<br />
feltétel ciklus feltétel<br />
hamis igaz<br />
ELSE THEN<br />
ág ág<br />
Iteráció szemléltetése<br />
DO WHILE<br />
ciklusmag<br />
REPEAT<br />
UNTIL<br />
ciklusmag<br />
ciklus feltétel<br />
CASE szelekció<br />
CASE feltételek<br />
érték érték ......<br />
utas. utas. ......<br />
25
Vezérlési struktúradiagram<br />
sorrendiség<br />
S;<br />
S;<br />
S;<br />
döntés (if ... then ... else ...) case<br />
S;<br />
if C then<br />
else<br />
S;<br />
S;<br />
S;<br />
S;<br />
S;<br />
end if<br />
S; S;<br />
S;<br />
case D is<br />
when C1= ><br />
S;<br />
S;<br />
end case<br />
when C2 = ><br />
S;<br />
S;<br />
Komponens architektúra<br />
"A" modul<br />
"A1" modul "A2" modul<br />
"A3" modul<br />
while ciklus<br />
S;<br />
while C;<br />
end C;<br />
S;<br />
"A31" modul "A32" modul<br />
S;<br />
S;<br />
S;<br />
26
Kódolás<br />
„A számítógépes program készítése a<br />
végrehajtandó utasítások meghatározott<br />
sorrendben írását jelenti a rendelkezésre álló<br />
nyelven. Az a mód azonban, ahogyan a<br />
programozó a nyelvi lehetőségeket<br />
használja a program intelligenciájának<br />
mértéke…”<br />
Tesztelés<br />
Kernighan, 1978.<br />
27
A tesztelés szükségessége,<br />
jelentősége<br />
Tesztelés<br />
kiértékelése<br />
Elfogadási,<br />
rendszer - és<br />
terhelési teszt<br />
Modul- és<br />
integrációs teszt<br />
Bevezetés, üzemeltetés,<br />
karbantartás,<br />
minőségbiztosítás<br />
Megvalósítás<br />
Tesztelés célja<br />
Célkitűzés,<br />
problémadefiniálás<br />
Elemzés,<br />
követelmény-<br />
specifikáció<br />
Inkrementális<br />
tervezés<br />
• Helytelen szemlélet:<br />
– a szoftver hibamentességének<br />
bizonyítása, ill. a specifikált<br />
tulajdonságok megvalósításának<br />
bizonyítása.<br />
• Helyes felfogás:<br />
– a szoftvertesztelés a fejlesztett szoftver<br />
végrehajtása azzal a céllal, hogy a<br />
benne levő hibákat, ill. a specifikációtól<br />
eltérő viselkedését felderítsük.<br />
28
Szoftverrendszerek tesztelése<br />
• A szoftver fejlesztés célja:<br />
– a specifikációban leírt követelményeket<br />
kielégítő szoftver készítése.<br />
– Fejlesztés során különböző ellenőrző,<br />
elemző lépéseket kell végrehajtanunk a<br />
cél elérése érdekében. A vizsgálat során<br />
két egymástól eltérő célunk lehet:<br />
• Vizsgálhatjuk azt, hogy a megfelelő terméket<br />
készítjük-e. Ebben az esetben validációt<br />
végzünk.<br />
• Vizsgálhatjuk azt, hogy a terméket jól<br />
készítjük-e. Ebben az esetben verifikációt<br />
végzünk.<br />
V & V: verifikáció és validáció<br />
• A verifikáció:<br />
– azt vizsgáljuk, hogy a fejlesztés során<br />
egymás után végrehajtott fejlesztési<br />
lépések során előállított szoftver (ill.<br />
annak terve) megfelel-e a<br />
specifikációban rögzített elvárásoknak,<br />
tulajdonságoknak.<br />
– A verifikáció során a vizsgálat alapja<br />
mindig valamilyen fejlesztés során<br />
előállított információ (termék).<br />
29
V & V: verifikáció és validáció<br />
• A validáció:<br />
– általánosabb folyamat,<br />
– Azt vizsgáljuk, hogy az elkészített<br />
termék megfelel-e a megrendelő<br />
elvárásainak.<br />
– A validáció tehát magában foglalja a<br />
specifikáció ellenőrzését is.<br />
V & V: verifikáció és validáció<br />
• A verifikáció, és a validáció<br />
végrehajtására használható<br />
technikák:<br />
– Szoftver átvizsgálás.<br />
– Szoftvertesztelés.<br />
30
V & V: verifikáció és validáció<br />
• Szoftver átvizsgálás:<br />
– A fejlesztés során előállított termékek<br />
(modellek, kód, stb.) statikus elemzése,<br />
ami lehet manuális vagy automatizált.<br />
– Manuális vizsgálatra példa a kód-review<br />
különböző formái, automatizált<br />
vizsgálatra példa a UNIX rendszerekben<br />
használt lint (splint) eszköz, mely C<br />
programokat elemez és felhívja a<br />
fejlesztő figyelmét a potenciálisan hibás,<br />
vagy hibát eredményező kódrészletekre.<br />
V & V: verifikáció és validáció<br />
• Szoftvertesztelés:<br />
– Az implementált szoftver futtatása<br />
tesztadatokkal, annak kimeneteinek,<br />
viselkedésének, ill. teljesítményének<br />
megfigyelése, összevetése a<br />
követelményekkel, azzal a céllal, hogy a<br />
benne levő hibákat felderítsük.<br />
– Ezt nevezzük dinamikus elemzésnek, ill.<br />
dinamikus verifikációnak.<br />
31
Statikus és dinamikus verifikáció<br />
alkalmazása szoftverfejlesztés során<br />
statikus verifikáció<br />
(review)<br />
dinamikus verifikáció<br />
(szoftvertesztelés)<br />
Követelmények<br />
1. Analízis & Tervezés<br />
Rendszer terv<br />
(pl. UML diagrammok)<br />
2. Terv verifikációja<br />
Verifikált rendszer terv<br />
(pl. UML diagrammok)<br />
3. Implementáció<br />
Implementált rendszer<br />
(pl. C++ code)<br />
4. Tesztelés<br />
Tesztelt rendszer<br />
Szoftvertesztelés alapsémája<br />
• A tesztelés lényege összehasonlítás:<br />
– A tesztelt szoftver (software under test, SUT)<br />
kimeneteit, működését, viselkedését<br />
összehasonlítjuk valamilyen referenciával.<br />
– Az összehasonlítás alapjául szolgáló<br />
referencia leírása sok forrásból származhat,<br />
attól függően, hogy a szoftverfejlesztés mely<br />
stádiumában hajtjuk végre a tesztelést.<br />
• Származhat az információ a specifikációból nyert<br />
adatokból,<br />
• prototípus szoftver leírásából/megfigyeléséből, vagy<br />
• a fejlesztés során előállított, rendszer viselkedését<br />
leíró modellből.<br />
32
Szoftvertesztelés alapsémája<br />
bemeneti sorozat<br />
Referencia<br />
(követelmény specifikáció,<br />
prototípus, rendszermodell<br />
stb.)<br />
viselkedés, állapot<br />
megfigyelése<br />
Tesztelt szoftver<br />
software under test,<br />
SUT<br />
referencia kimenet<br />
Értékelés<br />
(viselkedés, kimenetek<br />
összehasonlítása)<br />
SUT kimenet<br />
Szoftvertesztelés típusai<br />
eredmény<br />
• Két típus az alapján, hogy mi a<br />
tesztelés célja:<br />
– Hiányosság és hiba tesztelés:<br />
A tesztelés célja a fejlesztés során<br />
bekerült specifikációtól eltérő, vagy nem<br />
megvalósított működés kiszűrése.<br />
– Statisztikai tesztelés:<br />
A program teljesítményének,<br />
megbízhatóságának vizsgálata<br />
általában valós bemenetek<br />
felhasználásával.<br />
33
Tesztelés folyamata<br />
• A szoftver tesztelése különböző lépésekre<br />
bontható.<br />
• A szoftverfejlesztés korai szakasza, teszt<br />
<strong>tervezése</strong>:<br />
– definiáljuk, milyen módszerekkel és milyen lépésekben<br />
végezzük a szoftver tesztelését.<br />
• A tesztelés következő lépése a tesztesetek<br />
definiálása.<br />
– Tesztesetnek nevezzük egy adott hiba felderítésére<br />
szolgáló tesztet.<br />
– A teszteset definíciója tartalmazza:<br />
• a tesztelés során használandó bemeneteket,<br />
• a tesztelt szoftver teszteset végrehajtásához szükséges<br />
állapotának leírását (esetlegesen az állapot beállítás<br />
módját),<br />
• a helyes működés során keletkező referencia kimeneteket,<br />
ill.<br />
• a teszteset hibamentes végrehajtása során történő<br />
viselkedésének (pl. bejárt állapotok) leírását.<br />
Tesztelés folyamata<br />
– Ha egy teszteset alkalmas arra, hogy annak<br />
végrehajtásával egy adott hiba meglétét, ill.<br />
hiányát felderítsük, akkor azt mondjuk, hogy az<br />
adott teszteset (ill. az adott teszt) a kérdéses<br />
hibát lefedi. Ennek megfelelően beszélünk<br />
tesztesetek (tesztek), ill. teszteset halmazok<br />
(teszthalmazok) hibafedéséről.<br />
– Tesztgenerálásnak azt a folyamatot nevezzük,<br />
mely során a teszteseteket előállítjuk,<br />
definiáljuk. A tesztgenerálás célja a minél<br />
nagyobb hibafedésű teszthalmaz előállítása.<br />
34
Tesztelés folyamata<br />
• A tesztesetek definiálása és szoftver<br />
implementálása után történik:<br />
– a tesztesetek végrehajtása,<br />
– az eredmények értékelése, elemzése,<br />
mely a tesztelés utolsó fázisa.<br />
• A szoftverben feltételezhetően<br />
előfordulható hibák leírását nevezzük<br />
hibamodellnek.<br />
SW hibamodell<br />
• Hibák:<br />
– specifikációs hibák,<br />
– tervezési hibák,<br />
– kódolási hibák...<br />
• Általános probléma:<br />
– Nem lehet olyan leírását adni a<br />
hibáknak, ami általánosan használható.<br />
– Nehéz a tesztelés hatékonyságát mérni.<br />
35
Tesztelési megközelítések<br />
• A tesztelés során a tesztelt rendszert<br />
különböző módon lehet kezelni, mely<br />
alapvetően más, és más<br />
módszereket fog eredményezni a<br />
tesztesetek előállítására. Két<br />
alapvető megközelítés létezik:<br />
– Funkcionális tesztelés<br />
– Strukturális tesztelés<br />
Funkcionális tesztelés<br />
• A tesztelő nem veszi figyelembe a tesztelt<br />
szoftver belső felépítését. Kizárólag a<br />
rendszer specifikációja alapján végzi a<br />
tesztelést.<br />
• Az ilyen szemléletben történő tesztelést<br />
szokták még specifikáció alapján történő<br />
tesztelésnek is hívni.<br />
• Mivel a tesztek <strong>tervezése</strong>, ill. végrehajtása<br />
során a tesztelés alatt álló szoftver<br />
belsejébe nem látunk bele, szokásos az<br />
ilyen technikákat fekete doboz (black<br />
box) tesztelésnek is nevezni.<br />
36
Strukturális tesztelés<br />
• A funkcionális tesztelés ellentéte.<br />
• A tesztelés a szoftver a specifikációban<br />
megadott funkciót megvalósító program<br />
szerkezete alapján történik.<br />
• Mivel a tesztelő „belelát” a szoftver belső<br />
működésébe szokásos az ilyen<br />
technikákat fehér doboz (white box)<br />
tesztelésnek is nevezni.<br />
• Strukturális tesztelés esetén a program<br />
vezérélési szerkezetét modellezzük és a<br />
tesztelő a vezérlési szerkezet minden<br />
ágát, a program különböző bemenetek<br />
esetén végrehajtódó részét végrehajtva<br />
vizsgálja annak működését.<br />
Funkcionális tesztelési módszerek<br />
• Az ekvivalencia partícionálás<br />
– egy természetes tesztelési megközelítés<br />
formalizálása.<br />
– Abból indul ki, hogy minden hibához<br />
lehetőleg csak egy tesztesetet definiáljunk.<br />
Ennek érdekében a szoftver bemeneti<br />
adatainak minden kombinációját tartalmazó<br />
képzeletbeli halmazt olyan részekre<br />
(partíciókra) bontja, melyek mindegyike más és<br />
más hiba felderítésére alkalmas.<br />
– A bemenetek partícionálása után, a tesztesetek<br />
definiálásakor a tesztelő az egyes partíciókból<br />
egyet-egyet választ.<br />
37
Funkcionális tesztelési módszerek<br />
• A határérték analízis:<br />
– az ekvivalencia partícionálás finomítása.<br />
– Míg az ekvivalencia partícionálás során minden<br />
ekvivalencia osztályból csak egy, az osztályt<br />
reprezentáló bemenetet választottunk, addig a<br />
határérték analízis definiálja, hogy melyik<br />
bemenetet (vagy bemeneteket) válasszuk az<br />
ekvivalencia osztályból.<br />
– Azt mondja, hogy ha két partíció határos, vagyis<br />
a bemenetek természetes sorrendjében<br />
„egymás után következő” bemeneteket<br />
tartalmaz, akkor ezeket a partíció határán levő<br />
értékeket célszerű a tesztesetekben használt<br />
bemenetnek választani.<br />
– Egy partícióból, ha több más partícióval<br />
határos, akár több bemenetet is használhatunk.<br />
Strukturális tesztelés<br />
• A tesztelő nem állít fel explicit hibamodellt a<br />
felderítendő hibákról, kizárólag a hibamentes<br />
program működését, vezérlési szerkezetét<br />
modellezi a folyamat vezérlési gráf (Control<br />
Flow Graph - CFG) segítségével.<br />
• A strukturális tesztelés alapfeltételezése<br />
szerint a programban létrejövő hibák<br />
valamilyen módon befolyásolják a<br />
program vezérlési szerkezetét, mely a<br />
működést leíró folyamat vezérlési gráf gráfpontjainak,<br />
ill. éleinek hibás (nem<br />
megengedett) bejárását jelenti.<br />
• A használt hibamodell tehát egy folyamat<br />
vezérlési gráf alapján felállított implicit<br />
hibamodell.<br />
38
Tesztelés menete ST esetén<br />
• Tesztgenerálás:<br />
– Teszt bemenetek generálása valamilyen<br />
mértékszám alapján.<br />
• Teszt végrehajtás:<br />
– Program egy vezérlési ágának<br />
végrehajtása.<br />
– Eredmények összehasonlítása a<br />
specifikációban rögzítettel.<br />
Strukturális tesztelés előnyei<br />
• Hibák keresése anélkül, hogy<br />
tudnám, milyen hibákat is keresek<br />
konkrétan.<br />
• Matematikai modell: tesztelés<br />
hatékonyságának számszerű<br />
mérése.<br />
ST felhasználási területei:<br />
– Vezérlés intenzív alkalmazások.<br />
– Tervezési hibák felderítése.<br />
– Elérhetetlen (dead) kódrészek<br />
felderítése.<br />
39
Strukturális tesztelés módszerei<br />
• Vezérlési szerkezet modellezése<br />
• Programok vezérlési bonyolultsága<br />
• Egyszerű strukturális tesztgenerálás<br />
Vezérlési szerkezet modellezése<br />
• Folyamat vezérlési gráf (FVG)<br />
Control Flow Graph (CFG)<br />
• Gráf pontok: utasítások + végpont.<br />
• Egymás után végrehajtott<br />
utasításokat gráf él köti össze.<br />
• Utasítások típusa:<br />
– Szekvenciális utasítás.<br />
– Elágazás utasítás (predicate statement).<br />
40
CFG<br />
• A CFG egy gráf modell.<br />
• A gráf pontok az utasításoknak<br />
feleltethetők meg. Az utasításokat<br />
reprezentáló gráf pontokon kívül a program<br />
kezdetét, belépési pontját és végét,<br />
kilépési pontját is egy-egy gráf pont<br />
reprezentálja.<br />
• A gráf származtatása igen egyszerű, az<br />
egymás után végrehajtható utasításokat<br />
egy-egy irányított gráf él köti össze.<br />
CFG<br />
• A gráf-pontok két típusa:<br />
– Egyszerű (szekvenciális) gráf pont, amelyből<br />
egyetlen gráf él indul ki, és egy szekvenciális<br />
utasítást reprezentál.<br />
– Elágazás gráf pont, amelyből egynél több gráf<br />
él indul ki, és egy elágazás utasítás (predicate<br />
statement) feleltethető meg neki.<br />
• A CFG esetén az egyszerűbb<br />
kezelhetőség miatt általában a kimenő élek<br />
számát kettőben szokták limitálni.<br />
• Az elágazás utasításban mindig szerepel<br />
egy feltétel, mely meghatározza, hogy az<br />
utasítás végrehajtásakor melyik következő<br />
utasítás hajtódik végre.<br />
41
CFG<br />
3<br />
5<br />
7<br />
START<br />
1<br />
2<br />
4<br />
6<br />
END<br />
Programok vezérlési bonyolultsága<br />
• A programok vezérlési szerkezetének<br />
bonyolultsága igen eltérő lehet.<br />
• A programok vezérlési szerkezetének<br />
bonyolultságát jellemző mérőszám,<br />
az ún. ciklomatikus komplexitás (CK,<br />
Cyclometric complexity).<br />
42
Programok vezérlési<br />
bonyolultsága<br />
• Ciklonometrikus komplexitás (CK)<br />
(Cyclonometric complexity)<br />
• Független út:<br />
Olyan gráf út, amelyben létezik olyan<br />
pont v. él, amely más útnak nem<br />
eleme.<br />
• Ciklonometrikus komplexitás<br />
definíciója:<br />
A FVG-ben található független gráf<br />
utak maximális száma.<br />
CK számítása<br />
• Jelölés:<br />
G: gráf; V(G): CK ; E: élek száma;<br />
N: pontok száma;<br />
P: elágazás utasítások száma.<br />
• V(G)= E-N+2<br />
• V(G)=P+1<br />
(bináris elágazások esetén)<br />
43
CK számítási példa<br />
E=11<br />
N=9<br />
V(G)=E-N+2=11-9+2=4<br />
P=3<br />
V(G)=P+1=3+1=4<br />
Egyszerű strukturális<br />
tesztgenerálási algoritmus<br />
3<br />
5<br />
7<br />
begin<br />
1<br />
2<br />
4<br />
6<br />
end<br />
• CFG generálása a kód alapján.<br />
• CK számítása az CFG alapján.<br />
• Független utak maximális (CK<br />
darab utat tartalmazó) halmazának<br />
generálása.<br />
• Bemenetek generálása a független<br />
utak bejárásához.<br />
44
Problémák tesztgenerálás<br />
során<br />
• AZ CFG:<br />
– ciklikus, vagyis kört tartalmaz, így<br />
elvben a végtelen sok út generálható az<br />
adott CFG-hoz.<br />
• Nem generálható olyan bemeneti<br />
kombináció, amely egy adott út<br />
bejárását eredményezné az CFGben.<br />
Teszt hatékonyságának mérése<br />
• A strukturális tesztelés<br />
alaposságának jellemzésére<br />
mértékszámokat lehet használni.<br />
• A mértékszám egy arányszám:<br />
– megmutatja, hogy a kiválasztott<br />
szempont szerint a tesztelhető elemek<br />
(egységek, tételek) mekkora részét<br />
teszteltük le,<br />
– a korábban bevezetett terminológiát<br />
használva a feltételezett hibák mekkora<br />
részét fedtük le.<br />
45
Mértékszámok<br />
• Utasítás lefedettség:<br />
Az utasítások mekkora hányadát hajtottuk<br />
végre teszteléskor.<br />
• Ág lefedettség (döntés lefedettség):<br />
A CFG ágainak mekkora hányadát fedtük<br />
le (hajtottuk végre) teszteléskor.<br />
• Út lefedettség:<br />
A CFG-ban található utaknak mekkora<br />
hányadát fedtük le (hajtottuk végre)<br />
teszteléskor.<br />
SW tesztelés végrehajtása<br />
• SW tesztelését több fázisban hajtják<br />
végre.<br />
– Első fázis a modul tesztelés (unit<br />
testing).<br />
– Integrációs tesztelés.<br />
– Rendszerteszt.<br />
• Míg az első két fázis tipikusan<br />
verifikáció, addig a rendszertesztet<br />
általában validálására használják.<br />
46
Modul tesztelés<br />
• Unit testing.<br />
• A fázisban csak az egyes modulok<br />
specifikációját veszik alapul.<br />
• Különösen munkaigényes és emiatt<br />
költséges fejlesztési fázis.<br />
Modul tesztelés<br />
• A szoftvermodulok:<br />
– önálló specifikációval rendelkező,<br />
– más moduloktól függetlenül fordítható<br />
szoftver egységek.<br />
– Strukturált program esetén ezek<br />
lehetnek eljárások, függvények, ill. azok<br />
csoportja,<br />
– objektumorientált környezetben<br />
objektumok, ill. azok halmaza (clustere).<br />
47
Modul tesztelés<br />
• A modulok a kész rendszerben<br />
használják egymás szolgáltatásait,<br />
– pl. az egyik modul meghívja a másik<br />
modul adott függvényét. Ekkor azt<br />
mondjuk, hogy az egyik modul függ a<br />
másik modultól.<br />
– Modulok függősége grafikusan is<br />
ábrázolható.<br />
Modulok függősége<br />
• A modul például függ a B a C és D<br />
moduloktól.<br />
A<br />
B C D<br />
H<br />
E F<br />
G<br />
I J<br />
48
Modulok függősége<br />
• A tesztelő elkészíti azon modulok<br />
biztosan hibamentesen (a<br />
specifikációban leírt módon)<br />
viselkedő egyszerűsített változatát,<br />
melyektől a tesztelt modul (SUT)<br />
függ.<br />
• A szoftver modulok ilyen<br />
egyszerűsített megvalósítását<br />
nevezik stub-nak (csonknak).<br />
Teszt driver<br />
• A modulok tesztelése csak úgy<br />
történhet, ha azokat működtetjük,<br />
azok szolgáltatásait meghívjuk.<br />
– Ehhez létre kell hozni a megfelelő<br />
szoftver környezetet.<br />
• Teszt driver-nek nevezzük azt a<br />
szoftver elemet, mely a tesztelés<br />
során a tesztelt szoftvert működteti.<br />
49
Teszt driver<br />
• Feladata:<br />
– a tesztelt szoftver működtetése, annak<br />
bemeneti adatok biztosítása.<br />
– A szoftver driver általában megvalósítja<br />
a kimenetek eltárolását, ill. más, szoftver<br />
viselkedését jellemző információ<br />
összegyűjtését.<br />
Teszt driver<br />
• A stub-ok, ill. teszt drive-ek készítése:<br />
– legmunkaigényesebb, így<br />
legköltségesebb része a tesztelésnek.<br />
– Ha egy szoftver minden modulját<br />
önállóan szeretném tesztelni, akkor<br />
minden elemnek el kell készítenem a<br />
stub változatát, ill. minden elemhez<br />
készítenem kell egy teszt driver-t.<br />
• Az ilyen típusú tesztelés az izolációs<br />
tesztelés.<br />
50
Izolációs tesztelés<br />
teszt driver<br />
B C D<br />
tesztelt modul<br />
H<br />
E<br />
stub<br />
F<br />
stub<br />
I J<br />
Tesztelési költségek<br />
csökkentése<br />
G<br />
stub<br />
• A teszt driver-ek, ill. stub-ok készítése<br />
költséges.<br />
– Ezek készítését részben elkerülhetjük:<br />
• ha az amúgy is megvalósítandó szoftver moduljaimat<br />
használom driver-ként, ill. stub-ként.<br />
• Feltétlenül be kell tartanom a tesztelés azon<br />
szabályát, hogy tesztelés során a szoftvernek csak<br />
olyan komponensét használhatom (driver-ként<br />
vagy stub-ként), melynek helyes működése<br />
biztos, vagyis már átesett a tesztelésen.<br />
• Két alap technika létezik, a többi<br />
lényegében ezek finomítása:<br />
– top down tesztelés és<br />
– bottom up tesztelés.<br />
51
Top-down tesztelés<br />
• A teszt driver-ek készítése kerülhető<br />
el.<br />
• Teszt driver-ként mindig azokat a<br />
modulokat használom, melyek az<br />
adott tesztelés alatt álló modulomtól<br />
függenek.<br />
• Először mindig a hierarchia<br />
legmagasabb szintjén álló modulomat<br />
kell tesztelni, majd sorban az alatta<br />
levő modulokat.<br />
Top-down tesztelés<br />
B<br />
(tesztelve)<br />
H<br />
A<br />
driver (tesztelve)<br />
C<br />
(tesztelve)<br />
E<br />
stub<br />
D<br />
tesztelt modul<br />
F<br />
stub<br />
I J<br />
G<br />
stub<br />
52
Bottom-up tesztelés<br />
• A teszt stub-ok készítése kerülhető el.<br />
• Stub-ként mindig azokat a modulokat<br />
használom, melyektől az adott tesztelés<br />
alatt álló modulom függ.<br />
• A tesztelést a függőségi hierarchia legalsó<br />
szintjén kell elkezdeni azokkal a<br />
modulokkal, melyek nem függenek más<br />
moduloktól. Ezeket letesztelve léphetünk<br />
tovább a hierarchia következő szintjére.<br />
Bottom-up tesztelés<br />
teszt driver<br />
B C D<br />
tesztelt modul<br />
H<br />
(tesztelve)<br />
E<br />
(tesztelve)<br />
I<br />
(tesztelve)<br />
F<br />
(tesztelve)<br />
J<br />
(tesztelve)<br />
G<br />
(tesztelve)<br />
53
Tesztesetek definiálása<br />
• Teszteset azonosító:<br />
– a fejlesztési folyamat teljes menete során ezzel<br />
hivatkozhatunk a tesztesetre.<br />
– Fontos, hogy tényleg ne változzon.<br />
– Hibajelentések készítésekor, ill. teszt riportok<br />
összeállításakor látjuk hasznát. Regressziós<br />
tesztelésnél különösen hasznos.<br />
• A tesztelt szoftver elem azonosítása, ill. a<br />
tesztelt funkció, viselkedés azonosítása,<br />
leírása.<br />
• A tesztelt szoftver (SUT) teszteset<br />
végrehajtása előtt beállítandó állapotának<br />
leírása, szükség szerint a beállítás módja.<br />
Tesztesetek definiálása<br />
• Teszteset végrehajtásához szükséges<br />
bemeneti adatok.<br />
• Elvárt eredmény: hibamentes esetben várt<br />
kimenet, állapot, esetleg teljesítmény.<br />
• Teszteset végrehajtásának előfeltételei:<br />
– mely tesztesetet kell hibamentesen<br />
végrehajtani, ill.<br />
– mely teszteset által tesztelt funkcióra épül az<br />
aktuális teszteset.<br />
• A tesztelésnél alkalmazott szabványok<br />
előírhatnak további jellemzők megadását,<br />
pl. a teszteset definiálásakor alkalmazott<br />
tesztelési módszert.<br />
54
Integrációs tesztelés<br />
• A rendszer moduljait együtt tesztelik<br />
– nagy hangsúlyt fektetve a modulok<br />
együttműködésére,<br />
– interfészek vizsgálatára.<br />
Rendszerteszt<br />
• A teljes rendszert valós adatokkal<br />
valós környezetben tesztelik.<br />
55
Tesztadatok összeállításának<br />
szempontjai<br />
• adatok körének meghatározása:<br />
– napi adatok<br />
– szélsőséges adatok<br />
– tesztelési szintekhez eltérő adatok<br />
• tesztállományok összeállítása<br />
• elvárt eredmények meghatározása<br />
Tesztelés alapjai (terminológia)<br />
• teszt driver:<br />
– tesztelő rutin<br />
• teszt csonk (stub):<br />
– Tesztelt egység által használt más<br />
egység működését szimuláló rutin.<br />
• teszt eset: egy adott hiba<br />
felderítésére szolgáló teszt<br />
56
A programspecifikáció<br />
tartalma 1.<br />
1. a programrendszer célja<br />
– rendszercélok<br />
– HW, SW környezet specifikációuser interface<br />
tervek<br />
– menü- és struktúra tervek<br />
– adatbázis (külsőleg definiált)<br />
– tervezési feltételek<br />
2. Hivatkozott dokumentumok<br />
– szoftver dokumentáció<br />
– rendszerleírás<br />
– HW/SW szállítói információk<br />
– technikai referenciák<br />
A programspecifikáció<br />
tartalma 2.<br />
3. Tervezési specifikáció<br />
– adatleírás (típus, struktúra)<br />
– származtatott programstruktúra<br />
– struktúrán belüli interfészek<br />
4. Modulonkénti részletes specifikáció<br />
– feldolgozási eljárások<br />
– működési algoritmus leírása<br />
– interfészspecifikáció (input, output)<br />
– tervezési technológia<br />
– felhasználandó modulok, hívás módja<br />
– adatok köre és szervezési módja<br />
57
A programspecifikáció<br />
tartalma 3.<br />
5. File-szerkezetek, globális modell<br />
specifikáció<br />
– külső file-szerkezet: file-ok, rekordok, szervezési<br />
és elérési mód<br />
– globális adatok jegyzéke<br />
– file/adat kapcsolatok<br />
6. Folyamatok-modulok kapcsolatrendszere<br />
7. Tesztelési előírások, dokumentáció<br />
– tesztadatok, tesztelési utasítás<br />
– tesztelési stratégia, integrációs teszt<br />
– különleges előírások<br />
8. Programegységek létrehozása (package)<br />
– speciális átlapolás<br />
– átalakítási feltételek<br />
Átállás<br />
• Kísérleti futtatás<br />
• Fokozatos átállás<br />
• Párhuzamos feldolgozás<br />
• Azonnali átállás<br />
58
Átadás<br />
• Az átadás programja, forgatókönyv<br />
– Átadási információk<br />
– Az átadás programja<br />
– Különleges rendelkezések<br />
Átadási információk<br />
• Az átadás tárgya<br />
• Az átadás időpontja<br />
• Az átadás helye<br />
• Résztvevők<br />
• Az átadási anyagok<br />
– HW, SW dokumentáció, kézikönyvek<br />
• Elfogadási feltételek, átvételi<br />
kritériumok<br />
59
Az átadás programja<br />
• Bevezető tájékoztató<br />
• A rendszer bemutatása, elfogadási<br />
teszt (projektvezető és a megbízó)<br />
• Az elfogadási teszt kiértékelése<br />
(megbízó)<br />
• Döntés az elfogadásról<br />
• Jegyzőkönyv készítése<br />
60
Change language