SSADM

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót

(vágatlan)

Mik a szoftverfejlesztés lépései?

Modellezés A „valóság” rendszerei:

• A követelményeket kielégítő rendszerek leképzése: Problématér / Fogalmi tér
• A felhasználható eszközökből kialakítható rendszerek leképzése: Implementációs tér
• Tervezés*
• A fogalmi modellnek megfelelő optimális implementáció létrehozása

• ábra*: problématér+implementációs tér ~ valóság

Milyen okai vannak az SSADM fejlesztésének/alkalmazásának?

1. Segíti a fejlesztés határidőre való elvégzését:

• • elemi szintre lebontott tervekkel (mit, mikor, hogyan)
  • előírt ellenőrzéssel,
  • elvégzendő munka megbecsülhetőségével.

1. Támogatja a felhasználó bevonását a fejlesztésbe:

• • prototípus készítés lehetősége,
  • grafikus technikák alkalmazása,
  • alternatívák kialakítása és választási lehetőség.

1. Dokumentáltsága támogatja a rendszer működtetését, továbbfejlesztését.
2. Támogatja az „új” fejlesztő beillesztését: A formalizálást megvalósító technikák (lásd később) használata könnyű beilleszkedést, megértést biztosít.
3. Optimális megfelelőség biztosítása:

• • korai fázisban validálás,
  • teszttervek, verifikálás,
  • teljesség, konzisztencia.

1. Támogatja a termelékenységet és rugalmasságot:

• • a technikák elősegítik az elsajátíthatóságot és pontosságot, rövidítik a fejlesztési időt,
  • a projektirányítás a kritikus termékekre tud összpontosítani.

1. A szállítóktól való függés csökkentése:

• • a formális specifikáció lehetővé teszi az ajánlatok gondos összevetését,
  • a logikai és fizikai tervezés szétválasztása csökkenti az újraírás költségeit.

A SSADM helye a rendszerfejlezsés életciklusában

ábra

Alkalmazhatósági feltételek

• rendelkezésre álló adatok ...
• funkciók és követlemények ...
• terjedelem ...

A SSADM három nézete

ábra

Modellek - ismétlés

• logikai adatmodell
• adatfolyam modell
• egyed-esemény modell

Alapelvek

• keret, cél ...
• résztvevők és nézőpontjaik ...
• kulcsfogalmak ...

Rendszerfejlesztési alapminta szerkezete

döntési struktúra + viszgálat/helyzetfelismerés + specifikáció + rendszerépítés + felhasználói szervezet + koncepciók és eljárások. ábra

Mi a PDI jelentése?

Process Data Interface

Mely komponensek tartoznak a ~ az SSADM specifikációs architektúrájában?

fogalmi modellhez

• Entitás-élettörténet
• Kölcsönhatás ábrák
• Lekérdezési út
• Logikai adatmodell

felület tervhez

• Adatfolyam-modell
• Funkciók meghatározása
• Logikai dialógusok

belső tervhez

• .
• .

Specifikációs arhitektúra

ábra

=SSADM moduljai és szakaszai

*Modul*	*Szakasz*
Megvalósíthatósági-elemzés	0. A megvalósíthatóság eldöntése
Követelményelemzés	1. Jelenlegi helyzet vizsgálata 2. Rendszerszervezési változat kiválasztása
Követelmény specifikáció	3. Követelmények meghatározása
Logikai rendszerspecifikáció	4. Rendszertechnikai változat kiválasztása 5. Logikai rendszertervezés
Fizikai rendszertervezés	6. Fizikai rendszertervezés

Követelményelemzési modul (RA) szakaszai

1. szakasz: Jelenlegi környezet vizsgálata. 2. szakasz: Rendszerszervezési alternatívák

A 0. szakasz termékei, technikái

• Termékek:
  • Megvalósíthatósági tanulmány
• Technikák:
  • Rendszerszervezési alternatívák kialakítása
  • Adatfolyam modellezés
  • Dialógustervezés
  • Logikai adatmodellezés
  • Követelmény-meghatározás
  • Rendszertechnikai alternatívák kialakítása

Az 1. szakasz lépései

• 110. lépés: Elemzés keretei megteremtése
• 120. lépés: Követelmények vizsgálata, meghatározása
• 130. lépés: Jelenlegi folyamatok vizsgálata
• 140. lépés: Jelenlegi adatok vizsgálata
• 150. lépés: Jelenlegi szolgáltatások „logikalizálása”
• 160. lépés: A vizsgálat eredményeinek összeállítása

A 2. szakasz lépései

• 210. lépés: Rendszerszervezési alternatívák meghatározása
• 220. lépés: Rendszerszervezési alternatíva kiválasztása

A 2. szakasz technikái:

• Rendszerszervezési alternatívák kialakítása
• Adatfolyam modellezés
• Logikai adatmodellezés

A 3. szakasz lépései

• 310.lépés: Igényelt rendszer folyamatainak meghatározása
• 320.lépés: Igényelt rendszer adatmodelljének kidolgozása
• 330.lépés: A rendszer funkcióinak az előállítása
• 340.lépés: Igényelt adatmodell megerősítése
• 350.lépés: Specifikációs prototípusok kidolgozása
• 360.lépés: Feldolgozási folyamatok meghatározása
• 370.lépés: Rendszer-célkitűzések véglegesítése
• 380.lépés: A követelmény-specifikáció összeállítása

A 3.szakasz technikái

• DFD
• LDM
• Dialógustervezés
• Egyed-esemény modellezés
• Funkció-meghatározás
• Relációs adatelemzés
• Követelmény-meghatározás
• Specifikációs prototípus készítés

Az LS modul célja és leírása:

• A projektvezetés és a választott rendszerszervezési alternatíva és a követelmény-specifikáció ismeretében megvalósítási IT-lehetőségeket mérlegel: programozási nyelvek, fejlesztői/futtatási környezet, platformok stb.
• A követelmény-specifikáció alapján történő implementáció a rendszer működését formális lekérdezési, illetve módosító feldolgozásokkal realizálja

A 4.szakasz lépései:

• 410.lépés: Rendszertechnikai alternatívák meghatározása
• 420.lépés: Rendszertechnikai alternatíva kiválasztása

5. szakasz lépései:

• 510.lépés: Felhasználói dialógusok meghatározása
• 520.lépés: Módosító feldolgozások tervezése
• 530.lépés: Lekérdező feldolgozások tervezése
• 540.lépés: Logikai rendszerterv összeállítása

Milyen folyamatok tervezése folyik az 5. szakaszban?

• Módosító
• Lekérdező

Az 520.lépés (Módosító feldolgozások tervezése), lépés célja:

• Teljessé tenni az eseményekhez tartozó adatbázis-aktualizálások specifikációját
• Meghatározni az eseményekhez tartozó hibakezelést

-- adamo - 2006.04.15.