4. fejezet A szoftverfolyamat Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai és Gazdasági Intézet 2007. július 1
A szoftverfolyamat Ahogyan az első fejezetben megbeszéltük: A szoftverfolyamat tevékenységek és kapcsolódó eredmények olyan sora, amelyek egy szoftvertermék előállításához vezetnek Ezek történhetnek a szoftverfejlesztés kezdeteitől, de gyakran egy meglévő szoftver módosítására irányulnak Nehezen gépesíthető, mert nagyon sok emberi tényezőtől függ, kreativitást igényel Egyes fázisai támogathatók CASE eszközökkel CASE: Computer Aided Software Engineering 2
A szoftverfolyamat fázisai Sokféle megközelítés létezik, de vannak közös pontok: Szoftverspecifikáció Szoftvertervezés és implementáció Szoftvervalidáció Szoftverevolúció 3
A szoftverfolyamat modelljei Nincs olyan modell, ami minden folyamatra alkalmazható lenne. Vannak különböző megközelítésmódok, amelyeket ismerve, vegyesen alkalmazhatjuk ezeket: Vízesés modell Evolúciós fejlesztés Formális rendszerfejlesztés Újrafelhasználás alapú fejlesztés 4
A vízesés modell Ez a szoftverfolyamat első publikált modellje (1970) Nevezik szoftveréletciklusnak is Az ábrán látszik, hogy honnan kapta a nevét Mit jelentenek a nyilak? 5
Követelmények elemzése és meghatározása A rendszer által nyújtandó szolgáltatások, és a megszorítások a megrendelővel, illetve a leendő felhasználókkal történő konzultáció(k) alapján alakulnak ki Ezeket részletesen kifejtjük, írásba foglaljuk Aláíratjuk a felhasználóval Ez alkotja a rendszerspecifikációt 6
Rendszer- és szoftvertervezés A rendszertervezés fázisában választjuk szét a hardver és szoftver követelményeket Kialakítjuk a rendszer átfogó architektúráját A szoftvertervezés fázisában meghatározzuk az alapvető szoftverabsztrakciókat, azaz eldöntjük, hogy a rendszer egyes elemeit milyen szoftvereszközökkel fogjuk megvalósítani Meghatározzuk az elemek közötti kapcsolatokat Mindezt írásban rögzítjük 7
Implementáció és egységteszt Ebben a fázisban megvalósítjuk a szoftvertervben meghatározott szoftvermodulokat Az egységteszt ellenőrzi, hogy az egyes modulok megfelelnek-e a specifikációnak 8
Integráció és rendszerteszt Integráljuk az elkészült programmodulokat Teszteljük a teljes rendszert Célszerű fokozatosan végezni az integrációt és a tesztelést először két modult integrálunk és tesztelünk majd hozzákapcsoljuk a harmadikat, és teszteljük és így tovább, amíg minden modult be nem építettünk a rendszerbe Sikeres rendszerteszt után a rendszer átadható a megrendelőnek 9
Működtetés és karbantartás Általában ez a szoftver életciklus leghosszabb szakasza, de nem mindig. Mondjunk egy példát, amikor nem így van! Megtörtént a rendszer telepítése és használatbavétele A karbantartás elemei: olyan hibák kijavítása, amelyek nem derültek ki a korábbi fázisokban az egyes modulok továbbfejlesztése a rendszer továbbfejlesztése újabb szolgáltatások megvalósításával 10
Megjegyzések a vízesés modellhez Az egyes fázisok eredményei különböző dokumentumok Ezeket mindkét félnek jóvá kell hagynia, aláírás Elvileg akkor indulhat a következő fázis, amikor az előző sikeresen befejeződött, a gyakorlatban azonban ezek átfedhetik egymást Lehet, hogy vissza kell lépnünk egy korábbi fázisra tervezés közben derül ki, hogy módosítanunk kell a specifikációt implementáció közben derül ki, hogy módosítanunk kell a tervet 11
Megjegyzések a vízesés modellhez A szoftverfolyamat általában nem lineáris folyamat, hanem többszörös iterációk sorozata A leggyakrabban akkor szükséges visszalépés, amikor megváltoznak a megrendelő elvárásai Ha ez gyakran előfordul, az felboríthatja a rendszer struktúráját Ezért a modell akkor használható jól, ha előre ismertek a felhasználói elvárások Maga a gondolkodásmód azonban máskor is jól használható, ha nem ragaszkodunk szigorúan a merev határokhoz 12
Evolúciós fejlesztés Alapelv: fejlesszünk ki egy kezdeti implementációt mutassuk meg a megrendelőnek módosítsuk az elvárásainak megfelelően ezt ismételjük addig, amíg az aktuális verzió teljesen meg nem felel a megrendelő elvárásainak Ez csak akkor alkalmazható, ha a megrendelő elfogadja ezt az eljárást 13
Evolúciós fejlesztés Ez a módszer nem választja szét mereven a specifikációt, a fejlesztést és a validálást, így lehetővé teszi a párhuzamos munkát és a gyors visszacsatolást 14
Az evolúciós fejlesztés típusai 1.Feltáró fejlesztés A folyamat célja, hogy a megrendelővel együtt alakítsuk ki a követelményeket, majd a végleges rendszert A fejlesztés a rendszer ismert részeivel kezdődik Egyre több új funkciót építünk a rendszerbe 2.Eldobható prototípus készítés A folyamat célja, hogy egyre jobban megértsük a követelményeket A prototípus célja, hogy jobban megértsük a megrendelő igényeit 15
Az evolúciós fejlesztés előnyei Hatékonyabb, mint a vízesés modell, ha olyan rendszert akarunk fejleszteni, amely közvetlenül megfelel a megrendelő elvárásainak A rendszerspecifikáció inkrementálisan, fokozatosan fejleszthető Ahogyan egyre jobban megértjük a felhasználó igényeit, azokat beépítjük a specifikációba és magába a rendszerbe 16
Az evolúciós fejlesztés hátrányai A folyamat nem jól látható A rendszerek gyakran szegényesen strukturáltak. A folyamat előrehaladása nem jól látható kívülről, a vezetőség nehezen tudja követni a projekt alakulását A folyamatos változtatások hatására gyakran elromlik a rendszer szerkezete Speciális eszközökre és technikákra van szükség A gyors fejlesztéshez speciális eszközökre van szükség (program generátorok) Ezek nem mindig kompatibilisek más eszközökkel 17
Összehasonlítás A tapasztalatok szerint a rövid élettartamú és kis (kevesebb, mint 100 ezer programsor), vagy közepes (500 ezer sorig) méretű rendszerek esetében az evolúciós fejlesztés a leghatékonyabb A nagy és hosszú élettartamú rendszerek esetében a problémák túlságosan nagy veszélyt jelentenek Ezek esetében egy kombinált eljárás használata javasolt 18
Kombinált megoldás Evolúciós megközelítéssel készítünk egy prototípust, aminek felhasználásával kialakítjuk a pontos specifikációt Eldobjuk a prototípust Vízesés módszerrel újraimplementáljuk a rendszert A rendszer bizonyos részeit, pl. a felhasználói felületet feltáró programozással fejleszthetjük ki leghatékonyabban 19
Formális rendszerfejlesztés A vízesés modellhez hasonló megközelítés, de nagyon precízen, matematikai módszerekkel fogalmazzuk meg a rendszerspecifikációt ezt a specifikációt matematikai transzformációk segítségével fokozatosan átalakítjuk futtatható programmá 20
Formális rendszerfejlesztés A formális specifikációt, elemi transzformációk sorozatával, lépésekben alakítjuk át futtatható programmá Olyan transzformációkat hajtunk végre, amelyekről be tudjuk bizonyítani, hogy helyesek Ezért nincsen szükség arra, hogy a teljes program helyességét bebizonyítsuk 21
A formális rendszerfejlesztés előnye és hátránya Ezt az eljárás szinte képtelenség megvalósítani nagyobb programok esetén, legalábbis nagyon nagy ráfordítás szükséges hozzá Vannak azonban olyan esetek, amikor szükség van arra, hogy formális módszerekkel is garantálni tudjuk a program helyességét: biztonsági rendszerek kritikus rendszerek (űrhajózás, katonaság) A nagy rendszerek közötti kölcsönhatások következményeit azonban ez a módszer sem tudja garantáltan hibátlanul kezelni, erre itt is hasonló tesztelési módszereket kell használni, mint a többi módszertan esetében 22
Újrafelhasználás-orientált fejlesztés Valamilyen szinten minden projektben előfordul, hogy felhasználunk kész komponenseket Amikor észrevesszük, hogy egy adott feladatra létezik kész megoldás, vagy legalább részmegoldás, akkor elővehetjük azt, szükség szerint módosítjuk, majd beépítjük a projektbe Az evolúciós megközelítés esetében ez szinte kötelező a gyors prototípus készítés érdekében A napjainkban divatos komponens alapú tervezés is ezen az ötleten alapszik 23
Újrafelhasználás-orientált fejlesztés A folyamat eleje és vége megegyezik a többi módszertannal, a középső fázisok azonban eltérőek 24
Az újrafelhasználás-orientált fejlesztés fázisai Komponenselemzés: az elkészült követelményspecifikáció alapján meg kell vizsgálni, hogy léteznek-e kész komponensek, amelyek felhasználhatók a követelmények kielégítésére Követelménymódosítás: a talált komponenseket össze kell vetni a követelményekkel gyakori eset, hogy módosítani kell a követelményeket ha ez nem lehetséges, akkor a talált komponens nem használható fel 25
Az újrafelhasználás-orientált fejlesztés fázisai Rendszertervezés újrafelhasználással ebben a fázisban meg kell tervezni a rendszer szerkezetét úgy, hogy a rendelkezésre álló kész komponensek beépíthetők legyenek amelyik feladatra nincsen kész komponens, azt el kell készíttetni Fejlesztés és integráció el kell készíteni az új komponenseket integrálni kell a meglévő és az új komponenseket ebben az esetben az integráció kapja a fő hangsúlyt 26
Újrafelhasználás-orientált fejlesztés előnyei és hátrányai Előnyök: kevesebb modult kell kifejleszteni csökken a költség és az időszükséglet Hátrányok: kompromisszumokat kell kötni a követelményekben lehet, hogy a rendszer így nem elégíti ki a megrendelő igényeit nem rendelkezünk teljes felügyelettel a rendszer minden komponense felett, ez gondot okozhat például a továbbfejlesztés során 27
Folyamatiteráció Minden eddigi módszernek vannak előnyei és hátrányai A legtöbb fejlesztés esetében több megközelítési módot kell alkalmazni, azaz egy hibrid modellt használunk Az is gyakran előfordul, hogy a folyamat egyes fázisait meg kell ismételni például a követelmények megváltozása miatt 28
Hibrid modellek Inkrementális fejlesztés Spirális fejlesztés a specifikációt, a tervezést és az implementálást is kis szakaszokra (inkremensek) osztjuk és ezeket egymás után több fordulóban hajtjuk végre A rendszer fejlesztése egy spirál vonallal jellemezhető a kezdeti vázlattól a kész rendszerig Mindkét módszer esetében a specifikációt a rendszerrel együtt fejlesztjük, így a teljes specifikáció nem lehet része a szerződésnek Ezt nem minden megrendelő fogadja el! 29
Inkrementális fejlesztés A vízesés modell megköveteli, hogy az ügyfél véglegesítse a specifikációt mielőtt a tervezés elkezdődne, a tervezőtől pedig azt, hogy az implementáció megkezdése előtt véglegesítse a rendszertervet Ennek eredménye egy jól menedzselhető, tiszta szerkezet, ami azonban nem nyújt lehetőséget a menet közbeni változtatásokra Az evolúciós megközelítési mód megengedi, hogy későbbre halasszuk a követelményekkel és a tervezéssel kapcsolatos döntéseket, ennek azonban egy gyengén strukturált, nehezen menedzselhető rendszer a következménye Jó lenne kombinálni a két módszer előnyeit! 30
Inkrementális fejlesztés 31
Inkrementális fejlesztés A vázlatos követelménymeghatározás után csoportokba soroljuk az elvárásokat Kiválasztjuk a megrendelő számára legfontosabb funkciókat Az ezeket megvalósító inkremenst a legmegfelelőbb módszertan szerint részletesen specifikáljuk, megtervezzük, kifejlesztjük, teszteljük és integráljuk a rendszerbe A megrendelő elkezdheti használni a részrendszert Ha minden igényt kielégítettünk, akkor készen vagyunk Ha maradtak még kielégítendő követelmények, akkor folytassuk a következő inkremenssel 32
Az inkrementális fejlesztés előnyei A megrendelőnek nem kell megvárnia, amíg a teljes rendszer elkészül, ha az első inkremensbe soroljuk a legfontosabb funkciókat, akkor ezeket már a fejlesztés legelején használatba veheti Az inkremensek specifikálásához felhasználhatjuk a korábbiak implementálása, sőt akár használata során szerzett tapasztalatokat Kisebb az esélye annak, hogy a teljes projekt kudarcba fullad, legalább részben nagy valószínűséggel elkészül 33
Az inkrementális fejlesztés előnyei Minden inkremenst a legmegfelelőbb módszertannal fejleszthetünk Ha a legfontosabb szolgáltatásokat az első inkremensekbe soroljuk, akkor ezeket fogjuk a legtöbbször használni, tesztelni, mielőtt a teljes fejlesztés véget ér, így kisebb az esélye annak, hogy kritikus funkciókban hibák maradnak 34
Spirális fejlesztés A szoftverfolyamatot egy spirálként ábrázoljuk. Minden egyes kör a folyamat egy-egy fázisának felel meg legbelső kör: megvalósíthatóság a követelmények meghatározása a rendszer tervezése Minden egyes ciklust négy fázisra bontunk, amelyek minden ciklusban hasonló jellegű tevékenységet jelentenek 35
36
A spirális fejlesztés ciklusainak négy fázisa Célok kijelölése: az adott ciklus által kitűzött célok meghatározása azonosítani kell a projekt kockázati tényezőit, és azoktól függően alternatív stratégiákat kell tervezni Kockázat becslése és csökkentése: minden egyes kockázati tényezőre vonatkozóan részletes elemzést kell végezni meg kell próbálni csökkenteni a kockázatot például, ha felmerül, hogy a követelmények nem megfelelőek, akkor célszerű fejleszteni egy prototípust 37
A spirális fejlesztés ciklusainak négy fázisa, folyt. Fejlesztés és validálás: a kockázatok vizsgálatának eredményétől függően választani kell egy fejlesztési modellt, például ha a felhasználói felületet érezzük kockázatosnak, akkor választhatjuk az evolúciós fejlesztést ha a biztonsági kockázatokat találtuk a legfontosabbnak, akkor használjuk a formális transzformációkat végezzük el a fejlesztést és ellenőrizzük a kész modult Tervezés meg kell vizsgálni a projektet, és el kell dönteni, hogy folytassuk-e a következő ciklussal 38
A spirális fejlesztés értékelése Más módszerekkel szemben kifejezetten számol a kockázati tényezőkkel Kockázat minden olyan dolog, ami elromolhat a projekt folyamán Ebben a modellben nincsenek kötelezően előírt fázisok, mint specifikáció, vagy tervezés Magába illeszthet bármilyen más módszertant, minden ciklusban eldöntjük, hogy ezt milyen módszerrel fejlesztjük ki 39
A szoftverfolyamat alapvető elemei A következőkben megvizsgáljuk közelebbről a szoftverfolyamat alapvető szakaszait, amelyek valamilyen formában minden módszertannak részét képezik: Szoftverspecifikáció Szoftvertervezés és implementáció Szoftvervalidáció Szoftverevolúció 40
Szoftverspecifikáció Más szóval követelménytervezés Ezt a fázist, gyakran nem veszik elég komolyan Az itt elkövetett hibák, pontatlanságok alapvetően befolyásolják a projekt eredményét A követelménytervezés eredménye a követelménydokumentum 41
A követelménytervezés folyamata 42
A követelmények tervezésének négy fázisa 1. Megvalósíthatósági tanulmány meg kell becsülni, hogy a felhasználók kívánságai kielégíthetők-e az adott körülmények között el kell dönteni, hogy a rendszer költséghatékony-e, megvalósítható-e az adott költségvetésből viszonylag gyorsan, hatékonyan el kell dönteni, hogy érdemes-e belefogni a projektbe 43
A követelmények tervezésének négy fázisa 2. Követelmények feltárása és elemzése Tisztázni és dokumentálni kell, hogy milyen elvárásoknak kell megfelelnie a majdani rendszernek Eszközei: a megrendelővel, potenciális felhasználókkal folytatott megbeszélések a jelenleg rendszer(ek) alapos tanulmányozása különböző rendszermodellek, prototípusok felállítása 44
A követelmények tervezésének négy fázisa 3. Követelményspecifikáció az elemzés eredményéül kapott információkat egy egységes dokumentummá alakítjuk Tartalmilag és formailag két részre tagolódik: felhasználói követelmények a megrendelők, felhasználók számára fogalmazzák meg a rendszerrel szemben fennálló absztrakt elvárásokat, ennek megfelelő formában és nyelvezetben kell készülnie rendszerkövetelmények a fejlesztők számára tartalmazzák a konkrét elvárásokat a rendszerrel szemben, tulajdonképpen megadjuk, hogy milyen funkciókkal kell rendelkeznie a rendszernek 45
A követelmények tervezésének négy fázisa 4. Követelményvalidáció ennek keretében ellenőrizendő, hogy mennyire valósak, konzisztensek, és mennyire teljesek a követelmények fel kell tárni és ki kell javítani az esetleges hibákat A folyamat végén a megrendelővel el kell fogadtatni, alá kell íratni a követelménydokumentumot Ennek alapján fognak dolgozni a fejlesztők, ha ebben hiba van, akkor a rendszer biztosan hibás lesz, ezért mindkét fél érdeke, hogy alapos munkával készüljön el, és mindkét fél elfogadja 46
Szoftvertervezés és implementáció Nem más, mint a rendszerspecifikáció futtatható programmá történő konvertálása Mindig magába foglalja a rendszer megtervezését, és a programozást, de például az evolúciós megközelítés esetén a specifikáció finomítását és tartalmazhatja 47
Szoftvertervezés Ki kell alakítani az elkészítendő rendszer szerkezetét, a komponensek közötti kapcsolatokat és az interfészeket Meg kell tervezni az adatok áramlási rendszerét a komponensek között A tervezés szinte soha nem egylépcsős folyamat, rendszerint többszörös iteráció és visszalépés után jutunk el a végeredményig. 48
A tervezési folyamat 49
A tervezési folyamat tevékenységei Architekturális tervezés: Absztrakt specifikáció: meghatározzuk és dokumentáljuk a rendszert felépítő alrendszereket, és a köztük lévő kapcsolatokat minden alrendszerre megadjuk a szolgáltatások specifikációját, és a rájuk vonatkozó követelményeket Interfész tervezése: minden alrendszerre meg kell tervezni és dokumentálni kell a többi alrendszer felé nyújtott interfészét ennek olyan egyértelműnek kell lennie, hogy anélkül tudjuk használni a szolgáltatásokat, hogy foglalkoznunk kellene az alrendszer belsejével 50
A tervezési folyamat tevékenységei Komponens tervezése: Adatszerkezet tervezése: meg kell tervezni az egyes szolgáltatásokat megvalósító komponenseket és azok interfészeit. meg kell tervezni a program által használt adatszerkezeteket Algoritmus tervezése: meg kell tervezni a programban használatos algoritmusokat Ez egy általános modell, a gyakorlatban ezek a lépések nagyon sokféleképpen variálhatók 51
Tervezési módszerek A gyakorlatban a tervezés legtöbbször egy ad hoc folyamat, nincs mögötte módszertan A tervező kiindulva a követelményekből elképzel és leír egy rendszert általában természetes nyelven, nem formálisan Ennek alapján megindul az implementáció, aminek során legtöbbször eltérnek a tervtől, és ezt már nem dokumentálják, így az elkészült rendszer és a terv jelentősen eltérhet egymástól Ez jelentősen megnehezíti a rendszer későbbi üzemeltetését, továbbfejlesztését 52
Tervezési módszerek Az évek során többféle tervezési módszertant dolgoztak ki, amelyek különböző módokon formalizálják a tervezési folyamatot Strukturált tervezési módszertanok: Structured Design (Constantine, Yourdon, 1979) Structured System Analysis (Gane, Sarson, 1979) Jackson System Development (Jackson, 1983) Objektumorientált tervezési módszertanok: Robinson, 1992 Booch, 1994 Raumbaugh és mások, 1991 Booch és mások, 1999 Raumbaugh és mások, 1999a, 1999b 53
Strukturált tervezési módszertanok Különböző, legtöbbször grafikus rendszermodelleket tartalmaznak Szabványos jelölésrendszereket alakítottak ki Szabványos tervezési dokumentumokat határoznak meg Különböző CASE eszközöket is kialakítottak ezek támogatására CASE: Computer Aided Software Engineering A különböző módszertanok a hasonlóság mellett kisebb módosításokkal specializálódtak bizonyos területekre Nincsen egyértelműen jobb, vagy rosszabb módszer 54
Strukturált tervezési módszertanok A különböző módszertanok meghatároznak: tervezési folyamatmodellt jelölésrendszert a terv leírásához jelentésformátumokat szabályokat tervezési útmutatókat 55
Strukturált rendszermodellek A különböző módszertanok a következő rendszermodellek közül támogatnak egyet, vagy többet: Adatfolyam modell a rendszert különböző adattranszformációk segítségével modellezzük Egyed-kapcsolat (ER-Entity-Relationship) modell különböző egyedek és köztük lévő kapcsolatok leírására szolgál. Az ER-modellek az adatbázis-szerkezetek leírásának modelljei is. 56
Strukturált rendszermodellek Folytatás Strukturált modell Objektumorientált módszerek a rendszer komponenseit és a köztük lévő kölcsönhatásokat dokumentálja a rendszer öröklődési modelljét tartalmazzák, modellezik a statikus és dinamikus kapcsolatokat az objektumok között, és az objektumok együttműködését Egyes módszerek más rendszermodelleket is használnak pl. állapotátmenet-diagrammok, egyed-élettartam mátrixok, stb. 57
Programozás és nyomkövetés A megtervezett rendszer elkészítése, és az esetleges hibák megkeresése, kijavítása Bizonyos részeit CASE eszközökkel is lehet generálni A programozás még ma is meglehetősen személyes tevékenység, ahány programozó, annyi stílusban dolgozik A programozás közben folyamatosan teszteljük a kódot, megkeressük a hibákat, és kijavítjuk őket Ezt nevezzük nyomkövetésnek, belövésnek 58
Debugger Programozói segédeszköz a programhibák felderítésére, és kijavítására Legfontosabb funkciói: a program soronkénti végrehajtása töréspontok kezelése, feltételes töréspontok a változók értékének figyelése, módosítása futás közben a memória tartalmának figyelemmel kísérése assembly szintű nyomkövetés a processzor regisztereinek figyelése, módosítása a hívási verem (call stack) megfigyelése 59
Szoftvervalidáció Verifikáció és validáció Megvizsgálandó, hogy az elkészült rendszer megfelel-e a specifikációnak Az implementáció teljes ideje alatt folyamatosan folyik, de a rendszer elkészülte után feltétlenül szükség van alapos tesztelésre Egy összetett rendszer tesztelését alaposan meg kell tervezni, és részletekben kell elvégezni 60
A tesztelési folyamat 61
A tesztelési folyamat szakaszai Egység tesztelése Modul tesztelése minden egyes komponenst önmagában tesztelni kell, és el kell érni, hogy hibátlan legyen a modul egymással összefüggő komponensek gyűjteménye ezeket a többi modultól függetlenül lehet tesztelni Alrendszerek tesztelése az alrendszert alkotó modulok tesztjeinek összessége, kiegészítve a köztük lévő kapcsolatok, az interfészek tesztelésével 62
A tesztelési folyamat szakaszai Rendszerek tesztelése a teljes rendszer tesztelése, különös tekintettel az alrendszerek kapcsolódásainak vizsgálatára a rendszerhibák legnagyobb része az alrendszerek kölcsönhatásaiból származik, ezeket a hibákat csak a rendszer tesztelése során lehet felderíteni ezen a szinten kell megvizsgálni, hogy a rendszer teljesíti-e a specifikációban meghatározott funkcionális és nem funkcionális követelményeket 63
A tesztelési folyamat szakaszai Átvételi tesztelés a tesztelés legutolsó fázisa a rendszer használatbavétele előtt ekkor már a megrendelő saját adataival folyik a tesztelés szerencsés, ha a megrendelő is részt vesz benne ekkor derülhetnek ki a követelménytervezés során elkövetett hibák, hogy a rendszer nem felel meg a felhasználó elvárásainak, vagy a rendszer teljesítménye elfogadhatatlan 64
Alfa és béta tesztelés Az átvételi tesztet szokás alfa tesztelés-nek hívni Amikor egy szoftvertermék dobozos termékként kerül piacra, akkor szokás a béta teszt-nek nevezett eljárást használni A béta teszt során a potenciális felhasználók egy részéhez juttatják el a programot, akik valós, éles körülmények között kezdik el használni a szoftvert, valamilyen szerződés keretében Tapasztalataikról beszámolnak a fejlesztőknek, akik ezeket felhasználják a rendszer javítására Az elkészülő új verziót egy újabb béta tesztre bocsátják Ez ismétlődik amíg a rendszer minősége el nem éri a kívánt szintet 65
Szoftverevolúció Miután egy hardver eszköz gyártása elkezdődik, bármilyen változtatás szinte lehetetlen, illetve nagyon költséges A szoftver esetében azonban a fejlesztés (gyártás) alatt bármikor elvégezhető bármilyen módosítás Sőt az sem lehetetlen, hogy a felhasználónál lévő szoftveren hajtsunk végre módosításokat Ezért van értelme szoftverevolúcióról beszélni 66
Szoftverevolúció Ez a korszerű felfogás a szoftverevolúcióról A szoftverrendszerek egész életciklusuk alatt változhatnak, fejlődhetnek 67
Rational Unified Process (RUP) egy modern folyamatmodell, az UML-ből származik hibrid modell, mindegyik általános modellből tartalmaz elemeket támogatja az iterációt míg a hagyományos modellek a folyamatoknak csak egy-egy nézetét támogatják, addig a RUP három perspektívával rendelkezik 68
A RUP perspektívái 1.dinamikus perspektíva a modell fázisait mutatja 2.statikus perspektíva a végrehajtandó folyamattevékenységeket mutatja 3.gyakorlati perspektíva jól hasznosítható gyakorlatokat javasol a folyamat alatt 69
A RUP fázisai 1.Indítás a projekt üzleti vonatkozásainak tisztázása. kik lesznek a projekt résztvevői, ezek kapcsolatai el kell dönteni, hogy elindítsuk-e a projektet 2.Előkészítés célja a probléma megértése, a projektterv kifejlesztése a kulcsfontosságú kockázati tényezők azonosítása Eredménye: a rendszerkövetelmények modellje (UML használati eset) architekturális leírás a szoftver fejlesztési terve 70
A RUP fázisai 2 3.Létrehozás a rendszerterv elkészítése implementáció tesztelés 4.Átadás a rendszer áttelepítése a fejlesztési környezetből a felhasználói környezetbe 71
A RUP fázisai A RUP két szinten támogatja az iterációt, lásd az ábrán! 72
A RUP statikus munkafolyamatai 73
A RUP fázisok és folyamatok kapcsolata A RUP fázisai és munkafolyamatai nincsenek kötelező érvénnyel egymáshoz rendelve Elméletileg bármely munkafolyamat bármelyik fázisban lehet aktív Persze ritkán történik Tesztelés az Indítás fázisban, de ez a tervező döntése 74
A RUP gyakorlati perspektívája Fejlesszük a szoftvert iteratívan Kezeljük a követelményeket tervezzük meg a rendszer inkremenseit a prioritások alapján, és hozzuk előre a magas prioritású tulajdonságokat dokumentáljuk a megrendelő követelményeit, és tartsuk mindig karban annak változásait elemezzük a változások rendszerre gyakorolt hatásait mielőtt elfogadnánk azokat Használjunk komponens alapú architektúrákat a rendszert szervezzük komponensekbe 75
A RUP gyakorlati perspektívája 2 Modellezzük a szoftver vizuálisan Ellenőrizzük a szoftverminőséget használjunk grafikus UML-modelleket a szoftver statikus és dinamikus nézeteihez bizonyosodjunk meg róla, hogy a szoftver megfelel a minőségi előírásoknak Ellenőrizzük a szoftverváltoztatásokat menedzseljük a szoftverváltoztatásokat változtatáskezelési eszközökkel és konfigurációkezelési eljárásokkal 76
A RUP értékelése A RUP nem alkalmas minden különböző típusú szoftver kifejlesztésére, de az általános folyamatok új generációjának tekinthető Legfontosabb újítása: a fázisok és a munkafolyamatok szétválasztása az üzembeállítás beemelése a munkafolyamatok közé A fázisok dinamikusak és konkrét célokkal rendelkeznek A munkafolyamatok statikusak és olyan technikai tevékenységeket írnak le, amelyek felhasználhatók az egész fejlesztés folyamán 77
Számítógéppel támogatott szoftvertervezés (CASE) Computer-Aided Software Engineering (CASE) Olyan szoftverek együttese, amelyek a szoftverfolyamat egyes tevékenységeinek támogatására szolgálnak Ismerünk már ilyen eszközöket, soroljuk fel ezeket! Most megismerkedünk újabb típusokkal 78
Néhány példa CASE eszközök használatára grafikus rendszermodellek fejlesztése a tervek megértését segítő adatszótárak kezelése felhasználói interfész tervezése és implementálása program belövés támogatása, debuggerek kódgenerálás automatikus fordítás egyik programnyelvről egy másikra, pl. COBOL 79
A CASE technológiák elterjedése Napjainkban a szoftverfolyamat szinte minden fázisához léteznek CASE eszközök, legtöbbször a rutintevékenységeket támogatják Ennek hatására javult a szoftverek minősége, de ez kisebb mértékű. mint ahogyan kezdetben gondolták, egyes mérések szerint kb. 40%-os a javulás A CASE technológia kezdeti pártolói nagyságrendi javulást jósoltak Nem vált valóra az a várakozás sem, hogy a CASE lényegesen csökkenti a szoftverfolyamat költségeit 80
A CASE technológiák korlátai Miért nem következhetett be a várt nagyságrendi változás? a szoftvertervezés tervezői tevékenység, ami kreatív gondolkodáson alapszik, a CASE eszközök azonban ebben nem sokat tudnak segíteni, azok csak a rutintevékenységeket tudják támogatni, csak kisebb mértékben tudnak a mesterséges intelligencia eszközeivel segíteni a szoftvertervezés nagyrészt csoportos tevékenység, állandó kommunikációt, egyeztetést igényel, ebben is csak kisebb segítséget tud nyújtani a számítógép Párhuzam: gépi fordítás 81
A CASE eszközök osztályozása Három szempontból fogjuk osztályozni a CASEeszközöket: funkcionális szempontból: folyamatnézőpontból: a CASE eszközök funkciói szerint milyen folyamatot támogatnak integrációs nézőpontból: hogyan vannak integrált egységekbe szervezve 82
Funkcionális osztályozás 83
Folyamatközpontú osztályozás 84
Integrációs szempontú osztályozás Eszközök Eszközkészletek az egyéni folyamatlépéseket támogatják, például fordítóprogram, tesztelőeszközök, stb. a munkafolyamat egy-egy fázisát támogatják, például a specifikációt, tervezést, stb. ezek legtöbbször a fenti eszközökből összeállított csomagok, készletek Környezetek a szoftverfolyamat több, lehetőleg minden részét támogatják egy integrált keretben 85
CASE eszközök, eszközkészletek, környezetek osztályozása 86