3. A szoftverfolyamat alapvető

3.1 Szoftverspecifikáció (analízis)

3. A szoftverfolyamat alapvető tevékenységei

A követelmények tervezésének fázisai: 1. Megvalósíthatósági tanulmány készítése –

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)

Gyors gazdasági, műszaki elemzés a megvalósításra és az üzemeltetésre vonatkozóan

Követelmények feltárása és elemzése

2. –

Meglévő rendszerek vizsgálata, modellek, prototípusok készítése, konzultáció a megrendelővel

Követelmény specifikáció készítése

3. –

A rendszerkövetelmények és a felhasználói követelmények megfogalmazása, egységes dokumentumba foglalása

Követelmény validáció

4. –

BMF-NIK-SZTI

Tick: Szoftver Tervezés és Technológia

93

BMF-NIK-SZTI

Követelmények feltárása és elemzése

jellemzők: Követelmények validálása

Rendszermodellek

94

a.) Előzetes interjú módszer Követelmények specifikációja

Megvalósíthatósági jelentés


3.1.2 A specifiká specifikáció ciót tá támogató mogató techniká technikák

3.1.1 A kö követelmé vetelménytervezé nytervezés folyamata Megvalósíthatósági tanulmány

A követelmények valószerűségének, konzisztenciájának, teljességének vizsgálata, hibák keresése

Felhasználói és Rendszerkövetelmények

Követelmények dokumentumai

– – – –

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


95

BMF-NIK-SZTI


96

1

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?) BMF-NIK-SZTI


97

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.) BMF-NIK-SZTI


99

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


98

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


100

2

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) BMF-NIK-SZTI


101

A pontos specifiká 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

„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


103

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


102

l 1988-ban

rendszerbe állítva, 5 év repülés után … szeptember 14. Varsó, a Lufthansa 2940-es járata Frankfurt felől leszálláshoz készülődött …

l 1993.

… 2 halott, 45 sebesült … BMF-NIK-SZTI


104

3

Hogyan fordulhat elő elő, hogy egy 5 éve jól mű működő szoftver meghibá meghibásodik ?

3.2 Szoftvertervezés és implementáció 3.2.1 A tervezési folyamat tevékenységei:

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

1. Architekturális tervezés

BMF-NIK-SZTI

BMF-NIK-SZTI

l Időjárás:


105

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 Tick: Szoftver Tervezés és Technológia

106

3.2.2 A tervezé tervezési folyamat általá ltalános modellje 5. Adatszerkezet tervezés Követelmények specifikációja

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

Architekturális tervezés

Absztrakt specifikáció

Interfész tervezés

Komponens tervezése

Rendszerarchitektúra

Szoftverspecifikáció

Interfészspecifikáció

KomponensSpecifikáció

Adatszerkezet tervezése

Architektúraspecifikáció

Algoritmus tervezése

Algoritmusspecifikáció



107

BMF-NIK-SZTI


108

4

Absztrakció Absztrakció 3.2.3 A tervezé tervezés általá ltalános elvei

1. szint

(A problémára és környezetére orientáló megfogalmazás)

........

l Absztrakció l Finomítás

........

l Modularitás

(kohézió, csatolás) l Programszerkezet kialakítás l Információ rejté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


109

BMF-NIK-SZTI


110

Modularitá Modularitás

Finomí Finomítás A lépésenkénti finomítás módszerét Wirth ajánlotta 1971-ben.

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.

ha

Absztrakciós stratégiák:) l soros (egy strukturáló objektum van

Prof. Dr. Niclaus Wirth ETH Zürich Pascal, Oberon 8 egyetem díszdoktora

– tiszta (adatorietált, eljárás orientált,) – kereszt (pl. információs rendszerek) – ortogonális l


E(p1) > E(p2)

C(p1+p2) > C(p1) + C(p2) E(p1+p2) > E(p1) + E(p2)

(Tapasztalati képlet)

Ebből következik, hogy bontsuk szét sok apró, pici modulra a feladatot.

párhuzamos

BMF-NIK-SZTI

C(p1) > C(p2)

111

BMF-NIK-SZTI


112

5

ltséég költs

Probléma: nem lehet M-et előre megmondani.

A teljes szoftver kö költsé ltség alakulá alakulása a modularizá modularizálás függvé ggvényé nyében Költség/modul

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)

Interfész költség

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.)

„M”

Minimális költségek tartománya BMF-NIK-SZTI

modulok szá száma


113

A funkcionális függetlenség mérésére két jellemző szolgál: - kohézió - csatolás BMF-NIK-SZTI

Kohé Kohézió zió


114

Csatolá 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 csatolás a modul kapcsolatának intenzitását, erősségét fejezi ki más modulokhoz (adat és vezérlési kapcsolat).

A kohézió egy spektrumként fogható fel a gyengétől az erősig.

Egy spektrumként adható meg a laza csatolástól a szoros csatolásig.

Törekedni kell e minél erősebb kohézióra.

Törekedni kell a minél lazább csatolás kialakítására.

BMF-NIK-SZTI


115

BMF-NIK-SZTI


116

6

Programszerkezet kialakí kialakítás Ajánlások a programszerkezet kialakításánál:

Fan-out

mélység

l l l

Minimalizálni kell a fan-outokat és fan-ineket A mélység és a szélesség ne legyen 7-8-nál nagyobb Törekedni kell az egy bemenetű és egy kimenetű modulokra

Fan-in szélesség

BMF-NIK-SZTI


117

BMF-NIK-SZTI

Informá Információ ció rejté rejtés

l Adatszerkezet


orientált

– JSP (Jackson) l Adatfolyam David L. Parnas

orientált

– SA (DeMarco), SD (Yourdon, Constantine, l Objektum

orientált

– OOSE (Jacobson), OMT (Raumbught & all), UML (Raumbught, Booch, Jacobson)

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) BMF-NIK-SZTI

118

3.2.4 Tervezé Tervezési mó módszerek

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.


119

BMF-NIK-SZTI


120

7

Alapszerkezetek

Jackson Structured Programming Michael A. Jackson publikálta 1974-ben

Szekvencia

Struktúráló objektum: adattér Strukturáló szempont: szemantikus szint

A

Alkalmazott elvek: Michael A. Jackson 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: szerkezeti ábra (a program- és adatszerkezethez) l funkcionális leírás (pszeudokód szerű) a programszerkezet leírásához l

BMF-NIK-SZTI


121

Szelekció

A seq A1 A2 A3 A end BMF-NIK-SZTI

A2

Adatszerkezetnél: pl: rekord

A3

Programszerkezetnél: egymásután végrehajtandó műveletek


122

Iteráció A

A1

A2

A select – feltétel A1 A or A2 A end

A

A

A1

A1

A select - feltétel A1 A end


*

A iter while – feltétel A1 A end Adatszerkezetnél: fájl Programszerkezetnél: ciklus

Adatszerkezetnél: változó rekord Programszerkezetnél: feltételes utasítás BMF-NIK-SZTI

A1

123

BMF-NIK-SZTI


124

8

Példa:

Egy pé példa a jelö jelölésrendszer haszná használatá latára A

B

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:

C

D

E

H

F

I

G

*

Név: …….. …….. …….. ……..

*

J

BMF-NIK-SZTI

Egyetemi végzettségű dolgozók:

K

Cím: …….. …….. …….. ……..

A …….. Dolgozóból egyetemet végzett ……..


125

BMF-NIK-SZTI


126

A bemenő bemenő adatszerkezet terve

A kimenő kimenő adatszerkezet terve

TÖRZS

LISTA

REKORDOK

REKORD

EGYETEMI VÉGZ.

BMF-NIK-SZTI

FEJSOROK

*

REKORD

NEM EGYET. VÉGZ.


LISTA TEST

ZÁRÓSOR

*

EGYETEMI VÉGZ.

127

BMF-NIK-SZTI


128

9

A programszerkezet kialakí kialakításának menete

A programszerkezet terve LISTA

Bemenő adatszerkezet

Programszerkezet

Kimenő adatszerkezet ELŐKÉSZÍTÉS

FELDOLGOZÁS

BEFEJEZÉS

*

REKORD FELDOLG.

EGYETEMI VÉGZ.

BMF-NIK-SZTI


129

BMF-NIK-SZTI

NEM EGYET. VÉGZ.


130

A mó módszer tervezé tervezési lé lépései 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

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)

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. BMF-NIK-SZTI


131

BMF-NIK-SZTI


132

10

Strukturá Strukturált analí 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

Process

Folyamat (Információ transzformációt hajt végre)

Adat

Adat elem vagy azok gyűjtő fogalma A nyíl mutatja az információ áramlás irányát.

BMF-NIK-SZTI

Tom Demarco

Adat tároló


133

Inpu t inf

t in Inpu

f

External entity

outpu

External entity

A DFD az információ áramlását írja le, nem blokk diagram! (sorrendiséget nem tartalmaz)

t inf

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. BMF-NIK-SZTI

134

f ut in outp

Computer Based System 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.)

0-s szintű DFD External entity

BMF-NIK-SZTI

Adat tároló (tetszőleges típusú, stacktől adatbázisig)


135

A DFD-t finomítjuk, a buborékokat felvágjuk. (meddig finomítunk, melyek a finomítás szabályai)

BMF-NIK-SZTI


136

11

Példa: SafeHome system

A DFD-t kiegészítjük két leírással:

0-ás szintű DFD

a.) Data Dictionary, Adatszótár (DD)

Control panel

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)

Display information

User commands and data

Alarm type

SafeHome Software

Sensors

Telephone number tones

Sensor status

Control Panel display

Alarm

Telephone line

R. S. Pressman: Software Engineering (third edition) Tick: Szoftver Tervezés és Technológia

1-es szintű DFD Configure request

Password Process password

Sensors

ID Valid ge sa mes

Sensor status

Ac t iv nfig te ate ura m /de es a dat tion a sa cti ge va

Start/ stop

Co

Interact With user

Display Messages and status

or n ns Se atio m r o inf

Monitor sensors

m Alar type


Control Panel display


Format for display

Asses against set-up Sensor ID type

Sensor information

Alarm data

sor Sen s statu

Generata Alarm signal

Alarm type

Te le nu pho mb ne er

Dial phone

Alarm

Telephone line

138

Sensor ID type, location

Configuration data

lay n sp tio Di rma o inf

R. S. Pressman: Software Engineering (third edition) BMF-NIK-SZTI


Configuration info

Configuration info Activate/ Deactivate system

User commands and data

BMF-NIK-SZTI

2-es szintű DFD

Configure Configuration data system

figur ati data on

Control panel

137

Con

BMF-NIK-SZTI

Read sensors


R. S. Pressman: Software Engineering (third edition) 139

BMF-NIK-SZTI


140

12

Adatfolyam orientá orientált „Tranzakció” tervezé tervezés

Strukturá Strukturált tervezé tervezés (SD) Constantine, Myers, Steven nyomán Constantine és Yourdon dolgozta ki. Alapmű: E. Yourdon, L. Constantine: Structured Design, Prentice-Hall 1979

Edward Yourdon

Alkalmazhatóság: igen széleskörű, hiszen a problémák jelentős része leírható információáramlással (DFD)

Tranzakció központ és adat elérési út azonosítása

Bejövő/kimenő kötegek azonosítása

Tranzakciós szerkezet leképezése

Szerkezet leképezése

Tranzakció analízis

Transzformáció analízis

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

Larry Constantine Tick: Szoftver Tervezés és Technológia

„Transzformáció”

Folyam típusa

Szerkezet faktorizálása

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.) BMF-NIK-SZTI

DFD finomítása

141

Részletes tervezés R. S. Pressman: Software Engineering (third edition) BMF-NIK-SZTI

Tervezé Tervezési heurisztiká heurisztikák


142

Példa: SafeHome

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 R. S. Pressman: Software Engineering (third edition) BMF-NIK-SZTI


143

BMF-NIK-SZTI


144

13

Példa: SafeHome

3.3 Programozá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


I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 145

A programozá programozásná snál is ügyelni kell …

BMF-NIK-SZTI


146

A NASA belső vizsgálata a következőket állapította meg:

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 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).

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.

Í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


147

BMF-NIK-SZTI


148

14

3.4 Szoftvervalidáció (tesztelés)

3.4.1 A szoftver tesztelési folyamat

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).

Egységteszt

Modulteszt

Alrendszerteszt

Rendszerteszt

Átvételiteszt

Komponens tesztelés

Integrációs tesztelés

Felhasználói tesztelés



149

3.4.2 A tesztelé tesztelési fá fázisok a szoftver folyamatban Követelmények meghatározása

Rendszerspecifikáció

Átvételi teszt terve

Szolgáltatás

Rendszertervezés

Rendszerintegrációs teszt terve

Átvételi teszt

RendszerIntegrációs teszt


150

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.

Modul és EgységKódolás, és -tesztelés

AlrendszerIntegrációs teszt

Átvételi teszt terve

Szolgáltatás



Az átvételi tesztet szokás „alfa tesztnek” is nevezni.

Részletes tervezés

Alrendszerintegrciós teszt terve

BMF-NIK-SZTI

„béta teszt”

Rendszerintegrációs teszt terve

Átvételi teszt „alfa teszt”

RendszerIntegrációs teszt

I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 151

BMF-NIK-SZTI


152

15

3.5 Szoftverevolúció (szoftver karbantartás, szoftver követés)

3.5.1 A rendszer evolú 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.

Rendszerkövetelmények meghatározása

Meglévő rendszerek értékelése

Rendszerváltozások előterjesztése

Rendszerek módosítása

Az újabb felfogás szerint a kettő szerves egységet alkot és inkább a szoftver evolúciójának fogható fel. Meglévő rendszerek

Új rendszer



153

BMF-NIK-SZTI


154

16

3. A szoftverfolyamat alapvető

Recommend Documents