3. A szoftverfolyamat alapvető

3. A szoftverfolyamat alapvető tevékenys kenységei 3.1 Szoftverspecifikáció (Analízis) 3.2 Szoftver tervezés és implementáció 3.3 Programozás és tesztelés 3.4 Szoftver validáció (tesztelés) 3.5 Szoftverevolúció (karbantartás, követés) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 93 3.1 Szoftverspecifikáci ció (analízis) A követelmények tervezésének fázisai: 1. Megvalósíthatósági tanulmány készítése Gyors gazdasági, műszaki elemzés a megvalósításra és az üzemeltetésre vonatkozóan 2. Követelmények feltárása és elemzése Meglévő rendszerek vizsgálata, modellek, prototípusok készítése, konzultáció a megrendelővel 3. Követelmény specifikáció készítése A rendszerkövetelmények és a felhasználói követelmények megfogalmazása, egységes dokumentumba foglalása 4. Követelmény validáció A követelmények valószerűségének, konzisztenciájának, teljességének vizsgálata, hibák keresése BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 94 3.1.1 A követelmk vetelménytervezés s folyamata 3.1.2 A specifikáci ciót t támogatt mogató technikák Megvalósíthatósági tanulmány Megvalósíthatósági jelentés Követelmények feltárása és elemzése Rendszermodellek Követelmények specifikációja Felhasználói és Rendszerkövetelmények Követelmények validálása Követelmények dokumentumai a.) Előzetes interjú módszer jellemzők: a személyek nem ismerik egymást tartanak a félreértésektől hatnak esetleges régi rossz tapasztalatok ugyanakkor mindkét fél sikerorientált Az előzetes interjú célja a jég megtörése. I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 95 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 96

Módszer: -először kötetlen beszélgetés, informálódás a rendszer alapvető kérdései iránt. (Ki fogja használni a rendszert? Mi lesz az előnye a rendszer használatának?) - ezután a rendszer jellemzőivel kapcsolatos kérdéskör kerül elő (Hogy jellemezné, milyen ismereteket kell majd magánviselnie az elkészült rendszernek? Milyen környezetben kell majd üzemelnie a rendszernek?) - A harmadik kérdéscsoport az interjú hatékonyságára irányul. (Lényegretörő kérdéseket tettem fel? Van valami, amit meg kellen még kérdeznem?) b.) FAST (Facilitated Application Specification Techniques) Probléma: A megrendelő és a vevő tudat alatt mi és ők csoportokat képez és ebben gondolkodik. Nem alakul ki igazi team munka (félreértések, lényeges info elvész, stb.) Megoldás: FAST Az analízis és specifikáció korai fázisát, az információ gyűjtést támogató team-orientált szisztematikus módszer. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 97 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 98 Lényege: A felhasználók és fejlesztők közös teamet hoznak létre a probléma identifikációjára, a megoldás elemeinek kijelölésére, a megoldással szemben támasztott követelmények előzetes meghatározására. Alapvető jellemzők: - Az üléseket semleges fél vezesse - Az ülés előkészítésének, a meghívottak köre kialakításának szabályai rögzítve legyenek - a napirend rögzítse a teendőket, de adjon lehetőséget az ötletek szabad kifejtésére - Elnököt kell kijelölni az ülés irányítására - Definíciós mechanizmus használata ajánlott (táblázat, tábla, Pinwand stb.) FAST-ülés előkészítése: minden résztvevőt megkérnek, hogy készítsen: - a rendszert körülvevő környezet objektumainak listája - a rendszert alkotó objektumok listája - azon eljárások, f.vények listája, amelyek manipulálják ezen objektumokat. - kényszerfeltételek és működési kritériumok listája (a listáknak nem kell komplettnek lenni) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 99 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 100

Alkalmazott módszertan az üléseken: 1.) az első ülésen minden résztvevőnek igazolnia kell a termék szükségességét 2.) az elkészített listák ismertetése Pinn-wall, vagy mágnes tábla használata, a listaelemek csoportosíthatók, áthelyezhetők legyenek, kiegészítések legyenek lehetségesek (A vita tilos!) 3.) az ismertetett listák vitája, új ötletek felvétele a táblára, de törölni tilos, redundanciák összevonása 4.) konszenzusos lista vitával való kialakítása, törlés is és módosítás is megengedett (eredmény: konszenzusos lista) 5.) Rész-teamek képzése, minispecifikációk elkészítése, minden egyes elemre. 6.) A rész-teamek bemutatják az általuk elkészített minispecifikációkat. (Itt felvetődhetnek új objektumok, kényszerfeltételek, funkciók, stb) Vita a listákról, megoldatlan problémák listájának felvétele. 7.) A minispecifikációk elkészülte után a részteamek elkészítik a validációs kritériumokra tett javaslatokat. 8.) Az eddigi ülések anyagaiból egy kijelölt csoport összeállítja a specifikációt. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 101 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 102 A pontos specifikáci ció nagyon fontos! Az Airbus A320 fedélzeti szoftverének specifikációja szerint a repülőgép fékezőrendszer működésének logikája: l 1988-ban rendszerbe állítva, 5 év repülés után l 1993. szeptember 14. Varsó, a Lufthansa 2940-es járata Frankfurt felől leszálláshoz készülődött l földön" = mindkét főkeréken a nyomás legalább 12 tonna l sugárfék engedélyezve" = földön" l kerék fék engedélyezve" = Ha legalább az egyik főkerék sebessége nagyobb 72 csomónál" vagy ( főldőn" és a rádiós magasságmérő 3 méternél kisebb távolságot mutat a főldtől" ) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 103 2 halott, 45 sebesült BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 104

Hogyan fordulhat elő,, hogy egy 5 éve jól l működőm szoftver meghibásodik? l Időjárás: viharos eső, szél 160 fokról 25 Km/h, vastag vízréteg a kifutón (aquaplaning) l A pilóták a szabványos eljárást alkalmazták (emelt sebesség, enyhe jobbra döntés) l A jobboldali kerekek értek földet először és csak 9 másodperccel később a bal oldaliak. l 9 másodpercig semmilyen fék nem működött l A bal oldali kerekek teljes leérkezése után léptek működésbe a fékek 3.2 Szoftvertervezés és s implementáci ció 3.2.1 A tervezési folyamat tevékenységei: 1. Architekturális tervezés A rendszert alkotó alrendszerek és azok kapcsolatainak azonosítása, dokumentálása 2. Absztrakt specifikáció Minden egyes alrendszer szolgáltatásainak absztrakt specifikálása, peremfeltételekkel, megszorításokkal együtt 3. Interfész tervezés Minden egyes alrendszer interfészének megtervezése, dokumentálása 4. Komponens tervezés A szolgáltatások komponensekhez rendelése, a komponensek interfészének meghatározása BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 105 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 106 5. Adatszerkezet tervezés A rendszer implementációjában használt adatszerkezetek részletes tervezése 6. Algoritmus tervezés A szolgáltatások biztosításához szükséges algoritmusok részletes megtervezése 3.2.2 A tervezési folyamat általános modellje Követelmények specifikációja Architekturális tervezés Absztrakt specifikáció Interfész tervezés Komponens tervezése Rendszerarchitektúra Adatszerkezet tervezése Algoritmus tervezése BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 107 Szoftverspecifikáció Interfészspecifikáció Kompo- nens- Specifikáció Architektúraspecifikáció Algoritmusspecifikáció I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 108

3.2.3 A tervezés általános elvei l Absztrakció l Finomítás l Modularitás (kohézió, csatolás) l Programszerkezet kialakítás l Információ rejtés...... Absztrakció 1. szint (A problémára és környezetére orientáló megfogalmazás) n. szint (procedurális orientációjú leírás) Az absztrakció segít koncentrálni a lényegesre, elhanyagolva a lényegtelent, mindhárom területen alkalmazható (data design, procedual design, architectural design) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 109 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 110 Finomítás A lépésenkénti finomítás módszerét Wirth ajánlotta 1971-ben. Modularitás p1 - probléma; c(p) - a probléma komplexitása E(p) - a megoldáshoz szükséges ráfordítás (pl: költség) Párhuzamosan finomítható program és adatszerkezet (pl: rendezés). a finomítás a funkcionális primitívekig tart. Minden finomítási lépés egy-egy döntést igényel. (strukturáló objektum és szempont. Absztrakciós stratégiák:) l soros (egy strukturáló objektum van tiszta (adatorietált, eljárás orientált,) kereszt (pl. információs rendszerek) ortogonális l párhuzamos Prof. Dr. Niclaus Wirth ETH Zürich Pascal, Oberon 8 egyetem díszdoktora ha C(p1) > C(p2) C(p1+p2) > C(p1) + C(p2) E(p1+p2) > E(p1) + E(p2) E(p1) > E(p2) (Tapasztalati képlet) Ebből következik, hogy bontsuk szét sok apró, pici modulra a feladatot. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 111 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 112

költs ltség A teljes szoftver költsk ltség g alakulása a modularizálás függvényében Költség/modul Interfész költség M Probléma: nem lehet M-et előre megmondani. A modulok mérete (és így a száma) függ a feladat jellegétől nem lehet a modulokat ész nélkül szétbontani (funkcionalitás, integritás, kohézió, csatolás) Az effektív modularizálás (modulokra bontás) titka a funkcionális függetlenség. Ez azt jelenti, hogy jól körbe kell tudni határolni azon területet, amely egy modulba vonva logikusan összekapcsolódik és nem kommunikál sokat a külvilággal. (A másik szempont, hogy ezek aránylag egyszerű funkciók legyenek.) Minimális költségek tartománya modulok száma A funkcionális függetlenség mérésére két jellemző szolgál: -kohézió -csatolás BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 113 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 114 Kohézi zió Csatolás A kohézió a modul kompaktságát, integritását, feladatorientált tisztaságát, belső összetartását ill. homogenitását (a feladat szempontjából) fejezi ki. A kohézió egy spektrumként fogható fel a gyengétől az erősig. Törekedni kell e minél erősebb kohézióra. A csatolás a modul kapcsolatának intenzitását, erősségét fejezi ki más modulokhoz (adat és vezérlési kapcsolat). Egy spektrumként adható meg a laza csatolástól a szoros csatolásig. Törekedni kell a minél lazább csatolás kialakítására. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 115 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 116

Programszerkezet kialakítás Fan-out Ajánlások a programszerkezet kialakításánál: mélység l Minimalizálni kell a fan-outokat és fan-ineket l A mélység és a szélesség ne legyen 7-8-nál nagyobb l Törekedni kell az egy bemenetű és egy kimenetű modulokra Fan-in szélesség BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 117 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 118 Informáci ció rejtés 1972-ben Parnas publikálta az információ rejtés fogalmát. Lényege: A program elemek (modulok) csak az interfészen keresztül kapcsolódnak a külvilághoz. Belső változók, rutinok, eljárások nem érhetők el a külsők számára. Előnye: l Jól definiált interfész l Minőségi biztonság modulok cseréje, javítása esetén (a hiba is be van zárva) David L. Parnas 3.2.4 Tervezési módszerekm l Adatszerkezet orientált JSP (Jackson) l Adatfolyam orientált SA (DeMarco), SD (Yourdon, Constantine, l Objektum orientált OOSE (Jacobson), OMT (Raumbught & all), UML (Raumbught, Booch, Jacobson) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 119 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 120

Jackson Structured Programming Michael A. Jackson publikálta 1974-ben Struktúráló objektum: adattér Strukturáló szempont: szemantikus szint Szekvencia Alapszerkezetek A Alkalmazott elvek: l a probléma hierarchikus (top-down) lebontása l a lépésenkénti finomítás módszere l kizárólag elemi részgráfok alkalmazása (Böhm és Jacopini tétel alapján: szekvencia, szelekció és iteráció használata) Alkalmazott formalizmusok: l szerkezeti ábra (a program- és adatszerkezethez) l funkcionális leírás (pszeudokód szerű) a programszerkezet leírásához Michael A. Jackson BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 121 A1 A2 A3 Aseq Adatszerkezetnél: Programszerkezetnél: A1 pl: rekord egymásután végrehaj- A2 tandó műveletek A3 Aend BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 122 Szelekció Iteráció A A A A1 A2 A1 A select feltétel A1 A or A2 Aend Adatszerkezetnél: változó rekord Programszerkezetnél: feltételes utasítás A select - feltétel A1 A end BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 123 A iter while feltétel A1 A end Adatszerkezetnél: fájl Programszerkezetnél: ciklus A1 * BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 124

Egy példa p a jelölésrendszer használat latára Példa: A B C D E F H I G * * Adott a TÖRZS nevű bemenő állomány, mely rekordjának felépítése: név, cím, iskolai végzettség kódja Tervezzünk programot, amely kilistázza az egyetemet végzett dolgozók (iskolai végzettség kódja = E) nevét, címét és számát az alábbi formában: Egyetemi végzettségű dolgozók: Név: Cím:................ J K A.. Dolgozóból egyetemet végzett.. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 125 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 126 A bemenő adatszerkezet terve TÖRZS A kimenő adatszerkezet terve LISTA REKORDOK FEJSOROK LISTA TEST ZÁRÓSOR REKORD * REKORD * EGYETEMI VÉGZ. NEM EGYET. VÉGZ. EGYETEMI VÉGZ. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 127 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 128

A programszerkezet kialakításának menete A programszerkezet terve Bemenő adatszerkezet Programszerkezet Kimenő adatszerkezet LISTA ELŐKÉSZÍTÉS FELDOLGOZÁS BEFEJEZÉS REKORD FELDOLG. * EGYETEMI VÉGZ. NEM EGYET. VÉGZ. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 129 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 130 A módszer m tervezési lépéseil 1. Az adatszerkezetek elkészítése A feladat szövegének elemzése alapján elkészítjük a bemenő és kimenő adatszerkezeteket a három alapelem (szekvencia, szelekció, iteráció) segítségével. (Annyi bemenő és kimenő adatszerkezetet ábrázolunk, ahány fizikailag létező állomány van. Sorrend nem számít.) 2. A programszerkezet elkészítése az adatszerkezet alapján 3. A tevékenységek összeállítása "összeírjuk" az összes felmerülő tevékenységet valamint feltételt és sorszámmal látjuk el. 4. A tevékenységek elhelyezése a programszerkezetben Meg kell keresni azt a programelemet, amelyhez az adott tevékenység a legközelebb áll. 5. A funkcionális leírás elkészítése Leírjuk a teljes programot (pszeudókódban) a célnyelvtől független formában (konkrét tevékenységeket, feltételeket, logikai kapcsolatokat tartalmaz) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 131 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 132

Strukturált analízis (SA) Data Flow Diagram (DFD) Demarco 1979-ben fektette le az alapjait (foglalta össze) External Entity külső egyed (információ forrás vagy nyelő) Jellemzői: 20 éves fejlődési folyamat eredménye modellezési technika - adat és vezérlési áramlást és tartalmat ír le - a funkcionalitás és viselkedés szerint particionál Tom Demarco Process Adat Adat tároló Folyamat (Információ transzformációt hajt végre) Adat elem vagy azok gyűjtő fogalma A nyíl mutatja az információ áramlás irányát. Adat tároló (tetszőleges típusú, stacktől adatbázisig) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 133 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 134 0-s szintű DFD External entity External entity Input inf Input inf Computer Based System output inf output inf External entity External entity A DFD egyértelműen maghatározza, melyek a külső egyedek, mi az, ami része a rendszernek és mi az, ami nem. (Hol vannak a rendszer határai.) A DFD az információ áramlását írja le, nem blokk diagram! (sorrendiséget nem tartalmaz) A 0-s szintű DFD csak egy buborékot tartalmaz, ami nem más, mint a rendszer szoftver. Ezt szokás még: Context model, vagy Fundamental system Model-ként is nevezni. A DFD-t finomítjuk, a buborékokat felvágjuk. (meddig finomítunk, melyek a finomítás szabályai) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 135 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 136

A DFD-t kiegészítjük két leírással: Példa: SafeHome system a.) Data Dictionary, Adatszótár (DD) 0-ás szintű DFD b.) Process Specification (PSPEC) A folyamat szöveges megfogalmazása. (Algoritmust, megszorításokat, és egyéb részleteket tartalmazó kiegészítő leírás.) (A PSPEC megadásának formái) Control panel Sensors User commands and data Sensor status SafeHome Software Display information Alarm type Telephone number tones Control Panel display Alarm Telephone line BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 137 R. S. Pressman: Software Engineering (third edition) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 138 1-es szintű DFD Control panel User commands and data Sensors Password Configure request Interact With user Process password Sensor status Configure system Activate/ Deactivate system Start/ stop Valid ID message Monitor sensors R. S. Pressman: Software Engineering (third edition) Configuration data Activate/deactiva te message Configuration data Configuration info Sensor information Configuration data Display Messages and status Alarm type Telephone number tones Control Panel display Display information Telephone line BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 139 Alarm 2-es szintű DFD Configuration info Configuration data Sensor status Sensor ID type Asses against set-up Read sensors Format for display Sensor ID type, location Alarm data Telephone number R. S. Pressman: Software Engineering (third edition) Sensor information Generata Alarm signal Dial phone Alarm type Telephone number tones BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 140

Strukturált tervezés s (SD) Constantine, Myers, Steven nyomán Constantine és Yourdon dolgozta ki. Alapmű: E. Yourdon, L. Constantine: Structured Design, Prentice-Hall 1979 Alkalmazhatóság: igen széleskörű, hiszen a problémák jelentős része leírható információáramlással (DFD) A DFD típusai: 1.) transzformáció folyam (bejövő folyam - transzformációs folyam - kimenő folyam) 2.) tranzakció folyam (egy tigger adat tranzakciókat indít el lásd.) Edward Yourdon Larry Constantine BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 141 Adatfolyam orientált tervezés Tranzakció központ és adat elérési út azonosítása Tranzakciós szerkezet leképezése Tranzakció analízis Tranzakció DFD finomítása Folyam típusa Szerkezet faktorizálása Bejövő/kimenő kötegek azonosítása Szerkezet leképezése Szerkezet finomítása a tervezési heurisztikákkal Interfész és globális adatszerkezet leírások elkészítése Ellenőrzés Részletes tervezés R. S. Pressman: Software Engineering (third edition) Transzformáció Transzformáció analízis BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 142 Tervezési heurisztikák 1.) A programszerkezet kialakításakor vegyük figyelembe a csatolást és a kohéziót /modulok (funkciók) összevonása, szétválasztása/. 2.) Kerüljük a nagy Fan-Out-tal rendelkező szerkezeteket. Inkább a kiegyensúlyozott, arányos szerkezetekre törekedjünk 3.) A hatást kiváltó modul vezérlési körében legyen az a modul, amire hatással van. 4.) A modul-interfészek komplexitásának csökkentésére, a konzisztencia növelésére kell törekedni. 5.) Törekedjünk emlékezet nélküli modulok kialakítására (azonos inputra mindig azonos választ ad). 6.) Törekedjünk az egy bemenet-egy kimenet modulok létrehozására. 7.) A modulok csoportosítása különböző kényszer feltételek miatt. pl.: portabilitás BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 143 Példa: SafeHome R. S. Pressman: Software Engineering (third edition) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 144

Példa: SafeHome 3.3 Programozás és s tesztelés A programozás lépései A programozás dokumentumai A tesztelés fajtái A tesztelés menete A tesztelés dokumentumai Hiba behatárolása Hibajavítás megtervezése Hiba kijavítása Program újratesztelése A szoftver belövési folyamata R. S. Pressman: Software Engineering (third edition) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 145 I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 146 A programozásn snál l is ügyelni kell 1999. szeptember 23-án 9 hónapig tartó, több mint 190 millió Km utazás után a NASA mars szondája elérte a vörös bolygót. A telemetria vétele után a földről elküldött parancssorozat alapján a szonda mars körüli pályára kezdett állni. A folyamatos telemetria adatok rendben voltak. A NASA belső vizsgálata a következőket állapította meg: A mars szonda szoftverén két team dolgozott. A kódolás fázisában az egyik team az angol mértékegységeket használta (inch, láb, mérföld, font) a másik team a metrikus rendszert (cm, m, km, kg). Így amikor a földön a telemetriától 125 mérföld felszín feletti magasságot kaptak, akkor az valójában 125 Km volt. A parancssorozatban kiküldött rossz paraméterek következtében a szonda megsemmisült. 5 perc után a szonda eltűnt és soha nem sikerült vele kapcsolatot teremteni BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 147 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 148

3.4 Szoftvervalidáci ció (tesztelés) s) A tesztelési folyamat szakaszai : l Egység teszt (a rendszerkomponensek egymástól független tesztelése [tesztágy szükségessége]). l Modul teszt (az egymástól függő komponensek egységbe zárt rendszerének önálló tesztelése). l Alrendszer teszt (az alrendszert alkotó modulok egymás közötti kapcsolatának ellenőrzése [tipikus az interfész probléma]) l Rendszer teszt (az alrendszerek integrált egysége az alrendszer. Tesztelése során az alapvető rendszertulajdonságok vizsgálata történik). l Átvételi teszt (a rendszer tesztelése valódi adatokkal, az előre rögzített vakidációs kritériumok teljesülésének ellenőrzése). BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 149 3.4.1 A szoftver tesztelési si folyamat Egységteszt Modulteszt Alrendszerteszt Rendszerteszt Átvételiteszt Komponens tesztelés Integrációs tesztelés Felhasználói tesztelés I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 150 3.4.2 A tesztelési si fázisok f a szoftver folyamatban Követelmények meghatározása Rendszerspecifikáció Rendszertervezés Részletes tervezés Az átvételi tesztet szokás alfa tesztnek is nevezni. Egyedi megrendelő esetén az alfa teszt a megrendelő bevonásával történik. Nem egyedi szoftverek esetében az alfa tesztet általában egy béta teszt is követi. Átvételi teszt terve Rendszerintegrációs teszt terve Alrendszerintegrciós teszt terve Modul és Egység- Kódolás, és -tesztelés Átvételi teszt terve Rendszerintegrációs teszt terve Szolgáltatás Átvételi teszt Rendszer- Integrációs teszt Alrendszer- Integrációs teszt Szolgáltatás béta teszt Átvételi teszt alfa teszt Rendszer- Integrációs teszt I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 151 I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 152

3.5 Szoftverevolúci ció (szoftver karbantartás, szoftver követés) 3.5.1 A rendszer evolúci ciójának folyamata A hagyományos szemlélet szerint a fejlesztés és a karbantartás két élesen elkülönülő tevékenység. Az újabb felfogás szerint a kettő szerves egységet alkot és inkább a szoftver evolúciójának fogható fel. Rendszerkövetelmények meghatározása Meglévő rendszerek értékelése Rendszerváltozások előterjesztése Rendszerek módosítása Meglévő rendszerek Új rendszer BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 153 I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 154