Üzembehelyezési ismeretek. Literáti Pál

Átírás

1 Üzembehelyezési ismeretek Literáti Pál

2 Szoftver Szoftver (angol: software) alatt a legszűkebb értelemben elektronikus adatfeldolgozó berendezések (például számítógépek) memóriájában elhelyezkedő, azokat működtető programokat értünk. (Körülbelül ez volt a John W. Tukey által 1958-ban bevezetett angol software kifejezés eredeti értelme is.) A szoftver nemcsak elektronikus memóriatartalomként realizálódik, hanem életciklusának megfelelően többféle formában jelenik meg, fogalma ezekre a megvalósulási formákra is kiterjed, így a szoftver fogalmába tágabb értelemben beletartozik: az összes fejlesztési dokumentáció (mint például a forráskód); az összes felhasználói dokumentáció (mint például a felhasználói kézikönyv); az összes kereskedelmi dokumentáció (mint például a licenc); illetve az ezek bármelyikét tartalmazó adathordozók (mint például a telepítő CD vagy a nyomtatott számla). Az összetett feladatok elvégzésére kifejlesztett, egymással szoros kapcsolatban álló, önállóan is működőképes, de együttesen hatékonyabb és teljesebb támogatást nyújtó, éppen ezért teljes életciklusuk során együtt kezelt szoftverek csoportját programcsomagnak nevezzük. Szoftvercsoportosítások: Szoftverek funkciójuk szerint o Rendszerszoftverek o Alkalmazói szoftverek Szoftverek kereskedelmi kategóriái szerint Szoftver életciklusa szerint

3 Szoftvercsoportosítások Szoftverek funkciójuk szerint A programvezérelt gépek célszerű működését a szoftverek több rétege biztosítja. Aszerint, hogy egy szoftver specifikusan mennyire inkább a gép puszta működtetését, avagy az ember által igényelt feladatmegoldást segíti elő, a következő funkcionális csoportokat különböztetjük meg: indítóprogram vagy alapszoftver a felhasználó által a legkevésbé manipulálható, a gép üzemszerű működését beállító program(ok), ide tartozik a firmware is; rendszerszoftverek a gép és perifériái kommunikációját lebonyolító programok, beleértve a felhasználó oly mértékű kiszolgálását, amely lehetővé teszi a számára más szoftverek elkészítését és üzembe helyezését is; alkalmazói szoftverek vagy alkalmazások a felhasználót a számítógép használatán túl mutató céljainak elérésében támogató specifikus programok. Alapszoftver (Firmware): A firmware (angol: a.m. gyári beépített szoftver) egy olyan szoftverfajta, amely a hardvereszközbe van beépítve, és a hardver működtetéséhez szükséges legalapvetőbb feladatokat látja el (esetleg figyeli az eszköz állapotát, arról információkat nyújt a külvilágnak). Példák fimware-re: a személyi számítógépek BIOS-a, Open Firmware az Apple Macintosh számítógépekben, CD/DVD-meghajtók ROM áramkörök programjai, EPROM chipek programjai, amelyek speciális külső eszközzel módosíthatók, de szoftveresen nem. A firmware bizonyos eszközökben szoftveres úton is frissíthető, például a PC vagy néhány videokártya BIOS-a stb. Rendszerszoftverek: Operációs rendszerek Meghajtó programok (driverek) Segédprogramok o Fájlkezelők o Szövegszerkesztők (editorok) o Tömörítők Fejlesztési környezetek o Fordítóprogramok (compilerek) o Értelmezők (interpreterek) és futtatókörnyezetek o Nyomkövetők és hibakeresők (debuggerek) o Programszerkesztők (linkerek) Alkalmazói szoftverek: Irodai szoftverek

4 o Szervezőprogramok o Prezentációkészítők o Kiadványszerkesztők o Táblázatkezelők Üzleti alkalmazások o Számlázó programok o Könyvelő programok o Adatbázis-kezelők o Vállalatirányítási rendszerek Tervezőrendszerek o CAD-rendszerek Grafikai szoftverek o Rajzprogramok o Képszerkesztők Média szoftverek o Médialejátszók o Médiaszerkesztők Kommunikációs szoftverek o Levelező programok o Csevegő programok o Távbeszélő programok Hálózati alkalmazások o Webböngészők o Fájlcserélők Rosszindulatú alkalmazások o Vírusok o Férgek o Kémprogramok Biztonsági programok o Vírusellenőrzők o Kémprogram-felderítők o Titkosító programok o Tűzfalak Játékszoftverek

5 Szoftverek kereskedelmi kategóriái szerint A szoftverek főbb kereskedelmi kategóriáit voltaképpen a tulajdonjogot és a szoftverhasználatot szabályozó licencek alapján lehet felállítani. Ahány féle licenc, annyi féle szoftver létezik; a licencezés lényegi kitételeit tekintve azonban kialakult néhány közhasznú kategória is: Kereskedelmi szoftverek Shareware-ek o Ingyenesen, de csak korlátozott mértékben és/vagy ideig terjeszthető, birtokolható és felhasználható szoftver. Adware-ek és a spywarek Szabad szoftverek más néven Freeware-ek o A szabad vagy nyílt forráskódú szoftverek (FLOSS) szabadon használható, másolható, terjeszthető, tanulmányozható és módosítható számítógépes programok. (Linux, Mozilla Firefox, OpenOffice.org) Nyílt forráskódú szoftverek o A nyílt forráskódú licenc olyan licenc, mely biztosítja a licencelt szoftver forráskódjának nyitottságát. Abandonware-ek o Olyan szoftverek jelölésére használt fogalom, amellyel kapcsolatosan az eredeti jogtulajdonos vélhetően már semmilyen jogérvényesítési igénnyel nem fog fellépni Ingyenes szoftverek Szoftver életciklusa szerint A szoftver előállítása termelési folyamat, számítógépes programok előállítására irányul. A termék egy számítógépes program, ami egy feladat megoldására szolgál. A gyártási folyamat felosztható az elemzés, fejlesztés, üzembe helyezés fázisaira. A programozás előtti tevékenységet rendszerelemzésnek nevezzük. 1. lépés: rendszerelemzés A program megrendelője megfogalmazza igényét, hogy mit szeretne a számítógéppel megoldani. 2. lépés: rendszerfejlesztés Az algoritmus az az eljárás, amivel a bevitt adatok felhasználásával a kívánt eredményt megkapjuk. 3. lépés: specifikáció A megbízó, a rendszerfejlesztő, és a programozó együtt megalkotja azt a modellt, ami alapján a tényleges program működni fog. A specifikáció a szakmai nyelv mellett tartalmazza a programozói szóhasználatot a felhasználó számára érthető formában. Ebben leírják:

6 a tervezett hardverigényt a tervezett op.rendszert milyen adatokat kell rögzíteni hol, milyen formában kell az eredmény az alkalmazói programozási nyelvet milyen adatvédelemre van szükség. 4. lépés: algoritmus-tervezés A cél a megoldás szerkezetének géptől és programozási nyelvtől független szerkezeti egységet bemutató leírása (szöveges algoritmus, jel-algoritmus). 5. lépés: megvalósítás Ez a programozók feladata. 6. lépés: kódolás A program összekapcsolt utasítások sorozata, ami a programozás terméke. A megtervezett program megvalósítása a programnyelv kiválasztásával történik. 7. lépés: tesztelés Mielőtt a program alkalmazására sor kerül, ellenőrizni kell annak helyességét. A tesztelés a problémamegoldás biztosítéka (íróasztal-teszt, formai teszt, szintaktikai teszt, szemantikai teszt). 8. lépés: dokumentálás A programdokumentáció a program felépítésével és megvalósításával kapcsolatos valamennyi dokumentum gyűjteménye (felhasználói kézikönyv, szemléltetési kézikönyv). 9. lépés: rendszerbevezetés A letesztelt programok üzemeltetésre készek. A rendszerbevezetés az installálással kezdődik. Az üzemeltetőket, a felhasználókat ki kell képezni a program kezelésére, hibák elhárítására. A program üzemeltetése során szükség lehet apró módosításokra. 10. lépés: átadás A felhasználó ekkor ismeri meg a végleges verziót.

7 Maga a szoftver a programok, az adatok és a dokumentációk együttese. Tehát amikor szoftverről beszélünk, ezeknek az együttesét értjük, nem csak maga a program a szoftver. A szerzői jog jelen pillanatban ezt a szoftvert védi, nem csak a programot. Adatok alatt a szoftver vásárlásakor kapott állományokat kell érteni: ilyenek pl. a telepítő és a konfigurációs állományok. Manapság sokat lehet hallani, hogy a szoftvert (ezt a hármast) kivesszük a szerzői jogvédett dolgokból, és szabadalmi környezetbe helyezzük át. Egyrészt ez baromság (természetesen a Microsoft találta ki), sokan szoftver alatt csak a programot értik. Másrészt a szoftver tipikusan szellemi termék, ennek az összes előnyével és hátrányával, vannak speciális dolgai, és éppen ezért nem szabadalmaztatható. Affelé nyomja a világot pár nagy szoftvergyártó cég, hogy szabadalmaztassák a szoftvereket, és megesküszik rá, hogy ezt nem fogja kihasználni. Innentől kezdve garantáltan az első pillanatban tönkrevágja az összes kis céget, mert nem fogja kihasználni, csak a pénzt próbálja meg bekasszírozni. Nem lehet szabadalommal védeni a szoftvereket! A szerzői jogvédelem a szellemi termékekre vonatkozik, a szoftver szerzői jogvédelme elég. A szoftvereknek két nagy csoportjáról beszélünk: 1. általános célú (dobozos; COTS = Commercial On The Self) szoftvertermékek bárki megvásárolhatja általában sok év fejlesztőmunkája van mögötte általában nagy szoftverek a szakértelmet és a befektetett energiát kell megfizetni pl.: az Oracle adatbázis-kezelő rendszere 2. célszoftverek megrendelésre készülnek a kifejlesztést kell megfizetni pl.: a Neptun egységes felsőoktatási tanulmányi rendszer (:speciális célja, hogy pénzt szerezzen:) Az információs rendszerek fejlesztéséhez, a szoftvertechnológiához, a szűkebben vett információ oldali részhez a kitalálás óta két új dolog csatlakozott: minőségbiztosítási módszerek a szoftverek kifejlesztéséhez; projektvezetési, -irányítási, -szervezési módszerek a fejlesztést végző emberek munkájának menedzselésére. A félév folyamán elmondottak a nagyméretű (néhány százezer, de inkább néhány millió soros), összetett (komplex), hosszú fejlesztési idejű szoftverek előállítására vonatkoznak. Ebből következően nem egyedi munka, hanem csapatok dolgoznak a projekten, valamint a fejlesztési költség nagy, így a bukás is nagy lehet. A szoftver, mint termék előállítása egy folyamat, egy tevékenységsorozat, és a tevékenységhez eredmények, részeredmények kapcsolódnak. A szoftverfejlesztésben alapvetően négy nagy tevékenységcsoportot különböztetünk meg: specifikáció: az elvárásokat tárjuk fel, konkretizáljuk, rögzítjük elkészítés/implementáció validáció: az elkészült szoftverről belátjuk, hogy megfelelő szoftverevolúció: az elkészült szoftver módosítása, továbbfejlesztése (nem hibajavítás!) Rendszerszervezésben a következő terminológiát használtuk a szoftverfejlesztésre: elemzés (analízis), tervezés, implementáció, követés. Ezt a terminológiát egy kicsit kibővítve itt is fogjuk használni. Ezeket a tevékenységeket bővebben fogjuk tárgyalni, a köztes termékeket, az egyes tevékenységekhez csatlakozó részeredményeket is körbe fogjuk járni.

8 A lényeg: a szoftverfejlesztési életciklusban egy abszrakt megközelítéstől egy teljesen konkrét megközelítés felé megyünk el valamilyen módon, valamilyen alkalmazott tevékenységsorozat folyamán. Az elmúlt 40 év arról szólt, hogy hogyan lehet eltölti ezt a tevékenységsorozatot abba az irányba, hogy minél hamarabb, minél absztraktabb módon megfogalmazott dolgokból tudjuk a konkrét dolgokat automatikusan létrehozni. A folyamat: a követelmények meghatározása és elemzése tervezés alrendszerek fejlesztése rendszerintegráció a rendszer telepítése a rendszer működtetése rendszerevolúció a rendszer üzemen kívül helyezése Erre a folyamatra rakódik rá a minőségbiztosítás és a projektmenedzsment (fő célok: határidők meghatározása, melyik lépést mikorra kell végrehajtani; szükséges hardver-, szoftver-, emberi, és anyagi erőforrások biztosítása; az emberek munkájának irányítása, az erőforrások szétosztása, határidők biztosítása stb.) A követelmények meghatározása és elemzése A rendszer követelményeinek meghatározása természetesen a felhasználókkal történő konzultációsorozaton keresztül történik, a felhasználókat nem lehet kihagyni a szoftverfejlesztésből. (Nyilvánvalóan időnként beszélünk a dobozos szoftverekről, azonban most a hangsúly a fejlesztésen van, tehát a második kategóriájú szoftverekről (célszoftverekről) beszélünk elsősorban.) Tehát a követelmények a felhasználókkal együtt derítendők ki, elemzendők és dokumentálandók. A követelményeket három nagy csoportba soroljuk: funkcionális követelmények: az alrendszerekhez kapcsolódnak és a rendszer szolgáltatásait jelentik; az adott rendszernek milyen szolgáltatásokat kell nyújtania. pl.: tantárgyfelvétel, jegybeírás stb. rendszertulajdonságok: az alrendszerektől függetlenek, a rendszer egészére jellemző dolgok pl.: rendelkezésre állás, biztonságosság, barátságos felhasználói felület, teljesítmény stb. lehatárolás: a rendszernek mit nem kell tudnia, ezzel lehatároljuk a rendszert pl.: a Neptuntól, mint tanulmányi rendszertől nem várjuk el, hogy bérszámfejtést tudjon végezni

9 Tervezés Követelmények felosztása Alrendszerek interfészének definiálása Alrendszerek azonosítása Alrendszerek funkcionalitásának meghatározása Követelmények alrendszerekhez rendelése A következőkben a tevékenységeket ilyen ábrán fogjuk szemléltetni. A lekerekített objektumok a tevékenységeket, a köztük lévő nyilak az egymásutániságukat, vagy egymáshoz való viszonyukat szemlélteti, a tevékenységek eredményét pedig majd téglalap jelzi. A tervezés során a követelményektől eljutunk valamilyen módon az alrendszerekig. Alrendszerek fejlesztése Egy-egy alrendszer fejlesztése önmagában is egy nagyméretű szoftver kifejlesztését jelentheti, hiszen nagyméretű szoftverek esetén maguk az alrendszerek is nagyméretűek. Tehát amit itt most elmondunk, lehet, hogy egy alrendszernél újra kell kezdeni. Amiről szó van, lehet, hogy alrendszerekre alkalmazható, vagy az alrendszerekre esetleg külön más-más fejlesztési technológiát alkalmazhatunk. Az alrendszerek általában párhuzamosan fejlesztendők, fejleszthetők. Az egyes alrendszereken dolgoznak az egyes fejlesztői csapatok; tervezés után fejlesztik, implementálják, kódolják, majd tesztelik az egyes alrendszereket. Ennek eredményeképpen előállnak az alrendszereink.

10 Rendszerintegráció A kifejlesztett alrendszerekből összeállítjuk a teljes rendszert. Előfordulhat, hogy bizonyos alrendszereket nem fejlesztünk, hanem megvesszük. Bár a rendszerintegrációnál feltesszük, hogy az egyes alrendszerek önmagukban jól működnek, a rendszer összeállítása sok gondot okozhat. A rendszer telepítése Ha a rendszerfejlesztő cég és a megbízó jónak látja az elkészült rendszert, akkor következik a rendszer telepítése. A kifejlesztett rendszert konkrét hardver és szoftver platformra kell telepíteni. Azt pedig tudjuk a M$ óta, hogy a hardver és szoftver platformok egymással beszélő viszonyban sincsenek. Tehát az egyik platformon kiválóan működő rendszer van, hogy a másik platformon már nem is telepíthető. Különös tekintettel arra, hogy nagy rendszereket fejlesztő cégeknek megvan a saját fejlesztői platformjuk, onnan át kell ültetni egy működő alkalmazói platformra, amit külön meg kell tervezni. Másrészt elképzelhető, hogy a kifejlesztett rendszer nem okoz osztatlan lelkesedést a felhasználók között, amikor telepíteni kell, mert pl. ellenérdekeltek, utálják a rendszer fejlesztőjét, nem szeretnének áttérni az új rendszerre stb. Általában a megrendelő nem maga a felhasználó. Általában egy működő rendszert szándékozunk lecserélni egy másik rendszerre. Ha egy működő rendszer kényelmetlen is, egy idő után megszokja az ember. A rendszer működtetése A rendszer működtetése során derülnek ki a problémák, amire nem gondolt a felhasználó, pl. jó lenne, ha órarendet is lehetne felvinni a Neptunba. Működés közben ezeket a problémákat orvosolni kell. Felmerül a kérés: ki tegye mindezt?. Ez főnök vagy szerződés kérdése. Addig nincs baj, amíg a rendszer nem működik, akkor kezdődik a baj, ha működik. A rendszert működtetni kell, a működtetést pedig emberek végzik. Általános az, hogy egy nem 100%-osan jól megírt rendszert az emberi hibák nem abba az irányba viszik, hogy kijavítsák a hibákat, hanem inkább még jobban felnagyítják. Éppen ezért nagyon fontos a felhasználók képzése; a felhasználókat el kell látni információval, egyébként a működtetés nem fog menni. Rendszerevolúció A rendszerevolúcióhoz nem értjük hozzá a rendszer hibájának a javítását. Az nem rendszerevolúció, az a hülyeségnek a korrigálása. A rendszerevolúció annyit jelent, hogy a rendszert módosítjuk, továbbfejlesztjük a felhasználói környezet, a törvényi szabályozás, a cég méretének stb. megváltozása miatt. Tehát természetes fejlődés megy végbe a szoftvereknél is, amelynek semmi köze nincs a hibákhoz. Fontos, hogy a rendszer tervezésekor az evolúcióra is gondolni kell, hogy fejleszthető legyen. A rendszer üzemen kívül helyezése Az információs rendszer általában nem önmagában létezik, hanem további rendszerek környezetében dolgozik: más rendszerektől adatokat fogad, más rendszereknek adatokat szolgáltat. Tehát a rendszer üzemen kívül helyezése nem annyit jelent, hogy kidobjuk, hanem gondolnunk kell ennek a következményeire. A rendszer megszüntetésének nagyon sok hatása, mellékhatása, továbbhatása lehet, és mindezeket végig kell gondolni. Másrészt a végiggondolt rendszerevolúció oda vezet, hogy nem a teljes rendszert állítjuk le, csak a rendszernek bizonyos részeit, bizonyos alrendszereket cserélünk le, vezetünk ki, helyezünk üzemen kívül, és helyette más alrendszert vagy alrendszereket vezetünk be. Tehát manapság az üzemen kívül helyezés általában cserét jelent.

11 Ennyi volt a felvezetés, ezután a fenti lépéseken megyünk végig részletesebben, illetve az ezekhez szükséges gondolkodásmód, eszközrendszer, technológia stb. kerül terítékre. Szabványok Mint mindenütt, a technológiában is rengeteg szabvány van. A technológia szabványok fő letéteményese az OMG ( A szabányoknak három nagy csoportja van: tényleges, törvényszintű (de jure) szabványok Ezek a legmagasabb szintű szabványok, általánosan az élet minden területére vonatkoznak, a szabványügyi szervezetek (ISO, ANSI) dolgozzák ki őket. Ezek a szabványok közismertek, igazodnak hozzájuk, a gazdasági törvények egy része ezeken nyugszik. Minden országnak megvan a maga szabványügyi szervezete, így Magyarországnak is. Előnyük, hogy mindenki ismeri őket, igazodnak hozzájuk; hátrányuk, hogy az átlagember számára kvázi olvashatatlanok; angol nyelvűek, de még az angoloknak is le kell fordítani szabvány-nyelvről hétköznapi nyelvre. ipari (de facto) szabványok Ezek egy-egy szakterület szabványai; pl. informatika. Általában a szakterület vezető cégei összeállnak és alkotnak valamilyen formációt, konszenzusra jutnak, és ezt nyilvánosságra hozzák. Az OMG az egyik legnagyobb ipari szabvány-gyártó szervezet, amely a nyílt, elosztott objektumorientált rendszerek szabványait gyártja. A másik, az informatika területén alapvető szerepet játszó cég a W3C, amely a webes szabványok letéteményese. Az ipari szabványok követik a szakterület életét, úgy keletkeznek, hogy a szakterületen már kialakult termékek bizonyos szabványosítható jellemzőit vonják össze, rögzítik bennük. piaci (de azért is:) szabványok A piaci szabványok olyan szakterületeken alakulnak ki, amelyeken van egy nagyon erős piaci cég, amelyik nem foglalkozik a többivel, és ő mond valamit, kiad egy programot, és mivel ő uralja a piacot, az összes többi cég kénytelen lesz alakítani saját termékeit. Az informatika területén a piaci szabványt úgy hívták, hogy IBM, manapság bizonyos területeken pedig úgy hívják, hogy M$. A piaci szabványokat nem szeretjük. Folyamatmodellek A szoftverfejlesztés egy folyamat. Az elmúlt néhány évtizedben kialakultak szabványos folyamatmodellek (életciklusmodellek). Ezen folyamatmodellek mindegyikének megvannak az előnyei és hátrányai, megvan az alkalmazási területe, mikor célszerű és mikor nem célszerű használni. A folyamatmodellek történetileg az elmúlt harminc éven át folyamatosan alakultak ki. Azonban ez nem azt jelenti, hogy a korábbi folyamatmodellek elavultak; ezen folyamatmodellek mindegyike ma is él. El kell tudni dönteni, hogy egy adott szoftver fejlesztésénél melyik modellt követjük, beleértve azt is, hogy keverjük őket. Az adott lépésben, az adott részfolyamatban az oda legjobban megfelelő folyamatmodell alkalmazandó. A kialakult folyamatmodellek nagyjából történeti sorrendben a következők: vízesés modell evolúciós modell formális fejlesztési modell újrafelhasználás-alapú modell iteratív modellek o spriális fejlesztési modell o inkrementális fejlesztési modell

12 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM 1. Vízesésmodell Az első folyamatmodell, amely a történelemben kialakul, 1970-ben definiálták. Ez más termékelőállítási folyamatmodellből származik. követelmények meghatározása rendszer- és szoftvertervezés implementáció és egységteszt működtetés és karbantartás A vízesésmodell a nevét onnan kapta, hogy a folyamatelemek, az egyes lépések meglehetősen mereven egymásra épülnek, ilyen lépcsőzetesen kapcsolódnak egymáshoz, mint ahogy a víz folyik le a sziklán. Ez a modell előnyeit és hátrányait egyaránt magába foglalja. Hátránya: merev, nem flexibilis egymásraépülés. Minden egyes folyamat teljeskörűen lezárul, mielőtt a következő folyamat elindulna. Ez a felső nyilakon látszik. Ez a merevség oda vezet, hogy egy implementációs tervnek teljesen készen kell lennie. Minden egyes lépés végén születik egy dokumentum: az első és második lépés esetén ténylegesen szöveges, rajzos dokumentum, harmadik lépés után ez egy szoftver, kód a hozzátartozó dokumentumokkal. Ha ezt a dokumentumot a felhasználó és az informatikus együtt elfogadja, akkor lehet áttérni a negyedik lépésre. Az egyes lépésekről később, külön-külön, amikor odaérünk. Ez is mint minden elvi modell, absztrakt modell, azonban a gyakorlatban az egyes lépések átfedik egymást, de mindenféleképpen igaz, hogy a modellben nincs párhuzamos fejlesztés, a lépések semmiképp nem párhuzamosak. Előnye kicsi és közepes méretű rendszereknél jelentkezik, és azon rendszereknél, amelyeknél a követelmények valóban jól meghatározhatók. Ekkor egy jól struktúrált, jól felépített, jó architekturális jellemzőkkel rendelkező, robusztus rendszer fejleszthető. Sajnos általában nem igaz, hogy az elején a követelmények szépen kideríthetők és rögzíthetők. Innentől jönnek a gondok, mivel a lépések közül a működtetés a leghosszabb, és sajnálatos módon működétetés közben derülnek ki a követelményhibák, a rendszerterv hibái. Ekkor az egészet újból kell kezdeni. A legutolsó lépésben derülnek ki a korai lépések problémái: nem teljesített követelmények, félreértések, hibás specifikációk, félreérthető terv stb. Az alsó nyilak azt jelentik, hogy bárhonnan újrakezdődhet a folyamat, de az összes lépést végig kell csinálni. Nyilvánvalóan ha a vízesés modellben kifejlesztünk rendszert, melynek világos a struktúrája, de nem ér semmit, újra kell kezdeni az egészet, ez újbóli plusz költséget és plusz időt jelent. Viszont a vízesés modell létezik, és a vízesés modellnek mindenféle változata jött létre. Bizonyos esetekben napjainkban is a vízesés modellt használják, mivel a legegyszerűbb, a legjobban alkalmazható modell a fenti feltételek fennállása esetén.

13 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM 2. Evolúciós modell Az evolúciós modellt a 80-as évek elején találják ki, nagy rendszerek fejlesztésére hívatott. Egyik alapötlete, hogy az előbbi abszolút lineáris vagy minimálisan átfedő modellel szemben próbáljunk meg egy párhuzamos fejlesztési modellt kialakítani. A másik ötlet, hogy a fejlesztést úgy végezzük el, hogy egy nagyon korai implementációt készítünk, majd implementációk verzióin keresztül jutunk el a végső verzióhoz. Tehát az evolúciós fejlesztés verziósorozatot produkál. specifikáció kezdeti verzió vázlat leírása fejlesztés közbülső verziók validálás végleges verzió Tehát van egy vázlatos követelményrendszer, utána párhuzamosan követelményspecifikáció, implementálás, validálás történik úgy, hogy van egy kezdeti implementáció, majd annak vannak valamilyen változatai és végül megszületik a végleges verzió. Ezeket a verziókat hívja a modell prototípusoknak. Tehát ez a prototípusorientált vagy prototípusalapú modell. A párhuzamosság és a verziókezelés nagyon gyors visszacsatolási lehetőséget jelent, gyors beavatkozást tesz lehetővé. Tehát nem a végén derülnek ki a hiányosságok, hanem menet közben. Két fajta evolúciós megközelítés létezik: feltáró fejlesztés A prototípusok segítségével a felhasználó és a fejlesztő közösen finomítja, pontosítja a követelményeket, tehát prototípus sorozaton keresztül tárjuk fel a követelményeket. Tehát a felhasználó kap egy működő verziót, ezek alapján pontosítja a követeményeket, a fejlesztésnél ezt figyelembe vesszük és a következő verzió már jobban teljesíti a követelményeket. Így a verziósorozat egyes verzióiban egyre több felhasználói igény kerül beépítésre, míg a végső verzió már a tényleges követelményeknek megfelelő verzió lesz. Ez lesz a rendszer. Ilyenkor az első prototípusoknak a rendszer azon részeivel kell kezdődnie, amelyek tiszták, világosak, amelyeknek a követelményei egyértelműek, a rendszer ismert részeinek kifejlesztésével kezdődik. A kevésbé ismert, zűrösebb rendszerelemek a későbbi prototípusokba kerülnek bele. Minden prototípus az előzőből következik, az előző prototípusra épül, a végleges változat prototípus sorozat alapján készül el. eldobható prototípuskészítés Adunk a felhasználó kezébe egy verziót, és ennek segítségével a felhasználó kipróbálja a prototípust, így rájöhet, hogy mit akar. Ha arra jön rá, hogy nem ezt akarja, a prototípust eldobjuk, újrafogalmazzuk a követelményrendszert, és az ennek megfelelő prototípust állítjuk elő. Ebben a megközelítésben az első prototípusok a legkevésbé megértett, legkevésbé feltárt rendszerelemekkel kezdődnek azért, hogy a felhasználó kitalálja, mit akar. Az evolúciós modell előnyei: párhuzamosság; a felhasználó igényeinek jobban megfelel, gyorsabban kap egy prototípust, tud vele foglalkozni, rájön, hogy a követelmények jók vagy nem. Nagyon hamar kap kipróbálható verziókat, amelyek folyamatosan finomodnak. Így nem teljes alrendszert kell kipróbálni, csak bizonyos rendszerelemeket. Hátrányai:

14 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM Az adott esetben meglévő túl sok verzió között elveszhet a felhasználó és a fejlesztő is, a folyamat egy áttekinthetetlen verziókezeléssé válik. Nagy méretű rendszerek túl sok verziója nem biztos hogy szerencsés és az említett előnyöket tükrözik. Az evolúciós modell alapján létrehozott rendszerek szemben a vízesés modellben létrehozott rendszerekkel nem robusztusak. Magyarul a prototípus sorozat általában rossz stuktúráltságú, architektúrájú szoftverhez vezet. A prototípus-alapú feljesztés speciális. Ez gyors fejlesztést, rapid techikákat igényel, amelyhez speciális technikák és speciális tudású emberek kellenek. 3. Formális modell A formális modell a 70-es években alakul ki a vízesés modell egy változataként. követelmények meghatározása formális specifikáció formális transzformáció integráció és rendszerteszt rendszervalidáció A követelményspecifikáció és a rendszervalidáció ugyanaz, a közbenső rész más. Ezen formális modell szerint ugyanis a rendszerspecifikációból matematikai eszközökkel formálisan generálunk működő programot. Ehhez az szükséges, hogy a rendszerspecifikációt is formálisan, absztrakt eszközökkel adjuk meg. Ekkor a lényeg a transzformációs folyamat, amely a formálisan megadott követelményekből előállít egy adott nyelvű kódot. Megtakarítjuk azt a lépést, amelyet mindenütt majd validálásnak nevezünk, mivel az egész modell a validáláson alapszik. Ehelyett van egy matematikai eszközrendszer, amellyel ezt megtesszük. A model Mills-től származik. Konkrét alkalmazása a 80-as évek második felében az IBM- Cleanroom folyamat. A Cleanroom egy formális modell alkalmazó szoftverfejlesztői folyamat. Előnyei: automatizált a folyamat; bármilyen rendszer esetén alkalmazható. Egyetlen apró hibája, hogy a rendszerkövetelmények formalizálása kézzel kell, hogy történjen, azonban a rendszerkövetelmények matematikai eszközökkel való felírása általában nem megy. Biztonságkritikus rendszerek esetén alkalmazták, alkalmazták ezt a modellt. 4. Újrafelhasználás-orientált modell A modell lényege benne van a nevében, azonban az újrafelhasználás nem csak kódújrafelhasználást jelent, hanem tervezési szinten való újrafelhasználást is. A modell azon alapul, hogy léteznek olyan komponensek, amelyeket újrafelhasználhatunk. Legyen a modell olyan, hogy ezeket a meglévő komponenseket valóban újra felhasználjuk. Ez viszont a következőképpen módosítja a folyamatot: követelmények specifikációja komponenselemzés követelmények módosítása rendszerterv újrafelhasználássa l fejlesztés és integráció rendszervalidáció Az eleje és a vége azonos, a közepe más.

15 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM Ha megvan a követelmények specifikációja, akkor elsőként megnézzük, hogy a világban vannak-e olyan szoftverek, netalán olyan tervelemek, amelyek nekünk jók, felhasználhatók a mi rendszerünkben; megkeressük ezeket az elemeket. Problémák: tudnunk kellene, hogy vannak ilyen komponensek tudnunk kellene, hogy egyáltalán milyen komponensek vannak meg kellene tudni találni ezeket a komponenseket ha meg is találtuk, ezek nagy valószínűséggel nem felelnek meg teljes mértékben az igényeinknek. Megoldásként módosítjuk a követeményeinket annak megfelelően, hogy a kész komponenseket be tudjuk építeni a rendszerünkbe. Aztán ennek megfelelően végrehajtjuk a tervezést és beépítjük a tervbe vagy az implementációba a komponenseket. Hátrány: valószínűleg kompromisszumot kell kötnünk. Előnyök: kész komponenseket használunk fel, ezzel időt, pénzt takarítunk meg; a komponensek megvannak, léteznek, kipróbáltak, teszteltek stb., feltételezhetjük, hogy nem hibásak, vagy legalábbis miniálisan hibásak, így egyfajta biztonságérzetet nyújt, sok validációs lépést megspórolhatunk. Probléma még, hogy leromolhat a rendszer struktúrája. Az újrafelhasználással fejlesztett rendszer egy bizonyos idő után ha túl sok kompromisszumot kötünk, akkor ez a rendszer stuktúrájának rovására mehet még akkor is, ha a komponensek jók. 5. Iteratív folyamatmodellek a) inkrementális fejlesztési modell A fejlesztés implementálás része kis méretű egységekben, inkremensekben történik, a mindenkori rendszerbe inkremenseket építünk, inkremensekkel bővítjük, és ha szükséges, nyilván megismételjük az inkremenshez akár a specifikációs tervezés lépését is. vázlatos követelmények meghatározása követelmények inkremensekhez rendelése rendszerarchitektúra megtervezése rendszerinkremens fejlesztése inkremens validálása inkremens integrálása rendszer validálása véglege s rendszer a rendszer nem teljes Az alsó rész, az inkremensek hozzáillesztése ciklikus folyamat, mindaddig folytatjuk, amíg úgy nem döntünk, hogy kész van a rendszer. Az inkrementális fejlesztésnek ez a ciklus a lényege. Az inkremenseket önállóan fejlesztjük, tervezzük, implementáljuk, validáljuk, sőt adott esetben még a követelményspecifikációt is megadhatjuk, megváltoztathatjuk inkremensenként. Az architektúrát változatlanul hagyva az inkremensek fejlesztése teljes életciklussal történik.

16 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM Az inkrementális modell előnyei: az inkremensek kicsik (úgy kell megtervezni, hogy kicsik legyenek), ezekre önmagukban a legmegfelelőbb modell alkalmazható, például vízesésmodell is (az inkremensek kicsik, jól körülhatárolhatók, adott esetben a követelmények egyértelműen specifikálhatók). az inkremensek fejlesztése történhet párhuzamosan kezdhetjük a fejlesztést a legfontosabb funkciókat realizáló inkremensekkel, és mivel az inkremensek kicsik, a felhasználó nagyon hamar kap egy nem eldobható prototípust, amely viszont már nem a követelményfeltáráshoz való, hanem már tudja használni. Tehát bizonyos funkciókat, a legalapvetőbb funkciókat tartalmazó rendszert nagyon hamar kap a felhasználó, a kevésbé lényeges funkciókat majd később beépítjük a rendszerbe. A rendszervalidálás mindig megtörténik, tehát a rendszer ilyen értelemben a beépített inkremensekkel önmagában egy részrendszer, tehát egy használható rendszer. a rendszerfejlesztés kockázata kisebb, mint az összes többi modellnél (a fejlesztések igen nagy része, több mint 50 százaléka sikertelen), mivel a rendszer validált, kis elemekkel, tehát van egy validált működő rendszer még akkor is, ha befullad a projekt, legfeljebb nem teljes funkcionalitással. Nagyon nagy a valószínűsége, hogy az első pár inkremensnél még nem fogy el a pénz, az idő, az ember, nem változik meg a környezet. Ezért a részsikeres befejezés valószínűbb ennél a fejleszési modellnél. a fontosabb funkciókat implementáljuk először, ennek a következtében azokat a funckciókat a felhasználók rendszeresen tesztelik, a fontosabb funkciókat jóval többször használják, mint a kevésbé fontosakat. Így már a rendszerfejlesztés közben a hibák hamarabb kiderülnek, a mindenkori részrendszerben valóban a legfontosabb funkciók a legteszteltebbek. Tehát egy robusztusabb rendszer fejlesztéséhez vezet ez a modell. A modell problémáját a 2. és 3. lépésben az inkremensek megtervezése jelenti: milyen funckiókat tegyünk egy-egy inkremensbe? Mit jelent egy inkremens? Ez a felosztás, az architektúra megtervezése az, ami nagyon nyűgös. A modell ezen alapszik, tehát ha az elején az architektúrát rosszul tervezzük meg, akkor gond van. Nagyon nehéz az inkremensek behatárolása, az elején eldöntjük, hogy melyek a fontosabb funkciók: Melyik funkció mely inkremensbe kerüljön? az inkremensek átfedhetik egymást, nem lehet a funkciókat egymástól szétválasztani. b) spirális modell A legkésőbb, 1988-ban kialakuló modell, az ún. Boehm-spirál. Ez teljesen más modell, mint az eddigiek. Középpontjába olyan dolog kerül, amivel az eddigi modellek nem foglalkoztak: a fejlesztés kockázati tényezőinek felmérése, a kockázatból származó problémákra való felkészülés, a sikertelen kimenetek, a rizikó csökkentése. Négy alaplépés van, ezeket spirálisan ismételgetjük, tehát a következő spirálban ugyanaz a lépés az eddigieknél magasabb szinten ismétlődik meg. 1. lépés: a követelmények, pontosabban célok meghatározása: az adott spirális fázisban mit fogunk megvalósítani? azonosítjuk a tevékenységeket, meghatározzuk a megszorításokat, a menedzselési tervet és azt, hogy milyen kockázati tényezők várhatók ebben a lépésben, és ezeket a kockázatokat hogyan fogjuk kezelni, milyen alternatívák lehetnek a kezelésre.

17 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM 2. lépés: kockázatelemzés, kockázatok felismerése, kockázatok tényezőinek megszűntetése, ezekre való felkészülés: megtervezzük azokat a lépéseket, amelyek azt célozzák, hogy a kockázatokat el tudjuk kerülni. (Ha például a követelmények meghatározása kritikus pont, tehát úgy gondoljuk, hogy a teljes fejlesztésben nagyon nagy kockázatot jelent, rosszak a követelmények, akkor egy feltáró evolúciós modellt alkalmazzuk ebben a lépésben, építenünk kell egy prototípus sorozatot a követelmények minél pontosabb meghatározása érdekében.) 3. lépés: fejlesztés és validálás: a 2. lépés után fejlesztési modellt választunk, adott esetben minden egyes spirálban más-más fejlesztési modell alkalmazható, adott esetben a kockázatanalízis eredményeként választható a fejlesztési modell. Ezek után hajtjuk végre a szokásos tervezés, implementáció, validálás lépéseket. Az első spirálok esetén nyilvánvalóan a követelményfeltárás, követelménytervezés és a validációs lépések következnek, amíg el nem jutunk odáig, hogy lépés: tekintsük át a teljes projektet, az eddigi fejlesztést, az eddigi spirálokat, elemezzük ezeket, és döntsünk a folytatásról olyan értelemben, hogy megállunk-e (a megvalósíthatósági esettanulmány után dönthetünk úgy, hogy befejezzük). Amennyiben a folytatásról döntünk, a projektet tervezzük meg, azt tervezzük meg, hogy hogyan folytatódjon a projekt, és kezdődik elölről a spirál. A spirálmodell előnyei: foglalkozik a kockázatokkal sokkal szisztematikusabban foglalkozik a projekttel Hátránya: nem a legtriviálisabb modell. Nagy rendszereknél javallott, előnyei nagy rendszereknél jönnek ki. KÖVETELMÉNYEK MEGHATÁROZÁSA ÉS ELEMZÉSE A rendszereink nagyok, komplexek, nehezen lehet őket körülhatárolni, nehéz előre megmondani, hogy hogyan, milyen körülmények között, mit szolgáltatva működjön. A rendszer szolgáltatásainak, és az ezekre vonatkozó megszorításoknak az együttesét hívjuk követelményeknek. Az egész folyamat a követelmények megtalálásának, adott esetben kitalálásának, elemzésének, dokumentálásának és validálásának lépésével indul. Ezt hívjuk a követelmények meghatározásának és elemzésének, vagy szokás ezt követelménytervezésnek hívni. (A probléma a terminológiával az, hogy a designing, a planning és az engineering mindegyike tervezésnek fordítandók magyarra, holott a design és az engineering nem tervezést jelent.) Ez az első lépés. A követelmények osztályozása: felhasználói követelmények: azt specifikálják, hogy a rendszernek milyen szolgáltatásai legyenek majd, és ezek a szolgáltatások hogyan, milyen körülmények között, milyen elvárásokkal működjenek. A felhasználói követelmények tehát a szolgáltatásokat, a funkcionalitást jelentik. Például egy tanulmányi rendszertől követelményként elvárjuk, hogy lehessen benne órarendet meghirdetni, vizsgát meghirdetni, tantárgyat felvenni, törölni, jegyet beírni, előfeltételeket, diplomakövetelményeket lekérdezni stb. Elvárjuk, hogy a rendszer automatikusan tudja kezelni ezeket a fogalmakat. rendszerkövetelmények: azok a követelmények, amelyek általában, globálisan a rendszer egészére vonatkoznak, melyek függetlenek az egyes szolgáltatásoktól, konkrét szolgáltatástól független követelmények. Szoktak belső (immanens, eredendő) követelményeiről beszélni (az információs rendszer követelményei): pl. hozzáférhetőség, bizonságosság, válaszidő, társzükséglet stb. A rendelkezésre állás nyilván független attól, hogy milyen szolgáltatást nyújt a rendszer, el kell tudni érni éjjel-nappal. Egy tanulmányi rendszertől azt várjuk el, hogy az év minden percében rendelkezésünkre álljon.

18 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM Természetesen az eredendő rendszerkövetelményeken túl lehetnek speciális rendszerkövetelmények. szoftverterv-specifikáció: a követelmények meghatározásánál egy harmadik követelménycsoport a felhasználói és rendszerkövetelmények mellett. Ez általában kiegészítése a rendszerkövetelmény specifikációnak, ez a kifejlesztendő szoftvernek egy absztrakt specifikációja, amely majd a tervezési fázis alapjait szolgáltatja. A követelmények felosztása talán világosabbá válik, ha azt nézzük meg, hogy az egyes követelmények kiknek szólnak, az egyes követelményekkel elsősorban kiknek kell találkozniuk. A felhasználói követelmények azok a követelmények, amelyekkel elsősorban a fejlesztői oldali és a megrendelő oldali menedzserek találkoznak. Nagyon lényeges, hogy a felhasználói követelmények azok a követelmények, amelyek elsőrendű fontosságúak a végfelhasználók számára. Tehát egy tanulmányi rendszertől felhasználói szinten elvárjuk, hogy az összes oktató és hallgató mint végfelhasználó kívánalmait, megszorításait tudja teljesíteni. A rendszerkövetelményekkel a rendszerfejlesztők, az informatikusok találkoznak, mivel nekik kell olyan rendszert fejleszteni, amely a rendszerkövetelményeknek eleget tesz. A másik oldalon az üzemeltetőknél a rendszergazdák, a rendszeradminisztrátorok számára elsődlegesek. Mert például nekik kell konfigurálni a rendszert. A szoftverterv specifikáció nyilvánvalóan a szoftver tervezőinek alapvető fontosságú, befolyásolja a fejlesztő munkáját is. Másik felosztás szerint beszélünk funkcionális, nem funkcionális és szakterületi követelményekről. funkcionális követelmények: azok a követelmények, amelyek a szolgáltatásokhoz kapcsolódnak. A szemlélet egy kicsit azért más, mert a funkcionális követelmények felosztásánál azt mondjuk, hogy a rendszer bizonyos szituációkban bekövetkező reakcióit írják le, hogy hogyan reagál a rendszer bizonyos inputokra, bizonyos bekövetkező szituációkra. A funkcionális követelményeknél körül kell határolni a rendszert, tehát adott esetben a funkcionális követelmények közé felvesszük azt is, hogy a rendszertől mit nem követelünk meg, hogy mit nem kell tudnia a rendszernek. Körülhatárolás szempontjából lehet, hogy könnyebb azt mondani, hogy nem. Az is funkcionális követelmény, hogy azt nem kell tudnia. Például egy tanulmányi rendszertől nem várjuk el azt, hogy pénzügyi alrendszer legyen benne. nem-funkcionális követelmények: ezek általában a teljes rendszerre vonatkozó követelmények, nem az egyes konkrét esetekre vonatkozó, hanem általános követelmények; időbeli megszorítások, korlátok, magára a fejlesztési folyamatra tesz korlátot. Adott esetben nemfunkcionális követelmény lehet az, hogy megadjuk, milyen fejlesztési modellt kell követni, vagy bizonyos szabványokat kell követni, a rendszernek konformnak kell lennie bizonyos szabványokkal. Természetesen eleve nem-funkcionális követelmények az immanens rendszerkövetelmények is. szakterületi követelmények: olyan követelmények, amelyek egy-egy adott szakterülethez kötődnek, tehát speciálisan az adott szakterület felhasználói igényeiből következnek. Ezek lehetnek funkcionális követelmények, de nem az adott rendszerre vonatkozó, hanem általánosan a szakterületből következőek. Lehetnek általános, adott szakterületi rendszerekre vonatkozó megszorítások. Például régebben tanulmányi rendszerekben volt egy súlyozott átlag fogalom, ennek a számítása szakterületi funkcionális követelmény.

19 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM Ez a két osztályozás ortogonális egymásra. A rendszer funkcionális követelményei a teljes rendszertől elvárt szolgáltatásokra vonatkoznak. Ezeknél a funkcionális rendszerkövetelményeknél azt kell megmondani, hogy milyen szituációkban, pl. milyen inputokra hogyan reagáljon, milyen szolgáltatást nyújtson, milyen outputot adjon. Van egy külön nyűgös dolog, a kivételek feltárása. Ez különösen hangsúlyos. A funkcionális követelményrendszernek teljesnek és ellentmondásmentesnek kell lennie. Ez az, ami a gyakorlati életben nem teljesül, nagy rendszereknél ez nyűgös. Majdnemhogy definíció szerint nagy rendszereknél a követelményrendszer kezdetben nem teljes, mert a felhasználó nem tudja, mit akar, bonyolult rendszereknél pedig az ellentmondásosság pedig szinte garantált. Itt jön mindig a validálás, ilyen kérdésekre ad választ, hogyan kell az ideális követelményrendszert megközelíteni. A nem-funkcionális követelmények nem az egyes szolgáltatásokhoz, hanem a teljes rendszerhez köthetők, természetesen benne foglaltatnak az eredendő rendszerkövetelmények. A lényeg, hogy a nem-funkcionális követelmények nem az egyedi rendszerelemekre, hanem mindig a teljes rendszerre vonatkoznak. Ezek azért nagyon fontosak, mert hiába sikerül olyan rendszert készíteni a követelmények jó feltárásával, ezeket a követelményeket kiváló implementálásával, ha a teljes rendszerre vonatkozó nem-funkcionális követelmények nem teljesülnek. Ekkor az egész rendszer úgy bukik meg, ahogy van. A nem-funkcionális követelmények nagyon gyakran nem szoftverre vonatkozó szorosan vett informatikai követelmények, hanem a majdani rendszerre, környezetére, működtetésére vonatkoznak, és olyan külső követelmények is ide tartoznak, amelyek alapvetően a befolyásolják a rendszer kifejlesztését, validálását, működtetését stb. nem-funkcionális követelmények termékkövetelmények szervezeti követelmények külső követelmények hatékonysági követelmények megbízhatósági követelmények hordozhatósági követelmények együttműködési követelmények etnikai követelmények használhatósági követelmények telepítési követelmények implementációs követelmények szabánykövetelmények törvényi követelmények teljesítmény követelmények tárterület követelmények biztonsági követelmények adatvédelmi követelmények A nem-funkcionális követelményeknek három nagy csoportjáról szoktunk beszélni, a részletezés nem teljes, inkább csak példaként szolgál. A felsorolt követelmények eredendő rendszerkövetelmények. termékkövetelmények: a szoftverre vonatkozó követelmények szervezeti követelmények: azon szervezet követelményei, amelyek a szoftver működtetési környezetét jelentik, az adott szervezetből következnek, nem a szoftverből o a szabványkövetelményekben elő lehet írni olyat, hogy a megrendelő pl. ISO-szabványnak megfelelő fejlesztést kér, vagy belső szabvány, általában dokumentálást jelent

20 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM o implementációs követelmény lehet, hogy milyen szoftvereszközzel történjen a fejlesztés; ez nagyon kemény nem-funkcionális követelmény o telepítési követelmények azt adják meg, hogy milyen platformra vagy platformokra történjen a fejlesztés külső követelmények: a legnyűgösebb dolog, a szervezeten kívüli követelmények o együttműködési követelmények: az adott szoftver nem az adott cégnek egy önálló szoftvere lesz, hanem a cég beleilleszkedik egy politikai, társadalmi, kultúrális környezetbe, ahol természetesen már működnek rendszerek, és ebben a külső, szervezeten kívüli rendszerkörnyezetben kell a konkrét szoftvernek működnie. Például egy tanulmányi rendszernek együtt kellene működnie az országos felvételi rendszerrel. o törvényi követelmények: az adott jogszabályi követelmények között kell működnie a rendszernek. o etikai követelmények: pl. ugyan törvények nem tiltják, de egy kemény etikai követelmény, hogy a Neptunon keresztül politikai levelet ne küldjenek... A nem-funkcionális követelmények összegyűjtése nagyon kemény kérdés, itt szokták nagyon elszórni a követelményeket, nem kerül rájuk kellő hangsúly. Ahogy megyünk balról jobbra az ábrán, egyre kevésbé. A nem-funkcionális követelmények feltárása nagyon rossz szokott lenni. A nem-funkcionális követelmények nagy problémája az, hogy ezeket a követelményeket gyakran nagyon nehéz egyértelműen feltárni, megfogalmazni. Ráadásul mivel nincs egyértelmű megfogalmazás, ez rögtön implementálási gondokohoz vezet, ugyanis a programozó a könnyebb ellenállás irányába megy, úgy értelmezi a dolgokat, ahogy szeretné, és akkor nem kell programoznia semmit. Aztán meg majd ha jön a validáció, előjönnek a problémák a nem egyértelmű megfogalmazás miatt: mit lehet érteni egy követelmény alatt, és valójában az alatt mást értünk. Erre a problémára lenne megoldás a nem-funkcionális követelmények számszerűsítése metrikák megadásának segítségével. Van, amire könnyű metrikát adni (tárterület, sebesség, maximális válaszidő), viszont vannak nagyon nehezen mérhető követelmények (használhatóság, robusztusság). A nem-funkcionális követelmények másik nagy problémája, hogy gyakran ellentmondanak a funkcionális követelményeknek. Az egyik örök ellentét a válaszidő (funkcionális) és a tárméret (nem-funkcionális). Hogyan írjuk le, mennyire válasszuk el dokumentáció szintjén a funkcionális és nemfunkcionális követelményeket? Ez nagyon sokmindentől függ: a fejlesztendő rendszertől, a fejlesztő cégtől, a megrendelő cégtől, maguktól a követelményektől is. Mindkét megoldásnak vannak előnyei és hátrányai: ha együtt kezeljük a funkcionális és a nem-funkcionális követelményeket, akkor túl nagy lesz a specifikáció, nem veszünk észre bizonyos követelményeket; validációnál a bonyolultság miatt bizonyos követelmények elsikkadhatnak. ha külön kezeljük a funkcionális és a nem-funkcionális követelményeket, akkor nehéz az ellentmondások felderítése, mert koncentrálunk bizonyos funkcionális követelményekre, mások validálják a funkcionális és a nem-funkcionális követelményeket, így az ellentmondások nem derülnek ki, vagy később derülnek ki, mint kellene. Hogyan specifikáljuk, írjuk le, adjuk meg a dokumentációt a követelmények vonatkozásában? természetes nyelv illetve ennek valamilyen struktúráltabb, formalizált változata; jelen pillanatban ez elkerülhetetlen, a követelmények leírásának egy része minden esetben természetes nyelven történik. Előnye, hogy az adott nyelvet elviekben beszéli az a környezet, amely foglalkozik a

21 A rendszerfejlesztés techn., Készítette: Tóth Péter IV. PTM követelményekkel. Hátránya, hogy nem egyértelmű, terjengős, hosszú, nem szabványos, félreérthető, félremagyarázható ezen segít valamelyest a formalizált természetes nyelv. diagramok: a követelmények vizualizált megfogalmazása. Elég sokféle diagramot ismerünk, ma nagyobb hangsúlyt kap. Előnyük, hogy áttekinthetőbbek, szabványosak, kevésbé félreérthetőek. Problémát jelent nagyméretű rendszerek követelményeinek áttekinthetősége; egy A4-es papíron lévő UML diagram még átlátható, öt A4-es lapon lévő már nem, néhány méteres diagram már képernyőn sem látható át, mert vagy a részleteket látjuk, de ekkor nem látjuk az egészet, vagy az egészet nem tudjuk megnézni egyben, mert nincs olyan eszköz, amely meg tudná jeleníteni. Míg a természetes nyelvet beszélik mind a felhasználók, mind a tervezők, jó lenne, ha lenne olyan diagramtípus, amit mindketten ismernek: mindketten saját problémájukat vagy le tudják írni, vagy ha már le van írva, át tudják látni. Sokfajta diagrammal találkoztunk eddig, egy UML diagramot a felhasználónak odaadunk, jobb ha nem halljuk, mi a véleménye róla. Egy UML diagram kiváló informatikai oldalról, a felhasználói oldalról nem biztos. leíró nyelvek: az 50-es, 60-as évektől próbáltak a programnyelvekhez (Algol, Pascal, Java) formailag kísértetiesen hasonló egyszerűsített nyelvet létrehozni. Előnye, hogy egyértelmű, szabványos, hátránya pedig az, hogy a felhasználók nem értik. matematikai specifikáció: a követelményeket valamilyen absztrakt eszközrendszer segítségével próbáljuk megfogalmazni. Előnye, hogy egyértelmű, a probléma vele az, hogy a követelmények egy része nem formalizálható, a felhasználók nem értik. hibrid megoldás: manapság van egy diagramorientált specifikáció, vizualizáció, rajz és egy természetes nyelvi fogalomszótár. Tehát elsősorban az első kettő keverékét szokták haszálni manapság. A rendszerkövetelmények megadásához nagyon gyakran rendszermodelleket használnak. Ezek a modellek grafikus reprezentációk; diagram segítségével adják meg a rendszerkövetelményeket. Ezek szolgálnak dokumentációként a tervezéshez, hangsúlyozván, hogy a rendszermodellek minden esetben absztakciók. Ezek segítik formalizálni a követelményeket, képeznek egy hidat a felhasználó és a fejlesztő között. Rendszermodellek A rendszermodellek három különböző szempontból próbálják közelíteni a rendszerspecifikációkat: környezeti modellek: kívülről közelítenek; azt a környezetet modellezik, amelybe bele kell helyezni a rendszert (HOL dolgozik a rendszer?) viselkedési modellek: belülről közelítenek, de a rendszer viselkedését helyezik a középpontba (HOGYAN dolgozik a rendszer?) adatmodellek: belülről közelítenek, középpontjukban a rendszer, és az általa feldolgozott adatok struktúrája áll (MIVEL dolgozik a rendszer?) Struktúrált módszertanok Elsősorban a viselkedési modelleket favorizálják. Hátrányuk, hogy nem nyújtanak hatékony támogatást a nem-funkcionális rendszerkövetelmények modellezéséhez, nincs eszköz, mellyel a környezetet lehet modellezni. Egy időben előnynek tekintették, hogy aprólékos, sok dokumentum keletkezik, manapság már hátránynak tekintjük.