Szoftvertechnológia 2008/2009. tanév 2. félév 7. óra
Szoftvertechnológia
© Szabolcsi Judit 2008
Szoftvertechnológia 2008/2009. tanév 2. félév 7. óra (Ajánlott irodalom: : Ian Somerville: Szoftverrendszerek fejlesztése. Második, bıvített, átdolgozott kiadás, Panem Kiadó, Budapest 2007.) VIII. A követelmények feltárása és elemzése A követelménytervezés (szoftverspecifikációs folyamat) második nagy tevékenysége (lásd II.1. rész). E tevékenység során együtt kell mőködni a szoftverfejlesztıknek a megrendelıkkel és a végfelhasználókkal. Itt ki kell választani az úgynevezett kulcsfigurákat, olyan személyeket vagy csoportokat, akiknek közvetett vagy közvetlen befolyása lehet a rendszerkövetelményekre. A feltárás és elemzés nehézségeinek okai: • A kulcsfigurák gyakran nem tudják pontosan, mit várnak el a számítógépes rendszertıl. Bonyolult lehet számukra annak kifejezése, mit akarnak a rendszertıl; valóságtól elrugaszkodott kívánságaik lehetnek, mivel nincsenek tisztában a költségekkel. • A rendszer kulcsfigurái a saját szakterületi fogalmaikkal fejtik ki a követelményeket. • Az egyes kulcsfiguráknak különbözı követelményeik vannak, ebben a követelménytervezıknek fel kell fedezniük a közös dolgokat és ellentmondásokat. • A rendszerkövetelményeket politikai tényezık is befolyásolhatják. Lehetnek olyan vezetık, akik azért igényelnek specifikus rendszerkövetelményeket, hogy ezzel növeljék a szervezeten belüli befolyásukat. • A gazdasági és az üzleti környezet eközben dinamikusan változik, új kulcsfigurák jelenhetnek meg, újabb követelményekkel. A feltárási és elemzési folyamat általános modellje: act köv etelmények feltárása és elemzé... köv etelmények specifikációj a köv etelmények dokumentációj a
köv etelmények ellenırzése
vége szakterület megismerése
fontossági sorrendbe állítás
kezdés
köv etelmények összegyőj tése
ellentmondások feloldása
osztályozás
Szoftvertechnológia 2008/2009. tanév 2. félév 7. óra 1. A szakterület megismerése. Az elemzıknek fejleszteniük kell az alkalmazás szakterületére vonatkozó ismereteiket. 2. Követelmények összegyőjtése. A rendszer kulcsfiguráival való együttmőködés. Eközben javul a szakterület megértése. 3. Osztályozás. A követelmények strukturálatlan győjteményét összefüggı csoportokba szervezi. 4. Ellentmondások feloldása. Ahol több kulcsfigura is érintett, elkerülhetetlen, hogy a követelmények ellentmondása ne kerüljenek. 5. Fontossági sorrend felállítása. A kulcsfigurákkal együttmőködve, kiválasztjuk a legfontosabb követelményeket. 6. Követelményellenırzés. Teljes-e, ellentmondásmentes-e és összhangban van-e azzal, amit a kulcsfigurák a rendszertıl valójában várnak. A továbbiakban a követelmények feltárására és elemzésére három technikát nézünk meg. VIII.1. Nézıpont-orientált feltárás A közepes vagy nagy rendszerek esetén a végfelhasználók általában különbözı típusokba sorolhatók. Ismét a banki pénzkiadó rendszert (ATM) véve példának: • a bank jelenlegi ügyfelei: akik számára a rendszer szolgáltatást nyújt • más bankok képviselıi: akiknek kölcsönös megállapodásuk van egymás ATM-jeinek használatáról • a bankfiókok vezetıi: akik vezetıi információkat nyernek a rendszerbıl • a bankfiók alkalmazottai: akiknek feladata a rendszer napi mőködtetése, az ügyfelek panaszainak kezelése • a bank marketing osztálya: amely a rendszert marketingcélokra használja • hardver- és szoftverkarbantartó mérnökök: akik a hardver- és szoftverelemek karbantartásáért és fejlesztéséért felelnek • stb. Ebbıl is látszik, hogy még egy viszonylag egyszerő rendszer esetén is sok különbözı nézıpontra kell tekintettel lennünk. Ezek a perspektívák általában átfedik egymást. A nézıpont-orientált szemlélet legfıbb erıssége az, hogy felismeri a többféle perspektíva létezését, és eszközöket ad a különbözı kulcsfigurák által javasolt követelmények ellentmondásainak felderítésére. A különbözı módszerek mást és mást értenek a „nézıpont” szó alatt. Nézıpont lehet: • adatforrás vagy adatnyelı • reprezentációs eszközkészlet • a szolgáltatások fogadója Az interaktív rendszereknél az utolsó szemléletmód a legcélravezetıbb. Ebbıl a csoportból egy konkrét módszer a VORD (Viewpoint-Oriented Requirements Definition). A VORD-ben a nézıpont- és szolgáltatás információk szabványos őrlapok segítségével kerülnek összegyőjtésre. Emellett használ még nézıpont-hierarchia diagramokat és esemény forgatókönyveket is. Pl.: ATM Elsı lépés a lehetséges nézıpontok azonosítása. Ez ötletgyőjtéssel történhet, amikor a kulcsfigurák összejönnek és lehetséges nézıpontokat javasolnak. Következı lépés a nézıpontok és a szolgáltatások azonosítása. A szolgáltatásokat ajánlott a nézıpontokhoz elhelyezni. Egy szolgáltatás több nézıponthoz is tartozhat. A szolgáltatások felsorolása mellett a nézıpontok bemenetet is biztosítanak ezekhez a szolgáltatásokhoz. Pl.: Az ATM használóknak pénzfelvételkor
Szoftvertechnológia 2008/2009. tanév 2. félév 7. óra meg kell adniuk a kívánt pénzösszeget. A nézıpontok vezérlı információ is nyújtanak annak megállapítására, hogy a szolgáltatások felkínálásra kerülnek-e és ha igen, mikor. A vezérlı információt az automatán lévı gombok biztosítják, az adatokat pedig a felhasználó kártyája és a billentyőzet. Ezután elkészíthetjük a nézıpont-hierarchia diagramot. A következı lépésben kitöltjük a szolgáltatás- és nézıpont-sablonokat. Végül elkészítjük az esemény-forgatókönyveket, és keresztellenırzést végzünk a hibák és az ellentmondások felderítésére. A VORD-módszerhez CASE-eszközt érdemes használni. VIII.2. Forgatókönyvek Az emberek általában könnyebben kezelik a valós életbeli problémákat, mint az absztrakt leírásokat. A forgatókönyvek interakciósorozatok leírásai. A következı részekbıl állnak: • a rendszer kezdeti állapotának leírása • a forgatókönyvbeli események normális menetének leírása • egy leírás arról, hogy mi romolhat el és ezt hogyan kezeli a rendszer • egyéb tevékenységek leírása, amelyek ugyanabban az idıben mehetnek végbe • a rendszer végállapotát a forgatókönyv befejezésekor A forgatókönyveknek két fı típusa van: esemény-forgatókönyvek és a használati esetek. A VORD módszer esemény forgatókönyvet használ. A használati esetek (use-case-ek) az UML jelölésrendszer részei. A use-case diagramokat sorrenddiagrammal szokás kiegészíteni, ezek mutatják a további információkat. VIII.3. Etnográfia Megfigyelésen alapuló technika, amely felhasználható a társadalmi és szervezeti követelmények megértéséhez. Az elemzı elmélyed abban a munkakörnyezetben, ahol a rendszert majd használni fogják, megfigyeli a napi munkát és jegyzeteket készít. Az emberek gyakran nehéznek találják kifejezni munkájuk részleteit. A saját munkájukat megértik, de azt valószínőleg nem, hogy az milyen összefüggésben áll a szervezet többi részével. Azok a társadalmi és szervezeti tényezık, amik a munkát érintik, de az egyének számára nem nyilvánvalóak, csak akkor válhatnak világossá, ha egy tárgyilagos külsı szemlélı észreveszi ıket. Az etnográfia különösen hatékony a követelmények két típusának felderítésénél: • Azoknál a követelményeknél, amelyek az emberek tényleges munkavégzési módjából erednek, nem pedig abból, ahogyan a folyamatdefiníciók szerint kellene dolgozniuk. Pl.: a légiforgalomirányítók kikapcsolhatják azt a összeütközési riasztórendszert, amely a légi jármővek egymást keresztezı útvonalait érzékeli, annak ellenére, hogy a használatát a szabványok elıírják. Ha úgy tervezik meg a pályákat, hogy a repülık eltávolodnak egymástól mielıtt még ez problémát okozna, akkor a riasztórendszer csak akadályozná ıket a munkában. • Azoknál a követelményeknél, amelyek az együttmőködésbıl és a más emberek tevékenységének számon tartásából erednek. Pl.: a légiforgalom-irányítók felhasználhatják a többi irányító adatait annak megjósolására, hogy hány repülı lép majd be az ı szektorukba. Ezért egy önmőködı légi irányítási rendszernek ajánlott lehetıvé tenni a szektorbeli irányítók számára, hogy valamelyest belelássanak a szomszédos szektorok munkájába.
Szoftvertechnológia 2008/2009. tanév 2. félév 7. óra Kérdések (A válaszok beküldhetık: március 30-a délig) 1. Milyen tartós és átmeneti követelmények lehetnek egy könyvelıprogramnál? Legalább 2-2-t említsen! (Átmeneti követelmények: amik valószínőleg változni fognak a rendszerfejlesztési folyamat során, vagy a rendszer beüzemelése után.) (4 pont) 2. Készítsen egy levelezıprogramhoz (pl. Mozilla Thunderbird, The Bat, Outlook, stb.) használati eset (use-case) diagramot, amelynek segítségével össze lehet győjteni a rendszer követelményeit. (5 pont)
