Objektumorientált szoftverfejlesztés. Követelmények tervezése

Átírás

1 Objektumorientált szoftverfejlesztés Követelmények tervezése Selmeci István, 2003

2 Tartalom Követelmény menedzsment követelmények tervezése... 3 A követelmények tervezésének jelentősége... 3 A fejlesztési projektek bukásának okai... 4 A követelmények menedzselésének lépései, eszközei... 4 A követelmények tervezése... 4 A követelmények tervezésének fázisai... 5 A követelmények tervezésének eszközei... 6 Követelmények csoportosítása... 8 Felhasználói követelmények... 8 Rendszerkövetelmények... 8 Funkcionális és nem funkcionális követelmények... 8 Példa a követelmények tervezésére A feladat A jelenlegi rendszer A folyamat pontosítása A feladat pontosítása A végleges feladatleírás A követelmények ábrázolása használati eset modellben A kazettakölcsönzési feladat használati eset modellje Következtetések Üzleti folyamatok modellezése A modell elemei Események Output Célok A folyamatok modellezésének jelentősége Hálós követelménymodell Követelmények gyűjtése, rendszerezése Szöveges követelménylista Követelmény diagram Követelmények és használati esetek Követelmények részletezése, lebontása Összefoglalás

3 Követelmény menedzsment követelmények tervezése A követelmények tervezésének jelentősége A szoftvereket emberek (felhasználók) számára készítik, akik azokat céljaik elérése érdekében használják. A felhasználói célok teljesítése a legtöbbször bonyolult, egymással összefüggésben álló tevékenységek elvégzését jelenti, melyek során részcélokat teljesítünk. A felhasználói célok, részcélok a szoftver fejlesztői felé követelményként jelentkeznek, melyeket az alkalmazásnak ki kell elégítenie. A szoftver-követelmények az összetett felhasználói céloktól a kisebb részcélok teljesítésén át a gazdasági-technikai szintű szabályokig, előírásokig terjednek. Követelmény: olyan feltétel, képesség, szolgáltatás, melynek teljesítését (vagy az annak való megfelelést) elvárjuk a tervezett alkalmazástól. Az adott szoftverrel kapcsolatos követelmények feltárása, rendszerbe foglalása döntő jelentőségű a fejlesztés szempontjából, hiszen olyan szoftvert kell készíteni, amely megfelel a felhasználók igényeinek. A fejlesztés sikerének alapvető feltétele, hogy belül maradjunk az idő- és költségvetési korlátokon, és a végtermék pontosan megfeleljen a megrendelő elvárásainak. Ez nem egyszerű, mivel a követelmények a fejlesztés ideje alatt változhatnak. A követelmények rendszerezésével, változásaik nyomon követésével és ezek folyamatos dokumentáción való átvezetésével nagymértékben elősegíthetjük projektünk sikerét. A követelmények megváltozása egyáltalán nem ritka, és azoknál a fejlesztéseknél, amelyeknél a tervezés és kódolás egy korábban véglegesen rögzített követelményrendszer alapján készül, sokszor vezet kudarchoz: az időközben megváltozott felhasználói igények, prioritások miatt már nem arra a szoftverre lenne szükség, mint ami elkészült. Ennek elkerülése érdekében a követelményeket, azok változásait a fejlesztés teljes folyamatában figyelemmel kell kísérni, a terveket és program-prototípusokat pedig folyamatosan hozzá kell igazítani ezekhez a változásokhoz. A követelmények ilyen típusú kezelését nevezzük követelmény-menedzsmentnek. Követelmény menedzsment: a követelmények feltárása, rendszerezése és dokumentálása a követelmények változásainak nyomon követése A követelmény menedzsment folyamatos tevékenység, amely végigkíséri a fejlesztés teljes folyamatát. Célja a követelmények feltárása, rendszerezése, dokumentálása. További fontos feladata a követelmények változásának nyomon követése és ezek érvényesítése a fejlesztési folyamatra. 3

4 A követelmény menedzsment sikeres alkalmazása olyan minőségi termék előállításához vezet, amely megfelel a felhasználók igényeinek, a fejlesztés időtartama és költségei pedig a tervezett értékeken belül maradnak. A fejlesztési projektek bukásának okai. A fejlesztési projektek egy jó része sikertelen; túllépik finanszírozhatóságuk határát, kicsúsznak a határidőkből, esetleg éppen félúton megszakadnak. A befejezett projektek nem kis hányadánál pedig végül kiderül, hogy a megrendelő számára értéktelen, mert a termék nem felel meg igényeinek. Felmérések szerint a bukások leggyakoribb okai a felhasználói oldal egyes problémáiból, illetve a követelmények változásainak figyelmen kívül hagyásából származnak. Ez utóbbi ok leginkább abból származik, hogy: a követelmények igen érzékenyek az idő múlására, nehéz őket számba venni és dokumentálni a tervben figyelmen kívül hagyott változások végigkísérik a fejlesztést, és a végterméket egyre inkább eltávolítják az elvárt eredménytől A sikeres követelmény menedzselés érdekében alaposan meg kell ismernünk a szakterületet, melynek számára fejlesztünk, fel kell tárnunk a folyamatok lényeges elemeit és ezek kulcsszereplőit és persze célszerű megfelelő eszközt használni, amely jól támogatja a követelmény menedzsment feladatait. A követelmények menedzselésének lépései, eszközei Az alábbiakban bemutatjuk a követelmény menedzsment fő lépéseit és eszközeit. A lépések sorrendje, alkalmazásuk száma nem kötött és egyszeri, hiszen maga a fejlesztési folyamat is iteratív. A követelmények tervezése Mint korábban láttuk, a rendszer szolgáltatásainak és az ezekkel kapcsolatos megszorításoknak a leírásait nevezzük a rendszerrel szembeni követelményeknek. A szolgáltatások és megszorítások tehát a követelmények - kitalálása, feltárása, elemzése, dokumentálása és ellenőrzése a követelménytervezés. 4

5 A követelmények tervezésének fázisai A rendszerfejlesztés folyamata egyszeri, illetve ismételt lépések (iterációk) sorozatából áll. A folyamat iterációs jellege a követelmény-menedzselési tevékenység miatt alakul így: a kezdeti követelményhalmaz alapján elkészített tervek és próba-alkalmazások a követelmények változásával módosulhatnak, így áttervezésre, majd újabb prototípusok előállítására lehet szükség. A követelmények tervezése már a rendszerfejlesztés elején, az ún. megvalósíthatósági tanulmány elkészítése során megkezdődik. 1. fázis: A megvalósíthatósági tanulmány A megvalósíthatósági tanulmány az elkészítendő rendszer rövid leírása, elemzése. Ennek során el kell dönteni, hogy a megrendelők igényei egyáltalán kielégíthetők-e a rendelkezésre álló pénzügyi-technikai háttér figyelembe vételével, illetve milyen megoldási alternatívák képzelhetők el. A megvalósíthatósági tanulmánynak tehát össze kell foglalnia a legfontosabb felhasználói követelményeket. 2. fázis: A követelmények pontosítása, részletezése Ebben a szakaszban a fő követelményeket csoportosítjuk. A magas szintű, általánosan megfogalmazott követelményeket kiegészítjük az azokhoz kapcsolódó további követelményekkel. Ennek alapján felállítjuk kezdeti rendszermodellünket (például szakterületi modell formájában), és egyeztetjük azt a felhasználókkal. Ebben a fázisban célunk a rendszer pontosítása és minél jobb megértése. 3. fázis: A követelményspecifikáció elkészítése A feltárás és elemzés során összegyűjtött információkat egységes dokumentumba foglaljuk. Célunk a rendszer belső felépítésének, alrendszereinek meghatározása. A követelményspecifikáció a logikai rendszerterv alapja. 4. fázis: Ellenőrzés Az ellenőrzési szakasz célja az, hogy megállapítsuk: követelménymodellünk megfelele a valós igényeknek, nincsenek-e benne ellentmondások, és tartalmaz-e minden követelményt. Mint korábban említettük, a követelménytervezés végigkíséri a fejlesztési folyamatot, és sok esetben újragondolásra késztet terveinkkel kapcsolatban. Amennyiben gyökeres változás nem áll be a megrendelő elképzeléseiben, a fejlesztési folyamat során a fázis lépéseit hajtjuk végre rendszeresen, így biztosítva a követelmények, a tervek és a kódok naprakészségét, megfelelőségét. 5

6 A követelmények tervezésének eszközei Információk gyűjtése A feladat megismerésének, a fő felhasználói követelményeknek a feltárásához rendszerint az alábbi, széles körben ismert szervezési eszközökből válogatunk: interjúk kérdőívek követelményelemző foglalkozások brainstorming prototípus-elemzés Az összegyűjtött információk ábrázolása, dokumentálása Miután megismertük a szakterületet és feltártuk a főbb elvárásokat, készítsünk dokumentációs tervet. A dokumentációs terv elkészítése előtt döntsük el, hogy a követelmények feltárásához, elemzéséhez és rendszerezéséhez milyen technikákat fogunk alkalmazni: vagyis milyen modellezési módszereket használunk a követelmények tervezésénél. A követelmények modellezéséhez használt technikák körültekintő kiválasztása azért fontos, mert a különböző módszerek különböző lehetőségeket rejtenek magukban: például munkafolyamatok elemzéséhez nem célszerű szerkezeti összetétel bemutatásához használatos eszközt alkalmazni, és fordítva. Használati eset modell Az objektumorientált tervezés UML modellező nyelve a követelmények feltárásához, elemzéséhez kezdetben nem sok lehetőséget biztosított. A szabvány erre a célra a használati eset modellt ajánlotta, melynek segítségével leginkább a felhasználói szintű követelmények, illetve ezekből kiindulva a belső rendszerkövetelmények ábrázolhatók. A használati esetekhez kapcsolódnak a szekvencia diagramok, amelyek a követelmény teljesítéséhez szükséges erőforrásokat és műveleteket mutatják be. A folyamatok lefutását aktivitás diagramokkal is illusztrálhatjuk, illetve a feltárt objektumok belső viselkedését elemezhetjük aktivitás diagramok segítségével. Üzleti folyamat modell Nagyobb rendszerek esetében felmerül az igény egy átfogóbb modell elkészítésére is. Ezt a célt szolgálja az UML szabványhoz később csatlakozó üzleti folyamat modellezés (BPM, Business Process Model), amely az SSADM módszertanban sokszor használt adatfolyam modellekhez hasonló eszköz, de elemei az objektumorientált megközelítést 6

7 tükrözik. Az üzleti folyamat modellezés célja a létező, és/vagy a tervezett rendszer folyamatainak, anyag- és információáramlásának feltárása, bemutatása, megértetése. Hálós követelménymodell Az üzleti folyamatok modellezése leginkább a valós folyamatok feltérképezését szolgálja. A használati eset modell, illetve a hozzá kapcsolódó egyéb modellek pedig a felhasználó és a szoftver kapcsolatából kiindulva közelítik meg a problémát, és már kifejezetten a szoftver kialakítására koncentrálnak. Teljes körű, részletes, de ugyanakkor áttekinthető követelménymodell egyik korábbi módszerrel sem készíthető el. Az ún. hálós követelménymodell segítségével olyan modell készíthető, amely tetszőleges bontásban ábrázolja a követelményeket és kapcsolataikat. Ez a modell nem kötődik munkafolyamatokhoz, és nem kizárólag a szoftver-használat oldaláról közelíti meg a problémát. A hálós követelménymodell segítségével a probléma teljes követelmény-szerkezete ábrázolható, amely mindenfajta követelményt tartalmaz. 7

8 Követelmények csoportosítása A követelmények hierarchikus rendszert alkotnak, a rendszer elemei pedig összefüggésben állnak egymással. Az összefüggések lehetnek közvetlen ok-okozati, származási, illetve egyéb logikai kapcsolatok. A követelményrendszer felépítéséhez célszerű a követelményeket típusokba sorolni. Felhasználói követelmények Magas szintű, gyakran absztrakt követelmények a rendszerrel szembeni legfőbb megrendelői elvárások. Ábrázolásukhoz általában diagramokkal kiegészített természetes nyelvű leírásokat használunk. A cél annak definiálása, hogy milyen szolgáltatásokat várunk el a rendszertől, és annak milyen feltételek, megszorítások mellett kell működnie. A felhasználói követelményeknek a rendszer funkcionális és nem funkcionális követelményeit kell úgy leírniuk, hogy bárki megértse azokat. Célszerűen a rendszer külső viselkedését írják le, és nem térnek ki a belső működés jellemzőire. A felhasználói követelmények leírásánál a kulcsfontosságú igényekre kell koncentrálni. A megfogalmazott követelményeket rövid magyarázó szöveggel látjuk el. Rendszerkövetelmények Rendszerkövetelmények (a felhasználói követelmények részletezése és lebontása). A rendszerszolgáltatások és megszorítások részletes, a felhasználói követelményekhez (is) kapcsolódó leírása funkcióspecifikáció. Az egész rendszer teljes meghatározását tartalmazza, a rendszerterv kiindulási pontja lesz. Tartalmazhat objektummodelleket, adatfolyam modelleket, stb. Funkcionális és nem funkcionális követelmények A követelményeket sokszor célszerű abból a szempontból is vizsgálni, hogy a rendszer működésére vagy a működést befolyásoló egyéb követelményekre vonatkoznak-e. Ebből a szempontból megkülönböztetünk: funkcionális követelményeket: A rendszer által nyújtandó szolgáltatások ismertetése (hogyan kell reagálnia a rendszernek bizonyos eseményekre, hogyan kell viselkednie egyes szituációkban). A funkcionális követelmények a rendszertől várt funkciókat és/vagy szolgáltatásokat írják le. nem funkcionális követelményeket: A rendszer funkcióival és szolgáltatásaival kapcsolatos megszorítások (időbeli korlátozások, szabványok, hardver és szoftverkörnyezeti előírások, teljesítménykövetelmények, stb.). 8

9 Szakterületi követelmények A rendszer szakterületén alkalmazott előírások, megszorítások (számítási előírások, jogszabályok, stb.). A szakterületi követelmények természetesen lehetnek funkcionális és nem funkcionális követelmények. A követelmények jellegének meghatározása abban nyújt segítséget, hogy eldönthessük: milyen funkcionalitást, milyen felületet biztosítson a program a felhasználó felé, milyen belső funkciókat kell teljesítenie ahhoz, hogy a felhasználó igényeit kielégítse, és működése közben milyen előírásokat, szabályokat kell alkalmaznia, betartania. 9

10 Példa a követelmények tervezésére A követelmények tervezésének egyik módját egy konkrét példán keresztül mutatjuk be. A példa a demonstrációs célokat szolgáló alkalmazások között klasszikusnak számító videotéka feladat lesz. A megoldás modellezéséhez az objektumorientált fejlesztésben gyakran használt UML (Unified Modeling Language, Egységes Modellező Nyelv) technikáját, elemeit használjuk fel. A követelmények feltárása a rendszer elemzésével kezdődik. Mivel feladatunk egy már működő üzleti vállalkozás folyamatainak számítógépes támogatása, a jelenlegi rendszer analízisével kezdjük a munkát. A feladat Készítsünk számítógépes alkalmazást a videotéka kölcsönzési tevékenységének támogatására. A jelenlegi rendszer A videotéka a filmkazetták dobozait az üzlet polcain tárolja. Minden dobozhoz tartozik egy biléta, amelyen a kazetta egyedi sorszáma található. Ha a kazettadoboz mellett nem található biléta, az azt jelenti, hogy a filmet már más kikölcsönözte. Az ügyfelek a kiválasztott film bilétáját odaviszik az alkalmazotthoz, aki kikeresi a film kazettáját. Kölcsönösen meggyőződnek arról, hogy a kazettán a kívánt film van-e. Feljegyzik az ügyfél kódját, a kölcsönzött kazetta sorszámát, a kölcsönzés dátumát, és a visszahozatal tervezett időpontját. A filmet az ügyfél más időpontban is visszahozhatja (de legfeljebb 3 nap múlva), ez a kölcsönzési díjat befolyásolja majd. A kiadott kazetta bilétáját visszahozásig egy Kikölcsönzött filmek címkéjű dobozban tárolják. Visszahozatalkor a nyilvántartó füzetből kikeresik a kölcsönzésnél felvett adatokat, mellé írják a visszahozás dátumát, majd meghatározzák a fizetendő kölcsönzési díjat (jelenleg minden megkezdett nap 250 Ft). Ezután a kazetta visszakerül a szekrénybe, a bilétát pedig visszaakasztják a polcra, a doboz mellé. A kölcsönzéseket nyilvántartó füzetet időnként átvizsgálják, és ha egy ügyfél túllépte a 3 napos maximális határidőt, felszólító levelet küldenek neki. A fenti leírás a videotéka általános működését írja le. Ebből kiindulva a következőket kell elvégeznünk: A folyamat pontosítása A fogalmak tisztázása A számítógéppel támogatott tevékenységek meghatározása 10

11 A folyamat pontosítása A leírás alapján megpróbáljuk a rendszer folyamatát ábrázolni. Amennyiben ez hiánytalanul sikerül, nincs további feladatunk ez ügyben (szinte sosem fordul elő!). Már ebben a szakaszban figyelünk a fogalmak tisztázására. Kezdjük magával a feladattal. Minek a támogatására készítünk szoftvert? A fenti leírás a videotéka általános működését mutatja be. Ebben szerepelnek az üzlet eszközei, az ügyfelek és alkalmazottak, a filmek kiválasztásának módszere, a nyilvántartott adatok, stb. Határozzuk meg a minket érdeklő folyamatot! (Mivel a feladat erősen kapcsolódik egy vagy több munkafolyamathoz, a szakterület elemzéséhez üzleti folyamat modellt használunk) Definíció: A számítógépes alkalmazás feladata a kölcsönzési folyamat támogatása lesz. Ez azt jelenti, hogy nem foglalkozunk az alkalmazottak munkaügyi kérdéseivel, a filmek beszerzésével, az üzlet adóbevallásával, a házipénztár működésével, blokk kiadásával, stb. A következő lépés a folyamat kezdő és végpontjának meghatározása. Definíció: A kölcsönzési folyamat akkor kezdődik, amikor az ügyfél átadja a kívánt kazetta bilétáját az alkalmazottnak. Definíció: A kölcsönzési folyamat akkor fejeződik be, amikor a kazetta visszahozása után az alkalmazott bejegyzi ennek tényét (dátum). A fenti két definíció azt is tisztázza, hogy a fizetéssel kapcsolatos ügyekkel sem foglalkozunk: nem számítjuk ki a fizetendő összeget, nem határozunk meg kedvezményeket, vagy büntetéseket. Kérés biléta átadása Kölcsönzés «cél» Bev étel Ábra 1: A kölcsönzési folyamat Az ügyfél a Kérés eseménnyel elindítja a kölcsönzés folyamatát. A folyamat célja az ügyfél szempontjából a film megszerzése, az üzlet szempontjából pedig a bevétel növelése. Számítógépes alkalmazásunk oldaláról csak a Kölcsönzés folyamattal kell majd foglalkoznunk. 11

12 A korábbi leírást tanulmányozva, ajánlatos fogalom-gyűjteményt készítenünk, hogy: az egyes fogalmak alatt ugyanazt értsük, amit a felhasználó, a hamis fogalmakat kiszűrjük, az egyes fogalmak hatókörét tisztázzuk (Például észrevehetjük, hogy a videotéka alkalmazottainak szótárában a film és a kazetta fogalmak keverednek, szinonimaként használják ezeket) Fogalmak Kölcsönzés Kazetta Film Ügyfél Biléta Kivét Felszólítás Kölcsönzési idő Az a folyamat melynek során az ügyfél megkapja a kívánt kazettát, majd a kölcsönzési idő lejártával (vagy felszólításra), visszahozza azt. Mágneses adathordozó, amely egy vagy több filmet tárol. Az a dolog, amit az ügyfél keres, meg akar nézni. Kazettát kölcsönző ember, aki beiratkozott a videotékába. A kazetta egyedi sorszámát tartalmazó, annak kiválasztását segítő eszköz. A kölcsönzést rögzítő bejegyzés. A 3 nap maximális kölcsönzési időt túllépő ügyfelek számára készített levél. Az a napokban meghatározott időtartam, ameddig a kikölcsönzött kazetta az ügyfélnél van. A fogalmak tisztázása, megértése nem csak azt a célt szolgálja, hogy a fejlesztés során a megrendelő és fejlesztő közös nyelven beszéljen, hanem lehetővé teszi, hogy a későbbi szoftver is a szakterület kifejezéseit, fogalmait használja. 12

13 A kölcsönzés során anyagi és nem anyagi folyamatok játszódnak le. A feladatleírás alapján a kölcsönzési folyamat az alábbi input erőforrásokat igényli, illetve output eredményeket produkálja: Biléta Kazetta Ügyfél adatai biléta átadása Kérés Kölcsönzés «cél» Bev étel Biléta-doboz biléta bedobása kivét megírása, illetve érvénytelenítése Kiv ét felszólítás megírása Felszólítás Ábra 2: A kölcsönzéshez tartozó inputok és outputok A fenti modell alapján fogalmazzuk meg pontosabban a feladatot! A feladat pontosítása Készítsünk számítógépes alkalmazást a videotéka kölcsönzési tevékenységének támogatására. A program segítsen a kazetták kikölcsönzésében és visszavételében. A nyilvántartás alapján, a 3 nap maximális kölcsönzési időt túllépő ügyfelek számára felszólító levelet kell készíteni. Megvizsgálva a pontosított feladatleírást, további tisztázandó kérdést találunk: a kölcsönző ügyfél. Az ügyfél adatait szerepeltetni kell a kölcsönzésnél, de szükségünk van rá a felszólító levél kapcsán is. Ezekhez szükség van az ügyfelek nyilvántartására is, tehát követelményrendszerünk ezzel kiegészül. Ugyanígy észrevehetjük, hogy a kazetta adataira is szükség van, tehát a kazettákról is nyilvántartást kell vezetnünk. Miért? Mert az eredeti folyamatban, amikor az alkalmazott kikeresi a tényleges kazettát, ellenőrzi, hogy azon valóban a keresett film van-e. Ezt megteheti úgy, hogy beteszi egy videó készülékbe, de ez a gyakorlatban nem járható út. Vezessünk inkább megbízható kazetta - film nyilvántartást. Ha már a kazetta film témánál tartunk, további pontosításként meg kell jegyeznünk, hogy egy kazettán nem csak egy film lehet (pl. rajzfilmek). 13

14 A videotéka fő és kisegítő folyamatait egységes modellben ábrázolva megkapjuk a teljes rendszert. Kazetta adatai Ügyfél adatai Kazetták nyilvántartása Ügyfelek nyilvántartása Biléta Kazetta Ügyfél Kérés biléta átadása Kölcsönzés «cél» Bev étel felszólítás megírása biléta bedobása kivét megírása, illetve érvénytelenítése Biléta-doboz Kiv ét Felszólítás Ábra 3: A kiegészítő folyamatok A kölcsönzési folyamat időben két szakaszra oszlik: 1. a kazetta kiadása, és 2. a kazetta visszavétele Mindkét tevékenységnek megvannak a maga bemenő és kimenő adatai, illetve feltételei. A feladatot célszerű úgy ábrázolni, hogy lássuk a kölcsönzési folyamat e két összetevőjét is. 14

15 Kérés biléta átadása Kiadás kiválasztás ki vál asztás kivét megírása biléta bedobása Kazetta Ügyfél Biléta-doboz Kiv ét biléta visszaakasztása kivét kikeresése Kiv ét érvénytelenítése Kölcsönzés Visszahozatal Visszavétel Pénz Ábra 4: A kölcsönzési folyamat felbontása Foglaljuk most már össze a teljes, pontos feladatleírást. A végleges feladatleírás Készítsünk számítógépes alkalmazást a videotéka kölcsönzési tevékenységének támogatására. A program tartsa nyilván a kölcsönzésekkel kapcsolatos adatokat, melyek. a kölcsönző ügyfél kódja a kikölcsönzött kazetta sorszáma a kölcsönzés kelte a tervezett visszahozás dátuma a tényleges visszahozás dátuma A nyilvántartás alapján, a 3 nap maximális kölcsönzési időt túllépett ügyfelek számára felszólító levelet kell készíteni. Az ügyfelekről nyilvántartást kell vezetni, melynek tartalma: ügyfél kódja 15

16 neve címe (irányítószám, város, utca, házszám) A kazettákat és a filmeket is nyilván kell tartani: kazetta sorszáma film címe, rendező 1 film címe, rendező 2.. film cím, rendező n A rendezőt azért rögzítjük, hogy az azonos című filmek egyértelműen megkülönböztethetők legyenek. Az alkalmazás személyi számítógépen, egy munkahelyes, egy felhasználós üzemmódban fog működni. Operációs rendszer: Windows. 16

17 A követelmények ábrázolása használati eset modellben A használati eset modell azt írja le, hogy mire kívánja a felhasználó az alkalmazást használni. A modellben megjelenítjük a felhasználó és a program interakciós szintjét, illetve ha szükséges, tovább bontjuk a fő követelményeket. Itt már megjelenhetnek további, rendszerszintű követelmények is. A kazettakölcsönzési feladat használati eset modellje Az üzleti folyamat elemzéséből kiderült, hogy milyen tevékenységeket kell végezni a kölcsönzéssel kapcsolatban, illetve ezekhez milyen anyagi és információs folyamatok kapcsolódnak. Az alkalmazásnak az információs feladatokat kell támogatnia, tehát a felhasználó az ezekhez tartozó funkciókat várja el a programtól. Az alábbi használati eset modell - kiindulva a korábbi elemzésekből azokra a szolgáltatásokra koncentrál, amiket a programnak a felhasználó felé nyújtania kell. Támogató tevékenységek Fő tevékenység Filmek nyilvántartása Kazetta visszavétele Kazetta kiadása Alkalmazott «include» Kazetták nyilvántartása Karbantartási funkciók + Felvitel + Keresés + Módosítás + Törlés Felszólító levelek készítése Ügyfelek nyilvántartása Ábra 5: Használati eset diagram A fenti diagram a fő felhasználói követelményeket mutatja. Bár a kazetták, és ügyfelek nyilvántartása eredetileg nem felhasználói szinten fogalmazódik meg, de alapvető szükségességük miatt, a rendszer követelményeinek egyeztetésénél erre a szintre kerül. A későbbi implementálásnál kötelezően figyelembe kell venni: a felhasználó ezeket a funkciókat várja el a rendszertől, ezeket fogja keresni programunkban. A program elfogadásánál, átvételénél az egyik döntő szempont az, hogy az mennyire igazodik a támogatott szakterület szakmai és használati igényeihez. A felhasználói felület kialakításánál ezt maximálisan figyelembe kell majd venni. 17

18 Következtetések Mit és hogyan tudtunk meg a fenti elemzésekből? Mire használtuk a diagramokat? A követelmények feltárásánál a jól bevált emberi kommunikációs eszközök (beszéd, hang- és/vagy filmfelvételek) segítségével összegyűjtöttük 1, amit a rendszerről tudnunk kell. Nagyon fontos, hogy a követelményelemzést az illető szakterület jelen esetben a videotéka tapasztalati (helyszíni) megismerésével kezdjük. A szakterület felméréséhez jó eszköz az üzleti folyamat modell, mivel közel áll az emberi gondolkodáshoz. Segítségével feltárhatjuk, megismerhetjük a szakterület munkafolyamatait, és a munkafolyamatokhoz kapcsolódó anyagi és információs folyamatokat. Ez az elemzés azonban csak akkor használható igazán jól, ha olyan rendszert vizsgálunk, amelyben a munkafolyamatok meghatározó szerepet játszanak. Ha feladatunk például egy szövegszerkesztő program készítése, annál ezt a módszert nehezen alkalmazhatnánk. Az egész elemzés célja az, hogy a működő szakterület megismerésétől indulva tisztázzuk, hogy a tervezett alkalmazást kik, mikor, mire és hogyan kívánják használni. Az eredményeket olyan formában kell rögzítünk, hogy bárki számára bármilyen szinten megismerhető legyen a rendszer. E cél elérését szolgálhatja a használati eset modell, amely a majdani felhasználó szemszögéből próbálja a tervezett rendszert ábrázolni: használatát bemutatni. A használati eset modell a követelmények egy újabb szemszögből való megközelítése: vegyük észre, hogy a fenti példában is ugyanazt a rendszert jártuk körbe, és modelleztük különböző eszközökkel. A következő fejezetben összefoglaljuk az üzleti folyamat modellek készítésével kapcsolatos tudnivalókat, majd kitérünk egy újabb követelmény-ábrázolási lehetőségre, a hálós követelménymodellre. A használati eset modellekkel részletesebben nem foglalkozunk, az ezekre vonatkozó további ismeretek megtalálhatók tananyagunk UML diagramokkal foglalkozó részében. 1 Ne feledjük, hogy a követelmények gyűjtése, aktualizálása, felülvizsgálata a fejlesztés teljes folyamatában jelen van lásd: követelmények menedzselése. 18

19 Üzleti folyamatok modellezése (Business Process Model BPM) Az üzleti folyamatok modellezése az egyik alapvető szakasz a szoftverfejlesztésben. A folyamatok elemzése során gyűjtjük össze azokat az információkat, melyeknek alapján megismerjük, megértjük az illető szakterületet. A BPM modell mutatja meg, hogy a tervezett alkalmazásunkat hol és milyen módon illesztjük a támogatandó tevékenységekhez. A folyamatmodellezés mind a jelenlegi, mind a tervezett rendszer megismeréséhez felhasználható. Az elemzés és modellezés kezdeti szakaszában alkalmazott BPM segítségével felmérjük, összegyűjtjük az érintett tevékenységekkel kapcsolatos eseményeket, input erőforrásokat és a keletkező termékeket. A továbbiakban, a későbbi modellek elemeinek (pl. használati esetek) visszacsatolásával ellenőrizhetjük, hogy az üzleti folyamatok mindegyikét figyelembe vettük-e a tervezéskor. Bár a BPM rendszerint tágabb horizonttal rendelkezik, mint amit a szoftver fejlesztésekor figyelembe kell vennünk, talán épp ezért, kiválóan alkalmas arra, hogy meghúzzuk tervezett rendszerünk határait: mit valósítunk meg fejlesztésünk keretei között, és mit nem. A modell elemei Az üzleti folyamat modellekben általában az alábbi diagram-elemeket használjuk: a folyamat célja speciális input elemek és output elemek felhasznált erőforrások tevékenységek események Az üzleti folyamat jellemzője, hogy szervezeti keretek között zajlik, mindig valamilyen kézzelfogható célja van. A folyamat tevékenységekből áll, melyek mindegyike egy meghatározott fogyasztó, vagy piac számára állít elő végterméket. A folyamatnak mindig van egy jól meghatározható kezdete, és egy egyértelmű végpontja. Folyamat Ábra 6: A folyamat szimbóluma 19

20 A szimbólum magában foglalja a folyamatban zajló tevékenységek lefolyását (balról jobbra mutató irány). A belső folyamatok jelzésére az UML aktivitás elemeit használhatjuk. Folyamat Tevékenység 1 Tevékenység 2 Ábra 7: Belső folyamatok jelzése Inputok, erőforrások és információk Az üzleti folyamatok céljaik elérése érdekében információkat használnak fel. Az információk, ellentétben az erőforrásokkal, nem használódnak el a folyamat lezajlása során inkább a transzformációs folyamat részeinek tekinthetjük őket. Az információk származhatnak külső forrásokból, vevőktől, belső szervezeti egységektől, de más folyamatok terméke is lehet. Az erőforrások szintén a folyamat bemenő elemei, de a folyamat tevékenységei során elhasználódnak, beépülnek a termékekbe. Erőforrás Információ «input» «supply» Folyamat Ábra 8: Információk és erőforrások jelzése A <<supply>> jelzés azt mutatja, hogy az információ, vagy egyéb bejövő objektum nem használódik el a folyamat során. Például a nyomtatványok előállítását segítő sablonok akárhányszor felhasználhatók a szövegszerkesztőben. Az <<input>> jelzésű kapcsolat viszont azt jelzi, hogy az erőforrás elhasználódik a tevékenységek végzése során. 20

21 Események Az esemény egy történés, amely elindítja (esetleg megállítja) a folyamatot. Ábra 9: Folyamat indító esemény Output Egy üzleti folyamat mindig létrehoz valamilyen outputot, terméket. A létrehozott termék lehet közbenső (más folyamat inputja), vagy végtermék. Ez a termék lehet egy valóságosan létező objektum (pl. egy ipari gyártmány, vagy jelentés), illetve a bemenő erőforrások egy speciális kombinációja (pl. egy rendezett lista). A folyamat terméke lehet más folyamat elindító oka, eseménye. Erőforrás Információ «input» «supply» Esemény Folyamat «output» «output» Output Output Ábra 10: Outputok 21

22 Célok Egy üzleti folyamat mindig rendelkezik egy vagy több, jól meghatározott céllal. Ezek a célok azok, amiért a rendszer, a szervezet egyáltalán működik. Erőforrás Információ «input» «supply» Esemény Folyamat «goal» Cél «output» «output» Output Output Ábra 11: Cél A folyamatok modellezésének jelentősége Az üzleti folyamatok modellezése eredetileg nem része az UML szabványnak. Az UMLben, és a kapcsolódó fejlesztési módszertanban (UP, Unified Process, Egységesített Eljárás) a követelmények feltárása, elemzése és modellezése bizonyos szempontból mostohán kezelt terület volt. Az eredeti elképzelés szerint a szoftverekkel kapcsolatos követelményeket a használati esetek segítségével térképezzük fel. A használati esetek felhasználó-központúsága pedig biztosítja, hogy a tervezés során ne rugaszkodjunk el a valóságtól, a valós igényektől. Nagyobb, összetettebb rendszerek fejlesztése esetén ez a módszer azonban nem biztosítja a teljes rendszer megértését, illetve ábrázolását, mivel a követelményeknek csak egy részhalmazára koncentrál. Ez megfelelő lehet egy egyszerű alkalmazás tervezése során, de a teljes rendszer megismerésére, a sokféle követelmény (tevékenységek, adatok, korlátozások, környezeti feltételek, hivatalos előírások, stb.) által alkotott teljes igényrendszer gazdaságos ábrázolására nem alkalmas. Az adott szakterület szoftverrel való támogatásának alapfeltétele a szakterület alapos megismerése. Olyan esetekben, amikor az érintett területre a munkafolyamatok, tevékenységek, és az információáramlás jellemző, a folyamatmodellezés hasznos eszköz lehet. 22