2011.03.02.
Tartalom Nagy rendszerek struktúrált fejlesztése (SSADM)
Szoftvertechnológia előadás
Áttekintés A strukturális modell Az SSADM technikái Az SSADM termékei
2
Bevezető
Történet
Az SSADM az angol "Structured 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. E Ennek k ellenére ll é nagyon szigorú i ú metodika t dik Csak nagy szoftverprojektek esetén térül meg a nagymértékű adminisztrációval járó többletráfordítás
1980 ban a Központi Számítástechnikai és 1980-ban Távközlési ügynökség (CCTA) megbízására dolgozta ki az LBMS cég. Követelmények: { { { {
3
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) 4
1
2011.03.02.
Nyolc ok az SSADM használatára 1.
Nyolc ok az SSADM használatára
A rendszer elkészítése időre Az SSADM szerkezete lehetővé teszi teszi, hogy elemi szintű feladatokig lebontva tudjuk: mit kell előállítani, mikor és hogyan.
2.
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.
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 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é.
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.
5.
7.
A módszer könnyen y tanítható és érthető,, a termék-központúság p g megkímél a felesleges munkák elvégzésétől.
A meglévő szakértelem hatékony és gazdaságos kihasználása 8.
Az SSADM elterjedt technikákat használ az ezeket ismerő fejlesztők könnyen beilleszkedhetnek a munkakörnyezetbe.
A termelékenység növelése 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
Az SSADM helye az életciklusban
6
Az SSADM felépítése
7
8
2
2011.03.02.
A módszer felépítése (törzsrész + útmutatók)
Alapfeltételek (indítás)
Információ { {
Eljárások { {
A kezelendő információ szerkezete elegendő-e a modellezéshez Lehet-e áttekinthető, stabil logikai adatszerkezeteket használni A rendszer által végzendő eljárások szerkezete és pontossága elegendő-e modellezéshez Lehet-e Lehet e magas szintű adatfolyam adatfolyam-ábrát á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
A módszer nézetei (Funkciók, adatok, események)
Résztvevők
Egy módszer emberi tevékenységek rendszerének leírása, amely embereket különböző szerepkörökbe sorol. { { {
10
Felhasználók Vezetők Fejlesztők j
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
3
2011.03.02.
Filozófia
Strukturális modell
három szempontú p modell,, amely y kifejti j 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 f lh felhasználói álói szerepkörök kö ök célkitűzéseit élkitű é it h határozza tá 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
Mit kell előállítani? – Szabványos termékleírások Mikor kell előállítani – Strukturális modell Hogyan kell előállítani? – Technikák 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
Minta (Kombinált nézőpontú ábra)
14
Alapfogalmak
Információáramlási út Egy kommunikációs út minden termék- és ellenőrzés-áramláshoz az SSADM moduljai között. csökkenti az egyedi áramlások számát, a vezetési és technikai folyamatokat elválasztja egymástól. technikai folyamatok között közvetlen áramlások lehetnek míg a technikai és vezetői folyamatok lehetnek, közötti áramlásoknak az információáramlási utat kell használniuk.
15
16
4
2011.03.02.
Alapfogalmak
Alapfogalmak
Vezetői tevékenységek
Az
információáramlási út elválasztja a vezetői tevékenységeket a szakmai tevékenységektől.
Vezetői
Az
információáramlási út alatti központi szakmai tevékenység felbomlik alsóbbrendű folyamatokra, amelyek nem mutatják meg a belső részleteket, de az áramlási kapcsolatokat igen. A folyamatok négy szinten bomlanak fel: {a rendszerfejlesztési j életcikluson belüli modulok {modulokon belüli szakaszok {szakaszokon belüli lépések {lépéseken belüli feladatok.
tevékenységek pl.
{tervezés, { {
Technikai tevékenységek
felügyelet, felügyelet ellenõrzés
17
Alapfogalmak
Tevékenység-leírások
Termék- és ellenőrzésáramlások Termék { { { {
18
A tevékenység termékeinek áramlása Teljesítési jelentések Ellenőrzés/vezetői felhatalmazás áramlása
Minden szinten van egy tevékenységtevékenység meghatározás, ami a következõkből áll: { { { {
célok rövid leírás résztvevők előfeltételek, azaz
A termékáramlás felirata a résztvevő termékeket sorolja lj ffel. l A kkonkrét k ét SSADM ttermékek ék k neveii dőltbetűsek, egyéb termékek nevei normál betűtípussal szerepelnek
{ { { 19
vezetői felhatalmazás (csak modulokban és szakaszokban) kiindulási alapok hivatkozási alapok
termékek technikák (szakaszokban és lépésekben) tevékenységek 20
5
2011.03.02.
Megvalósíthatóság-elemzési modul
Az SSADM életciklus
egy nagyobb fejlesztés elindítása előtt a működési és t h ik i kö technikai követelmények t l é k ki kielégítésének lé íté é k llehetőségeinek h tő é i k 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
21
Követelmény-specifikációs modul
Követelmény-elemzési modul
22
A követelmény-elemzését a követelmény-meghatározás és a rendszerszervezési d é i alternatívák lt tí ák ki kialakítása l kítá vezérli. é li 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.
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)
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 23
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ó y p összeállítása ((380. lépés) p )
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
24
6
2011.03.02.
Logikai rendszerspecifikációs modul
Lehetőséget biztosítani a technikai környezet kiválasztására (a kö t l é követelményeknek k k megfelel f l l és é a legtöbbet l több t nyújtja újtj a ki kiadásokhoz dá kh 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 {
Fizikai rendszertervezési modul
Rendszertechnikai alternatívák (4. szakasz) Logikai rendszertervezés (5. szakasz)
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
Kiinduló Kii d ló anyag: Kiértékelt Kié ték lt kkapacitástervezési itá t é i információk, i f á iók Szervezetszintű környezeti útmutató,Projektalapító okirat, Követelmény-specifikáció, Választott rendszerszervezési alternatíva Termék: Logikai rendszerterv
25
Technikák
{
Technikák
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 { { { { {
Adatfolyam-modellezé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:
26
{
{
mérhetőek elegendően részletesek minimalizálják az ismétlődést
{ {
27
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 adattár-egyed egyed megfeleltetést 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 28
7
2011.03.02.
Technikák
Logikai adatmodellezés {
Egyedek és köztük létező kapcsolatok elemzése és leírása (E/K modell)
Relációs adatelemzés { {
Rendszerszervezési alternatívák { {
Techniká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 { { {
Specifikációs prototípus készítése {
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
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
{
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
29
Technikák
{
{
Termékek
Egyed-esemény 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 {
{
30
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
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 31
32
8
2011.03.02.
Vezetői termékek
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
Technikai termékek
33
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
34
Minőségbiztosítási termékek A módszer főbb termékeinek származtatása
Igazolása annak, hogy a minőség beépült a rendszerbe A projekt előrehaladásával növekednek 35
36
9
2011.03.02.
Irodalom
http://www.itb.hu/ajanlasok/a4/ http://www itb hu/ajanlasok/a4/ http://www.wikipedia.org http://www.cab.u-szeged.hu/local/ ssadm/1998/progterv/Juray_Tamas/
37
10
