Nagy rendszerek struktúrált fejlesztése (SSADM) Szoftvertechnológia elıadás Tartalom Áttekintés A strukturális modell Az SSADM technikái Az SSADM termékei 2 Bevezetı Az SSADM az angol "Structured Systems Analysis and Design Method", azaz a "Struktúrált Rendszerelemzési és Tervezési Módszer" rövidítése. A módszer elkülönült egységekre osztja fel az információs rendszer fejlesztésének munkáit és hajlékonyan idomul a különbözı feladatokhoz. Ennek ellenére nagyon szigorú metodika Csak nagy szoftverprojektek esetén térül meg a nagymértékő adminisztrációval járó többletráfordítás Történet 1980-ban a Központi Számítástechnikai és Távközlési ügynökség (CCTA) megbízására dolgozta ki az LBMS cég. Követelmények: legyen önellenırzı kipróbált módszereket alkalmazzon legyen alakítható legyen tanítható 1983-tól kötelezıen használandó a kormányzati projektekben (Nagy-Britannia kormányzati szabvány) 3 4 Nyolc ok az SSADM használatára Nyolc ok az SSADM használatára 1. A rendszer elkészítése idıre Az SSADM szerkezete lehetıvé teszi, hogy elemi szintő feladatokig lebontva tudjuk: mit kell elıállítani, mikor és hogyan. 2. A felhasználók igényeit kielégítı rendszer készítése Az SSADM olyan tulajdonságokkal rendelkezik, amelyek a felhasználók bevonását szükségessé és lehetıvé teszik 3. Olyan rendszer készítése, amely követni tudja a mőködési környezet változásait Az SSADM-mel készített rendszer dokumentációja a rendszer karbantartásához és továbbfejlesztéséhez alapvetı információkat tartalmazza. 4. A meglévı szakértelem hatékony és gazdaságos kihasználása Az SSADM elterjedt technikákat használ az ezeket ismerı fejlesztık könnyen beilleszkedhetnek a munkakörnyezetbe. 5. A minıség növelése a hibák csökkentése révén A fejlesztési dokumentumok minıségi követelményeinek pontos meghatározásával az SSADM jobb minıségbiztosítást tesz lehetıvé. 6. A hajlékonyság növelése Az SSADM a szabványos termékek elkészítésére vonatkozó tevékenységeket írja le. Tapasztalt szakmai irányítással az erıfeszítések a kritikus termékekre összpontosíthatók. 7. A termelékenység növelése A módszer könnyen tanítható és érthetı, a termék-központúság megkímél a felesleges munkák elvégzésétıl. 8. Az egy szállítótól való függés csökkentése Az elterjedt és "szabványos" módszertan biztosítja a több szállító közül történı választás lehetıségét. 5 6 1
A fejlesztés menete (életciklus) Az SSADM helye az életciklusban 1. Stratégiai tanulmány (projektterv) 2. Megvalósíthatósági tanulmány 3. Teljeskörő vizsgálat (szoftverspecifikáció) 4. Fejlesztési projekt (a rendszer felépítése) 7 8 Alapfeltételek (indítás) A módszer felépítése (törzsrész + útmutatók) Információ A kezelendı információ szerkezete elegendı-e a modellezéshez Lehet-e áttekinthetı, stabil logikai adatszerkezeteket használni Eljárások A rendszer által végzendı eljárások szerkezete és pontossága elegendı-e modellezéshez Lehet-e magas szintő adatfolyam-ábrát rajzolni Terjedelem Lehet-e konkrét kiterjedést meghatározni az alkalmazásra (vagy egyes részeire) Lehet-e kontextus-ábrát rajzolni 9 10 Résztvevık A módszer nézetei (Funkciók, adatok, események) Egy módszer emberi tevékenységek rendszerének leírása, amely embereket különbözı szerepkörökbe sorol. Felhasználók Vezetık Fejlesztık A rendszer leírása elıtt meg kell határozni minden egyes ilyen szerepkörnek a kitőzött céljait és prioritásait. 11 12 2
Filozófia három szempontú modell, amely kifejti a felhasználók nézeteit a rendszer feldolgozásairól, az üzleti/mőködési eseményekrıl és az információról követelmény-központúság, amely az elemzés során megvizsgálandó igényelt célokat fogalmazza meg, a sikeresség mértékével együtt felhasználó-, funkció- és adatmodellezés, amely felhasználói szerepkörök célkitőzéseit határozza meg, illetve a felhasználó és a rendszer kölcsönhatásait vizsgálja vezetıi alternatívák, melyek a vezetıség döntési lehetıségeit fejtik ki a projekt során Strukturális modell Mit kell elıállítani? Szabványos termékleírások Mikor kell elıállítani Strukturális modell Hogyan kell elıállítani? leírása A strukturális modell azt írja le, hogy milyen tevékenységeket kell végezni a módszeren belül és milyen termékáramlással vannak az egyes tevékenységek összekötve. 13 14 Alapfogalmak Minta (Kombinált nézıpontú ábra) Információáramlási út Vezetıi tevékenységek Technikai tevékenységek Rendszerfejlesztés Modulok Szakaszok Lépések Feladatok Termék- és ellenırzésáramlások A tevékenység termékeinek áramlása Teljesítési jelentések Ellenırzés/vezetıi felhatalmazás áramlása 15 16 Tevékenység-leírások Az SSADM életciklus Minden szinten van egy tevékenységmeghatározás, ami a következõkbıl áll: célok rövid leírás résztvevık elıfeltételek, azaz vezetıi felhatalmazás (csak okban és szakaszokban) kiindulási alapok hivatkozási alapok termékek technikák (szakaszokban és lépésekben) tevékenységek 17 18 3
Megvalósíthatóság-elemzési Követelmény-elemzési egy nagyobb fejlesztés elindítása elıtt a mőködési és technikai követelmények kielégítésének lehetıségeinek kiértékelése a költségekhez és várható haszonhoz viszonyítva Szakaszok / Lépések Megvalósíthatóság (0. szakasz) Felkészülés a megvalósíthatósági elemzésre (010. lépés) A probléma megfogalmazása (020. lépés) Megvalósíthatósági alternatívák kialakítása (030. lépés) Megvalósíthatósági tanulmány összeállítása (040. lépés) Kiinduló anyag: Projektalapító okirat Termék: Megvalósíthatósági tanulmány A követelmény-elemzését a követelmény-meghatározás és a rendszerszervezési alternatívák kialakítása vezérli. A jelenlegi környezet felmérése során felderített követelmények illetve az új rendszerrel szemben támasztott új követelmények alapján lehetséges alternatívákat kell felkínálni a felhasználói vezetés számára. Szakaszok: A jelenlegi helyzet vizsgálata (1. szakasz) Rendszertervezési alternatívák (2. szakasz) Kiinduló anyag: Projektalapító okirat, megvalósíthatósági tanulmány, Korábbi tanulmányok anyagai Termék: Követelmények elemzése, Rendszertervezési alternatívák, Választott alternatíva, Projekt és elemzés terjedelme 19 20 Követelmény-specifikációs Logikai rendszerspecifikációs Cél a részletes specifikáció elıállítása, amelyet kiindulásként lehet használni a további fejlesztés indítására Szakaszok/Lépések: Követelmények meghatározása (3. szakasz) Igényelt rendszer folyamatainak meghatározása (310. lépés) Igényelt rendszer adatmodelljének kidolgozása (320. lépés) Rendszer funkcióinak elıállítása (330. lépés) Igényelt adatmodell megerısítése (340. lépés) Specifikációs prototípusok kidolgozása (350. lépés) Feldolgozási folyamatok meghatározása (360. lépés) A rendszer-célkitőzések véglegesítése (370. lépés) A követelmény-specifikáció összeállítása (380. lépés) Kiinduló anyag: Követelmények elemzése, Szervezetszintő környezeti útmutató, Prototípus kiterjedés Termék: Követelmény-specifikáció, Parancsszerkezetek, Menüszerkezetek, Prototípus-kiértékelés Lehetıséget biztosítani a technikai környezet kiválasztására (a követelményeknek megfelel és a legtöbbet nyújtja a kiadásokhoz képest) Megvalósítási módtól független részletes specifikációt nyújtani az igényelt mőködésrıl Szakaszok Rendszertechnikai alternatívák (4. szakasz) Logikai rendszertervezés (5. szakasz) Kiinduló anyag: Kiértékelt kapacitástervezési információk, Szervezetszintő környezeti útmutató,projektalapító okirat, Követelmény-specifikáció, Választott rendszerszervezési alternatíva Termék: Logikai rendszerterv 21 22 Fizikai rendszertervezési A logikai rendszerspecifikációból és a technikai környezet leírásából kiindulva az adatok és folyamatok fizikai részleteinek megfogalmazása Megvalósíthatósági elemzés Egy megvalósíthatósági elemzés elızze meg a teljeskörő vizsgálatot (követelményelemzés, követelményspecifikáció és logikai rendszerspecifikáció) Ha alacsony a rendszer kockázata, akkor elegendı az SSADM teljeskörő vizsgálatának kezdetén meghatározott munkákat elvégezni Követelmény-meghatározás Funkcionális és nem-funkcionális követelmények Követelményjegyzék készítése Önmagában nem elegendı a pontos specifikációhoz Ismétlıdı folyamat (egyre részletesebb leírások) A követelmények: mérhetıek elegendıen részletesek minimalizálják az ismétlıdést 23 24 4
Adatfolyam-modellezés Az elemzés legkorábbi fázisaitól kezdve a követelményspecifikáció elejéig (az igényelt rendszer adatfolyam-modelljéig) Elıször a jelenlegi fizikai adatfolyam-modell készül el A fizikai modell tartalmazza az összes kiegészítı leírást az adatfolyam-ábrák mellett. Ezt a fizikai adatfolyam-modellt azután, összevetve az elkészült logikai adatmodellel, meg kell szabadítani a fizikai kényszerőségektıl. (logikalizálás / racionalizálás). Létre kell hozni a logikai adattár-egyed megfeleltetést, ami kapcsolatot létesít az eddig párhuzamosan fejlesztett logikai adatmodell és a logikai adatfolyam-modell között. Könnyen elıállítható, érthetı ábrákat produkál (DFD-szerő) A jelenlegi rendszer továbbvihetı, az új rendszerben felhasználható logikai folyamatait ábrázolja Logikai adatmodellezés Egyedek és köztük létezı kapcsolatok elemzése és leírása (E/K modell) Rendszerszervezési alternatívák Egy lehetséges megoldást ír le egy felvetett információs rendszerre Lehetıség van arra, hogy felhasználók és elemzık közösen megvizsgálják a rendszer határainak lehetséges változtatásait Funkció-meghatározás A funkciók olyan feldolgozási egységek, amelyek a felhasználókat támogatják Eljárás, amivel a létezı termékek alapján azonosítani lehet a rendszer funkcióit Nincsenek pontos szabályai, a fejlesztık tapasztalatán és tudásán alapul 25 26 Relációs adatelemzés Kiegészíti illetve ellenırzi a logikai adatmodellezést Az adatoknak egy olyan szerkezetét lehet elıállítani, amely a lehetı legkevesebb ismétlıdést és a lehetı legnagyobb rugalmasságot biztosítja (normalizáció) A logikai adatmodellezés biztosítja, hogy a projekt számára lényeges adatok átfogó képe ne vesszen el, míg a relációs adatelemzés biztosítja, hogy az összes alacsonyszintő részletet megfogjuk Specifikációs prototípus készítése A követelmény-specifikáció egyes kiválasztott részeinek ellenırzésére épül Fıbb feladatok: a menü és parancs szerkezetek prototípusainak elkészítése a menük, képernyık és jelentések mőködési együttesét bemutató prototípusok megtervezése és elkészítése a prototípusok bemutatása és felülvizsgálata a prototípusok tartalmára vonatkozó módosítások elvégzése a támogató SSADM dokumentációra vonatkozó módosítások elvégzése Egyed-esemény modellezés Az egyedek életének vizsgálata A rendszer részletes feldolgozási folyamatainak az ábrázolására lehet használni JSP formalizmusait használja Rendszertechnikai alternatívák kialakítása Információt nyújt a felhasználói vezetés részére a továbbhaladás módjáról, költségeirıl, feltételeirıl és idıtávjáról Az alternatívák kialakítása itt is hasonlóan történik mint a megvalósíthatóság elemzése vagy a rendszerszervezési alternatívák esetén 27 28 Termékek Vezetıi termékek A termék-felépítési szerkezet egy kezdeti "szabványos" modellt alkot Nem szükséges egy az egyben lemásolni, a projekt igényeihez lehet igazítani 29 A projekt tervezéséhez és ellenırzéséhez szükséges termékek dokumentumai A fontos stratégiai kérdéseket tartalmazó termékek is 30 5
Technikai termékek Minıségbiztosítási termékek A fejlesztési folyamat nagyobb termékeit tartalmazza (felsı szint) Kezdeti erıforrás (ember) végsı felhasználható termékké (kiképzett emberré) alakítását is tartalmazza 31 Igazolása annak, hogy a minıség beépült a rendszerbe A projekt elırehaladásával növekednek 32 A módszer fıbb termékeinek származtatása Irodalom http://www.itb.hu/ajanlasok/a4/ http://www.wikipedia.org http://www.cab.u-szeged.hu/local/ ssadm/1998/progterv/juray_tamas/ 33 34 6