Információrendszerfejlesztés. Információk, elérhetőségek

Átírás

1 Információrendszerfejlesztés II március 6. 1 Információk, elérhetőségek Kovács Katalin A 606-os szoba Tel.: kovacsk@sze.hu Konzultációs időpont: Hétfő: óra március 6. 2

2 IR-fejlesztés II. Irodalom: Ian Sommerville: Software Engineering 7 Roger S Pressman: Software Engineering: A Practitioner's Approach Sziray J., Kovács K.: Az UML nyelv alapjai március 6. 3 Software Engineering szoftverfejlesztési folyamat Software Engineering értelmezése Az a folyamat, mely eredményekénk létrehozunk egy adott feladatot megvalósító szoftver rendszert. Tevékenységek, technológia, módszerek, eszközök Számítógép alapú rendszert hozunk létre március 6. 4

3 Engineering Mérnöki munka rendszerek létrehozására (~ fejlesztés) Építő mérnök Gépész mérnök Villamos mérnök Szoftver mérnök Modellezés általános eszköz leendő rendszer leírása, specifikációja, terve március 6. 5 System Engineering és Software Engineering Rendszerfejlesztési folyamat ( rendszer ) System Engineering Általános értelemben vett rendszer fejlesztés. Szoftverfejlesztési folyamat (szoftver ) Software Engineering Szoftver alkalmazásokat, eszközöket ad a SE által definiált feladatok megoldására. A szoftver rendszer (alkalmazás) létrehozására koncentrál március 6. 6

4 Rendszerfejlesztés Rendszerfejlesztés alapkérdései Általános értelemben vett rendszer fejlesztés Rendszerfejlesztés lehet: Business Process Engineering ha vállalat (működésének) (át)szervezésével foglalkozunk Product Engineering ha egy termék előállítása a cél pl.: mobil telefon, repülőgép vezérlő rsz. Szoftverfejlesztési folyamat március 6. 7 Szoftverfejlesztési folyamat Szoftverfejlesztés értelmezése Az a folyamat, amelynek eredményekénk létrehozunk egy adott feladatot megvalósító szoftverrendszert, számítógép alapú rendszert hozunk létre. Szoftverfejlesztés lépései Fázisok Szoftverfejlesztési modellek, módszertanok: struktúrált (vízesés modell, Boehm-féle spirálmodell, V modell stb.) objektumorientált (OMT, OOA/OOD, Bocch2, RUP) március 6. 8

5 Vízesés modell március 6. 9 A fejlesztés életciklusa System engineering Rendszerfejlesztés Business process eng. Üzleti modellezés üzleti folyamatok tervezése, szervezése az üzleti környezet modellezése Product eng. Termék modellezés termékek tervezés termék modellezése, annak használata Requirements Követelménykezelés Analysis Elemzés Design Tervezés Implementation Implementáció Testing Tesztelés, Telepítés Karbantartás, Rendszerkövetés, Továbbfejl. Software eng. Rendszerfejlesztés System Eng március 6. 10

6 Módszerek, modellek Rendszerek tervezése, fejlesztése Rendszerfejlesztési módszerek Szoftverrendszerek fejlesztése Szoftverfejlesztési módszerek (módszertanok) március BMW elv Rendszerfejlesztés területén segít a rendszerek tervezésében. BMW: Beschreibungsmittel Methode Werkzeug március 6. 12

7 BMW elv Központi gondolat: Bármelyik módszertan három komponens: Leíróeszköz Módszer Támogatóeszköz megfelelő kombinációja. Az elv alkalmazásával a rendszerek tervezéséhez megfelelően lehet kiválasztani: A módszert, Leíró és Támogatóeszközt március BMW elv Módszer: Szabályrendszerre épülő, tárgya és célja szerint tervszerű, ismeretek és gyakorlati eredmények megszerzésére irányuló eljárás. Leíróeszköz: A viselkedés leírására, formalizálására szolgáló eszköz. Támogatóeszköz: Valamely leíróeszköz számítógépes alkalmazását segítő szoftver március 6. 14

8 Módszertan Modellező nyelv Eljárások Módszertan március Eljárások Tanácsok: milyen lépések szükségesek a rendszer elkészítése során és azokat milyen sorrendben kell végrehajtani. Az egyes lépéseket milyen szerepkört betöltő embereknek kell elvégezni. Milyen termékek születnek az egyes lépések során és hol kerülnek felhasználásra március 6. 16

9 Szerepkörök és tevékenységek A szerepkör (worker) egyfajta viselkedést ír le. A szerepkört betöltő személy vagy személyek felelősek meghatározott termékek (artifact) előállításáért. Minden munkatárs meghatározott tevékenység-sort végez a termékek előállítása érdekében. Minden valóságos személy többféle munkatársi szerepkört is betölthet a projekt folyamán, többféle felelőssége lehet március Termékek (Artifact) A projekt során előállított, használt dolgok. Például: Dokumentum Modell (pl.: használati eset modell) Modell-elem (pl.: használati eset) Riportok: modellekből, modell-elemekből előállított dokumentumok. A termékek tevékenységek során állnak elő, és útmutatók (guideline), sablonok (template) segítik a készítésüket: Pl.: hogyan találjuk meg és dokumentáljuk a használati eseteket? Nem termékhez kapcsolódó útmutatók: például hogyan szervezzünk workshopot március 6. 18

10 Modellező nyelv Jelölésrendszer (általában grafikus), amellyel leírjuk a rendszert, rendszertervet a fejlesztés során. A kommunikáció alapja: megrendelő és fejlesztő csoport között, fejlesztő csoport tagjai között. Fontos, hogy a modellező nyelv alkalmas legyen mind a valóság, mind rendszer belső szerkezetének ábrázolására: üzleti modelltől, telepítési modellig március IR-fejlesztés II. Rendszerfejlesztési folyamat Szoftverfejlesztési folyamat Szoftverfejlesztés strukturált szemléletben március 6. 20

11 Fázisok március SE fázisok Üzleti modellezés Követelmény-elemzés Elemzés-tervezés Implementáció Tesztelés Telepítés Konfiguráció és változás-kezelés Projektvezetés Környezet kialakítása Mérnöki feladatok Támogató munkafolyamatok március 6. 22

12 SE fázisok mérnöki feladatok A fejlesztési munka konkrét feladatai: Üzleti modellezés (Business Modeling) Cél megérteni annak a szervezetnek a felépítését, folyamatait, amely támogatására az alkalmazást fejlesztjük. Követelmény-elemzés (Requirements) Cél meghatározni azokat a feladatokat, amelyeket a rendszernek meg kell oldani (scope) és a megrendelőkkel együttműködve egy egységes képet kell kialakítani a fejlesztendő rendszerről. Elemzés-tervezés (Analysis & design) Cél a követelményelemzés során meghatározott elvárásoknak megfelelő, robosztus rendszer tervezése március SE fázisok mérnöki feladatok Implementáció (Implementation) Cél a terv alapján a rendszert alkotó komponensek implementálása, egységtesztjeinek elvégzése és integrálása. Tesztelés (Test) Cél annak ellenőrzése, hogy az implementált rendszer megfelel-e az elvárásoknak, és hogy valamennyi követelmény implementálva lett-e. Telepítés (Deployment) Cél a kész alkalmazást elérhetővé tenni a felhasználó számára március 6. 24

13 Támogató feladatok a fejlesztés során Azok a feladatok, amelyek a fejlesztés során folyamatosan segítik a fejlesztők munkáját: Konfiguráció és változás-kezelés Cél a fejlesztés során előálló termékek verzióinak kezelése. Projektvezetés Cél irányelvek megadása és a projekt ellenőrzésével és irányításával kapcsolatos feladatok elvégzése. Környezet kialakítása Cél a szoftverfejlesztési környezet (módszertan, eszközök) kialakításával kapcsolatos feladatok ellátása március Fázisok Minden fázis végén jól-definiált mérföldkövek vannak: kritikus döntéseket kell hozni: Értékelni az eddigi eredményeket, Dönteni a folytatásról március 6. 26

14 Ciklusok Egy fejlesztési ciklusnak nevezzük azt az időtartamot, amíg egyszer végigmegyünk mindegyik fázison és előáll a szoftver egy generációja, verziója. A szoftvert az új igényeknek megfelelően folyamatosan fejleszteni, javítani kell. Ilyenkor újabb és újabb fejlesztési ciklusok következnek, amelyek szintén végigmennek a fejlesztési fázisokon és a szoftver újabb és újabb generációját állítják elő. Ezeket a fejlesztési ciklusokat evolúciós ciklusoknak nevezzük. Az evolúciós ciklusoknál általában eltérően alakul a fázisok aránya március Fejlesztési fázisok március 6. 28

15 Üzleti modellezés Megérteni annak a szervezetnek a felépítését, viselkedését, amely számára a rendszert ki akarjuk fejleszteni Feltárni a szervezet aktuális problémáit és meghatározni a javítás lehetőségeit Biztosítani, hogy az ügyfelek, végfelhasználók és fejlesztők egységes képet kapjanak az adott szervezetről A szervezetet támogató rendszerrel szemben felmerülő követelmények felderítése március Üzleti modellezés Azt a környezetet írja le, amelyikben a rendszer működik, vagy amelyikben a rendszer működni fog. A rendszernek az üzleti környezetben, a szakterületi környezeten belüli helyét határozza meg. Más néven szakterületi (domén) modellezés. Értelmezhető mind a jelenlegi, mind a tervezett rendszer üzleti környezetére március 6. 30

16 Üzleti modellezés március Üzleti modellezés Az üzleti folyamatok állapotának felderítése (Assess Business Status) A fejlesztett rendszer által támogatott szervezet (cél szervezet) állapotának felderítése március 6. 32

17 Üzleti modellezés Az aktuális üzleti folyamatok leírása (Describe Current Business) Feltárni a cél szervezet folyamatait és szerkezetét. Nem cél a szervezet részletes leírása. Addig a szintig kell az elemzéseket elvégezni, amíg képesek leszünk kategorizálni a szervezet folyamatait és kiválasztani azokat a részeit, amelyekre a projekt hátralevő részét alapozni fogjuk. Üzleti szereplők, használati esetek, entitások és workerek azonosítása március Üzleti modellezés Az üzleti folyamatok azonosítása (Identify Business Processes) március 6. 34

18 Üzleti modellezés - tevékenységek március Üzleti modellezés - termékek március 6. 36

19 od A diplomamunka kezelésének folyamata A ké t esemén y kö zött meg határozatlan hosszúságú idõ telik el Diplomaterv beé rkezése a Tan szé kre Dip lo mamunka beérkezé se a Tanszé kre Diplomamunka - diplomaterv: - ko nzu le nsi la p: - kido lg ozo tt téma : Diplomaterv - szerzõ ada ta i: - kon zulen s ada ta i: - té ma b emutatása: - elfog adá s ke lte: Diplomaterv elbírálása Részleteszõ diagram Diploma te rv felvé te le enge délye zés vag y elu ta sítás [elfogad ás esetén ] Diploma te rv e k nyilv á nta rtás a Diplomamunka beérkeztetése, elbírálása Részletezõ diagram Bírálat - b íráló vélemé nye : - o sztályzat: bíráló és bírálat b ejegyzése Diploma -terv dokumentum B írálat dokumentum Elbírá lt terv visszakü ld ése Elbírált diplomamu nka visszaküldése D.O-ra A szakterület folyamatai (üzleti folyamat diagram) (Diplomáztatás esettanulmány) A két esemény között meghatározatlan hosszúságú idõ telik el Diplomaterv ek nyilv ántartása Diplomamunka - diplomaterv: - konzulensi lap: - kidolgozott téma: bíráló és bírálat bejegyzése Diplomamunka beérkezése a Tanszékre Diplomamunka beérkeztetése, elbírálása Részletezõ diagram visszaküldése D.O-ra Bírálat - bíráló véleménye: - osztályzat: Bírálat dokumentum március Szakterületi modell (Diplomáztatás esettanulmány) cd Szakterületi osztálydiagram Fejlesztõeszköz - megnevezés: DiplomaTerv - szerzõ neve: - fejlesztõeszköz: - konzulens: - tanszék: - cím: - témavázlat: +közremûködik Konzulens - név: +használja - név: Szerzõ +elkészíti +elkészíti +közremûködik Diplomamunka - diplomaterv: - konzulensi vélemyény: - kidolgozás: +jóváhagyja +kijelöli +bírálatra kiadja +kijelöli Tanszéki felelõs +képviseli Bírálat - bíráló neve: - osztályzat: - szöveg: +elbírálja +elkészíti Bíráló - név: Tanszék - megnevezés: március 6. 38

20 Követelmény (elemzés) március Követelményanalízis/kezelés a szoftverfejlesztési folyamat első lépcsőfoka már konkrét specifikáció, amely alapját képezi valamennyi szoftverfejlesztési tevékenységeknek, a teljes szoftverfejlesztési folyamatnak végrehajtásához a következő tevékenységek javasoltak: problémafeltárás problémaértékelés és megoldás keresés/alternatív megoldások felállítása modellezés specifikáció áttekintés, felülvizsgálat, ismertetés március 6. 40

21 Követelményanalízis/kezelés a probléma információs, funkcionális és a viselkedési doménére!!! koncentrál követelmények összegyűjtése követelmények elemzése konzisztencia, prioritások, köv. típusok követelmények specifikálása követelmények validálása produktuma: szoftver követelményspecifikáció dokumentum március Követelményelemzés A megrendelővel (felhasználóval) egyetértésre jutni, hogy pontosan mit kell a szoftverrendszernek tudnia. A fejlesztőknek pontos képet adni a rendszerről. Meghúzni a rendszer határait. Biztosítani az iterációk tervezéséhez szükséges technikai információkat. A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész meghatározása március 6. 42

22 Követelményelemzés A tervezett szoftverrendszernek kívülről, a felhasználó szempontjából történő leírását adja meg március Követelményelemzés március 6. 44

23 Követelmény 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 március Követelménymenedzsment 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 március 6. 46

24 Követelmények változásainak nyomon követése A fejlesztés során a megrendelőnek, a felhasználónak újabb elképzelései, igényei merülhetnek fel. A korábban specifikált követelmények tehát a fejlesztés folyamán változhatnak, módosulhatnak. A rendszert fel kell készíteni a követelmények változásának követésére. A változáskövetés során első lépésben elemezni kell a fejlesztés folyamán jelentkező új igényeket, majd meg kell vizsgálni az új igények milyen hatással lesznek a már felállított követelményrendszerre. A vizsgálat eredményének kiértékelése után lehet csak dönteni a változások megvalósíthatóságáról március Követelmények 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 március 6. 48

25 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 március Követelmények feltárását, összegyűjtését segítő technikák tipikus módszerek: megbeszélés, interjú FAST (Facilitated Application Specification Techniques) QFD (Quality Function Deployment) Use Case technika, amelynek segítségével különböző scenáriókat készíthetünk az előzőekben felsorolt technikákkal feltárt/meghatározott követelmények alapján, a scenáriókkal leírható ahogy a rendszer viselkedni fog adott szituációkban március 6. 50

26 Követelmények feltárását, összegyűjtését segítő technikák tipikus módszerek: megbeszélés, interjú Gaus&Weinberg által javasolt 3 kérdéscsoport módszer: szövegkörnyezet független kérdések Ki fogja majd használni az alkalmazást? Ki lesz az alkalmazás felhasználója? Milyen gazdasági előnyökkel jár egy sikeres alkalmazás? Kinek az érdekeit szolgálja a fejlesztés? a fejlesztés specifikus kérdések Le tudná írni azt a környezetet, amelyben a megoldást alkalmazzák? Létezik bármilyen dolog vagy megszorítás, amely hatással lehet az alkalmazás megvalósítására? meta-kérdések: amelyek a megbeszélés eredményességére fókuszálnak - A témához kapcsolódó kérdésekkel találkozott? Nem volt sok a feltett kérdések száma? március Követelménykezelés és az analízis a fejlesztésben Rendszerfejlesztés Szoftver követelmények, elemzés Szoftver tervezés március 6. 52

27 A követelmények csoportosítása Felhasználói követelmények Funkcionális és nem funkcionális követelmények Szakterületi követelmények március Felhasználói követelmények A felhasználónak a szoftverrendszerrel szembeni igényei, elvárásai felhasználói célok un. felhasználói követelmények formájában fogalmazódnak meg március 6. 54

28 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 március Felhasználói követelmények Meg tudják adni, le tudják írni a szervezetnek azt a területét/területeit (alrendszer), azt a szervezeti környezetet, amelyikben majd a fejlesztendő szoftveralkalmazás működni fog. Megadják a rendszertől elvárt szolgáltatásokat, és azokat a feltételeket (megszorításokat), amelyeket a rendszer fejlesztése és majdani működése során be kell tartani. Vannak elképzeléseik az alkalmazás használatára, az alkalmazás bemenetére, kimenetekre (pl. listák, bizonylatok formája) március 6. 56

29 Felhasználói követelmények A felhasználói követelmények: un. magas szintű célok kategorizálni kell, közöttük prioritási sorrendet kialakítani, majd a felállított fontossági sorrend alapján az igényeknek megfelelően, szükséges mélységben részletesen ki kell fejteni. A követelmények kategorizálásnak és minősítésének számos hatékony módszerei: A szakirodalom a Software Engineering Institute (SEI) és az ISO által kidolgozott módszereket javasolja alkalmazni. Az egységesített módszertan a követelmények csoportosítását a FURPS+ modell alapján végzi március Felhasználói követelmények A felhasználói követelmények alapot képeznek: a szoftverrendszertől elvárt konkrét szolgáltatások (szoftverfunkciók, amiket a szoftver csinál) meghatározására március 6. 58

30 Funkcionális és nem funkcionális követelmények Az alkalmazástól elvárt szolgáltatások, szoftverfunkciók a követelménymodellben: funkcionális (a rendszer működésére vonatkoznak) és nem funkcionális követelmények (a működést befolyásoló egyéb követelmények) formájában fogalmazódnak meg március Funkcionális követelmények 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. Már a szoftverrendszer működésére, a tényleges funkcionalitásra vonatkozó leírások március 6. 60

31 Funkcionális követelmények Funkcionális követelmények: azokat a követelményeket értjük, amelyek a szoftverrendszert kívülről nézve, a felhasználó szemszögéből írják le március Funkcionális követelmények A funkcionális követelmények: leírják, hogy a rendszert ért hatásokra, eseményekre a szoftveralkalmazásnak hogyan kell reagálni, a megfogalmazott feltételek, megadott megszorítások függvényében a rendszernek milyen alternatív végrehajtást kell biztosítani, a bekövetkezett események hatására milyen más funkciókat kell aktivizálni március 6. 62

32 Szervezet, vállalati belső környezet Fejlesztendő szoftverrendszer Felhasználók, akik fejlesztendő alkalmazást működtetik SW alkalmazások Külső rendszerek Külső szereplők, akik fejlesztendő alkalmazás szolgáltatásait igénybe veszik március Nem funkcionális követelmények A rendszer funkcióival és szolgáltatásaival kapcsolatos megszorítások. Például időbeli korlátozások, szabványok, hardver és szoftverkörnyezeti előírások, teljesítménykövetelmények, stb március 6. 64

33 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 március Tesztelés követelmények alapján március 6. 66

34 Szoftverrendszerek tesztelése A szoftver fejlesztés célja: a specifikációban leírt követelményeket kielégítő szoftver készítése. Fejlesztés során különböző ellenőrző, elemző lépéseket kell végrehajtanunk a cél elérése érdekében. A vizsgálat során két egymástól eltérő célunk lehet: Vizsgálhatjuk azt, hogy a megfelelő terméket készítjük-e. Ebben az esetben validációt végzünk. Vizsgálhatjuk azt, hogy a terméket jól készítjük-e. Ebben az esetben verifikációt végzünk március V & V: verifikáció és validáció A verifikáció: azt vizsgáljuk, hogy a fejlesztés során egymás után végrehajtott fejlesztési lépések során előállított szoftver (ill. annak terve) megfelel-e a specifikációban rögzített elvárásoknak, tulajdonságoknak. A verifikáció során a vizsgálat alapja mindig valamilyen fejlesztés során előállított információ (termék) március 6. 68

35 V & V: verifikáció és validáció A validáció: általánosabb folyamat, Azt vizsgáljuk, hogy az elkészített termék megfelel-e a megrendelő elvárásainak. A validáció tehát magában foglalja a specifikáció ellenőrzését is március Szoftvertesztelés alapsémája A tesztelés lényege összehasonlítás: A tesztelt szoftver (software under test, SUT) kimeneteit, működését, viselkedését összehasonlítjuk valamilyen referenciával. Az összehasonlítás alapjául szolgáló referencia leírása sok forrásból származhat, attól függően, hogy a szoftverfejlesztés mely stádiumában hajtjuk végre a tesztelést. Származhat az információ a specifikációból nyert adatokból, prototípus szoftver leírásából/megfigyeléséből, vagy a fejlesztés során előállított, rendszer viselkedését leíró modellből március 6. 70

36 Szoftvertesztelés alapsémája Referencia (követelmény specifikáció, prototípus, rendszermodell stb.) referencia kimenet bemeneti sorozat viselkedés, állapot megfigyelése Értékelés (viselkedés, kimenetek összehasonlítása) eredmény Tesztelt szoftver software under test, SUT SUT kimenet március Funkcionális követelmények leírása A felhasználói célokat a követelményelemzés munkafolyamat során a funkcionális követelményekben definiált funkciókkal teljesítjük. A funkcionális követelményeket az UMLben use case-ekkel írjuk le, ábrázoljuk. Minden felhasználói célhoz tartozni kell a funkcionális követelmények egy bizonyos halmazának, de legalább egy use casenek március 6. 72

37 Követelmények megvalósításának ábrázolása EA-ban ud KövetelményekMegv alósítása EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version ÁrajánlatbólRendelés EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version ÁrajánlatKészítés ÁrajánlatKészítés ÁrajánlatMódosítás EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version ÁrajánlatKészít_Weben EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version ÁrajánlatLekérdez_Weben ÁrajánlatMódosít_Weben EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version március Követelményelemzés A megrendelővel (felhasználóval) egyetértésre jutni, hogy pontosan mit kell a rendszernek tudnia. A fejlesztőknek pontos képet adni a rendszerről. Meghúzni a rendszer határait. Biztosítani az iterációk tervezéséhez szükséges technikai információkat. A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész meghatározása március 6. 74

38 Követelményelemzés Általános célok, feladatok: A megrendelővel (felhasználóval) egyetértésre jutni, hogy pontosan mit kell a rendszernek tudnia. A fejlesztőknek pontos képet adni a rendszerről. Meghúzni a rendszer határait. Biztosítani az iterációk tervezéséhez szükséges technikai információt. A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész meghatározása március Új rendszer fejlesztése A probléma elemzése: Nincs egy meglévő rendszer, amely meghatározná a megoldandó feladatot és az alapvető követelményeket. A probléma elemzését elsősorban az előkészítés fázisban, és a kidolgozás fázis korai szakaszában hajtjuk végre. Kapcsolódó tevékenységek: Fogalomtár készítése Use case modell: szereplők és use case-ek megkeresése Követelmény kezelési terv kidolgozása Projekt Vízió kidolgozása március 6. 76

39 Fogalomtár készítése Közös fogalmak megkeresése. a probléma domain területének közös fogalmai az itt definiált fogalmakat konzisztens módon használhatjuk a rendszer bármilyen szöveges dokumentációjában elkerülhetőek a projekt tagjai közötti félreértések A fogalomtár kialakítása során a következő típusú fogalmakat kell figyelembe venni: Üzleti fogalmak, amelyekkel az adott szervezet a mindennapi munkája során találkozik Valós világbeli fogalmak, amelyeket a rendszernek figyelembe kell venni, például: számla, utas, vevő Események, amelyeket a rendszernek kezelnie kell, például megbeszélések, hiba előfordulások március Új rendszer fejlesztése - Lépések Felvázolni a rendszer funkcionális működését Meghatározni, melyek azok a funkciók, amelyeket a rendszernek meg kell valósítani, és melyek azok, amelyek a rendszer határain kívül vannak Meghatározni, hogy KI vagy MI fog kapcsolatba kerülni a rendszerrel A készülő modellt csomagokra bontani a megtalált aktorok és használati esetek figyelembe vételével Elkészíteni a használati eset modellt A használati eset modell áttekintő leírásának elkészítése március 6. 78

40 Elvégzendő feladatok Felhasználói követelményeket teljesítő: funkcionális és nem funkcionális követelmények meghatározása. Funkcionális követelmények leírása UML segítségével: Use case-ek március Elvégzendő feladatok Use case-ek struktúrálása. Use case-ek és az aktorok kapcsolatának meghatározása: use case diagram. Use case modell(ek) március 6. 80

41 Use case modell A követelményspecifikáció végére előálló use case modell: a rendszer tervezett funkcionális működését, a rendszer viselkedését írja le a rendszert kívülről, a felhasználó szemszögéből nézve március Use case modell elemei use case-ek (szoftverfunkciók), amelyeket a fejlesztendő szoftverrendszernek meg kell valósítani, aktorok, akik/amik a rendszer határán kívül vannak, a rendszerrel kapcsolatba kerülnek, hogy a rendszerrel feladatokat (szoftverfunkciók) hajtsanak végre, a kapcsolat az aktorok és use case-ek közötti viszonyrendszert definiálja március 6. 82

42 Az aktorok és a use case-ek megkeresése gyakorlat: gyakran elég nehéz a use case-ek listájának felállítása a gyakorlat szerint elsőként könnyebb az aktorok listájának elkészítése, majd ezután a use case-k megkeresése vegyük sorra a szereplőket, és nézzük meg a felhasználó szemszögéből mit várnak el a rendszertől! Mi az elsődleges funkció, amit a szereplő elvár a rendszertől? A szereplő fog adatot bevinni a rendszerbe, módosítani vagy törölni? stb március Aktorok és use case-ek megkeresése - Aktorok azonosítása Cél: Meghatározni, hogy KI vagy MI fog kapcsolatba kerülni a rendszerrel március 6. 84

43 Aktorok Az aktor: egy szerep, amit az érdekelt játszik/végrehajt a rendszerrel folytatott interakcióban. A rendszer szereplője, valaki vagy valami a rendszer határán kívül, aki/ami kapcsolatba kerül a rendszerrel. Az aktorok nem kizárólag személyek, lehetnek elemek, dolgok, gépek-berendezések, üzleti egységek, vagy a rendszerrel kapcsolatot létesítő valamely külső rendszerek, rendszerkomponensek március Aktorok - szerepkör A szereplő elnevezés helyett gyakran a szerepkör kifejezés. Szerepkör: A rendszer felhasználói meghatározott feladatkört (szerepet, jogosultságot) betöltve léphetnek csak kapcsolatba a rendszerrel, csak konkrét szerepkör birtokában használhatják a szoftverrendszert és azok szolgáltatásait március 6. 86

44 Aktorok sajátosságai Egy felhasználó többfajta szerepet is játszhat/végezhet, többféle szerepkörben lehet; egy szerepkört több felhasználó is betölthet; Ha van a rendszerben két azonos aktor, akkor az csak egy aktor március Aktorok sajátosságai Az aktoroknak a rendszerrel kapcsolatban igényeik vannak, feladatok végrehajtását kezdeményezik, vagy a rendszer által nyújtott funkciók, szolgáltatások megvalósításában vesznek részt. A feladatok végrehajtását kezdeményező szereplőket kezdeményező szereplőnek, a funkció (use case) megvalósításában részt vevőket résztvevő szereplőnek hívjuk. Egy use case-t mindig csak egy aktor kezdeményezhet, egy use case megvalósításában viszont több aktor is részt vehet március 6. 88

45 Aktorok sajátosságai Az aktorok egymással együttműködve megvalósítják a rendszer céljait; Az aktor nem objektum, hanem csak egy osztályszerű elem, amit az UML classifier minősítéssel azonosít; Az aktor grafikus szimbóluma egy pálcikaemberke. szereplő/aktor március Aktorok azonosítása A felhasználóval folytatott beszélgetések, a felhasználói célokat összefoglaló dokumentumok alapján körvonalazódik, hogy mik, vagy kik az érdekeltek a rendszer határán kívül, amik/akik közvetlenül kapcsolatba kerülnek, kommunikálnak a szoftverrendszerrel. A követelményspecifikációban meghatározott érdekeltek köre (pl. a Kft. ügyfélszolgálati munkatársai, mint a szoftverrendszer használói) nem feltétlenül, sőt sok esetben abszolút nem egyezik meg az üzleti modellezés során felállított érdekeltek (pl. a Kft. vezetése, aki tendert írt ki a szoftverrendszer fejlesztésére) listájával március 6. 90

46 Az aktorok megtalálásának módja A felhasználói célokat összefoglaló dokumentumokból kikeressük a főneveket. A kereséskor a releváns szereplők meghatározása érdekében célszerű arra koncentrálni, hogy: Ki/mi használja a rendszert? Kik működtetik a rendszert, kik felelnek a rendszer karbantartási és adminisztrációs feladatainak végrehajtásáért? Kinek a hatáskörébe tartozik a biztonságkezelés, rendszervédelem? Létezik a rendszerben folyamatfigyelés, monitoring folyamat (monitoring process), amelyik hiba esetén újraindítja a rendszert? Kommunikál-e az új rendszer más rendszerekkel? stb március A rendszer szereplőinek specifikálásra vonatkozó előírások A rendszerrel közvetlenül kapcsolatba kerülő, a rendszert használó érdekelteket (személyek, dolgok, más rendszerek, rendszerkomponensek) a feladatkörre, szerepkörre utaló névvel kell ellátni, azonosítani. Az aktorok neve egy tetszőleges jelekből álló karaktersor. Az aktor neve azonosítja a use case-t kezdeményező, vagy a use case megvalósításában részt vevő szereplőt március 6. 92

47 A rendszer szereplőinek specifikálásra vonatkozó előírások Az UML modellező nyelv szabályai szerint az aktorokat grafikusan egy pálcikaember jelöli. Az aktor nevét a szimbólum alá írjuk. A specifikációban röviden meg kell adni mit vár el az aktor a tervezett szoftverrendszertől, mi a felelőssége március Use case-ek azonosítása A rendszer aktorainak, és azok elvárásainak ismeretében már viszonylag könnyű meghatározni a use case-eket március 6. 94

48 Use case Az UML-ben use case-ekkel írható le a fejlesztendő szoftverrendszertől a valós szituációkban a felhasználó által elvárt, megkövetelt viselkedések, a rendszer által nyújtott szolgáltatások március Use case fogalma Feladatok, funkciók kisebb vagy nagyobb egységeinek specifikálására szolgáló grafikus ábrázolási technika a use case-ek valójában a rendszer funkcionalitását, viselkedését fejezik ki a rendszert kívülről szemlélve. A rendszer egy aspektusának pillanatképe. A rendszerrel kapcsolatos összes use case feltárása a fejlesztendő rendszer külső képét adja. A rendszer kívülről látható funkciói, un. kapcsolódási pontok a szoftverrendszert használók és a szoftverrendszer között március 6. 96

49 A use case A felhasználó és a számítógépes rendszer közötti interakciót definiálja. Tipikusan a szoftver és a felhasználó (aktor) között lezajló kommunikáció, üzenetváltás lépéseit írja le a felhasználó szemszögéből. Egy use case pontosan azt határozza meg, hogy a felhasználó (aktor) MIT akar a szoftverrel végrehajtani, milyen célt kíván megvalósítani, ugyanakkor nem tér ki a megvalósítás, a HOGYAN részleteire? március Use case-ek a követelményspecifikációban A követelményspecifikáció munkaszakaszban definiált use case-eket a szakirodalom fekete doboz use caseeknek (black-box use case) nevezi. A fekete doboz jelző: azt hangsúlyozza, hogy a fejlesztésnek ebben a szakaszában nem térünk ki a rendszer, a rendszerkomponensek belső működésére. A cél csak a rendszer viselkedésének specifikálása a rendszert külső szemmel nézve, fontos a külső környezetnek a feltárása, a rendszerhatár meghúzása március 6. 98

50 Példa Black-box módszer a rendszer (külső) viselkedésének leírására Belső működés specifikálása ÁrajánlatKészít_Weben use case: Végrehajtásakor az Ügyfél megadja az Árajánlat összeállításához szükséges adatokat, majd a rendszer elkészíti az árajánlatot. ÁrajánlatKészít_Weben use case: A rendszer ellenőrzi a megadott adatokat, ha az adatok helyesek a rendszer az adatbázisba, az árajánlat táblába beszúr egy új sort, rekordot március A use case-ekre vonatkozó jellemzők, sajátosságok A fejlesztendő rendszer szempontjából megkülönböztetünk: architektúrálisan fontos, egyéb és rendszeridegen use case-eket; egy use case lehet kicsi vagy nagy ; egy use case diszkrét célt teljesít, valósít meg a felhasználó számára; március

51 A use case-ekre vonatkozó jellemzők, sajátosságok a use case-eket minden esetben az aktorok kezdeményezik; március Use case-ek megtalálásának módszerei az adott területre jellemző felhasználóval való folytatott közös beszélgetések, interjúk, kérdőívek használata csoportos felmérés esetén, brainstorming (ötletbörze) módszer alkalmazása. Használata elsősorban új fejlesztések esetén hasznos, vagy nehezen megfogható, leírható problémák megoldásakor. vitakurzusok a korábbi beszélgetések során definiált dolgok (feladatok, funkciók) megvitatására, tisztázására, egyszerű, un. favágó módszer: a célokat megfogalmazó dokumentumokból kigyűjtjük az igéket, stb március

52 A use case-ek specifikálásra vonatkozó szabályok a követelményspecifikáció során feltárt diszkrét dolgokat, feladatokat a use case-eket a funkciójellegre utaló névvel kell ellátni, azonosítani, a use case-t azonosító név egy tetszőleges jelekből álló karaktersor, a use case neve kettős szerepet tölt be: azonosítja a diszkrét feladatot, amit a rendszernek teljesíteni kell, az megnevezés az adott use case-t meg is különbözteti a többi use case-től március A use case-ek specifikálásra vonatkozó szabályok a use case-eket (diszkrét feladat, funkció) az UML modellező nyelv szabályai szerint grafikusan egy ellipszis szimbólum jelöli, a use case (funkció) nevét az ellipszis alá írva adjuk meg, minden use case-hez tartozni kell egy use case leírásnak use case/funkció március

53 Use case leírás A felhasználó szemszögéből rögzítjük a felhasználó és a rendszer között zajló üzenetváltás (párbeszéd) lépéseit: Normál működés, Alternatív működés március Use case leírás Normál működés: a use case szokásos működését a use case normál lefutásának, más szóval alapfolyamatnak hívjuk. Alternatív esetek: A működésnek lehetnek különleges, alternatív esetei (pl. hibás működés), ezek az alfolyamatok. A fejlesztés során minden use case esetén fel kell tárni az összes alternatív lefutási menetet. A use case-ek normál és alternatív működését külön forgatókönyvekben rögzítjük március

54 Forgatókönyv Más szóval szcenárió. A use case egy konkrét végrehajtása, lefutása, a use case egy instanciája (példánya). A use case működésének lépésenkénti, un. step-by-step végrehajtását írja le a felhasználó szemüvegén keresztül. Egy use case-hez az alternatív működések miatt több forgatókönyv készülhet, de egy biztosan március Forgatókönyv A forgatókönyv készítésekor a rendszer és a felhasználó között zajló üzenetváltásokat a felhasználó szerepében célszerű megfogalmazni, hiszen a felhasználó fogja az alkalmazást használni. Az üzenetváltások leírásakor a MIT-re koncentráljunk, azt írjuk le, hogy a use case működéskor MI történik, milyen tevékenységek zajlanak, és ne térjünk ki a HOGYAN részleteire, a megvalósítás módjára. A forgatókönyvben elsőként a use case normál működést írjuk le, de el kell készíteni az alternatív esetekhez tartozó forgatókönyveket is március

55 Forgatókönyv készítése A forgatókönyv készítésére nincsenek szigorú formai előírások, megkötések. A forgatókönyvben a use case működését, vagyis az egymás után zajló tevékenységeket szöveges formában, mondatszerűen fogalmazzuk meg március A forgatókönyv tartalma Egy lehetséges alternatíva: a feladat rövid értelmezése, alternatív útvonalak meghatározása, a végrehajtásban résztvevő szereplők meghatározása, közös feladatok kiválasztása március

56 Forgatókönyv készítése Érdemes megvizsgálni: Hogyan kezdődik a use case? Hogyan ér véget a use case? Milyen kölcsönhatások történnek az aktor és a use case között? Milyen adatok cserélődnek a use case és az aktor között? Milyen ismétlődő viselkedést hajt végre a use case? március Példa Az ÁrajánlatKészít_Weben use case-hez készített részletes leírásban négy forgatókönyvet kell részletezni: A use case normál lefutása szokásos működés esetén: a use case sikeresen véget ér, ha az Ügyfél elfogadja az Árajánlatra vonatkozó feltételeket március

57 Példa A szokásostól eltérő működéskor a lehetséges lefutások, alternatív útvonalak: az Ügyfél a felhasználói név és a jelszó megadásakor a MÉGSEM gombra kattint. az Ügyfél a felhasználói név és a jelszó megadásakor az OK gombot választja, azonban a rendszer a megadott adatok ellenőrzésekor hibát talál. A megadott adatok vagy azért hibásak, mert az ügyfél azokat rosszul adta meg, vagy azért, mert nem regisztrált felhasználó. Ilyen esetben a use case véget ér. Az Ügyfél a rendszer által küldött Árajánlat elfogadása üzenet megerősítésekor a MÉGSEM gombot választja március Forgatókönyv normál működés esetén Az Ügyfél a Kft. honlapján aktiválja az "Az Árajánlat készítés" funkciót. A bejelentkezéskor a rendszer megjeleníti a Login dialógusablakot, ahol kéri az Ügyfél felhasználói nevét, és jelszavát. Az Ügyfél megadja a felhasználói nevét, és jelszavát. A rendszer ellenőrzi (validálja) a megadott adatokat. Hibás adatok esetén újra kéri az adatokat március

58 Forgatókönyv normál működés esetén A rendszer megjeleníti az Árajánlat készítés lapot. Az Ügyfél megadja a kért adatokat. A rendszer validálja a megadott adatok helyességét, ellenőrzi az adatok konzisztenciáját. Ha az Ügyfélnek nem sikerült érvényesen kitölteni a lapot, a rendszer mindaddig visszatér a laphoz, amíg azt az Ügyfél helyesen ki nem tölti. A rendszer megerősítést kér az Ügyféltől az Árajánlat elfogadására. A rendszer elmenti az Árajánlat adatait, és nyugtázó üzenetet küld a képernyőn keresztül az Ügyfélnek az Árajánlat készítésének sikerességéről március Aktivitási diagram A forgatókönyvben meghatározott lépéseket az UML-ben tevékenységeknek, aktivitásoknak nevezzük. A forgatókönyvben meghatározott tevékenységek menetének grafikus szemléltetésére az UML diagramok közül az aktivitási (tevékenységi) diagramot használjuk. Egy use case-hez annyi aktivitási diagram készül, ahány alternatív lefutása (forgatókönyvek száma) van március

59 Az Ügyfél a Kft. honlapján aktiválja az "Az Árajánlat készítés" funkciót. A rendszer megjeleníti a Login dialógusablakot, ahol kéri az Ügyfél felhasználói nevét, és jelszavát. Aktivitási diagram Az Ügyfél megadja a felhasználói nevét, és jelszavát. A rendszer ellenőrzi, validálja a megadott adatokat. [ Hibás adatok! ] A rendszer megjeleníti az "Árajánlat készítés" lapot. Az Ügyfél megadja a kért adatokat. A rendszer validálja a megadott adatok helyességét, ellenőrzi az adatok konzisztenciáját. A rendszer megerősítést kér az Ügyféltől az Árajánlat elfogadására. [ Árajánlat Elutasítva! ] A rendszer elmenti az Árajánlat adatait. A rendszer nyugtázó üzenetet küld az Ügyfélnek a képernyőn az Árajánlat készítésének sikerességéről március Kapcsolatok Kapcsolat alatt klasszikus értelemben: az aktorok és a use case-ek közötti kapcsolatokat értjük. Az UML-ben a rendszer szereplői és a use case-ek között definiált kapcsolatok modellezésére a use case diagram szolgál március

60 Kapcsolatok A kapcsolatot a diagramban az aktorokat és a use case-eket összekötő vonal szimbolizálja. A vonal lehet irányított március Aktorok és use case-ek között értelmezett kapcsolatok típusa Kezdeményezés Közreműködés, részvétel a végrehajtásban március

61 Aktorok és use case-ek között értelmezett kapcsolatok típusa Egy use case-t mindig egy aktor kezdeményezhet, aktivizálhat. A rendszer szereplői és a use case-ek közötti kapcsolatot egy irányított vonal, nyíl jelöli. A nyíl a szereplőtől a use case felé mutat. Az aktor és a számítógépes rendszer között alapértelmezésben kommunikációs jellegű kapcsolat van. A kommunikatív jelleget a kapcsolatot szimbolizáló nyíl felett a <<communicate>> sztereotípiával jelölhetjük március Kezdemenyező szereplő use case március

62 Példa Regisztrál ÁrajánlatKészít_Weben ÁrajánlatLekérdez_Weben Ügyfél (from use case view) (from aktorok) ÁrajánlatMódosít_Weben ÁrajánlatNyomtat_Weben (from use case view) (from use case view) március Aktorok és use case-ek között értelmezett kapcsolatok típusa Egy feladat (use case) végrehajtásában több aktor is közreműködhet. A use case megvalósításában részt vevő szereplőket és a use case-t egyszerű vonal (irányítás nélküli) köti össze március

63 Résztvevő szereplő1 Kezdemenyező szereplő use case Résztvevő szereplő március Speciális kapcsolatok Két aktor közötti kapcsolatot. Definiálhatunk use case-ek közötti speciális viszonyokat is március

64 Speciális kapcsolat két aktor között Öröklődési viszony: egy use case végrehajtásakor több szereplő is ugyanazt a szerepet tölti be, ugyanabban a szerepkörben van. Az öröklődési viszonyban két aktortípus: leszármazott, ős szereplő március Speciális kapcsolat két aktor között A leszármazott minden use case-zel kapcsolatban van, amivel az ős szereplő kezdeményez kapcsolatot. Az ős szereplőnél definiált minden use case végrehajtását kezdeményezheti, de annál akár többet is március

65 Speciális kapcsolat két aktor között Ős szereplő use case/funkció Leszármazott szereplő1 Leszármazott szereplő március Speciális kapcsolat két aktor között Kereskedő Kereskedelmi Menedzser március

66 Speciális kapcsolatok use case-ek között Három speciális viszony: tartalmazás, kiterjesztés és öröklődés viszonyokat március Tartalmazás include viszony A szereplő által kezdeményezett (alap vagy normál) use case-ek végrehajtásában vannak olyan részek, lépések, amelyek mindegyik use case végrehajtásakor bekövetkeznek és azonos módon játszódnak le. Érdemes az azonos viselkedéseket egy külön use case-be kiemelni március

67 Tartalmazás include viszony A kiemelt viselkedés: tartalmazott vagy rész use case. A tartalmazott elnevezés utal arra, hogy a tartalmazott use case az alap use case-nek szerves része. A tartalmazott use case végrehajtása feltétel nélküli, vagyis az alap use case végrehajtáskor mindig bekövetkezik, lejátszódik március Tartalmazás include viszony Az UML-ben az alap use case-t és a tartalmazott use case-t szaggatott nyíl köti össze. A szaggatott nyíl az alap use case-től a tartalmazott felé mutat. A kapcsolat tartalmazás jellegét a szaggatott nyílon elhelyezett, francia zárójelek közé írt <<include>> sztereotípiával jelöljük március

68 Tartalmazás include viszony alap/normál use case1 <<include>> szereplő/aktor alap/normál use case2 <<include>> tartalmazott (included) use case március Tartalmazás include viszony ÁrajánlatKészít_Weben <<include>> <<include>> Ügyfél (from aktorok) ÁrajánlatMódosít_Weben (from use case view) <<include>> ÜgyfélAzonosítás_ felhasználói név&jelszó (from use case view) ÁrajánlatLekérdez_Weben (from use case view) március

69 Kiterjesztés extend viszony A modellben lehetnek use case-ek, amelyek végrehajtási menetében bizonyos feltételek bekövetkezésekor a vezérlés egy másik use case-nek adódik át. Ilyenkor a normál use case-nek egy bővített változata játszódik le. Mivel a normál use case viselkedésében a feltétel csak bizonyos esetekben következik be, ezért a normál use case-t bővítő viselkedést érdemes külön use case-ben leírni március Kiterjesztés extend viszony A feltételt (extention point) a követelmények specifikálásakor kell megadni. A szaggatott nyíl a kiterjesztett use case-ből az alap use case felé mutat március

70 Kiterjesztés extend viszony <<extend>> szereplő/aktor alap/normál use case kiterjesztett (extended) use case március Kiterjesztés extend viszony <<extend>> Kereskedő (from aktorok) MegrendelésKészít (from Kereskedő use case-ei) Kedvezményzárolás március

71 Öröklődés generalizáció Az öröklődési viszony: a leszármazott use case örökli a normál use case viselkedését, kapcsolatait. A leszármazott az eredeti/normál use case viselkedéséhez hozzáadhat újabb viselkedéseket, sőt az eredeti use case viselkedését felülbírálhatja, felülírhatja március Öröklődés generalizáció Az öröklődés jele: az UML-ben egy telt fejű nyíl. A nyíl a leszármazott use case-től az általánosított normál (ős) use case felé mutat március

72 Öröklődés generalizáció szereplő/aktor use case leszármazott use case március Öröklődés generalizáció Kereskedő ÜgyfélTörzsadatFelvitel (from aktorok) <<generalization>> ÜgyfélTörzsadatKarbantartás március

73 Use case modell Aktorok. Use case-ek. Use case-ek struktúrálása. Kapcsolatok. Ábrázolás: Use case diagram március Use case diagram A követelményspecifikációban feltárt use case-eket, Aktorokat (szereplőket) és a közöttük értelmezett kapcsolatokat ábrázolja. Segít: a rendszer viselkedésének megértésében grafikus modellezésében március

74 Use case diagram Alkalmas: A tervezett rendszerrel szemben támasztott összes követelmény (use case-ek halmaza) meghatározására, leírására. Eszköz: A felhasználóval való kommunikációra március ÜgyfélTörzsadatFelvitel <<generalization>> (from ÜgyféltörzsKezelés) ÁrajánlatKészítés (from ÁrajánlatKezelés) ÁrajánlatMódosítás (from ÁrajánlatKezelés) ÜgyfélTörzsadatKarbantartás (from ÜgyféltörzsKezelés) Kereskedő (from aktorok) ÁrajánlatbólRendelés (from ÁrajánlatKezelés) <<extend>> MegrendelésKészítés (from Kereskedő use case-ei) Kedvezmény zárolása (from use case view) Kereskedelmi Menedzser (from aktorok) KedvezményTörlése (from use case view) KedvezményJóváhagyása (from use case view) március

75 Ügyfél által kezdeményezett use caseeket összefoglaló use case diagram Regisztrál ÁrajánlatotKészít _Weben <<include>> Ügyfél ÁrajánlatotLekérdez _Weben <<include>> ÜgyfeletAzonosít_ felhasználóinév&jelszó ÁrajánlatotNyomtat _Weben március Use case modell dokumentálása Aktorok azonosítása. Minden aktor esetén meg kell határozni mit vár el a rendszertől. Use case-ek feltárása, use case lista összeállítása. Minden use case-hez részletes leírás készítése: Alternatív forgatókönyvek készítése a use case működésének leírására. Aktivitási/tevékenységi diagram készítése március

76 Use case modell dokumentálása Kapcsolatok meghatározása: Kapcsolatok aktor és use case között. Speciális kapcsolatok azonosítása. A rendszer funkcionalitásának, viselkedésének grafikus modellezése use case diagramok készítésével. A fejlesztés során menetközben módosult funkciók dokumentálása, módosítások átvezetése a követelménydokumentumba március Követelményjegyzék bejegyzés formalap Funkcionális és nem funkcionális követelmények dokumentálásának eszköze. Követelmények pontosabb, precízebb meghatározása. Nem UML szabvány. Folyamatosan bővül a fejlesztés során március

77 2006. március Követelmény AZ Forrás Prioritás Tulajdonos Funkcionális követelmény Nem funkcionális követelmény Haszon: Megjegyzések/ javasolt megoldási módok Kapcsolódó iratok Kapcsolódó követelmények egyedi azonosító a követelmény forrása, lehet személy, dokumentum stb. a követelmény prioritása, a felhasználó szerint, pl. magas/alacsony, vagy kötelező/ javasolt/ választható felhasználó vagy felhasználói szervezet, aki a követelménnyel kapcsolatos egyezkedésért felelős az igényelt lehetőség vagy szolgáltatás leírása leírás, lehetőség szerint cél értékkel, elfogadható tartománnyal (minimum, maximum), minősítő megjegyzéssel a követelmény kielégítéséből származó várható hasznok leírása lehetséges megoldások leírása, általános megjegyzések hivatkozás kapcsolódó dokumentumokra, mint például felhasználói dokumentumok, projektalapító okirat, adatfolyam-ábra stb. ha különböző követelmények hatnak egymásra, vagy kizárják egymást, akkor a hivatkozást fel kell jegyezni mindkét oldalon, hogy esetleges változtatás esetén fel lehessen mérni a hatást a mások oldalon a követelmény megoldási módjának feljegyzése, például egy konkrét funkcióleírásra Megoldás való hivatkozással. Ha egy követelményt nem fogunk kielégíteni, akkor itt kell felírni az okait március

78 Use case-ek szerepe a követelménykezelés és az elemzés és tervezési egyes fázisokban Követelményspecifikáció: fejlesztendő szoftverrendszertől a felhasználó által elvárt, megkövetelt viselkedés(ek)t, a rendszer által nyújtott szolgáltatásokat írják le. Elemzés és tervezés: A rendszer belső működésének leírása. Hogyan lesznek a rendszertől elvárt funkciók, use case-ek megvalósítva, majd implementálva március